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

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

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

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

こんにちは。こんばんは。 開発生産性の可視化・分析をサポートする Findy Team+ 開発のフロントエンドリードをしている @shoota です。 11月16日にグラントウキョウサウスタワーにて開催されたJSConf JP 2025でスポンサーセッションに登壇してきました。 今回はJSConfの雰囲気や登壇内容についてご紹介したいと思います。 jsconf.jp 会場へ出発！ 会場到着 ブースや発表の聴講 スポンサーセッション登壇 最終確認 登壇たのしい！！ おわりに 会場へ出発！ 普段は青森県でフルリモートとして働いているので、当日の早朝の新幹線に乗って会場に向かいました。 会場は東京駅直通のグラントウキョウサウスタワーということで、新幹線降車から直接向かうことができたのはとても嬉しかったです。 様々なイベントで勝手に 連れ回してもらっている自分のアクリルスタンド も連れて、ワクワクしながらいざ東京へ！ 自分のアクスタと東北新幹線 会場到着 颯爽と東京駅の改札をでて、普段はあまり出ることのない八重洲側出口を若干ウロウロしながら無事にサウスタワーに到着しました。 会場が44階にあることは新幹線内で履修済みだったので余裕の表情で受付を済ませていざ会場へ！！ ふおおおおおおおおおおお！ すんごい高い！すんごい高いよ！！！ 44階の凄さをわからせるエレベーター なんとか余裕の表情をキープして会場に入りました。 ノベルティのTシャツをもらいウキウキです。オフラインイベント独特の空気を身体中に吸い込んでいました。 いただいたノベルティTシャツ ブースや発表の聴講 自分の出番は17:30からとまだまだ時間がかなり合ったので、他のスポンサー企業様のブースや、セッションの聴講に向かいました。 わかっていたことではあるのですが、改めて、JSConfの発表はどれも濃い...。 TC39やJSの歴史の話などその辺ではそうそう聞くことができない濃度の話題がポンポンでてきていました。 JSConf JPの前身である東京Node学園の初期にも参加させてもらっていましたが、オーガナイザーの古川氏の思想と哲学がびっちりと詰め込まれたイベント内容になっていました。 ファインディでもインタビュー記事を掲載させていただいたのでこちらもご紹介しておきます。 findy-code.io 個人的に興味を惹かれたのはbunのスタックトレース実装に関する @__sosukesuzuki さんの発表でした。 東京Node学園もNode.jsの内部エンジンやノンブロッキングIO、イベントループの話題がかなりの盛り上がりがありましたが、15年以上の時をこえてJS エンジンの話が聞けるとは思いもよりませんでした。 前日はYAPCにいらっしゃったはずなのに、こんなに興味深い話ができるなんてすごい...。 speakerdeck.com スポンサーセッション登壇 最終確認 いよいよ登壇時間も近づいてきたのでお伝えしたいことのコアを確認しながら最終確認をしつつ、ブース裏で待機しました。 今回の持ち時間がおよそ30分でして、自分の発表経験のなかでもかなり長いので伝え漏れだけは避けたいという気持ち。 出番が近づいて急に集中しだす金髪 登壇たのしい！！ いよいよと登壇時間になったのでヌルヌルっと登壇者席に入り込み、無事に発表してきました。 speakerdeck.com 今回は巨大なJS/TSソースをモノレポ管理しているなかでのモジュール設計とその思想、CIとの関連について発表しました。 2分程度の余白をもたせて発表の準備をしっかりしてきたのですが、話が進むにつれて楽しくなってきてしまい、いろいろと付け足しながら進めたので時間はギリギリでした。 会場で聞いてくださったみなさんも集中して聞いてくださり、Xの投稿などもしてくださって感謝です。 オフラインの登壇たのしいな！！！ おわりに スポンサーブースではいろいろと見知った方も来てくださり、弊社のノベルティを喜んでくださる姿がとても嬉しかったです。 ファインディではさまざまなイベントの主催・企画をしていますが、JSConf JPのように特定言語のコミュニティがつくるイベントはまた違う雰囲気があって刺激的でした。 いろいろな言語や技術レイヤーのみなさんとつながり、エンジニアリングを楽しんでいけるといいなぁと思えた、幸せな一日になりました。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 そのような状況の中で先日、福岡でFindy AI Meetupの第3回を開催しました！ findy-inc.connpass.com そして今回は更に！東京でFindy AI Meetupを初開催しました！ findy-inc.connpass.com 当日参加くださったみなさま、ありがとうございました！ Findy AI Meetupとは？ 登壇内容 生成AIではじめるテスト駆動開発 生成AIが出力するテストコードのリアル：よくあるコードと改善のヒント データエンジニアリングにおけるAIの活用と未来 新規プロダクト開発におけるAI活用事例 懇親会 まとめ Findy AI Meetupとは？ ファインディ株式会社のエンジニアが主催する技術系のオフラインイベントです。 ファインディ株式会社では、生成AIやAIエージェントの活用を通じて開発生産性の向上を目指す取り組みを行っています。このイベントでは、ファインディのエンジニアが社内での実践事例を紹介するとともに、エンジニア同士がつながり、知見の共有や交流を目的としています。 今回のMeetupは福岡では3回目の開催となっており、前回開催にも参加くださった方々が３割ほど、初参加の方々が７割ほどの割合でした。 福岡の開催日はYAPCの前日となっており、福岡開催でありながら県外からの参加者の方も多数いらっしゃいました。50人の申し込み枠に対して定員を超える申込みをいただき、改めて皆さんのAIに対する関心の高さを実感しました。 東京での開催は初めてでしたが、こちらも多くの方に参加いただき、大盛況となりました。 まだ参加したことがない読者の方も次回開催には是非ご参加ください。 登壇内容 生成AIではじめるテスト駆動開発 最初は弊社フロントエンドテックリードの新福が「生成AIではじめるテスト駆動開発」と題して、検証中の開発プロセスについて発表しました。 生成AIを用いた開発では、「思ったような出力が得られない」「動かないコードが出力される」といった場面を目にする機会があると思います。 そこで、この発表ではGitHub CopilotのChat Modesの機能を交えつつ、テスト駆動開発に着目して開発プロセスの検証を実施しました。 使用したプロンプト等のサンプルは↓こちらのリポジトリにあります。参考になりましたら幸いです。 https://github.com/puku0x/gen-ai-tdd-test/tree/main/.github/chatmodes テスト駆動開発の検証を通して、これまでソフトウェア開発で培われてきたノウハウは、生成AI時代でも通用するものであるという気づきを得られました。 生成AIが出力するテストコードのリアル：よくあるコードと改善のヒント 次に私（戸田）が、「生成AIが出力するテストコードのリアル：よくあるコードと改善のヒント」と題しまして、生成AIが出力するテストコードの実状と、より良いテストコードを生成するためのポイントについて紹介しました。 テストコードは生成AI時代において、生成AIが暴走しないためのガードレールとしての役割を持ちます。 しかし、生成AIが出力するテストコードの質においては、未だ伸び代が残っているのが現状です。 不要なテストケースが追加されてしまったり、「テストを通すためのテストコード」が生成されてしまったり、変更に対して弱いテストコードが生成されてしまうことがあります。 この問題を解決するために簡単にできるポイントとしては、既存テストコードの見直しやmockの活用、テストコードのサンプルコードの用意などがあります。 生成AI時代にテストコードが持つ役割は、今までのものより重要なものとなりました。出力される実装コードの質を向上したい場合は、テストコードとも向き合うことが重要です。 今回の登壇と資料が皆さんの参考になると幸いです。 データエンジニアリングにおけるAIの活用と未来 データソリューションチームにおける取り組みについてお話させていただきました。 会の性質上、データ基盤について知っている方が少ないと想定されましたので、前半にデータ基盤についての説明を入れています。 後半では、Devinの導入の話や社内のADK活用事例を紹介しました。ADKについては、田頭 ( @tagasyksk ) さんが記事を公開されているので気になる方はチェックしてみてください。 tech.findy.co.jp speakerdeck.com 新規プロダクト開発におけるAI活用事例 最後にエンジニアの嶋村が、新規プロダクト開発の中でどのようにAIを取り入れていったかを紹介しました。少人数でスピードが求められる状況の中、AIを前提にどう開発を設計したかがテーマです。 発表では、開発の土台づくりから日々の作業の進め方まで、AIと協力しながらプロダクトを作るための考え方を整理してお伝えしました。また、実際の開発で役立った細かなAI活用のTipsも紹介しています。 「AIに合わせて開発を組み立てるとどうなるのか？」という視点でまとめた内容になっていますので、ぜひスライドも合わせてご覧ください。 懇親会 登壇発表後は参加者の皆さんと懇親会を開催しました。 懇親会では「パックマンルール」をお願いしています。懇親会で誰かと話すときは新しい人が会話に入れるように、一人分のスペースを空けて話しましょう。というルールです。 生成AI活用における悩みや知見を意見交換して、楽しんでいただけたようです。 まとめ 当日、イベントに足を運んでくださった参加者のみなさん、本当にありがとうございました。頂いたアンケート結果を、次回開催の参考とさせていただきます。 残念ながら今回のイベントに参加出来なかったみなさんも、次回イベント開催時には是非ご参加ください！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

ソフトウェアエンジニアの土屋 (しゅんそく, @shunsock ) です。タイトル通りYAPC::Fukuoka 2025に行ってきました。YAPCは2023年に学生支援で参加して以降毎年参加しています。 yapcjapan.org 今回は、ファインディの福岡メンバー、DevRelメンバー、私で参加しました。本記事では福岡でのファインディの活動をお届けします!! Day 1 セッション聴講 「正規表現をつくる」をつくる なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える Findy U29懇親会 at YAPC::Fukuoka 2025 Day 2 ファインディブース セッション聴講 探求の技術 キーノート Drinkup さいごに Day 1 セッション聴講 「正規表現をつくる」をつくる speakerdeck.com fortee.jp 夜な夜な正規表現の微分 (Brzozowski 微分) がきっかけで正規表現エンジンなどの実装面が気になっていたので聴講。 このセッションはあるパターン集合Aにマッチし、あるパターン集合Bにマッチしない正規表現を生成する問題 (能動的オートマトン学習) を扱っていました。 RPNI (Regular Positive and Negative Inference)や正規表現の合成・復元の理論的手法とLLMの相性の良さが意外で面白いと感じました。 なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える speakerdeck.com fortee.jp IaCのモジュール化は当社でも取り組んでいる問題で、非常に難しいと感じています。確かにTerraformは宣言的な記述が可能ですが、参照や変数などの要素や階層によって依存グラフが複雑化しやすいからです。 そんな「なんとなく思っていた」ことを見事に言語化されていて感動を覚えたのは私だけではないでしょう。 Findy U29懇親会 at YAPC::Fukuoka 2025 YAPC::Japanに参加したことがない、学生ではない29歳以下の若者の交通費と宿泊費を支援するU29スポンサーをして懇親会を開催しました。 findy.connpass.com Day1に聞いたそれぞれのベストトークの話や、今日聞いたそれぞれのベストトークの話や技術の話、悩んでいる話、趣味の話など、美味しい福岡グルメを堪能しながらお話できました。 YAPC初参加のU29の皆さんの横のつながりも作ることができたので、今回スポンサーできてよかったです。 最後にじゃんけん大会をし、限定ノベルティをプレゼント。 翌日パーカーを着て会場に来てくれました。 Day 2 ファインディブース YAPC::Fukuoka 2025のテーマ「きゅう」にちなんで、「今年探求したこと」を皆さんに聞いてみました！ 「設計」や「障害対応」など仕事で取り組んだことだけでなく、「料理」や「推し活」などプライベートで向き合ったことも含めて、さまざまな探求にまつわるエピソードを聞けたのでとても楽しかったです。 今年はAIコーディングツールが続々と登場したこともあり、「AI」に関する話題も多くありました。2025年で探求してきたことが2026年でも報われることを願っています！ セッション聴講 探求の技術 fortee.jp speakerdeck.com 個人の技術発信のときに「SNSのいいね数をKPIにしない方が良い」という話が本当に大切だと私も思っていたので共感しました。個人の学習のために書いているときは、登壇者の述べたように「学びを報酬にする」と発信を続けられると思います。 また、話したいことをyamlのようなファイルにまとめておいて、スライドとブログの下書き作ると共通のインターフェースで作成できていいなと感じました。今は人力でCanvaを書いているのですが、Marpも採用してみたいです。 キーノート P山さんの赤裸々な話が心を打ちました。特にスピーカーの就活の失敗話も自分に重なるところがありました。 僕も新卒就活中は、サーバーなどの基本知識に強くないこともあり、某社で「VMとかでサーバー動かしているの?」といわれ「???」となり落されたのを思い出しました。ただ、なんとか食らいついて来たから今があると思っています。 難題に対して、試行錯誤しながら前進する姿勢を見習いたいです。 Drinkup 懇親会の後は恒例のDrinkupを開催！ findy.connpass.com DrinkupはFindyのものに参加する！という方もいらっしゃり、とても嬉しかったです。 ファインディのDrinkupは立食スタイルで実施することが多いので、たくさんの方とお話できるのも楽しい時間の1つです。美味しいビールを片手に、懇親会からの続きのお話で盛り上がりました！ さいごに YAPCは毎回面白い話が聞けますし、廊下文化が盛んでエンジニアと知り会うきっかけにもなるので非常におすすめのカンファレンスです。次回は東京とのことですので、まだカンファレンス参加したことのないエンジニアの方は是非検討してみてください!! 素敵な会を開催していただいた登壇者、スタッフ、スポンサーの皆様、ありがとうございました。 ファインディでは一緒に働くメンバーを募集中しています!! 興味がある方はこちらから ↓ herp.careers

こんにちは。Findy Tech Blog編集長の高橋（ @Taka_bow ）です。 この記事は これが私の推しツール！シリーズ の第4弾です。今回も、 推しツール紹介 と題して、弊社エンジニア達が日々の開発業務で愛用しているツールやOSSを紹介していきます。 エンジニアにとってターミナルは、コードを書くための入口であり、開発環境そのものと言っても過言ではありません。どのターミナルツールを選び、どう使いこなすかは、日々の生産性や作業の快適さに直結します。今回は、そんなターミナルツールに焦点を当てた特集です。 複数プロジェクトの並行開発、AI駆動開発での効率化、細かなカスタマイズへのこだわり——それぞれのエンジニアが自分の開発スタイルに合わせて選び抜いたツールと、その使い方を紹介します。 トップバッターはsontixyouさんです。 ■ sontixyou / プロダクト開発部 / Tools開発 ■ Findy Conferenceを開発しているsontixyou( @sontixyou )です。 普段はWebアプリケーションのフロントエンドとバックエンドの開発を担当しています。 WezTerm wezterm.org WezTermで開発（使ってる様子） WezTermでよく使う機能はTabです。次のようにTabを活用しています。 赤枠で囲っている箇所がTabです。 普段Macを使っているため、command + 数字でTabを切り替えるようにしています。 command + 1を押すとTab Aに切り替わるようにしています。 左から順に次のように並べています。 Tab A Neovimの設定専用 Tab B Findy Conferenceの実装 Tab C Findy Toolsの実装 Tab D インフラ修正、ステージング環境の DB からのデータ抽出 など WezTermの推しポイント 自分が欲しい機能が揃っている 他にも Alacritty や Kitty といったターミナルはありますが、必要な機能が揃っており、かつ Lua で設定できるという条件を満たすのは WezTerm だけ 操作が簡単 Tabの作成（Command + T）や削除（Command + W）が直感的で、Google Chrome などと同じ感覚で操作できる 設定が楽 設定ファイルは Lua で記述でき、Neovim と同言語で整合が取れるうえ、 公式ドキュメント が充実しているため迷いにくい Zellij zellij.dev Zellijで開発（使ってる様子） 次のディレクトリ構成があるとします。 Findy-Conference/ ├── frontend/ └── backend/ 普段Findy-Conferenceのディレクトリで次の添付画像のようレイアウトに固定して作業しています。イメージは VS CodeのWorkspace機能 に近いです。 フロントエンドとバックエンドを横断して開発するため、両方のコードをまとめて grep・閲覧できる構成にしています。 左上で普段Neovimを起動させている 左下はGit, lazygit等のシェルコマンドを実行する 右はClaude CodeまたはCopilot CLIを常時起動 たまにフロントエンドとバックエンドでそれぞれのタスクを並列でやりたい場合、横に分割して、フロントエンドとバックエンドそれぞれでClaude Codeを起動している WezTerm の各Tabの中で、Zellij の複数Tab・Paneを運用しています。 Zellijの推しポイント 複数のリポジトリ・ディレクトリをまたいだ開発時の切り替えが楽 WezTermのPaneの代わりに、ZellijのPaneとTabがとても良い 公式ドキュメント が充実しており、設定も容易 導入ハードルが低い WezTerm以外のターミナルでも利用可能 Tabの切り替えやPaneの切り替えはマウス操作にも対応 マウスで操作感に慣れ、ショートカットへ移行可能 今気になってるツール zed.dev Atomを開発したメンバーが開発しているIDE WezTermとZellijの二段構えによるTab管理とPane分割の工夫が参考になりました。 WezTermのTabで大きな作業領域を切り分け、その中でZellijのTabとPaneを使って細かい作業環境を構築するという階層的な運用は、複数のプロジェクトを横断して開発する際に有効なアプローチです。 VS CodeのWorkspace機能に例えているのもわかりやすいですね。また、Luaによる統一的な設定記述や、マウス操作からショートカットへの段階的な移行を許容している点も、学習コストと操作効率のバランスが取れています。 続いて、danさんです。 ■ dan / プロダクト開発部 / AI+開発 ■ Findy AI+を開発しているdanです。 9月末までFindy Team+でバックエンドを主に担当しており、10月からはFindy AI+でバックエンドだけでなくフロントエンドにも挑戦しています。 iTerm2 iterm2.com iTerm2で開発 ターミナルに関しては画面いっぱいに広げたい個人的な好みがあります。 そこで初めて知ったのがこのiTerm2です。透過・表示切り替えも設定が簡単であったため昔から使っています。(別のツールにもあるかもしれないですが、初めて出会ったこのツールを使い続けています) また、sontixyouさんの推しツールである WezTerm のTab機能がiTerm2にもあるので用途に応じてTabを作成しています バックエンドのプロジェクト用 フロントエンドのプロジェクト用 Tabはcommand + 数字で切り替え可能です(このバーはcommandキーを押している時のみ表示されてます) iTerm2の推しポイント ターミナルを画面全体で表示・非表示するのが一瞬 Hotkeyの設定で可能です 透かすことができるのでターミナル以外の画面も閲覧できる 開発していると、PRのレビュー対応や公式ドキュメントで使い方を確認しながら作業をすることがあると思います。私が属しているFindy AI+ではほぼ100%AI(Claude Code)がコードを書いています。指示を送る時はターミナルで作業しているためレビューコメントやドキュメントを透かして確認できるのが個人的に便利だと感じています。 透過状態での表示・透過を無効化した状態での表示もコマンドで切り替えられるので、コマンド作業に集中したい時は無効化にしています。 設定し放題 起動時のディレクトリの指定や、用途によって設定を切り替えられるProfileも用意されています 透過設定はColors設定によって変わりますが、ここで設定できます Tabの増減は、Command + T(追加), Command + W(削除)で可能です 今気になってるツール チームメンバーの中には Warp というツールを使っているメンバーもいます。 ここで紹介したツールの一部機能を持ち合わせていることに加え、過去のコマンド履歴が表示されたり( zsh-autosuggestions のような感じ)、ターミナルなのに初期設定のままでも見やすいものになっています。 www.warp.dev iTerm2の透過機能と即座の表示切り替えは、実用性の高い使い方だと感じました。 特に、ドキュメントやレビューコメントを見ながらターミナルで作業できる透過機能は、AI駆動開発が中心のFindy AI+における実際の業務フローとよく合っています。 Hotkeyによる瞬時の表示切り替えやProfileによる柔軟な設定など、自分の使い方に合わせてカスタマイズできる点も優れています。「初めて出会ったこのツールを使い続けている」という言葉に、道具との相性の良さが表れていますね。 おわりに 今回は、2名のエンジニアが使用しているターミナルツールを紹介しました。それぞれが自分の作業スタイルに合わせてツールを選び、カスタマイズしている様子をお伝えできたかと思います。 ファインディでは、さまざまなバックグラウンドを持つエンジニアが活躍しています。技術にこだわり、より良いものを追求する仲間とともに働いてみませんか？ 現在、ファインディでは新しいメンバーを募集中です。 興味のある方は、ぜひこちらからチェックしてみてください！

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub Copilot や Claude Code など、生成AIを活用した開発支援ツールが次々と登場し、日常的なワークフローに組み込まれつつあります。 今では当たり前のように日常の開発業務で生成AIを利用している一方で、生成AIに意図したコードを出力してもらえないという声も耳にします。 そこで今回は、生成AIとのVibeCoding *1 をするうえでのコツを幾つか紹介したいと思います。 それでは見ていきましょう！ 適切な情報 タスク分解 軌道修正 セッション管理 まとめ 適切な情報 生成AIに質の高いコードを出力してもらうためには適切な情報が必要です。現状を具体的に把握させることで、より詳細で質の高い出力内容になります。 例えば次のようなプロンプトがあるとします。 ` /src/lib/hoge.ts ` と ` /src/lib/fuga.ts ` の既存の処理を参考にして、 ` /src/lib/piyo.ts ` に新しい機能を追加してください。 このプロンプトだと参考にする既存の処理の何を参考にするべきなのかが曖昧です。 参考にするべきポイントを明確に伝える 必要があります。 - ` /src/lib/hoge.ts ` と ` /src/lib/fuga.ts ` の既存の処理を参考にして、 ` /src/lib/piyo.ts ` に新しい機能を追加してください。 - ` /src/lib/hoge.ts ` の ` function aaa() ` の実装を参考にして、データ取得処理を実装してください。 - ` /src/lib/fuga.ts ` の ` class Bbb ` の実装を参考にして、取得したデータを加工して返す処理を実装してください。 外部データなどを参照させて情報を補完することも有効です。外部データを生成AIに参照させる際にはMCP(Model Context Protocol)サーバーが非常に有用です。 MCPサーバーを介してIssueやライブラリ、デザインデータなどの情報を取得して生成AIに渡すことで、的確なコンテキストを提供できます。これにより生成AIの理解度が向上し、より正確なコード生成が可能になります。 タスク分解 生成AIに多岐に渡って一度に全部依頼してしまうと、コンテキストが肥大化してしまい出力結果の精度が落ちます。 例えば次のような機能要件があるとします。 組織に紐付くユーザー情報に権限情報を付与して、その情報を更新できるAPIを追加する。権限ごとに実行できるAPIを制限する。admin権限の場合、全てのAPIを実行することができる。editor権限の場合、HTTP MethodがGETかPOSTのAPIのみ実行することができる。member権限の場合、HTTP MethodがGETのAPIのみ実行することができる この要件の内容を全て一度にプロンプトで実行すると確実に出力精度が落ちます。 異なる対応を幾つも抱えており、それ全てを一度に実行するためコンテキスト、認知範囲が広がってしまう からです。 このようなケースでは、まず 実行したかったプロンプトを修正内容別に分解 しましょう。 - 組織に紐付くユーザー情報に権限情報を付与する - その情報を更新できるAPIを追加する - 権限ごとに実行できるAPIを制限する。admin権限の場合、全てのAPIを実行することができる。editor権限の場合、HTTP MethodがGETかPOSTのAPIのみ実行することができる。member権限の場合、HTTP MethodがGETのAPIのみ実行することができる 次に、 各修正内容の詳細度を上げていきましょう。 - 組織に紐付くユーザー情報に権限情報を付与する - org _ usersテーブルに次の項目を追加する - role - String - 必須 - enum: [admin, editor, member] - default: member - その情報を更新できるAPIを追加する - PATCH /api/v1/orgs/{org _ id}/users/{user _ id}/role - リクエストボディ - role - String - 必須 - enum: [admin, editor, member] - レスポンス - 200 OK - 更新後のユーザー情報を返す - 権限ごとに実行できるAPIを制限する - admin権限の場合、全てのAPIを実行することができる。 - editor権限の場合、HTTP MethodがGETかPOSTのAPIのみ実行することができる。 - member権限の場合、HTTP MethodがGETのAPIのみ実行することができる ここまで分解できれば、あとは 大項目ごとに生成AIに依頼してPull requestを作成する と良いです。 このように生成AIに依頼するタスクは、コンテキストを絞った明示的な内容に細分化すると、出力精度が上がる傾向にあります。 軌道修正 生成AIに全部を一気に作らせると、意図しない修正だった場合に変更内容を破棄する範囲が広くなってしまいます。 必要な範囲だけ戻せるようにするのがコツです。 そのため指示する内容の粒度を細かくして、定期的にコミットしておくと良いです。これはPull requestの粒度よりも、さらに細かい粒度で考えたほうが良いです。 新しいテーブルを追加するタスクを例に説明します。次のようなプロンプトを実行したとします。 次のテーブルを追加してください。 - テーブル名: users - id: Integer, Primary Key, Auto Increment - 苗字: String, Not Null - 名前: String, Not Null 苗字を last_name で作成されましたが、ちょっと分かりづらいので family_name に変更したいため軌道修正するとします。 しかし、この時点で migrationファイルだけでなくモデルファイルが作成され、しかもlocal環境でmigrationまで実行されていたらどうでしょうか？ 軌道修正のために rollbackを実行して、モデルファイルもmigrationファイルも修正する必要があり、変更の破棄に手間と時間がかかってしまいます。 このようなケースでは、まずモデルファイルだけ作り、そこで認識を合わせてからmigrationファイルを作成するような流れでプロンプトを実行すると良いです。 - Userモデルを作成してください。 - id: Integer, Primary Key, Auto Increment - 苗字: String, Not Null - 名前: String, Not Null このプロンプトでモデルファイルだけ作成され、仮に苗字の項目名が last_name になっていても、モデルファイルだけなら修正は簡単です。次のプロンプトで軌道修正しましょう。 追加したモデルの苗字の項目名を ` family_name ` に変更してください。 モデルの内容の軌道修正が完了してからmigrationファイルを作成しましょう。 追加したモデルのテーブルを作成するmigrationファイルを作成してください。 このように生成AIに一度に対応してもらう範囲を細かく区切ることで、軌道修正をスムーズに進めることが出来ます。 セッション管理 生成AIとのやり取りは、セッション管理を意識すると効率的になります。 全く関係のない内容を同一セッションで行うと精度が落ちてしまいますが、 同じような修正は同一セッションで行うと効率的で精度が上がります。 例えば次のような修正を行うとします。 - 既存のLayoutComponentをコピーして新しいLayoutComponentを作成する - 新しいLayoutComponentを次のように修正する - propsに次の項目を追加する - current _ user - User型 - 必須 - props.current _ user.roleが 'admin' の場合、管理者用のナビゲーションメニューを表示する - 既存のLayoutComponentを使用している箇所を全て新しいLayoutComponentに差し替える このタスクを一度に全て実行しようとすると出力結果の精度は落ちます。 既存のLayoutComponentを使用している箇所を全て新しいLayoutComponentに差し替える の部分のコンテキストが広すぎて生成AIの認知負荷が肥大化してしまうからです。 このケースの場合、まずは新しいLayoutComponentの作成までを終わらせているのが良いです。なぜなら、LayoutComponentの作成と差し替えは全く異なるタスクだからです。 次に別セッションにしてからLayoutComponentの差し替えに取り組みます。まず、既存のLayoutComponentを使用している箇所を全てリストアップしてもらうプロンプトを実行して、対象ファイルを洗い出します。 洗い出したリストから1つ選択して、まず1箇所だけ差し替えを実行してもらいます。ここでVibeCodingを行って正しい差し替え内容になるように修正してください。これが大きなポイントです。 1箇所の差し替えを正しく実行できたら、セッションを維持したままで次のようなプロンプトを実行してください。 同じような変更を、リストアップした他の箇所にも適用してください。 このやり方により、コンテキストの範囲が一気に肥大化せず、出力精度が極端に落ちることを防ぎながら1つの修正を横展開することが出来ます。 差し替えるための新しいLayoutComponentを作成する 差し替え対象となるコードを全てリストアップする 差し替え対象から1箇所だけ選び、VibeCodingで正しい差し替えを1件完了させる リストアップした変更対象に水平展開させる このように、 生成AIとの会話履歴を意識すると、若干曖昧な表現だとしても会話履歴から補完して精度を保つことが出来るケースがあります。 まとめ VibeCodingの相手は生成AIですが、 結局は人間を相手にしていることとあまり変わらず、明確で簡潔な内容を１個ずつ指定することや、会話履歴を意識することが重要である ことが分かったかと思います。 今回の記事が皆さんのVibeCodingのヒントになると嬉しいです。 そしてこの度、 11月13日(木)に福岡で Findy AI Meetup の開催が決定 しました。 findy-inc.connpass.com 今回は YAPC::Fukuoka の前日の開催 です。県外からの参加者のみなさん、前日入りしてこちらへの参加もぜひ検討ください。 そしてなんと！これまでの福岡での開催が大盛況だったため、 11/17(月)に東京オフィスでのFindy AI Meetupの開催も決定 しました！ findy-inc.connpass.com こちらの参加もぜひ検討ください。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers *1 : OpenAIのAndrej Karpathy氏が2025年2月に提唱した、生成AIに自然言語で指示を与えながら直感的にコードを作り上げていく開発手法

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub Copilot や Claude Code など、生成AIを活用した開発支援ツールが次々と登場し、日常的なワークフローに組み込まれつつあります。 そんな中で先日、Claudeの新機能であるAgent Skillsが公開されました。 そこで今回は、Agent Skillsの紹介と解説、スキルの作り方を紹介したいと思います。 それでは見ていきましょう！ Agent Skillsとは 作り方 ファイル構成 skill-creator 実践編 まとめ Agent Skillsとは Agent SkillsはClaudeの機能を用途や状況に応じて柔軟に拡張できる便利な機能となっています。 docs.claude.com Claude Code のバージョンが1.0以上であれば、誰でも簡単に利用することが可能です。 スキルはClaudeが必要に応じて読み込むための指示を含む SKILL.md ファイルと、スクリプトやテンプレートなどのオプションのサポートファイルで構成されています。 スキルはモデルによって呼び出されます。Claudeはユーザーが入力したプロンプトとスキルの名前、説明に基づいて、いつどのスキルを実行するかを自律的に決定します。 公式ドキュメントによると、主なメリットは次の３つが挙げられています。 Claude の特化：ドメイン固有のタスクに合わせて機能をカスタマイズ。 繰り返し作業の削減：一度作成すれば自動的に使用可能。プロンプトの属人化を防ぎ、コード化したワークフローとしてClaudeに機能拡張する。 機能の合成：スキルを組み合わせて複雑なワークフローを構築。 スキルは再利用可能なファイルシステムベースのリソースであり、Claudeにドメイン固有の専門知識（ワークフロー、コンテキスト、そして汎用エージェントをスペシャリストへと進化させるベストプラクティス）を提供します。 プロンプトとは異なりスキルはオンデマンドで読み込まれるため、複数の会話で同じガイダンスを繰り返し提供する必要がなくなります。 ここまで読むとSubAgentやシステムプロンプト、MCPと何が違うのか良くわからない読者の方もいると思います。 Agent Skillsの特徴として Progressive disclosure が挙げられます。これは必要な情報のみが段階的に開示されることを意味しています。この仕組みにより、Claudeは幾つものスキルを同時に認識しながらも、コンテキストが肥大化することを防いでいます。 システムプロンプトやMCPとの決定的な違いはここにあります。両者は事前にClaudeがシステムプロンプトの内容やMCPが提供する全てのtoolの説明文と引数などを把握する必要があるため、必要以上にコンテキストが肥大化してしまう傾向があります。 一方、Agent Skillsはファイルシステムベースで動くだけでなく、最初は必要最低限の情報のみ把握します。そして該当するスキルを実行するときに、そのスキルの詳細のみを読み込みにいくのでコンテキストが必要以上に肥大化することを防いでいます。 作り方 ファイル構成 基本的には .claude/skills の配下にスキル用のフォルダと SKILL.md ファイルを作成するだけでスキルを作成できます。 SKILL.md の中身は次のような内容になります。YAMLとマークダウンで記述されます。 --- name: Your Skill Name description: Brief description of what this Skill does and when to use it --- # Your Skill Name ## Instructions Provide clear, step-by-step guidance for Claude. ## Examples Show concrete examples of using this Skill. まずYAMLの部分の解説をします。 --- name: Your Skill Name description: Brief description of what this Skill does and when to use it --- これはメタデータと呼ばれ、スキルを作成するうえで非常に重要な要素です。 Claudeは起動時にメタデータを読み込み、各スキルの存在と使用タイミングのみを認識してシステムプロンプトに組み込みます。このアプローチにより必要以上にコンテキストを肥大化することなく、多くのスキルを用意できます。 スキルのメタデータに一致するプロンプト実行やリクエストがあると、Claudeはファイルシステムから SKILL.md を読み取ります。 実際に実行されるかどうかの精度はメタデータの内容によって大きく左右されるので、非常に重要な要素となっています。 次にコンテンツ部分の解説をします。 # Your Skill Name ## Instructions Provide clear, step-by-step guidance for Claude. ## Examples Show concrete examples of using this Skill. メタデータはClaudeの起動時に必ず読み込まれますが、コンテンツ部分は実行時に読み込まれます。そして、エージェントスキルの実行時にコンテンツ部分に記載された内容を元にClaudeが処理を実行します。 ここで重要なのは、Agent Skillsが効率的な読み込みを実行していたとしても、コンテンツ部分の内容も簡潔にした方が良いという点です。Claudeがコンテンツ部分を読み込むと、その内容が会話履歴および他のコンテキストと競合します。 そのため、 CLAUDE.md やシステムプロンプトに記述されている内容やプログラム言語、ライブラリなどの一般的な内容についての言及はコンテンツ部分では省略して記述しましょう。どの部分を省略して、どこからをコンテンツ部分に記述するかの見極めをすることが、精度の高いスキルを作成するコツの1つです。 skill-creator スキルを簡単に作成するための仕組みとして、Anthropics社のリポジトリに skill-creator というプラグインが用意されています。今回はこちらを使って作成してみましょう。 github.com Claude Codeを立ち上げて /plugin コマンドを実行します。 > /plugin ╭─────────────────────────────────────────────────────────────────────╮ │ Plugins │ │ │ │ ❯ 1. Browse and install plugins │ │ 2. Manage and uninstall plugins │ │ 3. Add marketplace │ │ 4. Manage marketplaces │ │ 5. View installation status (errors) │ ╰─────────────────────────────────────────────────────────────────────╯ 4. Manage marketplaces を選択しましょう。 > /plugin ╭─────────────────────────────────────────────────────────────────────╮ │ No marketplaces configured. │ ╰─────────────────────────────────────────────────────────────────────╯ マーケットプレイスの登録が無いようです。 anthropics/skills をマーケットプレイスとして登録します。 > /plugin marketplace add anthropics/skills ⎿ Successfully added marketplace: anthropic-agent-skills 登録したマーケットプレイスから example-skills というプラグインをインストールしましょう。 > /plugin install example-skills@anthropic-agent-skills ⎿ ✓ Installed example-skills. Restart Claude Code to load new plugins. 再度 /plugin コマンドから 4. Manage marketplaces を選択しましょう。今度はマーケットプレイスが登録されていることがわかります。 anthropic-agent-skills を選択しましょう。 > /plugin ╭─────────────────────────────────────────────────────────────────────╮ │ Manage marketplaces │ │ │ │ ❯ ● anthropic-agent-skills │ │ anthropics/skills │ │ 2 available • 1 installed • Updated 10/20/2025 │ │ │ ╰─────────────────────────────────────────────────────────────────────╯ example-skills がinstallされていることを確認できました。 > /plugin ╭─────────────────────────────────────────────────────────────────────╮ │ anthropic-agent-skills │ │ anthropics/skills │ │ Last updated: 10/20/2025 │ │ │ │ 2 available plugins │ │ │ │ Installed plugins (1): │ │ ● example-skills │ │ Collection of example skills demonstrating various capabilities │ │ including skill creation, MCP building, visual design, │ │ algorithmic art, internal communications, web testing, artifact │ │ building, Slack GIFs, and theme styling │ │ │ │ ❯ Update marketplace │ │ Remove marketplace │ ╰─────────────────────────────────────────────────────────────────────╯ これで skill-creator を実行できるようになってるはずです。 実践編 では実際に skill-creator を使ってスキルを作ってみましょう。 今回はコミットメッセージのルールをスキルとして作成する例を紹介します。 弊社ではAPIのリリースをSemantic Versioningで管理しています。そこで重要なのがコミットメッセージです。コミットメッセージにSemantic Versioningを入れるルールとなっており、リリース時にコミットログからリリースバージョンを自動的に計算するようにしています。 まずは作成したいスキルの概要と skill-creator を使って作成する旨をプロンプトで入力します。 ▐▛███▜▌ Claude Code v2.0.25 ▝▜█████▛▘ Sonnet 4.5 · API Usage Billing ▘▘ ▝▝ /Users/hoge/project/github/Repo ─────────────────────────────────────────────────────────────────────── > コミットメッセージのルールを提供するスキルをskill-creatorを使って 作成してください。 semantic versioningをコミットメッセージの先頭に付与してください。 ─────────────────────────────────────────────────────────────────────── すると先ほどインストールした example-skills:skill-creator を使う旨のレスポンスが返ってきます。Yesを選択して作成してもらいましょう。 ⏺ コミットメッセージのルールを提供するスキルを作成します。skill-cre atorを使用して、semantic versioningをコミットメッセージの先頭に付与 するスキルを作成しましょう。 ╭─────────────────────────────────────────────────────────────────────╮ │ Use skill “example-skills:skill-creator”? │ │ Claude may use instructions, code, or files from this Skill. │ │ │ │ Guide for creating effective skills. This skill should be used │ │ when users want to create a new skill (or update an existing │ │ skill) that extends Claude's capabilities with specialized │ │ knowledge, workflows, or tool integrations. │ │ (plugin:example-skills@anthropic-agent-skills) │ │ │ │ Do you want to proceed? │ │ ❯ 1. Yes │ │ 2. Yes, and don't ask again for example-skills:skill-creator in │ │ /Users/hoge/project/github/Repo │ │ 3. No, and tell Claude what to do differently (esc) │ │ │ ╰─────────────────────────────────────────────────────────────────────╯ ここで初めて skill-creator のスキルのコンテンツ部分が読み込まれます。 Claudeが具体的な内容の認識を合わせようとしてくれています。ここで認識が違う場合はVibe Codingの要領で変更をしましょう。今回は特に問題ないのでOKと入力して続けます。 > The "skill-creator" skill is loading > The "skill-creator" skill is loading ⏺ skill-creatorスキルが読み込まれました。では、semantic versioningをコ ミットメッセージの先頭に付与するスキルを作成していきます。 まず、具体的な使用例を確認させてください。 どのようなコミットメッセージルールを想定されていますか? 例えば： - major-feat: 新しい機能を追加 - 破壊的変更を含む新機能 - minor-feat: 既存機能の拡張 - 後方互換性のある機能追加 - patch-fix: バグ修正 - 後方互換性のあるバグ修正 - patch-refactor: コードのリファクタリング - 動作を変えない改善 このようなフォーマットで良いでしょうか？また、以下の点も確認させ てください： 1. Semantic Versioningの適用方法: {version-type}-{change-type}: {description} という形式でよろしいですか？ 2. 変更タイプ: feat, fix, refactor, docs, test などのタイプを使用しますか？ 3. 自動判定: コミット内容から自動的にversion-typeを判定する必要が ありますか？それとも開発者に確認しますか？ skill-creator が実行されて、エージェントスキルのテンプレートファイルが作成されます。 ⏺ ありがとうございます。それでは、semantic versionをコミットメッセージの先頭に付与するスキルを作成します。 ⏺ Bash(python /Users/hoge/.claude/plugins/marketplaces/anthropi c-agent-skills/skill-creator/scripts/init_skill.py commit-message --path .claude/skills) ⎿ 🚀 Initializing skill: commit-message Location: .claude/skills … +16 lines (ctrl+o to expand) .claude/skills/commit-message/ ├── SKILL.md ├── assets/ │ └── example _ asset.txt │── references/ │ └── api _ references.md └── scripts/ └── example.py 続けて SKILL.md にエージェントスキルの内容を記述していきます。 ⏺ Read(.claude/skills/commit-message/SKILL.md) ⎿ Read 86 lines ⏺ 次に、SKILL.mdを作成します。semantic versioningルールに基づいたコ ミットメッセージを生成するスキルを書いていきます。 ⏺ Write(.claude/skills/commit-message/SKILL.md) ─────────────────────────────────────────────────────────────────────── Opened changes in Visual Studio Code ⧉ Save file to continue… Do you want to make this edit to SKILL.md? ❯ 1. Yes 2. Yes, allow all edits during this session (shift+tab) 3. No, and tell Claude what to do differently (esc) 次に参照ファイルを作成します。 SKILL.md からリファレンスファイルとして参照してもらうファイルが必要になるケースもあります。 ⏺ 次に、referencesディレクトリにsemantic versioningの詳細なリファレンスを追加します。 ⏺ Write(.claude/skills/commit-message/references/semantic_versioning.md ) ─────────────────────────────────────────────────────────────────────── Opened changes in Visual Studio Code ⧉ Save file to continue… Do you want to make this edit to semantic_versioning.md? ❯ 1. Yes 2. Yes, allow all edits during this session (shift+tab) 3. No, and tell Claude what to do differently (esc) 結果的にテンプレートで使わなかったファイルを自動で削除してくれます。 ⏺ 次に、不要なサンプルファイルを削除します。 ⏺ Bash(rm -rf .claude/skills/commit-message/scripts .claude/skills/commit-message/assets .claude/skills/commit-message/references/api_reference.md) ⎿ (No content) 最後にzipでパッケージングしてくれます。Claude.aiで作成したスキルを使いたい時に、このzipファイルをアップロードすることで利用可能になるようです。 ⏺ それでは、スキルをパッケージングしましょう。 ⏺ Bash(python /Users/hoge/.claude/plugins/marketplaces/anthropi c-agent-skills/skill-creator/scripts/package_skill.py .claude/skills/commit-message) ⎿ 📦 Packaging skill: .claude/skills/commit-message 🔍 Validating skill... … +7 lines (ctrl+o to expand) これでスキルの作成が完了しました。 ⏺ 完了しました！semantic versionをコミットメッセージの先頭に付与するスキルを作成しました。 作成したスキルの内容 📁 スキル構成 .claude/skills/commit-message/ ├── SKILL.md # メインスキルファイル └── references/ └── semantic_versioning.md # 詳細なリファレンス 🎯 主な機能 1. コミットメッセージフォーマット {version-type}-{change-type}: {description} 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> 2. Version Type（バージョンタイプ） - major: 破壊的変更（APIの変更、削除など） - minor: 新機能追加（後方互換性あり） - patch: バグ修正・小さな改善 3. Change Type（変更タイプ） - feat: 新機能 - fix: バグ修正 - refactor: リファクタリング - perf: パフォーマンス改善 - docs: ドキュメント - test: テスト - chore: メンテナンス - style: コードスタイル 4. 決定フロー - 破壊的変更があるか？ → major - 新機能を追加するか？ → minor - それ以外 → patch 5. 豊富な例とリファレンス - 具体的な使用例（4パターン） - 曖昧なシナリオの判断基準 - エッジケースの扱い方 📦 パッケージファイル commit-message.zip がプロジェクトルートに作成されました。このファ イルを他のプロジェクトで使用することもできます。 🚀 使い方 このスキルは自動的に有効になり、gitコミットを作成する際にClaude Codeが自動的に使用します。例： # ユーザー: "変更をコミットして" # → Claude Codeが自動的にcommit-messageスキルを使用 # → semantic versioningに従ったコミットメッセージを生成 スキルの準備が整いました！ では実際に作成したスキルを使ってみましょう。Claude Codeを再起動してコミットします。 > commitしてください ⏺ コミットを作成します。まず、現在の変更内容を確認します。 ⏺ Bash(git status) ⎿ On branch test-branch Changes to be committed: (use "git restore --staged <file>..." to unstage) … +8 lines (ctrl+o to expand) ⏺ Bash(git diff --staged) ⎿ diff --git a/.claude/skills/commit-message/SKILL.md b/.claude/ skills/commit-message/SKILL.md index 4f094c4..49b2adf 100644 … +702 lines (ctrl+o to expand) ⏺ Bash(git diff .claude/skills/commit-message/SKILL.md) ⎿ (No content) ⏺ Bash(git log -5 --oneline) ⎿ f384be4 Merge pull request #111 from Findy/fix/issue-222 eef554d patch-refactor: fix hoge … +7 lines (ctrl+o to expand) ⏺ 変更内容を確認しました。このコミットメッセージはcommit-messageスキルに基づいて作成します。 ╭─────────────────────────────────────────────────────────────────────╮ │ Use skill “commit-message”? │ │ Claude may use instructions, code, or files from this Skill. │ │ │ │ Rules for the commit message to be written when exec git commit │ │ (project) │ │ │ │ Do you want to proceed? │ │ ❯ 1. Yes │ │ 2. Yes, and don't ask again for commit-message in │ │ /Users/hoge/project/github/Repo │ │ 3. No, and tell Claude what to do differently (esc) │ │ │ ╰─────────────────────────────────────────────────────────────────────╯ ⏺ ドキュメントの改善なので、patch-docsでコミットします。 ⏺ Bash(git commit -m "patch-docs: enhance commit-message skill with comprehensive guidelines and examples…) ⎿ [test-branch 53ae227] patch-docs: enhance commit-messag e skill with comprehensive guidelines and examples 2 files changed, 560 insertions(+), 60 deletions(-) … +2 lines (ctrl+o to expand) ⏺ Bash(git status) ⎿ On branch test-branch Untracked files: (use "git add <file>..." to include in what will be committe … +5 lines (ctrl+o to expand) ⏺ コミットが正常に作成されました! 作成したコミット: - コミットハッシュ: 53ae227 - メッセージ: patch-docs: enhance commit-message skill with comprehensive guidelines and examples 変更内容: - .claude/skills/commit-message/SKILL.md を新規追加 - references/semantic_versioning.md を新規追加 - 合計560行の追加、60行の削除 なお、commit-message.zip という未追跡ファイルが残っていますが、こ れは意図的に除外されています。 スキルが起動して、変更内容からSemantic Versioningを付与したコミットメッセージを自動で作成してコミットしてることが分かるかと思います。 hoge@Macbook Repo % git log commit 4cb77a4d4332384a9acb7e67591ac3d32d08df21 (HEAD -> test-branch) Author: hoge <hoge@test.com> Date: Wed Oct 22 14:50:42 2025 +0900 patch-docs: enhance commit-message skill with comprehensive guidelines and examples 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> このようにスキルを作成することも利用することも非常に簡単でシンプルであることを理解できたかと思います。 まとめ Agent Skillsは機能拡張されていく予定となっているらしく、今後ますます目が離せない機能となっています。 www.anthropic.com ぜひ皆さんもAgent Skillsを活用して快適な開発環境を作ってみてください。 そしてこの度、 11月13日(木)に福岡で Findy AI Meetup の開催が決定 しました。 findy-inc.connpass.com 今回は YAPC::Fukuoka の前日の開催 です。県外からの参加者のみなさん、前日入りしてこちらへの参加もぜひ検討ください。 そしてなんと！これまでの福岡での開催が大盛況だったため、 11/17(月)に東京オフィスでのFindy AI Meetupの開催も決定 しました！ https://findy-inc.connpass.com/event/373552/ findy-inc.connpass.com こちらの参加もぜひ検討ください。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは。CTO室データソリューションチームの開です。 この記事は「 エンジニア達の人生を変えた一冊 」として、弊社エンジニア達の人生を変えた本を紹介していきます。エンジニアとしてのキャリアや技術的な視点に大きな影響を与えた一冊とは？それぞれの思い入れのある本から、技術への向き合い方や成長の軌跡が垣間見えるかもしれません。 今回は私・開と、松村さん、田頭さんの3名のエンジニアが、人生を変えた一冊を紹介します。 まず私から、データエンジニアとしてのアイデンティティを確立させた一冊を紹介させていただきます。データ基盤構築の世界に深く足を踏み入れるきっかけとなった実践的な書籍です。 ■ 開功昂 / データエンジニア ■ CTO 室データソリューションチームでデータエンジニアをやっている開です。 実践的データ基盤への処方箋〜 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ 実践的データ基盤への処方箋〜 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ 作者: ゆずたそ , 渡部 徹太郎 , 伊藤 徹郎 技術評論社 Amazon 私が紹介する「実践的データ基盤への処方箋」は、データ基盤構築のためのノウハウが詰まった書籍です。 この本を読んだきっかけ この本が出た2021年ごろ、プロダクトのバックエンドエンジニアとして働くかたわら、データ分析基盤やETLパイプラインの開発を業務で取り組んでいました。データ分析基盤構築のベストプラクティスやビジネスの価値につなげるためのアクション、世の中のデータ基盤プロジェクトの事例をキャッチアップするためにこの本を読みました。 本の内容 本は三部構成となっています。一部と二部で一般的なデータ基盤を満たすための構成要素やデータ基盤システムの作り方や望ましい構成について知ることができます。三部は「データ基盤を支える組織」と題してデータ基盤のプロジェクトの進め方や運用、管理方法について具体的なシチュエーションを交えながら学ぶことができます。 この本から影響を受けた点/学んだ点 一般的なデータ基盤の構成要素や登場人物について学ぶことができました。またデータレイク、データウェアハウス、データマートの三層構造やETL、データスチュワートなどの専門用語を改めておさらいでき、曖昧だった理解を深めることができました。 個人的な思い出として、この本を読んで僕がこれまでやっていた業務の内容が "データエンジニア" に近しいことがわかり、自分のことをデータエンジニアと名乗るようになりました。 特に印象に残った部分 三部の「データ基盤を支える組織」は特に勉強になることが多いです。組織デザインの部分では、事業や規模、時期に応じてアサインの仕方やチーム構成を変える考え方は、今の仕事にも取り入れています。直近アーキテクチャの見直しをチームで議論していたのですが、実現したい形とそれに応じたチームのあり方まで議論できたのはこの本のおかげだと感じています。 また、技術の話だけでなく、チェンジマネジメントやステークホルダーとのコミュニケーションについて記載されているところが印象的です。データ活用を浸透させようとした際に生まれる軋轢に対して経営層を巻き込みながら進めるという考え方は、これまでの経験から痛感しており、使えるデータ基盤を目指してアピールしていければと改めて思いました。 このような方におすすめ データ基盤プロジェクトを始めようとしている型やデータアナリストやデータエンジニアになりたい人、データ人材と一緒に仕事をする人にはぜひ手にとって読んでいただけると嬉しいです。 また僕と同じように4,5年データエンジニアを経験してきた人も読み直してみると新しい発見があるのでおすすめです。 宣伝 この本の著者であるゆずたそさんが、11月6日に開催のData Engineering Summitで登壇されます。「Data Engineering Guide 2025」と題してより現代に沿ったデータエンジニアリングついて話していただく予定です。こちらもよかったら参加していただけると幸いです。 data-engineering-summit.findy-tools.io 次は、キャリアプロダクト開発部でマネージャーを務める松村さんです。松村さんが選んだ一冊は、Rubyの「黒魔術」とも呼ばれるメタプログラミングの世界へと誘う書籍。この本との出会いが、gemのコードリーディングへの抵抗をなくし、さらにはgemの開発にまで発展したそうです。 ■ 松村さん / バックエンドエンジニア・マネージャー ■ キャリアプロダクト開発部 転職開発チームで主にバックエンドの開発をしているマネージャーの松村( @shakemurasan )です。 メタプログラミングRuby メタプログラミングRuby 第2版 作者: Paolo Perrotta オライリージャパン Amazon 私が紹介する「メタプログラミングRuby」は、タイトルの通りにRubyのメタプログラミングの概念や挙動について解説している書籍です。 この本を読んだきっかけ 当時勤めていた会社で、いくつか推奨書籍的なものがあったのですが、その中の一冊でした。 その時の上司から 「メタプログラミングがわからないと、gemの中身やRailsの挙動は理解できないから松村くんも読んでみるといいよ！ 後、黒魔術っぽくて面白いよ！」 的なことを言われて「黒魔術？？？」となったのを覚えています。 当時は「何がなんだかわからんが動いているのでヨシ！」の精神でgemを使っていたので、良い機会だから読もうかなとなったのがキッカケです。 本の内容 本書は、Ruby における「メタプログラミング」、つまり「プログラムがプログラムを記述・改変する」技術を丁寧に解説しています。 前半(第Ⅰ部)は、オブジェクトモデル、動的メソッド定義、ブロック／クロージャ、特異メソッド、コードを生成・評価する手法など、Ruby が持つ "魔術" 的な仕組みを順を追って解説しています。 後半(第Ⅱ部)では、実践として Ruby on Rails におけるメタプログラミングの事例(例:ActiveRecordの設計、ActiveSupportのConcernなど)を通じて手法の応用方法を紹介しています。 総じて、現実的なコードを読み解きながら「なぜそのように設計されているか」を理解できるようになっており、単なる言語機能の説明にとどまらず、Rubyという言語自体の設計思想にも踏み込んでいます。 後、角先生の翻訳本全般に言えることなのですが、原書のテイストを残したまま日本語としてもわかりやすく書かれていて、単純に読んでいて面白いです。 この本から影響を受けた点/学んだ点 とにかくRubyのコードを読んで、挙動を頭の中でシミュレーションするのが楽しくなりました。 「今どのクラスをさわっていて、そこにprependでこのモジュールを貼り付けてメソッドが生えたから〜」というのがクラス図として脳内でムクムク描かれていく。 そして頭がパンクして、実際にコンソールでancestorsを叩いてみて、フムフムこのクラスの継承木はそうなっているのかとまた解き明かしての繰り返し。 実践的なところで言うと、gemのコードリーディングをするのに抵抗がなくなりました。ライブラリのバージョンアップが来ても、コード差分を読み込むことで、自信をもってバージョンを上げられるようになります。 また、最終的に「メタプログラミングを実践してみたい！」という気持ちと、当時所属していた開発組織の課題が相まって、メタプログラミングを駆使してgemを作成してリリースしました。ファインディを受ける時も、この話題で現VPoE神谷とは盛り上がりました。 特に印象に残った部分 全部です！ と言いたいところなのですが、第3章「動的メソッド定義と特異メソッド」はメタプログラミングを支える柱と言っていいかもしれません。 3章ではメタプログラミングの核心部分である define_method 、 method_missing 、特異クラス(シングルトンクラス)を使った動的振る舞いの定義方法を具体例とともに学べます。 普段のRubyプログラミングではなかなか意識しない「オブジェクトのクラスやメソッド構造を動的に変えられる」仕組みを体感できます。 2章あたりまでで心が折れて積ん読になっている方は、是非3章までは読んでみることをオススメします！ このような方におすすめ Rubyを用いて定常的な開発・保守業務ができるようになった後、次のステップとしてディープダイブしたい方は読まれることをオススメします。 また、実行時まで挙動がわからないメタプログラミングはまだまだ生成AIが弱い領域だと思っていて、今の時代だからこそRubyエンジニアとして一皮剥けるために良い書籍だと思います。 最後は、同じくCTO室データソリューションチームの田頭さんです。田頭さんが選んだのは、第三次AIブームの到来を予見した先見性のある一冊。生物専攻からデータエンジニアへの転身を決意させた、AIの可能性を感じる一冊です。 ■ 田頭啓介さん / データエンジニア ■ CTO室データソリューションチームの田頭です。 人工知能は人間を超えるか ディープラーニングの先にあるもの 人工知能は人間を超えるか (角川ＥＰＵＢ選書) 作者: 松尾 豊 KADOKAWA Amazon 私が紹介する「人工知能は人間を超えるか」は、第３次AIブームまでに至るまでの人工知能の進化についてまとめられた書籍です。 この本を読んだきっかけ この本を読んだのは大学2年生の時です。当時生物専攻だったのですが、たまたま遺伝子解析でデータ分析や機械学習に触れる機会があり、人工知能について概観を知っておくために読みました。 本の内容 この本は、人工知能について一般読者向けに解説した入門書です。ディープラーニングに端をひらく第三次AIブームまでの歴史を振り返りながら、専門家と一般の人々の間にある人工知能への認識のズレを明らかにし、この先どのように生きていくべきかを考察しています。 この本から影響を受けた点/学んだ点 この本でデータやAIの可能性に強く惹かれたことで機械学習エンジニアを目指すようになり、現在のデータエンジニアとしてのキャリアに繋がりました。 特に印象に残った部分 改めて読み直したのですが、終章の「変わりゆく世界」が特に印象に残りました。実際に生成AIによって世の中が激変していく中、10年前の段階でここまでAIが発展している未来を予測できているのはすごいと感じました。 このような方におすすめ AIへの基礎的な知識を身に付けたい人におすすめです。 2015年出版当時から10年が経っていますが、AI活用が加速し、「人工知能」という言葉が溢れている今こそ読むべき内容だと思います。 おわりに 今回ご紹介した3名のエンジニアが人生を変えた一冊は、それぞれの専門分野や関心領域を反映した多様な選択でした。技術書との出会いは、単なる知識の獲得だけでなく、キャリアの方向性そのものをもたらしてくれるものです。 ファインディでは、さまざまなバックグラウンドを持つエンジニアが活躍しています。興味のある方は、ぜひこちらからチェックしてみてください！

こんにちは。Findy Tech Blog編集長の高橋（ @Taka_bow ）です。 前編では、グッドハートの法則の本質と、指標に圧力をかけることで開発現場がいかに歪められるか、そして"もっと悲観的に捉えるべきだった"理由を見てきました。 後編では、Beck氏が提唱する「価値の道すじ」の概念と、AI時代における測定の問題、そしてリーダーが実践すべき具体的なアプローチについて解説します。 前編はこちら tech.findy.co.jp 講演動画 ※ 視聴には Findy Conference へのログイン、並びに視聴登録が必要です。ご登録頂ければ、他の講演アーカイブも視聴できます。 日本語訳全文（続き） ソフトウェアが価値を生み出す4つの段階 Kent Beck氏： ではどうやって抜け出すのか？プログラミングのジーニー（生成AIのこと）についてお話しします。 ソフトウェアの価値を生み出す方法は？他にもありますが、私はプログラマーですから、今はソフトウェアの話をします。 まずは"労力(Effort)"の話です。プログラマーが何かのアプリのために、プログラミングに時間をかける。それが労力(Effort)です。 それは時間で測ることができます。 お金で測ることもできます。 その時間で他に何ができたかという機会費用で測ることもできます。とにかく最初の指標は労力(Effort)です。 アプリにボタンを追加したいとして、作るのにどれだけ時間がかかったか？プログラマーが労力(Effort)を費やせば、何かしら形になるものができます。これが"アウトプット"です。 今までなかったボタンが表示されます。よし、いいぞ。 労力(Effort)は比較的簡単に測定できます。アウトプットは少し難しくなります。 10個のボタンがあったら、５個のボタンより２倍良いのでしょうか？数えることはできます。まだ確信は持てませんが、それでもアウトプットの測定も比較的簡単です。 さて、アプリに新しいボタンがつきました。しかし、まだ価値は生まれていません。顧客が何か新しい行動を取るまではね。 顧客がこれらのボタンがあることの価値を認識し始めます。 "ここからここへのショートカットがずっと欲しかったんだ"、"今では新しいショートカットをいつも使っている"、"だからこのアプリがもっと好きになった"。 私が話している、"成果(Outcome)"とは、こういうことです。つまりユーザーの行動の変化なんです。 そして最終的に、私たちがプログラマーとして時間を費やして生み出した価値は、会社に戻ってきます。その形は収益の増加であったり、顧客満足度の向上であったりします。 コスト削減もまた、私たちの会社が収益性を上げる１つの方法かもしれません。 そして、そのプロセスの成果(Outcome)を収穫し、再び労力(Effort)に注ぎます。そうして会社は、プログラマーに報酬を払えるのです。プログラミングで報酬を得られるのはうれしいですね。 この、"価値の道すじ"のプロセスで、私が気づいたのは、"労力(Effort)"に近いほど物事を測定しやすいということです。 ですが同時に、指標は仕組みをゆがめる可能性があることを思い出してください。指標に圧力をかけると、仕組みの目標をゆがめてしまうのです。労力(Effort)の側に寄るほど、仕組みをゆがめる可能性が高くなります。 私は、若いプログラマーだった頃、より良いプログラミングをするために、より多くの時間を費やしました。 結論だけ言うと、それで自分を壊しかけました。週100時間以上働いて。 でも結局、それは無理なんです。念のため言っておきますが、やめてください。 時間は測定しやすく、制御も簡単です。しかしプログラミングに費やす時間を測定し制御しようとし、そして最適化しようとすると、良くない結果になります。 ちょっと右に移動しますね。少し難しい話になります。 ボタンを作るとして、それは難しいでしょうか？簡単でしょうか？ ボタンが２つあります、あなたが１つ作って、私が１つ作った。これは比較的、測りやすいですね。 労力(Effort)ほど簡単ではありませんが、比較的簡単に測定できます。そして私が話しているゆがみの影響(Impact)も少し小さくなります。 しかし、追加したボタンを誰かが気にしますか？成果(Outcome)が出るまで分からないんです。 "あなたはボタンを10個追加した、彼らは５個追加した"、"だから、あなたは２倍優秀だ"。 ですが顧客の行動を見るまでは、成果(Outcome)を比較することはできません。しかしユーザーの行動を注意深く観察すれば、アウトプットを比較することは少し簡単になります。 ではもし、あなたがボタンを追加することで、彼が追加したボタンが使いやすくなっていたら？その２つがそろって初めて、顧客がその機能を評価してくれるとしたら？ あなたが検索の速度を５倍にして、彼がグラフを追加する。高速になって、更にグラフがあるから、人々の行動が変わる。その場合、２つのチームの貢献度を切り分けるのは難しくなります。 どちらの功績かハッキリ言えません。こうして測定は更に難しくなります。 しかし、例えば、プログラマーの労働時間を測るか、顧客の行動変化を測るか。経営者として選ぶとしたら、私が測りたいのは100％、顧客がどう行動を変えたかです。プログラマーの頑張りには、あまり関心がありません。 そして、"影響(Impact)"の話に戻ります。 "この会社はどれくらい利益を出しているか？"、収益の増加は？コストの低下は？成長のスピードは？これらはすべて影響(Impact)の話です。 この時点でも測定は可能です。四半期ごとの財務状況もあります。しかし誰の功績なのかは分かりません。 "君が労働時間を増やしたから会社の利益が上がったね"。そんなことは誰にも分かりません、不可能なんです。 プログラマーが優秀でも、マーケティングの仕事がひどかったら？ そして収益性が変わらなかったら？ プログラマーの生産性とは関係ありません。その逆もあり得ます。プログラマーの仕事の出来が悪くても、マーケティングは優秀で収益性が上がっていたら？ 価値の道すじの中で先の方へ進めば進むほど、特定の人や特定のチームに価値を帰属させるのは難しくなります。しかし指標が仕組みをゆがめる傾向は弱くなります。 アメリカ企業がよくやるように、四半期の利益だけにこだわれば、さすがにこの仕組みはゆがみ、期待とは違う結果になります。 それでも、プロセスの初期でプログラマーにこう言うよりは、ゆがみは少ないんです。 "６時半に帰宅したのか、うちのチームは８時まで残ってるぞ"。 もしそんなレベルで制御するなら、確実にゆがみを生むでしょう。 "プログラマー１人当たりの収益性は？"の方がマシです。"プログラマー１人当たりの売上"、"１人当たりのコスト"も同じです。 AIが変えるもの、変えないもの さて、AIについて少しお話しします。 この会場でGene Kim氏に会えてうれしいです。（注：Gene Kim氏はもう一人の基調講演者です） Gene Kimは私を、AIベースのプログラミングに、"感染"させました。 私は、"拡張プログラミング"と呼んでいます。これが２ヵ月前か３ヵ月前のことで、それ以来、AIを使ったプログラミングを私は非常に楽しんでいます。 そして気づいたのは、機能を完成させるために必要な労力(Effort)が劇的に減ったということです。 さて、拡張コーディングの話は楽しいので何日でもできますが、今日はやめておきます。しかし時には労力(Effort)が増えることもあります。 AIというコーディング仲間は、とんでもなくバカなこともするからです。そこは覚悟してください。 しかし労力(Effort)は減り、プログラマー１人当たりのアウトプットは増えます。しかし労力(Effort)とアウトプットのレベルでの測定は、仕組みをゆがめることを思い出してください。 AIのおかげで10時間の作業が１時間でできたとしても、このプロセスをどう管理すべきかについては、何も変わらないのです。 もし私たちが、"10倍速くなったぞ、すばらしい、みんなに10倍の速さで作業させよう"、こんなことを言えば、仕組みにゆがみが生じることになります。 やはり私たちが重視すべきなのは、ソフトウェア開発全体を測定し、全体を意識することです。そうでないと、制御しようとして仕組みをゆがめてしまいます。 ジーニーでコーディングすれば労力(Effort)は減り、アウトプットは増えます。多分ね。 具体例を出します。人々は心配しています。 "ジーニーを使ったコーディングで若手プログラマーが不要になるのでは？"と。 シニアプログラマーの方が生産性が高いからです。"若手なんて必要ないだろう？"、"彼らは大きな混乱をより速く生み出すだけだ"。 私は選択の問題だと思います。 私はジーニーを教育用チューターとして使うのが好きです。Rustなどの理解できない言語でも、プログラミングをしてきました。Haskellとかね。そんなプログラムを見て思うことがあります。 この、"&&[~~"というのは一体何なんだ？そこで手を止めて、"これを説明して"と言うと、ジーニーがいつでも説明してくれます。 すばらしいことです。 若手を育てる際に、彼らの労力(Effort)やアウトプットではなくて、どれだけ学んだかで評価してはどうでしょう？ 例えば毎週の若手との会話の中で、こう聞くんです。 "今週、学んだことを３つ教えて"とね。"今週、追加した機能を３つ見せて"ではありません。 アウトプットを重視するか、学びを重視するかの選択です。長期的に見れば、雇用者にとっての価値を生み出すのは学びです。 若手は大量のコードを書くためにいるわけではありません。むしろ問題の種になることが多いので、大量のコードは書いてほしくないのです。でも早く学んでほしいと思っています。 そしてジーニーは、若手の学びを早める新しい手段となり得るのです。 もし私たちがアウトプットを重視するのであれば、学習に集中することで、確かにアウトプットは遅くなるでしょう。 それでも私は断然、学習を重視したいです。なぜならそれが長期的に見て、必要な価値を生み出すからです。 指標を見る人と行動が重要 私がめったに見ない質問は…。生産性の話に戻りますね。生産性とはアウトプットとインプットの比率です。 私がめったに見ないのは、"誰がこの数字を見るのか？"、"見た結果、どんな行動を取るのか？"という質問です。 もし最高財務責任者が、プログラマーの２割を解雇したいと思っているなら、どんな指標を当てはめようが同じです。ソフトウェア開発に恐ろしいゆがみを生むでしょう。 しかし例えば、現場のマネジャーが、部下が早く学ぶのを助けたいと思っているのなら、全く異なる見方になるでしょう。 私がいつも考えるのは、"単位は何か？"ということです。 "１日当たりの開発者１人当たりのPR"と誰かが言ったとします。しかし私が投資家の立場だとしたら、開発者のPRなんかに興味はありません。 会社の成長や収益性に何の影響(Impact)もありませんからね。"いつか株を売れるだろうか？"という判断に何の関係もありません。 "開発者の生産性を測っています"と言われても、それは私が気にかける単位ではありません。 投資家として気になるのは利益です。私はアウトプットもインプットも、金額で測定してほしいのです。 もし追加のプログラマーを雇うとして、生産性が1.4倍とか３倍とか７倍になると分かれば、プログラマーを雇うのは理にかないます。 しかし、"１日当たりのPR数が３件から６件になります"と言われても、プログラマーを追加で雇うべきなのか分かりません。しかし利益を見ることができれば、その数字を使って良い決断を下すことができます。 リーダーにできること ではどうすればいいでしょう？皆さんはマネジャーなのか、上級開発者なのか、リーダーシップを取る立場にあるとします。 まず最初に…、ちょっと気が滅入る話なのは分かってます。聞いてくださる皆さんに感謝します。できることは、いくつかあります。 １つ目は、"あとで確認すること"です。早い段階でしてはダメです。価値の道すじの初期段階で確認すると…、確認するだけでもダメですよ。 "タイムカードをつけよう"とかね。年配のプログラマーとしては、何か恐ろしいことの始まりだと思います。 または、"バグを自己申告しよう"とかね。私は疑い深いんです。 指標は労力(Effort)の側に近づけば近づくほど、仕組みをゆがめるので、あとで確認してください。そして、あとの段階で言ってください。 "これが開発者１人当たりの利益だ、達成する方法は問わない"、"でもこれが…"、"うちの開発者１人当たりの利益と、競合他社の開発者１人当たりの利益"、"どうするかは君たちに任せる"。 早い段階ではなく、あとで確認してください。会社への直接的な影響(Impact)が確認できないなら、成果(Outcome)を観察するのが良い方法です。ソフトウェア開発の有効性を評価するためにはね。 ２つ目のポイントは、意識向上の促進です。つまり、システムを速くするための最高の手法の１つは、システムの速度をグラフ化することです。何も言わなくていい。ただ…。 "これがこのシステムの速度です"というグラフを週に１度出すだけです。プログラマーはそれに夢中になり、改善したくなるでしょう。 "このグラフは何だ？なぜ上昇したんだ？"、"分からないな、自分で調べてみてよ"。リーダーはこれだけで意識を向上させられます。 圧力とは真逆です。リーダーとして圧力をかけないのは難しいことです。しかも圧力をかけると、仕組みにゆがみが生じます。 その代わりにできるのは、私が直面した中でも困難な課題ですが、目的を浸透させることです。どうチームに伝えればいいでしょう。 "ねえ、これを見て"、"本番障害がこのペースで起きなかったら、すばらしいと思わないか？"、"できるよ、私たちなら可能だ"、"今、何があれば、それを達成できると思う？"。 いけないのは、"本番環境で障害？君はダメなプログラマーだ"と言うことです。 それは圧力のアプローチです。押すのではなく、引くのです。 そのためには、リーダーとして現状に対する責任を持つ必要があります。そしてこう言います。 "私は障害が多すぎる環境を作ってしまった"、"でも今後はやり方を変えていきたい"。 この転換ができれば、グッドハートの法則に…。グッドハートの法則の悲観的な部分に、私たちは影響(Impact)を受けなくなります。指標に圧力をかけなければ、結果を変えずに測定できます。 代わりに、人々が最高の自分を目指すことを後押しできます。それは最高のレベルで創造し、共有する目標に全力を注ぐことです。その目標は揺るぎません。 私たちは、より大きな視点でソフトウェア開発を見ることを選んだからです。 ソフトウェア開発は、誰もが参加できる魔法のようなプロセスで、今でも成長を続け、私を驚嘆させ続けています。私たちなら目標を達成できます。 皆さんのお時間とご清聴に感謝します、ありがとうございました。 （会場拍手） ※ 講演後行われたサイン会は大盛況でした。 まとめ 25年ぶりの来日となったKent Beck氏の講演は、開発生産性の測定がもたらす根本的な問題を語るものでした。四半世紀の時を経ても変わらぬパワフルなメッセージは、私たちの開発現場の課題を深く考えさせられる内容でした。 講演から得られた重要なポイントをまとめます。 グッドハートの法則の真の意味 - 指標が目標になると良い指標ではなくなるだけでなく、仕組み自体を壊してしまう 測定と制御は別物 - 測定すること自体は価値があるが、指標でシステムを制御しようとすることが問題を引き起こす 価値の道すじ - 労力(Effort)→アウトプット→成果(Outcome)→影響(Impact)という流れの中で、測定しやすい指標ほどシステムをゆがめる AIは本質を変えない - AIで効率が上がっても、指標に圧力をかければシステムをゆがめるという本質的な問題は変わらない リーダーシップの役割 - 圧力ではなく、目的を浸透させ、意識を高めることが重要 Beck氏が最後に語ったのは、指標に圧力をかけなければ結果を変えずに測定できるということです。 つまり、測定そのものは続けながら、グッドハートの法則が引き起こす問題から逃れられる。測定は理解のため、意識向上のために使い、制御の手段にはしない。 この転換により、開発者は最高の自分を目指し、創造性を発揮できるようになります。単なる生産性向上のテクニックではなく、開発組織のあり方そのものを問い直す講演でした。 前編はこちら tech.findy.co.jp We're Hiring ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。Findy Tech Blog編集長の高橋（ @Taka_bow ）です。 2025年7月3日、ファインディ主催の開発生産性Conference 2025にて、エクストリームプログラミング(XP)の提唱者として知られるKent Beck氏による基調講演が行われました。 本記事では、Findy Conferenceで公開された講演動画とともに、全文の日本語文字起こしをお届けします。前編では、グッドハートの法則の本質と、それが開発現場でどのように機能するのかを解説します。 後編はこちら tech.findy.co.jp 講演動画 ※ 視聴には Findy Conference へのログイン、並びに視聴登録が必要です。ご登録頂ければ、他の講演アーカイブも視聴できます。 講演について Kent Beck氏は、アジャイル開発の礎を築いた開発者として世界的に知られています。 1999年に出版された『エクストリームプログラミング』は日本でも大きな反響を呼び、25年ぶりの来日となりました。 また、2024年には『Tidy First? ―個人で実践する経験主義的ソフトウェア設計』が出版され、現代のソフトウェア設計についての思想を発信し続けています。 Tidy First? ―個人で実践する経験主義的ソフトウェア設計 作者: Kent Beck オーム社 Amazon 今回の講演では、ソフトウェア開発の生産性測定におけるトレードオフと、単純な指標のリスクについて語られました。 講演タイトルの「グッドハートの法則はもっと悲観的に捉えるべきだった」は、イギリスの経済学者チャールズ・グッドハートが提唱した「指標が目標になると良い指標ではなくなる」という法則を指しています。 Beck氏はこの講演で、グッドハートの法則が示す問題は、実際にはグッドハートが想定していたよりも深刻であると主張しました。 開発生産性を向上させようとする試みがなぜ逆効果をもたらすのか。AIの台頭によってこの問題はどう変化するのか。リーダーは測定の目的と限界をどう理解すべきか。 Beck氏の講演内容をノーカットでお届けします。 日本語訳全文 オープニング Kent Beck氏： ありがとう。ありがとうございます。 （会場拍手） 日本に戻ってこられてうれしいです。皆さんのスマホがダンスのように一斉に上がりましたね。練習したみたいに。 （会場笑） 前回日本に来たのはもう25年ほど前になります。「エクストリームプログラミング」が出版された時です。 あの本は…ああ、笑顔が見えますね。日本で非常に人気の本でした。世界のどこよりも日本で人気がありました。 XPエクストリーム・プログラミング入門: ソフトウェア開発の究極の手法 作者: ケント ベック 桐原書店 Amazon （注：現在発売されているものは、 2nd Edition です） そこ（登壇者控え席）に座って、"どう話を始めようか？"と考えていると、前に来日した時のことを思い出しました。 大きな書店に行くと私の本が山積みで売られていて、"すごくいい気分だ、これが私の本だなんて"と思いました。 私は本にサインしようと１冊手に取りました。⋯⋯お持ちですね、後でサインします。 私は積んである本から１冊を手に取りレジに向かいました。そしてレジの女性にペンを借りてもいいか尋ねました。 彼女は私を見ました。 「違うんです、この表紙は私ですよ」と私は言いました。 （会場笑） 彼女は疑った様子でペンを貸してくれました。 本を開いて私が名前を書き始めると息をのむ音が聞こえました。私が落書きをしているように見えたんでしょうね、本の中にね。彼女は、"信じられない"といった様子で…。 私はただ本を山に戻して店から逃げ出しました。 それが私の前回の日本での経験ですが、戻ってこられてうれしいです。ファインディに感謝します。私を招待しこのセッションを実現させてくれてありがとう。 スポンサーの皆さんにも感謝を。きっとすてきな人々なので彼らの製品を買いましょう。これで、このセッション内での宣伝は終わりです。 開発生産性とは何か さて、今日は開発生産性について話すよう依頼されました。そして、これは一見とても単純な話に思えます。開発者がいて、彼らは何かを開発する。 生産性が高ければ良いことであり、生産性が低ければ悪いことです。では生産性を上げるには、どうすれば？ これは単純な話ではありません。あるドイツ語の単語があります、発音しませんが、"改善しようとして悪化させてしまう"という意味の言葉です。 補足 "verschlimmbessern"という単語のことかと思われます。"verschlimmern"（悪化させる）と"verbessern"（改善する）を組み合わせた造語で、善意で何かを良くしようとした結果、かえって状況を悪くしてしまうことを表します。 開発者の生産性に関して私が何度も目にしてきたのは、物事を改善しようと押し進めることで悪化させてしまうことです。 そして、招待されてから今日までの間にも、AIがその問題を良くするどころか更に悪くしてしまいました。 今日は、ある組み合わせについてお話しします。大事なのは組み合わせです。１つは開発者の生産性です、その定義についてもお話しします。 もう１つは測定の問題、つまり単純な指標が、しばしば意図した効果と逆の結果を引き起こすという問題。そしてAIの使用によりなぜそれが悪化してしまうのか？ 最後に、ここにいる皆さんは技術者ですから、"もっと早く"、"もっと生産性を高く"というプレッシャーに直面した時、この問題にどう立ち向かえばいいのか？ 今朝、一番上の子どもからメッセージが来ました。あるプロジェクトに30週間かかる予定だったのに、24週間ですべてを終わらせるように、そう指示されたそうです。 私の子ですから、"全部は終わりませんよ"と答えた。"でも、やるんだ"と言われ、"それは私の仕事じゃない"と返す。 私たちが常に直面していることですね。やることが多すぎるのです。そうでなかったら給料をもらいすぎということになる。 やることは常に山積みです。だからどんなに生産性を上げてもプレッシャーが軽くなることはありません。プレッシャーは常にあります。 私はAIを"ジーニー"と呼ぶのですが、それは…。ジーニーとは願いをかなえてくれるものです。願いを３つかなえてくれますが、与えられるものは願ったものとは違います。 かなったように見えるだけです。世界中の金を願ったらその金の下敷きになるとかね。それが今、私たちが扱っているものです。 おかげでこの問題はますます悪化しています。詳しく見てみましょう。 生産性の定義 まずは基本中の基本から。生産性とは何でしょうか？ 生産性とは比率です。アウトプットとインプットの比率であり割合です。そして、今はこれ以上詳しくは話しませんが、このあとの測定の問題を話す間、頭の片隅に置いておいてください。 話を戻します、生産性とは何を意味するのか？どうすればそれを悪い方向ではなく良い方向に役立てることできるのか？ マッキンゼーレポートへの批判 ２年ほど前のことです。コンサル会社のマッキンゼーが、開発生産性に関するレポートを発表しました。そしてそれは…、言葉を選んで話しましょう。礼儀正しく言えば"世間知らず"でした。世間知らずです。 "開発生産性を上げる"ための提案はどれも、状況を悪化させるものでした。経験ある開発者としては明らかにひどいアドバイスだと思いました。 そこで私は Gergely Orosz と一緒に、かなり話題になっていたこのレポートに対する批評を書きました。その後、解決のためにマッキンゼーに雇われてはいないので、どう解釈すべきか、分かりませんけどね。 これが開発生産性という問題に再び向き合うきっかけになりました。この話は最後にまた触れることにします。 補足 Kent Beck氏が言っているのは、2023年にマッキンゼーが発表したレポート"Yes, you can measure software developer productivity"（開発者の生産性は測定できる）の事です。 www.mckinsey.com このレポートでマッキンゼーは、従来のDORAやSPACEといった成果・最適化指標に加え、「機会指向メトリクス（opportunity-focused metrics）」を導入することで、開発組織の改善余地を定量的に把握できると提案しました。 開発活動を「Inner loop（コーディングやテストなどの価値創出作業）」と「Outer loop（統合・リリース・セキュリティ対応などの付随作業）」に分け、前者の時間を最大化することを理想としています。 また、Developer Velocity Indexや貢献分析を通じて、組織全体の生産性向上を体系的に評価する枠組みを提示しています。 発表された直後、Kent Beck氏は、Gergely Orosz氏（Uber、Skype、Microsoftに在籍経験のあるエンジニア。The Software Engineer’s Guidebookの著者）と共に反論をまとめています。 newsletter.pragmaticengineer.com グッドハートの法則 その前にまずお話ししたいのは測定の問題です。なぜ物事を改善しようとした取り組みが事態を悪化させるのでしょう？ ここで、ある古典的な言葉があります。グッドハートというイギリスの経済学者がいました。後ほどお話ししますが、彼はある観察をして、その観察は人類学者によってこう言い換えられました。 "指標が目標になるとそれは良い指標ではなくなる" これは完全に事実です。こう言われたとします。 "君はプログラマーだな、タイピングはどれぐらい速い？" "もっと速くタイプしろ" もし仮にタイピング速度と利益率に相関関係があったとしてもです。開発者はただ座って指をたくさん動かすようになるでしょうね。指を速く動かせば給料が上がるんですから。それは本当に求めていたものではありません。 指標自体は役に立つものですが、指標が目標になった途端、それは良い指標ではなくなってしまうのです。 これは言い換えられたもので、グッドハートの言葉ではありません。本来の彼の言葉は…。舌を噛みそうになる言葉です。 ある仕組みの中で統計的な規則性が観察されたとします。"これが上がると、これが下がる"というような規則性です。 しかし仕組みを制御しようとインプットに働きかけてアウトプットを変えると、その規則性は崩れてしまうのです。 例として、ある時期イングランド銀行が、借入の水準をコントロールしたいと考えていました。インフレ率を調整したかったのです。 そこで気づいたのは、短期金利を上げると借入は減り、短期金利を下げると借入が増えるということです。 統計分析の結果、このような規則性があることは世の理だと分かりました。短期金利が下がると借入が増え、上がると借入が減るのです。 彼らは思いました。 "やるべきことが分かったぞ" "我々はハンドルを手に入れた" "金利を上げれば借入を減らせる、下げれば借入を増やせる" "完璧だ" これは成功しました。短い間だけはね。 この方法の問題は、意思決定者が自分だけではないということです。銀行は金利を下げたり上げたりできますが、借り手にも選択権があります。 更に他の銀行が新しい金融商品を作って、短期借入金利の影響から顧客を守ろうとします。 最初のうちは確かに金利を上げれば借入は減りました。しかし、しばらくそれを意図的に繰り返していると、金利を上げても借入は減らなくなります。 なぜなら他のプレイヤーがそれに適応してしまうからです。 ここで、"指標が目標になると良い指標でなくなる"というグッドハートの法則の言い換えですが、その下にまた別の層があります。 それが元々グッドハートが言ったことです。 誰も読まないような地味な論文の脚注に書かれました。そんな脚注で有名になるとは、皮肉ですよね。 とにかく、統計的な規則性を見つけ、それを仕組みを制御するために使うと、それはもう制御手段としては機能しなくなってしまうのです。 さて、私はよくグッドハートの法則について話すのですが、それは最近ソフトウェア開発の指標が注目されているからです。 生産性もその１つですね。 深い層にあったグッドハートの元の言葉を見つけられて、うれしかったものです。 そこから考えるようになりました。世界はこれよりもずっと悪い状況なんじゃないかとね。これも悪いですよ。 つまりレバーがあって、それを引くと、最初はうまくいったとしてもしばらくすると何も起こらなくなる。 仕組みを制御できないということですから、これは悪い状況です。 しかし実際はもっと悪いのです。 測定は必要だが、制御のためではない 例を挙げましょう。 私はよく、ソフトウェア開発の測定を行う人たちと議論しているのですが、その際、ソフトウェアの測定方法についてたくさんの指標が提案されているのを耳にします。 先日LinkedInでこれについて少し書きました。私が受けた反応は"あなたはただ…" ⋯⋯何かな？慌てた顔も見えましたが大丈夫です。動かないようにします。（注：ちょっとした機材トラブルがあった模様） 私が指標に懐疑的なことを言うと誰かがこう返しました。 「あなたはただ何も測りたくないだけでしょう」 それは100万％違います。 私は自分のソフトウェア開発プロセスを測定しています。開発を始めてからずっとです。そして非常に価値があると思っています。 自分がやっていることを数値化して分析して解釈できるのですから。 しかしそれは、"このレバーでシステムを制御できる"という感覚とは全く別物です。人と話していて指標を提案されると私は、"でもこの場合はどうなる？"と聞きます。 私はソフトウェア開発というものを理解しようとしていますよ。私たち全員が参加できて、規模が変わっても機能する、魔法のようなプロセスです。 ソフトウェアの驚くべきところは、純粋な知的活動の中で、これほど規模を拡大できるものはないということです。 数学などにも同じような美しさがありますが、１つの定理に100万人の数学者を取り組ませることはできません。数学はそういうものではありませんが、ソフトウェアでは可能です。 さて、私はソフトウェアを測定して理解したい。 プルリクエスト(PR)を見てみましょう。プログラマー１人当たりの１日のPR数を数えることにします。 なぜなら、プログラマーを観察していると、非常に効率的に見える人もいれば、そう見えない人もいます。そして、全員により効率的になってほしいんです。 ここで気づいたのは、優れたプログラマーは小さいPRを多く出す傾向にあります。 小さなPRであれば読むのも簡単で、マージの際に他のPRとの競合も起きにくく、不具合が含まれる可能性も低くなります。読みやすければ、その分チーム全体で協力しやすくなります。 この矢印は小さなPRが多いほど読みやすいということを表しています。コードが読みやすければ協力しやすくなります。 そしてマルのついた矢印は逆相関を意味しています。協力が増えると無駄が減ります。そして時間の無駄が減るほど、PRを作る時間が増えます。 いい仕組みですね。これは自己強化型、または正のフィードバックループです。回せば回すほど速く回せるようになります。 これがすべてではありませんが、ソフトウェア開発で起きていることの一部は説明できます。 今のところは順調ですね。"開発者の１日当たりのPRは多いほど良い"いいですね。 さて、この仕組みに圧力をかけてみます。PRが多いほど良いなら、どう増やすか？圧力をかけます。 ではランキング表を作りましょう。 PRの多いプログラマーを上位に置き、そして…　 うげっ。（顔をしかめて見せる） PRの少ないプログラマーを下にします。そうやって圧力をかけるのです。多いほど良いのですから、これで数が増えて幸せになれるはず。ですよね？ 全然、違います。 これはソフトウェア開発チームにとって終わりの始まりです。 物事を改善しようとして悪化させています。誰だって一番下になりたくはないですからね。 それなりに筋の通ったPRが準備できると、わざわざそれを小分けにして出すようになります。 １件のPRが４件になり、いきなり以前の４倍になりました。 でもPRを細切れにしたことで、読みにくくなり、協力が減り、無駄が増えれば、PR件数も減ることになります。 しまった。では今度は４つではなく10件に分けて出しましょう。 皆さんはバカではないから、同じことをするでしょう。 誰も下位にいたくないからです。 つまり、ソフトウェア開発プロセスを改善しようと圧力をかけた結果、事態を悪化させてしまったのです。 さて、長い間プログラマーをやっていると、同じことが何度も繰り返されるのを見ることになります。私はキャリアの中で、こういうプロセスの流れを何度も見てきました。 コードの行数がプログラマーの生産性を測る正しい指標だと言われた時代もあります。生産性を測る人たちが気づいていなかったのは、私たちがプログラマーだということです。 プログラムを書くプログラムも書けるんです。 私をコードの行数で評価するというなら、コンピューターと同じようなすごい速さでコードを量産できます。 でもそれは最終的に求めるものではなく、むしろ逆の結果になっています。仕組みを良くするために圧力をかけることで悪化させてしまったのです。 グッドハートはもっと悲観的に捉えるべきだった このトークのタイトルは、"グッドハートの法則はもっと悲観的に捉えるべきだった"です。 彼の観察では、もし統計的な規則性があるならば…。例えば、"PRが多い開発者は効率的"というのが統計的な規則性です。 統計的規則性のある仕組みに圧力をかけると、規則性は崩壊するというのが彼の観察でした。 しかし実際は更に悪く、改善のため規則性に圧力をかけると、その規則性を生み出した仕組み自体を壊してしまうことになります。 ただレバーが緩んでしまうということではなく、レバーを引くことで、私たちの期待や意図とは真逆の結果になってしまいます。 だから、"もっと悲観的に捉えるべきだった"と言うのです。 規則性のある仕組みがあったとして、それを制御しようとしても、思ったようにはなりません。 PRのようなレバーを引くことで、意図した効果と逆の結果を得ることになってしまいます。なぜなら規則性を生み出した仕組み自体を壊してしまうからです。 指標にこだわりすぎる人たちは、この測定の問題を理解せず、こう言います。 "バランスの取れた複数の指標が必要だ"、"PR数だけでなく、欠陥の数も計測しよう"、"PRのレビュー時間も測ろう、それから…"。 これでは問題は解決しません。導入するすべての指標が仕組みをゆがめてしまいます。あなたが望まない方向にね。 仕組みをゆがめる指標が多ければ多いほど、その仕組みは理解しづらく制御しづらいものになっていくでしょう。 うまく開発するための指標のセットなんて存在しないんです。 意図はこうでしょう。 もし正しい指標のセットがあれば、"何も考えずに指標が改善するようにプログラムするだけで、すべてうまくいく"。 指標をどんどん導入するプロセスのゴールは、そこにあるように思えます。 それは私が望むものとは正反対です。プログラマーとして私はそんな風に扱われたくはない。考えることを後押ししてほしいし、自分の創造性に任せてほしい。 そしてこれらの思考と洞察と創造性のプロセスは、単純な数字に表せるものではありません。 （数値化しようとする）いかなる試みも、ソフトウェア開発に注ぎ込まれるべき思考、創造性、洞察を奪ってしまいます。 さて、先週このスライドを作りながら、私自身も楽観的すぎたと気づきました。システムは制御の圧力を軽減するために目標を放棄するだけでなく、ゆがんだ目標を採用してしまうのです。 例えば、"コード行数を増やす"、"PRを増やす"、"本番環境の障害を減らす"などの指標があります。 "障害を減らす"指標に注目します。本番環境での障害は避けたいですよね。そこで、"本番環境での障害をなくせ"と圧力をかければ、本番環境の障害報告はなくなるでしょう。 報告件数を減らす最も簡単な方法は、報告しないことだからです。 しかも相手は頭が良く創造的な人々ですから、数字をゼロにしろと言われれば、ゼロにする何らかの方法を見つけるでしょう。 これは仕組みをだましていると自覚するプログラマーにとって悪いことです。会社にとっても、顧客にとっても悪いことです。社会全体にとっても悪いことです。 これは人の働きを単純な数字で表そうとして、人間の判断を不要にして数字だけで制御しようとした結果です。 システムは目標を放棄するだけでなく、新しい目標を採用してしまいます。それは私たちが達成したい目標ではありません。これが指標に圧力をかけるということの本質です。 指標がどんなもので、いくつあって、どれだけバランスが取れていても関係ありません。 必要なのは、ここから抜け出す方法です。 後編に続きます 後編では、Beck氏が提唱する「価値の道すじ」の概念と、AI時代における測定の問題、そしてリーダーが実践すべき具体的なアプローチについて解説します。 後編はこちら tech.findy.co.jp We're Hiring ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub Copilot や Claude Code など、生成AIを活用した開発支援ツールが次々と登場し、日常的なワークフローに組み込まれつつあります。 生成AIを開発フローやプロダクトに組み込んだ事例を耳にする機会も増えました。弊社も例に漏れず、多方面で生成AIを継続的に組み込んでいます。 一方で「思ったような効果が出なかった」「むしろ生産性が下がったのでやめた」「効果の出る使い方がわからなかった」といった声も確かに存在します。 生成AIを導入したものの、思っていたような結果が出なかったと感じるとき、原因はAIではなく環境と人にあることが多いです。そこで今回は、その原因と解決策を紹介します。 それでは見ていきましょう！ プロンプトがわからない タスク分解 レビュー疲れ セルフレビュー Pull requestの粒度 思ったようなコードが生成されない ガードレール（迷わせない環境）整備 不要コードを削除 統一したコーディング規約 ドキュメント テストコード 生成AIと開発生産性、どちらが先か？ まとめ プロンプトがわからない 生成AIに依頼する内容が思い浮かばない。Vibe Codingに入るきっかけがわからない。長文を一気に渡して生成AIが混乱する。要件が頭の中に留まり言語化できない。要求がイシューやチケットに分解されず認知負荷が高止まりしている。このような経験をした読者の方も少なくないと思います。 根本的な原因を突き詰めると 人間が問題を十分に分解・言語化できていない ことが大きな要因となっています。生成AIは整理の補助にはなりますが、曖昧な思考を自動で明確に構造化する“魔法”ではありません。 タスク分解 最初の一歩はタスク分解です。「何を / なぜ / どうやって」を説明できる粒度まで言語化できたら、初めて生成AIに委ねる土台が整います。 いきなり生成AIに依頼するのではなく、まずは依頼主が理解することが重要です。 これがなぜ重要かというと、依頼主が理解していないタスクを生成AIに依頼しても、期待した結果が出力されることも、出力された内容が正しいかどうか判断することもできないからです。 生成AIに依頼する内容を自分自身が理解できているのか、内容そのものの認識や方向性が間違っていないかを判断するためにも、まずはIssue等に書き出してタスクリスト化することをおすすめします。 タスク分解については過去記事でも紹介しているので、ぜひ読んでみてください。 tech.findy.co.jp レビュー疲れ レビュー疲れの主な要因の1つは 人間が理解しづらいPull requestを大量に作成している ことに起因します。 ジュニアエンジニアが生成AIを使って出力したコードを理解せず、そのままレビュー依頼を出してリードクラスのエンジニアのレビュー負担が増加している。というケースをよく耳にしますし、実際にこの目で見たこともあります。 つまり質の低いPull requestが大量に作成され、そのレビューに追われているという状況なのです。 これは AIを使っている というよりも、 AIに使われている 状態と呼ぶのが近いかもしれません。 セルフレビュー 生成AIが出力したコードを理解した上でレビュー依頼を出すことが大事です。ここで重要なのは、読むだけではなく読み解いて理解するということです。 Pull requestの作成者自身が説明できない内容のままでレビュー依頼を出すのは、基本的にNGであるはずです。これは生成AIの有無に関わらず、普遍的な価値観といえます。 Pull requestをセルフレビューして、解説や説明が必要なのであれば、公式ドキュメントなどの一次情報を参照して、理解して解説するレビューコメントを残しましょう。これだけでレビューの負担は下がります。 生成AIが出力したコードの責任は人間にあります。 出力してもらったコードに自分自身が責任を持ちましょう。 Pull requestの粒度 要件をすべて同じPull request内で実現しようとしない方が良いです。 同じPull request内で多くの事を実現しようとすると、 生成AIが一度に認知すべきコードの範囲が広がってしまい、出力されるコードの質が落ちます。 また、 一度に広い範囲のコードを変更することで、レビューの負担も上がってしまいます。 仮に生成AIにレビューしてもらったとしても、コンテキストが大きくなるので精度が落ちてしまいます。 適切なPull requestの粒度を維持するためには、前述したタスク分解が重要となってきます。 要件を実現するために必要なタスクに分解して、そのタスクごとに生成AIにコード生成してもらいPull requestを作成することで、出力するコードの質だけでなくレビューの質にも繋がってくるのです。 AIに使われないためにも、タスク分解とPull requestの粒度の考え方は今後ますます重要となってくるでしょう。 Pull requestの粒度については過去記事でも紹介しているので、ぜひ読んでみてください。 tech.findy.co.jp 思ったようなコードが生成されない 「出力したコードの命名や規則がバラバラ」「ルールから逸脱したコードが出力される」「既存コードが壊れてしまう」このようなコードを生成AIが出力する背景には 生成AIが迷ってしまう環境 があります。 生成AIが迷わないように生成AIフレンドリーな開発環境を整えましょう。 ガードレール（迷わせない環境）整備 不要コードを削除 生成AIは現時点のリポジトリ情報を根拠に推論することがあります。 不要なコードが残っていることで、生成AIが余計な内容まで学習してしまうことに繋がっています。 不要コードは存在そのものがノイズと化します。まずは不要なコードやモジュールを削除しましょう。 統一したコーディング規約 Google Style Guide 等を参考にして、統一したコーディング規約をルール化しましょう。 コードのルールが一貫していると、生成AIはそのルールのみを学習するため迷いにくくなります。 その結果、出力されるコードにも一貫性が生まれ、質の高いコード生成に繋がります。 ドキュメント 実装コードだけではなく、ドキュメントも重要です。 READMEやカスタムインストラクションだけに留まらず、docコメントやAPIドキュメント、型定義ファイルなどは生成AIがコードの意図を理解するために非常に有用です。 テストコード テストコードは生成AIが仕様を把握するための情報源になるだけでなく、暴走しないためのガードレールの役割も担います。 生成AIが出力したコードが原因で既存のテストコードが失敗した場合、エラーメッセージをチェックして何がどう間違っていたのかを生成AIが学習できます。 その結果、テストコードのエラーの内容を元に生成AIが実装、テストコードを修正できます。この時、テストが落ちた原因が実装コードにあるのか、テストコードにあるのかの判断を間違わないようにするのがポイントです。 このように 思ったようなコードが出力されない原因は、そもそも生成AIが迷ってしまうようなコードの質、環境にあります。 生成AIが出力するコードの質は現時点でのコードの質と比例するのです。 ガードレール整備については過去記事でも紹介しているので、ぜひ読んでみてください。 tech.findy.co.jp 生成AIと開発生産性、どちらが先か？ これまで見てきた現場で、生成AIを導入して効果が出ていないケースの原因は、 生成AIを活用できていない のではなく 生成AIを活用する準備ができていない というものでした。 事前準備や環境、ガードレールの整備などの日々の小さな積み重ねが重要です。まずは 生成AIと自然に協働できるAIフレンドリーな環境 を目指しましょう。 結局のところ、やるべきことは変わらないのです。 人間の開発生産性を上げることが、生成AIフレンドリーな環境、ガードレール整備に繋がります。 生成AIで開発生産性は上がりません。高い開発生産性をさらに上のレベルへ引き上げるものが生成AIなのです。 生成AIを活用して効果を出したいのであれば、まずは人間の開発生産性に投資することをおすすめします。その結果、新メンバーとして生成AIを招待して活躍してもらえる環境が整うのです。 まとめ 今回の内容は先日開催した D-Plus Fukuoka でも紹介させてもらいました。 こちらがその時の資料となります。ぜひ参考にしてみてください。 また、 11月13日(木)に福岡で Findy AI Meetup の開催が決定 しました。 今回は YAPC::Fukuoka の前日の開催 です。県外からの参加者のみなさん、前日入りしてこちらへの参加もぜひ検討ください。 findy-inc.connpass.com 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

はじめに 課題 API利用ができない 機能不全に陥った検索システム 最低限のログ機能 画像品質の悪化 要件 実現方法 システムアーキテクチャ ドキュメントのバージョン管理 必要な情報が見つかる検索エンジンの搭載 画像の画質の保持 閲覧できるユーザーの制限 結果 成果 AIによるドキュメント作成 CLI上でのドキュメント検索 今後の展望 総評 はじめに データソリューションチームの土屋 ( @shunsock )です。 データソリューションチームでは、従来、GUIベースのドキュメント管理ツールを利用していました。しかし、検索体験の悪さや画像の画質低下といった課題を抱えていました。 そこで、CLIベースのドキュメントホスティングシステムを独自に構築しました。 本稿では、CLIベースで構築したドキュメントホスティングシステムの設計と実装について紹介します。 課題 ファインディでは従来、GUIベースのドキュメント管理ツールを全社で、開発チームの一部がCLIベースのドキュメント管理ツールを利用していました。データソリューションチームでは、全社で利用しているドキュメント管理ツールを利用していたのですが、次のような問題点がありました。 API利用ができない APIそのものは提供されているサービスだったのですが、社内規定で利用できませんでした。この影響で、API経由で解決できそうな課題の解決も既存ツールでは難しいという判断になりました。 機能不全に陥った検索システム 課題となっていたのは検索システムの弱さでした。従来のドキュメントツールは全社的に利用されていたため、さまざまな部署のドキュメントが一箇所に集約されていました。 しかし、検索結果に他チームのドキュメントが多数混在してしまい、必要な情報を見つけるのが難しい状況でした。通常はタグなどでドキュメントを検索可能にしますが、その機能がありませんでした。 具体的には、「設計書」と検索すると「他チームの設計書」に埋もれて「自チームの設計書」が見つけられないといった事象が発生していました。 最低限のログ機能 既存サービスでは、ドキュメントの最新のアップデートの時間以外の情報が表示されません。なので、誰がいつドキュメントを更新したのかを追跡できませんでした。 これにより、ドキュメントの信頼性が低下し、情報の正確性を保証することが困難でした。 画像品質の悪化 さらに、画像の品質劣化はドキュメントの可読性に大きく影響し、業務に支障をきたしていました。 次の写真は、実際に既存システムにアップロードされた画像です。元の画質は 1920x1080px なのですが、明らかに劣化しています。この写真がCMSの小さいカラムの中で表示されるので、読めなくなってしまうのです。 画像の文字が潰れた時は、別のシステムで画像を載せてそこのリンクを貼るといった運用をしていました。 要件 上記の課題を達成するために、次の要件を定義しました。 ドキュメントのバージョン管理 必要な情報が見つかる検索エンジンの搭載 画像の画質の保持 閲覧できるユーザーの制限 また、ドキュメントホスティングシステムは直接ROIに響かないため、低コストで実装する必要がありました。今回紹介するシステムは私一人の片手間で開発したものです。 実現方法 1 - 3 は 静的サイトジェネレーターで、4はCloudRun & IAPで実現しました。 システムアーキテクチャ 今回は、チームでも利用の活発なGoogle Cloudを利用しました。Google Cloud Run上にVitePress (後述) をホスティングし、IAP (Identity-Aware Proxy) を利用してアクセス制御を行います。ドキュメントやインフラストラクチャはGitHubで管理しています。 次に、前述した要件に対してどのように解決したかを説明します。 ドキュメントのバージョン管理 ドキュメントホスティングフレームワーク「 VitePress 」で解決しました。VitePressは、Markdownをベースにした静的サイトジェネレーターです。 このシステムをGitHubで管理し、バージョン管理を実現しました。 必要な情報が見つかる検索エンジンの搭載 現行の検索エンジンが問題になっていた要因として、検索対象の広さがありました。今回のプロジェクトで検索対象が自チームのみになり、解消されました。 ちなみに、VitePressでは検索機能の実装が簡単です。 config.mts に次のように記述すると検索が有効になります。 import { defineConfig } from 'vitepress' export default defineConfig( { // ... themeConfig : { search : { provider : 'local' // このブロックでローカル検索が有効になる } , } // ... } ) 次の画像は実際の検索画面です。マッチした部分をハイライト付きで確認できます。(業務内容に関わる部分はモザイクをかけています。) 画像の画質の保持 この問題も VitePress の導入で解決しました。 次の画像は本記事で紹介したシステム設計図の写真を元のシステムとVitePressで表示したものです。1枚目が元のシステムで表示したもの、2枚目がVitePressで表示したものです。VitePressでは、画像の品質が保たれていることがわかります。 閲覧できるユーザーの制限 社内ドキュメントを配信するので、閲覧制限を入れる必要がありました。 今回は Cloud Run と IAP (Identity-Aware Proxy) を利用して、閲覧できるユーザーを制限しています。 以前は、ロードバランサのリソースを作成しそれにIAPを紐付ける必要がありました。Google CloudからCloud Runに直接IAPを紐付ける機能が執筆時から数ヶ月ほど前に公開されたため、今回のシステムではこの新しい機能を利用しました。この機能のおかげでとても簡素なインフラ構成になりました。 https://blog.g-gen.co.jp/entry/using-iap-with-cloud-run 結果 成果 これらの取り組みにより、設定していた要件をすべて達成しました。さらに、GitHubに集約したことでAIとの協業がしやすくなりました。ここでは、ドキュメント作成・検索におけるAIの活躍を紹介します。 AIによるドキュメント作成 GitHubにドキュメントが集約されたことで、ドキュメントにAIが貢献しはじめました。次の写真は作成したホスティングシステムのHistoryです。直近ではDevinの関与しているコミットが80%を越えています。 次の画像は、 NeoVim と copilot.nvim を利用してAIがドキュメント提案をしている様子です。（灰色の部分がAIの提案） また、次の写真は Devin を利用してドキュメントの更新をしている様子です。編集者は、エディタを開かずにドキュメントを更新しています。 CLI上でのドキュメント検索 GitHubにドキュメントを集約したため、ghコマンドとAIエージェントを組み合せた検索ができます。次の写真ではClaude Codeでドキュメント内のGetting Started (=チュートリアル) を検索しています。 Claude Codeにプロンプトで検索を命令します。ここでは検索にghコマンドが利用できると伝えています。 Claude CodeがGetting Startedの一覧を出力していました。試しにgithub2slack (レビュー依頼の情報をSlackに通知してくれる社内向けアプリ) のGetting Startedの詳細を調べます。 このようにCLI経由の検索が簡単にできるようになりました。この検索機能は、「DesignDocや詳細設計書を参照しながら実装をClaude Codeでする」など様々なシーンで応用が効きます。 今後の展望 作成したシステムは概ね満足できる水準であったものの、いくつか改善点が見付かっています。 例えば、画像ファイルの保存方法です。作成したシステムでは画像を直接GitHubのリポジトリに載せています。チームメンバーに圧縮を依頼し、現段階では問題になっていないです。しかし、今後pushやデプロイ速度低下の懸念があるので、画像配信方法を改善する予定です。 また、GitHub Actions などで一定期間編集されていないドキュメントを集約し、更新を促すオペレーションを回そうと考えています。 総評 今回の仕組みは、「GUI前提のツールでは満たせなかったニーズを、限られた工数で解決できた」好例になったと考えています。 私の本業はデータ基盤の構築ですが、その片手間で開発・運用可能なレベルにシステムを簡素化できたことは、再現性や他チーム展開の観点でも有意義です。 今後もドキュメントを拡充して、オンボーディングの高速化やサイロ化の回避に貢献していきたいです。

こんにちは。Findy Tech Blog編集長の高橋（ @Taka_bow ）です。 エンジニアの仕事は、常に頭をフル回転させる必要があります。 複雑な問題と向き合い、コードと格闘する毎日の中で、ランチタイムは貴重な気分転換の時間。 美味しいものを食べて午後の活力をチャージし、心も体もリフレッシュする――そんな「元気の源」となるランチを持つことは、エンジニアにとって大切なことではないでしょうか。 今回は新シリーズ「エンジニア達の元気になるランチ！」の創刊号として、 天ぷら特集 でお届けします！ 1本目は私が大崎オフィス近くの穴場的天ぷら店を、2本目は福岡県民に愛される天ぷら処をご紹介します。それぞれ異なる魅力を持つ2軒、どうぞご覧ください！ 東京・大崎：てんぷら 天富 福岡・天神：天麩羅処ひらお おわりに ■ 高橋裕之 / CTO室 / Staff Engineer ■ 開発プロセスの改善が専門で、問題の可視化・分析から現場での改善実行まで、チームのパフォーマンス向上を支える『仕組み』作りをしています。 普段は、大崎オフィスで働いています。 東京・大崎：てんぷら 天富 私が紹介する元気になるランチは、揚げたての天ぷらが美味しい穴場的お店、 てんぷら 天富 のランチです！ お店の基本情報 場所 : 品川区大崎（大崎駅西口から徒歩約4分、大崎広小路駅から徒歩5分） ファインディオフィスからは、徒歩7分ぐらいです！ 営業時間 : 平日ランチ時間 11:30〜14:00終了 価格帯 : ランチ 1,320円〜4,400円（注：現金のみ） 雰囲気 : 落ち着いた小綺麗な定食屋さんのような雰囲気、カウンター席とテーブル席あり 脇道の奥にそっと佇むお店です。 初めて行くとお店の中が見えないのでどきどきしますが、安心してください。 お店はとても小綺麗で、カウンターとテーブル席があります。 そして、吉永小百合さんのサインが飾ってあります。しかし、吉永小百合さんをご存じない同僚がいました。世代間の断絶…… ランチメニューはこんな感じです。物価上昇のご時世ですが、天ぷら屋さんとしてはお手頃価格ではないでしょうか！ 今回は、ちょっと奮発して「天ぷら定食 松？」￥1,760 を頼みました！ 私はごはん大盛りにしてしまいましたが、これにはキケンが伴います。理由は後ほど。 季節のお野菜を中心に、揚げたてサクサクです。天ぷらはこれだけではなく…… お食事途中で、あなごの天ぷらが追加されます。長い！でかい！おいしい！（語彙力） なんと！最後はかき揚げのミニ天丼が届きます。 実質、おかわりです。 ですので、ごはん大盛りには気をつけましょう（笑） 本格的な天ぷら定食を堪能してきました。 つぎは天ざるにチャレンジしたいと思っています！ みなさんも、食べてみて！ 「てんぷら 天富」は、大崎オフィスから徒歩7分ほどの場所にある、本格的な揚げたて天ぷらを手頃な価格で楽しめる穴場的なお店です。途中で追加されるあなごの天ぷらや、最後のミニ天丼など、サプライズ感も魅力的です。 続いて2本目は、福岡からフルリモートで働くAI推進チームの戸田さんの推しランチをご紹介します。 ■ 戸田さん / AI推進室 / テックリードマネージャー ■ こんにちは。ファインディのAI推進室でテックリードマネージャーをやらせてもらっている戸田です。 普段は福岡からフルリモートで働いている僕がオススメするランチは、福岡県民なら誰もが知るあの 天麩羅処ひらおです。 福岡・天神：天麩羅処ひらお お店の基本情報 場所 : https://www.hirao-foods.net/shop/ 遠方からであれば天神アクロス店がオススメ 営業時間 : 10：30～20：00 価格帯 : ランチ 1000円前後（注：現金のみ） 今回は駅からのアクセスが便利な天神アクロス店を紹介します。天神駅の改札を出て地下道を歩いて徒歩3分の好立地です。 入口はこんな感じです。11時半の時点で既に店内は行列ができています。休日になると店の外にも行列ができていますが、回転率が高いので思ってるより待たされない印象があります。 メニューはこんな感じです。 食券を買って待機列で待ちましょう。順番が来たら席に呼ばれます。 すると天ぷらよりも先にこれが出てきます。 イカの塩辛です。これ目当てでひらおに行く人もいると言われています。定食を買うと小皿で出てくるのですが、これと白ご飯の相性が良すぎて、天ぷらが出る前にこれと白ご飯だけでお腹いっぱいになることもしばしばあります。 イカの塩辛はお土産用でも販売しているので、ぜひ一度お試しください。 イカの塩辛で満足したころにメインの天ぷらが出てきます。この時初めて、イカの塩辛が前菜だったことに気づきます。 ひらおは揚げたての天ぷらが完成した順番に席にデプロイされるシステムとなっています。 サクサクの衣と新鮮な具を堪能しましょう。 福岡では11月に PHPカンファレンス福岡 や YAPC::Fukuoka を始めとした大規模イベントが予定されています。 県外からの参加者のみなさん、是非ランチに 天麩羅処ひらおをよろしくお願いします。 なお、YAPC::Fukuokaの前日にはFindy AI Meetup in Fukuokaも開催予定です。県内外からの参加者のみなさま、こちらの参加も是非ご検討ください。 findy-inc.connpass.com 戸田さんの紹介する「天麩羅処ひらお」は、福岡県民なら誰もが知る人気店です。天ぷらよりも先に出てくる名物のイカの塩辛、そして揚げたてを次々とデプロイしてくれるスタイル――一度行くと、また「天麩羅処ひらお」にリトライしたくなる美味しさです。福岡を訪れる際は、ぜひ立ち寄ってみてください。 おわりに 今回は天ぷら特集として2軒のお店をご紹介しました。どちらもエンジニアの皆さんを元気にしてくれるランチです。 なお、ファインディには 「社内コミュニケーション補助」 という制度があります。他部署のメンバーとランチに行くと会社が補助してくれるというもので、組織を超えた交流のきっかけづくりに役立っています。美味しいランチを食べながら、新しい出会いやアイデア交換ができる、まさに一石二鳥な制度です。 また、今回ご紹介したように、ファインディでは全国各地からさまざまなエンジニアが活躍しています。技術にこだわり、より良いものを追求する仲間とともに働いてみませんか？ 現在、新しいメンバーを募集しています。興味のある方は、ぜひこちらからチェックしてみてください！

こんにちは。Findy Tech Blog編集長の高橋（@Taka_bow）です。 この記事は 自慢の作業環境を大公開シリーズ の第7弾になります。今回も、3名のエンジニアの作業環境を紹介します！ 今回最初にご紹介するのは、Team+開発部の鄭さんです。 ■ 鄭さん / Team+開発部 / バックエンドエンジニア ■ Team+開発部・ROI①チームの鄭智允です。 今年5月にファインディにジョインし、直近ではCopilot Reportとコーディングタスク分析の開発を担当しました。 基本的にはフルリモートで働いていますが、コミュニケーションを円滑にするため週に1回程度出社しています。神奈川県に住んでいるので出社は問題ありませんが、より集中できるリモートワークの方が私には合っています。 作業環境については、集中力を妨げないよう静かで視覚的に邪魔にならないことを重視しています。そのためデスク上には必要最低限のものだけを配置し、仕事への集中力を維持しています。 この作業環境はコロナ禍で在宅勤務が始まって以来、一貫して変わっていません。 デスク周り全体 デスク 電動昇降式デスクを使っています。コロナ禍で購入したもので、モニタアームを2台設置したことで真ん中がやや下がっているのですが、高さ調整は問題なく機能するので満足しています。 ディスプレイ ゲーミングモニターを2台配置しています。2010年代に購入したものなので少し古く、写真は控えめにしています。解像度は最新のものほどではありませんが、仕事をする上では十分に機能しています。 必要に応じて、iPadを縦向きにして3台目のモニターとして活用することもあります。 キーボード 韓国ハンソンという企業のキーボードを使用しています。 韓国で購入したものです。見た目はシンプルですが、Macにも対応しています。横に数値パッドがあるタイプが私の好みです。 静かでありながらも適度な打鍵感があるため、長く愛用しています。 マウス Logicool社の無線マウス と、バーティカル有線マウスを併用しています。普段は無線マウスを使用していますが、首に疲労を感じた時はバーティカルマウスに切り替えています。 ロジクール ワイヤレスマウス M331nWH 静音 ワイヤレス マウス 無線 3ボタン 電池寿命18ケ月 USB接続 M331 windows mac chrome ホワイト 国内正規品 Logicool(ロジクール) Amazon Logicool社は非常にコスパが良いと感じています。高品質で耐久性に優れているだけでなく、静音性の高い快適な使用感が気に入っているため、いつもこのブランドを選んでいます。 バーティカルマウスは軽量タイプが自分に合っているため、少し不便ではありますが有線タイプを使用しています。バーティカルマウスは自分の手に合うものを選ぶことが重要で、3回目の購入でようやく自分に合うものを見つけることができました。 こだわりのアイテム紹介 引出し 手書きメモが好きで、紙やペンを側に置いておく必要があるタイプなのですが、昇降式デスクの場合は引き出しがないケースが多いので、自分で作りました。 下の写真のように収納（引出し）をテーブルに取り付けています。片方にはメモ帳を、もう片方にはペンなどを入れています。 スピーカ 疲れた時は、 Anker製のBluetooth スピーカー を使用して音楽を聞いたりしています。 Anker Soundcore 3 Bluetooth スピーカー/ IPX7 防水/チタニウムドライバー/デュアルパッシブラジエーター/BassUpテクノロジー/アプリ対応/イコライザー設定/USB-C接続/ 24時間連続再生/ PartyCast機能/お風呂で使用可能/プレゼントやギフトに最適/ブラック Soundcore Amazon 携帯性に優れているのが魅力で、防水機能も備わっているため、キッチンで料理をする時にも使えますし、様々な場所に持ち運んで活用しています。 リモートワークでの工夫 日常的な外出習慣 昼間は毎日10分でも外に出て散歩するようにしています。コロナ禍で実感したのは、家に引きこもり続けると徐々に意欲が低下してしまうということです。忙しい時期には近所のコンビニへの往復程度しかできませんが、余裕がある時には食事を30分ほどで済ませ、外の空気を吸いながらリフレッシュする時間を大切にしています。オフィスに出社する日でも、昼間には必ず外出するようにしています。 今後導入したいもの ハーマンミラー チェア 長時間座っていても疲れにくく、着席感が非常に良いという評判をよく耳にするので、とても興味があります。 曲面モニター 最近興味を持ち始めました。ゲームには適しているようですが、仕事での活用価値については少し気になっています。 （参考）CTO佐藤さんの曲面モニター 鄭さんの作業環境では、韓国製キーボードとLogicoolマウスの組み合わせ、そして自作の引き出しによるデスクの最適化が特徴的です。また、リモートワーク下でも毎日欠かさず外出する習慣を通じて、仕事と生活のバランスを保たれている点も参考になります。 続いては、同じくTeam+開発部の澁谷さんをご紹介します。 ■ 澁谷さん / Team+開発部 / バックエンドエンジニア ■ Team+開発部・Enhance②チームの澁谷恭平です。 ファインディには2025年4月に入社しました。宮城県よりフルリモートで勤務しています。 直近ではNotion連携の開発に携わり、サーバーサイドを担当しました。 数年間自分の自室に作業スペースを確保していましたが、今は「家族と同じ場所にいながら作業ができる」をモットーに環境を整えています。 昇降式、デスク付きエアロバイク、MetaQuestでバーチャルディスプレイなど色々な環境を試し、現在はシンプルな形に落ち着いています。 デスク周り全体 移動式の小さなテーブルにいろんなものをくっつけ、リビングの一角に設置しています。 子供と家に二人の状況も多々あるため、家族といながら作業ができるようにしています。 デスク ニトリの折りたたみデスクを使用しています。 これ単体だとかなり狭いためキーボードトレーを装着してスペースを確保しました。 このトレーが意外に重く、モニターアーム側とのバランスを良い感じに整えてくれています。 またデスク右にはカップホルダー兼小物入れも装着し、できるだけデスク上を広く活用できるようにしています。 ETHU キーボードスライダー 後付け クランク式 天板2枚接ぎ 幅500*奥300mm スライドスムーズに 人間工学 姿勢改善 キーボードトレイ マウス収納 引き出し付き ホワイト ETHU Amazon マシン 私物のPCはMac Miniを愛用。小さい、安い、パワフルでとても重宝しています。 社用PCはデスク裏へ設置したPCホルダーに入れており、デスクを圧迫しない工夫をいれました。 ディスプレイ innocnのワイドディスプレイを使っています。 低価格ながらWFHD対応、Type-C給電にも対応しておりコスパがいいです。 INNOCN 29インチ モニター ウルトラワイド モニター 21:9 2560x1080 ディスプレイ パソコン モニター ワイド ディスプレイ sRGB DCI-P3 350cd/㎡ HDR機能 高輝度 縦横回転 対応 Type-C対応 PIP/PBP画面分割 ADSパネル ブルーライト軽減 3辺狭額縁 HDMI DP スピーカー付き TÜV認証済 (29インチ) INNOCN Amazon 会社用PCは基本クラムシェルモードのため、サブディスプレイとしてモバイルディスプレイを利用しています。 Intehill モバイルモニター 4K+ 13.4 インチ タッチパネル IGZO ノングレア 護眼 超高精細338PPI（3840x2400）16:10黄金比 500ニット 超軽量 モバイルモニター アルミ 筐体 1500:1 sRGB100% HDR対応 VESA デュアルUSB-C/HDMI 対応 保護カバー付き (U13ZT) Intehill Amazon キーボード apple純正です。HHKBや分割キーボードも利用してきましたが今はここに落ち着いています。やはりTouch IDは便利ですね。気分転換で別のキーボードも使ったりします。 マウス 安定のロジクール M575です。旧モデルから愛用しています。 ロジクール 静音 ワイヤレス トラックボール マウス M575SPGR Bluetooth Logibolt 無線 windows mac iPad OS Chrome トラックボールマウス グラファイト M575 M575SP 国内正規品 Logicool(ロジクール) Amazon こだわりのアイテム紹介 椅子 ハーマンミラーのセイルチェアを使用しています。長時間座っていても腰や背中の痛みが少なく感動しました。 肘掛けにはクッションをつけており、長時間利用しても肘が痛くならないようにしています。 HDMI USBデバイス切り替え機 UGREENの製品を使用しています。 会社PCと私用PCのケーブル脱着が面倒なこともあり、手元のボタン一発でディスプレイとデバイス接続を切り替えられるようにしました。 切り替え機本体はデスク下に設置。 手元のボタンでHDMIやキーボード、マウスなどの接続を切り替えられる。 リモートワークでの工夫 自室だとどうしても家族との時間が取りづらくなりますが、このスタイルにしてから「家族のことを考えると、○時から作業できるかな」などを頻繁に考えずに済むようになりました。 また自室には今まで使っていた昇降式デスクもあり、気分転換したいときはそちらに移って作業したりもします。 フルリモートのため、集中力を切らさないよう気分を変えるのは大事にしています。 今後導入したいもの 強いてあげればノートPCを置けるデュアルモニターアーム。自宅で社用PCを移動させるときにクラムシェルにせず、開いたまま載せた方がなんとなく楽そうなので。 WORLDLIFT デュアル モニターアーム 2画面 ノートパソコン アーム 17-32インチディスプレイ対応 12-18インチパソコン対応 高度7-65.5cm PCトレイ付き 耐荷重1-8kg ノートpc ケーブル収納 グロメット式＆クランプ式 VESA対応 WORLDLIFT Amazon 澁谷さんは、リビングの一角に省スペースながら機能的なワーク環境を構築されています。家族との時間を大切にしながら仕事に集中できる環境づくりに加え、切り替え機を活用した複数PC管理の効率化など、実践的な工夫が参考になります。 最後にご紹介するのは、QAエンジニアの金田さんです。 ■ 金田さん / Team+開発部 / QAエンジニア ■ Team+開発部 QAチームの金田直純です。 (職場ではニックネームでサム(Sum)と呼ばれています！) ファインディの1人目のフルタイムQAエンジニアとして、2025年5月にジョインし、早いもので4ヶ月が経ちました。 現在は、QAチームの立ち上げとTeam+の連携プロバイダを拡充する施策のQAを担当しています。 私は群馬県からフルリモートで働いており、これから紹介する作業環境はかれこれ7年ほど愛用しているもので、テーマは「DIY・シンプル・観葉植物」です。 デスク周り全体 こだわりのガジェットなどはありませんが、自作した広々デスクでお仕事しています！ あと現代的ではないかもしれませんが、ノートと付箋をいつでも使えるようにしていて、タスクを整理したり、テスト設計で仕様やテスト観点をマインドマップでざっくり書いたりしています。 デスク 自作デスクです！2020年頃にリモートワークを機にデスクを新調したものです。幅120cm x 縦60cmの天板にワトコオイルで塗装をしています。最近、昇降デスクに憧れていて脚を付け替えたい今日この頃です。 ディスプレイ PHILIPSの23インチディスプレイを使っています。友人が要らなくなったと頂戴して、かれこれ7年くらい使っています。 こだわりのアイテム紹介 イームズチェア風のアームシェルチェア デザインと包まれている感が好きでこれも5年くらい愛用しています。直で座ると腰が痛くなるので、ニトリのシートクッションを置いています。(最近、ガタが出てきたので、アーロンチェアなどに変えたい気持ちもあります。) 自作本棚 デスクを自作した時にDIYにハマってこちらも作りました。写真だと分かりづらいですが、長いボルトを柱にしていてナットで高さが変えられます(変えたことはない)。それからめちゃくちゃ不安定で物をたくさん置いていないと揺れます。 本棚には、ソフトウェア開発やテスト、品質保証関連の本と雑多なものを置いています。 リモートワークでの工夫 観葉植物と一緒に日光を浴びながらランチ フルリモートで外に出る機会が少ないので、休憩時間はベランダで観葉植物に水やりをして、一緒にお昼ご飯を食べます。ちなみに写真の植物はフィカス ベンガレンシス (ゴムの木)です。 今後導入したいもの 昇降デスクの脚 立って仕事することに憧れています アーロンチェア 今使っているものは仕事用に作られたものではないと思うので、そろそろデスクワークに向いている椅子を用意したいと思っています 金田さんの作業環境は、DIYによる自作デスクと本棚が印象的です。また、観葉植物と共に過ごすランチタイムの習慣からは、フルリモート環境においても日光を浴びる時間を意識的に作る重要性が伝わってきます。 おわりに 今回ご紹介した3名のエンジニアの作業環境からは、それぞれの生活スタイルや仕事の特性に応じた工夫が見て取れました。限られたスペースの有効活用、DIYによる環境カスタマイズ、家族との時間確保など、リモートワーク環境を快適かつ生産的にするための実践的なアプローチが参考になったのではないでしょうか。 ファインディでは、今回ご紹介したようにさまざまなバックグラウンドを持つエンジニアが、それぞれの個性を活かしながら活躍しています。 技術にこだわり、より良いものを追求する仲間とともに働いてみませんか？ 現在、新しいメンバーを募集しています。興味のある方は、ぜひこちらからチェックしてみてください！

こんにちは。Findy Tech Blog編集長の高橋（ @Taka-bow ）です。 「要件がまた変わった」「会議ばかりで開発時間がない」「あの人に聞かないと進められない」──こんな悩みを抱えていませんか？ 前回の記事 では、アジャイル実践者の59.6%が開発生産性に前向きだという意外な事実をご紹介しました。しかし、前向きでも実際の取り組み率は47.8%に留まっています。 今回は、798名の調査から明らかになった 開発生産性を阻害する要因 と、その改善への道筋を探ります。特に、技術的な問題よりも深刻かもしれない「組織の3大課題」がどのように連鎖し、どこから手をつければ効果的なのかを考察します。 【調査概要】 調査対象： ソフトウェア開発（組み込み開発を含む）に直接関わるエンジニア、プロダクトマネージャー、プロジェクトマネージャー、エンジニアリングマネージャー、開発責任者など 調査方法： インターネット調査 調査期間： 2025年4月2日(水)～2025年5月21日(水) 調査主体： ファインディ株式会社 実査委託先： GMOリサーチ&AI株式会社 有効回答数： 798名（95%信頼区間±3.5%） 統計的検定力： 80%以上（中程度の効果量d=0.5を検出） 調査内容： 開発生産性に対する認識 開発生産性に関する指標の活用状況 開発生産性に関する取り組み 開発環境・プロセス評価 組織文化と生産性 調査結果から、開発生産性を阻害する要因には明確な優先順位が存在することが判明しました。ここで注目したいのは、上位3つの課題がいずれも技術的な問題ではなく、組織運営やプロセスに関する点だということです。 上位3つは技術的な要因ではなかった 課題1 - 「不明確な要件」（53.5%） 半数以上が直面する根本的問題 要件が不明確になる3つの側面 ▼ 第一の側面 - 文書化・情報伝達の問題 ▼ 第二の側面 - ソフトウェア開発の本質的な不確実性 ▼ 第三の側面 - 優先順位と価値の曖昧さ 要件定義を阻害する組織的構造問題 「不明確な要件」への改善アプローチ ▼ 第1段階 - 文書化・情報伝達の改善 ▼ 第2段階 - 不確実性への適応力向上 ▼ 第3段階 - 組織文化の変革 課題2 - 「会議が多い」（38.7%） 開発時間を奪う会議の実態 会議が減らない本質的な理由 「会議が多い」への改善アプローチ ▼ 第1段階 - 会議の目的別再設計 ▼ 第2段階 - 組織構造の見直し ▼ 第3段階 - 会議依存からの脱却 課題3 - 「コミュニケーションの問題」（33.6%） 曖昧な「コミュニケーションの問題」が示すもの Flow Stateから見える「見えない中断」 「見えない中断」の正体 「コミュニケーションの問題」への改善アプローチ ▼ 「見えない中断」を減らすための具体策 まとめ - 共通認識から始まる改善 問題の連鎖構造 改善への第一歩 次回予告 上位3つは技術的な要因ではなかった 開発生産性を阻害する要因について尋ねたところ、次の結果が明らかになりました。 開発生産性の主要な阻害要因（複数回答） 順位 阻害要因 回答率 回答者数 分類 1位 不明確な要件 53.5% 427人 組織プロセス 2位 会議が多い 38.7% 309人 組織プロセス 3位 コミュニケーションの問題 33.6% 268人 組織プロセス 4位 技術的負債 30.5% 243人 技術的要因 5位 開発環境の制約 19.2% 153人 技術的要因 6位 その他（具体的に） 2.8% 22人 - （N=798、複数回答可） また、上位3つの阻害要因はいずれも組織プロセスに関連しており、技術的負債（30.5%）を上回っています。 この結果は、技術的な改善だけでは開発生産性の問題を解決できないことを示唆しています。むしろ、組織の仕組みやプロセスの見直しこそが、生産性向上の鍵となるのです。 それでは、これらの3大課題について、順に詳しく見ていきましょう。 課題1 - 「不明確な要件」（53.5%） 半数以上が直面する根本的問題 回答者の53.5%が指摘するこの課題は、上流工程における要件定義の品質に関わる根本的な問題です。 不明確な要件は、手戻りや追加開発を引き起こし、プロジェクトの効率性と開発チームの生産性を著しく低下させる要因となっています。 要件が不明確になる3つの側面 この問題には大きく3つの側面があると考えられます。 ▼ 第一の側面 - 文書化・情報伝達の問題 要件自体は顧客や関係者の頭の中では具体的になっているものの、それを適切に言語化・文書化できていない可能性があります。 この問題の本質を理解するため、要求仕様化の専門家の知見を参考にしてみましょう。 私の恩師である清水吉男氏は、要求の仕様化手法「USDM（Universal Specification Describing Manner）」を開発し、著書『[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?』でその手法を体系化したコンサルタントでした。 [改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか? 作者: 清水 吉男 技術評論社 Amazon 長年の実践を通じて日本のソフトウェア開発現場を見てきた清水氏は生前、「なぜ仕様が書かれないのか」について、次の3つの問題を指摘していました。 問題点 詳細 "要求"が表現されていない そもそも実現したいことが明確に表現されていないため、その要求を満たすための仕様を拾いきれない 要求と要求仕様の関係性の理解不足 要求と要求仕様の関係や違いを認識していないため、両者が混同される "機能仕様書"への偏り 機能面ばかりに注目することで、品質要求などの非機能要件が漏れてしまう これらの問題に加え、日本語の曖昧性も状況を複雑にしています。清水氏は「要求」「要件」「仕様」といった用語の混同についても警鐘を鳴らしていました。これらは英語と照らし合わせることで、それぞれの意味がより明確になります。 用語 英語 意味 要求 Requirement 実現したい（Require）ことが書かれたもの 仕様 Specification 特定（Specify）できた状態で表現されているもの そして、清水氏が特に強調していたのは、 要求には必ず「理由（Why）」が存在する という点です。 すべての要求には、それが存在する背景や理由があります。この「理由（Why）」を明確にすることが、適切な仕様を導き出すための重要な鍵となります。 要求の背後にある理由を探ることで、顧客が本当に実現したいことを正しい位置に誘導でき、仕様を外さない開発が可能になります。 理由が曖昧なままでは、要求の範囲を正しく認識できず、開発の方向性を見誤る可能性があります。 また、理由を理解することで、要求の変化の方向を予測し、将来の変更に備えた柔軟な設計が可能になります。 この「理由（Why）」への配慮が、最終的には保守性、パフォーマンス、機能拡張性、操作性、メモリー使用効率など、システム全体の品質に大きな差をもたらすのです。 このような概念の混同や、要求の背景にある「理由（Why）」への配慮不足が、文書化の質を低下させ、結果として「不明確な要件」という問題を生み出している可能性があります。 ▼ 第二の側面 - ソフトウェア開発の本質的な不確実性 より根本的な問題として、そもそもプロジェクト初期段階ですべての要件を確定できるという前提自体が非現実的である可能性があります。 書籍『アジャイルサムライ』では、この現実を端的に示しています。 ソフトウェア開発の3つの真実 1. プロジェクトの開始時点にすべての要求を集めることはできない 2. 集めたところで、要求はどれも必ずといっていいほど変わる 3. やるべきことはいつだって、与えられた時間と資金よりも多い 出典：Rasmusson, J. (2011).『アジャイルサムライ──達人開発者への道』（西村直人・角谷信太郎・近藤修平・角掛拓未 訳）. オーム社. (原著出版年：2010) アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson オーム社 Amazon これらの「3つの真実」は、多くの開発現場で日々体感されている現実ではないでしょうか。 要件の変更に振り回され、限られたリソースで山のようなタスクに向き合う。そんな経験は、きっと多くの読者の皆様にも共感いただけるはずです。 重要なのは、 この不確実性を前提として受け入れ 、それに対応できる柔軟な体制を構築することなのだと思います。 ▼ 第三の側面 - 優先順位と価値の曖昧さ 多くの開発現場では「やりたいことはたくさんある」状態です。 しかし、 どれから着手すべきか、なぜそれが重要なのか が曖昧なまま、要件リストだけが膨張していきます。 さらに深刻なのは、関係者同士が「合意が取れている」と思い込んでいる状況です。 会議では皆頷いていても、実際には各人が異なる成果物をイメージしており、後になって「思っていたものと違う」という事態が発生します。 出典：Jeff Patton "Glad we all agree" - https://jpattonassociates.com/glad-we-all-agree-2/ そして最も本質的な問題は、 顧客にとっての価値（アウトカム）が不明確 であることです。 「何を作るか」ばかりに注目し、「なぜ作るのか」「それによって顧客がどう変わるのか」という視点が欠如していると、要件自体が迷走してしまいます。 これらの問題に対する有効な解決策の1つが「ユーザーストーリーマッピング」です。 ユーザーストーリーマッピング 作者: ジェフ・パットン , 川口恭伸 , 長尾高弘 オライリージャパン Amazon ユーザーの行動を時系列で可視化することで、全体像と優先順位が明確になり、関係者全員が同じ地図を見ながら議論できます。 また、ユーザーの体験に焦点を当てることで、自然とアウトカムを意識した要件定義が可能になるのです。 要件定義を阻害する組織的構造問題 これらの3つの側面（文書化の問題、不確実性への対応、優先順位と価値の曖昧さ）がなぜ改善されないのでしょうか。 そこには、次のような組織的な構造問題が潜んでいると考えられます。 阻害要因のカテゴリー 具体的な問題 影響 文書化・情報伝達の阻害 決定権限や責任の所在が不明確 誰が最終決定権を持つのか曖昧なため、要求の「理由」を確認する相手が特定できない ステークホルダー間での認識の不一致 要求の背景や優先度について、関係者間で共通理解が形成されていない 不確実性への対応の阻害 完璧主義的な組織文化 「最初から完全な要件定義ができるはず」という非現実的な期待が根強い 変更を失敗と捉える風土 要件変更を「計画の失敗」と見なし、柔軟な対応を躊躇する 実際、調査では開発フレームワークについて「よくわからない」が18.2%、「ウォーターフォール」が36.8%と、合わせて過半数（55.0%）が変化への柔軟な対応を前提としていない、または開発手法自体を明確に理解していない状況でした。 この結果から、 不確実性への対処方法が組織的に確立されていない 可能性が高いことが見て取れます。ただし、ウォーターフォール型開発であっても、適切なリスクマネジメントが実施されていれば、ある程度は対処可能だと考えられます。 「不明確な要件」への改善アプローチ これまで見てきた問題構造を踏まえ、要件定義の改善には段階的なアプローチが有効と考えられます。 ▼ 第1段階 - 文書化・情報伝達の改善 清水吉男氏が指摘した「要求の理由」を明確にすることから始めましょう。 清水氏が開発したUSDM（Universal Specification Describing Manner）は、まさにこの問題を解決するための手法です。USDMの特徴は、要求と仕様を階層的に整理し、それぞれに「理由」を明記する点にあります。 USDMの基本構造 要求 ：「〜したい」という形で記述し、必ず「理由」を併記 仕様 ：要求を実現するための具体的な振る舞いを「〜する/〜である」と記述 階層化 ：要求を段階的に詳細化し、抜け漏れを防ぐ 例えば「ログイン機能が欲しい」という要求に対して、 理由 ：セキュリティを確保し、ユーザーごとにカスタマイズされた体験を提供するため 仕様 ：3回ログインに失敗したらアカウントをロックする、パスワードは8文字以上とする、など このように構造化することで、「なぜ」が明確になり、手戻りが激減します。 ユーザーストーリーカードという選択肢 アジャイル開発では「ユーザーストーリーカード」も有効な手法です。これは要求を次の形式で記述します。 「 〜として （Who：誰が）、 〜したい （What：何を）、 なぜなら〜だから （Why：理由）」 例 Who：「ECサイトの利用者として」 What：「過去の購入履歴を簡単に確認したい」 Why：「なぜなら、リピート購入を素早く行いたいから」 ユーザーストーリーカードの利点は次の通りです。 視点が明確 ：誰のための要求かが一目瞭然 価値が明確 ：「なぜなら」で理由と価値を必ず記述 対話を促進 ：カードを使って関係者と議論しやすい 受け入れ条件 ：裏面に具体的な仕様（受け入れ条件）を記載 USDMとユーザーストーリーカードは、どちらも「理由（Why）」を重視する点で共通しています。組織の文化や開発スタイルに合わせて選択するとよいでしょう。 実践的な改善策 要求テンプレートの導入 ：USDMやユーザーストーリー形式を活用し、要求記述時に必ず「理由・背景」欄を設ける ステークホルダーマッピング ：各要求の提案者と承認者を明確化し、決定権限の所在を可視化 共通言語の確立 ：要求・要件・仕様の違いを組織内で統一し、認識のズレを防止 ▼ 第2段階 - 不確実性への適応力向上 アジャイルサムライの「3つの真実」を受け入れ、変化を前提とした体制を構築します。 段階的な要件確定（Progressive Elaboration） ：初期はMVPレベルで要件を定義し、フィードバックを受けながら詳細化 ユーザーストーリーマッピングの導入 ：ユーザーの行動を時系列で可視化し、全体像を共有しながら優先順位を決定。Jeff Patton氏が提唱したこの手法は、要求の「理由」と「文脈」を自然に表現でき、ステークホルダー間の認識を合わせる強力なツールとなります 変更管理プロセスの確立 ：要件変更を「失敗」ではなく「学習」と捉え、影響分析と承認フローを明確化 プロトタイピングの活用 ：動くモックアップで早期に認識を合わせ、手戻りを最小化 ▼ 第3段階 - 組織文化の変革 過半数を占める「ウォーターフォール」「よくわからない」層への働きかけが重要です。 段階的な移行戦略 ：いきなり全面的なアジャイル化ではなく、小規模プロジェクトから試行 教育・研修の充実 ：開発手法の理解促進と、変化への対応力向上 成功体験の共有 ：柔軟な要件対応で成功したプロジェクトの事例を組織内で展開 課題2 - 「会議が多い」（38.7%） 開発時間を奪う会議の実態 回答者の38.7%が指摘するこの問題は、開発に集中する時間を大幅に削減する要因となっています。 会議は必要な情報共有の場である一方、過剰な会議は開発者のフロー状態を妨げ、集中して作業できる時間を奪っています。 さらに深刻なのは、会議の連鎖的発生です。 隙間がないカレンダーは要注意 明確な結論が出ない会議は、確認のための追加会議を必要とし、さらにその調整のための会議が発生するという悪循環に陥ります。 本来、効率化のための議論であっても、会議自体が目的化してしまうと、開発時間の確保という本来の目的から離れてしまう恐れがあります。 会議が減らない本質的な理由 会議が増殖し続ける最大の要因は、 異なる目的の会議が混在してしまうこと にあります。 会議には、次の4つの目的があると言われています。 会議の目的 会議の例 ディスカッションの種類 報告や情報共有を行い、次の活動に活かす 日常の進捗報告 情報交換型 多くの視点から、新しいアイデアを生み出す 新企画の洗い出し 洗い出し型 事実を論理的に組み立て、因果関係を整理する 現状課題の共有と整理 分析・考察型 ゴールを実現するために判断し、結論を出す 新企画の決定 意思決定型 しかし現実には、これらの異なる目的が1つの会議に混在し、「情報共有のつもりが議論になり、結論も出ないまま時間切れ」という状況が頻発します。 この問題は、課題1で見た「要件の不明確さ」と密接に関連しています。 要件の不明確さと組織構造の問題が複合的に作用し、会議を増やす負の連鎖が生まれています。 問題の種類 具体的な事象 結果 要件の不明確さ 要求の「理由」が共有されていない 同じ説明を何度も繰り返す 決定権限が不明確 意思決定型の会議なのに決定できない 目的が曖昧 「とりあえず集まって話そう」という会議が増える 組織構造 権限委譲の不足 同一部門内で多階層が参加（上司も部下も全員） 「全員参加」の誤解 議論には4-5名が理想なのに大人数を集める 責任回避の文化 「みんなで決めた」形にして個人の責任を曖昧化 実際、5人以上の会議になると「私1人ぐらい参加しなくても」という心理が働き、居眠りや内職、発言しない人が出てきます。 これは参加者個人の問題ではなく、会議設計の失敗なのです。 興味深いことに、アジャイル開発を導入した組織でも会議過多の課題は残っています。 デイリースクラム、スプリントプランニング、レトロスペクティブなど、本来は目的が明確なはずのセレモニーが、形骸化してしまうケースも見受けられます。 この問題は、物理出社でもリモートワークでも共通して発生しています。 むしろリモートワークの普及により、「とりあえずオンラインで集まる」ハードルが下がり、会議数が増加する傾向も見られます。 場所を問わず、会議の本質的な設計と運用の見直しが必要なのです。 「会議が多い」への改善アプローチ 会議の問題を解決するには、まず「会議の目的を明確に分離する」ことから始める必要があります。 ▼ 第1段階 - 会議の目的別再設計 前述の4種類の会議それぞれに適した運営ルールを設定します。 ディスカッションの種類 運営ルール 情報交換型 タイムボックス設定、資料事前配布、質疑は最小限 洗い出し型 参加者を4-5名に限定、個人思考時間を確保 分析・考察型 分析手法を事前に決め、全員が手順を理解してから開始 意思決定型 決定権者を明確化、判断基準と選択肢を事前準備 ▼ 第2段階 - 組織構造の見直し 会議過多の根本原因である組織構造にメスを入れます。 権限委譲の推進 ：同一部門内の多階層参加を避け、適切なレベルに決定権を委譲 参加者の最適化 ：議論は4-5名、情報共有以外は必要最小限のメンバーに限定 権限レベルの明確化 ：デリゲーションポーカーなどを活用し、各メンバーがどのレベルで意思決定に関わるかを明確にする デリゲーションポーカーはManagement 3.0で開発されたプラクティスです ▼ 第3段階 - 会議依存からの脱却 すべてを会議で解決しようとする文化から脱却します。 ドキュメント文化の構築 ：議事録・決定事項を確実に文書化し、共有する仕組みを確立 非同期ツールの活用 ：SlackやTeamsのスレッドで議論を進め、会議は意思決定のみに 時間制限の厳格化 ：すべての会議に明確な終了時間を設定し、延長を原則禁止 課題3 - 「コミュニケーションの問題」（33.6%） 曖昧な「コミュニケーションの問題」が示すもの 回答者の33.6%が「コミュニケーションの問題」を生産性低下の要因として挙げています。しかし、この「コミュニケーションの問題」が具体的に何を指しているのかは、統計的な分析を行っても特定できませんでした。 興味深いのは、「会議が多い」（38.7%）とは別項目として挙げられている点です。会議もコミュニケーションの一形態であるにもかかわらず、別の問題として認識されているということは、ここで言う「コミュニケーションの問題」は会議以外の何か別の問題を指していると考えられます。 Flow Stateから見える「見えない中断」 この問題を理解するには、DevEx（Developer Experience）の観点、特に Flow State（フロー状態） の概念が有効かもしれません。 開発者が「フローに入る」「ゾーンに入る」という状態は、完全に集中し、生産性が最大化される状態を指します。研究によれば、この状態を頻繁に経験する開発者は、より高いパフォーマンスを発揮し、質の高い製品を生み出します。 フロー状態を妨げる主要な要因は 中断や遅延 です。会議は「見える中断」として明確に認識されますが、「コミュニケーションの問題」は 「見えない中断」 を生み出している可能性があります。 「見えない中断」の正体 会議とは異なる形で開発者のフロー状態を阻害する要因として、次のようなものが考えられます。 中断の種類 具体的な問題 開発者への影響 非同期コミュニケーション Slackやメールの返答待ち 作業が停滞、待機時間が発生 チャットツールの頻繁な通知 集中が途切れ、再集中に時間がかかる 複数の会話を並行処理 思考が分散し、効率が低下 情報探索 ドキュメントがどこにあるか不明 探し回る時間で開発が中断 Wiki、チャット、メール等に情報が分散 情報収集に時間を取られる 「あの人に聞かないと分からない」 属人化により作業がブロック チーム間連携 他チームの作業完了時期が不明 依存関係で作業が止まる 決定権者が不明確 承認待ちで進捗が遅延 仕様の詳細が曖昧 何度も確認が必要になる 生成AI活用 AIの高速な生成に人間の判断が追いつかない レビュー待ちが常態化、判断疲れ 複数のAIタスクを並行して依頼 自己マルチタスク化で集中力が分散 AIの処理待ち時間に別タスクを開始 コンテキストスイッチが頻発 これらの「見えない中断」は、一つ一つは小さくても、累積すると開発者が集中できる時間を大幅に削減します。研究によれば、中断から再び集中状態に戻るまでに平均15〜30分かかるとされており、頻繁な「見えない中断」は生産性に深刻な影響を与えます。 特に生成AI活用においては、AIの処理速度と人間の判断速度のミスマッチが新たな中断を生み出しています。AIが瞬時に生成するコードや文書を適切にレビューするには時間がかかり、その間にAIに別のタスクを依頼することで、結果的に人間側が複数のコンテキストを同時に管理する「自己誘発的マルチタスク」状態に陥るのです。 「コミュニケーションの問題」への改善アプローチ もし「コミュニケーションの問題」が上記のような「見えない中断」を含んでいるとすれば、Flow Stateを守るための対策が効果的でしょう。 ▼ 「見えない中断」を減らすための具体策 改善カテゴリ 具体的な施策 非同期コミュニケーション • 返答の期待値を明確にする（今日中、明日中など） • 通知のルールを設定し、集中時間帯を確保 • 非同期で解決できることと同期が必要なことを区別 情報の構造化 • ドキュメントの一元管理と検索性の向上 • 技術的な意思決定の理由と経緯を文書化して残す • FAQやナレッジベースの整備 チーム間連携 • API仕様の文書化とバージョン管理 • 依存関係の可視化とタイムラインの共有 • ブロッキングポイントの事前特定と対策 AI活用の最適化 • AIタスクを順次処理する（並列依頼を避ける） • AIの出力をバッファリングし、まとめてレビュー • AIとの協働時間を時間枠で区切る これらの施策は、「会議を減らす」という目に見える対策とは異なり、日常的な開発作業の中で発生する「見えない中断」を減らし、開発者がフロー状態を維持できる環境を整えることを目指しています。 まとめ - 共通認識から始まる改善 調査で浮かび上がった3つの阻害要因──「不明確な要件（53.5%）」「会議が多い（38.7%）」「コミュニケーションの問題（33.6%）」は、実は互いに連鎖する1つの問題群です。 問題の連鎖構造 プロジェクト開始時に「なぜ」「何を」「どう進めるか」の共有が不足すると、次の連鎖が起きます。 要件が不明確になる理由 会議が増える理由 コミュニケーションの質が低下する理由 プロジェクトの目的や背景（理由）が共有されていない 共通認識がないため、都度確認が必要になる 前提となる情報が共有されていないため、毎回説明が必要 成功基準やトレードオフの優先順位が定まっていない 会議の目的も不明確になり、4種類の会議が混在する 判断基準が不明確なため、議論が収束しない 結果として、要求の「理由」が分からず、仕様が定まらない 決定権限が不明確なため、全員参加の非効率な会議が増える 情報が構造化されず、属人化してしまう これらすべての根本にあるのは「プロジェクト開始時の共通認識の欠如」です。 改善への第一歩 形式は問いません。インセプションデッキでも、1ページのキックオフノートでも十分です。最低限、次の4点だけはチームで明文化してから開発を始めましょう。 なぜやるのか （目的・期待する価値・成功指標） 何をつくるのか （スコープと優先順位・トレードオフ） どう進めるのか （進め方・意思決定権限・変更の扱い） 誰が決めるのか （責任と承認フロー） 共通認識の形成は一度きりの作業ではありません。しかし、スタート時点で最低限の合意がなければ、その後の適応的な変更も迷走してしまいます。技術的な改善以前に、まず「なぜ」「何を」「どう」「誰が」を明確にすることこそが、変化に強いチームづくりの第一歩なのです。 次回予告 第4回は「 AI時代の技術格差 ── Visual SourceSafe 15.8%が示す変革への壁 」をお届けします。 Visual SourceSafeがまだ現役？レガシーツールから脱却できない組織の本音に迫ります。 第1回、日本の開発現場の「リアル」を数字で見る ── 798名の声から浮かび上がる衝撃の実態 調査全体について 第2回、開発生産性への意外な好印象 ── アジャイル実践者59.6%が前向きな理由 開発手法による意識の違いの本質 第3回、開発生産性を阻む「組織の3大課題」 ── 要件定義、会議、コミュニケーションの問題 取り組みが失敗する本当の理由 第4回、AI時代の技術格差 ── Visual SourceSafe 15.8%が示す変革への壁 なぜ従来型ツールから移行できないのか 第5回、なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 日本の開発者が本当に求めているもの ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 そのような状況の中で先日、弊社から新サービスのFindy AI+がリリースされました。 Findy AI+のα版はリモートMCPサーバーで提供しており、以前の記事でも紹介させていただきました。 tech.findy.co.jp 一般的なWebサービスでは、ユーザー側のアプリケーションの他に、管理者用のアプリケーションを用意することが多くあります。 Findy AI+でも管理者用のアプリケーションを用意しましたが、今回は管理者用のMCPサーバーとして実装することで、専用の画面を必要とせず、自然言語で管理機能を実行できるようにしました。 そこで今回は、この管理者用のMCPサーバーについて深堀って解説していきます。 それでは見ていきましょう！ Findy AI+とは Local MCP Server for Administrator アーキテクチャ 認証 利用方法の統一 Elicitation まとめ Findy AI+とは Findy AI+はGitHub連携・プロンプト指示で生成AIアクティビティを可視化し、生成AIの利活用向上を支援するサービスです。人と生成AIの協働を後押しして、開発組織の変革をサポートします。 GitHub Copilot / Claude Code / Devin / Codexに対応しており、生成AIアクティビティを可視化し、生成AI利活用のボトルネック発見・利活用推進をサポートします。 また、ユーザーがプロンプトで指示して、Findy AI+のMCPサーバー経由で生成AIの利活用状況を定量・定性両面から自動取得します。 Local MCP Server for Administrator サービスやプロダクトを提供する場合、ユーザー向けの機能だけではなく、サービスの管理者側の機能も必要になることがあります。 このような場合、管理者用の画面を用意するのが一般的です。しかしFindy AI+では管理画面を作らず、Local MCP Serverを介して管理者用のAPIを実行出来るように環境構築を行いました。 昨今のWebフロントエンドの画面は、デザインからHTML/CSS、認証やデータ通信など、1画面を作るために必要な要素が多岐に渡るため、想定以上に時間とコストが掛かることがあります。 しかし、この仕組みにすることで管理者用の画面のデザインや実装をする必要がなく、最低限のAPIとMCPサーバーの実装をするだけで管理機能を用意できるようになりました。 アーキテクチャ アーキテクチャは非常にシンプルです。 まずFindy AI+の利用者がRemote MCP Serverに接続して、そこからFindy AI+や、GitHub、Devinなどといった外部APIを実行します。 Findy AI+の管理機能は画面やRemote MCP Serverではなく、運営メンバーのPCにLocal MCP Serverを用意して提供します。Local MCP ServerからFindy AI+のAPIを実行します。 この時、利用者側と管理者側のAPIはエンドポイントレベルで分けており、利用者側から管理者用のAPIを実行出来ないようになっています。 この仕組みを実現することで、管理機能を実装するコストがAPIの実装とLocal MCP Serverの実装コストだけになり、開発コストを大幅に削減しました。 認証 管理者向けのLocal MCP Serverの認証も非常にシンプルです。 運営メンバーのPCで動くため、MCPサーバーの起動時に管理者用APIの実行権限を持たせたアクセストークンを環境変数に付与します。また、APIの実行先を開発用とそれ以外で切り替えできるようにもします。 { " inputs ": [ { " type ": " promptString ", " id ": " ACCESS_TOKEN ", " description ": " MCP Access Token for Findy AI+ Admin ", " password ": true } , { " type ": " promptString ", " id ": " ENV ", " description ": " production or staging or local ", " password ": false } ] , " servers ": { " admin ": { " command ": " node ", " args ": [ " /User/hoge/dist/apps/admin/main.js " ] , " env ": { " ACCESS_TOKEN ": " ${input:ACCESS_TOKEN} ", " ENV ": " ${input:ENV} " } } } } MCPサーバーから管理者用のAPIを実行する際に、そのアクセストークンをhttp headerに付与し、API側で認証を確認します。 import * as https from 'https' ; import createFetchClient from 'openapi-fetch' ; import type { paths } from './__generated__/schema.js' ; const adminApiEnv = process .env[ 'ENV' ] || 'local' ; const baseUrl = adminApiEnv === 'production' ? 'https://production.hoge.com' : adminApiEnv === 'staging' ? 'https://stg.hoge.com' : 'https://localhost:8000' ; const apiClient = createFetchClient< paths >( { baseUrl , credentials : 'include' , } ); const httpsAgent = new https.Agent( { rejectUnauthorized : false } ); await apiClient.POST( '/api/admin/hoge' , { params : { header : { Authorization : `Bearer ${ process .env[ 'ACCESS_TOKEN' ] } ` , } , } , body : { text : 'test' } , httpsAgent , } ); このように、APIの実行先の切り替えとアクセストークンを、運営メンバーのローカル環境の環境変数に持たせることで、安全に管理運営できるように整備しました。 利用方法の統一 自然言語を利用して、MCPサーバー経由で管理機能を利用することになりますが、ここで1つ問題が出てきます。 MCPサーバーを実行する際に、運営メンバーが意図した挙動をするプロンプトを入力出来ないケースが想定されます。 この問題を解決するために、MCPサーバーのPromptsを活用することにしました。Promptsを利用することで、定型文を使って動的にプロンプトを作成することが可能になります。 modelcontextprotocol.io 例えば、新しく契約して頂いた企業情報を追加するとします。その場合、次のようなコードでプロンプトそのものを動的に作成できます。 import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js' ; import { z } from 'zod' ; const mcpServer = new McpServer( { name : 'Findy AI+ Admin MCP Server' , version : '0.0.1' , } ); mcpServer. prompt ( 'add_organization' , 'Add organization to Findy AI+' , { last_name : z.string().describe( 'Last Name(Family Name)' ), first_name : z.string().describe( 'First Name' ), email : z.string().email().describe( 'Email address' ), org_name : z.string().describe( 'Organization name' ), } , async ( { last_name , first_name , email , org_name } ) => { return { messages : [ { role : 'user' , content : { type : 'text' , text : `Findy AI+に組織を追加してください。 パラメータ: - 管理者名: ${ last_name } ${ first_name } - 管理者メールアドレス: ${ email } - 組織名: ${ org_name } ` , } , } , ] , } ; } ); 実際に実行すると、プロンプトを作るために必要な情報を聞かれます。 指示に従って内容を入力していくと、最終的に動的なプロンプトが作成されます。 あとはそのまま実行するだけで、誰が実行しても同じ結果になります。 Elicitation MCPサーバーで管理機能を実現するうえで避けて通れない問題がもう1つあります。基本的にMCPサーバーとのやり取りは一方通行だということです。 MCPサーバーとのやり取りの基本的なシーケンス図はこうなります。 このシーケンス図から分かる通り、リクエストを投げたらレスポンスが返ってくるといった、一般的な流れです。 しかし入力した企業名を間違っていたままプロンプトを実行してしまった場合、間違った情報のままでAPIが実行されてしまうのを止める手段がありません。 そこで活躍するのが、以前に他の記事でも紹介したMCPのElicitationという機能です。 tech.findy.co.jp Elicitationを利用することで、MCPサーバーとのやり取りのシーケンス図は次のように変わります。 confirmとapproveのフローが増えているのが分かるかと思います。MCPサーバーとMCPクライアントの通信中に、ユーザーに追加情報を要求できるようになるのです。 Elicitationを使った確認フローの実装例は次のようになります。 import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js' ; import { apiClient } from '@admin/api-client' ; import * as https from 'https' ; import { z } from 'zod' ; const mcpServer = new McpServer( { name : 'Findy AI+ Admin MCP Server' , version : '0.0.1' , } ); mcpServer.tool( 'create_org' , 'Create a new organization' , { org_name : z.string().describe( 'Organization name' ), email : z.string().email().describe( 'Email address' ), last_name : z.string().describe( 'Last name(Family name)' ), first_name : z.string().describe( 'First name' ), } , { title : 'Create Organization Tool' , } , async ( { org_name , email , last_name , first_name } ) => { const confirmation = await mcpServer.server.elicitInput( { message : `組織 " ${ org_name } " を作成しますか？ \n 管理者: ${ last_name } ${ first_name } ( ${ email } )` , requestedSchema : { type : 'object' , properties : { confirm : { type : 'string' , title : '確認' , description : 'Type "yes" to confirm or "no" to cancel' , enum : [ 'yes' , 'no' ] , } , } , required : [ 'confirm' ] , } , } , { timeout : 30000 } ); if ( confirmation. action !== 'accept' || confirmation.content?. [ 'confirm' ] !== 'yes' ) { return { content : [ { type : 'text' , text : 'Organization creation cancelled by user.' , } , ] , } ; } const httpsAgent = new https.Agent( { rejectUnauthorized : false } ); const { response , data } = await apiClient.POST( '/api/admin/hoge' , { params : { header : { Authorization : `Bearer ${ process .env[ 'ACCESS_TOKEN' ] } ` , } , } , body : { org_name , email , last_name , first_name , } , httpsAgent , } ); if (response. status !== 201 || !data) { return { content : [ { type : 'text' , text : `Error: Unexpected response status ${ response. status} ` , } , ] , } ; } const { id , name , user_id , user_first_name , user_last_name , user_email } = data; return { content : [ { type : 'text' , text : `Organization created successfully: - ID: ${ id } - Name: ${ name } - User ID: ${ user_id } - User Name: ${ user_last_name } ${ user_first_name } - User Email: ${ user_email } ` , } , ] , } ; } ); 実際にGitHub Copilot ChatでElicitationを実行した様子を見てみましょう。 まずは先程紹介したプロンプトを実行します。Toolの実行許可を尋ねられるので許可しましょう。 すると、次のような確認ステップが出力されます。 このRespondボタンを押下すると、次のような確認モーダルが表示されます。 今回のケースだとyesを選択するとAPIが実行され、noを選択するとそこで処理が終了となります。 このように、MCPサーバーとの通信中にユーザーに選択肢を要求して処理を分岐したい時にElicitationは大きな威力を発揮します。 まとめ いかがでしたでしょうか？ 今回の内容は先日開催した Findy AI Meetup in Fukuoka #2 でも紹介させてもらいました。 こちらがその時の資料となります。是非参考にしてみてください。 ファインディではMCPの有用性にいち早く気づき、検証を続けてきました。 その結果、開発効率を上げるだけではなく、今回紹介したようにサービスに埋め込んだり、プロダクトの作り方、提供の仕方までもが大きく変わりました。 MCPの可能性はどんどん広がっています。是非みなさんのMCP活用法も教えてください。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは。 ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 そのような状況の中で先日、Findy AI Meetupの第2回を福岡で開催しましたので、今回はそのイベントの様子や内容を紹介します。 findy-inc.connpass.com 当日参加くださったみなさま、ありがとうございました！ Findy AI Meetupとは？ 登壇内容 実践！カスタムインストラクション＆スラッシュコマンド ファインディ株式会社におけるMCP活用とサービス開発 懇親会 まとめ Findy AI Meetupとは？ ファインディ株式会社のエンジニアが主催する技術系のオフラインイベントです。 ファインディ株式会社では、生成AIやAIエージェントの活用を通じて開発生産性の向上を目指す取り組みを行っています。このイベントでは、ファインディのエンジニアが社内での実践事例を紹介するとともに、エンジニア同士がつながり、知見の共有や交流を目的としています。 今回のMeetupは2回目の開催となっており、前回開催にも参加くださった方々が３割ほど、初参加の方々が７割ほどの割合でした。まだ参加したことがない読者の方も次回開催には是非ご参加ください。 登壇内容 実践！カスタムインストラクション＆スラッシュコマンド 最初にフロントエンドテックリードの新福が、「実践！カスタムインストラクション＆スラッシュコマンド」と題して、ファインディでGitHub CopilotやClaude Codeの機能をどのように活用しているかを紹介しました。 カスタムインストラクションは、生成AIのコンテキストとして渡す文章です。生成AIの特性に合わせた書き方を工夫することで出力の精度を高められます。 実践の例として、今回はコミットメッセージ生成のカスタムインストラクションの設定方法を紹介しました。 // .vscode.settings.json { " github.copilot.chat.commitMessageGeneration.instructions ": [ { " file ": " .github/instructions/commit-message.instructions.md " } ] , } commit-message.instructions.md の例を次に示します。 --- applyTo: '**' description: 'コミットメッセージの生成' --- コミットメッセージは [Conventional Commits](https://www.conventionalcommits.org/ja/v1.0.0/) に従って記述する。 ## フォーマット <type>[optional scope]: <description> [optional body] [optional footer(s)] ### type（必須） - `feat`: 新機能や既存機能の変更 - `fix`: バグ修正 - `docs`: ドキュメントのみの変更 - `*.md` を追加、変更した場合 - `test`: テスト追加・修正 - `*.spec.*` `*.spec.*.snap` を追加、変更した場合 <!-- (中略) --> ### scope（任意） - ディレクトリ名が `package.json` または `package-lock.json` の時 `deps` - ディレクトリ名が `.github/**` の時 `github` - ディレクトリ名が `apps/frontend/**` の時 `frontend` - ディレクトリ名が `libs/frontend/feature-xxx/**` の時 `frontend-feature-xxx` - ディレクトリ名が `libs/ui/**` の時 `ui` <!-- (中略) --> ## コミットメッセージの例 - feat(frontend-feature-xxx): add social login - feat(ui): add button component - fix(frontend-feature-xxx): fix validation - docs(*): update README.md - refactor(frontend-feature-xxx): refactor form logic <!-- (中略) --> GitHub Copilotのカスタムインストラクションは applyTo というプロパティを持っており、ファイル拡張子でコンテキストを絞り込めるのが特徴です。 ファインディのフロントエンドでは、慣習的に 拡張子によってモジュールの責務を分離していた ため applyTo と相性が良いという発見が得られました。これまでやってきた開発の工夫が生成AIの活用に繋がった好例と言えるでしょう。 スラッシュコマンドについては、Gitコマンドを実行する例を示しつつ、プロンプトを書くコツを紹介しました。 プロンプトのコツ さらに実践的な内容として、 Nx のマイグレーションやClaude Codeの通知設定といった例を示しつつ、プロンプトの二重管理を防ぐ工夫を紹介しました。 プロンプト二重管理防止の工夫 スライドは↓から参照できます。時間の都合で割愛した他のサンプルも掲載しております。 ファインディでは生成AIツールの活用を進めつつ、生成AI時代に向けた新しいサービスを開発中です。 findy.co.jp 冒頭に紹介しました調査結果は、次のURLから全文をダウンロードできます（Findyのユーザー登録が必要です）。 findy-code.io ファインディ株式会社におけるMCP活用とサービス開発 次にテックリードの戸田が、「ファインディ株式会社におけるMCP活用とサービス開発」と題しまして、弊社の開発シーンでもMCP(Model Context Protocol)の活用方法と、MCPを埋め込んだプロダクト開発について紹介しました。 まず、弊社でのMCPの活用事例を紹介しました。 TypeScriptのSDKを使用して社内MCPサーバーを開発できるように環境を整備したことを紹介しました。以前にも、このテックブログで紹介しています。 tech.findy.co.jp Nxのgenerator機能を利用して、 ワンコマンドでMCPサーバーの雛形を作成できる ようにしています。さらにNxで管理しているため、複数のMCPサーバーをmonorepoで管理できるようにしており、MCPサーバーの社内エコシステムを実現しています。 このような環境を整備したことにより、3日間で10個のMCPサーバー、30個のtoolを実装して、社内のエンジニアに配布することを実現しました。 次に、他社のMCPと連携して効率化した事例を紹介しました。 GitHubのMCPを利用して、メンティーが受け取ったレビューコメントを取得し、社内MCPサーバーから解析用のプロンプトを動的に返すようにして、 レビューコメントの傾向をLLMが解析する 仕組みを作りました。 また、GitHubのメトリクスを取得してきて MCPサーバー内でmermaid記法のmarkdownに落とし込み、それをクライアント側でグラフ表示する といった仕組みも作りました。 このように、 LLMとMCP、MCPクライアントとMCPサーバーの責務を分けて考えることがMCP活用のコツ です。 最後に、弊社からリリースされた新サービスのFindy AI+について紹介させてもらいました。 Findy AI+は、GitHub連携・プロンプト指示で生成AIアクティビティを可視化し生成AIの利活用向上を支援するサービスです。人と生成AIの協働を後押しして、開発組織の変革をサポートします 当日はFindy AI+のアーキテクチャや設計などについても解説したのですが、これはまた別の機会で紹介できればと思います。お楽しみに！ 今回の登壇と資料が皆さんの参考になると幸いです。 懇親会 登壇発表後は参加者の皆さんと懇親会を開催しました。 懇親会では「パックマンルール」をお願いしています。懇親会で誰かと話すときは新しい人が会話に入れるように、一人分のスペースを空けて話しましょう。というルールです。 生成AI活用における悩みや知見を意見交換して、楽しんでいただけたようです。 まとめ いかがでしたでしょうか？ 当日、イベントに足を運んでくださった参加者のみなさん、本当にありがとうございました。頂いたアンケート結果を、次回開催の参考とさせていただきます。 次回開催は11月前後を予定しております。残念ながら今回のイベントに参加出来なかったみなさんも、次回イベント開催時には是非ご参加ください！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers