ottijp blog

「IMPACT MAPPING」を読んだメモ

ゴイコ・アジッチ著「IMPACT MAPPING」を読んだメモです.

ここでは,デリバリ=成果物,デリバリチーム=開発チームと読み替えています.

cf .IMPACT MAPPING インパクトのあるソフトウェアを作る | Gojko Adzic, ゴイコ・アジッチ, 平鍋 健児, 上馬 里美 |本 | 通販 | Amazon

インパクトマップとはなにか

  • ゴールを中心に,スコープと仮説を視覚化したツリーマップ
  • Why(ゴール)を中心に,Who(アクタ)/How(インパクト)/What(成果物・機能)を枝葉が広がるようにデザインする
  • 誰(Who)が何をもって(What),どんなインパクト(プラスもマイナスも)(How)をゴール(Why)に与えるかを表現する
  • GitHubで公開されているワークショップ用のチャートシートが良いリファレンス

impactmapping.org

インパクトマップの役割と効果

ゴールと仮設の明確化

  • ビジネスゴールと機能・スコープ・ロードマップを紐付ける
  • アジャイル開発が「予算がなくなるまで間違いを直し続ける」ことにならぬよう,仮説(成果物とインパクトの検証,インパクトとゴールの検証)の認識を共有できる
  • 開発チームには良いロードマップを,ビジネススポンサには全体像を与える
  • 検証する仮説の選択と優先度設定が的確にできる
  • 不完全なアジャイルが及ぼす悪影響を改善する
    • ビジネスと開発が分断された”ウォーター・スクラム・フォール”
    • これはBIG PICTUREの不在が原因

多くのチームはすばやい変更を優先するあまりBIG PICTUREを犠牲にして、プロジェクトを導いている。これはまるで暗いトンネルの中で、どこに向かっているかはわからないまま、落ちないように一歩一歩小さく進んでいるようだ。

無駄を排除し価値を速く生む

  • ストーリカード地獄(プロジェクトの開始時点で,成果物に必要な膨大な数のユーザストーリを作成してしまうこと)防ぎ,現状に適切な量・表現のユーザストーリを導出できる
  • インパクトマップのWho/How/Whatがそのままユーザストーリになるので,ユーザストーリの必要性がインパクトマップから判断できる
  • リーンのWIPを最小化する原則を実現する

導入しやすい

  • 記法が単純で,ステークホルダ全員が理解しやすく書きやすい

副次的効果(インパクトマップを書くだけではなくて,マインドセットも必要だと思う)

  • 効果的な会議
    • ビジュアル化による理解力・思考力・創造力の向上
    • インセプションデッキのような,立ち位置や目指す先の共有による議論の軸の確立
  • コストから投資への議論
    • 成果物のコストではなく,それがもたらす成果や利益への焦点の移動

インパクトマップのつくりかたのコツ

  • 「顧客に満足感を与える」ことだけを測るメトリクスは無価値なので,「行動につながる」メトリクスに焦点を当てること
  • 打ち合わせは2部制がよい
    • ビジネスゴールとメトリクスを設定する会
    • インパクトマップを作成する会
  • ビジネスマネージャは機能ではなくビジネスゴールを語るべし
    • 機能要求から始まった場合は,なぜなぜを繰り返しゴールを問う
  • ビジネスゴールは計測可能にする
    • SMARTを満たすこと
    • Measure
      • scale: 測定するものはなにか
      • meter: どう計測するか
      • benchmark: 現状はどうか
      • constraint: 許容値,損益分岐点
      • target:
    求められる価値
  • メトリクスは追跡しやすさではなく価値あるものを選ぶ
  • メトリクスを測定し,継続やピボットの判断を行うタイミングを定期的に作る
  • 複数の測定値を持つものはマイルストーンを分けて考えてみる

所感

  • かなりコンパクトにまとまっていて(100ページ未満)で短時間で読めるため,本の全体感を認識しながら読み切れた
  • それぞれの項目ごとにポイントが記述されているので,実際にインパクトマッピングをする際にリファレンスとして活用しやすい
  • 考え方はゴール志向要求分析や匠Methodに通じる部分が多いなと感じた
    • ビジネスと開発の分断を防ぐ方法論
    • What/Howだけだと失敗する
    • Start from Why
      • サイモン・シネックのゴールデンサークルに則っている考え方
    • システム開発だけアジャイルでも,ゴールやステークホルダと結びつかないので,ビジネスを含めアジャイルであるようにするための方法論
  • アジャイルであっても,知識体系のどの領域をカバーする議論なのかを意識することが有用に感じたのでPMBOKとかちゃんと勉強しようと思った
    • たとえばインパクトマップのWhy/WhoはPMBOKの計画プロセスにおけるプロジェクト憲章・ステークホルダ管理の概念
  • 「成果物の目的は,アクターの行動変化だということへの合意」という部分が,先日のYahoo! JAPAN Tech Conference 2019でCTO藤門さんが言っていた「ユーザの行動を変える」に通じるものを感じた
  • 本の最後の方にある「典型的な会議づくりに関する誤り」「典型的なファシリテーションの誤り」はインパクトマップ関係なく,仕事をする上でとても重要で参考になった

ottijp
都内でアプリケーションエンジニアをしています
© 2024, ottijp