はじめに

本記事は私が自社QAとして入社して2ヶ月で行った自分オンボーディングの工夫について記載します。
４月になりオンボーディングされる方が多いと思うので書いてみます。
オンボーディングは受け入れ側が実施すべきだと思われがちですが、実際はオンボーディングを受ける側についても少しの配慮と工夫が必要になります。
これはフルリモートの例なので、出社される場合は別の方法があると思います。
また本記事の事例はn=1の事例であり、また今回の成功事例もチームのメンバー、会社の文化、タイミング、運に恵まれたためであることを前提でお読みください。

とにかく1 on 1 をしよう

思いつく限り、1 on 1は積極的に行いました。
狙いとしては、その人との固有の関係性を築くこと、自分の存在を売り込むことです。

1.その人との固有の関係性を築く

ここで重要なのはPMや開発者など、役割に紐づいた人を認識するのではなく、人格のある一個人として認識していますよ、というポーズを示し、その人とのチーム内で用意されたコミュニケーションパスだけでなく、個人的な関係性を構築することです。
まず一番大事なのは相手の気持ちを知ることです。
私は必ず「仕事で大事にしていること」「課題だと思っていること」「今後どんなことをしていきたいか」を聞くことにしていました。
自分が聞きたいことを聞くのではなく、相手の反応に合わせて、相手が言いたそうなことをできるだけ深堀りして、自己開示を促すことが大切になります。
そういった盛り上がりテーマがあれば、自分もそれに対する意見を表明して、対話を行うようにするとGoodです。
そうしていって対話を深める中で目指すのは名前としての記号ではなく「ごまずんさん」「まるまるさん」と呼び合う中でお互いに固有の過去や背景を持った固有の関係性を築くことです。
ここの言語化は難しいですが、営業で言うと「顔を覚えてもらう」と言うところに匹敵すると思います。

2.自分の存在を売り込む

ここでは自分が何をやってきて、何ができるのか、何をしたいのか、どんな人間なのかを強制的に知ってもらうことを目的としています。
相手にとっても自分に何をお願いしたらいいのかを明確にしてもらい、チームとしての工数拠出要因としてだけでなく一個人として人格のある人間として認識してもらうことが目的です。
この時の注意点ですが、強めの思想や、〜してほしいなどの強めの要求は盛り込まないことです。
笑いどころは１つ以上作って、あくまでも1on1を楽しんでもらいながら、さりげなく自分を知ってもらうことが大事になります。
あくまでオンボーディング受ける側の1 on 1で大切なのは"その人との固有を関係性を築く"ことの精神です。2をやれればベターですが、バランス感覚やコミュニケーションが苦手な人は1に注力した方がいいでしょう。

わからないことを聞こう

聞くという行為が大切

最初は良い弟子として動くことが良いでしょう。
わからないことは積極的に聞いていくことが大切になります。
自分にとって理解が及ばないと感じたことや難しいことは積極的に聞くようにします。
この際に、「自分にはバイアスがある」ときちんと認識して「わかったフリをしない」ということが大事になります。
例えば「テスト戦略」という言葉があったとしても、組織によって表す内容、定義する事柄は多種多様です。JSTQBや29119の蘊蓄がちょっとあるからといってその組織の定義を理解できるとは言えません。
少しでも食い違いがあるなと感じたらなんでも聞くことです。
良い弟子になることで、相手への配慮と自分自身のバイアスを取り除き、早くチームに馴染むことが可能になります。

聞き方が大切

聞くことも大事ですが聞き方も大事です。
自分がわからないことや、どう理解したか、どう食い違いがあるのかをきちんと理解して言語化する技術が求められます。
他にも相手に配慮した聞き方があります。例えば枕詞を使うなどです。

• こういった理解で合っていますでしょうか？（以下箇条書き）

• 今後のアクションについて確認させてください(以下箇条書き)

• 勉強不足で申し訳ないのですが〜

• 申し訳ありません、この点に不安があるので、Meetでお話しできないでしょうか？

何かを聞くときの心構えとしては決してパニックにならないことです。
自分の中でわからないことを落ち着いて言語化して、もしすぐに解決しなくても、相手とのコミュニケーションがなぜうまくいかないかを冷静に分析して、事実ベース、できれば単語ベースでわからないことを聞いていくのが良いでしょう。
なお、「一々聞いてくんな」とキレる人もいますが、その時は「お忙しいところ大変失礼いたしました」と素直に謝ることが大切になります。

頼まれたことはすべて即応しよう

フルリモートの場合、どういったところで悩んでいるのか、手が止まっているのか、下手すれば「本当に仕事してんのか」と思われる場合があります。
そのために私は私にメンションされた内容はすべて即応するようにしています。
何の成果が挙げられていなくても、何かを言われた際は「承知いたしました。hogehogeについて検討いたします」などの何をする予定なのかを数分間で明確に言語化するようにしました。
また、まとまった仕事を頼まれた際、基本的には1時間以内に叩き台や手順を作り、依頼者やチームのみんなに見てもらうことが良いプラクティスです。
どちらにせよ、相手と自分との認識の違いを早めに識別して、早いフィードバックをもらうことを目的としています。

無理に改善しない。したい場合はまず質問する。

これは人によって意見が別れるところです。
入社したての頃はこれまでの経験から、色々な違いや良いプラクティスを取り入れたくなりますが、この感情については注意が必要です。
そのチームがその方法論を取り入れているのは、そのチーム固有の背景や経緯があり、それらは文書化されているとは限らないからです。

それでも気になった場合は「hogehogeについて理解ができませんでしたが、fugafugaなのでしょうか？」といった聞き方であくまで既存のメンバーの主導で改善を促していくようにすることが穏便に済みます。

結果的には「こちらのタスクは一度私の方で進めさせていただくことは可能でしょうか？」などで明示的にパスをもらうことで結果的にイニシアチブを取ることが可能になります。なので慌てず、相手のペースで問題を起案するようにするのが良いでしょう。

頼まれなくても日報を書く

自分が今日何をして、何を考え、これからどうしていくのかを積極的に発信していきましょう。
報告義務がなくても、どのように仕事を進めているのかをきちんと文書化して周りにアピールすることが大切です。
私の場合はtimesに投稿するようにしています。
またチームリーダーという立場もあり、メンバーの日報を見る立場でもあるのですが、相手に開示してもらってる以上、自分が開示しない理由はないと考えました。

結局は周りに恵まれるかどうか

身もふたもないですが、ホンマこれです。
基本的には周りに恵まれていることに一番影響を受けます。
もしオンボーディングがうまくいったとしたら、それは周りのメンバーや組織の文化に恵まれたからです。
もしオンボーディングがうまくいってなかったとしたら、どこか自分の中でバイアスがあるか、期待値にギャップがあったか、コミュニケーションの取り方がまずかったかだと思います。基本的に他責にするのは何の解決にもなりません。(ただし、心を病むようなら他責にして自分はゆっくり休みましょう)

とりあえず適当に書いてみました。
よき新生活を。