AI活用を一部の人で終わらせない、ファインディのカンファレンス開発チームの実践

AI で個人の業務は速くなった。でも、組織の成果は大きく変わってない。成果に繋げるには、組織が越境を促し、個人が役割の壁を越える必要があり、その先で組織の成果に結びつく大きな価値を生み出せるようになる。

Transcript

1. AI活⽤を ⼀部の⼈で終わらせない ── ファインディのカンファレンス開発チームの実践 ⼭⽥ 智博 ∕ CTO室 開発推進エンジニア 2026.08.27 © Findy Inc. 1
2. ⾃⼰紹介 ⼭⽥ 智博 ファインディ株式会社 CTO室 開発推進所属 エンジニア SIer、Web ベンチャー、フリーランス、SaaS 企業と、多くの現場で開発を経験。 バックエンドを主軸に、開発組織のマネジメントにも携わる。 2026 年 2 ⽉にファインディへ⼊社。CTO室 開発推進に所属し、 現在はファインディ カンファレンスの開発でフルスタック開発に従事しながら、チームの AI 推進役を担う カンファレンス開発チームは 全員フルスタックで、6 名規模のチームです。 © Findy Inc. 2
3. 今⽇お伝えしたいこと AI で個⼈の業務は速くなった。 でも、組織の成果は⼤きく変わってない。 成果に繋げるには、組織が越境を促し、個⼈が役割の壁を越える必要があり、 その先で組織の成果に結びつく⼤きな価値を⽣み出せるようになる。 © Findy Inc. 3
4. 今⽇お話しすること３つ （15 分...と少し） 01 個⼈の速さは、なぜ組織の成果にならないのか 02 組織で成果を上げるために、役割の壁を越えられるようにする 03 越境を⼀部の⼈で終わらせないために、AI を⼯程そのものに組み込む （レビュー負荷を 1/4 にした例） 本⽇はAI活⽤におけるAIツール選定や、セキュリティ‧コストの話ではありません。開発するエンジニアの成⻑と、領域の越境の話です。 レビュー負荷を下げた話も取り組みの⼀例として出しますが、主題はAI時代における組織と個⼈の向き合い⽅（姿勢）についてです。各社各チームで 前提が異なる環境での⼀例ですが、⽇々の業務に向き合うときに思い出していただければ幸いです。 © Findy Inc. 4
5. 01 個⼈の速さは、 なぜ組織の成果にならないのか © Findy Inc. 5
6. AI 活⽤にはいくつかステップがあります 今⽇は「組織の成果が出ている状態」＝ 4 つ⽬の「チーム全員がAI活⽤によりパフォーマンスが上がっている」状態と定義してお話します。 段階 1 段階 2 段階 3 段階 4 導⼊した 使われている 個⼈が活⽤できている 組織で活⽤できている 道具はある。⼀部の⼈が使う 多くの⼈が、⽇常的に使う ⼤多数が業務で使い、パフォーマ ンスが⼤きく上がる⼈も出る チーム全員がAI 活⽤により パフォーマンスが上がってる はじめの 3 段階にもAIの導⼊や運⽤における様々な事情や含蓄があると思いますが、本⽇は触れません。 © Findy Inc. 6
7. 段階3から段階4の差分から、なぜ個⼈が速くなっても組織の成果にならないのか... 個⼈が速くなっても、すぐに壁にぶつかる 例えば、⾃分の仕事が「要件を理解して、コードを書き、レビューを通してマージするまで」なら、速くなるのはそこまでです。 新しい機能を作ろうにも、要件がまとまっていなければ動けないし、デザインが上がらなければ、デザイン待ちで⽌まります。 待ってる間にやれることは沢⼭あります。ただ、多くの場合でそれは最優先で取り組むべき⼀番⼤事なアクションではありませんでした。 © Findy Inc. 7
8. よく引⽤されるお話で、似たようなことが120 年前にも起きていたそう。⼯場に電気が⼊っても、蒸気時代の動⼒軸に合わせた建物と機械の 配置をそのまま使い続けたので⽣産性は上がらず、個別にモーターを配置し、⽣産性を上げるまでに約 40 年かかった（Paul David, 1990） 電気に変わっても、⼯場のレイアウトは 40年 変わらず⽣産性上がらなかった。 AI に変わっても、まだ仕事のレイアウトが変わらず上がってないのが今。 1880年代 蒸気 電化 ── 同じ配置 1920年代 機械ごとに電動化 ★ ▶ AI時代の今、まっさらな状態から役割や業務を作るなら、今のレイアウトもおそらくベストではないはず © Findy Inc. 8
9. ⼯場も、はじめから理想のレイアウトを描けた訳ではありません。⽇々の積み重ねと⼯夫の先に、新しいレイアウトがありました。 今、AI を前提にしたレイアウトに描く必要がある そこに向かって私たちが取り組むことは何か、2 つのアクションをあげました。どちらも⼤事で、どちらかが⽋けても、先に繋がりません。 アクション①（⼈の配置を組み直す） ⼈が、役割の壁を越えられるようにする アクション②（⼯程を組み直す） 個⼈の作業ではなく、AI を⼯程そのものに組み込む ▶ この 2 つを、ファインディ カンファレンス開発チームがどう向き合って⼯夫しているかをご紹介します。 © Findy Inc. 9
10. 02（アクション①） 組織で成果を上げるために、 役割の壁を越えられるようにする © Findy Inc. 10
11. 役割の壁による弊害の形（例 越えられていない、とは具体的にどういう状態か。よくある形を 2 つ。 開発と QA が、はっきり分かれている 企画‧デザイン‧開発が、互いに不可侵 テストは専⾨職の領域で、 開発は中に⼊らない パスを回すだけで、 隣の領域には踏み込まない － 開発が AI で速くなった場合、検証が必要なものがQA に積み上がる － どこかが詰まると、他の⼯程は⼿が空く － 開発は QA 待ちで⽌まり、QA は溢れる（逆も然り） － 待ちの時間は、誰の担当にもなっていない ▶ 個⼈が速くなるほど、線の外にある詰まりのほうが⽬⽴ってきます。 © Findy Inc. 11
12. 役割の壁を越えるために必要な 2 つ ── ① 個⼈が AI を活⽤する 組織の成果を上げる（段階4）前に、まず個⼈が AI を使い倒していること、つまり前述の段階 3 が前提にあります。 AIを使い倒さないと、⾃分のドメインの業務は最適化できない。 その先の発想も、使い倒した⼈からしか出てこない。 AIを器⽤に使って楽をする話ではありません。⾃分の業務で使い倒して、AIを、知⾒を学ぶお話です。 それだけで「出来る事」や「出来るかもしれないこと」への理解が⽇々積み上がります。驚き屋さんの存在も⼤事。 AI活⽤度を数字で⾒て振り返る（/insight など）、ハッカソンでAIへの抵抗感を無くす、 ── そんな仕掛けも効きます。 号令や強引な働きかけでもなく、積極的に試⾏錯誤し、それを共感し活⽤し合う⽂化そのものが、活⽤を促進させます。 © Findy Inc. 11
13. 役割の壁を越えるために必要な 2 つ ── ② 組織が越境を歓迎する 個⼈活⽤の先で、段階 4 への⼊⼝を開けるのは組織側です。（既存の構造が変わることに、誰しも不安もあると思いますが） 組織の意思決定として、既存の役割の線を引き直す事を歓迎する。 それを促せるのは、⾃分で使い倒している⼈だけ。 現場がAIを使えるようになるだけでは役割は動きません。組織の意思決定として越境を促す必要があります。ただし、意思決定者の不理解が あれば期待と実態のズレが⼤きくハリボテになります。組織図に線を引く意思決定者が使い倒しているからこそ、理解の溝が埋まります。 私も過去に「これすぐに開発速度倍に上がっちゃうね！」→「そんな簡単じゃないので、ちゃんと⾃分で触ってください」で怒られました © Findy Inc. 12
14. ...で、前の 2 枚は、「⾃分の業務で AI を使い倒して」「偉い⼈も AI を使って、役割を越えていこうと促して」と⾔っているだけですね （伝えたいこと）読んで分かることと、動かして分かることは違う 繰り返しですが、⼤事なのは、⾃分の⼿を動かして、AI という武器を正しく理解し、応⽤できるようになること。 AI があるからできることはたくさんある。でも、AI があってもできないこともたくさんある。その線引きを、全員が持てるかどうかが⼤事 越境は、AI を勉強しただけでは促せません。 全員が⾃分の業務を通して AI を学び、動かすことです。 偉い⼈（弊社CTO）の⾔葉を借ります。 「⾃作なら、壊れた場所の⾒当がつきますし、 ⾃分の状況に合わせて改善し続けられます」 「つくり直すことが、⾃分にとっての学びだからです」 ファインディ CTO 佐藤 将⾼「⾞輪の再発明こそ、最⾼の学習法」（findy-code.io/media/articles/aisaji-ma3tk） ▶ ⾞輪の再発明こそ、最⾼の学習法。⼤事なのは⾃分で動かして学ぶこと、ぜひ持って帰ってください。 © Findy Inc. 13
15. ①個⼈ と ②組織 が揃うと、詰まりが越境の動きに変わる 使い込むほど⾃分の担当が速くなり、そこで初めて詰まりが⾒える。 そして、その詰まりは⾃分のスコープの外にあります。そこを越えていい、という前提が組織にあれば、そこから隣に⼿を伸ばせます。 © Findy Inc. 14
16. そして、実際に越える動きが⽣まれ、待つ時間が消えた ファインディでは、よく「越境しよう」「染み出そう」と呼びかけます。役割を「変えた」のではなく⾃分たちから⾶び出していきました。 たとえば「抽選機能を作ろう！！」 → 以前は PdM 待ち、デザイン待ち、今は⾃分で聞きに⾏き、⾃分でデザインを組んで進めます。 誰が、どこへ越えたか その結果、何が消えたか － エンジニア － デザイン待ちが、無くなった － PdM → 企画やデザインへ → デザインモックや、営業同⾏へ － デザイナー － 要件を待つのではなく、要件を作り出せるようになった → PM へ etc... © Findy Inc. 15
17. ただし、まだ全員ではない これだけでは、越境も、その成果も、AI を使いこなせる少数派のものになります。 全員が等しく壁にぶつかり、その先の越境を必要に迫られているかというと、そうではありません。まだ 3 つ⽬の段階です。 段階 3 個⼈が活⽤できている 段階 4 組織で活⽤できている 使いこなす⼈が、速い チームの開発が、速い tips. ⼤事なポイントですが、当然越境するには越境先の領域に強くなる必要があります。（明⽇から経営者に染み出してやろう！無理ですよね） 私達の場合は、例えば企画に染み出す場合、LearnUX の読書会やワークショップをチームで実施し、なんちゃって越境にならないよう⾃⼒をつけるよう研鑽してます ▸ では、チーム全体を速くするには ── 個⼈の練度に頼らず、AI を⼯程に埋め込む姿勢について © Findy Inc. 16
18. 03（アクション②） 越境を、⼀部の⼈で終わらせないために、 AI を、⼯程そのものに組み込む © Findy Inc. 17
19. ⼯程に組み込む前に ... そもそも、「AI とは何か」 指⽰者の要求を満たすことを⽬的に動く、⾃然⾔語で会話できる、 桁違いに仕事が速い存在。 疲れず、休まず、朝から晩まで働けます。しかも、分⾝して⾃分を何⼈分にでも増やせます。ご飯は電気 © Findy Inc. 18
20. ただ、たまにこういうことをします 「エラー消しといて」 「消しました！」 © Findy Inc. 19
21. こういうことを繰り返します © Findy Inc. 20
22. ⼈と⼤きく違う特性 ── たとえば、この 3 つ 速い 増やせる 学習しない ★ ⼈の 10 倍、100 倍で動く 同じ資料で、何⼈分にもなる 終われば、何も覚えていない － 私（⼈）はもう、もう追いつけない － 1 つ書けば、100 ⼈分に効く － 毎回、ゼロから渡し直す 毎朝、記憶を失って⽬を覚まし、書き置きを読んで⾃分を理解し直す ── 映画『メメント』の主⼈公と同じです。 ※tips. ⾃動記憶を持たせる仕組みもありますが、多くが個⼈の環境に閉じた話で今回の⽂脈からは省略してます © Findy Inc. 21
23. AI は仕事が速い。しかも、100 体にでも分⾝できる。ただし毎タスクが新⼊社員で、私たちの業務ドメインは何も知らない。 私たちは、AI100 体を動かす頭に切り替える必要がある いまの⾃分は、AI が代替できる 101 ⼈⽬ではないか、 いまの作業は、AI に代替させられないか 100 ⼈を動かす側にまわり、100 ⼈ を動かせるようにする。 だから、仕組みやドキュメントの価値が上がった。 AIに渡すのは、規約、開発フロー、環境構築、踏みやすい罠。資料に限らず、Claude Code なら rules や hooks、skill 等の仕掛けがそのまま効きます。 イライラしても、代わりに作業をやらない。⼈なら背中をみて学びますが、AI は背中を みてくれません。「もういいよ、俺がやる」になったら負けです。 ▶ ⾃分が⼿を出さず、部下が動けるように仕組みを直すのが私たちの仕事 ── ループエンジニアリング（?） © Findy Inc. 22
24. たとえば、こういうものの価値が跳ね上がる 下の例にある3 つとも、なかったのではなくROIが低かっただけです。100⼈で開発量が跳ねると、レバレッジによるROIが激変します デザイン テスト レビュー AI の苦⼿を、先に潰す ガードレールを、強固にする チェックする⼒が、価値になる ── デザインシステムを作る ── シナリオベースの e2e を作る ── この後、詳しく話します － ぶれるのは、難しい判断させているから － ⼈が書く量なら、⽬で気づけた － 作るのは、容易くなった － 型を渡せば、迷わせずに済む － 量が跳ねたら、機械で⽌めるしかない － 難しいのは、確認するほう ▶ 開発量が増えるほど、その品質担保や確認作業が追いつかなくなります。 © Findy Inc. 23
25. みなさんのコードレビューはどうですか 書く速度は上がった。ただ、質が上がったわけではない。 そして、レビューが⼀番の詰まりになった。 たぶん、あるあるだと思っています。 ここからは、この詰まり、レビュー⼯程に対するの取り組みを例にAIを⼯程に組み込む⽅法を紹介します。 © Findy Inc. 24
26. まず、レビューはなくせるのか カンファレンスチームはレビューを無くしていません（今は）。 AI は成果物に責任を持てないので、⼈が責任を持つためです。 AIを信頼しているからと、中⾝を⾒ずに承認するのは危険です。(エラーを消すために PC をぶっ壊す存在ならなおさらです） 信頼できるガードレールを設計したり、重要度をトリアージして、⼈が⾒る範囲を絞るのは良い判断です。ただ、意図も品質も確認しない コードを通せば、すぐさま中⾝はブラックボックスに転じ、責任も取れなければ、メンテもできません。 社内ツールや PoC 前提のバイブコーディングは別ですが、そのコードに責任を持つべきクライアントがいるなら、慎重になるべきです。 © Findy Inc. 25
27. ただ、なくせなくても、 AI をフル活⽤して⼯程の最適化は出来ます 出てきた成果物を「チェックする」ための仕組みとして、CI 上に以下仕掛けを⾏いました。 ① PR 要約を書かせる issue と差分から AI が書く ── ⼈の認知負荷を徹底して下げる ② リスク度を判定させる 作業の性質から AI が判定する ── 1 万円の稟議か、1 億円か ③ AIに⼀次レビューさせる ⾃分たちの規約を読ませたうえで、AI が⼀次レビューする そして、残るのは、⼈の⼆次レビュー 要件‧設計‧意図に沿うか がメイン ── ここだけは、⼈が⾒る ※tips. 前提として、CI の静的解析は厳重に。基本テストを書き、1 PR を最⼩単位にして TDD を徹底しています。 壊れていないかは CI（lint / test）が⾒ます。（最近は gh stack もあるので、PR を分けやすくなりましたね） ▶ ただし ③ のAIの⼀次レビューはどうしたら信頼できるチェック機構になるだろうか、、 © Findy Inc. 26
28. 前提、AI のレビューいまいちだと思いませんか なぜか...AIの能⼒は⾼くても、 このリポジトリの⽂脈も開発におけるドメインの暗黙知も、知らないからです。 同じ⾔葉でも、指しているものが違います。しかも学習しないので、昨⽇あったことは忘れてます。 © Findy Inc. 27
29. だから、そのままではレビューが的外れになる 必要ない指摘が積み上がり、繰り返す。 読むだけで苦痛になり、誰も信頼しなくなる。 では ー AIに読ませる業務資料を書いて読ませればいい ── が、AIがどこまで分かっていて、どこから分かっていないのかが⾒えません。 ▶ これを踏まえて、2 つの⼯夫を⼊れました。 © Findy Inc. 28
30. ドメイン知識を、コードレビューから学ばせます ⾒逃しを⾜す ── 必要な指摘を、増やす 外れを減らす ── いらない指摘を、させない 「⾒逃した指摘があったら、学んで」 「無視された指摘は無価値。学んで」 － merge のたびに 1 回、AIが⾒逃した⼈の指摘を渡す － 週に 1 回、AIのスルーされた指摘をまとめて渡す やることは難しくありません。Claude Code なら、学んだことを rules に書き出させるだけ。GitHub Actions 上に、この 2 つのワークフローを築く だけです。あとは⼆次レビューしてれば⾃動で回り続けます。次の PR から、CI 上のレビューがそれを読んで動きます。 ▶ レビューの当たり外れをルールとして残します。これだけで⽇々のレビューから、⾃動で学びを得ることが出来ます © Findy Inc. 29
31. & その仕組みを、チームの開発環境全部へどう配ってるいるか ロジックは共通リポジトリに書き、composite action として配るだけ。各リポジトリは workflow をコピーして使いたい機能を有効にするだけ # .github/workflows/claude-on-pr.yml jobs: claude: uses: <org>/<shared>/.github/workflows/claude-on-pr.yml@<sha> permissions: {} with: execute_pr_summary: true # PR 要約 execute_risk_check: true # リスク度の判定 execute_review: true # ドメインルールに沿った一次レビュー execute_learn: true # マージ後の学習 secrets: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} ※ アップデートは Dependabot 等に任せられます。改善は共通リポジトリに⼊れるだけで、各リポジトリに PR が届きます。 ▶ 作るのは 1 回、効くのは全リポジトリ。特別な基盤は要らず、全部 GitHub Actions だけで完結します。 © Findy Inc. 30
32. その結果、何が変わったのか AI の⼀次レビューの品質も、⼤きく上がった。 ⼈がレビューで出す指摘は、4 分の 1 に減った。 ⼈がPRに⾏う指摘の数 ── PR 1 件あたり AI がPRに⾏う指摘のうち、実装者が実際に直した割合 1.19件 ▶ 0.29件 34% ▶ 79% やったことは、CI に 4 つのワークフローを⾜したこと。仕込む場所さえ合っていれば、⼩さな⼯夫でも効果はこれだけ⼤きくなります。 ※ 主要 2 リポジトリ、2026年3⽉ → 8⽉。⽉ 300 件超の PR が対象。PR の⼤きさは変わっていません。 © Findy Inc. 31
33. AI を当てたのは、レビューではなく、チームのレビュー⼯程 同じレビューでも、当てる先で効き⽅が変わります。私達が当てたのは、チームが詰まっていたレビューという⼯程です。 ⼈に当てる ⼯程に当てる レビューする⼈が、 AI を使って丁寧に⾒る レビューという⼯程に、 AI を組み込む － 使う⼈と使わない⼈で、差が出る － 要約とリスク判定が、先に付いてくる － 読み解くところから始まるのは、変わらない － 全員のレビューが、同じ前提から始まる － その⼈が抜けたら、元に戻る － ⼈に残るのは、要件‧設計‧意図の確認がメイン ▶ チーム全員が通るレビュー⼯程、レビュー‧レビュアーの双⽅と全員に効きます © Findy Inc. 32
34. まとめ 個⼈で AI をぶん回すことはできる。ただ、それだけでは上限が⾒える。 いい意味で「AI 活⽤格差」をなくしましょう 120 年前、彼らは⼯場のレイアウトを変えました。私たちが変えるのは、仕事のレイアウト ── つまり、やり⽅です。 AI は個⼈の作業ではなく、チームが抱えている業務に当てる。仕組みづくりは⼤変ですが、その分レバレッジが効きます。 越えるのは ⼈ 後押しするのは 組織 変えるのは やり⽅ © Findy Inc. 33
35. 最後に、今後は役割も求められることも⼤きく変わります その先で私たちが出せる成果は確実に⾶躍します。 プロダクトをつくる⼈から、つくる仕組みをつくる⼈へ。要件を理解する⼈から、より根源的なニーズに向き合える⼈へ。 つくる速さが⼿に⼊れば、これまで腕の数が⾜りなくてできなかったことにも⼿が届きます。もっと⼤きな成果に、挑みにいけます。 AI のある / なしの分岐点、これだけのブレイクスルーは、そう多くありません。 © Findy Inc. 34
36. TAKEAWAY AI 活⽤を、 ⼀部の⼈で終わらせない。 個⼈が AI を使い倒し、組織が構造の変化を促す。⽇々の研鑽がレイアウトを変え、 その積み上げによる構造の変化が、組織の成果に繋がるはずです。 40 年の歳⽉を、⼀⾜⾶びに越えることはできません。ただ、そこへ向かって歩むことを意識して、 ⽬の前の業務に⽴ち向かっていただければ幸いです。 ご清聴ありがとうございました。 © Findy Inc. 35