分岐網羅に学ぶ
ゲームのRPGってジャンルでは、たひたびエンディング分岐と言うものが見られる。ものによってはバッドエンドを見てないとトゥルーエンドに行けなかったりするし、ノーマルエンドが無数に存在するものもある。プレイヤーはその全ての物語を見たくて、全ルートを網羅するようにプレイする訳だ。
システム開発の現場では単体テストというものがあり、これはざっくり言うと設計通りにプログラムが動いているか、をテストする工程である。この工程では期待値が想定どおりであるかはもちろんのこと、全ての分岐を通過したシナリオが作れているか、も大事な指標になってくる。
プログラム上の全てのルートが網羅されていなければ、シナリオが甘いってことになるし、場合によってはそのルートの挙動が仕様として曖昧になっている可能性も出てくる。
この曖昧になるって部分はRPGのシナリオ分岐も一緒で、一つ見逃すと最終的にストーリーが上手く繋がらず、ぼやけてしまう箇所が出てきてしまうのは、RPGをやったことがある人なら分かると思う。
単体テストはシステムエンジニアとして開発系の業務にアサインされたら、まず初めにやる可能性の高い作業の一つだ。そして、開発工程の中でも取り返しのつかないことが起こりかねない重要な工程でもある。
だけども、この作業は開発現場では比較的軽視されている傾向が強く、事実、しっかりした指導はないようにも思える。
現場の指導員は基本的にただ単体テストの実施方法を教えるだけになりがちなのだ。もちろん、実施方法については使っている言語によってある程度標準化されている部分ではあるので、今後も役に立つものだとは思う。だが、それでは単体テストはなんのためにやっているのか、という工程への理解が薄くなってしまう。
あくまで試験方法ってのは、試験を遂行するための手段に過ぎず、試験が遂行できるのであれば、どんな手段を取ったっていい。SQLでクエリを発行するだけのモジュールであれば、直接クエリを投げ込んだっていいし、後の工程で分岐網羅できるのであれば、別にそれだっていい。要はそのモジュールの役割、挙動を正しく理解してさえいれば、どこかしらで拾うことができるわけだ。
単体テストに向き合うことで、この辺の感覚が身についてくる。他の人が作ったシナリオを見たとき、これはこのモジュールには関係なくね？とか、これどっかから適当にコピってきただけで中身全然違くね？みたいな違和感を察知する能力も、ここで身につくと思う。
これは自分の中でも非常に重要だと思っている考え方で、一般的な開発現場の要件定義〜詳細設計という工程があったとき、どこで何を確認すればよいか？というベースには、新人の頃にやった単体テストの考え方があるし、この設計書の記載合ってなくね？とか、そもそも要件的にちょっと怪しくね？とかの感覚も、根底には単体テストでの経験があったりする。
どんな作業においても、ある程度批判的な見方は必要で、これがないと何となく作ったものがそのままリリースされてしまったりする。少しでも違和感があれば、遠慮せずに伝えることが重要で、これがSEにはコミュニケーションスキルが必須、とか言われる理由でもある。
最近は業界的にリモート作業が多くなってきて、相対的に対面で話し合う機会は減ってきた。これによって、対面のコミュニケーションよりテキストコミュニケーション、文章力がよりスキルとして重宝されるようになってきている。
指導する側も、指導を受ける側も大きな変化が求められている時代だ。自分も、ベースにあるものは残したまま、時代に対応できるエンジニアでいれるよう精進していきたい。
作業するだけになっちゃいけない、その作業がなぜ必要か考えるんだ。そうしたらやる必要のない作業も見えてくるから。その方が楽しく仕事できるんだ。なんかまとまらない気もするけど、今日はこの辺で。