カンバン

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

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

あらゆるカンバンチームの仕事は、カンバンボードを中心に展開します。カンバンボードとは仕事を可視化し、チームメンバー間で仕事の流れを最適化するためのツールです。物理的なボードを好んで使っているチームもありますが、仮想ボードはどんなアジャイルソフトウェア開発ツールであっても必須の機能です。なぜなら仮想ボードであれば、トレーサビリティを確保し、コラボレーションを容易にし、複数の場所からのアクセスができるからです。

チームのボードが物理的なものでもデジタルでも、その機能は同じです。チームの作業を可視化し、ワークフローを標準化し、すべてのブロッカーと依存関係を即座に認識し、解決します。基本的なカンバンボードには、To Do、進行中、完了の 3 段階のワークフローがあります。しかし、チームのサイズ、構成、目的によって、ワークフローをそれぞれのチーム特有のプロセスに沿うように変更できます。

カンバン方式は、作業の完全な透明性と、キャパシティに関するリアルタイムのコミュニケーションに依存します。そのため、カンバン ボードをチームの作業に関する、信頼できる唯一の情報源としてください。

日本語でカンバンとは、「視覚信号」を意味します。カンバン チームにとって、作業項目はすべて、ボード上の異なるカードとして表示されます。

作業をカードとしてカンバン ボードに表示する主な目的は、チーム メンバーがワークフローを通して、作業の進捗をより視覚的に追跡できるようにすることです。カンバン カードには特定の作業項目に関する重要な情報が書かれており、その作業項目における責任者、進行中の作業の概要、特定の作業項目にかかると予測される時間などをチーム全員が完全に把握できるようにします。バーチャルのカンバン ボード上のカードには、スクリーンショットや、担当者にとって重要な技術的詳細が表示されていることもよくあります。すべての作業項目の状況および関連情報を、チーム メンバーがいつでも確認できるようにすることで、焦点の明確化や、完全なトレーサビリティが実現でき、ブロッカーや依存関係を迅速に特定できるようになります。

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

カンバンチームは現在進行中の作業にのみ集中します。チームは作業項目を完了すると、バックログの一番上に位置する作業項目を取り出します。現在の作業項目以外の作業に対する変更はチームに影響を与えないため、プロダクト所有者はチームの作業を邪魔することなく、自由にバックログの優先順位を変更できます。プロダクト所有者が常にバックログの一番上に最も重要な作業項目を配置している限り、開発チームは事業に最大の価値を還元できるのです。そのため、スクラムで見られるような固定長のイテレーションは不要です。

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

スキル セットの重複はサイクル期間の短縮につながります。スキル セットを持っている人が一人しかいない場合、その人がワークフローのボトルネックになります。そこでチームは、コード レビューや指導的支援などの基本的なベスト プラクティスを採用し、知識を広めています。スキルが共有されていれば、チーム メンバーは異種の作業を引き受けられ、サイクル期間をさらに最適化できます。また、作業にボトルネックがある場合も、スキルが共有されていればチーム全体がその作業に取りかかり、プロセスが再びスムーズに流れるようにできます。たとえば、テストは QA エンジニアだけが行うものではありません。開発者も協力できます。

カンバン フレームワークでは、仕事がプロセスの中でスムーズに流れるようにするのはチーム全体の責任です。

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

たとえば、典型的なソフトウェア チームには 4 つのワークフロー状態があります。To Do、進行中、コード レビュー、完了です。コード レビュー状態では、WIP 制限を 2 に設定できます。制限が厳しいように感じるかもしれませんが、これには理由があります。開発者は、他人の作業のレビューをするより、新しいコードを書くことを好むものです。厳しい制限を設定していれば、チームはレビュー状態の課題に特別な注意を払い、自身のコード レビューを登録する前に他の人の作業のレビューをするようになります。これは、全体的なサイクル期間の短縮につながります。

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

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

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

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

カンバンとスクラムの理念を "スクラムバン" に融合しているチームもあります。その場合は、スクラムから固定長スプリントとロールを、カンバンから進行中の作業制限とサイクル期間に重点を置く手法を取り込んでいます。しかし、アジャイルを開始したばかりのチームは、どちらか 1 つの方法を選択して、しばらくの間それを実行することを強くお勧めします。カスタマイズは、後からでも可能です。