新しいプロジェクトが始まるたびに、同じ誘惑がささやきかけてくる。エディタを開き、フレームワークを選び、コードを書き始めるのだ、と。MaxOSのクリエイターであるMax Paardekamは、その誘惑を痛切に感じていた。数週間前まで、このプロジェクトは彼のノートの中に散らばったアイデアに過ぎなかった。彼の直感は、Cursorの中でTypeScriptを書き続け、マッスルメモリーとオートコンプリートに身を任せて勢いをつけることだった。しかし、彼はそれに抗った。アプリケーションのコードを書く代わりに、彼が生み出したのは、より稀少で、かつ壊れやすいものだった。それは、完成されたアーキテクチャである。
その決断は、最初は停滞のように感じられた。ツールが整い、ボイラープレートが数秒でインストールできる現代において、立ち止まって図形や矢印を描くことは、馬鹿げているように見えるかもしれない。しかし、MaxOSは、単なるWebビューをElectronでラップしただけの代物になるつもりはない。目標は、長年の使用、リファクタリング、そして拡張に耐えうるものを作り上げることだ。それほどの寿命を持つシステムには、素早いスタート以上の、より深い何かが必要となる。最初のimport文を書く前に、一貫した思考が必要なのだ。
なぜIDEを後回しにできるのか
現代の開発環境では、計画と実行の境界線が曖昧になっている。CursorのようなAI支援エディタを使えば、コメント一つでコンポーネント全体を生成することさえ可能だ。フィードバックループは即座に回り、UIが形になっていく様子を見ることで得られるドーパミンは、抗いがたいものがある。Paardekamもまさにその前提で始めていた。初期のエネルギーの大部分は、直接TypeScriptファイルへと注ぎ込まれるはずだった。しかし、彼は次第にその時間を純粋な設計作業へと振り向けていった。
これは、ソロ開発者にとって困難な転換である。自分自身がエンジニアリングチームのすべてであるとき、ダイアグラムツールやテキストドキュメントに費やす一時間は、リリースから奪われた一時間のように感じられる。しかし、初期段階のコードは、しばしば「進捗」を装った「負債」となる。最初の午後に作り込んだ前提条件のせいで、新しい機能を追加するたびに場当たり的な修正が必要になれば、動くプロトタイプの新鮮さはすぐに失われてしまう。エディタから自分を遠ざけることで、Paardekamは、時間が経つほどに複利で効いてくる唯一の資産を手に入れた。それは「明晰さ（clarity）」である。
機能ではなく、システムとして考える
この数週間における最も重要な変化は、技術的なものではなく、認知的なものだった。ソフトウェアアーキテクチャを真剣に捉えると、自問自答する問いそのものが書き換えられる。Paardekamは、機能中心の考え方でプロジェクトに取り組むのをやめた。特定の機能をどう付け加えるか（bolt on）を問うのではなく、より困難な問いに向き合った。「将来のあらゆる機能をより容易に追加できるようにするための、基盤となる構造とは何か？」という問いだ。
その違いは重要だ。「機能」の考え方では、ソフトウェアをToDoリストのように扱う。検索機能を実装し、次に通知機能を、その次にエクスポートボタンを実装していく。一方、「システム」の考え方では、検索、通知、エクスポートが、いかにして同じデータモデル、同じイベントバス、そして同じ権限レイヤーを共有できるかを問う。それは、アプリケーションの「文章」を書く前に、その「文法」を設計することを意味する。初期コストは高くなるが、その見返りとして、将来の作業は「組み立て（assembly）」ではなく「構成（composition）」のように感じられるようになる。
これは、通常であれば10個もの異なるアプリケーションに分かれている機能を統合することを目指すMaxOSのようなプロジェクトにとって、特に極めて重要だ。システム的な思考なしに密な統合を行えば、壊れやすいブリッジと一貫性のない状態の悪夢へと変わる。システム的な思考があれば、ワークスペースは、継ぎ接ぎのツールの連合体ではなく、一つの生命体のように振る舞う。
オペレーティングシステムではなく、ワークスペースを
Paardekamは、自身の野心の境界線について率直に語っている。MaxOSはWindowsやmacOSに取って代わるものではない。ドライバー、メモリ割り当て、あるいはハードウェア抽象化レイヤーを管理することを目指しているわけでもない。ターゲットは、より身近なもの、すなわち「ワークスペース」である。
ほとんどのナレッジワーカーは、断片化された環境の中で生活している。メールクライアントからカレンダーへ、メモアプリからターミナルへ、デザインツールからメッセージングプラットフォームへと飛び移る。その飛び移りのたびに摩擦が生じ、文脈は失われ、注意力は散漫になる。オペレーティングシステムは舞台を提供するが、劇を演出するわけではない。
MaxOSは、その体験を一つの環境へと統合することを目指している。それは、ユーザーの仕事の流れを理解し、より迅速に動けるよう積極的にサポートする環境だ。これは従来のOSを構築するのとは異なるエンジニアリング上の挑戦である。ワークフローに対する深い共感、スコープの冷徹な削ぎ落とし、そしてユーザーにツールへ適応させるのではなく、ユーザーの意図に適応するインターフェースが必要となる。ワークスペースを置き換えるということは、習慣を置き換えるということだ。そして習慣が変わるのは、新しい選択肢が「学習コスト」ではなく「解放感」として感じられたときだけである。
静かな数週間に築かれたもの
Paardekamのアーキテクチャ・フェーズでは、2つの具体的な成果物が作成された。第一に、明確なビジョンとミッションの定義である。これは単なるマーケティング用の美辞麗句ではない。一人のテクニカル・ファウンダーにとって、それは究極のスコープ・ガード（範囲の守護者）として機能する。チャットのサイドバーを追加すべきか、プラグイン・マーケットプレイスを作るべきかといった決断を迫られたとき、ミッション・ステートメントはその機能を歓迎するか、あるいは却下するかを判断する基準となる。第二に、彼はプロジェクトの完全なブループリント（設計図）を完成させた。
計画の全体像がエンドツーエンドで示されたことで、プロジェクトの心理状態が変わった。ノートに書かれたアイデアは仮説のように感じられるが、ブループリントは「必然」のように感じられる。それは、修正コストが低い段階でギャップを露呈させ、最も困難なリスクがどこに潜んでいるかを明らかにする。この段階では、正確なドキュメントは、コードの行数よりも真に重要である。コードはリファクタリングできるが、曖昧な前提は、どれほど深夜にデバッグを繰り返しても解消できない技術的負債として固着してしまう。
紙からモノレポへ
アーキテクチャが完了し、次のフェーズが始まった。Paardekamはドキュメントからコードへと移行しており、まずはモノレポの初期化から着手している。この移行には特有の不安が伴う。ブループリントは「約束」であり、コードベースは「証明」である。彼は、設計が実装という現実に直面したときに耐えうるものかどうか、不安を感じていると認めている。その正直さは、理論がライブラリのバージョン、エッジケース、そしてクロスプラットフォーム動作の実態と衝突したときに初めて現れる「未知の要素」に対する、健全な敬意の表れである。
モノレポの初期化は、単なる儀式的な git init ではない。それは論理的なアーキテクチャを反映する物理的な構造を決定するものである。パッケージがどこに配置され、それらがどのように相互依存し、レイヤー間の境界がどこに設定されるかは、数週間にわたる計画の成果を反映することになる。適切に行われれば、最初のフォルダ構造とビルド・パイプラインは将来のコントリビューションを導くガイドとなる。不適切に行われれば、プロジェクトに触れるすべての開発者を、その後何年にもわたって静かに苦しめることになるだろう。
真の教訓
Paardekamの経験は、現代のソフトウェア文化の多くを支配している「速度至上主義（cult of velocity）」に一石を投じるものである。迅速にリリースし、成長を示し、対話の代わりにコードで済ませようとする強烈な圧力がある。しかし、一部のプロジェクト、特に長く存続することを目的としたプロジェクトにおいては、忍耐が報われる。変数を宣言する前に、ビジョンを定義し、ブループリントを描き、システムを設計するという規律は、古くからある助言だが、その真実性が失われることは決してない。
もし今、アイデアを抱えてエディタを開きたくてたまらないのであれば、数日間の入念な設計が、後に発生する数ヶ月に及ぶ散漫な手戻りを防いでくれるのではないか、と考えてみてほしい。アプリが動くことによるドーパミンはすぐに消え去るが、優れたアーキテクチャがもたらす明快さは複利のように積み重なっていく。まずは、自分が何を、なぜ作っているのかを正確に把握することから始めよう。タイピングは後回しでいい。