1⼈1案件のプロダクトエンジニア時代に "プロセス監督"としてチャレンジしたこと のんちゃん / Voicy 2026/5/19 

⾃⼰紹介 菊池のぞみ / のんちゃん ‧株式会社Voicy / QA + 技術広報 ‧労務⼈事７年 → QA歴１年⽣ ‧X：@voicy_nonchan ‧ランニングと旅⾏が好き💖 Voicyチャンネル 学びのデバッグログ QAゼミチャンネル 

No content

BACKGROUND / 背景 新体制への短期的なチャレンジ開始💪 BEFORE ◯◯エンジニア時代 「Androidエンジニア」「Webエンジニア」 「QAエンジニア」など役割が固定 チームの中で得意領域を分担 NOW プロダクトエンジニア時代 AIを活⽤して「全員が全部できる」 プロダクトエンジニアを⽬指す⽅針へ ⼀⼈で1案件を完結させる動き 🆕 ⼀⼈1プロジェクト × 3案件並⾏の体制に 🆕 プロジェクト計画書ベースでの開発 

DEFINITION / 定義 「プロセス監督」という新たな役割の定義 QAエンジニアが担う「プロセス監督」とは何か？  進⾏のチェック プロセスが問題なく進んで いることを客観的に確認‧ チェックする  品質の担保 プロダクトの品質に問題が ない形で開発が進むよう、 プロセスを監視する  障壁除去‧報告 課題解決のために障壁を取 り除き、開発責任者へエス カレーションを⾏う 

APPROACH / 進め⽅ 計画書を作成 プロジェクト 計画書 開発の話は ここを⾒ればわかる SKILL 計画書作成Skill チームで運⽤を統⼀ ついでに漏れがちな項⽬を チェックリスト化 

PROBLEM / 直⾯した課題 直⾯した2つの課題 1 ドキュメントが追いつかない 開発が進むと要件はどんどん変わる 決定がSlackに散り、ログが残らない 後から探すのに時間がかかる 2 多案件を⼀⼈で追えない これまで2チーム掛け持ちで⼤変だった 1チームで3案件が同時並⾏に 進捗‧仕様変更の追跡が物理的に困難 課題は、「情報の分散」と「追跡コスト」 

APPROACH / ⼯夫 計画書をハブに、2つのSkillで⽀える プロジェクト 計画書 開発の話は ここを⾒ればわかる SKILL 計画書作成Skill チームで運⽤を統⼀ ついでに漏れがちな項⽬を チェックリスト化 SKILL プロセス監督Skill 最新の計画書を取得 差分をまとめて報告 進捗のダブルチェック ⾃分がメインで動きつつ、Skillsでダブルチェックする体制 

APPROACH / ⼯夫 04 / 09 ⼯夫したこと 01. 差分の追跡 差分だけを追えるようにした 仕様の変更やリリースタイミングの 変更など、⽇々変わっていく細かい 情報を追えるように 02. アラートの導⼊ リードの役割とエスカレーション 「⽔曜⽇までに終わっていなかった ら、PdMにエスカレーションする」 など⚠アラート⚠を仕組み化 ⾃律的なプロジェクト推進と、迅速な意思決定の仕組み化 

INSIGHT / 気づき 06 / 09 「プロセス監督」=QAが普段やっていること 01 仕様の空⽩を埋める TBD‧要確認‧未定義に 気づき、決定を促す 02 ボトルネックを⾒つける 進捗の詰まり‧依存関係のリスクを早期に検出 03 情報を届ける 関係者に過不⾜なく 意思決定の根拠を共有 04 認識を合わせる 暗黙の前提を⾔語化し、チームの理解をそろえる わからないことは突っ込んで質問する 役割名が変わっても、QAの本質的な動きは変わらない 

CHALLENGE / 難しかったこと 07 / 09 まだ解けていない論点 01 「チームとして動く」の再定義 技術相談は別途⾏うが、 レトロスペクティブ（チームの振り返り）は 全員で⾏う ⾃分の解像度が前ほど⾼くなく、 本質的な振り返りを設計しにくくなった？ 02 頭の切り替えコスト 進⾏中の案件が多いと、 コンテキストスイッチが重い Skillである程度補えるが ⼈間側の負荷は残る → 正直まだ答えが出ていない領域。同じ悩みがある⽅がいたらお話ししたい🥺 

CLOSING QAは「プロセスを監督する役割」 として動ける 体制が変わっても、QAの本質的な動きは変わらない AIを味⽅につけると、QAの関わり⽅の幅が広がる 「チームとして動く」の再定義は、これからの宿題