こんにちは。QAコンサルタントのヤスゴロウです。
私は15年ほど開発エンジニアを経験した後、QAエンジニアになり今年で16年目です。
現在は、QAコンサルタントの業務を担当しております。
開発エンジニアや開発プロジェクトマネージャー（以下「PM」という）からQAコンサルタントの職種に転職することを迷っている方がいらっしゃると耳にしましたので、お役に立てればと思い、熱く語らせていただきます！
なぜ私はQAエンジニアに転身したのか
きっかけ
はじめに、私がQAエンジニアになった経緯をお話させていただきます。私の場合は自分からQAエンジニアになることを希望したわけでなく、前職で「CMMI※1を用いたクオリティーマネージメントシステム（以下「QMS」という）の構築プロジェクト」に入ることを上司に薦められたことがきっかけでした。
私は業務システムやアプリケーションの仕組みを考えて自分の思惑通りの出来栄え(品質)に完成させることにやりがいを感じているシステムエンジニア（以下「SE」という）でしたので、あまりの新天地へのオファーに迷いました。しかし一方で、誰もやったことがないことを社内初でチャレンジして広めることも嫌いではなかったので引き受けることにしました。
実際やってみると、様々な学習が必要だったり、開発担当者をなかなか説得できなかったりなど苦労がありました。とはいえ、社内の有識者のお知恵を拝借したり、社外のCMMIコンサルタントの指導を受けたりして、なんとか皆で力を合わせて社内のQMSを構築することができました。
悟り
経験してみて悟ったことは「QAエンジニアがQMSを構築したりプロセスを改善したりすることは、開発エンジニアが業務システムを構築したり改善(保守開発)したりすることと大差がない」ということでした。プロダクトの品質を向上するための仕組み(システム)を考えたり、業務プロセスと同様に品質担保のためのプロセス(手順)を改善・効率化したりする仕事だと分かったら、段々面白くなってきました。システム構築や改善に興味があれば、誰でもできる仕事なのだと悟りました。
飛躍
その後、QMSは運用フェーズに入ったためQMS構築プロジェクトは解散し、気づいたら部門マネージャーと私だけの間接部門で運用・改善することになっていました。1人で多数のプロジェクトの品質を見るのは大変でしたが、更に独学を繰り返し、開発エンジニアの経験を活かして、ソフトウェアエンジニアリングプロセスの詳細まで踏み込み、要件定義プロセス、設計プロセス、テストプロセスの構築(標準化)をほぼ１人で成し遂げました。
出来上がってしまうと、あとはPDCAをまわしていくだけになってしまいました。それはそれでやりがいがありましたが、開発好きの私は運用だけでは物足りなくなってきました。
それから、社外のセミナーなどにも積極的に参加して有識者からも学ぶ機会があったとはいえ、所詮独学で自信がないところがありました。また、自信がないところがあるのに社内で一番の品質有識者のように扱われるようになってしまったため、もっと本物の有識者と一緒に働いて学んでみたい、自分がやってきたことが間違っていなかったかを確認したい(答え合わせをしたい)と強く思うようになりました。
いざ転身
このような経緯より、某開発会社の間接部門の「自称QAエンジニア」だった私は、独学で身につけたスキルを活かしてQAエンジニアの職を生業にして極めようと思い、AGESTのQAコンサルタント職へ転職しました。
そして入社後、上司の高木陽平さんと1on1をした際に、私のテストプロセス改善のアプローチは「かなりいい線いってたことが分かり大満足」でした。現在も多数の有識者や学習熱心な同僚達に囲まれて、希望通り楽しくお仕事をさせていただいております。
QAエンジニアの職務紹介・品質向上に貢献するアプローチの事例
では、ここからは私がQAエンジニアに転身してから経験したQAコンサルタントの職務と私が悟ってきたことをご紹介させていただきます。
開発プロジェクトにおいて、テストで不具合を見つけて解消することも必須ではありますが、テスト工程まで進捗してから修正することだけでは時間の制約など限界があります。
シフトレフト※2でテスト工程より前の上流工程から不具合を解消していくと手戻り感を削減することができます。
そのためのQAコンサルタントの職務の１つとして「開発プロセス改善」というお仕事があります。「開発プロセス改善」とは、簡単に言いますと「開発工程で不具合を混入しないような手順に変えたり、ルールを強化したりすることである」と私は解釈しております。（これだけではありませんが。）
私は、この「開発プロセス改善」において、開発経験や開発PM経験をかなり活用できております。
以下、「経験が役に立っているな！」と思う場面を「開発プロセス改善」の事例とあわせて２つご紹介させていただきます。
1.不具合の分析結果を用いて開発工程を改善するアプローチ
市場で発生した不具合、テスト工程で検出した不具合、レビューで検出した不具合(指摘事項)を分析して、混入した工程や原因となった問題を特定し、該当工程のプロセス定義（作業手順、ルール等）や成果物定義（標準文書テンプレート、記述ルール、サンプル等）などを改善するというアプローチです。
当然ながら手順やルール等を変えるためには、当事者である開発現場の皆さんとの合意形成が必要です。品質を向上するためには現状よりも重厚な手順（成果物の記述内容を増やす、レビューを必須にする、承認経路を増やすなど）を提案しなければならないことがよくあることなので、かなり開発現場の納得度の高い提案をしないと受け入れていただくことができません。
開発現場の納得度の高い提案をするためには、開発の知見があると有利であると実感しております。例えば、成果物にこういう記述項目を追加するとよいですよとか、そもそもフォーマットがないケースはフォーマットやサンプルを用意して使ってみませんかとか、自分の経験に基づいて相手が欲しい情報を提案しやすいです。
なによりも、開発担当者から「何故このようなことをやらなければいけないのか？」と問われた際は、自分が開発していた時の教訓等を思い出して例を挙げて説得することもできます。例えば、「なぜ要件ベースライン※3が必要なのか？」と問われた時、下流工程へ進む前にその時点の要件スコープを顧客と合意しておかないと、後工程で要件変更を受け入れざるを得ない状況に陥ってしまうことがある。また要件変更のために設計以降の工程で手戻りが発生してスケジュールを守れなくなったり、変更のタイミングによってはデグレード※4を発生させてしまったりすることがある、というようなことです。
あとは、開発経験があると開発担当者のツボにあわせた話がしやすいです。「この人開発者の気持ち分かってくれているなー」みたいな感じで反応が良くなったら改善を進めやすくなります。
困っている開発現場には、学術的な指導よりも今やるべきことを一緒に解決してくれるQAコンサルタントの方が喜ばれます。
2.世のベストプラクティスを用いて開発プロセスのギャップを改善するアプローチ
もう１つ別の開発プロセス改善のアプローチ方法による経験をご紹介いたします。
タイトルの「世のベストプラクティス」とは、例えばCMMIのような一般的な理想論（モデル等）と実際のプロジェクトや組織のプロセスを比較して、理想通りでない部分（弱み）を洗い出し、そのギャップを改善していくというアプローチです。
正直初めてCMMIのような学術的な書物を読んだ時には解釈が難しくてドン引きしましたが、読み進めているうちに自分の開発経験や開発PM経験に当て込んで解釈すると、なるほどと思えることが増えました。結局やりたいことは開発プロジェクトのプロセスやプロダクトの品質を向上することであって、そのために理想とする方法論等が書いてあるだけなのだと気づき、「なんだ、意外と難しくないぞ！」と思えるようになりました。
私はQAコンサルタント職に就いてからは、世の有識者が難しい言葉でいろいろ書いてくれている書物などを理解して即時に技術を使いこなせるスキル向上は必要であるとは感じておりますが、すぐに全部暗記までしていなくてよいと確信しております。どこにどのような情報があるか自分の頭の中に知識と経験のインデックスを徐々に作って引き出せるようになっていければよいと悟りました。
ですので、QAコンサルタントとしてやっていけるくらいの知識を身につけるためには、自分自身の開発経験や開発PM経験と結び付けて世のベストプラクティスを学び・解釈すれば、そんなにハードルが高いことではありません。開発プロジェクトの経験がある方なら未知の世界のことは１つも無いというのが私の感想です。
QAエンジニアになってから心がけていること
以上、QAエンジニアには開発経験が役立つ例として、開発プロセス改善の主な2つのアプローチによる私のQAコンサルタント経験をご紹介させていただきました。
最後に開発プロセス改善に限らず、どのQAエンジニアの職務においても、私が最も重要だと考えていることをお話させていただきます。「開発現場に寄り添い、共感し、納得してもらう」ことです。
私は第三者的な立ち位置から開発プロセス改善を初めて実行した時は、正直プロジェクト外からアクションしていくのは難しい！と感じました。自分自身が開発プロジェクトに所属している時は、「みんなルールこうしようぜー」と言うだけで変えられたのに、第三者の立ち位置から提言する場合は、あれやこれやと言い訳されてやってもらえない、挙句の果てには「お前分かっているのか？」「お前に何が分かるのだ！」というような勢いで反感を買うこともあります。
このような経験から得た私の教訓は、「開発現場に寄り添うことが必須である」ということです。
開発現場に寄り添うために私がいつも心がけているのは「自分が同じ立場でこれをやれと言われたらどう思うか？」を常に考え、理想論だけを叩きつけないようにすることです。
弊社のようなQA会社にご依頼をいただく案件は、品質に問題を抱えていたり、品質を向上するために苦戦したりしているわけで、開発現場からすると「時間はないが、品質は担保しなければならない」等の難題に悩まされ、場合によっては猛烈疲弊した状態になっていることもあるわけです。このような開発現場の皆さんに対して、どれだけ役に立つ提案や支援ができるかがQAエンジニアのミッション達成のための肝だと考えます。
私が開発エンジニア兼PMだった時、プロジェクトをうまくまわせずに品質問題を起こしてしまったことがありましたし、そのために寝られない日々をたくさん過ごしたこともありますので、開発現場の痛みを理解するように心がけ、自分のような目にあわないようにするための最善策は何なのかを常に考えるようにしています。
時には強い意志を持って開発現場を動かすアクションが必要な場合もありますが、その時は自分の経験を例に出して提言すれば多くの方々が納得してくれます。まず自分が同じ立場ならどう思うか、どうするか、どうしたいかを真っ先に考えるようにしたら、最適解を導き出すスピードが早くなりました。
反対に、開発現場の声を聞きすぎると改善が進まない場合もあり得るので、どうしたものかと考えていた時期もありました。しかし、この開発現場に寄り添った改善活動の進め方を、社外で知り合った有識者より好評いただいたことがあり、その時から自信を持てるようになりました。
「開発現場に寄り添ってくれるQAエンジニア」と言われたら、嬉しいですよね。
まとめ
- QAエンジニアのお仕事は開発経験や開発PM経験を活用できる場面がたくさんある。
- 品質問題で困っている開発現場には寄り添って一緒に解決してくれるQAエンジニアが喜ばれる。
- 開発現場に寄り添えるQAエンジニアになるためには、第三者的な立ち位置であっても開発担当者と同等の当事者意識を持つとよい。
- 開発担当者と同等の当事者意識を持つためには、開発経験や開発PM経験があると非常に役に立つ。
以上、ご参考になりましたら幸いです。
<おすすめ記事・メディア>
20-30代のためのハイキャリアメディア「コンサルキャリア」
未経験のシステムエンジニア・SE転職はきつい？20代・30代に応じた転職方法や注意点
プログラミング学習やエンジニア転職に役立つ情報を解説「wagtechblog」
APPENDIX:用語の説明
※1 CMMI
「CMMIとは、組織がプロセス改善を行う能力を評価する手法および指標。ソフトウェア開発プロセスの成熟度を測る「CMM」を元に複数の同種の手法を統合した汎用的な手法で、米カーネギーメロン大学CMMI研究所が開発、公表している。」
IT用語辞典 e-Words より引用
※2 シフトレフト
「シフトレフトとは、製品開発などで行われる特定の工程を通常よりも前倒しして実施すること。IT分野ではソフトウェア開発におけるセキュリティ対策やテストなどで行われることが多い。」
IT用語辞典 e-Words より引用
※3 要件ベースライン
「ベースラインとは、基線、基準線、基準値などの意味を持つ英単語。字義通り、図形などで何かの基準を表す線分を指す用法と、比喩的に、計画や標準、最低限度などを表す値やデータ、状態などを指す用法がある。」
IT用語辞典 e-Words より引用
「要件ベースライン」とはプロジェクトの要件をステークホルダー間で確認し、決まった内容や範囲(スコープ)を基準とすることである。またその基準をステークホルダー間で合意形成することを推奨する。要件ベースライン決定後の変更は変更管理をして、要件通りの品質を担保するためにはスケジュールやコストの見直し等をおこなう必要があることを説明するための根拠として使用する場合が多い。
※4 デグレード
「デグレードとは、新しいバージョンのソフトウェアの品質が、以前より悪くなること。また、以前修正した不具合やバグが再発・復活すること。新しいファイルなどを古い内容で上書きしてしまい、更新内容が失われることを指す場合もある。」
IT用語辞典 e-Words より引用
