## 要約
- 自分は「機能を作ること」よりも、開発が安全に・継続的に行われる構造を作ることに強い関心がある
- 実装そのものよりも、なぜその設計が良いのか / 開発者はどこまでを考えればよいのか といったことに面白さを感じる
- 研究や開発の中で、CI/CDや環境整備、再現性を高める基盤づくりに没頭していた
近いうちにClean Architectureを読んでみる。
## 今までやってきたことの言語化メモ
私はコードを書くことが好きですが、それ以上に「なぜそのコードが良い設計になっているのか」ということを考えたり、「どうすればより高速にミスなく開発サイクルを回せるか」という仕組みづくりが好きな気がしています。 単に動くものを作ることや、既存のAPIを正しく使うのはAIを使って簡単にできるようになってきました。それよりも、仕組みそのものを整えたり、構造を設計することに強い興味を感じます。
大学院での研究生活を振り返ると、研究や数値実験そのものよりも、数値実験の再現性を高めるための環境構築やCI/CDパイプラインの整備の方が楽しいと感じていました。自分は抽象的な理論で閉じてその理解で終わることよりも、それが現実に動く仕組みを作り上げるところに関与したいということです。
現在取り組んでいる研究室サーバー上でのPoCアプリの大量デプロイ基盤の構築は、その志向をはっきりと表しています。
PoCアプリは1つずつコンテナ化されたWebアプリとして実行されますが、開発者には Dockerfile と entrypoint.sh だけを書いてもらい、Traefikによるルーティングやデプロイ手順、運用上の制約はすべてこちらで引き受けています。
この設計では、「開発者が何をして良くて、何をしてはいけないのか」を明確に定義しており、実装の自由度を意図的に制限することで、全体として壊れにくく、増やしやすい仕組みを作っています。つまり、いわゆるGolden Pathの考えを自然と取り入れた形になっています。
ここで重要なのは、自分が関心を持っているのは特定の技術や言語そのものではなく、「判断をどこで止めるか」「誰が何を考えなくてよいか」といった設計上の意思決定の部分であるということです。この関心は抽象データ型（ADT）の考え方と似ている部分があります。ADTとは、内部実装の詳細は触れずに、「どんな操作が許され、どんな操作が禁止されているか」を定義する概念であり、私はこの考え方を基盤整備をしながら自然と身につけていたのだと思います。ただし、ADTのような思考を体系的に学ぶのが目的なのではなく、設計を説明してそれを正当化するためのツールとして使いたい、そのために必要なことを学びたいという位置づけにあります。
## Rustを学ぶべき？
RustはADT的な思考や関数型的な設計を「意識しなくても使える」言語ではなく、「きちんと設計しないと書けない」言語だと思います。状態遷移や所有権などを曖昧にしたままではコンパイルが通らず、「この操作は本当に許されているのか」を常に問われます。 これは、設計をごまかさずに考え抜く訓練として非常に強力であり、CI/CDの内部ツールや自動化ツールを書けば私の興味に合っている学習方法になるのかなと思います。