発注したシステムの納期が過ぎ、開発会社からは「あと1か月」と言われ続けている。そのうち「増員すれば巻き取れます」という追加費用の見積もりが出てくる。システム開発が終わらない状況で発注側が迷うのは、原因が何かではなく、その追加費用を払うべきかどうかです。この記事では、遅れの起点を発注側都合と開発会社都合に切り分けるところから始めて、追加費用を払う前に打てる手、そして止めるかどうかを決める基準までを順に整理します。技術の話ではなく、発注側にしか決められないことだけを扱います。
この記事のポイント
- 遅れの起点を工程単位で1つに特定してから打ち手を選ぶ
- 原因が自社の回答待ちなら追加費用も打ち切りも筋が変わる
- 人を増やしても納期は縮まらず、終盤ほど効きが悪い
- 範囲を削る・リリースを分けるは発注側にしか決められない
目次
システム開発が終わらない原因の切り分け
遅れの原因を並べた記事はたくさんあります。見積もりの甘さ、要件の追加、体制の問題、進捗管理の不足。どれも間違ってはいません。ただ発注側の立場では、原因を6つ7つと知っても次の一手は決まりません。必要なのは分類ではなく切り分けです。
切り分けの軸は1つだけで、止まっているのが自社側の作業か、開発会社側の作業かです。ここが決まらないまま追加費用を払うと、原因が自社側にあるのに増員の費用だけ負担する形になりますし、逆に開発会社側の事情なのに黙って待ち続けることにもなります。
遅れが始まった工程を1つに絞る
最初にやるのは、遅れの起点を日付で押さえることです。「全体的に遅れている」という認識のままでは打ち手が選べません。手元にある議事録と課題管理表、それから開発会社が出してきた計画表を時系列に並べて、予定から最初に外れた作業を1つ決めます。
私の感覚では、起点は大きく3つのどれかに落ちます。要件が確定しないまま設計に入ってしまった場合、設計を一度作り直している場合、テストで不具合が想定より多く出ている場合です。この3つは見た目が同じ「遅れ」でも、処方がまったく違います。
要件が固まらないまま進んだケースは、今から範囲を削る余地が大きいところです。設計の作り直しは、原因が仕様変更なのか技術的な判断ミスなのかで負担の持ち方が変わります。テストで不具合が出続けているケースがいちばん厄介で、残りの不具合の数が読めないため、期日を切っても意味がありません。この場合は日程ではなく、不具合の発生件数と修正件数の推移を毎週見ることになります。
発注側の事情で遅れているケース
先に自社側から見ます。順番を逆にすると、あとで話がこじれるからです。
よくあるのは、開発会社からの質問が返せていないケースです。「この帳票の丸め方はどうしますか」「この権限は誰が持ちますか」といった質問が、現場に確認中のまま2週間3週間と滞留する。1件ずつは小さくても、10件溜まると設計が進みません。課題管理表の未回答欄を数えて、いつまでに誰が答えるかを1行ずつ埋めるだけで動き出すことがあります。
次に多いのが仕様変更の積み重ねです。1回ごとは「ついでにこれも」という程度の話でも、合計すると当初の見積もりの前提が崩れています。書面で合意していない変更が積み上がっているときは、今の時点でいったん棚卸しして、どれを残しどれを取り下げるかを決める必要があります。
ほかに、承認者が不在で判断が止まっている、受入テストに出す現場要員を確保できていない、移行元のデータを渡せていない、といったものがあります。こうした自社側の滞留が主な原因なら、追加費用の話も打ち切りの話も筋が変わります。まずここを正直に棚卸しするのが出発点です。
開発会社の事情で遅れているケース
自社側を確認したうえで、開発会社側を見ます。典型的なのは、見積もり時点で作業量を少なく見ていた、担当者が入れ替わって引き継ぎに時間がかかっている、他の案件と掛け持ちになっている、想定していなかった技術的な問題にぶつかっている、といったところです。
ここで聞き方が重要になります。「あと何人日ですか」と聞くと、たいてい希望的な数字が返ってきます。そうではなく、残っている作業が何件で、そのうち着手済みが何件か、完了したのが何件かを件数で出してもらいます。件数は水増ししにくいので、状況が見えやすくなります。
開発会社が出してきた作業の一覧が、そもそも粗すぎて読めないこともあります。「機能開発」で30人日というような書き方だと、進んでいるかどうかを外から確かめる方法がありません。作業の粒度から遅れの兆候を読む方法はシステム開発のWBSを発注側が読んで遅れを見抜く視点で詳しく扱っているので、計画表の作りに不安があるときはそちらも見てみてください。
| 遅れの出方 | 典型的な原因 | 発注側が次に取る行動 |
|---|---|---|
| 要件が固まらない | 自社の回答待ち・決裁者不在 | 未回答の質問に期日と担当を割り振る |
| 設計を作り直している | 仕様変更の積み重ね | 変更の棚卸しと、残す変更の絞り込み |
| テストの不具合が減らない | 開発会社側の品質問題 | 件数の推移を週次で共有してもらう |
| 報告の中身が薄くなった | 体制の入れ替え・掛け持ち | 残作業を件数で出してもらう |
システム開発が終わらないときの打ち手
切り分けができたら打ち手に入ります。ここで扱うのは、開発会社からは提案しにくく、発注側にしか決められない3つです。
人を増やしても納期は縮まらない
先に、いちばん誤解されやすいところから書きます。増員しても納期は基本的に縮まりません。むしろ短期的には遅くなります。
理由は単純で、新しく入る人は今の仕様と設計を理解するところから始まるからです。教えるのは、いま手を動かしている人です。つまり増員した直後は、動いている人の時間が引き継ぎに割かれます。しかもプロジェクトの終盤ほど、把握しなければならない前提が増えているので、追いつくまでの時間が長くなります。序盤なら効くこともある手が、終盤では逆に働くわけです。
作業を分けられない性質の遅れもあります。テストで出た不具合の修正のように、原因を追う作業は人数で割れません。ここに人を足しても、待つ人が増えるだけになります。
そもそも工数と工期は比例しません。IPAが公開しているソフトウェア開発分析データ集2022では、5,546件の開発データが集められ、直近6年分の1,479件から工数・工期・規模・生産性などのベンチマークが算出されています。開発会社の見積もりが業界の実績と比べて妥当かを確かめたいときの物差しとして使えます。なお同ページには、事業終了に伴い今後の発行予定がない旨が明記されているので、最新版が出ないデータとして扱ってください。
だから「増員して巻き取ります」という提案が出てきたときは、増える人が何の作業に入るのか、その作業は分けられる性質のものか、効き始めるのはいつからかを1行ずつ確認します。答えが曖昧なら、その増員は納期ではなく請求額を動かすだけになります。
打ち手その一、範囲を削る
いちばん確実に効くのは、作るものを減らすことです。そして削る判断は、発注側にしか下せません。開発会社から「この機能はやめましょう」とは言い出しにくいからです。
ただ「どれを削れますか」と現場に聞くと、まず「全部必要です」と返ってきます。聞き方を変える必要があります。私が使うのは次の3つです。
- その機能が無いと、本稼働の初日に業務が止まるか
- 止まらない場合、手作業や今の仕組みで回せるか
- 手作業で回すとして、月に何時間かかるか
この聞き方だと「止まらないが月20時間かかる」のような答えが出ます。そうなれば、その20時間を3か月負担するのと、本稼働を3か月遅らせるのとを比べられます。判断材料になるのは、必要かどうかではなく、無い期間をどう凌ぐかの見通しです。
削った機能は消えるわけではなく、次の開発に回します。そのときに備えて、削る判断をした理由を1行ずつ残しておくと、あとで「なぜ入っていないのか」と聞かれたときに説明できます。
打ち手その二、リリースを分ける
範囲を削りきれないときは、一度に全部出すのをやめます。本稼働を2回に分け、1回目は限られた範囲で始める形です。
分けやすいのは、拠点や部署で切る方法、業務の単位で切る方法、利用者の範囲で切る方法です。たとえば本社だけ先に始めて支社は3か月後にする、受注の処理だけ先に切り替えて請求は従来のまま続ける、といった分け方になります。
正直に書くと、分けると総量は増えます。旧システムと新システムを並行して動かす期間ができるので、二重入力やデータの突き合わせが発生しますし、移行作業も2回になります。それでも分ける価値があるのは、稼働が先に立つことで社内の見え方が変わるからです。何も動いていない状態で3か月延びるのと、半分動いた状態で残りを進めるのとでは、社内の説明のしやすさがまったく違います。
逆に分けても意味がないケースもあります。データが相互に依存していて切り離せない場合や、切り替えのタイミングが法令や年度で固定されている場合です。この場合は範囲を削る側で調整することになります。
追加費用の見積もりが出てきたときの確認点
ここまで整理したうえで、追加費用の見積もりを見ます。見る順番は金額ではなく前提条件です。
確認するのは、この見積もりが何を前提に作られているか、どこまでが範囲でどこからが範囲外か、増える人がどの作業に入るのか、効果が出始めるのはいつからか、そして今回の追加でこの先の納期をどう約束するのかです。前提が書かれていない見積もりは、あとで「それは含まれていません」となりやすいところです。
前提や範囲の書かれ方を項目単位で点検したいときは、システム開発見積もりチェックシート（危険サインを見抜く60項目）が使えます。当初の発注時だけでなく、こうした追加見積もりの点検にもそのまま使える内容です。
そのうえで、払うかどうかは切り分けの結果に戻ります。遅れの主な原因が自社の回答待ちや仕様変更にあるなら、追加費用を負担する筋はあります。開発会社側の見積もり不足が原因なら、払う前に話す内容が別にあります。契約書のどこを見れば自社の枠が分かるか、賠償を請求できる範囲がどう決まるかはシステム開発の遅延で損害賠償を請求できるかの手順で扱っているので、金額の交渉に入る前に一度目を通しておくと判断しやすくなります。
止めるか続けるかを判断する基準
最後に、続けるかどうかの話です。判断材料は3つあれば足ります。
1つ目は、残作業の見通しが立つかどうか。件数で出してもらった残作業が週ごとに減っているなら、遅れてはいても進んでいます。2つ目は、同じ約束が何回破られたか。「あと1か月」が3回続いているなら、その1か月には根拠がないと考えたほうがいいです。3つ目は、今ある成果物が他社に引き継げる形になっているか。設計書とソースコードが揃っていて、自社に権利があるなら、切り替えの選択肢が現実に取れます。
ただし、切り替えは必ず時間を食います。新しい開発会社は現状を把握するところから始めますし、引き継ぎの期間そのものが2〜3か月かかることもあります。残りが本当に少ないなら、続けたほうが早く終わります。切り替えを検討する段階に入ったときの手順はシステム開発の途中でベンダーを変更する進め方にまとめてあります。
- Q. 開発会社から「あと1か月」と言われ続けています。どこまで待つべきですか
- A. 期間ではなく回数で見ます。同じ約束が2回まではあり得ますが、3回目が出てきたら、その見積もりには根拠がないと考えたほうがいいです。待つかどうかを決める前に、残作業を件数で出してもらい、前の週から何件減ったかを確認してください。減っているなら遅れていても進んでいます。3週間続けて減らないなら、日程を切り直しても同じことになります。
- Q. 遅れているぶん、費用を減らしてもらうことはできますか
- A. 契約の形と、遅れの原因がどちら側にあるかで変わります。請負で納期が契約に書かれていて、遅れの原因が開発会社側にあるなら、遅延損害金の定めがあるかを契約書で確認する話になります。ただし自社の回答遅れが絡んでいると、そこは免責事由として扱われることが多いところです。金額の話に入る前に、自社側の滞留を先に棚卸ししておくのが安全です。
- Q. 遅れの原因がうちの回答待ちだと言われました。確かめる方法はありますか
- A. 課題管理表で確かめられます。質問が出た日付と、こちらが回答した日付が記録されているはずなので、未回答のまま何日経っているかを1件ずつ数えます。10件のうち8件が2週間以上止まっているなら、指摘は正しいと考えるべきです。逆に回答済みなのに設計が進んでいないなら、そこは別の原因があります。記録が残っていない場合は、今日から日付を付けて残す運用に変えてください。
