paint-brush
開発者オンボーディングがうまくいかない理由と、何を変える必要があるか@rasmusstjernstrom
374 測定値
374 測定値

開発者オンボーディングがうまくいかない理由と、何を変える必要があるか

Rasmus Stjernström4m2024/11/14
Read on Terminal Reader
Read this story w/o Javascript

長すぎる; 読むには

オンボーディングは急いで行われることが多く、開発者は迷ったり、関心を失ったりしてしまいます。構造化されたアプローチは生産性と定着率を高め、新入社員が初日から成果を上げるのに役立ちます。

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - 開発者オンボーディングがうまくいかない理由と、何を変える必要があるか
Rasmus Stjernström HackerNoon profile picture
0-item

面接、テスト、コード チャレンジ、そしておそらく二度と会うことのない人々とのぎこちない雑談のマラソンを経て、ようやく仕事に就きました。あなたはワクワクして、飛び込んでインパクトを与える準備ができています。しかし、現実が突きつけられます。オンボーディングは後付けのように感じられます。


それは、同居するまではあなたに気遣いを見せてくれる人と付き合っているようなものです。突然、相手がソファーでポテトチップスを食べているのを見て、あなたは「自分の持ち物はどこに置けばいいの?本当にこんなふうに契約したの?」と疑問に思うことになります。


テクノロジー業界では、オンボーディングは急いで行われることが多く、新入社員がコーディングを始める前にチェックする項目です。しかし、不十分なオンボーディングは単にイライラさせるだけでなく、生産性を静かに低下させます。チーム全体のスピードを低下させ、開発サイクルを混乱させ、離職コストを押し上げます。

チームが大きくなればなるほど、この問題は大きくなります

  • 立ち上げ時間の延長
  • 離職率の向上
  • チームの生産性の低下
  • 知識サイロ


…リストはまだまだ続きます。これほど多くのことが懸かっているのだから、オンボーディングをチームの成功と製品の勢いの重要な推進力として扱うべきではないでしょうか?

問題

多くの開発者にとって、オンボーディングは、未完成の地図を持って迷路に放り込まれ、自分で解けることを期待するようなものです。ノートパソコンといくつかのツールへのアクセスが与えられ、案内してくれる「仲間」もいるかもしれません。しかし、明確なガイドライン、期待、構造がなければ、特に大規模な組織では、すぐに混乱が生じます。すぐに仕事に取り掛かるのではなく、混乱とボトルネックの地雷原を進むことになります。


最も大きな誤解の 1 つは、単に仲間を割り当てるだけですべてが解決するということです。確かに、頼れる人がいると役立ちますが、明確な目標と構造がなければ、このアプローチではギャップが生じます。

従来のチェックリストでは不十分な理由

多くの企業は、オンボーディングを依然としてチェックリストとして扱っています。つまり、ツールへのアクセスを許可し、メールを設定し、いくつかのタスクを割り当てて、それで終わりにします。しかし、この「トランザクション」アプローチは的を外しています。チェックリストは、役割の「方法」という基本事項をカバーするのには最適ですが、「理由」についてはほとんど触れていません。新しい開発者には、ツールのツアー以上のものが必要です。彼らは、自分の仕事の使命、目的、影響について明確な理解を必要とします。それがなければ、エンゲージメントが低下し、新入社員はすぐに機械の歯車の 1 つにすぎないと感じてしまいます。


私の考えでは、採用に注ぐのと同じ注意と思慮深さでオンボーディングに取り組む必要があります。オリエンテーションとツールのセットアップを急いで行うのではなく、オンボーディングでは、役割固有のワークフローと明確なマイルストーンを通じて、新しい開発者を徐々に統合し、仕事の技術的および戦略的なコンテキストの両方を理解できるようにする必要があります。


チェックリストは情熱を失わせるものです。オンボーディングは動的で意図的、そして力を与えるものでなければならず、開発者に初日から早期の成功と強い目的意識への明確な道筋を与える必要があります。

知識のサイロ化を打破する

オンボーディングの最大の悩みの 1 つは、知識のサイロ化です。開発者は、チーム、ツール、ドキュメントに分散している情報を常に必要としています。毎週これらの詳細を追跡することは、生産性を低下させるだけでなく、イライラさせるだけです。


オンボーディング ジャーニーを作成する関係者だけが関連する知識を付与するのではなく、プロセスを逆転させて、システムが新しい開発者に適切な情報を適切なタイミングで積極的に提示し、やり取りを減らすことを想像してみてください。


これが私が思い描いている方向性です。構造化されたジャーニーの構築から始めて、必須アプリを統合し、関連する知識を添付し、その配信を自動化します。また、コミュニティが生成したテンプレートは素晴らしいアイデアだと思います。これは、現実世界の入力によって進化し、改善されるライブラリです。ここでは探索すべきことがまだたくさんあり、この先はエキサイティングな道です。


私は Telepathic の CTO であるKillian Dunne氏に、「テンプレートは、オンボーディングの効率とチーム間の一貫性をどのようにサポートできると思いますか?」と尋ねました。彼の答えは次のとおりです。


リソースを作成し続けて、技術者を採用するたびに同じオンボーディング プロセスを繰り返すのは非常に面倒です。セットアップとトレーニングの時間を大幅に短縮できれば、大きなメリットになります。

オンボーディングとリテンション:表裏一体

オンボーディングとリテンションは本質的に結びついています。オンボーディングがポジティブな体験であれば、開発者は評価され、サポートされていると感じます。これは長期的な満足度とエンゲージメントの鍵となります。対照的に、オンボーディングが不十分な場合は、会社に組織力が欠けていることを示す危険信号となり、開発者は他の場所で機会を探すことになります。オンボーディングへの投資はリテンションへの投資であることを私は何度も目にしています。開発者のオンボーディングは、採用プロセスの単なるステップではなく、チームへの長期的な投資なのです。


私の最初の HackerNoon 記事を読んでくださり、ありがとうございます! 😊私はRasmus StjernströmSilo Teamの共同創設者です。妹と私たちの小さな情熱的なチームと一緒に、私たちはオンボーディングを本当にシームレスにするという使命に取り組んでいます。なぜか? 開発者がすぐに仕事に取り掛かれると、製品をより早く出荷でき、誰もが恩恵を受けるからです。アイデアの交換やベータ版の試用に興味がある場合は、お気軽にご連絡ください!