1. カンバンのキホン ∼始めるのをやめて、終わらせることを始めよう∼ 2016/6/17 @Ryuzee
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する 従量課金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee
3. 提供サービスの概要 アジャイルコーチング Agile開発については多くの誤解があり、 また経験の無いチームが自力で行うのは 難易度が高いものです。当方ではオンサイ トでAgile開発での企画∼開発まで全工程 を支援します。例えばプロジェクト立ち上 げに際しての集合研修、ふりかえりや計画 ミーティングのファシリテーションな ど。 DevOps実践支援 Cloud Architecting支援 ビジネスの成長やシステムの利用状 況に柔軟に対応できるのがクラウド の特性ですが、一方でシステムアー キテクチャがレガシーであればその メリットを享受できません。本支援 ではマイクロサービス化を始めとし て、柔軟で結合度の低いクラウドネ イティブアーキテクチャの構築を支 援します。 DevOpsには組織とツールの2つの要 技術顧問・執筆・講演 素があります。サイロ型の組織構造 技術顧問として定期的に訪問した のDevOps型組織への転換(組織デザ り、Agile・DevOps・クラウドに関 イン、採用プロセス、評価プロセ する講演をいたします。またWeb・ ス)、ツールによるデプロイ・プロビ 書籍・雑誌など各媒体向けの執筆・ 翻訳を行ないます。 ジョニング・運用・監視の自動化な ど幅広い側面で支援します。 主な提供トレーニング：「強いチームの作り方」「スクラム(半日∼2日)」「Chef入門」「カンバン入門」など
4. カンバン仕事術 2016/3/26 Marcus Hammarberg (著), Joakim Sundén (著), 原田 騎郎 (翻訳), 安井 力 (翻訳), 吉羽 龍 太郎 (翻訳), 角 征典 (翻訳), 髙木 正弘 (翻訳) 364ページ / 3,888円 / オライリージャパン ISBN-13: 9784873117645
5. 本書の構成 ✤ 第I部 カンバンの学習 ✤ ✤ ✤ 1章 チーム「カンバネロス」のはじまり 第II部 カンバンの理解 第III部 カンバンの応用 ✤ 8章 サービスクラス ✤ 9章 計画づくりと見積り ✤ 2章 カンバンの原則 ✤ 10章 プロセスの改善 ✤ 3章 作業の見える化 ✤ ✤ 4章 作業項目 11章 改善のガイドとなるメトリクスの 使用 ✤ 5章 仕掛り作業 ✤ 12章 カンバンの落とし穴 ✤ 6章 WIP制限 ✤ 13章 ゲームで教えるカンバン ✤ 7章 流れの管理 ✤ 付録
6. 本書の読み方 ✤ さくっとカンバンの全体像を知りたい => 第I部 (約40ページ)から ✤ 原理・原則や背景を知りたい => 第II部 ✤ 既に使っていてもっとよくしていきたい => 第III部
7. チームの課題 (例) ✤ 納期によく遅れる ✤ 見積りが不正確なことが多い ✤ チームは仕事に追われている ✤ 優先度がよくわからない ✤ 色々なところからチームに仕事が来る ✤ 誰が何をやっているのかよくわからない
8. カンバンはどこから始めるのか？ ✤ ✤ 今いるところから始める ✤ Scrumを適用しようとすると、役割・イベント・成果物に影響がでて くる（既存プロセスをいきなり変える）ことになるがカンバンは違う ✤ (余談)とはいえ本来Scrum適用自体も目的化してはいけない ✤ カンバンはメタプロセス的 自分たちが置かれている状況を理解できるようにして、そこから改善する
9. まず仕事を見える化してみる ✤ JIRAやRedmineを使って仕事を管理していたとしても、全体 はもっとたくさんあるかもしれない（隠れている仕事） ✤ それらを含めて全体を洗い出さないと、「人が何をやっている か分からない」状況が解決しない ✤ これを付箋紙に書いて、大きくて見やすいボードに優先度順に 貼ってみる
10. 付箋紙の扱いの(超)基本原則 ✤ 1つの付箋紙には1つのことを ✤ ボールペンではなくサインペンを使う（遠くからでも見えるよう） ✤ 他の人が読めるように丁寧に書く（うまい字である必要はない） ✤ 意味なく複数色の付箋紙を混ぜて使わない ✤ 付箋紙の束からの剥がし方重要
11. 壁に貼ることでイヤでも見える情報ラジエーターになる
12. 電子ツールを使うのであれば冷蔵庫化を防ぐこと (物理カンバンと併用もできる!!) https://www.flickr.com/photos/bradipo/5617896008/
13. ワークフロー（流れ）を定義する ✤ 仕事がチームに来たところから出て行くまでのステージを特定する ✤ いきなり完璧を目指さず、検査と適応で改善していく（後で追加してOK） ✤ 顧客に価値を生み出すまで仕事は完了しないことを覚えておく ✤ このステージの遷移（＝ワークフロー）を見える化する ✤ それぞれのステージに洗いだしたタスクをマッピングする
15. 例 特定のステージに仕事が積み 上がっている場合潜在的な問 題があるかもしれない
16. 作業項目（付箋） ✤ 自分だけが分かるのではなく他の人にわかるようにする ✤ ただ付箋に「テスト仕様書」みたいに書かれてもわからない ✤ 詳細すぎる必要はない ✤ 形式はなんでもOK。レイアウトはみなで える ✤ チケットのID、発生日、納期、進 インジケーター、サイズ見積り・リス ク情報などを入れたりする(自分たちで決める。やりすぎないこと) ✤ 障害やバグのような緊急のものは違う付箋紙の色を使うのも良い
17. 担当者を見える化する ✤ 付箋紙に名前を書いてもよい が、スペースに限りもあるし、 途中で担当を変えるかもしれ ない ✤ こういうときにはアバターを 使うのが定番 ✤ 1人あたりの個数を制限する のも良い手(抱え込み防止) アジャイルコーチの道具箱 - 見える化の実例集 P.11より
18. ここまでで分かるようになったこと ✤ どれだけの仕事があるか ✤ どんな種類の仕事があるか ✤ それぞれの仕事はどのようなステップを踏むのか ✤ それぞれの仕事が今どういう段階にあるのか ✤ 誰がなにをやっているか 見えないものは改善できない。なのでまず見えるようにした
19. リードタイムとサイクルタイムと仕掛り作業(WIP) ✤ リードタイムとは一連のプロセスに入ってからそれを出て顧客に届くまで の時間のこと ✤ これは短い方がよい（速い流れ） ✤ 短ければ、いつ届くのかを聞かれたり、催促されることが減る ✤ サイクルタイムとは1つの作業がステップを抜けるのに要する時間 ✤ 仕掛り作業(WIP)とは作業中の項目のこと
20. リトルの法則 サイクルタイム = そのステップでの仕掛り作業の数 / そのステップの処理能力 ✤ ✤ 月に12個の作業を完了させる能力があると仮定して ✤ 同時に12個を実施すると、サイクルタイムは1か月 ✤ 同時に6個にすれば、サイクルタイムは0.5か月 同時に実施する個数が減れば、サイクルタイムが短くなる
21. 多すぎる仕掛り(WIP)の弊害 ✤ コンテキストスイッチの増大 (あれさっき何やってたっけ？) ✤ 遅れると仕事が増える (いつ終わるのか報告してよ！) ✤ リスクが増える (他の会社が先にリリースしちゃいました！) ✤ オーバーヘッドが増える (またいろいろ調整しなきゃ) ✤ 品質が下がる (あのコードってどうなってたっけ？) ✤ モチベーションが下がる (なんでこんなにやることだらけなんだ…)
22. 仕掛り(WIP)の数を制限する レーンに入れられる項目数を制限し、 始めるのをやめて、終わらせることを始める
23. 仕掛り(WIP)の数を制限をどう決めるか ✤ 多すぎると流れが遅くなる (作業の手持ち) ✤ 少ない方が良いが、少なすぎると待ち時間が増える (作業者の手待ち) ✤ WIP制限は厳密なルールではなく、議論のきっかけであり、改善を推進す る方法にすぎない ✤ 絶対こうしろという数字はない。検査と適応を続ける ✤ 最終的には制限をかけなくても流れるようになるのがゴール (早い段階で やってはダメ)
24. 緊急の仕事への対応 ✤ 障害やバグ対応など通常の優先順位でない急ぎの仕事もある ✤ それを見えるようにするために特急レーンをボードに追加する ✤ 特急レーンに入ったものは早く終わるが、その分他のものは時間がかかる ようになる(コストを払う) ✤ ズルをするためのレーンではない
25. キューと進入・退出条件 Todo 開発 分析 作業中 完了 作業中 何を満たすと完了/引き取り可能になる のかを明らかにする テスト 完了 受入 作業中 完了 次工程が項目を引き取れることを明示す る。WIP制限を設定しておくことも可能
26. メトリクス ✤ さらに改善を進めるために使える ✤ 人事評価のためではない ✤ リードタイム(ワークフロー全体の時間)とスループット(一定期間で完了し た量)が役にたつ ✤ 例えばワークフローに入れた日付と完了した日付を記録するのもよい
27. 流れをよくするためには？ ✤ 待ち時間を減らす：自分のワークフローの外に出ていかないといけないこともある ✤ 次の作業の準備ができているようにする ✤ 作業項目を小さく、同じようなサイズにする（予測性も向上する） ✤ ブロッカーを取り除く ✤ スウォーミング（みんなで群がって素早く解決する） ✤ 再作業を避ける（逆流させない。すなわち品質を作りこむ） ✤ 質の低い要求を取り除く ✤ クロスファンクショナルチーム ✤ スタンドアップミーティングの活用
28. ボトルネック ✤ ボトルネックの箇所で全体の流れの速度が決まってしまう ✤ ボトルネックの上流のスループットが高いとボトルネックの直前にたまる ✤ ボトルネックの下流でスループットをあげてもやることが少ない ✤ 対処方法は (1) 制約を特定する (2) その制約を徹底的に活用する (3) 制約 以外を制約に従属させる (4) 制約の能力を向上させる (5) これを繰り返す ✤ 例えば(3)は品質を作りこむことで同じ作業が2回そこを通るムダを無くす など
29. まとめ：カンバンの3原則 ✤ 見える化 ：仕事やプロセス、それに対する理解の差異がわかる ✤ WIPの制限：1つ1つを早く終わらせる ✤ 流れの管理：仕事がワークフローを速く流れるようにする。 ボトルネックを見つけて対応する
31. https://www.flickr.com/photos/chrishuffman/2336990347/ • 左からReady / Requirements / UI Design / Tech Design / Tech Implementation / UI Implementation / Test Design / Test Implementation / Production Readyというレーンになっ ており、流れが分かりやすい • ボード左上に凡例が貼ってあり、付箋の 色ごとに内容が違うのが分かるのも良い • 下の破線以下の用途が分からないが緊急 割り込みタスク用であれば一番上でも良 いかも
32. • Todo / Doing / Doneだけでなく、Ready for QA(QA待ち)等があるのは良い。もしここに積み 上がるようならボトルネックはQAになる • 但しQA待ちのレーンが広すぎるかもしれない。こ の広さが埋まるのはマズイので領域を物理的に狭 めてよい • Doneが山盛りなので掃除しても良さそう • 付箋が反り返っている。貼り方は大丈夫？ • 付箋の色の違いに意味があるかどうか要確認 https://www.flickr.com/photos/dinomite/3219513356/
33. https://www.flickr.com/photos/jimdowning/6129928164/ • 各レーンの箇所に書いてある数字は WIPの制限だと思われる。この制 限を超えて着手したいと思うようで あればプロセスを改善するチャンス • 真ん中の上下に分かれたレーンは、 流れという観点だと分かりにくい。 全てが左から右に流れる方が視覚 的に捉えやすい
34. https://www.flickr.com/photos/sethandalexa/8425381749/ • いわゆるTodo(Planned)の手前(左)にアイ デアカラムがあるのは良い。ここに色々な アイデアを載せておいて優先順位付けや計 画が終わったら隣に移す感じになる。また 封筒はボツネタ入れ？こういうのも Good。あとで分析できる • 左端のボード外にあるのは凡例だと思われ る。これは良い • 一方でPlannedの箇所で貼り方がランダム で優先順位が分かりにくい。右隣に近い側 の上から並べると優先順位が伝わりやすい
35. ボードづくりの注意点 ✤ 楽に更新できるように ✤ みんなのためのもの。見やすい場所に配置する ✤ 情報過多にしない。多すぎる情報はかえって伝わらない ✤ 大きいサイズで！遠くからでも全体を把握できるようにする ✤ 使わないなら捨てる。価値の無い情報は載せない。使わないものを残して おくと他まで使われなくなったりだらしなく感じられる
36. ボードづくりのTIPS ✤ とくに初期ほどステップ(レーン)を追加したり、いろいろな変更をボード に加えることが多い ✤ あとから変更しやすくしておく。最初はテープでレーンを区切ったりしな いで、ホワイトボードマーカーなどを活用
38. あわせてどうぞ！ アジャイルコーチの道具箱 ‒ 見える化実例集 すごいチームはどう見える化している？ Jimmy Janlén(著) 原田騎郎(翻訳), 吉羽龍太郎(翻 訳), 川口恭伸(翻訳), 高江洲睦(翻訳), 佐藤竜也(翻 訳) #見える化実例集 https://leanpub.com/agiletoolboxvisualizationexamples-japanese
