# タイトルコール テスティングジャーニーへようこそ。 このチャンネルでは、ソフトウェアテストの世界を探索するをコンセプトに、 エンジニアリングマネージャー兼QAリーダーのサミーが、 ソフトウェアテストのコツや品相調の奥深さ、そして日々考えていることをお話しします。 # QA経験者はPdMに向いているか？ こんにちは、サミリです。今日もテストしていますか? 私はですね最近ふと思ったんですけど、テスト設計よりもテスト実行でポチポチ プロダクトを触っている時間の方が好きかもしれないなぁなんて思いました。 はい今回はですね、QA経験者はPDMに向いているのかについて考えてみたいと思います。 今話す前の段階では、なんとなくQAエンジニアやった方は、経験者は、プロダクトマネージャーが向いているというか、結構似ている領域もあるんじゃないかなぁと思っている状態です。 はい、なのでそのこのモヤモヤをですね、頑張って言語化していきたいと思います。 ポイントが4つあって、 1つ目がユーザー視点で考える習慣がある。 2つ目がリスクを見抜く力がある。 3つ目が曖昧な仕様を整理してきた経験がある。 4つ目が部門横断コミュニケーションに慣れていると。この4つの要素があるので、QAエンジニアの経験者は PDMに向いているというか、向いているんじゃないかなという風に思っているという話をしていきます。 順番にお話ししていきます。 まず1つ目がQA経験者はPDMに向いているのか。 1つ目、ユーザー視点で考える習慣がある。 これめちゃくちゃ一番そうだなぁと思うポイントなんですよね。 QAエンジニアの視点というか、一個大事にしている視点として、ユーザーはどういうふうに考えるのか。 ユーザーはどういうふうに行動するのか。 この動線で使いやすいだろうかとか、 ユーザーを想定外の操作したらどうなるだろうかとか、いろいろ考えるんですよね。 使う人の視点でプロダクトを見ています。 これってプロダクトマネージャーも同じなんじゃないかな。 似ている部分もかなりあるんじゃないかなというふうに思ったりします。 QAエンジニアの初心者とか、一番最初の方ってどうしても視点が機能によりすぎてしまって、 この機能をテストするにはどうかという発想になりがちなんですけど、 レベルアップ、スキルアップしていくとですね、 もう少し広くユーザーのどんな課題を解決するのか、 そのために今回の機能は有効なのかというのを考えて、 じゃあこういうテスト必要ですよねみたいに考えていったりとか、 できるようになっていくので、ちょっと話が逸れちゃった気がするんですけれど、 この機能がというものとしてから、 ユーザーがどういうふうに使うだろうか、ユーザーにとって使いやすいだろうかという ユーザー視点で考える習慣が結構あるので、 そういう意味ではPDMにも向いているのではないかというふうに思います。 続いて2つ目、 QA経験者はPDMに向いているのか。 2点目の話はリスクを見抜く力があるです。 これも結構ありそうだなと思うんですよね。 どういうことかというと、QAエンジニアは日々リスクと向き合っています。 いつもリスクのことを考えていると言っても過言じゃないぐらいですよね。 例えば、 今回の新機能の開発において変更がとても大きいとか、 あるいはコアなロジックに今回修正を入れるとなるとリスクは上がるよねとか、 じゃあリスクが高めなら、 雑に言うとしっかりにに細かく機能テストを設計していきましょうとかっていうのも考えるし、 それよりも今回の新機能はそんなに修正範囲は大きくなくて、 どちらかというと目的として機能を出す目的が何かを検証すると。 素早く出して、ユーザーの反応だったり行動というものを検証するためのリリース、機能開発、機能追加であれば、 じゃあちょっと言ってリスクを飲んでというか不安とか、その新機能の部分に関する動作がちょっと動かないとか、 リスクを飲んででも素早く出していきましょう、早くスピード優先しましょうみたいな、 そんなことを考えたりするんですよ。 ここで常にリスクというものは考えています。 プロダクトマネジメントの視点でも、この機能を作った場合のリスク、あるいは今作らなかった場合のリスク、 売上げのインパクトとかでどうなんだろうかみたいなことを考えながら、 ロードマップを考えたりとか、 どの機能を作るのか、その案件というのかな、一つの新機能これを作るぞっていう中でも優先順位って絶対必要だと思っていて、 その時にじゃあこの機能は削ってもよいかの1個の判断軸として、きっとリスクとかってあるんじゃないかなと思うんですよね。 それはシステム的なリスクもあるだろうし、 レプテーションリスクみたいなところ、対ユーザーっていうのかな、人に対するリスクっていうのもあると思うし、 いろんなことを考えて、じゃあ今回のスコープはここにしましょうというジャッジをしていくので、 そこのリスクを考えて判断する。 どのリスクをとるのか飲むのかっていうのはQAでもPDMでも似てる部分があるのかななんて思ったりします。 続いて3つ目、QA経験者はPDMに向いているのか? 3点目のポイントは曖昧な仕様を整理してきた経験がある。 QAエンジニアの場合はPRDとか要件定義書だったり、 あるいは仕様書っていうものをベースインプットとして、 じゃあ今回どういう機能を作ろうとしているのかっていうのを理解したり、 じゃあどういうテストが必要かっていうのを考えたりするんですけれど、 当然完璧な人間はいないし、スピードが求められているという中で、 綺麗にドキュメンテーションされている仕様が最初から揃っているかというと、 まあそんなことはないんですよね、少ないわけなんですよ。 そんな中で仕様書を読んだりとかしながら、こういう場合はどうなんだろうとか、 ここでエラーが発生したらどうなんだろう、 エラーハンドリングちゃんとできているかな、 境界値に当たるときはどういう挙動になるかな、 みたいなことを考えて質問をしたりするんですよね。 これはPDMも似ている部分があると思っていて、 そもそもプロダクトマネジメントとしては、何を作るのか、どこまで作るのかとかを、 ゼロから作っていくっていうのかな、ないものを言語化していくっていう お仕事なんじゃないかなというふうに思ってもいるので、 まさに曖昧な実現したいこととか、やりたいことっていうものをどんどん言語化したりとか、 明確にしていく、明らかにしていくっていう点、 曖昧なものを明確にしていく力っていうのが、どちらもQAもPDMも必要なんじゃないかなって思います。 最後4つ目、QA経験者はPDMに向いているか? 4点目のポイントは部門横断コミュニケーションに慣れている。 これはどうなんだろう、どうですかね、どう思いますか。 QAエンジニアが意外と各部門のハブになるっていうのは、 なんかあるあるかな、周りの職種の方から見てどう見ているかわからないですけど、 QAエンジニア的にはかなりあるあるですね。 開発チームと開発チームの間に入ることもあるし、 特に普通の開発チームで何かプロジェクトを進めていく、開発をやっていくとか、 担当が分かれている、いろいろな境目の部分っていうのが何とかあって、結構ボールが落ちやすくて、 その結合させる部分、チームAとチームBが開発した部分を結合させた状態での挙動、動作確認、動作の保証っていうのが結構ボール落ちやすくて、 どっちも相手のチームでショットを持っていて、どっちもテストしていないみたいなことが結構ある。 規模が大きくなればなるほど、あるあるでして、そんな時にQAチームの間に入ってというか、 テストじゃあやりますねという形で進めていったりするとかもあるので、 開発と話すというか、部門横断コミュニケーションのハブになっているのもありますし、 開発以外にもデザイナーさんだったり、カスタマーサポートの方だったりとか、 ケースの方だったりとか、いろんな人と品質を担保するためにですね、いろんな人と話さなきゃいけなくて、 当然接種を調整というものが発生します。 これはもしかしたら開発エンジニア1メンバーよりかは、あんまりそういう経験はないかもしれないんですけど、 プロジェクトマネージャーもいろんな部門、それこそ開発チームのリーダーだったりとか、 デザイナーさんと一緒にUXを詰めたりとか、 あとカスタマーサポートの方とリリースするときのお知らせとか、 告知みたいなところの調整があったりすると思うので、いろんな人と部門を超えて、チームを超えて、 コミュニケーション、接種を調整するというのは、どちらもやっていることなのかななんて思います。 はい、ということで今回はQA経験者はPDMに向いているのかについて考えてみました。 4つポイントをお話ししてきましたね。 ユーザー視点で考える習慣がある、リスクを見抜く力がある、曖昧な仕様を整理してきた、 部門横断コミュニケーションに慣れているということで、結構なんか共通スキルというのかな、 QAエンジニアの経験がPDMに存分にというのかな、結構活かせそうかなという感じができました。 今日の本編は以上です。 # 今日のほっこり話💡 今日の誇り話です。停電の話をします。停電というかブレーカーが落ちたって話ですかね。 先日サイゼリヤに行ったんですよ。で、ご飯を食べていたらバチッと電気が消えまして、多分ブレーカーが落ちたんじゃないかなという感じだったんですけど、 真っ暗にはならなくて、そういうブレーカーを押した時用の サブ電源みたいなのがあるのか、電球と普段の電球というのかなと違うところが光っていて、 レストランのフロアはそんなに真っ暗にならず、 なるほどなぁと思いながらモグモグしてました。 そういう風に危機管理というか何かが問題が起きた時にもお客さんがパニックにならないようにというか、真っ暗になっちゃったら本当にね なんか怪我とかも起きやすいと思うので、そうならないように、 ちゃんと工夫というか仕組みというか、 準備されているんだなぁというのを今回初めて体験しました。 ちなみにこのチャプターに画像1枚貼っておりまして、 今最善やってバーコードかな、 QRコードみたいなのがついてて、そこからモバイルでオーダーすると思うんですけど、 ちゃんとオーダーをすると今食事中ですとか、食事してない時は食事してませんというのが 表示されているんですけど、それは停電というかブレーカー落ちたらどうなるんだろうなぁと思って落ちた直後の写真を載せております。 画像には、写真には現在はご利用いただけません。ご注文スタッフをお呼びくださいという表示になって、 ほうほうほうと異常経路の場合はこういう表示がされるのかなんて、 ちょっとQA目線でも見たりしました。 何かこうトラブルが起きた時でも指に切り替えて、何ですかね、この機能を維持するっていうんですかなっていうのは、 システム的な用語で言うとフォールトトレラントなんて言ったりします。 システムがね、仮に一部ポンって落ちちゃったとしても、 指に切り替わってシステムが稼働維持できる、続行できるみたいな、そういう仕組みがあるんですけれど、 ソフトウェアの世界だけじゃなくて、物理というかレストランでも、ちゃんとそういう仕組みがあるんだなぁというのは感じた時間でした。 以上今日のほっくれ話でした。 # 次回予告 今回も最後までお聞きいただきましてありがとうございました。 明日はですね、人前で話すことに緊張しなくなったわけについてお話をしていきます。 先日、元同僚とご飯ディナーをしていて、結構サミンさんって 登壇とかしているとこ見てても、ほんとそのままお話しされてますよねっていうコメントをいただきまして ああ、そうか、みたいな。確かにとあるイベントというか、経験した後から 一切登壇とか人前で話すときに緊張しなくなったんですよね、とのお話を明日はしていきます。 今回の放送が役に立った、楽しかった、今日も聞きに来たような映像で 是非ハートマークを押していただけると、とっても励みになります。 コメントもお待ちしております。 それではまた明日。お会いしましょう。ごきげんよう。