🤷blog.takuyasuemura.dev

中身が見えないのは別に色関係なくない？ (From

開発エンジニアとしては、なんとなくブラックボックステストは軽視しがちというか、「今あるコードが仕様、以上！」というようなスタンスで動くことがままある。一方で、CSから「これこれこういう挙動について問い合わせがあったんですけど、これって仕様ですか」なんて質問が来た時、いや仕様書見ろやなんて思ったりしたら、実は仕様書に書いてない挙動で、しょうがないからコード読みに行ったりすることもある。

考えてみれば、開発エンジニアの人数なんて組織の中でたかが知れている。コードにしか書かれていない情報は、開発エンジニアしか見ることが出来ない。これは完全なるサイロだ。CSもセールスも、果てはユーザーさえ、公開されていない情報は「推測」するしかない。

ちょっと前の話だが、スプラ3の 懲罰マッチング なんてものが話題になっていた。これは頻繁な通信エラーやどう見ても不利なマッチングなどの不可思議な挙動を分析していくと、レート調整のためにユーザー体験を損ねるようなマッチングのアルゴリズムを意図的に仕掛けているように「見える」というものだった。だが、どれもこれも推測でしかなく、実態は開発者含めシステムを運営する「中の人」しか分からない。

繰り返しになるが、公開されていない事柄は推測するしかないのだ。これはあらゆる物事について同様である。起きている事象や、部分的に公開されている情報から、どのようなアルゴリズムになっているのか、背景にどのような意図が隠されているのかを推測する。ブラックボックス、あるいはサイロの外側にいる人達は、良い悪いは別としてそうするしかない。

対ユーザーとの話であれば、公開すべき情報、そうでない情報があるだろう。会社や組織、チーム、果ては一人一人の人間関係の中でも、公開しないほうが良い情報もある。だが、公開されない情報は憶測を生むことがある。憶測の結果は、憶測している側の感情に左右されることがある。人間関係であれば、しょっちゅう無断欠勤している人間について、「私生活がだらしない」などの憶測を生む可能性がある。仮に事実が病気や家庭の事情などやむを得ないものであったとしても、周囲の人間はその人に対して「だらしない人間だ」と評価するかもしれない。スプラトゥーン3のマッチングの例も非常に典型的だと思っていて、起きている事象をどう解釈するのかは人それぞれだ。

だいぶ話がそれてしまったが、開発の話をしよう。コードを読み書きする人間は、この事実をよく覚えておく必要がある。自分が書いているコードを読み書きできる人間は、組織の中でもごく少数の人間であると。そして、大抵のソフトウェア企業は、その「中身の見えない」ものをどうにかして売っていると。

ユーザーにとって、ソフトウェアの中身がどうなっているかなんてことは大した話じゃない。だが、CSやSalesにとっては重大なことだ。顧客からの質問に正しく答えるためには、ソフトウェアがどう動くのかがきちんとわかっていないといけない。良く分からないことについてはエンジニアに聞いたり、自分たちでテストしてみたりすることもあるだろう。

テスト、そうだ、テストだ！ブラックボックステストの話にようやく戻ってきた。テスターやQAも、良い悪いは別として、コードの読み書きが苦手だったり、システムアーキテクチャについて理解が浅いことは多い。だが、仕様をよく理解して、仕様に書かれていない物事やエッジケースを探し出して、試してみて、不具合を見つけ出すことに長けている。

プログラミングによるソフトウェアの実装は、提供するサービスそのものではない。奇妙に聞こえるかもしれないが、これは真実なのだ。サービスを受けるユーザーからしてみれば、裏側に人がいようがソフトウェアがいようが関係ない。だが、開発者はつい「ソフトウェア」こそが自分たちの提供している製品そのものだと勘違いしてしまう。だが、実際のところはサービスの裏側をソフトウェアという手段で実装しているだけだ。クリーニング店のたたみ加工を人間がやるかロボットがやるかの違いのようなものだ。

ソフトウェアは人間よりも大幅に複雑な物事を成し遂げられる。そこにはさまざまなユースケースが想定される。提供しているサービスについてどのようなユースケースを想定して開発し、どのようなものは想定していないのか？それらは良く考えられていて、仕様書などの形で見えるようになっているのか？

話が飛び飛びになってしまったが、要するにこういうことだ。開発者にとって、自分たちの仕事はすべて公開されているように見えている。コードはGitHubに全部上げてあるし、何かを変更するときはPull Requestを出して、他の開発者のレビューを受けている。リリースするときはPull Requestから自動生成されたリリースノートが作成され、Slackにポストされる。

だが、これらはみんな、実は他の人達にとってはブラックボックスなのだ。エンジニアが考えるVisibilityと、他の人達が考えるVisibilityは全然違う。なぜなら、大抵の人間にとって、コードは異次元の言語なのだ。エンジニアたちがどのような流れでソフトウェア開発を進めているのかは理解できても、それによって何が達成されたのかは分からない。エンジニアが成し遂げたすべては、実は他の人たちにとってのブラックボックスなのだ。

だからこそ、ブラックボックステストは重要だ。しかも、テストそのものではなく、その前が。これから提供しようとしているプロダクトが、サービスが、どのような目的を達成し、どのようにユーザーにとっての価値を生むのかを、より具体的に定義する。それが出来ないと良いテストは出来ない。

もっと言えば、テストの前に決めておくべきことがちゃんと決まっていれば、ブラックボックスの中身は明らかになるのだ。一言で言えば「仕様を明確にする」ただそれだけなのだが、そこにテスターが寄与できる部分は多い。そして、それは明らかに組織にとっての価値になる。開発チームの、そしてソフトウェアのVisibilityを高めるという点において。