要件定義が苦手なエンジニアに送る３つのポイント

プロジェクトメンバー、とくにエンジニアから、自分は要件定義書を書くのが苦手だという話を聞くことがあります。

とくに、何をやりたいのか、まだ煮詰まっていない段階での要件定義についてです。（いわゆる業務要件定義）

エンジニアは要件定義が苦手なのか？

もちろん得手不得手や好き嫌いはあるでしょうが、私が思うに「苦手」というより「観点が違う」というケースが多いように思います。

エンジニアは「どう作るか？」を考えますが、要件定義の初めには何を作るか？を決める必要があるからです。

業務システムのウォーターフォール開発では、業務要件定義とシステム要件定義がわかれ、発注者たる業務サイドの担当部門がやりたいことを要件としてまとめてくれて、システムサイドやベンダーはそれを実現する方式を考える、という役割分担が（建前としては）わりと一般的です。

いっぽう、コンシューマー向けWebサービス開発では、ビジネスとシステムが混然としていますし、そもそもそんな縦割りをするほどメンバーも豊富にいるわけではない、エンジニアが期待する形で"業務要件"を洗い出せる経験のある人は更にまれ、という状況が普通です。

さらには、昨今のDevOpsやアジャイルに代表されるような開発の考え方は、いっそうビジネスとシステムの垣根をなくしています。

このため、エンジニアであってもビジネスサイドから要件を引き出しながら要件定義書を作っていくスキルがより一層求められる時代になってきていると言えます。

当然、その逆としてビジネスサイドもシステムを理解してほしいと言いたくなると思います。ただ、個人的にはビジネスサイドはシステムとしての実現性はさておいてやりたいことを語ってもらうのがよいと思いますが、これは別の話。

話をもとに戻しましょう。

私は、こういった柔らかいビジネス要件をシステム要件に落とし込んでいく過程が好きなのですが、思い返すと、新卒で入ったアクセンチュアというコンサルとSIerを混ぜたような会社でコンサルタントとしての思考プロセスを学んだことが生きているように思います。

今回は、私が要件定義書を書くときに意識しているいくつかのポイントをお伝えします。ユースケースや業務フロー、BFC、SFCといった具体的な要件定義書の書き方には言及していませんが、いずれにも共通する内容かと思います。

1.ユーザー要件から始める。

当たり前だろうという突っ込みが聞こえますが、それでいてついつい忘れがちです。

たとえば、あるアプリで利用者にPushを送りたいとします。
（例えばサボテンECアプリとしましょう。何を隠そう、私はサボテン屋も運営しています。 https://www.solxsol.com/ ）

まずエンジニアなら、どう送るか？を考えるでしょう。
言い換えると、どう作るか。
配信方法はローカルPushか、Push配信サービスを使うのか、
配信内容はどうやって設定するのか、何人くらいを対象としてどれくらいの頻度で送るのか etc

ただここでまず問いかけるべきは、誰になぜどういう内容をいつどこに届けたいのか、です。つまり5W（Who, Why, What, When, Where）。Howは最後です。
これにはある程度、サービスを知らないといけないですね。
たとえば、セール情報を、その商品を表示したことのあるユーザのアプリ上に一斉配信したい、などです。

2.仮説を立てる

これがいちばん要件定義を書くのに大切なポイントかもしれません。

ユーザ視点で、と言われても、どういうサービスをやりたいのか知らないし、と思うかもしれませんね。

そこで有効なのが「仮説思考」です。
仮説思考とは、自分が知らない・はっきりと決まっていないことに対峙したときに、前提を仮に設定して、論理を構築する考え方のことです。

たとえば新宿から立川までどれくらい時間がかかって、費用はどれくらい？と聞かれたとしましょう。これを仮説思考で答えるなら、「"自家用車で行く"ならば、"新宿駅前"を"平日15時"に出発したとして、"立川駅前"まで約1時間です、"高速"を使えば1010円です」というようなことです。
""で囲まれているのは仮定です。私が勝手に決めました。
考える前に詳しくヒアリングできればよいですが、1週間後の打ち合わせで確認、その1週間後に案を作成なんてことやっているといつまでたっても要件定義が終わらないということになります。

アプリPushの要件定義も同じことです。
どういう内容をいつ届けたいのか。これまでの議論からある程度想像できることを勝手に考えてみます。

3.一貫性を持つ

仮説を立てて資料を作成し、レビューをしてもらったところ、ぜんぜん違った！ということはよくあります。

それでもよいのです。あくまで仮説なので、新しい事実がわかれば、仮説を置き換えれば。

このとき大事なのが、仮説に一貫性を持たせること。

例えば　新宿から立川までの所要時間の例でいうと、この仮説は一貫して自家用車でいくことを前提にしています。
ですので、いや「電車なんですけど」と言われれば、交通手段を電車にして見積もりなおせばよい。

この見積直しで大切なのが一貫性。
ある説明では自家用車前提で、ある説明では電車を前提にして話していたら、そもそも説明時点でどっちの前提で話しているか混乱しますし、見直すのもややこしいですね。

一貫性を持つ、というのは意外にビジネス資料を作る際の重要なポイントで、エクセルでもワードでも同じ資料内であれば仮説は一貫させるようにしましょう。そうすれば軌道修正も簡単です。

重要な３つのポイントはここまでで、ここからは上級編。

さらに意識したいポイント（１）　話を構造化する

いわゆるロジカルシンキングのことです。詳しく話すと長くなってしまうので割愛しますが、以下を意識するだけでも、多少の説明ストーリーがおかしくても、議論がぶれることは少なくなるでしょう。

論点を明確にする
サボテンアプリの例であれば今回の論点はアプリPushを送ることです。そしてその資料で何を決めたいかを明確にすること。

いろんな話を混ぜない
アプリPushを送るときにどういうメッセージ・デザインにするか、ということも気になると思いますが、それはあとで議論しても差支えない別の話です。

さらに意識したいポイント（２）　はじめにサマリーを伝える

資料を書くとき、課題設定から書き始めて、とりうる選択肢を並べて説明し、それぞれの比較をして、、、と頭の中のロジック展開そのままに書いていくのは、資料作成過程としてはいいのですが、実はすでに落とし込みたい結論がみんなわかっているようなときには少し冗長です。

聞いている側としては、選択肢比較の説明でボツ案にいろいろと突っ込んでしまいたくなり、議論が発散してしまいがちです。

議論をしたい場合はそれでもよいのですが、すでに導きたい答えがあるときは、はじめに結論を述べるとよいでしょう。

ついでに言わずにはいられない大事なコト

最後に一つ。

要件定義の検討打ち合わせでの決定事項は、最後に復唱し、あとから必ずメモを共有するようにしましょう。

まとめ

要件定義を苦手な人は、３つのポイントを意識しましょう。

1.ユーザー要件から始める

2.仮説を立てる

3.一貫性をもつ