「カンバン仕事術」を読んだ。
https://www.amazon.co.jp/exec/obidos/ASIN/487311764X/mersys-22/ref=nosim

WIPとリードタイムの話はなるほど、とは思った。
継続的なプロダクト開発とかだとフィットしやすいんだろうなぁと言う気がしつつ。
複数の受託案件のようなプロジェクトが並行して動いていて、メンバーアサインも複数プロジェクトにまたがる場合どうするのがいいのか悩ましいところだなぁ、と。

プロジェクト単位のボードがありつつ？ユーザー単位のボードがあり、全社ボードがある感じになるのがいいのか？
プロジェクトによっては分類の方法もかわるだろうから、そういうわけにもいかないだろうしなぁ。

いろんな案件に携わっていて、日々Backlogのチケットをあちこち返しているのは、コインを次の人に1つずつまわすような作業になっているんだろうか？？

サービスクラス＝プロジェクト？、という風に考えられなくもないけど、クラス＝優先度的な発想、というかんじで、緊急とかがあるんだろうな。
緊急、確定納期、欠陥、無形、通常項目、が例としては出ていたけど。
backlogでいうところだとタスクの種別みたいなものか？

リモートでコアタイム的なものがない場合、振り返りをどのように行うか？スタンドアップをどのように行うか？
振り返りの準備を継続して用意しておきつつ、適当なタイミングで行えるか？

予定通りにすすめられない・進まない、のは計画の立て方含めて開発着手前の前提とかスケジュール立てる時点で間違ってるところが大いにありそうな気がしている。
根本的に考え直さないといけないんだろうな。
ツールの使い方どうこうでは解決しなささそうな気がするし、まずは自身の行動を見直さないといけない気がする。

現状はBacklogを使っているがこれにカンバンの見える化的なわかりやすさをどうにか出来ないかは考えてみても良さそう。
あとは、例としてあげられていたようなステップをへるものの場合であれば使い方を工夫すれば調整が出来そうな気もするから何かしら考えてみたい。

リモートだとリアルホワイトボードは難しいからホワイトボードっぽいことが出来るWebサービスを使うか、Trelloみたいなカンバン系のサービスを使うか、とかでも良いのかもしれない。

アサインされてるものを、未着手なのか、着手したのか、一旦ペンディングにしているのかを見えるようにするだけでも少しはかわるだろうし、複数あるチケットについて、担当ごとに優先順位を付けられるだけでも変わるのかもしれない。
各工程におかれるWIPにアサインされた人をアバターでわかるようにする話はあるけど、その人はそれ以外のプロジェクトもあるからどのようにして串刺ししてみれるかが肝になりそうな気もする。

そもそも、複数プロジェクトにまたがらないようにする、というのも手ではあるのかもしれないが。
ツールに使われないようにしつつ、ツールの見直しも含めて、ツールの制約の中で出来ることを模索していきたいところ。

WIPの制限によるリードタイム短縮の話は、成果としては大きいものかと思うので、それに当たるような改善はしていかないとだ。