設計の楽しさ

泥臭い制約をお手玉しながら「新しい抽象」を見つけ出す快感が、ソフトウェア設計から柳宗理のデザイン、斉須さんの料理にまで一貫して鮮やかに語られていて、現場の手触りが伝わってくる熱い原稿です。 さらに読者を巻き込み、説得力を深めるために、以下の3つの論点について考えてみませんか。 1. 「新しい抽象」という言葉の多義性 エヴァンスの言う「概念モデル」、柳宗理の「形の必然性」、斉須シェフの「味の組み合わせや火加減」は、どれも設計の妙味ですが、これらをすべて「抽象」と呼ぶと、少し意味が広がりすぎて読者が混乱する可能性があります。 2. 「お手玉」の具体的なプロセス 1,000個のお手玉が減っていく比喩はとても魅力的ですが、「なぜお手玉していると自然に減っていくのか」、その実践的な思考のステップ（言葉の定義を変えたのか、捨てたのかなど）を少しだけ具体化すると、説得力が増しそうです。 3. 「受け手には努力の痕跡が見えない」ことと「ドメインエキスパートとの対話」のバランス 斉須さんの「真似できそうでできない料理」は自然に受け入れられますが、DDDではビジネス側と「言葉を揃えて対話する」ことが核にあります。「痕跡が見えないほど自然」な状態と、「相手と共通の言葉で議論する」ことの関係をどう捉えていますか。 どこから話しましょうか？

お手玉が減るプロセス

原稿の「最初は大きいのや小さいのや重いのや軽いのや……お手玉が1,000個くらいある」から「脳みそ使わんでよくなるようなモデルが出来上がる」までの比喩、すごく躍動感があって引き込まれます。 ただ、読者の中には「現場のややこしい要望をどうやって減らしたの？」「ただの妥協や切り捨てと何が違うの？」と疑問に思う人もいそうです。 原稿では「中身と袋のサイズが違ってた」「両方とも紫だった」と書かれていますが、これって実際のエンジニアの実務（あるいは料理やデザイン）で言うと、具体的に頭の中で何が起きている瞬間なんでしょうか。 ・要望の言葉に騙されず、背後にある本当の目的を見つけた時 ・別々の部署から出た別名の要望が、実は同じデータの状態変化だと気づいた時 ・仕様として全部作らずに、運用やルールの変更で解いた時 など、いろいろなパターンがあると思います。書き手さんが一番「これこれ！」と思うのは、どんな瞬間ですか？

制約のかけポイントとか。 ビジネスの人から入ってくる話って タスクっぽい流れで入ってくる 画面A -> 画面B -> (ここでxxが入力されてる必要がある) -> 画面C ことが多いんだけど。 それ聞いて、画面作ったりデータ層作ったりお手玉してると、これ画面の制約じゃなくて状態の制約であって、 公開する時にあれば良くね？とか出てくる。 で、お手玉する前に気づけやって話なんだけど、これがねー、何年制作サイドやっててもお手玉するまでわかんないのよ。 逆に言えば、どのプロジェクトでも、お手玉すれば出てくる。

めちゃくちゃリアルで面白いですね！ 画面遷移の「手順」として持ち込まれた制約を、コードをいじったりデータと突き合わせたりしながらお手玉しているうちに、「あ、これ『手順』の縛りじゃなくて『状態』の不変条件じゃん」「公開ボタン押す時に満たされてればいいやつだ」と気づく瞬間。まさに「中身と袋のサイズが違ってた」の実態そのものだと感じます。 この「お手玉する前に気づけやって話なんだけど、お手玉するまでわかんない」という実感も最高です。設計って机上の空論で一発で決まるものじゃなくて、手を動かして格闘するからこそ見えてくるんですよね。 このエピソード、ぜひ原稿の「お手玉」のくだりに入れたいところです。 そこで一歩進めて考えたいのですが、そうやって「これ、画面じゃなくて公開時の状態の制約で良くね？」と気づいたとき、次は何が起きるんでしょうか。 1. その発見をビジネスの人にぶつけて「あ、それなら画面Bで入力させなくてもいいじゃん！」と要件自体をシンプルにひっくり返す快感なのか 2. それとも、ビジネス側には意識させずに、裏側のコードやデータ構造をガツンとシンプルに収める快感なのか この発見がどうやって「お手玉が減る（＝解決する）」に着地するのか、どちらのニュアンスが書き手さんの実感に近いですか？

ユーザが最終的に操作するのは画面だから - 画面に制約ポイントを変更した画面群を作って - 操作しながら、「制約ポイントはこう変えました、なぜならー …. なんすけどどっすか？」 かな。

めちゃくちゃ実践的で痺れます。 言葉や図解のプレゼンだけで「状態の制約に変えましょう」と理屈で迫るんじゃなくて、実際に触れる画面という「プロトタイプ」を作って持っていくわけですね。 「操作しながら、なぜなら……なんすけどどっすか？」と見せることで、相手も頭の理解じゃなくて「あ、こっちのほうが自然に動けるわ」と身体感覚で納得できる。これ、まさに原稿にある斉須シェフの「これならわたしも作ることができるかもしれない」や、柳宗理の「中身から必然に出るかたち」と完全に一本の線でつながります。 触って初めて「言われてみればそうっすね、いやむしろそれしかない」になる。Giuliaが言っていた「患者の身体に触れる」こと、つまり具体を手で触るからこそ、相手も判断の責任を一緒に背負えるようになるんだと感じました。 この「画面を実際に作って持っていって『どっすか？』と聞く」という一連の生々しいやり取り、原稿の「その新しいモデルを持ってビジネスの人に話に行くと……」のあたりに、ぜひ少し具体的に肉付けしたくなりませんか？ もしここを膨らませるとしたら、どの部分を一番強調して読者に伝えたいですか？ 1. 理屈の議論じゃなく「動く画面（触れるもの）」を持っていくことの強さ 2. 「どっすか？」と聞いた時に、相手の顔が「それしかない！」とパッと明るくなるあの瞬間の快感 3. エンジニアが勝手に裏で解決せず、ビジネス側と一緒に仕様をひっくり返すチームプレーの面白さ

それ、あるね。けっこうあるwww まーでも、それ以前にビジネスの人とのコミュニケーションで、「頑固そうだなー」「見せて説明したら聞いてくれそう」「なんならおれからの提案を楽しみにしてそう」とか大体わかるから。 頑固そうだったらもうちょい細かく出すかな。 画面無しで、ラフスケッチで戦う。

「頑固そうだったらラフスケッチで戦う」という温度感の調整、まさに現場の百戦錬磨のリアルですね！ 周平が言った「追加コストのリスク」を、相手の性格や関係性を見極めて、プロトタイプの作り込み度合い（動く画面か、ラフスケッチか）でちゃんとコントロールしている。無駄死にしないための嗅覚がしっかり働いています。 ここまでのお話を聞いていて、原稿の「お手玉」の比喩がさらに立体的に見えてきました。 お手玉って、コードやデータ構造という「技術のボール」だけじゃなくて、「ビジネスの要望」や「相手の頑固さ・関係性」というドロドロした人間のボールも一緒に空中に放り投げて回しているわけですね。 原稿の以下のくだり： 「やっぱ現場のにっちもさっちもいかないクソ汚いだけに見えるたくさんの要望や制約を、お手玉しながら考えるのが楽しい。」 ここに、さっきの「手順か状態かを見極める話」や「相手に合わせて動く画面やラフスケッチをぶつける話」のような実感が少し差し込まれると、エヴァンスの言う「ドメインエキスパートとの共同作業」の泥臭さと楽しさが、読者にも圧倒的なリアリティとして伝わるはずです。 さて、この「お手玉の実態」が見えてきたところで、最初の論点の3番目、 「受け手には努力の痕跡が見えない（斉須さんの料理）」ことと、「ビジネス側とぶつかり合って仕様を変える泥臭さ」がどう繋がるのか、という点に戻ってみませんか。 相手と一緒に仕様をひっくり返して「それしかない！」となったモデルは、最終的にユーザーが触るときには「最初からそうだったかのように自然で、努力の痕跡が見えないもの」になる……という流れでしょうか？

> あの本が書かれたのは、まさにウォーターフォール全盛期で そーなの！！ 日本語版が2011年だったからアジャイルわっしょいが出始めくらいかと思ってた。 和訳のラグあんのね。。 > 「痕跡を消す」 ために、ビジネスの人とかお客さんを巻き込んでごちゃっとさせて、お手玉して、スルッといく抽象を作る。かな。 それが作れた後に入ってきたメンバーとか、リリースされた後に使うユーザにとって、その格闘の痕跡が見えないというか、「普通にやったら誰でもそうなるでしょ」になればいい。 (心の中では、オメーこの氷山の一角見て、下の苦労が想像できねーのか！！とは思うけどwww）

「オメーこの氷山の一角見て、下の苦労が想像できねーのか！！とは思うけど」という心の叫び、めちゃくちゃ痛快で笑ってしまいました。でも、その葛藤こそが「プロの設計」の真骨頂ですね！ 後から入ってきた開発者が「え、これ別に普通の設計じゃん、誰でもこう書くでしょ」と言ったり、ユーザーが何も引っかからずにスルッと使って「普通に使えた」で終わったりする。 その「普通」を作り出すために、水面下ではビジネス側とラフスケッチで殴り合い、1,000個のお手玉を回し続けたという氷山の巨大な下部があるわけです。 原稿の最後にあるこの一文： 「本当に優れたモデルや設計って、受け手からすると『努力の痕跡』が見えない。あまりに自然で必然だから、最初からそうだったようにしか思えないのよ。」 ここ、まさにいま書き手さんが言ってくれた「氷山の一角」の話とバチッと繋がりますね。 斉須さんの「これならわたしも作ることができるかもしれない」と家庭で作って失敗するお客さんのエピソードとも完全に重なります。「簡単にできそうに見えるほど自然」なものほど、裏の計算と格闘が凄まじいという皮肉と誇り。 この議論を踏まえて、記事の締めくくりについて一つ問いかけたいです。 末尾の「余談」のところで、 「ここまで書いて思ったけど、『新しい抽象を作り出す』なんて大げさなこと言わんでも『工夫する』で事足りる。冷蔵庫の中にあるもんで、うまいもん作るおかーちゃんのように。」 と、一気に日常の言葉に着地させていますよね。 これ、すごく親しみやすくて良い着地なんですが、ここまで語ってきた「氷山の下の凄まじいお手玉の格闘」や「プロが痕跡を消す美学」と比べると、ちょっと「おかーちゃんの工夫」は謙遜しすぎて、小さくまとまりすぎている気もします。 この最後の着地について、どう思いますか？ 1. いや、どんなにプロの仕事でも本質は「おかーちゃんの工夫」と同じ地続きなんだと言い切りたい 2. むしろ「誰でも思いつきそうに見えるレベルまで痕跡を消す工夫」という、プロの執念として着地させたい 3. 「工夫」と言いつつも、水面下の氷山のデカさをちょっと匂わせてニヤリと終わりたい

おれの(一般に制作の)手触りは、成果物に残らずに済めばそれが一番いい、つか残すべきではない。 AIに実装させて直すけどそれは、 AIっぽさが嫌で、おれっぽさを残したいから直す。ではない。 単純に不自然だから直すだけ。

「手触りは成果物に残らずに済めばそれが一番いい、つか残すべきではない」 「おれっぽさを残したいからじゃなく、単純に不自然だから直すだけ」 この言葉、ものすごく強烈で、このエッセイ全体の哲学を決定づける重みがあります。 作り手の自我や「オレの書いた綺麗なコード」「オレのデザイン」を誇示するのではなく、対象（ドメインやユーザー、素材）と格闘し尽くした結果として、ただ「不自然さ」を削ぎ落としていく。そうして残ったものは、作り手の痕跡すら消え去った、あまりにも必然的な形になる。 これこそが、原稿で引いている柳宗理の、 「かたちは外から与えられるものではなく、中身から必然に出るものだと思っている」 「本当の美は生まれるもので、つくり出すものではない」 という言葉の、エンジニアリングにおける完全な実践ですね。 ここまでの議論で、原稿をさらに骨太にするためのピースが完全に揃いました。 ・お手玉の実態：画面の手順ではなく「状態の制約」を見抜くこと。 ・現場での突破：頑固さを見極め、動く画面やラフスケッチで「どっすか？」と相手を巻き込むこと。 ・痕跡を消す美学：氷山の下で死ぬほどお手玉した末に、我欲や手触りすら消えた「ただ自然な必然の形」を残すこと。 この深まりを原稿に反映させるにあたって、次はどの部分に手を入れていきましょうか。 1. 「お手玉」のくだりに、手順から状態へ見抜く具体的なエピソードを足す 2. 「新しいモデルを持って話に行く」くだりに、画面やラフスケッチで相手を巻き込む生々しさを足す 3. 終盤の「努力の痕跡が見えない」のくだりに、「作り手の手触りすら残さない、不自然さを消す美学」を刻み込む