システム開発プロジェクトの現場では、基本設計や詳細設計といった工程の終盤で、「本当にこの工程を終えてよいのだろうか」とふと不安がよぎることがあります。成果物のレビューは一通り終えたものの、細かな論点がいくつも宙に浮いたままで、次の工程が近づいてくるという状況です。

一定規模のプロジェクトの場合、各工程の開始時にエントリークライテリア（工程開始条件：その工程を開始できるかどうかの判断基準）、終了時にエグジットクライテリア（工程終了条件：その工程が終わったかどうかの判断基準）を定めることがあります。

エントリークライテリアの例としては、設計工程開始であれば、

• 設計工程計画がレビュー・承認されていること
• 対向先システムの同意が取れていること

などがあります。

エグジットクライテリアの例としては、設計工程終了であれば、

• 設計成果物のレビュー・承認がされていること
• 品質基準（指摘の量など）を満たしていること
• 変更がある場合の要件定義書の修正が完了していること

などがあります。

基準を設定したとしても、その基準があいまいだと、後続工程に影響を及ぼすことがあります。

ここでは、成果物に関わる基準のあいまいさによって、後続工程で変更が多発してしまったというお話をご紹介したいと思います。

完了基準は満たしているのに、宙に浮いた指摘が後続工程で多くの変更につながった

成果物のレビュー・承認がなされていること、という完了基準自体は多くのプロジェクトで設けられていると思います。

成果物レビューでは、成果物そのものの確認は行われるものの、会議の場で交わされた議論のすべてが成果物や指摘QA台帳などに記載されるとは限りません。

たとえば「次工程以降で検討する」「後続工程でも対応可能」といった発言が会議中に交わされても、「そうか、この工程の話でないなら良いか」と、成果物にも指摘QA台帳にも残らないということが起こりえます。

そして、その結果、後になって、レビュー側、つまり顧客側、作成側、つまりベンダー側双方の認識に齟齬が生まれるケースが見られます。

あるプロジェクトでは、こうした認識齟齬が積み重なった結果、後続のUAT工程で変更管理として扱われる案件が100件程度発生しました。

1件ずつは小さい変更であっても、積み重なると、結果として大きな対応工数になります。

先に、仕様としてFIXをしておけば、または変更扱いとしてないと仕切っておけば、発生しなかった工数です。

この工数分で、スケジュールの都合でスコープ外とした要件も対応できたかもしれません。

完了基準としては、”この工程”の成果物はレビュー・承認がなされている、と言えなくもありません。レビュー指摘についても、”この工程の分”は管理されていました。

しかし、その裏では、あとで決められるからと、宙に浮いた議論が多く発生していたのです。

開始基準や管理ルールのあいまいさがこの問題を引き起こした

こうした問題が発生する背景には、「何をもって完了とするか」の認識が担当者ごとに異なるという事情が大きく関わっていました。

画面や帳票の項目の位置、大きさといった細かな仕様について、どの工程までに確定させれば完了と言えるのかという基準があいまいだったのです。

ある担当者は、基本設計工程の時点で確定していなければ未完了と考え、別の担当者は詳細設計工程で確定させればよいと考えていました。

加えて、レビュー会議の会議内容の記録ルールが曖昧だったということも問題を引き起こした１つの原因でした。

”その工程”の成果物の修正すべき指摘については指摘QA台帳に記載するルールになっていたものの、会議内で出た”すべて”の指摘や発言を漏れなく収集する仕組みがなかったのです。

これにより、この工程じゃなくても良い、という議論がどこにも記録に残らないという状況になりました。

その結果、基本設計工程では決めなかった細かい仕様が、どこにも記録されておらず、詳細設計工程であってもスルーされるという事態が起きました。

一定規模のプロジェクトでは顧客側もたくさんの打ち合わせや報告資料作成等で忙殺されてしまうのと、詳細設計に入ると業務側が細かい仕様まで確認しなくなるため、こういう細かい詰めが抜け落ちてしまうということは現実問題として起こりえます。

これらの問題は、完了基準のあいまいさによって起きたのではなく、もっと手前の、開始基準のあいまいさによって起きてしまったと思います。

設計工程の計画書作成時に、本来であれば、基本設計工程ではどこまで詰めるのか、例えば、例にあげた画面や帳票の項目の位置なども確定させるのか、成果物の完了基準を合意しておくべきだったと思います。

また、計画時の管理ルールとして、レビュー会議では”あらゆる”指摘や発言を議事録、または指摘QA台帳や課題台帳に記載するというルールを定めておくべきでした。

しかし、計画時に成果物の完了基準を定めましょう、運営ルールをしっかり決めましょうと認識していてもうまくいかないことがあります。

その解決策についてまとめました。

解決策①：プロトタイピングによる成果物完了基準の認識合わせ

設計工程開始時に、成果物の完了基準、つまりどこまで何を詰めるのかを整理することにした、とします。

しかし、これも実際の現場でよくあることですが、成果物サンプルをベンダーに作ってもらうと、他社案件のものを持ってくるので、ほとんど黒塗りされていて、詳細がわからないということが起きます。

また、やはりサンプル程度では、前述した項目の位置はどうする？のような微妙なラインの議論には至らないことが多いのが現実です。

顧客側とベンダー側で（ベンダー内でも）、成果物の完了基準の認識齟齬をなくすために推奨したいアプローチは、プロトタイピングを行うというものです。

成果物をプロトタイプ的に作成し、どこまで決まっていれば完了と言えるのかを双方で認識合わせします。例えば、この工程では、画面の項目位置まで決めるのか、そうではないのかなどを、設計作業全体がスタートする前にすり合わせることができます。

プロトタイプの実施には注意点があります。

まず、プロトタイプの実施には相応の工数と期間がかかるため、思いつきで途中に差し込むのではなく、最初から計画に盛り込んでおく必要があります。

次に、プロトタイプの題材選び（つまり画面などの機能です）が重要です。簡単すぎる題材では観点の洗い出しが十分にできず、逆に難しすぎる題材ではプロトタイプ自体に時間がかかりすぎて、後続タスクに影響を与えてしまいます。

プロジェクトの特性に応じた適切な難易度の題材を選ぶことが求められます。

解決策②：レビュー結果の管理ルールの策定とモニタリング

プロトタイピングで成果物の完了基準を押さえつつ、もう1つやるべきことは、レビュー会議の結果を管理するルールを策定することです。これも工程開始時に（または前に）行うことです。

レビュー会議の中で挙がった指摘や課題を、細かいものも含めて一旦すべて台帳管理するようにします。

リスト化した後は、どの工程で、いつまでに決定する必要があるかを整理し、顧客側、ベンダー側で認識を合わせます。

この取り組みにより、後続工程で、これは仕様変更だ、いや変更ではない、という議論をなくすことができます。

また、複数チームで作業を進めていると、これらのルールを守らないチームも出てきます。

そのため、PMOとして、各チームのレビュー会議に参加し、モニタリングを行います。

台帳をしっかり作っていない、議論した内容が台帳に反映されていないなどがあれば、作業プロセスの改善を促します。

レビュー結果の台帳管理の運用の徹底を機能させるためには、会議の時間管理も欠かせません。要件定義や設計工程では、議論に熱中するあまり時間が押してしまうことがあります。

台帳が作りっぱなし、にならないようにするためにも、必ず台帳の内容の認識合わせをする時間を設けるようにファシリテーションすることも重要です。

クライテリアに定義された基準を機能させるという姿勢

エントリークライテリアやエグジットクライテリアの各基準は設ければよいというものではありません。

形式的な基準になってしまっているケースも見かけます。あれやこれや理屈をつけて、その基準を満たしている、と報告するベンダーを見かけます。

管理のための管理になっていないでしょうか。

しかし、大事なことは、その工程でやるべきことは何か、そしてそれが実際にできているのかを顧客側とベンダー側でしっかりとすり合わせ、後続工程にリスクの種をなるべく持っていかないようにすることです。

工程管理に完璧な正解はありませんが、基準を形式的なものではなく、効果的に機能させるという姿勢を持つことこそが、後工程でのトラブルを未然に防ぐ鍵になると思います。