山修の開発文書品質入門（15） ―― 自然な関節レビュー
山本 修一郎
| この連載コラム「山修の開発文書品質入門」では，開発文書に携わる皆さんに役立ちそうな開発文書の品質につながる知識を分かりやすく解説します． バック・ナンバ |
■自然な関節という考え方
プラトンが語る「統合」と「分割」における〈関節〉とは，概念を人為的に切断するのではなく，事物そのものがもつ本来的な構造に即して区別するための“分かれ目”を指す．プラトンは『パイドロス』で，正しい思考（弁証法）を次のように表現した．
「自然がもつ関節に従って切り分け，どの部分も肉屋のように無理に切り裂かないこと」
ここでの関節は比喩的表現で，骨格における関節や生き物が自然に分かれる節目を意味している．人為的・恣意的な分類をしてはならないという警告だ．
■要求仕様レビューと自然な関節
要求仕様レビューに「プラトンの自然な関節」を持ち込むと，レビューの質が一段階上がる．というのも，感覚的・属人的になりがちなレビューを，原理に基づくレビューへと昇華できるからだ．そこで以下では，要求仕様レビューを対象として整理しよう．なお、ここで述べる考え方は，設計書のレビューにもそのまま適用できる．
では，要求仕様レビューの本質的な問いとは何だろうか．この問いに答えるため，まず従来のレビューのあり方を振り返ってみよう．従来のレビューは，書式は合っているか，抜け漏れはないか，曖昧な表現はないかを確認している．このようなレビューは大事だが，プラトン的に言えばこれは「表層」の確認にとどまる．一方，プラトン的レビューの核心は「この要求は，自然な関節で切れているか？」を問うことにある．
以上を踏まえると，要求仕様レビューでは，単なる書式確認ではなく，「自然な関節で切れているか」という視点から要求を見直すことが重要になる．そこで以下に，この視点を具体化した，要求仕様レビューのための「プラトンの自然な関節チェック」を整理する．
① 要求単位チェック（統合と分割）
問い：この要求は「1つのイデア（目的）」を持つか？
- 複数の「〜することで〜し，さらに〜する」→ 関節またぎ
- 「〜する」だけで終わる→ 関節として成立
② 判断点チェック（判断が混在していないか）
問い：この要求の中に，判断は何回現れるか？
- if / 場合 / 条件 が複数→ 関節が混線
- 判断が1つ→ 自然な関節
③ 責務境界チェック（誰の要求か）
問い：この要求に対して，説明責任を持つ主体は誰か？
- 「システム」「利用者」「管理者」が混在→ 不自然
- 単一主体→ 自然
④ 価値意味チェック（業務価値が閉じているか）
問い：利用者から見て，意味が完結しているか？
- データ処理の途中だけ→ 関節途中
- 業務行為として意味が完結→ 自然
⑤ 変更耐性チェック（将来変化）
問い：この要求だけを変更したいとき，他に波及するか？
- 多数に影響→ 関節位置誤り
- 局所→ 自然
以上の①〜⑤のチェックは，要求が自然な関節で切れているかどうかを評価するための観点であり，レビュー時に用いる指摘テンプレートとなる．これらの観点を踏まえることで，レビュー時には，感覚的な違和感ではなく，原理に基づいた指摘を行うことができる．
次に，これらのチェック結果を，レビュー指摘としてどのように表現すればよいかを考える．要求仕様レビューで使いやすい指摘表現は以下の通り．
「この要求は複数の判断と目的を含んでおり，プラトンのいう自然な関節をまたいでいます．分割を検討してください．」
以下では，これらの指摘テンプレートがどのように適用できるかを示すため，自然な関節に従って，悪い要求 と 良い要求の例を紹介する．まず，関節を無視した悪い要求の例を示す．
|
＜要求記述の例＞ システムは注文を受け付け，在庫を確認し，出荷指示を行うこと． |
この記述では，目的が受付なのか，在庫確認なのか，あるいは出荷なのかが不明確である．判断では，在庫可否のどちらを確認しているのか不明だ．また，３つの責務「受付」「確認」「出荷」が混在している．上述したレビュー指摘テンプレート（①〜⑤の観点）がそのまま当てはまる例だ． この悪い要求記述の例を，自然な関節を持つ良い要求記述に改善すると以下の通り．
|
＜要求記述の改善結果＞ 要求1（受付） 注文が入力されたとき，システムは注文を受付として登録すること． 要求2（判断） 在庫が引当可能な場合，システムは出荷可否を判定すること． 要求3（実行） 出荷が許可された場合，システムは出荷指示を生成すること． |
この改善で，各要求が「1つの目的（イデア）」を持つようになった．
以上の例から分かるように，自然な関節に従って要求を分割すると，各要求が1つの目的と責務を持つようになる．この考え方を一般化したものが，自然な関節に基づくレビュー原則である．以下にその原則を示す．
【レビュー原則】
良い要求仕様は自然な関節で切られている．
このレビュー原則はプラトンの弁証法に基づいた要求工学のレビュー原理である．
■自然な関節に基づく要求仕様レビュー
以下では，要求仕様レビューにプラトンの「自然な関節レビュー法」を適用する．
| ＜対象要求仕様＞ セキュリティ監視システムは，通常の間隔では少なくとも60秒おきに，デバイスの状態を通知しなければならない． |
自然な関節レビューの5項目で，対象要求仕様をレビューした結果は以下の通りである．
① 目的一貫性チェック
問い：この要求は1つの目的を持っているか？
表面上の目的は「デバイスの状態を通知する」ことである．しかし暗黙に含まれる目的には，監視の継続性保証，異常検知の前提，通信死活監視がある．
判定： △（やや不明）
指摘：
- 「なぜ60秒なのか」という目的が要求内に現れていない
- 監視目的か，通信保証目的かが曖昧
② 判断点チェック
問い：判断は1つか？
要求仕様に含まれる判断は，「通常の間隔かどうか」の判断と「60秒以内かどうか」の判断の2つがある．
判定： ×（複数判断が混在）
指摘：要求仕様に含まれる「通常の間隔」という状態判断と「60秒」という時間制約判断が同一要求内で混在している．したがって２つの関節をまたいでいる．
③ 責務境界チェック
問い：説明責任主体は1つか？
要求仕様に含まれる主体はセキュリティ監視システムである．しかし，「通知」失敗時とネットワーク障害時の責務主体は不明である．
判定： △
指摘：
- 通知できなかった場合の責務境界が未定義
- システム責務か，通信基盤責務か不明
④ 価値完結性チェック
問い：業務的に意味は完結しているか？
要求仕様では「通知する」だけで，誰に？何のために？が書かれていない
判定： △
指摘：技術的動作は書かれているが，利用者・運用者視点の価値が閉じていない
⑤ 変更独立性チェック
問い：60秒が変わったら影響は局所か？
要求仕様から，監視ロジック，通信負荷，アラート設計に波及する可能性がある．
判定： △〜×
指摘：時間制約と監視概念が密結合．関節位置が粗い
以上の①〜⑤の観点から評価した結果を踏まえ，対象要求仕様を総合的に判定する．
【総合判定】
自然な関節レビューのチェック結果は，目的△，判断×，責務△，価値△，変更△
総合判定：△（関節再分割を推奨）
この要求仕様は，「監視の概念」「通知の責務」「時間制約」という異なる性質の関節を1文に押し込めているため，プラトン的に言えば「自然な関節で切られていない」．
自然な関節に従って，要求仕様を改善した結果は以下の通り．
|
＜要求仕様の改善結果＞ 要求1（目的・価値の関節） セキュリティ監視システムは，監視対象デバイスの稼働状態を運用者が把握できるようにすること． 要求2（判断の関節） デバイスが通常稼働状態にある場合，システムは状態通知を周期的に行うこと． 要求3（時間制約の関節） 通常稼働状態における状態通知の周期は，60秒以下でなければならない． |
この改善により，各要求が1目的・1判断，時間制約は独立した関節となり，変更耐性が向上したことが分かる．
■まとめ
本稿のまとめとして，あらためてプラトンの「自然な関節」に立ち返ろう．プラトンは，「結果が得られればよいという思考態度」を批判するために，「自然な関節」という比喩を用いた．本質的な構造を保つように論理で分離することが重要だとしたのである．今回は，要求仕様記述に対する「自然な関節レビュー」を紹介した．従来の肉屋レビューと自然な関節レビューを比較した結果を表にまとめる．
| 観点 | 肉屋レビュー | 間接レビュー |
| 見ているもの | 文・構造 | 世界の構造・本質 |
| 判断基準 | 実装しやすさ・即物性 | 自然な切れ目か |
| 分割の仕方 | 力任せ・短絡 | 統合と分割の往復 |
| 変化への耐性 | 低い | 高い |
| 哲学的態度 | 手段優先 | 本質優先 |
自然な関節レビューは，要求仕様だけではなくモジュール設計などの開発文書にも適用できる．開発文書も，ただ作成すればよいというものではない．本質的な構造を保存するように，開発文書を適切に作成する必要がある．
