はじめまして。プロダクト開発部の横田です。昨年の12月より、QAグループのマネージャーをやっています。
グループとしては12月に正式に発足しましたが、グループになる前からの準備期間を含めると、すでにおよそ9ヶ月が経過していました（早い・・・！）。
せっかくなので、ここまでの活動を振り返りがてら、グループを立ち上げた直後にしたことの話でも書いてみようかと思います。
少々長い話にはなりそうですが、よかったらお付き合いください。
プロダクト開発部とQA
この話を始める前に、部門としてQAはどういう歴史を辿ってきたかについて触れてみようと思います。
前身
実はかつて、部門としてQAを担うチームが存在していました。もうかれこれ8年くらい前のことです。
少数かつ別業務と兼務するようなメンバーばかりながらも、なんとかやろうとしていたのですが、開発メンバーが増えていくなど、様々な事情があり、発展的解消となりました。
以降、プロダクトの品質は、開発者個人、後にフィーチャーチームとなった各チームが、暗黙的なノウハウを継承しながら維持していくことになります。
メンバーも徐々に代替わりしていくうち、QAという存在があったこと自体を知る人の割合もかなり少なくなりました。
再出発
ちょうど1年くらい前のことです。開発部内で大きな体制変更がありました。
詳細はこちらの記事によくまとまっていますが、フィーチャーチーム形式からの脱却が図られ、ひとつの機能を複数のチームが触るようになりました。チームの人数も1チームあたり3人程度のサイズに分割され、ノウハウを持ったシニアなエンジニアがいるチームとそうでないチームができるなど、プロダクトに関する知識にも濃淡が現れ始めました。
そんな組織の変化の中、改めて横断的に品質を見るQAが必要なのではという発想に至ります。
立ち上げ前夜
実は、テストを専門にした会社から業務委託としてお手伝いしてくれているメンバー4人で構成されたグループがすでに存在していました。
メインの領域はモバイルアプリのテストで、それ以外の領域は依頼ベースでお願いするスタイルです。
彼らとの窓口は、アプリチームのリーダーで、必要に応じて連携を取っていました。
このチームリーダーに代わって窓口になるところから、私がQAグループを立ち上げる話が始まります。
はじめにやったこと
大きく3つです。
- 過去に存在したQAグループの歴史を紐解くこと
- QAグループは何をするべきか考えること
- メンバーのニーズに耳を傾けること
過去に存在したQAグループの歴史を紐解くこと
当時のQAメンバーにお願いし、かつて役員たちと議論していた頃のスライドをもらいました *1。
その資料は120ページ超にも及ぶ渾身の資料なのですが、そこから個人的に読み取ったのは以下のことでした。
- 走るプロジェクトの数に対して、人手が不足していた
- エンジニアの品質に対する意識があまり高くなく、軽微な不具合がテスターの工数を圧迫した
- 専門的な知識を身につけることもままならなかった
当時と今を比べてみます。
- 同時並行するプロジェクトは増える一方である点は今も昔も変わらない
- 品質は各エンジニアが見ていて、軽微な不具合を出すことは少なくなった（ような気がする）
- 社員に専門家はいないが、専門の業務委託メンバーはいる
エンジニアだけで50人はいて、場合によっては一人で終わるようなプロジェクトが複数走っている状況を踏まえると、現状の人員で全部のプロジェクトのテストを請け負うようなことをすれば、やっぱり破綻するのは変わらないでしょう。
当時とは違い、専門の業務委託メンバーがいるのが今回の強みではありますが、テストを請け負うことばかりに傾倒すると、ただの社内下請けで終わってしまう感触にも不安を覚えました。
QAグループは何をするべきか考えること
壁打ち相手と呼べる人もいなかったこともあり *2、ひとりで何回かブレストしました。
テーマは、QAグループは何をするべきか。その前段として、今の組織の中でQA活動を通して得られる理想の状態とはどういう状態か、連想されるキーワードは何か。思いつくままに付箋に書き出し、いくつかのカテゴリーにまとめていきます。
最終的に6つの領域に分類しました。現状把握、技術、情報整備、プロセス改善、対外指標、組織体制の6つです。また、プロダクト面、ビジネス面、それぞれへの貢献が期待できる、といった2つの最終目標も浮かんできました。徐々にQAがターゲットにすべきトピックが見えてきた気がします。
続いてこの6つの領域が互いにどういう関連を持ちそうか、矢印でつないでいきます。矢印は完全にフィーリングです。この領域のことを始めようと思ったら、前段階にこの領域が関わりそうだな、とか、この領域に手をつけたら連動してこの領域が動きそうだな、とか、思いつくままにつないでみます。最終的にこんな感じになりました。
このあたりまでできてくると、まずは現状調査を行い、技術領域、情報共有領域、プロセス改善領域の施策につなげ、ほかの領域に関しては当分は手なりで進めようかという方向性が、徐々に見え始めます。ほかにも、つないだ矢印のInとOutの合計数を出してみて、特に重要な領域はどこなのか、定量で計ってみよう、みたいなこともしてみたりして、今後やっていくことについて、できるだけ仮説を立てていきました。
メンバーのニーズを聞いてみること
とはいえ、ここまでほとんどひとりワークなので、本当に妥当かどうかと言われるとちょっと自信はありません。いずれにせよ、さっきまでのワークで現状調査から手を付けるのは有効であろうと思えたので、アンケートを取ってみることにしました。新たに加わってもらったQA推進の業務委託メンバーにもアドバイスをもらいつつ、通算2度、アンケートに協力してもらいました。それぞれの回収率は50%ほど。特にリーダー層の声は大事にしたかったので、音沙汰がないときは個別にメッセージを送って書いてもらったりもしました。そこから以下のような傾向が見て取れました（ほんの一例です）。
- テストに多くの時間を割いているのに、十分にできている実感が持てていない
- モバイルアプリにはリグレッションテストがある一方、Webアプリには存在せず、テストケースが都度作り捨て状態になっている
- どちらかといえば既存のテストは、新規のテストよりもウェイトが少なめである
最終的に
これらを踏まえ、概ねの方向性を以下に決めます。
- 歴史的経緯から
- いきなり全プロジェクトのテストを請け負うことはしない
- 並行でテストや品質に関する知識はつけておく
- アンケートから
- プロダクトに関わる人数比上、最大効果を狙っていく意味を込めて、Webアプリからテコ入れを図る *3
- 最初に着手するのはリグレッションテストにする
- 戦略分析から
- 将来的には自動化も考えられたら嬉しいが、考えるのはもう少し先として、今は考えない
- 採用や評価といった領域は気になるけど、最初はそこに囚われず、時が来たら頭を使う
今では
業務委託のメンバーは10人に増え、社員メンバーも、4月に中途入社の方を新たに迎えたことで、私を含めて3人になりました。
開発チームから来るテスト依頼も引き続き請け負いますが、モバイルアプリにとどまらず、Webアプリ、Sansan Data Hubと領域を広げるようになり、部門内で横断的な組織としての一歩を踏み出して来れたかなと思います。
随分長くなってしまいましたが、グループを立ち上げ始めて1～2ヶ月くらいの頃の話でした。
今振り返ってみると、立ち上げ初期に考える時間が多く貰えたのは大きかったですね。今後似たようなことをされる人がいらっしゃった場合の参考になれば幸いです。
