名古屋アジャイル移動図書館「ソフトウェアのかんばん、TPSのカンバン」ブックトーク会

カンバン＝仕掛り作業数の制限されたチーム作業スタイル
イテレーションもタイムボックスもない
優先順位1の要件から片付けていく
流れを作る←流れを重視するのがカンバンの特徴

P201コラム：もしBTSが使えないとしたら
×どうやってバグを管理するか議論する
○BTSの必要のないソフトウェアを作るにはどうしたらいいかチームで考える

常にバグ(数)の監視と追跡をする
イテレーションの時間の10%をバグ修正と品質強化に充てる
バグはすぐ直すのが基本

「TDDにしたら、単体テストバグ数が取れなくなってしまいます。品質報告ができない。どうしたらいいでしょうか？」とか聞かれたりしますが、そもそもなんで単体テストバグ数が要るんですか？からじっくり話しましょう。

表層的な改善やIT化をしてもだめ
「わからん」（大野耐一の口癖）
本当に必要なこと、もの、本質を見抜く、考え抜く

タイミングがよければ価格競争を上回ることができる

作る単位≠売れる単位

自分達の都合、思考停止による在庫はダメ
よりよくするために工夫する、知恵を出す

着手指示の「仕掛けカンバン」と引き取り確認の「引き取りカンバン」は違うし、両方あってはじめてカンバン。よくある失敗事例は、引き取りカンバンだけ導入するというもの。
ソフトウェア開発において、仕掛けカンバンと引き取りカンバンを導入するとするとどのような形になるか。意味や効果はあるか。考えてみたい。