mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

QAから開発に移って1年が経ったので感想を書こうと思う

QAの部署から開発の部署に移ってから1年が経った。

感情の赴くままにその感想を書いていこうと思う。

 

QAでの経験を活かすのは普通にできなかった

QAでの経験を活かして高品質なアプリケーションを開発します!」と昔の自分は息巻いていた。

しかしそれはとても難しかった。というか、今もできていない。

そもそもQAできてなかった

どうして昔はQAができていたと過信していたのだろうか?

僕は新卒で入社してから6年近くQAをやっていたが、実際はQAの真似事をしているだけで、「ただの設計書の誤字脱字チェック」であったり、品質分析とは名ばかりの「バグを分類ごとに数えてそれっぽい良いカンジの報告書を作ること」であったりテスト設計と言いながら実際は「その場の思いつきのテストケースとそれっぽいテスト計画書作成」とかをやっていた。本当は品質を保証なんかできていなかったし、品質向上もできてなかった。

QAの時は、ただ誰でもできるけどやらないっていうことをひたすらやっていただけだったんだなとよくわかった。

お前より余程おれの方が品質保証を勉強してるよ

開発の部署に移ってから、とある先輩に言われた言葉です。めちゃくちゃ悔しくて「そんなわけない」「SQuBOKをおれは2回全章を音読したんだぞ」「29119とか知っているのか」「この前までISO9126までしかないと思っていたくせに」などと色々な思いが走馬灯のようにグルグルと頭を駆け巡ったが

実際先輩の言う通りであった。

というのも、(色々な方法論を築き上げてきた諸先輩方を貶す意図は一切ないのだけれど、あえて言うと)方法論や知識を知っていること自体に価値はないのである。

言うなれば自分は教科書の解答を丸暗記しているに過ぎなかった。品質向上の施策には静的解析やレビュー、またレビューの方法にもいくつか種類があり使い分けが必要である、テスト設計の際はラルフチャートであったり論理的機能構造のようなモデルを使うことでモデルベースの観点を発想することができるようになる、その際の注意すべきことは…などなど

実際僕はそれなりに勉強してきたし、JaSST東北実行委員会という良い意味で頭のおかしい人たちの中でたくさん手を動かして勉強もしてきた。(今度本が出るので買ってください)

でも結局、この練習帳でも書いていることだけどテスト技法は使ってなんぼなのである。ただ知っているだけでは何の役にも立たない。

僕の先輩はおそらく29119の規格があることなんて知らないと思うけど、実際その先輩が来てからグダグダだった進捗会議は会議のていを成すようになったし、その先輩が作った進捗表はとても見やすく遅れが一目見ただけでわかった。

小難しい技法を勉強することが、直接的に実際の品質改善につながるわけではない。

もちろん勉強も大事なのだろうし、実際役に立つ場面だって探せばあるのだけども

実際の現場で役に立つのは、大体が「進捗表を見やすく改善する」だとか「グダグダな会議のアジェンダを立てて会議として成立させる」とか、「放置されている懸案を拾ってきて議題として提起する」というような、一見地味だけど大切なことたちなのである。

僕は多分勉強して満足していた。知識を得たことで満足感を得てしまっていたように思う。でもそれは間違いだし、技法や方法論を築いてきた人たちだってそんなことはきっと望んでいないだろう。

地に足をつけた、地道なカイゼンが現場の開発をラクにしていくのである。僕は1年間かけてこのことを学んだ。

これからのことについて

開発の部署に移る前からわかっていたことではあったけど、正直全然スキル的についていけていない。もう自分はエンジニアとして7年目になるが、開発3年目のエンジニアにスキル的にも劣ると思うし、少なくとも7年目のエンジニアに求められるスキル基準には達していないと思う。

前回自分が転職に挑んだ時に失敗した理由というのは、実際に手を動かして学んでいないというところだったわけだが

実際それが一番大事だと思う。こんなことを書くとまた叩かれそうだけど、実際僕がプライベートで勉強しているアプリ開発ってマジで全然進んでいない。

 

QAから開発に移ったこと自体はとても大正解だったと思う。(QAにもまともな人たちはたくさんいるけど、)少なくとも僕はぬるま湯に浸かっていたし、誰にでもできるような仕事をしてなんとなく品質を保証している気になっていた。なぜか上長の評価も高かった。それが開発に移ってきて、良くも悪くも正当な評価を受けられるようになった。

 

正直な話、僕はテストと開発を天秤にかけたら開発の方が好きで、異動した理由もただそれだけなのである。コーディングしてる時は結構面白くて、この面白さはやっぱり開発の醍醐味だなと感じるけど、開発に情熱があるのかと聞かれたら、正直全然ない。

 

これまで散々悩んできたけど、僕の結論としては「四六時中開発のことを考えてたい」と思う人が開発エンジニアになるべきだし、「四六時中テストのことを考えてたい」と思う人がテストエンジニアになるべきだ。これに該当しない人は正直別の仕事でいいと思う。(個人の見解です)

僕がソフトウェアテストやソフトウェア開発を学び始めたのっていわゆる危機感ドリブンであったり劣等感ドリブン承認欲求ドリブンだったわけだけど、これらはすぐに息切れするし続かない(個人の感想です)。

結局、最後まで生き残るのは放っておいても勝手に勉強する人たちなのである。

そうは言っても…ね

そうは言っても、このまま今の仕事を辞めるのではこの1年何をしていたんだという感じだし、まだ全然ソフトウェアエンジニアリングをわかっていない。

全然わかってない上でいうのだけど、ソフトウェアエンジニアリングの世界って、ただ技法を知っててツールを使えるとかコードを書けるとかの話だけじゃない。

エンジニアリングをキチンとやっていくためには、計画を立てたり設計をしなくてはいけない。僕は特に、この設計を行うあたりがさっぱり理解できてないんだろうと思う。

 

多分これはどんな仕事でもそうなんだろうけど、行き当たりばったりで仕事をすると大抵うまくいかない。楽観的な予測だけにしたがって行動していると、予期しないトラブルに見舞われてこれまでの仕事がおじゃんになったりするし、大きな手戻りになって残業になる。

例えばソフトウェア開発でいえば、データ構造を考える時は「このデータって誰にどんな使われ方するんだろう」とかを結構初期に考えておかないといけない。そんな要件や仕様はまだ全然決まってなかったりするんだけど、これを前もって考えておかないと実際開発していく中で「なんでこんな不便な作りになってんだろう」ってなる。そしてその段階に来ると結構作り直すのがしんどい。

 

つまるところ、本当にお恥ずかしい話だけど今まで頭を使って仕事してこなかったんだと思う。「何したらいいですか」「何勉強しておいたらいいですか」って聞いて、その通りにしてたら仕事できてた(気になってた)。普段の仕事から頭使って考えてる人は別に家帰ってわざわざ勉強しなくたって勝手に成長していくんだと思う。

頭を使わないというのは本当にラクだ。ラクだから依存性がある。言われたことだけやってればいいというのは希望もないけど絶望もない。

でも、世の中というのは大抵頭を使わない人が搾取されまくる。何度も手戻りしたり生産性が悪くなって「なんで自分がこんな目に」とか思って鬱になっていくのだ。実際にそうやって辞めていく人を見たことがあるが他人事ではない。

もう少し頑張ろうと思う

仕事ができないというのは辛い。

色々な言動が自分を責めているように感じる。

自分じゃない人が雇われていた方が、みんな幸せなんだろうな」とか本気で考えることがよくある。別に病んでいるわけでもないけど、本当にそう思うことがよくある。

昨日先輩が飲みの場で「仕事で成果を出せないヤツが、筋トレにハマること多いらしいんすよ。これなら成果出せるんだ!って思えるみたいで」ということを言っていて、本当に辛くてなぜか涙が出そうになった。別に自分に言われたわけでは全然ないんだけど、そういういろんな言葉が自分を攻撃しているように思えることがある。

 

まあ、でも大変なことはあっても今の自分は環境的にとても恵まれている。

転職しますと言った挙句「うまくいきませんでした」と言って帰ってきて、大した実績もないのに開発の部署に移らせてくれて、希望していたWebアプリの開発もさせてもらえて。

恵まれていることは確かである。辛いものは辛いけれども。

 

ということで、まあ、もう少しがんばってみようと思う。1年後、またこうして日記を書けたらと思う。その時には、もう少しソフトウェアエンジニアリングのことをわかっていたい。