要件定義に整合性をもたせるためには 時間との戦い
要件を定義するとは 役に立つシステムを組み立てる ということである。
この「組み立てる」というのがなかなか難しい。
１，２週間で終わるような要件定義であれば、そんなに整合性を気にすることはない（頭の中である程度つじつまを合わせられる）が、数ヶ月かかる要件定義では整合性を取ることは大変難しい。
要件定義が始まったときと、それから１ヶ月後とではシステムに対する理解度は全く異なる。
最初の頃は全くシステム化への組立ができておらず、断片的な情報にもとづいて要件を組み立てている。
しかし、１ヶ月もたつとある程度組立が進み、システムの形が見えてくる。組立に伴う様々な意志決定が行われ、システム化の方向性も見えてくる。
そうなると今度は当初に作成した資料と、今作成している資料の整合性が不安になる。
若いときに経験した要件定義もまさにこの不安との戦いであった。
特にウォーターフォールが当たり前の時代。
時系列にドキュメントを積み重ねていくような手法を使っていたので、プロジェクト開始直後のドキュメントの精度の悪さが問題だった。
その反省も込めてRDRAでは全体を広く浅く、徐々に深掘りする方法を提案している。
一つ一つのドキュメントを完成させないで、全体を徐々に洗練化する方式である。
これであればドキュメントが時系列に古いものと新しいものに分かれないので、時間的な整合性の問題を解決できる。
しかし、問題は広い範囲をいかにスムーズに洗練化するかである。
そのポイントは個々の情報を深掘りしないことである。
簡単に直せるように個々の情報を少量の情報にとどめることが肝要である。
個々の情報としては大して情報量がなくても、視点の異なる情報がつながることで、豊かな情報を伝えることができる。
この特性を使って情報を表現し、素早く要件定義する。
いわゆる「モデリング」である。
要件定義のためのモデリングがRDRAであり、それを図的にではなく ツールとして情報をつなげて登録するのが「要件のツボ」である。
来週のセミナーではUMLを使った整合性の取り方を９月９日のセミナーで紹介し、９月８日のセミナーでは「要件のツボ」を使った整合性の取り方を紹介しようと考えている。
特に「要件のツボ」は専用ツールであり、整合性を確認するための機能が幾つか用意されているので、そこを紹介したいと考えている。
要件定義のためのプロセスという切り口でタイムボックスの考え方を紹介し、そのタイムボックスの中でいかにスピーディーに洗練化と整合性を高めていくかを実演したい。
要件定義の網羅性
要件定義をある程度行うと徐々にスコープが広がり、同時に大量のドキュメントがたまる。
一方要件定義の担当者は「これで全て網羅しているだろうか」「見落としていることはないか」と絶えず不安。
同時にこんなに広がっては予算に見合わないと考える。
さて 要件定義としての網羅性をどのように考えればいいのか？
私も若い頃 要件定義をすると必ず、要件漏れはないか？ これで網羅しているか？と とても不安になった。
今思い出してもその当時の不安な気持ちが昨日のように思い出せる。
一方要件定義で範囲を決めても、開発見積もり段階で予算に合わせて機能の絞り込みが必要になり、システム化範囲の見直しが発生する。
網羅的に要件定義を行い、かつ機能の絞り込みでもつじつまのあうようにシステム化範囲を決める方法が必要だ。
今までいくつものプロジェクトを見ていく中で網羅性についての考え方がある程度見えてきた。
そのポイントは以下の３点
- システム化の価値を明らかにし、その実現を範囲とする
- 複数視点からの確認で網羅性を確認する
- 情報のつながりでつじつまを合わせる
来週のセミナーでは「要件のツボ」と「EA」を使った具体的な方法を示したいと思う。
９月８日 http://www.vsa.co.jp/seminar/rdra/20110908
９月９日 「RDRA＋EAで要件定義モデリング セミナー」
