取り組む課題と開発テーマの決定

• 日程: Day 2 / セッション 4
• 時間: [11:35-12:40]
• 形式: 実習
• ゴール: 合意形成ルールに従い、課題候補から「取り組む課題」1つと「開発テーマ」1つを時間内に決定し、選定理由を1分で説明できる
• 学習形式: グループワーク、AIディスカッション

いよいよDay 2のクライマックスです。これから70分で、22日間付き合うことになる「取り組む課題」と「開発テーマ」を決定します。

ここで少し考えてみてください。Day 1のセッション4で、チーム計画書に合意形成ルールを書きましたね。あのルールは何のために作ったのでしょうか？

今日のためです。

「全員一致か、多数決か」「意見が割れたら誰がどう裁くか」。あの取り決めを実際に使う最初の場面が、このセッションです。テーマ決定はチーム開発で最初の、そして最大級の意思決定。ここで合意形成の練習をしておくと、この先の設計・実装で意見が割れたときも、チームは壊れません。

決定したテーマは、最後にAIに説明して、矛盾や弱点を指摘してもらいます。「話す＆行う」で学びを定着させましょう。

このセッションの流れは次のとおりです。

各ステップのコツを押さえておきましょう。

• 前提条件チェック: 課題候補20個をふるいにかける。セッション3の問い「何の情報を、ためて、どう加工して、誰に返す？」に答えられない候補を外す。ここは議論不要の機械的な作業。迷う候補は残してよい
• 2軸評価: 残った候補を「価値」「実現可能性」で評価し、上位3〜5個に絞る。各自が推し候補に投票する方式（ドット投票）が速い
• 合意形成ルールで決定: 上位候補について「推す理由」を1人30秒で話してから、チーム計画書のルールに従って決める。決め方そのものをルールに従わせるのが今日の練習
• 選定理由の言語化: 「誰の・どんな困りごとを・なぜ自分たちが・どんなシステムで解決するのか」を文章にする
• AIディスカッション: 決定内容をAIに説明し、反論役として穴を探してもらう

注意してほしいのは、「課題」と「テーマ」は別物だということです。

• 取り組む課題: 誰が・どんな場面で・何に困っているか（例: 「一人暮らしの新社会人が、冷蔵庫の食材を把握できず無駄にしてしまう」）
• 開発テーマ: その課題を解決する情報処理をともなうシステム（例: 「食材の登録・賞味期限管理・レシピ提案を行う食材管理システム」）

課題は「問い」、テーマは「答えの方向性」。セットで決めて、セットで説明できるようにします。

• 決定の手順: 前提条件チェック→2軸評価→合意形成ルールで決定→理由の言語化→AIレビュー
• Day 1で決めた合意形成ルールを必ず開いて、その通りに決める。ルールが現実に合わなければ「事前に報告して調整する」（本講義のルール）に従って修正する
• 「課題」と「テーマ」を別々の文章で書き分ける
• よくある間違い: 声の大きい人の案に流れること。全員が30秒ずつ話してから決めるだけで、決定の質と納得感が大きく変わる

NASAの研修などで使われる「コンセンサスゲーム」（月で遭難したら何を持っていくか等）では、毎回面白い結果が出ます。話し合いで合意したチームの答えは、メンバー個人の答えの平均より高得点になることが多いのです。「三人寄れば文殊の知恵」は実験的にも裏付けがあるわけです。ただし条件があります。安易な多数決や声の大きさで決めず、全員が理由を話すこと。逆に、誰も本心では賛成していないのに「皆が賛成してるっぽいから」と全員が口をつぐんで決まってしまう現象は「アビリーンのパラドックス」と呼ばれます。テキサスの一家が、誰一人行きたくなかった炎天下のアビリーンの町まで往復85kmのドライブをしてしまった逸話が由来です。今日のチームにアビリーン行きのバスを出さないために、「気になる点があれば今言う」を徹底しましょう。

決定したら終わり、ではありません。決定を鍛える工程が残っています。

人間のチームは、決定した直後ほど「自分たちの案の良いところ」しか見えなくなります（確証バイアス）。そこで、しがらみのないAIに反論役を頼みます。

そのまま使えるプロンプト例:

私たちのチームは、PBL研修（22日間、実装は実働約8日、前提知識は
プログラミング基礎とデータベース基礎）で開発テーマを決定しました。

取り組む課題: [課題を記入]
開発テーマ: [テーマを記入]
選定理由: [理由を記入]

あなたは厳しいレビュアーです。以下の観点で矛盾や弱点を指摘してください。
1. この課題は本当に「世の中でまだ解決されていない」か（類似サービスの存在）
2. このテーマは「情報処理をともなうシステム」として成立しているか
   （何の情報を、ためて、どう加工して、誰に返すのか）
3. 実働8日の実装で完成させられる規模か
4. 課題とテーマの間に飛躍はないか
最後に、弱点を補う改善案も提案してください。

AIの指摘を受けたら、チームで対応を決めます。

• 致命的な指摘（既に同じサービスが広く普及している等）→ 候補2位のテーマと比較し直す
• 規模の指摘（8日では大きすぎる等）→ 対象範囲を縮小する（セッション3で学んだ手法）
• 軽微な指摘 → 選定理由に「この弱点は承知の上で、〜と考えた」と書き足す。弱点を知っていること自体が強み

ここで大事な心構えを1つ。AIの指摘は命令ではなく材料です。最終決定権はチームにあります。「AIがこう言ったから変える」ではなく、「AIの指摘を聞いた上で、チームはこう判断した」と言えるのがプロの姿勢です。

• 決定直後のチームは自分の案に甘くなる。第三者役のAIで決定を鍛える
• 反論プロンプトには「研修の制約（期間・前提知識）」を必ず含める。制約を知らないAIの指摘はピントがずれる
• AIの指摘への対応（採用・縮小・承知の上で進む）をチームで決め、記録に残す
• よくある間違い: AIに褒められて満足すること。「厳しいレビュアー」と役割を指定しないと、AIは基本的に好意的に応えてしまう

あえて反対意見を言う役を立てる手法は「悪魔の代弁者（devil's advocate）」と呼ばれます。語源は16世紀のカトリック教会。聖人の認定審査で、候補者の欠点をあえて指摘する専門職が公式に置かれていました（1983年まで実在！）。現代では、ケネディ大統領がキューバ危機の際、側近にあえて反対役を演じさせて意思決定の質を高めた話が有名です。逆に反対役なしで突き進んだ失敗が前年のピッグス湾事件で、この2つはセットで「集団浅慮（グループシンク）」の教材になっています。皆さんは専属の悪魔の代弁者を、いつでも呼び出せる時代にいるのです。

進める前に疑問があれば、AIに質問してみましょう。たとえば：

• 「ドット投票のやり方を具体的に教えて」
• 「意見が2つに割れて合意形成ルールでも決まらない。第3の決め方を提案して」
• 「『課題』と『テーマ』の書き分けのお手本を3組見せて」

セッション2で作った課題候補リストから、チームの合意形成ルールに従って「取り組む課題」1つと「開発テーマ」1つを決定してください。決定後、AIに矛盾や弱点を指摘してもらい、選定理由を仕上げてください。

進め方の目安:

1. 前提条件チェック（10分）: 候補20個を「情報処理をともなうか」でふるいにかける。判断に迷う候補はAIに変換案（情報管理システムへの捉え直し）を出してもらう
2. 2軸評価と絞り込み（10分）: 価値×実現可能性で上位3〜5個に絞る。ドット投票（1人2票など）を活用する
3. 合意形成と決定（15分）: 上位候補それぞれの「推し理由」を1人30秒で共有。チーム計画書の合意形成ルールに従って、課題1つ＋テーマ1つを決定する
4. AIディスカッション（10分）: 本編のプロンプト例を使い、AIに弱点を指摘してもらう。指摘への対応をチームで決め、必要ならテーマの範囲を調整する
5. 選定理由の仕上げと発表練習（5分）: 「誰の・どんな困りごとを・なぜ・どんなシステムで」を1分で話せる形にまとめ、代表者が声に出してリハーサルする（話す＆行う）

• 「取り組む課題」: 誰が・どんな場面で・何に困っているかを記述した文章
• 「開発テーマ」: 課題を解決する、情報処理をともなうシステムの説明（何の情報を、ためて、どう加工して、誰に返すか）
• 選定理由: 1分で説明できる分量。AIの指摘とそれへの対応も添える
• これらはDay 3のペルソナ定義の入力になります。チーム全員が参照できる場所に保存してください

• 時間配分が命です。進行役はステップごとの終了時刻を最初に宣言しましょう（例: 「12:00までにふるい分け完了」）
• 2案で完全に意見が割れたら、「両方をAIに説明して指摘をもらってから再投票」が有効です。情報が増えると合意しやすくなります
• 決定が早く終わったチームは、AIディスカッションを2巡（指摘→修正→再指摘）させると、テーマが格段に強くなります
• 「どうしても決めきれない」も学びです。その場合は仮決定とし、「Day 3の午前中にペルソナを描いてみて違和感があれば見直す」と期限付きで前に進みましょう。ただし変更時は「事前に報告して調整する」ルールを忘れずに
• AIの指摘が厳しすぎて落ち込んだら、「このテーマの良い点と可能性も挙げて」と聞きましょう。バランスの取れた判断材料になります

今回学んだことを一言でまとめると、**「テーマ決定とは、合意形成ルールという道具を実戦で使い、AIの反論で決定を鍛えるプロセスである」**ということです。

• 手順: 前提条件チェック→2軸評価→合意形成→言語化→AIレビュー
• 課題（問い）とテーマ（答えの方向性）を書き分ける
• AIの指摘は材料。最終決定権はチームにある

これでDay 2の成果物「取り組む課題」「開発テーマ」が揃いました。次回Day 3は、このテーマで価値を届ける相手、ペルソナを定義し、カスタマージャーニーマップを作ります。「誰の顔を思い浮かべて作るのか」が、いよいよ具体的な人物像になります。

以下の問いに答えられるか確認してみましょう：

• 自チームの「取り組む課題」と「開発テーマ」を、1分で説明できますか？
• 決定の際、チーム計画書の合意形成ルールをどう使いましたか？
• AIからどんな弱点を指摘され、チームはどう対応しましたか？
• 「取り組む課題」と「開発テーマ」の違いを説明できますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: アビリーンのパラドックス・グループシンクの解説記事、ドット投票（Dot Voting）の手法解説
• 発展課題: 今日決めたテーマの「類似サービス」を帰宅後に1つ調べてみましょう。「それでも自分たちのテーマが解く課題は残っている」と説明できれば、テーマはさらに強くなります

このセクションは、受講者が理解を深めることをサポートする参考情報です。