1人かチームか。スキル、依存関係、リスクからプロジェクトの最小構成を決める方法

研究は、「小さいチームは常に優れている」 や 「大きいチームは常に多く成果を出す」 といった単純なルールを支持していません。

2023年のメタ分析では、208件の独立した効果と21,435チームが対象となり、チーム規模と課題成果の全体的な関係はほぼゼロでした。一方で、文脈によるばらつきは非常に大きく、課題の複雑さや調整要求などによってチーム規模の意味が変わることが示されました。 [4]

複雑な危機地図作成課題の実験でも、大きいチームには利点と費用の両方がありました。チームが大きくなると協力は増えましたが、個人の努力の配分も変化しました。その特定の実験では最大チームが同人数の独立作業者を上回りましたが、これはすべての仕事に使える普遍的な処方ではありません。 [5]

実務上の結論は単純です。人数は魔法の数字ではなく、仕事の性質から決めるべきです。

2020年のScrum Guideは、Scrum Teamを小さく、必要なスキルを横断的に持ち、自ら仕事を管理するチームとして説明しています。また通常は10人以下としています。 [3]

これは Scrumの文脈では 有用な指針ですが、あらゆるプロジェクト、サービス、業界、実施形態に共通する法則ではありません。

建設プロジェクト、マーケティング施策、セキュリティ評価、金融システム、小規模な情報サイトでは必要条件が大きく異なります。1つの数字をそのまま横展開すべきではありません。

英国のService Standardは、デジタルサービスのチームが多分野のスキルを持ち、必要な専門性にアクセスできることを求めています。また、その段階で何を達成する必要があるかに応じてチームを構成すべきだとしています。 [1]

別のGOV.UKガイドでは、サービス構築の段階によってチーム規模と必要な役割が変わると説明しています。 [2]

実践的な原則は次です。

まず仕事と責任を整理し、次に必要スキルを定め、最後に具体的な人へ割り当てる。

範囲が曖昧なままでは、適切なチーム構成は決められません。

最低限、次を明確にします。

• 何を成果として作るのか
• 何が範囲内か
• 何が範囲外か
• 重要な品質要件
• 時間と予算の制約
• 誰が成果を受け入れるのか
• チームは納品だけか、運用まで担当するのか

「アプリを作る」 プロジェクトと、「アプリを設計、構築、安全化、公開し、1年間運用する」 プロジェクトでは、必要な仕事のカバーがまったく違います。

すぐに職種名を並べるのではなく、実際に必要な仕事の種類を列挙します。

デジタルサービスなら、たとえば:

• 利用者ニーズの把握
• 解決策の設計
• 利用者に見える部分の構築
• サーバー側ロジックと連携
• テスト
• セキュリティ
• アクセシビリティ
• 公開と運用
• 範囲と意思決定の調整

別の種類のプロジェクトなら一覧も異なります。

GOV.UKは、デジタルサービスを構築し運用するチームには、利用者ニーズ、設計、構築、テスト、セキュリティ、公開、運用など幅広いスキルが必要だとしています。 [2]

必要なスキルすべてに、常勤の担当者が必要とは限りません。

各領域を次のように分類します。

常時 - 定期的に必要で、日々の判断に直接影響する。
定期 - 特定の段階や確認点で必要になる。
外部利用 - 応答時間と責任が十分明確なら、別の人やチームから提供できる。

GOV.UKは、専門家が常任メンバーでなくても、必要な専門知識へチームがアクセスできる形を明確に認めています。 [1]

これにより、重要な専門性を失わずに不要な人員増加を避けられることがあります。

2人合わせて必要スキルがすべて揃っていても、全作業が一本の狭い依存関係に並んでいるなら、良い構成とは限りません。

確認する点:

• 並行して進められる作業
• 他の作業を待つ必要がある作業
• 後続を止める判断を誰が行うか
• 外部のどのチームや供給者に依存しているか
• 1人の不在で複数領域が同時に止まる場所

GOV.UKは、他チームへの依存関係を管理することをデジタルサービス構築に必要な能力の一つに挙げています。 [2]

複数チームが同じサービスに関わる場合は、計画や進捗をチーム間で調整する追加の必要も生まれます。 [8]

必要な専門性の中には、製品機能の一覧には現れないものがあります。しかし欠けると大きな費用につながることがあります。

プロジェクトによっては:

• セキュリティ
• データ保護
• アクセシビリティ
• 法的または業界要件
• 信頼性
• データ移行
• 重要システムとの連携
• チームが未経験の技術

などです。

GOV.UKは、必要に応じて専門知識へアクセスできるようにすること、さらに現在の段階で最もリスクの高い仮定もチーム構成へ反映することを求めています。 [1]

すべてのリスクごとに常勤職を置くという意味ではありません。能力のある人が明確な責任を持ち、意思決定へ実際に影響できる必要があるという意味です。

1人が設計、開発、テスト、公開をすべて理解していても、それらを同時に、どんな期限でも実行できるわけではありません。

PMIのリソース計画資料は、スキル、利用可能性、費用、経験をプロジェクト需要に合わせる重要性を示しています。 [7]

各人について確認します。

• 実際に使える時間
• 注意を奪い合う作業
• 並行実施が必要な仕事
• 多種類の仕事を非現実的に切り替える予定になっていないか
• 公開後も運用担当が必要か

スキルが揃っていても時間が足りなければ、プロジェクトを十分にカバーしたことにはなりません。

最小構成では継続性も考えます。

確認すること:

• 重要人物が不在ならどうなるか
• 重要部分を理解しているのが1人だけではないか
• 判断や知識が記録されているか
• 他の人が重要作業を引き継げるか
• 不在時にプロジェクトを安全に止められるか

すべての小規模プロジェクトに完全な代替要員が必要なわけではありません。短期で低リスクなら、そのリスクを意識して受け入れる判断もあり得ます。

重要性の高いプロジェクトでは、同じ1人依存が許容できないことがあります。

役割名ごとに別の人を置く必要はありません。

1人が本当に必要なスキルを持ち、十分な稼働量があり、許容できないリスクを生まないなら、複数領域を責任を持って担当できます。

小規模プロジェクトなら、1人がインターフェース設計と実装を兼ねることがあります。別のプロジェクトでは、事業分析と範囲調整を兼ねることもあります。

「誰かがやらなければならない」 という理由だけで責任をまとめてはいけません。両方を必要水準で実行でき、時間も十分にある場合にのみ合理的です。

次の条件が同時に満たされるなら、1人が合理的な構成になることがあります。

• 範囲が小さく明確
• 必要スキルが本人の実力に収まる
• 大量の並行作業が不要
• 外部依存が少ない
• リスクが許容範囲
• 期限が実際の稼働量に合う
• 代替要員がいないリスクを意識して受け入れている

小さな情報資料、簡単な分析、単発相談、慣れた環境での限定的な導入などが例です。

ただし具体的な範囲が決定要因です。「小さなプロジェクト」 という名称だけでは判断できません。

次の条件が複数あるほど、チーム構成の必要性が高まります。

• 必要スキルが1人には広すぎる
• 多くの仕事を並行実施する必要がある
• 期限が現実的な順次実施より短い
• 依存関係や接点が多い
• リスクに独立した専門知識が必要
• 構築と運用を同時に行う必要がある
• 1人がプロジェクト全体の重大な単一依存になる
• 責任が異なる複数分野にまたがる

こうした場合、単に人数を増やすより、不足している能力を追加することが重要です。

人を増やせば知識の幅と潜在的な稼働量は増えますが、依存関係、作業引き継ぎ、判断調整の必要も増えることがあります。

Journal of Systems and Softwareに掲載されたソフトウェアプロジェクトの研究では、チーム規模、生産性、労力、時間の関係は複雑で、直感的な予想と常に一致するわけではないことが示されました。 [6]

チーム規模のメタ分析も、結果が課題の文脈とチーム内プロセスの費用に依存すると示しています。 [4]

したがって問いは 「何人追加できるか」 ではなく、「次の1人は調整費用を増やす以上に、実際の制約を取り除くか」 です。

重要な能力すべてを毎日チーム内に置く必要はありません。

常任参加 が適しているのは、定期的に判断する人、他領域との依存が多い仕事、素早い対応が必要な場合です。

定期支援 で足りるのは、レビュー、相談、リスク評価、専門的な受け入れなど特定時点だけ専門性が必要な場合です。

ただし、利用可能性は実態が必要です。明確にすること:

• 誰が責任者か
• いつ対応可能か
• 想定応答時間
• どの判断ができるか
• 問題を見つけたらどうするか

責任が定義されていない専門家への名目上のアクセスは、組織図では良く見えても実プロジェクトでは機能しないことがあります。

オンライン予約システムを公開するとします。

案A: アイデア検証用の簡単なプロトタイプ
範囲は限定され、決済や特に機微なデータはなく、小人数の利用者で流れを検証することが目的です。幅広いスキルを持つ1人が設計と実装を担当し、必要に応じて定期的な助言を得る形も考えられます。

案B: アカウント、決済、連携を含む公開サービス
専門性、テスト、リスク、依存関係、並行作業が増え、複数人チームの必要性が高くなります。

案C: 常時稼働し、問題へ迅速に対応するサービス
構築に加えて運用、監視、障害対応、知識継続が必要です。公開に足りる構成でも持続的運用には足りない場合があります。

同じ一般的な製品種別でも、範囲、リスク、運用モデルが違えば必要なチームも変わります。

1. 必要な仕事ではなく、既成の職種一覧から始める。

2. 役割ごとに別の人が必要だと思い込む。

3. スキルだけを見て利用可能な時間を無視する。

4. 依存関係やボトルネックを解消せず人を追加する。

5. 見える機能を作らないという理由で、リスク対応スキルを省く。

6. リスクを意識して受け入れないまま複数の重要領域を1人に依存させる。

7. プロジェクト開始時の構成を最後まで固定だと考える。

GOV.UKは、サービス開発の段階に応じてチーム規模と役割が変わると明示しています。 [2]

公共サービス以外でも合理的な原則です。

• 初期は調査と問題定義を多く必要とすることがある
• 実装時は構築とテストの能力が重要になる
• 公開前はセキュリティ、品質、運用準備の比重が増えることがある
• 公開後は開発と運用のバランスが変わる

最小構成は段階と範囲によって決まり、プロジェクト全期間に固定された数字ではありません。

重要領域ごとに5項目を書きます。

作業領域 - 何を行うか。
スキル - どんな知識と能力が必要か。
責任 - 誰が判断し、成果に責任を持つか。
利用可能性 - 常時、定期、外部のどれか。
不在リスク - スキルや人が不在なら何が起きるか。

その後で具体的な人を割り当てます。

1人が複数行を担当するなら時間と依存関係を確認します。1行に複数人が必要なら、理由が稼働量、独立確認、並行作業のどれかを確認します。

1. 必須の作業領域すべてに責任者がいるか。
2. 重要責任すべてを適切な能力を持つ人が担当しているか。
3. 複数役割を持つ人に現実的に十分な時間があるか。
4. 現在の構成では支えられない並行作業が必要ではないか。
5. 他の人、チーム、供給者への主要依存を把握しているか。
6. 重要リスクに適切な専門知識へアクセスできるか。
7. 1人の不在で全体が止まらないか。
8. 範囲内なら、構築だけでなく公開と運用にも十分か。
9. 常任でなく定期利用できる能力を把握しているか。
10. 範囲や段階変更後に構成を再評価する時点を決めているか。

チーム設計は次の問いから始めるべきではありません。

「この種のプロジェクトには通常何人必要か」

より良い順序は:

成果 -> 仕事 -> スキル -> 依存関係 -> リスク -> 稼働量 -> 人.

この確認後に1人で本当にすべてカバーできるなら、1人が正しい選択になり得ます。

スキル、時間、独立確認、継続性、並行実施能力が不足するなら、人を追加するか、専門家へ確実にアクセスできるようにする必要があります。

目的は最小人数のチームではありません。必要なリスクと品質水準で成果を現実的に届けられる最小構成です。

[1] GOV.UK Service Standard - Have a multidisciplinary team
出典を開く

[2] GOV.UK Service Manual - Set up a service team at each phase
出典を開く

[3] The Scrum Guide, 2020 - Scrum Team
出典を開く

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
出典を開く

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
出典を開く

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
出典を開く

[7] Project Management Institute - Solving The Resource Puzzle
出典を開く

[8] GOV.UK Service Manual - Running more than one service team
出典を開く

方法論上の注記: 一部の出典はデジタル公共サービス、Scrum Team、プロジェクト管理、またはチームとソフトウェア開発の研究を扱っています。本ガイドでは各出典を、それが実際に支持する範囲だけで利用しています。7段階の最小構成方法はこれらの原則を編集上まとめたものであり、列挙した組織の正式な標準ではありません。