システム設計5 プロジェクト管理の仕組み (その37)

更新日

投稿日

 それでは、機能以外にも注目してシステム要件をリストアップするにはどうしたらよいでしょうか、 そのための手法として FURPS+ を紹介したいと思います。
 
R&D
図71. FURPS+
 
 図71 に示しているように、FURPS+ とは Functionality(機能性),Usability(使用性),Reliability(信頼性),Perfomance(性能),Supportability(保守性)の頭文字を並べて、さらにその他の属性という意味で + を付け加えたものです。「ファープス プラス」と発音します。FURPS+ はシステム要件を考えるときに、機能 (F) 以外に考えるべき品質特性を忘れないようにガイドするものです。「ファープス プラス」と覚えておけば常に意識することが可能になるはずです。この自販機の場合 FURPS+ はどのようになるでしょうか。機能 (F) については前回、リストアップしたので、残りの URPS+ について考えてみましょう。
 
R&D
図72. 例題のFURPS+
 
 FURPS+ のリストアップができたらば、その一つひとつを機能やサービスと同じように要件としてブレークダウンし整理します。このとき、性能 (P) は機能 (F) としてブレークダウンできたり、信頼性 (R) は性能 (P) としてブレークダウンできたりすることに注意してください。たとえば、図72 の 信頼性 (R) の一つである「停電のときには投入したお金を返却口に返しその旨を表示する(伝える)」について考えると、次のように機能(F)にブレークダウンすることができます。
 
R&D
図73. FURPS+のブレークダウン
 
 これらの機能はすべて停電時のシステムの機能ですから、「停電時の商品とお金の保証」という新しいシステム要件として追加しておきます。同様に、信頼性(R)の他の項目についても、また、使用性(U)や性能(P)などの他の品質特性についても同様に一つひとつ検討してシステム要件に加えます。この作業はシステム設計の一部ですが、開発現場によっては要件定義とか要件設計というように呼んでいることもあります。どのように呼んでいるにせよ、大切なのは図73 に示すような考え方で、機能以外の品質特性についても漏れなくリストアップすることです。そして、FURPS+ を使うと機能以外の品質特性について考慮することができ、漏れのないシステム要件を作ることが容易になるわけです。
 
 くどいようですがもう一つ注意があります。開発現場の中には非機能要件としてシステム要件を整理しているところもありますが、その場合でも性能にしか注目していないことが多いということです。しかし、FURPS+ で示したように、システム要件を考える際には品質特性全般を考慮することが重要です。システム設計の最初のインプットであるシステム要件が正しくなければ、その後のシステム設計作業を正しく行うことはできないのです。そのためには、FURPS+ のような手法を使い、十分な時間をかけてシステム要件を整理することが大切です。
 
 さて、システム設計の一つであるシステムエンジニアリングのインプットであるシステム要件が決まりました。次にすることは、システムエンジニアリングを行って各サブシステムの要件を明確にすることです。具体的には、一つひとつの要件に対してシステムの振る舞いを考えることと、それと並行して、システムとしてどのようなサブシステム(ブロック)が必要なのか考...
 それでは、機能以外にも注目してシステム要件をリストアップするにはどうしたらよいでしょうか、 そのための手法として FURPS+ を紹介したいと思います。
 
R&D
図71. FURPS+
 
 図71 に示しているように、FURPS+ とは Functionality(機能性),Usability(使用性),Reliability(信頼性),Perfomance(性能),Supportability(保守性)の頭文字を並べて、さらにその他の属性という意味で + を付け加えたものです。「ファープス プラス」と発音します。FURPS+ はシステム要件を考えるときに、機能 (F) 以外に考えるべき品質特性を忘れないようにガイドするものです。「ファープス プラス」と覚えておけば常に意識することが可能になるはずです。この自販機の場合 FURPS+ はどのようになるでしょうか。機能 (F) については前回、リストアップしたので、残りの URPS+ について考えてみましょう。
 
R&D
図72. 例題のFURPS+
 
 FURPS+ のリストアップができたらば、その一つひとつを機能やサービスと同じように要件としてブレークダウンし整理します。このとき、性能 (P) は機能 (F) としてブレークダウンできたり、信頼性 (R) は性能 (P) としてブレークダウンできたりすることに注意してください。たとえば、図72 の 信頼性 (R) の一つである「停電のときには投入したお金を返却口に返しその旨を表示する(伝える)」について考えると、次のように機能(F)にブレークダウンすることができます。
 
R&D
図73. FURPS+のブレークダウン
 
 これらの機能はすべて停電時のシステムの機能ですから、「停電時の商品とお金の保証」という新しいシステム要件として追加しておきます。同様に、信頼性(R)の他の項目についても、また、使用性(U)や性能(P)などの他の品質特性についても同様に一つひとつ検討してシステム要件に加えます。この作業はシステム設計の一部ですが、開発現場によっては要件定義とか要件設計というように呼んでいることもあります。どのように呼んでいるにせよ、大切なのは図73 に示すような考え方で、機能以外の品質特性についても漏れなくリストアップすることです。そして、FURPS+ を使うと機能以外の品質特性について考慮することができ、漏れのないシステム要件を作ることが容易になるわけです。
 
 くどいようですがもう一つ注意があります。開発現場の中には非機能要件としてシステム要件を整理しているところもありますが、その場合でも性能にしか注目していないことが多いということです。しかし、FURPS+ で示したように、システム要件を考える際には品質特性全般を考慮することが重要です。システム設計の最初のインプットであるシステム要件が正しくなければ、その後のシステム設計作業を正しく行うことはできないのです。そのためには、FURPS+ のような手法を使い、十分な時間をかけてシステム要件を整理することが大切です。
 
 さて、システム設計の一つであるシステムエンジニアリングのインプットであるシステム要件が決まりました。次にすることは、システムエンジニアリングを行って各サブシステムの要件を明確にすることです。具体的には、一つひとつの要件に対してシステムの振る舞いを考えることと、それと並行して、システムとしてどのようなサブシステム(ブロック)が必要なのか考えることです。システムエンジニアリングにより次のことが明確になります。
 
システム内部の要素とその役割
システム内部の要素間の関係
システム要件に対するシステム内部の振る舞い
システム内部要素の要件(FURPS+)
 
 このステップについては次回、さらに解説します。システム設計のスタートは、顧客からの言葉を FURPS+ のような考え方を使って機能以外の品質特性も含めてシステム要件として整理することです。くれぐれも、顧客や企画部門から与えられた要求だけをシステム要件としたり、機能以外の品質特性について考慮しないままにシステム要件としたりすることがないように注意してください。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
自社の強みとは 『価値づくり』の研究開発マネジメント (その23)

   前回は、オープンイノベーションを成功させるためのビジネスモデルの必要性を解説しました。今回は、自社の強みの設定について議論したいと思...

   前回は、オープンイノベーションを成功させるためのビジネスモデルの必要性を解説しました。今回は、自社の強みの設定について議論したいと思...


経験を知識に転換する工夫 普通の組織をイノベーティブにする処方箋 (その58)

   現在KETICモデルの2つ目、Experience(経験)の解説をしています。しかし、いくら経験を重ねても経験(暗黙知)のままでは、...

   現在KETICモデルの2つ目、Experience(経験)の解説をしています。しかし、いくら経験を重ねても経験(暗黙知)のままでは、...


活動で考慮すべきこと 2 開発効率を上げる(その7)

     【開発効率向上の重要性 連載目次】 製造業の生産性 開発効率向上の重要性 開発効率向上活動の考え方 ...

     【開発効率向上の重要性 連載目次】 製造業の生産性 開発効率向上の重要性 開発効率向上活動の考え方 ...


「技術マネジメント総合」の活用事例

もっと見る
スケールド・アジャイル・フレームワーク (SAFe) の導入開始

        はたして僕が勤める企業はスケールド・アジャイル・フレームワーク (SAFe) を上手く導入で...

        はたして僕が勤める企業はスケールド・アジャイル・フレームワーク (SAFe) を上手く導入で...


設計部門の仕組み改革(その1)

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...


CMMIの要件管理 プロジェクト管理の仕組み (その2)

 前回のその1に続いて、今回は、CMMIの要件管理です。CMMI では次のこと(特定プラクティスといいます)ができている必要があります。   ...

 前回のその1に続いて、今回は、CMMIの要件管理です。CMMI では次のこと(特定プラクティスといいます)ができている必要があります。   ...