こんにちは！ファインディのTeam+開発部の甲斐（ @karukan013L23 ）です。この記事は 🎄ファインディエンジニア #1 Advent Calendar 2025 7日目の投稿です。 adventar.org 去年まで1度も登壇したことがなかったのですが、今年は次の3つのイベントに登壇しました。 2025/6/25: Mita.ts #6 2025/8/20: すごくすごい。フロントエンドミートアップ 〜複雑GUI・アーキテクチャ設計を語ろう 〜 2025/11/23: TSKaigi Hokuriku 2025 今回は、登壇経験のなかった私が登壇に挑戦したきっかけや、各イベントの登壇内容、そして登壇を通して得られた学びについて紹介します。 登壇のきっかけ Mita.ts 登壇内容 登壇してみて すごくすごい。フロントエンドミートアップ 〜複雑GUI・アーキテクチャ設計を語ろう 〜 登壇内容 登壇してみて TSKaigi Hokuriku 2025 登壇内容 登壇してみて 登壇準備でやってよかったこと 1. 登壇内容の壁打ち 2. 話したいことをとにかく書き出す 3. 登壇時に話す内容を全てスピーカーノートに書き出す、発表練習を繰り返してブラッシュアップ 4. 登壇資料のレビュー依頼 まとめ 登壇のきっかけ きっかけは、TSKaigi 2025の懇親会でした。来年のTSKaigiはプロポーザル出して登壇してみたいねと懇親会の参加者の方と一緒に話していました。私はまだ登壇したことがなかったのでそのことを話すと、「じゃあ1回登壇してみようよ」と直近登壇できそうなLTイベントを探してくださり、私はそのLTイベントに登壇枠で申し込みました。これが最初の登壇への一歩でした。 Mita.ts イベントリンク: https://mitats.connpass.com/event/353424/ 登壇タイトル: 「tsgoを触ってみて得た学び」 登壇資料 speakerdeck.com 登壇内容 Announcing TypeScript Native Previews でTypeScriptのGo言語実装によるコンパイラのプレビュー版の公開が発表されました。これにより、tsgoコマンドを使用することでGo言語実装版でのtypecheckが実行可能になりました。 そこで、typecheck実行時にコード量の異なるプロジェクトでどのようなパフォーマンス差が出るのかを検証しました。 実際に計測してみると、コード量が多いプロジェクトでは 8.47倍、少ないプロジェクトでも 3.14倍 の高速化を確認できました。 特にコード量が多いプロジェクトほど、Go言語による並列処理の恩恵を受けやすく、高いパフォーマンス改善効果が見られました。 調査過程で現在のTypeScriptから変わる部分や今後の動きを学ぶことができ、「調べるだけでなく実際に手を動かすことの大切さ」を実感しました。 登壇してみて 初めての登壇ということもあり、多くの反省点がありました。 特に時間管理が課題で、心の中で読むのと実際に声に出して発表するのとでは、所要時間に大きな差があることを痛感しました。大まかなメモだけで話そうとしてしまったため、想定以上に時間がかかってしまいました。 また、内容についても「とりあえず触ってみた」という域を出ず、聞き手にとっての学びやメッセージ性が弱かった点も反省です。 登壇自体は反省点が多かったですが、登壇準備はTypeScriptについて理解を深める良い機会になりました。 LT会はワイワイした雰囲気で、多くの人との交流を楽しむことができました。初めて登壇する場として、とても良かったと思います。 すごくすごい。フロントエンドミートアップ 〜複雑GUI・アーキテクチャ設計を語ろう 〜 弊社が会場スポンサーを務めるイベントで、「登壇してみないか？」と社内で声をかけていただきました。 1度登壇したことで登壇に対する心理的ハードルが下がっていたこともあり、せっかくの機会なので挑戦することにしました。 イベントリンク: https://formx.connpass.com/event/364158/ 登壇タイトル: 「AI疲れに効く、フロントエンドのワークフロー整備」 登壇資料 speakerdeck.com 登壇内容 生成AIによるコーディングが普及する一方で、AIが生成したコードのレビューや手直しによる「AI疲れ」という新たな課題も生まれています。そこで、AIと安全に協業しつつ開発速度を維持するための「守り」と「高速化」のワークフロー整備について紹介しました。 具体的には、「守り」としてTypeScriptやESLintによる静的解析、Nxによるモジュール境界の強制、Vitestを用いた自動テスト、フィーチャーフラグの導入などを行っています。 また、「守りの高速化」のアプローチとして、Nxの変更検知とキャッシュ機能を活用し、影響範囲のあるプロジェクトのみをCI対象に絞り込んでいます。さらに、GitHub ActionsのRunnerスペックを負荷に合わせて最適化することで、CIの実行時間を短縮しています。 これらの仕組みは元々開発効率と品質のために構築したものですが、結果としてAI時代においても強固な土台として機能しています。 登壇してみて 今回は弊社のフロントエンドテックリードに壁打ちをお願いし、方向性をしっかりと固めてから準備に入りました。「フロントエンドのワークフロー整備」という範囲が広いテーマでしたが、「AIに好き勝手させないための守りと高速化」という軸が決まっていたので、話す内容の取捨選択がしやすかったです。 当日は緊張しましたが、スピーカーノートをしっかり準備して練習していたおかげで、落ち着いて話すことができました。 TSKaigi Hokuriku 2025 弊社がGoldスポンサーとして協賛していたイベントです。 一般公募のプロポーザルは残念ながら不採択だったのですが、スポンサーLT枠として登壇の機会をいただきました。 イベントリンク: https://hokuriku.tskaigi.org/ 登壇タイトル: 「Nxはいいぞ！monorepoプロジェクトにおける差分検知を活用した型チェック最適化」 登壇資料 speakerdeck.com 登壇内容 プロジェクトのコード量増加に伴い、CI実行の実行時間が増加する課題に対して、Nxの差分検知とキャッシュを活用したCI高速化の手法を紹介しました。 Nxは、モノレポやアプリケーションのビルド、テスト実行、コード生成などの機能を備えた統合的なツールです。ファインディの多くのフロントエンドでも採用されています。主な特徴として、タスク実行の並列化、変更検知、キャッシュ活用によるCI実行の効率化があります。 Nxは変更があったプロジェクトと、それに依存関係のあるプロジェクトのみを対象にコマンドを実行します。これにより、typecheckなどのタスクの不要な実行をスキップでき、依存関係が小さい変更ほどCIが早く終わるようになります。 Nxの恩恵を最大限受けるためにはプロジェクトの依存関係を適切に整理することが重要です。コード量の増加によるCI実行時間の増加や開発体験の低下に課題を感じたら、ぜひNxのことを思い出してください！ 登壇してみて 元々プロポーザルを出していた内容だったため、ターゲット（モノレポ構成やCI時間に課題を感じている層）と伝えたいメッセージを明確にできており、登壇準備を進めやすかったです。 4分間のLT枠だったため、短い時間の中で「何を伝えればNxの良さが響くか」を意識して構成を考えました。結果、制限時間ギリギリではありましたが、伝えたいポイントはしっかり届けられたと感じています。 ちなみに、TSKaigi Hokuriku 2025については、同日参加したメンバーも記事を投稿していますので、イベントの雰囲気が気になる方はぜひ併せてご覧ください！ tech.findy.co.jp note.com 登壇準備でやってよかったこと これら3回の登壇を通して、特にやってよかったなと思った取り組みを紹介します。 1. 登壇内容の壁打ち 登壇内容の方向性、軸を決めるためにテックリードや他の登壇予定の方と壁打ちをすることです。 自分だけで登壇内容を考えると、何か足りないと感じたり範囲が広すぎて軸を定められないなど迷うことがあります。 必ずしもひとりで考えきる必要はありません。迷いがあったら壁打ちをお願いしてみることをおすすめします。 2. 話したいことをとにかく書き出す 「話したいこと」をとにかく書き出しました。 一度書き出すことで、自分自身の理解の曖昧な部分が浮き彫りになり、調査をして理解を深めるきっかけになりました。 調査の過程がそのまま学びの機会になるため、おすすめです。 3. 登壇時に話す内容を全てスピーカーノートに書き出す、発表練習を繰り返してブラッシュアップ いわゆる「台本」を作ることです。 話す内容を全て文字に起こすことで、説明の言い回しや構成に違和感がないかを確認できます。 また、実際に声に出して読んでみると「この表現は伝わりにくい」「ここは順序を入れ替えたほうがいい」といった気づきが得られます。 発表練習を繰り返してスピーカーノートを直し、時間配分を調整することをひたすら繰り返すことで、本番で落ち着いて話すことができるようになります。 4. 登壇資料のレビュー依頼 資料ができたら、テックリードや社内のエンジニアにレビューをお願いしました。 作り手視点だけでは気づけない「説明の誤り」や「わかりにくい表現」を指摘していただき、勉強になりました。 また、会場が大きいので、文字が小さいと後ろの席から見えないから限界まで文字サイズを大きくした方が良いといった、登壇経験者ならではの実践的なアドバイスもいただき勉強になりました。 まとめ 登壇に挑戦することで、技術の理解を深めるよい学びの機会となりました。 聞き手にわかりやすく説明するためには、自分自身がその技術を深く、体系的に理解している必要があります。曖昧だった知識を補完し、学び直すプロセスそのものが、エンジニアとしての成長に繋がったと感じています。 これからも、登壇やブログ執筆といったアウトプットの機会を大切にし、自分自身の学びの場として活かしていきたいと思います。 ファインディでは一緒に働くメンバーを募集しています！ 興味がある方はこちらから ↓ herp.careers

キャリアプロダクト開発部の森 ＠jiskanulo です。 この記事は、 ファインディエンジニア Advent Calendar 2025 の6日目の記事です。 adventar.org 現在Findyにて「うちのAIがやらかしまして」という企画ページを期間限定で公開しております。 https://findy-code.io/ai-yarakashi findy-code.io 「うちのAIがやらかしまして」はAIとの協働で生まれた“試行錯誤のエピソード”を投稿してもらう参加型企画です。 AIのやらかし・すれ違いをシェアし、皆さんの前向きな学びにつなげていく場を提供いたします。 今回は私のAIやらかし事例を紹介しつつ、同じやらかしを再度起こさないようにするため心がけることをご紹介します。 私のやらかし事例はいずれもClaude Codeの利用で起きたものですが、他のAIエージェントを活用されている方にも参考になれば幸いです。 AIやらかし事例の紹介 コードレビューに意図してないコメントを残された Pull Requestに関係ないファイルがコミットされていた 同じやらかしを繰り返さないために おわり AIやらかし事例の紹介 コードレビューに意図してないコメントを残された GitHubのコードレビュー内容を確認して、と指示を出したら対応するつもりのない内容をコメントとして残されてしまい慌てて訂正した findy-code.io このやらかしの原因は、私の指示が曖昧だったことです。 「コードレビューを確認して」と書いたつもりでしたが、「コードレビューを確認して 対応して 」と指示してしまったため、Claude Codeはそのレビューに返信コメントを投稿してしまったわけです。 コンソールを眺めていたらgh issue commentコマンドを発行しているのに気づき、慌てて訂正しました。短期間に正反対のコメントを連投しレビュアーに迷惑をかけてしまったやらかしです。 Pull Requestに関係ないファイルがコミットされていた 作業指示を出し、Pull Requestを作成してもらった。Pull Requestを確認すると作業指示に入っていないファイルもコミットされていた findy-code.io コミットされていたファイルは別のタスクでCLAUDE.mdの記述調整を依頼した際に作成された一時的なファイルでした。 Claude Codeが git add -A で全ファイルをコミット対象に追加し、そのままコミットを作成してしまったのです。 同じやらかしを繰り返さないために これら2つのやらかしを踏まえ、同じミスを繰り返さないための対策を整理します。 曖昧な指示が来た時に、Claude Codeに指示の内容を確認するようCLAUDE.mdに記載を追加しました。 これで思いがけない行動を取ってしまうことが減りました。 指示に不明な点や曖昧な点がある場合、作業を進めずに質問を返してください。 次に、指示が終わった後に意図しない挙動を示した場合、どうしてそうなったのか質問をし、回答を求めます。 以下は私が対話した内容の抜粋です。 私: 先ほど不要なファイルのcommitが混ざってしまった事象について、どうして起きてしまったのか、どうすれば再発を防ぐことができるか検討して提案して Claude: ⏺ CLAUDE.md.backupファイルが誤ってコミットされた原因と再発防止策を分析しました 原因分析 何が起きたか 1. PR #51 (docs-restructure-claude-md) でCLAUDE.mdのバックアップを作成 # 当時の作業 cp CLAUDE.md CLAUDE.md.backup 2. PR #51マージ後、mainから新ブランチを作成 3. git add -A で全変更をステージング 4. CLAUDE.md.backupがワーキングディレクトリに残っていたため、意図せずコミットに含まれた 根本原因 - ✅ バックアップファイルを作業後に削除しなかった - ✅ git add -A が全ファイルを無条件に追加した - ✅ コミット前のステージング内容確認を怠った 再発防止策 … これ以降、対話を続けて方針を定めました。 対話してまとめた内容をCLAUDE.mdに記載させ、次回以降同じことを起こさないようにしました。 内容が冗長だったり逆に限定的で不足している部分もありますが都度調整していきます。 最終的にCLAUDE.mdに追加した内容は次の2点です。 コミット前にステージングされているファイルを確認すること 意図していないファイルが含まれていないことを確認すること #### コミット前の確認 ```bash # ステージングエリアの確認 git status # 意図していないファイルが含まれていないことを確認 git diff --cached --name-only ``` おわり AIエージェントは最初から100％期待に沿う行動をしてくれるわけではありません。 いい加減な指示を出すと思いがけないふるまいをやらかしてしまいます。 時にはやらかしつつ、やらかしを再発防止策を考えて対策し、共に成長していくパートナーとして触れ合っていきましょう。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらからからご応募ください。 herp.careers

はじめに みなさんこんにちは。Platform 開発チーム SREでサブマネージャーの安達（ @adachin0817 ）です。この記事は、 ファインディエンジニア Advent Calendar 2025 の5日目の記事です。今回は2025年のSREチームの成果や課題などを振り返りたいと思います。 adventar.org はじめに Platform SREチーム ビジョンの再定義 2025年のPlatform SREロードマップ 主に取り組んできたこと Devinの活用 Terraform汎用モジュールとtestの拡充 Findy Team+ 本番DBクローン ワークフロー化 Findy Team+ AWSマーケットプレイス対応 Takumi SAST/DASTの導入 2026年に向けた展望と課題 おわりに Platform SREチーム ビジョンの再定義 「SREの文化を組織全体に根付かせ、開発チームが自律的にSREを実践できるように支援する」 このビジョンを元に、Platform開発チーム SRE(以下、Platform SRE)チームの方向性を再定義しました。これまでもビジョン自体は存在していたものの、メンバーの役割や責任範囲など曖昧で、チームとしてどう実現していくのかが十分に描き切れていませんでした。そのため、2025年に向けてビジョンをブラッシュアップし、具体的な行動指針へと落とし込みました。 また、ミッションは半期ごとに見直す運用へと変更しました。従来は年間を通して固定したミッションで動いており、課題や状況など大きく変化することが分かりました。そのため、より柔軟な意思決定と、チームメンバーの意志を反映できる仕組みにアップデートしました。 次は、2025年 Platform SRE ロードマップを解説します。 2025年のPlatform SREロードマップ AI活用 DevinやAI補助による運用・構築の自動化 Observability SLI/SLOの見直し Datadog RUMの検証 Cost パフォーマンス予測モデル導入 MCPによるコスト最適化 Security アプリケーション脆弱性対応 Takumi導入 Shisho Cloud棚卸し Infrastructure Team+ 本番DBクローン ワークフロー作成 Tools/Conference 本番DBのためのStgマスキングワークフロー作成 負荷試験環境 ログ基盤の設計 WordPressをShifterに移行 Terraform汎用モジュールの拡充 aws-nukeによる不要リソースの自動削除 Findy Team+ マーケットプレイス対応 CI/CD デプロイの共通化 GitHub Actionsのテンプレート化 ecspressoの導入 Automation 社内ツール実装(Go) 新規AWSアカウント作成業務の自動化 Onboarding 新規ジュニアメンバー教育 Culture SRE文化醸成 2025年のPlatform SREチームは、開発チームが自律的にSREを実践できる組織を目指し、8つの領域にフォーカスしてロードマップを策定しました。単なる改善タスクではなく、SREを仕組みと文化としてチームに埋め込むことを重視しています。 次は特に注力した取り組みについてまとめていきます。 主に取り組んできたこと Devinの活用 SREチームでは、新サービスが追加されるたびに、Shisho CloudとAmazon Security LakeをTerraformで連携しています。しかし、この設定手順は非常にシンプルでありながら毎回人手で作業することがトイルとなっていました。 そこで、Devinを活用した自動化に取り組み、Terraform連携を含む一連の作業をワークフロー化しました。さらに、GitHubアカウントの発行、AWSアカウントの作成、WordPressの軽微な修正などもDevin化し、SREのトイルを大きく削減できています。今後は、これらの仕組みを横展開し、より広く標準化していく予定です。 tech.findy.co.jp Terraform汎用モジュールとtestの拡充 tech.findy.co.jp 今年からは、新サービスをより高速に構築するため、Terraformによる汎用モジュールの整備に本格的に取り組みました。 これまでは既存コードの流用をベースに構築していたため、設定の漏れや環境差異を適切に把握できない状態が続いていました。 その課題に対し、Terraformの汎用モジュール化と Terraform Test の拡充することで、Apply前に失敗や設定ミスを検知できる仕組みを構築しました。これにより、信頼性を担保しながらもスピード感のあるインフラ構築が実現できるようになったと感じています。 Findy Team+ 本番DBクローン ワークフロー化 これまでは、Embedded SREが手動で本番DBのスナップショットを取得し、開発チームがそれを基にバッチテストや検証していました。しかし、テスト環境の構築に時間がかかるだけでなく、実際の運用に近い再現性が担保しづらいという課題がありました。 そこで、2025年からは 本番DBクローンを自動で生成できるワークフローを実装しました。この仕組みにより、バッチ処理を含むパフォーマンステストや検証作業を誰でも再現性高く実施できる環境が整備されました。安全性の確保にも配慮し、クローンDBは本番DBと隔離された環境で動作、アクセス制御を厳格に適用、本番相当のデータでテスト可能という形で、リスクを防ぎつつ、実運用に近いテスト環境を実現しています。 クローンDBの作成および削除は、すべてAWS CLIによるワークフローとして自動化しています。また、バッチのパフォーマンステストについては、Operationコンテナ上でAPIと同等の環境を再現しており、本番に近い条件での検証を行えるようになりました。 Findy Team+ AWSマーケットプレイス対応 aws.amazon.com Findy Team+では、AWSマーケットプレイスへの掲載準備が本格的に始まりました。これまでの直契約モデルから、AWS経由で利用できるモデルという選択肢が増えます。特にエンタープライズ企業では、調達プロセス・セキュリティ基準・契約形態・監査プロセスなどのハードルが高く、SaaS導入の初動でつまずくケースが少なくありません。その中で、AWSマーケットプレイス経由の契約であれば調達がスムーズになるため、AWS経由で使えることが導入条件になる企業でもTeam+導入の壁がさがることを期待しています。 今回の対応により、Findy Team+はエンタープライズ向けのSaaSとしての提供価値をより明確にしていくフェーズに入ったと考えています。 Takumi SAST/DASTの導入 flatt.tech Shisho Cloudを運用していく中で、アプリケーション層の脆弱性も同じ仕組みで検知・可視化したいという課題が生まれました。そこで、コード診断に特化した Takumi（SAST / DAST）を全サービスへ導入し、セキュリティ領域の基盤整備を進めました。 SASTによる静的解析ではコードの脆弱性を早期検知できるようになり、DASTによる動的解析では実行可能な攻撃パターンの再現・検証ができるようになりました。その結果、「診断 → 可視化 → 修正 → 再検証」 というサイクルが開発メンバーの中で自然と回り始め、SREチームによる支援型セキュリティの形が実際に機能し始めています。 また、DASTによるブラックボックス診断については、来年のSRE Kaigi 2026でもGMO Flatt Security CTO 米内さんと発表予定です。セッションではAI時代におけるセキュリティ戦略や、その実践的な導入アプローチについて具体的にお話しますので、ぜひご参加いただき、これからのセキュリティの在り方を一緒に考える機会にできれば嬉しいです。 ／ #srekaigi 協賛します！ ＼ GMO Flatt SecurityはSRE Kaigi 2026にダイヤモンドスポンサーとして協賛いたします！ ファインディSRE 安達様 @adachin0817 と弊社CTO 米内 @lmt_swallow によるスポンサーセッションも予定しています！ ぜひお越しください💁🏻‍♂️ https://t.co/HvZtuL7rBL — GMO Flatt Security株式会社 (@flatt_security) 2025年11月12日 2026年に向けた展望と課題 来年はSREチームとして、今年の取り組みを「仕組みを作る段階」から「仕組みを運用し、継続的に改善していく段階」へ移行していく予定です。単にSREの知識を展開するだけではなく、開発チーム自身が自律的にSREの判断・運用ができる状態を、より強く推進し、Enablingしていきたいと考えています。 おわりに 2025年は、SREチームにとって仕組みづくりと文化づくりの両輪で走り続けた1年でした。振り返ってみると、改善することよりも、なぜ改善するのか？どうあるべきなのか？を問い続ける1年だったように感じます。 まだまだロードマップは対応できていないものもたくさんあるのと、来年は今年つくった仕組みを本格運用フェーズへ進めつつ、開発チームが自律的にSREを実践できる組織づくりに挑戦していきます。 明日はjiskanuloさんになります！見ていただきありがとうございました。

こんにちは、ファインディCTOの佐藤( @ma3tk )です。この記事は、 ファインディエンジニア #1 Advent Calendar 2025 と ファインディデザインチーム Advent Calendar 2025 の4日目の記事です。 先日、 Findy AI+ という新規プロダクトのデザインシステムを1から設計しました。 片手間ながら1人で2〜3週間かけてベースの設計を仕上げた結果、これからのデザインシステムは「コードで管理すること」が不可欠だという思いが強くなりました。 なお、Figmaとコードの関係性の変化やAI時代における開発フローの変化など、関連するテーマは多くありますが、今回は「なぜコードで管理するのか」という背景を中心にお伝えします。 ユーザーと同じ環境でものを見る デザインツールと実装環境の違い コードで管理する最大の価値 型の力で強制できる 無理やり実装を防ぐ仕組み コードだからこそ実現できる強制力 最初から徹底できる 後付けでは浸透しない AI時代の開発スピードに対応する デザインをコード管理することは必要不可欠 Figma Schemaが示す方向性 ユーザーと同じ環境でものを見る デザインツールと実装環境の違い 従来のワークフローでは、Figmaなどのデザインツールでデザインを作り、実装はそれに追従する形でした。Figmaは優れたデザインツールですが、そこで見ている画面と、ユーザーが実際に触るプロダクトは異なる環境です。 デザイナーが意図した色やスペーシングが実装段階で微妙にズレることもあります。また、レスポンシブ対応で想定外の挙動が起きることもあります。デザイン時と実装時での乖離は、デザインツールと実装環境の違いから生まれる課題です。 例えば、ボタンの角丸が場所によって4pxだったり8pxだったり、余白が16pxと20pxで混在したりといった問題です。Figmaでは統一されているように見えても、実装では微妙に異なる値が使われることもあるでしょう。 これは、デザインツールと実装環境という2つの異なる場所で管理しようとすることの難しさです。 プロダクト開発に関わるメンバーが最も注目すべきは、プロトタイピングの画面ではなく、ユーザーが触る実際の画面だと考えます。 コードで管理する最大の価値 「ユーザーと同じ環境で、ものを見ることができる」 これがコード管理における最大の価値だと思います。 コードをマスターにすることで、実装された状態が常に正しい状態となります。 どれだけデザインツールで美しく見えていても、ブラウザで崩れていたら意味がありません。コードをマスターにすることで、デザイナーとエンジニアが「ユーザーが見ているもの」を直接触りながら改善できるようになります。 FigmaプラグインのToken StudioやCode Connectを使えば、コードで定義したトークンをFigmaに反映できます。つまり、Figmaでのデザイン作業は今まで通り行いながら、真実の情報源(Single Source of Truth)はコードに置くことができるのです。 効率化の話だけではなく、ユーザー体験の品質そのものに関わる問題だと捉えられます。 型の力で強制できる 無理やり実装を防ぐ仕組み Findy AI+の設計で最も意識したのは、「デザインシステムから逸脱できない仕組み」を作ることです。 テーマを作った後、実際にデザインシステムを適用させようとすると、無理やり実装しがちです。 css= や style= のような直接スタイルを当てる方法を使ってしまうケースです。 一度この逃げ道を許すと、デザインシステムは形骸化します。「急いでいるから今回だけ直接スタイルを当てよう」が積み重なり、気づけば誰も使わないものになってしまいます。 コードだからこそ実現できる強制力 Findy AI+では、Chakra UIをベースにデザインを行っています。Chakra UIのStrict Tokenモードを導入し、ESLintのルールを整えました。さらに、CLAUDE.mdとClaude Skillsでルールを明文化し仕組みを整え、生成AIにもデザインシステムを守らせるようにしました。 すると、エンジニアは必ずデザインシステムで定義されたトークンやコンポーネントを使わざるを得ない状況になります。例えば、直接スタイルを当てようとすると、Lintエラーが出てしまいます。 この強制力があることで、デザインシステムを形骸化させない鍵になると考えています。そして、この仕組みは今後デザインツールでできるようになるかもしれませんが、現在はまだ実現できません。コードで管理するからこそ、型の力で強制できます。 デザインされたものを一からコンポーネントとして実装するには多大な設計が必要です。しかし、Findy AI+では最初からデザインシステムをコードで定義し、逸脱できない仕組みを整えてきました。その結果、開発者が迷わずに実装でき、ルールが統一しつづけられる環境を作りました。 最初から徹底できる 後付けでは浸透しない デザインシステムの導入で最も難しいのは、浸透させることです。 すでに動いているプロダクトに後からデザインシステムを導入しようとすると、既存のコードとの整合性を取る作業が膨大になります。そして、その移行期間中は「デザインシステムを使っている部分」と「使っていない部分」が混在し、一貫性が失われます。 既存のプロダクトでも徐々にデザインシステムを適用していっていますが、浸透するまでに時間がかかります。デザインとしての一貫性がない状態からのスタートだったり、エンジニアがコンポーネントを置き換える作業が必要だったりと、後付けの導入には多くの障壁があります。 AI時代の開発スピードに対応する AI時代の開発スピードを考えると、後から統一する時間的余裕はありません。 最初に型を作り、デザインシステムを稼働させながら作ることがAI時代の作り方だと考えています。 Findy AI+では、プロダクト開発の初期段階からデザインシステムをコードとして定義し、そこから逸脱できない仕組みを整えました。この「最初から徹底」を実現するには、コードで管理することが不可欠です。 デザインをコード管理することは必要不可欠 Findy AI+でのデザインシステム設計を通じて、「なぜコードで管理することが不可欠なのか」を改めて実感しました。 ここまでを改めてまとめると、コードで管理すべき理由は大きく3つです。 ユーザーと同じ環境でものを見ることができること 型の力で逸脱を防ぐ仕組みが作れること プロダクト開発の初期段階から徹底して効率を上げられること デザイナーとエンジニアの両者が、デザインシステムの重要性を理解し、そして「コードで管理すること」の価値を理解していただけたら幸いです。 Figma Schemaが示す方向性 ちょうど先日、Figmaが「Schema」というイベントで 発表した内容 がこの考え方と合致していました。 Figmaの方針として、デザインシステムを「AIが読み取りやすいルールブック」として整備する方向に舵を切っています。Code Connect UIでFigmaコンポーネントとGitHub上のコードを紐付ける機能が発表されました。Figma MCP ServerでAIツールからFigmaデータを参照しやすくする機能も登場しています。VariablesのエクスポートでFigma変数をコードへ持っていきやすくなるなど、「FigmaデータとコードをつなぐAI前提の機能」が続々と出てきています。 この流れは、本記事で述べた「コードで管理する」という考え方を後押ししてくれるものだと感じています。Figmaは引き続き強力なデザインツールとしてプロトタイピングに活用しながら、ユーザーが見る実コードに主眼を置くことが大事だなと改めて思いました。 なお、今回は「Why」を中心にお伝えしましたが、FigmaとCode Connectの連携方法、Token Studioの活用、Storybookでの運用など、具体的な「How」についても今後記事にしていきたいと思います。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味がある方はこちらから ↓ careers.findy.co.jp

こんにちは！ファインディの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軒のお店をご紹介しました。どちらもエンジニアの皆さんを元気にしてくれるランチです。 なお、ファインディには 「社内コミュニケーション補助」 という制度があります。他部署のメンバーとランチに行くと会社が補助してくれるというもので、組織を超えた交流のきっかけづくりに役立っています。美味しいランチを食べながら、新しい出会いやアイデア交換ができる、まさに一石二鳥な制度です。 また、今回ご紹介したように、ファインディでは全国各地からさまざまなエンジニアが活躍しています。技術にこだわり、より良いものを追求する仲間とともに働いてみませんか？ 現在、新しいメンバーを募集しています。興味のある方は、ぜひこちらからチェックしてみてください！