QA組織の意義と役割
昔、Qbookに連載をしたときにQAについて私の考えを書きました。
QAについて改めて自分の理解を深めようと思って、いくつかの記事、論文を読みましたので、感想とと共に読んだことを書いていきます。
日本の品質保証の歴史
まずはここから読みました。
品質保証の仕事として以下の3つが例で挙げられています
チェックリストが網羅されているか確認
要求が漏れにくい要件定義は何かを考える
適切なアーキテクチャーの良し悪しを見る
チェックリストの網羅を品質保証の仕事と考えていると、必要性も疑わしくなるねって書いてあります。そして、2つめと3つめはソフトウェアエンジニアリングを知らないとできないって書いてあります。
お、ソフトウェアエンジニアリングについては原典を読んだ感想をnoteを書きましたよ！
スライドの方に話を戻すと、日本的品質管理は「ルールを守らせることではなく改善をし続けること」であり、欧米型の品質保証は「プロセスを決めて守れば保証できる」だと、で、欧米型は幻想なのに広まってしまったって書いてあります。
品質保証の歴史学の最後のスライドにて、品質保証（プロセス改善）を詳しく知りたい方向けとして、「日本におけるソフトウェアプロセス改善の歴史的意義と今後の展開」という論文が紹介されていたので次はその論文を読みました。
https://www.juse.or.jp/sqip/squbok/file/squbok_rev2016_1.pdf#page=15
この論文では、日本のソフトウェア開発におけるプロセス改善の歴史を3つの期に分けて紹介していました。
1971-1990年：QC/TQCのような現場の課題を取り上げて現場で改善するスタイル、製造業をベースにしたがソフトウェア規模が小さいこともあり効果が出た。しかし、結果的に属人的になってしまった時期
1991-2006年：CMMIのようなモデルをベースに組織的にプロセス改善を進めるが形骸化した時期
2007-年：医療用や車載用など産業分野に特有のプロセスモデルへの特化、およびモデルベースから課題ベース(アジャイル開発のような改善をな内包するもの)への回帰をする時期
今後のプロセス改善の3つのの方向性として「組織(人)へのアプローチと技術の融合」，「人に着目した技術，実践的なアプローチの導入」「新たなアプローチ創出のための視点」が提示されています。
私は社会人になったのが1991年でIT業界入ったのが1997年なので、第一期は実体験してないですが、それでも最初に勤めた製造業ではQC活動ってしてたので私もやりました。後、ISO9000っていうのを取得する場面にも2回やった経験あり、形骸化するのは納得感あります。
プロセス改善モデルであるCMMI
そして、「そういえばあきやまさんがCMMIのこと書いてくれてたな」って思い出し、noteの連載を読みました。
CMMIとはSPA（ソフトウェアプロセスの評価）+SPI（ソフトウェアプロセスの改善）のやり方の一つ
CMMIの仕掛け
統計を使えるようにする
すべきことを伝えて、行動を変えさせ、それを習慣化させるゴールに向けて段階的に習得する
その活動が価値を生んでいるかどうかでそのレベルを達成しているかどうかを評定
この仕掛けがうまく使えなかったのが昔の日本の問題点で、本来の仕掛けをちゃんと使うとCMMIはちゃんと品質向上に寄与するんだろうなって思いました。
CMMIの目的は、開発部門の組織が持つ能力を向上し、スタッフ等の間接要員がいなくても、高品質のソフトウェアやサービスを生産性高く開発し、提供できるようになること
CMMIの目的を一言で言えば、「TQCを始めるため」であり、3つで言えば、「予測可能性の向上(Improve Predictability)」、「制御の向上(Improve Control)」、「効率の向上(Improve efìciecy)」
TQCって言ってるのは、最初のスライドで言ってた「日本的品質管理は「ルールを守らせることではなく改善をし続けること」のことだと思われます。ここで言う日本的品質管理は（QualityControl：QC）のことだからです。CMMIは開発するときに70年代の日本のQC/TQCを参考にしたとのことです。アジャイル開発も日本のカンバン方式とか参考にしているって聞いたことがあるので、外国の文献や事例をもとに輸入しているものの多くが元を正せば日本のやり方だって、なんか不思議ですね。
（ちょっと脱線）「日本におけるソフトウェアプロセス改善の歴史的意義と今後の展開」のリンク先の論文集には誉田さんのアジャイル開発のQAについて考察した論文も載ってるのですが、2015年より前の時点で、アジャイルはQAがテストして品質保証するのが多いってことが書いてあります。
欧米でのウォーターフォールモデルの品質保証はQAテストが中心であり、アジャイル品質保証の仕組みも、図3に代表されるQAテストを中心とした事例報告が多い
だから、QAがテストするって考え方もアジャイル開発と一緒で輸入ですよね。私が若いころ、テストだけやる独立チームっていうのは基本的には製造業からの流れをくんでる、組み込み開発がほとんどだったと思います。そのころって、ソフトウェア開発だけを見るとほぼ全て開発者がテストしてました。（脱線ここまで）
CMMIにおけるQA
CMMIではPPQA（プロダクトとプロセスの品質保証）というキーエリアとして登場します。
あきやまさんのnoteに昔のバージョンですがCMMIの日本語訳の紹介がありました。
https://insights.sei.cmu.edu/documents/86/2011_019_001_28778.pdf
PPQAの目的は「プロセスおよび関連する作業成果物に対する客観的見通しを提供すること」
その後もいろいろ書いてあるのですが軽いタッチで読み解くの難しいです。このまま書いてあることやるのは大変だなって思いました。前述した論文の中の以下の一文を思い出しました。
多くの日本の開発組織はSEI がまとめたCMM の理解とその文言通りの実施に注力してしまった点が現実である
ただ、だからダメってわけではなく自分達がCMMIを適用するときの具体的なやることは自分達で決めていくことが大事なので、そういう意味ではこの抽象度で書いてあることはそれで意義があるのだと思います。
清水さんの記事から学ぶQAの意義と役割
そこで清水吉男さんの「SQAの活用」という記事を思い出しました。（この記事のSQAとはSoftware QAのことなのでSがついてます）
この記事に書いてあること全てが素晴らしすぎて、とにかくリンク先を読んでもらえればそれで十分なのですが、私が感銘受けたところを引用します。
最初の計画段階で定義されているプロセスが実際の要求にマッチしておらず、成果物も特定されていないしサイズ見積もりも見当たらない、要件管理プロセスも確立していないような成功する見込みのないプロジェクトに対して、SQAが途中でプロセスと成果物を保証するための審査を行う意味はないのです。
私の解釈だと、プロセスや成果物が定義されていれば早い段階でQAメンバーが入り、内容をチェックしてフィードバックをするのは意味があるが、何もないところだと効果出すのも大変になるのでやらないほうがマシってなります。
そんな際にできるのは成果物のテストだけです。テスト結果がQA(客観的な見通し）を提示するための唯一の手段になってしまうんだろうなと。
私は、SQAに以下の「４つの役割」を求めています。
・ミツバチの役割
・ペースメーカーの役割
・ブレーキの役割
・コンサルタントの役割
これもなるほどなって感じです。
オリジナルの文章に全部かいてありますが、要約すると「ミツバチ＝横展開係」「ペースメーカー＝応援と励まし係」「ブレーキ＝立ち止まらせる係」「コンサルタント＝駆け込み寺係」です。
開発にてテスト計画がうまく作れなければ書き方をアドバイス（コンサル）して、うまく計画通り進めていれば褒めて（ペースメーカー）、不十分な状態でリリースしようとしてたら待ったをかけて（ブレーキ）、あるプロジェクトからの教訓を他のプロジェクトにも伝える（ミツバチ）ってことをQAにしてほしいって清水さんは言ってます。
しかし、これらの仕事ができるっていうのはテストの知識だけでなく、ソフトウェアエンジニアリング全般の知識必要だよなって思いました。
私は、「SQA」に「損失の発生を食い止める」あるいは「利益を上げる」という使命を与えることを勧めています。設計部門が売り上げを上げても、その何倍もの損失が発生したのでは無意味です。いや、無意味で済めば良いほうです。場合によってはビジネスの機会を失うことも有り得るのです。
「ソフトウェアの設計部門や開発部門は売り上げを上げる組織」で、「確かに、売り上げを上げる組織は重要」なのだけど、品質低下や問題の再発繰り返しのようなことをしていると、損失が増えて利益が減ってしまうので、損失を減らして利益向上に繋げることに対してミッションをもつのがQAの意義だと清水さんは言っています。
しつこく言うようですがオリジナルのほうにはたくさんいいことが書いてあるのでぜひ読んでください。
フィードバックがQAのメイン業務になりそう
私は、品質を良くしていくのはこの３つがうまく回るように常に改善ができることだと思います。
テストやレビューは、「可視化」のための手段です。そこでみつかった課題や不具合をチケットにするのは「フィードバック」です。「作り込み」はフィードバックを受けて適切に作ることです。
清水さんの記事にある「ミツバチ＝横展開係」「ペースメーカー＝応援と励まし係」「ブレーキ＝立ち止まらせる係」「コンサルタント＝駆け込み寺係」っていうのは全部「フィードバック」になり、結局「フィードバック」がQAの本来の仕事なのではないかと思いました。例えば、同じ問題が繰り返し起きてるのであればそういう情報もフィードバックが必要です。なのでこのサイクルでいうと、フィードバックがQAのメインの役割になりそうです。
フィードバックするためには可視化が必要で、テストやレビューをしたり、他にもメトリクスをとったりといったこともQAとしてやることがありますが、テストやレビューはあくまでQAにとっては手段です。（QAにテストを含める理由は、QAのアプローチにおけるテストの重要性が大きく影響しています。テストから得られたプロダクトの状況が、QAとして開発者など関係者にフィードバックする際にとても鮮度のよい正しい情報になり、QAとテストが密接に連携したほうが可視化からフィードバックまでが効率良く、やりやすいからです。ただし、「テストは手段」と言ってもテストはテストで技術力が必要な世界なのでとても奥深いです。）
話をもとに戻しますが、そして、この3つが回ることで、（これも清水さんの記事からですが）利益が前より向上するようになることがQAをする価値で、QA組織があれば、そこを目標にするのが良いのだろうと思いました。利益の向上は、具体的に言えば不具合の件数が減ることがその1つかもしれませんが、不具合でもSverity（重篤度）によって、損失リスクが異なるので、そういう目利きができるように認識合わせをするのも大事です。
さいごに
1日でいっぱい読んだので、忘れないようにnote書いたのですが、歴史から学ぶの大事だなっていうのと、清水さんやっぱすげーなって思いました。
秋山さんのCMMIのnoteの中では、以下の2つは感銘を受けました。
ソフトウェア開発のなかで真に創造的な活動に自分の能力をフル活用するために統計を使うことで楽ができる部分には使っていこう
企業側もソフトウェアプロセスを良くしていく事に取り組んで（投資して）ほしい
何でもかんでも統計的管理ができるわけではなく、統計を使うことで楽ができる部分に使えばいいんだっていうのが大事だと思います。全部できなきゃいけないわけではないっていうのがいいです。そして、プロセス改善なんかをするのは、本来の創造的な仕事を良くするためにやっているってことを忘れちゃいけないと思いました。たとえばfreeeのサービスってスモールビジネスをやる人たちが本来の仕事に力を注げるようにバックオフィスの仕事はサービスを入れて楽にしましょうって言う話をするのですが、全く一緒だなって。で、そのために投資をしたほうがよいのですが、予防コストだと思えばよくて、KPIには損失が減ることで利益にどれだけ貢献してるかを入れていくと良いのかと思いました。
以上。
サポートありがとうございます。これをカテにこれからも頑張ります。