ソフトウェア構築におけるプロジェクト以前の工程、いわゆる企画とか(超)上流工程という領域について勉強していると、よくこういう声が聞こえる。「それはお客様が決めるから」「言われたことしかやれない」。そこで挫折して目を閉じてしまって、ソフトウェアの完成間近になって不備が見つかると、「お客様が決めたことだから」「言われたから」と言ってしまう。不毛だ。
以下のブログ記事を読んで、要求開発における「戦略リバース」というやり方のことを思い出した。
この記事で紹介されているのは、ビジネス企画書をLeanCanvasにリバースするという方法である。これに対して要求開発の「戦略リバース」では、プロジェクト計画をBSC戦略マップにリバースする手法だ。
下流から上流に手を伸ばしてチェックをするやり方というのは使えるのではないかと改めて考えている。
戦略リバースとは
要求開発では、目的と手段の整合性をチェックに使うことで「ムダなシステム」にならないようにしている。とはいえ、ビジネス戦略そのものが論理的でない場合もあるので、ボトムアップで論理性を再検証するようなやり方が提唱されている。
要求開発を行う場合に、重要なことは、そのゴールとなる具体的な「目標」と「目標値」を、企業全体の目標からブレークダウンして論理的に理解しておくことである。そして「ビジネス要求」という要求開発のインプットをプロジェクトの初期の段階で把握することである。そのためには、経営計画などの既存の制度による計画を「戦略マネジメント・システム」に「あてはめ」て考えていく。本書では、この「あてはめ」を「戦略のリバース」と呼ぶ。
戦略的「要求開発」のススメ
「戦略のリバース」は、既存の資料を戦略マップというフレームワークに「あてはめる」という活動である。そして、「あてはめる」ことで「『役に立つ』とは、どういうことか」を明確にすることが目的であり、それが「要求開発」のゴールを明確にする。そのために、戦略と施策との「目的と手段」という論理的な関係を理解する。
戦略的「要求開発」のススメ
上記の画像は、要求開発が紹介された2006年のデブサミ発表資料から。
要求だってリバースできる
リバースエンジニアリング(ソフトウェアの仕様を、実際に動くプログラムから逆に求めること)はソフトウェアエンジニアにとっては馴染み深いものだ。同じように、『要求』をリバースすれば、要求の妥当性や網羅性などについて検証することができる。
冒頭で書いた「言われたことしかやらせてもらえない」という愚痴のかわりに、要求をリバースしてみるのはどうだろうかと思う。
要求開発ではBSC戦略マップを例にしていたが、最近の流行であればビジネスモデルキャンバスやリーンキャンバスなどを使っても良いと思う。
既にサービスの企画書があって、ソフトウェアとして何を作るべきかを考える状況でも、LeanCanvasが使える(LeanCanvasの詳細についてはこちらをどうぞ)。企画書の内容をLeanCanvasの各エリアに書き出していって、空欄のままになっているエリアや、内容が不足しているエリアを特定する。これから作ろうとしているサービスに、該当エリアの検討は必要ではないか、企画者と会話すべきポイントになる。
LeanCanvasとエリアの関連性から企画書を見る。 - The Dragon Scroll
ただし、「完成形のモデル」をリバースで作ろうとしてはいけない。リバースで作られるモデルはあくまで企画者や利害関係者とコミュニケーションをとるためのものである。モデルの美しさや完成度にこだわって、そもそもの企画を疑い始めると、完全な企画フェーズへの逆戻りになるので、そこは注意すべきだと思う。
