SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

トランスコスモス・デジタル・テクノロジーが目指すエンタープライズ×AI駆動開発(AD)

AI駆動開発の恩恵を受けるのは、上位20%のエンジニアだけ? 大規模開発導入のカギは「開発標準化」

DeveloperZine編集部[著] / 関口 達朗[写]

 AIによるコード生成は検証の段階を越えたが、エンタープライズ開発においては品質とガバナンスをどう担保するかという課題が残っている。この課題に取り組むべく、トランスコスモスグループとして、Procedural Agent・QA Agent・Coding Agentの3つのエージェントと、開発標準を集約した「Agent Knowledge Base」で構成されたAI駆動開発環境「Waterfall Boost」を構築した。出発点にあったのは、5、6年続けても浸透しなかった開発標準化の取り組みだ。トランスコスモスの上席常務執行役員としてグループ全体の開発組織を統括している、株式会社トランスコスモス・デジタル・テクノロジー代表取締役社長の所年雄氏に、この構成に至った設計判断と、人の判断をどこに残したのかを聞いた。

AI駆動開発の恩恵を最大限享受するのは、上位20%のエンジニア

 エンタープライズにAI駆動開発を組み込めるか。この命題を考えるとき、日々開発現場の伴走支援に取り組む中で所氏に芽生えたのは、AI駆動開発が持つ「属人性」への懸念だった。所氏の見るところ、取り組みの多くは「AIに興味があるエンジニア」に依存する形で社内に広げようとしており、リードするエンジニアの思いや考え方が開発環境に強く反映されていた。

 なぜ、AI駆動開発によって属人性が生まれるのか。所氏はその理由を、AI駆動開発には高いスキルが求められるからだと指摘する。バイブコーディングをはじめとするAIを活用した実装は、技術レベルの差を埋めるものとして語られることも多い。しかし、所氏の認識は真逆だ。

 「AI駆動開発を本当の意味で活用できるエンジニアは、構造的に2割しかいない、という考え方をしています」

株式会社トランスコスモス・デジタル・テクノロジー 代表取締役社長 所年雄氏
株式会社トランスコスモス・デジタル・テクノロジー 代表取締役社長 所年雄氏

 所氏の指摘によれば、「AIにコードを生成させる行為」としてのバイブコーディングを使いこなせるのは、実のところトップ20%のエンジニアだけだという。理由は従来のエンタープライズ開発の構造だ。これまで、スキルに応じて担当する工程が分かれており、新人はテストと実装の下流を、力のあるエンジニアが上流を担っていた。ところがAIを使うと全工程が短時間にまとまってアウトプットされるため、すべてを同時に進行させなければならない。一人が全工程の知識を持っていることが前提であり、従来のエンタープライズ開発の構造とは相性が悪いのだ。

スキルの高いエンジニアほどAI駆動開発のメリットを享受できる

スキルの高いエンジニアほどAI駆動開発のメリットを享受できる

(引用:「Developers Summit 2026 Summer」における所氏の発表スライド)

 AIによってスキルが不要になったという理解についても、所氏は否定した。

 「スキルが不要になったのではなく、求められるレベルが上がっただけです。その一方で、今まで100人いなければできなかったことが、トップの20人だけでもできるようになりました」

 そして、トップ20%のエンジニアがAI駆動開発を積極的に進めることで、より一層開発の属人化は進んでしまう。

AIの登場は、開発標準化を教え、属人化を解消するチャンスだった

 所氏はここで、属人化によって起きるエンタープライズ開発の現実を整理した。

 「システム開発は時として辛い。なぜ辛いかというと、やはりトラブルが起きるからです」

 最初にプログラムが書けるようになったときの嬉しさが、時に辛さに変わってしまう。所氏自身「プライベートでソースコードを書くのはすごく楽しい」と感じながら、一方では開発中のトラブル、納品前の不具合修正、納期に間に合わせるための追い込み作業に向き合ってきた。だからこそ、この状況を変えて、エンタープライズ開発を一生続けたいと思える仕事にしたかったのだ。

 所氏が辛さの原因として挙げるものこそ、開発の作法や工程を進める「ルールの属人性」だ。会社や人によってやり方もドキュメントも異なるため、プロジェクトをリードする人のレベルによって抜け漏れが生じる。要件が決まらないまま実装が進めば、納品時にクライアントから成果物が要望したものと違うと指摘される。

 そこで所氏は、同社で徹底した開発標準化に取り組んだ。作成すべき上流工程のドキュメント、コーディングポリシー、UIのルールを定め、勉強会も開いた。この取り組みはAIが登場する以前の2020年頃から続けてきたが、成果は出なかった。

 「開発標準化はなかなか浸透しませんでした。実際の業務時に、標準化のドキュメントを逐一確認する人は少なかったです」

 同じことは機能開発でも起きた。ログイン機能など、多くのシステム開発で必要になる機能を完成品の部品として用意し、新規開発のたびに組み込めるようにした。それでも現場では毎回新たにログイン機能が作られた。標準化の難しさに直面していた最中、登場したのがAIだった。

 「人間が書くと、どうしてもソースコードに愛着が生まれていきます。一方で、AIはルールベースでコードを書くので、まずはAIに開発標準化を教えようと考えました」

 人間がどのような指示を出しても、AIはおおむね標準の中で動く。標準化を進めるほど、人間が求めるものと会社が定めた要件の両方を満たす成果物を作れるのではないか。それが同社のAI駆動開発の基盤である「Waterfall Boost」を作る最初のきっかけになった。

プロンプトエンジニアリングでは、言語化能力の差が如実に出る

 「Waterfall Boost」という名前のとおり、同社が構築するAI駆動開発環境は要件定義から保守運用までの従来のウォーターフォール工程を踏襲している。工程を組み替える選択肢もあったはずだが、所氏はこの選択について必然だったと振り返る。

「Waterfall Boost」の概要
「Waterfall Boost」の概要(引用:「Developers Summit 2026 Summer」における所氏の発表スライド)

 背景にあるのは潮流の変化だ。生成AIが登場した当初はプロンプトでいかに分かりやすく、的確な指示を出すかがエンジニアの能力だと言われていた。それが仕様駆動開発やPlanモードなど、決まり事を先にドキュメントへまとめ、AIに認識させてから指示を出す方向へ潮流は移ってきた。

 上位20%のエンジニアが優れているのは、抽象的なことを言語化する能力だと所氏は話す。なぜなら、これまで優れたエンジニアがやってきたことは「PCが理解しやすいシステムの書き方をプログラムにする」という作業であって、現在はその対象がPCからAIに変わっただけだからだ。

 クライアントが漠然と語る内容を要件にまとめ、システムの形に作り直す。その翻訳こそ能力差が最も出る部分であり、だからこそプロンプトエンジニアリングでは出力品質が人によって異なった。

 そこで所氏が目をつけたのが、以前から開発標準化の取り組みを進める中で作ってきたウォーターフォール開発に対応するドキュメントだった。工程の順番を踏めば形になるという手順が確立されている以上、そのドキュメントをプロンプト代わりに使えばよい、という発想だ。

 従来のエンタープライズ開発において、不具合が発生する主要な原因の一つには要件定義段階の仕様書作成にあると所氏は考えている。

 決めるべき要件が決まらないまま進む。詳細設計書を作らずに基本設計書から直接実装してしまう。その結果、必要な機能が欠落する。Waterfall Boostはこの抜け漏れを許さないエージェントを実装した。人間がプロセスを省略できない機能を置くことで、プロンプトを書けない人でもAI駆動開発ができるようにする設計だ。

 また、ウォーターフォールには、ナレッジが蓄積しやすいという利点もあった。業界向けテンプレートとして仕様書を用意しておけば、そこを決めない限り次に進めないという縛りを設けられる。使うほどノウハウが溜まる構造を作りやすい。

あえてエージェントのナレッジを一元管理する

 Waterfall Boostは3つのエージェントで構成されるが、3つの分割は始めから決まっていたわけではない。最初に生まれたのは、ドキュメントの品質をチェックするQA Agentだ。

 先述した通り、ウォーターフォール型でトラブルのないシステムを作るなら、ドキュメントが非常に重要だ。そこでまず、人間が作ったドキュメントをAIがチェックし、問題点を指摘する仕組みを作った。当時はその先のコーディングやテストを人間が行っていた。

 当時、実装工程を担うのは人間だったが、それでも効果はあった。AIのチェックでOKが出ない限り次の工程へ進めないという縛りによって、ドキュメントの質が安定したのだ。

「QA Agent」はウォーターフォールの各工程における成果物をチェックする

「QA Agent」はウォーターフォールの各工程における成果物をチェックする

(引用:「Developers Summit 2026 Summer」における所氏の発表スライド)

 そして、次に開発したのがCoding Agentだ。QA Agentにより、質の高いドキュメントが揃ったため、それをそのままAIに流し込もうとしたが、通常のLLMでは想定どおりの成果物が上がってこなかった。

 「外部のLLMにそのままドキュメントを流し込んでみると、想定外のものが出来上がってしまったり、セキュリティに穴があるものが出来上がってしまう可能性がありました」

 そこで、UIの作り方、機能ごとのコードの書き方、使用するライブラリといったルールを定め、その範囲で動くエージェントを用意した。これがCoding Agentだ。このエージェントには採用するライブラリやオープンソースを規定しており、それ以外は使わせない仕掛けになっている。

「Coding Agent」がAIによる実装をコントロール

「Coding Agent」がAIによる実装をコントロール

(引用:「Developers Summit 2026 Summer」における所氏の発表スライド)

 そして、QA Agent、Coding Agentを一つの流れで動かすにあたり、全体を管理する役割として、最後にProcedural Agentを開発した。従来、プロジェクトマネージャーが担っていたスケジュールや工程の管理を行うのがこのエージェントだ。

 QA Agent、Coding Agent、Procedural Agentはいずれも、開発標準を集約したAgent Knowledge Baseを参照する。業界やクライアントごとの特徴を吸収しつつ会社として定めた範囲で動くようドキュメントに収めてあり、強力な中央集権型のナレッジ管理だ。

「Waterfall Boost」ではノウハウやルールを必ず遵守する

「Waterfall Boost」ではノウハウやルールを必ず遵守する

(引用:「Developers Summit 2026 Summer」における所氏の発表スライド)

 一般的なAIエージェントの展開方法と比べて特徴的なのは、個々のエンジニアによる調整を認めていない点だ。

 「個人がAIをチューニングすることや、自分用にAIをカスタマイズするスキルファイルやルールファイルを置くことはできず、すべて一元管理しています。もしかしたら開発における楽しみが少し減ると感じる人もいるかもしれませんが、私は開発を標準化することこそ、品質を上げて、トラブルを減らし、最終的に楽しく仕事ができる環境につながると信じています」

 所氏はあくまで「開発標準化」をベースにしたAI駆動開発の実現を目指している。それは、属人化の解消こそが、エンタープライズ開発におけるAI活用のカギである、という考えからだ。

エージェントによるQAの性能を上げたのは、過去10年に人間がしてきたレビュー

 ウォーターフォール開発における仕様書の重要性はすでに広く知られているが、具体的にQA Agentはどのように品質の検査をするのか。このエージェントの特徴として、所氏は4つの視点を持ったLLMが7つのペルソナになってドキュメントを検査することを挙げる。

 1つは営業視点で、提案書としてRFPなどの要求に答えられているか、受注できる内容かを見る。2つ目は運用視点で、完成後に現場でオペレーションしやすい設計かを判断する。3つ目はテストと品質の視点で、ソースコードまで進んだときに本当に動くものが出来上がるかを推測しながら全ドキュメントを見る。4つ目はアーキテクチャとして最適かを見る。

 この4つの視点は、QA Agentの開発にあたって所氏が設計したものではない。同社には品質戦略部という、プロジェクトの進行を品質面からチェックする部隊があった。QA Agentが仕様書を検査する観点は、品質戦略部のレビュアーが普段使っているチェックリストを落とし込んだものだ。

 また、LLMに生成AIの成果物を評価させる手法(LLM-as-a-Judge)は、スコアが安定しないという指摘も聞く。この問題への向き合い方として所氏が挙げたのは、これまでに積み上げてきた社内のドキュメントだった。

 「過去のプロジェクトでうまくいった、正解とも呼べるドキュメントがあるので、どれだけその理想とするドキュメントに近い状態になっているかという近さでスコア化しているのが一番の柱になります」

 理想形は10数年のレビューの蓄積ですでに出来上がっており、それをAIに教えた。これまでトランスコスモスグループとして積み上げてきた仕様書作成のノウハウが、AI時代にQA Agentという形で結実した。

実装を知る最後の世代として、課題解決の担い手になる

 開発標準をエージェントに参照させる方法は、リポジトリ内に規約を置く分散型が主流になりつつある。先に紹介した強力な中央集権型のナレッジ管理、「Agent Knowledge Base」を選んだメリットとして所氏が挙げたのは、上流工程の成果物の質だ。

 「(中央集権型のナレッジ管理があれば)質の高い仕様書を作成することができて、どんなスキルレベルの人がClaude CodeなどのAIエージェントに投げても一定レベルのものが実装できます」

 分散型は全工程を同じ人、ないし同等のスキルレベルの人が担う前提であるが、中央集権型であれば各工程を異なるスキルレベルの担当者が担うことができる。

 ナレッジの更新は自動化されている。高い評価を得たドキュメントは汎用化・テンプレート化され、Agent Knowledge Baseに登録される。使えば使うほどナレッジが増える構造だ。

 同社で運用するなかでは、想定していなかった副次的な効果が見つかる場面もあった。人材育成だ。

 実装工程が減ればエンジニアの仕事は上流と判断に移るが、上流工程ができる人材はもともと不足している。まして、従来一般的であった下流工程を経験し、徐々に上流に立場を移す育成方法そのものも失われかねない。

 ところが、Procedural Agentの開発で状況が変わった。若手メンバーの業務に同エージェントを伴走させると、AIが要件の詰め方やリスクへの対策を次々に問いかけてくる。考えていなかった観点を指摘されて、詰めておくべき点を初めて知る。繰り返すうちにAIが何を聞いてくるかを予測し、情報を準備して臨むようになる。これまで育成の現場にもあった「属人化」が、思わぬ形で解消されようとしている。

 最後に所氏は、AI時代のエンジニアの役割をこう語る。

株式会社トランスコスモス・デジタル・テクノロジー 代表取締役社長 所年雄氏

 「やるべきことは、クライアントの課題やボトルネックになっているものを解決すること。エンジニアにとって、その手段がシステム開発です。起点はあくまで解決すべき課題にあります」

 これからエンジニアになる世代は、実装工程を経験しないかもしれない。だからこそ、所氏は経験のある最後の世代に課題解決の担い手になってほしいと期待を寄せる。AIは万能ではない。顧客の情報を守りながら、その力をどう引き出すか。そこに、実装を知るエンジニアの知見が生きる。

  「今エンジニアをやっている人たちには、AIの力を安全に、最大限に発揮できる環境をつくり、サービスがクライアントにもたらすメリットを最大化してほしい。そこに、これまでシステム屋として培ってきた能力を活かしてほしいと思っています」というのが所氏の思いだ。

ドキュメント品質管理AI「QA Agent」無償トライアル実施中

 本記事でご紹介したWaterfall Boostを構成するエージェントの一つである、ドキュメントの品質管理を担う「QA Agent」を無償でお試しいただけます。ご関心をお持ちの方は、トランスコスモス・デジタル・テクノロジー公式サイトのお問い合わせフォームより「QA Agent無償トライアル希望」とご記入の上、お問い合わせください

この記事は参考になりましたか?

提供:株式会社トランスコスモス・デジタル・テクノロジー

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー