私は引き継ぎ、得意です!!という方いらっしゃいますでしょうか?
いざ引き継ぎとなると「あれもこれもぜ~んぶやれるようになってもらわないと!!」と、高い負荷がかかり、教える方も教わる方もしんどく「引き継ぎ」自体がツライ業務になったり…そういうこと、ありませんか?
私自身はというと…転職の度に引き継ぎをしたわけですが、ほぼ黒歴史な気がしてあまり思い出したくないというのが本音です…
スムーズなもの、炎上気味なもの、いろんな引き継ぎを見てきて「引き継ぎにも最適なメソッドがあるのではないか?」と今更考えるに至りました。
引き継ぎに悩むあなたへ
そんな時に見つけたオススメ記事がこちら
「優秀なベテラン社員が会社を去るとき、その知識と経験をいかに引き継ぐか」
引き継ぎというのは退職に限らず担当変更でも実施しますが、担当者の退職を想定したこの記事は参考になったので、社内の会議で下記リストを共有しました。
【やるべきこと】
●経験の浅い社員に、熟練者の仕事を直接観察する機会を与える。
●チームメンバーには熟練者から学んだことを記録させる。さらに重要なこととして、新たに学んだスキルや行動を実践させる。
●熟練者を在職中から後任候補者のメンターとなるよう促すために、昇進要件に部下の育成とコーチングを組み込む。
【やってはいけないこと】
●パニックを起こしてはならない。知識継承の範囲とスケジュールを見極め、どんな方法が最善かを考える。
●去りゆく熟練者に長々としたハウツーマニュアルを書かせてはならない。その代わりに、過去に問題をどう解決してきたかをメンバーに話してもらう。
●去りゆく人を裏切り者扱いしてはならない。退職管理の期間中に、その社員に敬意を示す。
そして、今回実践する<引き継ぎ>の概要は下記の通りです。
引継ぎ担当者:テクニカルディレクター<引継ぎ後も担当を継続>、コーダー<退職による担当変更>
新メンバー:基礎的なコーディングができる3名
実際にはこのようなドキュメントの準備をして臨みました。
ドキュメントの種類 | 目的 | 使い方 |
---|---|---|
引き継ぎ進捗表 | 引き継ぎ項目の洗い出しと実践 | 引き継がれた側が実施済みのものについて記載する |
BacklogWiki | CMS投入用のモジュール定義の説明 | CMS投入データのコーディングの際に必要なモジュールの確認に使う |
CMS投入チェックリスト | CMS投入作業のチェックリスト | 投入データに間違いがないか確認する |
ワークフロー表 | 作業手順書 | CMS投入データを作成する前後の業務フローの確認 |
引き継ぎ業務の基本的な流れ
- 案件概要、CMSの仕組みの説明、ワークフローのおおよその流れなどの共有
- CMSの画面を見ながら実際の作業の流れをレクチャー
- 簡単なページを実際に制作(初回はマンツーマン形式)
- 基本の操作・仕組みの理解とワークフロー表での把握を確認
- 難易度やパターン違いを実際に制作(初回はマンツーマン形式)
- 毎日業務終了時に、その日にやった内容を「引き継ぎ進捗表」に記載
- 学んだこと、つまづいたところなどをBacklogに記載して他メンバーと共有し、振り返り
さて…今回の引き継ぎはうまくいったのでしょうか!?
実際に引き継ぎをしたメンバーの声
引き継ぎに関わったメンバーとPMで集まり、引き継ぎの振り返り会を実施しました。
策定された引き継ぎ計画の実施完了率は60%程度
引き継ぎ期間に経験できる案件とそうでないものがあり、レクチャーは受けたものの実践できなかったという業務の積み残しがありました。
案件の有無に左右されない練習課題や環境を用意できたら、もっとトライアンドエラーをすることで成長を促せたかもしれないという課題が見えました。
引き継ぎ進捗表は役立った!
スケジュールと同様に、当初予定していた項目のすべてが埋まったというわけではないのですが、引き継ぎ関係者ではないPMや他ディレクターが引き継ぎの進捗や各メンバーの理解度を把握し、業務アサインをするのにとても役立ちました。
「何がわからないかがわからない」などの最悪の状況は避けることができたのも良いポイントです。
引き継ぎ関係メンバーの席は近くで正解
コミュニケーションは口頭、Backlog、Slack、などいろんな方法がありますが、使い分けはすぐに慣れました。
例えば
- ソースを貼っての正誤を確認するような質問はSlack
- 操作の「ちょっとここで詰まってます」は口頭
- 気づきのメモや周囲に報告しておきたいことはBacklog
といった感じの使い分けになりました。
席が近いことで柔軟に質問・解決しやすく、どのメンバーも心理的に安心して取り組めました。
今回は1名(担当者)→3名(新メンバー)への引き継ぎでしたが、3名の新メンバーがそれぞれ疑問や解決方法をBacklogに投稿したことでコミュニケーションも活発になってアドバイスしあうなども良い点でした。
プロジェクトのwikiにある情報や資料の更新は柔軟に!
メンバー同士で話すことで理解度や知識を把握し、省ける説明は省略し、深く教えるべきことは資料化し…そういった柔軟性が大事だと気づきました。
当初用意がなかったものでも、後から整備して役に立ったという資料がありました。
「大事なのは<なぜ>の共有」
引き継ぎを振り返って、全員一致の意見が「最初は覚えたり作業で手一杯だが、<なぜ、そうなのか>の説明が何より重要だった」ということでした。
良い例:こうすべきだからsubmitを押す
操作の説明だけなら、操作動画を見てもらうなどでも済むのですが、それは「引き継ぎではない」ということがよくわかります。
重要なのは、プロジェクトの新しい担当者が、前任者と「同じ判断」ができることです。
最初に挙げた記事でもこのように書かれています。
極上引き継ぎ術まとめ
①物事、知識の単純化
行為や手順など、なるべく簡単にし、これについてはマニュアルで対応し、引き継ぎ先の理解度にあわせて柔軟に対応。
②考え方の共有
今までにイレギュラーな問題が起きた時にどのように考え、判断し、コミュニケーションをとったか。
つまり「課題の乗り越え方」について実践しながら継承する。
③「できる仲間が増える」は引き継ぎの最大のモチベーション
引き継ぎ時に改善できるフローを発見できたり、引き継ぎをとおして「対応できるメンバー」が増える事はチームで仕事をする上で超大事!
今後もこの記事「優秀なベテラン社員が会社を去るとき、その知識と経験をいかに引き継ぐか」を読み返しながら引き継ぎを更にスマートにしていきたいものです。
この記事を書いたメンバー
ずっとWEB業界でやってきました。そしてビーワークスには中途での入社です。現在は企画制作部という組織の成長をデザインすることに取り組んでいます。