システム開発が失敗する本当の理由

吉澤準特氏が公官庁のシステム開発の問題点について指摘していますが、開発失敗リスクについて感じるところがったのでちょっと書いてみます。

ITシステム開発のフェーズを2つに大別すると・・・政府調達に見るIT投資の無駄遣い

 

パッケージソフトなどの出来上がっているソフトにちょこっと修正して運用開始するのと違い、もとになるシステムの有無に関係なく、あるお客様に固有の業務フローをシステム化する開発プロジェクトには大きなリスクが常に存在します。

どんなリスクかという事をなるべく素人でも分かりやすく述べると下記の通りです。

1)手作業で行う効率的な業務プロセスがシステムでも効率化できるとは限らない。

多くのお客様では、現場への業務分析を行うと、現在の手作業(あるいは古いシステム)を前提としてかなり効率化(少人数化)されている事がほとんどである事が分かります。日本の文化的特徴として現場には優秀な人材が多く、出来る効率化はあらかた実行済みである為、「いまの効率的な業務プロセス」を要件定義の前提とする場合がほとんどと言っても過言ではないでしょう。

手作業による効率化された業務プロセス、あるいは個々の業務プロセスに特化して改良を重ねた古いシステムがあり、それらをプロセス間、科や課をつないで統合的に運用できるような新しいシステムを考えようとする場合、はっきり言うと、いまある効率化された業務プロセスを作り変える必要があります。

なぜなら、現在は科や課で独立して管理している情報(エクセル表や古いシステム)は、隣接する科や課が持つ関連する情報ときちんとリンクしていません。「きちんと」という意味は、人間なら許容できる範囲の時差と精度だが、統合的なシステムから見ると許容できないという意味です。

業務プロセスを統合システムに合わせて作り変える事は最重要課題ですが、実際にはこれが、要件定義やシステム設計をきちんと行うよりよほど難易度の高い問題です。最大の問題はスイッチングコスト(*1)と言われ、いままでと異なるやり方を現場が嫌がる(面従腹背で拒否する)という事です。私の経験では、システム導入を推進する組織トップが現場をきちんと指導できる強い統治力を持つ組織でない限り、この問題の解決はできません。

 

2)システム設計者はお客様の業務フローを生半可にしか理解できない。

あるお客様に特有のシステムを開発する場合、その業務内容に習熟した開発者側の人間がいれば、上記1で述べた業務プロセスを作り直す為の提案を行い、あらかじめ業務プロセスの改善に着手すると同時に、その着地点を前提とした要件定義を行なって、システム設計を行う事ができます。

ところが現実には、あるお客様に特有の業務プロセスに習熟する為に、優秀なシステム設計者を1つのお客様へ半年も1年も派遣して貼り付ける事は困難です。そのような優秀な人材は、どんな大企業でも人数に限りがあり、その一方で企業規模に応じた受注額をこなすために、1つの案件に貼り付けられる時間には限りがあります。

有名になった特許庁システムの開発破綻(*2)では、業務内容を習得するべき担当者が期間中に何回も入れ替わって、何をどう理解したのかもわからないような惨状であったと思われます。これは極端な例ですが、毎週何回も業者側のシステム設計者が業務担当者や係長や課長と打ち合わせを行ったところで、たかだか数週間とか数ヶ月でまとめられるのは主要な業務プロセスと主だった例外処理項目だけであり、どれだけの例外処理項目を見逃していたかはシステムを開発した後にならないと判らない事がほとんどです。

これを後の祭りと言います。

では、どうしたら開発失敗のリスクを減らす事ができるのでしょうか。

真正面から答えるならば、要件定義の前に業務分析と業務改善(ビジネスプロセスリエンジニアリング)(*3)のフェーズを挿入し、ここへ最も大きな時間と予算を投入する事です。そして業者側でエース級のシステム設計者に、主要な業務から年数回の例外処理まで、実務の担当者以上に業務内容を理解してもらい、それを前提とした業務改善を業者と一緒になって行ないます。

業務改善の趣旨は、組織全体でデータ管理の改善、例外処理が発生しないように主要な業務プロセスの見直し、外側組織のデータとの関係性の改善などです。

システム導入を前提として、業務プロセスをきちんと整理する事ができれば、その後の工程(要件定義、システム設計、システム開発、テスト)のリスクはかなり低下させる事ができます。

最後になりますが、公官庁のシステム開発案件でも、業務分析・改善フェーズからシステム設計フェーズまでは、少なくとも1つの業者が責任を持って請け負うべきだと考えます。

 

参考資料:
1)スイッチングコスト
2)特許庁のシステム開発破綻の理由
3)ビジネスプロセスリエンジニアリング

Facebook Comments
Tags:
Comments are closed.