QA部門から開発部門に移ってみて
QAエンジニアが開発プロジェクト内から品質改善をするまでの軌跡 #1
これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2021、第16弾（2021年12月22日）の投稿です！
最近、リモートワークもすっかり板についてきて、オフィスより自宅の方が働きやすい環境が整ってきました。
そんな中、我が家では子猫預かりボランティアをやっています。
かれこれ3年ほど続けているのですが、かわいくて手放せなくなる猫に巡りあってしまうのではと思っていました。
そしてついに巡り合ってしまい我が家に迎え入れることになりました。
名前は「ふく」です。
毎朝仕事部屋に移動すると、一緒に出勤してきます。
リモートワーク環境としてディスプレイやマイクなどだけではなく、癒しも整い、忙しいときには猫の手を借りれるようになり、さらに充実した環境になっています。
はじめに
猫の話はこれくらいにして、今回お話したいのは今年の9月に私が関わっている担当プロダクトの開発部門で大きな組織変更があり、そこで私がQA部門から開発部門に短期留学（開発プロジェクトの品質改善）することになりました。（短期留学なので、すぐにQA部門に戻る予定・・・のはず。）
組織を異動しましたが、関わるプロダクトは変わらずQA部門で得た知識を開発部門で発揮することになりました。
そこで今回のブログでは、QA部門内から見た開発プロジェクトと開発部門のメンバーとして中から見た開発プロジェクトについて話せればと思います。
開発部門に異動と言っても、開発部門の中でテストを担当するチームに移ったので、QAチームからテストチームに移ったといった感じです。
と言ってもわかりづらいと思うので、簡単にプロダクトの組織の説明をします。
開発部門の中に開発チームとテストチームがあります。
そしてQAチームはソフトウェアプロセス＆品質改善部（SQPI部）に属していて、開発部門とは別の組織になっています。
9月まではQAチームとしてプロダクトの品質に関わってきましたが、今は開発部門の中のテストチームとして品質に関わることになりました。
ざっくりそれぞれ何をやっているかというと、私が担当しているプロダクトの開発チームでは機能を実装し、テストチームでは開発チームで作ったモジュールをテストし、QAチームでテストが終わった製品を品質監査するといった感じです。
QAチームでの品質監査について
QAチームだった私は、主に開発プロジェクト内で作られたプロダクトについて、プロセス品質とプロダクト品質をQAの立場からチェックしていました。
プロセスの品質へのアプローチ
具体的には、プロセス品質では開発部門で作成された計画書のレビューを行ったり、デイリーミーティングに参加しリスクとなる事象が発生していないか確認、スケジュールに遅延が発生していないかなどを確認し、スケジュールに収まらない場合は機能を削る提案など、問題があればフィードバックをPOに行うことで、QCDのバランスを調整しています。
プロダクトの品質へのアプローチ
プロダクト品質に対しては、プロジェクト内で作成されたPBI、計画書や、機能仕様書、テスト設計書のドキュメントについてレビューを行っています。
またテストチームでテストされた機能について、作成したテスト設計からサンプリングしたテストケースを実行して動作確認や、最終的なリリース物に対する最終チェックを行っていました。
監査について
前章で監査をしていましたと書きましたが、製品が完成して最後にQAがノコノコ出てきて、偉そうに踏ん反りかえってあれがダメ、これがダメって言うだけの形ばかりの監査にはしたくなく、プロジェクトにできるだけ入り込んで、実際に製品を触り上流工程から品質向上に貢献できるQAになりたいという想いで、上記のような監査を行っていました。
しかし、自分の中では開発プロジェクトの中にがっつり入り込んでやっていると思い込んでいましたが、9月から開発プロジェクトに入ってみるとまだまだ入り込めていないと実感しました。
開発部門に移った経緯
9月に開発部門で組織変更があったと書きましたが、私が開発部門に異動になっただけでなく、それ以外にも開発チームやテストチームのメンバーの半分が別の部門に異動しています。
私の異動だけでなく、開発部門全体で大きな組織変更が行われる状況でした。
とあるジレンマ
まず、なぜ開発部門に移ろうと思ったのかについてですが、QAチームにいた頃、開発チームに対し品質改善に何とか貢献できないかと思い、週次で不具合分析を行い、開発にフィードバックを行っていました。
具体的には、特定の機能で影響範囲の認識漏れによる不具合が繰り返されていたので、影響しやすい機能をフィードバックし注意喚起やリグレッションテストに含められないか提案したり、インストーラー作成を手動で行っている部分があり、それにより不具合が発生していたので、自動チェックの仕組みを提案したりしていました。
このように課題を見つけ問題提起したり改善案を提案したりと、製品の品質を良くしたい想いからいろいろ対策を行っていましたが、実際にはなかなか改善に繋がらずジレンマを感じていました。
そんな時に開発部門で組織変更の話があり改善したいなら、外からじゃなくて中に入ってやってみたらとお誘いがあったのがきっかけです。
断ろうと思っていました
その話をはじめ聞いた時は、QAエンジニアとしてやっているときでも、開発メンバーと寄り添ってやっているつもりでした。
なので、自分の中では結構開発プロジェクトの中に入り込んでやっているし、組織の壁はそこまで感じていなかったのでやることも変わらないんじゃないかくらいに思っていたので、断るつもりでいました。
そんな中、開発部長とQA部長と話すことになり、異動の件は断るつもりで挑んだ打ち合わせでしたが、打ち合わせが終わってみたら、「開発で頑張ってみます！」って言ってました（笑）
決断した理由は、
- 今までのプロセスを全部取っ払って新しいやり方をしてよい
- 開発部のメンバーが移動になり少なくなったことで小回りが効くようになった
- 何かあれば部長２人の後ろ盾がある
の3つです。
今まで改善したいと思っていても、なかなか改善活動に繋がらないと思っていたことが、解決できるんじゃないか？ってワクワクしてしまったので、決断した感じです。
実際、うまくいくかはわからないですが、いろいろできそうだし部長２人が後押ししてくれると思うと心強いです。
今までのやり方を全部変えるとまではいかなくても、何か変えられるんじゃないかって思いました。
それにSPQI部が目指すShift Left戦略にも繋がるチャンスでもあると考えました。
実際に開発部門に入ってみて
そんな訳で9月から開発部門に入り、改善するぞ～！と意気込んで３ヶ月が経ちました。
中に入ってみて思ったこと、思ってたのと違うってことについて書きたいと思います。
開発チームとの距離感
中に入って思ったことは、現場の人との距離が近くなったことです。
QAチームの時は、開発チーム全体に向けてフィードバックしたり、マネージャーと課題について話したりだったので、実際に実装しているメンバーと話す機会が少なかったです。
ですが、開発部門に入ると、開発部門内部のみで行っている定例に出る機会が多くなったことや、現場レベルの困りごと、例えば不具合の対応方法について相談を受けるなどの機会が増え、話す内容もより現場に近い内容になりました。
不具合の対応方法の相談の１つとして「開発部門に移った経緯」で、週次の不具合分析でインストーラーのチェックの自動化を提案した話を書きましたが、開発チームとの距離が近くなったことで、どのようにチェックすればよいかの打ち合わせの場に参加する機会がありました。
その打ち合わせで以前Qチームで思っていたことの提案を具体的に話すことができ、自動チェックを実装する取り組みが進むことになりました。
開発プロジェクトの中に入り、近い位置から声を上げることで、具体的なアクションに繋がることを実感しました。
室井さん、聞こえますか？
やはり事件は会議室ではなく現場で起きてるんだなと実感した次第です。
QAチームの頃でも開発チームやテストチームに寄り添い同じ視点で課題に取り組む意識でいました。
しかしQAチームとしてはフィードバックや改善の提案までで、実際の改善作業は開発チームやテストチームで行うものといった感じで線を引いていたことに気付き、同じ視点になるのは重要なことで、外の組織からはなかなか難しいことだと思いました。
少し戸惑っているコト
思ってたのと違うところは、QAチームからテストチームに異動なので品質をどうしていくかや、テストのやり方などをメインにやっていくんだろうなと思っていました。
間違ってはいないのですがテスト以外に開発部門と他部門との調整や、障害修正の対応計画、開発プロジェクトの管理方法の改善などいろいろ求められるところがあり、テストチームの作業に専念できる訳ではなかったといったところです。
開発プロセス含め改善することで品質向上に繋げるのは当たり前の話ですし、上流工程から品質の作り込みに貢献していきたいのは元々思い描いていたのです。
ですが、テストチームのテストリーダーが多くの細かいタスクを抱えていてうまくまとめられていなかったのでフォローしたり、そのほかにも障害修正の対応や、サポートの問い合わせもあり割り込みが多く、品質改善に専念できないと感じているところです。
障害修正の対応や、サポートの問い合わせは私だけではなく、開発部門内全体に言えることで、なかなかメインの作業に専念できないことが課題だなと感じています。
まだまだ始まったばかり
ここまでいろいろ書きましたが、開発部門に異動してまだ具体的に改善が行えていないので、これからといった感じです。
改善したいことがたくさんあります
これからやりたいことは、POと連携して要件定義段階から品質の作り込みや、開発チームに対しQAエンジニアとして培った品質に対する考え方やテスト観点の作り方などをレクチャーし品質向上に繋げること、テストチームのテストリーダーがテストプロセスを円滑に進められるように教育するなど、QAコーチとしての役割を担っていきたいと考えています。
また、プロジェクトの進捗状況など見える化が不十分なので、POが状況を把握しづらく、チーム間でのフォローもなかなかうまくいっていない状況なので、ここらへんも改善していかなければなりません。
課題は山積みです。
最終的には、開発チームのメンバーが出荷までを含め製品の品質を意識した開発が行えるようにプロセスを含め改善していき、テストチームのメンバーはテストに関するスペシャリストになり、テストマネージメントをしっかり行える体制を目指したいです。
認定スクラムマスターにもなりました
そんな中、Scrum Alliance認定Certified ScrumMaster®の取得も行いました。
私たちの開発プロジェクトはスクラムで行っている訳ではありませんが、ユーザーストーリーを意識した開発や、チーム一丸となってプロジェクトを進められるようにスクラムのプラクティスを取り入れられればと考えたためです。
一番初めに書きましたが、私は短期留学で開発部門に異動しています。
チームが成熟して、うまく回るようになればスクラムマスターはいらなくなると思っています。
なので、開発チーム、検証チームのメンバーが製品の品質を確保でき、プロジェクトを円滑に回るようになれば私は開発プロジェクトにいらなくなりQAチームに戻ると思っています。
まだまだこれからではありますが、これまで外からQAエンジニアとしてフィードバックしていたことを、現場レベルの声を拾い上げた上で、開発部門内部から具体的な品質改善活動に繋げていければと思っています。
成果が出たら、開発プロジェクトの中に入って品質改善に貢献できるってことを報告したいと思います。
