はじめに
https://kichijojipm.connpass.com/event/383313/
吉祥寺.pmが、設計ナイト 2026をやるということで、直前に申し込みをして参加してきた。ソフトウェア/マネジメントでの設計について、Xで有名な人たちが登壇していたので、非常にたくさんの気づきを得た。ということで、メモしたものをまとめていきたいと思う。(間違っていたらリプ求む)
nwiizo「アーキテクチャモダナイゼーションとは何か-技術・事業・組織で大事なこと」
アーキテクチャモダナイゼーションの定義と目的
- アーキテクチャモダナイゼーションは、単なるマイクロサービス化やクラウドネイティブ化、ドメインの切り分けだけを指すものではなく、技術・事業・組織の三要素を同時に見直し続けることが本質。
- 従来は「マイクロサービス化すれば速くなる」「クラウドネイティブ化すれば快適になる」など、手段の名前だけで思考が停止する傾向があった。
- 事業面では「DX推進」「売上20%アップ」など抽象的な目標を戦略と誤認するケースが多く、組織面では「チームノポロジー」「スポティファイモデル」「スクラム導入」など仕組みだけ導入しても現場の実態が伴わないと失敗してしまう。
- 三要素（技術・事業・組織）を継続的に見直し、変化に適応し続けることが目的。
- 技術：マイクロサービスやクラウドネイティブなどの導入は手段であり、目的ではない。自組織の現状や課題に即した技術選定が重要。
- 事業：DXや売上目標などの抽象的なスローガンではなく、顧客やシステムの実態に基づいた戦略が必要。
- 組織：チームノポロジーやスポティファイモデルなどの導入は、現場の人間関係や文化とセットで考えるべき。
技術・事業・組織の三要素の相互作用
- 技術・事業・組織の三要素は不可分の関係性を持ち、三要素の相互作用を意識しない場合、全体最適や本質的な変革が実現しにくいという問題がある。
- 相互作用の重要性
- 三要素を同時に動かすことは理想論ではなく、物理法則に近い必然性があると強調している。
- 一つの要素を動かすことで他の二つも連動して変化するため、構造を先に設計しておくことが重要。
- 三要素を可視化し現状を把握することで、自組織の最適解を導き出すことができる。
- 技術・事業・組織の三要素は、個別に語られるだけではなく、相互作用を意識して全体最適を目指すことが不可欠。
境界設計とバリューストリームマッピング
- 4つの境界を揃える: 「言葉・意味・所有権・物理的分割」の境界を一致させてシステムを分割しないと、無秩序な共有データベースなどが生まれ全体の複雑化を招く。
- 改善の絞り込み: バリューストリームマッピングで業務やプロセスの流れを可視化し、ボトルネック（制約箇所）の改善にのみリソースを集中させる。
ドメイン分類による投資戦略の明確化
- コア領域への投資集中: 事業領域を「コア（差別化の源泉）」「サポート（専門的だが差別化しない）」「ジェネリック（汎用）」に分類し、コアに最大限の設計とリソースを投下する。ジェネリックの過度な内製化は避けること。
- Wardly Mapの活用: 要素はどの進化段階にあるのか、競争によってどこに移動するか、何を変えるべきかをチームの認識を揃える行為になる。
認知負荷を基準とした組織設計（チームトポロジー）
- 内在的負荷：チームが本質的に理解しなければならない業務や技術の複雑さ。
- 課題外財政負荷：業務以外の余計な負担（不要な手続きやコミュニケーション）
- 学習関連負荷：新しい知識やスキルの習得に伴う負担
- 速度や品質の問題は認知負荷設計の不備に起因する場合が多く、適切な認知負荷設計がチームの生産性や成果に直結する。
- 組織の結合度を下げ、チームの認知負荷を最適化することが速度と品質向上の鍵であり、チームトポロジーの分割は担当範囲の認知的把握可能性を基準とし、認知負荷の三種類を考慮して設計すること。
まとめ
- モダナイゼーションは、事業範囲の掘り下げによる診断、小さな変更と学びの反映、継続的な改善習慣の構築という流れで進行し、最終的な成果はアーキテクチャの刷新ではなく、診断と改善の習慣化をしていくこと。
moznion「悪い設計 <やつ> ほどよく残る ー 「なんでこうなっちまうんだ？」を掘り下げる」
悪い設計が残り続ける理由とその影響
- 責務過多は状況次第で許容されることもあるが、大規模システムでは、責務の分散や集約のバランスが崩れると悪い設計が温存されやすい。
- 設計原則を守れば常に良い設計になるとは限らず、状況に応じた柔軟な判断が不可欠。一度原則やベストプラクティスが無視されると、その後も無視され続け、悪い設計が定着しやすい。
- 割れ窓理論のように、最初の小さな設計ミスが放置されることで、全体の品質が低下しやすい。悪い設計は「汚れた聖域」のように連鎖的に広がる。
- 善意による誤った秩序の定着、巨大化による正当化、観測不能による問題の隠蔽も、悪い設計が残り続ける要因。
AI・LLMによる悪い設計の加速と課題
- AIが既存の悪い設計を信頼し、そのまま量産してしまう現象が発生。誤った秩序がAIによって補強される。
- LLMがレビューやコスト計算で手抜きをし、根本的な改善を避ける傾向がある。これにより、悪い設計や行動がコードベース上で増殖する。
- 「AIが言っていたから」と盲目的に受け入れることで、設計の質が低下し、悪い設計がさらに増えていく。
- LLMは一般的に良い設計知識を持つが、コンテキストを正しく理解し、適切な設計原則や手法を選択する必要がある。自動適用には限界があり、何を再現するかは不確実。
ソフトウェア設計における人間の役割と今後の展望
- AIやLLMが進化しても、現時点では人間の設計知識や判断が不可欠です。
- LLMがどんなに進化しても、既存のプラクティス（設計知識や経験則）に基づいた開発が最善策とされている。
- AIは人間の知識を学習し、模倣している段階であり、人間の設計センスや判断力が今も不可欠。
- 現状では人間の責務を果たしつつ、AIと共に歩むことが最適な道です。
まとめ
- 悪い設計を見逃さず、早期に対処する
- 善意による誤った維持を防ぐ
- 地道な改善を続ける覚悟を持つ
- AIの活用と人間の審理眼の両立
soudai1025「制約を設計する – 非決定性との境界線」
非決定性とLLMの抽象化によるソフトウェア開発の変化
- 抽象化レベルの飛躍的な向上: LLMの登場により、ソフトウェア開発における抽象化の次元が大きく引き上げられた。
- 「非決定性」へのパラダイムシフト: 従来の「同じ入力＝同じ出力」という決定的なプログラミングから、人間に近い「毎回異なる出力を返す」非決定的な世界観へと転換した。
- 開発者に求められる新たなアプローチ: 開発者は非決定性と向き合い、適切な「制約」を設計して望ましいアウトプットを導き出す工夫が必要になった。
- ドメインモデル設計の複雑化: この非決定性をシステムに組み込むことで、設計現場に新たな複雑さや課題が生じている。
- 新時代の必須スキル: 「LLMによる抽象化の進化」と「非決定性の理解・活用」が、現代のソフトウェア開発者における新しい役割となっている。
標準化によるアウトプット品質の均一化と境界線設計
- 標準化の目的:マニュアルやルール化によって属人性を排除し、業務の再現性とアウトプットの品質を均一化すること。
- 境界線という考え方
- 毎回結果が変わる「非決定的な世界（人間やLLM）」と、規則通りに動く「決定的な世界（システム）」を繋ぐ境界線を適切に設けることが不可欠。
- エンジニアに求められる役割
この2つの世界の「どこに境界線を引くか」を常に見極め、システムの品質と再現性を両立させる仕組みを設計すること。
ソフトウェアにおける制約設計とガードレールの役割
- 制約はゴールを直接導くものではなく、安全な道筋（ガードレール）を提供するもの。
- 契約的プログラミングや関数ドメインモデリングの考え方と類似し、制約によってシステムの正しさや信頼性を担保する。
- ハーネスエンジニアは、制約設計やガードレールの構築を通じて、システムの決定性と安全性を担保する重要な役割を担う。
- 境界線設計の難しさや変化への対応も、テストコードとオブザーバビリティによって補完される。
変化に対応する設計とドメインの自律性
- ドメインの自律的設計とは、システムが扱う本質的な問題空間を自ら責任を持って設計し、標準や流行は適切に活用するという思想。
- 「どうでもいいことは流行に従い、重大なことは標準に従い、ドメインのことは自ら設計する」
- 制約を活用することで、設計範囲を明確にしつつ、変更や交換が容易な柔軟性を確保できる。
まとめ
- 設計は経験によって身につくものであり、実際に手を動かした数だけ成長できる
- 過去と新しい知識の融合が現代のエンジニアに求められてる。
ナカミチ「感情を設計する」
感情と理性の関係性
- 感情の優位性
- 感情が行動や判断に大きく影響し、理性は感情の「奴隷」であると表現。
- 理性の役割
- 理知を働かせて感情や行動をコントロールすることが重要。
エウダイモニアの哲学的意義
- エウダイモニアは「よく生きる」「最高の善」「幸福」を意味し、人生や組織活動の根本的目的とされる。
- アリストテレス倫理学に基づき、アルテ（卓越性）を発揮し、中庸を守ることが幸福への条件。
組織運営・チームビルディングへの示唆
- 感情と理性の調和**が組織の健全な運営やチームの卓越性に不可欠。
- エウダイモニアの追求は個人の幸福と組織の持続的成長に直結する。
感情の対立と自由の設計
- 感情の対立が組織・チームに与える影響
- 感情の対立は組織やチームの各階層で頻繁に発生し、重大な阻害要因となる。
- 部門間や個人間など様々なレベルで対立が観察される。
対立の価値とリスク
- 感情の対立は自然な現象であり肯定的に捉えるべきだが、不健全な対立は組織の機能を阻害し、破壊リスクもある。
- 感情は理性や正しさだけでは制御できず、行動や意思決定に影響する。
対立の根本原因としての「自由」
- 選択の自由が対立の根本原因であり、選択肢の多さが対立を誘発する構造的要因となる。
- 不要な感情の対立を避ける構造設計が重要であり、感情を否定せず設計の一要素として扱うべき。
チーム内対立の早期対応の重要性
- 個人間の対立や不和は早期対応が不可欠であり、放置すると離職やチーム全体の雰囲気悪化、開発品質低下につながる。
- 経営戦略よりも「このチームが嫌だ」「この人と働きたくない」という理由で離職するケースが多い。
開発プロセス整備による対立解消
- 開発プロセスの整備が対立解消の鍵**であり、合意形成やフィードバックの仕組みが明確になる。
- スクラム導入はワーキングアグリーメントや定期的な振り返りを通じて対立の早期発見と対応を促進。
- 明確な役割分担やコミュニケーションルールがPMI倫理規定に基づく公正な意思決定を可能にする。
合意形成とフィードバックの重要性
- 合意形成とフィードバックの仕組みが対立を減らし、組織の卓越性と持続的成長を実現する。
ワーキングアグリーメントの定義と実践
- チームが自らの働き方や行動規範を話し合い、合意の上で決定するルールや約束事。
- 合意形成によるルール設計が健全なチーム運営につながる。
まとめ
- 感情のコントロールを個人努力だけに依存せず、組織として感情設計を支援する必要がある。
- 会社の為に生きているわけではないのと、個人の幸せを最優先すべき。
- 感情設計が不可欠であり、組織運営やチームビルディングでも個人の幸福追求が中心となるべき。
polidog「「AIがコードを書く時代のジェネレーティブプログラミング」
仕様駆動開発と自然言語モデルの限界
- 仕様をAIに記述し、その仕様を基にコードを生成するアプローチが提案されている。
- 仕様がモデルとなり、コードはその発生物として位置付けられる。
- 自然言語モデルの問題点と限界
- 自然言語で記述された仕様やモデルには曖昧さがあり、解釈の幅が存在する。
- 検証不能性の課題があり、仕様とコードの乖離が発生しても検知できない重大なリスクがある。
ジェネレーティブプログラミングの定義と書籍紹介
- ジェネレーティブプログラミングとは、コードを生成する仕組み自体を設計する考え方。
- 約700ページの書籍で体系的に解説されており、開発者に新たな視点を提供。
DEMRALという3つのフェーズ
- ドメイン分析：境界を明確化し、共通性と可変性を認識
- ドメイン設計：分析情報を基に設計を行う
- ドメイン実装：設計内容を具体的な生成システムとして実装
フィーチャーモデルの役割
- フィーチャーモデルは共通性と可変性を体系的に整理し、生成するコードのバリエーションや構成要素を明確化するモデル。
フィーチャーモデルの意義と構造
- フィーチャーモデルは、ドメインが持つ特徴をツリー構造で表現する手法。
- 仕様の関係性や優先度を明確に整理できる点が強み。
DSLによる仕様選択と記述
- フィーチャーモデルで表現された特徴から、どの機能を選択するかをDSLとして記述。
- DSSを用いて、フィーチャーモデルから選択した仕様をDSLで表現するアプローチが提案されている。
- AI時代においては、DSLの設計や作成がより簡単かつ自由になっている。
ジェネレーティブプログラミングとの関係
- ジェネレーティブプログラミングをAIで自動生成することよりも、モデルの検証を重視。
- フィーチャーモデル/Configuration DSLを活用し、仕様表現の精度と柔軟性を高めることを目指す。
言語ごとの実装制約と柔軟な対応
- コンシピテーションナレッジを活用することで、各言語の制約に柔軟に対応したコード生成が可能。
- PHPの条件をコンシピテーションナレッジとして記述し、実装コード側で反映することで言語ごとの違いを吸収。
DSLと実装コードの役割分担
- DSLは主要な表現手段として用い、実装コードの細かな制約や条件はDSLには記述しない。
- 実装コード側で言語固有の制約を管理し、DSLは抽象的な仕様や構成を表現。
構成知識による安定性向上
- 構成知識を適切に活用することで、より安定したコード生成が実現される。
まとめ
- AIがコードを書く時代の設計手法は、まだ誰も正解を持っていない
- 一緒に試して共有しあえたら嬉しい
hanhan1978 「あるアーキテクチャ決定と、その結果」
- アーキテクチャ決定とは
- アプリケーションやシステムの構造に関わる決定だ
- 優れたアーキテクチャ決定は、開発チームが適切な技術選択を行うための指標となる
- ADR以前の問題点
- ファイル増えすぎしんどい
- 依存関係特定しづらい
- ADR採用後
- 効果のあった決定
- ASRを残すと振り返りができる
- statsも雑に残しておくと良い
- 層を捨て、機能に束ねて、乱れ消ゆ
yu_mi0825「プロダクト粒度設計でも基礎となるコンポーネントの凝集原則」
変更理由によるコンポーネントのまとめ方（CCP原則）
- CCP原則は、「変更の単位」でコンポーネントをまとめる設計指針。
- 単一責任原則のコンポーネント粒度版とも言える。
- 保守性の観点から、作り手側が「一緒に変更されるもの」を1つのコンポーネントとしてまとめることが重要。
- 逆に、変更されないものや変更タイミングが異なるものを同じコンポーネントにまとめるのは避けるべき。
- 境界の妥当性は、実際の運用や変更履歴を活用して検証し、必要に応じてチューニングを行う。
- DD（ドメイン駆動設計）における集約の範囲設計とCCP原則は密接に関係しており、集約の単位を決める際にはCCPを目印に設計を進めることが推奨される。
- 境界設計は継続的な検証とチューニングが重要であり、CCP原則はアーキテクチャ設計やドメイン集約設計の中心的な判断基準となる。
再利用性を重視したコンポーネント分割（CRP・REP原則）
- CRP（再利用理由によるまとめ）およびREP（リリース単位によるまとめ）原則は、コンポーネントの再利用性を高めるための設計指針。
- 使う側の視点が重要であり、利用者が必要なものだけを切り分けて使えるように設計することが推奨される。不要な要素を含めないように分割することがCRP・REP原則の趣旨。
- 過度な細分化は依存関係の複雑化や保守性の低下につながるため、全部使うか、全部使わないか」という明快な単位での分割が推奨される。
- リリース番号は使う単位ごとに付与し、バージョニング戦略を明確にすることが重要。
ビジネスサイドとの共通言語とコミュニケーション手法
- 技術側が作成する図（アーキテクチャ図やコンポーネント図）は、ビジネスサイドには意図が十分に伝わらない場合が多く、単なる図示では共通認識の形成が難しい課題がある。
- Wardley Mappingを共通図として利用することで、利害関係者間のコミュニケーションツールとなり、ビジネスサイドと技術サイドの共通言語を形成できる。
- コンポーネントの進化や時間変化をWardley Mappingで可視化し、設計意図を伝えること、再利用や変更理由の原則選択を明示することが重要。
まとめ
ソフトウェアでの設計とマネジメントでの設計という様々な視点を得られるイベントだった。個人的に感銘を受けたのはナカミチさんのお話で、感情の対立を、個人の我慢や気合いで解決するのではなく、「ルールや仕組み（ワーキングアグリーメント）」を設計して防ぐという考え方は、目に鱗だった。
とても有意義な勉強会だったので、次回もマストで参加する！運営のみなさんお疲れ様でした！
帰りに、mozumasu、soraくん、おがどらくんと麺僧に行ってきたが、シンプルな味と食べやすさにリピート有りだったので、みんなもぜひ行ってほしいお店である。
0件のコメント