AWS re:Invent 2025 参加レポート - ラスベガスの街がAWSに染まる1週間を体験してきた

この記事は、ファインディエンジニア #3 Advent Calendar 2025の22日目の記事です。

adventar.org

はじめに

こんにちは、ファインディのPlatform開発チームでSREを担当している原（こうじゅん）です。

2025年12月に、アメリカ・ラスベガスで開催されたAWS re:Inventに参加してきました。

re:Inventは毎年ラスベガスで開催されるAWSの世界最大のカンファレンスで、世界中からエンジニアが集まります。

この期間中、ラスベガスの街全体がre:Inventの会場となり、最新のAWSアップデート情報のリリースや技術セッションの他、EXPO、re:Playパーティー、5K Raceなど様々なアクティビティが用意されています。

本記事では、技術セッションの内容よりも、会場の雰囲気やサブイベント、現地での過ごし方を中心にお伝えします。

技術セッションの内容を中心とした内容は先日投稿した AWS re:Invent 2025 参加レポート - 参加して感じた、AIOpsの本格的な到来に記載しているので、ぜひこちらも合わせて御覧ください。

re:Inventの規模感 - ラスベガスの街が会場に

会場は6つの施設に分散

re:Inventの会場は次の6つに分散しており、それぞれが巨大な施設です。

1. Encore
2. Wynn
3. The Venetian (メイン会場)
4. Caesars Forum
5. MGM Grand
6. Mandalay Bay

上の地図を見ても縮尺がわかりにくいですが、実際に現地で歩いてみると想像以上の距離があります。

メイン会場であるThe VenetianからMGM Grand付近まで実際に歩いてみると約1時間ほどかかりました。

さらに、各会場内も広大で、イベント全体を通じてかなりの距離を歩くことになります。

シャトルバスとモノレールで会場間を移動

会場間の移動手段は、シャトルバスかモノレールが基本です。

シャトルバスもひっきりなしに運行されており、私は期間中ずっとシャトルバスを利用していました。

街中やホテル内の至るところでre:Inventのバッジを付けた参加者とすれ違います。

まさに「ラスベガスの街全体がre:Invent」という雰囲気でした。

多数あるセッションカテゴリ

この複数ある巨大な会場の中で、様々なセッションが同時並行で行われます。セッションの種類は次の通りです。

• Keynote: 基調講演
• Breakout Session: 技術・事例セッション
• Workshop: ハンズオン形式
• Chalk Talk: 小規模なディスカッション形式
• Game Day: チーム対抗の技術チャレンジ

セッション数が膨大なため、見たいセッションを探すだけでも一苦労です。

また、移動時間込みでセッションスケジュールを考える必要があります。

re:Invent 2025 MCP Serverというイベント情報を調査できるMCPもあり、私はこれを利用してスケジュールを組んでいました。

builder.aws.com

Keynoteで発表された新サービスのアップデートに関するセッションは[NEW LAUNCH]という形で新しく登場してきます。

そのため、気になるアップデートがあれば、事前に組んでいたスケジュールから変更したり、柔軟にスケジュールを変えていく必要があります。

私の参加したスケジュールは次の通りです。その他の時間は、会場移動やEXPOへの参加などしていました。

今回は、Keynoteで発表されたDevOpsエージェント関連のワークショップを運よく予約できたこともあり、ObservabilityやAIOps系のセッションが多めの構成になりました。

• Scaling observability with generative AI (ARC311)
• Behind the scenes: How AWS drives operational excellence & reliability (COP415)
• Amazon ECS observability patterns and design decisions (CNS351-R)
• Opening Keynote with Matt Garman (KEY001)
• A deep dive on IAM policy evaluation (SEC402-R1)
• Best practices for cost optimization with AWS Backup (STG328-R)
• The Future of Agentic AI is Here (KEY002)
• Unveiling Amazon ECS workloads with AWS observability and agentic AI (CNS413)
• [NEW LAUNCH] Resolve and prevent future operational issues with AWS DevOps Agent (DVT337-R1)
• Infrastructure Innovations (KEY004)
• A Special Closing Keynote with Dr. Werner Vogels (KEY005)

技術セッションの感想を中心とした内容は先日投稿した AWS re:Invent 2025 参加レポート - 参加して感じた、AIOpsの本格的な到来に記載しているので、こちらもよろしければ御覧ください。

会場の様子

ここからは、セッション以外の会場の様子やサブイベントについての体験談を書いていきたいと思います。

フリードリンクと軽食

各会場の廊下には、コーヒー、ドリンク、サンドイッチ、ドーナツ、バナナなどの軽食がおいてあり、自由に飲食できます。

特に制限もないため、私はここで簡単に朝食を済ませたり、セッション後にコーヒーを入れてホテルに持ち帰ったりしていました。

Meal会場でのビュッフェ

Meal会場ではビュッフェ形式の食事が提供されています。

イベント期間中は軽食とMeal会場の食事が用意されているため、イベント時間中は会場だけで出費なしで食事を賄うことは可能です。

会場や日にちによって出る料理が異なったりしてますが、注意点としてはLunchの時間が11:00 AM ~ 1:00 PMなど食事できる時間が限られていることです。セッションの時間と様子を見てLunchの時間を確保する必要があります。

厳重なセキュリティチェック

各会場の入口には、セキュリティゲートが設置されており、持ち物検査を受ける必要があります。

麻薬検知犬も多く見受けられ、日本のカンファレンスでは体験できない海外イベントならではの厳重さを感じました。

シャトルバスで会場間を移動した際も、別会場の入口でセキュリティチェックを受ける必要があります。

EXPO会場

企業ブース出展会場のEXPOも圧巻の広さでした。

多数の企業が出展しており、Datadogの滑り台やKiroのお化け屋敷など、ユニークな展示もありました。

また、アメリカらしいと感じたのは、ドネーション(寄付)コーナーが設置されているブースで、日本にない文化を感じました。

SWAG

EXPO会場や各ブースでSWAG(ノベルティグッズ)が配られており、Tシャツ、ステッカー、ボトルなど様々なグッズを集めることができます。

SWAGもサプライズ的に配布されたりすることがあり、Xで「〇〇でXXが配られた！」などの情報をみて初めて知るものもありました。

SPORTS FORUM

SPORTS FORUMは、スポーツとテクノロジーを組み合わせたエンタメエリアです。

F1のタイヤ交換ゲーム、バスケのゲーム、VRなど、多彩なアクティビティが用意されていました。

散策しているだけでも楽しめます。

セッション以外のサブイベント

ここからは、re:Inventのサブイベントをご紹介します。

5K Fun Run

イベント期間中に開催される5Kmのマラソンイベントです。

参加して完走すればメダルがもらえます。

6:00 AMから開始され朝早いイベントですが、ラスベガスの道路を走れる貴重な機会なので、体力に余裕があればぜひ参加してみてください。

re:Play

re:Invent後半、クロージングKeynoteの後に開催される公式パーティーがre:Playです。

DJによるライブパフォーマンスが行われ、会場の雰囲気はもはやカンファレンスというより野外フェスそのもの。

40フィート走や、巨大なロボットアームで廃車を持ち上げて落とすという、ユニークなアクティビティも用意されており、締めのエンジョイできる時間でした。

おわりに

技術セッションで最新のAWSサービスを学べたのはもちろんですが、会場の規模感やサブイベントの充実度、そして海外のエンジニアとの交流が、このイベントの大きな魅力だと感じました。

ワークショップで英語を使って会話したり、海外のエンジニアからファインディについてフィードバックをもらったりと、コミュニケーションを取ろうとした経験は貴重なものでした。

もっと技術的なディスカッションができるようになりたいという想いも強くなり、継続して英語を学習していきたいと思っています。

来年以降re:Inventへの参加を検討している方の参考になれば幸いです。

---

ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

AWS re:Invent 2025 参加レポート - 参加して感じた、AIOpsの本格的な到来

この記事は、ファインディエンジニア #1 Advent Calendar 2025の21日目の記事です。 adventar.org

はじめに

こんにちは、ファインディのPlatform開発チームでSREを担当している原（こうじゅん）です。

2025年12月、ラスベガスで開催されたAWS re:Inventに参加してきました。re:InventはAWSが毎年開催する世界最大級のクラウドカンファレンスです。

今年は特にAI Agentを中心とした大きな変化を感じるイベントとなりました。

本記事では、私の体験したセッションを通じて見えてきたインフラ・運用の変化について、AIOps領域に焦点を当てて振り返りを書いていこうと思います。

会場の様子やセッション以外のイベントについてはまた別記事で書いていきます。

re:Invent 2025

re:Inventは、ラスベガスの街全体が会場となる巨大なイベントです。

reinvent.awsevents.com

6つの会場で数多くのセッションが同時並行で開催され、世界中のエンジニアが集まります。

会場間の移動だけでも場所によれば徒歩だと約1時間かかることもあり、シャトルバスやモノレールで移動しながら1週間を過ごすことになります。

セッション以外にもEXPO、re:Playと呼ばれるパーティイベント、5k Raceなど様々なアクティビティが用意されており、まさにAWSの祭典という雰囲気でした。

今年の主要テーマの1つであるFrontier Agents

2025年のre:Inventで印象的だったのは、Frontier Agentsと呼ばれるAIエージェントにまつわる発表です。

Keynoteでは、Kiro Autonomous Agent、AWS DevOps Agent、AWS Security Agent、など、フロンティアエージェントと呼ばれるインフラ・運用領域に直接関わるAIエージェントが次々と発表されました。

これらは単なる「補助ツール」ではなく、「チームメイトとして成果を出すことを期待される存在」として位置づけられています。

その中の1つである私が体験してきたAWS DevOps Agentについて軽く触れていきたいと思います。

AWS DevOps Agentとは

AWS DevOps Agentは、運用チームの「チームメイト」として次のような役割を担います。

• Team Player: アラートやチケットに対応し、Slackなどのコラボレーションチャネルで知見を共有
• Telemetry Expert: メトリクス・ログ・トレースを横断的に分析。DatadogやNew Relicとも連携可能
• Pipeline Pro: GitHubやGitLabと連携して障害につながる変更を特定し、パイプライン改善を提案
• Application Context: アプリ構成やRunbookを理解した上で判断

aws.amazon.com

ワークショップでの体験

実際にDevOps Agentを使ったワークショップである [NEW LAUNCH] Resolve and prevent future operational issues with AWS DevOps Agent に参加し、次のような操作を体験しました。

• 障害発生中のAWSリソースを解析して根本原因を特定
• Dynatraceと連携させてオブザーバビリティデータを統合
• インシデント対応レポートと改善計画の自動生成

エージェントが「インシデントの根本原因を教えてくれる」だけでなく、「改善計画」まで説明してくれる点は、まさにチームメイトのような動きでした。

まだプレビュー版ではありますが、弊社でオブザーバビリティツールとして使用しているDatadogとの連携もできるのでぜひ取り入れていきたいと思いました。

その他の運用・インフラ領域で参考になるセッション

DevOps Agent以外にも、AIOpsに関連する運用・インフラ領域で参考になるセッションがいくつかありました。

Observability × AI

Scaling observability with generative AI (ARC311) では、Kiro CLI Agentを用いた自然言語操作によるオブザーバビリティの自動化が紹介されました。

障害が発生している環境に対して、Kiroがカスタムエージェントで解析した内容をもとにLambdaのコードを書き換えたり、リソース設定を変更したりするデモが印象的でした。

Unveiling Amazon ECS workloads with AWS observability and agentic AI (CNS413) では、ECSワークロードに対して生成AIを活用し、オブザーバビリティデータを自動分析するアプローチが紹介されました。

毎週30億タスクが実行され、新規コンテナ顧客の65%がECSを利用しているという事実を紹介してから、AWSのオブザーバビリティツール全体を整理した上で、ECS上でAIOpsエージェントを構築する際のベストプラクティスが紹介されました。

運用の文化とプラクティス

Behind the scenes: How AWS drives operational excellence & reliability (COP415) では、AWSがグローバル規模で運用をどのように行っているのかが解説されました。

特に印象的だったのは、次のサイクルを継続的に回している点です。

1. Readiness: 障害が起きる前の状態づくり（アラーム、ダッシュボード、Runbook、オンコール体制の整備）
2. Observability: ログ・メトリクス・トレースでの計測、SLOドリブンなモニタリング
3. Incident Response: SOP（標準作業手順書）に従った対応、AIOpsによる障害分析
4. Reviews: 定期的なダッシュボードレビューと改善活動

これらはSREのプラクティスと大きくは変わらないなと思いつつ、改めて運用フローを整理・定義していく重要性を認識しました。

インフラ基盤の進化

Infrastructure Innovations (KEY004) では、Graviton5やLambda Managed Instances、Amazon ConnectのAI対応など、AWSのインフラ技術の進化が語られました。

セキュリティ、可用性、弾力性、コスト、俊敏性といった軸で、どのような思想で設計・進化してきたのかが示されており、基盤レイヤの理解を深めることができました。

IAMポリシーの深掘り

A deep dive on IAM policy evaluation (SEC402-R1) では、IAMポリシーの評価ロジックが詳細に解説されました。

権限評価は単一のポリシーだけで決まるのではなく、Organization → Account → Role → Boundary → Session という複数レイヤをすべて通過して決まります。

また、すべてのPrincipalを対象にしたDenyに条件を付けることで、特定のロールだけを例外として許可するIAMポリシーの書き方なども紹介されており、セキュリティ設計の参考になりました。

AIがインフラ領域に組み込まれている中、ガードレールとしてのポリシーの整備も必要だと感じました。

エンジニアに求められる姿勢

また、クロージングKeynoteで、AWS CTOのWerner Vogels氏が語った言葉が印象に残っています。

「AIは自分の仕事を奪うのか？」という問いに対して、CTOは「多分ね……」と答えつつも、本質的な問いはそこではなく、「AIがあなたを時代遅れにするのか？」であると強調していました。

そして、その答えは、「あなたが進化し続ける限り、断じてノーだ」と。

私たちは今、AIによって時代が大きく動いている震源地に立っています。その中で重要なのは、次の姿勢です。

• Be Curious: 好奇心を持ち続けること
• Think in Systems: 複雑なシステム全体を捉える力
• Communicate: 良いアイデアを明確に伝える力
• Owner: 成果物に対して自ら責任を持つこと
• Polymath: 多才であり、学び続けること

AIはあくまでツールであり、仕事の主体は常に「あなた自身」である。

The work is yours, not the tool's

YOUR CURIOSITY + YOUR SKILLS = WORLD-CHANGING

このメッセージは、re:Inventの締めとしてとても印象に残りました。

おわりに

4日間のイベントを通して、技術的な知見が広がり、刺激的で濃い時間を過ごすことができました。

2026年は、AIOpsが本格的に実務に組み込まれていく年になると感じ、ファインディのPlatform開発チームでもよりAIOpsを組み込んでいく体制づくりを行っていければと思います。

---

ファインディでは一緒に働くメンバーを募集中です！
よかったら覗いてみてください。 herp.careers

Findy AI+の開発・運用を支えるMCP活用事例 ― AI Engineering Summit Tokyo 2025登壇レポート

こんにちは。

ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。

現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。

GitHub CopilotやClaude Codeなど、生成AIを活用した開発支援ツールが次々と登場し、日常的なワークフローに組み込まれつつあります。

そんな中で先日、弊社主催でAI Engineering Summit Tokyo 2025が開催され、「Findy AI+の開発、運用におけるMCP活用事例」と題しまして登壇してきました。

ai-engineering-summit-tokyo.findy-tools.io

そこで今回は、登壇資料を元に、Findy AI+の開発でどのようにMCPを活用したか、その選択の背景と効果を振り返っていきます。特に、MVPでのリモートMCPサーバー活用と、Admin機能でのMCPサーバー実装という2つの事例から、MCPの実践的な活用パターンをお伝えします。

それでは見ていきましょう！

MCPとは

MCP（Model Context Protocol）は、アプリケーションが大規模言語モデル（LLM）に情報やツールへのアクセス方法を提供する、新しいオープンプロトコルです。

USB-Cが様々なデバイスを標準的な方法で接続するように、MCPはAIモデルを多様なデータソースやツールへつなぐための、標準化された方法を提供します。

詳しくは次の公式ドキュメントをご覧ください。

modelcontextprotocol.io

また先日、MCPがLinux Foundation傘下に新設されたAgentic AI Foundation (AAIF)に寄贈されるというニュースが発表されました。

www.anthropic.com

これにより、ベンダーに依存しない中立的な技術として管理されることになります、また、長期的な安定性と互換性が保証され、より安全に採用できる技術となるでしょう。まさに業界にとって不可欠な共有インフラとしての地位を確立しようとしていると言えるでしょう。

Findy AI+

Findy AI+はGitHub連携・プロンプト指示で生成AIアクティビティを可視化し、生成AIの利活用向上を支援するサービスです。

生成AIやAIエージェントを活用するうえでの組織、個人の課題を解決するために開発されました。

jp.ai-plus.findy.io

アルファ版: リモートMCPサーバーでの提供

まずこのプロダクトのニーズが一定以上あるかどうか検証するためにMVPでアルファ版の開発を行いました。

この時、アルファ版ではリモートMCPサーバーでのサービス提供を実現しています。

リモートMCPサーバーで提供することで、画面を実装する工数をカットすることが出来た上、分析や解析をクライアント側のLLMに任せることが出来たため、エンジニア2人で1ヶ月程度での開発を実現することに成功しました。

リモートMCPサーバーの役割は、必要な情報を外部APIから取得して、LLMが分析しやすい形に加工して返すことです。

分析そのものはクライアントから接続しているLLMに任せます。 そのため、実行するプロンプトによって出力結果にバラつきが出ることを防ぐために、MCPサーバーからプロンプトを動的に生成して返す機能までを実装しました。

リモートMCPサーバーの詳細は別記事を参照すると、より理解が深まるかと思います。

tech.findy.co.jp

ベータ版: チャットUIとMCP活用のAdmin機能

アルファ版の提供により一定以上のニーズを確認出来たため、次にベータ版として画面UIからのチャット形式のインターフェースを提供することになりました。

更にサービス全体を管理するためのAdmin機能が必要となりました。そこでAdmin機能を画面UIではなく、ローカルMCPサーバーとして実装することにしました。Admin機能は管理者のみが使用し、利用頻度も高くないため、画面UIを作るよりもMCPで柔軟に操作できる方が効率的と判断しました。

MCPサーバーのtoolからバックエンドのサーバーのAdmin機能用のREST APIを実行してデータを取得して返すだけのシンプルな構成です。また、Admin機能用のAPIとユーザー側の機能用のAPIのendpointと認証を分けることで、セキュリティ面も考慮しています。

結果的に、画面ベースで開発した場合の見積もりが約1ヶ月程度の工数であったのに対し、MCPサーバーとして実装したことで約1週間程度の工数で実装が完了しました。

Admin機能を提供するMCPサーバーについては別記事を参照すると、より理解が深まるかと思います。

tech.findy.co.jp

まとめ

MCPの登場により、開発効率を上げるだけではなくデータへのアクセス手段の選択肢が広がりました。 今回のFindy AI+の事例では、MVP開発でリモートMCPサーバーを活用することで開発期間を大幅に短縮し、Admin機能ではMCPサーバーとして実装することで画面UIの開発工数を削減できました。それにより、価値提供の方法も変わってきています。

また、LLMや生成AIツールが変わっても、MCPはLLMや生成AIツールを選ばずに接続が出来ます。これにより長く使える知識、技術となっています。

ファインディは早期にMCPの検証を開始して、積み重ねを継続して、実用化にたどり着くことができました。

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓
herp.careers

ECS Express Modeはインフラ構築をどこまで楽にしてくれるのか

はじめに

みなさんこんにちは。Platform 開発チーム SREでサブマネージャーの安達（@adachin0817）です。この記事は、ファインディエンジニア Advent Calendar 2025の18日目の記事です。今回はECS Express Modeをスピーディーに試してみたので、使ってみて分かったメリット・デメリットを中心にまとめていきたいと思います。

adventar.org

ECS Express Modeとは

• https://aws.amazon.com/jp/blogs/news/build-production-ready-applications-without-infrastructure-complexity-using-amazon-ecs-express-mode/

従来のECSを用いたインフラ構築では、ECSクラスターやタスク定義、サービスだけでなく、ロードバランサー、ターゲットグループ、セキュリティグループ、オートスケーリングなど、多数のリソースを個別に定義・管理する手間がありました。

公式ドキュメントによるとECS Express ModeはAPIを通じて、インフラのセットアップを全て、自動化できるようになりました。これにより、アプリケーション開発に集中できる環境を実現し、Amazon ECSを含む各リソースを設定できるため、必須項目はコンテナイメージのみで、シンプルさとスピードを飛躍的に向上させています。

• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_express_gateway_service

Terraformではaws_ecs_express_gateway_serviceリソースが提供されているため、こちらを使って一連の流れを実装していきます。

Terraform

terraform.tf

ECS Express Modeは、Terraform AWS Providerのバージョン6.23から利用できるようになります。

terraform {
  required_version = ">= 1.14.2"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 6.26.0"
    }

  }

  cloud {
    organization = "hoge"

    workspaces {
      name = "hoge-ecs"
    }
  }
}

iam.tf

ECS Express Modeでは、主に2つのIAM ロールが必要になります。Task Execution Roleは、コンテナイメージのpullやCloudWatch Logsへの書き込みに使用され、Infrastructure Roleは、ECS Express Modeが各種リソースを作成・管理するために使用されます。

resource "aws_iam_role" "ecs_task_execution_role" {
  name = "test-service-task-execution-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "ecs-tasks.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ecs_task_execution_role_policy" {
  role       = aws_iam_role.ecs_task_execution_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}

resource "aws_iam_role" "ecs_infrastructure_role" {
  name = "test-service-infrastructure-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "AllowAccessInfrastructureForECSExpressServices"
      Effect    = "Allow"
      Principal = { Service = "ecs.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ecs_infrastructure_role_policy" {
  role       = aws_iam_role.ecs_infrastructure_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRoleforExpressGatewayServices"
}

ecs.tf

ECS Express Modeでは、中心となるリソースであるaws_ecs_express_gateway_serviceを通じて各種設定を制御します。ECSクラスター自体は別途定義する必要がありますが、サービス側ではコンテナイメージ指定（今回はNginx）、ログ設定、事前に作成したIAM ロール、ネットワーク、CPU・メモリ、スケーリング設定などをまとめて指定します。

ロードバランサーについては ALBとターゲットグループが自動的に作成・管理され、ACM証明書も自動発行される仕様となっていました。また、セキュリティグループもExpress Mode側で自動生成・管理されるため、Terraform側では差分検知を防ぐために、ignore_changesを指定する必要がありました。

※ネットワークはデフォルトVPCを参照しています。

resource "aws_ecs_cluster" "main" {
  name = var.cluster_name
}

resource "aws_ecs_express_gateway_service" "main" {
  cluster      = var.cluster_name
  service_name = var.service_name

  primary_container {
    image          = var.container_image
    container_port = var.container_port
    command        = var.command

    aws_logs_configuration {
      log_group         = aws_cloudwatch_log_group.ecs_service.name
      log_stream_prefix = var.service_name
    }
  }

  execution_role_arn      = aws_iam_role.ecs_task_execution_role.arn
  infrastructure_role_arn = aws_iam_role.ecs_infrastructure_role.arn

  network_configuration {
    subnets         = toset(["subnet-xxxxxx", "subnet-xxxxxx"])
    security_groups = toset([aws_security_group.tests_service.id])
  }

  cpu    = tostring(var.cpu)
  memory = tostring(var.memory)

  scaling_target {
    min_task_count            = var.min_capacity
    max_task_count            = var.max_capacity
    auto_scaling_metric       = "AVERAGE_CPU"
    auto_scaling_target_value = 60
  }

  health_check_path = var.health_check_path

  lifecycle {
    ignore_changes = [
      network_configuration[0].security_groups
    ]
  }
}

variables.tf

variable "cluster_name" {
  type        = string
  description = "The name of the ECS cluster"
  default     = "hoge-cluster"
}

variable "service_name" {
  type        = string
  description = "The name of the service"
  default     = "hoge-service"
}

variable "log_group" {
  type        = string
  description = "The name of the CloudWatch log group"
  default     = "/ecs/hoge-service"
}

variable "container_image" {
  type        = string
  description = "The container image to use for the service"
  default     = "nginx:latest"
}

variable "container_port" {
  type        = number
  description = "The port that the container listens on"
  default     = 80
}

variable "command" {
  type        = list(string)
  description = "The command to run in the container"
  default     = ["nginx", "-g", "daemon off;"]
}

variable "cpu" {
  type        = number
  description = "The number of CPU units to allocate"
  default     = 256
}

variable "memory" {
  type        = number
  description = "The amount of memory (in MiB) to allocate"
  default     = 512
}

variable "min_capacity" {
  type        = number
  description = "Minimum number of tasks"
  default     = 1
}

variable "max_capacity" {
  type        = number
  description = "Maximum number of tasks"
  default     = 10
}

variable "health_check_path" {
  type        = string
  description = "The path for health checks"
  default     = "/"
}

Deploy

デプロイはECSビルトインデプロイであるカナリアデプロイとなっており、アプリケーションURLにHTTPSでアクセスできるようになりました。

❯❯ curl -I https://xxx.ecs.ap-northeast-1.on.aws
HTTP/2 200 
server: nginx
date: Tue, 16 Dec 2025 02:30:25 GMT
content-type: text/html; charset=utf-8
content-length: 14
x-powered-by: Express

削除の挙動と懸念点について

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-delete-task.html

• The Amazon ECS cluster (if no other services are running)
• The Amazon ECS service, task definition, and any running tasks
• Service security group
• CloudWatch log group
• Metric alarm
• ACM Certificate
• The Application Load Balancer (if no other services are configured), target group, security group, listener, and listener rule
• Amazon EC2 Auto Scaling policy, scalable target

削除の挙動については、Terraformでdestroyを実行すればExpress Mode管理下のリソースがすべて削除される想定でした。しかし、実際にはALBやターゲットグループ、ACMが残存し、その後に手動削除と再apply を行った結果、同一サービス名のECSサービスがDraining 状態のままとなり、再作成できない問題に直面しました。

╷
│ Error: creating ECS (Elastic Container) Express Gateway Service
│ 
│   with aws_ecs_express_gateway_service.main,
│   on ecs.tf line 5, in resource "aws_ecs_express_gateway_service" "main":
│    5: resource "aws_ecs_express_gateway_service" "main" {
│ 
│ ID: "hoge-service"
│ Cause: operation error ECS: CreateExpressGatewayService, ,
│ InvalidParameterException: Unable to Start a service that is still Draining."

クラスター名を変更して再度applyし直したところ、applyは完了するものの、ロードバランサーが作成されない状態となりました。その結果、存在しないセキュリティグループを参照したままサービスが起動できず、結果としてサービスがデプロイされないままタイムアウトしない事象が発生しました。この挙動から、Terraformでの削除・再作成は、現時点で課題が残っていると感じています。

まとめ

ECS Express Modeは、App Runnerと比べても、インフラ構築の複雑さを大きく減らし、アプリケーションエンジニアでも素早く環境を立ち上げ、開発に集中できる体験を提供してくれる仕組みだと感じました。一方で、Terraformを前提とした運用ではまだ課題が残る印象もありますが、Platform SRE チームがこれまで整備してきた汎用モジュールの一部を、将来的に置き換えられる可能性も感じています。

今後はAWSサポートとも連携しながら挙動の整理を進め、どのユースケースで安全に使えるのかを見極めつつ、実運用に耐えうる形へ落とし込んでいく予定です。

最後まで、読んでいただきありがとうございました！

herp.careers

アウトプットで学ぶ。チームでAIをキャッチアップする10分勉強会

こんにちは。 Findy Freelanceの開発チームでEMをしている中坪です。 この記事は、ファインディエンジニア Advent Calendar 2025の18日目の記事になります。

adventar.org

日々進化するAIや関連ツールをキャッチアップし、実務に活用することに苦労しているエンジニアの方も多いのではないでしょうか。

私たちは、チームでAIツールのキャッチアップを行う取り組みとして「10分勉強会」を実施しています。 本記事では、その取り組み内容について紹介します。

10分勉強会とは

発表者が5分間で学んだことを発表し、残り5分で質疑応答を行う形式の勉強会です。

この勉強会の目的は次の3つです。

• メンバーが学んだことをチームメンバーに共有する機会を作る
• 発表からその人の仕事、興味、課題などを知り、相互理解を深める
• アウトプットのハードルを下げ、アウトプットの習慣をつける

Findy Freelance開発チームでは、週に2回、10分勉強会を実施しています。 1回につき1名が発表し、ローテーションで全員が発表する形をとっています。

2024年の2月頃に開始し、継続しています。

2025年1月以降は、基本テーマを「生成AI活用」に設定し、変化の激しいAIツールのキャッチアップに焦点を当てています。

過去の発表内容の一部です。

発表内容の例

過去の発表内容の例をいくつか簡単に紹介します。

1. Sentry MCPとLog Analyzer with MCPを使った不具合調査

AWSが提供するLog Analyzer with MCPを使った不具合調査の方法を紹介しました。 このMCPはCloudWatch Logsの検索と分析を行うことができ、Sentry MCPと組み合わせることで、エラーの概要と詳細なログを横断的に調査できます。

Sentryでエラーの概要を把握し、CloudWatch Logsで詳細なログを確認することで、Claude Code上で一貫した調査が可能になり、エラーの根本原因を効率的に特定できた事例が紹介されました。

2. Gemini Canvasを使ったUIモックの作成と社内共有

仕様検討時にUIイメージを共有する方法として、Gemini Canvasの活用事例が紹介されました。 Geminiのチャット欄でCanvas機能を有効化し、既存画面のキャプチャと簡単なプロンプトを渡すだけで、動きのあるUIモックを作成できます。

生成されたHTMLをGoogle Apps Scriptにデプロイし、公開範囲を組織内に限定することで、社内のGoogleアカウントを持つメンバーだけがアクセスできるURLとして共有できます。

静的なキャプチャでは伝わりにくいインタラクションも、実際に動かせるモックを使うことで、仕様の認識合わせを効率的に進められた事例が紹介されました。 V0のような専用ツールと比べて、ファインディの社内で導入されている標準ツールで利用できる点が利点です。

3. Git Worktree Runnerの紹介

CodeRabbitが公開しているGit Worktree Runner (GTR)を使った開発効率化の事例が紹介されました。 このツールは、Git worktreeの作成と管理を簡単にし、AIツールとの連携をスムーズにします。

コマンド一つでworktreeとブランチを同時に作成でき、エディター(VS CodeやCursorなど)やAI CLIツール(Claude Codeなど)の起動も自動化できます。 フック機能により、worktree作成時にnpm ciなどの初期化コマンドを自動実行できるため、ブランチを切り替えてすぐに開発を始められる環境が整います。

git worktreeの導入ハードルを下げ、複数のタスクを並行して進めやすくするツールとして活用事例が共有されました。

持続するための工夫

10分勉強会がメインとなる開発業務の妨げにならず、継続的に実施するために、次のような工夫をしています。

発表のスキップを許容する

業務が忙しい時期や準備が間に合わない場合は、当日開催前までに周知すればスキップできるようにしています。

基本的には開発業務を優先し、発表者が自身の負荷状況を考慮して調整できる運用にすることで、無理なく続けられる仕組みにしています。

発表資料は任意

発表資料の作成は必須ではありません。 Notionに簡単にまとめるだけでも良いですし、実際の操作を画面共有しながら説明する形でも、誰かの書いたブログ記事を紹介する形でもOKにしています。 資料作成のハードルを下げることで、発表しやすい環境を作っています。

厳密ではないテーマ設定

基本テーマは設けつつ、テーマ以外の内容でも発表可能にしています。

業務での取り組み、ドメイン知識の共有、最近読んだ技術書の紹介など、特にチームに共有したいことなどがあれば、テーマ外でも発表可能です。

チーム内で開催する

ファインディのエンジニア組織全体ではなく、Findy Freelance 開発チーム内で開催しています。

チーム内であれば、Findy Freelance固有のプロダクトや事業やドメイン知識に関する内容も共有しやすく、実務に直結した内容を扱いやすいです。

全体開催に比べると、対象者が限定されており、一定の前提知識も揃っているため、発表者もテーマ設定や内容を考えやすいと考えています。

開催時間を短くする

オープン、クローズを含めて15分程度で会が終わるようにしています。

チームメンバー全員参加であっても、15分程度であれば業務の時間を大きく割くことなく参加しやすいと考えています。

効果と反響

チームメンバーの声

チームメンバーにアンケートを実施したところ、次のような声がありました。

AIキャッチアップの助けになっていたり、発表内容が実務に役に立っていることがわかりました。

良かった点: 色々MCPを知ることができたこと。Claude Codeの使い方を知ることができたこと。

---

AIのキャッチアップは大変なので知らなかった変更や知見を知れた

---

CloudWatch Logsの検索mcpはかなりの頻度で利用しています

---

自身が仕様検討する機会が多く、認識合わせのためのUIモックが必要だと感じている中でGemini Canvasを用いた画面モックの発表があり、すぐに仕様のすり合わせで活用することができた。

また、5段階評価で「生成AIのキャッチアップに役立ちましたか？」という質問に対しては、平均4.4点という高評価を得られました。

チームAI活用率

勉強会だけの効果とは言い切れませんが、Findy Freelance開発チームではAIツールの活用率は高い値を維持しています。

Findy Team+のAI活用レポートをみると、2025/09/16 - 2025/12/15の期間のAI利用者率は100%、AI利用プルリクの割合も70%を超えています。

単月でみると、最も高い月で10月のAI利用プルリク割合は約90%に達しています。

アンケートの反応なども合わせて考えると、10分勉強会がAI活用の促進に一定寄与していると捉えています。

メリット

アウトプットによる知識の定着

人に説明することで、自分の理解が深まり、知識が定着しやすくなります。 自分ではわかっているつもりが、発表しようとすると、理解が不十分な部分に気づくことがあります。

そこを調べたり、説明の仕方を考えたりすることで、より深い理解につながります。 この勉強会において、一番恩恵を受けるのは発表者自身だと感じています。

AIのキャッチアップをチームで取り組める

AIや関連ツールは日々進化しており、個人でキャッチアップするのは大変です。 一方で、新しいものがでてきたときに、少し触ってみる、試してみるということも重要だと考えています。 触ってみないと実際にそのツールがどのように役立つかを理解するのは難しいからです。

勉強会を通じて、他のメンバーが試したツールや活用事例を知ることで、個人のキャッチアップの負荷を軽減することができると感じています。 週2回という頻度も、変化の激しいAIツールのキャッチアップには適していると考えています。

聞いた内容をすぐに試せる

前述の通り、チーム内で実施しているため、発表内容が実務に直結しやすいです。 また、導入されているツールや対象とするシステムや環境が共通していることも多いため、発表を聞いた後にすぐに試してみることができます。

例えば、普段開発しているリポジトリにClaude Codeのカスタムコマンドを導入したという発表があった場合、他のメンバーにとっても普段さわっているリポジトリになるため、すぐに試してみることができます。 環境構築の手間も少なく、マージ済みであれば、勉強会を聞きながらその場で試すことすら容易です。

デメリット

体系的に学びたい場合や、基礎を固めたい場合には向いていないと考えています。 テーマは発表者が自由に選べるため、どんな内容が発表されるかは事前にはわかりません。 特定のトピックスに偏る可能性もありえます。また、深い内容を扱うには5分では時間がたりません。

Findy Freelance開発チームでは、現状ではミドル以上のエンジニアが中心の構成になっているため、自主性に一定の期待ができることもあり、この形式が機能していると考えています。

余談と「うちのAIがやらかしまして」の紹介

余談になりますが、10分勉強会では、試してみたけどうまくいかなかった事例も共有されることがあります。

また、AIの進化が早すぎて、発表した内容が古くなってしまったり、バージョンアップにより使えなくなったりすることもありました。

この記事を読んでくれている方の中にも、AIがうまく動いてくれなかった経験がある方がいると思います。

現在、Findyでは「うちのAIがやらかしまして」というAIを使ったときのちょっと笑えるやらかし体験をシェアする期間限定企画を実施中です。

ちなみにですが、私はこの投稿が好きです。

実際に体験がある方はぜひシェアいただけると嬉しいです!

他の方の投稿をみるだけでも面白いと思いますので、ぜひのぞいてみてください!

おわりに

Findy Freelance開発チームでは、10分勉強会を通じて、変化の激しいAIツールのキャッチアップをチームで取り組んでいます。 2025年は生成AI活用に焦点を当てて取り組んでおり、チームメンバーからも好評を得ています。

これは今のチーム構成や文化に合っているからこそ機能している面もあると考えています。 継続することが目的ではなく、チームの構成や人数や課題に応じて、勉強会の形式や実施するかどうか振り返ることも重要です。

ただ、どのような形式であれ、変化の激しいAIの進化をチームで協力しつつ、楽しみながらキャッチアップすることは継続していきたいと考えています。

ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers

【Claude】Pluginsで簡単横展開 - 開発手法の標準化 -

こんにちは。

ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。

この記事は、ファインディエンジニア #1 Advent Calendar 2025の17日目の記事です。

adventar.org

現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。

GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。

そんな中で先日、Claude Codeの新機能であるPluginsが公開されました。

そこで今回は、Pluginsの紹介と解説、作り方と利用方法を紹介したいと思います。

それでは見ていきましょう！

Pluginsとは

PluginsはCustom slash commands, Subagents, Hooks, Agent Skills、MCPサーバーを使用してClaude Codeを拡張できる便利な機能となっています。

また、marketplacesからPluginsをインストールして、事前に構築されたCustom slash commands, Subagents, Hooks, Agent Skills、MCPサーバーを利用できるようにもなります。

code.claude.com

一言で言うと、Claude Codeの各種設定や機能をPluginsとして事前に用意しておき、それらを簡単に横展開できるようにした仕組みです。

開発組織やチーム間で、開発手法やワークフローを標準化するのに非常に役立ちます。

作り方

必要なファイルと、展開したい各種Claude Codeの設定ファイルなどを用意するだけでPluginsを作成できます。

まずPluginsを管理するための新しいリポジトリをGitHub上に作成します。作成したリポジトリをLocal環境にcloneしましょう。今回は TestOrg/DevPlugins というリポジトリを作成したとします。

次にリポジトリのrootに .claude-plugin というディレクトリを作成し、その中に marketplace.json というファイルを新規で作成します。

{
  "name": "DevPlugins",
  "owner": {
    "name": "TestOrg Inc."
  },
  "plugins": [
    {
      "name": "development-plugin",
      "source": "./development-plugin",
      "description": "Development plugin for TestOrg Inc."
    }
  ]
}

次にリポジトリのrootに development-plugin/.claude-plugin というディレクトリを作成し、その中に plugin.json というファイルを新規で作成します。

{
  "name": "development-plugins",
  "description": "Development plugins for TestOrg",
  "version": "0.0.1",
  "author": {
    "name": "TestOrg Inc."
  }
}

これで DevPlugins というmarketplaceに development-plugin というPluginsが作成されました。

ここまで用意できれば、あとは展開したい各種Claude Codeの設定ファイルを development-plugin ディレクトリ以下に配置していくだけです。今回はCustom slash commandsを追加します。

---
description: Greet the user with a personalized message
---

# Hello Command

Greet the user warmly and ask how you can help them today. Make the greeting personal and encouraging.

全体の最小構成は次のようになります。

DevPlugins/
├── .claude-plugin/
│   └── marketplace.json
└── development-plugin/
  ├── .claude-plugin/
  │   └── plugin.json
  └── commands/
    └── hello.md

作成したファイルをGitHubのデフォルトブランチに push すれば Plugins の作成と展開は完了です。marketplace と Plugins の設定ファイルを作成し、展開したい各種Claude Codeの設定ファイルを配置するだけでシンプルに構築できることが分かると思います。

利用方法

作成したPluginsを利用する方法を説明します。

まずPluginsの登録先を追加します。Claudeのコンソールに入って、次のコマンドを実行します。

> /plugin marketplace add TestOrg/DevPlugins 

このコマンドにより、GitHub上のリポジトリをmarketplaceとして登録します。

次に、作成したPluginsを実際にインストールします。続いて次のコマンドを実行します。

> /plugin install development-plugin@DevPlugins

実行すると次のような出力が表示されるので Install now を選択します。

╭────────────────────────────────────────────────────────────╮
│ Plugin Details                                             │
│                                                            │
│ development-plugin                                         │
│                                                            │
│ Development plugin for TestOrg Inc.                        │
│                                                            │
│ Will install:                                              │
│ • Components will be discovered at installation            │
│                                                            │
│ > Install now                                              │
│   Back to plugin list                                      │
╰────────────────────────────────────────────────────────────╯

インストールが成功すると ✓ Installed development-plugin. Restart Claude Code to load new plugins. と表示されるので、Claude Codeを再起動します。

再起動すると、インストールしたPluginsが利用可能になります。実際に利用するには、次のようにコマンドを実行します。

> /development-plugin:hello

実行すると次のような出力が表示されました。Pluginsを正しくインストール出来たことが確認できます。

⏺ Hello! 👋 Welcome to DevPlugins

  I'm Claude Code, and I'm here to help you with anything related to this
  project. Whether you need to:

  - 🚀 Set up the development environment
  - 🔧 Build new features or fix bugs
  - 🧪 Write or run tests
  - 📊 Work with the database or migrations
  - 🤖 Integrate with Claude AI or GitHub APIs
  - 📝 Review code or create pull requests

  I'm ready to assist! I have full context of the project structure, authentication
  patterns, service architecture, and best practices for this codebase.

  What would you like to work on today?

まとめ

Pluginsを利用することで、開発組織やチーム間で開発手法やワークフローを簡単に標準化できるようになります。

弊社ではClaude Codeの共通の設定を自動で設定するCustom slash commandsや、Pull requestを作成するAgent Skillsなどを作成して開発組織全体に展開し、開発効率の向上に役立てています。実際に作成した Plugins の具体例紹介は、別の機会で改めてまとめたいと思います。

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓ herp.careers

Geminiを壁打ち役に迎えて、チームのミッション・ビジョンを定義しました

こんにちは、CTO室データソリューションチームでマネージャーをしている 開（hiracky16） です。

この記事は、ファインディエンジニア #1 Advent Calendar 2025の14日目の記事です。

adventar.org

先日、チームで半日ほど時間をとってワークショップ（オフサイトミーティング）を実施しました。今回は、そのプロセスの中で「生成AI（Gemini）をファシリテーター兼、壁打ち役として参加させる」という試みを行った話と、そこで決まった私たちの新しいミッション・ビジョンについて書きたいと思います。

データソリューションチームについて紹介

我々のチーム、データソリューションチームについて少し紹介すると現在は職能で言うとデータエンジニアのみが所属するチームで、現チーム体制になって約1年半が経過しました。横断組織でもあるため特定の事業の仕事に取り組むのではなく全事業のデータ活用に関する依頼に対応しながらデータ基盤を作っています。もともとはデータサイエンティストと一緒のチームでしたが、組織変更を経て、データサイエンティストやデータアナリストは事業部の方に所属となり今の形となりました。ファインディのエンジニアチームの構成は次のような形です。

ワークショップ開催の経緯

日々の業務としては、各部署のデータアナリストやサイエンティストの支援をしたり、データ活用の悩みを解決したり、全社横断の検索エージェント基盤を作ったり様々です。しかし、1年半走ってくる中で、マネージャーである私自身の中に、ある種の「モヤモヤ」が溜まっていました。

優先順位の悩ましさ

ファインディでは4事業を展開している中で、事業ごとにデータ関連の仕事の相談を受けます。横断組織として複数の事業に関わる一方で、限られた人数の中で取り組むテーマに優先順位をつけながら進めています。さらに新規事業やプロダクトも控えており、今後は関わる事業やプロダクト、仕事の幅が広がる中で、より丁寧な判断が求められる場面も増えていくと考えています。

「具体的な」データ・AI戦略の言語化

優先順位に迷いながらでも現場は回っている状況ではある中で、中長期的な指針がより明確になることで、チームが同じ目的をこれまで以上に共有しやすくなると考えています。また普段は単一の事業やチームに最適な取り組みをするとよいことが多いですが、「ファインディとして」どうあるべきか？という全社視点をあらためて意識することの重要性も感じています。

データエンジニアの役割変化

生成AIの台頭により、これまでの「基盤を作って終わり」というスタイルに加えて、よりビジネス価値に踏み込んだ関わり方が求められるようになってきました。ファインディ主催のカンファレンス「Data Engineering Summit 2025」でも他社の事例を見聞きする中で、データエンジニアやデータ基盤の役割が変わりつつあることを改めて実感しました。自分がモデレーターを務めた「サイロ化解消のその先へ。ビジネス/データ、それぞれの視点で語るRevOps」というセッションでも、RevOpsという領域におけるデータエンジニアの新しい役割やキャリアについて話すことができました。

そんな危機感を感じ、チーム全員で一度立ち止まり、自分たちのミッションやビジョンを見直すタイミングだと思いました。ただ、私ひとりが悩んで決めたトップダウンの指針では十分ではありません。メンバー全員が腹落ちし、意欲的に働くための指針を作ること──それが今回のワークショップの目的でした。

準備

ワークショップを企画するにあたり、今回はGeminiを活用しました。

私自身過去ワークショップに参加したことはありましたが、主催するのは初めてです。準備や進行の面でうまくできるか不安がありました。また当時、課題感は言語化できていない曖昧な状態でした。

そこで、今回は次のようなフローで準備を進めました。

1. 音声入力でひたすら喋る：現状の課題、チームの歴史、私の悩みなどを、脈絡なく音声入力でテキスト化
2. Geminiに投げ込む：その長文テキストをGeminiに渡し、「これらのコンテキストを踏まえて、半日のワークショップのアジェンダと、各パートの狙いを設計して」と依頼
3. 壁打ちしてブラッシュアップ：Geminiから返ってきた案に対し、「ここはもっと発散させたい」「ここは収束させたい」と対話し、スライドの骨子を作成

結果、課題の言語化にも成功しましたし、ワークショップの準備も比較的時間をかけずに終えられたと思います。

実施

当日は、会議室を半日貸し切って付箋を使いながらワークを行いました。

1. 情報のインプット

役職や社歴に問わず文脈を共有した上でワークに入れるように情報のインプットパートを設けました。まずは開催に至った経緯を丁寧にメンバーに説明し、私が抱いた悩みをメンバーも感じているのかの確認やメンバー間で違和感や課題感を揃えるところから始めました。また入社時期もバラバラで、直近だと3ヶ月前に入社したメンバーもいたのでチームの成り立ちから現状に至るまでの歴史を振り返りました。次に会社や部署の指針やミッションをスライドに記述することで会社から求められていることを意識して話し合いできるようにしました。

「生成AIの進化によるデータエンジニアやデータ基盤に求められる役割」をDeep Researchでまとめてもらい、それらを斜め読みする時間も設けました。社内の仕事だけしていると個社最適なスキルになりがちなので、世の中一般的なデータエンジニアリングのスキルと比較しながら議論しました。以下Deep Researchの結果を簡単にまとめてもらったものです。

2. 存在意義のワーク：「もし自分たちが1年いなかったら？」

まず取り組んだのが、「もし私たちのチームが存在しなくて、過去1年間不在だったら会社はどうなるか？」という思考実験です。

「データ連携が止まって、数字がズレる」や「誰もデータ基盤のメンテナンスをしなくなって、コストが爆増やセキュリティへの対応が遅れる」といったリアルな痛みから、「ツールが統一できずに情報やノウハウが分断される」といった機会損失まで様々なことが考えられました。このワークを通して我々のチームが会社や他のチームから求められていること、つまりミッションを考える上での重要な要素を洗い出すことができました。

3. Will/Can/Mustでビジョンを描く

次に、3年後の未来像を「Will/Can/Must」のフレームワークで言語化しました。メンバー個々人のキャリア上のWillと会社のビジョンである「挑戦するエンジニアのプラットフォームをつくる。」とが重なる部分を見出してチームのビジョンにしたいと思いこのワークを実施しました。

以下私が書いたことを例です。

- Can（できること）
  - データエンジニアリングと Google Cloud チョットデキル
  - 採用活動
- Must（すべきこと）
  - A事業部のデータ基盤開発、運用
  - マネージャーとしての調整業務
- Will（やりたいこと）
  - 全社のデータ活用を伴走し売上に貢献できるデータエンジニアになる

他のメンバーにも同じように書いてもらい、まずはメンバー間で一緒にできそうなことはないか探りました。そうすると「価値のあるデータ」や「売上に貢献できる」というエッセンスが得られました。

4. ミッション・ビジョンを考える

最終的に決まったミッションとバリューがこちらです。

Mission: 「データとエンジニアリングの力で、ファインディの知恵を結集し、意思決定を加速させる」

Vision: 「事業成長に並走できるデータxAI基盤を作る」

1~3のステップで得られた意見を元にチームでミッション・ビジョンを考えました。内容をGoogleスライドに書き込みながら進めていたためGeminiにそのまま添付し、ミッション・ビジョンの案を3つずつ考えてもらいました。あらかじめ4つの基準を考えており、「情熱が持てるか？」「会社のミッションと関連性はあるか？」「他のチームと比べてオリジナリティがあるか？」「シンプルで覚えやすいか？」をメンバーの主観で点数化しながら最終的に1つに決めました。

最後に言葉選びを我々のチームやファインディっぽく変更しました。例えば、会社のバリューに関連するワード「加速（スピード）」や「並走（チームワーク）」を使いました。「集結させる」のか「結集させる」のかで悩んだ際に「結集」には「力を合わせる」という意味合いがあるらしく採用しました。

振り返りとこれからの話

ワークショップを通じて、認識が揃ったことはもちろんですが、Geminiを議論に混ぜることで、より客観的にミッションやバリューを作る上で機能したことの気づきがありました。ある程度コンテキストを与えていたところはありますが、Geminiはより深い事情を知っているチームメンバーよりもいい意味で違った視点の意見を出してくれることが多かったです。またDeep Researchの結果を使って現代のデータエンジニア像をインプットできたのは客観的な視点で情報をまとめてくれたおかげです。

もちろん、Geminiは優秀な壁打ち相手でしたが、AIに頼り切るだけでは「メンバー全員が腹落ちし、意欲的に働くための指針を作る」という部分は達成できなかったように思います。最後に自分たちの手で細かい微調整をし、想いを込めていくプロセスこそが、今回のワークショップで必要だった作業だとわかりました。結果として、会社から求められていること（Mission）と、チームが成し遂げたいこと（Vision）が繋がり、「自分たちの言葉で決めた」という強い納得感のある指針が生まれました。

私たちデータソリューションチームはこの新しいミッション・ビジョンのもと、生成AI時代の新しいデータ基盤づくりに挑戦していきます。ファインディやデータソリューションチームのミッションに共感し、一緒にビジョンを叶えたい方、や我々チームの取り組みに興味を持ってくださった方はぜひ一度カジュアル面談でお話ししましょう！

herp.careers