最近サイトを眺めていて、たまたま、かつ、恥ずかしながら初めてサービスブループリントという要件定義の一手法を知りました。
要件定義の一歩手前の方法として紹介されている記事もありますが、ここでは乱暴ながら要件定義の手法の中に含めさせてください。
ちょっと調べてみると私がよく拝見させていただいているグロースエクスパートナーズ株式会社の鈴木雄介さんのブログでも紹介されていました。

いきなり横道に逸れますが、鈴木さんは2014年に以下の記事でソニックガーデンの倉貫さんと対談しており、その一言一言が非常に当時の私に腹落ちしたことを覚えています。
アーキテクトを目指す方は鈴木さんのブログやTwitterをチェックして損はないと思います。

本題に戻りまして。
一見、サービスブループリントはカスタマージャーニーマップやユーザーストーリーマッピングに似ています（カスタマージャーニーマップはマーケティングの分析手法なので、さすがに要件定義に含めるのは厳しいですね。。）

ただ、カスタマージャーニーマップやユーザーストーリーマッピングはユーザー中心の図であるのに対し、サービスブループリントはシステムを中心に記述すると同時に、フロントの各画面や管理画面等を明記し、それぞれの画面でどういった処理を行うかも記載できます。

ユーザーストーリーマッピングはざっくり流れを把握するのによさそうですが、複数のユーザー（ロール）の役割・作業や、どういった画面が必要になるかといったように更に詳しく深堀しようとするとちょっと厳しいのかなと思っています。
まあ、目的がそもそも要件定義というよりは要求の重要度、優先順位を決めるものであるので当然と言えば当然ですが。。

私が個人的に好きな手法はRDRA（ラドラ）になりまして、神崎 善司さんが提唱している要件分析フレームワークです。

私が個人的にRDRAを好きなところは

• コンテキスト図で俯瞰ができる

• 画面やシーケンスといった設計寄りの内容に無理なくシフト・答え合わせができる

の２点です。

特にコンテキスト図（システムコンテキストとも言います）は人型の「アクター」と、楕円の「システム」（開発対象のシステムだけでなく、連携対象やアクターが利用している他のシステムも含みます）を一通り書き出し、それぞれの関連を線で結んで。。といった形で記述する非常にシンプルな図なのですが、最初にシステムの概要、AsIs、ToBeを把握するには手軽でわかりやすい図だと思います。
RDRAは画面・帳票モデルや状態モデルといった各モデルの作成・検討を繰り返し、それぞれのモデル間で矛盾が無いことを確認することで漏れの無い要件定義が可能になります。

ただ、どうしてもモデルが多くなり、ボリュームが大きくなるとそれに比例してメンテナンスが難しくなるため、最近のRDRAの勉強会では無理にモデルを書こうとせず、Excelでよりわかりやすく、簡単に俯瞰できるように記述する方法が紹介されていました。
私の会社でも大きなプロジェクトでない限りはRDRAを教科書通り実施することはありません。
しかしながら、キックオフにあたってコンテキスト図を使用してAsIs、ToBeを把握し、お客様と認識合わせを行うということはプロジェクト規模に関係なく行っています。

パッと見、サービスブループリントはユーザーストーリーマッピングと同じようなものかとあまりちゃんと見ていなかったのですが、書き方によっては画面や管理画面側の処理も盛り込むことができ、更にはユーザーや管理画面を操作する側の人間も記載できるということで要件定義に必要な内容をかなり網羅できていると思います。
ある程度ユースケースごとに区切れば図自体が膨らんでしまうのも避けられそうです。
１つの図の中にまとまっていることでメンテナンスもしやすそうですし、システムの流れや必要となる処理・画面を1つの図で把握するには非常によさそうです。
機会を見つけて実際の業務で試してみたいと思います。