フルクラウド時代にどのようにIT投資は妥当だと判断すべきか

こんにちは、freee 株式会社で CISO 兼 CIO をやっております。土佐です。

この記事は、裏freee developers Advent Calendar 2018 の 11日目の記事です。

当社は、クラウド会計freeeや人事労務freeeといったクラウドサービスをスモールビジネスのお客様向けに提供する会社です。クラウドサービスを提供する以上、我々自身もクラウドワークスタイルを体現しなければならないという、暗黙の認識が当社には存在していて、社内ITツールとして利用するもののほとんど全てが クラウドツール(SaaS)です。

クラウドツールを前提にした、IT投資の判断はそれまでのものとは異なるところがいくつもあります。それを踏まえて、クラウドツールの投資判断はどのようにすべきか、当社の経験から導き出された考えをご紹介したいと思います。

クラウドツールになってIT投資は何が変わったか

クラウドツールが当たり前になる前、IT投資といえば、何かパッケージソフトを購入してどこかのサーバに構築するとか、社内外のエンジニアリソースを活用して独自ツールを開発するというものでした。こうしたクラウド以前のIT投資とクラウドツールに対するIT投資は、何が違うのでしょうか。

初期投資が安く、すぐに利用できる

クラウドツールを利用する最大のメリットと言えるでしょう。

これまでのIT投資は、システム構築やライセンス購入に関わる大きな初期投資が必要でした。当然、投資判断に関わるステークホルダーも大きくなるし、社内のより上位のポジションの人が決裁者になります。それに伴って、投資判断に関わる時間もコストも大きくなります。

クラウドツールであれば、数アカウントだけ購入して、社内の一部で試して評価してみて、ダメそうなら契約更新しなければいいし、良さそうなら少しずつ社内の利用範囲を拡大していく、というような初期導入プロセスがとれます。コストも安いので、現場判断だけですぐにスタートできるわけです。

アップグレード対応を考えなくていい

これまでは、パッケージ製品であればアップデート版の取り込みにかかるライセンス料やシステム開発・保守コストが発生したり、独自開発であれば新機能のための開発工数が発生したりしていました。

クラウドツールの多くはサブスクリプションとなっており、月額あるいは年額で一定の金額を支払っていれば、その範囲でどんどん機能がアップデートされていきます。法制対応が必要な業務のためのツールであれば、このメリットはことさら大きく感じることができるでしょう。

EOS/EOLを気にしなくていい

これまでのIT投資では、導入しているツールの現在のバージョンに対する、EOS(End of Sales:販売終了。新機能は開発されなくなる)や、EOL(End of Life:サポート終了。脆弱性があったとしても修正は提供されなくなる)は大きな悩みの一つで、常に EOS/EOL の時期を意識し、管理しつつ、それに伴うアップデートのための工数や予算を長期に渡って確保しておかないといけませんでした。

クラウドツールであれば、これを意識することは全くありません。(私自身、この記事を書きながら、久々にこの単語を思い出しました。)

ベンダーに「カスタマーサクセス」への取り組みが宿命づけられている

初期導入がしやすいというのが最大のメリットと前述しましたが、それは表面的なもので、本質的に最大のメリットは、このカスタマーサクセスにあると思います。

これまでのIT投資で購入していたものは、いわゆる買い切りのものが多く、サービス・製品の品質は、購入時点でMAXに到達することが求められました。それに対してクラウドツールは購入時点がスタートで、そこから向上していくことが必要になります。なぜなら、クラウドツールは顧客に使われ続けなければならず、さもなければすぐに使うのを辞められる、あるいは乗り換えられてしまいます。

この「使われ続ける」ために、クラウドツールのベンダーは顧客に「サクセス」してもらわないといけないのです。つまり、そのツールを使うことによるメリットを享受させ続けなければならず、ベンダーはそのための努力を強制されるわけです。

これは、クラウドツールに宿命づけられたものであり、クラウドツールの本質的にもっとも大きなメリットと言えるでしょう。

ツール利用組織規模の変遷を考慮した長期的な投資規模の想定が必要

初期導入がしやすいというのがメリットを前述しましたが、初期導入後、利用範囲を拡大していけば、それに合わせて大きなコストになってくるのは当然です。初期導入や、アカウント追加等のそれぞれのタイミングでは大きな金額にならないので、決裁テーブルの隙間を縫うように、きちんとした投資判断タイミングを逃れてしまうということもあり得ます。

また、規模が急拡大する組織でも同様なことが言えて、導入当初ではそこまで大きな金額に見えなくなったけど、数年経った今、やたらコストパフォーマンスの悪いツールに映る、ということもあります。

これを避けるためには、初期投資額に惑わされることなく、長期的に投資規模を見ていく必要があります。しかし、初期導入のしやすさというメリットを失うのは本末転倒です。このどちらもを両立させる、ITガバナンスが求められるのです。

資産計上できなくなる

特にクラウドツールの利用にシフトして行こうとする企業にとっては重い問題になるかもしれません。

これまでのIT投資では、ライセンス購入やシステム開発が発生していて、財務的に資産として計上されていました。そうなると、初期投資年度では費用として扱われる金額は少なく、減価償却によって費用は数年にならされます。

一方でクラウドツールはサブスクリプションである場合が多く、そのコストを資産に計上することはまずないのではないでしょうか。もちろん、年単位のコスト自体が小さくなるので、これまで資産計上していた全てが費用計上されるというわけではないでしょうが、財務的な費用としては、これまでよりも高くなるという場面も出てくるかもしれません。

業務をツールに合わせることが大事になる

クラウドツールの多くはカスタマイズ機能を持っていません。よしんば持っていたとしても、クラウドツール自体のアップデートに素直に追随していくために、カスタマイズは本当に最小限にしないといけません。

これまでのIT投資では既存の業務をシステム化するということが多かったと思いますが、そうなると、業務にツールを合わせるのではなく、ツールに業務を合わせることが重要になります。

どうしたらクラウドツールへの投資妥当性を適切に判断できるのか

前述の、これまでのIT投資とクラウドツールへの投資との比較を踏まえ、投資判断をどのようにすべきかあげていきたいと思います。この中には、当社が既に実践できているものも、まだアイディアベースのものもありますので、その点ご了承ください。

投資妥当性判断チェックポイントを設ける

前述した通り、クラウドツールは初期投資が小さいがために、導入時点できちんとした投資判断が行われず、そのくせ気づいたら結構大きな額になる、ということがよくあります。一方で、初期導入をコストかけず現場判断で行うということもとても大事です。

それを両立するには、長期的な投資判断チェックポイントを設けるべきだと考えています。

つまり、初期導入時には、金額規模に合わせた投資判断しか行わないけど、導入拡大計画の提出を求め、その中で「この時期にこの程度導入範囲を拡大する」というチェックポイントを設置し、そのチェックポイントの中で改めて、トータルの投資規模に合わせた投資判断を行うということです。

このためには、投資規模に関わらず現場でクローズさせない投資判断プロセスや、各ツールの長期的な導入状況のトラッキングが必要になります。

財務への影響を意識する

前述の資産計上できない、の件です。財務チームとの連携を忘れずにしておきましょう。

クラウドツールのコスパカーブを知る

これはあくまでも感覚的なものですが、クラウドツールのコストパフォーマンスには、運営企業の時価総額規模に応じて傾向があって、以下の図のような感じになると考えています。

f:id:teppei-studio:20181210230733p:plain
コスパカーブ

時価総額が数十億円規模以下の場合、コスパはそこそこです。ただ、提供する価値自体もそこまで大きなものではなく、なんか自前開発でもそこそこ作れそうだけど、真面目にコスト比較するとやっぱり自前開発よりはだいぶ安い、みたいな感覚です。ただし、社内で使うクラウドツールのコスト分布的には「ロングテール」になるので、「ちりつも」に要注意です。

そこから、時価総額が 数百〜数千億円規模になると、コスパが相対的に悪くなります。しかし、提供する業務範囲というか、その価値は大きいので、簡単に何か他のもので代替しようにもできず、負担感としては大きなものになってきます。ここの投資判断にはコストをかけてしっかり行っていく必要があるでしょう。

時価総額が兆円規模になると、王者の貫禄というか、圧倒的なコストパフォーマンスとなり、ごちゃごちゃ考えずに身を委ねてしまえという気持ちになります。その代表格が G Suite ですね。

APIの充足度を必要に応じて考慮する

ツールに業務を合わせていく必要があると前述しましたが、どうしても「かゆいところに手が届かない」場面が出てくることがあります。とはいえカスタマイズはできないので、そのツールでAPIが提供されていることが大事になってきます。

クラウドツールの導入にあたっては、今後の必要性を想像しつつ、API機能提供の充足度についても確認しておくべきでしょう。

格納情報に応じたセキュリティ要件を決めておく

クラウドツールは、あるがままの機能を利用するしかありませんので、自社のセキュリティポリシーに準じた一律のセキュリティ機能を要求するというわけにはいきません。そのため、クラウドツールへの格納情報のセキュリティレベルに応じて、あらかじめセキュリティ機能要件を決めておくと、便利だと思います。

ツールの根底にある「思想」を把握する

繰り返しになりますが、クラウドツールについては、ルールに業務を合わせていく必要があります。

このために、ツールの仕様をよく理解することはもちろん大事ですが、ツールの根底に流れる「思想」をよく理解し、今後の機能追加も含めてどのようなコンセプトで機能が追加されるのか、それらの機能はどういうユーザを想定しているものなのか、自分たちはそこの想定ユーザ像にどれだけマッチするのかをよく考える必要があります。

GYOMUハック人材を揃える

ここまで見てきたように、フルクラウド時代のシステム部要員に求められる役割も変わってきます。

これまでは、業務の現状をよく理解し、ベンダーコントロールをうまく行い、システム構築を推進していくことが求められました。しかし、フルクラウド時代においては、自社の業務とクラウドツールの思想のマッチングをしっかり考えたり、その上で、クラウドツールの選定を行ったり、自社業務の変更を推進したりする必要があります。あるいは時にはAPIなどを利用して、クラウドツールを拡張させる形で、ソリューション全体としてのカスタマイズが必要になります。

当社では3年以上前から GYOMUハッカー というポジションを設置し、まさにそのような取り組みをそこで担ってきました。フルクラウド時代への変遷に伴い、システム部要員の素養も変わりつつあるのだと思います。

まとめ

このようにクラウドツールへの投資は、これまでのiT投資には無い特徴があり、それを踏まえた投資妥当性判断ができるような体制が必要になります。

GYOMUハッカー募集中

freeeでは、一緒にGYOMUハックしてくれる仲間を募集中です。フルクラウド時代の新しいシステム部門を共に創っていきましょう!

次回

明日は、社内随一の好感ハッカー、スーパーマサキです。 お楽しみに!