presentation in D3QA.

1. freee 株式会社
WFとAgileで変わったこと変わらないこと

2. 2
流れ
2
● おっさん誰？
● WFでやってたこと
● Agileでやってること
● 変わったこと変わらないこと

3. おっさん誰？
3

4. CoreEngine/申告freee/AI月次監査などのテストを担当
ソフトウエア品質屋 / テストマネージャー / 自動化エンジニア
元海上J官(面影ナシ..)→ブラック派遣企業(転職・転籍)
→富士ゼロックス子会社の契約社員(転職)→社員(転職)
→カスペルスキー(転職)→freee(転職)。
アジャイルチームに入ってのテストや品質戦略などなど、
「何もないところからいいカンジにテストする仕組みを作る」
ことを生業としている。
組み込み系システム（複合機、医療機器）からクラサバシステム、
B2Bセキュリティソリューションなどを経て
Web系クラウド会計のfreeeでアジャイルテストを実践。
日本科学技術連盟にてソフトウエアテスト資格試験公認トレーニングコース講
師、テスト自動化研究会やSeleniumConfTokyoなどの活動。
ASTER（ソフトウエアテスト技術振興協会）正会員。
犬好きのおっさんです。
Ryuji Koyama
@koyaman2
https://github.com/koyaman2
小山 竜治
QAアニキ：コヤマン
4

5. 色々なテストプロジェクト
をやってきた
何もないところに入って
テストのやり方を構築するマン

6. WFでやってたこと
6

7. 某X社
7
当時の状況。組み込み機器を組み合わせたもの。B2B。
ポイント 内容
立場 第三者検証（拠点内請負業者）
フェーズ 開発内統合テスト
テスト対象 組み込み機器、当時で500万行超えのアプリケーション
テストベース 仕様書類（重厚で手厚い）、品質点検表（会社標準）
テスト環境 試作機
基本的なテスト戦略 分析的、回帰的（スモークテスト）、標準準拠
基本的なテストタイプ 機能テスト、組み合わせテスト
期間 数か月
開始基準 機能導入率、スモークテスト通過率
終了基準 スモークテスト通過率、テストカバレッジ、機能カバレッジ他

8. 8
働き方
当時から割と越境気味な動きをしていた
「企画書を見れる範囲でよいのでください」が口癖。
第三者検証の立場だったので、印刷ブロックされた状態やマスクされた情報を元に
「テスト対象の存在意義」を確認していた。
仕様書レビューをしたり、仕様書の反映よりも前に仕様書書いている人に聞きに行っ
たり、開発者に聞きに行ったり、開発者が見る仕様書が置いてあるサーバーを覗いて
情報収集したり。
情報を集めてまとめてテストケースを作っていた。
プロセスや与えられた役割の中でベストを尽くす感じ。

9. 9
よろこばれたポイント
❏ 開発チームが仕様を考えているときに、使う視点や少し広い視点で考えてフィード
バックするところ
❏ 単体テストなどでは実施しきれないパラメータ網羅や、パラメータを組み合わせた
状態の動作確認をするところ
❏ 会社のルールに則ったドキュメンテーションをするところ
❏ 不具合分析など、品質情報のフィードバックをするところ
❏ 過去のプロジェクトの情報を活用して過去との差分を確認するところ

10. Agileでやった/やってること
10

11. 某X社
11
当時の状況。webシステムを組み合わせたシステムofシステムズ。B2B。
ポイント 内容
立場 第三者検証（子会社）
フェーズ 開発内統合テスト
テスト対象 Webシステム（オンプレクラサバシステム）1000万行超え
テストベース 仕様書類(あるが更新遅い)、チケット(TFS)、品質点検表(会社標準)
テスト環境 LAN内に複数オンプレで構築
基本的なテスト戦略 分析的、回帰的（スモークテスト）、標準準拠
基本的なテストタイプ 機能テスト、非機能テスト、組み合わせテスト
期間 数か月
開始基準 機能導入率、スモークテスト通過率
終了基準 スモークテスト通過率、テストカバレッジ、機能カバレッジ他

12. 12
働き方
越境的というか、意志決定会議に参加していた。
開発のフォローや要望を直接予算を握るメンバーに直接交渉したりスケジュール調整
したり。
100人規模の開発チームに対してテスト担当チームはオフショア含めて30名ほど、交
渉窓口はコヤマン1名だったので、8スクラムのmtgにちょくちょく顔を出していた。
アジャイルというテイだったと言わざるを得ない。
オンプレなのでそもそもビルドが必要であり、dailyどころかweeklyでもビルドされてい
なかった。
スクラムmtgに参加する主な理由は情報収集と仕様策定支援。
会社のルールに従いながら、できることをする感じ。

13. 13
よろこばれたポイント
❏ 開発チームが仕様を考えているときに、使う視点や少し広い視点で考えてフィード
バックするところ
❏ 単体テストなどでは実施しきれないパラメータ網羅や、パラメータを組み合わせた
状態の動作確認をするところ
❏ システムとの組み合わせなど
❏ 会社のルールに則ったドキュメンテーションをするところ
❏ 不具合分析など、品質情報のフィードバックをするところ
❏ 過去のプロジェクトの情報を活用して過去との差分を確認するところ
❏ 度重なるスケジュール変化に対していい感じに協調するところ

14. 某f社
14
今の状況。Webサービス(SaaS)。B2B。
ポイント 内容
立場 サービスのQA担当
フェーズ 開発内統合テストだったりシステムテストだったり
テスト対象 SaaSアプリやMicroServiceなど、規模はときどきで変わる。
テストベース 仕様書類(あったりなかったり)、チケット(JIRA)、会話
テスト環境 テスト用環境（ステージング）
基本的なテスト戦略 分析的、回帰的（E2E）、探索的
基本的なテストタイプ 機能テスト、非機能テスト、探索的テスト、シナリオテスト
期間 数日～1ヶ月がメインで時々数か月がある。モノによる。
開始基準 開始できると判断できるとき
終了基準 リリースできると判断できるとき

15. 15
働き方
基本的にはリスクベースのアプローチをとっていて、リスクを洗い出してからテストの
やりかた等を考える。
ドキュメントがあれば見る、無ければ聞く。
期待値が事前に明確であれば期待値を書く、なければ探索的テストする。
回帰テストは自動テストを書く。
しかしクリティカルなデータが多いので品質は重視。
速度を阻害しないように品質を上げるためにやるべきことをやるだけ。
手段は適宜考えて柔軟に対応する感じ。

16. 16
よろこばれたポイント
❏ 開発チームが仕様を考えているときに、使う視点や少し広い視点で考えてフィード
バックするところ
❏ ユニットテストなどでは実施しきれないパラメータ網羅や、パラメータを組み合わせ
た状態の動作確認をするところ
❏ システムとの組み合わせなど
❏ 度重なるスケジュール変化に対していい感じに協調するところ
❏ リスク高い問題を中心に検出するところ
❏ 開発チームだけではない解決策をサジェストするところ

17. 変わったこと/変わらないこと
17

18. 変わったこと(WF→Agile)
18
❖ プロセスと役割
➢ WF：会社標準のプロセスと会社に決められた役割
■ 計画重視
➢ Agile：できること全部
■ 価値重視。スピード感も価値に入る。
❖ 周囲の人の意識
➢ 計画の遵守→ユーザーの価値
❖ 重視するポイント
➢ 計画→リスク
❖ 時間の使い方
➢ 調査→議論・会話・探索

19. 変わらないこと
19
❖ テストをするということ
➢ 「知りたいからやる」ということは変わらない。
➢ 基本的なテスト活動も変わらない（計画→分析→設計→実行→報告）
➢ 基本的なテストの目的も変わらない
■ 欠陥の摘出、品質が十分か確認する、情報を示す、未然防止する
❖ 製品の目的・存在意義が大事であること
➢ 何のためにテストするのか？が大事
❖ 「開発チームの認識の外側をフォローする」こと
➢ WF：仕様書に書いていない部分や意識が向いている外側をフォロー
➢ Agile：チケットに書いていない部分や意識が向いている外側をフォロー
❖ テストは状況次第ってこと
➢ 「モノによって細かいやり方が変わる」ということは変わらない。
➢ アジャイルってテイではアジャイルじゃなかったス。

20. スモールビジネスを、
世界の主役に。