プロジェクトマネジメント、プロジェクト管理におけるポータルサイト

HOME > ITの達人 > 能登原伸二達人のコラム> のとはらブログ相談(3) プロジェクトにおける上流設計の品質管理

2008年9月26日

のとはらブログ相談(3) プロジェクトにおける上流設計の品質管理

【質問】

のとはらブログ相談(2) 顧客側にIT部門がないプロジェクトにおける上流設計の品質管理のご相談者から続けてのご質問を頂きました。

■課題・ご相談内容
アドバイスいただいたとおり現在の取り組みとしましては 、「まずは、上流の設計品質を良くすることに全力を注ぎ、顧客の信頼を得た上で要件/仕様変更のルールを合意していく」ことに取り組んでおります。

具体的には、業務担当者の参画の必要性を説得し、上流設計を進めております 。これで、顧客側体制の業務知識不足の部分はフォローできつつありますが、IT知識不足の部分はまだリスクを抱えていると思っております。

そこで従来のウォーターフォールモデルからスパイラルモデルに変更しドキュメントベースの設計レビューから脱却しようと思っています。

新たなリスクと考えているのが収束しないスパイラルにならないかという点なのですが、注意すべきポイントや管理手法をアドバイス願います。


【回答】

要するに、顧客と効率的に良い品質を保ちながら仕様を決めて いくにはどのような方法が適切かということですね。
ここで述べられているスパイラルモデルがどのようなプロセスがわかりませんが、完全なイテレーション型の開発方法でプロジェクトを成功させるためには、以下に示す前提が必要だと考えています。

1.少数精鋭の高スキルチーム
2.顧客の積極的な参画
 ・顧客との適切な契約
 ・仕様が増えれば、追加費用請求可能など
3.開発ツールやフレームワークなど、開発生産性を向上させるしくみ

よって、このような前提条件が満たされていない場合はイテレー ション型のプロセスはお勧めできません。

それよりも、要件定義、外部設計フェーズで以下のような分担で仕様を決めていくことをお勧めしています。
要件定義で”正しさ”、外部設計で”見易さ”、”使い易さ”(ユーザビリティ といってもよい)を決めるということです。
要件定義では、ドキュメントベースで仕様を決定し、外部設計ではドキュメントで表しにくいGUIの部分については、実際のユーザーインターフェースを作成して、スパイラルアップしながら仕様を決定していくというやり方です。

<要件定義で決めること:”正しさ”>
1.業務ルール
 例)原価計算の考え方、各種計算式など
2.業務プロセス定義
3.データ定義(意味、属性)

<外部設計で決めること:”見易さ”、”使い易さ”>
1.画面の表示項目の配置
2.画面間の遷移
3.帳票の出力項目の配置

スパイラルアップしながら仕様を決めるときは、例えば2回目まで は受け入れるけど、それ以降の変更は仕様変更ということで合意していることが重要だと思います。
ただし、ここまできちんと手順を踏んで仕様を決定していくと大幅な仕様変更は少なくなると思います。

”正しさ”、”見易さ”、”使い易さ”を同時に決めようとすると顧客は、画面や帳票の使い勝手ばかりに注意が行ってしまい、ドキュメントベースで正確に決めておかないといけない業務ルールなどがいつまでも決まらないということに、なってしまいます。
まずはドキュメントベースで決めないといけない仕様を早めに決めてください。

コメント[0件] | トラックバック[0件]

コメントを書く

名前もしくはニックネーム(投稿者名として表示されます)※必須

メールアドレス(ページには表示しません)※必須

URL

コメント(スタイル用のHTMLタグが使えます)

 

※コメントは承認後に公開されますので少々お待ちください。

トラックバック

このページのトラックバックURL:
http://www.promane.jp/blog_manager/mt-tb.cgi/602

↑ このページの先頭へ