知識体系とSQuaRE

Mar 14, 2017  

ソフトウェア開発においては、ユーザーに対するアプリケーションの使用性と、 システムとして有効に機能するための品質特性の双方を考えることが重要です。 対象規模が大きなものや開発や運用が長期化してくると状況が複雑化する可能性がありますので、 課題に対して体系的に取り組む必要があります。

知識体系 (BOK: Body of Knowledge)

ソフトウェア開発プロジェクトを開始するときに考えるべき大きな枠組みとしては、「ビジネスアナリシス知識体系ガイド」 (BABOK - Wikipedia: A Guide to the Business Analysis Body of Knowledge) があります。BABOKでは、4種類の要求を定義しています。

  • ビジネス要求
  • ステークホルダー要求
  • ソリューション要求
  • 移行要求

IPA 独立行政法人 情報処理推進機構のサイト内検索で「BABOK」を調べると、PDFの資料がいくつか見つかります。 中でも「BABOK概要と最新動向」が網羅的な説明になっていると思います。(資料の副題はさておき)

非常にざっくりした説明だと、ビジネス要求は会社として利益を上げるために何をすべきか、ステークホルダー要求は顧客が欲しがるものは何か、 ソリューション要求はシステムとして何を構築するか、という感じです。 移行要求は現状からの変更点や変更方法を表しており、移行が終われば要求自体がなくなります。

それぞれの要求をどのように抽出および獲得していくか、という課題に対しては「要求工学知識体系」 (REBOK: Requirements Engineering Body of Knowledge)があります。 既存の業務をシステム化したい、という場合には、ユーザーとシステム開発者の間に背景情報や目標の違いが多々ありますので、 REBOKのような枠組みを使って原因を掘り下げていくと良いと言えます。

要求獲得がうまくいかないことの風刺として「Project Cartoon」が有名です。 顧客からの説明、プロジェクトリーダーの理解、システム開発および運用、その後のサポート体制やマーケティング、実は顧客が欲しかったもののそれぞれが、 似ているようでも全く異なることが木にかかったブランコで表現されています。

SQuaRE: Systems and software Quality Requirements and Evaluation

風刺画で共感を得ることはできますが、ではどうするの? という疑問には応えてくれません。 実際に合意形成を構築していくための実践的な内容として ISO/IEC の規格があります。 ソフトウェアの品質としては ISO/IEC 9126 がコアとなるもので、現在はその改訂版の ISO/IEC 25000 が有効です。 ISO/IEC 25000 は2014年に改訂され、以前のものは ISO/IEC 25000:2005 、現在のものは ISO/IEC 25000:2014 と表記されます。

話がやや複雑ですが、 ISO/IEC 25000 では関連する内容を「SQuaRE」(Systems and software Quality Requirements and Evaluation) として一連のシリーズにまとめており、個別の規格は別々に定義しています。 2500n (nは一桁の数字、以下同様) は品質管理、2501nは品質モデル、2502nは品質測定、2503nは品質要求、2504nは品質評価となっています。 発行済の 2501n には 25010 と 25012 があり、それぞれ「システム及びソフトウェア品質モデル」、「データ品質モデル」と呼ばれます。 これらは日本国内において JIS X としても発行されています。

さすがにこれだけ膨大な規格定義をいきなり読むことは現実的ではありませんので、IPA がガイドブックを発行したり、 ポータルサイトを作っている会社があったりします。

SQuaRE の品質モデルには「製品品質モデル」「データ品質モデル」「利用時の品質モデル」の3つがあります。 製品品質モデルでは品質を表す特性を「品質特性」と呼び、以下の8つに分類しています。

  • 機能適合性
  • 性能効率性
  • 互換性
  • 使用性
  • 信頼性
  • セキュリティ
  • 保守性
  • 移植性

それぞれの品質特性は「品質副特性」として細分化され、合計で31の副特性に分類されています。 システムの設計・開発・運用に際しては、これらのバランスをとる必要があります。 どこでトレードオフが発生するかをよく考えることで、考慮漏れの減少が期待されます。

まとめ

ソフトウェア開発における知識体系と品質管理に関する枠組みを概観しました。 大規模プロジェクトでは「要件定義書」としてまとめられるような内容だと思います。 小規模プロジェクトでは仰々しく感じられて省略されてしまう部分もあるかもしれません。 しかし、内容を認識していて時間的制約によりスキップする場合と、 内容を知らずに後から補修する場合では問題への取り組み方は大きく異なると予想されます。 抽象的かつそれぞれの文書量が膨大ではありますが、 開発プロジェクトの範囲を検討するに当たっては関係者間で目次を読み合わせておくと良いでしょう。