LASSIC Media らしくメディア
開発遅延で開発要員を途中参画させる前の注意点
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 途中参画を決める前に、SPIで遅れの大きさを、残コストで予算の余裕を数字にしておきます。
- 増員で日程は戻せても出来高あたりの費用は上がりやすいので、参画後はSPIとCPIを並べて見ます。
- 加わる人の作業はクリティカル・パスとの関係で決め、遅れの調整に受入テストの期間を削りません。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
開発が遅れているプロジェクトに、途中から開発要員を加えるべきか。人を増やせば取り戻せるという声がある一方で、加わった人の立ち上がりにかえって手を取られるのではないかという心配もあります。途中参画とは、すでに進んでいる開発に、工程の途中から新しいメンバーが加わることを指します。開発遅延の場面で途中参画を決めるときは、遅れの大きさ、増員で戻るものと戻らないもの、加わる人に任せる範囲を先に確かめておく必要があります。
本記事では、開発の現場を預かるマネージャーに向けて、デジタル庁の「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」が示す進捗管理の手法（EVM）と、調達やテストの注意点をもとに、途中参画を決める前と後に確かめることを整理します。
目次
途中参画で取り戻せるもの
デジタル庁の「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」は、府省の情報システム担当者に向けて、標準ガイドラインの進め方を事例とともに説明した資料です。設計・開発の章では、進み具合を数字で見る方法としてEVM（出来高で進捗を測る管理の手法）を紹介しています。
その進捗状況表の解説には、スケジュール効率指数（SPI）が1を下回っているときは、手順の見直しによるコスト効率の向上や、人員の増加による投入コストの増加によって遅延を回復できる可能性がある、と書かれています。続けて、人員を増やした場合は「コスト効率の低下が起きることが多い」とも述べています。*1
つまり開発要員の途中参画は、日程の遅れを取り戻す手段にはなりえますが、出来上がった量あたりの費用は上がりやすい打ち手です。守りたいのが期日なのか予算なのかで、同じ増員でも評価は変わります。社内の開発でも、この前提を関係者でそろえてから人を加えるかどうかを話し合うと、あとで「増やしたのに効果がない」という食い違いが起きにくくなります。
ガイドブックが挙げているもう一つの道は、手順の見直しです。開発遅延への手当てとして途中参画だけを検討するのではなく、手順の見直し、範囲や期日の調整と並べて比べられる形にしておきます。そのための材料が、次に説明するSPIとCPIの数字です。
遅れの大きさをSPIで測る
EVMでは、WBS（作業を細かく分けた一覧）の各作業に、計画時に見積もった出来高（PV）を割り当てます。進捗を確かめる時点で完了した作業の出来高がEV、その作業に実際に投じたコストがACです。ガイドブックはこの3つを使って、次の指標を月ごとにまとめる様式を示しています。*1
| 指標 | 求め方 | 読み方 |
|---|---|---|
| スケジュール効率指数（SPI） | 累計のEV÷累計のPV | 1を下回るとスケジュールが遅れている |
| コスト効率指数（CPI） | 累計のEV÷累計のAC | 1を下回ると作業の効率が下がっている |
| 予測総コスト（EAC） | 今の差が続くなら、計画総コスト÷CPI | 計画総コストを超えれば、計画より多いコストで終わる見込み |
| 残コスト（ETC） | EAC−AC | 完了までに使えるコストを超えれば、完了の遅れが見込まれる |
たとえば、今月末までに100の出来高を終える計画で、実際に終わったのが80なら、SPIは0.8です（数字は説明のための仮のもの）。遅れを「2週間くらい」といった感覚ではなく、計画に対してどれだけ進んでいないかで表せるので、途中参画で取り戻す量の見当がつきます。
あわせて見ておきたいのが残コストです。途中参画の人を加えれば、その分だけ投入するコストが増えます。残コストがすでに使えるコストを超えているなら、人を加える前に、範囲や期日の見直しを関係者と話し合う段階にあると考えられます。ガイドブックも、ある時点でCPIが1を下回っている場合は、手順や効率を改善しない限り、予定コスト内で終えるのは難しいことが多いとしています。*1
途中参画のあとにCPIを見る
ガイドブックには、SPIとCPIの推移をグラフにした記載例があります。7月1日に作業が始まり、9月3日や9月14日ごろにはSPIもCPIも1を下回りました。10月1日の段階ではSPIが1に戻り、日程は計画に追いつきましたが、CPIはさらに悪くなっています。ガイドブックはこの動きを、当初の想定以上に要員を投入したのではないかと読み取れる、と説明しています。*1
途中参画のあとに日程の数字だけを追っていると、この例のように遅れが解消したように見えて、費用の側の悪化を見落とします。参画を決めるときに、SPIをいつまでにどこまで戻すのか、CPIはどこまでの低下なら受け入れるのかを先に決めておき、月ごとに両方を並べて確かめるのがよいでしょう。
加わった直後は、説明や開発環境の準備に既存のメンバーの時間も使われます。そのため、投入したコストが先に増え、出来高は少し遅れて伸びてくることが考えられます。参画から最初の数週間のCPIだけで成否を決めず、何週目の時点で判断するかも、あらかじめ決めておくと迷いが減ります。
数字が実態とずれる落とし穴
SPIとCPIは、元になる進捗の数字が正しくなければ役に立ちません。ガイドブックは、定例会などで「進捗率が90%で止まっている作業が大量にある」という状況がよくあり、多くの場合は進捗率の定義があいまいなことが原因だと指摘しています。進捗率は、定量的に判断できる基準を前もって決めるよう求めています。*1
さらにガイドブックは、計画に描いたWBSに抜け漏れがあったり、潜在的な課題を見過ごしたりしていれば、EVMの上では問題がなさそうなプロジェクトでも、ある日突然進まなくなることがあると述べています。業務の関係者との調整や合意が不十分なら、開発の終盤に手戻りが発生するおそれもあるとしています。*1
この2つは、途中参画では縮みにくい遅れです。WBSに載っていない作業が後から見つかったのなら、まず必要なのは作業の洗い出しです。関係者の合意が取れていないなら、人を加えても決まらない仕様を待つ人が増えるだけになります。途中参画を決める前に、遅れの中身がこの2つに当たらないかを確かめておきます。
任せる作業はクリティカル・パスで分ける
途中参画の人にどの作業を任せるかを考えるときの手がかりが、クリティカル・パスです。ガイドブックは、クリティカル・パスを作業の最長経路と説明し、この経路に必要な期間がプロジェクトの最短の所要期間になるため、経路上の作業が遅れるとプロジェクト全体の期間に影響すると注意を促しています。*1
日程を縮めるには、最長経路の上にある作業を短くしなければなりません。一方で、その作業は前後の作業とのつながりが強く、加わったばかりの人がすぐに担うのは難しいことが少なくありません。任せ方は、次のように分けて比べると決めやすくなります。
| 任せ方 | ねらい | 気をつけること |
|---|---|---|
| 最長経路の外の作業を任せる | 既存のメンバーを最長経路の作業に集中させる | 任せた作業が最長経路に変わらないよう、作業の順番を見直す |
| 最長経路の作業のうち、分けられる部分を任せる | 経路そのものを短くする | 分けた部分の受け渡しの形と、終わったと言える状態を先に決める |
| 最長経路の作業を丸ごと任せる | 経験のある人に担ってもらう | 立ち上がりの期間がそのまま全体の遅れに加わる |
ガイドブックは、関係者の間で誰が何を実施するかという役割分担を決めて合意することがとても大切だとし、ほかのシステムとの連携仕様を誰が定めるのか、テストを誰が主導するのかが問題になりやすいと述べています。*1途中参画の人の担当も、どこからどこまでかを書いて、既存のメンバーと合意しておきます。
求める経験は役割ごとに決める
加わる人に何を求めるかも、途中参画の早さを左右します。ガイドブックの調達の章には、体制上のすべての要員に一律に資格の保有を求めたために見積りが高額になった事例が紹介されています。遂行責任者やチームリーダに適切な資格を求めていれば、作業の担当者には必ずしも資格を求める必要はなく、役割に応じた要件を定めることが必要だとしています。*1
同じ箇所では、過度な資格要件を設けると、資格は持っていないが経験の豊富な事業者が応札できなくなる可能性があるとも指摘しています。急いで人を加えたい場面ほど条件を厚くしがちですが、全員に同じ条件をかけると候補が狭まり、探す時間が延びて遅れが広がるおそれがあります。役割ごとに「必須」と「あれば望ましい」を分けて書き出しておくと、候補を比べやすくなります。
ガイドブックは、発注者との一元的な窓口となる役割が置かれていないと、やり取りが煩雑になるおそれがあるとも述べています。途中参画の人が複数になるときは、作業の担当とは別に、質問や報告を受ける窓口を誰にするかも決めておきます。
社外から加わるときの失敗例
開発要員を社外から途中参画させる場面では、別の会社を経由して人が加わることもあります。ガイドブックは、再委託にまつわる失敗事例も少なくないとして、次のような例を挙げています。*1右の列は、それを途中参画の前に確かめる事柄に置き換えた、この記事の整理です。
| ガイドブックの失敗例 | 途中参画の前に確かめること |
|---|---|
| 実際に作業する会社が必要なスキルを十分に持たず、品質の低下や遅延を招いた | 提案を受けた内容と、実際に作業する人の経験が合っているか |
| 会社どうしの関係の悪化などで要員が引き上げられ、作業が中断した | 交代が起きたときの連絡と、後任を立てるまでの扱い |
| 中心になる人が離脱し、その人だけが持つ情報が引き継がれておらず代わりが務まらなかった | 作業の記録をどこに残すか、特定の人に情報を集めない仕組み |
| 利用者との調整を丸投げし、要件や仕様の変更を把握できず、工数超過や遅延に発展した | 仕様の変更を誰がどの場で伝えるか |
| 情報が抱え込まれ、同じ説明を利用者に何度も求めて関係が悪化した | 加わる人が直接読める資料と、質問の受け口 |
ガイドブックは、こうした問題を防ぐために、再委託の制限や認める場合の条件、承認の手続きを調達の仕様で定め、要員の配置や品質、情報管理の責任の所在をはっきりさせるよう求めています。*1民間の開発では契約の形によって扱いが異なるため、途中参画の人がどの会社に所属し、誰の指示で作業するのかは、契約書で確かめておきます。
遅れを受入テストで吸収しない
途中参画で日程が戻りきらないとき、最後に削られやすいのがテストの期間です。ガイドブックは、設計・開発ではどこかの工程で遅延が発生することが多く、スケジュール調整の最終手段としてテスト工程を縮める手が選ばれがちだと指摘しています。1か月かける予定だった受入テストを1週間でやることになれば、本来確かめるべきことを十分に確かめられません。*1
そのうえでガイドブックは、受入テストの期間をあらかじめスケジュールとして確保し、それまでの工程が遅れても期間の短縮を安易に受け入れないよう注意を促しています。*1途中参画の効果を見積もるときは、受入テストの期間を動かさない前提で、残りの作業がいつ終わるかを数え直します。
体制を変えたら、その内容を計画にも反映させます。ガイドブックは、当初の計画からの変更は関係者の合意を経るよう求め、目的に直結する重要な事項を責任者の承諾なしに変えることは厳禁だとしています。*1途中参画で変わる体制、役割、費用の見込みを計画書に書き足し、関係者の合意を取ってから進めます。
遅れの原因を社員のスキル不足と人数の不足に分けて見る話は開発遅延と開発要員で、増員で縮む作業と縮まない作業の見分け方は開発遅延の立て直しの記事で扱っています。
まとめ：途中参画の前に確かめる4つのこと
開発遅延のプロジェクトに開発要員を途中参画させるときに確かめたいことは、4つに整理できます。第一に、SPIで遅れの大きさを、残コストで予算の余裕を数字にすること。第二に、増員で日程は戻せても出来高あたりの費用は上がりやすいと理解し、参画後はSPIとCPIを並べて見ること。第三に、進捗率の定義やWBSの抜け漏れ、関係者の合意の不足といった、人を加えても縮みにくい遅れでないかを確かめること。第四に、任せる作業をクリティカル・パスとの関係で決め、求める経験を役割ごとに絞り、受入テストの期間は削らないことです。任せる作業と役割が決まれば、それに合う人を探す段階に進めます。
よくある質問
途中参画の人を加えると、どのくらいで効果が出ますか
決まった目安はありません。加わった直後は既存のメンバーの説明の時間も増えるため、出来高はすぐには伸びないことがあります。参画を決めるときに、何週目の時点でSPIとCPIを見て判断するかを先に決めておくと、早すぎる見切りや判断の先送りを防げます。
EVMを使っていない現場でも、同じ考え方は使えますか
使えます。作業の一覧に計画した量を割り当て、終わった量と使った工数を記録すれば、SPIとCPIにあたる数字は出せます。ただし、進捗率の定義があいまいなままだと数字が実態とずれるので、何をもって完了とするかを先に決めておきます。
遅れが大きいときは、人数を一度に増やしたほうがよいですか
一度に増やすと、説明や作業の割り振りの負担が既存のメンバーに集中します。最長経路の外の作業など、すぐに任せられる作業の数から人数を決め、SPIとCPIの動きを見ながら追加を判断する進め方もあります。
任せる作業が決まったら相談
途中参画の人に任せる作業と役割が決まっていれば、そのままご相談いただけます。任せ方を検討している段階でも構いません。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック（DS-120）」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/0af5ce68/20260715_resources_standard_guidelines_guideline_05.pdf）。出典：デジタル庁（2026年6月12日）。第3編第7章 設計・開発のStep.3-2-C（当初計画からの変更の合意）・D（役割分担）・E（WBSと進捗率）・F（EVMを用いた進捗管理手法、表7-9 進捗状況表の記載項目、図7-10 進捗状況分析図の記載例、(5)EVMの使い方）、Step.4-5-A（受入テストに関する注意点）と、第3編第6章 調達のStep.3-2-E（参考6-2 作業実施体制に関する注意点）・G（事例6-7 再委託に関する失敗例）を参照（確認日2026年10月5日）（2026年10月確認）
