業務システム開発の​要件定義で​最初に​決めること｜全部を​一度に​固めようとしない​進め方

「要件定義」と​いう​言葉を​聞くと、​最初に​すべての​仕様を​細かく​決めきらないと​いけないと​考えがちです。​ところが、​細部まで​固めようとする​ほど​打ち合わせが​長引き、​決まらないまま​時間だけが​過ぎることがあります。​この​記事では、​業務システムの​開発を​依頼する​前に、​要件定義で​本当に​決めて​おくべきことを​整理します。

要件定義でつまずきやすい​原因

要件定義が​長引く​現場には、​共通した​傾向が​あります。

• 使う​人全員の​希望を、​最初から​すべて​盛り込もうとする
• 「あったら​便利」と​「今回必要」の​区別が​ついていない
• 決める​順番が​決まっておらず、​話が​行ったり​来たりする

これらは​担当者の​能力の​問題ではなく、​決め方の​順番が​整理されていないことが​原因です。

最初に​決めるべき​4つのこと

細部より​先に、​次の​4つを​言葉に​しておくと​打ち合わせが​進みやすくなります。

1. 誰が、どの場面で使うか（社内担当者だけか、​取引先も​操作するか）
2. 今、何に一番時間がかかっているか（入力、​確認、​集計、​共有の​どこか）
3. 他のシステムとつなぐ必要があるか（会計ソフト、​予約システムなど）
4. 最初のリリースで外してよい機能はどれか（あとから​追加できる​部分）

特に​4番目を​先に​決めて​おくと、​初回の​開発範囲が​現実的な​大きさに​収まります。

決める​順番の​目安

右側の​項目は、​実際に​動くものを​見ながら​決めた​ほうが​早く、​かつ的確に​決まることが​多い​部分です。

全部を​一度に​固めようとしない

要件を​一度に​すべて​固めようと​すると、​決まらない​項目が​全体の​進行を​止めてしまいます。​まず​必要な​範囲を​決め、​動くものを​確認しながら、​必要な​機能を​後から​広げていく​ほうが、​認識の​ズレに​早く​気づけます。​株式会社スリーラボでは、​要件定義の​段階から​試作を​交えて​進めることが​多く、​言葉だけで​仕様を​詰め切る​前に、​触って​確認できる​形を​用意します。

依頼前に​用意しておくと​早いもの

• 今​使っている​ツール・ファイルの​一覧
• 入力・確認・承認を​している​人の​一覧
• 「これだけは​外せない」と​思う​機能の​メモ
• 連携したい​既存システムが​あれば、​その​名称

すべてが​揃っていなくても​相談は​始められます。​整理​そのものを​一緒に​進めることも​可能です。

まとめ

要件定義でつまずく​原因の​多くは、​細部まで​一度に​決めようとすることに​あります。​まず​「誰のためか」​「今どこに​時間が​かかっているか」​「最初の​範囲」を​決め、​残りは​動くものを​見ながら​詰めていく​進め方が​現実的です。​株式会社スリーラボでは、​この​整理を​着手前の​ご相談から​一緒に​行っています。​ご相談はお問い合わせ、​サービス内容はできることのページから​確認いただけます。