システム開発における要件定義に何を求めるのか、その期待ポイントと目的について委託先企業と委託元企業の双方の立場から考えてみたいと思います。
ここでは前提条件として、システム開発を委託先企業にお願いするケースを想定します。ちなみにスタートアップでも次期開発機能を決めるときには要件定義を内部でしていました（要件定義とは呼んでいなかったですが）。
委託先企業の立場からみてみる
まずは委託先企業の立場から、要件定義を見つめてみたいと思います。委託先企業からすると、およそ次のような目的があるのではないかと思います。
- 業務を理解したい
- 製作スコープを明確にしたい
- 実現可能性を伝えたい
- リスクを減らしたい
- 顧客を理解したい
業務を理解したい
要件定義は開発受注後はじめてのフェーズであることが多いため、まずは委託元企業の仕事の内容、流れを知りたいです。
提案依頼書には事前に現状の業務フローがついていることがあって、流れだけならば文書で把握することが可能です。
ただ現場を見て、実際に言葉として聞くことで圧倒的に情報量が増えます。とくに製造業であれば工場や入荷・出荷場所を見たり、実際の帳票（手書きやFAXなどもあり）を見たり、現場の人の流れを見たりすることで業務を理解できます。
業務を理解することで、機能開発する際にも利用イメージが湧いてくるので、より委託元企業の要望にフィットさせることができます。
製作スコープを明確にしたい
何を開発して、何を開発しないか、製作のスコープを明確にしたい。委託元企業が望んでいるものを理解して、それを満たして満足してもらいたい、そんな前向きな気持ちがあります。
一方で何を開発しないかも重要です。過大な要望であったり、必要性に疑念が湧く場合もあります。そのようなときは「本当に必要なのか」「違うやり方もあるのではないか」「つくっても使われないのではないか」などを素直に問いかけることがあります。
無駄なものを作りたくない（あとからいらなかったと言われたくない）ですし、委託元企業のコスト増にもつながるので、こういう問いかけをして製作スコープをすり合わせていきます。
実現可能性を伝えたい
製作スコープと重なる部分がありますが、要望によっては大変工数（コスト）がかかる機能があります。
業務上本当に必須であれば回避不可能ですが、将来のための備えとなるようなとりあえず実装しておくというのであれば回避してもらいます。
また、積み上げたトータルの工数によっては委託元企業の希望納期を達成できないこともあります。この場合もスコープを見直すか、納期を見直すかの調整をします。
このように要望を聞くのみならず、実現可能性についてもはっきりとさせておきたいという目的があります。
リスクを減らしたい
リスク（将来おきるかもしれない損失の可能性）を減らしておきたいことも目的の一つになります。リスクは主に遅延と工数増大、またそれに伴う関係性の悪化が考えられます。
遅延や工数増大は要件の漏れや誤解などによって後続のフェーズにおきることがあります。そのため、委託先企業はさまざまな質問、文書、帳票などをつかってヒアリングするとともに、委託元企業としても聞かれたことのみならず
「関係あるかわからないが・・・」
「そういえば・・・」
のような会話ができるとリスクを減らすことができると思います。
遅延や工数増大が後続フェーズで起きるとお互いの関係性も悪化していくので、要件定義フェーズでなるべくリスクを減らしておきたいと考えます。
顧客を理解したい
要件定義は委託元企業と委託先企業の会話（オンライン・オフラインともに）で行われます。会話を通じて委託元企業のメンバーの特性などを理解して、コミュニケーションの方法や進めかたを調整しながら進めていきたいと考えます。
そのため要件定義フェーズにおける会話は重要なものになるのです。
委託元企業の立場からみてみる
つぎに委託元企業（自社）の立場からみてみたいと思います。自社からみると要件定義には次のような目的を考えるのではないでしょうか。
- 望むシステムをつくってもらいたい
- 業務を理解してもらいたい
- 開発コストを知りたい（抑えたい）
望むシステムをつくってもらいたい
もっとも大きな目的は望むシステムをつくってもらいたいこと。そして望むシステムをつかうことによって業務目的や事業目的を達成したい。システムを開発する際の最重要目的だと思います。
そのために、自社の仕事を丁寧に説明し、課題を挙げて、その解決策を委託先企業にもとめます。
業務を理解してもらいたい
委託先企業に望むシステムを開発してもらうためには、自社の仕事を理解してもらいたい。仕事の目的や流れ、使っている帳票、機械、倉庫、機材などすべてを理解してもらって同じ目線でプロジェクトを進めていきたいと考えます。
開発コストを知りたい
開発責任者や経営層からみると、精緻な開発コストの見積もりがほしいと考えます。
要件定義の終わりには開発工数および開発費用が判明します（させる必要があります）。提示された金額をもって役員会などで費用を決裁し、次期フェーズ以降の契約をすすめていきます。
まとめ
以上、要件定義に求めることをまとめてみました。委託先企業および委託元企業にはシステム開発という共通のゴールがある一方で、要件定義に求めることは異なってきます。
それぞれの立場を理解できる一助になれば幸いです。
