イネイブリングQAについての連載、第3回となる今回は、イネイブリングQAに必要なスキルについて考えていきましょう。
＜QA活動のスキル伝達「イネイブリングQA」 記事一覧＞※クリックで開きます
前回の記事では、開発者に対するさまざまな「イネイブリング圧」がある状況のなか、単純に品質に関する知識やスキルを伝えるだけでなく「開発者の負担を軽くすること」を意識しましょう、と書きました。
開発者をはじめとした他の職種・ロールの方々に品質の知識やスキルを伝え、実践できるようにしていくには、さまざまなスキルが必要になります。今回はその中でも、大きく2つのスキル
- 課題設定・提案・解決のスキル
- 品質技術の編集スキル
について説明します。
大前提：QAエンジニアとしての実務スキルは必須
イネイブリングQAとしてのスキルについて説明する前に大前提を確認しておきます。
前回・前々回の記事では、QAエンジニアが持っているテスト・品質関連のスキルや実務を開発者に移譲していくことがイネイブリングQAです、と説明しました。
つまりイネイブリングQAは「自分自身が手を動かすことをグッと堪えて、周りができるようにする」という側面があります。そのためには、自分自身が実務を担おうと思えば担えるだけのスキルが必要です。
口だけ出して自分はできません、ではなかなか信頼は得られません。自分自身ができるか、最低でも「知識としては持っているけど実践したことはないから、一緒にチャレンジしよう！」という姿勢は必要です。この点は忘れないようにしましょう。
必須スキル１：課題設定・提案・解決のスキル
開発チームの納得を得る重要性
イネイブリングQAとして品質技術を移転するにあたり、品質保証や向上に関する取り組みが開発チーム内で自走する状況を作る必要があります。主導していたイネイブリングQAがチームを離れたら全部止まってしまいました、では意味がないですよね。
品質に関する取り組みを行うというのは、それまでやっていなかったことを始めるという場面も多く、一時的に工数が増えたり、開発者の気持ちの面でも負担がかかることがあります。そのような状況において、開発チームで品質関連の取り組みを自走してもらうためには「最初は少し手間だけど、ちゃんとやるとメリットがあるよね」と納得してもらうことが大切です。
納得して続けてもらうために必要なのが、課題設定・提案・解決のスキルです。
開発者の納得する形で
- 現状の課題
- 品質に関するスキル習得や取り組みによって、課題が解決されること
- 課題解決によるメリット
を提示できれば、前向きにイネイブリングを進めることができるでしょう。
理想・現実・問題・課題の整理
課題設定・提案・解決のために、私はよく「理想・現実・問題・課題」を整理した図を用います。本図については【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 | Sqriptsでもご紹介しました。
この構造に当てはめて理想・現実・問題を明らかにしたうえで、そこから導き出した課題について開発チーム内で相談します。QAが一方的に設定したのではなく一緒に考えて決めた、という状態が望ましいので、「相談」という形がよいでしょう。課題の共通認識を持てたら、それに対する解決策の提案を行い、実際のアクションを起こします。
解決策の検討・実行における姿勢
解決のための活動は、QAエンジニアとしての腕の見せ所です。過去の経験や社内外の知見などをもとにして
色々な手段を試すことになるでしょう。開発者やマネージャーなど共に働く仲間は、こうした解決策の検討・実行の様子を（QAエンジニアが思っている以上に）見ています。取り組む姿勢や引き出しの多さなども信頼関係の醸成につながります。しっかりと取り組みましょう。
必須スキル2：品質技術の編集スキル
編集スキルとは何か
今回触れるもう1つの必須スキルは、品質技術の編集スキルです。品質技術の編集、という言葉は聞き慣れないかと思います。それもそのはず、この記事を書きながら作った言葉です。
イネイブリングQAの役割である、品質技術や実務を開発者に移譲していく活動においては、「教える」という行為が中心となります。教えるという表現に抵抗があったり、しっくりこないという場合には「伝える」と表現してもよいでしょう。
誰かに何かを教えるという行為について、よく「教える内容の10倍知っていなければ、教えられない」などと言われます。ひとに物事を教えるには、順序付けや取捨選択が大切であり、そのための「10倍知っている」だと私は理解しています。
私自身がイネイブリングQAとして仕事をしていて、品質技術を教えるうえでも同じことが言えると感じています。単純に自分自身が知っていること・できることをそのまま開発者に伝えればよいわけではありません。
- どうすれば伝わるのか
- どのように説明すれば身につけてもらえるのか
- 自分が居なくなっても、伝えたことが定着している・自走してもらえるにはどうすればよいか
を常に考えて伝えることが大切です。このような工夫を指して、ここでは編集と表現しています。
編集スキルを身につけるための2つのポイント
適切な編集を行うために私が心がけているポイントを2点ご紹介します。
①全体像を描く
何事もそうですが、個別のトピックを散発的に伝えられても、全体像がわからないと理解しづらい場合が多いです。
たとえば開発者に対してテスト設計技法を教えて業務で活用してもらおう、と考えたとします。今週は組合せ、来週は同値分割・・・とただ説明していても、おそらく身につきづらいでしょう。
まずは
- テスト設計技法とは
- 技法を使うメリット
などの概要から入ったうえで「このさきテスト技法を5つレクチャーします！」のように全量を提示したほうが、聞く側も理解しやすいはずです。
全体ボリュームやゴールなどの全体像を先に設定・提示してから進めるようにしましょう。
②QAにとっての正しい言い方・やり方にこだわりすぎない
開発者はJSTQBのシラバスを読み込んでいることはまれですし、日常的にインプットしている内容もQAエンジニアのそれとは異なります。つまり、完全に同じ共通言語をもっているわけではありません。
そうした状況で品質技術を伝える際に、いわゆる「QAにとっての常識」を押し付けることになると逆効果です。
たとえば「開発者が行うテストにおいても、テストプロセスに厳密に則らなければならない」や「テスト分析とテスト設計を厳密に区別して行わなければならない」などの押し付けをしてしまうと、反発を生んでしまいます。
実際に私も開発者とテストプロセスの見直しを行った際には、あえて「テストプロセス」「テスト分析」「テスト設計」といったワードは出さずに進めました。「いきなり細かいテストケースを作るのではなく、観点レベルでレビューしてから詳細化したほうが結果楽ですよ」など、一般用語を中心に説明したほうがよりスッと受け入れてもらえます。
このように、QAエンジニアの間で常識・普通とされているやり方や言い方にこだわり過ぎず、まずはエッセンスだけを取り入れてからだんだんとブラッシュアップしていく作戦も持っておくと良いでしょう。
まとめ：イネイブリングは「人を動かす」こと
今回はイネイブリングQAとして主に開発者に対して品質技術を伝える際に必要となる2つのスキルについて説明しました。
とくにイネイブリングQAに求められるのは、私は「人を動かす」ことだと考えています。知識を一方的に伝えるだけ、であれば簡単です。しかし必須スキル1の項目でも触れたように、開発者が品質知識や技術を身に着け、自走できてはじめてイネイブリングできたと言えます。そのためには、はたらきかけの方法について工夫をし、自分ごとと捉えて動いてもらうことが必要になります。
なかなか大変ではあるものの、それだけにやりがいがあるのがイネイブリングQAです。また、人に何かを伝えて行動を起こしてもらうためのスキルは、イネイブリングQA以外のあらゆる面で応用が効くものです。
私自身まだまだ試行錯誤中で、この先もそうだと思います。一緒に頑張っていきましょう。
