概要

ここでは、TOCの中で最も変えることが困難と言われている方針制約を
認知しやすいプロセスを改善することによってボトムアップに変えていくという思考プロセスについて書いていきます。
ただし長編になるので、今回はまずは価値観という抽象的な部分の更新について触れます。

※画像の引用元　Business Place

前提条件

以下の項目で当たり前のように匠Methodの思想を使っています。
価値記述？なにそれって思われる方は、ぜひ「匠Method」でYouTubeなどでググってみてください。慣れればサクサクできます。

また方針制約というTOC(制約理論)の方針制約というものにも触れています。
これはDXでは、絶対にマストな理論であるため、是非ともググってみてください。

また帰納法や演繹法というものは、要求定義などで使うと超威力を発揮します。
是非ともググってものにしてください。

問題と現実性

組織風土などの方針制約が、認知しやすいものであれば価値観から先に変えて、
トップダウンでプロセスである行動を変えるという方法もありです。
しかしながら、価値観というものは深い階層構造になっているものだし、
その階層がどの程度の深さなのか？認知が非常に難しいものです。

そのためにもっとも現実的なのは、DDDなどのモデリングとプロセス改善を通して
コンテキスト境界を継続的に変化させ続けること。
その人間が作り出す【概念】としての境界の位置が価値観を形成するし、
同時に価値観が概念としての境界の位置を作り出します。
【概念】であることに注目してくださいね。
なぜなら価値観が物理的なコンテキスト境界を形成することはあっても、物理的な部屋の仕切りとかが価値観を作り出すことはないので。

価値観の視える化

かといって価値観を認知しなくてもいいってわけではありません。
では、どのようにしてその価値観を可視化できるのでしょうか？
私なりの実験回数がまだ浅い仮説をご紹介します。
そのまえにまずは価値感と要求との関係性を理解しなくてはなりません。

価値と要求の関係性

要求を抽出することも割と大変ですが、このVUCAの時代では、
その要求すらも変化する速度が速くなっているように感じます。
そのメカニズムを下図を通して探索してみましょう。
(画像元：Business Place)

価値観が要求を定義し、その要求がビジネス要件として認知しやすい形を形成します。
つまり以下のようなこんな感じ。

この矢印の向きへ依存する形状になっています。
上に行けば行くほど、より抽象的で認知が難しいです。
下に行けば行くほど表層的であり、認知がしやすいという特性をはらんでいます。

出てくる要求は、常にこの価値観、何かしらのバイアスによって決まってくるのです。
そしてステークホルダーから出てくる要求を素早く吸い上げるだけでなく、
この価値観との一貫性を保たないと、永久にその場しのぎのビジネス要求と向き合い、
それをもとにビジネス要件を定義し、システム要件定義という環境の変化に、ひたすら翻弄されることになります。

価値観と要求の一貫性管理については後述で触れます。

DXでいわれているX(変革)は、方針制約である、この価値観であるバイアスを変えることにメスを入れているので、このもっとも深い所をあぶり出すまでがそもそも大変なわけです。

それが理由なのか、表層的な要件をひたすら変えることがDXだ！といっているプロジェクトは、基本的にほぼ効果が得られていません。
当たり前ですよね？　だって価値観のアップデートには向き合っていないんだから。

帰納法・演繹法で価値観の検証をしつづける

継続的にステークホルダーから出てくる要求を可視化し、
その要求から価値をボトムアップに帰納的にあぶり出すということをやらなくてはなりません。
その際に、わたしは匠Methodの価値分析と帰納法を組み合わせて使っています。

もう一度上図を見てください。
ある価値観を前提にして要求は形成されます。
人はそんな短期間で価値観が劇的に変わる生き物ではありません。
なので、短い期間内であれば、近似的に価値観は変化していない　とみることが可能です。

素早い仮説検証によって、現在の価値観を帰納法を使って仮説的にあぶり出したら、
今度はその価値観を前提にして、次の要求との関係性を見るのです。
丁度それはinterfaceである価値観をリスコフの置換原則を満たすような要求になれているか？
とチェックしていることに当たります。
もしもここで、新しい要求が前提である価値観を実現した姿でない場合には、
素早く仮定として置いた前提の価値観が今は間違っていると修正しましょう。

ちょうど具象なクラスで振る舞いを検証し、前提であるinterfaceを適切に修正するメカニズムと同じなので、こればかりは回数重ねて慣れるしかありません。

TOCとの掛け合わせでバイアスを除去

TOCでは、方針制約＝足かせとなっている価値観であるバイアスを除去し、
よい状態にしようという思考です。
これは非常に価値モデルと相性がいいので紹介します。

価値観の変化の状態モデル

価値観の状態変化を図式化すると以下のような感じです。
事前に価値デザインで明らかにしたToBeの価値観へと変化されるような力学を作用させる。

ToBeまでの道のりがものすごく遠いような一足飛びに行けないとか、
そういった状況では、小さくToBeをさらに細分化して、小さな変化を継続的に起こさせるのが最も現実的です。

実際にはこのインジェクションを注入したことで、別の副作用の起きる可能性が高いので、
それを事前に想定できるものは洗い出しておくのです。
そうすることで、ToBeまでの道のり中の脅威に対して事前に対策を立てておくことができます。

対立解消ツリーにおけるバイアスの除去

TOCにある5つの思考プロセスに、トレードオフ分析に向いている【対立解消ツリー】というものがあります。
主に要求同士がコンクリフト起こしているようなときに使います。

詳細は割愛しますが、ともに満たすことができない要素同士に対して、
その前提となっているバイアスを除去するようなインジェクションというものを注入することで、対立を解消するというものです。

私はこの際に、要求をあぶり出した後、その前提条件である価値観を帰納法を使って類推した後に、「恐らくこんな価値観を持たれていると考えれば今までの発言や行動が説明つく」
という現状AsIsの価値観を図で可視化し、ビジョンに向かうためのToBe価値観とのギャップを埋めるために、どんなインジェクションを与えたらいいのか？　と考えるようにしています。

価値観の変化の過程がエンゲージメントに繋がる

以下のエンタープライズアーキテクチャモデルの図を見てください。

ToBeとAsIsを並べてそのギャップを可視化し、
ギャップが少ない部分に関しては、そもそもやらないという選択と集中を行うために、
戦略を練るためによく使っている方はいると思います。

これと先程の価値観の状態変化のモデル図と、

価値観と要件の階層モデルを思い出してください。

AsIsの価値観が現在のビジネスアーキテクチャを構築している。
ToBeの価値観は成りたいビジネスアーキテクチャの姿である。
そしてそれが、ToBeのデータモデルや、ドメインモデル、品質文化などを作る土台となっている。

そこまでのロードマップを定義するのが、ちょうど匠メソッドで提唱されている、
価値デザインにおけるストーリーそのものである。

単なる思い付きでそのストーリーを描いてはならない。

もちろん自分たちがAsIsからToBeに向けてどんなロードマップを歩みたいと思っているのか？を描いたうえで、ToBeの価値観を可視化するという方法でもいい。
ただ、このようにして最終的にToBeの姿として、どんな価値観になっていたいのか？
を定義しないことには、たとえアジャイルでやろうと何しようと変革には至らない。

ストーリーであるロードマップを定義するメリット

こうやってロードマップを描くことによって、
利害関係者たちは「自分たちはどんな体験ができるのだろうか？」
というワクワクを演出したりすることにもつながるし、
それが目には視えないコトを定義し、一緒に利害関係者たちがロードマップを歩んでいく過程そのものがエンゲージメントを向上させ、それが可視化できるものとして組織のアーキテクチャが進化している。

逆にいうと、組織のアーキテクチャがどんなにかっこよくなろうとも、
利害関係者たちのエンゲージメントが高まらないようであれば、それはDXを実現できているとは言えない。

このロードマップを描く際に、TOCの移行ツリーの発想を取り入れておくと、
夢のあるビジョンに向かいつつも、現実を見られているロードマップを描くことができます。