ソフトウェアアーキテクチャの学習

2026 年 5 月 12 日

研究者として物理学者でありながら、ソフトウェア設計のスキルを修得しようというメールへの返信です：

キャリアの初期にバイオインフォマティクス研究所に所属していた経験から、あなたが話されている「科学のためのコード」という現象については理解できると考えています。私の考えを述べさせていただきます。

第一番目のメタ的な観察事項は、「ソフトウェア設計」は実践を通じて学ぶことが最も適しているという点です。大学では正式な「設計」に関する講義にも参加し、コースプロジェクトにおいて「アーキテクト」として役割も務めました。しかし、その経験はほぼ形式的なものに過ぎず、幼稚園児が消防士を演じるような模擬訓練に近いものでした。本当に実用的なことを教えてくれたのはキャリア上の偶然でした。 IntelliJ Rust という second な本格的なプロジェクト（※文脈より「第二个主要プロジェクト」）が私をソフトウェアリーダーの地位へと引き上げ、設計の問題として直面させる機会になりました。IJ Rust の開発中には確かにいくつかの過ちも犯しましたが、深刻なものではなく、そこから多くのことを学びました。つまり、良いニュースとして言えるのは、ソフトウェア工学は原理から理解することができ、かつ無数のブログ記事を読むことでさえも有用な分野だということです。

第二番目のメタ的な観察事項（ただしこれは残念ながらネガティブな側面です）：コンウェイの法則が重要です。ソフトウェアの生成プロセスは、それを生み出す組織の社会的構造を反映して繰り返されます。neugierig による優れた言葉巧みな表現ではこう語られています：

「私が学んだことを一言でまとめれば、プログラミングとはコードを書くことだと思われているが、実際にはコードよりもアーキテクチャの方が重要であり、さらにアーキテクチャよりも社会的事象の方が重要なのだ」と。

あなたが産業用ソフトウェアと科学用ソフトウェアの間に感じる違いについて推測すると、それはどちらかと言えばソフトウェア構築の知識の違いというよりは、人々がそのソフトウェアを生み出すよう駆り立てるインセンティブ構造（動機付け）の有無によるものだと思われます。「私の博士号論文を 3 ヶ月以内に発表しなければならない」といった状況が、一つの重要な説明要因ではないでしょうか。

ここで行うことができることは二つあります。一つ目は、時折プロジェクトのインセンティブ構造を設計したり、それを変更し推动する機会を得ることがあることです。これは極めて稀なことですが、もし実現できたら非常に大きな影響をもたらします。TIGER_STYLE の成功の秘密は、単に規則そのものにあるのではなく、これらの規則が有効なアイデアとなるための社会的文脈にあります。

二つ目は、悲嘆の四段階を乗り越えて受容に至るスピードラン（短期間で完了）を行うことです。インセンティブ構造は望むままとはほとんどなりません。しかし、それを変更できない場合でも、それに適応することは可能です。これは多くの産業用ソフトウェアプロジェクトについても同様で、正しく行うための十分な時間が与えられることはまずなく、制約の中で最善を尽くす必要があります。

rust-analyzer を例に挙げて説明しましょう。このプロジェクトの物理的現実とは、極めて深い側面（コンパイラであること！やったね！）と、極めて広い側面（LLM と逆に、古典的な IDE は多数の特注機能で構成されている）が同時に存在しています。社会的現実としては、「深いコンパイラ」は才能ある少数の専念した貢献者を惹きつけやすく、「幅広い機能」は土曜日の戦士（※「週末にしか参加できない人々」）、Rust を学びながら持続的なプロジェクト参加能力を持たないが、自分の課題を解決するために数時間割ける人々にとって良いフィット感を持っています。

rust-analyzer が rustc の構築を必要とせず、安定版の Rust に基づいており、C 依存関係を持たず、全体としてのテストスイートの実行時間が秒単位であることを強調した理由は、高インパクトの貢献者を惹きつけることを目的としていました。借 Checker（所有チェックの実装）に取り組んでもらうために、他のことを考えずに作業できるようビルドシステムを整備しました。

土曜日の戦士を惹き付けるために、rust-analyzer の内部は複数の独立した機能に分割されており、各機能はランタイムで catch_unwind によって保護されています。そこでの品質への過度な配慮は意図的に避け、機能の Pull Request を受理する基準は「happy path が動作し、テストが通りさえすれば良い」というものでした。コードがクラッシュしても問題ありません。むしろクラッシュが新たな貢献者を惹きつける条件さえ満たせば：

• 品質問題は特定の機能に限定され、他の部分に波及しないこと、
• ランタイム上、クラッシュはユーザーには目に見えないこと（rust-analyzer の機能は不変スナップショットと互換性があり、データを毒化してしまわないことが不可欠です）。

これに対し、機能をサポートするコアバネを扱う場合においては、品質への関与度相対的に厳格でした。

インセンティブ構造に適応するのではなく、それを変更することに注力するという注意点もあります。未来は不確かで、かつ最も不便な形で現れる傾向があります。rust-analyzer の実験の当初の動機は、並列コンパイラ（IntelliJ Rust 内にあるもの）を記述する必要を回避し、LSP のより優れたアーキテクチャのプロトタイプを作成して、その知見を rustc にバックポートできるようにすることでした。したがって、コア部分（特にコア部分）ではコードは非常に実験的でした。まあ、仕方ありませんね。今さらにコンパイラを一つ抱えることになりましたかね。

類似したことが uutils プロジェクトでも起こったかもしれません。それは Rust を学ぶ人々の主要な目的地として始まりましたが、やがて Ubuntu の coreutils 実装へと発展しました。

最後に具体的な推奨事項についてですが、残念ながら私が単一の書籍を通じて真理を伝えることができるような本を知りません。おそらくそのような本はボルヘスによる寓話的な短編小説の中だけで見つかるでしょう。練習がここでは不可欠な要素であることは明白です。しかし、以下に注意すべきいくつかのポイントをご紹介します：

• Gary Bernhardt による「Boundaries Talk」は生涯のベストで、堅固なオブジェクトレベルの助言を含んでいます。私にとってはメタ的な問いを促すきっかけになりました。
• 「How to Test（テストする方法）」については、私が持っておきたかった本です。テストの重要性を即座に理解しましたが、多くの広範に引用されているテストに関するアドバイスがシャーマニズムのインチキであることに気づくまでに長い時間がかかりました。そして実際に機能するものについて概念化することに時間を要しました。
• ∅MQ ガイドおよびピーター・ヒンテンズによる著作全般は、コンウェイの法則的思考を導入してくれました。「rust-analyzer の機能開発」アーキテクチャとは何か？——楽観的なマージングが適用されたものです。
• Jamii による「Reflections on a Decade of Coding（コーディング十年の考察）」は非常に優れたもので、極めてメタ的な視点を持っています。私が出したリンクリストの最初として意図的に配置しました。
• Ted Kaminski のブログ記事は、ソフトウェア開発の理論において最も一貫性があり、架空の本への注釈として適切に位置づけられています。

実際の書籍については、「Software Engineering at Google（グーグルでのソフトウェア工学）」および「Ousterhout の『The Philosophy of Software Design』（ソフトウェア設計の哲学）」が頻繁に推奨されています。これらは確かに良い本です。特に前者は、私にとっていくつか重要な名称を助けることができました。しかし、それらは私にとって革新的な内容ではなかったというのが实话です。