Webシステム発注初心者ガイド

4

要件定義―「なんとなく欲しい」を言語化する

要件定義って何をするの?

スコープが決まったところで、次は要件定義だ。

要件定義とは、「システムが何をするか」を文書として明確にする作業のこと。開発会社はこの文書をもとに設計・開発を進めるので、曖昧なままだと「思っていたものと違う」という事態になる。

でも、「見積書が作れる画面を作って」で伝わらないのかしら?

それだと開発者が困ってしまうんだよね。「見積書」一つとっても、会社によって全然違うから。

  • 品目行数の上限は?
  • 消費税は外税?内税?税率は複数ある?
  • 単価の小数点は何桁まで?
  • 承認者は誰が設定する?
  • 添付ファイルは付けられる?

これを全部「常識の範囲でうまくやって」と任せると、開発者の「常識」と自社の「常識」がズレて、あとで修正コストが爆発するよ。


画面ごとに分解してみる

要件定義では、まず「どんな画面があるか」をリストアップするところから始めた。

フェーズ1の画面一覧(案)

画面名主な機能
ログイン画面ID・パスワード認証
見積書一覧検索・絞り込み・ステータス確認
見積書作成・編集品目追加・単価計算・保存
承認フロー画面承認・差し戻し・コメント
PDF出力・送付PDF生成・メール添付送信
顧客マスター管理掛率・特別単価の設定
管理者設定ユーザー管理・承認ルール設定
7画面もあるの。これを全部書くのね?

全部書く必要はあるけど、深さは優先度によって変えていいよ。

コア機能(見積書作成・承認フロー)は詳細まで詰める。サブ機能(ログイン・マスター管理)は概要レベルで先に進めて、細かい仕様は後で合意する、という進め方が現実的だね。

最初から全部完璧に書こうとすると、要件定義だけで3ヶ月かかったりするから気をつけて。


見積書作成画面を詳しく書いてみた

コア機能である見積書作成画面について、できる限り詳しく書き出してみた。

見積書作成画面の要件(抜粋)

  • ヘッダー情報:見積番号(自動採番)、作成日、有効期限(デフォルト30日)、担当者名
  • 顧客情報:顧客マスターから検索・選択。選択すると掛率が自動セット
  • 品目行:品番検索→品名・定価が自動入力。数量・単価(掛率適用済み)・金額(自動計算)。最大50行まで
  • 小計・消費税・合計:消費税は外税10%固定(将来的に軽減税率対応を想定)
  • 備考欄:自由入力、最大500文字
  • 保存:「下書き保存」と「申請(承認フローへ送る)」の2段階
「将来的に軽減税率対応を想定」って書いたら、フェーズ1で作ってもらえるの?

「想定」と書いただけでは、フェーズ1の開発範囲には入らないよ。ちゃんと「フェーズ1では外税10%固定とする」と明記して、「将来の拡張を考慮した設計にすること」を別途依頼するのが正しいやり方なんだ。

これを非機能要件設計方針として別セクションに書くのが一般的だね。「今は作らないが、後から追加できるように設計してほしい」という要望は、きちんと言葉にして伝えないと伝わらないから。


承認フローの仕様を図にする

承認フローは言葉で説明するより、フロー図にした方が圧倒的に伝わりやすい。

担当者が見積書作成

  [申請]ボタン押下

金額 < 100万円? ─── Yes ─→ 営業部長へ直送

   No

営業リーダーが確認

  ├── 差し戻し → 担当者に返却

営業部長が承認

金額 ≧ 3,000万円? ─── Yes ─→ 役員決裁へ

   No

  承認完了
こういう図って、Wordで作ればいいの?

WordでもExcelでも、PowerPointでもOKだよ。大事なのは「誰が見てもわかる」ことだから。

無料ツールなら draw.io(diagrams.net)が使いやすいよ。フロー図・ER図・画面遷移図など、システム開発でよく使う図が全部作れるんだ。ブラウザで動いてGoogleドライブとも連携できる。

開発会社との打ち合わせでは「図を見ながら確認する」と認識ズレがぐっと減るから、時間をかけて作る価値があるね。


要件定義書にまとめる

画面の仕様と承認フローを整理したら、要件定義書としてまとめた。

フォーマットは自由だが、最低限以下の内容を含めた。

  1. プロジェクト概要:目的・背景・関係者
  2. 開発スコープ:フェーズ1で作るものとフェーズ2以降
  3. 機能要件:画面一覧・各画面の仕様・承認フロー
  4. 非機能要件:レスポンスタイム、同時接続数、セキュリティ要件
  5. 外部連携:製品マスターDBとのAPI連携仕様(インターフェース定義)
  6. 制約事項:予算上限・納期・使用技術の指定
これが完成したら、いよいよ開発会社に送っていいの?

まずは社内でレビューしてみて!営業部・経理部・上司に見せて「使いたいと思っていたものと合ってるか」を確認しよう。

要件定義書を社内で承認してから開発会社に送るのが鉄則だよ。「社内でまだ合意できていない仕様」を開発会社に渡してしまうと、後で「やっぱり変えたい」が連発して、追加費用の温床になるから。


次回:開発会社の探し方・選び方 →