要求工学知識体系

システム開発の手戻りの多くは、作る前の「何を作るか」の合意が曖昧なまま進んだことに端を発します。『要求工学知識体系』 (情報サービス産業協会 著、近代科学社、2011 年 6 月刊、第 1 版) は、副題に REBOK (Requirements Engineering Body Of Knowledge) を掲げ、要求の獲得 / 分析 / 仕様化 / 検証 / 管理という要求工学の営みを知識体系として一冊に整理した参照書です。国立国会図書館の書誌では情報サービス産業協会 (JISA) の REBOK 企画 WG が著者として記録されており、業界団体のワーキンググループが取りまとめた知識体系という性格を持ちます。214 ページの中に、要求工学の全体地図と用語の対照表、関連する標準やガイドラインの一覧までを収めています。

第 0 章から第 8 章まで、要求獲得から要求の計画と管理へ

構成は第 0 章「はじめに: 要求工学知識体系 (REBOK) 概説」から始まり、第 1 章「要求工学の基礎」と第 2 章「要求工学プロセス」で土台を固めた後、第 3 章「要求獲得」、第 4 章「要求分析」、第 5 章「要求仕様化」、第 6 章「要求仕様の検証・妥当性確認・評価」、第 7 章「要求の計画と管理」と、要求を扱う工程の順に知識領域を追います。第 8 章「実践の考慮点」で現場適用の観点を補い、巻末には「基本用語対照表」と「要求工学に関する標準・勧告・ガイドライン」の 2 つの付録を置きます。章立てそのものが要求工学のプロセスの見取り図になっているため、目次を眺めるだけでも、自分の組織のどの活動が手薄かを点検できます。

要求工学が難しい理由と、知識体系という形の効き目

要求工学が難しいのは、要求が最初から誰かの頭の中に完成形で存在するわけではないからです。獲得の段階では、利用者自身が言語化できていない暗黙の業務知識を引き出し、立場の異なるステークホルダーの間で食い違う期待を表に出す必要があります。分析の段階では、それらの要求の矛盾や優先順位を整理し、仕様化の段階では、自然言語の曖昧さを抑えながら、開発者と発注者の双方が同じ意味で読める形に落とし込まなければなりません。仕様ができた後も、レビューやプロトタイプによる検証と妥当性確認、変更が起きたときの影響追跡といった管理の活動が続きます。個々の技法は現場の経験で身につきますが、どの活動がどの目的で存在し、互いにどう接続するのかという全体像は、経験だけでは偏りがちです。知識体系という形式は、その全体像を知識領域ごとに区切って提示するもので、手順書やテンプレート集ではなく、自分たちの実践を位置づけるための地図として働きます。

ソフトウェア工学全体を扱う知識体系としては SWEBOK、ビジネス分析の側から要求を扱うものとしては BABOK が知られていますが、本書は情報サービス産業の業界団体が取りまとめ、要求工学に焦点を絞って日本語で体系化した点に独自性があります。付録の「基本用語対照表」は、用語の解釈が人によって揺れやすいこの分野で共通の語彙を確認する足がかりになり、「要求工学に関する標準・勧告・ガイドライン」の一覧は、より深く学ぶための参照先を示します。刊行は 2011 年で、その後にアジャイル開発の普及によって要求を ユーザーストーリー の形で段階的に育てる進め方が広がりましたが、獲得 / 分析 / 仕様化 / 検証 / 管理という活動の骨格そのものは開発手法が変わっても残るため、知識体系としての価値は時点に左右されにくい種類のものです。

要件定義の共通言語を求める組織に向く、2011 年刊という前提

最も元が取れるのは、要件定義 の進め方が担当者の経験に依存していて、組織として何を標準にすべきか迷っているチームのリーダーや PMO、そして発注側で要求をまとめる立場の情報システム部門です。プロセス改善や教育体系を作る際に、要求工学のどの知識領域を押さえるかの骨組みとして参照でき、個人としても、要件定義の場で自分が何を省略しているかを点検する物差しになります。一方、明日の要件定義会議で使えるヒアリングの質問例や要件定義書のテンプレートを求める人には、知識体系という体裁は遠回りに感じられるはずです。また 2011 年刊のため、クラウドサービスの調達のように、その後に広がった対象への当てはめは読者側で行う必要があります。

要求工学を体系として押さえた人は、要件定義の議論で自分たちがどの活動の段階にいるのかを言葉にでき、手薄な工程を早い段階で指摘できるようになります。上流工程の品質を属人的な勘から組織の共有知へ引き上げたいなら、REBOK を通読して知識領域の地図を手元に置くことが、その最初の一歩になります。