基幹システムの刷新をアジャイル開発で取り組んだ課題と成果

デブサミ2022 講演資料

Transcript

1. 基幹システムの刷新を
   アジャイル開発で取り組んだ課題と成果
   株式会社SHIFT
   SHIFT 丸山 佳紀
   

   View Slide

2. 2
   アジェンダ
   1. 自己紹介・会社紹介
   2. 開発体制とアジャイル開発の進め方
   3. アジャイル開発の成果・効果
   4. 職能別開発チームでの振り返りによる事例
   

   View Slide

3. 3
   はじめに
   

   View Slide

4. 4
   自己紹介
   丸山 佳紀 （まるやま よしき）
   名前
   所属
   株式会社 SHIFT
   技術統括部 DevOps推進部 Devops推進3グループ
   QAリード
   経歴
   SIerとして3年働いたのち、SHIFTに転職し3年以上QAとして経験。
   そのなかで、QAチームの立ち上げ、自動テストの導入、開発プロセス改善など品質向上に貢献し
   てきたつもりです！
   プライベートでは料理が好きで、土日の料理を担当。また、4歳の双子の父です。
   

   View Slide

5. 5
   5
   社名 株式会社 ＳＨＩＦＴ
   業務内容 ソフトウェアの品質保証、テスト、開発事業
   設立 2005年9月7日
   上場取引所 東京証券取引所 プライム市場（証券コード：3697）
   代表者 代表取締役社長 丹下 大
   従業員数 連結8,119人 （2022年2月末時点）
   所在地
   【本社＆東京第1オフィス】東京都港区麻布台2-4-5 メソニック39MTビル
   【東京第2オフィス】 東京都港区芝公園4-1-4 メソニック38MTビル
   【札幌第1オフィス】 北海道札幌市中央区北1条西3-3 敷島プラザビル
   【札幌第2オフィス】 北海道札幌市中央区南4条西8-2-1 サンプラーザ札幌
   【仙台オフィス】 宮城県仙台市青葉区本町2-15-1 ルナール仙台（2022年5月開設）
   【名古屋第1オフィス】愛知県名古屋市中区錦1-8-18 錦ハーモニービル
   【大阪第1オフィス】 大阪府大阪市北区堂山町3-3 日本生命梅田ビル
   【大阪第2オフィス】 大阪府大阪市北区太融寺町3-24 日本生命梅田第二ビル
   【広島オフィス】 広島県広島市中区鉄炮町10－12 広島鉄炮町ビルディング（2022年7月開設）
   【福岡第1オフィス】 福岡県福岡市中央区天神5-7-3 福岡天神北ビル
   【福岡第2オフィス】 福岡県福岡市博多区博多駅南2-1-5 博多サンシティビル
   関連会社
   株式会社SHIFT SECURITY
   SHIFT ASIA CO., LTD. ほか 計32社 （2021年8月時点）
   【会社説明】企業概要
   New
   open
   仙台
   New
   open
   広島
   無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供
   

   View Slide

6. 6
   SHIFTの目指す「売れるサービス」づくりに向けて
   6
   SHIFTは
   お客様のビジネス成功に
   コミットする会社に
   「ソフトウェアテスト」
   といえばSHIFT
   「DX」
   「売れるサービスづくり」
   といえばSHIFT
   第一想起
   第一想起
   ソフトウェアのテストを
   受託する会社
   【会社説明】株式会社SHIFTの目指すところ
   

   View Slide

7. 7
   さまざまな工程・開発手法に対応した、品質保証サービスを実施
   7
   【会社説明】株式会社SHIFTのビジネスモデル
   さまざまな工程・開発手法に対応した、品質保証サービスを実施
   プロダクトオーナー
   製品に対して責任をもち、
   機能に優先順位をつける
   ステークホルダー
   製品の利用者、出資者、
   管理職などの利害関係者
   プロダクト
   バックログ
   プランニング
   会議 デイリー
   ミーティング
   製品
   プロダクト
   スプリント
   レビュー
   ふりかえり
   １日
   テスト
   計画
   テスト
   分析・設計
   テスト
   実行
   テスト
   実装
   テスト活動
   実装
   設計
   要件
   定義
   開発活動
   スプリント
   バックログ
   スプリント
   （１〜４週間）
   アジャイルテスト支援
   (計画／設計／実行／レポート)
   スクラム推進支援
   (チームビルド／イベント定着)
   スクラム開発立上げ支援
   (スクラムマスター育成／チーム立ち上
   げ)
   アジャイル導入支援
   (出島戦略／WF差分検討／ロードマップ)
   プロダクトオーナー支援
   (PBL作成／チーム說明／受入)
   スクラム開発チーム支援
   (チーム派遣／インフラ構築)
   アジャイルテスト戦略支援
   (自動テスト導入／テストツール選定／
   テスト方針)
   アジャイル型開発におけるサービス全体像
   

   View Slide

8. 8
   対象システムと開発体制
   アジャイル開発の進め方
   

   View Slide

9. 9
   案件概要
   ■案件概要
   長年使用してきた基幹システムの刷新プロジェクト
   ■案件背景
   会社の成長とともに必要となった機能を追加で対応してきたが、
   複雑なデータモデル、複雑な処理、現在の業務に沿わない機能などが
   多く、メンテナンス性が悪く、業務上も現在は無駄な手順が多いため
   

   View Slide

10. 10
    対象の基幹システム概要（営業管理システム）
    問い合わせ 契約処理 発注処理 請求処理
    納品/出荷処理 支払処理
    問い合わせ情報
    の登録
    顧客情報の
    登録
    見積書作成
    契約書作成
    契約情報
    の登録
    必要な商品情報
    の登録
    仕入先への
    発注書作成
    納品物の確認
    仕入先との
    契約手続き
    顧客の
    出荷手続き
    仕入先への
    支払い処理
    仕入先への
    支払い額計算
    顧客への
    請求処理
    メイン業務
    顧客からの
    入金確認
    

    View Slide

11. 11
    開発体制
    職能別のそれぞれの強みを活かした開発チーム体制
    Backend
    チーム
    Frontend
    チーム
    DB
    チーム
    新システム
    QA
    チーム
    旧システム
    チーム
    プロダクトオーナー
    インフラ
    チーム
    SHIFT
    

    View Slide

12. 12
    1チームからはじまり、開発スピード向上のため、
    メンバー増、チーム拡大となり複数開発体制を構築。
    開発体制
    A開発
    チーム
    B開発
    チーム
    保守開発
    チーム
    Backend
    チーム
    Frontend
    チーム
    DB
    チーム
    新システム
    QA
    チーム
    旧システム
    チーム
    プロダクトオーナー
    インフラ
    チーム
    

    View Slide

13. 13
    アジャイル開発とは何なのか
    

    View Slide

14. 14
    アジャイル開発とは何なのか
    基幹システム、大規模システムだからという理由で
    アジャイル開発ができないわけではない！
    （と思っています）
    アジャイル開発だからこそ出た
    成果、効果をご紹介します。
    

    View Slide

15. 15
    業務単位で区切ったプロダクト単位で開発
    問い合わせ 契約処理 発注処理 請求処理
    納品/出荷処理 支払処理
    問い合わせ情報
    の登録
    顧客情報の
    登録
    見積書作成
    契約書作成
    契約情報
    の登録
    必要な商品情報
    の登録
    仕入先への
    発注書作成
    納品物の確認
    仕入先との
    契約手続き
    顧客の
    出荷手続き
    仕入先への
    支払い処理
    仕入先への
    支払い額計算
    顧客への
    請求処理
    メイン業務
    顧客からの
    入金確認
    

    View Slide

16. 16
    開発プロセス
    ふりかえり
    プロダクト
    バックログ
    プランニング
    会議 デイリー
    ミーティング
    リリース
    スプリント
    レビュー
    ふりかえり
    １日
    開発活動
    スプリント
    バックログ
    スプリント
    （2週間）
    テスト
    計画
    テスト
    分析・設計
    テスト
    実行
    テスト
    実装
    テスト活動
    実装
    設計
    要件
    定義
    4週間〜12週間
    各チームで実施
    複数回のスプリントを経て
    リリースとなる
    各チームで事前に実施
    プランニング会議で
    チーム間のすり合わせ実施
    リリースに必要な機能を
    少しずつつくっていく
    

    View Slide

17. 17
    アジャイル開発の3step
    STEP1 STEP2 STEP3
    1チーム体制で
    小さくスタート
    自動テスト導入による
    バグ検知体制の構築
    複数チーム体制による
    開発スピードUP
    ■ツール選定や環境構築
    新基幹システムのツール選定、
    動作環境の構築、
    新旧システムの連携手法検討
    ■アジャイル開発手法検討
    アジャイル開発による
    基幹システム刷新手法の検討
    Sprint期間、R/P方法など
    ■回帰テストの自動化検討
    システム全体の規模が見えてお
    り、将来的に回帰テストを手動
    テストで行うには無理があるこ
    とがわかっていた。
    ■自動テスト戦略検討
    自動テストの範囲検討、
    自動テストのテストレベル検討
    ■自動テスト実装
    STEP1の実装分に対し自動テス
    トスクリプト作成
    ■複数PJ並行開発体制の構築
    各職能チームの増員
    ■エンハンス対応体制の構築
    営業からの要望対応組織構築
    

    View Slide

18. 18
    基幹システムを
    アジャイルで開発した成果・効果①
    

    View Slide

19. 19
    もしウォーターフォールで開発していたら・・・
    

    View Slide

20. 20
    もしウォーターフォールで開発していたら・・・
    しかし・・？
    

    View Slide

21. 21
    もしウォーターフォールで開発していたら・・・
    実際は
    予定通り進みません！
    

    View Slide

22. 22
    実際にこんなことがありました
    開発がスタートし半年が経ったころ、
    基幹システムへの新規の機能依頼が
    経営層から優先度高でおりてきました。
    仕入先管理システムの新規開発依頼
    いままでは電話により社員側が仕入先情報の登録、
    契約手続きを紙媒体で実施していたところを
    社員の工数がかからないようにしたい。
    

    View Slide

23. 23
    もしウォーターフォールで開発していたら・・・
    実装ができていない状況のなか、
    新たな開発の相談が入ったことになる
    

    View Slide

24. 24
    アジャイルで開発していたから・・・
    アジャイル開発で
    行っていた場合は
    どうでしょうか。
    

    View Slide

25. 25
    アジャイルで開発していたから・・・
    問い合わせ 契約処理 発注処理 請求処理
    納品/出荷処理 支払処理
    問い合わせ情報
    の登録
    顧客情報の
    登録
    見積書作成
    契約書作成
    契約情報
    の登録
    必要な商品情報
    の登録
    仕入先への
    発注書作成
    納品物の確認
    仕入先との
    契約手続き
    顧客の
    出荷手続き
    仕入先への
    支払い処理
    仕入先への
    支払い額計算
    顧客への
    請求処理
    顧客からの
    入金確認
    2ヶ月 2ヶ月 2ヶ月 2ヶ月 2ヶ月 2ヶ月
    2ヶ月 4ヶ月 6ヶ月 8ヶ月 10ヶ月 12ヶ月
    3つの業務を刷新リリース後、
    新規開発の相談が入ってきたことになる
    

    View Slide

26. 26
    アジャイルで開発していたから・・・
    問い合わせ 契約処理 発注処理 請求処理
    納品/出荷処理 支払処理
    問合せ情報
    の登録
    顧客情報の
    登録
    見積書作成
    契約書作成
    契約情報
    の登録
    必要な商品情報
    の登録
    仕入先への
    発注書作成
    納品物の確認
    仕入先との
    契約手続き
    顧客の
    出荷手続き
    仕入先への
    支払い処理
    仕入先への
    支払い額計算
    顧客への
    請求処理
    顧客からの
    入金確認
    2ヶ月 2ヶ月 2ヶ月 2ヶ月 2ヶ月 2ヶ月
    2ヶ月 4ヶ月 6ヶ月 10ヶ月 12ヶ月 14ヶ月
    優先度に応じて開発予定（PBI）を
    柔軟に変更、差し込み開発が可能
    仕入先管理
    仕入先情報
    の登録
    契約処理
    の電子化
    2ヶ月
    8ヶ月
    

    View Slide

27. 27
    基幹システムを
    アジャイルで開発した成果・効果②
    

    View Slide

28. 28
    ウォーターフォールとアジャイルの違い
    ◼ ウォーターフォールでは、
    一度にシステムができあがるため改修後に大きな成果が見込めるが、
    改修の成果が出るまで時間がかかるのに対して
    アジャイルだからこそ
    すぐに業務の効率化、ビジネスの加速に繋がり、
    かつ、より優先度、影響の大きな追加機能の対応も可能。
    

    View Slide

29. 29
    システム刷新による業務効率効果
    システム刷新により業務が効率化され、
    対象業務にかかる工数削減が果たせる見込み。
    機能
    システム刷新前
    必要工数/月
    システム刷新後
    必要工数/月
    開発期間
    問い合わせ 2 人 1 人 2ヶ月
    契約処理 2 人 1 人 2ヶ月
    発注処理 2 人 1 人 2ヶ月
    納品/出荷処理 2 人 1 人 2ヶ月
    支払処理 2 人 1 人 2ヶ月
    請求処理 2 人 1 人 2ヶ月
    仕入先管理 2 人 0 人 2ヶ月
    途中での
    新規開発機能
    

    View Slide

30. 30
    もしウォーターフォールで開発していたら・・・
    工
    数
    /
    月
    時間
    12ヶ月
    15人
    10人
    5人
    14人
    8人
    2ヶ月
    6人
    1ヶ月あたり14人
    12ヶ月間
    ＝168人月
    14ヶ月間合計
    184人月
    1ヶ月あたり8人
    2ヶ月間
    ＝16人月
    14ヶ月
    

    View Slide

31. 31
    アジャイルで開発していたから・・・
    時間
    14人
    2ヶ月
    14ヶ月間合計
    148人月
    12ヶ月
    14ヶ月
    工
    数
    /
    月
    15人
    10人
    5人
    14人×2ヶ月間
    ＝28人月
    13人×2ヶ月間
    ＝26人月
    12人×2ヶ月間
    ＝24人月
    9人
    11人
    11人×2ヶ月間
    ＝22人月
    9人×2ヶ月間
    ＝18人月
    6人
    8人×2ヶ月間
    ＝16人月
    7人×2ヶ月間
    ＝14人月
    

    View Slide

32. 32
    ウォーターフォールとアジャイルの違い
    時間
    14人
    2ヶ月
    12ヶ月
    14ヶ月
    工
    数
    /
    月
    15人
    10人
    5人
    9人
    11人
    6人
    アジャイル開発時
    ウォーターフォール開発時
    最終的な、すべて開発し終えた削減工数は同じだが
    アジャイル開発の場合は
    早くリリースすることにより早く効果が表れる
    

    View Slide

33. 33
    職能別開発チームでの
    振り返り事例
    

    View Slide

34. 34
    SHIFTの振り返り事例
    チームが、つねに最高のパフォーマンスが出せる状態を
    継続してきたわけではない。
    チームのパフォーマンスも
    時には落ち込み
    時には向上し
    歩んできたチームの振り返りについてご紹介します。
    

    View Slide

35. 35
    チームのパフォーマンスの状態
    状態
    時間
    最高
    いまいち
    チーム増加
    メンバー増員
    作業場所が各チーム自社作業に
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/Sprint単位
    振り返り実施
    ・開発チーム全体/sprint単位
    振り返り実施
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    振り返り実施
    開発チームの振り返りが
    リリース単位では、長すぎて
    それまでに細かな問題の多くが
    放置されていた
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    ・QAチーム全体/Sprint単位
    振り返り実施
    QAチーム全体での振り返りが
    Sprint単位で、2週間前のことな
    んで覚えていないことが多々発生
    …
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    ・QAチーム全体/Sprint単位
    ・QAチーム全体/1週間単位
    振り返り実施
    完全リモートワーク化
    徐々に振り返りが減っていった
    QAチーム全体/Sprint単位
    振り返りしかできていない
    

    View Slide

36. 36
    SHIFTの振り返り事例
    開発チーム全体/Sprint（2週間）単位
    で振り返りを実施
    プロダクト
    バックログ
    プランニング
    会議 デイリー
    ミーティング
    リリース
    スプリント
    レビュー
    ふりかえり
    １日
    開発活動
    スプリント
    バックログ
    スプリント
    （2週間）
    テスト
    計画
    テスト
    分析・設計
    テスト
    実行
    テスト
    実装
    テスト活動
    実装
    設計
    要件
    定義
    4週間〜12週間
    

    View Slide

37. 37
    Backend
    チーム
    Frontend
    チーム
    DB
    チーム
    新システム
    QA
    チーム
    旧システム
    チーム
    プロダクトオーナー
    インフラ
    チーム
    開発チームも1チーム、関係者も10人程度だったこともあり、
    目線が揃いやすく、チームのパフォーマンス向上に向けて
    開発チーム全員で進められていた。
    SHIFTの振り返り事例
    

    View Slide

38. 38
    チームのパフォーマンスの状態
    状態
    時間
    最高
    いまいち
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/Sprint単位
    振り返り実施
    ・開発チーム全体/sprint単位
    振り返り実施
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    振り返り実施
    開発チームの振り返りが
    リリース単位では、長すぎて
    それまでに細かな問題の多くが
    放置されていた
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    ・QAチーム全体/Sprint単位
    振り返り実施
    QAチーム全体での振り返りが
    Sprint単位で、2週間前のことな
    んで覚えていないことが多々発生
    …
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    ・QAチーム全体/Sprint単位
    ・QAチーム全体/1週間単位
    振り返り実施
    完全リモートワーク化
    徐々に振り返りが減っていった
    QAチーム全体/Sprint単位
    振り返りしかできていない
    チーム増加
    メンバー増員
    作業場所が各チーム自社作業に
    

    View Slide

39. 39
    SHIFTの振り返り事例
    Backend
    チーム
    Frontend
    チーム
    DB
    チーム
    新システム
    QA
    チーム
    旧システム
    チーム
    プロダクトオーナー
    インフラ
    チーム
    A開発
    チーム
    B開発
    チーム
    B開発チームの内容、
    興味ないんだけどなぁ
    A開発チームの内容、
    興味ないんだけどなぁ
    日々の作業場所が異なり、コミュニケーションも希薄に。
    心理的安全性も低くなってきており、
    意見も出にくくなっていく・・・
    

    View Slide

40. 40
    SHIFTの振り返り事例
    ・開発チーム単位での振り返りを実施
    2つの開発チームがあるので、分けて2回実施
    ・開発チーム全体での振り返りを実施
    全体の課題、チーム単位での課題の改善に向かっていった
    ・開発チーム単位で、不具合多発といった課題改善
    ・開発チーム全体でのコミュニケーション課題の改善
    

    View Slide

41. 41
    SHIFTの振り返り事例
    開発チーム全体/Sprint（2週間）単位
    開発チーム単位/ Sprint（2週間）単位
    で振り返りを実施
    プロダクト
    バックログ
    プランニング
    会議 デイリー
    ミーティング
    リリース
    スプリント
    レビュー
    ふりかえり
    １日
    開発活動
    スプリント
    バックログ
    スプリント
    （2週間）
    テスト
    計画
    テスト
    分析・設計
    テスト
    実行
    テスト
    実装
    テスト活動
    実装
    設計
    要件
    定義
    4週間〜12週間
    

    View Slide

42. 42
    SHIFTの振り返り事例
    Backend
    チーム
    Frontend
    チーム
    DB
    チーム
    新システム
    QA
    チーム
    旧システム
    チーム
    プロダクトオーナー
    インフラ
    チーム
    A開発
    チーム
    B開発
    チーム
    要件定義しか進められてなくて、
    チームの課題も特にない
    テストも終えて、
    障害多発という課題に対して
    対策検討
    

    View Slide

43. 43
    SHIFTの振り返り事例
    効率の悪い振り返りを減らすため、
    開発チーム単位での振り返りをリリース後に実施
    次の開発に向けて改善を講じることができた
    開発チーム単位での振り返りでは、
    開発フェーズによっては振り返りの効果が薄かった
    

    View Slide

44. 44
    SHIFTの振り返り事例
    開発チーム全体/Sprint（2週間）単位
    開発チーム単位/リリース単位
    で振り返りを実施
    ふりかえり
    プロダクト
    バックログ
    プランニング
    会議 デイリー
    ミーティング
    リリース
    スプリント
    レビュー
    ふりかえり
    １日
    開発活動
    スプリント
    バックログ
    スプリント
    （2週間）
    テスト
    計画
    テスト
    分析・設
    計
    テスト
    実行
    テスト
    実装
    テスト活動
    実装
    設計
    要件
    定義
    4週間〜12週間
    

    View Slide

45. 45
    チームのパフォーマンスの状態
    状態
    時間
    最高
    いまいち
    チーム増加
    メンバー増員
    作業場所が各チーム自社作業に
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/Sprint単位
    振り返り実施
    ・開発チーム全体/sprint単位
    振り返り実施
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    振り返り実施
    開発チームの振り返りがリリース単位では、
    長すぎてそれまでに細かな問題の多くが
    放置されていた
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    ・QAチーム全体/Sprint単位
    振り返り実施
    QAチーム全体での振り返りが
    Sprint単位で、2週間前のことな
    んで覚えていないことが多々発生
    …
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    ・QAチーム全体/Sprint単位
    ・QAチーム全体/1週間単位
    振り返り実施
    完全リモートワーク化
    徐々に振り返りが減っていった
    QAチーム全体/Sprint単位
    振り返りしかできていない
    

    View Slide

46. 46
    SHIFTの振り返り事例
    開発チーム単位での振り返りがリリースごととなり、
    最大12週間ほど振り返りが実施されない状況。
    細かな問題が放置され、
    チームのパフォーマンス、状態が悪化していっていた
    

    View Slide

47. 47
    SHIFTの振り返り事例
    Backend
    チーム
    Frontend
    チーム
    DB
    チーム
    新システム
    QA
    チーム
    旧システム
    チーム
    プロダクトオーナー
    インフラ
    チーム
    A開発
    チーム
    B開発
    チーム
    開発チーム間、人によってで
    仕様の認識が違うなぁ…
    一部の開発チームの進捗が遅れているけど
    テストする時間はあるのだろうか…
    

    View Slide

48. 48
    SHIFTの振り返り事例
    QAチーム単体で2週間単位で振り返り実施により、
    QAチーム目線での開発途中でのチーム課題に対し
    取り組むことができるように。
    リリース後の振り返りでは、
    開発途中での課題に目が向きにくい状況になっていた。
    

    View Slide

49. 49
    SHIFTの振り返り事例
    開発チーム全体/Sprint（2週間）単位
    開発チーム単位/リリース単位
    QAチーム全体/ Sprint（2週間）単位
    で振り返りを実施
    ふりかえり
    プロダクト
    バックログ
    プランニング
    会議 デイリー
    ミーティング
    リリース
    スプリント
    レビュー
    ふりかえり
    １日
    開発活動
    スプリント
    バックログ
    スプリント
    （2週間）
    テスト
    計画
    テスト
    分析・設
    計
    テスト
    実行
    テスト
    実装
    テスト活動
    実装
    設計
    要件
    定義
    4週間〜12週間
    

    View Slide

50. 50
    チームのパフォーマンスの状態
    状態
    時間
    最高
    いまいち
    チーム増加
    メンバー増員
    作業場所が各チーム自社作業に
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/Sprint単位
    振り返り実施
    ・開発チーム全体/sprint単位
    振り返り実施
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    振り返り実施
    開発チームの振り返りが
    リリース単位では、長すぎて
    それまでに細かな問題の多くが
    放置されていた
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    ・QAチーム全体/Sprint単位
    振り返り実施
    QAチーム全体での振り返りが
    Sprint単位で、2週間前のこと
    なんで覚えていないことが多々発生…
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    ・QAチーム全体/Sprint単位
    ・QAチーム全体/1週間単位
    振り返り実施
    完全リモートワーク化
    徐々に振り返りが減っていった
    QAチーム全体/Sprint単位
    振り返りしかできていない
    

    View Slide

51. 51
    SHIFTの振り返り事例
    振り返りをしても、
    この1週間くらいのことしか覚えていないことが多発
    直近で起きた課題しか改善に取り組むことができず、
    2週間の間の本当に重要な課題、改善すべき課題の
    解決に取り組むことができていなかった。
    

    View Slide

52. 52
    SHIFTの振り返り事例
    QAチーム（SHFITチーム）内で
    1週間単位で振り返りを行うことで、
    振り返って思い出せるの範囲で振り返りが開催され、
    小さな課題にも対応でき、改善スピード向上し、
    チームが良い状態に！
    

    View Slide

53. 53
    SHIFTの振り返り事例
    開発チーム全体/Sprint（2週間）単位
    開発チーム単位/リリース単位
    で振り返りを実施
    ふりかえり
    プロダクト
    バックログ
    プランニング
    会議 デイリー
    ミーティング
    リリース
    スプリント
    レビュー
    ふりかえり
    １日
    開発活動
    スプリント
    バックログ
    スプリント
    （2週間）
    テスト
    計画
    テスト
    分析・設
    計
    テスト
    実行
    テスト
    実装
    テスト活動
    実装
    設計
    要件
    定義
    4週間〜12週間
    QAチーム/1週間単位
    で振り返りを実施
    ふりかえり
    

    View Slide

54. 54
    チームのパフォーマンスの状態
    状態
    時間
    最高
    いまいち
    チーム増加
    メンバー増員
    作業場所が各チーム自社作業に
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/Sprint単位
    振り返り実施
    ・開発チーム全体/sprint単位
    振り返り実施
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    振り返り実施
    開発チームの振り返りが
    リリース単位では、長すぎて
    それまでに細かな問題の多くが
    放置されていた
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    ・QAチーム全体/Sprint単位
    振り返り実施
    ・開発チーム全体/Sprint単位
    ・開発チーム単位/リリース単位
    ・QAチーム全体/Sprint単位
    ・QAチーム全体/1週間単位
    振り返り実施
    QAチーム全体での振り返りが
    Sprint単位で、2週間前のことな
    んで覚えていないことが多々発生
    …
    完全リモートワーク化
    徐々に振り返りが減っていった…
    

    View Slide

55. 55
    SHIFTの振り返り事例
    いままでの振り返りは対面で行っていたが、
    各社リモートワーク化に伴い、振り返りもオンライン化。
    職能チームだからこそ、チーム間の連携も難しく、
    QAチーム内でも出社に比べコミュニケーションが希薄
    振り返りが徐々に減っていった。
    

    View Slide

56. 56
    SHIFTの振り返り事例
    チームのよくない状態を改善しなければ、
    良い開発プロセスになることはなく、
    よい開発プロセスにならななければ
    よいプロダクトをつくることもできない！
    まだ継続している開発PJなので、
    これからも改善をしていきます！
    

    View Slide

57. 57
    まとめ
    

    View Slide

58. 58
    基幹システムをアジャイル開発で行った際の効果
    • 大規模システムはアジャイル開発には向いていない？
    →そんなことはありません！
    アジャイル開発の考え方は大規模システムこそ必要です！
    今回は、
    業務カットによる開発
    スケジュールの柔軟な変更により
    価値の高いシステムを早く
    提供することができました。
    

    View Slide

59. 59
    振り返り（改善）プロセスがもっとも重要
    実際に弊社が基幹システムの刷新というプロジェクトに
    QAチームとして参画した事例となっています。
    開発サイクルを回すことで、改善できる機会が多くなり、
    振り返りによる効果を徐々に発揮でき、
    チームが高いパフォーマンスを出すことができるようになる、
    と私は思っています。
    課題の一例
    ・チーム間の認識齟齬による障害が多い
    ・途中の仕様変更が多くリリース影響が出ている
    ・会議が終了時間で終わっていない
    ・QAチームのテストと開発チームのテストが重複しているのではないか
    ・ドキュメントがなく、過去の仕様、なぜそうなったのかわからない
    

    View Slide

60. View Slide