Close

カンバン

ソフトウェア開発でカンバン方式を活用する方法

トピック一覧

カンバンとは何か

カンバンは、アジャイルなソフトウェア開発の実装によく使用されるフレームワークです。キャパシティについてのリアルタイムのコミュニケーションや、作業の完全な透明性が必要となります。作業項目は視覚的にカンバンボードに表示され、チームメンバーはいつでも、すべての作業の状況を確認できます。

カンバンに関する記事

[続き]

カンバンは現在のアジャイルソフトウェアチームにおいて非常によく使用されるようになりましたが、カンバン方式には 50 年以上もの歴史があります。1940 年代後半、トヨタはスーパーマーケットが商品を棚に並べる方法に基づき、エンジニアリングプロセスの最適化を開始しました。スーパーマーケットは顧客のニーズを満たすために必要最小限の在庫のみをストックしています。これは、スーパーマーケットと顧客間の商品の流れを最適化する方法です。在庫レベルが消費パターンと一致しているため、スーパーマーケットは常に持っておかなければいけない余剰在庫を減らし、在庫管理を大幅に効率化できるのです。同時に、顧客が買いたいと思う商品の在庫は常に保持できます。

トヨタが同様のシステムを工場で採用したとき、目標は膨大な在庫レベルと実際の部品の消費を一致させることでした。キャパシティレベルをリアルタイムで工場内 (およびサプライヤー) に伝えるため、従業員はチーム間で "カンバン" と呼ばれるカードをやりとりしました。生産ラインで使用される部品が一箱分なくなると、必要な部品、必要量などが書かれたカンバンが倉庫に渡されます。倉庫にはこの部品が入った新しい箱がすでに用意されていて、これを工場に送り、倉庫からもカンバンをサプライヤーに渡します。サプライヤーも、この部品が入った部品箱をすでに用意していて、これを倉庫に送ります。このプロセスに使用される、合図を送る技術は 1940 年当時に比べて進化しましたが、"ジャストインタイム (JIT)" という製造プロセスは今もカンバン方式の中核となっています。

ソフトウェアチームにとってのカンバン

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

カンバンボード | アトラシアンアジャイルコーチ

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

カンバンボード

すべてのカンバンチームの作業は、カンバンボードを中心としています。これは、作業を可視化し、チーム内の作業の流れを最適化するツールです。物理的なボードが使いやすいというチームもありますが、アジャイルソフトウェア開発ツールにとっては、バーチャルボードが必要不可欠です。トレーサビリティがあり、コラボレーションしやすく、複数の拠点からアクセスできるからです。

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

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

アジャイルカンバンボード | アトラシアンアジャイルコーチ

カンバンカード

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

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

カンバンのメリット

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

柔軟なプランニング

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

プロからのヒント:

精通したプロダクト所有者は、バックログの変更を検討する際、常に開発チームを関与させます。たとえば、ユーザーストーリー 1 ~ 6 がバックログにある場合、ユーザーストーリー 6 の見積もりは、ユーザーストーリー 1 ~ 5 の完了状況に基づき作成できます。エンジニアリングチームと変更点を確認し、不測の事態が起こらないようにしておくことをお勧めします。

サイクル期間の短縮

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

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

カンバンフレームワークにおいて、作業がプロセスを通してスムーズに流れるようにするのはチーム全体の責任です。

ボトルネックの減少

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

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

指標の可視化

カンバンの基本理念の一つは、作業のすべてのイテレーションにおいて、チーム効率と効果の継続的な改善にフォーカスを当てることです。図があれば、チームは改善し続けていることを視覚的に確認できます。チームがデータを確認できれば、プロセスにおけるボトルネックの特定 (および排除) がより簡単になります。カンバンチームがよく使用するレポートは管理図と累積フロー図の 2 つです。

管理図は、各課題のサイクル期間やチームのローリング平均を示します。

プロからのヒント:

チームの目標は、課題がプロセス全体を移動するのにかかる時間を減らすことです。管理図で平均サイクル期間が減少していれば、それが成功の指標となります。

アジャイル管理図 | アトラシアンアジャイルコーチ

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

累積フロー図

継続的デリバリー

継続的インテグレーション、つまり 1 日を通じて段階的にコードのビルドと検証を行うことが、品質維持には欠かせないことは知られています。では、次に継続的デリバリー (CD) を見てみましょう。これは、毎日でも毎時でも、頻繁に顧客に作業をリリースする仕事の進め方です。カンバンと CD はどちらも、ジャストインタイムで (また一度に 1 つずつ) 価値を提供することに焦点を当てているため、お互いにうまく補完し合います。

チームがより早く市場にイノベーションを届けられるようになれば、市場における製品の競争力はより強くなります。カンバンチームは、顧客に製品を届けるための作業フローの最適化にフォーカスしています。

スクラムとカンバン

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

 

スクラム

カンバン
期間

一般的な固定長スプリント (2 週間など)

継続的なフロー
リリース方式 プロダクト所有者の承認があれば、各スプリント後 継続的デリバリーまたはチームの判断
役割 プロダクト所有者、スクラムマスター、開発チーム 既存の役割なし。チームによってはアジャイルコーチの支援を求める。
主要指標 ベロシティ サイクル期間
変更に関する考え方 チームはスプリント中にスプリント予測を変更しないように努力するべきである。変更すれば、見積もりに関する知見が損なわれる。 いつ変更してもかまわない

 

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

Dan Radigan
Dan Radigan

Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling. 

次の記事
Boards