こんにちは。品質管理部のtarappoです。

早いもので2023年度も1Q（4月〜6月）が終わって上半期も後半戦です。品質管理部は、次の記事に書いたとおり4月から組織体制を変えました。

上記の記事の執筆時点からさらに体制は変化しています。ざっくりと執筆時点での体制を図にすると次のような感じです。

以前はチームへのアサインが固定化されてないメンバーもいましたが、今は各開発チームへのアサインは固定化されています。上記のブログ記事や登壇含め、体制変化については伝えているものの、この体制になって各チームでどういったことを行なっているかについては話していません。

そこで、本記事ではこのチーム体制になってから各開発チームでの品管メンバーの動きについてフォーカスして話したいと思います。

その中で、まずは私が所属する「お会計チーム」についてフォーカスして話したいと思います。

開発チームごとの動きとは？
「お会計チーム」ではなにをおこなっているのか？
リリースをするまでの流れ
FY23 1Q（4月〜6月）の結果
- 関わった案件数の推移
- 課題
おわりに

開発チームごとの動きとは？

最初に、なぜ特定のチームにフォーカスして話すのかという点について説明したいと思います。

各開発チームはそれぞれ特徴があります。

扱う範囲が広めのチームもあれば、特定領域に特化したチームもあります。その中で、品管メンバーとしておこなっている内容についても違いがあります。

チーム体制になる前は品質管理部全体で動いていたので、次のような全体として1つのテストプロセスを決めていました*1。

このプロセスがチーム体制になったことでどう変わったかというと。

基本的にこのプロセスは踏襲しますが、チームの特徴に応じてチーム単位で変化を加えたり、プロセス内の特定のアクションをより深化させたりと、各チームのメンバーに判断してもらっています。

こうした背景があり、特定のチームにフォーカスして話すのがよいというのがあります。

「お会計チーム」ではなにをおこなっているのか？

私が所属するチームは「お会計チーム」です。チーム名の名前のとおり、お会計にまつわることを扱っています。

さらに本チームの特徴として、次のようなものがあります。

クライアントサイドよりサーバサイドを扱う機会が多い
外部サービスを扱っている機能が他チームより多い

このお会計チームのメンバー（SWE、PdM、私）でチームができたときにキックオフをおこないました。

そのときにおこなったインセプションデッキで、「品質」という観点におけるトレードオフスライダーをおこなっています。上図のようにこのチームでは扱う機能の関係上「品質」を重視するという話をチームのみんなでしています。

そのため「お会計チーム」では品質をより守っていくためのリリースプロセスとしています。実際にリリースするまでの流れについて次に説明していきます。

リリースをするまでの流れ

リリースをするまでの流れをざっくりと図にすると次のようになっています。

簡略化のために、あえてこの図では除外していますが実装前には仕様策定のステップもあります。図をもとにステップ、やること、担当者を表にすると次のとおりです。

ステップ	やること	担当者
（1）	仕様に基づき実装	SWE
（2）	内容の理解	品管メンバー
（3）	どう守るかを考える	品管メンバー
（4）	内容に対するフィードバック	品管メンバー
（5）	フィードバック対応	SWE
（6）	テスト実施	品管メンバー、SWE

基本的には（1）から順にすすみますが、（3）と（4）は同時に進めつつ（5）の結果をもとにさらに（3）をアップデートしたりします。必ずしも前に進んで戻らないというわけではなく、戻ったりしながら前に進んでいきます。

上記については実装からのステップの話になっていますが、品管メンバーもSpring Planningに参加しているので、本Sprintで何を実装予定なのか、そして今後の予定については把握しています。

なので、実装前の段階から品管メンバーも動けるとさらに良いのですが、現時点ではまだその状況にまでは達していません。仕様を決める段階から関わることもありますが、それをおこなっているのは全体の一部となります。

上述した流れについて主にどのようなことをおこなっているかについて次に説明していきます。

（1）実装と（5）フィードバック対応

お会計チームでは実装時にプロダクトコードに対する「テストコード」とプロダクトコードへの「コードドキュメント」は基本的に必須となっています*2。これが必須となっているのは「品質」に関係する対象機能に対する「認知コスト」をいかに下げていくかという点で重要なことでもあります。

コードドキュメントの対象読者は主にSWEならびに品管メンバーになります。

対象の機能に対して理解をする速度を上げるためにも「コードドキュメント」は重要です。プロダクトコードにdartdocで記載されたコードドキュメントはWebから見ることができるようになっています。また、文字だけでなく図（Mermaid記法）も貼ることでよりわかりやすくなっています。

テストコードにおいては、そもそもの課題として次がありました。

テストがなにをしているかが分かりづらい
テストとしてなにを守りたいかが分かりづらい
テストとして守るべき箇所が守れていない

テストコードを書くという文化はあり、コードカバレッジは高かったものの上記の課題がありました。そこでお会計チームでは、今ある自動テストをがんばって活かすというよりも新たに作り直すぐらいの気概で進めていくことにしています。

そして、後述する私からのフィードバックに対して、内容をチェックした上で対応をしてもらっています。

（2）内容の理解

（1）の成果物を元に内容を確認した上で、対象に対する理解を深めます。これによって次を理解していきます。

どのような機能なのか
なにができている必要があるのか

上記をおこなう上で見るべき成果物としては次のとおりです。必須で見ているのは1、2、3で、4は必要に応じて見るものが変わっていきます。

プロダクトコード*3
テストコード
コードドキュメント
関連ドキュメント（仕様書やDesignDocなどいろいろ）

理解を進めていく上で、上記の成果物を読んでいく中で分からないことがあれば適宜質問をしていきます。

理解をするのは今回の機能に関するものを読めば分かるとは限りません。変更点だけを見ても関連するものが分かれなければ、対象機能に対しての理解があまりできないこともあります。そのため、関連する機能に対しても同様な成果物を確認することはよくあります。

しかし、初期の頃は認知コストの高さや自身のナレッジの薄さから時間がかかりやすい傾向がありました。そのため、SWEに説明してもらったりシーケンス図などを用意してもらったりと、そういったこともおこないつつ理解を深めていきました。

理解が一定深まってきたら、「（3）どう守るか」を考えつつ「（4）内容のフィードバック」を併せておこないます。

（3）どう守るか考え（4）内容に対してフィードバックする

内容を理解した上で、「（3）どう守るか」を考えつつ「（4）内容に対してフィードバック」をおこないます。

常に新規機能ではなく、また新規に作ったものも既存の箇所で利用するといったケースもよくあります。したがって影響範囲もチェックした上で、どの箇所をテストするべきかを考えていきます。

影響範囲も加味した上でどう守るか、そのためにはどのようなテストをするかというのを考えていきます。

対応箇所：対象となる機能のどの箇所
守る手段：自動テスト*4、手動テスト、それ以外

守る手段においては自動テストの活用は重要です。その上で、自動テストだけでは守ることができない箇所に対して、手動テストがどの範囲で必要かどうかを判断していきます。

自動テストで守っていく範囲においては、現時点のテストコードで足りているかをチェックしフィードバックをしていきます。

レビュー観点

テストコードに対するレビュー観点の例としては次のようなものがあります。

テストコードが足りているか

対象のインターフェースのみを見た場合だとどうしても近視眼的になることがあります。状態が重要となるケースにおいては、状態遷移テストも必要になるため、その点も加味します。また、テストコードの見やすさと足りているかという観点からパラメタライズテストも積極的に活用しています。

テストコードを書きすぎていないか

お会計チームの場合、守りを強くしたいというのはありますが「なんでもかんでも」テストコードを用意するのが良いわけでもありません。自動テストもメンテナンス対象なので、必要でないと感じるものがあれば作らないでもいいようには考えています。とはいえ、現時点では守りを強固にしていることもあり一定多めになっているのも事実です。

テストコード内で確認しているものが妥当か

なにをチェックしているかどうかは重要で、確認すべきものを見ていないケースも過去にはありました。逆に見なくてもいいものを見ているケースもあります。

テストケース名は分かりやすいか

なにがテストで担保されているか分かるためにもテストケース名は重要です。単に「success」や「期待した結果になること」といった言葉があると、何をしたかったのかが分かりづらいです。

規約を作ったほうが良いよねということでSWE側で規約周りについていろいろと進めてくれています。その話について次のブログ記事を書いてくれています。

（6）テスト実施

（3）でどう守るかを考えた内容を元にテストを実施していきます。

テスト実施が「自動テスト」のみで完結するケースもあります。「手動テスト」が必要な場合は、内容を元に品管メンバーがおこなう場合もあればSWEがおこなう場合もあります。

テスト実施中に不具合が見つかれば対応をしていきますが、必要に応じてテストコードも追加していきます。問題がなければ最終的にはリリースを実施します。

品管としてはリリースがされたこともチェックしています。コードがmergeされてリリースされたのを見た上で、いつ時点までのコードを確認したかをメモしています。これにより前回との差分をよりわかりやすくできるようにしています。

FY23 1Q（4月〜6月）の結果

上述したようなリリースプロセスで、FY23 1Q（4月〜6月）の3か月間における結果として次について説明をします。

関わった案件数の推移
（現時点でのチームの）課題

関わった案件数の推移

この3か月間における関わった案件数の推移は次のとおりです。

4月：8件
5月：10件
6月：19件

徐々にテスト資産*5も溜まってきており、1件あたりにかかるスピードは上がってきています。

一方、開発メンバーもリファクタリングや改善を進めた結果として開発速度は以前よりも早くなっており、まだまだ品管メンバー側の対応が少し遅れている状態といえます。

この状態を脱するためにも、ほぼ私1人のみだった品管側の体制を変化させてメンバーを増やしています。他にも、今まで品管メンバーがおこなっていたことをいかに開発メンバーに委譲するかなどの検討も進めています。

定量的な数字は別の場所で話せればと思いますが、案件数の増加に伴ってテスト実施時に見つかる不具合が増えていたりユーザ影響がある障害が起きているわけではありません。

課題

すべてにおいて順調というわけではなく課題もいろいろとあります。現時点における課題としては次のようなものがあります。

扱う領域の中でまだテスト設計ができていない領域がある
- 把握できてないためにそこへの影響範囲が読みづらく広く守ろうとしてしまう
- 特にクライアントサイドに対しては弱い
現時点で私が案件全体に関わっておりほかメンバーへの分散化ができていない
- SETスキルを必要とする関係のためバス係数1の状態になっており、私がボトルネックとなるケースがある
- 今より早い段階から関わるということがあまりできていない

上記はあくまでも、現時点での「お会計チーム」での課題といえます。

他の開発チームも含めて考えると、今回のお会計チームのようにSETスキルを活用したほうがより効果をうむ開発チームもあります。しかし、現時点では品質管理部としてはまだそこにアプローチできていない現実があります。それは上述したような特定の開発チームの課題というよりも品質管理部としての課題の1つとなっています。