AIで開発は3倍速くなった。でも、チームは3倍速くならなかった。
株式会社iCAREでDevelopment部 CTO 兼 PdMをしています、でんでん(@shogodenden)です。
本格的にAIを使い始めて、1年ちょっとが経ちます。この記事を読んでいる方も、すでに開発にAIを取り入れている方が多いと思います。コーディングが速くなった、調べものが楽になった——その恩恵は、肌で感じているかと思います。ここで書いているのは、個人の話ではなく、組織としてAIを組み込んでいく中で起きたこと、そこから見えてきた気づきです。まだ答えが出ていないことも多いですが、何かひとつでもヒントになれば幸いです。
このシリーズについて
開発メンバーへのインタビューを基に、AI導入後に起きた変化を私が観察・振り返りながら書いています。インタビュー記事のまとめではありません。現場の声は「こう返ってきた」という形で紹介しています。「生産性」や「アウトプット」をどう捉えるか——アウトプット・アウトカム・事業インパクトの3層については、シリーズ最終回の#5で整理しています。
ボトルネックは消えない、移動するだけ
最初の数ヶ月、メンバーからの報告はよかったです。「コーディングが速くなった」「生産性が上がった」という声が上がってきました。自分もそう感じていました。
ところがしばらく経って、「別のところが詰まってきている」という話がメンバーから上がってきました。コーディングが速くなった、というのは本当でした。でも全体のアウトプットが同じように増えているかというと、そうじゃありません。どこかが詰まっています。どこが詰まっているのかをメンバーと一緒に追いかけてみると、次々と「次の詰まり場所」が見つかってきました。
「改善できた」と思ったら、違う場所が詰まっています。また改善すると、また別の場所が詰まっています。
これはボトルネックが消えたんじゃなくて、移動しているだけだ——そう気づいたのは、メンバーとの会話を重ねる中でのことでした。
コーディングが3倍速くなった
最初の報告は、明確によかったです。
コーディングが速くなっている、という話が上がってきたとき、自分も素直に「いいぞ」と思いました。AI導入の手応えを感じていた時期です。
ただ、その報告には続きがありました。
「コーディングは3倍になっていた。レビューにかかる時間も、3〜4倍にきれいに伸びていた」
数字が出ていました。コーディングが速くなったのは本当でした。でも同じ期間に、レビュー時間も同じ倍率で伸びていました。
このとき自分は、まだそれほど深刻には受け止めていませんでした。「レビューも改善すればいい」と思っていました。
でもレビューが詰まった
コードが速く書けるようになった分、コードの量が増えました。レビューは人間がやっています。人が見られる量には限界があります。
レビュー支援を入れました。するとレビューは少し楽になりました。でも今度はテストが詰まりました。テストを改善すると、次は要件が不明確、チケットが足りない、という話になってきました。
「これまでボトルネックだったのは開発だった。開発が大幅に速くなったことで、後ろの工程にボトルネックが移った。改善を重ねるたびに、今度は要件定義がボトルネックになっていった」
要するに、ボトルネックは消えていませんでした。移動していただけでした。
コーディング→レビュー→テスト→要件定義、という順番で詰まりが引っ越していきました。これは「改善している」とも言えますし、「解決していない」とも言えます。
並列で動かすと、人間も並列で疲れる
ボトルネックの話と並行して、別の問題が出てきました。
AIを複数同時に走らせることができるようになると、人間も複数のタスクを並列で持つようになります。効率的に見えます。でも実際はどうだったか。
エンジニアが、自分の状態をこう語った。
「AIに支配されつつあった。回答が気になって、食事をしながらPCの前に戻って確認し、また投げて、また食べる——そんなことを繰り返していた。『自分は何をしているんだ』という気持ちがあった。食事の休憩時間ぐらいは休め、と思った」
待機中も「いつ終わるか」「何か返ってきたか」が気になって、本当の意味で休めません。
別のメンバーからは、疲労感について別の言葉が上がった。
「同時並列で動かすと、みんな疲れるようになったと言っていた。頭がチリチリする、と」
「頭がチリチリする」という言葉が印象に残りました。速くなったはずなのに、疲れています。
「生産性が上がった」とは、どこを見ての話なのか
こうした話を整理していくうちに、「生産性」という言葉が気になり始めました。
コードを書く速度が上がったのは事実です。でも、それが「生産性が上がった」ということなのか。
エンジニアは、生産性の定義そのものを問いた。
「この生産性は、どこを見て生産性と言えるのか。コードを書く速度だけなら確かに早い。でも、物を出すまでの責任全体まで含めると、上がっていない」
コードを書く速度は生産性の一部でしかありません。要件を整理して、実装して、レビューして、テストして、リリースして、それが実際に価値を届けるまでの全体を見たとき、「上がった」と言えるのかどうか。
終わりに
AIを入れたことで、チームは確かに変わりました。コードを書く速度は上がりました。個々の工程は改善されました。それは事実です。
ただ、「全体として速くなったか」という問いへの答えは、「速くなったかどうかを問うより、次の詰まりに気づける組織になったかを問う方が正しい」というところに落ち着いてきました。
ボトルネックを完全に消すことはできません。移動し続けるものです。だとすれば、大事なのはボトルネックを消すことではなく、次の詰まりを早く見つけて対処し続けることです。AIを入れたことで、少なくともその「気づく速度」は上がったと感じています。開発が速くなった分、詰まっている場所が以前より早く見えるようになりました。
これは「AIを入れたら終わり」ではなく、「入れてからが本番」という話です。ボトルネックが引っ越しをやめない以上、私たちも追いかけ続けるしかありません。それを続けられる組織が、AIをきちんと使いこなせる組織だと今は思っています。
【全5回】CarelyのAI開発を紐解くシリーズ
この記事でお伝えした内容の他にも、AI開発を成功に導くための重要なフェーズや落とし穴があります。全5回のシリーズを通して、企画から組織への定着までの全体像をぜひチェックしてみてください。
ボトルネックは消えない、移動するだけ──AIワークフロー開発組織の現在#1｜Carely開発チーム / iCARE
AIは行間を読まない──AIワークフロー開発組織の現在#2｜Carely開発チーム / iCARE
AIが正しくても、正解とは限らない──AIワークフロー開発組織の現在#3｜Carely開発チーム / iCARE
コードを書かなくなったとき、何が残るか──AIワークフロー開発組織の現在#4｜Carely開発チーム / iCARE
アウトプットの先に、何を見るのか──AIワークフロー開発組織の現在#5｜Carely開発チーム / iCARE
読んでくださってありがとうございました。
この記事が「なるほど」と思えたら、「スキ」や「フォロー」もらえるとうれしいです。チームにもシェアしてもらえると、次の記事のモチベーションになります。
iCAREではエンジニアを募集しています
iCAREでは、産業保健クラウド「Carely」を共に開発していくエンジニアを募集しています。 これまでの経験を活かし、複雑な社会課題の解決に技術で挑戦したい方、ぜひ下記より詳細をご覧ください。
