要求工学と類似プラクティスの関係

本記事では、要求工学とデザイン思考、ユーザーストーリーマッピング、リーンスタートアップ、SysML などの類似プラクティスとの関係について解説します。広く捉えればこれらは顧客や利害関係者の要求を理解し、製品やサービスの開発に反映するための手法であり、それぞれが要求工学の異なる側面と考えることは可能ではないでしょうか。

（注意）本記事は生成AIによって調査・生成されたものであり、正確性を保証するものではありません。参照にあたっては、リンク先のサイトの情報も併せて参照下さい。

1. 要求工学の概要

要求工学 (Requirements Engineering) とは、システムやソフトウェアの開発においてステークホルダーのニーズと要件を体系的に収集・分析・文書化・検証・管理するプロセスである。

典型的な要求工学プロセスには、要求獲得（利害関係者からの要求の収集）、要求分析（要求の矛盾・不明確さの解消と優先度付け）、要求仕様化（要求を明確に文書化）、要求検証（要求が妥当で正確かの確認）、要求管理（要求の追跡と変更管理）といった段階が含まれる。これらのプロセスを適切に実行することで、プロジェクト関係者間で共通の理解を形成し、最終成果物が当初のニーズを満たすようにすることが可能になる。

要求工学は、要求の不明確さや誤解による手戻りやプロジェクト失敗のリスクを低減し、製品やシステムの成功率を高める上で重要である。特に開発初期に要求を確定・合意し検証することで、後工程での高価な仕様変更を回避し、ステークホルダーの満足度を向上させる効果がある。要求工学はこのように、プロジェクト全体の基盤を築き、適切なコミュニケーションと文書化によって「本当に必要なもの」を見極めるための重要な手法である。

参考: What is Requirements Engineering? - Requirements.com

2. 各手法の解説と要求工学への適用

デザイン思考

デザイン思考 (Design Thinking) とは、人間中心の創造的問題解決手法であり、ユーザの潜在ニーズに深く共感しながら革新的な解決策を生み出すことを目的とする。複雑で明確な解答がない「Wicked（解決困難な）な問題」に取り組む際に有効で、既存の思い込みを問い直しながらユーザ価値の高いアイデア創出を可能にするアプローチである。デザイン思考のプロセスは一般に5つの段階から構成される:

共感 (Empathize): ユーザや関係者への観察・インタビューを通じてニーズや課題を深く理解する段階。
問題定義 (Define): 収集した知見を分析し、真に解決すべき問題を明確化する段階。
創造 (Ideate): 問題に対する創造的解決策のアイデアをブレインストーミングなどで数多く生み出す段階。
試作 (Prototype): 有望なアイデアを簡易な試作品として具体化する段階。
テスト (Test): 試作品をユーザに評価してもらいフィードバックを得ることで、解決策や要求の妥当性を検証する段階。

これらのステップを非直線的かつ反復的に実施するのが特徴で、必要に応じて前の段階に戻り問題の再定義や新たなアイデア創出を行う。

デザイン思考は要求工学と補完的な関係にあり、特に要求獲得の初期段階や要求の妥当性確認に役立つとされる。

従来の要求工学が「ステークホルダーから要求を引き出す（言われたことを集める）」傾向があるのに対し、デザイン思考ではユーザの潜在的な欲求や問題の本質を共感によって探索し、表面的に与えられた要求の背後にある真のニーズを発見することに焦点を当てる。そのため、要求が不確定で変動しやすいイノベーティブなプロジェクトにおいて、デザイン思考は従来見落とされがちな要求（潜在ニーズや隠れた制約）を引き出し、問題空間を広げて検討することに寄与する。

一方で、デザイン思考で得られた洞察や試作品をいかに正式な要求仕様に落とし込んで開発プロセスに接続するかが課題となる場合があり、要求工学のプロセスと統合していく工夫（例えば得られたユーザストーリーやプロトタイプ検証結果を要求ドキュメントやバックログに反映するなど）が重要である。

参考:

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

ユーザーストーリーマッピング (User Story Mapping) とは、ソフトウェアや製品に対するユーザ視点の要求（ユーザーストーリー）を時系列の物語に沿って視覚的にマッピングする手法である。単なる要求リストでは捉えにくいユーザの全体的な体験の流れをマップ上に表現し、要求の抜け漏れの発見や機能の優先順位付けに役立てることを目的とする。具体的には、まずユーザが目的を達成するために行う大まかな活動（アクティビティ）やプロセスの流れを横軸に沿って列挙し（これをストーリーマップの「バックボーン」と呼ぶこともある）、各活動の下にそれを実現する個別の ユーザーストーリー（ユーザのタスク） を詳細に並べていく。こうすることで、製品が提供すべき機能をユーザ視点で網羅的に俯瞰でき、バックログ（要求の一覧）における抜けや重複を視覚的に検出できる。

ユーザーストーリーマッピングは、従来の長大な要求仕様書や平坦なリスト形式のバックログでは対応しづらい要求の変更やステークホルダー間の認識齟齬に対処する、よりアジャイルな要求整理法として提唱された。この手法ではチーム全員が一堂に会して付箋やカードを用いてストーリーマップを作成するワークショップ形式が推奨され、関係者全員が 「なぜこの製品を作るのか」「誰のための機能か」「どの順序で提供するか」 を共有理解する効果がある。出来上がったストーリーマップは、横軸に沿って重要度や実現時期に応じてストーリーに優先順位を付け、例えば上段を最小実用製品（MVP）としてまずリリースし、下段のストーリーは次のリリースに回す、といった形で段階的リリース計画を策定するのに用いられる。

このようにユーザーストーリーマッピングは要求工学における要求分析・構造化および要求管理に適用できる手法であり、チームが顧客価値に直結する要求から順に開発し、フィードバックに基づき迅速に改善を繰り返すための土台を提供する。結果として、ユーザにとって本当に価値の高い機能にフォーカスした開発が可能となり、無駄な機能の実装を避けるのに寄与する。ユーザーストーリーマッピングはJeff Patton氏によって提唱され広まった経緯があり、現在ではアジャイル開発における要求管理（プロダクトバックログ管理）のベストプラクティスの一つとして定着しつつある。

参考：

リーンスタートアップ

リーンスタートアップ (Lean Startup) は、製品やサービスの開発において仮説検証型のアプローチを取る手法であり、アイデアを迅速に試作して市場から学習しながら製品を進化させていくことを重視する。エリック・リース(Eric Ries)によって提唱されたこの手法では、「ビルド-メジャー-ラーン (Build-Measure-Learn)」というフィードバックループが核となっている。まず解決すべき課題や仮説を定め、それを検証するための最小限の実用的製品 (MVP: Minimum Viable Product) を構築し、実際のユーザに使ってもらってデータを測定 (Measure) し、その結果から学習 (Learn) して次のアクションを決定する、というサイクルを高速に回す。

MVPは必要最小限の機能だけを備えた製品であり、これを市場に投入してユーザや顧客からフィードバックを得ることで、仮説が正しいかどうかを素早く検証する。例えば新製品アイデアに対し、まず小規模なプロトタイプや限定機能版を提供してユーザの反応を確認し、期待通りの価値提供ができているかデータを収集する。結果が良好であればその方向性（仮説）を継続 (Persevere) し、もし顧客の関心が得られなかったり仮説が誤っていた場合には方向性を転換 (Pivot) して別の仮説を試す、といった意思決定を行う。

リーンスタートアップは要求工学の観点では主に要求の検証（妥当性確認）プロセスに該当すると言える。従来は要求を詳細まで定義してから開発を行い、リリース後に市場の反応を見て失敗に気付くというケースが多かったのに対し、リーンスタートアップでは要求を仮説とみなし、早期に実ユーザ検証することで手戻りを減らし、市場に適合する製品要求へと柔軟に進化させていく。このアプローチでは、要求の全てを最初から固定するのではなく、重要度の高い要求から順にMVPに盛り込み、それ以外の要求は将来のリリースに回す（詳細化を後回しにする）という段階的な要求定義を行う。

そのため要求工学プロセスにおける要求獲得・分析にも影響を与え、ステークホルダーとともに「どの要求をMVPに含めるか」を検討し取捨選択する段階が発生する。リーンスタートアップでのフィードバック駆動型の要求検証は、特に市場ニーズが不確実な新製品開発やスタートアップ企業のプロジェクトで有効であり、要求の誤りを早期に発見して軌道修正することで無駄な開発を最小化できる点が大きなメリットである。

なお、「リーン(Lean)」とは言えども決して行き当たりばったりに開発することを意味せず、継続的にビジョンをテストするための明確なプロセスを設けることが重要であるとされる。適切な指標(アクショナブルなメトリクス)を設定し、学習の成果（検証済みの知見）を開発の指針となる要求へ反映していくことで、要求工学のプロセスとリーンスタートアップ手法を組み合わせて活用することが可能である。

参考:

SysML

SysML (Systems Modeling Language) とは、OMG (Object Management Group) が定義したシステムエンジニアリング向けの汎用モデリング言語であり、複雑なシステムの仕様策定、分析、設計、検証に利用される。UML（統一モデリング言語）をベースに拡張した言語で、ハードウェア・ソフトウェア・人間・プロセスなどが絡む大規模システムを記述・可視化するためのシンプルかつ強力な表現要素を提供する。

その中でも要求工学に関連が深いのが要求モデリング機能である。SysMLには「要求 (Requirement)」という要素が定義されており、これを用いてシステム要件を階層構造でモデル化したり、要件間の依存関係を表現したりすることができる。さらに、SysMLでは要件と他のモデル要素を関連付けるためのトレーサビリティ機能が備わっており、例えば「satisfy（充足）」関係を使って「特定の要件を満たす設計要素」を結び付けたり、「verify（検証）」関係を使って「特定の要件を検証するテストケース」を関連付けたりすることが可能である。これにより、個々の要求がどの設計によって実現され、どのテストで検証されるかを一元的に管理できるため、要求変更時の影響分析や要件妥当性の確認を容易にする。

SysMLによる要求モデリングは、要求工学プロセスの中では主に要求仕様化および 要求管理（トレーサビリティと変更管理） の局面で有効に機能する。テキストベースの要求仕様書だけでは把握しづらい複雑な要求の構造も、SysMLの要求図(Requirement Diagram)を用いて階層的に整理することで、上位要求と下位要求の対応関係や、機能要件・非機能要件といった種別ごとの分類を明確にできる。

また、ユースケース図やアクティビティ図など他のSysML/UML図と組み合わせて要求をモデル化することで、要求から設計への一貫したトレーサビリティを確立し、要件漏れや矛盾の検出に役立てることが可能である。例えば、ある機能要求に対してユースケース図上でシナリオを具体化し、そのユースケースを満たすシステム構造をブロック図で表し、さらにテストケース図で検証方法を示すといった形で、要求から実装・テストまでを連携させて管理できる。SysML/MBSE（モデルベースシステムズエンジニアリング）の導入によって、従来のドキュメント駆動では困難だった要件と設計の一貫性確保や変更影響の即時把握が可能となり、結果的に開発期間の短縮や製品品質の向上につながるとの報告もある。特に安全性や信頼性が重視される領域（航空宇宙、自動車、医療機器など）の大規模プロジェクトでSysMLを用いた要求管理が広まりつつあり、要求工学の強力な実践手段の一つとなっている。

3. 各手法の適用場面と活用方法

各手法が要求工学プロセス上のどの場面で有効か、また実務で活用する際のポイントや事例について解説する。

デザイン思考

デザイン思考は主に要求獲得フェーズの初期段階で有効であり、ユーザの潜在ニーズや真の課題を引き出すのに適している。プロジェクト開始時に利害関係者（エンドユーザや顧客）を巻き込んだワークショップ形式で共感とアイデア創出を行うことで、従来見過ごされていた要求や革新的なソリューションの種を発見できる。特に、問題が漠然としている新製品開発や、イノベーション創出を目指す場面で威力を発揮する。

実務上のポイントとしては、デザイン思考で得られた洞察を後続の要求定義に反映することが重要である。例えば、ワークショップで描いた共感マップやペルソナ、プロトタイピングの結果生まれた改善案などを整理し、それらをユーザーストーリーや要求仕様書に落とし込むことで、開発チーム全体で共有可能な要求に昇華させる必要がある。

またデザイン思考のプロトタイピング手法は、仕様の詳細を詰め込みすぎずコアとなる機能に絞った試作を素早く作ってユーザ検証するアプローチであり、これはアジャイル開発の考え方とも非常に親和性が高い。そのため、デザイン思考を取り入れる際はアジャイルな反復開発サイクルと組み合わせ、プロトタイプによるフィードバックを次のイテレーションの要求改善に活かすと効果的である。実例として、IBMやSAPなどの大企業が全社的なイノベーション促進のためにデザイン思考をプロセスに組み込み、ユーザ中心の要求定義に成功したケースが報告されている (The Design Thinking Process: 5 Steps Complete Guide)。また、あるソフトウェア開発事例では要求工学にデザイン思考を融合し、マルチステークホルダー間のコラボレーションを改善して従来より斬新で的確な要求を定義できたとの研究結果もある (191023_IEEE_SOFTWARE_TEXT) (191023_IEEE_SOFTWARE_TEXT)。これらのことから、デザイン思考は要求工学の初期段階で真の要求を見極める強力な手段となりうるが、成果を正式な要求プロセスに接続するブリッジを構築することが実務適用上のカギとなる。

参考: システムズエンジニアリング連載vol.3 デザイン思考によるシステム開発と注意点 | 人とシステム | 株式会社NTTデータエンジニアリングシステムズ

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

ユーザーストーリーマッピングは要求分析・整理と要求管理の場面で威力を発揮する。特に要件をユーザ視点で整理し直したい時や、開発チームとビジネス側の認識合わせを図りたい時に有効である。実務では、プロダクトオーナーや開発チーム、UX担当者など関係者全員が集まりストーリーマッピングのワークショップを行うのが一般的だ。これにより各自がユーザの体験シナリオを共有し、「森（全体像）と木（個々の要求）の両方」を把握できる。ポイントは、単にユーザーストーリーを並べるだけでなく全員の議論を通じて共通理解を深めることにある。実際、「ユーザーストーリーマッピングの目的はプロセスそのものよりチームの認識を合わせることにある」とも指摘されており、ワークショップ中は各メンバーの意見を引き出しチーム全体でストーリーの優先度や範囲に合意することが重要である。

また、この手法はプロダクトバックログの可視化にも有用であり、リリース計画を立てる際にはストーリーマップ上にMVPや各リリースの「境界線」を引いて、どの機能を最初にリリースしどれを後回しにするかを合意形成するのに役立つ。これによって要求の優先順位付けが明確になり、リーンスタートアップ的なMVP戦略（まず価値の高い部分だけ実装して市場テスト）とも整合性を持った計画が立てられる。実例として、Twitter社のモバイルアプリ開発チームではユーザーストーリーマッピングを実施した結果、ログイン手順に関する新たな要求改善策が見出され、初回起動時にユーザがすぐタイムラインを閲覧できるように設計を変更するといった方向転換が行われた。

このようにストーリーマッピングは、要求の抜け漏れを防ぎつつユーザ価値に焦点を当てて要求を取捨選択する実践的手法として、多くのアジャイルチームで活用されている。導入のポイントは、手軽なツール（付箋やオンラインツール）を活用しつつ定期的にマップを更新して現在の要求に即した状態を保つこと、そしてマップをチームの生きたドキュメント（情報ラジエータ）として扱う文化を育てることである。これにより、チームは要求の全体像と進捗を常に共有し、変化に俊敏に対応できるようになる。

リーンスタートアップ

リーンスタートアップは要求の妥当性検証とイテレーションによる要求進化の場面で特に効果を発揮する。新規製品やサービスの立ち上げ期で市場ニーズの不確実性が高い場合、あるいは大胆な仮説に基づくプロジェクトでリスクを低減しながら要件を絞り込みたい場合に適している。

実務に適用する際のポイントは、まず検証すべき仮説を明確にすることである（例：「この機能はユーザの課題を解決し喜ばれるか？」など）。その上で、その仮説を最も手軽に試せるMVPを定義し実装する。MVPに含める要求（機能）はチームとステークホルダーで合意し、残りの要求は後回しにする潔さが必要となる。MVPをリリースしたら素早く定量的なデータを収集して測定し、仮説が正しいかどうか判断する。ここで重要なのは、アクショナブルな指標を設定しておくことである（例：ユーザ登録転換率が目標X%以上なら仮説支持、下回れば見直し等）。結果が良ければそのまま次の機能追加へと要求を展開し、期待した指標に達しなければ ピボット（方針転換） を検討する。

ピボットする際には、新たな仮説の下で要求そのものを大きく変更・追加することも辞さない。リーンスタートアップを成功させる鍵は、このフィードバックループをできるだけ短期間で回すことである。例えばあるスタートアップ企業では、数ヶ月かけてフル機能製品を作り込む代わりに数週間でシンプルなプロトタイプを出しユーザの反応を見たところ、当初想定と異なるニーズが判明したため方向転換し、その後の開発資源を無駄にせずに済んだという。このように、リーンスタートアップの実践によって早い失敗からの学習が可能となり、結果として最終的に市場に適合した要求セットを得ることができる。

大企業でもこの手法を取り入れる動きがあり、GE社では「FastWorks」というプログラム名でリーンスタートアップ手法を社内プロジェクトに適用し、新製品開発のスピードと成功率を高めた事例があると報告されている。実務で導入する際は、小さな実験プロジェクトから始めて成功体験を積み重ね、経営層やチームの理解を得ながら徐々に組織に浸透させていくと良いだろう。また、リーンスタートアップは要求工学の形式的プロセス（文書化やトレーサビリティ）を軽視しがちとも言われるため、規模が大きい組織では学習結果を簡潔にドキュメント化して共有する仕組みを用意するなど、従来の要求管理プロセスとのバランスを取ることもポイントである。

SysML

SysMLは要求の形式的な仕様化と追跡管理を必要とする場面で有効である。特に複数のサブシステムや分野（機械・電気・ソフトウェア・運用など）にまたがる大規模かつ複雑なプロジェクトでは、要求をモデルで一元管理することで整合性を保ちやすくなる。

実務においてSysMLを適用する際の第一歩は、プロジェクトの重要な要求を洗い出してSysML上に要求モデルを構築することである。要求IDや階層構造、要求間の依存関係（例えば「派生要求」「関連要求」）をモデルで表現し、要求ごとに優先度やバージョンなどの属性を付与して管理する。また、要求と他のモデル要素（ブロック、アクティビティ、テストケース等）との関連付けを行い、要求トレーサビリティを確立する。これにより、ある要求に変更が生じた際に関連する設計要素やテストへ自動で影響範囲を追跡できるようになる。

実務上の留意点としては、モデルの粒度を適切に保つことが挙げられる。あらゆる要求を過度に詳細なモデルで記述しようとすると工数が膨大になるため、プロジェクトの重要領域（安全性に関わる部分など）に絞って詳細にモデリングし、その他は要点のみモデル化する「イタレーション的詳細化」を行うのが現実的である。またチームにSysMLのトレーニングを実施し、関係者がモデルを正しく読み書きできるようにすることも不可欠だ。

SysMLの効果的な活用例として、ある自動車メーカーでは車両開発にSysMLベースのMBSEを導入し、要求から機能設計・テストまでのデジタルスレッドを構築した結果、部門間の認識齟齬を削減し開発サイクル短縮と不具合低減に成功したという報告がある。さらに、防衛産業の大型プロジェクトではSysMLモデル上で要求レビュープロセスを行い、テキスト文章では見逃されていた矛盾を早期に検出できた例もある。このようにSysMLは要求の厳密さとトレーサビリティが求められるプロジェクトで力を発揮するが、小規模で変化の激しいアジャイル開発にはオーバーヘッドとなり得るため、プロジェクトの性質に応じて適用範囲を見極めることが重要である。

参考: (Requirements in Model-Based Systems Engineering (MBSE))

4. 要求工学プロセスと各手法の対応表

下表に、要求工学の各プロセスに対する各手法の適用度をまとめる（〇＝適用可能/有効、△＝部分的に適用可、×＝適用困難）。

表: 要求工学プロセスと各手法の適用度

要求工学プロセス	デザイン思考	ユーザーストーリーマッピング	リーンスタートアップ	SysML
要求獲得	〇	△	△	×
要求分析	〇	〇	△	〇
要求仕様化	×	△	×	〇
要求検証	〇	△	〇	△
要求管理	×	〇	△	〇

（デザイン思考は要求獲得や要求の妥当性確認に強みを持つが、正式な仕様化や変更管理には向かない。ユーザーストーリーマッピングは要求分析・整理、およびバックログ管理に有効。リーンスタートアップは要求仮説の検証サイクルに特化しており、要求の変化適応に寄与するがドキュメント化は不得手。SysMLは要求の形式的な定義と追跡に適するが、初期の要求創出やユーザ検証には直接貢献しにくい。）

5. 総括と推奨活用法

新製品・サービス開発においては、以上のような 要求工学手法と個別手法（デザイン思考・ユーザーストーリーマッピング・リーンスタートアップ・SysML） を組み合わせて用いることで、各手法の長所を活かし短所を補完し合うことが可能である。例えば、まずプロジェクトの初期フェーズでデザイン思考を用いてユーザの真の要求を発見・定義し（要求獲得と問題定義に寄与）、次にその仮説上の要求をリーンスタートアップのMVPによって市場で検証する（要求の妥当性検証）、得られた知見を基にユーザーストーリーマッピングでバックログを整理しつつ開発計画と要求の優先順位を明確化する（要求分析と管理）、そして複雑な要件や安全規制に関わる部分はSysMLで形式的にモデル化し要求と設計・テストをトレーサブルに紐付けて管理する（要求仕様化と追跡）――といった流れである。それぞれの手法は要求工学プロセスの異なる局面を担っており、このように段階的・補完的に組み合わせることで要求開発全体の品質と効率を高めることができる。

実務で導入する際のポイントとしては、自社の開発文化やプロジェクト特性に合わせて適用範囲をカスタマイズすることが重要である。例えば、小規模でスピード重視のプロジェクトではSysMLによる重厚なモデリングは省略し、デザイン思考→ユーザーストーリーマッピング→リーンスタートアップのサイクルを短期間で繰り返す方が効果的だろう。一方、航空宇宙や医療など高い安全性が要求されるドメインでは、初期にデザイン思考でユーザニーズを掘り下げた後、要求をSysMLで厳密に定義・検証しつつ進め、ユーザーストーリーマップで開発計画を可視化し、必要に応じてリーンスタートアップ的手法で一部機能を段階リリースで評価する、といった組み合わせが考えられる。いずれにせよ組織への定着には関係者の理解と協力が不可欠であり、小さな成功事例の積み重ねやトレーニングの実施、専門ファシリテータの育成などを通じて徐々に適用範囲を広げていくと良い。要求工学の原則に各種手法を柔軟に取り入れることで、ユーザ価値に焦点を当てた迅速かつ確実な要求開発プロセスを実現し、新製品・サービスの競争力向上につなげることができるだろう。

要求工学はステークホルダーのニーズを正しく製品に反映させるためのプロセスであり、その成功は適切な手法の活用にかかっている。以上の分析から、デザイン思考・ユーザーストーリーマッピング・リーンスタートアップ・SysMLといった手法を要求工学の各段階で効果的に活用し組み合わせることが、新製品・サービス開発における要求定義の品質を飛躍的に高め、プロジェクトの成功確率を向上させると結論付けられる。