カンバン

アジャイルと DevOps の手法の基礎であるカンバン フローでは、視覚化されたワークフローによってシームレスなタスク進行を調整して効率を高めます。カンバン フローは、スーパーマーケットの合理化された在庫管理を反映しています。これにより、タスクを必要に応じて正確に開発プロセスに沿って進めることができます。

タスクはカンバン ボードで視覚化され、カードとして表示されるため、進捗を透過的に追跡し、ボトルネックを迅速に特定できます。WIP (進行中の作業) を制限することで、チームはリソースの割り当てを最適化し、安定したワークフローを維持できます。カンバンでは継続的な改善に重点を置いており、管理図や累積フロー図などのメトリックによって促進され、チームはワークフローを繰り返し改良できます。

ソフトウェア開発では、カンバン フローにより動的なタスク管理を促進し、デリバリー サイクルを加速し、集中的な連続した作業を通じて顧客満足度を高めます。要するに、カンバン フローは効率性を典型的に示します。透明性、適応性、継続的な改善を調和して融合し、アジャイル手法の可能性を最大限に引き出します。

カンバンを効果的に実装するには、ソフトウェア開発チーム内で構造化されたカンバン フローを確立することが不可欠です。これにより、タスクがスムーズに進行し、ワークフロー管理が最適化されます。カンバン フローを構築する方法をご紹介します。

ワークフローを視覚化する: まず、カンバン ボードでチームのワークフローを視覚化します。ボードでは、物理的でも仮想的でも、タスクの開始から完了に至るまで、開発プロセスの各段階が表示されます。

ワークフローを標準化する: チームのプロセスと要件に応じて、ワークフローの段階を定義・標準化します。一般的な段階には「To Do」、「進行中」、「完了」などがありますが、独自のワークフローを反映するよう、必要に応じてカスタマイズできます。

ブロッカーと依存関係を特定する: カンバン ボードでブロッカーと依存関係を即座に特定できるようにします。この透明性により、迅速な解決が可能になり、ワークフローの中断を防げます。

WIP (進行中の作業) の制限を設定する: ワークフローの各段階に WIP 制限を導入して負担が過剰にならないようにし、安定したワークフローを維持します。WIP 制限により、リソースの割り当てを最適化し、マルチタスクを減らし、生産性の向上を促進します。

コラボレーションを推進する: チーム内でコラボレーションの文化を醸成し、メンバーが一丸となってボトルネックに対処し、協力してワークフローを円滑に進めるようにします。この協調的なアプローチにより、効率を高め、タスク完了を加速します。

カンバン カードを利用する: タスクの説明、担当者、完了予定時間などの重要な詳細が記載されたカンバン カードとして各タスクをボード上に表示します。カンバン カードにより、タスクの進捗を視覚的に追跡しやすくなり、チーム内の透明性が向上します。

このようにカンバン フローを構築することで、ソフトウェア開発プロセスを合理化し、チームのコラボレーションを強化し、タスク管理の効率を最大化できます。

カンバンは現在のアジャイルおよび DevOps ソフトウェア チームにおいてよく利用されるようになりましたが、カンバン方式には 50 年を超える歴史があります。1940 年代後半、スーパーマーケットにおける商品陳列方法と同じ原則に基づき、トヨタ社ではエンジニアリング プロセスの最適化を開始しました。

スーパーマーケットは消費者の需要を満たすのに必要なだけの在庫を仕入れます。これがスーパーマーケットと消費者の間の商品の流れを最適化する方法です。在庫レベルが消費パターンと一致しているため、スーパーマーケットは常に持っておかなければいけない余剰在庫を減らし、在庫管理を大幅に効率化できます。同時に、必要な商品の在庫は常に保持できます。

トヨタ社が同様のシステムを工場で採用した際の目標は、膨大な在庫レベルと実際の部品の消費を一致させることでした。キャパシティ レベルをリアルタイムで工場内 (およびサプライヤー) に伝えるため、従業員はチーム間で「カンバン」と呼ばれるカードをやり取りしました。

生産ラインで使用される部品が一箱分なくなると、必要な部品、必要量などが書かれたカンバン カードが倉庫に渡されます。倉庫にはこの部品が入った新しい箱がすでに用意されていて、これを工場に送り、倉庫からもカンバンをサプライヤーに渡します。このプロセスは 1940 年代から進化してきましたが、これと同じ JIT (「ジャスト イン タイム」) 製造プロセスは今でもカンバン方式の中核となっています。

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

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

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

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

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

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

カンバン カードにはプロジェクト タスクに関する重要な情報が記載されているため、チームは各タスクの責任者、作業の簡単な説明、およびタスクの推定所要時間を把握できます。バーチャルのカンバン ボード上のカードには、担当者にとって価値のあるスクリーンショットやその他の技術的詳細が表示されていることがよくあります。

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

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

柔軟なプランニング

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

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

サイクル期間の短縮

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

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

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

ボトルネックの減少

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

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

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

メトリックの可視化

カンバンの基本理念の 1 つは、作業のすべてのイテレーションにおいて、チーム効率と効果の継続的な改善にフォーカスを当てることです。図があれば、チームは改善し続けていることを視覚的に確認できます。

チームがデータを確認できれば、プロセスにおけるボトルネックの特定 (および排除) がより簡単になります。カンバン チームがよく使用するレポートは管理図と累積フロー図の 2 つです。管理図は各課題のサイクル期間や、チームの移動平均を表示します。

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

継続的なデリバリー

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

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

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

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

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