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

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

3 はじめに

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

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の総合ソリューションを提供

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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人月

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

57 まとめ

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

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

No content