現在地と目的地が分かっていないプロジェクトは失敗する──「ITで儲かる計画」を描く実践フレームワーク

「どこを目指すのか」を描く──To-Be分析にありがちな失敗

　As-Isで現在地がわかったら、次は「将来どのようになっているべきなのか」（To-Be：あるべき姿）を描きます。実施するプロジェクトは、As-Isと、このTo-Beの“差分”を埋めるための取り組みとなるのです。受験対策を例にとった場合、プロジェクトは受験勉強に相当します。

　To-Beを立案するときのポイントは、特定の手法（システム購入など）を前提に描くのではなく、事業戦略と照らし合わせて必要な姿を描くこと。To-Beを検討する際にありがちな失敗は、いきなりコンサルタントやベンダーが持っているシステムに当てはめて理想像を描いたり、「こんなシステムが欲しい」と機能要件から詰めてしまったりすることです。

　特定の手法ありきでTo-Beを検討してしまうと、そこから抜け落ちた課題がその後も自社を苦しめ続けることになります。「こんなはずじゃなかった」とやり直しが必要になったり、理想と現実とのギャップを埋めるために際限のない追加投資が必要になったりする事態に陥りかねません。提案時は隠されたり過小評価されたりしていたデメリットやリスクが業務負荷やカスタマイズ費用として降り掛かってくるのです。

　まずは「自分たちの組織や事業が数年後にどのような姿になっているべきなのか」を組織内で明確にし、そこから手段を見極めていくアプローチが欠かせません。そうすることで、経営層だけでなく現場も共通の認識をもち、“同じ地図”をもってプロジェクトに取り組むことが可能になるのです。目標がクリアになったらそれらを因数分解し、各事業の改善すべき指標（KPI）を明確にし、プロジェクトの目的へとつなげます。

　また、To-Beを立案する際は、特定の商品やソリューションとつながっていない中立的な立場の専門家の知見を借りることも有効です。ITや業務改善の専門家は類似した課題に対処した経験が多いため、ある課題に対してどのような打ち手が有効なのかを理解しています。昨今よく見るTo-Beの失敗例として挙げられるのが、プロジェクトの意思決定者が「AIは何でもやってくれる」と誤認して、それがプロジェクトの目的とされているケース。当然ながら生成AIも一つの技術なので、できることに限界がありますが、この部分の見通しが不正確であるために、せっかく投資したプロジェクトが有効な成果を出せないことがあります。こうした失敗を防ぐためにも、To-Beの検討に専門家の知見を取り入れることは効果的といえます。

　では、To-Beの成果物の例を見てみましょう。次の図1-14は、前掲のサンプル企業A社におけるAs-Isをもとに、どのようなTo-Beが必要なのかを明確にしたもの。A社の課題は業務フローが複雑化・属人化しており、多様なツールが導入されているために各部署の連携が十分とれておらず、コミュニケーションミスやそれによるトラブルが頻発していることにありました。そこで、「案件マネジメントシステム」を導入することで、業務フローと情報共有の課題を一気に解決することを図ったのです。