クラウドサービスとスクラッチの大きな違い 真逆の考え方の二つの会社

無事に転職をした会社は、これまでの会社とはまったく180度違う考えの会社でした。集団でものづくりをする会社と海外から仕入れたものを使って圧倒的な営業力で販売していく営業会社。
この二つの相反する部分でどのように自己を確立していくのかが、ここからの新しい旅路です。今回は、そんな悪戦苦闘する私を御覧ください。

聞いていた話と違うという結末

転職エージェント経由で転職してからの最初の2ヶ月は、新人と一緒にネットワークに関する勉強と検定取得に勤しんでいました。検定は苦手でしたが、このMCPCだけはちゃんと解け、無事検定を通過できました。

これで当初の目的は既に達成されてしまったわけだが、ここに来て大きな問題が立ちはだかりました。

これ大阪に行けと言われていたのですが、いく必要がなくなったので非常に残念です。その代わり、急遽発表になったスマートフォンの発売に合わせて社内は大混乱に陥りました。

これは今回に限った話ではなく、昔からこの会社に努めている人にとっては日常茶飯事であり、変化に対応できないものはすなわち死を意味するというダーウィンの進化論みたいな話が展開され、やっていく業務が面接と異なってしまいました。

さて、ここで重要なのが、自前のネットワークとアメリカの端末を買ってきて組み合わせて売るという発想は私の考え方にすごく近いと思いました。自社の強みと他社の強みを組み合わせれば3にも4にもなるという発想です。

自社で作るという概念が希薄な会社において、スクラッチ開発がもはや時代の潮流から取り残されているのかを分かる様に説明していきます。

クラウドサービスとスクラッチの大きな違い

前職においては業務をシステム化するためサービスを作る側でしたが、この会社ではサービスは使うものなので、A社のスマートフォンで稼働するクラウドサービス＝SaaSをセットで販売することになりました。

クラウドサービスは普及してしばらく経っているのでおわかりの方も多いと思いますが、簡単におさらいを載せておきます。

大きく分けると以下の二つになります。

例えば、IaaSは、以前紹介した私が作ったWebサービスの事故のように、急激なアクセスがあった場合にとても役に立ちます。

先に環境パッケージを作っておき、ある一定の指標に基づき、自動的に新しいサーバを立ち上げ分散処理を始めるようにしておけば、寝ていても勝手に問題は防げることになります。
もちろん、実際は人が張り付いて不測の事態に対処するのですが、ハードウェアが到着するまで何も出来ないということはもう起きないでしょう。
実際に、私の知人もテレビで自社サービスが取り上げられた時に監視しながら別サーバを立ち上げて置くなどをウェブ上でやっており、見事にワールドビジネスサテライト砲から守りきったところを見ました。
このように、現代のサービスにおいてIaaSは必要なものとなります。

ですが、IaaSを必要とするのはあくまでサービスを提供し、自社の業務アプリケーションが必要な会社だけになります。

そこで、最近流行っているのがSaaSです。SaaSは、インターネットで登録して月額利用料を支払うだけで、その瞬間から利用可能となります。お試し期間がたくさんある企業も多いので、無料で使ってから課金出来るフリーミアムというビジネスモデルを取っている企業も多いです。

このモデルも、以前お話した顧客管理台帳サービスがそれに当たります。
所有から利用へというのがここ最近のモデルとなります。パッケージソフトや昔のASPのように端末の環境依存に悩まされることもなくなりました。インターネットブラウザとJavaScriptが高度化したことで、よりリッチなウェブ体験を得られることが出来るようになったからです。

従来はこのインフラ構築／サービス開発を行う際に、要件定義から始まり、仕様策定、基本設計、詳細設計と続き、その後単体テスト、組合せテスト、運用テスト、総合テスト、ユーザーテスト、リリースと言う流れがありました。これらをほぼ全てすっ飛ばして導入することが出来ます。やるべきことは、ユーザーテストだけです。
もちろん、実際は基本設計が必要ですが、それも従来の基本設計をする時間よりも考える時間は圧倒的に少なくなりました。
なぜなら、既にある程度の形が決まっているため、それ以上の拡張が容易では無いからです。

拡張できるIaaS、拡張をさせないSaaS

インフラという特性上、IaaSは拡張することがありきでした。ただ、自社で抱えるサーバのお預かりはNGとなっており、移行作業がどうしても必要となります。映画「トランセンデンス」のように、その人格をすべてクラウドにアップロードしなければいけません。これを嫌がる顧客がまだまだ多いのは事実です。
しかし、クラウドにいち早くアップロードした企業は多大な恩恵を被っています。

• 大量の人員をハードウェアの保守のために雇わなくてよい
• モニタリングも専用のツールで検知し、保守業者に無駄な回線費用を払わなくてもよい

オンプレミスで自社導入していたときよりも、データセンターにまるごとお預かりさせていたときよりも、自分でコントロールでき、且つ、圧倒的なコストパフォーマンスが出るというのがIaaSの特徴でした。
逆に、SaaSはその特徴からユーザーが任意で拡張するということを許可してきませんでした。最近ではAPIやアドホック用の環境を用意する企業が増えてきたので横に連携させて使うということが増えてきたり、プラグインのようなもので代替えしたりすることが出来ましたが、基本的にシステム内部の拡張はベンダーにお願いしないと無理です。
ベンダーも1社の要望をすぐに取り入れることはありません。ここら辺はSaaSビジネスが流行るに従って、ベンダー＝【ユーザー企業の奴隷】から開放されたと言ってもいいでしょう。著作権を自社で持つということは自由にアップデート出来るという権利であり、自分たちが納得出来ないことは実装しないということになります。

もちろん、SaaSはサービスなので導入／切り替えが非常に楽です。

気に入らなければ圧倒いう間に乗り換えてしまえば良いわけですから、ユーザーとしてアップデート／カスタマイズが出来ないということは他社に乗り換えてもらって結構という宣言と捉えても良いでしょう。

つまり、パッケージソフトやスクラッチ開発からSaaSに変化したことは、ベンダーとユーザーの関係性を変えるものになったと思います。もちろん、サービス提供事業者は誠実にサービスを提供し続けなければいけませんが、その会社でしか使わない機能を実装しなければならないということはもう無くなり、世の中で使われる機能を理路整然と実装する事に注力することが出来るようになったとも言えるでしょう。
作るから使うに変わるということは、ソフトウェアサービスの根幹から変えてしまったとも言えます。

主権が入れ替わったことによる代償

もちろん、ベンダーにとってすべてが嬉しいことばかりではありません。完全に競争に巻き込まれてしまい顧客を一気に失うことにも繋がりかねないということです。
ユーザー不在のサービスを作った場合、その会社は8割方終わります。ユーザーが居ないため、サービス向上が望めないからです。言い換えるならば、顧客が欲しがるものを作るという基本原則に従う必要があります。
その顧客が欲しがるものを、インサイトする力がSaaSベンダーには求められます。
また、一度サービスを開始したらサステイナブル（持続可能であること）にしなければいけません。企業はゴーイング・コンサーン（継続企業の前提）の元に成立しているわけですから、提供事業者側も当然ゴーイング・コンサーンを大前提にすべてを設計しなければいけません。
昔から事業継続性という言葉はSIの中にはありましたが、あくまで特定の顧客の事業継続を指しており、自社の経営まで踏み込んでいませんでした。

また、ASP事業者もそこまで真剣にサービスの維持を考えていた所は少なかったと思います。あくまで、ソフトウェアのサーバ化ぐらいにしか考えていなかったと思います。そのため、サービスのSLAという言葉が実際に使われ始めたのは、2000年代後半だったと思います。
現代においては、サービスは簡単に作れますが、容易にサービス停止が出来ない状態に陥っており、顧客の情報資産、とくに、個人情報の取扱いをどうするのかがいつも議論の対象となります。ISO9001やISO14001などに準拠し内部体制を強化していくのか、コンプライアンスをどのよう強化していくのか等事業者としての本気度を問われるシチュエーションは年々増加しております。

クラウドサービス化が進んでも、全ては人

たしかに、底支えするIaaSが安価に高度化しオープンソースが拡大して開発コスト／参入障壁が下がったことにより、ベンチャーキャピタル等からの投資／起業コストの低廉化によるSaaSサービスの拡大は、同時に弱年齢化する起業家により、本質的なサービス実装がなされていないということも多いです。
逆に、シニア経営者だからこそ、きちんと丁寧な実装やサービス提供出来ているという点もあり、実際に販売や提供をする際にその創業者のバックグラウンドや哲学などをしっかりと見極める必要があります。

IT化が進んだとしても、すべては人に帰結します。人が人の営みを作るのは間違いなく、そこを疎かにしている企業のサービスは使う必要はありませんし、そうではな無い企業のサービスは率先的に利用していくべきだと考えます。
顔の見えるサービス、顔の見える経営をきちんと営んでいる企業こそ未来が明るいわけです。

まとめ

今回は、新しい会社で取り扱ったクラウドとそれまでやってきたスクラッチ開発について説明してきました。

次回からは、具体的に転職先では、どのような導入コンサルティングをおこなったのか説明したいと思います。