ITプロジェクト成功の鍵は「システムを作らせる技術」
こんにちは。
税理士法人上坂会計 DXメンターチームの笹岡です。
企業が社内にITシステムを導入したいと考えた際に、外部のIT業者にITシステムの選定や開発、構築を依頼するかと思います。そして、それらの導入作業が終わり、「いざITシステムを運用開始するぞ」となった時に、現場社員から色々不平不満が出たり、全然社員が使ってくれなかったりして、結局ITシステムの導入プロジェクトが失敗に終わる、ということがあります。
ITシステムの導入プロジェクトの成功率は決して高くありません。
日経コンピュータが以前に行った調査によると、ITプロジェクトの成功率は、2003年の調査では26.7％、2008年の調査では31.1%、2018年の調査では52.8%とのことです。
20年ほど前までは3割ほどで、最近になって5割ぐらいにまでは高くなりましたが、それでも2件に1件は失敗している計算です。
大工さんに新しい家をお願いして、2軒に1軒の家が失敗するということは基本的には無いかと思います。それだけ、ITの導入というのは難しいのです。
何故、ITプロジェクトはよく失敗するのでしょうか？
色々原因はあるかと思いますが、その一つとして発注する企業側（ビジネス側）の役割認識のズレがあります。
ITプロジェクトというのは、まずビジネス側である会社において、実現したいこと、導入したいシステムがあって始まります。
IT会社の担当者に、自社の現状、やりたいことを伝えて、それをシステムで実現してもらうように依頼します。IT会社の担当者側においては、クライアントである企業の要望をヒアリングして要件を整理し、システムの設計をして実装します。
この流れは、以下のように整理されます。
ビジネス構造の把握（自社の現状、業務の流れ、企業特有のルールなど）
要件定義（システムで実現したい事、必要な機能などの要求事項の整理）
設計（要件通りのシステムをどのように作るかを決める）
実装（設計通りに、システムを作る）
ここで質問なのですが、上記の流れのうち、ビジネス側が果たすべき役割はどれで、エンジニア側が果たすべき役割はどれだと思いますか？
3.設計、4.実装は迷うことなく、エンジニア側の役割だということは分かりますよね。
では、1.ビジネス構造の把握、2.要件定義はどちらの役割なのでしょう？
ビジネス構造の把握、要件定義のどちらも、ビジネス側、エンジニア側の双方が果たすべき役割です。この点において、すれ違いが起きていることがよくあります。
ビジネス側は「相手はプロなんだから、必要なことは全部聞いてきてくれるだろう」と考えており、一方でエンジニア側は「相手が言ってきたことをすべて実現できれば、それで良いだろう」と考えている。
このように、互いに「相手に責任がある」と考えていては、ほぼ確実に後になって要件漏れが見つかって、手戻り発生による余計なコストがかかったり納期遅れが発生したり、最悪の場合プロジェクト自体が頓挫してしまうことになりかねません。
ビジネス構造については一番知っているのはクライアントであるビジネス側です。そして、エンジニア側は基本的にクライアント企業のビジネス構造をあまりよくは知りません（もちろん、経験豊富なエンジニアだったり、その業界に特化しているIT会社であれば知っている場合もあります）。
要件定義はビジネス構造（業務の流れ、社内ルールなど）が前提にあるため、それが曖昧な状態では要件定義も十分には出来ません。
エンジニア側はヒアリングを通して、必要なビジネス構造の情報や要件を聞き出そうとはしてくれますが、それでも限界はあります。
ビジネス側もビジネス構造の把握や要件定義をエンジニア任せにするのではなく、設計・実装に入るまでに、社内調査をしたり、資料にまとめたり、打ち合わせを実施するなりして、必要な情報を共有し要件の抜け漏れを無くすことに努めることが必要です。
ITプロジェクトを成功させるためには、エンジニア側のシステムを作る技術と同じくらい、ビジネス側のシステムを作らせる側の技術も重要なのです。
システムを作らせるための具体的な方法については、以下の書籍に詳しく載っていますので、もしよろしければ読んでみてください。
今回の記事が、少しでも皆さんのDXの理解に役立てば幸いです。
弊社でも、企業のDX支援をお手伝いさせていただいております。DXについての相談を常時受け付けておりますので、お気軽にお問い合わせください。
弊社へのお問い合わせは、こちらからどうぞ
この記事が気に入ったらサポートをしてみませんか？