こんにちわ、ディレクターのQです。
仕事をしている上で、担当者が異動や退職で変更になり、業務の引き継ぎを行うことはよくあることだと思います。私自身もlivedoor Blogをはじめとして多くのコンテンツをこれまで担当してきましたが、他の担当者から引き継いだコンテンツや業務が多々あります。
中には、前任者からの引き継ぎがないまま担当になっていて、問題が起きた時に慌てて人に聞いたり、ソースコードを読んで調べたりして大変だったこともありました。そこで、引き継ぎ、引き継がれしてきた中で学んだ引き継ぎ術の基本をまとめてみました。
弊社では、社内Wiki(Pukiwiki)やGoogle Docsといった情報共有ツールをよく利用しています。Wikiではコンテンツ毎にディレクトリを作成し、さらにプロジェクトやタスク毎に細分化してページを作成します。
※実際にサーバにディレクトリを作成するわけではなく、Wikiの機能としてページ名に/(スラッシュ)を入れて区切っています。
新しいプロジェクトが立ち上がった時には同時にWikiページも作成して、情報をそこに集約し、プロジェクトの進捗に合わせてWikiも更新していきます。Wikiに載せられない外部資料などがあれば、ファイル共有サーバやGoogle Docsを利用して、そこへのリンクを貼っておきます。

いざ引き継ぎとなった場合には、長々とした引き継ぎ書といったものを書く必要はなく、自分の担当していたプロジェクトをリストアップして、該当するWikiページのリンク集を作るだけでほぼ完了となるのが、理想の引き継ぎドキュメントの形です。
もちろん、こういった形での引き継ぎを行うためには、常日頃から、自分以外の第三者が理解できるような形で業務情報をログとして残していくことが必要です。
社内でも組織の再編成などによって、担当者の異動の多いウェブ業界だと思いますので、このような情報をログとして蓄積していくカルチャーを全社的に作るのは大切ではないでしょうか。
業務を引き継ぐことが決まったら、後任者に実際に作業をしてもらう時間を設けます。通常、異動や退職が決定してから引き継ぎにかけられる時間は最長でも一ヶ月程度だと思いますので、早めに後任者と一緒に作業を行える時間を確保しましょう。
業務によっては週1回や月1回だけのルーチンワークの場合もあると思いますので、事前に引き継ぎ完了までのスケジュールを組んだ方がいいでしょう。また、コーチングする日より余裕をもって引き継ぎ資料を後任者に渡して、熟読しておいてもらうことも大切です。
引き継ぎ資料に充分な情報を残していたとしても、言語化できていなかったノウハウに気づくことがあるので、必ず後任者と顔を合わせてフローを一通りこなすことをおすすめします。また、引き継ぎ中に、より効率的な運用などを後任者が思いつくこともありますので、それについて一緒に考えてあげられる余裕があるとなお理想的です。
以下は、実際にQから引き継ぎを受けたことのある社員の声です。
実際に業務で忙しい日々の中で、引き継ぎのことまで考えるのは難しい状況の場合もありますし、急な異動スケジュールで引き継ぎが発生する場合もあります。ただ、自分が業務を引き継ぐ立場になったときのことまで考えて、あと一つの手間を普段から心がけてみてはどうでしょうか。
NHN Japanでは、記憶よりも記録に残る引継ぎがちゃんと出来るディレクターを募集しています。
■関連記事
サービス開発の名サポート役 Wikiの活用方法
http://blog.livedoor.jp/ld_directors/archives/51209257.html
ディレクターらしくルーティンワークを捌くための5つのステップ
http://blog.livedoor.jp/ld_directors/archives/51768034.html
仕事をしている上で、担当者が異動や退職で変更になり、業務の引き継ぎを行うことはよくあることだと思います。私自身もlivedoor Blogをはじめとして多くのコンテンツをこれまで担当してきましたが、他の担当者から引き継いだコンテンツや業務が多々あります。
中には、前任者からの引き継ぎがないまま担当になっていて、問題が起きた時に慌てて人に聞いたり、ソースコードを読んで調べたりして大変だったこともありました。そこで、引き継ぎ、引き継がれしてきた中で学んだ引き継ぎ術の基本をまとめてみました。
(photo: Businessmen discussing document by Victor1558)
常日頃からの業務のドキュメント化が重要
弊社では、社内Wiki(Pukiwiki)やGoogle Docsといった情報共有ツールをよく利用しています。Wikiではコンテンツ毎にディレクトリを作成し、さらにプロジェクトやタスク毎に細分化してページを作成します。
※実際にサーバにディレクトリを作成するわけではなく、Wikiの機能としてページ名に/(スラッシュ)を入れて区切っています。
Wikiページ例
コンテンツA = コンテンツの概要と各プロジェクトへのリンクなど
コンテンツA/プロジェクト1 = プロジェクトの説明と各タスクへのリンクなど
コンテンツA/プロジェクト1/タスク = タスクの詳細など
新しいプロジェクトが立ち上がった時には同時にWikiページも作成して、情報をそこに集約し、プロジェクトの進捗に合わせてWikiも更新していきます。Wikiに載せられない外部資料などがあれば、ファイル共有サーバやGoogle Docsを利用して、そこへのリンクを貼っておきます。

社内wikiのイメージ
いざ引き継ぎとなった場合には、長々とした引き継ぎ書といったものを書く必要はなく、自分の担当していたプロジェクトをリストアップして、該当するWikiページのリンク集を作るだけでほぼ完了となるのが、理想の引き継ぎドキュメントの形です。
もちろん、こういった形での引き継ぎを行うためには、常日頃から、自分以外の第三者が理解できるような形で業務情報をログとして残していくことが必要です。
社内でも組織の再編成などによって、担当者の異動の多いウェブ業界だと思いますので、このような情報をログとして蓄積していくカルチャーを全社的に作るのは大切ではないでしょうか。
実際にコーチングをする機会ももとう
業務を引き継ぐことが決まったら、後任者に実際に作業をしてもらう時間を設けます。通常、異動や退職が決定してから引き継ぎにかけられる時間は最長でも一ヶ月程度だと思いますので、早めに後任者と一緒に作業を行える時間を確保しましょう。
業務によっては週1回や月1回だけのルーチンワークの場合もあると思いますので、事前に引き継ぎ完了までのスケジュールを組んだ方がいいでしょう。また、コーチングする日より余裕をもって引き継ぎ資料を後任者に渡して、熟読しておいてもらうことも大切です。
引き継ぎ資料に充分な情報を残していたとしても、言語化できていなかったノウハウに気づくことがあるので、必ず後任者と顔を合わせてフローを一通りこなすことをおすすめします。また、引き継ぎ中に、より効率的な運用などを後任者が思いつくこともありますので、それについて一緒に考えてあげられる余裕があるとなお理想的です。
以下は、実際にQから引き継ぎを受けたことのある社員の声です。
・運用ツールの引継ぎの際に、どんな用途で使っているかをまとめた資料と、実際に使用する場面でヒアリングする環境を設けていただき、さらに誰でもツールを利用出来るようにするアドバイスもいただきました。(エンジニア・T)
・引き継ぎ資料に当時の議論の様子や、なぜ今の運用にいたったかの記録が含まれていたので、歴史的な経緯を理解することができました。(ディレクター・I)
実際に業務で忙しい日々の中で、引き継ぎのことまで考えるのは難しい状況の場合もありますし、急な異動スケジュールで引き継ぎが発生する場合もあります。ただ、自分が業務を引き継ぐ立場になったときのことまで考えて、あと一つの手間を普段から心がけてみてはどうでしょうか。
NHN Japanでは、記憶よりも記録に残る引継ぎがちゃんと出来るディレクターを募集しています。
■関連記事
サービス開発の名サポート役 Wikiの活用方法
http://blog.livedoor.jp/ld_directors/archives/51209257.html
ディレクターらしくルーティンワークを捌くための5つのステップ
http://blog.livedoor.jp/ld_directors/archives/51768034.html
コメント