DevRel活動に取り組みたいが、実際にどのような企画を立て、アクションに移していくべきか。とくにDevRel立ち上げ期の企業にとっては悩ましい課題だ。Tech Team Journalでは先般、株式会社タイミー（以下、タイミー）の一人目DevRelとして2023年にジョインし、急速にエンジニアコミュニティを拡大させた河又涼氏を取材した。では、実際に河又氏はどのようにイベントを企画し、運営しているのだろうか。
それを知るべく、今回は4月11日（木）に開催されたタイミーと株式会社カカクコム（以下、カカクコム）の共催イベント「最後の門番はもう古い！？ QA2.0をQA立ち上げ期の2社が語る」に参加。本イベントの内容、企画の背景や狙いについてレポートする。
目次
カカクコムの開発組織全体でQA活動を浸透させる具体策
本イベントではまず、カカクコムでQAエンジニアを務める伊藤由貴氏が登壇。伊藤氏は第三者検証会社を経て2023年に同社へ入社。部門一人目のQAエンジニアとしてQA組織の立ち上げに取り組む傍ら、『ソフトウェアテスト技法練習帳〜知識を経験に変える40問〜』（技術評論社、2020年）の共著など、QAエンジニア育成やエンジニア組織のあり方について発信している。
（伊藤氏のTech Team Journalでの寄稿記事はこちら）
伊藤氏のテーマは『QAがQAしないでQAするために』。開発部門の中で複数の開発チームを有するカカクコムで横断的にQA活動を行い、現在組織づくりを進める伊藤氏が目指す姿やそれに対する取り組みについて講演した。
「QAがQAしないでQAする」組織を目指す理由
伊藤氏はまず、カカクコムにおけるQA組織の目指す姿について説明。カカクコムでは開発組織が主体となり品質保証などの活動を行い、継続的に改善できる組織づくりを目指している。まさにタイトルにあるように、「QA（エンジニアだけ）がQA（関連活動を）しないで（開発組織全体で）QAする」あり方だ。このような組織を目指す理由として、伊藤氏は「体制と文化」の両側面に理由があるという。
体制について、現在伊藤氏が所属している価格.com開発本部では、3つの開発部とその下に複数の開発チームがある。伊藤氏もそのうちの1つに所属し、部をまたいで他の開発チームに関しても、横断的にQAを支援する動き方をしている。
「どのようにQA活動をしていこうかと考えたとき、今回のイベントタイトルのように、最後の門番としてのQAチームを組織するのも一つの手段としてはあると思います。しかし、もしも『QAに関することはすべて私を通してください』となると、ボトルネックになるのが目に見えているので、少なくとも今の体制ではできません。また、今後そのような体制を目指して組織をつくっていくのも現実的ではないと思っています。最近QAエンジニアの採用が難しいとよくいわれていて、私自身も実感しているためです」
もう一つの理由としてあげた文化面での理由について、伊藤氏は「個人的にはこちらの方が大事だと考えている」と語る。価格.com開発本部では、開発者自身がテストを行っている。伊藤氏が入社するまでQAエンジニアがいなかったこともあるが、同社では基本的にテスト業務のアウトソースはせず、開発者自身がチーム内でテストをすることが当たり前に行われてきた。伊藤氏はここで、QA組織を立ち上げることによって「開発者からテスト業務を『剥がす』ことの是非」を提起した。
「たしかに、テストチームとQAチームをつくり、テスト業務を分離することで開発者が自分たちの得意な分野により集中できるメリットはあると思います。 一方で、開発者が自分たちでテストもするからこそ得られるメリットもあり、それが損なわれてしまうようなQA組織づくりは違うと考えています。
そのような理由もあり、QA組織自体の体制を厚くして業務全体を担うのではなく、あくまでも開発者主体で今の良い面を継続し、より加速させるサポートを行うQA組織を目指しています」
組織全体でQAを自分ごと化するための取り組み
では、上述のように開発者全体でQA活動を促し、それを支援する形でのQA組織をつくるために、どのような取り組みをしているのだろうか。伊藤氏は現状の取り組みから2点を紹介した。まず一点目が「QA活動の指針、現状把握の手段を提供」することだ。
「たとえば、ただ開発者に『QA活動頑張ってくださいね』と言うだけでは、当然物事は進まないので、指針を提示する必要があります。 そのためのQAガイドを作成し、それを皆さんに見てもらって、目指す姿を打ち出しているところです。当社の場合はサービスの性質も異なるので完全な標準化・統一化をするつもりはありませんが、チームを横断し最低限の土台を示すものとして公開しているのがQAガイドです。
しかし、ガイドを公開したからといって活動が進むわけではなく、フォローやサポートが必要になります。そこで作成したのがQAクライテリアです。これはQAガイドに則った品質保証やQA活動を、各開発チームがどのくらいできているのかを把握するためのセルフチェックです。30問ほどの質問項目を5段階評価で回答してもらい、私の方で集計・可視化しています。QAクライテリアは開発組織全体への意識づけと同時に、現状を可視化することにも役立ちます」
もう一点が「テストのスキルや考え方の伝達」。テストを始め、開発者一人ひとりがよりよくQA活動に取り組んでいくために、QAエンジニアやテストエンジニアが持っている知識やスキルの共有を進めているという。その中で伊藤氏はQMファンネルについて触れ、QAコーチやQAコンサルタントの役割には、QAの技術移転や品質文化の浸透、技術向上が挙げられると紹介。その際の心がけや考えについて、「QAやテストエンジニアがセオリーであるやり方をそのまま開発者に実行してもらうのは難易度が高い」と語る。
「まず、現場を見てこのくらいだったらやってもらえるというレベルに小さく分解し、実際に試して効果を実感してもらってから理想に近い形に仕上げる。段階を踏んだコントロールをQAの方でやるように心がけています。また、開発者から相談を受けることもありますが、そのときに正論だけ話すのではなく、チームの状況を加味して今やるべきことをセットで伝えることが、実際に行動を起こしてもらうためには非常に大事だと考えています。
QAやテストエンジニアが持っている知見を日々伝えていくことも大事ですが、一番開発者に重要性を理解してもらえるのは、困っているときや課題感を持っているときです。しかし、そういった機会がいつくるのかは当然わかりません。そのため、普段から勉強会を定期開催しナレッジベースを拡充して、タイムリーに応えられるような日ごろの準備を心がけています」
このような取り組みによって、徐々にQAクライテリアの数値も改善し、QAの支援依頼や相談も増えてきているという。目指すべき組織のあり方について手応えを感じる一方で、現状一人QAであるがために「パワーが一人だけだと足りないのが本音で、改善のスピード感を出していくのが課題」と語った。
チームトポロジーを採用する開発組織でのQAのあり方
タイミーからは、2024年にQAコーチとして同社にジョインした矢尻真実氏が登壇。矢尻氏は、ファーストキャリアを神主として過ごした異例の経歴の持ち主。その後受託開発SEやERPパッケージの導入コンサルタントを経てQAエンジニアに。現在はQAコーチとして活躍する。
講演テーマは『駆け出しQAコーチがチートポ型組織でQAしないで価値を届けたい話』。矢尻氏は取材時点でタイミーにジョインしてから3か月ほど。その中で取り組み始めたことや、今後予定している取り組みについて語った。
「モヤモヤ」の解消から始まったQAコーチ活動
講演冒頭、矢尻氏はタイミーの開発組織のあり方について説明。タイミーは開発組織の設計にチームトポロジーを採用している。チームトポロジーは、ビジネスや技術観点での戦略の変更に適応するための組織設計モデルだ。機能開発を担う「ストリームアラインドチーム」を中心に、特定領域のスペシャリストによるチームの能力ギャップを埋めるための「イネイブリングチーム」、スペシャリストの知識に依存しシステムを構築する「コンプリケイテッドサブシステムチーム」、機能開発チームが自律的にデリバリーできるようにする「プラットフォームチーム」で構成される。
このような組織構成の中で、矢尻氏はイネイブリングチームに属し、銀行と連携したワーカーへの給料支払や、キャッシュフローの管理システムを開発するIronBankチームでQAコーチをしている。まさに「鉄の守り」でお金を管理し、攻めの姿勢で機能開発を行うチームだ。では、そのような組織のQAコーチとはどのような役割なのだろうか。
「タイミーが最後の門番としてQAを施行しない一番の理由は、スタートアップやベンチャーにとって、リードタイムの阻害がビジネスリスクになるためです。プロダクト品質とデリバリーはトレードオフではなく、信念を持って高速に価値を届けること、これがビジネスの成功に必要不可欠と考えています。そのパイプラインの中でQAがチームに組み込まれ、可能な限り自動化されたテストを行い、まさに高速に石橋を叩きながら機能を開発してデリバリーしていく。その精度を上げるためには、QMファンネルにおけるQAコーチとしての振る舞いが最適と判断し、現在活動しています」
一方で、QA不在の開発組織の中で、コーチとして飛び込んだ当初は苦労したという。しかし、矢尻さんは「これも相互理解と文化の浸透のチャンス」と捉え、メンバーとのディスカッションを進めていった。
「チームビルディングの際、メンバーから『矢尻さんの話、ちょっとモヤモヤするんだよね』と率直な意見をもらいました。少しショックでしたが、正直な意見をもらえたのはとてもありがたかったですね（笑）。タイミーにとってのQAのイネイブリングは『モヤモヤ』を晴らすことから始まりました。
このような基本的な認識を合わせていくことは非常に重要だと考え、まずは『QAコーチって何者？』というところから図を用いて説明していきました。プロダクトエンジニアの方にも、品質保証の範囲をプロダクトだけではなくプロセス品質にコミットする必要があること。また、QAコーチとしてあらゆるステークホルダーに価値提供をするために活動していきたいという思いをていねいに共有し、少しずつ理解を深めていきました」
矢尻さんはQAコーチの役割とともに、開発組織におけるQAの認識の齟齬を埋める取り組みを深めていったという。その事例としてまず上がったのが「QA＝テスト」という認識だった。
「スクラムマスターが共同でチームをゴールに導き、環境を整備する役割を担うように、品質をチェックしながら高速にデリバリーするためのパイプラインの構築を支援するのがQAエンジニアの責務だと説明しています」
一方で、現状QA立ち上げ期に当たるタイミーでは、QAを専門とするのは矢尻さんしかいない。おのずと（矢尻さんだけが）QA（関連活動を）しない組織のあり方が求められる。そこでまず必要となったのは、現行でやっているテストが何の目的で行われているのか、その内容で十分なのかを整理することだった。矢尻さんはアジャイル開発手法の文脈でどのようにテストを行うのかを整理し、認知を統合するため、それぞれのテストとその目的をマッピングしたアジャイルテストの四象限マトリクスを共有したという。
自律的にQA活動を行う開発チームを目指して
このように、1年目のQA立ち上げ期の第一歩として認識の共有を進めている矢尻さんだが、具体的にはどのような取り組みを行っているのだろうか。矢尻さんは「発展途上のところも多い」ことも踏まえ、現在までの手順を以下のように説明した。
「最初の段階は『現在地の評価とビジョンの共有』です。具体的にどのように品質保証を進め、どのようなチームを目指すか。そこにたどり着くまでのマイルストーンをディスカッションし、ビジョンを掲げました。ディスカッションは、さきほどお話ししたようにQAに関するモヤモヤを認識する機会にもなりますので、それを足がかりに相互理解を深めていく。そして、まずはQAコーチから一般的な知識体系、 テクニックをティーチングする形で、イネイブリングを進めていきました。
次の段階は『自分たちのQA活動を確立する段階を目指す合意形成』です。費用対効果の高い活動をアレンジし、トライアンドエラーを繰り返しながらアウトカムを最大化させていくことを共通認識としました。そして3つ目の段階は『具体的な目標の設定』です。最終的に最高のQAをすべてマスターし、QAがいなくても自分たちでQAできる状態がゴールであり、そのころには誰に話しても恥ずかしくないプラクティスが確立されていることでしょう。しかし、そのためには、どういったことをやり、どのような目標をクリアすべきなのか。ここでもアジャイルテストの四象限マトリクスを参照しつつ、ディスカッションを進めていきました」
目標設定でのディスカッションでは、チームやプロダクトの抱える品質課題を洗い出すため、矢尻さんは「夜も眠れないような課題はないか」と投げかけ、チーム全体での本音の議論を促したという。そこから列挙されたプロダクトリスクやプロセスにおける課題がどのテストで担保できる問題かをマッピング。リスクが高い課題に対しては効果が見込めるテスト活動、とくに開発者テストとして実行できる自動テストは何かを選定した。
現在はユニットテストのカバレッジ向上や、コンポーネントより上のテストレイヤーの強化に取り組む。「将来的には機能横断的な取り組みとして、E2Eの回帰テストや実際の顧客満足、価値を確認するためのステークホルダーを巻き込んだ探索的テスト、受け入れテストも実施していきたい」と語る。
矢尻さんはイネーブリング活動をする上で大切にしていることとして、『スクラムガイド』（Ken Schwaber & Jeff Sutherland）の一節”知識は経験から生まれ、意思決定は観察に基づく”を引用する。
「実際に自分たちで課題を発見して、試行錯誤をしながら問題を解決することで得られる経験は、体系的知識になると思っています。またときには失敗すること、継続的な反省や改善を通じて初めて、自律的活動に結びつくとも感じています。
今回引用した部分では、スクラムチームが現実のデータや観察に基づいて意思決定を行うことを強調しています。 つまり、主観的な意見や予測だけじゃなくて、実際の状況だったり進捗状況を客観的に観察し、それに基づいて適切な意思決定を行うことも重要だとも考えています」
タイミーのQAコーチとして歩み出した矢尻さんは、すでに同社のより良いQAのあり方に向けて歩み出している。最後に、矢尻さんは以下のように締め括った。
「ご覧の通り、現状はまだ発展途上でやることも満載で、真っ白のキャンバスのような状態です。アドバイスやご意見をいただけるとうれしいと思っています。同時に今日お話ししたような当社QAのコンセプトに共感していただける方がいれば、ぜひ一緒にミッション、ビジョンの実現のためにご一緒できたらうれしいです。ご興味のある方はぜひお声がけいただけたらと思います」
DevRelとしてのイベント企画の狙い
本イベントは伊藤氏、矢尻氏それぞれの講演とパネルディスカッションの後、懇親会を経て終了。リアルでの当日参加は20名以上、オンラインでの事前申込数は130名となった。今回のイベントはQAエンジニア向け、とくに社内でQA組織の立ち上げや活動のあり方を組み立てる「一人目QA」にターゲットを絞ったイベントの中、ハイブリッドで多くの参加者を集めた。今回のイベントにはどのような狙いがあるのだろうか。河又さんに聞いた。
「タイミーはまだまだQA立ち上げ期ですが、その中でもフェーズゲート的QAではなくQAをEnableしていく本日登壇した矢尻のようなQAコーチを採用して取り組んでいるのは珍しいのではないかと思い、それを発信して世に学びを共有したい目的がまず1つ。そして今回はカカクコム社の伊藤さんをお招きしましたが、伊藤さんも当社と同じく一人目QAとして近しい取り組みをしています。QAを推進している中で得た知見や苦労されている面も含め、さまざまなことが学べる機会になると思いました。当社としても伊藤さんの知見から学びつつ、イベントにすることでより多くの人と学びを共有したいと考えて企画しました」
河又さんは前回の取材時に「コミュニティに貢献する、技術の知見共有においてしっかりとギブの精神で誰かの役に立つことを一番に考えてやっていくのが大事です」と語っていた。今回のイベントはまさにギブの精神に立脚している。実際、懇親会の場で参加者に話を聞くと、QA組織のマネジメントに悩みを抱える参加者や、社内カンパニーとしてQA組織を立ち上げたばかりの参加者もいた。講演による学びとともに、参加者同士での知見の交換もなされる場が醸成されているのが印象的だった。
一方で、タイミーとしてもイベントを通して得るものはほしいところだろう。自社のイベントとして企画するにあたり、どのような点を意識しているのだろうか。
「細かいポイントでいえば、タイミーとしてイベントを多く開催し認知を獲得したい意図もありますが、当社におけるQAのあり方も、まだまだ少数派だと思っています。こういうやり方もあると発信した結果、取り入れようと思ってくれる人や会社があるのであれば、世の中にもいいと思っていますね。
加えて、会社のメンバーにもさまざまなイベントに登壇してもらい、個人のプレゼンス向上にも寄与していきたいと考えています。会社としてしっかりバックアップし、本人が望むのであれば、機会が提供される環境はあるべきだと考えています」
河又さんがタイミーにジョインしてからは、このようなDevRel企画でのイベントは毎月開催されているという。そこで気になるのが、立て続けにイベントを開催するにあたって、どのような発想で企画を立てているのかだ。例として、今回のイベントはどのようなプロセスで企画を立てたのだろうか。
「毎月イベントを開催していくとなると、登壇者に偏りが出ない様にさまざまなテーマで開催したいものです。それで、これまでのテーマのローテーションの中でまだQAをやっていなかったというのが出発点の一つで、もう一つが直近で矢尻がジョインしたことがあります。社内のアセットとしてもチャンスがあり、矢尻も登壇に前向きだったので、企画の具体化を進めていくことにしました。
具体化にあたっては、QAの知見が豊富な人をお招きして自分たち自身も学びが得られる様な会にしたいと考えていました。伊藤さんは前職時代に企画したイベントで登壇をお願いしたこともあり、知見が豊富な方だということは認識していました。当時は伊藤さんもカカクコムに入社される前だったのですが、現在はカカクコムさんに転職されて開発組織の中の一人目QAということで弊社の矢尻と状況が近いということもあって、今回の一人目QAにフォーカスをあてたイベントを開催することにしました」
今回のタイトル「最後の門番はもう古い！？ QA2.0をQA立ち上げ期の2社が語る」も登壇者のアサイン後、キックオフミーティングで伊藤氏と矢尻氏の話を聞く中で生まれたものだという。
最後に、コンスタントにイベントを開催・成功させている河又さんに「エンジニアに刺さる企画の立て方」とはどのようなものなのか、率直な意見を聞いた。
「まず、『何を持って刺さっている』とするかの話もありますね。たとえば、ただイベントの参加人数だけを指標にするなら、エンジニアの母数が多い領域やトレンドの話題で企画をすれば参加登録は伸びやすいです。しかし、需要があることとリーチしたいエンジニアに刺さるというのは別物だと思っています。
そういう意味で、DevRelが企画で意識すべきはいかにエンジニアに役立つものを提供するかだと思っています。人数が伸びるか否かではなく、まずは聞きに来た人に満足してもらえるコンテンツだと確信できる企画、今日や明日から役立つような情報を届けられる企画を立てる。そのような感覚を大切にしていますね」
（取材／文／撮影：川島大雅）
