Test Automation

テスト自動化とか品質とか勉強会とかやってるエンジニア(Automation Architect)のブログです。

DevOps時代のアーキテクチャ品質特性とプロセス品質概論

はじめに

 DevOpsという言葉は2008年に誕生した。その概念は2015年頃日本でも再注目され、これまでDevOpsに有用な技術や文化の変革について議論されてきた。このブログエントリでは、DevOpsがアーキテクチャとプロセスに与えた影響についておさらいしたのち、DevOpsに必要なアーキテクチャの品質特性とプロセス品質を一覧で示す。

DevOpsがアーキテクチャとプロセスに与えた影響

DevOpsの意義

 プロダクト開発では、要求分析からリリースまでのサイクルを回し顧客からフィードバックを素早く得ることで、プロダクトの品質を素早く継続的に向上することが重要だ。これを達成するため、「要求分析」「設計」「実装」「テスト」「リリース」などのバリューストリームマップに含まれる工程の生産性を改善し、リードタイムを短縮する手段を、DevOpsは提供する。下記の図で黄色の線で示された、要求分析からリリースまでのフローのリードタイムを改善するため、各工程の生産性を向上する。

f:id:kokotatata:20190503141031p:plain

DevOpsのバリューストリームマップとフィードバック

各工程の生産性改善のためのDevOpsの2つのアプローチ

 各工程の生産性を向上するため、DevOpsの技術的なプラクティス郡は2つの共通のアプローチをとる。それは

  1. 各工程の手作業をソフトウェア化することで、それらを素早く、正確に、安全に、繰り返し実行可能になものにする。
  2. (上記の1.の結果、)各工程のアウトプットについて、特に、問題があった場合にそれを素早く発見、修正するフィードバックループを作る。

 1.には、クラウドやInfrasutructure as Codeによるリリース作業や復旧作業のソフトウェア化、テスト自動化によるテスト実行作業のソフトウェア化などが含まれる。繰り返し実行する手順を自動実行できるようにしたり、システムの状態をコードで定義できるようにしたりすることで、各作業をソフトウェアとして管理できるようになる。

 2.には、テスト作業のソフトウェア化によって実装工程のアウトプットであるソースコードの問題を素早くフィードバックするCI/CDや、リリース作業のソフトウェア化によってリリース工程のアウトプットである本番環境の問題を素早くフィードバックするカナリヤリリースなどが含まれる。上記の図に青の線でこのフィードバックループを示す。

手作業のソフトウェア化とフィードバックループが意味するもの

 DevOpsのプラクティスによる手作業のソフトウェア化とそれによるフィードバックループは、すなわちDevOpsがシステムのアーキテクチャーと開発のプロセスに織り合わさって変化をもたらしていることを意味する。

 システムのアーキテクチャ面では、プロダクトの外部品質だけでなく、ソースコードを容易に変更したり、テストやリリース作業を容易にソフトウェア化するための内部品質の重要性が増している。テストやリリース作業を容易にソフトウェ化することが可能なように、プロダクトを設計する必要がある。

 また、ソフトウェア化するテストやリリースなどの手作業は、それそのものがソフトウェアでありプロセスでもある。そのため、それぞれの作業をについてソフトウェア面の品質特性と、プロセスの品質を組み合わせて考慮する必要がある。

 次の章から、DevOpsで特に重要なアーキテクチャの品質特性とプロセス品質を一覧する。

DevOpsのアーキテクチャ品質特性

プロダクトの変更容易性(実装作業)にまつわる品質特性

ソースコードの保守性 プロダクトのソースコードは素早くなんども変更可能か?コードの可読性や、単一責任などのクラス設計は適切か?
サービスやコンポーネントの独立性(*1) 1つのサービスやリリースなどの変更を入れる際に、他のサービスやコンポーネントにも変更を入れる必要があるか?変更の影響は限定されているか?
データの結果整合性(*2) 複数のサービス間で共有されるデータには、どの程度の整合性が求められるか?結果整合性の場合、上記の独立性は担保できるか?

テスト作業のソフトウェア化にまつわる品質特性

テスト結果の取得容易性 システムへのリクエストやアクションの結果を期待結果として定義できるか?また、その結果をシステムから容易に取得可能か?
テスト結果判定の自動化容易性 テストの期待結果をコンピュータにも理解できる形で定義可能か?またテストの合否をコンピュータが判定可能か?
テスト実行の並行性 複数のテストケースを並行して実行することは可能か?テストケースやテストデータは独立か?
テスト実行の冪等性 テストケースは繰り返し実行しても同じ結果が保証されるか?テストの事前準備や事後操作がテストデータの冪等性を担保するか?
自動テストの結果の信頼性 テストのカバレッジは十分か?テスト環境は適切か?テスト実行ごとに異なる結果を返すFlaky Testの数は最小化されていか?
自動テストのレポートとログの判断容易性 テストレポートとログから素早くテスト結果を判断できるか?テスト失敗時に素早く調査可能か?

リリース作業のソフトウェア化にまつわる品質特性

サービスやコンポーネントの独立性

(*1)と同じ

複数バージョンの共存性 本番環境などで、複数のバージョンが共存可能か?バージョン間でI/Fなどの互換性はあるか?
リリース・リカバリ手順の冪等性(*2) リリース手順は繰り返し実行しても同じ結果を保証するか?
インフラの廃棄可能性(*3) 既存のインフラを廃棄しても、同じものを再現可能か?
リリース影響の制御容易性 リリースの影響をフィーチャーやユーザーセグメントなどの単位で制御可能か? リリースの影響範囲を段階的に制御可能か?
リリースやリカバリ結果の判断容易性(*4) リリースの合否の判断は容易に可能か? 判断に必要なシステムログやアプリケーションログは容易に取得可能か?

システムの復旧や運用作業にまつわる品質特性

システムの耐障害許容性 単一のシステムの障害が、他のシステムに影響を及ぼしたり、新たな障害を引き起こしたりしないか?
リリース・リカバリ手順の冪等性(*2) (*2)と同じ
インフラの廃棄可能性(*3) (*3)と同じ
システムのスケーラビリティ  アプリケーションやデータベースは独立性が担保されており、容易にスケールアウトすることが可能か?
リリースやリカバリ結果の判断容易性(*4)  (*4)と同じ
エラーログの判断容易性 エラーログから障害は素早く検知可能か?影響調査や原因調査を素早く行うのに対し、妥当なログが得られるか?

DevOpsのプロセス品質

実装工程の品質

ソースコード品質 実装工程の成果物であるソースコードの、コード行数、複雑度、コピペコードの割合などの技術的負債の量
実装工程で作り込まれた不具合数 実装工程で作り込まれた不具合数(テスト工程、リリース工程で発見した不具合数と市場に流出した不具合の総数)

テスト工程の品質

自動テストの品質 テスト工程の成果物である自動テストの、テストケース数、カバレッジ、実行頻度およびFlaky Testの割合
自動テストの所要時間 テスト準備、実行、およびテスト結果の調査にかかる時間
テスト工程での不具合発見率 不具合の総数に対する、テスト工程で見つかった不具合の割合
テスト工程での不具合修正時間 実装とテストの工程やチームをまたぐ、テストによる不具合の発見から修正、再テストによる修正確認までの時間

リリース工程の品質

リリースの品質 リリース工程の成果物である自動リリースの、デプロイ頻度、リリース成功率および失敗時の影響制御割合
リリースの所要時間  リリース準備、リリース作業、および事後確認にかかる時間
リリース工程での不具合発見率 不具合の総数に対する、カナリヤリリースで見つかった不具合の割合
リリース工程での不具合修正時間 実装、テストとリリースの工程やチームをまたぐ、リリースによる不具合の発見から修正、再テストによる修正確認および再リリースまでの時間
障害復旧時間 開発と運用チームをまたぐ、障害発生から検知、調査と不具合の修正やホットフィックスのリリースまでの、障害発生からリカバリするまでの時間
運用・保守作業時間 インフラチームとDBチームなど、複数のチームをまたぐ運用・保守の作業時間

 まとめ

 DevOpsがアーキテクチャとプロセスに与えた影響を概説し、DevOpsで重要なアーキテクチャの品質特性を工程・作業ごとに一覧で示した。DevOpsのプラクティスを通して生産性を改善するには、これらのアーキテクチャの品質特性とプロセス品質を考慮し、アーキテクチャとプロセス両面から改善活動を行うことが重要だ。

エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出しちゃった話3/3

前回の続き

社外発表をしてみて

 前々回前回と「エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出すまで」の話を書いた。このシリーズ最終回の今回は、エンジニアコミュニティ発表未経験の人事の相方が、実際に発表してみた後の振り返りについて書く。今回は、DevOps Days Tokyoのワークショップで体験してきた「Fun! Done! Learn!」で振り返りをした。Fun! Done! Learn!は楽しく振り返りやろうぜ!ってことだと思います(多分)。

Fun! Done! Learn!

 1時間ほどのFun! Done! Learn!の結果出てきた振り返りアイテムは

  • ①今までのカイゼン活動を誇れるようになった(Fun!, Learn! and Done!)
  • ②結果として色々いいことが!(Fun! and Done!) 
  • ③発表内容の工夫(Learn! and Done!)

の3つに大きく分類できた。赤い付箋が人事の相方から出たもので、黄色い付箋が僕から出たものだ。

f:id:kokotatata:20190422105840p:plain

  ここでは、人事の相方がエンジニアコミュニティでの発表で得たものや気付いたものをカテゴリごとに紹介していく。

①今までのカイゼン活動を誇れるようになった(Fun!, Learn! and Done!)

 JaSSTやDevOps Daysで発表する前は、エンジニアコミュニティ発表未経験の人事の相方は、

  • 人前で話すことじゃないと思っていたのに…
  • こんなの参考になると思ってなかったのに

と考えていた。

 だが、実際に発表してみたら、

  • 感動された
  • 勇気をもらったって言われた

というフィードバックを、発表を聞いた人たちから得ることができた。

 そういったフィードバックから、

  • 努力した事例→人の参考になる、影響を与える
  • けっこうすごいことやってたって気付いた
  • 自分が勇気をあげられると気付いた!
  • 参加だけより発表した方が楽しい

という気づきがあり、

  • やってきたことを誇れるようになった
  • 自信がついた

という効果が本人にあったようだ。

②結果として色々いいことが!(Fun! and Done!) 

 エンジニアコミュニティでの発表により、フィードバック以外にも色々嬉しいことがあったようだ。

  • Slideshareにアップロードした。3000 views
  • ツイッターフォロワーふえた
  • 知り合いふえた

のように、発表がきっかけでコミュニティで新しい人との繋がりを持つきっかけになったみたいだ。

 また、

  • Agile Japan実行委員にさそわれた

なんていう、次の機会に繋がるものもあり、

  • 人前で話すのがさらに好きになった

みたいだ。

③発表内容の工夫(Learn! and Done!)

 前回解説したエンジニアコミュニティでの発表の工夫についての振り返りも出た。

  • 伝えたいメッセージを意識して話した→間、強弱が自然とできた
  • 悩んでる人を想定して話した
  • 具体的事例を盛り込んだことでよく伝わった
  • 写真とか図とかSNSの投稿とか具体的な感じ
  • コンウェイの法則を見せることで問題が明確に
  • Fealess Changeとからめて説明してよく伝わった
  • Fealess Change(あるもの)→ブルドーザー(オリジナル)の流れがよかった

 エンジニコミュニティでの発表の工夫は最初はちょっと敷居が高く感じるが、実際に色々と工夫してみことで学びがあるみたいだ。

おまけ:Fun! Done!Learn!について思ったこと

 今回、Fun!Done!Learn!を振り返りの手法として使ってみて、「自分たちのやっていることを肯定的に捉え、チームや個人のマインドセットや行動のいいところを探し出すのに効果的な方法」だなと思った。

 「エンジニアコミュニティでの発表」を「Done!」することが、「参加だけより発表した方が楽しい」や「やってきたことを誇れる」などチームや個人の「Fun!」や、「努力した事例→人の参考になる、影響を与える」などのLearnに繋がっていることが振り返りからわかった。

 今回この振り返りは発表の後に行ったため、「Done!」→「Fun!, Learn!」の向きの影響が多かったが、スライドの準備段階や発表の練習段階では、「Fun!→Done!」や「Learn!→Done!」向きの影響が増えるかもしれない。

 ともあれ、「Fun!」「Done!」「Learn!」の3つの要素が織りなすサイクルが、チームの健康状態をよくするんだなってことを感じた。

まとめ

 この3回のブログエントリでは、人事の相方のちょっとしたカイゼンの話を見つけて世の中に送り出した話を書いた。気づいていないだけで現場のちょっとしたカイゼンの物語はあなたの現場にもきっとあるはずだ。エンジニアコミュニティでの発表をまだ経験したことない人も、是非挑戦してみて欲しいと思う。

エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出しちゃった話2/3

前回の続き

ちょっとしたカイゼン物語をエンジニアコミュニティに送り出す

 身の回りのちょっとしたカイゼンの話を見つけたら、次はどんな勉強会で、どんな構成で発表するか考えるだろう。でも、エンジニアコミュニティでの発表って、ちょっと敷居が高いと思われているかもしれない。

 実際、JaSST'18 Tokaiの発表スライドDevOps Days Tokyoの発表スライドを作っていているときも、エンジニアの僕は無意識にやっていることでも、人事の相方は「???」となる、エンジニアコミュニティ独特のお作法がいくつかあった。

 ここでは、人事の相方と一緒にスライドを作る中で気が付いた、エンジニアコミュニティ独特のお作法を、これからエンジニアコミュニティでの発表を目指す人向けに4つのポイントとして紹介しようと思う。

①発表の位置付け

 自分の発表が、コミュニティや今までの技術の発展の中でどういう位置付けなのかを明確にすることは、発表の意義をみんなに知ってもらう上で一番重要だ。こう書くと難しいことのように感じるかもしれないけれども、要は、「みんなXXについて課題を感じているよね?そのXXについての解決方法YYを考えて実践してみました」っていうように、自分の問題意識とアプローチを明確にするってことだ。

 ここでいう問題意識は、「アジャイルや自動化をチームに導入したいけど色々大変」とか、「自動化を進めたいけどチーム間でのコラボレーションが大変」といったような身の回りでありがちなもので最初は十分だ。いま自分が困っている課題は、実は世の中の多くの人が同じ課題感を抱えている可能性がある。その課題を実践的に解決する話は、きっとエンジニアコミュニティの他の人たちにとっても価値がある。

②発表内容のエンジニアリング的な納得感

 お作法ってほどではないけれども、「もうすでにコミュニティの中で正しいと信じられていること」から実践してみたり、発表スライドを始めてみたりするのはオススメのテクニックだ。エンジニアリングコミュニティの中では今までの歴史や積み重ねの中で、なんとなく「エンジニアリング的に正しい」と信じられていることがある。

 もし、そういう事柄があるのならば、発表スライドの一番最初にその話を紹介すると、「ああ、あの(みんなが正しいと信じてる)プラクティスを実践したのね」「ああ、あの(みんなが正しいと信じてる)手法を発展させたのね」と納得感を得られやすい。(例:いきなり「ブルドーザー」と言っても「なんじゃそりゃ」とビックリするけれども、いったんみんなの知っているFearless Changeをはさむことで、納得感が生まれるw) 

③発表内容の新しい価値とオリジナリティ

 もしあなたの発表内容が、例えば教科書に書いてある手法をその通りにやってみただけであったとしても、その実践内容や結果を発表することはコミュニティにとって大きな価値がある。どういう条件の時にうまくいくのか、いかないのか、事例として共有されると、その手法についての実践知がたまり、より深く理解するきっかけとなる。

 でも、僕個人としては、そんな事例の中にも少しオリジナルのアイデアがある方が好きかなあ(笑)。教科書的な部分て堅苦しい面があるけれど、「ブルドーザー」みたいなオリジナルのアイデアってやっぱワクワクするのよね。

④その手法はいつでも誰でも実践可能か

 もしあなたのカイゼン手法が、誰にでもどんな場合でも実践可能なものならば、多くの人がその手法を実践してみるだろう。より多くの人にとって実践可能な手法はコミュニティにとっても価値が高い。でも、カイゼン手法を誰でも実践可能なモノに落とし込むには少なからず手間がいる。

 手法の原因や結果などを構造化したり、ステップバイステップの手順を書き起こしたりすると、より多くの人が簡単に実践できるものになる。パターン化は、より定義された構造化の方法だ。また、その手法を使ってうまくいく・うまくいかないケースの条件なんかも、その手法を実践してみようとする人にとって貴重な情報だ。

「人事がDevOps研修を作っちゃった話」の上記4つのポイント

 今回の発表の中で、上記の4つのポイントをどのように作り込んでいたのかを参考までに書いてみる。

  JaSST Tokaiの場合 DevOps Daysの場合

発表の位置付け

  • 「"アジャイル"や"自動化"などの新しいプラクティスを組織に導入する」際に必要な文化的な変革の事例
    • ソフトウェア開発に置いて、特にテストの分野ではアジャイルや自動化を導入することが業界全体として急務の課題となっている
    • 上記課題に対して、技術的な解決方法はいくつか提案されているが、文化的な側面の解決方法および事例は少ない
  • DevOpsの文脈で重要な文化的な変革の1つ、研修の促進の事例
    • DevOpsの分野では、コンウェイの法則で知られるように、自動化などの技術的な側面だけでなく、文化的な変革も重要と言われている
    • 上記課題に対し、どういった研修が重要か?どういう風に研修を広めると効果的か?といった議論はほとんどされていない

発表内容のエンジニアリング的な納得感

  • 新しいプラクティスを組織に導入する手法・事例として「Fearless Change」と「変革の軌跡」を参照
  • 実践した手法・結果について、Fearless Changeをベースに振り返る
  • 新しいプラクティスを組織に導入する手法として「Fearless Change」を参照
  • 実践した手法・結果について、Fearless Changeをベースに振り返る

発表内容の新しい価値とオリジナリティ

  • 組織に研修を広めていく際に効果的だった行動が、フェアレスチェンジとも合致していたことを示す
  • また、フェアレスチェンジのカバーしていない部分を、オリジナルのパターン”フェアレスブルドーザー”として提案
  • 組織に研修を広めていく際に効果的だった行動が、フェアレスチェンジとも合致していたことを示す
  • また、フェアレスチェンジのカバーしていない部分を、オリジナルのパターン”フェアレスブルドーザー”として提案

その手法はいつでも誰でも実践可能か

  • あくまで事例の紹介であり、手法の再現性を保証するものではない
  • ただし、手法の振り返りにフェアレスチェンジをベースとして用いることで、パターンランゲージが保証する範囲での再現性を担保する
  • フェアレスブルドーザーの再現性を担保するには、別途再現性をパターンなどで担保する必要あり
  • あくまで事例の紹介であり、手法の再現性を保証するものではない
  • ただし、手法の振り返りにフェアレスチェンジをベースとして用いることで、パターンランゲージが保証する範囲での再現性を担保する
  • フェアレスブルドーザーの再現性を担保するには、別途再現性をパターンなどで担保する必要あり

 

次回に続く

エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出しちゃった話1/3

モチベーション

 先日DevOps Days Tokyoというイベントで「人事がDevOps研修を作っちゃった話〜恐れ知らずのブルドーザー改革〜」という内容で、人事の担当者と共同発表した。これは、DevOps研修を作るにあたって壁となるコンウェイの法則を乗り越えるため、様々な部署のたくさんのエンジニアをブルドーザーのように巻き込んだ、という人事視点のちょっとしたカイゼン物語エンジニアの技術コミュニティで発表したものだ。

www.slideshare.net

 このブログエントリーでは、この発表が作られるまでのエンジニア視点のアナザストーリーを書いてみようと思う。ここに書く話が、まだエンジニアコミュニティで発表したことがないけど迷っている人や、身の回りのちょっといい話をどうやって育てていこうか悩んでいる人にとって、次のステップに進むためのヒントになったらいいなと思う。

身の回りのちょっとしたカイゼン物語を見つける

人事の相方をエンジニアコミュニティでの発表に誘ったら

 今回、ノリノリで発表してくれた人事担当の相方だけど、エンジニアコミュニティでの発表を最初に誘った時は、実はものスゴく後ろ向きの反応だった。「私はエンジニアじゃなくて人事だし、私のやってることなんて大したことないからエンジニアに話してもつまらない」と。(←これ、JaSST' 18 TokaiやDevOps Daysでのブルドーザー発表を見た人にとっては信じられない話かもだけどもw)

スゴイ研究者や偉いエンジニアじゃなくたって…

 「エンジニアコミュニティの発表ってスゴイ研究者や偉いエンジニアがするもの」って漠然と思っている人って多いよね。たしかに、スゴいエンジニアの、例えば5年後のエンジニアリングに変革をもたらすような話は面白い。AIを活用することで既存のQAの形を劇的に変えるようなイノベーションの話なんかは、僕も大好きだ。

 でも、「自分はスゴイ研究者や偉いエンジニアじゃないから」って理由で、エンジニアコミュニティでの発表をためらう必要はない。世の中のエンジニアコミュニティが一歩でも前に進む内容なら、実績とか立場とか関係なくどんどん世の中に発信した方が、コミュニティにとっても自分にとっても価値が生まれる

現場のちょっとしたカイゼンの話は特に価値がある

 特に現場のちょっとしたカイゼンの話は、多くの人から共感を得られるし、聞いてくれた人に課題解決のヒントをもたらすことがある。僕の中では、この人事視点の物語がたくさんのエンジニアたちからの共感を得られるって確信があった。エンジニアと人事という立場や手法の違いはあれど、チームをよりよくするためのカイゼンをアジャイルに回していくっていう本質は同じだからだ。

 だから、発表することに対してあまり自信がなかった人事の相方を一生懸命説得した。「この人事視点の話をJaSSTで話すことで、アジャイルやテスト自動化で苦労してるたくさんのエンジニアたちが、自分たちのカイゼン活動を見つめ直して新しい解決のアプローチを考えるきっかけになる」って。そうしたら、「なんか騙されている気がするけど…w」と言いながら、一緒に発表することを承諾してくれた。

色んな現場に色んなちょっとしたカイゼンの話が埋もれている

 今回、僕は人事視点のちょっとしたカイゼンをたまたま見つけたのだけれども、色んな現場にまだまだたくさんのちょっとしたカイゼンが埋もれていると思う。それは、もしかしたらあなたのチームにあるかもしれないし、あなたの隣のチームにあるかもしれないし、今あなた自身がやっているカイゼンかもしれない。そういう「ちょっといい話」を見つけるのってすごく大事だと思う。「でもこれはそんな大した話じゃないし」なんて尻込みせず、「世の中のエンジニアリングがちょっとよくなるかも」と、そんなちょっとしたカイゼンの話がどんどんエンジニアコミュニティで公表されたらいいなあ。

 

次回に続く

f:id:kokotatata:20190418091458p:plain

 

DevOps時代のテストエンジニア採用面接

背景

 社内外のテスト自動化チームの人たちと話すと、テスト自動化エンジニアの採用は難しいという話題がよく出る。どこのチームもテスト設計が出来て、自動化も得意で、CI周りの構築もやって、といったパーフェクトなテスト自動化エンジニアを求めているが、実際には採用はなかなか進んでいないようだ。

 このブログポストでは、このテスト自動化エンジニアの採用にまつわる問題を「候補者の得意領域、不得意領域の話を引き出す面接を意識すること」を軸に少し一般化し、僕自身が気をつけていることについて書く。

テスト自動化エンジニアの採用が大変な理由

多岐に渡るテスト自動化のスキルセット

 テスト自動化エンジニアの採用が大変な理由は、一言で言えば、DevOpsが当たり前の昨今では、多岐に渡るスキルセットを評価する必要があることだ。

 例えば、ソフトウェアテストの資格試験であるISTQBでは、ソフトウェアテストの「Core」のスキルとしてテストマネージメントテストプロセステスト技法ソフトウェア品質特性などを挙げられている。また、「Specialist」のパスとしてアジャイルテストテスト自動化エンジニアが示されている。

 これらに加え、XPやTDD、継続的デリバリーなどにみるアジャイルでのテスト自動化への考え方Jenkinsなどのパイプライン自動化DockerやKubernetesなどのインフラ自動化なども周辺技術としてある。

採用面接におけるありがちな罠

 はっきり言ってしまえば、これらの多岐に渡るスキルや知識を評価することは想像以上に難しい。候補者の得意・不得意なスキル領域について客観的な評価ができなかったり、うまく話が引き出せない可能性があるからだ。下記に採用面接における例を示す。

f:id:kokotatata:20190430092937p:plain

面接における認知バイアスの例

 この例での面接官のAさんのスキルをみてみる。スキル領域①〜⑤を通して特に苦手な領域もなく、特にスキル領域①で高いレベルを持っている。

 候補者のBさんとCさんのスキルセットをみてみる。BさんはAさんと同様のスキル領域①が得意だ。一方で、Cさんはスキル領域①は苦手だが、スキル領域③と⑤で高いレベルを持っている。

 この例の場合、Bさんの方がCさんに比べ評価されやすいと僕は考えている。認知バイアスがかかるため、Aさんは自分自身が高いレベルをもつスキル領域①を重視して評価しやすいからだ。人間は自分が努力をして手に入れたものに対して、より多くの価値を見出す傾向がある。そのため、自分自身の得意な領域と不得意な領域について、客観的な目で評価するのは難しい

 また、面接官は自分が得意な領域について、より多く、深く質問してしまいがちだ。プログラミングについて詳しい面接官は、ついついプログラミングについての質問をしてしまう。しかし、面接は面接官の得意な領域について質問する場ではなく、候補者に得意な領域、不得意な領域について話してもらう場だ。候補者から得意、不得意な領域な話を引き出せるように面接を組み立てる必要がある。

テスト自動化エンジニアの採用で気をつけていること

スキル領域を定義する

 異なるスキル領域について客観的に評価するためには、事前にテスト自動化エンジニアに求めるスキル領域とスキルレベルを定義することが必要だ。例えば、僕個人は

  • テスト要求分析スキル(機能要求、品質要求含む)
  • テスト設計およびテスト優先順位づけスキル(テスト設計、リスクベーステストなど)
  • プログラミングスキル(構造体、アルゴリズム、エラーハンドリングなど)
  • 自動テストの設計スキル(Keyword Driven Tesing, Data Driven Tesing, PageObject Patternなど)
  • 問題解決スキル(自動テストの保守性、Flakyテストなどの問題をどのように解決するか?)

をテスト自動化エンジニアに必要なスキル領域として定義している。事前にスキル領域を定義することで、質問や評価が特定の領域に偏るリスクを軽減できる。

 また、それぞれのスキル領域の得意なチームメンバーと、質問や回答についてのレベル感について合意しておくことも重要だ。前述のように、スキルAが得意なメンバーとスキルBが得意なメンバーでは、スキルAが得意な候補者の評価が割れやすい。事前にメンバー間でレベル感について議論しておくと、スムーズに結論を導き出せる。

面接の冒頭にチームを紹介

 候補者から、得意・不得意なスキル領域の話を引き出すためには、面接の冒頭でチームを紹介することも重要だ。募集しているポジションのチームがどんなチームで、どんなスキル領域が得意なテスト自動化エンジニアに来て欲しいかを丁寧に伝える。すると、候補者は面接の質問に対し、自分のスキルセットや今までの経験について的確にアピールできるようになる。

 例えば、「開発者しかいないチームでテスト専門スキルの高いエンジニアにチームに来て欲しい」場合、それを伝えれば候補者は今までの経験の中でも、特にテスト要求分析やテスト設計の経験についてアピールしやすくなる。

 単純にテスト自動化エンジニアのポジションと言っても、そのチームは様々だ。開発エンジニアとテストエンジニアが一緒のチームもあるだろうし、独立したテストエンジニアのチームもあるだろう。Scrumでバリバリやってるというチームもあれば、ウォーターフォールでやっているチームもある。また、もう既に何十万件のテストケースを自動化したチームもあれば、これからテスト自動化を始めるチームもある。

 自分たちのチームがどんなチームで、どんなエンジニアにチームに来て欲しいかを伝えることで、候補者もそのチームに対しよりポイントをついた話をすることができるようになる。

候補者の得意なスキル領域を引き出すオープンクエスチョン

 候補者の得意なスキル領域の話を引き出すため「あなたの得意なスキル領域はどこですか?」とダイレクトに質問する方法もあるが、一般的なオープンクエスチョンから候補者の得意なスキル領域へ質問をシフトしていくのもオススメの方法だ。

 例えば、僕はしばしば「あなたが今まで経験したバグの中で一番大変だったものを教えてください」というオープンクエスチョンをする。この質問の面白いところは、「一番大変」と感じる領域が候補者によって完全に異なることだ。そして、この質問の回答に候補者があげる領域は、本人が自信のある領域である場合が多い。

 バグを発見した苦労話を聞かせてくれるエンジニアは、テスト技法について自信があるだろう。バグの根本原因を特定した苦労話を聞かせてくれるエンジニアは、インフラが得意だったりする。バグ修正の苦労話を聞かせてくれるエンジニアはプログラミングに自信があったりする。

 エンジニアは大体みんなバグで苦労をした経験がある。そのバグに対して「大変」と感じる視点の違いを、一般的なオープンクエスチョンから引き出すことができる。

スキルレベルを判断するための質問

 候補者から得意・不得意な話を引き出した後には、それぞれのスキル領域についてのスキルレベルなのかを判断する必要がある。

  • 得意なスキル領域は実務で活用できるレベルなのか?
  • 不得意なスキル領域も、ある程度の知識はあるのか?

「知っている」ことと「出来る」ことには大きな差があるため、この違いを見極める必要がある

 僕がしばしば面接で実施するのは、異常系がごっそり抜け落ちている仕様に対してプログラムを書いてもらい、続けてそのプログラムのテストを実施してもらうというものだ。本来の目的は「異常系の仕様の抜け漏れを見つけてもらう」ことなのだが、そのことは候補者には隠した上で、2〜3行の正常系の仕様に対しプログラミングとテストを実施してもらう。

 プログラミング自体はシンプルなので5分程度で終わる。しかし、テスト駆動開発やエラーハンドリングなどのテクニックを使いこなすエンジニアは、ここで異常系の仕様がごっそり抜け落ちていることに気付く。また、テストの実施の最中に、境界値分析などを用いてテスト設計をすることで仕様の抜けもれに気付くケースもある。

 この問題は、こちらから特にスキル領域やテクニックの指定はしないので、候補者が普段どんなスキルを使いこなして業務を遂行しているのかを知るのに役立つ。特に、テスト駆動開発や境界値分析など名前くらいは知っているというエンジニアも多いが、そういうレベルではこの問題の仕様の抜け漏れを発見することはできない

 稀にプログラムを書く前段階ですべての異常系の仕様の抜け漏れに気付くエンジニアもいる。そういうエンジニアは数百人に一人にしかいないので貴重な存在だ。

 

まとめ

 テスト自動化エンジニアの採用戦略について「候補者の得意領域、不得意領域を引き出すこと」を軸にみてきた。テスト自動化エンジニアのポジションに必要とされるスキル領域は多いため、優秀なエンジニアの採用はなかなか大変だ。しかし、チームと候補者のスキル領域がうまくマッチすると、劇的にチームが改善される可能性のある重要なポジションだ。

個人の経歴2018年バージョン

講演・執筆活動

カンファレンス講演等(日本)

カンファレンス講演等(国外)

執筆関連

勉強会での発表

勉強会企画

書籍関連・インタビュー・ブログ記事など

資格

  • JSTQB Advanced Level テストアナリスト (2017)
  • JSTQB Advanced Level テストマネージャー (2015)
  • JCSQE 初級 (2014)
  • JSTQB Foundation Level (2014)
  • プロダクトオーナー(2014)

JaSST'18 Tokaiが楽しかったw話

モチベーション

 このブログエントリのモチベーションは、ソフトウェアテスト#2 Advent Calendarを完走することです。今現在(2018年12/10)6つの枠が空いてるので、それぞれの空き日当日になっても空白だったら、どんどん埋めてきます。

qiita.com

JaSST' 18 Tokai

 2018/12/07 (金)に愛知県刈谷市で開催されたJaSST' 18 Tokai講演者として参加してきました。カンファレンスは、講演としては平鍋さんの基調講演我々の特別講演があり、その他にもポスターセッションやチュートリアルなど盛りだくさんで、最後には参加者同士で意見交換する情報交換会もありました。

 このブログエントリでは、JaSST'18 Tokaiで楽しかったところを挙げていくことにします。

JaSST' 18 Tokaiの楽しかったところ

楽しかったところ①:オープニングスピーチの委員長

 オープニングスピーチの委員長のスピーチがエネルギーいっぱい、駄洒落いっぱいで面白かったです。いろいろ話を聞いてみると、委員長のスピーチはJaSST' Tokai名物で毎年恒例のものらしいです。

 その場のノリとアドリブで盛り上げている感じのスピーチなのですが、後で「実は、そういうスタイルのスピーチに見えるように、前日カラオケで練習している」というお話も伺いましたが真偽のほどは分かりません。

èªå代æ¿ãã­ã¹ãã¯ããã¾ããã

楽しかったところ②:平鍋さんの基調講演

 平鍋さんの基調講演でのメッセージで印象的だったものとして

  • プロダクトだけでなく顧客も開発するしチームも設計して育てる
  • アジャイル開発では、ウェブサービスは内製化が進んでるし、ベンダーはアジャイル開発拠点に参加するようになる
  • プロジェクトの見える化/透明化が重要。カンバンなど。

があります。特に最初の「顧客も開発する」については、きっとアジャイルの導入やチームへの新規ツールの導入、またOSSの開発など、チームや市場にどんなニーズがどれくらいあるか分からないものについては、みんなアジャイルにやってくのがいいのだろうなあと思いました。

 あと、後で平鍋さんから「10年間同じ内容で講演している」という話を伺いまして、なるほどこういう情熱を持っている方が持続してメッセージを発信し続けることで日本のアジャイルは発展してきたのだなということを肌で感じました。

 平鍋さんの基調講演の内容については、平鍋さん自身がブログを書かれてますのでそちらもご参照ください。

anagileway.com

楽しかったところ③: 特別講演

 特別講演では、この半年間一緒にDevOps研修を育て上げてきた吉田さんと一緒に、アジャイルやテスト自動化導入の文化的・技術的な事例を紹介しました。

www.slideshare.net

f:id:kokotatata:20181210150955p:plain

アジャイルにおけるテスト自動化の役割

 講演内容についてはスライドを参照いただくとして、ここではtwitterでの感想を紹介します。

 

 

 

  一緒に発表した吉田さん。実は社外発表は初めてだったのですが、ブルドーザー的なパワーで全部かっさらっちゃいまして、その後の情報交換会などでも吉田さんの講演内容の話題で持ちきりでした(笑)

楽しかったところ④: 情報交換会&打ち上げ&飲み会

 情報交換会、打ち上げとその後の飲み会とすごく盛り上がりました。このあたり、シンポジウムの主催者の方達が、会を一方向のものにしないで、双方向のものにしようという気遣い・努力がすごいなと思いました。

 やっぱりこういう社外のシンポジウムでは、普段お話する機会がない方たちといろいろお話できるのがいいですね。少しビックリしたのが、東海の方だけでなく東京や関西から参加されている方がいらっしゃったり、あとエンジニアだけでなく人事の方なんかも参加されてました。この辺、JaSST' Tokaiは懐が深いシンポジウムなんだなーと感じました。

 あと、シンポジウム後の飲み会では平鍋さんとたっぷりお話する機会と、素敵なカード(ハガキじゃないよ)を頂きました。ありがとうございます!

f:id:kokotatata:20181210200449j:plain



楽しかったところ⑤: JaSSTで「アジャイル」という単語を使ってもいいんだと確信した

 完全に個人的な偏見ですが、JaSSTには長らく「アジャイル」をキーワードとして使うことに対する暗黙の禁句的ななにかがあったように思います。完全に個人的な偏見ですが、JaSSTで「アジャイル」というキーワードを出すと、参加者から拒絶反応が返ってくると思ってました。なので2014年に初めてJaSSTで発表した時も、出来るだけアジャイルという言葉を使わずに自分たちの取り組みを説明することに苦心しました。

 ですが今年2018年、「アジャイルとテスト自動化について」前半にはJaSST'18 Tokyoでパネルディスカッションの依頼を頂き、後半には今回のJaSST'18 Tokaiで特別講演する依頼を頂き、流れは変わってきたなあと。

 特に今回、講演後の情報交換会で、参加者のみなさんもアジャイルの導入を始めたりもうすでにいろいろと導入してるお話を聞きました。話の方向性として「アジャイルめっちゃ楽しい」よりも「アジャイル大変」成分が多めなんですが、それでもみんなアジャイルについて話したい、話すことが好きなんですね。

 

最後に

 今回JaSST' 18 Tokaiに参加させて頂きとても楽しかったです。お呼び頂きまして、企画者のみなさまありがとうございました。インタラクティブな会を作ろうとしているのがすごくよくわかりましたし、あと日本の東海地方には東海地方独自のアジャイルがあるんだということが発見でした。ぜひ、また参加してみたいシンポジウムの一つですね。

f:id:kokotatata:20181217183911p:plain

f:id:kokotatata:20181217183924p:plain