機能一覧表の作り方：見積もり精度を上げる粒度と優先度の付け方

機能一覧表は、作りたいシステムの「できること」を一行ずつ並べた表です。発注前にこれを作っておくと、開発会社ごとの見積もりが同じ前提で比較でき、予算に合わせて範囲を削るときにも「どこを削ればいくら下がるか」を具体的に話し合えるようになります。ポイントは二つだけです。機能の粒度をそろえること、そして各機能に「必須・あればよい・将来」の優先度を付けることです。

逆に、粒度がばらばらで優先度のない一覧表を渡すと、開発会社は不明点を自社の想定で埋めて見積もるため、金額の差が「仕様の解釈の差」なのか「会社の実力や単価の差」なのか見分けられなくなります。結果として、安い見積もりを選んだのに追加費用が積み上がる、という典型的な失敗につながります。

この記事は、システム開発を初めて発注する事業責任者や、新規事業の担当者に向けて書いています。機能一覧表に入れるべき列、粒度をそろえるための目安、優先度の付け方、開発会社とのすり合わせ方、よくある失敗までを、手を動かせる順番で説明します。

機能一覧表とは何か：要件定義書との関係

機能一覧表は、要件定義の中核になる成果物の一つです。要件定義書が「なぜ作るのか」「誰が使うのか」「どんな制約があるのか」まで含む文書であるのに対し、機能一覧表は「何ができるようになるのか」を網羅的に並べることに特化しています。要件定義書全体の書き方は要件定義書の書き方で詳しく扱っているので、ここでは一覧表そのものに絞ります。

発注者が機能一覧表を作る意味は、主に次の三つです。

• 見積もりの前提をそろえる：同じ一覧表を複数社に渡せば、各社は同じ範囲を前提に工数を積み上げるため、金額の違いを比較しやすくなります。
• 範囲調整の単位を作る：予算や期間が合わないとき、一覧表の行単位で「これは次の段階に回す」と判断できます。
• 抜け漏れに気づく：一覧にしてみると、登録はあるのに削除や修正がない、通知の仕組みがない、といった欠落が見つかります。

なお、一覧表は完璧である必要はありません。発注者が作る段階では「業務や利用者の言葉で書かれた、たたき台」で十分です。技術的な分解は開発会社の仕事であり、発注者は「何を実現したいか」をはっきりさせることに集中すれば足ります。

機能一覧表に入れる列：最低限そろえたい項目

列を増やしすぎると作る側も読む側も疲れます。最初は次の列で始め、必要に応じて足すのがおすすめです。

特に大事なのは「利用者」と「補足・未確定事項」の列です。同じ「予約を変更する」でも、会員が自分で変えるのか、スタッフが電話を受けて代わりに変えるのかで、必要な画面も権限の設計も変わります。また、未確定事項を書いておくと、開発会社はそこに前提を置いて見積もるか、質問を返してくれます。空欄のまま渡すと、その部分が見積もりのブレの原因になります。

列を足すとしたら、「対応する画面」「関連する外部サービス」「想定件数（データ量や同時利用者の目安）」が候補です。外部サービスとの連携や大量データの処理は費用に効きやすいため、該当する機能だけでも書いておくと見積もりの精度が上がります。

機能の粒度をそろえる：見積もりがブレる最大の原因

機能一覧表でもっとも差が出るのが粒度です。たとえば次の三行が同じ表に並んでいると、見積もる側は困ります。

• 会員管理
• パスワードを再設定する
• 管理画面

「会員管理」は登録・ログイン・プロフィール編集・退会など十以上の機能を含みうる大きな塊です。一方「パスワードを再設定する」は単一の操作です。「管理画面」に至っては、何を管理するのかすら分かりません。こうした大きな塊は、会社によって中身の想定が大きく違うため、見積もり額が数倍開くこともあります。

粒度の目安は「利用者が一回の目的で行う操作」

粒度をそろえる目安としておすすめなのは、「ある利用者が、一つの目的のために行う一連の操作」を一行にすることです。たとえば次のような単位です。

• 会員がメールアドレスで新規登録する
• 会員が登録情報を変更する
• 会員が退会する
• 管理者が会員を検索して一覧で見る
• 管理者が会員情報をCSVで出力する

この単位にすると、各行が「誰が・何をするか」という形になり、画面や処理に落とし込みやすくなります。逆に「ボタンを押すと確認ダイアログが出る」のような画面の細部まで書く必要はありません。そこまで細かいと一覧表が膨大になり、本当に大事な判断（何を作るか、作らないか）が埋もれます。

大きすぎる行を分解する手順

すでに大きな塊で書いてしまった行は、次の順で分解します。

1. その塊を使う利用者の種別を書き出す（会員、スタッフ、管理者など）。
2. 利用者ごとに、そのデータに対して行う操作を「作る・見る・変える・消す」で考える。
3. 「探す・並べ替える・出力する・取り込む」など、一覧に対する操作があるかを確認する。
4. 「通知する・承認する・記録を残す」など、操作に付随する動きがあるかを確認する。
5. 分解した結果、明らかに不要なものは消し、迷うものは優先度「あればよい」で残す。

この手順で「管理画面」を分解すると、「管理者が会員を一覧で見る」「管理者が予約を手動で登録する」「管理者が操作履歴を見る」のように、中身が見える行に変わります。管理画面は「何を管理するか」を書き出すと、思った以上に行が増えることが多い部分です。

見落としやすい「裏方の機能」

利用者の目に見える機能は書けても、裏方の機能は漏れがちです。次のものは一覧表に入っているかを確認してください。

• メールや通知の送信（登録完了、予約確定、リマインドなど）
• 権限ごとの表示の出し分け
• データの一括取り込み・一括出力
• 定期的に動く処理（毎日の集計、期限切れデータの整理など）
• 操作ログや変更履歴の記録
• 外部サービスとの連携（決済、カレンダー、会計ソフトなど）

これらは画面がない、または小さいため軽く見られがちですが、実際には工数がかかることが少なくありません。

優先度の付け方：必須・あればよい・将来の三段階

優先度は細かく分けすぎると判断がぶれるので、三段階で十分です。

優先度付けの考え方としては、MoSCoW分析がよく知られています。Must・Should・Could・Won'tの四段階に分ける方法ですが、発注者が最初に付ける段階では三段階に縮めた方が迷いにくい、というのが実務での感覚です。

「必須」が多すぎるときの絞り方

初めて一覧表を作ると、ほとんどの行が「必須」になりがちです。そのときは、次の問いで一つずつ見直します。

1. 最初の利用者は誰か。その人が最初の1週間で使う機能はどれか。
2. 手作業で代わりにできないか。たとえば請求書発行は、最初の数か月は既存の会計ソフトで手作業でも回らないか。
3. 他のサービスで代替できないか。問い合わせ機能は、フォームサービスとメールで足りないか。
4. 利用者が少ないうちは不要ではないか。高度な検索や絞り込みは、データが少ないうちは必要ないことが多い。

新規事業の初期であれば、とくに「将来」に回す勇気が大切です。最初の版で検証したいことに直結しない機能は、作っても使われないまま保守の負担だけが残ることがあります。最初の版で何を作るかの考え方はMVPの機能の優先順位付けで詳しく説明しています。

機能一覧表を作る手順：白紙から完成まで

ここからは、実際に作る流れを順番に示します。表計算ソフトがあれば十分です。

1. 利用者の種別を書き出す：会員、ゲスト、スタッフ、管理者など。権限が違う人は別の種別として扱います。
2. 利用者ごとに「やりたいこと」を書き出す：業務の流れや利用の場面を思い浮かべ、動詞で書きます。この段階では粒度を気にせず量を出します。
3. 大分類でまとめる：会員、予約、決済、お知らせ、集計など、5〜10程度のまとまりに分けます。
4. 粒度をそろえる：大きすぎる行は前述の手順で分解し、細かすぎる行はまとめます。
5. 裏方の機能を足す：通知、出力、定期処理、ログ、外部連携の漏れを確認します。
6. 優先度を付ける：三段階で付け、「必須」が多すぎれば絞ります。
7. 未確定事項を書く：決まっていないこと、相談したいことを補足列に書きます。
8. 画面との対応を確認する：主要な画面を簡単に描き、どの機能がどの画面に乗るかを照らし合わせます。画面の描き方は画面遷移図の作り方で解説しています。
9. 第三者に読んでもらう：実際の利用者や業務担当者に見せ、抜けや誤解がないかを確認します。

この手順で、機能数が数十行程度の一覧表になることが多いはずです。行数が多いこと自体は問題ではありません。大事なのは、各行の粒度がそろっていて、優先度が付いていることです。

具体例：架空の習い事教室の予約システム

ここでは、架空の例として「複数の教室を運営する習い事スクールが、電話受付の予約をWebに移したい」という場面で考えます。

最初に担当者が書いた一覧は「会員登録」「予約」「管理画面」「決済」「お知らせ」の五行でした。これを手順に沿って分解すると、次のようになりました（一部抜粋）。

分解の過程で、「スタッフが電話予約を代理登録する」機能が抜けていたことに気づきました。電話受付をすぐにゼロにはできないため、これがないと現場が回りません。逆に、決済と集計は既存の方法で当面しのげると判断し、「将来」に回しました。この時点で、見積もりを依頼すべき範囲が明確になり、開発会社からの質問も「振替予約のルール」「枠の一括登録の方法」といった具体的なものに変わりました。

もう一つの気づきは、「教室ごとの枠を登録する」が想像より重い機能だったことです。毎月、講師の出勤予定に合わせて数十の枠を作る必要があり、一件ずつ手入力する画面では運用が回りません。そこで補足列に「前月の枠を複製して一括作成したい」と追記しました。こうした運用上の要望は、現場のスタッフに一覧表を見せて初めて出てくることが多く、手順9の「第三者に読んでもらう」を省かない理由はここにあります。

開発会社とのすり合わせ方：一覧表を見積もりにつなげる

一覧表ができたら、開発会社に見積もりを依頼します。依頼時に準備する資料全体は見積もり依頼前の準備にまとめていますが、一覧表まわりで意識したいのは次の点です。

• 行単位で見積もりを出してもらう：合計額だけでなく、大分類や行ごとの工数を出してもらうと、範囲調整のときに効果を計算できます。
• 優先度別の合計を出してもらう：「必須だけならいくら」「あればよいまで含めるといくら」が分かれば、予算との調整が一気に楽になります。
• 前提条件を書いてもらう：開発会社が未確定事項にどんな前提を置いたかを明記してもらいます。前提が違えば、後で追加費用になる可能性があります。
• 質問を歓迎する：良い開発会社ほど、一覧表を読んで質問を返してきます。質問の質は、その会社が業務を理解しようとしているかの目安になります。

見積もりの段階では、多くの場合まず概算見積もりが出て、要件が固まった後に詳細見積もりに移ります。二つの違いは概算見積もり・詳細見積もりで解説しています。一覧表の粒度がそろっていれば、概算と詳細の差も小さくなりやすくなります。

よくある失敗と渡す前のチェックリスト

機能一覧表づくりでよく見かける失敗と、避け方をまとめます。

• 画面名を機能名にしてしまう：「トップページ」「マイページ」は画面であって機能ではありません。画面に何が載るかを、利用者の操作として書き直します。
• 既存システムの機能をすべて書き写す：今のシステムやExcelにある機能を全部移すと、使われていない機能まで作ることになります。実際に使っているかを業務担当者に確認してから載せます。
• 「〇〇と同じように」で済ませる：他社サービスを参考にするのはよいことですが、「〇〇のような予約機能」とだけ書くと、どこまで同じにするのかが伝わりません。参考にしたい点を具体的に書きます。
• 例外の扱いを書かない：キャンセル、変更、二重登録、退会後のデータの扱いなど、例外の処理は工数がかかりやすい部分です。少なくとも補足列に「ルールは要相談」と書いておきます。
• 作ったきり更新しない：一覧表は開発中も変わります。追加・削除・優先度変更の履歴を残し、開発会社と常に同じ版を見るようにします。変更が費用や期間にどう影響するかも、その都度確認します。

渡す前のチェックリスト

開発会社に渡す前に、次の項目を確認してください。

• 利用者の種別がすべて書き出され、各行に利用者が書かれている
• 各行が「誰が・何をする」の形になっていて、粒度がおおむねそろっている
• 「管理画面」「会員管理」のような中身の見えない大きな行が残っていない
• 通知、出力、定期処理、ログ、外部連携の要否が確認されている
• すべての行に「必須・あればよい・将来」の優先度が付いている
• 「必須」の行が、最初の利用開始に本当に必要なものに絞られている
• 未確定事項や相談したいことが補足列に書かれている
• 主要な画面との対応を一度は照らし合わせている
• 業務担当者や想定利用者に一度は読んでもらっている
• 版番号と更新日が書かれ、変更履歴を残す運用になっている

よくある質問

Q. 機能一覧表は発注者が作るべきですか、開発会社に作ってもらうべきですか？

たたき台は発注者が作るのがおすすめです。何を実現したいかは発注者にしか分からないためです。そのうえで、開発会社に技術的な観点から分解・補足してもらい、最終版を一緒に仕上げる形がもっとも手戻りが少なくなります。要件定義を開発会社に依頼する場合でも、発注者のたたき台があると打ち合わせの回数を減らせます。

Q. 何行くらいあれば十分ですか？

行数に正解はありません。小規模な業務ツールなら数十行、複数の利用者種別がある事業向けのサービスならそれ以上になることもあります。行数よりも、粒度がそろっていること、裏方の機能が漏れていないことを優先してください。

Q. 非機能要件（速度やセキュリティ）も一覧表に入れますか？

機能一覧表とは別の表にするのが一般的です。表示速度、同時利用者数、バックアップ、セキュリティなどは機能の行に混ぜると見落とされやすいため、「非機能要件」として別にまとめ、見積もり依頼時に一緒に渡します。

Q. 優先度は途中で変えてもよいですか？

変えてかまいません。むしろ、開発中に利用者の反応や業務の実態が分かって優先度が変わるのは自然なことです。ただし、変更したら開発会社に必ず共有し、費用や期間への影響を確認したうえで合意してください。

Otsumuに相談できること

利用者や業務がはっきりしていて、作りたいものが既存の業務をそのままシステムに置き換える性格のものであれば、この記事の手順で機能一覧表を作り、複数の開発会社に見積もりを依頼するところまでは自社で十分に進められます。表計算ソフトとこの記事のチェックリストがあれば、特別な知識は要りません。

一方で、新規事業で「何が必須か」自体がまだ分からない場合や、社内の関係者ごとに欲しい機能が違って絞り込めない場合、見積もりを取ってみたら予算と大きく離れていてどこを削るべきか判断できない場合は、外部の視点を入れた方が早く進むことが多いです。機能の優先度は、事業の目的や検証したい仮説から逆算して決めるものなので、作り手と事業側の両方の視点が必要になります。

Otsumuは自らも事業を手がける立場から、目的から逆算して必要な機能に絞る進め方を大切にしています。システム開発では機能一覧表のたたき台づくりから優先度の整理、AIを活用した少人数・短期間の開発、公開後の改善まで一気通貫で支援しています。新規事業の最初の版を短期間で形にしたい場合は新規事業の爆速MVPシステム開発もご覧ください。

作りかけの一覧表や、他社の見積もりを手元にお持ちの状態でもかまいません。「この範囲で必須はどこまでか」を一緒に整理するところから始められます。まずは30分の無料相談でお気軽にご相談ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01