脱Excelの要件定義はどう進める？機能一覧と優先度を整理する方法

先に結論

脱Excelの要件定義でやるのは、欲しい機能を思いつきで並べること ではありません。
現状分析、課題整理、運用ルール設計で見えた内容をもとに、次を整理します。

• どの機能が必要か
• その機能はなぜ必要か
• 優先度は高いか、後回しでよいか
• 誰が決め、誰が確認するか
• いつまでに作るか

つまり要件定義は、脱Excelをプロジェクトとして動かせる形にする工程 です。
ここまで整理できると、ツール選定や開発の話に入っても、判断がぶれにくくなります。

全体の流れを先に確認したい場合は、親記事から戻ると整理しやすいです。

脱Excelの進め方ガイド

前のフェーズである運用ルール設計がまだ曖昧なら、こちらも先に読むとつながりやすいです。

脱Excelの運用ルール設計で決めること｜誰が入力し、誰が確認するか

要件定義はツールの機能表を埋める作業ではない

脱Excelの要件定義でよくある失敗は、いきなりツールの機能一覧を見て、

• この機能は使う
• この機能は不要
• このオプションは高い

と判断してしまうことです。

もちろん、最終的にはツールの機能も見ます。
ただし、その前に 自社の業務として何が必要か を言葉にしておかないと、ツール側の都合に引っ張られます。

たとえば、kintoneに承認機能があるから承認フローを作る、Power Appsで画面を作れるから入力画面を増やす、という順番では危険です。
先に決めたいのは、どの業務で、誰が、何を判断する必要があるのか です。

まず集める材料

要件定義の材料は、ゼロから考えるものではありません。
すでにあるExcelと、関係者の話の中にかなりのヒントがあります。

1. 既存Excelから拾うもの

既存Excelを見るときは、列名だけでなく、実際に業務で使われている意味まで見ます。

• 入力項目
• 必須になっている項目
• 数式やマクロ
• 別シートや別ファイルへの参照
• フィルターや並び替えでよく見る切り口
• 会議前に追加で作っている集計表
• 使われていない列

ここで大事なのは、Excelをそのまま再現することではありません。
Excelの列を、業務として必要な情報に言い換える ことです。

たとえば「メモ1」「メモ2」「備考」のような列が複数あるなら、本当に自由メモが必要なのか、次回対応日や対応履歴として分けるべきなのかを見ます。

2. ステークホルダーから拾うもの

脱Excelでは、現場だけでなく、関係者ごとに見たいものが違います。

• 現場担当者は入力のしやすさを見ている
• 管理者は進捗や未対応の把握を見ている
• 経理は請求や入金に影響する項目を見ている
• 情シスは権限、連携、保守性を見ている
• 経営層は月次の数字やリスクを見ている

この違いを聞かずに機能を決めると、あとで「その一覧も欲しい」「その権限では困る」が増えます。
ブレストでは、誰が何を見るための機能なのか を必ずセットで聞きます。

機能一覧の作り方

材料が集まったら、機能一覧を作ります。
最初から完璧な要件定義書にしなくても構いません。
まずは、次の形で1枚にまとめると話が進めやすいです。

機能	目的	優先度	担当者	確認者	期限
案件情報を登録する	正本を1か所に集める	高	営業企画	営業責任者	5月末
ステータス別に一覧を見る	会議前の別集計をなくす	高	情シス	営業企画	5月末
承認済み案件だけ請求予定に回す	請求漏れを減らす	高	管理部	経理	6月中旬
担当者別の月次レポートを見る	会議資料作成を減らす	中	経営企画	管理部	6月末
過去履歴を検索する	引き継ぎを楽にする	中	営業企画	サポート	7月上旬

機能名は、できるだけ業務の言葉で書きます。
「一覧画面」「詳細画面」だけではなく、何を見る一覧か まで入れると分かりやすいです。

たとえば、

• 案件一覧
• 未対応問い合わせ一覧
• 承認待ち一覧
• 請求予定一覧
• 担当者別月次レポート

のように書くと、関係者と話しやすくなります。

機能一覧は、開発者だけでなく業務側が読んで分かる言葉で書く のが大事です。

優先度の付け方

脱Excelでは、出てきた機能を全部作りたくなります。
でも最初から全部入れると、時間も費用も膨らみ、現場の確認も追いつきません。

まずは、次の3段階で十分です。

優先度	意味	例
高	初回リリースにないと業務が回らない	登録、更新、検索、権限、承認
中	早めに必要だが、初回後でもよい	月次レポート、通知、CSV出力
低	あると便利だが、なくても始められる	見た目の細かな調整、追加グラフ

迷う場合は、業務影響度 と 実装の重さ で見ます。

判断軸	見ること
業務影響度	その機能がないと事故、手戻り、二重入力が残るか
利用頻度	毎日使うか、月1回だけ使うか
関係者数	何人、何部署に影響するか
実装難易度	権限、承認、連携、データ移行が重いか
代替手段	初回だけ手作業で逃がしても問題ないか

初回リリースでは、便利機能より事故を減らす機能を優先する と考えると決めやすいです。

担当者と期限を決める

機能一覧に優先度を付けたら、担当者と期限を決めます。
ここを曖昧にすると、要件定義は進んでいるように見えて、実際には誰も決めていない状態になります。

最低限、次の3つの役割を分けると進めやすいです。

役割	決めること
業務担当者	その機能で実現したい業務の中身を決める
実装担当者	ツールやシステムでどう作るかを考える
確認者	できたものが業務に合っているかを確認する

たとえば、案件登録の機能なら、業務担当者は営業企画、実装担当者は情シスや外部パートナー、確認者は営業責任者という形です。

期限は「全体リリース日」だけでなく、機能ごとに置きます。

• 要件を決める期限
• 試作品を確認する期限
• データ移行を確認する期限
• 現場へ案内する期限

機能ごとに誰がいつ決めるかを置く と、脱Excelが会議の話題から実行計画に変わります。

プロジェクトの進め方

要件定義から移行までは、次のように小さく区切ると進めやすいです。

ステップ	やること	成果物
1. キックオフ	目的と対象範囲を決める	目的、対象業務、関係者
2. 既存Excel棚卸し	項目、数式、参照、利用場面を見る	Excel棚卸し表
3. ブレスト	関係者の困りごとと要望を集める	困りごと一覧
4. 機能一覧化	必要な機能へ分解する	機能一覧
5. 優先度付け	初回範囲と後回しを分ける	MVP範囲
6. 試作品確認	小さく作って現場に見せる	プロトタイプ
7. データ移行とテスト	既存データを入れて確認する	移行チェック表
8. 運用開始	使い方を案内して切り替える	運用ルール

MVPという言葉を使うなら、ここでは 最初に業務が回る最小範囲 と考えれば十分です。
全部入りの完成形ではなく、まず事故や二重入力を減らせる範囲から始めます。

脱Excelは一気に全部移すより、小さく始めて広げる方が定着しやすい です。

要件定義でよくある失敗

1. 既存Excelをそのまま再現する

列、シート、色、計算式をそのまま移すと、Excelの複雑さも一緒に移ります。
特に、使われていない列や、会議資料のためだけに増えた列まで持ち込むと、新しい仕組みが重くなります。

2. 全部を優先度「高」にする

関係者に聞くと、どの機能も大事に見えます。
でも、全部を高にすると優先度を付けた意味がありません。

初回になくても運用で逃がせるものは、中や低に下げます。
優先度は要望の強さではなく、初回運用に必要かで決める とぶれにくいです。

3. 確認者を決めない

実装担当者だけが決まっていて、業務側の確認者がいないケースです。
この状態だと、作った後に「思っていたものと違う」が起きます。

4. 期限がリリース日しかない

最終期限だけ決めても、途中で止まっていることに気づきにくいです。
要件確定、試作品確認、データ移行確認など、途中の期限を置きます。

具体例で見る要件定義

以下は、イメージしやすくするための架空の例 です。

失敗例: 青海産業株式会社（従業員52名 / 建材卸）
営業部の案件管理を脱Excelするため、最初の会議で「今の案件表を全部アプリにする」と決めました。
既存Excelには、案件名、顧客名、見込み金額、確度、備考、会議用メモ、上長メモ、経理確認欄など、長年増えた列が60以上ありました。
そのまま機能一覧にしたため、初回から入力画面が重くなり、現場は「どこを入れればよいか分からない」と感じました。
優先度もほぼ全部が高になり、担当者と確認者も曖昧なまま進んだため、試作品の確認で大量の手戻りが出ました。
失敗の理由は、既存Excelを業務要件に言い換えず、そのまま再現しようとしたこと でした。

成功例: 浜町メンテナンス株式会社（従業員43名 / 設備保守）
この会社では、保守案件、訪問予定、請求準備がExcelで分かれていました。
要件定義では、まず既存Excelの列を棚卸しし、営業、事務、経理でブレストしました。
そこで見えたのは、初回で本当に必要なのは「保守案件の登録」「訪問完了ステータス」「請求予定への引き渡し」「未完了案件の一覧」だけだということでした。
月次グラフや細かなレポートは後回しにし、機能ごとに担当者と確認者と期限を置きました。
その結果、初回リリースでは請求漏れにつながる部分だけを確実に移し、現場の入力負担も増やさずに始められました。
うまくいった理由は、機能一覧、優先度、担当者、期限をセットで決めたこと でした。

ツール選定へ進む前に確認すること

要件定義が一段落したら、次にツール選定へ進みます。
ただし、次の質問に答えられないなら、まだ要件定義に戻った方がよさそうです。

• 初回で必要な機能はどれか
• 後回しにする機能はどれか
• どの機能が事故や手戻りを減らすのか
• 誰が業務上の正解を判断するのか
• いつまでに何を確認するのか

ここまで言えると、kintone、Power Apps、AppSheet、Airtable、専用システムなどを比べるときも、判断軸がはっきりします。

ツール選定の考え方は、次の記事で整理しています。

脱Excelの移行ツールはどう選ぶ？kintone・Power Apps・AppSheetの考え方

kintoneを具体的に候補にしている場合は、こちらも参考になります。

kintoneに移行する前に整理すべきこと

まとめ

脱Excelの要件定義で大事なのは、機能をたくさん出すことではありません。
必要な機能を、優先度、担当者、期限つきで整理すること が中心です。

押さえておきたいのは、次の5点です。

• 既存Excelから、項目、数式、参照、利用場面を拾う
• ステークホルダーから、困りごとと見たい情報を聞く
• 機能一覧は、業務側が読んで分かる言葉で書く
• 初回で必要な機能と、後回しでよい機能を分ける
• 機能ごとに担当者、確認者、期限を決める