新しいチームに加わるエンジニアのための "被" オンボーディングガイド v0.1.0

この記事はLAPRAS Advent Calendar 2019の13日目の記事です

自分も最近体験したということもあり、LAPRASのWebAppチームのオンボーディングについて紹介しようと思いましたが、最近自社推しが過ぎる気もしたので視点をオンボーディングを受ける側に移し、「こんな風に立ち回ろう！」というスタンスで書くことにしました。

v0.1.0 ということで走り書きの勢いでそのままお届け致します。

オンボーディングとは

オンボーディングとは、新たにサービスを導入した人や新たに組織に参加した人などに対して早く慣れることができるようにサポートすることです。

この記事の文脈は後者。 注意することやTIPSを書いていきたい。自分にも多少刺さる点もあるが、過去よりも改善はされていると思っているので勇気を持って書くことにする。

いきなり目立った成果を出そうとして消耗しない

まずは危険性を認識する

  • 新しいチームに入ってまず最初に戦わないといけないのは「自分、役に立ってるの？必要なの？」「自分は何者なの？」という不安感
  • どのような人でも、環境が変わればまずは学びのフェーズから始まる（エンジニアで、ある程度システムが大きくなっている場合は特に）
  • チームに入りたての学びのフェーズでは貢献は愚か、自己認識としてはマイナスの存在とも感じてしまう
  • 以前の職場でのパフォーマンスが高かったり、重要なポジションを担っていたりするほどギャップが激しく、精神的負荷が高い
  • 早くその状態を脱出しようとして焦り、目に付くインパクトの大きそうな課題やできそうなことを片っ端からやろうとするが、成果が出ずに自己肯定感が下がって消耗する
  • この過程に耐えられず、（想像上の）他者の認識から身を守ろうとして、他責的な振る舞いになって信頼を失う。これは危ない。
  • 地に足をつけて着実に積み上げていく方が長期的にチームにも貢献できるはず

以下、この危険性に対処するための方法を紹介する

目標とスケジュールを設定して共有する

  • 理想と現状のギャップに対して焦らないようにするためには、目標とスケジュールを決めるのが効果的
  • スケジュールがあれば「まだゴールには遠いけど、オンスケだから今日休める！寝るぞー」と思うことができる
  • この認識をチームと共有することで、自分も今の所大丈夫だと思えるし、周囲にもそう思ってもらえていると安心できる

ちなみにLAPRASでは入社前から以下のような期待値を提示されていた（内容はエンジニア向け、とは少しズレるが参考までに。純えんじにあ職ならばより技術的な貢献ができるような内容が並ぶはずだ）

* 1ヶ月
  * スクラムの開発チームに馴染んで(技術・内部仕様理解以外の点で)普段の業務に障害がなくなること（=普通に仕事がお願いできる状態）
* 3ヶ月 : 
  * 開発チームをまとめ、リードしていくことができる
* 6ヶ月
  * 予測不能（全社的に変化が激しいので、いまは明確にはできない
  • 入社直後に上記目標について改めて合意をし、合わせて必要なサポート（後述）についても認識を合わせる機会があった
  • 一開発者としてだけではなく、チーム全体への貢献を求められるポジション枠で入社していたということもあり、「まずは普通の開発者として一人分の仕事ができるようになることにフォーカス」と思えたことは学習フェーズの不安との戦いに大きく貢献した。（仮に僕が開発サイドオンリーで戦える強者であるならばとにかく開発集中でよいと思うが、残念ながら自分の技術レベルはそのレベルには達していない）
  • このような機会が無い場合はリクエストしよう

進捗を共有して必要であればスケジュールを変更する

達成できない目標は精神衛生上悪影響があり過ぎるし、達成できたと思っているのが自分だけだというのもまた悲しい

フィードバックをもらって現状を正しく認識する

自己認識でうまくいっていると思っていても、他者からはそう見えていないこともある。チームに貢献するという文脈において、このギャップは解消すべきだ。逆に、自分ではダメだと思っていても、他者からはよく見えているところもある。これは本来なら無用な悩みになるので、このギャップも解消すべきだ「●●の目標に対して、自分としてはこの点とこの点はできていると思っている。ここは足りないのでこうしようと思っている。認識はあっていますか？」という質問ができると良い。

ギャップがあれば解消する方法を考える
  • 世の中うまくいかないこともある
  • どうすれば修正できるのか、どのようなサポートが必要なのかを改めて対策を考えたり、助言を求めたりする
  • 目標やスケジュールの達成見込みが絶望的ならば、期待値かスケジュールを調整する

LAPRASでは主に毎週(慣れてきたら隔週)の1on1と、月一の振り返りで上記のような作業を行なった。同じく、このような機会がなければリクエストしよう。

（おまけ）結果

今は入社4ヶ月になるが、概ねギリギリ大丈夫と言えるレベルだと思っている。次のステップに向けて新しい課題に四苦八苦しながら対処しているところでもある。

受ける側の話とはずれるが、先輩社員に「焦って結果出そうとして苦しんで潰れていく人が多いから焦らないで一つずつやっていった方がよいですよ」と言葉をかけてもらったことをすごく覚えている。いくら自分がそのつもりで、目標を共有していたとしても、焦る気持ちはゼロにはならないので、言葉にしてもらえるて死ぬほど楽になったのを覚えている。

現状の仕組みを作り上げたことに対する敬意と感謝を忘れない

改めて言語化しようと思ったらTweetがあった。連投しているので気になる方にはみてもらえると嬉しい。大事なのは「味方感」。本当の意味で味方になることだ。

  • 課題があるのは当たり前、むしろ課題が無いなら自分がいる意味がない。自分は被害者ではない。
  • そもそも自分で今の状態を一から作れるかかんがえる（多分NOだから起業せずに入社したんだろう）
  • まずはそのすごさを認めて敬意を表し、チーム全体を自分にとって善の存在として認識する
  • その意識を忘れなければ細かい表現は気にしなくていいはず
  • 味方として一緒に解決に取り組めば良い

ちなみに受け入れ側として注意したいのは以下のような力学（そしてLAPRASのチームは信じられないくらいこの手のネガな部分が無くて好きだ）

実務上のサポート

エンジニア向けと書いたので、実務についての工夫も書いておく。 先ほど書いた「必要なサポート」の具体的な内容はおもにこちらにリンクする。ガンガンリクエストしていこう。

システムを触る

  • 自分たちが何を作っているのか理解せずに物を作るのはまずい。機会がなければ確実にリクエストしよう。

システム全体像のインプット

  • 最初に全体像を説明をしないところはないと思うが、されなかったらリクエストしよう
  • DB定義、依存ライブラリ/サービス、全体の設計思想、インフラの大まかな構成 などを中心に聞く
  • 一度に理解する必要はない。実務をやりながら理解を深めていくイメージで良い。

ペアプロ

  • コード理解において「（目的もなく）コード読んでおいて」はワークしないので、「とりあえずコード読んでおきます！」という宣言はしない
  • 任せるタスクが無い、余裕が無いのであればとりあえずペアプロをした方が効率が良い
  • 触っている箇所だけではなく、実装の背景など、気になったところは質問してドキュメントに落としきれていない知識を吸収することに務める
  • LAPRASでは最初の2週間の開発タスクは全てペアプロで実施、3週目からは自己申告で「これはソロ狩りしたい」といったものだけソロで対処するスタイルをとった

  • 1ヶ月で開発タスクをこなせるようになる、をクリアすることに大きく貢献した

  • もし現場でペアプロがあまり推奨されていない場合は、せめて対面でのコードレビューを求めよう（コードをみながらの会話は必ず必要だ）

ペアOpsもといペアワーク

  • 現場で実務をこなす際に必要なのはコードを書くことだけでは無い
  • 障害対応や、システム面の質問に答えるための調査をしたり、データ周りの調査などもそれに含まれる
  • これらの作業はやってみないと振られないので、自分からリクエストしにいく
  • とはいえいきなりは任せられないので「自分のやったことのない仕事やるときは声かけてください隣でみさせてください」と宣言する
  • shellの設定や使っている便利ツール、システム運用時に利用しているサービス、などなど、入社後の説明では得られなかった情報を発見することがある
  • 周囲のエンジニアのレベル感もわかる（この点自分は大いに焦りを覚えたのだけど）

自分の関わっていないPullRequestを見る

  • 最初はどうしても自分のタスクだけを追いがちになるが、最低限チームが何をやっているのかは把握したいところ
  • Issueは「これからすること」が書いてあるが、PRはその結果までついているので、初期はPRから見る方が効率が良い
  • 文字通り直近書かれたコードを見ることができるので「昔はこういう書き方をしていたけど今は...」のような事故が防げる
  • レビュー指摘の傾向などからチームの「大事にしているところ」や「雰囲気」も感じ取ることができるはず
  • (スクラムをやっているならば、計画MTGの設計で話していた内容が、どうコードに落としこまれるのかを意識して読むと良い）
  • みてはダメだと言われることはないが、時間をとれないようであればリクエストしてみよう

スプリント計画をちゃんとやるスクラムチームはEasyモード

  • 本筋とは少しずれる
  • もし新たに入るチームがスクラムを採用している場合、事前にスプリント計画の様子を聞くと良い
  • スプリント計画ミーティングにおいて、作るものと設計について詳細に議論して合意しているチームは、当然ながら新しく入った人のキャッチアップも早い

まとめ

  • ざっとみると、チームに入る側としては周囲に労力をかけてもらうようなリクエストが多いように見える
  • とはいえ新しくきた人をワークさせるのに労力がかかるのは当然なのでためらってはいけない
  • ためらって、結果としてパフォーマンスが下がればその方が損失が大きい
  • 多少ずうずうしく、学ぶために周りを巻き込んでいく姿勢が大事
  • 組織としては、その辺に気を配れるかが大事

その他

  • こまかいメンタル的なところなどはキャラ的に敏感ではないので書かなかった

最後に

偉そうに書いたが完全に自分の出来栄えは棚に上げた理想論だと思って読んでほしい。

多少の貢献はできているかもしれないが、まだまだチームの力になるにはどうすれば良いか割と必死だ。気を抜いたらただのお荷物やで自分！という感覚とは普通に戦っている。チームの皆様にはその辺は生暖かく見守りつつ、サポートも頂いているのでそれに救われている。徐々にやれる範囲を広げてきたのもあって抱えているものが増えてきたので、次は仕組みにして手放していき、パフォーマンスをスケールさせたい。

このように全然余裕な雰囲気はない。やっていきしかない。

というわけで、v0.1.0よろしくプロットのような描きっぷりになってしまったが、少しは有益だと思うのでその辺は容赦してほしい。（万が一）リライトしたらTwitterに書くので、とりあえずその時までみんな頑張ろう。