この記事は

この記事は、2年ほど勉強して考えてきたQAの心理学について、現時点で私なりにまとめられる範囲で、ふんわりまとめてみたものです。

長くなってしまったので、記事を前編・後編の2つに分けました。今回は後編です。

前編を未読の方は下のリンクからどうぞ。↓

結論を先に

前編でもお見せしましたが、QAの心理学を下の表のようにまとめています。

＜前編＞
・バグチェックの基礎心理学　→　一般システム論　＋　認知心理学
・バグチェックの応用心理学　→　認知バイアス　＋　デザイン原則
＜後編＞
・QAマネジメントの基礎心理学　→　多様性　＋　社会心理学
・QAマネジメントの応用心理学　→　探索的テスト　＋　フロー体験

今回は、後編です。QAマネジメントについての内容を取り上げたいと思います。

マネジメントとは

「マネジメント」という言葉は、「管理」と翻訳されています。

ところが、経営学者として有名なピーター・ドラッカーの著書「経営の真髄」を読むと、

・上司をマネジメントする

という章があります。

これを「上司を管理する」と翻訳してしまうと、主従が逆なので違和感があると思います。

違和感を覚えながら内容を読み進めたのですが、途中で、きっとこれは「管理」ではなく「関与」と翻訳する方が、ドラッカーの言いたいニュアンスに近いのだろうなと思いました。

「上司に関与する」なら違和感がありません。

そして、マネジメントという言葉を「関与」に置き換えて、QAのマネジメントについて考えてみました。

QAは、「接着剤」として多くのステークホルダーに関与する職業です。

だから、業務量的にマネージャーほど関与がメインではない現場従業員も、マネジメントの知識はあった方が良いのではないかと思いました。

労働者としての分類

さて、マネジメントについて学ぶために、まずは「QAは労働者として何に分類されるのか」を考えます。

労働者としての分類にあたりをつけることで、QAがどのような状態に置かれやすいかを考えられるようになります。

この記事では便宜的に、下の図のようにふんわり分けることにしました。

まず「労働者」という大カテゴリーを作りました。

「労働者」を、「知識労働者」と「肉体労働者」という２つの中カテゴリーに分けました。

「知識労働者」を、「IT従事者」と「IT以外」という小カテゴリーに分けました。

「IT従事者」を、「QA」「企画」「開発」という最小カテゴリーに分けました。

つまり、並びとしては「労働者＞知識労働者＞IT従事者＞QA」となります。

QAが学んでいく労働者リテラシー

上述した分類を眺めていると、QAエンジニアが業務を通じて学んでいく事になる労働者としてのリテラシー（知識と能力）は、下の図のように、基礎から応用へ積み上げるように考える事ができると思いました。

１、労働者リテラシー
２、知識労働者リテラシー
３、IT従事者リテラシー
４、QAリテラシー

数字の昇順に、長く役立つ抽象的な基礎知識から、すぐに役立つ具体的な応用知識へと変わって行きます。

それぞれ、順に概要を説明します。

1.労働者リテラシー

労働者リテラシーとは、あらゆる労働環境に適用できる、最も汎用性の高い知識と能力です。

「法令遵守・道徳・マナー」など、所属するコミュニティの「習慣、伝統、文化、暗黙の了解」を把握しつつ、世の中の変化の流れに合わせて、「包摂、尊重、創造、革新」を取り入れていく姿勢を身につけていきます。

私が読んだことのある書籍の中では、下記の２冊が特に役に立ち、おすすめできると思いました。

・デール・カーネギー著「人を動かす」
・エイミー・エドモンドソン著「恐れのない組織　「心理的安全性」が学習・イノベーション・成長をもたらす」

2.知識労働者リテラシー

知識労働者リテラシーとは、「1.労働者リテラシー」を踏まえつつ、個性を尊重して人間らしい創造性を発揮することで生産性を高めようとする姿勢と、それを実現するための知識です。

一昔前の薄利多売型ファーストフード店のアルバイトのように、業務を徹底的に標準化することで人を交換可能な歯車として扱う場合は、これとは真逆の姿勢という事になります。

私が読んだことのある書籍の中では、下記の２冊が特に役に立ち、おすすめできると思いました。

・ピーター・ドラッカー著「経営の真髄　知識社会のマネジメント」
・ロザベス・モス・カンター著「企業のなかの男と女　女性が増えれば職場が変わる」

3.IT従事者リテラシー

IT従事者リテラシーとは、「2、知識労働者リテラシー」を踏まえて、どのように考え、環境を作り、振る舞えば良いか、ITの現場に特化した具体的な知識です。

例えば「静かに集中できる環境づくり」や「品質至上主義で生産性の高いチームづくり」などが該当します。

私が読んだことのある書籍の中では、下記の２冊が特に役に立ち、おすすめできると思いました。

・トム・デマルコ/ティモシー・リスター著「ピープルウェア　ヤル気こそプロジェクト成功の鍵」
・ジェラルド・ワインバーグ著「ソフトウェア文化を創る１　ワインバーグのシステム思考法」

４.QAリテラシー

そして、4つ目のQAリテラシーが、この記事で考えていく内容です。

リテラシーの抽象度の高さは、数字の順番通り「1>2>3>4」なので、1〜3で学べることが4を考えるための基礎（土台）となります。　

1〜3で学んだ内容から心理学に関連するものを抽出し、QAでどのように活用されているかを考えます。

QAマネジメントの基礎心理学

上述のような分類を踏まえて、１〜3のリテラシーを学びながら、QAの参考書にも同じように書かれている「心理学に関連する内容」を抜き出す作業を行いました。

その結果、次の2つが特に重要だと思いました。

・多様性
・社会心理学

それぞれ、概要を説明します。

多様性（理想）

テスト設計やテスト実行は、テスト技法だけ知っていればできるというものではありません。

QAの能力は、ざっと考えてみただけでも、少なくとも下記の7つに分解できます。

・テスト技法
・ドメイン知識
・プロダクト経験
・デザイン知識
・ITリテラシー
・マネジメント知識
・統計知識、データ分析力

どれかに偏ったチーム編成は避けるべきです。

全員が新卒採用からエリートを集めたQAチームもよくありません。認知バイアスが似通ってしまうからです。

理想としては、年齢層が多重で、様々なバックグラウンドを持った各分野の専門職が、お互いの強みを活かし弱点を補強しあうような、多種多様な人員構成が望ましいです。

例えば、

・テスト技法　→ ISTQBやIVECの資格保有者
・ドメイン知識　→　ターゲットとなる業界での業務経験や有資格者
・プロダクト経験　→ ユーザーサポート経験や営業経験者
・デザイン知識　→ webデザイナー経験やフロントエンド開発経験者
・ITリテラシー　→ 開発やインフラ管理経験者、セキュリティ関連業務経験者
・統計知識、データ分析力　→ データサイエンティストや統計学の資格保有者

上記のような専門職や各分野の資格保有者の集まりで、各々にマネジメント知識がある状態が理想です。

お互いの得意分野について勉強会などを開催して共有し、「T字型」や「ダブルメジャー」などと呼ばれる人材を育成します。

このように、多様性のあるチーム状態を、心理学用語では「同質性が低い」と言います。

この、ややネガティブな言い回しが、すなわち”現実を見る”ということです。

現実を見よう

上述のような理想的なQAチームを最初から作れる会社は稀です。

もしあるとすれば、医療機器のようなハイセーフティを担保しなければならないプロダクトの場合ではないでしょうか。

医療機器メーカーであれば、おそらく最初から強い権限と十分なリソースがテストチームに与えられるのではないかと想像できます。

しかし、ハイセーフティを扱わない多くの企業（特にベンチャー）では、限られたリソースの中で、まずは製品リリースを優先させるために開発に集中投資し、顧客リストを集めるために営業やマーケティングに経営陣の関心が向くので、品質は二の次であり、テスト専門チームの発足が後回しになりがちです。

製品が無事初リリースを迎え、ある程度軌道に乗ってくるとユーザーからのバグ報告やクレームが相次ぐようになり、せっかく営業が頑張って受注してもすぐに顧客が離れるようになってしまうので、そこに来てようやく品質にも目を向けるようになり、テストチームの発足を検討し始めます。

テストチームのトップには、既存の従業員から信頼できる人を当座は選ばざるを得ないので、QAの知識も現場経験もほとんどない人物が任されるかもしれません。

そのような人物が、これから採用や外注でジョインするQAエンジニアをマネジメントしていくことになります。

ありがちなパターンとして、例えば、「テストチームのトップが開発担当から選抜された場合」で考えてみましょう。

トップが部下と接する時に、開発経験のあるQAは自分の言葉で話が通じるので信頼や高評価を得やすく、開発未経験のQAには話が通じるようにわざわざ簡単な内容に言い換えたり、周りくどい説明をしなければならないので、信頼や高評価を得にくいという状況になります。

これを心理学用語で説明すると、

・開発経験のある上司は、同じように開発経験のある同質性が高い部下に共感しやすく、厚遇する傾向にある
・逆に、開発経験のない同質性が低い部下には共感できる点が少なく、軽んじるつもりはなくても無自覚に軽んじ、冷遇してしまう傾向にある

となります。

不遇だと思えばすぐに見切りをつけ、特定の会社に執着しないのがエンジニアというものです。

開発以外に得意分野を持つエンジニアが定着しなければ、QAチームに多様性はもたらされません。

このような状況をできるだけ改善し、開発未経験者にも定着してもらうためのアプローチとして、集団に属する人間の行動パターンを研究する社会心理学の知識が役立ちます。

社会心理学（現実に対するアプローチ）

「同質性が低い」チームの運営手段として、知識労働のマネジメントの参考書などで紹介されている方法論には、例えば下記のようなものがあります。

・ルールで縛りすぎない
・現場に権限を委譲する

それぞれ、概要を説明します。

ルールで縛りすぎない

管理職が起こしやすい失敗パターンの一つに、「ルールで部下を縛りすぎる」というものがあります。

多重な組織構造で運営されている一般的な会社の場合、中間管理職に十分な権限が与えられていないと、説明や合意だけでは周囲や部下が思った通りに動いてくれない事があります。

そんなとき、ルールを作って「みんなが守っているのだから、あなたも守ってね」というロジックで人を動かそうとする人はとても多いです。

それ自体は手法の一つとして、うまく使いこなせば有効な場合もあるのですが、そのルールを細かく厳格にしすぎてしまう人が稀にいます。

設定されたルールに合わず、現場が息苦しいと感じれば、創造性を発揮することにやりがいを見出すような、多様性をもたらすタイプの従業員は定着しなくなってしまいます。

業務を最適化する時は、「管理職にとって最適な運用」でルールづくりをせず、あくまで現場が主役であることを第一に考える事が大切になります。

現場に権限を委譲する

現場従業員に主体性を求めるために「トップダウンをやめてボトムアップでいこう」という人をたまに見かけます。

しかし、この考えは間違いです。

「ボトムアップ」というのは、現場から上がってくるアイディアを上司が受理か却下か判断して、再度現場に降ろすことを言うので、結局は意思決定が上から下へ降りており、反対になりません。

「トップダウン」の反対は、「ボトムアップ」ではなく「現場への権限委譲」が正解です。

現場従業員に主体性を求めるなら「現場で意思決定したことを、成果と一緒に上司に事後報告させる」という業務フローをつくる必要があります。

そのためには、もともと管理職が持っていた権限を一部現場に委譲することになります。

現場に一定の権限を与え、無駄な根回し不要で、任意のタイミングで意思決定して、即座に実行できるようにします。

こうする事で、現場に結果責任が生まれます。

責任感を持ちながら、業務のやり方については上からの指示に従うのではなく現場の意思が尊重されるので、

・「自分の思った通りのやり方で成果が出せた」
・「工夫したら失敗したけど次につながる学びを得た」

というように、満足度の高い業務体験を得ることができます。

このようなアプローチを一つ一つ試し、社内の状況を見ながら検証していく事で、

・多種多様なスキルを持ったエンジニアの定着率アップ
・多様性の高いQAチームを維持・成長

などの可能性を高めていく事が、マネジメントにおけるQAリテラシーの基礎と言えるのではないかと思いました。

　
　
ここまで、「多様性」と「社会心理学」に焦点を当てて、QAリテラシーの基礎（土台）となる知識をふんわりまとめてみました。

この基礎をふまえて、QAの現場にどのように応用されているかを考えます。

QAマネジメントの応用心理学

ここまで述べてきたマネジメントの基礎心理学を踏まえて、QA関連書籍に目を通してみます。

すると、「多様性や社会心理学と深くリンクするのでは？」と思えるものが度々見つかるようになります。

ここでは、特に重要だと思えた次の2つを取り上げます。

・探索的テスト
・フロー体験

それぞれ、概要を説明します。

探索的テスト

探索的テストについて考えようとすると、普段学習している時の癖で、

・テスト設計とテスト実行を同時並行する
・チャーターやタイムボックスを使う
・経験をベースにリスクや優先度を考える

というような技術的な観点についつい意識を向けてしまいますが、一旦そのバイアスを外して、マネジメントの観点ではどのように見えるかを考えてみます。

管理職が部下にテストを任せるとき、「探索的テストを指示する場合」と「スクリプトテストを指示する場合」の２つの対比で考えてみます。

すると、探索的テストには次のような特徴を見出す事ができます。

＜探索的テストの特徴＞
・設計→実行という順番に囚われず、状況に合わせてアドリブを効かせられる
・設計と実行の時間配分を、テスト実行者が決められる
・得意なテスト技法や、チャレンジしたいテスト技法などをテスト実行者が選べる

上記の特徴をさらにマネージャー視点に寄せると、

・テストのやり方をマネージャーが実行者に押し付けない
・ルールを少なくして、現場のコントロールをできるだけゆるめる
・リスクを取りつつ、現場を信頼して自由にチャレンジさせる

という特徴を持っていると言えます。

つまり、チャーターやタイムボックスなどを使う探索的テストは、スクリプトテストよりも、

「現場への権限委譲」を推進するテスト管理手法である

と言えると思いました。

フロー体験

人は、自我を忘れるほど作業に没頭できた時に、最も高い生産性と、仕事に対する満足感を得る事ができます。

この「自我を忘れるほど作業に没頭」する体験を、心理学用語で「フロー体験」と言います。

テスト実行者が探索的テストで成果をあげ、自分の仕事に満足感を得るには、意図的にフロー体験を誘発する施策が必要です。

フロー体験に入るには、

１.興味のあるタスク
２.使いやすい道具
３.リラックスして静かに集中できる環境
４.まとまった作業時間

の４つの要素が必要です。それぞれQAの現場従業員に置き換えると

1.本人が希望するタスク
2.高スペックのパソコン、広いモニター、手に馴染んだマウスキーボード
3.不要不急の声がけや、騒音のない空間
4.ミーティングの頻度を減らし、作業が細切れになるのを防ぐ

という条件を、できるだけ満たす必要があります。

マネージャーは現場作業員の様子、作業スペース、スケジュールなどに時々気を配り、集中できる環境を不公平なく提供できているかチェックしたり、本人からのヒアリングなどができる状況を作ることが理想だと思いました。

また、現場従業員同士でも気を配り合うことが大切だと思いました。

後編まとめ

ここまで、一般的なマネジメント関連書籍に書かれている内容を手がかりに、QAマネジメントにも応用されている心理学的な記述を抜き出して、ふんわりまとめてみました。

QAという職種は、ITの業務を知らない人々には企画や開発と同じ「IT従事者」という括りで見られます。

肉体労働者には、他のオフィスワーカーと同じ「知識労働者」という括りで見られます。

経営者や投資家には、「労働者」という括りで見られます。

よって、それぞれの括りで必要なリテラシー（知識と能力）を身につけ、業務に活用しています。

それらのリテラシーは、職場で業務時間を過ごすだけでも無自覚に身についていく場合もありますが、書籍などで学べば自覚的に活用できるようになり、QA以外のさまざまなステークホルダーに関与する際に役立ちます。

また、その知識を基礎として、QAの業務にも応用する事ができます。

QAにとっての理想が「多様性」であり、理想を実現する手がかりが「社会心理学」にあります。

テスト管理手法としては、スクリプトテストよりも、チャーターやタイムボックスを使う「探索的テスト」の方が現場の主体性と仕事への満足度を上げやすく、理想の実現可能性が高いのではないかと私は考えました。

また、「探索的テスト」を十分に活用するには、「フロー体験」に着目してマネージャーから現場従業員に気を配り、または、現場従業員同士で気を配り合う必要があると思いました。

いかがでしたでしょうか。

今後も書籍などを読み、普段の業務を通じて考えが改まるような事があれば、いつか別の記事で書くかもしれません。

参考

・デール・カーネギー著「人を動かす」
・エイミー・エドモンドソン著「恐れのない組織　「心理的安全性」が学習・イノベーション・成長をもたらす」
・ピーター・ドラッカー著「経営の真髄　知識社会のマネジメント」
・ロザベス・モス・カンター著「企業のなかの男と女　女性が増えれば職場が変わる」
・トム・デマルコ/ティモシー・リスター著「ピープルウェア　ヤル気こそプロジェクト成功の鍵」
・トム・デマルコ/ティモシー・リスター著「熊とワルツを　リスクを愉しむプロジェクト管理」
・トム・デマルコ著「ゆとりの法則　誰も書かなかったプロジェクト管理の誤解」
・ジェラルド・ワインバーグ著「ソフトウェア文化を創る１　ワインバーグのシステム思考法」
・ミハイ・チクセントミハイ著「フロー体験入門　楽しみと創造の心理学」
・リサ・クリスピン/ジャネット・グレゴリー著「Agile Testing Condensed Japanese Edition」
・セム・ケイナー/ジェームズ・バッハ/ブレット・ペティコード著「ソフトウェアテスト293の鉄則」
・セム・ケイナー/フォーク・ジャック/グエン・フン・クォック「基本から学ぶソフトウェアテスト」
・リー・コープランド著「はじめて学ぶソフトウェアテストの技法」
・高橋寿一/湯本剛著「現場の仕事がバリバリ進む　ソフトウェアテスト手法」