• HOME
  • COLUMN
  • 【2】システム開発の依頼前に知るべき成功のポイント解説|失敗事例の紹介と「目的設定」の重要性
COLUMN コラム

【2】システム開発の依頼前に知るべき成功のポイント解説|失敗事例の紹介と「目的設定」の重要性

システム開発の成功は「目的」で決まる!失敗事例から学ぶ業務最適化の重要ポイントと工程

「多額の費用を投じたシステムが現場で使われない」という失敗は、実は開発が始まる前の段階で決まっています。成功の鍵を握るのは、高度な技術ではなく「目的設定」の解像度です。

本記事では、システム開発の依頼前に整理すべきポイントを失敗事例と共に解説。ベンダー任せにせず、企業が主導して業務最適化を実現するための鉄則を紹介します。

「なぜ、このシステムを作るのか?」──依頼前に整理すべき目的設定と重要ポイント

依頼前に整理すべき目的設定と重要ポイント

プロジェクトが迷走し始めるきっかけは、技術的な不備ではなく、ごく単純な「問い」を置き去りにした瞬間に潜んでいる。

会議室に響いた素朴な疑問|業務最適化に向けた考え方

ある週の定例ミーティング後、ハルヤは会議室の隅で腕を組み、首をかしげていた。

「そもそも、このプロジェクトって……なんで始まったんでしたっけ?」

アリサが少し笑って答える。

「え、上から“効率化のため”って言われたじゃない。私たちはそれに従ってるだけだよ、ハルヤ。」

ハルヤは納得がいかない表情だ。

「でもさ、“効率化”って便利な言葉だけど、人によって意味が違うじゃないですか。何を効率化したいのか、ちゃんと聞いたことあります?」

そこにCTO が入ってきた。

「いい質問だ、ハルヤ。実はこの“なぜ作るのか”を明確にしないまま走り出す案件が、驚くほど多いんだ。」

ハルヤ:「でもCTO さん、“システム作る”って、それだけでみんなやる気出すんじゃないですか?」

CTO:「いや、それは逆だ。目的が曖昧だと、途中で“やる気”がバラバラの方向に進んでしまう。君ら、前回の判決文を思い出せ。あの案件も、目的の共有ができていなかった。」

アリサ:「目的なんて会議で一度説明すればいいんじゃ?」

CTO:「一度じゃダメだ。目的は“文書化”して、“繰り返し説明”して、“全員が同じ言葉で言える”状態にしなければならない。

ハルヤ:「でも、それってベンダーがやってくれるんじゃ……」

CTO:「ベンダーは“作る”のが仕事だ。目的の設定は発注者の責任だ。もしそこを外注したら、君たちが何を得たいのかを他人に丸投げすることになる。」

アリサ:「……それじゃ、システムの成功って、ほぼ最初の目的設定で決まるってことですか?」

CTO:「そうだ。目的が曖昧なプロジェクトは、成功の確率が一気に下がる。」

解説|目的設定はシステム開発の成功を決める“スタート地点”

目的設定は、単なるスローガンではない。システム開発の全フェーズの判断基準になる。特に重要なのは以下の3 点。

  1. 共通認識の形成
    • 経営層・業務部門・IT部門が同じ言葉で目的を語れるか
  2. 成果の定義
    • 効果測定のための具体的な数値(例:年間保守費1,000 万円削減)
  3. 優先順位付け
    • 複数の目的がある場合、何を最優先とするか

目的が曖昧だと、要件定義や設計時に「これも便利だから追加しましょう」という**機能肥大化(スコープクリープ)**が発生しやすくなる。結果、コスト超過や納期遅延が起きやすくなる。

企業が陥りやすい「目的のない開発」にありがちな失敗例

ケース失敗の内容本来あるべき姿
A 社:基幹システムの刷新「老朽化が心配だから入れ替えよう」として導入。しかし業務の見直しはせず、結果的に前より使いにくいシステムに現状業務の課題を整理し、再設計したうえでシステム要件を設定すべきだった
B 社:営業管理ツールの導入上層部のDX指示でツール導入。しかし営業現場では活用されず「入力が面倒」と放置目的(例:訪問効率の可視化)を共有し、運用方針を現場と共に作るべきだった

類似のトラブル事例|事務効率化が招いた営業効率の低下

類似のトラブル事例

目的の不一致がいかにしてプロジェクトを破綻させ、企業に手痛い損失をもたらすのか、その典型的な失敗の軌跡を辿る。

背景|経営層とIT部門で異なる「サービス導入」の考え方

ある金融機関は「事務効率化」を目的に営業支援システムを導入することを決定。経営層は「顧客対応時間を減らし、営業活動を増やす」ことを狙い、IT部門は「既存システムの保守費削減」を重視していた。

経緯|業務現場への説明不足と工程の進め方のミス

  • 業務部門には「今の業務を変えず、画面が便利になる」程度の説明しかされなかった
  • 要件定義段階で経営層・IT部門の優先度が高く、現場要望は後回し
  • 設計後、現場が使っていた現行Excelツールが要件に含まれていないことが判明

結果|多額の費用を投じたシステムが活用されない現実

  • 導入後、現場は新システムを使わず、旧Excelツールを継続利用
  • 保守費は削減されたが、営業効率はむしろ低下

追加改修に数千万円を要し、導入効果はほぼゼロに

教訓|開発会社への依頼・契約前に作成すべき「共通認識」の重要性

  • 目的は全関係者に同じレベルで共有すべき
  • 説明不足は誤解と抵抗を生む

リストに戻る