#はじめに
一般的に、ソフトウェアの開発では仕様書を作成します。
それは、エンジニアだけでなく、品質管理、サポートなど、関係者が共通の認識として
ソフトウェアを理解するために必要だったりするためだったり、他にも様々な理由があったりするからです。
携帯ゲームの開発の現場では、リリース直前までバランスを調整したり、
おもしろいゲームを提供したいという強い思いから、突如仕様の変更が入ったりすることもあります。
結果として、仕様書の作成がおろそかになったり情報の更新が遅れたりします。
(仕様書のバージョン管理とかしっかりやっている会社さんとかあるのだろうか)
では、こうした開発サイクルの中で、
・テスト時にどこに気を付けたら良いのか
・どういった仕様書があると良いのか
あくまでテスト側の視点にはなりますが、そんなことを考えてみることにします。
#ゲーム開発における仕様書の役割
ゲーム開発の現場では、いくつかの仕様書が存在します。
ここでは弊社で使っている主な仕様書(中でも特にテスト側が関係するもの)と、その役割を紹介します。
###機能仕様書
基本的な動作や条件が書かれた仕様書です。
弊社では、企画書と呼ばれたりするケースもあります。
書かれている内容は、どういうイベントかというコンセプトから始まり、
参考にしたイベントや過去からの流用に対しての変更点、新規要素などが記載されます。
各機能が定義されているので他の仕様書の大本になり、多くの関係者が参照します。
###遷移仕様書
ゲームでは画面の遷移が多いので、仕様書としてまとめることがあります。
文字だけだと理解が難しい箇所や、複雑な遷移条件などがあるときに情報を整理するために使われます。
あまりゲーム自体の習熟度が高くなくてもある程度動作を想定できるため、
思わぬところ(新人への説明とか)で役に立つことがあります。
###設定仕様書
キャラのパラメータや、イベントの各種設定値をまとめた仕様書です。
Excel形式で作成されることが多く、過去とのバランスを見たり、データを俯瞰したいときに使います。
ギリギリまで調整が入りやすいので、Fix遅延が起きやすいです。
#テストにおける仕様書のチェックポイント
テストでは、主にテストケースの作成時と、テスト実行中の仕様確認で仕様書を使います。
それぞれどういった点を注視しているか、仕様書を見るときのチェックポイントをまとめてみます。
新規開発時と、すでにリリースされて運用している時で仕様書の内容が変わってきますが、
ここではひとまず運用時の仕様書について記載したいと思います。
##テストケース作成時
###仕様不明点には不具合が潜みやすい
テスト設計をしていると、仕様の記載内容が読み取れず、仕様作成者に質問が発生したりします。
シンプルなものだと、対象の画像がないとか、文言が過去のものだけど大丈夫か、とかですが、
中には動作するための条件の記載がないといったテスト設計者の気づきが必要な質問もあります。
(そしてそういう箇所は、考慮自体が漏れていることが多く、不具合のリスクも高い)
こういう条件考慮の漏れや記載の過不足が頻発する場合、仕様書のフォーマット自体に見直しをお願いしたりします。
(不明点が多いとQAからの質問も増えてしまうので、お互いに大変になったりもしますよね。)
ただ、仕様書はあくまで開発資料なので、見直しをお願いする際には留意が必要です。
###テストを網羅的につくるためには仕様書の記載内容が重要
テストケースは基本的に仕様書をベースに作成します。
仕様書に記載のない機能については、そもそも作成対象になりません。
機能自体の記載に漏れがないよう仕様書自体の網羅性にも注意したいところです。
運用フェーズでは、変更や新規要素があるか、削除される仕様はあるか、という点に特に注意が必要です。
仕様書上で、変更点や新規要素、削除要素がまとめられていない場合、
情報連携で認識の齟齬が生まれやすくなる(口頭でやり取りした結果の反映忘れとか)ので、
必要に応じて仕様書のフォーマットに入れ込んでもらうのが良いと思います。
##テスト実行時
###仕様書と比較するから古い情報はツライ
テストを実行していると、設定値やキャラのデザインを仕様書で確認することもあります。
そうしたときに、仕様書が更新されていないと、何をもってOKとするかの判断がつかなくなります。
また、古い仕様の記載を信じて、誤ってOKとしてしまうケースも考えられます。
仕様書がちゃんと更新される運用になっているかはテスト前に確認しておくことをおススメします。
###毎回記載方法が変わると読みづらくてツライ
「できるだけ慣れたテスト実行者をアサインしたい。」
ゲーム開発のテストに関わる人であれば、だれもが一度は考えることだと思います。
慣れているテスト実行者は、過去の仕様書も参照したことがあるので、
見慣れた仕様書とフォーマットが違ったり、参照したい情報の記載場所がころころ変わったりすると混乱してしまいます。
(探しにいくために時間もかかってしまうし、見落とした場合には仕様質問などにもつながる)
良く使うドキュメントだからこそ、読みやすさは重要です。
#★ではどういった仕様書が良いのか
テスト設計、テスト実行時のチェックポイントから、
どういった仕様書だと開発とQAの双方にとって良いかを3点考えてみました。
##1.動作条件や用語定義などは、フォーマットに仕込む
動作条件については、そもそも記入する枠を用意してしまえば、
書かざるをえない(空欄はNGというルールもつける)ので、フォーマットに入れ込むのが良いです。
必殺技などの発動条件や、効果の対象、発生する効果の内容など、
キャラクターの設定箇所は条件が複雑化しやすいので、うまく整理していきたい箇所です。
また、用語定義は、仕様書の参考情報として別途まとめておくと良いと思います。
##2.目次を入れる
大枠で漏れがないかは、目次くらいのレベルで最低限おさえるようにしたいです。
この時点で抜け漏れがあると、プロジェクトの事故率は大きく上がってしまうでしょう。
##3.設定値更新箇所もフォーマットに仕込む
運用フェーズの携帯ゲームで、一番変更が入りやすいのは設定値の更新だと思います。
クエストの設定、報酬の設定など設定値に関するテーブルはあらかじめフォーマットに仕込んでおき、
どこに配置されているのかが固定することで探しやすくなります。
(スプレッドシートや、Excelなど、仕様書とは別ファイルでも良さそうです。)
#さいごに
なんだか書いているうちに、文章量が見込みより多くなってしまいましたが、
個人的には、どんな形であれやっぱり仕様書はほしいです。
上述したように仕様書がないと、何をOKとしてテストすれば良いかわからないですし、
条件の考慮が漏れていたらお客さまのもとに不具合が流出してしまうかもしれません。
ただ、開発スケジュールにあわせて、作成を効率化することもあわせて必要だと思います。
枠組みや、更新方法を工夫することで作成コストもおさえられるので、
仕様書にどういう情報が必要なのか、どういう運用にするのかを整理しつつ、
開発、QA双方にとってより良い仕様書にしていきたいです。