ＳＷ品質まとめ⑦品質観点ポイント

一般的な各工程に切り分けた場合の品質観点ポイントをざっと説明したいと思います。とはいえ、できるだけ抽象的な観点ではなく、実践レベルでの具体的な内容にしたいと思います。

ただ、プロジェクトごとに成果物やその内容、様式が異なりますので、そのまま使えるわけではなく、現場ごとにアレンジを加えることは忘れないようにしてください。

ここでは、ＱＡとしてのポイントとしてももちろんですが、本来はエンジニアがあるいはマネージャーが「このソフトウェア開発プロジェクトはどうやって進めていこうか？」という計画を立てる際に最も大事にすべき観点ポイントとなります。

当然ながら、ＱＡはその意図をしっかりと理解したうえで保証をしなければなりませんので、エンジニアやマネージャーが検討し、決定したうえで、その進め方通りとなっているか確認する手前、エンジニアやマネージャー以上に本質を把握しておかなくてはなりません。

要件定義

「要求」と「要件」の違い

ユーザーからの希望や願いは、しばしば「要求」や「要件」という用語で表現されます。これらは全く異なる意味を持っているものと定義して開発に向き合わないと、プロジェクトの失敗比率が数割上昇します。

要求とは
　漠然とした希望や願い、思想、経営上期待している成果など
要件とは
　機能・非機能を含めたシステムに対する実現すべき定義

を意味している点に注意しましょう（ちなみに英語ではすべて Requirement で統一されており、「要求」と「要件」の厳密な違いを意識することはない）。

なぜ「要求」と「要件」の区別が重要になるのか。

それは、そもそもビジネスとＩＴには根本的矛盾があるため、まずビジネスとＩＴの２つの側面からユーザーの要望を切り分けることが必要としているからです。その根本的な矛盾とは、ビジネスとＩＴで情報のとらえ方が異なるということです。

ビジネスで扱う情報とは、あらゆるデバイスやリソース、環境の中に分散しているコンテンツであり、ビジネスプロセスの中で必要になるモノ。対してＩＴ側で語られる情報とは、基本的に「データ」であり、「インフォメーション」となります。

そのデータやインフォメーションが、どういう場面で誰に対し有用な“情報”となり得るかは、そのビジネスプロセスのコンテクストに依存してきます。そのコンテクストを切り分け、データを“情報”として扱えるようにするのがビジネスシステムの役割となるのです。つまりシステム開発とは、

ビジネス全体の中で必要な情報と、システムで切り出す情報とを分け、
さらにシステム要件を詰めて実装に落とし込む作業であり、
漠然とした大きな“要求”の中に、ＩＴ実装に必要な“要件”が隠されている。

ということになるわけです。実装に必要となる要望をユーザーの言葉から見いだしていく作業が必要で、そこで課題となるのが

　「要求をいかに引き出すか」
　「要求をいかに可視化（定義）するか」
　「要求をいかに管理するか」

という3点であり、この作業を”要件定義”といいます。

求められるアクティビティ

先述のように、要件定義と呼ばれる工程、あるいはプロセスと呼ばれる作業の中では大きく３つの課題が存在します。

　「要求をいかに引き出すか（=抽出）」
　「要求をいかに可視化するか（=整理）」
　「要求をいかに管理するか（=管理）」

この３つを満たす作業を構築しなければ、次工程に進んでも満足のいく設計作業ができず、確実に手戻りが発生するでしょう。仮に手戻り作業が発生しなくても、それは問題や課題に気付かずに作業が進んでいるだけであり、システムテスト工程以降に必ず大きな問題となって襲い掛かることになります。

これはシステム開発プロジェクトにおいて、マネジメントが不得意なエンジニアがよく経験するトラブルで、私自身も２桁は間違いなくそう言ったトラブルプロジェクトの火消しに参加していますし、そのトラブルでSIerが被った被害総額は20億を超えていると思います。

仕様変更、あるいは"仕様通りでない"と言う問題でユーザーと揉めるケースの多いプロジェクトではしばしばこういった事例が見受けられます。

ではこの３つの課題を実際に達成するための作業とはどのように構成されるのか、またその作業プロセスごとにどのような成果物を残し、次の工程に引き継いでいくべきなのか考えてみましょう。

成果物例は昔ながらによく聞くものを列挙していますが、一般的にはこういったアクティビティを検討しなければならないはずです。

[課題１] 要求をいかに引き出すか（=抽出）

ＩＴアーキテクトに必要な資質として「コミュニケーション力の高さ」が挙げられることが多々ありますが、この能力が発揮されるのがまさにこの「要求管理」分野においてでしょう。こうしたヒューマンスキルは本人の性質に依存することが大きいが、コツさえつかめば得意/苦手に関わらず要件定義において必要とされるコミュニケーション力を高めることは十分可能となります。重要なポイントは

　開く質問（オープンクエスチョン） と
　閉じた質問（クローズドクエスチョン）

です。これらの質問方式を有効に活用することで、ユーザーから要求を引き出し、重要度や決断を促すことが可能になってきます。

開く質問とは、文字通りユーザー99%の口を開かせる質問で、Yes／Noで回答できない種類の問いを指します。一般に「5W／1H」（何、どこ、誰、いつ、なぜ、どのように）といった問い掛けといえばわかるでしょうか。これに対し、閉じる質問とは基本的に「はい／いいえ」形式を意味します。

ユーザーから要求を引き出すには開く質問を使い、決断を求めたり事実を確認したりするときには閉じる質問というように、2つを使い分けることで、スムーズに要求を引き出せるようになります。これらの要求がどのような特性を持つのか分析し、システムに反映させていくのです。

一般的には、要求のタイプと構造として「機能要求」と「非機能要求」という２つの軸に分け、それぞれ

　ビジネスレベル
　ユーザーレベル
　システムレベル

という３つのレベルで要求のタイプを区分けしていきます。

ビジネスレベルとは主に経営層によるビジネス戦略上の成果や要望であり、ユーザーレベルとは業務現場からの機能要望や使い勝手にかかわる要望となります。対して非機能要求とは、一般に「非機能要件」といわれているものとほぼイコールであり、システムインフラに関与することも多くなります。こうした非機能要求を、ミドルウェアやアプリケーションフレームワークなどに組み込むことで、再利用を促進できるというメリットも生まれるわけです。

[課題２] 要求をいかに可視化するか（=整理）

「洗い出された要求をいかにモデル化するか」

モデル化することで、洗い出された要求の内容と実現可能性を確認するというメリットがあります。また、各ステークホルダー間の情報共有や、管理・統制がしやすくなるという側面もでてくるでしょう。要求管理のフェーズにおいて、最大の肝となるのがこの“モデル化”です。要求を可視化する手段として、ビジネスモデルやビジネスプロセスモデル、DFD（Data Flow Diagram）、状態モデル、イベントシーケンス図、概念クラス図、概念オペレーショナルモデルなど、多くのモデル表記法が有効となってきますが、とりわけ既存の様式に固執する必要はありません。関係者にとって共通認識となることができれば、その点は自由です。

ただし、中でも重要となってくるのはアーキテクチャ構築のためのメタモデルの重要性です。アーキテクチャのメタモデルとは、機能と非機能の2つのモデルで構成されます。ユーザーからの機能／非機能の要望をモデル化して、

　・仕様
　・詳細
　・物理

の３つの側面から分析し、融合させていくことをアーキテクチャ設計作業と位置付けていく必要が出てくるかもしれません。具体的には、機能要求はコンポーネントベースの設計・分析手法を適用し、非機能要求についてはノードやトランザクションの関連性モデルで表現する…と言った感じです。ただし、システムの規模が大きくなるとノードのモデルも複雑になるため、注意する必要があるでしょう。

[課題３] 要求をいかに管理するか（=管理）

最後の課題は「要求の管理」です。ここでいう“管理”とは、物理的な文書管理はもちろん、変更が生じた場合のトレースやインパクト分析も含めています。

さらにもう１つ、要求管理の実践において必要なのが「ベースライン管理」です。ベースライン管理とは、あいまいな要求の“ベース”となる起点を（暫定でもいいので）まずは決定し、そのベースに対してどれだけ変更が加えられたかを把握することです。

しかし、変更やその履歴を管理することは、普通にやろうとすると非常に大変な労力を伴います。結果、マネージャー、エンジニアの多くは記録化することをおざなりにし、"記憶"と言う曖昧な媒体を基に仕様を取り決めていくか、あるいは冗長的な記録を大量に作成し、後で見直すこともできない資料の山を築いていくかを実施します。その先にはほぼ確実に情報の管理ができず、後手に回り、悪いときにはトラブルとなって大炎上を起こしてしまうと言う状態となるでしょう。

よって、必要とわかったそのうえで、変更が頻繁に発生する要求管理を効率的に行うには、市販のツールを含めた何らかの『仕組み』が必要となってきます。

　「要求は開発するシステムの制約にかかわるうえ、
　　頻繁に変更や手戻りが発生するもの。
　　変更履歴のトレーサビリティを確保するには、
　　手作業ではなくツールの仕組みが必要になる」

と言う認識が必要になるのです。

ツールを導入するメリットは２つあります。１つはステークホルダー間の情報共有がより向上すること。もう１つは変更履歴のトレースやインパクト分析がしやすくなる点です。

一方、デメリットとしてはツールの導入により発生するオーバーヘッドの存在です。たとえば変更履歴のトレースやインパクト分析を実行するには、事前のデータ入力やメンテナンスが欠かせません。

こうしたイニシャルコスト(=初期投資)と呼ばれるオーバーヘッドを吸収する１つの目安が開発期間となります。３～４カ月未満のプロジェクトだと、メンテナンスと開発スピードのバランスが取りづらくなるので慣れてないうちは控えた方が良いかもしれません。また、要求管理に何らかのツールは必要ですが、メリット／デメリットを考えると、必ずしも高機能なツールでなくても構いません。

自社の開発手法の中に、要求を可視化し、管理する体制を作り上げることが最優先と位置付けなければ、無計画、無思慮にツールに依存してしまっていては効率的なプロジェクト管理は絶対にできはしないのです。

どのように要求をモデル化するのか？

ここでもう１度、モデル化について考えてみましょう。

ビジネス的な要求、そしてシステムに関係する要求（要件）をモデル化し、合致させることでアーキテクチャ設計を進めていくことになりますが、ユーザーの要求が複雑になるにつれモデル化は困難になり、その先の設計に支障を来たします。

必ずしも絶対的な正解があるわけではありませんが、アーキテクチャのメタモデル作成に対し、「アスペクト指向」の考え方を取り入れると良いでしょう。

アスペクト指向とは、横断的な関心事を共通要素としてくくり出し、再利用性を高める手法を言います。要求のモデル化に関していえば、主に非機能要件を切り出すケースが多いかもしれません。

機能要求のモデルを「ファンクショナル・アスペクト」、非機能要求を「オペレーショナル・アスペクト」と呼び、ファンクショナル・アスペクトはコンポーネントベースでの分析・設計を基本とし、対して非機能要求のモデルはシステムのノード／コネクション／ロケーションなど、インフラを抽象化したモデルと考えれば分かりやすいでしょう。これらのモデルを使って、機能要件を満たしたビジネスコンポーネントを、どのノードにどのように配置していくかを決めていくのが理想となります。

keyword（観点キーワード）

《一般要求事項の網羅》
“要求"とは、「～がしたい」という利用者の希望。
“要件"とは、要求を実現可能にするために何をしなければならないかを表したもの。一般要求事項とは、ユーザーから明示されていない同種のシステムであれば一般的に要求されるであろう「常識」がすべて盛り込まれていることを確認する必要がある。特に、セキュリティ要件と障害要件に関しては、ユーザーのBCPなどにも大きく影響するため、注意が必要となる。

《顧客要求事項の網羅》
要件を定義していくうえで、先に洗いだしておいた要求がすべて実現できるように要件に落とし込まれているかどうかを意味する。
この中には、１つの要求から読み取れる明示的ではない潜在的な要求も含まれなければならない。そのためには、一つひとつの要求に対して６つの品質特性の側面から、検討事案が無いかを確認する必要がある。

ここから先はファイルにて。

7. 品質観点ポイント
　7.1 要件定義
　　7.1.1. 「要求」と「要件」の違い
　　7.1.2. 求められるアクティビティ
　　　7.1.2.1 [課題１] 要求をいかに引き出すか（=抽出）
　　　7.1.2.2 [課題２] 要求をいかに可視化するか（=整理）
　　　7.1.2.3 [課題３] 要求をいかに管理するか（=管理）
　　　7.1.2.4 どのように要求をモデル化するのか？
　　7.1.3. keyword（観点キーワード）
　　7.1.4. 合目的性
　　7.1.5. 記述事項網羅性
　　7.1.6. 理解性（明確さ/わかりやすさ）
　　7.1.7. 追跡可能性・追跡容易性
　　7.1.8. 整合性（内部・外部）
　　7.1.9. 優先度・重要度明確性
　　7.1.10. このフェーズで起きるトラブル
　7.2 外部設計／基本設計
　7.3 内部設計／詳細設計
　7.4 設計レビュー
　　7.4.1. 分類
　　7.4.2. 重要度
　　7.4.3. 是正／再発防止
　7.5 製造
　7.6 単体テスト（Unit Test / Program Test）
　　7.6.1. keyword（観点キーワード）
　　7.6.2. 合目的性
　　7.6.3. 記述事項網羅性
　　7.6.4. 境界値（限界値）テストはどこで実施するのか？
　7.7 結合テスト（Join Test / Integration Test / Combined Test）
　　7.7.1. keyword（観点キーワード）
　7.8 総合テスト／システムテスト
　　7.8.1. 合目的性テスト
　　7.8.2. 正確性テスト
　　7.8.3. 効率性（性能）テスト
　　7.8.4. 性能試験計画の流れ

まだまだ未完成な部分もありますが、今後も充実・更新していこうと思います。