ホーム読みもの

要件定義って、結局こちらは何をすればいいのか

発注側が用意するのは仕様書ではありません。今のやり方と、困っていることと、決めていい人。この3つが揃っていれば、要件定義は進みます。

読了 約5分 発注DX業務改善
  • 「要件定義から始めましょう」と言われたが、こちらが何を用意するのか分からない
  • 仕様書を書けと言われても、書けない
  • 打ち合わせに呼ばれるが、質問に答えられずに終わる
  • 決めたはずのことが、あとで「聞いていない」となる

先に書いておくと、発注側が仕様書を書く必要はありません。仕様に落とすのは受注側の仕事です。

発注側が用意するのは3つだけです。今のやり方/困っていること/決めていい人。これが揃っていれば、要件定義は進みます。逆に、どれかが欠けていると止まります。

1. 今のやり方(現状)

いちばん大事です。そして、いちばん軽く見られています。

用意するのは、きれいな業務フロー図ではありません。実物です。

  • 今使っているExcelのファイルそのもの
  • 実際に回っている紙の様式(記入済みのもの。空欄のひな形ではなく)
  • 送っているメールの実物(依頼から完了までの一連)
  • 月に何件あるか、直近3か月の件数

記入済みの実物が効きます。空欄のひな形からは、どこに何が書かれ、どこが使われていないかが分かりません。個人情報が入っているものは、伏せて構いません。

「例外」を先に出してください

要件定義で揉めるのは、ほぼ例外の扱いです。「基本はこうですが、A社だけは違う」「年に数回、こういうケースがある」。これを最初に出してもらえると、見積りも設計も変わります。あとから出ると、作り直しになります。「今は特殊なケースは無い」と言われて進んだ案件で、無かったためしがありません(業務フロー図を書くべきか)。

2. 困っていること(症状)

「システムを入れたい」ではなく、何が起きているかを書いてください。

書き方の違い

伝わらない伝わる
業務を効率化したい月末の3日間、経理2名が残業している
情報共有を良くしたい同じ質問が週に5回、電話で来る
ペーパーレスにしたい申請書の保管場所が無い。過去分を探すのに30分かかる

右のように書けると、「それなら、そこだけ直せば済むかもしれません」という会話ができます。左だと、大きいものを提案するしかありません。

優先順位も付けておく

困りごとを5つ挙げて、「1つしか直せないならどれか」を決めておいてください。

これがあると、予算に収まらなかったときに、削る判断がその場でできます。無いと、持ち帰りになって2週間止まります。

3. 決めていい人

打ち合わせに出る人が、決められる人かどうか。ここで進み方が大きく変わります。

  • 決められる人が出ている → その場で決まる
  • 担当者だけが出ている → 毎回持ち帰りになる

全部の会に役員が出る必要はありません。ただし、「この範囲は担当者が決めてよい」という線引きを先にしてください。

・画面の見た目、項目の並び      → 担当者が決める
・承認の段数、権限の範囲        → 部門長が決める
・費用の追加、スケジュールの変更 → 役員が決める

これを1枚にしておくだけで、打ち合わせの速度が変わります。

使う人を1人、必ず入れる

決める人だけで進めると、現場が使えないものができます。実際に毎日それを使う人を1人、打ち合わせに入れてください。その人が「この順番だと入力しにくい」と言ってくれるかどうかで、定着が変わります(現場が新しいやり方を嫌がる)。

要件定義で決まること・決まらないこと

期待値を合わせておきます。

決まること

  • どの業務を、どこまで対象にするか(範囲
  • 何の情報を、どういう単位で持つか(データ
  • 誰が何をできるか(権限
  • どの画面で何をするか(機能の一覧
  • いつまでに何が出来るか(スケジュール

決まらないこと

  • 細かい画面の見た目(作りながら調整するほうが早い)
  • 運用のルールの細部(動かしてみないと分からない)
  • 将来の拡張(今決めても変わります)

全部を先に決めようとすると、要件定義が長引きます。決めるべきは範囲・データ・権限です。ここがぶれると作り直しになりますが、見た目は後で直せます。

記録の残し方

「言った・言わない」を防ぐのは、議事録ではなく決定事項の一覧です。

日付決めたこと決めた人備考
8/29承認は2段(上長→部門長)田中部長50万円以上は役員承認を追加

議事録は長くて読み返されません。決まったことだけを1行ずつ足していく表を1つ持ってください。打ち合わせの最後の5分で、その場で書きます。

これを受注側と共有しておくと、認識のずれがその場で見つかります。

期間の目安

規模によりますが、中小企業の1業務であれば次くらいです。

規模要件定義の期間打ち合わせ回数
申請1種類の電子化1〜2週間2〜3回
部署の業務1つ(台帳+アプリ)3〜4週間4〜6回
複数部署にまたがる1〜2か月8回以上

2か月を超えているなら、範囲が広すぎます。分割してください。1回目を小さく作って動かすほうが、結果として速く終わります。

準備が負担なら、そう言ってください

上に書いたものを全部そろえる時間が無い、という状況はよくあります。その場合は、現物を見せてもらいながらこちらで整理するやり方もあります。

  • 実際の作業を横で30分見せてもらう
  • 使っているファイルを開いて説明してもらう

準備が整うまで待つと、いつまでも始まりません。準備が負担なら、その旨を最初に言ってください。進め方を変えます。

まとめ用のシートを資料室に置いてあります。埋めて渡す形でも構いませんし、他社に出してもらっても構いません。

まとめ

  • 発注側が仕様書を書く必要はない。用意するのは3つ
  • 今のやり方は、記入済みの実物と件数で。きれいな図は要らない
  • 例外を最初に出す。あとから出ると作り直しになる
  • 困っていることは症状で書く。「効率化したい」ではなく「月末に2名が残業」
  • 1つしか直せないならどれかを決めておく
  • 決めていい人の線引きを1枚にする
  • 使う人を1人、必ず打ち合わせに入れる
  • 決めるのは範囲・データ・権限。見た目は後でいい
  • 議事録ではなく決定事項の一覧を1行ずつ足す
  • 要件定義が2か月を超えるなら範囲が広すぎる
  • 準備が負担なら、そう言う。進め方は変えられる

まずは、今使っているExcelを1つ、記入済みのまま出すところからで構いません。それだけで話はかなり進みます。

この記事で使うシートを配っています

XLSX

開発依頼まとめシート

業務アプリを外に頼むとき、これを埋めて渡すと見積りのブレが小さくなります。人数・元データ・承認の段数・期限・あとで誰が直すかの5項目に、後から揉めやすい定番の要否チェックを足した1枚です。

ダウンロード(無料・登録不要)

Excel(.xlsx) / 10 KB ※社内での利用・改変・配布は自由/転載・再配布・販売は不可

読んだうえで「うちの場合はどうか」を話したい方へ

OKD SOFT は、生成AI(Microsoft 365 Copilot / Copilot Studio)と Power Platform を使った業務改善・内製化支援をしています。作って渡して終わりにせず、担当の方が自分で直せる状態までご一緒します。

「何から手をつければいいか分からない」の段階でも大丈夫です。まずは現状をうかがうところから。