🌊

テストコードを書くようにアウトプットしてみる

2023/11/26に公開

はじめに

最近、アウトプットを増やそうと思って、手段の目的化状態になってた僕です。
僕も正直、なんでZennとかQiitaにドキュメント残してるんだろう?と思って一カ月ほどが経ちました。
もやもやした気持ちを抱えつつも、つらつら書いてたわけですが、ふと、テスト駆動開発と技術記事を書くことって似てそう、と思ったので、思考プロセスを残しておきたいなと思いました。
誰かの技術記事を書くモチベーションになれたら嬉しいです。

仮説:僕ら人間もWEBアプリケーションかもしれない?

思考実験として、いったん僕ら人間という曖昧な存在を、WEBアプリケーションとして考えてみたいと思います。
私 as WEBApplication みたいな感じです。

そう考えると、実は「私」はかなり壊れやすいプロダクトなんじゃないか、という気がしてきます。

  • 昨日できたんだけど、今日できない、もあれば、昨日できなかったけど、なんか今日できる、みたいなこともある。
  • 一年前に使ってたRailsのあれこれが今だともう思い出せないとか。
  • 動かせるけど、人に説明できるほど仕組みを理解できてないから、結果的に時間が経過してからまた同じようなデバックをしてまたゼロから動くように調査する場面とか。

開発を進める中で、今まで使えていた機能が壊れてしまったり、一部の修正が影響して他の機能のバグが生まれる、といったことは発生してしまうと思います。

これって、人間にも当てはまるのかなと思うのです。

つまり「私」は全然品質が保証されていない、言い換えれば冪等ではない存在なんじゃないかという気がしてきます。

人間 as WEBApplication のテストを書く

類似的に考えると、WEBApplicationにおける品質保証はテストコードで担保されるとするならば、人間の場合にその品質保証はどう担保されるんだろう?というのがふと気になりました。

定式化すると以下の三点を満たす何かが必要そうです

  1. 品質を保証するためには、常にインプットに対してアウトプットが一定であるように記述できる必要があります
  2. その記述が検証できる必要があります(正当性)
  3. 検証の手続き自体の正しさが担保されていることも必要です(正統性)

WEBApplicationの場合はそれがUT,IT,E2E,VRTなどのテストでカバーされるわけですが、人間の場合はどうでしょうか。

品質を保証するためには、常にインプットに対してアウトプットが一定であるように記述できる必要があります

まず、定式化1については言語がそれにあたりそうです。
これは自明なので、説明をしようとすると同語反復になりそうなので、割愛します。

その記述が検証できる必要があります(正当性)

では定式化2はどうでしょうか。
検証という概念を少し分析する必要がありそうです。
言語で記述されたものが検証される、ということはどのような構造を持つでしょうか。

それは以下のように定義できる気がします。

書き記されたものと、その対応関係になる対象(事態)が一致していること

ちょっと回りくどい言い方のように見えるかもしれませんが、例えば手順書を例に考えてみましょう。
手順書に書かれてある通りの手順を履行すれば、目的となる結果が得られることが上記の定義と等しいです。

具体的には、コーヒーメーカーの手順書に

  1. 水を入れる
  2. コーヒー豆を入れる
  3. ボタンを押す
  4. コーヒーが出てくる

と書かれていて、その通りに作業したらコーヒーが出てくることは、文字で記されたことと対象(事態)が一致した、と言えるかと思います。

ここで注意点としては言語で記されたものが必ずしも対象(事態)と一致するわけではないということです。

例として挙げると「白いは重い」は文としては成り立つけど、意味としてはその文が対応する世界の対象や事態がないためにナンセンスです(メタファーとしての意味が云々、となると説明できてしまいそうですが、ここでは掘り下げません)。

検証の手続き自体の正しさが担保されていることも必要です(正統性)

最後に定式化3について考えてみたいと思います。
これは、定式化2がhow to に関するものである、とラベリングするとすれば、定式化3はwhyに関するものである、と言えそうです。

とりあえずこうしたら動くんだけど、そのメカニズムはわからない、といった場合、定式化2は満たしているけど、定式化3は満たしていない状態です。

多くの場合は、公式ドキュメントが最終的な原理を記すものになると思うので、ざっくり言えば公式ドキュメントに該当する箇所の索引を明示できていれば基本的には定式化3はクリアになるのではないでしょうか。

TDDでも、テストすべき箇所をテストできていないアンチパターンがありますが、それ自体が正しさを担保できているのかどうか、といったメタ的な視点は人間もアプリケーションも等しく関心の対象として持つべきかなという気がします。

さいごに

ここまで読んでいただきありがとうございました。
ふと、思いついたアイデアを書き出した内容となってますので、不足や不明点などがあればご指摘いただけますと幸いです。

Discussion