背景

前職の大規模エンタープライズ案件でのマルチステークホルダー環境下で、
アーキテクチャを考えるというかなり難易度の高い案件にいたおかげで、
今回のステークホルダーマッピングの重要性を実感することができた。

※　引用元：システムアーキテクチャ構築の原理より

上図のように、アーキテクチャは前段階の要求・要件に依存しており、
その要求の関係性を可視化するために、ステークホルダーマップは超便利である。

上図のようにステークホルダーマップは、プロジェクトや組織が影響を与えたり、
影響を受けたりする関係者（ステークホルダー）を整理・可視化するために行うものである。

このステークホルダーの考慮漏れや暗黙化が、後のアーキテクチャに対して、
重大なダメージを与えてしまうことは、アーキテクトをやられてる方なら非常に頷くことであろう。

また、ステークホルダーマッピングと、それぞれの抱える要求の因果関係を可視化できていないことで、アーキテクチャ上で重要な品質特性などが何なのか？　まずわからなくなってしまう。
しかもステークホルダー同士の関係性は、当然固定的ではなく動的に変化するものである。
そのため、可視化せずにどうやってその運用すんのって話である。

ステークホルダーマッピングのメリット

全体最適視点で考えやすい

マップを見ながらの対話ありきではあるものの、
自分たちの活動にはどのような人や組織が関与し、影響を与えているのか？
それをステークホルダーマップと要求分析ツリーの両方を見比べることで考察しやすい。
どの要求を実現したら、全体の要求が実現できそうかを考察しやすくなる。

重要ステークホルダーの特定がしやすい

プロジェクトに影響を与えるステークホルダーを特定することができる

上記で全体の要求が実現できそうな根本の要求を特定したら、
その要求の持ち主であるステークホルダーが最重要なステークホルダーであるといえる。
そして、重要なステークホルダーを早い段階でプロジェクトに関与させ、協力を得ることでプロジェクト推進に勢いをつけられる。

リスクの事前予測がしやすい

脅威モデリングとのセットで考えることにはなるものの、
あるステークホルダーにとっての懸念事項が発生した際に、
他のステークホルダーに対してどのようなマイナスの影響を与えうるのか？の事前予測
をしやすい。それによって、ステークホルダーに向けて効果的に情報共有し、
不測の事態が起きた際にも前向きな意思決定につなげやすくなる。

主張 -巻き込むステークホルダーは設計するもの-

まず私が言いたいことは、

ステークホルダーマッピングは、アーキテクチャを考察するにあたって、
必ず描いた方がいい。
最初は仮説的に因果関係を定義し、必ず検証すること。
そして時間経過や外部環境変化に伴うそのモデルの変化を追うこと。

アーキテクトがステークホルダーマネジメントを行った方が、極力いいと感じている。
でないと、アーキテクチャを考える者が、今回のシステムにおいて、
重要な品質特性は何なのか？ということを不明な状態で、好き勝手なアーキテクチャを考えてしまい、それは結果的にステークホルダーたちにとって使われないシステムを作り出すことにも繋がってしまう。

絶対にダメなアンチパターン

最初から巻き込むステークホルダーを何となくでデザインすること。
これマジでやめてほしいと感じる、アンチパターンです。
下手したらせっかくお金払って巻き込んだステークホルダーが自分たちのプロジェクトの足を引っ張る存在になりかねません。

無駄なコストをドブに捨てることなく、目的を最小限のコストで実現しやすくするためには、必要なステークホルダーをデザインすることから始めることが必要不可欠と感じます。

ウォーターフォールでの進め方概要

ウォーターフォールまたは、反復型のプロセスで行う状況下では、
はっきり言ってこのステークホルダーマッピングを行うだけではだめで、
TOC(制約理論)の現状問題ツリーなどと組み合わせて考えましょう。

どちらかだけでは、正直威力がだいぶ低下します。
両方の図を見比べて、どのステークホルダーの要求に選択集中すれば、
全体の要求が満たしやすくなるのか？　を考えることが、
ウォーターフォール型のプロセスでは重要になってきます。

この詳細な手順については、以下の記事で別途記述します。

アジャイルな進め方概要

不確実性が高く、最初から巻き込むべきステークホルダーが見えない時があります。
DX系の案件とかでは特にそういったことが多く起こりえると感じています。
プロジェクト途中から「実はこんな人がいました」的な暗黙知を言われ、
再度一番最初の前提に戻るなんてこと、経験した方は少なくないはず。

その場合には、今把握できるステークホルダーのみにしましょう。
「あの人たちもこの人たちも」なんてやってたら、いつまでも前に進めませんし、
筆者の経験上にはなってしまいますが、そうやって膨れ上がったステークホルダーのうち、
半分くらいは次のプロジェクトが始動した時には、「あなた達は何処(いずこ)へ」状態です。

影響力と関心の強さグラフ

ステークホルダーの重要性を定性評価するのに、よく以下の２軸評価を用いるのが有名だ。

図では４つの証言に大きく分類しているが、状況に応じてより細かく分けてもいい。
なぜこのグラフを描くのかというと、たとえば以下の図において

ステークホルダーAにとっての要求Xが実現すると、ステークホルダーBの要求Yが実現する
という関係性が成立するとする。

その際に、その因果関係の線が時間経過に伴い変化する可能性がある。
もしもステークホルダーAがグラフのオレンジ領域【関心も影響度も高い】に位置している際には、要求Xが実現する⇒要求Yが実現する　という因果関係が成立するとしても、
外部環境や時間経過などによって、もしもステークホルダーAがグラフのブルー領域【関心も影響度も低い】に変化してしまった場合には、先程の因果関係の線が結べなくなる。

つまり、要求Xが実現しても、要求Yが実現しないという関係性になってしまい、
因果関係が破綻してしまうのだ。
それはすなわち、別の要求を満たさなくてはならないということを意味する。

それを定性的に観測できるようにするために、この２軸グラフを用いて、
定期的に対象のステークホルダーがどこにプロットされるのかを可視化し、
要求同士の因果関係の透明性を担保するのだ。

注意

もちろん因果関係モデルである要求分析ツリーを定義しただけではだめで、
あくまでそれは仮説にすぎないから、因果関係が本当に成立するのかを検証しないとダメ。

たとえば、超簡単なモデルでいうと、
ステークホルダーAにとっての「素早く移動したい」という要求を実現すると、
ステークホルダーBにとっての「業務コストを節約したい」という要求ができる　という
因果関係モデルを考えた場合、
素早く移動というものを見れば、移動速度というメトリクスを想定でき、
業務コストを節約というものを見れば、業務コストというメトリクスを想定できる。
あとは、移動速度を増減させた際に、業務コストがそれに対応して減増するのか？を
データで分析すればいい。

ステークホルダーのデザイン方法

使うものは主に匠メソッドになります。
これの価値デザインとビジョンモデリングの手法を組み合わせて、最上位のビジョンをまずは定義します。
これがまずは組織にとっての揺るがない北極星を定義することになり、
その座標を設定、つまりビジョンの地点を目標(エンタープライズゴール)として定義することによって、方針が定義可能となり、道に迷った際のコンパスになってくれます。

特化のステークホルダーに関しては以下のような手順で考えてみましょう。

特化のステークホルダー

上記で書いたエンタープライズビジョンとそのゴールをもとに
トップダウンでステークホルダーを考えてみましょう。

気を付けたいのが、先に「こんな人たちに価値を届けたい」という願望がある場合です。

その場合には、そのターゲットのセグメントAに価値を届けることで自分たちがどうなりたいのか？を下図のようにボトムアップ式にデザインしていきましょう。
これがまさにビジョンモデリングです。

ここで大事なことは、

「誰に価値を届けるのか？」というのは、１つの手段に過ぎない

ということです。

なぜなら、エンドユーザーにとっての価値を実現することを目的とした場合、
そのビジネスは常に他人軸となってしまい、自分たちの軸を見失ったビジネスになります。

これはなにも、ユーザーの声を無視しろと言っているわけではないです。
ユーザーにとっての目的の方向性と、自分たち提供者側の方向性が一緒であること。
これの重なりが大きいほど、より少ない労力でユーザーの価値を実現できることに繋がるからです。

それだけでなく、自分たちの軸というものがないと、ユーザーからの声をただ実現するだけという外発的動機によって、エンゲージメントにまでダメージを及ぼしかねないです。

そのため、ビジョンとゴールが決まっておらず、
どんな人々に価値を届けたいという手段が先行している場合には、
まずは以下のビジョンモデリングによって、ビジョンとゴールを定義することから始める
ことを推奨します。

最上位目的のビジョンを定義したら、今度は他の選択肢を探るために

ビジョンからトップダウンでエンタープライズゴール(目標)を設定し

その目標を実現するためのビジネスケイパビリティを定義する

そのケイパビリティを求めているセグメントBをマーケティング目線で明らかにし
ケイパビリティbを実現するサービスyを定義する

テンプレートステークホルダー

お決まりのステークホルダー、たとえばシステムを使う場合には、
開発者や運用者といったステークホルダーが必ずいるために、
それらの人々は予めテンプレートステークホルダーとして、別で定義しておきましょう。
そのテンプレートステークホルダーに関しては、関心のある情報などは必要最低限のテンプレートな指標だけを監視しておけばよく、必要に応じて増やしていけばいい。

(ここでもYAGNIを意識したメトリクス設計)

補足 -設計原則をステークホルダーマッピングに取り入れる-

ウォーターフォールでは、最初から抜けもれなくステークホルダーを洗い出すことが
めちゃくちゃ重要ですが、
アジャイルで進める際には、既存の設計原則、
たとえばKISSやYAGNIなどをステークホルダーマッピングに取り入れてみると、
状況によってはかなり吉に働きます！

ちなみにこの考え方は、誰に教わったとかでもなく、
私が勝手に独断と偏見で編み出したものなので、効果は保証しません。

KISS×ステークホルダーマッピング

ステークホルダーの関係図も、シンプルであった方が、
「この価値を実現することが一番目的を最小限のコストで実現できるね」という

シンプルな構造であるがゆえに根本問題部分を見つけやすい

ということ。

そのため、ステークホルダーマッピングのモデル図が複雑になってきたら、
構造化して見やすくしてあげましょう。

そうすることによって、どの部分に集中した新たな機能追加や仕様変更をしたらよいのか？
最小限の要件のみを追加して考えればよいアシストにもなりますし、
システム内のどの部分に変更や影響を加えれば、その要件を実現できるのか？
といった、嬉しい要素とかかるコストなどを定性的に比較しやすくもなります。

ステークホルダー種別が少ないうちはいいですが、マルチステークホルダー下において、
構造化とかしてシンプルさをキープしていないと、複雑なままのモデル図にしておくとあっという間に大変なことになります。
それこそ、その後にどんだけ頑張ってDDDとか実践しても徒労に終わることが予想できます。

名前重要×ステークホルダーマッピング

これは説明するまでもないでしょう！
プログラミングでも重要な名前設計、これをステークホルダーにも適用してください。
じゃあどういうようにしたらいいのかというと、
そのステークホルダーにとっての重要な価値、つまり欲しい情報やらを類推できる名前に
ステークホルダーの名称を付けるのです。
そして、ユビキタス言語のようにステークホルダーの名称は揃えましょう！

開発者たちの中で【ユーザー】と呼んでいても、
ビジネスサイドでは【ファンクラブ会員】とかって呼んでいたら、
結果的に後続のフェーズのドメインモデルとかにまでダメージが波紋する可能性大です。

また、ステークホルダーの名称が適当だと、
その者たちがどのようなプロセスや情報を価値と感じるであろうか？という
仮説の精度も一気に下がりかねません。
最初からよい名前を付けろとは言わないですが、意図のわかりやすい

【その者たちが抱えている価値や要求を類推しやすい】ような名前

を意識しましょう。
一度定義しただけでは、なかなかいい名前は付けられないので、
定期的に洗練するというスタンスでいましょう。

YAGNI×ステークホルダーマッピング

これは特にアジャイルプロセスで重要になってくる考え方です。
何が言いたいかというと、

その「こんなステークホルダーも必要かも」という何となくで考えた
利害関係者は結局必要にならない

ということ。
不確実性の高い案件では、上記でも書いたように
次のプロジェクトが始動した時には「あなた達は何処(いずこ)へ」状態なんてざらです。

これはそのステークホルダーにとっての価値が実現されていないとかで
モチベーションを失う離れるケースもあれば、組織の政治的な理由で離れていくケースなど色々あります。

よって、本当に必要になったらたとえば
「そのプロダクトにどうしても協力したい」というステークホルダーが出現する。
「どうしてもこの人たちに協力してほしい」というステークホルダーがいる。
という状況にならない限りは、ステークホルダーとしてカウントしない方がベター。

そのためにも、私は上図のような図を可視化するなり、
匠メソッドのフレームワークで可視化するなりして、必要な利害関係者を考えると
不要な利害関係者を巻き込むというリスクを下げられます。

SLAP×ステークホルダーマッピング

これは上記で記載したKISSでの構造のシンプルさと関連が強いです。
マルチステークホルダー環境下のように、そのステークホルダーの粒度感を揃えておかないと、ステークホルダーマッピングのモデル図における因果関係が考察しにくくなります。

事例①

【東京都のITエンジニア】【大阪のITエンジニア】みたいに
粒度感がぱっと見、同じくらいでしょうと思えるものに関してはいいのですが、
【東京都のITエンジニア】【大阪のセキュリティエンジニア】のように、
明らかに粒度感が異なるものを同じレイヤーとして考えてはならないってことです。

前提として、上記ではITエンジニアという集合の中に
セキュリティエンジニアがすっぽり入っているというベン図構造
というていで記載しました。

事例②

他の例でいうと、冒頭のステークホルダーマップを事例とすると、
【マンション住人】というステークホルダーのグループの中に、
【買い物依頼者】【買い物代行者】というサブステークホルダーがいます。

この時に、【ショッピングモール】というステークホルダーと
サブステークホルダーである【買い物依頼者】や【買い物代行者】を同じ粒度で
扱ってしまうと、ステークホルダースマップの保守が面倒なことになってしまうので、
粒度を揃えましょうというのが、このSLAP原則を適用したものです。

まとめ

アーキテクチャを決定するにあたって、前提となる要求が大事であり、
その要求の出どころはステークホルダーが握っている。

そのステークホルダーの握っている価値や要求の関係性を把握することなく、
アーキテクチャを考えてしまうと、ある特定のステークホルダーの要求だけを実現し、
それに相反する要求を持ったステークホルダーの思いは実現されない
といったトラブルにも繋がってしまう。

それを防ぐためにも、ステークホルダーマップを描くことはとても重要です。
またその際に、設計原則の思想を取り入れ、今後のステークホルダーマップを保守しやすくしておきましょう。

キーワード

匠の要求分析ツリー　ステークホルダーマッピング
TOCツリー　現状問題ツリー　未来ツリー
データ分析で因果関係を検証　バリューメトリクス