はじめに
株式会社ビットキーでQAをしているやきょ(@yakyo_824)と申します。
前回、こちらの記事では大枠としてQA組織がどういう変遷をたどったかについて説明しました。
その中で別記事にて公開予定としていた「組織体制変更における取り組みや課題と、それをどう乗り越えたか」について、この記事で話していきたいと思います。
対象読者
-他社のQA組織状況に興味がある方
-他社のQA組織に関する課題とその解決に興味がある方
QAチーム設立の背景と、その初期
ビットキーは創業後、いち早くアウトソーシングを活用し、事業のスピードを落とさずに品質を守ってきました。
ただ、アウトソーシングには以下のデメリットが存在していました。
-コミュニケーションが複雑になる
-社内にアセットやナレッジの蓄積が難しい
加えて、外注率100%であることもリスクであると考えられた結果、QAチームを設立することになりました。
そうしてビットキーとして一人目QAの採用を行った結果、私がジョインしました。選考の段階で上記QAチーム設立の背景は伺っており、入社したら何をするのか明確でした。
そうしてリファラル採用にも成功し、ビットキーの内製化は2022年10月よりスタートしました。その時点では、マネージャー1人のメンバー2名という体制でした。
内製化における変遷図
上記は内製化におけるunitの新設と廃合を示した図です。
unitとは、ビットキーにおける最小の組織単位です。実際にビットキー社内においても他部署から見ると、上記の図のように移り変わったはずです。
これを参考情報に、続けて説明していきます。
大きな出来事
内製化をスタートしたあと、重要な意思決定としてアウトソーシング先のリプレイスがありました。これは2022年12月に行われ、これにより2023年1月~5月にかけてリプレイスのプロジェクトが発足されました。
2023年6月以降、リプレイスによる大きなインシデントもなく、結果としては成功と言えるかと考えています。
具体的な取り組み
このプロジェクトで取り組んだのは以下の4つです。
-リプレイス後の体制検討と人員アサイン
-リプレイスの対象であるパートナーとのコミュニケーション
-テストウェアの取捨選択
-全体の状況をモニタリングし、プロジェクトをマネジメントできる体制の構築
<リプレイス後の体制検討と人員アサイン>
引き継ぎが必要かどうか、引き継ぐ場合の体制はどうするか。人員のアサイン含めてかなり苦悩しました。
ただ最終的に、B社は引き継ぎを行い、オフショアは引き継がず必要なテストウェアを再利用する方向にしました。
この差は、大きく分けると以下の要因があります。
-事業やビジネスにとって重要な領域であるか
-ほかのQAチームで代替もしくは再利用できるか
これらを考慮した結果というわけです。
また人員面のアサインについては、採用に自身が関わっていて選考の段階で見極めながら、という点もあり、能力的には問題ないという判断で「内定->入社->アサイン」の形で大きな問題は起きませんでした。
ただ、この点においてはメンバーにも恵まれていると考えています。なぜなら、任された業務の難易度が高く、プレッシャーがかかる場面でもモチベーションを高く維持して結果にコミットしてくれたことは、決してマネジメントの成功のみで語れないからです。
<リプレイスの対象であるパートナー社とのコミュニケーション>
意思決定後、上長とも密に連携を取りながら、細心の注意を払ったのはこの部分といえます。相手からすれば決して望んだ結果ではないその心情に寄り添い、いかに円満にクロージングするかが重要でした。
正解はないと思いますが、私たちが留意したポイントは以下です。
-意思決定を行なった時点で、必要な情報共有を添えて迅速に相手にそれを伝える。
-期間はある程度確保し、相手に伝える。そのうえで、タイムスケジュールなどの計画は相手も交えて一緒に考える。
-定期的な接点は、これまで通りに維持或いは頻度を増やす
また、リプレイスの意思決定以降の留意点は重要ですが、これまでの関係性が大きな影響を与える可能性もあります。そういう意味では私は当時入社して間もない頃ですので、ほかのメンバーが適切な関係性を構築してくれていたことにもなるかと考えています。
<テストウェアの取捨選択>
実務的な面でいうと、テストウェアは会社の資産として重要な役割を果たします。テスト活動を行う中で必要なもの、エビデンスとして残す必要があるもの、実に多種多様です。
リプレイスでもまず、テストウェアの引き継ぎは必ず行うよう調整し、そのすべてを受け取りました。そのうえで、どう活用していくかについては、体制も含めて取捨選択をする必要がありました。
特に、わかりやすいものでいうとローレベルテストケースになりますが、今後もそれらをテスト実行するか否かは、テスト活動に必要なリソースにも直結しますので、膨大な作業ではありますが、丁寧に紐解いていく作業を行いました。
こういったテストケースメンテナンスないし、テストウェアメンテナンスは経験済みの方も多いかと思いますが、参考程度に私が再利用しないと判断した基準を記述します。
-テストスコープ的に、ほかのQAチームと重複している部分
-過去は使われていたが、現在は使われていない機能の部分
-すでにほかの指標や手法があり、あえて利用する必要がない部分
<全体の状況をモニタリングし、プロジェクトをマネジメントできる体制の構築>
2023年2月には品質管理のunitを立ち上げ、ほかにも役割はありますが、その1つとしてリプレイスのプロジェクトのモニタリングを兼ねていました。
定期的にプロジェクトの進捗をリプレイスをする側とされる側の双方から報告を受け、必要に応じてサポートできる仕組みを作りました。その背景として当時、QAプロパーが本当にアウトソーシング先の業務を代替できるかどうかについて、そもそも確信はない状態でした。
結果として品質が悪化してしまい、大量の不具合が市場に流れ出るのではないか、というリスクや、そもそも引き継ぎの段階で能力差的に引き継げないなど、幾つかのリスクが考えられていました。
それらのリスクを即時に検知し、対策を講じることができるように、この体制を構築したことは振り返っても良い取り組みだったと考えています。
また、このunitはリプレイスのプロジェクト完了後、2023年6月末で一度解散されていますが、テストプロセス改善と標準化というunitがその役割を細分化した状態で担い、そして2024年4月からはより大きな組織単位のteamとして確立されました。
直面した課題とその解決策
ゼロから立ち上がったチームですので、そもそも独自の技術体系がまだ構築されていない状態でした。テスト設計をどのように行うか、テスト実行をどのように行うか。その他も含めてすべてがない状態です。
そして、アウトソーシング先の各社もそれぞれ異なるやり方で業務を進めていましたので、技術的な課題として、どのような技術体系を構築するか、という所からスタートしました。
それに対する解決策としてもっとも最初に策定したのが、QAの技術体系はJSTQBに準拠する、というテスト戦略でした。これを自分の手でドキュメンテーションし、1つのアウトプットとして上長の裁可も頂いたうえで、次は実務レベルでの具体的な技術体系策定に着手しました。
既存の成果物を参考に取り入れることもあれば、ゼロから新しい仕組みを構築することもありました。実例でお伝えします。
<既存の成果物を参考にした実例>
テストケースが記載されているGSSのフォーマットは、そのまま流用しています。一から作るよりも、すでに会社の資産となっているそれらを活用するほうがパフォーマンスに優れているためです。
<ゼロから新しい仕組みを構築した実例>
アジャイルテストでありながらアウトプットにも妥協せず、新たにテスト計画書とテスト完了報告書のフォーマットを作成し、テストプロセスにおけるテスト計画とテスト完了の意義も添えて導入しました。
まとめ
ビットキーは、アウトソーシングにおける課題に対応するため、2022年10月にQAチームの内製化を開始しました。主な取り組みとして、2022年12月にアウトソーシング先のリプレイスを決定し、2023年前半にプロジェクトを実施し、これについて今回、詳細にお話しました。
このプロジェクトによってどういう成果があったのかについては、こちらの記事に記載されていますのでぜひご一読ください。本記事においては、冒頭でも述べている通り、「組織体制変更における取り組みや課題と、それをどう乗り越えたか」にフォーカスしています。
振り返ってみると、全体的に個人の力だけでは突破できないような難しい局面において、全ての関係者が一丸となってプロジェクトを推進し、大きなインシデントもなく完遂できたことは、私自身にとっても得難い体験でした。
そういった局面において、実務的な能力は当然求められるが、ほかにも以下の点が重要であると考えています。
-いかに円滑に協力しあい、事業として、会社としての成功や価値に繋げていくか
-そのために自分はどんな役割を担えるか
-その役割を担うにあたり、必要な説明やコミュニケーションを十分に果たしているか
自身が取り組んできたことをベースに今回お伝えした内容が、1つの成功事例として誰かのお役に立てれば幸いです。
Discussion