松田信介@今日も元気だ、ご飯が美味い

今回のCTOが話題になってる中で、各々が考えるCTO像が見えてきたんだけど、全体的に目線が低いなと感じてしまった。 CTO Nightでは技術の話題なんかほとんど出なくて、組織や育成、採用、ビジネスの話ばかり。じゃあ技術がいらないのかというとそうではなくて、飲み会の合間に障害対応してる人もいる。技術は出来て当たり前の世界では技術の話なんかほとんどしないんですよ。 技術は手段、目的はビジネスになってない人がCTOはやってはいけないし、仮にそういう人をアサインしてしまうと開発組織ごと壊れます。

設計って漠然としちゃってるので、エンジニアがやってる設計並べてみます。 「設計できる人になりたい」って相談よく受けるんですが、設計って一枚岩じゃなくて、抽象度ごとに全然違う作業が積み重なってます。 上流（何を作るか決める） ・業務設計 ・サービス設計 ・UX設計 ・情報設計 ・ドメイン設計 システム化する範囲としない範囲の線引きをするところ。ここを間違えると、下流でどれだけ綺麗に書いても死にます。 アーキテクチャ領域（全体の骨格） ・システム方式設計 ・インフラ設計 ・ネットワーク設計 ・セキュリティ設計 ・可用性/信頼性設計 ・性能/キャパシティ設計 ・コスト設計 ・運用設計 ・移行設計 「作った後どう生き延びるか」を先に決める層。 外部設計（境界を決める） ・画面/UI設計 ・API設計 ・バッチ設計 ・イベント設計 ・データ設計（概念/論理） ・認証認可 ・権限設計 ・エラーメッセージ設計 自分と外側の約束事。一度公開すると変えづらいので、実は一番慎重にやるべきところ。 内部設計（実装の構造） ・モジュール/クラス設計 ・テーブル設計 ・状態遷移設計 ・トランザクション設計 ・例外設計 ・ログ設計 ・キャッシュ設計 ・命名規約 「動くコード」と「変更できるコード」を分けるのがこの層。 横断的な設計 ・テスト設計 ・CI/CD設計 ・デプロイ/リリース設計 ・組織設計 組織設計を入れてるのは、コンウェイの法則そのままで、チームの境界がそのままシステムの境界になるからです。 AI時代に増えたやつ ・コンテキスト設計 ・エージェント設計 ・人間の介在点設計（どこに承認ゲートを置くか） ここ2年で新しく生まれた設計領域。まだ誰も正解を持ってないので、みんな模索中。 で、全部並べて気づくのは、やってることは同じだということ。 制約の中で、両立しないもののどちらを取るか決めて、その理由を残す。 一貫性か可用性か。疎結合か単純さか。今の速度か後の変更容易性か。 だから設計書は成果物じゃなくて副産物で、本体は「捨てた選択肢とその理由」の方なんですよね。 逆に言うと、トレードオフが存在しない箇所は設計じゃなくてただの作業です。 AIが作業を持っていく時代に残るのは、こっち側です。