背景と前提
先日、匠メソッド関連のイベントに参加してきて新たな発見があったのでここに残します。
下図は、匠で大事とされてる３つの思考の要素です。
知は、ロジカルシンキングを駆使して自社戦略という抽象的なものから、
【誰が】【どんな具体的活動】をどのような【手段】で実現するのか？
という具体的な手段まで落とし込む領域。
情は、そのサービスを利用する他者が求めてる価値は何か？という他人軸の立場で、
感性を駆使して実現手段まで落とし込む領域であり、
その人がサービスを利用した後にどのような軌跡を描いて自分の変化、
たとえば己の成長とか、お客様精神から脱却して組織との一体感とかを体現していくとかっていう
コトの品質が情景として思い浮かぶようなストーリー(価値記述)として具体に落とし込む領域。
意(意志)は、自分たちがプロダクトなりを通じて、
未来の社会や未来のステークホルダー(フィーチャーホルダー)に対して、どのようなインパクトを与えたいのか？
またはするべきだという強い信念があるのかを定義する領域である。
わたしはこの知情意の図、下図のコンポーネント原則の図と似ているので、
勝手に３つは互いにトレードオフ関係にあるのかなって勘違いしてましたが、全然違いました。
３つはトレードオフ関係にあるのではなく、すべてを集約して価値の創造と向き合わなくてはなりません。
どれか１つを極めても本質的価値の創造にはならないんです。
それぞれの価値モデルの概要
価値分析モデル
まずこの価値分析モデルは、事前にステークホルダーモデルでフィーチャーホルダーも含めて、
ビジネスを成功させるために必要となるステークホルダーを抽出します。
このフィーチャーホルダーっていうのには、
これから生まれてくる人とか、直近ですぐにステークホルダーになるわけではないけど、
将来的にステークホルダーになり得る人っていうのも含まれています。
最初は仮説になりますが、以下のようなことをして検証することもできます。
たとえば最近では、サービスを受けた人の表情の解析結果などを通じて満足度の検証をする仕掛けを設けているものもあります。
ここからわたしが予想しているのは、すぐに価値を感じなくても、
①自分たちのサービスに触れてもらって、なにか新しい行動を起こすきっかけをつくる
②その人が次にどんな今まで取らなかった行動をとるのか？モニタリング
③最終的に「あの時のサービスがきっかけで私はこれだけ変われたんだ！」ていうように
「あの時のあれがあったから、こうなれたんだ」っていう視点をもって予測するっていう行動も大切になると予測しています。
ここでは、各ステークホルダーが抱えている悩みなどが、
そのプラダクトサービスに触れることでどのように＋の感情に変わるのか？
てことをステークホルダーを主語とするコンパクトなストーリー(価値記述)で明らかにします。
さらにそれが我々プロダクト開発者の下心(これがCapabilityとなります)の
どれと因果関係が成り立つのか？までこのモデル図で明らかにします。
ステークホルダー目線で価値記述の体験をした結果、それはどのCapabilityに貢献するのか？
言ってしまえば、このモデルはサービス利用者が感じる未来価値つまり【コトの品質】を明らかにします。
他人軸で考えるのがメインのモデルとなっていまして、
このモデルはちょうど上記に記載した情の部分に対応しています。
価値デザインモデル
一方でこちらの価値デザインモデルは、
自分たちのプロダクト(製品、サービス等)の長期的ビジョンToBeに至るまでに
どのような軌跡を辿りたいのか？というものを
自分たちの内側からにじみ出る熱い想いが伝わるようなストーリーにして明らかにしていきます。
こちらのモデルは先ほどの価値分析モデルとは違って、自分軸の意思をモデルに投影させたものなってきます。
自分たちのプロダクトはこんな想いがあってどうなっていきたいのか？
ていう魂をプロダクトに入れ込み、それを視える化したものになっています。
言ってしまえば、このモデルは先の分析モデルとは違って、
自分たちが感じたいと思う未来価値【コトの品質】を明らかにします。
この価値デザインモデルは、上記の意に対応しています。
たとえば私の場合、これから生まれてくる未来のステークホルダーに対して
私たちが文明の発展の代償として生み出してきた炭素やメタンによる、
地球環境問題や社会問題という大きな負債を絶対にそのまま残して死にたくないってのがある。
そのうえでたとえ外部環境が変わろうとも、たとえ自分の仕事が明日無くなったとしても、
自分のビジョンを満たすような別の手段を探して対処できるように、
絶対に自分のビジョンを特定の手段・特定の環境に依存させないこと。
その思想を未来永劫語り継いでもらうことっていうのが自分のビジョンとしてある。
キャッチコピーは【人生クリーンアーキテクチャ】であり、
コンセプトとして
・【相互発展のために価値の双方向の交換】
・【多様性とはある規約に従ったもとで初めて生まれる】
・【トレードオフを意識し、リスクを取る勇気を持つ】 である。
こんな感じで、現状-未来のビジョンまでどんな道筋をたどるのか？という、
自分たちがどんな成長の軌跡を辿りたいのかっていう品質が情景として浮かぶようなものをここで定義します。
（個人的に思うのですがキャッチコピーが適当だと胸に響かないのは、
このようなモデルで自分たちがどうなっていきたいのか？
ていう長期的な目的がそこにない、思い描けていないと感じてしまうから、
なんとなくなワードをチョイスされたからなんだろうな～と思っています。）
方針の決定
ビジョンを支える形で３つの重複しないようなコンセプトを打ち出します。
後の要求分析ツリーで出す戦略層を支える活動などといった具体的アクションたちの妥当性は、
このコンセプトに則っているか？いないのか？を基準に判断します。
ちなみにこの価値デザインの後に価値分析モデルの価値記述に取り掛かる際には、
ここのコンセプトを出す段階である程度、コンセプトを下で支えるCapability要素の目星をつけておくのも手だったりします。
どちらを先に？
さて、価値分析モデルと価値デザインモデルの概要を記載したうえで、
匠に慣れるまでわたしは、このデザインモデルと分析モデルどっちから先に
やればいいんだろう？ と疑問に思っていました。
というのも、たとえば先に価値分析モデルから始めた場合、
そのあとに価値デザインモデルをやろうとすると、
どうしても他人軸の分析モデルにひっぱられた価値デザインモデルになりがちだからです。
これはいわば、
【価値デザインモデル】→【価値分析モデル】という依存関係になってしまってます。
同様にして、価値デザインモデルから開始した場合、
【価値デザインモデル】←【価値分析モデル】という依存関係になり、
まるで自分軸で決めたモデルに、他人は合わせろ！と言わんばかりの
主従関係になってしまっています。
小規模なコミュニティを望んでるとかならこれでもいいのかもしれないですが、
ビジネスってなるとこんな主従関係では破綻してしまいそう💦
そこで萩本さんが大切にされてる思想として、
「どっちから先に始めるのかは状況によって変わるけども、片方のモデルに引っ張られたものは創らないこと。」
というものがあります。
つまり、価値デザインモデルから創り始めた場合、
価値分析モデルを作成時には、頭をマッサラにしてモデルを作成するってことです。
なんでかっていうと、そもそも価値デザインと価値分析とでは、考えている軸が違うから。
自分軸も、他人軸もどっちも同じように重要。
どちらかに無理やり合わせるのではなくて、
下図のようにそれらが重なってる所を見つけようってことが重要です。
下記で示す知のモデルである要求分析ツリーの中で、
意のモデルの要素と情のモデルの要素を結合させて戦略要求を作成することになります。
ビジョン-コンセプト-Capability-業務戦術層-IT要求層という階層構造をなすので、
自分軸と他人軸が重なっていない＝価値分析モデルで価値記述とCapabilityに因果関係が成立しない
という場合、自分たちの打ち出した戦略を支える土台がない状態になります。
なので、そんな場合には以下のことが原因として挙げられます。
・自分たちの意思の視野の範囲が狭くて、情のモデルと紐づかなかった。
・情ばかりに流され何でもかんでも価値を届けようとしてるけど、その先に目的が特にない。
このような場合は、潔く意および情のモデルを改めて見直した方がいいでしょう。
アンチパターン
これは自分の過去のアンチパターンを例にしてお話しします。
自分は生まれてから今日に至るまでに相当の数のコミュニティを立ち上げ、
そして解散させてきました。
スポーツコミュニティ、勉強会コミュニティ、バンドサークル、ITのモデリングコミュニティなどなど。
数にしたら、それこそ20以上にはなっています。
相当わたしは自分でも認識しているほど頑固者であるため、
自分の納得いかないものに対しては容赦ない部分があります苦笑
そのため、最初の方では圧倒的に【自分軸モデル】←【他人軸モデル】
という主従関係のコミュニティを描いてしまっており、
最初は自分のスキルやぶっ飛んだ行動に人が集まってきますが、
徐々に反乱分子がこちらがもともと提示していた契約に対してクレームを言うことが
増えてきて→ その人たちが内部の人間たちをかっさらっていく形で辞めてく、
ということがたーーーくさんありました。
「そしてちょっと反省」となり、今度は他人の話にも耳を傾けようってなって、
他人軸モデルの方を大事にします。
すると今度は「俺すごい奴なんだぜ」的ないかにも怪しい奴が入ってきて、
最初の印象はいいものの、徐々に利己的でサイコパスな面を出してきて、
しまいにはリーダーの自分に罵詈雑言の数々。
メンバーの前で「こいつはこんなんだからダメなんすよ、みんなもそう思うだろ？」
的なことを言いだし、メンバーはそれを我関せずという目で見てるというww
こんな感じの自分軸と他人軸の優先を交互にやってきて、
何度もアンチパターンを繰り返してきた結果行きついた先として、
【どちらかを犠牲にしたモデルは、絶対に崩壊する】ということを身をもって学んだし理解できた。ということ。
自分の場合で言うと、あまりにも中長期的視点で物事を見てしまう癖があるので、
その状態で他人軸モデルとの接点を探そうとしても繋がらず、
絵に描いた餅状態になってしまいがちであった。
この不確実性の高い世の中では、通常の思考回路の持ち主は１年先の姿すら
思い描けずに不安を・不信を抱いてしまいがちなんだとか。
「だから半歩先、予測できるようなちょこっと先の姿を語ることが重要なんだ。」
とだれかが言っていました。
だから自分軸モデルをだいぶ詳細化したうえで、他人軸モデルと繋がる部分を探す。
これを知らずにやって来てなかったていう時期と、
あえてやって来てなかった時期とでは最終的に味方として残る人の質もだいぶ違う。
当然後者の方が、集まる人の質はめっちゃいい。
ここまでのまとめ
ここまでをおさらいします。
要は自分軸である意ばかりに比重の傾いたモデルでは、自分たちばかりが嬉しい思いするモデルとなってしまって下で支えてるステークホルダーたちの喜びが不十分になりがちで、
絵にかいた餅になってしまいやすい。
逆に他人軸である情になかり比重を置いたモデルでは、
ステークホルダーを喜ばせたその先に何を思い描くのか？てことがない。
目的がないモデルとなってしまい、これもこれで統制の取れない。
非常識なことを自由と履き違えた、民度の低いお客を寄せ付けがちになってしまうと予想される。
自分軸と他人軸の両方を重ねてみて、共通の領域が
そのプロダクトの本質的価値として実現手段まで詳細化していく。
その詳細化の際に、要求分析ツリーを作成する。
ここで求められるのが論理的思考力である。
製品開発前に検証する
よくやられがちなコストの無駄遣いとして、
まだプロダクトすらほとんどできていないのにも関わらず
「こんな目的を達せしたいのなら、こういうITシステムが必要だ」と
最初から手段を固定化したプロダクト設計をしがちな人がいるように感じる。
わたしの思想としては、無駄な開発はしたくないし、
極力製品をつくらずに、いかに最小限のコストと労力で目的を達成できるか？
ってことを重視していますので、いきなり創るってのはハッキリ言って邪道に感じる。
プロダクト設計すらままならない状態で、ITシステムの設計してるようなもんだからだ。
よって、プロダクトの要求分析ツリーを作成したら
ユーザーストーリーマッピングで時系列及び、
ユーザーの感情の移り変わりが分かるようなストーリーを作成し、
随時ステークホルダーにフィードバックをもらいながら検証することを徹底している。
ちょっとした工夫
理想としては、要求分析ツリーを作成してから、戦略層や業務戦術層など
各ビューごとに関心を持ったステークホルダーに対して、
ユーザーストーリーマッピングを作成して、どの要素が比重高めなのかっていう
同じ粒度の要素同士での優先順位付けをします。
たとえば戦略層に興味関心のあるステークホルダーていったら経営層の人々とか。
その人たちに対してあらかじめ
「こんな状況下において目的を果たすためには、どの戦略要素が優先されますか？」
て厳選させて、その横に紐づく業務戦術要素やIT要素のストーリーを
各ビューに対応するステークホルダーに見せてFBをもらって・・・てことをしてます。
こうすることによって、プロダクトの大枠の設計をしてから、
製品の開発は最小限の検証材料として開発するってすることで、
無駄な開発コストを抑えるのと
「えーーーーせっかく創ったのにーー」ていうマインドが働いてしまうことを抑えています。
ただし、時間が本当にない時には、
ユーザーストーリーマッピングと要求ツリー作成は同時進行で進めてしまってる時もあります。
そうすると要求ツリーには厳選した要素のツリーしか現れないです。
この方法のデメリットとしては、前提条件が変わった際、
他の比較できたはずの要素が代わりに優勢に立つ可能性があるのに
その要素を最初からいらないものとして枠から捨て去ってしまう可能性高いってことが挙げられます。
これからの研究
いま自分はリスクマネジメントが結構波が来ています。
匠では価値というプラスの感情を生み出す品質改善を扱ってきていますが、
これの大枠の考え方を用いて(詳細は異なるけど)、
「こんなことは避けたい」ていうマイナスの感情を生み出さないための
プロダクトの品質保証という視点での、品質保証モデルなるものを作成することで
アーキテクチャが最低限満たさなくてはならない品質を捉え、
それを満たす形でアーキテクチャスタイルを比較選定するっていう方法論の土台固めをしています。
リスクマネジメントはマイナスの感情を生み出さないため。
価値モデルは、それとは発想を変えて０から＋の感情を生み出すために
トップダウンで目的から考えて、改善活動を繰り返しながら
全ステークホルダーの結束力を高めていく。
そこに組織としての成長や、アーキテクチャの成長が紐づいてくると尚のことビジネスの成長にも繋がっていきという、好循環をもたらすと考えています。
キーワードは、【リスクマネジメント】【価値】【進化】！！
ただし、価値とリスクは関心が異なるので、モデル自体は完全にわける。
引用元
匠メソッド https://www.takumi-businessplace.co.jp/takumi-method/index.html
SE4BS https://se4bs.com/sites/introduction/