「アジャイルコーチング」を読みました

原著を読もうと思ってたら、ちょうど翻訳版が出るという噂を聞いて、心待ちにしてたのでした。ちょうど一年ぐらい前からこういうチーム・組織を支援するロールもいいなと思ってて、けど何と言えばいいか分からなかった*1ところを、「アジャイルコーチ」という呼び方があるというのを知ったところだったので。

アジャイルコーチング

第1章 旅を始める

「エクササイズ：コーチングを始める前の質問」は、いい問いかけ。こういうの、頭から抜けがちですが、大事なところですしね。というわけで、いくつか問いをピックアップして、問に対する答えを言語化してみました。

• 動機：自分はどのような変化をもたらしたいのか？
  • 十分にスキルを持った個々のメンバーに対して、1+1=2 以上になるようなチームにしたい
• スキル：自分は何を提供すべきか
  • （他チーム・他社のベストプラクティスを含め）メンバーだけでは気づきづらいことに対して、外部からの第3者視点を提供する
• 責任：仕事の進捗をどうやってレビューすればいいか
  • 以前よりチームとして成果を出せていること
  • （のためには、成果って何？とか以前/今の状態をちゃんとトラッキングしておく必要があるんだよね・・・）
• 支援：周りからどのような支援が受けられるか
  • 金銭面・権限含め、ある程度自由に物事を導入でき、任せてもらえる

第2章 みんなと一緒に働く

「2.4 合意を形成する」で紹介されてた、「合意の段階」。「賛成」or「反対」の2値ではなく、「全面的に賛成」〜「どちらとも言えない」〜「絶対に反対」という段階で表す。↓の資料で紹介されてた「5 fingers」みたいなものかな。

slide.meguro.ryuzee.com

ちょうど見積もり時のプランニングポーカーみたいなもので、意思決定が必要な場面で、最初の方でこれやっておくと話が早くなりそうと感じました。お互い大体同じ結論に達してるのに、枝葉の差異にこだわりすぎて議論して時間をムダにしちゃうとかを、これで防げそう。あと、中庸の意見はひとまず置いておいて、極値の意見同士で話し合うとか。

権限を委譲したい/してほしいときに便利なデリゲーションポーカー - Qiitaもそうですが、all or nothing で考えるのではなく、段階があることを踏まえて適切に対応していく必要がありそうだなと感じてます。

第3章 学習を促す

質問してはいけないとき
助言をしたいときには、質問をしないように気をつけましょう。質問をすれば、同意できない答えでも受け入れなければなりません。（略）たとえば「このバグをもっと早く見つけるにはどうしたらいい？」と質問して、「もっと手動テストをやる」が答えだった場合、自動テストの方向に進めることは難しくなります。

あー、これ時々やりがち。上記の例で「いや、自動テストやろうよ」みたいにあからさまにもっていくことはさすがにないですが、自分が望む方向の答えだった場合、待ってましたとばかりに色々話しちゃうことがたまーに。。。

とは言え、望まない答えは避けたいからといって、全部一から教えてるとそれはそれでよくない。なので、最初は質問して答えを自分なりに考えてもらう、その後その答えはちゃんと受け止めつつ、こういう選択肢・方法もあるよと提供する感じかな。

ここまでが、コーチングの話。アジャイルコーチに限らず全般的な話でした。この辺は、以前読んだコーチングの本に通じるところがあって、いい復習になりました。

ikikko.hatenablog.com

第5章 デイリースタンドアップ

「5.4 時間を設定する」について。この話で、結構いい感じにチームをコーチングできたなあと思うのを思い出しました。

ユーザからの問い合わせを主に担当するチームがあるのですが、このチームに対しては朝に行うのではなく午後一に行うようにしました。問い合わせ対応は、短い時間で多くの件数を処理するため、朝のタイミングではその日一日のことを計画しきれないという声があがったためです。

朝ではなく昼にやることによって、下記のような効果を期待してました。実際に、いい感じに回ってるように見えてます。

• 朝からの流れでその日の状況をある程度推測しつつ、問題起こりそうなのを検知・対応できるように
  • 対応悩んで時間かかりそうなものを、デイリースタンドアップ後に相談したり
  • 立て込んでキャパオーバーになりそうな場合、適切に他チームなどにエスカレーションしたり
• 昼に一度作業の流れを切ることによって、立ち止まって状況を整理する機会を提供
  • 合わせて、デイリースタンドアップ前に 2,3 分程で状況を俯瞰できる問い合わせボードを更新
  • 定期的に整理する場があると、日々の作業にズルズル流されることなくボードを最新に追随できる

第6章 何を作るかを理解する

ユーザストーリーの作り方や、ストーリーテスト（受け入れ基準）の話。ストーリーテストのテンプレートとして、 Given-When-Then（前提 - もし - ならば ） という形が紹介されていました。ってこれ、BDDで見たパターンだ。

以前まで、BDDとTDDの区別があまり分かってなかったのですが、ストーリーテストという文脈で見て、少し分かってきました。ストーリーテストだと、Given（前提）とWhen（もし）の区別が重要になってきそうですね。Whenというほんとにテストしたい条件と、テストする前段階のGivenを明確にすることによって、何をテストするのかをはっきりさせることができそう。

いいテンプレートだなーと思って、さっそくチームに紹介・導入しました。

第7章 前もって計画する

午前中にユーザーストーリーを提示して、午後に見積もりをしているチームもあります。このやり方であれば、開発者で何をすべきか話し合う前に、コードを見ることができます。

このやり方、よさげ。機会あれば提案してみようかしら。

あと、直前のコラム、これどういう意味だろう。ちょっとよく分からなかった。誰かと話してみるか。もしくは分かりそうな人、コメントもらえるとありがたいなー。

書記はやらないように
ミーティングの記録係を引き受けないようにしましょう。チームを支えるためにできることだからと、ついついやっちゃうのよね。でもこれをやってしまうと、他のみんながミーティングに参加するのを妨げてしまうことになるの。そればかりか、ミーティングはチームのためのものではなくて、あなたの利益のためにやっているのだと思われかねないわ。チーム全体を巻き込むようにしてね。

(2017/05/08 追記 翻訳者の @kdmsnr さんから、書記についてのコメントもらいました)

@ikikko 書記のところは、コーチやスクラムマスターみたいな人がホワイトボードのペンを持ってしまう、みたいなことです。その人が場をしきる感じになってしまい、チームのための会議という感覚が薄まってしまうので、できれば避けたいところです。

— 角征典／新刊『アジャイルコーチング』 (@kdmsnr) 2017年5月8日

第8章 見える化する

この章、目下の課題。

うちは拠点が離れてることもあって、物理的な形での見える化はしづらく、その結果効果的な見える化がしきれてないんですよね。もちろん、距離を補うために色々やってて、そのための自社サービスを開発して自分たちの業務に組み込んでいたり、リモートワークを支えるツールなりを導入してはいますが、やっぱりリアル対面にはまだまだ及ばない。

まずはタスクボードから取り掛かるとして、そっからは以前読んだ「アジャイルコーチの道具箱」をもう一回見直してみようかな。何かインスピレーション湧いてくるかもしれない。

ikikko.hatenablog.com

第13章 ふりかえりで変化を推進する

ふりかえりやカイゼンなど、自分の中でうまく説明できない状況だったので、この章読みながら、雑にメモ書きした。

スーパー雑に、ふりかえり・カイゼンとやる必要があること（タスク）や、大きな目標について、自分の今の理解を書いてた pic.twitter.com/4cPETpKns7

— ikikko (@ikikko) 2017年5月4日

第14章 あなたの成長

この章、いいよねー。今まではチームのためにアジャイルコーチができることについて書かれてたのですが、ここはコーチとして成長していくためにどういうのが必要かについて書かれてる。あまりこういう視点で書かれた本ない気がするので、すごくいい。

例えば、最初の書き出しからこれですよ。結構慎重派なのであまりドラスティックな変化は好まない傾向があったのですが、こういうところは意識しようと思いました。

コーチは絶えず変化をリードします。つまり、自分自身を変えることに抵抗感を持たないことが重要です。

あと、最後の方のこのコラム。長いけど全文引用します。うまくできないことも多々あるし、やればやるほど自分のできなさや先人たちの偉大さが分かって心が落ち込むときもありましたが、このコラム読んで心が少し楽になりました。

自分に優しく
あるカンファレンスで、私は尊敬している人に愚痴っていたの。仕事であんなミスをしただの、こんなミスをしただの、チームのコーチをするのはどんなに難しいかだの。すると彼女は、ただ私を見て、こう言ったの。
「あなたは他の人はミスをしないと思ってるの？」
「いえ、違うわ。誰だってミスをすると思う」
「それじゃあ、どうしてそんなに自分に厳しくするの？」
「それは・・・」
それに続く理由は山のように浮かんだわ。
（うまくやらなくてはいけないから。）
（明らかなミスをするのは恥ずかしいことだから。）
（もっとうまくやりたいから。）
そしたら、彼女はこう言ったわ。
「自分に優しくなりなさい」
その言葉は心に刺さったの。私は自分に厳しかったのよ。みんなと同じね。自分はミスをしてはいけない、もっとうまくやらなくてはいけない、常に有能でなくてはいけない、そう思っていたの。自分に優しくしたっていいじゃない。息子がミスをしたら、抱きしめてこう言っているのに。
「大丈夫よ。次はもっとうまくやれるわ」
どうしてその言葉を自分に言えないのかしら？

---

途中でもいくつか引き合いに出したけど、この1年で読んできた本がだんだん結びついてきました。感想ブログまでじっくり書く方針なので、一つ一つ読むのは遅くなるけど、こうやって後から引き合いに出したりふりかえったりもできるので、自分にはこのやり方結構合ってます。

ちなみに、この本とは直接は関係ないけど、ちょうどどっかから流れてきた資料がすごくよかったです。アジャイルコーチを頼む方に視点を当てた内容ですが、コーチ自身のあり方とか価値の出し方とか、すごく参考になりました。"An Anonymous Agile Coach"ってあるけど、誰なんだろう・・・

docs.google.com

*1:スクラムマスター、だとスクラムに限定されそうな感じがして、ちょっと狭い

「リーン開発の本質」を読みました

何か発想の転換になりそうなので、「リーンソフトウェア開発」はちゃんと突き詰めていきたいところ。というわけで、次はこれを読んでみました。

リーン開発の本質

そもそもなのですが、リーンソフトウェア開発が全体の中でどういう位置づけかが曖昧だったので、そこから。「リーン」と「アジャイル」の関係とは？：書籍でたどる「リーン」の本質 (3/4) - ＠ITの以下の画像が、分かりやすかったです。

第2章 原則

検証時の欠陥発見は、当然ではなく、例外であるべきだ。検証がいつも「テストをしては修正する」というサイクルを生むようなら、それは、開発プロセス自体に欠陥があるということである。

欠陥は早め早めに（理想的には作るそばから自動的に）発見・対処できるように、プロセスを作り込んでいくべきだってことですね。思い当たるふしがあったので、今後の参考に。

第3章 価値

トヨタでは、チーフエンジニアがその車種のビジネス上の成功責任を持つ。

（中略）

チーフエンジニアを立てるという手法には、多くの情報を、責任ある一個人の頭の中で統合できるというメリットがある。

「チーフエンジニア」について。以前は、どちらかというとこういうリーダー的なのは不要ではと考えてました。チームメンバーがチームが達成すべきことなどを適切に把握してたら、リーダーはいなくとも進むだろうと。ただ、この本で説明されてた下記の理由を読んで、やっぱりリーダー的な役割はあったほうがいいかなとも思ってきました。

• 結果責任・説明責任を明確にできる
• 一個人の頭の中で、多くの情報を統合できる

あと、知らずに何となく感じてたことですが。チーフエンジニアって、スクラムで言うところのプロダクトオーナーみたいな役割に似てるなーと思ってたら、やっぱり関連があったとのことです（参考：株式会社戦略スタッフサービス）。なるほどー。

第4章 ムダ

複雑さを自動化するな

複雑なプロセスや、乱雑なプロセスをただ単に自動化したところで、顧客の役には立たない。ソフトウェアのもつ複雑さというがちがちのよろいで、ムダだらけのプロセスをつつむようなものである。

う、頭が・・・＞＜ CIやビルド周りに興味があるくらいなので、自動化は好きなのですが、これはそうだよねー。

続いては、ムダの話。これは有名な話ですよね、多分。リーン生産とリーンソフトウェア開発の対応表はこちら。

製造	ソフトウェア開発
在庫のムダ	未完成の作業のムダ
作りすぎのムダ	余分な機能のムダ
加工そのもののムダ	再学習のムダ
運搬のムダ	引き継ぎのムダ
動作のムダ	タスク切り替えのムダ
手待ちのムダ	遅れのムダ
不良を作るムダ	欠陥の無駄

いくつか、対応付けがいまいち分かってないところもあります。「加工そのもののムダ」に相当するものが「再学習のムダ」だったり。ただ、「作りすぎのムダ」＝「余分な機能のムダ」が一番タチが悪く他のムダを引き起こすことがあるというのと、（対応付けは分かってなくとも）ソフトウェア開発のムダに紹介されてるもの自体はその通りなので、ひとまずはそれらのムダを意識して見つけることができるようにというところからかな。あとは、カンバンにも表れてるけど、「在庫のムダ」＝「未完成の作業のムダ」らへん。

あと、バリューストリームマップ。これは、カイゼンの基本 | Ryuzee.com (on Azure)で紹介されてたこの本を読んで、別途やってみようと思ってます。

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

第5章 スピード

要望やタスクを管理する「待ち行列」について。

1. 待ち行列は短くなくてはならない。おそらく、作業の2サイクル分あたりが適当だろう。その程度の長さであれば、開発プロセスの間中、要求の平均サイクルタイムを管理できる。
2. マネジャーは、待ち行列にある項目をいつでも改定したり、変更したりできる。しかし、いったんチームがある項目に着手したら、マネジャーが日々の開発作業に干渉してはならない。
3. チームは、待ち行列から作業をプルし、その作業が完了するまで、一定のリズムで作業を行う。プルシステムによって、作業を許容範囲に収めながら、常にチームに仕事を与えていられるのだ。
4. 待ち行列がありさえすればチームに対応する時間がなくても、そのうち要求に対応してもらえる、という誤解を与えてはならない。

特に、1, 2が気になりました。1 は、無限待ち行列になってるのをよく見かけますよね。。。意識して制限しないとそうなりがちなのですが、無制限だと全体が見えづらく改善ポイントが分かりづらいとか、待ち行列を見るだけでいやになるとか、あとはリズムが出ないとかも結構大きいことかも。2 は、仕掛り始めたものをやっぱりやめたってなると、これまたリズム出ないしなかなか終わらない=価値の提供が遅れますしね。

とここまで書いてきて、これ見たことある、カンバンの原則だー！って気づきました。カンバンはリーンの考えから影響受けてるっていってましたしね。自分の読書感想ブログも含めて、本も改めて見直しておこう。

ikikko.hatenablog.com

第7章 知識

この章では、「顧客要求にもっと応えたい」というチームにおける例をふまえて、科学的方法の進め方が説明されています。科学的方法とは、こんな感じ。

1. 問題を定義する
2. 状況を分析する
3. 仮説を立てる
4. 実験を行う
5. 結果を検証する
6. フォローアップする / 標準化する

この中で、3 の「仮説を立てる」が「科学的方法の要でありながら、問題解決を急ぐチームが見落としてしまいがち」とされています。これ、すごい分かる。ちゃんと意識しておかないとだめですね。

ここの例、すごく参考になるので、多分今後何度も見直すんだろうなあ。

第9章 パートナー

オープンソースでのセキュリティフィックスをグローバルにまたがった複数のチームで対応した話と、トヨタ傘下のサプライヤの工場が火事になったときに別のサプライヤが協力して大本の発注を無事に納品した話。その中で、何がキーポイントだったのかというのが、↓な感じで説明されています。

よく、どうすれば世界規模のチームでのコミュニケーションを改善できるか、という質問を受ける。しかし、たいていの場合、根本的な問題はコミュニケーションではなく、約束を取り交わしたチームの不在なのだ。

なるほどね。約束を取り交わすことが第一で、その約束を果たすために必要ならばコミュニケーションの話になる、とのこと。多分その約束も、お互いがちゃんとやるべきことを把握できるレベルでの約束が大事な気がする。何となくとか、いい感じでお願いね♪みたいな曖昧なものだと、多分正しく機能しないんだろうな。

あと、コラムにあった「グローバルな作業グループから、グローバルなチームへ」っていうTIPSも、すごく参考になる。目次と簡単に一言で説明。

1. 頻繁な統合：コードベースでの統合とか
2. 人の交換：一方のチームメンバーを、もう一方のチームに送って一緒の時間を過ごす
3. テストを交換する：要求を引き渡す際、実行可能なテストでやり取りする
4. 窓口（Proxy）：窓口となって、毎日コミュニケーション
5. 動き回るチームリーダー：各地のチームを、チームリーダーが動き回る
6. 差別の撤廃：言語や立場などの違いは、真のチームワークに欠かせない尊敬や信頼や約束を簡単に破壊する

第10章 旅立ち

どこからリーンソフトウェア開発を始めるかについて。「訓練」「思考」「計測」とありますが、計測が特に気になりました。

「開発作業が終了してからしばらくたたないと、効果的な計測は難しい -> たくさんの部分最適から着手してしまう」という流れが紹介されてましたが、これだと全体最適を阻害する可能性もあるのでだめだとのこと。代わりに、計測対象を減らして、（サブシステムではなく）システムレベルでの計測点を見つけるのがいいよと。具体的には、この辺。

• サイクルタイム
• 財務上の成果
• 顧客満足度

サイクルタイムは、コンセプトがキャッシュになるまで。これを見るだけで、あらゆるムダが露呈するので、リーン手法の一番基本的な計測対象となる。

財務上の成果は、まあそのまま。開発（やもろもろの作業）がどう財務・ビジネスに紐づくか、当然意識して計測できるようにしておくべきだとは思ってるのですが、現実なかなか難しいなあと。ビジネスレベルまでいくと、開発者の作業以外の要素も絡んできそうなので。もちろん、最終的にはここに行き着くべきだけど、一歩目はもうちょいやりやすいところからかなーと。

顧客満足度は、こういう簡単な指標で出せるみたい。

「あなたの製品を、どれだけ薦められますか？」そして、顧客に0（薦めない）から10（絶対に薦める）までの点数をつけてもらう。その回答を、9~10点は「推奨者」、0~6点は「批判者」7~8点は「中立者」としてグループ分けする。

...

推奨者の正味比率を算出するには、推奨者の割合（パーセント）から批判者の割合を引く。すると、マイナス100パーセントから、プラス100パーセントまでの数字が出る。平均的な企業なら、点数は10パーセント」前後である。本当に優秀な企業であれば、50パーセントからそれ以上の点数が出る。マイナスになったら、深刻な問題につながると思った方がよい。

簡単なのはいいけど、実際にこのデータが手元にあった場合、どう活かせばいいのかはちょっとイメージできていない。傾向を継続的に見ていって、傾向が変わったタイミングで何かを検知するとか。もしくは、何かアクション起こす前に傾向がどう変わりそうかを仮説立てておいて、アクション後にその仮説を検証するとかかなあ。

---

一度通して読んだ後、この読書感想ブログを書くために再度読み直したのですが、この辺がいいなと感じたのかなと改めて。忘れがちなので、適宜また戻ってこようと思います。

• スクラムなどの開発チーム・プロジェクトにフォーカスするだけでなく、（バリューストリーム（マップ）をはじめとして）より上位の全体システムを見据えた最適化をはかれそう
• うっかりするとバッチサイズを大きくして一度に効率よく作業しようとなるところを、逆にバッチサイズを小さくしてサイクルタイムをよくすることを心がける

それにしても、いつにもまして長い・・・

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

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

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

第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チーム全体

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

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

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

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

---

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