はい、今回はみんな大好き（大嫌い）SIerについての話である。

デジタル庁の動きに駆動されて、日本で何度目かの内製推進が盛り上がろうとしている。

日本のITシステム開発がうまく行かない原因としてしばしば挙げられるのが、ユーザサイド（非IT産業）にエンジニアやプログラマなどのIT人材が不足しているというものだ。確かに、日本が欧米と比較してIT企業にIT人材を集中的に配置しているのは事実である。

こうしたIT人材の偏りによって、アジリティの高い開発ができない、CI/CDやDevOpsが進まない、というのは当たっているし、ユーザ企業も自らIT人材を雇用して内製を進めるべきだ、という議論にはもう十年以上の歴史がある（筆者が追えていないだけでもっと古いかもしれない）。

この時、悪玉として批判にさらされるのが、今回の主役であるSIerという存在である。日本における内製推進は、しばしばSIer批判とセットになって提起される。実際、今回のデジタル庁関連の議論においても、結局は旧来の人月ビジネスに回帰するのではないかと懸念する声がある。

さて、ではそのSIerというのは何だろうか。「御用聞き」、「政商」、「お気楽な人月商売」といったクリシェによる批判が繰り返されるが、なぜそこまで批判されながらなくならないのだろうか。

実は、SIerというのは、その名前に反して「インテグレーション」が主要な機能ではない。というと言いすぎかもしれないが、少なくともそれだけではない。もし本当にユーザ企業がインテグレーションを行う機能だけ欲しいのなら準委任（SES）で業務委託を受ける企業はたくさんある（クラスメソッドなどが有名だ）。それらとは違うSIerという存在が必要とされるのはなぜか、という点を理解しないと、なぜ日本で内製や脱SIが何度も試みられながら進まなかったか、という問題の根幹を理解できない。

「SIerとは何か」を一言でいいあてるのは、実際のところかなり難しい。その理由は、SIerが複合的機能の集合体だからだ。筆者が見る限り、SIerの最も重要な機能は、人的資源、金融、保険の三分野におけるリスクテイカーであり、責任引き受け主体である。このSIerの機能を前提に日本の大規模なシステム開発のあらゆるスキームが構築されているため、簡単に廃棄できないのだ。

リスクテイカーとしてのSIer

三つの分野のうち、最も分かりやすいのは、「人間」という具体的な資源に関わるところだろう。SIerがIT人材を一括して雇用しているのは、究極的には日本の解雇規制が厳しいからである。公務員はもちろん、日本の民間企業の雇用規制は厳しく、平常時の指名解雇はまずできないし、事業悪化時の整理解雇にも厳しい条件が課せられている（整理解雇の四要件）。

こうした事情から、日本企業は労働者にジェネラリストを求める傾向が強く、ITのような専門性の高い人的リソースはSIerやITベンダにアウトソースすることに合理性がある。労働市場の流動性が高く、プロジェクト単位でエンジニアの雇用・解雇が可能な米国とは大きく異なる点である（SIer自身も結局は解雇規制の制約を受けてジェネラリストの集団になってしまった、というきらいもあるが）。

一方、金融と保険の機能は目に見えないため少し分かりにくい。SIerは、別に証券のような金融商品を売ったり貸金業者として融資をしているわけではない。しかし、大規模な開発プロジェクトの「プライム（元請け）」として立つことで、完成まで支払いが発生しない（時には数年に及ぶ）開発プロジェクトの間、多くのサブコントラクタ（下請け）企業に毎月報酬を支払う。いわば売掛と買掛のタイムラグによる時間非整合を埋め合わせているわけで、これはまさに金融の定義そのものである（注：コメントでも指摘いただいたが、現在はSIerもリスク低減のためフェージング契約を導入しているので、売掛の回収サイクルは昔より短くなっている）。

また、SIerが大規模案件を受注するときの請負契約は、システムの動作に問題があった場合に修正を義務付けたり、ユーザ側が損害賠償を起こす権利を認める契約不適合（むかしの瑕疵担保）や、引き渡しが遅れた場合に遅延損害金が発生するなど、請負業者がリスクを負う内容となっている。これはSIerから見ればいわゆる「炎上案件」が発生する原因であるが、発注側から見れば期待する品質が満たされなかった場合の「保険」として機能する。

世の中には、SIerが「今回のプロジェクトはリスクが大きい／見積もれない」と思ったときに入る保険が用意されており、これなど再保険の一種と呼んでいいだろう。

需要あるところ供給あり、である。そういえば、最近はAIの流行を受けて、こんな会話をよく耳にする：

SIer「今回ご紹介するAIソリューションの精度は95%です」
客「100%に満たないことによるリスクは御社が引き受けていただけますか」
SIer「ええ・・・」

ブラックジョークに類するものだ（と信じたい）が、SIerがリスク引き受け主体と思われていることを端的に表すエピソードである。

中間業者が保険や金融の機能を持つことでリスクヘッジを行うビジネスモデルは、IT産業だけでなく様々な業界で見られる。たとえば、出版の「取次（とりつぎ）」や流通の「卸（おろし）」がこのような機能を持っている。

取次を例に考えると、取次は出版社と書店の間に入って書籍の流通・配本を担当しているが、それだけでなく金融機能を持っている。というのも、出版社が作った本を受け取った取次は、いったんその本が全部（あるいは一部）売れたという仮定で代金を一括で出版社に支払うからだ。実際は、書店に並んでも売れなかった書籍は返品が認められているので、取次はその返品分の差額を後日出版社に回収にいく。これは実質的に、出版社が取次から無利子で融資を受けているのと同じである。この有利な条件の融資を利用して、出版社は書籍出版というリスクの高いビジネスを運営している（そして出版社は著者に対してどれだけ本が売れなくても最低印税を保証することで、保険機能を提供している）。

余談だが、現在、取次は苦境に立たされており廃業も相次いでいる。これは書籍市場の縮小もあるが、取次の金融機能をAmazonのような巨大書店がカバーし、さらに「買い切り」という形で書籍が売れなかった場合の保険までカバーするようになってきたからである。出版社としては、取次を介する意味が薄くなっているのだ。

流通の卸も、やはり金融機能と商品が売れなかった場合の代金未回収リスクを負担する「保険」機能を持っている。

卸売業の機能には①調達・販売②物流③金融・危険負担④情報提供――があります。・・・
③金融・危険負担機能
商品が消費者に購入される前の段階でメーカーに代金を支払い、メーカーが次の生産のために投資できるようにする金融機能と、最終的に商品が売れずに代金が回収できなかった場合の危険負担をする機能です。
（日本リサーチセンター「マーケティングがわかる辞典」）

このように、中間業者は物理的な商品の移動だけでなく、リスクを吸収する主体として機能している。これはSIerがユーザ企業と下請け企業の間で実現している機能と相似である。SIerも多くのエンジニアやプログラマを集めて一つのプロジェクトを構成するという点で「人材」という商品を移動させることで価値を発揮している。しかしそれにとどまらず、下請け企業への月々の人件費の支払い（金融）と、プロジェクトが失敗したときに損失を引き受ける（保険）という機能を持っている。

中間業者は、金融庁から貸金業や保険の免許を交付されているわけではないし、明示的に金融や保険の商品を売っているわけでもない。あくまで暗黙のリスクテイカーなので、その機能が意識されにくい。SIerの場合、自身も必ずしもリスクテイカーの看板を表立って掲げていないことも影響している。

かつてSIerは「ITゼネコン」と呼ばれていた時代がある。これはもちろん建設業界におけるゼネラル・コントラクタ―（総合請負業者）の名前を借りてきたものだ（言うまでもなく、ゼネコンは日本最大級のリスクテイカーだ）。この名前も抽象的ではあるが、インテグレーションにとどまらない複合的機能を持っているという含意がある点でより適切だと思うのだが、おそらくゼネコンが全国的にバッシングを受けた時代（コンクリートから人へ）に、悪いイメージが飛び火するのを恐れて洋風の「システムインテグレータ」という名前に鞍替えしたことが、分かりにくさに拍車をかけたのではないだろうか。

ともあれ、SIerがリスクテイカーであるということは、必然的にSIerが巨大企業であることを必要とする。SIerが大企業揃いなのは「巨悪」イメージの醸成に一役買っているが、現実問題として、案件が一つ炎上したくらいで破綻していたら話にならない。大数の法則が働くくらい多くの案件を抱えてリスクを平準化するには、大きくないといけないのだ。保険会社や銀行がある程度の規模を持たないと機能しないのと同じである。中小SIerというのは語義矛盾である。仮に誕生したとしても、安定的に存在しえないので観測できない。あるいは本当に「インテグレーション」の機能だけ担ってリスクは負わないというビジネスモデルも考えられるが、それなら準委任（SES）による業務委託で十分である。冒頭でも述べたように、そういう会社は日本にもたくさんある。内製を積極的に行う企業はSESを活用しているし、SIerやITベンダにも同じような期待が持たれている。

スラムダンクに喩えれば、SIerは仙道ではなく魚住なのだ。

「そのデカい体は、リスクを抱えるためにあるんだっ！！」
（山王戦の名場面を思い浮かべながら読んでほしい）

面白いことに、当のSIerの社員は、自分たちの仕事がリスクテイキングだということをあまり意識していないフシがある。大規模案件の見積もりでもやれば否応なしに自覚させられるが、一般にSIerに入社するのは、外資やスタートアップに行く人間に比べればリスクを取らない、チャレンジしないタイプの人間だというイメージがある（よね？）。それに反してコア業務が巨大なリスクテイキングだというのはなんだか可笑しな気もするが、このギャップは笑い事ではなく、SIerの社員が心身を病む一因になっている。SIerのリスクテイク機能は、「ケツ持ち」とか「殴られるのも仕事のうち」というラフな表現で非公式に現場で共有されるにとどまっており、金融業のようにリスクヘッジの方法論を発展させることがなかったのは、その機能を暗黙のものとして持ってしまった中間業者ゆえの困難かもしれない。

SIerは何であるべきなのか ― MSPへの道

時間単位で人間を提供することに依存していたSIerの伝統的な役割は急速に衰退し、様々なas-a-Serviceアプローチに基づくビジネスモデルに取って代わられつつある。
　―― The Evolving Role of the Systems Integrator, Washington Technology

上で見たように、SIerというのは単にシステムのインテグレーションを行うだけの存在ではなく、少なくとも三つの分野においてリスクを引き受ける主体となっている。もし日本政府および企業が内製を進めることで徐々にSIerの機能を縮小していく ―― 最終的には廃棄する ―― 場合、どのような光景が出現するだろうか。これを考えるうえで参考になるのは、やはり米国の事例である。理由は、米国は伝統的にSIerの機能が小さく、しかも近年その縮小傾向に拍車がかかっており、米国のSIerも新たなビジネスモデルへのシフトを迫られているからである。

よく勘違いされるが、米国にSIやSIerが存在しないわけではない。米国で「私はシステム・インテグレーターで働いている」と言っても「それは何だ」と聞き返されることはない。政府や大企業のシステム開発においてプライム・コントラクターとして仕事を請ける企業も存在する。日本と違うのは、こうした役割をMicorosoftやAmazon、IBMといった日本では主に物販が中心のITベンダも担うことと、相対的にユーザサイドにエンジニアやプロジェクトマネージャ、ITアナリストなどの人的リソースが豊富に存在しており、SIerの役割が小さく、大きなリスクテイクが求められないことである。文字通り「インテグレーション」が主要機能である（そのため、中小SIerというのも珍しくない）。ちゃんと名が体を表しているのだ。

現在、米国のSIerは大きな岐路に立たされている。それは、クラウドシフトとサービス化の進展によって、インテグレーションがどんどん縮小しているからである。もともとパッケージ文化が強く、企業や政府が内製を好む土壌のある米国では、SaaS/PaaSの浸透が非常に早く、旧来のSIerがリセラーかマイグレくらいしかやることがなくなっている。この危機感をトリガーとして登場してきたビジネスモデルがMSP（Managed Service Provider）である。

GartnerのMSP Magic Quadrant

MSPという言葉自体は1990年代からあり、ほぼASPと同義で使われていたが、最近はSIerが単なるクラウドのリセラーを超えて自分たちの付加価値を再定義する言葉として使われるようになっている。一言でいうなら、

クラウドサービスのパッケージ + 人月サービス

である。米国では多くの業務パッケージベンダ（Adobe, Oracle, Microsoft等）がSaaSシフトに舵を切っており、スタートアップ界隈でもSalesforceを皮切りにサービスモデルで大きな成功を収めた企業は枚挙にいとまない。そのため、一芸特化のX-as-a-Serviceは百花繚乱の様相である。そうしたサービス群をパッケージングして、導入コンサルや運用の人月サービスを付加していく、というのがMSPである。MSPも、その出自に応じて個性があり、インフラから業務レイヤ、運用からAI、No CodeにAPI連携まで多種多様だが、個々の企業の特色に踏み込むことは割愛する。SIer自身のサービスプロバイダ化という大きなトレンドがある、ということだけ抑えてもらえればいい。

この傾向が強まると、旧来のSIの仕事は減少していくが、そのぶん、ユーザ側が引き受けるべきタスクと責任が増えてくる。いわゆる日本で従来言われたような「丸投げ」ということは出来なくなり、逆にユーザサイドの責任が大きくなってくる。たとえば、米国連邦政府のCIOオフィスは、クラウド活用戦略における政府機関と請負業者の責任分担について、以下のような方針を出している。

第二に、行政機関の長は、企業のリスクを管理する責任があり、その責任は、請負業者が運用するシステムであろうとも、行政機関の長が負う。クラウドサービスを利用する際の重要な要素は、CSPがどのようなサービスをどのようなレベルで提供するのかを明確にすることである。したがって、CSPとの関係を通じた効果的なリスク管理を促進するために、政府機関は、役割と責任を明確にし、明確なパフォーマンス指標を確立し、コンプライアンス違反の是正計画を実施すべきである。

(Second, heads of executive agencies are accountable for managing the risk to their enterprises, and that responsibility remains with the agency head even with respect to contractor-operated systems. An important element of acquiring cloud services is clarity in what services a cloud provider performs and at what level. Therefore, to facilitate effective risk management by way of their relationships with commercial cloud service providers, agencies should granularly articulate roles and responsibilities, establish clear performance metrics, and implement remediation plans for non-compliance. )

U.S. Federal Government CIO Office - Federal Cloud Computing Strategy

請負業者が運用するシステム（contractor-operated systems）というのは、CSPやMSPが提供する各種クラウドサービスを指している。そうしたサービスを利用する場合、最終的に品質に責任を負うのは政府機関側である、ということを明記しているのである。「丸投げするなよ」とわざわざ釘を刺しているのだ。日本の丸投げスキームに慣れた身からすると、かなり思い切った責任分界に見えないだろうか。

2020年11月、東京証券取引所がシステム障害で取引を停止した際、記者会見で東証の社長は「障害の責任は富士通だけでなく、当社にもある」という発言をしたことが大きな感動を（主にエンジニアの間で）呼んだ。

この発言にみんなが感動したのは、日本のエンジニアは障害時にユーザ企業から詰められたり土下座を要求されることはあっても、かばってもらえることはないからである。

こうしたユーザサイドがシステムの品質に最終責任を負うスキームは、米国では政府だけでなく民間企業においても珍しくない。2019年に米銀のCapital OneがAWS上に構築した自社システムから大量の個人情報を漏洩させるという史上最大規模のインシデントを起こした際、規制当局から責任を問われ制裁金を課されたのは、Capital One自身であり、AWSや他のサードパーティが責任を負うことはなかった。AWSのようなCSPは、責任共有モデルによって自社とユーザとの間で責任分界を定めており、自社が責任を負う範囲についてもSLAを明確に決めている。そのSLAの範囲内でどれだけ障害やインシデントが起きようとも賠償には応じない。SIerがMSP化する潮流の行きつく形は、あらゆるMSPがこうした責任分界とSLAを定めてそれ以上の責任を負うことを放棄するという世界であり、そこでは常にユーザが最後の責任主体となる。みんな覚悟はできてるか？ オレはできてる。

もちろん、責任と能力はバランスするものであるため、このような責任分担の再配置を実現するには、ユーザサイドに人的リソースを増強する必要がある（現在の日本は逆に、ユーザサイドにほとんどITケーパビリティがないことが、かえって消費主体に甘んじる口実になっている、という見方も出来る）。冒頭でも述べたように、それが現在デジタル庁が人材にフォーカスしている理由であろうし、決して焦点は間違っていないと思う。解雇規制の強さや給与体系の硬直性など法規制にまで踏み込まないと解決の難しい問題ではあるが、いつか突破しなければならない隘路なのも事実である。

政府の人的リソースについていえば、日本はそもそも政府職員の絶対数が少なすぎるのである。「小さな政府」という米国人が政府に求めるスローガンを聞いたことがあると思うが、あんなの嘘っぱちである。米国連邦政府は、職人200万人を超える巨大組織であり、エンジニアだけでも数万人を雇用している。年間のIT予算は驚異の10超円に迫る勢いである（日本政府の10倍）。

内閣府 - 公務員数の国際比較に関する調査

一国の政府システムの内製というのはこれくらいのリソースがバックボーンにあって初めて成り立つ（これだけのリソースを抱える米国ですら必ずしも順調なわけではない）。非正規雇用と出向でお茶を濁せるレベルではなく、相応の”覚悟”が求められる―― 特に解雇規制の強い日本では ―― 話である。精神論のようになって恐縮だが、最後は政府と企業にその覚悟があるか、という話になる。

以上、「SIerとは何か、今後何になるべきか」という問いについて、リスクテイカーという側面に光を当てて考えてみた。筆者が見落としている観点や事実認識が間違っている点もあるかもしれない。その場合はご教示いただければ幸いである。

SIerの置かれている立場は客観的に見ても厳しいものであり、今後もバラ色の展望が開けているとは到底言えないが、「自分の仕事は一体何なのだろう」、「これからSIerはどうしていけばいいのだろう」と悩んでいる「中の人」が心と頭を整理する一助になれば本稿の目的は達せられたと思う。

ハッピー・ホリデイ。

2020/12/25 追記：本稿では、リスク対応というSIerの受動的な役割に光を当てたが、SIerの成立時には積極的意義も期待されていたはずである。すなわち、IT人材とナレッジの集約による高度な価値創出とスケールメリットによる効率化である。この期待にSIerがなぜ応えられなかったのか、というのは、それ自体が大きな問いである。おそらくここでも解雇規制の強さが根本原因の気はしているが、いつかまた整理して書きたいと思う。