開発部の新人がQAをやってみた
walk with conflict「品質への葛藤」
おはこんばんにちは。MotionBoard開発部第2Gの武島です。
ついこの前、QAとして仕事をさせていただだきました。「開発者のテストって大事だよね」で片付けるにはあまりにも勿体ない経験でしたのでここに書き起こします。
「僕らが開発しているMotionBoardの品質って、どうしたら自分たちの手で守ることができるのだろうか」と深く考えるきっかけになりました。今回のブログはその葛藤が現れている気がします。
あらすじ
僕は開発部の人間ですが、毎年(MotionBoard開発部の)新人はQA部隊としてリリース間際の検証作業をお手伝いするのが恒例行事になっているようです。出稼ぎ期間はおよそ２ヶ月でした。その期間で実施した検証内容です。
- モバイル版マニュアルに沿ってテスト
- ブラウザ版マニュアルに沿ってテスト
- 仕様も実装も曖昧な新機能部分のテスト
- マイグレーションテスト
- リグレッションテスト
- インストーラテスト
自分の想像を超えたボリュームでしたが、同じ出稼ぎ仲間の同期や他部署の同期とほぼ常時通話(リモートワーク前提)で進めました。正直、精神的にきつい作業もありまして、雑談や愚痴を言い合いながらフラストレーションを緩和できた同期との関係性に感謝しかないです。
複数人と同じ空間(リモートですが)で検証作業するのは割と健全な考えだと思っています。（この伊藤さんの記事を参考にしました）
得られたもの
開発者の立場から離れ検証する仕事に携わったことで、多くのものを得られました。
元々開発者でありながら、製品そのものに対する知識がなかったのですが、検証作業を通して嫌でも製品理解の底上げが成されました。また、開発者が実装した後の工程でどんな人がどういう感情で何をやっているのかも知ることができました。
他にも色々な点が挙げられますが、ここからは特によかったものを紹介します。きっと僕のエンジニア人生を長く支えてくれる気付きや学びです。
開発段階でバグを防ぐ努力
開発段階での努力が一番効果的でステークホルダー全員を幸せにします。
この原理は入社後の研修があったので知ってはいましたが、今回検証する側の立場から開発側を見ていると、改めて思い知らされる機会が多かったです。開発者の仕事の質ってこの原理が全てなのかもしれません。
テスト容易性
マイグレーションテストとリグレッションテストをやっている時に、この特性の本質に気付きました。検証作業の中でも、特にこの2つのテストは単調な作業を延々と繰り返す精神ダメージが大きかったです。
ソフトウェア本体がこのようなテストの自動化を考慮した設計が成されていないのが根本の問題です。
テスト容易性が低いということは、よりクリエイティブで鋭利な検証に人間のリソースを割くことが難しいということです。逆に、テスト容易性が高いと、安く早く効果的に品質を検証できるので、よりビジネスに直結する仕事に人間が集中できます。つまり、テスト容易性がソフトウェアの本体の品質であると言えます。
意図のある開発プロセス
この体験を通して、いくつか品質面の課題が見えてきましたが、よくよく考えてみたら、「僕たち開発部は〜〜という目的で〜〜というプロセスで開発してます。」って言語化できないなぁって気付きました。
目的が分からないとその妥当性が評価できないのは当然です。
まず正しいかどうかは置いておいて、自分たちなりに考えた目的や意図を明確にして、そこにトライする。そのあと振り返ってまたトライする。このサイクルをチーム全体で自覚してやっていかないと、属人的な開発と品質しか残らないのではと想像しています。
自分たちの品質がなぜ良いのか、なぜ悪いのかを認識できなければ、そこから逆算してコントロールするのは不可能です。
おわりに
理想と現実
たくさんの気付きや学びがありましたが、そこには理想と現実があると思います。開発側もわかってはいるのですが、なかなか実現するのは難しい事ばかりです。確かにソフトウェア工学やQuality Assuranceの分野では、偉大な先人たちによって築き上げられた体系理論がありますが、その理論を実際の現場で落とし込むには、現場とソフトウェアを理解した上で、最適な形で植え付け定着させる離れ業が必要です。
そんなカリスマ指導者的な存在ってこの業界に何人いるのでしょうか笑
これから
開発者として品質というワードを深く考えて葛藤することができました。
この自問自答はこの業界にいる限り一生続きそうです。今回の出稼ぎ体験で得た最も大きなものは、この葛藤と共に生きていくんだという覚悟でしょうか。
