チームを引き継ぐときのフレームワーク

f:id:vekitomo-0:20160318000646j:plain:w200

最近、チームを引き継ぐことが多かったので、そのときのフレームワークを紹介します。

業界・仕事によって違うと思いますが、ここでは私の本業であるシステム開発です。

まずは整理するフレームワークを決める

闇雲に引き継いではいけません。最初にフレームワークを決めましょう。
私の場合ですと、プロジェクトマネジメントのフレームワークであるPMBOKを軸に決めます。 品質、スケジュール、メンバー、体制などです。

そのフレームワークを決めてから引き継ぎや、メンバーへのヒアリングをしましょう。

繰り返しますが、闇雲に突っ込んではいけません。

枠組みを決めておかないと、引き継ぎはただの井戸端会議のようなコミュニケーションになってしまいます。

残作業を確認する

決められたフェーズの中で残っている作業を確認します。 作業が明確になっていればいいですが、引き継ぐということは、いろいろな理由があってのことで、つまりは、残作業を可視化することが重要となります。 これをしておかないと、あとから何かがボンッ!となる可能性があります。そうなってはかなりつらいです。

体制変更をする

これは時と場合に多分によりますが、これまでのチームが上手くいっていない場合は、だいたい体制の再編を行います。 体制変更はいろいろな要素が絡みます。それぞれのメンバーのキャリヤやモチベーションも気にしないといけません。

大胆に変えることもありますが、あえて何も変えないときもあります。

体制がチームのパフォーマンスに与える影響は極めて大きいと思っていますが、失敗したときのマイナス・インパクトも大きいので、体制変更をするときは、ある程度腹をくくらないといけません。