実装とテストの微妙な関係

システム開発に必要な大事な要素,それは「実装」と「試験」だ。どっちかが良くても片方がダメダメなら全体が失敗する。この2つは言葉こそ違えど,「良いシステムを開発する」という目的は同じだ。しかし,特にPM(プロジェクトマネージャ)の志向によって,どうしても片方に傾いてしまう。かなりこの2つを綺麗に回すのは難しいだろう。

そこで,僕の思い描いている実装と試験の関係を,とりあえず気ままに書いてみる。

プロジェクトの中で,開発されたシステムを最も利用するのは,やはり試験を実施する人々だ。彼らは,目の前のソフトウェアが期待通りの動きをするかどうか,さまざまなパターンを想定し,ひたすら動作確認を行う。「こんなこと絶対にあり得ない」というケースでも,少しでも可能性のあることであれば,正しい動作をするかどうかチェックを行おうとするのが,試験を実施する人間の思考だと思う。

結局のところ,ソフトウェアの動作保証を行うのは試験工程であり,実装工程ではない。あくまで試験がソフトウェアの動作を決定する。

だからこそ,ソフトウェアの動作不良が見つかった際に,PMは試験を実施した人間に対して注意を行う。注意で済むこともあれば,激怒することもあるだろう。不具合を作りこんでしまった実装の人間が怒られることはない。不具合の個数がなかなか減らない場合にも,実装の人間が怒られることはない。「こんな後のフェーズになって,なんで不具合を見つけられなかったんだっ!!」と雷が落とされるのは,試験を行っている人間に対してだ。もっと言うと,画面の中で使いにくいUIになってしまったときに関しても,設計を行った人間ではなく,試験を行った人間が注意を受けるのだ。

動作保証された良いソフトウェアを作り上げるという目的のためにも,そして何よりもPMからのお怒りを受けないためにも,試験を行う人間は「仕様理解」を完璧なまでに行い,「仕様変更」を怖がらずに提案し,そして「不具合の発見」に全力を傾ける。そして継続的にソフトウェアの品質を気にしていき,考察を繰り返していく。PMに妥当と判断されるまで,その作業は続いていく。

それに比べて,実装に関しては,PMはあまりうるさく口を出さない。もちろん期限を守れない場合は指摘を受けるが,それほど雁字搦めになることはない。スケジュールさえ守られれば,バグが発生しようとも,それほど問題にはならない(限度はあるけど)。PMからのプレッシャーはそれほどなく,自由に仕事ができる。サボることは難しいことではない。

しかし,試験を実施している人間が,自分の書いたコードのためにPMに激怒されている姿を一度でも目にしてしまえば,あるいは,自分のコードの品質が悪いために,徹夜してまで試験を行っている人間を目にしてしまえば,サボるなんて気持ちは一気に吹き飛ぶはずだ。自分のせいなのに,自分が怒られるわけでもなく,他人が苦労していることほど,キツいことはない。普通の神経の持ち主なら,そんな状況を見たときには,かなりの自己嫌悪になるはずだ。

だからこそ,実装担当の人間は,試験を行っている人間のために,高い品質のコードを書こうと日々努力する。単体試験を繰り返し,異常系にも気を配って,試験に耐えうるコードを早い段階で作り上げようとする。もし不具合が見つかった場合は,試験を実施している人間に「申し訳ないっ!」という気持ちになり,自分の仕事の仕方を反省し,不具合の修正に全力投球する。

こうしてみると何か恐怖政治のようだが,一番厳しい状況になる試験担当者は,プロジェクトの中で「顧客よりも」権限を与えられる。顧客よりも業務や仕様を理解しているはずだからだ。そして実装担当の人間にとって,試験担当の人間の言うことは「絶対」である。「今日中に修正しろ」と言われれば,実装者は断ることはできない。また,人員構成についても,試験担当者の構成が優先される。また,工数の見積もりに関しても,試験の工数が重要視される。そして,試験に必要な投資を惜しむことはない。

これくらいの緊張感を持っていないと,真の品質は確保できないと思う。「怒られる」とか表現してしまったのでネガティブな印象を受けるかもしれないが,顧客の視点に立てば,いくら優秀な人間が実装していたとしても,その出来を確認する人間が不安であれば,全体が不安に感じてしまうだろう。それよりも,実装がおぼつかなくても,出来を確認する人間が適切であれば,正しい判断が繰り返し下されるはずなので,比較的安心してプロジェクトの進行を傍観できるはずだ。

実際にも,信用されるPMはバリバリ実装者ではなく,品質に関する高い認識を持った人間が多い。ただでさえ難しく複雑なソフトウェア開発は,実装ではなく,試験に注力する必要がある。もちろん,開発作業工程が成熟してくるにつれて違ってくるはずだが,そういう傾向が実感できるまでには,まだまだかかりそうだ。

・・・そのうち,EoDではなく,EoTって言葉が流行るかも。

このエントリーをはてなブックマークに追加

関連記事

スマートスピーカーはもう終わったデバイス?

QMK FirmwareとRaspberry Pi PicoでSPLIT_USB_DETECTを使わない方法

40%キーボードに慣れるためにやったこと

Lunakey PicoでQMK Firmwareを動かしてみました

Googleアシスタント向け会話型アクションが1年後にシャットダウンされます