この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。
第13回目のテーマは、「かんばん」です。
この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編」の内容を元にしています。
かんばんの誕生
かんばんは、イギリス人のデイヴィッドさんが考え出した開発手法です。
かんばんはその名の通り日本語が元になった開発手法です。もともとはトヨタ生産方式で使われているかんばんがベースなのですが、トヨタのかんばんとこのかんばんは、思想は似ていてもまったく異なる手段です。
かんばんは、開発手法としてのかんばんと、ツールとしてのかんばんがあります。開発手法のかんばんは、XPやスクラムのようなもので、原則が手順書のようになっているのではじめやすく、誰にでも理解しやすくなっています。
ツールとしてのかんばんは、タスクをふせんではりつけたタスクボードをさしています。厳密に言うとタスクボードとかんばんはちょっと違うのですが、このあたりも後ほど解説します。
かんばんに関しては、自分が翻訳した書籍『リーン開発の現場』をベースに解説します。また、翻訳の際に、かんばんの英語版Wikipediaページも日本語に翻訳しました。こちらもかんばんの理解にとても役立つ内容なので、おりまぜて解説します。
かんばんの基本原則
まず、かんばんの基本原則を解説します。
解説と言っても、原則自体が文章になっているので、これまでの開発手法とちがってとてもわかりやすい内容になっています。
原則： 現在、何をしているかを理解することから始める
ひとつめは「現在、何をしているかを理解することから始める」です。
まずは、現状、どういう流れで開発が行われているかを考えます。リーン思考で登場したバリューストリーム（価値の流れ）を意識します。かんばんではこれをワークフローと呼んだりします。
たとえば、大抵の開発現場では、要件を聞く ＞ 設計する ＞ 開発する ＞ テストする ＞ リリースする・・・といったワークフローになっているはずです。こういったバリューストリームを構成する要素をホワイトボードなどに書き出していくとよいでしょう。
そして、洗い出したワークフローをかんばんに反映していきます。
この写真は、実際に私が使っていたかんばんです。マスキングテープによって、タテのレーンにわかれていますが、それぞれのレーンが、要件をきく ＞ 設計する・・・といった構成要素をあらわしています。そこに仕事を表す付箋を貼ることで、仕事がどういう状態なのか、かんばんだとひとめでわかるようになります。
原則： インクリメンタルに進化させ、変化を追求していく
2つ目は「インクリメンタルに進化させ変化を追求していく」です。
さきほど登場したかんばんは、様々な進化を遂げて写真のような形になりました。もともとのかんばんは、上記のようなシンプルなかんばんでした。このかんばんは、TODO、DOING、DONEといったタスクの状態を可視化したものです。おそらく、さまざまな現場でも使われているフォーマットだと思います。
しかし、開発を進めていく上で、この方法ではわかりにくい部分が出てきたので、インクリメンタルに進化させ、変化を追求していきました。
たとえば、Doingひとつをとっても、開発がDoingもあれば、テストがDoingもあります。開発をすすめる上で、この違いがわかりにくくなったのであれば、開発DoingやテストDoingを追加するとよいでしょう。
このように進化を続けた結果、たくさんのレーンのあるかんばんになりました。
これをはじめて見たひとはよく「複雑でわかりにくそう」と感じるみたいですが、開発チームにとって見れば、自分たちの仕事の流れと状況がひと目で分かる仕組みになっています。Wikiにすらまとめる必要はありません。よって、新しいメンバーがはいったときでも、このかんばんを使い、ひととおりタスクを流してもらうだけで、開発の流れの全体像を理解できるようになります。
原則： 現状のプロセス、役割、責務、職位を尊重する
3つ目は「現状のプロセス、役割、責務、職位を尊重する」です。
現状、さまざまなプロセス、役割や責務があるはずです。とくに役割を見てみると、現状の役割分担では、アジャイル開発がうまく進まないケースもありえます。よくあるのが「これは誰が担当するのか？」の議論です。縦割りの工程に慣れているひとにとっては、職能横断型のやりかたは急にはなじめないものです。
かんばんでは、まずは現状を尊重し、そこから少しずつ変化をうながしていきます。
原則： すべての地位でのリーダーシップを求める
最後は「すべての地位でのリーダーシップを求める」です。
いうまでもなく、リーダーシップは重要です。これはチームだけでなく、マネジメント層や経営層まで、はばひろく求められる要素です。
チーム開発ですから「誰かがやってくれる」ではなく、「自分たちがやる」という気持ちを持つのが重要です。
コアプラクティス： 可視化する
最後にかんばんのコアプラクティスを紹介します。コアプラクティスも、やることが順番になっているので、わかりやすいのがかんばんのいいところです。ひとつずつ見ていきましょう。
ひとつめは「可視化する」です。原則にもありましたが、ワークフローを中心に可視化し、改善していきます。かんばんのいいところは、見える化に特化したツールなのでわかりやすい点です。
コアプラクティス： WIPを制限する
2つ目は「WIPを制限する」です。
これは、かんばんの特徴的なプラクティスです。WIPは（ウィップ： Work in progress）という意味です。日本語に訳すとすれば、進行中、処理中という意味になります。かんばんでは、同時進行の仕事の個数を制限します。これがWIP制限です。
たとえば、開発中というステータスのWIPを5に設定した場合、チームメンバーは5つの仕事だけを開発中にできます。これがWIP5の意味です。5つが開発中であれば、どれかが次に進まない限り、次の仕事を開発中にはもってこれません。
5人のチームだった場合、WIP5だとすると「ひとりひとつの仕事を担当する」という意味になります。もし、だれかが仕事を終えた場合、開発中の数がひとつへります。そうすると、新しくもうひと仕事を開発中に移動できます。
せっかく同時進行で進められるのに、やれる仕事の数に制限するのは不思議に思うかもしれません。ただ、ひとりで作業することが、効率が良いとは限らない場合もあります。たとえば、誰かに相談したくても、まわりもひとり一つの仕事に集中しています。もし話しかけるならば、誰かの仕事を止めることになります。
かんばんでは、WIP制限によって、流れる仕事の数を調整し、全体最適を考えていきます。このあたりはリーン思考に近い考え方です。
コアプラクティス： 流れを管理する
3つ目は「流れを管理する」です。
WIPで仕事の量をコントロールできたら、その状況を見極めます。たとえば、リリース待ちのエリアにたくさんの仕事が貼り付けてある場合、リリースがボトルネックになっている可能性があります。開発中のWIPを減らすなどして、リリースに仕事がたまらないようにするのもいいかもしれません。
かんばんを活用すれば、どこがどういう状況か？ 開発の流れがよくわかるようになります。
コアプラクティス： 明確なポリシーを作る
4つ目は「明確なポリシーを作る」です。
アジャイル開発でよく言われる「完了の定義」を決めます。たとえば、開発完了という状態がある場合、その状態になるためには何をクリアしなければならないのかを決めます。これを決めることで、チームメンバーはまよいなく仕事の状態を選択できるようになりますし、どうすれば終わるのかが明確になります。
たとえば、開発完了にテストも含めるのであれば、開発は終わったけどテストが終わっていない・・・といった状態に気がつけます。気がつけると、終わらせるための対策も打てます。
連載一覧
第1回：アジャイル開発の過去、現在、未来を知ろう！
第2回：声に出して読みたいアジャイルマニフェスト
第3回：従来型開発とアジャイル開発の違い その１
第4回：従来型開発とアジャイル開発の違い その２
第5回：アジャイル開発のよくある誤解を解いていこう！
第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発
第7回：わかるようでわかりにくいスクラムチームの責任
第8回：スクラムイベントの実践方法
第9回：エクストリーム・プログラミングとその価値
第10回：エクストリーム・プログラミングの原則と基礎プラクティス
第11回：エクストリーム・プログラミングの応用プラクティス
第12回：リーンソフトウェア開発
第13回：ソフトウェア開発における「かんばん」
第14回：さまざまな方法論 − リーンスタートアップ・DevOps
