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つを満たしていることです。
つまり重要なのは、スキルではなく姿勢。そしてそれは、肩書やポジションに依らず、誰もが発揮できるものだと思うのです。

落ちるりんごを見て引力を発想できるのか?の件

バグを見つけるだけがQAの仕事じゃない。上流工程から関わっていって、バグそのものを減らすのもQAの仕事である。

…って話はよく聞くが、そんなん言われても、バグをそもそも減らすって、どうすりゃいいのさ、と悩んでる人がまぁまぁ見受けられるので、今回はそれをテーマにしてみたい。

 

QAチームは、日々、不具合を見つけます。その不具合を開発チームに報告して、修正してもらうわけですが、修正してもらってオシマイにするのではなく、QAチームに集められた不具合を観察して、そこから「なぜこの不具合が産まれたのだろうか」と想像してみることが大事なのです。

 

不具合の具体例を集めて、「なぜ不具合が産まれるのか」という問いかけをして、その原因の仮説を立てて、原因を潰すための実行案を考えて、それを実行してみて、結果をモニタリングをする。この一連のプロセスが「上流工程からのQA活動」となるわけです(ちなみに、不具合発生の理由は様々です。採用した技術、プロセス、人、組織の成熟度、などなどが不具合の原因になり得ます)。

 

不具合を見つけるだけでなく、不具合と向き合うことで、次の一歩に進めるわけですね。

 

なお、上流工程のQAで一番難易度が高いのは、課題を見つけることでも解決案を考えることでもなく、上流工程のみなさんに、QAの意見をちゃんと聞いてもらうことだったりします。

それを解決するには、QAの意見をちゃんと聞いてもらうためにはどうしたらよいのか?という問いかけして、仮説を立てて、以下略。

 

んまぁ、そんな感じで、QAって「決められた手順で操作して、決められた期待値が出るかどうかを確認する」という、具体性のカタマリみたいな仕事だと思われてますが、その先には抽象的な問題のカタマリが待ち構えています。そして、その抽象的な問題を解決することが、いわゆる「上流工程からのQA」だと、僕は思うのでした。

 

頑固さは失敗のもと

たとえば恋人が、あなたのために料理を作ってるとしましょう。

料理スキルの高いあなたは、恋人の作業工程やレシピをみて、どうみても料理が失敗することが予想できました。こんなとき、どうしますか?

 

作業工程の途中で、「このまま進めても失敗するよ。まずい料理ができるだけだよ」と、伝えることができますか?仮に伝えることができたとして、その後、恋人との関係性に、多少の緊張感が走ったりはしませんか?

 

つまりなにかっつーと、失敗する前に指摘すると、指摘された側は「自分のことを否定された」と、感じてしまうことがあると思うのです。プロセスに対する指摘が、個人への指摘と捉えられてしまい、なにかと面倒なことになりがち。これが、失敗した”後”だったら、割りとスムーズに振り返りや反省ができるんですけどね。

 

 

リーダやマネージャになると、「部下や関係者がまずいやり方してるけど、これは、今言うべきか、それとも失敗が表面化し始めてから言うべきか」というところで、結構、頭を悩ませます。失敗する前に言う方が間違いなく良いのですが、プライドの高い人だと、そのプロセスに対する議論に入る前に、感情の問題を解決せねばならないし。

 

結局、指摘できるかどうかは、その人が素直かどうかってところに着地するのかな。そう考えると、素直って、大事な素養ですよね。失敗したくなかったら、技術やノウハウを身につけることも大事ですが、失敗に片足踏み込んだときに誰かに指摘してもらえるように、素直さを身につけることも大事かもしれません。

 

昔から、冬は寒いし夏は暑い

プロジェクトの品質に問題が合ったとき、どこに働きかけるべきか?
ということを、QAは、まず、ちゃんと考えなければいけない。

 

どういうことかというと。

 

 テストプロセスにもに色んなファクターがある。
予算とか、テストの対象とか、スケジュールとか、ツールとか、スタッフとか、環境とかとか。
そして、その中で、変えられるものと変えられないものがあるはずである。

 

たとえば、会社が儲かってるなら、予算は気軽に変えられる(増やせる)だろう。
しかし、そうでないなら、予算は動かすことのできないファクタになる。
にも関わらず、「予算が足りません!テスターのヘッドカウントが少ないので品質があがりません!」と、叫び続けても、状況は何もかわらない。予算は増えないだろうし、品質もあがらないだろう。まぁ、リスクの提示にはなるかもしれないけど。

この場合は、予算が少ない中で何ができるだろうか、というのを考えることに時間を使ったほうが生産的である。

 

 

たとえば。冬は寒い。しかし、冬の寒さに幾ら文句をいっても、暖かくはならないのである。寒いのが嫌なら、服を着るなり、運動するなり、暖房のきいた部屋にこもるなり、南半球に行くなりしたらよい。

 

変えられないものに対して「変えた方が良い。なぜ変わらないんだ」と言っても、デキの悪い評論家かクレーマーにしか思われない。QAも、プロジェクトのどのファクタに対して、意見を言うかを、ちゃんと考えたほうが良いと思います。はい。