テストエンジニアのモチベーションを上げるにはどうすればいいか（前編） JaSST'14 Tokyo

2014年3月24日

ソフトウェアの開発に関わるエンジニアの中でも特殊なスキルを持つテストエンジニア。そのテストエンジニアをマネジメントする上で、彼らのモチベーションを上げるにはどうすればいいのでしょうか？

ソフトウェアのテストに関わるエンジニアが集まる国内最大のイベント「ソフトウェアテストシンポジウム 2014 東京」（JaSST'14 Tokyo）が、3月7日と8日の2日間、東洋大学白山キャンパスで開催され、その基調講演に英国コンピュータ協会のStuart Reid（スチュアート・リード）氏が登壇しました。

リード氏はソフトウェアテストの国際標準であるISO/IEC/IEEE29119シリーズを作成している会議体の議長を務め、また英国コンピュータ協会のソフトウェアテスト研究グループの長でもあります。ソフトウェアテストの分野で国際的にも著名なリード氏の講演を、ダイジェストで紹介します。

テストエンジニアのモチベーション

Testing Solutions Group CTO、Stuart Reid博士。

私がこの業界に入って気がついたことは、成果を上げるためには技術的な内容よりも、人にどうモチベーションを与えるかといったことのほうが重要だということです。

モチベーションを上げることで仕事はもっと面白くなるはずですし、チームをマネジメントする立場の方にとって、チームのモチベーションを上げることは有益なことです。モチベーションが上がることで生産性も向上しますし、すばらしいエンジニアに長期間その会社で働いてもらえることでしょう。

ではモチベーションとは何によって上がるのでしょうか、とりわけ、テストエンジニアのモチベーションというのは何によって左右されるのでしょうか。今日はそのことについての調査結果について紹介しようと思います。

モチベーションの定義は複数ありますが、私はこの赤字で書かれていることが重要だと思っています。つまり、人々が継続的に興味を持ち、仕事を続けていきたいというモチベーションには、内部的要因と外部的要因があります。

50年前、モチベーションは「アメとムチ」、例えばお金だったり、気にくわない仕事に異動させるといった脅しと結びつけられて考えられていました。しかし学者はこのモデルではモチベーションはうまく働かないことに気づき始めました。

お金をたくさんあげると短期的に生産性は上がるかもしれませんが、そのあと生産性は下がってきます。だから生産性の向上に反しているのですが、テストエンジニアのマネージャの多くはこのモデルを使っています。

なぜかといえば、テストエンジニアのモチベーションを上げるための適切なアプローチがまだ分かっていないからです。だからテストエンジニアがマネージャに昇格しても、チームのモチベーションを上げる方法が分からないのです。

モチベーションとは単一の要素だけでコントロールできるものではありません。何かを変えれば上げられる、というものではありません。例えば、マネージャがテストエンジニアをどう扱うか、作業環境がいいか悪いか、朝起きて気分が乗らない日もあるでしょうし、いろんなことから影響を受けます。

そこで私たちは、モチベーションに関する調査をしました。40問の紙かオンラインでの質問形式で、世界中の多くの場所から600以上の回答をもらいました。

回答者はヨーロッパとオーストラリアが中心ですが、アジア、北米からも回答がきています。

回答者の組織で一番多いのはIT企業、もしくはITではない企業のIT部門のテストエンジニアです。

職種は、テストアナリスト、テストマネージャが多く、テストリード、テストコンサルタントなどもいます。

例えば、テストアナリストはテストの実行（Execution）、テストデザイン（Test Design）などが仕事の中心で、探索テスト（Exploratory）は46％しかしていません。

テストリードは役職の範囲が広い、テストマネージャとアナリストの両方の仕事をやっているようです。テストリードはレビューが多く、テストの部門長（Head of testing）は、面積が一番小さくなっています。

このデータから考えられるのは、ある役職から昇格するときには、まったく違う技能が要求されるということです。テストアナリストからテストリードに昇格すると新しい役割が期待され、テストリードからテストマネージャに昇格しても同様です。役割を変えるには、その前に教育が必要なのです。

ちなみに、開発ライフサイクルはこのようになっています。

私の経験からしても、テスト関連の本当の状況がここに表れていると思います。

モチベーションの理論はいくつもある

モチベーションの理論は70年前からさまざまなものがありますが、注目したいのはこの3つです。

Motivation-Hygiene Theory（動機付け衛生理論）、これは励みは人によって違うということ、Job Characteristics Model（職務設計理論）は職務を設計するときに生産性やモチベーションが上がるように作っていこうというもの、そしてもっとも新しい理論は2010年のダニエル・ピンクの「モチベーション3.0」。

Job Characteristics Modelを提唱したHackmanとOldhamが1975年に示したMotivation Potential Score（MPS）がこれです。

一番上の「Skill Variety」（V）は、職務の多様性。例えば車の生産ラインでヘッドライトを組み込むだけの仕事には多様性はなく、繰り返すだけです。そうではなく毎週やることが違うのであれば多様性があります。多様性がある方がモチベーションが上がります。

二番目は即無の完結性。例えば何かが完成するのに関わるとモチベーションが上がります。車の生産ラインなら、ライトを組み込むだけの仕事よりも、車を作る工程の最初から最後まで関われればモチベーションが上がります。

三番目は仕事の重要性。もしあなたが脳外科医なら、その仕事が非常に重要だということはすぐに分かります。しかし車のライトを組み込むだけの仕事は、どれだけ重要かは分かりません。

次が自主性とフィードバックです。次にどんな仕事をするのか自分で決められるなら自主性が高く、上司から指定されるだけなら自主性は低く、自分の責任はそこにはありません。

フィードバックは、上司から「これはいい仕事だった」と評価をもらえるか、あるいはモバイルアプリケーションを作ってたくさんダウンロードされればフィードバックが得られて、次のアプリを作ろうというモチベーションにつながるでしょう。

こうした要素を1から7の値にして式へ入れると、MPSのスコアが得られます。スコアは1から343までで、通常は60から200くらいのスコアになります。

相関関係について予備知識として説明しておきましょう。ある要素を変更するともう一方の要素も同じ方向に変わるとすれば、相関関係は1です。モチベーションを上げようとするとき、つねに誰に対しても同じように効果があれば、その方法とモチベーションの相関関係は1になるわけですが、やはりモチベーションというのはいろんな要素があり、誰にも同じように効果があるとはいかないので、ある方法とモチベーションの相関関係が1になることはありません。

さて、調査でテストという仕事にモチベーションを持って取り組んでいるかを聞いたところ、モチベーションを持って取り組んでいるというひとが相当いました。この分布は業界や地域が変わってもほぼ同じです。

このモチベーションの自己評価と、MPSによる評価の相関関係を見てみると、0.4という相関を得ることができた。これは強い相関があるといえ、MPSの評価はモチベーションを上げるための予測に使えそうだということが分かりました。

MPSの要素を見ていく

MPSの要素をテストエンジニアの役職ごとに見ていきましょう。それによってモチベーションを上げるためのよりよい方法が分かります。要素の中にはやる気をそぐ要因があることも分かります。また要因ごとに役職に対して異なる影響を与えていることも分かります。

例えば、同僚からのフィードバックは一般に励みになるが、デベロッパー／テスターの人たちは、同僚からのフィードバックはやる気をそぐと答えているのです。

なぜデベロッパーの人たちは同僚からのフィードバックでモチベーションが下がるのかといえば、おそらく「ここにバグがあるよ」と指摘されたくないと、むしろそんなフィードバックはいらないと思っているからではないでしょうか。でも、もちろんバグが見つかったら指摘せざるを得ませんよね。

この結果をアジア圏と世界全体とで比較してみましたが、結果に大きな違いはありませんでした。つまり、多国籍の人が集まるプロジェクトでも傾向は同じだということです。

業務の多様性はデベロッパーのモチベーションを下げる

業務の多様性についてはどうでしょうか。一般には業務に多様性があったほうがモチベーションが上がると思われていますが、デベロッパー／テスターは多様性はむしろモチベーションを下げています。デベロッパーはたった1つのことに集中したいということです。

これも推測ですが、ほとんどの人はプログラミングに集中したいと思っているのでしょう。つまり、この役職の人のモチベーションを上げるには、いろんなことをさせるのではなく集中させる。一方でテストアナリストやテストリードなどテスト専門の役職の人は幅広い多様性があったほうがいいということになります。

テストコンサルタントは重要度でモチベーションが上がる

次は重要性。ここでもデベロッパーのみなさんは違っています。同僚やプロジェクトに影響を与えるような重要な仕事はモチベーションが下がってしまうと。つまり部屋に閉じこもってプログラミングだけをしていたい、ということでしょうか。しかもこの結果の統計的有意性は非常に高いです。

一方、テストコンサルタントは結果の影響度が大きいのであればモチベーションが上がるということになっています。

アジアと世界との比較では、アジアでは仕事の重要性が大きくなるとモチベーションが上がっています。アジアの人はプロジェクトがうまくいくかどうか心配しているということでしょう。

アジアの人はタスクを終えることへのモチベーションが高い

次はアイデンティティ。仕事に完結性があるかどうか。テストの部門長はここがマイナスになっていますが、複数のプロジェクトを抱えていると1つのプロジェクトの完結性に気をとられたくなくてマイナスになっているのではないかと思います。

テストコンサルタントは、タスクの完結性でマイナスになっています。これはアドバイスするだけで、あとはテストマネージャやテストリードに任せるので、最後まで自分が完結するのを見守る必要はないということでしょう。

デベロッパーの人がタスクを完結するのを見たくない、という理由はちょっと想像がつきません。昨日と同じことを明日も明後日も続けたい、という風に思っているようです。

アジアと世界を比較すると、アジアの人はかなり異なっています。とにかくタスクを終えるということに強くモチベーションが働いているようです。つまり、なにかのタスクを終える前にほかの仕事にとりかからせるということをしてはいけない、ということでしょう。

アジアでは勤務時間と仕事の進め方が大事

自主性について。テストリードはやることがもっとも多い役割の人たちで、テストプロセスをとにかく進めなければならない。テストアナリストが何かを作るとテストリードはそれをレビューして、とにかくレビューに時間を使って、フィードバックをできるだけ早くするという役割。そんなにレビューの方法があるわけではないので、次にすることが選べてもそれほどモチベーションがあがらないのではないでしょうか。