要求工学のパラダイムシフト
関連ポッドキャスト
「Stochastic」という普段聞きなれない言葉は「確率的な、確率論的な、推計学的な」と訳される。ソフトウェアシステム開発の上流工程の工学領域である要求工学はStochasticな工程であるがゆえに、後続のライフサイクルフェーズと比べるといわゆる”工学的”な取り組みが難しい。その一方で、要求品質がプロジェクトに大きな影響を及ぼすことは、ソフトウェア工学の歴史の初期段階から認識されてきた。
要求に関する課題を解決するための開発ライフサイクル戦略として、要求の妥当性を細かい段階を踏んで確認していこうというアジャイル開発が、特にWebサービス系などの分野である程度の成功をおさめてきている。しかし、リリースするサイクルを短くする戦略を取ったとしても、何を作るべきかの要求を獲得するアプローチであるという意味では要求工学の従来パラダイムの延長にある。
このブログでは要求工学の新しいパラダイムを提案する。そこでは、要求は獲得するものではなく設計の結果導かれる。このパラダイムを説明するために、なぜ新たなパラダイムが必要なのかその背景から説明する。
低迷するITプロジェクトの成功率
スタンディッシュグループ（Standish Group）は1985年に設立された国際的なIT調査アドバイザリー会社として、公共および民間部門の情報システム導入プロジェクトに関するレポートで知られている。同社が発行するCHAOSレポートは、ITプロジェクトの成功率に関する事実上の標準値として参照されている。
最初にCHAOSレポートがリリースされたのは1994年。そこで報告された「ITプロジェクトの成功率は16.2%である」というその驚くべき低い数値は、IT業界のみならずソフトウェア工学研究者にも少なからぬ衝撃を与えるものであった。失敗原因の分析に関しては1995年の調査報告で確認することができ、「要件の不備、ユーザーの参加不足が上位に挙げられる」と報告されている。実際には失敗プロジェクトの約48%が上流工程の問題であった。
CHAOSレポートは、その後おおよそ2年ごとにリリースされており、図1に示すように、2015年の報告ではITプロジェクトの成功率は36%まで改善している。この改善にはアジャイル開発の定着があるとの分析がある。しかし一方で、20年近くの歳月でIT業界が達成できた改善率が20%程度であるともいえる。改善はこのまま年1％のペースで進んでいくのであろうか。グラフの傾きを見ると改善が線形に進んでいくとも思えない。
要件工学がこれまで取り組んできた要件の十分性や網羅性を確保する方法が、まだまだ足りていないのだろうか。プロジェクト失敗の主要因であった「要件の不備」と「ユーザーの参加不足」を解決するためにアジャイル開発を採用して、「あなたが欲しいものはこれですか？」とユーザとのコミュニケーションに実装結果を介する方法をとってみても抜本的な改善は見られていない。
このような状況の場合、普通はこのように考えるのではないか。
これまでの要求工学のアプローチは、根本的なところで間違っているのではないだろうか？
新しいパラダイムとしての「超上流」
これまでの要求工学の関心ごとは、図2に示すように、ITシステムの開発者側が開発に十分な要求を集めるプロセスにあると言って良い。集めた要求を分析してITシステム要件として定義し顧客との合意を形成するというプロセスが後半に続くとしても、集めた要求が不十分では、注文無しに顧客が喜ぶ料理を作れと言われているようなものである。
ソフトウェアプロジェクトの成功率が低迷する中、IPA（情報処理推進機構）が、要件管理からはじまる従来のソフトウェア開発ライフサイクルのさらにその上流工程をスコープに入れるべきであるとして「超上流」というキーワードを提唱したことはブログ「超上流工程の課題と逆Vモデル」でも取り上げた。
従来のシステム開発の上流工程が、ユーザからの要求をシステム要件として解釈し定義するところからが責務範囲であった。その開始時点をシステム開発のさらに上流方向に射程を伸ばすべきであるという主張は非常にインパクトのあるものであった。そしてこの同様の問題意識は、2018年に制定された国際標準「ISO/IEC/IEEE 29148」にも見られる。
ソフトウェアシステムの開発ライフサイクルの中でも上流工程にあたる要求工学に焦点をあてた国際標準ISO/IEC/IEEE 29148では、要求工学のライフサイクルが図3に示すように描かれている。図3で示される要求と仕様の関係では、左から入力された企業組織の外部環境からの要求に対して経営視点による組織レベルの運用概念（ConOps）が構想される。そしてこれをインプットとしてシステムの運用概念（OpsCon）が構想されシステム要件定義につながっていく。
図3をあらためて見ると、業務運用（Business Operation）とシステム運用（System Operation）の境界が点線で示されており、この点線をまたぐようにシステム運用概念（OpsCon）が置かれている。ISO/IEC/IEEE DIS 29148の主張のひとつは、システム要件（SyRS）を定義するまでのシステム運用概念工程は、業務とシステムとの責務が独立しているものではなく、相互に関係するプロセスであるということである。この考えかたはIPAの超上流工程の主張とも一致する。
「超上流」というキーワードは、要求工学の関心ごとを「要求の十分な獲得」という視点から、図4に示すように、ビジネスと開発との要求に関する「ミュニケーション」という新たなパラダイムを与えたものといえる。実際に、IPAによるレポート「高品質のための超上流工程における企業の課題・取り組み事例集」でも、ビジネス側と開発側の役割の定義とコミュニケーションのありかたに焦点が置かれた提言がされている。
ちなみにソフトウェア工学をコミュニケーションの活動として捉えるというパラダイムは、IPAによる超上流の提言を待たずとも、1988年の時点でACM SIGSOFT News Letter, Aprilに「A Paradigm Change in Software Engineering」としてChristiane Floydによって提起されていた。当時のソフトウェア工学の関心ごとはソフトウェアシステムの構築とそのためのプロジェクト管理の技術であり、それらは、ソフトウェアエンジニア視点によるものであった。それに対してFloydは「Paradigm Change」と主張しているように、ソフトウェア開発を利害関係者間の相互学習およびコミュニケーションの活動として捉えるべきであると提言し、参加型デザインや行動理論、認知言語学などの重要性を訴えていたがソフトウェア工学の主流の関心ごとにはならなかった。この1988年は（キング・オブ・ポップの彼ではない）マイケル・ジャクソンによって要求工学の教科書ともいうべき「Software Requirements & Specifications（1995年）」が出版された年代とも前後する意味で感慨深い。
新たなパラダイムへの取り組みとしてのBPR
要求工程の新たなパラダイムであるコミュニケーションはどのように実現したら良いであろうか。その取り組みの一つとして、例えば、BPR（Business Process Re-engineering）がある。BPRは、ビジネスプロセスモデルをビジネス側と開発側とのコミュニケーション基盤として、業務改善と業務に有効なITシステムを構築しようという試みである。業務レベルでの合意形成が実現していれば、そこから作られたITシステムはおそらく顧客が満足するものとなるはずである。
しかし現在のBPRの取り組みの中で記述されているビジネスプロセスモデルをみると、そこにはITシステムの仕様が記述されている（手元にビジネスプロセスや業務フロー定義があれば見て欲しい。そこには、システムの仕様が書かれていないだろうか）。現状のビジネスプロセスモデルには将来的に構築導入されるITシステムを利用することを前提とした作業フローが描かれており、図5に示すように、十分な合意を得るためにはまたしても前提として、顧客要求の十分な獲得というパラダイムが蘇ってしまうのである。
しかしこのことは意外なことではなく、ISO/IEC/IEEE 29148においても、業務運用とシステム運用の境界上で行われるコミュニケーションがシステム視点での運用概念（OpsCon）となっているように、システム主体の視点には根強いものがある（実は、システム主体の視点になってしまう根本的な原因はモデル化の方法そのものにあるのであるが、そのことについては改めて書きたい）。
新たなパラダイムの実現のために
新たなパラダイムである業務と開発とのコミュニケーションとはどのように実現すべきであろうか。業務プロセスを業務と開発とのコミュニケーションのための道具とするBPRのアプローチは良い方向ではある。しかし、ITシステムの仕様が暗黙的にも内包された業務プロセスでは、従来の要求工学のアプローチと変わらなくなってしまう。
要求工学がStochasticな探索的行為であるのは、そこに経営や組織といった決定論的には語れない領域が大きく関わるからである。そのため、業務と設計とのコミュニケーションも、探索的な行為と決定論的な行為（別な言い方では機械論的な行為）とのコミュニケーションとなる。
ところで、探索的な行為から決定論的な仕様へ至る過程は、実はすでにいたるところで行われていることであって、すなわち「設計（Design）」の行為そのものである。ITシステムの仕様を定義する工程においても、システムエンジニアは、顧客要求に対する探索的な行為から機械の仕様を決定しているのである。エンジニアの頭の中で探索行為と仕様決定のコミュニケーションとが行われているのである。
この設計行為を、業務と開発との探索と決定とのコミュニケーション領域でも実施すべきではないだろうか。このことが、「超上流」が提示した要求工学の新しいパラダイムとしてのコミュニケーションを実現方向に導く指針となるのではないか。
すなわち、要求工学の次なるパラダイムは、”コミュニケーションの方法そのもの”にあり、そこで語られる主要なキーワードは”要求”ではなく”設計”となるであろうと仮説するのである。つまり、図6に示すように、ビジネス側を要求空間として定義した場合、「要求空間の設計方法」が要求工学の次の主要な関心ごととなるべきである。
すなわち、
要求工学の新たなパラダイムは、要求空間そのものを設計（Design）する方法にある。
ということである。
PRePモデルは要求空間設計の概念モデリング方法の一つであり、この記事の中で触れた「ビジネスプロセスモデルがITシステムの仕様を無意識的にも記述してしまう問題」を解決してもいる。
