要求の外部完全性について
あらまし
システム内部で欠陥が発生しないように，機能例外に対応するための機能要求の完全性が内部完全性である．これに対して，システムを利用する外部からみた要求の完全性が外部完全性である．
デジタル技術で業務プロセスを再構築する「デジタライゼーション」では，業務プロセスと整合する外部完全な要求仕様が必要である．業務プロセスも含めた要求の外部完全性を分析できる「欠陥未然防止図」では，受付条件，資源条件，判断条件と例外条件に基づいて，アドホックな業務プロセスの発生を抑止し業務の欠陥を未然防止できる．
１．はじめに
システム内部で欠陥が発生しないように，機能例外に対応するための機能要求の完全性が内部完全性である．これに対して，システムを利用する外部からみた要求の完全性が外部完全性である．
以下では，まず2章で要求仕様の完全性についての関連研究を説明する．次いで，3章で外部完全性を提案する．さらに，４章でビジネス，要求と完全性について議論する．5章でまとめる．
２．関連研究
要求仕様の検査基準としてBoehm[1]が完全性，一貫性，実現可能性，試験可能性を定義した．
[完全性]すべての要求について要求を構成する属性，機能，制約が記述されていること
[一貫性] 要求記述間に矛盾や関係の抜けがないこと
[実現可能性] 計画された期間と予算内で要件を実現できること
[試験可能性] 外部インタフェース数，交換データ数，可能な状態数が限定できること
IEEE 830[2]では，要求仕様が完全であることを，a)設計制約，属性，外部インタフェース b)すべての状況における有効・無効な入力に対する応答 c)参照・用語の定義としている．
Leveson[3]は，要求仕様が完全であるとしている．すなわち，要求仕様に含まれている情報が，ソフトウェアの望ましい挙動と望ましくない挙動を設計者が判断する上で不十分であるとき，要求仕様はあいまいである. あいまいでない要求仕様が完全である．したがって，システムが動作する状況下で，ソフトウェアの安全な挙動を規定するために要求仕様が完全である必要がある．
筆者ら[4]は，アクタ状況完全，イベント応答完全，アクタ間相互作用完全を提案した．アクタ状況完全は，すべてのアクタとその状況が抽出できていることである．イベント応答完全は，すべてのイベントと応答が抽出できていることである．アクタ間相互作用完全は，すべてのアクタ間の相互作用が抽出できていることである．
User storyでは，ユーザー(Who)が何(What)をなぜ必要とするか(Why)だけを簡潔に記述する．User Scenarioでは，User Storyを時系列（When）で整理する．これに対して，要求仕様では，ユーザー(Who)が，どの状況で何を契機として(When)，どんな入力に対して，どう処理して，何を出力すると(What)，どんな応答があり，相手のユーザーに何が起きるのか(Why)を定義する．したがって，User StoryとUser Scenarioは要求仕様に含まれている．
３．要求の完全性
要求の内部完全性と外部完全性を次で定義する．
[定義]内部完全性は，対象システムの要求仕様書内で完全であることである
[定義]外部完全性は，外部環境要求に対して対象システムの要求仕様書が完全であることである
ISO/IEC/IEEE29148[5]では，要求仕様をステークホルダ要求仕様StRS，システム要求仕様SyRS，ソフトウェア要求仕様SRSに分けている．内部完全性はソフトウェア要求仕様の内部における要求完全性である．外部完全性は，ステークホルダ要求仕様およびシステム要求仕様とソフトウェア要求仕様とについての要求完全性である．
要求完全性を内部完全性と外部完全性に分離することにより，要求の完全性の範囲を明確にできる．
３．１ 要求変更要因
要求の内部完全性と外部完全性に基づいて，６個の要求変更要因[6]を分析した結果，要求の誤りを除いて他の5個の要求変更理由（発注者の知識の変化，技術・計画・経費，優先順位変更，システム環境の変化，組織変更）が外部不完全性によることが明らかになった．
ここで，発注者の知識の変化，技術・計画・経費，優先順位変更，組織変更は，StRSの変更である．また，システム環境の変化は，SyRSの変更である．
３．２ ビジネスIT整合性
グリコでは，システム再構築した結果，物流センターでの出荷データ不整合等が発生し，想定受注に対して処理が，間に合わず出荷の停止を判断した[7,8]．この不具合の解消に2か月の時間がかかると想定されている．全社レベルでデータを「見える化」するシステムなので不具合原因を特定して，システムの一部を改修しても，システムの信頼性を保証するためには，システム全体の試験作業が必要だと考えられる．また，食品の生産を制御するシステムなので，生産された食品の安全性を確認することも必要になる．
ITシステムが往々にして失敗しがちなのは， 技術的な能力と効率性に過度の重点が置かれ，ITシステムを使わなければならない人々に関する問題やITシステムが関連するより幅広い組織的な問題にあまり注意を払っていなかったからである[9]．
システム思考は，人間や人間の新年， 価値観と利害といったものに多くの関心を注ぐとともに， 技術と組織の構造と戦略との関連をも視野に入れている． そのためシステム思考は， 情報システム開発に責任がある人々に対して大きな貞献ができる．
RittelとWebber[10]は社会技術的なシステムは，社会環境や技術環境の変化に対応する必要があるから，システムが扱う問題も解も定義している間に変化してしまう厄介な問題であると指摘している．同様に，LehmanとBelady[11]もビジネス環境に埋めこまれる情報システムは常に進化し続ける問題を扱うので，問題を定義することが困難であるだけでなく，最適な解としての情報システムを開発することが難しいと指摘している．
ステークホルダ要求仕様[5]の内容は，はじめにで，ビジネスの目的 ビジネスの範囲，ビジネスの概要，ステークホルダを明かにする．ビジネスマネジメント要求で，ビジネス環境 ゴールと目標，ビジネスモデルを記述する．ビジネス運用要求で，ビジネスプロセス，ビジネス運用ポリシーと規則 ビジネス運用制約，ビジネス運用モード，ビジネス 運用品質，ビジネス構造を記述する．
４ ビジネス，要求と完全性
図1に，ビジネスアーキテクチャとビジネス，要求と完全性の関係を示す．
アーキテクチャには，ビジネスアーキテクチャと情報システムアーキテクチャがある．ビジネスアーキテクチャに対して，ビジネスモデルとビジネスプロセスが対応する．情報システムアーキテクチャに対して，ステークホルダ要求，システム要求，ソフトウェア要求がある．ビジネスアーキテクチャと情報システムアーキテクチャの相互作用に対してビジネスIT境界の整合性を明かにする必要がある．本稿では，要求についての完全性を定義した．
ビジネスモデルとビジネスプロセスに対する完全性についても明かにする必要がある．
４．１ ビジネスモデル完全性
顧客価値はビジネスモデルによって創造される[12]．これまでに，多くのビジネスモデルが提案されている．ビジネスモデルの要素に抜けがないことがビジネスモデルの完全性であると定義すると，ビジネスモデルごとに完全性を定義できる．
たとえば，アジャイル開発では，顧客価値を生む製品やサービスを迅速に開発する必要がある．しかし，単に早く動くものを作ることがアジャイル開発ではない．顧客価値を生まないサービスを迅速に開発していたのでは，かえって価値を生み出すまでに時間を浪費してしまうことになる．価値を生まない機能を開発する意味がないことから，Minimum Viable Product (MVP)が提案されている．MVPをモデル化するMVP canvasの要素は，顧客，ユーザーシナリオ，提供製品MVP, 機能，実行計画，ゴール，仮説検証基準である[13]．このために，MVP Canvasでは，ペルソナを明記して顧客による製品の利用プロセス（ジャーニー，利用シナリオ）を抽出して製品と機能を定義する．また，成果と仮説の検証基準を記述します．この理由はMVPを満たす製品であることを評価するために必要になるからである．また，仮説を定義するだけでは意味がない．仮説の妥当性を判断する基準を，製品を実現する前に定義しておくことが，顧客が望む「正しい製品」を開発するために重要になる．
Business Model Canvas[14]の要素は，ビジネスを協働で支えるパートナー，主要ビジネス活動，ビジネスを実現するために組織がもつ主要資産，顧客に提供する価値，顧客関係，ビジネス対象の顧客層，ビジネスを提供するための販売経路，ビジネスを運営する経費構造，ビジネスの収益構造である．これらの要素に抜けがないことがＢＭＣの完全性である．
筆者らによるアクタ状況完全，イベント応答完全，アクタ間相互作用完全は，ビジネスアクタ間の関係についての完全性であることから，ビジネスモデル完全性の一つである．また，ビジネスモデルが生む価値については，個別的に仮説検証基準を設定して確認する手法が知られている．
４．２ ビジネスプロセス完全性
ビジネスプロセスの実行段階では，設計段階では見えていない多くの例外が発生する[15]．この理由は業務工程を適切に実行するための条件を明確になっていないために，不完全なビジネスプロセスになっているからである．ビジネスプロセスの不完全性に対応するために，実行段階で個別例外に対応する必要がある．
ビジネスプロセスの完全性については，佐々木による自工程完結が知られている[16]．自工程完結では，業務フロー図と要件整理シートを作成する．要件整理シートでは，工程ごとに，入力と道具方法などからなる良品条件，出力，これで良いと判断できる判断基準を記述する．しかし，自工程完結の要件整理シートには，例外を扱っていない．
筆者ら[17,18]は，自工程完結の条件要素を受取条件，資源条件，判断条件として再構成するとともに，例外を工程ごとに定義する欠陥未然防止図を提案している（図2）．欠陥未然防止図では，受取条件，資源条件，判断条件を満たすとき，入力から出力を生成する．ここで，受取条件，資源条件，判断条件のいずれかを満たさないとき，例外を発生する．
４．３ 異なる完全性間の関係
ビジネス組織が ITを使用してビジネス目標を達成するプロセスがビジネスIT整合性である．従来から，ITシステムがビジネスと対応できないために，多くのITシステム障害が発生している．
前述したように，Jackson[9]は，ITシステムが失敗しがちなのは，ITシステムを使わなければならない人々に関する問題やITシステムが関連するより幅広い組織的な問題に注意を払っていなかったからだと指摘している．
ステークホルダ要求仕様StRSには，ビジネスマネジメント要求でビジネスモデルを記述するとともに，ビジネス運用要求で，ビジネスプロセスを記述する．また，ユーザ要求では，ユーザ入力に対するシステム出力を定義して，ユーザとシステムの相互作用条件を記述する．さらに，提案システム概念として，運用概念と運用シナリオを記述する．StRSでは，ビジネスモデルとビジネスプロセスを含めてユーザ要求とともに記述している．このように，StRSでは，実現するビジネスモデルとビジネスプロセスを明記しているから，ビジネスIT整合性を保証する要求記述である．また，StRSではシステム要求SyRSを含めて記述しているから，StRSを達成するSyRSであれば，StRS整合性を持つSyRSであることが保証される．
５．まとめ
本稿では，要求の完全性を内部完全性と外部完全に分類した．内部完全性では，ソフトウェア要求仕様内部の完全性である．外部完全性の対象は，ソフトウェア要求仕様の外部としてのステークホルダ要求，システム要求である．ステークホルダ要求の内部でビジネスモデルやビジネスプロセスを扱う．ビジネス要求とシステム要求についてはビジネスIT整合性が必要である．したがって，要求完全性の対象として，ビジネスモデル完全性，ビジネスプロセス完全性，ビジネスIT整合性，外部完全性，内部完全性がある．
欠陥未然防止図では，ビジネスプロセスの例外への対応を補完できるので，例外としての欠陥に対応できるビジネスプロセスを定義できる．
今後，４．３で指摘したように，これらの完全性について包括的な関係を明らかにする必要がある（図3）．前述したように，ビジネスIT整合性がStRSで実現できるなら，ビジネスIT整合性は，StRS・SyRS整合性に帰着するから，StRS・SyRS整合性が実現できるなら，結局，ビジネスIT整合性は，SyRS・SRS整合性に帰着することになる．ここで，ビジネスモデル・StRS整合性が，ビジネスモデル・プロセス整合性とビジネスプロセス・StRS整合性と置換え可能であることを確認する必要がある．したがって，ビジネスモデル，ビジネスプロセス，ステークホルダ要求との整合性や完全性について明らかにしていく必要がある．
参考文献
[1] Boehm, B. (1984). Verifying and Validating Software Requirements. IEEE Software, Jan.1984, p. 75-88
[2] IEEE Recommended Practice for Software Requirements Specifications, IEEE std. 830 -1998
[3] Nancy Leveson, Safeware– System Safety and Computers, Addison-Wesley, 1995, 松原友夫監訳，セーフウェア，翔泳社，2009
[4] Noboru Hattori, Shuichiro Yamamoto, Tsuneo Ajisaka, and Tsuyoshi Kitani, Proposal for Requirement Validation Criteria and Method based on Actor Interaction, IEICE TRANSACTIONS on Information and Systems, Vol.E93-D No.4 pp.679-692, 2010.12
[5] ISO/IEC/IEEE 29148:2011, Systems and software engineering —Life cycle processes — Requirements engineering, 5.2.3, 2011
[6] 服部昇, 山本修一郎, 知識イノベーションを支えるIT要求品質分析, NTT技術ジャーナル, pp.20-22, 2008.5
[7] めざましmedia, 消えたプッチンプリン，https://mezamashi.media/article/15268806
[8] 江崎グリコ株式会社, 当社グループにおけるシステム障害について, 2024.4.22
[9] Mike Jackson, Systems Thinking and Information Systems Development, Journal of the Japan Society for Management Information Vol.6 No.3, Dec.1997, pp.5-16
[10] Horst, Rittel, Melvin, Webber, Dilemmas in a General Theory of Planning, Policy Sciences, 4:2, p.155-169, 1973
[11] M.M. Lehman and L.A. Belady, Program Evolution -Process of Software Change, Academic Press, 1985
[12] Henry Chesbrough著,大前恵一朗訳, Open Innovationハーバード流イノベーション戦略のすべて,産業能率大学出版部,2002
[13] Paulo Caroli, Lean Inception– How to Align People and Build the Right Product, Editora Caroli, 2018
[14] Alexander Osterwalder & Yves Pigneur, Business Model Generation, Wiley, 2010
[15] 佐々木眞一, 自工程完結－品質は工程で造り込む，JSQC選書，日本品質管理学会, 2014
[16] McKinsey and Celonis bring the power of process mining to business transformations, https://www.mckinsey.com/about-us/new-at-mckinsey-blog/, March 15, 2024
[17] 山本修一郎, 自工程完結図式の提案，電子情報通信学会，KBSE研究会，5.18, 2024
[18] Shuichiro Yamamoto, Business Process Completeness, eKNOW 2024, 5.27