どのようにボトルネックに陥るのか？
成長中のスタートアップ企業は、一般的にオンボーディングプロセスへの投資が不足しています。人員を急速に増やす必要性は、予期せず発生する可能性があります。製品が顧客に受け入れられた、スタートアップ企業が買収された、あるいは新しい製品の方向に方向転換したなど、あるイベントがチームの規模拡大のきっかけとなることがあります。急速に、スタートアップ企業が新しい目標を達成するために必要な人数に関する計画が変更され、採用チームは面接とオファーを開始します。プレッシャーが増す中で、オンボーディングプロセスを最適化する時間を取りません。効果的なオンボーディングシステムがまだ導入されていない場合、新しい従業員はチームに配属され、いくつかのタスクが割り当てられ、生産性を高める方法を自分で考え出すしかありません。特に、チームメンバーが新しい従業員の立ち上げを共同で支援していない場合、オンボーディングのドキュメントがない場合、コードが読めない場合、あるいは製品の目標とKPIが不明確な場合は問題です。そうなると、新しい従業員は迷子になり、不満を抱き、生産性が低下する可能性があります。この記事では、企業が効果のないオンボーディングプロセスによってボトルネックになっている兆候と、Thoughtworks Scaleup Studioで効果があると認められたベストプラクティスのソリューションについて探ります。
新入社員のオンボーディングに加えて、このプロセスはチームの再編成時にも活用されます。スタジオは、学習し、迅速に失敗し、焦点を合わせ直す能力は、スケーリングを成功させるための重要なスキルであると考えています。機敏なスタートアップ企業は、学習内容や状況の変化に対応して方向転換を行い、これには製品チームの目標の変更と、新しい目標を最適に達成するためのリソースの再割り当てが含まれます。これを容易に行うためには、再割り当てされたチームメンバーが迅速に立ち上がれるようにする必要があります。この記事の内容のほとんどは、再編成にも当てはまります。
オンボーディングは重要なビジネスプロセスです
オンボーディングは、多くの場合、単にアクセス権を付与し、一連の管理タスクを実行してから、新しい従業員をマネージャーとチームに引き渡すことと見なされています。エンドツーエンドのビジネスプロセスとは考えられていません。しかし、適切に運営されているオンボーディングプロセスは、社会的および文化的な統合に取り組み、新しい従業員が対話しなければならないさまざまな機能間の連携を促進します。オンボーディングプロセスには、通常、人事、エンジニアリング管理、法務、IT運用、セキュリティ、および製品チームのメンバーが関与します。これほど多くのグループにまたがっているということは、非常にばらばらになる可能性があるということです。プロセスを最適化することは困難です。なぜなら、多くの場合、誰もプロセス全体を所有しておらず、すべての異なるプレーヤーをまとめなければならないからです。
ソフトウェアリーダーは、採用計画の策定と採用活動の支援に多大な努力を払っていますが、新しい従業員がどのように効果を発揮するかについては、あまり考えていないことがよくあります。これは間違いであると考えています。なぜなら、効果的なオンボーディングは、新入社員にとって「乗数効果」として機能するからです。
臨床的な観点から、新しい従業員の価値は何でしょうか？適切なオンボーディングがなければ、新入社員は価値と生産性の一部しか発揮できず、中には50％程度まで低下するものもあります。このレベルのROIでは、意図した目標を達成する可能性は低くなります。リーダーは追加の採用を余儀なくされ、組織の複雑さとマネージャーの作業負荷が増加します。これを避けるために、新しい従業員の採用と同じくらい、オンボーディングの最適化にも力を入れることをお勧めします。
私たちの意見では、オンボーディングプロセスは1週間後や1か月後に終了するわけではなく、その人が完全に生産性を発揮するまで続きます。誰かがオファーを受け入れるとすぐに、オンボーディングプロセスが開始され、その後、堅牢な新入社員オリエンテーション、ラップトップの受け取り、適切なシステムへのアクセスが行われます。チームに加わった後も、初めて職務を遂行し、チームメンバーやマネージャーとの関係を築き、一般的なタスクに関する習慣を身につけるにつれて、プロセスは続きます。オンボーディングの最後のフェーズでは、従業員が十分な生産性を発揮できるようになり、チームに創造的に貢献し、他の人を教え、オンボーディングプロセスに貢献することができます。このタイムラインは、役割、ドメイン、複雑さによって異なります。
最適なオンボーディングのタイムライン
状況を把握するために、この表は、開発者のオンボーディングの最適なタイムラインとして私たちが観察しているものを示しています。ここで言及されている概念については、この記事の残りの部分で詳しく説明します。
| マイルストーン | 完了期限 |
|---|
| すべての人事および管理システムへのアクセス | 1日目 |
| ワークステーションと個人開発環境へのアクセスが、必要なツールでセットアップされている | 1日目 |
| 企業理念と事業目標が説明され、議論される | 2日目 |
| 同僚の支援を受けて、些細な変更の本番環境へのプッシュを完了する | 3日目 |
| マネージャーが従業員と期待値を設定し、OKRを与えている | 1週間後 |
| 同僚とペアを組んで、本番環境までの実際の機能開発と欠陥解決を行う | 2週間後 |
| 主要な顧客の問題と社内業務プロセスを理解している | 2週間後 |
| 開発者: ストーリーの「アンカー」になることができる | 3～5週間後† |
| 開発者: サポートコールを主導できる | 5～7週間後† |
† 複雑さと経験によって異なります
スケーリングのボトルネックに近づいている兆候
新しい開発者が本番環境にデプロイできない
使用できる定量化可能な指標は、新しい従業員がコードを記述し、コミットし、本番環境にデプロイするまでにどれくらいの時間がかかるかです。これは、最初の1週間、理想的には最初の数日間で行われるべきです。複雑なタスクである必要はなく、非常に些細なことでも構いません。この指標は、開発者がコンピューターと開発環境を正しくセットアップし、本番環境に独自にプッシュするために必要なすべてを備えていることを示しています。新しい開発者が数週間、あるいは数か月も会社に在籍していて、本番環境に何もデプロイしていないという状況が見られます。
新入社員が孤立していると感じている
特にスタートアップ企業では、ほとんどのマネージャーは新しいイニシアチブにレーザーのように焦点を当てており、処理できる以上の仕事を抱えています。直属の部下の統合と立ち上げを優先順位から外すのは簡単です。新しい従業員は、システムの学習、関係の構築、必要なリソースへのアクセス方法などを自分で考え出すしかありません。さらに悪いことに、明確な目標が与えられていない場合、彼らは間違ったことに取り組んでしまう可能性があります。従業員は孤立し、生産性の大幅な低下や急速な離職につながります。このような文化的な問題は、発見するのが困難です。マネージャーの声と新しい従業員からのフィードバックに耳を傾けることをお勧めします。退職面談も貴重なデータとなります。
個々の作業に集中しすぎている
スタートアップ企業が新しい従業員を追加することで規模を拡大する場合、これにより異なる運用モードがトリガーされる可能性があります。最初の製品とテクノロジープラットフォームを構築したのは、小規模なチームでした。各エンジニアは、アプリケーションの一部を構築およびサポートすることに焦点を当てており、おそらく単独で作業していました。より大きなチームへの拡張に伴い、私たちがよく観察する問題は、在職期間の長い従業員が新しい従業員のオンボーディングに十分な時間を割いていないことです。つまり、新しいエンジニアとのコラボレーションやペアプログラミング、仕事のやり方の文書化、技術的な決定の理由の説明などを行っていません。そのため、オンボーディングが非常に困難になります。
チームの規模が拡大した場合、目標は個々の貢献に焦点を当てるだけでなく、製品チーム全体のパフォーマンスも含まれるべきです。製品チームのふりかえりでは、理想的には、新しい従業員の生産性を高める機会を探す必要があります。私たちが目にするアンチパターンは、個人が単独で作業の流れに割り当てられるように計画することであり、これにより知識の伝達が妨げられます。
変化に対するオープンさが足りない
新しい従業員を採用すると、既存のチームとは異なる経験を持っている可能性があります（特に、個人的なネットワーク以外で採用している場合）。彼らは異なる意見や視点を持っています。企業がこれを活用していないのをよく見かけます。典型的な状況は、スタートアップ企業には、仕事のやり方を見つけ、独自の特異性を持つ「ベテラン」のチームがあり、すべての決定には歴史があるということです。チームはアプローチに独断的であり、新人の新しいアイデアを却下します。これにより、新入社員は力を奪われ、評価されていないと感じます。
繰り返しますが、これは文化的であり、発見するのは困難ですが、注意すべきアンチパターンは次のとおりです。
- 既存の従業員が会議を独占したり、早口で話したり、新しい従業員が貢献したり、明確にしたりするのに十分な時間を与えなかったりする。
- 現状を過度に保護する。アイデアを却下する - 「私たちはそれを試しました」、「ここではうまくいかないでしょう…」。
- 非公式なチャネルを通じて裏で話を進める。在職期間の長い従業員は、文書化されたプロセスではなく、確立されたネットワークを通じて「お願い」をすることで、仕事を済ませてしまう可能性があります。
離職率が高い
新人の離職率は遅行指標です。離職率が高い理由はたくさんあるかもしれません。しかし、調査する価値はあります。オンボーディングプロセスに関連している可能性があります。新しい従業員が適切なトレーニングを受けておらず、会社に歓迎されていない可能性があります。チームは離職率とその傾向を監視し、新しい従業員に対して6か月後と1年後にアンケートを実施して補足する必要があります。そして、その結果を学習して、オンボーディングプロセスを継続的に改善することができます。
ドキュメントが新入社員の質問に答えてくれない
新規採用者、特に経験者採用者は、通常、高レベルで何をする必要があるかを知っています。しかし、新しい環境の特異性により、ごく普通のタスクでさえ完了できない場合があります。例えば、ソースリポジトリの場所や統合テスト環境のベースURLがわからないなどです。適切に構成されたオンボーディングドキュメントは、生産性を向上させ、自信を高め、一般的に快適な作業環境を提供するのに役立ちます。ドキュメントを継続的に改善し、最新の状態に保つために、新規採用者はドキュメントのバグを見つけて修正することを奨励する必要があります。
ボトルネックからどのように抜け出すのか？
オンボーディングプロセスを設計する際には、従業員の有効性について包括的に考えることが最初のステップとして有効です。以下の解決策セクションでは、有効性への道筋を作成する方法、Checkrで適用されたオンボーディング最適化の例、そして重要と考えるいくつかの手法について説明します。
効果的なパスを作成する
開発者の有効性を最大化するで、Timはアウトプットではなくアウトカムに焦点を当てるという考え方と、エンゲージメントの高い従業員がビジネスと顧客にとって最大の価値をどのように創造できるかについて話しました。権限を与えられた従業員は、単に要件をコーディングしたり、仕様に合わせて設計したり、営業チームからのリクエストに基づいて機能を作成したりするだけではありません。彼らは問題領域について創造的に考え、費用対効果が高く、スケーラブルで革新的なソリューションを考案しています。権限を与えられた従業員には何が必要か、そしてオンボーディングがそれをどのように可能にするかを見てみましょう。
企業のミッションとビジネス目標の明確な理解
リーダーは、ミッションの創造につながった経緯、将来の可能性、そして従業員がどのように貢献できるかを概説し、ミッションへの興奮を高める必要があります。これには、現在の製品戦略の展望も含まれるべきです。
会社はどのように収益を上げているか（または上げる予定か）？
ビジネス感覚と倹約の精神を植え付けるために、新しい従業員は、会社が現在どのようにサービスに課金しているか、その収益性、そして投資レベルを知る必要があります。
顧客体験への共感
すべての従業員が顧客について考えることを期待しましょう。システムを使用している顧客を観察する、（可能であれば）顧客としてシステムを使用する、顧客の問題に関する以前の調査を読むなど、いくつかの活動によってこれを強調することができます。
社内業務の理解
ほとんどのソフトウェアシステムには、（ターゲット顧客以外にも）さまざまなユーザーがいます。技術者がこれらの社内ユーザーを効率化するソリューションを設計できるように、これらのすべての側面を理解することが重要です。これは特に規模が大きくなるにつれて重要になります。
ビジネスドメインの理解
多くのビジネスドメインは非常に複雑です。理解は時間をかけて深まりますが、専門家による概要と推奨される読書から始めることができます。
チームとの良好な関係
懸念やアイデアについてオープンに話し合うためには、新規採用者は同僚や上司と一定レベルの親しみやすさと脆弱性を持つ必要があります。オンボーディングには、これを可能にするための活動が含まれるべきです。リモートではより困難になるため、新規採用者が参加してから最初の数か月以内にチームが直接会うことをお勧めします。
自身の目標の明確な理解
権限を与えられた従業員には目的が必要です。会社が彼らに何を達成してほしいのか、そしてどのように評価されるのかを知る必要があります。
現在のチームトポロジー
新規採用者は、製品とシステムの所有権、そして情報を得るために誰に相談できるかを明確に理解している必要があります。彼らがどこに位置づけられているかを示す最新の組織図は不可欠です。最初の数週間で意図的に1対1のミーティングを設定することは、チームや機能間のコミュニケーションを促進する良い方法です。
テクノロジーの活用方法
すべてのスタートアップは、技術革新と規模拡大にテクノロジーを活用しているため、すべての従業員は基本レベルの理解を持っている必要があります。役割を「技術的」と「非技術的」に分けることは効果的ではないと考えています。一部の役割は他の役割よりも「より技術的」であるだけです。
役割固有のニーズがあります。開発者は以下を知る必要があります。
コードを記述し、本番環境にプッシュする
完全にセットアップされ、動作する環境で、デプロイするためのアクセス権があり、独立して実行できます。この環境は、品質の問題を発見し、安全にロールバックできるという自信を与えます。
本番環境の問題をデバッグし、修正する
システム全体にわたる明確な可観測性へのアクセス。これには、ドキュメント、ランブック、一般的なタスクのウォークスルービデオが含まれる必要があります。
既存のコード、アーキテクチャ、および依存関係を理解する
効果的な知識管理システム、すべてのソースコードリポジトリへのアクセス、依存チームへのアクセス、チームメイトおよびSMEとの知識の伝達。
ソリューションの進捗状況を測定する
ビジネスおよび製品分析、そして技術メトリクス（パフォーマンス、可用性、コスト、品質指標）。これには、ソリューションを試す能力（プロトタイプ、A/Bテスト）と定性的なフィードバックへのアクセスが含まれるべきです。
この記事は主に開発者を対象としていますが、これらの概念を他の役割にも拡張できます。プロダクトマネージャーは以下を必要とする場合があります。
顧客との直接の経験
主要な顧客の紹介から始めます。また、プロダクトマネージャーは関係を築くためのスペースが必要です。創業者が窓口になりたがる場合があり、フィルタリングされていない情報を取得することが難しくなることがあります。
現在の製品戦略を明確に説明する
新しいプロダクトマネージャーは、現在の戦略、関連するシグナル、現在の製品への賭け、そしてそれらが成功しているかどうかを迅速に理解できる必要があります。
分析を見つけ、アクセスする
レポートを要求するのではなく、セルフサービスで探索的に行えることが理想的です。これには、製品、行動、財務、マーケティング、販売の指標、およびシステムパフォーマンスの指標が含まれます。
過去の賭けと変曲点から学ぶ
製品は現在、いくつかの特定の理由（明白ではないかもしれない）で特定の方法で設計されています。製品をうまく進化させるためには、なぜそうなっているのかを知るのに役立ちます。
実験プロトタイプを作成し、システムで「試してみる」
多くの場合、プロダクトマネージャーはデモ環境を使用したり、プロトタイプを作成したりするために必要なアクセス権を持っていません。
デザイナーは以下を知る必要があるかもしれません。
ローファイおよびハイファイアセットを作成するためのツールにアクセスする
洗練された製品に加えて、デザイナーはクリック可能なプロトタイプを簡単に作成し、多くの儀式なしにユーザーテストを実施できる必要があります。
ブランディングガイドラインとデザインシステムを見つけ、使用する
一貫性を確保し、UIの設計と実装を容易にするために、これらはアクセスしやすく、適切に文書化されている必要があります。これらのシステムの成熟度は、スタートアップの成熟度によって異なり、共有デザインファイルから生きたコンポーネントライブラリへと進化します。
以前のユーザー調査を発見する
以前のユーザーテストの記録、インタビューのドキュメント、および統合された調査結果は、個人のサイロではなく、会社のナレッジベースにアクセス可能で保存されている必要があります。
A/Bテストを実施し、行動分析にアクセスする
ユーザーインターフェースは、デザイナーがセルフサービスで可能な限り多くの洞察を得られるように、計測されている必要があります。多くのA/Bテストフレームワークでは、特定の種類の変更について開発者のサポートなしに、独立したリリースと分析が可能です。
このリストは例であり、網羅的なものではありません。あなたの会社のコンテキストで、あなたの役割の目標と「成すべき仕事」を見ることをお勧めします。
これが実際にどのように機能するかを説明するために、Checkrの例を使用します。
ケーススタディ：Checkr
Checkrは、 *仕事の未来を支える* HRテクノロジー企業であり、2018年から2020年にかけてThoughtworksと提携して規模を拡大しました。アーキテクチャ、品質、プラットフォームエンジニアリングに取り組んでいる間、ThoughtworksのコンサルタントはCheckrのオンボーディングプロセスの有効性に気づきました。Checkrが初期チームを超えて成長したとき、彼らはすべての従業員のための体系的なオンボーディングプロセスを作成することに投資しました。このプロセスは、顧客への共感を育み、ビジネスを理解し、従業員をできるだけ早く生産性を高めるように設計されました。Checkrのリーダーシップによって重要な能力と見なされている彼らのオンボーディングプロセスにより、彼らは30人から300人のエンジニアリングスタッフに成長することができました。彼らの成功にもかかわらず、Checkrはフィードバックを収集し、新しいアイデアを試すにつれて、プロセスを進化させ続けています。
ミッションを理解し、共感を築くための部門横断的なオンボーディング週間
Checkrは毎月、すべての新しい従業員向けに1週間のオンボーディング「ブートキャンプ」を実施しました。ブートキャンプの目標は、リーダーシップとCheckrの他のチームからの話を聞くことで、従業員に会社と製品の包括的な理解を提供することでした。カスタマーサクセス、財務、製品、エンジニアリングなどの他の機能のメンバーは、チームプロセスと製品のユースケースを新しい従業員とレビューします。
部門横断的な概要に加えて、新しい従業員は、顧客の共感を深め、Checkrが解決しようとしている問題領域を理解するためのさらなる機会が与えられました。新しい従業員は、顧客の身元調査の一環として地元の裁判所に行って記録を引き出し、カスタマーサクセス担当者がCheckrのツールを使用しているときにカスタマーサポートコールに参加します。
当初、コホートは約20人でしたが、時間の経過とともに増加しました。ブートキャンプの追加の利点は、新しい従業員がすぐに社内ネットワークを構築できたことです。CheckrのエンジニアリングディレクターであるKrista Moroderは、次のように述べています。「私はまだ自分が作った最初のネットワークを使用しています。オンボーディング仲間の1人は、依然として法務部門の最初の連絡先の1人です。」
ブートキャンプの後、彼らは役割固有の2日間のワークショップを実施し、それぞれのチームにオンボーディングしました。
開発者の生産性への道筋
従業員は初日から必要なすべてのサービスとツールにアクセスできます。エンジニアは、スクリプトを使用して数時間で個人開発環境をセットアップできます。Checkrは、新しい従業員が初日にデプロイすることを目標としていますが、実際にはチームごとに異なり、平均で最初の1週間以内です。現在、ラップトップベースの開発環境からクラウドベースのアプローチに移行しており、追加の容量と容易な構成管理により、オンボーディングのスピードアップを目指しています。
多くのチームはペアプログラミングを使用します。つまり、新しい従業員は、焦点となっているタスクにすぐにペアを組んで参加できます。Kristaはペアプログラミングについて話しました
「私が最初に率いたチームでのペアプログラミングのきっかけはThoughtworksでした。主な動機は、品質欠陥の削減、コンテキストスイッチの削減、共有知識の増加、サイクルタイムの改善、パンデミック中に完全リモートになったときの従業員のつながりとエンゲージメントの維持でした。チームは、エンジニアが毎日のスタンドアップ終了時にその日のペアを選択するモデルを使用しています。」
Checkrでは、「あなたが構築したものをあなたが運用する」というアプローチを採用しており、各開発者はチームが所有するシステムをサポートすることが期待されています。この方法を学ぶために、新しい開発者は入社後1〜2か月で、同僚とオンコールサポートを共同で行うことから始めます。通常、社内製品の場合は2か月後、消費者向け製品の場合は3〜6か月後に、シニアリティに応じて、問題を独立して解決できます。Kristaにとって、「生産性の指標は、マネージャーまたは経験豊富な開発者が、新しい開発者が複雑な問題をエンドツーエンドで解決できると信頼していることです。」
品質賞と学習週間
オンボーディングとは、誰かが参加したときに行われる活動の一部であり、人々を効果的に導く文化を創造することでもあります。継続的な学習文化を奨励したいCheckrは、年に2〜3回、参加者主導の「学習週間」を実施しています。毎回、インフラストラクチャや品質などの異なる能力に1週間焦点を当てることを目的としています。キャンプの前に、現在の知識のギャップを理解するために調査が実施されます。これらの週は、仲間から学ぶ機会を提供します。理想的な世界では、誰もが継続的に専門知識を共有します。しかし、忙しいスタートアップでは、それは必ずしも起こりません。学習週間は意図を設定し、人々が助けを求め、知識を共有することに慣れるのに役立ちます。
Checkrの定期的な全体会議の重要な部分は、品質賞です。ここでは、個人が仲間から推薦され、貢献が認められます。製品の発売などの典型的なマイルストーンを祝うだけでなく、ドキュメント、テスト、廃止、リファクタリングの卓越性が認められています。これは、高い技術的品質と仲間のサポートに対する興奮を築く文化を強調しています。
最初のオンボーディング期間を超えて、チームはプロセス全体を評価するために定期的に調査を送信します。これは、プロセスが効果的かどうかを監視し、会社での成功の基盤を築くのに役立ちます。
新入社員を企業文化に取り込む
スタートアップに新しい人材を投入することで、思考やアイデアの多様性を高める機会が得られます。新規採用者の経験と知識は、製品をより良くし、テクノロジーをより革新的で、プロセスをより効率的にします。これらの新規採用者を真に活用するには、現在のチームが適切に統合するための作業が必要です。新規採用者が適切な環境なしに既存のチームとつながり、貢献することは困難です。既存のチームの既存の社会資本と名声は威圧的です。新しい従業員の声を奨励できれば、彼らは撃墜されることを恐れずに発言し、新しいアイデアを提案することができます。
この安全で脆弱な空間を作成することは困難です。初日から、新規採用者オリエンテーションから始めて、新しい従業員は会社の使命の一部であり、その進化に貢献できると感じる必要があります。リーダーは、彼らがどのように相互作用し、会社の原則を設定するかにおいて、模範を示すことから始めることができます。それは個々の相互作用に帰着します。特にオンボーディング期間中は、他者に気を配り、他者がどのように行動し、感じているかを意識する文化を浸透させることをお勧めします。
内定後と初日の体験を完璧にする
第一印象を作る二度目のチャンスはないと言われていますが、これは確かにオンボーディングにも当てはまります。オンボーディングは最初の面接から始まります。面接官が候補者とどのように相互作用するかは、候補者が会社の文化をどのように認識し、どのように行動すべきかについての先例を設定し始めます。それ以降、初日、最初の週、最初の月、そしてそれ以降の経験が重要であり、彼らが成功し、幸せになるかどうかに大きな影響を与えます。
したがって、雇用の初日までの時間は非常に重要になる可能性があります。候補者がオファーを受け入れた後、新しい従業員が明確化を求めるための明確な連絡先（個人ではなく、できればメールグループ）があることを確認してください。
従業員が必要とするすべてのツールは、セルフサービスで利用でき、初日からアクセスできる必要があります。最初の数週間を「もぐらたたき」のように過ごして、必要なすべての権限のチケットを作成したい人はいません。これには、従業員を福利厚生、業績追跡、給与、知識リポジトリに自動登録するITシステムが含まれます。
オンボーディングチェックリストは、従業員を初日に案内するのに役立つ方法です。たとえば、Thoughtworksでは、新規採用者にはオンボーディングタスクを含む独自のTrelloボードが提供されます。すべてのタスクには、段階的な手順と、さらに支援が必要な場合の連絡先情報があり、完了する必要がある順序で優先順位が付けられています。これにより、新規採用者は、給与口座への直接預金の 설정などの基本的なタスクや、作業用ラップトップのセットアップなどのより複雑なタスクを完了するための準備が整います。さらに、一般的なタスクに対する進捗状況をすべて自分で追跡し、支援を求める方法を追跡できます。
新規採用者には、オンボーディングを支援するためのオンボーディングバディが割り当てられます。これをさらにシームレスにするために、新規およびベテランの従業員が質問を投稿して支援を受ける「最初の1年間の経験」チャットグループがあります。長年勤続している従業員でさえ、参加後数か月間使い続けることは珍しくなく、オンボーディングプロセス全体で最も気に入っている側面の1つとして挙げられています。
セルフサービスのナレッジマネジメントに投資する
どれだけの量の独自の知識がすぐに蓄積されるかは驚くべきことです。アイデアやアプローチは以前のセッションからよく理解されているかもしれませんが、書き留められたことはありません。物事を文書化する時間を取らないと、新しい従業員にとって最初の数か月はイライラする可能性があります。「包括的なドキュメントよりも動作するソフトウェア」というアジャイルの原則を支持しています。ソフトウェアコードは読みやすいはずですが、それでも的を絞ったドキュメントが必要です。ベストプラクティスには以下が含まれます
- ライブラリ、API、依存関係、および統合に関する最新の簡潔な技術ドキュメント–技術所有者へのフィードバックループは、ドキュメントの有用性と鮮度を劇的に向上させます。
- 情報を見つける時間を最小限に抑えるための、分類とドキュメントの中央検索
- 共有の原則と実践：チームが通常どのように運営されているかを理解することで、新しい従業員は新しい文化に適応できます。
- 過去の技術的および製品の決定の記録により、思考プロセスの背後にあるコンテキストがより明確になります。
- サービスの劣化の事後分析の書き込み。すべて問題は学習の機会であり、問題と軽減策を文書化することで、将来の問題を回避できます。
ThoughtworksのSensible Defaults
長年にわたり、Thoughtworksは、私たちを成功に導いてきた一連の実践、パターン、ガイドライン、および一般的な優れたアドバイスのコレクションを蓄積してきました。ローカライズされた意思決定と自律性はThoughtworksの文化の鍵ですが、横方向の従業員が始められる「舗装された道」を提供したかったのです。これには、開発者、アーキテクト、ビジネスアナリスト、プロダクトマネージャー、プログラムマネージャー、エグゼクティブステークホルダーなどのさまざまな学部向けのデフォルトが含まれます。これらのそれぞれには、それぞれのチャット、メールグループ、コミュニティがあり、誰でも質問したり、フィードバックを求めたり、アイデアを共有したり、現状に挑戦したりできます。
開発のsensible defaultsには、多くの主要なプラクティスに関するドキュメントが含まれています。いくつかの例を次に示します
頻繁で継続的な統合
テスト駆動開発（TDD）
ペア開発
セキュリティの構築
高速で検証済みの自動ビルド
自動デプロイパイプライン
早期かつ継続的な展開
品質と負債の効率的な管理
本番環境向けに構築
迅速なフィードバック
迅速なフィードバックとは、変更が数日ではなく数分で成功したかどうかを確認できることを意味します。単体テストに合格したか、本番環境を壊していないか、顧客が構築したものに満足している可能性があります。
再現性
再現性とは、奇妙な不整合を生み出す手動タスクを削除することから得られる信頼性と予測可能性です。また、うまくいくはずだったことのトラブルシューティングよりも重要な活動に時間を費やしたいと考えています
シンプルさ
優れた仕事をするために必要な複雑さ以上の複雑さを含まないソフトウェアが必要です。私たちは、将来何が来るかではなく、今必要なものに合わせて構築します。しかし、私たちは、ソフトウェアが急速に変化して、来るべき要件を満たすことができるようにする選択をします。
↑デプロイ頻度
↓MTTR
↓変更のリードタイム
↓変更失敗率
ペアプログラミングを重要なオンボーディング手法として活用する
Thoughtworksチームは、既存のコードで作業を開始し、ビジネスドメインを迅速に学習できる速度の速さについて、クライアントの利害関係者からしばしば称賛を受けています。（それほどではない）これの秘訣はペアプログラミングです。Thoughtworksは、クライアントのコンテキストに適合したエクストリームプログラミング手法に大まかに従っており、ペアリングは重要な手法です。チームに新しいメンバーをオンボードするとき、彼らはプロダクトマネージャーと時間を過ごし、製品の目標とビジネスコンテキストを学びます。その後、彼らはすぐにチームの既存のメンバーとペアプログラミングを開始し、実際の機能を構築します。コードベースの他の領域を学ぶために、彼らは異なるストーリーでチームの異なるメンバーをローテーションします。
スタートアッププロジェクトの経験から、オンボーディング中のペアプログラミングは知識の伝達を加速し、学習文化を導入することがわかりました。その他の利点としては、コードスタイルと品質に関するチーム規範を作成し、チームメイト間の信頼と脆弱性を構築し、集合的なコード所有権を作成することが挙げられます。これらのことは他の方法でも達成できますが、ペアプログラミングは、私たちの意見では、最速で最も効果的な方法です。これらの手法は、設計、製品戦略、管理などの他の分野にも適用できます。
個人環境のセットアップ
開発者に環境をセットアップするための一連のインストール手順を提供し、彼らにそれを理解させるだけでは十分ではありません。理想的には、個人環境には、開発者が本番環境にデプロイし、デバッグするために必要なすべてが含まれている必要があります。プリインストールされているか、いくつかの操作でインストールされている必要があります。最初の週は、マネージャーまたはチームメイトが最初のデプロイメントを実行するのに適した時期です。このようにペアを組むということは、彼らが関係を築き、新しい従業員が経験する摩擦を見ることができることを意味します。良い習慣は、些細なタスクを実行して、環境とデプロイパイプラインが機能することを示すことです。たとえば、Etsyは、チームページに写真をデプロイすることをオンボーディングタスクとして使用しています。
環境によっては、会社全体のイメージまたはスクリプトを使用して作成され、チームや部門に合わせてカスタマイズされる場合があります。通常、最も効果的な方法は、開発者が合成データまたは難読化されたデータを使用して、本番環境と機能的に同等のコピーを持つことです。チームが成長するにつれて、環境はすべての開発者にコピーを提供するには複雑で高価になりすぎる可能性があります。その時点で、個人環境は、チームが働くビジネスドメインのサービスとUIに基づいている必要があります。
個人環境の場所は、ユーザーのラップトップまたはクラウド環境である可能性があります。この決定は、多くの要因に基づいています。開発速度が最も重要ですが、環境の違い、プライバシー、コンプライアンスも他の要因です。私たちのチームは、多くのクラウドサービス（サービスとしての機能など）を使用している場合、ローカルまたはスタブで開発バージョンを使用するのではなく、実際のサービスを使用してクラウドで個人環境を実行する方が良い場合があることを発見しました。これは、チームが決定しなければならないトレードオフです。すべてを個人のラップトップから遠ざけることも、データセキュリティに役立ちます。
オンボーディングプロセスから摩擦を取り除く
オンボーディングプロセスにおける摩擦とは、従業員が不必要に行わなければならないこと、あるいは不必要に遅く官僚的なプロセスを指します。オンボーディングは単一のプロセスではないため、1つのチームが完全に所有することはできません。オンボーディングには、人事、採用、IT、学習開発、リーダーシップ、採用、チームの仲間の間で緊密なパートナーシップと賛同が必要です。組織全体で特定の責任を持つ多くの人が、プロセスにおいて役割を果たす必要があります。
細部が重要であることがわかりました。たとえば、最初の週の終わりに自動的に送信されるアンケートや、学習管理システムで必須トレーニングを自動的に割り当てるスクリプトなどを含めることができます。自動化すればするほど、新規採用者のエクスペリエンスを保証することができます。しかし、すべてを自動化できるわけではなく、全員がプロセスの自分の役割を認識している明確に定義されたプロセスが必要です。
プロセスの継続的な改善
オンボーディングは、多くの利害関係者が関与する部門横断的な活動です。一般的に、統一されたメッセージと一貫したエクスペリエンスを作成するために、これらの機能を中央で調整する必要があります。Thoughtworksには、効果的なオンボーディングエクスペリエンスの作成と実行に専念する運用チームメンバーで構成されたFirst Year Experienceチームがあります。彼らはコンテンツの管理者として、重要なメッセージが現在の事業方向と一致していることを確認するだけでなく、オリエンテーションやその他のオンボーディング活動を促進します。小規模なスタートアップ企業の場合、この調整と実行は、運用部門のマネージャーのパートタイムの責任として管理できます。
以前の「製品 vs エンジニアリング」の記事（製品 vs エンジニアリングの記事）で述べたように、機能マネージャーがチームとして活動して全体的な成果を達成することの価値は、オンボーディングプロセスにも当てはまります。間もなく人員を増強しようとしている場合、またはオンボーディングが効果的でないという兆候が見られる場合は、プロセスに焦点を当てて最適化するためのワーキンググループを作成することをお勧めします。プロセスとコンテンツを理解することで、何をしているのかをより明確に理解できるというメリットもあります。
所有されるべき明確な部分があります。新しい従業員がビジョンを理解していることを確認することは、リーダーシップの一部であり、多くの場合、創業者の責任です。規模が拡大すれば、それは体系化されます。いずれにせよ、創業者は、個別にミッションを人々に思い出させる方法を見つける必要があります。新規採用者のブートキャンプの作成や最初の週のエクスペリエンスの設定には、多くの異なる参加者が関与しますが、運用担当者（コーディネーター）が運営します。
継続的に改善するために、誰かがフィードバックを収集して配布する責任を負う必要があります。ドキュメントが明確でない場合、またはシステムが完全にセルフサービスでない場合は、それらの改善タスクを追跡して完了する必要があります。これはおそらく「コーディネーター」によって管理されます。フィードバックは、新規採用者からのアンケート（3〜6か月後のアンケートを推奨）と、新しい採用者をチームに組み込んでいるラインマネージャーからの意見の募集を通じて収集できます。
摩擦を取り除く際にしばしば見られる罠は、「問題を表面的に隠蔽すること」です。何かが新規参入者にとって難しいことが判明した場合は、根本原因を探すことを忘れないでください。たとえば、アーキテクチャが理解しにくい場合は、ドキュメントが不十分であるか、断片的すぎるか、複雑すぎる可能性があります。
定性的なフィードバックに加えて、いくつかの定量的な指標（兆候のセクションで言及）が役立ちます。これらは主にアウトプットベースになります。新しい従業員はツールを使用して、要求された仕事を完了できますか？これらは、顧客のために彼らが創造している価値や、コードまたはデザインの品質についてはあまり教えてくれませんが、それでも、プロセスと環境における摩擦を発見するのに役立ちます。これらの指標は、個人のパフォーマンスではなく、エンジニアリング組織の集計として使用し、時間の経過とともに傾向を追跡することをお勧めします。
- 初回本番コミットまでの時間
- 従業員が一人でオンコールになるのはいつか
- 10回目の価値のあるコミットまでの時間
- プロダクトマネージャーの最初の顧客インタビュー
- デザイナーによる最初の検証済み実験
オンボーディングプロセスへの投資
フェーズ1
実験
小規模で緊密なチーム、正式なオンボーディングプロセスは不要
製品と技術設計を記録し、将来の従業員の理解に役立つ
フェーズ2
牽引力の獲得
運用主導の部門横断チームによるオンボーディングプログラムの作成
ワークステーションのセットアップ、環境の作成、CDパイプラインの作成を自動化します。
技術、製品、ビジネスを網羅したセルフサービスの知識管理アプローチを確立する
賢明なデフォルトプラクティスを作成する
フェーズ3
（急激な）成長
ラップトップの調達、従業員のフィードバック、退職面接、人事システムへの自動オンボーディングに関するプロセスを確立します。
チームが日々の摩擦を取り除くことを可能にする継続的改善プログラムを実装する
開発者エクスペリエンスに特化したプラットフォームチーム、KPIには初回デプロイまでの時間が含まれる
フェーズ4
最適化
オンボーディングプロセスとその継続的な最適化を処理するための専任スタッフ。
disparate bodies of knowledge の統合
新しい採用バッチに刺激を与えるために、オンボーディングへのリーダーシップの継続的な関与
