UQAMのその先

以前公開した「UQAM; Usage-model-driven QA Methodology」(https://speakerdeck.com/ukigmo_hiro/uqam-usage-model-driven-qa-methodology-noshao-jie )を、プロダクト開発全体に拡張したモデルについて整理しています。

PdM・Sales・CS・SRE・Marketer・Designer・FE/BE・TE・QAなどの各ロールと生成AIが協業しながら、PBI作成・仕様モデルの更新・デザイン・インクリメント実装・テスト開発・リリース判断までを進める流れをスイムレーン風のPFDでモデル化しました。

特徴は、生成AIにタスクを委託するだけでなく、PBI作成やリリース判断の意思決定モデル・仕様モデル・レビュー観点図・テスト観点図・テストアーキテクチャといった「AIの手綱」そのものを、プロダクトQAの対象として扱う点です。
UQAMのその先として、AI時代のプロダクト開発とプロダクトQAのあり方を考えるための試論です。

Transcript

1. すずき UQAMのその先
2. この資料の概要 • 以前、UQAMという⽅法論を紹介するスライドを公開しました ▪ UQAM(Usage-model-driven QA Methodology)の紹介 • この資料内で明⾔はしませんでしたが、 はっきり⾔ってこの⽅法論はある種の妥協案‧現実解のつもりでした • しかし、⽣成AI周りの技術の発展は本当に早いもので、 また、それらの活⽤知⾒の蓄積スピードも、業界の努⼒により凄まじく、 公開から半年も経たない内に、理想案の実現可能性が出てきたと感じています • そこで、本資料にて、この“理想案”である 「UQAMをプロダクト開発全体に拡張したモデル」を、雑に公開してみます ▪ 従って、もはやUʻQA’Mではない ▪ 2ヶ⽉ぐらい前に作って、公開するのを忘れていたのです なのでもはやこれも古いのかもしれないなァ…… 2
3. 3 PDF版: https://ukigmo.work/qa/beyond-uqam-product-development-model.pdf
4. 全体的な解説 • 全体を通して、和⽥卓⼈⽒が講演の中でたびたび仰っている、 伴⾛と委託という2つのモードを使い分けています ▪ 伴⾛のスタイルとして、UQAM同様BFBL(Boosted FeedBack Loop)を推奨しています ▪ 参考: • AIとの協業の2つのモード: https://speakerdeck.com/twada/software-engineering-scrum-fest-niigata-2026-edition?slide=5 • UQAMのBFBL: https://speakerdeck.com/ukigmo_hiro/uqam-usage-model-driven-qa-methodology-noshao-jie?slide= 10 • また、本モデルのスコープは、プロダクト開発全体です ▪ QAは、経営の品質をも含んだ、あらゆる品質を保証するロールであるべきと思っています ▪ そのため、このモデルの最下⾏には「プロダクトQA」という、 プロダクト品質に特化したQAを指す⾔葉を当てています • プロダクトQAはプロダクト開発のプロセスや「AIの⼿綱」の品質を保証します ▪ それとは別に、テストに特化したロールであるテストエンジニア(TE)を置いています • TEというネーミングはQMファンネルを参考にしています 4
5. もう少し細かい解説 (この⽂章をAIに読ませたらええんや) 1. SRE‧マーケター‧PdM‧営業‧CS等々のロールが、利⽤状況のモニタリングデータやマーケ施策の効果データや展⽰会/ 打合せでのやり取りなどを、AIがアクセスできる場所に置きます。それらの情報をもとにAIがPBI案を作成します 2. PdMがPBIについてAIと議論してブラッシュアップさせます 3. PBIが固まったら、AIは、UCODなどの仕様のモデルを更新しつつ、デザイン案を作成します。仕様のモデルはQAが、デザ イン案はデザイナーが、それぞれレビュー‧議論‧ブラッシュアップ/修正の作業を⾏います ▪ UCOD: https://github.com/hansuoi/ucod 4. 次にAIは、プロダクトのインクリメントをTDDに基づいて開発します。インクリメントは⼈間のフロント/バックエンドエン ジニアが適宜レビュー‧修正します 5. 次に(あるいは4.と並⾏して)AIは、システムテストを開発し、テストエンジニア(TE)からのレビュー‧修正を受けます。当該 テストスイートは、基本的に⾃動実⾏されますが、⼀部どうしようもない部分はTEが⼿動でBET的に実⾏します ▪ BET: https://ieeexplore.ieee.org/document/9440172 6. 得られたテスト結果をもとに、AIがリリース可否の判断材料や推奨判断を提⽰します。最終決定は⼈間が下したほうが良い でしょう 7. リリース/デプロイが⼈間のタスクになっていますが、AIにやってもらってもいいかもしれませんね • 下記のモデル群(UQAMの表現で⾔うところの「AIの⼿綱」)は、QAが関連ロールと連携しながらモデリング/更新します ▪ PBI作成やリリース判断の意思決定 (どの要望をPBIにしてどの要望はまだストックとするのか‧どの程度の不具合なら許容してリリースするのか‧etc.) ▪ デザインやコードのレビュー観点図 ▪ モニタリング‧単体/結合/システムテストのテスト観点図 ▪ テストアーキテクチャ • モデル群やプロンプト群が⼤量に⽣まれるので、プロンプトウェアアーキテクチャの整備も並⾏して⾏うとよいでしょう 5
6. 「その先」のさらに先 • 「プロダクト開発全体版UQAM」が確⽴された後は、 以下のような発展の流れがあり得そうだなと思っています ▪ ▪ マーケティング‧営業‧CS‧etc.の改善を⾏い、 より良い情報をより効率的に得られるようにする ▪ バックオフィス業務の改善を⾏い、 企業としての基礎筋⼒や⼈材市場におけるブランドなどを向上させる ▪ ⾃分の⾮専⾨領域について勉強し、よりマッチョな⼈材を⽬指す また、組織の苦⼿領域についてチャレンジし、組織全体のスキルセットを増強する ▪ ユーザが当該プロダクトを使っている現場に赴くなど、 ユーザ価値についての解像度を上げ、そして議論するための時間を増やす ▪ 経営の品質や意思決定の品質を改善し、より強くよりタフな組織を⽬指し続ける 6
7. おしまい