ソフトウェア品質に関する実務的な書籍ってみかけない
こんな質問を受けたのですが、実際のところ、確かにソフトウェア品質に関する書籍ってあまり見かけません。いえ、あるにはあるんですけど実務的ではなく、どこか学術的で現場に落とし込んで実用するには、何段階もの解釈と応用を必要とします。
私自身も悩みましたけど、私が関わってきたＢ２Ｂ系の大手SIerが関与するプロジェクトを中心にして回答してみました。多少…清書、加筆加えています。
ここから回答
んー…『ソフトウェア開発』であれば、実務的なものはいくつかあると思います。
でも残念なことに『ソフトウェア品質』に限って言えば「書籍」そのものはあるんですけど、実務性の高いものはあまりない気がします。どれをとっても学術的な感じなんですよね。
もちろん、学術的な知識を身につけるのは間違いではありません。
ただ、学術的な内容のままでは、実践で有効活用できるレベルまで昇華するのはちょっと大変です。というのも、開発手法（開発モデル）によってまったく品質の考え方が変わってくるからです。特にＶ字モデルを継承したタイプの場合とアジャイルのようなタイプの場合では、ソフトウェア品質アプローチが全く異なります。
最近は、ソフトウェアテスト…中でも自動化手法や自動化ツールの運用による『効率化』に焦点が集まっています。自動化ツールを使えば人の手でテストするより、テスト自体の品質も保証できるうえに、圧倒的にコストも低減できるので、仕方がないことかもしれません。企業としては目先のコストが減った方が圧倒的に利益率が高くなった気がして飛びつきたくもなりますよね。
それに、優秀なディレクターと幾人かの中核を担うエンジニアがいれば、「品質保証」は無理でも、かなり高い品質管理が可能になります。そういうプロジェクトでは運よく不具合が出ない…という現場も多いでしょう。
ですので、流行ということもあって、自動化テスト系であればひょっとすると書籍も増えているかもしれませんね。
反して、
・設計品質（レビュー品質）
・製造品質
・テストケース品質
については、未だに属人性が高いのが現状です。
その背景には
「エンジニア一人ひとり、我流で自由に試行錯誤して開発するのが好き」
「そもそもソフトウェア開発企業自体、「品質」に対する意識が低い」
「エンジニアからたたき上げでマネージャーになる…という
レガシーなキャリアパスが未だに横行しているため
エンジニア時代の癖が抜けず、品質に対する理解度が低い」
という歴史が長く、まだまだ業界全体でもその重要性を意識した企業が圧倒的に少ないことにあります。少なくとも私がこれまでに所属していた４社、あるいはそれらの会社にいて取引してきたSIerのなかで、ソフトウェア品質という分野で尊敬できそうな人は１人もいませんでした（個人能力の高さで尊敬できる人は幾人もいましたけども）。
もちろん、ここ10年ほどでものすごく力を入れている企業も増えています。
・自社サービスや自社内製化が進んでいる企業
・医療や自動車ECU関係など、人命が関わる開発を行っている企業
人命が関わる業界では、そもそもISOなどの規格で必須化されており、品質を保証するプロセスが企業ごとに求められており、その認証がなければ開発する許可すら下りないケースもあるので、否応なく厳しくなります。
ですが残念ながら、大手SIerを含むＢ２Ｂ系のシステム開発系ではマネージャーもエンジニアも、そしてＱＡも、ソフトウェア品質を正しく理解している人は決して多くはありませんし、元請がそんな状態だと言いなりにならざるを得ない二次請け以降の企業でも浸透しないようです。
事実、Ｆ社、Ｎ社、Ｈ社、P社、etc.…様々な会社とお付き合いはありましたが、私の周りにはソフトウェア品質どころか、インプット・プロセス・アウトプットの因果関係すら理解されている方はいらっしゃいませんでした。中小企業でも上層部を担っている方々は、元は大手SIer出身とか、大手SIerの下請け出身の方が多いでしょうし、どうしても大手SIerの文化に近しい風土・文化を持っている企業が多いように感じます。
このように、業界全体が「ソフトウェア品質」に対してものすごく理解が薄く、やっと頭角を現してきたソフトウェアテストも比較的アジャイル向けに特化しているため、従来型の開発（ウォーターフォール）を行っている企業ではまったくと言っていいほど進歩しておらず、そういった実情から
「書籍化するほどのニーズが生まれない」
のが実態ではないでしょうか。読者のニーズもそうですけど、著者自体がそこにニーズを見出していない気がします。
前置きは長くなりましたが、設計側はともかく、ソフトウェアテストに限って言えば、まずはJSTQB監修または準拠の書籍がいいかもしれません。テスト手法に関して言えば、正しいことが書かれていますし、中には実用的な方法も記載されています。
ただし、テスト手法だけを学んだところで、それだけでテストというフェーズは完璧にはなれません。テストとはただのニーズに対する答え合わせです。
・テストケースが不完全なら、結局漏れます（テストケースの網羅）
・テストの実施内容を間違えたら、結局ダメです（テスト内容の妥当性）
・結果を見る箇所を誤ったら、保証になりません（テスト結果の適切性）
この３点をいかにして保証するか…その計画が立てられなければ意味がありません。テスト計画というと兎角「どの工程でどんなテストをするか？(WBS)」「スケジュールはどうするか？(ガントチャート)」の２点に絞られがちですが、それだけで品質が保証されることはありません。保証するためにはいかにしてMECE（漏れなくダブりなく）であるかを定義づけしなければならないのです。それができないテストは品質向上であっても、品質保証となることはありません。
このレベルになってくるとグッと学術的になってきて、普通のPGSEでは読むのでも大変かもしれません。
どれも現場のエンジニアやプログラマーでは読みにくい…と感じるでしょう。
また、多くのＩＴ業界人が忘れているのか、理解していないのか、ソフトウェア品質は『マネジメント』しないと上手く成立することができません。マネジメントできない人には、ソフトウェア品質の保証は難しいんです。
んー…わかりやすく言い換えるなら
『「ソフトウェア品質」活動の品質をマネジメントする』
ことが重要なんですよね。
でも、実際には多少理解が行き届いている現場でも、未だに
・有識者で検討する
・有識者がケースを洗い出す
・有識者がレビューする
といったことを行っています。人間が不完全な生き物である以上、人に依存した方法では
「その人の知識が偏っていたらどうすんの？」
「その人は一度覚えたことは一言一句違わずすべて覚えてんの？」
「その人がど忘れしたらどうすんの？」
「ど忘れしない保証は？」
といったリスクを解消できません。こうしたリスクを回避するために、企業によっては、過去の指摘・不良・バグなどをすべてデータ化して蓄積し、そこから傾向分析や対策方法を次に活かして、精度の高い品質保証方法をとっているところもあります（数は少ないでしょうけど）。
プロジェクトマネジメントの仕組みの中に
「品質を保証するためには、
どのような中間成果物が必要か？
どのようなプロセスで進めるべきか？
インプットとアウトプットの関連性に抜け・漏れはないか？
それらの関連性を紐づけるためのプロセスは必要十分か？」
と言った観点での構築ができていないと、「品質」を切り離して管理・運営しようとすると実現は難しいかもしれません。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。