「IMPACT MAPPING」まとめ その2

「IMPACT MAPPING」まとめその2です

インパクトマップの役割

  • ビジネスにおける仮説を表現し伝達する
  • 反復型デリバリにおいての計画作りと、ステークホルダーとの合意にも使える
  • 3つの重要な役割
    • 戦略的プランニング
      • プロジェクト開始時点でビジネス側、開発側両方のエキスパートに参加してもらう(両方の視点からプランニングすることで全体的なビジョンのもとに協力体制を敷く)
      • インパクトマップを作ることで参加者全員の「集合知」を得る効果がある
    • 品質を定義する
      • 技術的な成果物が作り出すインパクトをビジネス視点から可視化する
      • 成果物の目的は、アクターへの行動変化
    • ロードマップ管理

ビジネスゴールとは「私達はなぜこうしているのか」という理由を先にあげた「SMART」な表現で表したもの。
それを開発側とビジネス側の両方で共有して、同じビジョンのもと協力して進めていく。
インセプションデッキの「エレベータピッチ」と「我々はなぜここにいるのか」をビジネス側、開発側両方の視点から考える感じかなぁ。
あら、ちょっと難しくなってきたなぁ。
どんなに要求通りに作った機能でも、使われなければアクターの行動変化にはつながらない。
アクターの行動変化につながるインパクトを生み出す為の仮説を立てるのがインパクトマップ。
あってる?

機能ではなくビジネスゴールをデリバリする

  • 米陸軍の研究によれば、指揮官から複数の小隊への指示内容が「何を」「どのように」だけだと、小隊は予期せぬ問題に対する準備が不十分になるという結果を示した
  • 「なぜ(WHY?)」と「注意すべき点」を説明することのほうが遥かに重要
  • プロジェクトを進める上での焦点は機能やタスクではなく「利用者の目的を果たすこと」

ソフトウェア開発って「ソフトウェアを開発」する仕事じゃなくて、アクターの生活や行動へもたらす変化をソフトウェアという技術を介して提供している仕事だと思う。
なので、ソフトウェアじゃなくてもやりたい事が実現できるのであれば、ソフトウェアじゃなくてもいいんだと思う。(けど、ソフトウェアは柔軟でいろんなことに対して実現性が高いので選ばれている、というか…)
もしそれを無理やり機能に当てはめてしまおうとするのなら、それは開発者側の間違ったビジネスゴールだと思う。
某運送会社のCMに「場所に届けるんじゃない、人に届けるんだ」ってのがありましたが
指定した住所に確かに届いたとしても、それが使いたい人のところに届かなければ価値はない。だからその人に届けるのが自分達の仕事だっていうメッセージが伝わってきて、とても良いなぁと思い印象に残っています。
そして、それを実現する為に再配達や追跡番号、届け日指定などがDELIVERABLES(成果物)として生まれたのですね。
素晴らしいなぁと思いました。
「機能ではなくビジネスゴールをデリバリする」ってこういうことだと思います。

インパクトマップが解決する問題

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

測定できる目標

  • ビジネスを成功させるには、目指すゴールが「正しい」ことを知る必要がある
  • 「SMART」手法で「測定可能」なゴールを設定
  • 正しいゴールを持つと、プロジェクトを正しい目的に合わせて進められる
  • 行動につながるメトリクスに焦点をあてる

反復型デリバリによる改良

  • ビジネスとデリバリが分断する要因
    • デリバリチームは繰り返しリリースするが、ビジネス観点から見たら小さすぎて価値を生まないことがある
  • インクリメンタルではなくイテレーティブに

アジャイル開発では「小さく早くリリースを繰り返す」事を意識してプロジェクトを遂行します。
でも私はその中身が「イテレーティブ」なのか「インクリメンタル」なのかまではこの本を読むまで意識したことがありませんでした。
「インクリメンタル」に反復するのか「イテレーティブ」に反復にするのかってすごく大事だなぁ。
「反復」の仕方が全然違う。
インクリメンタルはパズルで、イテレーティブは風景画。
風景画は全体像が見えていないと、できあがった時に全然違う絵になったりしますからね。
っていうかこのモナリザの例わかりやすすぎて衝撃的でした。

次回は実際にどうやってマップを書いたらよいかというところに入っていきます。