５年やって分かった要件定義に必須な５つのスキルとその上達方法

「要件定義のスキルを上げたいけどどうしたら良いかわからない」

こんなふうに悩んだことはないだろうか。

要件定義ではかなり幅広いスキルが求められる。さらに要件定義の対象は毎回異なるため、具体的なレベルでスキルを言語化するのがかなり難しく、どうしてもスキル定義が「コミュニケーションスキル」や「ビジネス理解スキル」といった抽象的な言葉になりがちだ。

そこでこの記事では、要件定義を第一線で実行してきた私が、要件定義を構成するスキルを以下の５つに分解し、それぞれの向上のための方策も可能な限り具体化した。

・論理的に物事を整理するスキル
・ビジネスの数字を理解するスキル
・業務のフローを理解するスキル
・要求を具現化するスキル
・要求を達成するために必要な機能を洗い出すスキル

それでは一つずつ見ていこう。

１要件定義をするために必要な5つのスキル

この章では、要件定義に必須なスキルとそれがなぜ必要なのかを解説していく。

１−１　論理的に物事を整理するスキル

要求定義においては、物事を論理的に整理するスキルが一番重要だと考えている。これは全てのスキルの根底にあると言っても過言ではない。

企画者や発注者の要求事項を整理することができれば、以下の２点が可能になる。
・要求の背後にある隠れた要求を見つけることができる
・要求ごとの優先順位を判断することができる

以前のプロジェクトでこんなことがあった。そのプロジェクトでは、発注者が複数の求人サービスを所有していた。そこで、その複数の求人サービスのDBを統合したいという要求がでていた。

以下は、複数のDBを統合する目的を整理し直した結果の画像だ。

その結果、DBを統合するだけではなく以下のような要求も隠れていたことがわかった。
・サービスのドメインを統一する
・ソースコードを統一する
・異なるサービス経由で登録したユーザに対して、求人企業がスカウトを送信できるようにする

また、隠れた要求を含めた要求一覧からそれぞれの原因を特定できたため、大枠での対応工数を算出することもできた。その結果、工数とリターンをもとに対応の優先順位のすり合わせをクライアントと行えた。

このようにプロジェクトの初期段階で要求を論理的に整理することで以下のような利点があった。その結果、大きな混乱なくプロジェクトを完了させることができた。
・隠れた要求が早期に見つかり、
・要求ごとの優先順位も特定でき
・やること・やらないことを取捨選択できた。

１−２　ビジネスの数字を理解するスキル

ビジネスの数字を理解するスキルも必要だ。これは要求に優先順位づけする際に必要になる。なぜなら企画者や発注者である非エンジニアとの共通言語だからだ。

例えば先ほどの例で出てきた隠れた要求でいうと、緑背景の施策を後回しにし、青と紫背景の施策を優先する提案をした。改善に必要な開発コストを下げることよりも、求人サービスとして「採用」につながることの方がビジネス上重要だと判断したためだ。

このように、ある施策がどこの数字を改善しようとしているのかを把握して提案できることはかなり重要だ。これができるとビジネス側と目線を合わせて議論できるため、議論が平行線にならずに済む。

１−３　業務のフローを理解するスキル

業務のフローを理解するスキルも必要だ。これはユーザーストーリーを洗い出す際に必要になる。業務のフローが理解できれば、登場人物が誰でどんな順番で何をするのかを洗い出しやすくなる。

例えば、逆に業務フローがわかっていなかったために起きた反省点を紹介しよう。当時のプロジェクトでは、企業向けの環境データ管理のためのSaaSツールを開発していた。

ある機能開発案件で企業の水の使用量や電気使用量などをデータとして貯める機能を開発しようとしていた。これは、前者単位でのデータの数値の変化を経年で確認するための機能だ。

この時、既存の業務としてこのデータの集計がどのように行われているか把握していなかった。そのため、本社の人が全社の数字を入力することを想定して機能が作られた。

しかし、実際は本社の人が各工場や店舗の責任者にそれぞれの拠点の数字を入力してもらい、その後に本社の人がそれらの集まった数字を集計するというフローが取られていた。

結果として、業務フローに対する理解不足によって、想定していたユーザーストーリーが大幅に修正され開発の手戻りが発生してしまった。

１−４　要求を具現化するスキル

要求を具現化するスキルも必要だ。これは隠れた要求を洗い出す際に必要になる。

よく要件定義に必要なスキルは顧客の要望を引き出すコミュニケーションスキルだと言われる。それをより具体的に表現すると、顧客の要求をもとに具体的な叩き台を作り、適切にフィードバックを得て改善を重ねるプロセスを回すスキルだと筆者は捉えている。

抽象的なことを抽象的なまま話していても見えてこないことがたくさんある。そのため、抽象度の高い要求を、より具体的に見えるものに落とし込んでいって要求を引き出していくことが重要なのだ。そのために必要なのが要求を具現化するスキルというわけだ。

例えば、１−１で取り上げた求人サービスの統合案件の例を挙げよう。この求人サービスの統合案件では、DBの統合が要求として挙げられていたことは述べた。

そこから一歩進んでDBを統合した際に、求職者がどんな状態になるのかを可視化したのが以下の図だ。これによって、DBを統合すると求職者は今まで登録していた地域以外の企業からもスカウトを受け取れる可能性が明らかになった。

この図をもとに、「DB統合後は求職者は全ての地域からスカウトを受け取れる」という機能になることを確認した。すると、スカウトの受け取れる範囲は求職者が設定できるようにしたいという要望が出てきた。

このように、要求を具現化するとそれに伴って発注者の要求実現後の世界に対する解像度も上がってくる。それによって新たな要求が出てくる。この繰り返しをいかに早く行えるかが要件定義の質を上げるコツだ。

１−５　要求を達成するために必要な機能を洗い出すスキル

要求を達成するために必要な機能を洗い出すスキルも必要だ。これはユースケースやユーザーストーリーなどを特定後、それを実現するための機能一覧を洗い出す際に必要になる。なぜなら、要求を漏れなく把握していたとしても、要件定義フェーズでそれに必要な機能の一覧が洗い出せていないとその後の工程で手戻りが発生するからだ。

例えば、１−１で取り上げた求人サービスの統合案件の例を挙げよう。この求人サービスの統合案件では、DBの統合が要求として挙げられていたことは述べた。さらに、前の章でDB統合後に「求職者がスカウトを受け取れる範囲を決定できる」という要求が新たに出てきたことも述べた。

この時スケジュールの関係で、リリース直後の状態では、上記の要求を満たすために「スカウトの受け取れる範囲＝元々の登録地域」に決めうちすることが大枠合意された。この要件を実現するためのデータ構造と該当箇所の作成タイミングなどを整理するために、以下のER図とCRUDマトリクスを作成した。

すると、以下の重要なことがわかった。
・既存の求職者データに関しては特別な機能が必要ないが、統合後に新規登録される求職者ユーザに関しては地域と紐づける機能が必要である

２論理的に物事を整理するスキルをつける方法

この章では要件定義に必須の「論理的に物事を整理するスキル」を身につける方法を紹介する。

具体的には、要素を正確に分解する癖をつけることだ。そのためにはロジックツリーを作成し、レビューしてもらうことが重要だ。

例えば、以下のロジックツリーは「なぜ要件定義スキルは上げづらいか」を分解したものだ。ここでのポイントは、各要素のテキストを長くしすぎないことと、同じ階層でMECE（漏れなくダブりなく）の状態が表現できていることだ。

例えば以下の画像は各要素をの文章を長くした例だ。内容的には、先ほどの画像と変わらない。しかし、途端にわかりづらくなる。また同じ階層でのMECE状態も確認しづらい。そのため、品質の高い分解ができなくなる可能性が高くなる。

３ビジネスの数字を理解するスキルをつける方法

この章では要件定義に必須の「ビジネスの数字を理解するスキル」を身につける方法を紹介する。

ビジネスの数字を理解するためにはKPIツリーを理解することと、自分でも作成しレビューしてもらうことが必要だ。

KPIツリーが理解できるとどの数字とどの数字が関連しているのかがわかる。また、KPIツリーに正解はないため自分で作成する過程で様々な観点を得ることができる。

例えば、家族を対象にしたECサイトがあるとする。以下に、２種類のKPIツリーを用意した。両方とも間違いではないが、用途が異なる。1枚目は家族の購入率やアクティブな家族数を議論する際に使えて、2枚目は商品ごとの売り上げや商品ごとの「家族の商品購入数」や「ユニークな商品購入家族数」をメインで議論する際に使える。