プロジェクトは観察しないと
プロジェクトを観察しないから上手くいかない。進捗も品質も改善も技術的負債も、全部観察しないから。
観察するには、ただぼーっと眺めているだけじゃ観察にならない。観察する前に、どうあって欲しいか、どうなっては困るかを文字か図表にしておく。その上で、プロジェクトを観察する。
どうして観察するか。実現したい結果があるのにそうならずに明後日の方向に進んでしまうから。どうして明後日の方向に進んでしまうのか。それは、明後日の方向に進んでいるのに放置しているから。だいぶ明後日の方向に進んでから見つけるから戻すのが大変になる。
進捗が計画通りに進まない、見積もりどおりにDoneしない。だったら、やり始めるときと違いは何があるかを観察しないといけない。計画通りに無理くりやるという意味ではない。計画通りにいかないということは、計画と実態の何かが違っているということ。何が違うかを把握する。それを見つけて計画を直すのかやり方を直すのかを決める。日々観察していれば、小さな対応で終わる。週次で観察していたら5営業日分の大きさになる。日次の5倍の労力と5営業日＊3倍くらいのコストが掛かる。
品質は出来たものを確かめたくなるのが心情だが、それでは遅い。手遅れ。クリティカルパス上だったら命取り。進捗より短いスパンで観察しなければいけない。観察するのは出来上がった物の出来じゃない。作業プロセスをデザインしたどおりにやって、期待する品質特性を備えているかを観察する。作業と同じサイクルかそれ以下で観察できるような環境づくりをしなければ手戻りのインパクトはその分大きくなる。出来上がってから確かめては出来上がるまでの全部の日数とコスト＊3倍なのは進捗と同じ。当たり前と言えば当たり前。
改善というより『ふりかえり』で考える。プロジェクト完了後のふりかえりはフィードバックする先がない。なにぶん、プロジェクトは終了してしまうのだ。解散するメンバにフィードバックしても分散するから効果もほとんどなくなる。そういうことだ。ふりかえりは何かしら上手くいかないことを直そうという心持ちといいことは広げようという前へ前へという取り組みだ。ふりかえりを上手くいかせたいなら狙いのフィードバックを早く回したい。スプリントなんて言わず、毎週同じ曜日、同じ時間帯でやって改善が機能しているかふりかえりを観察する。
技術的負債も同じ。負債が負債だと思えるほど貯めてから負債だというのは返済不可能になってから騒ぐようなものだ。だから観察する。技術的に人でカバーしない運用を出来ているか。技術的なライフサイクルは。生産性は落ちていないか。そういった観察をする。
もちろん、エンジニアも観察する。ロール、技術レベルを観察する。しんどそうだったらコーヒーでも飲みながら雑談する。どうしたいかを話してもらう。
