iconはじめにかんばんプロジェクトについてレクチャーを受けた。学んだことをまとめる。流れをコントロールかんばん作成時のルール「かんばん」に参加しない人を作らない。全員に参加してもらう。progress)制限を設ける。2倍からはじめて、少しづつ減らして行くとよい可能な限り、終わらせることを優先させる。次のものが空いている人は、次のものを取りに行く仕組み。Doingが外的要因により進行できなくなった場合、上から別の付箋を付けてブロック状態を表示する。ブロックされていることを明示させるブロックされてて手が止まっていても、WIP制限に例外を作ったり、制限を緩めたりしない。優先順は、上が高、下が低。Todoだけじゃなく、Doingも基本的にこの順に並べるTodoには直近のタスクだけを作る。全部作ると大変なので、Todoは全部で20個に制限するなどルールを作り、なくなったら足して行くなどするのもよい。振り返りで必ず見直すレーンについて業務に合わせてレーンを作る。緊急レーンを作るケースもあり、その場合はかならず1個までというルールも併せて導入する。かんばんで取得すべきメトリックについて以下の日付を記入することで、それぞれのリードタイムを計測出来る。上記計測することで、デプロイの数がスループットになるスループットを計測することで、リードタイムの平均が取得出来る。ふせんについて色に意味を持たせる。同じ内容で違う色を使わない。一般的なタスクを黄色CSから上がってくるものはピンクブロックはオレンジ改善・リファクタリングタスクは緑など誰もがわかる見出しをつける。詳細はRedmineやJIRAとかで良いフォーマットを決めて書き方の見本を書いて置くと良い。粒度は半日〜1日で終わるくらいが望ましい。タスク単位ではなく、ユーザーストーリーに紐づく形が望ましい。APIだけ作っても、使うフロントがあって初めてユーザに価値を提供出来る。明確に担当者が決まっているのであれば、担当者を書く運用上のルールDoingからTodoへ基本戻さない。完了させることを優先する。次のものが空いている人は次のものを取りに行く。誰でも取りにいけるように、人依存にさせない。ある質問どのくらいの規模に向いているのか?規模は100人超えても使っている所もあるが、人数・規模の制限はない。チームが2つにわかれている場合どうするか?プロダクトで区切るのか。複数のプロダクトをまたいでやるケースがある為、チーム毎の方が良い。急ぎのバグ対応やCS問い合わせのタスクがある場合は?緊急レーンで対応するチームもある。1個だけといった絶対的なルールを作る。アナログとデジタルの共存についてリアルでは「ふせん」、デジタルではJIRAやredmineを使うとなると、2重管理になってしまう。それは仕方がないと割り切る。それぞれの特性を生かして使うアナログの方は状況の把握・見える化と優先順の調整のみ。細かい管理はデジタル(redmineやJIRA)で行う。