カテゴリー:Quality

ソフトウェア品質管理 事実に基づく管理の秘訣

ソフトウェア品質の状況を正しく把握し、その根本原因をもとに開発プロセスや開発技術を改善し再発防止や未然防止アクションをとることで、ソフトウェア品質マネジメント能力を向上します。事実に基づくソフトウェア品質管理サイクルを回転させるための秘訣を解説します。
ISO9001、CMMIに代表される組織的なマネジメント力を向上するためには、現場とマネジメントの融合の仕掛けなくして実現は困難ではないでしょうか。
現場の負担を増やすだけのマネジメントから、現場とマネジメントのWin−Winメカニズムを構築しましょう。

ソフトウェア品質マネジメントと品質管理 (Quality ManagementとQuality Control)

ソフトウェア品質管理—ソフトウェア品質マネジメントと品質管理

Quality Management というと、どう日本語に翻訳されるでしょうか?
品質管理でしょうか?
それとも品質マネジメントでしょうか?
この違いを意識したことがおありでしょうか?

日本語でいう品質管理の感覚は、現場での製品個々に対する品質を確認するというQuality Controlのイメージではないでしょうか?
それに対し、英語のQuality Managementは、ISO9000シリーズで示されるように、製品個々の実際の品質ではなく、もっと広範に製品の品質にかかわるものを述べています。
ISO9001は、Quality Managementシステムに関する国際規格ですが、日本規格協会のHPをみると、「品質管理」でなく、「品質マネジメント」と翻訳されています。
品質マネジメントは、ISO9001を取得している企業の製品の品質に欠陥品がないということを保証しているものではなく、あくまで手順を定め、その通りに製品をつくれば、一定の品質の製品ができるという、どちらかといえば、「品質保証」であるから、品質管理(Quality Control)と区別するために、その様に翻訳されたのではないかと思慮します。

品質マネジメントの基本原則

品質マネジメントの基本原則には
1. 顧客重視
2. 後工程はお客様
3. プロセス重視
4. 源流管理
5. 再発防止と未然防止
6. 事実に基づく管理
7. 全員参加。
があります。
これは、製造業の組立、加工のプロセスのみならず、ソフトウェアの世界でも有効に機能します。

ソフトウェア品質マネジメントと品質管理の融合の必要性

一頃よりは、ISO9001取得していれば安心というISO9001に対する幻想はなくなり、それだけでなく、どう活用しているかに焦点が当たってきていると思われます。
ソフトウェアの開発の世界では、ISO9001の品質マネジメントのみならず、開発力に関する組織的成熟度を示すCMMIというものもありますが、そういう認証や承認というワッペンだけでなく、現場でのいわゆる品質管理が求められることはいうまでもありません。
ソフトウェアの自動生成が将来実現できれば別ですが、ソフトウェアの開発はプロジェクトタイプの仕事であり、開発での個人依存のワークでの品質の作りこみをいかに組織的に支援、マネジメントするかが、従前より重要なテーマです。

ソフトウェア品質マネジメントと品質管理の融合の仕掛け

ソフトウェア開発現場の見える化と事実に基づくコミュニケーション環境

進捗や課題を参加メンバ間で可視化することにより、個人が課題を抱え込むことなく、メンバ同士が、協力支援できる環境を提供することです。
また、継続的な活動を行い効果をあげるためには、転記、集計の負担を参加メンバーにかけない仕掛けが必要です。
img_space
ソフトウェア品質マネジメントと品質管理の融合の仕掛け
個別プロジェクトの状況を正確に把握して事実に基づき組織的品質マネジメント能力を上げましょう。
img_space
 ところで、DevOpsという言葉を最近聞いたことが有りますでしょうか?
これは従来開発(Development)と運用(Operation)という、別々に考えていたものを一緒にすることで利害を克服し、システムに対する要求に対し、より柔軟に、スピーディにシステムを作り上げるプラクティスです。最近強調されるようになってきました。
というのも、ビジネス環境の変化に即応して、システムのリリースの回数を従来に増して増やすことが求められる時代になってきており、それに応えるための現場でのコラボレーション、文化改革として提示されています。当然、不具合の見直し品質面などにも寄与します。

見える化のための品質メトリックス

ソフトウェア品質管理のメトリックスの例を解説します。
・投入工数とレビュー工数(割合)
・仕様書ページあたりの不具合検出の数
・プログラム行数に対する不具合検出の数(フェーズ毎)
・プログラム変更量とテスト項目数・投入工数
これらを時系列、管理図、相関図をもとに比較していきます。人特性、プロジェクト特性、機能特性に分解していくことで一定の管理幅が設定できます。
規格外の担当者を検出した場合には、管理部門、品質部門マネジメントからプロジェクトマネージャへ担当者の変更または、担当業務の変更を提案してはどうでしょうか。

品質目標の設定と共有

ソフトウェアでは不具合(バグ)がないことはありえません。
すべての分岐、すべての入力条件でテストを行ったとしても、所詮人間のすることですから、絶対に不具合がないとは言えません。また不具合がないことを示すことに懸ける費用とその成果であるシステムの求める品質とのバランスを考える必要があります。宇宙船の管制制御システムとスマホのゲームアプリでは、懸ける費用も、求める品質精度が異なることは容易に理解できると思います。
したがって、求めるシステムの性格(社会的な影響、製品に対する直接的な影響、企業に与える業務への影響、当然費用、開発期間)に応じた一定の基準を設けて、それに応じた品質精度として、プログラムの大きさに対するテスト項目数及び不具合検出数の目標を決めるべきです。
要件提示を行う顧客は、早く(短納期で)安い方が良いことはわかりますが、それは品質とトレードオフになることを理解しておく必要があります。

ソフトウェア品質の状況を正しく把握するためのツールを組み合わせ、事実に基づく管理、共有化された目標設定を行い、ソフトウェア産業に従事する開発者、エンジニアを組織的な支援を行い、元気にしていきましょう。img_space

東洋ビジネスエンジニアリング株式会社
植木 浩二
東洋エンジニアリングより移籍後、R&D、管理部門を担当。品質管理、情報セキュリティなどの責任者を務め、現在顧問。
プラントの3D設計支援システム構築、CIM/FA分野でのPJ企画からシステム構築、国際共同研究Project IMS(Intelligent Manufacturing System)などに従事。IT技術全般に関心をもつ。

関連アプリ

品質保証 医薬品、医療機器業界のICH Q10及び、ISO9000/ISO13485の「CAPA 是正措置及び予防措置」を実現します。
サプライチェーン 生産計画から製造・出荷・請求における一連の業務サイクルにおいて、数多くの情報の授受、調整が行われています。
チームマネジメント チームでの仕事は、協働ワークそのものです。課題管理・進捗管理・会議運営の連動と日常業務の可視化によって、適切なマネジメントが実行できます。

 

 

Qualityのその他の記事を読む

ビジネスコラムのカテゴリ

Webサイトトップページへ戻る

ビジネスコラム「製造業SETQ部」記事一覧へ戻る

お問合せ・資料請求・メルマガ購読
  • お問合せ
  • 資料請求
  • メルマガ購読

おすすめ記事一覧

関連記事一覧

  • コラム・対談
  • よくある質問
  • EBCとは

ページTOPへ