引き継ぎは過去の負債の可視化である

システム開発のプロジェクトでは工程の進度により知的作業>労働集約型の作業が逆転し、労働集約型の作業ボリュームが増えるため、局面でエンジニアを増減することが当たり前のように行われているのだけれど、よくよく考えてみれば労働集約型の作業なんてないんだよねぇ。型(パターン)でプログラムをいくらでも複製できるかといえばそんなことはできないのだから。なにせ、プログラムなんて一品モノだし。

とは言え、局面での作業ボリュームの増減はプロジェクト期間を縮めれば縮めるほど山の高さは高くなり歪な要員計画になるし、そんな要員計画を計画どおりに回せるのは神業か回っていることにしているだけのどちらかに違いないですよ。

プロジェクトの情報量

 なんて誰も意識しないだろうけれど、プロジェクトを着手する前から情報は生まれていて、プロジェクトが着手されると日々刻々と情報量が蓄積されていく性質を持っているのですが、それはプロジェクト開始時点でプロジェクトオーナが何を実現したいかプロジェクトチームに具体性を持ってオーダできていないからです。もしプロジェクトオーナが実現したい要件なり仕様なりをプロジェクト開始時点でプロジェクトチームに渡すことができればプロジェクトの情報量は開始時点で垂直に立ち上がり、以降は大きな方針転換がなければ微増するだけです。

情報の継承

 プロジェクトの情報量は開始前から時間の経過とともに増殖するのであれば、プロジェクト期間中の要員の増減でプロジェクトの情報量を増減するタイミングでスナップショット的に情報の移転を行いたいと考えたいですが、現実的にはできないのはご承知のとおりです。

幸いにプロジェクトのリポジトリが存在していたとしてもそのリポジトリが最新の状態で維持されていることはまずありえないですし、あったとしてもリポジトリに表現されていること以外の経緯なり判断基準はリポジトリ形式知としては記録されないからが一つの理由。もう一つはそれを記録したエンジニアの裁量で何を記録し、何をエンジニア自身の中に属人的な情報として留めるか依存するからです。

もうひとつ引き継げないこと

 があるんですよ。例えば、エンジニアが増えるときにプロジェクトのリポジトリがあったとしても伝える側のエンジニアの技術力は参画するエンジニアに渡すことができないです。当たり前ですが。

逆にワークロードが減る、つまり人員が工程の進度で減員する場合は各メンバに分散していた技術力が集約されるかと言えばやはり無理があるわけです。ITは極度に分業化が進みすぎたのでここのエンジニアの技術の専門性が違いすぎますし。

引き継ぎ資料を作るのは過去の負債

 よくあるのが引き継ぐから引き継ぎ資料を作ってスキトラしておいてというやつ。これめっちゃ無駄というかそのときになって初めて言語化される業務があるということです。今まで何やっていたんだ、と。

そうなんですよ、本来はプロジェクトの進捗の成果としてリポジトリなりで可視化されておけばよかったものを日常的にやらないから負債として積み上がっていっただけで。

だいたいそういったやっつけの引き継ぎの資料なんて書き手が思いついたことだけしか書かれないんですから当然トラップは仕込まれるわけです。書けといった方が間接的に仕込んでいるのが真相ですが。

 

 

結局、日々リポジトリなりなんなりに情報を突っ込んでおいて、引き継ぎなんて(技術は引き継げないから)無理だし、無駄が多いのでその分、道幅的な立ち上げ、立ち下げの期間をソフトランディングできるようにバッファ期間を確保しておくしかない(=オーバーヘッドが出て生産性なんてパーになる)ということを理解しておきましょうということです。はい。

 

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで