はじめに
こんにちは、千株式会社でシステム開発部のマネージャー 兼 事業企画課をしています、 daitasuです。
- 「エンジニア内のAI利活用の程度にばらつきがある」
- 「職種間でAI活用に温度差がある」
- 「個人の努力に依存したAI導入になっている」
こんな課題、皆さんの組織でも感じていませんか？
私達のチームでは、この課題を解決するために、プロダクトマネージャー(PdM)やデザイナー、エンジニアと職種に限らず、
「全員でClaude Codeを使ってみよう」と決め、チーム全体で開発フローの改善に向き合ってきました。
今回は、現在に至るまでの背景、Claude Code を「全員」で使うことでどういった変化が生まれてきているかの現在地をレポートします。
私達のチームについて
弊社の開発組織は、PdM、デザイナー、エンジニアが同じ組織内に属していて、職種別ではなく、事業の単位でチームが区切られています。
レポートラインがまとまっている関係で、チームで何かを取り組む際には動きやすい構造にはなっています。
🔥 AI駆動で直面した3つの壁
弊社では、「Claude Code」や「Cursor」のサブスクリプション代金を会社として支払っており、各々で様々なツールを利用していました。
しかし、問題として、各個人がクローズドでAIの利活用にチャレンジしているものの、個々人の努力に依存してしまい、下記のような問題が生まれていました。
- 技術格差の拡大: リードエンジニア1名とジュニア寄りのエンジニアで構成されており、技術設計まわりの知識・経験差に大きな差があり、AI利活用に関する進め方も乖離が生まれていた
- ナレッジ共有の限界: 開発組織全体で、他チームともナレッジシェアなどはしていたものの、ナレッジシェアが事例紹介に留まっており、AI利用の浸透が進みにくい印象があった
- 個人最適化の罠: 各々が違うツールを使うことで、「チームとしてのAI利活用」でなく、「個人としてのAI利活用」になり、チームとしてのAI利活用の方向性が曖昧になっていた
💭 マネージャーとして描いた「理想のAI駆動チーム」
昨今のAIエージェントの活用の中で、他社が様々な取り組みをおこなっています。
私自身も、システム開発部のマネージャーとしての役割を担う一方で、「事業企画課」というもう1つの部署にも在籍しており、EMなのか、PdMなのか、Bizdev なのかよく分からない仕事をしていたりするのですが、
今後AI による開発フローの変化の中で、こうした責務定義についての抜本的な描き直しがより生まれていくと考えていました。
「今後あるべき開発組織のあり方とはどうあるべきか」
- 「エンジニアがMCPで各種の事業データを数値モニタリングして、事業戦略の議論ができる」
- 「デザイナーがよりモックを高速で作り、プロダクトマネジメントの領域に染み出していく」
- 「PdMがリポジトリコードをAIで読み解き、DBのデータ分析もAIで補助輪をつけて調査できる」
「そんなチーム、とても事業を牽引できるチーム といえるのでは？？」
色々なストーリーがありそうですが、ひとまずチームとしてまず動いていけるとことしては、
「個人としての知見」でなく、「チームとして」AIへ向き合い、みんなで「ルールを育てたい」
ところから始めるがよいのではないか、と考えました。
みんなが同じツールを用い、チームナレッジを全員で磨いていく。 出てきた課題に向き合い、AI駆動のあるべき開発フローを丸ごと見直していく。
そうしたチームを実現していくため、「チーム全員でClaude Codeを使おう！」と踏み切りました。
🚀 スタートダッシュ：全員でMCPセットアップ
まずは、AI Coding に慣れている人とそうでない人の差を埋めるために、
- Claude Codeの基本の共有
- チームとして最低限入れてほしいMCPの共有
から始めました。
具体的には、「PostgreSQL」「Github」のMCPの設定は完了してもらい、まずはテーブルスキーマを読んだり、リポジトリコードをPdMやデザイナーの方も含めた全員が読めるような状態にしました。
🔧 カスタムコマンドで開発フローを標準化
Claude Codeでは、カスタムコマンドを生成することができます。
本当はサブエージェントなども使ってより精度を上げていきたいのですが、「とにかくベースを作ってみんなで育てる」 を目的に始めました。
具体的には、最初に下記のようなカスタムコマンドを諸々作成しました。
/generate-prp
- Github Issue のリンクから、Claude Code の実行計画(PRP)を作成
- 私達のリポジトリはものリポ構成となっており、package やアプリケーションごとにそれぞれ
coding-guideline.mdやarchitecture.mdといったDoc ファイルがあります- Issue 内容から影響範囲のある package を推定し、Doc を読み取った上で実行計画を作るようなプロンプトにしました
/post-prp-to-issue
- PRP を該当のGithub Issue にコメントとして追記するコマンドです
- そのまま生成された内容をコピペでも良いのですが、「証跡を残しやすくする」、「実装開始前に方針レビューを挟みたい場合にチームに見てもらう」ことを可能にしました
PRPの内容としては、
- 概要
- システム的な影響箇所
- サンプルコード込みの実装手順
- テスト方針
- 関連URL
などをアウトプットとして出してもらうようにしました。
/create-pr
- base branch とのdiff をもとに、AIが自動でPRを作成
- 作成者ごとにDescription の粒度が異なる問題などがあったため、AIで効率化と標準化を進めました
/review-pr
- PR のレビューを全体レビューとインラインレビューで対応してくれるコマンド
- 上記のコーディングガイドラインや、コード品質憲章のDocなどをベースにレビューすることで、レビュー負担を軽減できるようにしました
/fix-pr
- 上記のインラインレビューに対し、各コメントの修正をcommit していくコマンドも準備
- これによって簡易な修正系は非同期で終わるようにしました
🌊 チームのAI化の波が進み出す
上記の開発フローは、筆者(daitasu) が最初の叩きとして作成したのですが、私自身はマネジメント業務や事業戦略などのやり取りが中心で、メンバーほど開発コードを書けていません。
あくまで最初のきっかけとして「やっていき」してたのですが、ここから一気にチームのAI利活用が加速し始めました。
SonarQube と連動した、AI自動品質レポート
まず、リードエンジニアの方が、今までコード品質を管理するために用いていたSonarQube とMCP連動した自動レポートが作成されるものを作ってくれました。
これにより、Scrum の振り返りでダッシュボードを眺めるだけでなく、どんなクリティカルがあるのか、対応優先度の具体性や課題がより顕著に議論できるようになりました。
Figma MCP と繋いだFrontend の実装
弊社では、今年から本格的にプロダクト横断のデザインシステムを実装しています。
また別のエンジニアの方が、中々精度を上げることができなかったFrontend まわりのAIコード生成を、Figma MCPと繋ぎ、デザインシステムのコンポーネントを見ながらAIがReact コードを生成してくれるコマンドを作成してくれました。
これにより、徐々にFrontend のVibe Codingも進んでいきそうです。
新卒エンジニア によるPR レビューの精度向上実験
今年弊社に入社した新卒の方が、チームのPRレビューの精度をより向上すべく、観点別でAIによるコード生成の品質スコアを出すような実験も取り組んでくれています。
デザイナー による、デザイン変更差分を自動検出するカスタムコマンド
Figma でデザインを書き換えた際、「どこ」が「いつ」書き換わったのかが分からず、エンジニアが実装対応を見逃してしまったり、変更検知の認知負荷が高いといった問題がありました。
元々、デザインの変更が入った際は、極力特定のIssue に連ねる形でコメントして logging をしていたのですが、これを進化してくれました。
デザイナーの方が、Before / After の画面キャプチャから、AIが自動で 差分を判断し、Issue に変更箇所を追記してくれるコマンドを作成しました。
これを用いることで、下記のような効果がありました
- どんな変更が入ったかすぐに分かる
- 変更のlogging に対する負担が軽減する
PdM による、デザインのモック作成
PdM は、Figma MCP を繋いでデザインシステムにつなぐことで、プロジェクトのデザインモックをAI に書かせるようになりました。
PdM が思い描く仕様をより具体のイメージに起こして議論することが可能になり、PdM / デザイナー間のコミュニケーションコストが軽減されるようになりました。
PdM による、Claude Codeでのコードリーディングと既存仕様の理解
私達のプロダクトは、20年近く運用されてきたプロダクトです。
その中でも、私達が担当しているシステムは、社内に既存仕様を把握している人がいない、非常にレガシーな仕様を保持したサービスになっています。
そのため、PdM がなにかを考える際に、「既存仕様のここはどうなっている？」を都度エンジニアに調査依頼を投げる必要がありました。
しかし、Claude Codeで様々なリポジトリとGithub MCP で接続したことで、
- まずPdMがある程度の現行仕様にアタリをつける
- 見えた情報をもとに仕様書を整理する
- 整理した内容をもとにエンジニアに相談を投げる
といった動きが取れるようになりました。
PdM としても、自身である程度の仕様理解を進められるようになり動きやすくなったり、エンジニアとしても、PdM が勘所を定めた上で相談してくれるため、コードを追いかけやすく、対話しやすくなってきました。
今後
今回、「全員でClaude Codeを触るようにしてからのチーム開発の変化」をお話しました。
「Claude Code に統一してみよう！」と話してから約1ヶ月。
全員で同じツールを触ることによる、 チームナレッジの強化 はもちろん、それぞれの 職種越境 が始まり、PdM / デザイナー / エンジニアのそれぞれの振る舞い方が変化し始めています。
まだまだAI 自動化しきれていない部分や品質面も改善の課題がたくさんあります。
しかし、こうしたAIによる改善を全員で取り組んでいけば、プロダクト開発フロー全体が大きく形を変えていくことが見込めるため、今後も一丸となってAI への Bet を進めていく予定です！
