新着記事はTwitterでご連絡いたします。下記URLから是非ご登録ください。
Twitter: https://mobile.twitter.com/can_know
デザインエンジニア概論第６回です。
前回はデザインエンジニアの起用メリットをブランコ開発を例に解説しました。今回はこれまでの説明に出てきた、「要求」「要件」そして「制約」について、改めて解説していきます。
デザインエンジニアとして領域横断するのであれば、これら３つの定義をプロジェクトで主体的にできることが望まれます。
解説にあたっては専門的な話も多い為、後半では前回のブランコ開発で具体例を示します。
目次
・要求分析と要件定義とは
・ブランコ開発の事例
要求分析と要件定義とは
デザインエンジニアリング概論第２回「ハードウェア開発とは」では、下記の開発プロセスの図を紹介しました。ここに「３．要求分析」と「４．要件定義」の表記があります。
この”要求分析”と”要件定義”について理解を深めていきます。
”要求”と”要件”は似ている言葉ですが、それらが意味するものは異なります。
”要求分析”とは、
開発の初期段階で、顧客がその製品に何を求めているのかを明確にしていく工程のことです。これは設計や実装を始める前に行う上流工程の一つとされています。
分析結果として得られる要求は「○○したい」「○○が欲しい」というように表現されます。
別の言い方をすると要求とは製品やサービスをユーザーが
”欲しいもの（体験）”です。また、要求はビジネス観点やユーザー観点など非技術的な表現であることが多く、設計や実装の立場では抽象的であることが多いです。
一方、”要件定義”とは、
要求分析結果をもとに開発制約を明確にしたうえで、開発対象の仕様や実装すべき機能・性能を定義することです。要求分析同様、設計や実装を始める前に行う上流工程の一つです。
ここで定義される要件は、「○○ができる」「○○が必要」というように表現されます。
別の言い方をすると要件とは製品やサービスの実現に
”必要なもの（機能）”です。また、記載される単位は、エンジニアやデザイナーが設計や実装を考える際に検討しやすい粒度が利用されます。
つまり、要求を実現する方法を技術的観点で定義されたものが要件ともいえます。
ちなみに、一般的な開発プロセスにおいては、請負い側が依頼者と合意するのは要求ではなく要件であると理解しておくことが重要です。抽象的である要求を最終成果物である製品が実現できたかどうかを評価することは非常に困難なため、評価可能な要件が合意条件とされるべきだからです。
プロジェクトで依頼者と請負い側が揉めるケースとして、「要件定義があいまいだった」というのはよく聞く話です。
ブランコ開発の事例
前回例として取り上げたブランコ開発を例に、「要求分析」と「要件定義」を具体的に考えてみます。
下記にブランコ開発の「要求分析」と「要件定義」の成果物を”要求”、”要件”、そして”制約”で分類し、具体例を記載しました。
以下分類ごとに解説します。
要求
スタイリッシュ
安全
低価格
要求分析で得られる”要求”は、前回もでてきた「スタイリッシュ」「安全」「低価格」の３つが該当します。しかし、これら要求が明らかになったところで、作り手は「スタイリッシュって具体的にどういうこと？」「どうなっていれば安全なの？」「いくらだったら低価格なの？」となってしまいます。
要件
構成要素：必要最低限の要素で構成する
耐久性：体重70kgの人が毎日30分使っても5年間壊れない
提供価格：1万円以下
要求を元に要件定義を行った結果、３つの項目を要件として定義しました。
まず、スタイリッシュという要求を実現するに当たっては、無駄な要素がなく「必要最低限の要素で製品を構成する」ことが必要であると定義しました。ただし、この要件が3つの中では唯一抽象的です。したがって、実務の場では当該要件についての評価者を具体的に立てる必要があります。
安全という要求に対しては、具体的なユーザーと耐久条件を明らかにすることで「体重70kgの人が毎日30分使っても5年間壊れない」と必要な耐久性を定義しました。製品評価の際には70kg荷重条件で912.5時間（30分×365日×5年）に相当する試験のクリアを目指します。
低価格という要求に対しては、製品全体を「1万円以下」提供する、という提供価格を定義しました。他の要件を満足したうえで、提供価格が1万円におさまるような製品の開発を目指します。
他の要件を満たそうとしたときに、当該価格におさまらない、というような無理な価格設定をしないことが重要です。
制約
庭に設置する
木を使用する
法規制を遵守する
要件定義では要件の他にも３つの制約も定義しました。
制約については前の項で触れていませんでしたが、制約とは、
開発に影響を及ぼす制限要素であり、製品開発において必ず守るべきもののことです。
このケースにおいては、「設置場所が庭」であり、土台となる「木を支給品として使用」しなくてはいけないことが制約です。また、これがどこの国の話かは分かりませんが、「法規制」に反する素材の使用や設計ができないことも制約の一つです。
制約は基本的には覆せないものとなりますので、まずはじめに依頼者と合意を握るのが実務的なポイントです。
このように、”要求”・”要件”・”制約”を明確にしていくことで初めて何をつくるべきかが明らかになっていきます。
以上で、ブランコ開発の事例を題材にした「要求分析」と「要件定義」の具体例の説明を終わります。要件定義の後は、要件定義のアウトプットを元に設計の工程に移っていくわけですが、これについてはまた次回以降解説していきます。
関連記事
＜株式会社３４６について＞
３４６（サンヨンロク）はデザイン経営を中核にしたものづくりでテクノロジーの民主化を目指す開発・製造総合支援企業です。インダストリアルデザイナー、ハードウェアエンジニア、ビジネスコンサルタントなど様々な専門家で構成されています。
＜ものづくりが好きな仲間を探しています＞
弊社３４６ではデザインエンジニアを募集しています。興味関心がある方はCAREERSよりお問い合わせください。
＜連載メディアを募集しています＞
弊社３４６では、本記事の連載または出版にご協力いただける企業を募集しています。興味関心がある方はCONTACTよりお問い合わせください。
参考文献
１．だまし絵を描かないための 要件定義のセオリー, 赤俊哉著, リックテレコム
