こんにちは。技術本部 技術戦略ディビジョンでマネージャーをしています、奥村です。
チームに新しいメンバーが参加する時に行っている事をまとめてみました。新しいメンバーが迅速にチームに溶け込めるように試行錯誤しています。
オンボーディングプロセスで悩んでいる人が参考にできる一例になれば嬉しいです。
オンボーディング準備の前に
オンボーディング準備の前にチームの状態や仕組みを確認しましょう。
チーム運営に役立つものは、オンボーディングにも役立ちます。
私のチームの場合、オンボーディングのために新たに作った仕組みはほとんど無く、普段からチームで利用している仕組みを流用するケースが多かったです。
逆に、オンボーディングについて考える事で、チームに不足している要素を洗い出せるかもしれません。
オンボーディングにも役立つチームの仕組み・取り組み
- スキルマップ
- 1on1
- ワーキングアグリーメント
- ガイドライン
- コーディングガイドライン
- レビューガイドライン
- ステークホルダーマップ
- チームの過去実績まとめ
もっといろいろあるかもしれないですが、私のチームで明確に活用しているのは上記の通りです。
「チームの過去実績まとめ」は目標の資料やエンジニアブログのリンクなどをまとめておくだけのものですが、これまで何をしてきたかが簡単に思い出せるので便利です。
チームに新しいメンバーが参加する時に行っている事
前提
ジョインしてやること、やってもらうことをすぐに確認・共有できるようにチェックリストを作ります。
一度作ってしまえば更新するだけなので後は楽です。
コミュニケーション系
- 1on1
- 奥村とメンバーで30分/週程度で実施
- 他チームとMTG
- 普段から関わりのあるチームとのMTGに参加
- 上位レイヤーと雑談
- チームの一つ上のレイヤーのマネージャーと雑談
- 対面で働く
- オフィスで一緒に働く
補足:対面で働く
私のチームは基本的にリモートワークです。
世間的にリモートワークも浸透しましたが、ジョインしたばかりの人がZoomやSlackだけでコミュニケーションをとるのはそれなりのハードルがあると考えています。
やはり物理で会話した方がコミュニケーションも取りやすいですし、会話のテンポも良くなる気がしています。
なので、特に最初の内はチームメンバーとのコミュニケーション機会増加のために、対面で働く機会を設けるようにしています。
組織説明系
- 会社説明
- パーパス&バリュー
- オフィスの使い方
- 総務や経理などの質問方法
- チーム説明
- ミッション
- 部署設立背景
- 担当領域
- 目標・目標管理
- ステークホルダー
- ロードマップ
- 直近のプロジェクト
- 過去実績
- タスク管理・業務の流れ
- 定例会議説明
- 1週間の流れ
- ワークルール
- ワーキングアグリーメント
- カルチャー
- アウトプット文化
- レビュー
- ポストモーテム
- 障害時の動き方
- ADR(xDR)(参考:ADRならぬxDRであらゆる意思決定の記録をすぐに確認できるようにしている話 - ADWAYS ENGINNER BLOG)
- ガイドライン
- コーディングガイドライン
- レビューガイドライン
補足:カルチャー
前述しましたが、チーム運営に役立つものは、オンボーディングにも役立ちます。
ですが、カルチャーに関しては言語化できていない部分が多いのでは無いでしょうか。
せっかくなのでオンボーディング準備のタイミングにでも自分たちの文化を見直して言語化する事をおすすめします。
ルール化まで至ってないが、みんなやっていることがそれに当たると思います。(ルールにしても良いと思います。)
業務環境系
- PCのツール・ソフト
- 必須ツール
- 推奨ツール
- 独自ツール
- (e.g.) タスク作成のCLIツール, SSHツール
- クラウド
- クラウドの独自取り組みの説明
- (e.g.) 自動削除, セキュリティガードレール
- アカウント(IAM)作成
- クラウドの独自取り組みの説明
- SaaS
- 各SaaSの説明
- アカウント作成
補足:PCのツール・ソフト
私のチームでは自由に使うツールを選択できるようになっていますが、チームで使うデフォルトのツールやソフトは決めておく方が良いと思います。
デフォルトのツールを決めておけば、セットアップの自動化や設定の共通化もできるのでメリットがあると思います。
オンボーディングもやりやすくなります。
ただ、ツールを縛る(例えばエディタを縛る)とそれなりに反発もあると思うのでチームで合意形成はするべきですね。
相互理解系
- ドラッカー風エクササイズ
- ムービングモチベーター
- スキルマップ入力
補足:スキルマップ入力
私のチームではスキルマップを作成・運用しています。
項目はPython、Terraform、パブリッククラウドの各種マネジメントサービスなどです。
4段階評価で自身がどの程度の経験や知識があるかを可視化しています。
評価基準も決まっているのでスキルの理解度の共通認識が生まれます。以下は評価基準の抜粋です。
- LV.1(無): 知らない
- Lv.2(△): 知っているが、説明できない。業務経験あり。
- Lv.3(◯): 概念・理論も説明できる。最新情報がわかる。
- Lv.4(◎): 完璧。他者に指導可能。
まずは、ジョインしたタイミングでの自己認識を入力してもらい、今後もっと伸ばしたいところ・伸ばしてほしいところの認識合わせも行います。
参考:スキルマップの抜粋(※ ◯の基準を厳しめにしています!)
序盤の業務
序盤に取り組んでもらう業務も検討しリスト化しておきます。
- システム理解
- 構成理解
- コード読み
- スキルマップを元にした勉強
- 小さく成果が出せるタスク
補足:小さく成果が出せるタスク
私のチームでは新しくジョインした人にいきなり難易度の高いタスクを割り当てるのではなく、規模が小さめでそれなりの成果が生まれるタスクに取り組んでもらっています。 これには2つのメリットがあります。
- 新しいチームでの成功体験を得る
- 成果を生み出す業務の流れを理解する
両方とも重要な要素なので、序盤の内に経験してもらうのが良いと考えています。
直近だと「GitHub OrganizationのTerraform化」に取り組んでもらった事例があります。
規模が小さすぎても成功体験として弱い可能性があるので新しいメンバーのスキルや状態を加味してちょうどよいタスクをアサインするようにしています。
今後取り入れたい事
現在は行っていない、今後取り込みたい事を挙げます。
- 相談先を決める
- 1年間の計画を立てる
相談先を決める
現状は、「何かわからない事があれば、SlackのチームのチャンネルかZoomの雑談部屋でチームメンバーに質問してもらう」という方法で行っています。
全員が反応できる場所で相談をしてもらう事になっていますが、チームメンバーの反応が無かったりすると不安になる可能性があります。見落とす可能性もあります。
また、既存メンバー側も「質問は確認したが回答が分からないので分かる人が見るまでスルー」の選択肢が生まれます。
新しく入った人には「時間が掛かるかもしれないが返信はするという認識を持ってもらう」こと、既存のメンバーには「分からない事の場合は分からないと伝えた上で他の人にリダイレクトする」ことをお願いしてもよいとは思います。
とはいえ、デフォルトの相談・質問先を決めていれば解決する事だと思うので、取り入れたいです。
1年間の目標を一緒に立てる
現在は「小さく成果が出せるタスク」の完了をオンボーディングの完了としています。 オンボーディング完了後は通常のチームメンバーとして、スキルマップを元にしたスキル向上やOKRに取り組んでもらっています。
その通常のチームの取り組みに加えて、「1年後にどうなっていたいか」「1年間でどういう事に取り組むか」などを決めたいと考えています。
業務とスキルアップの年間のざっくりとした見通しを立てられると、日々の業務に対するワクワク感も向上するんじゃないか?と考えています。
新しいメンバーとビジョンを共有できるのも良さそうです。
まとめ
「チームに新しいメンバーが参加する時に行っている事」をまとめてみました。
新卒採用、キャリア採用、部署異動など様々なチーム参加イベントに対応できるので一度作ってしまえば、受け入れが効率化します。
まだ作っていないチームは是非作成してみてください。