お仕事はテストエンジニア!?

第4話『仕様書が雑じゃない！？』

仕様書とは、「こういうアプリを作ります」が記載された説明書みたいなものだ。

どこにどんな機能があるか、その機能でどういうことができるか、といったことが書かれている。

ゲームであれば、オプションにはセーブ機能とロード機能があって10か所まで保存可能、BGM設定とボイス設定があってBGMは10段階設定、ボイスは各キャラごとに10段階設定ができる。そういったことが記載された資料だ。

その他にも、画面のどこに何を表示するといった画面のことも詳細が書かれている。

例えば乙女ゲーで言えば、メッセージボックスは画面下部、メッセージボックスの右側には各種オプションアイコン、画面右上には日付表示などだ。

これがもっと細かくなって、仕様で決めた機能を実現するためにどういうプログラムにするかを書いた資料は「設計書」というものになる。

私は個人開発だったので仕様書は作ったことがなかった。

自分さえわかっていればよく、頭の中に何をどうするかは決まっていたからだ。

複雑な場合はノートにメモを書く程度だった。

これが、ゲームを誰かに譲渡する、誰かに開発を手伝ってもらうなど、他の人が関わってくると頭の中のイメージを詳細に伝えるためにも仕様書が必要になってくる。

つまり仕様書は『思い描いたものを正確に人に伝えるためのツール』なのである。

＊＊＊

さっき小毬さんが開いてくれたフォルダには

『【Fix】最終版_仕様書_完成版(3).pptx』

というファイル。

他には「新しいフォルダ」があった。

名前くらい変更したらどうなのよ……。

そんなことを思いながらそれを開くと、

『翻訳済みラベル - コピー - コピー.csv』

というファイルも入っていた。

設計書らしきものは特に見当たらなかった。

てっきり企業では仕様書を管理するシステムがあったりするかと思ってたけど。

パワポなんだ……。

パワポはパワーポイントというソフト。本来プレゼンテーションをするためのものだったりする。

＊＊＊

さっそくパワポを開いて目を通す。

どうやら『ペットの里親を探せる、里親マッチングサイト』を開発しているようだ。

パソコンでも、もちろんスマホでも見られるWebサイトだ。

そのためにレスポンシブデザイン――使うデバイスの画面サイズによって画面を最適化する――を採用している。

最初は広告収入がメインで、マッチング数が確保できそうな見込みが立ったら後にマネタイズを変えていくらしい。

ペットの里親募集をしたいユーザーは登録必須。

里親になりたいユーザーは登録をしなくても募集したユーザーとやり取りができるようだ。

……簡単に利用できるようにしてユーザー数を確保したいのだろうか。登録していないユーザーは操作履歴が追えないため後々問題が起きないか気になる仕様だ。けど大きい会社で出そうとしているんだからきっと想定済みだろう。

メインページには里親募集中のペット画像がリストでズラリと並ぶ。

そこに「いいね」やコメントをつけられるようだ。

……メインページにコメントをつけられるとデータロードで時間がかかるからキャッシュ――データを早く読み込むための仕組みなどの工夫が必要だし、何より燃えそうだけど……大きい会社で出そうとしているんだから以下略。

大雑把な流れとしては、里親になりたいユーザーが里親募集中のペットに里親の申し込みをして、里親募集をしたユーザーが承諾すればマッチングが成立するといった形になっている。

他にもチャット機能がついていて、里親募集しているユーザーと里親になりたいユーザーでチャットもできる。

運営にも――つまりこの会社にもチャットで問合せを送ることができる。

……ユーザーが増えると通信量で負荷が大きくなりそうだけど、大きい会社で以下略。

ついつい作る目線でツッコミを入れながら読んでしまうな、これ。

画面の仕様も記載されていて、いらすとやの画像を駆使してどこに何が表示されるか書かれていた。

ヘッダー――つまり画面の上のバーの部分にはタイトルやログイン、登録ボタン。

中央に里親募集のペットのリスト。

タブがあって「犬」や「猫」といった種類を切り替えることができる。

リストの途中途中に広告が挿入されるようだ。

＊＊＊

どういったものを作りたいかの大枠は把握した。

けど……。

リストに何件画像を出すか、名前やプロフィールやコメントはどれくらいの文字数まで許容かとかは書いてないの？

メインページのリストに画像を何枚出すかは、メインページのロード時間に直結する。

画像を一気に読み込むほどロードが遅くなるのだ。

リスト形式なら、1ページに例えば20件出して、画面下の１，２，３…といったボタンでページを切り替えるか、画面に映る分だけ画像を読み込ませるLazy Load――スクロールしながら画面に映る場所だけロードする形式――でロード時間を短縮する。

ロード時間ってユーザーから結構ブーブー言われるんだよね……。

文字数は、長すぎると画面反映の時に画面が崩れたりする。またデータベースへの書き込みのときには何文字まで入るかといった設定をしないといけない。

このへんって仕様書レベルで決めておくものじゃないの？

仕様書というものを初めて見たので疑問ばかりが浮かぶ。

続いて一緒に置いてあったcsvファイルを開いた。

csvは、表形式のデータを簡単に表現できるテキストファイル形式だ。

データとデータがカンマで区切られている。

そこには

『KEY_ADOPTION,里親募集,Adoption』

とか

『KEY_INFO,お知らせ,Information』

とか書かれている。

あーはいはい。

仕様書には書かれてないけど、2か国語対応しようとしているようだ。

…………。

いやいやいや！

普通は仕様書に書くでしょ……。

多言語対応の時は文を直接ページに埋め込むのではなく、キーを設定して、言語設定によって文の出し分けをすることが多い。

例えば「お知らせ」という文を表示したいところには「KEY_INFO」というキーを設定しておき、言語設定が日本語だったら「お知らせ」、英語だったら「Information」を表示させる仕組みだ。

私の乙女ゲームエンジンにも組み込んでいますとも。海外ファンもいるもので！

前にキーを間違えて、オプション画面に「セーブ」が二つ並ぶということはやらかしたことがある。

もちろん片方はラベルが「セーブ」なだけで、動作はロードというね。

これはテストプレイで気付いて修正したっけ。

＊＊＊

「ふぅ」

一息ついた。

大雑把なことは把握したつもりだ。

ただ細かなことは書かれていないためわからない。

それに……。

こうやって使う、ということは書かれているんだけど。

もしこういうことが起きたらこう処理をする、ということが一切書かれていない。

エラーが起きた時などの挙動だ。

入力した文字が長すぎたときはどんなエラー文を表示させるのか。

画像が読み込めなかったら何を表示するのか。

メッセージに送信失敗してしまった場合はどうユーザーに伝えるのか。

もし里親を取り下げてそのペットのページがなくなった時に、ブラウザのお気に入りからなどでそこにアクセスしたら何が表示されるのか。

こういったことは仕様書には書かれていなかった。

ひたすら「こうやって使う！」が書かれていて、ちょっと違う操作をしたときのことは考慮されていないように感じる。

開発をする時もこの辺が決められていないと、何を実装すればいいかとか、開発者が勝手に仕様を考えていいのか悩むのではないだろうか。

私が作っている乙女ゲーでは、シリーズごとに1000人ほどはユーザーがいる。

そうすると、1000通りの環境で1000通りのタイミングで1000通り使い方がある。

そうなるとおかしなことも発生するわけで。

せめて想定できることは塞いでおかないとお問合せがくる。

お問合せが山ほど……。

う、つらかった思い出が……！

まぁ、それらはかなりの数になるし仕様書に全部書けというのも土台無理な話に思える。

そうなると。

「――コード見るのが早いか」

となるわけで。

個人的にも業務でどういうコード――プログラムが書かれているか気になるし、テストコードを書くなら把握しておきたい。

＊＊＊

プログラムはGitHub(ギットハブ)というクラウド上のサービスで管理することが今では一般的だ。

複数人でプログラムを作る時、そこからプログラムを持ってきて、変更や追加の作業をして、その作業したプログラムをGitHubにプッシュ――ようはアップロードをする。そして一緒に開発している人がそのプログラムをレビューして、問題がなければみんなで作っている全体のプログラムにマージ――くっつける作業を行ったりする。

こうして大人数でプログラムを組み立てていくのだ。

私は個人開発だったけど、変更などの管理にとても便利なのでプライベート設定で使っている。

ちなみに大事な乙女ゲーのシナリオもそこに上がっていたりする。

変更管理に大変便利でして。

＊＊＊

「小毬さん」

呼びかけてみた。

「はいっ！」

シュバっ、と音が出そうな勢いで手を上げて

「どうしたの？」

と言いながらトテトテとこちらに来た。

う……チャットで伝えればよかったかも。

「GitHubを見たいのですが」

「ぎっと……かむ？」

キョトン。

その表現が的確だろう。

ハテナがいっぱい並んだ顔が私に向けられていた。

「えーと……んと……」

首を可愛く傾げた。

あ。

なんかデジャヴを感じるぞ、これ。

「ちょっと待ってて」

席に戻った。

あ、よかった。きっとプログラムがある場所のURLを送ってくれるはず。

――ガラガラ

小毬さんはおもむろに袖机をあけていた。

ガサゴソとあさって、何かを取り出した。

トテトテと私の元に戻ってきた。

手には何やら袋が……。

「キットカット？」

にはは、とはにかみながら大容量パックを私に見せてくれた。

「……」

「バナナ味です」

一個手渡された。

「……」

「おいしいよ？」

――びりっ、モグモグ

食べてみた。

美味しかった。

……じゃなくて。

「……あの」

「美味しいよね」

「そうですね……」

やばい。小毬さんワールドに引きずり込まれている。

「……あの」

「もう一個たべたい？」

「じゃなくて」

もう一個取り出そうとしているのを止めた。

止めないと無限にお菓子をくれる近所のおばあちゃんになりそうだ。

「プログラムを見たいと思って。見せてもらってもいいですか？」

「プログラム…………？」

キョトン。

その表現が的確だろう。

ハテナがいっぱい並んだ顔が私に向けられていた。

って！

もうわかった。

この顔をした時の小毬さんは本当に分かってない。

南雲くんの方に顔を向けると「何コイツ？」と言わんばかりに怪訝そうに眉を寄せた後、すぐにディスプレイに顔を戻した。

「なんで？」

吉村リーダーから言葉が飛んできた。

若干不機嫌そうな語気を感じる。

「仕様書を見たのですが文字数やエラー時のことなどが書かれていなくて。プログラムを見て把握しようと思ったんです」

「美月さんプログラムがわかるんですかっ！？」

「へ？」

小毬さんがキラッキラした目を私に向けていた。

道端で偶然アイドルを見つけたような、目の前の人が有名人だったとわかったときのような雰囲気というか。

「すごーい！！」

すごい……？

んん？

ここはテストコードを書いたり、テスト関連のことを専門に行う部門なのでは……？

「あのなぁ」

吉村リーダーが今度はあからさまに不機嫌な様子で口を開いた。

「俺らはそんなもん見る必要ないから」

「ええ？」

プログラムを見る必要がない？

じゃあ、ここのみんなはどうやってテストをしているというんだ？

「それだと何もわからず、目隠しで確認をするようなものでは……？」

思ったことがついつい口を衝いてしまった。

「オレがテスト項目書を作ってんだよ。それ見ながらアプリを操作すりゃいいんだ」

ハァァ、とこれ見よがしに大きなため息をついた。

「ったく、リリース前のクソ忙しいときに妙なこと言い出すな」

そのまま立ち上がるとドアの方に歩き出した。

「日野ー。タバコ吸ってくるわ。おまえ、そいつにテストのやり方教えておけよ」

「あ……はい！」

ちょっと困ったような笑顔で返事をする小毬さん。

――バタム。

吉村リーダーはドアの向こうへと消えていった。

うわーーー！！

腹立つわ、あいつ！

もっと言い方というものがあるでしょ！

と、いう思いが顔に出てしまったらしい。

「吉村リーダー、忙しくてピリピリしてるんだと思うよ。普段はもっとぼーっとしてるから」

小毬さん、それ、フォローしてるんだかしてないんだかよくわからない。

「今のさ、あんたも悪いと思うよ」

南雲くんが口を開いた。

「ウチにはウチのやり方があるわけで」

私に「やれやれ」といった目を向けてきた。

「いきなり新参者が知ったか顔で、状況も知りもしないで今までのやり方に文句つけてきたら来たら、そりゃ怒るでしょ」

「……………………」

…………。

……そうか。

そりゃそうだ。

南雲くんの言うとおりだ。

例えるなら、人の家に上がりこんでおいて「この家具ダサくない？　違うの見せて」と言ったようなものだ。

「ナグくん、美月さん今日がはじめてなんだし、テストのこと知らないんだし、優しくしてあげて」

――プイッ

言ってみただけ、と顔をそむける南雲くん。

口調はアレだけど、十分に親切なアドバイスだった。

「南雲くん、ありがとう」

「……いきなり君づけかよ。別にいいけど」

しまった！

心の中での呼び名がそのまま出てしまった。

本人が許可してくれたし、ま、いっか。

「――小毬さん」

「ん？」

「テストは、プログラムを使ってするものではないんですか？」

ある程度言葉を選びながら小毬さんに問いかけた。

「うん、そうだよ。わたしたちはプログラムにはのーたっちです」

「じゃあ、どうやってテストを……？」

「吉村リーダーがテスト項目書っていうのを作ってるんだよね。それに操作が書いてあるから、アプリを書かれた通り動かしてみて問題なければOK、問題があったらNGってやるんだよ」

なるほど。

私の乙女ゲー開発で言うならテストプレイの工程だ。

いわゆるシステムテストという部分。

ほぼ完成しているサイトやアプリを実際に手で動かして想定通り動作するか、あとはイレギュラーな操作や機能を組み合わせた操作などでバグを発見する工程といったところか。

私が気にしてた文字数といった細かな部分も、テスト項目書には設定する値がきっと書いているんだと思う。

「わたしたちは、アプリを触って仕様書に書いてある通りちゃんと動くかチェックするお仕事です」

えへん、と胸を張った小毬さんだった。

アプリじゃなくてWebサイトね、とツッコむのは野暮というものだろう。

けど引っかかるものがある。

本当にそれだけで大丈夫なんだっけ……？

そんなことを思ったけど口にするのは控えた。

もし試用期間で打ち切りになったら私は家賃が払えなくなるという切実な問題を抱えている。

それに南雲くんが言った通り、いったんここでのやり方を学ぶのが優先か。