このたび、ふと思い立ってカンバンでタスク管理を始めました。
始めてからまだ3日ですが、今までのところを書いておこうと思います。
ぼくは地方の機械メーカーで組み込みソフトウェアエンジニアをやっています。
今は新製品開発プロジェクトの組み込み部門の設計リーダーをしています。
部下は4人です。
なぜカンバンを始めようと思ったか
割り込み業務が多すぎるから
割り込み業務がとても多いです。
毎日のように新しい割り込み業務が入ってきます。
（メカ、電気、その他関連部門から次々ときます）
納期はもちろん「できるだけ早く」です。
ASAP (As soon as possible)です。
いままでRedmineというタスク管理ツールをつかっていたのですが、割り込み業務が発生するたびに各タスクの納期をずらさなきゃいけないのがあまりにも苦痛で、タスク管理が崩壊しつつありました(笑)
そこでカンバンによるタスク管理が頭に浮かんできました。
チームの人数に対して業務が多すぎるから
チームの人数は僕も含めて5人ですが、シンプルに仕事量が多すぎるんですよね・・・。
新製品の開発スパンはおおよそ1年ですが、その間にやらなければいけないことが多すぎる。
通過しなければならないゲートが多すぎる。
無駄なく短納期で正確にこなしていくにはカンバンによる見える化が最適なのではないかと考えました。
今の開発スタイルは何かというと・・・
今の開発スタイルは何か。
答えるとすれば「フリースタイル」です！(笑)
とくにスタイルがないんですよね。
数年前まではいちおうウォーターフォールだと言われていました。
最近では開発プロセスの見直しがあり、「数週間の間に達成することを決めてPDCAを回せ。それを反復しろ」
と言われていたのでいちおうスクラム方式なのかもしれません。
ですが、あまりの割り込み業務の多さと仕事量の多さによってぜんぜん無理です。
その制度は速攻で形骸化しました。
他部門にも見える化したい
過去記事にも書きましたが、カンバンを採用したい理由の一つとして「他部門にも見える化したい」ということがあります。
ぼくの会社ではメカや電気部門に対して組み込み部門の力関係がすこし（けっこう？）弱いみたいです。
- メカや電気部門にデバッグ用のマシンを無断で取られたり
- 無茶な納期で頼みごとをされたり
- メカや電気の設計ミスのしわ寄せがきたり
- 挙句の果てには不具合の責任を追及されたり
といった具合です。
（隣の芝が青く見えているだけなのかもしれませんが）
他部門にも見える化することで、組み込み部門がどれだけ仕事を抱え込んでいるかわかってもらえるかもしれません。
それによって無茶な納期を押しつけられることが少なくなるのでは、と少しだけ期待しています。
また、
- 組み込み部門は何をやっているのかわからない
- 仕事が遅い
- すぐバグを発生させる
というイメージも持たれています（泣）
そのせいか他部門に比べて考課査定の評価が低い気がします・・・。
（気のせいだといいのですが・・・）
カンバンによって何をやっているのかわからせ、仕事がちゃんと進んでいることを見せ、プロセスもしっかりこなしているぞ！とアピールしていきたいです(笑)
過去記事のリンク
他部門への愚痴を書くとついつい長くなってしまいます。
「カンバンを導入したいなあ」という記事は前にも書いたのでよかったら読んでください。
参考にした本
カンバンを導入するにあたり参考にした本は以下の2冊です。
どちらも導入するためにかなり参考になりました。
カンバン仕事術
こちらの本がとくにおすすめです。
とてもわかりやすく、本の序盤がストーリー仕立てになっているので読みやすいです。
また、カンバンをやっていく上での心得やテクニック、ユースケースも豊富に載せてくれているのでそれぞれの職場にあったカンバンを作れるようになる本だと思います。
なぜ表紙は徳川家康なのでしょうか？
今すぐ実践！カンバンによるアジャイルプロジェクトマネジメント
こちらもなかなかためになりました。
カンバンの基本的な方法はもちろん、上層部に導入の許可を求めるためのフォーマットまで用意してくれています。
また、こちらもカンバンをやっていく上でのさまざまなトラブルシューティングを掲載しているので参考になります。
どのように導入したか
事前にちらっと話した
「ところでみんな、タスク管理なんだけどRedmineがあんまりうまくいってないとおもうんだよね。
そこでカンバン方式を取り入れたいなと思って。
カンバン方式って知ってる？」
と切り出したところ、4人中3人は首を横に振っていました。
1人（とてもできる若い子）は
「○○さん（別プロジェクトの人）がデスクの前でやっているやつですよね？」
と言っていました。
ほとんどみんなカンバンというものを知らない状況だったのです。
（ぼくも本でかじった程度ですが）
そこでインターネットの記事を画面共有で見せながらカンバンがどんなものかちょっとだけ説明しました。
そして、ぼくはこう言いました。
「カンバンを導入したい理由は2つあります。
ひとつは、割り込み業務が多すぎてRedmineでは管理しきれないから。
カンバン方式は割り込み業務に対してかなりフィットできる方式です。
これを使って見える化することで、それぞれのタスクをこなしていきやすくなると思うんですよね。」
みんなまだイメージはあんまりわかないようだけど、ある程度は納得してくれたようでした。
Redmineがしっかり機能していないことは、やはりみんなの実感としてあったようです。
「そしてもう一つの理由は、他部門にも見える化したい、ということがあります。
よく他部門から組み込み部門は何をやっているかわからない、と言われるけどカンバンによって見える化してわからせてやりたい」
と続けていったところ、ぼくと年の近いメンバー2人から苦笑とともに同意を得られました。
比較的若いメンバー2人はそんなに実感としてないようで、微妙な表情でした。
ウィークリーMTGの場で概要を説明した
その翌週、ウィークリーMTGの場でカンバンとはどのようなものか、どうやって進めていくのか説明しました。
基本的な流れはこうです。
- バックログ（未着手のタスク）
- 分析（仕様検討、不具合原因分析など）
- 設計（詳細設計、実装、不具合修正など）
- 受け入れ（成果物を確認してgitのmasterブランチにマージするなど）
- テスト（製品のROMとなったものをテストして動作検証するなど）
また、付箋の色によってタスクの種類を分けました。
（カンバンで使用するのは物理的なホワイトボードと付箋とサインペンです）
- 緑：機能作り
- 赤：バグ修正
- 青：その他（ドキュメント作成、リファクタリングなど）
その時に出た質問
Q1
「他部門の事情などによりタスクを途中で中断しないといけない場合がけっこうあるが、そういう時はどうするのか」
A（ぼく）
「中断されたタスクもフローのその場に残す。設計で中断している場合は、そのまま設計のフローに置いておく。ただし、小さい付箋などで中断している理由を記載しておいてください」
Q2
「ほかの業務を差し置いて急いでやらなければいけないタスクが急に発生することが多々ある。緊急用のレーンを作っておいたほうがいいのでは？」
A（ぼく）
「そのとおりですね。カンバンを導入する目的のひとつが緊急の作業を見える化することです。緊急用のレーンを作ります。ただし、レーンに載せていいタスクの数はひとつだけ。また、緊急のタスクが行われているときは、通常の業務が滞っていることを忘れないようにね」
Q3
「各フローの終わりの定義を明確にしたほうがいいのではないか」
A（ぼく）
「そうですね。それぞれの思っている終わりの定義が違っていると位相が合わなくなってしまいます。まずはカンバンによるタスク管理を軌道に乗せることに集中したいですが、慣れてきたらその辺もしっかり定義するようにしましょう」
（※ふつうは分析、設計などのアウトプットは何かという定義は当たり前に存在するのかもしれませんが、うちの会社はそうでもないのです・・・）
その時できあがった最初のカンバンの姿
「じゃあさっそくみんなが今かかえている作業を付箋に書いてみましょう。
書き終わったらその作業がいまどのフローに属するのか考えてはりつけてください」
それでできあがったカンバンがこれです！（字が汚くすみません・・・）
付箋に書かれている内容はぼかしました。
とりあえず、バックログ、分析、設計のタスクのみを入れました。
いちおう各メンバーの作業内容は把握していたつもりですが・・・こうしてみると設計のフローにある作業が多すぎますね。
5人のメンバーで10個ものタスクが設計にあります。
まずはここを減らしていきたい。
さっそく見える化することで実感できることがありました。
カンバンを導入して3日たちました
そしてこれが3日後のカンバンです。
今のところデイリーMTGもやりつつカンバンを更新し続けています。
"設計"の文字の下に（８）という数字を書きました。
「設計に存在するタスクは8個までにしましょう」
という意味です。
カンバン用語ではWIP(Work in progress)制限というそうです。
ますは設計のタスクは常に8個以下になるように努めます。
WIPも今後しっかり導入していきたい
今は設計のみWIPを8としていますが、ほかのフローに関してもWIPを設定して作業のフローがうまく流れるようにしていきたいです。
また、設計も8ではまだ多すぎるので6くらいにしたいです。
チームの変化
見える化されたことでやりやすくなった気がする
何を優先してやるのか明確になった
ある日の定時すぎにメカの設計リーダーからある機能についての追加実装の依頼があり、MTGをやりました。
追加実装はそこそこのボリュームがあり、納期は3日後（もう定時すぎだったので実質2日後）でした。
その作業を担当するメンバーはほかの業務をやっている最中でした。
ですが、カンバンでタスクの状況が見える化できていたので
「今はこれをやっています。ですが、今回の追加実装を優先して進めることは可能です」
というのをカンバンの前で説明してくれました。
カンバンがあるおかげで、今やっているタスクの中断、別のタスクの優先度アップという情報を、意図を間違えることなく簡単に共有できました。
これは管理する側のぼくとしても、作業者からしてもとても安心できることだと思います。
他のメンバーの状況がわかることで協力しやすくなった
デイリーMTGでカンバンの状況を確認したあとに、別途話があるメンバーは集まって
「さっきの件だけど、こういう風にやるといいと思うよ」
とか
「過去のマシンでこういうことがあって・・・」
という情報のやり取りが活発化しました。
チームが生き生きとし始めたように感じます。
いちばん若い子にも成長の兆しが
以下の記事で言及していた、なかなか成長が見られなくて困っていたA君にも成長の兆しが見られました。
A君の作業がひと段落して、次はなにをやろうか？という時に
「設計のタスク数を減らすことが大事ですよね？それでは、このタスク（けっこうボリュームがあるやつ）の今わかっている範囲の不具合を修正したいと思います」
と言いました。
ぼくとしてはその作業をやってもらうことは全然頭になかったのですが、A君が進んで言ってくれたことが嬉しかったですし、言っている内容も正しいなと思いました。
これもカンバンで見える化したことで、A君が全体的な状況をつかめるようになったからかもしれません。
課題
各フローの終わりの定義が明確でない
カンバン導入時の質問でも出ていたことですが、いまのところ各フローの終わりの定義が明確ではありません。
分析であれば、例えば
「要件がすべて整理されていること」
などとしてカンバンに書いておきたいですね。
設計であれば、
「設計書があること、コーディングと単体テストが完了していること」
とか書いておきたいです。
そうなるとドキュメントにアウトプット結果をおこす必要があります。
しかし、プロジェクトの開発速度に遅れをとらないためには、すべてのタスクに対してしっかりしたドキュメントを作っている暇はありません。
なのでメモ程度でもいいので、それを要件定義書や設計書としてもいいかもしれません。
（もちろん複雑な実装に関してはそれなりにしっかりしたドキュメントは必要だと思います）
あとはドキュメントの管理をどのようにするかですね。
これはRedmineに紐づけるのもいいかなと考えています。
Redmineでタスクのスケジュール管理までするのは無理だと思いましたが、ドキュメントを紐づけておくためとしては有用なのではないかと思っています。
割り込みのタスクの扱いが難しい
割り込みのタスクが毎日のように発生します。
ちょっとした割り込みであれば、今のところ優先してささっとやってしまっている作業メンバーが多いです。
それは本来であれば「緊急」レーンという扱いになりますが、どうも今のところあまりそういう認識がないメンバーがいます。
ぼくもちょっとした機能の修正であればささっと片付けてしまいたい衝動に駆られますが、どうなんでしょう？
やは小さい作業であっても緊急扱いでないのなら、いったんバックログ（未着手）のタスクとして格納しておくべきなのか・・・。
これに関してはまだ模索中というところですね。
メンバーで話し合って決めていきたいです。
カンバンはみんなで作るものですからね！
基本的に一人一人が分析～テストまでのフローをやっている
僕の会社の組み込み部門は、基本的に各タスクに対して分析→設計→テストまでを一人の作業者がすべて担当しています。
カンバンを導入した今でも基本的には変わりありません。
しかし、かならずしもそうする必要はないのではないかと、カンバンの本を読みながら思い始めました。
カンバンで見える化することによって、作業の次のフローへの受け渡しも容易になるはずです。
あとは各フローのアウトプットが明確であれば、分析、設計、テストをそれぞれ別の人が受け持ってもいいわけです。
むしろ開発スピードを上げるためにはそのほうがいいのかもしれないと感じています。
これも今後の課題として取り組んでいきたいと思います。
おわりに
まだカンバンは始まったばかりです。
これから有用なものとなっていくか、形骸化してしまうのかはまだわかりません。
カンバンによる見える化で、さまざまな気づきを得られるはずです。
その気づきを見逃さずにプロセスの改善に常につなげられるかが、分かれ道になると思います。
今後もカンバンによる成果を確認していきます。
