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

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

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

• システム開発の機能一覧とは
  • 機能一覧と関連資料の違い
  • 機能一覧を依頼前に作るメリット
• 機能一覧を作る7つの手順
  • 1. システム化の目的と対象範囲を決める
  • 2. 利用者と権限を洗い出す
  • 3. 現在と導入後の業務を整理する
  • 4. 業務上の動作を1機能1行で抽出する
  • 5. 業務ルールと例外条件を追記する
  • 6. データ・外部連携・運用を確認する
  • 7. 優先度と初回リリース範囲を決める
• 機能一覧テンプレートと記入例
  • 最低限入れたい項目
  • 見積もり精度を上げる補足項目
  • 予約管理システムの記入例
  • 提出前のチェックリスト
• 作成費用・期間と見積もりでの使い方
  • 作成支援の費用・期間の目安
  • 機能数だけで開発費を判断しない
  • 相見積もりで確認する項目
  • 開発会社を見極めるポイント
  • よくある失敗と回避策
• まとめ
• よくある質問
  • 機能一覧は発注者だけで完成させる必要がありますか？
  • 機能一覧と画面一覧は何が違いますか？
  • 機能数が分かれば開発費を計算できますか？
  • 既存システムの情報はどこまで開発会社に共有すべきですか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

業務の流れから整理したい場合は、業務フロー図の作り方｜開発依頼前の準備も参考にしてください。機能一覧は、業務フローに現れる操作や自動処理を抜き出して作ると、実務とのずれを防ぎやすくなります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最低限入れたい項目

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

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

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

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

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

提出前のチェックリスト

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よくある失敗と回避策

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

まとめ

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

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

よくある質問

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

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

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

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

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

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

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

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