「要件定義は社会常識である」――IPAが説く、AI時代の上流工程改革

NTTデータ、経済産業省CIO補佐官、内閣官房、デジタル庁データ戦略統括を経てIPAへ。日本のシステム開発の上流工程と向き合ってきた平本 健二氏が、生成AIブームのいま繰り返し説いているのは「要件定義の重要性」にほかならない。プロンプトもAI駆動開発も、本質はAIに何を伝えるかという話だ――。AI時代の上流工程はどう変わるべきか。平本氏に聞いた。

データもソフトウェアもAIも、根っこは要件定義

――NTTデータから経済産業省、内閣官房、デジタル庁を経てIPAへ。データ、ソフトウェア、AIまでを横断する立場で、いま何を最大のミッションと捉えていますか。

根っこの問題意識はずっと変わっていません。「要件定義をきちんとやろう」、これに尽きます。

NTTデータでソフトウェアエンジニアリングを身に着け、コンサル会社を経て経産省CIO補佐官、内閣官房政府CIO上席補佐官として政府全体のシステム設計とマネジメントを担ってきました。デジタル庁ではデータ戦略担当として日本全体のデータ戦略を設計し、現在IPAではデータ、ソフトウェア、AIを横断して担当しています。

IPAで取り組んだのが、ソフトウェアエンジニアリングのモダン化です。一般にモダン化と聞くとレガシー刷新を想起されがちですが、私たちの問題意識はそこにありません。モデリング手法を取り入れて、いかにアジャイルに開発を回せるか。1年取り組んだ結論は、「要件定義をきちんとやろう」というシンプルなものでした。2、30年前からモデリングの重要性を指摘し続けてきましたが、生成AIによってコード生成が加速したいまだからこそ、その重要性はさらに高まっています。

――プロンプトエンジニアリングやAI駆動開発など、生成AIをめぐる関心は次々に移っています。それでも要件定義に立ち戻るべき理由は何でしょうか。

プロンプトもAI駆動開発も、本質はどちらも要件定義にあります。プロンプトはAIに要件をどう伝えるかという手段で、AI駆動開発も、要件を定義したうえでコードを生成させる仕組みにすぎません。しかし、コード自動生成の話題に注目が集まるあまり、肝心の「何を作るか」が置き去りにされがちです。

仮にAIがコードを生成できたとしても、それだけでステークホルダー全員の合意を得るのは難しいでしょう。コードを見せて、経営層や非エンジニアを説得できるかといえば、多くの現場では無理があります。だからこそモデリング手法で要件を可視化することに意味があります。可視化されていれば、関係者全員で検証やシミュレーションが可能になり、合意形成にもつながります。

ソフトウェアにだけ「図面」がない

――もともと機械工学のご出身ですね。機械や建築では当たり前のモデリングとシミュレーションが、ソフトウェアには浸透していません。差はどこから生まれているのでしょうか。

自動車や建築の世界では、モデル&シミュレーションが前提です。しかしソフトウェアの世界だけはそこができていない。図面があり、シミュレーションで検証してから物をつくる。誰が図面を見ても同じものができる――これがエンジニアリングの基本です。

一方でソフトウェアは、要件定義のアウトプットが揺らぎのある文章のままになりがちです。その状態では、シミュレーションのしようがありません。ここに大きな差があります。

ただし、ソフトウェアでもモデル&シミュレーションができないわけではありません。要件をモデリングツールできちんと定義すれば、業務フローのシミュレーションは十分に可能です。たとえば窓口の受付業務で、来客数の変動や書類の差し戻しの確立、次工程への遷移といった条件を定義すれば、作業時間、コスト等を自動でシミュレーションできます。要件がモデルとして定義されているからこそ実現できることです。

逆に、自由に作業の流れを書いた、いわゆるフローチャートだけではここまでの分析はできません。あれはあくまで「イメージフローチャート」にとどまりがちで、解釈の揺れが生まれます。最新の手法によるモデリングツールは、記述の自由度にあえて制約をかけています。だからこそ、関係者全員が同じ理解にたどり着けるのです。

――国際標準や先進的なシステムズエンジニアリングでは、上流の要求定義やモデリングが明確に位置づけられています。一方で日本の現場では導入が進みにくい。その背景には何があるのでしょうか。

現場では作業マニュアルに従い作業を行います。要求工学などの技術の問題というより、マニュアルに対する文化の差です。日本のマニュアルは行間が広い。

たとえば業務システムで入力後に3秒待ってから次に進む処理がある場合でも、日本のマニュアルには「3秒待つ」とは書かれず、「画面が変わったら次に進む」といった表現で済まされがちです。「書かなくても分かるだろう」という前提があるわけです。

ところがAIにとってはこの“行間”が理解しにくい。海外のマニュアルは、労働者が頻繁に入れ替わっても大丈夫なように細かく記述されているため、AIにとっても扱いやすい構造になっています。日本のマニュアルが悪いと言っているわけではありません。行間が広い分だけ創意工夫の余地があるわけです。

日本でAI導入を進めるのであれば、こうした暗黙的な部分を明示的に記述する領域と、対面の接客やおもてなしといった人が担う、工夫できる領域に切り分けて考えていく必要があると考えています。

ビルディングブロックとデジタル公共財

――要件をモデリングで明確化していくことは、開発の進め方をどう変えますか。再利用や標準化のレイヤーまで広げて伺いたいです。

要件がきちんと定義されれば、再利用可能な部品を組み合わせる「ビルディングブロック型」、いわゆるモジュール型の開発を進められます。たとえば「証明書を発行する」という業務には共通する処理がいくつもあるのにもかかわらず、現場では毎回ゼロからコードを書いているケースが少なくありません。「自分で書いたほうが安心」という人はまだ多いのですが、実績のあるモジュールを再利用したほうが、結果として品質は安定します。

この発想を社会全体に広げたものが「デジタル公共財」です。オープンソースや、IPAが進めているデータ標準化はその代表例です。実際には、氏名一つ取っても、姓と名を分けるか、間を全角にするか半角にするかは会社ごとに形式がばらばらで、そのままではシステム間の連携ができません。共通語彙基盤（IMI）や、デジタル庁が提供する政府相互運用性フレームワーク（GIF）は、こうした氏名・住所などの基本データ項目を構造化し、海外の語彙や国際標準との相互運用性を確保するために整備されています。

ただし、現場には既存データや業務があり、簡単に変えられるものではありません。標準化は一朝一夕には進まず、長期的に取り組む必要があるテーマです。

説明責任の時代に、要件定義は社会常識になる

――AIを組み込んだシステムが社会に広がるほど、安全性や説明責任が問われます。上流工程で何を組み込んでおくべきでしょうか。

答えは可視化です。モデリングによって、システムの構造や判断ロジックを追跡可能な状態にしておくことが重要になります。事故が起こったら翌日には記者会見しなければならない時代、トレース（原因特定）の速さが何より重要です。

従来はコードを追って原因を特定していましたが、いまはモデルのレイヤーで“どこの論理がおかしいか”を把握できるようになっています。モデル上で「このブロックに間違いがあります」と問題箇所を示せれば、原因特定と説明のスピードは大きく向上します。

もう一つ重要なのが、データの来歴、いわゆるプロベナンスです。データが間違っていた場合、どこから来て誰がいつ加工したのかを辿れる仕組みが求められます。従来型のセキュリティ対策に加えて、上流工程からのトレーサビリティを組み込むこと――これが今後のシステムに求められる要件だと考えています。

――6月開催の「AI要件定義サミット2026」では、来場者に何を持ち帰ってほしいですか。

要件定義は、ソフトウェア開発のためだけにあるものではなく、日常の中にもあります。「今夜は何を食べるか」を決めるときの、「さっぱりしたものがいい」「辛いものがいい」こういったやり取りも、全部要件です。道に出たら車に轢かれないよう右と左を見るのも、耳をそばだてるのも要件。法律も「こういう条件ならこう扱う」という意味で、要件定義の一種といえます。

みんながこの基本を理解していれば、ものづくりスピードは上がり、コミュニケーションも円滑になります。AIに対しても的確な指示が出せるようになるでしょう。その入り口となるのが、要求工学（リクワイアメント・エンジニアリング）の基礎です。ゴール、コース、制約条件、ステークホルダーといった観点を押さえるだけで、考えの抜け漏れをチェックすることができます。

以前、情報サービス企業の方に同様の話をした際に、「要件定義はソフトウェアの専門用語じゃなくて、生活全般に役に立つ話として広めるといいですね」と意見をいただきました。私もその通りだと思っています。

サミットで持ち帰っていただきたいのは、この一点です。「要件定義は社会常識である」――そう捉えていただければと思います。