2015/07/29 Developers Summit 2015 Summerでの、志田の講演資料になります

1. 2015/7/30
経営のアジリティを支えるDevOpsと組織
リクルートテクノロジーズ
志田 一茂

2. Page 2 Page 2
自己紹介
志田 一茂
株式会社リクルートテクノロジーズ
ITマネジメント部 執行役員
①2006年～2010年
SierからリクルートのIT部門へ転職。
新規Webサービスのアジャイル開発の推進を担当。
②2011年～ 2012年
スマートデバイスアプリ(iOS, Android)のアジャイル開発/運用組織の立ち上げ。
全社のスマートデバイス戦略を担当。
③2013年～
執行役員
担当事業会社のIT戦略の立案・推進を担当
④2014年～
主要サービスでのビジネス高速化に向けDevOps推進組織を立ち上げ中。

3. Page 3 Page 3
Agenda
1. リクルート会社概要
3. 短期スピードを求めたAgile開発事例
4. エンタープライズ領域でのDevOps実現の事例
5. ITがビジネスを牽引する為に
2. リクルートのビジネスとIT活用

4. Page 4 Page 4
リクルート会社概要
創立 1960年「大学新聞広告社」としてスタート
グループ
従業員数
31,841名
連結売上高 約12,999億
連結経常利益 1,256億
グループ
企業数
162社(国内＋海外)
リクルート事業紹介
http://www.recruit.jp/company/about/data/
※数値は２０１５年３月末時点

5. Page 5 Page 5
リクルート会社概要
2012年10月 新経営体制へ移行
リクルート→5つの事業会社+3つの機能会社へ

6. Page 6 Page 6
リクルート会社概要
リクルートグループ各社の現在・将来のニーズを見据えて
競合優位性の高いIT・ネットマーケティング基盤を
開拓、ビジネス実装することにより
リクルートグループの競争優位を構築していく。
IT・ネットマーケティング領域の専門部隊。
リクルートグループをITで牽引する企業です
リクルートテクノロジーズのミッション

7. Page 7 Page 7
リクルート会社概要
リクルートグループ
各サービス
リクルートテクノロジーズ
ビジネス視点の
ITマネジメント
サービス開発部隊
サーバーセキュリティ
社内インフラ
サービスインフラ基盤
ビッグデータ
次世代 R&D
大規模プロジェクト推進
共通基幹システム
ソリューション別専門部隊
ビジネスニーズ
×
ソリューション
リクルートテクノロジーズの組織
サービス開発部隊×ソリューション別専門部隊

8. Page 8 Page 8
Agenda
1. リクルート会社概要
3. 短期スピードを求めたAgile開発事例
4. エンタープライズ領域でのDevOps実現の事例
2. リクルートのビジネスとIT活用
5. ITがビジネスを牽引する為に

9. Page 9 Page 9
リクルートのIT活用
～’90年代
S/W As a System
高品質
Waterfall
IT
Business
IT
Business
IT
Business
～’00年代
S/W As a Service
短納期/低コスト
Agile
Offshore
‘10年代
S/W As a Business
ビジネスバリュー
Lean Startup
DevOps
ソフトウェア-ビジネスの相関とプロセスの変遷

10. Page 10 Page 10
リクルートのIT活用
～’90年代
S/W As a System
高品質
Waterfall
～’00年代
S/W As a Service
短納期/低コスト
Agile
Offshore
‘10年代
S/W As a Business
ビジネスバリュー
Lean Startup
DevOps
【紙の時代】
本誌制作を支える
手段としての
IT活用
【Netシフトの時代】
Net商品でのマネタイ
ズを支える手段とし
てのIT活用
【ITが源泉の時代】
ITがビジネス創出の
コアコンピタンスへ
リクルートのプロダクト変遷とIT活用の変化

11. Page 11 Page 11
リクルート会社概要
http://www.recruit.jp/company/about/data/
多岐にまたがる事業領域
あらゆる領域の"不"を解消する

12. Page 12 Page 12
リクルート会社概要
350
200
267
スマホアプリの
主要ブランド数
ネットサービスの
主要ブランド数
「紙」のブランド数
（市販誌、無代誌、ムック）
出典:日経ビジネス 2014/04/07号
リクルートグループのブランド(サービス数)

13. Page 13 Page 13
Agenda
1. リクルート会社概要
3. 短期スピードを求めたAgile開発事例
4. エンタープライズ領域でのDevOps実現の事例
2. リクルートのビジネスとIT活用
5. ITがビジネスを牽引する為に

14. Page 14 Page 14
リクルートのIT活用
～’90年代
S/W As a System
高品質
Waterfall
IT
Business
IT
Business
IT
Business
～’00年代
S/W As a Service
短納期/低コスト
Agile
Offshore
‘10年代
S/W As a Business
ビジネスバリュー
Lean Startup
DevOps
ソフトウェア-ビジネスの相関とプロセスの変遷

15. Page 15 Page 15
アジャイル適用の背景
リリース直後から最大の効果を生むビジネス
→ 品質重視のシステム開発
情報誌
Agile適用の検討へ
差別化機能もスグに競合に模倣される
参入障壁の低下
競合より早くリリースする事がビジネス価値
→ 短納期重視のシステム開発
Net
急速なNetシフトに伴う開発を取り巻く環境変化

16. Page 16 Page 16
リクルート会社概要
http://www.slideshare.net/devsumi2009/12a525
詳細はデブサミ2009の事例紹介参照
独自Agile開発スキーム “SWAT” 構築

17. Page 17 Page 17
SWATのサマリ
プロセス
新サービス短納期立上げに特化した
独自のAgileスキームを構築
組織/体制
開発部門のみ専門組織化
社員PM＋外部エンジニア常駐
基盤 アプリケーション開発のみ標準化
構築実績
2006年～2008年の３年弱
新規25サービスの構築
平均納期
1サービスの開発期間は
平均して約3～4か月
生産性
開発生産性(FP計測ベース)で
約40～50FP/人月
ゴール：初期リリースまでの納期短縮
と、当時は一定の成果を生み出すもその後、3つの大きな課題に直面！

18. Page 18 Page 18
リクルートにおけるAgile開発
SWAT2.0説明資料@2008 FITシステム基盤推進室 ASG
2006年1月
短納期FSソリューション
“Rapid”
2007年4月
SWATの正式ソリューション化
“SWAT1.0”リリース
2008年10月
SWATのバージョンUP
“SWAT2.0”リリース
① 独自Agile開発スキームの継続運営・展開課題
☑ 最初はライトなルールが徐々に複雑化。覚えられない…

19. Page 19 Page 19
SWATで顕在化した課題
ビジネス 開発 運用
Slow Quick Slow
効果的なビジネス施策を
継続的に短サイクルで打ち
出せない。
品質担保の観点、
アーキテクチュア制約、
インフラ制約などで
素早くリリース出来ない。
☑ リリース後のエンハンス開発フェーズにおいて、
短サイクルで効果的な企画出し、高速な運用が困難に
② 立ち上げ後にWater-Scrum-Fallに陥る課題
ビジネス
企画
サービス
企画
システム
開発
システム
運用

20. Page 20 Page 20
SWATで顕在化した課題
☑ ビジネスの拡大と共に体制拡大/高まる品質要求に対して
独自Agileスキームが限界→W/Fモデルでスピードを失う
成長 成熟 再成長/衰退新規
Agile開発
小規模/シンプル
一体型/少人数
納期
③ 組織体制の物理スケール対応の課題
大規模/複雑
分業型/大人数
品質
W/F開発

21. Page 21 Page 21
Agenda
1. リクルート会社概要
3. 短期スピードを求めたAgile開発事例
4. エンタープライズ領域でのDevOps実現の事例
2. リクルートのビジネスとIT活用
5. ITがビジネスを牽引する為に

22. Page 22 Page 22
リクルートのIT活用
～’90年代
S/W As a System
高品質
Waterfall
IT
Business
IT
Business
IT
Business
～’00年代
S/W As a Service
短納期/低コスト
Agile
Offshore
‘10年代
S/W As a Business
ビジネスバリュー
Lean Startup
DevOps
ソフトウェア-ビジネスの相関とプロセスの変遷

23. Page 23 Page 23
エンタープライズ領域への挑戦
☑ 新規サービスでAgile導入は組織内で定着化した一方、
収益源泉の主要サービスは大規模・分業のW/Fモデル
成長 成熟 再成長/衰退新規
Agile開発
W/F開発
小規模/シンプル 大規模/複雑
一体型/少人数 分業型/大人数
納期 品質
エンタープライズ領域の開発再加速への挑戦
再加速
主要10数
サービス
200弱
ビジネス収益を支える
トップブランド群
将来のビジネス収益を
得るための投資

24. Page 24 Page 24
エンタープライズ領域への挑戦
24
ビジネス部門
大規模プロダクトの組織分業構成と責務
IT部門
ビジネス
企画
サービス
企画
システム
開発
システム
運用
☑ ビジネス部門はKPI、IT部門はQCDに責務を負う分業構造
中長期
ビジネスKPI
短期
サービスKPI
短期
システムQCD
中長期
システムQCD
アプリエンジニア インフラエンジニアプロデューサー ディレクター

25. Page 25 Page 25
エンタープライズ領域への挑戦
25
ビジネス部門
大規模プロダクトの企画～開発～運用プロセス
IT部門
ビジネス
企画
サービス
企画
システム
開発
システム
運用
☑ 機能間の連携で無駄は多いが安定するサイクル設計
要件
定義
設計 製造 テスト
W/F ITIL

26. Page 26 Page 26
エンタープライズ領域への挑戦
26
ビジネス部門
長期の継続開発で徐々に蓄積する負がスピードを阻害
IT部門
ビジネス
企画
サービス
企画
システム
開発
システム
運用
☑ 相互の責務についての信頼がなければ改善は難しい
アプリ密結合化
データモデル複雑化
パフォーマンス課題
EOSLの対応
施策の肥大化
個別要件の多様化
破壊的競合の台頭
市場の不確実性
遅い,高い,品質悪い！
（怒！！！！）
効果的な施策がない！
だったら、やらない！

27. Page 27 Page 27
エンタープライズ領域への挑戦
混乱からの改善の道筋…重視した4つのポイント
プロセス 一気通貫でのプロセスの構築
組織/体制 所属を超えた一体型の体制の構築
基盤 全体が効率化する環境/基盤の構築
文化/風土 改革を進める風土・経営の覚悟
☑ DevOpsではCAMSとCALMSSと定義され始めているが、
下記を整合性を持って変革していく方針を立てた。

28. Page 28 Page 28
サービス
企画
システム
開発
W/F
エンタープライズ領域への挑戦
28
全体最適の足掛かりにHUBとなる企画-開発の
Agile開発化の実現に最初に着手
ビジネス部門 IT部門
ビジネス
企画
システム
運用
サービス
開発
Agile
☑ 前述したSWATでのAgileノウハウを活用し多段構成を解消

29. Page 29 Page 29
プロセス最適化
参考URL：http://www.scrumalliance.org/certifications
まずベースとなる共通概念、体系的な理解促進
☑ SWAT時の独自Agileの継続運用課題を反省を踏まえ、
デファクト且つトレーニング体系の整ったScrumを適用

30. Page 30 Page 30
エンタープライズ領域への挑戦
ビジネス部門と一緒に相互理解の促進を図り一体感醸成

31. Page 31 Page 31
サービス
企画
システム
開発
エンタープライズ領域への挑戦
31
ビジネス部門 IT部門
ビジネス
企画
システム
運用
Scrumチーム
各機能のメンバーをアサインしScrumチームを構成
☑ 開発部門に閉じずビジネス部門のキーマンもアサイン

32. Page 32 Page 32
エンタープライズ領域への挑戦
32
独立したScrumチームを編成し自己組織化を促す
ビジネス部門 運用部門
ビジネス
企画
システム
運用
☑ 分離と共にScrumチームへ可能な限り権限を委譲
Scrumチーム
PO
Dev
Ops
任せる！
(気になるけど)
信じてる
(怖いけど)

33. Page 33 Page 33
エンタープライズ領域への挑戦
33
必然的に前述したWater-Scrum-Fallの課題に対峙
ビジネス部門 運用部門
ビジネス
企画
システム
運用
サービス
開発
Scrum
☑ 前後とのサイクルラグはScrumだけでは改善されない
開発部門

34. Page 34 Page 34
エンタープライズ領域への挑戦
34
最終的なゴールは全体スループットの向上
ビジネス
企画
システム
運用
サービス
開発
☑ 各機能のサイクルスピードを同期しムダを無くす設計が必要

35. Page 35 Page 35
エンタープライズ領域への挑戦
35
前後を接続するプロセス設計の検討
ビジネス
企画
システム
運用
サービス
開発
☑ Scrumチームの課題に対して最適な解決方法論の選択
Scrum

36. Page 36 Page 36
エンタープライズ領域への挑戦
36
データドリブンの仮説検証型のビジネス企画へシフト
ビジネス
企画
システム
運用
サービス
開発
☑ 粒度の大きい案件の割に効果が出ない企画立案課題を解決
LeanStartup
Scrum

37. Page 37 Page 37
エンタープライズ領域への挑戦
37
Scrum
Sprint
2Weeks
ビジネスと開発の接続設計の明確化とサイクル同期
☑ 仮説検証型シフトで案件粒度が細分化しAgile適合度向上
☑ まずA/Bテストを実施、結果を持って正式リリース

38. Page 38 Page 38
エンタープライズ領域への挑戦
38
DevOpsをチームと運用部門の共通概念に設定
ビジネス
企画
システム
運用
サービス
開発
☑ ScrumとITIL異なる改善サイクル差異をDevOpsで解決
Scrum
LeanStartup DevOps

39. Page 39 Page 39
エンタープライズ領域への挑戦
39
Sprint
2Weeks
開発チームの改善が全体のITSMの推進に繋がる設計
☑ スプリント毎に技術負債リストを作成・更新
☑ 短期課題の改善目標を共通ミッションとして設定
技術
負債
短期
課題
中長期
課題
組織
戦略へ
Scrum ITIL

40. Page 40 Page 40
エンタープライズ領域への挑戦
ITS/BTS
ツール
SCM
S/W構成管理
CI
継続的インテグレー
ションツール
テスト環境
サービス
本番環境
検品
CD
継続的デプロイメントツール
継続的
モニタリング基盤
継続的
コラボレーション
基盤
継続的
デリバリー基盤
コラボレーション
ツール
Scrum
チーム
モニタリング
ダッシュボード
チームが効率的に動く基盤を試行錯誤で構築中
モニタリング
ツール

41. Page 41 Page 41
エンタープライズ領域への挑戦
41
モニタリングダッシュボード
A/Bテスト分析結果
新機能
UI/UX改善
パフォーマンス
改善
企画立案
PO
Dev
データ分析
Ops
チームが情報をシェアするモニタリング基盤が効果大
☑ 立場を超えて新企画立案や課題解決案が出る状態に

42. Page 42 Page 42
エンタープライズ領域への挑戦
42
異なる方法論/概念を取り入れつつ全体最適をとった
ビジネス
企画
システム
運用
サービス
開発
☑ 自己組織化したScrumチームがボトムアップで課題を解決
Scrum
DevOpsLeanStartup

43. Page 43 Page 43
エンタープライズ領域への挑戦
43
広義にDevOpsとはビジネス全体の加速を促す事
ビジネス
企画
システム
運用
サービス
開発
☑ CI環境、リリースの自動化などに目が行きがちだが
組織のアクティビティ全体への貢献に高い価値を生み出す
DevOps

44. Page 44 Page 44
DevOps推進のサマリ
開発プロセス
共通言語しやすいScrumを基軸に
DevOps/LeanStartupの概念と接続
組織/体制
開発部門内部に閉じず、関連する部門を
巻き込み組織再編成
基盤
アプリ×インフラ基盤
チームを支える業務基盤
構築実績 主要2サービスで一年実施中
リリース
サイクル
2週間スプリントを継続し安定・向上
現在は部分的に1週間スプリント
ビジネス貢献
投入人月ベースでは純減で、
ビジネスKPI/SLA目標を達成
ゴール：サービスの継続的成長をITでリードする

45. Page 45 Page 45
Agenda
1. リクルート会社概要
3. 短期スピードを求めたAgile開発事例
4. エンタープライズ領域でのDevOps実現の事例
2. リクルートのビジネスとIT活用
5. ITがビジネスを牽引する為に

46. Page 46 Page 46
変革を進める上でのスタンス
目的と手段を混合しない
“XXXX”は手段であり、目的ではない。
IT課題を把握・改善提案できるのはIT部門のみ。
愚痴るな、声に出して問題提起・改善提案しろ。
目先の目標ではなく、中長期の目標達成を優先する。
残業するなパワープレーの対応は将来の負債を増やすだけ。
何かを変えるアクションには必ずネガティブな意見は出る。
信念を持って、粘り強く推進する覚悟と努力が必要。
IT部門のマネージャとして心掛けている事
（＝日々、部下に言っている小言）

47. Page 47 Page 47
経営層の意識改革
集客 営業
商品企画
システム開発
増員
ク
ラ
イ
ア
ン
ト
企
業
増員
カ
ス
タ
マ
ー
広告費増額
IT投資を増員では無く、
自己組織化、クロスファンクション化の推進投資へ
☑ 開発において体制拡大はスピードダウンの元凶になる

48. Page 48 Page 48
経営層の意識改革
Fixed
Parameter
Variable
Parameter
Scope
Time Resource
従来の概念 転換後の概念
Time
Scope
Resource
IT部門はマネジメントパラメータの転換を行う
☑ 体制とリリースサイクルを固定化し、チームの習熟に
伴いアウトプットが徐々に増えるという考えにシフト。

49. Page 49 Page 49
経営層の意識改革
従来の開発
検証型の開発
ビジネス
価値
時間
案件
ビジネス
価値
時間
検証 検証 検証 検証
・市場への早期リリース
・確実なROIと投資抑制
経営がプロセス差異を理解し使い分ける
・ 想定するビジネス価値の過大評価
・ デリバリ制約

50. Page 50 Page 50
経営層の意識改革
☑ 企画立案～リリースまでのリードタイムを圧縮する必要
ビジネス部門が
要する時間
IT部門が
要する時間
ビジネス部門が
要する時間
IT部門が
要する時間
ビジネス部門が
要する時間
IT部門が
要する時間
IT部門内に閉じた施策では期間短縮は限定的
☑ 経営の合意を持ってビジネス部門と連携して全体最適

51. Page 51 Page 51
密結合
経年劣化したアーキテクチュア
アーキテクチュアマネジメント
☑ 経年劣化した大規模システムは部分切り出しつつアジャイル化
システムC
システムB
システムA
次世代アーキテクチュア
密結合
経年劣化したアーキテクチュア
システムC
システムB
システムA
密結合
経年劣化したアーキテクチュア
次世代アーキテクチュア
システムC
システムB
システムB
肥大化・密結合化したシステムでAgile開発は困難
ビジネス優先度の高いサブシステムを切り出し刷新

52. Page 52 Page 52
アーキテクチャ指針の転換
サイトA サイトB
ソースコード ソースコード
サイトA サイトB
ソースコード ソースコード
ソースコード
（共通部分）
従来 アジャイル
開発チーム 開発Aチーム 開発Bチーム
☑ アーキテクトとして推奨される共通化が逆に足枷になるケースも
システム屋都合の共通化はアジャイルの妨げになる

53. Page 53 Page 53
組織・体制の整備
☑ 組織の距離を縮める＝組織変更 or プロジェクト化
部門間調整の無駄、重複検討タスクの無駄・・・
マネジメントライン複数化による承認プロセスの無駄
インタラクティブな企画・要件検討を推進する。
認識合わせの為のムダな中間成果物作成の時間を無くす。
☑ 物理的な距離も縮める＝ワンロケーション
可能な限りセクショナリズムを排除する

54. Page 54 Page 54
さいごに
ご清聴ありがとう御座いました
Speed for Enterprise
～デベロッパーがエンジンとなって企業ビジネスを加速させていきましょう～