機能一覧は、要件定義フェーズの成果物のなかでもっとも後工程に影響する表です。ここに載らなかった機能は見積もりに入らず、体制にも日程にも反映されません。後から出てくると、たいてい揉めます。
それだけ重要なのに、作り方は属人的です。ヒアリングのメモを眺めながら、経験のある人が頭の中で機能に切り分けている、というのが実態ではないでしょうか。
この作業の洗い出しと粒度そろえの部分は、生成AIにかなり任せられます。一方で、任せると見積もりが壊れる判定もはっきり存在します。この記事では、その境界線を含めて手順をまとめます。
機能一覧とは｜見積もりの土台になる表
機能一覧（システム機能一覧）とは、構築するシステムの機能をすべて並べ、それぞれをどう実現するかまで定義した一覧表です。単なる機能の目録ではありません。
一覧に持たせる列は、おおむね次のようになります。
| 列 | 何を書くか |
|---|---|
| 機能ID | 一意に特定するための採番 |
| 機能名／機能概要 | 何をする機能か |
| 業務分類（大・中・小） | どの業務に属するか |
| 機能分類 | 画面・帳票・バッチなどの種別 |
| 実現方法 | 標準機能の設定か、開発か。具体的にどう実現するか |
| 難易度 | 工数見積もりのための区分 |
| 備考 | 制約事項・前提 |
この表が「目録」ではなく「見積もりの土台」になるのは、実現方法と難易度の2列があるからです。この2列が無い機能一覧は、後工程で作り直しになります。
様式はシステム機能一覧のテンプレートをそのまま使えます。
用意するもの
機能一覧は、ゼロから発明するものではありません。必ず元になる情報があります。
| 入力 | 具体例 |
|---|---|
| 業務ヒアリングの記録 | 業務ヒアリングシートの記入結果、議事録 |
| 業務の全体像 | 業務機能階層図、組織図・業務体系図 |
| 現行システムの資産 | 既存の画面・帳票・バッチの一覧 |
| 要求の記録 | 要求仕様管理一覧 |
| 記入先の様式 | 使う機能一覧テンプレートの見出し行 |
このうち現行システムの画面・帳票・バッチ一覧は、あるなら必ず入れてください。移行案件では、機能の8割がここから導けます。逆にこれを渡さないと、AIは一般的な業務システムの機能を創作します。
手順
① ヒアリングメモから機能候補を洗い出させる
まず、量を出します。この段階で絞らないのがコツです。
ヒアリング記録と業務の全体像を渡し、「この業務を実現するために必要なシステム機能を、抜けなく挙げて」と依頼します。重複や粒度のばらつきは、この時点では気にしません。
人が最初から整った一覧を作ろうとすると、思いつかなかった機能がそのまま抜けます。AIに大量に出させてから削るほうが、抜けが減ります。
② 粒度を揃える
ここが機能一覧づくりの本丸です。洗い出した候補は、粒度がばらばらになっています。
粒度の基準は、「見積もれる単位か」で決めます。
- 粗すぎる（例：「受注管理」）→ 何人日かかるか誰にも答えられない
- 細かすぎる（例：「受注画面の得意先コード入力欄」）→ 一覧が数百行になり、管理そのものが目的化する
- ちょうどよい（例：「受注登録画面」「受注一覧照会画面」「受注確定バッチ」）
実務的には1機能＝1画面／1帳票／1バッチを基準にすると、ほぼ破綻しません。「この機能は何画面ぶんか」と問い返せる状態になっていれば、粒度は足りています。
AIには、基準を明示して揃え直させます。「1機能＝1画面・1帳票・1バッチの単位に分割・統合して」と指示すれば、機械的に整います。
③ 機能分類と業務分類を振らせる
粒度が揃ったら、画面・帳票・バッチの分類と、業務分類（大・中・小）を振ります。この作業は完全に機械的なので、そのまま任せて構いません。
業務分類は後で並び替えと集計に使います。ここが揃っていないと、「業務ごとに何機能あるか」が出せず、体制の検討に使えません。
④ 重複と抜けを突き合わせさせる
一覧ができたら、AIに自分の出力を検査させます。
- 名前は違うが実質同じ機能になっていないか
- 登録があるのに照会・修正・削除が抜けていないか
- 帳票を出す機能はあるのに、出力対象データを作る機能が無い、といった不整合はないか
登録はあるが一覧照会が抜けている——これは実際によくある抜けです。人が作った一覧でも頻繁に起きます。機械的な突き合わせは、AIが人より確実に見つけます。
現行システムの一覧があるなら、それとも突き合わせます。「現行にあって新機能一覧に無いもの」を出させると、移行漏れが一度に洗えます。
標準機能で足りるかの判定は、AIに任せない
ここが最も重要な線引きです。
「この機能は、パッケージやプラットフォームの標準設定で実現できるか。それとも開発が必要か」——この判定をAIに任せると、見積もりが根本から狂います。
理由は3つあります。
1. 製品のバージョンと契約内容に依存する 同じ機能でも、エディションやライセンス、有効化されているオプションによって、標準で足りるかどうかが変わります。AIは一般論で答えます。
2. 「できる」と「実用に耐える」は違う 標準機能で形は作れても、件数や同時実行数の条件で使い物にならない、というケースは頻繁にあります。この判断には実際の運用条件が要ります。
3. 間違えたときの損害が大きい 「標準で足りる」と誤判定した機能は、見積もりから開発工数が抜け落ちます。設計フェーズの終盤で発覚し、そのまま赤字要因になります。
したがって、実現方法の列は候補を挙げさせるところまでをAI、判定は人が持ちます。「標準で実現する場合の方法と、開発する場合の方法を両方挙げて」と依頼し、どちらを採るかは自分で決めます。
難易度と工数見積もりへの繋げ方
難易度の列は、機能一覧が見積もりに繋がる要です。
難易度は絶対的な基準ではなく、自社の基準に揃えるものです。「高・中・低」でも「1〜5」でも構いませんが、それぞれが何人日相当かを先に決めておきます。決めずに難易度だけ振っても、合計が出せません。
AIの使い方としては、基準を渡してから一括で振らせるのが有効です。
難易度の定義（低＝◯人日、中＝◯人日、高＝◯人日）を渡したうえで、 「この定義に照らして、各機能の難易度を振って。判断に迷ったものは印を付けて」
迷ったものに印を付けさせるのが要点です。全件を人がレビューするのは大変ですが、印の付いたものだけなら現実的に見られます。そして、迷いが出るのはたいてい要件が固まっていない機能です。難易度づけは、要件の曖昧さを炙り出す工程でもあります。
標準機能で足りるかの判定結果は、FIT&GAP分析一覧と揃えておくと、後の要件確定がスムーズになります。
うまくいかないときの原因
| 症状 | 原因 | 対処 |
|---|---|---|
| 一般的な業務システムの機能が並ぶ | ヒアリング記録を渡していない | 議事録やヒアリングシートの実物を渡す |
| 粒度がばらばらのまま | 基準を示していない | 「1機能＝1画面・1帳票・1バッチ」と明示する |
| 数百行になって管理できない | 細かく出しすぎ | 画面の項目レベルまで割らない。そこは設計書の仕事 |
| 難易度の合計が現実離れする | 難易度の定義を渡していない | 何人日相当かを先に決めて渡す |
| 移行漏れが後で出る | 現行の資産一覧と突き合わせていない | 手順④で必ず突き合わせる |
まとめ
- 機能一覧は目録ではなく、実現方法と難易度の2列があって初めて見積もりの土台になる
- 洗い出しは絞らず量を出す。 人が最初から整えようとすると、思いつかなかった機能が抜ける
- 粒度は1機能＝1画面・1帳票・1バッチを基準にすると破綻しにくい
- 標準機能で足りるかの判定は人が持つ。 誤判定は見積もりから工数が抜け落ち、そのまま赤字要因になる
- 難易度は定義を先に決めてから振らせ、迷ったものに印を付けさせる。印はそのまま要件の曖昧さを示す
洗い出しと整形をAIに任せられるようになると、空いた時間を実現方法の判定と、要件の詰めに回せます。機能一覧の精度を決めているのは、もともとそちらです。
進め方を実際に手を動かしながら身につけたい方は、AI開発トレーニングで個別にお伝えしています。
