ソフトウェア品質保証をめぐる齟齬のなくし方

1. はじめに

ソフトウェア品質保証の役割と名称（森崎 修司・著）を拝読しました。こちらの記事によると「ある人が思っている品質保証と別の人が思っている品質保証の違いが大きいときがあるので齟齬が起きやすくなります。」とのことです。

製造業でソフトウェアのQAに従事している筆者は品証さんと協力しながら仕事をすることもあって特に齟齬は感じないのですが、とはいえ齟齬が生じるのもわからないではないのでちょっと書いてみます。

2. 品質保証の多義性のホントのところ

齟齬をきたす要因として考えられるものを以下に挙げます。

2.1 Quality Assuranceと品質保証の違い

SQuBOK Guide V3より品質保証の解説を引用します。

• ISO 9000では…品質保証は，品質を確認する活動の実施状況を，証拠をもって示す活動である。(p.24)
• 日本では品質保証という用語を『お客様が安心して使っていただけるような製品を提供するためのすべての活動』〔飯塚2005〕(p.25)
• ISO 9000と日本流のどちらの解釈においても，品質保証を顧客満足を目的とした活動と位置付ける点では同じである。 (p.26)

ISO 9000の「Quality Assurance（を日本語に訳した品質保証）」と日本流の「品質保証」は顧客満足を目的とした活動は共通なものの実証に力を入れるか顧客が満足したという結果に力を入れるかという違いがあります。ただ、「ソフトウェア品質保証の役割と名称」でいうところの多義性はこれではなさそうです。

2.2 群盲象評

「品質保証」が多義的に見える二番目の理由として製品のライフサイクル（企画、設計、製造、販売、付帯サービス¹、廃棄）のどことも品質保証が関係する一方で個々のメンバーが関わるのはそのうちの一部分というのがあります。

分業体制では個々のメンバーは担当業務はよくわかる一方で担当外のことはあまりよくわからないという事態が発生します。自分の担当業務を担当外のメンバーが説明しているのを聞いたらなんだかいまいちと思うことがあるのはそうおかしなことでもないでしょう。

• この図は以下の記事にヒントを得て描いたものです。
  • 本日から、品質部門配属になりました　第32回　『市場品質の保証）』（その1）
  • 『品質でもうけなさい』2-2.品質とは「良さ」なのか？
• このモデルはJIS X 0129やJIS X 25000の「内部品質、外部品質、利用時の品質（製品の品質ライフサイクルモデル）」とは異なることや、保守性や移植性といった内部品質を顧客が直接認識することはない点に注意が必要です。

2.3 工程の違い

三番目の理由としてライフサイクルに登場する工程の違いがあります。製造業ではソフトウェアは製造工程（量産工程）を伴うもの（ファームウェア²）と伴わないもの（ファームウェア以外）の二系統あります。

• ファームウェア：量産移行判定までに完成させて部品の一つとして工場へリリースされ、そのバイナリデータがROMに焼かれて³量産品に組み込まれるソフトウェア
• ファームウェア以外：パソコンやスマートフォンのアプリなど量産工程を経ずにリリースされるソフトウェア

2.3.1 量産工程を伴わない

最初に量産工程を伴わない工程を以下に示します。

• パソコンやスマートフォンのアプリなど量産工程がないソフトウェアは設計工程の成果物がそのまま顧客の手に渡ります（クラウドサービスのように顧客にソフトウェアが渡らないものもあります）。
• 企画品質や設計品質のまずさがそのまま市場へ出ていくことになり品質保証の関心は企画や設計に向かいます。

2.3.2 量産工程を伴う

次に量産工程を伴う工程を以下に示します。

• 顧客が手にするのは設計工程で作成された「設計図や試作品、見本」ではなく量産された「コピー」です。企画品質や設計品質のまずさが市場に出ていくのは量産工程の有無を問わないもののその品質は量産移行判定でひとまず担保され⁴、量産部門は量産品質に注力します。顧客にとっては量産品質も大事な要素であり、それは品質保証にとっても大事です。
• 設計品質に「量産のしやすさ」が加わります。ハードウェアでいえば例えばポカヨケが、ソフトウェアでいえば工場検査用ファームウェアや検査モードの機能適合性（不良品を良品と誤判定をしない、不良の理由がわかる、など）や性能効率性（短時間で検査が完了する）などがあります。
• 量産品質の指標には例えば直行率や歩留まりがあります。これらは量産のない分野ではなじみがないかもしれません。

• ポカヨケは生産ラインでのうっかりミスを防ぐ工夫です。例えば置き方が決まっている部品を逆向きに配置するとネジ穴の位置が合わないように意図的に設計して正しい向きでしか置けないようになっている、といったものです。
• にしさんのJaSST'20 Tokai 基調講演「Re-collection of embedded software qa in the last decade 」p.34でソフトウェアトラップの一つに「順序が逆のものが混在すると、混同しやすい」が紹介されています。ソフトウェアは物理的なガードを入れられないにしても、形式知化された落とし穴を踏まえて順序が逆のものが混在しないように設計するのはソフトウェア版ポカヨケといえます。

2.4 分野による歴史の違い

戦後の日本の品質管理、品質保証の歴史をたどっていくと日本科学技術連盟発足⁵（1946年）、デミング賞創設（1951年）、JIS Z 8101 品質管理⽤語の制定（1956年）など約80年の歴史がありますが、世界初のマイコンとして知られるTI（テキサス・インスツルメンツ）TMS1000の発売は1974年でマイコン搭載製品の歴史は約50年です。

マイコン搭載製品として一眼レフカメラを例に挙げると拙著ArduinoとオシロスコープをExcelで制御して測定する(2)シャッタースピードの自動測定で使用したキヤノンのFTb-Nは1973年発売の機種でマイコンはまだ載っておらず、1976年発売のAE-1で「マイクロコンピュータが中央集中制御する方式」が採用され⁶、1978年発売のA-1で「完全デジタル制御による高度な電子カメラ」となりました。製造業の品質保証においてはソフトウェアは後からやってきたものになります。

一方でほかの分野に目を向けるとWikipediaの勘定系システムによると「銀行におけるコンピュータの利用は極めて早く、日本では1958年に三和銀行（現：三菱UFJ銀行）が導入したものが最初とされる。」という話で製造業と比べると10年以上先行しています。

また、ソフトウェア品質の歴史をたどっていくと第1回NATOソフトウェア工学会議でソフトウェア危機（1968年）があったり、日本ではSQiPの前身となるソフトウェア生産管理研究委員会の設置（日科技連・1980年）、JIS X 0129:1994、JIS X 25000:2010などを経て現在にいたります。システムおよびソフトウェア品質の国際的な基準の確立─日本主導の国際標準化への取組み─（込山 俊博、東 基衞・著、デジタルプラクティス 2019年）によるとソフトウェア品質の国際標準化は日本が主導して取り組んできたとのことです。

• 「ソフトウェア品質保証の役割と名称」に登場するベテランの製造業の方には、もともとある「品質保証」という言葉を後から使いだした人たちがそれまでと違う使い方をしているように見えたのではと思いました。
• 『「品質保証」はソフトウェア以外の分野でも長く使われている言葉』は時系列的には『「品質保証」はもともと製造業やハードウェアで使われていたのをソフトウェアでも使うようになった言葉』でしょう。
• ソフトウェア品質の国際標準化の経緯から製造業側だけでなくソフトウェア屋さん側にも強いこだわりや思い入れのある方がいても不思議ではないと思います。

2.5 管理システムと情報処理の違い

日本の品質管理はTQC、TQMを経て「JIS Q 9005 品質マネジメントシステム」としてJIS規格化されました。一方、ソフトウェア品質はISO/IEC 9126をJIS規格化した「JIS X 0129 ソフトウェア製品の品質」「JIS X 0133 ソフトウェア製品の評価」、ISO/IEC 25000をJIS規格化した「JIS X 25000 システム及びソフトウェア製品の品質要求及び評価（SQuaRE）」があります。よく見ると片方はQ（管理システム）、もう片方はX（情報処理）と分野が異なっています。

ソフトウェア品質保証の指すものが管理システムと情報処理で違っていたら齟齬を招いてもおかしくないでしょう。

2.6 社内における品証部門の位置づけの違い

各社の品証部長が語るソフト品質保証の取り組み（旧ソフトウェア品質保証部長の会・第1期3G・2010年）によると社内における品証部門の位置づけが3通り挙げられています。

①経営直轄型：事業部門から独立して、品質の砦として位置づけられる
②技術支援型：事業部門に対する全社的技術支援業務の一環
③事業部内型：事業部門内におかれ、事業特性に合わせた機能を持つ

また、ソフトウェア QA 最後の砦でGoogle検索すると、最後の砦からの脱却を目指す取り組みをされている組織もあることがわかります。

3. 製造業の品質保証とソフトウェア品質保証が違って見えるわけ

日本においては製造業の品質保証もソフトウェア品質保証も日本流の品質保証と思います。むしろどちらも日本流の品質保証だからこそ量産工程を伴う分野では齟齬が生じます。

量産工程を伴う分野では顧客が手にするのはハードウェアとソフトウェアが一体になった量産品（や、その量産品で利用するサービス⁷、付帯サービス）です。ソフトウェア品質保証は品質保証の対象をソフトウェアに限定しているがゆえにハードウェアとソフトウェアが一体不可分の量産品の品質保証ができず、品質保証の看板を掲げているのに品質保証をしないしできないという矛盾を呈します。例えば工場で量産した製品の出荷判定を量産品質の知見を持たないソフトウェア品質保証が担うのはナンセンスです。

一方で量産工程を伴わないソフトウェアに対して、量産品の出荷判定ができるといってもソフトウェア品質保証の知見がなければソフトウェアのリリース判定は難しいでしょう。

とはいえ、顧客が認識する価値は①製品そのものやその製品の関連サービス、②付帯サービス、③社会的価値の全部をひっくるめたものなので同じ組織内で「あなたのいう品質保証は私のそれとは違う」などと言っていてもしょうがないです。ハードウェア、ソフトウェア、量産のお互いの専門性を持ち寄って面でカバーする話です。

これはQAファンネル・QMファンネルでいえばQAプロモーターがハードウェア、ソフトウェア、量産で整合性をとりながらきちんと組織的な戦略を立ててQAを推進していく、あるいはJIS Q 9005:2023 品質マネジメントシステム―持続的成功の指針でいえば「4.2 顧客及び社会への価値提供における成功」を参考にしながらQMSを組んで回していくことが必要なのかなと思います。

4. おわりに

• 製造業のソフトウェア品質保証といってもその専門性で事業に貢献するのはほかの分野と変わらないです。
• 後工程に不良品を流出させないのはソフトウェアの設計品質、ハードウェアの設計品質、量産工程の量産品質のどれにも共通する目標ですがその手段はそれぞれ異なります。ソフトウェアがハードウェアに組み込まれて製造物となる分野で品証部門が出荷判定機能を持つ（＝出荷権限と責任を負う）ケースもあれば、ハードウェアを持たないソフトウェアやサービスの分野で出荷判定機能を持たず品質活動を推進するケースもあると思います。これは良し悪しや優劣ではなく扱っている商品や事業によって適したやり方が異なっているということです。
• 筆者が特に齟齬を感じないのはかつて組込み系プログラマだったときにハードウェアのエンジニアからリクエストをもらって機能実装をしたり量産立ち合いで工場の生産ラインへ足を運んでいた経験が役立っているように思います。ほんのちょっと相手の分野がわかるだけでも齟齬が緩和されるのではと思います。

1. 購入前サービスや購入後サービス ↩

2. CD-ROMなどに焼かれて量産品に同梱されるドライバやユーティリティソフトなどはひとまず割愛しファームウェアで代表します。 ↩

3. 日立の半導体部門とフラッシュメモリが起こしたマイコン革命（福田 昭・著、2018年）はソフトウェアをどのようにROMに組み込むかが年代ごとに紹介されていて興味深いです。 ↩

4. ファームウェアの不具合は量産移行判定までに摘出するのが原則です。生産ラインで行う検査はバグ出しのテストではなく、未知の不具合が生産ラインで発生すると生産ラインが止まる恐れがあります。 ↩

5. 沿革 - 品質管理なら日本科学技術連盟 ↩

6. AE-1の使用説明書によるとAE-1は「カメラでは世界初のCPU（中央演算ユニット）を内蔵し，露出の決定，記憶，信号発信，表示，時間制御，完了信号など，すべてを電子コントロールする，新しいタイプの一眼レフカメラ」とのことです。 ↩

7. 例えばスマートフォンのアプリストアサービス ↩