メルマガ配信中!登録はこちらから

システム開発の失敗を恐れてベンダーに丸投げしていたはずが、真因は業務要求仕様の不在にあった――中堅企業の基幹システム刷新支援事例

Estimated reading time: 12

基幹システムの刷新プロジェクトが始まった。
外部ベンダーに要件定義から任せ、IT部門は進捗管理とベンダーコントロールに徹する。
経営からは「失敗しないように」とプレッシャーがかかり、現場からは「使いにくくならないか」と不安の声が上がる。

中堅企業のシステム開発では、こうした状況が珍しくありません。
今回ご相談いただいた案件も、「基幹システム刷新の成功率を高めたい」「ベンダー任せで失敗したくない」が主題でした。
実際、過去の開発案件では、要件定義の曖昧さ、開発後の手戻り、予算超過、業務部門との認識齟齬など、典型的な課題が複数見えていました。

しかし、ヒアリングと検討を重ねる中で、表面上のプロジェクト管理課題の奥に、
より本質的な問題があることが明らかになりました。

それは、業務要求仕様の作成プロセスが自社に存在しないことです。

目次

  • 背景・相談のきっかけ
  • 当初見えていた課題
  • 真因の特定――システム開発失敗の背後にあった業務要求仕様の不在
  • 支援内容――「ベンダーコントロール」から「業務要求仕様の内製化」へ支援テーマを再定義
  • 実施後の変化
  • この事例から得られる示唆
  • まとめ

背景・相談のきっかけ

IT部門は、基幹システムの老朽化に伴う刷新プロジェクトの準備を進めていました。
過去の開発案件では、外部ベンダーに要件定義から設計・開発まで一括発注し、IT部門はプロジェクト管理とベンダーとの調整に注力していました。
しかし、開発が進むにつれて「話が違う」「こんな仕様は頼んでいない」といったトラブルが頻発し、結果として予算超過やスケジュール遅延、稼働後の現場不満が発生していました。

今回の刷新プロジェクトでは、
「同じ失敗を繰り返したくない」
「もっと精度の高い要件定義をしたい」
「業務部門とIT部門が同じ方向を向けるようにしたい」
という強い危機感がありました。

つまり、ベンダー選定やプロジェクト管理手法の改善以前に、発注者側が「何を作るべきか」を明確にする力が不足していたのです。

当初見えていた課題

初期段階では、課題は主に次のように整理されていました。

  1. 要件定義の精度が低いこと。ベンダーに丸投げしているため、業務部門の「やりたいこと」がシステム要件に正確に変換されず、開発後に「想定と違う」というギャップが発生していました。
  2. 業務部門とIT部門の認識齟齬。業務部門は「現場の課題を解決してほしい」と期待し、IT部門は「システムの仕様を決めてほしい」と求め、双方の期待値が合わないまま要件定義が進んでいました。
  3. ベンダー依存からの脱却ができないこと。IT部門には業務フロー分析やシステム要件整理のスキルが不足しており、結果としてベンダーに頼らざるを得ない構造が続いていました。

ここだけを見ると、「要件定義の研修を受ける」「業務部門との定例会議を増やす」「ベンダー選定基準を見直す」といった打ち手が自然です。
実際、当初の支援もその方向から始まりました。

真因の特定――システム開発失敗の背後にあった業務要求仕様の不在

しかし、検討を進めると、個別施策を打っても成果が出にくい構造が見えてきました。
それは、システム開発における「業務要求仕様」という工程そのものが、社内のプロセスとして確立されていなかったことです。

一般的なシステム開発プロセスは、業務要求仕様(業務側が主体)、システム要件定義(IT側が主体)、システム基本設計・詳細設計(ベンダーが主体)という階層構造になっています。

ところが、この企業では「業務要求仕様」の工程が存在せず、いきなり「システム要件定義」からベンダーに依頼していました。
そのため、業務部門は「何が必要か」を言語化できないまま要件定義会議に参加する、IT部門は「業務の理解」が不十分なままベンダーに発注する、ベンダーは「あるべき業務の姿」が見えないままシステム仕様を作る、という三者三様の不完全な状態で、プロジェクトが進んでいたのです。

業務要求仕様は「ベンダーに渡す仕様書」ではなく、「業務側が何を実現したいかを明確にするプロセス」として位置づけるべきでした。

つまり、真因は単なるベンダーコントロールやプロジェクト管理の技術ではありませんでした。
「新しい業務の姿(To-Be)」「業務フロー・IPO(Input-Process-Output)」「業務ルールとIT要求の分離」が構造化されていないことが、システム開発の失敗を繰り返す上流要因になっていたのです。

支援内容――「ベンダーコントロール」から「業務要求仕様の内製化」へ支援テーマを再定義

そこで支援の軸を、単発のプロジェクト管理強化から、業務要求仕様の作成体制構築へと切り替えました。
具体的には、次の3ステップで再設計を進めました。

まず、業務要求仕様の標準プロセスを設計しました。As-Is業務フロー分析、問題・原因・課題の整理、To-Be業務フロー設計、IPO(Input-Process-Output)定義、業務ルールとIT仕様の分離、という5つのステップを標準化し、IT部門と業務部門が協働で進めるプロセスとして整備しました。この工程により、「業務側が何を実現したいか」を明確にしてからシステム要件定義に進む流れが確立されました。

次に、IT部門の業務分析スキル強化を実施しました。業務フロー図の書き方、IPO表の作成手法、DFD(Data Flow Diagram)によるシステムスコープ整理、ER図の読み方など、業務要求仕様を作成するために必要なスキルをOJT形式で習得しました。また、業務部門へのヒアリング技法や課題整理のフレームワークも合わせて教育し、「業務を理解してシステム化する力」を組織に定着させました。

さらに、ベンダーとの役割分担を再定義しました。業務要求仕様書は自社で作成し、ベンダーにはシステム要件定義以降を依頼する、という明確な役割分担を設定しました。これにより、ベンダーは「何を作るべきか」が明確な状態で設計に入れるため、手戻りや認識齟齬が大幅に減少しました。また、発注仕様書の精度が上がることで、見積精度の向上や契約リスクの低減にもつながりました。

実施後の変化

約6ヶ月の支援を経て、以下の変化が生まれました。

定量面では、業務要求仕様書の標準フォーマットが完成し、IT部門と業務部門が協働で作成するプロセスが確立されました。また、次期システム開発案件において、業務要求仕様書を自社で作成し、ベンダーへの発注精度が大幅に向上しました。

定性面では、「何をベンダーに頼むべきか」「何を自社で決めるべきか」という役割分担の線引きが明確になり、IT部門の自信が高まりました。また、業務部門との対話の質が向上し、「システム開発は丸投げするもの」から「業務改善とシステム化を一体で進めるもの」という認識に変化しました。

さらに、業務要求仕様を作成する過程で、「現行業務の非効率性」や「部署間の業務ルールの不統一」といった、システム化以前の業務課題も可視化されました。
これにより、システム開発プロジェクトが単なるIT投資ではなく、業務改革の契機として位置づけられるようになりました。

この事例から得られる示唆

システム開発が失敗する原因として、多くの企業はベンダー選定やプロジェクト管理手法に目を向けます。
もちろんそれらは重要です。

ただし、発注者側が「何を作るべきか」を明確にできていなければ、どんなに優秀なベンダーを選んでも、どんなに厳密なプロジェクト管理を行っても、失敗は避けられません。

第一に、業務要求仕様はIT部門ではなく、業務部門と協働で作るものです。業務部門は「現場の課題」を知っており、IT部門は「システム化の可能性」を知っています。この両者が協働してはじめて、実現可能で価値のある業務要求仕様が作れます。

第二に、業務要求仕様の作成は、システム開発の成功率を高めるだけでなく、業務改革の起点にもなります。業務フローを可視化し、問題・原因・課題を整理し、To-Beの姿を描く過程で、システム化以前の業務課題が明らかになります。この気づきが、組織全体の業務品質向上につながります。

第三に、ベンダー依存からの脱却は、内製化スキルの習得から始まります。業務要求仕様を自社で作れるようになれば、ベンダーへの発注精度が上がり、見積精度も向上し、契約リスクも低減します。結果として、ベンダーとの対等なパートナーシップが築けるようになります。

まとめ

「システム開発を成功させたい」という相談から始まったはずが、掘り下げた結果、真因が業務要求仕様の不在にあった。

この事例は、システム開発の失敗を単なるベンダー選定やプロジェクト管理の問題として扱う危うさを示しています。
システムの品質は重要です。
しかし、その前提として、業務側が「何を実現したいか」を明確にし、IT側がそれを「システム要件」に翻訳し、ベンダーが「設計・開発」に専念できる体制をつくれているか。

ここを設計しない限り、システム開発は前に進みません。
基幹システムの刷新や、業務システムの内製化を進めたい中堅企業にとって、本件は「まず何を整備すべきか」を示す実践事例といえます。

■ 個別相談のご案内

基幹システムの刷新を検討しているが失敗が怖い、ベンダーに丸投げせず自社で要件を固めたい、業務要求仕様の作り方を知りたい――そのような課題をお持ちでしたら、ネクサライズコンサルティングまでご相談ください。

業務要求仕様の標準化、IT部門のスキル強化、ベンダーとの役割分担設計まで含めて、実行可能な形に整理し、伴走型でご支援します。

▶ システム開発、業務要求仕様でお悩みの方

▶ まずは課題感を相談したい

辻村裕寛(つじむらやすひろ)代表取締役兼CEO

IT系ベンチャー企業、SIer、コンサルティングファームを経て独立起業。現在は、働きがいと豊かさで次世代が夢を描ける社会を創るをMissionに、企業と働く人々へのコンサルティングを通じて持続的な変革を支援しています。お客様には
①「変化を見抜き価値を創る」コンサルティング、
②「学びで育む次世代の成長」を支える研修、
③「知恵を届け未来を動かす」執筆サービス
を価値としてお届けしております。