「カンバン:ソフトウェア開発の変革」の読書メモ

カンバン:　ソフトウェア開発の変革

カンバン手法の目的って何?

• ワークフローの見える化による段階的なカイゼン
• 仕掛り(WIP)制限による労働&成果物の質の向上

アジャイル開発手法のような定義されたフレームワークではなく、チーム毎の状況に応じてプロセスを進化させていく

チーム毎の状況に応じてプロセスを進化させていくことのメリット

• 「できること」から始められるので、導入のハードルが低い
• 最終的に各チーム毎に最適なプロセスになる(現実とフレームワークの乖離による問題が発生しない

アジャイル開発手法のカードウォールとの違い

アジャイル開発でよく「カンバン」と言われているものは、仕掛りの明示的な制限が無く、新しい作業を引き取るルールが無い、ただの「見える化」である

仕掛り(WIP)制限のメリット

• ライフワークバランス向上
• 品質とパフォーマンスコストの向上
• ゆとりを作ることのメリット
  • 自主的なカイゼンが進む
  • 突発的な事象に対応可能になる
  • 問題解決に「群がる」ことが可能になる

最初は仕掛り制限を緩めに設定することで、チームの導入の反発を防ぐことができる

• ただし、仕掛り制限を無しにすると、カイゼンのスピードは大きく落ちると作者は言っている
• 仕掛り制限があることにより、発生する緊張や議論がカイゼンを促進するという持論らしい
  • 実感が無いのでよくわからん…

タスクボードを作る前にやること

• バリューストリーム(開発組織が実行する作業の流れ)を明確にする
• バリューストリームの入力と出力を定義する
• バリューストリームの作業項目を分析する
  • 作業項目の需要に合わせて、作業容量を割り当てる

タスクボードを作ったあとにやること

• タスクボードの前でのデイリースタンドアップMTG
• プロセスの振り返り/分析するための定期的なMTG
  • 上流/下流のチームのメトリクスを報告
• タスクボードのメトリクスを取る
  • メトリクスの目標となる値を決める
    • 平均リードタイム、スループットなど

メトリクスについて

メトリクスの目的

• 作業量の予測が可能になっているか?
• 組織がビジネス面で機敏に動けているか?
• 常にカイゼンが明確にあらわれているか?

結局カイゼンしたかどうかは数値にしないとわからないわけで、メトリクス超大事

メトリクスの方法いろいろ

累積フロー図

• 未処理項目/仕掛り/リリース済の累積数をグラフにする
• 「仕掛り」の部分の面積が一定であるならば順調
  • 自分達のチームの場合「待ち」の数も必要か

リードタイム

• そのタスクが完了するまでに掛かった日数
• 目標を立てて、それから乖離したものを後で確認すると良い

納期パフォーマンス

• 納期がある作業をどれだけ納期までに完了できたか?

スループット

• 特定の期間にデプロイされた項目数
• アジャイルのベロシティに近い

初期品質

• 見落とした欠陥の数

失敗による負荷

• 過去のデリバリー品質の低さが招いた作業項目の数