ソフトウェア開発では、テストという作業はコードを書いたり動かしてみたりするのとは異なる独立した何かではなく、それ自体が開発における一つの工程です。ソフトウェアを作るということは、コードを書いて動かしてテストするところまでを含み、そのどれかが欠けてもソフトウェアを開発していることにはならないのです。

昔々、まだ人類が音楽をお金を出して買っていた頃、遥か彼方の銀河系では、テストは開発とは独立した工程として扱われていました。開発部門のプログラマたちはコンテンツ企画部の取締役から手渡された企画書を元に、なんとかそれに似た動きをするソフトウェアを設計開発し、Excelでテスト項目の一覧を作ると、それから休日返上でテストします。開発部門のトップを担う取締役はこんな時にもちゃんと会社に顔を出して一緒にテストを手伝うほどの人情家ですが、あまり芳しくないテスト結果にその表情は曇りがちです。そこから全員で徹夜の修正作業が始まり、こちらもExcelで管理されたスケジュールのガントチャートの下の方で動かざること山の如き存在となっていた期日の朝、誰もが目を真っ赤にしたまま、ソフトウェアはようやく一応の完成をみました。

倉庫や休憩スペースで眠りこける開発者たちを代表して、その日の経営会議には開発リーダーが呼び出されて参加しています。定刻通りに始まった会議の席で、リーダーは居並ぶ経営陣の前で完成品を披露します。取締役会のメンバーたちは、ふん、どれどれお前ら穀潰しどもがちゃんと言う通りに働くだなんてオレは少しも信じちゃいないからな、という顔で画面のあちこちを触り、気に入らない箇所をいくつか指摘します。口も悪いが態度も悪い上に性格もかなり悪い営業担当の役員が、それで、こいつはいつまでに完成するんだと開発陣を睨みつけ、色々と事情を説明する開発リーダーに「はぁ?随分と偉そうに言うやんけコラ、ほんまにできるんか?」と河内弁で絡むのですが、この時の印象があまりにも強かったので、数年後にこの役員から自分が設立した新しい会社で名刺をベースにしたSNSの開発をやらないかとメールで誘われた際もリーダーの脳裏にこの時の鮮やかな記憶が蘇り、最後まで読まれることもなくメールはゴミ箱に消えたのですが、それはまた別のお話です(ちなみにそのサービスは立ち上がらなかったので現存のいかなる類似のサービスとも無関係です、本当に)。とにかく、会議は訳のわからない方向にそれたまま終了しました。哀れな開発リーダーはそれでも先が見えてきたことにわずかな喜びを覚えつつ今日も残業します。

一方その頃、開発部門のトップは部下の作成するソフトウェアの「バグの多さ」について他の取締役から激しく詰め寄られています。なんでこんなことになるのか。大体、こんなもの企画書通りに作ればいいだけのことじゃないか。何回同じようなものを作っているんだ。早急に改善策を提出しろ。そんな要求を受けて開発部門が自社フレームワークを書き上げ、それがなんだかんだと多少利益を生み始めた頃、大した実績もないのに雇ってもらった借りもそろそろ返しただろうと悟った開発リーダー(左遷されて閑職にあったけど)は、失われた自尊心を多少なりとも取り戻せるなら仕事の安定なんか糞食らえだ、もう会社員になど二度となるものかと誓ってフリーランスへの道を歩み始めたのでした。

みなさん、これ笑いながら読んでます?書いてる本人は、これ全部身に覚えがある事なので、というか例え話を書いてるうちにどんどんただの自伝になっていったので、無為に失われた人生の貴重な時間に身悶えせんばかりなのですが。

ここから得られる教訓は、大抵のことはこの組織と逆のことをやればうまくいくというもので、それ以来ずっと人生の指針にはなっています。ええと、何の話をしてるんだっけ。そうだテストだ。テスト。テストって、例えば学校とかだと、何か勉強をして、その成果を確認するためのものですよね?ソフトウェアにおけるテストというのは、それとはやや意味合いが異なります。人間は当然間違えるし、それを防ぐ完全な手立ては存在しません。ソフトウェア開発におけるテストは、仕様を実体化するプログラミングという行為の補完物として存在し、それ以上でも以下でもありません。どちらも合わせて初めてソフトウェアの開発と呼べる行為になります。バグの発生率なんてのを人事考課と絡めるなんていうのは愚の骨頂で、そうなればプログラマは誰もテストの場にコードを提出しなくなります。テストは可能な限り密室で進められ、その結果は事前に担当者同士で調整、上に報告される前になんとか体裁を取り繕われるようになるので、誰も現場の実態を知らないままひたすら退職者だけが増えるので経営者は首を傾げますが、安値で雇えるプログラマなんていくらでもいるだろうと安心して、やがて会社は泥舟のように沈んでいきます。

レトリックの力というのはとても強力で、同じ「テスト」という言葉を使ってしまったばかりに学校のテストとソフトウェアのテストの概念を混同してしまうケースは後を断ちません。明太子がスパイシーキャビアという名前を得て海外でも受け入れられるようになったように人間の認知には概念の力が強く作用します。ソフトウェアの世界では、これと似たものに建設工事のアナロジーという問題もあります。ソフトウェア会社も普通の会社なので、経営上の様々な管理項目があり、製品開発にあたってはその工程や進捗を管理し、各スタッフがどれだけの作業をどの工程に費やしたのか細やかに記録する必要があるのですが、そのほとんどは建設工事の用語や概念を用いて説明されます。そのため、作業には完成期日があり、それに向けた作業計画があって、そこから逆算して様々な計画が立てられることになります。

そのどこが問題なのかわからない人のために説明すると、ソフトウェアには建設工事では考えられないような大逆転が起きることがあります。建物には建築法のような規制もあり、また家屋であれば屋根や壁が揃っていること自体に意味があるので、計画と異なることがあればそれ自体が大問題なのですが、ソフトウェアの場合は、もっと柔軟に対処するべき事態が作業中にも様々な形で現れます。当初予定されていたある機能が全く不要であることが判明したり、長大なコードがデータ構造の見直しで単純な操作に全て置き換わったりするようなことは珍しくもありません。もし、その際に工期と工数だけで物事を判断していると、最適解を見つけて作業を簡略化したらその分だけソフトウェア開発者は貰えるお金が減ってしまいます。その結果、無駄で長大な作業の方が最適解となってしまうわけですが、実際に作業の遅いプログラマの方が得をする現場というのは珍しい存在ではありません。主に大規模なソフトウェア開発でそのような光景を目にすることがあります。単純な話、下請けの仕事は怒られない程度にギリギリまで遅い方が、中抜きする立場の会社にも利益になります。だからこの先もこの傾向が改善されることはないのかもしれません。

まあそれだけなら大企業が余ったお金をばら撒くだけなので社会全体にとってはいいことなのかなという気にもなりますが、ベンチャー企業というのも得てして実態はただの中小企業なので、案外と大手のやっていることをそのままなぞっている会社も少なくないのではないでしょうか。

それに、ソフトウェアの開発は誰か優秀な人がいればどんどん縮まるというわけではありません。その逆に、例えば新たな攻撃手法に対応するため予定外の作業が追加されたり、依存していた製品の脆弱性を発見してしまい全てのテスト計画が台無しになることもあります。その時、もし会社が建設現場のアナロジーのまま工程を管理していれば、ひょっとしたらもうプロモーションのための予算でイベントの開催日が決まっているかもしれないし、CMの放映を優先しないと広告代理店からも怒られる上に、全国に展開した専用の配達サービス拠点は毎日ただ何もせず赤字を垂れ流すことになるかもしれません。ああ、まあ、でもどんな工程管理をしていてもそこに不測の事態というものを織り込んでいなければその分だけこんなことはいくらでも起こり得るんですけどね。

実は、このような問題にすぐに効果があり、どこの会社のどの現場にも適用すればたちまち効果覿面となる素晴らしい手法などというものは存在しません。あるという人たちもいますが、まあほぼ全てがYouTubeの動画を見るだけで英語がペラペラになるという東大生だけが知っている秘密の手法と同じで、あなたが抱える問題にかこつけて現実から目を逸らすためのツールを売り飛ばそうとしている人たちがでっち上げたか、自分でも本当に効くんだと思い込んでしまった哀れな人たちが押し付けてくるだけのものです。余計な脂肪があなたの肛門から排出されてトイレに脂が浮いて困る日は決してやって来ません。ソフトウェア開発というのはmoving targetであって、いい加減な知識はすぐに陳腐化すると相場は決まっているため、われわれソフトウェア開発者は毎日その知識を更新するよう迫られ続けているわけですが、それは仕事を依頼する側にとっても全く同じなのです。

Leanうんちゃらとかスクラムとかも、究極的な目的はmoving targetを相手にするんだからこっちもゴールを動かしたり目的地を変更したりしやすくしないとねということに尽きると思うんです。そのための手段なので、実際の適用となると無数のケースが存在するので、牛丼屋の牛丼ほどの再現性は望めないのが正直なところだと思います。それでも、われわれはなんとかほどほどのゴールを目指そうとするのですが、キレイなお屋敷が建設されないと気が済まない人々の理解を得るのはとても難しいです。

でも。こんな当たり前の、もはや言い古されたといっても過言ではないようなことを、どうして今またこうして書いているのかというと。最初に書いたような経験をしてきたものだから、この歳になってもいまだにテストが怖いんですよね。テストの期間はうまく眠れないし、何か発見されようものならSlackに飛びついてああどうしようどうしようと慌てている自分に気付いたり、気付いた夢を見て飛び起きたりします。テスト駆動開発をしても実際のテストはまた別に必要なので、これに効く手法っていうのもなかなかないんですよね。みなさんがテストは工程の一つであり、そこで予想外の問題が発見されたとしても、それこそがソフトウェア開発であり、その予想外のことに対処する準備をするために私たちがいるんだよ、だから安心してコードを書いてくれたまえと言ってくれる人が一人でも増えるように、こんなことを書いているのです。そうじゃない連中はみんな役立たずだから。やーいやーい