こんにちは。介護・医療・障害福祉・保育の求人サイト、ウェルミージョブのQAを担当している林です。 ウェルミージョブは、2025年7月にカイゴジョブからリブランディングしてサービス提供を開始しました。
私は先日Kaigi on Rails 2025に参加してきました。私はQAエンジニアでProduction Readyなコードは書けませんが、開発系のカンファレンスに興味があり、今回生まれて初めて参加しました。会場ではセッションを聴講したり自社ブースでの対応をおこないまして、感想としては、控えめに言ってすごくすごくよかったです！このブログでは、コードが書けないQAエンジニアの私が、開発系カンファレンスで何を感じ、開発とQAの意外な「共通点」をどう見つけたのか？具体的な学びとともにお伝えします。
自己紹介
QA歴は10数年で、2021年5月から現ウェルミージョブ（当時のカイゴジョブ）の開発チームへ、専属QAの一人目としてJOINしました。当時は人生初の一人目QA・育休明け・初のリモートワーク・コロナ禍における様々な影響などにより多くの困難がありましたが、アジャイルな開発チームの中で、持ち前のコミュニケーション能力と「握ったボールは自分でやり切るor誰かに渡す」の精神で乗り切ってきました。
私の開発系技術スペックはこんなかんじです。
- 大学はバリバリの文系で、開発系技術とは無縁
- 新入社員時代、必須受講のC言語研修にて、ポインタで挫折して泣いた（ほんとうに）
- QAエンジニアとして業務をしながら、2016年に基本情報技術者（FE）に合格。開発系の資格はこれのみ所有
- 過去には「仕様書がない・触れるシステムもまだない」案件で、ER図からがんばってテスト設計をやり遂げた経験あり
- SQLやAPIについて積極的には実行しないが、幸いにも年1回程度は触ったり勉強したりする機会に恵まれている
- アジャイルな開発チームにて日々、開発メンバー同士の会話を横で聞いている。そのため、テーブル・データ・モデル・処理などが大まかにイメージできている
なぜ「Kaigi on Rails 2025」へ参加したのか？
Kaigi on Railsは、「初学者から上級者までが楽しめるWeb系の技術カンファレンス」をコアコンセプトとした技術的な学びの場であり、多様な人々が交流できるイベントです。 kaigionrails.org エス・エム・エスはKaigi on Rails 2025へGoldスポンサーとして協賛し、スポンサーブースにてウェルミージョブのソースコードを公開しました。
このKaigi on Rails 2025へなぜQAの私が参加したかというと、2つの目的があったからです。
- @moroさんの基調講演を聴くため：ウェルミージョブの開発をリードする@moroさんがKeynote Speakerとして登壇して基調講演を務める運びとなり、私もそれを現地で聞きたいと思いました。普段からチーム内に共有されている@moroさんの考えが、多くのエンジニアに響くのを肌で感じたいと思いました。@moroさんが楽しそうな様子で準備しているのを身近で見ていたこともあり、私を含め多くのチームメンバーがワクワクしていました。さらに、開発チームのメンバーから「林さんも一緒に現地で楽しもう」とお誘いがあったことも参加の後押しになりました。
- 開発エンジニアの考えや課題感を知るため： セッションの視聴やブースでの交流によって開発エンジニアのことが知れると、それが開発とQAの相互理解を深める土台となって、より強い連携を築けるのではという期待がありました。
参加してわかった！セッションからの学び
特に印象に残った2つのセッションについてご紹介します。
1. 基調講演：dynamic!
要約
- なぜ動的/dynamicにしたいのか：この発表では「動的/dynamic」とは「継続して変化し続けること」を指します。不確実性の高いプロダクト開発において「初めから正解を選ぶ」のは難しいため、一度に正解を目指すのではなく、良い方向を目指して少しずつ変わることを大事にしたいです。そしてそれは、楽しいことです。
- フィードバックから得られる価値：「最もシンプルで、うまくいく」ものは何かを見極めて、作ってみて動かして、フィードバックをもとに変化させ続けます。動かすことで、開発者だけでなくデザイナーやQAエンジニアなどがそれぞれの職能を発揮できます。企画者も、事業活用の計画を判断できたり見直せたり、ドキュメントではなく動くソフトウェアをベースにコミュニケーションを円滑におこなえます。
- あらゆるものを動的に習熟していく：見極めたり、一度作ったものを変えるのは簡単ではありません。そのため、コード・プロダクト・プロセス・チーム・自分自身も含めてあらゆるものを少しずつ動的に習熟していきます（※1）。変わることを楽しみましょう！
- （※1）
所感
- 現地で聞けて良かった！：会場では多くの賛同のリアクションや拍手が起こり「良いプロダクトを作りたい」と願う人々の心が一つになったような感動を覚えました。講演の内容は、ウェルミージョブ開発の中で@moroさんが日々体現されていることをそのまま資料に落としたようなものでした。改めて、魅力あるプラクティスに日々トライできることへの喜びを感じました。
- 変化に対応するQAの課題感と、それを解決する可能性：QAエンジニアとして日々変化についていくのは容易でなく、高頻度に発生する追加のテスト設計・実施を軽やかにおこなうための工夫が必要です。ここで私は「忍者式テスト」を思い出しました。（忍者式テストの講演資料はこちら）忍者式テストとは深谷美和氏・関将俊氏によって提唱されるプラクティスで、反復開発の中で「増分だけでなく、プロダクト全体を都度テストする」というものです。忍者式テストでは、開発者もテストを実行してプロダクトから学び、修正や改善を積極的にできるようになるメリットがあるそうです。私は、忍者式テストへの挑戦も含めて、今後さらに軽やかに変化対応できるようトライしていきたいです。
- 不安を軽減するコミュニケーションの重要性：動的に開発が進むことにより、例えば企画者は「最終決定がいつ頃になるのか見通せない」と不安を覚えるかもしれません。そんな場面では、ステークホルダーが必要とするものが何かを知り、より相互にコミュニケーションをとり、必要なドキュメントはシンプルに残すなどして困り事や不安を取り去ることが大事になりそうです。
- 変わるのは、楽しいこと。変えられるのは、ハッピーなこと！：課題もありますが、不確実性の高いプロダクト開発において動的に物事を進めることのメリットは多大です。私もQAエンジニアとしてあらゆる変化を楽しみながら、よりよいプロダクト開発に尽力したいです！
2. Railsによる人工的「設計」入門
要約
- 設計を体得する・教えることの課題感：「設計」を体得したり教えるのは難しいことです。一方で、今後はAIが普及して設計の機会が減り「場数を踏んで体得する・させる」のが難しくなりそうです。さらに、AIを使いこなすためには設計できる能力が重要です。そのため、設計を教える人が「設計を教えられる」ようになっている必要があります。
- 手順から逆算して考えるアプローチ：設計ができない人は「コードを書くとシステムができる」と考えがちですが、設計とはコードとは違って、抽象的なレベルで考える活動です。「コードを意識しないで設計する」ように導くのに「システムができる手順から逆算して考える（※2）」というアプローチが有効でした。まず「完成したシステム」を思い浮かべ、もっとも実現したい本質的な事柄を「ゴール」と定めて、その実現に必要なことを段階的に考えるというステップで、抽象的なレベルで設計していきます。
- （※2）
- 「名前付け」の重要性：抽象化する作業において「名前を付ける」ことは重要です。長い概念を適当に省略してしまうと、本質から外れたところにミスリードされてしまいます。名前付けに苦手感がある人も、勇気を出して、本質を表す名前を自分の裁量でつけましょう。
所感
- 「抽象化する能力」の課題感はQAも同様：QAにとっても抽象化する能力は重要です。例えばテスト分析という過程で「何をテストするか」を定義する際、抽象化が苦手な人はテストケースなどの細かい粒度で考えてしまってテスト全体を捉えられません。さらに、体得する過程における課題感も開発と同様、AIの普及で体得する機会が減りそうです。そのため、QAにとっても「人工的に抽象化を体得させるメソッド」はとても役に立ちそうです。
- 「逆算して全体像を考える手法」はQAにも適用可能：先述した「システムができる手順から逆算して考える（※2）」の文脈で、私は、西康晴氏によって提唱されたVSTeP（「何をテストすべきか」という観点を図で整理し、抜け漏れなく効率的にテストを設計するための手法）（VSTePの講演資料はこちら）を思い出しました。VSTePでは、「テスト要求分析」「テストアーキテクチャ設計（コンテナ設計・フレーム設計）」などの工程を経てテスト全体をアーキテクトします。このうちの「テスト要求分析」の際にテスト観点（テストすべき要素）を整理するにあたり、逆算の手法を適用してみると、以下のステップで進められそうです。
- 「完成したシステム全体」を思い浮かべる
- 中核的な「実現したいこと」にフォーカスする
- 「実現したいこと」に対して「ユーザーに使ってもらって大丈夫、となれるには何の確認が必要か？」を順々に考えていって、全部考えた状態にする
- QAも「勇気を出して名前付けをしよう」：名前付けの重要性や課題感もQAに共通するところだと感じます。名前付けがしっくりこないときは「大事なものの見極め」がうまくいっていないサインですし、間違っていればチームメンバーがそれを教えてくれ、より正しく抽象化ができるようになります。「勇気を出して、本質を表す名前を、自分の裁量でつけよう」というメッセージを、多くのQAエンジニアにも届けたいです。
- 開発・QAが類似課題を共有して解決できる可能性：開発・QAの類似課題について、開発・QA両者が情報や知恵を出し合えると、よりよい解決の方向性が見出せると思います。さらに、VSTePの講演資料の「テスト開発プロセスの基本的考え方（※3）」において「テストケースを開発成果物と捉え、ソフトウェア開発プロセスとソフトウェアテスト開発プロセスを対応させよう」とあるように、開発とQAは様々なプロセスでリンクしています。設計のタイミングだけでなく、多くのプロセスにおける開発・QAの連携が期待できそうです。
- （※3）出典：VSTePによるソフトウェアテストの開発
- （※3）出典：VSTePによるソフトウェアテストの開発
ブース対応で感じたQAの可能性
今回はスポンサーブースに立ち、来訪者への対応をおこなう機会もありました。具体的な実装に関する受け答えができないので不安でしたが、いざやってみると、QAならではの強みを発揮できたと感じています。
- プロダクトの「体験」を提供：テスト用端末を使って来場者に実際にプロダクトを触ってもらうことで、コードだけでは伝わらない魅力を伝えることができました。
- 多様な情報提供：テックブログやウェルミーマガジンなど、プロダクト以外の情報も提供することで、来場者との会話を広げることができました。
- QAの魅力を発信：開発チームの中でQAがアジャイルに活躍していることを開発メンバーからも話してもらえて、QAの存在や魅力がより伝わったかと思います。また、ウェルミージョブの開発チームが「異なる業種間のコミュニケーションが良好なチーム」であるという魅力が発信できた点も有意義でした。さらに、来訪者の方にはQAの話に興味を示してくれる方もおり、QAからの情報発信の場として開発系カンファレンスは有効な場所となる可能性を感じました。
たくさんの人との出会い・関わり
2日間のセッション聴講やスポンサーブース対応を通じて多くの方々と関わることができました。開発業務が主担当ではない私の参加を歓迎していただき、また、QAという領域にも興味を持っていただくことができました。いずれの方も、カンファレンスへの参加や交流を心から楽しんでいる姿がとても印象的でした。
- 運営メンバー
- ブース対応を共におこなった開発チームメンバー
- ブースの来訪者
- 他社ブースの方、本屋さんやコーヒーなどを提供してくださった方
- 現在一緒に業務している方、過去に業務でご一緒した方
- 開発チームメンバーの方の紹介があって出会えた方…
また、私が身に着けているエス・エム・エスのロゴを見た多くの方から「○○さんの会社の」と声をかけていただきました。これらの出会いは、エス・エム・エスで活躍する人のつながりによって生まれた貴重なもので、私もそのつながりを大事に紡いでいきたいと思います。
一方で、普段とは違って多くの人と関わる場面のため、意識して気を付けようと思ったことがあります。それは「人を尊重すること」です。
- 安心して気持ちよく過ごせるために：アンチハラスメントポリシーはもちろん遵守します。さらに、そこからもう一歩踏み込んで「お互いが気持ちよく安心して過ごせるためのマナー」も大事にしたいと思いました。
- 楽しいからこそ要注意！：楽しさから気が緩んでしまったり、一体感や高揚感から「このくらいの言動は大丈夫だろう」と判断を誤ってしまうかもしれません。「普段から私は気を付けているから大丈夫」と過信せず、一呼吸おいて判断することが大事だと思いました。
- 尊重する相手は「すべての人」：尊重する相手は、お客様にあたる立場の方・運営メンバー・自社のチームメンバー・友人知人・会場や廊下などでたまたま物理的に距離が近づいた人と多岐に渡ります。そして（私の個人的な感覚かもしれませんが）「自分自身」もその対象に入れると、自然に「すべての人を尊重する」が実行できるような気がします。そのため、自分自身も大事にしたいなと思いました。
まとめ
今回の開発系カンファレンス参加を通じて、開発エンジニアとQAエンジニアは「よりよいプロダクトを作りたい」という同じ気持ちを強く持っていることを再確認しました。
「dynamicにシンプルに」プロダクト開発を進めることは容易ではありませんが、関わる人と相互理解のもとコミュニケーションをとって楽しんで実現していけると確信しています。
QAが開発系のカンファレンスに参加する意義は、自身のスキルアップだけでなく、QAの存在や意義を広く知ってもらうことや開発・QAの相互理解からの連携強化にも繋がります。開発エンジニアのみなさんにも、ぜひ品質保証に関するカンファレンスに参加していただけたら嬉しいです！
「コードが書けないQAが開発系カンファレンスに参加する」、2回目のチャレンジを目指して現在鋭意調整中です！
お知らせ
スポンサーブースで大好評だったウェルミージョブのソースコード公開は、カジュアル面談にておこなうことも可能です。「カンファレンスへの参加が叶わなかった」「時間がなくてブースに行けなかった」「ブースでコードを見てみたが、もっと見たい」という方がいらっしゃいましたら、ぜひ、カジュアル面談しましょう！ @moroをはじめとしたウェルミージョブの開発メンバーが（ご要望あればQAメンバーも）、みなさんとお話できるのを楽しみにしています。
