「アジャイルサムライ」を読みました

これも定番中の定番ですが、特にプロジェクトキックオフ時の取り組みに関してインセプションデッキを追求したくて、読もうと思いました。

アジャイルサムライ−達人開発者への道−

第3章 みんなをバスに乗せる

はい、インセプションデッキの章です。

今までも、プロジェクトの概要や目的を明文化するような取り組みとして、"インターナルプレスリリース"という取り組みを社内でやってきていました。これは、Amazon流の開発術では、まずプレスリリースを作る | fladdictに習って、先にプレスリリースを書いてみるというものです。ただ、インセプションデッキを試した後に気づいたことは、「インターナルプレスリリース作成前に、プロジェクトメンバーみんなで認識を合わせる場があったら、もっとよりよくできたのかもしれない」ということです。

インターナルプレスリリース

インターナルプレスリリースは、以下の流れで作成していました。

1. ある一人が、プロジェクトの概要をプレスリリースとして明文化する作業を行う
2. 明文化したものを、プロジェクト内外に共有する
3. フィードバックを受けて、ブラッシュアップする

インターナルプレスリリースの目的の一つに、「プロジェクト外の人に、プロジェクトの概要を周知するため」がありました。これは、会社が大きくなっていくにつれて、他のプロジェクトが何をやっているのかが分かりづらくなってきたという課題を解決するものです。インターナルプレスリリースによって、実際にプロジェクト外の人が該当のプロジェクトの概要を分かるようになりました。

ただ、インターナルプレスリリースを続けていくに従って、以下の点が問題点・改善できそうな点としてあがってきました。

• プロジェクトの概要を明文化するのは思いのほか難しく、一人で考えていると煮詰まってしまう
• プロジェクトメンバーでさえも、プレスリリースを眺めても深く入ってこない

上記の課題に、インセプションデッキ作成はぴったりはまりました*1。プレスリリースとして明文化する作業の前にインセプションデッキ作成を行っておくと、「プロジェクトメンバーが、プロジェクトの概要や目的をより深く認識・共有する」ことができるようになります。その前提だと、デッキを作成するときに話した内容を元にインターナルプレスリリースを作成することができます。これによって、プレスリリース作成者が煮詰まることが少なく、多少煮詰まっても他メンバーと相談していくことができます*2。

テンプレート化 on Cacoo

インセプションデッキを実際に作ってみると想像以上によかったのですが、ちょっとだけ手間がかかるところがありました。当初、本書のサポートサイトで配布されているテンプレートを使ってたのですが、更新が入るたびに毎度更新して、ファイルサーバ上に置きつつチャットにキャプチャ貼って・・・みたいなことをやってたんですよね。

で、こういう手間を無くすために、うちらはCacooというサービスを作っていたのでした。というわけで、インセプションデッキもCacoo化して、合わせて社内の他のプロジェクトでも手軽に利用できるようにテンプレート化。

多分このままだと、見ることはできても社外の人はコピーして流用するのはできなさげですが、欲しい人がいたらコメントか何かもらえると。コピーできるように、もうちょい設定します*3。

第4章 全体像を捉える / 第5章 具現化させる

インセプションデッキの中でも、うちらの中では以下の2つが重要だなと実感しています。

• 我々はなぜここにいるのか？
• エレベーターピッチ

「なぜ」これを作るのかという問いだと思いますが、エンジニア目線だとどうしてもこの辺が疎かになってしまうことがあります。結果として、何の役に立つのか・誰に向けた機能なのかがゆるふわになったり、当初のスコープより想定以上に膨らんだりしちゃいます。「なぜ」をプロジェクト初期にちゃんと考え抜いて、何かあったときにまたこの場所に戻って来れるようにしておくことは、当たり前といえば当たり前ですが大事なことですよね。

あとは、「パッケージデザイン」が上記のインターナルプレスリリースのたたき台に使えるんじゃないかとか、「やらないことリスト」「トレードオフスライダー」でプロジェクトで重要視するものを考えるきっかけになるよねとか、感じています。

そうそう、「期間を見極める」のところで出てきた、「プロジェクトの期間は6ヶ月以内が望ましい」ってのはまさにその通り。長いと、どうしても曖昧になってしまって、あれもこれもと夢を詰め込みがちになりますしね。

第6章 ユーザーストーリーを集める

ユーザーストーリーの洗い出しについていつも悩むんだけど、よさげなやり方が紹介されてました。フローチャートを書いてそこからストーリーを抽出していく方法と、画面モックからストーリーを抽出する方法。両方よさげ。

あと、あまり詳細に立ち入りすぎないようにってアドバイスもよかった。これもそのまま引用。

ストーリー収集ワークショップでは、1日かけて開催した場合で、ざっくりとしたストーリーを10~40ぐらい書き出せれば十分だろう。これぐらいあれば、向こう3ヶ月から6ヶ月ぐらいの計画を立てられる。書き出したストーリーが数百もあるのだとしたら、それは半年以上先の遠くまで計画を立てようとしているか、詳細に立ち入りすぎているかのどちらかだ。今の時点で優先すべきは幅だ（孵化さじゃない）。深みにはまって身動きが取れなくなっちゃいけない。

第8章 アジャイルな計画づくり：現実と向きあう

バーンダウンチャートではなくバーンアップチャートにして、かつスコープの広がりを表すもの。「アジャイルな見積もりと計画づくり」を読みました - @ikikko のはてなブログにも、バーンダウン棒グラフだったっけな？スコープも表現するようなものはあったけど、こっちのほうがシンプルでよさそう。今のプロジェクトに提案してみようかな。

---

最初の一歩の人に進めるときにいい一冊。アジャイル全般ならこの本で、もうちょいスクラムに絞った本ならばSCRUM BOOT CAMP THE BOOK、カンバンならばカンバン仕事術かな。本のWIPは1冊＆読書感想ブログを書くのを自分ルールに決めてるのであまり色々な本を読めておらず、もっと適切な本もあるかもですが。

SCRUM BOOT CAMP THE BOOK

*1:正直に言うと、デッキ作成しようと思い立ったときは、ここまで深くは考えていませんでしたが。

*2:正確には、インセプションデッキ作成後にプレスリリースの作成はまだやっていないのですが、おそらくこうなるだろうと感じています

*3:コピーできるようにしたら、大本のテンプレートのように CC ライセンスの記載も必要かもしれない。その辺も含めて、何かありましたらコメントもらえると助かります。

「リーンスタートアップ」を読みました

確か『「ユーザーストーリーマッピング」を読みました - @ikikko のはてなブログ』でMVP（Minimum Viable Product）という言葉が出てきて、その言葉をもうちょっと確認したくて、この本を手に取ってみました。

リーン・スタートアップ

はじめに

1. アントレプレナーはあらゆるところにいる
2. 企業とはマネジメントである
3. 検証による学び
4. 構築・計測・学習
5. 革新会計

上記のリーンスタートアップの5原則のうち、太字にした 3, 4 が今の自分にささってます。要するに、作りっぱなではなく、ちゃんと検証したり計測・学習しようねということだと理解してます。

第4章 実験

「とりあえず製品をリリースして様子を見よう」という方針で進むと、このような問題に悩まされがちだ。私はこの方針をナイキの有名なスローガンにちなんで「Just Do It（やってみよう）」型企業と呼ぶ。この方針に従うと様子を見ることには必ず成功するが、検証による学びが得られるとはかぎらない。失敗がなければ学びもないーそれが科学的手法の教えるところなのだ。

あー、やりがちだし分かる。「様子を見よう」ってのは、思考停止の兆候なのかもしれない。

「様子を見る」ってのは、つまり「何を検証したいか」・ひいては「どうあって欲しいか」というゴールをちゃんと考えきれていないということなのかな？ゴールがゆるふわな状態でのアクションは、結局そのアクションがゴールに結びついてるかどうか分からないという状態になりかねないと思ってます。なので、「様子を見る」というアクションは極力取らないようにしよう。

第6章 構築・検証

MVPに対して、「作り込みすぎたり約束しすぎたりという衝動をいかに抑える」ための実例が参考になった。エンジニア目線だとどうしても自動化・ソフトウェア化が一番のMinimumだと思い込みがちだけど、それよりもっと手前に、コンセプトに価値があるかを検証できる手段はあるよということ。

• 動画型MVP：Dropboxの実例
  • 優れた体験をプロトタイプででも提供するのは困難と判断して、動画でコンセプトを説明
• コンシェルジュ型MVP：Food on the Tableという、自分や家族の好みに応じて1週間の献立と食材のリストを作ってくれるサービスの実例
  • レシピ作成を最初からソフトウェアで自動化するのではなく、文字通り中の人として顧客の自宅まで出向いて欲しい献立を対面で確認して、それをもとにレシピを手動で作成

あとは、品質についてのこの原理も、なるほどと思いました。

誰が顧客なのかがわからなければ、何が品質なのかもわからない。

第7章 計測

コホート分析なるものが気になりました。こっち方面ド素人なんですが、これ結構いい指標なんじゃないだろうか。総数などに紛らわされずに、同じ指標でアクションの結果を計測していけそう。Mixpanel上で、これっぽいやつが実現できるかは不明（Retentionが近そうだけど）なので、だれか教えろください。もしくは、社内のその筋の人に聞いてみよう。

コホート分析の場合、総売上や総顧客数のような総計あるいは累積値を見るのではなく、製品と新しく接する顧客グループの成績を個別に見る。

...

さて、このグラフをよく見るといくつかのトレンドが読み取れる。製品の改良はわずかだが効いている。我々の製品を5回以上使う人は5%以下から20%近くまで増えた。しかし、この部分が4倍になってもIMVUを買ってくれる顧客の割合は1%前後で変わらない。

...

これはコホート分析なので、古い製品の第一印象に顧客がとらわれているんじゃないかとか、外部環境がよくないとか、そういう言い訳はできない。

あとは、スプリットテスト（A/Bテスト）とカンバンについてが面白かったです。「Xという機能をリリースしたとき、それは顧客の行動に影響を与えたか」を、スプリットテストなしでは測るのが難しい・コストがかかるけど、スプリットテストを実行するとこの辺が分かりやすくなる、とのこと。カンバンは、WIPの制限などはまあいわゆるカンバンの定義そのままなのですが、ステータスの一種に「構築完了」後に「検証中」を用意して、機能のユーザ価値まで検証を強制してるのがいいなと思いました。詳しくは、図を見てもらうと。

第10章 成長

3種の成長エンジンというのが気になりました。3種全部備えた事業もあるけど、原則としてはどれか1種に集中してそのエンジンをチューニングすることにかけた方がいいよとのこと。

• 粘着型成長エンジン
  • 一度顧客が使い始めるとずっと使ってくれることを念頭においた事業・ビジネスモデル。なので、解約率を指標とする。
• ウイルス型成長エンジン
  • 顧客が使うにつれて自然と広まっていくような事業・ビジネスモデル。ウイルス係数（顧客一人あたり何人の友達を連れてくるか）が大事になり、1.0（=1人当たり1人を連れてくる）を境に指数関数的に成長し始める。
• 支出型成長エンジン
  • 顧客を獲得するのに必要な支出と売上が相関してるような事業・ビジネスモデル。成長にあたって、顧客当たりの支出を抑える or 売上を増やすのどちらか。

今のうちのサービスだと、どれに該当するのだろう？粘着型：ウイルス型が 7:3 ぐらいかな。ITSやチャットなどのコミュニケーションツールは、ナレッジがたまると乗り換えコストが高く、ずっと使い続けた方がいい粘着型。かつ、組織の外部の人と使う際は一緒に使って自然と広まっていく、ウイルス型の側面もあるので。

---

どんぴしゃ自分が向かう分野ではないかもだけど、この辺の人たちと同じ文脈・同じ言葉で話せるようにという意味では、まあ読んで損はなかった本かなという気がしてます。あと、正直最後の方は息切れしたので、また別の機会に読み直してみたいです。

「Fearless Change」を読みました

いいものは色々取り入れようと日々奮闘しているのですが、そうは言っても取り入れ方にもいいやり方とちょっと受け入れづらいやり方ありますよね。というわけで、お次はこの本です。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

第1部 概要

第3章 さて、どこから始めよう

最初の足がかりとして、「エバンジェリスト」パターンが紹介されています。自分が「これはいい！」と情熱を持って導入・推進しないと、何事も進まないというのは、その通りだと思います。

エバンジェリストを前提として、以下が最初に導入する際の1セットとして紹介されています。とくに、後ろ三つの（ふりかえりの時間・小さな成功・ステップバイステップ）は、いわゆるスクラムでのふりかえりでもかなり重要視しています。色々根付かせるのは、ここからですよね。

• 予備調査
• ふりかえりの時間
• 小さな成功
• ステップバイステップ

第3部 48のパターン

どうでもいい話ですが、48という数字を見ると別のものを連想しちゃいます。。。

7 ブラウンバッグ・ミーティング / 9 何か食べながら

両方とも、食べることに関するパターンです。

「ブラウンバッグ・ミーティング」は、要するにランチミーティング。ランチミーティングは結構好きなんです。時間を有効活用してる感じがするとか、お弁当持ってきてるからとか仕事上人と合わせづらくてランチ一緒に行けてないけど行きたいとかの理由で。ただ、何回かランチミーティングやったら、あまり芳しくなかったのでちょっとサミシイ＞＜

「何か食べながら」は、そのまんまですね。食べながら話すと、リラックスできてより前向きに話し合えるとのこと。うちでも、リリース後のふりかえりとか、特別なイベントの際には経費でケーキなどを準備してもらうように進めています。あとは、ちょっと長くなりそうなミーティングの場合、1時間ぐらいでいったん休憩を挟んで、甘いものやコーヒーなどをとってもらうように仕向けるとか。

15 空間を演出する

物理的に掲載して、否応なしに目に入るようにするパターン。カンバンなどでもあるように、物理で見せるとやっぱり分かりやすい。ただ、うちはオフィスが分散してるので、ちょっと難しいんですよね。物理の力は偉大だと思ってるので、何かうまくやる方法を見つけたいとは思ってるところ。

お隣さんの製品ですが、「JIRA とアナログのボードの併用」ってのはいいアイデアだなーと思いました。一度試しにやってみたい。オフィスに遊びに行って見せてもらうかーｗ

www.evangelism.jp

22 種をまく

プレゼンやミーティングを行うときに、参考書籍やURLを出せるようにしておく、というパターン。割りとこれはやってる。特に、リモートの人と会話するときは、参考URLをぱっと出すと、相手もイメージしやすいので。

24 定期的な連絡

「コーチングマネジメント」を読みました - @ikikko のはてなブログにもあったけど、定期的にリマインドするの大事。何もしないと、人は忘れるものなので。

36 場所重要

少し特別なイベントを行うときは、普段の作業場所ではなく、ちょっと場所を入れ替えるというパターン。普段の場所だと、良くも悪くもすぐに普段の仕事に戻れるので、半強制的に切り替える。「9 何か食べながら」とかと組み合わせるとよさげですね。

46 恐れは無用

抵抗勢力がまったくいない状況を想像すると、ぞっとする。あなた一人で常に 100% の正しさを保証しなければならない。これはおそろしいことではないだろうか。

なるほど。こういう視点はなかった。こういうのを意識しておくと、何か抵抗や批判を受けたときも、リスクを潰してくれた・協力してくれたと前向きに考えることができるようになりますね。

---

基本的にこの本はパターン集なので、ざっくり頭に入れておいて、よさそうな機会に本引っ張り出して確認・適用みたいな流れになりそうかな。

「ユーザーストーリーマッピング」を読みました

良くも悪くも独自の感性でやってきた今の組織に対して、外部のベストプラクティスをうまく取り入れながらよりよいやり方を模索するのが、今の自分の役割の一つです。そのうちの一つに、ユーザーストーリーがありました。ユーザーストーリーはいいものだと思うのですが、全体像がちょっと掴みにくいなあと思ってたところだったので、この本を手に取ってみました。

ユーザーストーリーマッピング

3章 より早く学ぶためのプラン

ちょいちょい見る、下記の図の説明が腑に落ちました。

このようなリリースプランを立てれば、毎回のリリースで人々が実際に使えるものを届けることができる。しかし、私の目的が長距離旅行で、大きな荷物を持っていたら、この乗り物の例みたいにスケートボードなんかもらっても、ちょっとイラッとするだろう。（中略）あなたの目標が私を喜ばせることなら、これはまずいと思うはずだ。しかし、あなたの目標が学ぶことなら、その目標は達成できている。そう、これでいいのだ。あなたは、私がおもったより遠方まで旅行したいんだと考えていることを学んだし、その課題が片付いたら、私が楽しさにも価値を置いていることを学ぶだろう。

...

すべてのリリースを実験として扱い、何を学びたいのか忘れないようにしよう。

よく「単位を小さくリリースしろ」って言われるけど、（単位が小さいがゆえに）ユーザにとって価値が小さいのをリリースしてもどうなんだろう？と思ってました。けど、そのリリースの目的が（ユーザへの価値提供ではなく）学びであるならば、小さくリリースすることによってその学びを達成できたのであればいいことなんですね。予測と違う結果でも、「予測が違うかった」と学べたということで。

5章 あなたはもうやり方を知っている

この章では、「朝起きてから仕事に行く準備ができるまで」という題材で、実際にストーリーマッピングの作り方を試す流れになっています。こうやって、本で学んだ知識を実際に体験できるような章を用意しておいてくれるの、非常にありがたいですね。本読んだだけだと、ふむふむじゃあ実際にはどうやるの？ってなりがちですが、一度体験しておくと実導入する際にもう少し取り掛かりやすくなるので。

せっかくなので、会社で希望者募って一緒にやってみようかな。もし誰も希望者いなければ、会社の隅で一人さみしく付箋紙と戯れることになると思いますが・・・

(2016/11/16 追記)

やってみました。結果はこちら。オフィスの3~4名ぐらいが乗ってくれて、嬉しかったです。

16章 リファイン、定義、構築

ミーティングの形式について。

人数がある程度以上になると、興味が薄くてスマートフォンをいじったり別のチャットをやったりする人が出てきますよね。積極的に関与するほどではないけど、会話の流れを聞いておきたい人もいるという場合に有効なミーティングの形式として、「フィッシュボウル・コラボレーション」というパターンが紹介されていました。詳細は以下の画像を。

これ、割りといいなあと思いました。人数増えてくると参加者間で温度差が出て来るけど、それをうまく吸収できそう。一度取り入れてみたいですね。うちは拠点が分散してて hangouts などオンラインでミーティングする形式なので、物理的な円を描くとかはできなさそう。各参加者が、積極モードなのか、観察モードなのかを判別できるような仕組みがあればよさそう。

---

あと当たり前だけど、ユーザーストーリーマップを扱うときはユーザーストーリーも扱います。本の半分ぐらいはユーザーストーリーの説明も色々書かれてて参考になりました。まだ知識レベルな理解なので、ちゃんと実践投入してこの本で得た知識を活かせるようにいきたいです。（もしくは、やってみた結果今の自分たちに合わないと学んだならば、それはそれで成果だと思うし）

「XPエクストリームプログラミング入門」を読みました

基本的に仕事ではスクラム（or カンバン）をベースに考えてるのですが、スクラムの中でもXPのプラクティスは補完的に使えると思うし、Webで流し読みぐらいしかしたことなかったので、今改めて。

XPエクストリーム・プログラミング入門―変化を受け入れる

第3章 価値、原則、プラクティス

よく出てくる用語だけど、それぞれの意味や関係をちゃんと理解してなかったので。こういうことらしいです。

Xp2 from Toru Koido

第9章 応用プラクティス

「チームの継続」と「チームの縮小」。まさに考えてるところなので、参考になりました。

小規模な組織にはこのような問題はない。チームが1つあるだけだ。

...

大規模な組織は、チームの価値を無視し、代わりに「プログラミングリソース」という分子または流動体のメタファを採用する場合が多い。（中略）この戦略では、部分的な効率性は最大限となるが、全体的には組織の効率性が損なわれる。

今僕が見ているチームは、まさにスケールしている最中なので、小規模・大規模のこの辺がよく実感できます。合わせて、うちでは分散拠点なので、ロケーションの問題も考慮しないといけないのが、更にややこしいところなんですよね。もちろん、ロケーションの問題を極力埋めるために、オンラインビデオ会議などシステムで回避できるようなものも積極的に取り入れようと試みてはいますが。

第10章 XPチーム全体

メトリクス（測定値）とは何ぞや？というのを、すごい分かりやすく説明した文章があったので引用。

速度計が速度を指し示すのと同じように、開発後の欠陥と投資から収益までの時間はどちらもチームの有効性を示している。速度計の針をつかんで動かしてみても、車の速度を上げることはできない。速度を上げたければ、アクセルを踏み、その効果を確認するために速度計を見る。同じように、測定値に基づいて目標を設定できるが、チームは根本的な問題に対処する必要がある。数字を直接改善しようとしても、数字が修正されるだけで、プロジェクトに関する透明性の価値が排除されてしまう。

メトリクスはあくまで現状を測るためのものなんですよね。メトリクス自体を補正しようとしても、まったく意味がない、というのが分かりやすい例えでした。

ただ、そもそもメトリクスがないと、実際にいい方向に向かってるのか悪い方向に向かってるのかが分からない（感覚的にはある程度わかっていても）。なので、まずはメトリクスを取ってみるというところは意識付けしていきたいなと思ってます。

---

その他にも制約理論の話とか、ちょいちょい見たことがある話もありましたが、もろもろ再確認できました。ただ、正直なところ、何か文章が頭に入ってきづらかったんですよね。。寝不足で疲れてたとかもあるのかも。読書も持続可能なペースでいきたいものです。

「コーチングマネジメント」を読みました

テクニックや知識的なところだけでなく、人と対峙する面も求められる今の役割・立場的に必要そうとは思ってた「コーチングスキル」。いくつか推薦してもらった本の中から、まずはこれを読んでみました。

コーチング・マネジメント

PART1 : 今求められるマネジメント革命

ゴルフを教えないゴルフコーチ

ここで取り上げられてたやり取りが印象的でした。なるほど、こういうのがコーチングの基本形なのかなと感じました。

「目標に対する集中度は1から10で何点？」
「自分の体や動きに対する気づきは1から10で何点？」
「今のショットから学んだレベルは1から10で何点？」

みたいな感じで、コーチが特に技術的なアドバイスをするわけではなく、現状を気づかせる問いかけをするだけ。けれど、それによって、自分自身で考えて行動するようになる、という話。

ミスショットのときも、それを責めるとかではなくあくまで気づきを与えるような問いかけが、例に挙げられていました。

「どうやってあんなふうにボールを曲げたんだね？」
「打つ前から曲がるような気がしたし、・・・頭が混乱していたし、腕も緊張していた」
「そう、それでどんなことを学んだ？」
「混乱しているときは、仕切り直しだな」
「今までだって仕切りなおしのチャンスはあったと思うんだけど、それができなかったのはどうしてなんだろう？」
「一緒にプレーしている人の目を気にしていたのかな？」

PART3 : コーチング・スキル

クローズド・クエスチョンとオープン・クエスチョン

「なぜ？」って言葉は、オープンクエスチョンに見えて、実はクローズドクエスチョンに近いという話。「なぜ」と聞くと相手を萎縮させてしまって、結果的にクローズドクエスチョンになりがちだということです。

「なぜできなかったんだ？」
「なぜそんなことをやってしまったんだ？」

そのかわり、「HOW」や「WHAT」を使うとのこと。一般的には、HOWがアイディアを発展させて、WHATが問題をはっきりさせると説明されています。

「どうやったら、同じ失敗を繰り返さないですむと思う？」
「次はどういうふうにやる予定？」

「何が足りなかったんだろう？」
「何か気がついたことはなかった？」

効果的な質問のためにすること・実際のコーチングクエスチョン

コーチングの質問に際して考えておくべきことや、質問リストがきれいにまとまってました。ちょくちょく見直すことになりそう。

選択の幅を広げる質問

クローズド・クエスチョンの「Yes / No」「やるか、やらないか」は選択ではなくて脅迫らしい。コーチは、必ず3つ以上の選択肢を見つけ出して、自発的に選択できる状態をセットしなければいけないって。

結構難しい気がするけど、頑張ってみる。

アクナレッジメント

「賞賛」などの評価を含む言葉ではなく、事実を事実として伝える。評価が入ると、意見なので受け取りにくくなるということらしいです。「You」「I」「We」の視点があり、一番効果的なのは「We」のアクナレッジメント。

具体例をあげるのはやめておくかな。意識的か無意識的かにせよ、これと同じ言葉を誰かが聞いたとき、わざとらしく感じるかもなので。

エコロジカルチェック

何か変化があったときに、質問しながらその変化によって生じた歪みを見つけること、らしい。例えば、こんな状態になってるとして、

「頭では分かっているんだけどしっくりしない」
「何か違和感がある」
「最初はいいと思ったけど、今はちょっと」

これらの心理的な違和感や歪みを、こんな質問であらためて確認する感じ。

「今やっていることは、やる前に考えていたことと一致していますか？」
「やり方を変えて、気分はどうですか？」
「思ったような成果が上がっていますか？」
「ストレスはどうですか？」
「何か違和感はありませんか？」
「体の変化どうですか？」
「生活のバランスはとれていますか？」

要はやりっぱなしでなくて、ちゃんとアフターフォロー的なところも意識してってことかな。こういった「継続的な取り組み」ってのは、最近のマイブームというか、自分・組織に対して根付かせていきたいと思ってます。ふりかえりにしろ、例の本で学んだ見積もりと計画づくりにしろ、ここでのエコロジカルチェックにしろ。

---

一通り書いた後に見返してみると、ちょっとコーチングのスキル的なところばっかり目についちゃったかな。また適当なタイミングで見返してみて、そのときはどう思うかを感じてみたいです。

「アジャイルな見積もりと計画づくり」を読みました

名著と言われながら、今まであまり興味がなくて読んでなかった分野。もっと早く読んでおけばよかったなと思う反面、おそらく以前の自分では消化できなかった＆活かせなかっただろうなと思ってはいます。

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

1章：計画の目的

1. なぜ見積もりや計画づくりが必要なのか？

しょっぱなにあるこの問いかけ、最初からすごいためになる文章です。この本を読むまでは、見積もりや計画って、やりたくないけどやらざるを得ないといった、どちらかというと消極的な理由しか思い浮かびませんでした。でも、それだけでないよという話。具体的には、以下の5つが挙げられています。

• リスクを軽減する
• 不確実性を減らす
• 意思決定を支援する
• 信頼を確立する
• 情報を伝達する

この中で太字にしたものが、消極的な理由ではなく、計画作りをしていくことによってもっと前に進めるための理由かなと感じました。開発者・チームにおいても、いやいや計画づくりをやっていくのではなく、チームが計画づくりをやっていくことによって、ビジネス面での意思決定を支援したり他チームとの信頼を確立していくことを意識する。それが結果的に、開発チームだけでなく全体のサービス・プロダクトにいい影響をもたらしていくというのは、自他共に意識づけていきたいなと強く思いました。

あとは、これかな。

3. アジャイルな計画づくりとは？

本書で扱うのはアジャイルな「計画づくり（planning）」だ。アジャイルな「計画（plan）」ではない。
...
アジャイルな計画づくりで重視するのは、計画よりも、計画を作る過程そのものなのだ。

プロジェクト初期のみ「計画」を作成するだけじゃだめで、ちゃんと日々の活動の中で計画を更新していく「計画づくり」が大事だよということ。これって、プロセス改善の文脈でのメトリクスとかでも同様だよなーというのを思い描きながら読んでました。

11章：「望ましさ」による優先順位づけ

狩野モデルについての説明。このモデルについてはどっかで見たことがある気がするけど、本の中で出たので改めて見なおしてみました。守備範囲的にはプロダクトオーナーの領域っぽいけど、スクラムマスターとしてもさらっとでも知っておいて損はない領域だし、参考になりました。

モデルの説明については、先人のブログを参考に。
d.hatena.ne.jp

16章：ベロシティの見積もり

ベロシティは常に固定になるわけではなく当然幅があるけど、その幅をどう扱うかの話。3イテレーション（スプリント）以上取れる場合、以下の方法が挙げられていました。

• イテレーション毎のベロシティをそのまま幅として扱う
• 不確実性コーンを活用する

前者は単純。3回のイテレーションのベロシティが (12, 15, 16) ポイントだった場合、見積もり幅は 12~16 ポイントと扱います。

後者は、不確実性コーンと呼ばれる、プロジェクトの状況に応じて不確実性の幅が変わる図を流用しています。ここで、3回イテレーションこなした後の平均ベロシティが20ならば、下限が20*0.85=17, 上限が20*1.15=23 で、17~23 の幅に収まるだろうと推測する感じ。

実施したイテレーション数	下限の係数	上限の係数
1	0.60	1.60
2	0.80	1.25
3	0.85	1.15
4以上	0.90	1.10

ちょっと計算式は複雑になるけど、不確実性コーンをもとにした方が、今のうちのチームにとってはいいかなと思いました。理由としては、ベロシティの平均が基準となってるから。

うちのやり方として、1イテレーション内できれいに終わりきらないことがあるのですが、その場合各イテレーションのベロシティは変動しやすくなるんですよね。ただ、各イテレーション毎の変動はともかく、移動平均をとっていくと中長期的には問題とならないことが多い*1。なので、平均を考慮した方がより精度が高いものが出せるかなと思っています。

22章：なぜアジャイルな計画づくりがうまくいくのか

11. ゆとりを残す

チームメンバー全員の時間を100%使い切るような計画を立てないこと。特にイテレーション計画では気をつけること。高速道路の限界100%まで車を詰め込むと、誰も身動きの取れない渋滞になってしまう。開発チームもこれと同じだ。メンバー個々の時間を限界まで使ってしまうと、プロジェクトの進みは遅くなってしまう。

はい、やってしまってました。イテレーション計画ミーティング時は作業時間見積もりをしてるのですが、このとき全時間を詰め込もうとして結局計画したものが全部終わりきらない。終わらないものを計画時に話すのムダだし、終わらなかったという事実はチームメンバーのモチベーション的にもいい影響を与えない。

なので、最近ではベロシティ（実績）ベースで考えるようにしようとしてます。普段大体これぐらいポイント消化できてるのだから、（作業時間はもうちょい余裕あるけど）計画するのはここまでにしておこう。で、おかわりできるならばそのとき考えよう、という方針にしてます。

チームがもっと成熟して毎回安定して計画したものを終わらせられるようになってきたならば、その次はいかにベロシティを上げていくかを考えていく感じ。もしかしたらその中で、作業時間のムダに着目していって、より効率的にタスクに取り掛かれるようになるかもしれないなーとは考えています。

---

いつもより長くなった。それだけためになる内容が多かったです。特に1章の「1. なぜ見積もりや計画づくりが必要なのか？」は常に意識しておきたいです。

あと、タイムリーなことに、先月の WEB+DB PRESS でちょうど見積もりの話がでてました。こちらも参考に。

WEB+DB PRESS Vol.93

*1:この辺は「7章：再見積もり」の「4. 部分的に完了したストーリーの再見積もり」も参考に。