■テストと品質管理に関する致命的な誤認識

「品質管理が僕たちの責務です」

って、最近エンジニアリング界のライザップ的元テスト専門会社のQAエンジニアが、昔、言ってたなぁ……、と。

思い上がるなっ！

君たち如きに背負えるものでは、すでにない。

とあえて言おう。

それほどまでに、最近のサービスは、でかく複雑になりすぎた。

いや、マジで、無理なんよ、もう。

例えば、キッチキチにエレベータを作り込んだとして、後から点検してくれ、と言われたら、まぁ、普通は困るよな。

モーター室がモーターが入るギリギリの広さだとしたら、箱の外に出る手段がなったら。

どうやって点検するんだよ。

外から目視か？

実際には、設計時に点検方法を決定して、それができる余地を確保してから、施工するものだろう。

今時のEV車なんて、テスト用の仕組みがきっちりと、製品に組み込まれている。

品質管理の仕組みって、そもそもそういうもんだろ？

DDDで設計してます。

マイクロサービスで分割してます。

の前に、システムは「検証可能性」を検討するもんです。

検証不可能とまで言わなくても、検証困難な場合はちゃんと対策をとるもんです。

作りきってから、「E2Eテストお願いねー」とQAチームに投げるものじゃあないんですよ。

設計時に、テスト戦略から何から何まで検討済みになってるもんなんです。

そしてそれが「テスト駆動開発」のキモなんですわ。

別にユニットテスト書いて、カバレッジあげるのがTDDというわけではない。

検証可能なシステムを設計実装し、リリースのたびにシステムの健全性を検証できる仕組みを整える。

ってのが「テスト駆動開発」なんですわ。

テスト戦略をちゃんと練れば、マイクロサービスの分割の仕方、連携の仕方等々、多分、今、Web上でよく見る記事とはだいぶ様相が異なってくるはずだ。

で、プロダクトの中身である、設計や実装を理解できなければ、検証のしようがないのがここ10年ほどだ。

金槌を渡されて、「品質検査しろ」と言われたら、まだ何とかなるだろう。

けどボーイング787をポンと渡されて、「品質検査しろ」と言われたら？

マニュアルなしで。

モジュールがどう組み合わされてるか等、中身を理解できなければ、何をどうしていいかも分からんだろう？

扉の開け閉めができるとか、主電源入れたらなんか部屋の明かりがつくとか、そういう表面的な検査しかできないだろ？

これは、QAが、設計に飲み込まれることを意味する(10年以上前に、↑のQAエンジニアとした話)。

QAのテストに関する知見を、設計実装するエンジニアは当然持っておかなければならないということとともに、QAエンジニアは消えてなくなるということでもある。

お分かりだろうか？

同じ流れで、SREも不要になる。

そのためのクラウド、DevOpsの概念だからだ。

Infrastructure as Code は設計実装エンジニアのためのものだと言っておこう。

決して、Terraformのファイルを編集して、SREの許可を、延々と待ち続けて、適応してもらうことをいうわけではない。

そこまで込みで、設計するのだ。

高負荷時にどうスケールさせるかなども、当然設計に入ってくるからな。

ってなわけで、ほとんどの現場では、そういう致命的な誤認識をしていると思う。

認識が古すぎている上に、大型化複雑化した現状を認識できていない。

開発初期はまだ規模が膨らんでいないから、何とかなりそうな勘違いを犯しているだけの話だ。

初回リリース前後で、「あ、やばい……」となっているところがあまりに多すぎる。

また、この誤認識によって、役に立たないエンジニアの頭数だけを並べて札束を燃やし、事業の拡大の足を引っ張っていると指摘しておこう。

本当に、そういう現場が少なく見積もって8割あるとみている。

ここら、どげんかせにゃならんのよな。

Permalink | 記事への反応(6) | 09:03

ツイートシェア