プロジェクトストーリー PROJECT

H.II: QA専門組織発足以前は、QAを専任として担っているのは、私1人でした。私以外は、ソフトウェアテストは開発者が行う文化で、人によって粒度にバラツキがあったり、テストシナリオなどが最低限のものしかなかったりなどで、リリース後に不具合が発生してしまうケースもわずかながらあったんです。それを改善すべく、てこ入れが入ったのが、QA専門組織発足の背景です。
「1人のQAエンジニアから始まったストーリー」ということで、そんな私のヒューマンテクノロジーズ入社の経緯から時系列で辿っていくと、QA専門組織発足までの流れが掴みやすいかもしれません。
私自身は、90年代後半からテストエンジニアの道に入り、専門性を磨いてきました。
もともとは、アルバイト先の本やレコードを扱うサブカルチャーのお店が潰れ、路頭に迷っていたところ、小学生の頃からかじっていたプログラミングのことを思い出し、門を叩いたIT企業にて、テスト業務を担当したのがきっかけでした。
当時はインターネット黎明期ということもあって、私はソフトウェアテストという分野の大きな可能性を感じました。インターネットが普及すればするほど、ソフトウェアも開発者も増えていくわけで、その品質を担保する役割の重要性は増していくと。
その後、さまざまなプロジェクトでQAエンジニアとしての経験を積んだ後、ヒューマンテクノロジーズに初のQA専門職としてジョインしました。長年この業界を見てきた私から見ても「エンジニアがこんなに楽しく、自由な雰囲気で働いている場所はない」と、うらやましくなったことを覚えています。

H.II: いえ、入社後もそのイメージは変わりなく、誰でもすんなりオンボーディングして、なじめる職場だと感じました。
品質面では、勤怠管理システムのパイオニアとして、導入企業数、利用ID数ともにNo.1を走り続けているだけに高水準である一方で、歴史が長く機能も多い分、製品が巨大。全貌を把握するのも、品質管理面での改善策を実行するのも一筋縄ではいかない、という印象でした。
そんな状況下で入社して半年ほど、QAの基本的な考え方から社内浸透すべく、孤軍奮闘していました。そして、2020年7月、社内にQA専門組織を立ち上げることになり、リーダーを務めることになりました。

H.II: それまでの私は、開発チームの一員としてのQAエンジニアという位置づけでしたが、このQA専門組織は開発チームからは独立した存在となる、というのが最大のポイントです。作る当事者とは違う視点で、第三者の目線でソフトウェアの品質を保つ立場になるわけです。
これは、「三権分立」でたとえるならば、「司法」を担うポジションといったところでしょうか。
さらに、これは当社独自の考えにもとづく体制として、これまでカスタマーサポートチームにあったQC部門もQAに統合しています。

T.KANEMARU: QCは、もともとお客様と対峙するサポートと開発との架け橋を担っていたわけですが、こちらもサポートから独立したことで、サポート側・開発側、それぞれの立場や意見をフラットに俯瞰できる立場となりました。
また、QAと同じ組織に統合されたことで、技術的な知見が貯まり、リリース後、ユーザーが使っている部分での不具合に対応していく中で、QCとしてのレベルが上がっていく実感を抱いています。

T.KANEMARU: 私自身は、2018年4月に入社し、カスタマーサポートとして、お問い合わせの電話対応から導入支援まで一通りこなした後、OEMチームのSVを務めていました。ですから、QC業務自体は未経験だったんです。
ただ、SVというQCに質問をエスカレーションし、検証していく立場を経験する中で、強みを感じてもらえたのか、このQA専門組織にアサインされたかたちです。

H.II: T.KANEMARU の、「お客様の業務に沿って、設定を調整し、再現していく」という検証プロセスや、チケットのやりとりをはじめとした、丁寧な仕事ぶりをそばで見ていると、本当に適性がある、良い抜擢だとつくづく思いました。
そんな T.KANEMARU とは、ジョイン早々、とことん何時間も語り合って、信頼関係を築けたのが功を奏し、数ヶ月でツーカーのコミュニケーションがとれるようになって、お互いの視野が広がり、会社全体が俯瞰できるようになった気がします。
QC側で発生した技術的な課題や判断を、的確に相談してくれて、それを解消することで速いサイクルが回せる体制になったのは心強かったです。

T.KANEMARU: そうですね。技術面でわからないことがあれば、H.II に質問。私は私でQAエンジニアたちが業務面で理解できていないことを減らしていけるよう、QAチーム全体を巻き込んでいく、みたいな役割分担ができましたね。

H.II: とはいえ、T.KANEMARU がジョインする前は私以外は兼任のメンバーばかり、かつ本格的なQA経験者もいない体制だったので、立ち上げには苦労しました。
当初彼ら兼任メンバーの稼働1日8時間のうち、1/4の2時間をQA業務に充てる、という運用で、とりあえず「探索的テスト」を導入しようとしたのですが、あまり成果を上げられなかったんです。
まあ、「探索的テスト」は経験則から嗅覚が磨かれたベテランじゃないと難しいところもあるのでしかたない面もあったんですが。
もちろん、ソフトウェアテストの知識を底上げすべく、定期的に勉強会も開催しましたが、短期的な成果にはつながりませんでした。
そこで、開発側で採用したエンジニアのうち1人に、QAエンジニア専任になってもらえないかと打診したんです。無事そのオファーが通り、QA未経験者とはいえ、フルタイムQAに充てられるメンバーを獲得。
彼に手取り足取り教えることで、プロジェクトが回り出したのが転機でした。

T.KANEMARU: そうですね。私がジョインしたのも、その頃です。いわゆるQA業務が上向きになっていく一方で、負荷が偏りつつあったQC業務を改善するところから、私の仕事は始まったわけです。
日々のデータを網羅的に蓄積するようにしたり、リリースされた新機能の説明会動画を整理したりして、情報の見える化を徹底しました。
その過程で私自身も、QA専門組織の一員として、ソフトウェアテストの勉強会に参加するうち、どんどん興味を喚起されたので、JSTQB（Japan Software Testing Qualifications Board）認定テスト技術者資格の取得に向けて個人的にも学ぶようになりました。

H.II: はい、こうした活動が、結実した成果と言えるのが、2022年度の市場バグ発生数半減という実績です。これには様々な要因がありますが、特に効果的だったのは、QAチーム総出で、テスト仕様書のレビューを徹底的に行ったことでしょう。
どうしてもテストケース洗い出しは、各エンジニア次第、属人性の高いもの。その質を上げることが、品質向上に大きく貢献すると考えたのです。
当初は、私しか完全なレビューはできなかったのですが、次第にメンバーが学び、成長するにつれ、どんどん開発チームのテストの質が見違えて改善していきました。
QAエンジニアが見本を示し、ともにテストを遂行し、ブラッシュアップをくりかえしていく、そんな関与が、大きな気づきを生んでいったのです。
品質というものに対する、開発エンジニアの意識が、知識と経験によって変化し、バグの半減につながっていきました。

T.KANEMARU: 実はQCチームでも、テスト仕様書のレビューに関わらせてもらったんです。その結果、レビューリソースが増大したことで、さらに広範囲のレビューができるようになったのはもちろん、私たちQCチーム自身にとっても、QA業務の深い理解につながったのも大きかったですね。
テストの過程で、QAエンジニアが「どんなアプローチで検証しているか」が見えるようになったことで、いざ実画面に対峙した際、どんな結果を期待しているのに、どんな事象が起きているか、そのためにはどんな素材を添える必要があるか」といった報告のしかたが変わりました。
実際、チケットの切り方一つとっても、冗長な文章中心から、エンジニアが端的に把握できるような箇条書きが増えていった気がします。

M.TAKANO: はい、私はまさにそんなムードでの、QA経験者としての入社組となります。
興味があったJavaでのプログラミングを学び、開発エンジニアとしての職を探していたのですが、当時子どもが幼かったこともあって、開発と子育ての両立は難しいと判断し、ソフトウェア検証担当としてこの世界でのキャリアがスタートしました。
私も H.II 同様、いくつかプロジェクトを経験する中で、QAの仕事のやりがいや、おもしろさを味わっていき、いつしか、「QAこそ私の一生もののスキル」だと思えるようになりました。
リリース前に重大な不具合を見つけて感謝されたり、ヒヤリハットを一つずつ潰していって品質を改善している実感を覚えたりすることで、世の中にバグを流出させずに済んだ、という安堵が、他にはない達成感につながるのです。
そのうち、「もっと1つの製品に愛着を持って、その品質向上に末永く貢献していきたい」という感情が芽生え、プロジェクトベースではなく、自社製品／サービスのQAを担当したいと思うようになったんです。
そんな転職活動の過程で巡り会ったヒューマンテクノロジーズの「KING OF TIME」は、長い歴史に亘って、市場で多くのお客様に支持されている信頼性の高い製品であり、私の思いにドンピシャでした。

M.TAKANO: H.II、T.KANEMARU をはじめとした既存メンバーのがんばりによるものだと思いますが、未完成ではあれ、未熟ではないと感じました。
また、当社独自の体制である、QCチームが統合されている点も、個人的には、品質というものの本質を鑑みるに、一緒になっているメリットも感じています。市場に出てからも、ユーザーに近い目線を持ち、開発にフラットな目線でフィードバックできる強みがありますから。
とはいえ、H.II 同様、巨大な製品の全貌がつかめていない状態からのスタートで、さらに、開発チームとの関わり方をはじめ、完全リモートワークということもあって、社内に知り合いがまだ作れていない中で、会社全体を見通すことができず苦労したのは事実です。
これはどこの会社でも同じだと思いますが、出社して初めて「こんな雰囲気なのか」と、毎回感じています。
現在は、勤怠のテスト実行管理、テスト仕様書のレビュー、仕様書のレビュー、プロセスの改善などいろいろ取り組んでいるところです。

H.II: M.TAKANO には、主に勤怠製品の実行管理から移譲していったのですが、それをすごい勢いでブラッシュアップしてくれています。M.TAKANO のジョインで、間違いなく、2nd ステージに入った確信があります。

H.II: そんな中、直近の課題としては、まだ自動テストや Selenium でのテストができるリソースが不足しているので、強化したり、自動化やAIをはじめとした新しいテスト技術を積極的に導入し、よりいっそう効率化していかなくてはなりません。
中期的には、QA側からもっと製品・サービス側に提案していける体制を作ることです。さらに長期的には、当社の成長に合わせて、テストという狭義の品質管理の先にある、広義の品質保証体制を、当社らしく築いていくことでしょうか。
個人的にも、さまざまなバックグラウンドを持った方と、ソフトウェアの品質について語り合っていきたいです。

T.KANEMARU: 私もこのQCという業務にすっかりハマってしまっています。H.IIが描く品質保証体制を構築すべく、よりユーザー側の視点・カスタマーサポート側の立場や意見まで汲み取っていこうと思える、好奇心が強く、興味の幅が広いQAエンジニアの方を熱望しています。
プロジェクト立ち上げ当初、私とH.IIが語り合っていたように、「ああでもないこうでもない」と議論しながら、お互い高め合い、ともに当社らしい品質保証体制を描けることを楽しみにしています。

M.TAKANO: ここまでみんなで少しずつ作り上げてきた組織、そして、QAのコンセプトを、もっと会社の中に浸透させていきたいです。開発チームはもちろんですが、それ以外の全社員が品質というものに意識を持ち、それが皆さんの誇りの一つになっていくように、活動していきたいです。
私は本当に良いタイミングで入社したと思っていますし、今本当に面白くてエキサイティングなステージです。
QAエンジニアとして、「もっとこうしたい、もっと改善したい」という要素は尽きないので、まだまだ可能性も、活躍できる余地も、伸びしろもあります。
そんな試行錯誤が成長企業の醍醐味ですし、QA経験者なら、その知見で貢献できる機会には事欠かないはずです。ともに、品質保証の新しいスタンダードを作っていきましょう。