要求定義の前提になるのが、経営上や業務上の問題の発見と解決策である。ところが、その問題の定義が曖昧なことが多い。そこで今回は「問題とは何か」を示し、適切な定義方法を説明する。
システム開発プロジェクトの現場では時々、首をかしげたくなることが起こる。一例をあげよう。8人ほどのチームを率いるリーダーに、PMが「問題点を報告して下さい」と問う。そうすると「進捗が3日ほど遅れています」という答えが返ってくる。遅れている理由を聞くと、「仕様書の精度が低く、(メンバーが)理解するのに時間がかかっています」と言う。
そこで仕様書の精度が低い理由を問うと、「分かりません」で終わる。これではリーダーとして頼りないし、PMも手の打ちようがない。
別の例もある。プログラムの開発局面で、あるPMはプロジェクト推進チームから「用紙の消耗が増加している」と報告を受けた。通常はA4用紙500枚を一週間に10包みほど消耗するのだが、それが2倍になっているという。「プリンターが不足しているので買い増して欲しい」という要望もあった。
状況を知るため、PMは開発ルームに出向いてエンジニアたちの仕事ぶりをしばらく観察した。廃棄用紙の置き場は文字通り、溢れんばかりだった。なぜそうなのかを見ていくと、プログラムのテストを行うたびに、その結果を印刷している。テスト結果をみながら次のデバッグをやりたいのだという。
この記事の続きをお読みいただくには、
会員登録(無料)が必要です
会員登録(無料)が必要です
バックナンバー
- 要求仕様作成における最大のコツ─機能の2割をカットする:第14回(2009/11/02)
- システム仕様を数式に変換─Z言語で要求仕様を厳密に記述する:第13回(2009/10/02)
- 業務の粒度やアクターの役割を明確化し、システムのふるまいをUMLで表現する:第12回(2009/09/04)
- スケッチ、設計図、プログラミング言語UMLの利用法を再確認する:第11回(2009/08/06)
- ブレーンストーミング、KJ法、NM法、マインドマップ─発想法のエッセンスを理解する:第10回(2009/07/06)