クラウド時代の要件品質向上と品質保証への取り組み [4.01mb]

2016年3月11日

リコーITソリューションズ株式会社

品質管理部坂田英信

クラウド時代の要件品質向上と品質保証への取り組み

～ SQuaREによる品質マネジメントシステムの改善～

IPA/SECセミナー

Copyright © Ricoh IT Solutions Co., Ltd. All Rights Reserved.

Ricoh IT Solutions Confidential

はじめに～本日の内容～

リコーITソリューションズでは、システム開発プロジェクトの成功と開発組織の成熟度向上を狙いとして、品質マネジメントシステムの基盤と品質活動を全社に展開しています。

異なる分野の製品・サービスが “つながる世界“ においてソフトウェアへの品質要求が多様化する中、どのようにして品質を確保し、顧客満足を高められるかは、ますます重要なテーマです。

本日は、以下項目をご紹介しながら、その実践について考えます。

品質マネジメントシステムの取り組み

プロジェクトの立ち上げから終結までを対象に実践してきた品質活動、品質マネジメントシステムの取組みについて

上流工程の品質向上（要求インスペクション）

要求仕様書の品質向上による開発と製品の生産性・品質の向上について

クラウド時代の製品の品質保証の模索

利用時品質を加えた品質保証について

2



Agenda


上流工程からの品質向上（要求インスペクション）


まとめ

3

１

２

３

４



Agenda




まとめ

4

１

２

３

４



品質管理部門について

ミッション品質管理の統括（グループ展開へ）

組織機能不良システム出荷の予防

品質マネジメントシステムの継続的改善

エンジニアリングプロセスの革新

リコーITソリューションズについて

本社所在地東京都中央区晴海1-8-10

晴海アイランドトリトンスクエアオフィスタワーX

設立 1982年10月5日

資本金 2億5,000万円（株式会社リコー全額出資）

代表者森田哲也

従業員数 845名（2016年 2月 1日現在）

事業内容システムインテグレーション事業

ITサービス事業、組込みソフトウェア事業

会社概要と部門紹介

5

リコーグループとともに「人・情報・信頼を技術でつなぐイノベーション企業」として、お客様のワークスタイル・イノベーションを実現するITソリューションを提供

個別支援

各種テンプレート

標準ツール

システム

教育監査



RITS品質保証の特徴

6

① Quality Gate とプロセスレビューによるプロジェクト品質の確保

② 組織成熟度判定による組織能力・成熟度の向上

③ Ｗ字モデルによる早期評価基準の確立

品質監査報告書

プロジェクト

品質管理部

ドキュメント監査

監査指摘事事項

プロジェクトマネジメントボード• プロジェクトマネージャー• プロジェクトスポンサー• エグゼクティブスポンサー

プロジェクト立ち上げ

• 見積り

• プロジェクト憲章

プロジェクト計画

• プロジェクト管理計画書

• プロジェクト実施計画書

プロジェクト実行

• プロジェクト実績報告書

• プロセスレビュー

プロジェクト終結

• プロジェクト完了報告書

• プロジェクト評価書

受託審議会QGプロジェクト計画審議会QG設計審議会QG リリース審議会QG

組織監査

①

①

① 全マネージメントプロセスのレビュー

①

②

要件定義

要件定義書類

外部設計

アーキテクチャ設計書

機能仕様書類

内部設計

設計モデル

詳細設計書類

実装＆単体テスト

ソースコード

ビルド

統合/システムテスト

修正済ビルド

導入・受け入れ支援

リリースビルド

テスト仕様書類③

④ ①⑤

⑤

※ 全組織を年に一度監査※ プロジェクトを常時監視し監査する方式を試行中

④ ドキュメント標準による品質の確保⑤ 定量的品質管理

⑥ プロセスの可視化⑦ 顧客満足度調査

① 全エンジニアリングプロセスのレビュー

顧客とのプロジェクト合意QG

品質監査QG

①

→ 障害発見率予測とゾーン分析検証

⑦

⑥ プロセスの可視化

顧客満足度調査



Quality Gate とプロセスレビューによる品質保証

7

Quality Gate は、フェーズの境界にて実施するチェック機構であり、プロジェクトの生殺与奪を決定する（マイルストーンレビュー）

プロセスレビューは、マネジメントおよびエンジニアリングのプロセス実施状況をレビューする

プロセスレビュー（マネジメント）1. プロジェクト計画策定2. プロジェクトの監視と制御3. 要件管理4. 構成管理5. 供給者合意管理6. プロセスと成果物の品質保証7. リスク管理8. 定量的プロジェクト管理

プロセスレビュー（エンジニアリング）1. 要件定義（要件開発）2. 設計（技術解）3. 実装・単体テスト（技術解）4. 成果物統合5. レビューとテスト（検証）6. 妥当性確認

Quality Gate

1. 受託審議会2. プロジェクト計画審議会3. 顧客とのプロジェクト合意4. 設計審議会5. 品質監査6. リリース審議会

品質マネジメントシステム

エンジニアリングの領域

品質保証の領域

プロジェクト管理の領域

「開発のためのCMMI」に準拠したチェックポイント（評価基準）を備える

RITSの品質マネジメントシステムには、2005年に成熟度レベル４を達成した知見が活かされている



組織成熟度判定による組織能力・成熟度の向上～成熟度レベルの定義～

8

プロセスレビューのチェックリストに加えて組織活動をレビューするためのチェックリストを用い、年に一度、品質管理部が組織の成熟度を判定する

チェックリストは各プロセス固有のプラクティスとゴール、全プロセスに共通のゴールから成り立つ

判定するプロセスエリアは以下のとおり

レベルの定義

レベル３は「ふつう」ではなく、予測可能、すなわちコストや納期の大幅な乖離が稀である組織

RITS・RJの対象全組織がレベル３以上を目指す

プロセスレビュー（マネジメント）

1. プロジェクト計画策定2. プロジェクトの監視と制御3. 要件管理4. 構成管理5. 供給者合意管理6. プロセスと成果物の品質保証7. リスク管理8. 定量的プロジェクト管理

プロセスレビュー（エンジニアリング）

1. 要件定義（要件開発）2. 設計（技術解）3. 実装・単体テスト ※技術解4. 成果物統合5. レビューとテスト（検証）6. 妥当性確認

組織活動

1. 決定分析と解決2. 組織プロセス重視3. 組織プロセス定義4. 組織トレーニング5. 組織プロセス実績6. 組織実績管理7. 原因分析と解決8. 測定と分析

L1：初期

混沌としている

L3：定義されている

組織間で整合した標準プロセスを確立し、プロセス遂行が定性的に予測可能である

L5：最適化している

あらかじめ定めた定量的な（予測可能な）プロセス改善目標を達成できる

L2：管理されている基本的なプロジェクト管理プロセスが確立し、過去の成功を反復する

L4：定量的に管理されている

プロセスの遂行が定量的に予測可能である



Ｗ字モデルによる早期評価基準の確立

9

SLCPをベースとした開発標準を制定し、Ｗ字モデルを基本としている。

テスト時期になってテスト仕様書を作成するのではなく、上流工程の段階からテスト設計を並行して実施する。

ドキュメント標準にて、どの文書をもとにどの文書を作るかといった依存関係が明確に定義されている。

システムテスト設計

SW構築（単体テスト）

システムテスト

統合テスト

システムテスト

障害対応

システム要件定義

システム方式設計

SW要件定義

統合テスト

障害対応

統合テスト設計

SW方式設計

単体テスト設計

SW詳細設計

SW構築(コーディング＆デバッグ)※ SW=Software



ドキュメント標準による品質の確保～ドキュメント標準一覧～

パッケージテンプレートガイドライン実例

戦略 1. 顧客情報書 1. ― 1. ―

業務要件 1. 案件定義書2. 業務要件定義書

1. ―2. ―

1. ―2. ―

要件定義 1. 要求リスト2. 要件定義書3. 用語集

1. ○2. ○3. ○

1. ○2. ○3. ○

設計 1. アーキテクチャ設計書 1. ○ 1. ○

外部設計 1. 機能仕様書2. 外部ＩＦ仕様書

1. ○2. ○

1. ○2. ○

内部設計 1. IT基盤内部設計書（総称）2. ソフトウェア内部設計書3. データベース設計書4. 画面設計書5. 帳票設計書6. 外部接続設計書

1. ―2. ―3. ―4. ―5. ―6. ―

1. ○2. ○3. ○4. ○5. ○6. ○

テスト 1. 単体テスト仕様書2. 統合テスト仕様書3. システムテスト仕様書4. 品質報告書

1. ―2. ―3. ―4. ○

1. ○2. ○3. ○4. ○

プロジェクト管理 1. 品質計画書2. 課題管理表3. プロジェクト計画確認書

1. ○2. ○3. ―

1. ○2. ○3. ―

10

ドキュメント標準はテンプレートと作成ガイド、実例集によって構成される



プロジェクトのモニタリング

11

PMをはじめとする関係者がプロジェクトの状況： QCD+Rを把握

クリックするとさらにプロジェクトごとに詳細を確認できる

視認性を良くするためのアイコン表示

プロジェクト期間の消化、原価の着地見込みをグラフ化

プロジェクト管理文書、Quality Gate確認表の進捗をアイコンで表示



Agenda


上流工程からの品質向上（要求インスペクション）


まとめ

12

１

２

３

４



活動の背景と期待

背景

- そもそも要求仕様書に書くべき事項が書いてないことが多い

- 要求仕様書の品質向上とそれによる開発生産性、品質の向上を狙う

JISA「要求仕様書インスペクション研究会」が発足

- NTTデータと南山大学の青山教授との要件定義のインスペクションに関する合同研究（RISDM）をベースとしている

- 研究成果を複数の企業でも実施し有効性を研究中

- RITSも第２回会合から参加へ

- 他にも４社以上が参加している

13



活動の背景と期待（続き）

研究会での各社での設計（RISDMのテーラリング）

1. パースペクティブの決定

2. 評価軸の選定

3. 要件定義書の項目に対する評価軸の割り当て

研究会の期待効果

- 研究成果では特定評価軸のスコアリング結果とコスト乖離に相関あり

- 他の企業でも相関があるかを検証していきたい

- インスペクションの方式のバリエーションを増やすことで、様々な研究をし、ソフトウエア業界の要件定義の改善に役立てたい

RITSの期待効果

- スコアリング結果による品質監査の深度調整が可能となるか

- スコアリング結果によるプロジェクト管理の強度調整が可能となるか

14



インスペクションシートとスコアリング

要件定義書インスペクションシートを用いて記載内容を評価

記載項目ごとの記載充足率を算出

ISO/IEC9126とIEEE830から決定した評価軸ごとのスコアリング

15

要件定義書インスペクションシート

要件定義書スコアリング



要件定義書へSQuaREを適用

ISO/IEC9126から選別した品質副特性で評価することを基本

足りない箇所をIEEE830で補う

IEEE830 の再評価と評価軸の見直しを実施

８つのPQC項目（評価軸）

要件定義書にSQuaREの品質特性を適用した上で、要件定義の品質評価を実施、改善していく

評価軸の見直しも必要に応じて実施する

16



利用時品質の品質要求定義

利用時品質の品質要求定義をプロセスに取り入れていく

17

（参考情報）システム／ソフトウェア製品の品質要求定義と品質評価のためのメトリクスに関する調査報告書http://www.meti.go.jp/policy/it_policy/softseibi/metrics/20110324product_metrics2010.pdf

利用時の品質要求

システム製品・ソフトウェア製品の品質要求

メトリクスによる妥当性評価

メトリクスによる検証・妥当性評価

複数のコンピュータシステムを連携させ、

サービスを実現

個々のソフトウェアに求められる機能を実現

利用者ニーズ開発・実現

複数のソフトウェアを連携させ、機能を実現

利用時の品質システム製品・ソフトウェア製品の

品質（外部品質・内部品質）

現実のシステム環境での目標達成状況を

測定する

運用を意図したシステム環境で製品の実

現度合いを測定する

設計仕様書、ソースコードを評価する

利用者ニーズの定義

ステークホルダーの利用シーン（ユースケース）を識別する

システムの利用時のニーズ、リスク、課題を明らかにする

利用時の品質要求の定義

利用者ニーズから実現すべき要求を識別する

利用時の品質モデルを作成する

品質モデルの各特性の具体的内容をメトリクス等を利用して品質要求仕様として定める

製品の品質要求の定義

利用時の品質要求から製品に求められる機能要求・品質要求を整理する

製品の品質モデルを作成する

品質モデルの各特性の具体的内容をメトリクス等を利用して製品の品質要求仕様として定める

品質要求定義

http://www.meti.go.jp/policy/it_policy/softseibi/metrics/20110324product_metrics2010.pdf



Agenda




まとめ

18

１

２

３

４



リコークラウド商品の例

19

リコーが社内で活用している法務相談と契約情報管理をシステム化した法務業務支援ツールをベースにお客様向けにクラウド化

RICOH-EIM（Enterprise Information Management）によりサービスを提供

（詳細情報）商品情報： http://www.ricoh.co.jp/mds/cws/ニュースリリース： http://www.ricoh.co.jp/sales/news/2016/0114_1.html?_ga=1.163814143.1971401746.1455262184

2016年1月14日法務支援クラウドサービス「RICOH Contract Workflow Service」を新発売～企業における法務相談や審査結果の履歴を共有し、契約情報の一元管理を実現～

http://www.ricoh.co.jp/mds/cws/

http://www.ricoh.co.jp/sales/news/2016/0114_1.html?_ga=1.163814143.1971401746.1455262184



クラウド商品における利用時品質の活用方法

従来は製品品質のみで品質保証を行ってきた

結果として得られる利用時品質も加えた品質保証へ

製品品質と利用時品質の相関により重要視する品質を明確にする

20

機能適合性

性能効率性

互換性

使用性

セキュリティ

信頼性

保守性

移植性

有効性

効率性

満足性

リスク回避性

利用状況網羅性

利用時の品質

原因結果

「利用状況完全性」

「柔軟性」

製品品質（外部品質・内部品質）ＷｈｙＷｈat、How

「可用性」サービス稼働率：サービスを利用できる確率

「修正性」性能拡張性：各リソースが上限に近くなった場合、容易にスケールアップができること

【利用時品質の測定方法】

要求仕様書に対するヒアリングの結果や製品の利用時／利用後のアンケート調査による定量的評価、プロトタイプテスト、現地テスト、ベータテストなど

利用状況を的確に

捉えられるか

基本のシナリオ

応用のシナリオ

想定外シナリオ

適切な品質測定量を決められるか



利用時品質の品質評価

21

（参考情報）システム／ソフトウェア製品の品質要求定義と品質評価のためのメトリクスに関する調査報告書http://www.meti.go.jp/policy/it_policy/softseibi/metrics/20110324product_metrics2010.pdf

利用時の品質要求

システム製品・ソフトウェア製品の品質要求

メトリクスによる妥当性評価

メトリクスによる検証・妥当性評価

利用者ニーズ開発・実現

利用時の品質システム製品・ソフトウェア製品の

品質（外部品質・内部品質）

現実のシステム環境での目標達成状況を

測定する

運用を意図したシステム環境で製品の実

現度合いを測定する

設計仕様書、ソースコードを評価する

品質評価

複数のコンピュータシステムを連携させ、

サービスを実現

個々のソフトウェアに求められる機能を実現

複数のソフトウェアを連携させ、機能を実現

利用時の品質の評価

実運用時に、特定の利用者が特定の利用状況におけるシステムの品質要求仕様の実現度合を、メトリクスを利用して評価する

要求仕様書に対するヒアリングの結果や製品の利用時／利用後のアンケート調査による定量的評価、プロトタイプテスト、現地テスト、ベータテストなど

システム品質の評価

リリース前の結合・統合テストで（ソフトウェア結合・総合テストから移行・運用準備の間で）、システムの品質要求仕様の達成度合いをメトリクスを利用して評価する

ソフトウェア品質の評価

レビュー及び単体テストで、ソフトウェア製品の品質要求仕様の達成度合いをメトリクスを利用して評価する。また、システムとなった時にどのような品質が得られるかについてメトリクスを利用して評価する

利用時品質の品質評価をプロセスに取り入れていく

http://www.meti.go.jp/policy/it_policy/softseibi/metrics/20110324product_metrics2010.pdf



クラウド時代に向けて

22

これまでは…

リリースするまでに全ての障害を取り除くことを目指す

• “頑強な”システムか？ “柔軟な”システムか？

全社共通の品質基準（テスト密度、バグ密度）をベースライン

• 自社の実績値を反映したベースラインとはなっているが

全方位的なテストの実施

• 品質特性による重要度の強弱はあまり付けていない（プロジェクトによる）

想定内の利用、直接的なステークホルダーが中心

• 想定以上の利用、間接的なステークホルダーの視点は多くない

スクラッチ開発を中心にした品質保証がベース

• 他社のパッケージを担いだシステム開発が増加傾向



クラウド時代に向けて（続き）

23

グーグルのテスト担当者

「つながるシステム全体で」

・これまでは製品単体であったものが、ネットワーク環境を含めたシステム全体で、品質を確保する必要がある

・「品質に関する共通言語を定義し利用することが、つながるシステム全体の品質を具現化することを可能に

「品質を戦略的に考える」

・製品の特徴、などに合わせて、あえて品質を低いレベルに設定するという選択もある。

・適切に品質コストをコントロールする必要がある

「いつでもリリース」

・「21世紀の開発は、現場においてイノベーションからリリースまでがシームレスに続いており、いつでもリリースが発生する」

「ヘルスケア」

・「クラウド時代のテスト担当者の仕事は、「出荷前にできるかぎり信頼性を高めよう」的なプロセスではなくヘルスケアである」



進む・広がる品質基準

24

障害件数

時間

従来の品質基準＝“障害が出ないこと”

曲線がなだらかになったな･･･

クラウド時代、リリース時間は大幅に短縮スピード感が求められている

QAに時間がかかる

SQuaREの利用

“障害が出ないこと” が絶対的な基準？“出た障害がすぐ直せること”では？

“使いやすいこと”の方が？“美しいこと”じゃないの？

５０時間連続稼働で障害ゼロって過剰品質では？金融も医療もプリンタも車もスマフォも同じ品質基準？

安全性・セキュリティ、快適さや楽しさ、ビジネスへの高度の貢献が求められる

つながるシステム

製品品質だけでなく利用時品質、データ品質

の向上が求められる

つながるシステムのライフサイクルに対して（IoT、M2M、スマートコミュニティ、パッケージ製品等）



Agenda




まとめ

25

１

２

３

４



まとめ

SQuaRE品質モデルを適用中の活動

要件定義品質の向上（要求インスペクション）

品質保証における品質基準の見直し

開発標準の改善

• 開発プロセス標準、メトリクス管理標準

SQuaRE品質モデルの活用による期待

過剰品質の改善、品質コストの最適化

• 利用時品質を効果的に活用することで「過剰な製品品質」「顧客不在の性能競争」を抑制

品質の共通言語、品質基準の説明力向上と共通理解形成

• 個別案件においては重視する特性についての顧客合意

• 要件定義の漏れ防止、テスト計画の漏れ防止に活用

着目する品質

• 利用時品質、データ品質、セキュリティ/セーフティ、サービス品質26

機能が使えるだけではなく、必要とする機能を利用者が「高い満足度」で使えることが強く求められる時代に対応するため品質マネジメントシステムの改善を行う



27

ご清聴ありがとうございました

クラウド時代の要件品質向上と品質保証への取り組み [4.01mb]

Documents