システムの質は要件定義で決まる|基幹業務システム開発の現場で学んだ本質

システムの質は要件定義で決まる|基幹業務システム開発の現場で学んだ本質B2B-EC
この記事は約4分で読めます。

なぜシステム開発は失敗するのか

「システムを導入したのに、結局使われていない」
「現場では以前のやり方が残り続けている」

こうした状況は、決して珍しいものではありません。

ではなぜ、十分な予算と時間をかけたにも関わらず、システムは失敗するのでしょうか。

原因は明確です。

システム開発の成否は、開発ではなく要件定義の段階でほぼ決まります。

要件が曖昧なまま(しっかり定義されないまま)開発を進めれば、どれだけ優れた技術者が関わっても、完成するのは動作はするが実運用できないシステムが出来上がってしまいます。

要件定義を軽視したまま開発を進めると、数百万円から数千万円規模の投資が「使われないシステム」として無駄になるケースも珍しくありません。

私の原点はIBM AS/400の基幹業務システム開発にあります

私のエンジニアとしてのキャリアは、IBM AS/400による基幹業務システム開発から始まりました。

物流、経理、在庫管理、金融など、企業の根幹を支えるシステムを数多く手がけてきました。
開発経験がある業界は、通信販売の在庫・経理システムから、1円の誤差も許されない大手銀行や消費者金融の勘定系基幹システムまで、流通・商社・小売・金融・決済・医療・医薬・広告・サービスと広範囲に渡ります。

このような環境では、「なんとなくの仕様」は一切通用しません。
すべてを言語化し、定義しきることが求められます。

特に印象に残っているのは、台湾の銀行で消費者ローンの勘定系システムを構築したプロジェクトです。
言語も文化も異なる環境の中で、膨大な例外処理を一つずつ整理し、仕様として定義していきました。

その経験から、確信しています。

100時間の開発よりも、10時間の要件定義の方がシステムの品質を決める

この原則は、今も変わりません。
このような環境では、「なんとなくの仕様」は一切通用しません。
すべてを言語化し、定義しきることが求められます。

近年はAIの進化により、開発そのものの効率は飛躍的に向上しています。
しかし、その分だけ「何を作るか」を決める要件定義の重要性は、むしろ以前よりも高まっています。
間違った要件を高速に実装すれば、失敗もまた高速化するからです。

同じシステムでも成果が変わる理由

同じパッケージ、同じ技術を使っても、成功する企業と失敗する企業があります。

その違いは、機能ではありません。

  • 業務フローが整理されているか
  • 判断基準が言語化されているか
  • 例外処理が定義されているか
  • 現場の運用が理解されているか

これらが曖昧なまま導入すると、必ず問題が発生します。
つまり、システムの性能ではなく「設計の精度」が結果を分けています。

  • 確認作業が減らない
  • 手作業が残る
  • 担当者に依存する

つまり、システムの問題ではなく設計の問題です。

「現場」と「経営」両方の視点が不可欠

システムは、現場だけでも、経営だけでも成立しません。

現場は「使いやすさ」を求めます。
経営は「投資対効果」を求めます。

この両方を満たさなければ、システムは定着しません。

私はゼネコンの人事総務としてシステムを「使う側」も、決済代行会社の常務取締役としてシステムに「投資する側」も経験してきました。
そのため、単に要望をそのまま機能にするのではなく、経営と現場のバランスを俯瞰した最適解を提案することが可能です。

場合によっては
「その業務は見直すべきです」
「この機能は不要です」
といった提案も必要になります。

要件定義とは、単なる機能整理ではなく、業務そのものを設計し直すプロセスです。

重要なのは「データの流れ」を設計すること

システムにおいて本質的に重要なのは、見た目ではありません。

重要なのは、データがどのように流れるかです。

  • どの情報がどこで発生し
  • どのタイミングで処理され
  • どのシステムに連携されるのか

これが曖昧なままでは、どれだけ綺麗な画面を作っても意味がありません。

システムは「業務の構造」をそのまま反映します。

業務が整理されていなければ、システムも整理されません。

結論:要件定義がすべてを決める

システム開発において最も重要なのは、開発ではありません。

要件定義です。

ここで決まったことが、そのままシステムの品質になります。

逆に言えば、要件定義の段階で方向性を誤れば、その後に挽回することは極めて困難です。

システムの質は、要件定義の質に比例する

この原則は、どの時代でも、どの技術でも変わりません。

まずは業務の整理から始めるべきです

「何から手をつければ良いか分からない」
「自社の業務が整理できていない」

その状態こそ、最も重要なスタート地点です。

システムを選ぶ前に、まず業務を整理する。

それだけで、プロジェクトの成功確率は大きく変わります。

システム導入で失敗したくない方へ
多くの企業が「システム選定」から始めてしまいますが、本来やるべきはその前段階です。

構想段階でも問題ありません。
現状の業務整理からご相談いただけます。
▶ 相談する

投稿者プロフィール

OSAMU HORIKAWACEO
株式会社サンクユー 代表取締役CEO。
基幹システムとECをつなぎ、受発注業務の最適化を支援する専門家。

関西大学卒業後、東証プライム上場のゼネコンにて人事総務を経験。
その後システムベンダーへ転職し、IBM AS/400環境における金融・物流・販売管理・経理・人事など、企業の基幹業務を支えるシステム開発に従事する。
プログラマからプロジェクトマネージャーまでを経験し、台湾・台北駐在として銀行システム構築プロジェクトにも参画。

この経験を通じて、「システムの質は要件定義の質に比例する」という思想を確立。
業務理解を起点としたシステム設計を強みとする。

その後、クレジット決済代行会社にて、決済システムの再構築や銀行連携、ECサイト構築を担当。
あわせて組織改革にも携わり、20名から60名規模への組織拡大を実現(退任時:常務取締役)。

2008年に株式会社サンクユーを創業、2010年に法人化。
現在は、基幹システムとECの両領域に精通した知見を活かし、BtoB企業における受発注業務のデジタル化・効率化を支援。
特に、FAX・電話・メールなどアナログ業務のEC化や、基幹システムとの連携を前提とした業務設計を得意とする。

単なるECサイト構築にとどまらず、業務フローの整理・要件定義・システム設計まで一貫して関与し、「現場で使われる仕組み」を実現することを重視している。

NTTレゾナント「goo Search Solution」にてEC関連コラムを執筆。
ECマーケティングレポート | goo Search Solution

■趣味・関心領域
BMW / WRC / ロードバイク / RIZIN / UFC / 大相撲
David Bowie / blur / MUSE / The Rolling Stones / XTC
機動戦士ガンダム(富野由悠季)
ベルセルク / 頭文字D / 進撃の巨人 / ジョジョの奇妙な冒険 / あしたのジョー
Mission: Impossible / Memento / ワイルド・スピード / ソナチネ
LOST / Game of Thrones / FRINGE / The Mentalist
上岡龍太郎 / ダウンタウン

お気軽にご相談ください

お気軽にご相談ください

タイトルとURLをコピーしました