失敗しない機能要求洗い出しのコツ
機能要求の洗い出しに失敗しないコツを3つ、お伝えする。
1つめは、アクティビティ一覧同様、関係者全員が要求の全体感と個別具体性を行ったり来たりしながら中身を議論できるようなフォーマットで記述していく、ということである。「なるほど、そんな機能があるととても業務の効率が上がりそうだ」「だとしたら、こういうものも必要じゃない？」「いいですね！ では追加しましょう」といった議論を誘発するようなフォーマットが一番である。お勧めは「ファンクショナリティ・マトリクス（通称FM）」である。エクセルの一覧表で、縦軸に機能グループ、横に機能名を記述していく。
FMのよいところは、その視認性の高さである。将来のITの構造を機能グループのレベルで把握でき、それぞれの機能グループに対して機能要求を横並びで確認することができる。もちろん、FMは本質的には機能要求一覧なので、マトリクス形式ではなく一覧形式で書いても、果たすべき役割は変わらない（縦に長くなるので視認性は落ちるが）。機能要求の全体像を眺めながら関係者間で将来のITを構想するためのコミュニケーションツールとして成立していることが、極めて重要である。なお、さすがにFMだけでは各機能要求のディテールがわかりづらいので、別途、機能要求名とその概要を記した機能詳細一覧を作成する。
2つめは「あったらうれしいけど、なくても困らないかな」という機能要求もとりあえず入れておこう、ということである。FMの本質は「機能要求に優先順位をつける」こと、もっとハッキリいえば「要らない要求」を決めることにある。様々な関係者が積み上げた機能要求をすべて網羅したSaaSはない。仮に様々なSaaSを組み合わせればいけそうだ、となっても、当初のX倍の予算がかかるとなれば、何かを捨てなければならない。FMの優先順位付けは、そうなったときに議論が平行線にならないようにするための布石である。「それならば、最初から機能要求なんか作らなければいいのでは」と思われるかもしれないが、要求をすべて出し切って優先順位をつけるプロセスを経ておけば、IT導入後に「本当はこんな機能が欲しかった」「自分の希望が聞いてもらえなかった」という事態を防ぐことができる。優先順位付けはしばしば苦渋の決断になるのだが、ここにも関係者を納得させられる作法があり、次回の連載で詳しく述べる。なお、要求を出し切るにあたり、アクティビティ一覧以外にも以下のような情報も役に立つ。アクティビティ一覧のブラッシュアップにつながるものもあるかもしれない。使えるものはなんでも使おう。
- レビューサイトなどに載っている主要なツールのWebサイト、パンフレットなど
- 既存ユーザーのアドバイス（ベンダーに依頼すれば引き合わせてくれるし、弊社に気軽に相談いただいても構わない）
- トレンド書籍
- 社内で使っているITの全体図（既存システムの中に連携が必要なものがないか、見極めたりする）
3つめは、要求の優先順位を判断できる粒度で書こう、ということである。先にも述べたとおり、FMは機能要求を「全部乗せ」したものであり、かつ「欲しい順」をつけたものである。これに照らし合わせると、FMの粒度は以下となるべきだ。
- 議論の余地のない要求は、粗い粒度で記述する。
- 議論しないと要否の判断がつかない要求は、その議論に必要な粒度で記述する。
「議論の余地のない要求」とは「どの企業でも業務が変わらない、そして同じ領域のツールであればスペックが横並びであるような要求」である。例えば、MA（マーケティング・オートメーション）で言えば、顧客へのメルマガ配信機能をFMに書く場合は「メルマガ配信」とだけ記せばよいだろう。「配信先の抽出」「配信内容の記述」「配信日時の事前設定」など、メルマガ配信に必要な機能は当然搭載していると考えてよく、議論のためにわざわざ記述を分割する必要はない。例えば「配信内容の記述」をHTMLとテキストで別個に行いたい、といった個別の要求（これもどんなツールでもできることだろう）は、機能詳細一覧に記載することになる。
「議論しないと要否の判断がつかない要求」とは、自分たちのビジネスや顧客の特性を織り込んだ要求のことである。例えば、MAは様々な外部システムと連携させて使うことができるが、将来の業務を実のあるものにするためにどのような連携が必要か、は、企業により事情が異なるため、具体的な連携イメージを積み上げながら、丁寧な議論が必要となる。自社アプリを運営する企業であれば、アプリとMAの連携範囲を想像してみてほしい。ユーザーマスタを同期するだけでよい、アプリ内のユーザー行動をMAに取り込みアプリのコンテンツを出し分けしたい、など運営するアプリによって様々な連携の形が考えられ、開発や運用のコストもそれぞれ異なる。これらをひとまとめに「アプリ連携」とだけFMに記述してしまうと、「将来のビジネスのためにも、ここまでは必ず欲しい」「開発や運用のコストがバカにならなそうなので、いったんこの部分はあきらめよう」といった重要な意思決定をするための議論ができなくなる。この場合は「アプリ連携」という機能グループの中に、具体的な連携イメージを「議論したい粒度」でひとつひとつ書いていくのが妥当だろう。
このように、FMは決して一様な粒度で記述するものではない、ということが極めて重要である。
