NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'19 Kansai
HOME > 活動報告 > イベント報告 > JaSST'19 Kansai
2019年7月5日（金） 於 大阪市立住まい情報センター（大阪府大阪市）
JaSST'19 Kansai が、2019年7月5日に大阪市立住まい情報センターで開催された。今年も例年通り会場は満席で、各セッションにおいては多数質問が飛び交い、また、終了後の情報交換会においても、講演者への質問は絶えることはなく、参加者の熱意を随所に感じた。
オープニングセッションでは、実行委員長の江添氏と、実行委員の岩田氏が開催概要やテーマなどを説明されていた。
今回のテーマは"テストエンジニアの働き方"である。ソフトウェアテストは基本的にチームで実施するものだが、メンバー一人一人はスキルも違えば、教育方針も違う。また、近年では会社で働かずに遠隔地で仕事をする、いわゆるリモートワークが増えてきているなど、働き方に多様性が出てきている。それらに対し、会社やマネージャーは対応しなければならない。本イベントで、そうした対応すべき課題の解決策を少しでも見つけて、持ち帰ってほしい。
冒頭、石原氏は「今回の話は、"ツールがあればすべて解決！"という派手な話ではない。どのようなソフトウェアテストでも必ずつきまとう、ソフトウェアテストのプロジェクト管理の問題や、その問題を限られたリソースの中でどのようにして治めていくかについての話をする」と述べた。
具体的な問題としては、以下のような悩みである。
テストプロジェクト管理における問題点として、テストプロジェクトマネージャーが四面楚歌な状態になっていることがあげられる。プロジェクトマネージャーからは圧力がかかり、開発マネージャーとは敵対し、限られたリソースの中でやりくりし、それによりテストチームに負荷をかけ疲弊させ、結果として成果物の品質が悪くなり、お客様からの不満が発生する。これらの問題を一人で全て抱え込んでしまうと、途端にパンクしてしまう(石原氏は、一人で全て抱え込もうとすることを、スーパーマンになろうとする、と表現していた)。
このような状態になるのは、テストプロジェクト全体を見渡せていないからであり、全体を俯瞰した"計画立案"と"実施管理"が不十分であることが理由である。
テスト運営をする前に確認するポイントは、以下の2点である。
リスク管理については、重大度と可能性を3段階ずつに分け、例えばそれらを足し合わせて4以上だったら対処する、3以下は対処しないなど、シンプルに管理していくことをお勧めする。
ソフトウェアテスト全体計画を5W2Hの形で表現すると、以下のような形になる。
石原氏が経験してきた中で、失敗したプロジェクトや、やりくりして窮地を脱した事例などが紹介された。APIだけで1000以上あり、SIerを10社配置していたプロジェクトにおいて、開発設計書のレビュー項目を整理した事例や、プロセス標準がないプロジェクトに参画し、ドラフト版の簡易的なプロセス標準(1人日で作れるもの)を作成し、運用した事例などがあげられた。
石原氏はいずれの事例でも、"keep it simple stupid(KISSの原則)"を軸に改善していることを強調していた。
テストプロジェクトマネージャーは、自分が頑張るのではなく、人にやってもらうことを目指す。また、計画、モニタリングとコントロール、振り返り、改善を小さく繰り返し回していき、一歩ずつ確実に向上させていくことが大切である。
石原氏が冒頭に「本来8時間以上かけて話す内容」と述べていた通り、非常に密度の濃い内容であった。筆者は、テスト全体計画やテスト観点リストなどを、なるべくA4一枚で表現できるように作る、といった話が印象的だった。シンプルであればあるほど、余分な情報が淘汰されていき、純粋に伝えなければならないものだけ残る。また、見る側の人間にとって必要情報だけ載っているため、認識の齟齬が発生しにくくなる。今後の仕事において、これらのことを意識し、できるだけシンプルな資料作りを心がけようと思った。
本セッションは、これからテストエンジニアとしてキャリアを築いていく人や、若手を育成する際にどのように導いていくかを考えている人向けの内容である。最初は植月氏のエンジニアとしての経歴が紹介された。
テストエンジニアは様々なキャリアパスに繋がっている。植月氏の認識している範囲では、以下のような役割へのキャリアパスが存在する。
また、大手IT企業の求人募集要項から、テストエンジニアに求められている重要なスキルをピックアップしてみると、以下のようなスキルがあげられる。
目指すべきキャリアパスと、それに伴うスキルを身に付けていく必要がある。
自らが成長するためにできることとして、植月氏は4点あげている。
1. 仲間をみつけよう
社内外のエンジニアコミュニティなどに参画し、共に成長できる仲間を見つける
2. 師匠(メンター)を見つけよう
向かうべき方向を指し示し、学ぶ力を呼び起こしてくれる師匠を、会社内や社外のコミュニティなどで見つける
3. 優秀な人と仕事をすることにこだわろう
環境が人を作る。自分、またはチームの能力を引き上げる何かを持っている人と仕事ができるようにする
4. 自分の実力を測ってみよう
即席でテスト設計をする、資格試験やコンテストに挑戦するなどして、自らの実力を測る
昨今の日本の情勢としては、グローバル企業が台頭し、国内経済が縮小傾向にある。また、ネット上のコンテンツの25%は英語で作成されており、英語話者は全世界で15億人以上いる。したがって英語能力はあった方が良い。
英語能力を向上させるための、銀の弾丸は存在せず、地道に継続的に勉強することが大切である。継続することによって英語能力は必ず身につくため、モチベーションを維持する工夫をするとよい。
筆者は現在マネージャーとしてメンバーを抱えているため、植月氏の話はメンバーのキャリアパスを考える上で非常に参考になった。特に、自らを成長させるための4つの観点は年齢や役職などに関係なく共通的に使える観点であると感じた。
熊川氏の会社では、ソフトウェアテストに関する研修を講義形式と演習形式を1日ずつかけて実施している。研修後のアンケートによると、満足度も高い。しかし、現場の状況を見ると、それらの知識が十分に活かされていないことが判明した。講義形式や演習形式だと、"失敗から学習し、挑戦することができない"、"Knowing Doing Gap：知っていてもできない"状態に陥ってしまいがちになるのである。
熊川氏は、知識を得るだけでなく、実践する力も得られるような教育方法を考えた。その結果、"意図的にバグを混入させたソフトウェアを使用してテストの一連の流れを体験させる研修"を考察し、実践してみることにした。学習内容は"探索的テスト"に関するものとする。
まず初めに、知識としての講義・演習を行い、探索的テストに関する基礎知識を教え込む。その後、バグの埋め込まれたアプリを使ったテストをグループワークで実践する。一度実施した後、内容を振り返り、誤りや改善方法を知り、再度テストを実践する。そして、最終的な振り返りを行う。対象となるアプリケーションは、Excelマクロで作成された家計簿システムとした。作成する際は、作り込むバグから考えるのではなく、学習させたい技術で見つかるバグを埋め込むために熊川氏自らが探索的テストを行い、その観点からバグを作り込んでいった。
学習を効果的にさせるポイントとして、答えを簡単には教えないことを意識した。また、身につけさせたい技術の考え方や、陥りがちなアンチパターンをチェックリストで確認させるようにした。そうすることによって、受講者は自らが思っている以上に探索的テストの奥深さに気付く(ギャップが生まれる)。
研修の検証には、カークパトリックの4段階モデルを活用した。
Level1:反応
- 結果：満場一致で"役に立った"
Level2:学習
- 結果：習熟度のアンケートを取った結果、受講前と受講後を比較すると、受講後の数値が高くなった。
Level3:行動
- 結果：発見難易度の高いバグの摘出数に関する変化を見たところ、受講者の半数以上に効果がでていることがわかった。
また、受講状況をモニタリングしたところ、発言内容が講師の考えと一致するようになるなどの変化も確認できた。
Level4:結果
- 結果：受講後、実際のプロジェクトを用いて4人のテスターをモニタリングしたところ、1セッションあたりに検出したバグの量が増加した。
結果はおおむね理想に近いものが得られた。課題として感じていた、"Knowing Doing Gap"を埋めることができた。二次的な効果として、技術の普及展開にも役立っている。今までは自分が講師として各部署を回って研修を行っていたが、本コンテンツを実施したい部署に対し、学習用動画とコンテンツキットを渡すだけで、自分がその場にいない状態で研修を実施させることができるようになった。今後は探索的テスト以外についても、学ばせたいコンテンツに対して拡大させていきたいと考えている。
熊川氏も講演中にコメントしていたが、他の会社でも応用可能な研修方法であるといえる。もちろん研修の題材やコンテンツの作成などは容易ではないが、会社としてやるだけの価値はあると感じた。
自宅で働く在宅ワークや、モバイル端末を活用した働き方、シェアオフィスやサテライトオフィスを利用することなどである。今回は在宅ワークの話を中心に議論する。
子育て、介護、通院、趣味活動や社外活動と仕事のバランシングなど、柔軟な働き方ができる。地方の勉強会に参加し、日中は現地のホテルで仕事をするなども可能。
リモートワークを導入してみたが取りやめる企業も増えてきている。難しさの要因としては、プライベートと仕事の境界が曖昧なため働きすぎてしまいがちになったり、情報を自ら取りに行くような自主性が求められたりすることがあげられる。難しさを突き詰めると、リモートワークというよりは、コミュニケーションは難しいともいえる。
リモートワークでは同期的なコミュニケーションが難しい。それを克服するために、道具（Eメール、電話、チャット、テレビ会議など）をうまく使う必要がある。道具にはそれぞれ特性があるため、それらを理解することが不可欠である。例えば、チャットなどでは、自分の書いた文章がログとして残り続けることや、表情などのノンバーバルな情報が欠落する点などがあげられる。
テストエンジニアがリモートワークをすることは、できるが、難しさもある。検証端末を自宅に持ち帰れるか、テストデータに自宅からアクセスしてよいかなどのセキュリティ面や、業種によっては特殊な設備が必要になるなどが要因としてあげられる。また、テスト中、知らない間にデプロイされていたり、テストデータが消えたりするなど、オンサイトでは起きにくい問題も発生する可能性がある。
相性のよい仕事もある。例えば、テクニカルサポートや、出荷済み製品をターゲットとしたテクニカルドキュメントの作成など。また、社内のセキュリティ条件などが揃っており、ネットワーク経由でテスト可能なテスト対象などであれば、テスト作業は可能である。
テストエンジニアにリモートワークは非常に困難であると、筆者は考えていた。それは粕谷氏があげているようなセキュリティ面の条件などがあるからである。しかし、分野によってはできる環境も整ってきており、テストエンジニアがリモートワークをするために必要な要素は何か、という、やるためにはどうすべきかの視点で考え直してみようと感じた。
あっという間の1日間だった。先にも記載した通り、筆者は現在マネージャーの立場であるため、自らのチームや、会社全体の働き方に寄与できるものを多く持ち帰ることができた。
東京以外の地域のJaSSTは初参加だったが、終了後の情報交換会などでは、講演者へ気軽に質問でき、講演内容をより深く理解することができた。
これからますます働き方の多様性が企業に求められる時代になってくる。土台作りには多くの時間が必要になるため、今からでもできることを小さく一歩ずつ確実に積み重ねていくことが大切であると感じた。
記：白川 亮太