はじめに
こんにちは！
SecureNavi プロダクト開発部エンジニアのHayaです。
先日 アーキテクチャConference 2025 に参加してきました！
アーキテクチャをテーマにしたカンファレスで、名だたる企業が出展し、セッションを開催していました。
先進的な開発組織のリアルな話を聞ける場は少ないので、刺激的な学びばかりでした！🔥
特に印象に残った2つのセッションを、感想も交えて紹介しようと思います！
アイデアを爆速でプロダクトに落とし込むには💡
（Yuhki Yamashita氏 Figma, Inc.（CPO））
まずは圧倒的なユーザーインサイトの理解から
このセッションで何度も強調されていたのは、「ユーザーインサイトを徹底的に理解すること」でした。
- 何より「まず使ってもらう」ことを目指す
- ユーザーの要望はそのまま受け取らず、“なぜ？”を何度も掘り下げる
- AIはユーザーインサイトの洞察力を与えてくれるが、分析が正しいかは人が判断する必要がある
この “なぜ” を繰り返すことで、ようやく課題の本質にたどり着けるという話には、強い共感と学びがありました。
個人的に、ユーザーの要望は直感的な内容なので、課題の本質や最適な解決策を見つけるために深掘る必要があると考えています。
エンジニアとしてより"なぜ"を追求することが、大きい価値を提供できることにつながると感じたので、一層意識していきたいと感じました。
パフォーマンスへの執念
Figmaのアーキテクチャ選定で最も重要視されたのは、パフォーマンスとのことでした。
- 複雑なファイル構造
- グローバルに利用される
- 多人数同時編集という高難度の要件
- CICDで常にパフォーマンスを確認し、閾値を必ず設定して、それを下回る変更はしない
特に驚いたのがこれ：
「FPSが60 → 30になるだけで、CEOが即気づいてクレームを入れる」
まじで！？となりました。
そもそもFPSの違いに気づける時点で格闘ゲーマーか？と私は感じてしまうし、CEOがそこまでパフォーマンスを意識していることが、パフォーマンスを重要視する文化を醸成していることに驚きました。
Figmaのようなグローバルに使われるプロダクトの矜持をひしひしと感じました。
AIはプロトタイプ生成やナレッジ共有で役立つ
- PMがプロトタイプ生成に活用
- プロジェクトの初期段階でAIにプロトタイプを作成させる
- アイデアの幅が広がる
- AIにドキュメントを書かせて属人化を解消
- 以前は特定の人に聞かないと分からない仕様があり無駄が多かった
- 新入社員もAIに聞けば仕様がわかる状態に
特に後者は、素晴らしい運用だと感じました。
仕様のドキュメントが整備されていないと、質問をする側と受ける側の両方の工数がかかり、認識の齟齬や当事者しか知り得ない情報が増え、コミュニケーションコストが増大し、価値提供の遅れにつながります。
仕組み化しないとドキュメントは整備できない印象で、AIの得意領域でもあるため、参考にしたいです。
AI時代のインシデント対応 〜現場に権限を、組織に学習を〜⚠️
（草間 一人氏 PagerDuty株式会社 Product Evangelist）
AIによる開発の民主化が招くリスク
冒頭で語られたのは、AIによってアプリケーションの数が爆発的に増えるという話がありました。
- かつての Two Pizza Rule （1チーム5〜8人）から、
→ いまは2〜3人で1アプリを作れる時代へ - 開発の民主化が進む
- AIによるインシデントの事例も増えてきている
インシデントはコードの問題。しかし混乱を作るのは“組織”
- 障害そのものはAIで生成したコードで発生する
- しかし、混乱した状況は“人・情報の流れ・意思決定・責任分担”によって生じる
つまり、インシデント対応の本質は組織構造の問題。
下記が曖昧だと、障害対応は迷走してしまうとのことでした。
- 誰が判断するのか？
- 情報はどこに集約するのか？
- どのチャネルでどう発信するのか？
- どこまでエスカレーションするのか？
私も振り返ってみると、AIを使って開発をしていて何か問題が起きた際に、コードの修正は済んでいるものの誰が判断するかわからず、リリースが遅れてしまったことがありました。
あらかじめインシデント対応を見越した体制を構築し、エンジニアはコード修正に向き合いやすいフローを組めれば、安全かつ早急にインシデントに対応できると感じました。
ヒントは災害対応の世界にあった —— ICS
セッションで紹介されたのが、米国消防で確立された災害現場・事件現場などにおける標準化された手法である「ICS（Incident Command System）」です。
災害現場のように、多数のステークホルダー（住民、消防、警察、行政）が入り乱れる状況で、統制を取るための標準化された組織構造が必要とのことでした。
中心となる「インシデントコマンダー（IC）」
- 意思決定と指揮系統の中心
- 目的は インシデントを最短で解決に導くこと
- 責任の所在、情報の流れを明確化する
- 平時はCEOまたはPOが最も権限を持つ
- 戦時（インシデント対応）はインシデントコマンダーがトップ
- ICSでは「最初に現場に到着した人」がICを務めるが、 ローテーション制など、事前にルールを決めておく。
- より適した人がいれば後から移譲可能
コントロールプレーン（ウォールーム）
- リアルタイムで状況を変えるチーム
- ICと担当者が密にコミュニケーションする場
- 意思決定のハブ
- Slack / Zoom / 専用チャンネルなど
データプレーン（周囲への情報共有）
- 周囲への適切な情報共有を行う
- 情報共有の鉄則「3つの適切」
- 適切な粒度
- 適切な方法（ブロードキャスト型）
- 適切なタイミング（ステータスに変化があった時・定期的に）
災害対応を参考にすると聞いた時に、確かにITにおいてもインシデントは災害だよなと、斬新な発想だと感じました。
米国消防で確立された手法をITに落とし込んでおり、最大目標である「インシデントを最短で解決に導くこと」に向けて、合理的な体制が構築されている印象でした。
手法も当然ながら、業界に縛られない視野の広さが参考になりました。
まとめ
普段は自分の接する世界が「当たり前」になりがちでしたが、会場には自分の知らない先進的なエンジニアリングの世界が広がっており、エンジニアとしてモチベーションが大きく上がりました🔥
カンファレンスに出展されている企業はどこも技術レベルが高く、そうした企業の具体的な事例やアーキテクチャに触れられる機会は貴重で、非常に有益でした。
また、イベントならではの非日常感を楽しめたことに加え、普段はフルリモートなので、他のエンジニアと直接会って情報交換や食事ができたのも嬉しいポイントでした。こうした「交流」という副次的なメリットも体感できてよかったです！
単に参加して満足するのではなく、得た学びを今後の業務にしっかりと活かしていきたいと思います🏃♂️
採用やってます！
SecureNaviでは一緒に働く仲間を募集しています✊
私もカジュアル面談を担当しているので、よろしければお話ししましょう！
技術本部 募集ポジション
採用情報
カジュアル面談
Discussion