オカネに着目して心の準備をしておく、の巻

QAマネージャーとして第三者検証企業やツールベンダとミーティングをするときは、

雑談がてら、自社や業界の景気状況について話すようにしています(上場企業なら決算資料を元に話します)。別にQA職に限ったことではないですが、景気というのは自分たちのお仕事にも

大いに影響がでるためです。

前提として(この言葉の受け止め方は色々あるでしょうが)QA部署はコストセンターです。

自部署で売上を立てることができません。QA組織の運営費用はどこかが稼いでくれた売上に依存しています。そのため、お金に関することは、特に注意深く見ておいた方が良いと思っています。

具体的には、会社の売上、所属プロダクトの売上、所属プロダクトの開発費用、

所属プロダクトの会社内での立ち位置(優先度)、業界の景気、とかでしょうか。

会社の売上は上場企業なら3ヶ月に1回の決算資料で見ることができます。所属プロジェクトの調子は、日々のミーティング等で共有されていると思います。調子が良さそうなら、QAとしては特に気にすることはありません。採用や協力会社の開拓の準備をしておく、みたいな、ポジティブなお仕事が生まれるかもしれません。

逆に調子に陰りが見えてきたら、QAとしては人員計画(採用や異動や業務委託費用の見直し)の準備をしておきます(冒頭にあるような、関係者に雑談ベースで頭出ししたりしておく)。

スタッフを減らすくらいなら、まだマシで、発注先を安いところに丸ごと変える(海外とか含む)、みたいなハードな仕事が発生することもあります。

また、決算資料内でどの順番で事業の説明をしているか、とか、所属プロダクトがそもそも挙げられているか、みたいなことにも注目しています。所属プロジェクトが決算資料内であまり目立たない場合も、シュリンクに向けて心の準備はしておきます。シュリンクに向けた取り組みというのは、関係者にネガティブな感情を生み出すことが多いので、なるべくサプライズにならないように気をつけたいところです。「なんか最近調子悪いなぁー。QAにも影響出るかもな」みたいなことを、独り言のように呟くだけでも、それなりに効果あると思います。

業界の景気も影響します。

人手不足や単価の上昇は、QA組織の運営難易度を上げます(逆はそんなに問題にならない。が、自分の給料は上がりにくいかもしれない)。未経験者を雇い育成に力を入れるなどの方針で進めていかざるを得ないかもしれません。

まとめると、景気というのは、短期というよりは中長期的な時間軸で影響を及ぼすので、マネージャー以上は意識しておくと良いかもしれませんね。

ちなみに、個人的な感覚だと、Web界隈は売り手市場、ゲーム界隈は厳しい印象です。他はわかりません！

「JSTQB FL アジャイルテスト担当者」のシラバスの読書感想文

はじめに

スクラム開発が増えてきて、「スクラムのなかでQAとしてどう振る舞うのが良いのか」という問いを、ちょくちょく見かけます。これまでのQAのやり方を踏襲し、スクラムの中に「QAフェーズ(設計/実行の期間)」を設ける、俗に言う(？)「なんちゃってスクラム(=ちっちゃいウォーターフォール)」で対応したりと、色々試行錯誤が続いている段階かもしれません。

試行錯誤は良いことですが、スクラムもそこそこ歴史がありますし、まずは先人の知恵を借りようじゃないか。ということで、JSTQBのアジャイルテスト担当者のシラバスを読んでみることにしました。

内容を自分なりに咀嚼した上で、「アジャイル開発で、QAは何をすればよいのか？」を考えてみたいと思います(つまり、当記事は、読書感想文であり、シラバスのサマリーではありません。あしからず)当記事を読んで興味がわいたら、シラバスの原本も読んでるとよいでしょう。

そもそもアジャイルって何？スクラムって何？

アジャイル開発の手法のひとつ(かつ世の中的な主流)が「スクラム」になります。
アジャイルとは：https://www.nri.com/jp/knowledge/glossary/lst/aa/agile
スクラムとは：https://www.nri.com/jp/knowledge/glossary/lst/sa/scrum

シラバスではスクラム以外の開発手法(XPとかカンバンとか)にも触れられていますが、当記事ではスクラムのみ扱います。

1章 アジャイルソフトウェア開発の基本

ウォーターフォールの時代は「入念な計画」が重要視されていた。
しかし、昨今は市場(=ユーザの要望)の変化が激しい時代になってしまったため、長期にわたる計画的な開発は、効果的ではないシーンが増えてきている。
なるべく早くリリースし、ユーザの反応を見て、修正をなるべく早く行うことが重要になってきている(=変化とスピードが大切)。

アジャイル開発は、「ユーザが求めているもの」を「なるべく素早くリリースする」ための考え方である。

2章 アジャイルテストの基本的な原則、プラクティスおよびプロセス

アジャイルテストにおいては、(ユーザとプロジェクトにとって利益となる)仕様の変化は歓迎しなければなりません。かつ、どのような状況でも、なるべく早くテストを終わらせる必要があります(「動くビルド」を素早く提供する)。

そのためのキーワードが「シフトレフト」「探索的テスト」「テスト自動化」になります。

ちなみに、これまでのQA組織は、仕様や計画の変化を避けたがる傾向にありますね。「仕様変更」と聞いて喜ぶQAを見たことがありません。しかし、このマインドセットはアジャイル開発では不利に働く可能性が高いです。変化を歓迎出来なければ、アジャイルQAとして成果を出すのは難しいかもしれません。

準備をどれだけ減らせるか。「テスト設計」というものを考え直す

これまでのテストとの大きな違いは「テスト設計」の扱いにあるかなと思います。ウォーターフォールではテスト設計の品質がプロダクトの品質に大きく関連していました。また、テスト設計に費やされる時間は、テスト工数全体の50%近くになるプロジェクトも見かけます。

しかし、一つ認識しておくべきことがあります。それは「テスト設計している時間は、サービスの品質向上に貢献していない」という点です。サービスの品質が向上するのは「テスト設計で作成した成果物をもとに、サービスを触った時」です。テスト設計は、あくまで準備なのです。

料理でいえば、テスト設計はレシピを考えている時間です。レシピをどれだけ考えても、味はしませんし腹は膨れません。

つまり、「テスト設計の時間をなるべく減らす。しかし、充分にテスト設計した状態と変わらない内容でテスト実行を行う」が理想的な状態といえるでしょう。

シフトレフト

テスト設計をするな！というわけではありません。ただ、仮にテスト設計するのであれば、その内容は開発者にも共有するべきです。コーディングの段階でバグを潰すことができるでしょう。QAエンジニアは「品質のコーチ」としての役割も求められます。

探索的テスト

入念なテスト設計をせずとも、テスト実行の質を落とさない。そのために、探索的テストのスキルを向上させる必要があります。なお、本ドキュメントでは特に触れませんが、シラバスの第3章に探索的テストのノウハウが記されています。

テスト自動化

細かい改修を重ねるアジャイル開発では、回帰テストは大切です。追加した機能や、改修した機能が、既存機能に影響を与えていないことを確認してこそ、安心してリリースが出来ます。

回帰テストは、システムの機能が増えるほテストケースの項目数が膨らんでいきます。また、リリースの頻度に比例して工数が増えていきます。品質を担保し、回帰テストの時間と工数を減らし、テスト担当者が探索的テストや開発者との対話の時間を確保するために必要なことが、「テスト自動化」です。

3章 アジャイルテストの方法、技法、およびツール

アジャイル開発で大切なことは、安定したビルド(品質が一定以上のビルド)を、継続的に迅速にデリバリーすることです。

そのためには、各セクション間(エンジニアとかQAとかPMとか)で、対話、協調、合意をベースにして、業務を進めていくことが求められます。適切なコミュニケーションによって業務を効率化し、それと同時に、可視化により不要な(というか過剰な)コミュニケーション(ドキュメンテーション含む)を減らすことを目指しましょう。

QAに求められること

QAチームのタスクをブラックボックス化してはなりません。ツールを活用して、テストの観点、見積もり、テスト範囲、テスト結果、リスクを誰もが見えるようにしておくこと。また、アジャイル開発のQAは、テストレベルによって求められる役割が異なります。具体的な一例は下記。

• 対話やレビューを通して、関係者の品質意識を高めること
• 開発者が作成するユニットテストのテスト観点の共有
• E2Eテストの自動化
• マニュアルテスト

上記のプロセスで成果を出すためには、コミュニケーションスキル(ペアワーク等の技法含む)、自動テストスキル、マニュアルテストスキル、開発プロセスへの理解、が必要でしょう。

おわりに

シラバスを読んでみて、私はアジャイル開発ではQAというロールに、幅広いスキル・素養が求められてるな、という感想を持ちました。

それは、「難しい」という側面もあります。これまでのように「ドメイン知識が最低限あれば良し」という間口の広さは失われるかもしれません。一方で「いろんな長所を活かせる」とも言えると思います。開発が得意なら自動テストに寄せれば良いし、コミュニケーションを活かしたいなら対話で価値を出すこともできるでしょうし、マニュアルテストが得意なら爆速でハイクオリティなテストを提供することで価値が出せるでしょう。

QAというお仕事は、システムと人間という、複雑で曖昧なものと向き合う、とても奥が深いお仕事です。そして、それが世間に認知されつつあると感じています。QAの年収はここ10年で上がってきていると感じていますが、この傾向は、まだ続くのではないでしょうか。

なぜネガティブなフィードバックは隠されてしまうのか

会社でも家庭でも、本当にまずいことというのは、案外対処されない。リスクをリスクのまま放置して、いずれインシデントになる。

たとえば、従業員に高圧的な態度を取るスタッフ(Aさんとします)がいて、それを苦痛に感じている人が複数いるとする。当事者含めて周囲の人がそれを認知していても、当のAさんには、それが認知されないことはままある。だれかがAさんに「まずいんじゃないか」とフィードバックをするしかないが、それがなかなか行われない。

なぜか。

Aさんにネガティブなフィードバックを受け止める心の準備が出来ていないから、だと思う。無防備な状況に豪速球なフィードバックを投げても、受け止める側は悪い意味で驚いてしまう。

その驚きは、怒りや悲しみになり、フィードバックの内容が届かない。それがわかっているから、フィードバックをする側が躊躇してしまう。

僕の知り合いは、毎年一回、無理やり夫婦喧嘩をする日を作っているらしい。そこで、大なり小なりのネガティブフィードバック(要は不満をぶつける)を行うそうだ。その日は、お互いにネガティブフィードバックを受け取る準備が出来ている、ということである。夫婦という数十年の長期プロジェクトを健全に保つための、良いアイデアだなと思います。

我々サラリーマンも年に一回くらい、心の準備をした上で、ネガティブなフィードバックを喰らっても良いのかもしれない。そこには、発見もあるだろうし、誤解もあると思うけど、放っておくよりはマシだと思う。放って置いたほうが良いこと(言わなきゃよかった、聞かなきゃよかった、みたいなこと)も、きっとあるだろうけど。。。

なお、フィードバックはサラリーマンの特権かもしれません。社長やフリーランスの人はフィードバックは得られず、市場から判断されるのみ！(なので、コーチングとかが必要なのかな)

もし最近、考え方や働き方が変わるようなフィードバックをもらっていないのであれば、それは自身が完璧になったか、もしくは隠されているかのどちらかでしょう。後者の場合、なぜ隠されているのかを自問自答する必要がありますね。そういえば、僕ももう5年くらい耳の痛い意見から遠ざかってます。社歴の長さと(元)管理職という立場と口の悪さ(！)が、原因なんじゃないかな、と思ってます。

童話「裸の王様」は今にも通ずる話だよなぁ。

育成なのか選抜なのか

社内外の管理職レイヤーの方とお話していると、メンバーの育成に対する悩みが多い。しかし、よくよく聞いてみると、それは「育成」ではなく「選抜」なのではないだろうか？と思った。

習得すべき知識や技能があり(役割といっても良い)、それらを身につけるためのカリキュラムを提供し、それが出来ているかどうかをテストする。この流れのことを「育成」と呼んでいるような気がする。テストの結果次第で、「できる」「できない」「めっちゃできる」みたいな評価をもらう。僕はそれは「選抜」なのではないか、と思う。受験や資格勉強の対策に近い。

一方、僕が思う育成というのは、あくまで個人に対してのものである。チームとしての期待したい役割もあるっちゃあるが、それよりは「この人は何が好き/嫌いで、何が得意/不得意で、どうすれば伸びるのか」ということに関心がある。それをもとに役割を決めるし、中長期的なキャリアパスも考える。そのため、基本的にはオーダーメイドになる。

選抜の良いところは、見通しが立てやすいということにあると思う。決まった役割があり、それをこなせる人が来るので、一度仕組みを作ってしまえば業務が安定する。一方デメリットは、環境の変化に弱いことと、安定と引換にチームとしては停滞に向かうことにある。

格闘ゲームでいえば「習得困難なハメ技」に近い。一度覚えてしまえば、勝ちまくれる。しかし、勝ちを集めてはいるが、自身は成長しない。また、ゲーム内容がアップデートされるとそのハメ技は通用しなくなるかもしれない。

選抜というシステムは結果がわかりやすい。したがって、改善もし易いし、再現性も高い。一方で僕がいうところの育成は、複雑性が高いし再現性も低い。指導者次第なところがある。パフォーマンスも安定しないが、しかし、驚くような結果が出ることもある。

芸術や芸能やスポーツの世界は、ある程度は選抜で人をふるいにかけ、そのあとは指導者(監督やコーチ)がオーダーメイドで育成をしているように見える。サラリーマンは選抜だけで、成長は個人に委ねられている。サラリーマンにも育成の意識があれば、より良くなるのではないかしら。

そうは言ってもお前の言う育成ってなんやねん、イメージわかんわ。
という方には、ブルーピリオドという漫画にでてくる大葉先生(美大受験編に出てくる)と、Draft Kingという漫画に出てくる郷原というスカウトがやっていることが、僕が思う育成のイメージです。どちらの漫画もすごく面白いです。おすすめ！

■

マネジメントのお仕事を始めてから5~6年経ちますが、マネージャーのお仕事の一つにメンバーのアサインがあります。

各メンバーのパフォーマンスと将来性を考慮し、誰に何を任せるか、誰と誰を一緒にするか(あるいはしないか)を、いつも考えてました。

ぶっちゃけ、パフォーマンスの見積もりとアサインは直感でやってるところがあるのですが、最近いい具合に言語化できたので記事にしてみようと思います。

パフォーマンスの公式

個人のパフォーマンスは下記の公式で表されると思いました。
・パフォーマンス = センス x 技術 x 実行力 x 運

センス

たとえば、画家を二人同じ公園に連れてきて絵を描かせたとき、風景のどこを切り取りどのように表現するかはは、それぞれ異なっていると思います。その違いがセンスです。単純に良い悪いで評価できるものではないですが、筋の良さ/悪さみたいなものはあるし、特定の人/状況にウケる/ウケないみたいなものはあるでしょう。
また、一人のセンスも常に変化しています。
学習による変化というよりは、環境から影響を受けて変化している印象(学習による変化ももちろんあるし、それなりに大きい)

技術

絵の例でいえば、頭の中で描いた表現したいものを、紙の上でなるべく忠実に表現できる力のことです。学習可能で測定可能。測定可能なので転職するときとかは、こっちが測られやすい。

実行力

たとえば自分が思い描いた絵を書くためには、1年の制作期間と数人の仲間の協力が必要とわかったときに、やりきれるかどうか。みたいたこと。体力、メンタル、メンバーシップ、リーダーシップ、色んな要素がある。
センスと技術があったとしても、実行力がなければ絵に書いた餅。

運

まぁ、チャンスを掴むかどうかは運の要素も大きい。ただ完全とはいかないまでも、多少はコントロール可能かなと思っています。少なくとも無礼な人よりは礼儀正しい人のほうが、チャンスが巡ってくる回数は多いと思いますし。

ということで、パフォーマンスを高めるには

センスを育てるには、、どうしたら良いのでしょうね。環境からの変化を歓迎する素直さとかでしょうか。
技術は座学である程度習得可能。
実行力もようわかりません。ある程度、才能の世界な気もする。
運を高めるには、壺を買ったり滝に打たれたりするのも良いかもしれませんが、個人的にはgiveのマインドもち、礼儀正しく過ごすのが良いのではないのかな、と思います。

おわりに

自分のパフォーマンスを因数分解してみると良いかもしれません。どこが強みでどこが弱いのかわかるかもしれない。

面接と商談は似ている。というか似せていきたい。

面接を受けるのも苦手だし、面接官のお仕事も苦手な業務のひとつです。

何がその苦手の根本にあるのかな、と考えてみたときに、「目的と効果がいまいち不明瞭な質問とその解答で、評価が決定されること」にあるような気がした。ということは、それらをクリアにすれば、面接ももっとマシになるのではないか。

それを踏まえて、面接で一番重要な事項は「募集の背景」だと思う。まずはそのすり合わせが企業側と候補者側で行われる必要がある。それもせずに面接を行っても、意味のある面接にはならないだろう。

商談をイメージしてみると良いかもしれない。商談といっても、たとえば、家電量販店で家電やスマホやPCを買うときのイメージで良い。

このとき、お客側は「欲しい商品と、それによって解決したいこと」がある程度明確になっているはずである。「皿洗いが面倒くさいので食洗機が欲しい。予算はこれくらい」みたいな。この要望が面接における「募集の背景」となる。

一方、お店側(面接における応募者側)は、お客の要望にマッチした商品を提案することが最初のステップとなる。お客の要望を把握せずに商品を提案すると、食洗機を探しに来た人に洗濯機の説明を始めるようなことになりかねない。これでは、まず売れないし、仮に売れてもクレーム(＝採用のミスマッチ)になるだろう。

面接に話を戻すと、繰り返すが、まず最初に募集の背景のすり合わせが行われるべきである。企業側から説明したほうが良いと思うが、仮にそれがなかった場合、候補者側から募集背景を聞くと良いだろう。すり合わせが行われたなら、その後の質問は、その募集背景と絡めた質問と解答をすることができる。これによって、面接はより有意義になるし、ミスマッチも防ぐことができると思う。

コミュニティへの貢献に対する報酬について考える

先日、とあるミーティングで「テックブログ等で社内外への情報共有を活性化させるためには、どうすれば良いか」という話題になりました。結構、活発な議論になりまして、その時は「記事を書いてくれた人に何かしらの報酬が支払われるべきか否か」が焦点だったように感じました。

私自身、頼まれても居ないのにこうやってブログを書いたりしますし、誰かに頼まれて外部露出をすることもあります。このとき、正直、報酬は意識していません。意識していませんが、経験上自分に何かしらのメリットはあるなぁ、くらいの感覚はあります。
このぼんやりとした感覚に向き合ってみたところ、うまく頭の中でまとまった気がするので、記事に残してみます。

事業への貢献とコミュニティへの貢献

まず、我々は従業員は事業への貢献を期待されています。スキルと時間をアサインされた事業に費やし、事業の売上やユーザー数を伸ばすことが期待されています。僕らの年俸と紐づくのもここでしょう。

一方、冒頭のテックブログや外部露出の話を少し抽象化すると「コミュニティに対する貢献への報酬は何か」という問いになると思います。コミュニティとは何かというと、会社であったり事業部であったり所属グループであったり。

コミュニティに貢献するメリットは、「自分自身が良いコミュニティに所属することができる」ことです。良いコミュニティを自らの手で作り出せるためです。そして、良いコミュニティに所属していると、ストレスが減ったり業務に集中できたりするので、事業への貢献もやりやすくなるかもしれません。

コミュニティへの貢献は、「従業員がやりたければやってもよい」程度のものだと思っています。「やらなければならない」というのも、ちょっと違和感がありますし、「事業の貢献に直接結びつかないものはやるべきではない」というのも窮屈に感じます。
些末な例でいうと、自分の番でトイレットペーパーが切れたら、次の人のためにトイレットペーパーを変えてもいいし変えなくてもいいのです。ただ、変えてくれる人が多いコミュニティの方が、良いコミュニティになる気がします。

コミュニティへの貢献の報酬

事業貢献への報酬がお金(=半期ごとの評価)であるならば、コミュニティ貢献に対する報酬は「機会(チャンス)」だと思います。

コミュニティに貢献している人は、周囲の人がポジティブな印象を抱いてくれることが多いです。すると「あの人と仕事してみたい」「あの人にこの仕事を任せてみたい」となり、新たな機会が提供されやすくなるでしょう。新たな機会が提供されることで、結果として、自身の成長にも繋がっていきます。

直接的なメリットではなく、間接的(時差がある、と言っても良い)なメリットを得られることが、コミュニティ貢献への報酬の特徴なのかもしれません。

で、どうすればコミュニティが活性化するわけ？

たしかに。
コミュニティ貢献の報酬についてはスッキリしましたが、どうすればコミュニティが活性化するのかまでは、考えてませんでした。コミュニティ貢献の報酬は間接的なので「別に今はやらなくてもいいや/私がやらなくてもいいや」という判断がされがちです。その重い腰を上げてもらって、コミュニティ貢献をしてもらうには、メリットではなく充実感を餌(言い方)にする必要がありそうです。

ふと思ったのですが、これって献血の構造と似てる気がしますね。痛みを伴って献血しても本人に直接的なメリットはほぼありませんが、「何か良いことをしたぞ」という充実感があります(などと言ってますが、私は献血したことありません。やったことがある人がそう言ってただけです  )。

どうすればコミュニティ貢献から距離を置いているひとに、コミュニティ貢献の充実感を感じてもらえるのでしょうか。別の問いに置き換えると、どうすれば私は献血に行くのでしょうか。うーん、痛くなかったら行くかな。ということは、面倒臭さを解消すれば良いのでしょうか。でも、面倒くさいことをやるのがコミュニティ貢献だと思うしなぁ。となると、いっそのこと報酬をだして・・・(最初に戻る

ちなみに、献血が習慣になってる知人にきっかけを聞いたら「友人に誘われた」とのことでした。確かに学生の頃も、数人で献血に行ってる集団があったなぁ。献血の後にハーゲンダッツをみんなで食べるのが楽しみだったとか。

なるほど。たしかに近所の自治会しかり、コミュニティ貢献している人は、コミュニティ内でのコミュニケーションがご褒美になっている気がしました。つまり、コミュニティ内のコミュニケーションをご褒美にするのが良いのかもしれません。

答えは出ない！まぁでも、「目先の損得で判断せずに、とりあえずやってみようぜ」で、半ば無理やり巻き込むのが良いような気がしてます。