株式会社ピースフラットシステムの代表ブログ

業務効率化の"鬼"が送る日々の綴り

【驚愕】システム開発が失敗する確率は◯%

こんにちは。

株式会社ピースフラットシステム 代表の片川です。

 

本日は

システム開発が失敗する原因

を書いていこうと思います。

 

せっかく時間とコストをかけるので、失敗はしたくはないですよね。

私もこれまで、開発の仕事を通じて様々な改良を加えてきてますが、未だに「システム開発むずっw」てなってます。

 

ただでさえシステム開発は失敗確率が高いので、失敗の原因をザクッと把握しておくだけでも、成功率を上げられると思います。

 

システム開発の発注を考えている、特に発注経験のない方はぜひ参考にしていただければ幸いです。

 

1. 要件定義が不十分

これが失敗の原因の大半を占めています。

要件定義とは簡単に言うと「システムで実現したいこと」や「システム開発の目的」を整理し、開発範囲を明確にすることです。

 

ここが結構難易度が高く、開発側だとプロジェクトマネージャー(PM)の腕が問われる工程でもあります。

 

あるあるなケースとして、発注側は「プロに依頼しているし」と開発側にお任せで、開発側も「問題なさそうだし」といった具合に"ゆるく"プロジェクトが進んでいき、終盤で成果物が上がってきた段階で思っていたものと違った、ということがあります。

 

発注側は開発側から上がってくる資料などに対して、「こういう場合はどう?」などと入念に確認する。
開発側は資料を投げて終わり、ではなく打ち合わせなどでプレゼンをして発注側の指摘をもらうなど、互いを巻き込む動きは不可欠です。

 

イメージとして、要件定義期間は「暑苦しいくらいにコミュニケーションを取る」方が失敗確率を下げれると思います。

 

とはいえ、コミュニケーション量を上げる、だけでこの工程の勝率を上げられるかと言うと微妙な所なので、別記事で要件定義の過去事例を詳しく紹介します。

 

結構長くなるので、本記事ではここまで。

 

2. 開発側とのコミュニケーションの問題

これまで、「今の開発会社とのやり取りで課題を感じてるから、相談に乗って欲しい」という依頼が何件かありました。

 

蓋を開けてみると、発注側と開発側の窓口担当とのコミュニケーションに問題があるケースが多かったです。

 

これは私の観測範囲内ですが、以下のケースが多そうです。

  • 窓口担当に開発の知見がない
    • 発注側の要望は何となくわかるが、エンジニアに明確に仕様として伝えられないので、べらぼうにズレたものが出来上がる
  • 窓口担当に開発の知見はあるがコミュ力が低い
    • 発注側との会話で、システム用語使いまくり、発注側としては何言っているかよくわからない
  • 窓口担当が超多忙
    • 会話はできるが、忙しい為、発注側とのやり取りを、開発側へ共有が遅れ、内部的にはプロジェクトが進んでいない

 

たしかに、システム開発の窓口は難しいですよ。

 

私も実際にやってみて、エンジニアであることと、営業経験があったことに何度救われたか...という具合なので。

 

契約前にやり取りしてる開発会社の担当に色々と質問して、「私は営業担当なので、開発に確認します」とか言われた時には、注意が必要そうです。

 

3. 納期・予算の見積がミスってる

これは例えば、

「これくらいでいけるだろう」と開発側が思っていた、けど実際にはもっとかかった...

とか、

開発終盤になって発注側が「そういえばこれもあった」と焦って要件追加したものの、納期は後ろ倒しにできない...

などでしょうか。

 

正直、契約前に要件を詰め切ることは難しいケースも多いです。

ただ、ある程度システムの大枠のフローだったり、必要な機能一覧だったりは、把握することはできると思います。

 

ですので、契約前のシステム開発の商談では、半分要件定義が始まってるものと考えて、仕様について突っ込んだ会話をしていく方がいいと思っています。

すると、自然と開発会社側からのヒアリング9割くらいになります。

 

開発会社の自社紹介やアピールに結構時間を割くこともあるんでしょうけど、私の場合、自社紹介なんて事前に資料だけ送って、商談では「早速なんですけど」て感じで案件の詳細なヒアリングを始めてます。

 

「今日寒いですよね」とか「まず自己紹介させてください!」とかやらないですねw

重要な部分を把握せず契約するの、こっちもこわいので、本題以外に時間使わない方がいいと思う派です。

 

4. 開発者の技術力不足

要件定義も問題なし、納期・予算も問題なし、ただ開発が苦戦する...

 

こればっかりは展開として予想しにくいですけど、事前に開発実績をしっかり発注側が見ておく、などの動きが重要にはなります。

 

ただ開発実績をみても、「いい感じかな?」となって終わることもあると思うので、セカンドオピニオン的にわかる人に聞いてもいいと思います。

 

職業柄、例えば居酒屋でテーブルにある注文システム触った時、
ある程度のレベルのエンジニアなら「なにこれ?使いにく!」て文句言うくらい、普段から色んなシステムを触ってきてるので、それなりに目利きはできると思います。

 

個人の駆け出しエンジニアクラスの人に頼んだけど、バグだらけだからどうにかして、て相談がきたこともあって、その時は結局作り直した方が早い、となりました...
最初からできる人に頼めばよかったのに、事例ですね。

 

さいごに

システム開発の失敗率は70%、なんて言われています。

 

システム開発の成功確率を上げるには、いい開発者を見つけることもそうですが、発注側が「知るべきことを知っておくこと」という点も大事です。

 

「では何を知るべきか」については、本記事のような情報とか、↓とかは読みましたが結構参考になりました。

amzn.asia

 

  • システム開発を発注したいけど、失敗したくないからちょっと意見欲しい
  • 開発者とのコミュニケーションに悩んでる
  • 今運用しているシステムを見て欲しい

 

などあれば、気軽にご相談ください。それでは今回はこの辺で。

 

↓片川LINE↓

↓Webフォーム↓

https://peace-flat-system.com/#contact

 

↓20秒で業務効率化動画を配信中↓

https://www.tiktok.com/@kata_techtok