基礎知識カテゴリのエントリ

  山本 修一郎

■自然な関節という考え方

　プラトンが語る「統合」と「分割」における〈関節〉とは，概念を人為的に切断するのではなく，事物そのものがもつ本来的な構造に即して区別するための“分かれ目”を指す．プラトンは『パイドロス』で，正しい思考（弁証法）を次のように表現した．

「自然がもつ関節に従って切り分け，どの部分も肉屋のように無理に切り裂かないこと」

ここでの関節は比喩的表現で，骨格における関節や生き物が自然に分かれる節目を意味している．人為的・恣意的な分類をしてはならないという警告だ．つまり，関節とは，世界の側にある“理の切れ目”であり，人間の都合で作る線ではない．これを設計・要求レビューに引き寄せると，要求・機能・責務の自然な境界が関節であり，モジュール分割や業務分割で「なぜここで切るのか？」，「統合と分割を往復しても意味が壊れない設計か？」を問うことである．

■要求仕様レビューと自然な関節

要求仕様レビューに「プラトンの自然な関節」を持ち込むと，レビューの質が一段階上がる．というのも，感覚的・属人的になりがちなレビューを，原理に基づくレビューへと昇華できるからだ．そこで以下では，要求仕様レビューを対象として整理しよう．なお、ここで述べる考え方は，設計書のレビューにもそのまま適用できる．

では，要求仕様レビューの本質的な問いとは何だろうか．この問いに答えるため，まず従来のレビューのあり方を振り返ってみよう．従来のレビューは，書式は合っているか，抜け漏れはないか，曖昧な表現はないかを確認している．このようなレビューは大事だが，プラトン的に言えばこれは「表層」の確認にとどまる．一方，プラトン的レビューの核心は「この要求は，自然な関節で切れているか？」を問うことにある． 
 

以上を踏まえると，要求仕様レビューでは，単なる書式確認ではなく，「自然な関節で切れているか」という視点から要求を見直すことが重要になる．そこで以下に，この視点を具体化した，要求仕様レビューのための「プラトンの自然な関節チェック」を整理する．

① 要求単位チェック（統合と分割）

問い：この要求は「1つのイデア（目的）」を持つか？

• 複数の「〜することで〜し，さらに〜する」→ 関節またぎ
• 「〜する」だけで終わる→ 関節として成立
   

② 判断点チェック（判断が混在していないか）

問い：この要求の中に，判断は何回現れるか？

• if / 場合 / 条件 が複数→ 関節が混線
• 判断が1つ→ 自然な関節
   

③ 責務境界チェック（誰の要求か）

問い：この要求に対して，説明責任を持つ主体は誰か？

• 「システム」「利用者」「管理者」が混在→ 不自然
• 単一主体→ 自然
   

 ④ 価値意味チェック（業務価値が閉じているか）

問い：利用者から見て，意味が完結しているか？

• データ処理の途中だけ→ 関節途中
• 業務行為として意味が完結→ 自然
   

 ⑤ 変更耐性チェック（将来変化）

問い：この要求だけを変更したいとき，他に波及するか？

• 多数に影響→ 関節位置誤り
• 局所→ 自然
   

以上の①〜⑤のチェックは，要求が自然な関節で切れているかどうかを評価するための観点であり，レビュー時に用いる指摘テンプレートとなる．これらの観点を踏まえることで，レビュー時には，感覚的な違和感ではなく，原理に基づいた指摘を行うことができる．

次に，これらのチェック結果を，レビュー指摘としてどのように表現すればよいかを考える．要求仕様レビューで使いやすい指摘表現は以下の通り．

「この要求は複数の判断と目的を含んでおり，プラトンのいう自然な関節をまたいでいます．分割を検討してください．」

以下では，これらの指摘テンプレートがどのように適用できるかを示すため，自然な関節に従って，悪い要求 と 良い要求の例を紹介する．まず，関節を無視した悪い要求の例を示す．

この記述では，目的が受付なのか，在庫確認なのか，あるいは出荷なのかが不明確である．判断では，在庫可否のどちらを確認しているのか不明だ．また，３つの責務「受付」「確認」「出荷」が混在している．上述したレビュー指摘テンプレート（①〜⑤の観点）がそのまま当てはまる例だ． この悪い要求記述の例を，自然な関節を持つ良い要求記述に改善すると以下の通り．

この改善で，各要求が「1つの目的（イデア）」を持つようになった．

以上の例から分かるように，自然な関節に従って要求を分割すると，各要求が1つの目的と責務を持つようになる．この考え方を一般化したものが，自然な関節に基づくレビュー原則である．以下にその原則を示す．

【レビュー原則】

良い要求仕様は自然な関節で切られている．

 このレビュー原則はプラトンの弁証法に基づいた要求工学のレビュー原理である．

■自然な関節に基づく要求仕様レビュー

以下では，要求仕様レビューにプラトンの「自然な関節レビュー法」を適用する．

自然な関節レビューの5項目で，対象要求仕様をレビューした結果は以下の通りである．

① 目的一貫性チェック

問い：この要求は1つの目的を持っているか？

表面上の目的は「デバイスの状態を通知する」ことである．しかし暗黙に含まれる目的には，監視の継続性保証，異常検知の前提，通信死活監視がある．

判定： △（やや不明）

指摘：

• 「なぜ60秒なのか」という目的が要求内に現れていない
• 監視目的か，通信保証目的かが曖昧
   

② 判断点チェック

問い：判断は1つか？

要求仕様に含まれる判断は，「通常の間隔かどうか」の判断と「60秒以内かどうか」の判断の2つがある．

判定： ×（複数判断が混在）

指摘：要求仕様に含まれる「通常の間隔」という状態判断と「60秒」という時間制約判断が同一要求内で混在している．したがって２つの関節をまたいでいる．
 

③ 責務境界チェック

問い：説明責任主体は1つか？

要求仕様に含まれる主体はセキュリティ監視システムである．しかし，「通知」失敗時とネットワーク障害時の責務主体は不明である．

判定： △

指摘：

• 通知できなかった場合の責務境界が未定義
• システム責務か，通信基盤責務か不明
   

④ 価値完結性チェック

問い：業務的に意味は完結しているか？

要求仕様では「通知する」だけで，誰に？何のために？が書かれていない

判定： △

指摘：技術的動作は書かれているが，利用者・運用者視点の価値が閉じていない

⑤ 変更独立性チェック

問い：60秒が変わったら影響は局所か？

要求仕様から，監視ロジック，通信負荷，アラート設計に波及する可能性がある．

判定：  △〜×

指摘：時間制約と監視概念が密結合．関節位置が粗い

以上の①〜⑤の観点から評価した結果を踏まえ，対象要求仕様を総合的に判定する．
 

【総合判定】

自然な関節レビューのチェック結果は，目的△，判断×，責務△，価値△，変更△

総合判定：△（関節再分割を推奨）

この要求仕様は，「監視の概念」「通知の責務」「時間制約」という異なる性質の関節を1文に押し込めているため，プラトン的に言えば「自然な関節で切られていない」．

自然な関節に従って，要求仕様を改善した結果は以下の通り．

　この改善により，各要求が1目的・1判断，時間制約は独立した関節となり，変更耐性が向上したことが分かる．

■まとめ

本稿のまとめとして，あらためてプラトンの「自然な関節」に立ち返ろう．プラトンは，「結果が得られればよいという思考態度」を批判するために，「自然な関節」という比喩を用いた．本質的な構造を保つように論理で分離することが重要だとしたのである．今回は，要求仕様記述に対する「自然な関節レビュー」を紹介した．従来の肉屋レビューと自然な関節レビューを比較した結果を表にまとめる．

自然な関節レビューは，要求仕様だけではなくモジュール設計などの開発文書にも適用できる．開発文書も，ただ作成すればよいというものではない．本質的な構造を保存するように，開発文書を適切に作成する必要がある．

 山本 修一郎

　このコラムの第12回「非機能要求と例外」では，システムの構成要素間の依存関係に基づく機能例外を考慮することによって，システム全体の非機能要求を確認する方法を考察した．これは，あるグループ企業で生産能力を越えた仕事を受注した結果，品質検査工程で上司から手抜きを強要された社員の外部通報によって社会問題化した事例に基づくものであった．

　2024年6月になって，このグループ企業だけでなく，日本の多くの自動車メーカーで，型式認証不正が発覚して，国土交通省が立ち入り検査する事件になった．たとえば，自動車業界の経営層による、次の意見が紹介されている[1]．

「順法性の観点が欠けていた」

「業務手順で足りない部分があり，それを現場の判断で補う仕事をさせてしまった」

「当然出ると思っていた．隠し切れるものでもない」

本稿では，例外に基づいて業務プロセスの包括的な完全性を制御する方法[2][3]を紹介する． 

まず，自工程完結(Ji-Koutei-Kanketsu, JKK) [4]を説明する．生産工程の自工程完結は，特定のプロセスだけでなく，生産プロセス全体を最適化する手法である．JKKを導入するには，業務の流れを定義する業務手順だけでなく，業務要件を定義する要件整理シートを定義する必要がある．業務プロセスごとに必要な項目・情報，業務インプット，業務アウトプットのフィールドから要件整理シートを作成する．必要事項・情報欄では，製品の品質の条件として入力，ツール，方法，能力・権限，理由を記入する．入力フィールドには，いつ，どこで，何を受け取るかなどの基準を記述する． 出力フィールドには，どこに，いつまでに，何を生産するかを記述する． 基準フィールドには，「プロセスの出力が良品である」と判断するための基準を記述する．
JKKの重要な特徴は，ビジネスプロセス要素ごとに完全性条件を明確にできる要件整理シートである．

次に，欠陥未然防止図(Defect Prevention Diagram, DPD)を説明する．（文献[2]ではDPDを自工程完結図式と称していたが，欠陥を未然防止できることから改名した）

図 1 に示すように，DPDは6つの辺を持つ六角形のノードによって定義する．これらの側面は，入力，出力，受取条件，資源条件，例外条件，判断条件に対応している．受取条件，入力，資源条件，および判断条件の側面は，外部要素からの業務プロセスへの流れを表す． 出力および例外条件の側面は，業務プロセスから外部要素への流れを表す．例外条件と出力を異なる流れとして分離した点に，DPDの特徴がある．

図1　欠陥未然防止図（DPD）

DPDの関係には，「接続関係」と「伝播関係」の2つがある．

業務プロセス間のフローを定義する「接続関係」は，プロセスの出力側面から他のプロセスの入力側面に流れる二項関係である． 

「伝播関係」は，1) プロセスの例外条件が他のプロセスの受取条件に流入すること，および 2) プロセスの例外条件が他のプロセスの例外条件に流入することを定義する．「伝播関係」は，プロセスの例外を前方および後方にある他のプロセスに伝播するために使用される．前方伝播では，下流のビジネスプロセスから上流のビジネスプロセスに例外を，流れとは逆に伝搬する．後方伝播では，上流のビジネス プロセスから下流のビジネスプロセスに例外を伝搬する．

このような例外伝播分析により，ビジネスプロセス改善の候補を発見できる．プロセスに例外が通知された場合，プロセスは例外を処理するために受取条件，資源条件，判断条件を変更する必要がある．この仕組みによって，環境変化に応じて持続可能性を向上させる包括的なプロセス進化の機会を提供できる．

DPDで業務プロセスが完了したかどうかを確認する条件は次のとおりである．

1. 受取条件が満たされていない場合，プロセスは開始されない．
2. 資源条件が満たされない限り，プロセスは開始されない．
3. 自プロセスの処理結果が判断条件を満たさない場合は出力されない．
4. 自プロセスが起動できない場合，または出力が判断条件を満たさない場合に例外条件を生成する．
5. 受信条件を満たす入力に対して資源条件が満たされた場合，自プロセスの判断条件を満たす出力を生成する．

以下では，JKKとDPDを比較する．

まず，JKKでは業務フロー図と業務プロセスごとに要件整理シートを作成する．これに対して，DPDでは，欠陥未然防止図だけで業務プロセス全体を俯瞰する．

次に，JKKでは，要件整理シートで良品条件として，受取基準，道具，方法，能力・権限，理由，出力，判断基準を記述する．DPDでは，入力，受取条件，資源条件，出力，判断条件を図のラベルで記述する．DPDでは例外条件を明示するが，JKKでは，例外条件を記述しない．

DPDを使って，自動車メーカーで起こった型式認証不正の要因を分析した結果を，図２に示す．開発工程から試験車両を受け取ると，認証工程では試験成績書を作成する．認証工程の，まず，試験車両の受取条件は試験期間のリードタイムを確保できること，資源条件は，試験条件と試験期間ならびに型式認証制度を守ること，判断条件は，型式認証の合格基準である．

図2　型式認証不正と例外伝搬

認証不正が発生した理由は，十分なリードタイムが取れない状況で試験車両が認証工程に渡されたこと，型式認証制度の遵守が欠落していたこと，合格基準が型式認証制度に対して不十分であったことなどである．本来，これらの条件が満たされない場合，認証工程で例外を検出して，開発工程に欠陥を伝搬させて対応する必要があったことが，図2から明らかである．

DPDは，例外を見える化することによって欠陥を未然防止できる「欠陥未然防止図」である．「良いことしか起こらない」ことを前提とするのではなく，「想定外の状況が起きるかもしれない」ことを前提とする欠陥の未然防止が求められている．
JKKでは，「良品条件」の明確化を前提としているので，例外は「あってはならないこと」として無視されている．

しかし，ビジネス環境は変化するから，変化を例外として検知して適切に対応する必要がある．

 山本 修一郎

　要求仕様者のレビュー結果の妥当性を確認するためには、客観的な評価基準が必要です。本稿では、要求仕様書の語彙に基づく客観的なレビュー手法を紹介します。 

　まず、レビュー項目では曖昧さの種類を定義します。曖昧さの種類は、①用語自体、②用語属性、③用語例外（用語が正常ではない場合）のいずれかです。用語属性には、範囲、下限、上限があります。

次に、用語の曖昧さに基づいて、レビュー精度を定義します。

定義　レビュー精度水準値　L

0:曖昧用語がない

1:曖昧用語がある 

2:用語属性が曖昧である 

3:用語例外が曖昧である 

たとえば、用語 W の上限などの用語属性が省略されている場合、L(W) =2 となります。

 定義　語彙の次元

語彙の次元を、要求仕様の基本要素として「イベント」「入力」「機能」「出力」「応答」で定義します。そして、語彙の次元ごとに、レビュー精度水準値を評価します。

 　語彙レビューの過程で、レビュー担当者は特定の要件仕様に対する一連のレビュー項目を作成します。

 ＜実験＞

　要求工学の研修コースの中で、要求レビューの実験をオンラインで実施しました。この実験には、16名の組込みソフトウェア開発者が参加しました。開発者の経験年数は、3名が5年未満（以下「初心者」）であり、他の13名は5 年以上（以下「経験者」）でした。

　実験に参加した16名の被験者は、インスリンポンプ制御システムに関する次の5つの要求文をレビューしました。

(R1) インスリンポンプ制御ソフトウェアは、患者に埋め込まれたセンサーを使用して、血糖値に比例した血液パラメータを測定します。

(R2) 血液パラメータはポンプコントローラに送られます。

(R3) ポンプコントローラーは、必要なインスリンの糖度と量を計算します。

(R4) ポンプコントローラーは、患者に埋め込まれた針を介してインスリンを投与するために、小さなポンプに信号を送信します。

(R5) インスリンポンプは、ポンプコントローラからの1単位パルスに応答して1単位のインスリンを投与します。 

 　各被験者がこれらの要求文に対してレビューを行い、前述した定義に基づいて要求文Rのレビュー精度水準値Lを、以下のように計算します。

L(R)=（Rの語彙の曖昧さに対する指摘数）／Rの用語数 

　ここでもし、被験者によるレビューにおいて要求文の語彙の曖昧さに対する指摘がなければ、L(R)＝0になります。また、指摘数が多くなると、L(R)は大きくなります。

　レビュー対象とした要求文R1からR5までのL(R)の平均値を、語彙の次元ごとに計算した結果を表1に示します。

　表1では、曖昧な項目が検出された平均レベルを示しています。経験者の数値が初心者の数値より高いのは、曖昧用語の指摘数が多いことを示します。たとえば、曖昧な「イベント」項に対する初心者のレビュー精度水準値L(R) は0.067であるのに対し、経験者の L(R) は0.323です。したがって、経験者による曖昧な「イベント」項のL(R) は、初心者の4.85倍です。

 　表1から、経験者と初心者による曖昧用語レビューの大きな違いが「イベント」と「入力」にあることが分かります。一方、「機能」に対する経験者と初心者の差は、これらに比べると大きくないことが分かります。経験者の場合、機能をいつ実行するかという「イベント」と、機能が何を処理するかという「入力」に対し、注意深く要求文を確認する経験知識があると考えられます。このことから、初心者には「イベント」と「入力」について確認する訓練が必要であると言えます。

　このように表1は、経験者と初心者の語彙レビュー知識の差を明らかにしていることが分かります。

　表1の結果から、初心者と経験者による L(R) をレーダーチャートとして図1に示します。

図1：被験者別のレビュー精度水準値L(R)の比較

 まとめ

　本稿では、組込みソフトウェア開発者向けに語彙による要求レビュー手法を提案しました。本手法により、曖昧な用語のレビュー精度を数値化できます。本手法を用いて、要求仕様のレビュー実験を行い、定量的な評価を示しました。この実験から、初心者と経験者の要求レビュー能力の差を客観的に示せることが分かりました。

　本手法に基づいて、語彙の観点から自然言語要件仕様の曖昧な用語を検出でき、要求レビューを標準化できます。なお、本稿の内容は、論文[1]の要約に基づいています。

参考文献

[1]Shuichiro Yamamoto, Requirements Review Education Curriculum for Embedded Software Practitioners, WSSE '23: Proceedings of the 2023 5th World Symposium on Software EngineeringSeptember 2023Pages 184–187

  山本 修一郎

「仕事量を見誤ったか」

生産能力を越えた仕事を受注した結果、品質検査工程で上司から手抜きを強要された社員による外部通報が発生して社会問題化した，ある自動車企業の経営者の言葉だ．この会社のグループ企業では，同じことを繰り返している．

ところで，企業の生産能力を越えた過大な注文を受ければ，所要量の製品やサービスを生産できないか，生産できたとしても製品やサービスの品質が低下するのは明らかである．この経営者は生産能力という最も重要な組織能力の正確な値を認識していなかったことになる．正しい生産能力を知らなければ，注文数が生産能力を越えたかどうか分からない．逆に，生産能力の上限が分かっていれば，過剰な注文数を例外として検知することにより，それ以上の受注を制限できる．

同じことが情報システム障害の原因にもなることがある．たとえば，サービスを受付サーバと処理サーバによる分散システムとして構成することがある．処理サーバの処理能力には上限がある．処理能力を越えたサービス依頼を受付サーバで受理した結果，処理サーバが過負荷となってシステム全体が停止することになる．

DXがめざす姿の一つにデータ駆動経営がある．企業の生産データをリアルタイムに収集することで，生産能力に応じて適切な受注判断ができる．分散型情報システムの例でも，後続サーバの処理能力を越える可能性を先行サーバ側で例外として検知できれば，システム全体の性能や信頼性などの非機能要求の低下を抑止できる．

このように，システムの構成要素間の依存関係に基づく機能例外を考慮することによって，システム全体の非機能要求を達成できる．

 山本 修一郎

これまで，要求仕様書の書き方について説明してきました．本稿では，ユーザーストーリーを紹介して，要求仕様との関係を説明します．

■ユーザーストーリー

ユーザー視点で，顧客価値と対応付けて機能要求を定義する手法がユーザーストーリーです．ユーザーストーリーの英語構文は，次の通りです．

As a <User>, I want <Function> so that <Value>.

ここで，ユーザー<User>，機能<Function>，価値<Value>が変化する部分です．ユーザー，機能，価値は，Who，What，Whyに対応しています

ユーザーストーリーでは，この構文に従って，ユーザーが求める機能と価値を抽出することができます．日本語でユーザーストーリーを書くと，語順が変わりますが，次のようになります．

• カード会員として，商品を購入するために，カード決済したい．
• カード会員として，乗車するために，スマホでカードを利用したい．

■ユーザーストーリーの作成法^[1]

表1のようにして，ユーザーストーリーを作成できます．まずユーザー像を特定します．次いで，ユーザーが解決したい問題，すなわち機能を使う目的を明確にします．最後に，目的を実現する機能を抽出します．この各手順では，ユーザー像，目的，機能を識別するために役立つ質問を示しています．また，手順で作成するユーザー像，目的，機能を例示しています．

■ユーザーストーリーマッピング

　ユーザーストーリーを単文で記述することになるので，たくさんのユーザーストーリーができます．そこでユーザーストーリーをまとめる方法が必要になります．ユーザーストーリーマッピングは，小ストーリーを集めた中ストーリーからさらにそれをまとめた大ストーリーへと段階的にユーザーストーリーを構造化する手法です（図１）．中ストーリーで物語（ストーリー）のまとまりを作ります．中ストーリーをまとめることで，大きな物語の流れを説明できます．

図1 ユーザーストーリーマッピングの構造

■ユーザーストーリーの例

図書館の受付係が使う図書貸出管理システムを例として，ユーザーストーリーを記述してみます．図書貸出管理システムの以下の機能に対するユーザーストーリーは表2の通りです．

• 会員情報を確認する
• 会員の図書貸出状況を確認する
• 図書の貸出を登録する

表2 図書貸出管理システムのユーザーストーリー

このように，ユーザーストーリーによって，機能要求に対するユーザーとその目的を明確にできることが分かります．

■ユースケースとユーザーストーリー

ユースケースの記述では，システム機能を記述します．しかし，ユーザーによるシステム機能の操作を記述しないので，ユーザー操作とシステム機能との整合性を確認する必要があります．そこで，図2に示すように，ユーザー操作とシステム機能との対応表を用いて，イベント条件と機能を明確化することができます．図2では，ユーザー操作①に対してシステム機能②が実行され，次いでユーザー操作③が発生してシステム機能④が実行されることを示しています． 

図2　ユーザーストーリーとユースケースの関係

■例

ビデオ貸出システムに対するユーザー操作とシステム機能の関係を表3に示します．ユーザー操作では，ユーザーストーリーの記述から，ユーザーと目的を省略して，機能を使う操作を記述しています．

表3 ユーザー操作とシステム機能要求

■USDMとユーザーストーリー

表3の記述を見ると，USDM(Universal Specification Description Manner)と似ていることに気づかれた方もいると思います．USDMでも表形式で機能要求を記述します．USDMと表3の違いは，ユーザー操作をシステム機能と分離するとともに，関係を明確にしている点です．そういう意味で，USDMにユーザー操作を対応付けていることになります．また，ユーザーストーリーに基づいてUSDMを作成する方法を表3が示していることになります． 

参考文献

[1]asana, 優れたユーザーストーリーの書き方, https://asana.com/ja/resources/user-stories

  山本 修一郎

本ブログ第4回では，国際標準に基づく要求文のテンプレートの例を紹介した．

今回は，MazoとJaramillo[1]が，新たに提案しているシステム要求仕様の構文を紹介する．彼らは構成要素を8種類に分類している（表1）

これらの構成要素からなる要求仕様文に対する要求構文は次のようになる．

ここで，日本語の動詞にはサ変活用があるので，義務の部分を日本語にするのは難しい．日本語では，＜義務＞部分に，「必ず，絶対，できれば」などを使うことになる．それよりは，義務部分を表す，必須◎，望ましい〇，省略可△などの識別子を要求文の属性とすることにより，要求の優先順位を区別する方が明確になると思われる． 

以下では，この分類に従って要求仕様テンプレートの記述例を説明する．

条件

例：加熱スイッチが押下されたら

システム

例：電気ポット制御システムが

活動

例：加熱信号を送信する

対象

例：ヒータに

評価条件

例：直ちに

評価条件によって，活動に対する性能や信頼性についての非機能要求を記述できる．

活動条件

例：沸騰していない限り

対象条件

例：水タンクが空でない限り

■要求テンプレートによる記述例

上述した要素例をまとめて，要求文を記述すると，次の通りである．

 ただし，この例では，日本語として読みやすいように，要求構文の表現を改めている．このため，日本語の場合，語尾変化を考えて，要求構文を節の集まりで表現した方がいいと思われる．

【システム要求構文】

参考文献

[1]Raul Mazo, Carlos Andrés Jaramillo, Paola Vallejo, Jhon Medina. Towards a new template for the specification of requirements in semi-structured natural language. Journal of Software Engineering, Research and Development, Brazilian Computer Society, 2020, 8, pp.3. 10.5753/jserd.2020.473. hal-02502411

[2] Davies, Rachel. Format for expressing user stories. 2001.

[3] Wiegers, Karl, and Joy Beatty. Software Requirements Third Edition. Microsoft Press, 2013.

[4] Mavin, A., P. Wilkinson, A. Harwood, and M. Novak. "Easy Approach to Requirements Syntax (EARS)." International Requirements Engineering Conference RE, 2009: 317-322.

[5] ISO/IEC/IEEE. "29148 Systems and software engineering (Life cycle processes — Requirements engineering)." 2011.

 山本 修一郎

機能要求の書き方について，本ブログ第4回で要求テンプレートを紹介した．情報システムの信頼性を向上する上で，非機能要求を明確に定義することが重要である[1]．本稿では，非機能要求の書き方について紹介したい．

ロバートソン ら[2]は，非機能要求(NFR, Non Functional Requirements)を8種類に分類している（表1）．以下では，この分類に従って非機能要求の記述例を説明する．

1. 外見要求

2. 使用要求

 山本 修一郎

開発文書品質の一つに「理解性」がある．開発文書を理解することは，開発文書に含まれる用語の関係を理解することだと考えられる．そこで，用語の関係を図で表現できることに気づく．このような図にSystemigram(システミグラム)がある[1][2]．

Boardmanは，自然言語による文章表現と対応しやすい図として，Systemigramを考案した．Systemigramでは，名詞(句)と名詞(句)間の関係を次のような記述として定義する．

• 名詞(句)：ノード（点）
• 名詞(句) 間の関係を示す動詞(句)：ノード間の関係（線）

つまり，「名詞を表す点」と「動詞を表す線」の関係を使って，文章を図で理解できる．

例えば、下記の例文をSystemigramで表現してみよう．経済産業省が企業のDXに関する自主的取組を促す経営者に求められる対応をデジタルガバナンス・コードとして提示している[3]．この「デジタルガバナンス・コード」のビジョン・ビジネスモデルの柱となる考え方を説明している次の文を用いる．

 

山本 修一郎

　要求を明確に表現するには，要求仕様書などの文書の単位や，それぞれの要求を記述する文章の単位で，明確であることが求められます．その文書や文章を明確にするには，それらを構成する基本単位である個々の文の単位で曖昧性を排除することも必要です．今回は，要求記述の基本単位となる個々の要求文を明確にする方法を考えます．

　要求文を与えられて，「この要求を確認してください」と言われたら，みなさんはどうしますか？要求文の簡単な確認方法として，文を構成する部分ごとに確認する方法を紹介します．

■部分要素に分解する

• セキュリティ監視システム
• 通常の間隔では
• 少なくとも60秒おきに
• デバイスの状態
• 通知しなければならない

■部分要素を確認する

■組込み仕様への適用例

  

■まとめ

 このようにして，要求文を部分要素に分解して要求確認表を作ることによって，明確になっていない点をあぶりだすことができます．これは，要求を確認する側だけでなく，要求を書く側にとっても活用できる方法です．書く側では，要求文を記述する際に，要求確認表で予め整理することによって，曖昧な要求記述を回避することもできます．

 山本 修一郎

ソフトウェア開発における知識の流通形態として，文書化と対話を考えることができる．文書化を徹底すれば対話量を削減できる．逆に，文書量を削減すれば，必要な知識を獲得するために，多くの対話が必要になる．

アジャイル型開発では，文書化量は削減する代わりに，濃密な対話によって開発に必要な知識を補完することになる．

たとえば，アジャイル型開発では，「①プロセスとツール，②理解しやすい文書，③契約交渉，④計画順守」よりも，「⑤個人と対話，⑥動くソフトウェア，⑦顧客連携，⑧変化対応を優先すること」に価値をおいている[1]．これによって，ソフトウェア開発のさまざまな無駄を省くことを目的としている．無駄な文書やコードを作らないことと，逐次的にソフトウェアをリリースして開発期間を短縮することなどの特徴がアジャイル型開発にはある．

これに対して，ウォータフォール型開発では，工程を明確に定めて工程生産物としての開発文書を作成する．曖昧さや抜け漏れのない開発文書を作成することにより，手戻りのない開発を目的としている．

以上の議論から，文書化量を横軸，対話量を縦軸として，アジャイル型とウォータフォール型の開発をプロットすると，図1のようになる．

図1 文書化と対話からみたアジャイル型とウォータフォール型の開発

アジャイル型開発を進めるためには，対話能力が開発者に要求される．しかし，現場の開発者は十分な対話能力を持っていないことも多い．そこで考えられるのが，対話能力不足を文書で補うことである．実際，ある研究会で筆者がこの図を紹介した際に，アジャイル開発の現場でウォータフォール型の手法が見直されているという話を聞いた．図1でいえば，曲線の中間に位置づけられるような開発手法が現場で求められているということであろう．

そのような中間的な手法として，エレン・ゴッテスディーナーとメアリー・ゴーマンによる発見から納品へ（Discovery to Delivery, D2D）がある．

D2Dでは，文書に基づいて対話を構造化する「構造化会話(Structured Conversation)」を提案している．D2D型開発を図1に付加すると，図2のようになる

図2 文書化と対話からみたD2D型の開発

D2Dでは，対話を構造化できるように適応した文書を提案している．すなわち，表1に示すように，D2Dでは，開発プロダクトの７側面に対して，対話で活用すべき文書を提示している．

 ここで，プランゲージ(Planguage)[3]は品質特性を可視化するためにGilbが提案したテンプレート形式の表記法である．Baasらが提案した品質特性シナリオ[4]は，①発生源，②刺激，③環境，④シナリオ，⑤システム，⑥成果物，⑦応答，⑧評価基準を記述することによって，品質特性を明らかにできる．

参考文献

[1] アジャイルソフトウェア開発宣言, http://agilemanifesto.org/iso/ja/manifesto.html

[2] Ellen Gottesdiener, Mary Gorman, Discover To Deliver: agile product planning and analysis, EBG Consulting, Inc., 2012.
    (エレン・ゴッテスディーナー，メアリー・ゴーマン，発見から納品へ- アジャイルなプロダクトの計画策定と分析，株式会社オージス総研訳，ブックウェイ，2014.)

[3] Gilb, Thomas, Competitive Engineering: A Handbool for Systems Engineering, Requirements Engineering and Software Engineering Using Planguage, Butterworth-Heinemann, 2005.

[4] Baas, Len, Paul Clements, and Rick Kazman, Software Architecture in Practice, second edition, Addison-Wesley, 2003.
   （前田他訳，実践ソフトウェアアーキテクチャ, 日刊工業新聞社，2005.)