使われ方を考えてから作り方を考えることを考えることについて再考する機会があったため纏めます。
はじめに：問いの始まり
先日、若手エンジニアから「なんで実装の前にテストを書くんですか？」と投げかけられた質問に対し、私は「作り方と使われ方というものがあってだね～」と説明を始めました。
ところが、言葉に詰まり、自分の中で整理できていなかった部分に気付きました。
もともとの理解
私が「使われ方を考えてから作り方を考える」という視点に出会ったのは、fukabori.fmでのt_wadaさんのTDD解説でした。
そこで語られていたのは、「使い方を先に考えることで作りやすくなり、作ったものが期待通りに動くかを短いサイクルで検証し、学びながら進められる」という考え方で、私はこの考えに共感しました。
現場で感じた違和感
現在の開発プロセスでは、実装に入る前に受け入れテストや結合テストをドキュメントベースで定義するフローを採用しています。
一見「先にテストを書く」という点でTDDと近いように見えますが、実際にはフィードバックの速さやテストの役割が異なります。
その違いを自分で整理ができていないまま説明をしてしまっていたため、違和感があったことに気付きました。
「使われ方」とは何か
考える中で気づいたのは、「使われ方」という言葉が曖昧だということでした。
-
ユーザー視点での使われ方（業務・操作フロー）
- プログラムコード同士の使われ方（インターフェース・呼び出し）
この2つが混在していたため、「テストを書く前に使われ方を考える」ことの意味がぼやけていたことに気付きました。
TDDで見えてきた本質
改めてt_wadaさんのTDDの話を聞き直しました。印象的だったのは以下の言葉でした。
テスト設計やインターフェースの設計は若干理想から入っていく。理想一辺倒になるとオーバーエンジニアリングになる。
実装はどちらかというと現実解。現実解一辺倒だとアンダーエンジニアリングになる。
テスト駆動開発は、その中間を探り続ける設計プロセス。
また、テストファーストプログラミングの説明では、「先に使う立場に回ることで、使いやすさに気づける」という話もありました。
TDDとは、作る前に一度“ユーザー（＝テストコード）”の視点に立ち、使われ方から設計を導くプロセスでした。
自分の誤解と苦しさの正体
私はTDDの考え方を、受け入れテストや結合テストにも拡張してしまっていました。
しかしこれらは、実装が終わった後に動作を検証するものであり、TDDがもつ短サイクルでのフィードバックとは性質が異なります。
また、ドキュメントベースのテストでは、自分の実装に対して即時にフィードバックが得られないという点も苦しさの一因でした。
それでも「使われ方」を先に考える理由
それでも私は、「使われ方を先に考える」ことが重要だと感じています。
なぜなら、使う側の視点に先に立つことで、設計に客観性と意図が生まれるからです。
使いやすさを考慮した設計は、実装のしやすさとは必ずしも一致しません。
だからこそ、先に使われ方を想像し、それを実装のガイドとするTDD的な思考は有効だと思います。
作り方が手段であるのに対して、使われ方が目的であるからとも整理ができるかも知れません。
ただし、それはプロセスとして何を意図しているかという価値観の共有があってこそ、意味を持つのだとも思います。
まとめ
今回の整理を通じて、自分が受け取った情報を無意識のうちに“自分に都合よく”解釈していたことに気づき、反省しました。
一方で、そうしたモヤモヤを言語化し、立ち止まって考え直すこと自体が、理解を深めるために大切なのだとも実感しました。
この視点をチームと共有し、開発プロセスの目的や価値観を一緒に明確にしていけたらと思います。
