大規模言語モデル(LLM)の基礎原理の理解
arigaram
¥12,377
中級以上 / NLP, gpt, AI, ChatGPT, LLM
4.0
(3)
ChatGPTのような大規模言語モデルの基礎原理を理論中心に説明します。
中級以上
NLP, gpt, AI
問題化(Problematization)は、問題提起、問題づくりなどとも訳される用語です。そして問題設定や問題定義とも訳すことができます。要求事項や常識のような既知の事実に対して新しい観点から疑問を投げかけ、問題を定義し、この問題を解決する方式を組み立てていく過程が含まれている概念です。問題化はあらゆる開発の出発点となるべきですが、まだ開発分野では十分に議論されていないテーマです。プロジェクトを遂行することやプログラムを開発することも、実は問題を解決する計画を立てることです。つまり、問題化と関連があるということです。問題を解決するには、まず問題が明確に定義されていなければなりません。しかし、ほとんどの場合、曖昧な要求の形で問題が与えられます。したがって、曖昧な要求を明確な問題に変える力があってこそ、不要な「開発の無駄」を減らし、協業は円滑になり、ユーザーの本当のニーズを正しく把握することができます。この講義は実践事例とツールを通じて問題を「構成する思考」を訓練できるよう支援します。
受講生 36名
難易度 入門
受講期間 無制限
リクエスト、要求事項、ユーザー反応、コードレビューに隠された本当の問題を見つける方法
真の問題を問題記述の公式などを使用して構造化された問題として表現する方法
問題の根本原因を見つける方法
現象から本質を洞察する「問題化」という哲学的概念
「問題化」を実行するための様々なツール
2026年1月2日
動画の音質を改善し、講義内容を補完する作業を開始しました。全体の授業を改善するには多少時間がかかる場合があります。改善作業を完了した授業名の前には「[音質改善完了]」と表示します。
新人・ジュニア開発者のための協業、要求分析、コードレビューの出発点!
PM/POの立場から「開発の無駄」を防ぐために全チームメンバーに推奨すべき基本スキル!
コラボレーションツール、ソフトスキル、問題解決能力などに関連する基礎能力!
「企画書が曖昧すぎて何を作ればいいのか分かりません。」
「レビューでフィードバックはもらったんですが、正確にどこを直せばいいのか分からないんです。」
「いざコードを書こうとしたら…私は何を解決しようとしてたんだっけ?」
「質問したら『で、何が問題なの?』って聞き返されたんですよ。」
このすべての混乱の核心は問題を正確に定義できなかったためです。開発者は絶えず問題に直面します。しかし、その問題を正確に見つめ、定義できなければ正しい解決は始まりません。
曖昧な要求事項: 新入開発者はプロジェクトでしばしば不明確な要求事項を与えられる。例えば「ウィジェットを作ってほしい」といった曖昧な指示を受けると、具体的にどのような機能を実装すべきか混乱してしまう。開発者向けブログによると、新規入社者は「不明確な指示」(vague instructions)と十分なガイドの不在により混乱を経験する(codeanywhere.com)。
経験不足: 業務経験が少ないため、問題を体系的に分解したり、必要な情報を自ら見つけ出すことが難しい。実際の事例として、ある新人開発者はどこまで自分で解決すべきか判断することが難しく、過度に長い時間解決を試みた後にようやく質問するよう学んだ(rachsmith.com)。このような不確実性は不安感(インポスター症候群)につながり、学習と協業を阻害する。
コミュニケーションギャップ: ドメイン知識やビジネスコンテキストが不足していると、要求事項の核心的な問題を正確に把握できない。開発コミュニティでもドメイン知識の不足が要求事項の誤解につながるという指摘があり(kedin.com)、これはすぐに誤った実装や手戻りを生む。
曖昧な要求を明確に整理し、核心的な問題を設定する実践的な思考法
要求事項から問題を引き出す質問法
「問題」を問題らしくする5つの基準
言葉が異なるチームメンバーとも共感を形成する技術
問題を「定義」し「構造化」する図式化方法
コードレビュー、企画会議、業務伝達時に正確に聞き返す技術
15の主要パターン
クライアントや企画者が投げかけた言葉が曖昧すぎて、何を作ればいいのか分からない場合
例:「UXがちょっとイマイチです」「遅いです」「もっと直感的にしてください」
→ 要求を問題に変換する力が不足している状態
依頼: "UXをもっと良くしてください"
反応: "ただUXを良くしてほしいとだけ言われても.....どういう意味だろう?"
"'もっと直感的にしてください'という言葉に戸惑ったことはありませんか? 曖昧な依頼を明確な問題に変える技術、今から始めましょう。"
問題を分析し構造化する能力がまだ身についていない
企画者の言葉を書き取るレベルに留まっている場合
→ 自ら問題を定義できる技術が必要
依頼: 'OO' 機能 - 未定状態。まもなく決定される予定。
反応: "いくつかの機能が決まっていない現在の状態のまま開発しても大丈夫なのだろうか?"
「言われた通りに作るだけになっていませんか?企画を解釈し、問題を自ら定義できる開発者へと成長しましょう。」
機能実装は上手くできるが、その機能がなぜ必要なのか説明できない
開発の目的と問題の文脈を設計することに困難がある
→ 開発者 → 問題解決者 → 問題設定者へと成長しようとする人
要求:ボタンサイズ+10ピクセル
反応:「それは...なんとなくそういう風に作ったら良さそうな気がして...」
「機能を実装することはできるけど、理由を説明できないなら?問題の本質を見抜く思考が今必要な時点です。」
言葉は多く交わされるのに、「何が問題なのか」についての共通認識が形成されない
フィードバックが繰り返されたり、コミュニケーションの衝突が頻繁に起こる
→ 異なる言語を構造化し、協業の中心を定めたい人
要望:「お願いだからもっと直感的な感じにして」
反応:「デザイナーはなぜいつも『感じ』みたいなものばかり言うんだろう…?」
「企画者と話が通じないと感じていませんか?お互いの言葉を『問題』として整理すれば、協業が変わります。」
問題を定義し、方向性を提示すべき役割へと成長中の開発者
漠然とした要求をチームのタスクとして構造化する能力が必要
→ 問題設定はリーダーシップの始まり
要請:[情報要請(Request) > 原因(Cause) > ユーザー状況(User Situation)]の構造に合わせて...
反応:「これをチームの課題にするには、どう定義すればいいだろう?」
「漠然とした依頼を仕事として構造化する能力、今あなたがチームを率いる開発者になる第一歩です。」
この講義は「コードは書けるけど、何を書けばいいのかわからない」という悩みを抱えるすべての開発者に必須の講義です。
特に新人〜3年目のジュニア開発者には必須スキルと言えます。
要件収集の質問: 開発者掲示板やRedditで新人・準備生が「要件をどのように収集・分析しますか?」と尋ねる投稿がしばしば見られる。例えば、あるコンピュータ工学科の学生は「実務で利害関係者の要件をどのように集めますか?」と先輩開発者のアドバイスを求めた(reddit.com)。これは実際のプロジェクトで明確な要求を得る方法に対する需要を示している。
役割の強調: 中堅開発者のアドバイスによると、ソフトウェア開発の核心は「問題定義(Problem definition)」であり、真の専門家には要求事項を正確に定義する能力が必要だと言及されている(medium.com)。開発者コミュニティでもこのように問題定義の重要性を強調する意見が頻繁に見られる。
教育の必要性: 韓国の開発者ブログでは「基本」として問題定義能力を挙げており(medium.com)、データを分析したりシステムを設計する際にツールよりも解決すべき問題をまず定義することが必須であると指摘している(inflearn.com、velog.io)。このような記事は学習者に問題定義スキルの必要性を浮き彫りにしている。
実務ベースの思考法:
実際の協業で経験する問題事例を中心に構成
短く明確な講義:
各授業は一般的に10分以内で構成(例外もあり)されており、没入度の高い学習が可能
思考の構造化トレーニング:
問題を定義する「思考の流れ」を視覚的に整理するスライド中心の講義
実践例:
曖昧なフィードバック、抽象的な企画を明確な問題に変える対話方式を収録
問題設定とは何か – 問題解決の出発点
曖昧な依頼、どこから間違っていたのか
問題を問題らしくする5つの基準
「で、何が問題なの?」を違う形で尋ねる技術
コードレビュー、企画、スケジュール調整…問題設定が使われるあらゆる瞬間
混乱した要求も自ら構造化して整理できるようになります
一つの質問で核心を突く開発者になれます
業務コラボレーション時に不要な誤解を減らし、正確な会話を主導できます
レビューフィードバックも単純な指摘ではなく解決可能な問題に変換できます
開発者の仕事の始まりは、常に「リクエスト」を受けることから始まります。しかし、リクエストはほとんどが曖昧で不明確です。これを正確な問題に変えられなければ、企画がずれ、開発は空回りし、スケジュールは遅れます。
例:「ボタンをもう少し大きくしてください」→→ なぜ?誰に対して?何が問題なのか?
新人開発者やジュニアにとって最も難しい部分は、単純な実装ではなく「何を実装すべきか」を判断する能力です。この講義はまさにその点を指摘してくれます。
要件分析、コードレビュー、コミュニケーション、PMとの協議…すべて問題定義がうまくできてこそ流れがスムーズになります。この講義は話を聞いて本質を引き出す思考法を訓練してくれます。
実習のない理論ではなく、すぐに実務で使える問題陳述の公式、フィードバック基準、質問技法などを提供します。
要約すると、この講義は「なぜこれを開発しなければならないのですか?」「これは本当に問題なのですか?」という質問の前で立ち止まらず、
明確な判断と発言が可能な開発者になれるよう支援します。
🎯 今の開発者市場では、このように「考えることができる開発者」が最も速く成長します。
これからは、問題解決ではなく問題設定からうまくできる開発者になってみてください。
問題を正確に見ることができてこそ、解決も成長も始まります。
学習対象は
誰でしょう?
与えられた要求をそのまま実装するより、何が本当の問題なのか自ら考え判断する力を身につけたい開発者
曖昧な要求と意見の中でチームの方向性を定め、開発者と円滑にコミュニケーションを取りたい企画者、デザイナー、PM/PO
645
受講生
32
受講レビュー
2
回答
4.5
講座評価
18
講座
ITが趣味であり、職業でもある人間です。
執筆、翻訳、アドバイザリー、開発、講義など、多岐にわたる経歴を持っています。
全体
72件 ∙ (17時間 32分)
講座資料(こうぎしりょう):
全体
3件
5.0
3件の受講レビュー
受講レビュー 329
∙
平均評価 5.0
受講レビュー 2
∙
平均評価 4.5
受講レビュー 111
∙
平均評価 4.9
知識共有者の他の講座を見てみましょう!
同じ分野の他の講座を見てみましょう!
¥6,896

