「このコード、テストコードが書いてありませんけど」

「申し訳ありません。でも、この機能はなるべく早くリリースする必要があるので、テストコードは後で時間がある時に書きます」

これは、20年前から現在まで続いているシステム開発現場でのやりとりです。

テストコードの重要性は、私が新人の時から色々な書物やweb媒体を通して説かれていますが、実際の現場では未だに軽視されています。

テストコードを書かない理由をあげればきりがないのですが、一番の理由は

必要な労力に対して、受け取るリターンが小さい

と感じている人が多いからでしょう。

テストコードの実装には時間がかかります。

プロダクトコードを書くより時間がかかることも珍しくありません。

人は合理的に判断し損得で動くので、メリットを感じなければ行動を起こしません。

つまり、

ほとんどのエンジニアは、テストコードが重要なのを知ってはいるが、時間を割いてまでテストコードを書くほど重要だと思っていない

ということでしょう。

ちなみに私は

ユニットテストと結合テストは最低限通すようにしています。

理由は

ユニットテストと結合テストくらいまでは、テストコードを書いたほうが労力よりメリットが大きい

という個人的な経験則を持っているからです。

ただ、この考えは色々な経験を積んだ私がたどり着いた結論で、全員が同じ結論になるとは思っていません。

というのは、

実際の開発現場では、テストコードを書かない理由のほうが多く存在するからです。

今回は、その点について記載していきます。

評価されない

テストコードが書かれない大きな理由の一つに

テストコードを書いても周りから評価されない

ということがあります。

多くの現場では

とりあえず動くコード

を早く書く人がマネジメント層から評価される傾向があります。

また、エンジニア内で評価されるのも

綺麗なコード

というよくわからない主観的なコードを書く人だったりします。

この綺麗なコードという計測不可なコードに拘るのは、中途半端に力があるエンジニアであることが多いのもやっかいな所です、

このように、テストコードを書いても、誰からもあまり評価されないのが現実です。

また、バグの少ないテスタブルなコードを書く人より

とりあえず動くコードを書いて、バグが出たらすぐ修正

する人の方がエンジニアとして仕事を一生懸命やっていると周りも評価する傾向があります。

これは

ヤンキーが更生して真人間になって当たり前のことをやると評価され、最初から真人間が当たり前のことをやっても評価されない

ことと似ています。

このように

テストコードを書いても評価されにくい

という環境が、テストコードを書く文化の普及を阻害しています

書く時間がない

テストコードが書かれない次の理由は

書く時間がない

です。

これは

タスクの工数見積もりをする時に、テストコードを書く時間を入れて報告をしない人が多い

ということも原因です。

これは日本のIT業界の悪い慣習です。

なぜなら

テストコード書く人より、テストコードを書かない人のほうが必要な工数が短かくなる

のは当たり前だからです。

これは

テストコードを書く人は、タスクを終わらせるのに時間がかかる

と相手に受け取られてしまうリスクがあります。

また、別のケースでは

実際にかかる工数を大きく見誤り、結果としてテストコードまで手が回らない

ということもよくあります。

これまでの経験上

ほとんどのエンジニアは正確な見積もりを出せません

中には開き直って

見積もりなんて意味ない

と豪語する人もいます。

見積もりがうまくいかない原因は

割り当てられたタスクと自分の能力を正しく評価できない

からです。

もちろんこれは難しいことです。

しかし

95%のエンジニアは、タスク完了に必要な時間を過小報告してきます。

具体的には

10日間必要なタスクを「5日間で終わります」のように、タスクを過小評価して報告してくるケースが多いです。

「本当に終わります？」

と聞くと

「多分大丈夫です」

と返してきますが、こういう返事をする人はかなりの確立で遅延します。

このようなやり取りに慣れているベテランの管理者であれば、最初からスケジュールを長めに見積もることができますが、この業界に初めて来た人は驚くでしょう。

このように

多くの現場ではテストコードを書く時間を考慮しない

のが実情です。

これが

エンジニアがテストコードを書く習慣が身につかない

一因になっています

役に立つのは時間が経ってから

テストコードが書かれない最後の理由は

テストコードが役に立つのは時間が経ってから

という理由です。

テストコードを書くことは

プロダクトに対する長期投資

です。

なぜなら、テストコードが威力を発揮するのは

• 既存の動作が速度等の問題で改修が必要

• 既存の動作に追加等の条件を付加する

• 複雑なコードに手をいれる必要がある

ような場合です。

このような場面は、最初にコードを実装した数年後に訪れるケースが多く、ほとんどの人はテストコードの恩恵を感じられないでしょう。

つまり、テストコードとは

未来の自分や、未来に自分が実装した箇所を変更する人が、素早く安全にコードを変更できるための投資

です。

しかし、多くのエンジニアは

長期目線でプロダクトを見ることが出来ません。

長期目線でプロダクトのことを考えるのは

経営陣やプロダクトマネージャーになります。

実際は経営陣がプロダクトの実装レベルに口を出すことはないので、テストコードを書く書かないの選択をするのは

プロダクトマネージャー

になります。

しかしこれまでの経験上

「テストコードを書くように」と指摘するプロダクトマネージャーはほとんどいませんでした。

テストコードがなかなか浸透しないのは、エンジニア達を束ねるプロダクトマネージャー達にも問題があるのかもしれません。

まとめ

今回は

開発現場でテストコードを書く文化が普及しない理由

というテーマで記載しました。

まとめると

• 評価されない

• 書く時間がない

• 役に立つのは時間が経ってから

になります。

昔からよく言われていることで

まず誰かがテストを書きはじめてテストコードを書く文化をつくる

という言い伝えがあります。

しかし、実際はテストコードを導入しても、同じようにテストコードを書いてくれるのは一部のエンジニアです。

そしてそれを継続できるのは、さらにごく一部のエンジニアです。

会社の文化はそんな簡単に変わるものではありません。

世の中と同じで、人の考えはなかなか変わらないからです。

また、テストコードを書く文化が育つかどうかは、環境も重要です。

経営層やプロダクトマネージャーなどがテストコードの重要性を理解できるように、パレート図や管理図を作成して、slackなどで誰でも閲覧可能にしておくのも良いでしょう。

テストコードは初期投資のコストは大きいですが、時間が経つほどリターンが大きくなります。

また気をつけて欲しいのは、テストコードがあるから良いプロダクトというわけではないということです。

テストコードを書くことは、長期でプロダクトを成長させるのに、とても良い手段の一つであるということです。

絶対的に必要な投資ではありませんが、まずは試してみることをおすすめします。

きっと、「書いておいてよかった」と報われる時が来るはずです。