IT技術者は上流に向けて飛翔せよ：事例で学ぶビジネスモデリング（10）（2/3 ページ）

[林浩一（ディレクター），ウルシステムズ株式会社]

3．システム開発を失敗させる4つのギャップ

　これらの失敗が生じる要因はなんだろうか？ 主な要因はシステム開発にかかわるステークホルダーの間の知識や思惑のズレにある。4種類の失敗を引き起こす要因はそれぞれ異なっており、それぞれゴール（目的）のギャップ、アクティビティ（業務）のギャップ、プロセス（工程）のギャップ、スキル（技術）のギャップである。これら4つのギャップの頭文字を取るとGAPSとなる。多少こじつけだが、ギャップ自体がギャップになっている（gaps of GAPS）ことからGAPS2モデルと呼ぶ。これが最初に述べたビジネスとITのギャップの正体だ（図3）。

図3 ビジネスとITのギャップ

3.1. ゴールのギャップ

　ゴールのギャップは、経営者の持つビジネス上の狙いが開発側に伝わらない状態のことである。狙いが伝わっていないので、当然、完成したシステムはビジネスの役に立たないものになってしまう。ビジネス上の目的は、つまりそのシステムを使ってどのようなビジネス上の利益を得るのかという思惑である。これは「経営者に聞けばよい」で片付くほど簡単な話ではない。経営者の狙い自体はシステムとは直結しないのが普通だ。システム以外の施策も合わせたより大きな構図が分からないと理解できないことが多い。また、経営層が一枚岩とは限らない。いくつかの異なる目的の中でどれが最も重要なのかを見極めるのはそう簡単なことではない。

3.2. アクティビティのギャップ

　アクティビティのギャップは、システムを利用する現場ユーザーの業務のあるべき姿について、開発側が十分に理解できていない状態のことである。業務の流れがよく分からずにシステムを作っても、効率よく業務遂行ができるシステムには決してならない。こちらも「現場に聞けばよい」、で片付くほど簡単な話ではない。システムが支援するのが複数部門にまたがる業務であることは多い。普通の担当者は自分に関係のある業務は詳しくても、全体像を理解していることはまずない。また、業務のあるべき姿は、ビジネス上の目的を満たすために必要な作業を含む業務の将来像である。現場の担当者があるべき将来像を語れるかというと、それは難しい。現状で見えている業務の進め方にとらわれ、現実に直面している課題の解決に要望が強く入り、あるべき姿がゆがんでしまうことはよく起きる。

3.3. プロセスのギャップ

　プロセスのギャップは、関係者の間で、プロジェクトで生じている問題やリスクが共有されていない状態のことである。問題やリスクが把握できていないため、必要な対策を打つのが遅れて、致命的な納期遅延や予算オーバーなどを起こしてしまう。システム開発のプロジェクトマネジメントが大変な仕事だということは、読者の皆さんにはいうまでもないだろう。標準開発プロセスの整備やPMOの設置には一定の効果があるが、それらを完備してもプロジェクトは破綻する。プロジェクトはそれぞれに個別の事情があり、いくらプロジェクトマネージャが優秀でもすべてを見通すことはできない。問題やリスクは、会社や組織の壁によって見えないところに隠れていたり、経験不足の担当者によって見落とされていたりしていて、取り返しがつかないタイミングになって突然現れるのだ。そのときには外部から救いの手を差し伸べても手遅れになることが多い。慌てて要員を増員しても、結局、引き継ぎの工数が掛かって効果が出ず、かえって足を引っ張ることになる。

3.4. スキルギャップ

　スキルのギャップは、要求されている機能と性能を満たすシステムを作るのに必要な技術が足りていない状態のことである。つまり必要な技術力を持った要員を投入できていないために、求められるシステムを作ることができないのだ。システム構築に携わる技術者は多いが、技術者の実力は個人によって天と地ほどの開きがあることは、読者の皆さんはよくご存じのとおりだ。品質の良いシステムができるかどうかは、特殊な要件を持つシステムになればなるほど生産性や品質は技術者の力量に大きく依存する。また、導入実績の少ないパッケージ製品を採用したようなときには、それを使いこなすことのできる技術者がいないために、性能が出せないケースがよくある。

4. いまのままではギャップは埋まらない

4.1. ユーザー企業側に必要なガバナンス力

　システム開発を成功させるためには、これら4つのギャップを埋める必要がある。それを行うのは誰だろうか？ ここで読者の皆さんは、システム開発のプロジェクトマネージャ、あるいは、システムアナリストやアーキテクトを思い浮かべたかもしれない。しかし筆者は違う考えを持っている。ギャップを埋める責任はユーザー企業、つまりお客さま自身が持つべきである。中でも情報システム部が主体性を発揮することが重要になる。実際に開発を行うのが開発ベンダであっても、システムを使うのはユーザーだし、システムの所有者もユーザーである。また、ビジネス上の狙いや業務知識の共有ができていないのはユーザー企業内の問題であり、外部のベンダが立ち入るのは難しい。そして、プロジェクト管理や、適切な技術を持った要員を調達するのは、ユーザー企業の情報システム部門の仕事である。

4.2. ユーザー企業には助けが必要

　ビジネスとITのギャップを埋めシステム開発を成功させるには、ユーザー企業の情報システム部門が、ビジネス的な目的とシステムとを整合させ、業務部門の業務を把握し、プロジェクト管理ができ、十分な技術力を持つ要員を確保する力を持つことが必要になる。しかし、残念ながらIT技術の進歩が激しいこともあって、ユーザー企業だけで十分な体制を確保するのは難しいという現実がある。

　では、ユーザー企業はいったい誰に頼れば良いのだろうか？ 上流領域を専門に行うコンサルタントだろうか？ それともシステムの開発作業を担う開発ベンダだろうか？ 上流領域のコンサルタントに依頼する場合には、ビジネスや業務の視点から構想されたシステムが現実に実現可能かどうかを確認することが重要になる。現実の開発経験に乏しいコンサルタントの議論は机上の空論になりかねないからだ。反対に開発ベンダの場合には、上位のビジネス上の目的と整合する要件を一緒に定義していくことが大切だ。開発ベンダは、決まった費用の中でシステムを開発するという立場のため、与えられたスコープの範囲内で全力を尽くす以上のことをするのは難しいことが多いからだ（図4）。

図4 ユーザー企業はいったい誰に頼れば良いのだろうか？ （上流コンサルと開発ベンダとの間にさまざまなギャップ［GAPS］がある）