さいきょうのアーキテクチャを 生み出す センスメイキング おだかとしゆき as JGEEM（@EM4326168385309） 2025.1.31 吉祥寺.pm

自己紹介 おだかとしゆき as JGEEM（@EM4326168385309） 事業(J)会社(G)の元(Ex)EM / 52才 現職はアーキテクチャと格闘 定年までできることしたいことを探る日々 / 定年後もキャリアは続く AIIT 科目等履修生 貢献てなんだろう see also scrapbox，speakerdeck 2

組織を腹落ちさせるセンスメイキング センスメイキング？ ● 複雑な状況を理解し （腹落ち感を得るための） 納得感を得るための認知的プロセス で、アーキテクチャと何の関係が？？ 3

ハードな現状を調伏するため 4 自動テストが ない サポートは 切れてからが勝負 共有DBによる 共有結合 品質とは 外部品質のこと

そもそもどうしてそうなった ● やりたいことに対して正社員が足りない ● 業務知識は正社員に集まりがちなので 必然的に上流工程にシニアな正社員が集中 する ● 設計・実装するのは若手・委託先・派遣社員のみなさま ○ 意識やスキルにバラつき がある ● レビューはE2E観点が中心 （そして内部品質が犠牲に 捧げられる） 5 https://codezine.jp/article/detail/12245

さいきょうへの道は情報社会学にあり？ は？情報社会学って何よ？？ ● 情報社会学とは、 情報技術が社会や人間関係に与える影響 を研究する学問です ● レガシーシステム再構築は単なる技術課題ではなく、 組織、人、文化が複雑に絡み合う超複雑系な社会現象 です ● だからこそ、情報社会学の知見が さいきょうのアーキテクチャへの道しるべ となるのです 6

情報社会学の理論と適用【理論】 7 探索と活用 既存の知識を活用しつつ、新たな知識を探索するバランスが重要 CSV (共通価値の創造) 社会的価値と経済的価値の両立を目指し、持続可能な成長を実現する センスメイキング 複雑な状況を解釈し、組織全体で共通認識を醸成する オープンイノベーション 組織の境界を越え、外部の知識や技術を活用する 紐帯（ちゅうたい） 組織内の繋がりを強化し、情報と知識の流通を促進する プラットフォーム 関係者が相互作用し、価値を共創する基盤を構築する 創発 多様な要素の相互作用から、予測不能な新しい価値を生み出す

情報社会学の理論と適用【適用】 8 探索と活用 ビジネス価値を実現するアプリケーションアーキテクチャを探索し、ビジネス要求に応える（活用する） CSV (共通価値の創造) エンジニア個々の知識獲得やスキルアップも価値と設定して、ビジネス価値と併せて持続的な成長を図る センスメイキング なぜやるか、なにをやるか、どうやるか、様々な疑問や不安を払拭すべく信頼するリーダーからメンバに落とし込む。また組織と してのコミットも必要 オープンイノベーション 社外の有識者を招いて組織にない知識・技能をインストールする、あるいは社内の知見をコミュニティで披露し、新たな気付きを 得る 紐帯（ちゅうたい） チーム間の知識・技術格差を埋めるため、より密なコミュニケーションが行われるよう横串プロジェクトやワークショップなどを企 画する プラットフォーム 「保守性の向上」という価値を創発するための、ハレーション調整やオープンイノベーションの場を設定する 創発 プラットフォーム上で社内外のさまざまな知識が交差し、新しい価値を生み出す

まず何から始めます？ ここにいる方々は すでに「創発」に向けて一歩踏み出されてますね。 ではその動きを組織・業界に反映するには？ より大きな波を創り出すには？ 9 https://www.yutaka2much.com/archives/1325

ここからは おまけ (むしろ本題？あと 1分30秒!?)

センスメイキングされた組織が目指す 「さいきょうのアーキテクチャ」とは ● センスメイキングによって エンジニア本来の責務に目覚めればやるべきことは自明 ● それはビジネス価値を創り出す業務プロセス が より柔軟に価値を創出し続けられるよう 変更容易性を高めること ● では変更容易性は どんなアーキテクチャに宿るのか？ 11 https://www.oreilly.co.jp/ books/9784814400737/

こういうことか？ ● 基幹システム(SoR) を SoA と SoM に捉えなおす ○ SoA とは 現場のプロセス ○ SoM とは 制御と管理のプロセス ● 現場のプロセスを「手順書通りに作業する」と固定すれば、 その手順を変えるだけで様々な業務に対応できる !? ○ つまり手順書の interface を定義し、各種手順書が implements する ○ 現場のプロセスは引数に手順書 interface を取り、 その手順( )を実行することでさまざまな業務の 追加変更にも柔軟に対応できる！勝ったか !!?? 12 https://gihyo.jp/book/2024/9 78-4-297-14010-6

こういうことか！ 13 ● 手順書 as ドメイン知識 ○ 手順には対象の処理手段 (サービ ス)と、台帳への記録方法 (モデル) が含まれる ● 現場 as アプリケーション ○ 手順書を使って業務を行い、 台帳に記録する ● ユースケースに応じた手順が現場に渡さ れる→業務が行われる→結果が台帳に 記録される→イベントが発火する ポリ シー コマ ンド 集約 イベ ント ドメインサービス アプリケーション アダプタ(インフラ) アダプタ (UI) アダプタ (テスト) ドメイン モデル

14 ほらこんな感じ、、って、ん？？？ class 受注 { private 受注手順 o受注手順; // インターフェースのインスタンスを保持 public 受注(受注手順 o受注手順) { this.o受注手順 = o受注手順; // コンストラクタで手順を注入 } public void 明細処理(受注明細 o受注明細) { o受注手順.手順実施(o受注明細); // 実際の処理を手順に委譲 } }

15 https://ja.wikipedia.org/wiki/Strategy_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3 それ、、ストラテジーパターン だね、、

16 というわけで 「ぼくのかんがえたさいきょうのアーキテクチャ」 は ● インタフェースによる開放閉鎖原則の実現 ● つまりストラテジーパターンの適用 でした！ 併せて、ビジネス価値の源泉である エンジニアの 成長を創出価値 としたプラットフォーム の さいきょうのアーキテクチャも考えてみたいな、、と妄想中です

ありがとうございました 17