エンジニアと要件定義とWhy

エンジニアリング要件定義の why について簡単にまとめました。

エンジニアであれば要件定義はよく聞くワードではありますし、一般的なシステム開発の工程の中にも定義されていることが多いです。

また、Wikipediaでは以下のように説明されています。

ソフトウェア開発やシステム開発においては、「要件定義」とは、そのソフトウェアやシステムに必要な機能や性能を明らかにしてゆく作業のこと。IT関係の開発では「上流工程」と呼ばれている作業・工程の一部にあたり、実際の具体的な開発作業（プログラミング言語を使ったコーディング作業など）や実装作業を始める前に行う作業のひとつ。

要件定義にはコミュニケーション能力が重要で、逆に言うとそこまで特殊なインプットをせずとも雰囲気でできてしまいがちな工程の一つだと思っています（個人的主観）。

しかし、ユーザーや顧客は自分が欲しいものを完全に理解しているわけではないことが今までの数々の失敗例から明らかになっています。
また、ユーザーはシステムで何ができて、何ができないのかを正確に理解しているわけではないので、自分のオーダーがどの程度的を射たものなのかを把握していないことが多いです。

そんな中で要件定義を進めると、意図したものが出来上がらず、残念な結果になりがちです。

じゃあ、そうならないためにどうすればいいのか。
ここでは二つのケーススタディを元に見ていきます。

ケーススタディ1　コップと取っ手

ユーザーがコップに取っ手をつけて欲しいと言っています。
以下はよくある失敗例です。

ユーザーの要求をそのまま文字通り受け取って、要件を定義しています。
が、これでユーザーが欲しいものを作れるかどうかは完全に博打になります。

要件定義には正解はありませんが、
ユーザーの要求の Why を整理することで、もう少しマシな状況を作ることができます。

ここではなぜ取っ手が欲しいかを深掘りすることで、最初とは異なる解決策に到達しています。
先にも述べたように、ユーザーは技術的に何が可能かを完璧には理解していないので、ユーザー自身は解決策が取っ手しかないと思い込んで要求を述べている可能性があります。しかし、技術的には他にもいろんな手段でユーザーの問題を解決できるかもしれません。それゆえに技術に精通しているエンジニアが要件定義を行うことで新しいソリューションを生み出せる可能性があり、そこにイノベーションに繋がる価値があります。

最終的にどういった解決策が most better かは要件の Why によって決まるので、Why 確認することを常に意識していきましょう。

ケーススタディ2　管理画面と数字

ユーザーは画面にとある数字を表示して欲しいと言っています。
システム開発では本当によくある要件だと思います。
そしてあれもこれも画面に表示して...となっていくのもよくあります。

しかし、世の中には数字を見たい人なんていません（暴論）。

少なくとも管理画面などの業務システムで何かを見たい人はいないです。業務の一環として仕方なく見なければならないだけです。また、数字を眺めて終わり、なんてことはなく、それを見た結果、何かを判断する、あるいは何かしらのアクションを取る必要があるからこそ、数字を見たいと言っているのだと推測できます。

ここでも、Why を深掘りすることで何かが見えてきそうです。

xxで使うから、という Why をさらに深掘りして、後続のアクションとの関係性を明らかにすることで、よりユーザーフレンドリーな機能提案をできるようになります。営業とエンジニアしかいないとこういった会話は間に落ちがちです。しかし、こういうちょっとしたことが他との差別化になったりします。

単に Why 確認するだけでなく、その Why を深掘りすることを常に意識していきましょう。
また、要件定義はある程度科学的にハックできるものです。インプットを増やして、攻めの要件定義をやっていきましょう。