先日このような勉強会を主催しました。
勉強会の中で、Webサービスを主に業務として扱っているエンジニアの方々に架空のケースを見せたところ「イメージと違う」「この体制は縦割りすぎるし、小規模なチーム開発に適さない」などと様々なご意見をいただきました。
今回主催者としてはもう少しケーススタディを練った方が良かったという反省はあるのですが
それにしてもだいぶ大きなギャップを感じる機会となったので、これはこれで大きな学びとなりました。（使ったケーススタディは公開しません）
QAとは
何より大きかったのは、QAとはという議論です。
僕のこれまでのエンジニア人生におけるQAの定義は
- 品質を保証する
- 何かプロダクトに関して不都合なことが起きたらQAが全責任を負う
- そのQAがプロジェクトにいることで、バグが0件になる。プロダクトの価値も上がる。が理想。
だとずっと思ってきました。
多分組織文化のようなものもあるのですが、品質を保証するのがQAの仕事だしそれができないのならQAがいる意味がない、と思っていました。
しかし、その時の参加者のエンジニアの方々の意見は全く異なるものでした。
- そもそも品質を保証なんてできるの？
- 品質保証っていう呼び方がそもそも合わなくなってきてる。
- 至るところにつながってシステム化している世の中で全範囲を保証するのは物理的に不可能。
みたいな話をたくさんいただきました。
正直言うとこの時点でだいぶ思考がストップしてしまいました。
どうやったら品質を保証できるのか？というのを一生かけて追いかけていかないといけないとずっと思っていましたから、
そもそも保証なんかできない、それをめざすのは間違っているのかと思うと、なんというか頭が真っ白になってしまいました。
QAという存在に対する揺らぎ
そもそも、品質を保証するという立場はいわば、開発されたプロダクトを疑っている、ひいては開発をしたエンジニアを疑っているわけです。「本当にバグ、ないよね？」と。
でもこのスタンスは、一歩間違えば開発者へのリスペクトをなくしてしまう危険性もあるのではないかと思いました。
例えば「どんな開発をしていても、QAがいれば品質が保証できた状態でリリースができる」というのを目標にしたとしましょう。
これは確かに一つの理想かもしれませんが、仮にそうなったら開発で行っている努力はまるで見えませんよね。QAがいるなら誰が開発したって一緒、となるわけです。開発する立場の人にこのような話をするのは、なんだかとてもおこがましい気がします。
そもそも、これからのQAは検査とか保証をするとかそういうスタンスからどんどん脱却すべきで、どれだけチームで協調してモノづくりができるか、それをどれだけ効果的にサポートできるかというところに関わっていくべきなのではないかと思いました。
ソフトウェア品質保証の限界
今の時代、どんどんとあらゆるものが繋がっていく世界になっていくし、自分たちが作っていないものが起因して発生したバグですらも事前に予知したり検知するというのは、非常に難しいです。
QAが何でも知っていなくてはならない。理想的にはそうあるべきかもしれませんが、はたして現実的でしょうか。
実際、私もQAとしての責務をずっと感じて業務にあたってきましたが、限界を感じる部分も多々ありました。
もちろんレビューやテスト設計をきちんとやるなど、努力や勉強でなんとかなる部分も大いにあるでしょう。それを怠るのは違うと思います。
でも、QAが全部の責任を負うというのも、開発は責任を負わなくていいのか、という話にもなりますし、そもそもチームの全員が責任を負うべきでは？と思ったりもします。
そもそも前提となるエンジニア像が違う説
そもそも、QAにどのような役割が求められるかは開発のエンジニアがどんな状況にあるかで全く異なるわけですね。
会社に私くらいのポンコツエンジニアしかいないんだったら、QAにおんぶに抱っこな体制になるのかもしれませんが、開発エンジニアだけである程度自走していける組織なのであれば過度な介入は不要ですし、かえって迷惑になります。
特に自社でWebサービスを作っているところは、プロダクトへの愛着だって強いだろうし環境も違うのかもなと思いました。（別にSIを揶揄しているわけじゃないです）
大規模開発と小規模のチーム開発のギャップ
引き続きギャップを感じたのが、そもそものチーム規模です。
大規模の開発ではスピードもゆっくりになりますし、小規模では逆にスピーディになります。
それで同じQAのやり方をしていたのでは、現場の実情と合わないし、むしろ逆に足を引っ張ることになってしまいます。
私の場合、大規模開発のプロジェクトも参画したことがありましたから、その時の感覚が残っている部分もある気がします。でも、当然小規模で開発を回していくのであれば、そのカルチャーに合った動き方を覚えなければいけません。
個人的な好みでは、小規模なチームの方が自分がチームに貢献しているかが見えやすくなるのでやる気は出やすいです。でも結局好みだろうとは思います。
大規模な開発もまだまだ残り続けると思うので、どこに行きたいか、その目指す場所では何が求められているのかをウォッチしながら勉強していくといいのかなと思いました。
まとめ
とりとめのない話になってしまったので、まとめを書いておきます。
- QAの定義は人それぞれ全然違う
- 小さなサイクルでカイゼンを回していく今どきの開発と、昔ながらの大規模開発では求められるQAの役割も全く異なる
- テストの絶対解もなければ、QAの絶対解もない
- QAに限らず、良いモノを作って世の中に出そう！という意識はとても大事
参加された皆様ありがとうございました。
