カンバン（開発）

カンバン（日本語：看板）は、人間のシステム全体の作業を管理および改善するための無駄のない方法です。このアプローチは、需要と利用可能な容量のバランスを取り、システムレベルのボトルネックの処理を改善することで作業を管理することを目的としています。

作業項目は、通常はカンバンボードを介して、最初から最後までの進捗状況とプロセスを参加者に視覚化します。作業は、要求されたときにプロセスにプッシュされるのではなく、容量が許す限り プルされます。

知識労働とソフトウェア開発において、その目的は、何を、いつ、どれだけ生産するかについての意思決定を支援する視覚的なプロセス管理システムを提供することです。基礎となるカンバン方式は、トヨタ生産方式に触発されたリーン生産方式^[1]に由来しています。^[2]その起源は、1940年代後半にトヨタ自動車がジャストインタイムと呼ばれる生産システムを実装したときにさかのぼります。これは、顧客の需要に応じて生産し、生産ライン内での材料不足の可能性を特定することを目的としていました。しかし、トヨタが考案したこの方法が、あらゆる種類の組織プロセスに適用できるプロセスになる可能性があると気付いたのは、コービスのチームでした。カンバンは、スクラムなどの方法やフレームワークと組み合わせて、ソフトウェア開発でよく使用されます。 [ ^3]

この図はカンバンボード上のソフトウェア開発ワークフローを示しています。^[4]

カンバン ボードは、使用されるコンテキストに合わせて設計されており、大きく異なります。作業項目の種類 (ここでは「機能」と「ユーザー ストーリー」)、ワークフロー アクティビティを示す列、明示的なポリシー、スイムレーン (複数の列にまたがる行。ここでは機能ごとにユーザー ストーリーをグループ化するために使用されます) が表示される場合があります。目的は、一般的なワークフローと個々の項目の進行状況を参加者と関係者に明確にすることです。

カンバンボードはシステムのワークフローの定義^[5]を表し、以下の最低限の要素を必要とします。

• ワークフローを通じて移動する個々の価値単位の定義。これらの価値単位は、作業項目 (または項目) と呼ばれます。
• ワークフロー内で作業項目がいつ開始および終了するかの定義。作業項目によっては、ワークフローに複数の開始ポイントまたは終了ポイントがある場合があります。
• 作業項目が開始から終了まで流れる 1 つ以上の定義済み状態。開始ポイントと終了ポイントの間にある作業項目は、進行中の作業(WIP) とみなされます。
• WIP が開始から終了までどのように制御されるかの定義。
• 作業項目が開始から完了まで各状態をどのように通過するかについての明示的なポリシー。
• サービス レベル期待値( SLE)。作業項目が開始から終了までにかかる時間を予測します。

^{カンバンガイド[6]}に記載されているカンバンの実践は、

• ワークフローの定義と視覚化
• ワークフロー内のアイテムを積極的に管理する
• ワークフローの改善

カンバンは、効率的、効果的、予測可能なシステムを作成するためにこれらに従うことを目的とした戦略です。

カンバン方式は、カンバンを専門的に詳細に推し進めたものです。ソフトウェア開発におけるカンバン方式に関する書籍^{[7] [3]で説明されているように、カンバン方式の2つの主なプラクティスは、作業を視覚化することと、進行中の作業(WIP)を制限することです。Essential} Kanban Condensedに記載されているカンバン方式の4つの一般的なプラクティスは、ポリシーを明示すること、フローを管理すること、フィードバックループを実装すること、協力して改善することです。^[8]

上の図のカンバンボードは、カンバン方式の最初の 3 つの一般的なプラクティスを強調しています。

• 開発チームの作業（機能とユーザーストーリー）を視覚化します。
• 開発ステップの WIP 制限を取得します。列見出しの下の丸で囲まれた値は、そのステップでの作業項目の数を制限します。
• いくつかの開発ステップの下にある青い四角の中に、完了ルール^[9]とも呼ばれるポリシーが文書化されています。
• また、「ユーザー ストーリーの準備」、「ユーザー ストーリーの開発」、および「機能の承認」の各ステップのカンバン フロー管理も示しており、これらのステップには「進行中」および「準備完了」のサブ列があります。各ステップの WIP 制限は両方のサブ列に適用され、作業項目がこれらのステップへのフローまたはステップからのフローを圧倒するのを防ぎます。

カンバンはカンバンボード上で直接ワークフローを管理します。開発ステップのWIP制限により、開発チームは一般的なワークフローの問題に関する即時のフィードバックを得ることができます。^{[7] [9]}

たとえば、上記のカンバン ボードでは、「展開」ステップの WIP 制限は 5 で、現在そのステップには 5 つのエピック^{[説明が必要]}が表示されています。1 つ以上のエピックがそのステップを完了する (「配信済み」に移動する) まで、それ以上の作業項目を展開に移動することはできません。これにより、「展開」ステップが過負荷になるのを防止できます。「機能の承認」(前のステップ) に取り組んでいるチーム メンバーは、新しいエピックを展開できないために行き詰まる可能性があります。ボード上ですぐに理由を確認し、現在のエピックの展開を支援できます。

「展開」ステップの 5 つのエピックが配信されると、「機能の受け入れ」 (前のステップ) の「準備完了」サブ列の 2 つのエピックを「展開」列に移動できます。これら 2 つのエピックが配信されると、他のエピックを展開できなくなります (新しいエピックが準備完了していないと仮定)。これで、展開に取り組んでいるチーム メンバーは行き詰まってしまいます。彼らはすぐに理由を理解し、機能の受け入れを支援できます。

カンバン ボードの設定では、スイムレーンを使用して作業をプロセスのさまざまな段階に視覚的に整理し、明確さと焦点を確保します。効率的なワークフロー管理のためには、要件、開発、テスト、クローズ/完了したタスクなどの主要な段階ごとに個別のスイムレーンを維持することが重要です。具体的には、テスト ストーリーは常に指定された「テスト」スイムレーン内に配置する必要があります。この分離により、テスト アクティビティを簡単に追跡でき、開発中の他のストーリーや他の段階と混ざり合うことがなくなります。テスト タスクを独自のスイムレーン内に保持することで、チームはボトルネックをすばやく特定し、問題の優先順位を付け、開発段階や要件段階からの相互汚染なしにテスト プロセスの整合性を維持できます。この構造により、ワークフローが明確になり、チームのコラボレーションが強化されます。

このワークフロー制御は、すべてのステップで同様に機能します。問題はすぐに視覚的に明らかになり、再計画を継続的に行うことができます。進行中の作業を制限して、チーム メンバーが常に確認および追跡できるようにすることで、作業管理が可能になります。

デビッド・アンダーソンの2010年の著書「カンバン」 ^[7]では、2004年のマイクロソフトのプロジェクト^[10]で制約理論アプローチが使用され、ドラム・バッファ・ロープ（カンバンプルシステムに類似）が組み込まれたアプローチから、2006～2007年のコービスのプロジェクトでカンバン方式が^{[誰によって？ ]}特定されるまでのアプローチの進化について説明しています。2009年にドン・ライナーツェンは第二世代のリーンな製品開発に関する本を出版しました^[11]。この本では、カンバンシステムの採用と、データ収集と経済モデルを経営上の意思決定に使用することについて説明しています。もう1つの初期の貢献はコーリー・ラダスによるもので、2008年の著書「スクラムバン」^{[3]では、カンバンがソフトウェア開発における}スクラムを改善できると示唆しています。ラダスはスクラムバンをスクラムからカンバンへの移行と見なしていました。ジム・ベンソンとトニアン・デマリア・バリーは、2011年に個人や小規模チームにカンバンを適用した『パーソナル・カンバン』^{[12]を出版した。マイク・バロウズは}『カンバン・フロム・ザ・インサイド』（2014年）^[13 ]で、カンバンの原則、実践、根底にある価値観を説明し、それらを以前の理論やモデルに関連付けた。エリック・ブレヒナーは『アジャイル・プロジェクト管理とカンバン』（2015年）^{[9]で、マイクロソフトと}Xboxでのカンバンの実践の概要を示している。クラウス・レオポルドとジークフリート・カルテネッカーによる『カンバン・チェンジ・リーダーシップ』 （2015年） ^[14]は、変更管理の観点からこの手法を説明し、変更イニシアチブへのガイダンスを提供した。2016年にリーン・カンバン大学出版局は、初期のカンバンプロジェクトからの改善と拡張を組み込んだこの手法の要約ガイドを出版した。^[8]

2020年にジョン・コールマンとダニエル・ヴァカンティは、カンバンシステムを運用するために必要な最小限の条件を説明する「カンバンガイド」^{[6]を出版しました。コリーン・ジョンソン、ダニエル・ヴァカンティ、プラティーク・シンは2022年に「カンバンポケットガイド」 [15]}を出版し、実践者がカンバンの実践をナビゲートできるようにしています。ウィル・ゼーレとダニエル・ヴァカンティも2022年に「スクラムチームのためのフローメトリクス」^[16]の本を出版し、カンバンで一般的に使用されるメトリクスの利点をスクラムチームに提供しています。

• ソフトウェア開発哲学のリスト

• カンバン：テクノロジービジネスを成功に導く進化的変化、デビッド・J・アンダーソン（米国、ブルーホール・プレス、2010年。ISBN 978-0984521401 ） 
• Scrumban: リーン ソフトウェア開発のためのカンバン システムに関するエッセイ、Corey Ladas。(米国、Modus Cooperandi Press、2009 年。ISBN 9780578002149 ) 
• アジャイルプロジェクト管理とカンバン (開発者のベストプラクティス)、Eric Brechner。(米国: Microsoft Press、2015 年) 。ISBN 978-0735698956。 
• Kanban in Action、Marcus Hammarberg と Joakim Sunden （ニューヨーク州シェルターアイランド：マニング出版、2014）。ISBN 978-1-617291-05-0。 
• Lean from the Trenches: Kanban による大規模プロジェクトの管理、 Henrik Kniberg。(ダラス、テキサス州: The Pragmatic Programmers、2012 年) 。ISBN 978-1-93435-685-2。 
• 始めるのをやめて、終わらせ始めましょう! Arne Roock と Claudia Leschik。(米国: Lean-Kanban University、2012 年) 。ISBN 978-0985305161。 
• 『Real-World Kanban: Do Less, Accomplish More with Lean Thinking』、Mattias Skarin。(米国: Pragmatic Bookshelf、2015年) 。ISBN 978-1680500776。