システム開発の「要件定義」で何を決めておくべきか｜発注前に準備すること

「要件定義はベンダーに主導してもらえばいい」と思っていた時期が、自分にもあった。専門家に任せれば、こちらが気づいていない課題まで引き出してくれる、と。だが実際は違う。要件定義の主役は発注側だ。ベンダーはあなたの業務を知らない。どれだけ優秀なエンジニアでも、現場を毎日生きているあなたの代わりにはなれない。

業務フローを「言語化」しておく

要件定義の前に、まず自社の業務フローを整理する必要がある。「注文が入ったら何が起き、誰が何をして、次にどこへ渡るか」。これを文章か図にできない状態でシステム開発に入ると、ほぼ確実に手戻りが発生する。

重要なのは「例外処理」まで書くことだ。業務の8割は標準フローで動くが、残り2割の例外が現場の頭を悩ませている。その例外こそ、システムに組み込むべきか、割り切って手運用にするかを判断しなければならない。ここを曖昧にしたままベンダーに伝えると、後から「そのケースは想定外です」という会話が必ず生まれる。

「誰が使うのか」を具体的に想定する

ユーザーの解像度が低いままシステムを作ると、誰も使わないものができあがる。「社員が使います」では足りない。何年目の、どんな業務を担当している、どの程度ITに慣れた人間が、1日に何回、どういう状況で操作するのか。

営業が外出先でスマホから入力するのか、経理が事務所のPCで月次処理をするのか。この違いだけでUI設計は大きく変わる。現場担当者を要件定義の場に1人でも連れてこられるなら、ぜひそうしてほしい。決裁者だけで仕様を固めた結果、実際の使い手が「使いにくい」と感じるシステムを量産してきた歴史は長い。

「何が変わったら成功か」を先に決める

これが最も見落とされる問いだと思っている。システムを入れること自体が目的になってしまい、導入後に「なんとなく便利になった気がする」で終わるプロジェクトを何度も見てきた。

成功の定義は数値で持てるなら数値がいい。「月次集計の工数が今の半分以下になる」「ヒューマンエラーによる返品が月5件以下になる」。これがあると、要件定義の途中で「この機能は必要か」という判断軸が生まれる。ゴールから逆算できるからだ。逆にこれがないと、機能追加の歯止めが利かなくなり、スコープが膨らんでコストが跳ね上がる。

「現場観察」から始める、という発想

要件定義の最初のアクションとして、現場で実際に作業している人を1時間観察することを勧めたい。会議室でヒアリングするより、現場で「あ、そういう動きをするんだ」と気づくことの方が多い。人は自分の業務を完全には言語化できない。身体で覚えた手順や、なんとなくやっている確認作業が、システム化した途端に「そこが抜けた」と問題になることがある。

発注側が「仕様はベンダーに任せる」と言った瞬間、プロジェクトは受け身になる。ベンダーはRFP（要件定義書）に書かれていないことには責任を持てない。書かれていないことが問題になったとき、「それは要件に入っていませんでした」という返答は、技術的には正しい。だが業務は止まる。

準備に時間をかけることは、開発工数を減らすことに直結する。要件定義に1ヶ月かけて開発が3ヶ月になるより、要件定義が2週間で開発が6ヶ月になる方が、最終的なコストも品質も悪い。手を動かす前に頭を使う時間を惜しまないことが、システム開発成功の第一条件だと思っている。