要件定義の進め方｜手戻りを防ぐ「捨てる」判断と業務フローの作り直し
システム開発やツール導入で、後から「こんなはずではなかった」となる。
その原因の多くは、開発の途中ではなく、最初の要件定義にあります。
特に多いのが、いまの業務をそのまま新しいシステムに移そうとして、何も良くならないケースです。
この記事では、発注側の立場から、要件定義の進め方と、手戻りを防ぐために決めておくべきことを整理します。
要件定義とは
要件定義は、システムで何を実現するのか、何をしないのかを決める工程です。
どの業務を対象にするか、誰がどう使うか、どんな機能やデータが必要か。
これを発注側とベンダーの間で言葉にし、合意します。
開発が始まってからの変更は、時間も費用も大きくかかります。
要件定義は、プロジェクト全体の中で最も手戻りを減らせる工程です。
要件定義がうまくいかない理由
ベンダーは業務のプロではない
ベンダーは、設計や開発のプロです。
しかし、発注側の実務を理解しているわけではありません。
業務の流れや、なぜその手順になっているのかを伝えなければ、ベンダーは表面的な要望だけをもとに設計することになります。
業務を一気通貫のロジックで説明できるのは、発注側だけです。
「現場合わせ」の判断を先送りする
業務フローを棚卸ししていくと、必ず辻褄の合わない部分が出てきます。
部署ごとにやり方が違う、例外処理が人によって違う、なぜそうしているのか誰も説明できない。
こうした現場合わせの部分で「どうするか」を決めないまま進めると、要件定義そのものが止まります。
執筆者が要件定義に関わる中で、最も大変だったのがこの判断でした。
どこかで「これでいく」と決めなければ、プロジェクトは前に進みません。
いまの業務をすべて移そうとする
変化は面倒です。
だから、いまの業務をそのまま新しいシステムで再現しようとしがちです。
しかし、効率化やコスト削減、生産性の向上を目的にしているのに、いまのやり方をそのまま移しても、見た目が新しくなるだけです。
お化粧だけ新しくしても意味がありません。
あわせて読みたい：中小企業のDX｜ツールを入れて終わりにしない進め方
要件定義で必ず決めておくこと
目的
何のためにシステムを入れるのか。
作業時間を減らしたいのか、情報を共有したいのか、ミスをなくしたいのか。
目的が決まっていれば、迷ったときの判断基準になります。
やらないこと
目的と同じくらい大事なのが、いらないこと、やらなくていいことを捨てることです。
この帳票は本当に必要か、この承認は誰のためにあるのか、この転記はなくせないか。
新しいシステムに移す前に、業務そのものを削ります。
やらないことを決めた分だけ、システムはシンプルになり、使われやすくなります。
目指す業務フロー
いまの業務フローではなく、最適な形にバージョンアップさせた業務フローを定義します。
いまの流れを書き出し、不要な手順を捨て、新しい流れを決める。
システムの要件は、この新しい業務フローから導き出します。
いまの業務を移すのではなく、作り直す
やらないことを決め、業務フローを最適な形にしてから要件にする。
LUPINAは業務の棚卸しからご一緒します。
ご相談は無料です。しつこい営業は行いません。
要件定義の進め方
ステップ1：目的と範囲を決める
何のために、どの業務を対象にするのかを決めます。
範囲を広げすぎると、要件定義が終わりません。
最初は効果の大きい業務に絞ってください。
ステップ2：いまの業務フローを棚卸しする
担当者に聞きながら、実際の業務の流れを書き出します。
マニュアルに書かれている流れではなく、実際に現場で行われている流れを書き出すことが大切です。
ここで、辻褄の合わない現場合わせの部分が見えてきます。
ステップ3：やらないことを決める
棚卸しした業務を一つずつ見て、なくせるもの、まとめられるものを洗い出します。
「昔からやっているから」は、残す理由になりません。
誰のために、何のためにやっているのかを確認し、説明できないものは捨てる候補にします。
ステップ4：目指す業務フローを決める
残した業務で、新しい流れを組み立てます。
現場合わせの部分は、ここで「これでいく」と決めます。
全員が納得する答えを待っていると、いつまでも決まりません。
決める人を決めておくことが、要件定義を進める条件です。
ステップ5：ベンダーに一気通貫で伝える
新しい業務フローを、始まりから終わりまで一つの流れとしてベンダーに説明します。
機能の一覧だけを渡すのではなく、なぜその機能が必要なのか、前後の業務とどうつながるのかまで伝えてください。
業務のロジックが伝わると、ベンダーから設計上のよりよい提案が出てくるようになります。
ステップ6：要件を文書にして合意する
決めた内容を文書にし、発注側とベンダーで合意します。
やらないことも、文書に残してください。
後から「これも入っていると思っていた」という行き違いを防げます。
業務を知らない人の質問が、不要な業務をあぶり出す
要件定義の場で、ベンダーから「そんなことを聞くのか」と思うような質問をされることがあります。
なぜこの書類が必要なのか、なぜこの順番なのか。
業務を知っている側からすると当たり前のことです。
しかし、答えようとして考えてみると、「確かに、それは意味がないな」と気づくことがありました。
業務をなんとなく分かっている人より、まっさらな状態の人のほうが、前提を疑う質問ができます。
素朴な質問を面倒がらずに受け止めることが、やらないことを見つける近道になります。
よくある質問
要件定義は発注側とベンダーのどちらが主導すべきですか
業務の目的とやり方を決めるのは発注側、それをシステムとして実現する方法を考えるのはベンダーです。
業務の中身はベンダーには決められないため、少なくとも業務フローとやらないことの判断は、発注側が主導する必要があります。
現場の意見が割れたときはどうすればよいですか
目的に照らして、どちらがより目的に近づくかで判断します。
それでも決まらない場合に備えて、最終的に決める人を事前に決めておくことが大切です。
要件定義の段階で、すべてを決めきる必要がありますか
すべてを完璧に決めることは現実的ではありません。
ただし、目的、対象範囲、やらないこと、目指す業務フローは、開発に入る前に合意しておくべきです。
細部は、優先順位をつけて段階的に詰めていく進め方もあります。
まとめ
要件定義は、システムに何をさせるかを決める工程であると同時に、業務そのものを見直す工程です。
ベンダーは業務のプロではないため、発注側が業務を一気通貫のロジックで伝える。
現場合わせの部分では「これでいく」と判断する。
そして、いまの業務をすべて移すのではなく、やらないことを捨て、業務フローを最適な形にしてから定義する。
まずは、新しいシステムに移そうとしている業務の中に、「なぜやっているのか説明できないもの」がないかを探してみてください。
それが、最初に捨てるべき業務です。
Contact
まだ届いていない価値を、
共に見つけ、共に創り、共に届ける。
LUPINAは、業務フローの棚卸しから、目指す業務の設計、システムやダッシュボードの構築までを一貫して支援しています。発注側の立場で、要件の整理をご一緒します。
ご相談・お見積りは無料です。サービス内容はこちら
関連記事
Author
鈴木 章悟
株式会社Lupina 取締役 / COO
株式会社デジタルプラス、株式会社リクルートを経て、豊栄建設株式会社・株式会社ロゴスホールディングス（執行役員/CMO）で住宅事業の経営側からマーケティング・営業推進・経営企画を統合した事業運営を推進。Zenken株式会社では生成AI活用による全社横断の業務基盤構築を主導。