こんにちは、Takamiです！
現在私は現在担当しているC向けWebサイト、B向けWebシステムの改修案件を進めているのですが、要件定義の難しさを改めて思い知り、日々苦闘しています。
そこで今回は、現役でサイト開発をしている立場から「要件定義ができない原因」について考えてみました。
要件定義がうまくできない原因
クライアント・事業部の要求事項が途中で増える・変わる
これは多くのWebディレクターが共感してくれるのではないでしょうか？
本来の開発フローに沿って開発を行う場合、開発を行う最初の段階でクライアントがシステムに求める「要求事項」を固め（「要求定義」といいます）を固めてから、要件定義を行う必要があります。
しかし実際にクライアントから開発を依頼される時点では要求事項はおろか、どういうシステムにしたいかのイメージすらあやふやなことがしばしばあります。しかもなぜかデッドラインだけは最初からひかれていることも…。
締切は決まっているのでなんとか要求事項を引き出し要件に落とし込んで進めるも、クライアント側の社内会議で新たに要求事項が発生し要件追加や見直しが発生…なんてことも珍しくありません。
要件の追加や見直しが頻発すればそれだけエンジニアも設計から見直し続けなければならず、事故の元になってしまいます。
甘い要求定義
クライアント側の事情や視点を捉えられていないと、要求定義自体が失敗して要件定義がうまくいかなくなります。
クライアント側からは「こういうシステムを作ってくれ」という依頼をされた際、その背景で「何を実現したいのか」をヒアリングして引き出しておかないとただ言われたとおりのシステムを作ることになってしまいます。
こうなると開発側としては言われたとおりの開発を行っているのに、クライアントは当初のビジネスの目的を達成できない、といったことが発生します。
クライアントが最終的に「何を達成したいのか」を細かく理解し、時には当初依頼されたシステムとは異なるものをクライアントに提案することも大切です。
解決策
最もクリティカルな解決策は、クライアントから要求を正しくスピーディーに引き出すことです。
そのための手段として、私はよく「複数のシステム仕様案と、それぞれのメリット・デメリットを提示する」ということを意識しています。
相手の要求をヒアリング→要件定義だけで進めてしまうと、顕在化していない要求事項を見逃してしまうことが多々あります。そのため、要求事項に対するソリューションを複数案用意して、それぞれで考えられるメリット・デメリットを整理して提示することで、クライアントは選択を迫られます。
ふしぎなことに、人間は「選択」を迫られると失敗しないように考えを巡らせるので、今まで顕在化してこなかった視点＝要求事項が見えてきます。
さいごに
今回は要件定義がうまくできない原因について考えていきました。
今回でてきたこと以外にも様々な原因があると思いますが、やはり「要求定義」の失敗や変更が非常に大きなファクターなのではと思っています。
この記事を読んで、少しでも参考になれば幸いです。
以上、Takamiがお送りしました！
