カンバン
ソフトウェア開発でカンバン方式を活用する方法
トピック一覧
カンバンに関する記事
Jira Software を使用したカンバンの学習
カンバンプロジェクトの推進、作業の優先順位付け、ワークフローの視覚化、進行中の作業の最小化などの操作を Jira Software で実行する方法を説明するステップバイステップの手順
このチュートリアルを試すJira カンバン ボードで「作業前」から「完了」へ
Jira Software のカンバン ボードは、チームがサイクル期間を継続的に改善し、効率を高められるよう設計されています。
無料で入手するカンバンは現在のアジャイルで DevOps なソフトウェア チームにおいて非常によく使用されるようになりましたが、カンバン方式には 50 年以上もの歴史があります。1940 年代後半、トヨタはスーパーマーケットが商品を棚に並べる方法に基づき、エンジニアリング プロセスの最適化を開始しました。スーパーマーケットは消費者の需要を満たすのに必要なだけの製品を仕入れます。これがスーパーマーケットと消費者の間の製品の流れを最適化する方法です。在庫レベルが消費パターンと一致しているため、スーパーマーケットは常に持っておかなければいけない余剰在庫を減らし、在庫管理を大幅に効率化できるのです。同時に、顧客が買いたいと思う商品の在庫は常に保持できます。
トヨタが同様のシステムを工場で採用したとき、目標は膨大な在庫レベルと実際の部品の消費を一致させることでした。キャパシティレベルをリアルタイムで工場内 (およびサプライヤー) に伝えるため、従業員はチーム間で "カンバン" と呼ばれるカードをやりとりしました。生産ラインで使用される部品が一箱分なくなると、必要な部品、必要量などが書かれたカンバンが倉庫に渡されます。倉庫にはこの部品が入った新しい箱がすでに用意されていて、これを工場に送り、倉庫からもカンバンをサプライヤーに渡します。サプライヤーも、この部品が入った部品箱をすでに用意していて、これを倉庫に送ります。このプロセスに使用される、合図を送る技術は 1940 年当時に比べて進化しましたが、"ジャストインタイム (JIT)" という製造プロセスは今もカンバン方式の中核となっています。
ソフトウェアチームにとってのカンバン
アジャイルソフトウェア開発チームも、進行中の作業 (WIP) 量とチームのキャパシティを一致させることで、同じ JIT の考え方を活用できます。これによりチームは開発サイクル全体を通して、より柔軟なプランニングのオプション、迅速なアウトプット、焦点の明確化、透明性を実現できます。

このフレームワークの基本原則はいつの時代も、ほとんどの業界で適用可能ですが、ソフトウェア開発チームはアジャイル プラクティスにおいて特に成功を収めました。これは、ソフトウェア チームは基本原則を理解さえすれば、ほとんど経費を使用することなくカンバン方式を実践できたからでもあります。工場でカンバン方式を採用すると、物理的なプロセスを変更したり、使用する道具を追加したりする必要が生まれますが、ソフトウェア チームの場合はこれとは異なり、ボードとカードさえあれば開始できたのです。また、この 2 つのツールがバーチャルであっても実現可能でした。
カンバンボード
あらゆるカンバンチームの仕事は、カンバンボードを中心に展開します。カンバンボードとは仕事を可視化し、チームメンバー間で仕事の流れを最適化するためのツールです。物理的なボードを好んで使っているチームもありますが、仮想ボードはどんなアジャイルソフトウェア開発ツールであっても必須の機能です。なぜなら仮想ボードであれば、トレーサビリティを確保し、コラボレーションを容易にし、複数の場所からのアクセスができるからです。
チームのボードが物理的なものでもデジタルでも、その機能は同じです。チームの作業を可視化し、ワークフローを標準化し、すべてのブロッカーと依存関係を即座に認識し、解決します。基本的なカンバンボードには、To Do、進行中、完了の 3 段階のワークフローがあります。しかし、チームのサイズ、構成、目的によって、ワークフローをそれぞれのチーム特有のプロセスに沿うように変更できます。
カンバン方式は、作業の完全な透明性と、キャパシティに関するリアルタイムのコミュニケーションに依存します。そのため、カンバン ボードをチームの作業に関する、信頼できる唯一の情報源としてください。

カンバンカード
日本語でカンバンとは、「視覚信号」を意味します。カンバン チームにとって、作業項目はすべて、ボード上の異なるカードとして表示されます。
作業をカードとしてカンバン ボードに表示する主な目的は、チーム メンバーがワークフローを通して、作業の進捗をより視覚的に追跡できるようにすることです。カンバン カードには特定の作業項目に関する重要な情報が書かれており、その作業項目における責任者、進行中の作業の概要、特定の作業項目にかかると予測される時間などをチーム全員が完全に把握できるようにします。バーチャルのカンバン ボード上のカードには、スクリーンショットや、担当者にとって重要な技術的詳細が表示されていることもよくあります。すべての作業項目の状況および関連情報を、チーム メンバーがいつでも確認できるようにすることで、焦点の明確化や、完全なトレーサビリティが実現でき、ブロッカーや依存関係を迅速に特定できるようになります。
カンバンのメリット
カンバンは、今日アジャイルチームに採用されているソフトウェア開発方法の中でも、最高クラスの人気を誇ります。カンバンには、あらゆる規模のチームにとってタスクの計画と処理における複数の利点があります。
柔軟なプランニング
カンバンチームは現在進行中の作業にのみ集中します。チームは作業項目を完了すると、バックログの一番上に位置する作業項目を取り出します。現在の作業項目以外の作業に対する変更はチームに影響を与えないため、プロダクト所有者はチームの作業を邪魔することなく、自由にバックログの優先順位を変更できます。プロダクト所有者が常にバックログの一番上に最も重要な作業項目を配置している限り、開発チームは事業に最大の価値を還元できるのです。そのため、スクラムで見られるような固定長のイテレーションは不要です。
精通したプロダクト所有者は、バックログの変更を検討する際、常に開発チームを関与させます。たとえば、ユーザーストーリー 1 ~ 6 がバックログにある場合、ユーザーストーリー 6 の見積もりは、ユーザーストーリー 1 ~ 5 の完了状況に基づき作成できます。エンジニアリングチームと変更点を確認し、不測の事態が起こらないようにしておくことをお勧めします。
サイクル期間の短縮
サイクル期間は、カンバンチームにとって重要な測定指標です。サイクル期間は、1 つの作業ユニットがチームのワークフローを完了 (作業の開始から出荷まで) するのにかかる時間です。サイクル期間を最適化することにより、チームは自信を持って、今後の作業の提供について予測できます。
スキル セットの重複はサイクル期間の短縮につながります。スキル セットを持っている人が一人しかいない場合、その人がワークフローのボトルネックになります。そこでチームは、コード レビューや指導的支援などの基本的なベスト プラクティスを採用し、知識を広めています。スキルが共有されていれば、チーム メンバーは異種の作業を引き受けられ、サイクル期間をさらに最適化できます。また、作業にボトルネックがある場合も、スキルが共有されていればチーム全体がその作業に取りかかり、プロセスが再びスムーズに流れるようにできます。たとえば、テストは QA エンジニアだけが行うものではありません。開発者も協力できます。
カンバン フレームワークでは、仕事がプロセスの中でスムーズに流れるようにするのはチーム全体の責任です。
ボトルネックの減少
マルチタスクは効率を損ないます。同時に進める作業項目が多ければ多いほど、コンテキストの切り替えが増え、作業の完了が妨げられます。カンバンの主要理念が、進行中の作業 (WIP) の量を制限することであるのはそのためです。進行中の作業を制限することにより、集中度や人員、スキルの不足が原因でチームのプロセスに生じるボトルネックと滞りが明確になります。
たとえば、典型的なソフトウェア チームには 4 つのワークフロー状態があります。To Do、進行中、コード レビュー、完了です。コード レビュー状態では、WIP 制限を 2 に設定できます。制限が厳しいように感じるかもしれませんが、これには理由があります。開発者は、他人の作業のレビューをするより、新しいコードを書くことを好むものです。厳しい制限を設定していれば、チームはレビュー状態の課題に特別な注意を払い、自身のコード レビューを登録する前に他の人の作業のレビューをするようになります。これは、全体的なサイクル期間の短縮につながります。
指標の可視化
カンバンの基本理念の一つは、作業のすべてのイテレーションにおいて、チーム効率と効果の継続的な改善にフォーカスを当てることです。図があれば、チームは改善し続けていることを視覚的に確認できます。チームがデータを確認できれば、プロセスにおけるボトルネックの特定 (および排除) がより簡単になります。カンバンチームがよく使用するレポートは管理図と累積フロー図の 2 つです。
管理図は各課題のサイクルタイムだけでなく、チームの移動平均を表示します。
チームの目標は、課題がプロセス全体を移動するのにかかる時間を減らすことです。管理図で平均サイクル期間が減少していれば、それが成功の指標となります。
累積フロー図は各段階にある課題の数を示します。チームは、特定の段階において課題の数が増加していることを見ることで、簡単にブロッカーを特定できます。"進行中" や "レビュー中" といった中間のステータスにおける課題は、まだ顧客に届いていません。こういった段階でのブロッカーは、作業が上流にマージされる際に、大規模なインテグレーションの競合を生む可能性が高くなります。
継続的デリバリー
継続的なデリバリー (CD) は、ソフトウェアを顧客に頻繁にリリースする方法です。継続的インテグレーション (CI) は 1 日を通じて段階的にコードのビルドと検証を自動的に行う方法です。これらを組み合わせて、開発チーム (特に DevOps チーム) に不可欠な CI/CD パイプラインを形成し、高品質を保証しながらソフトウェアをより迅速にリリースします。
カンバンと CD はどちらも、ジャストインタイムで (また一度に 1 つずつ) 価値を提供することに焦点を当てているため、お互いにうまく補完し合います。チームがイノベーションを市場に届けるスピードが速いほど、その製品の市場における競争力が高まります。そして、カンバン チームはまさにそこに焦点を当てています。すなわち、顧客に届ける作業の流れの最適化です。
スクラムとカンバン
カンバンとスクラムは同じ概念をいくつか共有していますが、そのアプローチは非常に異なっています。この 2 つを混同してはいけません。
スクラム | カンバン | |
期間 | 一定の固定長のスプリント (すなわち、2 週間) | 継続的なフロー |
リリース方法 | プロダクトオーナーの承認があれば、各スプリントの最後 | 継続的デリバリーまたはチームの判断 |
役割 | プロダクトオーナー、スクラムマスター、開発チーム | 既存の役割なし。チームによりアジャイルコーチの支援を得る。 |
主要指標 | ベロシティ | サイクルタイム |
変更に関する考え方 | チームはスプリント中にスプリント予測を変更しないように努力するべきである。変更すれば、見積に関する知見が損なわれる。 | いつ変更してもかまわない |
カンバンとスクラムの理念を "スクラムバン" に融合しているチームもあります。その場合は、スクラムから固定長スプリントとロールを、カンバンから進行中の作業制限とサイクル期間に重点を置く手法を取り込んでいます。しかし、アジャイルを開始したばかりのチームは、どちらか 1 つの方法を選択して、しばらくの間それを実行することを強くお勧めします。カスタマイズは、後からでも可能です。
Jira カンバン テンプレートを無料で始める
最も重要な作業を確認して前進させることで、効率を最大限に高めます。
準備はできましたか?
カンバンプロジェクトの推進、作業の優先順位付け、ワークフローの視覚化、進行中の作業の最小化などを Jira Software で実行する方法を説明するステップバイステップの手順です。
このチュートリアルを読むアジャイルデザイン: コラボレーティブなデザインのプロセスとガイドライン
コラボレーティブなデザインでは、プロジェクトの開始時に顧客と開発者の視点で考えることで、製品デザインをイテレーションします。詳細をご覧ください。
この記事を読む