QC2QC時代にエンジニアとビジネスリーダーが紡ぐ「品質文化」とは#１

現在のビジネスにソフトウェアは欠かせず、その品質はビジネス全体を左右するほど重要である。従来のプロダクトに閉じた品質と異なる点は、エンジニアとビジネスリーダーが真に協力し全体を理解しなければならないことだ。本稿では、「品質」を決定する「品質文化」とは何かを紹介する。（全2回、前編）

※本記事は、GLOBIS Insightsに掲載した記事を翻訳し再編集しています。

現代のビジネスはソフトウェア抜きでは語れない。GLOBIS知見録でも過去にお伝えしたように、田川欣也氏が書籍『イノベーション・スキルセット』で掲げたBTC型人材（ビジネス・テクノロジー・クリエイティブの知見を横断的に活用するビジネスパーソン）の重要性が高まる中、本稿では特にビジネスとテクノロジーに着目したい。

すなわち、ビジネス知識をプロダクト開発に生かすソフトウェアエンジニア（以下、エンジニア）や、テクノロジーの潮流を捉え意思決定につなげるビジネスパーソンが活躍し始めているのだ。このような背景から、ソフトウェア品質（以下、品質）は今や企業の存続、それもあらゆる企業の存続を左右する論点となった。品質はプロダクトだけでなく、ビジネスそのものに関わるものになったのだ。

さて、品質はどこからもたらされるのだろうか？

その答えが本稿で扱う「品質文化」だ。

エンジニアたちは品質文化とは何か、長年議論を重ねてきた。ところが、いまだに唯一の正解は見つかってはいない。シンプルにテスト（ソフトウェアテスト）が実施されていることが品質文化のあらわれであると考える人もいれば、組織や戦略と結びつけて議論する人もいる。

そこで、本稿では、過去と現在の「品質」の意味するところの違い、組織文化と品質文化との関係性などから、品質文化とは何かを紐解いていく。

品質を実現・維持するための方法論に踏み込む前に、まずは「品質」という言葉が何を意味するかを知ることが重要である。

「品質」という用語はあいまいであり、様々な意味で使われているため、注意して用いるべきだ。「総合的品質マネジメント（TQM）」などの理論・体系をしっかり学んできた人材を除くと、品質とは何かを真剣に考えたことがあると言えるエンジニアは少ないのではないか。QA（Quality Assurance：品質保証）エンジニアなど、品質を専門とするエンジニアでさえ「品質」という言葉を振りかざしながら、品質を向上させるにはプロダクト（ソフトウェア製品）をテストしさえすればよい、などと考えていたりする。

こうした実状に対し、筆者は長年、品質はプロダクトのためだけの概念ではないと捉え、むしろプロダクトを作る人や組織にも拡張して品質というものに目を向ける必要があるのではないかと考えてきた。

こうした背景から「品質管理から品質文化へ（Quality Control to Quality Culture）」すなわち「QC2QC」という概念を提唱するに至ったのである。

「品質管理」という概念は、19世紀イギリスの産業革命に始まる工業化の時代に、フレデリック・テイラーが人間観察と人間理解に基づいてまとめた『科学的管理法（The Principles of Scientific Management）』に端を発し、以来、経済・国力の発展における重要な役割を担ってきた。時代とともに進化し、統計学の知見を用いて不具合（バグ）を見つけるため、品質を専門とするエンジニアが設計したテストシナリオ（ユーザーがどのようにプロダクトを使うかを想定して作成されるテスト手順書）などを基準として、かなり網羅的にプロダクトを検証するなどの手法が含まれるようになった。

品質管理が有効に機能するためには、前提としてビジネス環境が安定していること、業務がマニュアル化されていることが必要となる。過去、日本の製造業が品質を管理し、最高の製品を生産し続けてきた、その原動力のひとつだった。この時代、品質に要求される水準は一定で、わざわざ議論しなくても、品質に対する意識は当たり前にあったということができる。

だが、今やVUCAと呼ばれる、これまでにないほど世界的にビジネス環境が不安定な時代である。品質も過去の一定の水準では通用しない。現代に合わせて、自分たちの品質を考えなおす必要があり、プロダクトや品質水準をゼロから見直す企業がどんどん増えている。そこで有用となるのが「品質文化」というコンセプトである。

では、品質文化とは何か。品質文化を「組織でどのように品質が語られているか」であると捉えたのは、ロナルド・カミングス＝ジョンとオワイス・ピアである。彼らは著書『Leading Quality』（未邦訳）で、その捉え方を「品質ナラティブ」^＊と名付けた。

^＊ナラティブ＝語り

組織が採用する品質管理のアプローチは、品質文化に基づいて定義される。たとえ認識されていなかったとしても、あらゆる企業に品質文化は存在する。仮に品質が考慮されていなかったり軽視されていたり無意識に扱われていたとしても「そのような（品質を考慮しない）品質文化として存在する」のである。

品質文化を組織やプロダクトにとって望ましいものへと醸成するには、まずはその現状を把握しなければならない。その現状把握に役立つ手法が品質ナラティブとしてまとめられている3つの類型である。少々寄り道になるが、紹介したい。

「品質」に関わる議論は、大きく3つに分けられる。どのように自社で品質が語られているか、把握するための参考にしてほしい。例えば、現場は「検証ナラティブ」を重視し、マネージャーは「責任ナラティブ」を重視していたら、話は嚙み合わない。「価値ナラティブ」が軽視されていては、品質をいくら高めてどのような意味があるかを示すことはできない。この3つがバランスよく語られていることが大切だ。

「誰がプロダクトの品質に責任を持つか」という観点である。これは品質を慎重な側面から捉えている企業で特に多く見られる議論であり、明示的に品質責任者を置く企業も少なくない。近年採用されることが多いアジャイルソフトウェア開発では、品質の責任は特定の個人ではなくチーム全体にあるという考え方もされている。

「プロダクトに対し、いつ・どのようなテストを・どのような技法やツールを使って行うか」という観点である。品質を専門とするエンジニアであれば、品質を語る上でテスト（検証）を無視することはできない。とはいえ、組織において品質に関する議論のほとんどが「検証ナラティブ」である場合、いわゆる「How（やり方）」に偏り「Why（なぜそれをするのか）」の考察や議論が不足している可能性がある。品質のことを考えるのはエンジニアだけの役目であると考えている組織の品質ナラティブは「検証ナラティブ」が多くの割合を占めるだろう。

「品質への投資がどれだけ価値につながるか」という観点である。品質の重要性を否定する組織はほとんど存在しない。しかし、品質の高さがもたらす収益性・コスト削減効果・リスク低減効果といった価値に着目し、積極的に議論する組織はまだ少ない。テストをはじめとする品質向上施策にかかる費用をコストと捉えているか、それとも価値創出のための投資と捉えているかが見えてくる。

例えば、多くのスタートアップではアプリ開発に際し、MVP（Minimum Viable Product：市場で販売できる最小限の機能を備えたプロダクト）を目指し、できるだけ素早くプロダクトをリリースしようとする。この時点で考慮される品質には限りがある。他方で、大企業が多く手がける大規模プロジェクトでは、メンテナンス性や大量のアクセスに耐えるパフォーマンス性などの品質の優先度があがる。

組織戦略やプロダクトの成熟度などにより、必要とされる品質もその品質を実現する文化も異なる。ちょうど、同じ企業でも部署によってKPI（Key Process Indicator：重要業績評価指標）が違ったものとなるように。

また、ソフトウェアテストを外部の下請け企業に依頼し、自社ではプロダクトの製造までの工程と販売に注力している企業を想定してみよう。こうした組織はプロダクトに素晴らしい機能を追加するとか、販売チャネルを拡大するといったことに目を向け、プロダクト開発やセールスのプロフェッショナルを雇用する。この企業の組織文化は、プロダクトの「製造」や「販売」に最適化されているだろう。

彼らは自分の専門外である品質をどれだけ考慮するだろうか。それは「ビジネスモデル」ではなく組織の「品質文化」によって異なるであろう。

強力な品質文化を持つ組織であれば、従業員はソフトウェアテストをよく管理してリードし、不具合を見つけ、工程の手戻りを防ごうとするだろう。PDCAなどのサイクルを回して品質を向上させることに、より多くの時間を割くだろう。また、QAエンジニアなど品質を専門とする従業員を雇用するかもしれない。

他方で、品質文化が弱い企業であれば、外部にテストを任せ、報告された不具合を修正することにのみ関心を払うだろう。もしかしたら、テストを請け負うベンダー企業選定の基準は経験ではなく単価かもしれない。テストはコスト削減の対象として真っ先に槍玉に上がるかもしれず、営業や購買部門の調整次第でたやすく現場は左右される。

どのような形であれ「品質文化」は存在する。それが望ましいものであろうと、なかろうと、である。品質文化を変えるためには、組織文化を変える必要もある。組織文化は組織戦略とも密接な関係がある。

#2へ続く