決まらないくせに変わりやすいのが要件

要件定義とはお客さまがシステムを使って実現したいことを明確にすることです。決して「何を作ればいいのか」を決めることではありません。システム化を含めて、お客さまにとって「何を実現したいのか」を明確にすることです。

重要かつ難しい仕事でここを失敗すると、あとあとまでプロジェクトに悪い影響を与えてしまいます。

私は、プロジェクトにトラブルが発生する原因のなかで、
人に依存しないプロセス上の一番の理由は

　「要件が決まらないこと」
　「要件が変わること」そして
　「その環境の変化に、対応する準備を怠ること」

であると実感しています。そしておそらく、これは私だけが感じていることではありません。

グラフは日本情報システムユーザー協会(JUAS)によるアンケート結果です。

約40％の回答が要件定義に関係しています。大雑把にいうと、要件定義とは

お客さまの「やりたいこと」を文章や図にまとめてお客さまに確認し
最終的には画面や帳票などの機能に落とし込む作業

です（機能以外にも、性能・信頼性などの非機能要件もまとめなくてはいけません）。

建前上、要件は見積りが終わった段階で決まっているはずです。しかし実際問題として、見積り時に細かい要件まで決めきることはありません。そのためかなりの部分は開発が始まってから決められることになります。

また、要件定義は必要とする工数が実装やテストに比べると少ないためか、
期間が十分に取られないこともあります。これらのことが原因で要件が決めきれずその結果のちのち変更されることになります。

実質、

　要件は変わったのではなく、
　間違って定義されてしまっていることが多い

のです。

要件変更の影響は、工程が進むほど波状的に大きくなります。要件定義書の１行が実際には何千行ものソースコードと何日ものテスト期間に変わることがあります。

下請けの立場になればなるほど要件変更の影響は大きく、まるで振り子のように揺さぶられます。まさにエンドユーザのくしゃみは下請けの台風なのです。

要件を定義するには、ユーザと同じ視点を持つ必要があります。

つまり、「どうやって作るか(How)」という視点ではなく、「何を作るか(What)」、さらに上位の「なぜ作るのか(why)」という意識を持たなくてばいけません。

開発者は担当する役割毎に、工程毎に、成果物毎に視点と視座を切り替えなくてはいけません。当然、その中にはシステムを作る立場ではなく使う立場で考え、お客さまと一緒に考えを整理していく必要もあります。

そこに必要なのは広い意味での問題解決能力であり、プログラミングや設計のスキルだけでは足りません。業務に対する知識はもちろんのこと、要件を引き出すために高いコミュニケーションスキルが必要となります。