ImpactMappingの感想～アジャイル開発が主流の時代のライトウェイトな要件定義手法

ImpactMappingの感想をメモ。
僕の感覚では、ImpactMappingはペルソナ分析に似ている。

【元ネタ】
「IMPACT MAPPING」まとめ　その２ - @izumii19のブログ　You play with the cards you’re dealt

「IMPACT MAPPING」読みました - Yasuo's Notebook

文化の違う者同士が言葉を交わすために：無心に仕様書と戦う生活は終わりにしたい - ＠IT

アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか

NUCON に参加しました！：An Agile Way：ITmedia オルタナティブ・ブログ

デブサミで、『インパクトマッピング』のお話をしました！：An Agile Way：ITmedia オルタナティブ・ブログ

アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか

Impact Mapping from Kenji Hiranabe

【1】ImpactMappingの背景

文化の違う者同士が言葉を交わすために：無心に仕様書と戦う生活は終わりにしたい - ＠ITの記事が分かりやすい。

(引用開始)
開発現場では、しばしば指示された機能を作る際に「この機能は何のために作るのか」「どのように使うのか」という闇に覆われ、ただただ無心に仕様書と戦わなければならないことがある。
このような状況に陥ると、制作物に魂を込めることが難しくなる他、精神衛生上も良くない。
一方、指示する側の人間からすれば「なぜ、やってほしいことが伝わらないのだろう」となる。こうして、両者の間に距離が生じ始めるのだ。

平鍋氏は、このようなすれ違いを軽減するために、「IMPACT MAPPING（インパクトマッピング）」という手法を提案する。
IMPACT MAPPINGとは、マインドマップを使ってビジネス視点、技術者視点、デザイナー視点など、異なる視点を持つ人同士の対話を手助けし、「ビジネスの目的」を共有できるようにするものだ。
イベントでは、平鍋氏自らが運営するツール「astah*」の有償ユーザー数増加施策を用いてIMPACT MAPPINGの使用例を紹介。
(引用終了)

従来の要件定義では、大量のドキュメントを要件定義書として残し、開発チームに渡す。
しかし、その大量の要件定義書を元に、開発チームは全体像を理解し、システムの実現可能性を調査し、システムの詳細仕様へ落とさなければならない。
しかも、途中の工程で仕様変更が起きるのは普通だから、どんどん要件定義書が変わってしまい、膨大な要件をコントロールするのは難しくなる。

本番リリース時には、プロジェクト初期に作られた要件定義書とかけ離れたシステムになっているのが普通だろう。
そんな風景を開発者は何度も経験しているから、要件定義書を誰も読まなくなり、単なるキングファイルとして飾られる。

アジャイル開発では、ロードマップを元に、バックログからストーリーを順に実装して、順次リリースしていく。
要件は粒度の小さいストーリーに分割されており、バックログで優先順位付けされている。
ストーリーの優先順位は、ロードマップに従っている。
ロードマップは、プロダクトオーナーが決めた戦略方針に基づいている。

そのような仕組みがあるからこそ、アジャイル開発では、要件定義書は必要最低限でよく、必要な時に必要なだけ作る。
そのために、要件定義の作成プロセスは各スプリントに分散され、プロジェクト初期だけとは限らない。

しかし、要件定義の重要性がなくなったわけではない。
アジャイル開発においても、なぜ、そのストーリーを実装するのか、という理由は、開発チームになかなか伝わらない。
だから、本来のシステムとは違った機能として実装されるリスクはアジャイル開発でもある。
但し、アジャイル開発では、スプリントが終わるたびに利害関係者がデモで評価するので、早めにリスクを検知して、大きな失敗を回避することはできる。

【2】ImpactMappingの手法

ImpactMappingは、マインドマップを使った要件定義手法。
ビジネスの目標をアクター(システム利用者)の利用シーンを明確にすることで、本来のストーリーの存在意義を開発者に伝えようとする。

ImpactMappingで書かれるマインドマップの要素には、以下がある。

ゴール(Goal)：ビジネスの目標
アクター(Actor)：システムの利用者
行動(Impact)：システムの利用者に期待する行動
成果物(Delivery)：利用者の行動を促すシステムの機能

「機能ではなくビジネスゴールをデリバリする」という意味は、「システムを導入するだけではなく、ユーザにビジネス価値を届ける」事だと思う。
システムの機能は、ユーザにある場面でこう使って欲しいという「利用シーン」を提供している。
つまり、機能の背後には、ユーザがいる。

ここで、システムの機能は、全てのユーザが使うわけではないし、特定のユーザがシステムを使う場面(利用シーン)の一つにすぎない。
そのユーザの利用シーンを開発者に意識させてくれる。

利用シーンを開発者が意識すれば、こんなユーザインターフェイスがいいだろうという発想につながって、ユーザビリティや性能要件の改善にもつながるだろう。
また、利用シーンを受入テストのシナリオにマッピングすれば、受入テストの精度も高くなる。

Twitter / akipii:@hiranabeさんのImpactMappingの使い方が参考になる。製品よりも製品を使うユーザ、ユーザの利用状況を開発者に伝えるわけか。文化の違う者同士が言葉を交わすために：無心に仕様書と戦う生活は終わりにしたい - @IT http://www.atmarkit.co.jp/ait/articles/1402/27/news021.html

平鍋さんのImpactMappingの例がとても分かりやすい。

・ゴール：astah*の海外有償ユーザーの増加

・アクター：利用ユーザー、TDM（テクニカルディ シジョンメーカー：CTO）、Rock Star(人前で話をする人)、マスメディア、販社、大学の先生、ソリューソンパートナー、広告代理店

・行動(Impact)：
　→ユーザ：プラグインや評価レポートを書いてもらう、SNSでシェアしてもらう
　　TDM(CTO)：成功事例を公表してもらう
　　Rock Star：テンションを高めるためにプレゼンで製品を紹介してもらう

・成果物：(略)

【3】ImpactMappingの効果

ImpactMappingで解決できる要件定義プロセスの問題は以下になる。

1・スコープクリープ(スコープの肥大化)
2・誤ったソリューション
3・誰かの好みで追加した機能
4・誤った仮説
5・場当たり的な優先付け

【4】ImpactMappingの感想

ビジネスに結びつける要件定義手法は、ImpactMapping以外にも、ビジネスモデル・ジェネレーション、リーンスタートアップなど、色々ある。
それらの中で、ImpactMappingが優れていると思う点は、具体的ですぐに使えることだ。

僕の感覚としては、ImpactMappingはペルソナ分析に似ている。
つまり、業務システムやWebサービスを使うユーザをペルソナとして想定し、ペルソナが使う利用状況をシナリオとして作り、そのシナリオを実現するような機能をシステムで提供する。

ペルソナ分析は以前から知られた手法だったが、ImpactMappingはマインドマップを使うことで、作成する敷居を大幅に下げている。
マインドマップを普段から使っている人なら、そんなにギャップを感じずにやれるだろう。

但し、ImpactMappingが要件定義の全ての問題を解決するわけではない。
平鍋さんが書かれた絵を見ると、ImpactMappingの立ち位置が垣間見える。

Twitter / hiranabe: マーケや企画と開発を繋ぐ手法っていろいろあるなぁ、Impact Mapping, User Story Mapping, Kano Model, 要求開発、と並べてみた。 pic.twitter.com/qMki8tjFPT

また、アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのかの記事にも、平鍋さんが、要件定義と成果物(システム、ソース)の間のギャップを埋めるために、どんな仕組みや手法が必要なのか、をラフなイメージ図で提示している。

平鍋さんの下記のTwitterも興味深い。

Twitter / hiranabe: 僕はこの10年間アジャイルとモデリングを押してきたが、両方ソフトウェア開発の本質を突いてると(自分では)思っている。今年は、この二つが結びついた形を探索したい。「コミュニケーションデザイン」としてのソフトウェア開発。

僕も、平鍋さんのやっている事に興味があるし、追いかけてみたいと思う。

【参考】

Modeling in the Agile Age from Kenji Hiranabe