Upgrade to Pro — share decks privately, control downloads, hide ads and more …

顧客価値を安定的に届けるために―Rettyにおけるアジャイル開発とQA改善の取り組み / Deliver customer value regularly at Retty

顧客価値を安定的に届けるために―Rettyにおけるアジャイル開発とQA改善の取り組み / Deliver customer value regularly at Retty

Yuichi Tsunematsu

November 15, 2019
Tweet

More Decks by Yuichi Tsunematsu

Other Decks in Programming

Transcript

  1. 顧客価値を安定的に届けるために

    Retty株式会社

    常松祐一

    Rettyにおけるアジャイル開発とQA改善の取り組み

    2019/11/15

    confidential

    View Slide

  2. 自己紹介

    ● 常松祐一 (つねまつ ゆういち) 

    ○ Engineering Manager 

    ○ Software Engineer

    ○ Agile Development

    ● SNSアカウント

    ○ tunepolo : 

    ○ tune : 


    ● 顧客にとって価値のあるプロダクトを、チーム一丸
    となって協力し、短期間にリリースする開発体制の
    あり方を模索しています。 

    confidential

    View Slide

  3. Confidential Copyright © 2018 Retty, Inc. All Rights Reserved.
    3
    confidential

    View Slide

  4. Confidential Copyright © 2018 Retty, Inc. All Rights Reserved.
    4
    confidential

    View Slide

  5. Confidential Copyright © 2018 Retty, Inc. All Rights Reserved.
    5
    confidential

    View Slide

  6. グルメサービスRettyを支えるシステム
 confidential
    Photo by Jay Wennington on Unsplash
    to C向け
    Web & App
    to B(レストラン)向け
    Web

    View Slide

  7. 今回のテーマ
 confidential
    Agile Testの今
    Photo by David Travis on Unsplash

    View Slide

  8. あらかじめ申し上げておくと・・・
 confidential
    ● RettyはQAの分野で進んだ取り組みができている会社ではありません。

    ● RettyはQAを専門とする組織・チーム・社員がおりません。


    ● それでもRettyはアジャイルな開発に真摯に取り組んでいる会
    社だと確信しており、今日の話がアジャイルなQAを探求する皆
    様の参考になることを願っております。


    View Slide

  9. アジャイルってなんでしたっけ?
 confidential
    ● 状況変化に機敏に対応していけるという「状態」。

    ● 「アジャイル開発をやります」と言ってすぐにできるもので
    はない。組織の文化を変える必要がある。

    Photo by Cara Fuller on Unsplash

    View Slide

  10. Rettyが目指すソフトウェア開発の目標
 confidential
    ● 「グルメサービスRetty」ワンプロダクトで成長する

    ○ メンバーが増えてもプロダクトは増えない。

    ● 全社で重要なことに注力する

    ○ 重要なものから1つずつ対処する。着手からリリースまでを短く。

    ● フィードバックを踏まえ、短期間で方針を見直していく。


    「上記が達成された状態=顧客価値を安定的に届ける」

    を実現するため、アジャイル開発に取り組んでいます。


    View Slide

  11. 開発が抱えていた課題
 confidential

    View Slide

  12. 課題を改めて整理すると・・・
 confidential
    1. アジャイルになっていない開発プロセス

    ○ アジャイルを目指したはずが綺麗なウォーターフォールになっている。

    ○ 開発着手からリリースまでが長い。

    2. レガシーシステムのお守り

    ○ 創業からサービスを支えるPHPモノリス。

    ○ 全体像がわからず、パッチワークがさらなる負債となる。

    3. ドメイン知識が不足し、開発・ビジネスのスピードが上がらない

    ○ 仕様の把握に時間が取られ、開発スピードが遅くなる。

    ○ テストで見るべきポイントが曖昧で増えていく一方。


    View Slide

  13. 1. 開発プロセスの改善

    confidential
    【課題感】

    1. アジャイルを目指したはずが綺麗なウォーターフォールになっている 

    2. 開発着手からリリースまでが長い

    View Slide

  14. スクラムの簡単な紹介
 confidential

    View Slide

  15. アジャイルにやっているつもりが、なぜWFに?
 confidential
    1. 「何を作るか」と「どう作るか」を同じ人が担当。

    2. 手が空いてはいけないと思い、開発タスクを早期に開発
    者へアサイン。

    3. 開発が遅れた時のリカバリが難しくなるので開発項目を
    入念に見積もる。

    Photo by Mike Lewis HeadSmart Media on Unsplash

    View Slide

  16. 開発プロセスをテコ入れしたポイント
 confidential
    QA観点で重要なものを抜粋すると

    ● バックログリファインメントの改善

    ● 開発プロセスの見える化

    ● 小さく定期的に出していく意識の醸成

    Photo by Olga Guryanova on Unsplash

    View Slide

  17. バックログリファインメントの改善
 confidential
    ● バックログの項目に対し、「何をやる
    か」について「複数人」で議論し、「開
    発規模に対しての見積もり」を「ざっく
    りと」出す。メンバ間で見積もりに差異
    が生じた場合、「その背景をきちんと
    議論する」。


    View Slide

  18. だめなバックログリファインメント
 confidential
    ● バックログの項目に対し、「どうやる
    か」について「個人」で考え、「開発期
    間に対しての見積もり」を「正確に」出
    す。メンバ間で見積もりに差異が生じ
    た場合、「どちらかが折れるまで議論
    する」。

    ● バックログの項目に対し、「何をやる
    か」について「複数人」で議論し、「開
    発規模に対しての見積もり」を「ざっく
    りと」出す。メンバ間で見積もりに差異
    が生じた場合、「根拠を互いに共有」
    し「短く終わる」。


    View Slide

  19. バックログリファインメントの目的
    1. 開発スケジュールを正確に見積もるためではない。
    2. 関係者でアイテムについての認識を合わせるため。
    3. バックログのアイテムが開発可能であることを確認する。
    a. 受け入れ条件が明確である。
    b. 見積もりが可能なサイズである。
    c. 実現の目処がついている。
    4. バックログがメンテされ、取り組む価値のある開発項目
    が上位に並ぶようにする。
    ※社内向け説明資料より抜粋

    View Slide

  20. 開発プロセスの見える化
 confidential
    ● 現在の開発プロセスを可視化し、ボトルネックを明確にするためにカンバンを使う。

    ● GitHub Project、ZenHubを使っていたが、ツールが先にあるとツールの使いこなしに
    頭が向いてしまう。

    ○ GitHubのIssueよりも小さい単位でタスクを分割しない

    ○ ツールがサポートしていない項目は可視化しない

    ● 柔軟にカスタマイズができる物理カンバン (壁・ホワイトボード+付箋)で自分たちに
    合ったやり方を確立し、その上で必要ならば電子化する。


    View Slide

  21. カンバンの変化 (1週目)
 confidential
    チームのタスク以外に個人で請け負っ
    ているタスクがたくさん合った

    View Slide

  22. カンバンの変化 (2週目)
 confidential
    振り返りで決めたことを
    常に見える所に掲示

    View Slide

  23. カンバンの変化 (3週目)
 confidential
    社内のリリースフローに合わ
    せてフェーズを詳細化

    View Slide

  24. カンバンの変化 (4週目)
 confidential

    View Slide

  25. 小さく定期的に出していく意識の醸成
 confidential
    ● 大きくリリースしようとすると計画が大変になり、開
    発が複雑になり、QAが大変になり、障害対応も大
    変になる。

    ● 小さく定期的にリリースできれば計画は小さくなり、
    開発はシンプルになり、QAはやることが明確で、障
    害原因の絞り込みもやりやすい。

    ● 例えば

    ○ ありたい姿→ユーザ導線を改善したい。ペー
    ジ構成からヘッダからきちんと設計して刷新す
    る。

    ○ 最初の一歩→あるページに「戻る」リンクをつ
    けて様子を見る。


    View Slide

  26. 開発プロセスの改善 まとめ
 confidential
    ● 【課題感】

    ○ アジャイルを目指したはずが綺麗なウォーターフォール
    になっている

    ○ 開発着手からリリースまでが長い


    ● 【やったこと】

    ○ バックログリファインメントの改善

    ○ 開発プロセスの見える化

    ○ 小さく定期的に出していく意識の醸成

    Photo by Olga Guryanova on Unsplash

    View Slide

  27. 2. レガシーシステムからの脱却

    confidential
    【課題感】

    1. 創業からサービスを支えるPHPモノリス。 

    2. 全体像がわからず、パッチワークがさらなる負債となる。 


    View Slide

  28. 創業からサービスを支えるPHPモノリス
 confidential
    1. サービスの根幹をなす機能が密結合されている。

    2. 正しいビジネスロジックが把握しきれない。

    3. リファクタリング・改善が入れにくい

    Photo by James Hammond on Unsplash

    View Slide

  29. レガシーシステムをテコ入れしたポイント
 confidential
    QA観点で重要なものを抜粋すると

    ● マイクロサービスへの移行

    ● 不要になったコードの削除

    ● ビジネスロジックの整理・簡素化

    Photo by Pranav Kumar Jain on Unsplash

    View Slide

  30. PHPのモノリス→マイクロサービスへの移行
 confidential
    責務を小さく・明確にし、
    リリースしやすくする。
    ⇆ 一般的にQAは難しくなる。

    View Slide

  31. 不要になったコードの削除
 confidential
    ● 「焼け石に水」→「雨だれ岩を穿つ」

    ○ 不要になった機能の削除

    ○ 実行されないコードを削除

    ○ 不要になったブランチの削除

    ○ 不要になったIssueのクローズ

    ● マイクロサービスへの移行と同じくらいモノリスの弱体化は効果がある。


    View Slide

  32. ビジネスロジックの整理・簡素化
 confidential
    ● マイクロサービスの導入と合わせて型を導入

    ○ proto / gRPC

    ○ GraphQL, TypeScript

    ● 不要コードの削除と合わせてロジックの簡素化

    ○ 表示する写真の選別

    ○ 口コミの表示順 などなど


    View Slide

  33. 他にも取り組んでいる技術的な改善
 confidential
    ● CircleCIを使った自動テスト、カバレッジ計測・自動テスト

    ● Dependabotを使ったライブラリの定期的な更新

    ● Datadogを用いたモニタリング機構

    ● Terraformを使ったIaaC


    View Slide

  34. レガシーシステムからの脱却 まとめ
 confidential
    ● 【課題感】

    ○ 創業期を支えたPHPモノリス

    ○ 全体像がわからず、パッチワークがさらなる負債とな
    る。


    ● 【やったこと】

    ○ マイクロサービスへの分割

    ○ 不要になったコードの削除

    ○ ビジネスロジックの整理・簡素化

    Photo by Pranav Kumar Jain on Unsplash

    View Slide

  35. 3. ドメイン知識の蓄積とQAプロセス改善

    confidential
    【課題感】

    1. 仕様の把握に時間が取られ、開発スピードが遅くなる。 

    2. テストで見るべきポイントが曖昧で増えていく一方。 


    View Slide

  36. ドメイン知識が蓄積されず、QA改善が進まない
 confidential
    1. WF型の開発プロセスで、特定個人に知識が溜まる。

    2. PHPモノリスのあちこちにロジックが分散し、As-Isの把握
    すら困難になる。

    3. 上記解決のため、QAプロセスの抜本的な刷新を図るが
    頓挫する。

    Photo by Jessica Sysengrath on Unsplash

    View Slide

  37. ドメイン知識・QAプロセスをテコ入れしたポイント
 confidential
    QA観点で重要なものを抜粋すると

    ● 現状QAプロセスの良い点を認識する。

    ● To-Beではなく、As-Isから改善を進める。

    ● テスト観点・仕様の集積場を設ける。

    Photo by Sikai Gu on Unsplash

    View Slide

  38. 現状QAプロセスの良い点を認識する
 confidential
    ● 【課題】専門のQA組織・チームが無い

    ○ ✖ QA組織・チームを立ち上げよう

    ○ ○ 組織全体でQAをやっていく機運がある。

    ○ ☆ QA組織・チームが立ち上がっても、「ドメイン知識が不足している」という現
    在の問題は改善されないだろう。

    ● 【課題】プランナーがQA項目を考えている

    ○ ✖ QA項目はQAエンジニアが考えてチェックするべき

    ○ ○ プランナーがQA項目を考えることで仕様の矛盾に目が向くようになってい
    る。ユーザ観点のチェック項目はプランナーが作成し、エンジニアは実装観点
    のチェックを実施する。


    View Slide

  39. To-Beではなく、As-Isから改善を進める
 confidential
    ● 「QA組織・チームを立ち上げなければならない」という思い込みを元に、理想の状
    態から逆算して改善を進めようとした。

    ○ QAプロジェクト推進担当者を選出 → 本人の重荷に

    ○ 完全を目指した仕様書 → メンテされず


    ● 理想を話すより、今より少しでも改善される具体的な行動をとる。


    View Slide

  40. テスト観点・仕様の集積場を設ける
 confidential
    社内Confluenceに集積場を設けた。
    ● 問題に気がつくたびに追記する。
    ● まずは書き出してもらうことを優先
    し、後から整理する。
    テスト観点の集積→仕様の集積→テスト
    項目の修正 と段階的に進める

    View Slide

  41. ドメイン知識の蓄積とQAプロセスの改善 まとめ
 confidential
    ● 【課題感】

    ○ 仕様の把握に時間が取られ、開発スピードが遅くなる。

    ○ テストで見るべきポイントが曖昧で増えていく一方。


    ● 【やったこと】

    ○ 現状プロセスの良い点を認識する。

    ○ To-Beではなく、As-Isから改善を進める。

    ○ テスト観点・仕様の集積場を設ける。

    Photo by Sikai Gu on Unsplash

    View Slide

  42. まとめ

    confidential

    View Slide

  43. まとめ
 confidential
    1. 開発プロセスの改善

    ○ バックログリファインメントの改善

    ○ 開発プロセスの見える化

    ○ 小さく定期的に出していく意識の醸成

    2. レガシーシステムからの脱却

    ○ マイクロサービスへの分割

    ○ 不要になったコードの削除

    ○ ビジネスロジックの整理・簡素化

    3. ドメイン知識の蓄積とQAプロセスの改善

    ○ 現状プロセスの良い点を認識

    ○ To-Beではなく、As-Isから改善を進める

    ○ テスト観点・仕様の集積場を設ける


    View Slide

  44. アジャイルな開発をやっていくには
 confidential
    ● アジャイルは状況変化に機敏に対応していけるという「状
    態」である。

    ● 仕組みを導入すればできるものではない。

    ● 組織の文化を変える必要がある。

    Photo by Cara Fuller on Unsplash

    View Slide

  45. Rettyは様々なポジションで仲間を募集しています
 confidential
    Rettyの新たな仲間・募集ポジション一挙公開!
    https://note.mu/retty_inc/n/n5bb837354e47
    または私までお気軽にご連絡ください。
    twitter : @tunepolo
    mailto: [email protected]

    View Slide