「IMPACT MAPPING」まとめ　その３

本のレビュー

「IMPACT MAPPING」まとめその３です。最終章になります。
インパクトマップを実際に書いてみます！

インパクトマップを書く

マップのゴールを設定する

    • ビジネスゴールを設定する
    • ゴールがすぐ見つからない場合、リーンの「５回のなぜ」を使ってみよう
    • ゴールの測定値の立て方に有効な５つの項目
      • 測定するもの(スケール)
      • どう測定するか(メーター)
      • 現状はどうか(ベンチマーク)
      • 受け入れられる最小値(制約)
      • 求められる価値(ターゲット)
  • 骨組みを書く
    • ○○(誰)が、○○(行動)を○○(行動変化)することでゴールの達成に貢献できる

  • 代替案を見つける
    • このアクター達は他に何ができるか
    • 他に協力できるアクターはいるか
    • 私達を邪魔するアクターはだれか
  • 優先事項を決定する
    • ゴール達成を妨げる可能性は何か
    • 容易に達成できる高価値なインパクトはなにか
    • 検証すべき重要な仮説は何か
    • ドットシール

  • 検証された仮説または学習予算で説明がつくように成果物のマップを成長させる

というわけで、まずは本に載っているマップを写経しながら理解してみました。
ビジネスゴールは「ゲームのプレイヤー100万人達成」です。それを達成するために私たちは今ここにいます。続いて、ビジネスゴール達成の為に誰にインパクトを与えるか、どんなインパクトを与えるか、その為に機能として何が必要かをブランチを切って書いていきます。同時に代替え案を考えることで他のアクターも登場し、そのアクターに与えるインパクト、機能・・・というようにブランチがだんだん広がっていきます。
こうやって書くと「ゴール」と「機能」は「アクター」と「インパクト」によって繋がっているのがわかりますね。ビジネスゴールに対して機能をマッピングしているわけです。ここがイテレーティブなんですね！
インパクトマップってよくできてるなーと思いました。

おわりに

  • インパクトマップは、マインドマップをつかったビジネスゴールと機能を結ぶロードマップ
  • ビジネスゴール=「私達はなぜここにいるのか」
  • インパクト=誰かの行動を「どう変えたいのか」
  • 反復型デリバリではインクリメンタルではなくイテレーティブに行うことでビジネスの全体像をイメージできるように保つ
  • 機能ではなくビジネスゴールをデリバリする

開発部門と他の部門でもきちんとビジネスゴールを共有できれば、違う視点からひとつのビジネスゴールに向けて協力し合えるということを今回しっかり学んだ気がします。
アジャイル開発は開発チームだけのものではないし、ビジネスゴールは部門にかかわらずひとつであるべきだと思いました(というか、１つになるようなゴールを設定する)。
今回平鍋さんから献本していただいたのがきっかけでこのようなことを勉強する機会ができたことに大変感謝いたします。
どうもありがとうございました。

お知らせ

札幌のジュンク堂にて、訳者の平鍋健児さんと上馬里美さんが書いてくださった「IMPACT MAPPING」の直筆のPOPを置かせていただく予定です。
「IMPACT MAPPING」をお探しの際はこちらのPOPを目印にしていただくとすぐ見つかる(はず)です！

Scrum Boot Camp The Book 読書会 in 札幌 3

イベント・勉強会

Scrum Boot Camp The Book 読書会 in 札幌 3 に参加してきました。
1回目と2回目は都合がつかず３回目からの参戦でしたが、途中参加のハンデを感じさせない雰囲気の良さでした！

読書会は輪読方式で進めますが、「漫画パートどうするんだろう？」って思ってたら漫画パートもちゃんど音読しました。面白かった。

アジャイル開発のきっかけ

  • 自分の場合は開発のきっかけはない。入ったらそこがアジャイル開発だった
    • 数年ブランクあってからの復職だったので、特に違和感もなく抵抗もなく。
  • トップダウンか、ボトムアップか
    • 本書ではトップダウンの設定だが、実際には圧倒的にボトムアップの方が多い予感
    • できるところから始めることができるけど、開発チーム内で限界を迎える場合が多い
    • お客さんを巻き込むところまで到達しない
    • ボトムアップには限界がある

ロールを現場に当てはめる 「プロダクトオーナーは誰だ？」

  • 熱意を持った人にやってもらう
  • ロールはただの目印
    • でも責任の所在はハッキリとする(プロダクトの品質に対する責任はPO、チームに関する責任はSM)
  • POとSMの兼任は？
    • 本来は思惑が相反するロール。兼任しても良いの？
      • チーム全体が熟練してればできるかもしれないけど、そうじゃなければPO(=SM)とメンバーで温度差がでてきそう
      • 兼任すると、その人一人の中で落としどころを見つけちゃいそう
        • 兼任していなければPO=100%、SM=100%の気持ちで出し合った意見がぶつかる
        • PO,SM兼任だと、その人の中で落としどころを見つけちゃうので100％の気持ちがでてくることがないのでは
        • 最初はきちんとわけてやるのが良いような気がする
      • そういえばちゃんとロールについて合意しないまま始めた感・・・
        • したほうがいい気がする。大事な事かも。

プロジェクトを理解する 「どんなプロジェクト？」

  • インセプションデッキ
    • ゴールを理解する　-> エレベータピッチ
    • ミッションを理解する　-> 我々は何故ここにいるのか
  • エレベータピッチ=本当にゴールなのか？
    • これだとこの製品を開発することがゴールになる
    • 本当のゴールはこの製品を使うことで、利用者の行動を変えることじゃない？
      • ゴールには最終ゴールの他に、通過点ごとに設定したゴールがあって、エレベータピッチは通過点ゴールの方を指しているのかな
  • ゴール：目標
  • ミッション：任務
  • 全員で合意する
    • 全員で合意しても、違うメンバーが入ってきたら全員での合意が全員での合意ではなくなる
    • 途中参戦メンバにもきちんと合意してもらう
    • 差をどう埋めるか
      • 気持ち
      • 知識
      • 熱意
    • 付箋をうまく利用
      • 手強い質問をしやすくなる
      • 最初は「○個書くこと」ってしたら質問を引き出せるかも

読書会全体を通して

  • アイスブレイク「今年の一文字」
    • 「素」
      • いろんな意味で素直に生きる。自分の考え、自分の気持ちに素直に行動したい。自分の人生だし。
  • 前鼻さんの進め方うまいと思った
    • テンポよく進めてる！無駄な時間がない
  • ふせんに気づいたことを書いていく
    • 自分の意見を出しやすい
    • 自分が読んでいるときは読むのに夢中で書けない
  • 本に書いてあることからも、他の人からも学ぶことができて良い
    • 現場でのもやもやのヒントをもらえた

ちなみに主催者さんが書いた読書会のまとめはこちらにあがっておりますよ！

「IMPACT MAPPING」まとめ　その２

本のレビュー

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

インパクトマップの役割

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

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

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

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

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

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

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

測定できる目標

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

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

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

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

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

「IMPACT MAPPING」まとめ　その１

本のレビュー

チェンジビジョンの平鍋さんから「IMPACT MAPPING」を献本していただきました。
平鍋さん、ありがとうございます！
まとめようと思いましたが、思った以上に書いておきたいことが増えてしまったので２〜３回に分けてまとめることにしました。

まえがき

  • 異なる部門間においても、同じ問題について話ができるということがなぜ大切か
    • 違う部門間でのコミュニケーションは本来難しい
      • 異なる視点、使っている言葉の違いがある
    • コミュニケーション不全は間違ったものを生み出す原因になりうる
    • 本来必要なのは協力して問題に取り組む事、異なる部門の視点から貢献しようとすること
    • ⇒その為に同じ問題について話ができるということが重要
  • 今の時代こそ、考え方の転換期である
    • プッシュ型からプル型へ
    • 指示型コントロールから適応型コントロールへ
    • 目的達成の為に、より良い方法を自ら模索していく時代

ソフトウェアはペーパレスの為のひとつの手段であった時代から、ソフトウェア自体がビジネス価値を生み出す存在へと変化しました。
ビジネス価値を高めるためには、今市場で何が求められているのかということを私達は常に考え続ける必要があります。
その為にはいろんな部門がそれぞれの視点や知識を生かして協力し、素早く価値を生み出すという体制が不可欠です。
"素早く"大事！冷めた料理なんて誰も欲しがらない。
素早く価値を生み出す為には、異なる部門間が協力しあい、共通の認識をもって同じゴールを目指す必要があります。
インパクトマップはその手助けをしてくれる心強い手法です。

インパクトマップ

  • インパクトマップを構成する４つの要素
    • なぜ(WHY?)
    • 誰が(WHO?)
    • どのように(HOW?)
    • 何を(WHAT?)

インパクトマップの役割

    • ビジネスにおける仮説を表現し、伝達する
    • 反復型デリバリにおいて計画作りとステークスホルダとの合意にも使える

なぜ(WHY?)=【GOAL】

  • 「私達はなぜこうしているのか」の問への答え=GOAL
  • インパクトマップの中心に書く
  • なぜそれが役に立つのかを説明する
  • ゴールをしっかり知っておくことは、プロジェクトの計画が変更になった場合においてより良い判断のカギとなる
  • より良いゴールは「SMART」
    • Specific = 具体的
    • Measurable = 測定可能
    • Action-oriented = アクション指向
    • Realistic = 現実的
    • Timely = タイムリー

誰が(WHO?)=【ACTORS】

  • 「私達は誰にインパクトを与えたいのか」
  • 「期待通りに効果を生み出せるのは誰か」
  • 「それを妨げる可能性のある人は誰か」etc...
  • インパクトマップの最初の階層に書く
  • 品質=「誰かにとっての価値」価値を届ける相手は誰か？

どのように(HOW?)=【IMPACTS】

  • 「アクターの行動はどう変わるべきか？」
  • インパクトマップの２つ目の階層に書く
  • 顧客の望むサービスではなく、彼らが片づけたい仕事について理解し、支援する
  • アクターの行動の「望まれる変化」を考える

何を(WHAT?)=【DELIVERABLES(成果物)】

  • 「私達は組織、チームとしてこれらのインパクトを達成するために何ができるか」
  • インパクトマップの３つ目の階層に書く
  • ひとつひとつの機能には「なぜそれが必要なのか」の理由が存在するはず
  • 成果物はインパクトマップの中でもっとも重要性が低い

まず最終ゴール(=目的)が定めて、それは誰の為の物なのか、それがあると何が変わるのか、その為に何が必要かと考えていくと何が成果物として必要かがだんだんと見えてきます。
そしてそれはゴールから遡って考えているので、できた機能がゴールを満たしていないなんてこともありません。
成果物が一番重要性が低いというのは、言い換えると別な形で実現可能な場合置き換えることができるということですね。
私達が提供するものは機能ではなく価値。おお、すごいアジャイルっぽい！

「怒らない禅の作法」を読んだのでまとめ　その1

枡野俊明さんの「怒らない禅の作法」を読みました。
枡野さんはアジャイルジャパン2013で登壇してくださったのですが、その時のお話しが素晴らしかったので禅の世界に興味を持ちました。

禅の心とは物事にとらわれず今この一瞬を大切に生きること。
禅には安らかな気持ちで毎日を送る為のヒントがたくさんあります。
この本では主に「怒らない人」になる為の「心」「体」「生活」について43個のヒントが書かれています。

長いので何度かにわけてまとめようと思います。

※この先はネタバレを含みます

続きを読む

娘達がポケットからティッシュを出してくれない話

さっき大量の洗濯物をしていたら、ポケットにティッシュが入っていたらしく洗濯物全部にくっついてしまったんです。
経験した人ならこれがどんなにイライラすることかわかるはず。
場合によっては洗濯しなおしなんて事も…。

何度注意しても同じことを繰り返す娘達に今日は爆弾を投下しました。
「どうして何度いってもティッシュをポケットから出してくれないの？」と私が怒ると2人は黙ったまま。
まぁ、答えはわかってるんだけど。

「忘れちゃうから」

なんだよね。

怒られた後１週間くらいは忘れない。
でも時間が経ったり、急いでいたり、他のことに気をとられていると忘れてしまう。
喉元すぎれば、ってやつですよ。
わざと約束を守らないわけでもないことも、もちろんわかってます。

いくら注意しても意識しても状況によっては忘れてしまう事ってあるんです、大人も。
「忘れる」ってわざとできることではないと思うんですね。
忘れるってことは、もうその時すでに忘れているんだから無意識に近いというか(後から何かのきっかけで思い出すことはあったとしても)
つまり、忘れるっていうのはある程度仕方がないことだと思ってるわけです(特に子供の場合)

ではどうしたらポケットからティッシュを出してから洗濯カゴに入れてくれるようになるんでしょう？

私が考えたのは「忘れてしまうのであれば「思い出すきっかけ」を多くする」ことです。
忘れないようにするというのが無理なら思い出せるようにしたらいいんです。

具体的に何かというと

【子供達ができること】
・目に付くところにメモを貼っておく(脱衣所のドアとか、学校から帰ってきて最初に目につく居間のドア等)

これは無意識だったとしても目に入れば思い出せると思うからです。
(ただ慣れてくると素通りされてしまう場合もあり)

【私ができること】
・洗濯カゴの隣に「ティッシュ・ハンカチ入れBOX」を作る

ティッシュをポケットから出すという作業自体はとても簡単な事なので、洗濯ものを洗濯カゴに入れるタイミングでティッシュもティッシュ入れに入れてしまえばいいわけです。
「ティッシュ・ハンカチ入れBOX」を洗濯カゴの側に作っておけば、洗濯物を入れに来たとき必ず目に入ると思います。

・そもそもティッシュをポケットに入れることをやめる
入れるから出す作業が発生するわけで、入れるから見えなくなる訳なので入れなきゃいいんです。
よくあるポケットティッシュケースを服の外側に安全ピンやクリップで付けるようにすれば、ポケットに入れている時よりも目につくようになると思います。

こんなことを明日は子供と話してみようと思いました。

洗濯をする者にとっては「ティッシュを出さない人が悪い！」と思いがちですが(さっきまでそう思っていたし)、
今日の出来事で気づいたことは「改善しようと思ったらお互いが歩み寄って行動する」ということです。

子供には何度も言われないように改善してもらいたいし、私は子供達が思い出せる仕組みを作ってあげることができます。
子供を怒るということで得られる効果は所詮一時でしかないわけですから。

仕事をしていてもうまくいかないことがあるとその人に原因があるように思ってしまいますが、
その人自身が改善して行動することと、その人が改善して行動できるような仕組みや受け皿を用意してあげることが大切なんじゃないかなと思いました。

ちなみに子供の「忘れる」という能力はマイナスなことばかりではないんです。
子供は親に怒られたという嫌な記憶もちゃんと忘れていきます。
だから子供はいつまでも親を好きでいられるんだと思います。
もし、子供が「忘れる」ことができなくなったら親に怒られた記憶がどんどん蓄積されて良い関係でいられなくなるかもしれません。

こう考えると忘れん坊の子供達に救われているんだなーなんて思いました。
おしまい。

4月のふりかえり

GWもそろそろ終わります。というわけで４月のふりかえりです。

仕事

【Keep】

  • 業務でテスト設計ができた
    • 業務で一からテスト設計するというのが自分の中で初めての試みだったのでワクワクしながら取り組めた
    • 最初にユーザーストーリーを書いた
      • 私が、ただ書きたかった！(アジャイル札幌の打ち合わせでヒントを得て)
      • 何の為のテストなのか、何をする為のシステムなのかがブレてきた時に振り返るポイントにしたかったので
    • テスト設計する時の役割
      • テスト設計をする際には「このシステムを使う人」と、「このテストを通す人」の２つの帽子をかぶることが必要だったんじゃないか、もしかして。
      • 上手く帽子をかぶらないと、誰のためのなんのためのテスト設計なのかがブレてくるー
    • 初めてのことをやる時は自分の持っている少ない引出しに頼ってのスタートになる。自分なりのベストを尽くしたとしてもそれは成果物としては全然足りないことがある。
      • 他の人にレビューをしてもらうことで、気づきや材料を増やしていく
        • 少ない引出しの中身を少しでも増やす為に、普段から学ぶ姿勢を忘れない
        • 勉強会などはこれからもできるだけ参加したい
  • 平鍋さんのトークセッションに参加
    • 「アジャイル開発とスクラム」は、開発現場の現状と照らし合わせてなぜアジャイルが必要なのかが書かれている点がとても良い本。
      • イベントの時はまだ本を読んでいなかった…
      • やはりちゃんと読んでから参加した方が吸収が違うと思う。反省。。。
    • 平鍋さんと初飲みした！
      • 「子育て×アジャイル」みたいな話ができて楽しかった。
      • トークイベントも良いけれど、お酒を飲みながら肩の力を抜いた雰囲気でできる話はまた一味違って楽しかった。

【Problem】

  • 入社５年目に突入したけど、これから自分がやっていくべきことはなんだろう
    • ５年経っても「私これすごい得意だわー」とか「これ負けないわー」ってことが何もない気がする。
    • 特に技術力なんて５年たってもまだまだだと思う(５年前よりはできるようになったというレベル)
      • 何年たってもどんなポジションにいても学ぶ事をやめてしまったらだめだなぁ。
      • できる人からもっとたくさん盗むこと、自分の苦手なことにたくさん触れること。
    • アジャイルに対する考え方や、仕事をしていく上での姿勢みたいなものは自分の中でだいぶ土台ができてきた
    • これからはそういうものを人に伝えていきたい

【Try】

  • 今回のテスト設計をもっと進化させたい
    • 今回目指しているものはできたけど、あくまで土台に過ぎないのでもっと進化させていきたい
      • 誰でもテスト設計に関われるように
      • いろんなプロジェクトで使えるように
      • →やっぱり引出しを増やしていかなくちゃ。

【Happy】

  • やりたいと思っていたことをやれる場を与えてもらったことに感謝。
  • そして何度もレビューしてくれたメンバーに感謝。
  • テストに関する知識や勉強の場を与えてくれた人達に感謝。
  • 全部、自分一人ではできなかったこと。

プライベート

【Keep】

  • 次女入学
    • ちょっと甘えんぼなところがあるので心配だったけど、学校も児童会館も楽しく通ってくれていて安心
    • 長女５年生、やっぱり頼りになる。
    • 二人のおかげで、今月も特に困ったこともなく変わらずに仕事をすることができた。

【Problem】

  • お金がない！お金がない！
    • 新しいジャージ、入学写真、塾の年間テキスト代 etc
    • 固定資産税、車税
    • スマホ壊れた…→iPhoneに。ついでに長女の電話もかなり古かったので一緒に＆次女も念のため持たせるか、で結局３台。
    • 嵐のファンクラブ更新しないと！

【Try】

  • 節約
    • カードを使わない(ように頑張る)

【Happy】

  • 子供の成長に助けられている。楽になった分、自分はもっと違うことも頑張れるはず。
  • 長女と次女のダンスレッスンがかぶっている時に友達が協力してくれて嬉しかった。ありがとう。

全体

自分にとってアジャイルは開発に特化した手段ではなく、もちろん目的でもなく、人生を豊かにしていく姿勢のようなものだと思っているので、自分が子供に何か大切なことを伝えようとする時は、自分がアジャイルから学んだことを同じように伝えることが多いのです。
一緒に振り返ってみるとか。
一緒に見える化してみるとか。
例えば夏休みの宿題は、毎年必ずかんばんにタスクを貼ることから始めているんだけど、やっぱり最初はなんでこんなことするんだろう？って思っていたみたい。
でも、進み具合がわかることで何日までに終わりそうだから、○日は遊ぶ約束できそうだなとか、
「読書感想文を書く」というタスクはまず「本を選ぶ」「本を読む」「感想文を書く」の順番でやらないと終わらないなってのが、少しずつだけど本人の中で組み立てられるようになってきているように感じますな。
誰かが側にいて同じことを言わなくても「自分で」っていうのが一番の成果かな。
本人は「アジャイル」って言葉は全く知らないけれど、経験を通して暗黙知として蓄積されているのだなぁと。
というか、子供は難しい言葉やしくみを覚えることはできないから暗黙知として捉えることの方が自然と多いのかも。
なんか、子供を見ているといつも自分だけが停滞しているように思えてならない。
自分の成長ってあんまり自分じゃ感じられないのなー。
だからこそ、他の人に対しても「いいな」と感じた時にそれを伝えてあげるというのはとても大切なことなんだと感じました。