見出し画像

引継ぎをしないという仕事術

“引継ぎ” この言葉からどんな場面を想像しますか?

  • 配置転換によって新しい部署に異動する、とか

  • 退職者の業務を他の誰かが受け継ぐ、とか

限られた時間の中で自分を含む誰かの持つ業務知識やノウハウを他者へ継承する。一般的にはそんなイメージではないでしょうか。

私は今年の5月頭から8月末まで妻の出産にともない育児休暇を取得しました。計画的な取得ではなく切迫早産による入院、予定より1月早い出産、妻よりも早い子どもの退院日決定などの予想外の事態が発生し、ある日「来週から会社には行けない」状況にいたりました。

さて、残された一週間をどう過ごしたか?

特にいつもと変りなく淡々と過ごし、引継ぎらしい引継ぎは特に行いませんでした。しかし、4か月の間チャットでの些細なやり取りはあったものの、助けを求めて私にかかってきた電話は2本でした(相変わらず相応のトラブルが起きていたにも関わらず)。

仰々しい引継ぎ行為をしなくとも業務知識やノウハウを他者へ継承することは可能なんだと気づきました。本記事は私が日々どのように業務を進め情報をどう取り扱っているのか、経験をもとに書くことにします。

はじめに

ナカミチと申します。広島でシステムエンジニアをするかたわらBacklogのユーザ会であるJBUGの広島支部を運営しております。

そして、この記事は #Backlogアドベントカレンダー2021 by #JBUG の12月1日分の記事として執筆しています。

私の仕事は、業務システムの設計、開発、保守です。育児休暇に入る際にも2年をかけてフルスクラッチで作成したとある会社の基幹システム (会社が業務を行う上で使用するシステム) のメイン担当でした (イメージが湧かない方は止まることが許されないおっきなシステムだと思ってください) 。

システム保守のメンバーは以下です。

  •  私  メイン担当。顧客窓口。全フェーズにかかわる。システムでは主に金回りの部分を担当。

  • 後輩 入社4年目。設計~開発に関わる。システムでは主に画面周りとデータ集計部を担当。

  • 先輩 別拠点にいるマネージャ。要件定義~システム構築を指揮。

結果的には私が急にいなくなっても後輩がいつの間にかとても成長していたため全然大丈夫でした。

羊頭狗肉?🍖

いきなりタイトルに偽りありとなるかもしれません。
確かに私は後輩に対して「よし!俺いなくなるから引継ぎするぞ!」という行為はしてないのですが、日々知識とノウハウの共有は続けておりました。妻の入院以降はもしもの事態を想定して、後輩が触れてこなかったシステムエリアについての教育を積極的に行いました。

いや、めっちゃ引継ぎしてるやん。という声もあるでしょう。
私がこの記事で伝えたいことは、

いきなりやってきた人に1か月で業務内容を引き継ぐことなんてできないし、業務引継ぎという発想自体が幻想である。日ごろから自分がトラックに轢かれてもいいように、分身を作っておけよ!です。


私がいなくなってもいいようにやってきたこと

私がやったことは「後輩が未修得の業務・知識領域への日常的かつ継続的な教育」です。そして、常に以下のことを意識して行動しました。

聞かれたら教える、ではなく、まずは一緒に体験する。

何事でも経験しないとわからないことが山のようにあります。

新しい業務に関わることになった時、

「はい、とりあえず業務関連資料 (読む気を無くす物量) 、わかんないところは聞いて、何でも教えるよ。」

心の著書 けしからん教育 より

ってことないですか?

度し難い教育方法です。資料があるだけまだマシやんと思う人がいるかもしれませんが、断言します。資料があろうとなかろうと学習を人任せにしてはいけません。資料がないのであれば一緒に作ればいいだけの話です。この方法だと被教育者は自身が理解していない領域がどれだけあるのかすら把握できません。聞かれたら教える方法は教育者の怠慢でしかないと考えています。

ではどうしたのか?以下の順序で教育を進めました。

ひとつずつ説明します。

  1. システムの全体像を可視化する。

  2. 後輩の理解しているシステム領域の認識を合わせる。

  3. 理解していない業務はどんな些細な内容でも一緒に行う。

  4. 後輩主体で問題解決に挑戦する。

1.システムの全体像を可視化する。
システムの全体概要図とER図 (データベースの概要を現した図) があったのでまずは一緒に見ました。
どんな仕事でも同じです。起こりうる業務を全て書き出し業務間の関連性があるのであれば図に起こしましょう。

IPAよりシステム間関連図

シンプルな仕事なら仕事を箇条書きにするだけでもいいでしょう。

2.後輩の理解しているシステム領域の認識を合わせる。
一緒にシステムの全体概要図を見ながら理解が足りていない領域の認識を合わせましょう。私たちの場合、後輩は私がほぼ一人で担当していた債権債務の管理や仕訳データの作成といった会計周りの知識がほぼないことがわかりました。

3.理解していない業務はどんな些細な内容でも一緒に行う。
後輩が理解していない会計周りに対して、ぽつぽつと問い合わせや不具合、改善要望があがってきたので一緒に対応しました。私が対応すれば1時間もかからない内容でも基本的に二人体制で対応しました。

お互い別の業務にも携わっており時間が取れないことも多々ありましたが、こんな感じでやってました。

私「問い合わせが来た。この場合どう対応すればいいか想像つく?」--前提認識の確認
後輩「わからない。」--わかるのであれば手空きの方が対応
私「システム概要はxx。確認するための資料はxx。今回の問題はxx。なのでxxといった対応をする。コード修正しよう(できればペアプロ)。修正したコードを一緒に見よう。」--システムの全体像⇒関連性⇒問題点とフォーカス
私「最後に情報の残し方はxx」--BacklogとGit

大体こんな感じ

毎回ここまで詳細にはできないかもしれません。しかし、どんな問い合わせに対して何を考えて、どんな意図で、どんな対応をしたか会話し、Backlogに残すようにしてました。

忙しかろうが簡単なコミュニケーションは5分でできます。
記録しといたから見てね ⇒ 見ていませんでした。とはならないよう気を付けました。

4.後輩主体で問題解決に挑戦する。
3.のステップで対応した内容と関連した事象が発生した場合は後輩主体で動いてもらいます。

対応方法の検討 ⇒ 私に相談 ⇒ 方針の決定 ⇒ 対応 ⇒ 最終確認
という流れで問題解決に挑戦します。

この段階では後輩ひとりに対応を任せません。失敗への配慮もありますが、間違った対応での成功体験の獲得を避けるためです。同様に私が対応する場合も後輩や先輩に対応方針を必ず相談します。相談は狭い視野で行動するを避けるためと情報共有をかねています。

3.4.のステップでは問題の正しい解決方法を体験することを大切にしています。これを繰り返し理解の幅を広げます。一回で理解することは難しいので何度も繰り返します。

私が教育の前に準備すること

ひとりで考えられる土壌を整える。

教育者として重要なのは、被教育者がひとりで考えられるよう情報を整理することだと思います。設計資料、これまで発生した問題、対応の履歴とその思想、顧客とのやり取り。私たちはこれらの情報をBacklogに集約しています。

具体的な方法はこちらの記事に書いております。

業務で発生する問題はたいていの場合複数の解決方法が存在します。その中から、コスト、影響度、対応速度、過去の経緯を踏まえて最善と思われるものを選択する必要があります。端的に言うと過去~現在の情報から行う未来予測です。

選択するために必要なものは情報です。

  • 必要な情報を1カ所に集約すること。

  • 情報の全体図と情報同士の関連性を見えるようにすること。

  • それらに素早くアクセスできるようにすること。

情報が整理され取得することができて初めて被教育者は考えることができます。業務の情報が散り散りになっているうちは正しい教育も引継ぎも困難でしょう。まずはひとりで考えられる土壌を整えることから始めましょう。

私が教育する時に気を付けていること

なぜを伝える。

現在は観測可能です。エンジニアはプログラムコードを読むことで現在の姿を知ることができます (とても観測できないコードがたくさん存在することは承知の上申し上げます) 。また、現在の業務の流れや日々飛び交うメールやチャットから伺い知ることもできますね。過去も同様に情報が整理されていれば知ることができます。コミットログや課題対応の状況、過去のメール等々。

しかし、未来予測つまり問題解決の方法を選択するためには「なぜシステムや業務が現在の形になっているのか」の情報が最重要です。

尊敬する和田卓人さんの言葉を引用します。

システムでも業務でも同じです。

  • なぜその方法をとったのか。

  • なぜ他の方法ではだめなのか。

教育を行う際はこの2点を必ず伝える必要があります。

“なぜ” を理解すると被教育者は解決方法について思考することができます。“なぜ” を知らないと、通り一遍等の対応しかできません。そして、前述したとおり、たいていの問題は「AだからBの方法で対応しよう」といったものではありません。

例を挙げます。


A社ではとある書類を送る際、以下の手順を実施していました。
Excelにて書類作成 ⇒ 印刷 ⇒ 押印 ⇒ スキャン ⇒ メール送信

電子印が存在する中なぜ紙に出力して押印する必要があるのか?そもそも押印自体が必要なのか?を確認したところ「そう教えられたから、そうしている。」との回答が返ってきました。さらに上長に伺うと以下の回答がありました。「以前は社外への書類に対する電子印が禁止されていたから紙に出力していたが、今は電子印でも問題ない。」以降、担当者からは印刷とスキャンの手順は消えました。

担当者はなぜ紙に出力しなければいけないのかを正しく教えられなかったため、直接の原因が解消したにもかかわらず自ら考えることができなかったのです。


私たちはBacklogの課題とGitのコミットログを連携させることで、システムの変遷を透明化しています。変遷を透明化することで、現在に至る ”なぜ” の思想を汲み取れるようになります。透明化についての詳細はこちらに書いております。

“なぜ“ を伝え自分で考える力を育てる。日々気を付けております。

自分がした苦労は他者に経験させない。

最初に問題解決への考え方を伝え、解決方法を見せ、解答を教えるようにしています。その後、類似事例が出た時に初めて主体的に解決行動をとってもらいます。

持っている情報はすべて開示し、苦労したポイントは先に伝えてます。

先人と同様の苦労をしても顧客や社会に対して何の価値も生み出さないと考えているからです。

先述した「ひとりで考えられる土壌を整える。」に通じますが、些細なことだけど知らないだけで躓くケースはたくさんあると思います。

私は自身が苦労して身に着けた知識であろうと惜しげなく分け与えます。
その知識をもとに自分で問題解決ができるようになる過程にその労力はとっておいたらいいのです。できるようになるには時間と本人の努力が必要ですし、知っているだけで解決する問題なんて大したものではないのです。

スケールが大きくなりますが、2021年のトヨタ春闘でこんな会話が出てきます。

今でも、トヨタの中には、「情報を持っている人が偉い」という風潮があり、「情報が共有されず、一部の人だけのものになっている」のが実態だと思います。100年に一度の大変革の時代、「生きるか死ぬか」の闘いをしている中で、この状況は致命的です。TPS(トヨタ生産方式)の考え方に当てはめますと、「必要な人が、必要なときに、必要な情報を得ることができる」ということが大切になると思います。

トヨタ春交渉2021 #4より

技術や情報の獲得において、先人たちが障壁となってはいけないと考えております。顧客や社会をよくするためにも後輩たちには、私を超えていってもらわないといけないですしね。

人は突然いなくなることを忘れない。

人は突然いなくなります。退職、配置転換、出社拒否、事故、例を挙げればきりがないくらいです。自身も例外ではありません。

自身が明日いなくなってもいいように、一緒に働く人に少しずつ持っているものを受け渡しましょう。相手から求められる前に自分から差し出しましょう。求められるのを待っていても、必要に迫られなければ人は現れません。

社内においてたった1人で働いている方は、個人の努力ではどうにもならないかもしれないですが、チームで働けるように呼びかけてみてください。どうしてもいなければ、近い業務をしている人や仲の良い人でもいいかもしれません。

日常的な教育が引き継ぎを無くします。

分身ができると精神的に楽になるし、働き方も変わります。

まとめ

後輩が優秀だっだけじゃない?とか環境が恵まれてるだけなのでは?と言われれば、まあそうかもしれません。ただ、似たような環境に居ながらいつも仕事に追われていたり孤独な想いをしている人を見てきたので、何かの助けになればと日ごろ考えたり実行していることをまとめました。

まとめです。

  • 日常的に教育をすれば突発的な引継ぎはいらなくなる

  • 教育の前に情報を整理して土壌を整える

  • 被教育者と一緒に体験しながら、継承領域を広げる

  • “なぜ” を伝える

この記事が誰かの助けになればとても嬉しく思います。
お付き合いいただきありがとうございました。

最後にBacklogとかJBUGについて

ここからは宣伝とか補足とかです。

BacklogアドベントカレンダーなのにBacklogの影薄っ!って言われそうなのと、用語がわからない人がいると思うので補足します。

Backlog

当記事でのBacklogとはnulab社の提供するSaaS型プロジェクト管理ツールです。経済産業省が採用し業務改善結果を出したことは大きな話題となりました。テレビCMも放送されているらしいですね (私の住む広島では流れてないんじゃないかな) 。

とても使いやすいです。便利です。私はプライベートでも使用しており、妻の入院~出産時にも大活躍しました。

JBUG

Backlogのユーザ団体です。皆でBacklog使い方やよりよい仕事のやり方について集まって話したりしています。Japan Backlog User Group の頭文字をとってJBUGです。ジェイバグと読みます。楽しいです。僭越ながら私は2021年度の代表を務めております。

全国に支部があり継続的に勉強会を行っているので興味がある方は ↑ のリンクからぜひメンバーになってみてください。最近はもっぱらオンラインで勉強会をやっています。楽しいです。Backlog World という全国大会もやったりします。

そして、Backlogアドベントカレンダー2021はまだまだ続きます。ほかの記事もぜひ読んでみてください。きっと素敵な気づきがあるはずです。

では皆さんまたお会いしましょう🕺🕺。

この記事が気に入ったらサポートをしてみませんか?