# 機能一覧の作り方｜システム開発の依頼準備

- 公開日: 2026-09-07
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/column/system-function-list-preparation

システム開発を依頼する前の機能一覧は、「誰が・何の目的で・何をするか」を1機能1行で整理し、優先度と未決事項を付けるのが要点です。画面名だけを並べず、業務ルール・権限・外部連携・完了条件まで記載すると、見積もり漏れと各社の前提差を減らせます。

ただし、発注者だけで技術仕様まで完成させる必要はありません。まずは業務上必要な機能と後回しにできる機能を区別し、分からない点を「未決」と明示することが大切です。本記事では、システム開発の相談を受ける立場から、機能一覧の作り方、テンプレート、費用・期間、見積もりでの使い方を解説します。

## システム開発の機能一覧とは

機能一覧とは、システムの利用者が実行できる操作や、システムが自動で行う処理を一覧化した資料です。要件定義（＝作るものを決める工程）の入口に位置し、発注者と開発会社が開発範囲を共通認識にするために使います。

例えば、顧客管理システムなら「顧客登録」「顧客検索」「担当者変更」「CSV出力」「重複候補の通知」などが機能に該当します。一方、「顧客情報を効率的に管理したい」は要望であり、そのままでは見積もり可能な機能になっていません。

### 機能一覧と関連資料の違い

依頼前の資料は役割が異なります。機能一覧だけですべてを表現しようとせず、必要に応じて資料を分けると読みやすくなります。

| 資料 | 主な内容 | 答える問い |
|---|---|---|
| 課題・要望リスト | 現状の問題、実現したい状態 | なぜ作るのか |
| 業務フロー | 担当者、作業、判断、情報の流れ | 業務がどう流れるか |
| 機能一覧 | 操作、自動処理、優先度、条件 | 何ができる必要があるか |
| 画面一覧 | 画面名、利用者、画面間の移動 | どの画面が必要か |
| データ一覧 | 顧客、商品、申請などの情報 | 何を保存・利用するか |
| 非機能要件一覧 | 性能、セキュリティ、可用性など | どの品質水準が必要か |
| 要件定義書 | 上記を含む合意済みの要件 | 何をどの条件で作るか |

特に、機能一覧と画面一覧は同じものではありません。「申請詳細画面」に閲覧、編集、承認、差し戻し、コメント登録といった複数機能が含まれることがあります。反対に、期限前の自動通知や夜間のデータ集計は画面を持たない機能です。

### 機能一覧を依頼前に作るメリット

機能一覧の目的は、文書をきれいに仕上げることではありません。発注判断に必要な情報をそろえることです。

- 開発対象と対象外を区別できる
- 複数社へおおむね同じ条件で見積もりを依頼できる
- 必須機能と追加候補を分け、予算超過時に調整しやすくなる
- 部門間で要望の重複や矛盾を見つけられる
- 外部サービスとの連携や権限設定など、見落としやすい項目を発見できる
- 開発中の追加要望が、当初範囲か仕様変更かを判断しやすくなる

開発会社の立場から見ると、「会員管理」「予約管理」のような大分類だけでは見積もりの前提を置きにくいのが実情です。登録できるだけなのか、承認、履歴、重複判定、一括取込、通知まで必要なのかによって、必要な設計とテストが変わるためです。

## 機能一覧を作る7つの手順

機能一覧は、思いついた機能を先に並べるより、目的と業務から順に整理した方が抜け漏れを抑えられます。次の7段階で進めるのが基本です。

### 1. システム化の目的と対象範囲を決める

最初に「このシステムで何を改善するか」を1〜3文で定義します。目的が曖昧なままでは、便利そうな機能が増え続け、優先順位を付けられません。

目的の例は次のとおりです。

- 電話と表計算ソフトで行っている予約受付をオンライン化する
- 月末に3日かかっている請求集計を1日以内に短縮する
- 営業担当者ごとに分散している顧客対応履歴を共有する

併せて、今回の対象外も決めます。「会計仕訳は既存サービスで行う」「スマートフォンアプリは初回公開に含めない」など、境界を言語化してください。

### 2. 利用者と権限を洗い出す

同じ機能でも、誰が使うかによって必要な権限や操作が変わります。利用者を「一般ユーザー」「管理者」だけで済ませず、業務上の役割で整理します。

- 顧客・会員
- 営業担当者
- 営業責任者
- 経理担当者
- システム管理者
- 取引先担当者
- 外部委託先

例えば顧客情報について、営業担当者は自分の担当分のみ閲覧でき、責任者は部門全体を閲覧でき、管理者だけが削除できる、といった違いがあります。権限は後から追加すると複数機能へ影響しやすいため、依頼前に大枠を整理しておきます。

### 3. 現在と導入後の業務を整理する

現在の業務で「誰が、何を受け取り、どう判断し、次に誰へ渡すか」を確認します。その後、システム導入後にどこを自動化し、どこを人の判断として残すかを考えます。

業務の流れから整理したい場合は、[業務フロー図の作り方｜開発依頼前の準備](https://www.geek-bridge.com/column/business-flow-development-preparation)も参考にしてください。機能一覧は、業務フローに現れる操作や自動処理を抜き出して作ると、実務とのずれを防ぎやすくなります。

### 4. 業務上の動作を1機能1行で抽出する

業務フローに出てくる動詞に注目します。「登録する」「検索する」「申請する」「承認する」「通知する」「集計する」などを機能候補として抽出します。

機能名は、対象と動作が分かるように書きます。

- 不明確な例：顧客管理
- 改善例：顧客を新規登録する
- 改善例：条件を指定して顧客を検索する
- 改善例：顧客情報をCSVで一括登録する
- 改善例：顧客情報の変更履歴を確認する

1行が大きすぎると見積もりの前提が曖昧になり、細かすぎると一覧を管理しにくくなります。発注準備の段階では、利用者から見て一つの目的を達成する操作を1機能と考え、開発会社との打ち合わせで分割・統合する方法が現実的です。

### 5. 業務ルールと例外条件を追記する

見積もり差が生まれやすいのは、通常操作より業務ルールと例外処理です。各機能について、少なくとも次の点を確認します。

- 入力必須となる項目は何か
- 誰が登録・閲覧・編集・削除できるか
- 承認は何段階か、金額などで承認者が変わるか
- 同じデータが登録された場合にどうするか
- 締め日を過ぎたデータを変更できるか
- エラー時に誰へ何を通知するか
- 取り消しや差し戻しが必要か
- 操作履歴を残す必要があるか

この時点ですべて決められない場合は、推測で埋めず「未決」と記載します。未決事項の件数と重要度が分かれば、開発会社も要件整理に必要な期間を見積もれます。

### 6. データ・外部連携・運用を確認する

画面操作だけでなく、データと運用に関する機能も確認します。

- 既存データの初期登録や移行
- CSV・Excelの入出力
- メール、SMS、プッシュ通知
- 決済、会計、地図、本人確認などの外部サービス連携
- 定期的な集計やバッチ処理（＝決まった時刻などにまとめて行う自動処理）
- 管理者によるユーザー停止やデータ修正
- 問い合わせ対応に必要な検索・履歴確認
- マスターデータ（＝選択肢や料金など、業務の基準となるデータ）の管理

発注者が見落としやすいのは、利用者向け機能より管理・運用機能です。サービス公開後に誰がアカウントを管理し、誤登録を修正し、問い合わせを調査するかまで想定してください。

### 7. 優先度と初回リリース範囲を決める

すべてを必須にすると、予算や納期に応じた調整ができません。MoSCoW法（＝必要度を4段階に分ける方法）などを使い、優先度を決めます。

| 区分 | 意味 | 判断の目安 |
|---|---|---|
| Must | 初回に必須 | ないと主要業務や法令対応が成立しない |
| Should | 重要 | 代替運用は可能だが、早期に必要 |
| Could | 余裕があれば実装 | 利便性は上がるが、公開後でも対応可能 |
| Won't | 今回は対象外 | 将来候補として記録する |

優先順位は「欲しいかどうか」だけでなく、事業への影響、代替手段、利用頻度、依存関係で判断します。例えば利用頻度が低くても、法令対応や重大事故の防止に必要ならMustになり得ます。

## 機能一覧テンプレートと記入例

依頼前の機能一覧は、表計算ソフトで作成すれば十分です。最初から詳細な仕様書にせず、「見積もりに必要な最低限の列」と「検討を進めるための補足列」に分けると運用しやすくなります。

### 最低限入れたい項目

| 項目 | 記載内容 |
|---|---|
| 機能ID | F-001など重複しない番号 |
| 大分類 | 会員、予約、請求、管理など |
| 機能名 | 対象と動作が分かる名称 |
| 利用者 | 顧客、担当者、管理者など |
| 目的・概要 | 何のために何ができるか |
| 主な条件 | 権限、承認、上限、締め日など |
| 優先度 | Must、Should、Could、Won't |
| 初回対象 | 初回リリースに含めるか |
| 未決事項 | 決まっていない条件や確認先 |

### 見積もり精度を上げる補足項目

- 入力するデータ
- 出力・表示するデータ
- 外部サービスとの連携有無
- 通知先と通知手段
- 関連する既存システム
- 想定利用人数や処理件数
- 完了条件・受入条件
- 関連する画面や帳票
- 備考・参考資料の保存場所

受入条件とは、発注者が完成と判断するための条件です。例えば「予約登録ができる」だけでなく、「空き枠だけを選択でき、登録後に顧客と店舗へ確認メールが送信される」と書けば、認識を合わせやすくなります。

### 予約管理システムの記入例

| ID | 大分類 | 機能名 | 利用者 | 概要・主な条件 | 優先度 | 未決事項 |
|---|---|---|---|---|---|---|
| F-001 | 会員 | メールアドレスで会員登録する | 顧客 | 認証メールを送り、確認後に登録を完了する | Must | SNSログインを含めるか |
| F-002 | 予約 | 空き枠を検索する | 顧客 | 店舗、日付、メニューから予約可能枠を表示する | Must | 検索可能期間の上限 |
| F-003 | 予約 | 予約を登録する | 顧客 | 同一枠の重複を防ぎ、登録完了を通知する | Must | 仮予約を設けるか |
| F-004 | 予約 | 予約をキャンセルする | 顧客・店舗 | 予約開始24時間前まで顧客が操作可能 | Should | キャンセル料の扱い |
| F-005 | 通知 | 予約前日にリマインドする | システム | メールを自動送信し、失敗履歴を保存する | Should | SMSも利用するか |
| F-006 | 管理 | 予約実績をCSV出力する | 店舗管理者 | 期間と店舗を指定して出力する | Could | 出力項目の確定 |

この例のように、決まっていないことを未決事項として残せば、相談時の議題になります。空欄にすると「考慮不要」と受け取られる可能性があるため、未確認なのか対象外なのかを区別してください。

### 提出前のチェックリスト

- システム化の目的が機能一覧の冒頭に書かれている
- 対象となる利用者と権限が整理されている
- 1行ごとに対象と動作が分かる機能名になっている
- 通常処理だけでなく、取消、差し戻し、エラー時の処理がある
- 管理者向けの設定、検索、修正、履歴確認が含まれている
- データ取込、出力、移行の有無が書かれている
- 外部サービスや既存システムとの連携が明記されている
- 全機能がMustになっておらず、優先順位が付いている
- 初回リリースの対象と将来候補が区別されている
- 決め切れていない点が未決事項として記録されている
- 個人情報や秘密情報を必要以上に記載していない
- 部門責任者と実際の業務担当者が内容を確認している

## 作成費用・期間と見積もりでの使い方

機能一覧を社内で作成する場合、外部費用はかかりません。ただし、複数部門へのヒアリングや既存システムの調査が必要な案件では、開発会社やコンサルタントへ要求整理を依頼する選択肢があります。

### 作成支援の費用・期間の目安

以下は、機能一覧の整理を含む依頼前支援の一般的な目安です。実際の費用は、対象業務、関係者数、資料の有無、既存システムの複雑さ、成果物の詳細度によって変わります。開発費は含みません。

| 進め方 | 費用の目安 | 期間の目安 | 向いている状況 |
|---|---:|---:|---|
| 社内で作成 | 外部費用なし | 3営業日〜2週間 | 対象業務が限定され、担当者が内容を把握している |
| ワークショップ形式の整理支援 | 20万〜60万円 | 1〜3週間 | 要望はあるが優先順位や分類に迷っている |
| 業務ヒアリングを含む整理支援 | 50万〜150万円 | 3〜6週間 | 複数担当者がおり、業務ルールの確認が必要 |
| 複数部門・既存システム調査を含む支援 | 100万〜300万円以上 | 1〜3か月 | 部門横断、大規模刷新、外部連携が多い |

最初から全社分を詳細化せず、重要な業務領域だけを1〜2回の打ち合わせで整理し、開発の実現性と概算予算を確認する方法もあります。予算感と機能の優先順位が合わない場合は、本格的な要件定義へ進む前に対象範囲を見直せます。

### 機能数だけで開発費を判断しない

機能一覧は見積もりの土台になりますが、「1機能あたり一律いくら」という計算はできません。次の条件で開発工数が変わるためです。

- 業務ルールや計算式の複雑さ
- 承認段階や権限パターンの数
- 外部サービスとの接続方法や制約
- 扱うデータ量と処理速度の要件
- 個人情報、決済情報などのセキュリティ水準
- エラー処理、再実行、取消処理の必要性
- 管理画面、監査履歴、問い合わせ対応機能の範囲
- テスト対象となる端末、ブラウザ、利用条件

例えば「料金を計算する」という1行でも、固定料金を表示するだけの場合と、契約条件、時間帯、割引、税区分、上限額を組み合わせる場合では工数が異なります。機能数が少ない見積もりだから安いとは限りません。

### 相見積もりで確認する項目

複数社へ見積もりを依頼する際は、同じ機能一覧を共有したうえで、各社が置いた前提を比較します。

| 確認項目 | 見るポイント |
|---|---|
| 対象機能 | Must・Shouldのどこまで含むか |
| 要件整理 | 未決事項を詰める費用が含まれるか |
| 設計・テスト | どの工程と成果物が含まれるか |
| 外部連携 | 接続開発、利用料、申請作業の扱い |
| データ移行 | 調査、整形、移行、照合の範囲 |
| インフラ・保守 | 公開環境、監視、公開後対応の有無 |
| 仕様変更 | 追加費用を判断する手続き |
| 対象外 | 発注者側で対応する作業 |

概算見積もりは、現時点の情報を基にした予算判断用の金額です。機能一覧があっても業務ルールや画面仕様が未確定なら、金額が変動する可能性があります。固定金額だけを見るのではなく、「どの前提で、何が含まれ、どこから追加になるか」を確認してください。

### 開発会社を見極めるポイント

機能一覧を渡したときに、記載された機能をそのまま見積もるだけでなく、目的や業務上の必要性まで質問する会社が適しています。

- システム化の目的と成功条件を確認する
- 実際の利用者や業務担当者へ質問する
- 正常時だけでなく例外処理や運用を確認する
- 機能の分割・統合と、その理由を説明する
- 予算に応じて優先順位や段階導入を提案する
- 未決事項と見積もり前提を文書に残す
- 要件確定後に費用が変わる条件を説明する
- 成果物の利用権、保管場所、更新担当を明確にする

一方、依頼時点で詳細が決まっていないこと自体は問題ではありません。「どこまで決まっていて、何が分からないか」を共有できれば、必要な調査や要件定義の進め方を提案できます。機能整理から支援が必要な場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談ください。

### よくある失敗と回避策

| よくある失敗 | 起きる問題 | 回避策 |
|---|---|---|
| 画面名だけを並べる | 自動処理や操作条件が見積もりから漏れる | 利用者、動作、条件を1行に記載する |
| 正常な流れだけを書く | 取消、差し戻し、エラー対応が後から追加される | 例外時と運用時の処理を確認する |
| 全機能をMustにする | 予算超過時に範囲を調整できない | 代替運用と事業影響で優先度を付ける |
| 現行機能をすべてコピーする | 不要な業務や非効率な運用まで引き継ぐ | 目的に照らして廃止・簡略化を検討する |
| 未決事項を空欄にする | 開発会社ごとに異なる前提で見積もられる | 「未決」「対象外」「別途確認」を区別する |
| 管理・運用機能を後回しにする | 公開後の問い合わせや修正に対応できない | 管理者の作業も業務フローとして整理する |
| 開発会社に丸投げする | 業務実態と異なる要件になる | 業務判断は発注者、技術整理は開発会社と役割分担する |

特に避けたいのは、一覧を詳細にすること自体が目的になる状態です。利用頻度の低い例外をすべて初回へ盛り込むより、業務上のリスクを確認したうえで、手作業による代替が可能なものを公開後へ回す方が適切な場合もあります。

## まとめ

- 機能一覧は「誰が・何の目的で・何をするか」を1機能1行で整理する資料です
- 画面名だけでなく、権限、業務ルール、例外処理、外部連携、運用機能を確認します
- 発注前に技術仕様まで完成させる必要はなく、未決事項を明示することが重要です
- Must、Should、Could、Won'tに分け、初回リリースの範囲を調整できるようにします
- 機能数だけでは開発費を計算できないため、複雑さや見積もり前提も比較します
- 作成支援は一般的に20万〜300万円以上、1週間〜3か月程度が目安ですが、対象業務や成果物によって変わります
- 開発会社には同じ機能一覧を渡し、対象範囲、未決事項、対象外、仕様変更時の扱いを確認します

機能一覧は、発注者がシステムの細部を一人で決めるための資料ではありません。事業と業務の視点を発注者が示し、技術面と実現方法を開発会社が補うための共通言語です。完璧さよりも、目的、優先順位、未決事項が正直に整理されていることを重視してください。

## よくある質問

### 機能一覧は発注者だけで完成させる必要がありますか？

いいえ、依頼前に完成させる必要はありません。発注者は目的、利用者、必要な業務、優先順位、未決事項を整理し、技術的な分割や例外条件は開発会社と詰める進め方が現実的です。

### 機能一覧と画面一覧は何が違いますか？

機能一覧は利用者がシステムで実行できることを整理した資料で、画面一覧は必要な画面を整理した資料です。1画面に複数機能が含まれる場合や、通知・自動処理のように画面を持たない機能もあるため、両者は分けて管理します。

### 機能数が分かれば開発費を計算できますか？

機能数だけでは正確に計算できません。同じ1機能でも、業務ルール、権限、外部連携、データ量、セキュリティ、例外処理によって工数が大きく変わります。機能一覧は概算見積もりの土台として使い、詳細条件を確認して精度を上げます。

### 既存システムの情報はどこまで開発会社に共有すべきですか？

現行の機能一覧、業務フロー、画面、帳票、データ項目、外部連携、利用人数、課題を共有すると提案の精度が上がります。機密情報や個人情報はそのまま渡さず、必要に応じて秘密保持契約を締結し、匿名化したサンプルを用意してください。