システム開発が遅れたら何を確認する？残作業と業務の期限から見直す

システム開発が遅れると分かったら、まず計画を見直す材料をそろえます。材料は、残っている作業と順番の決まり、遅れの原因について分かっている事実、発注者側でまだ決まっていないこと、業務の期限とその根拠です。そのうえで、延期・段階開始・範囲の見直しを比べ、品質を守る条件を確かめてから、合意した内容と次の確認日を記録します。

この記事は、開発会社と話ができる状態で、遅れが分かってから見直した計画に合意するまでを扱います。誰の責任か、費用を誰が負担するかといった法的な結論は出しません。

残っている作業と順番の決まり、原因の事実を確かめる

最初に、開発会社から残っている作業の一覧をもらいます。作業を「終わった」「作業中」「まだ始めていない」に分け、それぞれが終わる見込みと、その見込みの前提を聞きます。「終わった」と報告された作業が、確認まで済んでいるかも聞いておきます。

架空の例では、「請求書の画面：作業中／見込み：〇月〇日／前提：帳票の項目が決まること」のように、見込みと前提を1行にまとめます。

次に、作業の順番の決まり（依存関係）を確かめます。たとえば「画面の確認が終わらないと、テストに入れない」といった関係です。最後の日がどれだけずれるかだけでなく、途中の確認日がどう動くかも見ます。

遅れの原因も、この段階で確かめます。集めるのは「何が起きたか」という事実と、まだ分かっていないことです。誰の責任かの判断とは分けて、計画を見直す材料として記録します。原因の事実が分からないままだと、見直した計画にも同じ問題が残りやすいためです。

日ごろの進捗報告で、完了・確認待ち・次の判断をそろえる方法は、進捗報告の記事で扱っています。

コラムシステム開発の進捗報告で発注者が確認すること｜完了・確認待ち・次の判断をそろえる

発注者側でまだ決まっていないことも一覧にする

遅れの材料は、開発会社の作業だけではありません。発注者側の確認待ち、まだ決まっていない仕様、社内の承認待ち、移すデータの準備なども、残っている作業に含めます。

これは責任を問うためではなく、計画に入れるためです。項目ごとに、回答の期限と、判断する人を決めます。架空の例なら、「帳票の項目を決める／回答期限：〇月〇日／判断する人：営業部長」のように1行で書きます。

判断する人が決まらない項目は、それだけで次の作業を止めることがあります。早めに社内で担当を決めておきます。回答が遅れそうな項目は、その時点で開発会社に伝えます。

遅れの理由に追加の要望が関わっている場合は、追加要望と仕様変更の扱い方の記事で確かめてください。

コラム開発途中の追加要望の扱い方｜不具合と仕様変更を見分け 費用と納期を確認する

業務の期限を、根拠・変更の可否・延長の条件で書き出す

次に、業務の側の期限を書き出します。「この日までに使い始めたい」という日には、それぞれ理由があります。期限が複数あるときは、早い順に並べます。期限ごとに、次の3点を確かめます。

根拠

なぜその日なのか。外部との約束か、契約か、社内の目標か。

変更の可否

その日を動かせるか。動かすと、何に影響するか。

延長の条件

延ばせる場合、どんな手続きや準備が要るか。

たとえば、今使っている仕組みの契約が終わる日は、動かせないように見えます。それでも、契約先に確かめると、延長の条件が分かることがあります。延長に費用や手続きが要る場合は、その内容も書き出します。反対に、社内の目標日だと思っていた日が、取引先との約束につながっていることもあります。「動かせない」と決める前に、根拠を確かめることが大切です。

根拠が分かると、取れる選択肢が見えてきます。確かめきれていない期限は「確認中」として残し、誰がいつまでに確かめるかを決めます。

延期・段階開始・範囲の見直しを比べる

見直しの選択肢は、主に3つです。組み合わせることもあります。どの案にも成り立つ条件と負担があり、いつでも正しい案はありません。

段階開始と範囲の見直しは似ていますが、違います。ここでは、予定した機能を維持し、使い始める順番を分ける案を段階開始と呼びます。そのため、先に使う部署や機能と、後から使う部署や機能で、やり方が一時的に分かれます。後から使う機能も今回の開発に含めたままにする点が、範囲の見直しとの違いです。範囲の見直しは、今回作る機能そのものを減らします。

比べるときは、表の内容に加えて、業務の期限に間に合うか、現場の負担がどう変わるかも書き添えます。

人を増やす案が出ることもありますが、必ず間に合うとは限りません。作業を分けられるか、新しく加わる人の準備にどれだけかかるかなどで、結果が変わるためです。開発会社に、実現できるかと影響を確かめ、比べる案の一つとして扱います。費用の見込みは、開発会社に出してもらいます。どの案を選ぶ場合も、決めたことは次の確認日とあわせて記録に残します。

品質とテストを守る条件を決めておく

期限に合わせるため、テストの期間を短くする案が出ることがあります。このとき、業務で必要な確認まで減らさないことが大切です。期間を短くするなら、確かめる項目は残したまま、進め方で補えるかを確かめます。

IPAの共通フレームとガイダンス（2013年の資料）では、費用・納期・性能・品質を、互いに影響し合う条件として扱っています。日程だけを動かそうとすると、ほかの条件にしわ寄せが出ることがあります。そこで、見直した計画に合意する前に、次の条件を決めておきます。

• 業務で必ず確かめる項目はどれか
• 一部のテストを並行して進められるか、準備を前倒しできるか
• テストに参加する社内の人の予定を確保できるか
• 確かめる項目が予定どおり終わらないとき、どうするかを誰が判断するか

準備の前倒しには、たとえば、確かめる業務の手順やテスト用のデータを、開発が終わるのを待たずに用意しておくことがあります。並行して進められるかどうかは、案件によって違います。作業の順番の決まりと合わせて、開発会社と一緒に確かめてください。