引き継ぎの3日間で、半年が決まる

株式会社Codence代表の西野です。

4月は、現場が一番揺れる月だと思っています。プロジェクトの切れ目、担当の入れ替わり、急に席が空く話。毎年4月になると、どこかの現場で誰かが引き継ぎをしています。

うまく引き継げた現場は、そのあと半年くらい静かに進みます。逆に、引き継ぎが中途半端だった現場は、半年くらいずっと燻ります。「あの仕様、前任者しか知らないんですよね」という言葉を、何度聞いたかわかりません。

私自身、エンジニアとして何度か現場を引き継がれる側になりました。会社を始めてからは、仲間が現場を引き継ぐ姿を近くで見ています。そのたびに、引き継ぎというのは3日間で決まるな、と感じるようになりました。今日はその話を書こうと思います。

「前任者、今日でいなくなるらしい」

一番しんどい引き継ぎは、前任者がほとんどいなくなるパターンです。

以前、私が入った現場では、前任のエンジニアが退職間近で、最終出社日まであと3営業日という状況でした。顧客との打ち合わせ資料は共有フォルダにありましたが、コードのどの部分にビジネスロジックが集中しているか、どの設定値を触ってはいけないか、そういう「空気」はほぼ口頭でしか残っていませんでした。

最初の半日、私はとにかく前任者の後ろに座って、黙って作業を眺めていました。彼がどのファイルを最初に開くか、どのショートカットで検索するか、どのSlackチャンネルをチラ見するか。口頭の引き継ぎ資料より、この「動線」のほうが参考になります。

1日目の夕方に、ようやく質問を始めました。「いつも最初にこのファイル見てますよね、どうしてですか」と。すると、「そこにエラー通知が飛んでくる設定があって、そこだけ見れば今日何が起きたかわかるから」と返ってきました。引き継ぎ資料のどこにも書いていない情報でした。

こういうのは、前任者にとっては当たり前すぎて資料化されません。書くまでもないと本人が思っているからです。でも、引き継がれる側からすると、この「当たり前」が抜けているせいで3ヶ月先の障害対応が遅れたりします。

前任者が持っているのは、知識というより「勘どころ」に近いものだと思っています。どのテーブルの更新が重い、とか、あのAPIは午前中だけ遅い、とか、担当者の○○さんにはメールより電話のほうが早い、とか。言葉にしてしまえば他愛ない情報なのに、自分でぶつかってから気づくと、ずいぶんコストがかかります。3日の間にそれをどれだけ受け取れるかが、半年後の落ち着きにつながる気がしています。

引き継ぎ資料は、たいてい半分しかない

引き継ぎ資料というのは、どこの現場でも似たようなフォーマットで作られています。システム概要、担当業務、関係者一覧、運用スケジュール。それを見れば最低限のことはわかる、という体裁になっています。

ただ、実際の業務はその資料の半分くらいでしか回っていません。残りの半分は、前任者の頭の中にあります。

たとえば「A社とB社の月次報告、B社だけフォーマットが違うので気をつけて」という情報は、たぶん書いていない現場が多いです。あと、「この関数、見た目より重いからループで回すと落ちる」とか、「水曜の午前中は本番リリースが集中するから、別のデプロイは避けた方がいい」とか。

書いていない理由は、前任者が手を抜いたからではありません。書くタイミングがない、というのが近いと思っています。日々の業務で手を動かし続けてきた人が、ある日突然、自分の頭の中を棚卸しして文章化するのは、かなりの重労働です。資料を書くために業務が止まる、ということにもなりかねません。

だからこそ、引き継がれる側が「資料は半分しかない」と最初から思っておくほうが健全だと思います。全部書いてあるはずだ、という前提で入ると、「聞きそびれた」「書いてなかった」と後で愚痴を言うことになります。愚痴を言っても、前任者はもういません。

私は引き継ぎを受けるとき、最初に資料を読むのではなく、前任者の隣に座って業務のリズムを観察する時間を確保してもらうようにしています。資料は読めばわかる。でも、前任者がいなくなった後では、絶対にわからない情報があります。

最初の3日で、聞きたいことを全部聞く

引き継ぎ期間が1ヶ月あったとしても、前任者が集中して答えてくれるのは最初の3日くらいだと思っています。そのあとは、向こうも送別会の準備とか、退職後の予定とか、次の場所のことで頭がいっぱいになっていきます。

だから、最初の3日で聞きたいことを全部聞ききる。これが引き継がれる側のコツです。

質問の仕方にも、少し工夫があります。「このシステム、どうなっていますか」と聞くと、前任者は一番整理されたバージョン、つまり資料に書いてある内容を話してくれます。欲しいのはそこではありません。

私がよく使っているのは「もし私が明日から1人でこの現場を回すとして、一番困りそうなことは何ですか」という聞き方です。こう聞くと、前任者は資料にならない話を探し始めてくれます。「実はあの画面、特定のブラウザだと動作が変で、ユーザーから毎月1件くらいクレームが来るんですよ」みたいな話が出てきます。これが、引き継ぎ資料にない「半分」の中身です。

もうひとつ、「過去に一番焦ったトラブルは何でしたか」という聞き方も有効です。一度やらかした経験の記憶は、人の中に深く残っています。そのトラブルの再発防止策は、たいてい引き継ぎ資料には書かれていません。その事実を知っているだけで、半年後の自分が救われます。

私は新しく現場に入るときに、紙の手帳を一冊持っていきます。ノートでもいいのですが、最初の3日だけは紙のほうが楽です。人の話を聞きながら、その場で図を描いたり、思いついた疑問を端に書き留めたりできるからです。質問を溜めておいて、区切りのいいタイミングでまとめて聞く。前任者も、次々と投げられる断片的な質問より、まとめて聞かれたほうが答えやすいと感じることが多いようです。

それから、「聞き残したと思ったら、深追いしすぎない」ことも大事だと思っています。最初の3日で全部は聞けません。どうしても抜け漏れは出ます。それは諦めて、前任者が去った後も連絡を取れる関係だけは最低限残しておく。「1ヶ月後にどうしてもわからなかったら、1通だけメッセージしてもいいですか」と先に伝えておくと、後々がずいぶん楽になります。

引き継ぐ側にも、たぶん葛藤がある

ここまで引き継がれる側の話ばかり書きましたが、引き継ぐ側にも、似たような大変さがあります。

私も過去に、現場を離れる側になったことがあります。自分がやってきた仕事を、次の人に渡すときの気持ちは、なんとも言えない複雑さがありました。

うまく引き継ぎたいと思う反面、全部渡してしまうことへの抵抗もあります。「この業務は自分がいたから成り立っていた」という感覚が、少しは残っている。それを丸ごと譲るというのは、理屈では当然なのですが、感情としては違和感が混じります。

あと、引き継ぎ資料を書いているうちに、自分がこの半年・1年で蓄積してきたものが、意外と薄かったことに気づく瞬間もあります。毎日それなりに忙しくしていたのに、文章化できるノウハウは数ページ分しかない。これは結構堪えます。

でも、これはきっと多くのエンジニアが通る道だと思っています。業務の8割は言葉にしにくい経験値で回っていて、残りの2割だけがドキュメントに残る。その2割を後任のためにちゃんと整えるのが、引き継ぐ側の最低限の仕事で、残りの8割はどうしても「一緒に過ごす時間」でしか伝えられない。そう割り切ったほうが、気持ちの負担が少し軽くなります。

そうすると、資料を書くのが億劫になります。中途半端な状態で次の人に渡すよりは、口頭でカバーしよう、と思う人もいます。でも口頭は、たいてい聞く側が覚えきれません。

私は、引き継ぐ側に回ったときは、意識的に「資料に書くと自分の価値が目減りする」という感覚を手放すようにしました。逆で、書いたぶんだけ、あとから振り返れる足跡が残る。会社を変えても、職種が変わっても、自分の中には「こういう業務をこう整理した」という経験が残ります。その経験は、次の場所でも必ず使えます。

引き継いだ後、現場を「自分の色」にしていいタイミング

もうひとつ書いておきたいのは、引き継ぎが終わった後の話です。

新しく入ったエンジニアが、前任者のやり方をそのまま守り続けるのか、どこかで自分の色を出していくのか。このバランスも結構難しいところだと思っています。

私の感覚では、最初の1ヶ月は「前任者のやり方をそのまま真似る」くらいでちょうどいいです。なぜかというと、その現場のやり方には、見えない理由があることが多いからです。一見非効率に見える運用にも、過去のトラブルや顧客との約束事が背景にあったりします。いきなり作り替えようとすると、表面的には改善に見えて、裏で新しい問題を生むことがあります。

1ヶ月ほど回してみて、「これはさすがにおかしい」と自分で納得できた部分から、少しずつ変えていく。周りのメンバーにも「ここをこう変えてもいいですか」と声をかけながら進める。そうすると、前任者のやってきた仕事を尊重しつつ、自分が入った意味も出していけます。

逆に、2〜3ヶ月経っても全部を前任者の通りに続けていると、こんどは現場が停滞します。引き継いだ側は「私は出しゃばっちゃいけない」と思い、周りは「新しい人、まだ遠慮してるな」と感じる。この状態が長引くと、せっかくの引き継ぎが機能しません。

このタイミングを見極めるのは経験則の部分が大きいのですが、「自分が入って最初に違和感を持った部分を、1ヶ月経っても違和感を持ち続けているか」を一つの目安にしています。最初の違和感が残っているなら、それは直す価値があることが多い。逆に、最初は変に見えたけど1ヶ月で腑に落ちたことは、たぶん意味があります。

Codenceで、引き継ぎをどう扱っているか

株式会社Codenceは、SES事業を主軸に受託開発の立ち上げを進めている会社です。SESという性質上、メンバーはいろいろな現場に入ります。そして、いつかは現場を離れます。

私たちの中で最近話しているのは、「引き継ぎはプロジェクトの最後の仕事ではなく、最初の週から始まっている」ということです。

現場に入った最初の週に、そのプロジェクトで自分がどんな判断をしたか、メモを残していく。コミットメッセージも、未来の自分や後任に向けて書く。Slackの過去ログに埋もれないように、重要な決定は別のドキュメントに転記しておく。

こうした小さな習慣は、次に引き継ぐタイミングで効いてきます。いざ退場が決まってから慌てて書くのではなく、日々の業務のなかに引き継ぎの素材を少しずつ積んでおく。地味ですが、現場のエンジニアとしての信頼は、こういう積み重ねで作られると思っています。

1月に入社したアブドラマン、4月に入ってくれた呉桐を含め、私たちはまだ数人の小さな会社です。メンバー全員が、いつか別の現場に移るかもしれないし、別の役割を担うかもしれない。そうなったときに「あの人がいなくなったら詰む」という状態を、できるだけ作りたくないと思っています。

それは冷たい話ではなくて、むしろ逆です。一人ひとりが、いつ手放してもちゃんと回るようにしておくこと。その前提があるからこそ、安心して次のチャレンジに向かえる。私たちはそう考えています。

また、SESという業態は「引き継ぎが発生しやすい業態」でもあります。契約期間が切り替わるタイミング、案件の範囲が変わるタイミング、メンバーが増減するタイミング。1年の中で、何度かは引き継ぎ的な動きが起きます。

そのたびに私が社内で話しているのは、「引き継ぎのうまさは、技術力と同じくらい現場で評価される」ということです。要件定義が的確にできることや、バグを素早く潰せることと並んで、「この人に渡されたら安心」「この人から引き継いだら安心」と思ってもらえることは、エンジニアとしての大きな武器になります。

受託開発の立ち上げを進めている中でも、同じことを意識しています。一人のエンジニアが最初から最後まで抱え続けるプロジェクトは、短期的には効率がいいように見えますが、長期的には脆くなります。チームとして引き継げる構造を作ることが、結果としてお客さまにとっての安心にもつながる。そう信じて進めているところです。

最後に

引き継ぎの3日間は、地味です。派手な成果は出ません。新機能を作ったとか、大きな障害を救ったとか、そういう話とは違います。

でも、この3日間をちゃんと過ごしたエンジニアの半年は、明らかに違います。周りの人が「あの人は、引き継いだ直後から落ち着いていた」と感じてくれる。そのあとの仕事が、とてもやりやすくなります。

もし今、4月の現場で引き継ぎの真っただ中にいる方がこれを読んでいたら、ぜひ「今日、前任者に何を聞けるか」を考えてみてください。聞けるのは、たぶんあと数日です。そして逆に、引き継ぐ側の方は「自分が残せる一番の価値は、資料そのものではなく、後任が安心して走り出せる状態を作ること」だと思い出してもらえると、少し気が楽になるかもしれません。

そしてもし、私たちのような小さな会社で、現場のリアルを一緒に整えていく仕事に興味がある方がいたら、一度話しに来てもらえたら嬉しいです。

引き継ぎのうまい人が増えると、現場はもう少し穏やかになります。派手ではない仕事ですが、地味に効いてくる。お客さまから「今回のメンバー交代、いつもより滑らかでしたね」と言ってもらえたときの、あの手応えは忘れられません。

4月は区切りの月だと、昔からよく言われます。私もエンジニア時代、毎年この時期に環境が少し変わるたびに、落ち着かない気持ちになっていました。でも振り返ると、あの3日間をどう過ごしたかが、その後の1年を決めていたな、と思います。

Codenceはまだ小さな会社で、できていないこともたくさんあります。それでも、引き継ぎという地味な営みを大事にしているエンジニアが集まる場所でありたいと思っています。この話に少しでも共感してもらえた方がいたら、ぜひ一度、話をしに来てください。お待ちしています。