方針は示し、あとは現場 ── 個人の工夫を組織の資産に変えるカンリーの3つの標準化

セーフィー × カンリー AI Night #2：AI開発における社内標準化の取り組み登壇時の資料です
https://canly.connpass.com/event/397617/

Transcript

1. 方針は示し、あとは現場 SA F I E × C A N LY A I N I G H T # 2 ── 個人の工夫を組織の資産に変えるカンリーの3つの標準化 Copyright © Canly, Inc. All rights reserved. 株式会社カンリー 福田 龍 ／ 2026.08.05
2. 自己紹介 福田 龍（ふくだ りゅう） 株式会社カンリー エンジニア本部 CTO室 エンジニアリングオフィス 自社開発の Web エンジニアとして10年以上従事し、マネジメントの傍ら MBA を取得 2025年8月 カンリー入社 Claude Code を中心とした AI 駆動開発の手法をキャッチアップし社内外に広めつつ、AI 時代におけるエ ンジニア評価制度の検討、技術広報方針の策定、採用フロー整備等、エンジニア組織戦略と実働全般を 担う X や Zenn・Qiita、外部登壇 で AI 駆動開発の話を発信し ています 前回（2026/6）: 個人最適から全体最適へ アーカイブはこちらから Copyright © Canly, Inc. All rights reserved. 02
3. 標準化には、得るものと失うものが両方ある 完全自由 標準化が弱い 共通設定 何のために標準化するのか 推奨ツール ツール一本化 揃えることで得るもの 揃えることで失うもの 他の人が作ったものが、自分の環境でも動く 作り込みの投資先が分散しない 使われ方を横で比べられる 現場ごとの試行錯誤の幅 個別最適の余地 決められた側の納得感 使い方統制 標準化が強い 両方あるから、やるかやらないかではなく どこまで標準化するか の話になる 今日話すこと： どこに線を引いたか・なぜそこにしたか・線の先をどうしたか Copyright © Canly, Inc. All rights reserved. 03
4. 標準化の範囲を広げた理由 ── 個別最適のままでは進まない 何のために標準化するのか 理由 1 理由 2 理由 3 理由 4 伸びるのは作り込んだ人の手元だ け。リードタイムは一番遅い工程 で決まるため、個人の高速化がプ ロダクトの速さにつながらない。 ハーネス（CLAUDE.md・スキ ル・フック等、AIが自走するため の環境）は作り込めば効くが、各 所で同じものが重複して生まれ る。かけた分だけ伸びしろを捨て ている。 工夫も失敗例も各自の手元とチー ム内に留まる。探すコストが高す ぎて、結局自分で作る方が早いと いう状態になる。 学習に週数時間を充てる、部署間 連携を前提にAI中心の進め方へ切 り替える。こういったことは現場 の工夫だけでは動かない。 個人最適の限界 → 全体で上げる 車輪の再発明 → 重複を減らす ナレッジの分散 → 集めて見せる 現場で決まらない → 上から決める 個別最適の合計では、開発生産性は上がらなかった ── だから標準化の範囲を広げた Copyright © Canly, Inc. All rights reserved. 04
5. 扱う対象が、1回の対話から組織の環境そのものへ広がってきている person 個人が主体 プロンプト エンジニアリング うまく頼む › コンテキスト エンジニアリング 文脈を渡す › 何のために標準化するのか groups 組織が主体 ── 今日の話はここ これから ハーネス グラフ エンジニアリング 環境を整える › ループ エンジニアリング 回して直す 1回の対話 › エンジニアリング 全体を繋ぐ 組織の環境そのもの 今日の3つは、この線の上の どこを揃えたか という話 Copyright © Canly, Inc. All rights reserved. 05
6. 標準化する条件は1つだけ 標準化で失いかけるもの 試行錯誤の幅 納得感は、対話で残せる 何のために標準化するのか ＜ 資産化・投資集中・観測 揃えて得るもの トレードオフはゼロにできない。認識して、言語化して、受け入れる 標準化は自由を奪う統制ではなく、AIの効果を個人止まりにしないための装置 Copyright © Canly, Inc. All rights reserved. 06
7. 「使っているか」は、最初から論点ではなかった コーディングエージェント メイン利用 95% 個人最適期 1年間ほぼ水平。ここは伸びしろではなかった 期初から、何らかのコーディングエージェントをメイン利用。詰まっていたのは別の場所だった 詰まっていたのはこの 3 つ ── 今日の 3 つはこれに 1 対 1 で対応する 01 02 03 → 標準化1：プラグイン → 標準化2：ツール → 標準化3：開発ライフサイクル 作り込んだ CLAUDE.md・スキル・ フックが個人の中で止まる ツール併存で、ハーネスの作り込み 先も観測も分散 Copyright © Canly, Inc. All rights reserved. ワークフロー自体がチームごとに人 間中心のまま 07
8. 標準化1：プラグイン STANDARDIZATION 1 / 3 個人の作り込みを、配れる形にする 01 02 03 共通の置き場と品質基準を用意し、工夫 を配れる形にする ハーネス投資と観測を寄せる先を、1つに 決める 進め方の型を、全員で共有する プラグイン ツール Copyright © Canly, Inc. All rights reserved. 開発ライフサイクル 08
9. 使いこなす人ほど、属人化が進む 標準化1 · プラグイン 個人 作り込むほど 個人の生産性は上がる trending_up 組織 CLAUDE.md・スキル・フックを 自分の環境に積み上げる ✕ 組織には 何も残らない block 置き場も基準もないので、 横に渡す経路がない 上手い人が伸びるほど差が開き、その差はどこにも共有されない Copyright © Canly, Inc. All rights reserved. 09
10. 用意したのは、共通の置き場と品質基準 標準化1 · プラグイン 失うもの ほぼ無し ／ 得るもの 工夫が横展開できる資産になる ── 式が最も成立しやすい「配布経路」から手をつけた 2025/10/10 プラグイン機能が公開された、 その日に社内マーケットプレイ スのリポジトリを作成 当時は品質基盤も運用ルールもな い置き場 2026/4 2026/1 CI・自動検証基盤を集中投入 ＝ 実質的な運用開始 正式配布と育成領域を分離 plugins/ と sandbox/ ── ここから 伸びる 現在 登録 26件 正式14 ＋ sandbox 11 ＋ 外部OSS 1 作る中身は現場に任せ、AI共有会・AIギルド・QuickWinTime という共有する場も用意した Copyright © Canly, Inc. All rights reserved. 10
11. 工夫は、個人からエンジニア全体へ4段階で昇格させる ── grill-me の例 01 個人 置き場 ホームディレクトリ（個人設定） または sandbox/ 上がるきっかけ 自分の手元で繰り返し使えている 02 チーム 置き場 sandbox/（プロジェクト設定から 参照） 上がるきっかけ 週3時間の固定枠で布教し、チーム 内で定着 昇格前（〜2026/7/5）は、同じ grill-me が5か所の置き場に散らばっていた grill-me は OSS のスキルで、誰かが全社に広めたわけでなく各所で自然に使わ れはじめていた。共通マーケットプレイス経由の利用はゼロ 03 複数チーム 置き場 標準化1 · プラグイン 04 正式配布 sandbox/（他チームからも参照） 置き場 共通マケプレ plugins/ 上がるきっかけ 共有会・ギルドを経て他チームで も使われる 自然には上がってこない段 だから利用ログで使われ方を見 て、候補を見つけて上げる 昇格後（2026/7/6〜） grill-me の呼び出し 153回のうち 83回が共 通マーケットプレイス経由になり、置き場がバラけていた利用が1 か所に集まった。使う人は 16名 → 22名 Copyright © Canly, Inc. All rights reserved. 11
12. 配る経路は作れた。次は、段を上げる動きを仕組みにする 渡せる形にできたものは、段を上がった 「日常的に利用している」以上を選んだ人の割合（四半期の全員調査・ 計4回） 100 50 49% スキル 0% 16% 25/11-12 86 81 70 MCP サブエージェント 26/01-02 26/05 標準化1 · プラグイン 今後の課題 ── 次の段へトスアップさせていく 個人に閉じているもの → チームへ 手元で回っている工夫を、チ ームの sandbox/ に乗せる チームに閉じているもの → 複数チームへ 共有会・ギルドで他チ ームに渡る状態にする 候補の拾い上げはログからできる 拾ったあとに磨いて上げる動 きが、まだ人に依存している 26/07 設定ファイル1本で渡せるものほど伸びが大きい（スキル +65pt・サブエ ージェント +54pt・MCP +37pt） 今は sandbox/ に置いたまま止まっているものが多い 線を引いたのは 配る経路まで。次は、個人→チーム→複数チームと 段を上げる動きを仕組みにする ファイル1本で渡せるものは、経路に乗せれば届いた（スキル 16 → 81%）。ファイルにならない工夫は、まだ人に付いている Copyright © Canly, Inc. All rights reserved. 12
13. 標準化2：ツール STANDARDIZATION 2 / 3 投資と観測を、寄せる先を決める 01 02 03 共通の置き場と品質基準を用意し、工夫 を配れる形にする ハーネス投資と観測を寄せる先を、1つに 決める 進め方の型を、全員で共有する プラグイン ツール Copyright © Canly, Inc. All rights reserved. 開発ライフサイクル 13
14. ハーネス投資も観測も、2つに割れていた 標準化2 · ツール ハーネスの作り込み ／ 利用の観測 ── 投資先が Claude Code と Cursor に分岐したまま メイン利用の内訳（ 2 0 2 5 / 1 2 社内調査 · n = 全エンジニア） Claude Code のみ 37% Claude Code をメイン利用 58% Claude Code CLI / ターミナル型 CLAUDE.md・スキル・フックの作り込み先 ① 利用ログの観測基盤 ① 両方 21% Cursor のみ 42% Cursor をメイン利用 63% Cursor エディタ統合型 設定の作り込み先 ② 利用ログの観測基盤 ② 投資も観測も、半分ずつに割れていた Copyright © Canly, Inc. All rights reserved. 14
15. 決めたのではなく、自然と Claude Code 一強になっていた 標準化2 · ツール 決定の年表 98% 95% 2025/11 Claude Code に寄せる統一案は初期から出ていたが、利用実 態が割れており決め手に欠け、決定せず Claude Code 63% 65% 58% 56% 交差 2026/2 2026/6 社内のメイン利用が逆転 Cursor 正式廃止 2026/4 Cursor 2025/12 ギルドで各チームの温度感を先にヒアリング。当初2チームが 反対、個別に状況を聞いて解消 7% 2026/1末-2初 2026/5 2026/7 Claude Code が増えるのと同時に Cursor が減った ── 併用ではなく乗り換えが起き 2026/6 正式アナウンス ていた 組織が決めて現場が動いたのではなく、現場が動いたのを見て組織が決めた Copyright © Canly, Inc. All rights reserved. 15
16. そして今、Codexを入れた 標準化2 · ツール 一本化した › ナレッジが1か所に集約 › 2〜5理解レベルが一気に上がった 月で スキル 37→76%・MCP 51→88% › なのに今、Codex を追加 ── なぜまた増やす？ 3 つの前提 立ち位置 Codex はあくまでサブ用途。メインを置き 換えるものではない Cursor のとき 主従を決めずに並存 → 投資と観測が分散して半年 デファクト変化への備え 将来的にデファクトが変わる可能性がある ため、どちらも触れる環境を残す メインは変えない サブスクでコストメリットがあり、ナレッ ジとハーネスも揃う Claude Code をメイン とする方針は維持 Codex のとき 主従を先に宣言してから配った 今度は、方針を先に示した。線を引いたのは 投資を寄せる先 までで、何を試すか・どう使うかは現場に残した Copyright © Canly, Inc. All rights reserved. 16
17. 標準化3：開発ライフサイクル STANDARDIZATION 3 / 3 進め方そのものの型を揃える 01 02 03 共通の置き場と品質基準を用意し、工夫 を配れる形にする ハーネス投資と観測を寄せる先を、1つに 決める 進め方の型を、全員で共有する プラグイン ツール Copyright © Canly, Inc. All rights reserved. 開発ライフサイクル 17
18. 個人は速くなったが、進め方は人間中心のまま 要件定義 速くなった › 設計 速くなった › 実装 速くなった 工程ごとは速くなった。 それでも 誰が何をどの順でやるか という形は、AIの前と 同じまま ・スクラムがメイン。スプリントという単位もスクラムイベントも、AI の前と同じまま ・人が書いたチケットを人がレビューする前提のままだから、待ちが消 えない ・工程間の引き継ぎは人の口頭・文書で、AIに渡る文脈が毎回途切れる ・部署間連携を前提にした進め方は、チーム単位では変えられない 標準化3 · 開発ライフサイクル › テスト 速くなった › レビュー 速くなった AI-DLC （AI-Driven Development Life Cycle） AWS が提唱する、AIを主担当に据えて開発ライフサイクル全体を 組み直すフレームワーク。人が書いてAIが手伝うのでなく、AIが 進めて人が向きを決める Mob Elaboration 要件をチーム全員でAIと対話しながら具体化する Mob Construction 実装も全員でAIと進め、成果物をその場で検証 する Bolt 単位の反復 スプリントでなく数時間〜数日の短い周期で回す 今必要なのは工程ごとの高速化でなく、進め方そのものの作り直し Copyright © Canly, Inc. All rights reserved. 18
19. 守破離の「守」だけは、業務を止めて全員でやった 2025/11 本部全体としてAI-DLCへの転 換方針を決定 失うもの チーム固有の進め方の一部 2025/12 2026/2 全体向け勉強会 先遣隊4名がAWSのワークショ ップへ 標準化3 · 開発ライフサイクル 2026/4 PdM7名・エンジニア26名の合 同ワークショップ 2日間・業務を止めて 得るもの 未来から逆算した、AI中心の開発ワークフロー 当初は先行チームで守破離まで作り込む構想だった。マルチプロダクトで一律は無理と判断し、「守」＝全員で体験 ／ 「破離」＝各 チームの現場 に切り替えた Copyright © Canly, Inc. All rights reserved. 19
20. 型は配ったが、使わない判断も現場に任せた 標準化3 · 開発ライフサイクル 実務に乗ったチーム PBI作成前の Intent言語化をPdMと同席してやる形（モブエラボレーション）が回りはじめ、仕様策定の背景や用語定義の曖昧さを先に詰め られるようになった AI-DLC各フェーズをつなぐスキル群を整備し、実PBIで運用する段階へ 適用を一旦見送ったチーム（2026/7） 理由：進捗の手応えが薄い ／ 優先度の高い案件が続き時間確保が難しい ／ チーム規模・フェーズとフレームワークが合わない 個人レベルのAI活用は継続。完全撤退ではない ギルドの所感：失敗というより、適用条件や限界を見極める知見 揃えたのは型まで。使うかどうかは、現場が決めている Copyright © Canly, Inc. All rights reserved. 20
21. 決めるのに、何が必要だったか CHAPTER 6 3つの標準化の背後に、共通してあったもの Copyright © Canly, Inc. All rights reserved. 21
22. 決める前に、材料が集まる仕組みを置いていた 横断組織が 置いたもの 場 AI共有会・AIギルド そこから 出てきたもの 工夫 プラグイン・スキル その材料の 上で決めた 世の中の流れ 決めるのに、何が必要だったか 時間 週3時間の固定枠 ▼ 実態 何に困っているか ▼ 経営視点 物差し 四半期の全員調査・テレメト リ 成長 追跡した23名全員が伸びた （1.61 → 2.36） 方針の明示 方針を決められたのは、現場の創意工夫と成長が材料になったから ── 組織はそれが集まる場・時間・物差しを置いただけ 例：④ツール一本化も、四半期調査とテレメトリがあったから決められた Copyright © Canly, Inc. All rights reserved. 22
23. 残っている課題は3つ 模索していくこと 01 全員伸びたのに、習熟のばらつきは広がった 習熟度（4点満点） これから層25% 0.90 → 1.28 ／ 先行層 25% 2.33 → 2.88 差 1.43 → 1.60 先行層の型が流通していない 02 AI-DLC は「触った」まで。日常にはなっていない 触った以上 16 → 84% ／ 日常利用は 2 → 30% 月の 実行 万回・プラグイン読込 万回。量は増え 03 配ったスキルが、切れないオーバーヘッドになっていた たが、量は成果ではなかった 7 Hook 58.7 25.0 いずれも、手順を当てれば片付く種類の問題ではない Copyright © Canly, Inc. All rights reserved. 23
24. AI駆動開発は「複雑」な領域 ── 答えを探すのでなく、探りながら進む 模索していくこと クネビン・フレームワークの 4 領域 ── A I 駆動開発は「煩雑」と「複雑」にまたがる だから、こう進めている 複雑 Complex AI-DLC など、まだ型のない部分 探索 ▶ 把握 ▶ 対応／探索して得たプラ クティス 煩雑 Complicated 従来の開発のプラクティスで解ける部分 把握 ▶ 分析 ▶ 対応／グッドプラクティ ス 無秩序 Disorder どの領域か未判定の状態 カオス Chaotic 因果が見えない 行動 ▶ 把握 ▶ 対応／新規のプラクティ ス 走りながら決める 世の中の変化と社内の状況を見ながら、方針を柔軟に意思 決定する 現場で試す 小さく試行錯誤して、効いたやり方だけを型として残す 単純 Simple 因果が誰にでも見える 把握 ▶ 分類 ▶ 対応／ベストプラクティ ス 決め直すことを前提にする 材料が変われば方針も変える。一度決めたことを固定しな い AI駆動開発はすべてが未知ではない。従来のベストプラクティスが効くところと、自分たちで探索するところを分ける Copyright © Canly, Inc. All rights reserved. 24
25. まとめ まとめ 標準化は自由を奪う統制ではなく、AIの効果を個人止まりにしないための装置 ただし 失うもの ＜ 得るもの が成立した単位からしか標準化しない。方針は示すが、その先は現場に残す 3つとも、判断も決め方も違った。共通していたのは毎回同じ式で考えたことと、決める前に材料が集まる仕組みを置いていたこと もし何も標準化しないままだったら ── 工夫は個人の中で消え、ハーネス投資は分散し、観測できないまま費用だけが膨らんでいた 標準化は一度決めて終わりでなく、線を引き直し続けることでした 材料を集めて、線を引いて、その先は現場に残す。そのために必要だったのは、AIの知識だけではありませんでした Copyright © Canly, Inc. All rights reserved. 25