リモートワークはむずかしい

リモートワークを初めて数年経つ。管理職としてチーム単位のパフォーマンスで見ると、リモートワークは出社に劣ると言わざるを得ない。理由はコミュニケーション量が減ることと、気付きが減ることにある(気づきが減る、ということにすら気づかないので、このデメリットは本当に深刻だと感じています)。リモートワークは手順が決まったオペレーションとは相性が良いけど、何かを新しく始めたりとかチームをより良くしていくみたいなのとは、相性が悪い(なので、新人の受け入れも相性が悪い。したがって、チームは人が新陳代謝していくごとに弱くなっていく)。

出社のメリットをリモートワークでも享受することはできないのだろうか、というと、これは可能だと思う。なので、ちゃんとうまくやれば、リモートワークは出社よりもパフォーマンスは上がると思っている。

ただ、「うまくやる」というのが、実質無理だと思っている。リモートワークをうまくやるには、「別に出社でも良い」と思っている人たちだけで、リモートワークをする必要がある。パフォーマンスが最優先で、働き方はその次、という優先度で働いている人たちなら、リモートワークはだいぶうまくいくだろう。

現在、リモートワークにこだわっている人たちは、パフォーマンスよりも働き方のほうが優先されている印象がある。そうなると、組織を変えるのが難しくなり、改善が難しくなる。ビデオ会議でカメラを頑なにカメラをオフにするような人は、本来、リモートワークに向かない。チームパフォーマンスよりも自身の働き方を優先している。

そして、これが厄介なんですが、リモートワークは個人のパフォーマンスは上がっているような錯覚をするので、一人ひとりは問題ないと感じてしまいがち。「私のパフォーマンスは大丈夫です。チームのパフォーマンスが落ちているなら、それはマネジメントの問題です」みたいな対立になってるのを、あちこちで見た。

リモートワークはだいぶ浸透してきたけど、今はまだ成熟していないように思う。今後も根付くのか、徐々に淘汰されていくのか。リモートワークがある方が、いろんな人材(地方在住者、子育て中の人、シニア層)が働きやすくなって、良い世の中になると思うのですけども。

テスト項目書の扱いを変えるときが来ている気がする

ここ数年、「アジャイル開発でいかにしてQAとして価値をだすか」を考える機会が増えた。「スピードと品質を、どうやって両立するか」と言い換えても良い。

以下時と場合による、という大前提だけど、僕は最近、テスト項目書を作らないことが増えた。テスト項目書を作っている時間とテスト項目書を埋めている時間は、品質の向上に寄与しないと気づいたからである。なお、テスト項目書はつくらないが、テスト設計はちゃんとやる。何をどれだけテストするかは、テキストやマインドマップ等でアウトプットしレビューも挟むが、それをスプレッドシートやテスト管理ツールに書き起こすことをやめた。項目書がないと振り返りが出来ないじゃないか、と思われるかもしれないが、設計で利用した成果物を利用したり、テスト実行時はなるべくログを残すようにすることで、カバーできる。

テスト項目書を作っている時間とは、料理でいえばレシピを書いている時間である(※レシピを考えている時間ではない。それはテスト設計にあたる)。レシピを書くことのメリットは、再現性が高まる(だれでも作れる)、振り返りがしやすい(レシピ内のどこをどう変えればより良くなるかが見えやすい)、分業できる、レビュー可能、といったところでしょうか。これはそのままテスト項目書のメリットにもなる。

しかし大事なことがひとつあって、レシピをいくらちゃんと作っても、腹は膨れないし味もしないのである。料理は調理しない限り、先に進まない。おなじく、テストも「テスト実行」が一番大事だと思っている(※やみくもに実行するのではなく、ちゃんと計画された上での実行の時間が大事)。品質とはテスト実行の時間と相関関係にある(はず)。

先程、テスト項目書のメリットを幾つか上げたが、ひとりひとりがスキルを上げれば、テスト項目書が無くてもカバー可能である。正直、現在のテスト項目書は、未熟なQAスッタフにテストをさせるために作られているという側面が大きい。全員がハイスキルなら、テスト設計さえちゃんとやっておけば、あとはコミュニケーションを怠らなければ、テストはしっかり行われると思う。

テスト項目書を毎回作るのを止めれば、コストは下がるし、スピードは上がるし、場合によっては品質も上がる(テスト実行の時間が増えるので)ので、アジャイル開発では大事な考え方なんじゃないかな、と思うのでした。

ゲームQAに特化した書籍がついに出た。そして、ゲームQA業界が抱える課題について

ゲームをテストする バグのないゲームを支える知識と手法 | 花房 輝鑑 |本 | 通販 | Amazon

明日から使える技術的なことも書いてあるし、QA部署を立ち上げることになった人に役立つ情報もあるし、ゲームQA業界の歴史読み物にもなっている。ゲームQAに携わる人はぜひ読んでほしい。

が、読んで欲しい人達には、きっと届かない。

これが、ゲームQA業界が抱える大きな課題だと思う。

その課題とは、ひとことで、率直に、忌憚なく、痛烈に、無遠慮に言うならば、「ゲームQAの人たちは不勉強である」ということだ。ゲームQAの人たちは、勉強をしない人たちが多い。

ゲームQAは、ゲーム操作と多少の文章読解力と文章作成能力があれば、なることができる(採用してくれる会社が多くある)。つまり、なりやすい。間口が広い(ただ、その分、給料はかなり控えめな額からスタートする)。

これはゲーム業界の他の職種と大きく異なる。プログラマーになるためには、プログラミングをそれなりに勉強しておく必要があるし、アートやサウンドも、それなりの量の鍛錬を積まないと、スタートラインに立つことは難しい。

不勉強だけど、ゲームが上手いからか、要領の良い人はそれなりにいて、なので仕事は案外ちゃんとまわる。業界として、マニュアル化もしっかりなされている。どのような人が来ても、戦力になるような受け入れ態勢が出来ている(すごいことだと思う)。

要領の良い人は、トントン拍子でテスト管理者になったりするが、しかし、そこで打ち止めになることが多い。その先のキャリアが用意されていない。用意されていないというか、これまで、だれもちゃんと考えてこなかったのかもしれない。

一方、Web業界のQAエンジニアは、多種多様な役割が用意され、年収も悪くない。500万以上はザラにある。

ゲームとWeb業界の差はなんなのか。

私見ですが、ゲームQAは労働集約的であり、組織の一部として振る舞うことが求められる。指示と遂行の関係である。そして、指示する側も遂行する側も、マニュアルがしっかりしている。具体的な課題を解決することが求められる。要領が良ければ価値が出せる。

Web業界のQAは少人数であれもこれもやる必要がある現場が多い。個人の幅広い能力が試される。やるべきことを自分で見つけて、それを遂行する。抽象的な課題を解決することが求められる。勉強をすることで、自分の提供価値範囲が広がっていく。

ゲームQA業界の未来は明るくない気がしている。

ゲーム以外の娯楽が増えてるし、そもそも少子化だしで、ゲームQAに興味持つ人は減っていくと予想される。そこに低賃金が加わると、より担い手は減るだろう。

ゲームQAの賃金を上げたい。僕はゲームQAには、その価値があると思う。ゲーム開発とソフトウェアテストの専門性をかけあわせ、開拓していけば、個人が提供できる価値は大きく増えると思う。スキルを増やし個人の生産性を2倍にしよう。そうすれば、人の数は今の6割7割くらいで済むだろうし、そうなったら一人ひとりの年収は1.5倍にはなるはず。僕は、これは夢物語では無いと思っている。

どうすればそのような世界になるのかというと、まずは採用の基準を変えることなのかな、と思う。「ゲーム好きあつまれ！」を止めるところからじゃないかな。ゲームは好きな方が良いが、その前に、仕事にちゃんと取り組めて、勤勉で、素直な人を採用する。気長な道だが、4～5年経てば、今とはだいぶ違うゲームQAの姿になっている気がする(たとえばだけど、全員がプログラマー出身のゲームQAチームがあったら、今のゲームQAとは、全く異なる価値を提供しそうな気がしませんか)

コントローラとスマホを脇に置いて、たまには書を読むところからスタートしよう！

dialogue based managementというものがあってもいいかもしれない

天ぷらを10年揚げられず…伝統文化の「下積み」は本当に必要？ 賛否両論に専門家は

https://headlines.yahoo.co.jp/article?a=20190709-00043970-otonans-life

読んだ感想としては、下積みが要る要らないではなく、下積みの内容を見直すかどうか、ということじゃないかな、と思いました。

僕は伝統文化の世界には居ませんが、「見て覚えろ。そして自分で考えろ。ただし間違ってても適切なフィードバックは与えないし、なんならぶん殴る」的な教育を学生時代の部活や短期間ですが社会人生活で体験しました。

そして今、それなりにいい歳になり、教える側にもなった立場からすると、この考え方は、平成も終わり昭和の名残も綺麗サッパリなくなった令和の時代には、流行らないだけでなく、無意味なんじゃないかな、と思います。

この手の教育手法に欠けているのは「対話」です。技術や考え方の継承で必要なのは「対話」であると、僕はここ数年のマネジメントの仕事で実感しています。

対話がなくても、まぁ、マネジメントが成り立たないわけではないのですが、その場合は後輩の成長が遅い、長期的にはYesマンの集まりになり、上意下達の多様性のないチームになりがち、というデメリットを抱えているように思います(それはそれで、有効な場面もあるでしょうが)。一言でまとめると、組織の賞味期限が短くなります。

賞味期限が短いと書きましたが、企業の管理職と個人経営の伝統文化のオーナーの違いは、賞味期限の意識にあるかもしれないですね。企業の管理職は、自分が居なくても会社や組織が繁栄できるような意識を持って仕事をすることが多いのに対し、オーナーは自分が居なくなったあとのことをそれほど考えていない、別の表現するなら、自分さえいれば仕事が回る状況を問題視していない、ということになるかもしれません。

企業秘密の優位性は失われていく

長期間の下積みを共用できた背景のひとつに、「技術が公開されていない」ということがあるかもしれません。この技術がほしければ、文句を言わず従いなさい、という取引が成り立っていた時代があった。

しかし、インターネットがあらゆるものがオープンソースにしていきます。料理のレシピからスポーツのノウハウからゲームの上達方法まで、インターネット上には一流のそれが公開されています(仕事にしろ趣味にしろ、ほんと、いい時代になりました)。

この流れが進めば、企業秘密というもの自体が時代遅れになるでしょう。組織の優位性は技術の内容ではなく、習得の難易度(料理でいえば、レシピではなく調理技術)になっていくでしょう。

「言うのは簡単だけど、やるのは難しい」ということに優位性が産まれていくし、それを如何に効率よく継承していくか、というところが管理職の腕の見せどころになるかもしれません。

そして、そのベースにあるのは「対話」だと思うのです。

新規か運用か

アプリゲームがゲーム市場の多くを占めるようになり、ゲームQAという仕事も、リリースまで頑張って終わり、というわけにはいかなくなりました。リリース後の運用フェーズのQAという仕事が生まれたのが、過去のゲームQAと異なる点ではないでしょうか。

個人的には、立ち上げQAも運用QAも、それぞれ長短あると感じてるので、思うところを書いてみようかなと思います。なお、最初に私見を言っておくと、QAとしての成長を重要視するならば「基本は運用、一度は新規」、という感じです。

立ち上げのQAは、数をこなしても、あまりメリットがないかなぁ、と思ってます。新規で得られるスキルは、概ね運用でも得られるし。

運用のQA

最大のメリットは、「フィードバックが早くて多い」ということです。リリースを繰り返していくため、何が良くて何が悪かったか、という振り返りの機会を多く持てます。

また、フローが良くも悪くも固まっていて、スケジュールと予算がタイトに決められていることが多いため、「どうすれば、限られたリソースで、効果的に品質をあげられるか」ということに、頭を使うので、QAとしての地力がアップします(頭を使ってない人もそれなりにいますが。すぐスケジュールとテスターの数を調整しようとする人)。

デメリットは、一つのタイトルに関わり続けることで、マンネリ化に陥りやすく、1年も経過すると成長も止まりがち、ということです。
マンネリ化してきたな、と感じたタイミングで、チームを異動できればいいのですが、長期間関わると、QAスタッフがドメインに詳しくなり、周囲からは評価されやすくなるため、自分自身もとどまりたくなるし、開発チームも手放さなくなり、異動するのに想像以上に労力がかかります。

あと、チームそのものがマンネリ化してる場合もあり、保守的なチームも少なくないです(ただ、その雰囲気を変えることができれば、大きな成果となるでしょう)

 

新規のQA

メリットは長期間(数ヶ月)の大規模なQAを経験できるということでしょう。テスト設計に1ヶ月というのも珍しくありません。

チームやフローやツールも、ある程度、自分好みにできるので、働きやすい環境が作れるかもしれません。

また、リリース後には大きな達成感を得ることもできます。

デメリットは、フィードバックが少ないということが挙げられます。特にQAチーム外からのフィードバックは、運用と比較すると、極端に少ない傾向にあります。QA期間中はQAはひたすらテストの消化に追われ、開発チームも追い込みで切羽詰まってるため、振り返っている暇がないためです。

リリース後にフィードバックが得られればいいですが、長い期間を経た割には、少ないフィードバックになりがちです。それどころか、開発が中止になった場合は最悪で、フィードバックすら得られません。素振りだけして終わり、みたいなもんです。

また、なにかしら課題に直面しても、残業か増員かスケジュール延長で対応しがちです(まぁ運用でもそれで解決しちゃうこと多いけどな…)。頭を使わずに解決してしまうので、QAとしての地力が身につきません。

したがって、新規のQAは、時間を掛ける割には、成長に繋がりにくい、という印象です。ある程度、経験を積んだ初中級者が一皮むけるには、とても良い題材ではありますが。

まとめ

ということで、それぞれ、メリット・デメリットあるので、自分自身のキャリアプランや成長プランに応じて、所属するチームを検討しましょう。

科学的と工学的

たとえば「何をもってして、サービスの品質が良いと言えるか？」

という問いに対して、アプローチは2つ考えられます。

①「品質」を言葉や数値で定義し、それをクリアしていれば、品質が良いとする
②関係者全員に「品質が良いと思うか？」と質問し、多くの人がYesと答えれば、品質が良いとする

前者は科学的アプローチで、後者は工学的アプローチと言えるかもしれません(科学的と工学的のちがいの参考はコチラ)

科学的な人は、準備をしっかりして、ルールを決めて物事を進めたがる傾向にあり、工学的な人はとりあえず手を動かしてみて、なにか問題が起きたら都度工夫をして進めようとうする、という傾向にあります。

そして、最近気づいたのですが、チーム内で科学的な人と工学的な人で意見が分かれると、議論が空回りして物事が先に進みにくい印象です。

逆を言えば、自分の上司や関係者が、どちらよりの人なのかを見極めると、コミュニケーションしやすくなるかもしれないですね。

僕はサッカー部のレギュラーでした

だからどうした、とみんな思うでしょう。はい。

でも、同じようなことを採用面接の場とかで、よく耳にするのです。
「リーダをやってました」
「立ち上げを経験しました」
「管理やってました」
ってやつです。

この手のアピールは、一見すると、「お、すごそうだな」と感じてしまうのですが、実はなんのアピールにもなってません。

たとえば、表題のように「レギュラーでした」と言われても、所属してたチームの規模も強さも活躍度合いもわかりません。万年1回戦負けで部員が11人しか居ないチームでレギュラーだったとしても、別に凄くもなんともないですよね？

仮に全国区の学校でレギュラーだったら、それは確かにすごいですが、でも結局知りたいのは、試合中にどんな活躍ができるのかだし、どんな練習をしてきたのかだし、周りのメンバとちゃんと協調できるのかどうかです。

リーダという肩書を貰ったことに価値があるのではなく、その肩書で何をしたのか、どんな成果をあげたのか、どんな失敗をしたのかを話せるようにならなくてはならない。

採用の募集要項も「リーダ経験のある方」じゃなくて、「リーダシップを発揮したことのある方」と記載するほうが良いかもしれないですね。あまり仕事のできない自称リーダ経験者は結構見かけますが、肩書なくてもリーダシップが何たるかを自分で考えて言葉に出来る人は、きっと良い人なんじゃないかしら。

なお、僕の思うリーダシップは
・仕事をより好みせず、眼の前に課題があれば、それを自分ごととして捉えることができること
・周りの力を借りれること。そして、自分の力を誰かのために貸せること
の2つを満たしていることです。
つまり重要なのは、スキルではなく姿勢。そしてそれは、肩書やポジションに依らず、誰もが発揮できるものだと思うのです。