2022.07.21にDevelopers Summit 2022 Summerで登壇した内容です。 -- 昨今のソフトウェア開発においてアジリティ向上は重要なテーマであり、高いデプロイ頻度やリードタイム短縮が企業の競争力を左右するといっても過言ではありません。モノタロウでもアジリティ向上は大きな関心事ですが、2000年代前半から成長を支えるECサイトの長大なリリースプロセスにより、改善サイクルを早められない課題がありました。状況を打破するための最初の一手として、モノタロウではカナリアリリース導入を選択しました。アーキテクチャをモダン化して組織の生産性を飛躍的に向上させる打ち手としての、リアルな現場の事例をお話しします。

1. 信頼性とアジリティを同時に上げろ！
モノタロウのカナリアリリース導入
1
2022.07.21 Developers Summit 2022 Summer
© 2022 MonotaRO Co., Ltd. All Rights Reserved.
株式会社MonotaRO 市原功太郎

2. 信頼性・アジリティ
2
信頼性
…… 時間と工数をかけて上げるもの？
アジリティ
…… リスクをとってスピードアップ？
⇒ 同時にかなえたい！

3. 3

4. 市原功太郎
株式会社 MonotaRO
ECシステムエンジニアリング部門
ソフトウェアデリバリーチーム チームリーダー
4
自己紹介

5. アジェンダ
5
● モノタロウの課題
● 負のスパイラルを突破せよ
● カナリアリリース導入

6. 6
モノタロウについて

7. 7
BtoB を対象に、
自ら間接資材の在庫を持ち、
自らオンラインで売るEC 企業
コールセンター、商 品 採 用、物 流、
マーケティング、データサイエンス、
IT など多くの業務とシステムを
自社開発、自社運用している
フルスタック EC カンパニー
事業紹介

8. 8
事業紹介
商品点数
約1800万点
ユーザー数
約600万以上
売上
約1900億円
グローバルに
サービス展開
（2021年度実績）

9. 9
売上・営業利益推移（単体）
10年連続20%成長
売上が3.5年で2倍に

10. 10
モノタロウの課題

11. でも困っている
11

12. ● Aプロジェクト
○ 2019年6月 起案
○ 2021年4月 要件定義開始
○ 2021年8月 工数が肥大化しすぎたため仕切り直し 半年遅れ
○ 2022年1月 機能① リリース 2ヶ月遅れ
○ 2022年8月 機能② リリース予定
● Bプロジェクト
○ 2020年8月 起案
○ 2020年12月 要件定義開始
○ 2021年6月 担当チーム引き継ぎにより仕切り直し 半年遅れ
○ 2022年4月 リリース
12
モノタロウ（EC開発）での近年の開発状況

13. ● 長期化する要件定義
○ 複雑・不明瞭な仕様とシステム。調査が終わらない
● 終わらないコードレビュー
○ 1か月かけて結局再実装
● 動作検証の工数肥大化
● 繰り返されるリリース&ロールバック
● ......
13
プロジェクト長期化

14. ● 仕様書が不十分・不明確
● 組織拡大で、全体を知る神が不在
● 見えづらい依存関係
● Testableではないプログラム
● 事前検証しづらいシステム構成
● ......
色々考えられそう
14
原因は

15. システムの
メンテナンス性が
悪化している
15
原因の根源は
内部品質が
悪化している
長期の開発・運用によって

16. 内部品質
保守性・可読性など開発・運用に影響する品質
外部品質
信頼性・UXなどユーザーが直接体験する品質
16
内部品質と外部品質

17. 成長企業のジレンマ
17
機能開発に集中し、
ビジネス成長を加速
内部品質を向上し、
開発生産性を上げる
当然前者が優先される(当然良いこと)
……コードは汚くなっていく
VS

18. 18
負のスパイラル
機能開発を優先
リファクタリング・
再設計が後回し
開発速度が落ちる
品質向上の時間が
ない
内部品質が悪化する

19. 19

20. 20
負のスパイラルを突破せよ

21. 質とスピードはトレードオフじゃない！！
21
質とスピード
※ 質とスピード（2022春版、質疑応答用資料付き） (和田卓人(t_wada)氏)

22. 悪循環のどこかにメスを入れたい
22
負のスパイラルを突破せよ
ここか
ここ

23. 1. テストやリファクタリングに投資して内部品質を上げる
2. 開発フローを改善して、チケットが流れるようにする
23
選択肢
②
①

24. 既にやっている
例) Software Design連載 「テストが無い」からの脱却
更に頑張って品質をガンガン上げていく作戦
24
選択肢① テストやリファクタリングに投資

25. ● メリット
○ 技術的負債を減少させる長期的な効果が大きい
○ 今後の設計刷新などの活動の足がかりになる
● デメリット
○ 短期的には学習コスト・実装コストが高い
○ 効果が現れるには時間がかかる
25
選択肢① テストやリファクタリングに投資

26. もちろん、継続してやらなきゃいけない
取組みは続けるが、大規模な運動にはしない
→ 別のところにパワーをかけて、まずは余裕をつくりだす
26
選択肢①は今じゃない

27. 改善することで品質向上の余裕を作り出す
……開発フローの何を解決する？
27
選択肢② 開発フロー改善

28. 起案～リリースされるまでのイベントを見直してみる
アイデア リリース完了
28
選択肢② 開発フロー改善
起案 要件定義 設計 開発 テスト デプロイ
ここが制約になっていそう

29. 開発後のデプロイのボトルネックを解消することで
全体フローの効率化・最適化を目指す
● メリット
○ デプロイ一点集中なら少ない人数で取り組める
○ 開発プロセスの制約だったデプロイ課題を解決する
● デメリット
○ 開発速度を直接向上するわけではない
29
選択肢②´ デプロイの仕組み改善

30. ● ビッグバン的リリース
○ MAX 40件以上の変更を同時にマージ
○ 本番にいきなり100%デプロイ
● 週一回のリリース頻度
○ 失敗したら、最悪全チケット翌週に
● デプロイ作業のコストが大きい
○ デプロイ作業は半日以上かかる
○ ユーザー影響を危惧して作業は夕方以降
30
「デプロイ」の課題感

31. ● コードの変更のリスクが大きい
○ 内部品質をあげる取り組みを出しづらい
○ 品質担保に時間をかけすぎる
● 長大なリリース計画
○ リリース計画が数週間単位で長大になりやすい
● デプロイ回数を増やせない
○ デプロイ作業が重い
31
課題から起こっていそうな問題

32. リリースしやすくなる
⏩ 機能開発を回しながら品質改善する余力ができる
⏩ 内部品質が向上する
⏩ 開発しやすくなる
⏩ アジリティが爆上がりする はず！
32
突破のための仮説

33. 改善施策が、本当に効果があるのか調べたい。
そもそも、今ってどのぐらいのアジリティがあるのか？？
33
アジリティを計測する

34. どうやって測る?
⇒ 世の中のプラクティスを取り入れよう！
34
アジリティ計測の方法

35. DevOps Four Keys
● デプロイ頻度
● 変更リードタイム
● MTTR
● 変更失敗率
※ エリート DevOps チームであることを Four Keys プロジェクトで確認する
35
仮説を可視化する

36. 36
Four Keysによるパフォーマンス計測
デプロイ頻度
今はだいたいこのあたり？
変更のリードタイム
サービス復元時間
変更障害率

37. 37
Four Keysによるパフォーマンス計測
デプロイ頻度
こうしたい
変更のリードタイム
サービス復元時間
変更障害率

38. ● エリートvs 低パフォーマンス差
○ from. DORAレポート2021
38
エリートになりたい！
エリートパフォーマンスチームと
低パフォーマンスチームの差
デプロイ頻度 973 倍 高い
変更のリードタイム 6,570 倍 速い
MTTR 6,570 倍 速い
変更障害率 3倍低い

39. 39
カナリアリリース導入

40. 変更を一部のユーザーに先行して適用することで、
全体へのリスクを抑えるデプロイ手法。
経過観察してから全体に変更を適用する。
https://martinfowler.com/bliki/CanaryRelease.html
40
カナリアリリースとは
安定版
カナリア

41. カナリアリリースを導入することで
デプロイ改善の問題を解く
41
作戦

42. ● ビッグバン的リリース
○ MAX 40件以上の変更を同時にマージ
○ 本番にいきなり100%デプロイ
● 週一回のリリース頻度
○ 失敗したら、最悪全チケット翌週に
● デプロイ作業のコストが大きい
○ デプロイ作業は半日以上かかる
○ ユーザー影響を危惧して作業は夕方以降
42
「デプロイ」の課題感
再
掲

43. ● デプロイあたりのリスク低減
○ ユーザー影響は従来の 5%
● MTTR短縮
○ トラフィック遮断で秒速で復旧
○ ユーザーを安定版にルーティング
43
カナリアを通して実現したいこと
ビッグバン的リリースを解決

44. ● デプロイ頻度向上
○ 一日に何度も出すことができる
○ デプロイごとの案件数が減ってリスク減
44
カナリアを通して実現したいこと
週一回のリリース問題を解決

45. ● デプロイ作業の負担軽減
○ テストにかかる時間を短縮
○ デプロイフローを省力化
45
カナリアを通して実現したいこと
デプロイコストの削減

46. ● デプロイ頻度: 1回/week ⇒向上するはず
● 変更リードタイム: 10～14日/ticket ⇒ 短縮するはず
● 障害復旧時間(MTTR): 60分 +α ⇒ 短縮するはず
● 変更失敗率: あまり変わらない
46
DevOps Four Keys では

47. 1. カナリアリリースの導入
2. リリース作業のコスト削減
○ デプロイ作業の自動化
○ E2E受け入れテストの高速化
47
やったこと

48. ①先行してデプロイできる環境を用意し
②重みづけルーティングを実装する
48
1. カナリアリリースの導入

49. 世の中のツールはコンテナ前提のものが多い
モノタロウのサイト主要部分はコンテナ化されてない
⇒世の中の良さげなツールが大体使えない 😥
49
困ったこと

50. 50
自前でつくる
デプロイツール経由で
トラフィック変更・遮断
新規構築
新規構築

51. ● 同時にデプロイが必要な密結合なアプリケーション
○ ⇒ 全部やることで解決
■ すべてのアプリのカナリア版を構築
■ リリースを制限して段階導入
● CDNでキャッシュが混ざってしまった
○ ⇒ コンテンツ配信戦略を見直して解決
51
大変だったこと

52. 52
2. コスト削減：デプロイの自動化
● ステージング・カナリア用環境へ自動で展開
● テストも全て自動で実行
● 開発者は、マージしたら通知を待つだけ
⇒ デプロイ作業担当者がデプロイ頻度向上に対応できる
※ 本番は担当者の手動プロセスあり

53. ● デプロイ後のE2Eテスト待ちが大変
○ 性質上不安定になりがち、再実行もよくある
同日に複数回デプロイするための障壁
53
3. コスト削減：受入れE2Eテストの高速化

54. ● 大幅短縮 25分⇒8分/回
○ シナリオの並列化を活用
⇒ 同日に複数回デプロイ&テストを行える
54
3. コスト削減：受入れE2Eテストの高速化

55. ● アプリケーションの配置や設計には手を入れない
○ コンテナ化やプロダクトコード変更はしない
● デプロイ手法の改善には手を入れない
○ 本番環境の隣にカナリア環境をつくるだけ
○ プロダクトコードを配布する方法はそのまま流用
● カナリアリリースの活用の方法を主導しない
○ 環境を用意して各開発チームの主体性に期待する
55
やらなかったこと

56. 2021.12 起案、設計開始
2022.1 インフラ構築開始
2022.2～3 デプロイツール改修
2022.4～5 運用試験、仮導入
2022.6 本導入。全てのデプロイをカナリア化
2022.7 4回/日, 3日/週の週12回デプロイ開始
56
スケジュール

57. --- やり切ったぜ
57

58. ● デプロイ頻度: 1回/week ⇒12回/week
● 障害復旧時間(MTTR): 60分 +α ⇒ 10分
● 変更リードタイム・リリース実案件数→ 変化なし
○ ⇒ まだ導入一か月。今後に期待
58
導入してどうなったか

59. ● プロデューサー (プロダクトマネージャー)
59
ビジネス側の視点での変化

60. 60
開発メンバーからの反応
トラブル対処が素早くできた件について
本番での不具合を見つけたとき
改善案を素早く出せる

61. 61
カナリアリリースが役立った例
Before
18時30分: リリース失敗
同日夜: リバート
1週間 後: 修正再リリース

62. 62
カナリアリリースが役立った例
Before
18時30分: リリース失敗
同日夜: リバート
1週間 後: 修正再リリース
After
10時30分: リリース失敗
2時間後: リバート完了
2時間後: 修正再リリース
修正リードタイムが 42 倍速！
(168時間後)

63. ● 何もしていないのに、突然良くなった
○ 臨時のリリースを出しやすくなった
○ リリース時のリスクが下がった
○ いろいろ自動化された
● → 少ないリソースで開発組織全体に良い影響
63
開発者目線での変化

64. ● 『質とスピード』社内講演
○ t_wada氏に登壇いただいた
○ 開発者・プロデューサーともに聴講
● SRE導入を通じた議論
○ 開発者、プロデューサーがSLOやユーザージャーニーを議論
○ サービスの核である機能を一緒に理解する
64
開発とビジネスの目線を合わせる

65. ● 内部品質を向上する変更を増やす
● より素早く価値を提供する
● 大きな変更のあるプロジェクトも
細かなフィーチャーに分割して段階デプロイ
● システムの設計変更のリスクを一部転嫁する
65
これからカナリアを活用してやりたいこと

66. 66
カナリアのその先

67. ● カナリアリリースを入れたら理想のシステム開発への
道が開けた
○ 迅速に開発したいが巨大なシステムが足かせだった
○ カナリアリリースでリスクを上げずアジリティ向上した
○ これを起点にアプリのモダン化、
開発文化の変革や組織再編をやっていく
67
まとめ

68. 68
© 2022 MonotaRO Co., Ltd. All Rights Reserved.