「リーンエンタープライズ」を読みました

Switchを買っちゃって、プライベートの時間がどんどんなくなっちゃって、ヤヴァイってなってます。この本も、もう1年以上前に読んでたのに、いまさらの感想ブログになってますし。

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

確か、この本読もうとしたときに、ちょうど↓のスライド見た記憶があります。幅広くカバーしてるってので、もれなく吸収したいなと思ったのでした。

リーンスタートアップ本を振り返る 2018 (Lean Startup Update! 2018) from Takaaki Umada

---

2章 企業ポートフォリオのダイナミクスを管理する

この章では、やっぱり3つのホライゾンですよね。

	ホライゾン1	ホライゾン2	ホライゾン3
概要	既存のビジネス：今日のキャッシュフローを生み出す	高成長ビジネス：今日の収益成長と明日のキャッシュフローを生み出す	成長のオプション：将来の高成長ビジネスのオプション。キーワードは、リーンスタートアップや製品／市場フィット（Product / Marget Fit）
目標	経済的リターンの最大化	キャズムを超える、収益に貢献し始める	新しいビジネスを作る
主要指標	計画に対する収益、市場シェア、利益率	売上高利益率、ターゲット顧客数	クチコミ（消費者）、有名顧客（法人）

自分の性質がホライゾン1,2に向いてるのもあって、ホライゾン3はちょっとおろそかになりがち。なので、そうなりがちというのを意識しておかないとなと、再確認しました。合わせて、自分が今手がけてる事業は、ホライゾンのどこに当たるのかな、それにふさわしい指標やら施策になってるんだっけ？というのを踏まえながら。

5章 製品／市場フィットを評価する

海賊指標：AARRRと、課題／解決フィット・製品／市場フィットの関係について、再確認。それぞれ単語は頭に入ってたのですが、それらの関連などを確認・考えるきっかけになりました。

名前	目的	Votizenでの例	気にかけるべきフィット
Acquisition：獲得	サービスを訪れた人の数	アカウントを作成した
Activation：アクティベーション	はじめてなんらかの体験をした人の数	信頼性を確証した	課題／解決フィット
Retention：定着	何度も戻ってくる人の数	少なくとも3回システムを使用した	課題／解決フィット・製品／市場フィット
Revenue：収益	収益を生む活動にかかわる人の数	活動を支援した	製品／市場フィット
Referral：紹介	他のユーザーを紹介する人の数	友人に転送した	製品／市場フィット

フィット関連について思い出したのは、下記の記事。製品の時間軸の流れを考えて、AARRR -> ARRRAというようにAcquisitionを最後に持ってきたのと同じことかなと思いました。自分の中の知識がチョットつながってきた。

growiz.us

あとは、ソフトウェア開発には外せない、エンジニアリングプラクティスについて。「あとで技術的負債を支払うために、最初から従っておくべき2つのプラクティス」はこちら。ホライゾン3では製品レベルだけど、ホライゾン2でも機能レベルで技術的負債を扱うことになるので、どのみち避けては通れない。

• 継続的インテグレーション
• 基本的なユニットテストおよびユーザージャーニーテスト

前者は、エンジニアとしての自分が価値を出せる＆自分もやってて楽しい領域。他は多少優先度下げてでも、ここはちゃんと第一線はれるように腕を磨いておきたい。

後者は、ユーザージャーニーテストって知らなかったんだけど、Fowlerの定義や下記の図いわく、一番下（ユニットテスト）と一番上（ユーザージャーニーテスト）を抑えておくべしということかな？

( by You cannot Automate a User Journey Test – Toby The Testers Blog )

6章 継続的改善をデプロイする

ソフトウェアに依存している会社がハイパフォーマンスを達成するには、何よりもまず、実行する能力、信頼できるシステムを構築する能力、複雑さを継続的に軽減していく能力にフォーカスすべきです。ビジネスの優先度と連携するのは、それができてからでいいでしょう。

よく「どこから改善していくべきですか？」という質問を受けたり見たりしたとき、雑な手書きだけどこういう風に認識している。いつまでもビジネスの優先度を考えないのも困りものだけど、まずは先立ってIT部門にある程度の実行能力がないと、ビジネスがうまく回っていかないので。

他には、活動会計。最終的には時間ではなくて、成果 = アウトカムに結びついてるかを考えたいけど、その手前としてどういう活動にどれぐらいの時間を使ってるかというのは、自分たちでコントロールしやすくてとりかかりやすそう。下記は、本書で取り上げられてた活動会計の表。

コストの割合	活動	以前
2%	継続的インテグレーション	10%
5%	アジャイルな計画	20%
15%	ひとつのメインブランチ	25%
10%	製品サポート	25%
5%	手動テスト	15%
23%	自動テストスイートの作成と保守	0%
~40	イノベーション	~5%

自分でもちょっとお試しとして、自分でも各人の月次稼働実績をまとめて集計して、何か見えないかを試してみました。もう1,2ヶ月分出してみて、ちょっとふりかえってみよう。

最後に、改善のカタ。これ、フォーマットとしていいんじゃないかと思いつつ、以前やったけどうまく実践できなかった。改めてもう一回トライしてみようかしら。

改善の型 コーチングの型 from Masanori Kado

www.slideshare.net

7章 価値を明らかにしてフローを増やす

バリューストリームマッピング、カンバン、遅延コストの章。これだけでご飯が3杯ぐらい食べられそう。

それぞれ、以前読んだ本にも取り上げられてるぐらい。けど、バリューストリームマッピングは結局素振りもちゃんとできてないので、やらんといけんってのを改めて思い出せました。やるぞー。

ikikko.hatenablog.com
ikikko.hatenablog.com

第IV部 変革

• 文化
• GRC：ガバナンス / リスク / コンプライアンス
• 財務管理
• IT部門

にまつわる話。ですが、まだまだピンとこなかったところが多いです。少しずつ関わるようにもなってきたのですが、まだまだ経験不足ですね。後日もう一回読み直してみましょうかしら。

最後のIT部門に関しては、おそらく今後レビュー書くであろう「LeanとDevOpsの科学」で触れるはず。もう読んだけど、感想文書くときにあらためて考えることにします。

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

---

1回目に読んだときは全然ささらなかった探索のところが、2回目読み直すとチョット分かるようになってきたのは面白い変化。前向きに捉えると、以前よりは成長してるということなんでしょうかね。

RSGT2019の当日ボランティアスタッフをやってきました

2019.scrumgatheringtokyo.org

応募したきっかけ

去年もボランティアスタッフに応募していたのですが、家族がインフルっちゃったので、（自分はかかってなかったけど）念のために直前キャンセルをさせてもらいました。なので、今年が初めて。

スタッフに応募した目的としては、よりRSGTを味わいたかったから。スピーカー枠でいけたら一番よかったんだけど、残念ながらプロポーザル落ちたので、ならばとスタッフで応募したのでした。スタッフ業が少し慌ただしい時間もあったのですが、とは言ってもフル稼働しておかないと追いつかないような体制では全然なかったので、適度にセッション見学や参加者と交流しつつができました。

スタッフみんな自律的！

スタッフ業やってて一番ほーとなったのは、スタッフみんなが自律的に動いてるというところ。ほとんどのスタッフが2回目以上だったり、会場が前年と一緒で慣れていたりというのもあるのでしょうが、各々が判断して作業を進めていました。

理由の一つに、トランシーバーが効果的なのかなと思いました。「ヘルプお願いー」とか声掛けあると、すぐにみんな反応するとかはわかりやすい話。あとは、判断に迷ったときでも「トランシーバー上で共有しておけば、ダメだった場合誰か止めてくれるか」と思って、自分の判断で動きやすいという心理的な安心感はありました。トランシーバーがないと、やっていいか分からないのでちょっと置いておくか、みたいな状況も多分多かっただろうなーとも。

細かいところを見れば、自律的に動いた結果、作業がかぶる（誰かがやったことを、よかれと思って戻す）こともちょいちょい見受けられたのですが、概ね問題なく進められて、全体としてはもろもろかなり早く進められたんじゃないかなと思ってます。自律的な組織・チームをトランシーバーという仕組みで作る、いい体験をできました。

スマホアプリもあるようなので、小規模のイベントではこっち使えるかもですね。

update.hirochan.org

体力的にはしんどい＞＜

前日準備も含めたら、4日間ほぼ立ちっぱで、棒が足のようになりました。普段座り作業に慣れてる体には、かなりしんどかったです。あと、朝の集合時間がモロに通勤ラッシュの時間帯で、前職以来久しぶりに車掌に体を電車内に押し込まれる体験をしました。

それでも、みんな毎日のように会場1Fの中華料理屋に懇親会に行ってて、スゴイなーと思いましたｗ

---

参加者の方々、また当日だけでなく事前からコンテンツやら色々考えてもらった実行委員の方々、みなさんお疲れ様でした。

さて、これから発表スライドを一通り眺めて、ふりかえりをしようかな。

「デザインスプリント」を読みました

基本、読んでる本はWIP 1で進める派（今読んでる本を読み終わる or 諦めるまで、次の本に手を出さない）なのですが、割り込みでデザインスプリントの本を読みました。

背景としては、業務でプロダクトデザインフェーズでのアイデア出しワークショップを開いたことのふりかえりから。ワークショップ内で発散まではまあどうとでもなるとして、収束させることがそのときの自分の引き出しではできなくて、結局ワークショップ内では発散しっぱなしで諦めました。で、そのことを某関西弁のパイセンコーチに壁打ちしたら、「デザインスプリントにアイデアがあるかもね」というありがたい言葉をいただいたので。

というわけで、今回はDay 3の「決定」を一番中心に読みました。言い換えると、「この本を読んだ後に、例のワークショップを開催するとしたら、どこをどう改善するだろうか？」というのを考えながら。

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド

ちな、以前下記のスライドは目を通してました。なので、デザインスプリントとは何？ってのをざっくり知ってるけど、実体験として理解はできていないレベルです。

Design Sprint 概要 / デザインスプリント概要 from Takaaki Umada

www.slideshare.net

Design Sprint ガイドブック v2 from Takaaki Umada

www.slideshare.net

---

決定に関わること

Day 3 決定：チームでのスケッチ作成

この作業のサイクルを複数回繰り返す時間はないことが多いでしょう。したがって、ユーザージャーニーマップを分割してチームごとにそれぞれ異なる部分を作業してもらいましょう。そして、最後にそれぞれのチームからフィードバックをまとめることで時間短縮が可能です。

ここが一番知りたかったところ。一気に全員で全範囲を収束の議論するのではなくて、分割した上でそれぞれを3~5名程度のグループ単位に割り当てていくわけね。その切り口の一つとして、ユーザージャーニーマップごとに分割するとか。

なるほどー。時間の問題もあったんだけど、一番のネックって思ってたのは、人数が多い状態（6名以上を想定）で収束の議論が難しいそうだなと感じてたんでした。それは、分割して議論の人数を絞った上でそれぞれで議論すればいいのか。もちろん、一人が全部をがっつり見ることはできなくはなるけど、それは各グループの結論を信頼して任せる感じ。

Day 2：発散でも似たように、分割してやってるところがあった。発散を複数回繰り返すときに、一気に全部を考えると、2回目以降同じ範囲を考えても同じアイデアしか出てこないんじゃないかなーと思ってました。けどこれも一緒で、1回目はジャーニーマップの前半で、2回目はジャーニーマップの後半とかやると、考える範囲が違うので、複数回してもよさげ。

Day 3 決定：最終スケッチの作成

「選択肢を2つか3つにまで収束できたなら」的な説明がありました。収束となると、この辺が現実的かなとは感じてます。

10も20もアイデア出てきても、全部を実装できるほど僕らの人生は長くないし、ましてや作りっぱなしではなく検証まで含めるのならばなおさら。なので、もう数個に絞る。どれぐらいに絞るかは、プロジェクトの予算やスケジュール感にもよるかな。

決定に関わらないけど、心に残ったもの

Day 1 理解：アイスブレイク

ここだけの話ですが、実は…

自己紹介に続けて、参加している他の参加者が誰も知らないと思われるちょっとした秘密を話してもらう。

希望と心配

2色のポストイットに、それぞれ希望・心配事を書いてもらう。で、それを匿名状態で集めて、任意に一枚ずつ選んで書いた人以外がその意味を推測しながら説明していく。このことによって、他の参加者の共感を持てるようになる。

前者の「ここだけの話ですが、実は…」の派生として、ワークショップで取り上げようとしてる内容に関してのことだと、より味わい出そう。あとは、少人数（1~3名）のみ知ってるとかだと、あまりにもニッチな領域じゃないところを狙いに行きたくなって少しゲーム要素も出そうでよさげ。

後者の「希望と心配」は、単に自己紹介で終わるのではなく、自分以外の誰かのことを考えるってのがよさそうと感じました。ドラッカー風エクササイズの「期待されてると思うこと」と派生の「相手に期待すること」でもそうだけど、他の人の立場で考える機会ってなかなかないけどチーム力を高める上で大事なことだと思ってるので。

Day 1 理解：課題の定義

また、モバイルデジタルプロダクトの1つだったAndroid携帯をFacebook携帯に帰るFacebook Homeを使ったことがある人もいるでしょう。結局我々はFacebook Homeを使いませんでした。このアプリにはまったく使う意義を感じられません。「ユーザーを自社アプリに囲い込む」というFacebookにとっての課題は解決されたのかもしれませんが、ユーザーにとっての本当の課題やニーズにはまったく考慮されていません。

Facebookのとあるプロダクトを例にあげられてて、ぐさっときました。あまり聞いたことないプロダクトの失敗事例を聞いてもぴんとこないところもあったけど、Facebookでさえもそういうことあるという（実際にFacebook Homeなんて知らなかった）。

自分たちに都合のいい解釈で、「自分たちのビジネス的にこうなるといいな」からの「これ作れば使ってくれるだろう」っていう流れに陥らないように、↑の説明文に続いて述べられてた↓の文も合わせて。

ユーザーや顧客のためではなく、自社にとっての課題を解決するためにデザインスプリントを行おうとしている企業は今も多数見受けられます。

Day 1 理解：HEART Framework & Goals-Signals-Metrics

「UX のゴールやメトリクスを設定するときには HEART Framework と Goals-Signals-Metrics プロセスが使いやすい」という触れ込み。ちらっと見ただけだけど、確かによさげ。頭の片隅に入れておこう。

Design Sprint ガイドブック v2 from Takaaki Umada

Day 2 発散：ストーリーボード

絵コンテとも。テキストだけより絵も含めて書いた方がより記憶に定着するだろうし、複数のコマで表現されてるとインタラクションがイメージしやすい。これも、アイデアを表現するフォーマットの一つとして、引き出しに入れておこう。

ストーリーボードの説明は、よさげなサイトがあったので、そちらにおまかせ。

esaura.jp

Day 5 テスト：プロトタイプの評価 - よく起こること：辞退者が出た

我々は辞退者の発生を見込んで、7,8 人にインタビューを行うようにしています。そうすれば、辞退者がいても最低でも5,6人からフィードバックを得られます。

いい目安。とりあえずメモだけ。

---

やっぱり、実際にやること・やったことと照らし合わせて読むと、理解度とかも違いますね。自分が知りたかったことが知れた（収束に至るまでのやり方）のもよかったし、それ以外でもいくつか引き出しができた。今後デザインスプリント自体をがっつりやるかはさておき、一つレベルアップできたんじゃないかな。

「エッセンシャルスクラム」を読みました

だいぶぶりの読書感想ブログ。ノルマ的にこなしていかんと、なかなか進まないなあ。いつも言ってる気がするけど。

ということで、これも今更ながらの名著です。実際には、スクラムガイド2017での変更点の紹介 | Ryuzee.comやスクラムで削除された5つのトピック | Ryuzee.comのように、スクラムガイドも細かく更新されています。が、本質的なところはそう変わってないはずなので、ちゃんと読んでおくべきだと判断しました。

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)

---

第1章 イントロダクション

クネビンフレームワーク。開発プロセスの提案をすることもときどき出てきた立場として、アジャイルプロセスを適用するかどうかの最初の指針になるもので、盲目的にアジャイルでいくんだーとなる前に考えていいところ。まあ、最近のソフトウェア開発は、大体は複雑な領域に相当するので、それをうまくやっていくためのアジャイルな開発プロセスがマッチするというのはそうなんでしょうけど。

iandco.jp

ちなみに、クネビンフレームワークを改めて調べ直して、カオスな領域での適切なふるまいを勘違いしてたことに気づきました。カオスな領域だと、まずはカオスを脱出するために、強力なリーダーシップのもとにコマンド＆コントロールで進めるべきみたいですね。例として挙げられてたのは、9.11 のテロ事件とか。確かに、テロ真っ最中のときに悠長に検査・適応してから進もうってのは苦しい。

と考えると、ソフトウェア開発でカオスな状況って、よっぽどのことですね。本の中では、自分たちのサービスのバグによって不利益をこうむった顧客から、今まさに巨額な訴訟を受けよう最中というのが挙げられてました。

第3章 アジャイルの原則

ここではやっぱり「3.5 仕掛中の作業（WIP）」ですよね。

• 作業は経済的に妥当なサイズにまとめよ
• 在庫を認識し、適切な流れで管理せよ
• 作業者の手待ちではなく、作業の手待ちに着目せよ
• 遅延コストを考慮せよ

この辺は、カンバンの原則にもまんま通じるところがあると思ってます。詳しくは、以前発表した資料を。

第5章 要件とユーザーストーリー

ここは目新しい項目はなかったのだけど、今まで学んできたことを再度確認した章。そうだよね〜とか、あーこれはどうだったっけ？って調べながら、読み進めていきました。キーワード的にはこの辺。

• ユーザーストーリー・エピック・テーマ
• INVEST
• 非機能要件
• 学習のためのストーリー（スパイク）
• ユーザーストーリーマッピング

第7章 見積もりとベロシティ

すでに本書の時点で、ストーリーのサイズ見積もりをしない話がでてました*1。

スクラムを実践している人たちの中には、PBIのサイズ見積もりを必須ではないと考えている人もいる。経験上、成熟したスクラムチームなら、すべてのPBIを同程度のサイズにまとめられると知っているからだ。彼らは、同程度の小さいサイズにまとめられたPBIを前にして見積もりをするのは、時間のムダだと考えている。そんなことをしなくても、単にPBIの和を数えれば、それで十分だというわけだ。

ケースバイケースとは思いつつも、↓の理由から作者はPBIを見積もりたい派で、自分も同じだなー。少なくとも今は。

• 第5章で説明したとおり、すべてのPBIが同時に同じサイズになるわけではない。たとえすべてのPBIのサイズを小さめに揃えることを目指していても、バックログの中には大きめのPBIがいくつか残る。
• チームのメンバーがPBIのサイズを同程度にまとめられるようになるには、それなりに時間がかかる。
• 同じサイズにすることが目的になってしまい、不自然なところでストーリーを分割せざるを得なくなるかもしれない。
• いちばん大切なことだが、見積もりの最大の目的は、話し合う家庭でいろいろな気付きが得られるということだ。何かに対して数字を付けてくれと頼んだりするだけでは、健全な議論が生まれない。意見の相違は見えなくなるだろうし、思い込みがあったとしても表には出てこなくなる。見積もりをやめてしまうのなら、健全な議論をうながすための何らかの手を他に探す必要がある。

この辺も思い出したので、参考がてらはっておこう。

poohsunny.hatenablog.com

第8章 技術的負債

今自分の中でホットな話題ｗ どういうものかはある程度感覚としてあるので、主にどういう風に解決していくべきか？という視点で読んでました。その中であがったのが、以下の2節。

• 技術的負債の可視化
• 技術的負債の返済

技術的負債の可視化

可視化については、ビジネスレベル / 技術者レベルでの可視化があるとのこと。ビジネスレベルではベロシティへの影響を与えるかどうかで考えるのが分かりやすそう。ベロシティが半分になれば、倍の作業コストなり遅延コストがかかるよねという感じで。

技術者レベルでの可視化については、障害管理システム / プロダクトバックログで障害を扱う / 技術的負債バックログの3つがあげられてました。それぞれ、負債の量が少ない順という感じかな。負債がすくなければ、不具合と同じレベルで障害管理システムに突っ込んでおくぐらいでいいし、もうちょい大きいものならばPBIとしてプロダクトバックログにつっこむ。負債が多い場合は、それ専用のバックログを用いて、かつそれをちゃんとスプリントプランニングで考える必要がある（けど、管理だけして忘れがち。。。）

技術的負債の返済

返済の手法で気になったのは、以下の3つかな。

• ボーイスカウトルールに従う（負債を見つけたらその場で返済する）
• 技術的負債の返済はインクリメンタルに
• 技術的負債を返済しながら顧客に価値をもたらす作業も行う

ボーイスカウトルールは好きなんだけど、無制限にその場で返済し続けるわけにもいかないですよね。一定の割合に収めるというのが大事そう。

残り2つは、一括返済じゃなくて徐々に返済していこうという話。一括は考えやすいんだけど、それは問題を先送りにして楽な方に逃げてたつけなのかもですね。ご利用は計画的に。

「技術的負債返済スプリント」だとか「リファクタリングスプリント」などといった言葉がチーム内で出てきたら、危険信号だ。（中略）私に言わせればそれは大量の負債を一気に支払うということだ。実際のところ、そんなコメントが出てくるというのは、技術的負債がそんなにふくれあがるまで負債の削減など気にしていなかった証に他ならない。

↑の「技術的負債バックログ」と合わせた手法も紹介されてました。こういうのもよさそう。

1. プロダクトバックログから、次のスプリントで作業するアイテムを選び出す
2. 技術的負債バックログのボードを眺めて、1 で選んだアイテムに関連する分野の負債のカードを取り出す

第9章 プロダクトオーナー

だんだん疲れてきたのでｗ、後から参考にできるように、ここでは最低限の表だけで。

開発の種類	プロダクトオーナーの候補
社内開発	そのソリューションによって恩恵を受けるビジネスエリアの代表や顧客
商用開発	実際の顧客やユーザーの組織内プロキシ（プロダクトマネージャー、プロダクトマーケッター、プロジェクトマネージャーなど）
外部委託開発	そのソリューションに支払い、恩恵を受ける会社の代表や顧客
コンポーネントチーム	技術的なバックログの優先順位をうまく受けられる技術者

最後のコンポーネントチームだけは、ちょっと疑問に思った。コンポーネントチームを作るのは、悪手だと思ってるので。コンポーネントチームはそれ単体ではユーザーに価値を出さないし、コンポーネントを利用するフィーチャーチームからすると外部のコンポーネントチームに依存するので、クロスファンクショナルにならなさそう。

というのを、第12章の「12.2 フィーチャーチームかコンポーネントチームか」に書いてあった。

第10章 スクラムマスター

「1日の様子」が面白かった。スクラムマスターのやることとして、下記のようなアクティビティがある。

• インペディメントの除去
• コミュニケーション
• チェンジエージェント
• プロダクトオーナーの支援
• チームのコーチ
• スクラムのアクティビティ

スプリントの最初と最後はスクラムのアクティビティ（スプリントプランニングやレビューなど）が占めるのはそのとおりだけど、それ以外の日は5割ぐらいインペディメントの除去に費やされてた。まあそうだよね。

第11章 開発チーム

ここでは、開発チームの特性かな。「よりいいチームになるために、どこを頑張っていけばいいと思う？」みたいな問いかけのときに、こういうのを思い返してもよさそう。

• 自己組織化
• 機能横断的な多様性と十分な能力
• T型スキル
• 銃士の姿勢
• 広帯域のコミュニケーション
• 透明なコミュニケーション
• 適切な規模
• 集中とコミットメント
• 持続可能なペースで仕事する
• 長寿

第12章 スクラムチームの構成

「12.3 複数チーム間での調整」で、スクラムオブスクラム・リリーストレインという2つの手法が紹介されてましたが、後者の方に興味をひかれました。ちょいちょい見たことはあったのですが、SAFeでも定義されてたんですね。SAFeはほとんど知らないのですが、いつかちゃんと見ておきたい。今の自分の立ち位置だと直接関わることはほぼなさそうですが。

jp4.scaledagileframework.com

第13章 マネージャー

マネージャーの責務として、一番根幹だと思うものを一つだけ取り上げておこう。

境界を定める

• マネージャーが、プロダクトやプロジェクト（砂場）を定める
• マネージャーが、チームの構成を決める（誰をどの砂場で遊ばせるかを決める）
• チームは、それぞれの砂場の中で自己管理する

第15章 さまざまなレベルでのプランニング

プランニングのレベル。スクラムで主に意識するのは、リリース・スプリント・デイリーぐらいまでだろうけど、プロダクトやポートフォリオ*2もあるよと共通言語を持っていると、話が早いだろうなとは思った。例えば、いまのうちの会社に照らし合わせると、ポートフォリオプランニングはあれで、プロダクトプランニングはロードマップ含めたあの辺かなという感じ。

レベル	範囲	誰が作るか	何を対象にするか	成果物
ポートフォリオ	おそらく年単位	ステークホルダーとプロダクトオーナー	プロダクトのポートフォリオの管理	ポートフォリオバックログ、そして仕掛中のプロダクト群
プロダクト	数ヶ月単位か、あるいはもっと長期	プロダクトオーナー、ステークホルダー	ビジョン、そしてプロダクトの成長	プロダクトのビジョン、ロードマップ、そして概要レベルのフィーチャー群
リリース	3ヶ月から9ヶ月程度	スクラムチーム全体、ステークホルダー	顧客に届ける価値と全体的な品質について、スコープやスケジュールそして予算などの制約の範囲で継続的にバランスを取る	リリースプラン
スプリント	イテレーションごと（1週間から1ヶ月）	スクラムチーム全体	次のスプリントでどのフィーチャーを出荷するか	スプリントゴール、そしてスプリントバックログ
デイリー	毎日	スクラムマスター、開発チーム	コミットしたフィーチャーをいかに完成させるか	進捗確認、そしてその日の作業をうまく進めていくための調整

第16章 ポートフォリオプランニング

この章からは、やっぱ遅延コストかな。よさげな概念だとは思うんだけど、まだ理解しきれていない。次かその次に感想ブログあげる予定のリーンエンタープライズでも出てきてるので、そっちも合わせて考えてみよう。

なお、ポートフォリオレベルでのプランニングとは言ってるけど、別にポートフォリオに限らずプロダクトレベルやリリースレベル以下でも十分に適用できる内容も多かったです。上記の遅延コストもそうですし、小さなリリースとか、WIPの制限、作業者の手待ちじゃなくて作業の手待ちとかとか。

第23章 未来へ

「23.4 スクラムを使って、進むべき道を探し出せ」がよかった。スクラムを広げる際、まずは少数のチームから始めて次に組織全体に広げていくことになったお話。全体に広げるときにやるべきことをバックログとして管理して、3週間のスプリントで見直しながら取り組んでいったというお話。開発じゃなくても物事を進めるときのフレームワークとしてスクラム（のエッセンス）を使うのもよさそうです。

最後に小ネタですが、高校の合唱コンクールでキロロの「未来へ」をピアノ伴奏しました。男の人がピアノ弾くと、映えるのでオススメです♪

www.youtube.com

---

スクラム自体というより、スクラムをうまくやるための周辺の考え方やツールなどが役に立ちました。スクラムのルール自体は、スクラムガイドで分かるしね。

ちなみに、ブログ書くときは再度読み直すのでこれも2周目なのですが、今回はいつにもまして以前読んだことをまったく覚えていない。。。まあ、だからこそ改めて読み直す意義があるのでしょうが。

*1:これって、No Estimateでいいんだっけ？No Estimateの正確な定義が見つけられなかったんだけど、No Estimateの動きの一種とみなしてます。

*2:複数のプロダクトの中から、どれを、どの順番で、どの程度の期間で進めていくかを決める作業を、ポートフォリオプランニングと定義されてます。

Atlassian Team Playbookを自分なりにまとめてみたよ（ヘルスモニター）

Atlassian Team Playbookなるものが出てました。なんかよさげな感じはあったのですが、イマイチ頭に入ってこなかったので、自分なりの解釈を含めてまとめてみました。

ja.atlassian.com

まずはヘルスモニターから。気が向けば、残り2つの要素（プレイ / ゲームプラン）についてもまとめてみようと思います。

---

以下、[ikikko]というタグ付けした箇所が、自分がまとめたところです。

チームの関連

このガイドでは、まずはヘルスモニターというもので、チームの全体像・健全性の基準を定めようと言われてます。ヘルスモニターは、以下の3チームに対してそれぞれ定義されています。

リーダーシップチーム

あなたは、影響力があり長期的なビジョンや高いレベルでの取り組みに関係し、意思決定することができる。プロジェクトで実際に作業をすることはないが、メンバーをまとめる役目にある。

プロジェクトチーム

新しい機能をリリースしたり、「ビジネス」をするための戦略的なプロジェクトを提供したり、新しいものをローンチさせることで、お客様のためになる素晴らしい成果を出すことがあなたの使命である。

サービスチーム

技術職かそうでなくても、作業量が多くリスポンスの質が重要になる役目。あなたの仕事は、キューが必要で1日または１週間で処理できる量が限られている。

[ikikko] 3チームの関連は、ざっとこんなものかな。厳密には、一方向じゃなくフィードバックループなどもあるでしょうが、ややこしくなるので図からは割愛。

なお、この3チームの分類は、スキルセットや専門分野によるものではなく、仕事の成果や仕事を生み出す手段での分類とのこと。2018/06時点だと3チームですが、今後増える可能性はあるよと（参考：このサイトにはチームのタイプが 3 つしかありませんが、それはなぜですか?）。

各チームの説明

各チームには、「フルタイムオーナー」や「価値と指標」といった、チームに必要な8つの属性が定義されています。ただ、属性を単に眺めてても右から左に流れていってたので、無理矢理にでもまとめてみました。

[ikikko] まずは、リーダーシップチーム。「チーム」と「成果物」、あとは両方にかかる「全体」的なものと、属性を3つに分類してみました。各属性の細かい説明については、Atlassianのページを参照してください。

[ikikko] 次に、プロジェクトチーム。リーダーシップチームと属性がかぶってるやつも多く、構成は大体似たり寄ったりな感じにまとめられました。

[ikikko] 最後は、サービスチーム。これが結構迷った。特に、サービスにかかりそうな「サービス指示書」「サービスレベル」。どう違うかがイマイチわからなかったのですが、「サービス指示書」が横軸的にスコープを表すもので、「サービスレベル」が横軸に対して縦軸的にレベルを表すものとしてみました。

チームごとの属性の差分

リーダーシップチーム vs プロジェクトチーム

↑でちょっと触れたように属性が結構かぶってて、6/8は一緒でした。違うのは以下。

チーム	チームに対する属性	成果物に対する属性
リーダーシップチーム	チームのまとまり	意思決定
プロジェクトチーム	フルタイムオーナー	概念実証

[ikikko] 以下、それぞれの差分に対する考察。

チームに対する属性の差分は、リーダーシップチームとプロジェクトチームで、構成メンバーの役割が多いか少ないか、とか？プロジェクトチームでは、プロジェクトの責任者であるオーナーだけでなく、日々作業を行ってる人などもいるはず。そういう中で、オーナーがしっかりフォーカスして役割を果たすことが重要になってくるから、必要な属性として「フルタイムオーナー」が出てくるのかなと推測しました。

成果物に対する属性の差分。これは、そのまま成果物の性質による差分でしょうね。リーダーシップチームの成果であるビジョンは、まあ「意思決定」を早くして進めることが大事ですよね。一方、プロジェクトチームの成果物はある程度具体的に見える・体感できるものになるはず。その成果物を、適切に「概念実証」を進めて顧客からのフィードバックを得ていくことが大事。

似たり寄ったりな理由は、成果物がビジョンなのかプロダクトなのかであって、どちらも成果物を創造するというプロセスは一緒だからなのかなとか思ったり。

リーダーシップチーム / プロジェクトチーム vs サービスチーム

ちょっとこれは、差分が大きすぎて比較はあまりできそうにない。その中でも大きな違いは、サービスチームでは「効果的なパートナーシップ」や「顧客中心」といった、「チーム」以外に関係者が増えるところ、ですかね（もちろん、前者2つのチームでも顧客が大事でないとは言わないけど、属性としては入ってない）

[ikikko] 「効果的なパートナーシップ」は、サービスを提供しようとなると、より広範囲なカバーとしてパートナーが必要となる場面も出てくる、ということかな。「顧客中心」については、サービスチームが最終的に顧客と一番密接に関与するから、とかかなあ。

---

以上、自分の頭の整理も兼ねて、Team Playbookで紹介されている要素について、まとめてみました。少なくとも自分の中では、なんとなく整理・分類できた気はします。この上で、ヘルスモニターを実施してみれば、どの系統が弱いのかがより分かりやすくなる・・・のかな。例えば、「フルタイムオーナー」や「バランスの取れたチーム」などチーム面が弱い傾向にある、とかとか。

もちろん、もっと別の適切な分類もあるとは思います。というかあるはず。特に、サービスチームについてはかなり怪しい。というわけで、こういう分類がより適切じゃない？とかあれば、ぜひぜひコメント・フィードバックください！

「カンバンによるアジャイルプロジェクトマネジメント」を読みました

「カンバン仕事術」を読みました - @ikikko のはてなブログでも読んでたのですが、カンバンはもっと突き詰めていきたいところなので、他の本で別の視点の意見も取り入れていきたいですね。ということで。

今すぐ実践！　カンバンによるアジャイルプロジェクトマネジメント マイクロソフト関連書

---

第1章 経営陣の同意を得る

カンバンを導入する際に、経営陣の同意を得やすくするプロセスについて。幸いにも、今の自分はある程度権限を与えられているので、ここにすごく力を費やす必要はないけれども、いつもいつもそういう恵まれたケースばかりじゃないだろうから、頭に入れておこう。

印象に残った項目は、この辺。

• 2ヶ月の試用期間について了承を得る
  • 試用期間、結構長いなと思った反面、これぐらいかかるちゃかかるかな
• 経験豊富なコーチを招いて初期の質問に答えてもらう / チームに対して、コンサルタントまたはチームの専門家によるカンバンのトレーニングを行う
  • 自分たちで試行錯誤する過程ももちろん大事ですが、専門家のアドバイスを聞くことも大事だよね

第2章 カンバンのクイックスタートガイド

この章に限った話ではないけど、トラブルシューティングが非常に役に立つ。

問題11：一度に複数の作業項目を担当したがるチームメンバーがいる

ありそう。基本的にはWIP制限をちゃんと守りつつ、どうしてもというときにはその部分だけWIP制限を増やして試してみる、ってのが提案されてました。

あと、ここで触れられてた「1作業項目＋50%のバッファー」つまりWIP制限をメンバーx1.5倍ってのは、スタート地点としてはよさそうだと思いました。1つ待ちが入ってる間にもう1つ進められる人もいるけど、全員が全員そうではなくて、その場合は周りを手伝わないといけなくなるというので、いい塩梅っぽい。

問題12：ツールや自動化を改善する時間が取れない

これもありがち。で、回答として「作業項目が10個あるとしたら、そのうちの1つか2つはインフラストラクチャの改善であるべきです」とのこと。大体1,2割ぐらいを改善の時間ということで、これは目安として考えてたのと一致してました。

第4章 ウォーターフォールからの適応

はい、ここも最後のQ&Aから。ウォーターフォールを経験したことがある人からのFAQとあるけど、はじめてカンバンに取り組む人から出てきそうな質問ということで、自分の言葉で説明できるようになっておかないと。特に↓らへんは。

Q 小さいバッチでどのようにしてスピードアップするのか？
A 小さいバッチはいろいろな面で効果的です。（中略）要するに、小さいバッチは無駄な作業や手戻りを大幅に減らし、プロダクトの品質を向上させます。

Q では、なぜこれまで小さいバッチを使用してこなかったのか？
A 小さいバッチを使用するには、作業フローの調整が必要だからです。（中略）分析、実装、検証が同じペースで進むように調整できない場合、その先にあるのは、一括の作業、無駄な作業、バグの大きなバックログ、そして大量の手戻りです。

Q いろいろなアナリストや開発者、テスト担当者がいる中で、どのようにして作業のペースを調整するのか？
A 分析、実装、検証の作業を、それらのペースが同じになるように制限します。（中略）こうした作業の制限はよく「WIP制限」と呼ばれます。

Q 作業を制限したらペースが落ちるのではないか？
A 私たちが制限するのは人ではなく、人が行う作業の種類です。開発者があるフィーチャーでブロックされているとしたら、アナリストがさらにフィーチャーを分析したところで意味がありません。そのような場合、アナリストは開発者のブロックを解除するために働くべきです。

第8章 サステインドエンジニアリング

SE：サステインドエンジニアリング。多分カンバンが一番有効で、使いこなせたらよりよくなるんじゃないかと思ってる領域。要するに、運用保守開発で、事前に計画出し切ることが難しい・突発的に起きうるタスクが多い領域ですね。そういやスクラム現場ガイドでも出てきたので、今一度読み返しておこう。

ikikko.hatenablog.com

最初に検討するのは、SE専門チームにするか、コアエンジニアリングチーム（プロダクトのロードマップを進めるチーム）が担当するか、の2択。

	メリット	デメリット
SE専門チーム	コアエンジニアリングチームがロードマップを進めることに専念できる	SEチームのメンバーは、あまり意欲的でないかもしれない
コアエンジニアリングチームが担当	SE業務を根本解決するモチベーションがわく	SE業務によって、チームの作業が頻繁に妨げられる可能性がある

次は、注記から引っ張ってくるけど、この辺ははっとした。極端な話、不具合0になれば不具合分のサポート業務は減らせて、より攻めの業務に時間費やせますよね。もちろん、そこまで目指すかどうかはケースバイケースにはなりますが、頭の片隅に入れておいていい考え。

コアエンジニアリングチームの作業がそこまで遮られる理由に目を向けることが重要となります。たとえば、全体的な品質の問題に対処すれば、サポートリクエストの数を最小限に抑えることが可能かもしれません。

章末のトラブルシューティングからは、この辺かな。

問題1：コアエンジニアリングチームにカスタマーサポートからのエスカレーションが殺到し、対応しきれないほどのバックログが生成されている
問題5：エスカレーションの数が予測できないため、チームの保守計画に支障が生じている

問題1は、何が問題かを見える化してからそれに対応するという、まあ基本ですよね。場合によっちゃ、SEに入る前のプロダクトの品質に問題があるかもしれないので、品質を高める活動が必要になるかもしれない。問題5は、予測不可能だからこそカンバンが有用だよ、けどカンバンで透明性を少しでも高めてスループットやリードタイムなどから予測できるようにしようと。

第9章 さらなる方策とカンバンを超えて

カンバンに関連する理論や手法について。多かれ少なかれ知ってるのもあるし、初めて聞いたのもあったけど、頭に留めておこう。

• 一個流し
• 制約理論（TOC）
• ドラム・バッファー・ロープ
• クリティカルチェーン
• リーン開発
• 全体最適化

---

あえてやってるんだろうけど、同じような語り口・パターンでの説明が続いて、単調に＆ちょっと無理があるように感じた場面もちょいちょい。まあでもカンバンについて、別の視点から見るという意味でも、ちょい忘れかけてたことを再度確認するという意味でも、ちょうどいい1冊でした。

「ザ・コーチ」を読みました

購入のきっかけは、1on1などに組織的に対応するフェーズになってきたことで、今回2018年の年始目標を立てるのに読み返しました。

ザ・コーチ

---

第2章 目標の達人への道

目標設定における、各言葉の定義とその関係性。細かいところはおいておいても、この図は関連を表すのにすごくわかりやすかった。合わせて、一番低レイヤの「目標」は具体化させるときには大事だけど、それだけではモチベーションがわかないので、「目的」や「ゴール」さらには「ビジョン」もセットで考える、というのはそうだよなあと。

第3章 価値ある恩恵

↑の「目的」や「ゴール」を明確にしておくと、どういう恩恵があるかどうかについて。色々触れられていたけど、この辺が今の自分にしっくりきたかな。

• 「目的」や「ゴール」に自然と意識が向くので、情報をキャッチしやすくなる・学習意欲が高まる
• 「目的」や「ゴール」に向かう過程で、選択力・決断力・集中力が増し、パフォーマンスが出やすくなる

確かに、この辺定期的に思い出さないと、すぐ忘れちゃうんですよね。

第5章 始まりの日

Q : 組織において部下にゴールを設定する時のポイントは何か？
A : 会社の目標と個人の目標の接点を見つけて共有する

Answer はもっともなことなんだけど、どこまで接点を見つけることができるんだろうというのは、ちょっと疑問にも残った。完全にトップダウンでの目標設定よりはもちろんましだけど、接点を見つけるにも見つけられないときもあるだろうし。まあそれがずっと続くようだったら、色々ミスマッチということでそもそも論になるので、そこまでいかないケースをできるだけ拾い上げるということかな。

第6章 真実が姿を現す時

行動計画表として、下記のようなものが例示されていた。こういうの、いいよね。全体像の中で、今どこまできているかが分かりやすい。今の自分はここまでは作ってないけど、機会を見て作ってみてもよさそう。

あと、目標設定時のTIPSとして、こういうのが。やった or やらないのTODOもではなく、状態を表す目標文にすべきとのこと。少し気をつけてみよう。

「たとえば、やるべきことを目標にしてしまうと、自分への問いかけは、『今日はやるべきことをやったか？』という閉じた質問になってしまいます。すると、その答えは、『やった』か『やれなかった』ということになります。これだと、発展や成長が感じられないと思いませんか？」」

「はい。確かにそうですね」

「本来の目標とは、作業を消化することではなく、効果的に行動したり、行動から学習したりするための指標です。目標を、目的やゴールに対する通過点や到達点だと考えれば、そのプロセスで自分に問いかける質問は、『今日、僕は目標に向けてどんなことをやったのだろうか？』とか『もっと効果的に進むためには、どうすればいいだろうか？』という開かれた質問になるのではないでしょうか。これこそが重要なのです。・・・」

第7章 自分に正直に生きる

<価値観を知るための言葉リスト> というのがあった。それで思い出したけど、持ち味カードというのを某コーチが使ってたのを見て、これ引き出しの一つとして使えそうだなーというのを改めて思い出したんだった。使い方見るに、1on1やチームビルディングの一環としても使えるし、採用基準作りなどにも使えそうなので、一度試してみようかしら。

www.delight-c.com

---

最初読んだときはちょい期待はずれだったかなーと思ったけど、実践する際にはかなり参考になった本でした。タイトルにあるコーチのHowToというよりは、目標設定のやり方というのが大きなところ。これを、まずは自分の中でちゃんと消化しつつ、広げていけたらいいな。

あ、最後まで読んで、本の中で取り上げられたワークシートが公式サイトで公開されているのに気づきました。さくっと試すのに、今度機会があったら使ってみよう。