結構昔から言われていることなのですが、SIerの丸投げは良くないよ、と。
今回の記事では、なぜSIerの丸投げがネガティブに捉えられているのかを解説してみたいと思います。
SIerの開発イメージをまずは共有
まずはこの話を進めるにあたって、よくある開発のイメージを共有しておきたいと思います。
よくSIerに依頼されるシステム開発の例として、例えば多くの企業には基幹システムというものがあります。
基幹システムは、その企業の情報をまとめて管理し、業務を効率化していくものです。
ゆえに、企業にとって中心となるシステムという意味合いから”基幹システム”と言われています。
この基幹システム、企業が大きければ大きいほど、扱う情報や業務が大きくなりますから開発の規模も比例して大きくなっていきます。
とてもユーザー企業だけでは開発しきれないので、基本的にその開発をSIerに依頼することになります。
ユーザー企業では、どのようなシステムを作ってほしいかの”要望”を用意し、
SIerはその要望に従って開発を進めていくことになります。
その後はウォーターフォール型開発の手法に従い、要件定義から設計、製造とテストを経てシステムの稼働が開始するわけです。
当然、要件定義や設計の過程では、ユーザー企業のIT部門メンバと一緒に仕様を調整していくので、完全な丸投げではないんですよね。丸投げと言われているのはいわゆるプログラミング工程やテスト工程。
ここからSIerとユーザー企業の接点がなくなっていきますので、ユーザー企業側はどのようなソースコードを書いているかなどを把握することができなくなります。これを回避しようと、ユーザー企業の担当者がコードレビューをすることを試みるユーザー企業もありますが、大抵の場合、他の業務が忙しくなりうまくいかないです。仮にソースコードレビューをちゃんとやろうとすると、その専任になるくらいの体制を構築しなければなりません。
このような状態では今後、ユーザー企業にとって良い未来は描きにくいと考えられる要因が３つあります。
SIerへの丸投げの問題点は大きく3つ
以下の3点です。
・ITによる事業進化にスピードが出ない
・開発ノウハウが蓄積されない
・最適なシステム構成を実現しにくい
個々に説明していきます。
ITによる事業進化にスピードが出ない
ITを使って、”事業を進化させていく”ということを考えた場合、これまでのように基幹システムを開発しているだけでは進化は不可能です。
ちょっと語弊があるかもしれないのですが、基幹システムで達成可能なことは業務の効率化に過ぎません。
その事業会社のユーザーに対して、何か価値をもたらすことに直接的にはつながってこないです。
ではどうするかというと、ユーザーに必要なもの、もしくはユーザーの潜在的なニーズをつかみ取り、それを実現していくことが求められます。
ここで必要になってくるのもまた、ITです。
ユーザーが求めるものすべてがITで実現できるわけではないですが、ITで実現できることが多いのも事実。
そこでITで新しい価値をユーザーに届けようと思った場合を考えてみましょう。
もちろん、そのアプリケーションを開発していく必要があるのですが、そのときには必ずといってよいほど基幹システムで扱っているデータや、基幹システムとの連携が必要になってきます。
そのとき、基幹システムの中身を詳細理解していないユーザー企業だけでなんとかなるでしょうか。
おそらく、ユーザー企業だけでは難しいでしょう。
理由は、
・基幹システムを修正することにより影響度合いがわからない
・修正や改修によってシステム障害が発生した時の対応ができない
この状況下においても、SIerとの関わりが外せないということになります。
改修を行うとなると、その都度SIerと契約を結ぶ必要があり、調整も入りつつなんだかんだ多くの時間を要してしまいます。
こう考えると、いざユーザーのためにアプリケーションを開発しようとした場合、基幹システムと連携するのにSIerとの契約が必要になり、そこが開発遅延の原因になる、ということが想定されます。
（そんなのAPIを自社で開発すれば良いではないか、という話も聞こえてきそうですが、なかなかそううまくいかないものなのです。。）
さらに、ユーザー求めることというのは、最近はショートスパンで変化していきます。
もはや変化に即対応していく姿勢は、世の中をリードしていく企業の使命でもあり、こういったボトルネックは排除することを考えていかなければなりません。（SIerを排除するという意味ではないですよ。詳細は後述。）
開発ノウハウが蓄積されない
次に、上記のようなアプリケーション自体を開発していくにあたっての話にうつります。
ユーザーのニーズを掴んで、開発を進める。こう書いたのですが、ユーザーのニーズ掴むことは想像しているよりも遥かに難しいです。誰も正解がわからないからですね。
ではどういうふうに進めていくかというと、これはもう仮説検証を繰り返していくしかないです。
さて、このアプリケーションの開発をSIerに任せると、ユーザー企業にとってはどうでしょうか。
仮説検証というものは、その過程で得られる知見やノウハウにより、ITの力というものが上がっていきます。
これをSIerにまかせてしまうと、ユーザー企業自体にはその力が身につきません。こういったノウハウや知見というものはすべての過程を自らの手で行っていかないとなかなかわからないことも多く、上述の通り、契約の話なども相まって、自分たちだけで開発を進めていくことができるユーザー企業と、SIerへ依存度が高いユーザー企業とを比較した場合、その優位性は自分たちだけで開発を進めていくことができるユーザー企業にあるのは間違いありません。
最適なシステム構成を実現しにくい
これは少し話が変わりまして、単純に言うと、
あなたのシステム、全てカスタマイズの必要がありますか？
という話です。
近年はSaaSの数も相当なもので、これらを活用すれば開発量を減らすことができる状態も珍しくありません。
しかし、多くの大企業は自分たちの業務を変えずに、システムをカスタマイズしています。
これはSIerに丸投げしていることが大きな理由の一つであるのですが、SIerのビジネスモデルは基本的に工数ベースなので、自分たちで多くの開発を請けた方が儲けが大きくなります。
なので、SaaSを導入するために業務フローをカスタマイズする選択ではなく、業務に合わせてシステムをカスタマイズすることを選択しがちです。
仮にSaaSを導入するとしたとしても、SaaSの方をカスタマイズする選択をとることもあります。しかしSaaSは基本的に時間経過に伴い進化していくものなので、その進化い伴いユーザー企業側のシステムをまた改修しなければならない、なんていう話になったりもするんですね。
こういった話は、意思決定権限を持つユーザー企業で判断すべきであり、また自社のことを考えると、自社のすべてのシステムをカスタマイズ対応するなんていう話にはならないと思います。
昔は丸投げでも良かった
昔は、とにかく基幹システム＋アナログ対応で業務が回っており今のやり方でも良かったのだと思います。
しかし、近年の業務はITソフトウェアによって簡単に破壊され、新しくなっていきます。
レンタルCD・DVDショップなどはその最たる例です。もはや何かをレンタルしに行く需要はほぼなく、アマゾンプライムやネットフリックスが主要なサービスとして人々に根付いています。
これほど既存の構造を変えられる力を秘めているITを、企業の事業進化に活用しない手はありません。
そうなると、どうしても自社ですべてをコントロールしてIT活用レベルを上げていくことが求められます。
今は丸投げでは進化できない。変化が求められている
外部環境もユーザーも今は数年経つと、大きく変化しています。
各企業は今後、この変化に追随していくことが絶対的に求められます。
大切なことは、その変化を追随するためにはどうあるべきかを自分たちで考えることです。
それをSIerに丸投げすることは、進化を諦めることと等しいことだと感じます。
かといって、SIerなしで今後システム開発をしていくのも困難なことだと思います。
丸投げ体質からから変わるためには
そこで、各企業はすべての開発に自社の社員を介入させることがスタートラインだと考えます。
SIerが開発するところでも、自社メンバを介入させ、自社のプログラムのコアを抑える。
設計、製造、テスト、全てにおいて自社社員の介入比率を高めていくことで、いわゆる丸投げ体質からの脱却につながると考えます。
また、コア部分をユーザー企業が自分たちで認識し、そこは自分たちで開発を進め、ほかは徐々に自社の開発体制下におくこととして、一旦はSIerの力をかりる。
こうすることで、
・ITによる事業進化にスピードが出ない
・開発ノウハウが蓄積されない
・最適なシステム構成を実現しにくい
この3点の課題は克服されていくはずで、ひいては自分たちでユーザーに価値ある内容をITによって届けられるようになると思います。
また、今回の話はDX(デジタルトランスフォーメーション)に深く関係してくる話です。
以下の記事ではSIerの視点でDXを語っています。参考にどうぞ。
今回はこんなところで。それでは。
この記事へのコメントはありません。