全6926文字
PR

DXプロジェクトの構想フェーズでは、基幹系システム開発プロジェクトと作業内容が異なる。「どう作るか」の前に「何をするか」を決める必要があるからだ。構想フェーズで決めるべき4項目と、このフェーズの根幹になる「サービス企画」の進め方を解説する。

 今回からDX(デジタルトランスフォーメーション)プロジェクトの最初の工程である「構想フェーズ」を取り上げます。DXプロジェクトの構想フェーズでは、基幹系システム開発プロジェクトと作業の内容が異なります(図1)。基幹系システム開発プロジェクトでは、プロジェクトの種類によって、解決すべき課題や解決方針がある程度決まります。

図1●構想フェーズでの基幹系システム開発とDXの違い
図1●構想フェーズでの基幹系システム開発とDXの違い
[画像のクリックで拡大表示]

 例えば、プロジェクト種類として、パッケージ導入やシステム移行、システム統廃合などがあります。この場合、解決すべき課題はコスト削減やEOS(End of Support:サポート終了)への対応などです。解決策も、「SAP」「Oracle EBS」などのパッケージを導入する、開発言語をCOBOLからJavaに置き換えるなど、大体は予想できます。ある程度「何をするか」が明確なので、構想フェーズでは、製品選定や効果・コストの試算、フェージング・開発計画の策定などの「どうやってやるか(How)」に重きが置かれます。

 しかしDXプロジェクトでは「何をするか(What)」を定義するところから始まります。例えばB2C(消費者向け)のサービス構想策定作業の場合、誰(どんな消費者)に、なぜ、どのようなサービスを提供するのかを詰めていきます。基幹系システムのように既存システムや既存業務ありきではなく、必要なシステムをゼロベースで決めていくのです。

 構想フェーズの段階で、そもそも「誰」に対するサービスかが曖昧なケースもあります。筆者がこれまで手掛けたプロジェクトでも、そうした例がありました。特にブロックチェーンや顔認証などの技術を既に持っている会社の場合、その技術で何かをしようというプロダクトアウト的な発想になりがちです。

 これではDXプロジェクトはうまく進みません。筆者自身が自社サービスを企画・開発してきた経験から言えるのは、「誰」に届けるかが決まっていないサービスは市場に適合できないということです。ニーズに合っていないサービスになりやすいからです。少なからぬ投資をしたのに、誰も使わないサービスにはしたくないものです。

 このため、構想フェーズでの企画内容がサービスの成否に大きく影響します。システム開発が進んでしまうと、費用やスケジュール面の制約でなかなか企画段階まで後戻りしてやり直せないのが現実です。DXプロジェクトにおける構想フェーズは、非常に重要な工程なのです。

 それでは、構想フェーズで具体的にどのようなことを整理していくべきかについて、まとめていきます。本連載における構想フェーズは要件定義の手前まで、つまり要求定義を含むものとします。