なぜ日本企業では"システム障害"が続発するのか…｢チェックのためのチェック｣がコストを増やす悪循環の罠

※写真はイメージです - 写真＝iStock.com／metamorworks

2023年10月の全銀ネットのシステム障害をはじめ、江崎グリコの一部商品出荷停止など、日本企業のシステムトラブルが後を絶たない。背景には何があるのか。リクルートなどでシステム開発の経験がある麗澤大学工学部教授の宗健さんは「システム開発をしている大手SIerとユーザー企業の信頼関係が重要だ」という――。

■プログラミングが得意な人を集めても「システム」は作れない

最近ではDXがバズワードとなり、さまざまな事業者がDXをキーワードにさまざまな製品・サービスの売り込みを行っている。こうした背景もあり、DXのPoC（Proof of Concept：概念実証）を内部で行うために、pythonなどのプログラミングが得意でデータサイエンスの素養のある若手を積極的に採用する企業が多くなっているようだ。

しかし、そうした若者を、PoCから自社システムの企画や開発に振り向けてもうまくいかない。

なぜなら、プログラミングやデータサイエンスは、システムの企画・設計・開発・運用のごく一部でしかないためだ。

システム開発とは、多くの人たちが関係するプロジェクトであり、システム開発をうまくやるために必要なのは、第一にシステムのアーキテクチャをうまく設計することであり、次がプロジェクトをうまくマネジメントすることである。そして、システムアーキテクチャの設計やプロジェクトマネジメントには、職人芸的なプログラミングスキルも高度なデータサイエンスのスキルも必要ではない。

そもそもプログラミングスキルが高くデータサイエンスの素養のある若者には、大規模な企業でのシステム開発の経験はない。

ひとはやったことがないことは基本的にはできないのだ。

■有名なサイトが数多く立ち上げられていた2000年前後

筆者が長く勤めたリクルートの創業は1960年だが、早くも1968年には科学計算用の小型コンピュータであるIBM1130を導入している。筆者が入社した1987年以降は基幹システムにはIBMのメインフレームを使いつつ、各事業部門でのダウンサイジング、オープン化が進められ、社員がプログラミングし業務システムを構築していった。

1995年にはMixJuiceというインターネットサイトが開設され、そこから約10年かけて各事業の紙媒体（リクルートブックや住宅情報、じゃらんやカーセンサーなど）をネットに変えていく、という大改革を行っている。これは今で言うDXそのものだろう。

そして、2000年前後には、リクルートナビや住宅情報（現SUUMO）、じゃらんなどの大規模なサイトの新規開発が各事業で行われ、さらに毎年のように大規模なリニューアルも行われた。

こうした状況はリクルートに限ったことではなく、Yahoo!（日本では1996年開始）や楽天（1997年創業）など現在でも有名なサイトの多くがこの時期に立ち上げられている。

2000年前後のネット開発は、それまでのホスト系技術者には勝手がわからず、30歳代の若手が主導することが多かった。

そうして経験を積んだ当時20歳代の若者は、いまでは50歳前後に、30歳代の中堅は60歳前後となり、いまでもシステム開発の第一線や企業の役員として活躍している人も多い。

■SIerのエースは多くの経験を積んでいる

一方、2010年以降になると、2008年のリーマンショックの影響もあり大規模なシステムの新規開発や大規模なリニューアルはめっきり少なくなり、逆にみずほ銀行のシステム統合の失敗のような事例が見られるようになった。

そうした状況では、システム全体を企画したり、システム全体を俯瞰してみるような大規模なプロジェクトを運営したりするような経験が積みにくくなっている。

簡単にいえば、今の40歳以下の世代は、細かく分けられた業務を割り当てられただけで、システム開発の全体を理解するための十分な経験が積めなくなっているのだ。

それでも、ユーザー企業の情報システム部門は、すでにあるシステムの維持・運用やちょっとした改修しか経験したことがない場合が多いが、SIerのエースは（もちろんSIerで働いている全員ではない）、数年ごとに新しいプロジェクトを渡り歩くため多くの経験を積むことができる。

こうして経験という面でも、ユーザー企業とSIerの間には埋められない差が積み重なっていく（参考：「「プッチンプリン」の出荷停止に、ゆうちょ銀行の入金遅延…日本企業でシステムトラブルが相次ぐ根本原因」）。

■システムは統合してはいけない

システム開発は基本的には、一品モノだから一つ一つのシステムごとに正解が異なる。そのためシステム開発には経験がものをいう。

こうしたほうがシステムとしてはうまく動く、こうするとこういった失敗につながる、といったノウハウがシステム開発には重要で、そのノウハウの多くは経験することによって獲得される。

筆者もさまざまな経験を積んだが、その中でもっとも重要だと思うのは「システムは統合してはいけない」ということだ。

システム開発を受注するSIerからみれば、システム統合プロジェクトは規模も大きくなり受注金額が増え、難易度も高いため高い単価を獲得することができる。そのため、システムの統合を好んで提案することが多いが、システムの統合がユーザー企業の実態や戦略に合致しているとは限らない。

写真＝iStock.com／kk-istock

※写真はイメージです - 写真＝iStock.com／kk-istock

統合システムを開発することのデメリットはいろいろあるが、ここでは逆にシステムを統合しない場合のメリットを挙げてみたい。

最大のメリットは開発規模を小さくできることだ。開発規模が小さいことは受注側からみれば好ましいことではないが、純粋にシステム開発を安く正確に早く行うためには、同じ機能であればシステムは小さければ小さいほど良い。

それはプロジェクトマネジメントの常識でもある。例えばコミュニケーション経路（経路数がすなわちコストだ）を考えてみると、プロジェクトの人数が1人であればコミュニケーション経路はゼロ、2人だと経路は1、3人だと経路は3、4人だと経路は6というように人数が増えれば、コミュニケーションコストは一気に上がっていく。

■「つぎはぎのシステム」には組織運営上のメリットもある

それがプロジェクトのオーバーヘッドとなり、同時にミスもどんどん増えていく。

さらに、できあがったシステムに手を入れる場合にも、小さなシステムでは手を入れる範囲をすぐに特定できるが、巨大な統合システムでは手を入れる範囲を特定するだけでもものすごい手間がかかる（一般的には影響範囲調査と呼ばれ大きなコストになっている）。

しかも影響範囲が広ければそれだけテストのコストも上がっていく。

システムが統合されておらずつぎはぎの場合には、組織運営上のメリットもある。

統合システムを作ったとしても、次の大規模なシステム開発は10年後どころか20年後になることもあるが、例えば5つのシステムをつぎはぎで使っている場合には、1つのシステムを20年ごとに4年かけて更新したとすれば、常にシステム開発が続くこととなり、若者もベテランも新しい経験を積む機会が継続的に確保される。

さらに、統合システムを一気に開発するよりも小規模な体制をずっと維持できることから、安定した雇用を維持できることにもつながる。

統合システムと言えば聞こえがいいが、安易にシステムを統合するべきではないのだ。

■厳密な年度計画はIT戦略の足を引っ張る

ほとんどの日本企業は年度計画に従って動く。組織の一つである情報システム部門も当然年度計画を立てるが、実はシステム開発には厳密で計画的な年度計画は不要どころか、IT戦略の足を引っ張ることになる。

年度計画は前年度の1～2月に立てられることが多いが、情報システム部では各部門からの開発要望を集め、それによって年度計画を策定する。

写真＝iStock.com／bee32

※写真はイメージです - 写真＝iStock.com／bee32

問題は、ここでエントリーされなかった案件が、どんなに事業に必要なものであってもほとんどの場合先送りにされることだ。

事業環境は刻々と変わっていくから、実際にはIT関連の案件は、少なくとも3カ月ごとに見直しをかけ、その時点時点で必要な案件の優先順位をつけ、案件の順番を入れ替え、開発体制を変更していく必要がある。

しかし、こうした案件の調整には、経営情報を把握しているだけの立場と、案件ごとの難易度や工数を判断できる高度な専門性と、経営陣・事業部門・情報システム部門・外注先であるSIerなどのベンダーとの複雑な関係を踏まえた調整能力、優先順位や案件内容を説明し、関係者を納得させモチベーションを喚起する力など、さまざまな力が必要となる。

さらに、案件を集め調整するだけではなく、新しいプロジェクトを提案し、実行していくことも求められる。

これが、本来のCIOの仕事だ。そして、こんな高度な仕事ができる人材はそうそういない。

■「チェックのためのチェック」がコストを増やしている

昨年10月の全銀ネットのシステム障害をはじめ、江崎グリコの一部商品の出荷停止、ゆうちょ銀行の入金遅延など、最近ではシステムトラブルがメディアを賑(にぎ)わすこともあり、実際に迷惑を被った人もいるかもしれない。

そして企業もシステムの障害が起きないようにもちろん努力しているが、その努力がシステム開発の現場を萎縮させ、生産性とモチベーションを大きく下げるリスクがあることも指摘しておきたい。

日本のシステム開発は、ユーザー企業がSIerに「発注」し、SIerが「受注」する構造になっている。見た目の力関係は、当然、発注側のほうが強いから、ミスが起きれば、発注先のSIerに原因究明と再発防止策を求めることになる。そしてこの時、「単なる作業ミスでした。今後気をつけます」というシンプルな話で終わることはまずない。

ミスのたびに原因が追及され再発防止策（その多くはチェックの追加だ）が練られることが繰り返されていくと、チェックのためのチェックが行われ、チェックが多重化すればするほど一つ一つのチェックはいい加減となり、品質は上がらないままコストはどんどん膨らみ、チェックのチェックをやらされる担当者のモチベーションは下がっていく。

2000年当時と現在を比べると体感的・感覚的なシステム開発コストは軽く5倍くらいになっていると思うが、その原因の多くはここにある。

写真＝iStock.com／BrianAJackson

※写真はイメージです - 写真＝iStock.com／BrianAJackson

■SIerとユーザー企業に十分な信頼関係が構築されていない

実際、筆者の2018年の論文「発注者と開発者のスキル・意識の違いがシステム開発に及ぼす影響」（※1）では、「意識的に余裕を持ったスケジュールを提示することがある」という設問にYesと回答した大手SIer管理職は29.6％に上る。あらかじめ予防線を張っているわけだ。

さらに発注側が「コストばかり言ってくる」と回答した大手SIer管理職は42.6％に上り、発注先の「知識・スキル・経験が足りない」という回答した大手SIer管理職は38.9％に上る。

こうした結果を見ると、システム開発の現場で十分な信頼関係が構築されているとは言えない。

一方で、「発注側と開発側の信頼関係はシステム開発で重要である」という回答には、ユーザー企業管理職の69.8％が、大手SIer管理職の85.2％がYesと回答している。

システム開発をうまく進めるためには、信頼関係の構築から始めるべきなのだ。

（※1）宗健（2018）「発注者と開発者のスキル・意識の違いがシステム開発に及ぼす影響」経営情報学会春期全国研究発表大会

----------

宗 健（そう・たけし）
麗澤大学工学部教授
博士（社会工学・筑波大学）・ITストラテジスト。1965年北九州市生まれ。九州工業大学機械工学科卒業後、リクルート入社。通信事業のエンジニア・マネジャ、ISIZE住宅情報・FoRent.jp編集長等を経て、リクルートフォレントインシュアを設立し代表取締役社長に就任。リクルート住まい研究所長、大東建託賃貸未来研究所長・AI-DXラボ所長を経て、23年4月より麗澤大学教授、AI・ビジネス研究センター長。専門分野は都市計画・組織マネジメント・システム開発。

----------

（麗澤大学工学部教授 宗 健）