「成果物を先に出す」と、開発はどう変わるか――日立製作所が示すプロセス転換と要件定義のギャップ

空き缶を3個積むのと、100個積むのは違う。100個となれば、土台の設計も強度計算もいる。日立製作所の広瀬 雄二氏は、エンタープライズシステムの要件定義をこの比喩で語る。6月11日に開催された「AI要件定義サミット2026」で、広瀬氏は「要件定義の認識ギャップをどう埋めるか〜AI×ローコードによる合意形成の実践アプローチ〜」と題して登壇した。銀行システムを20年以上担当し、その知見を日立グループの開発標準として広めてきた人物である。生成AIで実装は速くなった。だが、何もないところから書き起こす上流ほど、業務側と開発側の認識ギャップは残る。広瀬氏が示したのは、AIとローコードを活用して30分程度で動くアプリを生成し、それをたたき台として業務側と開発側の認識を早期にすり合わせるアプローチだった。

空き缶3個と100個は、積み方が違う――エンタープライズ要件定義の構造的課題

要件定義で生じる認識のズレは、担当者の力量の問題ではなく、エンタープライズ開発の構造そのものから生まれる。

広瀬氏は、これを空き缶の比喩で説明する。3個積むだけなら感覚的にできても、100個積むとなれば、土台の設計や強度計算まで考えないと崩れる。AIで小規模なアプリを素早く作れる時代になったが、大規模システム開発は単なる規模の延長線上にはない。そこには「量ではなく質の差」があり、より高度な設計と関係者間の合意形成が求められるのだという。

実際、エンタープライズシステムは画面・機能数が数百〜数千に上り、連携する周辺システムは数十、データ群も複雑に絡み合う。この物理量の大きさが、全体像の把握を一気に難しくする。広瀬氏は「勘がいい人でも、キャッチアップするまでには数週間かかってしまう」と振り返る。

しかも要件定義は、何もないところから始まる。目に見えない業務を自然言語の文書で形にするしかなく、関係者も成果物も多いため、合意までが長い。開発側は早く仕様を固めたいが、業務側は完成イメージが湧かないまま発注している――このすれ違いが、認識ギャップを生む。

日立はSIerとして大規模・複雑な業務システムに数多く関与し、構想・要件定義など上流工程にも参画してきたからこそ、この課題の根深さを知る。これは日立一社の悩みではなく、エンタープライズ開発に携わる誰もが直面する、共通の構造だ。

「リフトで山の中腹まで」――なぜ今、上流工程にAIが効くのか

ではどう解決するか。広瀬氏はここでも比喩を使う。「ドーンと山の途中までリフトやケーブルカーを使って上がっていく」。つまり、麓から1歩ずつ登るのではなく、中腹まで一気に引き上げ、その先を詰める。AIが、要件定義の出発点を押し上げる形だ。

転機は、近年のAIの推論力の向上にあった。曖昧な自然言語を読み取り、「こういう機能が必要だ」と構造化してまとめ直せるようになった。「曖昧なものをきれいに構造化してくれる」。整理済みのデータしか扱えなかった時代と違い、いまのAIは曖昧さを含む入力に対応できる。こうした変化が、要件定義をはじめとする上流工程へのAI適用を可能にした。

振る舞いも変わった。コマンドを打って応答を待つのではなく、「こういう仕事をしてくれ」「レビューしてくれ」と頼めば、まとめて動くエージェントのように使える。適用領域もコード補完に始まり、テストコード生成、設計書作成へと広がって、ついに上流の要件定義に届いた。

現場で起きていたのは、用語や背景の理解不足で質問すらできない停滞だった。そこにAIが高精度な初期成果物を持ち込めば、停滞は高速なサイクルに変わる。問題は、その初期成果物をどう作るか。広瀬氏の答えは、AIとローコードの組み合わせだ。

30分で動くアプリができる――AI×ローコードの実装

この手法は、複雑な仕掛けではない。ルールベースで動くローコード製品の入力をAIで作る――要点は、この組み合わせにある。

AIは曖昧な要件から文脈をくみ取って補完する創造性を持つが、出力には揺らぎが残る。ローコードは逆で、厳密に処理して再現性と本番品質を担保する。AIの創造力とローコードの確実性を掛け合わせると、画面からデータベースまで整合の取れたアプリを生成できる。コーディングエージェントで全部作る道もあるが、数百〜数千の画面を生成し、直し続けられる人財を集めるのは現実的でない。だからローコードを挟む。現時点では、この組み合わせが一番有力なアプローチだ。

入力は、わずか4行でよい。どんなシステムか、どんな顧客か、どの部署か、そしてどのような特徴や要件を持つか。これだけで動く画面が立ち上がり、要件定義に近い文書や画面一覧・帳票一覧などの基本設計成果物も同時に出る。さらに、デモや検証時に検索結果が0件になるような状態を避けるため、デモデータも生成する。

ユースケースは3つ。ゼロから立ち上げる「新規開発」、既存ソースコードを解析してローコードへ寄せる「ソースコードベース」、既存の要件定義書を起点にする「要件定義（一部）ベース」だ。新規開発ではジャスミンソフトのWagby、要件定義ベースではROUTE06のAcsimを用いる例が紹介された。いずれも入力から30分で動くプロトタイプが立ち上がる。

「30分後には、動くアプリケーションを作れます」。従来なら数週間を要し得るプロトタイプ作成を、30分でたたき台にできるという説明だ。セキュリティ上の脆弱性もある程度つぶしたコードが出るため、合意形成の出発点として、すぐ議論の俎上（そじょう）へ載せられる。

成果物先行――開発の「後半」を序盤に持ってくる

この手法は、開発の進め方そのものを変える。

従来は、要件を聞き、成果物を1つ作り、レビューして合意し、それを土台に次の工程へと積み上げてきた。これからは違う。一通り動く成果物がまず出て、それをベースに1つずつ完成度を高めていく。広瀬氏はこれを「段階的詳細化」と呼ぶ。

変わるのは、時間軸だ。完了条件やテスト項目を、序盤で合意できる。従来は、成果物が一通りできてから完了条件やテストの話に入るしかなかったが、その順序が逆転する。レビューも具体になり、「こんな感じか？」という推測のすり合わせから、動く成果物を前に「ここを直そう」へ変わる。

目指すのは、開発工程の後半のような状態を序盤につくることだ。後半は、関係者の誰もが設計の経緯や基準が頭に入っているため、意思決定が速い。その状態を早期に確立できれば、要件定義の局面は様変わりする。

人とAIの境界線――AIも読み手になる前提で設計する

人間の役割がなくなるわけではない。現時点では、ステークホルダーの特定や合意形成などを人間が担う必要がある、と広瀬氏は説明する。

誰が決裁権を持ち、関係者のパワーバランスはどうか。こうした特定は、現場で顧客と対話しながら詰めるしかない。フェーズゲートの設計や合意形成も、人間の腕の見せどころだ。レビューで生じるコンフリクトも同じで、たとえばセキュリティのため多要素認証を挟むか、利便性のため直リンクを許すか、どちらも正解になりうる。優先順位はAIに決めさせることも可能だが、「合理的に判断しました」で関係者が納得するとは限らない。最後は人間が知恵を絞る。

その先に、広瀬氏は1つの問いを置く。AIが成果物を生成するようになると、その成果物やUI、インターフェースを読むのは誰か。人間か、AIか。人間向けの曖昧な記述は、人間なら経験と勘で補えるが、AIが読むと、曖昧さは実装エラーに直結する。人間が読むだけでなく、マシンが読む前提で要件定義を設計し直す必要がある。

AIはもはや、コマンドを打つ道具ではない。「コマンドではなく、やってくれる別の開発パートナー」だと広瀬氏は言う。とすれば、仕事の振り方やマネジメントの対象にAIも入り、AI時代に合わせた役割の再設計が要る。

講演の終盤では、関連する枠組みとして「モダナイゼーション powered by Lumada」を紹介した。計画から実行、業務・IT刷新、データ管理、組織変革、人財育成までを含む広い支援体系で、今回のプロトタイピングはその入り口に当たる。

空き缶を100個積むには、土台から考え直すしかない。AIを「読み手」に迎えた要件定義も、いま同じ地点に立っている。何を機械に委ね、何を人が握るのか――その線引きを描けたところから、開発の序盤は姿を変えていくことになるだろう。