「デザインスプリント」を読みました
基本、読んでる本はWIP 1で進める派（今読んでる本を読み終わる or 諦めるまで、次の本に手を出さない）なのですが、割り込みでデザインスプリントの本を読みました。
背景としては、業務でプロダクトデザインフェーズでのアイデア出しワークショップを開いたことのふりかえりから。ワークショップ内で発散まではまあどうとでもなるとして、収束させることがそのときの自分の引き出しではできなくて、結局ワークショップ内では発散しっぱなしで諦めました。で、そのことを某関西弁のパイセンコーチに壁打ちしたら、「デザインスプリントにアイデアがあるかもね」というありがたい言葉をいただいたので。
というわけで、今回はDay 3の「決定」を一番中心に読みました。言い換えると、「この本を読んだ後に、例のワークショップを開催するとしたら、どこをどう改善するだろうか？」というのを考えながら。
デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド
- 作者: Richard Banfield,C. Todd Lombardo,Trace Wax,安藤幸央,佐藤伸哉,牧野聡
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/11/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
ちな、以前下記のスライドは目を通してました。なので、デザインスプリントとは何？ってのをざっくり知ってるけど、実体験として理解はできていないレベルです。
www.slideshare.net
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 プロセスが使いやすい」という触れ込み。ちらっと見ただけだけど、確かによさげ。頭の片隅に入れておこう。
Day 2 発散：ストーリーボード
絵コンテとも。テキストだけより絵も含めて書いた方がより記憶に定着するだろうし、複数のコマで表現されてるとインタラクションがイメージしやすい。これも、アイデアを表現するフォーマットの一つとして、引き出しに入れておこう。
ストーリーボードの説明は、よさげなサイトがあったので、そちらにおまかせ。
Day 5 テスト：プロトタイプの評価 - よく起こること：辞退者が出た
我々は辞退者の発生を見込んで、7,8 人にインタビューを行うようにしています。そうすれば、辞退者がいても最低でも5,6人からフィードバックを得られます。
いい目安。とりあえずメモだけ。
やっぱり、実際にやること・やったことと照らし合わせて読むと、理解度とかも違いますね。自分が知りたかったことが知れた（収束に至るまでのやり方）のもよかったし、それ以外でもいくつか引き出しができた。今後デザインスプリント自体をがっつりやるかはさておき、一つレベルアップできたんじゃないかな。
「エッセンシャルスクラム」を読みました
だいぶぶりの読書感想ブログ。ノルマ的にこなしていかんと、なかなか進まないなあ。いつも言ってる気がするけど。
ということで、これも今更ながらの名著です。実際には、スクラムガイド2017での変更点の紹介 | Ryuzee.comやスクラムで削除された5つのトピック | Ryuzee.comのように、スクラムガイドも細かく更新されています。が、本質的なところはそう変わってないはずなので、ちゃんと読んでおくべきだと判断しました。
エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)
- 作者: Kenneth Rubin,岡澤裕二,角征典,高木正弘,和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2014/07/08
- メディア: 大型本
- この商品を含むブログ (7件) を見る
第1章 イントロダクション
クネビンフレームワーク。開発プロセスの提案をすることもときどき出てきた立場として、アジャイルプロセスを適用するかどうかの最初の指針になるもので、盲目的にアジャイルでいくんだーとなる前に考えていいところ。まあ、最近のソフトウェア開発は、大体は複雑な領域に相当するので、それをうまくやっていくためのアジャイルな開発プロセスがマッチするというのはそうなんでしょうけど。
ちなみに、クネビンフレームワークを改めて調べ直して、カオスな領域での適切なふるまいを勘違いしてたことに気づきました。カオスな領域だと、まずはカオスを脱出するために、強力なリーダーシップのもとにコマンド＆コントロールで進めるべきみたいですね。例として挙げられてたのは、9.11 のテロ事件とか。確かに、テロ真っ最中のときに悠長に検査・適応してから進もうってのは苦しい。
と考えると、ソフトウェア開発でカオスな状況って、よっぽどのことですね。本の中では、自分たちのサービスのバグによって不利益をこうむった顧客から、今まさに巨額な訴訟を受けよう最中というのが挙げられてました。
第3章 アジャイルの原則
ここではやっぱり「3.5 仕掛中の作業（WIP）」ですよね。
- 作業は経済的に妥当なサイズにまとめよ
- 在庫を認識し、適切な流れで管理せよ
- 作業者の手待ちではなく、作業の手待ちに着目せよ
- 遅延コストを考慮せよ
この辺は、カンバンの原則にもまんま通じるところがあると思ってます。詳しくは、以前発表した資料を。
第5章 要件とユーザーストーリー
ここは目新しい項目はなかったのだけど、今まで学んできたことを再度確認した章。そうだよね〜とか、あーこれはどうだったっけ？って調べながら、読み進めていきました。キーワード的にはこの辺。
- ユーザーストーリー・エピック・テーマ
- INVEST
- 非機能要件
- 学習のためのストーリー（スパイク）
- ユーザーストーリーマッピング
第7章 見積もりとベロシティ
すでに本書の時点で、ストーリーのサイズ見積もりをしない話がでてました*1。
スクラムを実践している人たちの中には、PBIのサイズ見積もりを必須ではないと考えている人もいる。経験上、成熟したスクラムチームなら、すべてのPBIを同程度のサイズにまとめられると知っているからだ。彼らは、同程度の小さいサイズにまとめられたPBIを前にして見積もりをするのは、時間のムダだと考えている。そんなことをしなくても、単にPBIの和を数えれば、それで十分だというわけだ。
ケースバイケースとは思いつつも、↓の理由から作者はPBIを見積もりたい派で、自分も同じだなー。少なくとも今は。
- 第5章で説明したとおり、すべてのPBIが同時に同じサイズになるわけではない。たとえすべてのPBIのサイズを小さめに揃えることを目指していても、バックログの中には大きめのPBIがいくつか残る。
- チームのメンバーがPBIのサイズを同程度にまとめられるようになるには、それなりに時間がかかる。
- 同じサイズにすることが目的になってしまい、不自然なところでストーリーを分割せざるを得なくなるかもしれない。
- いちばん大切なことだが、見積もりの最大の目的は、話し合う家庭でいろいろな気付きが得られるということだ。何かに対して数字を付けてくれと頼んだりするだけでは、健全な議論が生まれない。意見の相違は見えなくなるだろうし、思い込みがあったとしても表には出てこなくなる。見積もりをやめてしまうのなら、健全な議論をうながすための何らかの手を他に探す必要がある。
この辺も思い出したので、参考がてらはっておこう。
第8章 技術的負債
今自分の中でホットな話題ｗ どういうものかはある程度感覚としてあるので、主にどういう風に解決していくべきか？という視点で読んでました。その中であがったのが、以下の2節。
- 技術的負債の可視化
- 技術的負債の返済
技術的負債の可視化
可視化については、ビジネスレベル / 技術者レベルでの可視化があるとのこと。ビジネスレベルではベロシティへの影響を与えるかどうかで考えるのが分かりやすそう。ベロシティが半分になれば、倍の作業コストなり遅延コストがかかるよねという感じで。
技術者レベルでの可視化については、障害管理システム / プロダクトバックログで障害を扱う / 技術的負債バックログの3つがあげられてました。それぞれ、負債の量が少ない順という感じかな。負債がすくなければ、不具合と同じレベルで障害管理システムに突っ込んでおくぐらいでいいし、もうちょい大きいものならばPBIとしてプロダクトバックログにつっこむ。負債が多い場合は、それ専用のバックログを用いて、かつそれをちゃんとスプリントプランニングで考える必要がある（けど、管理だけして忘れがち。。。）
技術的負債の返済
返済の手法で気になったのは、以下の3つかな。
- ボーイスカウトルールに従う（負債を見つけたらその場で返済する）
- 技術的負債の返済はインクリメンタルに
- 技術的負債を返済しながら顧客に価値をもたらす作業も行う
ボーイスカウトルールは好きなんだけど、無制限にその場で返済し続けるわけにもいかないですよね。一定の割合に収めるというのが大事そう。
残り2つは、一括返済じゃなくて徐々に返済していこうという話。一括は考えやすいんだけど、それは問題を先送りにして楽な方に逃げてたつけなのかもですね。ご利用は計画的に。
「技術的負債返済スプリント」だとか「リファクタリングスプリント」などといった言葉がチーム内で出てきたら、危険信号だ。（中略）私に言わせればそれは大量の負債を一気に支払うということだ。実際のところ、そんなコメントが出てくるというのは、技術的負債がそんなにふくれあがるまで負債の削減など気にしていなかった証に他ならない。
↑の「技術的負債バックログ」と合わせた手法も紹介されてました。こういうのもよさそう。
第9章 プロダクトオーナー
だんだん疲れてきたのでｗ、後から参考にできるように、ここでは最低限の表だけで。
| 開発の種類 | プロダクトオーナーの候補 |
|---|---|
| 社内開発 | そのソリューションによって恩恵を受けるビジネスエリアの代表や顧客 |
| 商用開発 | 実際の顧客やユーザーの組織内プロキシ（プロダクトマネージャー、プロダクトマーケッター、プロジェクトマネージャーなど） |
| 外部委託開発 | そのソリューションに支払い、恩恵を受ける会社の代表や顧客 |
| コンポーネントチーム | 技術的なバックログの優先順位をうまく受けられる技術者 |
最後のコンポーネントチームだけは、ちょっと疑問に思った。コンポーネントチームを作るのは、悪手だと思ってるので。コンポーネントチームはそれ単体ではユーザーに価値を出さないし、コンポーネントを利用するフィーチャーチームからすると外部のコンポーネントチームに依存するので、クロスファンクショナルにならなさそう。
というのを、第12章の「12.2 フィーチャーチームかコンポーネントチームか」に書いてあった。
第10章 スクラムマスター
「1日の様子」が面白かった。スクラムマスターのやることとして、下記のようなアクティビティがある。
- インペディメントの除去
- コミュニケーション
- チェンジエージェント
- プロダクトオーナーの支援
- チームのコーチ
- スクラムのアクティビティ
スプリントの最初と最後はスクラムのアクティビティ（スプリントプランニングやレビューなど）が占めるのはそのとおりだけど、それ以外の日は5割ぐらいインペディメントの除去に費やされてた。まあそうだよね。
第11章 開発チーム
ここでは、開発チームの特性かな。「よりいいチームになるために、どこを頑張っていけばいいと思う？」みたいな問いかけのときに、こういうのを思い返してもよさそう。
- 自己組織化
- 機能横断的な多様性と十分な能力
- T型スキル
- 銃士の姿勢
- 広帯域のコミュニケーション
- 透明なコミュニケーション
- 適切な規模
- 集中とコミットメント
- 持続可能なペースで仕事する
- 長寿
第12章 スクラムチームの構成
「12.3 複数チーム間での調整」で、スクラムオブスクラム・リリーストレインという2つの手法が紹介されてましたが、後者の方に興味をひかれました。ちょいちょい見たことはあったのですが、SAFeでも定義されてたんですね。SAFeはほとんど知らないのですが、いつかちゃんと見ておきたい。今の自分の立ち位置だと直接関わることはほぼなさそうですが。
第13章 マネージャー
マネージャーの責務として、一番根幹だと思うものを一つだけ取り上げておこう。
境界を定める
- マネージャーが、プロダクトやプロジェクト（砂場）を定める
- マネージャーが、チームの構成を決める（誰をどの砂場で遊ばせるかを決める）
- チームは、それぞれの砂場の中で自己管理する
第15章 さまざまなレベルでのプランニング
プランニングのレベル。スクラムで主に意識するのは、リリース・スプリント・デイリーぐらいまでだろうけど、プロダクトやポートフォリオ*2もあるよと共通言語を持っていると、話が早いだろうなとは思った。例えば、いまのうちの会社に照らし合わせると、ポートフォリオプランニングはあれで、プロダクトプランニングはロードマップ含めたあの辺かなという感じ。
| レベル | 範囲 | 誰が作るか | 何を対象にするか | 成果物 |
|---|---|---|---|---|
| ポートフォリオ | おそらく年単位 | ステークホルダーとプロダクトオーナー | プロダクトのポートフォリオの管理 | ポートフォリオバックログ、そして仕掛中のプロダクト群 |
| プロダクト | 数ヶ月単位か、あるいはもっと長期 | プロダクトオーナー、ステークホルダー | ビジョン、そしてプロダクトの成長 | プロダクトのビジョン、ロードマップ、そして概要レベルのフィーチャー群 |
| リリース | 3ヶ月から9ヶ月程度 | スクラムチーム全体、ステークホルダー | 顧客に届ける価値と全体的な品質について、スコープやスケジュールそして予算などの制約の範囲で継続的にバランスを取る | リリースプラン |
| スプリント | イテレーションごと（1週間から1ヶ月） | スクラムチーム全体 | 次のスプリントでどのフィーチャーを出荷するか | スプリントゴール、そしてスプリントバックログ |
| デイリー | 毎日 | スクラムマスター、開発チーム | コミットしたフィーチャーをいかに完成させるか | 進捗確認、そしてその日の作業をうまく進めていくための調整 |
第16章 ポートフォリオプランニング
この章からは、やっぱ遅延コストかな。よさげな概念だとは思うんだけど、まだ理解しきれていない。次かその次に感想ブログあげる予定のリーンエンタープライズでも出てきてるので、そっちも合わせて考えてみよう。
なお、ポートフォリオレベルでのプランニングとは言ってるけど、別にポートフォリオに限らずプロダクトレベルやリリースレベル以下でも十分に適用できる内容も多かったです。上記の遅延コストもそうですし、小さなリリースとか、WIPの制限、作業者の手待ちじゃなくて作業の手待ちとかとか。
第23章 未来へ
「23.4 スクラムを使って、進むべき道を探し出せ」がよかった。スクラムを広げる際、まずは少数のチームから始めて次に組織全体に広げていくことになったお話。全体に広げるときにやるべきことをバックログとして管理して、3週間のスプリントで見直しながら取り組んでいったというお話。開発じゃなくても物事を進めるときのフレームワークとしてスクラム（のエッセンス）を使うのもよさそうです。
最後に小ネタですが、高校の合唱コンクールでキロロの「未来へ」をピアノ伴奏しました。男の人がピアノ弾くと、映えるのでオススメです♪
スクラム自体というより、スクラムをうまくやるための周辺の考え方やツールなどが役に立ちました。スクラムのルール自体は、スクラムガイドで分かるしね。
ちなみに、ブログ書くときは再度読み直すのでこれも2周目なのですが、今回はいつにもまして以前読んだことをまったく覚えていない。。。まあ、だからこそ改めて読み直す意義があるのでしょうが。
Atlassian Team Playbookを自分なりにまとめてみたよ（ヘルスモニター）
Atlassian Team Playbookなるものが出てました。なんかよさげな感じはあったのですが、イマイチ頭に入ってこなかったので、自分なりの解釈を含めてまとめてみました。
まずはヘルスモニターから。気が向けば、残り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 のはてなブログでも読んでたのですが、カンバンはもっと突き詰めていきたいところなので、他の本で別の視点の意見も取り入れていきたいですね。ということで。
今すぐ実践！ カンバンによるアジャイルプロジェクトマネジメント マイクロソフト関連書
- 作者: Eric Brechner
- 出版社/メーカー: 日経BP社
- 発売日: 2016/07/14
- メディア: Kindle版
- この商品を含むブログを見る
第1章 経営陣の同意を得る
カンバンを導入する際に、経営陣の同意を得やすくするプロセスについて。幸いにも、今の自分はある程度権限を与えられているので、ここにすごく力を費やす必要はないけれども、いつもいつもそういう恵まれたケースばかりじゃないだろうから、頭に入れておこう。
印象に残った項目は、この辺。
第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：サステインドエンジニアリング。多分カンバンが一番有効で、使いこなせたらよりよくなるんじゃないかと思ってる領域。要するに、運用保守開発で、事前に計画出し切ることが難しい・突発的に起きうるタスクが多い領域ですね。そういやスクラム現場ガイドでも出てきたので、今一度読み返しておこう。
最初に検討するのは、SE専門チームにするか、コアエンジニアリングチーム（プロダクトのロードマップを進めるチーム）が担当するか、の2択。
| メリット | デメリット | |
|---|---|---|
| SE専門チーム | コアエンジニアリングチームがロードマップを進めることに専念できる | SEチームのメンバーは、あまり意欲的でないかもしれない |
| コアエンジニアリングチームが担当 | SE業務を根本解決するモチベーションがわく | SE業務によって、チームの作業が頻繁に妨げられる可能性がある |
次は、注記から引っ張ってくるけど、この辺ははっとした。極端な話、不具合0になれば不具合分のサポート業務は減らせて、より攻めの業務に時間費やせますよね。もちろん、そこまで目指すかどうかはケースバイケースにはなりますが、頭の片隅に入れておいていい考え。
コアエンジニアリングチームの作業がそこまで遮られる理由に目を向けることが重要となります。たとえば、全体的な品質の問題に対処すれば、サポートリクエストの数を最小限に抑えることが可能かもしれません。
章末のトラブルシューティングからは、この辺かな。
問題1：コアエンジニアリングチームにカスタマーサポートからのエスカレーションが殺到し、対応しきれないほどのバックログが生成されている
問題5：エスカレーションの数が予測できないため、チームの保守計画に支障が生じている
問題1は、何が問題かを見える化してからそれに対応するという、まあ基本ですよね。場合によっちゃ、SEに入る前のプロダクトの品質に問題があるかもしれないので、品質を高める活動が必要になるかもしれない。問題5は、予測不可能だからこそカンバンが有用だよ、けどカンバンで透明性を少しでも高めてスループットやリードタイムなどから予測できるようにしようと。
第9章 さらなる方策とカンバンを超えて
カンバンに関連する理論や手法について。多かれ少なかれ知ってるのもあるし、初めて聞いたのもあったけど、頭に留めておこう。
- 一個流し
- 制約理論（TOC）
- ドラム・バッファー・ロープ
- クリティカルチェーン
- リーン開発
- 全体最適化
あえてやってるんだろうけど、同じような語り口・パターンでの説明が続いて、単調に＆ちょっと無理があるように感じた場面もちょいちょい。まあでもカンバンについて、別の視点から見るという意味でも、ちょい忘れかけてたことを再度確認するという意味でも、ちょうどいい1冊でした。
「ザ・コーチ」を読みました
購入のきっかけは、1on1などに組織的に対応するフェーズになってきたことで、今回2018年の年始目標を立てるのに読み返しました。
- 作者: 谷口貴彦
- 出版社/メーカー: プレジデント社
- 発売日: 2012/05/31
- メディア: Kindle版
- この商品を含むブログを見る
第2章 目標の達人への道
目標設定における、各言葉の定義とその関係性。細かいところはおいておいても、この図は関連を表すのにすごくわかりやすかった。合わせて、一番低レイヤの「目標」は具体化させるときには大事だけど、それだけではモチベーションがわかないので、「目的」や「ゴール」さらには「ビジョン」もセットで考える、というのはそうだよなあと。
第3章 価値ある恩恵
↑の「目的」や「ゴール」を明確にしておくと、どういう恩恵があるかどうかについて。色々触れられていたけど、この辺が今の自分にしっくりきたかな。
- 「目的」や「ゴール」に自然と意識が向くので、情報をキャッチしやすくなる・学習意欲が高まる
- 「目的」や「ゴール」に向かう過程で、選択力・決断力・集中力が増し、パフォーマンスが出やすくなる
確かに、この辺定期的に思い出さないと、すぐ忘れちゃうんですよね。
第5章 始まりの日
Q : 組織において部下にゴールを設定する時のポイントは何か？
A : 会社の目標と個人の目標の接点を見つけて共有する
Answer はもっともなことなんだけど、どこまで接点を見つけることができるんだろうというのは、ちょっと疑問にも残った。完全にトップダウンでの目標設定よりはもちろんましだけど、接点を見つけるにも見つけられないときもあるだろうし。まあそれがずっと続くようだったら、色々ミスマッチということでそもそも論になるので、そこまでいかないケースをできるだけ拾い上げるということかな。
第6章 真実が姿を現す時
行動計画表として、下記のようなものが例示されていた。こういうの、いいよね。全体像の中で、今どこまできているかが分かりやすい。今の自分はここまでは作ってないけど、機会を見て作ってみてもよさそう。
あと、目標設定時のTIPSとして、こういうのが。やった or やらないのTODOもではなく、状態を表す目標文にすべきとのこと。少し気をつけてみよう。
「たとえば、やるべきことを目標にしてしまうと、自分への問いかけは、『今日はやるべきことをやったか？』という閉じた質問になってしまいます。すると、その答えは、『やった』か『やれなかった』ということになります。これだと、発展や成長が感じられないと思いませんか？」」
「はい。確かにそうですね」
「本来の目標とは、作業を消化することではなく、効果的に行動したり、行動から学習したりするための指標です。目標を、目的やゴールに対する通過点や到達点だと考えれば、そのプロセスで自分に問いかける質問は、『今日、僕は目標に向けてどんなことをやったのだろうか？』とか『もっと効果的に進むためには、どうすればいいだろうか？』という開かれた質問になるのではないでしょうか。これこそが重要なのです。・・・」
第7章 自分に正直に生きる
<価値観を知るための言葉リスト> というのがあった。それで思い出したけど、持ち味カードというのを某コーチが使ってたのを見て、これ引き出しの一つとして使えそうだなーというのを改めて思い出したんだった。使い方見るに、1on1やチームビルディングの一環としても使えるし、採用基準作りなどにも使えそうなので、一度試してみようかしら。
最初読んだときはちょい期待はずれだったかなーと思ったけど、実践する際にはかなり参考になった本でした。タイトルにあるコーチのHowToというよりは、目標設定のやり方というのが大きなところ。これを、まずは自分の中でちゃんと消化しつつ、広げていけたらいいな。
あ、最後まで読んで、本の中で取り上げられたワークシートが公式サイトで公開されているのに気づきました。さくっと試すのに、今度機会があったら使ってみよう。
バリューストリームマッピングの本を読みました
正式名称は『トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!』ですが、言いづらいので、「バリューストリームマッピング（VSM）の本」ということでｗ
全体最適の概念をサポートするツールの一つとしての、バリューストリームマッピング。自分の立ち位置・ロール的に、個別最適ではなく全体最適を見据えて動く必要があり、ぜひとも身につけておきたいものの一つだったので、トヨタ生産方式なので製造業についてだけどこの本を購入しました。
トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!
- 作者: マイクローザー,ジョンシュック,Mike Rother,John Shook,成沢俊子
- 出版社/メーカー: 日刊工業新聞社
- 発売日: 2001/08/01
- メディア: 単行本
- 購入: 1人 クリック: 8回
- この商品を含むブログ (5件) を見る
VSMを知らない人は、こっちを読んでおくとざっくりどんなものかが分かりやすそう。DevOpsの文脈で語られてはいるけど、それ抜きにしても多分問題なく理解できる。
序文
序文から、大事なことが書いてあります。
1. チェンジ・エージェントを見つける
2. よいセンセイを見つける
3. 危機を利用して、会社全体を動機づける
しかし、ここで彼らはステップ 5 へ飛んでしまうのです。
5. 重要なテーマを選んですぐにムダ取りを始める
けれども、飛ばしてしまったステップ 4 は、実はもっとも重要なクリティカル・ステップなのです。
4. 全ての製品ファミリーについて最初から終わりまでの全体の「バリュー・ストリーム」のマップを作る
5. でのムダ取りによって個別最適な部分でのカイゼンは達成できるけど、それが全体最適につながるとは限らない。むしろ個別最適されていないところに在庫が溜まって流れがよどみ、フラストレーションを引き起こすかもしれない。なので、まずバリュー・ストリームから全体を眺める必要がありますよね、ということ。
Part III : バリュー・ストリームをリーンにするには？
つくりすぎ
「リーン開発の本質」を読みました - @ikikko のはてなブログで、『「作りすぎのムダ」＝「余分な機能のムダ」が一番タチが悪く他のムダを引き起こすことがある』と紹介していたけど、ここでも同様のことがもうちょい具体例をあげて触れられています。
つくりすぎは、あらゆる種類のムダの原因になります。単に、過剰在庫とその中で眠るお金、という問題だけではありません。部品をまとめてつくったり買ったりすればそれを置いておかなくてはいけないし、置くためのスペースも必要です。置いてあれば運ばなくてはならず、そのために人も設備も必要になります。並びかえたり、修理したり、ということもあるでしょう。また、つくりすぎは欠品の原因にもなります。各工程が必要でないものをつくっているせいで忙しい、というのがその理由です。いま必要でないものをつくるのに人と設備を使っているが故に、余分な人と余分な設備能力が必要になっているのです。つくりすぎはまた、リードタイムも長くしてしまい、お客様の要求に対するフレキシビリティを弱めてしまいます。
製造業の話なので、ソフトウェア開発にそのまま当てはめられないところもありはします。在庫の保管スペース・設備とか持ち運びのコストなど、物理的なものは当てはまらないでしょう。ですが、一度着手すると完成するまでそれをメンテしないといけないとか（ステータスどういう状態になってる？とか、周辺コードの修正によるコンフリクトの解消作業とかとか）、あとちょっとで完成する他のものがあるのに今着手してるもののせいでなかなかそっちに手を出せないとか。
結局この辺も、自分の身の回りの個別最適ではなく、全体最適な視点でどこがボトルネックでそれを解消するには何が必要？を意識しないと抜け出せないので、やっぱりそこに落ち着くのかなーと。
ガイドライン #3：スーパーマーケットを使って、流れ化できない上流の生産をコントロールする
単純に流れ化できない工程において、後工程と前工程をつなぐ仕掛けとして、以下の二つが紹介されていました。
- スーパーマーケット
- 後工程がスーパーマーケット内の部品を必要なときに必要な分引き取り、前工程は引き取られた分だけ部品を補充する
- FIFOレーン
- ある程度量をしぼったキューを用意しておき、その範囲内であれば前工程から後工程に自由に出していいけど、キューの制限を超えた場合は前工程をストップする
二つの違い、正直いまいち分かってません。が、WIP の制限をつける / 後工程が pull 型でコントロールするというのは、いわゆるソフトウェア開発でのカンバンプロセスと一緒だよねという理解はできました。逆に、これやらないと、前工程の都合だけでどんどん作られて在庫が増えてしまい、作り過ぎのムダが発生するよねと。
ガイドライン #5：ペースメーカー工程で、異なる製品を少しずつ繰り返してつくる（機種ミックスを平準化する）
機種ミックスを平準化するということは、一定期間に異なる製品の生産を平らにならして配分することを意味します。たとえば、午前中にタイプAの全数を組み立てて、午後にタイプBの全数を組み立てる、ということをしないで、もっと小さな単位でAとBを繰り返しつくるのです。
この例みて、ちょっとエクストリーム過ぎると最初感じました。部分だけを見ると、明らかにまとめてやったほうが効率よくできそうに感じるので。だけど、部分最適を重視してバッチサイズを大きくしていくと、結局流れが淀んでしまってリードタイムが長くなる・全体最適に支障をきたすというのは、この本だけでなく色んなところで言われてることなので、そっち方面に倒すよう意識しないとなーと。
全般的に、製造業に対してはすぐにでも使えるぐらい細かくいい本だけど、ソフトウェア開発の文脈ではそのまま使うのはオーバースペックかもと感じました。タクトタイム*1をベースラインとして、秒単位での改善を目安としていくとかとか。ただ、全体の流れ = バリューストリームを見える化して関係者全員で共通認識を持ち、ボトルネックを解決していくというのは、ソフトウェア開発でもやっておくべきことかなと思ってます。
そういう意味では、冒頭に紹介した日本のDevOps変革を促進するバリューストリームマッピング：一般記事｜gihyo.jp … 技術評論社や、@ryuzee さんが以前ポストしていたバリューストリームマップの書き方などを参考にして、あとはやってみるぐらいから始めるのがいいのかな。コーチと自分で素振り的なのはやったことあるけど、やっぱ関係者巻き込まないと効果が薄いので、どっかでやりたいやりたい*2。
Jenkinsの診断サービス：Jenkins Advisor を試してみたよ
Jenkins Worldの1日目キーノートで発表された、Cloudbeesの新しいサービス「Jenkins Advisor」、せっかくなので試してみました。
これは、Jenkinsの稼働状況を診断して、レポートしてくれるサービスです。
設定はそんなに難しくないです。まあ大体Pluginのページに書いていますが。
- （ないならば）Cloudbees のアカウントを取得
- Pluginをいつもの手順でインストール
- 設定画面で、Cloudbeesのアカウントを入力
これだけで、あとは日次もしくは起動時に勝手にスキャンして、登録されてるメールアドレスに診断結果を送信してくれます。何かあやしいところがあれば、対応方法のリンクも一緒についてくる。動いてる状況も判断するのかな？時々だけ送信される指摘項目もあります。診断項目は、以下の4分類。
- Security
- Stability
- Performance
- Best Practice
減るものでもないし、入れておいて損はなさげな。特に、Stability / Performance などは、書籍や参考サイトだけでなく、実際の稼働状況を見ないと適切な診断を下せないこともあるだろうし、そのときの一つの参考情報として。
