ビジネス成長を最大化するサービスマネジメント

2019/6/19 itSMF Japan 第75回セミナでの仲江の講演資料になります

Transcript

1. ビジネス成長を最大化する サービスマネジメント 2019年6月19日 リクルートテクノロジーズ 仲江 健一
2. 2 自己紹介 ▪経歴 2000年〜 独立系SIer 2012年〜 リクルートジョブズ入社  事業開発室（開発ディレクション、商品企画）  ITサービスマネジメントグループGM（2015年10月〜） 2017年〜 リクルートテクノロジーズ出向  SRE部 RJBグループGM（〜2018年9月）  SOE部 インフラディレクショングループGM（〜2019年3月）  SOE部 ライフイベント領域サーマネグループGM（2019年4月〜） 2019年〜 リクルート住まいカンパニー出向  NB統括本部 DDU インフラアーキグループGM（2019年4月〜） 仲江 健一 株式会社リクルートテクノロジーズ ITインテグレーション本部 サービスオペレーションエンジニアリング部 ライフイベント領域サーマネグループ
3. リクルートのご紹介
4. 4 リクルートグループについて 創業 1960年3月31日 「大学新聞広告社」としてスタート グループ 従業員数 45,856名 （2019年3月31日時点） 連結売上高 23,107億円 （2018年4月1日〜2019年3月31日） 連結営業利益 2,230億円 （2018年4月1日〜2019年3月31日） グループ 企業数 344社 （子会社および関連会社、2019年3月31日時点） 目指す世界観 「あなた」を支える存在でありたい
5. 5 リクルートの事業内容 選択・意思決定を支援する情報サービスを提供 ライフイベント領域 進学 就職 結婚 転職 住宅購入 車購入 出産/育児 旅行 ビジネス支援 生活/地域情報 グルメ・美容 ライフスタイル領域
6. 6 ビジネスモデル リクルートには、ユーザーとクライアントという2つのお客様が存在します。 企業と人（B to C）、企業と企業（B to B）、人と人（C to C）、すべての間に立ち、 双方にとって最適なマッチングを図る「場」を提供しています。 ユーザーとクライアントを新しい接点で結び、 「まだ、ここにない、出会い。」の場を創造する。
7. 7 IR資料：「メディア＆ソリューション事業のご紹介」より抜粋 ビジネス領域の拡大を推進中
8. 8 リクルートテクノロジーズについて リクルートグループのIT・ネットマーケティング領域のテクノロジー開発を担う会社です。 リクルート ホールディングス リクルートキャリア リクルート住まいカンパニー リクルートライフスタイル リクルートジョブズ リクルートマーケティングパートナーズ リクルートテクノロジーズ リクルートスタッフィング スタッフサービス・ホールディングス リクルートコミュニケーションズ メディア & ソリューション事業 （株）リクルート 人材派遣事業 Recruit Global Staffing B.V. HRテクノロジ― 事業 RGF OHR USA, Inc. その他海外派遣グループ会社 Indeed,Inc.
9. 9 リクルートテクノロジーズについて 企画統括本部 ITマネジメント販促領域本部 リクルートテクノロジーズ ITソリューション本部 プロダクトデザイン本部 経営企画、広報、経理/人事/総務などのコーポレート スタッフ機能。先端技術の研究開発部門（ATL）も配置 リクルートグループ共通の社内システムやインフラ、 セキュリティ関連ソリューションの企画・開発・運用 ITインテグレーション本部 ビジネス検討、UI/UXのデザイン、デザインマネジメン トの推進 ITエンジニアリング本部 各事業領域におけるプロダクトの開発（内製開発を含 む）、横断でのAP基盤の開発・運用 ICTソリューション本部 ITマネジメントHR領域本部 HR領域の事業と一体となり、開発ディレクションや開発 マネジメントを通じて日々のシステム改善を推進 販促領域の事業と一体となり、開発ディレクションや 開発マネジメントを通じて日々のシステム改善を推進 大規模開発やオフショア開発ソリューション、データ利 活用・ネットインフラも含む統合ソリューションの提供 リクルート内外のデータを活用したアドテクノロジーソ リューションの開発・運用
10. 本日お話させていただくこと
11. 11 インフラ運用部隊が サービスマネジメント組織に進化し ビジネス成長に貢献するまで
12. 12 サービスマネジメント組織立ち上げの背景 品質マネジメント機能の強化を目的に専門組織を組閣  次から次へと品質問題が顕在化  ビジネス成長のための活動時間が減っていく・・・
13. 13 サーマネ組織への期待値 インフラ アプリ サービス サービス基盤の維持運用 基盤レイヤーから横断で品質をマネジメントし 「安定稼働」を実現する 横断ガバナンス サーマネ マッチング プラット フォーム 業務支援 ソリュー ション R＆D
14. 14 サービス提供価値を最大化するための条件 価値創出 ＆ 磨き込み サービスの 安定供給 両者のバランスが取れている状態 選ばれ続けるサービスの実現
15. 15 安定稼働を牽引することで成長のための時間を最大化する サーマネ組織のミッション
16. 16 マネジメントスコープ サービス アプリ インフラ 顧客 ネットビジネス イ ン フ ラ マ ネ ジ メ ン ト シ ス テ ム マ ネ ジ メ ン ト サ ー ビ ス マ ネ ジ メ ン ト 真のサービスマネジメント実現に必要な視界
17. 17 乗り越えなくてはならない壁 第１の壁 己を知る 第２の壁 開発 と 運用 第３の壁 IT組織 と Biz組織 持ち場意識を前提とした「思考の壁」は高い 「組織の壁」を乗り越えることでブレイクスルーを起こす インフラ視点 システム視点 サービス視点
18. 第一の壁（己を知る）
19. 19 インフラ運用組織の日常 業務の目的は？ 構築と保守 サービス維持 障害対応 要件通りに 正しく作る ＜モニタリング＞ トラブルの 予兆/発生の検知 迅速な復旧
20. 20 目的は「サービス価値の最大化」 ビジネスゴール （組織ビジョンの達成） 共通の目標を達成するためのHOWが違うだけ 個人技（組織ミッション）＋パスワーク（相互連携）が必要 商品 開発 運用 マーケ 営業 KGI（重要目標達成指標） KPI（重要業績評価指標）
21. 21 我々は何者か？ プ ロ ダ ク ト ・ サ ー ビ ス の 進 化 プ ロ ダ ク ト ・ サ ー ビ ス の 安 定 稼 働 オフェンス （開発） ディフェンス （運用）  新たな価値を生み出す  生み出した価値の維持  安定性＆効率性の追求 サーマネ 「運用」という立場からどう業績に貢献するか？
22. 22 目指す姿とミッション・バリューを言語化 減点方式の 仕事から脱却！！ 安定稼働実現を リードすることで 業績へ貢献する
23. 23 ITサービスマネジメントとは？ 顧客のニーズに合致した 適切なITサービスを提供する マネジメント活動全般のこと 引用元：Wikipedia
24. 24 ITILを正しく解釈する  誤ったスコープ インフラのみに閉じた視界で検討が進行  手段が目的化 ITILプロセスの白地を埋めることがゴール  何のためのサービスレベル定義？ ビジネス成長に寄与しない”保身のためのSLA” 「ビジネス価値の最大化」を目的とした マネジメントプロセス構築でなければならない
25. 25 ITILを正しく解釈する フレームワークはあくまで参考書 自組織に適した形でチューニングすることで効果を発揮 ＜遂行機能＞ サービス運用 サービスレベル （品質担保ラインの定義） 障害 ガバナンス ＜統制機能＞ ガバナンス方針 セキュリティ ガバナンス IT戦略立案 （非商品） インシデント/ 問題管理 構成管理 財務管理/ EOSL管理・・ 変更/リリース管理 性能管理 サービス 安定稼働 業務 機能 セキュリ ティ管理 ＜活動コンポーネント＞ ２機能、10業務にてサービス継続性を担保する
26. 26 インフラ アプリ 統制 サーマネ セキュリティ 管理 障害管理 IT戦略立案 （非商品系） 遂行 他組織 サービス 運用 サービスレベル 管理 現在地を認識し、登る山を明確にする 「コアの磨き込み」と「運用統合＆統制機能を装着」し サービスの安定稼働を牽引する存在になる 磨き込み 獲得 役割が明確になり 目指すゴールの 認識が揃った
27. 第二の壁（開発組織と運用組織） 第三の壁（ビジネス組織とIT組織）
28. 28 第１の壁は突破できたが・・ 商品企画 （サービス） IT組織 開発 （アプリ） 運用 （インフラ） Biz組織 第 ２ の 壁 第 ３ の 壁 ビジネスとしての機動力はまだまだ低い 組織間の連携不足 によるムダ あいまいな期待値に 応えるためのムダ
29. 29 第2の壁の補足（開発組織と運用組織) 開発 （アプリ） 運用 （インフラ） A商品 B商品 C商品 D商品 E商品 縦割り意識が生み出す非効率とナレッジの分散・・ 障害検知＆復旧までのリードタイムが伸びる構造 ＜ムダ②＞開発チーム間の連携不足 ＜ムダ①＞アプリ/インフラ運用の連携不足
30. 30 第3の壁補足（ビジネス組織とIT組織） ビ ジ ネ ス 組 織 組 織 I T 保身のために過剰なバッファを積まざるを得ない 結果、新たな価値を創出するための活動時間が減少  いつまでも言語化されない期待品質  ミスには厳しいコミュニケーション
31. 31 打ち手 商品企画 （サービス） IT組織 開発 （アプリ） 運用 （インフラ） Biz組織 第 ２ の 壁 第 ３ の 壁 第３の壁 期 待 値 を 揃 え る た め の ル ー ル 整 備 ア プ リ と イ ン フ ラ が 一 体 化 し た 運 用 体 制 の 構 築 第２の壁 ア プ リ と イ ン フ ラ が 一 体 化 し た 運 用 体 制 の 構 築 第２の壁
32. 32 過剰品質を生み出す仕組み 過剰な品質担保の仕組みが積み上がっていく構造 疲弊・・ 障害発生 ビジネス組織 IT組織 再発防止要求 調査報告 こら！ 大量の チェックシート 過剰な レビュープロセス リソースは有限
33. 33 【障害レベル定義】事象の重み付けを行う 深刻度に応じて対応レベルに濃淡をつけることで リソースを適切に配分する プロダクト影響有 プロダクト影響無 大規模 小規模 大規模 小規模 4 ◎ ― ― ― 3 ― ◎ ― ― 2 ― ― ◎ ― 1 ― ― ― ◎ レベル 種別 大 小  ４段階に事象を格付け  暫定対応は即時、L３以上は３ヶ月以内に恒久/再発防止策 深刻度
34. 34 【重要機能定義】守るべきものを具体的に定める 全国トップ 応募画面 主要検索軸の品質担保はマスト 求人情報一覧 求人情報詳細 エリアトップ 例）検索機能 ※上記以外にも、定めた基準に該当する検索軸を重要機能として運用しています
35. 35 【運用体制】マネジメント機能を設置する 疑わしきは全て報告する文化の醸成とログの集中管理 LV3 対応指示 報告 障害検知 障害管理チーム 障害管理DB 蓄 積
36. 36 横のつながりが強化されることで 障害対応をスムーズに行うためのアイデアが湧き出る 横断障害発生時は情報が錯綜 するので旗振り役が欲しい アプリインフラ間のリリース 計画ってお互いにしらないね モニタリングツールがバラバ ラだから会話レベルを合わせ るのが大変・・ 縦割り意識が緩和されることで起こる変化 障害時の調査を効率的に行う 仕組みが必要！ やろう！
37. 37 打ち手 商品企画 （サービス） IT組織 開発 （アプリ） 運用 （インフラ） Biz組織 第 ２ の 壁 第 ３ の 壁 第３の壁 期 待 値 を 揃 え る た め の ル ー ル 整 備 ア プ リ と イ ン フ ラ が 一 体 化 し た 運 用 体 制 の 構 築 第２の壁 第３の壁 期 待 値 を 揃 え る た め の ル ー ル 整 備
38. 38 【第２の壁】レイヤーの垣根を超えた日常的な融合の実現 People Process Product (人/組織) (プロセス) (ツール/基盤) 共通言語で語るためのツール整備と運用プロセスの構築
39. 39 即時検知→迅速な復旧を支えるツールを共通化 監視ツール ログ調査ツール Product （ツール/基盤）
40. 40 DATADOG：監視ツールの共通化 アプリ/インフラ双方がリソース状況を意識することで 異常シグナルの検知スピードが向上 Product （ツール/基盤）
41. 41 Kibana：ログ調査基盤の統一 有識者に頼った属人的な調査からの脱却 →迅速な原因の特定 Product （ツール/基盤）
42. 42 イベントの相互共有 Process （プロセス） 双方のリリースイベントを把握することで、 需要予測に基づく適切なインフラ拡張を実施できるように
43. 43 アプリとインフラが日常的にトラブルを共有議論する場 サーマネ 問題管理委員会 Process （プロセス） 組織横断で対応レベルの底上げを実現 活 用 蓄 積 対応ナレッジ インフラ チーム 全アプリ チーム 横 展 開 横 断 統 制
44. 44 品質状況の可視化 障害発生件数 障害発生区分 検知所要時間 復旧所要時間 障害混入時期 検知から復旧までのスピードと開発品質を可視化 ネクストアクションにつなげてもらう
45. 45 障害はゼロにはできない IT組織 原因究明と対処 大規模障害 経営ボード 内部統制 ビジネス組織 お客様対応検討 情報とりまとめ あらかじめ判断基準を定めておくことと 経営への定期的な品質レポーティングの重要性は高い ビジネス組織 お客様対応検討
46. あらためて・・ 第三の壁（ビジネス組織とIT組織）
47. 47 「DevOps」に閉じたサービスマネジメントの限界  大規模障害発生時は、開発組織外で多くの意思決定が発生  ブレない判断基準と意思決定スピードが重要 誠意ある対応を行うためにはガイドライン整備が有効
48. 48 トラブル対応ガイドラインの整備  お客様への対応判断が商品責任者に集中  数々の意思決定ロジックを言語化 属人性を緩和することで 「個人」ではなく「組織」で動けるようにする
49. 49 アクションの明確化 影響度 継続時間 Cランク 影響度と継続時間に応じて 「いつ」「何をするか」を決めておく Bランク Aランク Sランク
50. 50 正しい経営判断の起点になる 経営モニタリング  品質状況の把握と要因分析  しかるべき改善計画の報告 品質改善施策 サービスレベル 改善 安定している運用こそ形骸化していないかを疑い 意味を問い続けることが重要 サービスレベル 改善
51. 51 ビジネスゴールを見据えて Biz × Dev × Ops が一体化 全体を俯瞰して自分の役割を解釈し 組織として本質的な活動を実現していく
52. 成果
53. 53 全社一体運営による成果 ＜障害対応時間＞ 2014年 2018年 ピーク時の 1/10 まで減少 障害時間減 ＝ 価値向上時間の創出
54. 54 安定稼働が生み出す波及効果① スループット改善が大幅に進行 回帰試験 自動化 １回あたりリリース工数 １/2  開発組織内の業務割合が大きく変化 （改善時間：20%→60％）
55. 55 安定稼働が生み出す波及効果②  後手後手になりがちな「リスク対応」 Before After 確定デッド ライン 変動デッド ライン 不明デッド ライン 期限が迫ってる ので急がねば！ デッドラインを３つに分類しリスクを管理 計画的に組織全体でリスクに向き合う デッドライン マネジメント
56. 56 仕事の報酬は「仕事」 得意分野ごとに分業することで 事業運営上のセキュリティリスクをマネジメント システムセキュリティ （サーマネ） オフィスセキュリティ （内部統制） 全社セキュリティ支援チーム
57. まとめ
58. 58 まとめ 安定運用は1日にしてならず （根気強くコツコツ積み上げることが大事） 問題（障害）を機会（チャンス）と捉える （鉄は熱いうちに打つ。線を引かずにやるべきことをやる。） BizDevOpsの視点がサービスマネジメントを強くする （徹底的なサービス視点で横断的な課題解決を推進）
59. 59 商品企画 アプリ ユーザー インフラ サーマネ 「クリエイティブ」＆「エキサイティング」な仕事 サービスマネジメントという仕事の醍醐味
60. 60 あ リクルートテクノロジーズ 検索 一緒にサービスマネジメント活動を行なってくれる仲間を募集中です！
61. 61 あ ご静聴ありがとうございました