Claude Codeを推進したのに使ってくれない… うまくいかない原因と今後の進め方

2026/07/03 QiitaBash 登壇資料です。

Transcript

1. Claude Codeを推進したのに使ってくれない… うまくいかない原因と今後の進め⽅ くらっち ピーディーシー株式会社 システム開発部
2. 2 ⾃⼰紹介 くらっち • ピーディーシー株式会社 システム開発部（デジタルサイネージソリューション） • 普段は Ruby on Rails アプリケーションエンジニア / QA エンジニア として勤務 • JAWS-UG 東京⽀部 運営メンバー（AWSのユーザーグループ） Qiita Bashへの登壇は通算4回⽬です
3. 問い: Claude Codeを推進する理由はなんですか︖ 3
4. 効率化︖質の向上︖ 4
5. ⾃分は「会社の利益のため」だと考えたいです。 5
6. 6 背景︓最初は⼀部しか使えていなかった • 今年1⽉から、少しずつClaude Codeを導⼊ • でも、最初から開発メンバー全員が使いこなせたわけじゃない • 実際に使いこなせていたのは、私を含む「⼀部のメンバー」だけ そこから部内に広げる活動をしてきた中での「気づき」を話します
7. 7 ⼈が新しいツールを使う動機とは︖ 動機は⼤きく分けて2つあると考えています 能動的 好奇⼼・興味 「やってみたい」という⼼理から 受動的 課題・問題への対処 「やらざるを得ない」という⼼理から
8. 8 推進しやすいのは「受動的（Issue Driven）」 • きっかけ作りが簡単で、部内に広めやすいのは受動的な⽅ • 課題が起点なので、推進する側もアプローチしやすい でも、それだと危機感が募るばかり…
9. 9 能動的に推進して、私がぶつかった2つの壁 壁 1 アナウンス・プレゼンをして 知識を"渡して"も、動かない 壁 2 ツール（使える環境）を "渡して"も、使わない 共通点 = どちらも「何かを渡したのに、⼈が動かなかった」
10. 10 壁1︓アナウンス・プレゼンをして知識を渡しても動かない • 聞いて⾃分でインストールして使う⼈は、ほんの⼀握り • その層はSNSなどの情報から、すでに⾃分で触り始めている アナウンス・プレゼンをして知識を"渡す"だけでは、⾏動は変わらない
11. 11 壁2︓ツール（使える環境）を渡しても使わない • 環境を渡しても、興味がない⼈や課題がない⼈は使わない • ⾃分たちは⾃⼒で環境作りながら使っているから気づきにくいけど、 環境があったとしても使わない⼈の⽅が多いはず 理由はシンプルで 今、使わなきゃいけないほどの課題・問題に直⾯していないから
12. 12 実際にやったこと︓インストールハンズオン & ⾃作プラグインの展開 • Claude Codeインストールのハンズオンを実施 • 開発部の業務で共通して活⽤できそうな Skills/Hooks を整備し、 Gitリポジトリに「⾃作プラグイン」として配置し、開発部内に展開 インストール&環境整備を⾏ったとしても、課題に直⾯していないから使わない
13. ここまでのアクション、 ⽬的が「Claude Codeを推進すること」になっていたのにお気づきでしょうか 13
14. 反省… 14 • これまでの⾏動は、いつのまにか「Claude Codeを推進すること」⾃体が⽬的になっていた • 本来の⽬的は、課題を解決して会社の利益につなげること • ツールはあくまでも⼿段でしかない Claude Codeの推進うんぬんの前に、 会社の利益に繋げるために、「伸ばすべき強み」と「解決すべき課題」を考え、 理想的な業務フロー・開発フローを再設計する必要がある
15. 15 AI BPRの原則で、フローを再設計する 1⼯程だけ・個⼈だけの導⼊では効率化に限界がある。 業務・開発フローを丸ごとAIエージェント前提に再設計する。 ① 強み起点 「どの強み・価値を伸ばすか」から始める （問題解決 < 可能性増幅） ② ⼼理的安全なロールシフト 実⾏ を AI に委譲し、 ⼈間は 指⽰設計・評価 へシフト ③ 即時フィードバック AIとの対話で成果物をその場で作り、 認識のズレを即修正する 「強み起点」で、業務・開発フローを丸ごと作り直すのが AI BPR
16. 16 まず洗い出す︓「伸ばすべき強み」と「解決すべき課題」 現状を観察し、強み → 課題 の順でマッピングする（AI BPR の Observe） 伸ばすべき強み • 今うまくいっている⼯程 • 顧客価値を⽣んでいる⼯程 • まず"強み"から掘り下げる （"変えられない"防衛反応を避ける） 解決すべき課題 • リリースの度に、設計の考慮漏れによるバグが出る • 実装に時間がかかり、予定どおりに出せない 課題からでなく "強み" から始めるのが AI BPR の流儀
17. 17 理想の業務フロー・開発フローを再設計する 実⾏ を AI に委譲し、⼈間は 指⽰計画 / 評価 へ ── 開発が要る部分は AI-DLC で実装する AI-DLC AI-Driven Development Lifecycle • 対象︓ソフトウェア開発フロー • AIが計画 → ⼈間が承認 → 実装 を全⼯程で⾼速 反復 • Inception → Construction → Operations AI BPR AI-driven Business Process Re-engineering • 対象︓業務プロセスそのもの • Do を AI に委譲、⼈間は Plan / See へシフト • Observe → Shift → Simulate → Forecast 共通する思想 AIが主導し、⼈間が意思決定 / 改造ではなく第⼀原理から再構想 / 時間を劇的に圧縮
18. 18 理想フローの中で、Claude Codeは"適切な場所"で⾃然に使われる 「使わせよう」としたから浸透に苦労した ── 順番が逆だった ✕ これまで ツールを配って「使ってもらおう」とする → 動かない・使われない ◦ これから フローを再設計する → 必要な⼯程でツールが「⾃然に使われる」 「使わせる」のではなく、「⾃然に使われる」フロー・プロセスをつくる
19. まとめ 「推進」⾃体が⽬的に なっていた → 渡しても動かない ⽬的に⽴ち返る 強み・課題からフロー再設計 (AI BPR / AI-DLC) ツールが"適切な場所"で ⾃然に使われる → → 「使わせる」より、「⾃然に使われるフロー」を作るべし ツール推進は⽬的じゃない。⽬的は会社の利益︕ フローの構築が正しくできれば、ツールは⾃然についてくる
20. AI-DLC ・ AI BPR についてはこちらをご参照くださいませ︕ AWS AI-DLC 記事 AWS AI BPR 記事