要件定義工程では、様々なアクシデントや想定外が起こり、事前に計画していた進め方ができなくなります。標準で定められたプロセスやテンプレートに沿うこともできなくなることは大いにあるでしょう。

そのような状況下でも、明確な心構え(マインドセット)を常に持ち続ければ、適切な行動を選択することができます。

あなたはなぜ、要件定義をしているのでしょうか？ 何のために、その作業をしているのでしょうか？
要件定義はステークホルダー全員が協力して、達成する工程です。協力して仕事を成し遂げるためには、その仕事のゴールが見えていなければ不可能です。
ゴールを明確にすることで、不要な議論や機能の追加を防げます。要件定義書の完成というゴールを常に見据えながら進めていきましょう。

⇒ 📄要件定義書の完成条件

成果物である要件定義書や中間資料は、単なる「ドキュメント」ではなく、合意の証拠として捉えることが重要です。ドキュメントそのものに価値があるのではなく、その内容がステークホルダー間で理解・合意されていることに価値があります。PMは、文書の正確性や完全性だけでなく、合意・承認のプロセスを意識して運用することが求められます。

PMやエンジニアは、顧客の業務 要求をシステム要件に翻訳し、逆に技術的制約を顧客に理解できる表現を使って伝える「翻訳者」の役割を担います。
要件定義では要件の合意が重要ですが、そのためには顧客と開発側双方の「共通理解」が前提にあります。
顧客の言葉をそのまま実装しても正しい解決にならない場合があります。顧客はIT技術に精通していないからこそ、ITのプロにお金を払っています。エンジニアは、業務要件を確認し、ITプロフェッショナルとして業務要件を最適なシステム化要件へブレークダウンする必要があります。そして、エンジニア視点で実現可能性を考慮したうえで、顧客が理解できる表現に変換して提案する必要があります。
顧客の要望を復唱するだけでは、プロフェッショナルではありません。

「この機能が必要です」と言われたとき、まず「なぜですか？」と問いかけましょう。表面的な要望の背後にある本当のニーズを理解することで、より適切な解決策を提案できます。
もしかしたら、その機能は不要かもしれません。あるいは、その機能だけでは達成できない要望が隠れているかもしれません。
「当たり前」と思われるような要件でも、一度「なぜ必要なのか？」という疑問に回答してみましょう。

要件の最終決定者は顧客（正確には顧客の中のスポンサー）ですが、PMやエンジニアが、すべての要望にただ「Yes」と言うことは、責任放棄です。プロジェクトには制約があるからです。

あなたには、予算・納期・品質などの制約をクリアした上で、実現可能な要件を定められるよう、顧客を導く努力が求められます。時として、顧客も含めたチームの一員として、要件を定める必要があります。

必要なら「それは次のリリースで」「別の方法で解決しましょう」と提案する勇気と、それを後押しする論理を持ちましょう。相手の望みや期待を受け止めた上で、それが受け入れられない論理を説明しましょう。

要件定義工程では、多くのプロジェクトで共通する失敗パターンが存在します。これらの失敗を事前に知ることで、同じ轍を踏まずに済みます。

「後で決めよう」「とりあえず進めよう」という判断は、後工程での手戻りや認識齟齬の原因となります。曖昧な要件は必ず明確にし、合意を形成してから次に進みましょう。

一部の関係者だけで要件を決めてしまうと、後から「聞いていない」「それでは使えない」という問題が発生します。影響を受ける全てのステークホルダーを適切に巻き込み、合意形成を図ることが重要です。

「ついでにこれも」「この機能も簡単でしょう」という要望を無制限に受け入れると、プロジェクトは破綻します。スコープの変更には必ず影響分析を行い、優先順位をつけて判断しましょう。