カンバン

現代のアジャイル・ソフトウェア開発チームも、WIP（進行中）の作業量とチームのキャパシティを一致させることで、JIT の原則を活用できます。これによりチームは開発サイクル全体を通して、より柔軟なプランニングのオプション、迅速なアウトプット、継続的な改善への焦点の明確化、透明性を実現できます。

カンバン・フレームワークの基本原則はいつの時代も、ほとんどの業界で適用可能ですが、ソフトウェア開発チームはアジャイル・プラクティスにおいて特に成功を収めました。工場でカンバン方式を採用すると、物理的なプロセスを変更したり、使用する道具を追加したりする必要が生まれますが、ソフトウェア・チームの場合はこれとは異なり、ボードとタスク・カードさえあれば開始できたのです。また、この 2 つのツールがバーチャルであっても実現可能でした。

あらゆるカンバン・チームの仕事は、カンバン ボードを中心に展開します。カンバン ボードとは仕事を可視化し、複数のチーム全体でワークフローを最適化するためのツールです。物理的なボードが使いやすいというチームもありますが、アジャイル・ソフトウェア開発ツールにはバーチャル・ボードが必要不可欠です。トレーサビリティを確保し、コラボレーションし、複数の拠点からアクセスできるからです。

チームがデジタル・カンバン ボードを使用しているか物理的なカンバン ボードを使用しているかに関係なく、チームは作業を視覚化し、ワークフローを標準化し、すべてのブロッカーや依存関係を即座に特定して解決できます。基本的なカンバン ボードには、To Do、進行中、完了の 3 段階のワークフローがあります。ただし、チームの規模、構成、目的に応じて、独自のプロセスに合わせてワークフローをマッピングできます。

カンバン方式は、作業の完全な透明性と、リアルタイムのコミュニケーションに依存するため、カンバン ボードはチームの作業での信頼できる唯一の情報源として機能します。

日本語でカンバンは「看板」を意味します。カンバン・チームは、すべての作業項目をボード上の個別のカードとして表します。作業をカードとしてカンバン ボードに表示する主な目的は、チーム メンバーがワークフローを通して、進捗をより視覚的に追跡できるようにすることです。

カンバン・カードにはプロジェクトのタスクに関する重要な情報が記載されており、各タスクの責任者、その作業の簡単な説明、タスクにかかると予測される時間をチームが把握できるようにします。多くの場合、バーチャルのカンバン ボード上のカードには、スクリーンショットや、担当者にとって重要な他の技術的詳細が表示されます。

関連する詳細とともに各タスクのステータスを、チーム メンバーがいつでも確認できるようにすると、集中力が高まり、包括的なトレーサビリティが向上し、ブロッカーや依存関係を迅速に特定できるようになります。

カンバンは、今日アジャイル チームが使用しているソフトウェア開発手法の中でも、最高クラスの人気を誇ります。カンバンには、あらゆる規模のチームにとってタスクの計画と処理における複数のメリットがあります。

カンバン・チームは現在進行中の作業にのみ集中します。チームはタスクを完了すると、バックログから次のタスクを選択します。現在の作業項目以外の変更はチームに影響を与えないため、製品所有者はチームの作業を邪魔することなく、自由にバックログの優先順位を変更できます。

製品所有者が常にバックログの一番上に最も重要な作業項目を配置している限り、開発チームは事業に最大の価値をもたらすことができます。

サイクル期間は、カンバン・チームにとって重要な測定指標です。サイクル期間は、1 つの作業ユニットがチームのワークフローを完了するまで（作業の開始からリリースまで）にかかる時間です。サイクル期間を最適化することにより、チームは自信を持って、今後の作業の提供について予測できます。

スキル・セットの重複はサイクル期間の短縮につながります。スキル・セットを持っている人が一人しかいない場合、その人がワークフローのボトルネックになります。そこでチームは、コード レビューや指導的支援などのベスト・プラクティスを採用し、知識を広めています。スキルが共有されていれば、チーム メンバーは異種の作業を引き受けられ、サイクル期間をさらに最適化できます。

さらに、このアプローチにより、作業のあらゆるボトルネックにチーム全体が一丸となって対処できるようになり、迅速な解決を促進し、ワークフローが円滑になります。たとえば、テストの責任は QA エンジニアだけでなく開発者にも及ぶため、協力的な取り組みを促進して効率を維持します。カンバン・システムでは、チーム全体が作業をプロセスの中で円滑に進められるようにします。

マルチタスクは効率を損ないます。同時にワークロードが増えると、コンテキストの切り替えがより頻繁になり、タスクの完了に向けた進捗が妨げられます。カンバン・プロセスの重要な理念が、WIP（進行中の作業）の制限であるのはそのためです。進行中の作業を制限することにより、集中度や人員、スキルの不足が原因でチームのプロセスに生じるボトルネックが明確になります。

たとえば、典型的なソフトウェア・チームには 4 つのワークフローの状態があります。To Do、進行中、コード レビュー、完了です。コード レビューの状態では、WIP 制限を 2 に設定できます。制限が厳しいように感じるかもしれませんが、これには理由があります。

開発者は多くの場合、他者の作業のレビューをするよりも、新しいコードを記述することを好むものです。厳しい制限を設定していれば、チームはレビュー状態の課題に特別な注意を払い、自身のコード レビューを登録する前に他者の作業のレビューをするようになり、最終的に全体的なサイクル期間が短縮されます。

累積フロー図は、各段階にある課題の数を示します。チームは、特定の段階において課題の数が増加したら、簡単にブロッカーを特定できます。「進行中」や「レビュー中」といった中間の段階における課題は、まだ顧客に届いていません。こういった段階でのブロッカーは、作業が上流にマージされる際に、大規模な統合の競合を生む可能性が高くなります。

CD（継続的なデリバリー）は、ソフトウェアを顧客に頻繁にリリースするプロセスです。CI（継続的インテグレーション）は 1 日を通じて段階的にコードのビルドと検証を自動的に行う方法です。これらを組み合わせて、DevOps チームに不可欠な CI/CD パイプラインを形成し、高品質を保証しながらソフトウェアをより迅速にリリースします。

カンバンと CD はどちらも、ジャスト イン タイムで（また一度に 1 つずつ）価値を提供することに焦点を当てているため、お互いにうまく補完し合います。チームがイノベーションを市場に届けるスピードが速いほど、その製品の競争力が高まります。カンバン・チームはまさにそこに焦点を当てています。つまり、顧客に届ける作業の流れの最適化です。

カンバンとスクラムは同じ概念をいくつか共有していますが、そのアプローチは非常に異なっています。この 2 つを混同してはいけません。

カンバン方式とスクラムの理念を「スクラムバン」に融合しているチームもあります。その場合は、スクラムから固定長スプリントとロールを、カンバンから進行中の作業制限とサイクル期間を取り込んでいます。

アジャイルを開始したばかりのチームでは、1 つの手法を選択して、しばらくの間それを実行することを強くおすすめします。チームがカンバン方式を使い始める準備が整ったら、今すぐ無料のカンバン ボード・テンプレートを使用してみましょう。