楽楽精算のQA改革 / RAKUSTechCon2024_Kaneko

◆イベント名
RAKUS Tech Conference 2024
https://techcon.rakus.co.jp/2024/

◆発表タイトル
楽楽精算のQA改革

◆登壇者
東京開発統括部 QA課　金子佳樹

Transcript

1. 楽楽精算のQA改革 楽楽精算でのQA専門組織の実践と成功事例 東京開発統括部　QA課　金子 佳樹
2. 登壇者紹介 東京開発統括部　QA課 金子 佳樹 SIerを経て、2023年に株式会社ラクスへ入社しました。 QAマネージャとして、楽楽精算や楽楽明細など、複数サービスの品質保証を担当 しており、テストを通じた開発品質の向上と、業務運用を通じた運用品質の実現 に取り組んでいます。 2

3. はじめに 楽楽精算でQA機能を専門組織化した成功事例をお伝えします • 楽楽精算のQA組織の特徴 • QA専門組織化の背景 • 運用からのフィードバックが重要だと感じた例 • フィードバックループを回すための取り組み 3

4. 楽楽精算のQA組織の特徴 楽楽精算のQA組織はテストをするだけではない 4
 開発と運用に携わり、サービス全体の品質を見ています 開発の品質（品質保証/品質管理) 運用の品質（サービスマネジメント） ・品質基準/品質目標の設定 ・テスト計画/実行管理 ・品質管理(品質分析、品質改善） ・リリース管理 ・障害管理 ・運用業務/管理 ・定型的な運用業務の自動化　 ・顧客問合せ対応（CSと連携）
5. 楽楽精算のQA組織の特徴 開発と運用に携わり、サービス全体の品質を見る QA≒テストという位置づけになることが多い中、楽楽精算のQAは結合テスト以降を担っています 5
 運用 開発 要求仕様 概要設計 UI設計 製造 単体テスト 結合テスト 事業部テスト リリーステスト リリース 運用 問合せ対応 ※CSと連携 障害 管理 主にQAが担当している業務 運用から得た知見を開発へフィードバック
6. QA専門組織化の背景 品質や顧客課題に向き合うため 元々は、開発エンジニアが開発と並行してテストも運用も行っていました 6
 要求分析 開発 テスト 運用 開発
7. QA専門組織化の背景 品質や顧客課題に向き合うため 元々は、開発エンジニアが開発と並行してテストも運用も行っていました 利用社数が増え、開発と並行してテスト/運用を行うことが難しくなってきました 7
 要求分析 開発 テスト 運用 開発 開発と並行してテストと運用を行う難しさ • 「開発」と「問合せ対応」の優先度付けが難しい • 問合せから顧客課題の深い理解が難しい • テスト/運用の改善が進まない
8. QA専門組織化の背景 品質や顧客課題に向き合うため 元々は、開発エンジニアが開発と並行してテストも運用も行っていました 利用社数が増え、開発と並行してテスト/運用を行うことが難しくなってきました テストと運用を専門的に担うQA専門組織を立ち上げました 8
 要求分析 開発 テスト 運用 開発 要求分析 テスト 運用 開発 開発 PdM QA
9. なぜ楽楽精算のQA組織は開発だけでなく運用も見るのか？ 運用フェーズでないと本当の品質問題は見つからない ”品質は誰かにとっての価値である。”※を考えると顧客利用を妨げる状況は品質が悪いといえます 9
 運用
 開発
 要求仕様 概要設計 UI設計 製造 単体テスト 結合テスト 事業部テスト リリーステスト
 リリース
 運用
 問合せ対応
 ※CSと連携
 障害 管理
 ※G.M.Weinberg「ワインバーグのシステム思考法」より 運用フェーズでないと 実際の顧客の声は拾うことができない
10. 運用からのフィードバックが重要だと感じた例 実運用されて初めてわかることがある 2023年10月に開始されたインボイス制度は、新しい制度で誰も正解が分かっていませんでした 仮説を持って開発をしたが、それでも実運用がされて初めて分かったこともあります 10
 例１ AI-OCRバージョンアップで識別できなくなった領収書 例２　国税庁のAPI仕様と実際の挙動の差異 例３　事業者登録番号の未入力
11. インボイス制度（おさらい） 消費税の適正な申告と納付を支援する新しい税制 2023年10月に開始された消費税インボイス制度により、売買の様々なところへ対応が必要となり ました 11
 売り手 (領収書・請求書の発行側） 買い手 (領収書・請求書の受領側） 税務署 適格事業者登録 領収書・請求書発行 （※事業者登録番号など 必要要素を含んだインボイス） 領収書・請求書受取 インボイス対応 経費精算 インボイス対応 会計処理 （消費税　仕入税額控除）
12. 運用からのフィードバックが重要だと感じた例① AI-OCRバージョンアップで識別できなくなった領収書 AI-OCRバージョンアップに伴って 全体精度は上がったが正しく読み取れなくなった領収書が発生しました 12
 特定の 領収書 楽楽精算 AI-OCR v1 特定の 領収書 楽楽精算 AI-OCR v2 正しく読取 誤って読取 AI-OCRバージョンアップ後 AI-OCRバージョンアップ前
13. 運用からのフィードバックが重要だと感じた例① AI-OCRバージョンアップで識別できなくなった領収書 AI-OCRバージョンアップに伴って 全体精度は上がったが正しく読み取れなくなった領収書が発生しました 13
 特定の 領収書
 楽楽精算
 AI-OCR v1
 特定の 領収書
 楽楽精算
 AI-OCR v2
 正しく識別
 誤って識別
 AI-OCRバージョンアップ後
 AI-OCRバージョンアップ前
 リリースにより新たな顧客課題が発生しているかもしれない リリース後に顧客の声を拾うことも重要
14. 運用からのフィードバックが重要だと感じた例② 国税庁のAPI仕様と実際の挙動の差異 国税庁のWebAPIで適格事業者（T番号）の情報取得をしていますが、 開発時の仕様書理解とは異なるレスポンスが返ってきていました 14
 Web-API仕様書 楽楽精算 国税庁 適格請求書発行事業者 公表システムWeb-API ？

15. 運用からのフィードバックが重要だと感じた例② 国税庁のAPI仕様と実際の挙動の差異 国税庁のWebAPIで適格事業者（T番号）の情報取得をしていますが、 開発時の仕様書理解とは異なるレスポンスが返ってきていました 15
 Web-API仕様書
 楽楽精算
 国税庁
 
 適格請求書発行事業者
 公表システムWeb-API
 ？
 新しい連携を追加した際には運用開始後の実際の動作を確認して 意図しない連携が起きていないか確認する
16. 運用からのフィードバックが重要だと感じた例③ 事業者登録番号の未入力 経費精算にあたり領収書・請求書の事業者登録番号は制度開始前は必要ありませんでしたが、 2023年10月以降は、仕入税額控除のために、事業者登録番号の入力が必要となりました 16
 楽楽精算 領収書/請求書 事業者登録番号 制度開始前は 未入力で問題なかった 楽楽精算 領収書/請求書 事業者登録番号 制度開始後は入力しないと税額控除されない が、未入力率が高い 制度開始以降(2023/10以降) 制度開始以前(2023/10以前)
17. 運用からのフィードバックが重要だと感じた例③ 事業者登録番号の未入力 経費精算にあたり領収書・請求書の事業者登録番号は制度開始前は必要ありませんでしたが、 2023年10月以降は、仕入税額控除のために、事業者登録番号の入力が必要となりました 17
 楽楽精算
 領収書/請求書 
 事業者登録番号 
 制度開始前は
 未入力で問題なかった
 楽楽精算
 領収書/請求書 
 事業者登録番号 
 制度開始後は入力しないと税額控除されない 
 が、未入力率が高い
 制度開始以降(2023/10以降)
 制度開始以前(2023/10以前)
 制度開始とともに機能活用できているか確認していくことで 顧客課題をいち早く気づくことができる
18. 運用からのフィードバックが重要というまとめ 実運用に入ってからわかることも多い 顧客利用を妨げない・利用影響を極小化するためには、 開発時点での考慮は勿論のこと、運用に入ってからの顧客の声を拾うことが重要です →　なので楽楽精算のQAは継続して、開発と運用に携わりサービス全体の品質を見ていきます 18
 開発 運用 開発と運用のフィードバックループの確立
19. フィードバックループを回すための取組み 開発→運用、運用→開発の展開を定常化する 19
 開発 運用 ②障害からの学び ＝品質リスクの蓄積 ③品質リスクに基づく テスト計画 ④品質リスクに基づく テストのシフトレフト ①増加する運用に対して改善 ※一部は今後取り組む構想
20. 取り組み①　増加する運用に対して改善 定型化・自動化を通した運用改善 20
 定型化 自動化 ガイドライン テンプレート 作業要領 CI/CD AI活用 自動テスト コマンド化 ChatBot →　20%の作業時間削減
21. 取り組み①　増加する運用に対して改善　例：問合せ対応 対話型生成AIを用いて対応速度Up 21
 利用者 CS QA 開発 エンジニア 仕様等の 問合せ 技術的な問合せ 実装等の調査 あらかじめAIに学習させて対応速度Up 　・調査の属人性を減らしQAの調査力Up 　・開発エンジニアへのエスカレ率Down 　・資料調査をAIにやってもらい速度Up ・再現確認 ・ログ調査 ・過去事例調査 ・仕様調査 など
22. 取り組み②　障害からの学び＝品質リスクの蓄積 ふりかえりを通して運用から学ぶ 22
 発生した 障害 不具合に対するふりかえり テスト観点 品質リスク 障害対応に対するふりかえり 障害対応フロー 解析手順・復旧手順 再発防止策
23. 取り組み③　品質リスクに基づくテスト計画 品質基準を阻害するリスクに基づいたテスト計画 23
 案件 品質リスク分析 楽楽精算品質基準（例） ・法制度の遵守 ・金額計算(税額等)の正確性 ・支払/会計データの正確性 計画策定 テスト計画書 過去障害から 蓄積した 品質リスク 案件の 品質リスク
24. 取り組み④　品質リスクに基づくテストのシフトレフト 案件の品質リスクを早期に解消 24
 案件の 品質リスク 開発 要求仕様 概要設計 UI設計 製造 単体テスト 結合テスト 事業部テスト 主にQAが担当している業務 上流からQAが入り 品質リスクの早期解消
25. 開発・運用と幅広くQAに取り組むための知識習得 ベストプラクティスに学ぶ 個々人の思いつきや発想のみに頼るのではなく、基本は世の中のベストプラクティスに学んでいます →　QA組織のメンバに専門性は異なっていても、、 ベストプラクティスをQA組織のベースとすることで組織としての共通理解を作っています 25
 品質 テスト サービスマネジメント 業務知識 JCSQE ソフトウェア品質技術 ISTQB/JSTQB ソフトウェアテスト技術 ITIL ITサービスマネジメントの 世界的な業界標準 簿記 会計知識 資格取得を積極的に推奨
26. まとめ 楽楽精算のQAはサービス全体の品質を見る • 楽楽精算のQA組織はテストをやるだけではありません ◦ 開発と運用に携わり、サービス全体の品質を見ています • 実運用になってからわかることもあります ◦ 開発→運用、運用→開発と顧客視点で顧客影響がないかをウォッチすることが重要です • 開発・運用のフィードバックループを回すための取り組みをしています 26

27. ご清聴ありがとうございました。 27