ハードウェア開発における要求工学

率直に言って、要求事項に胸を躍らせる人はほとんどいません。とはいえ、どのハードウェアチームも、要求が曖昧であることの代償を経験しています。つまり、後工程で発覚する手戻りや、ステークホルダーが実際に求めていた内容を満たさない試作・製品化です。 

要求工学（RE）とは、最終製品が正しい課題を解決できるように、要求を定義・文書化・管理するための構造化されたプロセスに従う分野です。これを適切に適用すれば、ミスを早期に発見し、チームの足並みをそろえ、出荷されるものが実際に合意された内容どおりであるという確信を関係者全員に与えられます。

しかし、この用語はしばしば混同されます。というのも、ソフトウェア工学と、ハードウェア製品のシステムズエンジニアリングの両方にルーツがあるためです。 

この記事では、要求工学の明確な定義と、ハードウェア製品開発におけるその役割を説明します。理論的な概要と、ハードウェアプロジェクトでどのように適用されるかについての実践的なフレームワークの両方を取り上げ、実際の事例、よくある落とし穴の一覧、そしてそれらを回避する方法も紹介します。

主なポイント

• 要求工学は、ハードウェアチームが設計意図を明確な要求へ落とし込み、チーム全体の認識を一致させるのに役立ちます。
• 要求は、初期の計画・設計から、試験、変更対応、最終文書化に至るまで、プロジェクト全体を導きます。
• 優れた要求プロセスは、開発チームが問題を早期に発見し、高コストな再設計を回避し、最終製品が合意内容を満たしていることを確実にする助けになります。

要求工学とは何か？

要求工学とは、ハードウェア製品開発において、要求を定義・文書化・管理するための体系的かつ規律あるアプローチです。

これによりチームは、解決すべき課題を理解し、ステークホルダーのニーズを明確化・分析し、対立やトレードオフを解消し、製品が達成すべき内容を文書化し、製品の進化に合わせてその理解を最新の状態に保つことができます。

実務上、要求は、何を作るのか、なぜ作るのか、そして最終製品が設計意図を満たしているかをチームがどのように判断するのかについて、ステークホルダーとエンジニアリングチームの間に共通認識を生み出します。

要求工学の利点

REが適切に実施されると、誤解や高コストなミスを防ぎ、チームの足並みをそろえ、最終製品が要求を満たすようにする助けになります。

REの主な利点には、次のようなものがあります。

• 共通ビジョン： ステークホルダー、マネージャー、エンジニアリングチームが、何を構築しているのかについて同じ理解を持てるようにします。
• 明確なスコープ： プロジェクトに含まれるものと含まれないものを明確にし、スコープクリープと呼ばれる制御不能な追加を防ぐ助けになります。
• 高コストなミスの削減： 要求上の問題を早い段階で発見し、高額な設計手戻り、新たな試作、繰り返しの試験へ発展する前に対処できます。
• 計画とスケジューリングの改善： 何を構築する必要があるかをより明確に把握できるため、作業見積もりや現実的なスケジュール作成がしやすくなります。
• 製品品質の向上： 最終製品が合意された内容どおりに機能し、求められる品質基準を満たしていることを確実にする助けになります。

要求工学という分野の発展

要求工学は、システムズエンジニアリングとソフトウェア工学の両方にルーツを持っています。これら2つの系譜は異なる工学的文脈で発展してきたため、情報源によっては、この用語の対象範囲が今でもやや異なることがあります。

ソフトウェア工学の文脈では、主な焦点はソフトウェア開発の要求、すなわちソフトウェアが何をすべきか、どのように振る舞うべきか、どのような品質特性を満たすべきかにあります。ソフトウェアエンジニアは、機能要求と非機能要求を、ユーザーストーリー、ユースケース、受け入れ基準として文書化されたものとして捉えます。一方、システムズエンジニアリングの文脈では、対象範囲はより広くなります。要求は、ハードウェア、ソフトウェア、人、プロセス、インターフェース、動作条件、その他のシステム特性を含むシステム全体を指します。システムエンジニアは、システムレベル要求をハードウェア、機械、電気、ファームウェア、安全要因へと割り当て、正式な要求記述や要求トレーサビリティマトリクスとして記録します。

ハードウェア開発では、REはこれら両方の視点を統合します。部品表（BOM）コスト、熱制約、製造上の制約に対応するために必要な、システムズエンジニアリングの厳密さと学際的な対象範囲を取り入れるとともに、要求をテスト可能にし、開発全体を通じて結び付けておくために、ソフトウェア工学で用いられるライフサイクルトレーサビリティも組み合わせます。

要求工学に関連する分野

要求工学は、他の製品開発分野、特にシステムズエンジニアリングやプロダクトマネジメントと密接に関係しています。

システムズエンジニアリング

システムズエンジニアリングでは、製品をひとつの完全なシステムとして捉えます。システムエンジニアは、ハードウェア、ソフトウェア、機械部品、試験といった異なる要素が適切に連携し、互いに矛盾しないことを確認します。

これはREと密接に結び付いています。なぜなら、要求が、製品が達成すべきことについて、これらすべてのチームに共通の参照点を与えるからです。

たとえ話が好きなら、家を建てる場面を想像してみてください。基礎、電気、配管、暖房などは異なる専門家が担当しますが、それでもそれらすべてが実際にひとつの完成した構造としてうまく収まるように確認する人が必要です。システムズエンジニアリングは、製品開発においてまさにその役割を果たします。

プロダクトマネジメント

プロダクトマネジメント は、何を、なぜ作るのかを決める助けとなります。プロダクトマネージャーは、顧客と話し、市場を調査し、競合を分析し、ビジネス部門と連携しながら、どの問題を解決する価値があるのか、どの機能が最も重要なのかを判断します。

これもREと関係しています。なぜなら、こうした高レベルの顧客ニーズやビジネス目標が、製品要求を定義する出発点になるからです。

要求工学プロセスのフェーズ

REプロセスは、適用分野、関与する人々、組織によってさまざまな形で構成されます。あるプロジェクトでは、活動の大半が順番に進みますが、別のプロジェクトでは、チームの学びに応じて繰り返し見直されることもあります。

 Requirements Engineering journalに掲載された記事で説明されているように、一般的な教科書的アプローチでは、REプロセスを4つの中核活動（フェーズ）に分けます。

• 要求の引き出し（elicitation）： ステークホルダーやその他の情報源から要求を収集し、システムが何をしなければならないのか、またどのような条件下で動作しなければならないのかを理解します。
• 要求の分析と仕様化： 収集した内容をレビューし、不明確または矛盾する情報を解消し、エンジニアリングチームが利用できる明確な要求へと落とし込みます。
• 要求の妥当性確認： 要求が正しく、完全であり、システムが達成すべき内容を適切に記述していることを確認します。
• 要求管理： 要求とその変更を時間の経過に沿って追跡し、なぜ変更されたのか、また他の要求、設計作業、試験にどのような影響が及ぶ可能性があるのかも含めて管理します。

プロセスに関わる人々

REフレームワークには、製品が何をすべきかを定義するために協力する、いくつかの重要な役割が関与します。

• 要求オーナー： 曖昧なステークホルダーのニーズを受け取り、適切な質問を行い、それをエンジニアリングチームが実際に製品開発で使える一連の要求へと変換するエンジニアです。多くの場合、システムエンジニア、リードエンジニア、または同様の責任を持つ人が担います。
• 技術系プロダクトリーダーシップ： ステークホルダーやビジネス側とコミュニケーションを取り、そのニーズを理解したうえで、その要望を明確な製品目標に変換する人たちです。これには、プロダクトマネージャー、プログラムマネージャー、または類似の役割が含まれます。
• 実装エンジニア： 定義された要求を使って製品を設計・構築するエンジニアです。これには、電子、機械、ソフトウェア、ファームウェアのエンジニアが含まれる場合があります。
• 検証オーナー： 要求をどのように試験するかを決定し、必要なレビューや試験が確実に完了するようにする担当者です。これには、検証エンジニア、テストエンジニア、QAエンジニアが含まれる場合があります。

ハードウェア開発のための実践的な要求工学フレームワーク

上記の4つの活動がREプロセスの中核を定義する一方で、ハードウェアチームには、それらをプロジェクト全体を通じて適用するための実践的な方法が必要です。

以下は、ハードウェア開発における要求工学フレームワークの実践的な見方であり、各段階で要求がどのように位置付けられるかを示しています。

プロジェクトキックオフ：意図を捉える

プロジェクトの開始時には、技術リードは通常、顧客要求、提案依頼書（RFP）、ビジネス目標、あるいはコスト・サイズ・スケジュールの制約といった、曖昧な入力を受け取ります。たとえば、顧客が特定のユースケースに対応する、より小型のデバイスを求めることがあります。

要求オーナーとともに、技術リードは何が必要かを明確にし、それらの入力を、製品が達成すべきことを記述する高レベル要求へと変換します。

要求工学：要求を定義する

プロジェクトキックオフ段階で得られた高レベル要求は、詳細設計にはまだ抽象的すぎます。この段階では、要求オーナーがシステム全体を定義し、それを要素やサブシステムに分解し、それらの高レベル要求を各要素向けのより具体的な要求へと落とし込みます。

また、要求同士が矛盾していないか、重要な抜け漏れがないか、それぞれが明確でテスト可能かどうかも確認します。その結果、エンジニアリングチームが製品設計の出発点として使える、合意済みの要求セットが得られます。

実装：設計を進める

実装エンジニアは、合意された要求を使って製品の担当部分を設計・構築します。たとえば、回路図の作成、3D部品のモデリング、ソフトウェアやファームウェアの記述などです。設計が進むにつれて、各要求はそれを満たす設計要素に関連付けられます。こうしたリンクがプロジェクトのトレーサビリティを形成し、要求オーナーが要求の実装状況を把握する助けになります。

検証と妥当性確認：試験と確認

要求は、レビューや試験で何を確認すべきかも定義します。検証エンジニアは、各要求をどのように確認するかを定義し、実装エンジニアと協力して必要なレビュー、測定、試験を実施し、その結果を記録します。これにより、製品に求められていた達成内容と、それを実際に達成したかどうかを示す証拠が結び付けられます。

変更管理：改訂と反復

要求や製品設計は、開発中にしばしば変更されます。ある要求が達成不可能であると判明したり、部品が市場で入手できなくなったり、新たな制約が現れたりすることがあります。そうした場合、要求オーナーは、何が変わったのか、なぜ変わったのか、そしてどの要求、設計部分、試験に影響が及ぶのかを追跡します。

文書化と引き継ぎ：プロジェクトを引き渡す

プロジェクトの最後には、Requirements Owner が Verification Engineer およびチームの他のメンバーと連携して、要件、設計レビュー、検証活動のクローズアウトを行います。最終ドキュメントには、何が要求され、何が構築され、どのように検証されたかを追跡可能な形で記録しておく必要があります。顧客、製造業者、監査担当者、または今後その製品に継続して関わるチームは、後になってこの情報を必要とします。

要件エンジニアリングの例

医療機器における要件エンジニアリング

要件エンジニアリングは、医療およびケアテクノロジー製品全般で活用されています。要件は開発期間を通じて製品とともに維持されます。チームはステークホルダーのニーズを体系化されたシステム要件へと落とし込み、仕様変更があってもそれらのつながりを保ち、検証計画の策定や試験結果の文書化に活用します。

医療機器では、さらに規制対応という側面が加わります。チームはトレーサビリティ、検証、文書化、および各種書類作成により多くの労力をかけます。これは、米国の FDA 21 CFR Part 820や、EU およびその他の市場における ISO 13485:2016といった枠組みに基づく規制承認を支えるためです。

HitIQ のマウスガードは、安全性の要求があらゆる技術仕様を左右する医療用ウェアラブルの一例です。詳しくは、完全版のCustomer Success storyをご覧ください。

民生用および産業用エレクトロニクスにおける要件エンジニアリング

要件エンジニアリングの基本プロセスは、民生用電子機器と産業用電子機器で共通していますが、製品は異なる条件下で開発されます。スマートホーム機器やウェアラブルのような民生製品は大量に販売され、短期間で市場投入されます。一方、PLC（プログラマブルロジックコントローラ）やモータードライブのような産業製品は、過酷な環境下で何年にもわたって稼働しなければなりません。

どちらの場合でも、チームは製品が何をしなければならないかを書き出し、各要件を設計に関連付け、変更が生じた際には要件を更新し、それらに基づいて試験を行います。

異なるのは、チームが追加で注力するポイントです。民生用エレクトロニクスでは、要件の誤解が基板の再設計につながりかねないため、急速な変化への追随に注力します。産業用エレクトロニクスでは、出荷前に長寿命や過酷環境への適合を試験する必要があるため、検証に重点が置かれます。

安全規制に準拠した信頼性の高いハードウェアを構築するには、要件と設計変更を結び付けて維持することが重要です。MakeSafe Tools がこれをどのように実現しているかは、full success storyでご覧いただけます。

要件エンジニアリングでよくある落とし穴を避ける方法

要件エンジニアリングには、いくつかの典型的な課題があります。どのような問題が起こり得るかを知っておくことで、ハードウェア製品開発の早い段階で問題を見つけ、回避しやすくなります。

ここでは、注意すべきよくある落とし穴と、その回避方法を紹介します。

要件エンジニアリングのためのソフトウェアツール

少数の要件を管理するのは比較的簡単です。しかしプロジェクトが大きくなるにつれて、すべてを整理し最新の状態に保つには、より多くの労力が必要になります。その段階になると、要件をどのように管理するかがより重要になってきます。

実際には、チームは通常次のいずれかのアプローチを採用します。

• スプレッドシートとドキュメント： 親しみやすく、すぐに使い始められるため、小規模なプロジェクトには有用です。ただし、プロジェクトが大きくなると、維持のための手作業が増えます。
• 専用の要件管理（RM）ツール： プロジェクトが複雑になるにつれて、より高い構造化と管理性を提供します。その一方で、ツールによっては小規模なチームには不要なほど多くのプロセスを伴うこともあります。

目標は、必要以上に要件管理を複雑にすることなく、そのプロジェクトに見合った十分な構造を取り入れることです。

スプレッドシートでは対応しきれなくなったものの、大規模なエンタープライズ RM ワークフローまでは必要としない小規模ハードウェアチームにとって、 Requirements Portalは検討する価値のある実用的な選択肢です。これは、従来のエンタープライズシステムのような大きな負担なしに、小規模チームがより体系的に要件を管理できるよう設計されています。

結論と次のステップ

ここまでで、要件エンジニアリングの主要な概念と、それらが実務でどのように適用されるかを明確に理解できたはずです。

要件エンジニアリングについてさらに学びたい場合は、次のリソースがよい出発点になります。

• ISO/IEC/IEEE 29148:2018は、要件エンジニアリングのプロセスと実践に関する国際標準を提供しています。要件をどのように記述し、構造化し、文書化し、管理すべきかについて、追加の指針を得ることができます。
• NASA Systems Engineering Handbookは、システム開発において要件がどのように作成され、記述され、確認され、活用されるかについて、実践的なガイダンスを提供します。
• Guide to the Systems Engineering Body of Knowledge (SEBoK)は、要件がより大きなシステムズエンジニアリングのプロセスにどう位置付けられるか、またシステムのさまざまな部分がどのように連携して開発されるかを説明しています。
• Requirements Engineering journalは、要件エンジニアリングに関する研究、業界事例、さまざまなアプローチをより深く扱っています。

理論から実践へ進む準備ができているなら、Requirements Portalを試して、構造化された要件を実際のハードウェアプロジェクトで今日から活用してみてください。無料で、セットアップも不要です。

よくある質問

なぜ要件エンジニアリングは重要なのですか？

要件エンジニアリングが重要なのは、設計や開発が進みすぎる前にステークホルダーのニーズを明確に理解することで、チームが正しい製品を構築できるよう支援するからです。

Requirements Engineer の役割は何ですか？

Requirements Engineer は、ステークホルダーのニーズをエンジニアリングチームが活用できる明確な要件に変換し、プロジェクトの変化に応じてそれらの要件を整理・維持します。クライアントと開発チームの橋渡し役を担います。 

Requirements Engineering と Requirements Management の違いは何ですか？

Requirements Engineering は、そもそもシステムが何を行う必要があるのかを明らかにし、理解し、文書化するまでを含むプロセス全体を指します。Requirements Management はその中の特定の部分であり、記述された要件を整理し、変更があれば追跡する役割を担います。