Kyash x Postman: Powering a Culture of Quality

https://kyash.connpass.com/event/366479/

Transcript

1. ©2025 Kyash Inc. ©2025 Kyash Inc. 2025.9 Update Kyash TechTalk #8 - スポットマネー開発の裏側 Kyash x Postman: Powering a Culture of Quality @unionsep - masaya.bando (Software Engineer in Test) postmanを使ったテスト実装
2. ©2025 Kyash Inc. 2 1. About the Speaker 2. Credit Division 3. Why Postman ? 4. Use Case 5. Our Takeaways Kyash x Postman: Powering a Culture of Quality Postmanを使ったテスト実装
3. ©2025 Kyash Inc. ©2025 Kyash Inc. About Me 3 3
4. ©2025 Kyash Inc. 4 Kyash x Postman: Powering a Culture of Quality About Me KyashでSoftware Engineer in Test (QA) とし て開発業務も担当しています。Backend (SWE)を行 いながら、組織に品質文化を浸透させる役割も担ってい ます。 好きなGo Package はreflectです Go Gopher by Renée French is licensed under CC BY 3.0.
5. ©2025 Kyash Inc. ©2025 Kyash Inc. Credit Division 5 5
6. ©2025 Kyash Inc. 6 Kyash x Postman: Powering a Culture of Quality クレジット事業部は、スポットマネーの機能開発を担っ ています。スポットマネーはKyashが提供する与信プ ロダクトで、GeNiE様と共創プロジェクトです。 事業部の詳細は @daiki.ueda にお任せします。私 達は、スポットマネーで実現したい世界観や信条を体 現するために、ソフトウェア開発に日々勤しんでいま す。 #ff6a 56
7. ©2025 Kyash Inc. 7 Kyash x Postman: Powering a Culture of Quality スポットマネーは、Kyashだけでは実現できない機能です。共創モデルのプロダクトとして発足 し、GeNiE様のシステムとAPI連携しながら与信プロダクトを構築しています。そのため、海外で 開発している社外の開発メンバーと機能や仕様を共有しながら共同開発を進めています。 仕様理解やInterface Test b (ITb)やUser Acceptance Test (UAT)を密に進めなけれ ばならず、また、与信プロダクトという特性上、不具合はできる最小限に抑えたいため、ソフトウェ ア品質にこだわっています。 X
8. ©2025 Kyash Inc. “ ” 8 スポットマネーに関わる改修については「QAを挟まずにリリースしない」ぐらい重いものとチーム全体で考えたいです。 「該当部分の変更に伴うQAをしていない」という部分が共通するかなと思っており、同様の事象はもう起こしたくないなと。 「決済障害は起こしたらヤバい」みたいな意識はなんとなく全社であると思いますが、同じ意識をスポットマネーでも持てる状態にしたいです。 （共にライセンスの影響があるかつパートナー企業に迷惑をかける） ご迷惑をおかけしました・・・
9. ©2025 Kyash Inc. ©2025 Kyash Inc. Why Postman? 9 9
10. ©2025 Kyash Inc. 10 Kyash x Postman: Powering a Culture of Quality • すでに社内で使っているユーザーが多数いたので、Postmanの便利さや 詳細の説明が不要 • APIクライアントとして開発中に使ってもらい、自然な流れでUnit Testを 書くプロセスを開発フローに組み込みたい • トップダウン的にツールを指定するのではなく、開発者自身が自発的に使い たいと思えるものでないと普及しない（品質は向上しない） • mock serverでモックを作り、コードを書く前にドキュメント、テストを作成 したい • コードを書き始める前に設計（仕様）を洗練化し、高品質な成果物をリリース したい Unit Test Postman mock server
11. ©2025 Kyash Inc. ©2025 Kyash Inc. Use Case 11 11
12. ©2025 Kyash Inc. ©2025 Kyash Inc. Unit Test 12
13. ©2025 Kyash Inc. 13 Kyash x Postman: Powering a Culture of Quality ① ② ③ 1. OpenAPI YAMLに定義したAPI仕様をコ レクションにインポート 2. 400 Bad Requestをサンプルに追加 3. 追加したサンプルからコレクションを作成 し、Post-responseスクリプトを実装 専用環境
14. ©2025 Kyash Inc. 14 Kyash x Postman: Powering a Culture of Quality チームで合意を取ったOpenAPI仕様を元に、テストコードを実装し ます。テストコード実装直後は、テストを実行してもFailとなります。 実装者はテストRunnerがSuccessとなるように実装していきま す。 このテストスクリプトは、テストに通過したら良いという検証手段で はなく、API仕様をコードに落とし込めているか？という観点が重 要です。 今はまだ初期導入段階なので、200 OKと400 Bad Requestの ２パターンを準備。チームにTDDが浸透してきたら、テストコードは QAチームも実装したいと考えています。ゆくゆはPostbot(AI)で 自動的に・・・ Post-responseスクリプト
15. ©2025 Kyash Inc. 15 Kyash x Postman: Powering a Culture of Quality 書いたテストコードを実行するGithub Actions用の CI/CDをGenerateする。 Configure commandを押してyamlをコピペして Pull Requestに組み込むだけでテストが実行される。 至れり尽くせり。
16. ©2025 Kyash Inc. Kyash x Postman: Powering a Culture of Quality チームでPostmanのテストスクリプトを導入しようと提案した思いは、「自信を持ってコードを書く」ことに尽きます。毎 週、GeNiE様と定例を開いてもらっていますが、それでも認識の乖離や齟齬が生まれてしまいます。結果的に、少しのズレ が手戻りの原因となり、最悪の場合、不具合が表出してしまいます。 Code with Confidence 16 “I don’t write code without tests.” — Kent Beck Tests are not merely tools for verification; they are an essential part of design, guiding development while ensuring the code’s quality and maintainability. ※ 出典: Test Driven Development: By Example(https://www.amazon.co.jp/dp/B0CW1JBTHM） テストは単なる検証手段ではなく、設計の一部であり、コード品質と保守性を高める重要な手段です
17. ©2025 Kyash Inc. ©2025 Kyash Inc. Postman mock server 17
18. ©2025 Kyash Inc. 18 Kyash x Postman: Powering a Culture of Quality https://unionsep.hatenablog.com/entry/2024/12/16/120000 スポットマネーの開発関係者は大まかに右の図のような構成になっています。私は Kyash APIの開発を担当しています。 API API mobile team backend team genie team backend teamはGeNiE様のAPIチームと社内のmobile teamに挟まれている形になります。 この編成の課題は、GeNiE APIがある程度完成しないとKyash APIはテストできないし、mobile teamはKyash APIが完成し ないとテストできないことです。 QA視点では、すべてのチームの開発がある程度完了しないとテ スト実行することも動作確認することもできません。 The Start Point
19. ©2025 Kyash Inc. 19 Kyash x Postman: Powering a Culture of Quality 環境変数によってinterfaceの実装を切り替える テストしやすい環境にするため、backend teamが一肌脱いでStub を構築しました。mobile teamはテストしやすくなったものの、Stub はプロダクションコードの実装を経由しないため、backend teamは 保守するコードが2倍になり、負荷が増大しました。 API Stub API 完成していなくても Mobileに影響しない！ mobile team backend team genie team Stub Stubの課題は、backend teamの負荷が増大する にも関わらず、プロダクションコードを経由しないた め、精度の高いテストができない点にあります。
20. ©2025 Kyash Inc. 20 Kyash x Postman: Powering a Culture of Quality Postman mock serverを利用して、プロダクションコードを経由してリクエストする Mock APIにリクエストするエンドポイントのみを環境変数から切り替 え、プロダクションコードを経由してGeNiEシステムやKyash APIを 模したmockにリクエストします。そのため、プロダクションコードは増 えません。 プロダクションコードが完成していなくても、レスポンスを返すことがで きるため、各チームの開発完成をまたずに自チームの開発やテストを進 めることができます。 特別なデータやタイミングを必要とするリクエストもmock serverで 再現できるので、プロダクションコードのテストが強化されます。 API Mock API API 完成していなくても Mobileに影響しない！ mobile team backend team genie team Mock API エッジケースや5xxを 再現！ mock server プロダクションコードが増加しないにも関わらず、精度の高い テストを実行することができます。 Stub
21. ©2025 Kyash Inc. Kyash x Postman: Powering a Culture of Quality mobileとbackendが連携するAPIは、teamで仕様を決めてOpenAPIにしていましたが、GeNiE APIと連携するAPI仕様はExcelファイルで提供されています。最終的にPostman Collectionに落 とし込みたいため、AIを利用してExcel (PDF)からOpenAPIのyamlファイルに変換し、Postmanに 読み込ませてCollectionを自動で作成し、mock serverを作りました。 21 ※ とはいえ、そんなにうまいことできていないので、もっと簡単にしたい（Gemini CLIで自動化したい） mock serverの作り方
22. ©2025 Kyash Inc. Kyash x Postman: Powering a Culture of Quality Excelからyamlを作成する作業はかなり骨が折れる作業でした。mock serverを作るために、どうに かこうにかしてGeNiE様からいただいた仕様書からPostman Collectionを生成できないかと思案 し、生成AIを利用することにしました。 22 AI しかし、結果的に、AIの利用はチームに良い効果を与えました。 mock serverは実装に深く関わるため、AIが出力したyamlのファクトチェックが自然と行われ、その過 程で仕様書を人間がよく読むようになりました。今まで仕様書を読んでいなかったわけではないのです が、「Geminiがこんなこと言ってるけど仕様書に書かれてる？」「ほんまや・・・」のような会話が生まれ、 既存実装の改善ポイントが発覚しました。 あとから思うとGeminiではなく、Notebook LMのほうが良かったのかもしれません。Kyashでは GeminiもNotebook LMも使いたい放題です。
23. ©2025 Kyash Inc. mock server demo 23 時間があったらデモみせます
24. ©2025 Kyash Inc. ©2025 Kyash Inc. Our Takeaways 24 24
25. ©2025 Kyash Inc. 25 Kyash x Postman: Powering a Culture of Quality わたしたちの学び Our me 開発フローが自社内で完結する業務においては、関係者とのコミュニケーションで動かせる変数が多いですが、共創モデルとして誕生し た私達のプロダクトは動かせる変数に限りがあります。そのような中で、私達はtest-driven development(TDD)やspec-driven development(SDD)の思想を取りれようとしています。コードを書く時間よりも設計を洗練し、インシデントや不整合がある製品をお 客様に提供しないことを第一義としているためです。それを叶えるためにPostmanはとても優秀なツールでした。 QAである私の個人的な思いとして、TDDやSDDを開発者に勧めるのは困難な業務と捉えていました。開発者である私自身、ソフトウェ アテストや品質保証についての解釈が浅かった頃は、1つ1つのテスト内容の意義が理解できず、テスト範囲や深度に疑問を持った時期 があったからです。なので、開発者が自発的に使いたいと思ってもらえるツールやプロセスを意識し、決してトップダウン的なアプローチ にならないような普及活動に努めました。最終的に、「やっぱテスト書いたほうがいいっすね」や「Postman好きだから使い続けたい」と いうポジティブな発言をしてくれて嬉しかったです。その言葉が聞けただけで、私のQAとしての仕事の8割は成功したなと救われた思 いでいます。 Thank you! 急がば回れ！
26. ©2025 Kyash Inc. ©2025 Kyash Inc. Thank you 2025.9.30 @unionsep - masaya.bando (Software Engineer in Test) 26