はじめに

SQuBOK V2読破会アドベントカレンダー20日目のブログエントリーです。 www.adventar.org

SQuBOKというのはこれです。ソフトウェア品質知識体系ガイド。 Google Books で一部を読むことができます。

books.google.co.jp

SQuBOK V2の章構成は2章のマネジメントが中心

SQuBOK V2読破会では文字通りSQuBOK V2を全て読みました。理解が不十分な知識領域も多くありますが、少なくともソフトウェア品質に関係する知識領域が何なのかを広く認識できるようになりました。

そこで、改めてSQuBOKの構成を全体的に見つめなおしてみることにしました。各知識領域について知っているかどうかは、以前のエントリー SQuBOKによる無知の知の体験 - MassKaneko.Out で書きましたので、もっとメタに捉えてみることにしました。

第1章：ソフトウェア品質の基本概念
- 良い品質とは何なのかは製品や時代によって変わる
- ソフトウェアの品質には色々な側面がある
- 良い仕事の仕方が良い品質を生む
第2章：ソフトウェア品質マネジメント
- ソフトウェア品質マネジメントとは品質管理ではなく、manage本来の意味である"なんとかしてやる"という意味である。つまり、なんとかして目標とするレベルの品質に押し上げる・持続的に改善するための活動である。
- 開発やテストだけでなく間接的なもの含めてあらゆるアクティビティがソフトウェア品質に関わるため、それらはソフトウェア品質向上のためのマネジメントの対象となる。
- プロジェクト固有のマネジメント、プロジェクトに依らない共通のマネジメント、プロジェクトレベルを超えた組織レベルのソフトウェア品質マネジメントがある。ソフトウェア品質技術者だけが努力すれば良いわけではない。
第3章：ソフトウェア品質技術
- 品質を作りこんだり確認するためのテクニックやツールが色々ある

できるだけ短く書いてみました。こうして考えてみると、第2章が中心の本なのだなと思います。プログラマーやテスターからすると、品質を向上するためには第3章の内容が中心となって見えます。それは開発技術やテスト技術ですから、それはそれで閉じているわけです。

しかし品質を上げるために"なんとかできること"とは開発とテストだけではないわけで、マネジメントという概念を持ち出した時点で第3章は主役ではなくなるのです。そして、ソフトウェア品質マネジメントのことを書こうとすると必然的に「ソフトウェア品質とは」という第1章を書かざるを得なくなる。だから、この順番の章構成なのだと考えます。SQuBOKを読む前は「はぁあああ？？2章がマネジメントぉぉぉ？？？なんだよ結局品質管理屋のための本かよー。一生マネジメントでもプロセス改善(笑)でもやってればいいじゃん。そんなことしてる間にテクノロジーで遅れを取っていくんだよ。」と思っていましたが、1年前に比べればだいぶ考えがニュートラルに是正されてきたことを実感しています。もちろん直接的にソフトウェアの品質を決めるのはコードですし、欠陥を見つけるのはテストですが、それらの活動を満足に行うためにできることが沢山あるということです。

品質から経営の世界へ

ソフトウェア品質を真正面に考えるのであれば経営やマーケットの世界に足を踏み入れる必要がある。最近、そう思います。

一つは先ほど書いたマネジメントの話の延長線上にあることで、技術職以外の努力が必要となる領域を考えると次に管理職の努力が必要となる領域が思いつきますが、第2章にあるマネジメントを考えるとなるとプロジェクトマネージャー・プロダクトマネージャーよりも更に上位のレベルのマネジメントが必要となることが考えられます。例えば、会社組織における品質マネジメントシステムを構築したり、プロダクトのライフサイクル全体を考えたり、ソフトウェアプロダクトラインを考えたりといったことは、一定以上の規模の会社組織においては一管理職にはできることではなく、経営者の努力が必要となる領域だと思うのです。経営となるとソフトウェア品質だけに思慮を巡らせるわけにはいかなくなり、経済的合理性という側面からソフトウェア品質を考えることになります。

そうなるとソフトウェアやコンピューターの世界から経営の世界に足を踏み入れざるを得ないわけです。会社組織ぐるみでないと行えない品質マネジメント活動に一体どのような経済的合理性があるのかを考えないといけなくなります。しかもそれらの活動は本質的には投資であり、金銭的価値に換算することは難しいのです。かといって技術者に「投資対効果を示せ」と言ったのではその経営者は無能であることを自白しているに等しくなります。言い方を変えれば「私には品質マネジメント活動の価値がわからないから小学生でもわかる不等式で説明してくれ」と言っているに等しいのですから。

SQuBOKの巻頭にある"本書の利用方法"には、利用者層ごとのSQuBOKの利用方法について書かれています。開発者・品質保証・管理者などの職種別に書かれていますが、実は最初に述べられている利用者は 経営層 なのです。ソフトウェアがプロダクト・サービスの価値を大きく決める事業を行う経営層といっても必ずしもソフトウェアの専門家ではないでしょうし、専門家でなければならないということは無いと思います。しかし、少なくともどのようなトップマネジメントがソフトウェアの品質向上のために効くかということは、ソフトウェアがプロダクト・サービスの価値を大きく決める事業を行うのであれば…技術者のように論理立てて説明できなくとも、直感的に適切な選択肢を選ぶことができる必要があると思うのです。論理立てて説明できなくとも、概ね正しい直感を信じて迅速な意思決定ができる権限があるのは経営者だけだと思うのです。そして、ソフトウェア品質の専門家はそうしたトップマネジメントができるように経営層を技術面で支えたり、意思決定の根拠となる新鮮で正確な情報を集めたりできることが望ましい協力関係ではないかと思います。

品質からマーケットの世界へ

ソフトウェア品質と経済的合理性の関係は、欠陥や工数が少なくなること以外に、売り上げに対する関係も考えられます。すなわち、ソフトウェア品質を正面から考えるのであれば、いいものを作れば売れるのかどうかの問いに辿り着くということです。しかし、このブログを書いてる現在、"いいものを作れば売れる" でググると、そうではないという旨の文章が複数ヒットします。私はまだその答えを出せるほど品質の知識もマーケットの知識も無いのですが、思うに、"いいものを作れば売れるわけではない" かどうかの話は、 "いい" とは何なのかに踏み込みが浅いのではないでしょうか。

高機能・高性能・高信頼な製品が売れる時代は過ぎ去り、モノづくりからコトづくりの時代に変わったという論旨を、ここ数年で経済誌や講演で見かけるようになりました。昨年のソフトウェア品質シンポジウムでも触れられていました。ビジネスが変わればソフトウェアの品質も変わる。ソフトウェアがビジネスの鍵を握る時代の新しい品質とは。ソフトウェア品質シンポジウム 2014 － Publickey

これは "いい" とは何かが変わったということです。もう少し言うと、機能・性能・信頼性という製品の品質から、UXや安全性といった利用時の品質にユーザーの関心が移ったということなのだと思います。

もし "いいものを作れば売れるわけではない" という論旨における "いい" というのが高機能・高性能・高信頼のことであり、そう主張する人々がマーケターで、"良さ" を追い求めていたのが技術者だとしたら、マーケターと技術者が合わせて "いい" とは何なのかを共有する場が足りていないのではないでしょうか。

製品・サービスの "良さ" を考える(決める)ということはすなわち半分くらいは商品企画をするということだと思います。これまでは、商品企画というのは今まではマーケターの仕事というイメージがあったと思います。そしてこれからは、ソフトウェアが価値を大きく決める製品においては、品質に関する知識のあるソフトウェア技術者が商品企画の領域に切り込んでゆく余地があるのではないでしょうか。そうすれば "いいものを作れば売れるわけではない" から "ユーザーにとって価値があるものを作ることが売れることの第一条件だ" に進歩できるはずです。そう、売りたいマーケターと技術に触れたい技術者の間を取り持つのはユーザーに価値を届けることだと思うのです。そこだけは両職種に共通するところだと思います。今のソフトウェア品質体系は、良さとは何かをマーケターと共に決めることができるくらいに成熟していると思います。だから、もし良さとマーケターが中心となって決めているのであれば、そこにソフトウェア技術者が協力できることがあると思うのです。また、ユーザーに価値を届けずに売り上げを立てようと企てるマーケターや、ユーザーに届ける価値を考えずに提示された要求仕様を実現することだけしか考えないプログラマーを是正して、ユーザーに届ける価値を中心に仕事をする啓蒙活動を行う役割も必要となり、それを品質のわかるソフトウェア技術者やマーケターが担う可能性もあるでしょう。そういう意味で、ソフトウェア品質に携わる技術者はソフトウェア品質という技術の世界からマーケットの世界に足を踏み入れる余地があるのだと思います。