【引継ぎ】タスクへの考え

　『トラックナンバー』について以前書きました。
そのトラックナンバーを意識して取り入れたプロジェクトの効果に『引継ぎタスクをスムーズにできた』というのがあります。

ほとんどのプロジェクトでは、後工程になるにつれてメンバーが減っていったりします。
また新規開発プロジェクトでは、その後の追加開発/保守開発プロジェクトを当時のプロジェクトリーダーは抜けて、その下のサブリーダーが担当することもあります。

そんな時に(引き継ぐ側と引き継がれる側双方の)「引継ぎ」タスクが発生します。

この「引継ぎ」タスク…プロジェクトの進捗に関わる成果物を生み出さないので見落としがちですが、やっかいなタスクです。
油断するとプロジェクトで構築したシステムのライフサイクルにも大きな影響が出るものだと思います。
　

1：引き継ぎ時期

プロジェクト終盤、もしくは終了後すぐに…というパターンが多いと思います。
(順調なら)この時期は忙しくないのですが、(残念ながら)バタバタしていることが多いと思います。
そんな状態では、引き継ぐ/引き継がれる双方とも十分な時間が取れません。

また終了後すぐのパターンでは、引き継ぐ側は(往々にして)新しいプロジェクトに参画していて(そして忙しい)、同じく時間が十分に取れません。

引き継ぐ側は(悪い言い方をすれば、自分が抜けた後はそのプロジェクトの当事者でないと思っているからか)、「苦労をするのは自分でない」とばかりにけっこう適当にやってしまいがちな気がします。

引き継がれる側も「(なんかあったら)後で聞けばいいわ」と思ってしまうのか、浅いレベルの理解で済ませてしまいがちです。

上記の理由などにより、システムの設計思想やその仕様に至った過程などの(保守開発などでポイントで重要になる)情報が不十分になったりします。

一方、トラックナンバーを意識してプロジェクトを進めると、そもそも『引継ぎ』タスクがほとんど無く、また引き継がれる側の理解度もトラックナンバーによって高く保たれていると思われます。

どうしても直近のタスクの処理や、納期をクリアすることを優先するのはもちろんですが、『トラックナンバー』など、こういうプロジェクト終了後のことも含めてトータルで考え、マネジメントしていきたいです。
＃『トラックナンバー』と類似の取り組みで『ペアプロミング』もあります。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。