増田 亨

◆アプリケーション開発者:ドメイン駆動設計,Java,Spring
◆著書『現場で役立つシステム設計の原則 ～変更を楽で安全にするオブジェクト指向の実践技法』

[増田 亨 @masuda220]

拙著「現場で役立つシステム設計の原則」が重版されました。毎日すこしずつですが売れ続けているらしい。ありがたいことです。
オブジェクト指向プログラミングやドメイン駆動設計の入門書的に使っていただけてるようです。
読書会とかお声がけいただければおじゃましたい。
https://t.co/4cVXS8pycK

[JJUG @JJUG]

🎤 JJUG CCC 2026 Fall LTスピーカー募集！

11/28(土)の交流会で、3分間のLTに登壇しませんか？

Java・エンジニアリング・コミュニティに関するお話をお待ちしています⚡

🔗 LT大会お申し込みはこちら
https://t.co/qNAwwe5qNf

🔗イベントの参加登録はこちら
https://t.co/sAjfGXYf7f
#jjug_ccc

[Fado @fado_dev]

先日の要件定義の話、もう少しちゃんと書きます。

直近、要件定義でつまずいてプロジェクトがひっ迫するケースをみて、いろいろと原因をたどったんだけど、だいたい同じところに行き着く。

「ベンダー側が『言われたものを作る』姿勢で要件定義」

これ、一見まじめで誠実に見えるのがタチ悪い。お客様の要望を丁寧に聞いて、漏れなく一覧にして、合意を取る。やってることは正しそうなのに、確実に失敗する。

なぜか。

お客様が言ってるのは「要件」じゃなくて「要望」だから。

要望は、今の業務の延長で思いついた解決策。「この画面にこのボタンがほしい」「このExcelをそのままシステムにしたい」でも本当に解きたいのはその奥にある業務の課題で、そこはお客様自身も言語化できてないことが多い。

言われたものを作るスタンスだと何が起きるか。

要望をそのまま積む
↓
優先順位がつけられない(全部「言われたこと」だから)
↓
スコープが膨らむ
↓
要望同士の矛盾に後で気づく
↓
「言ったのに入ってない」
「聞いてない」
が始まる
↓
ひっ迫

削る根拠を持ってないわけ。

「それは要りません」と言えるのは、業務を理解してる人だけなので。

だから、相手よりもそのビジネスを理解する気概がいる。

具体的には
・その会社がどこで儲けてるか
・この業務で誰が何に困ってるか
・例外処理が現場でどう回ってるか
・システムが入ったあと、数字の何が変わるべきか

ここまで押さえて初めて「その機能より、こっちを先にやるべきです」が言える。要件定義って聞き取りじゃなくて提案なんですよ。

「私ならベストなシステムを作れる」と言えるところまで武装する。これは傲慢じゃなくて、責任を取りにいく姿勢だと思ってる。言われた通りに作りました、は責任を相手に返してるだけ。

AIで実装が速くなった今、ここの差はむしろ広がってる。作るコストが下がった分、「何を作るか」を間違えたときのダメージが相対的にデカい。間違った要件を爆速で実装しても、爆速で負債が積み上がるだけ。

で、最後。金額が見合わなければ断れ。

ここまでやるには工数がかかる。業務を理解する時間、現場に聞く時間、提案を練る時間。そこに予算がつかない案件は、結局「言われたものを作る」しかできなくなる。つまり失敗する構造に最初から入ってる。

安く受けて、要件定義を薄くして、後工程で燃える。誰も得しない。お客様も、担当も、会社も。

断るのは逃げじゃなくて、成功させられる案件だけを受けるという品質保証だと思ってます。

要件定義は「聞く仕事」じゃなくて「決めにいく仕事」

苦戦してる人は「聞き方」より先に、相手のビジネスをどこまで知ってるかを疑ってみてほしい。

[Findy Tools ファインディ【公式】 @findy_tools]

「ドメイン駆動設計をはじめよう」著者来日登壇決定！
アーキテクチャの「いま」に出会う2日間
※同氏の基調講演は会場限定

📍ベルサール羽田空港/オンライン
📅11月26日（木）・27日（金）9:25~18:55
🎫参加無料（一部有料チケットあり）

[増田 亨 @masuda220]

@papanda 取り組むとしたら、6章の、ステップバイステップとリシェイピングの組み合わせを、焦点を絞って、ボトムアップで始める感じかな、と思っています。ゲリラ的とは言いませんが、かなり現場主導で小さく少しずつ進める。
時間はかかると思いますが、大掛かりに取り組むより成功確率は高いかと。

[SHIRAI DESIGN @urayamashirai]

関東では晴天が続き冷え込んできて、旅心が刺激されます。
No.415バッグにスケッチブックを忍ばせるスケッチハイキングがおすすめです。

[増田 亨 @masuda220]

まずは「やってみようとする」こと。そして続けること。
やってみることで、自分たちに何が足りていないか、どのくらい足りていないか、どうすればできるようになるかが、つかめるようになってくる。そこがつかめれば、行動計画も見えてくる。

[増田 亨 @masuda220]

来週、某イベントで、なぜ変更容易性を改善できないか、どうすれば改善できるのか、について話す予定。
改善できない/しない理由
- 変更容易性を改善する効果の過小評価
- 変更容易性を改善する知識、経験、スキルの不足
- 変更容易性を改善するための時間を取れない

では、どうすれば改善できるか？

[増田 亨 @masuda220]

協働モデリングをうまくやることで、持続可能な設計判断ができるようになる。そのための実践ノウハウ。
モデリングや設計で生まれがちな意見の相違や感情的な対立を可視化しながら、適切に合意形成していくための考え方とやり方。そういう本です。
『協働ソフトウェア設計』
https://t.co/JcTN6uwJRw

[増田 亨 @masuda220]

ソフトウェア設計の歴史は、グローバル変数との戦いの歴史かもしれない。プログラムのどこからでも書き換えと参照が可能なグローバル変数を避けるために、引数で値を渡すようにし、データとロジックをクラスにカプセル化し、可能な限り可変状態を依存しないようにする方法が強く推奨されてきた。
しかし、実際には、50年以上前から続くグローバル変数を撲滅するための戦いのほとんどは、ポインタ渡し、publicなgetter/setter、データベースという名の巨大なグローバル変数など、グローバル変数を愛好するものたちがひねりだす技術に打ち負かされたきた。

[増田 亨 @masuda220]

じゃあどうすればよいか？
大きな泥団子を生まないために、目的に合った抽象的なデータ型(クラス)を設計し、アクセス可能範囲を制限し、可変な状態への依存を減らし、変数やメソッドの名前で意図を表現し、引数を減らし、メソッドを短く保ち、コードの重複をなくし、制御フローを整理して単純にする

[増田 亨 @masuda220]

生成AIは、大きな泥団子を作ることを自動的に防げる技術ではない。
むしろ大きな泥団子を効率的(？)に、生み出すことができる技術である。
使い方しだいではあるが、大きな泥団子を作り続けてきたソフトウェア開発の現場で、生成AIが大きな泥団子の高速生成技術として重宝(？)されるのは必然かも。

[増田 亨 @masuda220]

生成AIは、大きな泥団子を作ることを自動的に防げる技術ではない。
むしろ大きな泥団子を効率的(？)に、生み出すことができる技術である。
使い方しだいではあるが、大きな泥団子を作り続けてきたソフトウェア開発の現場で、生成AIが大きな泥団子の高速生成技術として重宝(？)されるのは必然かも。

[増田 亨 @masuda220]

顧客が自社の製品を選ぶ理由を磨く。顧客の視点で、他社とは違う魅力を生み出すことに注力する。
そういう自社独自の魅力を持続的に生み出すために、自社のさまざまな活動を、そこに向かって統合し調整する。

[sakata @mariosakata]

競争が激しくなると、つい価格で差別化したくなる。でも、他社に追随して安さを追うより、自社の強みを磨く方が支持につながることもある。

バーガーキングの戦略は、プロダクトづくりにも通じる話だと思う。ちなみに私はマックよりもバーガーキング派🍔
https://t.co/a3szGDbydp

[sakata @mariosakata]

競争が激しくなると、つい価格で差別化したくなる。でも、他社に追随して安さを追うより、自社の強みを磨く方が支持につながることもある。

バーガーキングの戦略は、プロダクトづくりにも通じる話だと思う。ちなみに私はマックよりもバーガーキング派🍔
https://t.co/a3szGDbydp

[増田 亨 @masuda220]

@dentomo これからも変わらないだろうと、わりと確信している基礎や基本と、今後どうならうかわからないな、と感じている部分はありますね。

[増田 亨 @masuda220]

先日のイベントで、2017年出版の拙著『現場で役立つシステム設計の原則』について、だいぶ古くなりましたね、と言われてちょっとびっくりした。むしろ、値オブジェクトやイベントソーシングなど、現代的な内容を先取りしていて、今でも現場でかなり役立つ内容だと思っていたので意表を突かれた。

[増田 亨 @masuda220]

10年前に『現場で役立つシステム設計の原則』を書いた時は、正直、エヴァンスの『ドメイン駆動設計』（という言葉）はそのうち下火になるだろうと思って、あまり正面から取り上げなかったのだけど、現在でも重要な考え方として大きな影響を与え続けているのは想定外だった。

[増田 亨 @masuda220]

先日のイベントで、2017年出版の拙著『現場で役立つシステム設計の原則』について、だいぶ古くなりましたね、と言われてちょっとびっくりした。むしろ、値オブジェクトやイベントソーシングなど、現代的な内容を先取りしていて、今でも現場でかなり役立つ内容だと思っていたので意表を突かれた。

[増田 亨 @masuda220]

『現場で役立つシステム設計の原則』は、そのくらい先進的な内容だったのですよｗ

[増田 亨 @masuda220]

データ管理も基本はコト（イベント）の記録重視だったので、現在のデータエンジニアリングの勃興で、ようやく歩調がそろってきたｗ
そういや去年だたケントベックのTidy Firstでも、10年前の拙著の内容がいろいろ取り上げられていた。