プログラマはテストコードをかくべきか？それともひたすら製造するだけでよいか？
"その昔、中国の人工が安かった時代のお話
品質が悪いものは捨てて、生産した良いものだけとりだしていた。それでも、納品数が想定以上あり、利益もでていた。
ソフトウェア開発も、外注にどんどん製造させて、QC担当がどんどんテストすればいい"
先日、社の某氏に、上記のような事を言われました。この件に関して、一度私の中でも、整理してみました。
どんどん製造させればよいという話になった経緯
この話が出てきた経緯を書きます。2019年期になってテストコードを必須にする施策をとりました。そのため、最初の半年位は、テストコードを書く：製造の意味でのコードを書く＝1.2:1 と、コードを書く時間が倍以上になっている期間がありました。（最近は、0.5～0.8：1くらいになってきています。）それなら、「テストコードはいらない」という話なり、このような発言がでてきました。
なぜテストコードを書くのか？
エンジニアチーム内で、いつも言われている、テスコードを書く理由は次の通りです。
1）コーディングした担当者の心理的安全
2）同じテストは、自動化することによる、工数削減
特に弊社の場合は、ロジックは一緒で外見が違うケースが多々あり、同じテストを繰り返すため、工数削減効果は大きいと考えています。
3）将来的にはCI（自動テスト・自動リリース機械）をまわすので、そのための準備
4）工業製品のように最初からきっちりきまっていないので、作りながらで試験内容を変える必要がある
5）自動テストができるので、いつでも、リファクタリング（コードの改善・修正）ができる⇒コードのカイゼンされることによる、機能追加時の工数削減
最後（5)の、リファクタリングが特に重要。そもそも、製造品とソフトウェアには違いがあります。
・工業製造品・・・あくまで、製造品、作り終わったら、製品そのものは変わらない
・ソフトウェア・・・継続的に、修正するもの、製品そのものが変わっていく
レガシーコードからの脱却に書かれていましたが、「ソフトウェアにかかるコストの最大80％は、最初のリリースより後に発生する」ものです。
ソフトウェアは、リファクタリングをしないと、複雑化していき、最終的に、改修コストが跳ね上がって戻ってきます。リファクタリングできるようにするためにも、テストコードが必要と考えます。
テストコードは、製造するプログラマでなく、QC担当に書かせればよい？
先の話でいうと、製造担当とQC担当を分けて、それぞれの専門家に、させればいよいという話になります。エンジニアチームのメンバーの中にも、こう考えるメンバーがいました。エンジニアチームに、私が説明した内容は次のとおりです。
１）テストを作る＝そのストーリーの全てのケースを事前に洗い出す＝設計
プログラマの設計力を磨くためにもやるべき
２）テストケースを事前に洗い出すことにより、Ｐ.Ｏ.と当初足らないケースの対処を提案・会話し、P.O.レビューでの手戻りをなくす（工数削減）
3)P.O.レビューでは、顧客価値について、重点的に話合うべきで、コード化されるものは、本来は範疇外（顧客価値の向上）
4）QC担当者の本来の役割
QC担当が本来やるべき事は、言語化されてない、非言語な要件のテストをするべき
例）全体的なフローとして最適化されてない箇所を見つける、ユーザビリティやＵＸのテストをする
ソフトウェアのプロダクトは、P.O.とコードを書くエンジニアが協創して作っていく物。エンジニア自らがそのストーリーに必要な事を設計し、テストを考え、P.O.と会話するために、テストコードをエンジニが書く必要があると考えます。
まとめ
・工業製品とは異なり、ソフトウェアは継続的に修正していくもの、工業製品と同じやり方ではいかない
・ソフトウェアのコストは、修正に多大なコストがかかる、修正へのコスト低減のためにも、リファクタリングが必要で、リファクタリングするためには、テストコードが必要
・ソフトウェアのプロダクトは、コードを書くエンジニアとP.O.が協創して作っていくもの、P.O.との会話を増やすためにも、テストコードは生産するプログラマが書くべき