なぜシステム開発は失敗するのか？（374号）

2024年は（も？）大規模システムの開発事案でのトラブルがいくつか起きています。

2024年の4月には、江崎グリコが業務システムの全面刷新を行うプロジェクトが稼動までこぎつけたものの、トラブル多発で、多額の損失を出しました。

また、2024年9月には、政府が進めているガバメントクラウドへの行政システム移行で富士通がギブアップ宣言をしました。
これによって、2025年度末を予定しているガバメントクラウド移行の完遂に暗雲がたちこめています。

トラブルはシステム開発につきものですが、どうしてこんな大トラブルになるのでしょうか？
今回は、大規模システムの難しさと、中小企業がシステム導入する時の注意点についてお話します。


1. システム開発は難しい

システム開発というのは、非常に難しいものです。

頭に描くイメージを実際に稼動かすまでには様々な作業が必要です。

理想のイメージ
　↓
　↓イメージを言葉に直す（要件定義）
　↓
　↓その実現方法を考える（設計）
　↓
　↓それをプログラムし、テストする（プログラミング）
　↓
運用開始

このうち、最初の理想のイメージは発注側（システムを作って欲しい側）が考えるしかありません。
だって、自分達が何を欲しているのかは、本人でないとわかりませんからね。

そのイメージを元に、お客さんとシステム開発会社が協力しながら以降の作業をこなしていくのです。


2. 理想のイメージって誰の理想形？

システム開発トラブルのお話ですので、本来は発注側とシステム開発会社側の両方の課題を取り上げるべきです。なぜなら、システム開発は基本的に協同作業ですので、どちらかが一方的に悪いということは滅多にないからです。

とはいえ、あまりに本文が長くなるのもアレですので、今回は発注側（システムを作って欲しい側）で起きがちな課題に絞って述べていきます。

さて、システム開発を発注する前に、自社内で理想のイメージを固めなければなりません。ところが、この作業が恐ろしく難しいのです。

部署や人によって理想イメージがバラバラで共有できていないままにシステム開発に入ると、決まってトラブルが起きるのは方向性が定まっていないからです。

理想イメージというのは使う人の立場によって変わります。

在庫管理を例に挙げてみます。
営業担当者は、お客さんに納品できる製品在庫数が重要でしょう。
でも、入庫担当者には各部品の入庫予定数が大切でしょうし、製造担当者なら各部品の置き場所の情報や不良数を除いた実在庫数が重要です。

このように営業担当者、入庫担当者、製造担当者でそれぞれの理想イメージは違ってくるのが普通です。

ですから、全社リニューアルなどの全部署に影響のある大規模改修の理想イメージを一部の部署の担当者だけで固めてしますことは極めて危険なのです。


3. 理想イメージの構築にはスーパーマンが必要

では、全ての部署の全ての要求を受け入れれば、皆が満足できるシステムが作れるのでしょうか？

いえいえ、そんな簡単な話ではありません。
互いに自分の理想を出したって、互いに矛盾があれば形にしようがありません。

ある部門はいろんな指標が欲しい、別の部門は指標を減らしてシンプルにして欲しい、というケースでは矛盾がありますよね。
また、おおざっぱでいいから早く数字を確認したい部門と、数字は正確でなければ困るという部門の違いもそうです。

こういった理想のイメージは社内で合わせていかないといけません。

これが数人だったら良いのですが、百人を越えると合意を取ることが大変になります。
ましてや、これが千人、万人ともなると、一つの理想イメージをまとめあげる労力たるや想像を絶するものとなります。

社内にスーパーマンと呼ばれるとてつもないリーダがいたり、誰もが認める「生き字引き」がいれば別ですが、そんな人は滅多にいません。
いきおい、それぞれの部門長たちが集って理想イメージを固めるわけですが、意見が対立すると両者の言い分を取り入れた、あいまい極まりない表現となりやすいのです。

なんとでも解釈できるような「理想イメージ」を元にしている限り、満足度の高いシステムなど作れるはずがないのです。


3. 後出しジャンケン

上記の理想イメージの共有ができていないと、決まって出てくるのが後出しジャンケンです。
「そんな機能より、こっちが優先だろ」
「最初から言ってたのに実現できてない」
「こんなのできて当然だろう。まさかできないとは思わなかった」

これをシステム屋の視点では、追加要望と呼びます。

発注側（システムを作って欲しい人）から見れば「システム開発会社側が確認しなかったからだ」と言いたくなるでしょうが、そもそも社内の理想イメージがズレまくっているのですから、こうなるのは当然の帰結です。

さて、この状況に陥ると開発会社側ではそのプロジェクトが問題プロジェクト認定され、事態の改善を目指します。
多くの場合、エースと呼ばれるプロジェクトマネージャを投入するのですが、その人物がいかに優れていようと、プロジェクトを完遂する方法は一つしかありません。

理想イメージを明確化した上で、やり直すことです。

ちなみに、こんな場面で投入されるエースと呼ばれる人々は、システム開発力以上にスゴい能力をお持ちです。
こじれた人間関係を修復して信頼を取り戻す能力、理想イメージの明確化などの発注側の作業にも卒先して参加してとりまとめる能力、などなど。

システム開発者というより人として尊敬できる方が多い印象が強いです。


4. 中小企業がシステム開発で失敗しないために

以上の話は大企業の話でして、多人数の組織を運営することも難しさそのものでもあります。

中小企業に限って言えば、冒頭に挙げたような強烈な大失敗は聞きませんが、それでもシステム導入で期待した成果を上げられないケースはたくさんあります。

その原因の多くは、上にも書いた理想イメージの共有ができていないパターンです。

中小企業の場合は、共有ができていないことで矛盾が起きることより、システム導入の目的をあいまいなままに、導入に突っ走って失敗するケースが多いように感じます。

もっとも、最近は業務用ソフトウェア（各業界向けの専用ソフト）を一から開発することは滅多になく、インターネット上でクラウドを使って実現するSaaS（Software as a Service：ソフトの利用権を買う方式）が中心です。SaaSであれば、高機能なシステムをローコストで利用できます。

とはいえ、やはりシステム導入にはそれなりの手間とコストがかかります。
価値のある投資かどうかは十分に考えていただきたいのです。

システム導入なんて業務を効率化する一手段に過ぎません。
ですが、「システム導入すれば全てが改善される」かのイメージを持つ方は今も多いのです。

例えば、現状のExcelでの在庫管理数がおかしいからといって、システム導入したっておかしな数字はおかしなままです。勝手にシステムが倉庫に行って在庫確認をしてくれるはずもありません。

数字がおかしいのであれば、その原因はExcel以外の部分にないでしょうか？
例えば在庫数のかぞえ方やデータの投入力方法はどうでしょう？
最初に手をつけるべきは、そういった課題整理ととその改善策の検討です。

この時点ではシステム導入の優先度はずっと低いはずです。

そういった改善を重ねてなお、Excel運用の不便さや面倒さが目立ってきたとなれば、その時こそシステム導入を検討すべきタイミングなのです。


5. まとめ

大規模システムでは、どんな機能をどんな形で実現するかを適切に規定することが非常に難しくなります。
これは大企業で全社員の考え方を合わせて、一致団結するのが難しいのと同じかもしれません。

ところが、その難しさを意識できないままシステム開発に着手するとひどいことになります。

参加者の意識が合っていないと、システムの目指すべき場所がわかりません。
目的の山を決めずに登山するようなものです。
こんなの失敗するに決まってます。

規模は違いますが、これと同じようなことが中小企業のシステム導入でも起きることがあります。
課題分析や問題分析が不十分なままシステム導入をしてしまうケースです。
システム導入で業務改善できるのは確かですが、それは原因分析が十分に行われていて、システム導入によって改善できることが明確な場合です。

売り手側の美辞麗句に惑わされることなく、皆さんにとって必要なサービスを取捨選択なさってください。

今回は、大規模システム開発の難しさと、中小企業のシステム導入の注意点をお話しました。
次回もお楽しみに。