ビジネス要求とシステム要件は、区別しよう
データフローから描くか、E-R図から描くか
ずいぶん昔のことだが、診断士の研修会場で、たまたま先輩のOさんにあった。Oさんは今や独立コンサルタントとして、また税理士事務所長として活躍されているが、当時は大手SIerでIT関係の仕事をされていた。休憩時間の雑談の中で、Oさんはこんなことを言われた。
「佐藤さん、業務系のシステム設計の仕事をするときに、SEって二つのパターンに分かれるんですよ。片方は、最初にユーザ・ヒアリングからデータフロー図を書き始めるタイプ。もう一方は、E-R図を書き始めるタイプ。どっちの方が良い仕事をすると思います？」
わたしは、データ構造を考えてE-R図から考えはじめる方じゃないか、と当てずっぽうに（自分自身もそうなので）答えた。するとOさんはにっこり笑って、「そうなんです。見てるととね、データ構造から考えはじめるSEの方が、おおむね優秀なんです。」という。わたしは心中、胸をなで下ろしつつ、なぜなのかとたずねた。Oさんも、「うーん、何ででしょうね。でもそういう傾向はあるんです」と答えただけで、明確には説明されぬまま、別の話題に流れていった。しかしその問いは、長く頭の中に残った。
ところで、わたしは3月にフルタイムの会社員をリタイアしたが、最後の6年間は経営企画部門で「チーフエンジニア（ビジネス・アナリスト）」という肩書きだった。「チーフエンジニア」とは、日揮グループにおける特定の技術分野に関する部長職のようなもので、直接の部下は持たないが、その技術に関して全社内を横断的にリードしサポートする（全社で多分20〜30数名いると思う）。ただ、社内のIT戦略にはそれなりに関わったが、「ビジネス・アナリシス」の技術領域を深掘りして後進を育てたかというと、あまり胸をはってyesと答えにくい。
要件定義とビジネス・アナリスト（BA）の責務
ビジネス・アナリスト（BA）の主要な仕事は、「要件定義」である。これがまあ、普通のIT分野の理解であろう。要件定義が重要なことは、論をまたない。要件定義書は、システム設計の基礎である。ここを間違うと、その後の労力も投資も、ろくな果実を結ばずに無駄になってしまう。
要件定義がどういう仕事か、要件定義書はどんな構成で、何をカバーすべきか。こうしたことは、IPAなどの組織がガイドを整備してきたし、今なら生成AIにたずねると、すぐ詳しく答えてくれる。ところで、英語ならRequirements Analysisと呼ぶこの仕事を、日本では「要求分析」と「要件定義」に分けることが多い。一般に英米の方が、仕事は細かく専門分化するのに、この点だけはなぜか日本の方が進んで(?)いる。では、その両者は何が違うのか。
簡単に言うと、「要求分析」とはユーザの業務的な要求を分析し明確にすることで、「要件定義」とは、その要求を実現するために必要なシステム機能要件・非機能要件を定義することだ。そんな風に説明されることが多い。だがこれで、二つの仕事の違いが分かっただろうか？ 両者は同じ人がやるべきなのか、違う人がやるべきなのか？ 英語では同じRequirementsなのに、要求と要件では、何が違うのか？
この説明が分かりにくいのは、要求とか要件を、ITシステムの側だけから見ているからだ。ITシステムとは簡単に言うと、データを処理する仕組みである。データを入力し、処理し、保管し取り出して、出力する。その流れのプロセスを、機能と呼ぶ。今日の業務系システムはたいてい、RDBを用いる。そのテーブル構成をデータ構造と呼ぶ。設計し開発するためには、機能と構造に関する仕様が必要である。その仕様を、ユーザ要求から導き出したい。そう捉えるから、話が見えにくくなるのだ。
ビジネス・ニーズとシステム・リクワイアメント
これは、車の設計に置き換えてみると、分かりやすいかもしれない。自動車はおおむね、構造が決まっている。エンジンがあり、駆動力の伝達系があり、ボディがあり、タイヤがあり、ブレーキやハンドルなどの運転制御系がある。エンジンの出力をどれ位にするか、ボディのサイズや重量や剛性はどうするか。設計ではこうしたことを決める。ではユーザ要求から、これらをどう導き出すのか？
わたしが現在の車を買った時、わたしの側にはいくつか「要求」があった。家族は3人、息子はアイスホッケーという珍しい種目のスポーツをしており、やらたと細長くて場所ふさぎな道具を持って移動する。夜間練習のために、車での移動ができるとベターだった。家は横浜の住宅街の細い道沿いにある。だから、そうした生活様式を支えてくれる車が必要になった。
ところで、このような「要求」をそのまま設計に持ち込むことはできない。自動車というシステム（車は立派な「システム」だ）の設計のためには、こうした要求を、回転半径＝XX(m)、1.最大積載重量＝XX(kg)、ハッチバックのワンボックス構造、といった技術仕様に翻訳しなければならない。
本当のことを言うと、当時のわたしは車それ自体が必要だったのではない。「車を持つことで実現できる生活パターン」が必要だったのだ。車はその道具の一部でしかない。これがわたしの「ニーズ」であった。そのうち、車に対するニーズだけを切り出したものが、システムへの「ビジネス要求」である。英語なら、Business needsだ。
そして、そのビジネス要求を技術仕様の用語に翻訳したものが、「システム要件」ということになる。英語ではSystem requirementsである。
業務とITシステムの架け橋として
こう考えると、日本で言う「要求分析」と「要件定義」は、確かに別種の仕事であることが分かる。別種というか、向き・目的が逆なのだ。ビジネス要求（ニーズ）の分析とよばれる部分は、じつは、現在はまだ存在しない業務のあり方を設計する仕事である。つまり業務で実現すべきアウトカムが、仕事の目的である。それが、ビジネス・アナリストの仕事だ。
一般に業務には、情報処理的な作業と、物理的な作業がある。混じっている場合も多い。その際に、情報処理的な作業項目について、必要な道具の「要求」（果たすべき機能のニーズ）を決めるのも、ビジネス・アナリストの役目である。業務上のニーズの一部が、情報処理ニーズになっている。ついでに言うと、物理的作業の道具の要件を考えて設計するのは、機械とか電気とか土木とかそれぞれ専門分野の技術者だだが、その制御システムの要件を決めるのも、ビジネス・アナリストがやって良い。だが制御技術（OT）と情報処理技術（IT）の間に人財的なギャップがあるため、別の担当になるケースが多い。
他方、「要件定義」は、機能的なニーズに基づいてITシステムの要件（仕様）を決める仕事である。目的は、より優れたITシステムを作ること。この仕事には、ITシステムの内部構造に対する知識が必要である。RDBで作る業務システムは積み木細工のようなものだから、データ構造について知見の積み重ねが重要になる。構造が決まると、主要な機能がかなり見えてくる。だから冒頭のOさんの発言は、構造から考えるSEの方が、機能に振り回されるSEよりも、結果としてはブレにくいということを意味していたのかもしれない。
明確な要件とは 客観的に検証可能であることが大切だ。だからシステムテストの基準も、ここで確立する。いわゆるV字モデルである。
このように要件定義とは、業務ニーズとシステム仕様をつなぐ架け橋である。それをつなぐのがビジネス・アナリスト（BA）の仕事だ。それがプアーだと、住宅街を曲がりきれない車や、妙に細長い荷物スペースの車ができたりする。
ところで、わたし達の社会の課題の一つは、業務畑出身で業務の洞察力のあるBAが少なく、IT技術畑でシステム機能に詳しいBAばかりが多い点らしい。それは煎じ詰めると、IT人財がユーザ企業側とITベンダー側のどちらに集中しているか、という日本のIT業界構造の問題と関係している。生成AI技術の進歩と共に、IT開発プロジェクト・マネジメントの勘所が実装側から上流設計側にシフトしてる今、ますます強く問われている課題なのである。
＜関連エントリ＞
「課題、ペイン、そしてソリューション」 (2008-02-10)
「課題、ペイン、そしてソリューション（２） ＩＴ産業の中核問題とは」(2008-02-18)