プロジェクトの遅れは増員で解消できる? 人を追加する前の確認点
二日分の作業を応援者へ渡せても、完成日は二日早くなるのでしょうか。説明や確認で中心担当者が止まれば、前倒しは小さくなることがあります。残る工程を十二日と置いた仮定から、検証と資料の支援を比べ、受入れと統合、応援を出す部署の負担まで考えます。
反対に、「遅れた案件への増員は逆効果だから」と応援を断り、切り離せる検証作業まで少人数で抱え込むのも、十分な判断とはいえません。必要なのは増員の賛否ではなく、応援者が終わらせる仕事と、そのために既存メンバーから取り上げる時間を、同じ工程で比較することです。
この記事の目次
十二日後の完成を、どの応援なら前へ動かせるか
同じ二日を短縮しても、完成日は動いたり動かなかったりする
システム更新の残工程を、営業日で考えてみる。仕様決定6日→データ検証4日→統合2日という順序があり、利用者向け資料は初日から別担当が8日で完成すると仮定する。公開には統合と資料の両方が必要で、途中の手戻り・休日差・外部承認はない。この条件では、12日の経路が8日の資料作成より遅く、最短の完成は12日後になる。
| 支援案 | 仕様→検証→統合 | 資料完成 | 全体の完成 |
|---|---|---|---|
| 変更なし | 6+4+2=12日 | 8日 | 12日後 |
| 資料だけを2日短縮 | 12日 | 6日 | 12日後 |
| 検証を2日へ、受入説明で仕様が1日延びる | 7+2+2=11日 | 8日 | 11日後 |
| 検証を2日へ、受入説明で仕様が2日延びる | 8+2+2=12日 | 8日 | 12日後 |
資料の短縮には、品質を確かめる余裕を増やす価値がある。しかし、今回の目的が公開日の回復なら、単独では達成しない。検証への応援も、二日分を速めたという説明だけでは足りず、同じ経路で受入負担を足すと、短縮は一日かゼロになる。総作業時間の差引と、完成日を決める経路を別々に読む必要がある。
実際には、仕様を決める人と資料を確認する人が同じなら、二つの経路は独立しない。先に誰がどの時間を使うかを組み直す。短縮が進むと別の経路が最長になることもあるため、一度見つけた遅れの原因へ人を足し続けない。更新した残工程で完成日を計算し直すところまでが、増員案の評価である。
渡す仕事と、受入れ・統合の負担を決める
増員案を「任せる仕事」まで分解する
以下は研究結果から直接算出した処方ではなく、ここまでの工程の比較を踏まえた編集上の提案です。増員の稟議には、人数だけでなく三つの仕事を書きます。
第一は、応援者が単独で完了まで運べる仕事です。入力、成果物、完了条件が決まっており、途中で中心メンバーに何度も判断を求めずに済むかを見ます。仕様が固まったテストの実施と、仕様そのものを決める作業では、同じ一人でも増やせる処理が違います。
第二は、受け入れるための仕事です。環境の準備、業務説明、権限の設定、質問対応、成果物のレビューを誰が担当するのか。最も遅れている設計者がすべてを引き受けるなら、その人の作業時間が減ることを計画に戻さなければなりません。
第三は、つなぎ直す仕事です。別々に完成した部品を統合し、整合を確認し、不具合を直す負担です。作業を分けた瞬間には見えなくても、納期直前に集まれば前倒し分を消します。担当を増やす案と、担当境界を増やす案は同じではありません。
同じ応援者でも、任せ方で判断が逆転する
例えば、システム更新が遅れているとします。以下は実在案件の成績ではなく、判断を比べるための仮想例です。残る仕事は、画面仕様の決定、移行データの検証、利用者向け資料の整備です。
検証用のデータと判定基準がそろい、応援者が結果を記録して引き渡せるなら、検証を任せる案に意味があります。既存担当者は仕様の決定に集中できます。ただし、検証結果を最終確認する人の空き時間も用意して初めて、仕事が前へ進みます。
一方、データの正解が決まっておらず、応援者が一件ごとに設計者へ問い合わせるなら、同じ検証要員の追加でも効果は変わります。先に代表的なデータを使って判定基準を決めるか、その判断ができる専門家を一時的に加える方が、検証人数の追加より有効な候補です。
さらに、検証を早く終えても外部連携先の準備が終わらず公開できないなら、その応援は納期の短縮には直結しません。品質の余裕を確保する価値は残り得ますが、目的を「公開日の回復」から「手戻りや残業の抑制」へ言い換えて評価する必要があります。
この例で選択を分けるのは応援者の熱意ではなく、作業を渡せる状態か、受け取った成果を次へ流せる状態かです。増員しない案を選ぶ場合も、何もしないのではなく、未決事項を減らす、納品範囲を絞る、受入担当の時間を確保するという別の対策が必要です。
人数の研究を、そのまま短縮日数にしない
人数と生産性の研究は、納期短縮の保証ではない
ソフトウェア開発には、遅れた案件へ人を加えるとさらに遅れる、というブルックスの法則が知られています。調整や習得の負担への警告ですが、あらゆる増員を禁じる実験結果として扱うべきではありません。
Scholtesらの研究は、58のオープンソース開発プロジェクトで、チーム規模と一人当たりの生産性に負の関係を報告しました。コードを共同で編集する関係にも着目しています。ただし、観察対象は公開開発の履歴です。日本企業の遅延案件で増員を無作為に割り当て、納期への影響を測った研究ではありません。研究者の公開ページ
ここでは二つの区別が必要です。一人当たりの作業量が下がっても、全員の合計が増えることはあります。また、コードの変更量が増えても、受入試験を終えた機能が増えるとは限りません。経営側が知りたいのは「人を何人動かしたか」ではなく、「利用できる状態になる日が変わるか」です。
Goteらは、同じような開発データから規模の効果について異なる結果が出る問題を検討しています。対象プロジェクトの選び方、生産性の測り方、共同作業の構造が分析を左右します。彼ら自身の分析は規模と個人生産性の負の関係を示しますが、だからこそ、単一の人数比率を自社の短縮率へ置き換えることはできません。論文本文
「チーム規模」の数え方も、企業の配置人数とは違う
Goteらの論文は、201の公開開発プロジェクトについて、42週間の区間内にコードを追加・修正・削除した人をチームの人数として数える。生産性には、コミット数だけでなくコードの変更を捉える八つの指標を使い、一人当たりへ換算している。第3節はこの定義を詳しく説明している。
したがって、この人数を企業の「専任で毎日働く人数」と同じにはできない。短い貢献をした人も入り、契約上の配置人数とは一致しない。コード変更の規模は、受入試験を終えた機能数とも別である。この違いを戻すと、研究から借りるべき問いは「何人までならよいか」より、作業の境界を増やしたときに、調整と完成がどう変わるかになる。
工程の順序を入れると、増員の評価はさらに変わる。米国GAOの2015年の工程評価ガイド・Best Practice 6、表6は、完成まで続く活動の経路と、資源の制約を確認する考え方を示す。増員や工程の重ね合わせにも費用・品質などの副作用があると説明している。管理指針であり、特定企業で何日短縮できるかを測った実験ではない。
応援元の約束も含めて、支援を続けるか確かめる
応援を出した部署で、別の遅延を作らない
増員案には、応援元で止まる仕事もあります。別案件の唯一の設計者を借りれば、目の前の案件は進んでも、次の納品が遅れるかもしれません。今回の案件で短縮できる日数だけを成果として数えると、遅延を移しただけの対策を選びやすくなります。
だからといって、応援元の仕事が少しでも遅れるなら異動できない、という意味ではありません。動かせない期限を守るために、後へ送れる仕事を明示して人を動かす選択はあります。その際は、どの約束を変えるかを両方の責任者が認識し、いつ戻すかまで決めます。これは先の開発研究が実証した配分ルールではなく、増員に伴う交換条件を隠さないための提案です。
比較するなら「増員あり」と「何も変えない」だけに限定せず、「応援者は周辺作業を担当」「機能を分けて先に渡す」も同じ残工程で見ます。人数を決めてから仕事を探すのではなく、完成を妨げる作業に対して人を選ぶ順序に変えます。
「即戦力」を使うなら、希少な判断を奪わない
経験者なら習得時間はゼロ、と考えることにも無理があります。同じ技術に詳しくても、その会社の例外処理や顧客との約束を知っているとは限りません。技術経験と案件の文脈への理解は分けて見ます。
応援の役割を、既存担当者と同じ仕事に限定する必要もありません。問い合わせを整理して重複を除く、試験環境を準備する、外部への確認を取りまとめる。こうした支援で、決定権を持つ担当者が判断に使える時間を取り戻せることがあります。これは研究が効果量を保証する方法ではなく、どの制約を解くかという計画上の選択です。
ただし、支援役が情報を抱え込み、確認窓口が一つ増えるだけなら逆効果になり得ます。誰へ何を渡せば終わりかを決め、支援を受ける人が必要な情報へ直接たどり着けるようにします。「調整役を置いた」という体制図だけでは、判断待ちは解消しません。
応援の生産分から、受入れと統合の時間を引く
応援者が10日間、一日6時間働き、説明12時間・日々の確認10時間・統合8時間を要する仮定なら、差引は60−12−10−8=30時間になる。品質と分業可能性を同じに置いた計算であり、残る遅れが外部承認ならその30時間でも待ちは短縮しない。応援元の未処理も含め、受け渡せる残作業から増員を判断する。
増員の成否を、残る工程で確かめる
開始後に見る対象は、応援者の稼働率だけではありません。受入済みの成果物が増えたか、既存担当者の説明・手直しが増えていないか、最後の統合や承認の待ちが長くなっていないかを、増員前の計画と突き合わせます。小さな作業単位で一度受け渡しを終えてから、任せる範囲を広げる案も考えられます。
期間や合格点を一律に決める根拠はありません。残る納期に対して、習得から受入れまでを試す余地がなければ、その増員を納期回復の主策として数えること自体が危うくなります。間に合わないと分かった後に、人数をさらに積み上げて約束を維持するのではなく、提供範囲や日付の変更を選択肢へ戻します。
増員を選ぶのは、独立して任せられる仕事があり、受入れと統合の負担を含めても、必要な完成を前へ動かせると説明できるときです。詰まりが未決事項や一人の判断にあるなら、人数の追加より、その判断を終わらせる支援へ変える。人を足す前に、何が終わるようになるのかを決めることが出発点です。