こんにちは。ファインディのTeam+開発部でエンジニアをしている古田（ryu-furuta）です。 この記事は、 ファインディエンジニア #2 Advent Calendar 2025 の22日目の記事です。 はじめに 2025年下期、私は「DevとOpsを融合する」というミッションを掲げ、問い合わせやアラートといった運用業務の改善にAIをいくつか活用していきました。 この記事では、Claude Code GitHub ActionsやNotion MCPを使った運用業務改善の具体的な実装方法を紹介します。 また、効率化を実現した先に見えてきた「次にやるべきこと」についても共有します。 AIを活用した運用改善を検討している方や、改善施策を打っても成果が出ないと悩んでいる方に読んでいただけると幸いです。 はじめに 問い合わせやアラートに生じていた課題 Claude Code GitHub Actionsでアラートの初期調査コストを削減 Notionのデータベースで問い合わせのチケット管理とデータ蓄積 Notion MCPを使って過去事例の検索と自動調査 取り組みの成果 今後の取り組み：根本原因の特定と改善の仕組みづくり まとめ 問い合わせやアラートに生じていた課題 私が携わる Findy Team+ はエンジニア増加による開発チームの細分化・多数の機能リリース・連携するサービスの増加といった変化の中にあります。これにより、問い合わせやアラートなどの機能開発以外の運用業務でも複数の課題が生じていました。 問い合わせ/アラートの数が増加して機能開発のボトルネックになっている 問い合わせ/アラートに関連した機能・実装のコンテキストを知らないため調査コストが高い 問い合わせのやりとりは Slack のスレッドで行っているためステータスが分かりにくい 問い合わせのデータが蓄積されないため対策や将来の改善に活かせない こういった課題を解消すべくAIやツールを活用した改善をこの2025年下期で取り組みました。 Claude Code GitHub Actionsでアラートの初期調査コストを削減 アラート通知はこのようにSentryを経由してSlackへ通知されます。 これだけを見てもどういったエラーでどこで発生したのか分かりません。 そのため従来はSentryのイシュー詳細に遷移し、スタックトレースを確認したり、そこからエディタで関連コードを調査したり、まず 状況把握をするための初期調査コストが高い という問題がありました。 この問題の改善に用いたのが Claude Code GitHub Actions です。 Claude Code GitHub Actionsは、GitHub ActionsのワークフローからClaude Codeを呼び出せる機能です。 SentryからGitHubのイシューを作成したら自動で次のようなプロンプトのコメントをClaudeにメンションします。 このissueのdescriptionに当リポジトリで発生したエラーが記述されています。 このissueのdescriptionにはSentryのissueのIDが記載されています。 mcp__sentry__get_sentry_issueで記載されたIDのissueの詳細情報を取得してください。 mcp__sentry__get_sentry_issueで取得した結果やエラー発生箇所・周辺ファイルを閲覧し、エラーの発生原因の調査結果をissueのコメントに記載してください。 可能であれば修正対応のプルリクエストを作成してください。 プルリクエストを作成する際は次の3ステップで実行してください： - エラーに対する初期の対応案（ドラフト）を作成してください。 - そのドラフトに対して、どこが良くてどこが改善できるかをレビューしてください。 - レビュー結果をふまえて、より良い最終的な対応案を提示してください。 これによってClaude Code GitHub Actionsが起動し、自動でエラー発生箇所の周辺調査や状況整理、うまく噛み合えばClaudeが作ったプルリクエストをマージするだけで対応が完了する時もあります。 ▼実際にClaudeが作成したコメント例 この取り組みによって アラート発生時の初期調査コストを削減 することができました。ケースによっては数時間かかっていた調査が数分で状況把握できるようになり、調査開始までの心理的ハードルも下がっています。 Notionのデータベースで問い合わせのチケット管理とデータ蓄積 前述したようにFindy Team+では数年間に渡ってSlackワークフローでの問い合わせ起票を行ってきました。 問い合わせのコミュニケーションに関してはSlackで過不足無いのですが、複数問い合わせが並行するとやりとりを追うのが大変だったり、現在のタスクの状況が分からなくなる問題が度々発生していました。 また問い合わせはプロダクトの改善に繋がる貴重な情報なのにそのデータが蓄積されずフィードバックループを回すことが出来ない、というのも大きな課題でした。 これを一気に解消したのが Notion のデータベースです。 Slackのワークフローでの問い合わせ起票を全て Notion Form に移行し、フォーム送信と同時に問い合わせの情報がデータベースに蓄積されるようになりました。 またデータベースでもチケット管理を行うようにしました。 対応期限のカラムやいわゆる「To Do」「In Progress」「Done」といった値を持ったステータスのカラムを用意し、 Zapier を使ってリマインドの機構を設けました。 例えば対応期限を超過してもステータスが「Done」になっていない場合、Slackで担当者へリマインド通知を飛ばすといった自動化も行いました。 ▼対応期限超過のリマインドメッセージ Notionのデータベースを用いることでステータス管理や情報の蓄積が可能になり、問い合わせが抱えていた複数の課題を一気に解消することができました。 また、データが蓄積されることで次に紹介する取り組みにも繋がりました。 Notion MCPを使って過去事例の検索と自動調査 問い合わせ起票時には起票するメンバーに問い合わせに関連した「画面機能」「連携サービス」「メトリクス」といった情報をデータベースに入力してもらうようにしています。 さらに問い合わせの対応が完了したらLLMに問い合わせのやりとりを要約してもらい、その内容もデータベースに保存しています。 これにより半自動的に問い合わせについての情報を拡充していくことができています。 そしてアプリケーションのリポジトリに次の内容のClaude Codeのスラッシュコマンドを作成しました。 --- description : Notion上の問い合わせDBから類似の問い合わせを検索し、原因を調査する --- - $ARGUMENTSは `collection://***` の問い合わせデータベースの中の問い合わせ(ページ)です。 - notion-fetchを使って $ARGUMENTS の問い合わせ内容を確認してください。 - $ARGUMENTS の問い合わせと類似の過去の問い合わせを `collection://***` のデータベースから検索してください。 - 検索の際は`summary`,`detail`,`tag`の各プロパティから類似の問い合わせを検索してください。 - この検索結果から $ARGUMENTS の問い合わせを当リポジトリのコードから調査してください。 - 最終的に次の結果を出力してください。 1. 類似の問い合わせが見つかったかどうか 2. 類似の問い合わせが見つかった場合、その問い合わせIDと概要(summary) 3. $ARGUMENTS の問い合わせの原因調査結果 このスラッシュコマンドは内部で Notion MCP のtoolを利用しています。 これにより過去の問い合わせ情報というコンテキストを持ちながらClaude Codeがより詳細にコード情報を調査することを可能にしています。 出力サンプルを本記事に掲載したいところですが、あまりにも詳細に情報を出力しすぎてしまうため残念ながらここでの掲載は控えさせていただきます。 ただ私自身何度かこのスラッシュコマンドを問い合わせに実行してみて過去に類似問い合わせがあると問い合わせの要因等をかなり詳細に調査してくれることを確認しています。 また過去に類似問い合わせが無いとしても、問い合わせに関連した周辺処理の概況を説明してくれるので全くコンテキストを把握していない機能の問い合わせの調査コストを軽減できていると感じています。 取り組みの成果 今回紹介した取り組みにより、次のような成果を得ることができました。 問い合わせやアラートの状況が可視化され、分析可能な基盤が整った AIによる初期調査で調査の効率化が実現し、状況把握までの時間を大幅に短縮できた チケット管理によりステータスが明確になり、対応漏れを防げるようになった 一方で、可視化や効率化を行うだけでは問い合わせやアラートの件数自体は減少しませんでした。 機能開発が進み、利用者数も増加している中での自然な傾向でもあります。 可視化や効率化は部分的に対応コストを下げるものであり、それだけでは件数を減らす根本的な解決にはなりません。 今後の取り組み：根本原因の特定と改善の仕組みづくり 蓄積された問い合わせデータやアラート傾向を分析し、頻出する問題の根本原因を特定していきます。 暫定対処ではなく恒久対応を行うことで、問い合わせやアラートの件数自体を減らすことを目指します。 たとえば、問い合わせデータを「画面機能」や「連携サービス」ごとに集計し、特定の領域に問い合わせが集中していないかを可視化します。 集中している領域があればUIの改善やドキュメントの拡充、場合によっては機能自体の見直しを検討します。 また、これまでは改善活動に対する明確な行動指針がなく、暫定対処に留まりがちでした。 今後はインセンティブの設計をしっかり行い、改善活動が継続して実施される仕組みを作ります。 具体的には、来期から私も機能開発チームに合流し、改善対応もミッションの一部として進めていきます。 運用業務の当事者として改善に取り組むことで、フィードバックループを確実に回していきます。 まとめ 2025年下期開始当初、自分は昨今のAIの潮流もあって「AIがあれば運用業務の全てを改善できる！」と意気込んでいました。 実際に取り組んだ結果、AIやツールを活用していくらかの問い合わせやアラート対応の「可視化」と「効率化」を実現しました。 しかしこれらは対応を効率化するものであり、件数を減らす根本解決ではありません。今後は蓄積したデータを活用して恒久対応に繋げ、問い合わせやアラートの根本原因を取り除いていきます。 引き続きAIを活用しつつ、改善活動が継続する仕組みを作りながら本質的な改善に挑戦していきます！ ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

この記事は、 ファインディエンジニア #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つの施設に分散 シャトルバスとモノレールで会場間を移動 多数あるセッションカテゴリ 会場の様子 フリードリンクと軽食 Meal会場でのビュッフェ 厳重なセキュリティチェック EXPO会場 SWAG SPORTS FORUM セッション以外のサブイベント 5K Fun Run re:Play おわりに re:Inventの規模感 - ラスベガスの街が会場に 会場は6つの施設に分散 re:Inventの会場は次の6つに分散しており、それぞれが巨大な施設です。 Encore Wynn The Venetian (メイン会場) Caesars Forum MGM Grand 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

この記事は、 ファインディエンジニア #1 Advent Calendar 2025 の21日目の記事です。 adventar.org はじめに こんにちは、ファインディのPlatform開発チームでSREを担当している原（ こうじゅん ）です。 2025年12月、ラスベガスで開催されたAWS re:Inventに参加してきました。re:InventはAWSが毎年開催する世界最大級のクラウドカンファレンスです。 今年は特にAI Agentを中心とした大きな変化を感じるイベントとなりました。 本記事では、私の体験したセッションを通じて見えてきたインフラ・運用の変化について、AIOps領域に焦点を当てて振り返りを書いていこうと思います。 会場の様子やセッション以外のイベントについてはまた別記事で書いていきます。 はじめに re:Invent 2025 今年の主要テーマの1つであるFrontier Agents AWS DevOps Agentとは ワークショップでの体験 その他の運用・インフラ領域で参考になるセッション Observability × AI 運用の文化とプラクティス インフラ基盤の進化 IAMポリシーの深掘り エンジニアに求められる姿勢 おわりに 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がグローバル規模で運用をどのように行っているのかが解説されました。 特に印象的だったのは、次のサイクルを継続的に回している点です。 Readiness : 障害が起きる前の状態づくり（アラーム、ダッシュボード、Runbook、オンコール体制の整備） Observability : ログ・メトリクス・トレースでの計測、SLOドリブンなモニタリング Incident Response : SOP（標準作業手順書）に従った対応、AIOpsによる障害分析 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

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 現在のソフトウェア開発の世界は、生成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とは Findy AI+ アルファ版: リモートMCPサーバーでの提供 ベータ版: チャットUIとMCP活用のAdmin機能 まとめ 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

こんにちは。 Findy Freelanceの開発チームでEMをしている中坪です。 この記事は、 ファインディエンジニア Advent Calendar 2025 の18日目の記事になります。 adventar.org 日々進化するAIや関連ツールをキャッチアップし、実務に活用することに苦労しているエンジニアの方も多いのではないでしょうか。 私たちは、チームでAIツールのキャッチアップを行う取り組みとして「10分勉強会」を実施しています。 本記事では、その取り組み内容について紹介します。 10分勉強会とは 発表内容の例 1. Sentry MCPとLog Analyzer with MCPを使った不具合調査 2. Gemini Canvasを使ったUIモックの作成と社内共有 3. Git Worktree Runnerの紹介 持続するための工夫 発表のスキップを許容する 発表資料は任意 厳密ではないテーマ設定 チーム内で開催する 開催時間を短くする 効果と反響 チームメンバーの声 チームAI活用率 メリット アウトプットによる知識の定着 AIのキャッチアップをチームで取り組める 聞いた内容をすぐに試せる デメリット 余談と「うちのAIがやらかしまして」の紹介 おわりに 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

はじめに みなさんこんにちは。Platform 開発チーム SREでサブマネージャーの安達（ @adachin0817 ）です。この記事は、 ファインディエンジニア Advent Calendar 2025 の18日目の記事です。今回はECS Express Modeをスピーディーに試してみたので、使ってみて分かったメリット・デメリットを中心にまとめていきたいと思います。 adventar.org はじめに ECS Express Modeとは Terraform terraform.tf iam.tf ecs.tf variables.tf Deploy 削除の挙動と懸念点について まとめ 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

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 この記事は、 ファインディエンジニア #1 Advent Calendar 2025 の17日目の記事です。 adventar.org 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 そんな中で先日、Claude Codeの新機能であるPluginsが公開されました。 そこで今回は、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

こんにちは、CTO室データソリューションチームでマネージャーをしている 開（hiracky16） です。 この記事は、 ファインディエンジニア #1 Advent Calendar 2025 の14日目の記事です。 adventar.org 先日、チームで半日ほど時間をとってワークショップ（オフサイトミーティング）を実施しました。今回は、そのプロセスの中で「生成AI（Gemini）をファシリテーター兼、壁打ち役として参加させる」という試みを行った話と、そこで決まった私たちの新しいミッション・ビジョンについて書きたいと思います。 データソリューションチームについて紹介 我々のチーム、データソリューションチームについて少し紹介すると現在は職能で言うとデータエンジニアのみが所属するチームで、現チーム体制になって約1年半が経過しました。横断組織でもあるため特定の事業の仕事に取り組むのではなく全事業のデータ活用に関する依頼に対応しながらデータ基盤を作っています。もともとはデータサイエンティストと一緒のチームでしたが、組織変更を経て、データサイエンティストやデータアナリストは事業部の方に所属となり今の形となりました。ファインディのエンジニアチームの構成は次のような形です。 ワークショップ開催の経緯 日々の業務としては、各部署のデータアナリストやサイエンティストの支援をしたり、データ活用の悩みを解決したり、全社横断の検索エージェント基盤を作ったり様々です。しかし、1年半走ってくる中で、マネージャーである私自身の中に、ある種の「モヤモヤ」が溜まっていました。 優先順位の悩ましさ ファインディでは4事業を展開している中で、事業ごとにデータ関連の仕事の相談を受けます。横断組織として複数の事業に関わる一方で、限られた人数の中で取り組むテーマに優先順位をつけながら進めています。さらに新規事業やプロダクトも控えており、今後は関わる事業やプロダクト、仕事の幅が広がる中で、より丁寧な判断が求められる場面も増えていくと考えています。 「具体的な」データ・AI戦略の言語化 優先順位に迷いながらでも現場は回っている状況ではある中で、中長期的な指針がより明確になることで、チームが同じ目的をこれまで以上に共有しやすくなると考えています。また普段は単一の事業やチームに最適な取り組みをするとよいことが多いですが、「ファインディとして」どうあるべきか？という全社視点をあらためて意識することの重要性も感じています。 データエンジニアの役割変化 生成AIの台頭により、これまでの「基盤を作って終わり」というスタイルに加えて、よりビジネス価値に踏み込んだ関わり方が求められるようになってきました。ファインディ主催のカンファレンス 「Data Engineering Summit 2025」 でも他社の事例を見聞きする中で、データエンジニアやデータ基盤の役割が変わりつつあることを改めて実感しました。自分がモデレーターを務めた「サイロ化解消のその先へ。ビジネス/データ、それぞれの視点で語るRevOps」というセッションでも、RevOpsという領域におけるデータエンジニアの新しい役割やキャリアについて話すことができました。 そんな危機感を感じ、チーム全員で一度立ち止まり、自分たちのミッションやビジョンを見直すタイミングだと思いました。ただ、私ひとりが悩んで決めたトップダウンの指針では十分ではありません。メンバー全員が腹落ちし、意欲的に働くための指針を作ること──それが今回のワークショップの目的でした。 準備 ワークショップを企画するにあたり、今回はGeminiを活用しました。 私自身過去ワークショップに参加したことはありましたが、主催するのは初めてです。準備や進行の面でうまくできるか不安がありました。また当時、課題感は言語化できていない曖昧な状態でした。 そこで、今回は次のようなフローで準備を進めました。 音声入力でひたすら喋る：現状の課題、チームの歴史、私の悩みなどを、脈絡なく音声入力でテキスト化 Geminiに投げ込む：その長文テキストをGeminiに渡し、「これらのコンテキストを踏まえて、半日のワークショップのアジェンダと、各パートの狙いを設計して」と依頼 壁打ちしてブラッシュアップ：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

こんにちは、ファインディでソフトウェアエンジニアをしているnipe0324です。 この記事は、 ファインディエンジニア #1 Advent Calendar 2025 の13日目の記事です。 adventar.org コーディングエージェントを使う中で、 実装は早くなる一方CIが遅いと思うことはないでしょうか？ かくいう私も、Claude Codeを使って並列にプルリクエストを作る中で「CI遅いなー」と思うことがよくありました。 CIの実行時間を短くしたいという気持ちはありつつ、メインの開発があるのでなかなか改善に手をだせませんでした。 しかし、2025年はAIエージェント元年。 せっかくなら、「Claude Codeに任せられるだけ任せてみよう！」と思い、CIのテスト実行時間の削減を任せてみました。 Claude Codeに「方針検討」「対応・効果測定」を任せ、私は意思決定とレビューに注力することで、 メインのタスクがありながらも、CIのテスト実行時間を約2分短縮 できました。 この記事では、具体的な内容を交えながら、Claude CodeにCI速度改善の方針検討と対応・効果測定を任せた事例をご紹介します。 CIのテスト実行時間が7分から5分に短縮 Claude CodeによるCI高速化の改善結果は次のとおりです。 CIでのテスト実行時間が7分から5分になり、 約2分短縮 できました。 対応前 対応後 改善 7分01秒 5分05秒 -116秒 (-28%) たかが2分の短縮と思うかもしれませんが、1日50-60回ぐらい実行されているので1日2時間、月の営業日を20日とすると月40時間になるので、 月5営業日分の待ち時間が削減 できました。 今回Claude Codeに実施してもらった改善は次の4つです。 並列マシンへのテスト割当をファイルサイズベースから実行時間ベースに変更（60秒短縮） テストファイルごとの実行時間の偏りが大きかったので平準化 不要なジョブを削除（27秒短縮） 影響のないジョブがクリティカルパスに存在していたので削除 aptでインストールしているライブラリのキャッシュ（25秒短縮） 毎回インストールして30秒ぐらいかかっていたのをキャッシュすることで2-3秒に短縮 テスト用のDBダンプのキャッシュ（55秒短縮） 並列実行のためDBスキーマ作成とシードデータ登録に1分弱かかっていたが、キャッシュ化で20秒前後に削減 Claude CodeにCIの高速化を任せていく CIのテスト実行時間の短縮のため、Claude Codeに「調査依頼」、「改善案の実施と効果測定」、「結果のとりまとめ」をそれぞれ任せていきました。 ファインディでは、CI/CDにGitHub Actionsを使っています。 GitHub Actionsでは、CIのワークフローの詳細な実行時間やログがあり、また、ghコマンドでそれらの情報が取得できるため、AIエージェントが自律的に改善・効果測定をできる環境が整っていました。 結果として、CI高速化はAIエージェントにとても任せやすいタスクだと感じました。 調査依頼 調査依頼では次のようなプロンプトで調査依頼をしました。 # プロンプトイメージ CIが7分と遅いので、5分以内にしたい。改善案を検討してください。 CIの実行結果: https://github.com/Findy/Xxxxx/actions/runs/1234567890 CIの実行結果を確認し、現状分析と改善提案をしてくれました。 Claude Codeの調査結果イメージ（一部省略） これまでもCI高速化を何度かしてきて改善余地が少なくなっている中でも、改善効果がありそうな改善案を6つほど提案してくれました。 クリティカルパスを利用した分析や削減効果と対応工数による優先度付けなど基本を押さえた分析と提案をするのですごいな！と思いました。 実際Claude Codeに改善案を対応してもらう中で一部想定と違うこともありましたが、適宜結果を確認して方向を微修正することで結果として実行時間短縮につながりました。 改善と効果測定 アイデアとして有望そうに見えますが、実際に試して効果を測定するまでわかりません。 そのため、Claude Codeに改善と効果測定を実施してもらいました。 # プロンプトイメージ https://github.com/Findy/Xxxxxx/issues/12345 の 「parallel_tests実行時間ベース分配」の対応を実施してください。 PR作成後にCIの実行時間を確認し、PRボディに見込みと実績を表形式で記載する。 Claude Codeが作成したPRイメージ Claude Codeがghコマンドを使うことで、GitHub Actionsの各ジョブやステップの実行時間や状況を知ることができるため、自律的に改善を任せることができました。 また、必要に応じてプロンプトに「CIが失敗したら成功するまで対応する」「改善結果が見込みに届かない場合、原因分析して追加改善をする」などの指示を追加して自律性を高めました。 結果の取りまとめ CIのテスト実行時間を短縮できたため、結果の取りまとめもClaude Codeに依頼しました。 # プロンプトイメージ https://github.com/Findy/Xxxxx/issues/12345 の対応が 一通り終わったので結果をとりまとめたい - 対応前後でのCIのテストの実行時間の比較 - 表形式で、サンプル数、中央値、平均値をだす - 対応前は 2025-12-05 と 対応後は 2025-12-10 のデータを集計 - 1分以内のタスクはテストがスキップされているので除外する - やったことの概要 - 箇条書きでシンプルに記載 - 結果をシンプルにまとめ、イシューにコメントをする Claude Codeのイシュー対応結果のまとめイメージ 数字があっているのか若干気になりましたが、確認してみると細部は少し怪しいものの、実際にCIの実行履歴を目検で眺めてみると概ねあってそうでした。 まとめ 今回は、Claude CodeにCIのテスト実行時間の改善を丸っと任せることができました。 その結果として、 自分はメインのタスクをしながらも、テスト実行時間を7分から5分に短縮 できました。 個人的にClaude Codeにうまく任せることができたポイントとしては、 「Claude Code自身がPDCAを実施したこと」 と 「影響範囲や制約が少ない領域だったこと」 だと考えています。 ゴールが明確で、エージェント自身がPDCAを実施 CIの実行時間を7分から5分に削減とゴール明確で測定可能 エージェントが直接CIの実行時間やログを確認できるため、改善後の効果測定や原因分析が自律的にできる 影響範囲や制約が少ない領域 改善に失敗しても、CIのテストが失敗するだけで影響範囲が限定的 制約もワークフローの実行時間、保守性、コスト、セキュリティぐらいで少ない 以上、参考になったら嬉しいです。 CIの実行時間が気になる方は、ぜひAIエージェントに任せてみてはいかがでしょうか。 最後に、現在Findyでは「うちのAIがやらかしまして」というAIとの試行錯誤の結果をシェアする期間限定企画をやっています。 「AIエージェント活用しているぞ！」という方は、ぜひのぞいてみてください。 findy-code.io

はじめに こんにちは！ファインディのTeam+開発部でエンジニアをしている澁谷（ TENTEN11055 ）です。 この記事は、 ファインディエンジニア Advent Calendar 2025 の11日目の記事です。 今年11月、AWS が主催する AI-DLC Unicorn Gym に参加しました。 AWS主催 Unicorn Gym 最終日の成果プレゼンの様子 このプログラムの開発プロセスはAIと共に歩む仕様駆動開発。 部分的なAI活用から一歩進んだ開発体験を得ることができ、同時に「今後はより読解力が求められる」と感じました。 この記事では読書習慣がなぜスキルになるのか、自分の体験をもとに書いています。 はじめに AI-DLC（AI駆動開発ライフサイクル）とは AI-DLCにおけるレビュー負荷 読書を始めてみた 理解力がある人の特徴 「読む」と「理解」は別 人間が監視する時代、読書がどう活きるか まとめ AI-DLC（AI駆動開発ライフサイクル）とは これまで開発の一部にAIを用いるケースが多く、その真価を発揮しきれないなどの課題がありました。 AI-DLCでは要件、ユーザーストーリー、設計、開発の全てをAIベースで行います。 そして 人間の役割は監視、つまりレビューです 。 作業の一切をAIに任せ、人間はそれを監視して品質を担保しながら素早く成果物を提供できるというものです。 AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 AI-DLCにおけるレビュー負荷 AI-DLCでは実装前に多くのドキュメントを作成します。 そのため最も時間を使ったのは「文章を読み、AIの意図を正しく理解すること」 でした。 AIの文章は論理的ですが、人間が読みやすいかどうかでは最適化されていません。 ときには矛盾を見抜き、ときには曖昧な記述を解釈して補う必要があります。 AI-DLCではこのドキュメントレビューの質がそのまま品質に影響します。 こうした経験から、「読む力」を鍛える必要性を強く感じました。 読書を始めてみた というのも、自身も普段の仕事で読解力に課題を感じており、対策として半年前から読書習慣を続けてきた背景があったからです。 文章の理解に時間がかかる 一行戻って読み直す回数が多い 説明を聞き返すことが増えた こうしたものを少しでも解消したくて、「読む力」を鍛える目的で始めました。 理解力がある人の特徴 読書を続ける中で、「理解力の高い人とは何が違うのか？」を意識して観察するようになりました。 理解力の高い人は、次の点が際立っています。 説明の意図を素早く理解できる 情報の本質を捉えられる そのため発言や判断が的確になる そしてこうした人たちは例外なく読書量が多い印象です。 「読む」と「理解」は別 こうして観察と実体験を重ねるうちに、読む行為と理解する行為は別の能力だと改めて実感しました 「それはそう」と言われてしまいそうですが、これを同時に行うトレーニングをできるのが読書のすごいところ。 以前に比べて本を読むのが早くなり、それは先に読んだ文章を理解しながら次の文章を読み進めているからだと気づきました。 また、文章全体を読みながら「重要な部分だけ自然と拾える感覚」も少しずつ身についてきました。 人間が監視する時代、読書がどう活きるか ここで話を AI-DLC に戻すと、この手法は前述の通り多くのドキュメントを作成します。 つまり「読む力」「本質をつかむ力」がそのまま成果物の質に跳ね返ってきます。 今回のワークショップで実施したドキュメント数は次の通り。 Inception（要件、ストーリー整理、 ユニット変換） 12ドキュメント Construction（ドメインモデル設計、フェーズの定義など、そして開発） 3ユニット、計18ドキュメント 合計30のドキュメントをレビュー後、コード生成に入るのです（そしてコードレビューへ...）。 そんな丸一日ドキュメントを眺める際に重要だったのは次の点です。 文章を短時間で理解できる力 AIが生成した成果物の意図や本質を汲み取る力 論理を追う集中力 これらは全て読書で鍛えることができます。 私も本当にまだまだですが、ワーク中「読書しててよかった〜」と思いました。 まとめ AIに何かを生成してもらうのはもはや当たり前の時代になりました。 人間の価値は「作業」から「確認と意思決定」に比重が移りつつあるように感じます。 AI は体系的に詳細な作業計画を作成し、積極的に意図のすり合わせとガイダンスを求め、重要な決定は人間に委ねます。これが重要なのは人間だけが情報に基づいた選択を行うために必要なビジネス要件の文脈的理解と知識を持つからです。 （AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 より） 読書はそんな時代においても開発の手助けとなり、基礎体力になります。 で、どんな本がおすすめかというと何でもいいと思います。 技術書、ビジネス書、小説でも十分トレーニングになります。 私は最近 ザ・ロイヤルファミリー という競馬が舞台の小説を読んでいました。 おすすめです。ドラマもおすすめ。 AI時代は基礎知識や読解力など、アナログ(？)なスキルが求められているかもしれませんね。 ファインディでは一緒に働くメンバーを募集中です！ よかったら覗いてみてください。 herp.careers

はじめに こんにちは、GenAI Enablementチームです。 この記事はファインディエンジニア #3 Advent Calendar 2025の9日目の記事です。 今年1月に「GenAI Enablementチーム」を立ち上げてから現在までの約1年間における活動を総括します。 チーム組成から今日に至るまで、どのような課題に直面し、それらをどう解決して成果に繋げてきたのか。その過程で得られた「理想と現実」のギャップや、具体的な成果・反省点について詳述します。 今後、自社でのGenAI活用推進を担う方々にとって、実践的なヒントとなれば幸いです。 今月から、沢山のアドベントカレンダー記事が執筆される予定ですので、年末のお供に是非読んでみてください。 adventar.org GenAI Enablementチームって？ まず簡単に、チームのご紹介から。 ファインディにはプロダクトマネジメント室直下にGenAI Enablementチームという、その名の通り 全社のデータ生成AIを含む広義のAI活用を推進し実装する、データサイエンティスト の専門部隊が存在します。 今でこそメンバー5名体制（兼務を含む）になりましたが、立ち上げ当初（2025年1月）はマネージャーと、入社したばかりのメンバー1名、計2名からのスタートでした。 チーム誕生の背景 会社として、2024年を通じて自社の事業やプロダクトに生成AIを組み込むことは、もはや『あったらいいな』ではなく、企業の生存確率を高めるための『必然』であるという確信に変わったからです。 プロダクトマネジメント室という部署にこのチームが置かれたのも、単なる業務効率化だけでなく、 プロダクトの競争力強化 に直結させるため。 そんなミッションを背負い、チームが発足しました。 【社内活用】プロダクト使い方Botが生んだ「意識の180度転換」 まず着手したのは、社内のAI偏差値の断絶を埋めることでした。CTOや一部のエンジニアを筆頭に、生成AIを活用する動きは社内でも出始めていたものの、まだまだ当時全社的に「生成AI？便利だって聞くし使いたいけど業務が忙しいのと、どう使っていいのかわからない…」のような空気感が漂っていました。 このままではイネーブルメントはできないと考え、はじめに生成AIアプリツール「 Dify 」を導入しました。Difyは、Slackと連携して便利なチャットボットを簡単に生み出すことができるため、これを活用し、最初のユースケースとして「 Findy Team+の使い方Bot 」を作成して全社展開してみました。 Findy Team+使い方Botの雰囲気 「便利やん！」から始まった変化 とはいえ正直、最初は「まあ使ってもらえれば御の字か」くらいに思ってました。 しかし、蓋を開けてみれば想定以上の反響。「これ便利すぎ！」「こんな用途で、似たようなBotを作成したい！」と、社内は一種の熱狂に包まれました。 社内の声① 社内の声② 社内の声③ この「Findy Team+の使い方Bot」は、Findy Team+の機能に関する説明や社内で蓄積されたドキュメント等々をナレッジとしたBotであり、これまで事業運営によって培ってきたものが結果として生成AIを強化する武器となってくれています。 しかし、このBot施策の本当の成果は使われたことそのものではありません。 Botを使っているうちに、社員みんながある事に気付いたこと。これこそが最大の成果です。 AIに適切なコンテキスト（データ）を渡し、そのデータを活用する役割を与えれば、強力なパートナーに変貌する ということです。今までは、 「データ入力？次の予定までに済ませなくちゃいけない準備が優先だから…」 となりがちだった業務の後処理が、 「ここに入力しておけば、AIが賢くなって後で自分が楽できる！きちんと入力しよう！」 という意識に変わった事が、当初想定していなかった一番のインパクトでした。 すなわち、 データをきちんと入力・整備することの重要性 への意識が、180度変わったんです。 長年事業を積み重ねてきたデータ資産の価値が再定義され、全社の目線が揃った瞬間でした。 社内の声④ 【事業貢献】Findy Insightsの立ち上げとα版リリース GenAI Enablementチームの業務は、社内の便利ツール作りだけではありません。 今年9月に提供開始された Findy Insights という 生成AIを中心に据えた新規プロダクトの立ち上げとα版リリース にもPoCから実装まで関わりました。 プロダクトの簡単な概要をご紹介すると、「Findy Insights」は、 日々集まる膨大な「顧客の声」や「市場データ」を生成AIが分析し、「次にどんな機能を作るべきか（プロダクトディスカバリー）」を支援するサービス です。 今までPMが泥臭く読み込んでいた議事録などのテキストデータを、AIが分析して「こういうニーズが増えている」と提案してくれます。勘と経験だけに頼らない、 データドリブンな意思決定を加速させるツール となります。 プロダクトオーナー（PO）の起案からPoCの着手を2月に開始し、約3ヶ月の検証期間を経てから5月のプロダクト開発開始。9月のα版公開と顧客提供開始というスピード感あふれるタイムスケジュールで駆け抜けることができました。 本来であれば1年はかかる規模の新規プロダクト開発でしたが、半年足らずで顧客への提供開始まで漕ぎ着けることができました。その背景には、 提供予定の機能のPoCを、POと連携しながら常に最前線で取り組み続けたこと PoCにより確定した仕様をアプリケーションエンジニアと連携し、実装にも加わりつつレビューにも入り込み、密な連携を取り続けたこと などと振り返っています。 もちろん、GenAI Enablementチームだけではなく、このプロダクトの開発に関わった全員の尽力に寄るところは言うまでもありません。 提供開始後まもなくではありますが、既に 数十社以上との商談やトライアル開始 などで引き合いを頂けている状況であります。 また、今後も様々な機能の開発とアップデートを予定していますので、どこかの機会でご紹介できればと思います。 取り組みの成果と社内評価 たった2名体制ながら、社内活用向けのBot開発と、事業貢献につながる新規プロダクト立ち上げの両輪で取り組みを進めました。その結果、半期に一度の全社表彰で受賞とノミネートの評価を得ることができました。 表彰トロフィーと表彰状 【知見共有】データサイエンティストがいなくても実装できる体制へ 成果が出れば出るほど、ぶつかった壁が「リソース不足」でした。 ML（機械学習）やLLMの実装は、一定部分をデータサイエンティストに依存してきた背景がありました。 社内活用や事業貢献の取り組みを通じて同時に取り組んだのが、 エンジニアリングの冗長化 です。 ML/LLMを伴う機能開発の概念フロー（Before） これまでデータサイエンティストだけで完結させていた実装ノウハウを、プロジェクトを通じて社内のエンジニアや他組織に積極的に展開しました。 その結果、今では実装面においてデータサイエンティストの手が空いてなくても、社内エンジニアに頼ればOKという状態になりつつあります。 ML/LLMを伴う機能開発の概念フロー（After） 実装工数が理由でお断りせざるを得なかった依頼も、レビュー/レビュワーの関係になりながらエンジニアチームと連携しながら進めることができるようになったことは、非常に大きな一歩だったと振り返っています。 やりきれなかったこと ここまで良い取り組みを書いてきましたが、その裏側には、思うように前に進められなかったことも少なくありませんでした。 お断りの連続 問い合わせや相談は急増しましたが、リソースには限りがあり、新規開発や業務改善の多くを先送りせざるを得ない状況が続きました。 生成AIフレンドリーなデータ整備 新しい取り組みを進めようとするほど、その実現に必要なデータが不足していたり、整備が十分でない場面に直面しました。 「業務改善のために Team+ の使い方Botのような仕組みが欲しい」という声も多くいただきましたが、前提となるデータが不足していたり、そもそも存在しないケースもありました。 データ活用、新規開発、Ops改善の推進に向けて、これらの課題を来年にかけて解決する必要があります。来期は、計画的に取り組みを進めていきます。 まとめ この1年の取り組みを経て、データ活用への意識やモメンタムを産むには、論より証拠。まずは作って示すことが効果的な方法の1つである事を学びました。 新規プロダクトをスピード感を持って立ち上げるには、データサイエンティストが常にPoC先頭に立って絶え間なく行い続けることができる体制を整える事が大切である事を学びました。 最後に GenAI Enablementチームではデータ・AI活用を用いて一緒に事業貢献に取り組んでいく仲間を募集しています。興味のある方はぜひカジュアル面談等々でお話ししましょう！ herp.careers

こんにちは、ファインディのみっきー @mikiko_bridge です。 12月6日（土）に池袋で開催された Developers Boost 2025 の「Hello, new world! ～技術とキャリアを次のステージへ～」というテーマのLT枠で登壇しました。 翔泳社さんのイベントで登壇するのは2回目です。昨年、 Women Developers Summit 2024 でLTをさせていただき、再び登壇の機会をいただけて本当に嬉しいです！ 本記事では、私のLTの内容と、登壇準備を通じて得た気づきについてお伝えします。 ファインディと生成AI ジュニアエンジニアはどう生きるか？ 伸び悩むわたし 5ヶ月間、何をやったか テストの追加 コードドキュメントの追加 結果 現在とこれから 登壇資料 おわりに ファインディと生成AI ファインディでは、生成AIの活用を推進しています。 AI推進チームが設立され、エンジニアが開発に集中できる環境が整っています。AI推進チームがAIのキャッチアップや活用をサポートしてくれるため、最新技術を取り入れやすい環境です。 AI活用事例については、次のブログをご覧ください。 https://tech.findy.co.jp/archive/category/GenAI%E3%83%BBLLM https://tech.findy.co.jp/archive/category/Claude https://tech.findy.co.jp/archive/category/Devin https://tech.findy.co.jp/archive/category/MCP https://tech.findy.co.jp/archive/category/GitHub%20Copilot ジュニアエンジニアはどう生きるか？ 生成AIが当たり前になった今、ジュニアエンジニアとしてどう成長していくべきでしょうか。これまでは、good first issue やテストコードの追加といった小さなタスクから始めて、徐々にスキルを身につけていくのが一般的でした。 しかし、生成AIの登場により、コードの自動生成やデバッグの支援が簡単にできるようになり、ジュニアエンジニアが直面する課題も変わってきています。 伸び悩むわたし ファインディに転職してから、チーム目標である1日4件のプルリクエスト作成をほぼ達成できない日々が続いていました。 コードを書いても思うようにいかず、レビューで指摘される箇所も多く、「なんとなくうまくいかないな」という感覚が続きました。 同期入社のエンジニアたちが次々と新しい機能を実装していく中で、自分だけが取り残されているような焦りと不安を感じていました。 そんな状況を見かねて、テックリードの方がメンターとなり、毎日1on1をすることになりました。テックリードに声をかけられることはなかったので、1on1の予定が入った時はめちゃくちゃビビっていました。1on1の当日、怒られると思っていたのですが、そうではなく、今後どうやって成長していくべきかを真剣に話し合いました。 そして、5ヶ月間の修行が始まりました。私は、「あえて生成AIという便利なツールに頼ることなく、まずはエンジニアとしての基礎をしっかりと固める」という方針を選びました。 5ヶ月間、何をやったか 2024年12月から2025年4月までの約5ヶ月間、私はテストのリファクタリングとコードドキュメントの追加という地道な作業に集中的に取り組みました。テックリードの方がメンターとなり、毎日1on1を行い、進捗や課題について相談しました。 テストの追加 ファインディはテストカバレッジが90%超えを維持していますが、さらに堅牢なテストにするためのリファクタリングを行いました。 具体的には、ソート機能に関するテストを強化しました。 境界値や閾値を意識したテストデータを用意する ソート順が正しく機能していることを検証するため、ID順とは異なる順序でデータを配置し、意図した並び順になっていることを確認する 条件に該当しないデータ（対象外となるケース）も含めることで、フィルタリングロジックが正しく動作していることを保証する 例えば、次のようなテストコードを書きました。 # ソート機能のテストの例 describe ' ソート機能のテスト ' do let!( :user1 ) { create( :user , name : ' Charlie ' , created_at : 1 .day.ago, is_active : true ) } let!( :user2 ) { create( :user , name : ' Alice ' , created_at : 3 .days.ago, is_active : true ) } let!( :user3 ) { create( :user , name : ' Bob ' , created_at : 2 .days.ago, is_active : true ) } let!( :inactive_user ) { create( :user , name : ' Dave ' , created_at : 4 .days.ago, is_active : false ) } it ' 名前順でソートされること ' do result = User .active.order_by_name expect(result.map(& :name )).to eq([ ' Alice ' , ' Bob ' , ' Charlie ' ]) end it ' 作成日順でソートされること ' do result = User .active.order_by_created_at expect(result.map(& :name )).to eq([ ' Charlie ' , ' Bob ' , ' Alice ' ]) end it ' 非アクティブなユーザーが除外されること ' do result = User .active expect(result).not_to include (inactive_user) expect(result.count).to eq( 3 ) end end 初めはテストデータの作成ミスがあったり、想定以上に時間がかかったりしていました。レビューコメントをもらう数も多く、なかなか思うように修正が進まないこともありました。 しかし、徐々にフィードバックを活かして改善を重ねていくうちに、最終的にはテストケースの漏れを自分で見つけられるようになりました。 コードドキュメントの追加 テストの追加が進む中で、コードドキュメントの整備が課題として浮上しました。特に、内部実装の共通処理に関するドキュメントが不足していたため、こちらの整備に注力しました。 コードドキュメントの追加を始めた当初は、例外処理の仕様や実際の使用方法の理解に苦労し、作成に時間がかかることも多くありました。 具体的には、次のようなYARD形式のドキュメントを追加しました。 まず、コメントドキュメントがない状態のコードを見てみましょう。 class UpdateUserInteractor include Interactor delegate :user_id , :name , :is_active , :roles , :options , to : :context , private : true def call update_user context.user = user rescue ActiveRecord :: RecordInvalid => e Logger .error_exception(e, message : ' Failed to update user ' ) context.fail!( message : ' Failed to update user ' ) end private def update_user # 実装 end end このコードを見ただけでは、 roles には何が入るのか、 options にはどんなパラメータを渡せばいいのか、よくわからないですよね？ そこで、YARD形式のコメントドキュメントを追加してみました。 # Interactorのコメントドキュメントの例 # # @attr user_id Integer ユーザーID # @attr name String 名前 # @attr is_active Boolean アクティブかどうか # @attr roles Array<Role> 権限一覧 # @attr options Hash { # ids: Array<Integer> IDのリスト。 # mode: String[Optional]("include") 選択モード # is_verified: Boolean (false) trueの場合、検証済みとして扱う # }[Optional] オプション設定 # # @example # UpdateUserInteractor.call( # user_id: 1, # name: 'John Doe', # is_active: true, # roles: [Role.first], # options: { ids: [1, 2, 3], mode: 'include', is_verified: true } # ) # class UpdateUserInteractor include Interactor delegate :user_id , :name , :is_active , :roles , :options , to : :context , private : true # Interactor実行 # # @return Interactor::Context { # user: User 更新後のユーザーデータ # message: String エラーメッセージ # } コンテキスト def call update_user context.user = user rescue ActiveRecord :: RecordInvalid => e Logger .error_exception(e, message : ' Failed to update user ' ) context.fail!( message : ' Failed to update user ' ) end private def update_user # 実装 end end いかがでしょうか？コメントがあると、各パラメータの型や意味、使用例が明確になって、格段にわかりやすくなりましたよね！ こうしたコメントドキュメントを追加したことで、自分自身がコードを読み返すときにも理解しやすくなりました。 後から参加する新メンバーにとっても助けになるし、生成AIにコードを解析してもらうときにも正確な情報を渡せるので、AI活用の場面でも役立っています！ 対応が進むにつれて作業の質が上がり、自力も少しずつ付いてきたため、最終的にはテストケースの漏れを自分で見つけられるようになりました。 ファインディでは日報・週報の文化があり、テックリードからは「周りではなく過去の自分と比較しましょう」と言われてきました。過去の日報や週報を読み返してみると、2025年4月の週報に「修正が必要な箇所を見極める力がついてきた」という記述がありました。 自分の成長を客観的に実感できた瞬間でした。 結果 取り組みを始めた当初は、プルリクエストの作成が週に7.2件程度というペースで、レビューの数も多い状態でした。 2024/07/01〜2024/11/30までの1週間あたりにPR作成数 しかし、作業を続けていくうちに、徐々にコードの書き方やテストの構造に慣れてきて、最終的には1日あたり18件のプルリクエストを作成できるようになりました。 2024/12/01〜2025/04/30までの1週間あたりにPR作成数 現在とこれから 5ヶ月間の修行を通して、生成AIや目新しい技術の前に、まず基礎を固めることが大切だと実感しました。これからは、基礎力upをベースに生成AIを適切に活用しながら、より品質を高めていきたいと考えています。 現在は、生成AIをピンポイントで利用しています。以前と違って、出力結果を鵜呑みにはしていません。コードリーディングの補助や、命名の提案など、具体的なタスクに対して活用しています。 登壇資料 Speaker Deckで資料を公開しました。 「生成AIを"おあずけ"された私〜自力で書く力がついた半年間〜」 speakerdeck.com おわりに 今回のLTでは、生成AIが当たり前になった時代において、ジュニアエンジニアとしてどう成長していくべきかについて、私自身の経験をもとにお話ししました。 生成AIは非常に強力で便利なツールですが、それを本当の意味で使いこなし適切に活用していくためには、基礎的な技術力やプログラミングの根本的な理解が不可欠だと感じています。 私はまだまだ成長途中ですが、この5ヶ月間の修行を通じて、焦らず地道に基礎を固めることの大切さを実感しました。同じようにキャリアをスタートした皆さんにとって、私の実践と学びが技術とキャリアを次のステージへ進めるヒントになれば幸いです。 最後に、このような貴重な機会をくださった翔泳社の皆さま、そして当日ご参加いただいた皆さまに心より感謝申し上げます。ありがとうございました！ ファインディでは共に働く仲間を募集中です！ 興味がある方はこちらから↓ herp.careers

こんにちは！ファインディのTeam+開発部の甲斐（ @karukan013L23 ）です。この記事は 🎄ファインディエンジニア #1 Advent Calendar 2025 7日目の投稿です。 adventar.org 去年まで1度も登壇したことがなかったのですが、今年は次の3つのイベントに登壇しました。 2025/6/25: Mita.ts #6 2025/8/20: すごくすごい。フロントエンドミートアップ 〜複雑GUI・アーキテクチャ設計を語ろう 〜 2025/11/23: TSKaigi Hokuriku 2025 今回は、登壇経験のなかった私が登壇に挑戦したきっかけや、各イベントの登壇内容、そして登壇を通して得られた学びについて紹介します。 登壇のきっかけ Mita.ts 登壇内容 登壇してみて すごくすごい。フロントエンドミートアップ 〜複雑GUI・アーキテクチャ設計を語ろう 〜 登壇内容 登壇してみて TSKaigi Hokuriku 2025 登壇内容 登壇してみて 登壇準備でやってよかったこと 1. 登壇内容の壁打ち 2. 話したいことをとにかく書き出す 3. 登壇時に話す内容を全てスピーカーノートに書き出す、発表練習を繰り返してブラッシュアップ 4. 登壇資料のレビュー依頼 まとめ 登壇のきっかけ きっかけは、TSKaigi 2025の懇親会でした。来年のTSKaigiはプロポーザル出して登壇してみたいねと懇親会の参加者の方と一緒に話していました。私はまだ登壇したことがなかったのでそのことを話すと、「じゃあ1回登壇してみようよ」と直近登壇できそうなLTイベントを探してくださり、私はそのLTイベントに登壇枠で申し込みました。これが最初の登壇への一歩でした。 Mita.ts イベントリンク: https://mitats.connpass.com/event/353424/ 登壇タイトル: 「tsgoを触ってみて得た学び」 登壇資料 speakerdeck.com 登壇内容 Announcing TypeScript Native Previews でTypeScriptのGo言語実装によるコンパイラのプレビュー版の公開が発表されました。これにより、tsgoコマンドを使用することでGo言語実装版でのtypecheckが実行可能になりました。 そこで、typecheck実行時にコード量の異なるプロジェクトでどのようなパフォーマンス差が出るのかを検証しました。 実際に計測してみると、コード量が多いプロジェクトでは 8.47倍、少ないプロジェクトでも 3.14倍 の高速化を確認できました。 特にコード量が多いプロジェクトほど、Go言語による並列処理の恩恵を受けやすく、高いパフォーマンス改善効果が見られました。 調査過程で現在のTypeScriptから変わる部分や今後の動きを学ぶことができ、「調べるだけでなく実際に手を動かすことの大切さ」を実感しました。 登壇してみて 初めての登壇ということもあり、多くの反省点がありました。 特に時間管理が課題で、心の中で読むのと実際に声に出して発表するのとでは、所要時間に大きな差があることを痛感しました。大まかなメモだけで話そうとしてしまったため、想定以上に時間がかかってしまいました。 また、内容についても「とりあえず触ってみた」という域を出ず、聞き手にとっての学びやメッセージ性が弱かった点も反省です。 登壇自体は反省点が多かったですが、登壇準備はTypeScriptについて理解を深める良い機会になりました。 LT会はワイワイした雰囲気で、多くの人との交流を楽しむことができました。初めて登壇する場として、とても良かったと思います。 すごくすごい。フロントエンドミートアップ 〜複雑GUI・アーキテクチャ設計を語ろう 〜 弊社が会場スポンサーを務めるイベントで、「登壇してみないか？」と社内で声をかけていただきました。 1度登壇したことで登壇に対する心理的ハードルが下がっていたこともあり、せっかくの機会なので挑戦することにしました。 イベントリンク: https://formx.connpass.com/event/364158/ 登壇タイトル: 「AI疲れに効く、フロントエンドのワークフロー整備」 登壇資料 speakerdeck.com 登壇内容 生成AIによるコーディングが普及する一方で、AIが生成したコードのレビューや手直しによる「AI疲れ」という新たな課題も生まれています。そこで、AIと安全に協業しつつ開発速度を維持するための「守り」と「高速化」のワークフロー整備について紹介しました。 具体的には、「守り」としてTypeScriptやESLintによる静的解析、Nxによるモジュール境界の強制、Vitestを用いた自動テスト、フィーチャーフラグの導入などを行っています。 また、「守りの高速化」のアプローチとして、Nxの変更検知とキャッシュ機能を活用し、影響範囲のあるプロジェクトのみをCI対象に絞り込んでいます。さらに、GitHub ActionsのRunnerスペックを負荷に合わせて最適化することで、CIの実行時間を短縮しています。 これらの仕組みは元々開発効率と品質のために構築したものですが、結果としてAI時代においても強固な土台として機能しています。 登壇してみて 今回は弊社のフロントエンドテックリードに壁打ちをお願いし、方向性をしっかりと固めてから準備に入りました。「フロントエンドのワークフロー整備」という範囲が広いテーマでしたが、「AIに好き勝手させないための守りと高速化」という軸が決まっていたので、話す内容の取捨選択がしやすかったです。 当日は緊張しましたが、スピーカーノートをしっかり準備して練習していたおかげで、落ち着いて話すことができました。 TSKaigi Hokuriku 2025 弊社がGoldスポンサーとして協賛していたイベントです。 一般公募のプロポーザルは残念ながら不採択だったのですが、スポンサーLT枠として登壇の機会をいただきました。 イベントリンク: https://hokuriku.tskaigi.org/ 登壇タイトル: 「Nxはいいぞ！monorepoプロジェクトにおける差分検知を活用した型チェック最適化」 登壇資料 speakerdeck.com 登壇内容 プロジェクトのコード量増加に伴い、CI実行の実行時間が増加する課題に対して、Nxの差分検知とキャッシュを活用したCI高速化の手法を紹介しました。 Nxは、モノレポやアプリケーションのビルド、テスト実行、コード生成などの機能を備えた統合的なツールです。ファインディの多くのフロントエンドでも採用されています。主な特徴として、タスク実行の並列化、変更検知、キャッシュ活用によるCI実行の効率化があります。 Nxは変更があったプロジェクトと、それに依存関係のあるプロジェクトのみを対象にコマンドを実行します。これにより、typecheckなどのタスクの不要な実行をスキップでき、依存関係が小さい変更ほどCIが早く終わるようになります。 Nxの恩恵を最大限受けるためにはプロジェクトの依存関係を適切に整理することが重要です。コード量の増加によるCI実行時間の増加や開発体験の低下に課題を感じたら、ぜひNxのことを思い出してください！ 登壇してみて 元々プロポーザルを出していた内容だったため、ターゲット（モノレポ構成やCI時間に課題を感じている層）と伝えたいメッセージを明確にできており、登壇準備を進めやすかったです。 4分間のLT枠だったため、短い時間の中で「何を伝えればNxの良さが響くか」を意識して構成を考えました。結果、制限時間ギリギリではありましたが、伝えたいポイントはしっかり届けられたと感じています。 ちなみに、TSKaigi Hokuriku 2025については、同日参加したメンバーも記事を投稿していますので、イベントの雰囲気が気になる方はぜひ併せてご覧ください！ tech.findy.co.jp note.com 登壇準備でやってよかったこと これら3回の登壇を通して、特にやってよかったなと思った取り組みを紹介します。 1. 登壇内容の壁打ち 登壇内容の方向性、軸を決めるためにテックリードや他の登壇予定の方と壁打ちをすることです。 自分だけで登壇内容を考えると、何か足りないと感じたり範囲が広すぎて軸を定められないなど迷うことがあります。 必ずしもひとりで考えきる必要はありません。迷いがあったら壁打ちをお願いしてみることをおすすめします。 2. 話したいことをとにかく書き出す 「話したいこと」をとにかく書き出しました。 一度書き出すことで、自分自身の理解の曖昧な部分が浮き彫りになり、調査をして理解を深めるきっかけになりました。 調査の過程がそのまま学びの機会になるため、おすすめです。 3. 登壇時に話す内容を全てスピーカーノートに書き出す、発表練習を繰り返してブラッシュアップ いわゆる「台本」を作ることです。 話す内容を全て文字に起こすことで、説明の言い回しや構成に違和感がないかを確認できます。 また、実際に声に出して読んでみると「この表現は伝わりにくい」「ここは順序を入れ替えたほうがいい」といった気づきが得られます。 発表練習を繰り返してスピーカーノートを直し、時間配分を調整することをひたすら繰り返すことで、本番で落ち着いて話すことができるようになります。 4. 登壇資料のレビュー依頼 資料ができたら、テックリードや社内のエンジニアにレビューをお願いしました。 作り手視点だけでは気づけない「説明の誤り」や「わかりにくい表現」を指摘していただき、勉強になりました。 また、会場が大きいので、文字が小さいと後ろの席から見えないから限界まで文字サイズを大きくした方が良いといった、登壇経験者ならではの実践的なアドバイスもいただき勉強になりました。 まとめ 登壇に挑戦することで、技術の理解を深めるよい学びの機会となりました。 聞き手にわかりやすく説明するためには、自分自身がその技術を深く、体系的に理解している必要があります。曖昧だった知識を補完し、学び直すプロセスそのものが、エンジニアとしての成長に繋がったと感じています。 これからも、登壇やブログ執筆といったアウトプットの機会を大切にし、自分自身の学びの場として活かしていきたいと思います。 ファインディでは一緒に働くメンバーを募集しています！ 興味がある方はこちらから ↓ herp.careers

キャリアプロダクト開発部の森 ＠jiskanulo です。 この記事は、 ファインディエンジニア Advent Calendar 2025 の6日目の記事です。 adventar.org 現在Findyにて「うちのAIがやらかしまして」という企画ページを期間限定で公開しております。 https://findy-code.io/ai-yarakashi findy-code.io 「うちのAIがやらかしまして」はAIとの協働で生まれた“試行錯誤のエピソード”を投稿してもらう参加型企画です。 AIのやらかし・すれ違いをシェアし、皆さんの前向きな学びにつなげていく場を提供いたします。 今回は私のAIやらかし事例を紹介しつつ、同じやらかしを再度起こさないようにするため心がけることをご紹介します。 私のやらかし事例はいずれもClaude Codeの利用で起きたものですが、他のAIエージェントを活用されている方にも参考になれば幸いです。 AIやらかし事例の紹介 コードレビューに意図してないコメントを残された Pull Requestに関係ないファイルがコミットされていた 同じやらかしを繰り返さないために おわり AIやらかし事例の紹介 コードレビューに意図してないコメントを残された GitHubのコードレビュー内容を確認して、と指示を出したら対応するつもりのない内容をコメントとして残されてしまい慌てて訂正した findy-code.io このやらかしの原因は、私の指示が曖昧だったことです。 「コードレビューを確認して」と書いたつもりでしたが、「コードレビューを確認して 対応して 」と指示してしまったため、Claude Codeはそのレビューに返信コメントを投稿してしまったわけです。 コンソールを眺めていたらgh issue commentコマンドを発行しているのに気づき、慌てて訂正しました。短期間に正反対のコメントを連投しレビュアーに迷惑をかけてしまったやらかしです。 Pull Requestに関係ないファイルがコミットされていた 作業指示を出し、Pull Requestを作成してもらった。Pull Requestを確認すると作業指示に入っていないファイルもコミットされていた findy-code.io コミットされていたファイルは別のタスクでCLAUDE.mdの記述調整を依頼した際に作成された一時的なファイルでした。 Claude Codeが git add -A で全ファイルをコミット対象に追加し、そのままコミットを作成してしまったのです。 同じやらかしを繰り返さないために これら2つのやらかしを踏まえ、同じミスを繰り返さないための対策を整理します。 曖昧な指示が来た時に、Claude Codeに指示の内容を確認するようCLAUDE.mdに記載を追加しました。 これで思いがけない行動を取ってしまうことが減りました。 指示に不明な点や曖昧な点がある場合、作業を進めずに質問を返してください。 次に、指示が終わった後に意図しない挙動を示した場合、どうしてそうなったのか質問をし、回答を求めます。 以下は私が対話した内容の抜粋です。 私: 先ほど不要なファイルのcommitが混ざってしまった事象について、どうして起きてしまったのか、どうすれば再発を防ぐことができるか検討して提案して Claude: ⏺ CLAUDE.md.backupファイルが誤ってコミットされた原因と再発防止策を分析しました 原因分析 何が起きたか 1. PR #51 (docs-restructure-claude-md) でCLAUDE.mdのバックアップを作成 # 当時の作業 cp CLAUDE.md CLAUDE.md.backup 2. PR #51マージ後、mainから新ブランチを作成 3. git add -A で全変更をステージング 4. CLAUDE.md.backupがワーキングディレクトリに残っていたため、意図せずコミットに含まれた 根本原因 - ✅ バックアップファイルを作業後に削除しなかった - ✅ git add -A が全ファイルを無条件に追加した - ✅ コミット前のステージング内容確認を怠った 再発防止策 … これ以降、対話を続けて方針を定めました。 対話してまとめた内容をCLAUDE.mdに記載させ、次回以降同じことを起こさないようにしました。 内容が冗長だったり逆に限定的で不足している部分もありますが都度調整していきます。 最終的にCLAUDE.mdに追加した内容は次の2点です。 コミット前にステージングされているファイルを確認すること 意図していないファイルが含まれていないことを確認すること #### コミット前の確認 ```bash # ステージングエリアの確認 git status # 意図していないファイルが含まれていないことを確認 git diff --cached --name-only ``` おわり AIエージェントは最初から100％期待に沿う行動をしてくれるわけではありません。 いい加減な指示を出すと思いがけないふるまいをやらかしてしまいます。 時にはやらかしつつ、やらかしを再発防止策を考えて対策し、共に成長していくパートナーとして触れ合っていきましょう。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらからからご応募ください。 herp.careers

はじめに みなさんこんにちは。Platform 開発チーム SREでサブマネージャーの安達（ @adachin0817 ）です。この記事は、 ファインディエンジニア Advent Calendar 2025 の5日目の記事です。今回は2025年のSREチームの成果や課題などを振り返りたいと思います。 adventar.org はじめに Platform SREチーム ビジョンの再定義 2025年のPlatform SREロードマップ 主に取り組んできたこと Devinの活用 Terraform汎用モジュールとtestの拡充 Findy Team+ 本番DBクローン ワークフロー化 Findy Team+ AWSマーケットプレイス対応 Takumi SAST/DASTの導入 2026年に向けた展望と課題 おわりに Platform SREチーム ビジョンの再定義 「SREの文化を組織全体に根付かせ、開発チームが自律的にSREを実践できるように支援する」 このビジョンを元に、Platform開発チーム SRE(以下、Platform SRE)チームの方向性を再定義しました。これまでもビジョン自体は存在していたものの、メンバーの役割や責任範囲など曖昧で、チームとしてどう実現していくのかが十分に描き切れていませんでした。そのため、2025年に向けてビジョンをブラッシュアップし、具体的な行動指針へと落とし込みました。 また、ミッションは半期ごとに見直す運用へと変更しました。従来は年間を通して固定したミッションで動いており、課題や状況など大きく変化することが分かりました。そのため、より柔軟な意思決定と、チームメンバーの意志を反映できる仕組みにアップデートしました。 次は、2025年 Platform SRE ロードマップを解説します。 2025年のPlatform SREロードマップ AI活用 DevinやAI補助による運用・構築の自動化 Observability SLI/SLOの見直し Datadog RUMの検証 Cost パフォーマンス予測モデル導入 MCPによるコスト最適化 Security アプリケーション脆弱性対応 Takumi導入 Shisho Cloud棚卸し Infrastructure Team+ 本番DBクローン ワークフロー作成 Tools/Conference 本番DBのためのStgマスキングワークフロー作成 負荷試験環境 ログ基盤の設計 WordPressをShifterに移行 Terraform汎用モジュールの拡充 aws-nukeによる不要リソースの自動削除 Findy Team+ マーケットプレイス対応 CI/CD デプロイの共通化 GitHub Actionsのテンプレート化 ecspressoの導入 Automation 社内ツール実装(Go) 新規AWSアカウント作成業務の自動化 Onboarding 新規ジュニアメンバー教育 Culture SRE文化醸成 2025年のPlatform SREチームは、開発チームが自律的にSREを実践できる組織を目指し、8つの領域にフォーカスしてロードマップを策定しました。単なる改善タスクではなく、SREを仕組みと文化としてチームに埋め込むことを重視しています。 次は特に注力した取り組みについてまとめていきます。 主に取り組んできたこと Devinの活用 SREチームでは、新サービスが追加されるたびに、Shisho CloudとAmazon Security LakeをTerraformで連携しています。しかし、この設定手順は非常にシンプルでありながら毎回人手で作業することがトイルとなっていました。 そこで、Devinを活用した自動化に取り組み、Terraform連携を含む一連の作業をワークフロー化しました。さらに、GitHubアカウントの発行、AWSアカウントの作成、WordPressの軽微な修正などもDevin化し、SREのトイルを大きく削減できています。今後は、これらの仕組みを横展開し、より広く標準化していく予定です。 tech.findy.co.jp Terraform汎用モジュールとtestの拡充 tech.findy.co.jp 今年からは、新サービスをより高速に構築するため、Terraformによる汎用モジュールの整備に本格的に取り組みました。 これまでは既存コードの流用をベースに構築していたため、設定の漏れや環境差異を適切に把握できない状態が続いていました。 その課題に対し、Terraformの汎用モジュール化と Terraform Test の拡充することで、Apply前に失敗や設定ミスを検知できる仕組みを構築しました。これにより、信頼性を担保しながらもスピード感のあるインフラ構築が実現できるようになったと感じています。 Findy Team+ 本番DBクローン ワークフロー化 これまでは、Embedded SREが手動で本番DBのスナップショットを取得し、開発チームがそれを基にバッチテストや検証していました。しかし、テスト環境の構築に時間がかかるだけでなく、実際の運用に近い再現性が担保しづらいという課題がありました。 そこで、2025年からは 本番DBクローンを自動で生成できるワークフローを実装しました。この仕組みにより、バッチ処理を含むパフォーマンステストや検証作業を誰でも再現性高く実施できる環境が整備されました。安全性の確保にも配慮し、クローンDBは本番DBと隔離された環境で動作、アクセス制御を厳格に適用、本番相当のデータでテスト可能という形で、リスクを防ぎつつ、実運用に近いテスト環境を実現しています。 クローンDBの作成および削除は、すべてAWS CLIによるワークフローとして自動化しています。また、バッチのパフォーマンステストについては、Operationコンテナ上でAPIと同等の環境を再現しており、本番に近い条件での検証を行えるようになりました。 Findy Team+ AWSマーケットプレイス対応 aws.amazon.com Findy Team+では、AWSマーケットプレイスへの掲載準備が本格的に始まりました。これまでの直契約モデルから、AWS経由で利用できるモデルという選択肢が増えます。特にエンタープライズ企業では、調達プロセス・セキュリティ基準・契約形態・監査プロセスなどのハードルが高く、SaaS導入の初動でつまずくケースが少なくありません。その中で、AWSマーケットプレイス経由の契約であれば調達がスムーズになるため、AWS経由で使えることが導入条件になる企業でもTeam+導入の壁がさがることを期待しています。 今回の対応により、Findy Team+はエンタープライズ向けのSaaSとしての提供価値をより明確にしていくフェーズに入ったと考えています。 Takumi SAST/DASTの導入 flatt.tech Shisho Cloudを運用していく中で、アプリケーション層の脆弱性も同じ仕組みで検知・可視化したいという課題が生まれました。そこで、コード診断に特化した Takumi（SAST / DAST）を全サービスへ導入し、セキュリティ領域の基盤整備を進めました。 SASTによる静的解析ではコードの脆弱性を早期検知できるようになり、DASTによる動的解析では実行可能な攻撃パターンの再現・検証ができるようになりました。その結果、「診断 → 可視化 → 修正 → 再検証」 というサイクルが開発メンバーの中で自然と回り始め、SREチームによる支援型セキュリティの形が実際に機能し始めています。 また、DASTによるブラックボックス診断については、来年のSRE Kaigi 2026でもGMO Flatt Security CTO 米内さんと発表予定です。セッションではAI時代におけるセキュリティ戦略や、その実践的な導入アプローチについて具体的にお話しますので、ぜひご参加いただき、これからのセキュリティの在り方を一緒に考える機会にできれば嬉しいです。 ／ #srekaigi 協賛します！ ＼ GMO Flatt SecurityはSRE Kaigi 2026にダイヤモンドスポンサーとして協賛いたします！ ファインディSRE 安達様 @adachin0817 と弊社CTO 米内 @lmt_swallow によるスポンサーセッションも予定しています！ ぜひお越しください💁🏻‍♂️ https://t.co/HvZtuL7rBL — GMO Flatt Security株式会社 (@flatt_security) 2025年11月12日 2026年に向けた展望と課題 来年はSREチームとして、今年の取り組みを「仕組みを作る段階」から「仕組みを運用し、継続的に改善していく段階」へ移行していく予定です。単にSREの知識を展開するだけではなく、開発チーム自身が自律的にSREの判断・運用ができる状態を、より強く推進し、Enablingしていきたいと考えています。 おわりに 2025年は、SREチームにとって仕組みづくりと文化づくりの両輪で走り続けた1年でした。振り返ってみると、改善することよりも、なぜ改善するのか？どうあるべきなのか？を問い続ける1年だったように感じます。 まだまだロードマップは対応できていないものもたくさんあるのと、来年は今年つくった仕組みを本格運用フェーズへ進めつつ、開発チームが自律的にSREを実践できる組織づくりに挑戦していきます。 明日はjiskanuloさんになります！見ていただきありがとうございました。

こんにちは、ファインディCTOの佐藤( @ma3tk )です。この記事は、 ファインディエンジニア #1 Advent Calendar 2025 と ファインディデザインチーム Advent Calendar 2025 の4日目の記事です。 先日、 Findy AI+ という新規プロダクトのデザインシステムを1から設計しました。 片手間ながら1人で2〜3週間かけてベースの設計を仕上げた結果、これからのデザインシステムは「コードで管理すること」が不可欠だという思いが強くなりました。 なお、Figmaとコードの関係性の変化やAI時代における開発フローの変化など、関連するテーマは多くありますが、今回は「なぜコードで管理するのか」という背景を中心にお伝えします。 ユーザーと同じ環境でものを見る デザインツールと実装環境の違い コードで管理する最大の価値 型の力で強制できる 無理やり実装を防ぐ仕組み コードだからこそ実現できる強制力 最初から徹底できる 後付けでは浸透しない AI時代の開発スピードに対応する デザインをコード管理することは必要不可欠 Figma Schemaが示す方向性 ユーザーと同じ環境でものを見る デザインツールと実装環境の違い 従来のワークフローでは、Figmaなどのデザインツールでデザインを作り、実装はそれに追従する形でした。Figmaは優れたデザインツールですが、そこで見ている画面と、ユーザーが実際に触るプロダクトは異なる環境です。 デザイナーが意図した色やスペーシングが実装段階で微妙にズレることもあります。また、レスポンシブ対応で想定外の挙動が起きることもあります。デザイン時と実装時での乖離は、デザインツールと実装環境の違いから生まれる課題です。 例えば、ボタンの角丸が場所によって4pxだったり8pxだったり、余白が16pxと20pxで混在したりといった問題です。Figmaでは統一されているように見えても、実装では微妙に異なる値が使われることもあるでしょう。 これは、デザインツールと実装環境という2つの異なる場所で管理しようとすることの難しさです。 プロダクト開発に関わるメンバーが最も注目すべきは、プロトタイピングの画面ではなく、ユーザーが触る実際の画面だと考えます。 コードで管理する最大の価値 「ユーザーと同じ環境で、ものを見ることができる」 これがコード管理における最大の価値だと思います。 コードをマスターにすることで、実装された状態が常に正しい状態となります。 どれだけデザインツールで美しく見えていても、ブラウザで崩れていたら意味がありません。コードをマスターにすることで、デザイナーとエンジニアが「ユーザーが見ているもの」を直接触りながら改善できるようになります。 FigmaプラグインのToken StudioやCode Connectを使えば、コードで定義したトークンをFigmaに反映できます。つまり、Figmaでのデザイン作業は今まで通り行いながら、真実の情報源(Single Source of Truth)はコードに置くことができるのです。 効率化の話だけではなく、ユーザー体験の品質そのものに関わる問題だと捉えられます。 型の力で強制できる 無理やり実装を防ぐ仕組み Findy AI+の設計で最も意識したのは、「デザインシステムから逸脱できない仕組み」を作ることです。 テーマを作った後、実際にデザインシステムを適用させようとすると、無理やり実装しがちです。 css= や style= のような直接スタイルを当てる方法を使ってしまうケースです。 一度この逃げ道を許すと、デザインシステムは形骸化します。「急いでいるから今回だけ直接スタイルを当てよう」が積み重なり、気づけば誰も使わないものになってしまいます。 コードだからこそ実現できる強制力 Findy AI+では、Chakra UIをベースにデザインを行っています。Chakra UIのStrict Tokenモードを導入し、ESLintのルールを整えました。さらに、CLAUDE.mdとClaude Skillsでルールを明文化し仕組みを整え、生成AIにもデザインシステムを守らせるようにしました。 すると、エンジニアは必ずデザインシステムで定義されたトークンやコンポーネントを使わざるを得ない状況になります。例えば、直接スタイルを当てようとすると、Lintエラーが出てしまいます。 この強制力があることで、デザインシステムを形骸化させない鍵になると考えています。そして、この仕組みは今後デザインツールでできるようになるかもしれませんが、現在はまだ実現できません。コードで管理するからこそ、型の力で強制できます。 デザインされたものを一からコンポーネントとして実装するには多大な設計が必要です。しかし、Findy AI+では最初からデザインシステムをコードで定義し、逸脱できない仕組みを整えてきました。その結果、開発者が迷わずに実装でき、ルールが統一しつづけられる環境を作りました。 最初から徹底できる 後付けでは浸透しない デザインシステムの導入で最も難しいのは、浸透させることです。 すでに動いているプロダクトに後からデザインシステムを導入しようとすると、既存のコードとの整合性を取る作業が膨大になります。そして、その移行期間中は「デザインシステムを使っている部分」と「使っていない部分」が混在し、一貫性が失われます。 既存のプロダクトでも徐々にデザインシステムを適用していっていますが、浸透するまでに時間がかかります。デザインとしての一貫性がない状態からのスタートだったり、エンジニアがコンポーネントを置き換える作業が必要だったりと、後付けの導入には多くの障壁があります。 AI時代の開発スピードに対応する AI時代の開発スピードを考えると、後から統一する時間的余裕はありません。 最初に型を作り、デザインシステムを稼働させながら作ることがAI時代の作り方だと考えています。 Findy AI+では、プロダクト開発の初期段階からデザインシステムをコードとして定義し、そこから逸脱できない仕組みを整えました。この「最初から徹底」を実現するには、コードで管理することが不可欠です。 デザインをコード管理することは必要不可欠 Findy AI+でのデザインシステム設計を通じて、「なぜコードで管理することが不可欠なのか」を改めて実感しました。 ここまでを改めてまとめると、コードで管理すべき理由は大きく3つです。 ユーザーと同じ環境でものを見ることができること 型の力で逸脱を防ぐ仕組みが作れること プロダクト開発の初期段階から徹底して効率を上げられること デザイナーとエンジニアの両者が、デザインシステムの重要性を理解し、そして「コードで管理すること」の価値を理解していただけたら幸いです。 Figma Schemaが示す方向性 ちょうど先日、Figmaが「Schema」というイベントで 発表した内容 がこの考え方と合致していました。 Figmaの方針として、デザインシステムを「AIが読み取りやすいルールブック」として整備する方向に舵を切っています。Code Connect UIでFigmaコンポーネントとGitHub上のコードを紐付ける機能が発表されました。Figma MCP ServerでAIツールからFigmaデータを参照しやすくする機能も登場しています。VariablesのエクスポートでFigma変数をコードへ持っていきやすくなるなど、「FigmaデータとコードをつなぐAI前提の機能」が続々と出てきています。 この流れは、本記事で述べた「コードで管理する」という考え方を後押ししてくれるものだと感じています。Figmaは引き続き強力なデザインツールとしてプロトタイピングに活用しながら、ユーザーが見る実コードに主眼を置くことが大事だなと改めて思いました。 なお、今回は「Why」を中心にお伝えしましたが、FigmaとCode Connectの連携方法、Token Studioの活用、Storybookでの運用など、具体的な「How」についても今後記事にしていきたいと思います。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味がある方はこちらから ↓ careers.findy.co.jp

こんにちは！ファインディのTeam+開発部の大石（ @bicstone ）、甲斐（ @karukan013L23 ）です。先日、ファインディは2025年11月23日に石川県金沢市で開催された「TSKaigi Hokuriku 2025」に協賛しました。 今回は、Findy Conferenceメンバー、DevRelメンバー、Team+開発エンジニアの6名で参加しました。 本記事ではTSKaigi Hokuriku 2025において印象深かったセッションの紹介や、登壇・ブース出展などの活動内容を紹介します。 この記事は 🎄ファインディエンジニア #2 Advent Calendar 2025 3日目の投稿です。 adventar.org TSKaigi Hokuriku 2025について 印象深かったセッション TypeScript 6.0で非推奨化されるオプションたち tsc --init の設計思想の変化とその背景を追う - “教育的”アプローチから実用性重視への転換 アルゴリズムの専門家と挑むフロントエンド実装 − 複雑なロジックを支える設計とパフォーマンス最適化 Welcome to the “Fantasy Land” 🧚 − 代数的構造をめぐる冒険 − 登壇 大石: TS 5.9 で使えるようになった import defer でパフォーマンス最適化を実現する 甲斐: Nxはいいぞ！ monorepoプロジェクトにおける 差分検知を活用した型チェック最適化 ファインディの活動 DrinkUpイベント ブース出展 Findy Conferenceによるイベント管理 さいごに お知らせ TSKaigi Hokuriku 2025について TSKaigiは日本最大級のTypeScriptをテーマとした技術カンファレンスです。 石川県金沢市のホテル金沢にて、2025年11月23日に開催されました。 hokuriku.tskaigi.org 印象深かったセッション 興味深いセッションが多くありましたが、その中でも特に印象に深かった4つのセッションを紹介します。 TypeScript 6.0で非推奨化されるオプションたち hokuriku.tskaigi.org TypeScript 6.0は7.0に向けた準備としての側面が大きいバージョンであり、機能追加というよりメンテナンス性向上のための仕様の整理とパフォーマンス改善に重きを置かれていることについて学びました。 target: es5 へのトランスパイルや moduleResolution: classic など、非推奨になるオプションを見ると今の開発では使われなくなりつつあるものが多く、現代の環境に合わせた変更となっています。こうして廃止されていくオプションを見ていると、TypeScriptとその周辺環境の移り変わりの歴史を垣間見ることができ面白かったです。 非推奨になるもの以外に、 alwaysStrict や types 、 rootDir などデフォルトの動作が変更になるものがあるため、移行する際は注意が必要です。 非推奨となるオプションが廃止されるTypeScript 6.5までまだ猶予はありますが、徐々に対応を進めていきたいです。 tsc --init の設計思想の変化とその背景を追う - “教育的”アプローチから実用性重視への転換 hokuriku.tskaigi.org 元々 tsc --init で生成されるtsconfig.jsonは全てのオプションと大量のコメントが出力されていましたが、これらがどう見直されたかについて学びました。 ES Modulesを推進したいのにCommonJSの設定がデフォルトになっていたり、テキストの壁と表現されるほどの大量のコメントアウトされたオプションが表示されるなどの課題がありました。 新しい方針ではコメントアウトされたオプションを削減し、必要最小限かつ推奨される設定のみを含むシンプルな設定に変更されました。 こちらの Issue で tsc --init のアップデートに関する議論されています。手元で新しいtsconfig.jsonを確認しつつIssueを覗いてみると面白そうです。 アルゴリズムの専門家と挑むフロントエンド実装 − 複雑なロジックを支える設計とパフォーマンス最適化 hokuriku.tskaigi.org 今回初の取り組みであるチーム発表のセッションです。チーム発表は、同じプロジェクト・チームでの取り組みを、異なる立場・役割の2名がそれぞれの視点から語る形式となっていました。本セッションはアルゴリズムの専門家とフロントエンドエンジニアの組み合わせの登壇となっていました。 それぞれの専門性を活かしつつ、共同資産として活用するためのWebAssemblyの採用は興味深かったです。WebAssemblyとJavaScriptのメモリ構造の違いや、ロジックをWebAssemblyとフロントエンドのどちらで実装するかの判断軸など、それぞれの立場からのお話を聞くことができました。 次回以降チーム発表のセッションがあるかは分かりませんが、面白い形式だったので次回以降も枠があると嬉しいです。 Welcome to the “Fantasy Land” 🧚 − 代数的構造をめぐる冒険 − hokuriku.tskaigi.org このセッションでは、プログラミングにおける代数的構造とFantasy Landという仕様について紹介されました。代数的構造とは、集合と演算に対してどのようなルールを満たすのか定めるものです。 具体的な例を挙げると、統合律（どの順序で演算しても結果が変わらないという法則）と単位元律（単位元 e と演算しても、元の要素 a の値が変わらないという法則）を満たすと、モノイドという代数的構造になります。 統合律 a・(b・c) = (a・b)・c 単位元律 a・e = e・a = a TypeScriptで表現すると、次のような実装になります。 // T: モノイドの要素の型 interface Monoid < T > { // 単位元（e）を返すメソッド mempty : () => T ; // 二項演算（•）を行うメソッド mappend : ( x : T , y : T ) => T ; } // 2. 文字列モノイドの実装 (単位元: ""、演算: +) const StringMonoid: Monoid < string > = { mempty : () => "" , mappend : ( x , y ) => x + y, } ; Fantasy Land は、プログラミングで頻出する代数的構造を体系化し、満たすべきルールをまとめた仕様です。TypeScriptのPromise型とResult型を例に共通の構造を探索していき、Fantasy Landで定義されたChainの仕様に抽象化していく過程は、普段とは違った視点でコードの構造を見ることができ面白かったです。 Fantasy Land自体はClassの利用を前提としているためすぐに活用することは難しいですが、より良い構造を探索するために代数的構造を活用するという視点はとても参考になりました。 登壇 ファインディからはCfP枠より大石、スポンサーLT枠より甲斐が登壇しました。それぞれの発表内容を紹介します。 大石: TS 5.9 で使えるようになった import defer でパフォーマンス最適化を実現する speakerdeck.com TypeScript 5.9で利用可能となる新機能「import defer」を用いたパフォーマンス最適化について解説しました。 TC39 Stage 3の提案であるこの機能は、モジュールの「取得・解析」を即座に行う一方で、トップレベルの「評価（実行）」を実際にプロパティにアクセスする瞬間まで遅延させるものです。これにより、従来の動的import（dynamic import）のように非同期処理（Promise）を扱う複雑さを避けつつ、同期的な構文のままで初期ロード時のCPUコスト（TBT）を削減できる利点があります。 具体的な活用例として、モーダルのような「ユーザー操作時に初めて必要となる機能」の評価を遅らせるパターンを紹介しました。また、利用にはtsconfig.jsonの設定変更が必要であり、現時点でランタイムやバンドラは実験的な対応にとどまる点にも言及しつつ、2026年に向けた未来のパフォーマンス改善を一緒に考えようと呼びかけました。 甲斐: Nxはいいぞ！ monorepoプロジェクトにおける 差分検知を活用した型チェック最適化 speakerdeck.com Nxを活用したmonorepoプロジェクトにおけるCI実行時間の最適化について解説しました。「CIの実行時間が長すぎて辛い」という多くの開発者が抱える悩みに対して、Nxを用いた解決策を紹介しています。 Nxは、モノレポやアプリケーションのビルド、テスト実行、コード生成などの機能を備えた統合的なツールです。ファインディの多くのフロントエンドでも採用されています。主な特徴として、タスク実行の並列化、変更検知、キャッシュ活用によるCI実行の効率化があります。 Nxは変更があったプロジェクトと、それに依存関係のあるプロジェクトのみを対象にコマンドを実行します。これにより、typecheckなどのタスクの不要な実行をスキップでき、依存関係が小さい変更ほどCIが早く終わるようになります。 Nxの恩恵を最大限受けるためにはプロジェクトの依存関係を適切に整理することが重要です。コード量の増加によるCI実行時間の増加や開発体験の低下に課題を感じたら、ぜひNxのことを思い出してください！ ファインディの活動 ファインディはゴールドスポンサーとして協賛し、DrinkUpイベントの開催、ブース出展、Findy Conferenceによるイベント管理という形で支援しました。 DrinkUpイベント DrinkUpイベントの集合写真 ファインディはスポンサーとして、カンファレンス開催前日に DrinkUpイベント を開催しました。 20名もの方に参加いただき、一緒にTypeScript愛を語り合うことができました！ 良い雰囲気で進められ、当日に向けてお互いに熱量を高め合うことができたと思います。また、初対面の方々が顔見知りになり、当日の交流がスムーズになったといった声もいただき、よい機会を作ることができたと感じています。 最後には恒例のじゃんけん大会をし、限定ノベルティをプレゼント。当選した方は翌日着用して会場に来てくださいました。 ブース出展 ブース出展の様子 当日はスポンサーとしてブース出展をしました。 今回は、TSKaigiにちなんでTypeScriptに関する課題文が登場するタイピングゲームをご用意しました。 文言や称号は大石、甲斐をはじめとしたファインディのエンジニアで考案したものになります。称号はすべてダジャレにしていたり、課題文には様々なネタを仕込ませていたのですが、楽しんでいただけましたでしょうか？ 称号の一覧 難易度を高めにしていたのですが、何度も挑戦していただくなど、前向きに臨んでいただき嬉しく思います。 称号 Lv.5 "型のカタリスト" を達成された方もいらっしゃり、大変盛り上がりました。 多くの方にプレイ・シェアをしていただきありがとうございました！ Findy Conferenceによるイベント管理 今回のTSKaigi Hokuriku 2025においては、イベント管理プラットフォームとして Findy Conference を採用いただきました。 参加者の皆様からも申込、受付の体験が良いと好評をいただきました。オンライン配信も問題なくサポートできました。 TSKaigiをイベント管理プラットフォームとしての立場からも支援できたことを嬉しく思います。 さいごに TSKaigiはとても暖かい素敵なコミュニティで、いち参加者としても多くの学びと交流の機会を得ることができました。 カンファレンスの開催にあたりご尽力いただいた、運営スタッフの皆様、関係者の皆様、登壇者の皆様に感謝申し上げます。 お知らせ 同日に参加したDevRelメンバーからも記事を投稿していますので、ぜひご覧ください！ note.com ファインディでは一緒に働くメンバーを募集しています！ 興味がある方はこちらから ↓ herp.careers

こんにちは。 ファインディのPlatform開発チームでSREを担当している 大矢 です。 私たちのチームでは現在、SREのトイル削減を目指して様々な施策に取り組んでいます。今回はその1つとして、AIエージェント「Devin」を活用したユーザー管理の自動化についてご紹介します。 今回のお話 本記事で触れること 本記事で触れないこと 自動化までの歩み 1. 手動管理期 2. Iac導入期 3. AIエージェント導入期 やったこと 1. Devinのセットアップ 2. Slackワークフローの整備 セットアップを終えて なぜDevinなのか 1. 非エンジニアでも利用可能なインターフェース 2. AIならではの柔軟性 今後の展望 おわりに 今回のお話 ファインディではクラウドサービスのユーザー管理の一部をPlatform開発チームが担当しています。具体的にはAWSのユーザー作成、グループへの追加、GitHubのOrganizationへのユーザーの招待などが該当します。 2025年12月現在、AWSのユーザーとグループはTerraformによるIaC管理に加え、Slackのワークフローを利用した申請受付からDevinによるPull Request(以下、PR)作成まで自動化を実現しています。 本記事では、かつて手動で行われていた管理フローがどのような課題を抱え、Terraform x Devinの導入によってどう改善されたのか、その経緯と改善内容についてお話しします。 本記事で触れること ユーザー管理自動化までの経緯と課題感 なぜDevinを採用したのか IaC x Devinの実装内容とメリット 本記事で触れないこと Terraformコードの詳細な実装 Devinのセットアップに関する細かい技術仕様 自動化までの歩み AWSユーザー管理の手段は、組織の成長に合わせて次のように変わってきました。 手動管理期: 情シスがマネジメントコンソールから手動で作成 IaC導入期: 申請者またはSREメンバーがPRを作成 AIエージェント導入期: DevinによるPR作成の自動化 1. 手動管理期 かつては、情シスがユーザー追加の依頼を受け、AWSマネジメントコンソールから手動でIAMユーザーを作成していました。転機となったのはファインディのAWSアカウント構成を見直すタイミングです。ユーザー管理をIAM Identity Centerへ移行し、これを機にTerraformによるIaC管理を開始しました。 2. Iac導入期 IaC化により、ユーザー管理はソースコードベースでおこなわれるようになりました。フローとしては、申請者がSlackのワークフローからの申請と、Terraformのリポジトリへ申請の内容に基づいたPRを作成するという形です。 ユーザーが作成されるまでの流れは次のとおりです。申請者がTerraformの構造を理解する必要はなく、所定のYAMLに所定のフォーマットを追加するだけです。 これにより、ユーザー管理の透明性は向上しましたが、運用を続ける中で新たな課題が浮き彫りになりました。 非エンジニア対応の負荷: エンジニアであれば自分でPRを作成できるが、非エンジニアの場合はGit操作が難しく、SREメンバーが代行してPRを作成する必要があった コンテキストスイッチの発生: 社員数の増加に伴い、特に月末月初にはユーザー追加申請が集中する。1件あたりの作業時間は短くても、申請内容の確認、Git操作、PR作成、レビュー依頼といった作業が五月雨式に発生することで、本来の業務が頻繁に中断されていた 「作業自体は単純だが、頻度が高く集中力を削ぐ」。これはまさにSREが削減すべき「トイル」そのものでした。 3. AIエージェント導入期 これらの課題から、「ユーザー追加業務は定型化された繰り返し作業であり、人間が手を動かす必要はない」という結論に至りました。そこで、自律的にタスクをこなせるAIエージェント「Devin」にこの業務を任せることにしました。 やったこと 具体的な実装例として、AWSユーザー追加におけるDevinの設定とフローを紹介します。 1. Devinのセットアップ Machineのセットアップをおこないます。Devin導入当初、KnowledgeやPlaybookは使用できず、Repo Noteに次のような自然言語による指示を記述しました。 - ユーザーの追加 - ユーザーの情報は以下のファイルで管理している - <ユーザー管理ファイルへのPATH> - ユーザーを追加する際は、以下の4項目が必要 - display_name - email - user_name - group - 前述の4項目には以下の情報を入れる - display_name はAWSのユーザのコンソールに表示される名前 - email はユーザのメールアドレス - user_name はAWSのユーザの名前 - group はAWSのユーザが登録されるグループ名 - ユーザーを追加する際は、display_nameをアルファベット順で並べる - ユーザーの削除 - 対象となる項目はユーザー追加時と同じ - 下記のユーザーを管理するファイルからAWSユーザーを削除 - <ユーザー管理ファイルへのPATH> - PRのコミットメッセージのタイトルはConventional Commitsに従うこと - ユーザーの追加、削除、変更は`chore: `とする - 申請者をPRのAssigneesに設定して - 申請者はSlackのIDだが、次のリポジトリにGitHubのIDとのマップがあるので、それに従い変換して - <SlackとGitHubのIDをマップしたファイルへのPATH> - 申請者のGitHubユーザーが特定できなかった場合、PRにコメントを残して - 処理は必ずPRを作成するところまで完了させて 上記のとおり、しっかり構造化されていない状態でもほぼ期待どおりに動きます。まずは実践するとよいでしょう。 2. Slackワークフローの整備 Devinを操作するためのインターフェースとして、専用のチャンネルとSlackワークフローを用意しました。 エンジニアだけでなく非エンジニアも利用するため、CLIツールなどではなく、誰もが使い慣れたSlackを入り口にすることが重要でした。 Slackワークフローには次の入力項目を設けています。(抜粋) 項目 設定・入力内容 変更種別 追加、変更、削除から選択 表示名(ローマ字の氏名) ローマ字の氏名 メールアドレス 申請対象者のメールアドレス グループ 事前に作成したグループ名 特記事項 イレギュラーな要望など このワークフローから投稿された内容をトリガーに、Devin（@devin）がメンションされ、指示通りにコードを修正してPRを作成します。 セットアップを終えて DevinとSlackの設定を終えた後は、次のフローでAWSユーザーの申請をおこないます。 DevinとSlackのセットアップは、初めて触る状態からでも半日もかからず完了しました。導入後は人間が対応する時間を少なくとも半分以下に削減でき、セットアップにかけた時間を大きく上回る効果を得られました。まずは小規模な定型業務から試してみることをお勧めします。 なぜDevinなのか AIによるコーディング支援ツールは多々ありますが、なぜDevinを選んだのか。その理由は主に2点あります。 1. 非エンジニアでも利用可能なインターフェース 例えばClaude CodeのようなCLIベースのツールも強力ですが、非エンジニアが利用するにはハードルが高いです。「Slackでフォームに入力するだけ」という体験を提供するためには、Slackと統合しやすく、自律的にGit操作まで完結できるDevinが最適でした。 2. AIならではの柔軟性 定型的なスクリプト処理では、例外的なケース(例: 1回の申請で2名以上追加したい場合)へ対応するため条件分岐の実装コストがかかります。 Devinの場合、ワークフローの「特記事項」に自然言語で注釈を入れるだけで、よしなに判断して処理してくれます。この「人間の曖昧な指示を汲み取れる柔軟性」は、運用コストを下げる上で非常に大きなメリットです。 今後の展望 現在はAWSやGitHubのユーザー管理だけでなく、次のような領域にもDevinの活用を広げています。 新規AWSアカウント作成時に発生する初期設定(繰り返し作業) WordPressの簡単な文言変更 DNSレコードの登録 私たちのチームでは、単純な自動化ではなくSRE x AIという視点を強く持ち、トイル削減と全社的な運用改善を推進していきます。 おわりに 今回は、ファインディで実践しているTerraformとDevinを組み合わせたユーザー管理の自動化についてご紹介しました。 「誰でもできる作業」をAIに任せることで、SREが「人間にしかできない価値ある活動」に集中できる環境作りを、これからも進めていきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは、ファインディCTOの佐藤( @ma3tk )です。 今回は、Anthropicの招待制イベント「 AI Founder Salon 」に参加し、登壇する機会をいただきました。 このイベントには、Anthropic共同創業者のBen Mann氏やAnthropicの社員の方々が来日していました。ぜひお話を聞いてみたいと思い参加を決めたのですが、そのタイミングで運営の方から「Fireside Chat（パネルディスカッション）形式での登壇をしてみないか」という打診があり、登壇させていただきました。 本記事では、Ben氏の発表に加え、私自身がパネルディスカッションで登壇した内容も含めてお伝えしたいと思います。 Ben氏が語った、生成AIの未来 AGIの定義は経済の50%をAIが担うこと エージェントの本質：ツールを持った言語モデル 継続的学習とスキル機能 私が登壇で話した「開発速度」と「UI/UX設計」 開発速度の向上と、その課題 AI時代におけるUIの提供の仕方とUX設計 これからも、先を見続ける Ben氏が語った、生成AIの未来 Anthropic Ben Mann氏のセッション Ben Mann 氏はAnthropicの共同創業者であり、Fireside Chatで約1時間にわたって生成AIの未来について語ってくれました。その中で印象的だった3つのポイントをお伝えします。 AGIの定義は経済の50%をAIが担うこと 生成AIの未来について、Ben氏が話していた中で最も印象的だったのは、AGIの定義についてでした。 AGIが来ると言われている状況ではありますが、彼はAGIになったかどうかを判断する方法として「経済的チューリングテスト」という考え方を示していました。 これは、「あなたが仕事のために誰かを雇って、3ヶ月間働いてもらう。その相手が人間かAIか判別できない状況になる。そして、経済全体の50%の仕事がAIに置き換わったら、それがAGIである」というお話でした。数年以内にAGIが実現するだろう、というのが彼の予測でした。 特に印象的だったこととして、健康問題の解決や老化の逆転など、人類のあらゆる問題を解決する可能性が高いと話していたことです。半信半疑ではありますが、非常にワクワクするお話でした。 エージェントの本質：ツールを持った言語モデル AIエージェントの本質についても話がありました。彼の定義はシンプルで、「ツールを持った言語モデル」というものでした。 その中で最も重要なのは、コンテキストへのアクセスであるとのことです。世の中にはたくさんのドキュメントがあります。例えば、Google Docs、SharePoint、社内システムなど、さまざまなシステムへアクセスできる言語モデルになっていく必要があります。 この「多様なシステムに、安全かつ一貫した方法でつなぎにいく」という要件に対して、この1年で登場したMCP（Model Context Protocol）という概念は、標準化を行いながらコンテキストへのアクセスを実現することを目指しています。AnthropicもMCPの開発に取り組んでおり、将来的には多くのシステムがMCPに対応していくことを期待しているそうです。 継続的学習とスキル機能 3つ目は、継続的な学習とスキル機能についてです。 パネルの中で、「AIを使う時に、毎日初めて接するような状態では作業を続けられない」と彼は言っていました。その中で Claude Skills は、継続的に学習していく上での第一歩になる機能だと紹介されていました。Claude Skills とは、カスタム指示や知識を記憶させることができる機能です。 例えば企業において、ブランディングガイドラインをドキュメントとして生成することで、デザインシステムを自分たちのプロダクトに合わせていくことができます。 また、自分たちのプロダクトの設計思想を形にしていくことで、AIが自動的にスキルを生成できるようになります。Ben氏は「3〜6ヶ月ほどで、より自動化が進むのではないか」と見立てていました。人間の役割としては、AIに対してコーチングを行うようになっていくことが見えます。 私が登壇で話した「開発速度」と「UI/UX設計」 パネルディスカッション パネルディスカッションでは、私もファインディでのClaude活用について話す機会をいただきました。大きく2つのことをお伝えしました。 開発速度の向上と、その課題 まず開発速度の向上についてです。Claude Codeを使うことでプルリクエストの数が増加し、部分的に開発生産性が上がっているメンバーもいます。 一方で、大きな課題も見えてきました。AIが作るものは、どうしても部分最適になりがちだということです。 これはプロダクトやプロジェクトのコンテキスト、私たちの思想といった要素を十分に埋め込めていないために起こることでもあります。やり取りを重ねるうちに重要な前提が会話の外へ押し出され、限られたトークン量の中で考えるほど、もともと意図していたアイデアを十分に活かし切れなくなってしまいます。 また、別タスクの会話や古い仕様の断片などが混入すると、プロダクト固有の前提が抜け落ち、結果として期待しない動作につながることもあります。 そこで、AIが作ったものを検証していく「守り」が大事になってきます。ユニットテストを書くこと、Lintツールを使うこと、そのうえでCI/CDとして守りのチェックを回すことです。これらの仕組みによってプロダクトそのものが常に安全に保たれ、AIによって意図しない方向へ進んでしまったコードを本番環境へデプロイせずに済みます。 早い段階でバグや違和感に気づける仕組みを整えていくことが大事だと考えています。 AI時代におけるUIの提供の仕方とUX設計 もう1つお話ししたのは、AI時代におけるUIの提供についてです。 テキストボックスを作ってチャット形式で入力するというUIはよく見かけますが、多くのユーザーにとって非常に難しいUIだと考えています。テキストですべて解決できるのは一部のユーザーだけです。 そうではなく、プロダクト提供者側から準備したいくつかの選択肢から選んでもらうことを実現する。ワークフローにAIを組み込んでいくことで、より便利に日々のルーティンワークをクリアにできるのではないかと思っています。 こうした設計思想こそが、その会社のプロダクトが存在する意味になってくるのではないでしょうか。 これからも、先を見続ける 今回のイベントを通じて、人間のこれからの役割について明確になったと感じています。 すでに多くの会社でAIの活用は始まっていますが、1つ1つの業務がAIワークフローに置き換わるという現象が起きています。Anthropicのような先進的な企業においては、ほとんどの簡単な業務がAIに置き換わっている状況になっているかもしれません。 では、そういった状況の先に何が来るのかを考えてみました。「自分たちの思想をクリアにし、相手が人であれAIであれ、その考えを落とし込んでいく。その結果として、AIを使ってものを作っていくという状況を作ること」が大事になってくると感じました。 創造性を発揮できる環境で、アイディアを出し続け、ブラッシュアップすることが求められてくると思います。Ben氏が語った「コーチング」と同様に、人と人のつながりやマネジメントという領域の重要性も高まっていくと考えています。 Anthropicからの招待に改めて感謝しつつ、これからAIが当たり前に使える環境を整えていくとともに、整え切った後に来る時代を見据えていきます。 また、ファインディではAI時代を一緒に切り抜けていけるようなメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは、 Findy Conference を開発しているsontixyou( @sontixyou )です。 普段はWebアプリケーションのフロントエンドとバックエンドの開発を担当しています。 この記事は、 ファインディエンジニア Advent Calendar 2025 の1日目の記事です。 今回はエンジニアの学び旅 Part1として、基本情報技術者試験の学習を通して、仕事の進め方がどのように変わったのかを紹介します。 基礎力をつけるきっかけ プロジェクトマネジメントにおける伸びしろ Webサービスの基礎知識の伸びしろ 基礎知識を学ぶ 基本情報技術者相当の知識を学ぶ Webサービスの基礎知識を学ぶ 自分の中で変わったこと プロジェクトマネジメントで変わったこと 基礎力をつけるための取り組み おわりに 基礎力をつけるきっかけ 新規プロダクトを0 → 1でフロントエンドとバックエンドをほぼ私1人で作ることになりました。 しかし、私は基本情報技術者試験相当の知識を知らないため、テックリードとシステム設計の話をしていても、話を理解できず、先に進まないことがありました。 開発が進む中で、プロジェクトマネジメントに支障が出て、リリース日が後ろにずれこんでいました。 振り返り会において、弊社のテックリードから自分のエンジニアスキルの基礎力が足りていないとフィードバックをもらいました。 基礎力の中でも特に次の点が不足していました。 プロジェクトマネジメント Webサービスを開発するための基礎知識 今まで開発業務に全力投球していたツケが回ってきました。 指摘された点については、基本情報技術者試験相当の知識があれば、当たり前に知っていることです。 プロジェクトマネジメントにおける伸びしろ 私は仕様が不明確だったり、仕事を進める中で調整に時間がかかりそうなタスクを後回しで、すぐ着手できるものから手をつけていました。 また、調整に時間がかかると見込んでいたタスクを着手したときには、自分の見積もりより時間がかかるタスクでした。 さらに、プロジェクトマネジメントにおけるクリティカルパスという単語を知りませんでした。 Webサービスの基礎知識の伸びしろ エンドポイントの設計やレスポンスのステータスの理解が足りていませんでした。 例えば、MDNの HTTP response status codes をもとに、正しいレスポンスのステータスをAPIから返せていませんでした。 これらの壁を超えるために、まずは基本情報技術者試験の内容を学ぶことにしました。 ただし、参考書を勉強するだけでも良かったのですが、基本情報技術者試験を合格することを目標の一部にしました。 なぜなら、基本情報技術者は一度合格すると永久に使える 国家資格 です。さらに、資格の更新が必要ないことも魅力であるためです。 基礎知識を学ぶ 基本情報技術者相当の知識を学ぶ 徹底攻略 基本情報技術者教科書 令和7年度 を読むことにしました。 その頃、テックリードが毎週、基本情報技術者試験の内容を解説してくれる回がありました。 受け身だと全然身にならないので、途中回から教科書を全部読んだうえで参加しました。そのおかげで、自分で学習した内容を復習しながら、参加していました。 試験に合格するために、基本情報技術者専門の過去問道場サイトにある直近5年間分の過去問をひたすら繰り返し解くことにしました。 1ヶ月半くらい勉強して、無事に基本情報技術者試験に合格しました！ Webサービスの基礎知識を学ぶ 基本情報技術者試験だけでは、Webサービスの基礎知識を身につけることが難しいため、 Webを支える技術 とMDNで公開されているWebについてのドキュメントも並行して読み進めました。 Webの基礎知識を学ぶことを通して、REST APIの設計やレスポンスのステータスコードについて理解が深まりました。 自分の中で変わったこと プロジェクトマネジメントで変わったこと クリティカルパスを意識しながら、機能開発を進めるようになりました。 新しい機能開発の設計や実装を始める前に、まずは仕様が不明確な点を洗い出し、不明確な仕様を決めにいくことや関係者と話し合うことを優先するようになりました。 仕様が確定するまでに時間がかかる場合、その間にできる他のタスクを進めることで、全体のスケジュールを守ることができるようになりました。 基礎力をつけるための取り組み 基礎知識を身につけることを重視して、技術書を選ぶようにしています。 最近読んだ本は次の通りです。 www.shoeisha.co.jp 今までは、流行っている技術を追いかけたり、ほかのフレームワークや言語を試していました。 現在は、最新のトレンドなどは情報収集のみを行い、基礎力をつけることに注力しています。 また、学んだことを自分のものとするために、手をたくさん動かすようにしています。 プライベートや実務でのシステム設計や実装をやっていると、本を読んだだけでは出てこなかった疑問が出てきます。 それを解決するために、周辺知識を学ぶ必要が出てくるため、そこから更に深掘って学んでいくようにしています。 ただし、疑問を解決するため度に新しい知識を学んでいくことは終わりが見えないため、区切りをつけることも大事です。 おわりに エンジニア4年目で基礎力の不足に気づき、基本情報技術者試験を通して、自分のスキルを伸ばせました。 もし自分と同じように、開発業務に全力投球してきて基礎知識に不安を感じているエンジニアがいたら、基本情報技術者試験の学習をおすすめします。 資格取得が目的ではなく、体系的に基礎を学び直すきっかけとして活用してほしいです。 基礎知識の学習に終わりはありませんが、1つずつ積み重ねていくことで、確実にエンジニアとしての基礎力が強くなっていくと信じています。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから herp.careers