概要

ロードマップに具体と抽象の考え方を適用することで、外部環境などの変化に強く、さらに一度定義した前提をどのレイヤーから変えなくてはいけないのか？を体系立てて理解するために、独自でプロジェクト中に設計したものである。
ビジョンが壮大であればあるほど、これを使った効果が大きくなると感じる。

最初はマクロなロードマップからトップダウンで問いを設定するが、
プロジェクトが進んでいくうちに新たな発見をする中で、
ボトムアップ式に　設定した前提を見直さないといけないフェーズが来る。

時には、現時点での技術力では到底目的地にたどり着けないという発見があるかもしれない。
その際に「ではどのようにして技術的制約を取っ払っていくか？」という技術戦略を設計する起点としても使える判断材料となる。

戦略ロードマップ

大きなビジョンがあって、そこまでいくつかのマクロな中継地点を経由しなくてはならない。それがマクロな粒度のロードマップ、戦略ロードマップである。

そして中継地点と次の地点までの間、これが１プロジェクトに相当する。

プロジェクトロードマップ

その１プロジェクトをさらに拡大したロードマップとして
ミクロな粒度のロードマップをプロジェクトロードマップと呼ぶことにする。

そのプロジェクトロードマップのプロットされた地点の１区間が丁度１スプリントに相当する。下図では、１スプリントを１週間で回すことを想定した図。

前提

事業戦略のロードマップのような【マクロなロードマップ】。
３か月といった１回のプロジェクト期間内という【ミクロなロードマップ】と呼ぶ。
実は大事なシステムの移行計画などもこれが定義されていないと意味を帯びてはこない。

用語の整理

要望・・・本当の願望のことであって、要求よりも抽象度の高いもの
要求・・・要望を実現するもの
要件・・・要求を具体化した誰もが同じものを考えるもっとも具体的なもの

演繹法
・・・置いた前提に当てはめて少し先の未来に起こる事象を予測する推論技術。
これによって未来に実際に起きた結果がその仮説と外れていたら置いた前提がそもそも間違っていたことを証明してくれる。
逆に実際に起きた結果が仮説とほぼ一緒であれば、置いた前提は一旦その時点では正しいと判断できる。

背景

これらにおいて自分の案件内で具体と抽象の思想を使って、
無駄な手戻りを発生させることなく、スプリントレビューで迅速に前提に戻ったり
「このまま自分達前に進んでいいんだっけ？」といった状況、
「次のプロジェクトではどんなものを論点とすべきか？」、
さらに短いミクロな期間で言えば「次のスプリントではどれを小論点とすべきか？」
を決めやすくするために、ロードマップにおいても具体と抽象の行き来を取り入れた。

主張

とりあえず手を動かすことを自分はアジャイルとは思っていない。
あくまでも北極星になるトップゴールは仮説ベースで定義した上で、
・そこからの逆算トップダウン思考と
・自分たちがどの方向に向かって進みたいのか？というボトムアップ
これらの折衷方式と道中に存在する制約条件を踏まえた上で、
要件定義の理論と同様の形式でプロダクトの移行計画を設計することが、今のプロジェクトから次のプロジェクトへの有機的つながりを生む。

なおこの記事では１つのプロダクトを成長させるロードマップとして内容を書いているが、この思考法は１つの組織全体がビジョンまで到達するまでの経営方針をデザインする際にも使える発想である。

そもそものビジョンは何なのか？

DXという名前だけがついていて、どこに向かいたいのか誰も不明なプロジェクトでは、往々にして自分たち組織が向かいたい目標の先にある夢の姿を思い描けていない。
思い描き、それを全員で共有していないからトップの目標も曖昧なものになりやすい傾向があると感じる。

抽象化スキルが非常に高い人であっても、いきなりビジョンが降ってくるということはそうそうない。
そこでまずそのビジョンを可視化するために必要な工程から解説する。

ビジョンモデリング

2022年にUMTPで開催されたイベントの中に非常に有効な手法が紹介されていたので、取り上げさせてもらうことにする。

ボトムアップを繰り返してビジョンを明らかにする

やることはシンプルである。
下図のように、「こんな機能がほしい」「誰誰に会いたい」
という仮初めの要件から　【そうすると何が実現できるの？】ということをボトムアップに抽出していく。

この際に気を付けたいのは、「時間的にそれは～～」とか「コスト的に～～」とかって制約を付けないことが大事である。
ここで変に制約を付けてしまうと、本当の願望が浮き彫りにならないからである。
それは結果的に間違った問題設定を引き起こしてしまう。

事例

この事例を見てもらえれば分かるように、
最終的な自分の要望である【自分が嬉しい】は、
１つ手前の【子供が喜ぶ】というものとセットで意味を持つ。
つまり、【子供が喜ぶことで自分が幸福感を感じる】ということがこのモデルのビジョンだ。

なのでいきなりビジョンからトップダウンで考えるということはお勧めしない。
ストーリー性が全くないからである。
すると価値を実現するために重要な品質特性の変数として何が優先度高いかも全く皆目見当がつきにくい。

このビジョンモデリングは大抵抽象化していくごとに１つに収束するものだが、
ごくまれにこのビジョンモデリングをすると発散してしまう方もいる。
それはまだビジョンにたどり着けていない状態なので、１つに集約されるまで繰り返すことでビジョンが可視化されてくる。
もちろん１つのビジョンに縛られない方がいいという意見もあるが、
組織という手段でプロダクトを作り上げる上では北極星になる１つのビジョンに絞った方がいい。

可視化されたビジョンからトップダウン

今度はボトムアップで抽出したビジョンからトップダウンで実現手段を考えていく。
この時大事なのは、最初にボトムアップでビジョンを抽出する際に考えていた「こんなものがほしい」といった手段を一切まっさらにして考えることである。
すると下図のように最初「こんなものがほしい」と思っていたものとは全く違うものが浮き彫りになってくる。

これが先ほどのものよりもより本質的に必要な実現手段である。

この事例と同様にして論点構造ツリーを作成するステップを紹介する。

論点構造ツリーから目標ツリー作成

勝手にこう呼んでいるが、トップ前提であるビジョンを定義し終わっている上で、
そこを起点に各プロジェクトでの大前提論点をツリー構造で定義していく。
その際に仮説ベースで各論点に対する達成指標を定義する。

もちろんそれは実際にプロジェクトの中で得られた知見をもとに、継続的に前提の再検討をすることとセットで考えなくてはいけない。

この際に大事になる思想として、
具体→抽象の依存関係を守りなさいという抽象依存原則と同様にして、
短期目的→より長期の目的　という依存関係を厳守する。
基本的には、より上位の長期的な目標は大前提になる。

下位の短期目標よりも素早い速度で変えることは許されません。
これは抽象依存原則と安定度・抽象度等価の原則を考えれば当然のことです。

より長期目標がドでかい問題に対するものであれば、
さらに階層構造化したものであった方が望ましいが、今回は簡単のため３階層にしました。

ループバックチェック

この際に必ず行った方がいいものとしてループバックチェックという手法があります。
詳細は割愛しますが、上位目的から下位の目的をトップダウンで抽出したら、
「この下位の要素だったらこんな上位目的になるよね」というボトムアップの検証を必ず行います。
この時にもしも違和感があったらその場で修正した方がいいです。

SLAP原則

抽象度を揃えましょうという原則がこのSLAPだが、
この論点構造ツリーでも各レイヤーの粒度は揃えるようにする。
でないと、同じレイヤーの中でどの目標が最も重みがあるのか？の比較ができない。

優先順位付けした上で取り組むものを定義

上記で定義した目標の構造ツリーに対して、各レイヤーの仮説ベースで優先度をつける。
ただし、不確実性の高いものであれば途中で定義した優先度が違うことに気づくことはある。
その際には新しい優先順位付けに更新し、その上でどの目標を達成すべきか？を決める。
一度優先度を定義してもより具体な短期目標のレイヤーでは、取り組むべき問いはコロコロ変わり得る。
それは外部環境の変化、たとえば他社で既に解かれてしまったとか、
もしくは実際に自分たちが成長する中で、それ以上その問いに取り組む効果が無くなっていくとか。

短期と長期のレイヤーを行き来

長期的なレイヤーで目標が抽象的すぎて比較できない場合には、
短期目標という具体的なレイヤーまで下りてみて、そこでまずは比較した上で一段上のレイヤーに行き、優先度付けをするというステップを踏めばいい。

たとえば図において、以下のような優先度の不等式が仮説ベースで定義できたとする。
A-a ＞＞ A-b
B-a ＜＜ B-b
C-a ＞＞ C-b

その上で、A-a、B-b、C-aに仮説ベースで優先度を付けてみよう。
1～3か月程度の短期目標であれば比較的容易に優先度を定義できるはずだ。

もしもそれでも比較できないなら目標が曖昧である可能性があるので、さらに分解した方がいい。

その上で、仮にA-a ＞ B-b ＞ C-a　という順になったとしよう。
その上で一段上のレイヤーに行くと、A＞B＞C という優先度になることが分かる。

ただし、A-a ＞ B-b ＞ C-a　という順はあくまでも仮説なので、
実際にプロジェクトに取り組む中で変わり得る。
すると当然、A＞B＞C という優先度も変わってしまう。

このように比較できない場合には、比較できるくらいの短期的な目標のレイヤーまで下りてみた上で、その上の中期目標や長期目標に優先度を付けよう。

制約条件

制約条件の可視化

目標を阻害する要因である制約条件を列挙する。
継続的に進みながらちょっと先に想定できる脅威を洗い出していく。

またすべての制約条件をなくそうとはせずに、
制約条件同士の因果関係を考えた上で、どの制約を排除していくのが一番インパクトのある問いを解決できるかを考える。

制約理論やLeanとDevOpsの科学によれば、目標を阻害する1番の要因は悪い意味での組織文化、つまりはバイアスである。
したがって、仮説検証を通してどの制約を倒せばドミノ倒しのように最終的な大きな制約を倒せるのか？という因果モデルを常に更新し続け、学習していくスタンスが大切。

制約を取っ払うのにかかるコストとの比較

仮説ベースでいいので、

①上記で考えた制約条件を取っ払うのにかかるおおよそのコスト

②その制約を取っ払うことで得られそうな恩恵

とを定性評価で構わないので、比較する。

もしも上位目的に対してインパクトのあるものであったとしても、
あまりにもコストがかかってしまうようなものであれば、それは解く価値がある問いとは言えない。

また①と②は時間経過とともにその重みが変化してしまう。
そのため、この比較は継続的に行うのがベターである。
もしも外部環境の変化が激しい状況下であれば、１週間以内にスプリントを設定し、
どの程度の変化があり、定性評価の結果は前と変化していないかなどの評価をする。

各スプリントのゴールを設定

プロジェクトのゴールを定義したら、各スプリントのゴールを設定する。
もちろん各スプリントレビュー時に演繹法を使ったボトムアップ式の検証によって、
１スプリントの中で解くべき小さな問いがそもそも解くべきものではなかったという発見がある可能性も高い。

しかしながら事前に構造化して可視化したロードマップがあることによって、
自分たちが設定したどの前提からそもそも再検討すべきなのか？
１プロジェクトゴールまでのレイヤーまでを見直せばいいのか？
それとも戦略ロードマップのところまで更新をかけなくてはいけないのか？
を評価しやすくなる。

そうすることで「なんかこの道をそのまま進んでも意味がなさそうだけど、でも一度決めてしまったことだからもう元に戻れない。」ということにはならず、
図をみながら継続的に小さく置いた前提の検証、および方向修正を
ミクロな粒度からマクロな粒度にかけて一貫して行うことができるのだ。

戦略ロードマップ上の軌道修正

置いた前提がスプリントゴールの粒度で見直しが必要なだけでなく、
そもそものプロジェクト単位の前提からして違っていることが判明したとする。
そんな場合にどうやって戦略を変えるべきだろうか？

具体例

たとえば下図において、上の方のブルー目標地点に到達するには、
上から２つ目の緑を中継する方が費用対効果大きいと仮定を置いて進んでいたとする。

しかし実際にプロジェクトを進めている中で、
２つ目の緑を達成してもブルーに到達できない可能性が判明したとする。

その場合には、即座に１つ手前の中継地点に戻るのだ。
ここで絶対にためらってはいけない。
置いた前提が間違っていると判明したのに、そのまま突き進むのは浪費しているだけで何も価値を生んでいない。
プロジェクトとはそうあってはいけないのだ、

戦略ロードマップ上の１つ手前の所に戻ったら、別のルートを検討する。
この場合には前の知見を持った状態で１番上の緑に次は取り掛かる。

絶対にこの境目でメンバーを交代させてはいけない。
せっかく失敗の中で培った知見が引き継がれることなく、なぜその問いを解いているのかわからないといった事態を引き起こす可能性が高いからだ。

そして戦略ロードマップ中のルートを変えるということは、
自分たちの戦略をそもそも変えなくてはいけないということを表す。
それすなわち、昨日までチームで極めていたケイパビリティを変えなくてはいけないということを表す。

ここで「せっかく昨日まであの分野頑張って勉強してたのに」みたいに執着することは、
戦略を変更できていない＝戦略的方向ベクトルの変更ができていない　ことを表す。

イケていない名ばかりのDXプロジェクトでは、このような現象はよくあるのではなかろうか？
検証の結果、戦略の方向性が間違っていないと判明したら、そのまま極めてもいい.

しかしながら明らかに目指している方向が違っていると判明したのに、
前に戻らない　極めていたケイパビリティを極めることをやめる決断をしないのは、
今進んでいる方向の先にビジョンがある(あってほしい)という単なる妄信に過ぎない。