エンジニアリング組織の規模拡大

Stripe のエンジニアリングチームの拡大から得た教訓

はじめに

Stripe は、規模拡大について常に考えています。Stripe では、数百万のビジネスに対し年間数十億ドルを処理するため、製品の規模を拡大してきました。それに伴い、エンジニアリングチームの拡大も必要になりました。成長の早い企業は、できるだけ早急にエンジニアリングチームを作ろうとします。しかしながら、成長が早いと、サイロ化が生じる、エンジニアがユーザに与える影響が徐々に減る、変化するユーザのニーズ応じて仕事のやり方を速やかに変えることができないといったリスクがあります。

弊社では、意図的にエンジニアの増員ペースをユーザ基盤の成長よりも遅くし、チームのリクルートと育成に反復的なアプローチを取ることにしました。以前は、チームを小規模に保って 1 人あたりの投資を増やし、ニーズの変化に応じて仕事のやり方を速やかに変えることができました。エンジニアが 50 人の場合に上手くいくことが 10 人や 1,000 人の場合に上手くいくとは限らないため、会社の成長に応じて継続的に変更を加えられるよう、フィードバックと反復的思考の企業文化を育成してきました。

このガイドでは、弊社がこの過程で学んだことをいくつか紹介します。

リクルートと雇用

プロセスを継続的に発展させる

リクルートのプロセスと雇用のニーズは企業によって異なります。私が Stripe に入社した頃は、何十人もの被紹介者や新規求職者をサポートする専任のテクニカルリクルーターが 1 人しかいませんでした。それ以降、Stripe はリクルートプロセスを全面的に見直して改善・追加・変更を行い、エンジニアリングチームの規模をほぼ 4 倍にしました。このプロセスは 6 ~ 9 カ月程は上手くいきましたが、その後更新が必要になりました。リクルートプロセスを無難に実施して発展させるには、次のことを行う必要があります。

  • 組織のニーズに合ったリクルート計画を定義する
  • リクルートプロセスに一貫性を持たせて効率性と公平性を確保する
  • 候補者の体験を大切に: 結果がどうであれ、候補者には、会社やチームに対して良い印象を残さなければなりません。
  • 定期的にリクルートプロセスを見直して進捗状況を評価し、必要に応じて変更を加える

一貫したリクルートプラットフォームを構築する

一貫したリクルートは効率性を高め、偏見を防ぎ、雇用のレベルを高めます。重要なのは、候補者の見極め・評価・採用に用いるプロセスを明確に定義することです。一貫性が高いほど、結果が予測しやすくなり、データに基づいて何が上手くいっているかを理解しやすくなり、上手くいっていない部分を改善しやすくなります。弊社では、リクルートチームとともに新任の雇用マネージャーを対象に、定期的なトレーニングセッションを行っています。候補者にメールを送るタイミングや書面によるオファーの送り方などの詳細事項についても明確に文書化しておくと、新任マネージャーのトレーニングやベストプラクティスの共有に役立ちます。雇用マネージャー、リクルーター、面接官は、面接の過程で各自がどのような責任を負うか把握していなければなりません。

トレーニングセッションはあらゆるレベルの体験にとって重要です。他社でリクルートリーダーを務めた経験のある新任マネージャーでも、Stripe の雇用方針を正確に学ぶことが効果的だと言います。これにより、チームが自信を持って能率的に動けるようになると同時に、一貫性も保たれます。

チームが一貫したプロセスに従うよう、リクルートのプラクティスを文書化します。

弊社の面接プロセスは、業界調査と自社のベストプラクティスに基づいて作られました。質問事項の目的は、ホワイトボード上で高度なスキルを試験することではなく、現実世界の問題に候補者がどう取り組むかを理解することです。バグ潰しエンジニアリングの面接では、候補者と面接官が横並びに座り、候補者が選択したプログラミング言語で作業をしながら、オープンソースプロジェクトで過去に実際にあったバグを解決します。エンジニアリングマネージャーの場合はチームロールプレイにより、チームメイトと 1 対 1 の会話をしながら問題解決をシミュレーションします。

Stripe では、各面接の実施方法を明確に定義した指示書を用いて質問事項を標準化し、これらの質問事項を一貫した方法で評価して、候補者のスコアを比較しています。指示書には面接の目標を明記し、候補者のパフォーマンスを評価する明確な基準を示すと良いでしょう。面接の前に、すべての面接官が指示書を読み、評価するスキルの内容を把握します。弊社ではスキルごとに、さまざまな熟練度の候補者がしそうな返答を例示しています。また、面接官がフィードバックを返す際に指示書を確実に参照できるよう、社内の求職者トラッキングシステムに指示書を直接組み込んでいます。

次に、弊社が候補者のコミュニケーションスキル評価に用いている指示書の例を示します。

コミュニケーションスキル

  • 質問に明確に答えているか?
  • 特に質問されたときに、自分の業務について具体的な詳細を述べているか、それともチームや会社の業務について大まかに述べるだけか?
  • 対話中の質問やフィードバックに対処できているか?

面接の評価

  1. 候補者のコミュニケーションは散漫、一貫性がない、または明確でない。質問をしても詳細や具体的なことを言わない、あるいは、個人的な業務や貢献以外のことしか話さない。この候補者は、面接官と有意義な双方向対話に入れない可能性がある (テーマを変えるよう促しても無視するなど)。
  2. 候補者のコミュニケーションは、明確性が一貫していない。質問に詳しく答える場合もあるが、そうでない場合もある。あるいは、詳しく答えていても、それが高ポイントにつながらない (つまり、自分の業務以外に関する詳細が多い)。この候補者は、一貫性のある双方向対話ができない可能性がある (長く話すうちに答えが変わるなど)。
  3. 候補者のコミュニケーションは一貫して明確でポイントが高く、具体例や詳細を挙げていて分かりやすい。面接官と有意義な双方向対話をしている。
  4. 候補者のコミュニケーションは非常に明確で、全般的な主張を裏付ける具体的な詳細を述べている。自分の個人的な経歴や影響力のほか、自分が携わってきたプロジェクト/チーム/企業に関することも話している。この候補者は、面接官の話や質問に柔軟に対応できる。

明確な指示書の作成に加え、Stripe では一貫性と客観性を保つために無意識の偏見に関するトレーニングも始めました。また、標準化された質問事項を新しい候補者レビュープロセスにも組み込みました。このプロセスは、面接終了後に面接官や雇用マネージャーにフィードバックを返す際に用います。

候補者レビューは経験豊富なレビュアーとの定期ミーティングで、すべての面接結果を精査することを目的としています。各セッションでは、レビュアーが結果に目を通し、個々の面接官にフィードバックを返し、プロセス全体の改善方法を提案します。レビュアーは決定事項を後から批判するのではなく、各自が詳細なフィードバックを残し、社内で見る情報のみに基づいて意思決定を行うようサポートします。

候補者レビューは、最初は小規模でした。私は個人的に 6 カ月間すべてのセッションに参加して、新任レビュアーのトレーニングを手伝い、フィードバックを読み、直に観察したことから学びました。短い期間でしたが、驚くほどの変化が見られました。エンジニアは自分の記録を誰かに個人的に読んでもらえることを喜び、詳細レベルと指示書遵守の両方の点で、フィードバックの品質と一貫性が短期間で向上しました。何よりも、このことは面接自体の改善に役立ちました。

明確な雇用目標と効果的なプロセスを定義する

明確な目標を定めると、成功の度合いを測り、必要に応じてプロセスに適切な変更を加えることができます。応募してきた求職者や被紹介者を受動的に受け入れているだけの企業は、今本当に必要な人材ではなく、ドアから入ってきた人を闇雲に採用してしまうことがあります。

Stripe では、設立から数年は主に、複数の分野で効率的に仕事をこなせるゼネラリストのエンジニアを雇用していました。その後、特殊性の高い問題 (セキュアな資格情報ストレージインフラの拡張や、国際的なモバイル決済フローの構築など) に取り組むことになり、そのときに必要なスペシャリストを呼び込むためにアプローチの変更が必要になりました。私はフロントエンドスペシャリストの雇用マネージャーとして候補者の面接を頻繁に行いましたが、「API 企業の Stripe にフロントエンドエンジニアは不要ではないか」と言われることがありました。

私はある面接で、Stripe が API 開発以外の問題にどう取り組んでいるかを説明しましたが、候補者がすぐに興味を失ったのが分かりました。入社後にどのような仕事に就くのかまったくイメージできなかったのです。私は急いでラップトップを取りに行き、30 分かけて自社の Web ダッシュボードとモバイルダッシュボードの実際のデモを候補者に見せました。これが功を奏し、候補者はすぐに質問や製品の提案をし始めました。彼らは面接後、ほどなくして入社しました。弊社ではこの経験を踏まえて、即興を必要としないフロントエンドエンジニアの新規候補者向けの面接体験を設計しました。現在 Stripe には多数のフロントエンドエンジニアが在籍しており、プロダクトチームに直接配属されている人もいれば、より良いフロントエンドコードを誰でも素早く簡単に記述できる共有コンポーネントやインフラの構築に携わっている人もいます。異なる製品分野に新出する際は、最初にゼネラリスト向けに構築した構造を、特殊性の高い職種に合わせて調整することが重要です。

弊社では、リクルート業務の刷新方法を 1 つずつ理解するために、少数の職種 (インフラストラクチャ、フロントエンドエンジニアリング) から始めました。現在は、Android から機械学習セキュリティまで、さまざまな分野に雇用を広げています。このような変更によりオファーの受け入れ率が着実に向上し、現在はあらゆる分野のスペシャリストが在籍しています。次のような詳細が、リクルートプロセスのあらゆる部分に影響を与えます。

  • 各種業務の説明を公開する
  • どの職種にどのリクルーターを配属するかを決定する
  • 各職種に特化した面接の質問事項、指示書、候補者の準備ガイドを作成する

Stripe では最近、Elements という決済フロー用の UI ツールキットをリリースしました。Elements チームは、セキュリティ、フロントエンドエンジニアリング、ユーザ体験のスペシャリストの経験を活かして、iframe によるカード詳細の安全な分離、ブラウザ固有のバグの解決、インターナショナリゼーションの追加、最新の JavaScript API 設計の組み込み、コンバージョンフローの最適化などの幅広い課題に取り組みました。

候補者の面接体験を向上させる

面接プロセスにより、会社とエンジニアリングチームの業務活動に対する全候補者の第一印象が決まります。弊社では、面接での候補者のパフォーマンスがどうであれ、候補者全員に良い印象を与えるよう努めています。プロセスのステップごとに一貫したタッチポイントを提供し、面接の準備に役立ち、適切な想定事項を設定し、面接に臨むすべての候補者が面接に成功して最善の成果を示すことができようにするためのベストプラクティスを考案しました。

弊社では最近、リクルートファネルの理解を深めるために、サンフランシスコ・ベイエリアの複数のリクルートチームを対象に社内調査を実施しました。ベンチマークによると、これらのチームのリクルートファネルにおけるオンサイト面接からオファー受け入れまでの受け入れ率は 12 ~ 20% です。大半の企業は、この数字の達成に重点を置き、その後その数値を最適化しようとします。忘れがちなのは、1 人雇用するたびに、面接を受けた他の 4 ~ 7 人が別の会社に就職することになる点です。つまり、再び話す機会が二度となくても、彼らは企業や面接官に対して何らかの印象を持って出ていきます。企業は大抵、候補者のソーシャルネットワークやプロフェッショナルネットワークから人材を雇用します。良い印象を残せば、その候補者が最終的にチームに加わらなかったとしても、優秀な求職者の呼び込みに役立つ可能性があります。

面接プロセスは、候補者が企業と関わり合う唯一の機会となる可能性があるため、すべての候補者に良い印象を与えることが重要です。

弊社では面接の前に、Stripe の企業文化の理解と面接の準備に役立つガイドを提供します。エンジニアはさまざまなプログラミング言語の中から好きな言語を選択し、自分のラップトップと開発環境を使うことができます。面接後は、候補者の体験を把握して改善方法を見極めるために、匿名のアンケートを候補者に送信しています。

弊社では Culture Amp アンケートを利用して、面接候補者とのフィードバックループを完結させています。

弊社では、最終的に Stripe に就職しない人も含め、すべての候補者と面接後に話をしています。弊社からのオファーを断った人には、その選択に至った理由と当該職種についての感想を聞くために電話で話を聞きます。不採用になった候補者については、候補者が面接体験から学べるよう、リクルーターが候補者に個人向けのフィードバックを提供します。

弊社のアンケートによれば、候補者が全般的に Stripe での面接に良い印象を持っていることが分かりました。不採用になった人でも、上記の質問で自身の面接体験について平均で 5 点中 4.1 点を付けています (オファーを得た人の評価は平均 4.5 です)。さらに嬉しいことに、Stripe に就職しなかった候補者が後で友人や同僚を紹介してくれることもあります。

ヒントと演習

  • 面接でよく尋ねる質問事項に関する指示書を作成し、応募者トラッキングシステムに組み込む。
  • 面接準備ガイドを作成し、面接を受ける候補者と共有する。
  • 面接体験について尋ね、改善方法を見極めるための簡単なアンケートを用意する。

トレーニングとオンボーディング

新入社員の能率を上げる

成長中の組織は新入社員の雇用には力を入れますが、働き始めた新しいチームメイトのサポートは見落としがちです。急成長するスタートアップで働くのは敷居が高く、新入社員はガイダンスがなければ、生産性向上に必要なことを学ぶために 2 倍の努力をしなければなりません。

Stripe も設立当初は、オンボーディングに十分な投資をしていませんでした。当時を知る従業員は、入社当初の経験が今後成功するか失敗するかを決めていると感じていました。私が Stripe に入社した頃は、数人のチームメイトが、新入社員にサポートがないのは試されているのだと説明してくれました。彼らは、会社がこの方法で入社した従業員を再評価していると思い込んでいました。これは事実ではありませんでしたが、オンボーディングプログラムに十分な投資をしないのは、暗に自力で成長しろと言うようなもので、間違いが社内基準になってしまいかねません。現在 Stripe では、全新入社員のオンボーディングと影響力向上にかなりの時間とエネルギーを費やしています。

トレーニングとオンボーディングの専用プログラムに投資

新入社員にとって、最初の数カ月は重要です。1 週目からエンジニアに機能作成を頼みたいところですが、オンボーディングとトレーニングに投資をした方が新入社員を安心させ、生産性を高めることができます。

弊社では、全新入社員を対象とした Stripe 101 を開発しました。これは、新入社員に会社全体を紹介する全般的なオンボーディングプログラムです。従業員はわずか数週間で複数のクラスに参加し、Stripe の共同創設者と顔を合わせ、Stripe の組み込みを構築し、サポートチケットに回答することで、Stripe について学びます。さらに、社内のさまざまな部門の社員と早期にコラボレーションする機会も得られます。これは全社規模で実施されており、82 名のインストラクターが 30 以上のセッションを担当しています。昨年は、Stripe の 200 名以上の従業員がこのプログラムを受けました。従業員アンケートでは、Stripe 101 は良い経験になり、重要な情報を非常に効果的に共有できると評価されています。

  • Stripe の新入社員の 100% が、Stripe 101 修了までに少なくとも 3 つの Stripe サービスの機能概要を言うことができました。
  • Stripe の新入社員の 94.5% が、入社 1 週目は良い経験になり、101のカリキュラムで時間を有効利用できたと実感しました。
  • Stripe の新任エンジニアの 90% が、プログラム修了までに Stripe スタックのコンポーネントを理解できました。
  • 新入社員はプログラム修了と同時に、Stripe のさまざまな部門で働く同僚とのネットワークを築いています。これにより、彼らがその後社内のプロジェクトに取り組む際に、個人的に連絡を取ることができます。たとえば、新機能の構築時に、ユーザ運用チームや販売チームに既に知り合いがいれば、早い段階でフィードバックを求めることができます。

Stripe 101 は全般的な知識を得るには効果的ですが、新任エンジニアにはさらにオンボーディング体験が必要だと分かりました。彼らはさまざまな従業員と顔合わせできることには満足していましたが、テクニカルチームと仕事をすることやコーディングに取り掛かることには不安を感じていました。そこで、Stripe の主要アプリケーションのコードベースに実際に生じた問題を解決することで新任エンジニアを自社のテクニカルスタックに慣れさせる、新たなプログラムを開発しました。弊社ではこれを /dev/start と呼び、まずは少数の新任エンジニアとボランティアのメンター、チームのバックログから抜粋したプロジェクト、1 対 1 のフィードバックからなる小規模のパイロット版から始めました。その後数カ月で複数の組織に規模を拡大し、まもなくエンジニアリング全体に用いられるようになりました。

現在では、新入社員を 3 ~ 4 週間、一時的な仮想チームに分けています。チームは専任のメンターと一緒に働き、実際のツールや製品の機能改善に携わりながら開発プロセスについて学びます。Stripe の熟練エンジニアはメンターとしてチームに協力し、プロジェクトを扱いやすいタスクに分割し、技術的な質問と製品に関する質問の両方に答え、コードをレビューし、エンジニアリングの他の部分との橋渡しをすることで、プロジェクトのリーダーシップとメンターシップを体験できます。

/dev/start はメンターと新入社員をつなぎ、グループプロジェクトに携わる新入社員のオンボーディングをサポートします (全員に限定版 T シャツが配られます)。

ソフトスキルと企業文化を忘れない

心理的安全性とは、リスクを気にせず知識を共有してサポートし合える、チームメンバー間の共通認識のことを言います。心理的安全性は、Google の Project Aristotle (能率的なチームの秘訣を探る研究) でチームの成功に最も重要な要素であることが分かりました。

Stripe では、一般的なコミュニケーションとチーム固有のプラクティスの両方を扱った企業文化とグループの基準に関するガイドを作成することで、心理的安全性の確立を目指しています。Stripe 101 には「Stripe でのコミュニケーション」というクラスが用意されています。このクラスでは、社内のメーリングリスト、メールに関するベストプラクティス、バグトラッカーのほか、明確でないコミュニケーションパターン (ミーティングのスケジュール方法など) についても説明します。カレンダーに関する基準は一般常識のように思われがちですが、企業文化に関する重要な知識が含まれています。これらを理解することは、恥ずかしいスケジュールミスを避けたり、重要イベントを見つけたりするのに役立ちます。

エンジニアリングチームは、特定のツール (GitHub や JIRA など) やコードレビューなどの一般プラクティスに関する専門ガイドを提供しています。これらのガイドは規範の役目をし、チーム全体が事前にプロセスについて合意することで進行時の議論や混乱を減らすことができます。また、セルフサービスの文書化により、従来の口頭連絡への依存を減らして、迅速な規模拡大に役立てることもできます。

Stripe でのメール規則

  • 緊急でないメッセージにはメールを使用します。すぐに返答が必要で、相手がメールを確認するまで待てない場合は Slack を使用します。
  • これから席を外す場合は、必要に応じて、返信の予定時刻や代わりの担当者を相手に伝える自動応答メッセージを設定します。これは必須ではなく、各自の判断に任せています。
  • 1 つの作業単位が終了したら、shipped@ メールを送信します。
  • 人のスレッドに不必要に参入しないようにします。納得のいくまで読むことは構いませんが、やりすぎは禁物です。有意義な貢献ができる場合は、礼儀をわきまえてリストに加わります。そうでない場合は、他の人の進行を妨げてはなりません。
  • Stripe でオープンコミュニケーションを機能させるには、Stripe の全従業員が安心できる環境をつくり、推進することが不可欠です。人のスレッドを不必要に読んで、必要以上に意識させることは、オープンコミュニケーションの妨げになります。ただし、他の従業員 (特に比較的新しい従業員) に、業務の遂行やリストの使用を軽く促すことは構いません。これは必ずしも気分の良いものではなく、ときには勇気も必要ですが、認知したリスクに見合うだけのメリットがあります。

これは、新入社員に弊社のコミュニケーション規則を理解してもらうために用いるガイドの一例です。

ヒントと演習

  • 自社および自社製品について概説するオンボーディングクラスを 1 ~ 2 つ実施する。
  • チーム向けの企業文化またはグループ基準指向のガイド (メール、カレンダー、コードレビューの実行方法など) を作成する。

エンゲージメントと人材維持

自分のチームに投資する

社員の満足度は多くの場合、社員が自分の仕事の影響力を理解していることと、日々の意思決定に自主性を感じていることの 2 点が大きく影響します。その上でチームが成功するためには、チームメンバーが長期間従事できるような構造も必要です。それには、フィードバックに積極的に耳を傾け、個人が成長するための明確な道筋を定め、最善を尽くしてチームをサポートするリーダーをトレーニングする必要があります。

新入社員の雇用とオンボーディングが済んだら、短期的な成果と長期的なチームの生産性のどちらに重点を置いても構いません。急成長する企業では状況が目まぐるしく変わり、そもそもの決定の経緯を覚えていないのに当初の意思決定の影響がいつまでも続くことがあります。創業時からの社員は、新入社員よりもはるかに多くの知識があり、能率良く仕事ができ、技術的な知識と組織を渡り歩く術の両方を身につけた優秀なメンターになり得ます。それと同時に彼らは、社内やテクニカルスタックの中で負担や閉塞感を感じ始める可能性があります。チームのために適切なサポート構造を築き、創業時からの社員と協力してこのような事態を回避しましょう。

生産性をエンゲージメントと間違えない

私は、以前の会社で初期のマネージャーとして、生産性の高い協力型のチームをサポートしていました。ある日、キャリアの長いエンジニアが私のところへ来て、そっと辞職願を手渡しました。彼は常に質の高い仕事をし、難しいプロジェクトも引き受けてくれ、新入社員やインターンの指導も行っていました。辞職の理由を尋ねたところ、彼は「やりがいを感じなくなった」と言いました。彼は自分が会社にとって重要な仕事をしていると知りながらも、自分の影響力を高めて新しいスキルを習得する方法を見いだせませんでした。私は今では、これをサプライズ辞職と呼んでいます。サプライズ辞職とは、仕事に行き詰まりを感じ、今の会社で新しいが影響力の低そうな役割を引き受けるより、意欲的な機会を求めて退職した方が良いとの結論に達するケースを指します。

私はすぐに、彼が出世に関するシンプルな会話の中で自分の気持ちを打ち明けていたにもかかわらず、警告のサインに気付かなかったと悟りました。社員が働き続けたいと考えるのは、個人的な成長を感じるときです。これをサポートするには、日々の生産性よりも先を見て、適切な質問をするようにします。弊社では年に 2 回、エンゲージメントの度合いを測る StripeSat という従業員アンケートを実施しています。前回のアンケートで尋ねた質問の中から、特に注意すべきものを紹介します。

  • 職場で学習や成長の機会はありますか? 学習または上達したいことは何ですか?
  • 3 年後も Stripe で働いていると思いますか? その理由は何ですか?
  • Stripe にキャリア向上の機会はあると思いますか (職位を上げる、責任を増やす、人事異動など)? 思わない場合、どのような機会に意欲を感じますか?

異動や学習をサポートする道筋をつくる

社員が新たな機会を見つけ、自主的にプロジェクトを立ち上げられるよう支援すれば、彼らは会社におけるキャリアや役割を形作ることができます。Stripe では、新しいチームを公示し、社員にローテーションで新規プロジェクトに参加するよう奨励し、独創性を養うためにハッカソンを実施しています。

従業員はローテーションで新しい言語を学び、スタックの担当外の部分を探究しています。中には、別のチームに永続的に移る場合もあります。過去 6 カ月間で、12 名以上のエンジニアが、iOS モバイル開発、決済 API のコア機能、機械学習アプリケーションなど全く異なるプロジェクトにローテーションで携わりました。また、人事異動のメリットが大きい業務 (新規チームの立ち上げや、複雑な技術的問題への取り組みなど) にも重点を置いています。このような取り組みを重視すれば、キャリアの長いエンジニアを、彼らが最も力を発揮できるプロジェクトに携わらせることができます。

新しいことを試すのに、数週間もの計画や新チームの発足は必要ありません。弊社では、新しいツールや製品の開発を奨励するために社内ハッカソンも実施しています。最近のハッカソンでは複数のオフィスから 80 名が参加し、Stripe Elements での RTL 言語 (右から左へ記述する言語) のサポートや、従業員の生産性を高める社内ツールを始めとする 7 つのプロジェクトを社内外のユーザに提供しました。

ハッカソンは、Stripe の社内ディレクトリにこの座席表のような便利な社内ツールを作成するのに役立ちます。Home の詳しい利用法については、こちらのブログ投稿をご覧ください。

フィードバックを集めて対応する

会社の成長とともに社員のフィードバックに対応するには、拡張性のあるアプローチと、個人の意見に注意深く耳を傾けることが必要です。社員は常に社内の問題に気付いていますが、自分が見ている状況を効果的に変化させる方法をいつでも知っているとは限りません。弊社では、次の 3 つのステップで社員のフィードバックに対応しています。

  1. 問題を特定する
  2. 建設的なフィードバックを集める方法を策定する
  3. フィードバックに対処し、結果を出す

2 年前、エンジニアたちが押し並べて「Stripe の開発環境は遅くて非効率だ」と訴えていました。そこで、社内開発者の体験に重点を置くため、熟練のエンジニアからなるチームを発足しました。彼らには高い洞察力と専門知識がありますが、影響力の大きいプロジェクトの見極めに苦労していました。チームは方向性を決めるために開発者体験に関するアンケートを実施し、次のような質問をしました。

  • 先週、開発プロセスに関する問題のせいで何時間無駄になりましたか?
  • 社内のツールやインフラについて、エンジニアの生産性を高めるために会社ができることを 1 ~ 2 つ挙げてください。
  • 現在担当しているコードベースで、本来あるべき状態よりも難しくなっていることは何ですか?

アンケート結果から、より迅速で信頼性の高い「編集・同期・テスト」ループに対する要望が最も (2 倍も) 多いことが判明しました。チームはこの点を重視し、コードの同期、再度読み込み、テストのスピードと信頼性を高める一連のプロジェクトに取り組みました。数カ月後に再び実施したアンケートの結果では、これらの点に関する満足度が 50 ~ 80% 向上していました。この取り組みによってチームとユーザ間の前向きなフィードバックループが生まれ、エンジニアは自分たちの意見が届いていると感じるようになりました。それ以降、開発者体験に関するアンケートを四半期に一度実施し、結果から学び続けています。

ヒントと演習

  • 発足したい具体的なチームや、熟練者の人事異動を必要とする業務について明記した社内求人掲示板を作る。
  • ハッカソンのパイロットプログラムを考案する。1 カ月や数週間など、一定の期間にわたる場合もあります。
  • 社内アンケートを実施し、フィードバックに応じて取り組むべきプロジェクトを 1 つ特定する。

まとめ

組織の発展において、チームをどのように拡張するかが、企業文化、生産性、社員エンゲージメント、さらにはビジネスの成功に多大な影響を及ぼします。成長の早い企業は状況が目まぐるしく変化するため、今日上手くいったことが明日も上手くいくとは限りません。ここで紹介したプラクティスは今までのところ弊社の規模拡大に役立っていますが、今後も反復を継続し、成長に応じて新たなプラクティスを考案していきます。ご紹介した教訓が皆様の規模拡大プロセスに役立ち、共有できれば幸いです。

ガイド一覧に戻る
You’re viewing our website for Malaysia, but it looks like you’re in the United States. Switch to the United States site