はじめまして。
弥生株式会社の開発本部システム開発部でQAエンジニアをやってます、奥野賢一といいます。
プロダクトについて
弥生では、主力プロダクトとして、家電量販店などでパッケージが山積みになっている会計ソフトをイメージしやすいかもしれませんが、実はクラウドサービスも展開しています。具体的には「ネクスト」シリーズや「弥生オンライン」などです。
さらに、事業者の方が事業を推進していく中で出てくる様々な課題をサポートする「事業支援サービス」も行っています。ソフトウェア開発だけにとどまらず、事業環境全般をサポートする会社だと思っていただければイメージしやすいかなと思います。
開発組織体制
システム開発部の全体像を出そうとすると、プロダクトの数がたくさんあって全部書き切れないので、ここでは抜粋版を共有しています。
QAエンジニアは、基本的にはプロダクトごとの開発チームにアサインされる形です。典型的なチーム構成はプロジェクトマネージャー、TechLead、エンジニア、そしてQAエンジニアといったメンバーが集まっています。
しかし、プロダクトの特性や規模によっては、QL（弥生ではQAエンジニアのことをQuality Leader略してQLと呼んでいます）がいないチームもあり、採用している開発プロセスがスクラムの場合はプロダクトオーナーやスクラムマスターがいたりして、また雰囲気が変わります。
さらに特徴的なのは、チーム外に「QA部門」が存在していて、ここでは開発チームの進捗状況を外部から観測して、必要に応じて支援に入るという役割を担っています。
実際にプロジェクトの中で品質関連の業務を担うQAエンジニアは、2025年2月時点で13名在籍している状態です。
弥生における「品質保証」とは
品質保証というのは、企業ごとに定義も指す範囲もバラバラです。どこを重視するかも組織によって変わります。
具体的には
「障害が少ないプロダクトを作ること」なのか、
「障害を減らすためのプロセス」を担保することなのか、
「UX（使い勝手）」まで含むのか...
要するに、品質保証がどこまで関わるかは本当に様々です。
弥生の場合は「全部やる」というのが基本スタンスです。
障害が少ない状態を目指すのはもちろん、プロセスの再現性を高めることや、より快適に使えるUXも含めて、「プロダクトをより良くするためのアプローチ」をどんどん試していこう、といった姿勢を大事にしています。大変ではありますが、その分やりがいのあるポジションだと思います。
QAエンジニアの取り組み
QAエンジニアのミッション
そのなかで「QAエンジニアは何を目指しているのか？」ですが、弥生のQAエンジニアに課せられたミッションは、「プロダクトの“価値”を向上させる」です。
ここまで「品質」という言葉を散々使ってきて「え、品質じゃなくて価値なの？」と思われるかもしれませんが、実は品質も“価値”の一部に含まれています。
どういうことかというと、私たちはプロダクト開発の中で「お客様が何を得られるのか？」を常に自問します。たとえば「意思決定の精度を上げる」「ビジネスを持続可能にする」「業務の信頼性を高める」といった、わりと定性的な目標が挙げられます。
そして品質は、それらの価値を下支えする大切な要素だと捉えています。つまり、価値をより大きくするためには品質が不可欠です。しかし品質それ自体が最終目的ではなく、あくまでお客様にとっての価値実現のための大きな柱の一つという位置づけになります。
お客様に真に求められるものを届けるために、QAエンジニアは品質を通じて価値を守る。そんな役割を担いながら、毎日の開発に取り組んでいます。
U字プロセスとテストへの関わり
実際の活動の流れをざっくり説明すると、まず弥生の開発プロセスは、いわゆるウォーターフォールを改良した「U字プロセス」と呼ばれるものを採用しています。
ウォーターフォールというと「変更に弱い」イメージがありますが、弥生の場合は後からの修正や手戻りを積極的に受け入れられるよう、柔軟な変更管理を組み込んでいるのが特徴です。また、上流からのレビューを重視して常にテストを意識しながら開発を進めるので、TDDとも言えるようなプロセスでもあります。
実際にQAエンジニアがどう関わっているかをもう少し掘り下げると、まず注目すべきは「レビュー」というプロセスです。
弥生では「静的テスト」と呼ばれる事もありますが、、各工程ごとに必ずレビューが行われ、そのほぼすべてにQAエンジニアが参加します。TechLeadやエンジニアと同様に、QAエンジニアの視点を取り入れることで、障害を早期に発見したり、要件を深掘りしたりすることができるんです。
また、このレビューを通じて得られる情報をもとに、QAエンジニアが主体となって後の動的テスト（実際に動かして試すテスト）の準備を進められるのもメリットです。
弥生ではこのように上流からQAエンジニアがしっかり入り込める環境があるので、より効率的な品質保証が実現しやすいと思っています。
統合テストと自動化の推進
次に「動的テスト」です。
結合テストが終わった後、弥生では「統合テスト」と呼ばれる段階に移行しますが、ここはQAエンジニアが主体で進めています。
テストの内容としては機能テスト（ブラックボックス）を中心に、ユーザー目線でのシナリオテスト、そして探索的テストなども行います。結合テストやレビューから得られた情報を踏まえ、テスト設計や結果のレビューを柔軟に反映させています。
また、同じテストを何度も繰り返す部分は自動化して、どうしても人間が手を動かさないと確認できない箇所に力を注げるようにしよう、という方針で進めています。
プロダクト改善と顧客の声
最後に、テストとは少し違う視点ですが、プロダクト改善の取り組みもQAエンジニアが中心となって進めています。弥生には大きなカスタマーセンターがあって、ユーザーからの問い合わせやトラブル報告を日々キャッチしてくれています。それを開発側にフィードバックし、より短いサイクルで改善につなげるのが狙いです。
もともと「要求管理」フレームワークは存在するものの、よりスピード感を持ってユーザーの声を拾いたいという思いから、直接CSとやりとりして「こんな機能があると便利じゃないですか？」と提案してみるという活動をしています。
CSとお客様との音声ログを直接聞くこともあり「テキストデータだけでは分からないユーザーの苦労や要望をどこまで吸い上げられるか」がポイントになります。
いま直面する課題と次に向けて
課題となるテーマとしては、大きく3つあります。
1.スピードと品質の両立
私たちの業界に限らずテクノロジーは猛スピードで進化しています。新しいビジネスが次々と登場し、市場の変化も激しいので、一度成功したプロダクトでも絶えず変化し続けないと生き残れません。これはお客様だけでなく、弥生自身にも当てはまります。
このようにスピードが求められる中で、品質も落とせないのがQAエンジニアの難しいところかと思います。取り組みの方向性としては、まず「自動化」をさらに推進すること。手順が一定で繰り返しの多いテストはどんどん自動化し、人間ならではの確認が必要な部分へリソースを回そう、という発想です。
それから、いわゆるシフトレフト。
弥生は上流工程からテストを入れているので、ある程度できてはいるものの、例えばセキュリティチェックはまだ後ろ工程になりがちで、後になって「大きな問題が見つかった！」というリスクが残っています。そこの改善が今後の課題です。
2.プロダクトの複雑化
2つ目はプロダクト自体の複雑化について。
お客様のビジネスが多様化・高度化しているので、それに対応しようとするとプロジェクトも自然と複雑になりがちです。加えて、後からの法令や要望で想定外の開発が必要になることも実際に起こっています。
ただ、いくら複雑化しても、お客様に複雑な操作を強要しては本末転倒になります。
そこできちんとUXを考慮して開発を進める必要があります。たとえばMiroなどのツールを使ってカスタマージャーニーマップを作り、ユーザーが実際にどう使うかを可視化し、「ここはもっと使いやすくできるんじゃないか」といったアイデアをQAエンジニアからも積極的に発信していくわけです。
3.シフトライト
最後にシフトライト。プロダクトはリリースして終わりではありません。
リリース後も本番環境を監視して障害を早期に発見・対応し、さらにお客様や市場からのフィードバックを定期的に取り込んで、より短いサイクルでアップデートしていくことが重要になります。
特に本番環境からはログやユーザーの声といった膨大な情報を得られるので、それを基にリスク分析や優先度付けを行い、QAエンジニアとして限られたリソースをどこへ注ぐべきか判断して品質を保つ、というのが今後のカギになってきます。
We Are Hiring!
もしこの記事を読んで「この課題、一緒に解決してみたい！」と思ってくださった方がいらっしゃったら、ぜひ弥生のエンジニア募集ページをのぞいてみてください。現在、QAエンジニアのポジションを2枠募集しています。
一方は「弥生オンラインシリーズ」を担当するポジションで、比較的ウォーターフォール寄りのプロセス。一方は「新サービス開発」で、スクラム寄りのアジャイル体制です。開発スタイルもプロダクトの内容も異なるので、自分に合った働き方を見つけられるかもしれません。興味を持っていただけた方は、ぜひご応募をお待ちしています！[1]
-
本記事は、2025年02月25日に開催されたイベントの内容を元に編集したものです。 ↩
