要件定義を専門でやる技術者(Requirement Engineer)に関する雑感

タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。

b.hatena.ne.jp

要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道

要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。
ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。
一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。

要求開発~価値ある要求を導き出すプロセスとモデリング

私もコミュニティの運営に関わっていた「要求開発アライアンス」でもそういった議論は繰り返されてきた（同コミュニティはその出自から、UMLを活用したビジネスモデリングを中心とした議論をしていた）
また別個の動きとして、JISAで要求工学知識体系（REBOK）の整備というのも進んでいて、日本発の取組みとして活発だったころがあったのだ。

• IPA 要求工学知識体系(REBOK)概説(PDF)

要求工学知識体系 第1版

要求工学知識体系（REBOK）では 要求アナリスト（Requirements Analyst）という役割を定義していて、要求工学に精通した人材が要件定義に参画すると良いとしていた。ちなみに要求アナリストに求められる能力は以下と定義されていた。

• 要求工学知識
  • 要求工学の知識
  • 対象とするビジネスや製品に関する知識
  • ソフトウェア開発全般に関する知識
  • プロジェクト管理全般に関する知識
• 要求工学スキル
  • コミュニケーションスキル、ファシリテーションスキル、交渉スキル、観察スキル、文書作成スキル、分析スキル、組織化スキル、モデル化のスキル、対人スキル、創造性

また欧米ではビジネスアナリシス知識体系（BABOK）の整備も進み、こっちはビジネスアナリスト（BA）という役割が定義されて、PMPのような資格化もされていったという歴史がある。

ふむ、それからどうなったの？

人によって見え方は変わってくると思うが、私の感覚でいうと「流行らなかった」と思う。
振返ってみると以下のような構造があった（個人の感想です）

• ユーザー企業の観点では、恒常的に要件定義を行うわけではないので「テクニック」には興味があったが、専門家を育成するマインドはなかった
• SIer的企業の立場で言えば、「要件定義は本業ではない」というマインドがあったと思う。よってやはり専門家を育成するマインドは低かった（大企業だったら話は別かもしれないが、身近なところでは観測できなかった）
• 要件定義を専門とする小さめの会社はいくつもあったが、規模を大きくしたり、類似の会社が増えるということもなかった

また、その後はアジャイル開発ブームが到来してくるので、開発技術におけるアーリーアダプター的人材はほとんどがアジャイル開発方面に移行していったような印象がある（個人の感想です）

というわけで要求工学の専門家という発想は、当時はあまり広がらなかったのだ

いま、改めて要件定義を専門でやる技術者(Requirement Engineer)について考える

すべて私見である。要求エンジニアのような職種のニーズは高そうだけど、やっぱり流行らなそう

要求エンジニアがいても、要件定義の本質的な難しさは変わらない

特に古いシステムを更改したり統合するというソフトウェア開発のプロジェクトにおいて、要求エンジニアができることは「要求の発掘」である（考古学、文化人類学、そしてリバースエンジニアリング能力が必要）。
そして「要求の発掘」により大量の要求っぽいものが発見されたとして、これを全て精査・厳選しして最終的な要件に変換することは、要求エンジニアには出来ない。これはシステムの使用者（ユーザー）がやらざるをえない。
そういう意味では、要求エンジニアを調達したとしても、ラクになるのは一種の前処理だけである（それでも十分に良いことなのだけれど）。

特に巨大なシステムの要件を定義するための意思決定の労力は、要求エンジニアがいても軽減されない。ここに一つの難しさがあるだろう。

要件定義工程だけの切り出しは難しい

要件定義の本質的な難しさを受け入れたとしても、次に問題となるのは要件定義工程の切り出し方である。話をシンプルにするために、ウォーターフォール型のソフトウェア開発プロジェクトを前提にする。要求エンジニアの支援をうけて要件定義を行うとすると、以下のような問題に直面することになるだろう。

• 要件定義のアウトプットを、要件定義が完了した段階で評価できない
  • 要件定義書などを単体で評価することが難しい。ソフトウェアが完成に近づいてはじめて、適切な要件定義ができていたかがわかるのだ。ということは、要件定義が終わった段階で要求エンジニアを含むチームは解散、というわけにはいかない。これはリソースやコスト面でかなり厳しそうだ
• ソフトウェア構築者と要求エンジニアを役割分離すると、要求が最適化できずに結果として作業が増加するという問題がある
  • ソフトウェアを実装する観点からすると、非効率となったりボトルネックになる要求（作り手から見てコスパが悪い要求、その1点を取り下げることで劇的に効率が上がる要求）というものは存在する。そういった要求を調整することでプロジェクトのリスクがコントロールできるのだが、ソフトウェア構築者と要求エンジニアが分離しているとうまく連携できないことがある。要求エンジニアはユーザーが要求しているのだから、効率などは無視して要求を定義するし、構築者は効率が悪いと思っても、すでに定義された要求は充足せざるをえないというマインドになってしまう

要求エンジニアの育成も難しい

エンジニアリングだけではなく幅広い知識が必要とされるので、単純に難しい。さらに加えて修行が難しいという問題もあるだろう。要求エンジニアが必要とされるようなプロジェクトは期間も長くなるので、短期的に大量の経験を積んで成長するといったことが難しいのである

じゃあ、どうすればいいの？

私も知りたい。銀の弾丸はない。

ただ最近考えるのは、

• ビッグバン的な大規模な要件定義をなんとかして避ける
• 運用フェーズで手を抜かず、保守性（特に移植性）を向上させる取り組みをして、次の更改のリスクを軽減する

あたりはポイントになるような気がしている。