要件定義工程は混乱する - 神崎コンサルノート

前回まではRDRAの４つの視点について説明してきました。

今回から数回にわたって実際の要件定義工程でRDRAをどのように活用していけばいいかを説明します。

まずは要件定義工程でよく起こる問題をあげます。

　・ドキュメントが大量にできているがシステムの全体像が見えない
　・誰もシステムにいて説明出来ない
　・要件定義が先に進まない
　〜〜

１．ドキュメントが大量にできているがシステムの全体像が見えない

これは派生開発（既存システムの新規開発）で起こりがちな問題です。
既存のドキュメントやシステムを焼き直した資料を作成しているとドキュメントは大量にできあがりますが、システムの全体像を表す資料やマクロな視点からの資料がまったく見あたらないケースです。

このようなことが起こりやすいのは派生開発特有の原因があります。
それは開発するシステムが基本的には現状とほぼ同じというところから来ています。
当然新規開発になりますので、使っていない機能を削除し、新たな機能を追加することになりますが、既存のシステムがベースになるということが前提になるため、既存のシステムの調査が全面に来ます。

このことから既存のシステムの調査がそのまま分析となって新たなシステム要件になってしまいます。
よく起こる例としては現状の業務フローを作成していたつもりがいつのまにか、新システムの業務フロー要件が混じっていたりします。
そして時間切れを迎え、現状の説明資料なのか、将来の業務フローなのかが不明確な資料ができあがることになります。

また、このケースの背後にはスケジュールの考え方が非常に大きな影響を及ぼしています。
それについては後日プロセスとして書きたいと思います。

２．誰もシステムについての説明ができない

システムの全体像からマクロな視点、そこから詳細な要件へと、つながった形で要件が整理されていないために起こる問題です。
これにはいくつかの要因が挙げられます。

　・詳細な情報ばかりを扱っている（１のケース）
　・つながりのないばらばらな要件をただまとめている
　・各担当者が横の連携無く作業を進めている
　・全体やマクロな視点での打ち合わせの機会が無い
　〜〜

など　システムの全体像をわかりやすく説明するためには、全体から詳細へとつながりのある分析を進めないとなかなかうまく説明出来ません。
開発するシステムを理解しているかどうかは説明可能かどうかで判断できます。従って、分析作業が機能しているかどうかは、わかりやすい説明が出来るか否かで評価することが出来ます。
詳細ばかりで全体をうまく切り分けて説明出来ないときは要注意です。

３．要件定義が先に進まない

要件定義は納期までに時間があるのでついつい延び延びになってしまいがちです。
そして要件定義では不確かなことが沢山ある中で一つ一つのことを決めていかなくてはいけない工程です。

従って合理的に物事を決めていく方法を持っていなければ直ぐに作業がストップしてしまいます。

よくある例として以下のことがあります。

　・議論が袋小路に入って進まない
　・システムの目的が不明確で要件が決めきれない
　・要件の揺り戻しが多い
　〜〜

このようなことが起こると「それでは次回までに各自で解決策を考えて来てください」といって、次の会議まで持ち越しになり、それで進捗が遅れます。

- - - - -

この他にも様々な問題がありますが、まずはこれらの原因と対処方法を考えていきましょう。