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

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

前のセッションでは、個人でAIと対話しながらアイデアを出しました。早かったですか？
1人とAIだけで進めるのは速いし、気楽です。では、なぜわざわざチームでやるのでしょうか。

「人数が多いほうがいいから」というのは説明になっていません。3人寄れば文殊の知恵——という言葉もありますが、3人寄って何も決まらない会議もたくさんあります。チーム開発が機能するためには理由と仕組みがあります。

このセッションでは、「なぜチームか」を4つの理由で整理し、「どう分担するか」をMECEという考え方で学びます。次のセッションでチーム計画書を作る前提を作ります。

1人で開発した方が早い場面もあります。それでも会社ではチーム開発が標準です。理由は4つに整理できます。

たとえばスマホアプリ1本でも、画面が10あれば1人では数ヶ月かかります。10人なら数週間で出せます。作業を分割して並列処理することで、1人では絶対に届かない規模に届きます。

人にはそれぞれ得意・不得意があります。デザインが得意な人、データベースが得意な人、文章が得意な人。得意を持ち寄れば、1人では作れないものが作れます。逆に、不得意なことを1人で抱え込むと品質が落ちます。

チームの中で他の人のやり方を見ると、自分の引き出しが増えます。「あ、あの人はあの順番で進めるのか」「あの人のコードの書き方は読みやすい」。1人では身につかないスキルが、見て・教えて・教わって身につきます。

1人で進めるプロジェクトは、その人が休んだ瞬間に止まります。チームなら誰かが体調を崩しても、他のメンバーが引き継げます。プロジェクトが止まらない仕組みを作れるのが、チームの強さです。

具体例で確認してみましょう。
1人で家を建てるとどうなるか想像してください。基礎・骨組み・配線・水道・内装すべて1人。何ヶ月、いや何年かかります。実際には大工・電気工・水道工・内装工が役割分担して短期間で完成させます。これがチーム開発の原型です。

ただし「人を集めただけ」では機能しません。それぞれが何を担当するかが決まっていないと、配線が終わる前に内装が始まって壁を剥がし直す——なんてことになります。

「人数が増えれば速くなる」は半分嘘です。コミュニケーションコストは人数の二乗で増えると言われます。3人なら3組の会話、5人なら10組、10人なら45組です。だから10人を集めれば10倍速くなるわけではなく、コミュニケーションの仕組みがないと、むしろ遅くなります。

「人月の神話」という本があります。1975年にIBMのフレデリック・ブルックスが書いた、ソフトウェア開発の古典です。彼はこう言いました——「遅れているプロジェクトに人を追加すると、さらに遅れる」（ブルックスの法則）。
新しい人に説明する時間、既存メンバーとの調整時間、コードベースの引き継ぎ時間が全部コストになるからです。50年前の本ですが、今でもまったく古びていません。

個人で動くときと、チームで動くときでは、判断軸が変わります。

ここで一番大切なのが、最後の**「困ったら早く共有する」**です。個人作業の癖で「自分で何とかしよう」と抱え込むと、チーム全体が止まります。助けを求めることはサボりではなく、チームのスピードを守る行為です。

人数が増えたら、「誰が何をやるか」を決める必要があります。このときの考え方が**MECE（ミーシー）**です。

MECEは「Mutually Exclusive, Collectively Exhaustive」の略で、日本語では「重複なく・漏れなく」と言います。

ポイントは2つ。

• 重複なく（Mutually Exclusive）: 同じ作業を2人が担当しない
• 漏れなく（Collectively Exhaustive）: 誰も担当しない作業を残さない

良い例（MECE）:

悪い例（重複あり・漏れあり）:

役割分担表を書いたら、**「重複していないか」「漏れがないか」**の2点を必ずチェックします。漏れの典型は「進捗管理」「ドキュメント整備」「外部とのやり取り」です。誰かが拾わないと、最後にバタつきます。

本研修では、次のような役割をチーム内で分担します。

ただしこれはあくまで例です。チームの人数や得意分野で変えてOKです。1人が複数役割を兼任することもあります。たとえば4人チームなら「PM兼リーダ」「サブリーダ兼デザイン」「開発2名」のような分け方もあります。

大切なのは**「全員がいずれかの役割を持ち、すべての責任が誰かに割り振られている」**こと。これがMECEです。

役割を決めただけでは動きません。いつ・どこで・何を話すかを決めるのがコミュニケーション計画です。最低3種類を計画しておくと安心です。

たとえば本研修では、実装期間（Day 11-17）に朝会（10分）→実装→終会（20分）というリズムを採用します。これが会議体です。

スクラム開発というアジャイル手法では、デイリースクラムという15分の朝会を毎日行います。話すことは3つだけ:「昨日やったこと」「今日やること」「困っていること」。世界中の開発チームが採用しているシンプルなフォーマットです。
シンプルだからこそ続きます。「30分の会議で全部議論する」より「15分で要点だけ共有する」方が、実は組織として強いのです。

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

• 「MECEな役割分担を、私たちのチーム（5人想定）で作るとしたらどういう例になる？」
• 「『困ったら早く共有する』が実践できないチームの典型的な失敗例を3つ教えて」
• 「ブルックスの法則を、料理のたとえで説明して」
• 「コミュニケーション計画で『振り返り』を入れるメリットは？入れないとどうなる？」

このセッションでは、4つのことを学びました。

1. なぜチームか: 規模対応・能力補完・相互学習・継続性の4つ
2. 個人とチームの視点の違い: 特に「困ったら早く共有する」が肝
3. MECEな役割分担: 重複なく・漏れなく
4. コミュニケーション計画: 会議体・レビュー・振り返りの3点セット

次のセッションでは、チーム計画書を実際に作ります。今日学んだ「役割分担」「コミュニケーション計画」「合意形成ルール」をチームで決めて文書化します。今日の知識を話す＆行うで使う場です。

• チーム開発の4つの理由を順番に言えますか？
• MECEとは何の略で、どういう意味ですか？
• 自分は次のセッションでどの役割を担当したいですか？それを志望する理由は？
• コミュニケーション計画の3要素（会議体・レビュー・振り返り）を、それぞれ何のためにやるか説明できますか？

• 参考リンク

  • フレデリック・ブルックス『人月の神話』
  • 『SCRUM BOOT CAMP THE BOOK』（スクラムの入門書）
• 発展課題

  • 自分が過去に参加した「うまくいったチーム」と「うまくいかなかったチーム」をMECEとコミュニケーションの観点で比較する
  • AIに「もし私がチームのPMをやるとしたら、最初の1週間でやるべきことを10個挙げて」と聞く