開発手法「カンバン」について

Pocket

開発手法「カンバン」について

はじめに

「カンバン」は 「デイヴィッド・アンダーソン氏(David J. Anderson)」がまとめた開発方法論です。
「ジャストインタイム」トヨタ生産方式、通称「かんばん方式」のアイデアを、
ソフトウエア開発用にアレンジして考案されました。

「カンバン」は アジャイル開発手法の1つです。
近頃、アジャイル=「スクラム」 と認識がされているように思いますが、「カンバン」もアジャイル開発の有力な選択肢になるものと思います。

  • 『今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント』という本を読み
    「カンバン」が非常に興味深かったのでこの記事を書いています。
  • 重要な内容から先頭に書くように構成しました。
    後ろに行くほど細かい内容になりますので、飽きたところで読むのを切り上げると効率いいかと思います。(細かい内容も知りたければ最後までお付き合いください)
  • 文章中「カンバン」という単語が、「開発手法としての意味」と「ツールとして意味」
    との2種類の意味で出現し、分かり難くなってしまいました。
    分かり難くさを緩和するために、開発手法としての意味で使用する場合はカギ括弧をつけて「カンバン」とし、
    ツールとしての意味で使用する場合はカギ括弧なしでカンバンと表記することにします。

「カンバン」とはどういうものか(超簡易版)

開発手法「カンバン」は、 タスク項目を貼ったボードを壁に設置した カンバン を使って プロジェクト管理する開発手法です。

「カンバン」の儀式度

  • 「カンバン」の儀式度は非常に低いです。
    このため、導入障壁が低いです。(アジャイルプロセスでよく導入される 「タイムボックス」も存在しません。)

(注) 儀式度
「作成すべき成果物」「実施すべきイベント」「開発上のルール」「開発手順」「定義しないといけない役割」などが多い開発プロセスを「儀式度が高い(higher ceremony)」と言います。
儀式度が高くなればなるほど、『○○しなければならない』『○○を作らなければならない』『○○を守らなければならない』『○○を開催しなければならない』『○○をする人を定義しなければいけない』というものが多いということになります。

(注) タイムボックス
スクラムやXPなどのアジャイルプロセスでは、
数週間 の期間で実施するタスクを最初に計画して、それらのタスクを期間なににすべて完了させます。
タイムボックスにより、開発に一定のペースを作りプロジェクトが混乱状態になることを回避します。
スクラムでは、このタイムボックスを 「スプリント」 と呼びます。

「カンバン」の儀式

「カンバン」とよべる状態であるためには、以下のような儀式が必要です。 (ここでは詳細は省略します)

  • カンバン(壁に設置してタスク項目を管理するボード)を使う
  • WIP制限
  • ステップごとの完了基準を定義する
  • デイリースタンドアップミーティング

「カンバン」に対する私的評価 (このブログの結論のようなもの)

あくまでも私的な評価ですが、 期待できる面と不安な面を以下にあげます。

期待できる面

  • 儀式度が非常に低く、導入するためのハードルも非常に低い
    (人的側面、環境面、導入コスト面 どの面からもハードルが低い)
  • カンバンを導入することにより、プロジェクトの混乱を改善できそう
  • より必要な成果物が、より早く提供でき、
    また、重要でない成果物を作らなくてすむようになりやすい。
    (おそらく、これが、「カンバン」が最も目指すことろ)

不安な面

  • チームメンバーに依存する (どんなプロセスにも言えるが、「カンバン」は特にメンバー構成が成否に大きく影響しそう )
    • 向かないメンバーやメンバー構成
      • 決まったルーチンワークをこなしたいメンバーが参加する
      • 現状に対する改善に興味がないメンバーが参加する
      • チームに分析力のあるメンバーが参加しない
  • 旧来の「ガントチャート」「PERT図」「WBSという名の進捗表」にこだわる上位マネジメントの影響が強い場合、非常に活動しにくい
    (「重要でない成果物を作らない」ことができず「カンバン」を導入する意味がなくなる。 マネジメント層を説得する必要がある。)

総評

  • 導入コストが低いにも拘わらず、期待できる効果が大きいと感じました。(費用対効果が良い)
  • 「会議」、「ボトルネックによる進捗の停止」、「作業のやり直し」 などによって失われる時間を減らす
    効果が期待できそうです

「カンバン」とはどういうものか(もう少し詳しく)

まずは、プロセス「カンバン」で使うカンバン自体を説明していきます。

「スクラム」でもカンバン(スクラムボード)を使うことが多いかと思いますが、
「カンバン」と「スクラム」とでは使用するカンバンが異なります。
(カギ括弧の有無を注意してお読みください。。。)

スクラムのカンバン(スクラムボード)との違い

「スクラム」のカンバン(スクラムボード)

「スクラム」では通常は以下のように3列に分けたカンバンを使います。
(各列のことを「スイムレーン」と呼びます。以下の例では3つのスイムレーンがあります)

    ┌------┬-------┬------┐  
    |Todo  |Doing  | Done |  
    └------┴-------┴------┘  

通常は以下のような運用をします。

  • スプリント毎に、新しくカンバンを作り直します。
    (「スクラム」ではスプリント毎にタスクをすべて消化することが原則です)
  • スプリントで実施するタスク(「スプリントバックログ」と呼びます)をすべて Todo に配置します。 (配置した時点で通常は担当者も決めておく)
  • 着手したタスクを Doing に移動
  • Doing のタスクが完了したら Done に移動
  • 最終的には、すべてのタスクが Done に移動して終了 (スプリントも終了)

スクラムの「カンバン」は Todo Doing Done 文字通りの運用でとても分かりやすいですね。

「カンバン」で使うカンバン

「カンバン」で使うカンバンは以下のようなものです。(一例。カンバンでは開発チーム毎のルーチンに合わせてステップ分けすることになっています。)

    ┌-----------┬-----------┬-----------┬-----------┐  
    |バックログ | 分析      |実装       |検証       |  
    |           | (2)       | (5)       | (3)       |  
    |           ├-----┬----┼-----┬----┼-----┬----┤  
    |           |Doing|Done|Doing|Done|Doing|Done|  
    └-----------┴-----┴----┴-----┴----┴-----┴----┘  

(注) アスキーで書いた表、ずれてしまっているかもしれませんが雰囲気でお察しください

上の例は、標準的なカンバンの例です。
(チームが採用しているプロセスに合わせてスイムレーンを定義するこが推奨されています。
どういうカンバンにするか判断つかない場合は このスイムレーンから始めて見ると良いらしい。)

カンバン運用方法は、若干複雑なので、もう少しあとで説明していきます。

「カンバン」と「スクラム」との比較

「スクラム」のカンバンより、複雑で分かり難いと感じるかもしれません。
しかしながら、「カンバン」ではこのカンバンを使って開発するという以外のルールがほとんどありません。
一方、「スクラム」のカンバン(スクラムボード)は、「スクラム」の構成要素のごく一部でしかありません。
プロセス全体として考えると、「カンバン」のほうが「スクラム」よりシンプルです。

(注) この記事ではスクラムについてのこまかい説明しません。(「カンバン」の記事なので) ご了承ください

(注) カンバン中の「括弧付き数字」は WIP制限 と呼ばれるものです。説明は後にしますので、しばらく無視してください


カンバン運用方法

カンバンの運用方法を説明していきます。(細かいところは大きくはしょります)

  • (注意) 上の『「カンバン」で使うカンバン』の図は横方向にスイムレーンが書かれていましたが、
    これ以降ブログの紙面の書きやすさの都合上
    スイムレーンの縦横を入れ替えて以下のように書きます。(すみません。。。)
    また、タスク項目はカッコつきで [A] のように表現します。

    • カンバン上のの項目のスナップショットイメージ
      • バックログ … [A],[B],[C]
      • 分析(2) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _
      • 実装(5) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _
      • 検証(3) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _
    • 上の例の場合、バックログにタスク [A],[B],[C] 3つが配置されており、他のスイムレーンにはなにも入っていない状態です

この下から、プロジェクトで発生したイベント事にどのようにカンバンを運用していくか説明していきます

バックログに配置

開発対象タスクすべてを、バックログの項目として追加します。 (「カンバン」にはスプリントがありません。文字通り認識しているタスク全部を追加します )

  • バックログの項目に優先順位を付けます
    • 利害関係者を集めた会議で優先順位を付けるような運用を想定していますが、優先順位の決定方法は開発チームや利害関係者などの状況次第で運用を検討する必要があります。
  • カンバン上のの項目のスナップショットイメージ
    • バックログ … [A],[B],[C]
    • 分析(2) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _
    • 実装(5) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _
    • 検証(3) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _

分析開始

バックログの最優先のものから項目を取り出し、「分析のDoing」に配置します。配置した項目の「分析」に着手します。

  • 項目を分析および仕様を明確化し、結果として後続の実装で管理される細かい項目に分割していきます。
  • カンバン上のの項目のスナップショットイメージ
    • バックログ … [B],[C]
    • 分析(2) | (Doing) [A] _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _
    • 実装(5) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _
    • 検証(3) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _

分析完了

分析が完了すると、1つの項目を実装できる適当なサイズの複数個の項目に分離し、「分析(Done)」に配置します。
以下の例では、 タスク [A] が [A1][A2][A3] の3つに分割された状態です

  • カンバン上のの項目のスナップショットイメージ
    • バックログ … [B],[C]
    • 分析(2) | (Doing) _ _ _ _ _ _ _ _ | (Done) [A1][A2][A3] _ _
    • 実装(5) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _
    • 検証(3) |(Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _

実装開始

分析(Done)の項目から1つ取り出し、実装(Doing)に移動します。配置した項目の実装を開始します。

  • カンバン上のの項目のスナップショットイメージ
    • バックログ … [B],[C]
    • 分析(2) | (Doing) _ _ _ _ _ _ _ _ | (Done) [A2][A3] _ _ _ _
    • 実装(5) | (Doing) [A1]_ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _
    • 検証(3) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _

実装完了

実装が完了したら、実装(Done)に項目を移動します。

  • カンバン上のの項目のスナップショットイメージ
    • バックログ … [B],[C]
    • 分析(2) | (Doing) _ _ _ _ _ _ _ _ | (Done) [A2][A3] _ _ _ _
    • 実装(5) | (Doing) _ _ _ _ _ _ _ _ | (Done) [A1]_ _ _ _ _ _ _
    • 検証(3) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _

検証開始

実装(Done)の項目から1つ取り出し、検証(Doing)に移動します。配置した項目の検証を開始します。

  • カンバン上のの項目のスナップショットイメージ
    • バックログ … [B],[C]
    • 分析(2) | (Doing) _ _ _ _ _ _ _ _ | (Done) [A2][A3] _ _ _ _
    • 実装(5) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _
    • 検証(3) | (Doing) [A1] _ _ _ _ __ _ | (Done) _ _ _ _ _ _ _ _

検証完了

検証が完了したら、検証(Done)に項目を移動します。 検証(Done) に移った項目は完了状態になります。

  • カンバン上のの項目のスナップショットイメージ
    • バックログ … [B],[C]
    • 分析(2) | (Doing) _ _ _ _ _ _ _ _ | (Done) [A2][A3] _ _ _ _
    • 実装(5) | (Doing) _ _ _ _ _ _ _ _ | (Done) _ _ _ _ _ _ _ _ _
    • 検証(3) | (Doing) _ _ _ _ _ _ _ _ | (Done) [A1]_ _ _ _ _ _ _

以上がカンバンの運用方法です。
実際のプロジェクトでは、複数人が参加するので、複数個のタスクが任意のタイミングで 次のスイムレーンに移動していくことになります。


細かいところを更に説明

はしょった細かいところや用語を補足していきます。

WIP制限

「分析(2)」「実装(5)」「検証(3)」のカッコ内の数字はWIP制限です。WIPは仕掛状態のタスク(Work In Progress)を意味していて、
この数字を超えて、そのステップにタスクを取り込むことを禁止するルールです。
このルールを「カンバン」は非常に重要視しています。

WIP制限がないと以下のような弊害が起こります。

  • 分析作業が完了して「分析(Done)」にどんどん項目がたまる。
    にも拘わらず、実装がなかなか進まず、「分析(Done)」に項目がたまる一方。
    昔分析し終わった項目は記憶が薄れているし、時間がたってしまったがために有用でなくなっているかもしれない。
    再分析する必要があるかもしれない。
  • 実装をどんどん完了して、実装(Done)に項目がたまる。
    時間がたって検証(Doing)に取り込んだが、実装(Done)の内容の記憶が薄れていてオーバーヘッドがかかる。
    そのうえ、実装(Done)の項目どおしに実は依存関係がることもあり、収集がつかなくなる。

このような状態では以下のようなムダが発生します

  • タスクに着手してもなかなか完了しない。価値の提供が遅れる
  • 複数のタスクを平行に多数こなすことでタスク切替が発生し余分なコストになる

WIP制限に抵触した場合の例

『分析(2)』となっている場合、
例えば、2項目の分析が完了して、それぞれ、3個の 分析(Done)の項目と 4個の 分析(Done) の項目に分割されている状態の場合、
WIP制限により、それ以上、 分析(Doing) に新しく項目を追加することはできません。
このような状態の場合、「カンバン」では、
分析を担当しているメンバーが実装のスピードアップを手助けするべきとしています。
たとえば、 「実装の阻害要因になっていことを取り除く」「直接実装のメンバーを手助けをする」というような行動をとるべきです。
そもそもの実装担当の人員配置人数を見直すことも必要かもしれません。
ボトルネックを解消できるようにチームが協力するという行動をとることが「カンバン」の思想です。

  • タイムボックス と WIP制限 について
    アジャイルプロセスの多くでは「タイムボックス」が定義されています。
    「タイムボックス」にを導入することにより、混乱しがちな開発をペース付けして統制をとるという側面があります。
    「カンバン」にはタイムボックスを定義するのではなく、WIP制限によりプロジェクトの混乱状態を回避しようとしています。

「ドラム・バッファー・ロープ」

WIP制限を活用してどのようにプロジェクトを進めれば良いかという背景となる理論として、
「ドラム・バッファー・ロープ理論」というものがあります。

スケジュールを最適化するためには、ボトルネックとなる長いステップにペースを合わせて工程を見直しなさいという手法です

  • ポイント
    • 長いステップの作業機会をうばわない
    • 長いステップをせかすような圧力をかけない

以下、ドラム・バッファー・ロープ理論を比ゆ的に表現したお話です。

「幼い娘」「私」「犬」 で散歩します。
歩くスピードは、左が一番遅く右が速いです。

「幼い娘」には「迷子ひも」をつけて娘を見失わないようにします。
「犬」にはロープを付けてどっかにいってしまわないようにします。(犬が暴走するすると困る)
「迷子ひも」は変化に対処できるように適度に緩ませておく必要があります。(娘は、走ったり、立ち止まったり、横にそれたりします。)

この状態であれば、安定して楽しい散歩ができます。

円滑に散歩するために守らないといけないのは

  • 娘が歩くのを邪魔しないようにする
  • 娘に早く歩くようせかしてはいけない (泣き出したり、疲れて歩けなくなったりする)

一般的な開発においての「実装」を、「幼い娘」にたとえています。
開発で一般的に一番時間がかかることが多い「実装」ステップを、
「邪魔したり(割り込み作業を追加する)」、
「圧力をかけたり(スケジュールを盾にせかせるとか 長時間労働を強いるとか)」、
してはいけない。という理論です。

この指針を守らないことにより、
チームが疲弊したうえ、品質が低下し、さらに、バグだらけのリソースの対応に時間がかかりトータルコストが余分にかかる
ということを警告しています。

分析作業について

分析作業がどういうものを意味しているのかイメージしにくいかと思います。

「はじめに」で紹介した本では、ディズニーランドの例として分析作業を紹介していました。

『ディズニーランドに行くことは、
アドベンチャーランド、フロンティアランド、ファンタジーランド、トゥモローランドを見ることに分解されます。』

システム開発でどのようなものかというと、
「ユーザーストーリ視点の要求事項」や「曖昧な仕様」や「粒度の大きすぎる内容」として定義されたタスク項目を、
市場などシステムに関係するの状況を分析した結果、次のステップ「実装」で着手できるようにタスク分割します。
具体的なサービスレベルを決定し、
仕様を具体化し、
タスクの工数規模を均一化する、
ようなことをする作業というイメージでよいかと思います。

ステップ分けについて

ステップ(カンバン上のスイムレーンの数) はチームの特性に合わせて、自由に設定してよいことになっています。
ステップ分けは、1人が続けて実施する作業は複数ステップに分割しないことを推奨しています。

作業担当について

「はじめに」で紹介した本では、「プロジェクトマネージャー」「リーダー」「アナリスト」「実装担当」「検証担当」など枠割を分けることが標準的とされていました。
ただし、役割に対する強い強制はありません。

デイリースタンドアップミーティングについて

5分以内で実施するミーティングです。カンバンでは必ず実施する必要があるとされています。
カンバンボードを取り囲んで開催します。
目的は、「ブロックされているメンバーや 助けを必要としているメンバーを把握すること」、
「問題を解決するために人を割り当てること(通常はプロジェクトマネージャーを割り当てる)」
というようなことです。

各ステップの完了基準について

各タスク項目が、左から右に移動するための基準を定義することの重要性を説いています。
完了基準があいまいだと、次のステップが円滑に進まず、WIP制限に引っ掛かる状態になりやすくなります。


「カンバン」の思想や理論的側面

「カンバン」の思想や理論的背景についてのキーワードを簡単にご紹介します。

  • 見える化
    カンバンの中心にある考え方。
    カンバンを見ることで、ボード、ステップ、完了基準、作業項目をいつでもだれでも見られる。状況が透明化される。
    (スクラムでも「透明性」は3本柱の最初にあげられる非常に重要な価値。この思想は「カンバン」と「スクラム」とは類似している)
  • 最小限主義
    「カンバン」は既存のワークフローを極力変えずに導入し調整はわずかにする。
    既存の、役割、責務、役職、チームも維持したまま。「カンバン」を導入してすぐに生産性と品質の改善が享受しやすい。
  • リトルの理論
    待ち行列理論。待ち時間を推測する例で紹介されることがある理論。
    WIP制限の数をこの理論に基づいて設定するのがよいとのこと。
  • 一個流し
    トヨタ生産方式に関する理論。複数の製品を1ロットとして生産した場合、
    「運搬コスト発生」「不良の大量発生」「不良発生時に全調査」「長い生産リードタイム」というリスクを抱えることになる。
    これを避けるために、トヨタ生産方式では1製品づつ生産し完成させていくという思想。
    WIP制限を重視している「カンバン」の理論的な背景になっている。
  • 制約理論
    最も制約となっているフォーカスして問題解決に取り組もうとする理論。
    WIP制限で 「実装(5)」と他のステップより制限数が多くしているのは、
    「実装」がボトルネックであり、アサインする要員を増やしてボトルネックを解消するため。
  • ドラム・バッファー・ロープ
    前出の WIP制限 の説明で紹介した理論

あとがきと感想

『今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント』 からの一部抜粋です。

しかし、チームの生産性と品質に最も大きな影響をおよぼしたのはスクラムでした —
それも 4年前にカンバンに切り替えるまでの話ですが。「カンバンのおかげで、チームが行う作業の一瞬一瞬がプロダクトの顧客価値を高めている」
と正直に言えるのは、筆者の長いキャリアの中でこれが初めてです。無駄になる時間や作業は一切なく、品質が保証されます。

私は「カンバン」を採用したプロジェクトは未経験ですが、
作者の感じたこの言葉は、非常に魅力的に映りました。

スクラムについては、一部要素を取り入れて、プロジェクト改善を目指したことは何度かあります。
ただ、「プロダクトオーナー」と「スクラムマスター」が開発で設定できず、
スクラム開発と呼べるような状態のプロジェクトにはできませんでした。

また、同僚でスクラムを導入しているチームのスクラムマスターの話によると
「スクラムのセレモニー」は工数がかなりかかるので改善したいと思っているとのことです。

「スクラム」は比較的自由度の高いプロセスですが、「カンバン」はそれ以上に自由度が高そうです。
また、「カンバン」については導入するためのハードルもコストも低い点が魅力的に感じました。

チャンスがあれば、ぜひプロジェクトに導入したいと思います。



参考書籍

  • 『今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント』(著 : Eric Brechner 翻訳 : 長沢 智治,クイープ)
Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です