第17回 仕様の構造化による大幅な手戻り削減 – フィーチャーモデリング入門

はじめに

「また仕様変更？ 影響範囲がわからない･･･」
「流用開発なのに、なぜ工数が２倍もかかるんだ？」
「テスト工程で発覚した仕様の矛盾･･･、また手戻りか･･･」

このような悩みを解決する手法として「フィーチャーモデリング」があります。

大量のバリエーションを持つ製品・サービスを経済的に展開するには、共通性（commonality）と可変性（variability）を明示化し、再利用可能な資産を設計する必要があります。そのソリューションとして、ドメイン分析で共通点と差異を体系的に抽出する手法である FODA（Feature-Oriented Domain Analysis）が 1990 年に発表されました。この手法が、ソフトウェア・プロダクトライン（SPL）とフィーチャーモデリングの基礎となり、類似製品群を低コスト・短納期・高品質で展開できる方法論となっています。

多くの組み込みソフト開発は文章主体の要求定義や要件分析の成果物となっており、曖昧さや重複、矛盾などが残りやすいために完全性・一貫性・明確性・検証可能性・追跡可能性が不十分となり、手戻りや不具合を発生させています。

SPL が前提でなくても、フィーチャーモデリングによって要求をフィーチャーとして構造化し、 相互の制約や前提条件を明示することで、設計やテスト、構成管理などといったソフトウェア開発全般に対する適切な入力を作成することができます。

実際に、私が関わった事務機器、車載機器、製造装置といったメーカーでは、フィーチャーモデリングにより以下の成果を実現しました。

変更手戻り：20-40% 減（要求仕様変更時の平均対応時間）
機能拡張工数：20-30% 減（派生製品開発工数）
導入期間：平均９ヶ月（パイロット３ヶ月＋製品開発６ヶ月）

組み込みソフトの規模は 10 年前と比べて 10 倍以上に拡大しています。しかし、多くの現場では依然として「Excel や Word で数百ページの仕様書」という 20 年前と同じ手法のままです。

また、本コラムは組み込みソフト開発を前提にした内容ですが、機械設計や電気設計にも適用可能です。今もあるクライアントでは、フィーチャーモデリングによって電気設計における流用開発の仕組み化を進めています。

1. 組み込みソフト開発の課題

自動車の SDV 化や IoT 機器の普及により、組み込みソフトウェアは製品価値の中核となっていますが、多くの現場では依然として、「仕様変更のたびに設計が崩れてしまう」「流用による機能拡張なのに計画工数をいつもオーバーする」「未だに機能の実装漏れや手戻りが減らない」といった問題で苦しんでいます。

これまでの 20年以上のコンサルティング経験から、以下の根本原因があると考えています。

・要求仕様が自然言語による文章主体の記述になっているため、完全性（抜け漏れ）・一貫性（矛盾）・検証可能性（確認条件不明）が不十分な文書となりやすい
・組み込みソフト開発は、派生プロダクト開発、長寿命保守、既存資産からの流用といった傾向がある中で、不十分な要求定義・要件分析が設計の抜け・漏れにつながり、結果、工数超過となる

たとえば、依然として「高速に動作する」（何秒以内？）、機能Ａと機能Ｂが同時に有効はあり得ないことを見落とす、１つの仕様変更の影響が 30 箇所以上（それもあちらこちら）に波及する、といったことが起きており、これらの問題を解決するのが要求仕様の構造化であり、そのための手法がフィーチャーモデリングです。

フィーチャーモデリングは、多くの派生プロダクト開発や長寿命保守となる組み込みソフト開発において生産性向上を実現するだけでなく、劇的な生産性向上の仕組みである SPL につながる基盤のしくみなのです。

2. フィーチャーモデリングとは

まず、フィーチャーモデリングで使われる用語を紹介しておきます。

フィーチャー：
問題領域におけるシステムの目立った特性。機能や品質上の要求の集合として表現される振る舞いの論理的単位で機能や非機能特性を含む。実装方法（どう作るか）ではなく、ユーザー視点の価値（何を提供するか）で定義する。

フィーチャーモデル：
フィーチャーの集まりを階層構造（ツリー構造）で表現したもの。フィーチャー相互における必須（Mandatory）/選択（Optional）/代替（Alternative/OR）や、全体・部分（Composed of）/汎化・特殊化（Generalization/Specialization）や、相互依存（Requires/Excludes）といった関係を示して、プロダクトの共通性（Commonality）と可変性（Variability）を表現する。系列の製品群の将来を考慮して分析したもの。

可変性（Variability）：
製品・バージョン・運用条件などに応じて差異が生じ得る性質（選択・切替・置換）。

可変点（Variation Point）：
製品ごとに選択が発生する（決定する）箇所。

変異体（Variant）：
可変点で取り得る選択肢（選択可能なフィーチャー）。

図２は、「通話」と「表示」はすべての製品モデルが装備している必須フィーチャーであること、「位置検出」や「メディア」フィーチャーは、製品モデルによってはない選択フィーチャーとなっていること、「メディア」フィーチャーには「カメラ」と「MP3」が選択可能だが製品モデルによってはある/なしや仕様が違う可変点となっていること、などを示しています。

＜注意＞
フィーチャーモデルは、仕様・要件詳細を記述した文書を置き換えるものではないことに注意してください。仕様・要件詳細の前提となる、フィーチャーの全体像とその相互関係を構造化する文書です。

3. フィーチャーモデル作成手順

フィーチャーモデルは、以下の４つのステップで作成します。

(1) フィーチャー抽出
従来製品とは違う新製品の場合は、一次要求を元に新たにゼロからフィーチャーをリストアップすることになります。

一方、既存製品の派生や流用となる新製品の場合は、参考・参照可能な仕様書、設計書、テスト仕様書などの既存の文書からフィーチャーを抽出するのが効果的です。このとき、共通あるいは重複しているコンポーネントと、そうでないコンポーネントを層別することにより共通と差分の見通しを立てることができます。さらに、運用手順や保守記録などから、稼働している現場からの課題や要求、運用における具体的な設定の違いなどを整理することができます。これらの情報は、この後の可変性分析のための有効なインプットとなります。

(2) 分類
抽出したフィーチャー候補を、以下の４カテゴリー（能力・サービス、動作環境、ドメイン技術、実装技術）に分類します。

(3) 構成分析
フィーチャー相互の関係を分析して構造化（ツリー構造に）します。以下の３ステップを繰り返し実施することで、できるだけ構造の完成度を高めます。

トップダウン：上位概念から長期視点で分解
ボトムアップ：抽出済みの要素を統合・関連付け
調整：抜け・冗長・粒度・相互関係を確認

(4) 可変性分析
構造化したフィーチャーにおいて、プロダクトのバリエーションを増やしたときに共通となるものと、バリエーションによって変わるものとを明らかにします。

1) 親子関係の特定
「全体・部分」は、あるフィーチャーがいくつかのフィーチャーから構成されている関係です。「汎化・特殊化」は、あるフィーチャーが特定の条件や前提にしたがって細分化・具体化したフィーチャーになっている関係です。

2) 必須/選択/代替/ORの特定
「全体・部分」か「汎化・特殊化」として特定した親子関係が、どんなバリエーションでも必要不可欠な関係であれば 必須（Mandatory）、特定のバリエーションで有効な関係であれば 選択（Optional）、Optional な子どものフィーチャー同士が同時に有効になってもいい関係の場合は OR、同時には有効にならない関係の場合は 代替（Alternative）となります。

3) 可変点/変異体の特定
具体的な親子関係を明らかにしたことで、Optional, Alternative, OR の関係が可変点となり、その親子関係の子どものフィーチャーが変異体となります。以下の視点の関係であれば可変点となります。

・市場、顧客、地域、設定（コンフィギュレーション）、ビルド方法などの違いによってプロダクトやその運用方法に違いを生じる
・あるフィーチャーを選択したときに他のフィーチャーに影響する（依存や排他となる関係のフィーチャーがある）
・要求が変わったときにユーザーに提供するフィーチャーが変わる（内部実装の変化は考慮外）

4) ツリー横断（Cross-tree）関係の特定
親子関係の階層化では関係づけできないフィーチャー間の相互依存と排他の関係を特定します。どうしても親子関係では表現できない場合だけに有効な親子関係を跨いだ関係です。

・要求（Requires）：あるフィーチャーAを選ぶと別のフィーチャーBが必須になる関係
・排他（Excludes）：同時に選べない相互排他関係

例えば、以下のようなフィーチャー同士の関係が考えられます。

物理制約：デバイス規格、容量などによる使用不可や採用必須となる関係
法規・標準：地域法規や業界標準で選択肢が限定される関係
運用モード：特定のモードで機能を無効や有効にしなければならない関係

5) 可変性のラベル化
要求分析となるフィーチャーモデリングの後工程となるシステム設計や実装や運用との関係を明確にするために「外部/内部」「時間的/空間的」の２軸で可変性にラベルを付与します。ラベルの定義は以下の通りです。

外部：顧客選択、市場、法規、運用などの環境や利害関係者の判断で選択される可変性
内部：実装技法、アルゴリズム、アーキテクチャなどの設計側の選択による可変性
時間的：運用モード、状態遷移、期間などで切り替わる可変性
空間的：地域、機種、製品オプションなどの製品個体ごとで固定される可変性

可変性ラベルによって、次のような対応と関連づけられます。

外部可変性：UI 設定やデプロイ構成での対応
内部可変性：ビルド設定や開発方針明確化による対応
時間的可変性：運用手順やモード遷移明確化による対応
空間的可変性：製品構成表の明確化による対応

6) 非機能要件の明確化
各フィーチャーの成立・前提条件となる、性能、信頼性、安全、保守性などの非機能要件を確認し、プロダクト全体として矛盾がないかを確認します。最終的に、フィーチャーの属性としてフィーチャーモデルとは別に文書化します。

4. フィーチャーモデルの例

最後に、あるプロダクトのメディア機能のフィーチャーモデルを紹介します。この図から以下の構造が読み取れます。

必須フィーチャー：すべての製品に必要な「楽曲再生」「再生制御」など
選択フィーチャー：製品モデルによっては装備しない「オンライン再生」「インターネット管理」
可変点：製品モデルによって提供する機能が変わる「楽曲属性DB」など
ORフィーチャー：「楽曲属性DB」の一部である「Apple Music Server」「楽曲メタ情報収集」など
要求関係：「ラスト再生」は「Media Source」を必要とするなど

5. まとめ

フィーチャーモデリングによって要求・要件を適切に構造化することにより、要求定義・分析の段階で共通と個別の機能仕様とその相互関係を明確化できることがわかっていただけたと思います。そして、フィーチャーモデルを要求定義・分析の後に続く設計工程のインプットとすることで、プロダクトラインナップやプロダクトグループといった製品の中期開発や既存製品の派生や拡張対応を、手戻りや無理・無駄のないものにすることができます。

開発の初段階である要求定義・分析工程を文章中心の成果物から、フィーチャーモデリングによって構造化することにより、ソフトウェア開発全体を効率的・効果的なものにすることができるのです。

ただし、各フィーチャーの詳細などは文章で記述する必要があり、文章による成果物を否定しているわけではありません。重要なのは、フィーチャーモデルにより要求仕様・分析の段階から構造化することで、内部実装などの詳細を列挙することを避け、プロダクトのラインナップやグループにおける差異を生む特性とその構造にフォーカスすることです。

組み込みソフト開発の競争力は、いかに効率的に高品質な製品群を展開できるかにかかっています。 フィーチャーモデリングは、その実現に向けた第一歩となる手法です。ぜひこの機会に、要求仕様の構造化による開発革新を目指してください。

セミナーのご案内

日本テクノセンターで、フィーチャーモデリングによる要求仕様の構造化のセミナーを実施します。フィーチャーモデル作成の詳しい説明に加えて、演習によりフィーチャーモデリングの実践力をつけることができます。

日本テクノセンター主催
組み込みソフトウェア開発における仕様の「構造化」と手戻り・工数削減への活かし方とそのポイント　～演習付～　＜オンラインセミナー＞
～ 要求分析とソフト開発における構造化の基礎、要求を構造化するフィーチャーモデリングによる工数削減の実践 ～

日時：2025年10月10日（金） 10:30-17:30（途中休憩含む）
形式：オンライン（演習あり）
対象：組み込みソフトの要求・設計の中堅技術者、リーダー・管理職の方を主対象）
https://www.j-techno.co.jp/seminar/seminar-75627/

執筆者プロフィール 日本ヒューレット・パッカード（HP）に入社し、R&D で半導体テスターなどの製品開発に従事した後、HP全社の開発・製造のデジタル化と仕組み改革にプロジェクト・リーダーとして参加。大幅な開発効率化を実現し、日本科学技術連盟石川賞を受賞。その経験をもとに開発マネジメントやプロジェクト管理、設計プロセスなどのコンサルティングを実施している。 コンサルティングを続ける中で、業務の仕組み改善は、個人の成長を伴うものであるべきとの思いが強くなり、コーチングや心理学を学び、組織と個人の両方に働きかけるコンサルティングを実施するために株式会社 RDPi を設立。組織と個人の両方に働きかけるコンサルティングを実施している。現在、日本ポジティブ心理学協会の理事を務めている。 ●株式会社 RDPi : http://www.rdpi.jp/ ●仕組みと意識を変える RDPi：https://www.facebook.com/rdpi.jp ●やる気の技術：https://www.facebook.com/motivation3.0 ●Email : ishibashi@rdpi.jp