企業の業務を改善するシステム開発プロジェクト。
日本のITは遅れていると言われており、早くシステム化しなければと思っている企業もいるだろう。
しかしITプロジェクトはうまくいかず失敗する事の方が多い。
業務利用に耐えられるシステムにはならなかったり、想定よりも効果が出なかったり、完成に時間がかかったり、コスト超過したりする。
何故期間やコストが超過するのか。
開発会社の見積もりが甘かったのだろうか。
そこで今回はITプロジェクトが失敗する理由（コスト編）について解説する。
この記事を書いている人
記事を読むメリット
ITプロジェクトが失敗する理由がわかり、適切なコスト計画を立てられるようになる。
ITプロジェクトの土台は要件定義
まず要件定義が不足しているとITプロジェクトはうまく行かない。
ITプロジェクトの基礎となる土台は要件定義である。
自分達の業務を整理し、業務のどこにシステムを導入して誰が使うことでどんな効果を出したいのか、これを決める必要がある。
そして業務について知っているのは発注側なので、発注側の責任で主体的に要件を決める必要がある。
要件定義の重要性については以前の記事を参考にしてほしい。
あわせて読みたい
期間やコスト超過の要因
期間やコスト超過の要因は大きく３つある。
期間やコスト超過の要因
前者の場合、元々設計して約束していた機能が完成していなかったとしたら開発会社の責任なので期間は延びてもコストは超過しないだろう。
後者の場合、当初の要件から設計して作ったシステムを見てみたら
という意見が出て、改善が必要になったパターンが当てはまる。
後から出てくる「考慮すべき点」については追加要件なので、これは要件定義不足に起因する超過である。
要件定義は発注側責任なので、これは発注側が期間超過とコスト超過を受け入れなければならない。
「未知の課題」に対して予算のとり方が間違っている
問題となるのは３つ目のコレ。
世の中には２種類の問題がある。
- 解決方法がわかっている問題
- 解決方法がわかっていない問題
システム開発PJに置き直すと、前者は「システム化されていないだけで業務ロジックは既にある問題」、後者は「現行業務には組み込まれていない、まだ誰も解決できていない問題」である。
そしてITプロジェクトを進める際の大きな間違いとして、後者の「誰も解決できていない問題」を「システム化できていないだけの課題」と同じように扱ってしまうというものがある。
要するに
と言っちゃうやつである。
前者の「解決方法がわかっている問題」については業務ロジックが明確なので、それをシステム化するには必要な処理や画面の数がある程度はっきりしている。
必要な処理や機能、画面が明確であればシステム化するのにどれくらいの工数がかかるのか見積もりは可能だ。
しかし後者の「解決方法がわかっていない問題」については同じようには行かない。
誰も解決できていない問題なので、どのような処理をすれば良いのか答えが無い。
なので「こうすれば解決できるのでは」という案を試すことから始まる。
つまりPoCである。
PoCとは、新しい概念や理論、原理などが実現可能であることを示すための簡易な試行。一通り全体を作り上げる試作（プロトタイプ）の前段階で、要となる新しいアイデアなどの実現可能性を示すためだけに行われる、不完全あるいは部分的なデモンストレーションなどを意味する。
PoCはあくまで「できるかどうかの検証」であり、研究開発的な側面が強い。
これを通常業務と同様に「完成することを前提とした予算」に組み込んで、
というのは間違っているのである。
未知の課題に対して解決できるかどうかは未知数なので、できることを前提とした皮算用をするのではなく、検証と割り切って「今期の検証にはいくらまで予算をかけられる」としなくてはいけない。
ウォーターフォール開発とアジャイル開発
このような「要件が確定しているか」で変えなければいけないのは予算だけではなく、開発手法も変える必要がある。
既知の業務ロジックをそのままシステム化するだけならば、要件定義→設計→開発と進めるウォータフォール型開発が適している。
しかし未知の課題解決を求める場合は、システム化すべきロジックも見えていない為、ウォーターフォールの進め方はできない。
例えば、銀行の店舗などで人の手で行っていた作業をシステム化していくような場合には、ウォーターフォール開発を採用する方がむしろ適していることもある。しかし、デジタル技術を活用して、今までになかったビジネスを新たにはじめるような場合には、当初はビジネス・フローの詳細は完全には見通せない。
巨大企業の富士通でも「要件のわからないものは小さく作って、使いながら追加する機能を見定める」というアジャイル開発の手法を勧めている。
前例がない、あるいはあっても極めて少ないビジネスを、デジタル技術を活用してはじめる場合には、ウォーターフォール開発を採用して早期に仕様の確定を行うと、使わない機能が満載の一方で、肝心の機能が使いにくいシステムが出来上がることになりがちである。経験がない事業や業務に何が必要かを、経験を蓄積する前に見定めることは難しいからである。
このようなケースではアジャイル開発を採用して、必要最低限の機能のシステムをまず作成し、実際に使ってみることで、付加する機能の必要性の高さを見極め、追加で開発サイクルを回していく方がよい。
まとめ
今回はITプロジェクトが失敗する理由（コスト編）について解説した。
期間やコストが超過する理由は、考慮が必要な要件が後から追加されるから。
そしてもっと根本的な問題がコレ。
業務ロジックが明確な業務のシステム化であれば、機能や画面数から開発側でコストを見積もることはできる。
しかしシステム無しでも業務上手動でも解決する方法が不明な課題については、システム化によって解決できるかどうかの検証（PoC）から始める必要がある。
「できるかどうか検証が必要な問題」に対して「いくらで完成するのか」と質問するのはナンセンス。
プロジェクトを始める前の準備として、通常のシステム開発予算ではなく、「課題解決の取り組みに今期いくらまで費用をかける」とする研究開発予算を計上をしなければいけない。
コスト（予算）の他にもシステム開発プロジェクトで気をつけた方が良いポイントがあるので、見ておくと良いかもしれない。
