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

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

前回は、仕様変更への不適切な対応が生む悲劇とその対応策についてご紹介しました。システム開発のプロジェクトにおいては、必ず仕様変更は発生するものと考えて、変更への備えを怠らないようにする必要があります。

しかし、現実のプロジェクトにおいては、そもそも仕様変更なのか、設計不良なのかをめぐって、発注側と受注側の間でバトルが繰り広げられることを良く見かけますよね。。。

【　仕様変更とは何か？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
「仕様変更は必ず発生するものなので、変更への対応の良し悪しがプロジェクトの成否を左右する。」ということは、発注側も受注側も共通認識としてもっているはずです。しかし、そもそも仕様変更がどんなものなのか、発注側と受注側で認識が大きくずれていることが多いように感じています。いったいこのずれはどこから発生するのでしょうか？

ごく普通に考えて、仕様変更とは「要求仕様が変わる」ことを指すはずです。この要求仕様は「システムが何をしなければならないかを記述したもの」です。（※１）

では、「システムが何をしなければならないかを記述したもの」とは具体的に何でしょうか？ここでは、一般的なウォーターフォールモデルによる新規システム開発で考えてみます。

＜新人Ｐ子さん＞　：　「そうねえ、要件定義書をもとに外部設計、内部設計を進めていくはずだから、『システムが何をしなければならないかを記述したもの』は、普通に考えて要件定義書じゃないかしら？」

＜ベテランＰＭのＭ男氏＞　：　「何をいっとるんじゃ！要件定義書なんて、まだまだ画面、帳票、データベースも固まってないし、『システムが何をしなければならないか』なんてまだ書かれておらんじゃろ？システムをどう実装するかが書かれているものは内部設計書じゃ！」

＜新人Ｐ子さん＞　：　「えー？だって、内部設計書って量が多いから、全部お客様とレビューするわけじゃないですよね？お客様が見てないものが変わったのが仕様変更って、なんかおかしくないですか？」

＜ベテランＰＭのＭ男氏＞　：　「あのなー！われわれは最終的に内部設計書をもとにシステムを実装するじゃろ。その内部設計書が変わるってことは、もちろん手戻りになるんだから、追加コストが発生する。その追加コスト分を少しでも回収するために、客と戦って仕様変更を勝ち取るのがわれわれの仕事なんじゃ！」

―――　うーん。やっぱり、仕様変更の定義って、お金がからむだけに、すっきりと決められないものなのでしょうか？仕様変更をめぐる発注側と受注側の認識のずれは、どのドキュメントを仕様変更の判断基準とするかの認識の違いなのでしょうか？

【　ベースラインを段階的に設定し、仕様変更の定義を合意する　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
一般的なウォーターフォールモデルによる新規システム開発の場合、要件定義⇒外部設計⇒内部設計と段階をふむことで、少しずつ開発するシステムの仕様が詳細化・明確化されていくことになります。Ｍ男氏が主張するように、仮に内部設計書が固まって、お客様がそれを全て確認してその通りにシステム開発することを合意したとすれば、合意した内部設計書を仕様変更の判断基準としてもよさそうですね。

しかし、開発規模が小さい場合にはそれも可能かもしれませんが、大規模なシステム開発の場合は、Ｐ子さんが言うように内部設計書は量が多すぎて、お客様がそれを全て確認することはあまり現実的ではありません。

それに、要件定義、外部設計、内部設計の作業そのものにも開発工数、開発コストがかかるため、要件定義、外部設計、内部設計期間中の仕様変更に伴う手戻りや追加コストの扱いが問題になる可能性もあります。

そこで、一般的なウォーターフォールモデルによる新規システム開発の場合には、図１に示すように、要件定義、外部設計、内部設計のそれぞれの工程開始のタイミングで仕様変更の判断基準となるベースラインを設定するとよいでしょう。

図１では、要件定義の出発点であるシステム企画書を「要求ベースライン」、外部設計の出発点である要件定義書を「要件ベースライン」、内部設計の出発点である外部設計書を「外部設計ベースライン」と表現しています。

前回　【第５１回】カルメンの心変わりと仕様変更～不適切な対応が悲劇を生む！　では、「外部設計での仕様変更多発」への対応策として、「仕様変更の判断基準となるベースラインの明確化」をあげました。つまり外部設計時点では、そのインプットとなる要件定義書が「要求仕様が記述されたもの」に該当するものであり、仕様変更の判断基準＝ベースライン・ドキュメントという整理になります。

ベースラインは仕様変更の判断基準となる大事なものなので、なるべく揺らがないようにしたいものです。そのために、要件や仕様が決定された理由や根拠をレビュー記録票や議事録などに明記して、ベースライン・ドキュメントと合わせて残しておくことも効果的です。あとで「言った・言わない」の水掛け論におちいらないようにするためにも、きちんと議事録を残す必要があるのです。

仕様変更の基準となるそれぞれのベースラインに応じて、スコープやコストも明確となるはずなので、「要求ベースライン」⇒「初期見積もり」、「要件ベースライン」⇒「概算見積り」、「外部設計ベースライン」⇒「詳細見積り」とひもづけて考えると、すっきりするのではなないでしょうか。（※２）

【　現実はそう簡単には決まらない！　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ベースラインを段階的に設定することを発注側と受注側で合意し、それぞれのベースラインを基準にした変更管理ができれば、仕様変更でもめることはだいぶ防げるようになると思います。しかし、現実はそう簡単には行かないことも多いようです。たとえば、次のようなケースはなかなか一筋縄ではいきません。

１．要件や設計が固まらないまま、複数工程を五月雨で実施する場合

たとえば、外部設計レビューが長期化し、なかなかすべての外部設計書が固まらない場合に、残りのスケジュール期間を考慮して内部設計を先行して着手することがあると思います。そのような場合は、「外部設計ベースライン」が確定しないまま内部設計に着手してしまうことになるので、内部設計以降の仕様変更判断基準があいまいなままとなり、仕様変更バトルの温床となってしまいます。

２．工程内での仕様揺り戻し

たとえば、外部設計工程の前半でレビュー承認された画面に対して、後半のレビューの揺り戻しで変更が入った場合は、「外部設計ベースライン」の合意前のために、仕様変更なのかどうかがあいまいになります。受注側としては一度決まった外部設計書がくつがえることで手戻りが発生したと受け止めるので、その追加工数を仕様変更として主張したくなるのは仕方が無いことかもしれません。

３．処理方式設計などの非機能要件に関するベースラインの扱い

カットオーバー後には、開発されたシステムを発注側がひきとって保守を行っていくことになるため、システムの実現方式についても発注側として理解しておく必要があります。場合によっては、発注側としての決まりごとや保守がしやすいような要求をとりいれてもらう必要があります。したがって、処理方式設計書などもベースラインとして合意する必要があるのですが、発注側としては専門知識があるわけでもなく、現実的には開発ベンダーにおまかせ状態となってしまうこともあると思います。

開発ベンダーにおまかせしたはずの処理方式が原因で、たとえばオンラインレスポンスなどの非機能要求が満たせなかった場合などは、発注側としては処理方式を見直してほしいということになるのは当然です。しかし、開発ベンダーとしては、処理方式設計書の承認をもらったうえでシステムの実装を行っているので、処理方式設計の見直しに伴う手戻りコストを仕様変更として要求するなんてことも起きる可能性があります。

ここにあげた例のように、それぞれのプロジェクト事情に応じて、仕様変更の扱いをめぐるトラブルの種は実にたくさんころがっているのです。

したがって、発注側と受注側の間での仕様変更をめぐるトラブルを回避するためには、今回とりあげたベースライン設定と変更管理ルールの合意だけでなく、双方が仕様変更発生時の予備費を確保するなどの備えを怠らないとともに、常日頃からお互いの信頼関係を築きあげる努力が求められると思います。

「仕様変更への対応として、適切なベースライン設定と発注側受注側の信頼関係構築が必要だ！」

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

工藤武久

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

※１　「要求仕様」『フリー百科事典　ウィキペディア日本語版』2013年4月13日 (土) 15:207 utc http://ja.wikipedia.org/wiki/要求仕様

※２　初期見積もり、概算見積り、詳細見積りのタイミングについては、当ブログの以下の回も参考にしてください。
・【第４１回】プロジェクト体制図にバルタン星人が現れるとき