システム開発の失敗要因
ＰＭさん！大丈夫？ 実は最初から分かる失敗プロジェクト
システム開発の失敗要因その１
システム開発の失敗には多くの要素があります。
ちょっとしたことでも顧客企業とトラブルになり新聞記事にも載ってしまいますのでプロジェクト責任者は気が気ではありませんね（業務や会社にもよりますが）。それに加えて失敗するとリカバリーするために多大なコスト費用が発生したり、弁護士に依頼して訴訟問題に発展するケースもあります。現場SEもプログラマーも時間外が増えて疲労困憊状態になり、俗にいう修羅場に陥ります。他人の批判や責任逃れなど行っている場合はではありません。一刻も早く現場を正常化して立て直しが必要ですが、立て直すつもりが気が付いた時には手遅れになることもあります。火消が終わって正常になっても「こんな現場では二度と働きたくない！」というIT人材も多く、プロジェクトのクローズミーティングも開催されない、または開催されても当たり前の反省事項が議事録としてつらつらと残っているだけで、次回には決して生かされません。厳しい与えられた予算の中でプロジェクトを消化することは、技術力だけでは達成できません。ＰＭと言われている管理者の経験やコミュニケーション能力が必要です。
極端な事例を冒頭に書きましたが、歴史のあるシステム開発会社であれば大企業も中小企業も関係なく、トラブルの大小も関係なく経験していると思います。失敗原因を究明して反省事項のレポートを第三者として確認してもあまり意味がなく、トラブルの原因などは表には出ない内面のどろどろした構造があったりするものです。また失敗事例とかで一度取り上げられると二度と立ち上がれない管理者もいたり、次のプロジェクトで正常に業務をこなすまでには時間が必要です。これは我々同様IT業界で働く人たちの課題テーマかもしれませんね。技術者のモチベーションも大切な要素ですが、管理するマネージャーの力量や企業の姿勢など人的要因以外に会社の仕組みの問題もあります。また仕事を依頼する側の発注側顧客企業にも受注側企業の要素と同じぐらい多くの原因要素があります。それぞれがうまくかみ合わないとちょっとした意識のズレが最終的に大きな問題になるケースも多々あります。
実は小生かれこれ３０年以上１０００を超えるソフトウエア開発プロジェクトに関わってきましたが、
昔と違って最近では失敗と言われるitプロジェクトは”ゼロ”になりました。最近５年ぐらいはシステム開発において失敗プロジェクトはありません。その成功要因はいろいろあるのですが、最近の技術は簡単にプログラムを製作できることや簡単に可視化して初期フェーズからユーザ目線でレビューが繰り返されるという面などが大きなストロングポイントだと思われます。そんな経験をもとに失敗しない為のポイントを解説していきたいと思います。
昔と違って最近のシステム開発では失敗しない要素
- 安定したパッケージシステムが主流となり、スクラッチ開発が少ない。※リスクが少ない。
- 販売、財務、会計、給与、人事、生産管理など一般的な業務は標準化されクラウドサービスを利用するケースが多い。
- ＩＴコンサルタントなどの活躍。※ＩＴシステム導入前に開発システムの目的、現状課題など内容を整理するケースが多い。
- ＩＴ化やＤＸ化は企業にとって重要なんだという意識が経営者に埋め込まれた。※経営者が自らコミットするケースも多い。
- ＩＴ化やシステム構築で企業内課題をなんでも解決できるという考えがなくなった。※システムは経営を支援する単なるツール。
- 営業対応見積もり段階で精度の高い可視化が可能になった。※モックなど事前確認して差異が生じない工夫。
- 全体的な日本国内のＩＴリテラシー向上。※まだまだ諸外国と比べると遅れていますが。
- ハードウエア資源の性能向上。※処理スピードなどは以前と比べ物にならないほど速い。
- 便利で安価な進捗管理ツールが多く顧客企業と情報共有が密にできる。
- ソフトウエア開発ツールや技術が格段に進歩。
がしかし、それでも”失敗しそうな”予感のするプロジェクトはあります。
そしてそのプロジェクトにアドバイスを入れるポイントは初期段階で具体的な行動をしなければなりません。
ではどんな要因でプロジェクトが失敗するのでしょうか？
- リーダーが多忙（複数ＰＪ掛け持ち、実際にコードも書いている。プロジェクト管理能力の問題など）
- 体制に問題あり（メンバスキル不足、教育担当無し）
- 要求事項があいまい（要件定義決議以降も仕様がころころ変わる。要望をそのまま実現しようとする。）
- スケジュールが厳しい（納期が短いのに対策していない）
- ＱＡ対応時に返答スピードが遅い（作業遅延の最大の理由）
- 新規業務、新技術、経験不足（初物なのに分析時間も無い）
- 機能単位でテスト項目が不足（テストデータ不足、モーラ率が低い）
- 仕様決定関係者が多すぎる（無責任なたらい回し）
- プロセスに拘り過ぎで資料作りと稟議が多すぎる（無理無駄多い）
- キックオフをしてくれない（忙しいのはわかりますがＮＧ）
- 打合せ中に過去の失敗を責める上から目線上司の存在！
- メンバーのモチベーションが低い（様々な理由でしょうけど）
- 無責任なＰＭ（そもそもＰＭを担当してはダメでしょ）
- 自分の失敗を他人に押し付けるメンバーの存在
- 顧客側とのコミュニケーションが少ない（机上はやめましょう）
- 契約時点で作成する成果物の確認不足（INとAUTO）の確認不足（最終フェーズで失敗）
システム開発の失敗事例あるある
- webシステム開発でよくある失敗は、セキュリティや曖昧な負荷テストによりレスポンスが悪い、データ漏洩事件
業務システム開発の経験があることと、webシステム開発の経験があることには大きな差があります。業者選定時に必ず注意してください。
- アプリ開発でよくある失敗は、大金かけて開発したけど、市場分析不足によりアプリがダウンロードされない
これもあるあるですが、経営層の考え方や方向性が最初から間違っているパターンです。プロダクトを売るのではなく、あくまでもビジネスモデルを市場に出していくのですから、市場分析が甘かったと言えます。このような場合にはmvp開発が向いています。
- 新規事業とともに支援システム開発をしたが、想定機能が使われない
- とにかくシステム品質が悪い
システムの機能性や操作性が悪く、想定していた効果が出ずに失敗に終わる場合があります。システム障害が出て起動しなくなるなどの故障が起きた場合も「システム品質が悪い」と評価します。しかし、システムの品質の悪さはシステム開発会社側が悪いとは限りません。要件定義（システム開発に求める条件を決めること）を行う際に、希望を伝えそびれてしまうなど、依頼者側にも問題がある場合もあります。
- 約束した納期が延びる
最初に立てた計画通りにシステム開発が進むとは限りません。予定が変更となり、納期が延びてしまう恐れもあるでしょう。納期の遅れにより、売上などに大きな影響が出て大きな被害を出ることもあります。
- 開発コストが膨れ上がり追加請求される
システム開発費は「単価×工数」で計算されるため、開発工程で手直しが発生した場合は、コストが膨れ上がってしまうのです。そのため、システム完成後に追加料金が請求されるなど料金トラブルが発生します。
- いつまで経ってもシステムが完成しない
経営層はプロジェクト責任者から報告を受けた期日にシステムが完成し、現場でシステムが稼働して、業務が効率化することを期待します。しかし、完成予定日になってもシステム完成の報告はなく、気が付くとシステムが完成予定日から数カ月経っても完成していない失敗例です。システムが予定通りに完成しない原因は多く存在しますが、最も多い原因は開発中に想定外の必要機能が発覚し、機能追加しないとシステムが動かないために開発期間が伸びるパターンです。この失敗は開発段階前の要件定義で業務要件や必要機能を洗い出せていないために生じる問題です。
- 完成したシステムがイメージしたものと違う
システムが予定通りに完成したが、完成品を確認すると要望していたシステムと全く違うシステムになっている失敗パターンです。納期通りに完成したとしても、完成品が要望とするシステムと異なる場合は全く意味のないシステムになってしまいます。このケースは要件定義段階は発注者と開発会社が密なコミュニケーションをとっていましたが、開発フェーズに入った途端、コミュニケーションが希薄になり、発注者が成果物を確認することなく開発が進んでしまった場合に起こります。要望通りのシステムにならなかった原因が開発会社にある場合は、無償で修正できますが、多くの場合は発注者側にも責任があるケースが多く、その場合は当初の開発予算相当の追加費用と時間をかけて、再度システムを開発しなおすことになります。
なぜシステム開発を失敗するのか
失敗する事例
- 発注者側の開発するシステム要件が固まっていない
開発会社はあくまでも要望されたシステムを開発するのが仕事であり、どんなシステムにしたいか、どんな機能が必要になるのかは発注者側が明確にする必要があります。開発するシステム要件が発注者側で明確に固まっていないまま開発が進んだ場合には、システム開発は失敗します。発注者は曖昧な説明をしても、「開発会社が補ってくれるだろう」と考えているかもしれませんが、開発会社は与えられた情報や要件以外はシステムに反映してくれません。そのため、開発者側はシステムを開発する目的と目的を達成するためにどんな機能が必要なのかを明確にして、開発会社に情報提供する必要があります。システム投資を判断する経営層も事前に課題を解決するシステム要件であるかを確認したうえで投資判断をする必要があります。
- プロジェクトメンバ－が多すぎる
失敗するシステム開発は、システム開発プロジェクトに関わる人数が多いです。多くの意見をシステム開発に取り込むことを目的として、プロジェクトメンバーを増やすあまり、優先度の低い意見や機能要望が溢れてしまい、結果として、社内で要件をまとめきれなくなることがあります。人数が多ければ多いほど、メンバー全員の合意をとるにも時間が必要になるので、予定していたスケジュール内での発注者側の決定が遅れ、開発スケジュールが遅延することもあり得ます。プロジェクトメンバーが多いほうが、いいシステムができると思われがちですが、人数が多ければ多いほど、プロジェクトに弊害をもたらすことになります。
- 開発会社との認識のずれ
発注者と開発会社に認識のずれがある場合、システム開発失敗に直結します。開発会社はシステム開発は得意ですが、発注者側の業務や企業文化に関しては知識を持っていない素人同然です。そのため、「分かっているだろう」、「言わなくても通じている」と十分な認識合わせをせずに、開発を進めてしまうと、完成後に大きな後悔をすることになります。手間がかかる作業ですが、発注者は懇切丁寧に業務要件や要望を開発会社に伝えることが重要です。開発会社からシステム要件に対して質問がないから認識がとれたと思うのは大きな間違いです。
- 開発フェーズを管理していない
要件定義が終わった後に開発会社任せにすると、システム開発は失敗します。多くの場合、発注者は要件定義フェーズが終わると安心してしまい、開発フェーズを全て開発会社に任せて、進捗報告だけ聞いて満足してしまいがちです。しかし、要件定義が終わった後も発注者はシステムの開発進捗を詳細まで管理する必要があります。開発期間中の成果物の確認など怠った結果、完成後に開発ミスや認識間違いに気づきますが、時すでに遅しです。
- BtoCの止められないオンラインシステムでのテスト不足
BtoCで販売管理、在庫管理、物流管理、それぞれの業務が密接に連携しているようなオンラインシステムの機能強化やカスタマイズリリース、それに伴うバージョンアップ等、新規開発と比べて開発費用は高くはありませんが、その代りテスト作業の難易度は高いものです。前述しましたが、本来のあるべき作業通り開発はおこなったとしても、データ連携が存在しているオンライン業務システムについては、各業務を把握しているメンバーと仕様書を理解しているメンバー、並びにベテランプログラマー、AWS等サーバーやネットワークインフラのメンバーなど、各分野が協力して作業を実施することがベストとなります。また本番ステージング環境へのマージ、リリースに関しては夜間又は休日を利用して作業するしかありませんので、テスト環境とステージング環境の同期をとる必要があり、各業務間はリアルタイムで連携していますので、テストデータの作り方も複雑です。それにも関わらずテスト計画の準備不足、リハーサルをしない、仕様書を信じて製造したが、稼働中のプログラムと仕様書に差異があり、テスト中に発見できれば幸いですが、見つからずにリリースしてしまって、大きなトラブルになることもあります。ここでお伝えしたいのは、入念なテストをするために十分な時間をとる必要があるということです。止められないオンラインシステムについては、ミスがミスを呼び、徹夜作業になることもしばしば。メンバーの疲労も重なり、身体を壊すどころか精神的なダメージが大きくなります。こんな作業は二度と経験したくないですよね。移行作業については別のコラムをご覧ください。
- 開発フェーズを管理していない
要件定義が終わった後に開発会社任せにすると、システム開発は失敗します。多くの場合、発注者は要件定義フェーズが終わると安心してしまい、開発フェーズを全て開発会社に任せて、進捗報告だけ聞いて満足してしまいがちです。しかし、要件定義が終わった後も発注者はシステムの開発進捗を詳細まで管理する必要があります。開発期間中の成果物の確認など怠った結果、完成後に開発ミスや認識間違いに気づきますが、時すでに遅しです。
システム開発の苦労話
システム開発には苦労が多い
最近は大きなトラブルになることはありませんが、それでも稀に残業が発生したり、突発的な顧客からの連絡により、緊急調査を強いられることもあります。保守契約の有無に関わらず、お客様が困っているときは助けてあげたくなるのも技術者の心得？とかっこいいことを言いながら、手出しをしたばかりに２日連続徹夜してしまうこともありますよね。大きなシステムになればなるほど長年利用してきたために、プログラムが継ぎ接ぎだらけになっていたり、過去の仕様書が無い、あっても実際のコードと合致しておらず、動かないトラブルの要因が解明できないこともあります。大工さんの仕事と同じで、現場に行って、深く穿ってみて初めて原因がわかります。
また話は変わりますが、開発中にお客様の要求を決定するタイミングが遅い場合があります。遅いだけなら待てば良いのですが、多忙を極めるお客様なので、曖昧なままちゃんと仕様を確認してもらえず、そのままコードを記述すると大変なしっぺ返しにあいます。
後々になってユーザ本番を迎えて以降、緊急呼び出しのパターンに陥ります。開発側からすると仕様書通りだし、言い訳したくなりますが、黙ってとにかく早く改修するしかありませんね。なぜなら言い訳しても何も終わらないですから
このようにシステム開発、システム開発技術者泣かせのお客様と一緒に作業をすることになると覚悟が必要となります。正常なプロジェクト進行をしていても、認識のずれは発生します。これは何度もレビューすることによって防ぐことができます。品質を高めるためのレビューは、仕様書レビュー、コードレビュー、テスト仕様書レビュー、結合テストレビュー、内部レビューとお客様向け外部レビューを実施すれば、品質は上がります。
毎日残業をするような状況は誰しも疲れますし、追加や変更が上流段階から多発しているプロジェクトは必ず、下流工程で本番直前で修正残業が発生してしまいます。そしてこのような後戻り作業はモチベーションが低下してしまいますし、せっかく残業してもお客様も喜んでいただけないのです。
話題が現実的で暗くなってきたので、苦労話の体験談はこの程度にしておきますが、どのような方法で改善できるのか。これがシステム会社、システム会社で働く技術者の心得によって差が出てくるポイントだと考えます。
システム開発失敗は発注者側の準備不足が原因
実はこの記事をご覧になられている方には申し訳ないのですが、これまで企業がシステム開発失敗に陥る原因とシステム化を成功させるポイントを解説してきましたが、企業がシステム開発に失敗するのは発注者側の準備不足が原因です。これが小生の持論です。そのため、企業がシステム開発を成功させるためには、発注者側が以下の4つポイントに関して入念な準備を行う必要があります。一度契約して取引を始めたら、なかなか後戻りはできないものです。ユーザーだから上から目線はおすすめしません。双方でWINWINの関係でチェックする必要がありますね。
- システムの目的を明確にする
- 優先順位を明確にする
- 業務内容を理解する
- システム開発のトレンドを理解する
詳細については次回のコラムで成功要因を解説いたしますので、それをご覧ください。
オンライン開発主流の中で工夫する
苦労はどんな仕事でもありますから、少し前向きな最近実行して効果が出ているお話をいたします。ZOOMやTEAMSでの会議が多くなっていますが、ちょこちょこ会話やなんでもないチャットが円滑なコミュニケーションにおすすめです
- ZOOMやTEAMSでの会議ではアイスブレークから始めましょう
- slack等のチャットは情報共有がメイン。挨拶や世間話もＯＫ
- 仕様検討はslack等のチャットでしない。ZOOMやTEMSで
- backlogやredmine進捗管理ツールは更新記録するルールを決めて
- backlogやredmine進捗管理ツールに頼り過ぎない方が良い
- プロジェクト管理ツールの情報更新は勤務時間中に。休日や夜中の更新は止めて
是非実行してみてください。それぞれ理由がありますが、オンラインツールは便利ですが頼り過ぎないことがポイントです。それといつでもどこでも情報を更新できるメリットがありますが、在宅勤務などが主流になり、ついつい自分の自由なプライベート時間に仕事をしてしまう仕事大好き人間もいらっしゃいます。しかしながら相手が更新するだけでメール通知が気づきとなり飛んできます。飛んでくるとついついパソコンやスマホで確認してしまう行為が、ダラダラと仕事依存症に陥ってメリハリが付かなくなります。
いかがでしたでしょうか？企業活動にとってシステム開発は必須となった世の中です。コロナ禍でFACEtoFACEができない分、便利なチャットツールやオンライン打合せなどが当たり前の時代になって、それに順応するだけでも大変だと思いますが、逆にコミュニケーションが改善された面もありますね。俗に言うちょこちょこチャットは有効だと証明されました。骨太のシステム、小さな業務改善システム、売り上げを拡大するための予測システムなどなど、企業様には様々なニーズがあって、これからの厳しい時代を安定した経営基盤にするためには、システムプロダクトは経営と両輪となります。今回の記事は、いろいろお悩みのベンダー様、システム導入検討中の企業様のご相談に少しでもお役に立ちましたでしょうか？次回は成功要因をコラムします！
