【連載】要求工学における「利用状況」の扱いをめぐる考察：要求(要件)定義に主語は必要か？（第４回①）

前回記事の最後の方で、伝統的な手法※1の多くは、機能およびその要求(要件)※2定義の表現に主語は記載しないと説明しました。しかし、その理由を説明し出すと長くなってしまうので、それは別途説明することをお約束しました。そこで、今回はその約束を果たしましょう。

日常使用している日本語において、主語が示されないことは普通にあることです。それが他の言語に比べ特殊であるとか、反対にそもそも常に主語を必要とする英文法に普遍性があるかのような前提に疑問を呈する論もあります[1][2][3]。今回取り上げる内容は、それとは全く無関係とは言いませんが、決して日本語特有のことではなく、英語圏であっても共通に通用することです。

まず前回、JIS X 0166[4]が示す以下の「要件(要求事項)プロセスと仕様書の関係性の例」の図を紹介しました。要求に対してレベル区分を考えることができるのを思い出してください。

図表1で示されているレベルは以下の四つです。

• BRS  ビジネス要件（要求事項）（経営層レベル）
• StRS   利害関係者要件（要求事項）（業務運用レベル）
• SyRS   システム要件（要求事項）
• SRS   ソフトウェア要件（要求事項）

ただ、本稿では前回と同様に大きく二つ、以下の表（図表2）のように分けて説明します。

要するに、今から開発するシステムや製品、ソフトウェア、コンポーネント、モジュールなど(本稿では以降、これらをまとめて人工物と表現します)に対するレベルと、それより範囲の広いレベルに分けるということです。なぜ今回もこのように分けるのかと言えば、これから説明する「要求に主語を書かない」理由も、この区分で異なるところがあるからです。

これは前回、すでに一部説明済みです。

役割やステークホルダー種別の情報が必要であると言及しました。ただ、その情報が要求定義表現の主語の位置を占めない方が良いというだけのことです。

前回はユーザーストーリーを使用する前提で説明しており、例えばConnextra Formatで表現する場合、役割やユーザータイプを記述することになっています。しかし、それらを例えば「購入者は」、「保守担当者は」といったように主語の位置に置くのではなく、「購入者として」、「保守担当者として」と表現する形式になっています。主語の位置を空けておくことで、例えば複数のペルソナを使用する場合などに、主語をそれぞれのペルソナに置き換えやすくなるからです。

他に、その位置を空けておくというよりも、主語は入れてはいけないとする考え方もあります[5]。その理由は、主語の部分はこれから考案して設計すればよい部分だからです。そこに「オペレーターは○○する」や「□□部門が○○する」などのように既存の役割や部門・組織などを置いた表現をしてしまったら、その後の創造活動を阻害してしまいます。つまり、業務役割や組織を硬直化させる方に働いてしまうので、例えばDX目的の場合などには主語は要求表現に入れない方が良いわけです。同じ理由で、As-Is（現状）のスイムレーンが描かれた業務プロセス図やアクティビティ図からいきなり開発に入ってしまうと、業務効率化の提案が出てくることは期待できますが、DXにつながる発想や提案は出しにくくなってしまうことにも注意する必要があります。

本気でDXに取り組むと、従来の役割や部門などが要らなくなり、仕事内容が変わる可能性があるはずです。しかし、それを一介のシステム開発プロジェクトに任せても、そこからそういう提案はなかなか出てきません。開発されたシステムを受け入れる現場が大きく反発する可能性がありますし、同じ社内の場合、社内に敵を作ってしまう可能性もあるからです。そういうわけで、できるだけ無難に、できるだけ多くの部門や役割に、少しずつ利便性の高い機能を提供して喜んでもらう方へと流れて行ってしまいます。それは経営層としては残念な結果となるわけですが、そういった問題に何も手を打ってこなかった当然の成り行きということでもあります。

本稿の冒頭で、JIS X 0166[4]が示す要件(要求事項)仕様に四つのレベルがあることを紹介しましたが、実はその上に組織レベルの運用概念（concept of operations）を策定することも、この規格は求めています。組織全体の視点での境界、例えばシステムが解決する課題の範囲、影響を与える組織単位などについても明確にします。経営者も含めてこれをしっかりと策定する活動や、実際に展開していく体制が別途構築され、それらがうまく協調できれば、上で記したような問題は防げるでしょう。

ところで、JIS X 0166[4]は以下に示す通り、いくつかの属性を要求と共に(含めて)把握・管理することを推奨しています。

5.2.8 要件（要求事項）属性

要件（要求事項）分析を支援するために，整形式の要件（要求事項）には，関連する要件（要求事項） の識別を支援し，要件（要求事項）を理解し管理する助けとなる説明的な属性を含めることが望ましい。

…以下略…

5.2.8.2要件（要求事項）属性の例

• 識別　…以下各項目の説明略…
• バージョン番号［及び要件（要求事項）のバージョンの表示］
• 所有者
• 利害関係者優先度
• リスク
• 論拠
• 難易度
• 種類

ここで示された属性について、それぞれ説明がなされており、「所有者」の説明は以下のようになっています。

所有者   要件（要求事項）を維持する組織の人物又は要素で，この要件（要求事項）について何か言う権利があり，要件（要求事項）の変更を承認し，要件（要求事項）の状態を報告する。

例えば、前回取り上げた自動販売機の例で考えると、「購入者」という役割が出てきました。それはこの「組織の人物または要素」ではありません。所有者としてふさわしいのは、「購入者」の実態について詳しく把握している、例えばマーケティング部門ということになるかもしれません。このように、所有者と役割や利害関係者(ステークホルダー)の種別が一致するとは限らないので、それぞれを属性として管理しておくと良いでしょう。

以上のようなことから、要求表現の主語の位置に特別な意味を持たせるよりは、そこは空けておき、所有者と役割や利害関係者(ステークホルダー)の種別を明確に区別した上で、属性で管理した方がメリットは大きそうだと同意できるかと思います。

システムや製品、ソフトウェアレベルなど、人工物のレベルに話を移します。そのレベルの要求表現についても、以下のことを前回紹介済みです。

人工物を主語にして、

機能要求については「A（目的語となる名詞）をBする（動詞）」という表現方法を基本として定義すること。

そしてその主語は、実際の表現には書かないこと。

主語を表現に入れない理由は、ユーザーレベルでの理由に似たところもあります。わざわざ主語を書かせると、そこに構成や部品といった特定の手段が出てきてしまうことになります。例えば、参考に示した文献[6]では、主語を明示することを推奨しており、そこに示されている事例を見ると、「フタは」、「本体部は」、「底部は」、「ヒーター部は」、「ステンレス層は」、「蒸気パイプは」といった表現となり、手段でしかないものが頻出してしまう結果になります。製品ではなくITシステムの場合でも、「サーバーは」、「ブラウザは」、「アプリは」、「データベースは」、「データウェアハウスは」といった表現が多々出てくることになります。そうした手段の特定は、初期には不要であるというだけではなく、特定した以降の創造活動を阻害してしまいます。つまり、構成や部品、手段を硬直化させる方に働いてしまいます。ですから、特にイノベーティブな新商品開発の場合などには主語は要求表現に入れない方が良いわけです。構成や手段について高い自由度を維持するには、ちょっとした意識的な工夫が必要だということです。そうしない場合、既存の思考に容易に取り込まれてしまうことが多いです。

誤解のないようにしていただきたいのですが、これは今から設計・開発する入口としての要求表現についての話です。設計の出口になる仕様では先の文献[6]が示している通り、手段や構成を含めて明確になっている必要がありますので、そこは注意してください。

ここまで説明した通り、人工物のレベルの場合、主語は初期の要求表現の本文に書かないだけで、曖昧でよいということでは決してありません。属性やルールと合わせるならば常に明確になっていなければいけません。ルールとして、「手段となる構成やアーキテクチャが決定され、どこかの構成に割り付けられるまでは、書かれていない主語は最大範囲（これから作ることになる人工物の全体）である」、と明確にしておけばよいでしょう。

発散思考（アイデアを広げ、多様な可能性を探る）と収束思考（アイデアを絞り込み、具体的な形に落とし込む）を意図的に使い分けることの重要性は、すでに皆さんご存じであると思います。要求定義のルールについても、これがうまく機能するように構築し、運用を徹底することが肝要です。

そのルールおよび目的の理解が現場に浸透していないと、主語の不在を利用して、特に曖昧さを助長してしまうリスクがあるため注意を要します。

そこで以下では、人工物のレベルで、主語を書かないことでどういう問題が起こりがちであるかをいくつか例示します。

さまざまな現場でよく見る表現に、「○○できること」、「○○できる」といった表現があります。「その要求表現の主語は何ですか？」と問うと、おおむね開発対象のシステムや製品だという回答が返ってきます。しかし、時々ユーザーであるという回答が返ってくることがあります。システムレベルの要求定義から参入してくる担当者が増えることもよくあることなので、特にそうした担当者の中にはユーザーレベルとの区別を意識することなく表現しているケースが散見されます。ユーザーを主語と想定して表現されているものの中には、本来、ユーザーレベルに追加すべきものもあります。それを、システムレベルに混入させてしまうのです。主語を書かないと、このような曖昧さや不都合が生じて困ることもあります。

そこで、それに対する対策を以下に示します。「○○できること」、「○○できる」といった表現は使わずに、先述してきた通り「A（目的語となる名詞）をBする（動詞）」という表現を使うことを基本ルールとすれば、この問題はかなり防げます。ユーザーが主語だと念頭に置いて「○○する」と表現すると、それはユーザーがすることになってしまい、人工物には何も要求していないことに自ら気付きやすくなるからです。

また、「○○できること」、「○○できる」といった表現は、他の曖昧さも引き寄せることがあります。それは、人工物自体が「できる」のか、人工物が支援機能を提供することでユーザーが「できる」ようになるのか、両方のケースが混在してしまう結果、個別に取り出した時にそれがどちらを期待しているのか曖昧で分からなくなるという問題が発生するといった事象です。人工物が主語だと念頭に置いて「○○する」と表現すれば、この問題も起こらなくなります。例えば、勤怠管理システムの人工物レベルの要求表現でも、「休暇申請ができること」などと書かれているのはよく見ます。「(ユーザーが)休暇申請する」と書き換えると、意味は通りますが、それでは人工物に何かを要求したことにはなりません。そうすると、ユーザーレベルの要求が混入した可能性もありますが、おそらくそれはすでにユーザーレベルの要求定義集合にちゃんと含まれていることでしょう。

一方、「(人工物は)休暇申請する」という表現だと意味が通りません。すぐに変だと気付くでしょう。「(人工物は)休暇申請を受け付ける」から始まって、その後のワークフローなどの処理を、人工物の働きや振る舞いを、明確に定義していかなければならないことに気付きやすくなるはずです。

※1) ここで「伝統的な手法」とまとめて表現している範囲は前回の記事と同じです。その例としては、バリューエンジニアリングにおけるファンクショナルアプローチ[7][8][9][10]、システム思考におけるワークデザイン手法[5][11]などです。最近では、XDDP（eXtreme Derivative Development Process）において使用されるUSDM (Universal Specification Describing Manner)の中のマナーの一つとしても示されています[12]。アジャイルのコミュニティーではあまり明確にこのような伝統的手法の説明がされることはありませんが、例えばJeff Pattonの著書[13]ではタスク(未来の機能)の表現形式について、この形式を推奨しています。この書籍で例示されているマップ図を丁寧に見ると、配置されているカードの中に書き込まれている表現は、基本的にこの形式に統一されています。

※2) 本稿では、以降「要求」に統一します。ただし、規格を引用およびそれについて説明する際には、その規格の表現をそのまま使用することにします。日本国内では、「要求」と「要件」を区別する流儀や現場も少なくありませんので、JISにおいても「要件(要求事項)」の表現が使用されることがあります[4]。対応する国際規格ではこれらは「requirement」であり、「要求」と「要件」の区別はありません。おおむね、国内では整形式で定義されたものを「要件」と呼び、もう少しルーズに表現されたものを「要求」と呼んでいることが多いようです。規格の「requirement」は整形式で定義されるべきものなので、ルーズに表現された国内でいうところの「要求」は、その手前の「ニーズを表出化したもの」といった位置付けだと捉えておくと良いでしょう。

[1] 金谷武洋(著), 『日本語に主語はいらない　百年の誤謬を正す』, 講談社選書メチエ

[2] 月本洋(著), 『日本人の脳に主語はいらない』, 講談社選書メチエ

[3] 月本洋(著), 『日本語は論理的である』, 講談社選書メチエ

[4] JIS X 0166:2021(ISO/IEC/IEEE 29148:2018)システム及びソフトウェア技術―ライフサイクルプロセス―要求エンジニアリング(Systems and software engineering -- Life cycle processes -- Requirements engineering)

[5] 五百井清右衛門, 黒須誠治, 平野雅章 著『システム思考とシステム技術』

＜早稲田大学システム科学研究所叢書＞白桃書房

[6] 緒方隆司(著), オリンパス(株)ECM推進部(監修)『製品開発は“機能"にばらして考えろ-設計者が頭を抱える「7つの設計問題」解決法』日刊工業新聞社

[7] ローレンス・D.マイルズ (著), 玉井 正寿 (翻訳)『VA/VEシステムと技法』日刊工業新聞社

[8] 秋山兼夫『機能分析―企業のシステム革新・効率化の基礎的ツール』( 財) 日本規格協会(1989年)

9] 石井 浩介, 飯野 謙次『設計の科学 価値づくり設計』養賢堂

[10] 前野隆司, 保井俊之, 白坂成功, 富田欣和, 石橋金徳, 岩田徹, 八木田寛之, 『システム×デザイン思考で世界を変える 慶應SDM「イノベーションのつくり方」 』, 日経BP

[11] ジェラルド ナドラー, 日比野 省三『新・ブレイクスルー思考 : ニュー・コンセプトを創造する7つの原則』ダイヤモンド社

[12] 清水吉男, 『【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？』, 技術評論社

[13] Jeff Patton (著), 川口 恭伸 (監修), 長尾 高弘 (翻訳)『ユーザーストーリーマッピング』オライリージャパン