ポストSIビジネス：４つの戦略と９つのシナリオ（２）

先週紹介させて頂きました「第１象限：ビジネス同期化戦略」に続き、今日は、「第２象限：アプリケーション・プロフェッショナル戦略」を考えます。

第２象限：アプリケーション・プロフェッショナル戦略

「アプリケーション＋専門特化」の戦略です。従来型SIビジネスで培った業務ノウハウを活かし、専門特化することで競合との差別化を図ります。

特化型SaaS／PaaS

従来型SIビジネスやパッケージ製品の開発で培った業務ノウハウをクラウド・サービスとして提供するシナリオです。

「SaaS」は、業務アプリケーションをクラウド・サービスとして提供するもので、企業規模の大小にかかわらず多くの企業が参入しています。Worldwide Cloud Applications Market Forecast 2014-2018 2014.7によると、クラウドアプリケーションの2014年から2018年までの年平均成長率は、コンテンツ系が38.0%と最も高く、SCM（27.2%）、eCommerce（24.6%）と続いています。今後エンタープライズ・アプリケーションのSaaS需要は拡大してゆくことになり、サービス事業者もビジネス規模の拡大を狙い、この領域でのサービス充実を一層はかってゆくものと予想されます。

また、「PaaS」は、開発や実行環境を提供するものです。従来であれば、この環境を構築・運用するために多大な労力やコストを必要とし、高い専門スキル求められました。PaaSは、これら人的負担をなくし、開発や変更のスピードを担保するだけではなく、IoTや人口知能などの最新のテクノロジーを自社のシステムに組み込むことを容易にし、ITの利用価値を高めることが期待されます。IBMのBlueMixやHPのHelionなど、オープン・ソースであるCloud Foundryを基盤とするものや、MicrosoftのWindows Azure App ServiceやAWS、Salesforce.comのSalesforce1 Platform、Google App Engine、サイボーズのkitoneのように独自のサービスで囲い込みを図ろうとしているものがあります。

このように成長性が期待される領域ではあっても、汎用性の高いSaaSやPaaSは、「規模の経済」が有利に働きます。そこで、これまでシステム開発してきた経験とノウハウを活かせる専門領域に特化したSaaS／PaaSにビジネス・チャンスを見出すことが、現実的でしょう。

例えば、長年開発に携わってきたECサイトの構築ノウハウを活かし、商品の管理や紹介、決済や広告宣伝など、ECサービスに必要な機能をクラウド・サービスとして提供し、誰もが短期間でECサービスをはじめられるSaaS（Software as a Service：アプリケーションを提供するクラウド・サービス）や、そのSaaSの機能を自ら構築するWedサービスと連携させるためのAPI（Application Program Interface：SaaSの機能を他のアプリケーション・システムから呼び出し、利用できる仕組み）を提供するサービス、ECサイト構築のために必要となるデータベース機能や決済機能などを他のアプリケーション・サービスでも利用できるように機能モジュールを部品として提供するPaaS（Platform as a Service：アプリケーションの開発や実行、運用に必要な機能を提供するクラウド・サービス）などが、考えられます。

ECサービス以外にも、経費精算や決済、データ解析やレポーティング、店舗レジや在庫管理、オンライン研修やタレント・マネージメントなど、自分たちの積み上げてきた業務ノウハウを標準化・汎用化し、SaaSやAPI、PaaSとしてサービス提供するものです。

また、自ら提供するサービスを使って、ユーザーの要望に添ってアプリケーション・サービスを構築したり、既存の業務システムと連携させたりといったサービスも合わせて提供することで、案件規模を拡大することも考えられます。

このシナリオでは、同様のシステムを個別の受託開発する場合に比べて、工数需要を見込むことはできませんが、長期継続的に利用料収入を獲得することが可能になります。また、提供する機能の充実や関連するサービスの品揃えを増やすことで、利用料収入を拡大し、お客様の囲い込みを図ることができるようになります。

注意すべきは、標準化と汎用化の徹底と開発運用体制の刷新、UX（User Experience：ユーザーの使い勝手を追求したシステム作り）の追求です。

標準化と汎用化の徹底

市場のニーズやサービスの特性を考慮し、多くのユーザーで使用できるように標準化し、汎用性を高めることです。例えば、特定の顧客のために作ったアプリケーション・システムを他の顧客でも使えるはずだと、市場のニーズを考慮せずサービス提供しているケースがあります。このようなやり方では、開発対象となったお客様には満足であっても、他のお客様には、機能不足であったり、使い勝手が悪かったりと、満足を与えることができません。また、設定に自由度がなく、ユーザーの実情に柔軟に対応できないことで、汎用性を確保できない場合もあります。このようなやり方では、ユーザーを拡大することはできません。それとは逆に、滅多に使うことのない機能まで作り込んでしまえば、開発や保守にコストは掛かり、利便性も損なわれます。汎用性を意識したユーザー・ニーズの把握と求められるビジネス・プロセスに絞った優先順位の設定が、大切となります。

開発運用体制の刷新

クラウド・サービスは、本番システムの開発・保守と運用が、同時に進行します。機能変更の変更や追加も本番サービスを維持しながら行わなくてはなりません。また、トラブルへの対処には、即応できなくてはなりません。そのため、従来型の受託開発で広く使われてきたウォーターフォール型開発や開発者と運用者がそれぞれ独立して役割を担うやり方では、対応は困難です。そこで、次のような取り組みを志向する必要があります。

ビジネス上重要性の高い機能やプロセスを高品質で開発するためのアジャイル開発
変更や追加への柔軟性・迅速性を担保し障害を局限化するためのSOA/マイクロサービス
開発スピードと本番適用を同期化させるDevOps

従来のSIビジネスでは、関わることは少なかったかもしれませんが、これら新しい取り組みに果敢に挑み、ノウハウを蓄積してゆくことで、サービスの価値を高めて行く必要があります。

UXの追求

サービスでは、「何ができるか」といった機能要件だけではなく、「操作性やわかりやすさ」などの非機能要件が、ユーザーの獲得や維持にとって重要となります。従来型の受託開発でも重要ですが、コストや納期を守るために妥協してもらっても、ユーザーは、そのシステムを受け入れざるを得ません。しかし、多くのユーザーに使ってもらうサービスでは、そのような妥協は許されず、使い勝手が悪いとなれば、使ってもらえなかったり、途中で他のサービスに乗り換えられたりという事態も起こりかねません。

このような事態に対処するためには、実際のユーザーの使い方を徹底して観察し、使い勝手を徹底して追求しなくてはなりません。また、継続的に見直しを行い、改善を続けて行かなければなりません。そのためにも、前項で説明したような開発運用体制を築かなければならないのです。

【事例】ウイングアーク1st

ビジネス・サービス

お客様にシステムを使わせるのではなく、自らがシステムを使い、お客様にビジネス・サービスを提供するシナリオです。

これまでSI事業者は、「お客様にシステムを使わせること」で収益を上げてきました。例えば、システム開発、インフラ構築、運用管理・保守といった業務は、お客様がシステムを使うことを前提としたビジネスです。しかし、お客様が、求めていることは、そのシステムを使って業務上の必要を満たすことです。例えば、文書管理であれば、紙の文書をスキャンニングすること、検索や管理のためのメタデータをシステムに入力すること、紙の原本を安全に保管することなどが、業務上の必要です。その一切合切を一括してサービスとして提供することができれば、システム提供だけではできない大きな価値をお客様に提供できます。

つまり、システム・ソリューションの提供に留まるのではなく、そのシステム・ソリューションを自ら使って、ビジネス・ソリューションを提供すれば、案件規模の拡大や継続的利用によるストック収益の安定確保が期待できるのです。

特に独自性の乏しいコモディティ化した業務、例えば、経費精算、文書管理、給与計算などは、ビジネス上の付加価値を生みだしにくい一方で、経営上なくてはならない業務機能です。そのために多くの企業にニーズはあり、経費や人件費を削減したいとの思惑が強く働いています。また、サービスを提供する側から見れば、汎用的手順と標準的なシステムで対応しやすい分野です。

そこで、システム・サービスの提供と人的作業のアウトソーシング（BPO：Business Process Outsourcing）・サービスを一体として提供することで、お客様の需要を取り込むことが期待できます。

このシナリオを実践するためには、次の３つの要件が満たす必要があります。

ビジネス・プロセス・トランスフォーメーション

このサービスは、お客様の業務プロセス全体を引き受けるわけですから、該当する業務について、十分な見識が必要です。つまり、業務システムの開発経験だけではなく、その前提となる業務プロセスの設計や業務運用に関わるノウハウが、なくてはなりません。

また、他社が提供するシステム・サービス使うこともできますが、BPO部分だけを付加したとしても、決定的な差別化を生みだすことはできず、ビジネスを継続的に拡大させることは難しいでしょう。業務とシステムを一体のものと考え、両者の連携を前提としてプロセスそのものの変革（ビジネス・プロセス・トランスフォーメーション）を図り、効率と付加価値でイノベーションを起こすべく取り組むことが大切です。

開発に当たっては、パブリック・クラウド上のIaaSの上ではじめから開発することも考えられますが、開発工数の抑制と変更への迅速な対応を考え、PaaSやSaaSのAPIをうまく使うという選択肢もあります。

汎用性

サービス対象をコモディティ業務に絞ったとしても、細部に至っては各社のニーズは異なります。この需要に柔軟に応えるための汎用性は必要です。だからといって、考え得る全ての機能が、はじめから揃っている必要はありません。業務全体で大幅なコスト改善が図られ、これまでに無かった利便性などの付加価値を生みだすことが大切ですから、ビジネス上、最も大きな効果が期待できるプロセスから優先順位を定め機能を揃えてゆくといいでしょう。

また、APIの充実や広範な適用範囲をカバーするパラメーター設定といった、作り込みも汎用性を高めるためには必要です。

さらにサービス全体として、効率と付加価値を生みだせばいいわけですから、必ずしも全てをシステムに任せるのではなく、特殊な要望であれば、お客様に料金を負担してもらうことを前提に、人手による運用で対応することも考えられます。要望が多いようであれば、順次システム機能として実装し、コストの削減を図ること考えれば良いでしょう。

体制構築

全てを自社内で完結させる必要はありません。それぞれの業務で高い専門性を持つ企業とパートナーを組み、サービス品質とコスト効率を高めることを模索すべきです。例えば、文書管理サービスであれば、システムは自らが開発および運用管理を手がけ、メタデータの登録や原本の管理は、倉庫会社に任せるというような連携が効果的でしょう。

むしろ、積極的にパートナーとなる企業の新たなビジネス・モデルの創出に貢献し、双方にとって大きなメリットが享受できるシナリオを描くことが大切です。

【事例】NSSOL

業種・業務特化インテグレーション

業務における高度な専門的知識やノウハウがなければ、実現できないシステム開発に専門特化するシナリオです。

例えば、金融業におけるデリバティブ（金融派生商品）取引の場合、金融工学理論に基づく計算ロジックやアルゴリズム、グリッドコンピューティングやGPGPU等の高速化技術などについての専門的知識やノウハウがなければ、システムを構築することはできません。また、文書管理業務でも、法律文書や契約書などを扱う場合、その法的手続きや管理基準などの理解が必要です。

上記以外にも、業種や業務に関わる専門知識が求められるシステムがあります。その中でも、「しくみが複雑で高度な精緻さが求められる」、「高度な安心・安全が求められる」、「法律や制度と深くリンクしている」といった、実装の難しく、容易に競合他社が参入できない情報システムの受託開発を積極的に引き受け、高い利益率が確保しようというビジネスです。

当然のことではありますが、このような情報システムの開発は、高度な専門的知識を持つ人材や長きにわたる経験の蓄積に裏打ちされたノウハウが必要です。一朝一夕で実現できるものでありません。従って、できるだけ早期にターゲットを絞り、専門性の高いシステム開発を積極的にこなし、実績を蓄積することが大切です。

また、ノウハウをそこに関わるエンジニアの個人的スキルとして埋没させるのではなく、ビジネスを効率よくスケールさせるためにシステム部品やテンプレート、メソドロジーを整備することにも取り組む必要があります。

では、どのようにして自らの「専門領域」を定めれば良いのでしょうか。例えば、あるERPパッケージの構築や導入に実績がある場合は、ERPそのものについての知識やノウハウの蓄積があるはずです。そこで、この製品とノウハウを切り離して考えてみます。つまり、今扱っている製品は棚に上げ、これまで蓄積したノウハウをビジネスにすることを考えます。

そのノウハウを使って、高額で導入をためらう中堅あるいは中小の企業、しかも経験のある特定の業種や業務にターゲットを絞り込み、オープン・ソースのERPを使って、「XX業種の中小企業・XX業務」に特化して、積極的に売り込み、実績を重ねてノウハウに磨きをかけ、その領域における一番を目指すというシナリオが考えられます。