TOPハウツー・学習テクノロジーSoftware Testing Journey🌍#192 なぜQAエンジニアはプロジェクト管理が得意な人が多いのか12:59 2025年6月21日 190再生 問題を報告する 再生する シェアする AI目次QAエンジニアとプロジェクト管理の意外な関係性とはプロジェクト管理が得意な理由、2つの仮説とはリスクベース思考がもたらす効果とはリスナーからのコメントに答えます今後の配信予定と視聴者参加への呼びかけAI文字起こし(β版) # タイトルコール ようこそ、世界が広がるソフトウェア品質展。 このチャンネルでは、キューエンジニアのサミーが、ソフトウェアテストやソフトウェアの品質保証を中心に、日々奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、テストウェア品質の世界を広げていきます。 # 📣6/24火20時から生放送 いよいよ生放送まであと数日となりました。 6月24日火曜日夜の8時20時から生放送を行います。 ゲストに大平さんをお呼びして、 コミュニティ運営にかける思いをお伺いします。 6月24日火曜の夜8時からです。 # なぜQAエンジニアはプロジェクト管理が得意な人が多いのか こんにちはQAエンジニアのサミリです。 今日もゆっくりお休みできていますか? 今回はですね、なぜQAエンジニアはプロジェクト管理が得意な人が多いのかっていうところをお話ししていこうと思います。 なんか前からなんとなく思ってたんですよね、数年前とか。 あと採用活動でQAエンジニアの採用に携わっていた時とか、 すごい感覚の話です。定量的な数値データは全くないんですけれど、 自分の感覚、所感としてプロジェクト管理やってました、みたいな。 カジュアル面談とか面接とかお話しする中で、そういう方が多いような気がすると。 なんでなんだろうなーってずっともやもやというふうに思ってまして、 今回考えてみたんですけれど、ポイントが2つあるのではないかと思っております。 ポイント一つ目が、自分の仕事というか、テスト設計とかテスト実行のタスクを持っていることが多いかなと思うんですけど、 それって誰かのタスクの後工程なんですよね、絶対に。 開発のタスクの後にテスト実行を行うとか。 テスト設計だったらソフトウェアの設計と全く同時期というよりかはちょっと後ろとか同時期とか、 もちろんプロセスによってはテストを先に作るというパターンもあると思うんですけれど、 テスト実行は絶対誰かのタスクの後になるかなと思ってます。 そうすると、全体像とか、今この開発のタスクはここまで進んでいて、 こっちのタスクはここまでで、じゃあ自分の後工程のタスクはこのくらいになりそうとか、 もうすぐ明日ぐらいに来そうかなとか、いろいろ見る必要がある。 そうしていかないと自分のタスクが差し込みになっちゃうんですね。 差し込みになっちゃうとコントロールしづらいというか、スケジューリングしづらいとなっちゃうので、 なんとなく予想でもいいし、その時点の情報でもいいので、 大体このくらいに自分のタスクが入りそうだなというのは、いつも把握するようにしてます。 来週そろそろだなとか、明日そろそろだなみたいなのは把握してるわけなんですけど、 ある程度全体像を把握してないと自分の仕事がしづらいのでは、そういう傾向があるのではというふうに考えてます。 なので、そろそろ自分のタスクが来るはずなんだけど、なかなかこれ終わりましたみたいな連絡が来ないなってなると、 あれ大丈夫みたいな全体のスケジュールでいついつまでにリリースをするっていうのは大体決まってると思うんですけど、 そこから自分の作業時間っていうのを逆算というか、逆算化するとここまでには終わってないといけない。 なんだけど、まだ今日の時点で依頼が来てない、これって大丈夫みたいな。 そういうのってよくありました。 最初の時というか、ジュニアの時っていうんですか、最初の時は何とか残業をして間に合わせるとか、 残業しても終わらないので、何日あと何時間とか何日くださいみたいな感じでテスト実行ガツガツやるみたいな。 具合が見つかったら修正をしてもらって、またその修正確認をするみたいな。 そんなことをしていたわけなんですけれど、それじゃやっぱり良くないじゃないですか。 自分の体力っていうところもそうだし、差し込み型になってしまうとスケジュールも読みづらいし、 そもそも期日がある、いつまでリリースしたいっていうのがあって、そこに間に合ってないっていうのはそもそも良くないので、 じゃあどうしたらいいんだろうっていうのを考えていくと、プロジェクト管理につながっていくのではというところがあって、 全体像を把握する全体のスケジュールとかマイルストーンとか、いつ頃までにここまで進んでなかったら プロジェクトとしては想定よりは遅れているねっていう勘どころだったり、 もちろんチームの中で合意することも大事なんですけど、勘どころとかもって取り組んでいるということがそういう風になりやすいので、 QnGにはプロジェクト管理が得意な人が多いのではないかというのが私の一つ目の仮説です。 もう一つの仮説が、リスクベースで物事を考えている癖がついている人が多いのではというのが二つ目の仮説になります。 ソフトウェアアナリストの勉強、経験ももちろんそうですけど、勉強を重ねていくと、 JSTCBの例えばアドバンスドレベルのテストマネージャーだったり、同じくアドバンスドレベルのテストアナリストの勉強をしていくと、 リスクベースのテストの話が出てくると思います。 リスクのアセスメントとか、リスクを識別してアセスメントをして、 そのリスクを軽減するための手法としてどういう手法が必要かというところを考えて実行する、 そういうリスクベースのテストがあると思うんですけど、 テストという意味でも全てをテストすることはできないので、 じゃあどこに重点を置くか、テストを一番厚くするのか、どこが薄くするのかというのを考えたときに一つの考え方として、 リスクの高いところは厚めにしましょうとか、最初にテストを実行しましょう。 それによって一番不安な部分とか、あるいは不具合、大きな致命的な不具合があったときにビジネスインパクトが大きい箇所からテストしていくことで、 早めにリスクを潰していくというか、何か問題を早めに検出するというのが大事になってくるわけです。 これをプロジェクト管理に当てはめてみると、リスクが高いところ、機能を、 例えば不確実性が高い機能から作っていこうとか、一番コアな機能から作っていこうとか、 手元にあったときに一番コストがかかりそうなところから開発していこうとか、そういうふうに考えることができるかなと思いますし、 リリースまでのスケジュール間と、大体いつまでに、ここら辺の機能まで終わっていないといけないとか、 マイルストーンを決めて、そのタイミングで想定しているところまで進んでいなかったら、 遅延だよねとか、アラートを出さなきゃいけないねとか、 何て言うんですかね、ちょっとあまりうまく言語化できていない理学はあるんですけれど、 タスクを一個一個積み重ねていって、終わりそうだねっていう順調に進んでいってるねっていう見方と、 同時に一方で全体像から逆算だったりとかを考えて、このままのスピードだったら、このままのベロシティの場合終わるんだっけとか、 そんなことを考えながらプロジェクトを見守ってたりとか、一緒にバンスを走ってたりっていう気がしますね。 どうなんですかね、結局そこで開発の進捗、実装の部分の進捗が遅れると、 自分にしわ寄せがくるってどこかで心の隅で思っているのかもかもしれないですね。 あと往々にして見積もりってどうしても少なく見積もりがちなんですね。 やっぱりプロジェクトが進んでいく中でこれも考えなきゃいけないとかっていうのは大体見えてきて、 タスクが増えたりとか考慮しないといけないことが増えたりとかして、大体後ろ倒しになるんですよ。 その時によくあるあるなのがテストの期間が短くなるっていうのがあるあるなので、 そうならないようにウォッチしてるっていうのはもしかしたらあるのかもしれません。 最後におまけの話なんですけれど、先日ファインディ×ボイシー主催の イベント音声で切り破くAI時代の生存勢力っていうイベントに顔を出しておりまして、 その時にファインディでCTOされている佐藤さんという方と少しお話しする機会があったんですけど、 佐藤さんがEMFMっていうポッドキャストをされてるっていうところでいくつかエピソードを聞いてて、 2月5日これいくつなんだろう、タイトルがプロジェクトマネジメント、タスクから見るかリスクから見るかっていうエピソードがありました。 これが今回のプロジェクト管理の話すごくマッチするなというか聞いててなるほどなって思ったので、 興味ありましたらぜひ聞いてみてください。 ということで今回は、なぜ旧エンジニアはプロジェクト管理が得意な人が多いのかっていうところを考えてみました。 仮説は2つあって、1つがテスト設計とかテスト実行のタスクっていうのは誰かのタスクの後工程なので、 全体像を把握しないと自分の仕事がしづらいのではっていうのが1つ。 もう1つの仮説はリスクベースで物事を考える癖がついているからではないかっていうのが私の仮説です。 よかったらコメントで皆さんのご意見聞かせてください。 # #185のコメント返し😍 コメント返しのコーナーです。今回は185話目のコメントをお返しします。 1週間前の185話目は、燃え尽けないために頑張りすぎない骨三線についてお話ししました。 コメントは一見松さんからいただいています。いつもありがとうございます。 体力的な疲れとメンタルで反応って違いますね。 体力的なお疲れサインは社員賞の代わりにスイカが出します。 ぼーっとしてるんですね。メンタルのサインは辛いですよね。 デビュー中に突然涙出てきた時ありました。びっくりしてその場から逃げ出しました。 メンタルは自分が気づくサインが出た時点でアウトな気がしますね。 そういえば最近ニコカレって引かなくなった気がしますがどうなんでしょう。 チームで気づく仕組みの代表格のイメージはありますね。 ということでコメントありがとうございます。 いやー、社員賞の代わりにスイカはさすがに、さすがに? そうですね、それはとてもお疲れですね。 もう一個のメンタルのサインも確かにメンタルのサインが出ちゃったらアウトは確かにって思いました。 最近はもう会社で泣くっていうのはないですけど、さすがにというか。 1年目はよく会社のトイレで泣いてました。 で、初日は上司とワンワンやっていて泣きました。 部署の人というか周りがざわっと入れたらしくて後から私は聞いたんですけど、 進入サイン泣かしたみたいな、上司の方が泣かしたみたいな感じになってたらしいんですけど。 実際はですね、いろんなことを聞かれたんです。 どういう風になりたいかとかキャリアのこととかを聞かれたんですけど、 私は全然答えられなくて、あと若干脳がパニックったみたいな、 パニック状態になったっていうところがあって、涙が出てしまったっていうことではあるんですけどね。 話がされました。 最近ニコカレって聞かなくなった気がしますか? 私ニコカレっていうのは何だろうと思って、あんまり聞いたことなくて調べたら、 たぶんニコニコカレンダーのことですね。 確かにこれを見てみると、今日の気分は?みたいなので、 メンバーの気持ちを身にかすのは、言われてみれば聞いたことはあるけどやったことはないなという感じですね。 ということで、コメント返しでした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回は週末版になります。 フォロワー200名を達成したらやってみたいことがありまして、 やってみたいことについて、いろいろ思っていることを話したり考えていることとか、 あと妄想も含めていろいろお話ししていきたいなというふうに思っています。 リスナーの皆さんと一緒にコミュニティを作っていきたいと思っているので、 ぜひぜひコメントをお待ちしております。 いつも以上に明日の放送にはコメントをお待ちしております。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は、 ぜひ画面右下のハートマークでいいねを押していただけるととても励みになります。 ぜひぜひSNSや口コミでのシェアもよろしくお願いします。 それではまた明日お会いしましょう。ごきげんよう。 もっと見る #QA #ソフトウェア #プロジェクト管理 Software Testing Journey🌍プレミアム放送配信中!00:181.タイトルコール00:162.📣6/24火20時から生放送09:163.なぜQAエンジニアはプロジェクト管理が得意な人が多いのかhttps://podcasts.apple.com/jp/podcast/em-fm-emfm/id1438349747?i=100068907423802:164.#185のコメント返し😍00:555.次回予告コメント感想・質問・応援メッセージを書こう
#639秋の夜長、時間を味わう 9分・一昨日・ 90再生AI目次スマホなしで味わう贅沢な時間“時間を使う”から“味わう”思考へ現代人が失った「何もしない」価値大喜利カードゲーム開発秘話の深掘り感謝と熱気!ゲームプレゼント企画
#638 『Taking Testing Seriously』 10章より 7分・9月11日・ 56再生AI目次『Taking Testing Seriously』品質特性の新定義プロジェクトに最適化する品質特性の思考プロダクトの『カリスマ性』を測る指標ユーザーを惹きつける10の評価要素季節の変わり目に感じた気温のサプライズ
#637要求と要件の違い、説明できますか? 11分・9月10日・ 111再生AI目次要求と要件の混同とその影響旅行のたとえ話で学ぶその違いISTQB定義と開発現場での応用本当に達成すべきゴールを見極めるヨーロッパ購入の特別な石鹸を捜索
#636 あと何回両親と食事ができるだろうか? 14分・9月9日・ 129再生AI目次「グッドライフ」が語る両親との時間限られた回数で気づく家族との絆リスナーのコメント:災害への備え仕事を抱え込まないチームの秘訣次回予告:要求と要件の違いとは?
#635 カードゲーム作りの難しさと面白さ 1時間1分・9月8日・ 64再生AI目次声優への愛から生まれた「マッピンカルタ」ゲーム発想の源泉、独自の思考プロセス仕事の複雑さをゲーム化する難しさクリエイターに共通するゲーム作りの型未発表「狩猟ゲーム」とQA愛の真髄
#634 仕事ができる人ほど「問いを持っている」 14分・9月7日・ 127再生AI目次「問い」を持つ人が仕事で強い理由QAエンジニアに不可欠な「問い」の視点良い「問い」を持つための3つの秘訣「自分がいなくても回る業務」の意義別府温泉で満たされた「温泉欲」
#633 ばさつさんと、大喜利カードゲーム作りについて 1時間0分・9月6日・ 68再生AI目次おもちゃ作りへの原点と妄想家コミュニティ「選ぶだけ大喜利」ゲームの着想2年間の試行錯誤!ルール簡素化の秘訣「パワーワード問題」を越えた言葉の妙印刷・PRの苦労とゲムマ出展の現実