なぜ「何を作るか」より「何を作らないか」が重要なのか
システム開発プロジェクトで失敗する最大の原因は、機能を作りすぎてしまうことです。
「全部入りで作ろう」
「あったら便利だから」
「他社にもあるから」
こうして膨らんだ要件のうち、実際に使われる機能は2割程度に過ぎないという調査もあります（Standish Group: CHAOS Reportなど）。残りの8割は、開発費・運用費・保守費を生み続けながら、誰にも使われずに眠っています。
これを防ぐには、要件を可視化し、客観的に評価し、優先順位をつけて切り捨てるプロセスが欠かせません。本記事では、書籍『システムを作らせる技術』（白川克著、ISBN 978-4-532-32399-8）で紹介されているFM（ファンクショナリティ・マトリクス）法を、実践的な使い方と合わせて解説します。
FM法とは
FM法は、要件を3つの軸で評価し、機能の採否を判断するフレームワークです。
オリジナルの3軸:
- ビジネス価値（H/M/L）
- 組織受入態勢（H/M/L、Beekleのツールでは「現場で使えるか」と表記）
- 技術的容易性（H/M/L、Beekleのツールでは「技術コスト」として逆向きに表記）
各軸を High / Medium / Low で評価し、組み合わせで機能の採否を判断します。
評価軸の意味
軸1: ビジネス価値（★1〜3）
その機能を作ると、どれだけビジネスに貢献するか。
- ★3（H）: 売上・コスト削減・顧客満足度に直結する。なくては困る
- ★2（M）: あった方が良いが、なくても致命傷ではない
- ★1（L）: あれば嬉しい程度。経営インパクトは小さい
具体的な質問:
- この機能で売上は上がるか？
- 業務時間は減るか？
- 失注を防げるか？
- お客様に選ばれる差別化要因になるか？
軸2: 現場で使えるか（★1〜3）
その機能を、現場が実際に使いこなせるか。
- ★3（H）: 現場のスキル・運用体制・モチベーションが揃っており、確実に使われる
- ★2（M）: 一部の人や部署では使われるが、全社浸透には研修や運用整備が必要
- ★1（L）: スキル不足、運用負荷、モチベーション欠如により使われない可能性が高い
具体的な質問:
- 現場のITリテラシーで使えるか？
- 入力する人を確保できるか？
- マスタメンテナンスは誰がやるか？
- 業務プロセスを変えられるか？
ここがFM法の真骨頂で、価値があっても使われないシステムを排除する仕組みが組み込まれています。
軸3: 技術コスト（低/中/高）
その機能を作るのに、どれだけの開発コストがかかるか。書籍では「技術的容易性」の高/中/低として表現されますが、発注者にとっては「コストがどれだけかかるか」という観点の方が直感的です。
Beekleのツールでは「技術コスト」として、書籍の軸を逆向きに表記しています。
- 技術コスト 低（書籍の H 相当 = 容易）: 既存技術で短期間に実装できる
- 技術コスト 中（書籍の M 相当）: ある程度の調査・実装工数が必要
- 技術コスト 高（書籍の L 相当 = 困難）: 新技術導入、大規模変更、高い不確実性
具体的な質問:
- 既存システムから流用できるか？
- 必要な技術スタックは社内やパートナーに揃っているか？
- 開発期間が3ヶ月以内に収まるか？
- 性能・セキュリティ要件で詰まらないか？
採否判定ロジック
FM法では、3軸の組み合わせで以下のように判定します。
ルール1: 3軸ともH（最高評価）→ 作る
- ビジネス価値 ★3
- 現場で使える ★3
- 技術コスト 低
- → 間違いなく作るべき機能
ルール2: Hが2つ以上 → 作る
- 例: ビジネス価値 ★3、現場で使える ★3、技術コスト 中
- 例: ビジネス価値 ★3、現場で使える ★2、技術コスト 低
- → コア機能。優先実装
ルール3: どれか1軸でもL → 作らない
- 例: ビジネス価値 ★1（だれも喜ばない）→ 作らない
- 例: 現場で使える ★1（使う人がいない）→ 作らない
- 例: 技術コスト 高（無謀）→ 作らない
- → 他の軸がどんなに良くても、Lが1つあれば外す
これが書籍の核心メッセージです。
「使われない機能」「無謀な機能」は、価値がいくら高くても切る。
ルール4: それ以外（M中心）→ 後回し
- 例: ビジネス価値 ★2、現場で使える ★2、技術コスト 中
- → スプリント2以降の検討対象
このロジックを通すことで、「全部欲しい」病から脱却できます。
MoSCoW法との違い
スコープ優先順位付けの手法として、MoSCoW（Must/Should/Could/Won't）も有名です。両者の違いは以下の通り。
観点 | MoSCoW | FM法 |
|---|---|---|
評価軸 | 1軸（重要度のみ） | 3軸（価値・受入・技術） |
「使われない」リスク | 検出しにくい | 「現場で使えるか」軸で検出 |
「無謀な実装」リスク | 検出しにくい | 「技術コスト」軸で検出 |
議論の客観性 | 主観に頼りがち | 軸ごとに議論しやすい |
学習コスト | 低 | 中 |
MoSCoWは早く決められる反面、主観バイアスの影響を受けやすい。FM法は学習コストがやや高いものの、判断の客観性を確保しやすい手法です。
詳細比較は 要件の優先順位付け: MoSCoW vs FM法 比較 で解説します（準備中）。
実際にやってみる: 5ステップ
Step 1: 要件をリストアップする
まず、ステークホルダーから出た「やりたいこと」をすべてリストにします。この段階では絞り込みません。
ヒント:
- ユーザーストーリー形式で書くと評価しやすい（Story Builder で書ける）
- 5〜30個程度が扱いやすい数。50個を超えたら一段階上のレベルでまとめる
Step 2: 3軸で評価する
各要件について、3軸を ★1〜3（または 低/中/高）で評価します。
評価のコツ:
- 関係者複数人で評価し、ズレがあれば議論する
- 評価が分かれたら、その理由が見える化のチャンス
- 「分からない」「決められない」と感じる時は、情報不足のサインなので追加調査を行う
Step 3: 判定ロジックを適用する
「作る／後回し／作らない」のラベルを付与します。BeekleのScope Managerでは、3軸を入れると自動で判定が表示されます。
Step 4: ステークホルダーに合意を取る
「作らない」と判定された機能について、提案者に納得してもらう必要があります。FM法のメリットは、判定根拠が3軸の評価結果として明示されることです。「ビジネス価値は高いが、現場で使う体制がないので作らない」と具体的に説明できます。
Step 5: 実装計画を立てる
「作る」と判定された機能を、依存関係と実装難易度で並べてスプリント計画に落とします。
よくある失敗パターン
失敗1: 評価が甘い
すべての要件を ★3 / ★3 / 低 と評価してしまう。これでは判定の意味がありません。
対策: 強制的にL/Mを混ぜる。「全部Hなら、本当に最も価値の高い1つを選んでください」と問う。
失敗2: 「現場で使えるか」を低めに見積もりすぎる
過度に保守的になり、ほとんどが「作らない」判定になってしまう。
対策: 使えない理由を具体的に書く。「漠然と不安」だけでは★1にしない。
失敗3: 経営層と現場で評価が分かれる
経営層は「ビジネス価値★3」、現場は「使えない★1」となるパターン。これは対話のチャンスです。FM法の価値は、評価の差を可視化することにあります。
対策: 「なぜ現場が使えないと感じるか」を深掘り。研修やプロセス変更で解決できるなら ★2 に上げられる。
失敗4: 1回評価して終わり
要件は変わるし、技術も進化します。3ヶ月ごとに再評価することで、過去の判断を更新できます。
対策: 再評価サイクルを最初から計画に組み込む。
Beekleの無料ツール「Scope Manager」
Beekleでは、FM法を実装した無料Webツール「Scope Manager」を公開しています。
機能:
- 3軸（ビジネス価値・現場で使えるか・技術コスト）を ★1〜3 / 低・中・高 で入力
- 自動で「作る／後回し／作らない」を判定
- Markdown形式で要件を入出力
- Story Builder で作ったユーザーストーリーをそのまま取り込み可能
- ローカル保存（ブラウザ内のみで動作、社外秘要件もOK）
まとめ
「何を作るか」を決めるより、「何を作らないか」を決める方が難しい。FM法はそのための強力な道具です。
3軸で評価することで:
- 主観バイアスを避けられる
- 「使われない機能」を排除できる
- 「無謀な実装」を排除できる
- ステークホルダーへの説明がしやすい
Scope Manager で実際に評価してみてください。要件定義のクオリティが目に見えて変わります。
関連記事 / 関連ツール
- Scope Manager（無料ツール）
- Story Builder（無料ツール）
- ユーザーストーリーの書き方完全ガイド
- EARS（要件記述構文）入門
- 使われないシステムを作らない方法
- プロジェクトマネジメント完全ガイド
ご相談
要件整理の進め方でお困りなら、無料相談で具体的なアドバイスをお出しします。
参考文献
- 白川克『システムを作らせる技術: エンジニアではないあなたへ』日本経済新聞出版（ISBN: 978-4-532-32399-8）