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

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

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

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

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

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

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

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

ファインディでソフトウェアエンジニアをやっている土屋です。今回は、先日大好評だった企画、「エンジニアの人生を変えたイベント」のPart2をお届けします。 tech.findy.co.jp 前回に引き続き、弊社エンジニア達が過去に参加したイベントの中で、特に印象に残っているイベントを紹介していきます。 それでは見ていきましょう！ YAPC (Yet Another Perl Conference) はじめての外部登壇 同世代エンジニアとの出会い キャリアの転機 まとめ HackBowl【次世代エンジニアの登竜門】 めぐろLT / TechBrew まとめ YAPC (Yet Another Perl Conference) CTO室データソリューションチームの土屋です。私はYAPC::Kyoto 2023とYAPC::Hiroshima 2024で人生が変わりました。 yapcjapan.org yapcjapan.org はじめての外部登壇 YAPC::Kyoto 2023では、初めて大きな舞台でLTに挑戦しました。イベントのトリとして全参加者の前に立つ緊張感は今でも鮮明に覚えています。 私は当時流行り出していた「ChatGPT」に自分の仕事で利用していた技術、「文字コード」を分析させる内容で登壇し、ベストLTをいただきました。 ChatGPTと文字コード.YAPC::Kyoto2023 LT.土屋俊介 (2023)) from stsuchiyabusiness さくらインターネットさんからいただいた賞状はいまでも家に飾っています。 このイベントを契機に、積極的に勉強会やカンファレンスで登壇するようになりました。外部登壇で培った伝える力は、職場での設計議論やプロジェクトの合意形成に貢献しています。 同世代エンジニアとの出会い また、このイベントを通じて知り合った仲間とは、今も一緒にコミュニティ活動を続けています。 「 若手ふんわり勉強会 」という若手エンジニア向け勉強会の運営をさせていただいているのですが、運営メンバーの @uutan1108 さん や @azukibar_D さん と出会ったのもこのイベントです。 同世代のエンジニアとのイベントは単に楽しみに留まらず、自分の実力を客観視する機会になっています。 キャリアの転機 YAPCは現職と関わるきっかけでもあります。YAPCのスポンサーとして来ていたファインディのチームと懇親会に行き親睦を深めました。和気藹々として楽しそうな会社だなと思ったのを今でも覚えています。また、当時の内定者に友人がいたので、CTOの佐藤さんと2ショットをtimesに送り驚かせたりしました (笑) その後、転職を考えはじめたときにファインディを想起し、ご縁があり就職しました。YAPCは私の人生を変えたと確信しています。 まとめ YAPCは私にとって、自分の可能性を広げ、新たな出会いとキャリアの転機を与えてくれる場所でした。そんな、YAPCは2025年11月14日、15日に福岡で開催されます。 blog.yapcjapan.org エンジニアとしての成長や仲間との出会い、人生を変えるきっかけが、そこにあります。カンファレンス初心者の方も、ぜひ一歩踏み出して参加してみてください!! HackBowl【次世代エンジニアの登竜門】 Findyの転職サービス を開発しているみっきーです。 大学2年生の時にHackBowlというTechTrainが主催するハッカソンイベントに参加しました。 このイベントがきっかけで、エンジニアとしてのキャリアの選択肢ができました。 prtimes.jp note.com 大学生の頃、エンジニアになるという目標があったわけではなく、ただ「みんなとご飯を食べにいく時間が楽しみ」という、ごくカジュアルな理由でプログラミングサークルに参加していました。 当時の私は、サークルに集まる情報系の学生や、Kaggle、AtCoderといった競技プログラミングで優秀な成績を収める先輩たちを見て、「そういった特別な人たちだけがエンジニアになれるのだ」と思い込んでいました。(私は情報系の学部の出身ではありません。) サークルに参加をし始めて、半年ほど経った頃にハッカソンへの誘いを受けました。 その時の誘い文句は、「人数合わせだから座っているだけでいい」「東京にも行けるよ(当時、大阪住み)」というものでした。 参加を迷っていましたが、メンターに相談できるハッカソンであり、初心者でも参加しやすそうだと感じたため、参加を決意しました。 結局、開発未経験の中で苦しい思いをしながら徹夜で開発に参加することにはなりましたが、ハッカソン後の懇親会で目の当たりにした光景が、私のエンジニアに対する固定観念を完全に打ち破りました。 様々なバックグラウンドを持つ学生たちが、楽しそうにエンジニアリングを語り合っていたのです。 この光景は、私にとって大きな刺激となり、「情報系の学生や競技プログラミングで優秀な人だけがエンジニアになれる」という、それまでの思い込みが完全に覆されました。 この時、心の底から「自分ももっと本気でやりたい！」という強い思いが芽生えました。 まさに、この瞬間が私の人生を変えるターニングポイントとなったのです。 このハッカソンでの経験が、私のエンジニアとしての道を本格的に歩み始めるきっかけとなりました。 また、学生時代に多くの出会いと助けを受け、支えられてきた経験から、「今度は自分がコミュニティに貢献したい」という気持ちが強く芽生えました。 サークルに所属して1年が経つ頃には、思いがけず代表を任されることになりました。 これを機に、学生向けハッカソンや勉強会の主催、エンジニアインターンへの挑戦など、本格的にエンジニアリングの道へと足を踏み入れました。 社会人になった今も、技術コミュニティへの関心は尽きません。 TechBull の運営に携わったり、Rubyコミュニティの活動に参加しています。 最近では、RubyKaigi 2024でLTに挑戦する機会をいただき、TechBullでも登壇させていただくなど、コミュニティに貢献しながら自身の技術を磨いています。 techbull.connpass.com 偶然の誘いから始まった1つのハッカソンが、私のエンジニアとしてのキャリア、そして人生観そのものを大きく変えました。 あの日の経験が、エンジニアリングへの情熱を燃やし、私自身の可能性を広げてくれたことに、深く感謝しています。 めぐろLT / TechBrew Findy Team+を開発している、おおいし（ @bicstone ）です。 私がエンジニアキャリアの転機として挙げたいイベントは、人生で初めて登壇した「 めぐろLT 」（2023年5月）と「 TechBrew 」（2023年6月）という2つのイベントです。 raksul.connpass.com findy.connpass.com これまでブログ執筆やイベントに参加する中で、登壇者の発表に刺激を受けるたび、いつしか「情報を受け取る側」から「情報を伝える側」へ回ってみたいという憧れを抱くようになりました。そして、思い切ってLT（ライトニングトーク）に挑戦したのがこの2つのイベントです。 当日は、業務で取り組んでいた チームでの合意形成を促す投票手法 について発表しました。 とはいえ、登壇には高いハードルを感じる方も多いかもしれません。私もその一人でした。もちろん、最初は「緊張せずにうまく話せるだろうか」「的外れなことを言って攻撃されないか」といった不安がつきまといます。 しかし、そんな心配とは裏腹に両コミュニティとも初心者や登壇者を温かく迎え入れてくれる雰囲気があり、運営の方や参加者の皆さんの温かい空気が、そういった不安を和らげてくれたのです。 TechBrewにて著者が登壇している様子（2023年6月） この初登壇での成功体験は、その後の継続的なアウトプットへの大きな自信と原動力になります。私自身、今では2ヶ月に1回以上のペースで登壇を続けており、 アウトプットを続けることのメリット を日々実感しています。あの時、勇気を出して一歩を踏み出した経験が、現在の活動の大きな糧となっています。 社外での登壇がもたらす最大のメリットは、全世界からフィードバックが得られることです。参加者としてイベントに参加するのとは異なり、発表に対してフィードバックや質問が寄せられます。これにより、チーム内だけでは得られない新たな視点に気づかされるのです。まさに、「発信した人のもとに、さらに質の高い情報が集まる」という好循環が生まれます。 この記事を読んで、少しでも学びを共有し成長したいと感じた方は、ぜひ身近なコミュニティのLTイベントに挑戦してみてください。きっと、温かい拍手で迎えてくれるはずです。 もし最初の一歩を踏み出す場所に迷ったら、私たち ファインディが開催しているイベント のLT公募登壇枠も、ぜひ選択肢に入れてみてください。挑戦するエンジニアを応援するこの場所で、皆さんの挑戦をお待ちしています。 まとめ いかがでしたでしょうか？ 3名とも初めての登壇が人生を変えたという共通点があり、最初の一歩を踏み出すことが大切なのだと改めて感じました。本記事が登壇の切っ掛けになれば幸いです。 そんな登壇者が集まるファインディでは一緒に働くメンバーを募集中です!! 詳細は次のリンクからご確認ください。 herp.careers

こんにちは。 ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 そのような状況の中で先日、Findy AI Meetupの記念すべき第1回を、2025年8月4日(月)に福岡にて開催致しました！ tech.findy.co.jp そのイベントで ファインディ株式会社における生成AI活用までの軌跡 と題しまして登壇しました。 そこで今回は、イベントに参加出来なかった方向けに、登壇資料をなぞりながら弊社が生成AIを活用できるようになるまでの道のりを紹介します。 ファインディの開発文化 生成AI活用のための事前準備 生成AI時代のファインディの開発現場 テックブログの壁打ち 小さいタスクはDevinにお任せ AI Agentで自律的かつ並列に開発 Model Context Protocol カスタムスラッシュコマンド まとめ ファインディの開発文化 まずは弊社の開発組織の文化を紹介します。 以前紹介したタスク分解。これは 弊社にJOINしてくれたエンジニアが最初に覚えるスキル です。 tech.findy.co.jp また、以前紹介したPull requestの粒度も重要です。適切な粒度でPull requestを作成することで、レビュワー、レビュイーの両者に対して優しいPull requestとなり、開発リズムを整えることが出来ます。 適切な粒度を知るためにも、タスク分解のスキルは必須となっています。 tech.findy.co.jp テストコードとCI/CDを整備することも重要です。 テストコードがあることで、実装コードを変更した際に、既存の振る舞いに影響がないことを保証することが出来ます。また、テストコードを読むことで、そのアプリケーションの正しい振る舞いを知ることが出来ます。 tech.findy.co.jp CI/CDは特に速度と自動化に拘っています。 Pull requestの粒度が比較的細かいため、作成数が多くなります。作成数が多い中でCIが遅い場合、CIの速度がボトルネックとなり、開発スピード全体が遅くなってしまいます。そこで弊社では、キャッシュや並列実行などを駆使してCIの高速化を図っています。 tech.findy.co.jp 統一されたコード規約と設計、ドキュメンテーションも重要です。弊社では「新しいメンバーがJOIN初日にPull requestを作成することが出来る」ということを目指してREADMEの整備を行っており、都度内容の見直しをしています。 このようにファインディの開発文化は、 開発に着手する前の事前準備を重要としている ことが分かるかと思います。 1つ1つはとても小さなことです。しかし、それらをこの5年間でしっかりとやり切ってきました。それらの積み重ねが開発組織の文化となっています。 僕もテックリードとなり、弊社の開発組織も5年前は10人も満たなかったのが、今では50人を超える規模となっています。 この規模になると、僕の目が行き届いていないチームも出てきています。 しかし、彼らは僕のいないところでも、今回紹介した 「開発に着手する前の準備」を怠っておらず、新メンバーに開発文化の継承を継続する ことが出来ています。 着実に積み重ねたものは強い ということを皆が証明してくれました。 生成AI活用のための事前準備 さて、ここからが本題ですが、ここまで読んでくださった読者のみなさんの中には既に勘付いている方もいるかと思います。 そうです。 ここまで紹介した内容はどれも、生成AIを活用するために必要なこと なのです！ タスク分解は生成AIに明示的に指示を出す時に特に重要 です。Issueやプロンプトに階層構造で明確なステップを記述することで、生成AIが理解しやすいタスクを作成できます。 適切な粒度のPull requestを生成AIに例として提示することで、 余計な内容を学習することなく同じような修正を任せる ことが出来ます。 テストコードとCI/CDは生成AI時代に重要度が更に増しています。 生成AIが修正内容の方向性を外れないためのガードレールとなるからです。 生成AIがコードを修正した後に、その内容が合っているのか、間違っているのかを生成AI自身が判断するための基準となる のです。 統一されたコード規約と設計、ドキュメンテーションは、生成AIがコンテキストを理解するうえで最も重要なリソースの1つです。これらの内容がバラついてしまうと、生成AIが正解を導くことが難しくなってしまいます。 ファインディではこれらのことを、生成AI活用が開発の現場に広まる前から取り組んでいました。 生成AIを開発に足したのではなく、生成AIが今までの開発フローに乗っかってきた。というイメージが近いかもしれません。 生成AIを活用するために新しく何かをした。ということではなく、 人が開発しやすくなるように整備を進めていた結果、生成AIフレンドリーな環境、文化になっていた ということです。 もちろん、全ての内容を完璧に整えられているわけではありません。まだ道半ばの箇所もあります。しかし、それらに対して 時間やコストを掛けて整備を進めることが当たり前という考えを、開発組織だけではなく経営陣含めて全社で共通認識として持っている ことが、弊社の文化だと言えるでしょう。 生成AI時代のファインディの開発現場 ここまでで、弊社が生成AIを活用出来ている理由を説明しました。 ここからは、実際にどんなシーンで活用しているかを紹介します。 テックブログの壁打ち 執筆やアウトプットの経験がないメンバーが、いきなりテックブログの記事を執筆するのはハードルが高いものです。 そこで弊社CTOが作ったのが壁打ちbotです。Slackのメッセージでbotとインタラクティブにやり取りして、執筆内容を壁打ちをしてくれます。 書きたい、伝えたい内容をbotと壁打ちしていくと、最終的にテックブログの記事の草案を出力してくれます。草案を元に記事を執筆できる環境を整えることで、テックブログの執筆に対するハードルを下げることに成功しました。 大事なこととして、AIで書かれた文章をそのままブログ記事にしてしまうと本人の持つ「味」が損なわれてしまいます。そのため、あくまで骨子を作ることまでに限定し、自分の手で書いてもらうことが望ましいです。 また、テックブログの記事を書き終わってタイトルに悩まされる経験をした読者の方もいると思います。そういったケースの場合、ChatGPTとタイトル案の壁打ちを行うこともあります。 この場合、生成AIに執筆内容を渡して、タイトル案を複数個出してもらうと良いです。 その中で気になるキーワードが出てきたら、そのキーワードを使うという条件を追加して新たにタイトル案を複数出してもらいます。この作業を繰り返すと、最終的に良い感じのタイトルが出てきます。テックブログの記事のタイトルに悩んだ時に試してみてください。 小さいタスクはDevinにお任せ 一括置換や軽微なリファクタといったタスクはDevinにお任せしています。 実際にDevinに依頼してPull requestを自動作成する仕組みを作ったことで、 個人のアウトプットが1.5倍 になったという実例もあります。 tech.findy.co.jp また、DevinでTerraformのコードを変更してPull requestを作成する仕組みも用意しています。 Slackのワークフローを用意して、Devinへの依頼を定型化します。そこからAWSのリソースへの権限追加や、構成変更などをDevinが自動でPull requestを作成します。 作成されたPull requestをSREチームがレビューし、問題なければmergeしてTerraformのapplyが実行されるようになっています。 Slackのワークフローを変更依頼のスタート地点としており、人間が介入するのはレビューとmergeのタイミングだけとなっています。このようにワークフローを定型化できる作業はDevinに任せています。 この話はまた別のタイミングで出来たらと思います。お楽しみに！ AI Agentで自律的かつ並列に開発 弊社では主にClaude Code ActionやGitHub Copilot Coding Agentを活用しています。 GitHubのIssueに要件とタスクを記載して、それをAI Agentに渡してPull requestの作成まで自動化しています。 そしてここでも タスク分解のスキルが大いに生きます。 AI Agentに依頼するタスクは明確なステップ階層で渡すと精度が上がります。 実際にClaude CodeやKiroが自身でタスクを出すときも、明確なステップ階層で出してきます。タスク分解に慣れていない方は、まずClaude CodeやKiroにタスクを出してもらい、そこから修正して正しいタスク出しを経験していくと良いと思います。 Model Context Protocol 弊社ではMCP(Model Context Protocol)の有用性に一早く気づき、検証を進めてきました。 tech.findy.co.jp tech.findy.co.jp MCPを内製で作成できるように環境を整備した他、業務効率化だけに留まらず、 新規プロダクトでの導入 も行っています。 後述にはなりますが、 次回開催するイベントで私がMCPをテーマに登壇する予定 です。福岡でのオフラインイベントになりますが、気になる方は是非ご参加ください。 カスタムスラッシュコマンド Claude Codeの機能で、頻繁に使うプロンプトを定義できます。 Nxのmigrateを自動で実行するものや、GitHubのIssueを取得して、タスク分解から実装、Pull requestまで自動化するものなど、多岐に渡って用意しています。 特に有用だと感じたのは、ローカル環境の環境構築を自動化するカスタムコマンドです。今まではREADMEの内容を元に各自実行して環境構築をしていましたが、カスタムコマンドで自動化することで、環境構築に対するハードルが落ちました。 次の例は、Pythonのプロジェクトの環境構築をするカスタムコマンドの例です。 # Local環境の環境構築 - brew install uv - mise install - brew install mkcert - mkcert -install - mkcert -cert-file localhost.pem -key-file localhost-key.pem localhost 0.0.0.0 - uv sync --frozen - cp .env.sample .env.local - docker compose up -d db mailpit - python -m alembic upgrade head - python -m pytest 今まではREADMEに環境構築の手順を書いていましたが、メンテナンスが行き届いていなかったり、意図しない場面で詰まることがありました。 ですが、Claude Codeのカスタムコマンドで環境構築することで、 意図しない場面で詰まっても、Claude Codeが原因を突き止めて、軌道修正しながら環境構築を完了する ことが出来ます。 まとめ いかがでしたでしょうか？ 長年の小さな改善の積み重ねが、現在の開発組織の文化を作りあげました。 その結果、生成AIと自然に協働できる AIフレンドリーな組織文化 となっていたのです。 生成AIとの協働は1日にして成らず。 事前準備や環境、ガードレールの整備など、 小さな積み重ねを続けることが重要 です。 人が開発しやすくすることは、結果的に生成AIのガードレール整備に繋がる のです。 生成AIを使ってみたけど、思っていた結果が出ないと感じているのであれば、まずは目の前の小さなことや、足元の整理に着手することをオススメします。 登壇資料の方も是非ご覧になってください。 最後になりますが、このたび 2025年9月8日(月)にFindy AI Meetup in Fukuoka #2の開催が決定 しました！ findy-inc.connpass.com 会場へのアクセスは天神駅から徒歩3分となっています。また、TVCM公開記念ノベルティや、イベント後半には懇親タイムもご用意しています。 僕も運営、登壇者として参加予定です。是非イベントに足を運んでいただき、懇親会でAI談義に花を咲かせましょう。 申込みの先着順となっておりますので、気になっている方は早めにお申し込みいただくことをおすすめします。生成AIの活用事例に興味のある方は奮ってご参加ください！ みなさんにお会いできることを楽しみにしています！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

はじめに こんにちは。CTO室 Platform開発チーム SREの原( @kouzyunJa )です。 ファインディでは日々サービスが爆速で開発されており、新しいプロダクトも次々と生まれています。それらのインフラ構築を、私たちのチームが支えています。 インフラ構築にもスピード感が求められるため、効率的かつ安全に進める仕組みが欠かせません。 今回は、そのスピード感あるインフラ構築を支えるTerraform Testの取り組みについてご紹介します。 はじめに Terraform Testの導入背景 Terraform Testの書き方紹介 UnitテストとIntegrationテスト ディレクトリ構成 mock providorとUnitテスト 複数モジュールを組み合わせたIntegrationテスト CIワークフローでの活用 まとめ Terraform Testの導入背景 developer.hashicorp.com Terraform TestはTerraform 公式のテストフレームワークで、Terraform v1.6.0から利用可能です。 モジュール更新による破壊的変更を事前に検証でき、テストは新規にリソースが構築され、その後自動的に削除されます。既存のインフラ環境やstateへの影響はありません。 弊社ではIaCとしてTerraformを導入しており、HCP Terraformにてstateの情報を管理しています。 スピード感のあるインフラ構築を実現するため、ファインディのプロダクトでよく利用するリソースをモジュール化しています。 これらのモジュールを、私たちは「汎用モジュール」と呼んでいます。 AWSの新規インフラ環境構築時にはこの汎用モジュールを活用する取り組みを推進しています。 しかし、汎用モジュールから環境を構築する際にTerraform Planは通るものの、Terraform Applyで失敗するケースがあり、その結果、構築スピードが低下するという課題がありました。 この課題を解決するため、Terraform Testを導入しました。 Terraform Testの書き方紹介 Terraform Test は専用のテストファイルに記述します。 .tftest.hcl または .tftest.json の拡張子のファイルにテストコードを記載していきます。 イメージが付きやすいように、S3バケットを構築するシンプルな例を使って説明します。 # main.tf provider " aws " { region = " ap-northeast-1 " } variable " bucket_prefix " { type = string } resource " aws_s3_bucket " " example " { bucket = " ${var.bucket_prefix}-bucket " } このS3バケットの名前が想定通りで構築されているかのテストを書いてみますと次のようになります。 # main.tftest.hcl variables { bucket_prefix = " test " } run " valid_string_concat " { command = plan assert { condition = aws_s3_bucket.bucket.bucket == " test-bucket " error_message = " S3 bucket name did not match expected " } } runブロック内でテストを記述しており、assertで条件式を定義し、期待する値と一致するかを検証します。 このように作成するリソースの値が正常に設定されているかを確認できます。 UnitテストとIntegrationテスト ファインディではTerraform Testにおいて、独自にUnitテストとIntegrationテストの2種類のテストカテゴリを設けています。 Unitテスト: Terraform Planに相当し、リソースを作らず論理的に検証する Integrationテスト: 実際にリソースをApplyして作成し検証、その後は自動的にリソースのDestroy行われる この2つを組み合わせることで、インフラ環境のテストを行っています。 使い分けはrunブロック内のcommandの指定によって決まります。 command = plan を指定すればUnitテストを実行する command = apply を指定すればIntegrationテストを実行する よって、さきほどの例は command = plan を指定しているのでunitテストとしています。Integrationテストでも、assertでの値の確認は同様に行うことができます。 ディレクトリ構成 テストのコードは、各モジュール配下のtestsディレクトリに配置しています。 UnitテストとIntegrationテストをディレクトリで分けており、対象のテストだけを個別に実行できます。 # Terraform モジュール と テスト構成例 modules/ <module-name>/ ├── main.tf ├── variables.tf ├── outputs.tf └── tests/ ├── unit/ │ └── main.tftest.hcl └── integration/ └── main.tftest.hcl テストを実施したい場合は、 terraform test コマンドを使用します。 また、 -test-directory オプションを指定することで、Unitテスト用のディレクトリや Integrationテスト用のディレクトリを切り替えて実行できます。 $ terraform test -test-directory=./tests/unit 実行結果は次のように表示されます。 runブロックごとにテスト名と結果が表示され、成功(pass)か失敗(fail)かを確認できます。 tests/unit/main.tftest.hcl... in progress run "test1"... pass run "test2"... pass run "test3"... pass run "test4"... pass run "test5"... pass tests/unit/main.tftest.hcl... tearing down tests/unit/main.tftest.hcl... pass Success! 5 passed, 0 failed mock providorとUnitテスト Unitテストではcommand = planを利用して実リソースを作らず論理的に検証します。 テストを行うモジュールの外部にあるリソース情報(例: 既存のIAM RoleのARNや、外モジュールのS3バケットのARN)を参照する場合、 mock providerを活用すると、外部リソースを実際に参照せずにテストを実行できます。 # main.tftest.hcl mock_provider " aws " { mock_data " aws_iam_role " { defaults = { arn = " arn:aws:iam::111122223333:role/mock-role " } } } run " check_role_arn " { command = plan assert { condition = data.aws_iam_role.example.arn == " arn:aws:iam::111122223333:role/mock-role " error_message = " IAM Role ARN does not match expected value " } } このようにmock providorを活用することで、モジュール外部のリソースを実際に参照せずともUnitテストを行うことができます。 複数モジュールを組み合わせたIntegrationテスト ファインディでは汎用モジュールを「Network」「Container」など機能単位でモジュールを分けて作成しています。 このため、例えばContainerモジュールを単体でIntegrationテストしようとしても、Networkモジュールで作成しているVPCやSubnetが存在しないためApplyに失敗します。 そこで依存するNetworkモジュールを先にApply → その出力値をContainerモジュールに渡す、という流れを取り入れました。 これにより、依存関係を含めた最小構成を再現しながら Integrationテストを実行できます。 # main.tftest.hcl run " network_module_apply " { command = apply # Call the Network module module { source = " ./../../../network " } variables { vpc_cidr_block = " XX.XX.XX.XX/XX " subnet_public_1a_cidr_block = " XX.XX.XX.XX/XX " subnet_public_1c_cidr_block = " XX.XX.XX.XX/XX " subnet_public_1d_cidr_block = " XX.XX.XX.XX/XX " subnet_private_1a_cidr_block = " XX.XX.XX.XX/XX " subnet_private_1c_cidr_block = " XX.XX.XX.XX/XX " subnet_private_1d_cidr_block = " XX.XX.XX.XX/XX " } } run " container_module_apply " { command = apply # Call the container module module { source = " ./../../../container " } variables { vpc_id = run.network_module_apply.vpc_id private_subnets = [ run.network_module_apply.subnet_private_1a_id, run.network_module_apply.subnet_private_1c_id, run.network_module_apply.subnet_private_1d_id ] public_subnets = [ run.network_module_apply.subnet_public_1a_id, run.network_module_apply.subnet_public_1c_id, run.network_module_apply.subnet_public_1d_id ] } } CIワークフローでの活用 ここからはGitHub ActionsのCIに組み込んだTerraform Test活用方法について紹介します。 Terraform TestはCI ワークフローに組み込んで自動実行しています。 CIに組み込む際のポイントとしてUnitテストとIntegrationテストは使い分けています。 Unitテスト: PR作成時に実行 Integrationテスト: Mainブランチへマージ後、HCP Terraformへリリースする前に実行 使い分けている理由として、Integrationテストはリソースの構築から削除までを伴うため、完了まで時間がかかります。 例えばAuroraの場合、構築から削除完了まで長時間のテストを待つ必要があり、PRのレビュー速度に影響するため、マージ後に実行する設計としています。 Unitテストは論理的に検証するため、PR作成時に実行してスピーディーな確認ができます。 サンプルコードは次のようになります。 name: PR - Terraform Test (Unit) on: pull_request: paths: - "**.tf" - "**.hcl" jobs: unit-tests: runs-on: ubuntu-XX.XX steps: - name: Checkout uses: actions/checkout@v4 - name: Setup Terraform uses: hashicorp/setup-terraform@v3 with: terraform_version: X.XX - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: aws-region: ap-northeast-1 role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }} role-duration-seconds: 1200 - name: Terraform init run: terraform init - name: Terraform validate run: terraform validate -no-color - name: Terraform test (unit) run: terraform test -test-directory=tests/unit PRのUnitテストで問題ないと判断したら、mainブランチへマージを行いIntegrationテストを実行します。 AWSのSandbox環境で apply → assert → destroy を行い、リソースがApplyに失敗せず正しく作成できるかを検証します。 Integrationテストがパスされれば汎用モジュールのstateを管理しているHCP Terraformへリリースされます。 サンプルコードはこちらになりますが、ほとんどUnitテストと変わりません。 name: Release - Terraform Test (Integration) on: push: branches: - main jobs: integration-tests: runs-on: ubuntu-XX.XX steps: - name: Checkout uses: actions/checkout@v4 - name: Setup Terraform uses: hashicorp/setup-terraform@v3 with: terraform_version: X.XX - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: aws-region: ap-northeast-1 role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }} role-duration-seconds: 1200 - name: Terraform init run: terraform init - name: Terraform validate run: terraform validate -no-color - name: Terraform test (integration) run: terraform test -test-directory=tests/integration このようにCIのワークフローにTerraform Testを組み込むことで、PR時にUnitテストで素早いフィードバックを得られ、マージ後にはIntegrationテストで実際の構築検証を行うという二段構えが実現できました。 結果として、より信頼性の高い汎用モジュールを安全に開発できるようになっています。 まとめ 以上がTerraform TestとCIワークフローへの組み込みの紹介となります。 テストを汎用モジュールに組み込むことで、事前にApply失敗を検知できる仕組みを整え、信頼性を高めつつスピード感のあるインフラ構築を進められるようになりました。 一方で、Integration TestはSandbox環境に実際のリソースを構築するため実行時間が長くなるという課題もあります。今後はテストスピードの改善や効率化の仕組みを検討していく予定です。 皆さんのTerraform活用のヒントになれば幸いです。 ファインディでは一緒に会社を盛り上げてくれるSREメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 そのような状況の中で先日、Findy AI Meetupの記念すべき第1回を、2025年8月4日(月)に福岡にて開催致しました！ tech.findy.co.jp イベント終了後には参加者の皆さんにアンケートを回答いただき、運営メンバー全員で全ての回答に目を通しました。 どの回答からもイベントを楽しんで頂けたこと、そして学びのきっかけを届けることが出来たことが伝わってきました。参加者の皆様、改めてお礼申し上げます。ありがとうございました。 Findy AI Meetup in Fukuoka #2 開催決定！ Findy AI Meetupとは？ 登壇予定 実践！カスタムインストラクション＆スラッシュコマンド ファインディ株式会社におけるMCP活用とサービス開発 まとめ Findy AI Meetup in Fukuoka #2 開催決定！ 前回開催から日は浅いですが、皆さんの熱量の高さに触れ、このたび2025年9月8日(月)にFindy AI Meetup in Fukuoka #2の開催が決定しました！ findy-inc.connpass.com そこで今回は、イベント開催の告知と、予定している内容を紹介したいと思います。 Findy AI Meetupとは？ ファインディ株式会社のエンジニアが主催する技術系のオフラインイベントです。 ファインディ株式会社では、生成AIやAIエージェントの活用を通じて開発生産性の向上を目指す取り組みを行っています。このイベントでは、ファインディのエンジニアが社内での実践事例を紹介するとともに、エンジニア同士がつながり、知見の共有や交流を目的としています。 今回は前回の開催から1ヶ月という短いスパンでの開催とはなりますが、皆さんの熱量のおかげで2回目の開催がすぐに決定しました！本当にありがとうございます！ 登壇予定 実践！カスタムインストラクション＆スラッシュコマンド GitHub CopilotやClaude等のAIツールを用いたソフトウェア開発は、今や当たり前のものとなっています。 この発表では、ファインディで用いられているカスタムインストラクションやスラッシュコマンドについて紹介します。 tech.findy.co.jp tech.findy.co.jp スラッシュコマンドについては、以前のテックブログで取り上げられたものの他にも、 Gitリポジトリの掃除 Claude Codeの通知設定 Nxのマイグレーション実行 といったものを紹介する予定です。 また、ツールの整備を通して得られた、コーディングスタイルと生成AIとの関係についても共有できればと思います。 ファインディ株式会社におけるMCP活用とサービス開発 「ファインディ株式会社におけるMCP活用とサービス開発」と題しまして、弊社のMCP活用の実例をいくつか紹介します。 まずMCP(Model Context Protocol)と、それを使った弊社のサービスについて紹介します。 tech.findy.co.jp tech.findy.co.jp 次に、MCPを日々の開発にどのように入れ込んでいるのか、弊社の事例をいくつか紹介します。 MCPとは何なのか？そして具体的にどう活用すればいいのかヒントを得たい方に是非聞いていただきたいセッションとなっています。 まとめ いかがでしたでしょうか？ 会場へのアクセスは天神駅から徒歩3分となっています。また、TVCM公開記念ノベルティや、イベント後半には懇親タイムもご用意しています。 申込みの先着順となっておりますので、気になっている方は早めにお申し込みいただくことをおすすめします。生成AIの活用事例に興味のある方は奮ってご参加ください！ イベント参加申し込みはこちらから ↓ findy-inc.connpass.com みなさんにお会いできることを楽しみにしています！

こんにちは！ファインディのTeam+開発部でEMをしている奥村です。 チームや組織が大きくなるにつれ、横の繋がりが薄くなった気がする…そんな課題を感じたことはありませんか？ 私たちファインディのTeam+開発部は多くのメンバーを迎え入れながら拡大を続けています。 現在26名（業務委託除く、正社員のみ）が所属しており、そのうちここ一年でジョインしたメンバーが11名にのぼります。 一方で横軸のコミュニティ構築とメンバーの主体性の促進が組織の課題として挙がっていました。 そこでOpen Space Technology（以下OST）というワークショップを実施したので、今回はワークショップの紹介と実施レポートを報告します。 なぜOST？ まず前提として私たちは、Team+開発部を 「チーム横断での協働・協力等の相互支援を活性化し、Findy Team+開発のあるべきを主体的に思い描き、建設的な議論を行いながら自走できる組織」 にしたいと考えています。 冒頭で述べた通り、私たちTeam+開発部は多くのメンバーを迎え入れて拡大をしています。 人数増加に伴いチームも6チームに分かれていますが、正直なところ、 かつてのような横軸のつながりが薄くなってきている と感じています。 また、組織課題に触れる機会も断片的・限定的になりがちで、他のチームの状況や各メンバーがどんなことを考えているのかを知る機会が減ってきています。 何かしら課題を感じても「周囲の考えが分からない」「どんな活動が進められているか見えない」といった具合に主体的な行動が抑制されかねないと感じています。 実際、属人化や対応偏り、知見や活動の共有の不足などを聞くこともありました。 そこで、次のような目的を持ってOSTを実施することにしました。 横軸のコミュニティを再構築し、課題解決に向けた協働文化や成長の相互支援を活性化する Team+開発の未来のあるべきを主体的に思い描き、建設的な議論を行いながら自走できる組織にする もう少し具体的に言うと、次の狙いです。 信頼関係・相互理解：チームを超えた交流の促進 自己組織化：主体的にあるべき姿を考える文化の醸成 自立性：自立して学び、行動する文化の促進 OSTってなに？ 「OST」というワークショップをご存知でしょうか？ OSTは、参加者が自分で「これを話したい！」というテーマを持ち寄って、自由に議論するスタイルのワークショップです。 セッションテーマの提案からタイムテーブルの作成、セッションの進行までを参加者自身が主体的に行うことが特徴です。 セッションテーマは誰でも提案可能で、アジェンダもその場で決まります。 参加するセッションも参加者が自身の興味関心に合わせて自由に選べます。また、セッションの途中で他のセッションへの移動も可能です。 「対話」をメインの目的としており、明確なネクストアクションを決めるようなことはありません。 対話を通して、テーマに対する理解の深化や知見の共有、アイデア創出など行うワークショップになります。 OSTには"4つの原則"があります。これらの原則は参加者の主体性を促すOSTの鍵となります。 ここにやってきた人は、誰もが適任者である 何が起ころうと、それが起こるべき唯一のことである いつ始まろうと、始まった時が適切なときである いつ終わろうと、終わった時が終わりのときである なお、他にも"蝶と蜂"や"移動性の法則"といった特徴がありますが、私たちの人数規模では詳細に説明する必要がないと判断して省略をしました。 似たワークショップにワールドカフェがあります。 ワールドカフェは設定されたテーマに対してメンバーを変えながら議論を深めていきます。 これに対して、OSTはテーマが複数並行して進行し、参加者が自由に選べる点で異なります。 当日の流れ 全体タイムテーブル 10:00 ~ 10:15: 準備 10:15 ~ 10:30 アイスブレイク 10:30 ~ 11:00 概要説明、タイムテーブル作成 11:00 ~ 15:00 セッション 11:00 ~ 11:40 セッション① 11:50 ~ 12:30 セッション② 12:30 ~ 13:30 お昼（お弁当） 13:30 ~ 14:10 セッション③ 14:20 ~ 15:00 セッション④ 15:00 ~ 15:10 クロージング、片付け 弊社オフィス内のイベントスペースで実施をし、フルリモートのメンバーもオフィスに集まってもらい23名が参加をしました。 アイスブレイクでは、テーブルごとに他己紹介を行なってもらい、各メンバーのパーソナルな部分を知る時間を設けました。 フルリモートのメンバーやチーム外のメンバーの意外な一面を知り、本題のセッションに入る前の心理的なハードルを下げることができたと思います。 各セッションは40分+10分のバッファで設定していました。 セッションタイムテーブル 大枠のテーマとして 「Team+の今後を考えるとき今話したいこと」 を置いて、各セッションのテーマはその場で各メンバーから自由に提案してもらいました。 念の為、テーマが挙がらなければマネージャー陣がファーストペンギンに…と裏で話していましたが、 全くの杞憂でした。 AIの話から、開発の進め方、品質、コミュニケーションなどなど、様々なテーマが挙がりました。 重複するものはマージし、類似するテーマは別時間にズラすなどの調整をして、最終的にはこのようなタイムテーブルとなりました。 セッション一部紹介 実際のセッションを一部紹介します。 ・チームを超えた交流の方法について ・どうやって考えている？（プロセス・手法） やってみてどうだったか？ 実施後アンケートから、非常にポジティブな結果が得られました。 対話と発散を意図していたため業務への活用はあまり期待していませんでしたが、「ある程度活用できる」が60%、「積極的に活用できる」が40%と、全員が何かしらの活用を考えることができたようです。 実際に、OST実施後に改善へ向けたアクションを起こしたメンバーもいました。 自由記入の感想では次のような回答がありました。 なかなか話す機会ないトピックについて話ができた チーム外のメンバーがどう課題感を持っているか、どういう考えを持っているのかを広く知れる機会になった 普段感じている課題感や難しさを共有できた マネージャーからメンバーまで、役職関係なくさまざまな視点からの意見が聞けた 今回のOSTを通して、各メンバーが何かしらに興味関心を持ち、何かしらに課題感を持っていることを再確認できました。 また、それらを発散・共有するだけでも組織の一員としての意識が高まることを実感しました。 目的が達成されたのかは今後のアクション次第ではありますが、少なくとも重要で大きな一歩目を踏み出せたと感じています。 コミュニケーションにおいても、普段フルリモートのメンバーやチーム外のメンバーなど幅広く交流ができ、通常の業務で会話する際のハードルを下げられたと考えられます。 次回以降の改善点として、他セッションでの議論を知る時間を設けることやエンジニア以外のメンバーを巻き込むことなどを考えています。 まとめ Team+開発にとってははじめてのOSTでしたが、単なる交流会ではなく、 組織を強くするための大きな一歩になったと確信しています。 交流を深められた・課題感を共有できた・アイデアを出し合えた等ポジティブな感想が多く、実施後に多くのメンバーから「定期的にやってください」と直接言われるほどでした。 反省点もあるものの、それを活かして今後も引き続き、組織の強化・文化の醸成に向き合っていきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。Findy Tech Blog編集長の高橋（ @Taka-bow ）です。 前回の記事 では、全体の44.3%が開発生産性に前向きという結果をご紹介しました。今回は開発手法別に深掘りすると、予想外の事実が浮かび上がってきました。 開発生産性への印象は多様 ── 約半数が中立的立場も抵抗感は少数派 意外な結果 ── アジャイル実践者の59.6%が開発生産性に前向き なぜアジャイル実践者は開発生産性に前向きなのか アジャイルの価値観と生産性改善の親和性 Kent Beck氏が語る測定の本質 ── 「測定が目標になると、システムは歪む」 アジャイル実践者の「前向きさ」に潜む3つの勘違い 何を測るべきか ── Kent Beck氏が示す価値創造の道筋 測定を「コントロール」ではなく「認識」のツールとして ── Kent Beck氏の4つの提言 次回予告 【調査概要】 調査対象： ソフトウェア開発（組み込み開発を含む）に直接関わるエンジニア、プロダクトマネージャー、プロジェクトマネージャー、エンジニアリングマネージャー、開発責任者など 調査方法： インターネット調査 調査期間： 2025年4月2日(水)～2025年5月21日(水) 調査主体： ファインディ株式会社 実査委託先： GMOリサーチ&AI株式会社 有効回答数： 798名（95%信頼区間±3.5%） 統計的検定力： 80%以上（中程度の効果量d=0.5を検出） 調査内容： 開発生産性に対する認識 開発生産性に関する指標の活用状況 開発生産性に関する取り組み 開発環境・プロセス評価 組織文化と生産性 開発生産性への印象は多様 ── 約半数が中立的立場も抵抗感は少数派 あらためて、「開発生産性」という言葉に対する印象を見てみましょう。 開発生産性への印象に関する回答分布 選択肢 回答者数 割合 詳細内訳 どちらでもない 384人 48.1% – ポジティブ 354人 44.3% とてもポジティブ + どちらかというとポジティブ ネガティブ 61人 7.6% とてもネガティブ + どちらかというとネガティブ 合計 798人 100.0% – 「開発生産性」という言葉に対してネガティブな印象を持つ人は わずか7.6% （61人）。一方で、 44.3%がポジティブ （354人）な印象を持っており、 約半数（48.1%）が中立的 （384人）な立場を取っています。 この結果から、多くのエンジニアが生産性向上に対して前向き、あるいは少なくとも抵抗感を持っていないことが分かります。これは、日本の開発現場が変化を受け入れる準備ができていることを示唆しています。 意外な結果 ── アジャイル実践者の59.6%が開発生産性に前向き 私がこれまで出会ったアジャイルコーチの多くは、口を揃えて「生産性は測れない」「生産性に意味はない」と言っていました。そのため、アジャイル実践者ほど開発生産性という概念に抵抗を示すのではないかと予想していました。 しかし、調査結果は意外でした。 開発手法別の開発生産性に対するポジティブ印象の比較 フレームワーク 対象者数 ポジティブ印象者数 ポジティブ率 アジャイル系 245名 146名 59.6% ウォーターフォール 294名 116名 39.5% 差 – – 20.1ポイント アジャイル実践者の約6割（59.6%）が開発生産性に前向きという結果は、ウォーターフォール開発者（39.5%）と比べて20.1ポイントも高い数値でした。 さらに、実際の取り組み状況を見てみましょう。 開発手法別の開発生産性向上への取り組み状況の比較 フレームワーク 対象者数 取り組み実施者数 取り組み率 アジャイル系 245名 117名 47.8% ウォーターフォール 294名 105名 35.7% 差 – – 12.1ポイント アジャイル系では47.8%が実際に取り組みを実施しているのに対し、ウォーターフォールでは35.7%にとどまっています。しかし、ポジティブ印象の差（20.1ポイント）に比べて、実際の取り組み率の差（12.1ポイント）は小さいことが分かります。 つまり、アジャイル実践者は「開発生産性」に対して前向きな印象を持っているものの、実際の取り組みに落とし込めていない人が多いということです。ポジティブな印象を持つ59.6%のうち、実際に取り組んでいるのは47.8%。この差は何を意味するのでしょうか？ 前回の記事で指摘した「測定指標の混乱」を考慮すると、このギャップの原因が見えてきます。実際、組織が重視する指標は千差万別です。 コード行数、バグ数、残業時間、機能数、ストーリーポイント──組織によって測定する指標はバラバラで、業界全体で「何を測るべきか」の共通認識が欠けています。DORA指標（デプロイ頻度、リードタイム、MTTR、変更失敗率）の認知度がわずか4.3%という事実も、この混乱を裏付けています。 アジャイル実践者の多くは開発生産性の重要性は理解しているものの、「何を測るべきか」「どう測るべきか」が分からず、結果として行動に移せていない可能性があるのです。 なぜアジャイル実践者は開発生産性に前向きなのか アジャイルの価値観と生産性改善の親和性 なぜアジャイル実践者の方が前向きなのでしょうか。私の経験から考えると、アジャイルの実践と生産性改善の考え方には、次のような共通点があるのかもしれません。 1. 継続的な改善が文化として根付いている スプリントやイテレーション（短期間の開発サイクル）ごとにレトロスペクティブで定期的に振り返り、改善を繰り返す。この習慣により、「生産性を向上させる」という考え方が自然に受け入れられています。 2. 測定と可視化が日常的な実践 ベロシティ、バーンダウンチャート、イテレーション完了率など、アジャイルチームは様々な指標を日常的に活用しています。そのため、「測定する」ことへの心理的抵抗が少ない。 3. 変化への適応力 「変化を歓迎する」というアジャイルの原則により、開発生産性という概念も「改善の機会」として前向きに捉えられます。 4. チームの自律性と当事者意識 アジャイルでは、チームが自ら課題を発見し解決策を考えます。開発生産性も「上から押し付けられる」ものではなく、「自分たちが主体的に改善する」ものとして受け止められています。 Kent Beck氏が語る測定の本質 ── 「測定が目標になると、システムは歪む」 しかし、アジャイル実践者の59.6%が前向きだという事実は、彼らが「正しく」生産性を理解していることを意味するのでしょうか？ 実は、この問題について、アジャイル界のレジェンドであるKent Beck氏が重要な示唆を与えています。19年ぶりに来日し、開発生産性Conference 2025で登壇した彼は、測定と生産性の本質的な問題について警鐘を鳴らしました。 Kent Beck 氏（開発生産性Conference 2025にて） Kent Beck氏は「グッドハートの法則」を引用しながら、こう語りました。 "When a measure becomes a target, it ceases to be a good measure. If we exert pressure on that system, the regularity will disappear. It's worse than that. If we exert pressure on that regularity to make things better, we will destroy the system that created that regularity in the first place." 「測定が目標になると、それは良い測定ではなくなります。システムにプレッシャーをかけると、規則性は消えます。それよりも悪いことに、物事を良くするためにその規則性にプレッシャーをかけると、最初にその規則性を作り出したシステムを破壊してしまうのです」 プルリクエストの例を挙げて、具体的に説明しています。 "I'm going to take my pull request that made some sense and I'm just going to slice it up. Their less readable leads to less cooperation leads to more waste leads to fewer pull requests. So by applying pressure to the software development process to make it better, we have made it worse." 「理にかなった1つのプルリクエストを細かく分割します。読みにくくなり、協力が減り、無駄が増え、プルリクエストが減ります。ソフトウェア開発プロセスにプレッシャーをかけて改善しようとすることで、悪化させてしまったのです」 このような単一メトリクスの問題に対して、「では複数のメトリクスでバランスを取ればよいのでは？」という反論が予想されます。Kent Beck氏は、この点についても次のように警告しています。 "People say well you need a balanced set of metrics. That doesn't solve the problem. Every metric that you introduce is going to distort the system that you're working in in ways that aren't what you want it to be." 「『バランスの取れたメトリクスのセットが必要だ』と言う人もいます。しかし、それでは問題は解決しません。導入するすべてのメトリクスは、望ましくない方法で作業しているシステムを歪めます」 つまり、メトリクスを増やしても、歪みが複雑化するだけで根本的な解決にはならないということです。これは、日本の組織でよく見られる「各チームが異なるKPIを追求する」状況と重なります。 ただし、Kent Beck氏自身も 「測定自体は極めて価値がある」 と強調しています。 "I've been measuring my own software development process as long as I've been developing and I find it extremely valuable to turn what I'm doing into numbers that I can analyze and interpret." 「私は開発している限り、自分のソフトウェア開発プロセスを測定してきました。私がしていることを分析し解釈できる数字に変えることは非常に価値があると思います」 つまり、問題は測定そのものではなく、 何を測るか と どう使うか なのです。 アジャイル実践者の「前向きさ」に潜む3つの勘違い Kent Beck氏の警告を踏まえると、アジャイル実践者の「前向きさ」には次のような勘違いが潜んでいる可能性があります。 1. ベロシティ＝生産性という誤解 ベロシティが上がると「生産性が向上した」と感じてしまいがちです。しかし、ベロシティはあくまでもチーム内での前イテレーションとの相対比較でしかなく、チーム間の比較や組織全体の生産性を示す指標ではありません。さらに、ストーリーポイントのインフレーション（見積もりの甘さ）や、価値の低いタスクの量産でも数字は上がります。Kent Beck氏が指摘するように、これはまさに「測定が目標になった」状態です。 2. プロセスの遵守をアウトカムと混同 アジャイルの「儀式」を正しく実行していることと、実際に価値を生み出していることは別物です。毎日スタンドアップをやり、レトロスペクティブを欠かさず、バーンダウンチャートが美しい右肩下がりを描いていても、それは「プロセスを守っている」だけかもしれません。顧客が本当に必要としている機能を届けているか、ビジネスアウトカムにつながっているか、技術的負債を積み上げていないか──これらの本質的な問いを忘れ、「アジャイルをちゃんとやっている」ことに満足してしまうリスクがあります。 3. 複数メトリクスの罠 ── なぜ全体最適が失われるのか 日本の組織では、各チームが自分たちの領域で完璧を追求する傾向があります。開発チームはベロシティを上げ、QAチームはバグ検出率を誇り、運用チームは安定性を守る。それぞれが「うちのチームは生産性が高い」と思っています。しかし、これはまさにKent Beck氏が警告する「バランスの取れたメトリクス」の問題です。各チームが異なるメトリクスを最適化することで、システム全体に複雑な歪みが生じます。開発が早くても、QAで長時間滞留し、運用への引き渡しで調整に時間がかかり、結局顧客に価値が届くまでのリードタイムは改善されない。 Kent Beck氏が指摘するように、「システムを歪めるメトリクスが多いほど、理解しにくく影響を与えにくくなる」のです。各チームの「優秀さ」が、かえって全体のボトルネックを見えなくし、誰も全体像を把握できない状況を生み出しています。 つまり、アジャイル実践者が「前向き」なのは、 自分たちの測定方法や改善活動が正しいと信じているから かもしれないのです。 何を測るべきか ── Kent Beck氏が示す価値創造の道筋 本調査から明らかになったのは、どの開発手法でも「何を測るべきか」の共通認識が欠けていることです。この根本的な問題について、Kent Beck氏は価値創造の道筋を次のように説明しています。 Kent Beck 氏（開発生産性Conference 2025にて） "We start out with effort... That's effort. We can measure it in time... Now we have some output... But we still haven't created value until the customer does something, behaves in some new kind of way... And finally the value that we created... comes back to the company in terms of increase in revenue, increase in customer satisfaction." (*下図を示しながら)「まず努力（Effort）から始まります。これを時間で測定できます。次に何らかの成果物（Output）が生まれます。しかし、顧客が新しい行動を取るアウトカム（Outcome）が生まれるまでは、まだ価値は生まれていません。そして最終的に、創出された価値が収益増加や顧客満足度向上という影響（Impact）として会社に還元されます。」 Kent Beck 氏のプレゼン資料から引用 (p.8) そして、この価値の道筋における測定の難しさと歪みの関係について、次のように述べています。 "The further over here we are towards effort the easier things are to measure. But also the more likely that measurement is to distort the system... The further over here you are... the harder it is to attribute value to any one person or one team but the less prone that measurement is to distorting the system." 「投入した努力（作業時間など）に近い指標ほど測定は容易ですが、同時にその測定がシステムを歪めるリスクも高まります。一方、創出された価値（ビジネスアウトカム）に近い指標ほど、そのアウトカムを特定の個人やチームに帰属させることは困難になりますが、測定によるシステムの歪みは生じにくくなります」 測定を「コントロール」ではなく「認識」のツールとして ── Kent Beck氏の4つの提言 では、どうすればこの問題から抜け出せるのでしょうか。Kent Beck氏は講演の結論で、4つのアプローチを提示しています。 Kent Beck 氏のプレゼン資料から引用 (p.11) 1. Observe later（後で観察する） 価値連鎖の早い段階（努力やコード量）ではなく、後の段階（アウトカムや影響）を観察することを推奨しています。「開発者1人あたりの利益を見てください」と彼は例を挙げています。 2. Encourage awareness（認識を促す） 「システムを高速化する最良のテクニックの1つは、システムがどれだけ速いかをグラフ化することです」と述べ、可視化によって自然な改善を促すことを提案しています。 3. Avoid pressure（プレッシャーを避ける） 「リーダーとしてプレッシャーをかけないことは最も難しいことです。しかし、プレッシャーをかけると、システムの歪みが生じます」と警告しています。 4. Instill purpose（目的を植え付ける） 「今のような頻度で本番環境のインシデントが発生しない世界は素晴らしいと思いませんか？」という形で、プレッシャーではなく共通の目標として提示することの重要性を語っています。 この観点から見ると、 DORA指標 （デプロイ頻度、リードタイム、MTTR、変更失敗率）も実は「Output」レベルの測定です。これらは「コード行数」のような純粋な努力（Effort）レベルよりは価値に近いものの、依然として「どれだけ速く・頻繁にリリースしたか」を測っているに過ぎません。顧客の行動変化（Outcome）やビジネスへの影響（Impact）を直接測定しているわけではないのです。 それでも、DORA指標には意味があります。なぜなら、これらの指標を プレッシャーツールとしてではなく、チームの健全性を把握し、改善の機会を見つけるための認識ツール として使うことができるからです。 重要なのは、 どんな指標であっても、それを目標化してプレッシャーをかけるのではなく、現状を理解し、チーム自身が改善方法を考えるためのツールとして活用すること です。 アジャイル実践者への提案 ベロシティだけでなく、顧客価値の提供速度を測る チームの指標とビジネス指標を接続する DORA指標やDevExの考え方を取り入れる ウォーターフォール開発者への提案 現在の指標（バグ数、納期）を維持しつつ、先行指標を追加 小さな改善サイクルを導入して効果を検証 リスクを最小化しながら段階的に変化を進める 次回予告 第3回は「 開発生産性を阻む『日本の3大悪習』── 要件定義、会議、コミュニケーションの罠 」をお届けします。 日本の開発現場が抱える構造的な課題と、その改善への道筋を探ります。 第1回、日本の開発現場の「リアル」を数字で見る ── 798名の声から浮かび上がる衝撃の実態 調査全体について 第2回、開発生産性への意外な好印象 ── アジャイル実践者59.6%が前向きな理由 開発手法による意識の違いの本質 第3回、開発生産性を阻む「組織の3大課題」 ── 要件定義、会議、コミュニケーションの問題 取り組みが失敗する本当の理由 第4回、AI時代の技術格差 ── Visual SourceSafe 15.8%が示す変革への壁 なぜ従来型ツールから移行できないのか 第5回、なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 日本の開発者が本当に求めているもの 第6回、なぜDORA指標は日本で普及しないのか ── 認知度4.3%の背景と打開策 数値化への懸念と向き合う方法 第7回、生産性向上を阻む組織の壁 ── 37.8%が未着手の深刻な理由 経営層を説得する具体的な方法 第8回、既存システムから次世代への変革 ── 日本の開発現場が立つ分岐点 品質文化を強みに変える改革のロードマップ また、ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 突然ですが皆さんは、イベントに参加することはありますか？ コロナ禍を経てオンラインイベントも増えましたし、最近はオフラインイベントも少しずつ戻ってきてるように感じています。 そこで今回は エンジニアの人生を変えたイベント と題して、弊社エンジニア達が過去に参加したイベントの中で、特に印象に残っているイベントを紹介していきます。 それでは見ていきましょう！ Hiyoko Developer Meeting TDD Boot Camp 2020 Online #1 RubyKaigi 2022 まとめ Hiyoko Developer Meeting Tech Lead をやらせてもらってる戸田です。 僕が今まで参加して一番印象に残っているのは、Hiyoko Developer Meetingと呼ばれるイベントです。 hiyoko-dev.connpass.com 当時の自分は20代中盤くらいで、会社には先輩しかいない状況でした。同年代のエンジニアとの比較が出来ない状況が長く続き、自分自身のエンジニアとしての立ち位置、そして市場価値を測ることが難しかったのを覚えています。 そんな中、このイベントが開催されました。同年代のエンジニアと交流できるとのことで、すぐに参加申請を押したのを覚えています。 実際に参加して、同年代のエンジニアのみんなと交流して、自分自身の立ち位置と市場価値の現在位置を大まかに把握できましたし、自分のキャリアの方向性の答え合わせが出来ました。 その中でも強烈に覚えているのは、「エンジニアの友人」が出来たことです。 社外の横の繋がりは、転職によって会社が変わっても消えることはありません。当時は違う会社で働いていましたが、今ではファインディで一緒に働いている友人もいます。 彼らと初めて出会うきっかけをくれたこのイベントを、僕は一生忘れないでしょう。 ファインディでも先日、若手エンジニア限定のイベントを開催しました。 findy.connpass.com このイベントに参加してくださった若手エンジニアのみなさんがXのアカウント交換をしている姿を見て、10年前の自分と友人の姿を重ねました。 当時の僕と同じ境遇の若手エンジニアの読者のみなさんも、是非イベントに参加してみてください。 そしてまずは顔見知りを作るところから始めてみてください。その出会いが友人となり、気づいたら同僚となり、戦友と呼べるような関係になるかもしれません。そのきっかけと出会いを作るのに必要なものは、あなたが持つであろう小さな勇気だけです。 TDD Boot Camp 2020 Online #1 Findy Team+を開発しているEND( @aiandrox )です。 私が一番印象に残っているイベントは、「TDD Boot Camp 2020 Online #1」というイベントです。コロナ禍で配信のみのイベントがほとんどの中で、初めて参加した「見るだけではないイベント」でした。 tddbc.connpass.com 当時、私はプログラミングスクールを卒業して、エンジニアとして就職活動をしていた頃です。テストについては興味があるが、チーム開発の経験もなく「良いテスト」がどういったものなのか肌で理解できていませんでした。そんな中で、TDDを実践できるイベントがあるということを知り、勇気を出して参加しました。 実際に参加してみると、想像していた以上に濃い体験が待っていました。 t_wadaさんによる基調講演のライブコーディングでは、FizzBuzzのテストと実装をここまで細かく繰り返すのかと衝撃を受けました。仕様のTODOリストを作成する、まずは落ちるテストから書く、利用者の視点でテストを書く、など、すべてが新しい発見でした。 初めてのモブプロでは、わからないことだらけではあったものの、現役エンジニアの方と話しながらテスト駆動開発を進めることができました。同じコードを見ながらちゃんと会話ができたのと、どう進めていくか相談をして自分の意見が取り入れられた経験が自信にもなりました。 このイベントをきっかけに、私はテストの目的や良さについて自分の言葉で話せるようになりました。それは今も開発スタイルの根源にあります。 振り返ると、あのとき「まだエンジニアでもない自分には無理かもしれない」とひよってしまうのではなく、思い切って参加して本当によかったです。 RubyKaigi 2022 Findy IDを開発しているsontixyou( @sontixyou )です。 私にとっては「RubyKaigi 2022」への参加でした。 rubykaigi.org 当時、私はベンチャー企業でエンジニアとして働いており、Ruby歴は2年でした。 RubyKaigi 2022への参加は、私にとって初めてのテックカンファレンス体験。行きの道中は、参加が楽しみであるのとワクワク感でいっぱいでした。 参加の目的はつぎのものです。 セッションを通じて、Rubyが好きな理由を言語化したい Rubyistのつながりをつくりたい RubyKaigi 2022の3日間、毎セクション何かしらの発表を聞きました。 分からない用語もたくさんありましたし、当時の自分の実力でもなんとか分かる内容もありました。 カンファレンス終了後、私はRubyが好きでプライベートでも仕事でもRubyを使い続けたいと思いました。 しかし、同時に課題も見つかりました。「Rubyの具体的にどんな点が好きなのか」を自分の言葉で説明できなかったのです。Ruby良いよなという感情はあるのに、それを論理的に語る知識と経験が不足していました。 この気づきから、自分のスキルアップのための取り組み方を大きく変えました。 Rubyの動的型付けの柔軟性を客観視できるように静的型付け言語のRustに挑戦 gemの開発を通じて、Rubyの深い知識を身につける 地域のRubyコミュニティに定期的に参加してRubyistと交流することで、自分の考えを深める これらを通じて、ただ「Rubyが好き」から「Rubyのこの部分がこういう理由で素晴らしい」と語れるようになりました。技術的な実力向上はもちろん、自分のキャリアの方向性も明確になったと感じています。 技術カンファレンスは、新しい知識を得る場としてだけでなく、自分の現在地を知り、自分の伸びしろを見つけるチャンスだと思います。 「分からないことがあっても大丈夫」という気持ちで、ぜひ積極的に参加してみてください。きっと、予想もしない成長のきっかけや出会いが見つかるはずです。 最後に、RubyKaigi 2022でスポンサーしていたファインディで現在働いているのはなにかの縁かもしれません。 まとめ いかがでしたでしょうか？ 1回のイベントに参加するだけで、学びだけではなく、エンジニアとしてのキャリアや人生に対して大きなヒントを得ることが出来るかもしれません。ぜひ皆さんの思い出のイベントも教えてください。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは。Findy Tech Blog編集長の高橋（ @Taka-bow ）です。 皆さんは「開発生産性」という言葉を聞いて、何を感じますか？ これまで、エンジニアの「開発生産性」という概念に対する理解度や、その活用状況を体系的に調査した事例はほとんどありません。 そこで2025年、ファインディは ソフトウェア開発における「開発生産性」に関する実態調査 を実施し、日本のIT従事者798名にこのテーマを真正面から問いかけました。 【調査概要】 調査対象： ソフトウェア開発（組み込み開発を含む）に直接関わるエンジニア、プロダクトマネージャー、プロジェクトマネージャー、エンジニアリングマネージャー、開発責任者など 調査方法： インターネット調査 調査期間： 2025年4月2日(水)～2025年5月21日(水) 調査主体： ファインディ株式会社 実査委託先： GMOリサーチ&AI株式会社 有効回答数： 798名（95%信頼区間±3.5%） 統計的検定力： 80%以上（中程度の効果量d=0.5を検出） 調査内容： 開発生産性に対する認識 開発生産性に関する指標の活用状況 開発生産性に関する取り組み 開発環境・プロセス評価 組織文化と生産性 その結果は、私たちの想定を大きく覆すものでした。これまで「日本は海外に比べてアジャイルやDevOpsの浸透が遅れている」といった一面的な見方がされがちでした。 しかし、実際に見えてきたのはそれだけではありません。日本の開発現場には、品質へのこだわりやチームワークといった確かな強みがある一方で、それを十分に活かしきれない構造的な課題が浮き彫りになったのです。 まずは今回の調査から見えてきた全体像をお伝えし、その後はシリーズでテーマごとに深掘りしていきたいと思います。 第1回、日本の開発現場の「リアル」を数字で見る ── 798名の声から浮かび上がる衝撃の実態 調査全体について 第2回、開発生産性への意外な好印象 ── アジャイル実践者59.6%が前向きな理由 開発手法による意識の違いの本質 第3回、開発生産性を阻む「組織の3大課題」 ── 要件定義、会議、コミュニケーションの問題 取り組みが失敗する本当の理由 第4回、AI時代の技術格差 ── Visual SourceSafe 15.8%が示す変革への壁 なぜ従来型ツールから移行できないのか 第5回、なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 日本の開発者が本当に求めているもの 第6回、なぜDORA指標は日本で普及しないのか ── 認知度4.3%の背景と打開策 数値化への懸念と向き合う方法 第7回、生産性向上を阻む組織の壁 ── 37.8%が未着手の深刻な理由 経営層を説得する具体的な方法 第8回、既存システムから次世代への変革 ── 日本の開発現場が立つ分岐点 品質文化を強みに変える改革のロードマップ それでは、第2回以降で深掘りしていく各テーマに入る前に、まずは調査全体を象徴するいくつかの結果をご紹介します。 開発生産性への認識は前向き、でも実践にはギャップが 組織運営の課題が技術的課題を上回る現実 従来型ツールがAI時代の足かせに Developer Experience（DevEx）の低い認知と見えてきた課題 測定指標の混乱 ── 業界全体で「何を測るべきか」が不明確 なぜ変われないのか ── ケイパビリティと体験のギャップ 数字だけでは動けない現場 必要なのは「体験から学ぶ」ステップ 日本の強みを活かしながら 開発生産性への認識は前向き、でも実践にはギャップが 興味深い発見のひとつは、IT従事者の開発生産性に対する認識が予想以上に前向きだったことです。 「開発生産性」という言葉に対してネガティブな印象を持つ人は わずか7.6% 。多くのエンジニアが、生産性向上に対して前向きな姿勢を示していました。 特に注目すべきは、開発手法による意識の差です。 アジャイル実践者の59.6% がポジティブな印象 ウォーターフォール開発者は39.5% に留まる 私は「アジャイル実践者」のほうが、よりネガティブに捉えているのではと予想していたので、これは意外な結果でした。 また、開発生産性向上への取り組みは「実施36.6%」「未実施37.8%」と拮抗している一方で、25.6%が自組織の状況を把握していないという結果が浮かび上がりました。これは、生産性への関心は高いにもかかわらず、取り組みが十分に浸透しておらず、組織内の情報共有やコミュニケーションに課題が残っていることを示しています。 組織運営の課題が技術的課題を上回る現実 開発生産性を阻害する要因を尋ねたところ、技術的な問題よりも組織運営の課題が上位を占めました。 最大の障壁は 「不明確な要件」（53.5%） です。半数以上のIT従事者が、プロジェクトの上流工程に大きな問題を感じています。続いて以下の通りです。 会議が多い 38.7% コミュニケーションの問題 33.6% これらはいずれも組織運営に深く関わる問題であり、しかも長年にわたり繰り返し指摘されてきた課題です。 その根本原因は「やり方を変えないこと」にあるのではないでしょうか。どれほど最新のツールやフレームワークを導入しても、こうした本質的な課題に向き合わない限り、生産性の大幅な向上は望めません。 日本の開発現場は、技術力そのものは十分に備えているにもかかわらず、それを最大限に活かせる土壌が整っていない──そんな実態を映し出しているのかもしれません。 従来型ツールがAI時代の足かせに ソースコード管理ツールの利用状況を見ると、技術格差の深刻さが明らかになりました。 GitHub 30.5% Visual SourceSafe 15.8% Subversion 13.7% GitHubがトップあることは驚きませんでしたが、2012年にサポートが終了したVisual SourceSafeが2位という事実は衝撃的でした。さらにSubversionも含めると、約3割の組織が従来型のバージョン管理システムを使用していました。 これは単なる「古いツールを使っている」という話では済みません。 GitHub CopilotやAmazon CodeWhispererなど、最新のAI開発支援ツールはGitベースのワークフローを前提としています。従来型ツールに縛られている組織は、AI活用による生産性向上の波に乗り遅れるリスクが高いのです。 つまり、現在の技術格差が、将来的にはさらに大きな生産性格差へと発展する可能性があるということです。 Developer Experience（DevEx）の低い認知と見えてきた課題 日本において「Developer Experience（DevEx）」という概念は、まだ広く浸透していません。今回の調査でも、DevExという言葉を知っていると答えたエンジニアはわずか 4.9% にとどまりました。 同じ調査では、DevExの要素であることを伏せたうえで、基盤的な要素の満足度も尋ねました。その結果、以下のようにきわめて低い数値が明らかになっています。 CI/CDパイプライン 満足度14.2% ドキュメント管理システム 満足度17.5% 開発環境整備 満足度24.7% これらの結果は、日本の開発現場におけるインフラ整備の遅れを如実に物語っています。特にCI/CDパイプラインの満足度が14.2%にとどまっているのは深刻です。継続的インテグレーション／デリバリーは現代のソフトウェア開発の基本であるにもかかわらず、8割を超えるエンジニアが不満を抱えたまま日々の開発を続けているのです。 こうした環境の不備は、エンジニアのモチベーション低下を招くだけでなく、生産性そのものにも直結します。ビルド待ち時間、手動デプロイによるミス、ドキュメント不足による知識共有の停滞 ── これらの問題が開発現場を日常的に妨げているのです。 測定指標の混乱 ── 業界全体で「何を測るべきか」が不明確 最後に、最も根本的な問題があります。業界全体で「何を測るべきか」という共通認識が欠けているのです。 実際、組織によって重視する指標は大きく異なります。ある企業はコード行数を追い、別の企業はバグ数を数え、さらに別の企業は残業時間を管理しています。しかし、これらの指標が本当に開発生産性を正しく示しているのか、確信を持てている人はほとんどいません。 世界的に注目されているDORA指標（デプロイ頻度、リードタイム、平均復旧時間、変更失敗率）の認知度がわずか 4.3% にとどまっているという事実も、この混乱を裏付けています。 測定基準が曖昧なまま「生産性を上げろ」と求められても、現場は困惑するばかりです。まるでゴールの見えないマラソンを走らされているようなものです。 なぜ変われないのか ── ケイパビリティと体験のギャップ 調査では、44.3%が「開発生産性を高めたい」と前向きに答えました。 しかし、実際に自社で具体的な取り組みをしていると答えたのは36.6%にとどまります。 ここで重要なのは、この36.6%が必ずしも「正しい指標に基づいて取り組んでいる」とは限らないという点です。測定基準が不明確なままでは、努力が空回りしてしまう危険があるのです。 その背景には、“知識として知っていること”と“実際に体験していること”の間に横たわる、大きなギャップがあります。 数字だけでは動けない現場 たとえば、DORA指標の認知度はわずか4.3%。「デプロイ頻度を上げよう」「リードタイムを短縮しよう」といった施策を伝えても、それがもたらす真の価値──素早いフィードバック、リスク低減、チームの自信向上──を実感したことがなければ、単なる数字遊びにしか見えません。 同じことはCI/CDの整備にも言えます。満足度14.2%という結果は、自動化がまだ十分に根付いていないことを示しています。ビルドやテストが自動化されていれば「コードを書いたらすぐに安心できる」「金曜の夕方でもデプロイできる」──そんな開発体験が得られます。しかし、体験がなければその価値を想像することすら難しいのです。 必要なのは「体験から学ぶ」ステップ 本当に必要なのは、生産性の高い組織が備えている ケイパビリティ（組織能力） を理解し、実際に体験することです。 疎結合なアーキテクチャ ：チームが独立して素早く動ける 自動テスト ：安心してリファクタリングできる モダンなバージョン管理 ：PR・レビュー・CI/CDが可能になる ただし、これらのケイパビリティは一足飛びには身につきません。段階を踏んで育てていくしかないのです。 Visual SourceSafeを利用している組織は15.8%、Subversionを利用している組織は13.7%に上り、両者を合わせると全体の約3割を占めます。つまり、GitHub（30.5%）とほぼ同じ規模で、いまだにレガシー寄りの環境が現場に残っているのです。こうした環境では、PRやコードレビュー、CI/CDパイプラインといったモダンな仕組みを前提とした開発体験を実現するのは難しく、「デプロイを自動化しましょう」と言われても、その基盤自体が存在しません。 だからこそ、小さな一歩から始める必要があります。新しいツールの価値を「頭で理解する」のではなく、まずは「体験する」こと。その実感が、次のステップに進む原動力となります。こうした積み重ねが、最終的に組織全体の変革を実現していくのです。 日本の強みを活かしながら 日本の開発文化が培ってきた 品質へのこだわり や チームワーク は、決して手放す必要はありません。むしろそれを土台にしながら、新しいケイパビリティを段階的に身につけていく。そのプロセスこそが現実的な改善への道筋です。 あなたの組織は今、どの段階にいますか？ そして明日から、何を始めますか？ この問いへの答えを探るために、次回以降は7回にわたり調査結果をテーマ別に深掘りしていきます。 第2回は「開発生産性への意外な好印象 ── アジャイル実践者59.6%が前向きな理由」を取り上げます。 また、ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 そのような状況の中で先日、Findy AI Meetupの記念すべき第1回を福岡で開催しましたので、今回はそのイベントの様子や内容を紹介します。 findy-inc.connpass.com 福岡でのイベント開催は実に2年ぶりとなっており、我々も参加者の皆さんにお会い出来ることを楽しみにしていました。 ありがたいことにキャンセル待ちが出るほどに参加申し込みをしていただきました。当日参加くださったみなさま、ありがとうございました！ Findy AI Meetupとは？ 登壇内容 Nx × AI によるモノレポ活用 ~ コードジェネレーター編 Findy Freelance利用シーン別AI活用例 ファインディ株式会社における生成AI活用までの軌跡 懇親会 まとめ Findy AI Meetupとは？ ファインディ株式会社のエンジニアが主催する技術系のオフラインイベントです。 ファインディ株式会社では、生成AIやAIエージェントの活用を通じて開発生産性の向上を目指す取り組みを行っています。このイベントでは、ファインディのエンジニアが社内での実践事例を紹介するとともに、エンジニア同士がつながり、知見の共有や交流を目的としています。 今回のMeetupは初めての開催となっており、登壇者は全員弊社のエンジニアとなっています。 登壇内容 Nx × AI によるモノレポ活用 ~ コードジェネレーター編 まず弊社のフロントエンド テックリードの新福が登壇しました。 弊社のフロントエンドの多くにはNxが採用されています。今回はNxを採用してきたことが、生成AIの時代にマッチしていたというお話をしました。 tech.findy.co.jp これまで弊社では、NxのGeneratorを用いて開発効率の向上に取り組んできました。NxのGeneratorは強力な機能を持つ反面、覚えることも多く、初心者がとっつきにくいというのが課題でした。 tech.findy.co.jp 最近のNxは生成AIとの連携が強化されており、中でもNx MCPの登場によって、モノレポ内の情報を生成AIのコンテキストとして利用できるようになりました。 Nx MCPの素晴らしい点は、モノレポ内のプロジェクトやNxのGeneratorを自然言語で操作できることにあります。これにより、複雑なコードを書かなくても柔軟で対話的なコード生成の業務フローが実現可能になりました。 例として今回は、CopilotやClaude CodeのスラッシュコマンドからNx MCP + Nx Generatorを起動させる方法を紹介しています。 生成AI時代の業務標準化は、もうすぐそこに来ているのかもしれません。 今回はNxのGeneratorに焦点を当ててお話しましたが、Nx公式のCIサービスである「Nx Cloud」にもAI機能が続々と追加されているので、いつかご紹介できればと思います。 Findy Freelance利用シーン別AI活用例 次にフロントエンドエンジニアの主計が、Findy Freelanceチームのコーディング以外でのAI活用事例をいくつか紹介しました。 1つ目は、不具合調査時の Ask Devin の活用です。 不具合報告があった際に、不具合内容をAsk Devinに調査を依頼しています。 対象となるリポジトリを複数選択できるため、原因箇所の特定や切り分けが素早くできるようになっています。 専門領域に関わらず一次調査ができるのもありがたいです。 2つ目は、dependabotのAIレビューです。 最初はDevinのPlaybookを利用して週1でまとめてレビューを依頼していましたが、 Claude Code Base Actionを利用して随時自動で行うように改善しました。 精度も上がり、日々の作業の負担が軽減されています。 3つ目は、AI によるリファインメントの実施です。 PdMとエンジニアで行っているリファインメントの文字起こしデータをNotebookLMに追加して、 リファインメントの観点を洗い出しプロンプト化しています。 ラベル付与をトリガーとすることで、PdMメンバーが任意のタイミングでAIリファインメントを実施できるようになり、リファインメントの負担を軽減できています。 アウトプットに関しては文量が多かったり、肯定的なフィードバックになりがちだったりと課題があるので、引き続きプロンプトを調整しています。 チームでAI活用を進めるため、10分勉強会（5分LTを正社員メンバーで持ち回り）で実施しています。 継続することを優先し、スキップ可や記事紹介可などハードルを下げて取り組んでいます。詳細はこちらの記事をご覧ください。 findy-code.io 普段の業務にAIを活用するために、AIのキャッチアップと同時に、どの業務にどうAIを活用するか日々チーム全体で考えることが大事だと考えています。 引き続きAIを積極活用していくので、良い事例があれば紹介していきたいと思います。 ファインディ株式会社における生成AI活用までの軌跡 最後に、テックリードの戸田が、「ファインディ株式会社における生成AI活用までの軌跡」と題しまして、弊社が生成AIで結果を出せるようになるまでの軌跡を紹介しました。 まず弊社の開発組織の開発文化を支えている考え方やテクニックをいくつか紹介しました。以前にこのテックブログでも紹介した内容もあります。 特にタスク分解とPull requestの粒度は重要です。 tech.findy.co.jp tech.findy.co.jp また、統一されたコーディング規約や設計、ドキュメントを整備することも文化として根付いています。特にドキュメント整備は重要で、弊社ではJOIN初日にPull requestを出せるようにしています。 このように、弊社の開発文化を支えているテクニックはコードを書く前の事前準備を重要としており、また、環境や自動化、スピードに拘りを持っています。 これは小さなことをコツコツと積み重ねることでしか実現できませんが、それをしっかりやり切ってきた歴史があり、その積み重ねこそが開発組織の文化となっています。着実に積み重ねたものは強いのです。 次に、弊社が生成AIを活用するために取り組んだ内容を紹介しました。 既存コードの最適化や不要なコードの削除、テストコードの整備やドキュメンテーションなど、生成AIのガードレールとなる要素の整備に関して紹介しました。 また、生成AIに命令を投げる際は、可能な限りスコープを限定的にして、具体的な内容を段階的に渡すのが良いとされています。そのため、弊社で取り組んでいたタスク分解のスキルが重要となるシーンが増えました。 ここまで読んだ読者なら気付いた方もいるかもしれません。そうです。弊社の開発組織の開発文化は、生成AIが流行するずっと前から生成AIフレンドリーな文化となっていたのです。 今までの開発組織に生成AIを足した。ということではなく、今までやってきたことの延長線上に生成AIが乗っかってきた。という表現が近いかもしれません。そのため、生成AIを導入したことで一時的に生産性が落ちた。といった光景は、弊社ではほとんど見られなかったのです。 今までの積み重ねが、結果的に生成AIとの協業を可能としていました。もちろんガードレール整備がまだ行き届いていない箇所もあります。しかしながら、そこの整備に対して投資をするという意思決定が当たり前となっている開発文化でもあります。 このあと、生成AI時代の弊社の開発現場の様子をいくつか紹介させてもらいましたが、これはまた別の記事でも紹介できればと思います。 懇親会 登壇発表後は参加者の皆さんと懇親会を開催しました。 懇親会では「パックマンルール」をお願いしました。懇親会で誰かと話すときは新しい人が会話に入れるように、一人分のスペースを空けて話しましょう。というルールです。 生成AI活用における悩みや知見を意見交換して、楽しんでいただけたようです。 まとめ いかがでしたでしょうか？ 当日、イベントに足を運んでくださった参加者のみなさん、本当にありがとうございました。頂いたアンケート結果を、次回開催の参考とさせていただきます。 次回開催は9月前後を予定しております。残念ながら今回のイベントに参加出来なかったみなさんも、次回イベント開催時には是非ご参加ください！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは。 ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 そのような状況の中でこのたび、Findy AI Meetupの記念すべき第1回を、2025年8月4日(月)に福岡にて開催することとなりました！ findy-inc.connpass.com 今回は、このイベントの紹介をしたいと思います。それでは見ていきましょう！ Findy AI Meetupとは？ 登壇予定 Nx × AI によるモノレポ活用 ~ コードジェネレーター編 Findy Freelance利用シーン別AI活用例 ファインディ株式会社における生成AI活用までの軌跡 まとめ Findy AI Meetupとは？ ファインディ株式会社のエンジニアが主催する技術系のオフラインイベントです。 ファインディ株式会社では、生成AIやAIエージェントの活用を通じて開発生産性の向上を目指す取り組みを行っています。このイベントでは、ファインディのエンジニアが社内での実践事例を紹介するとともに、エンジニア同士がつながり、知見の共有や交流を目的としています。 福岡でのイベント開催は実に2年振りとなっており、我々も参加者の皆さんにお会い出来ることを楽しみにしています。 登壇予定 Nx × AI によるモノレポ活用 ~ コードジェネレーター編 弊社では、ほぼ全てのフロントエンドでNxによるモノレポ管理が採用されています。 tech.findy.co.jp tech.findy.co.jp 最近のNxは生成AIとの連携が強化されており、中でもNx MCPはモノレポ内の情報を生成AIのコンテキストとして利用できるなど非常に便利です。 今回は、NxのGeneratorをより柔軟かつ対話的に利用できるよう、Nx MCPや プロンプトファイル を組み合わせ、生成AI時代の業務の標準化を目指したお話を紹介します。 Findy Freelance利用シーン別AI活用例 Findy Freelanceの開発ではコーディング時の生成AI活用はもちろんのこと、 コーディング以外の開発関連業務のなかでも生成AIを活用し業務効率化を図っています。 特長の異なる生成AIをどのように使い分けているか、利用シーン別にご紹介します。 ファインディ株式会社における生成AI活用までの軌跡 「ファインディ株式会社における生成AI活用までの軌跡」と題しまして、弊社が生成AIで結果を出せるようになるまでの軌跡を紹介します。 まず弊社の開発組織の開発文化を支えている考え方やテクニックをいくつか紹介します。 tech.findy.co.jp tech.findy.co.jp その開発文化の上で、どのように生成AI活用を推し進めたのか、現在はどのような開発現場になっているのかを紹介します。 まとめ いかがでしたでしょうか？ 会場へのアクセスは天神駅から徒歩3分となっています。また、TVCM公開記念ノベルティや、イベント後半には懇親タイムもご用意しています。 申込みの先着順となっており、ありがたいことに参加枠も残りわずかとなっております。生成AIの活用事例に興味のある方は奮ってご参加ください！ イベント参加申し込みはこちらから ↓ findy-inc.connpass.com みなさんにお会いできることを楽しみにしています！

こんにちは。ファインディでソフトウェアエンジニアをしている千田（ @_c0909 ）です。 2025年3月末頃からファインディに導入されたClaude Codeは、私たちの開発フローに大きな変化をもたらしました。特に私が注目し活用を進めてきたのが、カスタムスラッシュコマンドの機能です。 Claude Codeを初めて触った時は、 CLAUDE.md に長文で汎用的な指示を書いてコードを生成していました。しかし、全てのプロンプトを網羅するには限界があり、より効率的な活用方法を模索していました。そんな中で出会ったのが、このカスタムスラッシュコマンド機能です。 この機能は、日々のGit操作やコーディング作業の自動化を後押ししてくれます。本記事では、私が実際にどのようなカスタムスラッシュコマンドを作成し、どのように開発業務に役立てているのかを具体的な事例と共にご紹介します。 Claude Codeのカスタムスラッシュコマンドとは 実際に作成したカスタムスラッシュコマンド ブランチを作成 commitメッセージを作成 Pull Requestを作成 ブランチ, commit, PRの全てを一度に作成 頻出するコードを自動生成 まとめ Claude Codeのカスタムスラッシュコマンドとは Claude Codeでは、 .claude/commands/ ディレクトリにMarkdownファイルを配置することで、個人またはチーム独自のコマンドを作成できます。例えば /create-branch のようなコマンドを実行すると、事前に定義したルールに従ってClaude Codeが作業を進めてくれます。 docs.anthropic.com 実際に作成したカスタムスラッシュコマンド まずはGitのコマンド実行です。Gitの操作は同じ内容を CLAUDE.md にも書いていて、コードを書いてPR作成までの流れを一貫して依頼することもあります。ただ、コーディングとGit操作の工程を分けて、その間に人がチェックした方が手戻りが少ないため、敢えてカスタムスラッシュコマンドとして用意しています。 ブランチ命名やメッセージの作成などは、次のように自動化しています。 ブランチを作成 .claude/commands/git-create-branch.md ## branchを作成 - ブランチ名は [ Conventional Branch ]( https://conventional-branch.github.io/ ) に従う - feature/[FeatureName]-[実装した機能名] 例: feature/admin-user-role-edit-invite-form 毎回悩みがちなブランチ名の命名。Conventional Branchに従っていても、命名するタイミングで手が止まってしまうこともありますよね。このコマンドのおかげでブランチ名を考える手間がなくなり、開発がスムーズになりました。 次の画像は、コマンドを実行した時の結果です。 commitメッセージを作成 .claude/commands/create-commit.md # commitメッセージを作成 ## 実行手順 1. Read @~/.claude/commands/guideline-read-code.md 2. 違反があれば作業を中断 4. ` git status ` でファイルを確認 5. [ Conventional Commits ]( https://www.conventionalcommits.org/en/v1.0.0/ )に従ってコミットを実行 ## 形式の指定 - type(scope): subject の形式に従う - タイトルは50文字以内、本文は72文字程度で改行 - 動詞は原形を使用（add, fix, updateなど） - scope は原則記述するが、適切なものがない場合は省略可 - コミットメッセージは小文字で始める ## 実装とテストが含まれる場合の優先ルール - 実装とテストコードが含まれている場合、typeはtestよりもfeat/fixを優先する このコマンドの特徴は、コミット前に必ずコーディングガイドラインをチェックすることです。手順1の Read @~/.claude/commands/guideline-read-code.md の部分で読み込ませてます。 例えば、Reactのテストコードでhooksの関数を作成した場合、そのテストとしてコールバック関数がパラメータ付きで実行されることなどを確認しますが、実行回数やエラー時のコールバック関数が実行されていないことを必ずセットで検証します。このような内容をガイドラインとして盛り込んでいます。 機械的にできるレビューは、Commit前にClaude Codeが事前チェックすることで、レビューの負荷を下げます。 なお、弊社のテストコードの考え方については Findyの爆速開発を支える「システムを守るテストコード」の実例3選 - Findy Tech Blog で紹介しています。 Pull Requestを作成 .claude/commands/git-create-pr.md # PRを作成 - Read @.github/PULL _ REQUEST _ TEMPLATE.md に従うこと - Draftで作成すること - push時は ` git push -u origin <branch_name> ` のように ` --set-upstream ` を指定すること - コマンドの例: ` gh pr create --draft --title "title" --body "body" ` PRのテンプレートに詳細な情報が記載されているため、ファイルを参照するだけのシンプルな構成です。エディターでもセルフレビューをしますが、GitHubのdiffの方が見やすいため、PRは必ずDraftの状態で作成してセルフレビューを実施するフローを標準化しています。 また、 PULL_REQUEST_TEMPLATE.md には「動作確認」の項目を用意しています。これはブラウザ上で目視で動作確認する目的で、Claude Codeに内容を列挙して貰っています。 一部抜粋すると次のイメージです。 ## 動作確認 - [ ] レスポンシブ対応が正しく動作すること（スマートフォン、タブレット、デスクトップ） - [ ] Xのシェアボタンが正しく表示されること - [ ] 背景色がブレークポイントに応じて適切に変更されること この対応により、特にフロントエンドの実装時はレビュー前にブラウザで動作確認をする時のチェック観点として、PRのレビュアーにも共有しています。 ブランチ, commit, PRの全てを一度に作成 .claude/commands/git-create-branch-commit-pr.md # branch & commit & pr を作成 ## 実行手順 1. Read @~/.claude/commands/create-branch.md を実行 2. Read @~/.claude/commands/create-commit.md を実行 3. Read @~/.claude/commands/create-pr.md を実行 ブランチ作成からPR作成までの一連の作業は、開発サイクルの中で何度も繰り返されます。この定型的なプロセスを自動化するコマンドを作成しています。 開発プロセスの中で事前にタスクを分解し、その粒度に沿ってPRを作成しています。そのため、PRの粒度が小さく、1つのPRに対してコミットは1件が多いです。これにより、ブランチ作成からPR作成までの自動化が容易に実現できています。 タスク分解の詳細は Findyの爆速開発を支えるタスク分解 - Findy Tech Blog で紹介しています。 頻出するコードを自動生成 カスタムスラッシュコマンドは、Git操作だけでなく、具体的なコーディング作業の自動化にも威力を発揮します。私の経験則ではIssueに作成したタスクリストに基づき、小さな単位で具体的なコードを指示すると期待した結果が得られやすいと感じます。 そのため、定型化できる実装はカスタムスラッシュコマンドで対応してもらいます。例えば、フロントエンドの実装では、次のよく使うコードはカスタムスラッシュコマンドで対応しています。 保存ボタンの連打防止の実装 テキスト入力の必須バリデーションの実装 フォーム入力中の離脱防止の実装 .claude/commands/[Repository name]-coding-is-saving.md ## 保存ボタンの連打防止を実装 作業対象のフィーチャー: $ARGUMENTS ### 参考情報 - PRの確認にghコマンドを使うこと - https://github.com/Findy/[リポジトリ名]/pull/111 ### 実装コードの例 < Button priority= "primary" size = "large" disabled = {isSaving} type = "submit" > 保存 </ Button > ### テストコードの例 describe('isSaving', () => { it('should disable save button when isSaving is true', () => { // Arrange setup({ isSaving: true, }); // Act & Assert expect(screen.getByRole('button', { name: '保存する' })).toBeDisabled(); }); it('should enable save button when isSaving is false', () => { // Arrange setup({ isSaving: false, }); // Act & Assert expect(screen.getByRole('button', { name: '保存する' })).toBeEnabled(); }); }); コーディングにおいてカスタムスラッシュコマンドを作成する基準は次の通りです。 3回以上同じような実装に遭遇した プロダクトコードとテストコードを1セットでPRを作成できる 実装内容が分かり切っている このようにClaude Codeに小さな粒度でコードを書いてPRを出して貰いつつ、その間に私は別の作業をします。 Claude CodeのHooksの設定により、コーディングなどの作業が完了したら通知音を鳴らしているため、スムーズに切り替えることができます。 まとめ 本記事では、私が実践しているClaude Codeのカスタムスラッシュコマンド活用術をご紹介しました。Git操作の自動化から、具体的なコーディング作業の効率化まで、多岐にわたる場面でClaude Codeが開発をサポートしてくれています。 カスタムスラッシュコマンドは汎用的な指示よりも、具体的で小さなタスクに特化させて作成することで、その効果を最大限に発揮すると感じています。機械的な作業をClaude Codeに任せることで、私たちはより本質的な開発業務に集中できるように今後も試行錯誤していきたいです。 この記事が、皆さんの開発現場におけるAI活用のヒントになれば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 そのような状況の中で、MCP(Model Context Protocol)の新バージョンが公開され、いくつかの機能が追加されました。 modelcontextprotocol.io そこで今回は、その中でも特に注目すべき3つの機能について紹介したいと思います。 それでは見ていきましょう！ toolの表示名の項目追加 MCPサーバーからの出力データの構造化 Elicitation まとめ toolの表示名の項目追加 MCPサーバーにtoolやpromptを登録する際に、 title を設定することが出来るようになりました。 github.com 今までのMCPサーバーでのtoolの登録は次のようなコードで実行されていました。 import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js" ; import { z } from "zod" ; const mcpServer = new McpServer( { name : "Sample MCP Server" , version : "0.0.1" } ); mcpServer.registerTool( "addition" , { description : "足し算をする" , inputSchema : { a : z.number(), b : z.number() } } , ( { a , b } ) => { return { content : [{ type : "text" , text : String (a + b) }] } ; } ); MCPクライアントからtoolの情報を確認すると、次のような出力になります。 ╭───────────────────────────────────────────────────────────────────────────────────────────╮ │ Tools for sample (1 tools) │ │ │ │ ❯ 1. addition │ ╰───────────────────────────────────────────────────────────────────────────────────────────╯ ╭───────────────────────────────────────────────────────────────────────────────────────────╮ │ addition (sample) │ │ │ │ Tool name: addition │ │ Full name: mcp__sample__addition │ │ │ │ Description: │ │ 足し算をする │ ╰───────────────────────────────────────────────────────────────────────────────────────────╯ Tool nameに addition が、Full nameに mcp__sample__addition が設定されているのがわかります。 同じMCPクライアントで複数のMCPサーバーに接続した場合、tool名が重複してしまうケースが有り得ます。そのため、Tool nameとは別にFull nameが用意されており、MCPサーバー名とtool名を組み合わせた一意な名前が用意されています。 しかしここで重要な問題が起こります。MCPクライアントによっては、Full nameに文字数制限が存在しており、制限を越えてしまうとMCPサーバーの実行に影響が出ることがあります。とはいえ、tool名はLLMが実行対象を決めるための判断材料となっているため、短縮しすぎることはできません。 そこで今回追加された title の出番です。 title を次のように設定します。 import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js" ; import { z } from "zod" ; const mcpServer = new McpServer( { name : "Sample MCP Server" , version : "0.0.1" } ); mcpServer.registerTool( "addition" , { description : "足し算をする" , inputSchema : { a : z.number(), b : z.number() } , annotations : { title : "add two numbers" , } } , ( { a , b } ) => { return { content : [{ type : "text" , text : String (a + b) }] } ; } ); MCPクライアントでtool情報を再確認すると、次のような出力に変化します。 ╭───────────────────────────────────────────────────────────────────────────────────────────╮ │ Tools for sample (1 tools) │ │ │ │ ❯ 1. add two numbers │ ╰───────────────────────────────────────────────────────────────────────────────────────────╯ ╭───────────────────────────────────────────────────────────────────────────────────────────╮ │ add two numbers (sample) │ │ │ │ Tool name: addition │ │ Full name: mcp__sample__addition │ │ │ │ Description: │ │ 足し算をする │ ╰───────────────────────────────────────────────────────────────────────────────────────────╯ title を活用することで、Full nameの文字数制限を気にすることなく、よりわかりやすい名前をMCPクライアントに提供できるようになります。 MCPサーバーからの出力データの構造化 MCPサーバーにtool等を登録する際に inputSchema を設定することは以前から可能でしたが、今回のバージョンアップから outputSchema を設定できるようになりました。 modelcontextprotocol.io outputSchema を定義して、MCPサーバーからのresponseに、 content とは別に structuredContent を設定することで、MCPクライアントは構造化されたデータを受け取ることができるようになります。 実際に outputSchema を設定したMCPサーバーのtoolを見てみましょう。 import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js" ; import { z } from "zod" ; const mcpServer = new McpServer( { name : "Sample MCP Server" , version : "0.0.1" } ); mcpServer.registerTool( "addition" , { description : "足し算をする" , inputSchema : { a : z.number(), b : z.number() } , outputSchema : { result : z.number().describe( "Sum of the two numbers" ) } , } , ( { a , b } ) => { const result = a + b; return { content : [{ type : "text" , text : JSON . stringify ( { result } ) }] , structuredContent : { result } } ; } ); toolを登録する際に、 inputSchema だけではなく outputSchema も設定しています。更にtoolのresponseには content に加えて structuredContent を追加しています。 後方互換性を持たせるために、 content には structuredContent をJSON文字列に変換して返します。 これらの設定により、MCPクライアントはtoolの実行結果をより構造化された形で受け取ることができます。 今回の outputSchema と structuredContent の追加により、MCPクライアントとLLMがMCPサーバーからのresponseをより適切に解析して利用できるようになることを期待できます。 Elicitation 最後になりますが、今回のMCPの新バージョンで追加された機能の中でも特に注目すべき機能が Elicitation です。 modelcontextprotocol.io Elicitation を活用することで、MCPサーバーとMCPクライアントの通信中に、ユーザーに追加情報を要求できるようになります。 今まで紹介したMCPの機能とは一線を画しているのでイメージしづらいと思いますので、実際のコードと具体例で説明していきます。 import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js" ; const mcpServer = new McpServer( { name : "Sample MCP Server" , version : "0.0.1" } ); mcpServer.registerTool( "validate_username" , {} , async () => { const elicitInputResponse = await mcpServer.server.elicitInput( { message : "Input your username." , requestedSchema : { type : "object" , properties : { username : { type : "string" , title : "your username" , description : "input your username." } } , required : [ "username" ] } } ); if (elicitInputResponse. action !== 'accept' ) { throw new Error ( "username is required." ); } const userName = elicitInputResponse.content?. [ 'username' ] as string ; if (userName. length > 12 ) { throw new Error ( "username must be less than 12 characters." ); } return { content : [{ type : "text" , text : ` ${ userName } is valid.` }] , } ; } ); elicitInput を呼び出すことで、ユーザーに追加情報を要求できます。GitHub Copilotで実行した場合、次のような表示になります。 usernameを入力するように要求されているので、次のように入力してみます。 追加要求が成功した場合、ユーザーの入力内容を取得でき、その内容を元に処理を続行できます。 今回は入力されたユーザー名の長さをチェックして、12文字以下であれば有効なユーザー名として処理を続行しています。 今回は12文字以内で入力して送信したため、次のような結果になりました。 また、 elicitInput は文字列の入力だけではなく、enumを使って選択式にするといったことも可能です。選択式にすることにより、入力内容からの分岐をより明確にできます。 mcpServer.server.elicitInput( { message : "select period" , requestedSchema : { type : "object" , properties : { period : { type : "string" , title : "Period" , description : "Select the period" , enum : [ "today" , "yesterday" , "this_week" ] , enumNames : [ "Today" , "Yesterday" , "This week" ] } } , required : [ "period" ] } } ); このように Elicitation を活用することで、MCPサーバーからの追加要求を通じて、ユーザーとのインタラクションをより柔軟に行うことが可能になります。MCPサーバーの使い方、作り方、提供内容がより多様化し、ユーザーにとっても使いやすいツールを提供できるようになることが期待されます。 まとめ いかがでしたでしょうか？ 今回紹介したMCPの新バージョンでは、 title 、 outputSchema と structuredContent 、そして Elicitation といった重要な機能が追加されました。 これらの機能は、MCPサーバーとMCPクライアントの連携をより強化し、ユーザーにとって使いやすいツールを提供することが期待できます。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers