「今度システムを入れるから、要件定義まとめておいて」
上司や取引先からそう言われて、途方に暮れていませんか?
「要件定義って言われても……結局、何を決めればいいの?」というのが一番しんどい悩みですよね。
ネットで検索しても、出てくるのは難解なIT用語や、分厚い仕様書の書き方ばかり。これでは手が動きません。
実は、システム導入やツール作成で炎上する原因は、資料の体裁が悪いことよりも、決めるべき項目の「決め漏れ」が引き金になるケースが多いです。
この記事では、IT専門職ではない小規模事業者や管理部門の方が、外注先や社内エンジニアと揉めずにプロジェクトを進めるための、Excelで埋められる「決めること一覧(12項目)」と、現場で実際に揉めた「決め漏れ5例」をセットで公開します。
私はこれまで複数の現場で「追加費用の発生」「手戻り」「責任の押し付け合い」を見てきました。そこで痛感したのは、「何を決めておけば揉めにくいか」を先に知っているだけで、トラブルの芽はかなり摘める、ということです。
難しい理論は脇に置いて、「埋めれば前に進む」状態を作りましょう。
.webp)
結論:要件定義は「決めること」を先に固定すると揉めにくい
結論から言います。要件定義の成功とは、立派な仕様書を書くことではありません。
「後から揉めそうな火種(未決定事項)を、先に潰しておくこと」です。
過去に私自身、資料を厚く作ったのに、たった一つの「決め漏れ(誰が承認するか)」が原因で現場が止まった経験があります。
逆に、体裁が箇条書きレベルでも、以下の「決めること」さえ合意できていれば、進行は驚くほどスムーズになります。
ここで、私が現場で必ず確認する“止血ポイント”を共有します。
承認者が会議にいない場合、その場で結論は出しません。
やることは一つ、未決事項リストを増やして「次回、誰が決めるか」だけ確定させます。これをやらないと、担当者が“決めたつもり”で走って、後でひっくり返されます。
忙しい人向け:決めること12項目(ここだけ見ればOK)
.webp)
全体像です。
小規模な業務ツールやExcelマクロの開発であれば、以下の12項目を押さえるだけで、揉めごとの確率を大きく下げられます。
これは教科書のまとめではなく、私が現場で「ここが決まってなくて揉めた」経験から逆算して作った“防御リスト”です。
| 重要度 | 項目 | 決めること(ここを埋める) |
|---|---|---|
| 【高】 | 1. 目的・ゴール | 何のために作るか?(工数削減?売上UP?) 成功と言える状態・数値は? |
| 【高】 | 2. 対象範囲(スコープ) | どこまでやるか? 「何をやらないか」 |
| 【高】 | 3. 利用者・業務フロー | 誰が、いつ、どの流れで使うか?(現状→理想) |
| 【高】 | 4. 入力データ定義 | 項目の意味、必須/任意、入力ルール、例外 |
| 【中】 | 5. 出力・帳票 | 誰が何を見たいか?(帳票名・頻度・項目) |
| 【中】 | 6. 機能要件 | 具体的に何ができる必要があるか? |
| 【中】 | 7. 非機能要件 | 速度、権限、バックアップ、セキュリティなど |
| 【中】 | 8. 外部連携・移行 | 他システム連携、過去データ移行の範囲 |
| 【低】 | 9. テスト・受入条件 | どうなれば完成(検収)か? |
| 【低】 | 10. 教育・マニュアル | 誰が教えるか?誰が作るか? |
| 【低】 | 11. 運用・保守体制 | エラー時は誰に連絡し、誰が直すか? |
| 【低】 | 12. スケジュール・費用 | いつまでに?予算上限は?追加対応の扱いは? |
特に「2. 対象範囲(やらないこと)」は重要です。
以前、在庫管理ツールを作った際、「当然、棚卸し機能も付いてるよね?」と納品直前に言われ、真っ青になったことがあります。
「今回は入出庫の記録だけ」と明文化していなかった私の落ち度でした。
各項目の詳しい書き方や、Excelでの管理方法は、後述するテンプレート部分で解説します。
この記事の使い方:30分で形にする手順
.webp)
このリストを見て「全部埋めるの大変そう…」と思った方も大丈夫です。
最初から100点を狙うほど、手戻りが増えます。
要件定義で一番危険なのは、「完璧な資料を作ろうとして抱え込み、時間が経ってから出したら『方向性が違う』と言われて全直し」になることです。
(独立したての頃、これで2週間分の作業を溶かしました)
以下の3ステップで「30分」で形にしてください。
- STEP 1:テンプレを埋める(所要時間:15分)
分かる範囲だけでOKです。分からない箇所は「未定」と書きます。
この「未定」を可視化することが要件定義のスタートです。
- STEP 2:関係者に見せる(所要時間:10分)
合言葉はこれです。
「叩き台です。空欄は質問です。今日決めたいのはAとBだけです」
上司や実際に使う担当者に見せ、意見を引き出します。
- STEP 3:差分を修正して合意(所要時間:5分〜)
出た意見を反映し、「この内容で進めて良いですか?」と合意を取ります。
合意は重たい稟議でなくても、チャットの「OKです」一言でも“証跡”になります。
ポイントは、「未完成の状態で見せる勇気」です。
白紙だと相手は意見が出ませんが、3割でも埋まったExcelがあれば「ここが違う」と指摘できます。
その指摘こそが、あなたが欲しい「真の要件」です。
次の章から、要件定義の本質に入ります。
要件定義とは?初心者向けに一言で言うと
.webp)
専門用語を使わずに結論だけ言います。
要件定義とは、作る前に「誰が・何のために・何を・どこまでやるか」を合意する工程です。
難しい技術文書を書くことではありません。
家を建てる前の家族会議と同じで、「予算」「子供部屋」「キッチンの形」が決まっていなければ、大工さんは釘一本打てません。
この章では、定義不足で揉めた現場の経験を交えつつ、初心者が押さえるべき本質を解説します。
要件定義=「誰が・何のために・何を・どこまで」を合意する工程
初心者が陥りやすい罠は、「どんな画面を作るか(How)」から入ることです。
しかし、成功する担当者は「何のために(Why)」と「どこまで(Scope)」を先に固めます。
ここがブレると「完成したけど使えない」が起きやすいからです。
【失敗談:機能一覧が立派でも揉める】
細かい「機能一覧」があるのに、終盤で大揉めしたプロジェクトがありました。
理由は「誰が使うか(利用者)」の合意が無かったからです。
- 発注者:「若手がスマホで入力する」想定
- 開発側:「経理がPCで管理する」想定
結果、スマホで操作できず、全修正になりました。
画面のリストはあっても、「誰がどう使うか」が抜けていた典型例です。
要件定義では以下の4つを言語化し、関係者全員で握る(合意する)必要があります。
.webp)
| 用語 | 現場での意味(翻訳) |
|---|---|
| 要件(Requirement) | 「〇〇がしたい」「〇〇がないと困る」という要望・必須条件。 |
| 仕様(Spec) | 要件を満たすための「形や数値」。 (例:要件=速く走りたい → 仕様=高性能エンジン) |
| 機能要件 | システムができること。(例:ログイン、検索) |
| 非機能要件 | 品質や制約。(例:3秒以内、権限、バックアップ) |
特に「非機能要件」は見落としやすいポイントです。
クリックして30秒待つシステムは、機能があっても使われません。速度・権限・復旧など「当たり前の品質」も定義対象です。
ありがちな誤解:「要件定義=作る機能を全部書く」ではない
「要件定義書を作ってください」と言うと、Excelに「ログイン画面」「商品登録画面」…と画面名を並べ始める人が多いです。
はっきり言います。それは要件定義ではありません。“画面名リスト”です。
要件定義で決めるべきは量ではなく、揉めるポイント(ルール)です。
ルールが決まっていない資料は、見た目が整っていても地雷になります。
→OK(ルール合意)に変換する考え方.webp)
| NG(ただのリスト) | OK(ルール合意) |
|---|---|
|
【書いたこと】 ・売上入力画面がある ・金額入力欄がある 【結果:揉める】 Aさんは税込、Bさんは税抜で入力。 集計が崩れて“ツールのせい”にされる。 |
【決めたこと】 ・金額は税抜で入力 ・消費税は自動計算 ・1円未満は切り捨て 【結果:安定】 誰が入力しても同じ結果になる。 見た目よりルールを固定した勝ち。 |
検索意図の正体:欲しいのは「テンプレ」より「揉めない状態」
「要件定義 テンプレ Excel」で探している人の多くは、綺麗なドキュメントが欲しいわけではありません。
本当の目的は、人間関係のトラブルと追加費用の発生を避けること。これです。
立派な資料があるのに揉めた現場と、メモに近いExcelでもうまく回った現場、その両方を見てきたので断言できます。
勝敗を分けるのは「書式」ではなく合意の取り方です。
5W1Hで分解(誰が・いつ・何に困ってる?)
.webp)
このキーワードで来る方は、エンジニアではなく「総務・経理・経営者」など管理部門が多いです。
- Who:IT専門職ではない担当者が
- Whom:外部ベンダーや社内の詳しい人に
- What:業務効率化ツールを依頼したいが
- Trouble:伝え方が分からない/専門用語で丸め込まれそう
ここで本当に怖いのは、曖昧なまま進んだ末路である「デジタル・スラム化」です。
要件や設計のメモが残らないまま、詳しい人が退職すると、便利ツールは一瞬で“触るのが怖い爆弾”に変わります。
テンプレを探しているのは、この未来を避けたい直感が働いているからです。
マズローで言うと「安心」と「尊厳」を守りたい
.webp)
綺麗なExcelファイルが欲しいのではなく、守りたいのはこの3つです。
| 守りたいもの | 現場での本音 |
|---|---|
| ①金銭的な安心 | 後から別料金と言われ、追加予算の説明をするのが嫌 |
| ②責任の所在 | 言った・言わないの水掛け論を避けたい(証跡が欲しい) |
| ③社内での立場 | 現場から「使いにくい」と責められたくない |
要件定義書は機能一覧表ではなく、責任の境界線を引くための防波堤です。
クエリタイプ判定:Do(今すぐ埋めたい)が中心
この検索は「今すぐ空欄を埋めて不安を減らしたい」というDo(行動)に寄っています。
注意点があります。
項目が多すぎる重厚テンプレを拾って挫折するのは避けてください。
小規模案件では、埋める作業が目的化して止まります。
- × 立派な仕様書を完成させる
- ◎ 「これだけ決めれば大事故が起きにくい」項目(12個)を埋めて合意する
要件定義で「決めること」一覧(初心者向け・Excel想定)
.webp)
要件定義は分厚い文章ではありません。
必要なのは、揉めやすいポイントを先に決めることだけです。
ここでは、現場で「決まってなくて揉めた」ポイントを厳選し、7つに整理しました。
Excelのセルを埋める感覚で、ここだけ先に固めてください。
①目的・ゴール(何を良くする?数値は?)
目的が曖昧だと、途中で判断基準がブレて迷走します。
経営者と現場担当で“目的が逆向き”なこともあります。
社長は「分析して戦略を立てたい」。
現場は「入力作業を楽にしたい」。
結果、入力項目を削りすぎて、分析に必要なデータが取れず作り直しになった。
形容詞ではなく、状態や数字で合意します。
| 項目 | 悪い例(曖昧) | 良い例(具体) |
|---|---|---|
| 目的 | 業務を効率化する | 月初の集計作業を5日→1日に短縮する |
| 成功条件 | 使いやすくなる | 新人がマニュアル無しで入力完了できる |
テンプレ記入位置:「目的・ゴール」「成功条件」欄
②対象範囲(どこからどこまで・やらないこと)
重要なのは「やること」より「やらないこと(対象外)」です。
ここが曖昧だと、終盤で「ついでにこれも」の増殖が起きます。
▼決めるべき境界線の例
- 対象業務:見積作成のみ(請求書発行は会計ソフトで行うので対象外)
- 対象部署:本社のみ(支店はフローが違うため対象外)
- データ移行:過去1年分のみ(それ以前は移行しない)
テンプレ記入位置:「スコープ(IN/OUT)」欄
③利用者と業務フロー(現状→理想)
誰が、いつ、どんな状況で使うかで、必要な機能もUIも変わります。
- 経理(月1回):速度より、間違い防止の導線が欲しい
- 営業(毎日50回):Tab/Enterだけで爆速入力したい
箇条書きで良いので、現状(As-Is)と導入後(To-Be)を書き出してください。
テンプレ記入位置:「利用者」「業務フロー」欄
④入力データ定義(項目の意味・入力ルール・例外)
Excel運用で最も崩れやすいのがここです。
同じ言葉でも部署で意味が違うことが普通に起きます。
例:「売上日」の解釈違い
- 営業:注文書をもらった日
- 経理:請求書を発行した日
- 倉庫:出荷した日
このズレを放置したままシステム化すると、集計が合わず“ツールのせい”にされます。
ここで作るのが「データ辞書(項目定義)」です。
| 項目名 | 定義・ルール | 入力例 |
|---|---|---|
| 商品単価 | 税抜を入力(消費税は自動計算)。 セット割引は適用前の金額。 |
1000(半角) |
| 顧客ランク | A/B/Cの3段階。新規はC。 | A |
テンプレ記入位置:「入力項目」「定義・入力ルール」欄
⑤出力・帳票・集計(誰が何を見たい?)
入力よりアウトプットから逆算すると失敗しにくいです。
- 帳票名:(例:月次売上レポート)
- 頻度:(例:毎月1日にPDF)
- 必要項目:(例:顧客名、売上、前年差)
テンプレ記入位置:「出力(帳票/集計)」欄
⑥受入条件(ここまで満たせばOK)
「完成の定義」を作ります。これが無いと、終わらない修正ループが始まります。
- 1000件入力しても再計算が3秒以内
- A4で印刷が崩れない
- 既存台帳と1円単位で一致
テンプレ記入位置:「受入条件(検収条件)」欄
⑦運用・保守(誰が直す?問い合わせ窓口は?)
属人化を防ぐための命綱です。
詳しい人が退職した瞬間に、便利ツールは“止まる爆弾”になります。
| 運用管理者 | マスタ追加やユーザー追加(例:総務課長) |
| 保守担当者 | エラー時や修正(例:外部パートナー/社内IT) |
| 緊急時対応 | 手書き代替/バックアップ復旧方針 |
テンプレ記入位置:「運用・保守」「バックアップ」欄
現場で揉めた「決め漏れ」5例(この章が武器)
.webp)
要件定義で怖いのは、難しい機能が作れないことではありません。
決めるべきことが決まらないまま進み、後から人間関係と費用が燃えることです。
ここでは、追加費用・遅延・空気の悪化を招いた“決め漏れ”を5つ紹介します。
逆に言うと、この5つを先に潰すだけで勝率が上がります。
決め漏れ①:目的が二重人格(経営と現場で別ゴール)
結論:目的(成功条件)がズレていると、良いシステムでも「失敗」と判定されます。
決め漏れ②:スコープ境界が曖昧(“それは対象外”戦争)
結論:「やらないこと」を表で握らないと、作業は増殖します。
決め漏れ③:データ定義が無い(同じ言葉で別のものを見ている)
結論:定義が曖昧だと、Excelやシステムは平気で嘘をつきます。
決め漏れ④:例外処理が放置(現場の例外は毎日起きる)
.webp)
結論:現場は例外の連続です。正常ルートだけだと二重管理が残ります。
決め漏れ⑤:責任と権限が曖昧(最後に詳しい人が燃える)
結論:誰が決めるかが決まっていないと、仕様は漂流します。
無料テンプレの“中身”をこの記事内に置きます(コピペOK)
.webp)
世の中のテンプレは項目が多すぎることがあります。
小規模案件で必要なのは、数百ページではなく指差し確認できる1枚の合意書です。
以下は、私が現場で「これだけあれば大事故が起きにくい」と判断して残した最小構成です。
Excelやスプレッドシートにコピペして使ってください。
要件定義テンプレ(最小版:1ページで終わる)
【使い方】
- ExcelのA列に「項目」、B列に「内容」として貼り付けます。
- 空欄にしないでください。未決なら「未定(いつ決めるか)」と書きます。
- 版をつけます(例:v0.1 → v0.2)。チャットのOKでも“合意の証跡”になります。
| 大項目 | 詳細項目 | 記入例・ポイント |
|---|---|---|
| 1. 全体像 | 目的・ゴール | 月次集計を3日→1日に短縮する。 「便利にする」等はNG。 |
| 対象範囲(スコープ) | 請求書発行まで。入金消込は対象外。 やらないことを明記。 |
|
| 2. 業務定義 | 利用者 | 営業(入力)、経理(承認・修正)、社長(閲覧) |
| 業務フロー | 25日入力→月末確認→翌月1日請求書発行 | |
| 例外処理 | 返品はマイナス伝票?キャンセル扱い? ここが揉めやすい。 |
|
| 3. 機能要件 | 入力項目 | 取引先名、金額(税抜)、日付、担当者名 |
| 出力 | 請求書PDF、月次売上推移 | |
| データ量 | 月100件、過去3年保持 | |
| 4. 運用 | 保守担当・受入条件 | エラー時は総務Aさん。 3ヶ月並行してズレ無しで本番。 |
過去に私が失敗した事例です。簡単な在庫管理ツールを作った際、この「例外処理」の欄を設けずに着手しました。
結果、終盤になって「棚卸しのときは?」「返品は?」「入力ミスの取り消しは?」が一気に噴き出し、仕様が後付けで膨れました。
“たまに起きる例外”ほど声が大きく、現場はそこで揉めます。
だからテンプレには、格好良さより揉めどころの受け皿を用意します。
空欄をゼロにすることより、未決を見える化して、誰がいつ決めるかを残すほうが価値があります。


コメント