非専門家のための人工知能統計学
arigaram
数式一つ、コード一行も使わずに、人工知能の開発と活用に必要な基礎統計の本質を突き詰めます。
入門
AI
受講生 36名
難易度 入門
受講期間 無制限
リクエスト、要求事項、ユーザーの反応、コードレビューの中に隠れた真の問題を見つける方法
本当の問題を問題定義文(プロブレム・ステートメント)の公式などを用いて、構造化された問題として表現する方法
問題の根本原因を見つける方法
現象から本質を洞察する「問題化」という哲学的概念
「問題化」を行うためのさまざまなツール
2026年3月6日
全体的に内容と授業資料を改善しました。[第2版]と表示して授業を入れ替えていきます。
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
696
受講生
38
受講レビュー
2
回答
4.6
講座評価
18
講座
ITが趣味であり、職業でもある人間です。
執筆、翻訳、アドバイザリー、開発、講義など、多岐にわたる経歴を持っています。
全体
73件 ∙ (17時間 49分)
講座資料(こうぎしりょう):
全体
3件
5.0
3件の受講レビュー
受講レビュー 330
∙
平均評価 5.0
受講レビュー 2
∙
平均評価 4.5
受講レビュー 111
∙
平均評価 4.9
知識共有者の他の講座を見てみましょう!
同じ分野の他の講座を見てみましょう!