企業の業務を改善するシステム開発プロジェクト。
日本のITは遅れていると言われており、早くシステム化しなければと思っている企業もいるだろう。
しかしITプロジェクトはうまくいかず失敗する事の方が多い。
業務利用に耐えられるシステムにはならなかったり、想定よりも効果が出なかったり、完成に時間がかかったり、コスト超過したりする。
例えばみずほ銀行のシステム統合は何年も頓挫した上に、終わってからもATMトラブルが何度も発生しており、成功とは言いにくい現状だ。
何故失敗するのか。
そこで今回はITプロジェクトが失敗する理由について解説する。
この記事を書いている人
記事を読むメリット
ITプロジェクトが失敗する理由がわかり、失敗の根本原因を避けられるようになる。
ITプロジェクトが失敗する理由は「要件定義が不十分」
まずITシステム開発プロジェクトの失敗理由の大半は「要件定義が不十分」ということだ。
失敗理由の筆頭はシステムの「要件定義が不十分」
成功率が上がったものの、「半数が失敗」している現状がある。2018年の調査で日経コンピュータは失敗したプロジェクトの失敗理由を調べている。それによると、満足を得られなかった理由の筆頭は「要件定義が不十分」、コストを順守できなかった理由の筆頭は「追加の開発作業が発生」、スケジュールを順守できなかった理由の筆頭は「システムの仕様変更が相次いだ」だった。スケジュールを守れなかったプロジェクトで最も苦労した工程を尋ねると「要件定義」が筆頭に来た。
要件定義、すなわちやりたいことを決めるということ。
要件定義は難しい
直感的には自分達のやりたいことはわかってそうなイメージがある。
ただそれはあくまで「感覚的に自覚している」という範疇。
実際に要件を明確に定義するのは難しい。
例えば直感的な要求として「空を自由に飛びたいな」というものがあったとする。
アニメであれば未来道具でサクッと解決できるが、要件定義はそれでは済まない。
理由はコレ。
要望には必ず理由となる背景がある。
「空を自由に飛びたい」という要望の理由は、いくつか考えられる。
自由に飛びたい理由の例
この理由によって「自由に飛ぶ」という要望にどのような解を出すかが変わる。
さらに理由を深堀りしていけば、もしかしたら空を飛ばなくてもいいかもしれない。
そして現実の要件定義でも同じで、要望の背景を深堀りする必要がある。
ITシステム開発プロジェクトの場合、深堀りするのは発注側の業務だ。
業務を整理して理解し、業務のどの部分にどんな課題があり、システムにどんな機能を持たせると、誰にどのようなメリットがあるかを定義する。
これが要件定義である。
しかし業務知識を暗黙知として持っている場合、業務整理をすっ飛ばして「空を飛びたい」レベルの要望でシステム開発に臨んでいるパターンが多く、結果として意図しない結果になってしまっている。
では要件が定義が失敗する原因はどこにあるのか。
要件定義は発注側の責任
要件定義がうまくいっていないとなると
と、思うかもしれない。
しかし要件定義は発注側の責任である。
情報処理推進機構（IPA）の資料にも以下のようにしっかりと記載されている。
要件定義とは、どのようなシステム、何ができるシステムを作りたいのかを定義することです。それはあくまでも発注者の仕事であり、発注者の責任で行うものです。要件定義があいまいであったり、検討不足のまま、受注者に開発を依頼した場合、その結果として、コスト増、納期遅れ、品質低下を発生させるおそれがあります。その責任を受注者に負わせることはできません。
受注側のシステム開発会社に協力してもらうことはできる。
しかし発注側の業務構造を理解しているのは発注側であり、業務に関する情報を持っているのも発注側である。
受注側ができるのは、提示された情報を整理して
と提案するだけである。
当然だが業務が整理できていない、または業務上の課題がわかる情報を提示できていなければ提案するシステムは業務に役立たないものになる。
そして描いたプランにGOサインを出すのは発注側の責任である。
よくある失敗例「業務を整理せず課題だけ持ち込む」
よくある失敗例として「業務を整理せず課題だけ持ち込む」というものがある。
発注者側は自分達の業務を理解しており、ドキュメント化せずに当然の暗黙知として持っている。
なので「そらを自由にとびたいな」レベルの要望だけ開発会社に渡すケースである。
しかし開発会社は発注者側の暗黙知は当然持ち合わせていないので、発注者に代わって適切な要件定義をすることはできない。
この場合、要件定義を繰り返す「要件定義地獄」に陥るか、見切り発車で開発をして後から追加修正になるかである。
失敗の根本は「お客様精神」
では要件定義及びITプロジェクトを失敗させている要因は何なのか。
失敗の根本は「お客様精神」にあると思われる。
よくあるのが、発注側がお金を払い、「後は全てお任せ」モードに入ってしまう状態。
そして後は成果物を見て「良い」「悪い」を判断するようになる。
これが受付や発送のような定型業務の依頼であれば、マニュアルを渡して教育して「あとはヨロシク」でもうまくいくかもしれない。
しかしITプロジェクトの場合はこれではうまくいかない。
と言うかもしれないが、ITは丸投げではうまく行かない。
何故なら、システム化の対象である業務を最も知っているのは発注側だから。
なので要件定義を丸投げしても、業務が整理できていなければ正しい要件は洗い出せない。
成果物に対して評価者になって批判しても、「業務をシステムでどのように改善したいか」のビジョンを持っていないと改善方針を決めることもできない。
開発会社はシステム開発のプロではあっても、発注側の業務を熟知しているプロではない。
あくまで発注者側が当事者として業務を整理して適切なインプットを行い、「開発会社と一緒にシステムで業務を改善する」という気持ちでなければいけないのである。
もうひとつの原因は説明を省きがちな「ハイコンテクスト文化」
実はITプロジェクトの成功を阻む根深い原因がもうひとつある。
それがハイコンテクスト文化だ。
ハイコンテクスト文化については以下の通り。
文化人類学者のE・H・ホールの理論における文化の区分の一つで、コミュニケーションに際して共有されている体験や感覚、価値観などが多く、「以心伝心」で意思伝達が行われる傾向が強い文化のこと。一般的に、日本の文化は「空気を読む」ことや「状況を察する」ことが重視されることから、ハイコンテクスト文化であるといわれる。
要は暗黙知や常識や背景を共有することで、あえて言葉では説明しない文化である。
「空気を読む」とか「忖度する」とかが該当する。
しかしITプロジェクトにおいては、このハイコンテクスト文化が悪い方向で作用する。
何故なら説明や情報共有が省かれるから。
基本的にわかってない人に説明することに慣れていない。
仕事もOJTで教育するため明文化されない暗黙知という形で従業員に定着する。
事業を継続するだけであればこれでも回るが、ITプロジェクトにはよろしくない。
社内だけで通用する暗黙知や常識は、開発会社には通じない。
しかし資料は無いし、そもそも常識レベルに叩き込まれているので資料が必要という発想になりにくい。
なので無意識的に業務整理や説明を省いてしまい、結果として要件定義が難航することになる。
まとめ
そこで今回はITプロジェクトが失敗する理由について解説した。
ITプロジェクト失敗する理由としてよく挙がるのは「要件定義不足」。
要件定義は受注側のシステム開発会社が手伝うケースが多いが、本来は業務のどこをシステム化して改善するのかという要件を決めるのは業務を熟知している発注側の責任。
しかし「お金を払うお客様」という立場になると、少ないインプットで要件定義も開発側に丸投げしてしまう。
ITプロジェクトを成功させるには、お金を出す発注側も当事者として現状の業務の流れを整理し、自社の業務の全体の中で『どの部分にどんな課題があってシステム化したいのか』を明確にしてプロジェクトに臨むと良いだろう。
心構えの他にもシステム開発プロジェクトで気をつけた方が良いポイントがあるので、見ておくと良いかもしれない。
