はじめに
「仕事は一つ一つ終わらせてから次の仕事に取りかかれ」
誰しも若い頃に先輩から言われた経験があると思います。要件定義工程に当てはめると「一つ一つのドキュメントを確実に終わらせてから次のドキュメントに取りかかれ」となるでしょう。しかし、実際にはそう単純にはいきません。
一つ一つのドキュメントを完成させることが要件を一つ一つ決めていくことだ！
と考えているとすれば、ドキュメントを一つ一つ確実に終わらせる作業スタイルが問題の種になります。
例えば「業務フローを決めてから、各作業で使用する画面の設計を行う」という順序で作業を行っているとすると、画面設計で業務フローが影響を受けることがないということになります。
果たしてそうでしょうか？ 画面や帳票などの設計を通してシステムのイメージが固まることで、より効率的な作業を見いだすことができるのではないでしょうか。
RDRA（リレーションシップ駆動要件分析）では要件定義の各情報は相互に依存すると考えます。従って「一方が変われば必ず関係するところも影響が出る」と考えています。
ドキュメントを一つ一つ完成させて進捗を管理する方式が成果物ベースの管理方式です。進捗を管理する上では進捗の判断が明確に分かりとても管理が容易な方法です。しかし、上記のように成果物の完成イコール要件の決定となると問題を引き起こします。
そこで今回は成果物ベースで各メンバーが並行的に作業する従来の方式とはまったく逆の、メンバーが集まり共同して成果物を作成する進め方をご紹介します。
よくおこる問題
既存システムを置き換えるようなプロジェクトの場合は以下のようなことがよく起こります。
- 大量のドキュメントができあがっているがシステムの全体像を誰も説明できない
- システムの枝葉の機能は分かるがシステム化の目的や価値は説明できない
- 自分が担当したところは分かるがそれ以外はまったく分からない
- 要件を固めたいがその前提情報が分からず判断できない
～～
などなど問題をあげればきりがありません。
今回はこれらの問題に対処するための考え方を紹介します。
