LASSIC Media らしくメディア
開発遅延の立て直し、開発要員の増員で縮む作業と縮まない作業
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 増員で遅れが縮むのは原因が体制の側にあるときで、仕様の決定待ちは人数を増やしても縮みません。
- 残りの作業を、分けて同時に進められるものとそうでないものに分け、渡せる作業の数から人数を決めます。
- 増員も範囲や期日の変更も進捗の会議で決め、IPAのモデル契約にならって理由と影響を記録に残します。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
遅れを取り戻そうと人を増やしたのに、説明と確認に追われて進みが変わらない。増員を頼んだあとで、止まっていたのは仕様の確定待ちだったと分かった——。開発の現場では、こうした食い違いが起こりがちです。開発遅延の立て直しとは、遅れた計画について費用・範囲・期間のどれを動かすかを決め直し、終わりまでの見通しを取り戻すことを指します。
開発要員の増員は、その手段の一つです。残っている作業のうち、分けて同時に進められるものが多ければ、加わる人の分だけ進みが早まります。ただし万能ではなく、決定を待っている作業や順番にしか進められない作業は、人数を増やしても縮みません。本記事では、開発を預かるマネージャに向けて、遅れの原因の切り分け方、増員で縮む作業と縮まない作業、加える人の役割と時期、引き継ぎの負担、そして範囲や期日を動かすときの手続きを整理します。
目次
開発遅延の立て直しとは
立て直しで動かせるものは、大きく3つです。費用（人や時間をどれだけ投じるか）、範囲（何を作るか）、期間（いつまでに終えるか）です。開発要員の増員は、このうち費用を投じて期間を守ろうとする打ち手にあたります。
IPA（情報処理推進機構）の「情報システム・モデル取引・契約書（第二版）」は、システム開発の契約のひな型と、条文ごとの解説をまとめた資料です。*3 その解説は、当初の費用・範囲・期間の中でシステムを作るのが不可能だと明らかになった場面について裁判例を引き、「開発費用、開発スコープ及び開発期間のいずれか、あるいはその全部を抜本的に見直す」か、それが難しければ「開発そのものを断念するかも含めて決定しなければならない局面」があると説明しています。*1
増員だけを先に決めてしまうと、範囲や期間を見直す機会を逃しやすくなります。人を増やすかどうかは、3つのうち費用の側の一つの答えにすぎません。範囲を絞る、期日を延ばすという選択肢と並べて比べられる形にしておくことが、立て直しの最初の一歩になります。
遅れの原因をどう切り分けるのか
増員で遅れが縮むかどうかは、遅れの原因しだいです。原因を分けるときの手がかりになるのが、IPAの「ソフトウェア開発分析データ集2022」です。企業から集めた開発プロジェクトの実績を分析した資料で、集めるデータ項目の定義も載っています。*2
そのデータ項目の一つが「QCDの計画未達の場合の理由」です。QCD（品質・コスト・納期）の計画が未達だった場合に、その理由を「主要なものから3つまで選択する」と定められています。*2 選択肢は「その他」を含めて12あります。RFP（提案依頼書）やテストに関わるものも並ぶので、次のように分けて眺めると、どれが人数で埋まる原因なのかを考えやすくなります。
| 分け方 | IPAの選択肢 | 増員との関係 |
|---|---|---|
| 要求の側 | システム化目的不適当／RFP内容不適当／要求仕様の決定遅れ／要求分析作業不十分 | 人数を増やしても決まらない。決める人と期日を先に決める |
| 体制の側 | 自社内のメンバーの人選不適当／発注会社選択ミス／構築チーム能力不足 | 人を加える、入れ替えることで縮む余地がある |
| 検証の側 | テスト計画不十分／受入検査不十分／総合テストの不足 | 計画を直したうえで、テストの実行を分担すれば縮む |
| 管理の側 | プロジェクトマネージャの管理不足 | 作業者だけを増やすと管理の負担が増える。管理を補う人を先に置く |
| その他 | その他（具体的記述） | 中身を書き出してから判断する |
表の1行目は、人数とは別の問題です。要求仕様の決定が遅れているなら、増員した人も同じ決定を待つことになります。まず決める人と決める期日を決め、それでも間に合わない部分を範囲か期間で調整します。
IPAの項目が理由を3つまで選ぶ形になっているように、遅れの原因は1つに絞れないこともあります。社内で振り返るときも、主要なものから順に3つまで挙げ、上から手を打つと整理しやすくなります。
増員で縮む作業と縮まない作業
原因が体制の側にあると分かっても、残りの作業がすべて人数で縮むわけではありません。残りの作業を1つずつ書き出し、次の3つの性質で見分けます。
- 分けて同時に進められる作業（画面ごとの実装、決まったテストケースの実行、移行したデータの確認など）
- 前の作業が終わるまで始められない作業（設計が固まってからの実装、結合したあとの総合テストなど）
- 1人の判断でそろえる必要がある作業（全体の設計方針、データの持ち方、共通部品の仕様など）
縮むのは1つ目です。作業を分けて渡せば、加わった人の分だけ同時に進みます。2つ目は、前の作業の終わりを待つ時間が残るので、人数を増やしても待ちの長さは変わりません。3つ目は、判断する人が増えると方針がばらつき、かえって手戻りのもとになります。
書き出すときは、作業ごとに「終わったと言える状態」も書いておきます。どこまでやれば完了かが書けない作業は、加わった人に渡しても質問が増えるだけで、結局もとのメンバーの手が止まります。完了の状態が書けた作業から順に、増員で縮む候補にします。
この見分けをしておくと、増員の人数も決めやすくなります。分けて同時に進められる作業が2つしかなければ、3人目以降は待つことになります。人数は、同時に渡せる作業の数から逆算します。
加える人の役割と時期
加える人には、作業を担う人と、管理を補う人の2通りがあります。遅れの原因がプロジェクトマネージャの管理不足にあるなら、作業を担う人を増やす前に、進み具合をまとめる人や、テストの計画を立て直す人を置くほうが先です。作業者だけを増やすと管理する相手が増え、管理の負担がさらに重くなります。
増員は、進捗を確かめる会議で決めます。モデル契約の第12条は、ユーザとベンダーが連絡協議会を定期的に開くと定めています。第4項では、ベンダーが進捗管理報告を出したうえで「遅延事項の有無、遅延事項があるときはその理由と対応策、本章で定める推進体制の変更（人員の交代、増減、再委託先の変更など）の要否」などを協議するとしています。*1 人員の増減は、遅れの理由や対応策とあわせて、決まった場で決める事柄として扱われています。
同じ条の第7項は、議事録に、決定された事項と継続検討とされた事項、継続検討事項があれば検討スケジュールと検討を行う当事者を書くよう求めています。*1 社内の開発でも、増員を決めた日、加わる人の役割、最初に渡す作業、効果を確かめる日を議事録に残しておくと、増員で進みが変わったかどうかを後から振り返れます。
加わる時期は、工程の区切りに合わせると渡す作業を用意しやすくなります。設計が固まったあとの実装やテストの実行は、作業を分けて渡しやすい時期です。反対に、設計の途中で人を加えると、決まっていない方針を説明する時間ばかりが増えます。
引き継ぎの負担
増員のすぐあとは、進みがかえって遅くなることがあります。加わった人に仕様や環境を説明するのは、いま手を動かしているメンバーだからです。説明にかかる時間は、そのままもとのメンバーの作業時間から引かれます。
負担を減らすには、加わる人が来る前に次の4つをそろえておきます。
- 最初の1〜2週間で渡す作業と、それぞれの完了の状態
- 開発環境・アカウント・リポジトリの権限（初日から使えるように手配する）
- 読めば作業に入れる資料（仕様書のどこを読めばよいか）
- 質問を受ける窓口の人と、質問に答える時間帯
質問の窓口を1人に決めておくと、ほかのメンバーは作業を続けられます。窓口になる人の担当は、あらかじめ減らしておきます。そうしないと、窓口の人の担当分が新しい遅れになります。
引き継ぎにかかる時間は、残りの期間が短いほど重くのしかかります。残りの期間の大半が加わった人の立ち上がりに消えるようなら、増員より範囲や期日を見直すほうが確実です。
範囲や期日を動かすときの手続き
増員で縮まない部分が大きいと分かったら、範囲か期日を動かします。このとき、口頭の合意で済ませないことが大切です。モデル契約の解説は、仕様の変更が口頭でなされると、変更の有無や内容の認識が共有できず、役割分担や責任範囲があいまいになり、品質に悪い影響を与える一因にもなると述べています。*1
第37条は、変更の提案を受けた側が「変更管理書」を作り、連絡協議会で変更の可否を協議すると定めています。変更管理書に書く事項は、次の8つです。*1
| 番号 | 記載する事項 |
|---|---|
| ① | 変更の名称 |
| ② | 提案の責任者 |
| ③ | 年月日 |
| ④ | 変更の理由 |
| ⑤ | 変更に係る仕様を含む変更の詳細事項 |
| ⑥ | 変更のために費用を要する場合はその額 |
| ⑦ | 検討期間を含めた変更作業のスケジュール |
| ⑧ | その他変更が本契約及び個別契約の条件（作業期間又は納期、委託料、契約条項等）に与える影響 |
範囲を絞る変更でも、同じ8つを書いておくと、何を後回しにしたのかが記録に残ります。後回しにした機能は、次の段階でいつ扱うかまで書いておくと、利用部門にも説明しやすくなります。
協議がまとまらない場合について、第38条は、ユーザが個別契約の未了部分を解約できると定めています。*1 そのうえで解説は「重要なのは、変更管理に関するユーザの意思決定が速やかになされることである」としています。*1 範囲・期日・費用のどれを動かすかを決められないまま時間が過ぎると、その間も遅れは広がっていきます。
外部に頼むときに確認しておきたい点
開発要員を社外から加えるときは、社内の人を加えるとき以上に、渡す作業の書き出しが大事になります。社外から来る人は、社内の決まりや過去の経緯を知りません。分けて同時に進められる作業のうち、完了の状態が書けているものから渡します。
依頼の前に確かめておきたいのは、加わる人の役割（作業を担うのか、管理を補うのか）、最初に渡す作業、進捗を報告する場と形、質問の窓口の4つです。報告の形は、社内のメンバーと同じ進捗の会議に合わせておくと、遅れの状況を1つの表で見渡せます。
遅れの原因の切り分けと、範囲や期日を動かすかどうかの判断は、社内に残します。どちらも利用部門との調整や予算の判断を伴うためです。日程が押したときに社員のスキル不足と人数の不足を分けて見る話は「開発遅延と開発要員」で、リリース直前に増員するかどうかを残業の理由から決める手順は「リリース前に開発要員を増員するか決める手順」で扱っています。
まとめ：立て直しで確かめておきたい3つの点
開発遅延の立て直しで開発要員を増やすかどうかを決めるうえで、確かめておきたい点は3つに整理できます。第一に、遅れの原因が要求・体制・検証・管理のどこにあるかを切り分けること。第二に、残りの作業を、分けて同時に進められるもの、前の作業を待つもの、1人の判断でそろえるものに分け、渡せる作業の数から人数を決めること。第三に、増員も範囲や期日の変更も、進捗の会議で決めて記録に残すことです。この3点を踏まえておけば、「人を増やしたのに、説明に追われて進みが変わらなかった」という事態を避けやすくなります。渡せる作業は書き出せたのに、社内で担える人が見つからないときは、外部の手を借りるのも一つの選択肢です。
よくある質問
増員の効果が出るまで、どれくらいかかりますか
作業の性質と、加わる人がその技術や業務を知っているかどうかで変わります。一律の目安は公表されていません。最初の1〜2週間で渡す作業を決めておき、その作業が終わったかどうかで効果を確かめるのが現実的です。
増員せずに遅れを取り戻す方法はありますか
あります。後回しにできる機能を次の段階へ移して範囲を絞る方法と、期日そのものを延ばす方法です。どちらを選ぶ場合も、変更の理由と影響を書面に残し、関係者の承認を得てから進めます。
連絡協議会の議事録は、誰が作りますか
IPAのモデル契約では、ベンダーが作成してユーザに提出し、承認を得たあとで双方の責任者が記名押印すると定めています。*1 原案を開催日から何日以内に作るかは、契約ごとに日数を決める形になっています。*1
遅れが解消したあとも、加えた人に残ってもらうべきですか
残りの作業と、リリース後の保守の計画しだいです。遅れを取り戻すための作業だけを頼んだのであれば、区切りで終えるのが自然です。続けてもらう場合は、改めて役割と渡す作業を決め直しておくと、担当があいまいになりません。
遅れた開発に加わる人を探したいとき
残りの作業の書き出しや、加わる人に任せる範囲の整理からご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「情報システム・モデル取引・契約書＜第二版＞（2025年4月8日更新）」（Word）（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000087884.docx）。出典：第12条（連絡協議会の設置）第4項・第6項・第7項とその解説、第37条（変更管理手続）第1項とその解説、第38条（変更の協議不調に伴う契約終了）A案とその解説、B案の解説（東京高判平成25年9月26日）を参照（2026年9月確認）
- *2 参考：IPA「ソフトウェア開発分析データ集2022」本編（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：付録A5.2.2「開発プロジェクト全般」のデータ項目126「QCDの計画未達の場合の理由」の定義と選択肢a〜lを参照（p.200）（2026年9月確認）
- *3 参考：IPA「情報システム・モデル取引・契約書（第二版）」（https://www.ipa.go.jp/digital/model/model20201222.html）。参考：公開ページ。公開日（2020年12月22日）、最終更新日（2026年9月11日）と、第二版・追補版の構成を参照（2026年9月確認）
