テクノロジスト工場に閉じ込められて

テクノロジスト工場に閉じ込められて

私が初めてClojureを使って報酬を得たのは、その言語がリリースされてからわずか2年後のことでした。言うまでもなく、それは初期段階のスタートアップでした。

Runaのアイデアは、小規模なオンライン小売業者向けに動的な価格設定を行い、個々の買い物客の行動に基づいてターゲットを絞った割引を提供することでした。実際には、ショッピングカートを放棄した人に固定割引を提供していました。顧客の小さな割合をコントロールグループとして扱うことで、小売業者の売上に対する自分たちの影響を計算し、その一部を受け取ることができました。最大の課題は、小売業者に価格設定を任せてもらうこと、そして次に、計算された「リフト」の数学的根拠が妥当であることを納得させることでした。

私たちは、大きな契約が間もなく成立し、トラフィックを恒久的に1桁増やすことができると自分たちに言い聞かせました。私たちは、私たちと同じようにスケールするように設計されたHBaseをプライマリデータストアとして使用しました。[1]将来的には、ソフトウェアで結びつけられた独立したオンライン小売業者で構成される、緩やかに連邦化されたAmazonを構築するつもりでした。もし私たちがそれを構築すれば、彼らは来るだろう、と。しかし、彼らは来ませんでした。私たちを支えていたのは、CEOがeBayの幹部を知っていたため、eBayのために構築した特注製品だけでした。その後、私が退職した後、その同じ幹部はStaplesに移り、そのスタートアップを全面的に買収するよう説得しました。私たちが構築したものは何もStaplesにとって有用ではなく、単に私たちの「革新」能力の証拠に過ぎませんでした。その結果できた"skunk works"チームは、その後解散されました。

次の仕事は、より確立されたスタートアップであるFactualでした。そこではJavaと埋め込みJavaScriptを使用して製品を構築し、Clojureを採用し始めていました。彼らの製品は、Webクロールデータに数百もの異なるヒューリスティックを適用して生成された、世界中のすべての場所のインデックスでした。各エントリには、正規のIDと、名前、住所、営業時間などのさまざまなプロパティがありました。さらに興味深いのは、YelpやFoursquareなどのさまざまなプラットフォームの同等のIDも含まれており、不完全な（あるいは部分的に間違った）プロパティセットをインデックス内の対応するエンティティに解決できるAPIを提供していたことです。

私たちの製品は、地理的な要素があれば、数千もの異なるデータセットを統合できました。私はそれを「世界の外部キー」と説明するのが好きでした。残念ながら、オントロジーにはあまりお金になりません。私が参加した時点では、そのデータセットはすでにFacebook Placesの基盤として、またAppleの当時の新しいマップ製品の一部として使用されていました。これらは大きな契約でしたが、世界には大企業はそれほど多くなく、地理的な要素を持つ企業はさらに少数です。小規模な顧客で差を埋めようとどれだけ努力しても、10億ドルの評価額への道はありませんでした。

私たちは、データによって強化されたサービスを提供するようになりました。社内では、これはピボットというよりは、データの本来の価値を示すデモンストレーションとして提示されました。私たちがデータを使って何ができるかを見れば、きっと彼らも独自のアイデアを持つだろう、と。最初のお客様は広告テクノロジー企業で、モバイル広告の地理ターゲティングを改善したいと考えていました。デジタル広告の経験を持つ営業担当者やマーケティング担当者を雇用し、売上が伸び始めるとさらに多くの人を採用しました。毎日数十億もの広告インプレッションを処理するサービスや、広告テクノロジーパートナー向けのオンプレミスサービスを強化する特注のほぼデータベースを構築しながらも、私はそれがすべて付随的なものだと自分に言い聞かせていました。私たちのビジネスはデータであり、広告ではない、と。

もちろん、私は間違っていました。会社の広告部門が成長のすべてを牽引しており、製品の方向性は、彼らが契約を成立させるのを助けるものでした。しかし、この事実に気づくのが遅かったのは私だけではありませんでした。CEOとの退職面接で、退職を伝えた直後に、Factualの焦点が恒久的にシフトしたことを皆にもっと直接伝えるべきだと話しました。彼は、私がまだ自分自身に言い聞かせようとしていたことを言いました。広告は一時的な気晴らしであり、すぐに基盤となるデータに戻るだろう、と。しかし、その後の数年間、Factualは位置情報ベースの広告にますます注力するようになり、最終的にFoursquareと合併しました。

---

スタートアップがベンチャー資金を調達すると、その唯一の目標は成長になります。10億ドルの評価額に到達するか、それに挑戦して死ぬかのどちらかです。その成長に伴い、技術的な課題はますます大きくなります。これらのうちいくつかは明白です。ユーザーが増えれば、より多くのマシンが必要になるだけでなく、より複雑なインフラストラクチャが必要になります。[2]他のものはそれほど明白ではありません。ユーザーベースが増えるにつれて、個々のユーザーはソフトウェアのビジネスロジックの中でますます抽象化されていきます。最初の課題に対処するには、技術的な手腕が必要です。2番目の課題に対処するには、ビジネスドメインを深く理解する必要があります。

これは、スタートアップが成長を続ける限り、エンジニアは知識と手腕を向上させることができる（そしてそうしなければならない）ことを意味します。しかし、ほとんどのスタートアップは失敗します。それらの失敗の一部は、会社が自身の成長に追いつけなかったためですが、これらは例外です。一般的な、退屈な失敗の原因は、スタートアップがほとんど成長しなかったことです。

停滞に直面したエンジニアリング組織は、2つの反応をとることができます。会社を再発明するのを手伝おうとするか、あるいは必然的に来るであろう成長のために準備を続けるかです。Runaでは、後者を選びました。

当初、エンジニアリングのリーダーシップは、将来的に必要なレバレッジを与えるであろう、有望だが十分に理解されていないテクノロジー（Clojure！HBase！）を採用しました。しかし、ローンチして停滞が始まると、その準備は絶え間ない準備の必要性に変わりました。初期の技術的な間違いは、たとえ残念なものであっても、すべて焼き付けられていました。それらを再訪し、より良いものを構築しようとすることは、成長が最終的に来たときに私たちを不意打ちにするだけでした。

私はRunaに入社して数ヶ月後にエンジニアリング組織が防御的な姿勢に入りました。私は経験不足で、[3]あまりにも気を取られていたため、それを疑問視しませんでした。毎日、私たちはジェンガをプレイし、新しいコミットごとに既存のコードベースを可能な限り少なく動かすように努めていました。後に、これまでの仕事のどれにも誇りを持てないことに気づき、システムの主要部分の再構築を精力的に推進し始めました。

数ヶ月後、私はそれをやめるか、3週間の解雇手当を受け取るかのどちらかだと言われました。私は解雇手当を選びました。

もちろん、たとえ私の意見が通ったとしても、何も変わらなかったでしょう。私たち全員が、実際の問題、つまり私たちのビジネスモデルが実際には機能しなかったということを注意深く無視していました。私たちの製品と価格設定モデルの両方は、潜在的な顧客からの不当なレベルの信頼を必要としましたが、私たち誰もそれを自分たちの問題として解決しようとはしませんでした。私たちはビジネスモデルの下流にいました。私たちの仕事は、その最終的な成功を待って準備することだけでした。

私は問題空間に魅了されたためFactualに入社しましたが、私が参加した時点ではそのほとんどが解決されていました。約6ヶ月後、リーダーシップは、私たちのビジネスモデルは成功していましたが、10億ドルの評価額には到達しないだろうと認め始めました。そこで、広告テクノロジーへの私の転落が始まりました。

私は教訓を学んだことを証明したかったのです。現在のビジネスモデルがうまくいかないなら、新しいモデルを構築するのを手伝おうと思いました。生データを消費するサービスや、処理された結果を顧客に提供するオンプレミスサーバーを構築しました。営業会議に出席し、設計ドキュメントを書き、パケットダンプを丹念に分析して、レイタンスパイクが相手のシステム内の他の場所で発生していることをパートナーに証明しました。

結局、広告業界があまり好きではないことを学びました。ブランドがデジタル広告キャンペーンを実行したい場合、代理店に行き、その予算を最大限の効果で使う責任を負います。次に、代理店はデマンドサイドプラットフォーム（DSP）に行き、取引所での個々の広告インプレッションに対してリアルタイム入札を行う責任を負います。これらの決定を知らせるために、DSPはFactualのような企業に行き、電話の現在地と過去の場所をキャンペーンに関連するバイナリ機能に絞り込むことができました。

特に、オンラインで何かを販売していない場合、デジタル広告キャンペーンの効果を測定することはほぼ不可能です。[4]これは、代理店が契約を成立させる限り、ほとんど何でも言えることを意味します。次に、DSPは、代理店が契約を成立させるのを助けると思われるものを販売しました。そして、この連鎖の終わりにFactualがあり、ブランドを説得する営業担当者を誘惑すると思われるものを販売していました。

私は製品中心になり、会社が成功するのを助けるあらゆる問題に解決する準備ができたと思っていました。実際には、私は技術的な問題にしか注意を払っていませんでした。それらが大部分解決されると、製品が実際に行っていることに対する私の曖昧さを無視するのが難しくなりました。最終的に、私は去りました。

---

この人生の時期から2つの教訓を得ました。1つ目は個人的なものでした。私は、本質的にテクノロジストです。一般化し、抽象化するのが好きです。ソフトウェアの周りのコンテキストを理解することが重要だと信じていますが、そのコンテキストが他人のソフトウェアである場合に最も幸せです。

2つ目の教訓は、より広範で、より明白ではありませんでした。[5]私たちの業界は、私のような人々を育成するように設計されています。

これは驚くべきことでした。なぜなら、それは明らかに私たちの利益に反するように見えるからです。ほとんどすべてのケースで、企業は間違ったものを作るために失敗します。顧客がエンジニア自身でない限り、私はその手助けをするのに適した人物ではありません。システムの周辺に快適にいて、競争環境について学びたい、顧客と話したい人物が必要です。あなたはプロダクトエンジニアを必要としています。

しかし、私たちの標準的な面接の質問を考えてみてください。データ構造、再帰、計算量。これらの質問が「実際の」日常的なソフトウェアタスクを反映していないと主張する人がいるのを見ると、少し奇妙に感じることがあります。私も常に再帰関数を書いています。しかし、それは抽象化の結果です。特定のデータ型に対する単純なネストされたルックアップが、可能なデータ型のセット全体に一般化しようとすると再帰になる可能性があります。

同様に、たとえばO(log N)とO(N)の違いは、実際にはNが十分に小さい傾向があるため重要ではないと主張するのを見たことがあります。それは一部のドメイン、おそらくほとんどのドメインでは真実かもしれませんが、汎用ツールを構築している場合は、病的なケースに焦点を当てる必要があります。

もちろん、他の人は、この初年度のCSの教材が私たちの仕事の本質であると主張するでしょう。これは間違いなく私がGoogleにいたときの態度でした。[6]既存の従業員はJavaScriptを書くのをあらゆる手段を講じて避けていたため、フロントエンドの経験がある人は誰でも技術的な基準が低く設定されるだろうと彼らは決定しました。これらの採用者は、誰もやりたがらない仕事をするためにのみ許可された人々として、広く二級と見なされていました。

しかし、プロダクトエンジニアを採用したい場合、代わりにどのような質問をすべきでしょうか？私たちの業界の広範な範囲を考えると、私たちの正確な製品スペースでの事前の経験を持つ候補者のみを考慮することは非現実的です。同様に、候補者の以前の製品スペースの専門知識を期待することも非現実的です。私たちは共通の語彙、優れた設計上の選択と平凡なものを分けるニュアンスの共通の理解を欠いています。

そして私たちは街灯の下で鍵を探し続けています。鍵はどこにでもあるかもしれませんが、光があるのはここです。幸運にも、私たちが採用するテクノロジストは、人間的で有用なソフトウェアを作成するために必要な他のすべてのスキルも持っているでしょう。

これは、たとえあなたがテクノロジストでなくても、ふりをすることを学ばなければならないことを意味します。そしてこれは、言語がリリースされてからわずか2年後に、私の最初のClojureの仕事が初期段階のスタートアップにあったことが明らかになった、始まりに戻ってきます。

ほとんどの新しいテクノロジーは、採用される場合でも、よく知られたパスをたどります。まずホビイストが来て、次にそのホビイストを雇用する企業が来ます。この2番目のステップは、企業が新しいテクノロジーを採用するためのプロセスをほとんど、あるいはまったく持っていない場合に最も簡単です。つまり、初期段階のスタートアップです。この現象に関する標準的な物語は、特定のテクノロジーは単に強力であるというものですが、それらを使いこなす方法を知っているニッチな人材プールから採用するのに十分大胆なのはスタートアップだけだというものです。

しかし、新しいテクノロジー[8]には力はありません。そのためにはコミュニティ、ドキュメント、そして活気に満ちた補助技術のエコシステムが必要になります。彼らが持っているのは可能性であり、それはスタートアップと初期の採用者の可能性に共鳴します。おそらく、彼らはすべて、時間をかけて一緒に成長できるでしょう。

多くの人が指摘しているように、これは会社を構築するための合理的な戦略ではありません。しかし、新しいテクノロジストを訓練するための驚異的な方法です。チェスタトンはさておき、フェンスが存在する理由を学ぶ最も速い方法は、それを解体して何が起こるかを見ることです。

この観点から見ると、それほど非合理的ではないように思えます。ほとんどのスタートアップは、実存的な技術的リスクを伴う規模に達する前に失敗します。彼らがエンジニアに提供できる唯一の保証された利益は、独自の課題を発明し、反復的な失敗を通じて学ぶ自由です。[9]スタートアップが失敗しても、害はありません。スタートアップが軌道に乗れば、エンジニアは新たに得た知恵を応用できます。

これは、スタートアップが未熟な新しいテクノロジーを採用するのではなく、その未熟さのために採用することを意味します。これは、テクノロジストのスキルセットの重要性を増幅する、新しさの絶え間ない循環と陳腐化を促進し、スタートアップが新しいテクノロジーを採用するように駆り立てます。

このフライホイールは何年も回転しており、私たちが新しさと技術的進歩を混同していることを指摘しただけで止まることはありません。しかし、それが現実の害を引き起こしていると信じているため、それを遅くできることを願っています。

私たちが解決するすべての問題に抽象化を導入することで、私たちの仕事が最終的にどのように使用されるかから私たち自身を遠ざけます。私たちは自分たちが鋭いナイフを作るビジネスにいると自分たちに言います。もし私たちがそれらをより安全にすれば、バターを塗る以外のすべてには役に立たなくなるでしょう。私たちは、進歩の避けられない結果として、私たちが作成したものに影響されることなく浮遊しています。

私たちの価値観を汎用ソフトウェアにエンコードできないことは真実ですが、[10]私たちは単に原子化されたテクノロジストではなく、私たちの世界は私たちが公開するインターフェースによって制限されていません。私たちは、私たちが作成したものに対して集団的な責任を共有しており、その責任に基づいて集団的に行動する能力があります。

しかし、集団的責任への信念は、実際には何を意味するのでしょうか？どのような行動を伴うのでしょうか？正直なところ、わかりません。私が知っているのは、街灯の下にいつまでも留まることはできないということです。ある時点で、暗闇の外にあるものを見なければならないでしょう。

---

1. 誰にも驚かないひねりですが、私たちがそれを使用した方法は決してスケールしませんでした。キーに対する順序付きスキャンをサポートするために、HBaseはキー空間の連続した範囲でパーティション化します。日ごとのイベントをスキャンしたかったため、すべてのキーはタイムスタンプで始まっていました。これは、指定された期間のすべての書き込みが単一のシャードに集中することを意味し、HBaseは負荷を均等に分散しようと必死にシャードを再パーティション化することになります。私たちのHBaseクラスターは常にクラッシュ寸前でした。↩
2. コアサービスが水平方向にスケールできるという非常にまれなケースであっても、それらが生成するデータ量の増加を処理すると、システム内の他の場所に複雑さが導入されます。↩
3. Runaでの最初の年は、ほとんど無関係なうつ病の発作と重なりました。ソフトウェア開発に対する一歩一歩のアプローチは、私の人生の他のほとんどすべてのアプローチ方法を完璧に反映していました。↩
4. これの唯一の例外はGoogleかもしれません。Androidフォンをお持ちの場合、GoogleはWalmartの広告を表示した数日後に、Walmartへの訪問をそれに帰属させることができます。Google Payを使用している場合、購入を帰属させることさえできます。因果関係を証明できないかもしれませんが、それでも他の誰もが提供できるものよりもはるかに優れています。↩
5. 私たちは皆、会社の物語の弧の中で主人公であるという蔓延する神話のために、テクノロジー、特にスタートアップにおける構造的な力を推論することは困難です。何かが失敗した場合、それは私たちが十分に一生懸命働かなかったか、より良いアイデアを持っていなかったためだけです。今でも、このキャリア期間を考えると、罪悪感がよぎります。物語の結末を変えることができなかったのだろうか？↩
6. これは2010年のことですが、状況が大幅に変わったとは思いません。↩
7. この試練を回避する方法はいくつか知っていますが、どれも普遍的な魅力はありません。初期段階のスタートアップで誰かがあなたを保証してくれる場合、彼らはしばしばあなたが「カルチャーフィット」であることを確認することに直行します。しかし、これは、強力なネットワークを持ち、小規模なスタートアップで働きたいと考えており、該当する文化に適合する候補者に対してのみ機能します。同様に、あなたは単に自分の会社を設立することができますが、創業者であることは、あなたをまず第一にビジネスと投資家の間のインターフェースに置きます。製品とユーザーの間のインターフェースは、常にリストの下の方になります。↩
8. そして、スタートアップが採用するニッチなテクノロジーは、例外なく新しいものです。グラハムのLispの普及は、Common Lispの広範な採用につながるのではなく、まだ可能性に満ちたまったく新しいLispであるClojureの採用につながりました。↩
9. 現在の状況を考えると、ジュニアエンジニアに退屈なテクノロジーのみを使用するように指示することは、実際には、古い世代のエンジニアがはしごを引き上げていると描写される可能性があります。彼らは失敗から学ぶことができましたが、新世代も同じようにできないのでしょうか？↩
10. 何かが悪い目的で使用されているかどうかを区別できるソフトウェアライセンスを読んでいるすべての人に、倫理に関する単一の本を読むように懇願します。↩