基本設計の説明を受けてから3か月後、テストの画面を触った現場の担当者が「この入力順だと仕事が回らない」と言い出した。開発会社からは、画面の作り直しには設計からやり直す必要があり、期間も費用も追加になると返ってくる。設計書は確かに承認したはずなのに、なぜここまで戻らなければならないのか。システム開発の手戻りは、発注側にとってこういう形で現れることが多いです。
先に結論を書くと、手戻りそのものをゼロにすることはできません。ただし、見つかる時期を前に寄せることはできます。手戻りは、見つかる工程が後になるほど作り直す範囲が広がり、費用と期間への影響が大きくなるからです。この記事では、手戻りが起きる仕組みを発注側と開発会社側に分けて整理し、IPAのモデル契約書にある中間資料の承認と未確定事項の扱いに沿って、発注側ができる承認の出し方を解説します。
この記事のポイント
- 手戻りは見つかる工程が後になるほど作り直す範囲が広がる
- 要件の後出しと承認の先送りは発注側が原因になる代表的な手戻り
- 中間成果物は期限内に書面で返さないと承認したものとみなされる
- 決めきれないことは未確定事項として書面で残しておく
目次
システム開発の手戻りが起きる仕組み
手戻りとは、一度終えたはずの作業をやり直すことです。システム開発では、要件定義、設計、実装、テストと工程を積み重ねていくので、前の工程の内容に問題が見つかると、その上に積んだ作業もまとめてやり直すことになります。
発注側から見て大事なのは、手戻りが「どこで生まれたか」と「どこで見つかったか」の2つを分けて考えることです。
手戻りは見つかる工程で重さが変わる
要件定義の段階で「この項目も必要だった」と気づけば、直すのは要件定義書の1行です。同じことを設計の段階で気づけば、画面や帳票の設計まで直すことになります。テストの段階で気づくと、設計、プログラム、テストの手順書までさかのぼって作り直し、さらにテストをやり直す必要があります。
本番稼働の後に気づいた場合は、これに加えて、すでに入力されたデータの扱いや、現場への再説明まで必要になります。生まれた場所は同じ1行の考え漏れでも、見つかる時期が遅れるほど、作り直す範囲は階段を下りるように広がっていきます。
私が現場でよく見るのは、要件定義の段階で「細かいところは画面ができてから考えましょう」と先送りにした論点が、テストの段階でまとめて噴き出すケースです。先送りそのものが悪いわけではありませんが、先送りにしたことを記録していないと、誰も覚えていないまま工程が進んでしまいます。
発注側が原因になる手戻り
手戻りの原因は開発会社にあると思われがちですが、発注側に原因があるものも少なくありません。代表的なのは次のようなものです。
- 要件定義のあとで、現場から新しい要望が出てくる
- 設計書の承認を先送りにしたまま、開発が先に進んでいる
- 現場の担当者がテストの段階で初めて画面を見る
- 決める権限のある人が打ち合わせに出ておらず、あとから方針が覆る
- 現行システムと同じでよい、とだけ伝えて中身を確かめていない
どれも、発注側の社内で起きていることが開発会社からは見えない、という点で共通しています。開発会社は、承認された内容を前提に作業を進めるしかありません。承認のあとに方針が変われば、それは開発会社から見れば変更であり、作り直しになります。
開発会社側が原因になる手戻り
もちろん、開発会社側が原因になる手戻りもあります。要件定義書に書かれている内容を読み違えた、確認すべきことを確認せずに思い込みで作った、設計のレビューを省いた、テストが足りずに不具合を後の工程に持ち越した、といったものです。
こうした手戻りは、本来は開発会社の中で吸収されるべきものです。ただ、発注側がまったく関係ないわけではありません。確認の質問に答えるのが遅れたり、回答が担当者ごとに違ったりすると、開発会社は推測で進めるしかなくなります。質問への回答期限と、回答する人を決めておくことは、発注側にできる手戻り対策の一つです。
手戻りの費用は誰が負担するか
手戻りが起きたときに揉めやすいのが、その費用を誰が負担するかです。考え方の起点は、契約で合意した仕様書にその内容が書かれていたかどうかです。仕様書に書かれていたのに違うものができたなら、開発会社が約束どおりに作れていないという話になります。仕様書に書かれていなかったことを後から求めたなら、変更として扱われ、追加の費用や期間が必要になるのが一般的です。
いちばん揉めやすいのは、仕様書の書き方があいまいで、どちらとも読めてしまう場合です。「一覧画面で検索できること」とだけ書かれていて、どの項目で検索できるかが決まっていなかった、というような状態です。こうした場合は、どちらか一方の落ち度と言い切りにくく、話し合いで落としどころを探すことになります。あいまいな書き方は、承認の前に言い直してもらうのがいちばんの予防です。
つまり、手戻りの費用の話は、承認した書類に何が書かれていたかで決まります。追加費用の請求が来たときの確かめ方や、変更管理の手続きの回し方は、システム開発の追加費用を発注側が見極める基準で詳しく整理しています。
システム開発の手戻りを防ぐ承認の出し方
手戻りを見つける時期を前に寄せるには、発注側の承認の出し方を変えるのがいちばん効きます。承認は、開発会社から届いた書類にはんこを押す作業ではなく、そこから先の作業の前提を確定させる行為だからです。
中間成果物の承認は期限内に書面で返す
経済産業省とIPAが公開している情報システム・モデル取引・契約書（第二版）には、設計書などの中間資料を発注側が承認する手続きが定められています。開発会社が中間資料の承認を書面で求めた場合、発注側は決められた点検期間内に内容を点検し、結果を書面で返すとされています。
見落とされやすいのが、その次の定めです。点検期間内に、具体的な理由を書面で示して異議を述べなかった場合は、中間資料を承認したものとみなされます。忙しくて設計書に目を通せていないまま期間が過ぎれば、承認したのと同じ扱いになるということです。そして、承認された中間資料を後から変えるには、変更管理の手続きを通す必要があるとされています。
一方で、同じ条文は、内容に不都合がある場合や、まだ決まっていない事項と関係していてその時点では判断できない場合には、具体的な理由を示して承認を拒否したり留保したりできる、とも定めています。承認できないなら黙って期間を過ごすのではなく、理由を書いて返すことが、発注側の権利を守ることにつながります。
承認の前にどの観点で要件定義書や設計書を見ればよいかは、要件定義書レビューのチェックリストにまとめています。
決めきれないことは未確定事項として残す
要件定義や設計の段階で、どうしても決めきれないことは出てきます。社内の別の部署の判断待ち、取引先との調整待ち、法令の改正待ちといった事情です。
モデル契約書は、こうした場合の扱いも定めています。発注側がやむを得ない事情で必要な事項を確定できないときは、その未確定事項の内容と確定の予定時期、確定したときに委託料や納期などの契約条件が変わる場合があることを確認し、双方が記名押印した書面を作っておく、というものです。確定したら、すぐに内容を書面で示し、必要な設計書の修正を依頼します。
この手続きのよいところは、決まっていないことが決まっていないまま記録に残る点です。口頭で「そこはあとで」と済ませると、決めていないことを誰も覚えていない状態でテストまで進み、そこで一気に手戻りになります。未確定事項の一覧を定例の打ち合わせで毎回確認するだけでも、見つかる時期を前に寄せられます。
要件定義書の抜けや、決めておくべき項目の漏れを発注前に点検しておきたい場合は、追加費用・手戻りを防ぐ要件定義書レビューシートで確認項目を一覧で見られます。
画面や帳票は動くもので確かめる
設計書の文章や画面のイメージ図だけでは、実際に使うときの使い勝手までは分かりません。冒頭の例のように、入力の順番が業務に合わないといった問題は、画面を触って初めて気づくことがほとんどです。
そこで効くのが、画面の試作品を早い段階で作ってもらい、現場の担当者に実際に触ってもらうことです。試作品なら、作り直すのは試作品だけで済みます。設計の段階で試作品を使うかどうかは、見積もりや期間にも関わるので、発注の段階で開発会社と相談しておくとよいでしょう。試作品の作り方や費用の目安はプロトタイプの作り方と費用の目安で扱っています。
現場の担当者を早い工程で入れる
手戻りの多くは、実際にシステムを使う人が、承認の場にいないことから生まれます。情報システムの担当者が承認しても、現場の担当者がテストで初めて画面を見るのであれば、そこで出てくる指摘はすべて手戻りになります。
要件定義と設計のレビューには、業務を一番よく知る現場の担当者に入ってもらいます。全員でなくても、業務ごとに1人ずつ代表者を決めて、承認の前に目を通してもらうだけで違います。あわせて、決める権限のある人がいつ承認するのかも、工程表に書き込んでおくと、承認が先送りにされにくくなります。
手戻りの兆候を途中で見つける
手戻りは、ある日突然起きるように見えますが、実際にはその前から兆候が出ています。定例の打ち合わせで、次のような数字や状態を見ておくと、テストの段階でまとめて噴き出す前に手を打てます。
- 開発会社からの質問のうち、回答していないものが週を追うごとに増えている
- 承認待ちの設計書が、点検期間を過ぎたまま残っている
- 未確定事項の一覧が減らず、確定の予定時期が何度も後ろにずれている
- 打ち合わせで「それは画面を見てから決めましょう」という発言が繰り返されている
- 現場の担当者がレビューに一度も出ていない
どれも、発注側の社内で判断が止まっていることを示すサインです。開発会社は、判断が止まっている間も工程表に沿って作業を進めるので、あとで判断が出たときには、その間に作った部分がまとめて作り直しになります。数字が増え始めた時点で、社内の誰が判断を止めているのかを確かめ、決める人と期限を決め直すのが先です。
よくある質問
- Q. 手戻りが多いのは開発会社の力量不足ではないのですか？
- A. そういう場合もあります。ただ、要件の後出しや承認の遅れといった発注側の事情が原因になっていることも少なくありません。手戻りが続くときは、どの工程で生まれた問題が、どの工程で見つかっているのかを一度整理してみてください。生まれた場所が要件定義や承認の段階なら、発注側の進め方を見直すほうが効きます。
- Q. 設計書を承認したあとでも、変更をお願いできますか？
- A. できます。ただし、モデル契約書では承認された中間資料の変更は変更管理の手続きによってのみ行うとされているので、変更の内容と理由を示して協議し、費用や期間への影響も含めて合意する流れになります。無償で直してもらえるとは限らない点は押さえておいてください。
- Q. アジャイル開発なら手戻りは起きませんか？
- A. アジャイル開発は、短い期間で作って確かめることを繰り返すので、大きな手戻りを小さく分けやすい進め方です。ただ、作り直しがなくなるわけではなく、確かめる場に発注側が出ていなければ同じことが起きます。どの進め方でも、承認と確認の場に誰が出るかが鍵になります。
