Findy AI Meetup in Fukuoka #5 を開催しました — AI時代のエンジニア育成

こんにちは。ファインディ株式会社でテックリードマネージャーをしている戸田です。

2026年4月15日に、Findy AI Meetup in Fukuoka #5を福岡で開催しました。

今回のテーマは「AI×育成 AI時代のエンジニア育成」です。

この記事では、当日の登壇内容を振り返りながら、生成AI時代におけるエンジニア育成で私たちが直面した課題と、そこから見えてきた「変わらない大切なこと」を紹介します。

https://findy-inc.connpass.com/event/383906/findy-inc.connpass.com

当日参加くださったみなさま、ありがとうございました！

Findy AI Meetup in Fukuokaについて

Findy AI Meetupは、ファインディのエンジニアが主催する技術系オフラインイベントです。

生成AIやAIエージェントの活用を通じた開発生産性の向上をテーマに、社内での実践事例の紹介やエンジニア同士の交流を目的としています。

福岡での開催は今回で5回目となりました。回を重ねるごとに参加者同士の顔なじみも増え、福岡のエンジニアコミュニティとして根付いてきたことを実感しています。

登壇内容

新メンバーのために、シニアエンジニアが環境を作る時代

1つ目の登壇は、フロントエンドエンジニア/テックリードの新福が担当しました。

エンジニア以外のメンバーがPull requestを作るようになった

生成AIの普及により、エンジニア以外のメンバーでもコードを書けるようになりました。

ファインディでは、デザイナーがClaude Codeを使ってUIドキュメントを作成したり、PdMがCursorでモックを作成するといった事例を確認しています。

直近では、エンジニアがBizメンバー向けにNotion MCPを用いた求人票改善ツールを開発しました。

tech.findy.co.jp

実はこの話にはまだ続きがあります。しばらくすると、今度はBizメンバーが自分でプロンプトを修正し、エンジニアにPull requestを送るようになったのです。

コミットやPull requestの作り方を誰かに教わったわけではありません。AIチャットに聞きながら操作し、Pull requestを作り上げていました。AIチャットが開発の入口となる時代、その波は既にエンジニア以外のメンバーにも届いています。

Pull requestの品質が課題に

一方で、コミットメッセージのフォーマットや命名規則など、開発ルールを知らないまま作られたPull requestには品質面での課題がありました。レビュアーの負担が増え、指摘のたびに手戻りが発生するような事態は避けたいです。

この解決策としては、エージェントスキルの整備が有効と考えられます。

AIチャットから自然言語でエージェントスキルを呼び出すだけで、誰でも開発ルールに準拠したPull requestを作成できます。

AI時代のシニアエンジニアができること

シニアエンジニアはこれまで、知識を言語化して伝えること、コードレビューによる品質担保、ペアプロでの指導といった形で、チームの品質と成長を支えてきました。

これらの役割は引き続き重要ですが、AI時代はそれに加えてカスタムインストラクションやエージェントスキルの整備などもシニアエンジニアの仕事になると思われます。

誰でも参加できる仕組みを作ることは、教える相手を選ばない育成インフラの構築につながります。入社1週目の新メンバーが初日からコントリビューションを体験し、「何を作りたいか」に集中できる環境を整えること——それがAI時代のシニアエンジニアの新しい役割となるかもしれません。

生成AI時代のエンジニア育成 — 変わる時代と変わらないコト

次にテックリードマネージャーの戸田が担当しました。

生成AIでコードの作り方が変わった

生成AIの登場によって、開発の進め方は大きく変わりました。「調べる→試す」だったプロセスが「AIに聞く→コピペ」に変わり、詰まる時間は激減しました。

基本的な知識がなくても動くコードが手軽に出せるようになった一方で、公式ドキュメントよりAIへの問い合わせが先になりがちで、「なぜ動くのか」を知らずに実装する機会が増えていました。

現場で起きた逆説

AI導入後、シニアエンジニアのアウトプット量は増えていました。しかし若手エンジニアについては逆の現象が起きていました。

Pull requestの質が落ち、AIが出力したコードを理解せずにレビュー依頼を出すケースが増えたのです。その結果レビューコメントが増え、レビュー負担が上昇し、リードタイムは悪化していました。

トータルで見ると、チーム全体の生産性はさほど変わっていなかったのです。「AIで効率化できた」という実感とのギャップがそこにはありました。

AIに「使われる」のではなく「使う」

この状況を整理すると、若手エンジニアの一部はAIに「使われている」状態でした。

AIが出力したコードが正しいかどうかを判断できず、間違いに気づかないままレビューを依頼する。ハルシネーションを見抜けず、誤った実装をしてしまう。AIに正しい指示を出せないから「作ってください」としか言えず、意図と異なるコードが出てくる。

「使う」状態はその逆です。自分の意図に沿ってAIを動かせる。正誤を判断できるから間違いをその場で弾ける。正しい指示が出せるから意図通りの出力が得られる。

この違いを分けるのは、エンジニアとしての基礎力です。

基礎知識がなければ、正誤判定も正しい指示もできません。動くものを作るレベルは「AIに使われている」状態であり、正しい方法と手順で作るレベルが「AIを使う」状態です。

原点回帰 — 基礎力の価値が上がっている

生成AI時代だからこそ、基礎力の価値はむしろ上がっています。基礎知識、座学、資格取得といった、一見すると地味な取り組みが重要性を増しているのです。

ファインディでは、基本情報技術者試験相当以上の資格を取得することを推奨しています。広く浅い基礎知識を体系的に習得できるという点で、コスパもタイパも高い学習方法です。合格した場合は受験料を会社が負担する制度も用意しています。

基礎力がつくとAIの出力に対する正誤判定の質とスピードが上がり、レビュー前のセルフチェックで問題を潰せるようになります。ハルシネーションを見抜けるようになり、「何かおかしい」と気づける感覚が身に付きます。

さらに、AIに正しい方法と手順で指示を出せるようになるため、レビューでの議論が設計やパフォーマンス、UI/UXといった本質的な内容になります。

今回の登壇と資料が皆さんの参考になると幸いです。

■ 明日から試せるアクション ■

明日から試せるアクション

登壇内容を踏まえて、明日から実践できることを整理しました。

AIの出力を必ず検証する習慣をつける

AIが生成したコードをそのままコピペするのではなく、「このコードは何をしているか」「なぜこの実装なのか」を自分の言葉で説明できるか確認してからレビューに出しましょう。説明できないコードはレビューに出すべきではありません。

基礎知識を体系的にインプットする

基本情報技術者試験の教材は、ネットワーク、データベース、セキュリティ、アルゴリズムなど、開発の土台となる知識を広くカバーしています。資格取得そのものが目的ではなく、AIの出力を正しく評価するための「物差し」を手に入れることが目的です。

「AIに聞く前に公式ドキュメントを読む」時間を意識的に作る

すべてをAI経由にするのではなく、まず公式ドキュメントで基本を理解したうえでAIを活用する、という順序を意識するだけで、コードの理解度は大きく変わります。

チームの開発ルールをエージェントスキルやカスタムインストラクションに落とし込む

シニアエンジニアが持つ暗黙知を仕組みとして整備することで、新メンバーやエンジニア以外のメンバーでも開発ルールに準拠したPull requestを作れるようになります。「教える」から「仕組みで支える」への転換です。

まとめ

今回のFindy AI Meetup in Fukuoka #5では、AI時代のエンジニア育成というテーマで2つの登壇を行いました。

登壇を通じて伝えたかったのは、AI時代で環境は大きく変わったが、変わらないこともあるということです。

手を動かし、汗をかき、積み重ねた基礎と経験は絶対に裏切りません。同時に、シニアエンジニアがエージェントスキルやカスタムインストラクションといった仕組みを整備し、誰でも開発に参加できる環境を作ることも重要です。

AI時代だからこその原点回帰として、エンジニアとしての基礎力を鍛えていきましょう。

Findy AI Meetup in Fukuokaは今後も継続して開催していきます。福岡のエンジニアの皆さんとオフラインでつながれるこの場を、これからも大切にしていきたいと思っています。

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

herp.careers

フロー効率よりAIのポテンシャルを！開発プロセスを「個人アサイン」にシフトした理由

こんにちは！ファインディでプロダクト開発部のVPoEをしている浜田です。

AI駆動開発が浸透するなかで、エンジニア1人あたりの開発能力は大きく向上しています。しかし、従来のチーム単位のアサイン方式のままでは、そのポテンシャルを十分に引き出せていないと感じていました。 この記事では、私たちが開発プロセスを「チーム単位」から「個人単位」のアサインへ移行した背景と、その結果得られた変化について紹介します。AI駆動開発を取り入れたものの、チームの開発プロセスをどう変えるべきか悩んでいる方に向けた内容です。

これまでの開発プロセス

ファインディのプロダクト開発部には複数の開発チームがあり、それぞれ5名前後のエンジニアにPdMとデザイナーを加えた構成で、協働しながらプロダクト開発を進めています。

これまでの開発プロセスでは、施策開発をチームにアサインし、メンバーそれぞれが優先度の高いタスクをフレキシブルに取っていくスタイルで運用していました。1つの施策開発をチームにアサインすると、結果的に4名程度のエンジニアが集中して取り組み、一気に開発を完了させるという進め方です。いわばフロー効率を重視した開発スタイルで、最も優先度の高い施策を最速で完了させることに注力していました。

この方式はチームの連携が生まれやすく、うまく機能していました。複数人が同じ施策に取り組むことで、設計の議論がその場で生まれたり、実装中に詰まったときもすぐに相談できたりと、チームで動くからこその強みがありました。

AI駆動開発で見えてきた課題

AI駆動開発の導入により、エンジニア1人が同時に扱える開発量は増えました。タスク分解をおこなって依存関係さえ明確にできれば、かなりの数のタスクをAIエージェントに渡して並列で進めることが可能です。加えて、これまではキャッチアップに時間がかかっていたような、自身の習熟度が低い技術スタックの部分であっても、AIをパートナーにして自力で開発を進められるようになりました。

しかし、フロー効率を重視した従来のスタイルでは、このAIのポテンシャルを十分に引き出せませんでした。複数のエンジニアで1つの施策を分担している状態では、一人ひとりが持つタスクの粒度はすでに細かくなっています。そこからさらにタスクを分解して複数のAIエージェントに並列で任せるのは難しく、AIの役割はあくまで副操縦士としての補助にとどまっていました。

加えて、タスクのアサインを明確に決めず、手が空いた人から優先度の高いタスクを取っていくスタイルでは、自分がこの先どのタスクを担当するかが見通せません。先の計画が立たない以上、AIエージェントに先回りしてタスクを渡して並列で進めてもらうこともできず、結局は目の前の1つのタスクをAIと一緒にこなすだけになってしまいます。

個人アサイン方式への移行

そこで、施策開発を個々のエンジニアにまるごとアサインする方式へと切り替えました。

1人が施策全体を担当することで、タスクの分解と計画を自分の裁量で行えるようになります。どの部分をAIエージェントに並列で任せ、どの部分を自分で手を動かすかを事前に整理できるので、AIを副操縦士ではなく、複数の作業を同時に進めるパートナーとして活用できるようになりました。

具体的には、Claude Codeのような自律型エージェントを用いて複数のワーカーを立ち上げます。そして、あるコンポーネントの実装やテストコード生成をそれらに並列で進めさせながら、自身は全体の設計やオーケストレーションに集中する、といった働き方です。 この「1人のエンジニアが複数のAIエージェントを指揮する」具体的なワークフローについては、以下の記事で詳しく解説していますので、あわせてご覧ください。

tech.findy.co.jp

フロー効率を重視していた頃と比べると、最も優先度の高い施策が完了するまでの速度は低下します。4名で集中して取り組んでいたものを1名で担当するのですから、これは当然のトレードオフです。しかし、エンジニア間のコミュニケーションコストが減ることや、AIによるアウトプット量と速度の向上により、大きく低下させることなく開発を進められています。さらに、2番目、3番目に優先度の高い施策も別のエンジニアが並行して開発を進めるため、個々の施策にかかる期間が延びても、結果としてより多くの施策を素早くリリースできるようになりました。

実際に、この変化は定量的な指標にも明確に表れています。以下のグラフは紹介した変更を行なった開発チームのPR（プルリクエスト）作成数の推移ですが、個人アサインへの移行を本格的に進めた2026年2月中旬以降、PR数が明確に一段増えていることがわかります。個人のポテンシャルを引き出すアプローチが、開発チーム全体のアウトプット最大化に繋がった形です。

一方で、チーム全体のまとまりという意味では変化がありました。これまでのように全員で1つの開発に集中する場面は減り、どちらかというと個々の集まりに近い形になっています。

ただし、チームとしての連携を完全に手放したわけではありません。たとえば設計の方針に関わる判断は、個人で抱えずチームで議論してから進めるようにしていますし、実装についても「属人化」を防ぐためにプルリクエストをこまめに分割してレビューし合うプロセスを維持しています。さらに、各自が何に取り組んでいるかを定期的に共有する場を設けることで、お互いの状況が見えなくなることも避けています。つまり、チームとしての協働がなくなったのではなく、その関わり方が変わったというのが正確な表現です。

個人のオーナーシップを高める

AI時代だからこそ、個人を目立たせることが重要だと考えています。

チームの一員として開発に参加するだけでは、個々のエンジニアの貢献が見えにくくなります。極端に言えば、AIに代替されやすいポジションになってしまう可能性もあります。個人がオーナーシップを持ち、「これは自分がやった」と自信を持って言える状態をつくることが、エンジニアとしての価値を高めることにつながると思っています。

個人アサインに移行したことで、各エンジニアが担当する施策に対して当事者意識を持って取り組むようになりました。設計の意思決定からリリースまでを一貫して担うことで、施策全体を自分ごととして捉える姿勢が自然と生まれています。また、チームで開発していた頃はどうしても窓口がチームリーダーに集中しがちでしたが、施策ごとに個人をアサインしているため、メンバーそれぞれがPdMや事業メンバーと直接やりとりをおこなうようになりました。その結果、施策の背景やリリース後の効果に対する意識が上がるなど、良い効果が出ています。

これはマネジメントの観点からも好ましい変化でした。誰がどの施策を推進しているかが明確になるので、成果の可視化にもつながります。チームの中で埋もれるのではなく、一人ひとりの仕事が見える状態をつくることが、エンジニアのモチベーションにもよい影響を与えていると感じています。

技術改善が進みやすくなった

個人アサインに切り替えたことで生まれたもう1つの変化として、技術的な改善が進みやすくなったことがあります。

チーム全体で施策開発に集中していた頃は、技術改善やリファクタリングはどうしても後回しになりがちでした。個人にアサインされる形になったことで、自分の裁量で改善タスクを差し込みやすくなりました。実際に、以前はなかなか手がつけられなかったライブラリのアップデートやテストの整備といった地道な改善が、各エンジニアの判断で着実に進むようになっています。

チームとしてもリソース配分を明確にしました。施策開発、改善、その他の割合を7:2:1と定めたことで、「2割のリソースは技術改善に使おう」という共通認識が生まれ、改善活動に取り組みやすい環境が整っています。

まとめ

フロー効率を重視したチーム開発から、AIのポテンシャルを引き出す個人アサインへと開発プロセスを移行しました。個々の施策が完了するまでの速度は下がるものの、AIエージェントを活用した並列開発によってチーム全体のアウトプットはむしろ増加し、実際にPR数にもその変化が表れています。加えて、個人のオーナーシップが高まり、技術改善にも手が回るようになりました。

チームのまとまりが薄れるリスクはありますが、設計判断の議論やレビューといった連携ポイントを意識的に残すことでバランスを取っています。AI駆動開発を推進するなかで開発プロセスの見直しを検討している方の参考になれば幸いです。

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

herp.careers

"AIツール入れたけど効果あるの？"に数字で答える——Findy AI+の分析ワークフロー実践ガイド

こんにちは。

ファインディ株式会社でFindy AI+の開発をしているdanです。

Findy AI+は、AIツールを導入したけれど、実際にどれくらい効果があるのかという問いに対して定量的に答えるための分析ワークフローを新たにリリースしました。

今回は、これらのワークフローを使って実際にどのような示唆を得られるのかについて実践形式で紹介します。AIツールを導入したものの効果が見えづらいと感じているEMやPdM、チームの活用状況を把握したいエンジニアの方に向けて、MCPサーバーとGitHub Actionsそれぞれでの実行手順と、分析結果からチームの改善ポイントを見つけるまでの流れを紹介します。

Findy AI+とは

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

人と生成AIの協働を後押しし、開発組織の変革をサポートします。

Claude Code、GitHub Copilot、Codex、Devinなど様々なAIツールの利活用を横断的に分析しています。

今回リリースされた分析ワークフローはMCPサーバー・GitHub Actionsの両方に対応しており、定期的に開発組織の状態について改善サイクルを回せる仕組みをサポートしています。

開発チームで分析してみた

ファインディのある開発チームで分析してみました。 分析ワークフローは7種類ありますが、今回はそのうち2つをMCPサーバー経由、GitHub Actions経由の両方で実行しています。

AI環境整備コミット履歴分析（MCPサーバー経由）

AI設定ファイルへの貢献者を分析することができます。コミッター統計、PR作成者統計、ファイル別の分析結果が表示されるため、有識者の把握やナレッジ共有のきっかけにすることができます。

MCPサーバー経由の分析は、VS Codeを使用していればChatからスラッシュコマンドを実行するだけで始められます。

コマンドを実行すると、対話形式でリポジトリ名・開始日・終了日の3つのパラメータを順番に入力していきます。

次のようなプロンプトで分析を依頼できます。

以下の条件でAI設定ファイルへの貢献を分析してください：

【分析対象】
- リポジトリ: Repository-A
- 期間: 2025-10-01から2026-02-28

【分析観点】
- AIツールの設定に最も貢献しているメンバーの特定
- 設定ファイルごとのメンテナンス状況
- 貢献パターンや傾向の洞察

パラメータの入力が完了すると、MCPサーバーへのツール実行許可を求められます。内容を確認して許可すると、分析が開始されます。

MCPサーバーのツール実行結果です。

Ran AI Configuration File Contributions

Input
{
  "repository": "Repository-A",
  "date_from": "2025-10-01",
  "date_to": "2026-02-28"
}

Output
# AI環境整備コミット履歴分析レポート

**リポジトリ**: Org/Repository-A
**分析期間**: 2025-10-01 〜 2026-02-28
**分析実行日**: 2026年03月26日

## 🎯 論点別サマリ

### 論点1: 誰がAI活用環境整備に貢献しているか？上位は誰か？

**回答**: user1が圧倒的な貢献者で全体の73.5%を占める。次いでuser2が20.6%、user3とuser4が少数貢献。

**インサイト**: user1が中心的役割を担い、特に2025年12月に集中的なリファクタリングと拡充を実施。user2は初期構築とCI整備に貢献。

### 論点2: 最後に最新化されたのはいつか？更新が古すぎないか？

**回答**: 最終更新は2026-01-21で約2ヶ月前。月平均7.0コミットで継続的に更新されているが、直近2ヶ月は停滞気味。

**インサイト**: 2025年12月に大規模な整備が完了後、更新が減少。定期的なメンテナンスサイクルの確立が望ましい。

## 1. 貢献パターン分析

**インサイト**: user1は.claude/context/配下の構造化に注力（11コミット）し、アーキテクチャ設計を主導。user2はCI/CDとエージェント初期設定に特化。役割分担が明確。

---

📊 貢献者別コミット割合
user1  ███████████████░░░░░ 73.5% (25件)
user2  ████░░░░░░░░░░░░░░░░ 20.6%  (7件)
user3  █░░░░░░░░░░░░░░░░░░░  5.9%  (2件)
user4  █░░░░░░░░░░░░░░░░░░░  2.9%  (1件)

分析が完了すると、次のようなレポートが出力されます。トップコントリビューターの一覧、設定ファイル別のメンテナンス状況、月別コミット推移などが可視化されており、誰がいつどのファイルを整備したのかが一目で分かります。

一部出力内容ですが、出力データをもとに、メンテナンス状況と貢献パターンのサマリーも整理されます。

## AI設定ファイル貢献分析レポート

**リポジトリ**: Org/Repository-A | **期間**: 2025-10-01 〜 2026-02-28

### 1. 設定ファイルごとのメンテナンス状況

| ファイル/ディレクトリ | 最終更新 | 主要メンテナー | 状態 |
|----------------------|---------|---------------|------|
| CLAUDE.md | 2025-12-10 | user1 | 約3.5ヶ月未更新 |
| settings.json | 2026-01-14 | user1 | 約2ヶ月未更新 |
| .claude/context/ | 2025-12-09 | user1 | 約3.5ヶ月未更新 |
| .claude/agents/ | 2025-12-16 | user1, user2, user3 | 約3ヶ月未更新 |

### 2. 貢献パターンと傾向

**時系列の傾向**:
- **2025年10月**: user2による初期構築フェーズ（Claude Codeエージェント設定、PR作成エージェント）
- **2025年11月**: user1がCI/CD軽量化から参入
- **2025年12月**: **最も活発な月（23コミット）** — user1による`.claude/context/`への大規模分割、Copilot設定統合、@記法導入。user2によるセキュリティ関連整備も同時進行
- **2026年1月**: 2件のみ。整備完了後の安定期に入った可能性
- **2026年2月**: コミットなし

**役割分担**:
- **user1**: アーキテクチャ設計・構造化のリード（context分割、設定統合）
- **user2**: 初期設計とCI/CDセキュリティ強化
- **user3 / user4**: セットアップガイドやドキュメント補完のスポット貢献

**推奨アクション**:
- 主要設定ファイル（CLAUDE.md、copilot-instructions.md）が3ヶ月以上未更新のため、プロジェクトの現状と乖離がないか定期的なレビューサイクルの確立が望ましい
- 貢献者がuser1に集中しているため、バス係数（Bus Factor）の観点からナレッジ共有の促進も検討すべき

AIと人のPR作成量比率分析（GitHub Actions経由）

AIに任せられる可能性がある業務領域を特定し、最適な分担を提案することができます。メンバー別AI活用率やPR作成量の偏在度を確認できるので、新機能開発と運用開発の分担を考え直すきっかけ作りにつながります。

GitHub Actionsでの分析は、リポジトリのActionsタブから手動実行できます。対象リポジトリ名と分析期間を入力して「Run workflow」を押すだけです。

分析が完了すると、結果のサマリーがSlackに自動通知されます。チームメンバー全員がすぐに結果を確認でき、定期実行と組み合わせることで月次の振り返りにも活用できます。

結果はGitHub Issueとしても自動作成されているので、Slack通知内のリンクから遷移できます。構造化されたレポートが作成され、チーム内での共有や議論をする親Issueとしても活用できます。

詳しいセットアップ方法はGitHub Actionsでの分析セットアップガイドをご覧ください。

Findy AI+の分析ワークフローについて

ここまで紹介してきた分析は、Findy AI+が新たに提供を開始した分析ワークフローを使って実行したものです。ここからは、ワークフローの全体像と活用方法を紹介します。

分析ワークフローでできること

今回のリリースでは、次の7種類の分析ワークフローを提供しています。

ワークフロー	できること
Agent Environment Analysis	AI向け指示ファイル・フォルダをスコア化し、自走環境の整備度合いを診断
PR Reviews Analysis	コード変更者・開発環境の伸びしろを特定し、改善施策を提案
PR Productivity Analysis	AI活用によるアウトプット量の変化や機能開発への影響を分析
AI-Human Collaboration Analysis	AIに任せられる業務領域を特定し、最適な分担を提案
Multi AI Cost Comparison	複数AIツールのROIを人件費対比で算出
PR Type Summary	PRの作業種別ごとにサマリーを生成
Findy AI+ PR Review	PRオープン時にAIレビューを自動実行し、結果をコメント投稿

これらはMCPサーバー・GitHub Actionsの両方からご利用いただけます。

GitHub Actionsで分析を自動化

GitHub Actionsを使えば、上記の分析をリポジトリから定期実行できます。デフォルトでは毎月1日にスケジュール実行される設定になっており、頻度はカスタマイズ可能です。GitHub Web UIやCLIからの手動実行にも対応しています。

分析結果はSlackチャンネルに自動通知されるため、チーム全体で定期的に確認し改善サイクルを回す運用が実現できます。チーム単位での分析にも対応しているので、組織全体だけでなくチームごとの傾向把握も可能です。

気になるポイントをさっと確認したいときはMCPサーバー、じっくり深堀りしたいときはGitHub Actionsという使い分けがおすすめです。

おわりに

今回は、Findy AI+の分析ワークフローを使って、ある開発チームのAI活用状況を約1年にわたって追いかけてみました。

AI環境整備コミット履歴分析では、誰がAI設定を整備しているのか、どのファイルがどの時期に集中的に更新されたのかが見えてきました。AIと人のPR作成量比率分析では、AI活用率の推移やメンバー間の活用度の差が可視化されました。こうした数字があることで、「なんとなくAIを使っている」という感覚ではなく、具体的にどこに課題があり、何を改善すべきかを議論できるようになります。

AIツールを導入したものの効果が見えづらいと感じている方は、まず自分たちのチームの現状を可視化するところから始めてみてください。データがあれば、次の一手が見えてきます。

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

基本情報技術者試験をスキル棚卸しに使う - 45歳エンジニアが発見した意外な盲点

キャリアプロダクト開発部の森 ＠jiskanulo です。

私ごとですが今年で45歳、WEBサービスの開発歴は20年以上になります。世間的にはベテランエンジニアとかシニアエンジニアとかと称される類だと自認しています。

そんな私ですが2026年1月に基本情報技術者試験を受験して合格しました。 この記事は、ベテランエンジニアが基本情報技術者試験をスキル棚卸しツールとして活用した体験と、受験しなくても使えるセルフチェックの方法を紹介します。

www.ipa.go.jp

受験の動機

受験したきっかけは昨今の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

【エンジニアの日常】エンジニア達の人生を変えた一冊 Part6

こんにちは。Findy AI+開発チームのdanです。

この記事は「エンジニア達の人生を変えた一冊」として、ファインディのエンジニアが人生を変えた本を紹介していくシリーズです。

一冊の技術書がきっかけで、新しい分野に足を踏み入れたり、日々のコードの書き方が変わったりした経験はありませんか？今回は私・danと、千田さんの2名が、自分にとって転機となった本をお届けします。

それでは、さっそく紹介していきましょう！

■ dan / エンジニア ■

普段はFindy AI+でバックエンド・フロントエンドの開発をしているdanです。若干Terraformデビューをしました。

SREの知識地図——基礎知識から現場での実践まで

SREの知識地図——基礎知識から現場での実践まで

私が紹介する「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・エージェント開発から読み解く　コンテキストエンジニアリング エンジニア選書

Findy AI+ではLLMが分析したものをサービスに取り入れています。現在、機能が増えていく中で分析の精度がネックになっており、プロンプトの調整に課題を感じています。

この本ではLLMがどのように解釈して分析をしているのか、なにをさせてはいけないのかなども書かれており、サービスのためのキャッチアップ以外では、現在のAI駆動開発にも活かせる本なのではないかと思っています。

続いては、キャリアプロダクト開発部 転職開発チームの千田さんです。千田さんが選んだのは、多くのエンジニアにとってバイブルともいえるあの一冊。「良いコードとは何か」を考えるきっかけをくれた本について語ってもらいました。

■ 千田 / エンジニア ■

キャリアプロダクト開発部 転職開発チームの千田です。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

私が紹介する「リーダブルコード」は、コードの読みやすさに焦点を当てた実践的な書籍です。

この本を読んだきっかけ

新人エンジニアとして働き始めたとき、「正しいコードの書き方」がわからなくて悩んでいました。動くコードは書けるけれど、それが良いコードなのか自信が持てない。レビューで指摘されても、なぜそう書くべきなのか腑に落ちないことがありました。

そんなときに出会ったのがこの本です。エンジニアの間で定番書として名前を聞くことが多く、まずはここから始めてみようと手に取りました。

本の内容

本書は「コードは他の人が最短時間で理解できるように書かなければいけない」という原則のもと、変数名の付け方、コメントの書き方、条件分岐の整理、式の分割といったテーマを13章にわたって解説しています。

Before/Afterのコード例が豊富に載っていて、「読みやすいコードとは何か」を実践的に説明してくれます。

コードレビューのとき、なんとなく「こっちのほうがいいと思う」とは感じるのに、言葉にできない。そういう経験を持っている方は多いのではないでしょうか。この本を読むと、「なぜ読みやすいと感じるのか」を論理的に説明できるようになります。

この本から影響を受けた点/学んだ点

一番大きかったのは、コードを書く上での自信が生まれたことです。

本書を読む前は、レビューで「こう直したほうがいい」と言われても、それが一般的なルールなのか、その人の好みなのか区別がつきませんでした。本書は「理解するまでにかかる時間」を短くするという明確な判断軸を示してくれます。

この軸を手に入れたことで、「なぜこう書いたのか」を自分の言葉で説明できるようになりました。

例えば、1行に詰め込んだ複雑な式よりも2行に分けたほうが理解しやすいケースがある。短いコードこそ良いコードだと思い込んでいた当時の自分にとって、コードの良し悪しは行数ではなく読み手の理解コストで決まるという考え方は新鮮でした。

特に印象に残った部分

2つあります。

ひとつはコメントについての章です。新人の頃はコメントをどこに書けばいいのかわからず、結局ほとんど書いていませんでした。本書では「コードからすぐにわかることをコメントに書かない」としつつ、設計意図やコードの欠陥など「監督のコメンタリー」としてのコメントは積極的に書くべきだと述べています。

コメントを書くか書かないかではなく、「読み手にとって新しい情報を提供するか」で判断する。この基準を知ったことで、コメントを書く場面と書かない場面の区別がつくようになりました。

もうひとつは、説明変数と要約変数の考え方です。本書では、複雑な式や繰り返し登場する条件を変数に切り出すことで、コードの意図を明確にする手法が紹介されています。

例えばrequest.user.id == document.owner_idという式は、要素が多くて読み解くのに少し時間がかかります。でもこれをuser_owns_documentという変数に置き換えると、コードが伝えたいことは「ユーザーがこの文書の所有者かどうか」だとすぐにわかる。式が「何をしているか」ではなく「何を意味しているか」を伝えるようになるわけです。

この考え方を知ってから、条件分岐やif文の中に長い式をそのまま書くことに違和感を覚えるようになりました。変数名をつけるという小さな工夫が、コード全体の読みやすさに大きく影響することを教えてくれた例でした。

このような方におすすめ

コードを書き始めたものの、何が良いコードなのかわからないという方にはぴったりの一冊です。設計パターンやアーキテクチャのような大きな話ではなく、日々のコーディングですぐに実践できる内容が詰まっています。

また、経験を積んだエンジニアにとっても、普段無意識にやっていることを言語化し直すきっかけになると思います。レビューで「なんとなくこっちのほうがいい」としか言えなかった感覚に、言葉を与えてくれる本です。

おわりに

SREの全体像をつかむための入門書と、日々のコーディングを支える定番書。今回の2冊は方向性こそ異なりますが、私はSLOとエラーバジェットという定量的な視点を、千田さんは「読み手の理解コスト」というコードの良し悪しを測る基準を、それぞれ本から得ていました。

判断軸があると、迷ったときに立ち返る場所ができる。技術書との出会いがそういうきっかけになることを、少しでもお伝えできていれば嬉しいです。

ファインディでは一緒に働くメンバーを募集しています。少しでも興味を持っていただけた方は、ぜひこちらをご覧ください！

Git worktreeの運用をスキルに委ねる ―複雑さを隠蔽するClaude Codeスキル設計の実践―

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

ファインディでは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とは

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行に集約されます。裏側では次の処理が自動で実行されています。

1. メインリポジトリのパスを記録
2. EnterWorktreeで.claude/worktrees/feature-add-auth/にworktreeを作成
3. セッションの作業ディレクトリを自動で切り替え
4. .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を作成します。

1. GitHub Issueを取得
2. git-worktreeスキルでworktreeを作成 ← ここで活用
3. Issueの内容に基づいて実装
4. Pull requestを作成
5. 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

1時間を5分に短縮！Claude Code × Notion MCPで実現した業務自動化の全貌

こんにちは。ファインディ株式会社でエンジニアをしている山岸です。

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で自動化したい方の参考になれば幸いです。

求人票作成の業務フロー

まず、求人票がどのように作られているかを説明します。

bizメンバーが企業との商談でヒアリングした内容をもとに、Findy側でFindy AI Career向けの求人票を作成・掲載しています。具体的なフローは次のとおりです。

1. 求人票のURL・詳細情報を取得
2. 商談にてAI記述部分をはじめとする詳細情報をヒアリング
3. Notionの企業情報・商談ログやFindy AI Career上に掲載している既存求人、Web上のAI関連記事を統合してClaude（Web版）でドラフト作成
4. Google Docにドラフトをコピペし、企業とGoogle Doc上で内容を推敲
5. ドラフト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