1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【参加レポート】アーキテクチャConference 2025〜「適正技術」への回帰と、プロダクト・組織を進化させ続けるための設計論〜

Posted at

1. イベント概要

  • イベント名: アーキテクチャConference 2025
  • 日時: 2025年11月20日(木)~21日(金)
  • 場所: ベルサール羽田空港 / オンライン
  • テーマ: 技術の変化が加速する中での「最適なアーキテクチャ」の選択と進化
  • URL: アーキテクチャConference 2025

2. 全体的な所感:システム設計から「組織と成長」の設計へ

当初、「アーキテクチャカンファレンス」という名称から、システム内部の構成技術や低レイヤーの実装論が中心になるのかな?という印象を受けましたが、タイムテーブルをみるとどうもそうでもない。という事で、参加要望を出し、問題なく許可が降りたので大阪から東京へ。
そしてその結果、期待以上に学びの多い2日間となりました。

特に、コードやインフラの話以上に 「プロダクトを作り、運用し、拡大・成長させていくための全体設計」 に関する深い知見が沢山得られたのは大収穫でした。

現在、私はEM(エンジニアリングマネージャー)として、スタートアップにおけるプロダクトの立ち上げから運用フェーズに携わっています。本カンファレンスで語られた内容は、単なる技術トレンドの紹介ではなく、「システムとして考慮すべきポイント」と「チーム・組織として考慮すべきポイント」が不可分であるという現実を突きつけるものでした。

技術選定における「守破離」、組織拡大に伴う「オーナーシップの維持」、そしてAI時代における「人間の役割」。これらは全て、今の我々のフェーズにおいて避けて通れない課題であり、その解決に向けた具体的な指針を得ることができたと感じています。

イベント運営の皆様、登壇者の皆様に深い感謝を!
そして心置きなく参加許可を出してくれた弊社にも感謝を!

それでは振り返っていきましょう。


3. 詳細レポートと考察

① モダナイズの現実と選択:マイクロサービスは「目的」ではない

Opening KeynoteのSam Newman氏のマイクロサービスの話から始まり、いくつかのセッションではマイクロサービス、モノリス、という言葉が使われましたが、これらは「目的」ではなく「手段」であることを再認識することができたと思います。

【主なセッション内容と学び】

  • モノリスの肯定: 最初はモノリスでも問題ない。むしろ、スタートアップでリソースが限られている中で、理由なくマイクロサービスを選択することは避けるべき。「時期尚早な最適化」はいい選択とは言えない。
  • 守破離の「守」: スタートアップの立ち上げ期においては、基本の型(守)を忠実に歩むべきである。「型無し」と「型破り」は違うという言葉が印象的だった。
    • インテグリティ(完全性): 更新時の排他制御、トランザクション管理など、データが壊れない基本を徹底する。
    • メンテナビリティ(保守性): コードに現れない背景や意図をコメントに残す。分割統治や疎結合といった設計原則を守る。
  • 技術的負債との付き合い方: 拡大運用期はエンジニアリングリソースの「投資ゲーム」である。負債には「意図的なもの」と「認知外のもの」があり、特に危険なのは認知外の負債。これらをコントロール下に置き、一括ではなく「分割返済」していく戦略が求められる。

【考察・所感】
かつて私たちも、マイクロサービスという言葉の響きや柔軟性に憧れ、実装を試みた経験があります。
しかし結果としては「マイクロサービスっぽいもの」で留まりました。それは、マイクロサービスのメリットを活かせるほどの大きなシステムではなく、モノリスで十分なシステム規模だったからです。

今回の講義で 「無理に選択する必要はない」 と断言されたことには、強く背中を押される思いでした。重要なのは、アーキテクチャのラベル(名称)ではなく、モノリス構成の中であってもドメインごとの境界(モジュール性)を意識し、将来の分割を見越した「綺麗なモノリス」を作ること。柔軟なシステムを描くための本質はそこにあると再確認しました。
憧れやトレンドに乗るだけではなく、現実を踏まえた判断を下すことが大切だと再認識しました。

② スタートアップを支える組織戦略:自律とオーナーシップ

スタートアップでプロダクトを立ち上げ、運用し、拡大してきた実例の話から、実にリアリティのある参考になる話が聞けました。

【主なセッション内容と学び】

  • サービスチームの理想形:
    • 6〜8名の「サービスチーム」が、要件定義から開発、運用まで全てを行う(フルサイクル/フルスタック)。
    • これによりコミュニケーションコストが下がり、プロダクトに対する強いオーナーシップが生まれる。
    • 特定の機能(ドメイン)を担当する「ドメイン型チーム」は持続性が高く、知識が蓄積される。
  • 横断チームによるコモディティ化:
    • セキュリティやID管理基盤など、高度な専門性が必要な領域は「横断チーム」として切り出す。
    • 認証基盤を共通化し、各プロダクトがそれに接続する「コンパウンド化」を進めることで、テナントごとのコスト削減と開発速度向上を実現。
  • 文化は戦略に勝る:
    • どんなに良い戦略も、カルチャーが根付いていなければ機能しない。
  • 拡大運用期:
    • 拡大運用期は投資ゲーム
      • エンジニアリングリソースをどう振り分けるか。
      • 運用負荷、内部品質など見過ごされがちな投資先に如何に投資できるかが、今後の鍵。
      • PdM、POと共通認識をもつ。
    • 技術的負債は分割返済
      • 一括返済は大変。
      • 重要な場所ほど重点的に。

【考察・所感】
「サービスチーム」と「横断チーム」の両輪で回すスタイルは、まさに私たちが目指すべき 「進化系」 だと感じました。各チームが自律的に動き、プロダクトを成長させていく姿は理想的です。

しかし、現実は「兼業で手が足りない」「他のタスクで時間が溶ける」という課題も山積しています。理想の組織を実現するためには、単純な開発力だけでなく 「採用」 がボトルネックになると痛感しました。募集を待つだけでなく、イベント登壇やスカウトメールなど、自社の文化や技術を外部に発信する「攻めの採用活動」こそが、アーキテクチャを支える土台になり得ると強く感じました。
技術観点な話ではなく、こういった組織観点の話が、プロダクト全体にとって重要なポイントになるのだと感じました。

③ AIエージェントの未来と、試される「人間」のスキル

AIエージェントの構成、AI駆動開発など、今や欠かせないAIに関しても、アーキテクチャの観点や運用組織の観点から、沢山の興味深い話がありました。

【主なセッション内容と学び】

  • エージェントアーキテクチャの多様化:
    • シングルエージェントだけでなく、複数の専門エージェントが連携する「マルチエージェント(逐次、並列、レビュー型など)」の実装パターンが紹介された。
    • ADK (Agent Development Kit)
    • AgentOps
      • AIAgentの成功指標を計測する仕組み。
  • AI駆動開発の要諦:
    • コードの秩序(フォーマット、型検査、不要コード検査)をCIで自動化し、AIが生成するコードの品質を担保する仕組みが必要。
    • サンドボックス環境(Squid Proxy等)によるセキュリティ確保。

【考察・所感】
普段は何気なくCopilotを使っていますが、その裏側にあるアーキテクチャや「エージェントとして自律させるための設計」を知ることで、活用の解像度が一気に上がりました。

一方で、AI駆動開発が進むほど浮き彫りになるのは 「使う人間側の能力」 です。実装方針の策定や、AIのアウトプットに対する品質保証(レビュー)は、依然として人間に委ねられています。AIの能力は凄まじい勢いで進化していますが、我々自身が高いスキルと設計力を持ち得ていないと、その能力を100%引き出すことはできません。 「ツールに使われるのではなく、成長した我々がツールを使いこなす」 という意識変革が必要だと感じました。

④ レジリエンスの本質:システムは「完成」しない

Closing KeynoteのSam Newman氏による「レジリエンス」の定義は、この2日間の総括として非常に印象的でした。

【主なセッション内容と学び】

  • レジリエンスの定義: 単なる「堅牢性(障害に耐える力)」や「リバウンド(復旧力)」だけではない。
  • 持続的な適応性(Sustained Adaptability): 予期せぬ事態に対応し、システムを現在の状態に適応させていくこと。つまり、システムを進化させ続ける能力こそがレジリエンスである。
  • 問いかけ: 「システムはパフォーマンスを出しているか?」を常に定義し、観測し続ける必要がある。

【考察・所感】
勉強不足ではありますが、レジリエンスという言葉は初めて聞きました。
しかしその内容は、普段何気なく考慮していたものでした。
そして僕はこのセッションを通じて、「システムを作って終わりにするな」というメッセージを受け取った気もします。

レジリエンス・エンジニアリングとは、エラーへの備えといった守りの姿勢だけでなく、 「先を見続け、システムを進化させる」 という攻めの姿勢でもあると理解しました。
プロダクトを運用する者として、観測し、計測し、評価し、そして適応させていく。自分たちのプロダクトもそうありたいと強く願う、素晴らしい締めくくりでした。


⑤ 最後に

会場では、様々なシステムのアーキテクチャ図が展示されていました。
そこには、このアーキテクチャの工夫やポイントが記載されていて、各社色んな思考を凝らして、システムを作っているのだと感じさせられました。

自分も同じく開発に携わるものとして、プロダクトを運用・開発するものとして、様々な思考を凝らしてシステムを作ってきたつもりですが、そこには同志が沢山いるのだと感じた反面、まだまだ学び実践せねばならないものが沢山あるとも感じました。

繰り返しになりますが、本当に学びの多い、期待以上想像以上の、素晴らしい2日間でした。
本イベントに感謝を!

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?