アーキテクチャにもOutcome Deliveryを使おう
Mobius Outcome Delivery Masterclassにて事例紹介させていただきました。
前半部分、なぜアーキテクチャにもOutcome Deliveryを使うのか、の部分のサマリを作っておきます。
イベントはこちら。
そもそもMobius Outcome Deliveryとは？
Outcome Deliveryはデザイン思考をベースとした問題解決のフレームワークで、よくプロダクト開発に使われます。
ただし非常によくできており、一般的な問題解決にも使えるんですよ。
アーキテクチャにOutcome Deliveryが使えると思う理由
理由1:
ソリューションモードにいち早く飛びつきやすい領域だから！
例えば我々のところに入ってきた「マイクロサービスアーキテクチャをやりたいんです！」と言うお客さんの困り事を聞いたら、実はDevOpsとアジャイル、およびフロントエンドとバックエンドの分離ができればよかったとか。
あるいは現在のAPIのエンドポイント (URL) の粒度の見直しが必要なだけだったとか。
そういう案件がたくさんあります。
もし本当にマイクロサービスアーキテクチャ化を進めていったら、本来解決したかった課題を解決できない何かのために何千万も何年もかけることになります。
理由2:
予算の獲得
これは2軸あって、以下2点が明確になっていなかったりするとやっぱり予算がおりにくい。
アーキテクチャが良いとビジネス側 (=予算を出す人) は何が嬉しいんだろう？
他には本当に解決策はないんだよね？
Outcome Deliveryの提供するマップを使いながら基本の流れに従うと、これがうまくカバーできるのでとてもいいんですよ。
TOGAFとの相性
TOGAFっていうアーキテクチャ策定フレームワークがありまして
以前これをチラッと解説してます。
これ勉強すると、アーキテクチャって設計して実装したら終わりじゃなくて、元々の目標値に足りなかったらそれをどう是正するかを検討するのが自動的にプロセスに組み込まれているんですよね。
で、これを以下のようにマップして実行すると非常に相性がいい。
GやHが実際の開発プロジェクトなんですが、開発プロジェクトが終わってから効果の程を測定するわけです。
そうすると目標値に達成しているかがわかります。
達成していない場合はどうやったら是正できるかを考えて右側の部分をもう1ループするわけです。
実際に使ってみた例
詳しい解説は割愛しますが、以下のような分析手法や表現方法を使った例をご紹介しました。
プロジェクト遅延の原因がアーキテクチャにあった例です。
関係各所から開発プロセスのインタビューをMajikaフレームワークで実施しました。
集めた情報をVSMで分析し、Customer Mapで顧客にとっての困り事を明確にします。
同時にこれが先に進むとすると予算はビジネス側 (CIO) から出るので、これはCIOにとってはなぜやらなければいけないんだろう？をBusiness Mapで明確にし、常にCIOにとっての目的感を意識して進められるようにしました。
共感マップはDELIVERで実施した実験の結果により後から必要になって書きました。
思いついた課題をPrioritize OptionsやWSJFを使って優先順位をつけ、効果が出るかどうか実験をしました。
スタート段階で、経験的にこれはリファクタリングじゃないと無理だなーと思ったので、DELIVER部分の実験は本当にその他の解決策では効果がないのか確認する目的、および他の解決策はないという証拠がためのために実施しました。
証拠がためですので実験はMVPを意識し、最小限で作るようにしました。
実験の作成時にはStory Boardを使い、効果測定をして、結果を使ってもしこの解決策でCIOに訴求するとなるとどういうエレベーターピッチになる化を考えるため、Epic Hypothesis Statementを使ってまとめています。
実験は基本的にタイムボックスで実施し、最後にレトロスペクティブを実施して作業の効率化をしています。
以上！
そのうち動画をConnpassのイベントページにて共有するかもしれません。ご興味がありましたらそちらをご参照ください。