« 【告知】「XP寺子屋」第1回 | トップページ | プロジェクトは冒険ゲームだ »

2008/01/20

【考察】要求と品質の関係性

「成功する要求仕様 失敗する要求仕様」を興味深く読んでいくうちに、「要求と品質の間にはどんな関係性があるのか?」が疑問として上がってきた。
要求と品質について考察してみる。


【要求エラーの種類】
「成功する要求仕様 失敗する要求仕様」では、いわゆる要件定義のプロセスを要求マネジメントと呼び、その重要性を強調している。
成功したプロジェクトでは開発コストの10~20%、失敗したプロジェクトでは5%以下という統計があるらしい。

「成功する要求仕様 失敗する要求仕様」では、要求マネジメントを下記のプロセスと定義している。
但しシーケンシャルとは限らない。

1.要求の導き出し

2.要求のトリアージ

3.要求の仕様化

そして、要求マネジメントで発生する要求エラーを下記として定義している。

【A】認識エラー
要求の導き出しプロセスで発生する「要求として認識されなかった」エラー。
いわゆる要求漏れ。

「成功する要求仕様 失敗する要求仕様」では、マズローの欲求5段階説を持ち出し、システムに対する顧客の満足度は、ある程度の機能を満たさないと次の要求が出てこないと言う。

この指摘は同意する。
例えば、新規開発でVer1.0をリリースした直後は、まずは信頼性を最優先し、性能や使い勝手は後回しにする時が多い。
この場合、検収後、バグや不具合として課題が上がってくる時が多い。
そして、Ver1.1から順にリリースしてバグフィックスしていくと、機能が安定してくる。
すると、お客様から、もっと使い勝手を良くして欲しい、とか、こんな機能も追加して欲しい、という課題が多くなる。
つまり、課題の質も、苦情から期待へ変化する。

期待系の課題は、信頼性という品質がまず確保されないと、使用性や効率性の品質まで要求が上がってこない。
非機能要求は、後々、システムのカスタマイズで要件漏れとして発覚しやすい。

また、「成功する要求仕様 失敗する要求仕様」では、要求の導き出しで必要なテクニックは、ステークホルダー分析とファシリテーションであると指摘している。

「開発者の仕事はファシリテータであり、顧客が要求を理解できるように手助けする」ことだと述べている。
この指摘は興味深い。
つまり、要求候補を洗い出すプロセスでも、開発者が主導権を握って、顧客をコントロールする必要があることを示している。

【B】トリアージエラー
要求のトリアージプロセスで発生する「要求を実現するために十分なリソースが足りない」エラー。
例えば、機能AとBを実現すると、CとDの開発には間に合わなかった、という事象を指す。
つまり、どの機能を最優先で開発するか、という決断が間違っていたことになる。

この事象は、プロジェクトリーダーならいつも遭遇するはず。
プロジェクトマネジメントで重要なプロセスとしてリソース管理、スケジュール管理があげられるが、有限のリソースをいかに上手に使うか、いつも悩まされる。

「成功する要求仕様 失敗する要求仕様」では、スケジュールも要求の一つと指摘している。
つまり、スケジュールから要求の優先順位を付けることを示唆している。

「成功する要求仕様 失敗する要求仕様」では、要求のトリアージに力点を置くという視点が斬新なのかもしれない。

【C】仕様エラー
要求の仕様化プロセスで発生する「要求を文書化する時に全関係者に共通の見解を与えられなかった」エラー。
つまり、要求そのものは全関係者で合意は取れているが、実現した時に間違っていたということ。
要求を理解しきれていなかったことが相当するだろう。

この事象は、開発チームの設計力、技術力と比例するように思う。
設計力がなければ、要求を仕様化した時、仕様の整合性を突き詰めて考えることができないだろう。
技術力(特にプログラミング力)がなければ、1つの要求からどれだけ広範囲にプログラムに影響があるか、見極められないだろう。

また、品質の内部特性がここで発生する。
要求に関係するステークホルダーとして開発者もいるが、開発者の視点から見ると、保守性や再利用性が良くなければ、要求を後から実現することは難しくなる。

ここで分かることは、顧客は品質の外部特性しか見ないため、保守性や再利用性という要求は開発者からしか出てこないこと。

お客からは、信頼性(機能が業務をカバーしていること)、効率性(性能)、使用性(使い勝手)のように、品質の外部特性しか見ない。
開発者からは、保守性(機能追加や修正がしやすいこと)、可読性(ソースコードが読みやすいか)、再利用性(他システムへコンバートできるか)、理解性(アーキテクチャの一貫性)のような品質の内部特性を重視する。

プロジェクトリーダーの視点からは、システムの品質が新規開発時だけでなく、運用保守フェーズでも、チームの生産性に直結する。
要求に品質を上手く混ぜ込むことが大事だと思う。

|

« 【告知】「XP寺子屋」第1回 | トップページ | プロジェクトは冒険ゲームだ »

プロジェクトマネジメント」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/17765443

この記事へのトラックバック一覧です: 【考察】要求と品質の関係性:

« 【告知】「XP寺子屋」第1回 | トップページ | プロジェクトは冒険ゲームだ »