本当に必要なのは「QAという技術」だった!試行錯誤から生まれた、品質とデリバリーの両取りアプローチ / Turns Out, "QA as a Discipline" Was the Key!
by
ar_tama
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
© LayerX Inc. 本当に必要なのは「QAという技術」だった! 試⾏錯誤から⽣まれた、品質とデリバリーの両取りアプローチ あらたま @ Scrum Fest Niigata 2025
Slide 2
Slide 2 text
2 © LayerX Inc. 新多真琴(あらたま) @ar_tama 株式会社LayerX バクラク事業部 EM(エンジニアリングマネージャー) 📝 数社でソフトウェアエンジニア→CTO→ ソフトウェアエンジニア↔EM 🤝 EMゆるミートアップ 🎊 EMConf JP 2025&2026 ⚡ Startup in Agile 👉 2025/05/20@東京 ⾃⼰紹介
Slide 3
Slide 3 text
3 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに、AI SaaSとAI DXの事業を展開 事業紹介 バクラク事業 企業活動のインフラとなる業務を 効率化するクラウドサービス Fintech事業 ソフトウェアを駆使したアセットマネジ メント‧証券事業を合弁会社にて展開 AI‧LLM事業 社内のナレッジやノウハウをデータ ベース化するAIプラットフォーム AI SaaSドメイン AI DXドメイン
Slide 4
Slide 4 text
© LayerX Inc. 4 「バクラク」シリーズラインナップ ‧AIが請求書を5秒でデータ化 ‧仕訳 / 振込データを⾃動作成 ‧電帳法‧インボイス制度にも対応 仕訳‧⽀払処理効率化 ‧年会費無料で何枚でも発⾏可 ‧カード利⽤制限で統制を実現 ‧すべての決済で1%以上の還元 法⼈カードの発⾏‧管理 ‧帳票の⼀括作成も個別作成も⾃由⾃在 ‧帳票の作成‧稟議‧送付‧保存を⼀本化 ‧レイアウトや項⽬のカスタマイズも可能 請求書発⾏ ‧スキャナ保存データも直接取込 ‧AI-OCRが⾃動読取&データ化 ‧[取引先][取引⽇][取引⾦額]での検索 帳票保存‧ストレージ ‧AIが⾒積書‧請求書を5秒でデータ ‧スマホからも申請‧承認OK ‧柔軟な通知設定‧承認の催促機能 稟議‧⽀払申請 ‧直感的UIで従業員の負担を軽減 ‧Slack連携で打刻や⾃動リマインド可能 ‧わかりやすい残業 / 休暇管理レポート 勤怠管理 ‧AIが領収書を5秒でデータ化 ‧スマホアプリとSlack連携あり ‧領収書の重複申請などミス防⽌機能 経費精算
Slide 5
Slide 5 text
© 2024 LayerX Inc. スタートアップ企業が実践する 「⾝の丈スクラム」の現在地 あらたま @ Scrum Fest Osaka 2024
Slide 6
Slide 6 text
6 © LayerX Inc. プロダクトも機能も順調に成⻑! イントロダクション
Slide 7
Slide 7 text
7 © LayerX Inc. そのころ開発現場は…… 複雑なフォーム=複雑な状態管理とUIとが密結合に 個々の機能が複雑に絡み合い、1箇所の変更で複数箇所が影響を受ける イントロダクション
Slide 8
Slide 8 text
8 © LayerX Inc. そのころ開発現場は…… 複雑なフォーム=複雑な状態管理とUIとが密結合に 個々の機能が複雑に絡み合い、1箇所の変更で複数箇所が影響を受ける イントロダクション
Slide 9
Slide 9 text
9 © LayerX Inc. そのころ開発チームは…… - チームの7割、エンジニアの多くが異動&⼊社したて🐣 - 他プロダクトとの連携機能も随⼀の多さ - 他チームからのコントリビューションも多い - レビューをすり抜け「知っていれば防げたが…」な罠をことごとく踏み抜く イントロダクション
Slide 10
Slide 10 text
10 © LayerX Inc. リリース前の検証プロセスで⼿戻りが多発 次のリリースサイクルに向けた開発着⼿が遅れ、慢性的な息切れ状態に イントロダクション
Slide 11
Slide 11 text
⼿戻りを減らすことにフォーカスする
Slide 12
Slide 12 text
12 © LayerX Inc.
Slide 13
Slide 13 text
13 © LayerX Inc. 「開発がうまい⼈は、⼿戻りが少ない」 - ⾼速でフィードバックを得る - 作り始める前に影響範囲を把握する 「QAという技術」が必要
Slide 14
Slide 14 text
14 © LayerX Inc. ⾼速でフィードバックを得る - ⼿数を増やす(Cline/Roo, Devin, etc..) - プロトタイピング(Figma, V0, etc..) - デイリースタンドアップでデモをする 「開発がうまい⼈は、⼿戻りが少ない」
Slide 15
Slide 15 text
15 © LayerX Inc. 作り始める前に影響範囲を把握する - 「虎の巻」と「タスクテンプレート」の整備 - QA観点Sync、ET会 - セルフ検証、開発者相互検証 「開発がうまい⼈は、⼿戻りが少ない」
Slide 16
Slide 16 text
16 © LayerX Inc. 虎の巻 チーム内外に向けて、開発の⼿引となるドキュメントを整備 作り始める前に影響範囲を把握する
Slide 17
Slide 17 text
17 © LayerX Inc. タスクテンプレート 概要 - [Why] この機能で解決したいユーザーの課題、提供したい価値 - [What] Whyを満たすために何を変更するのか 検証観点 - Whatが満たされていることをどのように確認するか - 何を確認したら「他の箇所には影響ない」と⾔えるか - 関連するが変更が起き得ないはずの箇所はどこか - 何を確認したらサイド‧エフェクトがないと⾔えるか 作り始める前に影響範囲を把握する
Slide 18
Slide 18 text
18 © LayerX Inc. 「Whyはむずかしい」 作り始める前に影響範囲を把握する
Slide 19
Slide 19 text
19 © LayerX Inc. なかなかうまくいかない…… - そこで「QAの技術」の出番! - チームで以下を推し進めることで、QAの⽬線や技術をインストール - 概要‧検証観点を開発者が記⼊し、チームでレビューし合う - ET(探索的テスト)会で「仮説を持って検証すること」に慣れる - セルフ検証、開発者相互検証項⽬のQAによるレビュー‧追試 「QAという技術」が必要
Slide 20
Slide 20 text
20 © LayerX Inc. チーム全員でSECIモデルを回す🌀 「QAという技術」が必要
Slide 21
Slide 21 text
21 © LayerX Inc. 失敗談:開発者相互検証 「QAという技術」が必要 - コードフリーズ前に開発者同⼠で互いの開発物を検証し、FBし合う - ⼀定の効果はあったものの、運⽤が回りきらなかったため断念 - 🙆 ⾃分以外の開発物への解像度が上がり、ドメイン知識の補完にも - 🙅 息切れ問題解消のために始めたはずが、ただでさえ短い開発期間が更 に削られることに… - いま、改めてコードフリーズ後に復活させているところ🔥
Slide 22
Slide 22 text
22 © LayerX Inc. 私たちの現在地 「QAという技術」が必要 - デリバリースピードを落とさずに、品質も安定してきた👏 - 障害件数、コードフリーズ後の修正件数ともにおおよそ半減 - 並⾏してドメイン知識のキャッチアップが叶ったことも理由のひとつ - 新たな仲間も増え、更に取り組みを推し進められそう🏎 - 最も複雑な箇所のリアーキテクティングに取り組んでいるところ - 詳細はTSKaigi 2025 Day2で!
Slide 23
Slide 23 text
23 © LayerX Inc. 技術のインストールは⼀朝⼀⼣には進まない - 施策の全てにもちろんトレードオフがある - ときにはQAという⼈(役割)に頼って、背中を預ける選択肢も⼤事 - 理想と現実のギャップを把握して、⼀歩ずつ距離を詰める - 挑戦と失敗を繰り返して、チームに経験値を貯めていく - ふりかえりとナレッジの発信で定着させる おわりに
Slide 24
Slide 24 text
24 © LayerX Inc. 最後に宣伝!5/20(⽕)にイベントやります!@東京 Startup in Agile #4 みんなの「アウトカムの射程」を語ろう! おわりに