DXの波で企業はシステムの内製が必要だ、SIは不要。SaaSがSIを代替しつくす等々の話題がよく出ています。果たしてそれは正しいのでしょうか。
私のスタンスとしてSIerに寄っているわけではないのですが、表面的で加熱気味なSIer不要論が出てきており、少々技術屋として口を出したくなりました。技術戦略上、どのような特性を持つのかきちんと考察してみます。
業務システム開発をする当事者のための1つの指針になれば幸いです。
業務システムを開発するにあたっての３形態
業務システム開発手法について、内製エンジニアによる開発、SIerへの委託、SaaSソフトウェアの導入の3つの形態があります。三者三様ですが、多くの企業において、SIerへの委託が盛んに行われてきました。エンジニア採用を行ってきた大企業には、SI企業としてグループ企業に分離することも多く、この場合の開発手法ではプロフィットセンターが分かれているため内製ではなくSIerへの委託として考えます。
昨今はSIerへの委託ではなく内製を進めよう、SaaSをもっと活用しようという論が出てきています。（SaaSというのも曖昧な概念ですが、後ほど記述します）
これらについて各開発手法を概観していきます。
3つの開発形態のメリット・デメリット
「内製エンジニアによる開発」は最上級のオプション
内製エンジニアによる開発のメリットは、スピード感を持ってシステム開発・改修ができることです。アジャイル開発手法についても採用することが容易になるでしょう。また、自社内にエンジニアを雇用するためノウハウが失われづらく、形式知化していくことも他の手法と比べると容易です。内製化することで必要なシステムやサービス企画なども立てやすいかと思います。
デメリットとしては、システム開発のない時期にできる仕事がないことです。保守作業などはありますが、基幹システム開発に携わったことがあるとわかるのですが、5年に一度ほど大きな更改があり、この様な時期だけ多くの人員が必要になります。システム部は15人ほどでも、基幹システム更改のために月200人ほどが数年間必要といった状況を経験したことがあります。
特定時期だけ人員が必要という形態は、日本企業の雇用では向いていません。簡単に解雇ができないため、大きな更改のために一時的に人員を雇用しても、更改が終わった後の仕事がなければ、仕事のない人員を雇用し続けるという事態が発生します。電話をかけて「FIRED」と宣言したら解雇できる国とは事情が違うと思います。
こちらの雇用の問題については、Japan Degital Design CTOの楠さんが詳しく書いています。
「SIerへの委託による開発」は雇用しなくても細かく要件を注文できる代替策
SIerへの委託メリットは、必要な時に一時的にエンジニア人員を集められることです。先に述べた一時的に必要な人材を、正式に雇用することがなく収集可能です。また、SIerに必要なシステム要件を細かく依頼し、導入のサポートなども委託することができます。
デメリットとしては、発注者がシステムや技術についてわかっていないと、レモン市場が起きて作られるシステムの目利きができないことがあります。基幹システムの導入成功率は30％とも40%ともいわれます。満足しないシステムが作られる確率が60%だか70%だかとあるということです。2020年には官公庁が委託したシステムに問題があり、官公庁の発注能力が問われました。また、内部にナレッジが蓄積されず、ベンダーロックインといった事態も起きえます。
「SaaSソフトウェアの導入」は低コストでスケールメリットを得る選択肢
SaaSソフトウェアというと新しい概念のように思われますが、本質的にはERPパッケージと同様だと考えています。多くのユーザーに導入することで、共通要件を提供してスケールメリットを活かす形態です。また、クラウドで提供することで素早い改善を行っていきます。それ故、SaaSソフトウェアの導入メリットは、提供する開発組織が強靭であるほど、どんどん機能が追加されてスケールメリットを享受できます。それこそ非常に低コストで大きなメリットを受け取ることが可能です。
デメリットはメリットの裏返しで外部にコントロール性を任せることにあります。SaaSソフトウェアの内部はユーザーからするとわからないため、本当の意味でコントローラブルではない点ではあります。基幹システムの間に組み込むなどの都合で事細かにロジックをカスタマイズしたりテストすることに制限はあります。また、業務に必要なデータを掴まれるとロックインの可能性があります。ソフトウェアに蓄積されたデータがCSVやAPIで出力できないと、他ソフトウェアへの移行が難しくなり、選択肢が減ることになります。
3つの開発形態はサービスレベルで分類できる
カスタマーサクセスの考え方ですが、ハイタッチ・ミッドタッチ・テックタッチという分類があります。サービスレベルを以下3つに分解して、ユーザーが必要とするレベルをそれぞれ提供します。
- ハイタッチ - 個社単位で手厚いカスタマイズされたサービスの提供。コストが高い
- ミッドタッチ - 複数企業に対してパッケージ化されたサービスの提供。コストは中程度
- テックタッチ - テクノロジーを利用して自動化されたサービスを多くの企業の提供。コストは低い
これを、3つの開発手法に当てはめて考えてみます。
まず、「内製エンジニアによる開発」は究極のハイタッチです。必要な業務システム、基幹システムを好きなように迅速に開発できます。常時雇用コストを払い、組織の内部にノウハウを蓄積することで新たなシステム企画やサービス戦略を考えやすくする土台を作りやすいはずです。
「SIerへの委託」は、カスタマイズしてシステムを発注するハイタッチが可能です。また、開発だけでなく導入や使い方の教育なども委託できます。障害や不具合があったとき、依頼すれば解決してくれます。常時雇用ほどではないものの、ハイタッチには変わりありません。ERPパッケージの導入を委託するなど、すでにあるソリューションを複数社に提供する場合はミッドタッチ的な動きもあるでしょう。
「SaaSの導入」は様々なSaaSがありますが、多くの場合、ミッドタッチからテックタッチに該当します。常時サポートを依頼するほどではなく、細かな個社カスタマイズもできませんが、コストについて圧倒的にメリットが出ます。例えば会計freeeをスクラッチで作ろうとした場合、1億やそこらでは足りないでしょうが、上位のプロフェッショナルプランでも月39,800円から利用できます。
※エンタープライズのユーザー向けにSI機能を持ってハイタッチなサービスレベルを提供することはあります。
「ソフトウェアの入れやすさ」の４象限
さて、内製・SI・SaaSのどれを選択するべきなのかという問いに立ち返ります。既にみた通り、ドメイン領域や個社事情によって必要なサービスレベルは異なります。強いベンダーロックイン要素や透明性要件がなく、安価でメリットがあるならばSaaSを利用すれば良いかと思います。
一方で、様々な状況制限やノウハウ提供者としての役割を求める場合、SIerへの委託も選択肢に上がるでしょう。
「結合度」と「ミッションクリティカル性」の２軸
SaaSソフトウェアを入れやすい領域、SI・内製機能が求められる領域を分類するための軸を考えます。
1つは、「密結合」・「疎結合」の軸です。基幹システムには、販売管理（受注システム・売上システムetc）・生産管理・購買管理・在庫管理・会計・人事労務…といった領域があります。会計・人事労務といった領域はバックオフィス業務で他システムとのつながりが比較的少なく、疎結合です。一方、販売管理・生産管理・購買管理といった領域は多くのシステムと関連し合い、密結合になりがちです。このような場合、圧倒的に疎結合な方がソフトウェアを入れる難易度が低くなります。密結合であれば、他の関連システムとの接続面の現状分析やカスタマイズなどが必要になることもあり、SIまたは内製機能が求められます。
もう1つは「ミッションクリティカル」・「ノンミッションクリティカル」の軸です。そのシステムに障害があった場合、企業活動に大きな影響を及ぼす、高いサービスレベルを求められるのであればありもののソフトウェアを入れるハードルは高くなります。ミッションクリティカル性が高いほどSLAを求められ、内製となる判断もあるでしょう。
疎結合でミッションクリティカルでないほど、ソフトウェアは入れやすい
2つの軸を引いて、ソフトウェアの入れやすさを４象限にした図です。③→②→④→①の順にソフトウェアを入れやすいはずです。
右上の①は最もミッションクリティカルで、例えば20分も販売管理の実行系システム（受注など）が止まると注文が受けられず大きな障害になります。
②はミッションクリティカルですが、疎結合なためSaaS採用もしやすい。
③は疎結合で、かつ①、②と比べると比較的ミッションクリティカルではないので、最もSaaSを入れやすい領域です。（前提として、会計や人事システムも止まるべきではない重要なものですが、販売管理などと比べると比較的要件は緩和されます）
④は密結合なため、現状整理のためにSI・内製機能が求められますが、比較的ノンミッションクリティカルなため、トライがしやすい領域です。
実際に存在するSaaSのロゴで思いついたものをのせてみましたが、やはり左下が圧倒的に多く、右上はあまり出てきませんでした。
SaaSの採用といった点については上記の図が参考になればと思います。
①、④の象限としてSIを利用するか、内製にするか。ここは各社の戦略や懐事情などにもよりますが、発注能力の確保という点でも、腕の良い内製エンジニア要員はいた方が良いと考えています。大きなプロジェクトが走り、一時的に多くのリソースが必要な場合、SIへの依頼は発生することもあるでしょう。そのとき、業務の分解ができ技術にも明るいエンジニア人材がいると、SIへの依頼を行うにしてもクオリティが上がるはずです。
まとめ: 「コアは内製、ノンコアはSaaS」の意
「コアは内製、ノンコアはSaaS」とはよく言われます。システム戦略としてのコア・ノンコアに加えて、「ソフトウェアの入れやすさ」の象限を整理しました。これによりSaaSを採用しやすい領域を整理しています。
青の領域、緑の領域といったところはSaaSが増えていくでしょう。一方で、赤の領域についてはSI機能が必要だと思います。パランティアのような、政府向けのゴリゴリのSIer企業がユニコーンとなっていることからも、４象限の赤い領域に挑む型としての正しさはあるのではないかと考えています。
SIerは消える、不要といった論はこれからも強いでしょうが、「SIとしての機能」は依然必要です。一部は内製化やSaaS企業に取り込まれるといった形はあるかもしれませんが、優秀なSIerは早くからERPパッケージの開発をしてSaaS的なシェアの取り方をしているのでSIとSaaSの垣根がなくなっていくのかもしれません。
過去のサービスレベルに関する記事
よければTwitterフォローをお願いします https://twitter.com/naomasabit
![情シス・IT担当者[必携] システム発注から導入までを成功させる90の鉄則](https://m.media-amazon.com/images/I/51YKHxkX4jL._SL500_.jpg "情シス・IT担当者[必携] システム発注から導入までを成功させる90の鉄則")
