パブリッククラウド基幹システムの誤解

パブリッククラウド基幹システムに対して、よくある誤解が２つある。
 
まず多いのは、「パブリッククラウド型基幹システムを導入する場合は、システムに業務を合わせる（Fit to Standard）必要があるのは理解しているが、合わなければ追加開発で作れば良い」と考えてしまうことだ。オンプレ型の基幹システムを利用している人がクラウドを検討する場合、このような考えに陥りやすい。しかし、パブリッククラウド型はオンプレミス型に比べ制約事項も多く、追加開発をする場合はオンプレ時より開発量が増えたり、期待値に達しないレベルの開発しかできなかったりする。
次にパブリッククラウド型基幹システムは、コストが安いという考えだ。一般的には、オンプレでの導入に比べ初期構築の手間がかからないので安価に利用はできる。ただしそれは、自社の業務プロセスがパブリッククラウド型基幹システムとマッチしている、あるいは業務プロセスを変更しシステムに合わせることができるのが前提だ。
 
 

パブリッククラウド基幹システム導入課題

パブリッククラウド型基幹システムを十分に理解しないで導入を進めた場合に発生しやすい課題は以下の3点だ。
 

①Fit to Standardなのに、結局ギャップ出しに集中する

Fit to Standardセッション（業務プロセスをシステムに合わせ、改善・標準化を図る検討）を行っても、業務側は現行業務を維持する考えから抜けられないことが多い。そのため、現行業務と標準システムを比較し、その差を導入ベンダーに埋めてもらうという動きになる。また、業務理解がないベンダー側はシステムでその要求に応えようと動いてしまう。結果業務側はギャップ出しに専念してしまう。
 

②サービスに制限があり、開発が増大することや、複雑になる傾向

パブリッククラウド型基幹システムは、Fit to Standardの考えに基づくため、サービスに制限が多く、プライベートクラウド型やオンプレミス型基幹システムのように調整できるわけではない。そのため、現行業務とのギャップが生じるが、そのギャップを埋める対応で追加開発することになり、結果的に開発が増える。また、制約事項から追加開発プログラムが複雑化しやすい。
その結果、予定工期の超過によりコストが増大するケースや最悪の場合プロジェクトがとん挫するケースに発展することもある。
 

③プロジェクト途中で、スコープの変更が発生しやすい

Fit to Standardセッションの結果、業務プロセスを変えることができず、顧客特有の現行業務の実現が必須となった場合に、パブリッククラウド型基幹システム内での調整も難しく、追加開発でもやりきれないと判断されると、他システム／サービスでの実現をプロジェクト途中で検討しなければならなくなる。スコープが変更になることで、スケジュールの維持が難しくなり、ここでもコスト超過が避けられない。そして、必要な要員のスキルも変わり、ここでもコスト高が発生する恐れがある。
 
以上のことが発生するような事態になると、そもそもパブリッククラウド型基幹システムの導入が適切だったのかということにもなりかねない。
 
 

パブリッククラウド基幹システム事前検討

こういった事態を避けるためにも、パブリッククラウド型基幹システム導入では、プロジェクト開始前に以下の4点の検討が肝要だ。
 

①業務側がどうやって業務を実施できるかを考えられるようなセッションの実施

Fit to Standardセッションは、要件のギャップを出す場でなく、業務側がこれでどうやって業務を実施するかを考える場だ。業務側が、現行プロセスに固執せず、どう適応するかを考えられるようなセッションにする必要がある。セッション実施側は、例えば、現在使っているマスターを変更することなく利用できるかをあらかじめ確認したり、変更後の業務イメージができる資料を作成しておくなど、受け入れやすい情報を用意することも大切だ。またFit to Standardで進めるためには、パブリッククラウド型基幹システムだけでなく、他サービスも組み合わせて利用する可能性があることを前もって伝え、それらのサービスも含め用語やサービスのコンセプトなどを説明し、理解を促しておく必要がある。このようなプロセスを経て、業務側がセッション実施前までに、「どうすればFit to Standardで業務を実施するか」と考えるモードになるように準備することが大切だ。
 

②サービスを組み合わせてスコープが成立することを確認

現行の基幹システムで自社独自業務機能を抽出し、今後もそれらは業務として継続する必要があるかをまず判断する。必要と判断されたら、それらがパブリッククラウド型基幹システムだけで成立するかを確認し、そうでないなら、別のサービスなどを組み合わせて利用することで実現できないかを検討する。そして、いくつかのサービスや周辺システムの組み合わせで期待する機能が充足されることを概要レベルで確認しておくことが重要だ。世の中に適切なサービスがない場合は、やむを得ず追加開発することにする。この時点は概要レベルの検討なので、実現性の確認まではなかなか難しいが、接続に不安点があるならAPIがあるかを前もって調べておいた方がよりプロジェクトリスクを低減できる。
 

③サービスを組み合わせてそのまま使うことを業務側含めて合意

いくつかのサービスの組み合わせで期待する機能が実現することを確認できたら、それらをそのまま利用して業務を実施することをプロジェクトメンバーだけでなく、業務担当者に合意を取っておくことが大切だ。なぜパブリッククラウド型基幹システムを選択したのか、それが自社にとってどんなメリットがあるのかなど、業務側に理解してもらうことが重要だ。
 

④プロジェクト途中で、スコープが変わることを想定

サービスを組み合わせてスコープが成立することを事前に確認したとしても、プロジェクトを開始し業務の詳細検討が進むと、想定していた組み合わせでは対応できないことが発生する場合が多々ある。その場合は、さらに他のサービス利用の検討が必要になり結果的に、工数、スケジュール、コスト変更が発生する。これに関してはやむを得ないものとしてあらかじめ、変更が発生する前提の計画としておくか、発生時に検討するとしても、こういう変更が発生する可能性があることを関係者間でプロジェクト開始前に合意しておくことが重要だ。
 
これらの検討をした上でも、うまく進められない課題があり、その解決が難しい場合は、パブリッククラウド型基幹システムの導入は時期尚早と考えられる。
 
 

おわりに

パブリッククラウド型基幹システムの導入は、これからさらに普及すると考えられる。業務の標準化が進み、データが一元化されることで、経営判断の迅速化や、事業変革への対応、人材の適正化などが期待できる。IT面でもシステムの属人化リスクの低減、アップグレードやインフラ周りの対応から解放されITコストが最適化されるなど、多くのメリットがある。しかしながら、従来型の基幹システムの導入と同じ意識で実施すると痛い目に遭う可能性が高い。さまざまな企業があり、それぞれの業務がある以上、パブリッククラウド型基幹システムだけでは、自社業務を網羅することは難しい。だからと言って、多くの追加開発をしたのでは、パブリッククラウド基幹システムを導入するメリットが少なくなる。関係者全員が「従来型のパッケージ+自社向け開発」から「サービス利用」という意識に転換し、どういう組み合わせであれば業務が網羅できるかという発想で取り組むことが欠かせない。本稿が、皆さまのパブリッククラウド型基幹システムの成功の一助となれば幸甚である。