Stripe では、スケールについて常に考えています。数百万の企業のために年間数十億ドルを処理できるよう製品を拡張する中で、エンジニアリングチームの規模も拡大する必要がありました。急成長する企業には、できるだけ早くエンジニアリングチームを構築したいという誘惑があります。しかし、急速な成長には、サイロの形成、エンジニア一人あたりのユーザーへの影響の長期的な減少、そして変化するユーザーニーズに迅速に対応するための柔軟性が制限されるなどのリスクが伴います。

私たちは意図的に、ユーザーベースの成長よりも遅い速度でエンジニアを追加し、代わりにチームの採用と育成に反復的なアプローチを取ることを選択しました。チームを小規模に保ち、各メンバーへの投資を増やし、ニーズの変化に応じて柔軟に働き方を変えることができました。50 人のエンジニアに有効な方法が、10 人や 1,000 人には当てはまらないこともあるため、私たちはフィードバックと反復的思考の文化を築き、成長に合わせて継続的に変化を続けられるようにしています。

このガイドでは、その過程で学んだことのいくつかについて説明します。

採用・雇用

プロセスを継続的に進化させる

すべての企業の採用プロセスと採用ニーズはそれぞれ異なります。私が初めて Stripe に入社したとき、専任の技術採用担当者は 1 人だけで、数十件の紹介と新規応募をサポートしていました。それ以来、採用プロセスのほぼすべての要素を改善・追加・置き換え、エンジニアリングチームの規模はおよそ 4 倍に拡大しました。私たちは、プロセスを更新する前に、約 6〜9 か月間は安定して機能していることを確認しています。採用プロセスを安全に試行し、進化させるためには、次の点が重要です。

• 組織のニーズを満たす採用計画を策定する。
  
• 採用プロセスに一貫性を持たせ、効率性と公平性を確保する。
  
• 候補者の体験を軽視しないこと。結果がどうであっても、会社やチームに対して良い印象を残すよう努める。
  
• 採用プロセスを定期的に見直し、進捗を評価して必要に応じて修正する。
  

一貫した採用プラットフォームを構築する

一貫した採用活動は効率を高め、偏見を防ぎ、採用基準を引き上げます。候補者の特定・評価・採用に用いるプロセスを明確に定義することが重要です。一貫性を導入すればするほど、結果をより予測可能にでき、データを活用してうまく機能している点を把握し、改善すべき点を特定できます。私たちは、採用チームと並行して新任マネージャー向けの定期的なトレーニングセッションを実施しています。明確なドキュメントは、新任マネージャーの教育やベストプラクティスの共有に役立ちます。たとえば候補者へのメール送信タイミングや、書面によるオファーの送付方法などの細部に至るまでです。すべての採用マネージャー、採用担当者、面接官は、面接パイプラインにおける自身の責任範囲を把握しています。

トレーニングセッションは、経験レベルを問わずすべての人にとって価値があります。他社で採用活動を主導した新任マネージャーでさえ、Stripe が採用にどのように取り組んでいるかを正確に学べることの有用性を実感しています。これは、一貫性を重視することと同じくらい、自分のチームに自信と成果をもたらす取り組みでもあります。

面接プロセスの設計は、業界調査と自社のベストプラクティスに基づいています。私たちの質問は、ホワイトボードで示すような難解なスキルをテストするのではなく、人々が現実世界の問題にどのように取り組むかを理解することを目的としています。Bug Squash エンジニアリング面接では、候補者と面接官が並んで座り、候補者が選択したプログラミング言語で作業しながら、オープンソースプロジェクト内の実際のバグを解決します。エンジニアリングマネージャー向けには、チームメイトとの 1 対 1 の会話中に問題を解決するシミュレーションとして、Team Role Plays を使用します。

各面接の実施方法を正確に定義し、それらの質問を一貫して評価し、候補者間のスコアを比較できるように、書面によるルーブリックを使用して質問を標準化しています。良いルーブリックは、面接の目的を明確にし、候補者のパフォーマンスを評価するための明確な基準を提供します。面接の前に、すべての面接官はルーブリックを読み、どのスキルを評価するのかを理解します。各スキルについては、習熟度の異なる候補者がどのように応答するかの例を提示します。また、ルーブリックは applicant tracking system (応募者追跡システム) に直接統合されており、面接官はフィードバックを提供する際に常に一貫して参照できます。

候補者がどれだけ効果的にコミュニケーションできるかを評価するために使用するルーブリックの例を以下に示します。

明確なルーブリックを構築することに加えて、私たちは 無意識の偏見 トレーニングを開始し、一貫性と客観性を維持するためのトレーニングを開始しました。また、標準化された質問を、新しい 候補者レビュー プロセスに組み込みました。このプロセスは、面接完了後に面接官や採用担当者へフィードバックを提供するために使用しています。

候補者レビューは、すべての面接結果を確認するために行われる、経験豊富なレビュー担当者との定期的なミーティングです。各セッションでは、レビュー担当者が結果を確認し、個々の面接官にフィードバックを提供し、プロセス全体を改善する方法を特定します。レビュー担当者は決定を推測することはありませんが、全員が十分に詳細なフィードバックを残し、見える範囲の情報のみに基づいて決定を下すようにします。

候補者レビューは小規模に始まり、私は個人的に 6 か月間すべてのセッションに参加し、新しいレビュー担当者のトレーニング、フィードバックの確認、直接の観察からの学習を支援しました。短期間でこれほど大きな変化を生み出せたことは驚くべきことでした。エンジニアは、自分のメモを誰かが実際に読んでくれていることを高く評価し、フィードバックの質と一貫性が、詳細さとルーブリックの遵守の両面で向上するのを実感しました。重要なのは、この取り組みが面接そのものの改善にもつながったという点です。

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

明確な目標を持つことで、成功を測定し、必要に応じてプロセスに適切な変更を加えることができます。インバウンド応募や紹介などの受動的な採用経路に主に依存していると、今本当に必要な人ではなく、たまたま応募してきた人を雇ってしまう可能性があります。

Stripe の立ち上げから数年間、私たちは主にスタック全体で効率的に作業できるジェネラリストエンジニアを採用していました。安全な認証情報ストレージインフラのスケーリングや、国際的なモバイル決済フローの構築など、より専門的な課題に取り組むようになるにつれて、当時必要としていたスペシャリストを惹きつけるために採用アプローチを変更する必要がありました。フロントエンドスペシャリストの採用マネージャーとして、私は候補者から「Stripe にはフロントエンドエンジニアは必要ない。あなたたちは API 会社です。」と言われることがよくありました。

ある面接で、私は API 開発以外の問題にどのように取り組んでいるかを説明していましたが、候補者の興味をすぐに失っていることは明らかでした。彼らは、参加後にどんな業務に携わるのかを具体的にイメージできていなかったのです。私はラップトップを取りに走り、約 30 分間にわたって Web ダッシュボードとモバイル・ダッシュボードのライブデモを見せました。私のプレゼンはうまくいき、彼らはすぐに質問し、製品提案を始めました。その後、面接を経て彼らは入社しました。この経験をきっかけに、私たちは即興対応を必要としないフロントエンドエンジニア向けの新しい候補者エクスペリエンスを設計するようになりました。現在、Stripe には多くのフロントエンドエンジニアが在籍しており、製品チームに直接所属している人もいれば、誰もがより優れたフロントエンドコードを迅速かつ容易に書けるようにする共有コンポーネントやインフラを構築している人もいます。さまざまな製品分野に拡大する際には、ジェネラリスト向けに最初に構築した構造を引き継ぎ、それをより専門的な役割に合わせて調整することが重要です。

私たちは、少数の役割 (インフラストラクチャ、フロントエンド エンジニアリング) から始めて、採用業務を 1 つずつ再構築する方法を理解しました。現在、さまざまなパイプラインで採用しています。Android から 機械学習、セキュリティ まで多岐にわたります。これらの変更によって、オファーの受け入れ率は着実に向上し、現在ではすべてのパイプラインにスペシャリストが在籍しています。こうした各詳細は、以下を含む採用プロセスのあらゆる部分に影響しています。

• さまざまな職務記述書を公開する
  
• どの採用担当者をどの役割に配置するかを決定する
  
• 各役割に特化した面接の質問、ルーブリック、候補者準備ガイドを作成する
  

立ち上げ時にリリースした Elements は、支払いフロー用の UI ツールキットです。Elements チームは、セキュリティ、フロントエンドエンジニアリング、ユーザーエクスペリエンスにわたる専門家の総合的な知見を活かし、iframe によるカード情報の安全な分離、ブラウザ固有のバグ修正、国際化対応の追加、最新の JavaScript API 設計の導入、コンバージョンフローの最適化など、幅広い課題に取り組むことができました。

優れた候補者エクスペリエンスを構築する

面接プロセスは、会社やエンジニアリングチームの運営方法に対する候補者の第一印象を形づくります。私たちは、面接の出来にかかわらず、すべての人に優れた体験を提供できるよう努めています。そのために、プロセスの各段階で一貫したタッチポイントを提供し、候補者の準備を支援し、適切な期待値を設定し、バーチャルでも対面でも、すべての候補者が平等に面接を成功させ、自身の最良の仕事を示せるようにするためのベストプラクティスを開発しました。

採用ファネルをより深く理解するために、私たちは最近、サンフランシスコ・ベイエリアのいくつかの採用チームを対象にプライベート調査を実施しました。これらのベンチマークによると、これらのチームの採用ファネルでは、オンサイト面接から内定受諾までの受諾率が 12〜20％ となっています。多くの企業は、この数値の達成と最適化に注力しています。しかし、3〜7 人の候補者のうち少なくとも 1 人は他社に就職し、その際に面接での体験を持ち帰っていることを忘れがちです。こうした候補者たちは、あなたの会社や価値観を暗黙的に体現しており、再び会話する機会がなくても、あなたのブランドを代表する存在になります。候補者のソーシャルネットワークや専門的ネットワークから人材を採用する可能性は非常に高く、良い印象を残せば、チームに参加しなかった人でさえ優れた紹介を生み出す助けとなります。

面接の前に、Stripe の文化を理解し、面接準備に役立つガイドを共有します。エンジニアは、複数のプログラミング言語から選択し、自身のラップトップと開発環境を使用できます。面接後には、候補者の体験をより詳しく把握し、改善点を特定するために、匿名のフォローアップアンケートを送信します。

面接後は、Stripe で働くことにならなかった候補者も含め、すべての候補者とお話しします。私たちは、オファーを受け入れなかった方に対して、その選択理由や役割への印象を理解するための電話をスケジュールします。オファーを出さない場合でも、採用担当者は候補者に個別のフィードバックを提供し、経験から学ぶ手助けをします。

全体的に、当社の調査では、候補者が Stripe での面接を良い経験と感じていることが明らかになっています。内定を得なかった人は、上記の質問に対して自分の経験を 5 点満点中平均 4.1 と評価しています (内定を受けた人は平均 4.5)。さらに注目すべきことに、Stripe に入社しなかった候補者が、後に友人や同僚を紹介してくれることも多くあります。

ヒントと演習

• よく聞かれる面接質問のルーブリックを作成し、応募者追跡システムに統合します。
  
• 面接準備ガイドを作成し、新しい候補者と共有します。
  
• 簡単なアンケートを設定し、面接体験とその改善方法について学びます。
  

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

新入社員を効果的に立ち上げる

成長中のチームは新入社員の採用に懸命に取り組みますが、入社後の成功を支援することを見落としがちです。急成長中のスタートアップに参加することは大きな挑戦であり、十分な指導がなければ、新入社員は生産性を上げるために必要な知識を身につけるのに倍の努力を強いられます。

Stripe の初期には、オンボーディングに十分な投資を行わなかったという誤りを犯しました。従業員は、立ち上げ期間を「沈むか浮くか」の経験だと捉えていました。私が初めて Stripe に入社したとき、何人かのチームメイトはこのサポート不足を「テスト」と表現し、会社が入社後に全員を再評価する方法だと思っていました。実際にはそうではありませんでしたが、オンボーディング・プログラムに十分な投資を行わなかったことで、社員を一人でやらせるという暗黙のメッセージを送ってしまっていたのです。こうした誤りが、偶発的に会社の慣習となるのは容易です。現在では、オンボーディングに多くの時間とエネルギーを投入し、新入社員全員がより大きな影響力を発揮できるよう支援しています。

専用のトレーニングおよびオンボーディング プログラムに投資する

最初の数か月は、新入社員にとって極めて重要です。エンジニアに入社初週から機能開発を任せたくなるものですが、オンボーディングとトレーニングに投資することで、チームメンバーの満足度と生産性を高めることができます。

すべての新入社員を対象に、全社の新入社員をつなぐ包括的なオンボーディングプログラム「Stripe 101」を開発しました。わずか数週間で、参加者はクラス受講、共同創業者とのミーティング、Stripe 連携の構築、サポートチケット対応を通じて Stripe について学びます。また、社内のさまざまな職種の人々と早期に協働する機会も得られます。このプログラムは大規模に運営されており、組織全体から集まった 82 名以上の講師が 30 以上のセッションを実施しています。昨年は 200 名を超える Stripe 従業員がこのプログラムに参加しました。従業員調査の結果、Stripe 101 は非常に有意義な体験であり、重要な情報共有において卓越した効果を発揮していることが示されています。

• Stripe の新入社員の 100% が、Stripe 101 修了時点で少なくとも 3 つの Stripe 製品の機能を説明できました。
  
• Stripe の新入社員の 94.5% が、入社初週を有意義な経験だったと感じており、Stripe 101 のカリキュラムは時間を有効に活用できる内容だったと回答しています。
  
• Stripe の新入社員エンジニアの 90% が、プログラム修了時点で Stripe スタックの構成要素を理解していました。
  
• 新入社員は、Stripe 内のさまざまな部門で働く同僚とのネットワークを形成したうえでプログラムを修了します。これにより、今後のキャリアでプロジェクトに取り組む際、より個人的なつながりを通じて組織内をスムーズに進めることができます。たとえば新しい機能を開発するとき、ユーザー運用チームや営業チームの知り合いに早期のフィードバックを求めることができるのです。
  

Stripe 101 は汎用的な知識を得るのに役立ちますが、新しいエンジニアには追加のオンボーディング体験が必要であると私たちは考えました。彼らは会社全体の人々と交流することを楽しんでいましたが、技術チームと過ごし、コードに没頭することを望んでいました。そこで私たちは、メインアプリケーションのコードベースにある実際的な課題を解決することで、技術スタックを紹介する新しいプログラムを開発しました。これを /dev/start と名付け、少数の新入エンジニア、ボランティアのメンター、チームのバックログから選ばれたプロジェクト、1 対 1 のフィードバックを取り入れた小規模なパイロットとして開始しました。数か月以内に複数の組織に拡大し、やがてエンジニアリング全体で活用されるようになりました。

現在、新入社員は一時的な仮想チームに編成され、3〜4 週間活動します。チームは専任メンターと協力し、具体的なツールや製品の改善をリリースしながら、開発プロセスを学びます。経験豊富な Stripe エンジニアはメンターとして、チームと共に作業し、プロジェクトを実行可能なタスクに分解し、技術面と製品面の両方の質問に答え、コードをレビューし、エンジニアリング全体との架け橋として機能することで、リーダーシップとメンターシップのスキルを磨きます。

ソフトスキルと文化を忘れないでください

心理的安全性 とは、リスクを取って知識を共有し、互いをサポートすることが安全であるという、チームメンバー間の共通の信念です。Googleの Project Aristotle による、効果的なチームの秘訣を探る研究では、心理的安全性がチーム成功の最も重要な要因であることが明らかになりました。

私たちは、文化やグループの規範に関するガイドを作成することで、この安全性を育むことを目指しています。ガイドでは、一般的なコミュニケーションとチーム固有のプラクティスの両方を扱います。Stripe 101 には Stripeでのコミュニケーション と呼ばれるクラスが含まれており、社内メーリングリスト、メールのベストプラクティス、バグトラッカーだけでなく、ミーティングのスケジュール方法といった一見明示されていないコミュニケーションパターンについても説明しています。カレンダーの規範は一見常識のように思えますが、実際には重要な文化的知識を含んでおり、それを理解することで、スケジュール上の誤りや重要イベントの見落としを防ぐことができます。

エンジニアリングチームは、特定のツール (GitHub や JIRA など) やコードレビューなどの一般的なプラクティスに関する専門ガイドを提供します。これらは信頼できる情報源として機能し、チームが事前にプロセスについて協力して合意できるようになり、進行中の議論や混乱を軽減します。セルフサービスのドキュメントは、口頭での伝達への依存を減らし、より迅速にスケールするのに役立ちます。

ヒントと演習

• 会社および製品の概要を説明するオンボーディングクラスを 1 ～ 2 回試験的に実施します。
  
• チーム向けの文化またはグループ規範に関するガイド (電子メールの送り方、カレンダーの使い方、コードレビューの完了手順など) を作成します。
  

エンゲージメントと人材定着

既存のチームに投資する

従業員の幸福度は、多くの場合、自分の仕事がもたらす影響を理解しているかどうか、そして日々の意思決定に自律性を感じているかどうかという 2 つの要因に左右されます。これに加えて、成功するチームは、メンバーが長期的に意欲を持って関与し続けられるような仕組みを整える必要があります。チームは、フィードバックに積極的に耳を傾け、個人の成長に向けた明確な道筋を定義し、リーダーを育成してチームを最適に支援する必要があります。

新入社員の採用とオンボーディングを終えると、企業は短期的な成果に注力するか、チームの長期的な生産性に焦点を当てるかを選択できます。高成長企業では状況が急速に変化し、当初どのように意思決定が行われたのかを思い出しにくくなったとしても、初期の意思決定が長く影響を及ぼすことがあります。初期メンバーは新入社員よりも豊富な知識を持ち、成果を上げるうえで最も効果的であり、技術的な文脈と組織構造の両面を理解することで、会社にとって貴重なメンターとなります。一方で、彼らは業務過多に陥ったり、特定の部署や技術スタック内に閉じ込められてしまうこともあります。初期メンバーと連携し、チームに適した支援体制を整えることで、こうした状況を回避しましょう。

生産性をエンゲージメントと混同しないこと

前職で初期マネージャーを務めていたとき、私は協調的で生産性の高いチームを支援していました。ある日、長年勤めたエンジニアが 1 対 1 の面談に現れ、静かに退職届を差し出しました。彼は常に質の高い成果を上げ、挑戦的なプロジェクトに取り組み、新入社員やインターンの指導も行っていました。理由を尋ねると、チームが会社にとって重要な仕事をしていることは理解しているが、自身の影響力を高めたり、新しいスキルを学んだりする方法が見つからず、挑戦を感じなくなったと答えました。私はこれを サプライズ退職 と呼んでおり、これは人々が「現状の最適解 (ローカル・マキシマム) に行き詰まった」と感じたときに起こります。つまり、社内で新しいが影響の小さい役割を引き受けるよりも、新しい機会を求めて会社を去る方が簡単だと判断するのです。

私はすぐに、何の警告サインにも気づいていなかったものの、彼のキャリアの目標について少し話をするだけで、その懸念が明らかになっただろうと気づきました。人は自己成長を実感するとエンゲージメントを維持しやすくなります。日々の業務の生産性だけでなく、適切な質問を投げかけることでこれを支援できます。私たちは年に 2 回、エンゲージメントを測定するための従業員アンケート「StripeSat」を実施しています。以下は、前回の調査で特に重視した質問の一部です。

• 職場で学び、成長する機会はありますか？どのようなことを学びたい、または上達したいと考えていますか？
  
• 3 年後に Stripe で働いていると思いますか？その理由、またはそうでない理由を教えてください。
  
• Stripe にキャリア成長の機会があると思いますか (例: ストレッチアサインメント、責任の拡大、社内異動など)? そうでない場合、どのような機会に魅力を感じますか？
  

異動と学習を支援する仕組みを構築する

従業員が新たな機会を見つけ、独立したプロジェクトを立ち上げられるよう支援することで、会社でのキャリアストーリーや役割を自ら築くことができます。Stripe では、新チームを紹介するための社内リソースを整備し、従業員に新しいプロジェクトへの参加を奨励し、創造性を育むためのハッカソンを開催しています。

従業員はローテーション制度を活用して新しいプログラミング言語を学んだり、自社スタックの別の領域を探求したり、場合によっては恒久的にチームを異動することもあります。過去 6 か月間で、10 数名のエンジニアが iOS モバイル開発、コア決済 API 機能、機械学習アプリケーションなど、幅広いプロジェクトを経験しました。また、社内異動によって最も効果を発揮できる役割 (例: 新しいチームの立ち上げや複雑な技術課題の解決など) を特定・推奨しています。こうした取り組みによって、経験豊富なエンジニアを最も貢献度の高いプロジェクトへ導くことができます。

新しいことに挑戦するのに、何週間も計画を立てたり、新しいチームを組んだりする必要はありません。新しいツールや製品の開発を促進するため、社内ハッカソンも実施しています。最近のハッカソンでは、複数のオフィスから 80 名が参加し、Stripe Elements における右から左への言語サポートや、従業員の生産性を高める社内ツールなど、7 つのプロジェクトを社内外のユーザーにリリースしました。

フィードバックを求め、それに対応する

企業が成長するにつれて、従業員のフィードバックに対応するには、スケーラブルなアプローチと、個人の声に注意深く耳を傾けることの両方が求められます。従業員は常に企業内の問題を認識していますが、それを効果的な変化へとつなげる方法を必ずしも知っているわけではありません。従業員からのフィードバックには、次の 3 つのステップで対応します。

1. 問題を特定する。
   
2. 構造化されたフィードバックを収集する方法を設計する。
   
3. フィードバックに対応し、結果を出す。
   

2 年前、エンジニアたちは開発環境が遅く、非効率的だと一貫して述べていました。これに対応するため、私たちは社内の開発者エクスペリエンスに焦点を当てた、経験豊富な Stripe エンジニアのチームを結成しました。直感と専門知識を備えていたにもかかわらず、彼らは最も影響力の大きいプロジェクトを特定するのに苦労しました。そこでチームは、次のような質問を含む開発者エクスペリエンス調査を開始し、作業の指針としました。

• 先週、開発プロセス上の問題で何時間失いましたか？
  
• 当社のツールやインフラストラクチャについて、生産性を高めるために私たちができることを 1 ～ 2 つ挙げてください。
  
• あなたが作業しているコードベースで、必要以上に難しいことは何ですか？
  

調査結果によると、最も一般的な要望は (2 倍) の頻度で、高速かつ信頼性の高い編集・同期・テストループでした。チームはこれを真摯に受け止め、コードの同期・リロード・テストの速度と信頼性を高めるための一連のプロジェクトに取り組みました。数か月後の次のラウンドでは、これらの分野の満足度が 50〜80% 向上したことが示されました。これにより、チームとユーザーの間に前向きなフィードバックループが生まれ、エンジニアが自分の意見が聞き入れられていると感じることができました。それ以来、私たちは四半期ごとに開発者エクスペリエンス調査を実施し、その結果から学び続けています。

ヒントと演習

• 経験豊富な社内異動者を募集する、特定のチームや役割を強調する社内求人掲示板を作成します。
  
• ハッカソンのパイロットプログラムを開発します。これは、Hack-a-Month や Hack-Weeks など、さまざまな期間にわたって実施することができます。
  
• 企業調査を実施し、フィードバックに基づいて取り組むことができるプロジェクトを 1 つ特定します。
  

まとめ

組織が進化するにつれて、チームをどのようにスケールさせるかは、文化、生産性、従業員エンゲージメント、そしてひいてはビジネスの成功に大きな影響を与えます。急成長する企業では状況が急速に変化し、今日うまくいっていることが明日には通用しない可能性もあります。これらのプラクティスは、これまでのスケール拡大に役立ちましたが、今後も成長に合わせて新たなプラクティスを反復し、発展させていきます。これらの学びが皆さんのスケーリングの旅に役立つことを願うとともに、その過程で得た発見を共有できることを嬉しく思います。