エンジニアリングはテクノロジー企業にとって極めて重要な職務の一つです。いやむしろ、どの企業も何らかの形でテクノロジー企業になるので、これはあらゆる企業にとって重要です。しかしテクノロジー企業の場合、エンジニアリングは事業の中心にある主力製品、つまりその企業が販売し、人々が使用・購入する製品の開発に関与します。そして、技術的製品部門にはリーダーが多い (アーキテクトからCTOまで) 可能性もある一方、その中でも Head of Engineering または VP of Engineering はエンジニアチームを育成・管理する幹部です。そして機能 (または製品) を提供するまでにかかる時間を評価し、そのスケジュールに沿った質の高い製品を発売することに責任を負います。
ですが、その役割をロジスティクスの観点だけで理解してしまうことは役割の範囲について単純化し過ぎで、VP of Engineering という花形の役職が実行するその他多くの重要かつ繊細な職務を見逃しています。組織が拡大していくと、納期を決定し、正しい日付に全て間に合わせ、集団の意見を一致させながら開発を優先順位付けすることは (不可能ではないものの) 困難になります。この他にも適切な社内文化を設定するという重要な要素があります。この要素は優秀なエンジニアを雇うためには欠かせません。さもなくば彼らは他のところへと去ってしまうでしょう……。この市場では、優秀なエンジニアにとっては留まるよりも動く方がはるかに簡単です。良い VP of Engineering はおそらくそういったものを全て実現したうえで、質の高い製品を出荷したり、エンジニア部門以外の組織全体にもプロセスの透明性をもたらすはずです。
この職務に存在するそういった他の側面を理解していないスタートアップでは、エンジニア責任者の求人募集が、製品開発サイクルから見てあまりに遅いことも多々あります。その結果、状況を管理する有能な VP of Engineering がいないことで生じるあらゆる社内の問題を処理せざるを得なくなります。たとえば、プロセスの不具合、うまく編成できていないチーム、エンジニアリングと製品マネジメントとの不均衡、フラストレーションを感じさせるようなエンジニア・チーム内の文化、といった問題です。
私は幸運にも複数の非常に優れたエンジニア幹部たちと一緒に働く機会に恵まれました。そういった人物を取締役会に招くと必ず、彼らは社内の大きな問題に対処してくれました。そして私はどのケースでもこう思いました、「もっと早く彼を招いていればよかった!」と。というわけで、以下にこの職務で欠かせない側面のうち、適切な候補者を探す際に覚えておくべきものをいくつか挙げていきましょう……
製品プランニング
ほとんどの人々は当然ながら、エンジニア責任者の実行能力を重視します。しかし、開発に先立つ製品プランニングの段階でも彼らの役割は欠かせません。
テクノロジー企業内のエンジニア組織の場合、製品開発への取り組みで研究開発に関する詳しい説明が必要になることもよくあります。特定の製品や機能セットをより実用的かつ本番環境に耐えるスケールで提供するためです。そして、プロダクトマネジメントやプロダクトマーケティングがその製品の特徴、市場規模、価格設定に対する洞察を提供する一方で、エンジニアリングのリーダーは任意の期日までに提供するために必要となるリソース (人数、設備など) へのフィードバックを提供します。
これは反復されるプロセスとなるのが普通です。きちんと順序良く進むと思う人もいるかもしれませんが、そうではありません。CEOは予算やその他の物事による一連の制約の中で動かなければなりませんし、市場や製品価値を拡大するような機能と、そこに至るまでに要する人員や資本支出をうまく両立させる必要があります。実行の見積もりを正確にまとめ上げたのち、その予測を管理・更新することは強力な製品事業を経営するうえで欠かせません。優秀な VP of Engineering 抜きでは、それも非常に危険な作業となりかねません。
ただ単にエンジニアチームから情報を直接入手することができない理由は何でしょうか? エンジニアリングにかかるプレッシャーは、特にスタートアップでは非常に重くなります。あたかも企業が成功へ到達する前に立ちはだかる唯一のものであるかのごとく、エンジニアリングを位置づける言説もよく聞かれます。そのような立場に陥ったエンジニアたちは、予定通りにリリースするために、会社にとって正しいと自分たちが思う行動 (技術的負債を引き受ける、夜間や週末に働く、品質保証をおろそかにする) を取りがちです。時には、個々のエンジニアたちに対してプロダクトマネージャーや営業担当者が個別に接触し、特定の機能が公開されるまで実際にどのくらいかかるかの「正確な」判断を知ろうとすることもあります。否定論者になりたがる人はいないため、このような見積もりはより広範な課題や組織内で競合する優先事項を考慮に入れていない、過度に楽観的なタイムフレームを引き起こしてしまいます。それはつまり、工程が省かれ、技術的負債が生じ、機能が差し迫った販売サイクルで必要なものだけに偏って (一方、その他の戦略的開発で必要なものは少なくなって) しまうということです。
しかし、良い VP of Engineering はより幅広い方針に関する統一見解によって、このプロセスに健全性をもたらします。 VP of Engineering は何か他のものを犠牲にしてでもある機能を盛り込むべきとき、そして後でその理由を説明する方法を心得ています。
エンジニアチームとその文化の構築
当然ですが、良いエンジニア責任者がもつパワーは、製品機能と製品リリースの管理のみに要約できるものではありません。 VP of Engineering の最も重要な職務とは、エンジニアチームを構築し、スタートアップのエンジニア文化を根付かせることです。とりわけ、その組織がミドルマネージャーの必要となる規模に至る場合に重要です。また、優秀なエンジニアの技能レベルを測る標識には明確なもの (オープンソースの信頼性、コーディングテストのパフォーマンスなど) がある一方、マネージメントはより定性的な領域となります。
そのため、優秀な VP of Engineering であれば、誰がそのチームにとって良いマネージャーかを判断して彼らを雇い、長い時間をかけてその人材を教育できるはずです。なぜなら、優秀なチームの構築というのは静的なものではないからです。スタートアップは素早く成長し、それに伴ってエンジニア組織も拡大する必要があります。また、初期のチームにあった文化は規模が2倍、4倍となるにつれ、いとも簡単に失われます。優秀な VP of Engineering は既存の文化の維持と新しい文化の発達の間でバランスを取る方法を心得ています。そして、エンジニア組織がサブプロジェクト (相互運用する必要はあるが、別々の締め切りに縛られるもの) へと分割され始める際、良いエンジニアリーダーはその集団間での活動を管理できます。
ですが、私たちは雇用する際に、良いエンジニアリーダーがどんな人物かをどうやって知ればいいのでしょうか? VP of Engineering について書類上の資質にとどまらない評価を行う最も簡単な方法とは、その人物による現在または過去のチームを見てみることです。そのチームはリリース予定日に間に合っていましたか? チームのプロセスは思慮深い (場当たり的ではない) ものでしたか? チーム間で起きた不和 (例えば、非生産部門とクリエイティブ部門との衝突など) は多過ぎませんでしたか? エンジニアリングマネージャーは、自らが管理する集団を最もよく反映した存在だということに私は気づきました。彼が担当したチームの中で見つかったものは、自社でも起こる可能性が高くなります。
実行の保証
最終的に、あらゆるエンジニア組織の成果は製品という形になります。正しく機能している組織は高品質な製品を作り上げるだけでなく、事前に決定した期日に間に合わせ、もしそれが変わる際にはスケジュールの更新を正確に予測します。したがって、良いVPはソフトウェア開発プロセスを全て掌握し、正しいプロセスが実施され、守られることを保証します。
エンジニアリングのプロセスとやり方についてはすでに多くを記してきたので、ここでは詳しく述べません。その代わり、優秀なエンジニア幹部がもつ、見かけからははっきりわからないものの、遂行にとっては大いに役立ついくつかの特徴に注目していきましょう。
士気の維持 (とその結果生じる作業量の多さ)
往々にして、士気と作業量はいささか相反しているように思えます。より多くのサイド・プロジェクト、休み、付随的なトレーニングが士気をさらに高める結果をもたらします。ですが、スタートアップにはこのような余裕がないことも多いです。優れたエンジニア責任者はそのチームが製品を前に進めるうえで充実感や満足感を抱けるよう、彼らに十分なオーナーシップと自由度を与える傾向にあります。
アーチではなく、複数の箱の構築
プログラマと設計者は通常、その設計における優雅さを高く評価します。そして、何らかの価値を生み出される前からそのプラットフォームに多額の投資が必要となるほど、設計が全般的な場合もよくありますこのプロセスをアーチを用いた建築になぞらえるのを聞いたことがあります。そのような建築では、最後の1ピース (要石) が頂点に挿し込まれて、全てがまとまるまで構造物が自立できません。これは優雅ではあるかもしれません。しかし、ある市場において再現可能な Product/Market Fit を見つけるというスプリントの期間中には、価値を示すことや顧客からのフィードバックを得ることが不可欠です。そのため、有能なエンジニア責任者であれば、有用な外部からのフィードバックを迅速に集められる、より実用的で漸進的な設計の方向へとチームを向かわせられるはずです。それと同時に、そのシステムの長期的な普遍性を危うくすることもありません。ここでのVPの役割はアーキテクチャを作成することではなく、設計のプロセスにおいて、漸次的なリリースこそが本当の要件となるように徹底することです。
カオスへの対応
テクノロジー業界には「顧客が一人もいないことよりも悪い唯一のことは、顧客がいることだ」という有名なことわざがあります。ある製品の立ち上げがうまく行き、世界中で熱烈に関係されたとき、その市場からのフィードバックは膨大な量になりかねません。たとえわずかの成功であっても、顧客からのエスカレーション、機能のリクエスト、現場からの質問、技術的提携事業者からの統合に関するプレッシャー、顧客とのミーティングなどなどがエンジニアリング組織に殺到します。この全ては製品を推進し続けるのと同時に処理しなければいけません。プレッシャーの下にいるとき、組織は上向きます。有能な VP of Engineering の特徴はこのカオスな状況でかじ取りをしながら、冷静さを維持できることです。
顧客管理
エンジニア責任者はおおむね社内の問題に向き合うものの、製品を出荷する企業の場合には販売の前後でも重要な役割を果たす可能性があります。例えば品質保証プロセスを把握するなどの目的で、顧客が VP of Engineering と話す機会を望む場合もよくあります。開発ライフサイクルの初期には、構想やそのチームの強み以上のものは実際のところありません。優秀な VP of Engineering はこれだけを活用して、顧客の信用という欠かせないものを勝ち取れます。販売後の場合にも、目に見える顧客の特徴が下落し始めたり、製品に問題が発生したりする際に、 VP of Engineering が引っ張り出されることもよくあります。その顧客が直面しているバグの根本的原因とその対処状況を説明するにせよ、あるいは重大なスケジュール遅延の裏にある理由を説明するにせよ、エンジニア担当の経営幹部をその顧客と直接会わせることが顧客の信用を再び得るのに極めて有効な方法の一つです。
* * *
Niciraの初期の頃、最初の一般入手可能なバージョンの自社製品を送り出したときのことを今でも覚えています。積み上げた壁はすぐに崩壊し始めました。もちろん、現場でバグがいくつか発見されることは予想していましたが、エンジニアリングに対する外からのプレッシャーは私たちが予期していたものをはるかに越えていました。顧客のエスカレーションに加えて、並外れて複雑だった製品に関する Proof-of-Concept を効率化するのに役立つようにと、セールスエンジニアチームが使い勝手の改善を要求してきました。それと同時に、サポートはリモートデバッグに必要な即時の変更を強く求めていました。顧客はすぐに公表していたスケーリングの限界を突破したうえ、私たちが想像もしなかった形で製品を利用していました。それにより、社内では再現できない問題を引き起こしていました。
会社の創業者として、私は毎朝、あらゆるものが漏れ出している船の上へと足を踏み入れるような気分でした。私が最もよく会いに行った人物は VP of Engineering の Rob Enns です。彼はその当時、会社の一員になったばかりでした。私は彼に対して、沈没するまであとどのくらいなのか (「私たちは切り抜けられるのか? 」) とよく尋ねていました。 そして彼は私を安心させたのち、自分を一人にしてくれと告げ、「ビジネスをやりに行け」と言ってきたものでした。それが私の経験です。ですが振り返ってみると、もし私たちが彼をもっと早くに迎えていたら、事態はずっと、はるかに簡単だったはずです!
私は全てのスタートアップが VP of Engineering を雇うべきだと確信しています。それも早い内に、たとえ総社員数と比べてちょっと早過ぎるのではないかと思えたとしても、問題が発生し始める前に彼らを迎え入れるべきです。多くの新しいスタートアップはそのエンジニアチームが十分な経験を積んでいるとか、あるいは規模が小さすぎるという理由で、 VP of Engineering は必要ないと考えています。ですが、その役割がもつ重要性はどれだけ強調してもし足りないほどです。優秀な VP of Engineering はその事業が抱えるプレッシャーに耐えるエンジニア部門を根底から支えます。それと同時に、組織を成長させつつ、それがアドホックなプロセスの重みに耐えかねて崩壊しないようにします。適切な社内文化と適切なプロセスの設定は、規模に関わらず、その組織に固有のものとしてあなたが望むものです。そしてそれはまさに、適切な VP of Engineering を適切なタイミングで雇うことによって実行できることです。
著者紹介 (本記事投稿時の情報)
Martin Casado は Andreessen Horowitz のジェネラルパートナーです。彼は以前 Nicira の共同創業者兼 CTO であり、2012 年に VMWare に買収されました。VMWare にいる間、Martin はNetworking & Secruity Business 部門において上級副社長兼ジェネラルマネージャーでした。
記事情報
この記事は原著者の許可を得て翻訳・公開するものです。
原文: Hire a VP of Engineering (2017)
