キャリアプロダクト開発部の森 ＠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

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 ファインディでは要件定義から設計・タスク分解・Issue生成までをAIに任せるカスタムコマンドを開発しています。 tech.findy.co.jp 今回は、そのコマンドで生成したIssueをAIエージェントに渡したときに、どう並列実装まで自動化しているかを紹介します。Git worktreeとClaude CodeのAgent Teamsを組み合わせることで、依存関係を考慮しながら複数のIssueを並列にPR作成まで進められます。 Git worktreeとは 依存関係グラフで実行レイヤーを決定する Claude CodeのAgent Teams機能 Team LeadとWorkerの役割分担 IssueごとのWorktreeで並行実装を実現する merge-gateによるレイヤー間の同期 Workerの実装フロー まとめ Git worktreeとは Git worktreeは、1つのGitリポジトリを複数のディレクトリで同時にチェックアウトできる機能です。 通常のブランチ切り替えと異なり、メインの作業ディレクトリはそのままに、別のディレクトリで別のブランチを並行して操作できます。 # worktreeの作成 git worktree add .worktrees/feature/add-auth -b feature/add-auth main # worktreeの一覧表示 git worktree list # worktreeの削除 git worktree remove .worktrees/feature/add-auth エージェントごとに独立した作業ディレクトリを持てる点が、並列実装との相性が良い理由です。あるエージェントの変更が別のエージェントの作業ディレクトリに影響しません。 依存関係グラフで実行レイヤーを決定する この仕組みを使うには、GitHubのIssueが次の構造になっている必要があります。 親Issue にGitHubのSub-issue機能でSub-issueが紐づいていること Sub-issue間の依存関係 がGitHubのIssue依存関係機能（blocked_by）で設定されていること docs.github.com 具体的には次のような構造です。 #200 ユーザー認証機能の実装（親Issue） ├── #201 テーブル作成 │ ├── #202 サービス実装 │ │ └── #204 APIエンドポイント │ └── #203 テンプレート実装 └── #205 ドキュメント更新 並列実装で最初に解決しなければならない問題は「どのIssueを先に実装するか」です。Sub-issue間に依存関係がある場合、順序を間違えると後続の実装が破綻します。例えばテーブルが存在しない状態でサービス層を実装しようとしても、マイグレーションが走っていないためテストが通らず、PRを作るところまで辿り着けません。人間が実装するときも依存関係の順序は意識しますが、複数のエージェントが並列で動く場合は「誰がどの順番でどれを実装するか」を明示的に制御する仕組みが必要になります。 この依存関係をもとに、並列実行できるIssueのグループ（レイヤー）を計算します。 Layer 0 : 依存なし → 全て並列実行可能 Layer N : Layer N-1 以前のIssueにのみ依存 → Layer N-1 完了後に並列実行 例えば5つのSub-issueがある場合、次のような実行計画になります。 依存関係グラフ: #201 テーブル作成 ─┬→ #202 サービス実装 ─┬→ #204 APIエンドポイント └→ #203 テンプレート ─┘ #205 ドキュメント更新（独立） Layer 0（並列実行）: #201, #205 Layer 1（並列実行）: #202, #203 ← Layer 0 完了後 Layer 2: #204 ← Layer 1 完了後 この実行計画をユーザーに提示し、確認を得てから実装を開始します。循環依存が検出された場合はエラーを報告して中止します。 Claude CodeのAgent Teams機能 この仕組みはClaude CodeのAgent Teams機能を基盤として構築しています。 code.claude.com Agent Teamsは、複数のClaudeセッションがチームとして協調して動作するための機能です。Team Leadがタスクを作成して各Workerに割り当て、WorkerはSendMessageでTeam Leadに進捗を報告しながら並列で作業を進めます。なお、執筆時点では実験的な機能のため、利用するには設定での有効化が必要です。 Team LeadとWorkerの役割分担 実行はTeam LeadとWorkerというエージェントの役割分担で行います。 Team Lead : 依存関係グラフの構築、タスクの作成と事前割り当て、Workerの起動・停止、レイヤー間の同期（merge-gate）を担当する。コードは実装しない Worker : 割り当てられたIssueのworktreeを作成し、実装・セルフレビュー・PR作成まで一貫して行う Team Leadはオーケストレーターに徹し、Workerのworktreeに対してコマンドを実行したり、コードを直接編集したりしません。Workerからの報告を受動的に待つだけです。 IssueごとのWorktreeで並行実装を実現する 各WorkerはアサインされたIssueごとにworktreeを作成し、独立したディレクトリで実装を進めます。worktreeはリポジトリ内の .worktrees/exec-issues-{親Issue番号}/issue-{Issue番号}/ 以下に配置され、作業が完了したら削除されます。 git worktree add ".worktrees/exec-issues-200/issue-201" -b "issue-201/テーブル作成" main 複数のWorkerが同時に動いていても、それぞれが独立したworktreeを持つため互いの作業が干渉しません。あるWorkerがファイルを編集しても別のWorkerの作業ディレクトリには影響がなく、並行実装が安全に行えます。 tmuxやiTerm2を使っている場合、Workerの起動と同時にペインが追加されます。並行実装中のWorkerがそれぞれ別ペインで動いている様子をリアルタイムで確認できるため、全体の進行状況を把握しやすくなっています。 同一レイヤー内の並行IssueがどのファイルをPATCHするかは事前にわかりません。そのため、Workerのタスク情報に「同一レイヤーで並行実装中のIssue一覧」を含め、ファイル競合リスクをWorkerが意識できるようにしています。 merge-gateによるレイヤー間の同期 レイヤー間の依存関係を守るために、merge-gateという仕組みを新たに追加しました。 Layer 0のWorkerが全員PRを作成し終えたら、Team LeadはLayer 1のWorkerを起動する前にmerge-gateを処理します。merge-gateでは、Layer 0で作成された全PRのマージ状態をチェックし、未マージのPRをユーザーに通知して待機します。 全PRがマージされたことを確認してからdefaultブランチを最新に更新し、Layer 1のWorkerを起動します。この仕組みにより、後続レイヤーのWorkerは常に最新の状態をベースに実装を始められます。 タスクの依存関係で表現すると次のような構造です。 [impl] #201 ─┐ ├→ [merge-gate] Layer 0 ─┐ [impl] #205 ─┘ ├→ [impl] #202 └→ [impl] #203 merge-gateタスクはTeam Lead専用で、Workerはclaimしません。 Workerの実装フロー 各Workerは割り当てられたタスクを順番に処理します。 タスク詳細（Issue番号・タイトル・親Issueの文脈）を読み取る worktreeを作成して環境をセットアップする （PLAN_APPROVALが有効な場合）実装計画をTeam Leadに送信して承認を得る Issueの内容に従って実装する セルフレビューを実施し、修正提案をTeam Leadに送って承認後に適用する PRを作成してTeam Leadに結果を報告する worktreeを削除してクリーンアップする 全タスクを処理し終えたらTeam Leadに完了を報告して終了します。 まとめ 今回紹介した仕組みのポイントは次の3点です。 Sub-issue間の依存関係をもとにレイヤー分けし、同一レイヤーのIssueを並列実行する merge-gateでレイヤー間のPRマージを確認してからdefaultブランチを更新し、後続レイヤーに進む IssueごとにWorkerとworktreeを対応させることで、並行実装の干渉を防ぐ Sub-issueに依存関係を設定した親Issueを用意して指示するだけで、実装の順序管理からPR作成まで自動で進みます。複数の施策を同時に走らせることへの心理的なハードルが下がり、並行して進められる開発の幅が広がりました。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディでデータエンジニアをやっている 開（hiracky16） です。 ファインディでは事業の成長に伴い、スプレッドシートで管理していたKPIダッシュボードの複雑さが限界を迎えつつありました。この記事ではLookerを導入し、 derived_table→mart→dim/fact と段階的にデータモデリングを進化させてきた過程を紹介します。ファインディが大切にしているバリューの一つであるスピードを損なわずにガバナンスを整えていくノウハウとして、参考になれば幸いです。 ファインディにおけるKPIダッシュボードの重要性と複雑性 Looker導入の背景 段階的なデータモデリングの最適化 derived_tableからの出発 martレイヤーの導入 dim/factモデルへの移行 移行時のガードレール整備 データアナリストの自律化と利用状況の変化 まとめ ファインディにおけるKPIダッシュボードの重要性と複雑性 ファインディは主に4つの事業と8つのサービスを展開しています。事業ごとに追うべきKPIが異なるため、事業部内のメンバーはもちろん、複数チームや事業を横断して見る部長や役員にとっても、各事業の健康状態を把握できるダッシュボードの必要性が以前と比べて増しています。事業によって売上が発生するまでの経路やリードタイムが異なり、ユーザーや企業を独自のセグメントで切り分けて分析する必要もあります。こうした複雑さは事業が成長するごとに増していきます。 たとえばファインディの祖業である転職事業では、職種・経験年数・アクセス頻度などといった属性値をもとに多軸で分析を行っています。さらに、転職に至るまでにはスカウト・応募・面談といった複数のファネルが並行して進むため、単純な線形のファネル分析では実態を捉えきれない難しさがあります。 Looker導入の背景 こうした重要性や複雑性を踏まえつつ、既存のスプレッドシートとBigQuery構成でKPIを管理する方法にはいくつかの課題が生じていました。 まず、事業やチームごとにスプレッドシートが増え続け、それぞれが独自フォーマットで作られているため、チームを横断した利用ができない状態でした。期が変わるたびに指標が追加されていくと、今期追うべき指標の整理も難しくなります。さらに、スプレッドシートごとにセグメントの切り方や集計ロジックが異なり、同じ指標のはずなのに数値が一致しないといった問題も起きていました。加えて、データ量の増加に伴いスプレッドシートの表示速度が低下し、売上管理の集計結果表示で障害が発生するなど、安定性の面でも限界が見え始めていました。 こうした課題を解決するために、LookMLで指標定義をコード管理しGitHubでレビューできるLookerを導入しました。BigQueryとネイティブに連携できるためデータ量が増えても表示速度が安定すること、チーム内にLookerの経験者がいて立ち上げコストを抑えられること、そしてGoogleの担当の方による丁寧なPoCで運用イメージが具体化できたことが導入の決め手になりました。 段階的なデータモデリングの最適化 導入後、まずは主要なKPIがLookerに集まっている状態を目指しました。ただし、利用者がBIツールに求めているのはいち早く事業数値を確認することであり、指標の定義を統一したいというデータチーム側の課題意識とは温度差があります。スプレッドシートからの移行でスピード感を落とさないことを重視しつつ、段階的にデータモデリングを進化させていきました。 全体の流れを図にすると次のようになります。 derived_tableからの出発 最初のステップとして採用したのが、LookMLの derived_table です。 derived_table はSQLベースでビューを定義できるため、BigQueryのSQLに慣れ親しんだメンバーにとってはダッシュボードやLook構築までのリードタイムが最も短い方法でした。ファインディではデータ変換にDataform（プロジェクトによってはdbt）を使っていますが、LookMLとは別リポジトリで管理する必要があり、両方を行き来すると開発速度が落ちてしまいます。その点 derived_table であればLookMLリポジトリだけで完結するため、スプレッドシートからの移行初期にはこの手軽さが大きな武器になりました。 一方で、 derived_table はExploreが実行されるたびにBigQueryへクエリが走るため、データ量が増えるにつれて表示速度が遅くなり、クエリコストもかさむという課題が見えてきました。 たとえばDAU（Daily Active User）を集計するビューは次のようなイメージです。 view: daily_active_user { derived_table: { sql: WITH calendar AS ( ... ), page_view AS ( ... ), users AS ( ... ) SELECT calendar.report_date, users.user_job_segment, users.user_id FROM calendar LEFT OUTER JOIN page_view ON ... LEFT OUTER JOIN users ON ... ;;} dimension_group: report { ... } dimension: user_job_segment { ... } measure: dau { ... } } explore: daily_active_user {} martレイヤーの導入 derived_table の課題を解消するため、SQLのロジックをDataformへ移行し、事前に計算済みのmartテーブルとしてBigQuery上に実体化しました。LookML側は derived_table のSQL定義を削除し、 sql_table_name でmartテーブルを参照する形に書き換えます。Exploreからは計算済みのテーブルを読むだけになるため、表示速度とクエリコストの両方が改善されます。 先ほどのDAUの例をmartに移行すると、LookML側は次のようにシンプルになります。 view: daily_active_user { sql_table_name: `project.mart.daily_active_user` ;; dimension_group: report { ... } dimension: user_job_segment { ... } measure: dau { ... } } explore: daily_active_user {} derived_table のSQL定義がなくなり、 sql_table_name でmartテーブルを参照するだけになっています。ただし、martテーブルはスケジュール実行で更新するため、データの鮮度には注意が必要です。先ほどのDAUの例であれば日次の集計で十分なので、Dataformのスケジュール実行で一日一回テーブルを更新しています。 dim/factモデルへの移行 martテーブルが複数できあがってきたタイミングで、ディメンショナルモデリングへ進みます。ここで重要なのは、すでに動いているレポートが複数ある状態でモデリングを行うことです。実際のレポートから共通する軸を抽出できるため、机上の設計よりも実態に即したモデルを組み立てられます。 たとえば、先ほどのDAUレポートに加えて、コンバージョンを日次で追うレポートも職種セグメント別に組み立てられているとします。この場合、 user_job_segment は複数のレポートで共通して使われる適合ディメンション（Conformed Dimension）になります。日付軸も同様です。 こうした共通軸を整理していくと、ユーザーディメンション・カレンダーディメンション・ページビューファクトという形に分解できます。ディメンションとファクトに分けたことで、新しいレポートを追加する際も既存のディメンションを再利用でき、定義のばらつきを防げるようになりました。 分解後のLookMLは次のようになります。 # カレンダーディメンション view: dim_calendar { sql_table_name: `project.dim.calendar` ;; dimension_group: report { ... } } # ユーザーディメンション view: dim_user { sql_table_name: `project.dim.users` ;; # サロゲートキーを作成 dimension: user_key { ... } dimension: user_job_segment { ... } } # ページビューファクト view: fct_page_view { sql_table_name: `project.fct.fct_page_views` ;; dimension: user_key { ... } dimension: user_id { ... } dimension: access_date { ... } measure: dau { ... } } # コンバージョンファクト view: fct_conversion { sql_table_name: `project.fct.fct_conversions` ;; dimension: user_key { ... } dimension: conversion_date { ... } measure: conversions { ... } } # Explore でディメンションとファクトを結合 explore: fct_page_view { label: "ページビュー分析" join: dim_calendar { ... } join: dim_user { ... } } explore: fct_conversion { label: "コンバージョン分析" join: dim_calendar { ... } join: dim_user { ... } } fct_conversion のExploreでも dim_calendar と dim_user をそのまま再利用しています。ファクトテーブルが増えてもディメンションを使い回せるため、定義の重複が起きません。 移行時のガードレール整備 dim/factモデルへの移行ではBigQueryのテーブル構造とLookMLの両方に修正が入るため、意図せずダッシュボードが壊れるリスクがあります。ファインディではDataform上でのmartテーブルとdim/factテーブルの整合性テスト、LookerのCIによるLookMLバリデーション、そしてLooker APIを使ったExplore実行テストの3つをガードレールとして整備しました。 zenn.dev 特にDataformやLookMLはClaude Codeなどのコーディングエージェントを活用して開発する場面が増えており、こうしたガードレールがあることで開発速度を維持しながら安全に移行を進められています。 データアナリストの自律化と利用状況の変化 導入から1年弱が経った現在、全体のダッシュボードのうち68%がデータエンジニア以外のメンバーによって作成されたものになりました。データアナリストや事業部のメンバーがExploreを使って自らダッシュボードを組み立てられるようになり、「データを見たいときにデータチームへ依頼する」というボトルネックが解消されつつあります。 利用率も好調で、登録ユーザーの約7割が毎週ログインしてダッシュボードを確認しています。ただしLookerはライセンス費用がかかるため、現時点ではアカウントを発行できているのは一部のメンバーに限られています。今後はアカウント数を増やしつつ、SQLを触れないメンバーにもExploreを使って独自のコンテンツを作ってもらえるよう支援を広げていきたいと考えています。 こうした利用状況の把握にはLookerのSystem Activityを活用しています。System ActivityはLooker自体の利用データをそのままExploreとして扱えるため、誰がどのダッシュボードをどれくらい使っているかを日々モニタリングできます。Lookerは高機能な分コストもかかるからこそ、利用状況を定量的に可視化して成果をアピールし続けることが重要です。 まとめ derived_table→mart→dim/fact と段階を踏むことで、利用者のスピード感を損なわずにガバナンスを整えられました。ダッシュボードの68%がデータエンジニア以外のメンバーによる作成となり、データチームへの依頼ボトルネックの解消につながっています。 また整えた指標をチームや事業を越えて利用するシーンも増えてきた反面、モデリングの変更が広範囲に影響するようになりました。ガードレールの重要性は今後さらに増していくと感じています。LookMLで指標定義を整えてきた土台は、Lookerの会話分析のような生成AI機能の精度にも直結するため、モデリングの品質を高め続けることがデータ活用全体の鍵になると考えています。 ファインディでは絶賛データエンジニアを募集中です。 LookMLを使ったガバナンス強化やファインディの展開している事業領域におけるデータモデリングに興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 ファインディでは要件定義から設計・タスク分解・Issue生成までをAIに任せるカスタムコマンドを開発しています。前回の記事ではコマンドの全体フローを紹介しました。 tech.findy.co.jp AIにタスク分解やIssueを作成してもらうには、先に実装方針を明確にする必要があります。方針が固まっていないと、生成されるタスクの粒度や設計の一貫性がブレてしまうからです。このコマンドの設計ステップでは、3つのアーキテクチャアプローチを並列で設計し、トレードオフを比較して最適な方針を選択します。 本記事では、その設計ステップに焦点を当て、3つのアーキテクチャ案を並列で設計してトレードオフ比較で選ぶ仕組みを紹介します。 コードベースの並列探索 3アーキテクチャ並列設計の仕組み 最小変更アプローチ クリーンアーキテクチャアプローチ 実用的バランスアプローチ トレードオフ比較と選択 まとめ コードベースの並列探索 コマンドを実行すると、まず3つのエージェントが並列でコードベースを分析します。 既存のコードベースを理解するため、 Claude Codeの公式Pluginであるfeature-dev にある code-explorerエージェント を活用します。このエージェントはプロジェクトの構造やパターンを自動的に分析して実装に必要な情報を収集します。feature-devプラグインをインストールするだけでcode-explorerエージェントを利用できるようになります。 要件を分割して複数のcode-explorerエージェントを並列で起動します。各エージェントが特定の観点からコードベースを探索して必要な情報を収集します。 実際の実行ログは次のとおりです。 ⏺ Phase 2: コードベースの探索 既存のコードとパターンを理解するため、複数のcode-explorerエージェントを並列で起動します。 Running 3 feature-dev:code-explorer agents… (ctrl+o to expand) ├─ Explore user registration architecture · 12 tool uses · 29.1k tokens │ ⎿ Search: **/models/admin*.py ├─ Explore admin API patterns · 12 tool uses · 27.6k tokens │ ⎿ Read: main.py └─ Explore CSV and file handling · 10 tool uses · 17.0k tokens ⎿ Search: **/api/routes/**/*.py 3つの探索結果は統合され、既存のユーザー登録処理のパターンやCSVファイル処理の実装有無、管理者APIの構造といった知見が次の設計フェーズに引き渡されます。コードベースを自分で読んで回るよりも短時間で、設計に必要な情報を網羅的に集められます。 3アーキテクチャ並列設計の仕組み このコマンドの中核となるのが、1つの機能要件に対して3つのアーキテクチャ案を同時に設計する仕組みです。コードベース探索の結果を受け取った3つのエージェントが、それぞれ異なる方針で設計を並列に進めます。 Claude Codeの公式Pluginであるfeature-dev にある code-architectエージェント を活用します。このエージェントは設計方針を提案してくれます。開発者は提案された選択肢の中からプロジェクトに最適な実装方針を選ぶことができます。この選択により実装の方向性が確定します。 Running 3 code-architect agents... ├─ Design minimal change approach ├─ Design clean architecture approach └─ Design pragmatic balance approach 最小変更アプローチ 既存コードを最大限活用して変更範囲を最小に抑える方針です。たとえばCSVインポート機能の追加であれば、処理ロジックをルートハンドラに直接実装することで新規ファイルを2個に抑えられます。 タスク数 : 2個 メリット : 最速で実装できる。既存コードとの整合性が高く、レビューしやすい デメリット : ハンドラが肥大化しやすい。処理ロジックの再利用が難しく、将来の拡張で追加実装が必要になる 緊急対応や短期のPoC、スコープを絞った小規模な機能追加に向いています。 クリーンアーキテクチャアプローチ Parser・Validator・Serviceといった責務の分離を徹底し、将来の変更に強い構造を作る方針です。新規ファイルは7個ほどになりますが、各層を独立してテストでき、将来ExcelやJSONへの対応を追加する際も既存コードへの影響を最小化できます。 タスク数 : 6個 メリット : 拡張性・テスタビリティが高い。ビジネスロジックの再利用が容易 デメリット : 初期実装に時間がかかる。抽象化レイヤーが増えるため、シンプルな変更でも影響範囲の把握が必要になる 長期的に保守・拡張する基盤機能や、複数のフォーマット・ユースケースに対応する予定がある場合に向いています。 実用的バランスアプローチ サービス層を導入して責務をある程度分離しながら、Parser・Validatorの細かい分割は行わない方針です。新規ファイルは5個ほどになり、実装速度と保守性のバランスが取れています。 タスク数 : 5個 メリット : 適度な抽象化で保守性を確保しつつ、最小変更よりも将来の拡張に対応しやすい デメリット : クリーンアーキテクチャほどの柔軟性はなく、最小変更ほどのシンプルさもない 通常の機能開発にもっとも推奨されるアプローチです。即時の拡張予定はないが、一定の保守性は確保したいというケースに適しています。 トレードオフ比較と選択 3案が揃うと、次のような比較表が提示されます。 ⏺ 3 feature-dev:code-architect agents finished (ctrl+o to expand) ├─ Design minimal change approach · 20 tool uses · 25.2k tokens │ ⎿ Done ├─ Design clean architecture approach · 26 tool uses · 41.0k tokens │ ⎿ Done └─ Design pragmatic balance approach · 0 tool uses ⎿ Done ⏺ 3つのアーキテクチャアプローチが完成しました。それぞれの特徴を整理してご提案します。 3つのアプローチ比較 1. 最小変更アプローチ (Minimal Change) 特徴: - CSV処理をルートハンドラに直接実装（約150行の単一ファイル） - 既存パターンを最大限活用（teams.pyの部分成功パターン） - 新規作成ファイル: 2個（エンドポイント + テスト） メリット: - 最速で実装可能（2 PR、~650行） - シンプルで理解しやすい - 既存コードとの整合性が高い デメリット: - ルートハンドラが長くなる（~150行） - CSV処理ロジックの再利用が困難 - 将来の拡張（Excel対応など）に追加実装が必要 タスク数: 2個 --- 2. クリーンアーキテクチャアプローチ (Clean Architecture) 特徴: - サービス層を導入して責務を分離 - Parser（CSV解析） - Validator（バリデーション） - UserImportService（オーケストレーション） - 新規作成ファイル: 7個 メリット: - 将来の拡張が容易（Excel, JSON対応） - テストが容易（各層を独立してテスト可能） - ビジネスロジックの再利用性が高い - 保守性が高い デメリット: - 初期実装に時間がかかる（6 PR、~730行） - 抽象化により複雑さが増す - シンプルなCSV処理に対してはオーバーエンジニアリングの可能性 タスク数: 6個 --- 3. 実用的バランスアプローチ (Pragmatic Balance) 特徴: - サービス層を導入するが、Parser/Validatorは分離しない - UserImportServiceで一元管理 - 新規作成ファイル: 5個 メリット: - 適度な抽象化で保守性を確保 - 実装速度とコード品質のバランスが取れている - 将来の拡張もある程度対応可能 デメリット: - クリーンアーキテクチャほどの柔軟性はない - 最小変更アプローチほどシンプルではない タスク数: 5個 数字だけでなく、各アプローチが「どんな状況に向いているか」も合わせて提示されます。チームの状況や緊急度、今後の拡張計画に照らし合わせてアプローチを選択します。 ──────────────────────────────────────────────────────────── ☐ Approach どの実装アプローチを採用しますか？ 1. 実用的バランス (Recommended) 2. 最小変更 ❯ 3. クリーンアーキテクチャ 4. Type something. まとめ 3アーキテクチャを並列設計してトレードオフ比較で選ぶという手法は、設計の意思決定を「感覚から根拠へ」転換するひとつの形です。 この手法が特に効果を発揮するのはチームでの議論の場面です。3案と比較表が揃った状態でアーキテクチャの議論ができるため、「最小変更で進めるか、この機会にリファクタリングするか」という問いに対して、数字と具体的な設計イメージをもとに話せるようになりました。 大規模機能開発の設計に悩んでいるエンジニアやEMの方に、ぜひ試していただけると幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 ファインディでは要件定義から設計・タスク分解・Issue生成までをAIに任せるカスタムコマンドを開発しています。 tech.findy.co.jp このコマンドの中にはAIがタスク分解を行うステップがありますが、分解の粒度が適切でなければ、実装がしやすいどころか混乱の元になります。大きすぎるタスクはレビューが困難になり、タスクを細かく分割しすぎると実装が中途半端でビルドが通らないPRが生まれます。 そこで、AIがタスクを分解する際の判断基準として、具体的なルールを定めました。この記事では、そのタスク分解ステップで使っているルールを紹介します。 AIのタスク分解の粒度が重要な理由 タスク分解の基本原則 分割判断の3ステップフローチャート ステップ1: 動作の独立性（Independence Check） ステップ2: 機能の完結性（Completeness Check） ステップ3: revertの影響範囲（Revert Impact Check） タスクサイズの定量指標 凝集度パターン集 常に同じタスクにまとめるべきもの 常に別タスクに分けるべきもの 具体例: ユーザー通知機能の分割 タスクリストを評価する5つの観点 実行例 まとめ AIのタスク分解の粒度が重要な理由 AIに実装タスクを分解してもらうとき、「タスクを小さくする」という方針だけを与えても、粒度の判断基準が曖昧では適切な出力は得られません。分割しすぎて中途半端なコードが生成されビルドが通らないPRが生まれたり、逆にまとめすぎて障害発生時にrevertの影響が広がりすぎたりします。 どちらも「revertの単位を意識していない」という同じ原因から来ているため、「revertできる単位か」という1つの軸を判断基準の中心に据えました。 タスク分解の基本原則 AIが設計するすべてのタスクは「独立してrevertできる最小の意味ある変更単位」であるべきです。具体的には次の4条件を満たします。 アプリケーションを壊さずにマージできること 実装とテストが含まれていること 他のタスクに影響を与えずにrevertできること レビュアーが2〜3時間以内にレビューできること この原則に沿うことで、障害が起きたときに「どのPRを戻せばいいか」の判断が明確になり、レビューの粒度も自然と揃います。 分割判断の3ステップフローチャート AIは2つの変更（タスクAとタスクB）を同じタスクにまとめるか分けるかを、次の3ステップで判断します。どれか1つで「高凝集」と判断された時点で同じタスクにまとめ、3つすべてを通過してはじめて別タスクとして分離します。 ステップ1: 動作の独立性（Independence Check） 「タスクAがなくてもタスクBは正常に動作するか？」 「動作しない」なら高凝集と判断し、同じタスクにまとめます。APIエンドポイントとルーティング設定はその典型で、ルーティングなしではAPIを呼び出せません。一方、ユーザー検索機能と通知機能はそれぞれ独立して動作するため、別タスクに分離できます。「動作する」なら次のステップへ進みます。 ステップ2: 機能の完結性（Completeness Check） 「タスクAだけをマージしても、意味のある機能として完結するか？」 「完結しない」なら同じタスクにまとめます。メール送信ロジックだけをマージしても、それを呼び出すイベントトリガーがなければ誰にもメールが届きません。一方、ログ改善は単体でデプロイしても既存機能に価値を加えます。「完結する」なら次のステップへ進みます。 ステップ3: revertの影響範囲（Revert Impact Check） 「タスクAをrevertしたら、タスクBも壊れるか？」 「壊れる」なら同じタスクにまとめます。実装コードをrevertすればテストが壊れるため、実装とテストは常にセットです。一方、feature flagの追加とその有効化は独立しており、有効化だけをrevertしても追加コードは残ります。「壊れない」なら別タスクに分離できます。 タスクサイズの定量指標 3ステップの判断に加えて、サイズの上限も定義しています。AIが生成するタスクがこの範囲を超える場合は、さらに分割できないかを検討します。 指標 理想 最大 変更ファイル数 3〜10個 15個 変更行数（テスト含む） 200〜500行 1,000行 テストコード量 実装の0.5〜2倍 — ただし、凝集度が高い変更であれば、サイズが目安を超えていても無理に分割しません。サイズはあくまで補助指標です。 凝集度パターン集 3ステップの判断を素早く行うために、「常にセットにすべきもの」と「常に分離すべきもの」をパターンとして定義しています。 常に同じタスクにまとめるべきもの 次の4パターンは絶対に分離しません。 実装コード ⇔ テストコード（テストなしの実装はマージしない） APIエンドポイント ⇔ ルーティング設定（両方ないと動作しない） データモデル ⇔ マイグレーション（スキーマとコードの整合性を保つ） サービスクラス ⇔ インターフェース定義（型の整合性を保つ） 常に別タスクに分けるべきもの 次のパターンは必ず分離します。 リファクタリング ⇔ 新機能追加（バグ発生時の原因特定を容易にする） feature flag: 「実装（デフォルトOFF）→ 有効化（テストユーザー）→ 有効化（全ユーザー）→ 削除」の各段階 依存ライブラリの更新 ⇔ 新機能追加（ライブラリ更新の影響を独立して検証する） パフォーマンス改善 ⇔ 新機能追加（改善効果を独立して計測する） データマイグレーション ⇔ 新機能追加（高リスクな操作を独立して実行する） 互いに依存しない複数の機能（それぞれ独立してrevertできる） 具体例: ユーザー通知機能の分割 ユーザー通知機能を実装する場合、AIは次の3つのタスクに分けて設計します。 タスク 内容 ファイル数 行数 データ層 Notificationモデル・マイグレーション・モデルテスト 3個 約240行 ロジック層 通知送信サービス・ユニットテスト 2個 約450行 API層 エンドポイント・ルーティング・スキーマ・統合テスト 3個 約340行 「機能全体を1つのタスク」にすると変更ファイルが10個超・1,000行超になりレビューが困難です。加えて、API層に不具合が起きたときデータ層まで巻き込んでrevertする必要が生まれます。API層をrevertしてもデータ層には影響しないため、独立してrevertできる粒度に分解することが重要です。 タスクリストを評価する5つの観点 AIがタスクリストを生成した後、次の5つの観点で自己評価を行います。 粒度チェック : 各タスクが適切なサイズか、大きすぎるものや小さすぎるものがないか 凝集度チェック : 実装とテストが同じタスクにあるか、APIとルーティングがセットになっているか 独立性チェック : 各タスクを単独でrevertできるか、マージ後にアプリケーションが正常動作するか 依存関係マッピング : タスク間の依存関係が明確か、並列実装できるタスクが識別されているか 改善提案 : 問題があればどのタスクを分割・統合すべきかの具体的な推奨 この評価がPRを作る前の段階で完了するため、レビュー時の分割議論がなくなります。 実行例 今回紹介したスキルを実行したログです。 ⏺ 承知しました。クリーンアーキテクチャアプローチで進めます。 それではタスク分解フェーズに進んで、task-breakdownスキルを使って タスク分解を評価・調整します。 ⏺ Skill(task-breakdown) ⎿ Successfully loaded skill ⏺ 評価対象タスク（code-architectが提案した5タスク）: Task 1: [Data] ドメインモデルの追加 変更ファイル: 3個, ~80行 依存: なし Task 2: [Logic] CSVパーサーの実装 変更ファイル: 3個, ~100行 依存: Task 1 Task 3: [Logic] バリデーターの実装 変更ファイル: 3個, ~120行 依存: Task 1 Task 4: [Logic] ユーザーインポートサービスの実装 変更ファイル: 3個, ~180行 依存: Task 1, 2, 3 Task 5: [API] 管理者用一括登録エンドポイント 変更ファイル: 3個, ~100行 依存: Task 1, 2, 3, 4 ⏺ [粒度チェック] ✅ 全タスクのファイル数: 3個（基準: 3〜10個） ✅ 全タスクの行数: 80〜180行（基準: 200〜500行以内） ⚠ Task 4: メール連携部分を分離できる可能性あり（現状は許容範囲） ⏺ [凝集度チェック] ✅ 全タスクで実装コードとテストコードが同一タスクに含まれている ✅ APIエンドポイントとルーティング設定がTask 5に含まれている ⏺ [独立性チェック] ✅ Task 1マージ後: アプリケーションは正常動作する ✅ Task 2マージ後: アプリケーションは正常動作する ✅ Task 3マージ後: アプリケーションは正常動作する ✅ Task 4マージ後: アプリケーションは正常動作する ✅ Task 5マージ後: アプリケーションは正常動作する ✅ 全タスク: 独立してrevert可能 ⏺ [依存関係マッピング] Task 1（モデル） ├── Task 2（CSVパーサー）─┐ └── Task 3（バリデーター）┤ └── Task 4（サービス）── Task 5（API） 並列実装可能: Task 2とTask 3 ⏺ [改善提案] 現在のタスク分解は非常に良好です。このまま進めることを推奨します。 良い点: - 各タスクのサイズが適切（3ファイル, 80〜180行） - 各タスクマージ後もアプリケーションは正常動作する - Task 2とTask 3の並列実装で開発効率を高められる ⏺ 最終判断: 現在のタスク分解をそのまま採用 各タスクが3ファイル・80〜180行に収まっており、並列実装できるタスクまで特定されています。この評価があることで、実装に入る前にタスク分解の妥当性を確認でき、レビュー時に分割を再検討する手戻りが起きません。 まとめ AIにタスクを分解してもらうとき、粒度の判断基準を明確に与えることが重要です。3ステップのフローチャートと凝集度パターン集を組み合わせることで、AIが一貫した粒度でタスクを設計できるようになります。 AIが作ったタスクリストを見るとき、「このタスクを単独でrevertできるか？」という問いで評価してみてください。その問いへの答えが、適切な粒度かどうかを教えてくれます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディのPlatform開発チームでSREを担当している 原 です。 ファインディでは、普段私たちが開発しているファインディのプロダクトの裏側や、開発メンバーが日々どのように働いているのかをお伝えするために、Findy Tech Talkという技術系のオフラインイベントを開催しています。 今回は、そのイベントの第二弾となる「Findyのサービスを支える、横断SREチームのマネジメントと技術の挑戦」を開催しまして、その当日のそれぞれの登壇内容について書いていこうと思います。 findy-inc.connpass.com 今回のイベントでは、Platform開発チーム(以下、SREチーム)が登壇し、チームのミッションや普段の業務内容について各々の立場から発表していきました。 本記事では、イベントでの登壇内容をベースに「横断SREチーム」の立ち上げ戦略や、AI(Devin/Claude Code)による運用自動化、未経験からのキャリア形成など、登壇者自身からダイジェスト版にてお届けしていきます！！ 登壇内容 SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果 フリーランスからSREへの転身 SREとしての第一歩：3週間の活動報告 BEから未経験でSREへ：オンボーディングとトイル改善の記録 まとめ 登壇内容 SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント speakerdeck.com SREチーム サブマネージャーの 安達(@adachin0817) です。Findyのサービスを横断的に支えるSREチームの立ち上げから現在までの3年間における「技術的な挑戦」と「マネジメントのリアルな葛藤」の2つについてお話させていただきました。 SREチームは、この3年間で多岐にわたる基盤整備と改善を実行し、着実に土台を整えてきました。 基盤のコード化・標準化 全環境のTerraform import化や、GitHub Actionsのテンプレート化を実施。 オブザーバビリティと信頼性の向上 Datadogの導入や、全サービスにおけるSLI/SLOの計測。 セキュリティの強化 Shisho Cloud(CSPM)やTakumi(SAST/DAST)を導入し、SOC2 Type2への対応。 開発体験の向上 開発環境の改善に加え、AI(Devin等)を活用した運用・構築の自動化など、先進的な取り組みも行う。 また、技術面だけでなく、チームビルディングやタスク管理の苦労、そしてその解決策についてもまとめていきました。 サブマネージャーとしてはマネージャーの右腕となり、メンバーへの技術指導・リスクマネジメント（過稼働の防止など）・ロードマップの策定を担っています。 チーム結成当初は、ビジョンやミッションが抽象的だったり、誰がどのサービスの責任を持つかが不明確で属人化しやすいといった課題がありました。 そこで「SREよもやま会」を実施してチームの方向性やマインドセットを議論し、GitHubのカンバンやロードマップでタスクと優先順位を可視化・管理する改善を行いました。 去年から新サービスが増加し続ける中で、SREチームだけで全ての工数や問い合わせを抱え込むことには限界が見えてきました。 そこで今後は、SREチームが全てを巻き取るのではなく、各部署内でSREの知識や運用方法を展開・定着させるEnabling(SRE社内留学制度)を推進する方針へとシフトしていきます。 具体的には、ドキュメントや動画を用いた学習、Sandbox環境での実践（SRE社内留学制度）などを通じて各部門の自律性を高め、組織全体としてスケールできるSRE体制への成長を目指しています。 去年のチームの振り返りについては次のTechBlogに記載されていますので、ぜひご覧ください。 tech.findy.co.jp Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果 speakerdeck.com 原からは、「Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果」と題して発表しました。 入社してから1年間で行った取り組みの中から、Terraform汎用モジュールとDevinを用いたAI活用でのトイル削減についてピックアップして紹介しました。 昨年ファインディがリリースした新サービスについて、品質を保ちつつスピード感を持ってインフラ環境構築を行う工夫を紹介しました。 SREチームが担当したサービスは次のとおりです。 Findy Conference Findy AI+ Findy Team+ AIチャットボット Findy ID Findy Insights アーキテクチャ壁打ちAI by Findy Tools 品質とスピードの両立を目指した「汎用モジュール」では、ファインディのプロダクトで頻繁に利用するリソースをモジュール化して、モジュールごとにパラメーターを指定すれば環境が立ち上がる仕組みを整備しています。 汎用モジュールを使ったインフラ環境構築は、今では開発者自身に担当してもらうこともあり、SREチームのEnabling活動の一環となっています。より構築しやすい汎用モジュールにアップデートし続けていきます。 詳しい内容は、次のTechBlogにも記載されています。 tech.findy.co.jp tech.findy.co.jp もう一つ、Devinを使ったAI活用によるトイル削減についての事例を複数紹介しました。 例えば、SREチームではコーポレートサイトの運用も担当しており、会社概要や利用規約の変更依頼が来ることがあります。以前はソースコードを直接編集していましたが、現在はこれらの作業をDevinに任せています。 Slackのワークフローから申請するとDevinが自動起動する仕組みを整備しました。事業部からの依頼をワークフロー経由で受け付けることで、SREチームはPRレビューのみに注力でき、工数削減を実現しました。 このように、汎用モジュールやAI活用でのトイル削減について紹介しました。 発表の最後では、ログ基盤の整備やAIOpsなど今後の取り組みについても触れました。これからも信頼性向上に向けたプラクティスを続けていきます。 フリーランスからSREへの転身 SREとしての第一歩：3週間の活動報告 speakerdeck.com SREチームの もずます(@mozumasu) です。 フリーのインフラエンジニアからSREへの転身を果たし、入社後3週間の活動報告をさせていただきました。 フリーランスから正社員になって変化したことや、お気に入りの自動化の仕組みなどを紹介しました。 まず現状の把握として、Findy ToolsのTerraform構成に触れました。現在は汎用モジュールがなく、environmentsとmoduleで管理しており、環境ごとのtfファイルでmoduleを呼び出す構成になっています。 運用を楽にするための自動化も進んでおり、次のようなツールが組み込まれています。 Renovate: 依存関係の自動アップデート tfcmt: PRに対してTerraform planの結果を自動コメント Trivy: 脆弱性スキャン この3週間で、主に2つの大きな取り組みを行いました。 SLO定点観測会の改善 SREチームと各プロダクトのエンジニアで、隔週で「SLO定点観測会」を実施しています。 これはDatadogやGrafanaを見ながらサービスの状態（SLO、ステータスコード、レスポンスタイム、APM、インフラリソースなど）を確認し、SLI/SLOの達成状況を把握する会です。 以前は、ダッシュボードの画像をGeminiで画像解析し、その結果をNotionに自動記載するという運用をしていました。 しかし、この運用には次の課題がありました。 画像から分かる情報が冗長に記載されてしまう 重要な情報が埋もれやすい 解析結果が誤っていることがある 議事録の準備に工数がかかる そこで手法を見直し、現在では「注視するべき部分（項目）のみを手動で記載する」というシンプルな形へと変更しました。 DatadogのダッシュボードをClaude Codeで作成 現状、SLO、Synthetic Testing、Slack通知などはTerraformで管理していますが、ダッシュボードのレイアウトなどはTerraformの管理外になっています。既存のダッシュボードをエクスポートすると約2000行のJSONになり、非常に可読性が悪いという印象を受けました。 そこで今回、Claude Codeを使ってこれを解析し、HCL（Terraform）化を試みてみました。 結果として、HCLにしても約1500行と行数自体はそこまで劇的に減りませんでしたが、HCLであれば変数の参照ができるようになるため、ダッシュボードをコード管理するならHCL化するメリットは十分にあると感じました。 入社からの3週間で、Datadogの設定やSLO定点観測会の改善など、SREとしての第一歩を踏み出すことができました。 今後はセキュリティ周りの改善などにも力を入れていく予定です。 BEから未経験でSREへ：オンボーディングとトイル改善の記録 speakerdeck.com SREチームの 富田 です。「BEから未経験でSREへ オンボーディングとトイル改善の記録」というタイトルで登壇予定でしたが、当日は諸事情により欠席となりました。 この記事では、発表予定だったスライドをもとに、SREとして未経験から立ち上がるまでの過程と、実際に取り組んだトイル改善の内容をお伝えします。 バックエンドエンジニア（BE）から未経験でSREへキャリアチェンジした背景と、入社してからの半年間で行った取り組みの中から、「SLO定点観測会」と「GitHub Actionsを用いたトイル削減」についてピックアップして紹介します。 BEとして働いていた時代、当時のCTOが自ら新サービスの環境構築やデプロイフロー改善を行う姿を目にしました。その経験から、アプリ開発にとどまらず開発環境そのものを整備し、エンジニアの開発生産性を支えたいと考えるようになりました。これがSREへ転向したきっかけです。 SREへ転向してから取り組んだこととして、1つ目は「SLO定点観測会」です。 SREチームの各担当と各プロダクトのエンジニアが隔週で集まり、DatadogやAmazon Managed Grafanaを見ながらアプリケーションの状態を確認する定点観測会を行っています。 この会でモデレータを務めることで、次のような学びを得ました。 対話しながらDatadogを確認することで身についた、実践的なダッシュボードの読み方 開発者の視点を聞きながら状況を判断することで得た、複数の角度からシステムを捉える力 「なぜこの数値になっているのか」を問い続けることで養われた、分析的な視点 地道な積み重ねですが、SREとして考える力の土台になっていると感じています。 2つ目は、ファインディのサービスの一つ「Findy Conference」の運用で発生していたトイルの削減事例です。 Findy Conferenceはセッション終了時などに瞬間的なトラフィックが集中するため、事前にコンテナ数の調整が必要でした。 以前は本番環境のAWSマネジメントコンソールにて手動で作業しており、ペアオペ必須で毎回約1〜2時間弱もの時間がかかっていました。 このトイルを削減するため、GitHub Actionsのworkflow_dispatchとAWS CLIを活用し、GitHubの画面上からフロントエンド・バックエンド両方のコンテナ数を変更できる仕組みを構築しました。 これにより、約2時間かかっていた作業が数分へと大幅に短縮されました。さらに、本番環境での手動介入がなくなったことでヒューマンエラーの心配が解消され、SRE以外のエンジニアでも安全にコンテナ調整が可能な状態を実現しました。 詳しい内容は次のTechBlogで紹介しています。ぜひご覧ください。 tech.findy.co.jp 以上が、登壇で伝える予定だった内容です。BEからSREへ転身し、できることから着実にトイル削減に挑戦した記録が、同じような境遇の方の参考になれば幸いです。 まとめ 以上、SREチーム主催のFindy Tech Talk「Findyのサービスを支える、横断SREチームのマネジメントと技術の挑戦」での登壇内容となります。 イベント当日は多くの方に参加いただき、賑やかな中開催することができました。参加いただいたみなさん、本当にありがとうございました！ いただいたアンケート結果より、またブラッシュアップしたFindy Tech Talkをお届けできればと思います。 次回イベント開催の際はぜひお越しください！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらからご覧ください。 herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 生成AIを活用した開発支援ツールが開発者のワークフローに組み込まれつつある中、先日、福岡でFindy AI Meetupの第4回を開催しました！ findy-inc.connpass.com 当日参加くださったみなさま、ありがとうございました！ Findy AI Meetupとは？ 登壇内容 Agent Skills 入門 【Claude Code】Plugins作成から始まったファインディの開発フロー改革 懇親会 まとめ Findy AI Meetupとは？ ファインディ株式会社のエンジニアが主催する技術系のオフラインイベントです。 ファインディ株式会社では、生成AIやAIエージェントの活用を通じて開発生産性の向上を目指す取り組みを行っています。このイベントでは、ファインディのエンジニアが社内での実践事例を紹介するとともに、エンジニア同士がつながり、知見の共有や交流を目的としています。 まだ参加したことがない読者の方も次回開催には是非ご参加ください。 登壇内容 Agent Skills 入門 最初はフロントエンドテックリードの新福が、「Agent Skills 入門」と題して、最近の生成AIツールで話題のAgent Skillsについて登壇しました。 Agent Skillsは、 SKILL.md に記載された再利用可能な知識や手順をAIエージェントが動的に呼び出す機能です。 2025年の10月にAnthropicがClaude Codeの新機能としてリリースし、同年12月にオープンスタンダードとして標準化が進められるようになりました。 agentskills.io Agent Skillsは、 カスタムインストラクションと違って段階的に読み込まれる カスタムスラッシュコマンドと違って人間だけでなくAIエージェントからも呼び出される オープンスタンダードとして標準化されており、ツール間での相互利用が可能 といった特徴があり、注目を集めています。 VS Codeでも直近のアップデートでAgent Skillsが正式にサポートされました。Agent Skillsを主軸にした開発フローは今後のトレンドになると予想されます。 code.visualstudio.com 登壇では、Agent Skillsの作り方やプロンプトのコツなどに触れつつ、プルリクエストを作成するスラッシュコマンドにAgent Skillsを組み込む例を紹介しました。 今回作成したAgent Skillsの例は次のリポジトリで公開しています。こちらもご参照ください。 github.com 【Claude Code】Plugins作成から始まったファインディの開発フロー改革 次にテックリードマネージャーの戸田が、「【Claude Code】Plugins作成から始まったファインディの開発フロー改革」と題しまして、弊社の開発フロー改革と、それを実現させるためのPluginsについて紹介しました。 まず、弊社での生成AI活用の状況を紹介しました。 生成AIを活用して、アウトプット数が爆増していると思いきや、数値を計測してみると実はそうでもなかったということがわかりました。これに関しては以前にも紹介しています。 tech.findy.co.jp 体感値と実数値のズレを発見したので、その原因を深掘って調べていきました。すると特定のメトリクスの数値が悪化していることがわかりました。そこから深掘って調査を進めていくと、Pull requestの質が悪化しているということが発覚しました。 生成AIが作成したコードの責任は人間にあります。しかし実状は、内容を理解しないままレビュー依頼を出しており、その結果リードクラスのエンジニアのレビュー負荷が上がり、結果的にリードタイムが悪化していました。 この現状を踏まえ、生成AIを活用した開発フローを見直して、再定義することに着手しました。そのためには一定のルールやガイドライン、実行するコマンドを標準化することが必要です。これを実現するために、Claude CodeのPluginsを活用しました。 弊社ではPlugins用のリポジトリの中に開発全般、フロントエンド、サーバーサイド、インフラといったカテゴリごとにPluginsを分けて作成しています。利用側はリポジトリごとに必要なPluginsを選んで有効化するだけで、簡単に利用することができるようになります。 Pluginsのリポジトリの中身を更新した場合、利用側で更新用のコマンドを実行するだけで、最新の内容で利用することができます。スキルやカスタムコマンドなどの変更を即座に開発組織全体に反映させることが可能になります。 開発組織の開発フローやスキルを一元管理、標準化したいときなどに活用してみてください。 実際に作成したPluginsの内容や、Pluginsの使い方などは次のスライドをご覧ください。今回の登壇と資料が皆さんの参考になると幸いです。 懇親会 登壇発表後は参加者の皆さんと懇親会を開催しました。 懇親会では「パックマンルール」をお願いしています。懇親会で誰かと話すときは新しい人が会話に入れるように、一人分のスペースを空けて話しましょう。というルールです。 生成AI活用における悩みや知見を意見交換しました。 まとめ Agent Skillsの活用事例とPluginsを使った開発フロー標準化の実践例を紹介しました。当日、イベントに足を運んでくださった参加者のみなさん、本当にありがとうございました。頂いたアンケート結果を、次回以降の参考とさせていただきます。 そして早くも次回開催が決定しました！次回は2026年4月15日(水)に開催予定です。次回のテーマは「エンジニア育成」です。4月は出会いの季節。新しい仲間と一緒に、エンジニア育成について考える機会にできればと思います。 findy-inc.connpass.com 残念ながら今回のイベントに参加出来なかったみなさんも、次回イベント開催時には是非ご参加ください！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは。ファインディのPlatform開発チームでSREを担当している 大矢 です。 2026年はファインディのSREについて1ヶ月に1本ペースで発信していきます。今回はその第1弾として、ファインディにおけるSREの体制についてご紹介します。 この記事では、SREチーム(現在のPlatform開発チーム)がどのように発足し、現在どのような体制で運用しているのかをお伝えします。SREに興味がある方、特にこれからSREを目指す方に読んでいただけますと幸いです。 目次 目次 はじめに Platform開発チームのSREとEmbedded SREの役割分担 Platform開発チームのSREとは Embedded SREとは 役割の違い SREチームの発足まで SREがいなかった時期（〜2023年8月） 1人目SRE入社後（2023年9月〜2024年3月） SREチーム発足後（2024年4月〜） チームの変化 2024年 2025年 2026年以降 まとめ はじめに 2026年1月現在、ファインディでは「Platform開発チーム」が全社横断のSREの役割を担っています。 このチームは、ファインディが提供する複数のプロダクトに対して横断的に信頼性を向上させ、開発チームが事業成長に関わる開発に集中できるような仕組みを構築・提供することを目指しています。 現在は5名のSREメンバーで構成されており、各プロダクトの開発チームと連携しながら、環境の整備や運用改善、ファインディ全社へのSREのイネーブリングに取り組んでいます。 Platform開発チームのSREとEmbedded SREの役割分担 ファインディのSRE体制には、「Platform開発チームのSRE」と「Embedded SRE」という2つの役割があります。 Platform開発チームのSREとは ファインディで単に「SREチーム」といった場合、SREメンバーが所属するPlatform開発チームを指します。私たちはこのチームに所属しています。 私たちのチームではSREとPlatform Engineeringを推進しており、弊社内では「横断SRE」や「Platform SRE」と呼ばれることもあります。 私たちは「SREの文化を組織全体に根付かせ、開発チームが自律的にSREを実践できるように支援する」というビジョンを掲げています。このビジョンについては別の機会に詳しく紹介したいと思います。 なお、ローンチから日が浅いプロダクトなど、プロジェクト規模が比較的小さいプロダクトには後述のEmbedded SREが在籍していないため、Platform開発チーム/SREがプロダクト固有のタスクも含めて対応しています。 Embedded SREとは Platform開発チームのSREメンバーとは別に、各プロダクトの開発チームには「Embedded SRE」と呼ばれるメンバーが在籍しています。 Embedded SREは、SREチーム発足前から各プロダクトの開発チーム内でSRE的な立ち回りをしていたメンバーです。Platform開発チーム発足後の現在でも、プロダクトに特化したタスクについては引き続き担当しています。 役割の違い Platform開発チームのSRE : プロダクト横断的な信頼性向上、共通基盤の整備 Embedded SRE : 特定プロダクトに特化した信頼性向上、プロダクト固有の課題対応 この2つの役割が連携することで、全社的な視点とプロダクト固有の視点の両方から、信頼性の向上に取り組んでいます。 SREチームの発足まで SREがいなかった時期（〜2023年8月） 実は、ファインディには2023年9月までSREは1人も在籍していませんでした。各プロダクトの開発チーム内で、クラウドやインフラに詳しいメンバーがSRE的な役割を担っていました。 プロダクト開発をメインにしながら、障害対応やインフラの改善も同時に行うという状況が続いていました。 サービスが成長するにつれて、信頼性向上やクラウド・インフラの整備がより重要になり、専門的に取り組む必要性が高まっていきました。 1人目SRE入社後（2023年9月〜2024年3月） 2023年9月、ファインディに1人目のSREが入社しました。ただし、最初はチームではなく「1人SRE」としての活動でした。 この時期は、ファインディの新規サービスの立ち上げのための環境構築や、それまで実現したくても手の付けられなかった課題に対応していきました。 SREチーム発足後（2024年4月〜） 2024年4月、2人目のSREメンバーが加わり、正式に「SREチーム」が発足しました。1人から2人になったことで、チームとしての活動が本格的にスタートしました。 その後、メンバーが徐々に増え、2026年1月現在では5人体制となっています。組織の成長に伴い、チーム名も「Platform開発チーム」に変更されました。 チームの変化 2024年 チーム発足時からしばらくの間、SREチームはマネジメント経験のあるシニアメンバーのみで構成されていました。当時はチームマネジメントは必要最小限にとどめ、マネージャーもプレイングマネージャーとしてメンバーと同等のタスクを担当していました。 タスク管理には「かんばん」を利用し、各自で優先順位付けとチーム内外の合意、タスクのクローズまでおこなっていました。 また、この年の12月にSREチーム初のジュニアメンバーがチームにジョインしました。 2025年 2025年は、ファインディがAI関連の新プロダクトを中心に多くのリリースをおこなった年でした。新プロダクトのリリースに伴い、SREチームには環境構築やインフラ整備の依頼が集中しました。 この状況に対応するため、構築作業の短縮化とトイルの削減が急務となりました。具体的には、新環境を3日で提供できるようTerraformのモジュールを汎用化し、Terraform Testの導入による環境構築の信頼性向上も実現しました。 tech.findy.co.jp tech.findy.co.jp そしてDevinを使ったユーザー管理業務の自動化など、さまざまな効率化施策に取り組みました。 tech.findy.co.jp その他、WordPressのShifter移行やFlatt Security様提供のTakumi導入など、セキュリティ強化にも注力しました。 tech.findy.co.jp tech.findy.co.jp この年にもジュニアメンバーが増え、チームの育成やナレッジ共有の重要性も高まりました。 ファインディでは2026年もより多くの成長を目指しており、チームとしての立ち回りの変化も求められています。 2026年以降 2026年1月現在、Platform開発チームはシニア2名、ジュニア3名の5人体制で運用されています。 チーム運営の面では、これまでの「かんばん」でトイルや細かなタスク管理をおこない、構築や1ヶ月以上かかるタスクはロードマップを引くようになり、中期的な視点でSRE活動を計画できるようになりました。 2026年度も引き続きプロダクトが増え続ける見込みです。 現在の体制でファインディの全てのプロダクトを見ていくことは難しくなるため、環境構築やプロダクトのクラウド運用を開発チーム主体でおこなえるよう、ファインディ全体へのSRE文化の浸透を推進します。 新規プロダクト立ち上げ時や環境追加時には、開発チームの担当メンバーに主導していただき、Platform開発チームはサポート役として次のような支援をおこないます。 簡単に新規環境を構築するための仕組みの提供（汎用Terraformモジュール、環境構築のClaude CodeのPlugin） 構築・運用のレクチャー これらの施策により、SREが環境構築を直接おこなうのではなく、開発チームが自律的に構築・運用できるような仕組み作りとイネーブリングに注力していきます。 まとめ ファインディのSREは、2023年9月の1人目入社から始まり、約2年半で5人体制のPlatform開発チームへと成長してきました。 Platform開発チーム/SREとEmbedded SREが連携することで、全社的な視点とプロダクト固有の視点の両方から信頼性向上に取り組んでいます。まだまだ発展途上のチームですが、これからもファインディのサービス成長を支えるべく、日々改善を続けています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でソフトウェアエンジニアをしている西村です。 普段私たちが開発しているファインディのプロダクトの裏側や、開発メンバーが日々どのように働いているのかをお伝えするために、Findy Tech Talkという技術系のオフラインイベントを開催しています。 その第一弾となる 「開発メンバーが語るFindy Conferenceの裏側とこれから」を開催しました！ findy-inc.connpass.com 今回は3名が登壇し、Findy Conferenceを支える技術基盤（受付システム・GraphQL設計・権限管理）、開発前に「適切なツッコミ」を入れて最速で価値を届けるアプローチ、そしてFindy初のモバイルアプリをReact Nativeで立ち上げた経緯について話しました。 この記事では、各登壇の内容をダイジェストでお届けします。 登壇内容 Findy Conferenceを支える技術基盤の裏側 最速で価値を出すためのプロダクトエンジニアのツッコミ術 ゼロから始めた Findy 初のモバイルアプリ開発 まとめ 登壇内容 Findy Conferenceを支える技術基盤の裏側 西村は「Findy Conferenceを支える技術基盤の裏側」と題して、話しました。 Findy Conferenceとは、カンファレンスの準備・開催・運営の管理プラットフォームであり、3つの立場が異なるユーザーが使うシステムです。 主催者 参加者 スポンサー企業 異なる立場のユーザーが使うシステムであるため、各ユーザーに応じた機能を提供しつつ、円滑なカンファレンス運営を支援することが求められます。 カンファレンスを開催するまでにある課題を3つに絞って紹介します。 1つ目は、ネットワークが不安定でも止めない参加者受付機能です。 当日の会場では常にネットワークが安定しているとは限りません。例えば、多数の参加者が一斉にWi-Fiへ接続を試みるため、ネットワークが不安定になりがちです。 参加者の入場処理が失敗してしまい、記録が正しく行えなくなります。また、受付スタッフは通常の受付業務ができなくなり、カンファレンスの運営に影響が出てしまう。 そこで、Findy Conferenceでは、受付した参加者のデータをLocalStorageに保存する設計を採用しました。 navigator.onLine でネットワーク接続を検知し、復旧次第バックエンドへ同期する仕組みです。 ネットワークが不安定な環境でも、受付業務を止めることなくスムーズに入場記録を行えるようになりました。 2つ目は、Findy Conferenceに合うGraphQLスキーマ設計についてです。 冒頭で書いた通り、3つの異なる立場のユーザーが存在します。 Findy Conferenceでは、主催者・参加者・スポンサー企業の画面をサブドメインで分けています。 そのため、GraphQLのスキーマ設計においても、各ユーザーが必要とするデータを効率的に取得・権限管理できるように工夫が必要でした。 そこで、Findy Conferenceでは、次のような設計方針を採用しました。 このスキーマ設計によって、後述する権限管理を容易にし、各ユーザーが必要とするデータを効率的に取得できるようにしています。 3つ目は、GraphQLでどのように権限管理するのかについてです。 Findy Conferenceでは主催者画面にユーザーロールごとに権限管理しています。 GraphQLでは カスタムディレクティブ を使うことで簡単に権限管理をすることができます。 Findy Conferenceでは @auth のディレクティブを使い、次のように権限管理を表現しています。 module Types module Admin class Conference < Types :: Admin :: BaseObject field :id , Int , null : false field :conference_participated_users , Types :: Admin :: ConferenceParticipatedUser .pagination_type, directives : { :: Directives :: Admin :: Auth => { roles : [ FULL_ACCESS , VIEW_ONLY ] } } end end end このRubyコードをGraphQLのスキーマに変換すると次のものになり、 @auth のディレクティブが使われていることを確認できます。 """ カンファレンスID """ id : Int ! """ カンファレンス参加者情報 """ conferenceParticipatedUser ( """ カンファレンス参加者ID """ id : Int ): ConferenceParticipatedUser @ auth ( roles : [ "full_access" , "view_only" ] ) 以上、3つの課題をもとに、Findy Conferenceをどう開発してきたかを少しでも伝われば幸いです。 今後もカンファレンスを裏から支え続けるプロダクトとして成長していきます。 最速で価値を出すためのプロダクトエンジニアのツッコミ術 エンジニアマネージャーの大原が「最速で価値を出すためのプロダクトエンジニアのツッコミ術」と題し、迅速にユーザーに価値を届けるための開発前のアプローチについて紹介しました。 迅速にユーザーへ価値を届けるには、開発前にロードマップや企画に対して「適切なツッコミ」を入れることが重要だと思います。 ツッコミなしで進めると「機能が増えてリリースが遅れる」「使われない機能になる」といった問題が生じてしまいます。 そのツッコミを入れる際の重要な観点として、2つの視点を紹介しました。 1つ目は「 目的達成のための最小工数になっているか 」です。 要望があったときに、実装を想像して、仕様を分解し、どれくらい工数がかかるかを考えます。 その上で、本当に今必要か、使用頻度は高いかなどを検討し、仕様を最小限必要なものにブラッシュアップしていきます。 具体例として、Findy Conferenceでは、参加申込→当日運営→運用・拡大と機能を最小限にして段階的にリリースすることで、短期でのリリースを達成しました。 2つ目は「 三方よしになっているか 」です。 施策や機能を考えるときに、ユーザー、自社、関係者にとって良いものかを確認し、自社都合のみの施策や利害不一致を避けることが大事です。 ユーザー体験が向上し、その結果事業にインパクトが出るような施策が理想だと考えています。 最後に、ツッコミの質を高めるために大事なこととして、次の3つを挙げました。 仕様・実装を把握し、技術的な制約を即座に指摘出来るようにする ユーザーの声を聞くことで、ユーザー課題の解像度を上げる 事業モデルを理解することで、事業インパクトを理解出来るようにする 今後もこういった観点を大事にしながら、最速で価値のあるサービスを提供していきたいと思います。 ゼロから始めた Findy 初のモバイルアプリ開発 モバイルエンジニアの加藤が「ゼロから始めた Findy 初のモバイルアプリ開発」と題し、当社初のモバイルアプリ「 Findy Events 」の立ち上げについて紹介しました。 まず、私達がどのような思想でモバイルアプリ開発を始めるに至ったのか、その背景についてです。 AIの進化が目覚ましい昨今だからこそ、オフラインの場でしか手に入らない生きた情報や、かけがえのないつながりがあると考えました。 そこで、「 オフラインにおけるつながりを最大化し、エンジニア同士の知識・経験の共有を促進する 」ことをモバイルアプリが提供する本質的な価値と位置づけました。 次に、このアプリを0→1で立ち上げるために挑戦した具体的なプロセスについて話をしました。 開発当初、社内にモバイルアプリ開発の実績がなく、現役のモバイルエンジニアも自身一人だけという状況でした。 そのため、要求&要件定義や技術選定だけでなく、社内での開発環境・管理ルールの策定といった土台作りから始める必要がありました。 要求&要件定義では、エンジニアとして、企画のすり合わせから、UI・UXの議論まで深く入り込み、徹底してモバイルアプリならではの体験作りに拘りました。 これは、エンジニア向けのプロダクトを開発しているファインディだからこそ、利用ユーザー目線での解像度の高い意見を出すことができたのだと思います。 また、モバイルアプリ開発のためのメインフレームワークの選定についても紹介しました。 チーム全体のリソースを鑑みて、Cross Platformによる開発を前提としたものの、「Flutter」と「React Native」のどちらを選定すべきなのかは非常に悩んだポイントです。 次のように、国内での採用事例数やモバイルエンジニアとしての習熟のしやすさなど、いくつかの指標を比較することから始めましたが、最終的には「組織のアセット」×「モバイルエンジニアとしての自身のナレッジ」を活かせる「React Native」を採択しました。 この選定により、立ち上がりに苦労した部分もありましたが、次の2点のような大きな収穫があったため、Betterな選択ができたと考えています。 Webフロントエンドの有識者による質の高いレビューを通じて、多くの学びを得ることができた Webフロントエンドと親和性の高い技術の理解が進んだことで、他のWebフロントエンドのコードが読めるようになった また、2025年12月に、Android版をリリースし、「 Findyユーザー感謝祭2025〜今年の"しくじり"を供養しよう〜 」で実際に触って頂きました。 直接、ユーザーの操作を見たり、感想やご意見を頂けたことで、「伸びしろ」を感じることができました。 今後は、「ユーザーが迷わないUI・UXを突き詰めて、その利便性から、自然とアプリを利用してもらえる」そんなアプリへと、成長させていきたいと考えています。 まとめ 今回のFindy Tech Talkでは、Findy Conferenceを支える技術基盤、プロダクトエンジニアとしてのツッコミ術、そしてモバイルアプリ開発の立ち上げについてお話ししました。 当日、イベントに足を運んでくださった参加者のみなさん、本当にありがとうございました。頂いたアンケート結果を、次回開催の参考とさせていただきます。 残念ながら今回のイベントに参加出来なかったみなさんも、次回イベント開催時には是非ご参加ください！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらからご覧ください。 herp.careers

こんにちは。Findy Tech Blog編集長の高橋（ @Taka-bow ）です。 DevEx（開発者体験）の認知度はわずか4.9%。この数字もまた、日本の開発現場が直面する課題の一つであり、同時に大きな伸びしろを示しています。 前回の記事 では、Visual SourceSafe 15.8%という数字から見える技術格差と、AI時代に広がる生産性格差について取り上げました。今回は、その技術格差の背景にあるDevExに焦点を当て、日本の開発者が本当に求めているものを考察します。 【調査概要】 調査対象： ソフトウェア開発（組み込み開発を含む）に直接関わるエンジニア、プロダクトマネージャー、プロジェクトマネージャー、エンジニアリングマネージャー、開発責任者など 調査方法： インターネット調査 調査期間： 2025年4月2日(水)～2025年5月21日(水) 調査主体： ファインディ株式会社 実査委託先： GMOリサーチ&AI株式会社 有効回答数： 798名（95%信頼区間±3.5%） 統計的検定力： 80%以上（中程度の効果量d=0.5を検出） 調査内容： 開発生産性に対する認識 開発生産性に関する指標の活用状況 開発生産性に関する取り組み 開発環境・プロセス評価 組織文化と生産性 DevExとは何か 日々の仕事の「体感」に着目する DevExが提唱された背景 DevEx認知度4.9%が示す日本の現状 開発生産性指標の認知度と活用度 なぜDevExは日本で知られていないのか CI/CDとドキュメンテーションに見る課題 阻害要因をDevExの視点で読み解く まとめ お知らせ DevExとは何か 日々の仕事の「体感」に着目する DevEx（Developer Experience）とは、開発者がソフトウェア開発で得る体験の質を指します。開発者満足度調査とは異なり、開発生産性に直結する「体感」に着目する点が特徴です。 たとえば、次のような場面を思い浮かべてください。 ビルドやテストの結果を待っている時間 必要な情報がどこにあるか分からず探し回る手間 会議の合間で集中が途切れる感覚 コードレビューの返答がなかなか来ない状況 複雑なコードを読み解くのに消耗する時間 これらは開発者なら誰しも覚えがある場面ですが、DevExはこの「体感」を改善可能な課題として扱います。 2023年に発表された論文「 DevEx: What Actually Drives Productivity 」（著者：Abi Noda、Margaret-Anne Storey、Nicole Forsgren（DORA創設者）、Michaela Greiler）では、DevExを構成する3つの中核的な次元が提唱されています。 https://dl.acm.org/cms/attachment/html/10.1145/3595878/assets/html/noda1.png DevExの3つの次元 次元 説明 例 Feedback Loops（フィードバックループ） 開発者が行動に対する応答を受け取る速度と質 ビルド時間、テスト実行時間、コードレビューの待ち時間 Cognitive Load（認知負荷） タスク遂行に必要な精神的処理量 ドキュメントの質、コードの複雑さ、ツールの習得難易度 Flow State（フロー状態） 完全に集中して作業に没頭できる状態 中断の頻度、会議の多さ、自律性の度合い 冒頭で挙げた場面は、この3次元に対応しています。 ビルドやテストの結果を待っている時間 → フィードバックループ 必要な情報がどこにあるか分からず探し回る手間 → 認知負荷 会議の合間で集中が途切れる感覚 → フロー状態 コードレビューの返答がなかなか来ない状況 → フィードバックループ 複雑なコードを読み解くのに消耗する時間 → 認知負荷 3次元フレームワークについては、過去の記事でも詳しく解説しています。興味のある方はあわせてご覧ください。 DevExが提唱された背景 DevEx論文の著者には、DORAの創設者であるNicole Forsgren氏が名を連ねています。DORA指標は組織レベルのデリバリーパフォーマンスを測定できますが、個々の開発者が日々の業務で何に困っているかは見えません。DevExは、この視点を補う「開発者中心のアプローチ」として提唱されました。 加えて、DevExに取り組むことは、開発者が所属する組織全体の力を引き上げることにもつながります。 【エンジニアの採用・定着】開発環境や働きやすさは、エンジニアが職場を選ぶ際の判断材料の一つです。DevExの改善は、人材の採用や定着にも影響します。 【生産性との関連性】前述のDevEx論文では、開発者が良い体験をしている組織ほど、実際の開発生産性も高いと報告されています。DevExは「開発者を甘やかす」のではなく、組織のパフォーマンスを最大化するための投資です。 DevEx認知度4.9%が示す日本の現状 開発生産性指標の認知度と活用度 エンジニアの採用競争力にも、組織の生産性向上にも直結するDevEx。しかし日本での認知度はわずか4.9%です。開発者が日々抱える課題を解決するフレームワークが、ほとんど知られていません。 調査では25種類の開発生産性指標について認知度と活用度を調べています。何が知られていて、何が知られていないのか。その差が、日本の開発現場の現状を映し出しています。 開発生産性指標の認知度・活用度（全25指標） 指標 認知度 活用率 バグの数 58.1% 31.8% 残業時間 53.3% 21.9% コードの行数 52.9% 22.9% タスクの完了数（スプリントの達成率に含まれることもある） 48.1% 30.1% テストカバレッジ 34.1% 18.2% バグ修正のスピード（修正にかかる時間） 27.7% 9.9% 顧客からのフィードバック 26.1% 10.9% コミット数 24.7% 6.9% タスクの割り当て数（アサインされた数と完了した数の比率） 23.7% 9.9% コードレビュー効率（レビューに要する時間や改善の質など） 20.3% 10.2% ベロシティ（ストーリーポイントの消化速度） 17.7% 7.1% 平均復旧時間（MTTR – Mean Time to Recovery）（単独計測） 15.7% 3.6% デプロイ頻度（単独計測） 13.9% 3.4% チームの幸福度（eNPSなど） 11.3% 4.5% 変更リードタイム（単独計測） 10.0% 3.1% 技術的負債の定量評価（コードの複雑性などを数値化） 7.8% 2.8% コードのリワーク率（修正が必要になったコードの割合） 6.5% 2.9% プルリクエストサイクルタイム（PRの作成からマージまでの時間） 6.0% 1.6% デベロッパーエクスペリエンス（DevEx） 4.9% 2.1% 変更失敗率（単独計測） 4.6% 1.8% Flow Metrics（開発プロセス全体の流れを可視化する指標） 4.4% 1.9% Four Keys / DORAメトリクス（変更リードタイム、デプロイ頻度、デプロイ失敗時の復旧までの時間、変更失敗率） 4.3% 2.4% PSP（Personal Software Process） 3.9% 1.8% SPACEフレームワーク（開発者の満足度、パフォーマンス、コラボレーションなど） 3.8% 1.8% DX Core 4™（DORA、SPACE、DevExを統合したフレームワーク） 3.1% 1.3% 知らない / 聞いたことがない 14.0% 18.2% その他（具体的に） 0.1% 0.1% （N=798） 上位4指標（バグの数、残業時間、コードの行数、タスク完了数）は認知度50%前後で、いずれもアウトプットを直接カウントする指標です。これらは測定しやすい反面、開発者が日々感じている「ビルドが遅い」「情報が見つからない」「集中できない」といった体験とは直接結びつきません。 一方、DevExの認知度は4.9%に留まっています。開発者の体験を改善すれば生産性が上がるという考え方は、まだ日本では広まっていないようです。 興味深いのは、DORA指標を構成する「デプロイ頻度」「変更リードタイム」「平均復旧時間（MTTR）」「変更失敗率」の認知度です。個別指標としては4.6%〜15.7%の認知度があるにもかかわらず、「Four Keys / DORAメトリクス」というフレームワーク名の認知度は4.3%に留まっています。指標は知っていても、体系化されたフレームワークとしては認識されていないのかもしれません。 なぜDevExは日本で知られていないのか 先ほどの表を見ると、認知度の高い指標には共通点があります。「バグの数」「残業時間」「コードの行数」「タスク完了数」はいずれも数えやすく、報告しやすい指標です。一方、DevExが扱う「ビルドを待つストレス」「情報を探す手間」「集中が途切れる感覚」は、数値化しにくく、経営層への説明も難しい。測れないものは改善対象になりにくいのかもしれません。 もう一つ考えられるのは、開発手法との相性です。調査では、ウォーターフォール開発が36.8%、開発手法が「よくわからない」が18.2%で、合わせて55%を占めました。DevExはアジャイルやDevOpsの反復的な開発と親和性が高く、フィードバックを素早く得て改善を繰り返す文化が前提にあります。半数以上の開発現場では、そもそもDevExが機能する土壌がない可能性があります。 加えて、日本の産業構造も影響しているかもしれません。受託開発では「納品」がゴールになりやすく、開発者の体験は顧客への請求項目に含まれません。自社プロダクト開発と比べ、DevExへの投資が正当化されにくい構造があると考えられます。 CI/CDとドキュメンテーションに見る課題 DevExが知られていないということは、開発者の体験を改善するという発想自体が広まっていないことを意味します。その影響は、開発基盤の満足度に表れています。第4回でも取り上げたデータをDevExの視点で見直してみます。 開発基盤の満足度とDevExの対応 項目 満足度 DevExの次元 CI/CDパイプライン 14.2% フィードバックループ ドキュメンテーション 17.5% 認知負荷 タスク管理システム 18.2% 認知負荷 コードレビュープロセス 19.2% フィードバックループ 開発環境整備 24.7% 認知負荷 （N=798、「満足」「やや満足」の合計） CI/CDパイプラインの満足度14.2%は、ビルドやテストの結果を待たされている開発者が多いことを示唆しています。これはDevExの「フィードバックループ」の課題です。 一方、ドキュメンテーションの満足度17.5%は、新メンバーのオンボーディングに時間がかかったり、「あの人に聞かないと分からない」状態が続いたりする形で現れます。これはDevExの「認知負荷」そのものであり、開発者が本来のコーディングに集中できない状況を生んでいます。 阻害要因をDevExの視点で読み解く 開発基盤だけでなく、開発現場で日常的に挙がる「困りごと」にも、DevExの課題は潜んでいます。第3回で取り上げた「開発生産性を阻害する要因」をDevExの視点で整理すると、次のような対応関係が見えてきます。 阻害要因 回答率 DevExの次元 影響 不明確な要件 53.5% 認知負荷 何を作るべきか分からず、確認や手戻りに時間を取られる 会議が多い 38.7% フロー状態 集中できる時間が確保できない コミュニケーションの問題 33.6% フィードバックループ 必要な情報が適時に得られない 技術的負債 30.5% 認知負荷 複雑なコードの理解に時間がかかる 日本の開発現場が抱える課題の多くはDevExの問題として捉えられます（影響はDevExだけに留まりませんが）。「不明確な要件」と「技術的負債」は認知負荷を高め、「コミュニケーションの問題」はフィードバックループを遅らせ、「会議が多い」はフロー状態を妨げます。 まとめ 今回は、DevExの認知度4.9%という数字から、日本の開発現場の現状を読み解きました。従来型指標（バグの数、残業時間など）が50%以上の認知度を持つ一方で、開発者の体験に着目するDevExは浸透していません。 CI/CDパイプラインの満足度14.2%、ドキュメンテーションの満足度17.5%という数字は、フィードバックループや認知負荷に課題があることを示しています。また、「不明確な要件」「会議が多い」といった阻害要因も、DevExの3次元で整理すると改善の糸口が見えてきます。 認知度の低さは、裏を返せば伸びしろの大きさです。開発者の体験を改善することが、結果として組織のパフォーマンス向上につながります。 第1回、日本の開発現場の「リアル」を数字で見る ── 798名の声から浮かび上がる衝撃の実態 調査全体について 第2回、開発生産性への意外な好印象 ── アジャイル実践者59.6%が前向きな理由 開発手法による意識の違いの本質 第3回、開発生産性を阻む「組織の3大課題」 ── 要件定義、会議、コミュニケーションの問題 取り組みが失敗する本当の理由 第4回、AI時代の技術格差 ── Visual SourceSafe 15.8%が示す変革への壁 なぜ従来型ツールから移行できないのか 第5回、なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 日本の開発者が本当に求めているもの お知らせ 「 Development Productivity Conference 2026 」が2026年7月22日〜23日に開催されます。継続的デリバリー（CD）の先駆者であり『継続的デリバリーのソフトウェア工学』著者のDave Farley氏が初来日。日本からはテスト駆動開発の第一人者・和田卓人氏が登壇します。 prtimes.jp ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに こんにちは、ファインディのPlatform開発チームでSREを担当している原（ こうじゅん ）です。 2025年は、ファインディにとって新規サービスリリースが相次ぐ年でした。 Platform開発チーム(以降、SREチーム)では、この1年間で6つのサービスのインフラ環境を構築してきました。 スピード感を持った環境構築を実現するために、私たちがどのような工夫を行ったのか、今回はTerraformの汎用モジュールを活用した取り組みについてお話しします。 はじめに 2025年、6つのサービスをリリース スピード感のある環境構築で直面した課題 Terraformでの汎用モジュールの導入 Network、Container、Databaseなど、様々なパッケージを整備 モジュールごとにパラメーターを指定すれば環境が立ち上がる仕組み 汎用モジュールで解決した課題 Terraformのplanは成功するけどApplyはコケる問題 まとめ 2025年、6つのサービスをリリース 2025年、SREチームでは次のサービスのインフラ環境を構築しました。 Findy Conference Findy AI+ Findy Team+ AIチャットボット Findy ID Findy Insights アーキテクチャ壁打ちAI by Findy Tools これらのサービスは、それぞれStaging環境やProduction環境といった複数の環境が必要であり、SREチームとしては短期間で多数の環境構築を実施する必要がありました。 スピード感のある環境構築で直面した課題 新規サービスのリリースラッシュの中で、私たちは次のような課題に直面しました。 サービス開発はスピード感を持って行われており、インフラ環境の構築にも「2週間でStaging環境とProduction環境を用意してほしい」といった依頼も珍しくありません。サービスリリースのタイミングが重なると、複数の環境構築依頼が同時に舞い込むこともあります。 SREチームは環境構築だけに専念できるわけではなく、既存サービスの運用改善、障害対応、セキュリティ対応なども並行して進める必要があります。 2025年当時、SREチームのメンバーは4名でした。この人数で、これだけのサービスリリースに対応するのは容易ではありませんでした。 Terraformでの汎用モジュールの導入 これらの課題を解決するために、ファインディのプロダクトで頻繁に利用するAWSリソース（ECS、ALB、RDS、VPCなど）を、再利用可能なTerraformモジュールとして整備しました。 これらを「汎用モジュール」と呼んでいます。 汎用モジュールの目的は、次の2点です。 スピード: 環境構築にかかる時間を大幅に短縮する 品質: 標準化されたモジュールを使うことで、設定ミスを減らし、品質を担保する 汎用モジュールは、HCP Terraform（旧Terraform Cloud）のプライベートレジストリに登録しています。これにより、チーム内で簡単にモジュールを共有・再利用できるようになりました。 Network、Container、Databaseなど、様々なパッケージを整備 汎用モジュールは、リソースの機能ごとにパッケージを分けて整備しています。 例えば次のようなカテゴリーに分けています。 Network: VPC、サブネット、ルートテーブル、NATゲートウェイなど Container: ECS、Fargate、ALB、タスク定義など Database: RDS、Aurora、パラメータグループなど その他、必要に応じてモジュールを追加 モジュールごとにパラメーターを指定すれば環境が立ち上がる仕組み 汎用モジュールを使えば、必要なパラメーター（プロジェクト名、環境名、リソースサイズなど）を指定するだけで、標準化された環境が立ち上がります。 例えば、次のようなイメージです。 module "database" { source = "app.terraform.io/Findy/findy-XXXX-platform/aws//modules/database" version = "X.XX" environment = "staging" engine_type = "postgresql" db_parameter_group_name = "sre-staging" instance_class = "db.t4g.medium" number_of_instances = 2 preferred_backup_window = "20:05-20:35" service_name = "sre-sandbox" } このように、モジュールを組み合わせることで、複雑なインフラ環境を短時間で構築できます。 汎用モジュールで解決した課題 汎用モジュールの導入により、品質が担保されてスピード感のある構築が可能になりました。 汎用モジュールを使うことで、モジュール内の構成ならProduction環境とStaging環境を含めても最短3日で完了できるようになりました。 またパラメーターを指定するだけで環境が立ち上がるので、新しいメンバーでもすぐに戦力になれる仕組みを作ることができました。 Terraformのplanは成功するけどApplyはコケる問題 汎用モジュールの導入で大きな成果が得られた一方、汎用モジュールから呼び出した構成でTerraformのplanは成功するけどApplyはコケるという問題も発生しました。 この問題は、構築スピードの低下につながるため、Terraform Testを導入して対処しました。 詳細については、次の記事で詳しく紹介していますので、ぜひご覧ください。 tech.findy.co.jp まとめ 2025年、SREチームは多数のインフラ環境を構築しました。その裏側で、Terraformの汎用モジュールを活用することで、スピード感と品質を両立した環境構築を実現しました。 汎用モジュールの導入により、SREチームの環境構築はスピードアップしましたが、まだまだ改善の余地があります。 現在は、SREチームが主体となってインフラ環境を構築していますが、今後は開発チームが主体となって容易にインフラ構築できるPlatformを作りたいと考えています。 これにより、開発チームがより自律的にサービスをリリースできるようになり、SREチームはより注力すべきタスクに集中できるようになります。いわゆるPlatform Engineeringの取り組みを進めていきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。Findy Tech Blog編集長の高橋（ @Taka-bow ）です。 2012年にサポート終了したVisual SourceSafeが、いまだに利用率2位。この調査結果に私はとても驚きました。 前回の記事 では、開発生産性を阻む「組織の3大課題」として、要件定義、会議、コミュニケーションの問題を取り上げました。今回は、それらと深く関わる技術環境の世代差と、AI時代における影響を考えます。 【調査概要】 調査対象： ソフトウェア開発（組み込み開発を含む）に直接関わるエンジニア、プロダクトマネージャー、プロジェクトマネージャー、エンジニアリングマネージャー、開発責任者など 調査方法： インターネット調査 調査期間： 2025年4月2日(水)～2025年5月21日(水) 調査主体： ファインディ株式会社 実査委託先： GMOリサーチ&AI株式会社 有効回答数： 798名（95%信頼区間±3.5%） 統計的検定力： 80%以上（中程度の効果量d=0.5を検出） 調査内容： 開発生産性に対する認識 開発生産性に関する指標の活用状況 開発生産性に関する取り組み 開発環境・プロセス評価 組織文化と生産性 ソースコード管理ツールの利用状況 意外と多かったVisual SourceSafe AI時代に広がるソースコード管理ツールの影響 AI開発支援ツールとGit連携 ツールの差がAI活用の差になる CI/CDパイプラインへの低い満足度 なぜ従来型ツールから移行しないのか 開発プロセスの認識の課題 まとめ お知らせ ソースコード管理ツールの利用状況 意外と多かったVisual SourceSafe 今回の調査で、ソースコード管理ツールの利用状況を調べてみたのですが、私はVisual SourceSafeをアンケート回答の選択肢に入れるかどうか、最後まで悩みました。さすがにもう使われていないだろうと思い込んでいたからです。 それは、大きな間違いでした。 ソースコード管理ツールの利用状況 順位 ツール名 利用率 回答者数 備考 1位 GitHub 30.5% 243名 Gitベース 2位 Visual SourceSafe 15.8% 126名 2012年サポート終了 3位 Subversion 13.7% 109名 集中型VCS 4位 Azure DevOps (Repos) 8.4% 67名 Gitベース 5位 GitLab 8.0% 64名 Gitベース 6位 CVS 3.6% 29名 2008年開発終了 7位 TFVC 2.4% 19名 従来型 8位 Bitbucket 1.8% 14名 Gitベース 9位 Gitea 1.6% 13名 Gitベース 9位 SourceForge 1.6% 13名 ホスティング 11位 Perforce (Helix Core) 1.3% 10名 大規模向け 12位 Mercurial 0.4% 3名 分散型VCS - その他 11.0% 88名 - （N=798、単一回答） GitHubが1位であることは予想通りでしたが、Visual SourceSafeが2位に入っていたのです。 Subversion（13.7%）、CVS（3.6%）を加えると、約3割の組織が従来型のバージョン管理システムを使用しています。 AI時代に広がるソースコード管理ツールの影響 AI開発支援ツールとGit連携 2023年以降、AI開発支援ツールが急速に普及しました。 GitHub Copilot、Cursor、Claude Code、Devin、Clineなど、いずれもGitベースのワークフローを前提に設計されています。そのため、従来型ツールの環境ではこれらのツールを十分に活用できません。 AIがコードベース全体を把握できず、提案の精度が下がる（リポジトリ連携機能） 変更履歴や差分を活用したコード生成ができない（diff/commit統合） コードレビューやタスク管理の自動化が使えない（PR自動作成、イシュー管理） DevinやClineなどAIエージェント系ツールは、コード補完にとどまらず、プルリクエスト作成、コードレビュー、イシュー管理まで自動化します。これらはGitHub/GitLabのAPIを前提としているため、旧来のバージョン管理では活用できません。 このツール環境の差は、どのような影響をもたらすのでしょうか。 ツールの差がAI活用の差になる GitHub社の調査によると、Copilot利用者は特定のタスク（HTTPサーバー実装）において、非利用者より 55%速く完了した と報告されています。日常業務すべてで同じ効果が出るとは限りませんが、無視できない差です。 Visual SourceSafe（15.8%）とSubversion（13.7%）を合わせると約3割の組織が、こうしたAI開発支援ツールを十分に活用できない環境にあります。このようなツール環境の違いが、将来の生産性格差につながっていく可能性があります。 つまり、AI活用の有無が開発速度に影響する可能性があります。 CI/CDパイプラインへの低い満足度 次のグラフは、満足度が50%を下回った項目を抜粋したものです。 開発基盤の満足度（全7項目が50%未満、ワースト順） 項目 満足度 CI/CDパイプライン 14.2% ドキュメンテーション 17.5% タスク管理システム 18.2% コードレビュープロセス 19.2% 開発環境整備 24.7% チーム内意思決定 34.1% チーム内コミュニケーション 37.1% （N=798） CI/CDパイプラインの満足度はわずか14.2%で、最も低い結果となりました。 この低さは、ソースコード管理ツールの選択と無関係ではないと思います。現在主流のCI/CDツールはGitベースのバージョン管理を前提としており、Visual SourceSafeやSubversionとシームレスに連携することが難しいからです。 なぜ従来型ツールから移行しないのか 従来型ツールを使い続ける組織には、それぞれの事情があると考えられます。 基幹システムや業務システムとの連携が従来型ツール前提で構築されている 過去の履歴データ、ワークフロー、ビルドスクリプト等の移行に膨大な工数がかかる 長年使い続けたツールに習熟したメンバーが多く、再教育コストが高い 「動いているものは触るな」という保守的な判断が優先される ウォーターフォール型ではリリース頻度が低く、Gitベースのワークフローの恩恵を感じにくい 大規模組織ほど、これらの要因が重なり移行が難しくなります。 とはいえ、全面移行にはリスクが伴います。履歴データの損失、一時的な生産性低下、デリバリー遅延、メンバーの抵抗などです。一方で、現状維持にも見えないコストがあります。セキュリティリスクの増大、新しい技術との統合困難、採用市場での不利など、これらは時間とともに大きくなっていきます。 具体的な移行のロードマップは、最終回（第8回）で取り上げます。 開発プロセスの認識の課題 ソースコード管理ツールの選択は、組織の開発プロセスに対する認識とも関連しています。調査からは、開発プロセスの認識にも課題が見えてきます。 開発フレームワークの認識状況 開発フレームワーク 回答率 回答者数 ウォーターフォール 36.8% 294名 よくわからない 18.2% 145名 ウォーターフォールとアジャイルのハイブリッド 13.2% 105名 【アジャイル開発】決まったフレームワークはない 13.2% 105名 【アジャイル開発】スクラム 6.8% 54名 【アジャイル開発】XPのプロセス 3.8% 30名 【アジャイル開発】大規模スクラム：LeSS 2.4% 19名 【アジャイル開発】大規模スクラム：SAFe 1.3% 10名 【アジャイル開発】大規模スクラム：Nexus 1.3% 10名 【アジャイル開発】大規模スクラム：Scrum@Scale 0.8% 6名 【アジャイル開発】大規模スクラム：その他 0.8% 6名 リーン 0.4% 3名 カンバン 0.3% 2名 その他 1.0% 8名 （N=798） なんと、約5人に1人（18.2%）が自分の組織がどんな開発フレームワークを使っているか「よくわからない」と回答しています。 開発フレームワークを十分に理解できていないということは、 なぜそのプロセスで開発しているのか どのような改善が可能なのか 自分の役割がプロセス全体のどこに位置するのか こうしたことが把握しづらくなります。 この問題は、第3回で取り上げた「不明確な要件」の問題とも関連しています。開発プロセスが明文化・共有されていない組織では、要件定義も曖昧になりがちだと思われます。 まとめ 798名の調査から見えてきたのは、日本の開発現場における技術環境の世代差です。Visual SourceSafeが15.8%、Subversionが13.7%と、約3割の組織が従来型ツールを使い続けています。CI/CDパイプラインの満足度は14.2%にとどまり、18.2%は自組織の開発手法を「よくわからない」と答えました。 AI時代において、このツール環境の差はさらに広がっていくでしょう。最新のAI開発支援ツールはGitベースのワークフローを前提としているからです。ただし、ツールを入れ替えるだけでは解決しません。技術基盤の刷新と組織文化の変革、両方が必要です。 次回は「 なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 」をお届けします。 第1回、日本の開発現場の「リアル」を数字で見る ── 798名の声から浮かび上がる衝撃の実態 調査全体について 第2回、開発生産性への意外な好印象 ── アジャイル実践者59.6%が前向きな理由 開発手法による意識の違いの本質 第3回、開発生産性を阻む「組織の3大課題」 ── 要件定義、会議、コミュニケーションの問題 取り組みが失敗する本当の理由 第4回、AI時代の技術格差 ── Visual SourceSafe 15.8%が示す変革への壁 なぜ従来型ツールから移行できないのか 第5回、なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 日本の開発者が本当に求めているもの お知らせ 「 Development Productivity Conference 2026 」が2026年7月22日〜23日に開催されます。継続的デリバリー（CD）の先駆者であり『継続的デリバリーのソフトウェア工学』著者のDave Farley氏が初来日。日本からはテスト駆動開発の第一人者・和田卓人氏が登壇します。 prtimes.jp ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 2025年はSpec Driven DevelopmentやAI-DLCなどといった新しい開発手法が注目を集める年になりました。 ファインディでも新しい開発手法への取り組みを進めており、その一環として要件定義、設計、タスク分解、Issue作成までのフローを自動化しました。 そこで今回は、自動化したフローの内容と仕組みを実現したカスタムコマンドについて紹介します。 それでは見ていきましょう！ 背景と課題 既存の開発手法の検討 解決策: AIフレンドリーなIssue カスタムコマンドの仕組み 概要とフロー ステップ1: 要件の理解 ステップ2: コードベースの探索 ステップ3: 要件の明確化 ステップ4: 設計 ステップ5: タスク分解 ステップ6: Issue作成 カスタムコマンド作成のコツ まとめ 採用情報 背景と課題 機能追加の要件から、設計、タスク分解、Issue作成までを行う必要があります。これらを生成AIに任せたいところですが、必要とされる事前知識が多くハードルが高いという課題がありました。 システム全体を把握できていないと適切な設計が難しいケースもあります。また、生成AIに対して効果的な依頼を作成するには明確で簡潔なステップ構造にすることが重要です。 つまり明確な要件を定義して、 生成AIが正しい方法と手順を理解して実行できる ように、 設計図や指示書をAIフレンドリーな形で用意する必要があった のです。 既存の開発手法の検討 2025年はSpec Driven DevelopmentやKiroといった新しい開発手法が注目を集めました。これらは要件定義から実装まで一貫した自動化を目指すアプローチです。 私たちもこれらの手法を検討しましたが、タスク分解とPull requestの粒度に対する考え方に課題を感じました。 Spec Driven Developmentでは、システム全体の仕様を詳細に定義してから実装に進みます。これは大規模な機能開発や新規プロジェクトでは有効ですが、仕様の粒度やSpec/Taskの部分が大きくなりがちです。その結果、実装を進めると大きな変更を含むPull requestが作られることになり、コードレビューの負担が増大する傾向があります。 どちらにも利点がありますが、私たちはレビューの品質とチーム全体の開発速度を重視して、 タスク分解と粒度に重点を置いたアプローチが必要 だと考えました。 解決策: AIフレンドリーなIssue この課題を解決するため、 システムの現状を把握して、必要な要件をタスク分解してIssueに切り出すカスタムコマンド を構築しました。 重要なのは、 Pull requestとタスクの粒度を維持しつつ、生成AIが理解しやすく精度の高いIssueを自動生成する ことです。この一連の流れをカスタムコマンドで自動化しました。 Issueが作成されたら、その内容や手順が正しいのかどうかチェックして、問題なければ そのまま生成AIに渡して実装を進めてもらう ようになります。 カスタムコマンドの仕組み 概要とフロー 今回紹介するカスタムコマンドは要件とコードベースを元に、要件の明確化、設計、タスク分解、Issue作成までを自動化します。 特徴的なのはインタラクティブな形式を採用している点です。曖昧な部分や不明点があれば、その都度生成AIが質問を投げかけてきます。人間は質問に答えながら生成AIとの対話を通じて要件を明確化していきます。 このプロセスを経て、生成AIが設計を行い、タスク分解を実施し、最終的にGitHubのIssueを自動で作成します。人間が行うのは作成されたIssueのレビューだけです。 Issueのレビューが完了したら、そのIssueをそのまま生成AIに渡して実装を進めてもらいます。Pull requestの粒度を意識した形でIssueが作成されるため、後続のコードレビューの負担も軽減されます。 このカスタムコマンドの全体フローは次のようなイメージです。 これら全てのフローを実行するために必要なカスタムコマンドやSkill、Sub Agentを社内Pluginとして開発組織全体に展開しています。 ステップ1: 要件の理解 まずは実現したい要件を生成AIが理解するところから始めます。このステップのフローは次のようなイメージです。 カスタムコマンドを実行して実現したい要件をパラメータ経由で伝えます。この段階では要件がある程度曖昧でも問題ありません。 ❯ /plugin:feature-breakdown 複数ユーザーの新規登録を一括で実行する機能を追加したい ⏺ I'll help you break down the bulk user registration feature into implementation tasks and create GitHub issues. Let me start by creating a TODO list for all phases. ⏺ Phase 1: 要件の理解 初期リクエスト: 複数ユーザーの新規登録を一括で実行する機能を追加したい 要件の中に曖昧な内容があれば生成AIが確認のための質問を投げかけてきます。対話を通じて徐々に要件を明確にしていきます。 今回は追加したい機能を具体的にするために生成AIから幾つかの質問が投げかけられました。解答を選択式にすることで、スムーズに要件を明確化できます。 この機能について、以下の点を明確にさせてください。 ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ← ☐ 対象ユーザー ☐ 入力形式 ☐ 認証フロー ☐ エラー処理 ✔ Submit → この一括登録機能は誰が使うことを想定していますか？ ❯ 1. 管理者（AdminUser）のみが使用 管理画面から管理者が実行する機能として実装。一般ユーザーは使用できない。 2. 組織の管理者（Org内の特定ロール） 組織内の権限を持つユーザーが自組織のメンバーを一括登録できる。 3. 一般ユーザーも使用可能 全ユーザーが利用可能な機能として実装。 4. Type something. 解答を選択式にするためにClaude CodeのToolの AskUserQuestion を利用するようにプロンプトに明記すると便利です。 AskUserQuestion は情報を収集または曖昧さを明確にするために、ユーザーに複数選択肢の質問をします。 一通りの質問に回答すると生成AIが要件を整理してくれます。ここまでの選択で要件を理解することができました。認識にズレがなければこのまま次のステップに進みます。何かしらに誤りがあった場合、この段階で軌道修正もできます。 ⏺ User answered Claude's questions: ⎿ · この一括登録機能は誰が使うことを想定していますか？ → 管理者（AdminUser）のみが使用 · ユーザーデータの入力形式はどのようなものを想定していますか？ → CSV/TSVファイルのアップロード · 登録時のユーザー認証フローはどうしますか？ → 確認メール送信（既存フロー準拠） · 登録処理中のエラーハンドリングはどうしますか？ → 部分成功を許可 ⏺ ありがとうございます。要件を整理します。 ⏺ 理解した要件 機能: 複数ユーザーの新規登録を一括で実行する機能 要件の詳細: - 対象ユーザー: 管理者（AdminUser）のみが使用可能 - 入力形式: CSV/TSVファイルのアップロード（email, name, org_id等のカラム） - 認証フロー: 確認メール送信（既存の単一ユーザー登録フローと同じ） - エラー処理: 部分成功を許可（成功したユーザーは登録、失敗したユーザーはエラーレポートで返す） ステップ2: コードベースの探索 次に、要件を実現させるために既存のコードベースがどうなっているのかを理解する必要があります。 次のようなフローでコードベースを探索していきます。 既存のコードベースを理解するため、 Claude Codeの公式Pluginであるfeature-dev にある code-explorerエージェント を活用します。このエージェントはプロジェクトの構造やパターンを自動的に分析して実装に必要な情報を収集します。feature-devプラグインをインストールするだけでcode-explorerエージェントを利用できるようになります。 要件を分割して複数のcode-explorerエージェントを並列で起動します。各エージェントが特定の観点からコードベースを探索して必要な情報を収集します。 ⏺ Phase 2: コードベースの探索 既存のコードとパターンを理解するため、複数のcode-explorerエージェントを並列で起動します。 Running 3 feature-dev:code-explorer agents… (ctrl+o to expand) ├─ Explore user registration architecture · 12 tool uses · 29.1k tokens │ ⎿ Search: **/models/admin*.py ├─ Explore admin API patterns · 12 tool uses · 27.6k tokens │ ⎿ Read: main.py └─ Explore CSV and file handling · 10 tool uses · 17.0k tokens ⎿ Search: **/api/routes/**/*.py ctrl+b to run in background ⏺ Excellent! Now let me read the critical files identified by the code-explorer agents to deepen my understanding. ⏺ Read(src/api/routes/user/users.py) ⎿ Read 60 lines ⏺ Read(src/api/routes/user/users.py) ⎿ Read 60 lines ⏺ Read(src/api/routes/admin/orgs.py) ⎿ Read 70 lines ⏺ Read(src/api/routes/user/orgs/teams.py) ⎿ Read 60 lines ⏺ Read(src/services/email/email_service.py) ⎿ Read 132 lines 今回は複数のユーザー登録を一括で実行する機能を追加したいので、既存のユーザー登録処理や管理者用APIのパターン、CSVファイルの取り扱い方法などを中心にコードベースを探索しているようです。 要件を実現させるために必要なコードベースの情報が揃ったようなので、次のステップに進みます。 ステップ3: 要件の明確化 次は入力した要件とコードベースの情報を元に、要件を更に明確化していきます。 既存コードと要件を精査して曖昧な内容が残っていれば、追加で質問が投げかけられます。対話を繰り返すことで実装に必要な情報を揃えていきます。 ⏺ Phase 3: 明確化のための質問 コードベースの調査結果から、以下の点について確認させてください。 ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ☐ CSV Columns CSVファイルにはどのような情報を含めますか？ ❯ 1. 必須情報：メール、名前、ロール (Recommended) email, first_name, last_name, roleの4カラム。GitHubアカウントはオプション 2. 必須情報：メールと名前のみ email, first_name, last_nameの3カラム。ロールはデフォルトでmember 3. メールアドレスのみ emailの1カラムだけ。他の情報は後から追加 4. Type something. このステップではエラーハンドリングやエッジケースなど、細かい点についての要件を明確化します。 ⏺ Phase 3: 明確化のための質問 コードベースの調査結果から、以下の点について確認させてください。 ⏺ User answered Claude's questions: ⎿ · CSVファイルにはどのような情報を含めますか？ → 必須情報：メール、名前、ロール (Recommended) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ☐ Duplicate Emails 既存ユーザー（同じメールアドレス）がいた場合、どう処理しますか？ ❯ 1. スキップして結果に記録 (Recommended) 既存ユーザーは登録せず、skipped_emailsリストとして返す 2. エラーとして返す 既存ユーザーがいたらエラー情報を返し、その行を登録しない 3. 情報を更新する 既存ユーザーの名前やロールをCSVの値で更新 4. Type something. ここまでで要件と既存コードの変更内容が明確化されました。次のステップで設計に進みます。 ステップ4: 設計 設計フェーズでは、 Claude Codeの公式Pluginであるfeature-dev にある code-architectエージェント を活用します。 このエージェントは設計方針を提案してくれます。開発者は提案された選択肢の中からプロジェクトに最適な実装方針を選ぶことができます。この選択により実装の方向性が確定します。 設計に関するフローは次のようなイメージになります。 今回は最小構成、クリーンアーキテクチャ、実用的バランスの3つのアプローチでcode-architectエージェントを並行稼働して最適な設計方針を提案してもらいました。 ⏺ Phase 4: アーキテクチャ設計 それでは、3つの異なるアプローチでアーキテクチャ設計を行います。 ⏺ Running 3 feature-dev:code-architect agents… (ctrl+o to expand) ├─ Design minimal change approach · 3 tool uses · 10.1k tokens │ ⎿ Search: send_invite_user_email ├─ Design clean architecture approach · 4 tool uses · 10.1k tokens │ ⎿ Search: src/services/**/*.py └─ Design pragmatic balance approach · 0 tool uses ⎿ Initializing… ctrl+b to run in background ⏺ 3 feature-dev:code-architect agents finished (ctrl+o to expand) ├─ Design minimal change approach · 20 tool uses · 25.2k tokens │ ⎿ Done ├─ Design clean architecture approach · 26 tool uses · 41.0k tokens │ ⎿ Done └─ Design pragmatic balance approach · 0 tool uses ⎿ Done ⏺ Perfect! Now I have three comprehensive architecture designs. Let me present them to the user for selection. ⏺ 3つのアーキテクチャアプローチが完成しました。それぞれの特徴を整理してご提案します。 3つのアプローチ比較 1. 最小変更アプローチ (Minimal Change) 特徴: - CSV処理をルートハンドラに直接実装（約150行の単一ファイル） - 既存パターンを最大限活用（teams.pyの部分成功パターン） - 新規作成ファイル: 2個（エンドポイント + テスト） メリット: - 最速で実装可能（2 PR、~650行） - シンプルで理解しやすい - 既存コードとの整合性が高い デメリット: - ルートハンドラが長くなる（~150行） - CSV処理ロジックの再利用が困難 - 将来の拡張（Excel対応など）に追加実装が必要 タスク数: 2個 --- 2. クリーンアーキテクチャアプローチ (Clean Architecture) 特徴: - サービス層を導入して責務を分離 - Parser（CSV解析） - Validator（バリデーション） - UserImportService（オーケストレーション） - 新規作成ファイル: 7個 メリット: - 将来の拡張が容易（Excel, JSON対応） - テストが容易（各層を独立してテスト可能） - ビジネスロジックの再利用性が高い - 保守性が高い デメリット: - 初期実装に時間がかかる（6 PR、~730行） - 抽象化により複雑さが増す - シンプルなCSV処理に対してはオーバーエンジニアリングの可能性 タスク数: 6個 --- 3. 実用的バランスアプローチ (Pragmatic Balance) 特徴: - サービス層を導入するが、Parser/Validatorは分離しない - UserImportServiceで一元管理 - 新規作成ファイル: 5個 メリット: - 適度な抽象化で保守性を確保 - 実装速度とコード品質のバランスが取れている - 将来の拡張もある程度対応可能 デメリット: - クリーンアーキテクチャほどの柔軟性はない - 最小変更アプローチほどシンプルではない タスク数: 5個 --- ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ☐ Approach どの実装アプローチを採用しますか？ 1. 実用的バランス (Recommended) 開発速度と品質のバランス。サービス層を導入しつつもシンプルさを維持。タスク数: 5個 2. 最小変更 最速で実装。ルートハンドラに直接実装。既存パターンを最大限活用。タスク数: 2個 ❯ 3. クリーンアーキテクチャ 保守性と拡張性を重視。Parser/Validatorを分離し、将来の複数フォーマット対応を考慮。タスク数: 6個 4. Type something. 様々な設計方針ごとにメリット、デメリットなどが提示されます。要件やプロジェクトの方針にもよりますが、今回はクリーンアーキテクチャを選択します。設計方針が決まったので次のタスク分解のステップに進みます。 ステップ5: タスク分解 確定した設計方針を元に実装に必要なタスクを洗い出して分解します。 今回のカスタムコマンドで特に重要なのは、Pull requestやIssueの粒度を考慮することです。今回のカスタムコマンドの調整により、レビューしやすく適切な粒度でマージしやすい最適な粒度に分解してくれます。 Pull requestやIssueの粒度に関するガイドラインはSkillに切り出しています。 Sub AgentやSkillに切り出すことにより、タスク分解の品質を継続的に改善できるだけでなく、カスタムコマンドの一連の流れのコンテキストを適切に管理できるようになります。 今回はクリーンアーキテクチャを選択しており、最初に各種共通処理の作成とリファクタを行い、その後にAPIを追加するというタスクの分け方になっているようです。 ⏺ 承知しました。クリーンアーキテクチャアプローチで進めます。 それでは Phase 5 に進んで、task-breakdown Skillを使ってタスク分解を評価・調整します。 ⏺ Skill(task-breakdown) ⎿ Successfully loaded skill ⏺ Task Breakdown Skillがロードされました。それでは、Phase 4で得たクリーンアーキテクチャアプローチのタスク分解を評価します。 code-architectが提案したタスク分解 以下は、クリーンアーキテクチャアプローチで提案された6つのタスクです： Task 1: [Data] ドメインモデルの追加 - 変更ファイル: - CREATE: src/services/user_import/models.py - CREATE: src/services/user_import/__init__.py - CREATE: tests/services/user_import/test_models.py - 概要: ImportRow, ValidationError, CreatedUser, ImportResult モデルを作成 - 依存関係: なし Task 2: [Logic] CSVパーサーの実装 - 変更ファイル: - CREATE: src/services/user_import/parser.py - MODIFY: src/services/user_import/__init__.py - CREATE: tests/services/user_import/test_parser.py - 概要: CSVParserインターフェースとDefaultCSVParserを実装 - 依存関係: Task 1（ImportRowモデルが必要） Task 3: [Logic] バリデーターの実装 - 変更ファイル: - CREATE: src/services/user_import/validator.py - MODIFY: src/services/user_import/__init__.py - CREATE: tests/services/user_import/test_validator.py - 概要: UserDataValidator（ビジネスルール検証）を実装 - 依存関係: Task 1（ImportRow, ValidationErrorモデルが必要） Task 4: [Logic] ユーザーインポートサービスの実装 - 変更ファイル: - CREATE: src/services/user_import/user_import_service.py - MODIFY: src/services/user_import/__init__.py - CREATE: tests/services/user_import/test_user_import_service.py - 概要: UserImportService（オーケストレーション層）とメール連携 - 依存関係: Task 1, 2, 3（すべてのコンポーネントが必要） Task 5: [API] 管理者用一括登録エンドポイント - 変更ファイル: - CREATE: src/api/routes/admin/user_import.py - MODIFY: main.py - CREATE: tests/api/routes/admin/test_user_import.py - 概要: POST /api/v1/admin/users/import エンドポイントの実装 - 依存関係: Task 1, 2, 3, 4（サービス層全体が必要） --- Task Breakdown Skillによる評価 1. タスクの粒度チェック Task 1: ドメインモデル - ファイル数: 3個 ✅ (理想的) - 行数: ~80行 ✅ (適切) - 評価: 適切なサイズ Task 2: CSVパーサー - ファイル数: 3個 ✅ (理想的) - 行数: ~100行 ✅ (適切) - 評価: 適切なサイズ Task 3: バリデーター - ファイル数: 3個 ✅ (理想的) - 行数: ~120行 ✅ (適切) - 評価: 適切なサイズ Task 4: ユーザーインポートサービス - ファイル数: 3個 ✅ (理想的) - 行数: ~180行 ✅ (適切) - 評価: 許容範囲だが、メール連携部分を分離できる可能性あり Task 5: APIエンドポイント - ファイル数: 3個 ✅ (理想的) - 行数: ~100行 ✅ (適切) - 評価: 適切なサイズ 2. 密結合の識別 ✅ 密結合が適切に保たれているもの: - Task 1: モデル定義 + テスト （実装とテストが同一PR） - Task 2: Parser実装 + テスト （実装とテストが同一PR） - Task 3: Validator実装 + テスト （実装とテストが同一PR） - Task 4: Service実装 + テスト （実装とテストが同一PR） - Task 5: APIエンドポイント + ルーティング + テスト （API完全性が保たれている） ❌ 潜在的な密結合の問題: なし 3. 独立性の検証 独立してrevertできるか？ - Task 1: ✅ 他のタスクに影響なし（モデルのみ） - Task 2: ✅ Task 1に依存するが、独立して削除可能 - Task 3: ✅ Task 1に依存するが、独立して削除可能 - Task 4: ⚠️ Task 2, 3に依存するため、revert時は順序が重要 - Task 5: ✅ Task 4に依存するが、独立して削除可能（ルーター登録を削除するだけ） 各PRマージ後、アプリケーションは正常動作するか？ - Task 1マージ後: ✅ モデルのみ追加、既存機能に影響なし - Task 2マージ後: ✅ パーサーのみ追加、既存機能に影響なし - Task 3マージ後: ✅ バリデーターのみ追加、既存機能に影響なし - Task 4マージ後: ✅ サービス層のみ追加、APIエンドポイントがないため既存機能に影響なし - Task 5マージ後: ✅ 新規エンドポイント追加、既存機能に影響なし 4. 依存関係の整理 Task 1 (モデル) ├── Task 2 (Parser) ← Task 1に依存 └── Task 3 (Validator) ← Task 1に依存 └── Task 4 (Service) ← Task 2, 3に依存 └── Task 5 (API) ← Task 4に依存 並列実装可能なタスク: - Task 2とTask 3は並列実装可能（どちらもTask 1にのみ依存） 5. 推奨事項 現在のタスク分解は非常に良好です。以下の理由から、このまま進めることを推奨します： 良い点: 1. ✅ 各タスクのサイズが適切（3-10ファイル、100-200行） 2. ✅ 実装とテストが密結合として同一PRに含まれている 3. ✅ 各タスクが独立してrevert可能 4. ✅ 依存関係が明確で、並列実装の余地もある 5. ✅ 各PRマージ後もアプリケーションは正常動作する 最終判断: 現在のタスク分解をそのまま採用 --- ここまでで要件を正しい方法と手順で実現するために必要な準備が整いました。最後のステップをこれらを元にIssueを作成していきます。 ステップ6: Issue作成 最後のステップで、分解したタスクを元にGitHubのIssueを自動で作成します。 作成前には確認ステップを踏み、認識がズレていないか最終チェックを行います。問題がなければ、そのままIssueを作成してSub Issueの紐付けとrelationshipの設定まで完了させます。 これにより親Issueと子Issueが適切に構造化された状態で、すぐに実装に取り掛かれるようになります。 GitHubのIssueを作成する処理もSub Agentに切り出しています。Issueを作成するために必要な情報量が多く、すぐにコンテキストが肥大化してしまうからです。 そのためIssue作成専用のSub Agentを用意して必要な情報だけ渡してIssueを作成する形にしています。 ⏺ Phase 7: GitHub Issueの作成 github-issue-creator agentを起動してGitHub issueを作成します。 ⏺ plugin:github-issue-creator(Create GitHub issues) ⎿ Done (25 tool uses · 117.1k tokens · 8m 35s) ⏺ ✅ Feature Breakdown 完了！ GitHub Issueの作成が完了しました。以下が作成されたIssueです。 📋 親Issue #1 - Feature: 複数ユーザーの一括登録機能 https://github.com/Findy/Example/issues/1 📦 子Issue（実装タスク） 1. #2 - [Data] ドメインモデルの追加 + テスト https://github.com/Findy/Example/issues/2 依存関係: なし 2. #3 - [Logic] CSVパーサーの実装 + テスト https://github.com/Findy/Example/issues/3 依存関係: #2 3. #4 - [Logic] バリデーターの実装 + テスト https://github.com/Findy/Example/issues/4 依存関係: #2 4. #5 - [Logic] ユーザーインポートサービスの実装 + テスト https://github.com/Findy/Example/issues/5 依存関係: #2, #3, #4 5. #6 - [API] 管理者用一括登録エンドポイント + テスト https://github.com/Findy/Example/issues/6 依存関係: #5 --- 📊 Issue構造 📋 #1 Feature: 複数ユーザーの一括登録機能 ├── 📦 #2 [Data] ドメインモデルの追加 + テスト │ ├── ⚙️ #3 [Logic] CSVパーサーの実装 + テスト │ └── ⚙️ #4 [Logic] バリデーターの実装 + テスト │ └── ⚙️ #5 [Logic] ユーザーインポートサービスの実装 + テスト │ └── 🔌 #6 [API] 管理者用一括登録エンドポイント + テスト --- 🎯 次のステップ 1. 実装開始: #2から順番に実装してください 2. 並列実装可能: #3と#4は#2完了後、並列で実装可能です 3. 進捗管理: 親Issue #1で全体の進捗を確認できます 4. PRの作成: 各Issueごとに1つのPRを作成してください --- 📝 設計サマリー 採用アーキテクチャ: クリーンアーキテクチャ - Parser層（CSV解析） - Validator層（ビジネスルール検証） - Service層（オーケストレーション） - API層（HTTPハンドリング） 主な技術要素: - CSVパース: Python標準ライブラリ csv.DictReader - バリデーション: Pydantic + カスタムロジック - トランザクション: ユーザー単位のコミット - メール送信: 既存のEmailService再利用 - エラー処理: 部分成功パターン 受入基準: - テストカバレッジ90%以上 - 各PRは3-10ファイル、200-500行の変更 - すべてのPRは独立してrevert可能 Feature Breakdown コマンドの全フェーズが完了しました！ これで要件の策定から適切な粒度でのIssue作成までの一連の流れが完了しました。Issueの内容をチームでレビューして、実装を生成AIに任せましょう。適切な粒度でタスクが分解されているので、Pull requestの粒度も適切になり、レビューの負担が大幅に軽減されます。 カスタムコマンド作成のコツ 様々な開発タスクを効率化するためには必要な情報を用意する必要があります。その結果、コンテキストが肥大化してしまい精度が一気に落ちてしまうことがよくあります。 まずは一通りの流れをカスタムコマンドで作成して、内容やスコープに応じてSkillやSub Agentに切り出していくのが良いです。特定の知識やガイドラインなどはSkillに切り出しましょう。メインのコンテキストには不要で結果のみ必要な情報を扱う場合はSub Agentに切り出すのが良いです。 いかにしてコンテキストを最小限に保つかがコツです。 カスタムコマンドに限らず、 コンテキストが肥大化すると生成AIの精度は一気に落ちてしまいます。 必要な情報だけを適切に渡して維持し続けることが、生成AIを活用する上で非常に重要です。 まとめ 今回紹介したカスタムコマンドは、誰でも高品質で適切な粒度のAIフレンドリーなIssueを作成できるようにするものです。 生成AIを活用した開発では、生成AIが理解しやすい形で要件と設計を伝えることが重要です。要件定義から設計、タスク分解、Issue作成までのフローを自動化することで、開発者はより本質的な開発業務に集中できるようになります。生成AIとの協業による開発スタイルは、今後ますます重要になっていくでしょう。 最後になりますが、このたび 2026年2月18日(水)にFindy AI Meetup in Fukuoka #4の開催が決定 しました！ findy-inc.connpass.com 会場へのアクセスは天神駅から徒歩3分となっています。またTVCM公開記念ノベルティや、イベント後半には懇親タイムもご用意しています。 申込みの先着順となっておりますので、気になっている方は早めにお申し込みいただくことをおすすめします。生成AIの活用事例に興味のある方は奮ってご参加ください！ みなさんにお会いできることを楽しみにしています！ 採用情報 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから。 herp.careers