DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

システム開発において、最後の仕上げともいえるシステムテストやユーザーテストは、要件定義や外部設計などの上流工程の設計妥当性を検証することが主な目的です。妥当性検証の結果、設計不良を摘出して、それを改修することで、よりシステム化の目的に合致したシステムに仕上げていくことになります。

ところが、開発を請負っているベンダーとしては、上流工程で決定したはずの設計の通りに作ったシステムを改修することになるので、その改修にかかる追加工数は仕様変更として発注側に費用負担してほしいと主張する場合があります。。。

【　システム開発のＶ字モデル　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
先ほど、「システムテストやユーザーテストは、要件定義や外部設計などの上流工程の設計妥当性検証をする」と書きましたが、これは一般的にウォーターフォールモデルにおける品質の作りこみ過程と品質の検証過程をＶ字型に示して説明した、いわゆるＶ字モデルの考え方によります。

システム開発を行う組織によって開発工程の定義はさまざまであり、各テスト工程と設計工程が図１で示すほどきれいな対称関係にはならないとしても、Ｖ字モデルは各テスト工程でどんなことを検証すべきかを直感的に理解しやすくなる概念図です。

図１では、要件定義で合意した内容をユーザーテストで検証し、外部設計で合意した内容をシステムテストで検証するといった関係性を示しています。ここで注意してほしいのは、システムテストは「外部設計の通りにシステム化されているか」という観点だけでなく、外部設計の正しさ＝「要件定義の内容が外部設計通りに作られたシステムによって達成されるか」という観点も検証対象となっていることです。

この「要件定義の内容が外部設計通りに作られたシステムによって達成されるか」という観点の検証によりＮＧと判定された場合は、「外部設計通りではあるが要件定義を満たしていない」不合格とみなされ、システムを改修する必要が発生します。

さて、このシステム改修が必要な不合格は、仕様変更でしょうか？設計不良でしょうか？

実際のシステム開発においては、このようなグレーゾーンは必ず発生します。いや、そもそも、システムテストの観点として「要件定義の内容が外部設計通りに作られたシステムによって達成されるか」の検証が含まれていることから、むしろこのようなグレーゾーンを摘出して改修することがシステムテストで行うべき作業そのものということになるはずです。

【　仕様変更と設計不良の境界線とは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
システムテストやユーザーテストで、「設計通りではあるが改修の必要がある」不合格を見つけた場合、開発ベンダーとしては、承認をもらっている設計の変更ということで、それはすなわち「仕様変更」であり、追加費用を当たり前のように要求することになります。

ところが、発注側からすると、確かに承認した設計通りかもしれないが、改修が必要であるということは単なる設計不良であり、追加費用を払うことに釈然としないことでしょう。要件定義や外部設計の妥当性検証をシステムテストやユーザーテストで行って、せっかく不合格を摘出したのに、それが仕様変更≒「発注側からの要求が変わった」扱いになるなんて！発注側組織内の経営陣から「どうして開発ベンダーにきちんと要求が伝えられていなかったんだ」と叱責されるのを避けるために、ベンダー側の責任で対処するよう押し付けたくなるのもわかります。

この問題は、前回のブログでご紹介した仕様変更の判断基準としてのベースラインをいくらしっかりと設定したところで、回避できるものではありません。要件定義や外部設計の誤りは、設定したベースラインそのものが間違っていたということであり、確かにどう扱えばよいか、やっかいな問題です。（※１）

この仕様変更と設計不良のグレーゾーンの扱いがやっかいであることはわかっていることなのに、意外にどのプロジェクトでもあいまいなままとされることが多いのが現実です。システムテストやユーザーテストで実際に検出されたグレーゾーンの扱いをめぐって、発注側と受注側の間でコンフリクトが発生して、余計な調整工数などのロスが生じているのです。このグレーゾーンの発生が少ない場合は都度調整すれば多少のロスがあってもカットオーバーを迎えることができるかもしれませんが、もし多発した場合には調整が追い付かずに、プロジェクトが迷走してしまうことになります！

システム開発のプロジェクトが仕様変更多発で暗礁に乗り上げるといった場合、ユーザーの要求が変わることよりも、このグレーゾーンが多発するケースの方が多いのではないでしょうか？「仕様変更多発」という表現は、ベンダー側からすると聞こえは良いかもしれませんが、なんのことは無い、その原因の多くは単に要件定義や外部設計などの上流工程での検討が不十分だっただけであり、本質的には「設計不良多発」と同義であると考えるべきです。

つまり、いわゆる仕様変更と設計不良の間に境界線など存在せず、「仕様変更のほとんどは設計不良だ」と自覚する必要があると私は考えています。この考え方が自覚できれば、システムテストやユーザーテスト段階で発生した仕様変更をめぐる発注側と受注側のコンフリクトをもっとうまく避けることができるはずです。

「システム開発における仕様変更のほとんどは、上流工程の設計不良だと自覚しよう！」

【　仕様変更と設計不良のグレーゾーンのさばき方　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここで発注側の言い分として、「不良と位置付けられるんだから、ベンダーが追加コスト無しに対応するのが当たり前」という短絡的な発想は捨てる必要があります。その発想の根源には、おそらくシステム開発を委託しているのが発注側、委託されたシステムを開発しているのが受注側という図式があるのではないでしょうか？

昨今では、システム開発の上流工程や超上流工程の重要さが認識されてきていると思いますが、上流工程や超上流工程で主役を演じるのは発注側のはずです。そして、システムテストやユーザーテストなどの最終的な品質の検証過程においても、主役を演じるのはもちろん発注側です。システム開発は発注側と受注側の共同作業であり、もっと言うと、「発注側によるシステム開発の一部を受注側に委託している」という図式で考える必要があるのです。（※２）

開発ベンダーが主役である製造やコーディングなどの下流工程において、一定の不具合が作りこまれることを見込んで作業期間や工数を見積もって計画を立てるのと同じように、要件定義や外部設計などの発注側が主役（たとえ実作業のほとんどを開発ベンダーが行うとしても）の上流工程においても、一定の不具合が作りこまれるはずということをしっかりと見込んで作業期間や工数を見積もったうえで計画に反映する必要があるのです。

あとは、この上流工程で作りこまれた不具合（これまではグレーゾーンとされてきたもの）への対応にかかる作業期間や工数を、どの見積り項目に、どれくらい見込む必要があるかということをはっきりとさせ、発注側と受注側双方が合意しておけばよいのです。

このグレーゾーンについて見積りや計画にどう反映させるべきかは、いろいろな考え方があると思いますが、Ｖ字モデルの概念からしても、システムテストやユーザーテストの対応工数や期間の中に明示的に含めておくのがわかりやすいと私は思います。どのくらいかという点については、なかなか明確な答えは出しづらいと思いますが、過去プロジェクトの実績収集結果にもとづいて算出するのが良いでしょう。

当ブログの　【第４５回】ありのままのプロジェクト実績データ収集　では、「失敗や手戻りも含めた、ありのままのプロジェクト実績データを収集」する必要があると主張しました。要件定義や外部設計などの上流工程の失敗である設計不良が、どの程度発生し、どのくらいの工数がかかっているのかというデータもしっかりと収集する必要があるということです。システムテストやユーザーテスト段階で発生した設計不良への対応を「仕様変更だから別枠だ」などと無視してはダメで、貴重なデータとして扱うべきなのです。

見積り時点では、たとえば、「システムテストやユーザーテストでは開発規模に対して、××％の割合で設計不良が発生する」という前提条件をおいて、その対応期間と工数をあらかじめ見積り、プロジェクト計画に盛り込んで、発注側と受注側で合意しておけばよいのです。

もちろん、仮に前提条件がくずれた場合のリスク対応策についても、あらかじめ明確にして合意しておく必要があります。たとえば「××％を超えた場合のために予備費とスケジュールバッファを確保しておく」とか、リリース日や予算がプロジェクトの制約事項だとすれば「××％を超えそうな部分については、原則としてリリース後に対応する」なんて方針をあらかじめ明確にしておくだけでも、プロジェクト終盤におけるコンフリクトや混乱を予防することができると思います。（※３）

プロジェクト終盤のコンフリクトはダイレクトにプロジェクトの失敗につながることを十分に意識して、これをなんとしても避けるためにできることを発注側と受注側でよく話し合うことが大事なのです！

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　仕様変更とベースラインについては、当ブログの以下の回も参考にしてください。
・【第５１回】カルメンの心変わりと仕様変更～不適切な対応が悲劇を生む！
・【第５２回】仕様変更判断の鍵を握るベースライン設定タイミング

※２　超上流工程とは、図１のＶ字モデルの「ＩＴ構想・企画」および「要件定義」を指すと考えてください。

※３　プロジェクトの前提条件、制約条件については、当ブログの以下の回も参考にしてください。
・【第４２回】プロジェクト制約条件の起源～数字はひとり歩きする！
・【第４３回】プロジェクト計画書に隠された「ありえない前提条件」