個人の変化をチームに持ち込む難しさ

千葉：Qiitaはエンジニアの知識を記録・共有するサービスです。この1年、社内のAI活用推進を主に担当してきました。

2024年末から2025年にかけて、Clineなどのコーディングエージェントが次々と登場し、そこからバイブコーディングが広がりました。エディタを開かなくなった、ターミナルすら開かなくなったというエンジニアも増え、個人としてはどんどんいろいろなものを作れるようになった実感があります。

一方で、その変化をチームに持ってくるのは難しいと感じている方も多いのではないでしょうか。プロジェクト開発全体を変えるには自分だけでなくメンバー全員がAIを使わないとボトルネックになりますし、開発以外のプロセスもこれまでのやり方をアンラーンしなければなりません。次々と新しいプラクティスが生まれ求められるプロセスも変わり続けるため、一度学んで終わりというわけにはいかず、プロンプトをコピーしただけで同じ結果が出せるわけでもありません。

そこでQiitaでは、コピーするだけでなくチーム全体で試行錯誤を繰り返し、その回数を増やしていくことを目指してきました。実際にこの半年でClaude Codeの利用割合は大きく伸び、現在は90%以上をAIで開発する状態になっています。

プルリクエスト数もチーム全体で140%程度に増加し、特に伸びているメンバーに限ると200%程度まで成果を伸ばしています。数だけでなく、学んだことをチームや社外に還元する動きも増え、AIを学べる組織になっていったと感じています。今回は、Qiitaがどのようにしてこの状態に至ったのかをお話しします。

試行錯誤するチームをつくるという目標は、一足飛びには実現できないため、2つのステップに分解して取り組みました。1つ目はまず試す動きを増やすこと、2つ目はそこから学んだ知見をチームに還元することです。

「まず試す」メンバーを増やす

まず試すメンバーを増やすためには、試すために必要な消費（コスト）を減らすことが必要でした。

最初にClaude Codeを社内で利用開始したときは従量課金で運用していましたが、正直まったく広まりませんでした。従量課金では1回の開発で1〜2ドルかかることが分かってしまうため、コスト意識が働き、費用対効果を気にしてしまいます。プライベートで試しているメンバーは開発が良くなる実感から使い続けますが、初めて使うメンバーや慣れている途中のメンバーは、そこが気になってなかなか試せないという状況が起きていました。

そこでQiitaでは、Claude CodeのPro・Teamプランを段階的に開発者全員へ配布しました。共通の設定でガイドレールも整備した結果、利用するメンバーが増えていきました。大きく変わったのはコスト意識です。従量課金では費用対効果が気になってなかなか試せませんが、サブスクリプションであれば5時間ごとにリミットが来る前に使い切ったほうがお得だという意識に変わります。これは和田卓人さんのツイートでも話題になっていた感覚で、クレジット消費を心配せずに使い続けられると、プログラミング感が変わります。実際に社内でも同じ現象が起き、みんなが使っているなら自分もと、利用が広がっていきました。

同時に重要だったのが、これを目標として落とし込むことです。Qiitaは当初「AIでの業務効率化」というふわっとした目標を掲げていましたが、これではアクションに落とし込みづらいという課題がありました。そこで「AIにほとんどコードを書いてもらう」「AIに開発を任せられる」という段階を目指す目標に噛み砕き、社内で発信しました。

社内では冗談交じりに、直接手を動かす開発者ではなくAIのプロセスを管理・改善する側に回るという意味で「工場長」と呼ばれることもあります。目標をチームや個人単位のアクションに分解し、マネージャーのサポートも受けながら業務として取り組めるようにしていきました。

AIに開発を任せるという目標もまだふわっとしているため、さらに分解を進めました。書いたテストコードを検証してAIがフィードバックを受け取れる仕組みとしてTDDを取り入れたり、並行して開発できるようgit worktreeを整えたり、少しずつリリースできるようリンターを整えたりと、試行を後押しする開発基盤を整備していきました。

開発の様子を見せる

この取り組みの中で社内に一番刺さったのが、AIに開発を任せている様子をそのまま社内配信したことでした。SlackやGoogle Meetを使い、画面を共有しながらタスクに取り組む様子を公開し、他のメンバーに見てもらう形です。

当時の開発環境は、一番左にエージェント用のシェルを配置し、右側にAIが書いたコードをレビューする画面（difit）を並べたものでした。どういうツールを使い、どういうスタイルで進めているのかが伝わりやすくなり、「エディタを開かないんですね」といった反応がありました。推進したい立場の人間が自ら使う様子を見せることは、他のメンバーが試しやすくなる効果につながりました。

こうしてAIで試しやすい状況を整えていった結果、Claude Codeを使いながら学び、一部のメンバーは大きく使いこなせるようになり、生産性やアウトプットを伸ばしていきました。一方で、AIに振り回されてしまうメンバーも出てきました。AIにコードを書いてもらったもののレビューで意図を聞かれても答えられない、といったケースです。試行する環境を整えたことで、伸びるメンバーと振り回されるメンバーの間に偏りが生まれました。

個人の学びをチームの知見に変える

個々のメンバーが使いこなせるようになったことを受けて、それをチームとして還元し、底上げしていく第2ステップに進みました。

個人の学びをチームの知見に変えるというと、スキルやClaude Pluginを整備してインストールしてもらう方法が想像されると思います。Qiitaでも実際に試しましたが、最初はあまりうまくいきませんでした。開発リポジトリにスキルやプラグインを用意しても、整えた本人以外にチームとして取り組むメンバーはなかなか増えなかったのです。どういうものを作るとチームのためになるのか分からず悪影響を心配してしまうこと、そしてローカルでコーディングエージェントを使っているとPCの中で完結し、他の人が何に困っているか見えないことが理由でした。いきなり共通化を目指すのは早すぎたということです。

そこでまず、お互いがどう使っているかを共有できる場をつくることから始めました。

共有の場をつくる

最初に取り組んだのは、AIについて共有する場をつくることでした。うまくいったことだけでなく、どう試しているか、うまくいかなかったことも含めて過程を共有する場です。チームの振り返りイベントに組み込むことで、自然と振り返りのタイミングでこうした共有が行われるようにしました。

この取り組みはうまくいきました。もともとチームとして目標を決め、マネージャーのフォローを入れながら各メンバーがアクションに落とし込んで進めていたため、それぞれが何かしら試していたためです。そこに、書いたことを後押しするサポートを加えたのが肝でした。自分の書いた内容に価値があるのか迷うメンバーもいましたが、他の人の役に立つからどんどん書いていこうと伝え、他のメンバーの発信を見て刺激を受け、徐々に広がっていきました。参加メンバーの投票で一番トライしていたメンバーを表彰する仕組みも取り入れ、目標として意識するメンバーも出てきました。

心理的安全性を高める

何でも共有していい空気づくりも意識しましたが、ただそう伝えるだけでは実現しません。シニアメンバーやリードするメンバーが自ら失敗したこともアウトプットすることが大切だと考え、AIに大きすぎるプルリクエストを作らせてしまい失敗した、といった内容も自分から発信しました。そうした姿勢を見て他のメンバーもアウトプットしてくれるようになり、トライや悩みが可視化されていきました。

プロンプトを共有する

振り返りで共有する中で、どういうプロンプトを使ったのか知りたいという声が出てきたため、プロンプトを置くリポジトリ「ai-prompts」を用意しました。開発のリポジトリとは完全に別で、個人ごとにディレクトリを切り、それぞれが好きに共有用のプロンプトを置けるようにしています。

こうして振り返りのついでに「これがプロンプトです」と共有する流れが徐々に増え、他のメンバーが自分のプロンプトに足してみるといった広がりも生まれました。

開発を見学し合う

開発プロセスの試行は、テキストやコードの共有だけでは伝えきれません。ループエンジニアリングをやっていると言葉で説明しても、実際にどう進めているのかは伝わりにくいものです。そこで、お互いのAI開発を見学し合う「開発チーム勉強会」を、モブプロ風に、メンバーを交代しながら実施しました。

これにより、どのタイミングでどんな指示を出しているかといった、言語化されていなかった学びが伝わるようになりました。本人が知見だと思っていなかったことに他のメンバーが興味を持つ場面もありました。開催にあたっては事前にメンバーへヒアリングを行い、自分の開発を見せることへの恥ずかしさに配慮し、発表会形式ではなく人数を絞ったモブプロ形式にする、教える場ではなく作業する様子を見せるだけで十分とするといった工夫で、できるだけ気軽に参加できるようにしました。

こうした取り組みの結果、メンバー同士の助け合いが増えていきました。ジュニアエンジニアはAIの出力を評価しづらい、レビューで意図を聞かれても答えられないという課題を抱えていましたが、AIが一方的に進めるのではなく、AIの側から質問して人間に判断させるスキルを備えた「junior-engineer-support」というClaude Pluginが、AIプロンプト共有リポジトリを通じて生まれました。レビューについても、AI向けの規約ガイドラインを整理し、適切な場所に配置してリンターでチェックできるものはリンターに任せるといった見直しが進みました。

アウトプットからアウトカムへ

Qiitaが取り組んできたのは、試行し適応できるチームをつくることです。AIは難しく、答えがある問題でもありません。最初からうまく使うことはできないため、どうしても試行錯誤は発生します。それをチームとして許容できる環境を整えることを重視してきました。つまり、AIに対してチームで向き合う際の心理的安全性を高めることです。

これは独自研究になりますが、アジャイル開発やスクラムで良いとされている考え方に近いと感じています。やってきたことはまさにFail Fastの文化づくりであり、スクラムの3本柱のうち透明性や適応は、今回のトライの共有に近いものです。AIというちょっとずつ試して修正していく不確実性の高い対象に向き合う上で、これらのプラクティスから学ぶことがAIを学べるチームをつくることにつながると考えています。

こうしてアウトプットを増やせる組織にはなりましたが、これで終わりではありません。次はアウトプットをきちんとアウトカムにつなげる必要があります。開発が早くなったからといってアウトカムが増えるわけではなく、開発以外の部分がボトルネックになったり、重要でない部分に注力してしまったりすることもあります。ここでも、出てきたエラーをチームとして受け止めて直していくという、これまでと変わらない姿勢が必要になります。

その一例として、Qiita自身の直近の失敗も紹介します。スライドの投稿機能をベータリリースした際、ヘルプページを作り込みすぎてしまいました。ヘルプはユーザーの解決に役立つものですが、ベータ版は機能変更や追加が続くため、作り込むほど開発コストが上がり、内容もすぐ古くなってしまいます。以前であれば途中で手間の割に合わないと気づけたはずですが、AIが手早く作れてしまう分、おかしいと気づくタイミングがないまま最後まで進んでしまいました。

そこでチームで改めて振り返りを行い、AIによる自動作成は続けつつも、ヘルプページという形にこだわらずリリースブログに使い方を軽く書いておく程度でよいのではないかと、方針そのものを見直しました。こうした試行錯誤をチームとして許容し、そこから学んでいく姿勢が今後さらに必要になっていくと感じています。試行を恐れず、失敗から学ぶチームで、AIに立ち向かっていきましょう。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら

※動画の視聴にはFindyへのログインが必要です。