Geoff Ralston
今から私のパートナーのJared Friedmanが、このパネルの方々とテクノロジーの話をしてくれます。ありがとうございます。
Jared Friedman
Geoff、ありがとう。私は今日こんな素晴らしいゲスト達といられる事を幸せに思います。このパネル上の皆が本当に成功した企業のテクニカルファウンダーです。皆本当にクールな会社と素晴らしい技術組織を作り上げています。
私たちは、今日のイベントの名前を変更しました。もともとは「CTOからのアドバイス」だったのですが、Lillianの助言に従い「テクニカルファウンダーへのアドバイス」に変更しました。この方が正しい表現なので。
また、パネルへの質問をStartup Schoolのフォームに書いてくれた人に感謝したいと思います。私たちは数週間前に質問を募集し始め、150以上の投稿をもらいました。質問してくれた方々、ありがとうございます。できるだけ多くの質問に答えられるよう最善を尽くして、その後ここにいるみなさんにも質問できるようにします。 では始めましょう。
皆の自己紹介と会社や技術の紹介から始めましょう。今の技術スタックは何か、今まで作った面白い技術は何か、現在の技術はどのような構成なのか、などについて。Ralphからどうぞ。
Ralph Gootee
みなさんこんにちは、Raplh Gooteeです。私は、PlainGridの共同創業者およびCTO（最高技術責任者）です。PlainGridには350人いて、サンフランシスコ・ミッション地区を拠点にしています。
私たちは、17兆ドルを動かす建設業界のために、簡単で美しいソフトウェアを作っています。あなた達にわかりやすくするため最近の話題に例えると、私たちは建設のためのGitHubのようなものです。建設には図面がつきものですが、図面は頻繁に変わるのでバージョン管理が非常に重要です。変更があるということは問題が起きているので、それを追跡し共同作業ができるツールを作っています。
また、建設業界の専門用語を多く用いるような他のツールもあります。私たちのスタックはAWS（Amazon Web Services）に基づいたものです。前は他のものを使っていましたがAWSに全てを移動しなければなりませんでした。バックエンドは主にPythonで、Goなどいくつか他のものも使っています。
課題の一つは、それぞれのプラットフォームのネイティブプログラミング言語でコードを書くというもので、iOS、Swift、Subjective-C、Android、（音声不明瞭）、Kotlin、Web React、Windowsがあります。また、.NETのWindowsアプリも持っています。
Jared Friedman
良いね。
Calvin French-Owen
こんにちは、Calvin French-Owenです。SegmentのCTOおよび共同創業者です。Semgentはあなたの顧客データを収集、整理して、あなたが使用しているかもしれないダウンストリーミングツールに適応するための単一APIです。それがGoogle AnalyticsやMixpanelのような分析ツールでも、Gainsightのようなカスタマーサクセスツールでも、Customer.ioのようなEメールツールでも。 Segmentは情報があるところからデータを収集し必要なところに届けられます。
会社は全体で300人余りです。サンフランシスコに本社がありますが、バンクーバー、ニューヨーク、ダブリンにも事務所を持っています。エンジニアのプロダクトデザインチームでプロダクトを作っているのですが、それは80から90人くらいです。
技術スタックの面では、私たち完全にAWS上に構築されています。 インフラストラクチャを実行する方法の面では、ECSというAmazonのコンテナサービスを使っており、私たちのサービス全てがコンテナ化されています。現在は約300種類のマイクロサービスを実行しており、様々な（音声不明瞭）情報を管理し、データの読み書きし、変換し、それが必要なところに送り出しています。そして、私たちのバックエンドは主にGoで書かれています。
Diana Hu
おはよう、私の名前はDiana Huです。私はEscher Realityの創業者兼CTOだったのですが、私たちは拡張現実のためのバックエンドを作っています。
創業者兼CTO「だった」と言ったのは、私の会社がちょうどPokemon Goを作っているNianticに買収されたからです。 だから、私たちがEscherでしていたことを今はNianticで続けています。
拡張現実のバックエンド技術を作って、開発者がより簡単にAR体験を作り上げられるようにしています。私たちがコンピュータービジョンのアルゴリズム、バックエンドの分析、などものを作る際に複雑なことを処理し、開発者が数分で簡単にARアプリを作れるようにします。私たちはマルチプレイヤー、永続性、クロスプラットフォームといったARの機能を多く用意し、開発者が簡単に開発できるようにしています。技術スタックの面では、経験豊富です。
Escherの時はAWSでのサービスがあったのですが、Dockerのコンテナに全てあったのであまり問題はありませんでした。しかしNianticはGoogle Cloudを使うので全てそこに移しました。しかしコードの多くはC++です。なぜなら一旦アルゴリズムを書いてからAndroid、iOS、バックエンドといった構造を編集した方が私たちにとっては効率が良いからです。私たちはコンピュータービジョンアルゴリズムを実行して携帯電話でプロトタイプを作れますし、私たちのサーバーもC ++で書かれているためそこに移動することができます。
Lillian Chou
こんにちは、Lillianです。私はSecond MeasureのCTOではなくCOO（最高執行責任者）です。Second Measureには50人くらいいて、2015年に創立されサンマテオに拠点があります。 私たちがやっていることは、クレジットカードのデータの分析です。
要は、沢山のクレジットカード取引を見て、公共および民間企業のパフォーマンスを日ごとに見られるようにしています。私たちは自動的に何十億もの取引を分析、調整し、綺麗にして正規化します。それをVC会社、ヘッジファンド、Blue ApronやSpotifyといった大きな会社などにフロントエンドアプリとして提供し、競合他社や顧客情報の傾向を確認させています。
面白いことに、私たちの会社にCTOはいません。なので私がこのパネルに来ています。 私や共同創業者は二人とも技術者なので、幸運です。私たちは、技術者でない創業者と起業する時に起こる問題の多くに悩まされる必要はありません。
チームに50人程度いると先ほど言いましたが、主に技術系で、技術者が30人ほどで、その内データ科学者とエンジニアが半分ずつ占めています。そして私たちのユニークなことは、当社の主力プロダクトはデータそのものである、ということです。なのでデータ科学者とエンジニアは、日常的に緊密に協力しなければなりません。
おそらく技術的に興味深いものとなっている事は、私たちのユーザーの多くは私たちのデータを詳しく探りたいという事です。検証できる適応性を持ったフロントエンドを作りながら良いユーザーエクスペリエンスを保つには、速くデータ照会する方法を見つけてバックエンドで複雑な問い合わせを実行する必要があります。技術スタックについては、基本的にAWSで、パイプラインにはLambdaやSparkといったサービスを併用しています。フロントエンドにはReact、バックエンドにはRedshiftのようなカラム指向データベースを使ってサービスを提供しています。
バージョン1の作り方
Jared Friedman
素晴らしい、皆クールでしたね。多様なテクノロジー企業や商品について聞けてとても良いですね。OK。Startup Schoolの企業のほとんどは本当に初期のものです。だから皆にはV1について思い出してもらいましょう。
あなたが実際に何かを提供していた前の、本当に最初のバージョン。そのV1をどう作ったか教えてください。誰がどのように作ったか、どれくらい時間がかかったか、その過程で起きた問題などについて。
Ralph Gootee
私から始めましょう。面白い話ですよ。実は今、あそこでCEOである共同創業者が私のことを見ています。だから、ちょっと...
Jared Friedman
Tracey、こんにちは。
Ralph Gootee
Tracey、楽しんでる？元々は、Traceyが図面をiPadに載せるというアイデアを聞かせてくれたことが始まりでした。それはiPadが発売され始めた2011年だったので、技術的にはとても早かったです。私は「問題ないよ。PDFのようにiPadに図面を載せられるよ、問題ない。」と言いました。
ぱっとiPadに図面を載せて彼女を感心させたかったのですが、実はiPadのような簡単なコンピューター能力しかないものに巨大な画像を載せることは非常に難しい事だったのです。当時はグラフィックチップがなかったので、2万ピクセルなんかの画像はビデオメモリーを機能停止させてしまいました。またPDFという扱いにくいフォーマットだったこともあり、最初のプロトタイプは本当に遅くてだめなものでした。しかし、そこには本当に取り組むべき挑戦があるのだと私は気づきました。
そこから二つ目のプロトタイプを作るまでに一ヶ月かかりました。実はPixarで働いていたことがあるので、グラフィックスの経験はありました。独自のものは使用しませんでしたが、簡単なコンピューターグラフィックの知識を使って、携帯機器で使える初の図面ビューアーを作りました。 それが最初のプロトタイプでした。
一番よかったと思うのは...最初のプロトタイプで重点的に取り組んだことは、技術的に不可能なことでした。当時は図面をiPadに載せることなど不可能だったのですが、それが私たちのプロトタイプでした。
全てのデータがサイドローディングされたので、ウェブインターフェースもありませんでした。ひどいウェブインターフェースはありましたが、削除ボタンのすぐ隣に発行ボタンがありましたし、削除ボタンの確認機能もありませんでした。
なので実は私たちのチームはバックエンド上のすべてを裏で管理して、最初の30か40人目の顧客までのドキュメントを全てロードしていました。しかし、顧客視点からは速くて仕事ができるプロトタイプに見えたでしょう。 裏でことがうまく進むように努めていた者の姿は見えなかった、といったところですね。これが私たちの最初のプロトタイプの話でした。
Jared Friedman
凄いね。
Calvin French-Owen
では私はV1についての話と、少しその後の話もしましょう。共同創業者のPeterの話をStartup Schoolで聞いた人はわかると思いますが、彼はプロダクトマーケットフィットの話をしました。そこで彼がより詳しい話をしていますが、私も今までの私たちの道のりについて少しお話しましょう。まず私たちはYCの2011年のクラスで一緒でした。YCではもう大昔ですね。
しかし、当時はSegmentとは全く異なるものを作っていました。その時作っていたものは学校の講義用のツールで、生徒が考えていることを授業中に教授にフィードバックできるようにするものでした。当時私たちも学生だったので、「これは良いアイデアじゃないか！」と思いました。「教授が5分間ぐらい延々に喋り続けると、生徒は話についていけなくなり混乱し、皆の時間が無駄になってしいます。 その問題を解決しましょう。」
私たちは夏にそれを作り、秋にボストンに戻ってそれを展開しました。しかし大失敗でした。生徒がすぐFacebookやYoutube、Wikipediaを見てしまうのです。思い返すと、大学生が講義中にパソコンを使う時にしがちな事について私たちは考えていませんでした。
また私たちはシードラウンドを終えられたので、新しいアイデアを探し始めました。 まず、「この大学講義用のツールのどこがいけなかったか」を考えました。 一つは、人々がどのように私たちのツールを使っていたのかという質問に答えられなかったということです。ハーバード大学の生徒とMITの生徒のツールの使い方に違いがあるかも、人類学と生物学の授業で使われ方が違うのかも、分かりませんでした。そして、新しいものに切り替えました。
これも今している事とは違いますが、MixpanelやAmplitudeのライバルプロダクトでした。これはユーザーを様々な規則でセグメント分けできるツールで、それが名前の由来です。
そこからユーザーに接触したり、一番積極的なユーザーが何をしていたかを把握することができました。私たちは約15ヶ月間そのシステムを作りました。ずっとバックエンドのインフラストラクチャーを見直してツールを作っていたのに、それを欲しがるユーザーがいませんでした。
それで15ヶ月経過し、私たちは1年間のボストン滞在を経てベイエリアに戻ってきていました。そしてPG（Paul Graham）に、ここ1年半で私たちがしてきたことを話しました。そして彼は歩きながら私たちがしたことを聞いていたのですが、話が終わった時に少し止まってから言いました。「50万ドルも燃やしたのにまだ出発点にいるんだね」 私たちも「はい」と答えました。 彼は「まあ幸運にまだランウェイも残っている事だし、新しいものに挑戦してみれば？」と言いました。
当時私たちには、より多くのユーザーを取得するために使っていた内部のツールがありました。そのツールは、Mixpanel、Kissmetrics、Google Analyticsといった他のツールにデータを送信する時に使うAPIと同じものを使って私たちにデータを送れるようにするものでした。
人々はその単一のAPIを気に入ってくれ、GitHubのオープンソースのライブラリに提供して使用してくれていました。それを見た共同創業者のIanが、「これを商品にしよう」と言ってきました。「これをローンチして、何が起こるか見てみよう」と。 共同創業者ピーターは、「それは最悪のアイデアだ、絶対に成功しない」と言いました。 彼もゆくゆくは納得してくれて、今はCEOですがね。
彼は「早急にこのアイデアをテストする方法を見つけないといけない」と言いました。 なのでライブラリをクリーンアップした後にHackernewsに投稿したのですが、驚く事に初日だけでGitHubで星1000個ほどもらえました。ですから、私たちのV1は、そのライブラリと「ホストされたバージョンに興味があればメールを送ってください」と書かれたランディングページだけでした。 すると500人くらいからメールがきました。
また私たちはV1を約一週間で作りました。皆ハッカソンのように働きまくって一週間後にプロダクトを作り上げました。現在のプロダクトは当時と全く違うものになっていると思います。しかし、良いプロダクトマーケットフィットを実現してユーザーベースを取得するには十分でした。
Jared Friedman
じゃあ1週間が目安だね。皆聞いたね、1週間ですよ。 はい。
Diana Hu
1週間でできたなんて凄いですね。私たちの話は間違いなく1週間以上です。私と共同創業者は色々なものを作ろうと考えていましたが、当時気づいた技術のトレンドの一つは...彼にはロボット工学の背景がありSLAMの経験もあります。SLAMはSimultaneous Localization and Mappingを略したアルゴリズムで、現在はARに主要的に使われています。カメラの位置を把握しながら環境地図のマップを作る事ができます。
当時は主にロボット工学に使われていたアルゴリズムがありました。ARも何回も挑戦したのですがなかなかピックアップされませんでした。マーカー付きのARもありましたがあまり成功しませんでした。
次に私たちは、このアルゴリズムを携帯で実行できないか考えました。そして、実際にできるのではないかと思えるようなところまでたどり着きました。なぜなら、たとえば当時のiPhone 7の計算量は2013年のMacbook Proと全く同じだったからです。ムーアの法則や当時の出力効率の傾向を考えても、素晴らしいことです。なので私たちはそれを実行する事にしました。
当時私はまだデータサイエンスチームのリーダーとして働いていたのですが、「やりましょう」と言いました。 少し仕事を変えても良いかなと思っていたので。私はパートタイムで他の素晴らしいエンジニアとこれに取り組んでいました。しかし機能するバージョンを作る事に苦労しました。最初のものは本当にぼろぼろで残念でした。毎秒5フレームしかなかったのですが、良いAR体験を提供するためには毎秒30フレームくらい処理する必要があったので全然駄目でした。早急に作られたものだったので、とてもがっかりさせられました。
その後リサーチコードを取り除くとうまく機能し始めて、毎秒30フレームできるようになったので、期待が高まりました。ちなみにこれはARが立ち上げられる1年半も前の話です。私たちはとても興奮していましたが二人とも技術者側の人だったので、プロダクトマーケットフィットやこれからとるべき行動が分かりませんでした。そこで、私たちは市場を見つけなければなりませんでした。
これを使ってくれるだろうと思った人とたくさん面談し、ゲーム業界にぴったりだという事が分かりました。なのでそれに集中すると決めて、YCに応募しました。これも面白い話なのですが、YCの初日にAppleがARKitという今まで私たちが作っていたようなものを発表したのです。それが一か八かの正念場でした。私たちは、Appleと対決してみようじゃないかと決意しました。なのでプロダクトの強化に入りました。
当時はデモプロダクトや技術が携帯にしかなくて、バックエンドには何もありませんでした。なのでYCでバックエンドやAndroidに取り組んで、1年かかると考えていた作業を3ヶ月で終わらせました。それを公開して興味がある人が参加できるようにしたら、1週間で1000人くらいの開発者が参加しました。「何か見つかったかもしれない」と思いました。 その後何人かに関心を持たれてその一つがNianticだったのですが、後日買収されました。これが私たちの話でした。
Jared Friedman
では初期のSlamのアルゴリズムからユーザーが使えるプロダクトになるまでどれくらいかかりましたか？
Diana Hu
フルタイムの仕事ではなかったので、パートタイムで1年ほどでした。しかしそれでも上手くいかなかったのでフルタイムにして、そこから私ともう一人のエンジニアで6ヶ月かけました。そして夏の間に二人エンジニアを追加で雇い、その時速度を上げてうまく機能させられるようになりました。
Lillian Chou
なるほど。私たちのV1は、フルタイムで2、3ヶ月かかったと思います。その時間のほとんどは、どういうプロダクトを作るか考えることに使われていました。面白い問題に取り組もうと考えていました。当初は投資者に着目して投資する時に必要な情報を提供しようとしていました。投資先がヘッジファンドでも、公開市場でもベンチャーキャピタルでも民間市場でも。
私たちはいくつかアイデアを考えました。「投資家は、会社の四半期売上高がどうなるかの予測が知りたいのかな？」と思いました。 短い答えはイエスですがノーです。あまり持続可能なビジネスモデルではないと思ったので少し方向性を変えました。次に、「もしかしたら投資者は深く考えて自由自在にデータを変形させたいのかもしれない」と考えました。
なので早急にプロトタイプを作って投資者の友人に体験してもらいましたが、皆圧倒されてしまう事にすぐ気付きました。ユーザーは指導を必要としていました。最終的には、迅速にデータを理解するためにはどうデータを見るべきか、私たちの意見を反映できるようなセルフサービスプラットフォームを作る必要があると分かりました。
それが分かってからはとても速かったです。私の共同創業者は、フロントエンドアプリケーションの分析ピースを作る事に集中しました。そして一緒にデータのパイプラインを作りデータを変換しました。しかし私たちが早期にした重要な選択は、今あなた達が直面している事かもしれませんが、どの技術でこれを作りたいかという事です。最終的に初期のアプリはGrailsフレームワークのGroovyで作る事にしました。あまり格好良くないし人気もありませんが、私たちが一番経験豊富なコードでした。
共同創業者のMikeは、数十万人のユーザーに同時にサービスを提供する大規模なシステムを作った経験もあり、たった1週間でアプリの骨組みを完成させました。そして今までの話にもあったように、私たちもV1はもう使っていません。初期の頃には迅速に反復できる事が大切です。そのためには自分が最も知識のある技術を使うことが重要で、マーケットフィットや顧客の必要なものが理解できた時にその問題に最適な技術を選んで使えるように整理されたものを作るべきです。
エンジニアリングのベストプラクティスと速度のバランス
Jared Friedman
素晴らしい。 次に、Startup Schoolのフォームで一番人気だった質問をします。広範囲のテストカバレッジ、セキュリティ、スケーラビリティ、冗長性といったエンジニアリングのベストプラクティスと、なるべく早くプロダクトを作るバランスの取り方について教えてください。V1でどのようにバランスを取り、それがどのように変化していったか話してください。会社の成長とともにどう変わり、何が大事になったかなど。 ここで順番を逆にしましょう、Lillianが最初で。
Lillian Chou
了解。スピードが最優先事項です。素晴らしいテストカバレッジがあっても誰も相手にしてくれません、早期は必要なものを提供することが大事です。セキュリティのリスクはあってもプロダクトが動かなければ何も始まらないし、作ったものにはちゃんと毎日機能してほしいですよね。修理ややり直しの繰り返しで実際に新しいものを作っていない、という状態にはなりたくありません。
しかし、バランスも大切です。最初は開発のスピードを上げてテストで分かったことをプロダクトに組み込む事の方が、超頑丈なプロダクトを作る事よりも大事になります。あなたは人々がお金を払う価値があるもの、また実在する問題を解決できるものを見つけようとしているので、それには時間と反復が必要です。私たちが始めて以来ずっと変化してきた事です。
プロダクトマーケットフィットが見つかれば問題も変わります。システムが複雑になり、チームメンバーやコードを貢献してくれる人がより多くなり、システムが壊れやすくなるし、あなたのプロダクトに頼る人も多くなります。
それが分かった時に私たちは、それぞれのエンジニアが自分のコードの作品を検証できるようにするユニットテストを書き始めました。その後、私たちはそのコードが全体のシステムで動作することを確認するためCI/CDを導入しました。
当社のエンジニア組織をリードしているエンジニアリングの取締役は、テストやコードレビューといったベストプラクティスを開発し正式化させ始めました。その過程を決めたあとは、システムが壊れにくくするような制御を作りました。
Jared Friedman
その過程はどのくらいかかりましたか？立ち上げた2ヶ月後？2年後？
Lillian Chou
私が今話していたことはほぼ全て過去1年、1年半ほどで起こりました。
Jared Friedman
そしてそれはローンチ後何年ですか？
Lillian Chou
ローンチ後約一年半です。その主な理由は成長です。システムも複雑になりましたし技術スタッフも去年で3倍になったので、より大きな情報の処理が必要になったのです。
Diana Hu
私たちは、ある程度うまく動くMVP（minimum viable product、実用最小限のプロダクト）を達成しようとしていました。とてもぼろぼろのコードで、とても自慢できるものではありませんでした。それはただ...なんとか組み立ててやっと動いてくれているものでした。
小規模でベータ版を立ち上げて顧客を登録させた時もそのような感じでした。ベータ版を使ってゲーム開発者と協力していましたが、それもあのぼろぼろコードでした。私たちがちゃんとしたベストプラクティスを始めたのはNianticに入ってからでした。Pokemon Goのような何億人ものユーザーがいるゲームに組み込まれる事になったので。その時は皆必死に働いていました。コードベースをほぼ全て書き直したので、前あったものはほとんど残っていません。予想されるユーザー数の急増に対処するためです。
Calvin French-Owen
なるほど。Segmentでは、開発が3段階に分かれていました。最初の段階は、ハッカソンみたいに働きまくっていた時かな？間違いなくテストもCIもありませんでした。80％ぐらいの確率でそれが失敗して、2週間後には放り出して次のことに進んでいるだろうと考えていました。
私たちは苦労しながら過去一年半かけてインフラストラクチャを作り上げて設定し、新しいサービスを書いて試作して提供していたにもかかわらず、何も進歩がなかったことにうんざりしていました。私たちにはユーザーがいませんでした。ただ、私たちに「何があってもとりあえずこの時点ではユーザーを獲得する事が大事」という意識を植え付けました。
そこから始まり、最初の9、10ヶ月は迅速な反復、ユーザーの増加、資金に底をつかせない事だけを考えていました。それがなければ元も子もないので。そこから次の段階に移ったのは、エンジニアのTJと働き出した時だと思います。
今まで一緒に働いてきたエンジニアの中でも抜群でした。Nodeのコミュニティにいる人は彼を知っているかもしれませんね。Nodeのジョブの九割は彼のコードで作られていると思います。彼はSegmentに来て、私たちの作っためちゃめちゃなプロダクトを見て「こんなところで僕は働けない」と言いました。協力してもらうまで苦労しましたし、彼のパソコンを設定するのに1週間もかかりました。
それまでは開発チームの全員が同じことをしていましたが、ここからエンジニアが増えてプロダクトを作れるようになりました。それと同時に私たちの作ったものやスタックのテストやCIの質、再現性の質が高まりました。急に僕たち4人以外も関与するようになったので。そしその期間が2、3年間ほど続いたと思います。
現在から2、3、4年前の時にまた一つ段階が進み、徹底したテストやセキュリティといった顧客のデータを守るベストプラクティスについて考え始めました。その本当の理由は、今の私たちは実際かなりの売上と顧客を持っていて、評判もあるからです。初期はユーザーもいなかったので、数時間、いや1日中ダウンしても関係ありませんでした。しかし現在、私たちにはデータを磨き、保管し、整理および管理することにおいてSegmentに頼っているユーザーが何千人もいます。 なので今となってはそうするしかありません。
Jared Friedman
その最終段階ですが、どういった規模に到達してからそういう事について真剣に考え始めましたか？
Calvin French-Owen
うん、それは良い質問です。毎年6桁以上の金額を払うような企業顧客を持ち始めたとき、それが意識が変わり出した時だと思います。私たちは「顧客はこれに頼って自身の企業を動かしているから、私たちもデータの扱い方に気をつけ始めなければ」と思いました。
Ralph Gootee
私の話は他のパネリストとは少し違うと思います。これは面白いかもしれません。私は3つの面全て大事だと思います。確かセキュリティ、スケーラビリティ、そしてベストプラクティスでしたよね。PlainGridではそれぞれ別々に扱わなければいけません。
PlainGridは、カリフォルニアではほとんどの病院、刑務所、道路工事に使われています。また情報系キャンパスや政府の建物にも使われています。なのでもちろんセキュリティは大事です。初期からずっと重要でした。なので常にセキュリティやスケーラビリティを意識しないといけませんでした。顧客のプロジェクトを建てられないと私たちは何の役にも立たないので。
私たちは図面の代わりになっているので、私たちが失敗すると何も建てられなくなります。1日建設が遅れるだけで収入が大幅に影響されるような業界です。なので私たちにとってセキュリティとスケーラビリティは重要でした。
しかしスケーラビリティというのは難しいですね。どうしても反動的にしか進められないと思います。全てを超細部に設計しすぎてプロダクトを完成できないまま終わるか、のち出てくるスケーリングの問題に対処していくか選ばないといけません。私たちは、ある程度の期間持続した後に顧客がスケーリングの問題を発見してくれるように設計しようとしました。今の規模について皆にわかりやすくすると...一つのプロジェクトに50万枚の図面と500万件以上の注釈がついているような顧客がいたりします。
またオフラインでも作業できるようにデバイスのキャッシュにダウンロードします。iPadでの使用容量は、プロジェクトによっては100ギガバイトにもなります。今まで様々なスケーリングの問題に対面してきましたが、1年後まで予想して設計するようにしています。しかし3年後まで考えるのは難しいので、そこは妥協が必要です。なので、自分でそのバランスを見つけましょう。
私たちがYCにいたときに、鉄壁のようなコードを作り上げたにも関わらず市場に出すプロダクトがなかった会社についてよく聞いていたので、同じ様にならないよう意識していました。エンジニアリングのベストプラクティスについてですが、私たちのV1にあったコードの中には現在まで使っているものもあります。今までV1のコードが残っていることは、エンジニアリング組織としては少し恥ずかしいことです。
しかし同時に、私は開発者を何人も見てきましたが...私たちは、現在はCI、CD、統合テスト、UIテストなど洗練されたこともやっています。なので、これは私が過去から得た教訓です。
経験豊富な開発者は、酷いスパゲッティコード（他人に解読困難なコード）を書く事には慣れていません。彼らにとっては逆にとても難しい事です。一部の人々は最初から上手だし、ほとんどの人は時間をかけてプロダクトを作っていく過程の中でスパゲッティコードを書かないようにすることを覚えます。そしてそのコードの中にはテストなしで動くものもあるのです。
もう一つ言うべきなのは、ちゃんとプロダクトのスケーリングテストを行うべきだという事です。統合テストでデータをアップロードやダウンロードするのに何日もかかるので、機能性をテストしておいて再確認しやすくする必要があります。しかしUIとユニットテストで気づいた事があります。
私たちはユニットテストや開発のテストが大好きですが、スパゲッティコードでテストの構造を作って自分のプロトタイプをテストする開発者も今までたくさんいました。しかもプロダクトをリリースしないといけないような状況の中で。
彼らはユニットテストを書くことに時間を費やしすぎて、テストするプロダクトを実際に作る時間がありませんでした。エンジニアリングのベストプラクティスは大事ですが、テストを書くことと最初から良いコードを書くことの妥協が必要です。
開発方法論
Jared Friedman
テスト駆動開発といえば、さまざまなエンジニアリングの方法についての質問が多くありました。アジャイル開発、リーンスタートアップ、テスト駆動開発、エクストリームプログラミング。これらについてどうお考えですか？あなたの会社では特定の方法にこだわっていますか？
Lillian Chou
私たちはアジャイル寄りですね。これらの方法にはいずれも完全には従っていません。チームにとってうまくいく方法を見つけてそれを使います、アジャイルにこだわっている訳ではありません。スプリントやデイリースタンドアップなどアジャイルの要素も取り込んでいますが、やはり会社のために問題をたくさん解決していくには自分に合う方法を見つける必要があります。自分に合った部分だけを取って会社に適応させるのが良いと思います。
また成長するにつれて自分の働き方も変わってくるので、これも難しいですよね。お互いをよく知る4人ほどの小さなチームで働くことと、30人、50人、また数百人以上のチームで働くことは全然違います。なので常に「今の会社の段階で、この方法で仕事をして良いのか」考える必要があります。
Diana Hu
私たちも作業プロセスをいつも進化させています。昨年はわずか4人のエンジニアでプロダクトを作っていました。なので皆なるべく速く働こうとしていたし、非常に乱雑でした。記録はしていなくて、ホワイトボードに書いたものについて皆で考えてなにかを作り上げようとしていました。またスプリントもしませんでした。それを好まないエンジニアもいたし、一人一人に大きなエリアを任せていたので皆の負担が大きすぎることもありました。
しかし今は違います。ARプラットフォームのプロダクトのために前の3倍の従業員を雇いました。チームの人数が増えたので効率的に連絡できるプロセスが必要になりました。仕事が重複してほしくないし、皆が全てを知っている訳ではないしシステムが複雑になるので。前は記録なんてしていなかったのですが、今は記録がたくさんあります。
前は少しだけCIを使っていましたが今はLinux、Mac OS、Android、X86、Android ARM、iOSなどの構成のほとんどにCIをつかっています。また全てをテストして多くのバグを見つけてくれます。これらの事をカバーした上で、プロセスが増えてもチームが作業できるようにしないといけないので、スプリントまでとはいきませんが1週間ごとの計画を立てています。再招集した後に、チームがサブチームに分かれていきます。人々は色々な事業を行き来しています。
私たちは主に3つの事業に分かれています。1つはバックエンドで、2つ目はクロスプラットフォームにするために取引先と一緒に働きAPIもしています。もう一つの大きめの事業は、コンピュータービジョンのアルゴリズムの補正です。
面白いのは、チームにいる人皆が結局はコンピュータービジョンのエンジニアになるということです。それが主なので。 サーバーにはCVアルゴリズムがありますし、顧客のところにもCVアルゴリズムのような大事なアルゴリズムがあります。
今までの結果からこうなりましたが、別に方法を決めていた訳ではありません。現在NianticはOKR（目標と主要な結果）を実施しているので、私たちも四半期ごとにやっています。今私たちはより長い計画やアイデアを練りはじめています。前はなんとなく方向性を決めていたぐらいだったのが、今はしっかり計画しています。
Calvin French-Owen
特にSegmentでもこれといった方法にこだわっている訳ではありません。私たちは、Spotifyのように別々のエンジニアチームがあります。チームごとに自己管理や方針を任せています。
スプリントしたければできるし、JiraまたはAsanaを使ってもいいし、自分の好きな方法で作業できます。私たちが過去2年間に導入したことの一つは、先ほど同様にOKRモデルです。
知らない人のために言うと、これはGoogleで開発されたモデルです。Objectives（目標）のOと、Key Results（主要な結果）のKRです。まず目標を決めた後主要な結果を予想する事で、目標達成できたか客観的に評価することができます。全ての主要結果を足すと、目標全体と重なるはずです。これは私たちが会社全体で取り組んでいることです。
それぞれの四半期の1週間前に会社内の全てのチームが集まってOKRを決め、その計画に沿って3ヶ月間行動します。チームによっては毎週「自分はゴールに近づけているか」を自己評価しています。 月ごとに自己評価するチームもあります。しかし四半期の終わりには、すべてのチームが「私が決めていた目標に対してここまでできた」と言います。
私が作業しているチームでは、今週は何を達成したいかを毎週ミーティングで決めています。またデイリースタンドアップもあります。常に最も重要な問題の議論しさえすれば、会議の内容についてはあまり気にしていません。ツールやプロセスは私たちに仕えるものであり、その立場が逆になってはいけません。
Ralph Gootee
PlainGridでの私の経験も他のパネリストと似ていて、アジャイル寄りの自己管理です。チームそれぞれが自分の使いたいツールを選べます。しかしどのチームもずっと重宝していることの一つにデイリースタンドアップがあります。あなた達にも役立つかもしれません。日常的に話し合うことが大事です。
エンジニアとして、起きてすぐプログラミングに取りかかる前に他人と話し合うということは面倒です。しかし15分間だけでもSlackのようなオンライン上でも良いので、人と繋がることは大いに有益です。
タイムボックス。多くのマネジメント慣行は抽象的な理論になりがちです。スプリントはタイムボックスの方法の一つです。延々に一つのものに取り組む事を防ぎ、皆に現状を把握させられます。私を含め皆予想が外れることはよくありますし、1週間かかると思ったものが1ヶ月以上かかることもあります。
なので、タイムボックスをすることによってしっかり確認できます。 また今から実践できる小さい管理技術は、毎週の個人面談です。グループでスタンドアップをしているなら、ちゃんと個人個人とも関係を築くようにしてください。彼らの要求、ニーズ、気持ち、キャリアなどについてもっと知りましょう。
Jared Friedman
良いですね。では、非技術系の共同創業者と協力する時にすべきことに話を変えましょう。Startup Schoolのフォームで一番聞かれた質問はRalphが少し話したことでした。特に非技術系の共同創業者と、締め切りや時間配分をどう管理するべきですか？特に初期の段階で。誰か意見がある人？順番は何でも良いですよ。
Ralph Gootee
非技術系共同創業者があそこにいるので、私からいきます。いくつかあります。特に本当に非技術系の人の場合は...まあ彼女はパソコンぐらいは使えるでしょうが...本当に非技術系だった場合は、素晴らしいテスティングの機会です。
私がソフトウェアを作ってウキウキしながら彼女に見せても、彼女がいじった途端に壊れるということがよくありました。iPadを振ったり3回回転させたり、どういうわけかいつも僕の作ったものを壊す方法を見つけていました。素晴らしい初期テスティングになっていました。それがあなたの非技術系共同創業者と協力する一つの方法です。
また最終的に自分の締め切りを決めだす必要がありますが、それは本当に難しいことです。私は常に楽観的なのであまりうまくいっていません。今でも「まあ1週間もあれば終わるかな」と考えてしまいます。 私が楽観的だからうまくいかずに1週間ほど遅れてしまう事を自覚していますし、彼女もわかっています。
私が話した他のエンジニアリーダーは、非技術系の共同創業者に伝える用と自身に言い聞かせる用で二つの期限を作っています。共同創業者に「これが期限」と言っておいて、それとは別に実際はどれくらいかかりそうか自分で予想しておくのです。また、「ここではテストして、ここでリリース」というような大まかな過程を決めておくことも有益だと思います。
例えば、iOSのリリースサイクルは開発者ではなくAppleにコントロールされているという事を知らない人も多いのではないでしょうか。なのでそれを考慮しながら計画しないといけません。非技術系の共同創業者がいる場合は、少しのプロジェクト管理が大いに役立つ場合が多いです。共同創業者が管理が得意な人だったらそれも一緒に働く良い理由ですね。
Calvin French-Owen
私の共同創業者は技術者ばかりなので初期の頃でもあまりそういう悩みはありませんでした。何か問題が起きても皆状況を把握していたのでそれほど困りませんでした。私が最近締め切りを決めるためにやり始めたことは個人面談です。
一人一人に、今から3、4週間でどこまで進めると思うか聞きます。個人面談で分かることは、第一に、他人の答えに合わせられないので正直な意見がもらえます。一人一人に今後短期間で何が起こるか考えさせられます。
そして第二に、皆自分がやってない所に関して慎重になるので、トラブルスポットがどこにあるかわかりやすくなります。最終的には大体いつも3、4人の答えの平均が正解だと明らかになります。なので、皆に今後の動きについて考え予想してもらうことによって、より的確な締め切りを設けられるようにし始めました。それらの平均が大体の締め切りになるべきです。
Diana Hu
私の場合は、共同創業者はエンジニアではなく、プロダクトの作成も出荷もしていません。PhD生で、ほぼリサーチのみでした。プロダクトの作成や出荷の経験がないという意味で、少し非技術的ですね。主にアルゴリズムの方しか触っていないみたいな。
なので、なぜ作るのに時間がかかる物があるのか、またなぜ特定の方法で作る必要があるのかを分かってもらうのに少し苦労しました。しかしある時点で私に任せてくれる様になりました。そして、彼はパートナーを探すなど外部との連絡を積極的にしてくれました。
このように、技術的創業者がプロダクトや開発の管理を任せられることもあります。そして、明確なコミュニケーションをとり未来を予想することも難しいです。エンジニアリングとプロダクトと経営のバランスをいつもとらないといけません。いつ何をするか決めて、それを明確に話し合う必要があります。
Lillian Chou
私の共同創業者も技術者なので、あまり言えることはありません。締め切りや予想についても特にありません。なるべく近い予想をして、余裕を持ってください。非技術系の共同創業者について一つ言っておくべきだと思うことがあります。あなたが技術系の創業者なら、おそらくあなたがプロダクトのコードを書いているのでしょう。
私の経験では、それはいつか変わります。私は会社に入ってから1年ほどでコードを書く事をやめました。会社に勢いがつき始めた頃に、私の様なリーダーによく起こる話です。皆そうではないかもしれませんが。市場に合うプロダクトを作る事ではなく、会社を作ることが中心になります。あなたが関与していなくても沢山の人が長く使えるものを作れる様なシステムです。
私が言いたいことは、いつかあなたにも非技術的な仕事が増えるかもしれないから、心の準備をしておくべきだという事です。
エンジニアの採用と組織構造
Jared Friedman
素晴らしい。Startup Schoolの会社の多くは、初期エンジニアチームの構造をどうするべきか考えている段階にいます。現地で採用するかリモートワークにさせるか。フルタイムの従業員のみを雇うか、商品の一部を請負業者や第三者の開発会社に任せるか。あなたが今会社を立ち上げるとしたらどう考えるか教えていただけますか？アドバイスしてください。これを最後の質問にして、あとは観客からの質問にします。
Lillian Chou
私が始めますね。私たちは請負業者に頼らず、フルタイムの従業員を雇う事で始めました。私の主なアドバイスとして、あなたはプロダクトや会社を作って会社の能力を上げようとしています。それを委託してしまうと、技術の知識だけではなく顧客の要望やプロダクトの情報など初期で学べる事を学ぶ機会がなくなります。初期から会社に外部の人を関与させると、色々な知識の損失になります。
まだ立ち上げたばかりで、委託を通して採用する可能性のある人を査定するという人もいるかもしれません。確かにその方法も可能です。 しかし、それはあなたのチームを作り上げるための事ですよね。似たように、外部委託する前にも自社の強みや知的財産は何なのか考える必要があります。そこを外部委託してしまうと、ただのマーケティング会社になってしまいます。
また...ビジネスモデルによって異なる要件があるので、会社によっては自分が作っているものの大部分を外部委託することが正しいかもしれません。私たちも少しだけ外部委託を試してみたことがあります。 プロジェクトを明確にしておきつつ、進路を完全に決定させないようにして色々試せる様にしています。外部委託するということはいつもと違うプロジェクトなので、自分の会社にそれが合うかどうか見定められます。合ったら素晴らしいし、合わなくても気にしないで。リモートワークについての質問もありましたか？
Ralph Gootee
はい、現地採用とリモートワークについて。
Lillian Chou
どのような企業文化を作りたいかによります。私たちにとってはチームと一緒にいることが大切なので、現地採用でした。その後、ここ一年ほどでリモートワークのエンジニアも雇い始めました。それによって企業文化も少し変わりました。
まだ主に現地採用ですが、豊かな人材プールから選べるなどリモートワークの利点も多いです。またちゃんとコードの説明や決断をした理由などの記録をする良いきっかけになりました。会社が大きくなるにつれてコミュニケーションが難しくなるので、これは良いことです。そんな感じです。
Diana Hu
私たちの場合は、会社の主力が技術自体にあるので、外部委託はあまりしませんでした。採用プロセスとして契約をしたことならあります。1ヶ月ほど契約をして一緒に働いてから採用のオファーをするのです。私たちはそうしていました。
しかし、会社の本質ではないと思ったことは外部委託しました。 例えば、3Dモデル、デザインの一部、技術文書の作成、Webサイトなど。やりたければ自分でできた事です。私がWebサイトを作ってもよかったけど、もっと主要なことにその時間を使うべきです。なのでそこは外部委託しました。
そして、現地採用対リモートワークの面では、私たちは作るものが複雑なので全て現地採用でした。今でも現地でチームを集めています。しかし、人によります。リモートワークさせる会社も多くありますが、最初からリモートワークでないといけません。
Calvin French-Owen
私も共有できることがあります。初期はフルタイムでしか雇っていませんでした。請負業者を試すことはしませんでした。唯一外部委託していたのは、AWSに私たちが作っているインフラストラクチャや新しい機能を載せて、そこから作業するということです。あれは正しい判断だったと思います。スタートアップ初期の頃は不安定だし、同じ方向性を持っていて長期戦に備えているような人達がたくさん欲しいですよね。
現地採用対リモートワークに関しては、実はリモートのみでの採用を始めました。GitHubでいくつかのオープンソースのコミュニティに関わっていました。特に初期はNodeやJavaScript、Componentなどがありました。この人たちとは何年間も共同作業していたので、採用が始まった時には単純に「私たちにもっと大きく関わる気はない？」と聞きました。 妥協している部分もありますがね。
利点としては、サンフランシスコのベイエリアにいなくても才能に溢れている人と共同作業できたという点があります。すでに一緒に働き慣れている人々だし、Segmentにとっても大きな資産になってくれています。
しかし難しいのは、コミニュケーションを図ることや皆を同じ方向性に保つことです。最初の10、15人の採用はリモートワーキングでしたが、その後の70人ほどは現地採用にしました。
そして、ごく最近リモートワーキングの採用をまた始めました。現代では、記録やコミュニケーションを重宝した良いリモートワーキング文化を作るためのネット回線容量がありますし、何年間もリモートワーキングしていた人を実際に採用できます。
Ralph Gootee
パネリストの皆良いアドバイスをしていますね。私は、妥協について一番意識しておくべきだと思います。請負業者の話に戻りますが、それについて短い話を一つ。最初に採用した二人は個人請負でした。
一人は請求書やオフィス関連の手伝いをしてくれて、もう一人は技術開発の面で手伝ってくれました。私がジョン・ホプキンズ大学で働いていた時の同僚でした。最初は個人請負だったのですが、私の友人だったので彼に支払うお金はなく株式で報酬を支払っていました。最終的には最初のエンジニアとして会社に参加して主要な技術を作り上げてくれて、PlainGridにとっても素晴らしい力になりました。
なのですぐに請負業者を雇うべきだとは思いませんが、私たちは当時の会社の大きさや必要なものを考慮した時に道理にかなった選択をしました。「この人に色々作っててもらわないといけないし、報酬が株式でも受け取ってくれるから良いや。それ以外に報酬を支払う方法もないし！」 今自分の会社に何が必要なのか、先入観なしで考えましょう。請負業者には妥協がつきものです。
また、今は私の友人の話でした。別に雇った請負業者もいます。 無知な事を言いますが...今でも請負業者を雇うと「この人は管理しなくても大丈夫」だとつい考えてしまいますが、これは誤解です。創業者にとって、請負業者の管理も大切です。ちゃんと雇っている人なので。時にはそれはフルタイムの従業員よりも請負業者のためにより多くの時間を費やすこともあります。それを覚えておいてください。
リモートワークも面白いトピックですね。会社を立ち上げた頃はサンフランシスコで人を集めようとしていたのですが、私と共同創業者が数ヶ月間ほど別行動する事もあると気づきました。「ちょっと1ヶ月ぐらいシカゴに戻るわ」って。 別に共同創業者の一人がシカゴから仕事をしていても構いませんでした。今までの8年間で、リモートワークを認めたり認めなかったりを繰り返してきました。リモートワークをするのが友人やトップレベルのすごく優秀な人だったら許すとか。
現在は会社はこの点に関してはとてもオープンなので何でも構いません。管理職がリモートでも良いし現地でも良いし、デザイナーも商品も皆何でも雇います。ただ才能ある人を探しているのです。 ベストアドバイスは、先ほど言っていましたが今の会社の大きさに一番合った事をするべきだという事。どの決断にも妥協はありますが、簡単な答えは存在しません。
Q&A
Jared Friedman
ありがとう。では観客からの質問に1つか2つ答えられると思います。 質問ある人？質問ある人？そこのあなた。そう、君です。
やり直すとしたら？
Speaker 7
もしまた新しい会社を作るとしたら、どのように開発のプロセスを加速させますか？ 前回と何を変えますか？
Jared Friedman
まず、皆に聞こえるように質問を繰り返しますね。もしまた新しい会社を作るとしたら、どのように開発のプロセスを加速させますか？答えたい人？
Diana Hu
はい。私の場合は、技術を作ることに時間を費やしすぎました。なのでなるべく早くプロダクトマーケットフィットを見つけましょう。これはあなたが選ぶ分野によっては難しいもしれません。ARやVRやバイオ技術のような最先端技術は、どうしても開発に時間がかかってしまいます。あと、どのような会社にしたいかも考えましょう。
Lillian Chou
常にユーザーの目に入るようにしましょう。ユーザーベースを見つけましょう。自分の世界に入って共同創業者と「どうしたら良いのかな。これが良いかな。これはダメかもね。」と二人で考えているだけではなかなかプロダクトは作れません。 実際に誰かに見てもらって良いか悪いか感想を聞く方が簡単です。 フィードバックは本当に貴重です。
Calvin French-Owen
そのユーザーについての考えに同意です。ユーザーの前に出て色々見せてください。深く掘って、本当に彼らの問題を解決できているか確認してください。
私がまた会社を立ち上げるとしたら、使用しないつもりのバージョンを2、3個作ると思います。今までの経験から個人的に考えている事かもしれませんが、もし安定した基礎があり準備ができた時にV1を集中して作れるようであれば、それは強みになります。
Ralph Gootee
私はモバイル開発もSwiftもKotlinも大好きですが、次回は4つものプラットフォームに書くことはしないと思います。クロスプラットフォームのライブラリの一つを選ぶだろうと思います。どれが一番良いかはわかりません。教えて欲しいぐらい。もし誰か...この後に、どれが一番か強い意見があったら教えてください。どれにも妥協点がある気がします。
私の1番のアドバイスは、少し早めにコードを書くのをやめて採用を始めましょう。当時の私は色々な機能をどうしても作りたかったのですが、もしあの時他の開発者を採用していたらもっと速く作れていたと思います。
Jared Friedman
面白いね。さて、あと一問。あそこ。
非技術系の創業者とのコミュニケーション方法
Speaker 8
非技術系の創業者として、新しい機能の実装について、技術系の創業者またはCTOと何を話し合うべきですか？CTOが安定性やスケーラビリティに集中していて、あなたがユーザーが求める機能を推したい場合、どのようにコミュニケーションをとれば良いですか？
Ralph Gootee
電話したりミーティングに連れてきたりして、ユーザーと会話させましょう。そして、自分が求めているフィードバックに誘導させるような質問をしましょう。もし想像と違う答えが帰ってきたら、そこにも見直すことがあるかもしれません。などでユーザーとの接触を多くさせましょう、これが私の中では一番の方法です。
Jared Friedman
では、皆ありがとうございました。素晴らしかったです。
記事情報
この記事は原著者の許可を得て翻訳・公開するものです。
動画: Startup Technology - Technical Founder Advice (2018)
トランスクリプト: Startup Technology: Advice for Technical Founders
