アーキテクチャConference 2025 DAY2 に参加しました。
2年連続の参加。今年も多くの刺激と学びを頂きました。
イベントやセッションから得た学びをまとめます。
- イベントの概要
- イベント参加の背景
- 参加したセッション
- ブース
- 懇親会
- まとめ
イベントの概要
技術の変化が加速し組織やツールが多様化する今、最適なアーキテクチャをどう描くか。
アーキテクチャは、プロダクトの特性やチームのあり方によって最適解が異なり、普遍的な正解は存在しません。 トレンドを追うだけでは不十分で、設計に込めた意図を自らの文脈で捉えて継続的に見直していくことが求められます。
本カンファレンスでは、アーキテクチャの構想・判断・構築にまつわるリアルな知見を共有し、多角的な視点から設計判断への理解を深めます。自社にとって最適な構成を考えるための視点とヒントを、実践につながるかたちで持ち帰っていただける場を目指します。
引用：
architecture-con.findy-tools.io
イベント参加の背景
参加したセッション
1. DDDが導く戦略的トレードオフのアート
メモ
20年前エンジニアを始めた時にガイダンスを探していた。
エリック・エヴァンスの書籍がはじめてビジネスに合わせてソフトウェアを変えていくかのガイダンスだった。
ただ、DDDを理解をするためには長い時間がかかった。
どうやってシステムのモジュラリティをあげるかに注目したが、DDDとうまく結びつかなかった。
DDDの仕組みを活かすためには正しくやるだけではなく、もう一人の怠惰なエゴと闘う必要がある。
ドメインモデルと言えば、Aggregate、Value Object、Entity、Domain Event。
これらは大事だが、動くものを作ることも大事。
テクニカルな技術、適切な設計を取ることが後回しになることもある。
Bounded Contextにはいろいろある。
ライフサイクルの境界線。オーナーシップの境界線。モデルの境界線。
正しいモデルを見つけることが重要。問いから必要なモデルを洗い出す。
モデルを事業と結び付けていく。
人がBounded Contextによっては、立場が異なることもある。
複数のBounded Contextを統合していく必要がある。
ProducerとConsumerであれば、ProducerをConsumerが参照する。
ProducerはConsumerをモデル化する。
Producer（上流）が変わればConsumer（下流）も変わる必要がある。
そうした依存性をさげるために、Integration Contractを設ける。
ただ、こうした面倒なことをせず、2つのモデルがパートナーシップを築けば解消もできる。
それでも依存性を解消するためには、腐敗防止レイヤーを下流に設ける必要がでてくる。
とはいえ、そうしたレイヤーを設ける必要もなくなっていく。
ここまでいくと、同じビジネスロジックを複数モデルで持てばいいとも考えられる。
パターンがまったく逆の戦略が闘うことになる。
DDDの二重性を考える必要がある。
2つのコンポーネントが結合し、片方が片方を参照することが重要。
その逆方向に与えるのは、最も抽象的な形で言うと「知識」である。
知識は上流から下流に流れていく。
知識の内容によって、デザイン意思決定の質が決まる。
知識を計測する単位を何にするか。
INTEGRATION STRENGTH
・Intrusive Coupling：侵入型結合。
実装の詳細。プライベートインターフェースを介した統合。
・Functional Coupling：機能的結合。
機能的関係。業務要件が変わると両方に変更が発生する。
・Model Coupling：モデル型結合
上流に変更が走ると下流でも変更が走る。
モデルに対する変更時に複雑性が発生する。
・Contract Coupling：契約結合
導入時には非結合。それぞれが独自に進化できる。
インテグレーションコントラクトや腐敗防止結合がこれにあたる。
知識を共有するときに2つの役割の間にどのように知識が共有されているかが重要となる。
また、距離も重要となる。
Statements→Methods→Classes→Namespaces→Components→(Micro)Services→(Micro)Systems
距離が離れれば離れるほどコーディネーションが必要となる。
この距離はチームの単位としても捉えることができる。組織がそれを表す。
弱い距離*弱い結合：複雑
強い距離*弱い結合：高凝集
弱い距離*強い結合：疎結合
強い距離*強い結合：複雑
2つの組み合わせはモジュール性。バウンダリーをまたがって共有されるもの。
結合強度をビジネスユースに特化して反映する。
資産価格の変動の度合いは予測できない。
システムによって変更が多いもの、低いものがある。
ビジネスの構成要素であるサブドメインによって決定される。
コアサブドメイン：事業の競争優位性につながるもの。
ジェネリックサブドメイン：既に解決されている問題。ビジネスの差別化は無い。
サポーティングサブドメイン：中間にあるもの。ビジネスの複雑さも競争優位性もない。解決するのは簡単。
コアサブドメインが一番資産価格の変動の度合いが高い。
善玉のDDDと悪玉のDDDは事業領域によって使い分けるべきである。
資産価格の変動の度合い、距離、結合度によって判断をする。
DDDの知恵はデザインエクセレンスのためだけではない。
グラレコ
学び
DDDは難しい。
だからこそ、適用のための判断が重要となることを再認識しました。
また、距離という捉え方が興味深く感じました。
個人的にはサービスが離れると仕組みが無いと見失う感覚があります。
2. ドメイン駆動設計とマイクロサービスアーキテクチャ
メモ
本当にマイクロサービスアーキテクチャでいくか？？
成功したマイクロサービスは大きくなりすぎたモノリスを分解することから始まっている。
デスカッション
・サブドメイン：業務を分析して分解
・境界づけられたコンテキスト：モデルを作るための分解。ユビキタス言語の適用できる範囲。設計で見つける。
- この2つの関係は？どっちが大きい？いつ分割する？
成瀬さん：
理想は1対1。サブドメイン1つに対し、境界づけられたコンテキストが複数になることも。
福井さん：
1対1理想だが、ユビキタス言語が通用するが業務が分割されていることもある。
コンテキストの境界は疎結合とする。ただ、リアルの業務では異なることもある。
成瀬さん：
地図がサブドメイン。国境は境界づけられたコンテキスト。
- 分けた方がいいにおい
成瀬さん：サブドメイン→会話する人が変わったとき
福井さん：組織で分けられることもある
成瀬さん：
開発者がビジネス領域に入ることで、ビジネスにソフトウェアが近づき1対1になってきている。
ビジネスは早い。システムは後追いになる。結果ずれることもある。
福井さん：
イベントストーミングの最後のコンテキストマップから設計となる。
お客様によってはコンテキストマップを見てから逆コンウェイ戦略をできる。
成瀬さん：
組織を分けて決定権が無いというアンチパターンもある。
組織のトップレベルの理解を得る必要がある。
- 境界づけられたコンテキストとマイクロサービスの関係性
成瀬さん：サービス = デプロイ可能プロセス。1対1じゃないこともある。インフラ・運用コストにも影響する。
福井さん：マイクロサービスは実態のあるアーキテクチャ。その単位でデプロイできる。スケーラビリティが求められる範囲で決める。
成瀬さん：パフォーマンス上げたいものを分けるという考え方もできる。
福井さん：
サーバーレス（FaaS）だと分散されてマイクロだという誤解もある。
1つのLambdaで1つのコンテキストを実現するのはFAT。ラムダリスと呼ばれる。
複数のLambdaでマイクロサービスを実現する形となる。
ラムダリスはAPIごとに呼び出しメソッドを分けることもできる。
- モデルが共有されるパターンでどうモデルを管理するか
成瀬さん：
いろいろなパターンがある。
モノリポ：マイクロごとに参照できる。
全部分けるパターン：システム同士のつながりが見えなくなる。
依存関係が重要となる。
福井さん：
依存関係の見え方をIDEで工夫もしている。
生成AIで考えると、AIが見える範囲に全部ある方が良い。
モノレポでも構造を整理することが重要。
- 境界線を分割した後に何から着手するか
成瀬さん：
先手はコアドメイン。実際作ってみて検証することが重要。
福井さん：
新規と既存でやり方違う。
新規は一番難しいものから着手する。
既存は依存関係の最も少ないものから外だししていく。
成瀬さん：
コアドメインの一番依存関係の低いものからやる。
一番後ろからやるのがよい。
バリュー出すのが大事。なので、コアドメインからやることが重要。
PoCレベルから学習としてやるのも手だが、コアで価値を生む。
コアドメインに強いメンバーをあてる。
- 生成AIの活用して効率的に開発するには？
福井さん：
AWSではAI-DLCを推進。
開発者は2つのパターンを利用している。
1つは委託。1つは伴奏。
開発者が常に意思決定をしていく。
AI：プランニング、タスク分解、アーキテクチャ提案
開発者：検証。意思決定、監督の最終的な責任を保持
大きく3つのフェーズ。
インセプション：ストーリーの定義から仕事のユニット計画
コンストラクション：モデリング、コーディング、テスト
オペレーション：IaC環境でのデプロイ、インシデント管理
この3つのフェーズを人間がぐるぐる回していく。
レビューが重要になり、業務理解、システム理解が重要となる。
学び
Youtubeでいつもお世話になっています。面白かった。
特にコアドメイン、境界づけられたコンテキスト、マイクロサービスの関係性は勉強になりました。
それぞれ何を表現していて、どう定義していくかは形式知と整理できるようになりたい。
開発者がビジネス領域に入ってきているので、コアドメインと境界づけられたコンテキストが1対1になってきているという話が興味深かったです。。
特に事業価値のあるコアドメインに手を出すことは肝に銘じたい。
3. ビジネスを駆動するアーキテクチャへ ～AI-Agentという新しいアクター
メモ
資材調達ネットワーク。フルスタックEC。自前でやっている。
関節資材業界の流通体系は複雑かつ不透明。それを合理化する。
購買プロセスの課題やストレスに対して、プロセスを効率化する。
基幹システムの話。
デジタルとリアルが複雑に絡みあう変化に合わせ進化が求められている。
事業成長に貢献するためのアーキテクチャ再構築とシステムのモダナイズに挑んでいる。
ドメインモデリングの前にやったこと。
仮決めしたドメインに合わせて組織を分割。逆コンウェイ。
ドメインごとに実行環境を変えてデプロイ可能にした。
イベントストーミングで時系列で業務を整理した。
プロセスを読み解くと、発注ドメインと配送ドメインに違和感があった。
その間に在庫ドメインが必要であることが分かってきた。
メソッド単位に落とし込んでイベントストーミングでして、業務理解に努めた。
EDA＋ES+CQRSのPoC、在庫ドメインを切り出して作った。
この手法に対しての理解も深まった。
再度基幹システム全体のコンテキストマップを書き、通信の関係性も表した。
これだけでは十分ではない。
変えたいこと：組織とアーキテクチャ、文化、開発手法
やりたいことはビジネスを駆動するアーキテクチャ。
アーキテクチャと表裏一体の組織。変わることが当たり前な文化。アーキテクチャを変えてく手法。
・開発手法（技術）
オンプレからクラウド。ドメインごとのDB。スキーマ駆動開発。業務に即したデータ型。
そのために、DOJO。MDI*エコシステム。
・文化（人）
変わるための課題解決。
ひとりひとりにスポットをあてる。
・組織とアーキテクチャ
AI-Agentというアクターが登場。
テックビジョン：データとテクノロジーを徹底的に活用
参考：
業務部門の方はまだAIに慣れていない。
カスタマーサポート向けAI-Agentの開発。
ヒトとAI-Agentの協業モデルを模索するため、速く作って学びを得たかった。
MVPとしてドキュメントが整備されているであろうルールベースの業務を選んだ。
暗黙知が眠っていることが発見された。
やりたいことは利用部門による利用部門のための自動化。
Agentic Autonomous Platform。
ユースケース1本1本では規模が小さい。
費用対効果を考えると広く使ってもらうことが必要となる。
結果、マニュアルが重要。
業務は無数のあれこれで構成されている。ここはマニュアルある。
そのためのシステムの使い方とかノウハウ。これは実装出来ない。
手続き的な処理を抽象化して宣言的に書き換えていく必要がある。
＝業務の複雑性をシステムに隠ぺいする。
このことを業務の人にやってもらうことは難しい。
AIでのプランニングでは限界がある。
ヒトの意思決定は、実現したいことと理由を持ったパラメータを決めること。
これをどう実現できるのか。
組織とアーキテクチャの再編成。
基幹システムとして必要な事は、既存システムを目的別に分けること。
所定の業務ルールに従いI/P/Oするシステム。Systems of Activities（SoA）。
SoAの振る舞いを監視・変更するシステム。Systems of Management（SoM）。
一昔前まで、基幹システムはSoRと呼ばれていた。SoRecord=SoControls+SoA。
ActivityをControlする関係性。
この状態でのAIでは業務目的を構成する状態に適したワークフローを選定。
業務システム/SoCの仕事をAIエージェントが代替する。
モダナイゼーションはこれから。
実施の知見から進む方向性は見えてきた。ビジネスインパクトも見える必要あり。
アプリケーションを動かせる状態にしてから、次のトライアルも生まれた。
横のつながりを用意している。
・アーキテクチャと組織
AI-Agentなど使われる側の整備が重要になっていく。
急場しのぎではなくAPI連携を実現していく。
必要なケイパビリティをチームに凝集していく。
・これから
不要な複雑性をシステムに閉じ込め、業務インパクトを出せるようにする。
学び
現在進行形の実践の話。
ドメインごとに実行環境を変えてデプロイ可能にしたという話が、とんでもなく大きなことへの挑戦を感じました。
利用部門による利用部門のための自動化について、費用対効果／投資対効果がでる規模の大きい部分での挑戦が考えておきたいところでした。
マニュアルがあるから形式知が整っている訳では無いということも興味深かったです。
そのうえで、いかにエンジニアリングしていくかという話として、もっと整理して解釈したいと思いました。
4. メッセージ駆動が可能にする結合の最適化：スケールと変化に耐えるアーキテクチャの実践
メモ
分離には3つある：時間的分離、空間的分離、読み書きの分離
イベント駆動とメッセージ駆動：関係性
メッセージ駆動：より広い概念、コマンドもイベントも使う
イベント駆動：メッセージ駆動の一種、主にイベントを使う
疎結合の分離軸：
・時間的分離
あるコマンドを送ったときにいつ処理をされるのか。
結合度が高いと関心の分離が難しくなる。メソッド、同期API、ブロッキングi/o。
・空間的分離
コンポーネントの場所など
モジュラーモノリスでの論理的な分離。
物理的な空間分離ができなくなる。
同期呼び出しにより呼び出し元がブロックとなる。
結果、スケールアップしかできなくなる。変更管理も難しくなる。
同期呼び出しのトレードオフ。
APIファーストで進めても処理が連結すると同一故障単位に繋がる。
それらのサービスが分離できる場合は、依存度が高いということになる。
非同期メッセージングを利用するためには、間にメッセージ基盤（SQS、Kinesiss）を入れる。
処理の依頼はただ投げっぱなしになる。ファイア・アンド・フォーゲット。
サービスAからサービスBを呼ぶ。
サービスB側にイベントを購読するためのリードモデルが必要になる。
サービスA、Bどちらかに故障があっても稼働できるようになる。
複雑な処理であればCQRSでコマンドとクエリを分離する。
読み取りの要求は非正規型データを求める。
イベント・ソーシングの本質は、集約の状態そのものがEventに基づいて構築される。
Eventは流れていくだけのものではなく、今の集約の状態をつくる。
CQRSを利用すると、イベント・ソーシングは必須となる。
実践で使えるツール：Apache Pekko、Proto.Actor(Go)、event-store-adapter、fraktor-rs
学び
時間的依存について今まで考えたことがなかったため大きな発見でした。
メッセージングについて改めて考え方を押さえることができました。
5. 出前館アプリ進化論 〜アーキテクチャと組織のリアルな変革の舞台裏〜
メモ
コンシューマー領域の変革について。
2020年3月Lineグループと資本業務提携。
・変革フェーズ1
コロナ。
やったこと。サービス理解、業務理解、システム理解。
各コンポーネントでのそれぞれの課題に向き合う必要があった。
インフラ：オンプレミス中心、サービス特性に合わせたインフラ構成ではない、運用属人化
→クラウド化で解消
バックエンド：EOLフレームワーク、モノシリック構造責務混在、巨大DB（800テーブル以上）
→マイクロサービス化で解消
フロントエンド：Controller肥大化、ビジネスロジックがclientに点在、知識・リソース不足
→WEBサーバーフルリプレースで解消
アプリ：開発体制（アウトソース）、コード品質
→ドキュメント整備・コツコツ改修
参照：
・変革フェーズ2：リアーキテクチャ
2021年頃。
でっかいAPIサーバーからでっかいDBを参照していた。
でっかいAPIサーバーとは別にWEBサーバーを設けキャッシュしていた。
現在。
ビジネスロジックをBFFに集約。マイクロサービス化。
サービスを止めずに進化させてきた。
WEB：
段階的に構成を変えていった。
・Codeigniter→Next.js/PHP→TypeScript
フルサーバーレンダリングSPA
100以上の画面を移行した
・BFF/WEB混在
もともとキャッシュ目的だったBFFの責務が、
ビジネスロジックの共通化、マイクロサービスのオーケストレーション
バックエンド：
モノシリック、マイクロサービス
800以上のテーブルをどのサービスが持つかのオーナーシップの整理
新規マイクロサービス立ち上げ
DB：
でっかいDBから移行。サービス間の依存を物理的に切った。
アプリ：
もともと80以上のAPIが乱立していた。
BFF移行。MicroServiceもBFFで吸収。
アーキテクチャが変わったことでステークホルダーも明確になった。
変化し続けられる文化もできた。
・次の10年にかけて
いかに素早くユーザーに価値を届けられるか。小さく早く。
ドキュメントと敬意を残し続けること。
質の高いコードと技術負債との付き合い方。
23年間支えてくれるユーザーを裏切らない。
学び
出前館さんの泥臭い変革の話。改めて凄い。
コロナ前後で出前館さんを利用していたため、その裏でこんな戦いがあったとは、と驚きます。
また、当時の出前館を利用者として知っている人間として、800以上もテーブルがあったことにも驚きです。
サービス利用者としてはそんなに無い気もするし、無い気もする時点でどういった状態だったのかの想像ができます。
そんな途方も無く感じる状態に対して勇気を貰います。
6. 事業状況で変化する最適解。進化し続ける開発組織とアーキテクチャ
メモ
製造業で起きている問題。データの分断により車輪の再発明が頻発。
目指していきたい世界観：資産化されていない情報を資産化する。
そのための製造業AIデータプラットフォーム。
基盤で整理されたデータはアプリケーションを通じて活用される。
事業状況の変化。
2017年創業。2022年CADDi Drawer開始。2024年。CADDI Quote開始。
Drawerの頃の2倍ぐらいの組織規模になっている。
2019-22：Manufacturing事業
図面中心のUI。サーバーレス。Pub/Sub非同期。
社内プロダクトのなかでは一番個別最適に振り切っている。
2021-22：CADDi Drawer初期
図面データを資産に変える。図面データからすべての周辺データに繋ぎにいく。
図面に記載される情報をAIで取得する。
フォーマットの無い2次元情報を扱うのが難しさ。
プロダクト化前（PoC）：サーバーレス、Firebase、全文検索のみ実装、品質落として最速開発
お客様の重要な情報を預かるにあたりISMS取得した。
2023-24：CADDi Drawer成長期
成長に伴い、組織とアーキテクチャの課題が現れた。
顧客要望に応える必要が高まってきた。
データモデル・解析処理の拡張性が求められた。
多くのデータ活用が顧客に広がっていった。
組織再編：分割統治と全体最適
チーム最適と全体最適。
自律は進んだが、サイロ化が発生。組織とシステムがずれて複雑化した。
25-：データプラットフォーム化
データ種別が各種ばらばら。解析に当たってはドメイン知識も必要。
一般的にモデルを学習。
グローバル・セキュリティ・統治。各国の輸出規制に対するデータの管理も行っている。
組織再編では逆コンウェイを意識した。
事業成長に対してリソース不足も見えている。注力をする領域を見極めて優先順位付けしている。
・急成長企業の3つの課題
組織とシステムの境界がずれて複雑化：境界設計と再構築で解決
自律は進んだがサイロ化が発生：共通ポリシーで解決
事業成長に対してリソース不足：優先度で解決
学び
年で区切ってのアーキテクチャの変遷の紹介でしたが、その裏には随時判断が求められていたのだろうと思いました。
製造業のDX。プロダクトと製造業のお話を聞くたびに凄く貴重な仕事だと思います。
随時求められるトレードオフの話が印象的でした。
7. ソフトウェア設計の課題・原則・実践技法
メモ
・ソフトウェア設計の課題
ソフトウェアシステムは事業活動を効率的かつ効果的に進めるためのさまざまの仕組みの一つ。
目的は高業績を持続させること。
広く連動：2010年頃。PCの利用率と携帯電話の利用率が逆転した。あらゆる事業がデジタル化。
深く連動：状況判断・推論がソフトウェアシステム上で行われるようになった
双方向に影響：
事業活動の変化 = ソフトウェアの変化。影響する範囲が広い。
そうしたソフトウェアは複雑になる。
事業は複雑なため、ソフトウェアも複雑になる。
事業活動の変化に沿ってソフトウェアも変化する。
未知・不確実の状態で事業・ソフトウェアに取り組んでいかなきゃいけない。
設計に使えるための資源は限られている。
・良い設計を生み出すための基本原則
変更容易性に焦点を合わせる。
事業と共に変更発展していくソフトウェアにとって重要。
重要なことは事業活動を理解して設計判断すること。
綺麗にする部分が事業に役立たない部分だと、ソフトウェアとしても役に立たない。
設計とは何か？
形の無いところに形を与えて、その形を変え続けること。
良い設計は悪い設計よりも変更しやすい。（達人プログラマー）
整理整頓されたコードは乱雑なコードよりも変更が楽で安全である。
良い設計は事業価値を生み出す。悪い設計は事業に損失をもたらす。
事業活動を理解して設計判断すること。
整理整頓に使える時間は限られている。
費用対効果の高い箇所を事業視点で判断する。
事業理解にはいろいろある。
事業の差別化戦略とソフトウェア実装を結びつける。
差別化戦略に適合するソフトウェア設計方針と開発の優先順位を見つける。
差別化への影響が少ない部分は簡略で済ませる。
事業活動を理解して設計するための参考図書。
『ドメイン駆動設計をはじめよう』『エッセンシャル版 マイケル・ポーターの差別化戦略』
中核の業務領域こそ、変更容易性の改善に継続的に取り組む。
・ソフトウェア設計の実践技法
良い設計を生み出すための基本原則をどう実践するのか。
乱雑なコードの整理整頓。
設計改善の費用対効果を最大にするには。効果は分からなくても費用は分かる。
小さな設計改善を開発組織全体で継続する。
戦略的に重要な個所を重点的に設計改善する。
判断力をあげることで限られた時間を有効に使えるようになる。
機能修正や機能追加について、事業影響の重要度を判断できるようにする。
ビジネス的な仮説検証の中にエンジニアも入れるようにする。
重要な機能追加/修正を対象範囲を限定して実施する。それ以外はやらない判断をする。
綺麗にすることをゴールにせず、変更で楽に安全になったことを検証する。
ソフトウェア設計のアンチパターン。
初期設計に時間をかける。重要度低い設計改善に時間をかける。
乱雑なコードを整理整頓しないで機能を修正追加する。
今触らない機能を整理整頓する。
設計改善の3つのレベル。
小さな設計改善。大きな設計改善。戦略的設計改善。
仕事でやる以上、この3つを並行して実施する。
小さな設計改善：
（初級）不要なコード消す、チャンキング、グループ分けした単位に名前をつける
（中級）値オブジェクト、コレクションオブジェクト、区分オブジェクト、
大きな設計改善：
計算判断・出力・入力の３つの関心毎をクラスとパッケージを使って切り離す。
アプリケーション特化のデータ型を使って計算判断ロジックを記述する。
戦略的な設計改善：
事業戦略とソフトウェア設計を結びつける。
差別化戦略。競合他社と異なる自社独自の価値提案。
ビジネスルール。差別化戦略の実行手段。
業務ロジック。計算判断ロジックの実装。
学び
事業活動とソフトウェア開発の連動性。
競争優位性のある機能こそ設計改善を。
今日多くのセッションでその実践をお聞きすることができたと思っています。
それを大なり小なりエンジニアのひとりひとりが事業領域を見据えてコードを扱うことができれば。
改めて、プロダクト領域をエンジニアが見据えていくことの重要性を理解しました。
8. そもそも「レジリエンス」とは何か？
メモ
レジリエンスについて。
今新しい本、『分散システムのレジリエンシィ』。
・レジリエンスとは？
レジリエンスとは持っている／持っていないではない。
レジリエンスはどのようにシステムがパフォーマンスを出しているか。
あるかないかではなくて、質。
Eric Hollnagel：
必要な操作を維持すること。
何か問題が起きても継続しないといけないことは何か。
予期している状態、予期していない状態に対応する。
機能を調整すること。
システムを作ったときに何か起きた時何もできないとレジリエンスがないと言える。
オペレーションが継続できることがレジリエンスがあると言える。
間違ったことを受け入れることが重要となる。
・レジリエンス・エンジニアリング。
安全管理。
従来、悪影響を及ぼす結果を減らしていくことだった。
ただ、問題をなくすということでは、限定的になっていく。
大規模化すると難しくなっていく。
システムのコンポーネントが増えると、故障する確率は増えていく。
人間が入るシステムは複雑になっていく。
人間はコンピューターのような動き方をしない。
案件管理とはシステムが複雑になると困ってしまう。
何か間違えなければ好いが、間違えるとどうなるのか。
そのためにレジリエンスエンジニアリングが重要となる。
厳しい状態であっても継続できるようにするのがレジリエンスエンジニアリングとなる。
一つ一つの故障率を下げることは重要である。
コンポーネントが増えると対応できなくなってくる。
安全性の管理。悪いことが起きないようにする。
その外にあるのがレジリエンス工学。
悪いことが起きないだけでは十分ではない。
そのために3つある。
すべてのモデルは間違っている。
完璧にお互いのモデルが動くわけではない。
レジリエンスの4つの概念。
・堅牢性：何かあっても持続できる状態にする。複雑性が増える（例：k8s）
・リバウンド：何か起きてもどれだけ早く回復できるか。
・優雅（Graceful）な拡張性：
不測の事態にどれだけ対処できるか。
プロセス、文化に関わる。
組織は人がやるべきことが決められている。人がどう対応できるかが重要となる。
・持続的な適応能力：
何か起きたときにシステムに反映すること。
システムはリリース（新しく）するたびに次に備えることができるようになる。
適応は危機や進化のための革新とできる。
実践的なガイダンス。
ディッケンソンのサービス信頼性。
・監視：オブザーバビリティ。システムの中で起きていることの理解。
・インシデント対応
・ポスト・モーテム・根本原因分析：心理的安全性をもとにした事後検証
・テスト＆リリース：非機能、スモーク。レジリエンスの目で何ができるのか。
・キャパシティプランニング：必要なキャパシティが必要なときにあるか。
・ディベロップメント：コードの中に何を入れられるのか。障害に対応できる要素を入れる。冪等性を実現する。
・プロダクト：デプロイとリリースは分ける。段階的にロールアウトできるようにする。
参考：
コンピューターは基本的には理解に難しいものではない。
コンピューターシステムは複数システムと接続している。
1つのサービスは複数のサービスとつながっている。
繋がっている分散システムは本質的には複雑性をもっている。
AWS。サービスが特定の部分に依存していた。
人間というオペレーターがシステムをより複雑にしている。
ソシオテクニカル・システム。
もともとは社会とテクニカルを合わせた用語。知識と行うことの技術に関連している。
レジリエンスを高めるためには、システムを考えることと同様に、乗務員のことも考えないといけない。
六角形モデルがソシオテクニカルを表す。
プロセス、インフラ、ソフトウェア＆ツール、人、文化、ゴール。
ヒトとテクニカルの要素が集まっている。
例：
電車事故があったときの原因分析。
まずはインフラを見た。次にプロセスを見た。次に文化的要素。
ゴールはなんだったのか。速く終えることがゴールになっていた。
安全な手順がどんどん軽視されるようになっていった。
本来は点検すべきところが点検していない状態を招いた。
誰か一人が間違えたから悪い結果が起きるわけではない。
一人の人が解消できるわけではない。
追及の文化も良くない。結果、問題が表に出なくなる。
重圧が問題の解決をさせなくなる。
何が起きたかを理解することが重要となる。
レジリエンスにとって重要なこと。
何かを諦めても何を継続させるか。
多くのことが継続できるようにすること。
レジリエンスの向上をしたい場合はシステムを理解すること。
学び
レジリエンスに対する理解が深まりました。
システムを持続可能とするためには、われわれ人間もその要因の一つであると捉える必要がある。
ソシオテクニカル・アーキテクチャを捉える六角形モデル。
何かあった時に無作為に思考を巡らせるのではなく、そうした時にすぐ取り出せるとこに置いておきたい。
ブース
スタンプラリーを全制覇しました。ありがとうございました。
様々な企業のプロダクトを知ることができ、自分の視界を広げることができました。
ビットキーさんとログラスさんの書籍も無事にゲットしました。
頂いたノベルティも嬉しいです。
懇親会
今回、はじめてFindyさんのイベントの懇親会に参加させて頂きました。
楽しい時間でした。ありがとうございました。
びくびく参加したところしゅういちろうさんを発見し救われました。
TechRAMEN 2025 Conference以来の方たちともご挨拶できて嬉しかったです。
色々なコンテキストの方たちとお話させて頂き、学ぶところが多くありました。
皆さん凄い。背筋が伸びます。
まとめ
今回2日目のみの参加でしたが刺激と学びを多く頂きました。
自分はソフトウェアエンジニアということもあり、アーキテクチャといえばアプリケーション・アーキテクチャを想定しがちですが、アーキテクチャはアプリケーションだけでなく、インフラやなんだったら組織的な部分もあり、依存度も時間や空間越しの依存度まで意識をするとなると、改めてソフトウェアの捉え方を拡張せざるを得ない時代になったと気が付きます。
また、今年は同じプロダクトを開発しているメンバーが両日参加し、本当に嬉しかったです。いつもカンファレンスはひとり参加が多いため、一緒に感想を言い合える仲間がいることが嬉しい。
Findyさんはいつも我々エンジニアがわくわくするイベントを開催してくれて本当に感謝しています。
見れなかった登壇資料も追いたい。
今回のアーキテクチャConferenceの登壇資料はこちらにまとめていきます！
— Go (@00_AK1RA) 2025年11月20日
後日アーカイブ動画もこちらに掲載しますのでぜひご覧ください！
https://t.co/qNch2ju8Nx#アーキテクチャcon_findy
来年も楽しみだし、今年もまだまだ楽しみにしています。
