はじめに
前回は、アーキテクチャ設計の不在がコードの再利用や開発効率の低下を招いていることを見てきました。
今回はさらにその根幹にある「要件定義」について掘り下げます。
あなたの会社やプロジェクトでは、要件定義をどう捉えているでしょうか？
「業務部門にヒアリングして、欲しい機能をリストアップすること」
「画面モックを作って、業務の人がうなずけば合意完了」
─もしそのように考えているとしたら、それは「構造設計」の視点を完全に欠いたアプローチかもしれません。　

要件定義＝聴き取り調査ではない
日本の多くの現場では、要件定義を「ヒアリング中心の要望収集フェーズ」として捉えています。もちろん業務部門からのヒアリングは重要ですが、それはあくまで“素材”であって、“設計”ではありません。
本来の要件定義とは、「業務の構造を再構成し、戦略に沿った仕組みを設計するプロセス」であり、「業務の欲しいものを聞いてくる仕事」ではないのです。

業務部門は「あるべき構造」を言語化できない
現場からの要望をそのまま聞き出して実装するのは、一見「ユーザー志向」のように思えますが、実際には大きな落とし穴があります。
なぜなら、業務部門自身が「業務の構造」や「理想的な業務設計」を十分に把握しているとは限らないからです。現場の方が語るのは、多くの場合「現在の運用の不満」や「過去のシステムとの比較」です。
つまり、業務部門のヒアリングだけでは、
•業務全体の整合性
•組織横断の再利用設計
•データとプロセスの連動性
といった、アーキテクチャ的視点が抜け落ちてしまうのです。

本来の要件定義は「構造化のプロセス」であるい
本当に必要なのは、「聞く」ことではなく、「構造化する」ことです。
たとえば：
•類似業務をパターン化し、業務ドメインとして整理する
•各業務ドメインで必要とされるデータエンティティを明確化する
•ユースケースや業務フローをモデルとして描き、業務横断的に整合を取る
•可視化されたモデルを用いて、現場と“構造”について合意形成する
これが本来の「アーキテクチャ駆動の要件定義」です。
言い換えれば、EAの4階層の最上部であるBA（ビジネスアーキテクチャ）を、要件定義フェーズで設計することが、本来の目的なのです。

「ヒアリング駆動の要件定義」が招く悪循環
ヒアリング中心の要件定義では、以下のような悪循環が起こりがちです：
1.現場から出てきた「バラバラな要望」がそのまま要件となる
2.機能単位での実装が優先され、構造的整合性が取れない
3.新機能追加や変更時に影響範囲が読めず、保守が難しくなる
4.プロジェクトを重ねるたびに、システムが複雑化・属人化する
こうして、技術的負債が蓄積され、いつしか「抜本的な再構築」が必要になる──というパターンに陥ってしまうのです。

要件定義の“前”に必要なもの：BA設計フェーズの導入
•組織の戦略を読み解き
•業務構造を設計し
•ユースケースやデータ構造に分解し
•それを元に、初めて機能要件として定義する
このプロセスを通じて初めて、再利用性や変更容易性を持った「設計されたシステム」が実現できるのです。
アーキテクチャ駆動型要件定義の具体イメージ
たとえば、顧客対応業務のシステムを設計する場合：

このように、要件定義の質がまったく変わってくるのです。

次回予告：日本企業に「アーキテクト」が育たない理由
第4回では、そもそもこうしたアーキテクチャ設計を担うべき「アーキテクト人材」が、なぜ日本では育たず、制度上も確立していないのか？──について掘り下げます。
戦略と業務とITをつなぐ「橋渡し人材」が不在なままでは、いくら手法を学んでも根本的な変化は起きません。人と組織の観点から、EA実践を阻む壁を見ていきます。

第1回：EAの4階層モデルが「理屈」で止まっている問題
第2回：アーキテクチャ不在が、再利用性・保守性の低下を招く構造

合同会社タッチコア　代表　小西一有