「カンバンによるアジャイルプロジェクトマネジメント」を読みました

「カンバン仕事術」を読みました - @ikikko のはてなブログでも読んでたのですが、カンバンはもっと突き詰めていきたいところなので、他の本で別の視点の意見も取り入れていきたいですね。ということで。

今すぐ実践！　カンバンによるアジャイルプロジェクトマネジメントマイクロソフト関連書

作者: Eric Brechner
出版社/メーカー: 日経BP社
発売日: 2016/07/14
メディア: Kindle版
この商品を含むブログを見る

第1章経営陣の同意を得る

カンバンを導入する際に、経営陣の同意を得やすくするプロセスについて。幸いにも、今の自分はある程度権限を与えられているので、ここにすごく力を費やす必要はないけれども、いつもいつもそういう恵まれたケースばかりじゃないだろうから、頭に入れておこう。

印象に残った項目は、この辺。

2ヶ月の試用期間について了承を得る
- 試用期間、結構長いなと思った反面、これぐらいかかるちゃかかるかな
経験豊富なコーチを招いて初期の質問に答えてもらう / チームに対して、コンサルタントまたはチームの専門家によるカンバンのトレーニングを行う
- 自分たちで試行錯誤する過程ももちろん大事ですが、専門家のアドバイスを聞くことも大事だよね

第2章カンバンのクイックスタートガイド

この章に限った話ではないけど、トラブルシューティングが非常に役に立つ。

問題11：一度に複数の作業項目を担当したがるチームメンバーがいる

ありそう。基本的にはWIP制限をちゃんと守りつつ、どうしてもというときにはその部分だけWIP制限を増やして試してみる、ってのが提案されてました。

あと、ここで触れられてた「1作業項目＋50%のバッファー」つまりWIP制限をメンバーx1.5倍ってのは、スタート地点としてはよさそうだと思いました。1つ待ちが入ってる間にもう1つ進められる人もいるけど、全員が全員そうではなくて、その場合は周りを手伝わないといけなくなるというので、いい塩梅っぽい。

問題12：ツールや自動化を改善する時間が取れない

これもありがち。で、回答として「作業項目が10個あるとしたら、そのうちの1つか2つはインフラストラクチャの改善であるべきです」とのこと。大体1,2割ぐらいを改善の時間ということで、これは目安として考えてたのと一致してました。

第4章ウォーターフォールからの適応

はい、ここも最後のQ&Aから。ウォーターフォールを経験したことがある人からのFAQとあるけど、はじめてカンバンに取り組む人から出てきそうな質問ということで、自分の言葉で説明できるようになっておかないと。特に↓らへんは。

Q 小さいバッチでどのようにしてスピードアップするのか？
A 小さいバッチはいろいろな面で効果的です。（中略）要するに、小さいバッチは無駄な作業や手戻りを大幅に減らし、プロダクトの品質を向上させます。

Q では、なぜこれまで小さいバッチを使用してこなかったのか？
A 小さいバッチを使用するには、作業フローの調整が必要だからです。（中略）分析、実装、検証が同じペースで進むように調整できない場合、その先にあるのは、一括の作業、無駄な作業、バグの大きなバックログ、そして大量の手戻りです。

Q いろいろなアナリストや開発者、テスト担当者がいる中で、どのようにして作業のペースを調整するのか？
A 分析、実装、検証の作業を、それらのペースが同じになるように制限します。（中略）こうした作業の制限はよく「WIP制限」と呼ばれます。

Q 作業を制限したらペースが落ちるのではないか？
A 私たちが制限するのは人ではなく、人が行う作業の種類です。開発者があるフィーチャーでブロックされているとしたら、アナリストがさらにフィーチャーを分析したところで意味がありません。そのような場合、アナリストは開発者のブロックを解除するために働くべきです。

第8章サステインドエンジニアリング

SE：サステインドエンジニアリング。多分カンバンが一番有効で、使いこなせたらよりよくなるんじゃないかと思ってる領域。要するに、運用保守開発で、事前に計画出し切ることが難しい・突発的に起きうるタスクが多い領域ですね。そういやスクラム現場ガイドでも出てきたので、今一度読み返しておこう。

ikikko.hatenablog.com

最初に検討するのは、SE専門チームにするか、コアエンジニアリングチーム（プロダクトのロードマップを進めるチーム）が担当するか、の2択。

	メリット	デメリット
SE専門チーム	コアエンジニアリングチームがロードマップを進めることに専念できる	SEチームのメンバーは、あまり意欲的でないかもしれない
コアエンジニアリングチームが担当	SE業務を根本解決するモチベーションがわく	SE業務によって、チームの作業が頻繁に妨げられる可能性がある

次は、注記から引っ張ってくるけど、この辺ははっとした。極端な話、不具合0になれば不具合分のサポート業務は減らせて、より攻めの業務に時間費やせますよね。もちろん、そこまで目指すかどうかはケースバイケースにはなりますが、頭の片隅に入れておいていい考え。

コアエンジニアリングチームの作業がそこまで遮られる理由に目を向けることが重要となります。たとえば、全体的な品質の問題に対処すれば、サポートリクエストの数を最小限に抑えることが可能かもしれません。

章末のトラブルシューティングからは、この辺かな。

問題1：コアエンジニアリングチームにカスタマーサポートからのエスカレーションが殺到し、対応しきれないほどのバックログが生成されている
問題5：エスカレーションの数が予測できないため、チームの保守計画に支障が生じている

問題1は、何が問題かを見える化してからそれに対応するという、まあ基本ですよね。場合によっちゃ、SEに入る前のプロダクトの品質に問題があるかもしれないので、品質を高める活動が必要になるかもしれない。問題5は、予測不可能だからこそカンバンが有用だよ、けどカンバンで透明性を少しでも高めてスループットやリードタイムなどから予測できるようにしようと。