はじめに
私は2015年からテストエンジニアとして活動を始めました。最初の6年はシステムテスト・アドホックテストを中心としたテスト実行業務を従事し、その後の2年はテスト実行チームのチームマネジメントを行っていました。
2023年10月に株式会社ビットキーに入社し、テスト分析・テスト設計・テスト実装のテスト活動を担当し、現在はテスト自動化作業に取り組んでいます。
自己紹介としては以上となりますが、上記で触れたチームマネジメントについて、もう少し深掘りしたいと思います。
一般的にチームマネジメントといわれる業務は様々ですが、私が担当していた業務は「チームのテスト進捗管理」「チームの運営」「チームメンバーの教育」です。
個々の業務の説明については割愛させていただきますが、その中でも特に印象に残った業務が「チームのテスト進捗管理」です。
なぜ印象に残っているのかというと、単純に難しいからです。
そこで今回は私が行った進捗管理のやり方についてお話しできればと思います。
対象読者
- これからテスト管理や進捗管理を行う方
- 進捗管理の経験はあるが、進捗管理が上手くいかず改めて見直すきっかけが欲しい方
進捗管理とは何かといった部分から説明をしていきますので、進捗管理の基本的な概念が理解できます。
また、私が実際に行ってきた進捗管理のテクニックもご紹介いたしますので、進捗管理の経験がある方にとっても、改めて進捗管理について考えてみることで新しい発見があるかもしれません。
進捗管理とは
そもそも進捗管理とはというところから触れていきたいと思います。
進捗管理とは、作業計画と実績に「ズレ」が生じていないかを確認することです。
そして、「ズレ」が生じた場合、期限までに作業を完了させるよう軌道修正をすることです。
例えば、「明日友人と食事へ行くため、〇〇駅に朝10時集合」という場面があるとします。
これに対して、みなさんはどう予定を立てますか？
ここでいう予定は、進捗管理でいう「計画」にあたります。
明日は朝何時に起きて、何時に朝ごはんを食べて、何時に身支度して、何時に家を出て、何時の電車に乗って、何時に集合駅に着いて、など。
おそらくこういった計画を無意識にみなさんは立てられると思います。
計画通りに物事が進めばそれに越したことはありませんが、しかしどうでしょう、この計画がうまくいかないときありますよね。
朝30分寝坊して起きる時間が遅くなったとか、身支度に時間がかかり家を出る時間が遅くなってしまったとか、もしくは電車が遅延して集合時間に間に合わないとか。
もし30分寝坊をしてしまったら、本来起きる時刻よりも30分遅れることになり、さらに全体の計画よりも30分遅れることになります。
つまりあらかじめ立てた計画に反して遅れが生じることになります。
進捗管理でいうと、「30分寝坊して起きた時刻」が「実績」であり、「計画に対しての30分の遅れ」が「ズレ」となります。
上記の図はこれまでの説明を図式化したものです。
図の上部には計画、下部には実績を表し、右に進むにつれて時間が経過していくものです。
図から分かる通り、計画に対し実績では起床時間が30分遅れているため、そこでズレが発生しております。
進捗管理はこのズレが起きていないかを確認し、もしズレがあれば修正をする作業のことです。
これまでの例でいうと、寝坊により30分の「ズレ」があれば、朝ごはんを軽くするもしくは抜くとか、駅まで走るとか(交通ルールは必ず守りましょう)、電車よりタクシーの方が早ければタクシーを利用するとか。
方法は色々あると思いますが、これらの行動は30分寝坊による遅れを取り戻そうとする行動になります。
つまり期限(集合時刻)までに集合駅に到着できるよう30分遅れの「ズレ」を軌道修正する作業になり、この作業も進捗管理にあたります。
上記は日常的な例となりますが、他にも配送業者が「指定日時に荷物を届ける」といった場合や、ゲーム開発者が「発売日までにゲームを作る」といった場合でも進捗管理が行われています。
「指定日時」や「発売日」といった期限・期日がある限りは、それに向けて事前に作業計画を立て、実際の作業から進み具合に「ズレ」がないかを確認し、「ズレ」があれば修正をしなければいけません。
もし「ズレ」を修正しない、つまり進捗管理をしなかった場合、「指定日時に荷物を届けることができない」や「発売日までにゲームが完成しない」といったことが起きてしまいます。
進捗管理は小さな個人タスクでも大きなプロジェクトでも行われているのです。
なぜQAで進捗管理が必要なのか
上記で述べたように、期限・期日がある限りは、QAでも進捗管理は必要です。
開発者がリリースまでに商品を作ることに対して、QAはリリースまでに作られた商品の品質が保たれているかを確認しなければいけません。
品質が保たれているかを確認するため、事前に必要なテストを計画し、期限までに計画したテストが完了するよう進捗管理をしなければいけません。
もし進捗管理を怠ると、テストが未完了のままリリースを迎えることになりかね、そこから市場で大きな不具合が検出された場合は、企業の信頼低下に繋がる可能性もあり、最悪損害賠償などの大問題に発展することもありえます。
そのような事態を防ぐためにも、QAとして進捗管理は非常に大切な作業になります。
進捗管理のやり方
ここからは私が実際に行ったQAでの進捗管理のやり方についてご説明します
進捗管理は大きく分けて、QA開始前とQA開始後の2つに分けられます。
それぞれについてご紹介いたします。
〜QA開始前〜
いわゆる準備期間になります。
この期間で進捗管理でいう作業計画を作成します。
やることとしては、まずチームの作業工数を算出することです。
作業工数とは、テストを実施できる時間のことです。
例えば、チームの作業工数が30hの場合、受け入れられるテストの見積もり工数は30hまでです。
もしこのときチームの作業工数を算出せず知らずに見積もり工数が30h以上のテストを引き受けた場合、最初からテスト完了期限までに間に合っていないことになりますよね。
それを防ぐためにまずはチームの作業工数を算出してチームとして受け入れられるテストの量を把握する必要があります。
チームの作業工数の算出方法についてご説明します。
まず、テスト開始日からテスト完了期限日まで何日あるかを確認します。
次に、1日に何人テスト実施に着手できるかを確認します。
そして、1日で1人何時間分テスト実施に着手できるかを確認します。
あとはそれぞれを掛け合わせるだけです。
例：テスト開始日からテスト完了期限日まで30日あって、1日に5人テスト実施ができて1日に1人8時間テスト実施に着手できる場合
30(日) × 5(人) ×8(h) = 1200h
となり、チームの作業工数は1200hとなる。
簡単でしょう。
と言いたいところですが、実際はこんな簡単には算出できずもう少し複雑になってきます。
つまりどういうことか、上記の例では30日間5名全員で1日8時間テストする計算になっていますが、実際はそんなにうまくいくでしょうか。
テスト実施メンバーのうち、 Aさんは5日間不在のためテスト実施ができないとか、Bさんは10日間別の業務のためテスト実施ができないとか、そういう状況もあるでしょう。
その場合はそのテスト実施ができない時間分を作業工数から引く必要があります。
上記の例で言うとAさんは5日間テスト実施できないため5日 × 8hで40h、Bさんは10日間テスト実施ができないため10日 × 8hで80h、合計で120hチームとしてテスト実施ができない時間が出てきます。
そのため、チームの作業工数は
1200 - 120 = 1080h
となります。
最初の計算で得られたチームの作業工数が1200hに対し、120hも減って1080hになりました。
もし、テストが実施できない時間を考慮せずに作業工数を算出した場合、作業工数よりも120h分余分にテストを引き受けてしまい、結果としてテスト完了期限までに間に合わないという事態になってしまいます。
これを防ぐために、メンバーには事前にテストが実施できない日や時間を確認しましょう。
また、上記の例では、1日8時間テスト実施に着手できる計算をしていますが、果たしてそれは可能でしょうか？
仮に就業時間が8時間として、その時間を全てテスト実施に当てられるでしょうか？
もちろん組織によって異なりますが、これは不可能だと思います。
これはあくまで1日にテストを実施できる時間であって、検証や不具合起票の時間は含まれません。
テスト実施中に不具合を見つけたら検証をして起票することになりますが、それに掛けた時間分1日のテスト実施時間が少なくなる計算になってしまいます。
また、MTGやテスト以外の業務も日常的に行われることでしょう。
そういった時間を考慮して、1日でテスト実施に着手できる時間を計算しなければいけません。
では、実際にどうするか。
上記の例で1日でテスト実施に着手できる時間を8時間から5時間に変更したとします。
そうすれば、残りの3時間を不具合起票やMTGの時間にあてられることになり、もしテスト実施中に不具合起票をすることになっても、1日のテスト実施5時間分には影響しないことになります。
(不具合起票が多い場合や検証に時間がかかる場合は、そうとは限りませんが)
このように1日でテスト実施できる時間は現実的な時間にしなければいけません。
この時間を決める際は、不測の事態に備えてバッファー込みで計算をして多少余裕を持たせるとよいでしょう。
また、メンバーの状況を見て一人ひとりに時間を決めていってもいいでしょう。
例えば、新人メンバーであればまだ知識や経験が浅くテスト実施に時間をかける傾向があるため、この人は他のメンバーの半分の時間で計算するなどの配慮も必要でしょう。
ただし逆にベテランのメンバーだとしても、1日のテスト実施時間を多めに取ることはおすすめしません。
プレッシャーを与えることになるため、かえってパフォーマンスが低下する可能性があります。
上記の考慮して改めて作業工数を計算すると以下になります。
テスト開始日からテスト完了期限日まで30日あって、1日に5人テスト実施ができて1日に1人5時間テスト実施に着手できる
ただし、メンバーのうちAさんは5日間テスト実施ができない、Bさんは10日間テスト実施ができない
30(日) × 5(人) ×5(h) -75(h) = 675h
※-75(h)はAさんとBさんで計75h(15日 × 5h)テスト実施できない時間
これが今回のチームでの作業工数になります。
最初の1200hと比べて作業工数は約半分になり、結果として最初の半分ほどしかテストが実施できないことがわかりました。
この作業工数を見てテストを実施できる、できないを判断することになります。
もし、作業工数を誤って見積もると、抱えきれない量のテストを実施することとなり、結果としてテスト完了期限まで間に合わない恐れがあるため、作業工数は正確な時間を算出しなければいけません。
さて、作業工数を算出したあとはそれに見合ったテストを実施するよう計画を立てていきます。
どのテストをメンバーの誰にアサインするか、いつまでに完了させるか、などですね。
ここで私が行った進捗管理の手法を紹介します。
それは「バーンダウンチャート」というものです。
バーンダウンチャートとはテストの進捗具合を可視化した線グラフのことで、残りのテスト量とテスト実施完了までの時間をわかりやすく表したものです。
上記のグラフがバーンダウンチャートです。
バーンダウンチャートは縦軸にテスト量(h)、横軸に時間(日付)、残りのタスク量(h)を線グラフで表しています。
線は「実績線」「計画線」「理想線」の3つの線を用いられ、それぞれの線を比較することでテストの進行状況を把握することができます。
それぞれの線についてご説明します。
「実績線」はテスト完了までの残りのテスト量を表しています。すべてのテスト量から実施したテスト量を引くことで算出しています。
「計画線」はQA開始前に決めたテスト実施が計画通りに進んだ場合を表しています。
「理想線」は時間内でテスト量を均等にわけた場合の進み具合を表しています。
実績線と計画線が近いほど計画通りにテスト実施が進んでいるといえます。
実績線が計画線よりも右上に位置するほどテスト実施が遅れているといえ、逆に計画線が実績選よりも右上に位置していればテスト実施が計画より早く進んでいるといえます。
実施するテストが決まりましたら、QAが始まる前にバーンダウンチャートを作成しましょう。
これで、QA開始前の進捗管理は完了となります。
〜QA開始後〜
QA開始後の進捗管理は主に作業計画と実績とのズレを修正する作業になります。
計画通りにテスト実施が進めばズレを修正する必要はありませんが、残念ながら計画通りにテスト実施が進まないことが多いです。
デイリーで進捗を取ることになると思いますが、テスト実施で遅れが発覚した場合は、その時点で実施メンバーから現状をヒアリングして、まずは遅れの原因を特定しましょう。
遅れが起きてしまう原因は様々です。
テスト準備で予想以上に時間が掛かってしまった、不具合が多くてテスト実施がなかなか進まない、不具合によりテストがBlockされた、テスト実施に必要な機材が足りない、当日に実施メンバーで欠員が出た、障害によりツールが使用できなくなった、そもそも見積もりが甘かった、など。
どんなに些細なことでも遅れの原因になりうるため、メンバーから気になる点などきめ細かくヒアリングしましょう。
遅れの原因が特定できたら、それの解決策を練り実行へ移ります。
もし解決策を実行することで遅れが取り戻せたならば問題ありません。
逆に遅れが取り戻せない場合は、別の解決策を練るしかありません。
また遅れが発覚した時点ですぐにQAの上層部の方やプロジェクト責任者へ報告と相談をするようにしましょう。
チーム内だけでは難しい問題も解決の糸口が見つかるかもしれません。
また、実施メンバーには現状のテスト実施の進捗具合を共有するようにしましょう。
メンバーに現状の進捗具合を意識させることでチーム内での共有やフォローなどがよりスムーズになる可能性があります。
ただし、進捗が遅れているからといって決してメンバーには「もっと頑張れ」などの気持ちややる気を無理に奮い立たせるようなことはしないことです。
それは意味もなくプレッシャーを与えるだけです。
絶対にやってはいけないことは遅れを放置することです。
仮に数分や数時間の遅れだとしても、まだなんとかなるだろうと放置すると、その遅れがだんだんと蓄積されていき後々取り返しがつかない大きな問題に発展しかねないのです。
また、期日が迫ってくるほど解決に要する時間がなくなり、より解決が難しくなっていきます。
他にも「残業で挽回する」といった考えもやめましょう。
残業でテスト実施の遅れを解消することは、一時的な解決法であって、遅れの根本的な解決法にはなりません。
さて、ここまではテスト実施の遅れによる「ズレ」についてお話しましたが、「ズレ」にはもう1種類あります。
それは計画よりもテスト実施が早く進むことにより起こる「ズレ」です。
早く進むことで起きる「ズレ」について、予定よりもテスト実施が早く進んでいることで期日までに完了できるので
問題はないのですが、なぜ計画よりも早く実施できたのかは確認しておくとよいでしょう。
そこで得られた知見が今後のQAで活かせるものであればどんどん活用していけばよいのです。
QA完了後もチーム内で振り返りを行い、そのときにテスト実施が遅れた原因や早く実施できた原因を見返しましょう。
そして、そこで改めて適切な解決策を練るとよいでしょう。
終わりに
ここまで私が思う進捗管理について書いていきました。
QA期間中は不測の事態が発生しやすく、何かと進捗に影響が出ます。
もしそうなった場合は、進捗を取り戻すために臨機応変な対応が求められます。
進捗管理には正解がありません。
今後進捗管理をやられる方は、もし何か問題が起きても決して焦らず冷静さを持って1つ1つ問題を紐解いていきましょう。
最後までお読みいただきありがとうございました。
Discussion