増14．“テストファースト”と言われて

スキル

» 2012/10/29

●今回の発端

　筆者は直接は言われたことはありませんが、別の所で仕事をしている人などは、「テストファースト」でプログラムを作るのが良いと言われたことがあるそうです（その人は「緑の文字」と言われただけで嫌そうな顔をしていました）。Webの記事などでも見かけます。

　もちろん、人間の価値観で軽重の無いプログラムの成果を、人間の価値観に引き込む唯一といっていい方法がテストです。テストは必要です。

　しかしながら、“仕事で分担して作業しているプログラマに直接”“「テストファースト」をしろ”と、言われると、まるで「労せず実務上の権限をごっそり奪取しよう」としているように聞こえます。多分、周りの人が手をこまねいていると本当に奪取されるかもしれません。

　なぜ、良いことのはずが、こんなにひどいことになるのか？ その辺りを描写したいと思います。

●背景説明

　学生のプロジェクトなどで、

• 自分一人でやっている

• デザイン担当はいるが、ノリでそれを改変しても問題なし、むしろ意欲があってよろしい

という環境なら「テストファースト」は非常に良いかもしれません。究極の少人数で手掛かりもないところに、それが見つかるのですから、悪いはずがありません。

　ただし、仕事でプログラミングをしている場合、

• 大枠を誰かが作る（誰が作るかは割と自由で、そこそこ書けるようになった新人の場合もあれば、ベテランの場合もあります）

• 個別の機能を誰かが作りつつ、必要な共通機能を誰かが作る

ということになると思います（複数人数で個別の機能を作ってもばらばらになるだけです）。ここで問題なのは、どこがファーストか？ ということです。上記の例では「大枠を作る」のがファーストに見えますが、ほぼ中身は作らないので、テストしようがありません。しかしながら、テストしがいのある個別の機能に着手できるころには、勝手なテストソースを混ぜ込むだけの余地は残っていなくなります。

　できるタイミングが無いのに、指示を出すことは無責任であり、無責任な人間に対して周りの人間が手をこまねいていることは、社会の成員として不誠実です。もちろん、相当の金額を投資して、対価をもって権限を得た場合でしたら別ですが、その場合の金額は家計レベルでなく、事業レベル（2桁は高い）となると思います。

●さらに説明

　さらにそもそも、プログラミングはファーストではありません。その前に、設計があります。そして、その設計内容は「ノリで改変する」ことあたわざるものです。

　もちろん設計は（アニメでいう動画と原画の原画に当たる）大まかな物で、（動画に相当するものの担当の）プログラマも質問したり、すりあわせをしたりしてコミュニケーションを取る必要がありますが、その際、設計者に対して意見をしたりする知見の元は、実際にやってみた実体験です。少なくとも１度は実体験をしないと、前々から準備してきた設計者を揺り動かすだけの知見は得られません。

　（自分の置かれた制限の中で闇雲に何かをやる）実体験がファーストだと思います。何もやらずに手を動かさずに設計者の意図とは独立してテスト内容を「ファースト」で思い付くのは人智を超えていると思います。

●本当に“テストファースト”を望むのなら

　本当に“テストファースト”を望むのなら設計者、それもアーキテクトクラスの設計者に言うべきだと思います。そここそがまさに「ファースト」です。

　VBなど「任意の箇所で任意の資源にアクセスできて当然」みたいな作りのシステム（作りやすい代わりに、確定的なテストをするためには、すべて画面から手で打ち込まないと×）を、設計段階からもう少し“不自由”にしてもらって（MVCパターンとか）切れ目を利用してテストしやすくするなど、できたら最高ですが、そのような全体の決定は高位の設計者の役割です。
プログラミングの段階で個別のプログラマに、そのような決定を強いるのは、間違いなく権限の簒奪です。

　まぁ、今回はこんなところです。

●コラムのコメント欄の方針

　コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。

ですので、このコラムで、
　・わたしは基本的にコメントに答えない
　・コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。