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

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

前回は「プロジェクトの不条理」に果敢に立ち向かうプロジェクト・マネージャーの姿を描きました。この物語の中でも、デスマーチを引き起こした原因は要求仕様の追加でした。

システム開発のプロジェクトにおいて仕様変更は必ず発生するものであり、変更への対応の良し悪しがプロジェクトの成否を分けると言っても過言ではありません。。。

【　カルメンの心変わりへの不適切な対応が生む悲劇　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ジョルジュ・ビゼーが作曲した『カルメン』（Carmen）というオペラをご存じでしょうか？その前奏曲や『ハバネラ』『闘牛士の歌（トレアドール）』などは必ずどこかで耳にしているはずです！（※１）

カルメンは男たちのあこがれのまとであり、恋に生きる女性です。連隊の伍長ドン・ホセは幼なじみのミカエラと婚約していたため、他の男たちと違いカルメンに見向きもしません。そんなドン・ホセに男気を感じたカルメンは恋に落ち、色香を使って誘惑します。

そこに闘牛士エスカミーリョが現れ、カルメンに言い寄るも簡単には落とせません。エスカミーリョは自分が出場する闘牛に招待するため、危険を顧みずに盗賊たちと逃避行中のカルメンのもとへ向かいます。一方、母の危篤を知らされたドン・ホセは、カルメンへの未練を捨てきれないまま母のもとへ向かいます。カルメンはそんなドン・ホセを捨て、エスカミーリョに心変わりします。

そして、闘牛場を訪れたカルメンを待ち受けていたのは、傷心したドン・ホセでした。ドン・ホセは「自分とよりを戻さなければ殺す！」と脅すものの、カルメンは「よりを戻すなら死んだほうがまし！」と突き放し、逆上したドン・ホセに殺されてしまうという悲劇です。

カルメンの心変わりに翻弄されてしまうドン・ホセと、落ち着いてカルメンの心変わりを待つエスカミーリョの姿が対照的に描かれています。

【　仕様変更への不適切な対応が生む悲劇　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
システム開発のプロジェクトにおいても、仕様変更への不適切な対応が悲劇を生むことが良くありますよね。典型的なケースをいくつかご紹介します。（※２）

１．カットオーバー間近の安易な仕様変更取り込みが生む悲劇！

システムテストまでは順調に進んだものの、ユーザーテストでデータの検索画面に検索キーをいくつか追加する仕様変更を実施しました。その後無事カットオーバーを迎えられたのですが、本番稼働後にエンドユーザーから「オンラインのレスポンスが遅すぎて使い物にならない」とのクレームが続出してしまいました。

レスポンスが悪い原因は仕様変更で追加した検索キーに起因していました。システムテストで大量データによる性能テストを実施し、問題が無いことを確認していましたが、その後のユーザーテスト以降は機能面の確認を中心に実施していたため、大量データを使ってのテストは行っておらず、レスポンスの悪化を検知することができなかったのです！

２．テスト段階での前提条件見直しが生む悲劇！

オンライン処理が中心のシステムであったため、バッチ処理の検討は後回しにされました。オンライン処理の開発スケジュールもきつかったこともあり、バッチ処理との排他制御をまったく考慮せずに開発・テストを進めてしまっていたのです！（※３）

ようやくバッチ処理の検討が進んだのはオンライン処理の結合テスト終盤でした。この段階で日次バッチ処理をどうしてもオンライン時間帯に実行する必要性が判明し、オンライン処理のＤＢアクセス方式を全面的に見直しする必要が生じてしまったのです！

ユーザーの立場からすると仕様変更ではありませんが、方式設計書も承認済みであり、バッチ処理の検討を後回しにすることも合意していたために、開発ベンダーからは強行に仕様変更であると主張され、受け入れざるを得ない状況でした。結合テストを一時中断し、オンラインとバッチの並行稼働を前提としたＤＢアクセス方式の全面見直しを実施することで、開発コスト増大とカットオーバー延期を招くことになったのです！

３．外部設計での仕様変更多発が生む悲劇！

度重なる機能追加を重ねながら十年以上稼働してきた現行システムの調査が不十分の状態で、エンドユーザーからの新システムへの期待感は膨らむ中、要件定義も時間切れで無理やり終結させて、外部設計に突入しました！

外部設計では、現行の画面レイアウトに変更点を書き加えた設計メモを頼りに進めましたが、ユーザーからは「新システムではこうしたい、ああしたい」という要望が多発しました。開発ベンダーの担当者は、ユーザーの要望を自分の担当している設計書に取り込むことに必死で、開発スコープの拡大、現行機能と追加要件の矛盾、お客様担当者間での一貫性の無い要望などの課題への対応が放置され、外部設計がいつまでも収束せず、とうとうプロジェクト続行は不可能との裁定がくだされてしまいました！

【　仕様変更への対応策　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
どれも良く聞くような話でしたね。それぞれのケースでどんな対応をとれば悲劇を防げたのか、対応策を少し考えてみましょう。

１．「カットオーバー間近の安易な仕様変更取り込み」への対応策

・仕様凍結点（仕様変更期限）の設定
⇒　カットオーバーまでに残された期間を考えて、仕様変更取り込み後の十分なテスト期間がとれなくなる時点からは、仕様変更を受け付けないことを合意しておくことです。プロジェクト計画策定時に、マスタースケジュール上のマイルストーンとして設定しておくと効果的です。（※４）

・仕様変更発生時の影響調査や再テスト実施範囲に関するルールの明確化
⇒　仕様変更の内容に応じて、どの機能に影響するか調査する範囲や実施済みの作業をどこまでやり直すかなどを事前にある程度ルール決めしておきます。影響調査と再テスト実施などの仕様変更による手戻り工数は、当初開発よりも割高になることを十分プロジェクトメンバーに周知しておく必要があります。

・カットオーバー間近の仕様変更発生リスクへの予防策、発生時対策の明確化
⇒　カットオーバー間近の仕様変更が発生した場合、プロジェクト目標達成に影響を与える可能性があることを十分意識し、リスク予防策やリスク発生時対策をあらかじめ決めておくことが必要です。

２．「テスト段階での前提条件見直し」への対応策

・バッチ運用時間などの非機能要件の早期明確化と実現性の検証
⇒　バッチ運用時間、オンラインレスポンスなど、主な非機能要件については、要件定義段階で明確に定義し、その実現性を検証しておく必要があります。

・前提条件が変わった場合でも耐えられるような処理方式を採用
⇒　バッチ運用時間などの前提条件は、本番稼働後にも変更となる可能性があります。前提条件がどちらに転んでも耐えられるような処理方式をできる限り採用すべきでしょう。ただし、その処理方式の採用がコストやスケジュールなどに影響する場合は、どのプロジェクト目標を優先するかを熟慮して、プロジェクト・ステークフォルダ間で合意する必要があります。

・前提条件が変わるリスクへの予防策、発生時対策の明確化
⇒　バッチ運用時間などの前提条件が変わった場合も、プロジェクト目標達成に影響を与える可能性があることを十分意識し、リスク予防策やリスク発生時対策をあらかじめ決めておくことが必要です。

３．「外部設計での仕様変更多発」への対応策

・仕様変更の判断基準となるベースラインの明確化
⇒　外部設計段階では、どこまでがもともとの要求仕様であり、どこからが仕様変更なのかの判断があいまいになりがちです。要件定義書に書かれていることを外部設計段階での仕様変更の判断基準となるベースラインとして設定します。逆に言うと、開発スコープやコストに影響を与える仕様変更を切り分けられるような粒度で、要件定義書を記載しておく必要があると言うことです。

・仕様変更発生時の対応方法の明確化
⇒　変更管理ルールをあらかじめ決めておくことです。ルールを決めておけば、変更を依頼する側も依頼された側も、適切なアクションがとりやすくなるはずです。

・仕様変更多発リスクへの予防策、発生時対策の明確化
⇒　仕様変更多発も、プロジェクト目標達成に影響を与える可能性があることを十分意識し、リスク予防策やリスク発生時対策をあらかじめ決めておくことが必要です。

いずれのケースでも共通して言えることは、このような事態ができるだけ起きないようにすることと、もし起きてしまった場合への備え、つまり、リスク予防策と発生時対策の明確化が大切だということです。

『カルメン』におけるドン・ホセのように流されて行き当たりばったりの行動は悲劇を生みます。できるだけエスカミーリョのように変わることを想定した落ち着いた行動を心がけたいですね！

「仕様変更は必ず起きると考え、リスク予防策と発生時対策をあらかじめ決めておこう！」

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

工藤武久

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

※１　「カルメン (オペラ)」『フリー百科事典　ウィキペディア日本語版』2015年3月23日 (月) 17:57 utc http://ja.wikipedia.org/wiki/カルメン (オペラ)

※２　ここであげた例は、あくまでも「ありうる話」であり、フィクションです。

※３　「排他制御」『フリー百科事典　ウィキペディア日本語版』2014年8月26日 (火) 05:27 utc http://ja.wikipedia.org/wiki/排他制御

※４　マスタースケジュール、マイルストーンについては、当ブログの以下の回も参考にしてください！
・【第３０回】マスタースケジュール・フェチ
・【第３１回】禁断の裏マスタースケジュール