カンバンのキホン #カンバン仕事術

2016年5月19日に開催されたKanban Casual Talksでの資料をアップデートしたものです

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. カンバン仕事術 2020/5/28 株式会社アトラクタ 吉羽龍太郎
2. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https://www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリング などが専門領域 2
3. 登壇 各種イベントでの登壇 コーチング オンサイト トレーニング アジャイル開発やDevOps に関するオンサイトコーチ ング アジャイル開発や組織づくり に関するオンサイト トレーニング 認定研修 認定スクラムマスター研修 Suitable for all categories 等の主催 business and personal 執筆・翻訳 技術書やドキュメントの 執筆や翻訳 などなど
4. 吉羽龍太郎 / Yoshiba Ryutaro クラウドコンピューティング、DevOps、インフラ構築自動化、アジャイ ル開発、組織改革を中心にオンサイトでのコンサルティングとトレー ニングを提供。Scrum Alliance認定チームコーチ(CTC) / 認定スク ラムプロフェショナル(CSP) / 認定スクラムマスター(CSM) / 認定ス クラムプロダクトオーナー(CSPO)。青山学院大学非常勤講師 4
5. カンバン仕事術 2016/3/26 Marcus Hammarberg (著), Joakim Sundén (著), 原 田 騎郎 (翻訳), 安井 力 (翻訳), 吉羽 龍太郎 (翻訳), 角 征典 (翻訳), 髙木 正弘 (翻訳) 364ページ / 3,888円 / オライリージャパン ISBN-13: 9784873117645
6. 質問です ✤ あなたは3つの仕事を抱えています。いま丁度締切を迎えました。どちらの状態がいいですか？ ✤ (1) 3つの仕事とも95%は終わっている ✤ (2) 3つの仕事のうち2つは100%終わっている。残り1つは50%までしか終わっていない 6
7. 今日いちばん大事なこと ✤ 「始めるのをやめて，終わらせることを始めよう！」 ✤ 効率を重視すると、同時にたくさんのことを進めたくなります ✤ 結果的にどれも終わらなくなります ✤ 今日の話はそれをやめる方法についてです 7
8. チームで仕事をしている時の課題（例） ✤ 納期によく遅れる ✤ 見積りが不正確なことが多い ✤ 優先度がよくわからない ✤ 色々なところからチームに仕事が来る ✤ 誰が何をやっているのかよくわからない ✤ 要するにチームは仕事に追われている 8
9. どう対処していくと良いだろうか？ ✤ 1. がんばる ✤ 2. 人を増やしてもらう ✤ 3. 良いツールを買ってくる ✤ 4. 逃げ出す 9
10. Opinion vs Fact (意見か事実か) Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 何してるか不明 Opinion (意見) 納期よく遅れる 見積りが不正確 仮説 あちこち から仕事 仕事 に追われている 優先度不明 設計 頑張る 人を増やす ツールを買う 逃げ出す 10
11. 事実としての問題を見つけるところから始める Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 仮説 Opinion (意見) 設計 11
12. 【重要原則】見えないものは改善できない 12
13. 1. まず仕事を見える化してみる ✤ JIRAやRedmineを使って仕事を管理していたとしても、全体はもっとたくさんあるかも しれない（隠れている仕事） ✤ それらを含めて全体を洗い出さないと、「人が何をやっているか分からない」状況が解 決しない ✤ タスクよりも「成果」をベースに洗い出すと良い ✤ これを付箋紙に書いて、大きくて見やすいボードに優先度順に貼ってみる ✤ カンバンによる見える化 13
14. カンバンはどこから始めるのか？ ✤ ✤ 今いるところから始める ✤ Scrumを適用しようとすると、役割・イベント・成果物に影響がでてくる（既存プロセスをいきな り変える）ことになるがカンバンは違う ✤ (余談)とはいえ本来Scrum適用自体も目的化してはいけない ✤ カンバンはメタプロセス的 自分たちが置かれている状況を理解できるようにして、そこから改善する 14
15. 付箋紙の扱いの(超)基本原則 ✤ 1つの付箋紙には1つのことを ✤ ボールペンではなくサインペンを使う（遠くからでも見えるよう） ✤ 他の人が読めるように丁寧に書く（うまい字である必要はない） ✤ 意味なく複数色の付箋紙を混ぜて使わない ✤ 付箋紙の束からの剥がし方重要 15
16. 壁に貼ることでイヤでも見える情報ラジエーターになる
17. 電子ツールを使うのであれば冷蔵庫化を防ぐこと (物理カンバンと併用もできる!!) fl https://www. ickr.com/photos/bradipo/5617896008/
18. 見える化する上での電子ツールの弊害 ✤ 中身を見ることに対して、明確な意思を必要とする ✤ 自分たち以外からは見えない ✤ 入力項目が多く、使うのに時間がかかる ✤ 物理的に汚くならないので、論理的なゴミ箱になりやすい ✤ つまり臭いものにフタをしてしまいがち ✤ => 全員同席の環境であれば、まずアナログでやってみる ✤ => とはいえ、このご時世でリモートチームが増えているので、これらの弊害を防ぐ活動が必要 18
19. 2. ワークフロー（流れ）を定義する ✤ 仕事がチームに来たところから出て行くまでのステージを特定する ✤ いきなり完璧を目指さず、検査と適応で改善していく（後で追加してOK） ✤ 顧客に価値を生み出すまで仕事は完了しないことを覚えておく ✤ このステージの遷移（＝ワークフロー）を見える化する ✤ それぞれのステージに洗いだしたタスクをマッピングする ✤ ステージが少ない（作業 => レビュー）こともある。このときはワークフローというより状態として見え る 19
20. 例 いまの状態を把握できるようになった 20
21. 例 特定のステージに仕事が積み上 がっている場合潜在的な問題が あるかもしれない 21
22. 作業項目（付箋） ✤ 自分だけが分かるのではなく他の人にわかるようにする ✤ ただ付箋に「○○機能」みたいに書かれてもわからない ✤ 詳細すぎる必要はない ✤ 形式はなんでもOK。レイアウトはみなで揃える ✤ チケットのID、発生日、納期、進捗インジケーター、サイズ見積り・リスク情報などを入れたりする(自 分たちで決める。やりすぎないこと) ✤ 障害やバグのような緊急のものは違う付箋紙の色を使うのも良い 22
23. 3. 担当者を見える化する ✤ 付箋紙に名前を書いてもよいが、スペー スに限りもあるし、途中で担当を変えるか もしれない ✤ こういうときにはアバターを使うのが定番 ✤ 1人あたりの個数を制限するのも良い手 (抱え込み防止) アジャイルコーチの道具箱 - 見える化の実例集 P.11よ り 23
24. ここまでで分かるようになったこと ✤ どれだけの仕事があるか ✤ どんな種類の仕事があるか ✤ それぞれの仕事はどのようなステップを踏むのか ✤ それぞれの仕事が今どういう段階にあるのか ✤ 誰がなにをやっているか 見えないものは改善できない。なのでまず見えるようにした 24
25. リードタイムとサイクルタイムと仕掛り作業(WIP) ✤ リードタイムとは一連(全体)のプロセスに入ってからそれを出て顧客に届くまでの時間のこと ✤ これは短い方がよい（速い流れ） ✤ 短ければ、いつ届くのかを聞かれたり、催促されることが減る ✤ サイクルタイムとは1つの作業がステップを抜けるのに要する時間 ✤ 仕掛り作業(WIP)とは作業中の項目のこと 25
26. リトルの法則 サイクルタイム = そのステップでの仕掛り作業の数 / そのステップの処理能力 ✤ 月に12個の作業を完了させる能力があると仮定して ✤ 同時に12個を実施すると、サイクルタイムは1か月 ✤ 同時に6個にすれば、サイクルタイムは0.5か月 ✤ 同時に実施する個数が増えれば、サイクルタイムが長くなる ✤ 同時に実施する個数が減れば、サイクルタイムが短くなる 26
27. 多すぎる仕掛り(WIP)の弊害 ✤ コンテキストスイッチの増大 (あれさっき何やってたっけ？) ✤ 遅れると仕事が増える (いつ終わるのか報告してよ！) ✤ リスクが増える (他の会社が先にリリースしちゃいました！) ✤ オーバーヘッドが増える (またいろいろ調整しなきゃ) ✤ 品質が下がる (あのコードってどうなってたっけ？) ✤ モチベーションが下がる (なんでこんなにやることだらけなんだ…) 27
28. 4. 仕掛り(WIP)の数を制限する レーンに入れられる項目数を制限し、 始めるのをやめて、終わらせることを始める 28
29. 仕掛り(WIP)の数を制限をどう決めるか ✤ 多すぎると流れが遅くなる (作業の手持ち) ✤ 少ない方が良いが、少なすぎると待ち時間が増える (作業者の手待ち) ✤ WIP制限は厳密なルールではなく、議論のきっかけであり、改善を推進する方法にすぎない ✤ 絶対こうしろという数字はない。検査と適応を続ける ✤ 最終的には制限をかけなくても流れるようになるのがゴール (早い段階でやってはダメ) 29
30. 緊急の仕事への対応 ✤ 障害やバグ対応など通常の優先順位でない急ぎの仕事もある ✤ それを見えるようにするために特急レーンをボードに追加する ✤ 特急レーンに入ったものは早く終わるが、その分他のものは時間がかかるようになる(コストを払う) ✤ ズルをするためのレーンではない 30
31. サービスクラス ✤ すべての作業項目が、均等な価値を持つわけではない ✤ すべての作業項目が、同じ時間的な制約を持つわけではない ✤ 作業項目は、なんらかのサービスクラスに属する ✤ よくあるサービスクラスの例(自分たちで設計して良い) ✤ 特急(緊急)、確定納期、通常(標準)、無形、欠陥 ✤ サービスクラス間で、優先順位に違いがある ✤ サービスクラスはWIP(同時仕掛り数)や全体の優先順位の決定に影響を与える ✤ 1つの項目が複数クラスに該当しそうなら、項目を分割するのも良い 31
32. サービスクラスの例 特急(緊急) いますぐ急いでやらないといけないもの 確定納期 特定の期日またはそれより前に完了していないといけないもの。期日にあうようにスケジュールを立 てる必要があるが、早すぎも良くない 通常(標準) 通常の項目。多くはこのサービスクラスになる 無形 ビジネス価値がなかったり見積もれないが、それでいて重要なもの。優先順位の低い欠陥、UIの軽微 な改善など。定期的にまとめて実施する手もある 欠陥 バグや障害など。特定のワークフローをスキップすることもある 32
33. サービスクラスの配分 ✤ 特急(緊急)以外のサービスクラスの項目 について、どれくらいの比率で行うかを 決めておくこともできる ✤ 定期的に割合を分析して、改善ポイント をさぐったり適切な割合を見つけるのも よい ✤ 緊急（だが重要ではない）タスクを減ら さないと価値が生まれない 無形の仕事が緊急になるまで放っておくと身動きがとれなくなる 33
34. キューと進入・退出条件 Todo 開発 分析 作業中 完了 作業中 何を満たすと完了/引き取り可能になるのか を明らかにする テスト 完了 受入 作業中 完了 次工程が項目を引き取れることを明示する。 WIP制限を設定しておくことも可能 34
35. メトリクス ✤ さらに改善を進めるために使える ✤ 人事評価のためではない ✤ リードタイム(ワークフロー全体の時間)とスループット(一定期間で完了した量)が役にたつ ✤ 例えばワークフローに入れた日付と完了した日付を記録するのもよい 35
36. 流れをよくするためには？ ✤ 再作業を避ける（逆流させない。すなわち品質を作りこむ） ✤ 待ち時間を減らす：自分のワークフローの外に出ていかないといけないこともある ✤ 次の作業の準備ができているようにする ✤ 作業項目を小さく、同じようなサイズにする（予測性も向上する） ✤ ブロッカーを取り除く ✤ スウォーミング（みんなで群がって素早く解決する） ✤ 質の低い要求を取り除く ✤ クロスファンクショナルチーム ✤ スタンドアップミーティングの活用 36
37. 再作業を避ける!! ✤ 前工程は神様 後工程はお客様 ✤ 前工程がきちんとした品質のものを届けてくれるのに感謝 ✤ 顧客とは実際のエンドユーザーだけでなく、内部の後工程も指す ✤ 品質を作りこむ。そして不良を次工程に回さない ✤ つまり自工程完結 37
38. ボトルネック ✤ ボトルネックの箇所で全体の流れの速度が決まってしまう ✤ ボトルネックの上流のスループットが高いとボトルネックの直前にたまる ✤ ボトルネックの下流でスループットをあげてもやることが少ない ✤ 対処方法は (1) 制約を特定する (2) その制約を徹底的に活用する (3) 制約以外を制約に従属させ る (4) 制約の能力を向上させる (5) これを繰り返す ✤ 例えば(3)は品質を作りこむことで同じ作業が2回そこを通るムダを無くすなど 38
39. 応用編：前工程・後工程の分割 ✤ 工程間に前後関係があって、担当部署やチームが違う場合にはカンバンを複数にすることもある 39
40. ケーススタディ(1) ボトルネックはどこ？ WIP: 2 2日/ 機能 WIP: 4 3日 / 機能 WIP: 6 2日/ 機能 WIP: 1 20日 / 機能 分析 開発 テスト QA / デプロイ Dev Ops $$$$ 40
41. ケーススタディ(1) ✤ このケースではリードタイムはとても長い ✤ 理由は、QA/デプロイが20日も占めていること ✤ さらに同時に1つしかデプロイできないのでスループットも低い ✤ ここでDevチームの生産性を向上させても全体のリードタイムとスループットの向上はわずか 41
42. ケーススタディ(2)ボトルネックはどこ？ 不具合… 分析 デプロイ拒否 修正待ち… 開発 Dev テスト QA / デプロイ Ops $$$$ 42
43. ケーススタディ(2) ✤ このケースでは開発工程で手戻りが頻発している ✤ デプロイを自動化しても開発工程のリードタイムは長いまま ✤ 全体のリードタイムの増大はソフトウェアの低品質が原因なので、デプロイ自動化の効果は限定的 43
44. 44
45. 全体の流れが悪く見えたら？ ✤ バリューストリーム（価値の流れ）全体を見直す ✤ ボトルネックを探す ✤ 部門をまたぐ場合は難易度があがる ✤ 部分最適から全体最適への挑戦 ✤ 何かを変更するとボトルネックが移動することもある 45
46. カイゼンのパターン：工程をなくす(Eliminate) Before 工程A After 工程A 工程B 工程C 工程C 46
47. カイゼンのパターン：工程を統合する(Combine) Before After 工程A 工程B 工程A 47
48. カイゼンのパターン：順番を変える(Rearrange) 手戻り Before 工程A 工程B 工程C After 工程C 工程A 工程B 48
49. カイゼンのパターン：単純化する(Simplify) 工程 B1 Before 工程A 工程B 工程C 工程 B2 After 工程A 工程B 工程C 49
50. まとめ：カンバンの3原則 ✤ 見える化 ：仕事やプロセス、それに対する理解の差異がわかる ✤ WIPの制限：1つ1つを早く終わらせる ✤ 流れの管理：仕事がワークフローを速く流れるようにする。 ボトルネックを見つけて対応する 50
51. あわせてどうぞ！ アジャイルコーチの道具箱 – 見える化実例集 すごいチームはどう見える化している？ Jimmy Janlén(著) 原田騎郎(翻訳), 吉羽龍太郎(翻 訳), 川口恭伸(翻訳), 高江洲睦(翻訳), 佐藤竜也(翻 訳) #見える化実例集 https://leanpub.com/agiletoolboxvisualizationexamples-japanese

Comment

No comments...