00:00:00 スタートアップの技術監査入門
00:01:42 VCがどのようにしてJoannesを技術監査へ導いたか
00:03:24 収益源としての技術監査
00:05:08 スタートアップにおけるソフトウェアの評価
00:06:36 Joannesの機械学習の経験
00:08:50 技術監査の主要な側面
00:10:02 セキュリティ対正確性のトレードオフ
00:11:46 投資家向けレポートの効果的な作成
00:14:57 チェックリストを超えたスタートアップの評価
00:17:04 ビジネスコンテキストに合わせた監査の適応
00:20:24 CTOへのインタビューとライブでのコードレビュー
00:24:12 開発者の親和性とリーダーシップの評価
00:28:22 開発者の能力の判断
00:30:49 コード品質の注意すべき赤信号
00:33:47 コミット履歴からの洞察
00:37:03 クラウドコストの持続可能性
00:42:14 LLMがNLPスタートアップを混乱させる
00:46:29 儲かるソフトウェア市場の発掘
00:50:32 技術的負債のリスク
00:55:34 スケーラビリティへの過剰投資
00:59:59 明快な文書は優れたエンジニアリングを示す
01:04:08 なぜ投資において技術監査が稀なのか
01:07:12 締めくくりの言葉

要約

最近のLokadTVのエピソードで、Conor DohertyはLokadのCEOであるJoannes Vermorelに、スタートアップの技術監査に関する10年以上の経験についてインタビューしました。Vermorelの「ライトニング・テック監査」は、従来の方法とは異なり、動的かつ文脈に即した評価に注力することで、ベンチャーキャピタリストに技術スタックの専門的な評価を提供します。彼のプロセスは、CTOやエンジニアリングチームとの面談を含む、集中的な1日間の評価により、コードの品質やチームの機能性をチェックします。Vermorelは、情熱、明確なドキュメント、そして賢明なリソース活用の重要性を強調しており、その洞察は業界における重大な見落としを明らかにし、投資家とテック起業家双方へのベストプラクティスを際立たせています。

詳細な要約

最近のLokadTVのエピソードで、LokadのコミュニケーションディレクターであるConor Dohertyは、LokadのCEO兼創設者であるJoannes Vermorelと対談し、Joannesのあまり知られていないが非常に影響力のある活動、すなわちスタートアップの技術監査について深堀りしました。過去10年以上、Joannesはこれらの監査を実施し、ベンチャーキャピタリストに対して投資候補の技術スタックに関する専門的意見を提供してきました。Joannesが「ライトニング・テック監査」と呼ぶこの手法は、技術業界における最良と最悪の実践について独自の視点を提供しています。

Joannesの技術監査への道のりは、Lokad初期にベンチャーキャピタリストの導入を検討していた際に始まりました。正式な投資家を迎え入れることはなかったものの、初期の頃に多くの投資家と話をする中で、他のスタートアップの技術面を評価する専門知識を提供する道が開かれました。この転換により、時間のかかる面談を、投資候補となる企業の技術スタックに関する専門家の意見を求めるベンチャーキャピタリストへの貴重な営業機会へと変えることができたのです。

Joannesの監査プロセスの核心は、一日で完結する集中的な評価であり、従来の監査手法とは大きく異なります。標準的なアプローチがチェックリストに依存するのに対し、彼の手法は動的で、各スタートアップの具体的な状況に合わせて調整されています。まずCTOとの20分間の面談で企業の技術状況を把握し、その後、エンジニアリングチームとの一対一の面談を通じて、残りの時間を費やします。この実践的なアプローチにより、コードの品質だけでなく、チームが自社技術を扱う際の流暢さや一貫性も評価できます。

Joannesは、自身の目的が企業の技術に精通することではなく、チームが機能しているか、技術的方向性が妥当かを評価することにあると強調しています。彼はコードベースのパターン、コミット履歴、そしてドキュメントの品質を注視します。例えば、コーディングスタイルの一貫性やコミットメッセージの明瞭さを確認することで、コードベースの品質を迅速に評価できます。また、スタートアップにとって重要な、限られたリソースを賢明に活用しているかも評価対象です。

Joannesが示した最も衝撃的な洞察の一つは、テック企業が複数回の投資ラウンドを経ても、その技術が真剣に検証されることがほとんどない頻度です。後の投資ラウンドにおいても、技術スタックが疑問視されることなく、そのままであることに彼は呆れています。この十分なデューデリジェンスの欠如は、かつてTheranosで見られたように、重大な見落としを招く可能性があります。

Joannesはまた、技術開発における情熱と配慮の重要性について語りました。彼は、配慮の欠如がテック企業にとって致命的であると考えています。CTOやエンジニアリングチームが自社技術に真摯な情熱を注ぐと、その情熱は仕事の質や一貫性に現れます。逆に、企業が開発をフリーランサーに委託するか、技術への深いコミットメントが欠如している場合、結果はしばしば破滅的になります。

ベストプラクティスの観点から、Joannesは明確な文書作成とドキュメントの重要性を強調しました。コード内のコメントであれ、チケットでの問題定義の明瞭な表現であれ、明快さと簡潔さは、よく機能するチームの重要な指標です。また、彼は珍しいながらも適切な技術の利用を評価しており、これは技術環境に対する深い理解と最適な解決策を模索する姿勢を示しています。

Joannesの技術監査へのアプローチは、慣例からの新鮮な逸脱であり、各スタートアップの実情と具体的なニーズに焦点を当てています。彼の洞察は投資家とテック起業家双方にとって貴重な教訓を提供し、情熱、明確さ、そして各社に合った技術開発アプローチの重要性を浮き彫りにします。技術業界が進化し続ける中、Joannesのライトニング・テック監査手法は、技術革新の真の可能性を評価するための堅実なフレームワークを提供しています。

フル・トランスクリプト

Conor Doherty: LokadTVへようこそ。またお会いできて嬉しいです。本日は、Lokadの創設者兼CEOであるJoannes Vermorelをスタジオにお迎えしています。彼のユニークなサイドクエスト、すなわちスタートアップの技術監査についてお話しします。実は、多くの人はご存知ないかもしれませんが、Joannesは約10年にわたりソフトウェア企業の評価、すなわちコードやインフラ、スタッフ、リーダーシップに至るまでをチェックしてきました。彼と私で、ベストプラクティスやこれまで学んだことについて議論します。いつものように、私たちの発信する内容を気に入っていただけたなら、YouTubeチャンネルの登録とLinkedInでのフォローをお願いします。それでは、今日のJoannes Vermorelとの対談をお届けします。Joannes、ようこそお戻りください。導入で申し上げた通り、今日は普段のテーマではなく、なおも大きな関心を呼ぶ内容について話しましょう。あなたは多くの技術監査を行っている、ということでよろしいでしょうか?

Joannes Vermorel: はい、そしてそれは10年以上、恐らく約14年続いています。

Conor Doherty: ところで、これがどのように始まったのか、正確にはどんな経緯なのでしょうか?LokadTVをご覧の皆さんは、既にあなたがサプライチェーンやその関連技術について語っているのに慣れ親しんでいると思います。しかし今回の件はおそらく初耳でありながら、あなたは10年間続けていると言います。サイドクエストとしては微妙なものですが、一体どのように始まったのですか?

Joannes Vermorel: Lokad初期の頃、私はベンチャーキャピタリストの導入、すなわち投資を受け入れる可能性について検討していました。最終的には正式な投資家を迎え入れることはしなかったものの、初期には多くの投資家と話をしました。しばらくすると、メールのやり取りで「一杯のコーヒーでもどうですか?」という誘いが来るようになりました。投資家と会い、会社や投資への関心を語り合うのは時間がかかるため、「この潜在的な投資家との面談に時間を費やすのは、製品開発や販売に充てる時間が失われている」と気付いたのです。そこで、「彼らに何かを提案してみては?」と考え、ベンチャーキャピタリストとの面談を営業ミーティングのように扱うことにしました。もし彼らが興味を持てば—私は現金を必死に求めているわけではなく、それゆえ彼らにとって最適なスタートアップではないことを伝えましたが—他の投資対象について専門的な意見を必要とするなら、私がその役割を果たせる、と話したのです。私の専門は、他のスタートアップを見て儲かるかどうかを判断することではなく、それは非常に難しい作業ですが、技術スタックについて、教養に基づいた意見を持つことには自信がありました。ベンチャーキャピタリストがテック企業に投資する際、多くの場合、その企業の評価額の大部分は開発中の技術に依存しています。本当に価値のある技術なのか、創業者が要求するプレマネー評価額に見合うのか――そうして、結果的に私はこれらの技術監査を始めたのです。月に1回、時には2回程度、12年か13年近く続け、多くの企業を監査してきました。その評価は非常に短時間で行われます。ちなみに、「どうやってその時間を捻出するのか」と尋ねられますが、私は一日で完了するライトニング・テック監査として実施しているのです。

Conor Doherty: この点については必ず後ほど戻り、あなたのアプローチが従来のコンサルテーションサービスとどのように異なるのか、その影響についても掘り下げます。ただ、「専門家の意見」や「専門知識」といった言葉を用いている以上、あなたにどのような資格があるのかをご存じでない方々のために、これまでの実績を概説していただいても構いません。

Joannes Vermorel: 私は長い間、ソフトウェア技術に情熱を注いできました。小学校でプログラミングを始め、中学校や高校では、より洗練された技術に触れながら腕を磨き、常にソフトウェアに関するあらゆることに興味を持ってきました。これらの監査を始めた頃、私はまだ30歳には達しておらず、その年齢に近いものでしたが、既に自身のプロジェクトはもちろん、大学や他社でのプロジェクトを通じて、約10年分のプロフェッショナルなソフトウェア経験を積んでいました。

Conor Doherty: ところで、あなたはアメリカのAT&T Labsでもしばらく働いていましたね。それは、彼らが機械学習のパイオニアであった時期で、1990年代に機械学習を開始していた時代でした。

Joannes Vermorel: はい、人工知能が流行するずっと前から、彼らは機械学習に着手していました。もちろん、この分野に携わる人々はいましたが、私の関心のごく一部に過ぎません。企業の監査を行う際、機械学習はしばしば問題のごく一部にすぎず、場合によっては全く関係ないことも多いのです。企業はソフトウェア企業であったり、ソフトウェアを大規模に活用するバイオテック企業、オンラインギャンブル、B2B向けの生産性向上アプリ、さらには病院の手術室に設置された医療機器に組み込まれる埋め込みソフトウェアなど、多種多様です。いかなる場合もコアはソフトウェアであるものの、各スタートアップで採用される技術は大きく異なります。ここに、私の真の専門知識があると考えています。

Conor Doherty: 技術監査を行うというと、人々はその概念をある程度理解していると思います。しかし、具体的には何が含まれているのでしょうか?どの分野に焦点を当て、ソフトウェアだけなのか、それとも人材も評価しているのか、一体何が含まれているのですか?

ジョアネス・ヴェルモレル: 成果物とは、まず提供されるもの、つまり投資家に返すメモです。ベンチャーキャピタリストは、スタートアップに投資しようとしています。通常、すでに署名された意向表明書を持っており、企業に200万から2000万、時にはそれ以上のドルまたはユーロを投入しようとしています。評価の大部分は、彼らが投資する技術に依存しています。彼らは、既に何かを開発したとされるチームに投資しているのです。私はシードステージの監査は行わず、ここで話しているのはシリーズA、あるいは時にはシリーズBの段階です。つまり、この段階では通常、すでに何かを開発している人々が対象となり、それが高い評価額の正当性を与えています。さて、問題は、その人たちが要求する価値に見合うかどうかです。価値とは、彼らが持っているものだけでなく、投資家から資金を受けた場合にロードマップの目標を達成できるかどうかという、企業内の技術的ダイナミクスにも依存します。人々は、企業が現状どのようなものかだけでなく、何よりも明日どのような企業に成長するのかに投資するのです。彼らの財務予測が正しいかどうかは私には評価できません。私の専門は、例えばギャンブル市場の未来にあるわけではありません。分かりませんし、それは他の人が判断するべきことです。しかし、もし彼らがギャンブル用のアプリを見せてくれた場合、そのアプリが安全かどうかを確認する必要があります。というのも、ギャンブルの場合、極めて安全でなければならないからです。これが私が答えることのできる質問です。もしそれが手術中に使用される機器であれば、正確性は絶対に不可欠です。文字通り、もし機器が故障すれば、患者を命の危険にさらす可能性があるのです。こうした課題は全く異なります.

コナー・ドハティ: 先ほどの例に戻ると、セキュリティの例やあなたのジャケットの件は理解できましたが、手術用機器の件については、正確性をどう評価するのか、信頼性は十分あるのかという点で、あなたの見解を教えてください.

ジョアネス・ヴェルモレル: これは単なるセキュリティ問題ではありません。なぜなら、これらの機器はネットワークから隔離され、ITの観点からすでに非常に安全な環境、つまりネットワーク接続がない状態で運用されるためです。しかし、問題は、機器が確実に動作することを脅かすようなグリッチやバグ、その他何かが発生しないことをいかに保証するかという点にあります。現在、多くの機械は自動化されています。もし、患者に何らかの液体を送るポンプを操作するのであれば、故障していないか、あなたが求める通りに正確に動作しているか、どうやって確認するのでしょうか。つまり、私が成果物に対してアプローチする方法は、意見を形成することです。それが、企業の価値についての私の全体的な見解を投資家に返すメモとなるのです。そして、それこそが本当に重要な点です。私は、企業が何を達成しようとしているかに基づいて、その価値がいかにあるのかという意見を築こうとしているのです。もしあなたがビデオゲームを開発しているのであれば、「非常に中毒性があり、魅力的で、楽しく作られているのか」が問題となります。これがあなたのエンゲージメントの条件です。もし、新たな診断技術を持つバイオテック企業で、従来の方法よりも早く正確に病状を診断できるというものであれば、それは実際に機能しているのでしょうか? 本物でしょうか? 信頼できる統計はあるのか? 経験的な結果が理論に沿っていることを示すプロセスは揃っているのか? もし生産性向上アプリ、特にB2Bアプリであれば、何百、あるいは何千もの機能やマイクロ機能をどうやって管理するのか、という問題が生じます。企業向けアプリは、対応すべきケースが多すぎるため、機能が迷路のようになりがちです。企業はこの複雑さをどのように管理しているのでしょうか? 自社の複雑さに溺れているのか、それともうまく整理されているのか? どのスタートアップを監査するかによって、価値提案やその本質といったエンゲージメントの条件は大きく異なります。私の成果物は、最も重要な点についての意見を形成し、それを投資家に返すことにあります。監査中にこのコアバリューの提供を脅かす何かを見つけた場合、必ず指摘します.

コナー・ドハティ: 改めてですが、あなたは約10年から12年この仕事をしてきたと言っていました。月に1〜2件として、少なくとも100件以上の監査を行っていることになります。では、主な案件はどのようなものなのでしょうか? ギャンブルアプリの監査もあれば、医療機器の監査もあるとお話しされましたが、これらの分野は全く異なります。監査の際の典型的な雰囲気や、主に扱っている案件はどのようなものですか?

ジョアネス・ヴェルモレル: 基本的にはソフトウェア企業で、ソフトウェアを開発している人々が対象です。時には、機器向けのソフトウェアを開発するなど、物理的な要素が多少絡むこともあります。また、統合すべきサードパーティ製のソフトウェアがある場合もあります。単体で動作するアプリなのか、多くの他システムと連携しているのか、状況はさまざまです。明らかに、私が手がけた案件の約3分の2はB2Bまたは専門機器系で、残りの3分の1がB2Cに該当します。ただし、これが分類の一端に過ぎず、その他は非常に多様です.

コナー・ドハティ: なるほど、成果物とあなたの経歴について効果的な大局的視点をいただきました。しかし、主要なプロセスとして、どのようにして意見を形成し、そのメモや見解に到達するのか、手順を教えてください.

ジョアネス・ヴェルモレル: ここで、私のアプローチは一般的な監査プロセスとは大きく異なります。簡単におさらいすると、監査を行う人の99%はチェックリストを持っており、数百の質問が並んだ長いチェックリストを用意して、企業に「これをやっていますか、あれをやっていますか?」と尋ねます。はい、いいえ、はい、いいえ、といった具合に。監査人はそのリストをただ淡々とこなすだけです。私の見解では、このプロセスは特にスタートアップの技術監査においては全くの無意味なものです.

このチェックリストというものは、たとえ何であっても、スタートアップ自身の条件を問うものにはならないという問題があります。例えば、ゲーム会社が非常に安全であるかどうかを問いただすのは全く無意味です。ビデオゲームの場合、セキュリティは二次的な関心事に過ぎません。スタートアップではリソースが乏しいのです。大半のビデオゲームが、ユーザーの利便性を損ねるほどの重いセキュリティ機能に多大な投資をし、セキュリティ担当者を雇うことに意味があるでしょうか? カジュアルなビデオゲームなら全く意味がありません。誰もFarmvilleをプレイしている事実に関心を持たないのです. The bottom line is that having checklists is a recipe to be a massive waste of time for the founders and a massive distraction for the investors themselves. They might say, “Oh, the startup is compliant with hundreds of irrelevant items,” and then you would say, “Oh, but they’re not compliant on these 100 items,” which are also completely irrelevant to the success of the company. My take is that they have a business case; they say they want to go in a certain direction business-wise. I let other people assess if there is money to be made. I don’t assess that. I mean, yes, I have my own opinion on whether it seems plausible, but I don’t challenge the size of the market. My take is that, okay, let’s assume there is a market and that if you execute this thing excellently, there will be people to serve, and those people will be willing to pay you. 結論として、チェックリストを持つことは創業者にとって莫大な時間の浪費であり、投資家にとっても大きな分散要因となります。投資家は「このスタートアップは何百もの無関係な項目に準拠している」と評価するかもしれませんが、同時に「しかし、この100項目には準拠していない」と言われても、それらは企業の成功に全く影響しない要素です。私の見解では、彼らにはビジネスケースがあり、ビジネス的に特定の方向へ進みたいと主張しているのです。利益が見込めるかどうかは他の専門家に判断させ、私はその判断をしません。確かに、妥当かどうかについて自分の意見は持っていますが、市場規模に異議を唱えることはしません。つまり、市場が存在しており、この事業を優れた形で実行すれば、顧客が現れ、彼らが支払う用意があると仮定しているのです.

コナー・ドハティ: そして、あなたはそのレベルの洞察を提供する立場にあるのですね。技術について憶測を述べることができるわけですが…

ジョアネス・ヴェルモレル: 監査人と比較すると、私の場合は、1日の始まりに最初の20分間で通常CTOのインタビューを行います。その20分以内に、議論を最も重要な事項に導くための一連の質問を頭の中で組み立てる必要があるのです。20分のプレゼンテーション(通常はカジュアルな会話形式)が終わった後、残りの時間は、コンピューターの前にいる誰かからコードベースを見せてもらう一連のインタビューで進めます。つまり、同じ画面を見ながら行う1対1のインタビューを実施し、企業の従業員が私のガイドとしてコードベースを案内してくれます. コナー・ドハティ: なるほど、あなたはヴァージルというわけですね. ジョアネス・ヴェルモレル: はい、彼らが私をコードベース内に案内してくれます。コードベースのコピーを要求しないのは、コピーを求めると多くの問題が発生し、知的財産に関して責任を負う可能性があるからです。私が望むのは、コードベースを実際に目で見ること。それが、技術を見る私なりの方法です。しかし、コードベースは非常に広大になることがあります。5人のソフトウェアエンジニアが数年間働いただけの小さな会社でも、簡単に10万行以上のコードが存在します。もし私が一人でコードベースを探索しようとすれば、全体の90%の時間を道に迷うことに費やすことになるでしょう。そこで、隣にエンジニアが座り、私が質問をすると彼らがコードを見せてくれます。もちろん、全体ではなくサンプルをレビューするのです—全コードベースをレビューすることは不可能です. コナー・ドハティ: ここでの潜在的な財務的リスクを考えると、なぜCTOと一緒にコードを見渡さないのですか? ジョアネス・ヴェルモレル: まず、CTOがコードベース全体に精通しているとは限らないのです。5人のチーム(CTOを含む)であればおそらくCTOは全体に通じていますが、20人のエンジニアがいる後期の会社の場合、CTOがすべてのセグメントに詳しいとは言えません。さらに、企業の他のメンバーが隣に座ることは非常に興味深いです。なぜなら、彼らがコードベースにどれだけ精通しているのかを見ることができるからです。例えば、「永続層にはどうアクセスしているのか?」や「記録したデータにはどうアクセスしているのか?」といった基本的な質問をしたとき、手がかりが全くなければ良くありません。また、「直近で何をしたのですか?」と尋ねて「この機能を開発していました」と答え、今まさに取り組んでいるものを示す際に途方に暮れているようであれば、それは問題です.

コナー・ドハティ: (以下略)

コナー・ドハティ: ここでの潜在的な財務リスクを踏まえると、なぜCTOと一緒にコードを確認しないのですか?

ジョアネス・ヴェルモレル: まず、CTOがコードベースのすべての部分に詳しいとは限りません。5人のチーム(CTOを含む)であればおそらくCTOは全体を把握していますが、20人規模の会社では、CTOがすべてのセグメントに精通しているとは考えにくいです。さらに、企業の他のメンバーが隣に座ることで、彼らがどれだけコードベースに精通しているかを確認できます。例えば、「永続層にはどうアクセスしているのか?」や「記録されたデータにはどうアクセスしているのか?」といった基本的な質問に対して、全く分からなければ良くありません。また、「最近何をしましたか?」と尋ね、「この機能を開発していた」と答えた後、その機能を実際に示そうとして途方に暮れているようであれば、それも問題です.

インタビューでCTOと話すのは良いのですが、同時にチーム全体がCTOと同等の能力を持っているかも評価する必要があります。これは両方向に起こり得ます。時にはCTOが非常に優秀であっても、他のメンバーが劣る場合もあれば、その逆もあります。時にはCTOが非常に弱いにもかかわらず、他のメンバーが実際には非常に強い場合もあります。状況は様々であり、これもまた、成果物として投資家に返すメモの中の意見の一部となります。さらに、会社に現在所属している貢献者が次のフェーズの挑戦に応えられるかどうかについても意見を持っています。もし投資が実行されるなら、スタート時点で予算が極めて限られており、技術的に非常に優秀でない人材を採用することがよくあります。これは創業者が技術者でない場合に頻発します。内部情報を持ち、解決すべき特定の問題を理解している創業者が、ニーズと支払い意欲リンクはそのままを見出すことが多いのです。これはB2B市場で非常に頻繁に起こります。しかし、その創業者は技術者ではないため、見つけた最初のソフトウェアエンジニアを採用します。大きな予算がない場合、初期採用は単に費用が安いという点だけが強みとなる人材かもしれません.

ジョアネス・ヴェルモレル: それでも問題ありません。何もないところから始めるのです。例えば、20,000ユーロを会社に投入するとしましょう。それはあなたにとってすでに大きな投資です。その20,000ユーロのおかげで、50万ユーロ規模のシード資金が得られるわけです。これは良いスタートです。そして、例えば2人のソフトウェアエンジニアのチームを組んで製品を開発します。その後、次の段階、つまり300万ユーロの第一ラウンドに進みます。多額の投資、数百万単位の段階では、本当に優秀なソフトウェアエンジニアを採用できる資金があるはずです。そこで、現在所属しているメンバーが次のレベル、次の段階の挑戦に応えられるかどうかが問われるのです。これは唯一の問いではありませんが、検討されるべき重要な質問の1つです.

コナー・ドハティ: 確認させてください。覚書、すなわち成果物の一環として、誰が残るべきで誰が残らないべきかについての推奨事項を提示する可能性があるということですか?

Joannes Vermorel: そうですね、そうです。結局のところ、会社の技術的な価値やその技術的軌跡を高めるか、あるいは損なうかという点に関わるのです。時には間違った人材がいることもあります。つまり、地域限定の選手権に勝つために必要な選手は揃っていたかもしれませんが、全国大会あるいは世界選手権で戦いたい場合は、別の人材が必要になるかもしれません。より多くのお金が入ると状況は一変します。突然、はるかに経験豊富で才能のある人材を雇える可能性がでてくるのです。場合によります。才能ある人々でも、なぜか会社内のダイナミクスが非常に悪い場合もあります。たとえば、理由は分かりませんがCTOが二人いることもありました。実際、いくつかの監査でそういった事例が見受けられました。つまり、技術面のリーダーが二人存在し、その二人が異なるロードマップを追っているのです。そこで私のメッセージは「どちらか一方に絞るべき」ということです。完全に二面性を保つわけにはいかず、どちらかを選ぶ必要があります。それは追求する市場が異なるため、ビジネス上の決断となります。しかし最終的には、投資家が技術に何か問題があるのか、または将来的に問題が発生する可能性があるのかを知る必要があるという問題なのです。なぜなら、現時点では問題がなくても、お金を投入することは火に油を注ぐようなものであり、わずかに機能不全な部分に数百万ドルを注ぎ込むと、小さな問題が投資そのものによって大きく拡大してしまう可能性があるからです。ですから、それもまた問題になり得るのです。重ねて申し上げますが、私にはチェックリストはなく、ルールも存在しません。私が注目するのは、解決すべき問題や投資家への提言として意味があると判断した点すべてなのです。それが私の役割の一部です。つまり、私はそれを一日で完了するミッションとして扱っており、もっと深入りする時間はないのですし、創業者自身も非常に多忙だからです。古典的な監査の問題は、これらが時間の無駄であり、何週間もかかって会社を完全に麻痺させ、何も良い成果を生み出さないという点にあると思います。

Conor Doherty: その点についてですが、つまりあなたはチェックリストを使わず、一日以内に済ませることを目指していると言うわけですね。一日というのは労働日を意味します。すなわち、何週間もかかるプロセス―1日8時間で複数週かかるもの―の代わりに、タクシーやフライトを除いておそらく8~10時間で、チェックリストを使わずに、会社に対して大きな影響を与える提言を行う、というお話です。これらの制約を踏まえると、あなたはただ単に非常に優秀なのか、それともどうやって一日でチェックリストも使わずにその判断を下しているのか、教えていただけますか?

Joannes Vermorel: ええ、まずはコードベースです。たくさんのコードベースを読むことに少しでも慣れていれば、多くのことが一目瞭然になります。コードベースを数分見ただけで、そのコードがしっかり書かれているのか、ただのクソコードなのかが分かるのです。私は通常、コードベースをざっと眺めるだけで5分以内に意見が固まります。もし多くのプログラミング言語に慣れ、数多くのコードベースを見ていれば、これが優れた、きっちりとしたエンジニアリングによる、整理された意味のあるコードなのか、あるいは単に混沌として不整合なものなのかを判断するのに何時間もかかることはありません。たとえば、コードベースを見て全く異なるコーディングスタイルが入り混じっているのを発見したら、「ああ、各々の貢献者がコードの書き方について全く共通の合意を持っていない」という結論に至るのです。これは本当に悪い状態です。では、コミット履歴を見ますか?それだけでも多くのことが分かります。例えば、ある機能追加のコミットが1回あり、その後にその機能追加によって生じたバグを修正するためのコミットが2ダース続いているのを見たら、それは非常に悪い兆候です。つまり、人が何かを導入するたびに、すぐに壊した部分を修正するのに多くの時間を費やすことになるのです。ですから、直近の200件ほどのコミットをざっと眺めるだけで、パターンを見抜くことができるのです。いろいろなパターンが見えてきます。例えば、コミットメッセージの履歴があります。これは利用者にとっての進化の過程です。コミットはコードベースを段階的に変化させる手段です。変更を加え、現在では通常Gitを使います。我々はウェブ開発でもそれを使い、Lokadでも皆と同様に我々の技術スタックで利用しています。問題は、例えばコードベースに変更が加えられたとき、その変更が本当に意味があるのかどうかです。たとえば、コミットのタイトルが「more stuff」とだけ記されている場合、文字通り「これは何だこれは」となるのです。いや、何かが変わったとはとても言えません。さらに、例えばバグ修正のコミットの場合、修正と同時に次回コードに触れたときに同じバグが再発しないような工夫がなされているのか、という点も重要です。バグが再発しないようにする方法はたくさんあるのですが、あなたはそれに取り組んでいるのでしょうか?また、貢献やコミットを見ると、人々はコードレビューを行っているのか?物事がどのように設計されるべきかについて議論しているのか?重ねて申し上げますが、コードベースは技術そのものだけでなく、その歴史についても多くの物語を語ってくれます。その軌跡、つまりどのように発展してきたかが見てとれ、そこからコアな部分に焦点を当てることができるのです。例えば、もしあなたがAIや機械学習のスタートアップであれば、核となる価値は何か非常に難しい問題を解決するための、賢いnumerical recipeであるべきです。どのようにそれを実現しているのか?ただのトリックなのか、それとも深い専門知識に裏打ちされているのか?どれほどの堀(moat)があるのか?あなたが実現したことを模倣するのが難しい真の堀があるのか、あるいは単なる手品のようにオープンソースのライブラリを使っているだけで、結局、何も自社プロダクションならないのか?つまり、コミュニティ内の何かを再利用しているに過ぎないのか?これは投資家にとって非常に重要な問題です。なぜなら、「ああ、ユニークな機械学習技術を開発した」と言ったところで、基本的にそれがオープンソースの一部を再利用しているだけなら、誰にでもできるからです。確かに、うまく機能しているしクールではありますが、ただ働くという理由だけで投資家が会社の評価を高くするべきでしょうか?実際、オープンソースであれば、ほぼ誰もが同じことを実現できるため、堀は存在しないのです。重ねて申し上げますが、私が注目している点は、その企業の具体的な事情に大きく依存しています。

Conor Doherty: また、たった一例としてGitやBitbucketのコミットログ―我々はBitbucketを使っています―を見ることで、かなり多くのことを読み解くことができます。たとえば、マーケティングチームであっても、ウェブサイトに何かをプッシュするたびに、あなたは非常にクリーンで整然としたコミットログを求めます。そこから、何が起こったのか、誰が承認したのかが正確に把握できるのです。 Joannes Vermorel: その通り。そして、時には人々とのやり取りの仕方そのものからも多くを読み取ることができます。たとえば、誰かと話していて、ふとした質問を投げた際、その人が瞬時にコードの該当箇所へ案内してくれるかどうかです。「ああ、この機能は面白いですね、その関連コードを見せてもらえますか?」と尋ねたとたん、相手が「はい、問題ありません」と即座に実装箇所へ案内してくれるなら、それは非常に良いサインです。コードベースの完全な習熟度、つまり物事がどのように進められているかの完全な理解は、非常に素晴らしいのです。また、例えば新しい機能を導入する際に、その正当性を説明するための十分に整理されたチケットがあるかどうかも重要です。ソフトウェアエンジニアが適当にコードをいじっているのか、それとも「これを実装するために、理由が明確に記されたチケットがある」という、よく整然としたプロセスで動いているのか。状況に依りますが、普通、チケットの整然さはB2Bアプリケーションや生産性向上アプリケーションでは非常に重要です。なぜなら、そこには限りなく増え続ける、非常にドメインに特化した多数の機能が含まれるからです。企業向けアプリケーションの場合、追加できる無限の機能に迷い込むべきではありません。したがって、企業ごとに全く異なるプロセスになるでしょう。しかし、私が言いたいのは、数時間でどのように自分の意見を形成できるかということです。誰かと隣でコードベースに触れていれば、本当に多くのことが見えてくるのです。人々の行動パターンに注目すれば、それは単なるパターン認識であり、特定の職務において人が得意なことや不得意なことには限りがあるのだと分かるのです。

特定の職務において、人が得意なことや不得手なことには限りがあります。

Conor Doherty: そうですし、一貫性も確認します。つまり、技術に関して、皆が同じ認識を持っているのかどうかです。たとえば、「このコンポーネントは何をしていると思いますか?」と尋ねて、複数の人から全く異なる説明を受けたなら、「明らかにこのチーム内では、何が起こっているのか十分に理解されていない」という結論に至るのです。

Joannes Vermorel: 物事に不整合があると認識するのに、真実を知る必要はありません。重ねて申し上げますが、私の目的は彼らの業務の専門家になることではなく、チームが機能しているか、技術の発展の軌跡が常軌を逸していないかを評価することにあります。時には、例えばクラウドコンピューティングのリソースが適切に管理されているかどうかを確認することも含まれます。クラウドリソースを適切に管理できていない企業もあります。クラウドは素晴らしく、「使った分だけ支払う」という仕組みで、可能性は無限大です。大量の仮想マシン、ストレージ、あらゆるものを展開できます。しかし、場合によっては、一部の企業がやや度を越してしまい、必要以上にクラウドコンピューティングリソースに費用をかけるという事態に陥るのです。

Conor Doherty: それは、彼らの事業内容によるでしょう。クラウドコンピューティングリソースにいくら支払うべきかは、達成しようとしている目標に依存します。明確なルールはありませんが、重要なのはクラウド上で扱うべきワークロードを評価し、その費用が正当かどうかを判断する経験です。それが達成すべき成果として評価されるのか、非常にパフォーマンスの高いソフトウェアの証なのか、あるいは非常に劣っていて単にお金を無駄にしているだけなのか。たぶん、余分なお金を使いまくるのは正しい戦略ではなく、数百万ドルの追加資金が投入される前に、その問題を解決すべきでしょう。

Joannes Vermorel: 資金が不足していると、計算資源への無謀な出費を抑える自己規律を保つことはできません。資金が大幅に増えた後、急に賢明になれる可能性は極めて低いのです。

Conor Doherty: その点についてですが、実は計算資源に関する別のビデオもございますので、プレイリストをご確認ください。しかし金銭の話になると、財務について、あるいはサプライチェーンの話をする際、あなたは意思決定が企業の最終的な財務に与えるインパクトを考慮するとおっしゃいます。技術系企業の評価においても同様のアプローチを取られているのでしょうか?すなわち、技術の価格に関係なく、最も財務的に有利なオーケストレーションか、あるいは単に最高の技術を評価されるべきかという点です。

Joannes Vermorel: いいえ、違います。すべてのスタートアップは限られた資源しか持っていません。問題はチェックリストが絶対的な視点を持っていることにあります。チェックリストは「これをやれ、これをやれ、これをやれ、これをやれ」と指示しますが、私の視点は常に企業の成熟度に応じた相対的なものです。

Conor Doherty: その通り、各企業の状況に合わせての話です。

Joannes Vermorel: 例えば、小さな企業がISO認証を取得しようとするのは、全くの狂気です。それは、極端に規制の厳しい市場で、認証がなければ生き残れない場合を除き、資源の完全な無駄遣いなのです。私が注目しているのは、限られた資源をどれだけ効果的に活用して最大の成果を上げられるかという点です。あなたの方向性が正しい、すなわち最終的に成功して利益を上げると仮定した上で、もしその前提に立つなら、「この事業がうまくいけば、この市場で競争力を持ち、利益が生まれるだろう」と認めざるを得ません。そこで、競争市場のナンバーワンプレーヤーになるために使われるすべてのドルやユーロが賢明に使われているかという点が問われるのです。

Conor Doherty: その通りです。つまり、適切な才能が確保されているかということも重要です。時には支出が少なすぎることもあります。実際、ある程度成功を収めた会社が、非常に安価だったために最初に採用した人材を手放さないということもよくあります。これはテックスタートアップでは頻繁に見られる現象です。

Joannes Vermorel: 特に、創業者が技術者出身ではなく営業出身で、その後CTOとして最初に採用されたソフトウェアエンジニアがいる場合に、よくある話です。そして、その人物が求められるレベルに達していないことも多いのです。もちろん、例外もありますので、ケースバイケースです。

Conor Doherty: その通りです。そこで私の質問ですが、企業を評価するために入った際、コードやチームの働き方など、これまでお話しされてきたすべての要素を評価するために入ったのに、彼らの最終的な目標自体が全くナンセンスであったというケースはありましたか?例えば、2008年にある企業がVHSテープを復活させようと決意する、というような、金銭や時間、資源の大幅な浪費だと私が強く感じる完全に常軌を逸した事例です。

Joannes Vermorel: ああ、そういうことは確かにあります。どうぞ、ただし具体的な名前は出さないでください。

Conor Doherty: いや、実はソフトウェア技術の中には非常に速いペースで進化するものもあります。例えば、過去2年間で、NLPを扱っている企業をいくつも監査してきました。これらの企業は2018年または2019年に設立され、AIブームに乗ってNLP、すなわち自然言語処理技術を開発しましたが、これはLLM(大規模言語モデル)以前のものです。LLMではない、膨大なNLPモデルや機械学習、deep learningの文献が存在していました。LLMはそれら全てのNLP技術にとって、一種の絶滅事象となってしまいました。

Joannes Vermorel: はい、私の結論としては、多くの企業で「この会社は20種類のかなり洗練されたNLPモデルを開発したが、すべてが完全に時代遅れだ」と判断された。LLMはそれらすべてを一様に凌駕している。技術スタックをすべて捨て、LLMを中核に据えてゼロから再出発すれば、よりよくなる。救いは何もない。理由はさまざまで、よくあるのは10社に1社、20社に1社といった割合で、何かの理由で技術が完全に時代遅れになっている場合だ。たまに、人々は何がその代替になるか正確には見えていないが、そう、これを見ると、既に解決済みの問題を取り組んでいることが分かる。

Conor Doherty: 通常、問題は、その人たちが愚かだからという意味でのナンセンスではない。解決すべき問題が存在し、彼らは素晴らしい何かを開発したが、すでに見つかっている、しかもおそらく無料のはるかに優れたものがある。今はまだ一般的ではなく、あまり知られていないだけだ。私にとってLLMは、企業がLLMの到来を知っていて、それが絶滅イベントになると認識していたという点で、極端な例である。しかし、あなたが会社の創業者で、すでにシードラウンドで調達した資金を投じている場合、今や技術がほとんど価値を持たなくなってしまうという見通しに直面する。技術を再開発するための投資を取り付けようとしても、厳しい。

Joannes Vermorel: このような状況で私が取るスタンスは、投資家に「投資するな」と言うことではない。私のメッセージは、彼らの持つ技術スタックは全くの価値を失っているということだ。もし人材が優れていれば、投資する理由はあるかもしれないが、それも技術資産がもはや資産ではなく負債になっているため、評価額ははるかに低くなる。

The team is functional, and the trajectory in terms of development of the technology is insane. Sometimes, it’s also about checking, for example, that the resources in terms of cloud computing resources are just under control. Sometimes, you have companies who are mismanaging their cloud resources. The cloud is fantastic; pay as you go means that the sky is the limit. You can spin tons of virtual machines, tons of storage, tons of everything. Sometimes, companies go a little bit crazy on that and end up with a trajectory where they are spending way too much on cloud computing resources than they should. It depends on what they’re doing. How much should you be paying for cloud computing resources? Well, it really depends on what you’re trying to achieve. There is no clear rule, but part of the experience is to assess what is the workload you’re trying to accomplish on the cloud and does it make sense that you’re paying that much. Is it an achievement well done, your software is highly performant, or is it super bad and you’re just burning money? Probably giving you tons of extra money to burn is just not the right move. You should probably be fixing those problems before being granted a few extra million. If you’re lacking money, you cannot discipline yourself to not burn money through unwise spendings in computational resources. The chances that you will become wise once you have a lot more money are super thin.

Conor Doherty: ふと思ったのだが、その話題に関連して実は計算資源についての別のビデオもあるので、ぜひそのプレイリストもチェックしてほしい。ただ、金銭の話になると、私たちがサプライチェーンについて語るとき、必ずその選択が底線に与える財務的影響について触れる。技術企業を評価する際にも、最も財務的に有利な構成を見るのか、あるいは価格に関係なく最良の技術を見るのか、どちらのアプローチを取るのだろうか?

Joannes Vermorel: いいえ、違う。すべてのスタートアップは資源が限られている。チェックリストの問題は、これこれこうと絶対的に決めつける点にある。私の視点は常に、その会社の成熟度に相対している。

Conor Doherty: そう、彼ら自身の条件においてね。

Joannes Vermorel: 例えば、小さな会社がISO認証を取ろうとするのは、正気の沙汰ではない。極端に規制された市場でなければ、その認証なしで生き残ることはできない。私が見ているのは、限られた資源を使い、最大限の効果を引き出す能力だ。あなたの方向性が正しいという前提のもと、もしこの取り組みが完了すれば市場で競争力を持ち、利益が出るだろうと仮定する。その上で、市場でナンバーワンになるために使われる一ドル一ユーロが賢明に使われているかどうかを評価する。例えば、適切な人材が確保されているかどうか。時には支出が少なすぎることもある。企業が一定の成功を収めた後、最初は非常に安価に採用された人材を手放せなくなることがよくある。特に、創業者が技術者でなく営業出身の場合、CTOはその会社で最初に採用されたソフトウェアエンジニアであることが多い。これは頻繁に起こり、その人物は要求されるレベルに達していない。もちろん例外もあるが、状況によるものだ。

Conor Doherty: その通り。そこで聞きたいのは、企業を評価に訪れた際、最終目標自体が完全にナンセンスだと感じたことはあるかということだ。たとえば、2008年にある企業がVHSテープを復活させようと決意している、というような、莫大な時間と資金、リソースの無駄遣いに他ならない例はあったか?

Joannes Vermorel: ええ、本当にそういうことはある。

Conor Doherty: 名前は出さずに、感じたままを共有してくれ。

Joannes Vermorel: あるソフトウェア技術は非常に速いスピードで進化する。例えば、過去2年間でNLPに取り組む多くの企業を監査した。これらの企業は2018年か2019年に設立され、AIブームに乗ってNLP(自然言語処理)技術を開発したが、いずれもLLM(大規模言語モデル)が出る前のものだった。NLPモデルや機械学習、ディープラーニングに関する文献は膨大だったが、LLMは存在しなかった。結果として、LLMはすべてのNLP技術にとっての絶滅イベントとなった。これらの企業について、私が結論付けたのは、彼らが20種類のかなり洗練されたNLPモデルを持っていたが、それらはすべて完全に時代遅れであり、LLMがそれらを一様に凌駕しているということだ。技術スタックをすべて捨て、LLMを前面に据えてゼロから再構築すれば、救いは全くない。理由は様々だが、技術が単に時代遅れになっているケースはかなり頻繁にある。時には、何がその代替になるのか正確には見えていない。しかしながら、これを見ると、既に解決された問題を扱っていることが明らかだ。通常、それはその人たちが愚かだからというのではなく、解決すべき問題が明確に存在し、彼らは何か素晴らしいものを生み出したが、すでに見つかっている、もしくはおそらく無料のはるかに優れたものが存在するという現実がある。この技術はまだ普及しておらず、非常に知名度が低い。LLMは、企業が何が来るかを知っていたために、ある意味で絶望的になり、それが絶滅イベントとなった極端なケースだ。あなたは会社の創業者であり、すでにシードラウンドで集めた資金を投じている。そして、今やあなたの技術はほとんど価値がないという見通しに直面する。投資を引き出して技術を再構築しようとしても、難しい。私の見解としては、投資家に投資しないよう促すのではなく、彼らの技術スタックは全く価値を持たないと示すことだ。もし人が優れていれば投資の余地は残るが、持っているものはもはや資産ではなく負債であるため、評価は大幅に下がるはずだ。

Conor Doherty: 一方で、企業内を評価に入った際、「次のイーロン・マスクに出会った」と感じたことはあるか?つまり、その人は天才で、まるでダイヤモンドを抱えているかのような場合は?

Joannes Vermorel: そのようなスケールの例はないが、時々自分の会社と比べて若干の嫉妬を感じることはある。特に、人々が非常に美しいニッチ(隙間市場)を持っている場合だ。美しいニッチは数多く存在する。私が嫉妬を感じるのは、美しく、極めて専門的な問題で、誰もその問題の存在に気づいていなかったものだ。しかし、実際には数千万人、あるいは場合によっては10億の規模がかかっている。これはニッチ市場であり、競合が存在しないために企業が50%の市場シェアを取るチャンスがある。対照的に、Lokadが行うsupply chain optimizationのような、競合が千以上あるハイパー競争の市場ではない。私たちは、何十億という大企業が競合する市場とも対峙することがある。競争環境は厳しい。そして、時には競合が文字通りゼロの企業とも出会う。その場合、彼らは唯一無二であり、顧客は満足しており、これまで聞いたことのない非常に専門的な問題に特化した解決策を持っている。

Conor Doherty: 例を挙げるとどうだろうか?それとも、あまりに暴露しすぎるだろうか?

Joannes Vermorel: いや、あまりにも詳しく話すと問題になるので控えたい。しかし、重要なのは、非常に専門化された何かを想像してほしいということだ。

例えば、洋上石油掘削リグの専門的なメンテナンスを考えてみてほしい。やるべきことが山ほどあり、特定の作業にはソフトウェアによる支援が必要とされる。そういった業務を行う企業が存在する。非常に専門的なニッチ、つまり非常に特定の問題に対して専用のソリューションが求められている分野を思い浮かべてみてほしい。

また、手術室で外科医が使用する技術機器の数を想像してみてもよい。測定するための多くの機器があり、例えばこの建物では、石綿を検出する制御機器があった。石綿を検知するためのソフトウェアが組み込まれた装置があった。そういった機器を提供する企業がどこかに存在する。これらは非常に特定のニッチ市場であるが、世界規模で見ると決して小さな市場ではない。

こうした非常に小さなニッチ市場は、全世界で数億ドル規模であり、競合がいなければ企業は50%の市場シェアを獲得できる。さもなければ、従来の手書きの方法が使われるに過ぎない。

Conor Doherty: この10年間でさまざまな事例を見てきた中で、ソフトウェアやスタートアップにおける一般的な最良の実践と最悪の実践は何かあるだろうか?まず、絶対に避けるべきことを教えてほしい。いわば、避けるべきものから始めて、最後はポジティブな点で締めくくってほしい。まず、絶対に避けるべきことは何だ?

Joannes Vermorel: 技術を大切にしなければ、すぐに大惨事を招く。無関心は致命的だ。技術に気を配らない企業を見るたびに、その技術は通常、完全なゴミである。

Conor Doherty: 「気にしない」とは具体的にどういう意味なのか説明してほしい。すなわち、学ぼうとしないのか、かつては関心を持っていたが今はないのか、それとも単にスキルが不足しているのか?どういう状態を指すのだ?

Joannes Vermorel: 最も的確に表現すると、CTOがシャワーを浴びている間に自分の技術のことを考えるのか、それともゴルフのことを考えるのかという点だ。心から技術を大切にしている人々は、ある種の情熱と強度を持っている。オフィスアワーだけでなく、その枠を越えて取り組む。彼らは非常に好奇心旺盛で、熱意に満ち、情熱的だ。本当に正しいことをやろうとするのだ。単にクライアントのためだけでなく、技術そのもののために正しいことを行おうとする、いささかの狂気すら感じさせる情熱がある。

あなたは本当に美しいものをエンジニアリングしているのか?かつてスティーブ・ジョブズに関する逸話がある。彼はiPhoneの内部も美しくありたいと願った。分解したときに、iPhone内部の部品が適切な色の選択などでエレガントに仕上がっているように。こうした配慮は、表面的な見た目だけでなく、顧客が決して目にしない技術的な部分にも深い関心を持っていることを示している。

人々が技術を大切にしないと、状況は悪化する。最悪なのは、テック企業がその技術の開発をフリーランスに外注するケースだ。たとえそのフリーランスがどれほど優秀であっても、結果として技術は通常、完全な混沌状態になってしまう。

Conor Doherty: 多くの人が、内在する情熱や、物事をうまく成し遂げようとする駆動力は素晴らしい資質だと認めると思う。しかし、もしCTOと20分しか時間がないとしたら、チェックリストなしでどのようにしてその無形の要素を見極めるのだ?

Joannes Vermorel: 強い情熱を持つ人なら、「この技術を選んだのはこういう理由がある」と教えてくれる。彼らは「なぜ」を理解している。ただ「ウェブインターフェイスが必要だからこれを選んだ」というだけではなく、技術的な選択について多くの意見を持っている。情熱的な人々は、その意見があふれ出してしまうほどで、自分を抑えることができない。技術の一部に触れるたびに、「これをこうするのはこういう理由がある」と話してくれるのだ。

Conor Doherty: 要は、彼らの情熱こそが重要だということだね。

Joannes Vermorel: その通り。そして、彼らの思考の強度が明らかに見える。単に要件を満たすためだけに技術を実装したのではなく、営業チームからの指示でそのまま実装するいわゆる凡庸なアプローチではない。そうした方法は、結果として技術スタックが酷いものになってしまう原因だ。

Conor Doherty: 例えば、もし過去にスティーブ・ジョブズを監査して、「この電話の内部が美しいんだ」と語ったのを聞いたなら、あなたのメモは彼が情熱的であることを示すだろうが、それは莫大な費用をかけるには、あまりにも狂気じみた行為だと言えるのか?

Joannes Vermorel: いや、違う。重要なのは、彼らがただ気を散らすために無駄なことをしているのか、あるいは本当に余分な磨きを加えているのかだ。そうした追加作業は非常に多額ではない。ただ、その強度が違う。ほんの数パーセント多く手を加えるだけで、全体が非常に引き締まり、見事に仕上がる。それは狂気ではない。過剰にやりすぎる人々には、しばしばセカンドシステム効果と呼ばれる現象が見られる。つまり、最初の試みが失敗したため、次の試みで必要のないことに過剰投資してしまうのだ。

The most frequent case is when people over-invest in scalability that they won’t need anytime soon. They say, “Look at our beautiful architecture; it can deal with 10 million users.” How many users do you have at this point? “Oh, 200.” There’s a vast disconnect between what is needed and the over-engineering.

また、間違ったことに対して忍耐強くあろうとする人たちもいます。技術そのもののある種の優雅さや美しさを求める忍耐力があるのか、それとも何らかのドグマに従っているのか? ソフトウェア業界にはあらゆる種類のドグマが存在します。スクラムのように行うべきだとか、ドメイン駆動開発、テスト駆動開発、マイクロサービスといった具合に、業界には多くのグル風の意見が飛び交っています。そして、それに熱狂的な人々もいます。ここで私が「熱意」と言うのは、自らの作品を愛しているものの、特定のイデオロギーに盲目的ではない人々を指します。熱狂的な人々は、自分たちの実際の要求さえも顧みずに行動します。「だが、テスト駆動デザインだからそうしなければならない」といった具合に。テスト駆動デザインであるという事実は、そのやり方を正当化する理由にはなりません。本当に抱えている問題に対して、その方法が意味を成すのでしょうか?

Conor Doherty: そしてベストプラクティスに関してですが、さっきの発言の逆を言うだけではいけません。何か、見た瞬間に「お、これは良い兆候だ」と感じるものはありますか?

Joannes Vermorel: 明快な文章です。以前も言いましたが、明快な文章が必要です。すべての部分が的を射て、鋭く、簡潔でなければなりません。コード内に「コメントしなければならない」といった官僚的なコメントが何ページもあるでしょうか? 誰も読むことのないテンプレートのようなコメントページがあるのでしょうか? それとも、非常に洗練された、興味深いコメントがあるのでしょうか? たった一つのコメントを読むだけで、そのコードファイル全体が明らかになる場合もあります。チケットを見ると、あなたの問題記述は非常に明確に書かれているのか、それとも理解不能な混沌とした状態なのでしょうか? 技術的課題に直面した時、問題と可能性について非常に明瞭な議論がされているのか、それとも何も語らないくだらない箇条書きのスライドがあるのでしょうか? 文章の質は、見分ける上での決定的なサインの一つです。もう一つは、人々が珍しい技術を使っていて、それが結果的に非常に良い選択である場合です。珍しい技術を使っている場合、多くは単なる無知からです。はるかに主流で優れた解決策があることを知らなかったのです。通常はマイナスですが、意外にも、比較的珍しい技術が彼らの取り組みに非常に適していることが分かれば、それはとても良いことです。それは、彼らが技術の全貌、特にオープンソースの技術動向を非常に幅広く探求しているということを意味します。これは素晴らしいことです。今日では、「ああ、私たちはPython、PostgreSQL、CSS用Tailwind、Reactを使っている」と言っても誰も驚かないでしょう。これは、どの程度有能なソフトウェアエンジニアでも知っているコンポーネントです。しかし、もし彼らが自分たちの問題に本当に合った非常に特定の何かを知っているなら、それもまた非常に興味深いのです。

Conor Doherty: いいですね。さて、約1時間ほど話してきました。時間を意識して、締めくくりに、皆さんと共有したい最後の考えはありますか?

Joannes Vermorel: はい。この10年間の監査で私が最も驚いたのは、テック企業が実際に何年も、場合によっては連続した投資ラウンドの中で、技術を一度も見られることなく進められているという事実です。あの大詐欺Theranosは例外だと思われるかもしれません。あんなにも莫大な投資がなされながら、誰も技術のデューデリジェンスを行わなかったのです。しかし、面白いのは、それが普通であるということです。私にとって非常に興味深いのは、こうした技術監査がいかに稀であるかという点です。スタートアップの創業者たちと話すと、彼らはたいてい「こんな質問をされるなんて思ってもみなかった」と言います。彼らは私がこの狂ったような馬鹿げたチェックリストを持ってくると思っているのです。Theranosを想像してください;人々は容易にそのチェックリストを騙してしまったでしょう。「これに準拠していますか?」「はい、準拠しています。」「見せてください。」といったやり取りです。実際、あちこちに「これこれに準拠していますか?」というチェックリストは山ほどありました。はい、はい、はい、はい。しかし、本質的な質問である「あなたの血液分析技術は本物か?」という問いは、誰からも問われなかったのです。それは非常に基本的な質問でした。

Conor Doherty: これは、以前にあなたが述べた「スキン・イン・ザ・ゲーム」の点に戻ります。もしベンチャーキャピタリストがあなたの会社に何百万もの投資をするのであれば、彼らもまたリスクを共有しているのです。

Joannes Vermorel: 私が非常に驚くのは、通常、私がたとえ第3ラウンドに入っても、誰も技術スタックを真剣に検証していないという点です。それは非常に奇妙です。ただチェックボックスに印をつけるだけの監査人がいますが、私にとってはそれらは意味をなしません。彼らはただ作業をしているふりをしているだけで、本質的なことは何も行いません。騙すのは非常に簡単です。嘘をつけばいいのです。「これをやっていますか?」「ええ、やっています。」「見せてください。」といった具合に。監査人は技術者ではないため、何を見せても「はい、チェック済み」と言ってしまいます。これらの監査が終了するとき、その様子は非常に興味深いものになっています。古典的な監査では、監査人は「私たちに嘘をついていないことに署名してください。もし嘘をついていたら、全責任を放棄します」といった書類にサインを求めます。私自身は決してそんなことはしません。人々が真実を語っているとは仮定しないからです。だからこそ、私はコードベースを見たいのです。はい、あれこれと私に言って騙すことはできるかもしれませんが、コードベース――つまり、何千ものコミット、何百ものチケット、すべての補助資料を偽造することは、はるかに難しいのです。私が驚くのは、その費用が監査1日分で済んでしまうということです。私が決して安いわけではありませんが、それでも1日です。10年以上もこれらの監査を行ってきたにもかかわらず、私が訪れても、第2ラウンドや第3ラウンドにおいても、誰も本当に技術に異議を唱えたことがないのです。人々はただ、それが良い、動作する、そしてロードマップ通りであると仮定しているだけです。何のチェックも行われません。私にとって、それは少し呆れるほどです。

Conor Doherty: さて、今日話し合った何かが変化をもたらし、あるいは数人の方々があなたに連絡するきっかけになることを願っています。あなたはバットミツバーや誕生日のお祝いにも応じていると聞いています。

Joannes Vermorel: はい.

Conor Doherty: では、Joannes、時間を割いて私の質問にすべて答えていただき、本当にありがとうございました。ご視聴の皆さんにも感謝します。では、また次回お会いしましょう.