カンバンが機能する理由と、チームに向いているかを見極める方法

多くのチームは、誰かがブログ記事を読んだことをきっかけにカンバンを導入します。本当に考えるべきは、カンバンが解決する課題が自分たちのチームの課題と一致しているかどうかです。

チームが8、9人を超えたあたりで、多くの人が経験する場面があります。仕事は進んでいます。メールは送られ、機能はリリースされ、顧客対応も行われている。それでも、他のメンバーが何をしているのか、誰にもはっきり分からない。プロジェクトは積み上がり、約束されたことが静かに忘れ去られていきます。会議のたびに、ある仕事が今どこにあるのかを確かめるだけで20分かかる。返ってくる答えはたいてい「どこかにあるはず」です。

カンバンは、まさにこの問題を解決するために生まれました。戦略を立てる、適切な人材を採用する、組織文化をつくるといった課題ではなく、チームが何に取り組んでいて、何が進行を妨げているのかを把握するという、地味で骨の折れる実務上の課題です。

これだけ注目を集めたにしては、驚くほど控えめな道具です。カンバンは組織を立て直すとは主張しません。ただ、仕事を見えるようにするだけです。そして、この「見える化」を継続して行うと、その先の多くの物事が変わることがわかっています。

カンバンの本当の由来

「カンバン」は日本語で、看板を意味します。この仕組みは1940年代後半にトヨタが、製造工場の在庫を管理する手段として開発しました。考え方はシンプルです。決まったスケジュールで部品をつくるのではなく、後工程が必要だと知らせたときにだけ生産する。カンバンという物理的なカードが、依頼として生産ラインをさかのぼって流れていきます。見込みで何かをつくることはなく、不要なものが積み上がることもありません。

トヨタが得た洞察は、のちにソフトウェアチームにも取り入れられました。システムの非効率の大半は、人の作業が遅いことではなく、間違った仕事を間違ったタイミングで行っていることから生じる、というものです。一度に手を付けすぎる。手遅れになるまで誰も気づかないボトルネック。ある場所では完了した仕事が置かれたままなのに、次の工程は別の場所で手一杯になっている。

ソフトウェア開発者たち、特に2000年代初頭のMicrosoftのような企業では、こうした考え方をナレッジワークに応用し始めました。カードはタスクになり、工場の工程はワークフローの段階になりました。そして看板はボードになります。最初は物理的なもの、のちにデジタルなものとなり、チームの誰もが、何が進行中で、何が待機中で、何が完了したのかをひと目で確認できるようになりました。

カンバンボードが実際に見せてくれるもの

基本的なカンバンボードには、「To Do」「In Progress」「Done」の3つの列があります。多くの小規模チームにはこれで十分で、出発点としても申し分ありません。ただし、本当の価値が現れるのは、こうした段階を、理想の流れではなく、実際の仕事の流れに合わせてカスタマイズし始めたときです。

コンテンツチームなら、アイデア、ブリーフ、執筆中、レビュー中、公開予約、公開済み、といった段階になるかもしれません。ソフトウェアチームは「In Progress」を、開発、コードレビュー、QAの列に分けるでしょう。コンサルティングチームなら、ディスカバリー、提案、進行中、クライアント待ち、完了、といった具合です。各段階は、実際の引き継ぎと待ち時間、つまり仕事の担当が変わる場所や、何かが起きるまで止まっている場所を反映するべきです。

中央の列にあるカードに注目してください。倉庫監査レポートは、着手から8日が経過し、ブロック中と表示されています。ボードのない環境では、このタスクはさらに2週間、誰にも気づかれずに止まったままかもしれません。誰かが外部の第三者を待っている。あるいは、自分がボトルネックだと気づいていないマネージャーの判断待ちになっている。ボードは、この停滞を見えるようにします。それが仕事の大半です。

機能させるためのルール:WIP制限

カンバンを正しく使いこなすチームと、見た目がきれいなToDoリストを持っているだけのチームを分ける概念があるとすれば、それは仕掛かり作業の制限、略してWIP制限です。各列に同時に置けるアイテムの上限数を決めるという考え方で、列がいっぱいになったら、何かが次へ進むまで新しい仕事を追加できません。

これは直感に反するように感じられます。進行中のタスクを増やせるほうが、より多くの仕事が片づくのではないか、と。実際はそうなりません。多くのことを同時に進めると、すべてに時間がかかるようになります。コンテキストスイッチにはコストがかかり、中途半端な仕事は調整のオーバーヘッドを生みます。そして10件が「進行中」になっていると、どれが本当に進んでいて、どれが印も付かないまま止まっているのか、見分けるのがとても難しくなります。

「進行中」列のWIP制限を3にすると、4つ目の仕事が誰かの手元に届いたとき、チームの誰かが判断を迫られます。既存のどのタスクを先に完了させるのか。これは優先順位付けを促し、会話を促します。そして、新しい仕事に着手するペースが落ちたとしても、個々のアイテムはより早く完了する傾向があります。

カンバンとスクラム:チームが必ず尋ねる疑問

ソフトウェアチームや現代的なオペレーションの考え方に少しでも触れたことがあれば、スクラムを目にしたことがあるでしょう。仕事を固定の2週間スプリントに区切り、計画セッション、振り返り、スクラムマスターやプロダクトオーナーといった定められた役割を置くフレームワークです。多くのチームは、スクラムとカンバンを対立する方法論と捉え、どちらかを選ばなければならないと感じています。実際には、違いはもっとシンプルです。

多くのチーム、特に純粋なソフトウェアエンジニアリングではないチームは、スクラムの儀式が重く、固定スプリントの構造を継続的な運用業務に当てはめにくいと感じています。マーケティングチーム、カスタマーサクセスチーム、オペレーションチーム、そしてすべてを同時にこなす創業者の仕事は、2週間のサイクルにきれいに収まることはほとんどありません。カンバンの継続的なフローのモデルのほうが、たいていは適しています。

とはいえ、両方を組み合わせるチームも多くあります。プロダクト開発にはスプリント形式の計画サイクルを使い、どのスプリント中であっても流れ込んでくる運用やサポートの仕事にはカンバンボードを使う。これはまったく妥当なハイブリッドです。

ボードが30秒で答えられるべき3つの質問

カンバンボードが最も役に立つのは、誰にも話しかけなくても、次の3つの質問にすぐ答えられるときです。チームは今何に取り組んでいるのか。仕事はどこで詰まっているのか。やるべきなのに、まだ着手されていないことはないか。

ボードを見て30秒以内に3つとも答えられないなら、おそらく適切に運用されていません。最もよくある失敗は、タスクが作られるだけで一度も動かされないボードです。実際の仕事を映す生きた地図ではなく、良い意図の墓場になってしまいます。最新でないボードは、ボードがないよりも悪い状態です。見えているという誤った安心感を生むからです。

ボードを保つには、本物の規律が必要です。仕事が動いたらタスクも動かす。止まったアイテムは、2週間後ではなく止まった瞬間にフラグを立てる。カードには明確な担当者がいて、担当者は自分のカードを更新する。どれも多くの時間は必要ありません。うまく運用されているカンバンなら、1人あたり1日5〜10分程度でしょう。ただし、継続性が求められます。カンバンから最も恩恵を受けるチームは、ボードを補足的な記録作業ではなく、信頼できる唯一の情報源として扱っています。

カンバンにできないこと

カンバンは戦略のためのツールではありません。何に取り組むべきかを見つける手助けにはならず、すでに取り組むと決めたことを管理するのを助けるだけです。もし組織に、優先順位付けの問題、権限の曖昧さの問題、あるいはプロセスではなくリーダーの行動に根差した「古いプロジェクトを終える前に、新しいプロジェクトを始めすぎる」という問題があるなら、カンバンボードはそれらの問題を浮き彫りにしますが、解決はしません。

優れたマネジメントの代わりにもなりません。ボードは、1on1や、考え抜かれた権限委譲、特定の仕事がなぜ重要かについての明確なコミュニケーションを置き換えるものではありません。プロセスのツールを導入すれば、本来マネージャーの仕事である人間関係や組織面の仕事までプロセスがやってくれる、と期待してしまうチームもあります。それは起こりません。

カンバンができるのは、多くのチームの足を引っ張っている漠然とした不確かさを減らすことです。「誰が何をしているのか」「これは終わったのか」「次に何を手に取ればいいのか」という問いは、共有された見えるシステムがない組織では、価値の低いコミュニケーションを大量に生み出します。カンバンは、そうしたノイズの大半を取り除きます。そしてそのノイズが主な問題になっているチームにとって、その差は大きなものです。

3日間のワークショップなしで始める方法

私が見てきた中で最も優れたカンバン導入は、小さく始めて進化させたものでした。最悪だったのは、コンサルタントを呼び、2日間の合宿を行い、美しく設計されたボードが3週目には誰にも使われなくなっていたケースです。

実際のチームの姿と、実際に抱えている仕事から始めましょう。バックログ、進行中、完了の3つの列を作ります。チームと30分かけて、現在のすべての仕事をカードに書き出します。ルールはひとつだけ合意します。何かに着手するときは、それをボードに載せる。それが動いたら、カードを動かす。そのほかには、2週間は何もしません。

2週間後、チームでボードを見直します。どこに仕事が溜まったか。全員が優先事項だと言っていたのに、バックログに残ったままのものは何か。予想より早く進んだものは何か。何が、なぜ止まったのか。観察したことをもとに列を見直し、具体性を加えましょう。「進行中」を「進行中」と「外部待ち」に分けたほうがいいかもしれません。そのステップがたびたび見落とされるなら、「レビュー中」という列が必要かもしれません。ボードは、方法論の本が示す理想の姿ではなく、実際の仕事が示すものに応じて進化させてください。

より先を見据えて:フロー指標

カンバンの運用が軌道に乗ると、ほとんどのチームが活用していないデータが生まれます。中でも最も重要なのがリードタイム、つまりタスクが作成されてから完了するまでの総時間です。典型的なタスクの平均リードタイムが12日で、それを5日にしたいなら、目標とする数字があり、余分な7日がどこで消えているかを示してくれるボードがあることになります。

サイクルタイムは、タスクがバックログに置かれている時間を除き、実際に作業している期間だけを測ります。スループットは、チームが1週間に完了するアイテムの数を測ります。カードが作成された日と閉じられた日を記録する規律さえあれば、どの指標にも特別なソフトウェアは要りません。そしてこれらを合わせると、見積もりに基づく計画プロセスよりもはるかに正直に、チームの処理能力が見えてきます。

小規模から中規模のチームの多くは、ここまで到達しません。カンバンを見える化のツールとして使い、それだけで十分に価値があるので、そこから先へは進みません。それで構いません。しかし、ステークホルダーに対していつ完了するかを約束したくなったり、なぜ一部の仕事が予想の3倍もかかるのかを理解したくなったりしたときには、必要な指標はそこにあります。