AIで作れるようになった。でも、お客さんは変わったのか。
株式会社iCAREでDevelopment部 CTO 兼 PdMをしています、でんでん(@shogodenden)です。
本格的にAIを使い始めて、1年ちょっとが経ちます。この記事を読んでいる方も、すでに開発にAIを取り入れている方が多いと思います。コーディングが速くなった、調べものが楽になった——その恩恵は、肌で感じているかと思います。ここで書いているのは、個人の話ではなく、組織としてAIを組み込んでいく中で起きたこと、そこから見えてきた気づきです。まだ答えが出ていないことも多いですが、何かひとつでもヒントになれば幸いです。
このシリーズについて
開発メンバーへのインタビューを基に、AI導入後に起きた変化を私が観察・振り返りながら書いています。インタビュー記事のまとめではありません。現場の声は「こう返ってきた」という形で紹介しています。「生産性」や「アウトプット」をどう捉えるか——アウトプット・アウトカム・事業インパクトの3層については、シリーズ最終回の#5で整理しています。
#1から#4を書き終えたとき、ふと気づきました。
ボトルネックの移動、言語化の圧力、判断の重さ、役割の変化。書いたことはすべて、開発の中で起きたことでした。取材でも、現場も、そこに集中していました。速くなった、詰まった、疲れた、変わった。いずれも本当の話です。
ただ、一つだけ抜けていたものがあります。
作ったものが、お客さんの業務をどう変えたか。開発が速くなった分、会社の経営にどう効いたか。インタビューでは、ほとんど語れませんでした。キツイ問いだった、というのが正直な感想です。話していないのは、取材相象のせいではなく、私自身がアウトプットの話に意識が向いていたからだと思っています。
この最終回は、#1〜#4の先に何があるのかを整理します。現場の声は少なめです。私の観察と、これから見に行く方向の話になります。
「生産性が上がった」は、どの生産性の話か
#1で書いた「コーディングは3倍速くなった」これは事実です。メンバーからの報告でも、数字でも裏付けがありました。
ただ、それが「生産性が上がった」という話の全部なのか、という問いは残っていました。エンジニアが、生産性の定義そのものを問いかけてきた。
「この生産性は、どこを見て生産性と言えるのか。コードを書く速度だけなら確かに早い。でも、物を出すまでの責任全体まで含めると、上がっていない」
コードを書く速度は、生産性の一部です。要件を整理して、実装して、レビューして、テストして、リリースして、その先まで含めて「上がった」と言えるのか。さらにその先、顧客の業務が変わったかまで含めると、どうなるのか。
開発の「生産性」について議論するとき、何を分子にして何を分母にするかで、景色がまったく変わります。広木大地さんの 開発生産性について議論する前に知っておきたいこと では、仕事量・期待付加価値・実現付加価値という3階層で整理されています。レベルが違う生産性を、短絡して議論するとコミュニケーションがずれる。その構造は、うちの現場でもそのまま当てはまりました。
私たちの言葉に置き換えると、次の3層になります。
アウトプット：開発の中で、どれだけ出せたか。コード、PR、機能のリリース、レビューの通過。コーディングが3倍になった、レビューが詰まった、テストが詰まった——#1で書いたことは、すべてこの層の話です。
アウトカム：顧客の業務は、どう変わったか。使い方が変わった、時間が減った、新しい価値が生まれた。開発チームの外側で起きる変化です。
事業インパクト：会社の経営に、どう効いたか。売上、チャーンレート、工数削減。ビジネス全体への波及です。
3層は階段です。アウトプットが上がっても、アウトカムが上がったとは限りません。アウトカムが上がっても、事業インパクトまで届かないこともあります。逆に、アウトプット層で詰まっていると、その先に進めません。
本当に見たいのは、アウトカムの方
私は何度も同じ違和感を感じていました。
AIを入れると、議論の中心が「どれだけ早く、どれぐらい綺麗に作れるか」に寄りやすい。エンジニアの仕事は、作ることではない。作ったものがお客さんを助けるか。業務が楽になるか、早くなるか、新しい価値が生まれるか——そこを本当は考えなきゃいけない。ただ、AIの文脈ではそこにフォーカスすることがあまりない、と。
問いは持っていました。でも、数字や観測の話まで踏み込めませんでした。
もうひとつ、
「AIで開発がアップしましたっていうこのアップと、お客さんが良くなった・業務が良くなったという話を、同じぐらい倍になってますよね、という形でちゃんと取らないと、ただの芸術作品みたいになってしまう」
アウトプットが増えたことと、アウトカムが増えたことを、同じ重さで見ないといけない。開発が速くなっただけでは、プロとしての仕事にならない——その感覚は、以前から持っていました。
SNSで「AIでこれができました」という投稿を見るときも、同じ違和感がありました。「結果、お客さんどうなったの、まで書かれていることはほとんどない」自分もそう感じていました。作れた、速くなった、きれいになった。アウトプットの話は溢れている。でも、その先の顧客の変化までは、ほとんど語られていない。
だから私にとっての本丸は、アウトカムです。顧客の業務がどう変わったか。ユーザーがどう動いたか。現場の負担が実際に減ったか。アウトプットはそのための手段であって、目的ではありません。
うちは今、どこにいるか
では、iCAREは今どこにいるのか。できるだけ正直に書きます。
アウトプット層：今、ここを改善中です。しばらくここになりそうです。
#1〜#4で書いたことが、そのまま当たります。コーディングの高速化、ボトルネックの連鎖移動、AIワークフローの整備、判断と役割の変化。開発チームの中では、目に見える変化が次々と起きています。活発に動いている層です。
一方で、まだ詰まっている場所も見えています。「何を作るか」「どうあるべきか」——要件定義やビジネスドメインの調整が絡む領域は、まだAIの効率化が十分に届いていない。ボトルネックが、開発の手前に移ってきている、という感覚があります。
アウトカム層：問いはあるが、観測はまだ十分ではない。改善中です。
顧客の業務がどう変わったかを、データから継続的に観測できるレベルには、まだ至っていません。機能をリリースしたあとに「使われているか」「業務が楽になったか」を素早く確かめる仕組み——ここはこれから整えていく段階です。問いと違和感はある。数字としての実感は、まだ弱い。
「アウトプットは増えたが、アウトカムはまだ数字として実感がない」——私が口にしていた感覚は、まさにこの状態です。
事業インパクト層：これから。今の段階では語り切れない。
売上、チャーンレート、工数削減。開発したものが経営にどう効いたかを、開発チーム単体で説明できる状態ではまだありません。アウトカムの観測が整って初めて、ここに橋を架けられる話です。
隠すことでも、恥ずかしいことでもないと思っています。多くの組織が、今ここにいるのではないかと思います。
#1から#4は、アウトプット層の記録だった
振り返ると、シリーズの4本はこう読めます。
#1は、ボトルネックが開発の中でどこに移動しているか。#2は、アウトプットを出すための前提、言語化とコンテキスト、が整っているか。#3は、アウトプットの質を誰がどう判断するか。#4は、アウトプットを出す人の役割がどう変わるか。
いずれも重要な話です。アウトカムを見に行くための足場でもあります。言語化が進まない組織では、アウトカムの議論もできません。判断できない人間が増えた組織では、速く作ったものが顧客に届く前に止まります。
ただ、足場を整えることと、目的地に着くことは別です。#1〜#4は足場の記録でした。この#5は、目的地の方角を示す記事です。
これから見に行くもの
AIを入れた組織に求められることは、段階的に上がります。
まずアウトプット層を整える。ボトルネックを追い、ワークフローを整え、判断の質を上げる。うちは今ここです。しばらくここに留まると思います。
次にアウトカム層を見る。リリースした機能が、顧客の行動や業務にどう効いたかを観測する。問いを持つだけでは足りません。観測の仕組みが要ります。
その先に事業インパクトがある——アウトカムが積み上がって、売上や継続率、コストに波及したかを見る。
広木さんの記事でいうレベル1からレベル3への階段と、同じ構造です。レベル3の生産性が低いからと言って、レベル1の生産性が低いわけではない——その整理も、うちの状況に当てはまります。アウトプットは改善している。アウトカムと事業インパクトは、まだこれからです。
私がこれから意識したいのは、「開発が速くなった」という報告と、「顧客の業務が変わった」という報告を、同じ重さで聞くことです。前者だけが上がってくる組織は、アウトプット層に閉じこもります。後者の問いが自然に出てくる組織が、AIを前提に意思決定している組織だと思っています。
手段が目的化しないように——作ることやAIを鍛えることではなく、最終的にお客さんに提供する価値は何か、を考え続ける。インタビューのときに自分が語っていたことですが、今もそれが一番の課題です。
終わりに
このシリーズを書き始めたとき、「AI活用している会社」ではなく「AIを前提に意思決定している組織」として伝えたい、という話がありました。
#1〜#4は、その入り口でした。現場で何が起きたかを、嘘なく記録する。速くなったことと、疲れたことと、違和感の両方を載せる。
#5は、その先です。アウトプットの先にアウトカムがある。アウトカムの先に事業インパクトがある——その階層を共有し、今どこにいるかを正直に言う。
答えが全部出ている記事ではありません。アウトカムを数字で語れる段階にもまだありません。でも、見に行く方向は決めたい。
#1で書いた通り、ボトルネックは消えません。移動し続けます。アウトプット層のボトルネックを追いかけながら、アウトカム層の観測を整え、事業インパクトまで橋を架ける。その両方を、これから続けます。
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」を共に開発していくエンジニアを募集しています。 これまでの経験を活かし、複雑な社会課題の解決に技術で挑戦したい方、ぜひ下記より詳細をご覧ください。
