【連載】QAの変遷を語る：HBA・安達賢二さん「品質保証の領域は製品・サービスの“外側”にまで広がった」

——まずは現在のお仕事と、これまでのキャリアを教えてください。

1987年に新卒で北海道ビジネスオートメーション株式会社（現・株式会社HBA）に入社しました。2012年には社内イントレプレナー制度第1号事業者としてSoftwareQuasolを立ち上げ、今はコンサルティング業務をメインで行っています。

キャリアを振り返ると、入社後に携わったのは官公庁および自治体関連システムの保守・運用業務です。当時はまだ紙を印刷して裁断し、封筒に入れるといった手作業もたくさんありました。そういった泥臭い仕事も含めてシステムの保守や運用、さらにはシステムの新規開発にも関わりました。

しばらくして技術系の部署に異動し、その数年後には大規模な金融系パッケージ開発のプロジェクトマネジャーを三年間務めました。

大型プロジェクト案件が一段落した1996年、たまたまその時に会社でISO9000に取り組む話が出ており、「お前、暇そうだからちょっと手伝え」と上司に言われて、所属部署の品質管理担当の下働きのようなことを請け負いました。

——それが品質管理との最初の出会いだったわけですね。

そうですね。部署の中で手順書を作ってそれを広めたり、メンバーの教育をしたりと、何やらいろいろとやっていました。

ただ、当社には「全社統括部門」があり、そこに対応する顧客や提供する製品・サービスの異なる部門が複数ぶら下がっていたため、基本的には全社統括部門で作成された画一的な開発・保守業務の手続きが落ちてきました。当然、自分たちの部署の開発形態とは合わない内容ですから、全社統括部門と結構ドンパチやりまして（笑）。最終的には、「これではまともに運営できないから、別途考えないと駄目だ」という話になり、部門ごとに品質マネジメントの運用手続きを作りました。

その後、2000年には全社統括部門に異動となりました。ちょうど「品質管理部門」と名称を変えて、全社のサービス品質をどうするかといった議論が活発に成り始めたタイミングでした。

——2000年当時だと、日本ではまだソフトウェアの品質管理に関する情報が少なかったと聞きます。どのように学んでいったのでしょうか？

日本科学技術連盟のソフトウェア品質管理（SQiP）研究会から「ISO9000のソフトウェアへの適用」というガイドが出たので、それで学びました。加えて、東京大学の飯塚悦功先生がいろいろなところで講演する内容や関連雑誌の記事なども参考にしました。

後、ISO9000のコンサルタントとして手広く情報発信していた辻井浩一さんという方がいたんですね。辻井さんが自身のWebサイトでいろいろ紹介していました。ただ、手広くやっていた関係で、ソフトウェア業に関する内容は一部にとどまっていたのです。そうしたら、「あなたがソフトウェア業で品質管理の専門サイトを運営されてはどうか」という話が来たので、独自にサイトを1999年6月に立ち上げました。そうしたことを通じて勉強ながら、自社でも適用していった感じでしたね。

結果的に、そこから2012年3月までずっと品質管理部門にいました。QA（Quality Assurance）やクオリティマネジメント、最後は情報セキュリティやマネジメントシステムなどを含めて全部担当することになりました。

——品質管理やQAに関わり出した当時、ソフトウェア業界はどのような状況だったのでしょうか。

日本の場合、最初は製造業の真似から始まったと思います。製造業の品質管理モデルを、ソフトウェア業にそのまま適用して、何とかしようと試みたのではないでしょうか。

——実際はそんな簡単に適用できるものではないと？

そうですね。当初、私が一番分からなかったのが、実はこれなんですよ（下図を見せる）。

製造業には大きく「設計」「製造」「試験」という三つの流れがあって、特に製造の工程が強かったわけです。でも、ソフトウェア業だと、先ほど述べたSQiP研究会のガイドには、ほとんどが設計で決まるといった話が載っていて。この違いが腑に落ちるまでがすごく大変でした。

製造業の場合、製造にすごいノウハウを持っていると思うのです。一方で、ソフトウェア業はほとんどが設計。ですから製造業の成功モデル、例えば手続きをちゃんと定めてその通りやったらみんな同じものができるはずだといったモデルを適用しようとしても、ソフトウェア業では手続きをどんなに詳細に書いてもきちんとできるわけでもないのです。

当時私が会社に品質管理を導入するとなったとき、手順書の整備をどうしても真っ先にやらなくてはなりませんでした。それにすごく労力がかかったのですが、手順書はほとんど誰にも読まれませんでしたね……（苦笑）。

それと、あくまでも昔はモノ（製品）の品質だったんですよね。でも、2000年辺りを契機に、実はISO9000も改定をして、製品・サービスの品質になりました。スコープが広くなったというか、製品以外の領域も含めた保証をしなくてはいけないというモデルに変わりました。それから日本にもCMMI（Capability Maturity Model Integration：能力成熟度モデル統合）やPMBOK（Project Management Body of Knowledge：プロジェクトマネジメント知識体系ガイド）が導入されて。

海外から“黒船”が日本にやって来て、企業は一斉に適応しなければならなくなったのが、2000年前後に起きました。PMBOKは要するに手続き集。手続きを適切に積み上げればプロジェクトは成功するはずだという考えに基づいています。モノからサービスへという広がりは生まれたけど、まだ手続きでいけるのではないかといった状況でした。

ただ、今はPMBOKも変わりました。第7版は「原則」しか書いていません。いよいよプロジェクトマネジメントも、手続きを積み上げればできるものではなくなってきたのを悟ったわけですよね。

——時代が変わっていく中で、QAエンジニアに求められるスキルはどう変化するのでしょうか？

カリフォルニア大学名誉教授のデビッド・アーカー氏が提唱した「価値の3分類」が参考になります。「機能的価値」「情緒的価値」「自己実現価値」の三つから成るもので、従来のIT製品・サービスは、機能をどのくらい搭載しているとか、性能が良いとか悪いとかといった機能的価値を保証することが中心でした。

でも、今はユーザーが利用時にどういう体験をして何を感じ、何が実現できるようになるのかという、製品・サービスの外側にある「情緒的価値」「自己実現価値」が重視されています。ユーザー体験やQoL（Quality of Life）といったものですね。実際、機能をたくさん積んでも、お客さんの総合評価はむしろ下がるという統計データが示されてもいます。ですからQAエンジニアも、モノからヒト、あるいはさらに外側で起きることに目を向けなければならないでしょう。

とはいえ、QAエンジニアでその視点を持っているのはまだまだ少数。まさに今それを社内でも訴えています。恐らくモノを作っても売れない時代が来ると思いますから、現状分析をして、ユーザーの生活や業務を製品・サービスによってあるべき姿に変えるために必要な機能は何かという具合に、ユーザーの生活や業務が目指すゴールから、製品・サービス機能までの導線をトータルデザインし、全体を保証しないとダメだと。

最近はQAを担当する人が開発チームに入り込んでいるケースが出てきています。それでいて客観的視点も持ち合わせて、他の人が気付かないことを補いながら共にやっているのです。

従って、QAエンジニアは製品・サービスを使ったお客さんのところで何が起きるのかまで観察し、フィードバックを得ることも必要だし、企画および開発の早い段階からそういうことをデザインしなければなりません。マーケティングや企画の担当者がやるような仕事を、QAエンジニアが入って一緒にやる時代になるのではと思っています。

——そのように提供すべき価値が広がった要因は？

2018年ごろから「VUCA」（Volatility：変動性、Uncertainty：不確実性、Complexity：複雑性、Ambiguity：曖昧性）が叫ばれ始めて、それと歩調を合わせるように世の中の価値観も変わってきた気がしています。

ソフトウェア開発者の和田卓人さんがある発表の中で、「計測するものが変わってきている」という話をされていました。昔は製品・サービスの信頼性を中心に見ていて、いかに障害のないモノを作るかが勝負でした。今は許容できる障害であれば、むしろ早くサービスを世に出して、その代わり、不具合が出た時にいち早く回収して、修正していくことが求められています。リードタイムを短く、どんどん変化に追従していく方が重要だということです。

「MTBF」（Mean Time Between Failure：平均故障間隔）よりも「MTTR」（Mean Time To Repair：平均修復時間）。以前はリリースしたらなるべく改修しない方がよくて、最初から完璧なものを仕上げることを重視しました。でも今は唯一の答えがない時代。しかも変化するからどんどんアップデートしなければいけません。これまで人間が実施してきた作業を整理して、本当に人間でなければできないことを深掘りすることが必要になります。

——この先、QAエンジニアには高い資質が必要になりそうです。

恐らく見なくてはならない要素数が、劇的に増えると思うのですよ。さらに変化も激しいので課題だらけになるはず。製品・サービスも複雑化していますし。最近は製品を1個作ってもいろいろなサービスとつながらないと使い物にならないから。

ですから、複雑さを読み解いて、取り組むべきは課題を絞り込む能力がまず必要だと思っています。適切な課題設定ができる人にならないと駄目ですね。

G.M.ワインバーグ氏やピーター・センゲ氏などが提唱するように、そうした状況に対処するには「システム思考」がいいとされています。課題を特定できる能力さえあれば、後は解決策をそこに充てがうだけでよい。少ないリソースでたくさんの物事に対応する時には欠かせないと思います。

もう一つは「デザイン思考」です。どうしても他人に目を向けなければならないから、相手の立場で考えるという、すごく原理的なことができるかどうか。

QAエンジニアにとっても開発のリーダーにとっても、システム思考とデザイン思考はこれから絶対に欠かせないと考えています。

ただし、課題を抽出したり、相手の視点を持ったりするには、いろいろな人がざっくばらんに発言できる場作りが不可欠です。そのためのファシリテーション能力、誰もが言いたいことを言えて、適切に議論ができる場を作るスキルも併せ持つべきでしょうね。システム思考、デザイン思考、ファシリテーション力。この三つがこれからのQAエンジニアに求められるでしょう。