会社でホワイトボードに書き出してはいるものの上手くいってなかったので、いっときAmazonでも在庫切れになったりとい人気っぽいカンバン仕事術を読んでみた。

総論

ってきり、はじめはスクラムとかXPとかアジャイルの手法ゴリゴリかな?と思っていたのだが、むしろ逆で、かなりピュアなカンバンの本だった。
スクラムとかXPとかのアジャイルを現場に持ち込むのはそれなりにパワーいるが、この本のようなカンバンだけなら簡単に導入できる部分がありそう。
カンバンでの見える化からはじめて、いきなりやるには、作法がわからないとか、その作法の裏にあることを理解できてなくて諦めがちなアジャイルの手法にも段々ともっていくというようなこともできるのではないだろうか。

カンバン仕事術だけでは具体的案イメージがつかなかった点も多いのだが、アジャイルコーチの道具箱 – 見える化実例集を合わせて読んだらよりイメージがわいたのでセットでオススメです。

感じている課題の解決にむけて試してみたいなって思う事などあったのでメモ。

うちの現状

  • チーム構成 
    • 開発: 社員+協力会社
    • 運用・サポート: 開発のできる社員・できない社員+シフトで開発支援のアルバイト数名
    • マーケ: 運用・サポート兼任メンバー+営業やデザイン系の部署
  • PJの状態
    • いくつかのチームにまたがるものや、跨がらないものなのど、サイズはかなりバラバラ
    • 開発は比較的PJ単位で動けていて少しスクラムっぽいことも始めている
  • タスクの状態
    • PJ単位で発生しているもの、部署全体で月次や週次で定められたタスク(ルーチン)、運用・サポート中心に顧客からの問い合わせなどに合わえて受動的・突発で動くものなど

こんな現場でチーム横断で情報を共有するためにホワイトボードをおいていたのだが、結構うまくいってなかった。
ちなみに最近、開発は開発だけで別にカンバン的なことを始めている

  • 感じている課題
    • 部署全体のルーチンタスクが特定の人に依存・集中しがち?
    • 出ているタスクの粒度に差が激しい?
    • いつまでも消化されないタスクが積み上がってる?
      • 特に開発がわからないメンバーが出したタスクはおかれたまま消化されない物が多そう
    • 全チームを取りまとめてる部長や開発のリーダーがしょっちゅうボトルネックになる
    • そもそもホワイトボードに張り出しているが普段見てない部分がほとんどな気がする
    • 朝会の時間が守られない、ボードにない内容で時間がすぎていったりするし、同じような報告を別なMTGでもしている
    • ルーチンや他のタスクに追われて本来のしごとができていないという発言が全メンバーから出てくる
    • アルバイトに渡す仕事が当日の朝まできまってないことがある
    • アルバイトが定形作業ばかりでもうすこし開発系の仕事も任せたいがどれくらいできるかわからない

なかなかの課題はたくさんあるのだが、ここらへんについて幾つかヒントがもらえた。

試してみたいなと思った事

追記:以下は、本に書かれている各エッセンスを自分の現場ならこういうことをやってみたいなと思ったもので、本に書かれている内容とは異なりますので、ご了承を。

  • WIP制限
    • これは基本っぽいし人によってのタスクの粒度の差や特定の人への依存、ボトルネックの可視化に一番有効そう。ただいきなり小さな数でやるのは怖いので少し大きめの数字で始めてみようと思う。(人数x2.5くらい)
  • マグネットに名前入れて付箋にはる
    • だれがやってるタスクかということの可視化。カンバン仕事術ではアバターとしてえらく可愛いのがでてたが、アジャイル
  • アルバイト用カンバン+定形タスクと開発タスクで付箋の色わける
    • アルバイトに何を任せているのかやアルバイトに任せたい仕事を可視化しやすくなれば、アルバイトが定形以外の開発タスクにももっと関われるし、何をやるか明確になっていくのではないか?
  • どれだけできたかメトリクスを測る
    • アルバイトもそうだし社員の仕事にしても貼りだすだけになっていて、どれだけできたかを測ることができていなかったので、よけいどれくらいできるのかわからなくなっているのかも。
    • まずはサイズが安定しているルーチンから開始日と終了日を記載していくことにして、アルバイトが中心のルーチンはアルバイトだけでも改善を検討できるようにもっていけるのではないか?
  • 開発ができない社員のタスクを分けてみる
    • 開発できない人が作ったタスクが残りがちなのは、その人だけで終わらないものがあるのに持ち続けているので、他から助けにいけばいいのか可視化されていないのかも。自分でできないものとできるものに分解するようにしていけば、他のメンバーのサポートを受けやすくなるか?
    • 分解はしなくても、そのタスクが終わるまでのフローを書き出したカンバンにすれば自分でできるところできないところがわかりやすくなるかも。
  • 粒度を成果の単位にする作業単位にしすぎない
    • 付箋の粒度がまちまちなので、何かしらアウトプットとして成立する単位という粒度のルールを共通でもったらどうだろうか。
  • 誰になにをしてもらわないとおわれないのか?それは本当か?見直す
    • 部長や開発リーダーがボトルネックになりがちなのはなぜなのか?例えば絶対部長のレビューが必要な仕事のレベルを決めて、それを付箋に書けば実は必要のない仕事まで部長や開発リーダーに念のため〜で回っていないだろうか。
  • PJ以外のタスクの可視化をして優先順位と制限をつける
    • PJで決められているタスク以外のものの優先順位をはっきりさせて週にやっていい量を制限する
    • 優先順位を決めるルールも共有する
  • 朝会の内容を絞る
    • 部署全体の朝会は運用作業と全体で共有しておきたい(他のチームにしらせておかないといけない)事に留める(デイリーシンク・リリースシンク)他にすべてのチームが知っておくべきことはないか?
  • 改善のタスクの仕方
    • ワークフロー上に自分ができる仕事がなければ普段できていない、他がはいってきたらすぐやめれるそういう仕事に着手する

一番大切にしたいと思ったこと

  • ゆとりの無いところに改善はない
  • みんなで決める

試してみたいことはいっぱいでたけど、一人でやるとか、いきなりトップダウンで下ろすのではなくもっとほかのアプローチもないかみんなで決める
そして、まずはそのゆとりを作れるようにするところは、一番上から働きかけていく。

とりあえず、明日からの仕事に向けて自分なりに思ったことをまとめた。
また機会があれば、この結果どうなったかをどこかでまとめてみる。