AI活用を推進するためにファインディが下した、1つの小さな決断

こんにちは。

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

「AI活用を推進したいが、思うように進まない」──この悩みを抱えているエンジニアの方は、少なくないのではないでしょうか。

ファインディも例外ではありませんでした。2025年の上半期までは、普段の業務をやりつつ片手間でAIのキャッチアップや社内展開を進めていました。

今回は、そこから潮目が変わるきっかけとなった決断と、その後1人あたりのプルリクエスト作成数が前年比で約1.5倍になるまでの過程を紹介します。

同じようにAI活用の推進に手応えのなさを感じている方の参考になれば幸いです。

片手間で追いかける限界

2025年の上半期まで、ファインディの開発組織では興味と意欲のあるエンジニアが、普段のプロダクト開発と並行して、最新の動向をキャッチアップし、使えそうなツールを社内で共有していました。いわゆる"片手間"で進めるスタイルです。

最初のうちは、これでも回っていました。しかし、次第にこのやり方では追いつかなくなっていきました。

理由は単純で、AIのアップデートが多すぎたからです。

ほぼ毎日のようにアップデートが公開され、新しいエージェントや機能が登場する。上半期の半ばあたりから、キャッチアップに充てる時間がどうしても足りないという感覚が強くなっていきました。

努力で巻き返せるレベルの遅れではなく、物量的に両立が不可能な状態に近づいていました。

1つの小さな決断

この状況を動かすために取った1つの決断が、「AI推進だけを専任で担うポジションを作る」というものでした。

その人を普段のプロダクト開発業務から外し、AI推進そのものを業務にする。兼務で時間を増やすのではなく、業務から外して全振りするという発想への切り替えが、このポジションの本質です。

この判断の背景には、「全員が業務の10%をAI推進に充てるよりも、1人が100%を充てたほうが組織としての前進量は大きい」という確信がありました。

兼務スタイルで各自が少しずつ動く形では、日々のAIアップデートの速度には追いつかない。仮に追いついたとしても、それらを使ってアウトカムを出せるまでが遠すぎました。一方、1人が専任で全力でコミットできれば、情報の集約・検証・社内展開を最速のスピードで回せると判断しました。

AI推進ポジションのエンジニアの仕事は、AI活用と組織への展開そのもの。日々のプロダクト開発タスクは原則持たず、AI関連の動向調査・検証・社内展開・仕組み化に集中してもらう形にしました。

プロダクト開発の手を減らすことに対しては、当然ながら社内でも葛藤がありました。それでも踏み切れたのは、片手間で続けていた半年間を通して、兼務では絶対に追いつかないという確信があったからです。

最初にやったこと:Findy Team+で現状を知る

専任ポジションを置いてから最初に取り組んだのは、派手な施策やスキル作成などではなく現状把握でした。

組織全体のAI活用を推進するといっても、感覚だけで動くと認識のギャップが生まれます。そこで、Findy Team+を使ってチーム単位・メンバー単位でAI活用の度合いを可視化するところから始めました。

ここでわかったのは、想定していたよりAIの恩恵を受けられていない、という事実でした。

もう少し掘り下げると、チームや事業部ごとにAIの活用度合いに明確な差があり、同じ役割のエンジニアでも使っているスキル・エージェントにばらつきがあることが見えてきました。よく使えている人の工夫が、他のメンバーに自然には伝わっていない状態です。

組織として全員で底上げされているのではなく、一部の熱量の高いメンバーが先行している状態だった、というのが当時の姿でした。

Claude Code Pluginsで展開を仕組み化する

現状把握でわかったスキル・エージェントのばらつきを埋めるために選んだ打ち手が、Claude CodeのPlugins機能を使った社内展開です。

Plugins機能については以前の記事でも紹介しています。

tech.findy.co.jp

Claude CodeのPluginsは、スキル・エージェント・カスタムコマンド・各種設定などを1つのパッケージとして配布できる仕組みです。AI推進のエンジニアが作成した開発用スキルなどをプラグインとしてインストール可能にしておけば、各メンバーが自分の環境でコマンド1つで使える状態になります。

この仕組みに乗せることで、便利なコマンドや開発標準化のスキルなどをそのまま開発組織全体に配布できるようになりました。新しく入ったメンバーも初日からファインディのAI活用の恩恵を受けられるようになっています。

実際に、ファインディの開発組織で運用しているスキル・エージェントの一部は、次の記事でも紹介しています。

tech.findy.co.jp

tech.findy.co.jp

tech.findy.co.jp

いずれも個人の工夫として始まったものを、プラグイン化して全員に配布できる形にしたものです。

継続的な浸透:毎日の通知と月一の共有

プラグインを配布するところまで作っても、更新を知ってもらえなければ次第に忘れられてしまいます。そこでファインディでは、配布の仕組みに加えて、更新が自然と目に入る状態を保つ工夫を並行して走らせています。

1つ目は、プラグインの更新内容をSlackの専用チャンネルに毎日通知する仕組みです。新しく追加されたスキルや、アップデートされたコマンドが翌日には目に入る状態にしておくことで、いつの間にか変わっていたではなく、今日こんな機能が追加されたという鮮度で情報が流通します。

2つ目は、月一のエンジニア定例のなかに、プラグインやAI活用の使い方を共有する時間を設けたことです。ドキュメントだけでは掴みきれないニュアンスやちょっとしたコツを口頭で流す場として、思った以上に機能しています。

プラグインという土台に加えて、通知と定例という継続的な露出。この組み合わせが、AI活用を一部のメンバーだけで閉じさせず、組織全体に浸透させる力になっています。

結果:PR作成数が前年比で約1.5倍に

こうした取り組みを進めた結果、1人あたりのプルリクエスト作成数は前年比で約1.5倍になりました。

AI活用が進んだ実感というあいまいな言葉ではなく、開発のアウトプットそのものが定量的に伸びた、というのが大きなポイントです。

もちろん、プルリクエスト作成数は開発の速度やスタイルの指標の1つに過ぎません。それでも、組織としての変化が数字として見える状態になったこと自体が、AI活用のどこに投資すべきかを議論する大きな土台になりました。

振り返って気づいたこと

半年ほど取り組んで気づいたのは、専任を置いたから任せきる、では成り立たないということです。

専任1人ですべてを背負う構造にすると、その人自身がボトルネックとなってしまいます。専任の役割は、自分がすべてを実行することではなく、組織のAI活用を前に進めるための仕組みをつくること。

現場のエンジニア・マネージャーが自走するための土台を整え、みんなで良くしていくというスタンスが重要だと感じました。

まとめ

ファインディのAI活用推進は、特別なツールや大がかりな制度改革ではなく、「AI推進だけを専任で担うポジションを作る」というシンプルで小さな意思決定から加速しました。

そこから専任が取り組んだのは、Findy Team+を使った現状把握、Claude Code Pluginsを使ったスキル・エージェントの社内展開、そしてSlack通知と月一定例による継続的な浸透。

いずれも派手さはありませんが、これらの積み重ねによって、1人あたりのプルリクエスト作成数が前年比で約1.5倍になるまでの変化を生み出すことができました。

AI活用は一日にして成らず。小さな意思決定や地道な取り組みの積み重ねが、組織全体の大きな変化につながることを実感しています。

全員が10%ずつAI推進に充てるよりも、1人が100%を充てる。この発想の転換が、ファインディのAI活用を動かす原動力になっています。

AI活用が思うように進まないと感じている組織の責任者の方がいれば、制度や研修を考える前に、専任を置く(業務から外す)という選択肢を検討してみてください。

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

herp.careers

登壇スライドを30分で作る:Claude Codeで壁打ちからGoogle Slides生成までワークフロー化

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

ファインディではClaude CodeのスキルやカスタムコマンドなどをPlugins経由で社内展開しています。

tech.findy.co.jp

コードレビューやタスク分解といった開発業務の効率化が進む一方で、登壇準備はまだ手作業の割合が大きい領域です。話す内容を固めて、構成を考えて、スライドに落とし込んで、デザインを整えて……。発表の本質は「何を伝えるか」なのに、準備工程に時間を奪われがちです。

本記事では、この課題に対処するために社内Pluginsに作った登壇スライド生成スキルを紹介します。壁打ちによるコアメッセージの言語化からMarkdownスライド生成、Google Slidesへのエクスポートまでを一気通貫で行えるもので、壁打ちから完成まで30分で終わるようになりました。

登壇準備にかかる時間の内訳

登壇準備のどこに時間がかかっているかを振り返ると、スライドのデザインや配置よりも、その手前の工程が大きいことに気づきます。

前半は「何を話すか」の整理です。話したいことはぼんやりあるけれど、コアメッセージを一文にまとめるのが難しい。構成を決めても「この流れで聴衆に伝わるか?」と不安になって何度も組み替える。ここが一番時間を食います。

後半はスライドの作成とリハーサルです。ようやく構成が固まっても、今度はスライドツールを開いてフォーマットやデザインと格闘する。前半さえ効率化できれば、発表内容そのものの質を上げる時間に使えるはずだと考えました。

NotebookLMを試して感じた限界

最初に試したのはGoogleのNotebookLMでした。ソース資料を読み込ませてスライドを生成できる機能があり、期待して使ってみました。

ただ、実際に使ってみるといくつか壁がありました。出力がPDFや画像形式のため、生成後の編集が難しい点です。スライドの順番を入れ替えたい、テキストを修正したいといった基本的な操作ができず、結局ゼロから作り直す羽目になりました。

もう一つは、社内のスライドガイドラインに沿った出力が非常に難しかったことです。フォントやカラースキーム、ロゴの配置などは組織ごとにルールがあります。汎用的なAIツールではそこまで制御できず、ガイドラインに準拠させるための手作業が発生していました。

Claude Codeスキルという選択肢

これらの課題を踏まえて、Claude Codeのカスタムスキルとして登壇スライド生成ワークフローを自作しました。Claude Codeスキルを選んだ理由は、対話的なワークフローを自然に組めること、Markdownで中間出力できること、そしてAPIを叩いて外部サービスに連携できることの3点です。

開発したのは2つのスキルです。1つ目がMarkdownスライドの生成、2つ目がGoogle Slidesへの変換を担います。

ワークフローの全体像

スキルを実行すると、次の流れで処理が進みます。

  1. 参考URLやコードスニペットの収集(任意)
  2. 壁打ちでコアメッセージを言語化
  3. タイトル・概要・発表時間の入力
  4. テンプレートに基づく構成設計
  5. Markdownスライドの生成
  6. Google Slidesへのエクスポート(任意)

各フェーズを詳しく見ていきます。

壁打ちフェーズ:コアメッセージの言語化

このスキルで最も力を入れたのが壁打ちフェーズです。登壇準備で一番時間がかかるのは「何を伝えるか」を固める工程だからです。

スキルを起動すると、まず対象オーディエンス(テックリード、シニアエンジニア、EMなど)を選択します。次に「発表内容はすでに決まっていますか?」と聞かれ、「まだ漠然としている」を選ぶと壁打ちモードに入ります。

? スライドに取り込みたいURLやコードスニペットはありますか?(任意)
> なし

? 対象オーディエンスを教えてください(複数選択可)
  エンジニア系: ✔ テックリード ✔ シニアエンジニア
  マネジメント系: ✔ EM

? 発表内容はすでに決まっていますか?
> まだ漠然としている(一緒に考えたい)

どんな発表をしたいですか?テーマや話したいこと、伝えたいことを
自由に教えてください。まだ漠然としていても大丈夫です。

壁打ちは次の順序で進みます。

  1. コアメッセージの確定 — 「この発表で一番伝えたいこと」を1文に絞る
  2. 逆算による構成設計 — コアメッセージを結論として、聴衆が納得するために必要な情報を逆順に積み上げる
  3. タイトル・概要の決定 — 構成が固まった後に、コアメッセージが伝わるタイトルを考える

ポイントは「逆算」というアプローチです。結論から遡って構成を組むことで、「話したいことを全部詰め込んだけど結局何が言いたいのかわからない」というよくある失敗を防ぎます。

実際のやり取りはこんな感じです。

> 生成AI時代のエンジニア育成について話したいんですけど、
  まだ切り口が定まってなくて

エンジニア育成×生成AIですね。テックリードやEM向けなので、
現場のリアルな課題感が求められます。
AI導入後に育成面で一番変化を感じたのはどこですか?
学習速度、コードの質、それともチームの生産性でしょうか?

> AI導入後にシニアの生産性は上がったんですが、
  若手のアウトプットの質がむしろ落ちていて。
  AIの出力をそのまま使ってしまって、理解が追いついてない感じです

なぜAIの出力をそのまま使ってしまい、理解が追いついていないと感じていますか?

> AIが出力したコードを理解せずにレビュー依頼するケースが増えていて、
  結果的にリードタイムが悪化していることはわかった。
  AI時代の今だからこそ原点回帰が必要。

なるほど。つまり「生成AI時代だからこそエンジニアの基礎力の価値が
上がっている。AIを"使う"側に立つには原点回帰が必要。」
ということを一番伝えたい、という理解で合っていますか?

> はい

Claudeがコアメッセージを1文に言語化してくれるので、対話で壁打ちを進められます。コアメッセージが確定すると、逆算で構成を組んだうえでまとめを提示してくれます。

壁打ちの結果をまとめました!

タイトル案: 生成AI時代のエンジニア育成 — 変わる時代と変わらないコト
概要: 生成AIの導入でシニアの生産性は上がったが、若手のアウトプットの
  質は低下していた。AIが出力したコードを理解せずにレビュー依頼する
  ケースが増え、結果的にリードタイムが悪化。基礎知識なきAI活用は
  「AIに使われている」状態であり、今こそ原点回帰が必要だと気づいた
  実体験を共有する。
コアメッセージ: 生成AI時代だからこそエンジニアの基礎力の価値が
  上がっている。AIを"使う"側に立つには原点回帰が必要。

? このまとめでスライド生成に進みますか?
> 進む

テンプレート設計:発表時間から逆算するスライド枚数

スキルには3種類のテンプレートを用意しました。

  • standard — 20〜60分のカンファレンストーク向け。背景→本題→デモ→まとめの王道構成
  • lt — 5〜10分のLightning Talk向け。「結論ファースト」で1点突破
  • tutorial — 30〜40分のハンズオン向け。手順ごとに検証ステップを挟む

発表時間を選ぶと、テンプレートが自動選択されます。5分や10分ならLTテンプレート、15〜20分ならstandard、30分以上でハンズオン形式ならtutorialです。

スライド枚数は「1分1枚」を基準に算出しています。20分の発表なら15〜20枚。セクションごとの配分は、背景10〜15%、メインコンテンツ50〜60%、デモ15〜20%、まとめ・Q&Aで残りという割合で自動配分されます。

? 発表時間を選択してください
> 20分

テンプレート: standard(カンファレンストーク向け)を自動選択しました
目標スライド枚数: 15〜20枚

構成を設計しています...
? スライドに取り込みたいURLやコードスニペットはありますか?(任意)
> https://tech.findy.co.jp/entry/2026/02/20/070000

URLの内容を取得しています...
✓ 取得完了: https://tech.findy.co.jp/entry/2026/02/20/070000
  → 要点を抽出し、背景・メインコンテンツのセクションに反映します
  → 参考資料スライドにリンクを追加します

Google Slides API

Markdownで生成したスライドをGoogle Slidesに変換するスキルも開発しました。Google Slides APIを実行しており、OAuth2認証でユーザーのGoogleアカウントに紐づけています。

developers.google.com

? Google Slidesにエクスポートしますか?
> エクスポートする

Google Slidesにエクスポートしています...
✓ エクスポートが完了しました
  URL: https://docs.google.com/presentation/d/1abc.../edit

テンプレートコピー方式

今回は会社のスライドマスター(テンプレート)をGoogle Drive API経由でコピーし、そこにスライドを追加していく方式を採用しました。テンプレートには表紙・中扉・詳細ページのレイアウトが定義されており、Markdownの見出しレベルに応じて適切なレイアウトを選択します。

Markdownからスライドへの変換ルール

Markdownのパース結果は、見出しレベルとボディの有無でスライドの種類を自動分類しています。

Markdownのパターン スライドの種類 デザイン
# タイトル 表紙 背景画像あり
## 見出し + 本文あり 詳細ページ 背景画像あり
## 見出し のみ(本文なし) セクション区切り グレー背景 + 白文字

##の中に###の小見出しが含まれる場合は、自動的にセクション区切り1枚 + 小見出しごとの詳細ページに展開します。たとえば「AI時代の到来と変化」の下に「変わったこと」「変わらなかったこと」の2つの###があれば、計3枚のスライドに分割されます。

デザインガイドラインの組み込み

会社指定のスライドガイドラインをスキルの定義ファイルに直接記述しています。フォントやカラーパレット、サイズといったルールをスキルの中で持ち、エクスポート時に各要素に適用します。

70点の完成度で出す割り切り

運用上、重要にしているのは「70点の完成度で一発出力し、残りは人間が仕上げる」という割り切りです。

AIが100点のスライドを作るのは現状難しいですし、目指す必要もないと考えています。スライドの完成度を70点から100点にするのは人間の感性が必要な部分です。逆に、0点から70点の工程(構成決め、テキスト配置、フォーマット統一)はAIの得意分野です。

この分業により最速で「壁打ち15分 + スライド生成5分 + 手動調整10分 = 30分」で登壇準備が完了するようになりました。

まとめ

今回紹介したスキルで作成されたスライドがこちらです。

登壇準備の工程をClaude Codeスキルで一気通貫にしたことで、壁打ちから完成まで30分程度で終わりました。

このスキルの価値は「スライドを自動生成すること」自体ではなく、「コアメッセージの言語化を対話で支援すること」にある点です。登壇準備で本当に時間がかかるのは構成やデザインではなく、「自分が何を伝えたいか」を整理する工程だったのだと、スキルを開発する過程で改めて実感しました。

登壇の機会があるエンジニアの方は、ぜひ挑戦してみてください。


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

herp.careers

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数が明確に一段増えていることがわかります。個人のポテンシャルを引き出すアプローチが、開発チーム全体のアウトプット最大化に繋がった形です。

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からスラッシュコマンドを実行するだけで始められます。

Claude Codeでスラッシュコマンドを実行

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

リポジトリ名の入力 開始日の入力 終了日の入力

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

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

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

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

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

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」を押すだけです。

GitHub Actionsのワークフロー手動実行画面

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

Slackへの分析結果通知

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

分析結果が投稿されたGitHub 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の知識地図」は、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・エージェント開発から読み解く コンテキストエンジニアリング

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

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

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

■ 千田 / エンジニア ■

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

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

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

この本を読んだきっかけ

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

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

本の内容

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

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

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

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

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

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

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

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

特に印象に残った部分

2つあります。

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

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

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

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

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

このような方におすすめ

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

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

おわりに

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

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

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