チーム開発の原則〜役割分担とコミュニケーション計画

• 日程: Day 1 / セッション 3
• 時間: [11:10-11:40]
• 形式: 座学
• ゴール: チーム開発が必要な理由を4つ（規模対応・能力補完・相互学習・継続性）挙げ、MECEな役割分担の例を説明できる
• 学習形式: 対話型解説、AIディスカッション

さきほどのセッション2では、1人とAIでアイデアを出しました。「AIがいれば1人でも開発できるのでは？」と思った人もいるかもしれません。

そこで問いかけです。
「文化祭の出し物を、たった1人で準備したらどうなると思いますか？」

企画を考え、買い出しに行き、装飾を作り、当日の接客もして、お金の管理もする……。想像しただけで大変です。

• 時間が足りない（量の問題）
• 装飾は得意でも会計は苦手（質の問題）
• 風邪をひいたら全部止まる（継続性の問題）

仕事のシステム開発はこれよりはるかに大きく、長く続きます。だから世の中のソフトウェアは、ほぼすべてチームで開発されています。

このセッションでは「なぜチームなのか」を4つの理由に整理し、チームをうまく動かす2つの道具——役割分担（MECE）とコミュニケーション計画——を学びます。次のセッション4で実際にチーム計画書を作るための準備です。

チーム開発が必要な理由は、次の4つにパターン化できます。

ここで考えてみてください。
「優秀な人が10人集まれば、必ず1人の10倍の成果が出るでしょうか？」

出ません。連絡ミスで同じ作業を2人がやってしまったり、誰もやらない作業が放置されたりすると、10人いても5人分の成果しか出ないことがあります。つまりチームは自動的には機能しません。

ここで必要になるのが視点の切り替えです。

• 個人の視点: 「自分のタスクが終わればOK」
• チームの視点: 「チーム全体の成果物が完成してはじめてOK」

サッカーに例えると、フォワードが「自分はシュートを打ったから仕事した」と言っても、チームが負けたら意味がありません。自分の作業がチームの成果にどうつながるかを常に意識する。これが「個人の視点からチームの視点へ」の意味です。

• 4つの理由は「規模対応・能力補完・相互学習・継続性」とセットで覚える
• チームの力は人数に比例しない。仕組み（役割分担と計画）があってはじめて人数以上の力が出る
• よくある間違い: 「仲が良ければチームはうまくいく」。仲の良さは大事だが、それだけでは作業の重複や漏れは防げない

「人を増やせば早く終わる」が常に成り立たないことは、ソフトウェア工学の古典『人月の神話』（1975年、フレデリック・ブルックス著）で有名になりました。ブルックスは「遅れているプロジェクトに人を追加すると、さらに遅れる」と喝破しました。新人への説明や連絡経路の増加で、かえって時間を食うからです。彼の名言が「産むのに9か月かかる赤ちゃんは、妊婦を9人集めても1か月では産まれない」。チームは「人数」ではなく「分担と連携の設計」で強くなるのです。

チームの力を引き出す1つめの道具が役割分担です。キーワードはMECE（ミーシー）。

• Mutually Exclusive: 互いに重複なく
• Collectively Exhaustive: 全体として漏れなく

ピザの切り分けに例えると、MECEな切り方は「切れ目が重ならず、食べ残しの部分もない」状態です。

役割分担で確認するのは2つだけです。

• 重複: 同じ仕事を2人が担当していないか？ → 二重作業・お見合い・主導権争いの元
• 漏れ: 誰も担当していない仕事がないか？ → 「誰かがやると思ってた」事故の元

この研修での役割分担の例を見てみましょう。

具体例と非具体例で確認しましょう。「進捗管理はPM、画面デザインはデザイン担当」はMECEに該当します。一方、「AさんとBさんがなんとなく両方ともデザインを見る」は重複があり、「テスト担当を誰も決めていない」は漏れがあるので、MECEに該当しません。なぜなら、責任の所在が曖昧になり、問題が起きたときに誰も動けないからです。

ここで少し考えてみてください。
「5人チームで役割が5つ。1人1役で完璧にMECE。でも開発担当が1人だけだと、何が起きるでしょうか？」

その人が休むと実装が止まります（継続性の喪失）。役割は「責任の所在」を決めるものであって、「その人しか作業してはいけない」という意味ではありません。責任者は1人、作業はみんなで。これが実務的なバランスです。

• MECEのチェックは「重複はないか？」「漏れはないか？」の2つの問いだけ
• 役割＝責任の所在。作業の独占ではない
• つまずきやすい点: 役割を曖昧なまま「みんなで頑張ろう」とする。最初に決めておくほど、後の揉め事が減る

MECEという言葉を広めたのは、経営コンサルティング会社マッキンゼーです。1960年代に同社のバーバラ・ミントが報告書の論理構成法として体系化しました。実は身近なところにもMECEはあります。たとえば信号機の「青・黄・赤」。同時に2色は点きませんし（重複なし）、どの状態にも対応する色があります（漏れなし）。世の中のうまく回っている仕組みを「これはMECEか？」と見る癖をつけると、設計力が一気に伸びます。

2つめの道具がコミュニケーション計画です。「いつ・誰が・何のために集まり、どう情報を共有するか」を事前に決めておくことです。

決めておく主な要素は3つです。

• 会議体: 定例の集まり。例: 朝会（10分、今日の予定共有）、終会（20分、進捗報告・課題共有）
• レビュー: 成果物を相互チェックする場。例: 設計書の読み合わせ、コードレビュー
• 振り返り: 仕事のやり方自体を見直す場。例: 各フェーズの終わりにKPTで振り返る

「必要になったら話せばいい」ではダメなのでしょうか？

ダメな理由を、健康診断に例えてみましょう。体調が悪くなってから病院に行くのが「問題が起きてからの相談」。年1回の健康診断が「定例の会議体」です。定例があるからこそ、自覚症状のない問題を早期発見できます。「ちょっと遅れ気味だけど、わざわざ言うほどでもないか…」という小さな遅れは、報告の場がないと1週間後に大問題として爆発します。

この研修でもDay 11以降、毎日「朝会→実装→終会」のリズムで進みます。これは実際の開発現場（アジャイル開発のデイリースクラム等）と同じ習慣です。

そして、コミュニケーション計画とセットで決めるのが合意形成ルールです。

• 例: 「意見が割れたら、まず全員が1分ずつ意見を言い、最後は多数決」
• 例: 「技術の選定はPMではなく開発担当の意見を優先する」

さらに本講義の最重要ルールを思い出してください。

合意した内容に変更が生じる場合には、事前に報告して調整する

「黙って変える」が、チームの信頼を壊す最大の原因です。変更そのものは悪ではありません。報告なしの変更が悪なのです。

• コミュニケーションは「自然発生」に任せず「計画」する
• 会議体・レビュー・振り返りの3点セットで決める
• よくある間違い: 会議を増やしすぎる。短く・定期的に・目的を明確に、が原則

立ったまま行う短い朝会「スタンドアップミーティング」には、面白い由来があります。座って会議をすると人間はつい長話をしてしまうので、わざと立たせて足を疲れさせ、会議を短くするという発想です。ある調査では、立って行う会議は座って行う会議より約34%短く、意思決定の質は変わらなかったという結果も出ています。人間の集中力をハックする、なかなかずる賢い知恵です。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「MECEな分け方とMECEでない分け方の例を、コンビニの商品分類で説明して」
• 「5人の新人チームで開発するとき、起こりがちなコミュニケーションの失敗を5つ挙げて」
• 「朝会で話すべきことと、話すべきでないことの例を教えて」

AIディスカッションのお題もあります。次のプロンプトで議論してみましょう：

私は新入社員5人のチームで22日間のシステム開発研修に取り組みます。
役割分担を「PM・リーダ・サブリーダ・デザイン担当・開発担当」で考えています。
この分担に重複や漏れ（MECEの観点での問題）があれば指摘してください。
また、新人チームならではの注意点も教えてください。

今回学んだことを一言でまとめると、**「チームは自動的には機能しない。MECEな役割分担とコミュニケーション計画という設計図があってはじめて、1人では出せない力が出る」**です。

• チームが必要な4つの理由: 規模対応・能力補完・相互学習・継続性
• 役割分担はMECE（重複なく・漏れなく）。役割＝責任の所在
• コミュニケーションは計画する: 会議体・レビュー・振り返り
• 合意した内容の変更は、事前に報告して調整する

次回（セッション4）は、いよいよこの知識を使って、自分たちのチーム計画書を作ります。今日学んだ言葉（MECE・会議体・合意形成ルール）がすべて登場します。

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

• チーム開発が必要な4つの理由を挙げられますか？
• MECEとは何の略で、役割分担では何をチェックしますか？
• コミュニケーション計画で決める3つの要素（会議体・レビュー・振り返り）の違いを説明できますか？
• 「個人の視点からチームの視点へ」とは、どういう行動の変化ですか？

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

• 参考リンク: 『人月の神話』（フレデリック・ブルックス著）— チーム開発の古典。「ブルックスの法則」だけでも調べてみる価値あり
• 発展課題: 自分の過去のグループ活動（部活・文化祭・ゼミ等）を1つ思い出し、「重複・漏れ・報告漏れ」がなかったかをAIと一緒に振り返ってみましょう

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