2015年12月1日火曜日

こんな要件定義の研修を作りました!

【このテーマの目的・ねらい】
目的:
 情報システムの要件定義のあるべき姿を知っていただきます。
 ここでも「目的・ねらい」の確認が極めて有効なことを
                           知っていただきます。

ねらい:
 この要件定義のあり方、それを基にした研修をご検討ください。

ーーーーーーーーーーーーーーーーーーーーーーーーーーー

今月はほぼ1カ月、この作業にかかりきりでした。

ある大手情報サービス業のお客様のご要望に対応したものです。

従来の要件定義のガイドや研修では、
そもそもの要件定義の目的が不適切であるために、
全体感がないものがほとんどでした。

そこで、当社では要件定義の実施目的を
「システム開発を実施する意思決定である」として、
そのために必要な作業をトップダウン的に整理しました。

実はその「整理」は約10年前にしていまして、
今回開発したのはそれをベースにしたコンパクトな研修です。
研修は2日間です。
その時間割を示します。
 



このアプローチは、
システム企画方法論であるMIND-SAと同じです。

要件定義の実施目的は「システム開発の意思決定である}
   ↓
意思決定をするためには何が必要なのか。
   ↓
新システムの価値・効用と必要資源である。
   ↓
新システムの価値=システム開発の「目的・ねらい」
必要資源=工数・費用と時間の見積り
   ↓
それが可能となるところまでシステムの内容を明らかにする
(価値の評価や見積りに関係しないものは具体化しない)

ということで、要件定義段階でどこまで検討すべきかの
線引きが明確にできるのです。


これに対して、従来のアプローチは
「システム開発内容を固める(=システム開発の要件)」
というアプローチです。
ボトムアップアプローチであるとも言えましょう。

これだと、どこまでのことを決めればOKなのかが
定まりません。
本来の目的からするとやりすぎだったり不足したりします。
いい加減な内容になってしまうのです。

今回作成した要件定義の成果物関連図をご覧ください。
 



























これは、成果物間の関連を示したものです。





























こちらは、その成果物の位置づけを示しています。
 
 前提条件の規定: スタート地点の要求条件確認です。
 
 設計資料: 要件定義段階の検討成果物の中心です。
  
 定義資料: 設計の詳細化ですが、
         要家定義段階の主役ではありません。
 
 説明資料: 意思決定者・システム利用者への説明用資料です。
 
 要約資料: まとめ資料です。

と区分しています。

この中の定義書類は、今後のためにメモ的に作成するか、
必須の成果物を裏付けるために必要な範囲で作成するかです。
これらの完成は次の工程である外部設計以降になります。

この研修は、「これから要件定義もできるようになろう」
という方々への強力な指針となります。

ご関心ある方は当方にお尋ねください。

因みに、現在ある雑誌で
「手戻りしない要件定義」という解説が連載されていますが
その元祖は当社なのです。

0 件のコメント:

コメントを投稿