【勉強会主催参加記録】Engineer Onboarding Meetup #1 @co-ba JINNAN(渋谷)

主催参加イベント

engineer-onboarding.connpass.com

主催参加目的

• 所属組織に新人が入って来る際の受け入れに苦労しており、onboardingについて知見を集めるため
• 国内のエンジニアがいる組織(企業/チーム)が、Onboardingをきちんとすることを当たり前にするため
• 主催すると役割が発生するのでドタキャンが出来ない（迫真）
• エンジニアイベント主催の経験を積むため

登壇

上司のオンボーディング ーある日あなたのチームの上司が突然変わったらー

てつのすけ@まなびプランナー (@tetsunosuke) | Twitter

• まなびプランナー（採用・組織開発）
  • ワークショップ・ゲーム研修・ファシリテーター・組織エンジニア

---

• 雑にチームビルディングをする方法は、共通の敵を作ってしまうこと
• チームビルディングのGRPI
  • Goal
  • Role
  • Process
  • Interaction
• 上司が高圧的になる -> メンバーが団結して上司を敵にする -> 上司はますます高圧的になる悪循環
• 上司も本当は仲良くしたい（人事も）
• コミュニケーションの不足に問題がある -> お互いの期待を合わせよう
• 期待を合わせるためにすること
  1. 上司をのぞいて集まる
  2. 期待すること・質問を匿名で記入
  3. メンバー同士で相互理解
  4. 上司を拍手で歓迎
  5. 答えられるものから答えてもらう
  6. 所信表明・計画説明
  7. ワークショップ・親睦会

メルペイのオンボーディング

shinden (新田) (@t_shinden) | Twitter

• メルペイのバックエンドエンジニアマネージャー

---

• 初日

  • 会社が大事にしている価値観の理解を深める

• 二日目

  • 決済事業の業界とビジョンの理解を深める
  • メルペイの会社としての価値観の理解を深める

• 三日目

  • メルペイエンジニアのOnboarding
    • エンジニアに必要なシステムアウトラインを理解する
      • マイクロサービス全体、アーキテクチャ、gRPC、Spanner、GCP、チーム全体
    • 各マイクロサービスチームでのオンボーディング
      • オリエンテーション、メンター、メンターランチなど

• さらなるオンボーディング体制を作る必要がある

Manager README

kubot64 (@kubot64) | Twitter

• DMM.comのメンバーシップサービス部のマネージャー

---

• DMM歴まもなく6年
  • プラットフォーム -> マネー統合 -> やっていきチーム -> 他事業コンサルチーム -> 基盤開発チーム
• 「会社に来て楽しいか？」
  • 成果を出すためのスキルとモチベーションの両方を判定することができる質問
• HRTの中でも重要なのは信頼
• 情報がオープンであること、なぜその決定がされたのかが透明であること
  • ダメな例 : 「CEOがダメと言ったので」
• Modern Agileなチームが好き
  • 特に気に入っているのは「高速に実験＆学習する」
• ふりかえり
  • ポジティブに振り返ること
  • KPTだけじゃない。色々試してみるのがいい
• コミュニケーション
  • DMよりpublicで会話する
• 1on1
  • 詳しくはnitt-sanのスライドを見てね！（宣伝）

オンボーディングの理想と現実

kosako (@aki85135) | Twitter

• RettyのVPoE

---

今日のポイント

1. 手段の前に目的をしっかり考えよう
2. みんなを巻き込んで継続しよう
3. 人と組織に合わせたオンボーディングをやろう

---

• 組織の一員として定着させ、戦力化する
• オンボーディングは人事戦略におけるサイクルの中のひとつ
• 戦略的採用のホイール・モデル
  • Input -> Process -> outputのサイクル
  • InputやProcessに課題がある場合、outputだけよくしようとしても意味がない
• 人の課題
  • 誰に聞けばいいのかわからない
  • 相談先がない、わからない
  • 人同士の関係
• 情報の課題
  • どこまでわかっているのかがわからない
  • 情報の存在自体も知らない
  • 最初からいた人だけは知っている、ドキュメントされてない暗黙知
• カルチャーの課題
  • 会社のミッション、価値観への理解
  • 期待値のズレ
    • 何を期待されているのかが本人、現場ともにわかっていない
    • 「頑張ってるんだけどなぜか会社に評価されない」
    • 期待する期間の認識差分
• 中途でありがちなこと
  • 「中途は即戦力」 -> 何をどれぐらい教えるべきかはっきりしていない。「まあなんか頑張ってよ」
  • シニアはある程度値踏みされる
    • 信頼を構築する難易度が高い
• 会社、職種横断組織、チームの3つのレイヤでやることを考える
• やりたいことを挙げれば無限に出てくる
• 最初は入社後1〜2ヶ月ぐらいの社員を巻き込んで資料を作っていく
  • ドキュメンテーションをオンボーディングにする
• オンボーディングの最後に「自分なりにRettyをどう理解したか」をアウトプットしてもらう
• 入社後2週間は毎日1on1をする
• 3ヶ月後、半年後に期待していることを伝えた上で、本人にプランニングしてもらい、定期的にフィードバックを行う

採用活動は究極のオンボーディングである

星 (@yahooshiken) | Twitter

• POLのEM

---

採用活動は究極のオンボーディングである

• PXとは
  • POLにはPX(People experience)部がある。人事部がない。
  • 全員採用
    • 採用活動はメンバー全員でするもの
    • JDもメンバー起点で考える
  • スクラム採用
    • 基本方針 : 経験主義
    • 透明性（メトリクスを取る）
    • 検査（悪しきプロセスを発見する）
    • 適応（カイゼンする）
• 採用活動への取り組み
  • エンジニアの採用要件/JDをチーム全員で考えた
  • 一人一人がどういう人と働きたいかを明確にイメージ
  • 一人一人がどういう人に成長していくべきかを考える機会となった
• 全員採用する3つのメリット
  • 採用パワーが増加する
  • 候補者の採用体験向上
  • チームメンバーのPX向上
• 今後の課題
  • エンジニアの幸せってなんだ？
  • 全員採用から全員広報へ
  • 採用要件・JDの認識、バリューの浸透度合いを合わせるのが難しくなってきた