カンバンを導入するにあたり、大事なことはすべてこの本で学びました。
まだまだ勉強中ではありますがまとめておきたいと思います。
- カンバンに興味があるけどいまいち何をすればいいのかわからない。
- カンバンってどんな効果があるの？
- 導入したいけどどうやって始めればいいのか・・・
という人たちにおすすめです。
どの現場でも共通の課題
この本の第1章はストーリー仕立てになっており、読者の悩みに寄り添うような形になっています。
僕が職場で抱えている悩みにも重なる部分が多々ありました。
ちなみに僕は機械メーカーで組み込みソフトウェアエンジニアをやっています。
部下は4人ほどいて、新製品開発のプロジェクトで設計リーダーをやっています。
この本のストーリー部分で挙げられている課題は以下のとおりです。
- 納期によく遅れる
- 見積もりが不正確なことが多い
- チームは仕事に追われている
- 優先度がよくわからない
- いろいろなところからチームに仕事がくる
- 誰が何をやっているのかよくわからない
カンバンはこの手の課題から逃げることなく向き合い、チームみんなで解決していくための手法です。
仕事を見える化する
隠れている仕事を明らかにする
それぞれのメンバーが抱えている仕事を付箋に書き出して、それをはりつけます。
僕も自分のチームでこれをやったところ、
「え！？みんなこんなに仕事あったの！？」
と、驚くべき量の仕事を各自が抱え込んでいることが明らかになりました。
設計リーダーが思っている以上に、各メンバーが多くの仕事を隠し持っていることがあります。
カンバンによって各メンバーが持っている仕事を誰の目にも明確にしていきます。
こんなことが見えるようになる
誰がその仕事をやっているか
たまに「あれ、この仕事は誰がやってるんだっけ？ちゃんと進んでるのかな」
と不安になるときがありましたが、カンバンを始めてからはまったくその心配がありません。
タスクはホワイトボードに貼られていますし、毎朝デイリーMTGでその状況を確認しているからです。
各作業者も自分の仕事の範囲が明確になってやりやすくなったことでしょう。
自分が何をやっているか
自分が何をやっているかわかるようになる。
「自分が何をやっているかわかるなんて当たり前だろ」
と思うかもしれませんが、人によってはこれもひとつのカンバンの恩恵となりえます。
僕なんかはそうでした。
僕はけっこう複数の仕事をちょっとずつ着手してしまう癖がありましたが、どの仕事もスムーズにいかないとストレスがたまってくるんですよね。
たくさんのことに着手しすぎると効率も悪くなります。
カンバンによってタスクが見える化されたことで、たくさんのタスクに着手することはできなくなりました。
（ほかのメンバーの目があるので・・・）
それによって一つ一つの仕事へのコミットをしっかりせざるを得ないので、結果的に一つ一つの仕事の質が上がったように思います。
僕のようなたくさんの仕事の手を付けてしまう困った癖のある部下がいる場合、その仕事方法の矯正ができます。
どれだけの仕事が行われているか
どれだけの仕事が現在進行しているのかぱっと把握できることはカンバンの大きな利点です。
割り込みの仕事が発生した時など、まっさきにカンバンの状況を確認してスケジュール調整の検討を始めることができます。
メンバーに仕事を振るときも、
「このタスクはいったん後回しにして、この割り込みの仕事をやってください」
と簡単に優先順位の説明をすることができます。
カンバンは情報を周囲に放射する
「放射する」
英語で言うとRadiationですね。
というのがよくわからないかもしれませんが、実際に導入してみると情報が周囲に放射されているのを実感できます。
付箋の情報がそこに貼られていることで、その目の前に人が集まり、それぞれのタスクについて話し合いが行われます。
他部門の人たちもそのカンバンをみていかに組み込み部門が仕事をこなしているかがわかるようになりました。
「仕事量えぐ・・・。10人くらいで回してるならわかるけど、5人くらいだよね・・・？」
と実際に言われました。
いかに自分たちの仕事量が多いかをアピールしてリスペクトを得ることが、少しずつですができています。
ワークフローを作る
僕のチームのワークフローは以下のように分かれています。
ワークフローの分け方は各チームで合うようにアレンジしていくべきです。
その際、みんなで話し合いながらカンバンを作成できるといいですね。
誰かの独りよがりで始めてもなかなかうまくいきません。
Todo
未着手のタスクが並ぶ領域です。
優先度順に並べておきます。
付箋がたくさん並んでいるとげんなりしてきますが、だんだんと終わりが見えてくると元気が出てきます。
全部のタスクは「ToDo」エリアに載せきれないので、別のPCツールでもバックログしてあります。
分析
そのタスクで成し遂げるべきことはなにか、注意すべきことはなにか、といったことを洗い出します。
要件定義、仕様検討といった段階です。
アウトプットとして機能仕様書を作ることもあります。
設計
機能実現のための詳細設計、コーディング、単体テストを実施するフローです。
アウトプットとして詳細設計書、コーディングのgitへのプッシュ、単体テスト結果などを作成することがあります。
受け入れ
本番環境に実装内容を組み入れるフローです。
うちの現場では、gitのmasterブランチにたいして個別の開発ブランチをマージする段階です。
おもに設計リーダーである僕の仕事です。
「受け入れ」だけは「待ち」と「済み」の区画を作りました。
以前は
「もうmasterにマージしていいの？」
といちいち確認していましたが、今では「待ち」に入っていればマージしてほしい、という意思統一ができているので確認の手間が省けます。
テスト
組み込んだ本番環境をROM化して、実際のマシンに書き込んでテストします。
アウトプットとしてテスト項目書を作ります。
人が足りなくて今のところ滞りがちです。
もっとスムーズに流していかないとバグの混入を発見できないのですが、改善の余地ありです。
完了
そのタスクが完了したことを示します。
一定期間が過ぎたら付箋を取り除きます。
付箋の色を区別する
付箋の色は以下のように区別して使っています。
- 緑：機能実装
- 赤：バグ修正
- 青：その他（ドキュメント作成や開発環境の手入れなど）
色分けをすることで視覚的にさらにわかりやすくなります。
ただし色を使いすぎると逆効果かもしれません。
仕事量を制限する
これは非常に大切なことです。
カンバンでは仕事量を制限して着手できるタスクの数をできる限り少なくします。
どうしてそんなことをするのかというと、
特に団体で仕事をする場合、多くのことに着手すればするほど効率が落ちる
からです。
（個人でもそうですが）
この仕事量を制限することは、WIP制限（work in progress）という専門用語で呼ばれています。
仕事量を制限しないとどんどん設計とか分析に仕事が入ってしまい、手を付けられなくなります。
（僕の職場の最初の状況がそうでした）
仕事量を制限すると各人が仕事を始めることではなく、仕事を終わらせることにフォーカスするようになります。
いまでは抱えていい仕事数を制限できたので一つ一つのタスクがスムーズに進みます。
例えば僕の職場では、
「分析」WIP制限4
「設計」WIP制限6などと決めています。
WIP制限は正解はなく、各職場に合うように試行錯誤していくものだと、本に記載されています。
今後も状況に合わせて最適なWIP制限を考えていく必要がありそうです。
カンバンはこのような立ち止まって考える機会を与えてくれるところがすばらしいところです。
これがカンバンによる見える化のチカラというものです。
小さいけど大切なルール
ボールペンではなくサインペンで書く
小さい文字で書いてしまうと人々の理解を妨げ、チームへ参加する感覚も失わせるとのことです。
付箋はカールしないようにはがす
付箋をはがすときに角度をつけてはがすと、付箋がカールしてしまいホワイトボードにくっつきづらくなります。
優しく角度をつけないようにはがしましょう。
チームのみんながけっこう付箋のはがし方を把握していないことにちょっとびっくりしました。
一度剥がれにくくなった付箋には、ずっとハラハラさせられることになります。
おわりに
いかがだったでしょうか。
カンバン仕事術という本は、これからカンバンをチームに導入してみたいという人にとって最適な本だと思います。
今のあなたの状況から、カンバンを始めることができます。
そしてカンバンによってどんどんチームを向上させて生産性を高めていきましょう。
