Arda Akgür
この文章は完璧なシステムの作り方を説くものではない。完璧なシステムなど存在しないと、私は思っている。
これは何年もかけてシステムを作り、コードを書き、学生に教え、動いているシステムが壊れる理由を見てきた末に得た原則だ。
私にとってシステム工学は、技術選定よりも前に、問題解決である。
1. システムで最も大切なのは安定である
どんな基本ロジックでシステムを作ったとしても、動き始めたあとそのロジックを絶えず書き換えないこと。
パラメータは変えてよい。小さな改善もしてよい。バグは直す。しかしコアのルールを道の途中で書き換え続けると、やがて最初の設計も新しい設計も手元に残らない。
本当に大きな変更が必要なら、現行システムを無理に曲げるのではなく、新しいバージョンを始めることが正しい場合がある。
試合の途中でルールを変えるな。
2. 動く最小のシステムを作れ
初日に百万ユーザー、五年後のスケール、まだ存在しない問題のために巨大アーキテクチャを組もうとするな。
それは多くの場合エンジニアリングではなく、YouTube建築である。
今日の問題をできるだけ早く解く、理解できて、実際に動くシステムを作れ。
いつか本物のスケール問題に当たったら、それは良い問題だ。そこまで生きたということだ。
V2が必要なら、V2は違うやり方で作ればいい。
3. 現状維持から距離を取れ
誰もが使っている技術やアーキテクチャだからといって、あなたの問題に正しいとは限らない。
「Industry standardだから」だけでは技術的根拠にならない。
まず問題を定義せよ。それからその問題を最もよく解くものを見よ。
答えが皆のやり方なら使え。違うなら、違うことを恐れなくていい。
道具ではなく問題に忠実であれ。
4. 空腹時・疲労時に重要な決断をするな
アーキテクトの最も重要な道具はコンピュータではない。自らの知性だ。
空腹と深刻な疲労は判断の質を壊しうる。普段なら拒む案が「それで十分」に見えはじめ、不要なリスクを取り、怒りやすくなり、終わらせるためだけの悪い決断を受け入れるかもしれない。
ときにその状態は酔ったようにも感じる。まだ決められると思う——だが判断はすでに崩れている。
そんなときは定型作業をしてよい。コードを書き、テストを回し、ログを見よ。だが高い代償のアーキテクチャ判断は、できる限りするな。
決断が朝まで待てて、自分が消耗しているなら、朝まで待たせよ。
空腹と疲労は敵だ。
システムを設計する前に、アーキテクト自身が稼働状態でなければならない。
5. コードが変わるならドキュメントも変わらねばならない
意味のあるコード更新のたびに、ドキュメントも更新せよ。
ドキュメントを「仕事が終わってからの別タスク」と思うな。コードとドキュメントは同一変更の二つの半分だ。
現代のAIツールのおかげで、これは昔よりずっと楽になった。重要な変更のあとは、AIに変更と関連コードを点検させよ。システムの現状を述べるMarkdownを生成するか、既存を更新せよ。
可能な限りリポジトリ内に `.md` としてドキュメントを置け。Markdownは単純で、バージョン管理しやすく、GitHubでも読みやすい。
バックエンドの変更がフロントエンドに影響するなら、関連Markdownをフロントエンドチームと共有せよ。
フロントエンド開発者は、コードを掘る前に、エンドポイントの動き、request/response、変わった振る舞い、注意点を理解できるべきだ。
同じ原則はチーム間・サービス間の変更にも当てはまる。
AIはドキュメントを加速する。正しさの責任は、依然として変更を行ったエンジニアにある。AIが書いたドキュメントを未検証のまま真実とみなすな。
コードを更新してドキュメントを更新しなければ、仕事は終わっていない。
ドキュメントはシステムの記憶である。
6. 完成形をまず頭の中で見よ
コードを書き始める前に、完成したシステムを頭の中で見られるべきだ。
見えないなら、ペンと紙を取って描け。
ER図である必要はない。UMLである必要もない。誰かの標準に合わせる必要もない。
箱を描け。矢印を描け。横にメモを書け。しっくりくるように描け。
大切なのは絵の美しさではない。システム全体を見えていることだ。
見えていないシステムをコードで発見しようとすると、設計と実装を同時に始めることになる。
まず見よ。それから作れ。
7. システムが誰のためのものか忘れるな
非技術的なマネージャーやユーザーのアイデアを見下すな。
技術的には奇妙に感じる考えが、あなたが一度も考えなかった角度から問題を見ていることがある。
彼らの仕事は、あなたのように考えることではない。
あなたの仕事は、彼らが何を望むかを理解し、可能なら動くシステムに変えることだ。
夢を聞け。実現を試みよ。結果が本当に驚くこともある。
自分のためではなく、使う人のためにシステムを作れ。
8. アーキテクトはコントロールを失ってはならない
深刻なシステムにはフェイルセーフが必要だ。
必要なら単一の環境変数で止められるべきだ。必要なら制御された管理エンドポイントを持て。重要な部品を無効化できる道を考えよ。
これらはセキュリティを破る秘密の裏口であってはならない。認可され、安全で、できればログされる仕組みであるべきだ。
どれほど自律しても、アーキテクトは自分のシステムの観客になってはならない。
最終制御はアーキテクトに残る。
9. まず自分の誤りを疑え
システムが遅くなったら、すぐにハードを責めるな。
見えないデッドロックがあるかもしれない。悪いクエリを書いたかもしれない。不要なネットワーク呼び出しがあるかもしれない。アーキテクチャ上の誤りがシステムをロックしているかもしれない。
もちろんハードが本当に不足している可能性はある。
だがまず測定せよ。
エンジニアは自分が間違えることを認められなければならない。恥ではない。
間違いを認められない人は、間違いを直せない。
10. 学生を育てよ
システムが自分の頭の中だけで生きることを許すな。
学生にシステムを教えよ。
自分が明日いなくても、システムは続きなければならない。他者が理解し改善できることは権威を減らさない。良いアーキテクトである証拠だ。
一人しか理解できないシステムは強くない。脆い。
知識を伝えよ。
11. 小さく、足並みの揃ったチームで働け
一人アーキテクトになるな。不必要に大きなチームも作るな。
学びへの門が開き、聞き、質問し、学生の精神を失っていない人と働け。
批判は貴重だ。ジュニアが自分の見逃したバグを見ることがある。聞け。
だが絶え間ない反対を仕事の流儀にする人は、システム構築において危険だ。あらゆる決定を何度も蒸し返すことはアーキテクトを方向転換させ続け、やがて安定を壊す。
決定まで議論せよ。
決まったらチームとして実行せよ。
継続的な反対で前進を止める人と長く働く必要はない。
12. 創造的であれ、しかし単純であれ
良いシステムを見た経験あるエンジニアは「へえ」と言えるべきだ。
同じシステムに入った良いジュニアは、およそ一週間で何が起きているかだいたい理解できるべきだ。
この二つは対立しない。
真の熟練は、百個のサービスを使うことでも、誰も理解しない抽象を作ることでもない。
複雑な問題を、驚くほど単純なシステムで解くことだ。
複雑さは技ではない。
13. 新しいものすべてを古いシステムに詰め込むな
新しいアイデアが来たとき、最初の反射は現行システムへ足すことであってはならない。
新しいサービスが必要なときがある。新しいアプリが必要なときがある。本当にV2が必要なときもある。
古いシステムを永遠に拡張しようとすると、やがて初期の単純なシステムの上に何年もの決定と例外を積み上げることになる。
ゼロから始めるほうが安く、きれいで、正しい場合がある。
変化は常に現行システムの肥大化を意味しない。
14. AIを道具として使え
AIはシステムを本気で強化できる。
特に現代のreasoningエンジンは、構築時にもランタイムにも強力だ。
コードを見て、エッジケースを見つけ、判断を支え、自然言語を理解し、古典的アルゴリズムが苦手な曖昧な問題を解ける。
だがすべてをAIに押し付けるな。
単純な決定的解法で足りるならそれを使え。reasoningが本当に価値を足すならAIを使え。両方がよいならハイブリッドを作れ。
AIに仕事を与えよ。システム上の権威は与えるな。
15. AIに奇跡を期待するな
AIの賢さは、使う人の賢さ次第だ。
問題を誤って述べれば、強力なモデルでも誤った解を非常に速く出しうる。
自分が欲しいものを知らねばならない。答えを評価できるほど問題を理解していなければならない。間違ったときに気づかなければならない。
AIがあなたの代わりにエンジニアである必要はない。
うまく使えば、あなたの工学能力を拡張する。
奇跡を期待するな。
16. 性格は引き、クソは臭う
It is what it is.
すべてに深い意味を探すな。
バグはただのバグのことがある。悪いコードは悪いコードだ。動かないアイデアは動かない。誤った決断は誤っている。
単純な説明で足りるなら、余計な理論で問題を飾るな。
まず目の前の現実を見よ。
17. 師を模倣することを恐れるな
学生のとき、すべてを発明する必要はない。
私が学生のころ、学ぶためにArrayListのような既存構造をゼロから書いた。目的は新しいデータ構造を発明することではなかった。
目的は、師がやったことを自分でやり、仕組みを理解し、自分の解と比べ、成長することだった。
模倣による学習は盗作ではない。
まず師がやったことをできる水準に至れ。なぜそうしたかを理解しようとせよ。それから問い直せ。それから自分の方法を育てよ。
理解していないものを、違うためだけに拒むのは創造ではない。
まず学べ。それから壊せ。
結び
良いシステム工学は、できるだけ多くの技術を使う芸術ではない。
問題を理解し、解法を頭で見、できるだけ単純に作り、動くものの安定を守り、必要なときに自分の過ちを認めることだ。
良いアーキテクトはまず自らの心の状態を知る。空腹、疲労、健全に考えられないときに大きな決断をしないことも、工学の一部だ。
コードと同じくらいシステムの記憶を守る。変更を文書化し、その知識をシステムを育て続ける人々と共有する。
システムを制御する——崇拝しない。
チームを導く——学生を黙らせない。
AIを使う——思考を外注しない。
過去から学ぶ——現状に屈服しない。
そして何より、システムが動いているならなぜ動くのか、動いていないならなぜかを理解しようとする。
残りはすべて道具だ。
Arda Akgür
ARCシステム原則
v0.1 Final