最近ブログ更新が停滞していました・・・。
さてさて今回のお題ですが、スモールスタートについてのおはなしです。
この数年IT運用改善のプロジェクトを計画しているお客さんで、よく聞くキーワードに
スモールスタート＆クイックウィン
という言葉があります。つまり小さく初めてすぐに成果を出しましょうということなのですが、計画を進めているうちに
あれれ？
という感じで、この計画大丈夫なのかな？と心配になることが多々あります。
スモールスタートと言う言葉が、費用を捻出できないために小さく始めるしかないという逃げの言葉に使われ始めるのです。
子供の頃に、木の上になったブドウを食べられないキツネが「あのブドウは酸っぱいに違いない。」
という捨て台詞をはくという童話？を読んだ記憶があります。大きく始められない言い訳になってしまっているのです。
そうなると、今度は「何を小さく始めるのか？」という事がそもそも決まっていないのでお客さんの中でも計画の推進の軸ブレが起こります。
運用対象数を絞るのか、改善するべきプロセスや仕事の範囲を絞るのか？
そんなことすら決まっていないでスモールスタートと決定してしまうのです。
小さく始めれば効果も小さくなることが殆どですので、仮にクイックにウィンできても大きな効果が得られないという試算になってしまいがちで、担当者は上司に説明できずに結局稟議を通すことができない。なんてことがよくあります。
仮に稟議が通ってプロジェクトがスタートしても、何をウィン（成功）とするのか？が決まっておらず、
「プロセスができました」
とか、
「システムがカットオーバーしました」
とかがウィンにすり替ってしまう事もよくあります。
先のブログでもこのことはお話ししましたが、プロセスを作るとかカットオーバーしたとかは、マイルストーンであってそれらの仕事が、実務やビジネスにどれだけ貢献できたかを証明できるものではありません。
更に苦笑してしまうケースとしては、プロジェクトにおけるSIや利用製品を提案しているSI会社やベンダは自分たちの提案が受け入れられ受注することをウィンと勘違いしてユーザ企業に提案しまっていることもあります。
提案した内容が実際に実行され当初の期待する効果が得られることが真のウィンなのですから、プロジェクト終了後に効果をきちんと測定し、お客さんと共有できることを提案していないのであれば、クイックスタート＆クイックウィンというコンセプトで提案しないほうがいいんじゃないかと個人的には思います。
スモールスタート＆クイックウィンを狙って運用改善を計画する場合には、
- より効果が得られるという範囲や規模についてアタリを事前に付けておくこと。（事前調査と試算が重要）
- 試算結果をウィンとして証明できるようにしておくこと。（KPIの定義と計測）
- 特にスモールスタートの場合は、改善成果などをパーセンテージで算出したほうがよい。（XXパーセント削減など）
- いきなりウィンのハードルを上げない。（７割位できれば良しとする、残りは継続的な改善で良くしていく）
- クイックウィン後のロードマップを明確にしておく（スモールスタートは継続的なPDCAサイクルの一転がり目です。）
などなど事前にある程度の戦略を持ってゴール設定し計画立案することをお勧めします。
