ここはウォーターフォール市、アジャイル町を読んでいます。
トラブルプロジェクトでレスキューされたこと、トラブルプロジェクトを見過ごせなくて火中の栗を拾ったこと。
正しい仕事が何なのか。あと仕事がどれだけあるのか、何がどれだけ必要なのか。
まず、見える化した。
急ぎのもね、時間をかけていいものを切り分けした。お詫びしながら進めていた。
この時、焦るみんなの気持ちを抑えて、確実に進むようにした。火中の栗を拾ったのは、横のプロジェクトで徹夜続けて同僚がみすごせなかったから、と自分がその前のプロジェクトで同じ経験をしていたから。
体験してわかっていたのは、トラブルプロジェクトはできるかできないか判断しないでパンパンにしてしまうこと。
マルチタスクにして処理時間が長くなってしまうことです。また、あせるため作業者の稼働率は100%になります。
これは、リーンソフトウェア開発に書かれている高速道路に車を詰め込んだパターンです。少しのアクシデントが大きく影響し、リードタイムが長くなるパターンです。
待ち行列の考え方を取り入れれば分かること、
到着の平準化、サービス時間の平準化、稼働率の低下なのです。
すべての仕事を見える化して、バラバラにして小さくする。優先順位を決める。確実に進んでいることを朝夕に確認する。
そして最後に帰る時間を徐々に早くしていく。これをコマンドコントロールしながらできるようにして、徐々に自分達で運営できるようにします。
そうなんです、この方法はアジャイルかアジャイルでないかは関係ないのです。
そして、この状況はマネジメントを間違えれば何時でも起きるのです。
だからこそ、忘れてはいけないのです。
バッチ処理は短くしないといけない、優先順位を決める、稼働率をあげない、ということなんです。