どうも、ADWAYS DEEEで取締役CTOをしている大曲です。

2025年のエンジニア組織はAIツール導入によって大きな変化をしています。この記事では、組織の変化を時系列で振り返ってみたいと思います。

はじめに

私たちの組織では、2025年2月から本格的にAI活用に取り組み始めました。現在、組織全体でのAI活用が進む一方で、まだ解決すべき課題も多く残っています。

この記事が、同じようにAI導入を検討している、あるいは既に取り組んでいる組織の参考になれば幸いです。

前提：私たちの組織について

まず、私たちの組織の状況をお伝えします。

プロダクト組織人数は45名程度
エンジニアは30名程度
プロダクトとしては2サービスをメイン開発している（細かいサービスを含めると5〜7個くらいある）
10〜20年と長いサービスが多い
リポジトリは100個くらい（メインはGitHub、一部GitLabを使っている）
開発文化の責任者としてテクニカルマネージャー（テックリードの複数チームを見る人たち）がいる

時系列で起こったこと

ツールの導入や組織の変化を時系列でまとめました。

ポイントとなる変化や判断について、いくつか書きます。

判断：Cursor、Devinの見切り発車での導入

年末頃からエージェントモードが盛り上がっていました。正直、GitHub Copilotがうまく追随して実装してくれるだろうと思っていました。（これは今でも期待しています）

世間の盛り上がりに対して、どうしようか悩んでいました。

外部の方と話した際に、こんなアドバイスをもらいました。「スマホの時にiPhoneとAndroidのどちらを選ぶべきだった？両方とも押さえた方が良かった。それと同じことがAIでも起きるから、全部に賭けるように」この言葉に後押しされて、すぐにアカウントを開設して、メンバーに配布しました。

どれを導入するかは悩みましたが、CursorとDevinを導入しました。開発以外ではDifyも導入しました。

Cursorを選択した理由

エージェント機能としての体験が良かったためです。チャットに問いかけて、各ファイルの変更をチェックしたりする体験が良かったため、メンバーの開発体験が変わったことを感じられるIDEだと思い、採用しました。

Devinを選択した理由

IDEとは別で自律型のAIとして、Slackベースやタスクベースで依頼ができそうだったためです。開発プロセスの中で使うというよりも、エンジニアが自動化しやすいタスクを依頼するものとして採用しました。

変化：ペアプロをメインとしていたため、みんなが使うまでが早かった

私たちの開発ではペアプロをメインとしています。現在ではAIとのペアを使い分けている状態です。参考資料

そのため、チームメンバーの誰かが使い始めると、便利であることを感じるまでが早く、ペア作業でもメインツールとして使う頻度が増えました。ペア作業がメインであるため、全メンバーで同じツールがないと効率が落ちるため、メンバー全員への配布と活用が増えました。

変化：Devinがエンジニアのためというより、非エンジニアに有効だった

Devinは当初エンジニアのために役に立つだろうと思っていましたが、非エンジニアへの恩恵が高かったです。

PdMによる活用例：

エンジニアが監修したタスクをPdMがDevinに依頼
- 簡単な運用タスクが依頼されたらPdMがSlackで依頼してPRを作成し、テスト環境でチェックする
- エンジニアは本番リリース前の最終レビューのみとなる
PdMが仕様調査のためにDevinに依頼
- エンジニアに相談する前にDevinに相談して見当をつける
- フロー図を依頼したりして、新機能開発のユーザーストーリー作成に活用する

エンジニア向けは、CursorやClaude Codeメインへとシフトしました。 Slackで長々と依頼するよりも、ローカルのツールでやり取りをした方が早いので、そうなるのは自然な流れですね。Devinをがっつり活用しているメンバーもいるため、人それぞれなパターンがあるなと思います。

エンジニアでの活用例もあります。メイン作業をしながら、別のことをDevinに依頼しておくことが多いように見えます。

ちょっとした機能を依頼してみる
- メインで別作業をしながら、依頼しておいたりしている
エンジニア自身も仕様調査のためにDevinに依頼
- 気になっていたポイントを聞いておく

判断：Claude Codeの変化が大きく、導入判断を早くした

6月にClaude Codeの検証を、テクニカルマネージャーを中心に行いました。開発生産性3倍を掲げて、意図的なレビュースルーを行い、どこまで早くなるかも検証しました。

9月末まで検証して、全体展開などを考えていました。ただ、使えば使うほどCursorの時の体験とまた違う衝撃がありました。

自分自身でもDiscordのBot開発やそれに伴う既存システム改修などを行なっていたため、その変化を肌で感じました。

本当に直接コーディングすることが減りました。 変にAIツールに指示する面倒さが残るかというと、そうではない体験でした。なぜ違和感がないのか考えてみました。やりたいことをまとめた後にどこのファイルをどう編集するべきかを考えていましたが、この「どこのファイルから編集するべきか？」からClaude Codeと一緒に決めることで、AIへの指示が面倒でなく自然と指示してしまう体験に変わりました。

それとともに、7月末にClaude Codeのサブエージェント機能がリリースされました。この時に、個人で使うAIではなくチームで使うAIにシフトしたいと思っていました。（AIツールのTipsをうまく使い分けるのではなく、チームメンバーでAIエージェントを最適化する）

そのこともあり、Claude Code自体の開発体験の凄さとチームでAIエージェントのマネジメントができる点も相まって、
9月末の判断を待たずに、8月中にアカウントを配る動きを行いました。

現在ではプラグイン機能もリリースされたため、テクニカルマネージャー監修のプラグインリポジトリができました。各チームが活用したり、各チームで模索して良い結果が出たエージェントの設定を取り込んだりして、組織全体でAIエージェント設定の最適化を行なっています。

GoやTerraformでのガイドラインに準拠したサブエージェント設定
チームごとでよく使うコマンド

徐々にAI主体で管理する領域やプロジェクトごとに特化したAIエージェントが組み込まれていくなと期待しています。

変化：AIツールの進化が早く、解決手段がコロコロ変わる

5月頃に業務改善のための設計を考えた際に、サービスデータへのアクセスをどうするか悩んでいました。サービスデータの更新は、APIを作るべきという方針はあったのですが、サービスデータ参照系でわざわざAPIを作りたくありませんでした。

AI機能開発としても、AIの利活用でもデータ基盤の改善が必須であると判断したため、営業がアクセスできるデータ基盤という形で刷新を考えていました。設計案は以下の通りです。

ただ、他のプロジェクトもあり、データ基盤改善への着手が遅れていました。その間にテクニカルマネージャーとの議論で、シンプルにDBをMCP化した方が良いと判断しました。結果として、MCP Toolbox for DatabasesでMCP化を行い、データ基盤経由ではなく直接サービスのデータに接続できるようにしました。また、業務改善としての恩恵だけではなく、営業が利用するAIツールからの接続やエンジニアがサービスの調査をする際にも役に立ちました。

AIツールの進化が早いため、いつの間にか解決手段が広がります。その都度、新しいアーキテクチャを設計し、検証するために作ってみる速さが必要だと感じました。テクニカルマネージャーがサクッとアーキテクチャから一気に作り上げてくれたので非常に助かりました。

振り返り

他社にも負けないようにAIへの投資に対するスピードや学びを模索しました。改めて振り返ると、CTOとして学びが多いなと感じました。

やはり組織の変化は、2か月かかるもの

各チームでAIを活用するためには、2か月くらいはかかります。触れ始め、そしてAIで改善する動きができるまでには数ヶ月待つ必要があります。変化の兆しがあるとそこからは早いので、じっくり待つのも大事です。ただ、2か月でも変化があるのは早い方だろうと思います。（全てのチームでという訳ではないので、それぞれで変化を起こすために各チームに入る必要はあります）

ただ、各チームでWeekly AIや意図的なAIを利用する検証活動を行ったりして、AIに馴染む動きを活発にしてくれています。ここをわざわざCTOが指示せずとも動いてくれるのは、CTOとして非常に嬉しい限りです。

AIツールの費用対効果を見るよりも、組織の状態をどうしたいのかを意識するようになった

プロダクトのロードマップでも機能ではなく、課題や状態ベースであるべきという考えがあります。 https://note.com/ozyozyo/n/nfb370fadd70c

AIツールは今後も様々なアップデートが行われ、便利なツールが次々と登場すると思います。重要なのは、それらのツールが組織の文化をどう変えるかという観点で判断することだと学びました。

Claude Codeの導入で、チーム全体でAIエージェントのマネジメントに向き合いました。このような視点での導入が、より組織としての方針も打ち出しやすそうで、AIと開発文化の文脈で開発プロセスの検証が進みそうだなと思います。

今後に考えられそうなこと：

Cursorのボイスモードでペアプロで議論している情報が全てインプットされやすくなり、コーディング体験が変化し、ペアプロの品質がより増幅するのではないか
スペック駆動開発と現在のユーザーストーリーを組み合わせることで、より開発のスピードが底上げするのではないか
監視ツールのMCPとシステムリソースのMCPを活用することで障害対応の体験での調査を全て自然言語で調査できるのではないか

コンパクトなチームこそ費用対効果が高そうだが、AIで起こす変化のためにリソースが必要だった

AIツールの台頭により、採用戦略や組織規模に関しての議論も今年は活発でした。その中で、組織としてコンパクトなチーム（50人規模くらい）がAIツールへの投資もしやすく、変化も起こしやすいのではないかと考えていました。

下半期（7月〜12月）では、AI活用のために各チームで動いている動きが自ずと連動していくようになり、組織全体の変革に繋がりたいと考えており、徐々にその変化が起きていることを感じています。 DBのMCP化ができAIツールへの接続が簡略化され業務効率化の幅が広がったり、ドキュメントの整備でAIツール経由の開発が楽になったりと、様々な改善が連鎖的に起こっています。

リソースと学びのジレンマ

AIを通した学びを得るためには、時間がかかります。学びがあるまでずっとリソースをかけ続けられる状態が保てない時があります（特に事業の数値が悪い時こそ判断が難しい）。

例えば、業務改善チームで業務効率化を図る際に、ルールベースで処理をするべきものがありつつも、AIの検証のために色々と敢えて挑戦したいという状況がありました。しかし、成果を求めるためにルールベースで作る判断をしました。これらは成果への判断としては正しいのですが、敢えてAIベースにすることでAI前提での業務フローの学びを得るチャンスを逃してしまったのではないかと感じる時もありました。

変化はあるものの、他社の大手テックカンパニーとの変化にまだまだ追いついていないと、やればやるほど感じました。リソースの絶対量の違いから、同じ比率をかけたとしても学びの量はリソースの絶対量に伴います。

そのため今後は、組織として取捨選択を明確にして、毎月成果を出すべきものを明確にし、マネージャー同士が連携してコミットメントを求める判断により重きを置くべきだと思っています。

数百人エンジニアがいる組織ではなく、小さい組織だからこそ、取捨選択は今までと変わらないなと改めて感じました。

開発プロセスへの変化がまだまだ必要である

Findy Team+を利用しています。上記はそこでの数字の変化です。ちょうどFindyさんとの振り返りで「一人当たりの生産性も明らかに良くなっている」や「ペアプロ × AIがハマっている部分があるのではないか」と褒めてもらいました。しかし、なんと振り返りから1か月くらい経った数字では下がっていました（笑）

もちろん、様々な理由はありますが、ペアプロ × AIでの効果だけでは足りない部分があるなと感じています。個人の生産性向上だけでなく、開発プロセス全体をもっと最適化していかなければ、真の組織としての生産性向上には繋がりません。これは今後の大きな課題です。

ペアプロだけではなく、今まで培ってきた文化（ユーザーストーリー、仮説検証の進め方）を意図的にアップデートしていく必要があります。

月ごとでの生成AIのFBの内容を見ても、全て書いているという訳では無いですが、組織の学びの傾向が分かります。ツールの使いたての頃は、コーディングでのFBも多いのですが、最近では開発プロセスの根本をもっと変えるべきFBが少ないです。ここに組織の意識を集中させる必要があります。