数十年分のレガシーシステム。100を超えるサービスドメイン。肥大化したドキュメント。

AI前提に組織を変革する「AX（AI Transformation）」を進める上で、これほど難しい条件がそろった企業はそう多くない。

LINEとヤフーの合併から約3年。大企業のAX推進の渦中に立つCTO・朴イビンさんが、実に7年ぶりのメディア登場としてエンジニアtypeの独自取材に応じてくれた。

朴さんは、多くの企業が苦戦しているAXにおいて、「着手する順番」の重要性を強調する。中でも先に取り組むべきなのは、AIツールを導入することそのものではなく、組織や仕様をAIが理解できる状態に整えることだという。では、LINEヤフーではいかにしてAI前提の開発組織を実現しているのか。そしてそこでは、エンジニアの仕事の本質はどう書き換わるのだろうか。

巨大組織の変革を率いるCTOが、その舞台裏を語った。

最初の一手を誤ると、AXは失敗する

ーーLINEヤフーでは現在、全社を挙げたAXへと舵を切っていますよね。ですが昨今、多くの企業が「GitHub CopilotなどのAIツールを全社導入したものの、現場の生産性が劇的に上がった実感がない」と頭を抱えています。どこに問題があるのでしょうか？

AI駆動開発を試すこと自体は、ある程度の技術力があれば誰でもできるんです。でも、それを既存のプロダクト開発に本格的に組み込もうとすると、全く別の壁に直面します。

ここで最も重要なのは、AIツールを入れることではなく、組織やプロダクトを「AI Ready（AIが自律的に動ける状態）」にすることです。

ーー「AI Ready」とは、具体的にはどのような状態を指すのでしょう？

一言で言うと、AIが自律的に動ける状態です。仕様や前提条件をAIが理解できる状態に構造化していなければ、どれだけ綺麗なコードが出力されたとしても、結果的に仕様とは全く異なるものが出来上がってしまいますから。

高品質なAI駆動開発を行う上では、コーディングの手前にある準備に、組織としてどれだけリソースを投資できるかが全てと言っても過言ではありません。

ーーツールを入れて満足するのではなく、組織から変えていく必要がある……ということですね。

そうですね。開発プロセスの一部だけをAI化しても、必ず別の場所でボトルネックが生じます。

意思決定に時間がかかる、上位者の承認がないと動けない、特定のラインでしか物事が進まない……といった課題を残したままでは、AIによって一部の工程が効率化されても、全体のスピードは上がりません。

AI Readyな組織をつくるには、まずは開発プロセスや組織上の歪みを洗い出すことが必要です。そして、「どこを自動化し、どこを人間が担保すべきか」を一つずつ検討し、改善していく。そんな、組織を変えていく粘り強さが求められます。

30年のレガシーが蓄積した現場の再設計へ

ーーLINEとヤフーが合併してまもなく3年。サービスドメインは100を超え、長いもので約30年の歴史を持つ、一般的には「レガシー」との見方もできる環境です。その組織のAX化となると、正直なところ気が遠くなるのですが……。

私としても、今でも難しさの連続です（笑）。歴史が長いプロダクトほど、「どの情報が最新か分からない」「仕様の把握が完全に属人化している」という闇を抱えていますから。

そこで私たちは、「SSOT（Single Source of Truth：単一の正しい情報源）」を再構築することから始めました。

ーーなぜ、そこからだったのでしょう？

AXの本質は、コーディングそのものではなく、その前段階にある「企画」や「設計」にあるからです。

まずは、巨大なプロダクトを適切なコンポーネントに分割し、依存関係を全て可視化しました。そして、これまで人間に向けて作られていた仕様書やドキュメントを、AIが完璧に理解できる形へと徹底的に構造化・再翻訳していったんです。

ーー地道な作業が重要だ、と。具体的な成果は出ているのでしょうか？

この1年間で、AI向けに構造化した設計書の数は約46倍に増加しました。その結果、AIが即座に活用できる状態まで整備されたリポジトリの割合は、全社平均で約15％に達し、全社で生成されるコードの約20％はすでにAIが担っている状態です。

これはあくまでもLINEヤフー全体の平均値なので、プロダクトによっては9割近くのコーディングをAIでカバーしています。

ーーただ、既存のやり方を変えるとなると、現場からの抵抗が起こりそうです。

現場にはやるべき業務が数多くありますからね。『やりましょう』と呼びかけるだけでは不十分です。なので、目標を設定し、それを評価につなげる仕組みまで整えることで、優先順位を上げていきました。

大きな変革を起こすためには、個人の力では限界があるのも事実です。組織全体として取り組まなければ本当の意味でのAXは成し得ませんから、誰か一人が疲弊するのではなく、仲間と接点を持ちながら取り組める組織をつくる必要があるでしょう。

「書く喜び」は不変。変わるのは仕事と責任の範囲

ーーエンジニアに対して、朴さんは2019年のインタビューで「コードを書き続けたい」という現場志向のエンジニアに寄り添う言葉をかけてくださいました。しかし今、コーディングの役割はAIに移りつつあります。「コードを書きたい」という本能は、もう通用しないのでしょうか？

当時と今で、私の根底にある考え方は全く変わっていません。前提として、「コードを書く」というのは、単に「コーディングをする」ことだけを指す言葉ではないと考えています。現場に立ち続け、技術をリードしていく。それも「コードを書く」ことに含まれているんです。

今やコーディングは、AIが最も得意とする領域になりました。ですが、「世の中に価値ある成果を届ける」という目的は、今も昔も変わらないはずです。

ーーつまり、手段が変わっただけだと。

そうです。むしろAIのおかげで、挑戦できるアイデアの数は何倍も多くなっています。AIはエンジニアから創る喜びを奪う存在ではなく、これまでリソース不足であきらめていた挑戦を無限に可能にする最高の相棒なのです。

ただ、その相棒と協働していくためには、エンジニアが担うべき役割と責任も広がっています。

ーー具体的に、どう変わっているのですか？

AIによる出力を評価し、品質を担保する最終責任は人間にあります。システム全体の仕様と品質に責任を持ち、リードしていく役割が求められるでしょう。

もはや、開発のことだけを考えればいい時代は終わりました。企画段階から要件を構造化し、組織のボトルネックを解消することも、これからはエンジニアの仕事になります。

ーーコードを書く本能を、システム全体を最速で駆動させる方向へとアップデートする必要があるんですね。

AIが得意な領域と、人が集まることでより大きな力を発揮できる領域は、それぞれ異なると考えています。繰り返しの実装やパターンの探索はAIに任せ、そこで生まれた時間を、重要なアイデアや設計についてより深く議論し、判断をすり合わせ、新たな価値を生み出すことに使う。これこそが、AI時代の開発組織が目指すべき方向ではないでしょうか。

「今のやり方が唯一の正解だ」と言い切れる人は、世界中に一人もいません。私自身も日々試行錯誤を重ねています。大切なのは、過去の成功体験にとらわれず、「できない理由」を探すのではなく、「どうすればできるか」を問い続ける姿勢だと思います。

加えて、「AIがあるから一人で何でもできる」と孤立するエンジニアは危険です。AI時代だからこそ、仲間と議論し、レビューし、判断をすり合わせる時間には、これまで以上の価値があります。

技術は進化しても、より良いものは、最後までそうした対話の積み重ねから生まれるものです。そして、その積み重ねこそが、AI時代の開発組織の強さにつながっていくのだと思います。

撮影／桑原美樹　取材・文／秋元 祐香里（編集部）