システム受託開発が失敗する原因の大半は発注元企業にあり!

2018年8月3日金曜日

システム開発

t f B! P L
システム受託開発ではよくトラブルが起きる。
納期に間に合わなかった。
見積もり金額に収まらなかった。
必要な要件を満たしていなかった。
実用的な品質を満たしていなかった。
エトセトラ

 日経コンピュータの調査によるとITシステム開発の成功率は 52.8% (2018年)だそうで半数近くが何らかの失敗を招く。これでも昔に比べて随分改善しており十年前(2008年)の調査では31%程度だったそうだ。
 私もたくさんの失敗プロジェクトを経験しており納期遅延で何度もデスマーチと呼ばれる非人間的長時間労働を経験している。これらが原因でSIer(エスアイアー)業界と呼ばれるシステム受託開発業界はブラック企業が跋扈する労働環境劣悪な業界という印象が定着している。実際、この印象は事実であり弁護する気は全くない。

 しかし、システム開発を依頼する発注元企業にとってはこの状況好ましいものでは無いだろう。高い代金を支払って開発を依頼しているにもかかわらず開発の現場でITエンジニアが過労でバタバタ倒れ、残った者も寝不足と疲労でフラフラになりながら開発したシステムを発注元は安心して使用できるだろうか? 保守運用だってままならない。トラブル対応依頼したら担当エンジニアが入院してサポートが受けられないかもしれない。

 システム開発が失敗する原因の代表的な理由は、
「要求分析・要件定義などの精度が不十分」
「テストが不十分。旧システムなどからの移行に問題がある」
「システム設計に問題があり開発が混乱する」
というのが代表的なものです。
システム開発は大雑把に説明すると以下の工程を順番に進めて開発していきます。

(1)システム構想・企画立案...既存業務の見直しシステム化計画の立案
(2)要求分析...企画に従い業務手順を明確化。業務の詳細を分析する。どこをシステム化するか明確化。
(3)要件定義...具体的に開発するシステムの機能と仕様を明確化する。
(4)設計...システム仕様書を作成する。
(5)開発...システムを開発する。
(6)テスト...システムの動作確認を何段階かに分けて行う。
(7)リリース・移行...ユーザーの環境に稼働するシステムを導入する。旧システムのデータを新システムに取り込む。
(8)継続的運用...不具合対応、負荷増大などへのパフォーマンス対応など。

 システム開発の失敗原因は(1)から(4)までの「前工程」が原因になって起きることが殆どです。「後工程」が原因で失敗することは殆どありません。
 何故かと言えば後工程は修正や回復、復旧が容易だからです。
例えば設計が正く、開発の段階でプログラマーの能力が不十分で十分な品質を実現できなかった場合は早い段階でプログラマーの人選を見直すことができます。開発チーム全てのプログラマーが能力不足ということはほぼ無いので人選の見直しは通常一部です。
 テストや移行などもやってみてダメならやり直せば良く、失敗の影響も後工程ほど小さくなります。
 前工程の失敗はその後の工程の手戻り作業となる為、前工程になるほど失敗の悪影響が大きくなります。(3)設計が間違っていて、それが(4)開発で発覚した場合、一度設計に戻ってやり直し、もう一度開発もやり直さなければなりません。間違いの場所によってはそれまで開発した全てのプログラムを修正しなければならなくなり大幅に納期が遅れたりします。(1)システム構想(2)要求分析(3)要件定義の最前工程の間違いはその後の工程全てをやり直ししなければならなくなる為、影響が大きくなります。
 つまり、前工程の失敗が原因となりシステム開発全体が失敗する率が高いのは、前工程で失敗する人が多い訳では無く、前工程で失敗したときの影響がより大きいからです。
 ミスする確率は前工程も後工程も変わらないと思います。
 移行で失敗するケースは移行の設計で失敗していることが多く、その原因も移行対象となるシステムの要件定義や設計の部分に問題があって失敗していることが殆どです。
 テストが不十分で失敗するケースは全て「品質」の問題だけだけでありプログラムの改修だけで解決できる為、致命的な問題になりにくいです。回復に掛かる費用もそれほど大きくなりません。

 致命的な失敗の原因は殆ど「前工程」が原因で起きるとお考えください。
(1)システム構想(2)要求分析(3)要件定義の前工程はシステム開発の成否を左右する重要な工程です。そしてこの工程は実業務の専門家である「発注者」がITエンジニアやコンサルの助言指導を受けながら作業を行わなければならない工程です。
 発注者の多くは「システム開発はITベンダーに全部やってもらうもの」と勘違いしている場合が多くあるのだが、実際は前工程ほど実業務の専門家である業務担当者が主体的積極的に参画しないと失敗するものなのです。

 私の経験や過去の同僚や同業者の話から言えることは、「システム開発前工程の失敗の大半は発注元企業の無知と非協力的態度にある」と言えるでしょう。
 逆に考えれば「発注元企業がシステム開発について熟知しており協力的」であればシステム開発の成功確率は大幅に増えるのです。
「システム開発に熟知」といっても自らシステムを開発できるほどの専門性は必要なく、システム発注の基礎知識があれば良いのです。あとITベンダーの内輪事情なども知っておいた方が良いと思います。
 自らの努力で自らの損害を防ぐことができるのであれば、多くの発注元企業は(余程バカでなければ)努力を惜しまないのではないでしょうか?
 
 このブログでは主にIT素人の発注者向けにシステム開発の基礎知識を書いていきたいと思っています。ブログ執筆は初めてなので色々変な文書も書くかも知れませんがそこは「ご愛敬」ということでよろしくお願いします。

 また、システム以外にも「働き方」「生き方」「道徳常識」「経済政策」などについては書いていくと思います。こちらもよろしくお願いします。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ