私の思うQAの全体像を語るシリーズ第三弾です。
前作：私の思うQAの全体像 ver.2 - mhlyc -practice
いただいたコメントを参考に見直しました。でも悪い意味でブログ慣れしてて、一見読みやすそうに思えるけど実は書きなぐりで、全体像が全く見えてこない。だから、この内容で構わないから、体系的に整理してみません？ RT こないだよりずいぶんよくなったよね。(^_^) RT @mhlyc: 第二版…
— Yasuharu NISHI (@YasuharuNishi) 2018年10月18日
※遅くなってすみません
体系的に整理するとは
体系的に整理するにはまず何かしらの体系にあたる必要があります。 品質保証の体系といえばこれ。
SQuBOKを参考に整理する方法を考えてみました。
整理方法の案1：ソフトウェア品質モデルベースで整理する
ソフトウェア品質モデルは、プロダクトやシステムの品質を考えるには良いモデルなのですが、それを取り巻く開発現場の状況など広げて考えるには不向きかもしれないと思いました。
整理方法の案2：SQuBOK樹形図より、ソフトウェア品質マネジメントの章にマッピング
ちょっと大変そうですが、こちらの方がより体系ぽく整理できそうな気がします。こちらで整理してみることにしましょう。
ロジカルシンキングは全然得意ではありませんが、今回はアドバイスをもとにマインドマップを使って整理してみることにします。整理されてなーい。
— あきやま🍠 (@akiyama924) 2018年10月18日
って思ったら、にしさんも「体系的に、、、」ってアドバイスしていた。マインドマップやロジカルシンキング得意なんでしょう？ああいうので今回書いたブログを分解してまとめ直すと良い（良いものができるではなくてリリカルさんの考えていることが通じやすくなる）と思いました。
SQuBOKの章をマインドマップのブランチにしてみる
まずSQuBOKの章をマインドマップのブランチにしてみることにしました。
弱点分野が明らかになる
章を全体で見渡してみると自分の理解度が足りていないところが多くあることに気がつきました。
ソフトウェア品質マネジメントシステムの構築と運用
そもそも品質マネジメントシステム、QMSという言葉にあまり馴染みがありません。普段自分がやっていない業務だからかもしれません。
品質マネジメントシステムとは一体なんなのでしょうか？ マネジメントシステムとはなんなのでしょうか？ ここでは、少し話がそれますがQMSについて考えてみたいと思います。
今まではQMSは「標準に則った監査〜対策実施〜再発防止」というサイクルの繰り返しでしかないと思っていたのですが、そうではないと今は思っています。
「QMSは継続的な品質改善を可能とするためのシステム」というのが今の私の理解です。 QMSこそが、実はQAの真骨頂なのではないかと思いました。QMS無くして品質保証はできないと思います。
しかしながら、簡単に実現できるものでもないと思います。 正直、QMSを機能させるためにはどうしたらいいのか、結構考えてみましたが、思いつきませんでした。というのも、QMSというのはシステムとして機能させなくては意味がなくて、システムとして機能させるというのは単に仕組みを作っておしまいというのではなくて、開発者やQAを含めたメンバー全員による継続的かつ組織的な品質改善を必要とします。どうしたらそれができるか、難しくてすぐに答えは出ませんでした。引き続き考えようと思います。
ライフサイクルプロセスのマネジメント
ライフサイクルプロセスのマネジメントは、おそらくライフサイクルの初めから終わりまででは、関わる人が様々であるからこそ生まれたものなのではないでしょうか。 例えば、企画を担当する人と保守を担当する人が同じ人とは限りません。そう言った、同じ製品には関わるものの関与するタイミングが異なるような場合において、拠り所となるようなライフサイクルプロセスモデルがあるといいのかなと思いました。
また、これは当たり前ですが自分が経験しているライフサイクルプロセスについては理解が深いものの、他の未経験のものについてはいまいちイメージがわかないところがあります。
ソフトウェアプロセス改善のマネジメント
これも、QMSと似た話なのかなと思いました。もちろんプロセスのメトリクスを採取するといった仕組み的な部分もありますが、それだけではうまく回らないはずです。改善の文化を根付かせていくという方向性でも考えていく必要があるのではないでしょうか。そうでないと、せっかくメトリクスを取ることにしてもメトリクスを取得する目的がブレてしまったり、うまく改善に繋げられなくなってしまうと思います。
検査のマネジメント
ここでいう検査はいわゆるリリース前のテストで合否判定をすることをいっていると思います。もちろん、出口検査となってしまっては手戻りの工数がかかりますから、早期から品質を確保するような施策が必要となるでしょう。リリース可否の基準が明確に決まっていることはもちろん、第三者的な確認ができるかどうかも重要です。（チェックがなあなあになって、なし崩し的にリリースすることがないようにすべきです）
監査のマネジメント
監査は何かしらの基準や規格がある前提で行われます。なぜ監査が必要なのでしょうか。その目的はやはりプロセスの改善ではないかと思います。また、監査による重要なメリットの一つが、規範の遵守を証明して、信頼感を付与するということだと思います。CMMIやISOシリーズなども、こういった側面もあるかもしれません。
ただしここでも、重要なのは単なる規格に対する機械的な確認に留まらず、本質的な改善を目指すということだと思います。例えば、そもそものプロセスがイケてないのにそれに合致していることを監査したところであまり有効とは思えません。
教育・育成のマネジメント
これが重要なのは、言わずもがなでしょう。教育・育成を効果的に行うために、いくつものスキル標準が定められています。短期的に目の前の仕事をこなしていくのではなくて、長期的な目線で必要な人材が育成できているか、育成の計画が立てられているか検討すべきでしょう。
法的権利、法的責任のマネジメント
特許法、OSSと著作権法、不正アクセス禁止法、製造物責任法などソフトウェア開発において押さえておくべき法規があります。特にOSSライセンスの遵守や不正アクセス禁止法については、実際の実装にも関わる部分なのでソースコードに触れる全員が知っておくべきでしょう。
次回に向けて
次回は、今回の内容を踏まえて理解が足りない、もっと調べたいと思う部分を掘り下げていきたいと思います。（おそらく、QMSとソフトウェアプロセス改善の話になると思います…。）
