明日の自分をアップデート!

  1. マネジメント
  2. 7 view

【失敗例】スモールスタートはシステム開発の基本!でもそれだけじゃ失敗する

最終更新日: 2021.05.21

開発ベンダーとの打ち合わせで、「まずは小さくはじめましょう」と言われたことはないでしょうか。

スモールスタートは低コスト短納期で運用を開始でき、ベンダーに取っても開発がコントロールしやすいため、発注側、受注側双方にとってメリットが大きい手法です。

ただ、最初に最終ゴールまでの緻密な計画を立てておかないと失敗しやすい手法でもあります。

今回はスモールスタートで陥りやすい失敗例についてご紹介いたします。

最初は1拠点から。段階的に導入拠点を広げる計画が…

失敗例

海外に多くの子会社を抱えるA社。基幹システムのパッケージを購入し、徐々に全拠点に広げる計画を立てていました。プロジェクト開始から3年後。最初の拠点へのシステム導入が完了し、運用上の課題や不足機能も見えてきています。

これらを改善し次の拠点への導入を始めようとした矢先、パッケージシステムの販売終了が決定してしまいました。

全拠点にシステム導入するまではサポートを続けてもらえるとのことでしたが、これではプロジェクト終了後すぐに次のシステムについて検討しなくてはいけません。

結局、全拠点に入れた後に長く使うことができないということで、もう一度システム選定からやり直すことになってしまいました。

まずは1社にシステム導入して機能の過不足を洗い出すというのは、リスク管理の点では理に適っています。

しかし、導入計画が長期的すぎてサービスの終了リスクについて考慮ができていませんでした。

スモールスタートは「まずは導入」というところに意識が行きがちで、その後はアジャイル的な進め方になりがちです。

「いつまでに導入を完了させるか」最初にしっかり計画できていれば、このトラブルは防げたかもしれません。

技術の進歩に振り回されて…

失敗例

基幹システムの刷新を検討しているB社。ERPを導入しデータを素早く正確に集めることを目的としたプロジェクトを立ち上げました。

ERPは販売管理や会計などのサブシステムが多岐に渡るため、まずは会計システム、次に販売管理システムという形で段階的にシステム導入する形で進めることにしています。

しかし、技術進歩の流れは速く、クラウド、Fintech(フィンテック)、IoTの話題が多く聞こえるようになってきました。

最初は順調にシステムの入れ替えが進んでいましたが、経営層からはクラウド化への対応、Fintech(フィンテック)の導入の声が日に日に強くなっています。

実はERPパッケージをバージョンアップすることでこれらの新技術には対応できることが分かっています。

しかし、それには導入済みのシステムの一部再設計が必要となるため、戻り作業となってしまいます。

結局、全システムの入れ替えが終わる前よりはダメージが小さいということで導入済みシステムの見直しに着手することになってしまいました。

全システムの入れ替えが完了するのはいつになるのか、今ではまったく見通しが立ちません。

IT技術は進化の流れが速く、文字通り日進月歩で新技術が登場しています。

プロジェクト当時は最先端だった仕組みや考え方も数年後には陳腐化してしまう恐れがあるのです。

スモールスタートは段階的なシステム導入を可能としますが、導入済みシステムのバージョンアップが大変で、結局次のシステム導入にたどりつけない、という計画倒れになってしまう可能性あります。

どうなれば終わりなの?

失敗例

オーダーメードでシステム開発を検討しているC社。複数のシステムにまたがっていて連携が悪い業務を一つにまとめたいと考えています。

現在利用中のシステムには全く使ってない機能もいくつかあるのですが、どれが必要でどれがいらないか、全体が把握できていません。

そこで、まずは絶対に必要と分かっている最低限の機能だけを集めたシステムを作成し、たまにしか使わなかったりあると便利な機能は必要な都度追加していくスモールスタートの形を取ることにしました。

最低限の機能だけを集めて運用開始したまでは良かったものの、利用者からは「これもほしい」「あれもあった方がいい」と機能追加の希望が後を絶ちません。

当初は1年の運用で必要な機能とそうでない機能の住み分けがはっきりすると想定していましたが、業務担当者の入れ替わりが激しいこともあり、終息のめどが立たなくなってしまいました。

このままでは、結局全機能を移植することになってしまいそうです。

スモールスタートは小さく始められることが最大のメリットですが、終了までの道筋が見えてないと、終わりのないプロジェクトを続けることになってしまいます。

場合によっては「いつの間にかプロジェクトが消滅していた!」なんてこともあるでしょう。

最初の段階で「終了条件」をはっきりさせておくことが重要なのです。

それでもスモールスタートは多くのプロジェクトの最適解である

いかがでしたでしょうか。

スモールスタートの失敗例をご紹介させていただきましたが、私はスモールスタート否定派ではありません。むしろ、推奨派です。

小さく始めることで軌道修正が簡単ですし、最悪やめることもできます。またベンダーに伝える要件もシンプルになるため品質は上がりやすく、自社業務を知ってもらうというの教育の面でも効率的です。

今回ご紹介したような失敗例にならないためにも、事前にしっかり計画を立てた上で、スモールスタートをうまく活用したいですね。

関連記事

コメント

  • コメント (0)

  • トラックバックは利用できません。

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

CAPTCHA


PAGE TOP