昔、お客様の基幹系システムをスクラッチ開発していた頃、システム運用担当の皆様ともよく打ち合わせしたが、ビジネスルールを如何にわかりやすくコードに書くかではなく、業務上変わり得るルールならそもそもコードに書かず、ユーザー部門がテーブル登録する仕様にしてくれという話の方が普通だった。
この辺、この三十年ぐらいで、もしかしたらものすごく後退してきてるんじゃないかと感じることがある。
COBOL が Java になろうが、何かの関数型言語になろうが、変わり易いと分かっている業務ルールをハードコードして、リーダビリティ云々と言っているんじゃ、ソフトウェア設計としては、レベルが落ちているとしか言いようがない。
太陽電池でモーターを回し、木をこすって火を起こしている印象だ。
僕のいたのがコンサルティング会社でレベルが高かったー、みたいな話ではなくて、お客様の情報システム部門がまずそういうスタンスだったですね。
確かにやりすぎのリスクはある。普通のマスター項目以上、汎用言語未満、みたいなところで寸止めするのが結構大事。#やりすぎがちなアカウントの述懐
DBのカラムにJSのコード断片入れておいてごにょごにょさせる、みたいな。けっこう凶器じみているかも。
本件、メタプログラミングを志向してるんじゃないんです。変わると言われがちな要件の背後にある変わらぬものを見い出そうとする試みなんですね。まあ、メタプログラミングは本来そうだと言えば、そうかもしれない。
■ 1. 各主張の評価
- 主張(1)「変わり得るルールはコードに書かず、ユーザー部門がテーブル登録する仕様にすべき」:
- 評価: 部分的に妥当だが、過度に一般化されている
- 妥当な点: 税率・手数料等のビジネスパラメータをDB管理することは「設定と実装の分離」の原則と一致する
- 問題点(1): 「変わり得るルール」の基準が曖昧であり、ほぼ全てのビジネスロジックが対象となり得る
- 問題点(2): ユーザー部門への責任転嫁により入力ミスや整合性破壊のリスクが高まり、ミッションクリティカルな基幹系では逆効果となり得る
- 問題点(3): 「昔の普通が今の正解」であるという論拠が示されていない
- 主張(2)「COBOLがJavaになっても変わりやすいルールをハードコードしているのはレベルが落ちている」:
- 評価: レトリックは強烈だが、論理的根拠が弱い
- 問題点(1): 「太陽電池で木をこすって火を起こしている」という比喩は論証として機能しない
- 問題点()2: マジックナンバーの直書きと、DDD等で推奨されるドメインロジックのコード表現を「ハードコード」として同一視している可能性がある
- 問題点(3): 「この30年でレベルが後退した」という主張に客観的なエビデンスがなく、個人的印象に過ぎない
- 主張(3)「やりすぎのリスクはある。普通のマスター項目以上、汎用言語未満で寸止めが大事」:
- 評価: 最も誠実な発言だが、核心的な問いへの回答を回避している
- 問題点(1): 「やりすぎは危険」と自認しながら、線引きの基準・方法論・判断プロセスの具体的な説明が欠如している
- 問題点(2): 「寸止めが大事」という最も実践的に重要な部分の内容が最も薄い
- 主張(4)「DBのカラムにJSのコード断片を入れておいてごにょごにょさせる」:
- 評価: 著者自身が「凶器じみている」と述べており、推奨ではなく逸話として位置づけられている
- 問題点(1): コードインジェクション・デバッグ困難性・型安全性の欠如という、現代のソフトウェア工学で強く忌避されるパターン
- 問題点(2): これを「設計の知恵」として文脈に置くことは主張の一貫性を欠く
- 主張(5)「メタプログラミングを志向しているのではなく、変わらぬものを見いだす試み」:
- 評価: 哲学的には理解できるが、実装との接続が不明
- 妥当な点: 「変わり得る要件の背後にある変わらぬものを見いだす」ことはドメイン分析の本質の一つとして正しい
- 問題点: これは「良いコード・良いドメインモデルとして表現する」こととは矛盾しないため、「だからコードに書くな」という結論には論理的に直結しない
■ 2. 総評
- 論拠の具体性: 低い
- 個人的経験と印象論が中心
- 「この30年でレベルが後退した」という強い主張にエビデンスが存在しない
- 唯一の具体例が著者自身の「凶器」と呼ぶDBへのJSコード埋め込み
- 主張の一貫性: 不安定
- 「ハードコードはレベルが低い」と断言しながら「やりすぎは危険」と直後に認める矛盾
- 批判と留保が混在し、推奨内容が不明確
- 時代・文脈への配慮: 乏しい
- CI/CD・アジャイル・型システムの進化を無視している
- 「昔は普通だった」を根拠としており、文脈の更新が著しく不足
- 実践的な指針としての有効性: 低い
- 「マスター項目以上・汎用言語未満」という言葉だけでは実務で使えない
- 最重要の判断基準「寸止め」が具体化されていない
- 評価スコア（5点満点）:
- 論拠の具体性: 1.5点
- 主張の一貫性: 2点
- 時代・文脈への配慮: 1点
- 実践的な指針としての有効性: 1.5点
- 合計: 6点 / 20点（平均 1.5点）
- 最大の弱点: 「昔の基幹系SIでは正しかった」という命題と「今も正しい」という命題は別物であり、その橋渡しとなる論証が完全に欠落している
そりゃ昔（今も？）みたいにコードの変更は「まず稟議を上げて部門長の承認を得て、システム部門に申請してシステム部門の承認を得て、そこから開発企業に発注して、先方の対応を待って漸く実装されたら、受入試験を実施して...（略」みたいな状況だったら、そりゃ利用部門で柔軟に変更できるようなDSL的な何かが欲しくもなるだろうけど。
社内に開発チームを常駐させて緊急性・重要性の高い案件から処理していくアジャイル開発のスタイルを採用するなら過度な柔軟性はむしろ生産性を下げるのでドメインロジックはコードで表現するのがやはり最適解だろう。
とはいえ、DSL的な何かで処理やデータを自由に定義できるという方向性自体は間違いでも無いので、そういうのはダッシュボードツールやJupyter Notebook的なものを提供すればよいだろう。