bon now

僕はもともと、テストというか、製品品質に命をかける職人気質の企業文化の元で指導を受けてきた。 そんなことだから、当たり前のようにテスト項目やエビデンスを作りまくっては撮りまくっていた。 明らかに不当な部分もあったかもしれないけど、それでもある程度の品質指標をもとに様々なプロジェクトが回っていたので、 どんどんナレッジは蓄積されていくし、そこからプロジェクトの特性別に指標をちょっといじるみたいな、そういう応用も効くっぽい感じだった。多分。 社内SNSでは結構議論の的になっていたんだけど、今、その会社から離れてベンチャー企業で働く身となって考えると、ちゃんと意味があったなって思う。

実際、テストケースのまとめかたも評価の方法も3年目まではほとんどのSEができるし、 ある程度の品質は先の通り指標に沿ってさえいれば余計に突っ込まれることもない。 エビデンスをExcelにまとめるのはどうかと思うが、それもまぁ「仕事した感」を出すのには十分だ。

前の会社は創業当時からずっと今まで、長い時間をかけて品質保証の重要性を組織の文化として根付かせてきた。 途中誇大広告やら事件やらやらかした時期もあっただろうけど、まぁ現代まで生き延びた大手企業ということでそれだけでも価値はあったわけだ。

僕の現職では、まあまあテストに対するエンジニア界隈の意識が低い。 SEから転職した側からするととても天国だなと思う部分もあるけど、結局そのせいでメンテしにくいコードができたり、 触れたら爆発するコードを埋め込んだり、果ては単体テストの結果を頭の中だけでやって、あとは結合テスト担当に丸投げするみたいなことも起きる。 スピード？という名のまやかしに踊らされ続け、技術？という名の幻想を武器に戦い続けてきた結果である。

僕が今一番どうすればいいかと思っている部分は、設計とテスト、そしてプルリクエストとテストの関連性だ。

最初の1つの設計とテストは、V字モデルと言われている通り、基本設計に対応するのは結合テストとか総合テストだ。 アジャイルでも「設計をするなとは言っていない」という注意があるように、設計そのものは工程からなくなることはあまりない。 その設計をなんのためにやるのかをちゃんとエンジニアが意識し、さらに品質保証する立場の人間が、その設計から何をどう学ぶかを考えなければならない。 まぁこのあたりはSEを経験した大体のエンジニアは理解できるだろうから、そんなに意識付けに時間はかからないと思う。

問題は「プルリクエストとテスト」の関連性である。

SEしているとあんまりプルリクという文化を経験していないことが多い。 逆にベンチャーや技術先行のエンジニアリング企業においては、当たり前のようにプルリクがコーディングの文化の1つとして存在しているはずだ。 レビューをすること自体はそれを「やる」だけなので文化なんてのは熟成する間もなく決めた段階で文化になるようなものだ。（レビュー精度そのものは別として） ただし、そこに「テスト」が入るとそう簡単に行かない。 テストとは手法・仕組みである。テストそのものが素敵な解決策になるわけではない。 テストをすることで不具合を摘出し、コードの毒を抜いていくことで、徐々に製品そのものの品質が良くなっていくのである。 なので、単純に「テストちゃんとやるでぇ」では、その文化はそう簡単に熟成しない。 梅酒は1年そこらでそこそこの味が出るけど、テスト文化はその程度では素人に毛が生えたくらいの結果しか得られない。 だから、そこで「全然テストした意味がないじゃん」っていう結論がでてきて「新しい方法を探せ」だの「もうやめよう」みたいな風潮が出てくる。 エンジニアそれぞれの意識がそこで分断される。分断された意識では、正しい方向に組織は歩んでいけない。

まとめ

テストに対する指標や考え方の一貫性は重要だ。僕の経験からも、そして現状からもそれは確かだ。 もし、これを読んでいるどこかの誰かの所属する組織がテストに対してバラバラの価値観、意識の場合は注意が必要だ。 このとき誰かが継続的にテストに対する一貫した対応を取り続け、結果が出なくともフィードバックをもとに改善し続けることが重要だ。 その誰かを祭り上げるのか自分が名乗り出るのかはともかく、もし、その動きが組織にないようであれば、 僕個人としては無駄に頑張るよりも、気づけた人間からプリズンブレイクすることをおすすめしたい。 5年を棒に振るか、会社のために尽力してテスト文化を熟成した実績を得るか、そのへんはしっかり見極めていこう。