トヨタのかんばんに学ぶバックログ管理術

トヨタのかんばんに学ぶバックログ管理術

マイクロソフトディベロップメント IPX Team

津田義史

[XP祭り 2013.09.14]

宣伝。

韓国語版が出ました!!

アジェンダ

• バックログの復習

• TPSのかんばん

• BTSのバグ報告票

• ソフトウェア開発における在庫とは

バックログの復習

• タイムボックス

•スコープボックス

•バックログ

タイムボックスとは

入口出口

全開発期間

出口は延長しない、入らない作業は無理して詰め込まない

• 納期（時間）を固定する

–作業の範囲は柔軟に保つ

– この箱に作業を詰める（タイムボクシング）

マイルストーン: 1～数ヵ月間の箱

イテレーション: 数日～数週間の箱

全開発期間

イテレー

マイルストーン

ション・


イテレー


全開発期間

タイムボックスの構成

スクラムでは、1ヶ月間のマイルストーンをスプリントという

スコープボックスとは

• 作業の範囲を固定する

–納期は柔軟に保つ...

– フィーチャーボックスともいう

デスマーチになりやすいアプローチです

作業

作業

作業

作業

作業

作業

作業

作業

作業

作業

これを全部やる、と決める

スコープ

バックログとは

• 残作業のこと

– タイムボックスの入口でバックログを作成

– これを、タイムボックスの出口までに全部やる

バーンダウンチャートはお使いですね！スプリントの出口（最終日）までに、全ての作業をDoneすることが必要です

作業

作業

作業

作業

作業

作業

作業

作業

作業

作業

これを全部やる、と決める

え、全部やるの？タイムボックスと

スコープボックスって何が違うの？

うまくいかないときの、計画の立て直し方が違う!!

• スコープボックス–スケジュールを伸ばす（作業の範囲は変えない）

–全部の作業が完了するまで、やめない

• タイムボックス–作業の範囲を減らす（スケジュールは変えない）

–箱から溢れそうな作業は、バックログから除いて次のタイムボックスへ先送り

作業をパント（延期）する

• 持っている作業から手を離して、それが地面に落ちる前に蹴り飛ばす

• 次のタイムボックスの中にいる誰かに、キャッチしてもらうことを期待

• キャッチできるかもしれないが、落とすことになるかもしれない...

• だが、今はとりあえず先送り！

できない作業を、いつまでも手に抱えていてはいけない

ボール

バックログのまとめ

• バックログは、タイムボックスの「計画」

• 作業を、計画通りに全部やる！

• だが、無理な計画は立て直す

–溢れそうな作業は、早めにパントする

–出口で「これできませんでした」はNG！

• で、立て直した計画通りに全部やる！

アジェンダ





TPSのかんばん

• トヨタ生産方式のかんばんとは

• かんばんの運用で守るべきルール

• 電子かんばんとは

Toyota Production System

トヨタのかんばんて

どんなの？

こんなの

http://pc.watch.impress.co.jp/docs/2005/1121/gyokai142.htmhttp://www.chunichi.co.jp/hold/2008/yui_no_kokoro/list/200805/CK2008051402011210.html

痛まないようにラミネートのケース入り。薄い鉄板やプラスチック板を使うことも

http://pc.watch.impress.co.jp/docs/2005/1121/gyokai142.htm

http://www.chunichi.co.jp/hold/2008/yui_no_kokoro/list/200805/CK2008051402011210.html

かんばんの運用

かんばんで、部品を引き当てる！この部品の消費部門（図右）で、別の種類の部品（製品）を組み立てたら

それにも別の種類のかんばんを貼ります

かんばんには、この部品をどこに届けるべきか書いてある

部品を使うときにかんばんを剥がす適当な頻度で、まとめて生産部門に返す

部品を作ったら、かんばんを貼る手元のかんばんがなくなるまで部品を作る

かんばんのルール

かんばんは必ず現物につけておく

かんばんと在庫部品を

1対1で対応づける

かんばんがなければ生産を

開始しない

かんばんが到着した順で生産する

流通しないかんばん（紛失）に注意！

かんばんの枚数を

減らしていく

不良品を消費部門に送り込んではいけない

生産の微調整に使う

かんばんのルール#1


かんばんが貼られていない部品があってはいけない部品を作ったら、すぐにかんばんを貼って

その部品が工場の中で迷子にならないようにする



1対1で対応づける部品の在庫数を、かんばんの枚数と同じにして

在庫数を追跡・見える化


かんばんがなければ

生産を開始しない生産部門がヒマなときでも、かんばんがなければ生産してはいけない

それ（作り置き）しちゃうのは部分最適。全体最適を目指す



部品Aのかんばん10枚到着、部品Bのかんばん10枚到着、部品Aのかんばん10枚到着こんなとき、部品Aを20個作ってから部品Bを10個生産する方が早く作れるとしても、

それは部分最適。（AとBを交互に1個ずつ作る運用もあります）



減らしていくかんばんの総枚数を減らせば、部品の在庫数を減らせる

（減らしすぎると、部品の引き当てが間に合わなくなるので、少しずつ程ほどに。）


流通しないかんばん

（紛失）に注意！かんばんを紛失すると、

「あれ？部品の引き当てが間に合わない。えーい、何枚かかんばん足しちゃえ！」なんて、何やってるんだか訳が分からなくなります



必要な数の部品しか作らないので、不良品を送ると消費部門（下流工程）の生産ラインを止めてしまう



完成品の需要（時期や季節）によって、かんばんの総枚数（＝在庫数）を増減させる

電子かんばんとは

• 各かんばんを追跡できるように、かんばんにバーコードやICタグを付けたもの

• 消費部門から生産部門にネットで送って印刷し部品に貼付するもの

など

かんばんと同じく、部品に貼付できるように物理的に存在する必要がある

（TPSのかんばんは、完全には電子化できない）

TPSのかんばんのまとめ

• 部品（製品）を作ったら、かんばんを貼る

• 部品を消費（出荷）するときに剥がす

• 剥がしたかんばんを繰り返し使って、次の生産を指示

–消費した分だけ、また作る！

• 重要なパラメータは、かんばんの総枚数

–かんばんの総枚数を増減させることで、在庫数を増減・調整する

アジェンダ





BTSのバグ報告票

• タスクかんばんとバグ報告票

• バグ追跡システムの運用と、守るべきルール

• TPSのかんばんとの違い

Bug Tracking System

タスクかんばん、どこに貼る？

壁に貼る間違いではないが、本質ではない

TPSのかんばんは、部品（在庫）に貼るものでしたね！

（参考）生産指示かんばん

トヨタのかんばんも、かごに入れるかわりに壁に吊るして管理できるこのほか、ラインの進捗を壁に表示する種類のかんばんもある

http://itpro.nikkeibp.co.jp/article/JIREI/20080924/315302/タスクかんばんを壁に貼るのも、決して間違いではない

状況に応じて、適切なツール（壁やITSなど）を選択しましょう

http://itpro.nikkeibp.co.jp/article/JIREI/20080924/315302/

タスクかんばん、どこに貼る？

タスクに貼る

ひとつのタスクにひとつのタスクかんばんを貼り、このタスク（の状態）を追跡・見える化

バグ報告票、どこに貼る？

バグに貼る

ひとつのバグにひとつのバグ報告票を貼り、このバグ（の状態）を追跡・見える化

バグ報告票の運用

バグ報告票で、人的リソース（担当者）を引き当てる！（「担当者で、次の作業を引き当てる」という解釈も可能…）

バグ報告票には、このバグを誰に届けるべきか書いてある

バグを見つけたら、バグ報告票を貼る

担当者を剥がして、次のバグ報告票を引かせる

バグ報告票のルール

発見したバグは必ず起票しておく

バグとバグ報告票を


バグ報告票がなければ作業を

開始しない

バグ報告票の優先度順で作業する

流通しないバグ報告票（放置）に注意！

（オープンな）バグ報告票の枚数を

減らしていく

ブロッキングバグを

テストチームに送り込んではいけない

人的リソースの負荷分散に使う

バグ報告票のルール#1


バグ報告票が貼られてないバグがあってはいけないバグを見つけたら、すぐにバグ報告票を貼って

そのバグがチームの中で迷子にならないようにする



1対1で対応づける一件一葉の原則を守り、潜在的なバグをすべて発見して

すべてのバグを追跡・見える化


バグ報告票がなければ作業を開始しないチームのTransparencyを高めてVisibilityを確保

（チームを透明にして、今誰が何をしているのかを見える化する）



開発者的には、こっちを先に直した方が早く作業を完了できる…としても、それは部分最適。

他人の作業との依存を考慮した優先度を、尊重して作業する必要


（オープンな）バグ報告票の

枚数を減らしていくバックログの運用と同様！出口までに全部直してゼロにする


流通しないバグ報告票

（放置）に注意！バグ報告票を放置するのは、かんばんを紛失するのと同じ

バグ報告票を滞りなくチーム内に流通させる！


ブロッキングバグをテストチームに送り込んではいけない

テストをブロックするバグは、テストチームの作業を止めてしまう



高負荷の人にアサインされたバグ報告票を低負荷の人に振り分け直して、負荷を平準化




かんばんがなければ生産を

開始しない


流通しないかんばん（紛失）に注意！


減らしていく






バグ報告票がなければ作業を

開始しない


流通しないバグ報告票（放置）に注意！

（オープンな）バグ報告票の枚数を

減らしていく

ブロッキングバグを

テストチームに送り込んではいけない


かんばんのルール

バグ報告票のルール

かんばんとバグ報告票の違い

TPSのかんばん

• 生産したら貼る

• 繰り返し使う

• 同じかんばんをたくさん使う– 作業内容・作業時間が同じ

• 最初から解決方法が明確– 何を作って、どこに届けるか

• 完全に電子化はできない

• 後工程引き取り（Pull型）

• 出口がない（プロジェクトでない）

• 複数の製品を継続して出荷

BTSのバグ報告票

• 発見したら貼る

• 繰り返しては使わない

• 同じバグ報告票はない– 作業内容・作業時間が異なる

• 最初は解決方法が不明– 直すべきか、誰がどのように直すか

• 完全に電子化することが可能

• 湧いて出てくる（Push型）

• 出口のたびに、枚数をゼロにする

• 最終的にひとつの製品を出荷

「テストケース実行」のように、各スプリントで繰り返し実施するタスクもあるが、都度起票する方が使いやすい

テストケースの実行時間（工数）は、テストケースに書いておくと便利。

BTSのバグ報告票のまとめ

• TPSのかんばんと良く似た性質をもつ

–各バグの状態に応じて、チーム内を流通させる

–人的リソースの稼働をコーディネート

• プロジェクトの健康診断に活用

–チームにフィードバックを供給する「血液」

–総枚数、増減のトレンド、滞り具合、などで診断

–重要な診断指標は、バグ報告票の総枚数

アジェンダ





ソフトウェア開発における在庫とは

ずばり、スプリントバックログが「在庫」です。

Backlogを辞書で引いてみよう

「バックログ」は、スクラムの専門用語ではない

Backlog →

Backlog →

Backlog →

（参考）バーンダウンチャートバックログを、スプリントの出口までに全て着地させる

The glide path is approaching!!

Backlog →

フライトパス: 実際の飛行経路グライドパス: 理想的な滑空経路

Backlogを「在庫」と扱う

とは、どういうことか

在庫とは

• 工場の在庫

–工場の中にあって、まだ出荷していない製品

–仕掛中の部品（WIP）を含む

• ソフトウェア開発の在庫

–バックログの中にあって、まだ完了していないタスク

–着手済みの作業（WIP）を含む

在庫を減らすには？

• 工場の在庫– 部品を完成

– 製品を出荷

• ソフトウェア開発の在庫– タスクを完了

– 機能を実装

– バグを修正

– テストを実施

– …

部品を完成して消費部門にお届け

||

タスクを完了してチームにお届け

最終的には、すべての部品（タスク）を統合して製品を組み立て（ビルド）し、ユーザーにお届け

不良在庫とは

• 工場の不良在庫

–出荷できる見込みがなく、抱え込んでいる製品や部品

• ソフトウェア開発の不良在庫

– （このスプリントの出口までに）完了（修正）できる見込みがなく、抱え込んでいる作業やバグ

不良在庫を減らすには？

• 工場の不良在庫

–かんばんの枚数を減らす

• ソフトウェア開発の不良在庫

–バグ報告票やタスクかんばんの枚数を減らす

おいおい、どんな魔法だよ

適切な在庫量（スプリントバックログの分量）

を維持する!!不良在庫は、早めにプロダクトバックログの中へパント

（次のスプリントへ先送り）

適正な在庫量とは

スプリントの出口までに確実にDoneできる分量

適正な在庫量の目安は、グライドパスが教えてくれる

まとめ

• ソフトウェア開発における「バックログ」は、工場における「在庫」と似た性質をもつ

• 在庫を計画的に完成して出荷する

• 在庫量を適正に制限する

–確実に出荷できる在庫だけを保有

–不良在庫は、早めに次のスプリントへパント（プロダクトバックログの中に蹴り入れる）

Backlog Done Deliver

実際、スプリントの成果物はdeliverable（出荷可能なもの）といいます

続きは...

[目次]

1. ソフトウェアを育てる準備

2. チームの役割と責務

3. タイムボックスとビルドの運用

4. 構成管理とブランチの戦略

5. 再現可能なビルドの実現

6. バグの追跡と解決

7. テストケースの自動化

8. 開発プロセスの構築

トヨタのかんばんに学ぶバックログ管理術

Technology