私はもともとソフトウェアQAの出身ですが、今は開発をメインにやっています。
「QAやってた人が開発やったら、品質の高いコードが出来上がるのでは？」って思うじゃないですか。
そうならなかった話を書きます。
私の経歴
- 7年くらいデジカメのソフトウェアQAをやってた。
- 6年くらいWebのQAをやってた。
- 2年くらいWeb開発・保守運用をやってる。
背景
- 1週間沖縄オフィスに行って業務を効率化してくるミッションをもらう(普段は東京オフィスに勤務)
- 具体的には「あるツールを使った操作を自動化」する(ことで作業効率を上げる)
私としては1週間も「それだけに時間を使っていい」枠をもらえたし、やってやるぜ感だった。(普段は同時に複数プロダクトを運用しており、1つのことに集中できる機会があまりない)
沖縄入りして現場のメンバーから状況をヒアリング・観察してみると操作が複雑で自動化(SeleniumWebDriverを想定してた)は厳しいなって思った。
よくよく考えるとやりたいことは「操作ログを記録する」(ニュアンスちょっと違うけどこの表現だとわかりやすいかと思う)だったので別アプローチを取ることにする。
開発に着手するが、結果としていろいろ見逃してて遠回りした。
「できたぜ！」って臨んだ出張最終日のデモ中に不具合が見つかって凹んで東京に帰ってくるという一週間を過ごしました。
※ココでは「やってることが高度かどうか」は別問題として進めます。
ここで帰りの飛行機の中で思ったことを書きます。
開発脳とQA脳は違う
「脳」というか、スタンス？考え方？思考の方向性？なのかもしれません。
私はQAをやってた時間のほうが長いので、先にQAのことを書きます。
前提として、私がやっていたQAは「開発したものを別な人が動かして動作確認する」みたいなやつです。
QAとして私がある機能をテストするという場合には、仕様書にあるなしかかわらず「どんなことができるのか」を考えます。ここでいう「できること」というのは、「ボタンを押してメールを送信できる」機能だった場合、「メールを送信できる」ということだけではなく「その周囲にあるパターン、条件」みたいなものになります。例えば「下書き」にチェックが入っていたら「送信されちゃダメ」みたいな条件があるとか、実は送信できるボタンが複数箇所あって両者で送信される条件が違う、みたいな。
その上でそのテスト対象と向き合うときに
- どうやっていろんなパターンを試してやろうか。(洗い出してやろうか、の気持ちのほうが強いか)
- どうやって不具合を見つけてやろうか。
- どうやって開発の想定漏れをみつけてやろうかぐふふ。
みたいな気持ちになります。
これは前提として「動くものがある」からスタートしてるので、それより「外側」を見て思考してる気がします。
一方、開発するときの脳はというと。
エンジニアはゼロからものを作れます。そして「必要最低限」のところから作ります。(いきなりエッジケースの実装はしない) 上記例で言えば、まずは「ボタンが押されたらメールが送信されること」を満たしに行きます。その時、そこにどんな条件があるかは(設計時に関係するけど)置いておいて、まずはこれを満たします。
それを少しずつを積み上げていって、0だったものを1にして、10にして、100にしていきます。
仮に「開発者である私が思っているゴール」を100とします。このときの100が、QAをやってる私のゴールと違うんです。多分QAは250くらいを見てるイメージ。QAのほうが自由に広く発想している気がします。
なぜこれを一人でできないのか？
(完全に私の印象なので、もっとレベルの高いエンジニアは違うと思うし、むしろ違っていてほしい)
元QAとしてどんなパターンがあるのか洗い出していくのは得意なはずなのに、自分が作ってるものになると途端にその能力が落ちます。発想も気持ちも切り替えもうまくできない感じがします。
QAのときは「こいつは動かないかもしれない。動かないところを見つけてやる」ってマインドだけど、開発のときは「頼む動いてくれ。動くよね？大丈夫よね？」ってマインドになっています。視野が狭くなるというか。動いているものを壊したくない、壊れてほしくないという思いが強くなります。これによっていろんな動作パターンに発想が行かず「今動いてる」ことに執着し始めます。無意識に臆病になる感じ。。。
2年も開発やっててなぜ今それを思ったか
「1週間ずっと1つのことをやってていい時間」および「一人でやる」という機会があったからだと思います。普段は複数人で行動しているので「自分ひとりの責任で何かを作り切る」という経験があまりなかったため、いつもとは違うことも考えられたのかなと。(あと、沖縄という場所に行って何かが解放されたのかもしれませんけどｗ）
これを書きながら思ったこと
私のエンジニアとしてのスキル・経験が低いことに起因することだとも思います。こと最近のアジャイルやスクラムではQA・テスト「専門」のメンバーがいないこともあって、その場合は開発者が自分でテストするわけで、そういう意味では上記の250のゴールを満たす実装ができるエンジニアが求められていると思うのです。
2,3年後には別の見方ができるようになっていたいと思います。