要件定義の効率を劇的に上げるコツ4選をプロが解説

皆さんはこんな課題を抱えていないだろうか。
・「開発してみたら、要件定義の内容が曖昧すぎて開発しながら要件を決める必要があった。」
・「開発が進んできたら、要件定義で決めた内容が不完全なことがわかった」
・「開発が進んでいるのに要件が頻繁に追加されたり変更されたりする」

これはある種仕方ない現象だと言える。なぜなら、要件定義はそれほどに難しいからだ。

プログラムを書くのとは違い、かっちりと実施内容が決まっていないために不確実性が高い。また、要件は自分や機械ではなく利用者側の人間と合意する必要がある。この「相手が人間である」という点もプログラムを書くのとは違う特殊な難しさがある所以だ。

しかし、この記事ではそんな要件定義の難しさに悩まされているエンジニアの方に向けて、要件定義のコツを紹介する。

筆者も10年弱におけるエンジニア人生で数々の失敗をしてきた。その過程で本や先輩から多くのことを学んできた。今回は現時点で筆者が思う、要件定義の勘所について４つ紹介する。

筆者は主に自社開発をしているウェブ系ベンチャーを中心にキャリアを築いてきた。そのため、自社開発をしている企業のエンジニアの方にはかなりリアルなコツを紹介できているのではないかと思う。

この記事が要件定義に悩むエンジニアの手助けになれば幸いである。

1 仮説を持って提案することで要求を明確にしていく

まず、一番お勧めしたいコツは要件定義をする際に、常に仮説を持って提案していく姿勢を持つことだ。

受け身の姿勢で相手の言うことを鵜呑みにしていると、要件定義の質は相手次第になってしまう。相手が適切な情報を適切なタイミングで出せないと、途端に質が下がってしまう。つまり、自分のエンジニアとしての仕事のバリューの半分以上を相手に委ねてしまっている状態だ。

たとえば、複数のダイレクトリクルーティング（スカウトが送れる求人）サービスを一つに統合する案件をやっていた時の話だ。案件の背景としては以下の通りだ。一つの地域から始まった求人サービスがあった。しかし、フランチャイズ形式で他の地域でも運営者を変えて横展開していっていた。横展開の方法としては、ソースコードとDBを少しだけ変更してコピーする方法をとっていた。その結果、ソースコードとDBがほぼ同一の複製されたサービスが10個近くある状態だった。

当初、複数あるサービスを一つにしたいと言う話だけがきていた。ソースコードもDBもほぼ同一なので単純に差分を統合してDBを一つにしたら良いと言う認識が社内にあった。

しかし、サービスを分析するとスカウトには欠かせない要素が容易に統合できない状態であることがわかった。具体的に言うとユーザが自分の属性として登録する現在の収入や職種、現在の雇用形態などの値が地域ごとに任意で管理していたため、持っている情報が異なっていたのだ。（ある地域では収入が10万円区切りだったが、とある地域では15万円区切りになっていたり、時給単位で示されていた）

単純な「統合」という言葉を額面通りに受け入れるのではなく、この事実をもとに統合の方向性を二つ示した。

一つ目は、今回のスコープではそれらの値は統合しないことだ。その結果としては、利用する求職者と求人企業にはほとんど変わらない挙動を提供するという内容だ。つまり、現在の登録している地域を基準にして、統合後も統合前に別地域に登録していた求職者はスカウトできないとするものだ。なぜなら、他の地域のユーザを月収で検索しようとすると網羅的ではない値が並んでしまうためだ。（例えば、収入の検索欄には「10〜20万円、10〜15万円、時給1,000円」といった値が並ぶことになる）

二つ目は、今回のスコープでそれらの値を統合してしまうことだ。具体的には、企画サイドで他の地域の運営者と協議の上で収入の選択肢を統合してもらうことだ。その結果としては、求人企業がすべての地域の求職者をスカウトすることができるようになる。

ダイレクトリクルーティングというサービスの性質上、二つ目が良いのではないかという仮説の上での提案だったがその通りであった。

逆に「統合」という言葉を鵜呑みにして深く考えなかった場合には、プロジェクトが終わってからクライアントから意図通りのものができなかったという評価が下されていただろうと思う。

2 要求の背後にある課題をグルーピングし、優先順位をつける

洗い出された要望・要求の背後にある課題をグルーピングし、対応の優先順位をつけることも有効だ。

一般的に、自社開発であれば企画者（受託であれば発注者）が持ってくる案件は要望がてんこ盛りになっていることが多い。なぜなら、エンジニア以外は開発コストの試算ができないからだ。そのため、時間やお金の制約を考えずに、企画者自身が欲しいと思う完璧な機能の状態で要望が作成されるわけだ。

エンジニアは、上記を所与のものとして捉えて、もらった要望の背景にある課題を定義し直し、それをグルーピングすることで優先順位をつける必要がある。こうすることで、現実的なお金と期間の制約から対応するものを選別していき、スコープを限定していくことでより絞られた対象に対して深い議論ができる。

たとえば、先ほどあげたサービス統合のプロジェクトの話だ。

当初先方は、システム的な知見があるわけではなかったため、「統合」したらDBもソースコードも統合されるという期待を持っていた。しかし、実際にはソースコードの統合まで行うと工数が大幅に想定を超えることがわかった。

そこで、ビジネス的な統合に対する目的や課題感の仮説をリストアップし、網羅的にまとめた。その課題をもとに、直近で必ず解決しないといけないことは何かを逆に提案した。以下の画像がその時に利用したロジックツリーだ。一番右側の背景色ありテキストが打ち手を示している。

その結果、「統合」という言葉の範囲がDBの統合だけであるという認識で先方と合意することができ、開発工数としても半分以上削ることができ、その後のプロジェクトではDBの統合にだけ議論を集中させることができた。

3 利用者にとって意味のある単位で適切にフェーズを分ける

要件定義でフェーズを分けて開発することを決めた場合の話だ。

この場合するべきは、優先づけされた課題を利用者や企画者にとって意味のある塊で対応していくことだ。あくまでも利用者や企画者にとっての意味がある塊であり、開発者にとってでも単なる優先順でもない。

例えばタスク管理システムを開発していたとする。他の機能も合わせて考えると以下のような優先度がつけられていたと仮定する。
・クレジットカードを使ってウェブ上で課金できる機能
・タスク同士の関連付けをできる機能
・ApplePayなどのPay系サービスを使って課金できる機能
・課金しているプランを確認できる機能
・課金しているプランを解約できる機能

ビジネス的には課金できたり、課金する方法が増えたり、システムの根幹となるタスクの関連付けの機能が優先度高いのは納得いただけると思う。

しかし、だからといって優先度順に開発を進めていって、課金機能と課金しているプランを確認できる機能と解約できる機能が別々のタイミングでリリースされていいわけではない。（多少例として強引な部分があるかもしれないが）

要は単純な優先度だけでリリースする機能をフェーズわけするのではなく、意味のある塊にまとめて対応する必要があると言うことだ。

4 利用イメージの認識を合わせるために、利用フローを図示する

要件定義は大きく、要望・要求を分析する段階と、その要求などを解決するための方策を提案する段階に分けられる。

後者を実施するタイミングでは、最適な提案ができていることを確認するために、フロー図などを用いて具体的な利用イメージの認識を企画者と合わせることが重要だ。

なぜなら、よくある要件定義の失敗例として、開発が終わってみたら課題を解決できていなかったり、使いづらかったりということがあるからだ。原因としては、エンジニアがシステム開発の目的や背景をきちんと理解していないか、利用者側に立ってシステムを運用するイメージができていないかのどちらかである。だが、誤認している場合やわかっていないことをわかっていない場合は、それを正しい認識に持っていくのは難しい。

そこでするべきなのが、より成果物に近いものを企画者に提示してより具体的に完成後の利用シーンをイメージしてもらい完成系のイメージがずれていないかのフィードバックを貰うことだ。そのために、この段階で工数をかけすぎずにそれを実現する方法として、利用フロー図などを作成、共有、確認してもらうのが有効というわけだ。

例えば、特定の職種の人向けのプロフィール作成サービスを開発していた時の話である。

最初、ざっくりとプロフィールの入稿画面が欲しいと言う要望をもらった。そしてこの要望をもらう直前の会議では、サービス開始直後はプロフィール作成は運営側の営業担当者が行うと言う話が上がっていた。

そこで、私はざっくりと運用フローを以下のようなフロー図にして認識の確認をした。つまり、社内の人が使う画面ですよねという確認をしたわけだ。