はじめに
久しぶりの投稿です。この本読みました。
今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント
- 作者: Eric Brechner,長沢智治,クイープ
- 出版社/メーカー: 日経BP社
- 発売日: 2016/06/03
- メディア: 単行本
- この商品を含むブログ (2件) を見る
今どんな仕事してるの?
今はOSS開発にCIを導入する仕事です。今時CI、ビルド自動化やテスト自動化をやってないプロジェクトなんて世の中にあるかわかりませんが、大きい会社ですので、そのあたり専門チームを作ってフォローしていくという体制になっています。
やってる仕事が多岐に渡り、単純な開発をするわけではなく、テストプログラムを書くこともあればトラブル調査をしたり、開発者に以来したり関連部署と調整したり、いろいろあります。その中でタスクが見えづらくなり、まず見える化のためにgitlab issueを使いはじめました。
そしてちょうど隣にissue boardがあったので、実践してみているところです。ベストプラクティスを学ぶためにこの本を買いました。結論、買ってよかった。
第1章 経営陣の同意を得る
もちろん、新しいプラクティスを導入する際には経営陣の同意は必要でしょうね。インターネット上のカンバンボードシステムを使うにしろ、リアルなホワイトボードと付箋を使うにしろ、お金はかかります。
幸い、私の部署では既に社内システムとしてのGitlabを使っていたのでGitlab boardが何の手続きもなく使えるということ、管理職もこういった変化や新技術導入や取り組みに関しては絶対のNoと言わないひとなので、ここの障壁は一切ありませんでした。
ただ本書にとってのこの章のいいところは、経営陣の同意を得る、というていで、読者にカンバン導入時にどれだけ時間がかかって、どんなリスクがあるのか、同時に説明できるところですね、うまいなぁと思いました。
第2章 カンバンのクリックスタートガイド
この章ではカンバンの基本的な使い方を説明してくれます。大事な部分。
手順1 チームの大まかなルーチンを把握する
これはカンバンボードのリスト(フェーズ)を割り出すために、ある程度決まった形をあぶり出しておいたほうが良いということでしょうね。うちのチームは開発チームではなく、仕事はひとと話すことから技術的解決まで幅広くあるので特に定めていません。
手順2 壁の模様替えをする
これはアナログのカンバンボードを作るという章ですね。私がgitlab boardを使ってますが、まぁアナログのほうが動かす感覚があってメンバーが乗り気になるメリットはあるのかもしれません。
手順3 混乱を抑制する
WIPの上限の設定方法について書かれています。この算出方法は普段の仕事が全て同じルーチンであるときにだけ使える方法ですね。手順1でも言った通りうちのチームでの採用は難しい。
手順4 完了を定義する
各タスクの完了基準を定めないと次のステップへ移動できない、当然のことのようにも思えますが、これはうちはできていませんでした。issueの本文に何ができたら完了か、ということを書いておくと良いと思いました。導入します。
手順5 デイリースタンドアップミーティングを行う
これも各フェーズのWIP制限が決まった上での話ですね。カードをいつ誰でも動かしていいのか、デイリースタンドアップミーティングのときだけ動かすのか、迷っています。WIP上限が決まっていれば、空いたときbacklogから必要分を移動させられる点が良いと思いました。
トラブルシューティング
充実した内容でした。フェーズごとに担当が分かれている場合は作業がブロックされることがあるようですね。そのときはその原因となるフェーズを手伝うことが有効とのこと。多分重要なのはいかにタスクを留まらせないか、だと思いました。Doingに動きがない状態が一番まずいというのは体感しています。
第3章 納期を守る
納期を守るために必要なコツが記載されています。MVP(Minimam-Viable Product)最低限顧客に渡すもの、機能を定義したり、完了予定日の追跡、それに付随するパラメータの計測。
- TCR(Task Comletion Rate) / タスク達成率。毎日どれだけ達成しているか、もしくはタスクが移動しているか
- CTE(Current Task Estimate)/ 現在のタスクの見積もり。
- TAR(Task Add Rate) / タスク追加率。月初のタスク総数を月末のタスク総数から引けばどれだけ追加されたかがわかりますね。
これらをgitlab issueで簡単に取得できたらいいんですが。issueをopenした日とcloseした日がわかればいけるか。rssだとupdateした日しか取れないんですよね。。。
4章〜7章 組織ごとのカンバン導入方法
ウォーターフォール開発、スクラム、アプリケーションのデプロイメント、大規模組織、サステインドエンジニアリング(サービス継続のための欠陥対処)といったシーン、業務の種類に応じてどうカンバンを適用できるかを個別に紹介しています。徹底した現場目線がすごい。
9章 さらなる方策とカンバンを超えて
この章はカンバンがなぜうまくいくのか、その理論的解説をしています。この章めっちゃ大事ですね。
見える化はもちろんのこと、カンバンフローを運用すると自然のタスクには「完了条件」が決められます。そしてWIP制限によって、そのときそのときに最も必要なタスクが順にとられるので、最小限の作業をするようになります。
特にリーン開発の「7つの無駄」をどれも効果的に解決することに気づきます。個人的には「手持ちのムダ」が適切なスイムレーン設定によってなくなること、チケット化+チャットでの通知によって「伝搬のムダ」が大きいと感じています
おわりに
実際に導入してみて、この本を読んで、毎週使い方を改善していっています。ほぼどんなプロジェクトにも適用できるのではないでしょうか。
本書にあるプラクティスを全部実践する必要はないですが、今うちが実践してるルールはこんなところ。
- WIP制限(Doingのところだけ制限をかけています )
- レーンを一方通行にすること
- うちはBacklog→TODO→Doing→Review→Doneにしています
- 完了条件を明記すること
- レーンを一方通行にするためには「Review」が一度くるとそのissueは終わるようにしなければなりません。
- つまり「機能Aの開発」だとして、作業見積もり、コード作成、テスト実行のそれぞれにReviewが入るなら、その単位にissueは分割されます
- TODO〜Review間は個人が自由に動かして良い。
- Doneに移動するとき、BacklogからTODOへはデイリースタンドアップミーティングで実施
- 最初と最後は優先度つけもしくは完了したかの共有のためにメンバー全員の前で実施するようにしています。
自然とタスク粒度が決まってくること、WIP制限によって今やってる仕事と残りの仕事が明になること、フローが流れることで今何に詰まっているのかがわかるようになること。自分でやれるところまでやったらすぐにReviewにすることで待ちのムダがなくなることに効果を感じています。
Gitlab issueに特化した記事をそのうち書こうと思います。物理でもソフトウェアでも、カンバンボードはあらゆるタスク管理に使えると思います!おすすめ!