Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
カンバン入門
Search
Kei Shiratsuchi
PRO
October 13, 2016
Technology
5
2.5k
カンバン入門
PFI セミナー 2016/10/13
Movie:
https://www.youtube.com/watch?v=1AnBScrT51s
Kei Shiratsuchi
PRO
October 13, 2016
Tweet
Share
More Decks by Kei Shiratsuchi
See All by Kei Shiratsuchi
モノリスとマイクロサービスの橋渡し - ベターからモアベターへ
kei_s
PRO
0
84
なぜ リアーキテクティング専任チームを作ったのか
kei_s
PRO
2
1.4k
実践 Rails アソシエーションリファクタリング / Rails association refactoring in practice
kei_s
PRO
8
8.3k
「Go言語でつくるインタプリタ」を Rust で移植してみた / "Write An Interpreter In Go" In Rust
kei_s
PRO
1
1.9k
Rust言語で作るインタプリタ / Write An Interpreter In Rust
kei_s
PRO
2
590
育児休業のご報告と、育児グッズとしてのスマートスピーカー / Parental Leave and SmartSpeaker
kei_s
PRO
0
840
「深層学習による自然言語処理」読書会 第6章2.7
kei_s
PRO
0
440
「深層学習による自然言語処理」読書会 第5章5.1
kei_s
PRO
0
420
最近個人的に気になるプログラミング言語おさらい Ruby, Python, Go, Rust, Julia
kei_s
PRO
0
980
Other Decks in Technology
See All in Technology
C++26 エラー性動作
faithandbrave
2
680
podman_update_2024-12
orimanabu
1
260
DevOps視点でAWS re:invent2024の新サービス・アプデを振り返ってみた
oshanqq
0
180
How to be an AWS Community Builder | 君もAWS Community Builderになろう!〜2024 冬 CB募集直前対策編?!〜
coosuke
PRO
2
2.8k
非機能品質を作り込むための実践アーキテクチャ
knih
3
720
Password-less Journey - パスキーへの移行を見据えたユーザーの準備 @ AXIES 2024
ritou
3
1.4k
小学3年生夏休みの自由研究「夏休みに Copilot で遊んでみた」
taichinakamura
0
140
re:Invent 2024 Innovation Talks(NET201)で語られた大切なこと
shotashiratori
0
300
2024年にチャレンジしたことを振り返るぞ
mitchan
0
130
LINE Developersプロダクト(LIFF/LINE Login)におけるフロントエンド開発
lycorptech_jp
PRO
0
120
KubeCon NA 2024 Recap / Running WebAssembly (Wasm) Workloads Side-by-Side with Container Workloads
z63d
1
240
プロダクト開発を加速させるためのQA文化の築き方 / How to build QA culture to accelerate product development
mii3king
1
260
Featured
See All Featured
A Tale of Four Properties
chriscoyier
157
23k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Designing for Performance
lara
604
68k
Code Review Best Practice
trishagee
65
17k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Unsuck your backbone
ammeep
669
57k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
Docker and Python
trallard
41
3.1k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
510
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Building Adaptive Systems
keathley
38
2.3k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Transcript
カンバン⼊⾨
⾃⼰紹介 • ⽩⼟ 慧 (Shiratsuchi Kei) • Preferred Infrastructure(2016年4⽉⼊社) –
Ruby on Rails エンジニア • スタートアップ経験 – 前職:メガネのECサービス(⼀⼈⽬のエンジニア) – 前々職(新卒):レコメンデーションエンジン開発 • ⼤学時代 – 複雑ネットワーク • 趣味 – 妻とポケモンGO(130種) – ⼩説(舞城王太郎)
Table of Contents • カンバンとは? • なぜ? • カンバンを作ってみる •
カンバンを運⽤してみる • カンバンの流れを管理する • まとめ • プラクティス
カンバンとは?
カンバンとは?
カンバンの構成要素 ワークフロー 作業項⽬ アバター
なぜ?
導⼊前のチームの状態 • チーム⼈数: 10+α⼈ • 動いている案件が多い • 携わっているプロダクトが多い • 会議体
– 毎⽇のスタンドアップミーティング – 週⼀度の定例ミーティング
課題感 • 全体を把握する⼈が忙しくなると、回らなくなる – 個別の作業は進むが、全体の取りまとめで⼿こずる – リリースの直前でバタバタする • (⼊社したての私の課題感) 動いている話が多く、脳に乗らない
動機 • チームでもっとスムーズに仕事を進めたい • 「いま忙しい?」って聞かれたくない – 暇なわけない • 「いま忙しい?」って聞きたくない –
すぐ本題に⼊りたい
参考図書 • 「カンバン仕事術」 • https://www.oreilly.co.jp/books/9784873117645/ • 原著 “Kanban in Action”
– Marcus Hammarberg and Joakim Sundén – アジャイルコンサルタント & Spotifyのエンジニア
カンバンを作ってみる
カンバンの作り⽅ 1. ワークフローを定義する 2. 作業項⽬を定義する 3. アバターを配置する 「カンバン仕事術」1章を参照
1. ワークフローを定義する そのうち やりたい 未着⼿ 着⼿中 レビュー中 チームに 出した 確認待ち
完了 レビュー 待ち 社外に 出した
1. ワークフローを定義する • 仕事がチームに⼊ってくるところから、出て⾏くところ まで、すべてのステージを特定する – 本での例: Todo、分析、開発、テスト、受⼊、運⽤待ち、本番 • 完璧を⽬指さない。やりながら改善
• 顧客に価値を⽣み出すまで仕事は完了しない • ワークフローを⾒える化する
2. 作業項⽬を定義する • 作業の説明 – ユーザストーリーを使う? – 「やるべきことを思い出せる 短い説明であれば、なんでも良い」 •
付箋の⾊ – 開発▪、案件▪、その他▪、緊急▪ • タグ – [製品名]、[顧客名] など • 開始⽇、終了⽇ • 書き損じは破って捨てる
3. アバターを配置する • Slack のアイコンを貼り付けた マグネット – 付箋に直接書くと、どんどん ⼈が増えていき、つらい •
マグネットの数が重要(後述)
ポイント:⾒える化 • ワークフローの定義で、仕事がどう進むかがわかる – 暗黙的なフローをチームで議論して、全員が同じよ うに仕事を進めることができる • 作業項⽬をワークフローに並べることで、どこがボトル ネックになっているか把握できる
ポイント:⾒える化 • 情報ラジエーター(発信物)になる – 情報を常にアップデートし、関係者が誰でも必要な 時に参照できるようにする – 「誰が何をやっているか」「どれが終わったのか」 質問する必要がない
ポイント:常に更新できるようにする • ⾒る価値のある状態を保つ • 更新コストを下げる – アクセスしやすいホワイトボードで作る – デジタルはコストが⾼い →
「情報冷蔵庫」 • 最初から綺麗に作りすぎない – ワークフローの更新を気軽にできるように • 物理&⼿書き最強
カンバンを運⽤してみる
WIP の導⼊ • WIP = Work in Process – 同時に作業している作業項⽬の数
• WIP を減らす • 「コイン渡しゲーム」で解説
コイン渡しゲーム • 作業者と計測者でペア + 顧客役ひとり • コインを20枚⽤意 • 作業者は、コインをひっくり返して、次の⼈ に渡す
– 最後の⼈は、顧客に渡す • すべてのコインが顧客に渡ったらゴール • 計測者は、作業者が作業を始めてから終わる までを計測 • 顧客は、全体の時間(最初のコインがゴール した時間と、最後のコインがゴールした時 間)を計測
コイン渡しゲーム • ゲームを3回⾏う • 1回⽬:20枚すべてひっくり返してから、次 の⼈に渡す • 2回⽬:5枚ずつひっくり返したら、次の⼈ に渡す •
3回⽬:1枚ずつひっくり返したら、次の⼈ に渡す • ひっくり返すコイン(仕事の量)は同じ • 個々の作業時間、全体の時間はどうなるか?
コイン渡しゲーム
コイン渡しゲーム 最初のコインが ゴールするまで の時間が短くな る
コイン渡しゲーム 合計時間も短く なる
コイン渡しゲーム 作業者の作業時 間は⻑くなる
WIP を制限する効⽤ • 同時に作業する仕事の数を減らす と、リードタイムが短くなる • それぞれの作業者の効率は落ちる – プロセスをより速い流れに最 適化すると、リソースの稼働
率は低下する – 全員を常時稼働させることは 重要か? minneチームでKPTAのふりかえりとコイン渡しゲームをやった | けんちゃんくんさんの Web⽇記 http://diary.shu-cream.net/2016/05/11/minne-product-team-retrospectives.html
ソフトウェア開発における WIP • 実装されていない仕様 – 放っておくと、腐る • マージされていないコード – ⼿元の開発環境でしか動かない
• テストされていないコード – 正しく動いているかすぐにわからない • リリースされていないコード – 価値を提供できていない
WIP が多い弊害 • コンテキストスイッチが増える • フィードバックが遅れると仕事が増える – バグ報告が遅くなると、調査に時間がかかる • リスクが⾼まる
– 時代遅れになる可能性 • オーバーヘッドが増える – WIP 同⼠の調整が必要になる • 品質が低下する • モチベーションが低下する
WIP を制限する • 原則: 「始めるのをやめて、終わらせることを始めよう」 – 現在の作業を終わらせる前に、他の作業に着⼿しな い – 同時に⾏う作業の数を制限する
• WIP 制限に答えはない – 実際に試してみて、調整する
WIP を制限するアプローチ 1. ボード全体、チーム全体で制限する – チーム⼈数の1.5倍の数だけ着⼿できることにする 2. ワークフローの列ごとに制限する 3. ⼈に対して制限する
2. ワークフローの列ごとに WIP 制限する • 列に滞留できる項⽬の数を制限する • 分析から開発にするには、開発中の作業を2以下に減らさなければ開始できない • 例:レビューが溜まってしまったら
– レビューできる⼈を増やす必要があるのではないか – レビューに時間がかかっているのではないか。事前共有ができていないの ではないか
3. ⼈に対して WIP 制限をする • アバターの数を制限する – 4つ以上の作業に着⼿できないようにする • 例:フルで埋まっている⼈がいたら
– 作業の肩代わりができないか – その⼈以外も作業できるようにするにはどうすればいいか
WIP 制限はゴールではない • 流れを改善することがゴール • WIP 制限は、流れを阻害する問題を⾒つけやすくする ツール – ボトルネックの発⾒
– 問題点の改善
カンバンの流れを管理す る
流れの管理 • 「流れ」は、すべてのステップで邪魔や待ち時間が発⽣せず 価値を⽣み出している理想的な状態 • 流れるようにするために – WIP を制限する –
ブロッカーを取り除き、待ち時間を削減する – 品質を作り込み、再作業をなくす – クロスファンクショナルなチームを作る – タイムボックス(イテレーション)を使って、優先順位を 決める
⽇々の流れの管理 • デイリースタンドアップ – 毎⽇、短時間で • デイリースタンドアップで、カンバンを確認する – アップデートされているか –
作業の流れは順調か、溜まっていないか • 「次に何をすべきか?」にチームが答えられるようにす る
まとめ
カンバンの原則 • ⾒える化 • WIP の制限 • 流れの管理
今いるところから始められる • 現在どのような⼿法をとっていようが、カンバンを適⽤ して改善を進められる – プロセスの変化、役割の変更はない • 何が流れを滞らせているかが⾒え、改善できる • 「カンバンはメタプロセス」
– カンバンの原則をプロセスに適⽤して、プロセスを 改善する
カンバンを始める時の最⼤の間違い • WIP の制限なしで始めてしまうこと – 改善を進めるための制約がなくなってしまう • 今のチームでは、「未着⼿」に制限がないので、どんど ん溜まってしまう –
「未着⼿」と「開発」の間に、なにか列が存在する のかもしれない
本の中で話していないこと • 計画づくりと⾒積り • プロセスの改善 – ふりかえり • プロセスのメトリクス –
メトリクスの⾒える化
おまけ
案件カンバン • 案件の⾒える化 – ラジエーターに • ワークフローの定義 • 暗黙的な WIP
制限 – アバター制限を かける予定 • 週次MTGで更新 案件名 内容 窓⼝ 完了 今後3ヶ⽉ ワ ー ク フ ロ ー
ありがとうございました 参考 • Kanban Casual Talks(2016/05/19) – http://togetter.com/li/977418 想定質問 •
リモートでどうやるの • デジタルツールならどれがいいか • トヨタのかんばん⽅式との関係は