【エンジニアの日常】これが私の推しツール! 〜日々の開発を豊かにするおすすめツール〜 Part4

こんにちは。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の推しポイント

  1. ターミナルを画面全体で表示・非表示するのが一瞬

    Hotkeyの設定で可能です

  2. 透かすことができるのでターミナル以外の画面も閲覧できる

    1. 開発していると、PRのレビュー対応や公式ドキュメントで使い方を確認しながら作業をすることがあると思います。私が属しているFindy AI+ではほぼ100%AI(Claude Code)がコードを書いています。指示を送る時はターミナルで作業しているためレビューコメントやドキュメントを透かして確認できるのが個人的に便利だと感じています。
    2. 透過状態での表示・透過を無効化した状態での表示もコマンドで切り替えられるので、コマンド作業に集中したい時は無効化にしています。
  3. 設定し放題

    1. 起動時のディレクトリの指定や、用途によって設定を切り替えられるProfileも用意されています

    2. 透過設定はColors設定によって変わりますが、ここで設定できます

  4. Tabの増減は、Command + T(追加), Command + W(削除)で可能です

今気になってるツール

チームメンバーの中にはWarpというツールを使っているメンバーもいます。

ここで紹介したツールの一部機能を持ち合わせていることに加え、過去のコマンド履歴が表示されたり(zsh-autosuggestionsのような感じ)、ターミナルなのに初期設定のままでも見やすいものになっています。

www.warp.dev

iTerm2の透過機能と即座の表示切り替えは、実用性の高い使い方だと感じました。

特に、ドキュメントやレビューコメントを見ながらターミナルで作業できる透過機能は、AI駆動開発が中心のFindy AI+における実際の業務フローとよく合っています。

Hotkeyによる瞬時の表示切り替えやProfileによる柔軟な設定など、自分の使い方に合わせてカスタマイズできる点も優れています。「初めて出会ったこのツールを使い続けている」という言葉に、道具との相性の良さが表れていますね。

おわりに

今回は、2名のエンジニアが使用しているターミナルツールを紹介しました。それぞれが自分の作業スタイルに合わせてツールを選び、カスタマイズしている様子をお伝えできたかと思います。

ファインディでは、さまざまなバックグラウンドを持つエンジニアが活躍しています。技術にこだわり、より良いものを追求する仲間とともに働いてみませんか?

現在、ファインディでは新しいメンバーを募集中です。 興味のある方は、ぜひこちらからチェックしてみてください!

Findyの爆速開発を支えるVibeCodingのコツ

こんにちは。

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

現在のソフトウェア開発の世界は、生成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つの修正を横展開することが出来ます。

  1. 差し替えるための新しいLayoutComponentを作成する
  2. 差し替え対象となるコードを全てリストアップする
  3. 差し替え対象から1箇所だけ選び、VibeCodingで正しい差し替えを1件完了させる
  4. リストアップした変更対象に水平展開させる

このように、生成AIとの会話履歴を意識すると、若干曖昧な表現だとしても会話履歴から補完して精度を保つことが出来るケースがあります。

まとめ

VibeCodingの相手は生成AIですが、結局は人間を相手にしていることとあまり変わらず、明確で簡潔な内容を1個ずつ指定することや、会話履歴を意識することが重要であることが分かったかと思います。

今回の記事が皆さんの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に自然言語で指示を与えながら直感的にコードを作り上げていく開発手法

【Claude】Agent Skills入門 - はじめてのスキル作成 -

こんにちは。

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

現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。

GitHub Copilot や Claude Code など、生成AIを活用した開発支援ツールが次々と登場し、日常的なワークフローに組み込まれつつあります。

そんな中で先日、Claudeの新機能であるAgent Skillsが公開されました。

そこで今回は、Agent Skillsの紹介と解説、スキルの作り方を紹介したいと思います。

それでは見ていきましょう!

Agent Skillsとは

Agent SkillsはClaudeの機能を用途や状況に応じて柔軟に拡張できる便利な機能となっています。

docs.claude.com

Claude Code のバージョンが1.0以上であれば、誰でも簡単に利用することが可能です。

スキルはClaudeが必要に応じて読み込むための指示を含む SKILL.md ファイルと、スクリプトやテンプレートなどのオプションのサポートファイルで構成されています。

スキルはモデルによって呼び出されます。Claudeはユーザーが入力したプロンプトとスキルの名前、説明に基づいて、いつどのスキルを実行するかを自律的に決定します。

公式ドキュメントによると、主なメリットは次の3つが挙げられています。

  • 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

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

こんにちは。CTO室データソリューションチームの開です。

この記事は「エンジニア達の人生を変えた一冊」として、弊社エンジニア達の人生を変えた本を紹介していきます。エンジニアとしてのキャリアや技術的な視点に大きな影響を与えた一冊とは?それぞれの思い入れのある本から、技術への向き合い方や成長の軌跡が垣間見えるかもしれません。

今回は私・開と、松村さん、田頭さんの3名のエンジニアが、人生を変えた一冊を紹介します。 まず私から、データエンジニアとしてのアイデンティティを確立させた一冊を紹介させていただきます。データ基盤構築の世界に深く足を踏み入れるきっかけとなった実践的な書籍です。

■ 開功昂 / データエンジニア ■ CTO 室データソリューションチームでデータエンジニアをやっている開です。

実践的データ基盤への処方箋〜 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ

私が紹介する「実践的データ基盤への処方箋」は、データ基盤構築のためのノウハウが詰まった書籍です。

この本を読んだきっかけ

この本が出た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」は、タイトルの通りにRubyのメタプログラミングの概念や挙動について解説している書籍です。

この本を読んだきっかけ

当時勤めていた会社で、いくつか推奨書籍的なものがあったのですが、その中の一冊でした。
その時の上司から

「メタプログラミングがわからないと、gemの中身やRailsの挙動は理解できないから松村くんも読んでみるといいよ! 後、黒魔術っぽくて面白いよ!」

的なことを言われて「黒魔術???」となったのを覚えています。
当時は「何がなんだかわからんが動いているのでヨシ!」の精神でgemを使っていたので、良い機会だから読もうかなとなったのがキッカケです。

本の内容

本書は、Ruby における「メタプログラミング」、つまり「プログラムがプログラムを記述・改変する」技術を丁寧に解説しています。

前半(第Ⅰ部)は、オブジェクトモデル、動的メソッド定義、ブロック/クロージャ、特異メソッド、コードを生成・評価する手法など、Ruby が持つ "魔術" 的な仕組みを順を追って解説しています。

後半(第Ⅱ部)では、実践として Ruby on Rails におけるメタプログラミングの事例(例:ActiveRecordの設計、ActiveSupportのConcernなど)を通じて手法の応用方法を紹介しています。

総じて、現実的なコードを読み解きながら「なぜそのように設計されているか」を理解できるようになっており、単なる言語機能の説明にとどまらず、Rubyという言語自体の設計思想にも踏み込んでいます。

後、角先生の翻訳本全般に言えることなのですが、原書のテイストを残したまま日本語としてもわかりやすく書かれていて、単純に読んでいて面白いです。

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

とにかくRubyのコードを読んで、挙動を頭の中でシミュレーションするのが楽しくなりました。

「今どのクラスをさわっていて、そこにprependでこのモジュールを貼り付けてメソッドが生えたから〜」というのがクラス図として脳内でムクムク描かれていく。
そして頭がパンクして、実際にコンソールでancestorsを叩いてみて、フムフムこのクラスの継承木はそうなっているのかとまた解き明かしての繰り返し。

実践的なところで言うと、gemのコードリーディングをするのに抵抗がなくなりました。ライブラリのバージョンアップが来ても、コード差分を読み込むことで、自信をもってバージョンを上げられるようになります。

また、最終的に「メタプログラミングを実践してみたい!」という気持ちと、当時所属していた開発組織の課題が相まって、メタプログラミングを駆使してgemを作成してリリースしました。ファインディを受ける時も、この話題で現VPoE神谷とは盛り上がりました。

特に印象に残った部分

全部です!

と言いたいところなのですが、第3章「動的メソッド定義と特異メソッド」はメタプログラミングを支える柱と言っていいかもしれません。

3章ではメタプログラミングの核心部分である define_methodmethod_missing、特異クラス(シングルトンクラス)を使った動的振る舞いの定義方法を具体例とともに学べます。 普段のRubyプログラミングではなかなか意識しない「オブジェクトのクラスやメソッド構造を動的に変えられる」仕組みを体感できます。

2章あたりまでで心が折れて積ん読になっている方は、是非3章までは読んでみることをオススメします!

このような方におすすめ

Rubyを用いて定常的な開発・保守業務ができるようになった後、次のステップとしてディープダイブしたい方は読まれることをオススメします。

また、実行時まで挙動がわからないメタプログラミングはまだまだ生成AIが弱い領域だと思っていて、今の時代だからこそRubyエンジニアとして一皮剥けるために良い書籍だと思います。

最後は、同じくCTO室データソリューションチームの田頭さんです。田頭さんが選んだのは、第三次AIブームの到来を予見した先見性のある一冊。生物専攻からデータエンジニアへの転身を決意させた、AIの可能性を感じる一冊です。

■ 田頭啓介さん / データエンジニア ■ CTO室データソリューションチームの田頭です。

人工知能は人間を超えるか
ディープラーニングの先にあるもの

私が紹介する「人工知能は人間を超えるか」は、第3次AIブームまでに至るまでの人工知能の進化についてまとめられた書籍です。

この本を読んだきっかけ

この本を読んだのは大学2年生の時です。当時生物専攻だったのですが、たまたま遺伝子解析でデータ分析や機械学習に触れる機会があり、人工知能について概観を知っておくために読みました。

本の内容

この本は、人工知能について一般読者向けに解説した入門書です。ディープラーニングに端をひらく第三次AIブームまでの歴史を振り返りながら、専門家と一般の人々の間にある人工知能への認識のズレを明らかにし、この先どのように生きていくべきかを考察しています。

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

この本でデータやAIの可能性に強く惹かれたことで機械学習エンジニアを目指すようになり、現在のデータエンジニアとしてのキャリアに繋がりました。

特に印象に残った部分

改めて読み直したのですが、終章の「変わりゆく世界」が特に印象に残りました。実際に生成AIによって世の中が激変していく中、10年前の段階でここまでAIが発展している未来を予測できているのはすごいと感じました。

このような方におすすめ

AIへの基礎的な知識を身に付けたい人におすすめです。

2015年出版当時から10年が経っていますが、AI活用が加速し、「人工知能」という言葉が溢れている今こそ読むべき内容だと思います。

おわりに

今回ご紹介した3名のエンジニアが人生を変えた一冊は、それぞれの専門分野や関心領域を反映した多様な選択でした。技術書との出会いは、単なる知識の獲得だけでなく、キャリアの方向性そのものをもたらしてくれるものです。

ファインディでは、さまざまなバックグラウンドを持つエンジニアが活躍しています。興味のある方は、ぜひこちらからチェックしてみてください!

【日本語訳全文】Kent Beck氏 基調講演:開発生産性測定のトレードオフ「グッドハートの法則」はもっと悲観的に捉えるべきだった・後編

こんにちは。Findy Tech Blog編集長の高橋(@Taka_bow)です。

前編では、グッドハートの法則の本質と、指標に圧力をかけることで開発現場がいかに歪められるか、そして"もっと悲観的に捉えるべきだった"理由を見てきました。

後編では、Beck氏が提唱する「価値の道すじ」の概念と、AI時代における測定の問題、そしてリーダーが実践すべき具体的なアプローチについて解説します。

前編はこちら tech.findy.co.jp

講演動画

※ 視聴には Findy Conference へのログイン、並びに視聴登録が必要です。ご登録頂ければ、他の講演アーカイブも視聴できます。


日本語訳全文(続き)

ソフトウェアが価値を生み出す4つの段階

Kent Beck氏:ではどうやって抜け出すのか?プログラミングのジーニー(生成AIのこと)についてお話しします。

ソフトウェアの価値を生み出す方法は?他にもありますが、私はプログラマーですから、今はソフトウェアの話をします。

まずは"労力(Effort)"の話です。プログラマーが何かのアプリのために、プログラミングに時間をかける。それが労力(Effort)です。

それは時間で測ることができます。

お金で測ることもできます。

その時間で他に何ができたかという機会費用で測ることもできます。とにかく最初の指標は労力(Effort)です。

アプリにボタンを追加したいとして、作るのにどれだけ時間がかかったか?プログラマーが労力(Effort)を費やせば、何かしら形になるものができます。これが"アウトプット"です。

今までなかったボタンが表示されます。よし、いいぞ。

労力(Effort)は比較的簡単に測定できます。アウトプットは少し難しくなります。

10個のボタンがあったら、5個のボタンより2倍良いのでしょうか?数えることはできます。まだ確信は持てませんが、それでもアウトプットの測定も比較的簡単です。

さて、アプリに新しいボタンがつきました。しかし、まだ価値は生まれていません。顧客が何か新しい行動を取るまではね。

顧客がこれらのボタンがあることの価値を認識し始めます。

"ここからここへのショートカットがずっと欲しかったんだ"、"今では新しいショートカットをいつも使っている"、"だからこのアプリがもっと好きになった"。

私が話している、"成果(Outcome)"とは、こういうことです。つまりユーザーの行動の変化なんです。

そして最終的に、私たちがプログラマーとして時間を費やして生み出した価値は、会社に戻ってきます。その形は収益の増加であったり、顧客満足度の向上であったりします。

コスト削減もまた、私たちの会社が収益性を上げる1つの方法かもしれません。

そして、そのプロセスの成果(Outcome)を収穫し、再び労力(Effort)に注ぎます。そうして会社は、プログラマーに報酬を払えるのです。プログラミングで報酬を得られるのはうれしいですね。

この、"価値の道すじ"のプロセスで、私が気づいたのは、"労力(Effort)"に近いほど物事を測定しやすいということです。

ですが同時に、指標は仕組みをゆがめる可能性があることを思い出してください。指標に圧力をかけると、仕組みの目標をゆがめてしまうのです。労力(Effort)の側に寄るほど、仕組みをゆがめる可能性が高くなります。

私は、若いプログラマーだった頃、より良いプログラミングをするために、より多くの時間を費やしました。

結論だけ言うと、それで自分を壊しかけました。週100時間以上働いて。

でも結局、それは無理なんです。念のため言っておきますが、やめてください。

時間は測定しやすく、制御も簡単です。しかしプログラミングに費やす時間を測定し制御しようとし、そして最適化しようとすると、良くない結果になります。

ちょっと右に移動しますね。少し難しい話になります。

ボタンを作るとして、それは難しいでしょうか?簡単でしょうか?

ボタンが2つあります、あなたが1つ作って、私が1つ作った。これは比較的、測りやすいですね。

労力(Effort)ほど簡単ではありませんが、比較的簡単に測定できます。そして私が話しているゆがみの影響(Impact)も少し小さくなります。

しかし、追加したボタンを誰かが気にしますか?成果(Outcome)が出るまで分からないんです。

"あなたはボタンを10個追加した、彼らは5個追加した"、"だから、あなたは2倍優秀だ"。

ですが顧客の行動を見るまでは、成果(Outcome)を比較することはできません。しかしユーザーの行動を注意深く観察すれば、アウトプットを比較することは少し簡単になります。

ではもし、あなたがボタンを追加することで、彼が追加したボタンが使いやすくなっていたら?その2つがそろって初めて、顧客がその機能を評価してくれるとしたら?

あなたが検索の速度を5倍にして、彼がグラフを追加する。高速になって、更にグラフがあるから、人々の行動が変わる。その場合、2つのチームの貢献度を切り分けるのは難しくなります。

どちらの功績かハッキリ言えません。こうして測定は更に難しくなります。

しかし、例えば、プログラマーの労働時間を測るか、顧客の行動変化を測るか。経営者として選ぶとしたら、私が測りたいのは100%、顧客がどう行動を変えたかです。プログラマーの頑張りには、あまり関心がありません。

そして、"影響(Impact)"の話に戻ります。

"この会社はどれくらい利益を出しているか?"、収益の増加は?コストの低下は?成長のスピードは?これらはすべて影響(Impact)の話です。

この時点でも測定は可能です。四半期ごとの財務状況もあります。しかし誰の功績なのかは分かりません。

"君が労働時間を増やしたから会社の利益が上がったね"。そんなことは誰にも分かりません、不可能なんです。

プログラマーが優秀でも、マーケティングの仕事がひどかったら?

そして収益性が変わらなかったら?

プログラマーの生産性とは関係ありません。その逆もあり得ます。プログラマーの仕事の出来が悪くても、マーケティングは優秀で収益性が上がっていたら?

価値の道すじの中で先の方へ進めば進むほど、特定の人や特定のチームに価値を帰属させるのは難しくなります。しかし指標が仕組みをゆがめる傾向は弱くなります。

アメリカ企業がよくやるように、四半期の利益だけにこだわれば、さすがにこの仕組みはゆがみ、期待とは違う結果になります。

それでも、プロセスの初期でプログラマーにこう言うよりは、ゆがみは少ないんです。

"6時半に帰宅したのか、うちのチームは8時まで残ってるぞ"。

もしそんなレベルで制御するなら、確実にゆがみを生むでしょう。

"プログラマー1人当たりの収益性は?"の方がマシです。"プログラマー1人当たりの売上"、"1人当たりのコスト"も同じです。

AIが変えるもの、変えないもの

さて、AIについて少しお話しします。

この会場でGene Kim氏に会えてうれしいです。(注:Gene Kim氏はもう一人の基調講演者です)

Gene Kimは私を、AIベースのプログラミングに、"感染"させました。

私は、"拡張プログラミング"と呼んでいます。これが2ヵ月前か3ヵ月前のことで、それ以来、AIを使ったプログラミングを私は非常に楽しんでいます。

そして気づいたのは、機能を完成させるために必要な労力(Effort)が劇的に減ったということです。

さて、拡張コーディングの話は楽しいので何日でもできますが、今日はやめておきます。しかし時には労力(Effort)が増えることもあります。

AIというコーディング仲間は、とんでもなくバカなこともするからです。そこは覚悟してください。

しかし労力(Effort)は減り、プログラマー1人当たりのアウトプットは増えます。しかし労力(Effort)とアウトプットのレベルでの測定は、仕組みをゆがめることを思い出してください。

AIのおかげで10時間の作業が1時間でできたとしても、このプロセスをどう管理すべきかについては、何も変わらないのです。

もし私たちが、"10倍速くなったぞ、すばらしい、みんなに10倍の速さで作業させよう"、こんなことを言えば、仕組みにゆがみが生じることになります。

やはり私たちが重視すべきなのは、ソフトウェア開発全体を測定し、全体を意識することです。そうでないと、制御しようとして仕組みをゆがめてしまいます。

ジーニーでコーディングすれば労力(Effort)は減り、アウトプットは増えます。多分ね。

具体例を出します。人々は心配しています。

"ジーニーを使ったコーディングで若手プログラマーが不要になるのでは?"と。

シニアプログラマーの方が生産性が高いからです。"若手なんて必要ないだろう?"、"彼らは大きな混乱をより速く生み出すだけだ"。

私は選択の問題だと思います。

私はジーニーを教育用チューターとして使うのが好きです。Rustなどの理解できない言語でも、プログラミングをしてきました。Haskellとかね。そんなプログラムを見て思うことがあります。

この、"&&[~~"というのは一体何なんだ?そこで手を止めて、"これを説明して"と言うと、ジーニーがいつでも説明してくれます。

すばらしいことです。

若手を育てる際に、彼らの労力(Effort)やアウトプットではなくて、どれだけ学んだかで評価してはどうでしょう?

例えば毎週の若手との会話の中で、こう聞くんです。

"今週、学んだことを3つ教えて"とね。"今週、追加した機能を3つ見せて"ではありません。

アウトプットを重視するか、学びを重視するかの選択です。長期的に見れば、雇用者にとっての価値を生み出すのは学びです。

若手は大量のコードを書くためにいるわけではありません。むしろ問題の種になることが多いので、大量のコードは書いてほしくないのです。でも早く学んでほしいと思っています。

そしてジーニーは、若手の学びを早める新しい手段となり得るのです。

もし私たちがアウトプットを重視するのであれば、学習に集中することで、確かにアウトプットは遅くなるでしょう。

それでも私は断然、学習を重視したいです。なぜならそれが長期的に見て、必要な価値を生み出すからです。

指標を見る人と行動が重要

私がめったに見ない質問は…。生産性の話に戻りますね。生産性とはアウトプットとインプットの比率です。

私がめったに見ないのは、"誰がこの数字を見るのか?"、"見た結果、どんな行動を取るのか?"という質問です。

もし最高財務責任者が、プログラマーの2割を解雇したいと思っているなら、どんな指標を当てはめようが同じです。ソフトウェア開発に恐ろしいゆがみを生むでしょう。

しかし例えば、現場のマネジャーが、部下が早く学ぶのを助けたいと思っているのなら、全く異なる見方になるでしょう。

私がいつも考えるのは、"単位は何か?"ということです。

"1日当たりの開発者1人当たりのPR"と誰かが言ったとします。しかし私が投資家の立場だとしたら、開発者のPRなんかに興味はありません。

会社の成長や収益性に何の影響(Impact)もありませんからね。"いつか株を売れるだろうか?"という判断に何の関係もありません。

"開発者の生産性を測っています"と言われても、それは私が気にかける単位ではありません。

投資家として気になるのは利益です。私はアウトプットもインプットも、金額で測定してほしいのです。

もし追加のプログラマーを雇うとして、生産性が1.4倍とか3倍とか7倍になると分かれば、プログラマーを雇うのは理にかないます。

しかし、"1日当たりのPR数が3件から6件になります"と言われても、プログラマーを追加で雇うべきなのか分かりません。しかし利益を見ることができれば、その数字を使って良い決断を下すことができます。

リーダーにできること

ではどうすればいいでしょう?皆さんはマネジャーなのか、上級開発者なのか、リーダーシップを取る立場にあるとします。

まず最初に…、ちょっと気が滅入る話なのは分かってます。聞いてくださる皆さんに感謝します。できることは、いくつかあります。

1つ目は、"あとで確認すること"です。早い段階でしてはダメです。価値の道すじの初期段階で確認すると…、確認するだけでもダメですよ。

"タイムカードをつけよう"とかね。年配のプログラマーとしては、何か恐ろしいことの始まりだと思います。

または、"バグを自己申告しよう"とかね。私は疑い深いんです。

指標は労力(Effort)の側に近づけば近づくほど、仕組みをゆがめるので、あとで確認してください。そして、あとの段階で言ってください。

"これが開発者1人当たりの利益だ、達成する方法は問わない"、"でもこれが…"、"うちの開発者1人当たりの利益と、競合他社の開発者1人当たりの利益"、"どうするかは君たちに任せる"。

早い段階ではなく、あとで確認してください。会社への直接的な影響(Impact)が確認できないなら、成果(Outcome)を観察するのが良い方法です。ソフトウェア開発の有効性を評価するためにはね。

2つ目のポイントは、意識向上の促進です。つまり、システムを速くするための最高の手法の1つは、システムの速度をグラフ化することです。何も言わなくていい。ただ…。

"これがこのシステムの速度です"というグラフを週に1度出すだけです。プログラマーはそれに夢中になり、改善したくなるでしょう。

"このグラフは何だ?なぜ上昇したんだ?"、"分からないな、自分で調べてみてよ"。リーダーはこれだけで意識を向上させられます。

圧力とは真逆です。リーダーとして圧力をかけないのは難しいことです。しかも圧力をかけると、仕組みにゆがみが生じます。

その代わりにできるのは、私が直面した中でも困難な課題ですが、目的を浸透させることです。どうチームに伝えればいいでしょう。

"ねえ、これを見て"、"本番障害がこのペースで起きなかったら、すばらしいと思わないか?"、"できるよ、私たちなら可能だ"、"今、何があれば、それを達成できると思う?"。

いけないのは、"本番環境で障害?君はダメなプログラマーだ"と言うことです。

それは圧力のアプローチです。押すのではなく、引くのです。

そのためには、リーダーとして現状に対する責任を持つ必要があります。そしてこう言います。

"私は障害が多すぎる環境を作ってしまった"、"でも今後はやり方を変えていきたい"。

この転換ができれば、グッドハートの法則に…。グッドハートの法則の悲観的な部分に、私たちは影響(Impact)を受けなくなります。指標に圧力をかけなければ、結果を変えずに測定できます。

代わりに、人々が最高の自分を目指すことを後押しできます。それは最高のレベルで創造し、共有する目標に全力を注ぐことです。その目標は揺るぎません。

私たちは、より大きな視点でソフトウェア開発を見ることを選んだからです。

ソフトウェア開発は、誰もが参加できる魔法のようなプロセスで、今でも成長を続け、私を驚嘆させ続けています。私たちなら目標を達成できます。

皆さんのお時間とご清聴に感謝します、ありがとうございました。

(会場拍手)


※ 講演後行われたサイン会は大盛況でした。

まとめ

25年ぶりの来日となったKent Beck氏の講演は、開発生産性の測定がもたらす根本的な問題を語るものでした。四半世紀の時を経ても変わらぬパワフルなメッセージは、私たちの開発現場の課題を深く考えさせられる内容でした。

講演から得られた重要なポイントをまとめます。

  1. グッドハートの法則の真の意味 - 指標が目標になると良い指標ではなくなるだけでなく、仕組み自体を壊してしまう
  2. 測定と制御は別物 - 測定すること自体は価値があるが、指標でシステムを制御しようとすることが問題を引き起こす
  3. 価値の道すじ - 労力(Effort)→アウトプット→成果(Outcome)→影響(Impact)という流れの中で、測定しやすい指標ほどシステムをゆがめる
  4. AIは本質を変えない - AIで効率が上がっても、指標に圧力をかければシステムをゆがめるという本質的な問題は変わらない
  5. リーダーシップの役割 - 圧力ではなく、目的を浸透させ、意識を高めることが重要

Beck氏が最後に語ったのは、指標に圧力をかけなければ結果を変えずに測定できるということです。

つまり、測定そのものは続けながら、グッドハートの法則が引き起こす問題から逃れられる。測定は理解のため、意識向上のために使い、制御の手段にはしない。

この転換により、開発者は最高の自分を目指し、創造性を発揮できるようになります。単なる生産性向上のテクニックではなく、開発組織のあり方そのものを問い直す講演でした。

前編はこちら tech.findy.co.jp


We're Hiring

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

herp.careers

【日本語訳全文】Kent Beck氏 基調講演:開発生産性測定のトレードオフ「グッドハートの法則」はもっと悲観的に捉えるべきだった・前編

こんにちは。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? ―個人で実践する経験主義的ソフトウェア設計』が出版され、現代のソフトウェア設計についての思想を発信し続けています。

今回の講演では、ソフトウェア開発の生産性測定におけるトレードオフと、単純な指標のリスクについて語られました。

講演タイトルの「グッドハートの法則はもっと悲観的に捉えるべきだった」は、イギリスの経済学者チャールズ・グッドハートが提唱した「指標が目標になると良い指標ではなくなる」という法則を指しています。

Beck氏はこの講演で、グッドハートの法則が示す問題は、実際にはグッドハートが想定していたよりも深刻であると主張しました。

開発生産性を向上させようとする試みがなぜ逆効果をもたらすのか。AIの台頭によってこの問題はどう変化するのか。リーダーは測定の目的と限界をどう理解すべきか。

Beck氏の講演内容をノーカットでお届けします。


日本語訳全文

オープニング

Kent Beck氏:ありがとう。ありがとうございます。

(会場拍手)

日本に戻ってこられてうれしいです。皆さんのスマホがダンスのように一斉に上がりましたね。練習したみたいに。

(会場笑)

前回日本に来たのはもう25年ほど前になります。「エクストリームプログラミング」が出版された時です。

あの本は…ああ、笑顔が見えますね。日本で非常に人気の本でした。世界のどこよりも日本で人気がありました。

(注:現在発売されているものは、2nd Editionです)

そこ(登壇者控え席)に座って、"どう話を始めようか?"と考えていると、前に来日した時のことを思い出しました。

大きな書店に行くと私の本が山積みで売られていて、"すごくいい気分だ、これが私の本だなんて"と思いました。

私は本にサインしようと1冊手に取りました。⋯⋯お持ちですね、後でサインします。

私は積んである本から1冊を手に取りレジに向かいました。そしてレジの女性にペンを借りてもいいか尋ねました。

彼女は私を見ました。

「違うんです、この表紙は私ですよ」と私は言いました。

(会場笑)

彼女は疑った様子でペンを貸してくれました。

本を開いて私が名前を書き始めると息をのむ音が聞こえました。私が落書きをしているように見えたんでしょうね、本の中にね。彼女は、"信じられない"といった様子で…。

私はただ本を山に戻して店から逃げ出しました。

それが私の前回の日本での経験ですが、戻ってこられてうれしいです。ファインディに感謝します。私を招待しこのセッションを実現させてくれてありがとう。

スポンサーの皆さんにも感謝を。きっとすてきな人々なので彼らの製品を買いましょう。これで、このセッション内での宣伝は終わりです。

開発生産性とは何か

さて、今日は開発生産性について話すよう依頼されました。そして、これは一見とても単純な話に思えます。開発者がいて、彼らは何かを開発する。

生産性が高ければ良いことであり、生産性が低ければ悪いことです。では生産性を上げるには、どうすれば?

これは単純な話ではありません。あるドイツ語の単語があります、発音しませんが、"改善しようとして悪化させてしまう"という意味の言葉です。

補足 "verschlimmbessern"という単語のことかと思われます。"verschlimmern"(悪化させる)と"verbessern"(改善する)を組み合わせた造語で、善意で何かを良くしようとした結果、かえって状況を悪くしてしまうことを表します。

開発者の生産性に関して私が何度も目にしてきたのは、物事を改善しようと押し進めることで悪化させてしまうことです。

そして、招待されてから今日までの間にも、AIがその問題を良くするどころか更に悪くしてしまいました。

今日は、ある組み合わせについてお話しします。大事なのは組み合わせです。1つは開発者の生産性です、その定義についてもお話しします。

もう1つは測定の問題、つまり単純な指標が、しばしば意図した効果と逆の結果を引き起こすという問題。そしてAIの使用によりなぜそれが悪化してしまうのか?

最後に、ここにいる皆さんは技術者ですから、"もっと早く"、"もっと生産性を高く"というプレッシャーに直面した時、この問題にどう立ち向かえばいいのか?

今朝、一番上の子どもからメッセージが来ました。あるプロジェクトに30週間かかる予定だったのに、24週間ですべてを終わらせるように、そう指示されたそうです。

私の子ですから、"全部は終わりませんよ"と答えた。"でも、やるんだ"と言われ、"それは私の仕事じゃない"と返す。

私たちが常に直面していることですね。やることが多すぎるのです。そうでなかったら給料をもらいすぎということになる。

やることは常に山積みです。だからどんなに生産性を上げてもプレッシャーが軽くなることはありません。プレッシャーは常にあります。

私はAIを"ジーニー"と呼ぶのですが、それは…。ジーニーとは願いをかなえてくれるものです。願いを3つかなえてくれますが、与えられるものは願ったものとは違います。

かなったように見えるだけです。世界中の金を願ったらその金の下敷きになるとかね。それが今、私たちが扱っているものです。

おかげでこの問題はますます悪化しています。詳しく見てみましょう。

生産性の定義

まずは基本中の基本から。生産性とは何でしょうか?

生産性とは比率です。アウトプットとインプットの比率であり割合です。そして、今はこれ以上詳しくは話しませんが、このあとの測定の問題を話す間、頭の片隅に置いておいてください。

話を戻します、生産性とは何を意味するのか?どうすればそれを悪い方向ではなく良い方向に役立てることできるのか?

マッキンゼーレポートへの批判

2年ほど前のことです。コンサル会社のマッキンゼーが、開発生産性に関するレポートを発表しました。そしてそれは…、言葉を選んで話しましょう。礼儀正しく言えば"世間知らず"でした。世間知らずです。

"開発生産性を上げる"ための提案はどれも、状況を悪化させるものでした。経験ある開発者としては明らかにひどいアドバイスだと思いました。

そこで私は 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

グッドハートの法則

その前にまずお話ししたいのは測定の問題です。なぜ物事を改善しようとした取り組みが事態を悪化させるのでしょう?

ここで、ある古典的な言葉があります。グッドハートというイギリスの経済学者がいました。後ほどお話ししますが、彼はある観察をして、その観察は人類学者によってこう言い換えられました。

"指標が目標になるとそれは良い指標ではなくなる"

これは完全に事実です。こう言われたとします。

"君はプログラマーだな、タイピングはどれぐらい速い?"

"もっと速くタイプしろ"

もし仮にタイピング速度と利益率に相関関係があったとしてもです。開発者はただ座って指をたくさん動かすようになるでしょうね。指を速く動かせば給料が上がるんですから。それは本当に求めていたものではありません。

指標自体は役に立つものですが、指標が目標になった途端、それは良い指標ではなくなってしまうのです。

これは言い換えられたもので、グッドハートの言葉ではありません。本来の彼の言葉は…。舌を噛みそうになる言葉です。

ある仕組みの中で統計的な規則性が観察されたとします。"これが上がると、これが下がる"というような規則性です。

しかし仕組みを制御しようとインプットに働きかけてアウトプットを変えると、その規則性は崩れてしまうのです。

例として、ある時期イングランド銀行が、借入の水準をコントロールしたいと考えていました。インフレ率を調整したかったのです。

そこで気づいたのは、短期金利を上げると借入は減り、短期金利を下げると借入が増えるということです。

統計分析の結果、このような規則性があることは世の理だと分かりました。短期金利が下がると借入が増え、上がると借入が減るのです。

彼らは思いました。

"やるべきことが分かったぞ"

"我々はハンドルを手に入れた"

"金利を上げれば借入を減らせる、下げれば借入を増やせる"

"完璧だ"

これは成功しました。短い間だけはね。

この方法の問題は、意思決定者が自分だけではないということです。銀行は金利を下げたり上げたりできますが、借り手にも選択権があります。

更に他の銀行が新しい金融商品を作って、短期借入金利の影響から顧客を守ろうとします。

最初のうちは確かに金利を上げれば借入は減りました。しかし、しばらくそれを意図的に繰り返していると、金利を上げても借入は減らなくなります。

なぜなら他のプレイヤーがそれに適応してしまうからです。

ここで、"指標が目標になると良い指標でなくなる"というグッドハートの法則の言い換えですが、その下にまた別の層があります。

それが元々グッドハートが言ったことです。

誰も読まないような地味な論文の脚注に書かれました。そんな脚注で有名になるとは、皮肉ですよね。

とにかく、統計的な規則性を見つけ、それを仕組みを制御するために使うと、それはもう制御手段としては機能しなくなってしまうのです。

さて、私はよくグッドハートの法則について話すのですが、それは最近ソフトウェア開発の指標が注目されているからです。

生産性もその1つですね。

深い層にあったグッドハートの元の言葉を見つけられて、うれしかったものです。

そこから考えるようになりました。世界はこれよりもずっと悪い状況なんじゃないかとね。これも悪いですよ。

つまりレバーがあって、それを引くと、最初はうまくいったとしてもしばらくすると何も起こらなくなる。

仕組みを制御できないということですから、これは悪い状況です。

しかし実際はもっと悪いのです。

測定は必要だが、制御のためではない

例を挙げましょう。

私はよく、ソフトウェア開発の測定を行う人たちと議論しているのですが、その際、ソフトウェアの測定方法についてたくさんの指標が提案されているのを耳にします。

先日LinkedInでこれについて少し書きました。私が受けた反応は"あなたはただ…"

⋯⋯何かな?慌てた顔も見えましたが大丈夫です。動かないようにします。(注:ちょっとした機材トラブルがあった模様)

私が指標に懐疑的なことを言うと誰かがこう返しました。

「あなたはただ何も測りたくないだけでしょう」

それは100万%違います。

私は自分のソフトウェア開発プロセスを測定しています。開発を始めてからずっとです。そして非常に価値があると思っています。

自分がやっていることを数値化して分析して解釈できるのですから。

しかしそれは、"このレバーでシステムを制御できる"という感覚とは全く別物です。人と話していて指標を提案されると私は、"でもこの場合はどうなる?"と聞きます。

私はソフトウェア開発というものを理解しようとしていますよ。私たち全員が参加できて、規模が変わっても機能する、魔法のようなプロセスです。

ソフトウェアの驚くべきところは、純粋な知的活動の中で、これほど規模を拡大できるものはないということです。

数学などにも同じような美しさがありますが、1つの定理に100万人の数学者を取り組ませることはできません。数学はそういうものではありませんが、ソフトウェアでは可能です。

さて、私はソフトウェアを測定して理解したい。

プルリクエスト(PR)を見てみましょう。プログラマー1人当たりの1日のPR数を数えることにします。

なぜなら、プログラマーを観察していると、非常に効率的に見える人もいれば、そう見えない人もいます。そして、全員により効率的になってほしいんです。

ここで気づいたのは、優れたプログラマーは小さいPRを多く出す傾向にあります。

小さなPRであれば読むのも簡単で、マージの際に他のPRとの競合も起きにくく、不具合が含まれる可能性も低くなります。読みやすければ、その分チーム全体で協力しやすくなります。

この矢印は小さなPRが多いほど読みやすいということを表しています。コードが読みやすければ協力しやすくなります。

そしてマルのついた矢印は逆相関を意味しています。協力が増えると無駄が減ります。そして時間の無駄が減るほど、PRを作る時間が増えます。

いい仕組みですね。これは自己強化型、または正のフィードバックループです。回せば回すほど速く回せるようになります。

これがすべてではありませんが、ソフトウェア開発で起きていることの一部は説明できます。

今のところは順調ですね。"開発者の1日当たりのPRは多いほど良い"いいですね。

さて、この仕組みに圧力をかけてみます。PRが多いほど良いなら、どう増やすか?圧力をかけます。

ではランキング表を作りましょう。

PRの多いプログラマーを上位に置き、そして… 

うげっ。(顔をしかめて見せる)

PRの少ないプログラマーを下にします。そうやって圧力をかけるのです。多いほど良いのですから、これで数が増えて幸せになれるはず。ですよね?

全然、違います。

これはソフトウェア開発チームにとって終わりの始まりです。

物事を改善しようとして悪化させています。誰だって一番下になりたくはないですからね。

それなりに筋の通ったPRが準備できると、わざわざそれを小分けにして出すようになります。

1件のPRが4件になり、いきなり以前の4倍になりました。

でもPRを細切れにしたことで、読みにくくなり、協力が減り、無駄が増えれば、PR件数も減ることになります。

しまった。では今度は4つではなく10件に分けて出しましょう。

皆さんはバカではないから、同じことをするでしょう。

誰も下位にいたくないからです。

つまり、ソフトウェア開発プロセスを改善しようと圧力をかけた結果、事態を悪化させてしまったのです。

さて、長い間プログラマーをやっていると、同じことが何度も繰り返されるのを見ることになります。私はキャリアの中で、こういうプロセスの流れを何度も見てきました。

コードの行数がプログラマーの生産性を測る正しい指標だと言われた時代もあります。生産性を測る人たちが気づいていなかったのは、私たちがプログラマーだということです。

プログラムを書くプログラムも書けるんです。

私をコードの行数で評価するというなら、コンピューターと同じようなすごい速さでコードを量産できます。

でもそれは最終的に求めるものではなく、むしろ逆の結果になっています。仕組みを良くするために圧力をかけることで悪化させてしまったのです。

グッドハートはもっと悲観的に捉えるべきだった

このトークのタイトルは、"グッドハートの法則はもっと悲観的に捉えるべきだった"です。

彼の観察では、もし統計的な規則性があるならば…。例えば、"PRが多い開発者は効率的"というのが統計的な規則性です。

統計的規則性のある仕組みに圧力をかけると、規則性は崩壊するというのが彼の観察でした。

しかし実際は更に悪く、改善のため規則性に圧力をかけると、その規則性を生み出した仕組み自体を壊してしまうことになります。

ただレバーが緩んでしまうということではなく、レバーを引くことで、私たちの期待や意図とは真逆の結果になってしまいます。

だから、"もっと悲観的に捉えるべきだった"と言うのです。

規則性のある仕組みがあったとして、それを制御しようとしても、思ったようにはなりません。

PRのようなレバーを引くことで、意図した効果と逆の結果を得ることになってしまいます。なぜなら規則性を生み出した仕組み自体を壊してしまうからです。

指標にこだわりすぎる人たちは、この測定の問題を理解せず、こう言います。

"バランスの取れた複数の指標が必要だ"、"PR数だけでなく、欠陥の数も計測しよう"、"PRのレビュー時間も測ろう、それから…"。

これでは問題は解決しません。導入するすべての指標が仕組みをゆがめてしまいます。あなたが望まない方向にね。

仕組みをゆがめる指標が多ければ多いほど、その仕組みは理解しづらく制御しづらいものになっていくでしょう。

うまく開発するための指標のセットなんて存在しないんです。

意図はこうでしょう。

もし正しい指標のセットがあれば、"何も考えずに指標が改善するようにプログラムするだけで、すべてうまくいく"。

指標をどんどん導入するプロセスのゴールは、そこにあるように思えます。

それは私が望むものとは正反対です。プログラマーとして私はそんな風に扱われたくはない。考えることを後押ししてほしいし、自分の創造性に任せてほしい。

そしてこれらの思考と洞察と創造性のプロセスは、単純な数字に表せるものではありません。

(数値化しようとする)いかなる試みも、ソフトウェア開発に注ぎ込まれるべき思考、創造性、洞察を奪ってしまいます。

さて、先週このスライドを作りながら、私自身も楽観的すぎたと気づきました。システムは制御の圧力を軽減するために目標を放棄するだけでなく、ゆがんだ目標を採用してしまうのです。

例えば、"コード行数を増やす"、"PRを増やす"、"本番環境の障害を減らす"などの指標があります。

"障害を減らす"指標に注目します。本番環境での障害は避けたいですよね。そこで、"本番環境での障害をなくせ"と圧力をかければ、本番環境の障害報告はなくなるでしょう。

報告件数を減らす最も簡単な方法は、報告しないことだからです。

しかも相手は頭が良く創造的な人々ですから、数字をゼロにしろと言われれば、ゼロにする何らかの方法を見つけるでしょう。

これは仕組みをだましていると自覚するプログラマーにとって悪いことです。会社にとっても、顧客にとっても悪いことです。社会全体にとっても悪いことです。

これは人の働きを単純な数字で表そうとして、人間の判断を不要にして数字だけで制御しようとした結果です。

システムは目標を放棄するだけでなく、新しい目標を採用してしまいます。それは私たちが達成したい目標ではありません。これが指標に圧力をかけるということの本質です。

指標がどんなもので、いくつあって、どれだけバランスが取れていても関係ありません。

必要なのは、ここから抜け出す方法です。


後編に続きます

後編では、Beck氏が提唱する「価値の道すじ」の概念と、AI時代における測定の問題、そしてリーダーが実践すべき具体的なアプローチについて解説します。

後編はこちら tech.findy.co.jp


We're Hiring

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

herp.careers

生成AIが先?開発生産性が先?生成AI時代を走り抜けるための最初の一手

こんにちは。

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

現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。

GitHub Copilot や Claude Code など、生成AIを活用した開発支援ツールが次々と登場し、日常的なワークフローに組み込まれつつあります。

生成AIを開発フローやプロダクトに組み込んだ事例を耳にする機会も増えました。弊社も例に漏れず、多方面で生成AIを継続的に組み込んでいます。

一方で「思ったような効果が出なかった」「むしろ生産性が下がったのでやめた」「効果の出る使い方がわからなかった」といった声も確かに存在します。

生成AIを導入したものの、思っていたような結果が出なかったと感じるとき、原因は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