イベントの概要
2026年の設計の現在地を確認する会、それが「設計ナイト2026」です！
今年も昨年に引き続き、吉祥寺の武蔵野公会堂ホールでの開催、もはやカンファレンス、フェス！
イベント参加の背景
- エンジニアとして設計が一番楽しいかも知れない。
- AIが開発プロセスに入り込んできて改めて設計を捉え直したいと思っている。
- 今回待ちに待った初参加！！
貴重な学びを頂いたセッション
アーキテクチャモダナイゼーションとは何か-技術・事業・組織で大事なこと by nwiizoさん
メモ
技術、事業、組織を個別扱うものはあるが、一緒に話されることは少ない。
1つを動かした結果、2つがついてくる物理法則がある。
アーキテクチャ・モダナイゼーション。
レガシー・システムが悪いわけではない。敬意を払うべき。
技術のよくある語られ方：
手段を出すと効果が先に来る。（例：クリーンアーキテクチャだと速くなる など）
Not For Me、自社の現状を知ることが重要。
判断基準がなければ同調圧力だけが残る。
組織のよくある語られ方：
仕組みだけ適用し、人と人の関係が後回しにされる。
アーキテクチャモダナイゼーションは、3つ合わせてものごとを前に進める。
ゴールは3つを同時に見直し続けること。
なぜ同時なのか？それぞれが不可分。技術は事業、組織に影響を受ける。
それぞれバラバラに語られるから、オーバーテクノロジーになる。
マイクロサービスの書籍。
著者はバズワードになってしまったと言っていた。
本質は異なるドメインに関する機能が疎結合にデプロイできるかが本質だったはず。
同じ言葉が違う意味を持つ場所に境界でシステムを作る。
境界づけられたコンテキスト。
境界には4つの種類がある。言葉、整合性、所有権、物理的（デプロイの単位）。
ボトルネック以外の改善は幻想。バリューストリームマッピングで確認する。
すべてのドメインに等しく投資してはならない。DDDの4象限で判断する。
Wardley Mapを利用して同投資すべきかを判断する。
作れるからと言って作らない。内製の誘惑を避ける。経済合理性の判断が欠く。
境界とチームがうまくいかないと、認知負荷がボトルネックになる。
チームの頭に入るかでチームを分割する。
3つの軸が交差する場所。
境界設計の失敗は3つの悪影響を及ぼす。
モダナイゼーションは診断から始める。事業の範囲で決める。
モダナイゼーションの成果物は診断そのもの。
学び
ふわっと意識していることの言語化がすごい。
技術、事業、組織、それぞれ大事と思いつつ、ちゃんと軸足を置いて考えることができていませんでした。
そのうえで、これは誰が考えるべきなんだろうと思うと、誰かひとりが考えるのではなく、チームで考えるべきと気づきました。
AI時代だからこそモブプロ、モブワークで誰かひとりの判断に依存せず、進めていくことが大事なのかも知れない。
積んでるアーキテクチャ・モダナイゼーションを今すぐ読みたくなりました。
悪い設計 <やつ> ほどよく残る ー 「なんでこうなっちまうんだ？」を掘り下げる by moznionさん
メモ
良い設計、悪い設計は場合による。責務過多の良し悪しも場合による。
良いと言われている設計手法や原則はある。
これらの手法・原則を適用しても満足する良い設計になるわけではない。
基本的には守った方が良いもの程度。
一度、ベストプラクティスが破られると、破られ続けていく。
良くないのは観測できなくなる。汚れた聖域状態となる。
汚れた聖域はどんどん汚れを吸引していく。
善意の割れ窓もある。悪い設計を良いものとして扱ってしまうこともある。
かつ、直すべき対象とならない。
巨大な聖域は正しくなさを正当化する。巨大になったらおしまい。
汚れた聖域をAIが加速させる。汚れた聖域を作らせないことが重要。
人間側のソフトウェア設計に対する審美眼は今も重要。
良い設計を壊すのは簡単だが、悪い設計を直すのは大変。
学び
最近、割れ窓は人と人のコミュニケーションにも表れるような気がしています。
健全な魂は健全な身体に宿るし、健全なコードは健全な組織に宿る。
そして、健全な組織は健全な事業と共にある。
そのうえで、AIは増幅器でしかない。
「善意の割れ窓」は記憶にあります。それは審美眼が無かった気がします。
それを判断できる状態を作りたい。
制約を設計する - 非決定性との境界線 by soudai1025さん
メモ
LLMは抽象化のレベルを上げた。
非決定性とうまく付き合う方法を見つけなければならない。
制約を活用して決定していく。
LLMは非決定性との境界を作っている。LLMのアウトプットは不定である。
精度や品質は上がるが、求めている答えが返ってくるかは分からない。
それは人間と一緒。経験を積むと同じアウトプットを出すわけではない。
人間に対するアウトプットを固定にする仕組みは、LLMにも適用できる。
スループット（処理）を標準化する。例：ルール、チェックリスト、暗黙知の形式化
どこかで境界線を作ることが重要。
もともとソフトウェアはハードウェアのために、非決定的な現実世界を仕様として決定している。
制約が決定性を作る。ソフトウェアの世界の制約が境界線を作る。
アーキテクチャ、契約プログラミング、など。
制約以外のアプローチ。AIの方法性を整える。
AIが明後日な方向に行かないように制約の壁をつくる。
それをなんとかする答えのひとつがハーネスエンジニアリング。
他にも、例えば、テストコード。オブザーバビリティ。
アウトプットの品質指標がコードの方向性を決める。
ふわっとした要求を仕様として決定してきた。
人間とAIの非決定性をソフトウェアにしていく。
仕事が変わっても抽象度を高めれば一緒。変化できる設計が重要。
ドメインは自分で決定する。
学び
人間に対しても同じように、AIに対してもコマンド型ではなく、柔軟に動けるようにガードレールを設けた依頼ができるイメージを持てました。
完全に委譲できる部分と、人間が判断して変化させることができる設計が重要。
感情を設計する by ナカミチさん
メモ
理性は感情の奴隷である。良く生きることが大事。
良く生きるためには、卓越性が大事。
アリストテレスは、魂は感情、能力、性向からできているといった。
人間は性向が中庸であることが重要と言われた。
感情の設計。
ソフトウェア開発は激変したが、価値は変わらない。
別に人間が幸せになったわけではない。
感情の対立が多大な影響を与えている。
選択の自由があることで、対立が生まれる。
何を設計するのか？
組織構造、目標、責任範囲、意志決定フロー、コミュニケーションルール
どう設計するのか？
階層を観察して、不足に気付く。部門間の衝突、技術戦略、個人間など。
経営、プロジェクトマネジメント、チーム運用、いずれも悪かったりする。
チーム内の話。
個人間の衝突にははやく対処すべき。
チームや仕事でうまくいかず人は辞めていく。
チームの対立問題は開発のプロセスの整備が効く。
キモ：タスクにチームで向き合うチームで合意する、フィードバック、チームでプロセスを決める
開発がうまくいっていると感情の対立は減る。
ワーキングアグリーメントをチームで合意する。適切に自由を奪う。
プロセスだけでなく、振る舞いの啓蒙も日々の活動で行う。
感情のコントロールを個人の努力任せにしない。
感情が乱れないための設計を行う。
プロジェクトマネージャーとしてチームのサポートに入る場合。
ゆっくりチームに入って、チームで言語化してもらう。
学び
チームの状態が、よい感じのチーム、よくない感じのチームとあった場合、設計によってよりよい状態に寄せていくことができるイメージができました。
改めて、それがマネジメントの役割という意識ができました。
偶然に任せるのではなく、よりよい状態に寄せていきたい。そのために何が設計できるのか。
AIがコードを書く時代のジェネレーティブプログラミング by polidogさん
メモ
DDDでは動くコードがモデルだった。
コードがモデルであることには限界がある。
AIがコードを書く時代でも人の頭のなかにはモデルがある。
問題はそれが外に出ていないこと。
その手段として、SDD。
ただ、自然言語には解釈の幅がある。モデルと呼ぶには曖昧すぎる。
そこで、ジェネレーティブプログラミング。
コードを生成する仕組みを設計する。
DEMRAL：ドメイン分析・設計・実装というフェーズから成る
モデルを検証可能にすることが重要
フィーチャーモデル：
ドメインが持つフィーチャー（機能的特徴）をツリーで表現
仕様の関係性を図で表現
DSL：
フィーチャーの選択を宣言的に記述。
AI時代の設計書はまだまだこれから決まっていく。
動くコードから構造化された仕様に。
学び
自分はSDDで開発をしていくなかで、あくまでAIは人間ができることを倍速でやってくれるだけのイメージを持ってました。
AIが作成するrequirementsはウォーターフォールで作成される設計書とそこまで大差ないと思っていました。
初見の人間が読むにはコンテキスト薄く、作り方は分かっても何のための機能かは分からないドキュメントと理解していました。
なので化石化しやすく、いかにそこから上位のドキュメントを作っていくかが重要と思っていました。
ただ、それはあくまでAIを人間の延長線として捉えていたのかも知れないと気がつきました。
AIのための設計書をちゃんとキャッチアップしていきたい。
LTセッション
LT1 「あるアーキテクチャ決定と、その結果（仮）」 by hanhan1978さん
メモ
2023年7月に受けたADR。
既存Package By Layer。マイクロサービスへの変更を求められたが断った。
Package By Featureを採用し、各チームの担当機能に対応する形で境界を整理した。ADR採択後：効果はあった。ADRあると振り返りできる。statsは雑でも残す。
学び
昨年の開発生産性カンファレンスで取り上げられていて気になっていた話でした。
改めて意図をもとに設計することの重要性を学びました。
apps配下からmodules配下に放流していくという表現が分かりやすかったです。
LT2 「崩壊したレガシーOSとアンチフラジャイルな再構築」 by yu_mi0825さん
メモ
プロダクト、サービスの設計の基礎となるコンポーネントの凝集原則について。
どこでシステムの境界を設けるかなどを考えるときにコンポーネント原則がそこまで語られていない。
どう纏めるかの3点を扱う。
・CCP：閉鎖性共通の原則
変更頻度の単位。単一責務。作り手側の保守性の都合。
・CRP：全再利用の原則
全部使うか／使わないか。使い手側の再利用性の都合。
・REP：再利用・リリース等価
まずはCCPに全振りをする。
ウォードリーマップで右側を目指していく。
学び
コンポーネント凝集原則、ウォードリーマップはじめての知識でした。
知識は物事を整理するうえで重要。
感想
改めて設計の多様性を学びました。
自分は長年エンジニアをやってきたせいか、「設計」というとソフトウェア、アプリケーションの設計を意識してしまいます。
ただ、何のために、誰が何をどうやって設計するのかを考えると、設計はエンジニアのためだけのものではないことに気がつきます。
加えて、設計はものが出来上がったらおしまいではなく、常に変動していく要素を反映して実施することが重要であると改めて意識することができました。
そして、その設計の判断を都度ふりかえることが重要と理解できました。
とても濃厚な設計の学びをありがとうございました。
作る部分をAIが代替するからこそ設計を意識していきたいと思いました。
楽しかったです！！
