Kyash x Postman: Powering a Culture of Quality

by Bando Masaya

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

©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.

Slide 5

Slide 5 text

Slide 6

Slide 6 text

©2025 Kyash Inc. 6 Kyash x Postman: Powering a Culture of Quality クレジット事業部は、スポットマネーの機能開発を担っています。スポットマネーはKyashが提供する与信プロダクトで、GeNiE様と共創プロジェクトです。事業部の詳細は @daiki.ueda にお任せします。私達は、スポットマネーで実現したい世界観や信条を体現するために、ソフトウェア開発に日々勤しんでいます。 #ff6a 56

Slide 7

Slide 7 text

©2025 Kyash Inc. 7 Kyash x Postman: Powering a Culture of Quality スポットマネーは、Kyashだけでは実現できない機能です。共創モデルのプロダクトとして発足し、GeNiE様のシステムとAPI連携しながら与信プロダクトを構築しています。そのため、海外で開発している社外の開発メンバーと機能や仕様を共有しながら共同開発を進めています。仕様理解やInterface Test b (ITb)やUser Acceptance Test (UAT)を密に進めなければならず、また、与信プロダクトという特性上、不具合はできる最小限に抑えたいため、ソフトウェア品質にこだわっています。 X

Slide 8

Slide 8 text

©2025 Kyash Inc. “ ” 8 スポットマネーに関わる改修については「QAを挟まずにリリースしない」ぐらい重いものとチーム全体で考えたいです。「該当部分の変更に伴うQAをしていない」という部分が共通するかなと思っており、同様の事象はもう起こしたくないなと。「決済障害は起こしたらヤバい」みたいな意識はなんとなく全社であると思いますが、同じ意識をスポットマネーでも持てる状態にしたいです。（共にライセンスの影響があるかつパートナー企業に迷惑をかける）ご迷惑をおかけしました・・・

Slide 9

Slide 9 text

Slide 10

Slide 10 text

©2025 Kyash Inc. 10 Kyash x Postman: Powering a Culture of Quality ● すでに社内で使っているユーザーが多数いたので、Postmanの便利さや詳細の説明が不要 ● APIクライアントとして開発中に使ってもらい、自然な流れでUnit Testを書くプロセスを開発フローに組み込みたい ● トップダウン的にツールを指定するのではなく、開発者自身が自発的に使いたいと思えるものでないと普及しない（品質は向上しない） ● mock serverでモックを作り、コードを書く前にドキュメント、テストを作成したい ● コードを書き始める前に設計（仕様）を洗練化し、高品質な成果物をリリースしたい Unit Test Postman mock server

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

©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スクリプト

Slide 15

Slide 15 text

Slide 16

Slide 16 text

©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）テストは単なる検証手段ではなく、設計の一部であり、コード品質と保守性を高める重要な手段です

Slide 17

Slide 17 text

Slide 18

Slide 18 text

©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

Slide 19

Slide 19 text

©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の負荷が増大するにも関わらず、プロダクションコードを経由しないため、精度の高いテストができない点にあります。

Slide 20

Slide 20 text

©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

Slide 21

Slide 21 text

©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の作り方

Slide 22

Slide 22 text

©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も使いたい放題です。

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

©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! 急がば回れ！