はじめに
ソーシャルデータバンクで運用管理部という保守運用をするチームでマネージャーをしている田村です。
今回の記事では、私が入社して間もなくQAチームを立ち上げるにあたって考えていたことや気をつけていたポイントをまとめてみました。マネージャー視点だけでなく、プレイヤー視点でマネージャーへ求めること、として参考にできるかもしれません。
準備：どこから手をつけるか？※QA関係なく一般論として
同じ仕事をする、チームに溶け込む
自身が所属するチームの業務を知る・一緒に働く人を知るためにも同じ業務をこなします。自ずと”何か”がうまくいっていないことを感じることができます。チームメンバーとの距離感もグッと近づきます。
カルチャーを知る
カルチャーがどのようなものかを知る。これは、新しい施策を受け入れてもらうためにどのような手法をすれば、新しい仕組み＝新しい仕事＝仕事が増えることを許容してもらえるか考えることに繋がります。
業務フローを把握する
- 前述の”何か”を深掘りするためにも必要。同じ業務をした仲間と一緒に業務フロー図をアウトプットする。業務フロー図を作る過程で、問題点の輪郭がハッキリしてきます。
- 業務フローを分析する上で意識したいのは部署と部署もしくはチームとチームの間では往々にして軋轢が発生し、お互いにコミュニケーションなどの課題を持っていることが多いです。こういった課題が同時に解決するようにすることも新しい仕組みを受け入れてもらうためのポイントです。
ポイント：具体的な実践内容
プロを連れてくる
内部にQA領域の専門家が不在であったので、外部から連れてきました。たまたま以前一緒に働いたことのあるSESのQAエンジニアの連絡先を知っていたので、連絡のうえ各種調整を行い来てもらいました。
詳細な取り組みは、ベンチャー企業でQAチームを立ち上げました をご覧ください。
ここでプロを連れてくるのは、開発者に対して影響力を持たせるためです。プロの言説は説得力が高く新しいものを受け入れてもらい易くなります。
QAチームの権威付け・権限移譲を行う
QAチームのメンバーは、どうしても部内・チーム内ではウォーターフォール上の下位に位置した役割で下請け的なケースが多いです。これでは、新しい仕組み導入の障害となります。QAという取り組みの重要性を部内で啓蒙する、QAメンバーに権限があること責任ある立場であることを理解してもらい寄り添いながら物事を進めてもらうことを重要視していました。
今回幸いなことに技術者からQAを本格的にやってみたいという人間をQAチームに参画させることができました。そのことによって、QAvs開発といった対立構造ができにくい体制になりました。人手不足な中、プロパーからQAチームへのジョインがなされたのはラッキーでした。
ソフトランディングで小さく変化させる
大きな変更を強いると反発も生まれ、試行錯誤をして成果が出る前に施策が有耶無耶になってしまいがちです。そこで、小さな変化をコツコツと取り込むように促していきました。
引き算する
新しい取り組みをするにあたり、現在やっている無駄な仕事を引き算して無くしていくということもできました。新しい取り組みを始める際は、仕事が増えるというネガティブな現象がハードルになりがちですが、ここで最低でも±0にできたのは良い方に転がりました。
効果
本取り組みによって、結果下記のような効果がありました。
- テストフローが整備された仕組み化された
- テスト手法の向上によって品質向上ができた
- プロジェクトチーム内で、シフトレフトが進み品質向上ができた
- テストの自動化の取り組みが進んでいる（進行中）
- QAチーム中心にユニットテストの取り組みが推進された
おわりに
QAチームは下請け・下位に位置付けられてしまいがちです。
しかし、仕組み・検証の担当者を信じて適切な権威付け・権限移譲ができると様々な効能があると考えていました。そして期待を超えた成果を出してくれました。
マネージャーとして身も蓋も無い結論でしたが割と本質へのアプローチ大事ということで結びとさせていただきます。
Discussion