機能一覧表とは
機能一覧表(Function List)は、システムが提供する全機能を階層構造で一覧化した設計書です。「大機能(業務区分)→中機能(処理グループ)→小機能(個別処理)」の3階層で整理するのが一般的で、画面設計・API設計・工数見積の根拠資料として使用されます。
機能一覧表は要件定義フェーズで作成した「業務フロー図」「ユースケース図」を入力として作成します。ユースケース図の各ユースケースが小機能に対応し、アクターが機能を利用する権限(ロール)として引き継がれます。
💡 機能一覧表の用途
① 画面一覧の作成根拠(各小機能が1〜複数の画面に対応) ② バックエンドAPI設計の洗い出し ③ テーブル設計のCRUD分析 ④ 工数見積の作業単位 ⑤ リリーススコープのフェーズ管理
① 機能の分解構造
機能は「大機能 → 中機能 → 小機能」の3階層で分解します。各階層の目安は以下の通りです。
- 大機能(業務区分):「マスタ管理」「受注管理」「在庫管理」「帳票出力」など業務領域レベル
- 中機能(処理グループ):「商品マスタ管理」「顧客マスタ管理」など業務エンティティレベル
- 小機能(個別処理):「商品登録」「商品更新」「商品削除」「商品一覧表示」など個別処理レベル
| 機能ID | 大機能 | 中機能 | 小機能 | 機能概要 |
|---|---|---|---|---|
| F001 | マスタ管理 | 商品マスタ管理 | 商品一覧表示 | 商品情報をページネーション付き一覧で表示する |
| F002 | マスタ管理 | 商品マスタ管理 | 商品詳細表示 | 商品IDを指定して商品詳細情報を表示する |
| F003 | マスタ管理 | 商品マスタ管理 | 商品登録 | 新規商品情報を登録する |
| F004 | マスタ管理 | 商品マスタ管理 | 商品更新 | 既存商品情報を更新する |
| F005 | マスタ管理 | 商品マスタ管理 | 商品削除 | 商品を論理削除する(物理削除不可) |
| F006 | マスタ管理 | 顧客マスタ管理 | 顧客一覧表示 | 顧客情報を検索・フィルタ付き一覧で表示する |
| F010 | 受注管理 | 受注処理 | 受注入力 | 新規受注を入力・登録する |
| F011 | 受注管理 | 受注処理 | 受注承認 | 入力された受注を承認者が承認する |
② CRUD定義の記載
各機能が対象とするテーブルとCRUD操作(Create/Read/Update/Delete)を明記します。この情報はDB設計・APIエンドポイント設計・アクセス制御設計の根拠となります。
| 機能ID | 小機能 | 主テーブル | C | R | U | D | 関連テーブル |
|---|---|---|---|---|---|---|---|
| F001 | 商品一覧表示 | m_product | ● | m_category | |||
| F003 | 商品登録 | m_product | ● | m_category, m_maker | |||
| F004 | 商品更新 | m_product | ● | ● | m_category, m_maker | ||
| F005 | 商品削除 | m_product | ● | (delete_flg更新のみ) | |||
| F010 | 受注入力 | t_order | ● | ● | t_order_detail, m_product, m_customer |
⚠️ 論理削除 vs 物理削除の方針を明記する
削除操作について、論理削除(delete_flgフラグ更新)か物理削除(レコード削除)かをこの段階で方針決定し、機能一覧に明記します。特に監査ログ要件がある場合は物理削除は原則禁止とすることが多いです。
③ アクター(利用者)との紐付け
各機能を使用するアクター(ユーザーロール)を定義します。アクターは後の権限管理設計の基盤となります。
| 機能ID | 小機能 | 一般ユーザー | 担当者 | 管理者 | システム管理者 |
|---|---|---|---|---|---|
| F001 | 商品一覧表示 | ○ | ○ | ○ | ○ |
| F003 | 商品登録 | ○ | ○ | ○ | |
| F004 | 商品更新 | ○ | ○ | ○ | |
| F005 | 商品削除 | ○ | ○ | ||
| F011 | 受注承認 | ○ | ○ |
④ 優先度・フェーズ分類
全機能を一度のリリースで実装することが難しい場合、機能をフェーズ(リリース計画)に分類します。以下の基準で優先度を設定します。
- Must(必須):Phase 1 — システムが成立するために必要不可欠な機能
- Should(推奨):Phase 2 — あると業務効率が大幅に向上するが、初回リリースでは省略可能
- Could(オプション):Phase 3 — 利便性向上のための機能。後回し可能
- Won't(除外):今回のスコープ外。将来の拡張候補として記録
⑤ 非機能要件との関連付け
特定の機能に非機能要件(性能・セキュリティ)が課される場合、機能一覧に明記しておきます。
| 機能ID | 小機能 | 性能要件 | セキュリティ要件 | 備考 |
|---|---|---|---|---|
| F001 | 商品一覧表示 | 3秒以内にレスポンス(1万件検索時) | — | ページング必須(100件/ページ) |
| F010 | 受注入力 | 5秒以内にDB登録完了 | CSRF対策必須・入力値サニタイズ | 二重送信防止トークン実装 |
| F011 | 受注承認 | — | 承認者ロールのみアクセス可 | 操作ログ記録必須 |
Python Tips — 既存システムのログから機能を抽出する
既存システムのリプレース案件では、現行システムのアクセスログを解析して実際に利用されている機能を抽出することで、機能漏れを防げます。
"""
Apacheアクセスログから利用頻度の高いURLパスを集計して機能一覧作成に活用する。
pip install pandas
"""
import re
import pandas as pd
from pathlib import Path
from collections import Counter
# Apache Combined Log Format のパターン
LOG_PATTERN = re.compile(
r'(\S+)\s+' # IPアドレス
r'\S+\s+\S+\s+' # ident, authuser
r'\[([^\]]+)\]\s+' # 日時
r'"(\S+)\s+(\S+)\s+\S+"\s+' # メソッド, URL
r'(\d{3})\s+' # ステータスコード
r'(\d+|-)' # バイト数
)
def parse_access_log(log_path: str) -> pd.DataFrame:
"""アクセスログを解析してDataFrameに変換する"""
records = []
with open(log_path, encoding="utf-8", errors="replace") as f:
for line in f:
m = LOG_PATTERN.match(line.strip())
if m:
ip, dt, method, url, status, size = m.groups()
# クエリストリングを除去してパスのみ取得
path = url.split("?")[0]
records.append({
"ip": ip,
"method": method,
"path": path,
"status": int(status),
})
return pd.DataFrame(records)
def extract_function_candidates(df: pd.DataFrame, top_n: int = 50) -> pd.DataFrame:
"""
機能候補URLを抽出する。
- 静的リソース(CSS/JS/画像)を除外
- 成功レスポンス(2xx/3xx)のみ対象
- アクセス数上位N件を返す
"""
# 静的リソースを除外
STATIC_EXTS = ('.css', '.js', '.png', '.jpg', '.gif', '.ico', '.woff', '.woff2', '.svg')
mask_static = df['path'].apply(lambda p: not p.endswith(STATIC_EXTS))
mask_success = df['status'].between(200, 399)
filtered = df[mask_static & mask_success].copy()
# GETとPOSTを分類してURLを集計
url_counts = (
filtered.groupby(['method', 'path'])
.size()
.reset_index(name='count')
.sort_values('count', ascending=False)
.head(top_n)
)
# CRUD推定(HTTPメソッドから推定)
method_to_crud = {'GET': 'R(参照)', 'POST': 'C/U(登録/更新)', 'DELETE': 'D(削除)', 'PUT': 'U(更新)'}
url_counts['CRUD推定'] = url_counts['method'].map(method_to_crud).fillna('不明')
return url_counts
if __name__ == "__main__":
LOG_FILE = "/var/log/apache2/access.log" # ログファイルパスを変更
df = parse_access_log(LOG_FILE)
print(f"総リクエスト数: {len(df):,}件")
candidates = extract_function_candidates(df, top_n=30)
print("\n【機能候補URL 上位30件】")
print(candidates.to_string(index=False))
# Excelに出力して機能一覧作成に活用
candidates.to_excel("function_candidates.xlsx", index=False)
print("\nfunction_candidates.xlsx に出力しました")
✅ 活用シーン
上記スクリプトで抽出したURL一覧を機能一覧表の「小機能」に対応させることで、現行システムの実態に即した機能洗い出しが可能です。アクセス数ゼロのURLは「実際に使われていない機能=リプレース対象外」として判断できます。
定義チェックリスト
| チェック項目 | 確認ポイント |
|---|---|
| □ 全業務領域の機能が網羅されているか | 業務フロー図・ユースケース図と突き合わせて漏れがないか |
| □ 3階層(大・中・小)で整理されているか | 大機能・中機能・小機能の粒度が適切か |
| □ 機能IDが一意に割り当てられているか | 他ドキュメントからの参照に使えるIDか |
| □ CRUD定義が全小機能に記載されているか | 主テーブルと操作種別が明記されているか |
| □ アクターと機能の対応が定義されているか | どのロールがどの機能を使えるかが明確か |
| □ フェーズ・優先度が設定されているか | 全機能がMust/Should/Couldに分類されているか |
| □ 関係者のレビューを受けているか | 業務担当者・PL・PMのサインオフが得られているか |