大手SIerからITスタートアップに転職して6年経ってわかった、日本のシステム開発がつらい6つの理由
どうも、エンジニアのgamiです。
僕は2016年に富士通という大手SIerのSEを辞め、SaaSプロダクトを提供するITスタートアップに転職しました。富士通にいた期間は短いですが、大企業とスタートアップ、受託開発とサービスベンダー、それぞれの立場でソフトウェア開発やシステム構築の現場に関わってきました。
富士通にいた頃、僕は行政系のパッケージ開発に関わっていました。そして大量のExcel設計書を向き合い、本当はどこの会社の人かもわからない多重下請けのパートナー会社の開発メンバーに囲まれて、常に不自然さを感じていました。技術的にも、COBOLという古のプログラミング言語とVSSという古来から伝わるバージョン管理ソフトが当然のように使われていました。テストもほとんど手動で、バージョンアップの時期は毎回Excelで作られた巨大なテスト仕様書に沿って人間が画面操作（「打鍵」）をしてバグを洗い出します。つらい。
現職の仕事でも、大手SIerや大規模なユーザー企業が関わるプロジェクトに参加することがあります。そんなとき、システム開発におけるパラダイムの違いを痛感します。その違いとは、根本的にはユーザー企業がソフトウェア開発にまつわる大きなリスクを取れない構造、あるいはそのリスクを適切に分散する手段が浸透していないことに起因しています。
今回は、システム開発に関わる誰もが何となく感じているパラダイムの変化について、6つの軸で整理します。その違いを言語化できる人が増えることが、きっとつらいシステム開発を減らす一助になるはずです。
日本のシステム開発がつらい6つの理由
僕が大手SIerからITスタートアップに転職したとき、開発の仕方がまるで違うことに驚きました。それは単に使っているプログラミング言語やクラウドサービスが違うというだけではなく、システムアーキテクチャ、プロジェクトの進め方、チームの人数や役割構成に及びます。もちろん作っているものやビジネスモデルが違えば、最適な手段も異なります。しかしながら、僕が直面した「違い」というのはそんな生易しいレベルではなく、言うなれば「一定のリスクを取ってより良いものをより高い生産性でつくっていく」という、仕事をする上で当たり前だと思っていた姿勢があるかないか。その点が決定的に違っていました。これが、まさに僕が感じた「パラダイム」の変化でした。
日本において、SIerは現代のシステム開発における悪者にされがちです。そこには、関係者が多すぎて、スピード感が遅く、生産性の低い、そんなつらいシステム開発現場のイメージが付きまとっています。具体的には、プロジェクトメンバーが大量のExcelドキュメントと日々にらめっこしており、納期直前になって大きな仕様変更が発生して炎上し、結果的にエンドユーザーの体験やコードの品質がないがしろになってしまうような、そんな開発現場です。
もちろん従来のシステム開発の手法や慣習が全て悪いわけではありません。ときに古くからあるノウハウを取り入れるべき局面もあります。しかし多くの場合は他の選択肢が取れない状況に追い込まれて仕方なくレガシーな手法を選ばされています。そしてそれは、SIer自体が悪いというわけではなく、ユーザー企業を含む日本のシステム開発の慣習に根深く残る構造的な問題に起因しています。
システム開発にまつわるパラダイムの変化を6つの軸で整理したものが、次の表です。
対立軸として大雑把なところもありますが、誤解を恐れずあえてシンプルにまとめてあります。大局観を掴む上で、こうした比較表は役に立ちます。ここに書いた6つの要素が構造的に絡み合い、つらいシステム開発の現場がそのつらさから抜け出せない状況が生まれています。
システム開発はなぜ巨大化するのか？
いわゆる大手SIerが担ってきた重厚長大なシステム開発プロジェクトには、多くの問題があります。問題とは、たとえば次の通りです。
開発の規模が大きいので、プロジェクトに際して大量の人員確保が必要であり、能力にバラつきのある社外の開発人員を大量に投入せざるを得ない
関わる会社や部署が多くなるので、ステークホルダマネジメントや情報共有の点でプロジェクト管理コストが非常に高い
1プロジェクトの失敗が影響する範囲が大きすぎるので、失敗が許されなくなり実績のある技術や手法しか採用できない
これらの問題に共通する原因として、「プロジェクトのスコープが大きい」ということが挙げられます。システムアーキテクチャ的には、1つの大きな岩盤のように分離不可能なシステムを「モノリシック」なシステムと呼びます。その巨大なモノリスの機能をガラッと変えようと思ったら、全体を作り直すしかありません。モノリシックなシステムが多いことが、プロジェクトの規模が大きくなる1つの原因となっています。
逆に「マイクロサービス」とは、システムを独立した複数のサービスで構成するというシステムアーキテクチャの考え方です。
マイクロサービス化されたシステムでは、個々のサービスが相互に連携することでシステム全体の機能を実現します。サービス間は相互依存度が低く、それぞれ独立して開発や修正を進めやすい構造になっています。比較的小さなサービスの単位で開発ができるようになると、システム開発プロジェクトの規模も小さく分割しやすくなります。
マイクロサービス化を本気で進める場合、クラウドインフラが利用できる状況の方が有利です。一般的に、自社でサーバーを抱えるオンプレミスよりクラウドインフラを使った方がサーバーやネットワークの構成を機動的に変更しやすいからです。
現代の複雑なシステム開発プロジェクトでは、単に「当初の想定通りのものを作る」のではなく「何を作るべきかを学習しながら作り進める」ことが求められます。本当に作るべきもの（What）やその作り方（How）が最初から細かい部分まで明確にわかっている、というケースは稀です。仮にプロジェクトメンバーの誰もがそう信じていたとしても、実際にはプロジェクトの進行とともに想定外の要件や環境変化が発生し、真に選ぶべきWhatやHowが明らかになっていきます。こうした状況下では、設計と実装を明確にフェーズ分けするようなウォーターフォール型のプロジェクト進行だけでは真に良いものは作れません。設計と実装のサイクルを繰り返すアジャイル開発のプラクティスを取り入れた方が、不確実性の高い状況下では有利です。
一方で、リスクを取りにくいシステム開発の場合、事前に何をどのくらいの期間で作るのかが明確に決まるウォーターフォール型の方が相性が良いです。言い方を変えれば、リスクが大きすぎたり十分にリスクを許容できない状況下ではウォーターフォール型開発という選択肢しか選ぶことができなくなります。大規模なシステム開発ほど失敗のリスクも大きく、その制約を強く受けやすいわけです。
ここまでで、そもそも既存システムのアーキテクチャやインフラ環境がモノリシックで分割困難であることが、システム開発プロジェクト自体を巨大化させている一因であるとわかりました。この状態を解消するには、システム全体のあるべき姿を描き、数年に及ぶ移行計画を立て、地道にそれを推進していくような変革が必要になります。
しかし、大手SIerがユーザー企業のシステム開発を一手に引き受けるような従来のシステム開発の慣習が、その大きな足枷になっています。
SIerに丸投げせず「手の内化」する
日本は先進国の中でも「IT人材がIT産業に偏在している国」であることが知られています。
米国やドイツでは非IT業界のユーザー企業にもIT人材が多く存在し、内製開発が盛んです。他方、日本では長らく大手SIerにシステム開発を「丸投げ」するような慣習が続いていました。そのような慣習が根強い理由には、日本の解雇規制の強さもあります。「数百人規模のシステム開発人員を自社で正社員として抱えるのはリスクである」と日本企業が考えるのは、至極当然のことです。
経産省がDX（Digital Transformation）の必要性を声高に叫ぶときにも、「内製化」というのがよくキーワードになっています。先に述べたようなシステムの大きなアーキテクチャ変更を進めるには、ユーザー企業が抱える多数のステークホルダを巻き込んで変革を推進するための強力なリーダーシップが必要です。さらにその変革に際しては、技術的な意思決定や検証作業も大量に発生します。システム開発をSIerに丸投げしている状況では、ユーザー企業が開発プロジェクトをリードできる人材を社内に抱えナレッジを蓄積することはできません。
またユーザー企業とSIerの利害が必ずしも一致するとは限りません。SIerの基本的なビジネスモデルは、ソフトウェアを売るのではなく「人月」を売るというものです。「人月」とはSIerが集めた人員が何ヶ月稼働するかでシステム開発の工数見積りや請求が行われるということです。つまり、プロジェクトに関わる開発要員の稼働時間を増やすことが、SIerの売上を増やすことにつながります。これは、ときに顧客の目指すべき「より良い技術への移行」や「生産性の向上」と競合します。なぜなら、単純計算ではシステムの開発や運用が大変であればあるほどSIerの売上は大きくなるからです。ユーザー企業は、こうした利害関係の不一致を理解した上でSIerをうまくコントロールする必要があります。
これらの理由から、「内製化」の重要性が上がっています。具体的には、ユーザー企業が社内にCTOや開発チームを抱えて自社のシステム開発全体をリードできるようになることが求められます。仮にSIerとの取引が続くとしても、技術上に重要な領域を詳細まで把握し関連する意思決定をコントロールできる状態に持っていく必要があります。『ソフトウェア・ファースト』ではこうした変化のことを「手の内化」と表現しています。
これまでシステム開発を外部パートナーに一任してきた企業が、いざDXに取り組みタイミングですべてを内製化するのは現実的ではないと思う方もいらっしゃるでしょう。ただし、現実問題としてそうせざるを得ないとしても、DXで肝になるのはIT活用を「手の内化」できるかどうかです。
手の内化とはトヨタグループで使われている言葉です。トヨタ企業サイトの『トヨタ自動車75年史』によると、80年代に発展したカーエレクトロニクス分野の関連機能をグループ内で内製化したことを「手の内化」と記しています。筆者なりにその意味を解釈すると、自社プロダクトの進化にかかわる重要な技術を自分たちが主導権を持って企画・開発し、事業上の武器にしていくことを「手の内化する」と言うのでしょう。DXでもこの考え方がとても重要になります。仮に外部パートナーを活用するとしても、ITの企画、設計、実装、運用というすべてのフェーズを自らコントロール可能な状態にすること、つまり手の内化していくことが大事なのです。
「内製化」と「自前主義」の違い
「内製化」に対するよくある誤解として、「自社のシステムを全て自社で開発すること」が正義であると思われがちです。しかしこうした「自前主義」の考え方は、現代のソフトウェア開発の定石とはズレています。たとえば「内製化」のお手本とされがちなITスタートアップの開発現場では、「いかに自社内で書く独自のプログラムを減らせるか？」が強く意識されています。
それは単にあまり使わない機能を消していくという話だけではなく、OSSコミュニティやサービスベンダーが書いたプログラムを積極的に利用していくということです。極端な話、仮にレガシーなSIerであっても、わざわざサーバーのOSから作り始める人はいません。そこではLinuxやWindowsなどの既にある標準的なOSが使われます。さらに昨今では、一般的なシステム開発で使われる技術要素やモジュールの多くがOSSやクラウドサービスとして市場に流通しています。そして当初はインフラレイヤーや低レイヤーなミドルウェアから進んだこの標準化の流れは、最近ではアプリケーションに近いレイヤーにまで及んでいます。たとえば顧客管理システムではSalesforceが使われ、決済ではStripeが使われ、ECサイト構築や在庫管理ではShopifyが使われます。マネージドサービスを使うことで、その領域についてはコードベースはおろかサーバーの管理すら意識しなくても良くなります。
このように現代のソフトウェア開発では「いかに自分たちが管理するコードを減らすか」や「いかに自分たちが運用するサーバーを減らすか」がとても重要になっています。この視点を持っているかどうかが、生産性に数倍〜数百倍の格差を生みます。まさに「パラダイム」の変化です。
「自前主義」が前時代的なものになった背景には、ソフトウェア産業が積み重ねてきた進歩があります。ITエンジニアの数が増え、OSSコミュニティが活発化し、クラウドサービスが増えた。それによって、ソフトウェアの中でも「新しく作るより既存のものを使った方が早いし安いし品質も良い」と言える領域が驚くほど広がっています。この進歩の上にうまく乗っかった方がより高度で価値あるソフトウェアを低コストで作ることができるのは、当然のことです。
逆に言えば、「自前主義」を貫いたまま「内製化」に舵を切るような過ちを犯すとそのまま茨の道をひた走ることになります。エンジニア採用は売り手市場で、せっかく人を集めても生産性の低い「車輪の再発明」を続ける現場だと分かれば優秀なエンジニアはすぐに辞めてしまいます。どうにかして自前のシステムを組んでも、洗練されたOSSやクラウドサービスの品質には遠く及びません。さらに、IT投資をすればするほど自社で管理するコードやサーバーも増えるので期間当たりの運用コストやシステム変更コストが積み上がっていきます。これはつらい。
というわけで、「内製化」という一言にも様々なコンテキストがあり、それを無視して「自前主義」を貫いてもつらさが増すだけです。
ユーザー企業は責任主体へ、SIerはMSPへ
ここまでの話をまとめると、システム開発をつらいものじゃなくするためには、ユーザー企業に次のようなことが求められます。
1. オンプレミスのシステムをAWSやAzureなどのクラウドインフラ上に移行し、モノリシックシステムを徐々にマイクロサービスに分割していく
2. 自前主義を脱却してOSSやマネージドサービスを積極的に導入し、自社で独自に管理すべきコードやサーバーを減らしていく
3. これらによって開発チームや開発プロジェクトの規模を小さく分割しやすくなるので、少しずつウォーターフォール型開発からアジャイルプラクティスを取り入れた不確実性に強い開発手法に移行する
ユーザー企業がこうした変革を主導するということは、それまでSIerに負わせていたシステム開発におけるリスクを自社で引き受けるということです。僕の大好きな次の記事でも、システム開発におけるユーザー企業の責任について言及されています。
こうしたユーザサイドがシステムの品質に最終責任を負うスキームは、米国では政府だけでなく民間企業においても珍しくない。2019年に米銀のCapital OneがAWS上に構築した自社システムから大量の個人情報を漏洩させるという史上最大規模のインシデントを起こした際、規制当局から責任を問われ制裁金を課されたのは、Capital One自身であり、AWSや他のサードパーティが責任を負うことはなかった。AWSのようなCSPは、責任共有モデルによって自社とユーザとの間で責任分界を定めており、自社が責任を負う範囲についてもSLAを明確に決めている。そのSLAの範囲内でどれだけ障害やインシデントが起きようとも賠償には応じない。SIerがMSP化する潮流の行きつく形は、あらゆるMSPがこうした責任分界とSLAを定めてそれ以上の責任を負うことを放棄するという世界であり、そこでは常にユーザが最後の責任主体となる。みんな覚悟はできてるか？ オレはできてる。
ユーザー企業がSIerに負わせていたリスクとは、事故によるシステム停止、個人情報流出などの障害のリスクだけではありません。たとえば次のようなリスクが挙げられます。
システム開発プロジェクトの実現のためにたくさんの開発要員を雇用するリスク
プロジェクトが破綻し当初想定した「品質」や「コスト」や「納期」を守れなくなるリスク
こうしたリスクを負う責任主体になることを回避したいユーザー企業と、そのリスクを負うだけの体力がある大手SIerとの蜜月関係が、日本のシステム開発における慣習を現代まで続くものにしてきました。
しかしこのままでは、不確実なシステム開発プロジェクトをリードするためのノウハウや人材がSIerの中にしか育ちません。ユーザー企業がシステム開発におけるリスクを自ら引受ける責任主体となることが、生産性の高い内製開発チームをもち機動的なIT戦略を実現するための必要条件です。
リスクを一身に受ける従来のビジネスモデルにおいて、SIerは大企業であることが有利でした。大企業として様々な業界のユーザー企業の開発プロジェクトを同時に抱えている方が、1プロジェクトが失敗することのリスクを分散できるからです。
しかし、前述したユーザー企業の「内製化」が進む中で、SIerの立ち位置も変わりつつあります。
様々な角度から、SIerには変化を強いる圧力がかかっています。前述したようなOSSやクラウドサービスの普及によって、システム開発は「民主化」され、開発業務のハードルが下がっています。少人数のチームでも大規模なシステム開発が実現できるようになったことによっても、IT産業における「大企業であることの優位性」は大きく揺らいでいます。実際、日本でもBtoB SaaSの分野で成功を収めるITスタートアップが急増しています。これまで大手SIerが中心となって担っていた業務システムの世界でも、新興IT企業が開発するSaaSプロダクトへのシフトが進みつつあります。さらに人材獲得の面でも、IT業界を志す優秀な学生は大手SIerではなくITスタートアップを就職先に選ぶ割合が増えつつあります。
これらの圧力の中で、SIerもリスクテイカーとしての役割からSaaSベンダーのようなサービスベンダーに近い役割へと変化することが求められています。先に引用した記事では、その役割をMSP（Managed Service Provider）と表現しています。
MSPという言葉自体は1990年代からあり、ほぼASPと同義で使われていたが、最近はSIerが単なるクラウドのリセラーを超えて自分たちの付加価値を再定義する言葉として使われるようになっている。一言でいうなら、
クラウドサービスのパッケージ + 人月サービス
である。米国では多くの業務パッケージベンダ（Adobe, Oracle, Microsoft等）がSaaSシフトに舵を切っており、スタートアップ界隈でもSalesforceを皮切りにサービスモデルで大きな成功を収めた企業は枚挙にいとまない。そのため、一芸特化のX-as-a-Serviceは百花繚乱の様相である。そうしたサービス群をパッケージングして、導入コンサルや運用の人月サービスを付加していく、というのがMSPである。
実際、業務で使うSaaSプロダクトを導入をするプロジェクトに関わっていても、そのSaaSを契約してすぐ価値を発揮できるということは基本的にありません。普通は、「インプリ」と呼ばれるような「ユーザー企業がもつシステムの中に新しいサービスを適切に配置しやりたいことを実現できるようにする作業」が必要になります。具体的には、次のような作業です。
既存システムとのデータ連携を設計・実装する
アカウントの権限設定や運用上のルールなどを設計し、ユーザー側で運用を回せる状態にする
そのサービスの機能だけでやりたいことを実現できない場合、他のサービスと組み合わせたり間をつなぐプログラムを書いたりしてそれを実現する
サービスベンダー企業の中には、こうしたインプリ作業をサービスの一部として提供している会社もあります。一方で、複数のサービスを横断してデータフローや機能連携の設計をする必要がある場合などは、1つのサービスベンダーでそれを持ち切れない場合も出てきます。そこではSIerが複数サービスを束ねてやりたいことを実現できるまで持っていき新たなサービスとしてユーザー企業に提供することが新たな価値になります。こうした複数サービスのパッケージングとインテグレーション（=まさにSystem Integratorという言葉通りの仕事）において付加価値を生む存在が、MSPというわけです。
SIerがMSP化した世界では、ユーザー企業から見ればSIerはある業務領域のシステム開発を丸投げできる対象ではなく他のSaaSベンダーなどと並列にいるサービスベンダーの中の1つになります。
この図を見ても、ユーザー企業のコントロール範囲が大きくなることが伺えます。見方を変えれば、SIerに集中的にリスクを負わせていたところを、ユーザー企業が責任主体となって自らリスクの分散やコントロールができる状態になります。
DXの文脈で語られる日本の従来型システム開発がなぜつらくなるのか。その理由を6つのワードで整理してみました。もちろん、現状を理解したからといってこの複雑かつ構造的な問題をすぐに解決できるわけではありません。しかし、進むべき方向に確証を得るためにも前提の理解は重要です。ソフトウェアの力が強まっていく中で、それでも楽しく働く人が増え続けるように、日本からつらいシステム開発の現場が少しでも減ることを願っています。
サポートをいただけると、喜びドリブンで発信量が増えます！初月無料のマガジン『仕事を楽しくするデジタルリテラシー読本』もおすすめです！