これはソフトウェアテスト Advent Calendar 2019 - Qiita 12日目 のエントリです。
はじめまして。
福岡の会社でQA Manager をしています、Fukunaga と申します。
今回所属するQA組織で今年から運用を開始している QA Engineer の評価基準 を策定～運用してみた話を綴ります。
皆さん現場で使えるテストスキルのお話が多い中で、ちょっと毛色が違う内容で恐縮ですがよろしくお願いします。
#はじめに
私が評価基準を作ろうとした際に、この手の情報がなかなか見つけられずに苦労しました。
そういった「今から作る方」「既にある基準を改善したい方」に向けて。
また「評価される側」として現職の テスター、QA エンジニアの方にも
裏側の葛藤など少しでも伝わればと思いこのテーマを選択しています。
※こういった記事の執筆や社外に向けて公開した事がないため、
読みづらい部分も多々あると思いますが、なにか得るものがあれば幸いです。
#【最初に結論】
#【背景/課題】
それでは、まず基準策定以前の背景、課題をかんたんに記載します
##■内部事情
- 1.従来の評価基準の形骸化
- 過去に策定されたスキルマップは存在していたが、現在のニーズとマッチしなくなり活用されていなかった
- そのため最新の業界、組織状況を踏まえて求める QA Engineer 像が**明示されていなかった**
- 2.社内QAスキルのガラパゴス化
- 基準が曖昧化していたことで、同じ"QA Engineer"でも、アレができるがコレはできないなどレベル感の偏りが顕著に
- そのため昇進、昇格のたびに「なんでアイツが？」となり現場からの**評価への納得感**が失われていた
- QA Engineer自身も、自分達が客観的にどの程度のスキルを持っているか判断できず、 **不安や確かな自信を持てずにいた**
- 3.成長鈍化
- 目指すべき道が見つけられない人たちが増加
- →「何したらいいもわからない上に、やっても昇給するかもわからない(だからしない)」 →「上司のお気に入りしか昇進しない」という悪評、悪循環が生まれつつあった(主観)
- (評価だけの問題ではないが)間接的に**専門職として技術力の向上に目を向けづらく、人海戦術から卒業できない** など全体的な成長を妨げるリスクを抱えていた
- 1.全社的な人事制度の変更
- 2019年度より、会社全体の人事制度に変更が入り、従来よりも細かいランク規定が制定されることになった
- ※それに伴って細分化したランク毎にQA Engineerの 評価基準を制定するよう、ボスからお達しを受ける
- 2.経営層への認知度
- 明確な基準もなく、業務内容や成果を組織外に向けて共有する仕組みが存在しない → 社内ですらQAのお仕事がブラックボックス状態
- 偉い人**「QAってなにしてるの？」**
- → このままじゃおちんぎんに期待できない..！
- 1.求められるQA Engineer像を明示化する
- 評価を通じて求められるスキルの理解と、QA Engineer 本人が現在のスキルレベルを客観的に理解できること
- 2.評価の妥当性の向上
- 各QA Engineer のスキルレベルを視覚化、公開することで失わてれていた評価への納得感を向上する
- 3.成長促進
- 業界で認知され評価を受けているモデルをベースとして活用し、市場ニーズの高いスキルの理解と習得の促進
- 4.認知向上
- 業界標準のベンチマークを用いた測定結果を人事評価に組み込み、
- QA組織のレベル、価値に対する経営層からの理解度の向上の材料に → おちんぎん上げたい..！
#【参考にしたもの】
- ① Test.SSF
- ② TPI NEXT
- ③ 現場の声
##① Test.SSF
- http://aster.or.jp/business/testssf.html 
- 著名なモデルですのでここでTest.SSF自体の詳細は省きますが、
- このモデルの資料に記載された"目的"や、活用対象等がまさに私達の課題にピッタリで、先ずコチラに目をつけました
- Test.SSF からは「全体的な構造」、「段階的なレベル定義」、「現在のソフトウェアテスト業界で求められるスキルのハードル感」など大枠の部分でとても参考にさせて頂きました。
- 特に、**このモデルに込められた"理念"にとても共感を覚え**、改めて気が引き締まりました。
- 当然ながらスキルカテゴリ/個別の項目内容についてはそのままではさすがに完全にマッチしない部分もあり、 現状の職務要件やニーズに沿ってテーラリングが必要でした。
- https://www.tmap.net/building-blocks/test-process-improvement-tpi 
- そこで、個々のスキル項目はTPI NEXTというテストプロセス改善モデルのアセスメント項目を参考に構築しました
- もともとTPI NEXTは別で学習、社内活用を進めていたこともあり、 既にアセスメント項目を社内向けにテーラリングしていたため、策定コストを抑える意味でも世界的に汎用的なスキル定義ができることも意識してこちらを活用しました
- 以下にスキルマップのスクショを掲載していますが、**大項目>中項目>小項目等のフレームワークはほぼこちらから引用**しています。
- 最小項目の内容を他の参考物と合わせて取捨選択、自社向けに文言の再翻訳をかけて適応しました。
- こちらもTPI NEXT そのものについての説明は他の方がたくさん良い記事を出していますので、こちらでは割愛します。
- 一方的に管理職だけで定めた項目では納得感や、現場の実態とかけ離れたものができてしまう懸念もあったため、
- QA Engineer 本人達にも協力頂き、それぞれの実務からの体験談
- ・「このスキルがあったのでうまくやれた事例」
- ・「あるスキルが不足していたので困った事例」
- などをテーマにディスカッションし、そこで得た生の意見も参考に項目を追加しました
- 例
- などなど
- これらを元に、昇格試験や評価サイクルの制定 ( レビューのフローなど )
- QA Engineer 協力のもとシミュレーションを何度か実施し、2019年度から運用開始がはじまりました
- テーラリング
- 既存のモデルを持ってきただけでは、どうしても自社の状況にマッチしない部分があるもので、テーラリングは必須かと思います(元のモデルでもそれが推奨されています
- そもそも状況によって変わるのでコレが正解！といったものもないかと思いますが
- ・**「参考元のモデル自体をまずは深く理解すること」**
- ・**「多くの人を巻き込み広い視野での意見をもらうこと」**
- この2つはいずれにせよとても大事なポイントだと思います
- Be Agile
- どうせならガチっと長く使えるものを作ろうと思ってしまいがちですが
- 素早く変化し発展していくこの業界で、普遍的なスキルを意識してたら一向に形にならないと思いあえて一旦忘れました
- そのため必ず継続的な改善が必要になる前提で、小さくスピーディーに出していこう というスタンスで実施しました
- そもそもがタイトなスケジュールでマストの締め切りがあったこともあり
- これはもう、未来の自分やその時の当事者たちが継続してより良いものにしていく。 もしくは施策がゾンビ化してしまったら破棄してもいいと"振り切れた"事が実際に形にするために重要な考え方だったと感じます
- ※もちろん実際にいろいろと詰めが甘いところ、不備があって関係各所に一部負荷を強いることもありました。
- 当然それによって周囲からの不平不満、容赦ないマサカリ死ぬほどふってきましたし、申し訳なさもたくさん感じました。ですが、**なにもないままより絶対良くなる**と強く信じて考え続け、施策を動かし続けました。
- 気合い
- 技術力向上のため！ とかインテリなこと言いながら、この手の施策を形にするためには結局、 考え抜いて動き続ける**マッチョな気持ち**が最も重要なことかもしれません(根性論) 
- スキル項目は【参考にしたもの】をベースに用語や社内の事情に最適化した文言に整え、そのスキルが必要とする目的、不足している場合の懸念事項を合わせて見せるようにしています。
- "何が"必要か。だけでなく"なぜ"必要なのか。という点も合わせて理解を促したい狙いです。  ###スキルレベル
- Test.SSF の段階評価をベースに社内の対象者のレベル感や期待値に沿って全面的に 段階評価の基準を制定しなおしました
- 上記スキルマップの項目に対して、それぞれ5段階評価で選択します
- また、会社自体のVISION/MISSION で示されるコンピテンシー要素を加点項目として追加しています。
- 各項目に対して5段階評価を実施し、総合スコアが基準値を満たした場合にランクアップ目安となる仕組みです 
- 評価サイクルはこのように自己評価→上長評価→(特定のランクでは昇格試験）→結果 という大まかな流れで動かしています。
- 基本的に半期ごとに実施しています 
- 評価項目の認識ズレ
- 評価者間の認識ズレ
- 評価にかかるコスト(過密日程)
- 評価項目の認識ズレ
- 社内向けにスキル項目を再翻訳したとは言え、ある程度のベースとなる知見がないと意味が理解できないことも多々ありました
- そのため、評価者とQA Engineer相互にスキル項目の内容の認識合わせに時間がかかりました
- ただ、ここは初回は特に必須で発生するコストと事前に割り切っていたため 適宜説明を行いなんとか認識埋め合わせをして進めることができました
- 評価者間の認識ズレ
- これはキャリブレーションを目的に、複数の組織長間で相互に別組織の社員の評価の最終チェックを行うPhaseを設けていたのですが
- 組織によって、レベル基準判断のブレが大きく**お互い判断に異議アリ！で殴りあい疲弊しきってしまう惨劇**となってしまいました
- 結果的にキャリブレーションという目的は果たせたものの、評価者のメンタルが一時的に崩壊した事でその後この辺のルールは大幅に改定されることになりました()
- 個人的にここが一番苦しく、また反省すべき点が多かった部分だと感じています。
- 同じ組織内、同じマネージャ同士という点で甘えが少なからずあり、お隣の部署の方まで相互理解を深めるための事前の動きが足りなかったと後から反省しました。
- 普段から QA Engineer に対してDeveloper やPlannerと早期に認識揃ってるかしっかり確認せぇ！と言ってる自分ができてませんでした(泣)
- 評価にかかるコスト(過密日程)
- 後はシンプルに時間がかかることも継続課題です
- 旧スキルマップと比較して単純な項目数は 半分程度まで削減できたのですが、どうしても慣れていないこともあり
- またやってみたら運用面含めて想定以上に考慮漏れや予期せぬトラブルが発覚するなど、関係者全員ボロボロになりながら初回の評価を終えました (皆様ご苦労をおかけして大変申し訳ございませんでした) 
- いまも改善中
- 上記の多大な犠牲、反省を無駄にしないため、 次回評価までの間に「改善委員会」を発足し、各組織長との連携を強める、現場にアンケート+QA Engineer 自身も委員会加入希望を実施
- 現在も委員会を中心に、全体コスト最適化や、基準の認識固め、各種ガイド資料の充実等リアルタイムで改善を重ねながら最適な方法を日々探しています
- またスキルが視覚化、数値化された事で様々な分析、適材適所なアサインへの活用等今後の発展も継続して実施していきたいと考えています。
- 効果
- ■求めるQA像の明示化、妥当性、方向性理解の向上
- まだまだ多くの課題は残るものの、
- しっかり向き合って**力量を証明した方達が適切な評価を受け昇格**することができ、
- またこれまで避けてきた**高度なスキルへの興味関心、広範囲へのアウトプット等も必要性も相まって積極的に取り組む姿勢**ができてきています。
- ■現場からも"自信に繋がった"というフィードバック
- 今まで自分の客観的な力量がわからず自信が持てなかった方も、 強みと成長ポイントを把握したことで**「自分がある程度できている事がわかって自信になった。」「何が必要とされているか把握でき、次の目標を定めやすくなった。」**という意見もよく頂きました
- 当然評価者の立場としても、フィードバックをする際に 評価項目を引き合いに新しいチャレンジ促進にも活用できるようになるなど有効性を体感しています
- ■偉い人の理解度向上
- スコアの妥当性を証明するために、スキルマップとは別に定量的な成果を証明する仕組みがあるのですが、
- これが昇進・昇格の際に面談資料として提示されることりになり**「QAはここまでやっていたのか」「本当に居ないと困るね」**という理解を得られました。
- 肝心のおちんぎんについてはここでは自粛しますが、顔で察してください
- ■ Ownership の芽生え
- 何よりも、全体を通して現場の QA Engineer を巻き込み協力を常に頼ってきたことで
- **自分たちの働く環境は自分たちで良くできるんだ！**という"Ownership"の芽生え、向上にも収穫があったことは嬉しい誤算でした 
- この指標の策定と運用を通じて、冒頭にあげた多くの課題に対して 大なり小なり改善効果を生み出す事ができたことは間違いありません
- ただ1つだけ絶対にできないことを知りました
- それは**誰もが納得できる評価基準**はできないということ。
- 当たり前のことですが、この取組みを通して改めてこの"理想"は実現が難しいし、何より優先度が高くないということを感じました
- 評価には必ず優劣がつくものであり、みんなが納得したり気持ちよくなるためものではないからです。
- もちろんそこに現場の納得感が強い方が正しい運用が継続可能なので、すべては捨てられないものですが、あまりにも現場の声を聞きすぎて本来の目的を忘れないようにという自戒の念を込めて書いてます
- もしかしたら、世の中にはもっと頭が良くて両立できちゃう方もいるかもしれません、そんな自信のある方は是非仲間になって一緒に良くしていきましょう。ご応募お待ちしています
- とりあえず、みんなに井の中の蛙としてではなく、大海でも強く生きていけるようにと願いをこめて今も絶賛評価進行中です 
-
同じ悩みを持つ方、乗り越えた方など是非意見交換させてください
> Twitter：https://twitter.com/fm03fmfm
##■外的要因
#【目的】
上記背景を踏まえて、以下の目的で新しい QA Engineer の評価基準を作ることにしました
>公式より引用「Test.SSFの公開に寄せて」
日本のソフトウェアテストの技術は、世界に対して誇れるものでしょうか。 日本のソフトウェアテストの産業は、世界に対して競争力を持つものでしょうか。 私たちASTER（ソフトウェアテスト技術振興協会）とIVIA（IT検証産業協会）は、日本のソフトウェアテストの現状に危機感を持ちつつ、その一方で明るい希望を持っています。多くの日本のソフトウェアテストのエンジニアは、自分の技術を他人に説明することができません。 すなわち、技術が低いように思えます。これが危機感の源泉です。一方、一部の日本のソフトウェアテストのエンジニアは、他人に説明こそできないものの、豊富な経験と鋭い洞察力を基にした質の高いテストを行っています。すなわち、高い技術を持っています。これが希望の源です。日本のソフトウェアテストの産業は、これからどこへ向かっていくのでしょうか。技術の高さを説明できないまま、顧客に単価をダンピングされて有能な人財に去られ、壊滅していくのでしょうか。それとも、技術の高さをアピールして顧客に高い付加価値を提供し、同時に高い技術をベースラインとして継続的な技術の高度化を行い世界に冠たる産業に成長していくのでしょうか。
我々は分岐点に立っています。いま行動を起こさなければ、産業は壊滅していくでしょう。我々は、座して待つわけにはいきません。いま必要なことは何か。いま行うべきことは何か。いますぐに、行動しなくてはなりません。
その一つのアプローチが、Test.SSFです。Test.SSFは、テストのスキル、すなわち実践的なスキルの高さを示すためのフレームワークです。テストのスキルが高い組織は、Test.SSFを用いることでスキルの高さを明示することができるようになります。テストのスキルが高いとは言えない組織は、Test.SSFを用いることでスキルを向上する目標を明確に設定し努力を始めることができるようになります。顧客組織は、より高いスキルを持つ組織に仕事を依頼することができるようになります。
Test.SSFは、日本で駆使されている高いテスト技術をベンチマークし、説明可能に致しました。そのため、皆さんの組織では耳慣れない概念や技術用語、工程などがあるかもしれません。大事なことはTest.SSFに自組織を合わせるのではなく、Test.SSFを用いて自組織に眠っている高い技術を掘り出し育てることです。ASTERとIVIAの願いは、Test.SSFを用いて自分たちを鍛える組織が増え、日本のソフトウェアテスト産業が世界に冠たる存在に成長していくことです。Test.SSFを用いてソフトウェアテストエンジニアが高い技術を持っていることに気づき、誇りを持って働けるようになることです。ぜひTest.SSFを用いて自分たちを鍛え、日本のソフトウェアテスト産業を世界に羽ばたかせてください。
ぜひソフトウェアテストエンジニアが誇りを持って働けるようにして下さい。ASTERとIVIAはTest.SSFという活動を通して微力ながらも尽力してきたいと考えております。どうぞよろしくお願い申し上げます。
2011年7月 ASTER理事長 西康晴
##② TPI NEXT
##③ 現場の声
>・Gitに関する知見があった → Developer のデプロイ順序ミスを察知 → 本番障害を未然に防げた >・HTMLの知見がないテスターから、同一原因だが複数箇所で発生している問題をバラバラに報告されて苦労した
#【意識したこと】
#【完成品】
上記の流れでできた評価基準を一部公開いたします
###スキルマップ
###評価サイクル
#【初回運用してみての反省】
形作るまでも、まぁまぁ血反吐吐きながら作っていたのですが、本当の地獄は運用を開始してからでした
###初回実施後の主要な課題
#【その後】
#【さいごに】
###PR
この基準策定を一緒に進めて頂いた上司も「小ネタ」の方でAdvent Calendar参加していますので、是非覗いてみてください
12/23の記事 https://qiita.com/advent-calendar/2019/software-testing-koneta