こんにちは。アイレット デザイン事業部でディレクターをしている ivanov です。

前回の記事で「仕様駆動開発2.0」の本を読んだ感想を紹介しました。『仕様駆動開発』を効率的に進めるためには「ビジネス価値の最大化」という観点が必要なため、開発する機能の優先度を判断する場面も自ずと多くなるのではないかと思います。

先日、「ビジネス価値の最大化」観点で優先度を可視化する手法として「Impact Mapping（インパクト・マッピング）」があることを知りました。『IMPACT MAPPING』という本があったので、早速読んでみました。内容を紹介させてください。

素晴らしいものを作っているはずなのに、期待した成果につながらないのは何故か？

この問題の根本原因は技術的な問題ではなく、「そもそも何を作るべきなのか？」というビジネスの戦略的な羅針盤が狂ってしまっているという問題です。機能をリリースすることを目的とせず、ビジネスやユーザーに測定可能な良い影響を与えることを目的とすることで顧客満足度が高いアウトプットを続ける。それで、この問題は改善されます。

「アウトプット ≒ アウトカム」となるようにするにはどうすれば良いのか？その問いを解決するために「Impact Mapping」という手法があります。

インパクトマップとは？

インパクトマップは、スコープとその背景にある仮説を視覚化したマップのことです。これは、技術側、ビジネス側のエキスパートが共同で作るマインドマップと言えます。以下の4つの質問に答えることで発想を広げていきます。

  • 何故（Why）？
  • 誰が（Who）？
  • どのように（How）？
  • 何を（What）？

Why？（何故？）

Goal

インパクトマップの中心に最も重要な

  • 「私たちは何故、これをやっているのか？」

の質問への答えを書きます。この問いへの答えが、達成すべきゴールとなります。

Who？（誰が？）

Actor

インパクトマップの第1階層には

  • 「私たちは、誰の行動にインパクトを与えたいのか？」
  • 「期待通りの効果を生み出せるのは誰か？」
  • 「それを妨げる可能性がある人は誰か？」
  • 「サービスの顧客、ユーザーは誰か？」
  • 「インパクトを受けるのは誰か？」

のそれぞれの質問への答えを書きます。これらの問いへの答えが、プロジェクトの成功を左右するアクターとなります。

How？（どのように？）

Impacts

インパクトマップの第2階層には

  • 「アクターの行動はどう変わるべきか？」
  • 「アクターは、私たちのゴールの達成にどのような貢献ができるか？」
  • 「アクターは、私たちのゴールの達成にどのような障害となり得るか？」

のそれぞれの質問への答えを書きます。これらの問いへの答えが、私たちが作り出そうとしている「インパクト」です。

What？（何を？）

Deliverables

インパクトマップの第3階層には

  • 「私たちは組織、そして、デリバリーチームとして、これらのインパクトを達成するために何ができるか？」

の質問への答えを書きます。この問いへの答えが、作るべき「成果物」となり、ソフトウェアの機能や組織の活動を意味します。

何故インパクトマップを作成するのか？

現在の開発計画や要件定義書には、機能（成果物）のみをリストアップしたものが多く、それが「何故必要なのか？」を説明する背景がありません。ビジネスゴールと成果物への関連付けと、その背景の説明がなければ、各機能への投資判断が難しくなります（その機能をコストをかけてまで作る必要があるのか否か）。

背景の説明がないと、さまざまな人の嗜好やアイデアが盛り込まれ、作ろうとしているソフトウェアやサービスが肥大化し、ユーザーに伝えるべき本来の価値がぼやけてしまいます。また、様々なアイデアが盛り込まれた結果、開発も当初の予定から遅延します。

ちなみに、インパクトマップを用いず、ファンクショナリティ・マトリクスを作成するという方法もありますが、インパクトマップの方が直感的に「ゴールとのつながり」を理解することができます。インパクトマップを用いて議論した後にファンクショナリティ・マトリクスを作成すると作業がスムーズにつながると思います。

インパクトマップの役割

インパクトマップはビジネスにおける仮説を表現し、伝達したり、ソフトウェアやサービスの開発において、計画作りとステークホルダーとの合意にも使えます。また、デザインチーム＆開発チーム内での、ビジネスへのインパクトに対する理解を深めることで、リリースするソフトウェアやサービスのクオリティを上げることができます。

こんな時におすすめ

  • アジャイル開発を行うにあたって、どんな機能から作っていけば良いのかわからない。
  • 開発する機能のスコープを絞る際に、どの機能を優先すれば良いのかわからない。
    • 開発を行うにあたって、要求される機能が多すぎてスケジュールから溢れる。
    • 開発を行うにあたって、要求される機能が多すぎて予算に対して工数が溢れる。

例

社内システムリニューアル（※架空のシステム）

インパクトマップの例