はじめに
エンジニアとして働く上で、一見真逆のことを言います。
- 動くものをどんどん作ってください
- 動くだけのものを作らないでください
どういうこと？
「学習のためには」動くものをどんどん作ってください
- 頭で考えるより手を動かした方が圧倒的に理解できる
- 理論だけでうまくいかないことは頻繁にある
- どんどん試行錯誤をするべき
「業務では」動くだけのものを作らないでください
- 「作る」のはゴール地点ではなくスタート地点
- あなたが作ったシステム・機能は数年、モノによっては10年以上使う
- 雑な実装は未来のあなたと未来のチームメンバーを永劫苦しめる
- レガシーをなくすはずが、作った時点からレガシーにならないように
今回は「動くだけのものを作らない」ための話です。
この場ですべてを覚える必要はありません。
頭の片隅に置いておいて、見返し・思い返せるようにしてください。
おさらい: アーキテクチャの目的
前半のおさらい: 📄
【設計入門2026 #2】設計の目的 / 📄【設計入門2026 #3】オブジェクト指向とは？
ソフトウェアアーキテクチャの目的は、変更しやすくすることにある。
現場感覚から補足
- ソフトウェアの価値はソフトであることにある
- 変更できない = ハードウェアにしない
- 変更しないという選択肢はない
- ビジネス上変更の必要がなくても、変更は発生する
- OS・ミドルウェア・ライブラリのアップデート・破壊的変更
- OS・ミドルウェア・ライブラリのEOL
- 連携システムの仕様変更
- …etc
- 何もしないとシステムは"経年劣化"する
- 脆弱性の累積
- ドメイン・システム知識の消失
- 一般的な技術からの乖離
- エンジニア確保困難
- ビジネス上変更の必要がなくても、変更は発生する
余談1: 言語のアップデート間隔
| 言語 | リリース間隔 | サポート期間 | 備考 |
|---|---|---|---|
| Python | 1年 | 5年 | |
| Node.js | 1年(LTS) | 3年(LTS) | マイナーアップデートでも動作が変わる |
| Java | 2年(LTS) | 5年(LTS) |
- リリース即更新することはないので、実際に使える期間はもっと短い
- 累積したバージョンを一気に上げることは難しく、結局1バージョンずつ上げたりする…
余談2: フロントアプリ(Next.js)で1週間にくるライブラリアップデート数
約10件
- マイナーアップデート(機能変更がある)もののみでこれ
- 1年放置すると約520件の変更をチェックする羽目に
これらを実現するために、エンジニアができることを適切に制約するのがアーキテクチャです。
今回はアーキテクチャを考える上での基本的なアプローチについて解説します。
💡
やり方そのものではなく、なぜそうするのか？という部分をうっすらとでも記憶してください。
💡
今回はPythonコードで解説しますが、他の言語でも考え方は同様です。