プロジェクト目標がちゃんと実現されるようになっているか、裏取りをすることが重要
itpjstudy
以前の回で、カッコ良いプロジェクト目標を掲げるものの、その成果を十分に獲得できないケースのお話をしました。今回は、どうすれば十分な効果を獲得できるようになるのかについて、お話していこうと思います。
まず、やはり、カッコ良い目標 ＝ 錦の御旗から始まります。
Must-Read Insights
錦の御旗 (にしきのみはた)
下記は、以前の回でも取り上げたプロジェクト目標の例です。
プロジェクトに関わる人達、新システムを利用する人達にとって、「これは、すごい。ぜひ頑張って、実現しなければいけない」と思うようなプロジェクト目標はとても重要です。
ここでは、皆が掲げる共通の目標として、『錦の旗』と呼びたいと思います。
もちろん、身の丈に合ったものでなければいけませんが、大変な労力をかけて、システム導入プロジェクトを進めていく訳ですから、実現できることも大きなものであって欲しいです。
以前の回では、この錦の御旗が、絵に描いた餅で終わってしまうというお話でしたが、どうすれば、十分な効果を確保できるでしょうか。
絵に描いた餅にしないために、錦の御旗をブレイクダウンしていく
ここでは、上記の錦の御旗のうち、「① 全社業務標準化による効率化」を例にとって、お話をします。
まずは、錦の御旗を実現するための施策を検討する
「全社業務標準化による効率化」という言葉だけだと、世の中一般にある「ただの掛け声」でしかありません。
それを、自社で実現するためには、錦の御旗を、自社の状況・文脈に合った施策に落とし込んでいく必要があります。
極めて業務的な検討になりますが、システムの議論に入る前に、この検討をしっかりやっておくことが、欠かせません。
このタイミングで、ユーザ企業のマネジメントへの報告も行われます。ここで、社長や役員の方々が、具体的なイメージを持って、効果を感じられなければ、システム導入で大きな効果を得るのは難しいと考えます。
ここまでの活動を行う期間は、一般的に、構想立案フェーズやグランドデザインフェーズと呼ばれます。
構想立案が終わっても、まだシステム実装の検討には入らない
構想立案を行った後ですが、すぐには、システム実装の検討には入りません。
構想立案フェーズで検討した施策を実現するための業務プロセスやルールの検討（要件定義）を行います。まだまだ、極めて業務的なお話が続きます。
変更後の業務プロセスやルールで、詳細化された各施策が実現できるのかを確認していきます。そのあと、ようやくシステム実装の検討（基本設計）になっていきます。
基本設計後に、錦の御旗が実現される実装になっているのか点検する
実施できているプロジェクトは、あまり多くないと思いますが、基本設計のあと、錦の御旗が実現できるようになっているのか、点検することを推奨します。
プロジェクトによっては、要件定義や基本設計が難航してしてしまい、錦の御旗の実現よりも、まずはフェーズを終わらせることが優先されてしまう場合があります。
そういった場合、動くものはできたが、錦の御旗は実現できないという結果になることが少なからずあります。
そのため、集中確認会などを設けて、構想立案・要件定義の成果物を見ながら、システム実装のウォークスルーをしていきながら、錦の御旗が想定通り実現できるのか確認することを推奨します。
ここまで、錦の御旗を実現するための進め方について、説明してきました。
ここからは、効果実現が十分できなかったプロジェクトが、失敗しがちな点について、お話していきます。
よくある失敗：いきなり要件定義に入ってしまう
多くの失敗として、前段の構想立案フェーズでの踏み込みが甘いまま、いきなり要件定義フェーズに入ってしまうケースがあります。
錦の御旗を実現するために「どうありたいか」の具体的なイメージができていませんから、錦の御旗の実現は当然困難になります。
最近のシステム導入では、パッケージソリューションを使うことが多いですが、「どうありたいか」の具体的なイメージのないまま、パッケージの標準プロセスとのFit ＆ Gap分析に終始している事例が大変多いように見えます。
うちが導入するソリューションはベストプラクティスだと聞いてるよ。パッケージに業務を合わせれば、大きな効果が得られるんだよね？
企業のIT化があまり進んでいなかった時代には、パッケージソリューションを入れるだけで、一定の大きな効果があった時期もありましたが、今はそうではありません。
しっかりと、錦の御旗をブレイクダウンして、「どうありたいか」の具体的なイメージを持ったうえで、システム実装の検討に入って行くことが大変重要です。
大きな導入効果を獲得しようと思うと、システム実装の検討の前に、極めて業務的な検討を入念に行う必要があります。
IT主導で業務側のマネジメントの関りが弱いケースや、パッケージソリューションでいきなりFit ＆ Gapに入ってしまうケースなどは、失敗しがちです。
ちなみに、パッケージの標準プロセスに業務を合わせることは非常に重要で、業務側で業務プロセスを決め過ぎることにもリスクがあるのですが、この辺りは、また別の機会にお話します。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
