「リリカルの質問全部答えます」 参加レポート （主に品質保証の歴史学）

はじめに ● このスライドは、2018年1月9日に行われたイベント 「リリカルの質問全部答えます」の参加者が、 登壇者の発言内容を勝手にまとめたものです。 ● イベント告知ページはこちら。 – https://connpass.com/event/74455/ ● イベント当日のツイートのまとめはこちら。 – https://togetter.com/li/1188522

イベントの主旨 ● リリカルさんという類稀なる人物が用意した質問に、 にしさんとみっきーさんがどんどん答えていくイベント。 ● 用意していた質問集はコチラに書いてあります。 – http://mhlyc.hatenablog.com/entry/2018/01/ 09/181952 ● 今回は色々話した中で、品質保証にまつわる歴史が 大変興味深かったので、その部分を共有。

"品質保証"という仕事について ● [質問]なぜ品質保証が必要なのですか？ ● 「品質保証」といっても、実は色々な仕事がある。 – チェックリストを網羅しているかどうか確認する。 ● 一般的にイメージしがちな品質保証のお仕事。 ● この仕事のみをイメージしたうえでの質問なのでは？ – 要求が漏れにくいような要件定義は何か考える。 – 適切なアーキテクチャの良し悪しを見る。 ● この2つはソフトウェアエンジニアリングを知らないとできない仕事。 ● これらを行うためには勉強し続ける必要がある。

日本的品質管理 ● ソフトウェア業界では、品質保証を理解していない 品質保証の担当者や責任者が多い。 ● 戦後間もない頃から日本がやっていたのは品質管理。 – 最初は工場での不良品撲滅で、そこから設計の質を向上し、 そして価値の高いものを企画する必要があると考え始めた。 – 管理というのは、ルールを守らせることではなくて、 きちんと改善し続けること。 ● これが日本的品質管理。 – プロセスを決めて守れば品質が上がるという思想ではない。

欧米型品質保証とISO9001 ● 一方、1980年代の欧米では、 発注通りに作られない現状を見て、 「これをやれ、こうやってチェックしてマニュアルを作って」 というのを合意・監査する必要があると考えた。 – これが欧米型品質保証。 ● 欧米型品質保証では、 「2社間で合意したものをちゃんとやってますよね」 ということを監査する必要があった。 ● この監査の部分を1980年代にイギリスの提案で 国際標準化したのが（当時の）ISO9001。

汎用機系品質保証は欧米型 ● 今、ソフトウェア業界で「品質保証はこうやれば良い」と 言っているものの殆どは、汎用機向けソフトウェアの 品質保証のための方法論でしかない。 – 同じようなソフトウェアを同じ人たちが 同じように作り続ける場合に最適。 – 汎用機向け品質保証の方法論は 欧米型品質保証のように聞こえる。 ● 今は汎用機向けソフトウェアと同じ作り方をしないことが ほとんどなので、汎用機向けソフトウェアの品質保証 のための方法論ではうまくいかない。

欧米型品質保証という幻想 ● 汎用機から脱する時期（1980年代後半～90年代前半）に、 ちょうど、ISO9001の流行や 日本版CMM（レベル3を政府調達基準とする動き） といったプロセス品質が流行し、 ソフトウェア業界で「品質保証」という言葉が注目された。 – プロセスを決めて守れば品質は「保証」できる、 という欧米型品質保証的なクソのような幻想が広まった。 – その幻想は汎用機向けソフトウェアの品質保証の方法論と 同じに聞こえた。 – 品質保証部は、ソフトウェア開発技術に通じていなくても プロセスの（はんこ、もしくはメトリクスによる）監査はできるので、 とても楽な仕事ができると喜んだ。

日本的品質管理は誤解された ● 以前から日本的品質管理をよく理解していた人たちは、 「プロセスを決めるというのは仕事の順番を決めることだけではない。 そんなのごく一部でしかない。 だってそれだと品質を保証できないでしょ？」 と主張していたが、その話を聞く人は少なかった。 – 開発技術やノウハウ、ツールも含めて決めなければ、 品質の高いソフトウェアなど作れるわけがない。 – ハードウェアの日本的品質管理の専門家は プロセスも開発技術もノウハウもツールも全て含めて 「標準を定めて改善のサイクルを回せ」と言う。 – しかしソフトウェアの品質保証の自称専門家たちは、標準はプロセスであり、 プロセスは仕事の順番のみだと誤解した。 だから彼らは「ハードウェアの日本的品質管理の専門家が行っているようにやっ ている」と誤解した。

“標準”について ● [質問]標準は必要なのでしょうか？ ● 「標準」と一言でいっても、色々ある。 ● 強制の度合い – 厳守 – 目標 ● 標準の種類 – 技術的な標準 ● SQL標準 – 工程的な標準 ● 手順系 ● 目標であることが多いが、会社によってはゲートチェックしていることも。

標準が機能する条件 ● 標準が機能するには3つの条件がある。 – 1. どうやればよいかが明確であること – 2. それが当分変わらない、 　　もしくは同じ標準を色々なものに適用できること – 3. 使っている人が良いやり方だと思えること ● ソフトウェアの場合、1つ目が上手く行かない。 – 同じ結果に対して色々なやり方があるから。 ● ただし、アンチパターンは示せる。 – どうやってはいけないか、は明確に示せる。

品質保証部とプロセス ● 限りなく成功するプロジェクトの場合、要件定義が終わった 段階で、プロセス設計を必ずやっている。 – このプロセス設計では仕事の順序を決めるだけではなく、 どのような開発技術やノウハウ、ツールが必要なのかも十分検討する。 ● その際、会社のプロセス標準は守った体にしたりする。 – この「会社のプロセス標準」には仕事の順序しか定義されていない。 ● 問題なのはそこに品質保証部が関与しないこと。 – 品質保証部にはプロセス設計結果のうち仕事の順序しか届かない。 – どういうプロセスになったかは分かるけど、どうしてこのプロセスになったのか 分からない。だから、本来は横展開もできない。 ● ただ、品質保証部は「上手くいったなら、他でも上手くいく」 と信じているから、そのまま横展開に持っていってしまう。

プロジェクトマネジメントブーム ● 以前は同じお客さんに同じ開発者がずっと貼りついていた。 阿吽でできるため管理技術が弱くなってしまった。 ● そこでバブル崩壊後は、マネジメントを鍛えようという風潮になり、1990 年代後半にプロジェクトマネジメントブームが起きる。 ● ソフトウェアとはプロジェクトであるという刷り込みが発生した。 – プロジェクトの成功ばかり考えて、組織能力を高めるという発想が乏しくなり、 開発技術や品質がどんどん低下していった。 – 下請けは下請けで、毎回違う顧客相手なので手を抜くようになった。 – そのため、安請けが儲かり、モラルハザードが起きた。 ● さらに2000年代にはコンプライアンスブームが来て、 それもプロセス監査にマッチしてしまった。 – コンプライアンスは守ることが目的であり、改善が目的ではない。

品質保証について詳しく知りたい方へ ● 品質保証（ソフトウェアプロセス改善）の 歴史については、以下の文献が参考になります。 – 『日本におけるソフトウェアプロセス改善の歴史的意義と今 後の展開』 ● SQuBOK Review Vol.1(2016)に掲載 ● http://www.juse.or.jp/sqip/squbok/squbok_review. html