要件定義の手法に必要なものは
RDRAはRelationship Driven Requirement Analysisの頭文字を取ったものです。
この手法は要件をその関係性を利用して洗い出し、整合性を高め、そしてシステマティックに要件を定義する手法です。
この手法は以下の３つにこだわっています。
・システマティックに要件を定義する
・網羅性を確保する
・整合性を保つ
要件定義の手法を定めるにはこの３つのキーワードが重要な役割を担うと考えています。
「そもそも有効な要件を導き出すことが一番大事ではないか」という声が聞こえてきそうです...
もちろん、それが一番大事です。
そこについては以下のように考えています。
「視覚化して」
「考えるためのツールを使って」
「みんなで考える」
これについては後日説明したいと思います。
今日のところはこの３つのキーワードにこだわる理由を書きたいと思います。
■システマティック
上流工程では往々にして「どのように要件定義を進めるか」ということで混乱します。
私も何度か混乱している上流工程のプロジェクトに呼ばれたことがありますが、そのような現場では決められた手順に従って要件定義をすることが求められます。
プロジェクトを取り巻く状況は様々です。、そのような状況の中で「決められた手順」というものを予め定めるのはなかなか困難です。
しかし、「ある程度順序だった進め方をするための考え方があるのではないか」と感じることがありました。
仕事の中ではなかなか形として整理することが出来ませんでしたが、コンサルとしていつも提供しているやり方はありました。
混乱する現場をある程度類型化して整理する中で、その答えは合意形成にあるように思いました。
つまり、いかに「合理的に合意形成するか」というのを整理することがシステマティックな要件定義につながるのではないかと考えたのです。
合理的に合意形成できればシステマティックに要件を定義することが出来ます。
そして、合理的な合意形成の鍵は要件として定義する情報の関係性にありました。
■網羅性
要件定義も終盤にさしかかってくると「これで本当に必要なものは洗い出せたのかな〜」という漠然とした不安が出てきます。
２０年以上も前の話ですが、２０代でプロジェクトリーダーをしていたときは、外部設計をしていてもまだ、何か抜けがあるのではないかと不安になったものです。
そのころはウォーターフォールが当たり前でUMLのような豊かな表現力をもったモデルも無い時代だったので、全体像を把握することがなかな出来ませんでした。
そのような思いがあるので、いまだに「これで全てか」ということを検証する手段を求めてしまいます。
その答えはまだ無いのですが、網羅性について合意を得るためのポイントのようなものが見えてきました。
網羅性の大本は「システム化の価値にある」と考えたのです。
「おいおいそんなの当たり前だろう！」
「システム化においてその価値を明らかにすることは耳にタコができるほど聞いた」
という声がまたまた聞こえてきそうです....
問題はシステム化の価値を網羅性にどのように結びつけて考えるか ということでした。
■整合性
同じく要件定義が終盤を向かえると、果たして１ヶ月前に作成した資料と今作成している資料の整合性は取れているのだろうかと心配になります。特に文章で組み立てたような仕様の場合はその整合性の検証が非常に難しいです。
現状要件定義の検証は大きく２つに分かれているように思います。
一つはレビューによる方式とOCLのような論理的な方式です。
レビューはレビューワーの技量に非常に依存する方式です。
レビューも効果があるとは思うのですが、チェックするポイントのようなものがないとなかなか品質が安定しないと思います。
つまり優秀な人がレビューすれば有効だが、優秀ではない人がレビューをすると、往々にしてどうでもいいところに難癖をつけて終わってしまうことになります。
もう一方のOCLは厳密なモデルチェックの方法です。
OCLが機能するクラス図だけでは要件は表現できないのと、要件は時間の経過とともに変わっていくのでOCLで厳密に定義しても時間の無駄になってしまう可能性が高いと考えています。
要件定義での整合性はどちらかというと「精度をあげる助けになる」という程度がコストパフォーマンス的（あまり時間をかけずに効果がある）にいいと考えています。
つまり、要件定義のチェックポイントを示し、それを元に妥当でないものを指摘する というのがいいと考えます。
そしてその緩やかな整合性確保の鍵は、やはり要件定義の各情報のつながりにあります。
このように要件定義の手法を考えるにあたっては、網羅的で整合性のある要件をシステマティックに定義できることが必要であると考えています。
