この投稿は、ほぼ思いつくままに Wispr AI で口述筆記したものです。

リモート会社を運営するにあたって、自分自身に課した基本的なルールがあります。オフィスの家賃にあてるはずだったお金を、四半期に1〜3回は対面で集まるための旅費に使う、というものです。先日、セントルイスで初めての全社オフサイト（といっても3人ですが）を終えたばかりです。わずか2.5日間でしたが、比較的生産的に過ごせたと感じており、次回も繰り返したいと思ったことや、他の人にもおすすめしたいことを書き留めておきたいと思います。

すべての時間に役割を与える

最初にホワイトボードにやったことは、合宿のすべての時間を1時間単位で区切り、このオフサイトで達成したいことをすべて書き出すことでした（いわゆるタイムブロック計画を、グループ単位でやるイメージです）。また、全員がオフサイトで扱いたいテーマについて意見を出せるようにし、終わったときに「自分がやりたかったことはできた」と感じて帰れるようにしました。

このやり方の定番の問題は、過小評価の誤差が積み重なることです。1時間で終わるはずの議論が3時間かかることもありますが、それはごく自然なことです。これは1日の終わりに、予定外の延長のための余白（いわば「？」の時間）を残しておくことで緩和できます。私たちはまだ極めて初期段階なので、これから紹介する各セッションについて事前準備はしませんでした。もっと規模の大きなオフサイトでは、議論するセッションに向けて十分なコンテキストを共有するため、オフサイトの1〜2日前から準備を始めるのを見たことがあります。

財務レビュー

私たち3人は合わせて4〜5社のリモート企業でオフサイトを経験してきましたが、その中で財務の全体レビューを行う会社はほとんどありませんでした。おそらく、給与を含むあらゆる経済状況を公開することへの慎重さや、顧客やSKUが多岐にわたると会計が複雑になることなどが理由だと思います。私たちの場合は今のところ給与が透明ですし、資金調達先や顧客・収益源もかなりシンプルなので、これは問題になりませんでした。

このミーティングの基本的なゴールは、会社にいる全員が「お金がどこにあり、どこから来てどこへ行くのか、そして将来どこでより多く稼げる可能性が高いのか」を理解して帰ることです。そうすることで、特に従業員にとって、ランウェイや事業の根本的な存続可能性について一定の安心感が得られます。

私たちの場合は非常にシンプルで、思いつくままに図を描ける程度だったので、15分で終わりました。

顧客レビュー

自分たちが誰のためにプロダクトを作っているのかを深く理解すればするほど、プロダクトやエンジニアリングの優先順位は明確になります。正直なところ、この点はまだ模索中であり、顧客中心主義や顧客への執着こそが会社を成長させる正しい道だ――少なくとも会社を誠実に保つ道だ――と強く信じているということ以外、確かなアドバイスがあるわけではありません。技術中心や研究中心、あるいは「雰囲気」中心といった他のアプローチと比べての話です。

アーキテクチャ・ウォークスルー

コードベース全体を ChatGPT に放り込み、主要なセクションをボックスと矢印で示した Mermaid 図を作るよう頼みます。それを Excalidraw に貼り付け、好みに合わせて調整し、色を付け、全体としてだいたい意味が通るように整えます。そして、それを会社全員に説明して回ります。

基本的な考え方はこうです。次に何をすべきかについて誰もが意見を持つ権利はあるが、今日何が存在しているかという基本的な事実は全員で共有しなければならない。

なぜこの演習が重要なのか、疑問を投げかけられました。仮に規模の大きな会社であれば、CEOは技術チームをブラックボックスとして扱い、実装の詳細をそれほど気にする必要はないはずです。チームの規模を度外視しても、エンジニアリングチーム以外のメンバーがアーキテクチャを理解することは依然として重要だと考えています。そうすることで、これまでに行われた技術的な賭けを正しく評価でき、突飛で非現実的な機能リクエストを防ぐことができます。可能であれば、機能としてプロダクト化できるようなシステムの設計を、自発的に浮かび上がらせることにもつながります。

もちろん、テクニカルファウンダーとして、この機会を利用して自分が持っていたいくつかの意見を差し込むこともしました。それが次の議論につながります……。

プリンシプル・ミーティング

オフサイトは、日々のルーティンから意図的に離れ、「事業の中で働く」のではなく「事業について働く」ための良い機会です。これは Richard Gerber の著書『E-Myth Revisited』から得た考え方ですが、正直なところ私は読んでいません。ただ、あまりに多くの人が語っているのを聞いたので、読んだような気になっています。つまりこれは、どのように働くか、そして今後どのように働き続けたいか、という「HOW」についてのミーティングなのです。

初めての創業者として、これは自分がずっと働きたいと思っていたような会社を作る上で最もレバレッジの高いミーティングだと感じ、とても新鮮でした。自分が最も強く信じるプリンシプルを公の場で表明し、それについて責任を問われることで、成功を複利的に積み重ねる習慣を作っていけるからです。言い換えれば、自分が信じるワークカルチャーを言葉にすることで存在させ、メンバーはそれに対して異議を唱えることも、概ね同意して進むこともできるわけです。

プリンシプル・ミーティングに最も影響を与えたのは、おそらく Amazon のリーダーシップ・プリンシプルと Ray Dalio の著書『Principles』です。Ray の最上位のプリンシプルは「苦痛＋内省＝進歩」です。Amazon には Jeff Bezos が作り上げた、さまざまな強い意見を定義する14のリーダーシップ・プリンシプルがあります。私はプリンシプルの簡潔さに価値があると考えています。だからこそ、プリンシプルの一語一語が重要であり、重みを持つようにしなければなりません。プリンシプルが多すぎると覚えられず、守らなくても言い訳がしやすくなってしまいます。私たちは最終的に5つのプリンシプルを作りましたが、これは会社にいる人数よりも多いので、おそらく1つか2つ多すぎるでしょう。もちろん、最も難しいのは、もっともらしい追加案に「ノー」と言うことです。

中心的で、まだ決着していないプリンシプルをめぐる議論

現在、AI において私が最も強く信じているプリンシプルは、「プロダクトがプロセスを導き、プロセスがプラットフォームを導く」というものです。言い換えれば、顧客にとって最高のプロダクトとは何かを第一原理から考え、ソフトウェアと人間の労働力を組み合わせるなど、何をしてでも最高のプロダクトを作るということです。そして人間の労働をプロセスとして体系化し、最終的には可能な限り、それらのプロセスをソフトウェアとして表現・コード化・一般化しようと試みます。

これは、私が見てきたプラットフォームを最優先する他のスタートアップとは真逆のアプローチです。例えば、何でもできるオープンソースプロダクトや、何でもできるクラウドプロダクトを作ってから、顧客やユースケースを探しに行くようなやり方です。

私の一般的な感覚では、AI で最も成功しているリーダーたちは、魔法のような、あるいは最先端の体験を体現するプロダクトを作っており、人々は実際には裏側の API へのアクセスをそれほど気にしていません。彼らが気にするのは、最終的な結果だけなのです。

将来的に、そうした体験を支えるオープンソースプロダクトや API プラットフォームを公開すれば、ユーザーはプロダクトのブランディングに惹かれてプラットフォームも採用するようになります。それは、後に立ち上げられた Amazon Web Services に対して Amazon.com がお墨付きを与えたのと似た構図です。もちろん、このルールにも例外はあります。Character AI のようにプロダクトを優先しながらも、たとえ先行するプロダクトであっても必ずしも勝つわけではなく、プロダクトもプラットフォームもうまくマネタイズできないケースもあります。また、強い思想を持ったプロダクトに導かれることなく、比較的成功しているプラットフォームもあります――Together AI、Braintrust、Fireworks などがそれにあたります。

ただ、顧客第一ではなくプロダクト第一を掲げることで、顧客中心ではなくプロダクト中心になる口実を与えてしまうのではないか、という懸念もあります。それが、現在の会社としてのプリンシプルに見出した欠点です。

よりシンプルなプリンシプル

私が提案し、いくらかの議論はあったものの最終的に受け入れられた、よりシンプルなプリンシプルは、毎日コードを出荷するというものでした。これは理論や事業戦略というより行動に関するプリンシプルですが、勢いを保つという点で気に入っています。

ここでのモチベーションとなったエピソードは、Nat Friedman が GitHub の CEO に就任したときの話です。多くの新任 CEO は動き出す前に上級管理職と3〜6か月かけて傾聴ツアーを行うものですが、Nat は代わりに「次の100日で100個のものを出荷し、そこで障害を発見しよう」と言いました。そうすることで会社がどのように機能しているかを学ぼうとしたのです。

もちろん、小さな会社ではそれほど異論のある話ではありませんが、コードに近いことがプロダクトに近いことでもあるというコミットメントが、私たちが素早く動くのに役立ったと思います。スタートアップであるということは、素早く動き、新しい技術や顧客の要望に迅速に対応することを意味します。

このプリンシプルは、この投稿の冒頭で触れたタイムブロック計画にも直接反映されました。私たちはオフサイトの毎日でコーディングする時間を確保し、こうしたメタワークをしている間に仕事が止まってしまうのではないかという懸念に対処しました。

バス係数オンボーディング

これもまた、小さな会社で最も有用なミーティングでしょう。このミーティングの目的は、最も詳しい人物が他の全員に対して、システム全体の運用方法、権限や管理者ログインの取得方法、システム管理全般について一通り説明することです。そうすることで、誰かが休暇中でも、誰かが引き継ぐことができます。誰かが不在でも、時間はかかっても他の誰かがシステムを復旧できるようにするのです。

Zoom を立ち上げて画面共有し、録画することをお勧めします。そうすれば、いざというときに立ち戻れる、きちんとしたプロセスの録画が残ります。この種の録画からランブックを自動生成してくれる AI プロダクトもいくつかありますが、私自身まだ試していないので、おすすめできるものはありません。

ブレインストーミング

日々の業務の中では、コアプロダクトの観点からも、プロダクトの拡張や試したい他の実験の観点からも、何をすべきか、何ができるかについて多くのアイデアが飛び交います。このミーティングは、みんなでブレインストーミングし、創造力を結集する場を提供しますが、残念ながら発散から収束へ切り替えるのは非常に困難です。

優先順位付けのためには別のミーティングを設けることをお勧めします。私たちもオフサイトの最後に収束のためのミーティングを設けました。

優先順位付け

最終的に、優先順位付けはファウンダー／CEO／プロダクトマネージャーの仕事なので、完全に民主的なプロセスというわけではありません。やりたいことをすべてボードに並べて可視化し、すべてをやる時間は決してないということを認識し、難しい決断をしなければならないと考えることは有用です。

Linear や JIRA スタイルの評価を含む多くの優先順位付けスキーマで私が課題だと感じるのは、優先順位が時間とともに変わりうるという事実を考慮していないことです。レーティングシステムやアイゼンハワー・マトリクス式の評価システムは、小さく容易なステップで情報を得ていく際の、実験の価値や戦場の霧のような不確実性を織り込んでいません。私は、アイデアの「容易さ」と「ポテンシャル」に基づく2つの数値による評価システムを提案しました。それぞれ1から10で評価します。そして、評価の範囲に境界を作ろうとしました（つまり、容易さスケールで1が何を意味し10が何を意味するのか、ポテンシャルスケールで1と10がそれぞれ何を意味するのかというレベル感を定義するのです）。

そしてこれらのスコアを掛け合わせたり足し合わせたりして、追求したいアイデアを点数でランク付けしようと考えました。私たちは「容易さ」のスケールに慣れていなくて……。

全員が最も苦労したのは「容易さ」のスケールでした。というのも、「E」を「effort（労力）」と解釈してしまったからです。私たちは高い数値がより良いことを表すようにしたかった一方で、手の届きやすい果実ばかりを選ぶわけではないという事実も認めたいと思っていました。私たちは、成果が期待できる手の届きやすい果実と、長期的には報われることが期待されるより困難なものを、バランスよく選びたいのです。

懇親

たいていの人は、気恥ずかしいチームビルディング・アクティビティにうんざりしています。正直なところ、私たちは一緒に食事をしたことと Blueberry Hill を訪れたこと以外、あまり社交的なことはしませんでした。セントルイスに行く機会があれば、ぜひ訪れることを強くお勧めします。それで十分だと思いますが、私たちのような小さなチームにとってより良いソーシャル活動のアイデアがあれば、ぜひ聞いてみたいです。