はじめに簡単な自己紹介をさせていただきます。
AIQVE ONE株式会社 技術支援部の熊野泰司と申します。
ゲーム、非ゲームを問わずテストの見積もりや設計業務及びマネジメントを担当しながら、新入社員研修やテスト技法などの技術者育成もしております。

はじめに

テスト工程においても開発工程と同様に、タスク管理やリソース配分などのスケジュール調整をプロジェクトの進行に合わせて適切に行うことが必要であり、その為にも初めのうちに出来る限り詳細なテストスケジュールを立てることが大切です。
仕様変更やテスト範囲の増加、トラブル発生などの際に詳細なテストスケジュールが作成されておらず、進捗状況などのタスク管理も適切にできていなければ、適切な対応や、プロジェクトリーダーや取引先への説明も難しくなります。

そこで、テスト計画の一つ「テストスケジュール」について私が行っているWBS方式でのスケジュール作成と活用例をいくつかまとめてみました。

※WBSとは、「Work Breakdown Structure」の略称で、作業工程を細かな作業（Work）に分解（Breakdown）し、構造化（Structure）することで管理する手法を指します。

【関連記事】テスト計画書とは？目的や要件をわかりやすく解説します

テストスケジュールを作成する5つのメリット

実際にテスト業務が始まると様々な角度からテストの進捗や予定を確認することが多くなります。デイリーでの進捗、メンバーの作業予定、ウィークリーでの進捗目標、機能Aのテスト開始または完了の予定日など、確認したい情報のカテゴリや大きさも様々です。
また、一言でテストと言っても準備からテストの設計・実行・修正確認などの様々な工程が存在するので、各種工程におけるスケジュールを作成し活用しましょう。
ここでは、テストスケジュールを作成するメリットを5つご紹介いたします。尚、ここでご紹介するメリットは、WBS方式で作成した場合を想定しています。

メリット1．スケジュール調整を効果的、効率的に行いやすくなる

「機能Aが開発遅延でテストも後ろ倒しになった」「追加で機能Cが実装されるのでそちらもテストしてほしい」など、機能追加や仕様変更などでスケジュールの調整をする必要が出る場合があります。その際に一つひとつの工程が細分化されていると、遅延で空いた日程へのタスクの割り振り、後ろ倒しになったタスクの再配置、追加されたタスクの差し込みなどの調整を行いやすくなります。
また、「○日を超える場合の遅延はスケジュールに収まらなくなる」「〇日～〇日はこれ以上タスクを並行できないので受け入れられない」など、リスクや要求の対応可能・不可能などが判断しやすくなります。

メリット2．メンバーに対するリソースの管理がしやすくなる

メンバー毎のタスク配置や稼働率が見やすくなり、タスクの偏りや漏れ、非効率なタスク振りなどから生まれるリスク・トラブルの予防に役立ちます。タスクが全て完了したメンバーを他メンバーのヘルプにあてる先を確認したり、欠勤が出た際に影響のあるタスクを把握しやすくなります。また、他のタスクから人員を一時的に移動して対応するべきか？どのタスクから移動するか？など、タスク配置の再検討にも役立ちます。

メリット3．作業の円滑化と遅延の防止

事前にメンバー毎の全作業予定をチーム全体へ共有することができるので、管理者はメンバーが作業を終えるごとに次の作業指示を出す手間が減り、メンバーは次の作業を事前に把握できるのでスムーズに次の作業へ移れるようになります。
また、管理者が長時間の打合せや欠勤などで不在となっても、テストスケジュールを確認することでメンバーが自分自身での進捗の遅れに気づけ、他メンバーの作業状況を確認してヘルプをお願いすることができます。着手していたタスクが完了、またはトラブルで停止した場合も、次に何をすればよいのか判断がつきやすいので、現場の混乱を防ぎ作業に遅延が発生しにくくなります。

メリット4．メンバーのモチベーションへの影響

単純にチームの状況が見えやすくなることで、メンタル面でもチームに良い影響を与えることが多いです。
実際にスケジュールというものが活用されていなかった（もしくは共有されていなかった？）とき、現場では以下のような声がありました。

・自分のタスクの量がわからない、今の作業ペースで大丈夫なのかわからないので危機感を持ちづらい（今自分は遅れてる？進んでる？）
・作業予定がわからないので次のタスクを考慮した作業ができない（適当にタスクを振られている気がする）
・他の人が何をやっているのか知らない、わからない（チームで作業している感覚をあまり感じない）
・特に何かあったわけでもないのに最後の週になって急に進捗が遅れてると言い出して残業を行いだした（もう少し前から把握できなかったの？先週から残業していれば負担が減ったのに…）

周りの状況が見えづらいことや、自分にどれだけタスクがあるのか見通しが悪いままタスクを振られ続けることが、メンバーのモチベーションに良くない影響を与えてしまうことは少なくないようです。

メリット5．遅延の早期発見

遅延をなるべく早い段階で気づくためにも役立ちます。
たとえば、機能Aと機能Bのテストするというタスクに対して、機能AとBそれぞれではなくテスト全体でスケジュールを立て、「AとBに対してテスト日数20日あるから「デイリー進捗目標は5％」という認識で作業を進めたとします。その結果、機能Aは進捗目標値でもある進捗率5％で進んでいたが、機能Bでは進捗率が3.5％ほどに落ち込んでしまいました。その際のレポートとしては「機能Aは順調だったが、機能Bで遅延が発生した」といった内容になりました。
ですが実のところ、機能ごとに進捗スケジュールと進捗目標を出すと、機能Aはシンプルなので5日間のテスト予定でデイリー目標10％、機能Bは複雑なので15日間のデイリー目標約3.4％の進捗であったことがわかりました。
機能Aはデイリーで10%進んでいなければならない工程であるにも関わらず、全体から見たときにデイリー目標の5％に届いているので「順調」と判断してしまったのです。つまり、前半作業の時点で既に遅延していたことに気づけなかったというケースです。
機能ごとに詳細なテストスケジュールを作成しておけば、こういった遅延に早めに気づくことができます。

テストスケジュールの作成手順

次に、テストスケジュールに作成手順について解説します。作成手順は大きく以下の3つに分けました。

①工数の見積もり
②優先度の設定
③スケジュールを設定
※「①：工数の見積もり」についての詳しい内容は長くなってしまうので、別記事にて解説します。

②優先度の設定

見積もり工数、テストアプローチとテストアイテムの仕様書などの情報を元に各タスクに優先度を設定します。
優先度を決めることにより、プロジェクトの進行に伴って今行うべき作業が明確になり、差し込みでタスクが追加された際や、前工程が遅延した時などのスケジュールの調整が必要になった際の管理を効果的・効率的に行うことができます。
その優先度を設定するために私は以下のことを行っています。

タスクの関連性を分析する

一言でタスクといっても様々なものがありますので、まずはタスク同士の関連性を分析します。たとえば、以下のようなものがあります。

・「タスクを進めるために完了している必要があるタスク」
たとえば、テストケースを実行するタスクに着手する為にはまず、テストケース作成のタスクが完了していなければなりません。

・「他タスクを行うことで必要な情報を得られるタスク」
たとえば、機能Bの一部には機能Aの処理結果に比例した処理が行われる仕様がある為、機能Bをテストするには機能Aを理解しておく必要がある場合や、機能Aの○○仕様は機能Cと同じ仕様なのでそちらを参照する、などです。

・「完了することで他タスクの進捗に影響を与えるタスク」
たとえば、機能Bには、機能Aとの共通処理が多く含まれており、機能Aをテストすることで機能Bの一部をテスト完了扱いにできるなどです。

タスクに関連する要素の状態を確認する

テスト対象機能や仕様書などのタスクに関係する要素とその状態を洗い出して数値化し、優先度を設定する方法をご紹介します。
たとえば、機能Aが中枢を担うものであれば当然優先度は高くなりますが、実装予定がスケジュール後半だった場合は前半へは割り振れないので他のタスクを入れるしかありません。逆に中枢を担うような機能ではないがバグの潜在リスクが高い見込みがある場合などは早期にテストを行った方が得策だと考えられます。
中枢を担う機能に後日仕様変更があると既に分かっている場合は、重要だからと優先度を高くして早期にテストを行ってしまうと仕様変更後にやり直すことになり、無駄になってしまいます。
テストケース数が膨大などテストに多く日数（工数）を要する場合は、遅延のリスクが高いので機能の実装完了後、即テストを開始したいところです。タスクを優先するべきかどうかを判別する要素は意外とたくさんあります。テスト対象ごとに「共通する要素」をいくつかピックアップしてその状態を確認します。

その際に、ピックアップする要素は行う作業に合わせなければ効果的ではなくなってしまうため、注意が必要です。
たとえば、テスト設計作業に対して行う場合に確認する要素は以下のようになります。

・仕様書の完成度は？　⇒低いと情報が不足がちで優先しても設計作業ができない
・仕様変更の予定はある？　⇒変更が入る前に作業をしてしまうと手戻りが発生
・仕様のFIX(仕様書の完成)予定は？　⇒先であるほど変更の可能性が高い傾向にあるため早期の設計はリスク有り
・仕様は複雑？　⇒複雑である程、作業が難航しやすいので遅延リスクを考えると早期に着手したい
・共通処理は含まれている？　⇒テストケースの流用が見込め他の機能に展開したいので早期に着手したい
・テスト実行(または機能実装)予定はいつ頃？　⇒日が近い場合、テスト実行時にケースが無いといったリスクを避けたい

などなど様々な要素(出来事)が想定されます。
また、これらの情報の中には、開発スケジュールや仕様書などの資料のみでは確認や想定できないものも多いため、開発チームとのコミュニケーションを積極的に行い、プロジェクト状況と作業に合わせた情報を選択して集める必要があります。

関連性と要素の状態を数値化する

上記で分析したタスクの関連性と要素の状態に合わせた数値に置き換えます。たとえば、仕様書の完成度に対して、完成度が低ければ「1」高ければ「5」とするといったイメージです。そのように、それぞれに法則を決めて数値化して行き優先度を設定しやすくします。

この例でいくと、合計値が低いほど優先度が高くなるイメージです。テスト計画で機能実装順にテストすると決定されている「開発チームの要望で○○関連からテストしてほしい」など重要視する要素が顕著な場合は別枠で優先度を設定したり、要素自体にも優先度を設定して数値に倍率をかけるなどでより正確に細かな優先度をつけたりもしています。

③スケジュールを設定

ここまでくればあとは、工数と優先度を元にテスト設計、テスト実行、α版β版などのフェーズごとのスケジュールに割り振っていく作業になります。当社では、WBS方式の他にガントチャート方法でもスケジュールを作成しています。

・WBS方式

こちらは、主にテストチーム向けに作成しており、メンバー個人毎にタスクの概要、期間(工数)、優先度(順序)などタスクの情報を明確に記載します

・ガントチャート方式

こちらはテストメンバーだけでなく開発チームなどのプロジェクト関係者各位へのぱっと見でのわかりやすさを意識して作成しています。
また、詳細なスケジュールを作成する工数がどうしても確保できない場合や、高い頻度でスケジュール調整を行うプロジェクトなどのWBS方式が有用的でないと思われる場合には粒度を調整してこちらのみを作成し運用しています。

※ガントチャートとは、 縦軸にタスク項目を配置し、横軸に時間軸を配置して横棒グラフで表すことで、直感的に全体像を掴めることが特徴です。

大事な点として、どちらにも共通しているのは「何をいつ作業を始めていつまでに完了させなければいけないか」を「見る側」がすぐに分かるように作成することです。これがわかりにくい作りであると誤った認識をしやすくなり効果的でなくなってしまいます。
最悪の場合、開発チームだけでなくテストチームのメンバーにもあまり見てもらえなくなってしまいます。

テストスケジュール作成時の注意点

テストスケジュールを作成する際の注意点としては、「バッファを使う前提でスケジュール設定やタスクの割り振りをしないこと」です。
バッファの方針にもよりますが、基本的には大きな仕様の追加や変更、差し込み作業やトラブルなど見積もり外の工数の発生やリストをある程度想定して計算し用意されている工数です。
何のトラブルもなく、仕様変更や追加のない見積もり上の作業のみをしているはずなのに、バッファ分の工数を使用している(見込まれる)時点で人員が不足している、スケジュールを超過していると認識をして、テスト計画の見直しを検討、提案しましょう！

例：見積もり8人日＋バッファ2日＝計10日の見積もりに対して、「完了予定は9日目くらいなら問題ないな。」といった判断。

スケジュール設定はバッファを使う前提であり問題なしとは言い難い状況です。バッファ工数は気軽に使用してよい工数ではないと注意をしましょう。
（バッファと言っているにも拘わらずに使う前提の見積もり・スケジュールになっているようでは、それはバッファ工数ではなく普通に必要工数です！）

テストスケジュールの管理方法と注意点

次に、作成したテストスケジュールの管理方法と注意点について解説します。

タスクの進捗は細かく取る

どの機能までテスト完了しているのか？今の進捗は全体でどのくらいなのか？といった進捗状況を記録しているケースは多いと思いますが、「昨日はどうだったか？」「○月○日の機能Bは？」といったことが把握できる進捗の取り方は疎かにされがちな印象です。進捗を取るという作業に使う工数がない、といった場合が多いかと思いますが、確かに管理者だけでなく、進捗表に入力を行うメンバーにも負担はかかります。
ですがこれをおろそかにしてしまうと、タスク単体で見た時の作業の遅延に気づけなかったり、そのタスクに対して追加や変更があった際に発生する遅延や、必要な追加工数の目途も立ちにくくなります。タスク毎やメンバー毎に、進捗と工数をデイリーで細かくデータを取ることで今後のタスクの工数見積もりに使えたり、追加や遅延発生時のスケジュール調整の難易度や精度が大きく変わってくるので、その際に価値を発揮します。

差し込みタスクの工数は別枠で取る

差し込み作業は、たいていの場合急を要するものなので、今行っている作業を止めて着手＝遅延することになります。
たとえ、5～10分程の差し込みであっても回数が重なれば無視できない工数になって作業が遅延してしまいますし、機能Aのタスク中に差し込みが来たからと機能Aの工数として進捗を反映してしまうと、差し込み作業によるものなのか単にテスト内容の複雑さによるものなのか分からなくなってしまい、後で見返したときやリグレッションテストの見積もりの参照など工数を参考にしたいときに、意味が薄れてしまいます。
特にアジャイル型の開発スタイルでは差し込み作業は多い傾向にありますので、しっかりとタスクの遅延を把握できるように別で工数を記録するようにしましょう。

忙しくても情報を更新をする！

見積もりはあくまでも見積もり（予測）でしかありません。プロジェクトが進行するに伴って入手できる情報が増えたり明確になることで段々と鮮明になり、より具体的で正確な内容をテストスケジュールに落とし込むことができるようになっていきます。テスト進行中にも継続して情報収集は怠らずテストスケジュールを更新、調整を行うことが大切です。
特に、テスト進行途中に人員追加などがあった際にスケジュール表が更新がされていないと、誤った情報を取り入れてメンバー同士で作業が被ってしまったり、抜け漏れが発生したり、スケジュールの変更を説明する時間がスケジュール更新作業よりも多くかかってしまうなどのリスクもあります。

そのほかにも、スケジュール通りにいかなかった場合の最悪なケースは、トラブルもなく、仕様変更も進捗に影響がない程度だったにもかかわらず、予定より遅延してしまった、などの特に目立った理由がない場合です。
この場合に挙がる現場の声としては、「思っていたより難航した」「見積もりが甘かった」といった類が良く出ますが、それは、初期のテスト計画の想定（見積もり）スケジュール感のまま動いており、その時点のスケジュールから変わっていない⇒プロジェクトやテストの状況に合わせた調整を行えていないケースが殆どです。ただ作成するだけでなく、テストスケジュールが適切に運用できれば、追加の要素やトラブルが生まれた時点で遅延や超過に気づき、取り返しのつく段階で見直しの検討・提案が行える可能性が大きく上がります。

最後に

テストスケジュールの作成は手間も時間もかかり、精度を上げるには経験も必要になってきます。
テスト計画には他にもやるべきことがたくさんあってとても大変ですが、最初に苦労した分それ以上に後が楽になるので、損して得取れの精神で取り組んでみてください！