この記事はベリサーブ Advent Calendar 2021のカレンダー | Advent Calendar 2021 - Qiitaの１日めです。ついに始まりましたね。
ここ２，３年、（システム）テスト自動化の普及活動を行ってきました。そのへんの整理も兼ねつつ、会社でテスト自動化の教育を整え＆継続的に発展させている話について紹介しようかと思います。
本記事のおおまかな内容
- やった／やっていること
- 会社で（システム）テスト自動化関連の教育の土台を作った
- その後チームで育て続けている
- 得られた／共有したい知見
- なにをどう考えて土台を作ったか
- 教育を整備・普及する過程で心がけたこと
背景
外からは「テスト会社」などと呼ばれることもあるように、エンジニアの多くはそれぞれ特定のお客様のところでソフトウェアテストや品質に関する業務を行っています。
当時テスト自動化がバリバリできますという個人は存在していたものの、「特定の個人や部署ができます」という状態ではいかんよね、という問題意識が会社としてあり。それを「もっと会社全体としてのテスト自動化力をあげる必要があるので、キミのミッションとしてやりなさい」と言われたのがきっかけです。
というと言われたからやってる、のように見えますが、ちゃんと前向きにやってます。
そんな流れでテスト自動化を会社で普及させることになったので、「まずは育てる仕組みからだ」と考えて教育の整備にいたりました。
教育を整備・普及させるために考えたこと
まず考えたのが「コンテンツを作って研修をしよう」ということでしたが、闇雲にやってもダメだろうなという実感もありました。
色々と工夫すべきポイントを考え、大まかには以下の3点を気にしました。
- 組織と個人に対する動機づけ
- 研修「群」としての整理
- スケールできるような仕組みづくり
現状すべてうまくいっているわけではないものの、これらを継続的にやっている状態です。
１．組織と個人に対する動機づけ
組織の中でなんらかの技術を普及させようと思ったとき、ただ「やろうぜ！」だけではうまくいきません。エンジニア個人に「自分にとって必要だ。受けよう。」と思ってもらうこと、組織のマネージャに「自分たちの部署にとって必要だ。受けることを促そう。」と思ってもらうこと。この両面からのアプローチが必要です。
そこで、テスト自動化を普及させることが会社として必要であることと、個人としてメリットがあること、をアピールしました。
訴求する点として以下の4つが考えられます。
- 会社としてテスト自動化を
- 普及するとビジネス上のメリットがあること
- 普及しないとビジネス上のデメリットがあること
- 個人としてテスト自動化を
- 学ぶとメリットがあること
- 学ばないとデメリットがあること
MECE風に書き出していますが、個人的に「これをやらないとあなたは損しますよ」という危機感を煽って行動を起こさせる方法だと長続きしない（＝常に危機感を煽りつづけなければならない）ので、あまり好きではありません。
組織の中で技術を普及させる、というのは先の長い話になるので、基本的には「やるとメリットがありますよ」という正統派ルートで必要性を訴求しています。
２．研修「群」としての整理
特定のツールの使い方や考え方を普及させたい場合には不要かもしれませんが、「テスト自動化」くらいの抽象度のものを教育して普及させたい場合には複数の研修が必要になります。
これをバラバラに作ってしまうと、受ける側としても「どれを受ければいいの？」「受けたらどうなるの？」という点がわかりづらくなります。１の「動機づけ」のところのブレーキにもなりかねません。
そこで、テスト自動化ができるエンジニアのロール区分として設定したものをベースに、「この研修を受けて身につけると、だいたいこのロールのこのレベル相当ですよ」といった内容を整理し、研修の全体像を作りました。
via ベリサーブが考えるテスト自動化プロジェクトのマネジメントとは｜実績・強み｜ソフトウェアテスト・第三者検証のベリサーブ
例えば
- テスト自動化エンジニアの必須要件
- テスト自動化入門研修
- Selenium研修（初級編）
- Git/GitHub研修
のような整理です。（ロールの要件は実際と異なりますが、イメージとして。）
３．スケールできるような仕組みづくり
会社の規模にもよりますが、技術の普及を単身やりきるというのは基本不可能です。一歩目は単身かもしれませんが、だんだんと仲間を増やしていく必要があります。（『カイゼン・ジャーニー』なんかを見ていると、流れは近いのかなと思っています）
これは工夫というか結果なのですが、テスト自動化技術を普及させるチーム（課）を作ってもらえたのが大きかったです。仲間ができたことによって、普及活動にあてられるマンパワーも純粋に増えましたし、推進力が増しました。
また、普及活動を行う人数を増やすことにも関係しますが、知識とパワーが極力個人に依存しないような状態を保つことを最初から心がけました。
例えば、
- 研修資料は編集可能な状態で常に社内公開する
- 他の部門の若手に声をかけ、研修講師をやってもらう
などです。
研修資料を常に公開しておくことで、忙しくて研修に参加できないエンジニアも好きなタイミングで独習することができますし、社内の一部では「部門向けカスタマイズ」をして独自の研修が開催されていたりもします。研修で教えられる内容の範囲や質を厳密に管理したい、という場合には適さないかもしれませんが、カスタマイズを許容しながら社内のあちこちで学びが発生している状態のほうが有益、と考えています。
また、他部門の若手に声をかけて研修講師をやってもらうなど、教える側の役目ができる人もコツコツ育てています。上で書いたようにテスト自動化を普及させるチームを結成したはいいものの、結局そのチームでしか教えられない、ではスケールしません。
どうせ同じ会社内なので、技術の普及活動においては知識や情報の独占はせずにフルオープンで臨むのがよい、です。技術の普及を担う部門が寝てても勝手に広まっていく、が真の理想です。寝たい。
結果どうなっているのか
テスト自動化のロールに紐づける形で教育の全体像をざっくり作り、研修コンテンツを作り、教育を行う。これを、チームを拡大しながら地道にやってきました。
結果、テスト自動化に関するなんらかの教育を2019年度から毎年100人以上に行えています。
研修のコンテンツに関してもどんどん増えており、一例をあげると
- 全般
- テスト自動化入門
- 社内テスト自動化ガイドライン研修
- テスト自動化模擬プロジェクト
- ツール
- UFT One
- Selenium
- Appium
- Magic Pod
- Autify
- mabl
- 周辺技術
- Python
- Jenkins
- CircleCI
- Git/GitHub (GitBucket)
- Docker
などなど広がっています。
チーム体制を整備したことによって、最初にスタートした自分が研修を作ったり開いたりしなくともメンバーがどんどん研修を強化して提供できるようになっているので、教育の整備・普及という点ではわりとうまくいったのでは、と思っています。嬉しい。
今後
いまのところ作った土台の上で順調に教育が整っていっているので、今後はより多くのエンジニアに研修を受けてもらったり、さらに高いレベルの技術力を身に着けてもらえるようなコースを提供していきたいと思っています。
いち個人としては、これらの学習機会とコンテンツを整えたことによって、社内のより多くのエンジニアが「テスト自動化楽しいじゃん」と思って自走できるような、そんな方向に背中を押していけたら最高です。