「カンバン仕事術」を読んで

開発プロセスの参考にカンバン仕事術 を読んでのメモ。

「カンバン ソフトウェア開発の変革」を読んで - Lチカ開発ブログ につづいて、スクラム開発で、タイムボックス化されたイテレーションに合わせるユーザーストーリーを一貫して継続する事が困難となってきたため、開発プロセスの変革の参考に本書を読んでみた。

「カンバン:　ソフトウェア開発の変革 」とほぼ同じ内容で、読み比べて追加で気になった箇所をメモ。

第I部 カンバンの学習

1章　チーム「カンバネロス」のはじまり

1.1　イントロダクション
    ▽P7
    チームの課題
    ・納期によく遅れる
    ・見積もりが不正確な事が多い
    ・チームは仕事に追われている
    ・優先度がよくわからない
    ・いろいろなところからチームに仕事が来る
    ・誰が何をやっているのかよくわからない

第II部 カンバンの理解

2章　カンバンの原則

2.1　カンバンの原則
▽P49
・見える化：個々の項目の状態がわかるようにする。ワークフローから改善の可能性を発見できるようにする
・WIP(仕掛り作業)の制限：同時に進める仕事の数に制限を設ける
・流れの管理：ワークフローを常に改善し続ける出発点。この仕事が完了することはない、フローはいつでも改善できる

4章　作業項目

4.1　カードの設計原則
    4.1.1　判断を促す
    ▽P72
    チームが判断を下せるようなカードにする。自分たちの自己組織化を助けるようなもの。

            4.1.2　成果の最適化を支援する
    ▽P72
    カードの設計は、成果のリスク、顧客満足、経済性などについて、チームメンバーが最適化できるように支援するものでなければならない。

4.2　作業項目カード
    4.2.1　作業項目の説明
    ▽P76
    ユーザーストーリー
    作業項目の「何を」「誰のために」「なぜをやるか」を記述したもの。
    よく使われるユーザーストーリーのテンプレートは、
    [役割]として、 [機能]が欲しい。それは[利益]のためだ。
    [利益]のために、[役割]として、[機能]が欲しい。

    ▽P81
    外部の電子システムID
            4.2.5　ブロッカー

     4.3　作業の種類
    ▽P83
    黄色：通常
    緑：メンテナンス、技術
    赤：バグ
    種類が違うことを明確にすれば、何が起きているかを理解しやすくなる。ボードを眺めるだけで、チーム全体の状況を感じられる。

    ・赤(バグ)が多ければ、システムの品質に問題がある。品質向上の活動をすべき
    ・緑(メンテナンス、技術)がまったくなければ、技術負債の返済が十分でない。今後システムの捕手が困難になっていく
    ・黄(機能要求)がなければ、システムに新機能がまったく追加されていない

    4.7　自分の作業項目カードを作る
    ▽P90
    ・作業項目を実行するのに必要な情報は何か？設計ゴールを忘れない
    ・作業項目に直接関わってない人でも毎日見たいと関心を持てるような情報は何か？
    ・他の作業の種類はないか？種類を分けることのメリットは何か？
    ・ブロッカーは必要か？どのようなポリシーで運用すべきか？作業項目がブロックされたら何をすればいいのか？ブロッカーを取り除くのは誰の責任か？

    4.8　まとめ
    ▽P90
    ・説明：この作業が「何」かがわかる
    ・アバターなどのマーカー：「誰」が作業しているのかがわかる
    ・追跡IDや外部システムへの参照：追加情報が「どこ」で手に入るかがわかる
    ・ブロッカー：ブロックされている作業を見つけ、なぜ進捗が「止まっている」かがわかる
    ・作業の種類：作業の「種類」を把握して、必要に応じて優先度を正しく決められる
    ・サイズ：「サイズ」と作業量の差がわかる

5章　仕掛り作業

5.2　WIPが多すぎるときの影響
    5.2.1　コンテキストスイッチ
    ▽P99
    同時に頭の中に入れようとするとするタスクの数だけ、時間と集中力を失うことになる

6章　WIP制限

6.3　ボード全体とチーム全体のアプローチ
    6.3.1　イチ！ニー！
    ▽P114
    大切なのは(全員の作業がブロックされた場合、流れはどのように変わるのか？)WIP制限を決める裏付け。
    チームと現在の状況に最適な数字を探す。

7章　流れの管理

7.1　なぜ流れなのか？
    7.1.2　ソフトウェア開発における7つのムダ
    ▽P129
    ・未完成の作業のムダ
    ・余分な機能のムダ
    ・再学習のムダ
    ・引き継ぎのムダ
    ・遅れのムダ
    ・タスク切り替えのムダ
    ・欠陥のムダ


7.2　作業の流れを促す
    7.2.2　待ち時間を減らす
    ▽P133
    作業項目を小さく、同じようなサイズにする

7.3　デイリースタンドアップ
    7.3.2　デイリースタンドアップに関連するカンバンのプラクティス
    ▽P144
    ・昨日、あなたは何をしたか？
    ・今日、あなたは何をするか？
    ・それを行う際に、障害物となっているものはあるか？

8章　サービスクラス

8.2　サービスクラスとは何か？
▽P170
すべての作業項目が均等な価値や時間制約を持つ必要はない。
そのことをボードやポリシーに明示的に反映したのである。
作業項目の価値、リスク情報、明確なポリシー、さらにはボード上での見える化を作り出すことにより、チームが自己組織化して作業に取り掛かり、ビジネスニーズを満たすことができる。そのためのシンプルで透明性が高いやり方が、作業項目にサービスクラスを割り当てるというもの。

9章　計画づくりと見積り

9.2　作業の見積り：相対的に伝える
    9.1.2　発注点
    ▽P190
    発注点の導入により、残りの作業項目が一定数になったときに、他のステークホルダーから新たな作業をプルできる。

    9.2.1　ストーリーポイント
    ▽P198
    フィボナッチ数列
    見積もる際にフィボナッチ数列がよく使われるのは、数学的なギークさから来ているわけではない。項目が大きくなればなるほど、見積もりの精度が低くなるようにしているのである。
    ある項目が12ポイントなのか13ポイントなのかを議論しているなら、それだけの精度の見積もりを出せるだけの情報もあるし、正確に見積もれるはずだと思い違いしている。

10章　プロセスの改善

10.1　ふりかえり
    10.1.1　ふりかえりとは？
    ▽P220
    チームのふりかえりは定期的に行われる。あまりやらないよりも何度もやるほうが好ましい。通常、チームは1~4週間ごとに数時間程度のふりかえりの時間を確保する。これはチームが仕事の改善のために時間を投資しているということだ。
    1. 場を設定する
    2. データを収集する
    3. アイディアを出す
    4. 何をすべきかを決定する
    5. ふりかえりを終了する

11章　改善のガイドとなるメトリクスの使用

11.1　よく使うメトリクス
    11.1.1　サイクルタイムとリードタイム
    ▽P240
    リードタイムを計測することによって、デリバリーするまでの時間、市場に届けるまでの時間、予測可能性などを改善できる。
    それから、納期を守っているかどうか(目標と考えていた日までに作業が終わっているかどうか)もわかる。リードタイムがわかれば、作業項目のどこに時間がかかっているのかを分析できる。

    サイクルタイム：作業項目がプロセスの一部を通り抜ける時間を計測
    リードタイム：プロセス全体を完了する時間を計測


11.2　強力な2つの見える化
    11.2.1　統計的プロセスコントロール（SPC）
    11.2.2　累積フロー図（CFD）

12章　カンバンの落とし穴

12.3　時には変革が必要
▽P283
カンバンが素晴らしいのは、今いるところから始められる点だ。何も変えることなく、カンバンを使い始めることができる。作業の進め方を見える化して、同時に着手する項目を制限すれだけでいい。
ここからさらに学習して、プロセスを改善して、進化させていくことができる。
・カンバンは進化的なものとして導入できる
・ただし、時には大改造となる変革が必要なこともある
・改善の速度は自分でコントロールできる
・他の手法を使い、それにカンバンの原則を適用することで、改善を推進できる

カンバン仕事術