仕様変更管理

やっていて当たり前のようですが、以外とできていないのが「仕様変更管理」です。

設計の変更要因は仕様障害、要件もれ、仕様の詳細化不足など様々ですが、仕様変更で一番やっかいなのが、設計書の記載レベルが粗すぎて仕様変更なのかどうか揉めてしまうケースです。

「仕様変更」というと直接コストに跳ね返るような気がして、誰の責任なのか、といった話になりやすく仕様変更依頼をあげずに仕様変更をさせようとするケースもあったりします。

仕様変更管理はなぜ必要なのか、どういう目的で行うのかを明確にしてプロジェクトに適用できれば良いのですが、プロジェクト外部の方も含めて理解を完全に得て進めるのは難しい場合もありますね。

仕様変更はプロジェクト記録、情報共有という意味合いを強く出す方が、スムーズに運用に乗ると思います。

仕様変更の管理を行わないプロジェクトでは、担当者レベルの判断で項目の追加や動作の変更を行いシステムの全体整合性がいつの間にか損なわれるというが起こります。

こういう状況が発生しだすと、大規模プロジェクトでは底なし沼に陥るようなものです。

仕様変更の発生がむやみに現場レベルで行われないこと、そして発生した変更内容をプロジェクト内で共有できる事が重要な目的のひとつです。

それから、プロジェクト記録として重要な役割があります。

プロジェクト実施中に「いつの間にか」仕様が変わってしまう事をゆるすと、承認された設計書の位置づけがあいまいな物になってしまいます。

現場の担当者がユーザに求められて対応を行った仕様変更が、後に元の(承認された)仕様で無いことが問題になった場合、開発者側が元に戻すことを求められるリスクがあります。

設計書や仕様書を仕様変更のたびに書き換え、それを版変えして再承認を得るという運用は無理に近いので、仕様変更管理の運用を行います。

コストマネジメントの観点でも、重要です。予算内で対応できるのかどうか、対応の重要性はどうなのかといった事を常に把握できるプロセスを構築できるのです。予算超過するかどうかは予算根拠からの乖離について常に意識を向けているかが重要です。

 

 

 

 

 

 

 

コメントする

このブログ記事について

このページは、アイブルーム藤井が2009年2月14日 10:52に書いたブログ記事です。

ひとつ前のブログ記事は「プロジェクト組織はミッション定義が重要」です。

次のブログ記事は「問題でなく解決にフォーカスする」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1