🎶

Claude Code導入3ヶ月後の社内アンケートから分かったこと

resqnet

2025/10/23に公開

 背景と目的Claude Code が ver.1.0.0 になってから 5 ヶ月、弊社が全エンジニアに展開してから 3 ヶ月が経過しました。
その中で生産性が上がった人とそうでない人が明確に分かれていたり、新たな大変さが生まれてフラストレーションも多く抱えています。
Web 開発の現場で LLM 開発を導入することで何に困るのか明確にして次の施策につなげたいと考え、定性・定量の両面からチーム全体の実態調査をしました。
これから LLM 導入を考えている、導入後どうしたらいいか悩んでいる人の参考になれば幸いです。

 結論の概要調査で見えてきたのは、「生産性は確実に上がっている一方で、精神面や学習面での課題も存在している」 という現実でした。
導入後、プロダクト Issue の対応数は目に見えて増加し生産性は向上したように見えます。
しかし定性意見では、プラス面ばかりではなくマイナス面も見える結果となりました。

満足度はそれなり：満足度 3.8 点（5 点満点）。圧倒的ではないものの、現実的な期待値に落ち着いている

生産性向上を実感している：83%が生産性向上を実感、66%が 1 日 1〜2 時間の時間短縮を達成

新しい疲れが出現した：並列作業によるストレス増を 83%、疲労感の増加を 42%が報告

チーム・組織レベルの支援が求められている：67%がチーム内での経験や課題を共有する場を求めている
LLM を利用したことでプロダクト開発指標の伸びと現場エンジニアの感覚にはズレがありそうです。

詳しく見ていきます。

 調査の概要
対象：社内開発チーム 12 名

期間：2025 年 7〜9 月（実使用 3 ヶ月間を対象）

使用頻度：毎日利用 67%、週数回 25%、時々 8%

方法：22 項目アンケート＋自由記述

 Claude Codeへの満足度：平均3.8点（5点満点）
低くはないものの圧倒的でもない数値です。

「現実的な期待値に落ち着いた」という印象を受けました。

 一方で生産性の実感は感じている
利用したメンバーの 83%が生産性向上を実感 66%が 1 日 1〜2 時間の時間短縮を達成。

でも、満足感はまぁまぁという現実です。

 アンケートで見えてきた新たな課題
 新たなストレス
 並列作業による認知過多

66.7%（8人）が「並列作業が増えた」 と回答がありました。
そのうちコンテキストスイッチによる負荷を感じている人が大半でした。
「非常に負荷が大きい」10%（1 人）
「多少負荷がある」71.4%（5 人）
Claude Code を使うとタスクが同時進行できる分、複数の文脈を行き来する認知負荷が増え「AI が作業を分担してくれる」というより「AI と一緒に複数の作業を抱えるようになった」という事例が増えました。Claude Code が自走してくれる範囲は与えたプロンプトの範囲に依存するため現在の精度で効率よく使おうとすると小規模から中規模の指示を与えがちかと思います、これにより待ち時間を有効活用するために複数ブランチを跨いで行う作業が増えた様です。

 疲労感の増加「疲労感が増えた」42%（5 人）
「ストレスが増えた」25%（3 人）
時間短縮できているが、疲労感が増えるという結果になりました。
1. 「張り付き疲れ」最も印象的だった声です。
「Sonnetだと今のところ張り付いてあげる必要があって、中途半端な待ち時間が繰り返されると結構しんどさを感じる」
並列作業ができるようになった一方で、「AIを見守る時間」という新しい待機時間が生まれていました。
2. 「思った通りにならない」ストレス複数の開発者から同様の声が上がっています。
「Claude Code で期待するコードが生成されず自前実装してしまうことが多々ある」

「全部任せるにはまだ工夫がいる」

「とても楽なのはそうだが、まだ試行錯誤フェーズなので、トータルとして時間を節約出来ているかは正直まだ分からない」
期待値と現実のギャップが 試行錯誤のループを生んでいます。

このループが「時間短縮できているのか分からない」という感覚につながっていました。
ClaudeCode利用時の課題生成されるコードの品質にばらつきがある（66.7%・8 人）
プロジェクト固有のルール・スタイルに非対応（50%・6 人）
料金・使用量の管理が難しい（33%・4 人）
セットアップや設定が複雑（33%・4 人）
予想はついていましたが「品質のばらつき」は多くの開発者が挙げていました。

"だいたい正しいけど、どこか違う" という微妙なズレが、レビュー工数を増やしたり、試行錯誤を繰り返す要因になっています。

 なんとなくうまく使えていない気がする新しい技術ということもあり多くの開発者が「上手く活用できているのかわからない」というモヤっと感の中進んでいることもわかりました。

またキャッチアップする時間が必要であったり、試行錯誤する時間が発生していました。

 開発者のリアルな声「課題を倒すためには活用できているが、自分の使い方をより詳しい人が見たらこの方が効率がよいと突っ込まれる気がなんとなくする」

― バックエンド開発者（満足度5）
「単純な使い方しかできていないと感じている。ドキュメントやZenn等に投稿された記事を見ると把握すらできていなかった使い方がたくさんあるが、それもイマイチ自分の環境に取り込めていない」

― フロントエンド開発者（満足度4）
満足度 5 点をつけた人でさえ「もっと効率的な使い方があるはず」という意見を持っていました。

 一方でアンケートで伺えたポジティブな側面
 生産性向上の実感まず一番わかりやすい変化として、83%（10人）が生産性向上を実感しています。

内訳は「非常にそうである」が 25%、「そうである」が 58%でした。
時間短縮効果も大きく 66%（8人）が1日1〜2時間の削減を達成。

これは LLM を利用した他社の事例と比べても遜色ない結果でした。

（参考：Microsoft 導入事例｜日立製作所）

 使われ方が広いClaude Code はコード生成だけでなく開発の様々な場面で活用されていました（複数回答可）
特に印象的だったのは Git 操作や PR 作成での活用が半数以上だったことです。
コード生成だけでなく、開発フロー全体のアシスタントとして機能していることがわかりました。

 繰り返し作業の負担の軽減認知過多とは別の軸では負担軽減にも繋がっていそうです。
繰り返し作業における精神的負担が軽減された（75%・9 人）
コーディング時のイライラが軽減された（25%・3 人）
作業への集中状態に入りやすくなった（25%・3 人）
単純作業や定型作業から解放され、本質的な部分へ集中できるようになったという声が多数ありました。

 導入後に効きそうなアクションこれらの課題に対して開発者が求めている対策をヒアリングした結果、明確な傾向が見えてきました。

チーム内での経験・課題共有の場(67%・8 人)

AI活用による負荷増への理解・配慮(67%・8 人)

並列作業スキルに関する研修・サポート・作業負荷への適切な調整(25%・3 人)
圧倒的に多かったのは「チーム内での経験・課題共有の場」「AI 活用による負荷増への理解・配慮」でした、キャッチアップが必要と思われる技術を実務があるなかで効率よく学ぶための場は組織的に作っていく必要があると思います。これらは個人の問題というよりベストプラクティスがまだ確立されていない過渡期ならではの課題です。
これらを踏まえ、導入後に実施すべき具体的なアクションをまとめました。

 1. チーム共有会を開催する対象課題:「使いこなしへの不安」「単純な使い方しかできていない」の払拭やキャッチアップの場を用意する。
この施策は最も要望が多かった内容となります、気付いたことレベルや実践で良かったことを気軽にシェアできる環境が必要です。

開催頻度: エンジニア定例のトピックや必要に応じて都度開催

共有内容:
成功事例・失敗事例の共有
「こういう時はこう使う」のノウハウ横展開
「こういう時は使わない方が速い」の判断基準共有
つまづいたポイントとその解決方法
モブプロや勉強会を開催するなど

個人で試行錯誤するのではなく、チーム全体でナレッジを蓄積することで「使いこなしへの不安」を解消を目指します。

 2. プロジェクト固有のベストプラクティスを整備する対象課題:「なんとなくうまく使えていない」不安、生成コードの品質ばらつきを減らしていく。
チーム標準を明文化することでスキル格差を縮めます。

よくあるユースケース集を作成する
新機能実装、バグ修正、リファクタリングなど、タスク別の効果的な使い方


「このタスクにはこの使い方」ガイドを作る
タスクの粒度や複雑さに応じた使い分けの基準


プロジェクト固有のルール・コーディング規約を明文化する
Claude Code に伝えるべきコンテキスト情報をドキュメント化
生成コードの品質を安定させるための前提条件を整理

これらは最初から完璧である必要はなく、共有会で出た知見を随時追加していく形で育てます。

 3. 新たな負荷があることを前提に作業設計と1on1を実施する対象課題:「新しい疲れ」(並列作業によるストレス、張り付き疲れ)
エンジニアの半数が並列作業によるストレス増を報告しており、組織としての理解と配慮が必要だと感じます。
作業設計の見直し:

並列作業の粒度を調整する - 一度に抱えるタスク数の上限を意識

集中タイムを確保する - コンテキストスイッチを減らす時間帯を設ける

「待ち時間」の有効活用方法を共有する - 張り付き疲れへの対処
1on1での確認事項:

「AIによる効率化=楽になる」ではないという認識を持つ
並列作業や認知負荷の増加を感じていないか確認
適切な作業負荷になっているか定期的にチェック
疲労感やストレスの増加を早期にキャッチ
効果が出ているからこそ、その裏にある負荷を見落とさないようマネージャーは意識することが大事です。

 4. 四半期ごとに定性意見を取得する対象課題: 継続的な改善、新たな課題の早期発見。
LLM ツールは急速に進化しており、使い方や課題も変化していきます。

四半期ごとにアンケートを実施
満足度、生産性、ストレス度などの定量評価
自由記述での定性意見収集


新しい課題が出ていないかチェック
ツールのアップデートによる変化
チームの習熟度に応じた新たな課題


施策の効果を測定し改善する
共有会やベストプラクティスが機能しているか
負荷軽減施策が効果を上げているか

定期的なフィードバックループを回すことで、継続的に改善していきます。

 まとめ
 LLM導入の効果は確かにあった83%が生産性向上を実感
66%が 1 日 1〜2 時間の時間短縮を達成
Git 操作・PR 作成まで広く活用されている
精神面でもポジティブな変化

 一方で表出した課題満足度は 3.8 点(5 点満点)と、圧倒的ではないが現実的な期待値に落ち着いています。

この背景には以下のような課題が見えてきました。

 1. 新しいストレスが生まれている「疲労感が増えた」42%（5 人）
「ストレスが増えた」25%（3 人）

 2. うまく活用するためのサポートが必要満足度 5 点をつけた人でさえ「もっと効率的な使い方があるはず」という不安
生成コードの品質ばらつきによる試行錯誤ループ
67%がチーム内での経験・課題共有の場を求めている

 ここから先最も重要なのはチーム内での経験・課題共有の場を作ること。
効果を伸ばしつつ、新しく見えてきた負荷をどう軽減するか。

ここがポイントになりそうです。

 おわりに現時点では LLM によって効果は出ています。

しかし何かの負荷が軽減した世界には至っておらず、別の負荷が高まっている状況です。
特にエンジニアがアジャストしていくサポートが必要な時期だと認識しています。
また比較的、導入してすぐに生産性向上を実感する人はキャッチアップ速度が早くマルチタスクスキルの高い傾向にありました。
個人差を埋めるには、そういった感度の高いメンバーに協力を得ながら進めるのが良いでしょう。
そのためにもチーム共有の仕方やスキルアップサポートだけでなく心理的安全の担保によってもたらされる雰囲気や文化が特に重要そうです。

これらの文化を LLM で解決できず、日頃から生産性向上に向き合い醸成していくことが大事だと改めて感じました。
この記事が、同じように AI 活用を進めている方の参考になれば幸いです。