AIを導入して最初に困ったのは。

株式会社iCAREでDevelopment部 CTO 兼 PdMをしています、でんでん(@shogodenden)です。

本格的にAIを使い始めて、1年ちょっとが経ちます。この記事を読んでいる方も、すでに開発にAIを取り入れている方が多いと思います。コーディングが速くなった、調べものが楽になった——その恩恵は、肌で感じているかと思います。ここで書いているのは、個人の話ではなく、組織としてAIを組み込んでいく中で起きたこと、そこから見えてきた気づきです。まだ答えが出ていないことも多いですが、何かひとつでもヒントになれば幸いです。

このシリーズについて

開発メンバーへのインタビューを基に、AI導入後に起きた変化を私が観察・振り返りながら書いています。インタビュー記事のまとめではありません。現場の声は「こう返ってきた」という形で紹介しています。「生産性」や「アウトプット」をどう捉えるか——アウトプット・アウトカム・事業インパクトの3層については、シリーズ最終回の#5で整理しています。

AIは行間を読まない

「AIには行間が読まない」これは、AIが流行り始めた頃からよく言われていた話です。行間、つまりコンテキスト。指示の裏にある背景情報、過去の意思決定の経緯、なぜこの設計になったのかという暗黙の前提。それをAIは持っていません。だから渡してあげる必要があります。聞いたときは「まあそうだよな」と思っていました。

ただ、うちのプロダクトは今年でサービス開始から10年になります。

10年間、何人ものエンジニアたちが積み上げてきたコードがあります。でも、当時開発を担っていたエンジニアの多くは、もうチームにいません。なぜあの設計になったのか、あの意思決定の経緯は何だったのか——そういう情報はチャットの過去ログか、退職した人の頭の中にしかありません。

ドキュメント整備が開発において重要な課題であることは、エンジニアなら誰でも知っています。でも後回しにされがちな問題でもあります。目の前の実装を優先するうちに「ドキュメントは後で」になります。どの組織でも起きる話です。うちの開発部も例外ではありませんでした。

AIをワークフローに組み込もうとしたとき、その「後回し」にしてきたものが問題として現れ始めました。

AIに仕事を頼もうとしたら、渡す情報がなかった

AIをきちんとワークフローに組み込んでみようという話が出てきたのは、AI導入から半年ほど経った頃でした。

「コンテキストを渡せば動く」という話は聞いていました。実際、個人レベルで試している人間はいました。うまくいっている場面もありました。だから組織としてきちんと使える形に整備しようと思いました。

そのとき初めてわかったのは、「渡すべきコンテキストが、そもそも組織に存在しない」という問題でした。

エンジニアが、その苦労を言語化してくれた。

そうなんだよな、と思いました。組織の情報はどこにあるかというと、チャット、メール、人の頭の中、過去の会議の空気感。そういう場所にあります。AIには渡せない情報です。

「死ぬほど優秀な新卒に、何も教えていない状態」

この問題を的確に言語化してくれたのが、エンジニアの比喩でした。

この比喩はよくできていると思いました。

問題はAIが賢いかどうかじゃありません。むしろAIは十分賢いです。問題は、渡すべき情報が言語化されているかどうかです。

社内独自のルール、過去に失敗した理由、この案件にはこういう背景がある——こういう情報は、人間なら行間で読み合えます。でもAIは行間を読みません。行間にある情報を、存在しないものとして動きます。

だから、行間に頼って動いている組織では、AIをうまく使えません。

「すべてドキュメント化されている組織なら、AIはやりやすい」

エンジニアは、組織の成熟度についてもう一段踏み込んで語った。

「そうでない会社の方が圧倒的に多い」という部分が刺さりました。

AI活用が進んでいるかどうかの差は、AIツールの選定でも、プロンプトのうまさでもなく、「どれだけ組織の情報が言語化されているか」で決まる、という話です。

エンジニアからも、同じ方向の指摘があった。「きちんと各々の判断軸がすべて言語化されていれば、AIは動けるはずだ」。

言語化が、AI活用の天井を決めます。この構造を認識したのはAIを本格的に入れてから半年後でした。入れる前は、こういう問題があるとは思っていませんでした。

予想外の副産物。AIを入れたら、ドキュメントが増えた

ただ、ここには逆説的な副産物がありました。

AIワークフローを整備しようとすると、「きちんと情報を渡さないと動かない」という圧力が自然に生まれます。その圧力が、言語化を促しました。

ドキュメントが増えた話を聞いたのも、同じエンジニアだった。

AIワークフローを入れる前と比べて、GitHubに追加されるドキュメントの数が明らかに増えているというのです。

AIが、組織の言語化を促す触媒になっていました。これは想定していなかった変化でした。

言語化されていないから動かない、でも動かそうとすれば言語化が進む。この構造が、組織にとってのリハビリになっています。

誰かが指示したわけではありません。AIを動かすために必要だったから、自然にそうなりました。強制されたわけじゃないのに、組織が変わった。それがこの変化の面白いところだと思っています。

AIは行間を読みません。だから、行間に頼っていた組織は、AIを入れた瞬間に「言語化」を迫られます。

「AIを使うと仕事が楽になる」という話はよく聞きます。でも実際には、AIを本気で使おうとすると、それまで曖昧にしていたものを明文化する圧力がかかります。その圧力に向き合えた組織が、少しずつAIと一緒に動けるようになっていきます。行間を埋める作業は大変です。でも、その作業を通じて組織が少しずつ言葉を持つようになっていきます。AIを入れた副産物として、それは悪くない変化だと思っています。

iCARE開発部では、その気づきをチームの構造に落とし込みました。日々の開発タスクの中で得た知見を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」を共に開発していくエンジニアを募集しています。 これまでの経験を活かし、複雑な社会課題の解決に技術で挑戦したい方、ぜひ下記より詳細をご覧ください。

herp.careers X02_オープンポジション(社員リファラルもこちらから)

株式会社iCARE

募集要項をみる