要件定義の打ち合わせで、こんな場面に覚えがないでしょうか。現場の担当者から「この機能もあった方がいい」「競合サービスにはこの機能がある」と要望が次々に出て、気づけば初回リリースの予定機能が当初の倍になっている。開発会社に見積もりを依頼すると、想定より期間も費用も大きく膨らんでしまう。かといって、機能を削ると「それでは使えない」と現場から反発が来る。このやり取りを繰り返すうちに、リリース時期そのものが見えなくなってしまうケースは珍しくありません。
こうした状況で大切なのは「全部やる」か「全部やらない」かではなく、最初の一回で何を検証したいのかを先に決めることです。以下、具体的な絞り込みの考え方を整理します。
まず「誰の、どの作業」を対象にするか決める
機能を絞る前に、対象業務を一つに絞ることが出発点になります。たとえば受発注管理システムを想定例として考えると、「発注」「在庫確認」「請求書発行」のすべてを一度に作ろうとすると、要件定義だけで何ヶ月もかかることがあります。まずは一番困っている業務、たとえば発注ミスが多い部署の発注プロセスだけに絞り、そこで使える最小限の仕組みを作る、という進め方が現実的です。
「このリリースで解決したい作業は、具体的に誰のどの作業ですか。一文で言えますか」
この問いに一文で答えられない場合は、まだ対象業務が絞り切れていないサインです。打ち合わせの場で何度でも立ち返る価値のある質問です。
機能を「ないと業務が止まるもの」と「あると便利なもの」に分ける
要望として出てくる機能は、性質がまったく異なる二種類が混ざっていることがほとんどです。一つは「これがないと現場の業務自体が成立しない」機能。もう一つは「あれば作業が楽になる、見た目が良くなる」機能です。前者は初回リリースに必須ですが、後者は運用を始めてから優先順位をつけ直しても遅くありません。
見分け方の一つは、「この機能がない状態で、今の紙やExcelの運用と比べて業務が回るか」を確認することです。今の運用より明らかに悪化するなら必須、同程度か改善するなら後回しでも成立する可能性が高いと判断できます。
開発するか、既存サービスや運用改善で足りるかを先に確認する
機能を絞る以前に、そもそも新規開発が必要かどうかを確認する段階も欠かせません。次のような条件であれば、既存の業務ツールや運用ルールの見直しで十分対応できることがあります。
Aを選ぶ条件（既存サービス・運用改善で足りる場合）として、対象の利用者が少人数で業務パターンがほぼ固定している、月に数回程度の頻度でしか発生しない業務である、市販の表計算ソフトやクラウドサービスの標準機能で代替できる、といった状況が挙げられます。この場合、開発費用をかけるより運用ルールの整備やテンプレート作成の方が早く解決することが多いです。
一方、Bを選ぶ条件（開発を検討する価値がある場合）としては、利用者数が多く手作業のばらつきがミスや手戻りの原因になっている、業務の条件分岐が複雑で既存ツールでは管理しきれない、複数部署間でのデータ連携が頻繁に発生し手入力の転記作業が負担になっている、といった状況です。こうした条件が重なる場合は、最小限の機能からでも専用の仕組みを作る検討が現実的になります。
試作段階で確認する範囲をあらかじめ決めておく
初回リリースの機能を絞ったら、どの指標で評価するかも事前に決めておくと、リリース後の判断がぶれません。たとえば「入力にかかる時間が今までよりどのくらい減ったか」「入力ミスによる手戻りの件数がどう変わったか」「実際にどの程度の頻度で使われているか」といった観点です。数値は目安であり、必ずしも想定通りの改善が出るとは限らない前提で、実際の利用状況を見ながら次の機能追加を判断する姿勢が重要です。
また、現場担当者による確認の工程も省略しないことをおすすめします。自動化された処理であっても、最初のうちは人が最終チェックを行い、想定外の入力や例外ケースが出ていないかを確認する期間を設けると、本格運用後のトラブルを減らせます。
- このリリースで解決したい作業を、誰のどの作業かという形で一文にできているか
- 要望に出た機能を「ないと業務が止まる」「あると便利」の二種類に分けたか
- 既存の表計算ソフトやクラウドサービス、運用ルールの見直しで足りないか再確認したか
- 対象業務の利用者数や発生頻度を具体的な数字で把握しているか
- 初回リリース後に見る指標（作業時間、手戻り件数、利用頻度など）を事前に決めたか
- リリース後しばらくは人が結果を確認する工程を確保しているか
- 削った機能を「いつ、どの条件で再検討するか」をメモに残しているか