機能一覧の書き方とテンプレート 機能IDの採番と粒度の決め方

機能一覧とは、システムが持つ機能を1行に1つずつ並べ、機能ID・分類・機能名・種別・概要・利用者・優先度を表にした設計書です。 画面設計書・帳票設計書・バッチ設計書・テスト仕様書がすべて機能IDで結びつくため、後の工程の目次の役割を持ちます。

機能一覧を書くときに迷いやすいのは、「機能IDをどう振るか」と「どの細かさで1行にするか」の2点です。この記事では、表計算ソフトに貼れるテンプレートを架空の予約管理システムの記入例30行で示したうえで、機能IDの採番ルール3方式の比較と、粒度をそろえる判断基準を表にまとめます。件数の集計と重複IDの検出を Python で行う例も、出力つきで載せています。

確認環境：Ubuntu 24.04 / Python 3.11.15（標準ライブラリの csv・re・collections のみ使用）

機能一覧の早見表

機能一覧表の項目一覧

小分類に使う語は、あらかじめ決めておくと表記がそろいます。

テンプレートと記入例：予約管理システムの30機能

架空の「社内備品の予約管理システム」を題材にした記入例です。機能IDは「大分類の略号3文字－種別の記号1文字＋連番2桁」で振っています（RSV＝予約管理、ITM＝備品管理、USR＝利用者管理、CMN＝共通／S＝画面、R＝帳票、B＝バッチ、A＝API）。

表計算ソフトに貼れるタブ区切りです。1行目が見出しです。このままファイル（functions.tsv）に保存すると、後ろの Python スクリプトで集計できます。

機能ID    大分類 中分類 小分類 機能名 種別  概要  利用者 優先度
RSV-S01 予約管理    予約  検索  空き状況検索  画面  備品と期間を指定して空き状況を表示する 一般利用者   高
RSV-S02 予約管理    予約  登録  予約登録    画面  備品・期間・数量・目的を入力して予約を申請する 一般利用者   高
RSV-S03 予約管理    予約  変更  予約変更    画面  申請中の予約の期間と数量を変更する   一般利用者   高
RSV-S04 予約管理    予約  取消  予約取消    画面  自分の予約を取り消す  一般利用者   高
RSV-S05 予約管理    予約  照会  予約一覧    画面  自分の予約を状態別に一覧表示する    一般利用者   高
RSV-S06 予約管理    承認  承認  予約承認    画面  申請中の予約を承認または差し戻す    管理者 高
RSV-R01 予約管理    帳票  出力  予約票出力   帳票  承認済みの予約1件を予約票としてPDFに出力する    一般利用者   中
RSV-R02 予約管理    帳票  出力  月次利用状況表出力   帳票  備品別・部署別の月間利用日数を出力する 管理者 中
RSV-B01 予約管理    通知  送信  利用前日リマインド通知 バッチ 利用開始日の前日に予約者へメールを送る システム    中
RSV-B02 予約管理    通知  送信  返却期限超過通知    バッチ 利用終了日を過ぎた未返却の予約を管理者へ通知する    システム    中
RSV-A01 予約管理    連携  取得  空き状況取得API   API 備品コードと期間から空き状況を返す   システム    低
RSV-A02 予約管理    連携  登録  予約登録API API 社内ポータルからの予約申請を受け付ける システム    低
ITM-S01 備品管理    備品  照会  備品一覧    画面  備品を区分・状態で絞り込んで一覧表示する    管理者 高
ITM-S02 備品管理    備品  登録  備品登録    画面  備品コード・名称・区分を登録する    管理者 高
ITM-S03 備品管理    備品  変更  備品変更    画面  備品の名称・区分・備考を変更する    管理者 高
ITM-S04 備品管理    備品  停止  備品利用停止  画面  修理中などの備品を予約対象から外す   管理者 中
ITM-R01 備品管理    帳票  出力  備品台帳出力  帳票  全備品の一覧を表計算ファイルに出力する 管理者 中
ITM-B01 備品管理    取込  登録  備品マスタ一括取込   バッチ CSVファイルから備品をまとめて登録・更新する 管理者 低
ITM-B02 備品管理    棚卸  作成  棚卸用データ作成    バッチ 期末に備品ごとの所在と状態の一覧を作成する   システム    低
ITM-A01 備品管理    連携  取得  備品情報取得API   API 備品コードから名称・区分・状態を返す  システム    低
USR-S01 利用者管理   利用者 照会  利用者一覧   画面  利用者を部署・状態で絞り込んで一覧表示する   管理者 高
USR-S02 利用者管理   利用者 登録  利用者登録   画面  氏名・部署・メールアドレスを登録する  管理者 高
USR-S03 利用者管理   利用者 変更  利用者変更   画面  利用者の部署と有効・無効を変更する   管理者 高
USR-S04 利用者管理   権限  設定  権限設定    画面  利用者に一般・管理者の権限を割り当てる 管理者 中
USR-B01 利用者管理   取込  登録  人事データ取込 バッチ 毎日夜間に人事システムの異動情報を反映する   システム    中
USR-A01 利用者管理   連携  取得  利用者情報取得API  API 利用者IDから氏名と部署を返す システム    低
CMN-S01 共通  認証  ログイン    ログイン    画面  IDとパスワードで認証する   一般利用者   高
CMN-S02 共通  メニュー    表示  メニュー    画面  権限に応じた機能の入口を表示する    一般利用者   高
CMN-S03 共通  お知らせ    登録  お知らせ管理  画面  利用者向けのお知らせを登録・公開する  管理者 低
CMN-B01 共通  ログ  整理  操作ログ保管整理    バッチ 保管期間を過ぎた操作ログを退避して削除する   システム    低

優先度の凡例は、次のように表の近くに書いておきます。

機能IDの採番ルール3方式の比較

機能IDの振り方は、大きく3つの方式に分けられます。

どの方式でも共通して決めておくルールは次の6つです。

途中に機能を足す可能性が高いときは、連番を10刻み（010、020、030）で振る方法もあります。間に 015 を入れられるので、並び順を保ったまま追加できます。

方式を選ぶ判定表

粒度をそろえる判断基準

粒度の基本は「1機能＝1画面／1帳票／1バッチ／1API」 です。設計書を1つ書く単位、テストで1つのまとまりとして確かめる単位と一致するので、工数の見積もりや進み具合の管理にもそのまま使えます。

分ける・まとめるの判定表

迷ったときは、次の表に当てはめます。「分ける」が1つでも当てはまれば別の行にします。

記入例に当てはめると、次のようになります。

粒度がそろっているかを数で確かめる

粒度のばらつきは、件数を数えると気づきやすくなります。目安として、次の3点を見ます。

• 大分類ごとの機能数に極端な差がないか（1つの大分類だけ数十個あるなら、分類の分割を考える）
• 「〜管理」「〜処理」のような広い名前の機能が残っていないか（登録・変更・照会に分けられる）
• 概要が1文で書けない機能がないか（書けないときは複数の機能が混ざっている）

Pythonで件数集計と重複IDを検出する

保存した functions.tsv を読み込み、種別ごとの件数、大分類×種別の件数、優先度ごとの件数を数え、機能IDの点検（重複、書式、分類・種別との対応、空欄）を行うスクリプトです。

import csv
import re
import sys
from collections import Counter

PREFIX = {"予約管理": "RSV", "備品管理": "ITM", "利用者管理": "USR", "共通": "CMN"}
KIND = {"画面": "S", "帳票": "R", "バッチ": "B", "API": "A"}
ID_PATTERN = re.compile(r"(RSV|ITM|USR|CMN)-[SRBA][0-9]{2}")

path = sys.argv[1]
with open(path, encoding="utf-8", newline="") as f:
    rows = list(csv.DictReader(f, delimiter="\t"))
print(f"{path}: {len(rows)}機能")

# 1. 種別ごとの件数
kinds = Counter(r["種別"] for r in rows)
print("種別ごとの件数:", " / ".join(f"{k} {kinds[k]}" for k in KIND))

# 2. 大分類×種別の件数
print(f"{'大分類':<8}" + "".join(f"{k:>6}" for k in KIND) + f"{'計':>6}")
for major in PREFIX:
    counts = [sum(1 for r in rows if r["大分類"] == major and r["種別"] == k) for k in KIND]
    print(f"{major:<8}" + "".join(f"{c:>7}" for c in counts) + f"{sum(counts):>7}")

# 3. 優先度ごとの件数
prio = Counter(r["優先度"] for r in rows)
print("優先度ごとの件数:", " / ".join(f"{p} {prio[p]}" for p in ("高", "中", "低")))

# 4. 点検（重複ID・書式・分類との対応・空欄）
problems = []
for fid, n in Counter(r["機能ID"] for r in rows).items():
    if n > 1:
        names = [r["機能名"] for r in rows if r["機能ID"] == fid]
        problems.append(f"重複ID {fid}: {'、'.join(names)}")
for line, r in enumerate(rows, start=2):
    fid = r["機能ID"]
    if ID_PATTERN.fullmatch(fid) is None:
        problems.append(f"{line}行目 {fid}: IDの書式が採番ルールと違う")
        continue
    if PREFIX.get(r["大分類"]) != fid[:3]:
        problems.append(f"{line}行目 {fid}: 大分類「{r['大分類']}」と接頭辞が合わない")
    if KIND.get(r["種別"]) != fid[4]:
        problems.append(f"{line}行目 {fid}: 種別「{r['種別']}」と種別記号が合わない")
    empty = [k for k, v in r.items() if v.strip() == ""]
    if empty:
        problems.append(f"{line}行目 {fid}: 空欄あり（{'、'.join(empty)}）")
print(f"点検結果: {len(problems)}件")
for p in problems:
    print("  -", p)

記入例の30行に対して実行した結果です（python3 check_functions.py functions.tsv）。

functions.tsv: 30機能
種別ごとの件数: 画面 17 / 帳票 3 / バッチ 6 / API 4
大分類         画面    帳票   バッチ   API     計
予約管理          6      2      2      2     12
備品管理          4      1      2      1      8
利用者管理         4      0      1      1      6
共通            3      0      1      0      4
優先度ごとの件数: 高 14 / 中 8 / 低 8
点検結果: 0件

次に、点検が働くことを確かめるため、わざと5か所を書き換えたファイル（functions_ng.tsv）を用意しました。予約取消のIDを RSV-S03 に、返却期限超過通知のIDを RSV-S07 に、備品台帳出力のIDを ITM-R1 に、利用者変更の利用者を空欄に、ログインのIDを RSV-S01 に変えています。

functions_ng.tsv: 30機能
…（集計部分は省略）…
点検結果: 6件
  - 重複ID RSV-S01: 空き状況検索、ログイン
  - 重複ID RSV-S03: 予約変更、予約取消
  - 11行目 RSV-S07: 種別「バッチ」と種別記号が合わない
  - 18行目 ITM-R1: IDの書式が採番ルールと違う
  - 24行目 USR-S03: 空欄あり（利用者）
  - 28行目 RSV-S01: 大分類「共通」と接頭辞が合わない

5か所の書き換えから6件が見つかりました。ログインのIDを RSV-S01 にした行は、重複と大分類の食い違いの両方で検出されています。重複IDは目で探すと見落としやすいので、機能を追加・変更するたびに機械的に点検する のがおすすめです。

機能一覧から後の工程へのつなげ方

機能IDは、後の工程の成果物に必ず書き写します。

機能一覧のチェックリスト

よくある質問

Q. 機能一覧はどの工程で作りますか？ A. 要件定義の終わりから基本設計の初めにかけて作ります。要件定義では大分類・中分類までの粗い一覧を作り、基本設計で1画面・1帳票・1バッチ・1APIの単位まで細かくして機能IDを確定させる進め方が一般的です。

Q. 登録・変更・取消・照会を1つの「〜管理」機能にまとめてもよいですか？ A. 入口や権限が同じで、あわせて短い期間で作れる小さなマスタなら、まとめても構いません。ただし一覧の中で基準を混ぜると件数や見積もりが比べにくくなるので、「マスタ保守は1機能にまとめる」のように基準を決めて凡例に書きます。

Q. 途中で分類が変わったら、機能IDも振り直しますか？ A. 振り直しません。機能IDは設計書やテストの結びつきに使われているため、変えると影響が広がります。分類の列だけを直し、IDと分類が合わなくなった行は備考にその旨を書きます。こうした変更が多いと見込まれる場合は、分類を含めない方式（AかB）を選びます。

Q. 画面IDと機能IDは同じにしてよいですか？ A. 1機能＝1画面の単位にしているなら、同じにすると管理が楽になります。入力・確認・完了のように1機能に複数の画面がある場合は、機能IDに枝番を付けて画面IDにします（RSV-S02-1、RSV-S02-2 など）。

まとめ

• 機能一覧は「1行1機能」 で、機能ID・大／中／小分類・機能名・種別・概要・利用者・優先度を列にする
• 粒度は1機能＝1画面／1帳票／1バッチ／1API にそろえる
• 分けるか迷ったら、利用者・入口・操作の種類・起動の時刻・作る時期 の違いで判定する
• 機能IDは通し連番、種別＋連番、分類＋種別＋連番の3方式 から規模と体制で選ぶ
• 桁数を固定し、一度振ったIDは変えず、欠番は再利用しない
• 重複ID・書式・空欄は機械的に点検 し、種別ごとの件数で粒度のばらつきを確かめる

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。