5月12日、matklad氏が「Learning Software Architecture」と題した記事を公開した。
rust-analyzer作者が覆すソフトウェア設計の常識
「ソフトウェア設計は技術の問題ではない」— これは、**rust-analyzer**（RustのIDE支援ツール）の開発者として知られるmatklad氏の断言だ。バイオインフォマティクス研究者からの「科学的コードと産業用ソフトウェアの品質差をどう埋めるか」という質問に対し、氏は実体験に基づいた回答で従来の設計論を覆している。
rust-analyzerは、**Rust言語**のコード補完や構文解析を担う重要なツールで、現在多くのエディタで使用されている。この複雑なプロジェクトを通じて得た知見から、氏は大学の形式的な「設計」コースを「幼稚園児が消防士ごっこをしているようなもの」と表現し、真の学習は実際のプロジェクトでのリーダーシップ経験から得られたと述べている。
コンウェイの法則が支配する現実
記事の核心は、1967年にメルビン・コンウェイが提唱した**コンウェイの法則**の重要性だ。「ソフトウェアの構造は、それを開発する組織の構造を反映する」というこの法則は、現代でもソフトウェア開発の現実を的確に表している。
matklad氏はneugierigの言葉を引用している：
プログラミングについて学んだことを一文でまとめるなら：私たちはプログラミングをコードを書くことだと語るが、結局コードよりもアーキテクチャが重要で、アーキテクチャよりも社会的問題の方が重要だ。
科学的コードと産業用ソフトウェアの品質差は、技術知識の不足ではなくインセンティブ構造の違いにあるという。「3ヶ月でPhDの論文を発表する必要がある」といった制約が、コード品質を決定的に左右するのだ。
rust-analyzerで実証された組織設計
matklad氏の理論は、rust-analyzer開発で実践されている。このプロジェクトは「深い（コンパイラ）」部分と「広い（多数の専用機能）」部分を併せ持つ特殊な性質を持つ。
氏が発見したのは、異なる部分が異なるタイプの貢献者を惹きつけるという現実だった：
- 「深いコンパイラ」部分：少数の優秀で献身的な貢献者
- 「幅広い機能」部分：多数の週末開発者（1-2時間の限定的な貢献が可能）
この洞察から、氏はrust-analyzerの開発環境を週末開発者向けに最適化した。rustcのビルド不要、安定版でビルド可能、C依存関係なし、全テストが数秒で完了という設計にこだわったのは、参加障壁を下げるためだった。
さらに、内部を独立した機能に分割し、各機能を実行時にcatch_unwindで保護。「ハッピーパス動作＆テスト済み」というシンプルなマージ基準を設け、品質よりも参加しやすさを優先している。
実践的な学習リソース
体系的な単一書籍の推奨は難しいとしながらも、氏は以下のリソースを挙げている：
動画・記事
- **Gary BernhardtのBoundariesトーク**：具体的アドバイスと抽象的思考の両方を提供
- **How to Test**（氏の記事）：一般的なテスト手法の多くを「呪術的な売薬」と批判
- **∅MQガイド**：コンウェイの法則的思考の入門として最適
- **Ted Kaminski**のブログ：「存在しない本へのメモ」として最も体系的なソフトウェア開発理論を提供
書籍
- 「Software Engineering at Google」
- Ousterhoutの「A Philosophy of Software Design」
設計を社会問題として捉える新視点
matklad氏の回答は、ソフトウェア設計を純粋に技術的問題として捉える従来の視点を覆している。社会的・組織的文脈こそが設計品質を決める最重要要素であり、これは特に研究環境から産業環境への移行を考えるエンジニアにとって重要な視点といえる。
コンウェイの法則が示すように、優れたソフトウェアを作りたければ、まず優れた組織構造を作ることから始める必要があるのだ。
詳細はLearning Software Architectureを参照していただきたい。
