-0b10日後に最終出社を迎える@ohbaryeです。
最終出社を迎えるにあたって後任の任命や業務の引き継ぎといった退職・離職までの一連の流れを経験したわけですが、なにぶん人生でそうそうあることではないのでしばらくは暗中模索の様相を呈しました。人生において数度あるとはいえ慣れるほど数をこなすわけでもなく、同じ会社ですでに退職を経験された方々、あってほしい"先達"はすでになく。
会社としての事務手続きは整備されていても、どのような振る舞いがより効率的であるのか、退職後も良い信頼関係を築けるのかといった点についてはさほど多く語られていないと気付きました。
この記事では退職・離職までの一連の流れを"オフボーディング"と呼称し、退職が決まってからの効果的な過ごし方を目指してやってきたことについて記述します。
ありふれたビジネスマナー記事にならないように留意したつもりです。
対象読者
- 退職する人
- 同僚に退職される人
- 人事
本質に言及すると「退職に際して良好な関係を築くことを目的とする人」が想定読者です。
この目的がなければオフボーディングを効果的に行う価値は薄く、本記事で語られることもあまり役に立たないと思います。しかし良い関係を継続することで得られる効用があります。
退職時に良好な関係性を築くことが必要な理由については以下の記事に詳しいのでご参照ください。主に企業向けの内容ではありますが参考になります。
前提
前提として「どれぐらいのタイムスパンでやったことなのか」が気になる方もいると思うので以下の情報を記しておきます。
- 退職広報: 2020-01-22 (水)
- 最終出社: 2020-03-31 (火)
本記事では広報から最終出社までのおおよそ2ヶ月の間の取り組みについて書いています。
やったこと
まとまりがなくて恐縮ですが効果的なオフボーディングを目指してやったことを記載していきます。
定番。業務の引き継ぎ・ドキュメンテーション
ここは言われずともやる事柄かもしれません。
個別詳細な内容は会社や担当業務によって全く変わってくるのでここでは割愛します。
1つ言えるのは、「自分がボトルネック・SPOFにならない」「ドキュメンテーションはエンジニアの職分」ということを普段から心がけておけ、ぐらいです。2つ言った。
後任を決める
自身が担当している業務を洗い出して後任を決定します。メンバー間で調整出来ることもあると思いますが、業務負荷の偏りがなるべく生まれないようにマネジャーも巻き込んで決定するとスムーズです。
ohbaryeの場合は自身がマネジャーだったので開発・運用等の業務に加えて後任のマネジャーを決める必要がありました。
ハイパフォーマーだからといって全くの不意打ちでマネジャーにするのはアンチパターンと考えていたので、自分が退職する2ヶ月前には次期マネジャーとして諸々引き継いでもらえないか相談を始めました。今回は引き受けてもらえたから良かったものの断られていたら次善策が必要だったため、もっと余裕を持って始めるべきだったかもしれません。
背中で語る1-on-2
マネジャーとして行なったことといえば、チームメンバーとの1-on-1にゲストとして新任マネジャーに参加してもらうというものがありました。これは私の発案ではなく新任マネジャーが「1-on-1でのohbaryeの振る舞いを見たいので"見"の姿勢で参加したい」と希望してくれたことにより実現しました。
マンマークではなくダブルチームで相対することによって「あなたは特別な存在だ」という圧をメンバーに与える効果もあったかもしれません。
横顔で語る採用活動
過去に本ブログでもご紹介しているように採用活動の型化や知見共有には力を入れています。
- より良い面接を実現するために "Quipper採用面接ガイド" を公開しました - スタディサプリ Product Team Blog
- QuipperのWebエンジニア採用におけるコードテスト - スタディサプリ Product Team Blog
- カジュアル面談への扉 - スタディサプリ Product Team Blog
しかしいくら"型-インタフェース-"を整備しているとはいえ、1-on-1や採用活動のように"密室-プライベート-"で完結してしまう業務における振る舞いは失われやすいと同僚からの指摘で気づきました。
そこで、最近採用活動に加わったメンバーを中心に、ohbaryeと一緒に面接・カジュアル面談に参加してもらうことで技を盗んでもらうことを企図しました。
後任の紹介・挨拶まわり
「あれ、このサービスで問題が起きたとき昔はohbaryeが対応してたな…今は誰なんだろう…」
「@here このサービスのこと知っている人いますか？以前にohbaryeが対応しているのは見たのですが」
みたいなのを見たことがあると思います。
営業だったり、担当する顧客がいたりすると商慣習に合わせた挨拶まわりなども必要そうです*1。弊社のように自社プロダクトを内製しているエンジニアの場合には対外的なアクションが必要なシーンはあまりないと思いますが、社内の関係者に「自分がやっていたこの仕事はこれからこの人がやりますよ」と引き継ぎ先を周知するのはエンジニアでも大事です。
Slack integrationの引き継ぎ
退職前にSlackアカウントを停止すると捗るにあるように、最終出社にそなえてSlackのアカウントを一時的に停止してもらうことで不意のSlack integration 関連の問題を防ぐことができます。
負債解消・改善活動
時間に余裕があるならば、負債解消やコード掃除やちょっとした改善活動をやるのもおすすめです。
こうした活動も引き継ぎに含めることができるかもしれませんが、退職者が認知している重要度・緊急度や思い入れや思想や描く未来まで引き継ぐのは難しいので出来るなら仕上げてしまいたいものです。
卑近な例ですが「自分がむかし書いたイケてないコードを直したい」というissueがあったとき、退職者にとってはいちプログラマの矜持・モチベーションはあるがそれを他人に引き継ぐべきかというと疑問符が付きますよね。
オフボーディングのために限らず、普段からやりたいことリストを作っておくことをおすすめします。急に時間ができたときに思考コストゼロでissueに着手することができます。
コード掃除
上記の改善活動とも近いですが、今回ohbaryeは退職にあたって最後の仕事としてCode cleanup projectをやっていったのでそのことについて一項を割きます。
やった掃除の内容は以下です。
- 未使用のコードを40万行ぐらい消した
- 不必要なモデル*2を109個ぐらい消した (models数は 390 => 281)
- それらのmodelsを利用するアプリケーションコードも消した
結果だけを書くとすごいインパクトですが、これには但し書きが必要なので注釈で背景を補足します。
背景->*3
こうした背景のため、消された莫大な量のコードはアプリケーションをまるごと消したものであったり、modelにしてもデータが1件も存在しないものが中心です。数字のインパクトほど大変ではないですが12営業日ぐらいはこの作業のために費やしました。
同僚 => 退職者へのフィードバック
oNPS
NPS (Net Promoter Score), eNPS (emproyee Net Promoter Score)をもじってoNPS (ohbarye Net Promoter Score)という調査を実施しました。同僚にohbaryeへのフィードバックを求めるものです。
質問項目は以下です。
- 業務上なんらかの形で @ohbarye と関わったことはありますか？（例: 開発、採用活動、エンジニアリングマネジメント、上長だった、部下だった）
- あなたは @ohbarye と働くことをどのくらい友人や知人に薦めると思いますか？（仮に自分に似た価値観の友人や知人がいたとしてお答えください。）
- 上記のスコアをつけた理由を教えてください。
- どうすればそのスコアはもっと改善すると思いますか。
- エンジニアリングマネジャーとして見た時、 @ohbarye の良かった点があれば挙げてください。
- エンジニアリングマネジャーとして見た時、 @ohbarye の良くなかった/改善すべき点があれば挙げてください。
- ソフトウェアエンジニアとして見た時、 @ohbarye の良かった点があれば挙げてください。
- ソフトウェアエンジニアとして見た時、 @ohbarye の良くなかった/改善すべき点があれば挙げてください。
- 戴いた回答の一部または全部を引用し、ブログなどで外部に公開することを許可しますか？（引用する際には内容から個人を特定できないようにします）
- その他、言いたいことがあれば何でも書いてください（例: Xの引き継ぎ頼む、Yをやり残している etc.）
- Your Name. (optional ですが、いただいたフィードバックに対してリアクションしたりフィードバック返しができたりします)
このうちほとんどは必須入力でなく任意入力です。とはいえ項目多くて大変ですよね。回答いただいた同僚には感謝しかありません。
目的とは！？
ある日 私が「退職にあたり引き継ぐことってあんまりないですかね」と、とある1-on-1で尋ねた折、「引き継ぐ業務や知識はなくとも、意識せずに行う振る舞いや言語化されていない思考・行動様式が存在し、それらこそが伝えられていくべきものではないか」という鋭い指摘がありました。
一理、確かに自ら認知できていないことを引き継ぐことはできない。ではそうした形なきものをどのように浮き彫りにできるかと問いかけてみれば、「観測しえた人間に聞くより他ない」。気恥ずかしさを感じつつもこのような形でフィードバックを募ることにした次第です。
結果
2020-04-01 16:52 JST時点で19件、ガッツリ一緒に仕事した方だけでなく、仕事で関わったことがない方や非エンジニアの同僚からもフィードバックをいただきました。
本当に率直な意見を短文または長文で貰いまして、思ってもみなかったところを褒められたりもしましたが、中にはかなり耳が痛い意見もありました。自分ができていないと思ったことを見抜かれていたり。何十回でも繰り返して読みたいのでデスクトップの背景にしています。
頂いたフィードバックの中で後任のエンジニアリングマネジャーに有用そうな部分はサマリして共有しました。
また、回答してくれた同僚全員に対してohbaryeからもお礼とフィードバックを個別に返しました。
退職者 => 同僚・会社へのフィードバック
自省録
やってきたことや結果に関する客観的な事実は後からでも検索可能ですが、個人の主観・感想にはアクセスできずに終わってしまうことがほとんど、という指摘が @ujihisa からありました。
過去にやってきたこと＋その時に考えていたことなどを記しています。詳細は省略しますが以下のような目次で書いています。なお、このテンプレは @chaspy により考案されました。
執筆してみた感想は、「単体でやってきたことや当時の感情の羅列は長々と書けるけれども、一本筋の通った線やストーリーを引いたり一段上の抽象を見出して現在の表象と結びつけるのは難しい」、です。
extra 1-on-1
私はマネジャーとしてチームメンバーと1-on-1を定期的に行なってきましたが、退職直前にそれ以外の同僚からの1-on-1の申し込みがありました。計14名と実施しまして、それぞれ求めているものが違ったり純粋に雑談を楽しみたいだけだったりして面白かったです。
1-on-1を行なってくれた方を以下のような分類を勝手に行いました。全体としてはやはりなんらかの課題意識を持って来られる方が多かったです。
- 今も一緒に仕事している人
- あまり多くなかった
- 文脈が共有できているのでフィードバックもしやすいし議論の速度も早い
- 以前仕事したけど最近疎遠なタイプ
- 割合としてはそこそこ多かった
- 自分が過去に抱いていたその人への評価が固定化されてしまっていることに気付かされた
- 過去と現時点のdiffをとるのが面白い
- 一緒に仕事したことない人
- けっこう多かった
- コラボレーションの余地は十分にあったと気付かされた
- フィードバックを求められることがあったが、思いつきの皮相なフィードバックしかできなかった
中には「今後のQuipperはどうなりますか？」のように占い師的なロールが求められている方もおり、勝手な未来予想をワッ────と喋りました。これもまぁ雑談の範疇ですね。
脱線────私はよくいうのですが1-on-1は必ずしも上司と部下の関係で行うものではないので、もっと普段からもカジュアルに1-on-1を申し込んで見ると良いと思います。残された時間が僕らにはあるから────
#offboarding-ja channel
退職にはどうしてもネガティブなイメージがついて残された民へ不安を与えてしまう。退職時に良好な関係性を築いたり、率直なフィードバックを貰って組織やチームや個人の改善に活かしたいという目的で #offboarding-ja というchannelが @wozaki の手によって爆誕しました。
同channelでは本記事で紹介するようなアクティビティについて語ったりしています。
退職に対する考えや思いや背景は人それぞれあるはずなので必ずしも型化して公開させることが大事ではない、という前提がとても気に入っています。
中には挙げづらい聲の形もあると思いますし、全てを無理やりポジティブに見せるような修辞も不要です。
まとめ・わかったこと
やってきたことを節操なく書き散らしてしまいましたが、オフボーディングを経験してみてわかったことをまとめます。
1. Copy on write式の引き継ぎが大事
同僚の @qsona の表現「Copy on write式引き継ぎ」が言い得て妙だったので引用します。
社内異動だと copy on write 式引き継ぎが可能であるが、退職だとそうも行かないのでなかなか難しい
— qsona (@qsona) 2020年3月30日
これは、「退職者の記憶領域にある情報を、他人が必要なタイミングでコピーするような引き継ぎ」と解釈しています。「必要なものを、必要なだけ、必要なときに」という意味ではJIT (Just in time) と言っても良さそうです。
上述の例では1-on-1や採用活動がこれに当たると思います。いかに文書化（脳内にあるものをdump）したとしても後任が必要なタイミングでないと有効なインプットにはならないことが多いですし、モブワークなどの共同作業を通じて引き継ぐほうが効率的だったりします。また、引き継がれるべきものが定まる・求められるタイミングが最終出社日を超えてしまうこともあります。
「普段からボトルネックになるな」の一言に尽きるかもしれませんが時既に遅しの場合は、なるべく引き継ぎ期間を長くとるか、Copy on writeが発生するように意識して引き継ぐと効果的です。*4
2. 思考・行動様式の引き継ぎも意識する
上述のoNPSの目的とも関連しますが、意識せずに行う振る舞いや言語化されていない思考・行動様式といったものは引き継ぐのが最も難しいものの1つです。
そもそも引き継ぐ必要があるかどうかの判断が難しいと思います。
これについては答えが出ていませんが、退職者自身での判断も難しいので何かを残してほしいと感じた同僚が退職者から引き出すアプローチをかけるのが有効だと思いました。
3. フィードバックを大事にする
同僚からの同僚目線でのフィードバックを貰う機会を退職後に得ることは難しいです。会社目線でも退職後にフィードバックを依頼することは難しいことが多いため、在職中に依頼しておくと良いと思います。*5
私はマネジャーとしてフィードバックを行う機会はそれなりにありましたが貰う機会が少なかったという反省があり、このタイミングでフィードバックをもらえたのは大変ありがたいことでした。
余談ですが、フィードバックって水物なんですよね。適切なタイミングで即座にやらないと意味をなさなくなってしまったり成長機会を逸してしまう。私がオフボーディングにおけるフィードバックを「最後のフィードバックチャンス」と考えるのはそういう特性のためです。
メッセージ
さて、効果的なオフボーディングを目指して長文を書き起こしましたが最後にメッセージめいた私見を述べます。
フィードバックは大事と書いておいてなんですが、残る同僚の皆様におかれましては「退職者の声を真摯に受け止めることは大事だが振り回される必要はない」と考えています。退職理由は人それぞれにも関わらず退職者の意見に引きずられ続けると支離滅裂な組織になってしまうからです。牛裂きの刑みたいなイメージです。
指摘されたことは本当に解決すべき課題なのか。解決すべき課題だとして優先度は高いのか低いのか。それらは残ることを選んだ人々が選び取っていき、残ることを選んだ人々にとっての理想に近づけていくべきです。
最後に、本記事に書かれた内容のうち1つでも参考になれば幸いですが、同社においてにせよどこか別の会社にせよこれから退職される方には上述のことを実践する義務はありません。退職の背景・理由・プロセスは人それぞれなのでご自身の納得の行くオフボーディングを行なっていただければと思いますし、特定のアクティビティを行わないことによって責めを受けることがないように願います。
こんな形の退職もできるQuipperの話をさらに聞いてみたいと思われた方は以下のリンクから是非話を聴きに来てください。でも、そこに私はいません────
*1:ウッ、ビジネスマナー臭が出てきてしまった…こんなはずでは…。
*2:RailsにおけるModel層、ActiveRecordを継承したclassを指します
*3:Quipperでは日本向けプロダクト「スタディサプリ」と海外向けプロダクト「Quipper School」「Quipper Video」を開発・運用しています。これらのプロダクトは同じコードベースを別個の環境にデプロイし、環境変数やデータにより動的に挙動を各国向けに切り替えるという設計でした。
この設計を続けて早4年。得られた恩恵もありましたが、大量のif分岐であったり、お互いをケアしながらプロダクト開発を続けていくのが難しくなってきたこともあり、コードベースの共有をやめるという判断に至りました。各国がより速度を持った開発や独立した意思決定ができるようにするためです。この件については別途記事が書かれるかもしれません。
かくして2020年2月にリポジトリ単位での分離を実行したため、分離後のお互いのリポジトリには自国で提供するサービスにとっては不要なアプリケーションやコードが残されました。
これらを削除するのがohbaryeの最後の仕事でした。
*4:コミットメントシフトのようなアプローチもありますが2020年時点の雇用情勢では実現可能性が常にあるとはいえない
*5:「フィードバックを普段から行なえるカルチャーであるべき」と良いというのは真理ですけど、なかなか気合入れた文章を高頻度で書くのは疲れるものです。