なめらかな"品質保証"と、その敵〜開発者が知っておくべきQAの本質とAI活用テスト設計〜

2025/12/16に開催された、【WAKE Career主催】の「なめらかな"品質保証"とその敵〜開発者が知っておくべきQAの本質とAI活用テスト設計〜」の登壇資料です！

https://wake-career.connpass.com/event/376011/

Transcript

3. 3 ユニファ株式会社って、どんな会社？ 保育施設向けの総合ICTサービス「ルクミー」を提供している会社です
4. 4 ユニファ株式会社って、どんな会社？
5. 5 ユニファ株式会社って、どんな会社？
6. 今⽇のセッションの流れ（ざっくり） 6 最初に、Demoをお⾒せします！
7. 今⽇のセッションの流れ（ざっくり） 7 ⾼⽥が考えている「品質の本質」をベースに、 AIを活⽤したテスト設計について、お話します！
8. アジェンダ • なめらかな"品質保証"と、その敵 • AIも理解できる「品質の構造」 • 「構造化」によるAIとの共創ワーク フロー • まとめ 8
9. 9 なめらかな"品質保証"と、その敵
10. なめらかな"品質保証"と、その敵 10 技術スタック • 「Cursor 」+ 「spec-kit」を使⽤ ◦ Claude codeや、Github Copilotなどに対応。 ◦ 対応の詳細は、 https://github.com/github/spec-kit?tab=readme-ov-file#-supported-ai-agentsを参照 願います。 ◦ spec-kit の“道具箱”（.specify/ 配下のファイル）を使⽤して、テスト設計をAIと共に作って いきます。
11. なめらかな"品質保証"と、その敵 11 Demo
12. なめらかな"品質保証"と、その敵 12 Demoの内容 • 出⼒：以下のように出⼒（⼀部抜粋） “spec.md”の⼀部を抜粋
13. なめらかな"品質保証"と、その敵 13 Demoの内容 • 出⼒：以下のように出⼒（⼀部抜粋） “test-design.md”の⼀部を抜粋
14. なめらかな"品質保証"と、その敵 14 Demoの内容 • 出⼒：以下のように出⼒（⼀部抜粋） 「AIに丸投げしない」＝ 曖昧さを“管理”する
15. なめらかな"品質保証"と、その敵 15 なぜこれだけで、テスト観点が出るの？ ↓ 後半で、解説します！
16. なめらかな"品質保証"と、その敵 16 AI時代の開発スピードと「違和感」について
17. なめらかな"品質保証"と、その敵 17 AIの活⽤って、どれくらい普及してる？
18. なめらかな"品質保証"と、その敵 18 AI活⽤の実態（国内） • Gartnerジャパン 2025年調査によると、国内企業の3分の1~約半数（31.8 〜49.0%）が既にAIコーディングツールを導⼊ ◦ 対象：⽇本国内でソフトウェア開発に従事する企業内個⼈ 「400⼈」（n = 400） ◦ 「コード⽣成‧補完」では、49% ◦ 「コード‧レビュー」では、40% ◦ 「要件定義」では、39.8% etc… ◦ 前回 (2024年6⽉) の調査時：各⼯程12.8〜21.2% 「Gartner、国内のソフトウェア開発における AI活用の現状に関する最新の調査結果を発表」より抜粋
19. なめらかな"品質保証"と、その敵 19 AI活⽤の実態（国内） • 更に、「AIツール利⽤者の過半数が⽣産性の向上を実感」 ◦ 対象：ソフトウェア開発においてAIツール∕サービスを使⽤していると答えた回答者「363 ⼈」（n = 363） ◦ ⼀位：「開発効率‧⽣産性の向上」（57.9%） ◦ ⼆位：「コード品質の向上」(44.1%) ◦ 三位：「ドキュメント品質の向上」(30.6%) ◦ 「9割弱の開発者がAI活⽤をポジティブに捉えている」 「Gartner、国内のソフトウェア開発における AI活用の現状に関する最新の調査結果を発表」より抜粋
20. なめらかな"品質保証"と、その敵 20 AI活⽤の実態（国内） • 2025年度に⾏った、住友商事の「バイブコーディング体験研修」 ◦ 対象：プログラミング未経験者含む、住友商事に勤める社員の⽅々 ▪ 90分間で、様々な実⽤的なプロトタイプ作品を作成 ◦ 「研修後のアンケートでは90%以上が「何か⾃分でも作れそう」という変化を実感して頂き ました」とのこと。 ◦ 技術習得だけでなく、「業務や⽣活における課題解決⼿段としてデジタル技術を捉える視 点」の変化 ▪ 「イメージを共有しあうモックアップ作成に利⽤したい」 ▪ 「新規サービスやプロダクトを作る際に、簡易的な検証⽤に使いたい」 「総合商社の文系社員が AIプログラミングでアプリ開発。 90分で成果物実装まで行うバイブコーディング研修を住友商事にて実施。」より抜粋
21. なめらかな"品質保証"と、その敵 21 ほう。なら、海外は？
22. なめらかな"品質保証"と、その敵 22 AI活⽤の実態（海外） • Cognizant、AIリテラシー向上のため世界最⼤規模の「Vibe Coding Week」を開催 ◦ 対象：⼈事、営業、エンジニアリング、マーケティング部⾨など、25万⼈以上の従業員 ◦ 全社員25万⼈以上を対象に、AIエージェントを活⽤した開発イベントを実施 ◦ オンライン⽣成AIハッカソンの参加者数最多で、「ギネス世界記録™」のタイトル獲得を⽬指 しています。 「Cognizant Attempts World's Largest Vibe Coding Event to Accelerate AI Literacy Across Thousands of Employees」より抜粋
23. なめらかな"品質保証"と、その敵 23 結果：AI活⽤によってソフトウェア開発は、「爆速」になった。
24. なめらかな"品質保証"と、その敵 24 疑問：「テスト」と「品質保証」、置き去りになっていませんか？
25. なめらかな"品質保証"と、その敵 25 DORA (DevOps Research and Assessment) レポートを、⾒てみる
26. なめらかな"品質保証"と、その敵 26 "AI is an amplifier."（AIは増幅器である） 1. 「スループット」と「安定性」の不均衡（システム的な未成熟） a. 開発者はAIを使ってかつてない速度で変更を⽣成‧コミットできるけど、下流⼯程にある 「テストやデプロイ」のパイプラインがその量と速度に対応できていない。 2. 「信頼」は、そんなに⾼くない（と、感じる） a. ⽣成されたコードを「信頼している」と感じる回答者が70%いる⼀⽅で、残りの30%は、 「信頼がほとんどない」、もしくは「まったくない」と報告している。 3. 「検証の難化」と「認知摩擦」の移動 a. 「⼀⾒正しそうに⾒える」コード（⽣成AIが作ったコード）は、変更量の増加によって、検証 と調整のコストを増加させる可能性がある。 b. ⽣成されたコードを⼗分に理解‧検証せずに信頼してしまうと、微細なバグやシステムの不 整合が⾒過ごされる。 「Google Cloud DORA Report (2025): State of AI-assisted Software Development」より抜粋
27. なめらかな"品質保証"と、その敵 27 t-wadaさんは、なんて⾔ってる？（和⽥卓⼈さんの記事を⾒てみる）
28. なめらかな"品質保証"と、その敵 28 1. AIの登場は、問題の顕在化を圧倒的に早めた a. そもそも、「昔からあった問題」ですよね？ i. 技術的負債の⾼速な積み上げによる開発のスループット低下も、コードレビューがボト ルネックになることも。 2. 「ソフトウェアエンジニア以外の⼈々」に対する⾰命 a. これまで障壁となっていたコーディングという作業が、AIを⽤いることで簡単に突破できるよ うになり、ソフトウェア開発の裾野がどんどん世界中に広がっていった。 3. 「労⼒は外注できるが、能⼒は外注できない」 a. ⼈間の設計判断能⼒を上げていくために必要なフィードバックは、⾃らの⼿でコードを書く ことによって⼀番多く得られる。 b. ⼈間側の能⼒を上げていかないと、開発スピードや組織の能⼒は上がらない。 「t-wadaが説く、今あえて “自分の手”でコードを書く理由「バイブコーディングは、エンジニアのためのものではない」より抜粋
29. なめらかな"品質保証"と、その敵 29 AI時代の開発スピードと「違和感」のイメージ ↓ 「普通の乗⽤⾞に、F1のエンジンを搭載して動かす」ようなもの
30. なめらかな"品質保証"と、その敵 30 構造化能⼒がないままAIを使うと、「技術的負債が⾼速 / 爆速に」積み上がる
31. なめらかな"品質保証"と、その敵 31 設計などの基礎能⼒が不⾜していると、混乱を招く
32. なめらかな"品質保証"と、その敵 32 本当の（根本的、本質的な）「敵」は？ ここからは、高田の個人的な視点からみたものです。
33. なめらかな"品質保証"と、その敵 33 敵の本質：「◯◯◯◯」
34. なめらかな"品質保証"と、その敵 34 敵の本質：「バイアス」
35. なめらかな"品質保証"と、その敵 35 「バイアス：思い込み、勘違い」
36. なめらかな"品質保証"と、その敵 36 「バイアス：思い込み、勘違い」 ↓ ⼈間が潜在的に持っている、「不具合（バグ）」 ↓ 完全に失くすことは「不可能」だが、影響を最⼩限にすることは「可能」
37. なめらかな"品質保証"と、その敵 37 影響：「利⽤可能性ヒューリスティック」と「損失回避」による「偶像化」
38. なめらかな"品質保証"と、その敵 38 「利⽤可能性ヒューリスティック」 • 「頭に思い浮かびやすいもの」や「⽬⽴ちやすいもの」を選択してしまうこ と 「損失回避」 • 「今の損失」を過⼤評価し、「将来の損失」を過⼩評価すること 「偶像化」 • 「こうするしかない！」と決めつけて、進むこと 「利用可能性ヒューリスティック」「 損失回避」は、「ファスト＆スロー　上・下　 ―あなたの意思はどのように決まるか？ ―（ハヤカワ文庫 NF）」より抜粋 「偶像化」は、「戦略の要諦（日経 BP 日本経済新聞出版）」より抜粋
39. なめらかな"品質保証"と、その敵 39 影響：「利⽤可能性ヒューリスティック」と「損失回避」による「偶像化」 ↓ 「技術的負債が⾼速 / 爆速に」積み上がる、開発のスループットを低減させる
40. なめらかな"品質保証"と、その敵 40 「AIでのソフトウェア開発」は、どのように映る？
41. なめらかな"品質保証"と、その敵 41 System 1 (Fast：早い思考) vs System 2 (Slow：遅い思考) ↓ AIコーディング(System 1) vs Quality Assurance(System 2) 「ファスト＆スロー　上・下　 ―あなたの意思はどのように決まるか？ ―（ハヤカワ文庫 NF）」より抜粋
42. なめらかな"品質保証"と、その敵 42 System 1 (Fast：早い思考) • AIコーディング (System 1)： 早い思考で「作る」 ◦ 直感的に書けて、しかも⾼速 / 爆速で書ける。 ◦ かかる⼯数（コスト）や認知負荷を、省エネでき、「楽に」書ける ◦ 「動いたからヨシ！」と判断しやすい
43. なめらかな"品質保証"と、その敵 43 System 2 (Slow：遅い思考) • Quality Assurance(System 2)： 遅い思考で「検証する」 ◦ 体系的な⼿法や技法‧経験知を駆使して、ロジカルに考える ◦ テストドキュメントのフォーマットでアウトプット ◦ 「品質指標」を監視‧制御しながら、品質を判断 「品質指標」：定量的な「 Value（価値）を、ユーザーに届けられる状態にあるのか？」と、定性的な「 Value（価値）は、ユーザーにどれくらい届けられているのか？」を指す
44. なめらかな"品質保証"と、その敵 44 AIはコードを量産するが、テストコードや仕様書は後回し。 ↓ 「テスト設計に時間がかかる」「何を書けばいいかわからない」 ↓ 結果、「⾼速な技術的負債の積み上げ」につながりやすい
45. なめらかな"品質保証"と、その敵 45 「この機能のテスト書いて」と、AIエージェントに頼む ↓ AI「書きました（幻惑や情報過多）」→ ⼈間「ヨシ！（思考停⽌）」 ↓ 結果、形だけのテスト‧運⽤できないテストの⼭になり、AIへの丸投げに失敗
46. なめらかな"品質保証"と、その敵 46 敵の正体 ↓ バイアスの影響により、テスト⾃⾝を楽しようとする
47. なめらかな"品質保証"と、その敵 47 問い ↓ AI時代の「品質」と、どう正対すべきか（向き合うべきか）？
48. なめらかな"品質保証"と、その敵 48 品質保証においても、「テストの構造化能⼒」「テスト設計⼒」が必要
49. なめらかな"品質保証"と、その敵 49 AI任せにするのではなく、AIも理解できる「品質の構造」を⼈間が設計する能⼒ ↓ でも、どうやって？
50. なめらかな"品質保証"と、その敵 50 「品質保証の本質」を⾒てみる
51. AIも理解できる「品質の構造」 51
52. AIも理解できる「品質の構造」 52 Quality Assurance(System 2)： 遅い思考で「検証する」 ↓ QAエンジニアの頭の中って、どうなってる？
53. AIも理解できる「品質の構造」 53 Where? What? How?
54. AIも理解できる「品質の構造」 54 1. Where? (テスト対象): どこをテストするのか？ a. どの機能か？、どのAPIか？、どのメソッドか？ etc… b. CRUD（新規作成、読み込み、更新、削除）のどれ？ 2. What? (テスト観点): 何をテストするのか？ a. 正常系？、異常系？ b. 「どういう状態のときに、何の操作をした時」の何の検証？ 3. How? (テスト⽅法): どうやってテストするのか？ a. ⼿順など、具体的な操作⼿順は？ b. テストデータは？ c. テストパターンは、ある or ない？
55. AIも理解できる「品質の構造」 55 これらを、⾼⽥は「品質保証のゴールデントライアングル」と呼んでいます。
56. AIも理解できる「品質の構造」 56 同時に⾼⽥は、これらは「品質保証の本質」であると考えてます
57. AIも理解できる「品質の構造」 57 「テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02 p.20」より抜粋
58. AIも理解できる「品質の構造」 58 更に、QAエンジニアの「暗黙知」（AIエージェントが知らない）を⾒てみる
59. AIも理解できる「品質の構造」 59 Who? Why?
60. AIも理解できる「品質の構造」 60 Who?（ユーザーのペルソナ、権限、コンテキスト） ↓ AIには「誰にとっての正解か」が⾒えていない
61. AIも理解できる「品質の構造」 61 Why?（システムの因果関係、⽬的、不変条件） ↓ 「なぜその結果になるべきか」の意図が伝わっていない
62. AIも理解できる「品質の構造」 62 構造（Where/What/How）を整理する。 ⽂脈（Who/Why）を明⽰する。
63. AIも理解できる「品質の構造」 63 「What You See Is What It Does（WYSIWID）」
64. 「構造化」によるAIとの共創ワークフロー 64
65. 「構造化」によるAIとの共創ワークフロー 65 “What You See Is What It Does: A Structural Pattern for Legible Software” ↓ Daniel Jackson教授とEagon Meng教授（どちらも、MITの教授）が提唱した 「ソフトウェアの可読性を⾼めるための構造パターン（Concepts/Syncs）と、 AIエージェントにおける「認知（See）」と「⾏動（Do）」の⼀致を⽬指すため のモデル」 「What You See Is What It Does: A Structural Pattern for Legible Software」より抜粋
66. 「構造化」によるAIとの共創ワークフロー 66 “What You See Is What It Does: A Structural Pattern for Legible Software” ↓ 上記の論⽂をベースに、ソフトウェア（およびテスト）を3層で構造化する。 「What You See Is What It Does: A Structural Pattern for Legible Software」より抜粋
67. 「構造化」によるAIとの共創ワークフロー 67 構造（Where/What/How）を整理する。 1. Concepts (概念) a. 独⽴した状態とアクションを持つ機能単位。Page Object Modelにおけるページクラスのよ うな、他と依存しない「個」としての存在。 2. Syncs（Synchronizations：同期） a. Concepts同⼠の連携ルール。あるConceptの状態変化が、別のConceptにどう影響するか。 3. Actions (操作) a. Conceptsに対する具体的なメソッド実⾏。クリックや⼊⼒などの具体的な操作⼿順。 「What You See Is What It Does: A Structural Pattern for Legible Software」より抜粋
68. 「構造化」によるAIとの共創ワークフロー 68 構造（Where/What/How）を整理する。 1. Concepts (概念) ≒ Where? (テスト対象) a. どの機能か？、どのAPIか？、どのメソッドか？ etc… b. CRUD（新規作成、読み込み、更新、削除）のどれ？ 2. Syncs (同期) ≒ What? (テスト観点) a. 正常系？、異常系？ b. 「どういう状態のときに、何の操作をした時」の何の検証？ 3. Actions (操作) ≒ How? (テスト⽅法) a. ⼿順など、具体的な操作⼿順は？テストデータは？ b. テストパターンは、ある or ない？ 「What You See Is What It Does: A Structural Pattern for Legible Software」より抜粋
69. 「構造化」によるAIとの共創ワークフロー 69 ⽂脈（Why/Who）を明⽰する。 1. Observer(視点) ≒ Who? (ペルソナ) a. 「テストを誰の視点で評価するか」 i. 業務側ペルソナ ii. 開発側ステークホルダー 2. Purpose/Causality(⽬的/因果関係)≒ Why? (条件や性質) a. テストが判定（Oracle）できる形にした“チェック可能な不変条件‧性質” i. 「なぜその結果になるべきか」（因果関係） ii. 「なぜその順序で操作するのか」（時間的な順番） iii. 「どのルールがどれに優先するのか」（優先順位）
70. 「構造化」によるAIとの共創ワークフロー 70 手前味噌ですが、高田が書いた記事「進め！ “Vibe Testing”計画！ 〜AI開発推進部 QAの”初”挑戦〜」より抜粋
71. 「構造化」によるAIとの共創ワークフロー 71 技術スタック（再掲） • 「Cursor 」+ 「spec-kit」を使⽤ ◦ Claude codeや、Github Copilotなどに対応。 ◦ 対応の詳細は、 https://github.com/github/spec-kit?tab=readme-ov-file#-supported-ai-agentsを参照 願います。 ◦ spec-kit の“道具箱”（.specify/ 配下のファイル）を使⽤して、テスト設計をAIと共に作って いきます。
72. 「構造化」によるAIとの共創ワークフロー 72 spec-kit の“道具箱”（.specify/ 配下のファイル） • .specify/memory/ ◦ constitution.md: プロジェクトの憲法（品質‧テスト‧設計の“交渉不可ルール”を固定し、以降の 判断基準にする） • .specify/scripts/bash/ ◦ common.sh: 共通ライブラリ（repo root/feature dir の解決、spec.md/plan.md/tasks.md 等の パス計算） ◦ create-new-feature.sh: 新規featureの⼟台作成（NNN-... ブランチ/specs/NNN-.../spec.md をテ ンプレから⽣成） ◦ setup-plan.sh: plan.md の雛形作成（specs/<feature>/plan.md をテンプレから⽣成） ◦ check-prerequisites.sh: 前提チェック（feature dir と plan.md、必要なら tasks.md の存在確 認） ◦ update-agent-context.sh: エージェント設定同期（plan.md から技術情報を抽出し、CLAUDE.md や .cursor/rules/... 等を更新/⽣成）
73. 「構造化」によるAIとの共創ワークフロー 73 • .specify/templates/ ◦ spec-template.md: spec.md の型（Concepts/Syncs中⼼。Who/Whyを落とす） ◦ plan-template.md: plan.md の型（技術スタック‧構成を確定） ◦ tasks-template.md: tasks.md の型（タスク分解フォーマット） ◦ test-design-template.md: test-design.md の型（観点表/Viewpoint Matrix） ◦ test-implementation-template.md: test-implementation.md の型（テスト実装⽅針） ◦ test-execution-template.md: test-execution.md の型（実⾏記録） ◦ test-report-template.md: test-report.md の型（結果/学び/次アクション） ◦ checklist-template.md: チェックリストの型（漏れ/曖昧さ検出） ◦ agent-file-template.md: Agent⽤コンテキストの型（各種Agentファイルの元）
74. 「構造化」によるAIとの共創ワークフロー 74 .specify配下に、設定している内容 1. Plan & Spec (対話と構造化): a. ユーザーストーリーをConcepts（機能単位の対象） と Syncs（観点） に分解する。 b. ここで必ず Who（権限/⽴場） と Why（意図/不変条件） を問い直し、spec.md を作る。 2. Design (批判的思考で設計): a. spec.md を⼊⼒に、AIが Viewpoint Matrix（観点表） を出す。 b. ⼈間が Critical Thinking で⽳（例外‧競合‧前提崩れ）を指摘し、設計を完成させる。 3. Implement (コード⽣成): a. Designに基づき、Concepts（機能単位の対象） と Syncs（Test Scenario） を⽣成する。 b. Actions（操作） はAIが補完する（⼈間は“構造”に集中）。 4. Review (実⾏と修正): a. 実⾏して、壊れたら コードではなく構造（Spec/Design） をまず疑う。
75. なめらかな"品質保証"と、その敵 75 Demoの内容 • Promptの内容：以下の通り ◦ 固定（基本コピペ）：指⽰の概要（テスト設計書の作成）、やること、出⼒形式の指定、制 約（ガードレール）を記述 ◦ 変動（⼈間側が書くところ）：スコープ内‧スコープ外の記述、ユーザーストーリー、Why （構造的Why）とWho（ペルソナ）の記述
76. 「構造化」によるAIとの共創ワークフロー 76 Demoの内容：「固定」(テンプレ＋ガードレール)
77. 「構造化」によるAIとの共創ワークフロー 77 Demoの内容：「変動」（スコープ/ストーリー/Why/Who）
78. 「構造化」によるAIとの共創ワークフロー 78 ⼈間側のほうで考えること 1. Concepts（機能単位の対象）とSyncs（連携ルール）を定義すること 2. そして、「批判的思考（Critical Thinking）」で、その構造が正しいかを問 い続けること
79. 「構造化」によるAIとの共創ワークフロー 79 1. 単なる「ノリ（Vibe）」ではない。 2. 「なめらかな品質保証（Smooth QA）」を実現するアプローチ。 a. 「QAエンジニアの経験知（Golden Triangle）」を「構造（Structure）」に変換し、AIと共 に品質をエンジニアリングする⼿法。 3. 敵（バイアス）に対抗するために、「品質の構造（Structure）」をAIも理 解できる形にし、System 2の思考をAIと共に⾼速化（System 1化）する⼿ 法。
80. まとめ 80
81. まとめ 81 1. 「敵（バイアス）」を知る: ⾃分たちがSystem 1（直感）で楽をしようとし ていることを⾃覚する。 2. 「Easy」に逃げない: AIに丸投げせず、「Who/Why」を⾔語化し「品質の構 造」からテストを作る。 3. 能⼒を磨く: 「批判的思考（Critical Thinking）」で品質をデザインする。 a. JSTQB (Version 2023V4.0.J02) でも、テストに不可⽋なスキルとして「分析的思考、批判的 思考、創造性」が定義されている。 b. AIが出してきた答えを鵜呑みにせず（System 2）、構造の正しさを問う⼒が求められる。
82. 82 ⾼⽥が考えているQAエンジニア像は、「品質という”誰かにとっての価値”を語る ストーリーテラー」になること ↓ 「品質のモデラー」へと進化しなければならない
83. 83 「作業はシュリンクするが、品質をエンジニアリングすることは無くならない」
84. 84 Appendix
85. Appendix 85 • 「Gartner、国内のソフトウェア開発におけるAI活⽤の現状に関する最新の調査結果を 発表」 • 「総合商社の⽂系社員がAIプログラミングでアプリ開発。90分で成果物実装まで⾏う バイブコーディング研修を住友商事にて実施。」 • 「Cognizant Attempts World's Largest Vibe Coding Event to Accelerate AI Literacy Across Thousands of Employees」 • 「t-wadaが説く、今あえて“⾃分の⼿”でコードを書く理由「バイブコーディングは、 エンジニアのためのものではない」 • 「進め！“Vibe Testing”計画！ 〜AI開発推進部 QAの”初”挑戦〜」 • 「Google Cloud DORA Report (2025): State of AI-assisted Software Development」
86. Appendix 86 • 「ファスト＆スロー 上‧下 ―あなたの意思はどのように決まるか？―（ハヤカワ ⽂庫NF）」 • 「戦略の要諦（⽇経BP ⽇本経済新聞出版）」 • 「テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02 p.20」 • 「What You See Is What It Does: A Structural Pattern for Legible Software」 • 「spec-kit（コーディングエージェントを利⽤した仕様駆動開発（Spec-Driven Development）のためのツールキット）」 • 「批判的思考」（Wikipedia）
87. 87 ユニファ開発チーム、仲間を探しています お知らせ ユニファ株式会社 会社紹介資料（開発チーム版） / Unifa inc information for dev team - Speaker Deck
88. 88 ご清聴、ありがとうございました！