必要な情報をヒアリングで引き出そう

要件定義とは

まず、要件定義と要求定義の違いを理解しておきましょう。要件を形作るのは、「何をしたいのか」「システムに対して何を求めるのか」といった内容です。具体的な業務や事業が要求に基づき洗い出され、すべて文章化されているのであればヒアリングは必要ありません。すぐに作業に入ることができますよね。しかし、そんなことはあり得ないので、相手の要求を理解して要件定義をする必要があります。

認識齟齬がないように

どんな案件でも、発注側の要求は曖昧であることがほとんどです。ヒアリングを通して本当にしたいことは何かを突き詰めていく必要があるんですね。要件定義を進める際は、すでにある文章などから相手の要望を汲み取り、その上でヒアリングによって必要な情報を聞き出さなければなりません。
ヒアリングの際によく発生するのが認識齟齬です。依頼内容をプロジェクトメンバー全員がすぐに理解するのは困難です。要件定義で行われた解釈とそれぞれのイメージが大きく異なる可能性があることを理解しておきましょうね。認識齟齬を解消せず、実装されたシステムが発注側の要望とかけ離れていれば、当然ながらトラブルに発展しますよ。
また、発注側の要望をそのまま鵜呑みにしないでください。伝えられた要望をそのまま実装しても、課題を解決できるとは限らないからです。正しい情報を吸い上げるためには、引き出した要件をベースに文章化や認識合わせを行い、認識齟齬が発生しないようにする必要がありますよ。

相手の立場や知識の有無を考慮すべき

誰が何を意識して話すべきか、あるいは聞くべきかが重要です。例えば、事業部は事業のスペシャリストであって、システムの専門家ではありません。彼らは自分の知識や経験を踏まえて要望を伝えてくるので、自ずと事業的な観点から話が進むことになるでしょう。その上で、エンジニアは「その課題をどうやってシステムで解決するのか」を考えなければなりませんよ。このアプローチを間違うと、要件定義は上手くいきません。発注側にITの知識がないことも多いので、その場合は認識齟齬が発生するリスクはより高くなります。もし、発注側に社内SEやIT担当がいるなら、その人たちも巻き込んでヒアリングをした方がいいかもしれませんね。
ビジネスにおける課題に対して、具体的な解決策を専門的な技術を用いて提供するのがエンジニアの仕事です。それを実現するためには、ヒアリングによって正確な情報を引き出すことが必要不可欠なんですね。