チームを引き継ぐときのフレームワーク
最近、チームを引き継ぐことが多かったので、そのときのフレームワークを紹介します。
業界・仕事によって違うと思いますが、ここでは私の本業であるシステム開発です。
まずは整理するフレームワークを決める
闇雲に引き継いではいけません。最初にフレームワークを決めましょう。
私の場合ですと、プロジェクトマネジメントのフレームワークであるPMBOKを軸に決めます。
品質、スケジュール、メンバー、体制などです。
そのフレームワークを決めてから引き継ぎや、メンバーへのヒアリングをしましょう。
繰り返しますが、闇雲に突っ込んではいけません。
枠組みを決めておかないと、引き継ぎはただの井戸端会議のようなコミュニケーションになってしまいます。
残作業を確認する
決められたフェーズの中で残っている作業を確認します。 作業が明確になっていればいいですが、引き継ぐということは、いろいろな理由があってのことで、つまりは、残作業を可視化することが重要となります。 これをしておかないと、あとから何かがボンッ!となる可能性があります。そうなってはかなりつらいです。
体制変更をする
これは時と場合に多分によりますが、これまでのチームが上手くいっていない場合は、だいたい体制の再編を行います。 体制変更はいろいろな要素が絡みます。それぞれのメンバーのキャリヤやモチベーションも気にしないといけません。
大胆に変えることもありますが、あえて何も変えないときもあります。
体制がチームのパフォーマンスに与える影響は極めて大きいと思っていますが、失敗したときのマイナス・インパクトも大きいので、体制変更をするときは、ある程度腹をくくらないといけません。