product engineering with qa

JaSST 26 Kansai登壇資料 (https://jasst.jp/kansai/26-about/)

【概要】
「Park Direct for Business」の開発組織では、プロダクトエンジニアとQAが互いの領域へ染み出しあう協業を実践しています。
プロダクトエンジニアはLLMを活用してテスト観点出し・テスト設計から実行までを担い、QAはPRD・仕様レビューの上流から観点を注入しています。過去のQAナレッジはテスト観点カタログとして資産化し、AIの共通のコンテキストとして育てています。
仕様駆動開発を土台に、役割の濃淡を保ちながら品質と開発速度を両立させ、プロダクトをスケールさせる取り組みを、プロダクトエンジニア/QAの視点から紹介します。

Transcript

1. 職種の境界を染み出しあう品質保証 PdEがテストへ、QAが上流へ、AIとともに 2026.07.03 JaSST Kansai 株式会社ニーリー 古庄 和也 @k_furusho_ NEALLE 1
2. 2025年10月にニーリーに入社 プロダクトエンジニアとしてPark Direct for Businessのプロダクト開 発に従事。 第一子が誕生し、仕事と育児の両立に奮闘中。 2 自己紹介 @k_furusho_ 株式会社ニーリー プロダクト本部 PDBiz開発G リーダー Kazuya Furusho 古庄 和也
3. 3 会社・プロダクト紹介
4. 4 会社・プロダクト紹介 駐⾞場業務を 委託 法⼈⾞両向け駐⾞場管理SaaS「Park Direct for Business」 駐⾞場探し ⽀払い代⾏ 契約代⾏ 法令‧税務対応 導入企業様 管理会社 オーナー 契約/⽀払い などの⼿続き代⾏ インボイス対応/ 契約などの⼿続き代⾏
5. 1. ニーリーにおける プロダクトエンジニア・QA 2. どう染み出しあっているのか 3. 境界の染み出しを、AIとオントロジーで支える 4. 具体的な変遷と、今後の展望 5 目次
6. 6 1. ニーリーにおけるプロダクトエンジニア・QA
7. プロダクトエンジニア＝価値提供を最速で実現する 7 ニーリーの PdE
8. QAは、インプロセスQA ニーリーの QA 8
9. 9 2. どう染み出しあっているのか
10. QAの主なプロセス 10 QAが染み出すプロセス
11. 11 インプロセス（チームの中で） 上流⼯程のレビュー 複雑な業務ロジックを整理‧精査。曖昧さ‧⽭盾を早期に抽出し、⼿戻 りを最⼩化 テスト分析‧設計‧実⾏ 価値と開発スピードを両⽴する、最⼩で最⼤の効果を⽣むテスト 横断（QA チームとして） Playwright シナリオの作成‧保守 E2E ⾃動テストで開発の速度と信頼性を両⽴。SET の⽀援でメンテしや すく Biz⇔Dev のハブ‧不具合分析 ‧ プロセス改善 両⾯を理解するから、認識ズレのない仕様調整と、本質的な再発防⽌が できる ＋ 社内勉強会‧外部発信で、知⾒をチームと社外へ広げる
12. 仕組みは、⽇々の運⽤から⽣まれた 12 染み出しから生まれる改善の仕組み 業務の解像度も、⼀緒に上げる 実データ‧実際の管理業務にあたって確かめる 事業部の OJT に、QA と PdE の両職種で参加 PdE が商談で得たことを、即 QA へ共有 権限管理のような複雑な設計も、PdE/QAで詰める 現場の事実が、毎⽇流れ込む 毎⽇リファインメント＋ 週次のアゲアゲ会 QA と PdE が、困りごと‧やりたいことを持ち寄る。出して、試し て、改善する。 ⾃然⾔語リグレッション 観点カタログ資産化 テストケースのスキル化 プロセス⾒直し フルリモート環境で、密に課題を持ちより、PDCA を回してきた 毎⽇顔を合わせて情報伝達する関係があった。染み出しは、その積み重ね
13. 要求整理段階にシフトレフトを加速 13 染み出しから生まれる改善の仕組み prd-domain-check (AI) 仕様の変更が、どの業務ルール‧どの観点に波及するかをオントロジーと突き合わせ、考慮漏れを実装前に指摘す る。 ‧ ドメイン知識（オントロジー）を活⽤し、⼈間の設計思想をAIがサポート ‧ 実装が始まる前の、最も⼿戻りコストが低い「仕様書フェーズ」で⾃動検知 ‧ 属⼈化しがちな複雑な業務仕様ロジックのチェックを標準化 できあがってから⼿戻りを引き受けるより、仕様の段階で観点を置くほうが、⽋陥は早く安く消える。
14. 14 入力 PR / シナリ オ STEP 1 仕様確認 STEP 2 観点設計 観点カタログを注入 STEP 3 テスト⽣成 STEP 4 Playwright 実⾏ 観点出し〜実⾏を、PdE が回す AI が「シニア QA」の役割で観点を設計し、テストまで⽣成する。各 ステップは⼈が確認して次へ。 回帰テストは、⾃然⾔語のまま保守 画⾯が変わっても、直すのは⽇本語のシナリオ。SET の⽀援と、⾔葉 ‧ガイドラインが安定性を担保する。 テストは QA だけのものではなくなった。PdE も、AI とともにテストへ染み出す
15. 15 3. 境界の染み出しを、AIとオントロジーで支 える
16. AI が動かし、オントロジーが地図を与える 16 AIとオントロジー ① AI 動的な実行と増幅 上流レビューからテスト設計・実行・保守まで、 AI とともに 回す。1人の踏み込みを、 AI が増幅する。 ② オントロジー 共通前提と揺るがぬ境界 業務を言葉とつながりの地図にし、人も AI も同じ前提で動 く。踏み込んでも、解釈が割れない。 真ん中を貫くのは、 QA の知見。1人の観点を、チーム全体と AI に効かせる
17. 仕様の SSOT を、ドメインで構造化する AIとオントロジー 17 Repository docs/ 構成定義 docs/ ├── domain/ 常に最新のドメイン仕様 │ ├── glossary.md 用語の定義 │ ├── context-map.md 関係 │ ├── viewpoints.md 観点 │ └── contract / application / ... ├── system/ データフロー・連携 ├── flow/{ticket}/ 案件の PRD・DD └── _templates/ ・ architecture/adr/ .claude/ skills / rules / agents → 全 AI へ Stock ドメイン仕様（stock） 常に最新を保つ、業務の共通知識。契約・申込・請求...をコン テキストごとに整理 Flow 案件仕様（flow） チケット単位の PRD・Design Doc。作っては積もる、時系列の 記録 AI Delivery .claude で配る skills / rules / agents 経由で、同じ前提を全 AI へ渡す ポイントは stock と flow の分離。常に最新のドメイン層を、人も AI も同じ土台として参照する
18. 4 分類した知識コンテキストで、品質を 持続可能にする AIとオントロジー 18 概念 glossary.md ｜ 何が在るか ドメイン用語をユビキタス言語として定義（用語・英語名・定義） 関係 context-map.md ｜ どう繋がるか 境界づけられたコンテキストと依存（契約 → 請求 など） 制約 各 rules.md の BR-XXX-NNN ｜ 何が正しいか 業務ルールを ID 付きで定義（例： BR-CON-005 自動更新） リスク viewpoints.md ｜ 何を見落とすか 抜けやすい観点。対応する BR を参照 オントロジーとは ある領域に「何が在り・どう関係し・何が成り立つか」 を、明 示的に共有した概念体系。左の 4つ（概念・関係・制約・リス ク）がまさにそれ。 例）申込（Application）と契約（Contract）は別概念、と用語集で一 度定義しておく。だから「契約」と言えば、人も・テスト生成 AI も・レ ビュー AI も、同じ Contract を指す。 定義が1つ ＝ 解釈が割れない ＝ AI が取り違えて作り込 む余地が消える
19. 文書は現実とズレていく。だから 変更のたびに 検証・同期する AIとオントロジー 19 事前 仕様を書く前 prd-domain-check 変更がどのルール・どの観点に波及する かを、関係の地図と突き合わせ、 考慮漏 れを指摘 執筆時 仕様を書くとき spec-reviewer / validate-spec 用語の一貫性・相互参照・受け入れ条件 と、文書の構造を 検査 事後 実装が終わったら update-domain-from-pr マージ済み PR の差分を一次情報に、ドメ イン仕様を実装の実態へ同期 同期の過程で見つかった新しい落とし穴は、 観点カタログへの追記候補になる。変更が、地図を育てる。 知識の体系を維持し続けることは、知識工学の古典的な難問。 検証と同期を変更のライフサイクルに埋め込む ことで、常に実態に即した「生きた地図」に保つことができます。
20. 観点カタログを 4カラムで運用 AIとオントロジー 20 観点 チェックの狙い 確認すること 見落とすと アップロード経路の網羅 同種の処理が複数画面に散在。 1経路だ け直す事故を防ぐ 変更が全アップロード経路（契約詳細・明細管 理・一括取込...）を対象にしているか 一部だけ新仕様、他は旧挙動のまま不 統一 編集経路の二重性（契約編 集／申込編集） 同じ項目に、編集経路が 2系統ある 新項目・補助UIが両経路とも仕様・設計・テスト の対象か 片方の画面から入力・操作できない 絞り込みのCSVへの波及 一覧の絞り込みはエクスポートにも及ぶ べき 絞り込み適用時、結果が絞り込み後のみになる か 全件が出力され対象外が混入 viewpoints.md「変更の波及先の見落とし」より（一部抜粋） 当たり前の正常系は載せない。 見落としやすい観点だけ を書き、 業務ルールの番号で逆引きできるようにする。同じ 1行が、上流レ ビューと自動テストの両方を駆動する。 育て方 その場かぎりの観点は弾く。 QAがカタログの品質を握り、 PdEが日々の発見で太らせる。
21. 21 4. 具体的な変遷と、今後の展望
22. 入社から現在までの変化 22 具体的な変遷と、今後の展望 軸 2025.10 入社時 / すでにあったもの この 10 ヶ月で深めたこと QA の立ち位置 インプロセス QA として各チームに 上流レビューを主導し、テストは境界をまたいで分担 QA 観点 主に各人の経験知 観点カタログに資産化し、共通の地図にする テスト QA 主導 PdE が AI で観点出し〜実行、自然言語で回帰テストを保守 AI 活用 個人利用 全員と全 AI に同じ作法・同じ地図を配る すでに回っていたインプロセス QA の上で、染み出し合いを深めた。 だからスケールしても、品質保証がボトル ネックにならない
23. 手応えと課題 23 具体的な変遷と、今後の展望 手応え (成果) 着実な品質向上と効率化のループ 新規参画者と既存メンバーの、見落としの差が縮まった QA を増やさず機能を増やせた 観点の再利用・早い段階での欠陥検知・テスト資産の保守 性向上 まだ難しいところ (課題) AI時代における運用と信用の設計 AI は観点を出しすぎる・もっともらしく外す 人が確認するコストの最適化 カタログを保つ運用の手間
24. 今後の展望 24 具体的な変遷と、今後の展望 オントロジーを、より機械可読な形へ Markdown 中心の今から、知識グラフ的な検索と MCP で、AI がより厳密に参照できる形へ 観点カタログの育成を、半自動に 実行で得た新しい観点を還元し、カタログ更新の手間を下げる 多プロダクトへ、横展開 インプロセス QA ＋ オントロジーを、新規プロダクトにも広げる 効果を、定量で語る 前倒し検知率・手戻り削減を測り、未然に防いだヒヤリハットの 計測 目指すのは、事業のスケールと、品質保証が “仕組みごと ”スケールする 状態
25. この10 ヶ月、いちばん助けられたのは、 QA の「見落としを言葉にできる専門性・知識」。 それが共有資産になったとき、チーム全体と AI に効きはじめた。 プロダクトエンジニアと QA が相互に染み出し合うことによって、 AIともに品質を作るサイクルは確立できる。 QA の観点が、チームと AI を動かしていた 25 まとめ
26. end 26