ToC(制約理論)から理解する「カンバン」の真価

はじめに

• ToC(制約理論)を説明します。（といってもリクルートさんの資料がめちゃくちゃ丁寧なのでそれベースです。）
• カンバン自体はToCを生かしたやり方なんですが、ToCそのままは少し使いづらいので、ちょっとファジーで現実的な使い方の提案です。

カンバンのよくある誤解

よく以下のようなメリデメ整理がされてるんですが、このレベルの理解だとちょっともったいない気がしています。

メリット

• 情報を統一化して管理しやすくなる
• チームのコミュニケーションを取りやすくなる

デメリット

• 詳細が把握しづらい
• タスクの重要度が判別しづらい

個人的にカンバンで一番重要なのは「ボトルネックの見える化」だと考えています。
その強みを生かす使い方を説明する前に、そもそもカンバンの前提理論である「ToC（制約理論）」を説明していきます。

ToC(制約理論)とは

まずはこれをみて

以下のリクルートさんの資料がめちゃくちゃわかりやすいので、これ見てください。

個人的な抜粋

個人的に特に重要だと思ったところを抜粋して紹介。

ボトルネックの特定

• この図だと「工程C」がボトルネックになっています。
• この「工程C」を改善しない限りは、他の工程の処理量が上がったとしても、結果としてのスループット（出荷量）は変わりません。
  • 例えばA/Bを改善したとしても、Cが処理できないので、詰まるだけです。
  • さりとてDを改善したとしても、インプットとなるCの処理量が増えない限りは、暇な時間が増えるだけでしかありません。
• このボトルネックにフォーカスして改善していくべきというのが「ToC（制約理論）」の考え方です。

ボトルネック自体の改善

• 最初のアプローチは、ボトルネック自体の改善を図ります。（現状の制約範囲内で対応できる改善）
• この例では稼働率を80%→100%に上げました。
• 結果として、出荷量が増えます。

ボトルネック側に合わせる（制約に従属させる）

• 工程A/Bで無駄な在庫をどれだけ作ったところで出荷量に影響しないのであれば、稼働率を下げましょう。合わせて資材の投入量も下げて良いはずです。
• 着手前の作業が大量にある状況は、工程Cの作業品質を悪化させます。（もっと作業を早くしないといけないという焦りから、必要な手順を飛ばしたりするなど）
• また、期間の開いたものを作業開始しようとすると、これってなんだっけ？みたいな確認作業も産まれたりするので、非常に効率が悪いです。

制約自体を見直す

• ここまで来たらそもそも制約自体を見直せないか考えましょう。
• よくあるのは、現行の承認プロセスだと厳しいとかですかね。一番難しいところ。
• 概ね、チームがコントロールできない部分がこの制約にあたる部分だと思います。関係各所を巻き込んで改善にアプローチしましょう。
• これが改善できたら次のボトルネック探しにいきます。

改善サイクル

• こうやってプロセスを改善していく考え方がToC（制約理論）。

カンバンとToC

カンバンで重要な要素はよく以下の３つ言われます。

• 見える化：プロセスの整備・タスク状態の把握
• WIP制限：ボトルネックへの従属を強制させる仕組み
• 流れの管理・改善：ボトルネックの特定・改善

唯一WIP制限だけわかりづらいのでちょっと補足します。
WIPは「Work In Progress（仕掛かり中）」の略称です。

ボトルネックに従属させることを強制させるために、各工程において同時に実行して良いタスク数を制限します。
WIP制約は工程ごとに異なる数字になります。
どの数字が妥当かは数式で算出する方法もあるんですが、正直直感で決めて微調整していけばいいと思っています。

カンバンへの適用

理論そのままカンバンに適用するとどうなるか

こんな感じで工程ごとに分けるようなイメージ。
実際のプロセスにはめて考えればいいと思います。
ただ実際のシステム開発現場で考えると微妙に使い勝手が悪い。

開発以外にもちょっとした作業などもカンバンで管理した時に、特定の作業種別しか扱えないカンバンって管理しにくい。
なので、現実はもっとシンプルに「作業前」「作業中」「完了」くらいのものが多い。

ただこのやり方にするとプロセスは整備され、ボトルネックとなっているポイントも明確になります。
汎用的ではないですが、ポイントを明確にして使えば非常に効果の大きい使い方だと思います。

スクラムバン（スクラム + カンバン）

どうも初期に公表されたサイトはもう閉じられてしまったようなので、AgileAllianceの解説ページを載せておきます。

ざっくりこんな感じのレーンに分かれることになります。

• Backlog：バックログ
• Ready：バックログの中でも次に着手するもの（優先度の高いもの）
• Specify：完了条件(PBIの完了条件というよりはタスクの完了条件)を定義中のもの
• Complete：完了条件が明確になり着手可能となったもの
• Execute：作業中（開発作業などを指す）
• Done：完了したもの

これの良いところは汎用的に扱えるので、作業であっても開発であっても取り扱えます。
また、未着手・作業中・完了といったシンプルなステータス管理と比べて「完了条件の明確化」といったところにフォーカスされているため、チーム内での認識合わせでもっとも会話すべきゴールのすり合わせを明確に行うことができます。

もっと雑に扱う

もっと雑に扱うならよく見かける「未着手/作業中/完了」の３レーンに分けるのでもありだと思います。

WIP制約について
ここまでシンプルだと、WIP制約の意味が少しわかりにくくなりますが、設定しておく方が良いとは思います。
設定しておくことで、待ち状態で放置してるタスクが増えてくると、チーム外を巻き込んで改善しなければならないという方向性に話が及ぶはずです。
（まぁそう上手くいくことはないですが、気づくきっかけにはなると思いますので、それを契機に改善に動くのが良いかと思います。）

タスクの滞留と粒度
WIP制約をしないにしても、ステータスが長い間変わっていないタスクは、課題を抱えているタスクだと判別できます。
ただ、そのためにはタスクの粒度がある程度小さい必要があります。
どれもこれも大きな粒度で、どれもこれも滞留している状態だと、どれが課題を抱えているのか判別できません。
課題を見える化するためにも、タスクの分割は重要になってきます。
（作業者側からするとタスク分割って面倒なだけに感じるケースはあるので、上手い粒度を探る必要がある認識）

まとめ

カンバンの背景にある制約理論を理解すると、もっと現場の改善ポイントを見つけることができます。
上手く使っていきましょう。

次回予告

昨日の記事で話題に上げた「スプリント期間の考え方」を整理します。