見出し画像

SaaS導入はウォーターフォールよりもアジャイル的に進める方がいい3つの理由

元来、業務システムの導入では、ウォーターフォール型と言われる導入プロセスで行うのが鉄則とされてきました。

SaaS導入は80%のアジャイルと20%のウォーターフォールをオススメしたい理由_1

■ウォーターフォール型導入の主なプロセス
・業務プロセスのTo-Be(理想状態)を定義
・業務プロセスのAs-Is(現状)を整理
・To-BeとAs-Isのギャップを分析
・ギャップを解消できるよう仕様を設計
・開発・テスト
・本番運用

これらのプロセスを順番に進めていく様子が、
滝のように流れていく=ウォーターフォール型と名前の由来です。
(最初にそう呼んだ人、天才…)

業務システムは文字通り業務に直結しており、一度導入してしまうとそう簡単には変えられないという前提があったため、導入前に緻密な要件定義を行なってからシステム導入することが当たり前と考えられていました。

「完璧な」ウォーターフォールはSaaS導入に向いていない

僕の経験上、「完璧な」ウォーターフォール型でSaaSを導入しようとすると、メリットよりもデメリットが大きくなる印象があるため、あまりオススメできません。

以下、その理由を記載します。

理由①:導入を進めている間に業務要件が変わる

SaaSのメリットの1つがすべての機能をすぐに利用開始できることです。

ところが、ウォーターフォール型で導入を行おうとすると、現状整理や要件定義に大幅な時間が割かれて、導入までに数ヶ月以上かかってしまうケースがあります。

SaaS導入は80%のアジャイルと20%のウォーターフォールをオススメしたい理由_2.002

ビジネス環境の変化が早い昨今、数ヶ月も経つと業務要件が変わってしまうこともザラにあるので、導入時に検討していた要件が導入を進めている間に変わってしまう可能性も十分に考えられます。

100%の要件を定義するのでなく、70%程度の要件を決めたら、トライアルで業務に装着する方がSaaSのメリットを活かして、無駄なくスピーディーに導入が進められます。

(とはいえ、要件を全く決めずに導入するのはやめた方いいですよ!)

理由②:自分たちの理想形 ≠ 業務の理想形

前述した通り、ウォーターフォール型の導入では、はじめに業務のあるべき姿(To-Be)を設定するのですが、自分たちが考える理想的な業務=最適な業務とバイアスが少なからず存在します。

SaaS導入は80%のアジャイルと20%のウォーターフォールをオススメしたい理由.003

SaaSは様々な業界・企業におけるベストプラクティスでありある種の共通解を前提に作られています。そのため、ほとんどのケースでは自分でTo-Beを設定するよりも、SaaSベンダーが提供しているベストプラクティスに業務を合わせる方がベターです。

理由③:クラウドはアップデートされ続ける

SaaS導入は80%のアジャイルと20%のウォーターフォールをオススメしたい理由.004

オンプレミスと呼ばれるインストール型のソフトウェアパッケージは、改修やバージョンアップが非常に大変であるため、時間をかけて業務要件と機能の整合性を確認することが合理的な進め方でした。

一方、クラウドサービスは様々な企業からの要望をベースに日々進化し続けます。導入時の断面だけでSaaSの機能を見てしまうと、将来的な業務要件とのギャップが生まれてしまうリスクがあります。

現在の業務課題だけでなく、自社で将来起きうる要件も念頭に置いて、SaaSの導入を行っていく必要があります。

ちなみに、僕がSaaS導入の支援をする際は、 サービスのロードマップを確認することをオススメしています。中長期的にどのような機能が搭載され流のか、どんなプロダクトになっていくのかを把握すると、将来のギャップを最小化しやすくなります。

アジャイルの発想で業務とシステムをアップデートし続ける

現在の世の中は業務もシステムも日々変化していきます。

新しい商品が増えた、部署の統廃合が発生した、サイトがリニューアルしたなど、日々発生するイベントに合わせて、SaaSの設定をチューニングして行かないと、あっと言う間に業務の実態と乖離したシステムになってしまいます。

時にはSaaS側の新しい機能が登場したことによって、業務プロセスが変わることもあるでしょう。

このような状況下で業務システムとしてSaaSを使いこなすためには、導入をゴールにするのではなく、アジャイルの発想で継続的にPDCAを回し続けることが必須となってきます。

SaaS導入は80%のアジャイルと20%のウォーターフォールをオススメしたい理由.005

とはいえウォーターフォールも必要

今までと言っていることが真逆じゃないかと聞こえてきそうですが、ここで伝えたいのは「手戻りを避ける」というウォーターフォールの考え方です。

SaaS導入で手戻りができない部分。それは「サービス選定」です。

先述した通り、業務プロセスと機能のフィッティングは、導入後に改善していくことが出来ますが、サービスそのものはそうはいきません。マンションの内装はいくらでも変えられるけど、マンションそのものは簡単に変えられないのと一緒ですね。

サービス選定の具体的なプロセスは、こちらの資料で紹介しているのでご興味がある方は是非ダウンロードしてみて下さい。

不確実性を受け入れよう

業務システムの導入時には、意思決定者から「要件全部出し切った?」「それで本当に業務は回るの?」「ROIどうなってるの?」といった質問が飛んでくるのがあるあるです。

これらは不確実性をリスクヘッジしたい気持ちの表れです。

もちろんリスクを一定以下に低下させることはとても重要ですが、SaaS導入時に極端に不確実性を排除しようとすると、SaaSのメリットが消えてしまいます。

一定の不確実性を許容し、スピード優先でPDCAを回し続けるアジャイル的な進め方こそが最もSaaSに適した導入方法だと思います。

--------- ここから宣伝です🙏 ---------

CloudFitでは様々なSaaSをインテグレーションすることで、次世代型の業務システムを構築するサポートを行なっています。

SaaSのサービス選定から運用支援まで幅広く支援しておりますので、SaaS導入でお困りの方はぜひお問い合わせ下さい!

Twitterのフォローもよろしくお願いします🕊
https://twitter.com/y_senuuu

この記事が気に入ったらサポートをしてみませんか?