品質保証における原則をソフトウェア開発に当てはめて考えてみる
はじめに
本記事は「新版品質保証ガイドブック」に記載のある、「品質保証に関わる原則」について、ソフトウェア開発の文脈でどのように関わりがあるかを検討するものです。
私自身はQAエンジニアではありますが、JIS認証に関わっているわけでもなければ、大学で学んだりしたわけでもない市井のQAです。
ですので、読者の方は決して鵜呑みにしないでいただきたいと思っています。
原著を読んだり、専門家の先生に習っていただき、きちんと学習していただきたいと思っています。
そもそもの品質保証の位置付け
品質保証やTQMについて、一言で表すことを避けている文献は多い印象です。
それは品質や、品質保証の概念は時代や価値観によって移り変わり、さまざまな変遷があるからだと考えます。
学習すればするほどさまざまな方面の事情がクリアになってくるからです。
本稿では、新版品質保証ガイドブックにある以下の記述を引用したいと思います。
顧客・社会のニーズを満たすことを確実にし、確認し、実証するために、組織が行う体系的活動
新版品質保証ガイドブック p15
QMSと日本的品質管理でも、品質保証の位置付けは違います。
本校は「新版品質保証ガイドブック」にあるように、日本的品質管理を下敷きにしています。
品質保証のかかわる原則
品質保証にかかわる原則はさまざまあり、「目的」「手段」「組織の運営」という3つの視点で語られています。
本稿では区別せずに語っていきます。
顧客重視（マーケットイン）
「顧客重視」という考え方があります。
これは提供側の技術や都合を優先するのではなく、あくまで顧客のニーズを第一にして製品を提供していくという行動原則です。
いわゆる「マーケットイン」と「プロダクトアウト」の対立軸で語られる「マーケットイン」が含まれています。
現在ではこららの対立軸は否定的に受け止められることが多いと思いますが、過去はむしろプロダクトアウトを批判する文脈でマーケットインという言葉が使われていたことが伺えます。
なにより「顧客のニーズを満たす」ということは「顧客重視」という原則に現れていると思います。
これはアジャイル開発宣言の「顧客との協調」にも示される通り、今でも通用する価値観だと思います。
後工程はお客さま
お客さまと接触することの少ない部門やロールの人は、「顧客重視」の原則への意識が、薄くなることがあります。
その場合は、「後工程」の人をお客さまと捉えることもいい考えだということがあります。
後工程をお客さまと捉えることで、組織の隅から隅まで「顧客重視」という品質保証の原則を行き渡らせる狙いがあるようです。
ソフトウェア開発だと顧客と協調していることは多いですが、設計と実装が分業している場合や、devとopsが分離している場合は、これらの考えは活かせると考えます。
後工程の人々のことを考えた設計や実装やドキュメントが、実際の顧客満足に繋げることができることは想像に難しくないと思います。
私は本当の顧客や社会のことを重視していきたいですが、これをみても品質保証の原則はある種のやさしさがあるなあと思ったのでした。
プロセス重視
結果のみを重視するのではなく、結果が生み出されるプロセスにも着目して、管理していこうという原則です。
「プロセス」とは、仕事を行なう方法や仕組みのことです。
一見アジャイルっぽくなくて嫌な気持ちになる人はいるかもしれませんが、私はむしろあとで語られる源流管理やPDCAサイクルを実現するための、前提となる考え方と捉えました。
伝統的なプロセスを守り続けるよりも、よりよいプロセスを模索し続ける必要があるのだと考えます。
「プロセス」とは属人化した職人技から脱して、組織的に品質を保証するための大きな武器だと思っています。
ソフトウェアエンジニアとして、個人の創意工夫や自発的なアイデアを尊重しながら、プロセスとして強くしていく、
そんなQAエンジニアがイケていると私は考えます。
標準化
組織で仕事をする場合、各人が勝手に行動するとどうしても結果のばらつきができてしまいます。
なので、その時点でもっとも優れた方法を標準として定めて、行動するという原則です。
標準化の目的・役割は複数あります。
- 互換性の確保
- 思考・情報伝達の省略
- 信頼性・安全性の向上
- 改善の促進
「標準化」でもウッってなる人はいると思います。
ただ、ソフトウェア開発でも標準化はあります。
リポジトリを使っている場合、git flowなどがそれにあたりますし、ドメインモデリングなどの技法を使っている場合も同様です。
コーディング規約があったり、lintなどを使ってCIで怒られる体験をしている人も多いでしょう。
標準は常に見直される余地があるべきであることとして語られています。
標準化により、技術レベルが向上し、改善に取り組めることが示唆されています。
源流管理
「源流管理」とは仕事の流れの上流に遡って、顧客が満足する製品やサービスを考えて管理していこうというものです。
昨今ソフトウェア開発で言われている「シフトレフト」はそもそも品質管理では当たり前の原則なのです。
最近はアーキテクチャやプロダクトマネジメントへの注目がされているように見えますが、私は源流管理の流れの1つなのではないかと思っています。
PDCAサイクル
説明不要ですよね。
スクラムをはじめとした反復型開発では通じるところが多いと思います。
人間が考えるプロセスは不完全であり、最初から完璧なものを確立することは難しいという前提に立っています。
また、PDCAサイクル自体も、「確実かつ継続的に」回すことを良しとしています。
現実に基づいて学び・修正していくというアプローチは現代でも通用する考えだと思います。
再発防止と未然防止
「再発防止」とは、問題が発生したときに二度と問題が起きないようにするという考え方です。
「未然防止」とは、問題が発生する前にトラブルを予測して対策しておこうという考え方です。
これは現場によってはある「ポストモーテム」や「リスクマネジメント」が対応するように思えます。
私は大切だとは思いますが、アジャイルやソフトウェア開発一般のプラクティスとして指示されているかというと少し自信がないです。
ご存じの方はコメントなどで教えてほしいです。
潜在トラブル・潜在ロスの顕在化
クレームなどのトラブルや見えているロスは氷山の一角にすぎないため、積極的にみつけていって予防しようという考え方です。
ヒヤリハットの活用がこれにあたるとのことです。
ソフトウェア開発だと、カオスエンジニアリングなどが該当するかもしれないですね。
これについても、何かソフトウェア開発の事例があれば教えて欲しいです。
結果にもとづく管理（目的志向）
「結果にもとづく管理」とは、プロセスの結果（および目的）に着目してそれに基づいてプロセスの議論をしようという行動原則です。
常により高次の目的は何かを考え、その目的に沿って行なっていることや行なおうとしていることの適切さを判断することが大切とのことです。
アジャイル開発ではインセプションデッキなどさまざまなプラクティスで「目的」を意識するようにできていると思っています。
アウトプットよりもアウトカムという風潮も結果に基づく管理と近いと考えます。
「ゴールは何か？」を常に意識することが、品質管理において大事ということですね。
重点志向
重点志向とは、無数にある問題のなかで、もっとも重要な問題に着手しようとする考え方です。
これはアジャイルのバックログリファインメントなどにも通じますが、TOCなどの手法にも通じるものかもしれないですね。
限られたリソースのなかで、より大きな顧客価値を届けるために頑張るソフトウェア開発と相性のいい原則だと思います。
事実にもとづく管理（ファクトコントロール）
勘や経験にのみ頼るのではなく、データや事実に基づいて管理するとう原則です。
事実を正しく把握して、正しく判断する。そのために現場・現物・現実の三現主義や統計的手法を用いようという考え方です。
品質管理の発展は統計的手法に支えられたといっても過言ではないと思います。
ソフトウェア開発において、データや事実に基づいて管理するという考えは正しいと思います。
一方で、統計的手法がソフトウェアに必ずしも当てはまるかというと、そうでもないと考える人はいるかもしれないですね。
全員参加
さまざまな専門性の人が、組織全体の目的に向けて、1人1人の役割や能力を十分に発揮するという意味の全員参加です。
ソフトウェア開発において、チーム開発で頑張っていこうというのは大きな流れかと思います。
また、XPにおけるWhole Team Approachと同じではないでしょうか。
とくに私はテスターであり、QAでもあるので、全員参加として尊重されることは嬉しいです。
人間性尊重
人間らしさ、つまり感情・英知・想像力・企画力・判断力・行動力・指導力などの能力をフル活用するようにという原則です。
マズローの欲求の「自己実現」に達して、1人1人が充実して挑戦できるような課題に取り組むことが品質管理において大切だということです。
これはまさにソフトウェア開発における前提な気もします。
ソフトウェア開発だけではありませんが、ソフトウェア開発はとくに、現在のところは知的な活動なので、個人のマインドセットやモチベーションが重要になります。
教育・訓練の重視
組織の発展を支えるために、1人1人の能力を長期的な視野に立って伸ばそうという考え方です。
現在の大企業でもありますが、かつては終身雇用などを支える原則であったと思います。
キャリアパスを考えることも重要だと思います。
これは、ソフトウェア開発だと微妙な気がしますね。
やはりまだまだ中途採用や転職が前提の雇用になっていると思わなくもありません。
一方で、コミュニティが人を育ている側面はあると思います。
つまり、日本のコミュニティが日本の品質管理を育てている。なんちゃって。
参考文献
- 新版品質保証ガイドブック、（社）日本品質管理学会、2009年、日科技連出版社
- マネジメントシステムの審査・評価に携わる人のためのTQMの基本、（社）日本品質管理学会標準委員会、2008年、日科技連出版社
Discussion