増田 亨

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

アムダール博士と池田専務の名前が出てきたのは驚いたなあ。 楽しい飲み会だった。

@irof 純粋リファクタリングというのはないのかも コードが変更すれば、コード全体の状態は変わるので、外部から見える振る舞いを固定しても、状態はいつまでも静止しないのかも

@masuda220 リファクタリングは可逆なものなので最終的にはそうなりそうな気はしてるんですが、なかなかループにならないんですよねぇ……たぶんリファクタリングと言いつつリファクタリングじゃないことをやっちゃってるんだろなーと思ってるんですが。

将棋の千日手みたいに、ある段階か同じリファタリングを繰り返す無限ループになりそう。 メソッドの抽出とメソッドのインライン化の無限ループとか

irofさんは良いことをいう

「どうせこうなるだろな」と予測するのもある種のスキルで、それに対して「本当にそうか？」と疑問を抱くのもある種のスキルで、実際に確かめてみるのもある種のスキルで、その確かめ方を評価しようって考えられるのもある種のスキルで……

AI生成コードの品質保証というのは今後のエンジニアリングの一大テーマだな。単なるテストの技法を超えて運用中における監視と改善のサイクルまで射程に入れて考えるべきなのだろう。

周囲にその辺のエキスパートとか知識持ってる人がいればラッキーくらいの感じであまり期待せずに自分がエキスパートになるんだ！みたいな心持ちで知識やらを身につけていくしかないかなと思っている RT

アジャイルソフトウェア開発宣言の "Individuals and interactions"の日本語訳が「個人と対話」になっているけど、意図としては「人と人との相互作用」あたりのほうがしっくりくるかなあ。 Individualsという複数形のニュアンスを「人と人」で表現したい感じ。Interactionsも、対話よりももう少しお互いに影響し合う感じをだしたい。

ポジショントークなので、ポジションを明らかにするところから

スライドをつくりはじめた。 実践的で具体的な話しをしたいのだが、前置きというか背景というか概念的は話が膨らみ始めて、なかなか具体論にならない さてどうするか #jjug_ccc

ZOZOはJJUG CCC 2026 Springに協賛しています！ 当日のブースではみなさまへのアンケート・オリジナルノベルティをご用意してお待ちしています！ 詳細は以下の記事をご覧ください↓ technote.zozo.com/n/na8b9756ff26e #jjug_ccc #zozo_engineer

📢JJUG CCC 2026 Spring セッション紹介📢 「ふつうのFeature Flag実践入門（13:15〜 Room AB）」irofさん 5/30(土)西新宿にて開催！🌿 🗓️タイムテーブル: x.gd/ECNpV 🎟️参加登録：x.gd/WL6eb #jjug_ccc

「どこかに正しい答え」がある、とか、「誰かが答えを知っている」、というメンタルモデルだと、こういうことが起きがち。 ドメインを理解し、モデリングと設計に取り組む活動は、さまざまな知識と技能を持ち寄って、課題の解決策を模索し創発する活動。

ドメインの経験がない人がLLMを使っても情報の正誤を判断できないよね、という内容の記事 architecture-weekly.com/p/dont-overest… ・ドメイン駆動設計（DDD）においてドメインエキスパートの話を過信するミスを犯しがちだが、LLMを用いたドメインリサーチも同様の落とし穴がある ・ホスピタリティマネジメントに関する知識をLLMで調査したところ、重要度の区別なく詳細な情報が大量に出力され、肝心のチェックアウトプロセスがノイズに埋もれてしまった ・これはドメインエキスパートとの初期の対話に似ており、専門家も自分が重要だと思うことや業界用語を一方的に話しがちである ・LLMは学習データの偏りによって特定の製品の用語を優先し、異なるシステムの仕組みを混ぜ合わせながら自信満々に回答する ・ドメインエキスパートも同様に、解決すべき問題そのものではなく自分たちの経験に基づいた主観的な解決策を提示することが多い ・こうした情報をそのままソフトウェア設計に反映させるだけでは不十分である ・DDDで重視されるユビキタス言語は認知負荷を下げるための道具であり、絶対的な真実ではない ・エンジニアの役割はドメインエキスパートになることではなく、矛盾を整理してビジネスに役立つソフトウェアを構築することである ・専門用語や略語を避け、批判的かつ好奇心を持ってビジネス側と対話する姿勢が重要になる ・LLMは統計的な機械に過ぎず、最終的にはユーザーの意見に同調して人工的な現実を作り出してしまう ・LLMがリサーチに最適だと主張する人は、自分自身の分析スキルをLLMの能力だと投影している可能性がある ・ドメインの経験がない人がLLMを使うと情報の正誤を判断できず、競合をただ模倣するだけの価値の低い設計に陥る ・LLMは情報をまとめるのには便利だが、論理的な一貫性に欠け情報の出所も不透明である ・モデリングを任せてもありふれた表現や不適切な設計慣行が混ざり、コンテキストが失われた質の低い結果になりがちである ・C4モデルやイベントストーミングなどの手法を適用させようとしても、ルールを無視した断片的なモデルしか作成できない ・LLMは未知の用語を知るための手がかりや、定型的なドキュメント整理の道具として活用すべきであり、思考そのものをアウトソースしてはいけない ・対人コミュニケーションを避けるためにLLMを使うのではなく、人間同士が協力して独自の価値（スペシャルソース）を見つけ出す必要がある ・モデリングや設計のスキルを磨き、現実世界からのフィードバックを得るというエンジニアとしての本質的な仕事は代替できない

4桁までもう一息

参加申し込み者700名超えました！ありがとうございます！ JJUG CCC 2026 Spring（現地開催のみ） jjug.doorkeeper.jp/events/196011 #jjug #jjug_ccc @JJUGより

@shields_pikes セキュリティホールの発見は確かに将棋ゲームの勝ち負け判定に似ているかも知れませんね

@masuda220 少なくとも、セキュリティホールの発見においては、もはや人間はAIに勝てなくなってますよね。 つまり、最高性能のAIを使った攻撃を防ぐためには、人間のエンジニアよりも最高性能のAIに書かせた方が優れてる、ということでは。

なんでこんな単純に考えられるのか不思議。 将棋の勝ち負けというとても単純な解決空間の話と、何が優れているかを定義できないソフトウェア開発という取り組みを同一視できる不思議さ。

ソフトウェア開発は、開始の状態が、具体的には何も決まっていないことが多い。 問題空間が無定義というか

限定合理性を基本制約として受け入れ、重要なところを選択して、そこに集中する。 さまざまな知識と技能を持ち寄って、共通の目的を目指して、人と人との相互作用を通じて解決策の協働創発に取り組む。