システムのリリース直後、現場から「使いにくい」という声が上がることがある。仕様通りにできているのに、当初の想定より利用率が伸びない。やがて「結局、前のシステムの方が良かった」という評価が出る。開発側には珍しくない話だが、この現象には再現性がある。同じ性質の問題が異なる企業で繰り返されるのには、構造的な理由がある。「業務とシステムのずれ」は要件定義で生じる仕様通りにできたシステムが使われない最大の原因は、「要件定義の時点で『業務』ではなく『機能』を議論した」ことにある。「この画面にこのボタンが欲しい」「このデータをCSVでダウンロードできるようにして欲しい」——こういった機能要件は具体的で議論しやすい。だがそれらの機能が「どの業務プロセスのために必要か」が共有されていないと、システムができた後に「ここが違う」が発生する。つまり、システムは当初の設計通りに動いているが、業務の実態とは同期していない。「今のシステムと同じ機能」という要件の落とし穴特に旧システムからの移行案件で起きやすいのが、「今のシステムでできることをすべて新システムでもできるように」という要件だ。これは表面上合理的に見える。だが現行システムの機能の中には、「業務上本当に必要な機能」と「誰かがある時期に追加した機能」と「長年の運用で形骸化された機能」が混在している。「今と同じ」を要求することは、その混在をすべて新システムに引き継ぐことになる。いわばブルドーザーのパターンで、不要な複雑性をそのまま移植することになる。要件定義が「業務」でなく「機能」になる理由要件定義を機能要件の議論にしてしまうのは、発注側が自分たちの業務をシステムの言葉で語れないからだ。「業務プロセス」で話すには、自分たちの業務の全体像とシステムの対応関係が頭に入っている必要がある。それがない状態で議論の席に座ると、話したことがある画面や機能の言葉に落ちる。そしてできあがったシステムは、機能一覧としては要件通りだが、業務の実態に合っていないシステムになる。現行調査は「業務言語」を得るためのプロセスでもある現行調査を通じてたどり着く情報の一つが、「業務プロセスとシステム機能の対応関係」だ。これが整理されているかどうかで、次の要件定義の質が大きく変わる。かつて「仕様通りにできたのに使われない」と言われた企業の多くは、この対応関係の整理が要件定義の前になかったことを起点にしている。あわせて読みたい：なぜ基幹システムの刷新は予算オーバー・遅延・頓挫するのか——「仕様通りにできた」のに使われない問題の背景にある、刷新失敗の構造を解説基幹システム刷新の進め方｜現行調査・要件定義の正しい順序——現行調査から要件定義まで、順序を間違えないための3ステップSIerに相談する前に自社で整理すべき3つのこと——要件定義を機能要件の議論にしないために、相談前にやっておくこと要件定義の前に自社の業務とシステムの対応関係を整理したい場合は、現行調査サービスからご相談ください。