どんなに正確に仕様を詰めようとしても，開発着手前に仕様を完全に凍結することは不可能である。そこで，どうすれば仕様変更/追加を減らせるか，どうすれば仕様変更/追加の影響を小さく抑えられるか，を考える。
仕様変更/追加を巡るトラブルの多くは，プロジェクトに利用者を適切に参加させることで防げる。
情報システム部門がベンダーとの窓口となっている想定プロジェクトのようなケースでは，利用部門の意見が反映されにくい。しかし，利用部門はシステムに対して多くの問題意識や要求を持っている。立会検査時に同席した利用者部門から仕様変更要望を受けて，結果として大きな仕様変更に対応せざるを得なくなるリスクがある。
非協力的なユーザーへの対処法
仕様変更/追加マネジメントの基本は「版数（バージョン）管理」である。マネージャは仕様の版数管理表を作成し，仕様変更/追加のたびに版数を上げ項目を変更していく。
開発着手前に必要な要件がそろわず，すべてを凍結できない場合でも，決まった仕様について版数管理を行う。「Ver0.1」とするなどして確実に仕様を固め，保留（未決定）事項を明確にしておく。
版数管理表には，版数，日付，変更理由，承認者を記述する。仕様変更/追加/削除が発生したら，都度版数を更新する。契約時の仕様を「Ver1.0」とすると，大きな仕様変更時には「Ver2.0」，小さな変更時には「Ver1.1」と版数を上げていく。
承認者は誰でもいいわけではない。仕様変更/追加に至る意思決定のプロセスをあらかじめ決めておく。PMBOK Guide＊5ではこれを変更管理システムと呼んでいる。変更管理システムには，ユーザーの情報システム部門と利用部門の各責任者が関わることが必須だ（図3[拡大表示]）。
情報システム部は，性能，信頼性，使用性などシステムの妥当性に関わる部分で主にコミットしてもらう。漏れやすいのは，顧客システムのインタフェース仕様/データベース仕様，利用者画面の遷移仕様，性能/信頼性等の必達目標値/条件など。これらの仕様確定は開発着手前に済ませておき，できれば契約条件に盛り込む。
仕様を確定するプロセスは，必ずユーザーとベンダーの共同作業にする。ユーザー側は，情報システム部門だけでなく，利用部門の参加も求めたい。情報システム部門からは，必要最低限の情報（要求）しか出ないことが多い。利用部門の現場に足を運び，仕様打ち合わせでは出てこない暗黙の要求を確実に吸い上げる。
利用部門の意見は，現在の運用状況やユーザー責任者と利用者の意識のズレを確認する上で重要だ。改善したいことや，情報システム部門に相談したが動いてもらえないことが分かれば，仕様を固める上で参考になる。
利用部門が非協力的なら，彼らの作業負荷を抑えながら協力を得られるように進め方を工夫する。利用者がシステムのイメージを把握しやすく，意見が出やすくなるように，プロトタイプや画面仕様を作成し提示する。
多忙などを理由に，仕様打ち合わせ会議をしょっちゅうキャンセルされるケースもある。そういう時は，数少ない打ち合わせの密度を上げるために，システムの利用現場を訪問する。
やり取りの記録を共有する
決定事項や保留・懸案事項は必ず記録に残し，ユーザーの承認を得る。記録は決められた様式の議事録に限らず，電子黒板などのハード・コピーで構わないので，その場で作成するのがベスト。承認印が困難な場合は，サインやメールの返信など何らかの形で証明できるものを残しておく。
記録自体は仕様変更/追加を減らすことには役立たないが，それが発生した時に，ベンダー側が無償対応すべきなのか，対価を請求できるかの根拠になる。金銭トラブルの大半は，やり取りの記録がきちんと管理されていないことに起因している。
やり取りの記録は，ユーザー，自社，関係会社間で共有できれば望ましい。日付や双方の承認が入った同じ資料を，できればプロジェクト関係会社からアクセス可能な共有フォルダを作り管理したい。同一名の記録は，最新版を識別できるようにしておく。
|
町田 仁司 |
