はじめに

前回のコラムでは、SBO（スクラッチ開発）及びパッケージシステムの導入プロセスとSaaSシステムの導入プロセスを比較することで、SaaSシステムの導入プロジェクトマネジメント方法論を検討した。今回のコラムでは、SaaSシステムの導入プロジェクトの特徴を考えてみたい。

投資リスクから来るプロジェクトマネジメントの方向性の違い

前回のコラムで、システム投資リスクについて簡単に言及したが、もう少し詳しく考えてみよう。
SBOによる開発やパッケージ購入によるシステム導入は、簡単に言うと、買ってから稼働させる、作ってから稼働という観点でシステム導入プロジェクトを進めることになる。これは、プロジェクト管理の観点で言えば、いかに「無事に」システムを稼働させるか、という視点に重きが置かれることになる。つまり、導入できなければ、そのプロジェクトは「失敗」であると評価される訳である。

一方、SaaSシステムの場合、システム購入費用やハードウェアの購入や環境構築の不要の為、SBOやパッケージの導入と比較して初期投資を極端に抑えることができる。その上で、プロジェクトマネジメントの観点として、「導入しようとしているSaaSシステムが自社に合うか？」や「SaaSを使って如何に自社の業務効率を向上させたり、ビジネスを拡大させたりすることができるか？」という観点から導入を進めてゆくことになる。これは、初期投資が少ない分、捨てるという意志決定をしやすい、というSaaSの特徴から来ている違いである。

導入方法論の違い

次に、実際導入するに当たっての個別に導入方法論的な違いを見ていこう。/p>

• 要求定義の進め方の違い

  SBOやパッケージの導入に於いては、ます最初に現状分析（As Is）を行い、その上で要件定義を行う流れとなる。SaaSの場合は、すでにすでにある程度本番環境に近い形で動作するものがあるため、導入プロジェクト担当者や実際の業務担当者が実際に使いシステムの画面を確認しながら、実際の業務プロセスと摺り合わせつつシステムの要件定義を進めてゆく形式となる。言わば、要求定義とシステムの機能仕様がお互いに絡み合いながら導入プロセスが進んでゆくことになる。

  また、その際は前回のコラムでも考察したとおりコンフィグレーションを中心に進めてゆくことになるが、そのコンフィグレーションもリアルタイムでシステムに反映されてゆくため、その場でSaaSシステムの動作を確認しながら要求定義と機能仕様を平行してブラッシュアップさせてゆく、という進め方になるのである。

• プロジェクトメンバーの構成

  要求仕様定義の仕方の違いは、プロジェクトメンバーの構成にも影響を与える。SOBによる開発やパッケージの導入では、関連する領域のITに精通したシステム技術者が必須であるが、SaaSの場合はシステム管理や環境構築などの技術的領域はすべてSaaSベンダーから提供されるため、SaaS導入プロジェクトに於いてはITの技術者よりもむしろ業務を理解した分析から設定までのプロセスを担うコンサルタントが中心的な役割を担うことになる。また、その際には、導入の際にはプロジェクト導入推進者だけでなく、実際に利用するユーザーの参画度合いが大きくなるため、それらの要求仕様を言わば「捌く」スキルがこれまで以上に大きく要求されることになる。

  さらに、ユーザーと話をしながらプロジェクトを進めてゆく機会が多くなるために、持ち帰り先（オフィス）での作業を中心的に担うリソースは、特にプロジェクトが一定規模以上にならない限りは必要ないことになる。

  つまり、従来の導入形態（Face to Faceを前提とした常駐形態による開発を中心としたプロジェクト体制による導入とは異なり、SaaSの場合はリモート環境による導入になるため遠隔コミュニケーションによるコンフィグレーションを中心としたプロジェクトの進め方になるのである。

• リモート環境による導入

  これはSaaS導入を実際に行うと実感する点であるが、インターネットによる機能利用が前提となるSaaSシステムは、その特徴が導入の際も活かされることになる。どういうことかというと、極端に言うと導入するコンサルタントやプロジェクトマネージャーと実際の利用ユーザーが直接顔を合わさなくても導入うを進めることができる、ということである。

  実際、アメリカでは7割以上のプロジェクトが一度も顔を合わせずに完了している。国土の広いアメリカでは、打合せをするために移動の時間やコストも大きくかかるため、以前から電話会議などのシステムが普及していたが、SaaSの導入ではそれを一歩進めて、電話会議上で打合せをしながらコンフィグレーションを進め、その場でシステム仕様を詰めてゆく、という導入の仕方が普及している。アメリカの特に中西部を中心にまずSaaSが普及したのも、こうした理由が一つがると考えられる。

  このことは日本でも同様のことが言え、弊社で実施した地方のクライアントへの導入プロジェクトの際には、実際に先方に訪問して打合せをするのは月１回程度で、あとは電話会議でお互いに画面を見ながら要求定義とコンフィグレーションを進めてゆく形を取った。このことにより、お互いの移動時間などの工数を大幅に減らすことができ、また１回の打合せにおける負担感も大幅に減らすことができた。その結果、非常に効率良く導入を進めることができ、例えば財務会計・管理会計を中心とするシステム業務基盤を平均で約４ヶ月程度で構築することができるようになっている。

SaaSシステム管理上の留意点

SaaSシステム導入の特徴が以上に概観したが、次にこうした特徴から来るSaaSシステム導入に於ける管理上の留意点を見てゆこう。

• システムリリース時期の判断

  SaaSの、最初からある程度動く、という特徴は、逆に言えばどの時点でリリースをするかの判断がSBOやパッケージの導入よりも難しくなる。極端に言うと、本番環境でコンフィグレーションを進め都度テスト稼働をさせながら、ある程度システムの品質が担保できた時点でリリースという流れになるため、やろうと思えばコンフィグレーションの途中でも社内利用を始めることがでることになる。

  プロジェクトマネジメント上でこの点は非常に重要で、これまでのシステム導入以上にリリースした時点でもシステムの品質がプロジェクトマネージャーの技量にかかってくる、ということになる。また、だからといっていつまでもダラダラと導入プロジェクトを大なっていれば良いという訳ではなく、決められた目標期日までに如何にSaaSシステムの導入品質を上げてリリースされるか、という視点が強く求められることになる。

  場合によっては、リリースをした後で稼働しているシステムをブラッシュアップすることになってくるが、その場合も、どの部分をどの程度、いつまでにブラッシュアップさせるか、という視点でプロジェクト管理を行うことが重要になり、それらの全体の方針策定を含めてプロジェクトマネージャーが役割を担うことになる。

  現実的なプロジェクト管理上の方法論としては、SaaSであっても、やはりリリース目標時期などを勘案しながらプロジェクトマネージャー主導で要件定義の終了と本番仕様の決定をいったん行い、どこまでを本番時点で実装するかをユーザと合意するステップを取る、という形が落としどころになるであろう。但し、SaaSであれば仕様決定後も例えばレポートの項目などユーザ自身で変更できるような軽微な修正など影響度の低いものは、改善できるので、この点は従来のスクラッチ方よりは柔軟にケースバイケースで対応してゆくことができる。

• ドキュメント管理

  SaaSシステムの導入は、要求定義と機能要件が絡み合いながら進められてゆくことは導入方法論の違いで見てきたとおりだが、これはともすれば要求定義書や機能要件定義書の作成が疎かになるリスクをはらんでいることに留意すべきである。つまり、SBOやパッケージの導入では、要求定義書や機能要件定義書がプロジェクト内で承認されて始めて次のフェーズに進めることができるが、SaaSシステムの導入においてはユーザーとコミュニケーションを取りながらリアルタイムでコンフィグレーションを進めることとなるため、ドキュメントの作成が後追いとなりがちになり、その状態が続くと、ドキュメントの作成が実際のプロジェクトの進捗に追いつかなくなってしまう、ということになりかねない。

  特にプロジェクトが進んでいる間は特にこの問題に明確に気づかないが、プロジェクトが終わってみると、コンフィグレーションが決定した経緯を含めドキュメントが一切残っておらず、また導入当時の状況も分からなくなってしまっている、ということになってしまわないように、プロジェクトマネージャーがプロジェクトの進行中からドキュメントは留意して整備してゆくことが求められる。

  ただし一点注意したい点として、最初からドキュメントを完璧に整備しようとすると、その後に変更が頻繁に行われていくためにかえってワークロード上の負荷が上がり、作業効率を阻害しかねない。悪くするとSaaS導入の際のプロジェクト効率の良さという特質を棄損しかねない為、導入プロセス用のドキュメントと最終化用のドキュメントを分けて管理するなどの工夫が必要になるだろう。

• 更新管理

  コンフィグレーションの更新管理はパッケージの導入でも同様のことが求められるが、特にSaaSシステムの導入の場合、リアルタイムで更新できるという特徴から、コンフィグレーションの更新管理も重要な留意点になる。ユーザーと話をしながらその場でコンフィグレーションをブラッシュアップさせていったのはいいが、どこの部分がどのように設定されたのか分からなくなってしまうと、後々でSaaSシステム全体の整合性を阻害する状況に陥るリスクがある。システムによってはコンフィグレーションの変更履歴を自動的にログ管理してくれる機能が付加されているものもあるが、それでも全体として、いつ、どのような目的で、どこの部分が、どのように設定されているのか、というコンフィグレーションとその設定履歴の管理はSaaSシステム全体を管理する上で必須のものである。

まとめ

以上見てきたとおり、SaaSシステムは、単に技術上のシステム機能の提供方法が従来のシステム機能の提供方法と変わった、という以上のインパクトを持っている。

私は、SaaSシステムの普及により、システム投資や導入プロセスの観点からも、よりシステムがユーザーにとって利用しやすい環境が整ってきているとの印象を持っているが、これらのSaaSシステムがメリットとして持つ環境や特徴を適切にユーザーに提供する義務と責任がシステムベンダーやコンサルティングファームにはあると感じている。

次回は、これまで見てきたSaaSシステムの導入プロセスの特徴から、システムベンダーやコンサルティングファームにおける従来のビジネスモデルとSaaSを前提としたビジネスモデルの違いを考えてみたい。