【連載】冒険者の地図：「マーカー塗り」の衝撃、品質管理エキスパートの熊川一平さんがQAにのめり込んだ理由（前編）

1984年に大阪府で生まれた熊川さんは、当時としてはかなり早い時期にコンピュータに興味を持った少年だった。

「小学生のとき、自宅にあったPC（NECのPC-9800シリーズ）を壊してしまって。子どもながらに『これはやばいことをした……』と、折れ曲がったPCのパーツとお年玉を握りしめて日本橋（大阪の電気街）に行きました。思い起こせば、その頃からコンピュータには関心がありましたね」

エンジニアとしてのキャリアにつながる原体験を熊川さんは回想する。中学、高校と成長するにつれてコンピュータに対する熱量は高まり、ソフトウェアやITサービスを作りたいと考えるように。そこで情報工学の専門コースがある岡山県立大学に進学した。

大学時代にさまざまな知見を深めた結果、せっかくならば社会インフラシステムなど責任のある大きな開発にチャレンジしたい気持ちが湧き上がってきた。それを実現できるフィールドとして、熊川さんが就職先に選んだのが大手SIerである。

新卒で入社し、最初に配属されたのは、金融機関向けの大規模システム開発チームだった。それまでの通例だと、細かな開発業務は外部の協力会社にアウトソーシングして、そのマネジメントを熊川さんが勤める会社の社員が担うことが多かったそうだが、その当時、同社は開発の内製化に舵を切ろうとしていたため、熊川さんも現場の一エンジニアとしてソースコードを書いたり、アーキテクチャを検討したりしていた。そこで衝撃的な光景を目の当たりにする。

「変化によるリスクを忌避する風潮があるので、大規模金融系システムはかなり古い開発スタイルを踏襲していました。例えば、単体テストの場合、ソースコードを紙に印刷して、クリアした場所をマーカーで塗り、それを全部ファイリングしていました。あるいは、開発画面のキャプチャをエクセルにペタペタと貼って保存していました」

熊川さんから見れば、明らかに非効率な作業だった。一人のエンジニアとして素直にやめたいと思い、「マーカーを塗る仕事は終わりにさせてください」と上司に掛け合った。反発はなかったのか。

「強い反発だったり、頭ごなしに否定されたりはありませんでしたが、ルールを変えるための手続きのハードルは高かったです。ある意味、既存の開発標準の統制が効いているので、そのルールを変えるための丁寧な説明は不可欠でした」

ただし、突拍子もないことをした自覚はなかった。基本的には現場のエンジニアも、マーカーを塗る作業に疑問を持っていたし、そうして作った証跡を後々見返すことがないのは分かっていた。他方、マネジメント側も業務の生産性を上げなければいけないという課題は常にあった。そう考えると実際には全員の総意として改善を進められる環境にはあったという。

改善を進めるには見本を示すほうが早いと判断した熊川さんは、海外のフレームワークを紹介したほか、そうしたものを実際に自ら使ってみて、「こういうことができるんです」と見せることで、周囲に具体的なイメージを持ってもらえるようにした。

熊川さんがQAに強い関心を持ったのはこの頃だ。テスト領域には専門性の高い技術がたくさんあることを知り、QAのスキルを磨けば、これまでの金融機関システムでやっていたような改善活動をもっと幅広い分野に応用できるのではないかと考えた。

QAに惹かれたのは自身の問題意識の表れでもある。一つは、明らかに非効率的な作業が許せなかったこと。もう一つは、ソフトウェア開発の現場においてテストが軽視されていたことである。

「なぜこのテストをしなくてはいけないのか、なぜこのテスト項目でいいのか、どうやって品質をマネジメントするのかなど、誰に尋ねても曖昧な答えしか返ってきませんでした。また、アーキテクチャ設計とか、アルゴリズム設計などは議論されるのに、テストや品質についてはなかった。議論が足りていない、曖昧な指標なのに、品質に問題がないと言い切れるのだろうと」

とはいえ、当時はもっとQAの価値を上げようなどとは特に思っていなかった。どちらかというと、なぜこのテストをしなくてはいけないのだろう、どうしてこの品質で分析できるのだろうといった部分を、しっかりと論理的に定義していくことがモチベーションになっていた。

これは先述した、テストコードをマーカーで塗る無駄な作業と通じる部分があるという。そういった伝統的な非効率業務は変えられるし、他にもっといい方法もある。それを訴えたいと考えた。

そんな折、立ち上がったばかりのテスト専門組織に目をつけた熊川さんは、社内公募による異動を願い出た。入社5年目のことである。

異動先は、特定のプロダクトに対して活動する部門ではなく、全社横串でテストプロセスの高度化や改善を提案していく、いわゆるR&Dの部署だった。その一員として熊川さんもQAに関する論文やレポートを書いたり、学会発表したりする活動に没頭する。自身の主要テーマは「テスト自動化」だった。

「当時はSelenium RCやWebDriverといったエンドツーエンドのまだ普及していない時代。また、日本でテストツールの利用が進んでいないことが専門誌の調査で明らかになったようなタイミングでした。そこに課題感を持ってテスト自動化の意義などを社内に啓蒙していきました。国内にはあまり詳しい人がいなかったので、社外に発表する機会も多かったです。キャリアにおける一つのターニングポイントでしたね」

こうして次第に社内外でテスト・品質分野に詳しい人物だという認知が広まっていった。

テスト自動化に取り組んでいく中で熊川さんが気になったのは、明らかに成果が出るプロジェクトと、上がらないプロジェクトが極端に分かれていたことである。その原因は何かを追求する中で、テストの戦略や計画、設計などにも目を向ける必然性を感じた。

「うまくいかないプロジェクトでは自動テストという手段が目的と化していました。でも、あくまでも自動テストは手段の一つだと捉え直しました。他の方法も含めて、どうすればプロジェクトを成功に導くことができるか、それをどうやってテストで実現していけばいいのかを考えるようになりました」

その結果として、リスク低減に向けてテスト作業の優先順位を決めることを重視した「リスクベースドテスト」や、テスターがテストの内容作成と実行を同時に行う「探索的テスト」を深く研究するようになっていった。

ところで、熊川さんはどのようにQAの専門的知識を身に付けていったのだろうか。

一つは、テスト・品質技術の領域には数多くのコミュニティーや勉強会があり、そこでの学習機会が豊富だったことが挙げられる。加えて、勤め先にはQA業界の重鎮と呼ばれる社員がいて、直接教わることもできた。

もう一つは、所属していた部署には社内からさまざまなプロジェクトの相談が来るため、実践の場が多数用意されていた。失敗、成功を問わず、非常に早いスピードでQA業務を経験できたことが大きいという。

「苦しんでいるプロジェクトがあると、その解決方法を提案しに行きました。仮に受け入れられなかったとしても、たくさんのフィードバックを現場から得られるので、それも学びになりました」

いくつものプロジェクトに関わってきた中で、特に思い出深いエピソードを熊川さんは披露してくれた。

（後編に続く）

※本記事内の記載や発言内容は、個人の見解であり、所属組織の見解ではありません。