エンジニアが仕掛ける「職種の壁を越えたAI活用」。チーム全員でClaude Codeを使いこなす文化と仕組み

はじめに

社内のAI環境やAIツールの提供をリードしているIT本部が中心となって、社内のAI戦略や活用事例、その裏側にあるストーリーを発信する企画「AIジャーニーの足跡」。前回に引き続き第2幕では、IT本部の新卒エンジニアが社内を駆け巡り、ビジネスや開発の現場でどのように AI が活用されているのかをレポートしていきます。

AI によって個人の作業効率が上がる一方で、これからは「職種同士の連携」がより重要になってくるのではないか――。エンジニア個人のコーディング速度が上がっても、仕様策定やデザイン、職種間のコミュニケーションに時間がかかっていては、最終的なプロダクトのリリース速度は上がりません。

今回は、事業者向けの管理画面と一般ユーザー向けシステムが密に連動する大規模プラットフォーム開発において、職種の壁を越えて AI を使いこなしているプロジェクトチームにお話を伺いました。職種ごとに AI の使い道はさまざまですが、PdM、エンジニア、デザイナーが「Claude Code」をはじめとするAIツールを活用し、開発スピードの向上や手戻りの削減にどう取り組んでいるか、実際の事例を共有します。

キーワードは 「AI前提のチーム開発」。「個人の効率化」にとどまらず、「職種間の連携と運用の最適化」を追求する、その革新的な取り組みの全貌に迫ります。

プロフィール

田邉優斗（インタビュアー）
- データ基盤部 MLエンジニア（25新卒）
- AI活用事例に興味があり、AIジャーニーの足跡のインタビュアーとして立候補

どんなチームが、何のために AI を活用しているのか

田邉： 今回は PdM、エンジニア、デザイナーという異なる職種の皆さんから、「職種間での連携」に AI がどのような影響を与えたかをメインにお伺いできればと思っています。まずは前提として、皆さんのチームの役割と、どのような課題や背景から今のような積極的な AI 活用が始まっていったのか、プロジェクトの概要と合わせて教えてください。

PdM： 私たちは、事業者向けの管理画面システムと、一般ユーザー向けの Webシステムを同時に開発している大規模なプロジェクトに携わっています。登場人物としては、発注元の事業者さまと、実際にシステムを運用する数多くの外部パートナーさま、そして一般のお客様という複数の層に分かれています。私の役割は、PdM としての仕様調整や社内メンバーとの連携に加え、非常に多くの外部パートナーさまと直接やり取りをしながら、各環境の初期設定を進めることです。

田邉： 膨大な数のステークホルダーと同時並行で仕様調整や設定を進めるのは、かなりのコミュニケーションコストですね。エンジニアはいかがでしょうか？

エンジニア： 開発チームはフロントエンド、バックエンド、そして私が所属する SDK の3つに分かれています。SDK チームは初期に私1人で開発していたこともあり、「最初からすべて AI に作らせよう」という設計思想で進めてきました。具体的には、自作した「SDD（Spec Driven Development）ワークフロー」という Claude Code のプラグインを活用して開発しています。PRD や技術仕様書を AI に作らせ、その仕様書を基にコードの生成までをすべて AI に任せることで、人間は PRD や仕様書のレビューだけに特化する方針を貫いています。

田邉： 初期から「AI前提」で動いていたのですね。デザイナーの役割も教えてください。

デザイナー： デザイナーチームは全体で3人ほどおり、B2B の管理画面から B2C のアプリまで幅広く、UI/UX設計やデザインシステムの整備を担当しています。他職種との関わりとしては、仕様策定の場面やフロントエンドエンジニアとの連携が非常に多いです。実装の相談をする時に、AI を使ってモックを作り、「こういうことを実現したいのですが、実装可能ですか？」とエンジニアに見せて会話する、といった形で AI をよく活用しています。

1. 「テキスト」から「動く実物」へ：AI が変えた職種間の共通言語

田邉： 職種間の連携において、AI の導入によって具体的にどのような変化がありましたか？

デザイナー： 一番大きな変化は、「空想」ではなく「実物」を見ながら話せるようになったことです。以前は、Notion などのテキストの仕様を読み解き、Figma で画面を作り、それをプロトタイプで繋いでから「イメージと合っていますか？」と確認していたため、どうしても時間がかかっていました。それが今は、ざっくりとした仕様を AI に突っ込んで「一旦これでモックアップを作って」と指示を出すだけで、数分で動くモックが作れるようになりました。まずはその実物をベースに認識をすり合わせることで、連携が圧倒的にスムーズになりましたね。

PdM： これは PdM 目線でも本当に助かっています。テキストの仕様書だけだと、「ダイアログが表示された際、その外側のエリアをタップしたらどう挙動するか」といった、細かいインタラクションの考慮漏れが起きがちなんです。

田邉： 従来なら、実装が完了してはじめて「思っていた挙動と違う！」と気づき、大きな手戻りが発生していた部分ですね。

PdM： まさにそうです。開発の超初期段階で生成されたモックを実際に触りながら具体的な仕様を詳細化できるため、深刻な手戻りを未然に防げています。昔の感覚だと、仕様を定義してから動くものを見るまでに 2週間〜1ヶ月かかっていたサイクルが、今は1日、2日のスピード感で回せています。

田邉： デザイナーが作ったモックから、実際のデザインデータへの落とし込みはどうされているのですか？

デザイナー： モックで方向性が決まったら、AI に「これを Figma のオートレイアウト適用したデータにして」と指示を出します。すると、そのまま綺麗なデザインデータとして出力されるので、そこから本格的なデザイン作業に移れるのも大きなメリットです。

2. 仕様の変更に追いつくドキュメント管理と、何が「最新の正しい状態」なのか

田邉： 開発フェーズでは日々のミーティングや Slack 上で仕様変更が頻繁に起きると思いますが、ドキュメントの更新や共有はどうしているのでしょうか？

PdM： そこもほぼすべて AI に任せています。 Notion にまとめている PRD の更新も自動化しています。たとえば、毎日行う調整会議の議事録を AI に投げて「仕様変更が必要な箇所」を自動で洗い出させたり、Slack のスレッドで議論の結論が出たら、その URL をそのまま AI に渡して「この内容を PRD に反映しておいて」と指示を出したりしています。人間の手をほとんど介さずにドキュメントが最新化されるので、反映の作業が圧倒的に楽になりました。

田邉： なるほど。PdM 側が管理する大枠の要件定義は、常に Notion 上で最新化されているわけですね。では、それを実際に開発へ落とし込むエンジニア側のドキュメントとは、どのように同期しているのですか？

エンジニア： 私たち SDK チームの場合、ソースコードに紐づく詳細な PRD や技術仕様書は、すべて GitHub上でブランチ管理しています。PdM が Notion で管理しているのはあくまで大枠の要件なので、実際に実装するとなると、さらに細かい仕様を詰める必要があるんですよね。ただ、仕様書が別の外部ツールにあると、並行開発しているうちにコードと仕様がどうしてもズレていってしまいます。それを防ぐために、現状のコードと同じ場所（GitHub）で管理しているんです。

その同期も AI を使って自動化していて、PdM が更新した Notion の要件や、Slack での日々の細かい議論のコンテキストを MCP 経由で AI に吸い上げさせています。その情報をベースに、GitHub上の詳細な PRD を AI に自動でブラッシュアップさせていくという流れですね。

3. 非エンジニアを置き去りにしない「文化」と「ガードレール」

田邉： お話を伺っていると、PdM やデザイナーといった非エンジニアの方々が「Claude Code」や「MCP」などを当たり前のように使いこなしているのが印象的です。どのようにチームへ浸透させたのでしょうか？

PdM： 現在、私たちのメインツールは基本的に「Claude Code」1本に絞られています。私はエンジニアのバックグラウンドがない完全なビジネス職なので、最初は全然知識がありませんでした。転機になったのは、週に1回、職種をまたいで AI の活用成果や試行錯誤を共有し合える場がセットされていたことです。そこでエンジニアのメンバーが快くサポートしてくれたおかげで、ビジネス職でも「仕事の幅」を広げることができました。

田邉： 技術的なオンボーディングの仕組みと、それを歓迎する文化があったのですね。エンジニア側としてはどのような工夫をされましたか？

エンジニア： 非エンジニアを巻き込むためには、「心理的ハードル」を下げる仕組みが必要だと考えています。たとえば、知識のない状態から AI を使って GitHub のチケットを自動生成しようとすると、「誤って他のプロジェクトを壊してしまったらどうしよう」という恐怖心やリスクがありますよね。

田邉： 確かに、触るのが怖くなってしまいそうです。

エンジニア： その不安をなくすために、エンジニア側で事前に「ガードレール」を設けた自作のネイティブアプリを提供しています。誰でも安全にタスク管理や AI 活用ができる環境を、技術の力で担保することが重要だと考えています。

4. 振り返りと次なる挑戦：「AI前提の運用設計」へ

田邉： 非常に理想的な活用が進んでいますが、あえて現時点で課題に感じていることや、今後の改善点はありますか？

PdM： 私たちは「既存の仕様書フォーマットや運用ルールに、いかに AI をはめ込むか」というアプローチで進めてきました。しかし振り返ってみると、最初から「AIありき」を前提にして、AI が理解しやすく作業しやすいルールをトータルで設計しておけばよかったな、というのが正直な反省点です。たとえば、数多くの外部パートナーさまとの Slack コミュニケーションも、人間同士が普通に会話しているだけだと、AI は「いまどちらがボールを持っているのか」「期限はいつか」を判断しにくい。最初から「Slack の文面はこういう運用ルールで書く」と決めておけば、AI もより正確に情報をハンドリングできたはずです。

デザイナー： デザイナー側でも同じ課題を感じています。デザインシステムを整備して、Figma 上にボタンや入力フォームなどのコンポーネントは一通り用意してあるんです。ただ、「どの画面で、どれを使うか」という細かい運用ルールがドキュメント化されず、デザイナー間の「暗黙の了解」になってしまっていました。人間同士なら「なんとなくの共通認識」でカバーできていたのですが、ルールが明記されていない状態で AI にデザインを任せようとすると、やはり質の低いアウトプットになってしまいます。AI に実務を任せるためには、人間側が「暗黙知の言語化」を徹底しなければいけないと痛感しています。

エンジニア： 私のチームが AI を 100%活用できているのは、最初からワークフローに AI を組み込んでいたからです。「人間がゼロから書く」ことを廃止し、「PRD を作る時は必ず特定のコマンドやスキルを使う」といったルールにしました。仕事のフロー自体を AI 前提に変えてしまえば、人間はレビューに専念できます。この「AIありきの仕組み」を他の職種やチーム全体にも最適な形で提供していくことが、次のステップだと思っています。

田邉：「個人の効率化」から始まり、モックを介した「職種間連携の強化」、そして「AI が働きやすいように人間側のルールを言語化・最適化していく」という次世代の課題まで、まさにチーム全員で AI ジャーニーを歩まれている素晴らしいお話でした。本日はありがとうございました！