要点
- 要件把握は、ドキュメントだけでなく判断を生み出すべき。
- プロセスマップ、範囲を絞った最初のリリース、アーキテクチャの概要、前提付きの見積もりを期待する。
- 管理する人だけでなく、実際に作業する人を巻き込む。
- 良い要件把握は、作るものを減らすこと、あるいは作らないことを勧める場合もある。
ソフトウェアプロジェクトの費用とリスクの大半は、要件把握の段階で決まります。役立つ要件把握で得られるもののチェックリストと、役に立たない要件把握の兆候を紹介します。
要件把握の目的
要件把握は、費用がかさむ前に思い込みを判断に置き換えるためにあります。最初のリリースが何を、誰のために、どの連携と制約のもとで行うのか、そして妥当な費用はいくらかに答えます。
受け取るべきもの
役立つ要件把握は、チームが読み、議論し、承認できる少数のドキュメントで終わります。
- 現在の仕事の流れと、新システムでの流れを示すプロセスマップ。
- ユーザーの役割と、それぞれが見る必要のあるもの・行う必要のあること。
- 意図的に後回しにするものを明記した、範囲を絞った最初のリリース。
- 連携一覧:新システムがやり取りするすべてのシステムとその方法。
- アーキテクチャの概要:データモデル、構成要素、ホスティング、セキュリティの考え方。
- 前提条件を書き添えた見積もりと計画。
同席すべき人
管理者はプロセスがどうあるべきかを説明します。実際に作業する人は、新システムが支えるか取り除くべき回避策も含めて、実際にどう動いているかを説明します。両方の視点が必要で、重要な要件は後者に隠れていることが多いのです。
注意すべき兆候
これらのどれかが当てはまる場合、難しい判断が開発段階に先送りされており、そこではより高くつきます。
- ワークフローではなく画面の一覧になっている要件定義書。
- 見積もりの前提が書かれていない。
- データ移行や連携についての議論がない。
- 要望されたすべての機能が最初のリリースに含まれている。
作るものを減らすという答え
誠実な要件把握は、既製品、より小さな最初のリリース、あるいはソフトウェアではなくプロセスの見直しを勧めることもあります。それは良い結果です。最も安いコードは、書く必要のないコードです。
参考になりましたか?次の記事をメールで受け取れます。

