はじめに
最近社会人4年目になりました。品質保証エンジニアのキャリアの中で、自分を俯瞰して考えるようになったと思います。
そこで、自分の中での答えが最近出た気がするので記事にすることにしました。
あくまで自分自身の話ではあるので、これがいいとか、悪いとかはないとは思います。こういうマインドもあるんだな程度に閲覧いただけるといいのかなと思います。
入社時
入社時みなさんは何を考えていたでしょうか。何か高度の技術を触れることに期待してドキドキしたり、新しい生活に対してワクワクしていたかもしれません。
この時点では、エンジニアという職業に対しての解像度はまだまだ低く、会社を取り巻くさまざまな状況、技術力など、まだまだ見えていない部分があり、不安がありました。しかし必ず面談、面接などでは5年、10年後にはどうしたいのか、何をやりたいのかは必ず聞かれます。
今までの経歴
私は最初の1年半バックエンドエンジニアとして実装していました。
そこで実際の開発現場について知ることになります。
現場はみんなが意見を出し合いワークフローに基づいてバリバリ開発するのとはかけ離れていました。
そこで上司から言われた言葉があります。
「お前はこの先何がしたいのか良くわからない」
そこで仕事のやりがいとは何か、システム開発とはなんなのかを考えるきっかけができました。
「あなたは何をしたいのか」という質問に対して、昔の自分と今の自分は何と答えるでしょうか。
昔の自分が答えていたのは「わからない」でした。
とにかくわかりません。 ドキュメントの場所、仕様、運用、使う技術、仕事をする上でのマインド全て。
この時の自分は実装があまりできず、意見もあまりできなくて辛い時期でした。
優しくて優秀な同期にいつも助けられていた記憶があります。
問いに対して答えを出せずにいました。
同時にこれは自分のエンジニアのキャリアを考えるきっかけになります。
自分がやりたい仕事
私はバックエンド開発から逃げる形で2年目から品質保証チームに配属されました。
当時品質保証とはなんなのか全く理解できていませんでした。
そもそもテスト設計もやったこともありません。
そこでうまくやっていけるかも分かりませんでした。
しかしDBの運用が当時滅茶苦茶だったのは知っていたので、これを改善したいと思いました。
そこで同期と一緒にDBマイグレーションツールとER図の導入を始めました。当時はあまり気にしていませんでしたが、これも品質保証としての仕事の一部だったのかもしれません。
これが開発側に対して大きなインパクトを与え、最適化や仕組み化でシステム開発へ影響を与えました。
そこで気づいたことがあります。これが自分がやりたい仕事だと。
つまり自分の中で、運用最適化による生産性の向上によってQA、Developperから、ステークホルダ、顧客全体がストレスなく、楽しく、やりがいができるような、そんな仕組みを作りたいという考えになりました。
今この先何をしたいかと聞かれたら、これを答えると思います。
そこでいろんな開発における障壁に考えを向け、ナレッジ共有ツールの導入や問題提起を行いました。
開発における視座がかなり高まったと感じています。
品質の壁
品質は顧客に対してダイレクトに影響を与える部分です。
当時開発していたものは画面を触ってみてもあまり気持ちの良いものではありませんでした。
品質保証に半年ほどいた後、後輩から言われた言葉があります。
仕様書なしでどうやってテストするんですか？
たしかに・
当時、会社の品質保証としての背景やフローに関してあまり疑っていませんでした。
そこにはただ、「品質が悪い」という事実がありました。
ここで、人を巻き込んで品質とはなにかに関して考えることになります。
TEST SKILL
品質を語る上での構成要素というのは非常に多いです。
個人的にしっくり来ているのはテスト担当者におけるスキルスペースの話です。
スキルの構成要素
-
テストスキル：テストを作成する上でのスキル。テスト分析やそれに対するテスト技法を選択してテスト設計、モニタリングする技術
-
ソフトスキル：仕事をする際におけるコミュニケーションスキル等
-
ITスキル:開発におけるスキル
-
ドメインナレッジ:製品のドメインに関する知識
テスト担当者は、これらに関してバランスよく学ぶ必要があると理解し、これに対して今の組織にはテストスキルが圧倒的に足りないという結論になりました。
現在ではこれを埋めるため、QA勉強会を社内で開催したり、外部の勉強会に参加したりしています。
実装をする
QAには実際に開発しているコードを見る、実装する機会も是非与えて欲しいなと思います。
それにはいくつか理由があります。
- 流入する前にバグを防ぐきっかけをつくることができる
- 調査スキルが上がるので、出てきた問題に対して対処できるようになる
- アーキテクチャ理解が進む
- ITスキルがあがる
- 単体試験や結合試験について考えるきっかけにつながる。
これは実体験ですが、QAも実装を行うことで自分の開発におけるスキル、開発における視座を高めることができます。
ただし、過度な職能の入れ替えはアンチパターンだと個人的に思っています。
（短期間でQAもバックエンドもフロントエンドもさせる等）
あくまでQAの立場として実装にはいってみて改善点を探していく。という感じです
こちらは絶賛取組中です。
自分たちが置かれている状況を理解する
上記でテストスキルの話を書いたと思いますが、これをもとに自分達が置かれている状況を理解するために、開発やQAのライフサイクルを記述してみることをお勧めします。
自分は下記の資料をもとに、現在の品質保証のライフサイクルを見直し、できていないところには赤で印をつけたりしていました。
これはPFD（プロセスフローダイアグラム）で書かれていますが、自分達で理解できればどのような図でも良いと思います。
線の間に現場の運用で問題があるところには印をつけ、話し合います。
これによって、今自分達が置かれている状況と、QA活動にはなにが必要なのか？についての議論を始めることにつながります。
推進力を高めるために
ここまでつらつらと書いてきましたが、気づいたことがあります。
理想ドリブンQA（開発） を推進するって本当に難しい。
各々でQAに関する考え方は結構違いますが、理想とするQAに持っていくための施策をするための体力を削りながら本来ある業務を行うので正直滅茶苦茶しんどいです。実際に施策をするための時間が取れないことも多いと思います。
これに対する答えですが、すぐやれです。
推進し続けて改善するには下記が必要だと思っています。
- 品質に対する熱量
- スピード感
- 寄り添う心
- 自分からやる心
幸運なことに品質に対する熱量をもった後輩がいます。
それに対して先輩としてできることは寄り添う心と率先してやること、だと思っています。
（体を壊さない程度に）
最後に
品質とはなにか？ に対しての質問に対して、何と答えるでしょうか。
その答えはみなさんがそれぞれ持っていると思います。
画面を触った時に操作性が悪ければ品質が悪い、になりますし
開発者が開発しにくい環境というのも品質が悪い、ということになるんだと思っています。
つまり、品質保証のみが品質という枠組みとして考えるのではなく、全てにおける役割で改善活動を行うことで結果的に品質を高めることができた、ということになるんだと思います。
みなさんの品質に幸あれ