ニューレガシー徹底抗戦ガイド
JJUG CCC 2025 FALL kawashima-san
吐き気を催すパターン・ランゲージ
アーキ部はいつもよる遅め開催で見逃しているのでkawashima-sanセッションを聴講できるの久しぶり
コードがぐちゃぐちゃとは
「大きな泥団子」論文に書かれている内容
すべてが他の全てとやり取りする
だが「依存関係としての複雑さ」は実際にはほとんど見られない？
画面ごとに担当者が割り振られるので、画面間の依存関係は少ない
お団子アーキテクチャ
結合＝モジュール結合ではなく、セマンティックカップリング（意味的な結合）
同じ仕様・扱いでなければならない処理やデータが複数の画面に散乱している
だが、コードとしての依存関係がないので見えない
複雑さの壁
複雑なコードは根気強く読めば分かる？
情報が不足しているコードは、いくら読んでもわからない
仕様の再構築（再解釈≒エスパーか？）が必要
この「解読不能な複雑さ」が属人性の要因ではないか
言語化されていないナレッジを有す「誰か」に依存することが複雑性の原因になると
ニューレガシーアンチパターン
（Xに載ってた画像のやつ）
画面駆動設計
テーブル駆動設計
早期サイロ化
画面駆動設計からの早期に担当者分割することでサイロを生む
SIerとしての実装効率向上を目指すと促進される
「仕事算」のアナロジーは効率や文脈知識を無視してる
が、一定無視して仕事を進められるのが早期サイロ化
見積もりに大量のバッファを積み、帳尻を合わせるのがITゼネコン仕草
「正しい」とは…
画面駆動・テーブル駆動の組み合わせにより爆誕したクラスをどうつなぐか？を設計？するが配線プログラミング
モダンなパターンでもよく見ると配線プログラミングな例はよくある
儀礼的レイヤリング
レイヤありきで振り分ける（目的がない）
レイヤ例としてのOSI参照モデル
Contract-less Service
「画面協会でバリデーションするから」という理由で、以降のレイヤで事前条件が設定されない
model-overloadingを書けなかった
なぜアンチパターンがは何度でも再現するか？
設計者と実装者が分離するから
SIerあるある
プログラマの時間の使い方
プログラムの理解が50％超
25%は調べ物
コード編集は5%程度
一番の問題は抽象レイヤの喪失だろう
影響調査が困難に
プログラマはただのコーダーに
すべての変更に「お伺い」が必要になる
徹底抗戦するには
原因は？
仕様モデルの不認知
抽象概念の喪失
対策
仕様モデル駆動設計
テキストは認知負荷が高い
データモデリングに概念モデル、論理モデル、物理モデルがあるように
ドメインモデルにも概念モデル、仕様モデル、実装モデルがある
概念モデル why
仕様モデル what 何をしなければないかなら、どのような情報を保持するか
実装モデル how
どう書く？
形式手法？
DSL？
data データ名 入力 = 出力
behavior 振る舞い名 = データ名 演算子 データ名 … -> データ名
表現できないことはコメント
着目すべき点（関心事を分ける・単一責任になるまで）
スタンプ結合を避ける
振る舞いの名に注目
モデルなき仕様駆動開発はニューレガシーの温床になるのでは