こんにちは。こんばんは。 Findy Team+ 開発のフロントエンドリードをしている @shoota です。 今回はフロントエンドからは少し離れ、AIによるプルリクエストのレビューシステムを作成した話を書きます。 Findy Team+フロントエンドの現状と課題 AIコーディング時代の新たな課題 AIによる自動レビュー（Approve）を作ろう 解決したい課題 レビューは大きく3種類ある 誰が使えるのか 何を判定するのか 判定のキモはTidy First?の分類 実装とポイント GitHub Actions Claude Code Actions ワークフローの変化とプロンプトの改善 実行コスト おわりに Findy Team+フロントエンドの現状と課題 過去のブログでも触れていますが、Findy Team+のフロントエンドは、非常に大きなモノレポで構成されています。 tech.findy.co.jp このため、CIの最適化・チューニングはもちろんのこと、コードベース全体の秩序の品質を維持するためにさまざまな工夫や制約をもって運用してきました。 AIコーディングが主流になってからは更にこれらを強化し、制約やルールの策定、ESLintやユニットテストなどのガードレール整備や強化をおよそ1年をかけて進めてきました。 （この内容については別で発表したいと思います） これらの投資とAIモデルの進化により、これまでバックエンドを中心に活動しているメンバーのフロントエンドの参入障壁を大きく下げることに成功しています。 現在では、AIが生成するコードの質は1年前から大きく向上していると体感しています。 AIコーディング時代の新たな課題 しかしここで新たな課題が生まれました。それは、「AIが真似すべきでないコードの修正や、それらを防ぐルールの導入のためのレビューコストが異常に高い」ということです。 AIの活用のためにコードを直し続ける活動は巨大なコードベースではかなりコストがある 技術的な障壁よりも単純な物量がつらく、対抗する手段がない ESLintのルールを1つ変更するだけでプルリクエストが大量に必要になる 特定のルールのちょっとした厳格化で25件のプルリクエストを作成 あたらしいルールを追加したときは150件のプルリクエストが必要になった 軽微な変更でも意味のある粒度で修正しなくてはレビューできないため、ひたすらに数を重ねる このような事象が定常的に発生しており、次のFindy Team+でのグラフでも確認できます。 大量のプルリクエストが発生する様子 Vitest の一部のassertionがdeprecatedになったことに対して、私が一人でClaude Codeを回し、1日に72件、2日で100件以上のプルリクエストを作成しました。 レビュー待ちが多く発生する割に、内容は関数の置き換えなのでレビュー価値が低いプルリクエストが大量に必要になったのです。 このような 「AIを利用して品質を維持するための整備が人間を苦しめている」 という状況は、近頃話題になっていた Hustle Porn に近いのではないか？と考えました。 hustle porn 覚えた https://t.co/y3jpiLDL0x — Takuto Wada (@t_wada) 2026年4月13日 プルリクエストをたくさん書くことは素晴らしいですが、そこに意味のある粒度と価値が伴わなければなりません。 AIによる自動レビュー（Approve）を作ろう このような背景からレビュー負荷を可能な限り低減させ、ただしい 怠惰 を取り戻すために、AIレビューの仕組みを作成することにしました。 まずはやりたいことから全体の構想とコンセプトを決めていき、次のような内容になりました。 解決したい課題 プルリクエストを高速に作り続けることはむしろ歓迎すべき 課題の本質は「レビュープロセスが対ひとでしか機能していない」こと 人の時間をうばう 人のアクションを待つ 両者にメリットが少ない レビューは大きく3種類ある レビューする価値がないことを確認するレビュー。レビューというワークフローを実施しているだけであり、本質的なレビューはしていない。レビューワークフローに相乗りしている儀式のひとつ。 品質、プログラム観点としてのコードレビュー。いわゆる本質的なコードレビュー。 レビュー結果が反映されていることのレビュー。論点が絞られており、コードの内容がレビュー指摘に即して修正されているかを「確認する」だけの作業的な儀式。 今回は1. の「レビューする価値がないことを他者が保証する儀式」をAIにやらせることをゴールとします。 誰が使えるのか 初手はフロントエンドのレビュワーチームのみに絞る 最大リスクは、誤判定や手順のハックによるレビューのザル化 フロントレビュワーチームはセルフレビューで一定の品質担保ができている前提で考える 条件的に一般解放は想定するが、判定の成功率データがたまるまではリスクのほうが大きい 何を判定するのか 要はプルリクエストの分類器をつくる Claude CodeのReview (~$25) は必要がない 変更内容から人間がレビューする必要があるかどうか？を判定する 振る舞いが変わらない 構造的なリファクタリング code generatorなどの既存の機械的なワークフローの結果も不要と判断する 判定のキモはTidy First?の分類 レビューの必要性を測る判定処理に、 構造的なリファクタリング という概念を持ち込みました。 これは昨年の弊社のイベントでキーノートを務めていただいたKent Beck氏の書籍 Tidy First? から引用した言葉です。 この書ではリファクタリングの分類が紹介されており、リファクタリングを効率的に進めるための作業を指します。 和訳では「整頓」と表現されています。 振る舞いの変化を伴わない、「コードの移動・分割」、「名前の変更」、「配置の変更」 プログラム（群）の凝集度に対するリファクタリングアプローチ これらの修正は人間が目で追うのは意外と面倒で、レビューコストが割に合わない 例）ファイル移動や統合、変数・関数のリネームor削除、関数統合・分離 www.oreilly.co.jp Tidy First?に関する考察は非常に多く議論されているので、Claude Codeに調査させながら「人間のレビューが不要」の定義を確定し、プロンプトに起こしていきました。 次に示すのがそのパターンの概要です。詳しい内容はぜひ書籍を確認していただけるとよいかと思います。 対象パターン（T1〜T14） T1: ファイル移動・リネーム T2: import整理・barrel export T3: 型定義の移動・分離 T4: コンポーネント・関数の分割・統合・抽出 T5: 変数・関数・propsのリネーム（テスト/モックへの機械的波及含む） T6: ESLint/Prettier修正 T7: 不要コード・ファイル削除 T8: 非推奨APIの機械的移行（1:1対応） T9: GraphQL codegen実行結果 T10: Nx generator実行結果 T11: ガード節への変換 T12: 説明変数・定数の導入 T13: Feature Flag名の追加 T14: コメントの追加・修正・削除 NGパターン（NG1〜NG7） 新条件分岐、新ビジネスロジック、API変更、状態管理変更、テスト追加、UI変更、設定値変更 実装とポイント 全体の要件が決まったのでここからは実装です。 GitHub Actions GitHub Actionsをランナーとし、プロンプトファイルを読み込んだうえでClaude Code Actionsに渡して実行、結果をパースしてレポートする非常にシンプルなフローです。 またFindy Team+はCI結果を送ってCIの実行分析ができるので、これも組み込んであります。 GitHub Actionsのフロー Claude Code Actions Claude Code Actionsの呼び出しのポイントは --max-turns です。 これはClaude Codeが処理を何手まで行うかを制限するもので、変更ファイル数やそれらのファイルの関連性によって前後します。 - name: Classify PR changes id: claude uses: anthropics/claude-code-action@5d5c10a4f389689f992ea10bb14dcb6fcc83146d # v1.0.102 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} claude_args: '--max-turns 20' prompt: ${{ steps.prompt.outputs.content }} 何パターンかの構造的なリファクタリングのプルリクエストで試したところ 〜15 turns におさまるようでしたが、余裕を見て20を設定しています。 これを設定しておくことでプロンプトの誤認や想定しない大きな差分で実行された場合でも「判定不能」で安全に終了するようにしています。 ワークフローの変化とプロンプトの改善 何度か試していくうちに、ひとつの気づきがありました。 これまでプルリクエストは 「人間が認知できる変更量」にサイジングするようにすべき でしたが、AIは機械的にこれを分析できるので「同じ作業なら差分が大きくても1つのプルリクエストにまとめる」ことができる、ということです。 そのため大きな差分でもApproveができるような負荷耐性をもたせる必要があります。 そこで変更ファイルが多い場合は変更そのものを見るのではなく、いくつかをサンプリングし、「diffのパターンが同一であるか？」をClaudeが確認するようにしています。 <!-- 追加したプロンプトの抜粋 --> ## 大規模 PR のフォールバック - **変更ファイル数が 30 ファイルを超える場合**: 同一パターンの変更が繰り返されるファイル群はサンプリング（代表的な数ファイルの確認）で判定してよい。サンプリングした旨と確認したファイルを注意事項に記載する - **サンプリング時は副作用の取り逃しに注意する**: ある T パターンを特定したら、**その波及先ファイル群（スナップショット、spec、モック、`index.ts` の re-export、import 更新 等）も必ず1件以上サンプリングに含め、元の T パターンとの対応を確認する**。波及先のファイルだけを単独で見ると NG に誤分類しやすい（例: T5 リネームのインラインスナップショット更新を NG5 と誤認）。波及元・波及先を**セットで**サンプリングすること （以下略） 実行コスト Claude CodeのReviewは 最大$25の費用が必要 ですが、今回はプルリクエストの分類器なのでそこまでのコストがかかりません。 CIから実行したログからみると、1 runあたり、$0.20〜0.50で分類ができていました。 { " type ": " result ", " subtype ": " success ", " is_error ": false , " duration_ms ": 62472 , " num_turns ": 10 , // Claude Codeの手数の実績値。最大20で絞ってある。 " total_cost_usd ": 0.24731475000000003 , // 約$0.25を消費 " permission_denials_count ": 0 } おわりに プルリクエストの分類器をGitHub Actions + Claude Code Actionsで作成することで、人がレビューしなくて済むプルリクエストは作成者が単独でマージできるようになりました。 この仕組みの導入は想定以上に開発者体験がよく、また機能開発の合間でリファクタリングするモチベーションも高めてくれます。 まさに Tidy First? のなかでの「先に整頓、あとに整頓」を仕組みで支えることができたと感じています。 Claude Code Actionsはチャット形式に似たJSONレスポンスを返すため、AIチャットの実装経験もCIのデバッグに役立ちました。 今後はさらに対象を拡大させつつ、組織的に利用するAIワークフローを充実させていきたいと思います。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディ株式会社でデータエンジニアをしている 開 です。 2026年4月28日（火）に、データソリューションチーム主催の採用イベント 「事業成長に効かせるファインディ流データエンジニアリングの実践」 を開催しました。 findy-inc.connpass.com この記事では、イベントを企画した背景と当日の3本のセッションを参加できなかった方にもイメージが伝わるようにまとめます。 イベント開催の背景 セッション1: ファインディの事業拡大を支える拡張可能なデータ基盤へのリアーキテクチャ セッション2: データモデリングを通して管理会計のオペレーションを再設計 セッション3: 社内で使われるLooker整備の進め方 まとめ イベント開催の背景 ファインディでは、既存4プロダクトに加えて、新たに4つのプロダクトをリリースし、エンジニアの皆さまへサービスを多角的に展開しています。会社規模の拡大とともに、扱うデータの量と種類は急速に広がってきました。 prtimes.jp 変化の激しい事業環境のなかで客観的な意思決定を支えるには、社内の情報流通をより活性化させる仕組みが欠かせません。私たちは、その土台を担うのがデータエンジニアリングだと考えています。 データソリューションチームは少数精鋭で推進してきましたが、事業成長のスピードに合わせてデータ基盤をさらにスケールさせるには、共に挑戦してくれる仲間の存在が不可欠です。今回のイベントは、ファインディがどのような課題に向き合い、どのような技術と組織で解いているかを直接お話しする機会としました。 セッションは3本立てで、データ基盤・データモデリング・BIの3つの観点からファインディのデータエンジニアリングをお話ししました。 セッション1: ファインディの事業拡大を支える拡張可能なデータ基盤へのリアーキテクチャ 登壇者: 開 speakerdeck.com 事業拡大に合わせてデータ基盤をどうリアーキテクチャしているかを紹介しました。直近1年でデータソースは10倍、Google Cloudプロジェクトは6倍に増える一方、データエンジニアは3名のままで、認知コストと運用負荷が膨らんでいました。 これまでは事業＝ドメインとしたデータメッシュ的な構成で、技術選定も各チームに委ねていました。アジリティは出る一方で、ドメイン間の連携不足や技術のばらつき、作業重複が課題になっていました。 そこで、データメッシュの利点は残しつつ実装を見直し、Google Cloudプロジェクトの統合、IAMのデータセット単位での管理、dbt Platformへのオーケストレーション集約やマネージドサービスの活用を進めています。これによりマネージドサービスのAPIやMCPを用いてAIエージェントに運用を一部移譲することができています。作成したスキルやサブエージェントは以前テックブログで紹介したプラグインとしてチーム全体で使えるようにしています。 tech.findy.co.jp DataOpsの省力化が進む一方、コスト透明性の低下といった新しい課題も見え、FinOps体制の構築や、浮いた時間をデータ活用者との会話やイネーブリングに使っていくことを次のテーマにしています。 セッション2: データモデリングを通して管理会計のオペレーションを再設計 登壇者: 田頭さん speakerdeck.com 経営判断に直結する管理会計という業務領域に対して、データモデリングの観点からオペレーションを再設計した取り組みを紹介しました。 ファインディの管理会計は、長らくスプレッドシートを中心に回っていました。月次のたびに関数とピボットを手作業で組み直し、IMPORTRANGEやVLOOKUPで絡み合ったスプレッドシートのリネージは50件を超え、どこか1枚崩れると全体が連鎖して壊れる脆さを抱えていました。同じKPIが部署ごとに別ロジックで計算されて数字が合わない、月次締めに2〜3日かかって意思決定が後追いになる、といった状態も常態化していました。 再設計の起点に置いたのは、技術選定ではなく業務担当者へのヒアリングです。「計上組織」「補助科目」「配賦」「予算番号」といった専門用語が飛び交うなか、勘定元帳やマクロを眺めるだけでは掴めない集計粒度や分析軸を、経営管理部の担当者と何度もMTGを重ねて引き出していきました。書籍 『アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド』 のBEAM✲を参考に、誰が・何を・いつ・どこで集計したいのかを対話から輪郭化し、総勘定元帳を起点に売上・費用・原価を月次粒度のファクトとして整理しています。 実装は、会計データソースをGoogle DriveにアップロードしてTROCCOで取り込み、dbtで集計してLookerやスプレッドシートから参照する構成に落としています。これにより、ワンボタンで月次の実績値が揃い、想定外の科目も自動で検出できるようになりました。「どの数字が正しいか」を議論する場面はなくなり、月次締めの所要時間と数字の信頼性が同時に改善しています。 今後は、実績ファクトと同じ粒度で予算・見通しを取り込んだ予実分析の自動化や、整備済みのファクトを起点にAIエージェントが自然言語で会計分析を行える基盤への展開を進めています。 セッション3: 社内で使われるLooker整備の進め方 登壇者: 出相さん speakerdeck.com 社内で実際に使われるBIにするためにLookerをどのように整備してきたかを紹介しました。「ダッシュボードを作った瞬間がピークになって使われなくなる」「事業部からはデータ活用の入口が見えない」「スプレッドシート運用が属人化して限界が見えている」といった、よくある課題を出発点にしています。 ファインディでは、Lookerを意思決定にひも付くダッシュボードを定常的に見る場としてだけでなく、Exploreや会話分析でデータそのものを探索する場にすることを目指しています。ただし、最初はLookerを見に行く習慣もExploreの操作にも慣れていないため、進め方の工夫が欠かせません。 そこで、ヒアリングで課題を引き出す → 最低限の機能に絞って最初のダッシュボードを素早く提供する → 共有MTGで一緒に触りながら改善ループを回す → 利用が定着してからディメンショナルモデルやメタデータを整える、という4ステップで価値を積み上げてきました。完璧な設計よりも早い体験提供を優先し、苦労していたことから先に解消していくことを大切にしています。詳しい進め方は以前のテックブログでも紹介しています。 tech.findy.co.jp その結果、MAUは2026年1月から4月途中で約1.5倍、WAUは1月中旬から4月中旬で約2.6倍に成長しました。経営管理部からも「BigQueryやLookerを駆使したモニタリングが事業拡大に不可欠」というコメントが届くなど、Lookerが信頼できるデータソースとして社内に定着してきています。 まとめ 今回のイベントを通じて、ファインディがデータエンジニアリングをどのように事業に効かせようとしているかを、3つの異なる切り口でお伝えできたと思います。データ基盤・データモデリング・BIのいずれも、技術そのものよりも「事業や業務にどう接続するか」を軸に進めてきた取り組みです。 参加してくださった皆さん、ありがとうございました！ ファインディでは、データエンジニアリングの力で事業成長を支える仲間を募集しています。今回のイベント内容に少しでも興味を持っていただけた方は、ぜひお気軽にカジュアル面談などでお話しできるとうれしいです。 herp.careers

こんにちは、ファインディでFindy Toolsの開発をしている本田です。 このたび、Findy Toolsの新機能として「アーキテクチャAI」をリリースしました。要件を入力するとAWSのアーキテクチャ図と設計の提案が生成される機能です。 findy.co.jp 今回の開発では、PM・仕様策定・スコープ定義・インフラ・FE/BE開発・テストまで、ほぼ一人で1か月で担当しました。そして、コーディングはほとんどClaude Codeに任せ、私自身はほぼコードを書いていません。 この記事では、そんな開発を進めるなかで分かったこと、難しかったこと、そして改めて実感したエンジニアの仕事について紹介します。 アーキテクチャAIについて 一人開発の全体像 エンジニアが価値とコストを自分で判断する 対話で判断の視野を広げる 動くもので共通認識を作る 自分の仕事は減らず、判断と意思決定の時間が増えた まとめ アーキテクチャAIについて 本題に入る前に、リリースした機能を軽く紹介させてください。 アーキテクチャAIは、Findy Toolsの中で提供している機能の1つで、「作りたいシステムの要件」を入力するとAWSを使った構成案とアーキテクチャ図、そして設計の考え方の解説がまとまった形で得られるものです。 ai-architecture.findy-tools.io アーキテクチャの設計はサービスの土台を決める工程で、経験や周辺知識の広さが問われる領域です。そうした知見を持った人に相談しづらい場面でも、構成の検討を前に進める助けになることを目指しています。 ここから先は、この機能を一人で1か月で作ったなかで気づいたことを中心に書いていきます。 一人開発の全体像 今回は、PMから開発、テスト、リリースまでを一人で担当しました。具体的には次のような範囲です。 プロダクトの方向性・優先順位の決定 仕様策定、スコープ定義 インフラの構築 フロントエンド・バックエンドの実装 テスト、リリース作業 開発のワークフローはシンプルで、だいたいこのサイクルを回していました。 GitHub Issueに「なぜ作るのか」「何を作るのか」を、PRDやユーザーストーリーの形で書く Claude CodeにIssueを渡して実装してもらう 自分は差分をレビューし、必要に応じて指示を出す 別チームのメンバーにレビューしてもらい、PRをマージする 実装の途中でも、作りたい背景やユーザーに届けたい価値に立ち戻って方針を調整することはよくありました。 仕様策定やUIのモック作成も、AIと壁打ちしながら進めていました。結果として、自分でコードを書いた量はごくわずかで、ほとんどの実装はClaude Codeが書いています。 一方で、「自分はほぼコードを書いていない」からといって仕事が少ないわけではありませんでした。むしろコーディング以外にやることが山ほどあるというのが実感です。 何を作るか、何を削るかの判断 仕様の細部に関する意思決定 技術選定 コードレビューと品質の担保 スケジュール管理とリリース計画 ここからは、この進め方で1か月やってみて感じたことを書いていきます。 エンジニアが価値とコストを自分で判断する 最も強く感じたのは、 エンジニア自身がユーザー価値と実装コストのバランスを判断しながら開発に携わることの強み です。 今回は一人で担当していたので、事業やプロダクトの意図、技術的な実現可能性、実装コストが、すべて自分の頭の中に揃っていました。「ユーザー価値として外せない部分はどこか」「コストをかける価値があるのはどこか」を、自分の中でつなげて考えながら開発を進めることができます。 具体的には、開発の途中でアーキテクチャ図の描画ライブラリを切り替える判断をしたり、リリースの2週間前になってからSNSで共有されたときに見栄えの良い画像を生成する機能を追加する判断をしたりと、方針転換を素早く進められました。技術的に成立するかをClaude Codeで素早く検証しつつ、プロダクトとして本当に必要かを自分で判断できたことで、価値とコストの両取りを狙える選択肢を見つけやすくなっていました。 体制を一人にしたことが本質ではないと思っています。大事なのはやはり、作る側のエンジニアがユーザー価値や事業価値を理解したうえで、コストと価値のバランスを判断しながら開発に携われているかだと、今回の開発を通じて改めて感じました。 対話で判断の視野を広げる 意思決定が速いのは良いことですが、速ければ良いわけではありません。一つの視点だけで速く判断を続けていると、気づかないうちに筋の悪い方に流れてしまいます。 ここで効いてきたのが、一人で担当していても孤立はしていないという体制づくりでした。 開発中は、事業部長・PO・デザイナと定期的に相談・共有できる場を持ち、それ以外の場面でもいつでもコミュニケーションを取れるようにしていました。 プロダクトとして何を大事にしているか 事業としてこの機能にどういう期待があるか デザインとして譲れない部分はどこか こうした観点を継続的にすり合わせることで、自分一人では見えていなかったより良い選択肢を見つけやすくしていました。 自分の頭の中だけで判断すると、どうしても視野が狭くなります。そこに他の立場の視点が入ると、「他にもっと良い選び方はないか」という問い直しができます。スピード重視の体制であっても、というよりスピード重視だからこそ、チームとの対話は欠かせないと感じました。 動くもので共通認識を作る もう1つ強く感じたのが、 速く見せられるもの・動くものを使って共通認識を作ることの効果 です。これ自体は昔からよく言われる話ですが、AIの力でぐっとやりやすくなりました。 今回は、実プロダクトの開発を始める前に、別リポジトリでPoCアプリを作り、ステークホルダーやインタビューにご協力いただいた方に、実際に見たり触ったりしてもらう時間を取りました。 PoCアプリの画面。デザインは作り込まず、ユーザーに価値を体験してもらうことを優先した。 文章やスライドだけで議論すると、どうしても抽象的になり、認識のズレに気づきにくくなります。動くものがあると、「これは欲しい」「ここは期待と違う」というフィードバックが具体的に返ってくるだけでなく、「どういう価値が得られそうか」という部分でも共通認識を作りやすくなります。 PoCを見たり触ったりしてもらうなかで見えてきたのは次のようなことです。 ユーザーが本当に価値を感じるのはどの部分か 最初はあると便利そうに見えたが、実際はなくても困らない機能 技術的に見落としていた制約や、逆に想定より軽く実現できそうな部分 PoCで得られたこれらの情報が土台になって、本開発のスコープと方針が定まっていきました。 AIで「仮に動くもの」を高速に作れるようになった強みを活かして、動くものを中心に仮説検証のサイクルを回せたこと が、1か月という限られた期間のなかで特に効いたポイントだと思います。 自分の仕事は減らず、判断と意思決定の時間が増えた ここまで書いてきたことを踏まえて、改めて感じたのは 少なくとも今回の自分の経験では、コーディングをAIに任せても、エンジニアとしてやることは減らなかった ということです。むしろ、本質的な判断に集中する必要が出てきた感覚でした。 今回の開発で自分が時間を使っていたのは、次のような部分です。 この機能を作る意味は何か、誰のどんな課題を解くのか スコープをどこまで広げ、どこで切るか どの技術を選び、どの技術を見送るか 出てきたコードが本当に要件を満たしているか、将来の運用に耐えるか どれも、意思決定と判断の仕事です。コーディングそのものをAIに任せられるからこそ、こうした判断に集中できる時間が増えました。 AIと協業するなかで変わる部分と変わらない部分があり、「コードを書く時間」は確実に減りますが、「エンジニアリングを行う時間」は減らない、むしろ増えている感覚でした。 まとめ ほぼ一人で1か月かけてアーキテクチャAIをリリースしてみて、次のことが学びとして残りました。 エンジニア自身がユーザー価値と実装コストのバランスを判断しながら開発に携われると、価値とコストの両取りを狙える選択肢を見つけやすい 速さだけを追うのではなく、複数の視点を対話で取り込んで選択肢を広げていく AIで仮の動くものを高速に作れるようになった強みを活かせば、短期間でも動くものを軸に仮説検証を回しやすい 少なくとも今回の自分の経験では、コーディングをAIに任せても仕事は減らず、判断と意思決定に集中する時間が増えた AIと一緒に開発する時代になっても、「何を作るか」「どう作るか」「なぜそれを選ぶか」を考え抜くことの大切さは変わらないなと、今回の開発を通じて改めて感じました。 アーキテクチャAIは次のページから触れます（Findy Toolsの会員登録が必要です）。ご興味のある方はぜひ試してみてください。 findy-tools.io ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。プロダクト開発部の森 @jiskanulo です。 2026年4月22日から24日までRubyKaigi 2026 Hakodateが開催されました。 rubykaigi.org 函館アリーナを3日間に渡って貸し切る大規模イベントの運営をしていただきましたスタッフの皆様に感謝を申し上げます。 ファインディ株式会社もPlatinumスポンサーとして協賛しました。 私もブースに立って出展やファインディ各サービスのご案内をさせていただきました。 お話しをしていただいた皆様にも重ねて感謝申し上げます。 ブースに立つ合間にセッションを聞いて自分でやれそうなことに思いを馳せたり、他社様のブースを回ってプロダクトのお話をしたり、昔の同僚や知人と再会したりと個人的にもいい刺激の多い3日間でした。 さて、4月24日、最後のセッションのMatzさんのキーノートにてRubyファイルをネイティブバイナリにコンパイルする Spinel が発表されました。 早速Spinelを使ってみた感想とつかいどころを記します。 Spinelとは 検証環境とセットアップ 動かしてみた Hello, World! eval / requireの挙動：エラーにならず無音で間違う eval は no-op に置き換わる require は文ごと消える 現時点での注意点 Spinelを使ってみる requireなしでJSONを扱う ハマりどころは個別に踏みに行く価値がある Spinelを試すときの判断基準 個人的所感 おまけ: Spinelの由来 おわり Spinelとは SpinelはRubyのAOT (Ahead-Of-Time) コンパイラです。 RubyソースコードをPrismでパースし、全プログラム型推論を行いCのコードに変換してネイティブバイナリを生成します。 パイプラインは次のとおりです。 Ruby → Prism → AST → 全プログラム型推論 → Cコード → ネイティブ実行ファイル リポジトリのREADMEによると、miniruby比で約11.6倍、Conway's Game of Lifeでは86.7倍という性能が示されています。 またバイナリサイズもmrubyを含めずに数十KBに収まるので容量が厳しい環境にも適用できるとのことです。 実体としての ./spinel はPOSIX shell wrapperで、内部で spinel_parse → spinel_codegen → cc を直列に呼び出している、という作りです。 検証環境とセットアップ 検証は手元のmac環境で行いました。 4月24日公開直後にmacで動かそうとしたタイミングでは malloc.h が存在しないなどでエラーになったのでDockerでUbuntuのコンテナを起動して操作しましたが、現在は対応されています。 土日で函館観光しているうちにコントリビュートが進んでいますね。コントリビュートのチャンスですね。 mac build対応 https://github.com/matz/spinel/commit/4593581eb87cea45b59fb28b9dcf2cd75a9bcbab windows対応 https://github.com/matz/spinel/commit/1fe3136aa9bf834b5f37176faca7346503fb1446 環境は次のとおりです。 macOS (arm64) Apple Clang Spinel masterブランチ（2026-04-28時点） ビルドと実行の基本フローはシンプルです。 spinel をmakeし、 spinel にrubyファイルをわたせば実行形式バイナリが出力されます。 make deps # 初回のみ: libprism 取得 make # spinel_parse / spinel_codegen / ランタイムをビルド ./spinel app.rb # Ruby → 実行形式（./app） ./app 動かしてみた Matzのキーノートとも被りますがサンプルコードを動かしてみました。 またキーノートで話があったとおり eval と require はサポートしていないとのことです。 eval, requireを使うと具体的にどうなるのかも試してみました。 Hello, World! 最小の動作確認はそのまま動きます。 # hello_world.rb puts " Hello, World! " ./spinel hello_world.rb ./hello_world # => Hello, World! eval / requireの挙動：エラーにならず無音で間違う 2026年4月28日の現時点では コンパイル時にエラーにならず、warningも出ず、しかし実行すると無音で間違った出力 を返すという挙動です。 具体的に2つのケースを見ていきます。 eval は no-op に置き換わる 次のRubyコードをSpinelでコンパイルして実行します。 # test_eval.rb code = " 1 + 2 " result = eval (code) puts result $ ./spinel ./tmp/jiska/samples/test_eval.rb ./tmp/jiska/samples/test_eval.rb -> test_eval 実行すると結果は 0 です。 $ ./test_eval 0 生成されたCのコードを見ると eval() の呼び出しがno-opに置き換わり、戻り値は型推論で決まったゼロ値（ mrb_int のため 0 ）になります。 const char *lv_code = "1 + 2" ; mrb_int lv_result = 0 ; // mrb_int = int64_t typedef lv_code = "1 + 2" ; lv_result = 0 ; // ← eval() 呼び出し自体が消滅、0 を代入するだけ printf ( " %lld\n " , ( long long )lv_result); mrb_int はmrubyのような」命名に見えますが lib/sp_runtime.h で int64_t のtypedefとして定義されたSpinelランタイムの整数型です。 https://github.com/matz/spinel/blob/64105ec86d08c9edc92c3d17bf059126ceaa15d3/lib/sp_runtime.h#L53 require は文ごと消える 次は require "json" と JSON.generate を使うケースです。 # test_require.rb require " json " puts JSON .generate({ name : " spinel " , year : 2026 }) こちらも実行すると 0 になります！ $ ./spinel ./tmp/jiska/samples/test_require.rb ./tmp/jiska/samples/test_require.rb -> test_require $./test_require 0 require の行は生成されたCのコード上で文ごと消えます。 続く JSON.generate もSpinelから見れば未定義メソッドであり、 eval と同じくゼロ値を返す呼び出しに化けます。 最終的に puts には 0 が渡って表示される、という流れです。 現時点での注意点 現時点では「コンパイルが通った」「実行ファイルができた」「実行できた」の3点だけを見ていると間違った結果を吐いていることに気づけません。 Spinel向けにRubyを書くときは README を都度確認することが重要です。 Spinelを使ってみる 次に実際のユースケースを想定してみます。 実例として、GitHubのPR一覧JSONを入力に取り、各PRの number と author を表示するスクリプトを書いてみました。 入力はARGV、stdinの優先順で受け取ります。 requireなしでJSONを扱う require "json" が使えないので標準の Regexp と String 操作だけで処理を組む必要があります。 なお、ここで示すコードは正しいJSONパーサではありません。 require "json" が使えないSpinelの制約下で、入れ子オブジェクトや }, を含む文字列値が現れない、フラットな配列形式の固定データから number と author をアドホックに取り出す例として読んでください。本格的なJSON処理が必要な場合は、入れ子・エスケープなどで容易に壊れるため、この実装は使えません。 実際のRubyファイルは次のとおりです。 多少トリッキーなところは感じますが、こうした限定的な用途であれば、RegexpとStringの標準機能だけで実装できることがわかりました。 if ARGV .length > 0 input = ARGV [ 0 ] else input = readlines.join end records = input.split( / }, / ) results = [] records.each do |chunk| if chunk =~ / "number" \s* : \s*(\d+)/ num = $1 if chunk =~ / "author" \s* : \s* " ([^ " ]+) " / auth = $1 results << " # #{ num } by #{ auth }" end end end if results.length == 0 $stderr .puts " Error: failed to parse JSON (no matching number/author pairs found) " exit 1 end results.each do |line| puts line end 実行サンプルは次のとおりです。 引数渡し、パイプ、リダイレクトそれぞれに対応しています。 JSONを展開できない場合は標準エラーへエラーメッセージを出して exit 1 します。 SAMPLE='[{"number":1,"author":"Findy"},{"number":2,"author":"jiskanulo"}]' # 1) 引数渡し ./pr_extract "$SAMPLE" # 2) パイプ echo "$SAMPLE" | ./pr_extract # 3) リダイレクト ./pr_extract < sample.json # それぞれの出力: # #1 by Findy # #2 by jiskanulo $ ./pr_extract "not json" Error: failed to parse JSON (no matching number/author pairs found) $ echo $? 1 なお、引数もパイプもなしで ./pr_extract を起動すると readlines がEOF待ちでブロックします。 最初は $stdin.tty? で判定してUsageを表示しようとしましたが、実機で試すとTTYでもパイプでも両方 0 が返ってきました。これも eval / require と同じく、Spinel未対応のメソッドが silent failしている例です。 # test_tty.rb puts $stdin .tty? $ ./test_tty # TTY実行 0 $ echo "" | ./test_tty # パイプ実行 0 Spinelで標準入力を扱うときは $stdin.tty? に頼った分岐ができないため、引数で渡すかパイプ・リダイレクトで明示的に流し込む運用に倒すのが安全です。 ハマりどころは個別に踏みに行く価値がある 実装してみると String#<< でmutable化すると Regexp#scan に渡せない、 Regexp#scan(/(...)/) { |m| ... } のキャプチャは効かない...などとハマりどころがいくつかありました。 ただ、現時点での詳細を解説しても開発が活発に進んでいるのですぐに風化してしまうので詳しくは記しません。 Spinelを試すときの判断基準 ここまで触ってみた感触から、Spinelを触るときの判断基準を次にまとめます。 成功体験を得やすいのは次のようなコードです。 入出力が puts / printf で完結する 標準ライブラリに依存しない 数値計算・文字列処理・正規表現( =~ + $1 )で書ける範囲 逆に、現時点で踏むと詰まる、もしくはsilent failになるのは次のような領域です。 require を前提とするコード（標準ライブラリの利用） eval を含むメタプログラミング 未対応メソッドに依存する処理（呼び出しがゼロ値返却に化ける） 「コンパイルが通ったから動いている」とは限らない、というのが現時点での最も大事な感触です。 CRubyとSpinelの両方で実行して出力をdiffする運用を組むのが安全です。 個人的所感 ローカル環境のlintやチェッカーなど今までワンライナーでやっていたことを置き換えて使ってみたいですね。 コンパイル済みのバイナリを配布できるのであれば環境構築の手間も減るかもしれません。 まだ少し触っただけですが、Spinelに可能性を感じています。また、こういうワクワクするものを提供してくれるMatzさんの凄さをあらためて実感します。 これから機能が拡充されていくのが楽しみです。 自分でもコントリビュートしていきたいですね。 おまけ: Spinelの由来 Rubyと同じく宝石つながりでSpinelなのかなあとはじめ思っていましたが、漫画アニメ『カードキャプターさくら』のスピネル・サン（スッピー）から名前をとっているそうです。 相棒はルビー・ムーンなのでここでもRubyに繋がってきますね。 由来聞いた時はそっちか〜〜！！となりました。かわいい。 おわり ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 Claude CodeのPluginを使うと、社内で育てたSkillやAgentを、組織のメンバーにまとめて配布できるようになります。ファインディでも、この仕組みでセルフレビュー用のSkillを開発組織全体に配り、各自がPull request作成前に呼び出す形で活用してきました。 この記事では、そこから さらに一歩踏み込んだ使い方として、PluginをGitHub Actionsから呼び出してCIで動かす 取り組みを紹介します。具体的には、Pluginに含まれるセルフレビューSkillをCIから定期実行し、指摘内容を反映したPull requestを自動で生成する仕組みです。 Pluginの使い方というと「Skillを社内で共有して、各自がローカルで叩く」という一面が語られがちですが、 同じPluginをCI基盤から起動する という選択肢をとると、Pluginで育てたSkillが個人の開発体験だけでなく、チーム全体のプロセスにも効いてきます。 PluginとセルフレビューのSkillについては次の記事を参照してください。 tech.findy.co.jp tech.findy.co.jp Pluginで配って各自に使ってもらう運用 PluginをCIから呼び出す 実際のWorkflowを読み解く トリガーとスコープ PluginをCIに引き込む 自動生成Pull requestにもCIを走らせるための GitHub App 1指摘1Pull requestに切り出す GitHub Actionsのmatrixを使って並列でPull requestを作る まとめ Pluginで配って各自に使ってもらう運用 まず、ファインディでのセルフレビューの流れを整理します。 社内の開発用Pluginには、セルフレビューSkillが含まれていて、Pull request作成前にローカルでPull request作成用のコマンドから呼び出されます。Pluginとして配布しているので、新しくジョインしたメンバーも、追加の手順なしに同じSkillを使える状態になっています。 このあたりの「Pluginで開発ナレッジを横展開する」話は、冒頭に貼った記事で詳しく紹介しているので、そちらをぜひご覧ください。 この運用は、個人の開発体験を底上げするうえで十分機能しています。この記事が公開された頃には実に1500個ものPull requestで実行されており、「最後の一押し」として働いてくれています。 PluginをCIから呼び出す この運用をベースに、 さらにもう一歩踏み込んで、同じPluginをCIからも呼び出してみる というのが本記事のテーマです。 PluginはSkillやSub Agentなどの集まりなので、 Pluginを参照できる実行環境さえ作れば、人間の代わりにCIから呼び出すこともできます 。普段ローカルで走っているものと同じSkillを、 anthropics/claude-code-action 経由でGitHub Actionsから起動すれば、Skillを再実装することなくCI化できるわけです。 github.com 本記事では、この考え方の一例として、セルフレビューSkillを定期実行し、指摘事項ごとに別々のPull requestを自動生成するWorkflowを取り上げます。対象にするのは、既存コードのうち長期間触られていないファイルです。人間のレビューでは目が届きにくい箇所に対して、機械がレビューすることで技術的負債の蓄積を抑えるというねらいがあります。 具体的に組み上げたWorkflowは、2つのjobで動きます。 指摘抽出 job ：Pluginのセルフレビュー用Skillを呼び出し、対象コードに対する指摘を抽出する。 修正Pull request作成 job（matrix） ：指摘の件数を matrix strategy に展開し、 指摘内容ごとに独立したjobを並列起動 。各jobは新しい runner 上で指摘内容を1件だけ修正したのち、PluginのPull request作成SkillでPull requestを作成 結果として、朝出社すると 改善Pull requestの候補が並んでいる 状態になりました。ローカルで個人が手動実行するSkillと、CIから定期実行されるSkillが、同じPluginの中身を共有している——これが、Pluginの使い方をもう一段広げてくれるポイントでした。 この仕組み自体はセルフレビュー専用のものというより、「PluginをCIから起動する」というパターンの1つの応用です。同じ構造で、様々なSkillをCIに組み込めます。 実際のWorkflowを読み解く まずは、今回組み上げたWorkflowの全体像です。PluginのSkillをCIから呼び出して指摘、Pull requestを並列生成するという流れを一通り確認できます。 name : Scheduled Self Review on : schedule : - cron : '0 19 * * 0-4' # 平日 JST 04:00（UTC 19:00 Sun-Thu） workflow_dispatch : env : SELF_REVIEW_MAX_FINDINGS : "3" jobs : # --------------------------------------------------------------------------- # Job 1: findings 抽出 # セルフレビューSkillで stale files をレビューし、 # 指摘を findings.json として artifact 化。matrix 展開用の index も出力。 # --------------------------------------------------------------------------- extract-findings : runs-on : ubuntu-latest timeout-minutes : 30 outputs : finding_indices : ${{ steps.compute-matrix.outputs.finding_indices }} findings_count : ${{ steps.compute-matrix.outputs.findings_count }} steps : - id : app-token uses : actions/create-github-app-token@fee1f7d63c2ff003460e3d139729b119787bc349 # v2.2.2 with : app-id : ${{ secrets.SELF_REVIEWER_APP_ID }} private-key : ${{ secrets.SELF_REVIEWER_APP_PRIVATE_KEY }} - uses : actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 with : token : ${{ steps.app-token.outputs.token }} fetch-depth : 0 - name : Compute stale file list run : | git log --since="1 month ago" --name-only --pretty=format : origin/main \ | grep -v '^$' | sort -u > .stale-recent.txt git ls-files | sort > .stale-all.txt comm -23 .stale-all.txt .stale-recent.txt > .stale-files.txt - name : Clone plugin repository run : | git clone https://x-access-token:${{ secrets.PLUGIN_REPO_READ_TOKEN }}@github.com/your-org/plugin-repo.git /tmp/plugin-repo - name : Extract findings via self-reviewer uses : anthropics/claude-code-action@4e5d8b13ca281a6d163cdb287d8917b216e00d6f # v1.0.103 with : anthropic_api_key : ${{ secrets.ANTHROPIC_API_KEY }} github_token : ${{ steps.app-token.outputs.token }} plugin_marketplaces : | /tmp/plugin-repo plugins : | example-dev-plugin@plugin-repo claude_args : >- --allowedTools Read --allowedTools Write --allowedTools "Skill(example-dev-plugin:<review-skill>)" --allowedTools "Skill(<review-skill>)" --allowedTools "Bash(cat:*)" --allowedTools "Bash(jq:*)" --allowedTools "Bash(gh pr list:*)" prompt : | .stale-files.txt に列挙された stale files を対象に、 セルフレビューSkillを呼び出して指摘を抽出し、 各指摘を 1 finding としてスキーマに従い findings.json に書き出せ。 コード修正・Pull request作成は行わない（後続 matrix job が担当）。 - id : compute-matrix run : | COUNT=$(jq length .self-review-findings.json) INDICES=$(jq -c 'to_entries | map(.key)' .self-review-findings.json) echo "findings_count=$COUNT" >> "$GITHUB_OUTPUT" echo "finding_indices=$INDICES" >> "$GITHUB_OUTPUT" - uses : actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 if : steps.compute-matrix.outputs.findings_count != '0' with : name : self-review-findings path : .self-review-findings.json include-hidden-files : true # --------------------------------------------------------------------------- # Job 2: finding ごとに修正 + Pull request 作成（matrix で並列） # 各 matrix job は独立した runner で新規 checkout するため、 # worktree を使わずに済み、job 同士の編集衝突もそもそも発生しない。 # --------------------------------------------------------------------------- fix-per-finding : needs : extract-findings if : needs.extract-findings.outputs.findings_count != '0' runs-on : ubuntu-latest timeout-minutes : 40 strategy : fail-fast : false matrix : finding_index : ${{ fromJSON(needs.extract-findings.outputs.finding_indices) }} steps : - id : app-token uses : actions/create-github-app-token@fee1f7d63c2ff003460e3d139729b119787bc349 # v2.2.2 with : app-id : ${{ secrets.SELF_REVIEWER_APP_ID }} private-key : ${{ secrets.SELF_REVIEWER_APP_PRIVATE_KEY }} - uses : actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 with : token : ${{ steps.app-token.outputs.token }} - uses : actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0 with : name : self-review-findings - name : Extract single finding id : finding run : | FINDING=$(jq -c ".[${{ matrix.finding_index }}]" .self-review-findings.json) { echo "finding<<EOF" echo "$FINDING" echo "EOF" } >> "$GITHUB_OUTPUT" echo "branch=fix/self-review-$(date -u +%Y%m%d-%H%M)-${{ matrix.finding_index }}" >> "$GITHUB_OUTPUT" - name : Clone plugin repository run : | git clone https://x-access-token:${{ secrets.PLUGIN_REPO_READ_TOKEN }}@github.com/your-org/plugin-repo.git /tmp/plugin-repo - name : Fix finding and create Pull request uses : anthropics/claude-code-action@4e5d8b13ca281a6d163cdb287d8917b216e00d6f # v1.0.103 env : FINDING_JSON : ${{ steps.finding.outputs.finding }} FINDING_BRANCH : ${{ steps.finding.outputs.branch }} with : anthropic_api_key : ${{ secrets.ANTHROPIC_API_KEY }} github_token : ${{ steps.app-token.outputs.token }} plugin_marketplaces : | /tmp/plugin-repo plugins : | example-dev-plugin@plugin-repo claude_args : >- --allowedTools Read --allowedTools Edit --allowedTools "Skill(example-dev-plugin:<pr-skill>)" --allowedTools "Skill(example-dev-plugin:<review-skill>)" --allowedTools "Skill(<pr-skill>)" --allowedTools "Skill(<review-skill>)" --allowedTools "Bash(git switch:*)" --allowedTools "Bash(git commit:*)" --allowedTools "Bash(git push:*)" --allowedTools "Bash(gh pr create:*)" prompt : | $FINDING_JSON が担当 finding、$FINDING_BRANCH が担当ブランチ。 origin/main から $FINDING_BRANCH を切り、 affected_locations のみを Edit → PR作成Skill で Pull request を作成。 ここからは、このWorkflowを設計するうえでポイントになった箇所を取り上げて解説していきます。 トリガーとスコープ Pull requestではなく スケジュール をトリガーにしているのは、普段のPull requestで触る機会が少ないコードにも、同じSkillの観点を届けたいからです。 さらに対象ファイルは「直近1ヶ月以上変更されていないファイル（stale files）」に絞っています。最近の変更は通常のPull requestレビューで既にカバーされている前提で、それ以外の領域にフォーカスする設計です。 絞り込み自体は、 git log --since で直近の変更ファイル一覧を作り、 git ls-files と comm で差分を取るだけのシンプルな処理です。AIにリポジトリを丸ごと渡すと、コンテキストも費用も膨らむので、 「今効かせる価値がある範囲」に絞り込むための前処理を1段挟む のが運用上のコツでした。 PluginをCIに引き込む Workflow内では、社内Plugin配布リポジトリを都度cloneし、Claude Code Actionの plugin_marketplaces に渡しています。 ここで効いているのが、 Skillの実体をWorkflow側にコピーせず、Pluginからそのまま引き込む という構造です。Skillの改善はPlugin配布リポジトリにマージするだけで、自動的にすべてのリポジトリのCIに反映されます。ローカルで配っているSkillと同じものが、何のコピーもなしにCIで動く。これが、「Pluginで配るとローカルで使える」から「Pluginで配ったものがCIでも走る」への、ちょっとした発想の飛躍でした。 自動生成Pull requestにもCIを走らせるための GitHub App 地味に重要だったのが、 github_token にGitHub Appのinstallation tokenを渡している部分です。 なぜ GITHUB_TOKEN ではなくAppを使うのか。理由は、 GITHUB_TOKEN で作成されたPull requestはWorkflowを自動で発火させない というGitHub Actionsの仕様にあります。 自動生成されたPull requestに対しても、通常のPull requestと同じようにCIやセルフレビューのSkillを走らせたい。しかし GITHUB_TOKEN で作るとこれらが自動で発火しません。App token経由のPull requestはこの制約の対象外なので、「AIが生成したPull requestにも、人間のPull requestと同じCIが自動で実行される」状態を作れます。 「PluginのSkillをCIから走らせる」を本気で運用に乗せるなら、token戦略はワンセットで考える必要がありました。 1指摘1Pull requestに切り出す このWorkflowで考慮した設計判断の1つが、「見つかった複数の指摘を、1つのPull requestにまとめるか、1指摘1Pull requestに分けるか」です。 最終的に選んだのは、 指摘事項ごとに別々のPull requestに切り出す 方針でした。理由は次の通りです。 1つ目は レビュー観点の分離 です。1つのPull requestに複数の無関係な改善が混ざると、レビュアーが見るべき観点がまばらになってしまいます。「このリファクタは妥当だが、あちらは慎重に見たい」といった判断を、Pull request単位で切り分けられる状態にしたいというのが背景でした。 2つ目は revert単位の粒度 です。生成AIによる特定の変更が本番で不具合を起こした場合を想定すると、他の変更を巻き込まずに戻せるような粒度に保つのが安全であると考えました。1指摘1Pull requestであれば、revertひとつで該当の変更だけ元に戻せます。 3つ目は 依存関係なしにマージできること です。複数のPull requestを1本にまとめると、どれか1つがマージできないだけで全体がブロックされます。依存関係が少なくなるようにPull requestを分けておけば、マージできるものから順に処理できます。 代償として、レビュアーは「Pull requestの件数が増える」ことになります。ただし各Pull requestの変更量は小さく、観点も絞られているので、1本あたりのレビュー時間はむしろ短めになります。 GitHub Actionsのmatrixを使って並列でPull requestを作る 指摘ごとにPull requestを分ける前提に立つと、次は「どうやって並列で安全にPull requestを作るか」が論点になります。ここで採用したのが、 GitHub Actionsの matrix strategy による job 並列化です。 具体的には、job を2つに分けています。 最初の job（ extract-findings ）でセルフレビューSkillを走らせ、指摘内容をまとめる 後続 job（ fix-per-finding ）は、その指摘内容ごとに matrix に展開する。matrix の要素数ぶん、 独立した runner 上で並列に job が起動 する 各matrix job は、指摘内容を1件だけ取り出して修正して、PluginのPull request作成SkillでPull requestを作ります。 並列化でありがちな事故は、編集の衝突です。複数のエージェントが同じファイルを同時に触ると、どちらかの変更が失われます。今回はこれを、 matrix で分散した各 job が別 runner 上で独立に checkout する という構造で、そもそも発生しない形にしました。 strategy : fail-fast : false matrix : finding_index : ${{ fromJSON(needs.extract-findings.outputs.finding_indices) }} fail-fast: false にしているのは、1つのmatrix jobの修正が失敗しても他の matrix job を止めないため。AIが生成する修正は当たり外れがあるので、「一部が失敗しても残りは流す」という姿勢で運用するほうが現実的でした。 この構造で効いているのが、Pluginとして配布されているSkillの存在です。 extract-findings ではセルフレビューSkill、 fix-per-finding ではPull request作成Skillをそのまま呼び出すだけで、「レビューする→修正する→Pull requestを作る」という流れが組み上がります。 Pluginで配ったSkillが、CIの job 分割の単位とそのまま噛み合う 。これが、「Pluginで配ってローカルで使う」の一歩先にある使い方です。 まとめ Pluginで配ったSkillをGitHub Actionsにも載せたい場合に使えるポイントをまとめます。 Plugin配布用リポジトリをWorkflow内でcloneし、 plugin_marketplaces に渡す 。Skillの改善はPluginリポジトリへのマージだけで、ローカルにもCIにも同じ内容が反映される 自動生成Pull requestにもCIを回したいなら、 GITHUB_TOKEN ではなくGitHub App tokenを使う 。発火チェーン抑制の対象外になる 並列で動かすなら、GitHub Actionsの matrix strategy で job を分離する 。各 job は独立した runner で新規 checkout するので、編集衝突はそもそも発生しない Pluginで配ったSkillは、個人の開発体験を底上げするだけでなく、 CIに載せることでチーム全体のプロセスにも効いてくる 使い方ができます。「ローカルで配って使う」の次の一歩として、参考になればうれしいです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに こんにちは。プロダクト開発部 転職開発チームでエンジニアリングマネージャーをしている松村( @shakemurasan )です。 2026-04-22(水)から2026-04-24(金)までの3日間開催されているRubyKaigi 2026に現地参加しています。 rubykaigi.org この記事は、Day1 13:00-13:30のkoicさんのセッション『Exploring RuboCop with MCP』について、事前準備編と当日編（セッション当日に残したメモと感想）を1本にまとめたものです。 事前準備編にはAIによる予想が含まれるため、実際のセッション内容と一致するとは限らない点をあらかじめ断っておきます。 はじめに 事前準備編 koicさんの人となり AIに予想させてみたら、本人告知で焦点が絞れた 本人おすすめの教材とPRを少し覗いた 当日編 前半: MCP Ruby SDKとStreamable HTTP 後半: この1年間の試行錯誤 結びへ: 決定性と非決定性、そしてElicitation 聴き終えて腹落ちしたこと おわりに 事前準備編 koicさんの人となり koicさんはRuboCopのトップコミッターで、2025年にはMCPの公式Ruby SDK ( modelcontextprotocol/ruby-sdk ) のメンテナーにも加わっています。 github.com そこまでの道のりはFindy Engineer Labの取材記事『 365日欠かさずコミットを積む。なぜRuboCopコミッター伊藤浩一はOSSと向き合い続けるのか 』と、直近のお話はご本人のブログ『 MCPの公式Ruby SDKのメンテナーに加わった 』で詳しく綴られています。 findy-code.io koic.hatenablog.com 個人的な話をすれば、私がRubyを書き始めて数年の頃、地域のRubyコミュニティで何度かkoicさんをお見かけし、ジュニア時代の自分に刺激をくれた方の一人でもあります。 AIに予想させてみたら、本人告知で焦点が絞れた セッションタイトルだけでは論点が見えにくかったので、実は事前に予習の材料として、AIにkoicさんの直近のPRやIssueをもとに内容を予想させていました。 返ってきたのは大きく3通りの案でした。 1つ目は、stdio実装とMCP primitives（tools / resources / prompts）の写像を中心に据える構成。 2つ目は、MCPのtool annotationとRuboCopのCop属性の対応を核に据える構成。 3つ目は、Streamable HTTPを軸に据え、組織運用論にまで広げていく構成。 いずれもkoicさんの公開PRやIssueから拾えそうな筋ではあり、最初は「なるほどこのどれかだろうな」と眺めていました。 その後、koicさんご本人が『 RubyKaigi 2026に登壇します 』で背景と予習の案内をすでに公開されていることに気づきました。 koic.hatenablog.com 本人告知で軸に置かれていたのは「RubyツールチェインへのAI時代の課題提起」で、Streamable HTTPは副題として明示されていました。 一方で、tool / resource / promptといった「よく溢れている情報」は深掘りしない、とも明言されています。 AIの予想と本人告知を観点ごとにまとめると、次の通りです。 観点 AIの予想 本人告知 中心軸 RuboCop実装詳細 / MCP primitivesの写像 RubyツールチェインへのAI時代の課題提起 Streamable HTTP 1案の中心、他2案では末尾に触れる程度 副題として明示 、講演の大きなトピック tools / resources / prompts 写像の中心概念として扱う 「よく溢れている情報」として深掘りしない旨を明言 当たっていたのは「Streamable HTTPが主要トピックの1つ」と見立てていた点で、大きく外れたのは「tool / resource / promptを写像の中心概念として扱う」という方向性でした。 AIの予想は世に広く出回っている話題の重心に引っ張られやすく、本人が「あえて深掘りしない」と宣言していた領域こそがむしろ中心に置かれていた、というコントラストになります。 そのおかげで、当日聞きに行くべき焦点が一気に絞れました。 本人おすすめの教材とPRを少し覗いた 本人告知で紹介されていた教材のうち、RubyWorld Conference 2025でのkoicさんの登壇アーカイブに目を通しました。 「なぜstdioだけでは足りず、双方向のHTTP通信が必要なのか」という道筋が登壇の流れで追えるため、セッション前のウォームアップに助かりました。 当日編 本編は事前告知どおりの2部構成で、前半がMCP Ruby SDKの話、後半がRuboCop x MCPの話でした。 なお、当日のセッション資料は『 Exploring RuboCop with MCP 』としてすでに公開されています。 speakerdeck.com 以降は、現地で受け取った温度感の記録として読んでもらえればと思います。 前半: MCP Ruby SDKとStreamable HTTP Ruby SDKはもともとShopify社内で少人数のエンジニアが始めたもので、koicさん自身もRuboCopを念頭に早い段階から参画し、コミッターに招かれたのち、 mcp gemとして公開された、という経緯が紹介されました。 MCPにはTier1〜3のランクが定義 されていて、現在のRuby SDKはTier3。 Tier1を目指していく、と明確に宣言していました。 本題のtransportsの話では、規格としてstdioとStreamable HTTPの2つが並びます。 stdioの単純さはさらりと触れ、時間が割かれたのはStreamable HTTPのほうでした。 HTTPの規格のままで、WebSocketのような独自プロトコルに寄らずに双方向通信を成立させる。 実装はRackアプリケーションとして組んでおり、HTTPで叩かれたタイミングでMCPセッションIDを払い出してセッションを確立し、Queueを介してやり取りを何往復も成立させる。 1リクエスト1レスポンスではなく、1リクエストを起点にサーバー・クライアント間で通信が走る、という絵が丁寧に描かれていきます。 手を動かさないと実感が湧きにくい領域ですが、Rackの上に素直に乗っているという話を聞いた瞬間、普段触っているWeb技術の延長線上で捉えていい話なのだ、と急に距離が近く感じられました。 そして前半の締めでkoicさんが置いた次のようなニュアンスの一言が、個人的に一番刺さっています。 「AIになってガラッと変わったと思われるが、Linuxであるとか低レイヤの世界は何も変わっていなくて、我々はその上で開発をしているに過ぎない」 弊社でもたびたび話題に上がる「AIの台頭によりエンジニア自身にとってはむしろ基礎が大事になっていく」という考え方と一致しており、強く共感しました。 後半: この1年間の試行錯誤 後半はトーンが少し変わりました。 「1年間いろいろ試行錯誤してきたが、うまくいかなかったことが多かった。その話をします」とkoicさんが率直に切り出します。 成功譚ではなく、試行の経過と現在地の共有だ、というモードに切り替わりました。 最初のアイデアはシンプルで、RuboCopの結果をJSON構造でMCP化すればAIフレンドリーになって良いのではないか、というものでした。 しかし実際に手を動かしてみると、RuboCopはそもそも著名なgemなので、AI側もすでに相当学習していたように感じられた、と振り返ります。 わざわざMCPの皮を被せなくても、ある程度のことは既にできてしまう相手だった、ということです。 アイデアを広く募集して議論もしたものの、寄せられたものをそのまま実装して全員が喜ぶ機能になる自信は持てなかった、とも続きます。 結びへ: 決定性と非決定性、そしてElicitation そこから結びに向けて「RuboCopはこれまで、インプットに対して結果が一意に定まるものだった」と改めて位置づけ直されます。 「決定性こそがLinterとしての価値だった」という前提を言葉にしたうえで、そこに非決定性を持つLLMを組み合わせたら何ができるのか、と続きました。 具体例として並べられたのは、LLM側に委ねるSamplingと、ユーザーに聞き返すElicitationでした。 どちらもサーバーからクライアントに問い合わせを返せる仕組みですが、自分の耳に特に残ったのはElicitationのほうです。 ユーザーに対して定まったフォーマットの質問と回答フォームを返せる仕組みで、「この修正、どう進めたい？」と聞き返す余地をMCPの上で作れる、という話として置かれていました。 決定性のあるRuboCopの流れのなかに人間に問いを返すポイントを差し込み、そこを挟んだ非決定性を許容する。 決定性を捨てる話ではなく、どこで問いを立て、どこで非決定性を受け入れるかの設計の話として受け取りました。 この時私が思い出したのは、自チームでRuboCopのルール改廃を議論する時の話です。 一元的に適用するか悩ましいものが出てきたとき、その悩みには既存コードの暗黙的な規約、各エンジニアの思想や経験、copとして定義されているベストプラクティス、と様々な要素が絡んでいます。 これらは機械的に一意には定められないものです。 この統治過程にLLMが自然な形で介入し、対話を経てLinterに落とし込んでいくのはありそうな役割だと感じました。 (それをRuboCopの機能として提供されてユーザーが嬉しいかはさておき) ちなみにMCPの規格としてElicitationが発表された当時、弊社でも管理者向けのLocal MCP Serverにこれを組み込む事例があり、『 生成AI時代のサービス運営管理 - MCP Server for Administratorの実践 - 』（2025年9月16日公開）としてまとめられています。 tech.findy.co.jp 一方通行になりがちなMCPのやりとりに confirm / approveのステップを挟むという考え方は、koicさんが当日RuboCopの文脈で示したElicitationの位置づけとそのまま重なるものでした。 聴き終えて腹落ちしたこと 少なくともセッションの内容は「RuboCop x MCPのベストプラクティスがバシッと決まっている」わけではないということです。 むしろ、当事者として踏み抜いた人しか持ち得ない肌感を、苦労ごと公開してもらった30分だった、というのが近いと思います。 文字にするとシンプルですが、現場で聴講した皆さんにはkoicさんの試行錯誤と苦労が生々しく伝わっていたのではないかと思います。 現地参加する醍醐味をこういうところにも改めて感じました。 MCP化が思ったほど刺さらなかったこと、アイデアを集めても一意の答えに収束しないこと、Human in the Loopをどう設計するかが実装より先にあること。 どれも、ドキュメントや事例紹介を眺めていても掴めない、当事者として踏み抜かないと分からない種類の手触りです。 前半と後半を通して一本の線で繋がっていたのは、RubyツールチェインをAI時代にどう位置づけ直すかという問いだったように思います。 Streamable HTTPという具体的な技術基盤の話と、RuboCop x MCPという応用の試行錯誤、そして「低レイヤの世界は何も変わっていない」という立ち位置。 3つが重なって、Rubyのツール群とAIの関係をReframingする、という輪郭が浮かび上がる構成になっていたように私は感じました。 先頭に立ってこれだけの領域を踏み抜いてきたkoicさんへは、感謝と尊敬の気持ちでいっぱいです。 Ruby SDKへの貢献はRuboCop単体の話に留まらず、Rubyツール群全体が立つ足場を整える仕事なのだろう、と自分には受け取れました。 本セッションはAI時代にもRubyが最前線で使われる言語であり続けるための重要な歩みの1シーンを見せてくれたのだと改めて感じました。 おわりに AI時代だからといって銀の弾丸はなく、Rubyツールチェインも、HTTPやRackやQueueといった土台の上で地道に積まれていきます。 前半の締めの「低レイヤの世界は何も変わっていなくて、我々はその上で開発をしているに過ぎない」という言葉は、AIに振り回されずに使う側に回るのに必要なのは近道ではなく基礎だ、ということを改めて思い出させてくれました。 ファインディでは、一緒にRubyやRailsの開発をしてくれる仲間を募集しています。 興味のある方は、ぜひこちらからチェックしてみてください！ herp.careers

こんにちは。ファインディ株式会社でモバイルエンジニアをしている加藤です。 先日、「 React Native Lunch Talk ～いま選ばれる理由とアプリの現在地～ 」にて、「新規サービス開発におけるReact Nativeのリアル〜技術選定の裏側と実践的OSS活用〜」というテーマで登壇しました。 本記事は、その発表内容を改めてテックブログとして書き起こしたものです。 発表では時間の都合で駆け足になった部分や、質疑応答で答えきれなかった論点もあったため、本記事ではそのあたりも含めて踏み込んで書いています。 背景：Findy Events β版の開発 前回の記事 でも少し触れましたが、昨年、Findy初のモバイルアプリ「Findy Events」をα版としてAndroidアプリのみリリースしました。 現在はα版から得た学びをもとにUI・UXをフルリニューアルし、技術カンファレンス向けのiOS/Androidアプリとしてβ版のリリースを目指して開発を進めています。 Findy Eventsが長期的に目指しているのは、「カンファレンスでの学びとつながりを、その場限りで終わらせず継続的な成長の資産に変える」ことです。 β版では、その第一歩として、カンファレンス当日の体験をスムーズにする次のような機能を提供予定です。 QRコードを提示してのチェックイン 予約済みセッションやタイムテーブルなど、カンファレンス情報の閲覧 カンファレンス前日やセッション開始前に届くリマインダーPush通知 本記事では、そんな新規モバイルアプリの立ち上げにあたって、なぜReact Nativeを選ぶに至ったのか、そしてOSS選定や実装で直面したリアルな所感について紹介します。 前回の記事 では技術選定の結論だけを紹介しましたが、本記事ではその判断に至るまでの比較過程やOSS選定の裏側までを踏み込んで書いています。 背景：Findy Events β版の開発 React Nativeの技術選定の背景 OSSモジュールの選定と活用事例 独自選定の事例1：Sign in with Apple 独自選定の事例2：UIライブラリ React Nativeに対するリアルな所感 立ち上がりは、AI時代でも想像以上に苦労した OSS活用で感じたこと AI時代に、今からReact Nativeをやる意味 まとめ React Nativeの技術選定の背景 まず触れておきたいのは、「なぜ数ある選択肢の中からReact Nativeを選んだのか」という話です。 Findyにとって初のモバイルアプリ開発。しかも、技術選定を一から設計できる、エンジニア冥利に尽きる環境です。 ただ、自由度が高いということは、言い換えれば判断の重みも大きいということ。「モバイルアプリを開発する」と一言で言っても、その道筋はひとつではありません。 出発点として置いたのが、次の3つのアプローチの比較です。 最適な開発手法は、置かれた環境と考え方で変わる。これが私の基本スタンスです。 そして今回の前提は、「最小リソースで最速リリース」。この一点に照らして、まずCross Platformを選びました。 次に、Cross Platformの中から、国内外で実績が豊富なFlutterとReact Nativeの2つに絞って比較しました。 次の表は、iOSエンジニア出身である私の主観も踏まえて、2025年8月頃に整理したものです。 一見、表だけを見ればFlutterが優位に映ります。 正直なところ、私自身も最初はFlutterに馴染みを感じていました。 それでも最終的に選んだのは、React Nativeです。 決め手は、「組織のアセット」と「モバイルエンジニアとしての自身のナレッジ」の掛け算。この2軸をかけ合わせることこそ、「最小リソースで最速リリース」という目標に最短で近づく道だと確信しました。 仮にFlutterを選べば、私だけでなく将来参画するメンバー全員に一定の立ち上げコストがのしかかります。特にモバイルエンジニア出身でないメンバーほど、負担は大きい。 対してReact Nativeなら、ReactとTypeScriptの素養を持つメンバーが多い今の組織にそのまま馴染みます。 自分さえ立ち上がってしまえば、その後の開発速度は中長期的に最も出せる。これが最終的な決め手です。 具体的に、「組織のアセット」と「モバイルエンジニアとしての自身のナレッジ」についてですが、「組織のアセット」としては、 社内の優秀なWebフロントエンドエンジニアからReactやTypeScriptの知識提供、レビュー協力を得られる React製の既存プロダクトの設計思想やソースコードを参考にできる という期待感がありました。 また、「モバイルエンジニアとしての自身のナレッジ」として、 iOS/Androidのプラットフォーム特性への理解 プッシュ通知などのモバイル固有の課題への対応力 を活かすことができると考えていました。 「社内のWeb資産をどこまで活かすことができたのか？」という部分が気になる方もいらっしゃるかもしれません。結果としては、次の技術スタックのとおり、組織のアセットをフル活用することができました。 実は、アーキテクチャに関しても、既存のWebプロダクトをほぼ流用する形で開発しています。 つまり、設計思想や実装パターンまで踏み込んで参考にできるほど、React NativeはReactと親和性が高いということです。 OSSモジュールの選定と活用事例 続いて、OSSモジュールの選定についてです。 iOSエンジニア出身の私がReact Nativeに触れて最初に感じたのは、「とにかくOSSが豊富」ということ。 ただ、裏を返せば「多過ぎて、どれを選べば良いか迷う」という別の課題が立ち上がってきます。 そこで採った方針は、 Expo公式ドキュメント を「羅針盤」として活用すること。 Expo公式ドキュメントは非常に充実していて、Expo公式モジュールはもちろん、推奨される3rd Party OSSも明記されています。第一候補をここに置くだけで、選定コストは大きく圧縮できるというわけです。 もちろん、これで100%をカバーできるわけではありません。その場合は、プロダクトのコンテキストに合わせて独自に選びます。 ここからは、その独自選定した2つのOSSを紹介します。 独自選定の事例1：Sign in with Apple モバイルアプリの認証では、GitHub・Google・Appleの3つのOAuth認証を新規に導入する方針を採りました。中でもSign in with Appleは、iOSの審査要件として必須の機能です。 そこで選定軸に据えたのは次の2点です。 審査で認証ボタンのデザインも厳格に確認されるため、iOS SDK標準の ASAuthorizationAppleIDButton を内部で利用していること iOSだけでなくAndroidでもSign in with Apple機能を提供できること Expo公式には expo-apple-authentication があるものの、Androidが対象外。今回は見送りました。 最終的に選んだのは、両OSに対応した react-native-apple-authentication です。 独自選定の事例2：UIライブラリ 冒頭で述べた通り、自社初のモバイルアプリということもあり、社内にモバイル用のデザイン資産はありません。「最小リソースで最速リリース」を実現するには、UIライブラリの活用が欠かせない要素になります。 選定軸に据えたのは次の2点です。 豊富なUIコンポーネントが提供されていること iOSエンジニア出身の自分にとって、学習コストが高すぎないこと 実はα版では Tamagui を採用していました。ただ、β版でUI・UXをフルリニューアルすることが決まり、より要件に合致するライブラリを改めて探すことに。 たどり着いたのが、選定軸2点をしっかり満たす HeroUI Native です。 ここで一つ頭を悩ませたのが、採用を決めた当時（2026年1〜2月頃）のHeroUI Nativeがまだβ版だったこと。利用によって課題が顕在化するリスクを抱えての判断になります（※現在はstable版が提供されています）。 そこで採った工夫が、「HeroUI NativeのWrapper Componentを実装し、画面側からは直接HeroUI Nativeに触れない構成」にすること。 影響範囲をWrapper層に閉じ込めておけば、将来の差し替えや仕様変更への耐性が確保できる。β版OSSを採用する際のリスクヘッジとして、有効な型の一つだと感じています。 React Nativeに対するリアルな所感 立ち上がりは、AI時代でも想像以上に苦労した React Nativeを選んだ結果として率直に感じたのは、「AI時代と言えど立ち上がりにはそれなりに苦労した」ということ。 実は10年ほど前に少しだけReactに触れたことがあったのですが、React HooksやLifecycleに相当する考え方はほぼ初学者の状態。概念の再学習が必要でした。 また、TypeScriptも「Swiftと似て非なるもの」であることを痛感します。 型による安全性という思想は近いものの、 as によるキャストや enum がベストプラクティスとしては非推奨とされている点など、Swift感覚で書くと足をすくわれる場面が少なくありません。 一方で、React Native自体に対するハードルはそれほど感じません。理由は次の2つです。 宣言的UIによるUI構築は、SwiftUIで経験していた プッシュ通知など、モバイル固有機能の仕組みそのものを理解していた LT会では「どうやってReact Nativeを勉強したか？」という質問もいただきました。取ったアプローチは、過去にSwiftで開発していた個人アプリをReact Nativeで書き直してみるというもの。 題材を一から考えずに済む上に、Swift版という答え合わせの対象がある状態で進められるため、SwiftUIとの共通点や差分を体感しながら学べます。 こうして実感できたのは、React Nativeを選んでも、モバイルエンジニアとしての経験や強みは十分に活かせるということです。 OSS活用で感じたこと OSS活用の面でも、幾つか印象的な気付きがあります。 1つは、OSSの更新速度の速さです。 React / React Native界隈は更新サイクルが早く、iOS Nativeとの文化の違いを肌で感じます。 加えて、脆弱性検知などのエコシステムが整っており、開発者体験として足かせになっていない点も心強いところです。 もう1つは、Expoの利便性への驚きです。 ExpoはReact Native界隈ではデファクトスタンダードと言える立場を確立しており、信頼性も高く、証明書やリリース周りといった「モバイルアプリ開発ならでは」の知識を手厚くカバーしてくれます。 これは、Webフロントエンドエンジニアがモバイルアプリ開発に参入するハードルを相当下げていると言って良いでしょう。 実際、Webフロントエンドエンジニアの方から「React Nativeって実際どうなの？」と聞かれた際は、Expoのおかげで「モバイルアプリ開発は想像以上に始めやすい」と答えることができています。 AI時代に、今からReact Nativeをやる意味 最後に登壇の中では時間の都合で踏み込めなかった論点について書いておきます。 それは、「AI時代に、今からReact Nativeをやることに意味はあるのか？」という問いです。 個人的には、少なくとも次の3点で意味があると考えています。 1つ目は、iOSとAndroidを同時に立ち上げる中で、OS間の差分に向き合う経験が積めることです。 Cross Platformと言えど、プッシュ通知や認証、OSの作法といった領域では差分が必ず顔を出します。 AIに任せれば書ける時代だからこそ、差分の勘所を自分の中に持っているかどうかが効いてくると考えています。 2つ目は、アーキテクチャ選定やOSS選定といった、プロダクトの土台を作る判断を経験できることです。 ゼロからモバイルアプリを立ち上げる機会はそう多くなく、「何を選んで、何を選ばなかったか」を自分の言葉で語れるようになる経験は、AI時代でも色褪せにくい資産だと感じています。 3つ目は、Webフロントエンドへの足掛かりになることです。 React NativeでReactやTypeScriptを書いている時間は、そのままWebフロントエンドの学習コストを前払いしていると言えるかもしれません。 そのため、モバイルエンジニアとしてWebフロントエンドへ領域を広げたい人にとって、React Nativeは自然な入り口になると思います。 （もちろん、Webフロントエンドエンジニアとして、モバイルアプリへ領域を広げたい人にとっても同様です。） まとめ Findy初のモバイルアプリ開発を通じて、React NativeやOSSの選定と実装で多くの知見を得ることができました。 初めは慣れないReact Nativeに四苦八苦することもありましたが、一度慣れてしまえば、モバイルエンジニアとしての強みを存分に活かすことができると実感しました。 AI時代においては、人がガードレールとしてソフトウェアの責任を背負う場面がますます増えていきます。 その観点で見ても、React Nativeは「AI時代に、人が責任を取れる技術」として十分に選定に耐えうると考えています。 モバイルアプリの技術選定に迷っている方や、iOS/Androidの経験を活かしてReact Nativeに踏み出そうとしている方は、ぜひ一度触ってみてください。 本記事がその一歩を踏み出すきっかけになれば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 「AI活用を推進したいが、思うように進まない」──この悩みを抱えているエンジニアの方は、少なくないのではないでしょうか。 ファインディも例外ではありませんでした。2025年の上半期までは、普段の業務をやりつつ片手間でAIのキャッチアップや社内展開を進めていました。 今回は、そこから潮目が変わるきっかけとなった決断と、その後1人あたりのプルリクエスト作成数が前年比で約1.5倍になるまでの過程を紹介します。 同じようにAI活用の推進に手応えのなさを感じている方の参考になれば幸いです。 片手間で追いかける限界 1つの小さな決断 最初にやったこと：Findy Team+で現状を知る Claude Code Pluginsで展開を仕組み化する 継続的な浸透：毎日の通知と月一の共有 結果：PR作成数が前年比で約1.5倍に 振り返って気づいたこと まとめ 片手間で追いかける限界 2025年の上半期まで、ファインディの開発組織では興味と意欲のあるエンジニアが、普段のプロダクト開発と並行して、最新の動向をキャッチアップし、使えそうなツールを社内で共有していました。いわゆる"片手間"で進めるスタイルです。 最初のうちは、これでも回っていました。しかし、次第にこのやり方では追いつかなくなっていきました。 理由は単純で、 AIのアップデートが多すぎた からです。 ほぼ毎日のようにアップデートが公開され、新しいエージェントや機能が登場する。上半期の半ばあたりから、キャッチアップに充てる時間がどうしても足りないという感覚が強くなっていきました。 努力で巻き返せるレベルの遅れではなく、物量的に両立が不可能な状態に近づいていました。 1つの小さな決断 この状況を動かすために取った1つの決断が、 「AI推進だけを専任で担うポジションを作る」 というものでした。 その人を普段のプロダクト開発業務から外し、AI推進そのものを業務にする。兼務で時間を増やすのではなく、業務から外して全振りするという発想への切り替えが、このポジションの本質です。 この判断の背景には、 「全員が業務の10%をAI推進に充てるよりも、1人が100%を充てたほうが組織としての前進量は大きい」 という確信がありました。 兼務スタイルで各自が少しずつ動く形では、日々のAIアップデートの速度には追いつかない。仮に追いついたとしても、それらを使ってアウトカムを出せるまでが遠すぎました。一方、1人が専任で全力でコミットできれば、情報の集約・検証・社内展開を最速のスピードで回せると判断しました。 AI推進ポジションのエンジニアの仕事は、AI活用と組織への展開そのもの。日々のプロダクト開発タスクは原則持たず、AI関連の動向調査・検証・社内展開・仕組み化に集中してもらう形にしました。 プロダクト開発の手を減らすことに対しては、当然ながら社内でも葛藤がありました。それでも踏み切れたのは、片手間で続けていた半年間を通して、兼務では絶対に追いつかないという確信があったからです。 最初にやったこと：Findy Team+で現状を知る 専任ポジションを置いてから最初に取り組んだのは、派手な施策やスキル作成などではなく現状把握でした。 組織全体のAI活用を推進するといっても、感覚だけで動くと認識のギャップが生まれます。そこで、Findy Team+を使ってチーム単位・メンバー単位でAI活用の度合いを可視化するところから始めました。 ここでわかったのは、想定していたよりAIの恩恵を受けられていない、という事実でした。 もう少し掘り下げると、チームや事業部ごとにAIの活用度合いに明確な差があり、同じ役割のエンジニアでも使っているスキル・エージェントにばらつきがあることが見えてきました。よく使えている人の工夫が、他のメンバーに自然には伝わっていない状態です。 組織として全員で底上げされているのではなく、一部の熱量の高いメンバーが先行している状態だった、というのが当時の姿でした。 Claude Code Pluginsで展開を仕組み化する 現状把握でわかったスキル・エージェントのばらつきを埋めるために選んだ打ち手が、Claude CodeのPlugins機能を使った社内展開です。 Plugins機能については以前の記事でも紹介しています。 tech.findy.co.jp Claude CodeのPluginsは、スキル・エージェント・カスタムコマンド・各種設定などを1つのパッケージとして配布できる仕組みです。AI推進のエンジニアが作成した開発用スキルなどをプラグインとしてインストール可能にしておけば、各メンバーが自分の環境でコマンド1つで使える状態になります。 この仕組みに乗せることで、便利なコマンドや開発標準化のスキルなどをそのまま開発組織全体に配布できるようになりました。新しく入ったメンバーも初日からファインディのAI活用の恩恵を受けられるようになっています。 実際に、ファインディの開発組織で運用しているスキル・エージェントの一部は、次の記事でも紹介しています。 tech.findy.co.jp tech.findy.co.jp tech.findy.co.jp いずれも個人の工夫として始まったものを、プラグイン化して全員に配布できる形にしたものです。 継続的な浸透：毎日の通知と月一の共有 プラグインを配布するところまで作っても、更新を知ってもらえなければ次第に忘れられてしまいます。そこでファインディでは、配布の仕組みに加えて、更新が自然と目に入る状態を保つ工夫を並行して走らせています。 1つ目は、プラグインの更新内容をSlackの専用チャンネルに毎日通知する仕組みです。新しく追加されたスキルや、アップデートされたコマンドが翌日には目に入る状態にしておくことで、いつの間にか変わっていたではなく、今日こんな機能が追加されたという鮮度で情報が流通します。 2つ目は、月一のエンジニア定例のなかに、プラグインやAI活用の使い方を共有する時間を設けたことです。ドキュメントだけでは掴みきれないニュアンスやちょっとしたコツを口頭で流す場として、思った以上に機能しています。 プラグインという土台に加えて、通知と定例という継続的な露出。この組み合わせが、AI活用を一部のメンバーだけで閉じさせず、組織全体に浸透させる力になっています。 結果：PR作成数が前年比で約1.5倍に こうした取り組みを進めた結果、 1人あたりのプルリクエスト作成数は前年比で約1.5倍 になりました。 AI活用が進んだ実感というあいまいな言葉ではなく、開発のアウトプットそのものが定量的に伸びた、というのが大きなポイントです。 もちろん、プルリクエスト作成数は開発の速度やスタイルの指標の1つに過ぎません。それでも、組織としての変化が数字として見える状態になったこと自体が、AI活用のどこに投資すべきかを議論する大きな土台になりました。 振り返って気づいたこと 半年ほど取り組んで気づいたのは、専任を置いたから任せきる、では成り立たないということです。 専任1人ですべてを背負う構造にすると、その人自身がボトルネックとなってしまいます。専任の役割は、自分がすべてを実行することではなく、組織のAI活用を前に進めるための仕組みをつくること。 現場のエンジニア・マネージャーが自走するための土台を整え、みんなで良くしていくというスタンスが重要だと感じました。 まとめ ファインディのAI活用推進は、特別なツールや大がかりな制度改革ではなく、「AI推進だけを専任で担うポジションを作る」というシンプルで小さな意思決定から加速しました。 そこから専任が取り組んだのは、Findy Team+を使った現状把握、Claude Code Pluginsを使ったスキル・エージェントの社内展開、そしてSlack通知と月一定例による継続的な浸透。 いずれも派手さはありませんが、これらの積み重ねによって、1人あたりのプルリクエスト作成数が前年比で約1.5倍になるまでの変化を生み出すことができました。 AI活用は一日にして成らず。小さな意思決定や地道な取り組みの積み重ねが、組織全体の大きな変化につながることを実感しています。 全員が10%ずつAI推進に充てるよりも、1人が100%を充てる。この発想の転換が、ファインディのAI活用を動かす原動力になっています。 AI活用が思うように進まないと感じている組織の責任者の方がいれば、制度や研修を考える前に、専任を置く（業務から外す）という選択肢を検討してみてください。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 ファインディではClaude CodeのスキルやカスタムコマンドなどをPlugins経由で社内展開しています。 tech.findy.co.jp コードレビューやタスク分解といった開発業務の効率化が進む一方で、登壇準備はまだ手作業の割合が大きい領域です。話す内容を固めて、構成を考えて、スライドに落とし込んで、デザインを整えて……。発表の本質は「何を伝えるか」なのに、準備工程に時間を奪われがちです。 本記事では、この課題に対処するために社内Pluginsに作った登壇スライド生成スキルを紹介します。壁打ちによるコアメッセージの言語化からMarkdownスライド生成、Google Slidesへのエクスポートまでを一気通貫で行えるもので、壁打ちから完成まで30分で終わるようになりました。 登壇準備にかかる時間の内訳 NotebookLMを試して感じた限界 Claude Codeスキルという選択肢 ワークフローの全体像 壁打ちフェーズ：コアメッセージの言語化 テンプレート設計：発表時間から逆算するスライド枚数 Google Slides API テンプレートコピー方式 Markdownからスライドへの変換ルール デザインガイドラインの組み込み 70点の完成度で出す割り切り まとめ 登壇準備にかかる時間の内訳 登壇準備のどこに時間がかかっているかを振り返ると、スライドのデザインや配置よりも、その手前の工程が大きいことに気づきます。 前半は「何を話すか」の整理です。話したいことはぼんやりあるけれど、コアメッセージを一文にまとめるのが難しい。構成を決めても「この流れで聴衆に伝わるか？」と不安になって何度も組み替える。ここが一番時間を食います。 後半はスライドの作成とリハーサルです。ようやく構成が固まっても、今度はスライドツールを開いてフォーマットやデザインと格闘する。前半さえ効率化できれば、発表内容そのものの質を上げる時間に使えるはずだと考えました。 NotebookLMを試して感じた限界 最初に試したのはGoogleのNotebookLMでした。ソース資料を読み込ませてスライドを生成できる機能があり、期待して使ってみました。 ただ、実際に使ってみるといくつか壁がありました。出力がPDFや画像形式のため、生成後の編集が難しい点です。スライドの順番を入れ替えたい、テキストを修正したいといった基本的な操作ができず、結局ゼロから作り直す羽目になりました。 もう一つは、社内のスライドガイドラインに沿った出力が非常に難しかったことです。フォントやカラースキーム、ロゴの配置などは組織ごとにルールがあります。汎用的なAIツールではそこまで制御できず、ガイドラインに準拠させるための手作業が発生していました。 Claude Codeスキルという選択肢 これらの課題を踏まえて、Claude Codeのカスタムスキルとして登壇スライド生成ワークフローを自作しました。Claude Codeスキルを選んだ理由は、対話的なワークフローを自然に組めること、Markdownで中間出力できること、そしてAPIを叩いて外部サービスに連携できることの3点です。 開発したのは2つのスキルです。1つ目がMarkdownスライドの生成、2つ目がGoogle Slidesへの変換を担います。 ワークフローの全体像 スキルを実行すると、次の流れで処理が進みます。 参考URLやコードスニペットの収集（任意） 壁打ちでコアメッセージを言語化 タイトル・概要・発表時間の入力 テンプレートに基づく構成設計 Markdownスライドの生成 Google Slidesへのエクスポート（任意） 各フェーズを詳しく見ていきます。 壁打ちフェーズ：コアメッセージの言語化 このスキルで最も力を入れたのが壁打ちフェーズです。登壇準備で一番時間がかかるのは「何を伝えるか」を固める工程だからです。 スキルを起動すると、まず対象オーディエンス（テックリード、シニアエンジニア、EMなど）を選択します。次に「発表内容はすでに決まっていますか？」と聞かれ、「まだ漠然としている」を選ぶと壁打ちモードに入ります。 ? スライドに取り込みたいURLやコードスニペットはありますか？（任意） > なし ? 対象オーディエンスを教えてください（複数選択可） エンジニア系: ✔ テックリード ✔ シニアエンジニア マネジメント系: ✔ EM ? 発表内容はすでに決まっていますか？ > まだ漠然としている（一緒に考えたい） どんな発表をしたいですか？テーマや話したいこと、伝えたいことを 自由に教えてください。まだ漠然としていても大丈夫です。 壁打ちは次の順序で進みます。 コアメッセージの確定 — 「この発表で一番伝えたいこと」を1文に絞る 逆算による構成設計 — コアメッセージを結論として、聴衆が納得するために必要な情報を逆順に積み上げる タイトル・概要の決定 — 構成が固まった後に、コアメッセージが伝わるタイトルを考える ポイントは「逆算」というアプローチです。結論から遡って構成を組むことで、「話したいことを全部詰め込んだけど結局何が言いたいのかわからない」というよくある失敗を防ぎます。 実際のやり取りはこんな感じです。 > 生成AI時代のエンジニア育成について話したいんですけど、 まだ切り口が定まってなくて エンジニア育成×生成AIですね。テックリードやEM向けなので、 現場のリアルな課題感が求められます。 AI導入後に育成面で一番変化を感じたのはどこですか？ 学習速度、コードの質、それともチームの生産性でしょうか？ > AI導入後にシニアの生産性は上がったんですが、 若手のアウトプットの質がむしろ落ちていて。 AIの出力をそのまま使ってしまって、理解が追いついてない感じです なぜAIの出力をそのまま使ってしまい、理解が追いついていないと感じていますか？ > AIが出力したコードを理解せずにレビュー依頼するケースが増えていて、 結果的にリードタイムが悪化していることはわかった。 AI時代の今だからこそ原点回帰が必要。 なるほど。つまり「生成AI時代だからこそエンジニアの基礎力の価値が 上がっている。AIを"使う"側に立つには原点回帰が必要。」 ということを一番伝えたい、という理解で合っていますか？ > はい Claudeがコアメッセージを1文に言語化してくれるので、対話で壁打ちを進められます。コアメッセージが確定すると、逆算で構成を組んだうえでまとめを提示してくれます。 壁打ちの結果をまとめました！ タイトル案: 生成AI時代のエンジニア育成 — 変わる時代と変わらないコト 概要: 生成AIの導入でシニアの生産性は上がったが、若手のアウトプットの 質は低下していた。AIが出力したコードを理解せずにレビュー依頼する ケースが増え、結果的にリードタイムが悪化。基礎知識なきAI活用は 「AIに使われている」状態であり、今こそ原点回帰が必要だと気づいた 実体験を共有する。 コアメッセージ: 生成AI時代だからこそエンジニアの基礎力の価値が 上がっている。AIを"使う"側に立つには原点回帰が必要。 ? このまとめでスライド生成に進みますか？ > 進む テンプレート設計：発表時間から逆算するスライド枚数 スキルには3種類のテンプレートを用意しました。 standard — 20〜60分のカンファレンストーク向け。背景→本題→デモ→まとめの王道構成 lt — 5〜10分のLightning Talk向け。「結論ファースト」で1点突破 tutorial — 30〜40分のハンズオン向け。手順ごとに検証ステップを挟む 発表時間を選ぶと、テンプレートが自動選択されます。5分や10分ならLTテンプレート、15〜20分ならstandard、30分以上でハンズオン形式ならtutorialです。 スライド枚数は「1分1枚」を基準に算出しています。20分の発表なら15〜20枚。セクションごとの配分は、背景10〜15%、メインコンテンツ50〜60%、デモ15〜20%、まとめ・Q&Aで残りという割合で自動配分されます。 ? 発表時間を選択してください > 20分 テンプレート: standard（カンファレンストーク向け）を自動選択しました 目標スライド枚数: 15〜20枚 構成を設計しています... ? スライドに取り込みたいURLやコードスニペットはありますか？（任意） > https://tech.findy.co.jp/entry/2026/02/20/070000 URLの内容を取得しています... ✓ 取得完了: https://tech.findy.co.jp/entry/2026/02/20/070000 → 要点を抽出し、背景・メインコンテンツのセクションに反映します → 参考資料スライドにリンクを追加します Google Slides API Markdownで生成したスライドをGoogle Slidesに変換するスキルも開発しました。Google Slides APIを実行しており、OAuth2認証でユーザーのGoogleアカウントに紐づけています。 developers.google.com ? Google Slidesにエクスポートしますか？ > エクスポートする Google Slidesにエクスポートしています... ✓ エクスポートが完了しました URL: https://docs.google.com/presentation/d/1abc.../edit テンプレートコピー方式 今回は会社のスライドマスター（テンプレート）をGoogle Drive API経由でコピーし、そこにスライドを追加していく方式を採用しました。テンプレートには表紙・中扉・詳細ページのレイアウトが定義されており、Markdownの見出しレベルに応じて適切なレイアウトを選択します。 Markdownからスライドへの変換ルール Markdownのパース結果は、見出しレベルとボディの有無でスライドの種類を自動分類しています。 Markdownのパターン スライドの種類 デザイン # タイトル 表紙 背景画像あり ## 見出し + 本文あり 詳細ページ 背景画像あり ## 見出し のみ（本文なし） セクション区切り グレー背景 + 白文字 ## の中に ### の小見出しが含まれる場合は、自動的にセクション区切り1枚 + 小見出しごとの詳細ページに展開します。たとえば「AI時代の到来と変化」の下に「変わったこと」「変わらなかったこと」の2つの ### があれば、計3枚のスライドに分割されます。 デザインガイドラインの組み込み 会社指定のスライドガイドラインをスキルの定義ファイルに直接記述しています。フォントやカラーパレット、サイズといったルールをスキルの中で持ち、エクスポート時に各要素に適用します。 70点の完成度で出す割り切り 運用上、重要にしているのは「70点の完成度で一発出力し、残りは人間が仕上げる」という割り切りです。 AIが100点のスライドを作るのは現状難しいですし、目指す必要もないと考えています。スライドの完成度を70点から100点にするのは人間の感性が必要な部分です。逆に、0点から70点の工程（構成決め、テキスト配置、フォーマット統一）はAIの得意分野です。 この分業により最速で「壁打ち15分 + スライド生成5分 + 手動調整10分 = 30分」で登壇準備が完了するようになりました。 まとめ 今回紹介したスキルで作成されたスライドがこちらです。 登壇準備の工程をClaude Codeスキルで一気通貫にしたことで、壁打ちから完成まで30分程度で終わりました。 このスキルの価値は「スライドを自動生成すること」自体ではなく、「コアメッセージの言語化を対話で支援すること」にある点です。登壇準備で本当に時間がかかるのは構成やデザインではなく、「自分が何を伝えたいか」を整理する工程だったのだと、スキルを開発する過程で改めて実感しました。 登壇の機会があるエンジニアの方は、ぜひ挑戦してみてください。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディ株式会社でテックリードマネージャーをしている戸田です。 2026年4月15日に、Findy AI Meetup in Fukuoka #5を福岡で開催しました。 今回のテーマは「AI×育成 AI時代のエンジニア育成」です。 この記事では、当日の登壇内容を振り返りながら、生成AI時代におけるエンジニア育成で私たちが直面した課題と、そこから見えてきた「変わらない大切なこと」を紹介します。 https://findy-inc.connpass.com/event/383906/ findy-inc.connpass.com 当日参加くださったみなさま、ありがとうございました！ Findy AI Meetup in Fukuokaについて 登壇内容 新メンバーのために、シニアエンジニアが環境を作る時代 エンジニア以外のメンバーがPull requestを作るようになった Pull requestの品質が課題に AI時代のシニアエンジニアができること 生成AI時代のエンジニア育成 — 変わる時代と変わらないコト 生成AIでコードの作り方が変わった 現場で起きた逆説 AIに「使われる」のではなく「使う」 原点回帰 — 基礎力の価値が上がっている 明日から試せるアクション AIの出力を必ず検証する習慣をつける 基礎知識を体系的にインプットする 「AIに聞く前に公式ドキュメントを読む」時間を意識的に作る チームの開発ルールをエージェントスキルやカスタムインストラクションに落とし込む まとめ Findy AI Meetup in Fukuokaについて Findy AI Meetupは、ファインディのエンジニアが主催する技術系オフラインイベントです。 生成AIやAIエージェントの活用を通じた開発生産性の向上をテーマに、社内での実践事例の紹介やエンジニア同士の交流を目的としています。 福岡での開催は今回で5回目となりました。回を重ねるごとに参加者同士の顔なじみも増え、福岡のエンジニアコミュニティとして根付いてきたことを実感しています。 登壇内容 新メンバーのために、シニアエンジニアが環境を作る時代 1つ目の登壇は、フロントエンドエンジニア/テックリードの新福が担当しました。 エンジニア以外のメンバーがPull requestを作るようになった 生成AIの普及により、エンジニア以外のメンバーでもコードを書けるようになりました。 ファインディでは、デザイナーがClaude Codeを使ってUIドキュメントを作成したり、PdMがCursorでモックを作成するといった事例を確認しています。 直近では、エンジニアがBizメンバー向けにNotion MCPを用いた求人票改善ツールを開発しました。 tech.findy.co.jp 実はこの話にはまだ続きがあります。しばらくすると、今度はBizメンバーが自分でプロンプトを修正し、エンジニアにPull requestを送るようになったのです。 コミットやPull requestの作り方を誰かに教わったわけではありません。AIチャットに聞きながら操作し、Pull requestを作り上げていました。AIチャットが開発の入口となる時代、その波は既にエンジニア以外のメンバーにも届いています。 Pull requestの品質が課題に 一方で、コミットメッセージのフォーマットや命名規則など、開発ルールを知らないまま作られたPull requestには品質面での課題がありました。レビュアーの負担が増え、指摘のたびに手戻りが発生するような事態は避けたいです。 この解決策としては、エージェントスキルの整備が有効と考えられます。 AIチャットから自然言語でエージェントスキルを呼び出すだけで、誰でも開発ルールに準拠したPull requestを作成できます。 AI時代のシニアエンジニアができること シニアエンジニアはこれまで、知識を言語化して伝えること、コードレビューによる品質担保、ペアプロでの指導といった形で、チームの品質と成長を支えてきました。 これらの役割は引き続き重要ですが、AI時代はそれに加えてカスタムインストラクションやエージェントスキルの整備などもシニアエンジニアの仕事になると思われます。 誰でも参加できる仕組みを作ることは、教える相手を選ばない育成インフラの構築につながります。入社1週目の新メンバーが初日からコントリビューションを体験し、「何を作りたいか」に集中できる環境を整えること——それがAI時代のシニアエンジニアの新しい役割となるかもしれません。 生成AI時代のエンジニア育成 — 変わる時代と変わらないコト 次にテックリードマネージャーの戸田が担当しました。 生成AIでコードの作り方が変わった 生成AIの登場によって、開発の進め方は大きく変わりました。「調べる→試す」だったプロセスが「AIに聞く→コピペ」に変わり、詰まる時間は激減しました。 基本的な知識がなくても動くコードが手軽に出せるようになった一方で、公式ドキュメントよりAIへの問い合わせが先になりがちで、「なぜ動くのか」を知らずに実装する機会が増えていました。 現場で起きた逆説 AI導入後、シニアエンジニアのアウトプット量は増えていました。しかし若手エンジニアについては逆の現象が起きていました。 Pull requestの質が落ち、AIが出力したコードを理解せずにレビュー依頼を出すケースが増えたのです。その結果レビューコメントが増え、レビュー負担が上昇し、リードタイムは悪化していました。 トータルで見ると、チーム全体の生産性はさほど変わっていなかったのです。「AIで効率化できた」という実感とのギャップがそこにはありました。 AIに「使われる」のではなく「使う」 この状況を整理すると、若手エンジニアの一部はAIに「使われている」状態でした。 AIが出力したコードが正しいかどうかを判断できず、間違いに気づかないままレビューを依頼する。ハルシネーションを見抜けず、誤った実装をしてしまう。AIに正しい指示を出せないから「作ってください」としか言えず、意図と異なるコードが出てくる。 「使う」状態はその逆です。自分の意図に沿ってAIを動かせる。正誤を判断できるから間違いをその場で弾ける。正しい指示が出せるから意図通りの出力が得られる。 この違いを分けるのは、エンジニアとしての基礎力です。 基礎知識がなければ、正誤判定も正しい指示もできません。動くものを作るレベルは「AIに使われている」状態であり、正しい方法と手順で作るレベルが「AIを使う」状態です。 原点回帰 — 基礎力の価値が上がっている 生成AI時代だからこそ、基礎力の価値はむしろ上がっています。基礎知識、座学、資格取得といった、一見すると地味な取り組みが重要性を増しているのです。 ファインディでは、基本情報技術者試験相当以上の資格を取得することを推奨しています。広く浅い基礎知識を体系的に習得できるという点で、コスパもタイパも高い学習方法です。合格した場合は受験料を会社が負担する制度も用意しています。 基礎力がつくとAIの出力に対する正誤判定の質とスピードが上がり、レビュー前のセルフチェックで問題を潰せるようになります。ハルシネーションを見抜けるようになり、「何かおかしい」と気づける感覚が身に付きます。 さらに、AIに正しい方法と手順で指示を出せるようになるため、レビューでの議論が設計やパフォーマンス、UI/UXといった本質的な内容になります。 今回の登壇と資料が皆さんの参考になると幸いです。 ■ 明日から試せるアクション ■ 明日から試せるアクション 登壇内容を踏まえて、明日から実践できることを整理しました。 AIの出力を必ず検証する習慣をつける AIが生成したコードをそのままコピペするのではなく、「このコードは何をしているか」「なぜこの実装なのか」を自分の言葉で説明できるか確認してからレビューに出しましょう。説明できないコードはレビューに出すべきではありません。 基礎知識を体系的にインプットする 基本情報技術者試験の教材は、ネットワーク、データベース、セキュリティ、アルゴリズムなど、開発の土台となる知識を広くカバーしています。資格取得そのものが目的ではなく、AIの出力を正しく評価するための「物差し」を手に入れることが目的です。 「AIに聞く前に公式ドキュメントを読む」時間を意識的に作る すべてをAI経由にするのではなく、まず公式ドキュメントで基本を理解したうえでAIを活用する、という順序を意識するだけで、コードの理解度は大きく変わります。 チームの開発ルールをエージェントスキルやカスタムインストラクションに落とし込む シニアエンジニアが持つ暗黙知を仕組みとして整備することで、新メンバーやエンジニア以外のメンバーでも開発ルールに準拠したPull requestを作れるようになります。「教える」から「仕組みで支える」への転換です。 まとめ 今回のFindy AI Meetup in Fukuoka #5では、AI時代のエンジニア育成というテーマで2つの登壇を行いました。 登壇を通じて伝えたかったのは、AI時代で環境は大きく変わったが、変わらないこともあるということです。 手を動かし、汗をかき、積み重ねた基礎と経験は絶対に裏切りません。同時に、シニアエンジニアがエージェントスキルやカスタムインストラクションといった仕組みを整備し、誰でも開発に参加できる環境を作ることも重要です。 AI時代だからこその原点回帰として、エンジニアとしての基礎力を鍛えていきましょう。 Findy AI Meetup in Fukuokaは今後も継続して開催していきます。福岡のエンジニアの皆さんとオフラインでつながれるこの場を、これからも大切にしていきたいと思っています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは！ファインディでプロダクト開発部のVPoEをしている 浜田 です。 AI駆動開発が浸透するなかで、エンジニア1人あたりの開発能力は大きく向上しています。しかし、従来のチーム単位のアサイン方式のままでは、そのポテンシャルを十分に引き出せていないと感じていました。 この記事では、私たちが開発プロセスを「チーム単位」から「個人単位」のアサインへ移行した背景と、その結果得られた変化について紹介します。AI駆動開発を取り入れたものの、チームの開発プロセスをどう変えるべきか悩んでいる方に向けた内容です。 これまでの開発プロセス AI駆動開発で見えてきた課題 個人アサイン方式への移行 個人のオーナーシップを高める 技術改善が進みやすくなった まとめ これまでの開発プロセス ファインディのプロダクト開発部には複数の開発チームがあり、それぞれ5名前後のエンジニアにPdMとデザイナーを加えた構成で、協働しながらプロダクト開発を進めています。 これまでの開発プロセスでは、施策開発をチームにアサインし、メンバーそれぞれが優先度の高いタスクをフレキシブルに取っていくスタイルで運用していました。1つの施策開発をチームにアサインすると、結果的に4名程度のエンジニアが集中して取り組み、一気に開発を完了させるという進め方です。いわばフロー効率を重視した開発スタイルで、最も優先度の高い施策を最速で完了させることに注力していました。 この方式はチームの連携が生まれやすく、うまく機能していました。複数人が同じ施策に取り組むことで、設計の議論がその場で生まれたり、実装中に詰まったときもすぐに相談できたりと、チームで動くからこその強みがありました。 AI駆動開発で見えてきた課題 AI駆動開発の導入により、エンジニア1人が同時に扱える開発量は増えました。タスク分解をおこなって依存関係さえ明確にできれば、かなりの数のタスクをAIエージェントに渡して並列で進めることが可能です。加えて、これまではキャッチアップに時間がかかっていたような、自身の習熟度が低い技術スタックの部分であっても、AIをパートナーにして自力で開発を進められるようになりました。 しかし、フロー効率を重視した従来のスタイルでは、このAIのポテンシャルを十分に引き出せませんでした。複数のエンジニアで1つの施策を分担している状態では、一人ひとりが持つタスクの粒度はすでに細かくなっています。そこからさらにタスクを分解して複数のAIエージェントに並列で任せるのは難しく、AIの役割はあくまで副操縦士としての補助にとどまっていました。 加えて、タスクのアサインを明確に決めず、手が空いた人から優先度の高いタスクを取っていくスタイルでは、自分がこの先どのタスクを担当するかが見通せません。先の計画が立たない以上、AIエージェントに先回りしてタスクを渡して並列で進めてもらうこともできず、結局は目の前の1つのタスクをAIと一緒にこなすだけになってしまいます。 個人アサイン方式への移行 そこで、施策開発を個々のエンジニアにまるごとアサインする方式へと切り替えました。 1人が施策全体を担当することで、タスクの分解と計画を自分の裁量で行えるようになります。どの部分をAIエージェントに並列で任せ、どの部分を自分で手を動かすかを事前に整理できるので、AIを副操縦士ではなく、複数の作業を同時に進めるパートナーとして活用できるようになりました。 具体的には、Claude Codeのような自律型エージェントを用いて複数のワーカーを立ち上げます。そして、あるコンポーネントの実装やテストコード生成をそれらに並列で進めさせながら、自身は全体の設計やオーケストレーションに集中する、といった働き方です。 この「1人のエンジニアが複数のAIエージェントを指揮する」具体的なワークフローについては、以下の記事で詳しく解説していますので、あわせてご覧ください。 tech.findy.co.jp フロー効率を重視していた頃と比べると、最も優先度の高い施策が完了するまでの速度は低下します。4名で集中して取り組んでいたものを1名で担当するのですから、これは当然のトレードオフです。しかし、エンジニア間のコミュニケーションコストが減ることや、AIによるアウトプット量と速度の向上により、大きく低下させることなく開発を進められています。さらに、2番目、3番目に優先度の高い施策も別のエンジニアが並行して開発を進めるため、個々の施策にかかる期間が延びても、結果としてより多くの施策を素早くリリースできるようになりました。 実際に、この変化は定量的な指標にも明確に表れています。以下のグラフは紹介した変更を行なった開発チームのPR（プルリクエスト）作成数の推移ですが、個人アサインへの移行を本格的に進めた2026年2月中旬以降、PR数が明確に一段増えていることがわかります。個人のポテンシャルを引き出すアプローチが、開発チーム全体のアウトプット最大化に繋がった形です。 一方で、チーム全体のまとまりという意味では変化がありました。これまでのように全員で1つの開発に集中する場面は減り、どちらかというと個々の集まりに近い形になっています。 ただし、チームとしての連携を完全に手放したわけではありません。たとえば設計の方針に関わる判断は、個人で抱えずチームで議論してから進めるようにしていますし、実装についても「属人化」を防ぐためにプルリクエストをこまめに分割してレビューし合うプロセスを維持しています。さらに、各自が何に取り組んでいるかを定期的に共有する場を設けることで、お互いの状況が見えなくなることも避けています。つまり、チームとしての協働がなくなったのではなく、その関わり方が変わったというのが正確な表現です。 個人のオーナーシップを高める AI時代だからこそ、個人を目立たせることが重要だと考えています。 チームの一員として開発に参加するだけでは、個々のエンジニアの貢献が見えにくくなります。極端に言えば、AIに代替されやすいポジションになってしまう可能性もあります。個人がオーナーシップを持ち、「これは自分がやった」と自信を持って言える状態をつくることが、エンジニアとしての価値を高めることにつながると思っています。 個人アサインに移行したことで、各エンジニアが担当する施策に対して当事者意識を持って取り組むようになりました。設計の意思決定からリリースまでを一貫して担うことで、施策全体を自分ごととして捉える姿勢が自然と生まれています。また、チームで開発していた頃はどうしても窓口がチームリーダーに集中しがちでしたが、施策ごとに個人をアサインしているため、メンバーそれぞれがPdMや事業メンバーと直接やりとりをおこなうようになりました。その結果、施策の背景やリリース後の効果に対する意識が上がるなど、良い効果が出ています。 これはマネジメントの観点からも好ましい変化でした。誰がどの施策を推進しているかが明確になるので、成果の可視化にもつながります。チームの中で埋もれるのではなく、一人ひとりの仕事が見える状態をつくることが、エンジニアのモチベーションにもよい影響を与えていると感じています。 技術改善が進みやすくなった 個人アサインに切り替えたことで生まれたもう1つの変化として、技術的な改善が進みやすくなったことがあります。 チーム全体で施策開発に集中していた頃は、技術改善やリファクタリングはどうしても後回しになりがちでした。個人にアサインされる形になったことで、自分の裁量で改善タスクを差し込みやすくなりました。実際に、以前はなかなか手がつけられなかったライブラリのアップデートやテストの整備といった地道な改善が、各エンジニアの判断で着実に進むようになっています。 チームとしてもリソース配分を明確にしました。施策開発、改善、その他の割合を7:2:1と定めたことで、「2割のリソースは技術改善に使おう」という共通認識が生まれ、改善活動に取り組みやすい環境が整っています。 まとめ フロー効率を重視したチーム開発から、AIのポテンシャルを引き出す個人アサインへと開発プロセスを移行しました。個々の施策が完了するまでの速度は下がるものの、AIエージェントを活用した並列開発によってチーム全体のアウトプットはむしろ増加し、実際にPR数にもその変化が表れています。加えて、個人のオーナーシップが高まり、技術改善にも手が回るようになりました。 チームのまとまりが薄れるリスクはありますが、設計判断の議論やレビューといった連携ポイントを意識的に残すことでバランスを取っています。AI駆動開発を推進するなかで開発プロセスの見直しを検討している方の参考になれば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でFindy AI+の開発をしているdanです。 Findy AI+ は、AIツールを導入したけれど、実際にどれくらい効果があるのかという問いに対して定量的に答えるための分析ワークフローを新たにリリースしました。 今回は、これらのワークフローを使って実際にどのような示唆を得られるのかについて実践形式で紹介します。AIツールを導入したものの効果が見えづらいと感じているEMやPdM、チームの活用状況を把握したいエンジニアの方に向けて、MCPサーバーとGitHub Actionsそれぞれでの実行手順と、分析結果からチームの改善ポイントを見つけるまでの流れを紹介します。 Findy AI+とは 開発チームで分析してみた AI環境整備コミット履歴分析（MCPサーバー経由） AIと人のPR作成量比率分析（GitHub Actions経由） Findy AI+の分析ワークフローについて 分析ワークフローでできること GitHub Actionsで分析を自動化 おわりに Findy AI+とは Findy AI+ は、GitHub連携やプロンプト指示を通じて生成AIアクティビティを可視化し、生成AIの利活用向上を支援するサービスです。 人と生成AIの協働を後押しし、開発組織の変革をサポートします。 Claude Code、GitHub Copilot、Codex、Devinなど様々なAIツールの利活用を横断的に分析しています。 今回リリースされた分析ワークフローはMCPサーバー・GitHub Actionsの両方に対応しており、定期的に開発組織の状態について改善サイクルを回せる仕組みをサポートしています。 開発チームで分析してみた ファインディのある開発チームで分析してみました。 分析ワークフローは7種類ありますが、今回はそのうち2つをMCPサーバー経由、GitHub Actions経由の両方で実行しています。 AI環境整備コミット履歴分析（MCPサーバー経由） AI設定ファイルへの貢献者を分析することができます。コミッター統計、PR作成者統計、ファイル別の分析結果が表示されるため、有識者の把握やナレッジ共有のきっかけにすることができます。 MCPサーバー経由の分析は、VS Codeを使用していればChatからスラッシュコマンドを実行するだけで始められます。 コマンドを実行すると、対話形式でリポジトリ名・開始日・終了日の3つのパラメータを順番に入力していきます。 次のようなプロンプトで分析を依頼できます。 以下の条件でAI設定ファイルへの貢献を分析してください： 【分析対象】 - リポジトリ: Repository-A - 期間: 2025-10-01から2026-02-28 【分析観点】 - AIツールの設定に最も貢献しているメンバーの特定 - 設定ファイルごとのメンテナンス状況 - 貢献パターンや傾向の洞察 パラメータの入力が完了すると、MCPサーバーへのツール実行許可を求められます。内容を確認して許可すると、分析が開始されます。 MCPサーバーのツール実行結果です。 Ran AI Configuration File Contributions Input { "repository": "Repository-A", "date_from": "2025-10-01", "date_to": "2026-02-28" } Output # AI環境整備コミット履歴分析レポート **リポジトリ**: Org/Repository-A **分析期間**: 2025-10-01 〜 2026-02-28 **分析実行日**: 2026年03月26日 ## 🎯 論点別サマリ ### 論点1: 誰がAI活用環境整備に貢献しているか？上位は誰か？ **回答**: user1が圧倒的な貢献者で全体の73.5%を占める。次いでuser2が20.6%、user3とuser4が少数貢献。 **インサイト**: user1が中心的役割を担い、特に2025年12月に集中的なリファクタリングと拡充を実施。user2は初期構築とCI整備に貢献。 ### 論点2: 最後に最新化されたのはいつか？更新が古すぎないか？ **回答**: 最終更新は2026-01-21で約2ヶ月前。月平均7.0コミットで継続的に更新されているが、直近2ヶ月は停滞気味。 **インサイト**: 2025年12月に大規模な整備が完了後、更新が減少。定期的なメンテナンスサイクルの確立が望ましい。 ## 1. 貢献パターン分析 **インサイト**: user1は.claude/context/配下の構造化に注力（11コミット）し、アーキテクチャ設計を主導。user2はCI/CDとエージェント初期設定に特化。役割分担が明確。 --- 📊 貢献者別コミット割合 user1 ███████████████░░░░░ 73.5% (25件) user2 ████░░░░░░░░░░░░░░░░ 20.6% (7件) user3 █░░░░░░░░░░░░░░░░░░░ 5.9% (2件) user4 █░░░░░░░░░░░░░░░░░░░ 2.9% (1件) 分析が完了すると、次のようなレポートが出力されます。トップコントリビューターの一覧、設定ファイル別のメンテナンス状況、月別コミット推移などが可視化されており、誰がいつどのファイルを整備したのかが一目で分かります。 一部出力内容ですが、出力データをもとに、メンテナンス状況と貢献パターンのサマリーも整理されます。 ## AI設定ファイル貢献分析レポート **リポジトリ**: Org/Repository-A | **期間**: 2025-10-01 〜 2026-02-28 ### 1. 設定ファイルごとのメンテナンス状況 | ファイル/ディレクトリ | 最終更新 | 主要メンテナー | 状態 | |----------------------|---------|---------------|------| | CLAUDE.md | 2025-12-10 | user1 | 約3.5ヶ月未更新 | | settings.json | 2026-01-14 | user1 | 約2ヶ月未更新 | | .claude/context/ | 2025-12-09 | user1 | 約3.5ヶ月未更新 | | .claude/agents/ | 2025-12-16 | user1, user2, user3 | 約3ヶ月未更新 | ### 2. 貢献パターンと傾向 **時系列の傾向**: - **2025年10月**: user2による初期構築フェーズ（Claude Codeエージェント設定、PR作成エージェント） - **2025年11月**: user1がCI/CD軽量化から参入 - **2025年12月**: **最も活発な月（23コミット）** — user1による`.claude/context/`への大規模分割、Copilot設定統合、@記法導入。user2によるセキュリティ関連整備も同時進行 - **2026年1月**: 2件のみ。整備完了後の安定期に入った可能性 - **2026年2月**: コミットなし **役割分担**: - **user1**: アーキテクチャ設計・構造化のリード（context分割、設定統合） - **user2**: 初期設計とCI/CDセキュリティ強化 - **user3 / user4**: セットアップガイドやドキュメント補完のスポット貢献 **推奨アクション**: - 主要設定ファイル（CLAUDE.md、copilot-instructions.md）が3ヶ月以上未更新のため、プロジェクトの現状と乖離がないか定期的なレビューサイクルの確立が望ましい - 貢献者がuser1に集中しているため、バス係数（Bus Factor）の観点からナレッジ共有の促進も検討すべき AIと人のPR作成量比率分析（GitHub Actions経由） AIに任せられる可能性がある業務領域を特定し、最適な分担を提案することができます。メンバー別AI活用率やPR作成量の偏在度を確認できるので、新機能開発と運用開発の分担を考え直すきっかけ作りにつながります。 GitHub Actionsでの分析は、リポジトリのActionsタブから手動実行できます。対象リポジトリ名と分析期間を入力して「Run workflow」を押すだけです。 分析が完了すると、結果のサマリーがSlackに自動通知されます。チームメンバー全員がすぐに結果を確認でき、定期実行と組み合わせることで月次の振り返りにも活用できます。 結果はGitHub Issueとしても自動作成されているので、Slack通知内のリンクから遷移できます。構造化されたレポートが作成され、チーム内での共有や議論をする親Issueとしても活用できます。 詳しいセットアップ方法は GitHub Actionsでの分析セットアップガイド をご覧ください。 Findy AI+の分析ワークフローについて ここまで紹介してきた分析は、Findy AI+が新たに提供を開始した分析ワークフローを使って実行したものです。ここからは、ワークフローの全体像と活用方法を紹介します。 分析ワークフローでできること 今回のリリースでは、次の7種類の分析ワークフローを提供しています。 ワークフロー できること Agent Environment Analysis AI向け指示ファイル・フォルダをスコア化し、自走環境の整備度合いを診断 PR Reviews Analysis コード変更者・開発環境の伸びしろを特定し、改善施策を提案 PR Productivity Analysis AI活用によるアウトプット量の変化や機能開発への影響を分析 AI-Human Collaboration Analysis AIに任せられる業務領域を特定し、最適な分担を提案 Multi AI Cost Comparison 複数AIツールのROIを人件費対比で算出 PR Type Summary PRの作業種別ごとにサマリーを生成 Findy AI+ PR Review PRオープン時にAIレビューを自動実行し、結果をコメント投稿 これらはMCPサーバー・GitHub Actionsの両方からご利用いただけます。 GitHub Actionsで分析を自動化 GitHub Actionsを使えば、上記の分析をリポジトリから定期実行できます。デフォルトでは毎月1日にスケジュール実行される設定になっており、頻度はカスタマイズ可能です。GitHub Web UIやCLIからの手動実行にも対応しています。 分析結果はSlackチャンネルに自動通知されるため、チーム全体で定期的に確認し改善サイクルを回す運用が実現できます。チーム単位での分析にも対応しているので、組織全体だけでなくチームごとの傾向把握も可能です。 気になるポイントをさっと確認したいときはMCPサーバー、じっくり深堀りしたいときはGitHub Actionsという使い分けがおすすめです。 おわりに 今回は、Findy AI+の分析ワークフローを使って、ある開発チームのAI活用状況を約1年にわたって追いかけてみました。 AI環境整備コミット履歴分析では、誰がAI設定を整備しているのか、どのファイルがどの時期に集中的に更新されたのかが見えてきました。AIと人のPR作成量比率分析では、AI活用率の推移やメンバー間の活用度の差が可視化されました。こうした数字があることで、「なんとなくAIを使っている」という感覚ではなく、具体的にどこに課題があり、何を改善すべきかを議論できるようになります。 AIツールを導入したものの効果が見えづらいと感じている方は、まず自分たちのチームの現状を可視化するところから始めてみてください。データがあれば、次の一手が見えてきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

キャリアプロダクト開発部の森 ＠jiskanulo です。 私ごとですが今年で45歳、WEBサービスの開発歴は20年以上になります。世間的にはベテランエンジニアとかシニアエンジニアとかと称される類だと自認しています。 そんな私ですが2026年1月に基本情報技術者試験を受験して合格しました。 この記事は、ベテランエンジニアが基本情報技術者試験をスキル棚卸しツールとして活用した体験と、受験しなくても使えるセルフチェックの方法を紹介します。 www.ipa.go.jp 受験の動機 結果 得意と苦手が可視化された 得意だった領域 苦手だった領域 得意と苦手のコントラストが意味するもの 試験範囲でスキルを棚卸しする方法 受験のTips CBT受験の雰囲気 集中力の維持に課題 まとめ 受験の動機 受験したきっかけは昨今のAIエージェントを前提とした開発手法の変化です。 ファインディではAIエージェントの導入・検証を積極的に行っています。 私もDevin, GitHub Copilot Chat, Cline, Claude Codeなどさまざまなツールやサービスを日々の開発業務に導入すべく検証していました。 2025年6月頃からClaude Codeを本格的に使用しはじめ、2026年3月現在では私自身が手でコードを書くことは全くなくなりました。 昨今のAIエージェントが主となり開発を進める体制では、AIエージェントへ適切な指示を出す力、AIエージェントからの提案を判断し承認・修正するための力が求められます。 この力をつけるための基礎知識として、基本情報技術者試験の内容はちょうどよいと感じています。 また、2025年末に開発部で「基本情報技術者試験の合格を目指しましょう」という方針も出たこともあり、社内のメンバーが続々と受験・合格している流れに乗りました。 受験理由をもう一つ挙げると、実は基本情報技術者試験を20年ほど前に受験して不合格になっており再挑戦をしないままでした。 さらに後年に応用情報技術者試験を受験し合格しているのですが、応用情報は持っているのに基本情報は持っていないというチグハグ感を解消したかったのです。 近いうちにデータベーススペシャリスト試験を受けようと考えていたところ、2026年度からCBT（コンピュータベースの試験）方式に移行するという情報があり、CBTの雰囲気を先に体験しておきたいという思いもありました。 ただデータベーススペシャリスト試験の実施そのものが2026年中は不明瞭な状況です。動向を注視しつつ、申し込みが再開されたらすぐエントリーしたいですね。 www.ipa.go.jp 結果 科目Aは705点、科目Bは680点となんとか合格できました。もう少し余裕を持って合格したかったのですが、そこは今後の伸びしろとします。 得意と苦手が可視化された 受験して最も収穫だったのは、自分のスキルの輪郭がはっきり見えたことです。 得意だった領域 計算問題やコードリーディング、データベース正規化や稼働率計算などの問題はスムーズに解けました。 日常業務でコードを書き、レビューし、設計・運用を考えることを毎日やっているので、実務経験がそのまま得点に結びつきました。 過去問の模擬試験でもこれらの分野は正答率が高く、特別な対策をしなくても安定して解ける状態でした。 苦手だった領域 一方、会計管理や財務指標に関する問題には苦戦しました。損益分岐点、ROI、減価償却といったテーマは過去問を解いていても正答率が目に見えて低い分野でした。 振り返ってみると、日々の開発業務で財務指標を意識する場面はほとんどありませんでした。 業務で触れない領域は経験年数に関係なく穴のまま残っている。この気づきが、受験して得た最大の収穫でした。 得意と苦手のコントラストが意味するもの この経験から見えたことは、エンジニアのスキルは実務でカバーしている範囲には自然と強くなれるが、逆に触れていない範囲は何年経っても盲点のままだということです。 基本情報技術者試験の出題範囲はITエンジニアの基礎知識を広くカバーしています。 だからこそ、受験すると自分のスキルマップの中で「どこが埋まっていて、どこが空白か」が浮き彫りになります。 試験のための勉強がすぐにサービス開発に活かせるかというとそうでもないのですが、自分の基礎知識の全体像を把握するにはちょうどいい粒度だと感じました。 試験範囲でスキルを棚卸しする方法 受験するにあたり、基本情報技術者試験ドットコムに大変お世話になりました。 www.fe-siken.com 私の場合は1日30分、20日間ほどで合計600問を回答しました。無料サービスの範囲でも十分に過去問を試すことができますし、有料のメンバー登録をすると学習の記録管理がしやすくなります。 スキル棚卸しをするために、まず科目Aの過去問を解いてみてください。 分野ごとの正答率が記録されるので、自分がどの分野に強く、どの分野に穴があるかが数値で可視化されます。 参考として、基本情報技術者試験の科目A出題範囲をもとにしたセルフチェック表を載せておきます。自分が「得意」「苦手」「触れたことがない」のどれに当たるか振り返ってみてください。 分野 自己評価（筆者の例） 基礎理論（離散数学、情報理論等） 得意 アルゴリズムとプログラミング 得意 コンピュータ構成要素 得意 システム構成要素 得意 ソフトウェア 得意 ハードウェア 苦手 データベース 得意 ネットワーク 苦手 セキュリティ 得意 マネジメント（プロジェクト・サービス） 苦手 ストラテジ（経営戦略・法務） 苦手 表のとおり、実務で日常的に使う分野は得意、そうでない分野は苦手という傾向がはっきり出ました。 正答率が安定して高い分野は実務でカバーできている基礎知識。低い分野やまったく分からない分野は、業務で触れていない盲点です。「知っているつもりだったが正確には理解できていなかった」という曖昧な領域も見つかるかもしれません。 受験のTips CBT受験の雰囲気 当日午後に受験会場に着くと、試験開始時刻前でも受験を始めてよいと案内されました。 パソコンに向かう前に持ち物検査を終えて着席。 キーボードはログイン時にしか使わず、試験中はマウス操作のみ。紙とペンは貸してもらい、筆算やコードのトレースをしながら回答しました。 回答完了ボタンを押すとすぐに得点が表示され、合否をその場で確認できました。結果待ちのモヤモヤがなかったのは嬉しいポイントでした。 集中力の維持に課題 科目Bの時点で集中力が切れてしまったのが今回の反省点です。 20年前は午前問題のあとに2時間ほどの昼休みがあり、リフレッシュしてから午後問題に臨めました。現在の形式では科目Aのあと10分の休憩で科目Bが始まるため、体力的にも精神的にも消耗した状態で後半戦に入ることになります。 受験する前には十分に体調を整えて臨むことをおすすめします。 まとめ 基本情報技術者試験は、資格取得という目的だけでなく、自分のスキルの得意と苦手を可視化するツールとして活用できました。 スキルを可視化できたこともあり、今年中にデータベーススペシャリスト試験の合格を目指して準備を進めていこうと思います。 みなさんも試験を受けてみてください。受験しなくても、過去問を試すだけでスキルの棚卸しになりますよ。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 Findy AI+ 開発チームのdanです。 この記事は「 エンジニア達の人生を変えた一冊 」として、ファインディのエンジニアが人生を変えた本を紹介していくシリーズです。 一冊の技術書がきっかけで、新しい分野に足を踏み入れたり、日々のコードの書き方が変わったりした経験はありませんか？今回は私・danと、千田さんの2名が、自分にとって転機となった本をお届けします。 それでは、さっそく紹介していきましょう！ SREの知識地図——基礎知識から現場での実践まで この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ 今気になってる本 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ おわりに ■ dan / エンジニア ■ 普段は Findy AI+ でバックエンド・フロントエンドの開発をしているdanです。若干Terraformデビューをしました。 SREの知識地図——基礎知識から現場での実践まで SREの知識地図——基礎知識から現場での実践まで 作者: 北野 勝久 , 近藤 健司 , 小林 良太郎 , 渡部 龍一 , 齊藤 拓朗 , 柘植 翔太 , 横山 達男 技術評論社 Amazon 私が紹介する「SREの知識地図」は、Site Reliability Engineeringの全体像を一冊で見渡せるように書かれた書籍です。 この本を読んだきっかけ SRE領域にはずっと興味がありました。サービスを安定して届けることの重要性は日々の開発で実感していたものの、自分の中でSREは「サービスを支えている、すごい人たち」くらいの解像度でした。 そんなとき Findy AI+ の業務でドメイン切り替えの対応を担当することになりました。インフラ寄りの知識が求められる場面が増え、これはいい機会だと思い、SREについて体系的に学んでみようと決めました。 とはいえ何から手をつければいいかわからず、社内のSREチームに、どこから触れていくのがいいかと相談しに行ったところ、この本を紹介してもらいました。 本の内容 本書はSLO・エラーバジェットの設計から、モニタリングとオブザーバビリティ、ポストモーテム、オンコール体制、トイル削減、本番リリースレビュー(PRR)まで、SREの主要な概念を9章にわたって網羅しています。組織構造の選択と実際の導入事例にも触れられています。 タイトルの「知識地図」が的を射ていて、各章が独立したトピックでありながら、章をまたいで読むとSREという領域の輪郭がはっきり浮かび上がってくる構成です。 技術的なプラクティスだけでなく「SREチームをどう組織に根づかせるか」という話まで書かれているのが、この本の特徴だと感じました。 この本から影響を受けた点/学んだ点 一番大きかったのは、「信頼性は100%を目指すものではない」という考え方に触れたことです。SLOとエラーバジェットの仕組みを知り、信頼性と開発スピードのバランスを定量的に議論できるという発想に衝撃を受けました。 普段のアプリケーション開発では「落ちないこと」が当然の前提になりがちですが、SREの視点ではエラーバジェットが残っている限りリスクを取ってリリースできるし、使い切ったら信頼性の改善に集中する。このトレードオフの設計思想は、開発者としてのものの見方を変えてくれました。 現在、SREチームと隔週で定点観測会を行っているのですが、本書でSLOの概念を理解してから臨めたことで、観測結果の受け取り方が変わりました。 数値の変動から仮説を立てる思考プロセスや、そこからNext Actionにつなげる動き方など、SREチームの実践を肌で学べています。本書がなければ、観測会に参加しても表面的な数字を眺めるだけで終わっていたかもしれません。 特に印象に残った部分 ポストモーテムの章で触れられていた、障害が起きる前の小さな異変から学びを得るという考え方が印象に残っています。 Findy AI+ ではアラート体制の基盤を強化する余地がありました。SREチームと一緒に、まずそこを整えるところから始め、モニタリングのダッシュボードを作り、そこから定点観測で振り返る。会を重ねるごとに着実に前進できていると実感しています。本書で読んだ「軽量に回せる学習サイクル」を、まさに今つくっている最中です。 もうひとつ、第9章の「SREの実践」で書かれていた、開発チームの課題に寄り添うというアプローチにも強く共感しました。ドメイン変更の対応でSREチームと一緒に動いたとき、ただサポートされているのではなく、同じ目線で一緒に進めているという感覚がありました。 SREプラクティスを一方的に推進するのではなく、チームが直面している具体的な課題にまず寄り添う これはSREに限った話ではなく、自分が何かを提案するときにも同じことが言えると思います。新しいツールやプロセスを持ち込みたいとき、まず相手が今何に困っているかから入ることで提案は押し付けではなく解決策になるのではと感じました。 このような方におすすめ 自分のようにアプリケーション開発がメインだけど、インフラや運用にも関心が出てきたエンジニアにはぴったりの一冊です。SREの全体像を短時間でつかめるので、これからSRE領域に踏み出す最初の一冊として機能します。 また、すでにSRE的な業務に携わっている方にとっても、自分の実践を体系の中に位置づけ直す機会になると思います。 私の経験ではエラーの発生でSLOの数値が下がっているという議論があったときに、なぜエラーがSLOに影響するのか、サーバーが返すエラーの仕組みを変えられそうかを考える土台になったのは、本書で得た知識でした。 今気になってる本 LLMの原理、RAG・エージェント開発から読み解く　コンテキストエンジニアリング LLMの原理、RAG・エージェント開発から読み解く　コンテキストエンジニアリング エンジニア選書 作者: 蒲生 弘郷 技術評論社 Amazon Findy AI+ ではLLMが分析したものをサービスに取り入れています。現在、機能が増えていく中で分析の精度がネックになっており、プロンプトの調整に課題を感じています。 この本ではLLMがどのように解釈して分析をしているのか、なにをさせてはいけないのかなども書かれており、サービスのためのキャッチアップ以外では、現在のAI駆動開発にも活かせる本なのではないかと思っています。 続いては、キャリアプロダクト開発部 転職開発チームの千田さんです。千田さんが選んだのは、多くのエンジニアにとってバイブルともいえるあの一冊。「良いコードとは何か」を考えるきっかけをくれた本について語ってもらいました。 ■ 千田 / エンジニア ■ キャリアプロダクト開発部 転職開発チームの千田です。 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 作者: ダスティン・ボズウェル , トレバ-・フォシェ , 角征典 オライリージャパン Amazon 私が紹介する「リーダブルコード」は、コードの読みやすさに焦点を当てた実践的な書籍です。 この本を読んだきっかけ 新人エンジニアとして働き始めたとき、「正しいコードの書き方」がわからなくて悩んでいました。動くコードは書けるけれど、それが良いコードなのか自信が持てない。レビューで指摘されても、なぜそう書くべきなのか腑に落ちないことがありました。 そんなときに出会ったのがこの本です。エンジニアの間で定番書として名前を聞くことが多く、まずはここから始めてみようと手に取りました。 本の内容 本書は「コードは他の人が最短時間で理解できるように書かなければいけない」という原則のもと、変数名の付け方、コメントの書き方、条件分岐の整理、式の分割といったテーマを13章にわたって解説しています。 Before/Afterのコード例が豊富に載っていて、「読みやすいコードとは何か」を実践的に説明してくれます。 コードレビューのとき、なんとなく「こっちのほうがいいと思う」とは感じるのに、言葉にできない。そういう経験を持っている方は多いのではないでしょうか。この本を読むと、「なぜ読みやすいと感じるのか」を論理的に説明できるようになります。 この本から影響を受けた点/学んだ点 一番大きかったのは、コードを書く上での自信が生まれたことです。 本書を読む前は、レビューで「こう直したほうがいい」と言われても、それが一般的なルールなのか、その人の好みなのか区別がつきませんでした。本書は「理解するまでにかかる時間」を短くするという明確な判断軸を示してくれます。 この軸を手に入れたことで、「なぜこう書いたのか」を自分の言葉で説明できるようになりました。 例えば、1行に詰め込んだ複雑な式よりも2行に分けたほうが理解しやすいケースがある。短いコードこそ良いコードだと思い込んでいた当時の自分にとって、コードの良し悪しは行数ではなく読み手の理解コストで決まるという考え方は新鮮でした。 特に印象に残った部分 2つあります。 ひとつはコメントについての章です。新人の頃はコメントをどこに書けばいいのかわからず、結局ほとんど書いていませんでした。本書では「コードからすぐにわかることをコメントに書かない」としつつ、設計意図やコードの欠陥など「監督のコメンタリー」としてのコメントは積極的に書くべきだと述べています。 コメントを書くか書かないかではなく、「読み手にとって新しい情報を提供するか」で判断する。この基準を知ったことで、コメントを書く場面と書かない場面の区別がつくようになりました。 もうひとつは、説明変数と要約変数の考え方です。本書では、複雑な式や繰り返し登場する条件を変数に切り出すことで、コードの意図を明確にする手法が紹介されています。 例えば request.user.id == document.owner_id という式は、要素が多くて読み解くのに少し時間がかかります。でもこれを user_owns_document という変数に置き換えると、コードが伝えたいことは「ユーザーがこの文書の所有者かどうか」だとすぐにわかる。式が「何をしているか」ではなく「何を意味しているか」を伝えるようになるわけです。 この考え方を知ってから、条件分岐やif文の中に長い式をそのまま書くことに違和感を覚えるようになりました。変数名をつけるという小さな工夫が、コード全体の読みやすさに大きく影響することを教えてくれた例でした。 このような方におすすめ コードを書き始めたものの、何が良いコードなのかわからないという方にはぴったりの一冊です。設計パターンやアーキテクチャのような大きな話ではなく、日々のコーディングですぐに実践できる内容が詰まっています。 また、経験を積んだエンジニアにとっても、普段無意識にやっていることを言語化し直すきっかけになると思います。レビューで「なんとなくこっちのほうがいい」としか言えなかった感覚に、言葉を与えてくれる本です。 おわりに SREの全体像をつかむための入門書と、日々のコーディングを支える定番書。今回の2冊は方向性こそ異なりますが、私はSLOとエラーバジェットという定量的な視点を、千田さんは「読み手の理解コスト」というコードの良し悪しを測る基準を、それぞれ本から得ていました。 判断軸があると、迷ったときに立ち返る場所ができる。技術書との出会いがそういうきっかけになることを、少しでもお伝えできていれば嬉しいです。 ファインディでは一緒に働くメンバーを募集しています。少しでも興味を持っていただけた方は、ぜひこちらをご覧ください！

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 ファインディではClaude CodeのSkillやカスタムコマンドなどをPlugins経由で社内展開しています。 tech.findy.co.jp AIに実装を任せる場面が増えるほど、開発者は複数のタスクを並列で進めたくなります。 レビュー待ちの間に別のIssueに着手したり、hotfixを即座に対応したりが良い例です。 ファインディでもGit worktreeを活用した並列開発を実践しています。 tech.findy.co.jp Git worktreeは非常に便利な機能ですが、実際にチームで使おうとすると「コマンドが多い」「クリーンアップを忘れる」「環境ファイルのコピーが面倒」といった運用上のハードルが立ちはだかります。 本記事では、Git worktreeの操作をClaude Codeのスキルに閉じ込めて、チーム全員が簡単に並列開発できるようにした取り組みを紹介します。スキルの設計判断や、他のスキルとの連携についても触れるので、Claude Codeでの効率化に興味がある方の参考になれば幸いです。 Git worktreeとは 手動でworktreeを使った場合 スキルに閉じ込めた スキル設計の工夫 他のスキルとの連携 「複雑さはスキルに閉じ込める」という考え方 まとめ Git worktreeとは Git worktreeは、1つのリポジトリに対して複数の作業ディレクトリを作成するGitの機能です。 通常、あるブランチで作業中に別のブランチへ切り替えるには git stash や git switch が必要ですが、worktreeを使えばディレクトリごとブランチを分離できます。 # メインの作業ディレクトリ（feature/auth ブランチ） ~/project/MyApp/ # worktreeで作った別の作業ディレクトリ（fix/login-bug ブランチ） ~/project/MyApp/.claude/worktrees/fix-login-bug/ それぞれのディレクトリが独立したブランチを持つので、片方でコードを書きながら、もう片方でレビュー修正を進めるといった使い方ができます。 手動でworktreeを使った場合 Git worktreeの概念はシンプルですが、実際の運用では手順が多くなります。新しいworktreeを作って作業を始めるまでに必要なコマンドを並べてみます。 # 1. worktreeを作成してブランチを切る git worktree add .claude/worktrees/fix-login-bug -b fix/login-bug # 2. 作成したディレクトリに移動 cd .claude/worktrees/fix-login-bug # 3. 環境ファイルをコピー（.envやSSL証明書など） cp ../../.env . cp ../../.env.local . cp ../../localhost.pem . cp ../../localhost-key.pem . cp ../../.claude/settings.local.json .claude/ # 4. 依存パッケージのインストール npm install # or bundle install, etc. 4ステップ、コマンドにして8行以上。しかもこれは「worktreeを作る」だけの話です。 作業が終わったあとのクリーンアップも忘れてはいけません。 # 5. 元のディレクトリに戻る cd ~/project/MyApp # 6. worktreeを削除 git worktree remove .claude/worktrees/fix-login-bug # 7. 不要なブランチを削除（オプション） git branch -d fix/login-bug これだけの手順を毎回正確にこなすのは、慣れた開発者でも面倒です。 チームに導入しようとすると「手順書を読む気にならない」「クリーンアップを忘れてworktreeが残り続ける」という問題が起きます。実際、社内でworktreeを勧めても「便利そうだけど、手順が多くて複雑に見えてしまい重い腰が上がらない」という反応が大半でした。 スキルに閉じ込めた Claude Codeには「スキル」という仕組みがあります。Markdownファイルにワークフローを記述しておくと、スラッシュコマンドとして呼び出せます。 スキルの作り方や基本的な考え方については、次の記事で詳しく紹介しています。 tech.findy.co.jp 実はClaude Code自体にも --worktree フラグがあり、worktreeの作成とセッション切り替えはできます。ただし、これだけでは足りませんでした。 --worktree が担うのはworktreeの作成のみで、 .env のコピーや依存パッケージのインストールといった環境セットアップは含まれません。プロジェクトごとにセットアップ要件が異なる点や、他のエージェントやスキルからワークフロー的に呼び出したい点を考えると、スキルとして設計する必要がありました。 そこで今回は、Git worktreeの複雑な操作をスキルに閉じ込めることにしました。 使い方はシンプルです。Claude Codeで次のように入力するだけで、worktreeの作成から環境セットアップまでが完了します。 > /git-worktree feature/add-auth 先ほどの8行以上のコマンドが、この1行に集約されます。裏側では次の処理が自動で実行されています。 メインリポジトリのパスを記録 EnterWorktree で .claude/worktrees/feature-add-auth/ にworktreeを作成 セッションの作業ディレクトリを自動で切り替え .env やSSL証明書など、必要な設定ファイルをコピー ここで重要なのが、Claude Codeが提供する EnterWorktree と ExitWorktree という2つのツールです。 EnterWorktree はworktreeの作成とセッションのディレクトリ切り替えを一度に行います。通常の git worktree コマンドでは作成後に cd で移動する必要がありますが、 EnterWorktree ならClaude Codeのセッション自体が新しいworktreeに切り替わるため、その後のすべての操作が自動的にworktree内で実行されます。 作業が終わったら ExitWorktree を呼ぶだけです。元のディレクトリに戻りつつ、セッション終了時にworktreeを残すか削除するかを選べます。「クリーンアップを忘れてworktreeが溜まり続ける」問題は、このライフサイクル管理で解消されました。 スキル設計の工夫 このスキルは、worktreeの作成を担当するスキルと、環境セットアップを担当するスキルの2つに分離しています。 作成スキルはworktreeの作成とコンテキスト切り替えを担当します。セットアップスキルは作成されたworktreeに環境ファイルをコピーする処理を担当します。 なぜ分けたのか。理由は、プロジェクトごとにセットアップ要件が異なるからです。 あるプロジェクトでは .env と .env.local だけコピーすれば十分かもしれません。別のプロジェクトではSSL証明書が必要で、さらに別のプロジェクトではデータベースのマイグレーションまで走らせたいかもしれません。 セットアップスキルはプロジェクトローカルでオーバーライドできる設計にしました。 プロジェクトのルートにセットアップ用のシェルスクリプトを置けば、プラグインのデフォルトスクリプトの代わりにそちらが実行されます。 # プロジェクトに固有のセットアップスクリプトがあればそちらを使う .claude/skills/setup-worktree/setup-worktree.sh ← プロジェクト固有（優先） # なければプラグインのデフォルトを使う ~/.claude/plugins/.../setup-worktree.sh ← デフォルト worktreeの作成ロジック自体はプロジェクトによって変わらないので、作成スキル側は共通のまま維持しています。変わる部分と変わらない部分を分離したことで、各プロジェクトは自分に必要なセットアップだけをカスタマイズできるようになりました。 他のスキルとの連携 このスキルが本領を発揮するのは、他のスキルと組み合わせたときです。 社内ではGitHubからIssueを読み取り、実装してPull requestを作成するエージェントを使っています。このエージェントは内部で今回紹介したgit-worktreeスキルを呼び出して、Issue単位でworktreeを作成します。 GitHub Issueを取得 git-worktreeスキルでworktreeを作成 ← ここで活用 Issueの内容に基づいて実装 Pull requestを作成 worktreeをクリーンアップ 複数のIssueを並列で処理する場合、Issue1つにつきworktreeが1つ作られます。それぞれが独立したディレクトリで動くので、コンフリクトを気にせず並列実行できます。 git-worktreeスキルを単体で作っておいたことで、エージェントは「worktreeの作り方」を知らなくても並列開発が実現できています。もしworktreeの作成手順が変わっても、git-worktreeスキルだけを修正すれば済み、エージェント側に手を入れる必要がありません。 スキルの粒度を意識しておくと、こうしたエージェンティックなワークフローを組みやすくなります。1つのスキルに機能を詰め込みすぎず、再利用可能な単位に分けておくことで、他のエージェントやスキルなどから自在に組み合わせられるようになります。 「複雑さはスキルに閉じ込める」という考え方 今回の取り組みで実感したのは、ツールの複雑さは必ずしも排除しなくてよいということです。Git worktreeの操作が複雑なのは、それだけ柔軟性があるからです。問題は、その複雑さが毎回ユーザーに露出することにあります。 Claude Codeのスキルは、この課題に対する有効なアプローチです。複雑な操作手順をMarkdownファイルに記述してスキルとして登録すれば、ユーザーはスラッシュコマンド1つで呼び出せます。 スキルに閉じ込める対象は、Git worktreeに限りません。プロジェクト固有のデプロイ手順、複雑なテスト実行コマンド、環境構築の手順書など、「手順が多くて面倒だけど、やることは毎回同じ」という操作が候補になります。 ポイントは、スキルを設計するときに「変わる部分」と「変わらない部分」を見極めることです。今回でいえば、worktreeの作成ロジックは変わらない部分、セットアップ処理は変わる部分でした。変わる部分だけをオーバーライド可能にしておくと、汎用性と柔軟性を両立できます。 まとめ チーム内で「worktreeは難しい」と敬遠されていた並列開発が、Git worktreeの複雑な操作をClaude Codeスキルに閉じ込めることで、誰でも気軽に使えるものになりました。 設計面では、worktree作成と環境セットアップを分離し、プロジェクトごとにセットアップをカスタマイズできるようにしました。この分離によって、他のエージェントやスキルからも再利用しやすくなっています。 「手順が多くて面倒な操作」を見つけたら、スキルに閉じ込められないか検討してみてください。Claude Codeのスキルは、チームの開発体験を底上げする強力な手段です。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディ株式会社でエンジニアをしている山岸です。 Findy AI CareerはAI人材に特化した求人プラットフォームです。掲載する求人票は、企業の求人情報をベースにAI活用状況や方針を盛り込んで作成しています。この業務はFindyのbizメンバーが担当しており、1件あたり20分〜1時間ほどかかっていました。 ai-career.findy-code.io 今回、この求人票作成のワークフローをClaude Codeのカスタムスラッシュコマンドとして実装し、作業時間を最大1時間から約5分に短縮しました。 この記事では、Claude CodeとMCP（Model Context Protocol）を組み合わせた業務自動化の具体的な進め方と、エンジニア以外のメンバーが使えるツールに仕上げるまでの過程を紹介します。社内の定型業務をClaude Codeで自動化したい方の参考になれば幸いです。 求人票作成の業務フロー 何が課題だったのか 解決策: Claude Codeのカスタムスラッシュコマンド Notion MCPで企業情報を自動取得 プロンプト設計の工夫 試行錯誤した部分 エンジニア以外のメンバーへの展開 成果 まとめ 求人票作成の業務フロー まず、求人票がどのように作られているかを説明します。 bizメンバーが企業との商談でヒアリングした内容をもとに、Findy側でFindy AI Career向けの求人票を作成・掲載しています。具体的なフローは次のとおりです。 求人票のURL・詳細情報を取得 商談にてAI記述部分をはじめとする詳細情報をヒアリング Notionの企業情報・商談ログやFindy AI Career上に掲載している既存求人、Web上のAI関連記事を統合してClaude（Web版）でドラフト作成 Google Docにドラフトをコピペし、企業とGoogle Doc上で内容を推敲 ドラフトFIX後、マークダウンに変換して管理画面から入稿 このうちステップ3が最も工数のかかるボトルネックでした。 何が課題だったのか ステップ3の問題は大きく2つありました。 1つ目は、 参照すべき情報ソースが散らばっている ことです。求人票を作成するには、Notionに記録された商談のヒアリング情報、既存のFindy AI Career求人、企業のテックブログや登壇記事など、複数のソースを手作業で集めて統合する必要がありました。中には認証が必要なソースもあり、情報を読めていないケースも発生していました。 2つ目は、 作業が属人化していた ことです。各メンバーがそれぞれのプロンプトでClaudeに投げていたため、出力品質に個人差がありました。経験豊富なメンバーなら約20分で済む作業が、不慣れなメンバーだと1時間近くかかることもあり、品質のバラつきも課題でした。 解決策: Claude Codeのカスタムスラッシュコマンド これらの課題を解決するために、Claude Codeのカスタムスラッシュコマンドを開発しました。企業名と求人票URLを渡すだけで、必要な情報を自動収集し、求人票ドラフトを一発で生成するワークフローです。 全体の処理フローは次のようになっています。 実際にコマンドを実行すると、次のような対話形式で求人票が生成されます。 > /create-job-posting ⏺ 求人票作成を開始します。 企業名と既存求人票のURLを教えてください。 > ABC株式会社 ⏺ 既存求人票のURLまたは追加情報はありますか？ > https://ai-career.findy-code.io/companies/xxx/jobs/yyy ⏺ Notionから ABC株式会社 の情報を検索します。 ⏺ 以下のNotionページが見つかりました。どのページを使用しますか？ 1. ABC株式会社：商談 - 2025/10/09 - AI特化の求人を掲載する方針... 2. ABC株式会社：商談 - 2025/08/22 - AI人材の採用ニーズについて... 3. すべて使用する 4. 使用しない（スキップ） > 1 ⏺ 情報を取得しました。求人票ドラフトを作成します。 ⏺ Write(drafts/abc_ai-engineer_20251224.md) ⎿ Wrote 368 lines ⏺ 求人票ドラフトを作成しました。 確認が必要な項目 - 生成AI活用ラベル: 4つの選択肢から確認が必要 - AI活用に対する評価制度: 既存求人に記載なし - エンジニア・全社のAI利用割合: 具体的な数値が不明 Notion MCPで企業情報を自動取得 MCP（Model Context Protocol） は、AIアシスタントが外部のデータソースやツールと連携するための標準プロトコルです。今回はNotion MCPを使い、企業名を入力するだけで商談時のヒアリング情報を検索・取得できるようにしました。 Notionには大量のページが存在するため、カテゴリとページタイプを指定して検索範囲を絞り込んでいます。検索結果が複数ある場合は、AIに自動で選ばせず、ユーザーに選択してもらう形にすることで、誤った企業情報を参照するリスクを排除しました。 プロンプト設計の工夫 カスタムスラッシュコマンドのプロンプトには、品質を担保するためにいくつかの工夫を入れています。 まず「雰囲気で書かない」という原則です。情報ソースに記載がない項目は推測で埋めず、「確認が必要な項目」としてリストアップするようにしました。これにより、ドラフトのどこが確定情報でどこが未確認なのかが一目でわかります。 既存のFindy AI Career求人からの情報取得にも工夫があります。URLが渡された場合はAPIを呼び出して求人データをJSON形式で取得し、会社概要や技術スタック、福利厚生といった共通項目は正確にコピーされるようカラムを指定しています。これにより「手作業でコピペする」工程が不要になりました。 また、求人票の表現やトーンなど、メンバーごとに判断が分かれていた部分もプロンプトにルールとして明記しています。こうした暗黙知をコードに落とし込んだことで、誰が実行しても同じ品質の出力が得られるようになりました。 試行錯誤した部分 初期のプロンプトでは、AIが情報を補完しすぎる問題がありました。ソースに記載がない「AI活用に対する評価制度」や「エンジニアのAI利用割合」といった項目を、もっともらしく埋めてしまうことがありました。ソースの採用基準が人によって異なる場合や、確認漏れが起きてしまうリスクがあったため、「情報がない場合は【要確認】と明記する」ルールを追加しました。 Notion MCPの検索精度にも課題がありました。初期のプロンプトでは検索範囲の絞り込みが甘く、関係ないページや似たようなページをまとめて読み込んでしまうリスクがあり、検索結果の確実性を担保できていませんでした。Notion MCPの検索精度は、接続先のデータがどれだけ整理されているかに左右されます。今回精度高く検索できたのは、bizメンバーがNotionのデータベースをカテゴリやページタイプで整備してくれていたからです。この運用のおかげで、カテゴリを絞り込んだ上で企業名でフィルタリングする方法が取れました。 エンジニア以外のメンバーへの展開 bizメンバーがClaude Codeを使うのは初めてだったため、Homebrewのインストールから始まるセットアップガイドをREADMEに用意しました。ターミナルの開き方、gitの初期設定、APIの認証設定、Personal Access Tokenの作成手順まで、スクリーンショット付きで解説しています。 実際にbizメンバーに操作してもらうお披露目会も開催しました。その場で「Notionの検索でヒットしない企業がある」「既存求人から流用したい項目がコピーされていない」といったフィードバックをいただき、Notion MCPの検索範囲やFindy APIからのデータ取得を改善していきました。 成果 導入後の変化をまとめます。 指標 Before After 作業時間（1件あたり） 20分〜1時間 約5分 品質のバラつき 経験値に依存 誰でも同水準 プロンプト 個人ごとにバラバラ コマンドとして統一 情報ソースの収集 手作業で複数サイト巡回 自動取得 経験豊富なメンバーでも20分から5分へと短縮されており、並列で複数の求人票を作成できるようにもなりました。 実際に利用したbizメンバーからは「出力がそのまま使えるレベルで、手直しがほとんど要らなくなった」と好評を得ています。 さらに嬉しい変化として、エンジニアリングのバックグラウンドを全く持たないbizメンバーが、このツールの仕組みを応用して自ら新しい機能を追加するようになりました。本機能がきっかけで、現場の課題に合わせて機能を作っていくという業務の効率化が能動的に起こるようになったのです。 bizメンバーからは「単に求人票作成の業務効率だけでなく、業務全体の効率化を自ら図る基礎ができた。仕組みや考え方を教えてもらったことで、効率化ツールをエンジニア頼りにするのではなく自分でもできる範囲があると気付かされた」という声もいただいています。 まとめ 今回の取り組みを通じて感じたのは、暗黙知をプロンプトに落とし込むことの価値です。個人のスキルや経験に依存していた業務を、カスタムスラッシュコマンドとしてコード化することで、チーム全体で同じ品質を担保できるようになりました。 このプロジェクトは、bizメンバーとの会話から課題を拾い上げたことがきっかけでした。普段からbizメンバーとコミュニケーションを取り、困りごとを気軽に相談してもらえる関係を作っておくことが、こうした改善の第一歩になるのだと実感しました。 Claude Code × MCPの組み合わせは、社内の業務改善ツールとして手軽かつ強力な選択肢です。似たような課題を抱えている方の参考になれば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。データエンジニアの田頭( @tagasyksk )です。 ファインディのデータ基盤は、CTO室データソリューションチームが事業部横断で開発・運用を担っています。事業の拡大に伴ってプロダクト数が急増し、当初採用していたデータメッシュのアーキテクチャでは管理コストの増大やサイロ化といった課題が顕在化してきました。 本記事では、Google Cloudプロジェクトの統合や共通化と分権のバランス再設計など、データ基盤をプラットフォームへと進化させている途上の取り組みについてご紹介します。まだ道半ばではありますが、同様の課題に向き合っている方の参考になれば幸いです。 これまでのデータ基盤のあゆみ データメッシュの採用 責任分界点の設計 事業拡大で直面した課題 プロダクトの急増 Google Cloudプロジェクトの増殖 技術選定のサイロ化 プロジェクト間データ連携の複雑化 どう解決したか データメッシュの再解釈とプロジェクト統合 フェデレーテッド・ガバナンスの確立 dbtランタイムの共通化 Lookerによる事業部横断の指標管理 今後の展望 終わりに これまでのデータ基盤のあゆみ データメッシュの採用 ファインディのデータ基盤は、分散型のデータウェアハウスアーキテクチャであるデータメッシュを採用していました。 データメッシュは、各事業部がデータの所有権を持ち自律的にデータを管理するアーキテクチャです。ファインディでは次のような方針で運用してきました。 事業部ごとにGoogle Cloudプロジェクト及びBigQueryを分離 各事業部がそれぞれのデータを管理し、アクセス権を事業部単位で制御 事業部間のデータ共有にはBigQuery Sharingを利用 責任分界点の設計 データチームでは、レイヤーごとに責任分界点を定め、各チームが自律的にデータを活用できる体制を整えていました。データチームはソースデータの取り込みや共通のデータモデルを整備し、各事業部はその上に独自の分析用モデルを構築する形です。 データメッシュの運用については、過去に別の登壇でも発表しています。 事業拡大で直面した課題 プロダクトの急増 ファインディでは2026年に「生成AI時代の事業戦略2026」として、Findy InsightsやFindy AI+など4つの新規AI事業を同時に発表しました。 prtimes.jp これにより、当初の設計で前提としていた「プロダクト数がある程度限られている」状態が崩れ、いくつかの課題が表面化しました。 Google Cloudプロジェクトの増殖 当初の設計思想に則り、プロダクトごとにGoogle Cloudプロジェクトを分離していたため、プロダクトが増えるたびにプロジェクトも増え続ける構造になっていました。IAM、予算、リソースの管理がプロジェクトの数に比例して煩雑になり、新しいプロダクトが追加されるたびに同じようなインフラ構築作業が発生していました。 技術選定のサイロ化 データメッシュではデータに関わる技術選定も各事業部に委ねていたため、ツールや実行環境が事業部ごとにバラバラになっていました。データ変換にはdbtとDataformが混在し、BIもスプレッドシートとLooker Studioが併存、dbtの実行環境もDocker・GitHub Actions・ローカル実行と統一されていない状態でした。中央で統制しづらく、会社として共通のノウハウを蓄積しにくいことが課題になっていました。 プロジェクト間データ連携の複雑化 事業部横断でのデータ活用ニーズも増えてきました。各プロダクトのCRMに蓄積された顧客情報をBigQueryに集約した「共通企業マスタ」の構築や、MCPとAIエージェントを組み合わせたSlackからの横断検索など、プロダクトを跨いだデータ連携の取り組みが広がっています。 tech.findy.co.jp しかし、プロジェクトが分離された構成のままでは、プロダクトが増えるたびに連携先も倍々で増加し、管理が追いつかなくなることが見えていました。 どう解決したか データメッシュの再解釈とプロジェクト統合 方針転換の核となったのは、「データメッシュにおけるドメイン分離の単位をプロジェクトからデータセットに変える」という判断です。 Google Cloudプロジェクトを一つに統合し、BigQueryのデータセット単位でドメインを分離する構成に移行しました。これにより、プロジェクト管理のオーバーヘッドを大幅に削減しつつ、ドメインごとのデータの独立性は維持しています。 フェデレーテッド・ガバナンスの確立 フェデレーテッド・ガバナンスとは、全社共通で統制すべきルールと各事業部に委ねるルールを明確に分け、中央集権と分権を両立させるガバナンスモデルです。プロジェクト統合に伴い、このモデルに沿ってガバナンスの境界を整理しました。 IAM管理、Cloud DLP、BigQuery Policy Tagなどのセキュリティ・コンプライアンス領域は元々共通化していたものです。事業拡大を機に、CI検査項目、Formatter・Linter、dbtの実行環境(ランタイム)を新たに標準化しました。一方で、事業ドメイン、ビジネスイベント、データモデリングといったビジネスに近い領域は引き続き各事業部に委譲しています。 共通化すべきものと分権すべきものの線引きが明確になったことで、データチームと事業部チームの双方が迷いなく動けるようになりました。 dbtランタイムの共通化 バラバラだったdbtの実行環境をDockerに統一しました。共通のDockerイメージをArtifact Registryで管理し、各リポジトリはGitHub Reusable Workflowを通じて共通のワークフローを呼び出す形にしています。 jobs : dbt-build : uses : org/shared-workflows/.github/workflows/dbt.yml@main with : image_tag : "0.0.0" mount_path : "." dbt_args : "build --target prod" また、ローカル開発時の共通コマンドにはTaskfileのincludes機能を活用しています。各リポジトリは共通Taskfileを参照するだけで、lint、test、buildなどの操作を統一されたインターフェースで実行できます。 includes : common : taskfile : ./path/to/shared/Taskfile.yml tasks : lint : cmds : - task : common:lint test : cmds : - task : common:test 新しいプロダクトが追加された場合も、共通のワークフローとTaskfileを参照するだけでdbt環境が整うため、立ち上げのリードタイムが大きく下がりました。バージョンアップやdependabotへの対応も、事業部の数だけ必要だったものが共通イメージ1つの更新で済むようになっています。 Lookerによる事業部横断の指標管理 データ基盤のリアーキテクチャとあわせて、BIツールの見直しも行いました。これまで事業部ごとにスプレッドシートやLooker Studioで管理していた指標を、Lookerに集約しています。 Lookerのセマンティックレイヤーを活用することで、全社で共通のビジネスロジックを定義し、指標の一貫性を担保できるようになりました。一方で、指標の定義そのものは各事業部に委譲しています。実際に、全体のダッシュボードの68%がデータエンジニア以外のメンバーによって作成されており、中央に寄せつつも現場のデータ活用はむしろ活発になっています。Looker導入の詳細については次の記事で紹介しています。 tech.findy.co.jp 今後の展望 プラットフォーム化の取り組みはまだ道半ばです。今後は次の2つの方向で進化を続けていきます。 1つ目は、セルフサービスかつAI Readyなデータ基盤です。事業部のメンバーやAIが自らデータを探索・分析できる仕組みをさらに拡充し、データチームへの依存を減らしていきたいと考えています。 2つ目は、メタデータの整備です。今後事業やプロダクトが増えても低コストでデータを探し利用できるようにし、事業や組織間のシナジーをデータで生み出していくことがチームのミッションとして求められています。 終わりに 本記事では、データメッシュからプラットフォームへとデータ基盤を進化させた取り組みについて紹介しました。 事業の成長フェーズによって、最適なアーキテクチャは変わります。ファインディでは、データメッシュの考え方自体を捨てたわけではなく、「プロジェクト分離」から「データセット分離」へとドメイン境界の粒度を見直すことで、スケーラビリティと自律性のバランスを取り直しました。 データ基盤は一度作って終わりではなく、事業の成長に合わせて進化し続けるものです。今回紹介したリアーキテクチャもまだ道半ばで、セルフサービス化やメタデータ整備など取り組むべきテーマは山積みです。この記事が、同様の課題に向き合っている方の参考になれば嬉しいです。 ファインディではこのデータ基盤を一緒に育てていくメンバーを募集しています。少しでも興味が湧いた方はカジュアル面談お待ちしております！ herp.careers

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 ファインディではClaude CodeのSkillやカスタムコマンドなどをPlugins経由で社内展開しています。Pluginsに関しては前回の記事を参照してください。 tech.findy.co.jp AIに設計やタスク分解、コード生成を任せる分、Pull requestのコード品質やコードレビューがネックになることがあります。「型チェックが抜けてる」「命名がチームの規約と違う」といった指摘で手戻りが発生すると、AIで加速した開発のテンポが崩れてしまうからです。 本記事では、その課題に対処するために社内Pluginsに作ったセルフレビュースキルを紹介します。過去のレビューコメントから自動生成するチェックリスト、複数のAIエージェントによる並列レビュー、修正の段階的な適用を組み合わせて、Pull requestを出す前のセルフレビューを自動化しています。 Pull requestの質と、コードレビューをめぐる課題 セルフレビュースキルの概要 エージェント並列レビューの設計 規約・スタックベースのチェック チェックリスト照合 コード品質チェック Codex AI コード簡潔化 要件確認 レビュー結果の統合と出力 修正の段階的な適用 まとめ Pull requestの質と、コードレビューをめぐる課題 AIが設計やコード生成を行うようになり、1日に作成できるPull requestの数は増えました。しかし一方で、Pull requestの質やコードレビューで問題が出てきました。 AIが出力したコードがチームのコーディング規約に沿っていなかったり、型チェックが抜けていたり、テストコードが不十分だったりすると、コードレビューで指摘されて手戻りが発生します。AIで加速した開発のテンポが崩れてしまうのです。 そしてこれら全てを人間のコードレビューで事前に防ぐのは、現実的に難しくなってきています。 AIが生成するコードの量とPull requestの数が増えており、これら全てを人間がチェックしようとすると、人間がボトルネックとなるのです。 そこでファインディでは、 人間がチェックしないといけない領域と、AIにチェックを任せる領域を切り分けた うえで、 AIにチェックを任せる領域を自動化する ことにしました。それが今回紹介するセルフレビューのスキルです。 セルフレビュースキルの概要 セルフレビュースキルは社内展開しているClaude Codeのスキルの一つで、Pull requestを出す前にコード変更をセルフレビューするためのものです。「セルフレビューして」と話しかけるだけで起動します。 # カレントブランチ全体をレビュー セルフレビューして # 特定ファイルに絞る src/services/UserService.ts をセルフレビューして # コミット範囲を指定 HEAD~3..HEAD の変更をレビューして 起動すると、リポジトリ全体の過去指摘パターン・バグ検出・セキュリティ・コード品質・実装漏れといった 異なる視点を持つ複数のエージェントが同時に動き出します。 それぞれが独立してdiffを解析し、 全エージェントの完了後に結果をサマリとして統合します。 指摘事項は出典エージェント付きで一覧化され、「すべて反映」「個別に選択して反映」「反映しない」の3択でコードに適用できます。 エージェント並列レビューの設計 現在は最大6つのエージェントを並列起動します。各エージェントはレビュー対象のdiff（ git diff DEFAULT_BRANCH...HEAD の結果）を受け取り、それぞれ異なる観点で独立して動作します。 全エージェントの完了を待ってから結果を統合するため、直列実行と比べて待ち時間を大きく削減できます。 規約・スタックベースのチェック プロジェクトの命名規則への準拠、テストコードの適切さ（テスト漏れ・カバレッジ・テスト規約への準拠）、ドキュメントとの整合性に注力して確認を行います。 CLAUDE.mdやrulesなど、プロジェクトの規約やスタックに関するドキュメントを学習したエージェントが、diffの内容と照らし合わせて規約違反やスタックの不適切な使用を指摘します。 チェックリスト照合 事前に用意しているセルフレビューのチェックリストの各項目とdiffを照合します。チェックリストの項目は該当リポジトリの過去のPull requestで指摘された内容から生成されているため、「やりがちなミス」にピンポイントで反応します。 チェックリストの自動生成の仕組みについては、次の記事で詳しく紹介しています。 tech.findy.co.jp このチェックリストは定期的に自動で更新されるように仕組み化しており、常に最新の指摘パターンをカバーできるようになっています。 コード品質チェック Claude Code公式プラグインの feature-dev:code-reviewer エージェントが動きます。 github.com バグ・セキュリティ・コード品質の3観点で検査し、 信頼度80以上の指摘のみを報告 する設計になっています。「これは問題かもしれない」程度の低確信度の指摘は出力されないため、レビュー結果がノイズで埋まりません。 具体的には次のような問題を検出します。 ロジックエラー（条件分岐の誤り、状態管理の不整合） セキュリティ問題（SQLインジェクション、認証チェックの欠落、機密情報のハードコード） コード品質（デッドコード、過剰な複雑度、テストの網羅性） Codex AI OpenAI Codex CLIの codex review コマンドにdiffを渡してレビューを実行します。 developers.openai.com プロンプトは次の優先順位で構成されており、スタイルやフォーマットの指摘は明示的に除外しています。 【最優先】バグ検出 - ロジックエラー、エッジケースの見落とし、例外処理の漏れ - null/undefined処理の欠落、境界値チェックの不足 【第2優先】セキュリティ問題 - SQLインジェクション、XSS、CSRF - 認証・認可の欠陥、機密情報の露出 【第3優先】パフォーマンス問題 - 非効率なアルゴリズム、メモリリーク、不要なループ 【除外】コードスタイルやフォーマットの指摘 Codex CLIが未インストールの場合は起動時に確認を求め、承諾されれば npm install -g @openai/codex を自動実行します。認証（ChatGPTアカウントへのログイン）も同様に案内します。 ファインディでは基本的にClaude Codeでコード生成を行っており、Codexはレビューの観点を増やすための補完的な役割で使っています。コード生成したモデルとは別のモデルの観点でのレビューを挟むのをオススメします。 コード簡潔化 Claude Codeのビルトインスキル /simplify を呼び出します。 /simplify はコード変更を対象に「コード再利用」「コード品質」「効率性」の3観点でレビューエージェントを並列実行し、結果を統合して報告します。既存ユーティリティとの重複検出、冗長な状態管理、不要な処理・並列化漏れ・メモリリークなどが検出対象です。 code.claude.com 要件確認 現在のPull requestのタイトルとBody、紐づくIssueの内容から要件を抽出し、実装コードとテストコードの両方に反映されているかを2軸で分析します。 要件は「機能要件」「非機能要件」「エッジケース」の3種類に分類したうえで、実装ギャップ（要件があるのに実装がない）とテストギャップ（実装はあるのにテストがない）を区別して報告します。 ## ギャップ分析レポート ### ✅ 実装・テスト両方あり - ユーザー認証: 実装: UserService.ts:42 / テスト: user_service_spec.rb:15 ### ⚠️ 実装済み・テストなし → テストが必要です - パスワードリセット: 実装は PasswordService.ts にあるが、テストがない 理由: 異常系（トークン期限切れ）の挙動が未検証 ### 🚨 実装なし・テストなし → 実装漏れの可能性があります - メール通知: Issueに「登録完了メールを送信する」とあるが、実装が見当たらない レビュー結果の統合と出力 全エージェントの完了を待ち、結果を統合して表示します。 各レビュー用エージェントからの報告のサマリを出力して、コードの品質を全体的に把握できるようにします。 ## セルフレビュー結果 ### 📋 チェックリスト照合 #### ✅ 問題なし - nullチェック: OK #### ⚠️ 改善提案 - 関数名の命名規則: getUserById → fetchUserById に統一するとよい #### ❌ 要修正 - エラーハンドリング: 外部API呼び出しにtry-catchがない --- ### 🔍 コード品質チェック #### ❌ 要修正 - L42: 認証トークンのnullチェックが欠落 修正案: `if (!token) throw new UnauthorizedError()` --- ### 🤖 Codex AI #### ⚠️ 改善提案 - L78: N+1クエリの可能性。ループ内でDBアクセスが発生している --- ### 📊 レビューサマリー - チェックリスト照合: ✅ 3個 / ⚠️ 1個 / ❌ 1個 - コード品質チェック: ✅ 0個 / ⚠️ 0個 / ❌ 1個 - Codex AI: ✅ 0個 / ⚠️ 1個 / ❌ 0個 - 要件確認: ✅ 2個 / ⚠️ 1個（テストギャップ） - 合計指摘事項: 4個 修正の段階的な適用 レビュー結果が揃ったら、 AskUserQuestion で3択を提示します。 ? 修正を反映しますか？ > 個別に選択して反映する (Recommended) すべて反映する 反映しない Other… 「個別に選択して反映する」 では、指摘事項を一件ずつ確認しながら採否を判断できます。「この修正を適用しますか？（出典: コード品質チェック）」のように出典が表示されます。 ## 未対応リスト（インラインコメント用） ### 1 - path: src/services/UserService.ts - line: 42 - source: code-reviewer - body: **[出典: コード品質チェック]** 認証トークンのnullチェックが欠落しています **修正案**: ` if (!token) throw new UnauthorizedError() ` < sub > *AIセルフレビュー* </ sub > 「すべて反映する」 を選ぶと、レビュー用エージェントそれぞれからの修正提案をEditツールで順次適用します。 「反映しない」 を選ぶと、レビュー結果の確認だけで終了します。内容を把握してから自分で修正したい場合に使います。 まとめ AIが開発ワークフローに入れば入るほど、生成されるコードやPull requestの数は増えていきますが、それら 全てに人間が対応するのは現実的に難しくなってきています。 人間が対応する必要のある領域と、AIに任せる領域を切り分けたうえで、 AIに任せる領域を自動化することが重要 になります。 全ての変更内容を同じレベルでレビューしない ようにすることがAIレビューの設計のコツです。 軽微なリファクタリングと、データベースからの項目削除は、同じレベルでレビューする必要はありません。前者はコード品質の観点で簡単にAIに任せてしまい、後者は人間がしっかりレビューする、といった具合に、 変更内容の性質に応じて適切なレビューのレベルを設計するのがポイントです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。Findy Tech Blog編集長の高橋（ @Taka_bow ）です。 前編では、Gene Kim氏の26年にわたるDevOps研究の旅路、DORA研究によるハイパフォーマーの実態、DevOps Enterprise Summitの多彩な事例、そしてスティーブン・スピアー博士との共著『Wiring the Winning Organization』から導かれた"勝つ組織の魔法"のフレームワークとカウチのメタファーを紹介しました。 後編では、この魔法を解き放つ3つのテクニック ── 巧遅（前倒し）化（Slowification） 、 単純化（Simplification） 、 増幅（Amplification） ── を具体的な事例とともに紹介します。そして最後に、Gene Kim氏自身が体験した生成AIとバイブコーディングの世界をお届けします。 前編はこちら tech.findy.co.jp 講演動画 日本語訳全文（続き） ソシオテクニカルの達人 巧遅（前倒し）化（Slowification） Netflix と Chaos Monkey ── 本番環境での巧遅化 単純化（Simplification） Amazon ── モノリスからサービス分割へ 増幅（Amplification） ウェストラム博士の組織文化モデル 情報理論で文化を診断する トヨタ工場でのシグナル増幅 生成AIから得た教訓 バイブコーディングの価値と注意点 まとめ 今年も開催します！（名前変わります） We're Hiring 講演動画 conference.findy-code.io ※ 視聴にはFindy Conferenceへのログイン、並びに視聴登録が必要です。ご登録頂ければ、他の講演アーカイブも視聴できます。 日本語訳全文（続き） ソシオテクニカルの達人 このすばらしいシステムはどこから来たのでしょう？ 昨年、フォースグレン博士も言及していたロン・ウェストラム博士です。 彼の詳しい話はあとにしますが、彼には"ソシオテクニカルの達人"という言葉を教わりました。 5つの特徴を持つ人たちです。 高エネルギーで高基準。 システム思考なので大規模作業で活躍しますが、小規模作業でも活躍し、質の高い質問ができます。 フロアを歩くのが好きで、自分の仕事が終わると積極的に現場を見て回ります。 このまま、ソシオテクニカルの達人がどんな行動をするかお話ししますね。 巧遅（前倒し）化（Slowification） 1つ目 ── ソシオテクニカルの達人は"巧遅（前倒し）化"します。最も危険度の高い作業は本番環境では行わず、前段階で問題を解決します。 『Wiring the Winning Organization』では24の事例を紹介しており、うち20％はテクノロジー関連です。 しかし驚くべきことに、最もケーススタディが多いのは医療業界でした。 救急部門は非常に危険な場所として知られています。 事故に遭って運び込まれた時、症状が増えて帰ることになる確率は、スカイダイビングやベースジャンプでケガする確率よりも高いのです。 ベースジャンプはビルや崖、ダムなどから飛び降りるスポーツです。病院はベースジャンプよりも危険です。 Ms.モリス 対 Ms.モリソンというケーススタディがあります。 間違った患者が処置を受けてしまった事例で、14もの強力なシグナルが出ていたにも関わらず手術は行われました。 患者自身も"違う"と訴えていたそうです。 明らかに制御不能な状態に陥っている兆候が見られるような時には、システムを停止させるのが正解だと示す事例です。 Netflix と Chaos Monkey ── 本番環境での巧遅化 私たちの業界における巧遅（前倒し）化の最も良い事例は、2011年4月に起こったAmazon EC2の大規模障害でしょう。 具体的にはAWSで最も規模が大きいUS-Eastの可用性ゾーンがダウンしました。顧客数も最大だったので大手顧客もすべてダウンしたのですが、非常に興味深いことにNetflixは例外でした。 NetflixはAmazonのクラウドサービスの利用を公言している大規模ユーザーですが、どうやって危機を乗り越えたのでしょう？ その答えは後日明らかになりました。 彼らは3つの驚くべき内容を明かしました。 "単一障害点は排除せねばならず、Amazonはその最たる存在だ"。 "障害を乗り越えるためには、常に障害を起さなければならない"。 そう言って"Chaos Monkey"の存在を明らかにしました。 ご存じの方も多いでしょうが、このChaos Monkeyはランダムに障害を起こします。クラウド上の仮想マシンに対して、日中にです。 Netflixの開発者でシステムを構築し実行する人間なら、いつでもシステムがダウンし得ると知っているので、障害時に回復力のあるシステムを作ります。 だからAmazonの障害も彼らにとっては日常にすぎなかったのです。 さらに驚くべきことに、Netflixはいくつもの障害を乗り越えてきました。 2014年にはAmazonの大規模リブートがありました。パッチを当てるために全体の5％のサーバーを再起動する必要があったのです。 ぜひスライドをご覧ください。NetflixのChristos Kalantzis氏が言っていたことです。"緊急リブートのニュースを聞いた時、影響を受けるノード数のリストを確認してぞっとしました。特にデータベース周りです"。ただ彼はこうも言いました。"でもChaos Monkeyのおかげで、かかってこい！です"。 結果はどうだったか。Bruce Wong氏が言ったように、2700以上ある本番データベースのノード中、218のノードがリブートされ、そのうち22は正常にリブートされませんでした。 でもNetflixの顧客にダウンタイムは発生しませんでした。 これこそが巧遅化の賜物です。本当に耐障害性と可用性を重視するなら、私たちは恐れずに本番環境で自分たちを試すべきなのです。 技術的な負債を解消することや、"何かが変"と誰かが言った時には耳を傾けることも含まれます。 巧遅（前倒し）化の事例紹介でした。 単純化（Simplification） 2つ目に移ります。次は"単純化"です。 単純化とはつまり、問題を分割することです。大きな問題を小さくし、安全に解決しやすい問題にするのです。方法はいくつもあります。一気に行うことも、段階的に行うこともできます。私のお気に入りの1つはモジュール方式です。 DevOps研究という観点から最も成果が期待できるのは、アーキテクチャでした。何によって測定できるでしょう？ どの程度まで、誰の許可もなしにシステムを大幅に変更できるのか。チーム外の人間と細かい調整を行うことなく、どの程度まで仕事を進められるか。どの程度まで、他のサービスとは関係なくデプロイとリリースができるか。不足しがちな統合テスト環境を使うことなく、必要なテストを任意のタイミングでどこまで実行できるか。 私たちは社内の多くの人間とカップリングされていますが、これらの条件を満たせれば、営業時間内のデプロイも可能で、ダウンタイムも最小限に抑えられます。 Amazon ── モノリスからサービス分割へ 実際に私が気に入っている事例の1つが、2000年代初頭のAmazonの話です。 米国では多くの人が昔のAmazonを覚えています。90年代後半はAmazonで本を注文しました。本と音楽を売っているシンプルなサイトでした。 しかし2002年になる頃には、製品カテゴリが35種類も増えていました。これによりチーム間のコミュニケーションと調整の量が増えました。 AmazonのCTOであるワーナー・ヴォゲルス博士が2004年にある発言をしています。 デジタルチームが直面していた不可解な仕様に関してです。 その仕様とは、音楽やビデオや電子書籍などデジタル製品を購入する際にも配送先住所の入力が必要というものでした。 配送する物など何もないにも関わらず必須だったのです。 デジタルチームは製品カテゴリーごとにあった80もの受注担当チームの元を訪れて変更のお願いをしました。でも彼らの答えはいつも"予算がない"でした。 そんなわけでデジタルチームはやるべきことを達成できぬまま、行き詰ってしまったのです。 理由は、当時のAmazonのソフトウェアアーキテクチャがモノリスで、3500人のエンジニアが全員、1つのカウチを一緒に運んでいるような状態だったからです。 補足 モノリス（monolith）とは、すべての機能が1つの大きなコードベースに統合されたソフトウェアアーキテクチャのことです。 デプロイ件数からも見てとれます。1999年には年間で多数のデプロイが行われていたのが、2001年にはほぼ停止状態となっていました。 年間にわずか数十件で、多くのデプロイが未完に終わりました。 スティーブ・イエギ氏が書いた有名なメモがあります。 Amazonの元CEOで創設者ジェフ・ベゾス氏の有名なお達しに言及した内容で、"チーム間のコミュニケーションはAPIのみで行い、例外は許されない"、"従わない者は解雇する"とまで書かれたものでした。 最後の"良い一日を"はイエギ氏の追加したジョークだそうです。 "ベゾスはスタッフの一日がどうでも気にしない"とね。 それ以外は実際の内容で、 元陸軍レンジャーで当時CIOだったリック・ダルゼル氏が強行しました。 補足 リック・ダルゼル氏はこんな感じの方です。（動画） www.youtube.com 10億ドル規模のプロジェクトでしたが効果も絶大でした。1つのサービスを10に分割し、10から100、さらには1000にまで分割しました。 すると年間数十件だったデプロイ数は、2011年には1日あたり1万5000件、2015年には1日あたり13万6000件にまで増えました。 さて、なぜでしょう？ 彼らはカウチを細かく分割することで、行動に独立性を与えました。おかげでチーム外とのコミュニケーションや調整を行わずに、開発、テスト、デプロイができるようになったのです。 ケント・ベック氏はよく、疎結合を理解するのに30年かかったと話しています。 Gene Kim氏の講演を聞きながら熱心にメモをとるKent Beck氏 私もまったく同じです。疎結合がなぜそれほど重要なのか理解するのに30年かかりました。 補足 疎結合（decoupling）とは、コンポーネント間の依存度を低くし、それぞれが独立して変更・デプロイできるようにするソフトウェアアーキテクチャの設計原則です。前編で紹介した密結合（coupling）の対義語にあたります。 増幅（Amplification） それでは最後のテクニックを簡単に紹介したいと思います。 最初に話した巧遅（前倒し）化は本番前の段階で問題を解決するという話でした。単純化は問題を分割して小さくする話でした。3つ目は弱いシグナルを増幅する話です。大きな問題になってしまう前に、大きな問題と同様に対処するためです。 ウェストラム博士の組織文化モデル 先程のロン・ウェストラム博士。 彼が研究していたのは、医療、航空宇宙、原子炉分野の安全性に関してです。 その中であることに気づきました。安全性は組織文化と相関性が高いということです。 安全性が最低レベルの組織に見られたのは、これらの特徴です。情報を隠ぺいし、悪いニュースのメッセンジャーを攻撃します。 チーム間の橋渡しは行わず、失敗も隠ぺい、新しいアイデアは潰します。良くありませんよね。 真ん中は彼が"官僚的"と呼ぶグループで、人を守るためにプロセスを作ります。わりと良さそうです。 でも最高の組織では、これらの特徴を見いだせます。情報を積極的に求め、メッセンジャーは悪いニュースを伝えるように訓練され、リーダーはそれを聞くように訓練されます。 大野耐一氏が言うように、"問題がないことが最大の問題"なのです。 補足 大野耐一氏はトヨタ自動車の元副社長で、トヨタ生産方式の生みの親とされる人物です。英語では "Having no problems is the biggest problem of all." として広く知られています。 トヨタ生産方式 作者: 大野 耐一 ダイヤモンド社 Amazon Toyota Production System : Beyond Large-Scale Production Amazon 責任が共有されているのでチーム間の橋渡しも推奨されます。アップタイムと可用性はOpsだけの仕事ではありません。情報セキュリティがそうであるように、それは皆の仕事なのです。そして障害が起きてしまったら、とことん調べます。 情報理論で文化を診断する ロン・ウェストラム博士は言いました ── "文化は時に問題となり得る"。なぜなら彼の言葉で言うと、文化は軽くて空気のようなもので、つまり目には見えにくく、実体がないものだからです。 スピアー博士と私が挑戦したことの1つは、ウェストラム博士が明確化しようとした内容と同じでしたが、私たちは情報理論を使いました。ウェストラム博士が言っていたことをすべて表現できると思います。 情報はまず生成されなければならず、それが送信され、確実に受信され、対応がなされてから問題が解決したか確認します。助けを求めてきた人に、問題は解決したかと尋ねるのです。 そして ── 私がこれを好きな理由はエンジニアとして診断できるからです。 つまり、文化の問題なのか？ 情報生成に問題があったのか？ そもそも知ってたのか？ それとも送信段階の問題？ 悪いニュースのメッセンジャーは攻撃されるので送りたくないですからね。 それとも受信側の問題？ リーダーに届いていない？ あるいは対応が見送られた？ つまり優先順位の問題？ それとも最後の確認漏れ？ 問題が解決したか確かめていない？ トヨタ工場でのシグナル増幅 スティーブン・スピアー博士の本はすべて読みました。トヨタ生産方式の研究論文も含めてね。ただ『Wiring the Winning Organization』の"増幅"の章で、彼は非常にすばらしい事例の1つを挙げていました。 進行中のトヨタ生産方式に基づいた事例です。 彼がトヨタ自動車の製造工場を直接訪問した時の話でした。 テキサス州サンアントニオにある、トラックやSUVを製造している工場です。トヨタの社員とティア1サプライヤーの人間、合わせて数千人の従業員がいたそうです。 シグナル増幅のスピードの速さを示す事例です。 工場には3000〜4000ものアンドンのコードがあり、それを引くとリーダーの助けが必要な問題発生を意味します。 しかし最も注目すべきことの1つは、米国トヨタのSVPであるKevin Voelkel氏が毎日数時間は現場にいるということです。 補足 Kevin Voelkel氏は、トヨタ・モーター・マニュファクチャリング・テキサスの SVP（シニア・バイスプレジデント） です。 リーダーが現場を実際に見ることの大切さを示すエピソードです。 従業員の仕事ぶりを確かめることで、部下の目標達成のために自分に何ができるかが見えてきます。 私がこの話をした理由は皆さんがリーダーだからです。 現場で従業員の業務を妨げている障害に気づいてあげるために、どうすれば現場の実態を把握できるか考えてみてください。 生成AIから得た教訓 話を締めくくる前に、昨年生成AIを使ってみて私が学んだことをお話ししたいと思います。 正直、これまでのキャリアを通してこんなに楽しかったことはありません。 昨日、ケント・ベックも最高に楽しいと言っていましたね。とにかく目新しくて新鮮で、コーディングの喜びを私の日常にもたらしてくれました。 先程、スティーブ・イエギ氏が書いたこちらのメモをご紹介しました。 私は彼の仕事ぶりの大ファンで、長年彼の話を引用し続けています。AmazonとGoogleで20年過ごしてきた彼と、昨年やっと会えました。 "駆け出しエンジニアの死"と題した講演をカンファレンスで行い、AI登場の影響について話していました。 駆け出しエンジニアは消える運命か？ 答えはノーです。これまで以上に開発者は増えるでしょう。 実際に開発作業にAIを使ってみて、新たな楽しい冒険が始まりました。スティーブとは一緒に本を書き始めました。『バイブコーディングブック』という今秋に出版予定の本です。 補足 原題 "Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond" 2025/10/21 に発売されました。 Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond 作者: Kim, Gene , Yegge, Steve It Revolution Press Amazon 私はあることに驚嘆しました。なんとスティーブは、調子が良い日には、1日あたり7000〜1万2000行におよぶコードを35年間取り組んできたゲームのために書き続けていたのです。 彼は作業を進めるために何百ドルもClaudeに費やしていました。 ここで疑問が湧くと思います。 スティーブのような人だけがそうやって ── 多くタイピングすれば良いわけではないので、数字で比べたくはないのですが ── スティーブ・イエギのように100万行以上のコードを書いてきた実績がないとダメでしょうか？ それとも私のような平凡な開発者でもAIの恩恵を受けられるでしょうか？ 驚いたことに答えはイエスでした。 本を書いていた頃、その最後の80時間で ── 気づけば私は4000行のコードを書いていました。原稿の締切直前で怒涛の編集作業を行っていたさなかにです。 スライドの上の部分は、その4日間の間に本の作業に費やした時間を示しています。 その下はコーディングをした時間です。 本の執筆にAIを役立てるためにバイブコーディングでツールを作っていました。 当時の私は、実は手と手首を痛めてしまっており、4つのGoogleドキュメント間でコピペするだけの作業さえ苦痛でした。 そこで思ったのです。本の原稿をSQLデータベースのようにして、クエリを送ることで目次や文章の一部を取り出したり、章や節ごとに取り出したりして、AIで書き換えられるようにしたいと。 スティーブ・イエギのレベルでなくても、平均的な開発者でも、平均以下の開発者でも、バイブコーディングの恩恵は受けることができます。 バイブコーディングの価値と注意点 そして本の中では ── バイブコーディングの価値を挙げ、英語の頭文字から"FAAFO"と呼んでいます。 より速く欲しいものを作ることができ、より高い目標に挑戦することができ、自分一人で構築できるようになります。他人に頼る必要も、他者と調整する必要もありません。普通ならなかなか難しいことですよね。だけど何より、作業がはるかに楽しくなります。ケント・ベックは数十年ぶりに午前3時にコーディングをしたそうですよ。 何かを作る作業というのは非常に楽しいものですが、それがより手軽で楽しいものになる上、私たちの選択肢も大幅に広がります。 ありがたいことに、つい最近あるAIラボの開発生産性ディレクターとお話しする機会を得ました。 彼は自分たちが抱える問題について教えてくれました。 "社内の開発者の多くは日々の業務にAIを使っていない"、"なぜか皆、手書きが好き"なのだとか。 つまり、 AIの開発を行う企業の中でさえ、リーダーが部下に便利なツールの使用を促している状態なのです。 私たちの多くがこれから直面する課題だと思います。 AIという魔法の技術を活用して仕事をうまくこなすことを勧めていくことになるでしょう。 ただ、バイブコーディングは新たなリスクに満ちています。 本でも、自分たちが実際に経験した失敗について書きました。 単体テストを無効にして、コードが消えました。 理解できない謎のコードベースを作成してしまい、変更できなくなりました。 良いコードベースを台なしにしたこともあり、多くの注意と警戒が必要です。 しかし良いニュースもあり、 AIによって私たちの強みと弱みは増幅されるでしょう。 だから単独作業を可能にするモジュラー型アーキテクチャの存在がこれまで以上に必要になるはずです。 フィードバックループはより速さが求められ、学ぶ文化も必要です。 この本の初期の草稿を読んだ人の多くはこんな反応でした。 "2人はものすごく賢いはずだ"、 "たくさん本を書いて優れた開発者の働き方を研究してきたのに、なぜこんなにも愚かな失敗を？"。 でも例えばですが、これまでずっと馬で移動する人生だったとします。 馬にしか乗ったことがなく、最高時速は約5マイル（約8キロ）程度。 その感覚では時速約50マイル（約80キロ）に耐えられません。訓練を重ね、自分をアップデートしなければ車は大破するでしょう。 そこで本ではバイブコーディングの流れを表すループや、内部、中間、外部の開発に役立つ実践項目も紹介しています。 AI活用のメリットが開発者の皆さんに伝われば幸いです。AIを使えばより楽しく、より大規模な開発を行えますし、開発スピードも上がり、所属する組織にもメリットがあります。 本の発売は今年の秋の予定です。（※発売されました） まとめ それでは話をまとめます。 成功する組織は"魔法"の力で並外れたパフォーマンスを実現します。個人の力ではどんな人でもおよびません。 組織内の問題解決能力や想像力が完全に解放された状態なのです。 逆に魔法がない組織では、創造力も問題解決能力も発揮できないまま全員が終わる運命でしょう。 この魔法を解き放つには3つの方法があります。 "巧遅化、単純化、増幅"の3つでした。 ソシオテクニカルの達人になればそれが実現できます。 高エネルギーで高基準、大規模でも小規模でも活躍し、現場歩きが大好きな人です。 補足 『Wiring the Winning Organization』邦訳では、Slowificationを「巧遅化」、Simplificationを「単純化」、Amplificationを「増幅化」（本記事では「増幅」と表記）と訳しています。 9月にはまた別のカンファレンスを開催します。テクノロジーリーダーが開発チームや企業のためにどうAIを活用しているかなどの話が聞けます。 ぜひそちらにもお越しください。各講演へのリンクや本の抜粋など、本日紹介した内容の詳細に興味がある方は、スライド送信用のアドレスにメールを送ってください。 件名に"Vibe"または"DevOps"とあれば、数分以内に自動返信が届きます。 本日はありがとうございました。 （会場拍手） 前編・後編を通して、Gene Kim氏の26年にわたるDevOps研究の集大成をお届けしました。DORA研究のデータに裏打ちされたハイパフォーマーの実態、製造業からソフトウェアまで共通する「勝つ組織の原則」、そして生成AIがもたらす新たな可能性 ── 皆さんの組織でも、この"魔法"を実践してみてはいかがでしょうか。 Ask the Speaker も盛り上がりました ファインディブースにも来てくださいました 前編はこちら tech.findy.co.jp 今年も開催します！（名前変わります） 『継続的デリバリーのソフトウェア工学』著者 Dave Farley氏と和田卓人氏の登壇が決定！ スポンサー募集中です。（残り僅か！） prtimes.jp We're Hiring ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。Findy Tech Blog編集長の高橋（ @Taka_bow ）です。 本記事は、2025年7月にファインディが開催した「 開発生産性Conference 」のキーノートスピーカーとしてお招きした Gene Kim氏 の基調講演を、日本語の全文書き起こしとしてお届けするものです。 Gene Kim氏は、ベストセラー『The DevOps 逆転だ！（The Phoenix Project）』『The DevOps ハンドブック（The DevOps Handbook）』の著者であり、1999年から26年にわたり高い成果を上げるテクノロジー組織の研究を続けてきた人物です。 本講演では、DORA研究の成果、勝つ組織に共通する普遍的な原則、そして生成AIがもたらす変革について語られました。 前編では、DORA研究によるハイパフォーマーの実態、DevOps Enterprise Summitで出会った多様な事例、そしてスティーブン・スピアー博士との共著『Wiring the Winning Organization』から導かれた"勝つ組織の魔法"のフレームワークを紹介します。 後編では、その魔法を解き放つ3つのテクニック（巧遅化・単純化・増幅）と、生成AI・バイブコーディングの実践について紹介します。 後編はこちら tech.findy.co.jp 講演動画 日本語訳全文 オープニング ─ 26年間の研究とDevOpsへの道 DevOpsのビジネス価値は我々の想定よりさらに高い DevOps Enterprise Summit ─ あらゆる業界での実践事例 過去4年間で得た教訓 魔法の側面① ── 必要なものが手に入る 魔法の側面② ── 弱いシグナルが検知される 魔法の側面③ ── 計画と実践に十分な時間がある 3つのレイヤー ── 作業の構造を理解する カウチのメタファー ── DevOpsの本質 今年も開催します！（名前変わります） We're Hiring 講演動画 conference.findy-code.io ※ 視聴にはFindy Conferenceへのログイン、並びに視聴登録が必要です。ご登録頂ければ、他の講演アーカイブも視聴できます。 日本語訳全文 オープニング ─ 26年間の研究とDevOpsへの道 Gene Kim氏： ありがとうございます。 （会場拍手） 私は高業績のテクノロジー組織について1999年から研究しています。創業者兼CTOとしてTripwireという情報セキュリティの会社に勤めていた頃からです。 私が研究対象としてきた高業績の組織は、開発プロジェクトの納期内でのパフォーマンスが申し分なく、運用の信頼性・安定性、セキュリティ・法令遵守体制も万全でした。知りたいのは、彼らがどうやって見事な変革を成し遂げたか、どうすれば他の組織が追随できるかということです。 ご想像の通り、この26年の間に多くの驚きがありました。最大の驚きは、私がDevOpsムーブメントのど真ん中に引き込まれたことで、これは極めて緊急かつ重要な動きだと考えています。 DevOpsは多くの産業に変革をもたらしましたが、それ以前で最後に目にした大変革は、恐らく1980年代にトヨタがアメリカ市場に進出した時だと思います。 彼らは見事に、ほぼすべての米自動車メーカーを完全に打ち負かしたわけですが、根底にはリーンの原則がありました。DevOpsの土台にもなっている原則です。 テクノロジーのバリューストリームに適用すると創発的なパターンが出現し、1日に数十件、数百件、さらには数十万件のデプロイが可能になり、世界水準の信頼性・セキュリティ・安定性も維持したままです。 10〜15年前には考えられなかったことです。少なくとも当時の私は、無理だと思っていました。しかし、今では多くの組織が実現しています。 今日は、私がこの26年で学んだ大事なことをいくつか紹介しようと思います。 私の著書をご覧になった方もいると思います。『The DevOps 逆転だ！』や『The DevOps ハンドブック』などですね。 翻訳本を監修してくれた榊原彰さんに昨夜会えたんです。 11年越しの願いがやっとかないました。 補足 The DevOps　逆転だ！究極の継続的デリバリー 作者: ジーン キム , ケビン ベア , ジョージ スパッフォード 日経BP Amazon The DevOps ハンドブック 理論・原則・実践のすべて 作者: ジーン・キム , ジェズ・ハンブル , パトリック・ボア , ジョン・ウィリス 日経BP Amazon 『The DevOps 逆転だ！』（原題：The Phoenix Project）および『The DevOps ハンドブック』（原題：The DevOps Handbook）は、いずれも榊原彰氏（パナソニックコネクトCTO：写真右）が監修、長尾高弘氏が翻訳を担当しています。 11年越しの初顔合わせ さて、昨年こちらのイベントでニコール・フォースグレン博士が登壇しました。 彼女とは6年以上、研究を共にしてきた仲です。内容は、ハイパフォーマンスとはどんな状態か ── それがDevOps研究の現状です。 今日は皆さんに4つのことをお話しします。 1つはニコール・フォースグレン博士と行った研究についてで、ハイパフォーマンスの実態とそれを予測する行動とは何かという話です。 次に、スティーブン・スピアー博士とこの4年で学んだことを紹介します。トヨタ生産方式を長年にわたり研究してきた人物です。 共著『Wiring the Winning Organization』の内容をベースに、DevOpsについて話します。既にご存じの内容もあるでしょう。ただ、何が驚きかというと、トヨタの現場管理者ならすぐに理解・共感できる内容です。 それから、昨日すばらしい講演をしたケント・ベック氏のように、私も生成AIを使ったバイブコーディングに取り組んでおり、非常に楽しく過ごしています。昨年学んだことを共有したいと思います。 DevOpsのビジネス価値は我々の想定よりさらに高い 先ほど、ニコール・フォースグレン博士とジェズ・ハンブルと進めた研究についてお話ししました。ジェズは『継続的デリバリー』の著者で、私達は『The DevOps ハンドブック』を共著しました。 私たちは2013年から2019年まで、6年間の間に3万6000人を対象に調査を行い、高業績な組織はどのような状態で存在するのか、ハイパフォーマンスの実態を調べました。結果は6回とも同様 ── ハイパフォーマンスな組織は存在し、そうでない他者をはるかにしのぐということでした。 その判断基準とは？ 私たちが発見したのは、ハイパフォーマーは1日に複数回デプロイしているということです。他者と比べて、頻度が2桁多いのです。もっと重要なのは、デプロイにかかる時間の短さです。バージョン管理システムでコードをコミットしてから、統合してテストしてデプロイするまでの時間 ── つまり顧客に届くまでです。 1時間以内であることが分かりました。リードタイムの違いが2桁なのです。 しかも作業が速いだけでなく、結果も伴っています。彼らがデプロイを行う時に失敗する確率はどの程度なのでしょうか。業務に支障が出る重大度1（SEV1）のインシデントの発生率は？ その可能性は7分の1なのです。 そしていざ何かが起きた時は ── 失敗は必ず起こるものだと言いますからね ── 1時間以内に解決できるのです。これは他者と比べて3桁も短い障害復旧時間になります。 スティーブン・スピアー博士がトヨタ方式を研究していた時、トヨタは生産性が4倍だと分かりました。床面積とサイクル時間は半分にも関わらず、生産物は2倍なのです。ここではそれが4倍どころか、100倍、1000倍なのです。ケント・ベック氏も言っていましたが、ソフトウェアのすばらしいところです。 品質についても多角的に見てきました。ハイパフォーマーは情報セキュリティの目標を日々の業務に取り入れているため、セキュリティ問題の修正に費やす時間は半分でした。 2014年に私たちは別のことに目を向け始めました。これらのハイパフォーマーは技術的に優れていただけでなく、あらゆる指標で数値が高かったのです。 収益性や市場シェア、生産性の目標を上回る可能性は2倍でした。組織が政府機関や軍などといった非営利団体であっても同じことが言えて、組織とミッションの目標を達成する可能性が2倍でした。顧客満足度や量と質の目標においても同様です。 これらはあることを示唆しています。価値の提供やミッションの達成にも、テクノロジーのバリューストリームと同じ作業が必要なら、DevOpsの原則やパターンはその目標達成に役立ちます。 もう1つの興味深い指標は、このような業績の高い組織では、従業員が勤務先をいい職場として同僚や友人に薦める確率が2倍でした。 "従業員ネットプロモータースコア（eNPS）"という ── 収益性や収益成長率と深い相関関係にある指標です。 ですから、デプロイができない組織やしづらい組織だと、友人に自分の職場を薦めたいとは思わないということでしょう。 DevOps Enterprise Summit ─ あらゆる業界での実践事例 数字を超えて、これが示唆するのは、 私たちはいかに安全かつ迅速に、高い信頼性を持って確実に、サービスの提供対象の目標、夢、願望を達成するかが大事 なのです。 この11年間 ── "DevOps Enterprise Summit"というカンファレンスを運営してきました。カンファレンスの目的は、大規模で複雑な組織が、FacebookやAmazon、GoogleやMicrosoftと同じように勝利をつかむためのパターンを示すことでした。 補足 DevOps Enterprise Summitは現在、Enterprise Technology Leadership Summitに名称変更されています。 数多くのテクノロジーリーダーたちに、どうやってDevOpsを使って市場で勝ってきたかを共有してもらいました。私のお気に入りを一部紹介します。 こちらの男性はMike Carr氏で、ヴァンガード社のCTOです。 ヴァンガードは投資信託を普及させた会社で、9兆5000億ドルの資産を運用しています。1万人以上いる技術者の開発生産性を向上させることによって、先程私がお話しした指標をすべて達成しています。 それによって投資家に価値を ── 投資家というのはつまり、彼らの投資信託を買う人たちですね ── 彼らに価値を還元しています。 お次は世界有数の製薬企業ファイザーのJamie Hook氏です。 彼らの開発生産性の向上は、ある協力関係がきっかけでした。エンジニアリングのVPであるMike Lamb氏と、CISOだったBrian Cincera氏によるものです。 目的は生産性だけでなく、安全性も高めることでした。紹介してくれた開発者の支援方法が驚きで、研究開発、販売、マーケティング、流通など所属する組織に関わらず、重要な社会的目標を達成する支援を行っていました。 補足 Brian Cincera氏は2024年にファイザーを離れています。 皆さんはこう思っているでしょうか ── "よくある話だ"。 では、海軍大佐の例はどうでしょう？ 現在は准将ですが、当時は大佐でした。彼はイージスミサイル防衛システムの責任者だったのですが、海上にいる船のソフトウェアをアップグレードする必要がありました。なのに8年も待つしかなく困っていました。 ソフトウェアをアップグレードするには、鋼鉄の穴や隔壁を切り開き、コンピューターを運び出す必要があったためです。 ですが今ではDevOpsパターンにより、海上にいる船を2隻同時にアップグレードできます。 紅海にいる船も含めてです。1970年代に造られた船でこれが実践できたのですから、ほぼどこでもできるはずです。 こちらは米国トヨタのKishore Jonnalagedda氏です。彼は工場の現場にDevOpsのパイプラインを構築し、工場の業務だけでなく、セールス、マーケティング、ポストセールスサービスなどの業務の何百ものアプリケーションを効率化しました。DevOpsの有効性を示しています。 彼いわく、トヨタウェイのおかげで改善の文化が築きやすかったそうです。もちろんトヨタでは"カイゼン"の概念が根づいており、ITの人たちも日々の業務を改善しやすい環境ではあります。 私が一番気に入った事例は、こちらかもしれません。シーメンスのThomas Jachmann氏のケースです。 彼はCTスキャナーのソフトウェアの責任者です。CTスキャナーは病院の画像診断部門に6000台も納入されています。 彼が解決したかった問題は、現場でソフトウェアをアップグレードする認証を得るには6ヵ月という長い期間を要することでした。 そこで彼はテスト自動化への投資を始めました。自動テストであれば、好きなタイミングで認証の段階へと進められます。 認証にはまだ数ヵ月かかりますが、認証が下りるかどうかは技術の問題ではありません。ただ、頻繁なアップグレードの土台はできます。 これが重要だと思う理由は、CTスキャナーで撮る際の出力電力というのはソフトウェアで制御されているからです。 安全性に関わり、重要です。 "うちではDevOpsは無理"と言う友人や同僚がいたら、"どこでもDevOpsは可能"と思い直してほしいのです。 困難でも成功した事例はたくさんありますからね。 過去4年間で得た教訓 スティーブン・スピアー博士と仕事でご一緒したことは先程お話ししました。彼との出会いは約10年前にさかのぼります。MITスローン経営大学院のワークショップに参加した時でした。 有名な方ですが、その理由の1つは1990年代の彼の研究で、彼はトヨタ生産方式を深く掘り下げた第二世代の研究者グループの一員でした。 彼らのような人たちのおかげで、アンドン、カイゼン、現場ウォークなどは海外でも通用する言葉となり、トヨタの手法を学ぶ際に役立っています。 補足 「アンドン」はトヨタ生産方式における異常の見える化のための仕組みです。 トヨタ自動車公式サイト に詳細があります。 1999年に彼は、最も広くダウンロードされたハーバード・ビジネス・レビューの記事を執筆しました。 タイトルは「トヨタ生産方式の"遺伝子"を探る」です。 補足 原題 "Decoding the DNA of the Toyota Production System" の邦訳は https://dhbr.diamond.jp/articles/-/3743 に掲載されています。 私はこちらを2001年に読み、そのすばらしさに驚嘆しました。 彼はこう述べていました ── "3000〜5000人の人間がトヨタの工場で働いているとしたら、その全員が科学者集団の一員で、絶えず検証と改善に努めている"。 よく覚えている言葉です。10年後に彼と仕事をできる日が来るとは、当時は思いもしませんでした。 彼とどんなことに取り組んだかと言うと、『Wiring the Winning Organization』という本を書きました。 補足 Wiring the Winning Organization　成功する組織を導く3つのメカニズム 作者: ジーン・キム , スティーブン・J・スピアー 日本能率協会マネジメントセンター Amazon 邦訳『Wiring the Winning Organization　成功する組織を導く3つのメカニズム』（日本能率協会マネジメントセンター） 私たちの目的は ── まずは驚きますよね。なぜスティーブン・スピアー博士と私なのかと。 彼はハードウェアと製造業、私はソフトウェアの出身。 一見、話が合わなさそうです。ですが、私たちが読んできた本や論文を見ると、かなり重なっており、私たちは疑問を持ちました。 次のものの共通点は？ ── アジャイル、DevOps、トヨタ生産方式、リーン生産方式、安全文化。 そして私たちが導き出した結論は、いずれもより大きな全体の不完全な表現であり、3つのメカニズムがそれらを結びつけているのです。 この点を明確にするために、勝つ組織が持つ"魔法"の3つの側面をシェアしたいと思います。 魔法の側面① ── 必要なものが手に入る まず1つ目の側面というのは、誰もが常に重要な問題に取り組んでいます。 平行して行っているのが理想です。必要な時に、必要なものが手に入るからそれが可能なのです。適切な形式とタイミングで、適切な関係者から手に入るのです。例えばどんなものかと言うと、情報や承認、要件や決定権、テスト結果、生産ログなどがそうです。 その重要性を理解するには、魔法がない状態を想像します。つまり、誰もが行き詰っている状態です。必要なものが適切な形式とタイミングで手に入らないのが原因で、皆に尋ねて探し回るしかありません。だから小さな取り組みでも英雄的な努力を要するのです。 これがどれだけ重要なことかを提唱するために（ダメな例として）、「The Checkbox Project」という論考を友人たちと書きました。著書『The DevOps 逆転だ！』に近いものです。 補足 「The Checkbox Project」は、2023年にIT Revolutionが主催したDevOps Enterprise Forum（3日間のリトリート形式）での議論をもとに生まれたガイダンスペーパーです。 本稿のベースとなったのは、実際の出来事です。ある大企業で「サービスにシンプルなオプトイン用チェックボックスを追加する」という一見単純なタスクが、構想から完成まで12ヶ月かかり、コストが2,800万ドル超に膨れ上がりました。この実例をケーススタディとして、組織の「配線の仕方」がいかにパフォーマンスを左右するかを解説しています。 著者はApple・John Deere・Scaled Agileなど多様な組織のリーダー6名（Kamran Kazempour、Chris Hill、Steve Pereira、Dean Leffingwell、Amy Willard、Gene Kim）による共同執筆で、2023年9月26日にFall 2023 DevOps Enterprise Journalの一部として公開されました。 The Checkbox Project 入手先 https://itrevolution.com/product/the-checkbox-project/ この話のプロジェクトの目標は、1つのチェックボックスを表示することです。 何百万もの顧客に表示され、それにチェックを入れると、顧客は月額5ドルのサービス契約を結ぶことになります。 問題はそれが4つの顧客チャンネルにまたがり、20のチームによる作業が必要な点です。CEOレベルのサポートを必要とし、連日行われる作戦会議には12ヵ月で2800万ドルかかると見積もられています。さらなる問題は、プロジェクトが成功すると思っている人が20％しかいないという点です。 なぜなら過去2回は失敗したからです。 チェックボックスの表示は技術的に難しいことではありません。実際に大変なのは、調整やコミュニケーション、優先順位づけやスケジューリング、政治工作や説得、エスカレーションなどです。誰も必要なものが得られないとこうなります。これが魔法の1つ目の側面です。 魔法の側面② ── 弱いシグナルが検知される 次に2つ目を紹介します。 至る所で活発なフィードバックループが機能し、些細な失敗シグナルでも検知され、増幅されます。そうすれば迅速な対応でミスを防いだり、修正したりできます。このフィードバックを通して人々は学び、上達し続けられます。ただ、それはフィードバックが適切な人に、適切かつ実行可能な形式で届いた場合に限ります。 再び重要性の確認のため、魔法がない事態を想像します。フィードバックループが弱いか、遅いか、存在すらしない状態です。あるいは間違った人に届く状態です。 それだと失敗が検出されないので、時間の経過とともに拡大してしまいます。小さな問題が雪だるまのように膨らむのです。 シグナルは生成されるものの、システムで抑制されてしまうか、消されるケースもあり得ます。 悪いニュースを伝えると嫌な目に遭うような組織だと、それを恐れてこういうことが起こります。良くありませんよね。これが魔法の2つ目の側面です。 魔法の側面③ ── 計画と実践に十分な時間がある そして最後の3つ目です。 計画、実践、実験、改善のための十分な時間が確保された状態です。 最も危険かつ重要な事態は、稼働してからではなく、リスクが低い計画と実践の段階で起こるのが理想的です。そうすればやり直しが容易なだけでなく、安全に失敗し、学び、改善することもできます。 そうやって教訓を得ていくことで、より良い仕事につながります。 ここで再びこの重要性を理解すべく、最も重要な作業をすべて本番稼働後に行うしかない事態を想像します。 元に戻すことも、やり直すこともできず、小さなミスが大きな失敗を引き起こします。学べるような状況でもありません。 スピードアップのために一度ペースダウンする時間も、『ノコギリの刃を研ぐ』ために手を止める時間もありません。 明らかにそれは良くない状態で、11年前に発売した『The DevOps 逆転だ！』でも語られている話です。 補足 「ノコギリの刃を研ぐ（Sharpen the Saw）」はスティーブン・R・コヴィーの『7つの習慣』における第7の習慣。生産性を高めるために、あえて手を止めて自分自身を磨く時間を取ることの重要性を説いています。 3つのレイヤー ── 作業の構造を理解する さて、この3つの側面に名前をつけて説明しますが、先にもう1つお伝えしておきます。 これは最初にスピアー博士が類型化した内容で、私は重要だと思っていませんでした。ですが徐々に重要性が分かってきて、世界の見え方まで変わりました。 私たちが提唱するのは、作業には3つのレイヤーがあるということです。 レイヤー1 は目の前の作業対象です。たとえば患者だったり、取り組んでいるコードだったり、本番環境で動くバイナリだったりします。 レイヤー2 は私たちが使うツールや技術です。たとえばMRI装置、CTスキャナー、X線装置、IDEなどです。Kubernetesプラットフォームもですね。 しかし製造業やソフトウェアで鍵を握るのは レイヤー3 で、社員やチームを編成する役割がある管理システムです。ここで誰と誰が話すかが決まります。その頻度や内容、形式についてもここで決まるのです。 製造業の組織における非常に有名な事例をスピアー博士から教わりました。レイヤー1とレイヤー2は何も変えなかった事例です。 北カリフォルニアのフリーモントに非常に有名な製造工場があります。 ゼネラルモーターズの工場だった頃は、北米どころか世界トップクラスの業績の悪い自動車工場でした。 GMとトヨタの合弁会社の拠点となり、2年も経たないうちに日本の工場レベルの業績をたたき出しました。人も床面積も設備も、何一つ変えていません。 レイヤー1とレイヤー2は変化なしで、唯一変わったのがレイヤー3でした。 私たちの業界では、ソフトウェアアーキテクチャに当たります。リーダーが定める部分です。 一度にたくさんの仕事をするのか、小さく分けて仕事をするのか？ フィードバックのスピードは？ レイヤー3は非常に重要だとお伝えしておきます。 補足 この工場はNUMMI（New United Motor Manufacturing, Inc.）として知られ、1984年にGMとトヨタの合弁事業として設立されました。同じ労働者、同じ設備でありながら、トヨタ生産方式の導入により劇的に業績が改善した事例として、経営学の教科書にも登場する有名な事例です。 カウチのメタファー ── DevOpsの本質 製造業でもソフトウェアでも、良いシステムを作るには3つの方法があります。 魔法の3つの側面が目指すのは、弱いシグナルを増幅できるかどうか、スピードアップのためにシステムをスローダウンできるか、そしてシステムを分割することで簡素化できるかです。 小難しく聞こえますよね。スティーブン・スピアー博士との研究で、最も鮮明に感じた話をここでご紹介します。 2人でカウチを動かす話です。スティーブとジーンです。 スティーブとジーンが行っているのは、ただの肉体労働で、頭は使わないと思うかもしれません。 しかし、2人で解決しなければならない問題が実はいくつも隠れています。 例えば、カウチの重心はどこか。狭い出入り口を通るにはどう回るべきか。狭いくねった階段を通るには誰が先に行くべきか。体は向き合うべきか、などです。 ただ、コンサルタントもフォーカスグループもここでは必要ありません。 試行錯誤と素早いフィードバック、そして何よりコミュニケーションと調整により、2人は確実に目標を達成するでしょう。 しかしリーダーの力で、彼らの仕事はもっと難しいものにできます。 1つは電気を消すことです。 作業にかかる時間が増え、危険度が増し、カウチや部屋、自分の体を傷つける可能性があります。 他にも様々な方法で変化を加えることができます。 大きなサイレンや大音量の音楽といった雑音を流してみたり、 スティーブとジーンが直接会話できないよう仲介人を送り込んだりもできます。 すると突然、スティーブとジーンがカウチの移動に失敗する姿が想像できます。 なぜなら、問題を解決するのに必要なはずの情報が手の届く範囲にないからです。 要するに、これこそがDevOpsの本質です。 2000年代にデプロイが非常に複雑になり、開発と運用がJiraチケットや要件定義書、プロジェクトマネージャーを介してしかコミュニケーションできなくなると、突然、目標達成に必要な帯域幅が不足してしまうのです。 開発と運用に限らず、技術とビジネスの間、研究開発とマーケと営業など、あらゆるチーム間でです。 スティーブとジーンのカウチ移動は、共同作業における問題解決のメタファーで、彼らのチームとしての成果に焦点を当てています。 リーダー次第で、彼らの仕事は簡単にも困難にもなります。 このカウチは2つのコンセプトを表していると思っています。 1つ目は コヒーレンス（Coherence） です。 スティーブンとジーンはどこまで一体として機能できるでしょうか？ 直接話すことができない状況では、もはやチームではなく、ただのカウチを個々に支える2人です。 2つ目は 密結合（coupling） です。 2人でカウチを動かす作業は、2人が2つの椅子を別々に動かすのとは違います。 椅子が2つなら、コミュニケーションや調整は不要です。狭い出入り口を同時に通る時は別ですよ。 私たちが取り組むことの多くは、他のチームと連携して行います。例えば、大規模なカンファレンスの場で何かのプランニングに参加するとします。 何千人もの人が集まってコンテキストを共有し、方向性を決めるのはすてきなことですが、日常業務では行いたくありません。 何千人もの人間が連絡を取り続けて調整するなんて無理です。 代わりに必要なのが、カウチの分割です。 常に連絡と調整に追われることなく、独立して仕事ができるようにするためです。 後編に続きます 後編では、このすばらしいシステムを構築する3つのテクニック ── 巧遅（前倒し）化（Slowification） 、 単純化（Simplification） 、 増幅（Amplification） ── について、具体的な事例とともに紹介します。さらに、Gene Kim氏自身が体験した生成AIとバイブコーディングの世界についてもお話しします。 後編はこちら tech.findy.co.jp 今年も開催します！（名前変わります） 『継続的デリバリーのソフトウェア工学』著者 Dave Farley氏と和田 卓人氏の登壇が決定！ スポンサー募集中です。（残り僅か！） prtimes.jp We're Hiring ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers