Movatterモバイル変換

[0]ホーム
URL:

PDF, PPTX9,826 views

経営のアジリティを支えるDevOpsと組織

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

Embed presentation

Download as PDF, PPTX
2015/7/30経営のアジリティを支えるDevOpsと組織リクルートテクノロジーズ志田 一茂
Page 2 Page 2自己紹介志田 一茂株式会社リクルートテクノロジーズITマネジメント部 執行役員①2006年～2010年SierからリクルートのIT部門へ転職。新規Webサービスのアジャイル開発の推進を担当。②2011年～ 2012年スマートデバイスアプリ(iOS, Android)のアジャイル開発/運用組織の立ち上げ。全社のスマートデバイス戦略を担当。③2013年～執行役員担当事業会社のIT戦略の立案・推進を担当④2014年～主要サービスでのビジネス高速化に向けDevOps推進組織を立ち上げ中。
Page 3 Page 3Agenda1. リクルート会社概要3. 短期スピードを求めたAgile開発事例4. エンタープライズ領域でのDevOps実現の事例5. ITがビジネスを牽引する為に2. リクルートのビジネスとIT活用
Page 4 Page 4リクルート会社概要創立 1960年「大学新聞広告社」としてスタートグループ従業員数31,841名連結売上高 約12,999億連結経常利益 1,256億グループ企業数162社(国内＋海外)リクルート事業紹介http://www.recruit.jp/company/about/data/※数値は２０１５年３月末時点
Page 5 Page 5リクルート会社概要2012年10月 新経営体制へ移行リクルート→5つの事業会社+3つの機能会社へ
Page 6 Page 6リクルート会社概要リクルートグループ各社の現在・将来のニーズを見据えて競合優位性の高いIT・ネットマーケティング基盤を開拓、ビジネス実装することによりリクルートグループの競争優位を構築していく。IT・ネットマーケティング領域の専門部隊。リクルートグループをITで牽引する企業ですリクルートテクノロジーズのミッション
Page 7 Page 7リクルート会社概要リクルートグループ各サービスリクルートテクノロジーズビジネス視点のITマネジメントサービス開発部隊サーバーセキュリティ社内インフラサービスインフラ基盤ビッグデータ次世代 R&D大規模プロジェクト推進共通基幹システムソリューション別専門部隊ビジネスニーズ×ソリューションリクルートテクノロジーズの組織サービス開発部隊×ソリューション別専門部隊
Page 8 Page 8Agenda1. リクルート会社概要3. 短期スピードを求めたAgile開発事例4. エンタープライズ領域でのDevOps実現の事例2. リクルートのビジネスとIT活用5. ITがビジネスを牽引する為に
Page 9 Page 9リクルートのIT活用～’90年代S/W As a System高品質WaterfallITBusinessITBusinessITBusiness～’00年代S/W As a Service短納期/低コストAgileOffshore‘10年代S/W As a BusinessビジネスバリューLean StartupDevOpsソフトウェア-ビジネスの相関とプロセスの変遷
Page 10 Page 10リクルートのIT活用～’90年代S/W As a System高品質Waterfall～’00年代S/W As a Service短納期/低コストAgileOffshore‘10年代S/W As a BusinessビジネスバリューLean StartupDevOps【紙の時代】本誌制作を支える手段としてのIT活用【Netシフトの時代】Net商品でのマネタイズを支える手段としてのIT活用【ITが源泉の時代】ITがビジネス創出のコアコンピタンスへリクルートのプロダクト変遷とIT活用の変化
Page 11 Page 11リクルート会社概要http://www.recruit.jp/company/about/data/多岐にまたがる事業領域あらゆる領域の"不"を解消する
Page 12 Page 12リクルート会社概要350200267スマホアプリの主要ブランド数ネットサービスの主要ブランド数「紙」のブランド数（市販誌、無代誌、ムック）出典:日経ビジネス 2014/04/07号リクルートグループのブランド(サービス数)
Page 13 Page 13Agenda1. リクルート会社概要3. 短期スピードを求めたAgile開発事例4. エンタープライズ領域でのDevOps実現の事例2. リクルートのビジネスとIT活用5. ITがビジネスを牽引する為に
Page 14 Page 14リクルートのIT活用～’90年代S/W As a System高品質WaterfallITBusinessITBusinessITBusiness～’00年代S/W As a Service短納期/低コストAgileOffshore‘10年代S/W As a BusinessビジネスバリューLean StartupDevOpsソフトウェア-ビジネスの相関とプロセスの変遷
Page 15 Page 15アジャイル適用の背景リリース直後から最大の効果を生むビジネス→ 品質重視のシステム開発情報誌Agile適用の検討へ差別化機能もスグに競合に模倣される参入障壁の低下競合より早くリリースする事がビジネス価値→ 短納期重視のシステム開発Net急速なNetシフトに伴う開発を取り巻く環境変化
Page 16 Page 16リクルート会社概要http://www.slideshare.net/devsumi2009/12a525詳細はデブサミ2009の事例紹介参照独自Agile開発スキーム “SWAT” 構築
Page 17 Page 17SWATのサマリプロセス新サービス短納期立上げに特化した独自のAgileスキームを構築組織/体制開発部門のみ専門組織化社員PM＋外部エンジニア常駐基盤 アプリケーション開発のみ標準化構築実績2006年～2008年の３年弱新規25サービスの構築平均納期1サービスの開発期間は平均して約3～4か月生産性開発生産性(FP計測ベース)で約40～50FP/人月ゴール：初期リリースまでの納期短縮と、当時は一定の成果を生み出すもその後、3つの大きな課題に直面！
Page 18 Page 18リクルートにおけるAgile開発SWAT2.0説明資料@2008 FITシステム基盤推進室 ASG2006年1月短納期FSソリューション“Rapid”2007年4月SWATの正式ソリューション化“SWAT1.0”リリース2008年10月SWATのバージョンUP“SWAT2.0”リリース① 独自Agile開発スキームの継続運営・展開課題☑ 最初はライトなルールが徐々に複雑化。覚えられない…
Page 19 Page 19SWATで顕在化した課題ビジネス 開発 運用Slow Quick Slow効果的なビジネス施策を継続的に短サイクルで打ち出せない。品質担保の観点、アーキテクチュア制約、インフラ制約などで素早くリリース出来ない。☑ リリース後のエンハンス開発フェーズにおいて、短サイクルで効果的な企画出し、高速な運用が困難に② 立ち上げ後にWater-Scrum-Fallに陥る課題ビジネス企画サービス企画システム開発システム運用
Page 20 Page 20SWATで顕在化した課題☑ ビジネスの拡大と共に体制拡大/高まる品質要求に対して独自Agileスキームが限界→W/Fモデルでスピードを失う成長 成熟 再成長/衰退新規Agile開発小規模/シンプル一体型/少人数納期③ 組織体制の物理スケール対応の課題大規模/複雑分業型/大人数品質W/F開発
Page 21 Page 21Agenda1. リクルート会社概要3. 短期スピードを求めたAgile開発事例4. エンタープライズ領域でのDevOps実現の事例2. リクルートのビジネスとIT活用5. ITがビジネスを牽引する為に
Page 22 Page 22リクルートのIT活用～’90年代S/W As a System高品質WaterfallITBusinessITBusinessITBusiness～’00年代S/W As a Service短納期/低コストAgileOffshore‘10年代S/W As a BusinessビジネスバリューLean StartupDevOpsソフトウェア-ビジネスの相関とプロセスの変遷
Page 23 Page 23エンタープライズ領域への挑戦☑ 新規サービスでAgile導入は組織内で定着化した一方、収益源泉の主要サービスは大規模・分業のW/Fモデル成長 成熟 再成長/衰退新規Agile開発W/F開発小規模/シンプル 大規模/複雑一体型/少人数 分業型/大人数納期 品質エンタープライズ領域の開発再加速への挑戦再加速主要10数サービス200弱ビジネス収益を支えるトップブランド群将来のビジネス収益を得るための投資
Page 24 Page 24エンタープライズ領域への挑戦24ビジネス部門大規模プロダクトの組織分業構成と責務IT部門ビジネス企画サービス企画システム開発システム運用☑ ビジネス部門はKPI、IT部門はQCDに責務を負う分業構造中長期ビジネスKPI短期サービスKPI短期システムQCD中長期システムQCDアプリエンジニア インフラエンジニアプロデューサー ディレクター
Page 25 Page 25エンタープライズ領域への挑戦25ビジネス部門大規模プロダクトの企画～開発～運用プロセスIT部門ビジネス企画サービス企画システム開発システム運用☑ 機能間の連携で無駄は多いが安定するサイクル設計要件定義設計 製造 テストW/F ITIL
Page 26 Page 26エンタープライズ領域への挑戦26ビジネス部門長期の継続開発で徐々に蓄積する負がスピードを阻害IT部門ビジネス企画サービス企画システム開発システム運用☑ 相互の責務についての信頼がなければ改善は難しいアプリ密結合化データモデル複雑化パフォーマンス課題EOSLの対応施策の肥大化個別要件の多様化破壊的競合の台頭市場の不確実性遅い,高い,品質悪い！（怒！！！！）効果的な施策がない！だったら、やらない！
Page 27 Page 27エンタープライズ領域への挑戦混乱からの改善の道筋…重視した4つのポイントプロセス 一気通貫でのプロセスの構築組織/体制 所属を超えた一体型の体制の構築基盤 全体が効率化する環境/基盤の構築文化/風土 改革を進める風土・経営の覚悟☑ DevOpsではCAMSとCALMSSと定義され始めているが、下記を整合性を持って変革していく方針を立てた。
Page 28 Page 28サービス企画システム開発W/Fエンタープライズ領域への挑戦28全体最適の足掛かりにHUBとなる企画-開発のAgile開発化の実現に最初に着手ビジネス部門 IT部門ビジネス企画システム運用サービス開発Agile☑ 前述したSWATでのAgileノウハウを活用し多段構成を解消
Page 29 Page 29プロセス最適化参考URL：http://www.scrumalliance.org/certificationsまずベースとなる共通概念、体系的な理解促進☑ SWAT時の独自Agileの継続運用課題を反省を踏まえ、デファクト且つトレーニング体系の整ったScrumを適用
Page 30 Page 30エンタープライズ領域への挑戦ビジネス部門と一緒に相互理解の促進を図り一体感醸成
Page 31 Page 31サービス企画システム開発エンタープライズ領域への挑戦31ビジネス部門 IT部門ビジネス企画システム運用Scrumチーム各機能のメンバーをアサインしScrumチームを構成☑ 開発部門に閉じずビジネス部門のキーマンもアサイン
Page 32 Page 32エンタープライズ領域への挑戦32独立したScrumチームを編成し自己組織化を促すビジネス部門 運用部門ビジネス企画システム運用☑ 分離と共にScrumチームへ可能な限り権限を委譲ScrumチームPODevOps任せる！(気になるけど)信じてる(怖いけど)
Page 33 Page 33エンタープライズ領域への挑戦33必然的に前述したWater-Scrum-Fallの課題に対峙ビジネス部門 運用部門ビジネス企画システム運用サービス開発Scrum☑ 前後とのサイクルラグはScrumだけでは改善されない開発部門
Page 34 Page 34エンタープライズ領域への挑戦34最終的なゴールは全体スループットの向上ビジネス企画システム運用サービス開発☑ 各機能のサイクルスピードを同期しムダを無くす設計が必要
Page 35 Page 35エンタープライズ領域への挑戦35前後を接続するプロセス設計の検討ビジネス企画システム運用サービス開発☑ Scrumチームの課題に対して最適な解決方法論の選択Scrum
Page 36 Page 36エンタープライズ領域への挑戦36データドリブンの仮説検証型のビジネス企画へシフトビジネス企画システム運用サービス開発☑ 粒度の大きい案件の割に効果が出ない企画立案課題を解決LeanStartupScrum
Page 37 Page 37エンタープライズ領域への挑戦37ScrumSprint2Weeksビジネスと開発の接続設計の明確化とサイクル同期☑ 仮説検証型シフトで案件粒度が細分化しAgile適合度向上☑ まずA/Bテストを実施、結果を持って正式リリース
Page 38 Page 38エンタープライズ領域への挑戦38DevOpsをチームと運用部門の共通概念に設定ビジネス企画システム運用サービス開発☑ ScrumとITIL異なる改善サイクル差異をDevOpsで解決ScrumLeanStartup DevOps
Page 39 Page 39エンタープライズ領域への挑戦39Sprint2Weeks開発チームの改善が全体のITSMの推進に繋がる設計☑ スプリント毎に技術負債リストを作成・更新☑ 短期課題の改善目標を共通ミッションとして設定技術負債短期課題中長期課題組織戦略へScrum ITIL
Page 40 Page 40エンタープライズ領域への挑戦ITS/BTSツールSCMS/W構成管理CI継続的インテグレーションツールテスト環境サービス本番環境検品CD継続的デプロイメントツール継続的モニタリング基盤継続的コラボレーション基盤継続的デリバリー基盤コラボレーションツールScrumチームモニタリングダッシュボードチームが効率的に動く基盤を試行錯誤で構築中モニタリングツール
Page 41 Page 41エンタープライズ領域への挑戦41モニタリングダッシュボードA/Bテスト分析結果新機能UI/UX改善パフォーマンス改善企画立案PODevデータ分析Opsチームが情報をシェアするモニタリング基盤が効果大☑ 立場を超えて新企画立案や課題解決案が出る状態に
Page 42 Page 42エンタープライズ領域への挑戦42異なる方法論/概念を取り入れつつ全体最適をとったビジネス企画システム運用サービス開発☑ 自己組織化したScrumチームがボトムアップで課題を解決ScrumDevOpsLeanStartup
Page 43 Page 43エンタープライズ領域への挑戦43広義にDevOpsとはビジネス全体の加速を促す事ビジネス企画システム運用サービス開発☑ CI環境、リリースの自動化などに目が行きがちだが組織のアクティビティ全体への貢献に高い価値を生み出すDevOps
Page 44 Page 44DevOps推進のサマリ開発プロセス共通言語しやすいScrumを基軸にDevOps/LeanStartupの概念と接続組織/体制開発部門内部に閉じず、関連する部門を巻き込み組織再編成基盤アプリ×インフラ基盤チームを支える業務基盤構築実績 主要2サービスで一年実施中リリースサイクル2週間スプリントを継続し安定・向上現在は部分的に1週間スプリントビジネス貢献投入人月ベースでは純減で、ビジネスKPI/SLA目標を達成ゴール：サービスの継続的成長をITでリードする
Page 45 Page 45Agenda1. リクルート会社概要3. 短期スピードを求めたAgile開発事例4. エンタープライズ領域でのDevOps実現の事例2. リクルートのビジネスとIT活用5. ITがビジネスを牽引する為に
Page 46 Page 46変革を進める上でのスタンス目的と手段を混合しない“XXXX”は手段であり、目的ではない。IT課題を把握・改善提案できるのはIT部門のみ。愚痴るな、声に出して問題提起・改善提案しろ。目先の目標ではなく、中長期の目標達成を優先する。残業するなパワープレーの対応は将来の負債を増やすだけ。何かを変えるアクションには必ずネガティブな意見は出る。信念を持って、粘り強く推進する覚悟と努力が必要。IT部門のマネージャとして心掛けている事（＝日々、部下に言っている小言）
Page 47 Page 47経営層の意識改革集客 営業商品企画システム開発増員クライアント企業増員カスタマー広告費増額IT投資を増員では無く、自己組織化、クロスファンクション化の推進投資へ☑ 開発において体制拡大はスピードダウンの元凶になる
Page 48 Page 48経営層の意識改革FixedParameterVariableParameterScopeTime Resource従来の概念 転換後の概念TimeScopeResourceIT部門はマネジメントパラメータの転換を行う☑ 体制とリリースサイクルを固定化し、チームの習熟に伴いアウトプットが徐々に増えるという考えにシフト。
Page 49 Page 49経営層の意識改革従来の開発検証型の開発ビジネス価値時間案件ビジネス価値時間検証 検証 検証 検証・市場への早期リリース・確実なROIと投資抑制経営がプロセス差異を理解し使い分ける・ 想定するビジネス価値の過大評価・ デリバリ制約
Page 50 Page 50経営層の意識改革☑ 企画立案～リリースまでのリードタイムを圧縮する必要ビジネス部門が要する時間IT部門が要する時間ビジネス部門が要する時間IT部門が要する時間ビジネス部門が要する時間IT部門が要する時間IT部門内に閉じた施策では期間短縮は限定的☑ 経営の合意を持ってビジネス部門と連携して全体最適
Page 51 Page 51密結合経年劣化したアーキテクチュアアーキテクチュアマネジメント☑ 経年劣化した大規模システムは部分切り出しつつアジャイル化システムCシステムBシステムA次世代アーキテクチュア密結合経年劣化したアーキテクチュアシステムCシステムBシステムA密結合経年劣化したアーキテクチュア次世代アーキテクチュアシステムCシステムBシステムB肥大化・密結合化したシステムでAgile開発は困難ビジネス優先度の高いサブシステムを切り出し刷新
Page 52 Page 52アーキテクチャ指針の転換サイトA サイトBソースコード ソースコードサイトA サイトBソースコード ソースコードソースコード（共通部分）従来 アジャイル開発チーム 開発Aチーム 開発Bチーム☑ アーキテクトとして推奨される共通化が逆に足枷になるケースもシステム屋都合の共通化はアジャイルの妨げになる
Page 53 Page 53組織・体制の整備☑ 組織の距離を縮める＝組織変更 or プロジェクト化部門間調整の無駄、重複検討タスクの無駄・・・マネジメントライン複数化による承認プロセスの無駄インタラクティブな企画・要件検討を推進する。認識合わせの為のムダな中間成果物作成の時間を無くす。☑ 物理的な距離も縮める＝ワンロケーション可能な限りセクショナリズムを排除する
Page 54 Page 54さいごにご清聴ありがとう御座いましたSpeed for Enterprise～デベロッパーがエンジンとなって企業ビジネスを加速させていきましょう～

Recommended

PDF
心理的安全性を 0から80ぐらいに上げた話
PDF
ビジネスパーソンのためのDX入門講座エッセンス版
PPTX
DXとかDevOpsとかのなんかいい感じのやつ　富士通TechLive
PPTX
オーバーエンジニアリングって何？ #devsumi #devsumiA
PDF
フロー効率性とリソース効率性、再入門 #devlove #devkan
PDF
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
PDF
「顧客の声を聞かない」とはどういうことか
PDF
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
PDF
ユーザーインタビューするときは、どうやらゾンビのおでましさ
PDF
Design Sprint と Lean UX: 顧客からの学び方
PDF
ChatGPTの ビジネス活用とセキュリティ
PDF
Design Sprint Process / デザインスプリントの実際のプロセスについて
PDF
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
PDF
ピッチをする前に知っておきたかったこと　スタートアップの資金調達
PDF
チケット駆動開発の解説～タスク管理からプロセス改善へ
PDF
大企業アジャイルの勘所 #devlovex #devlovexd
PPTX
心理的安全性と、Veinの紹介　Psychological safety and introduction of Vein
PDF
マイクロにしすぎた結果がこれだよ！
PDF
今なら間に合う分散型IDとEntra Verified ID
PDF
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
PDF
アジャイルな見積りと計画づくり勉強会
PPTX
アジャイルメトリクス実践ガイド
PDF
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
PDF
TDD のこころ
PDF
トップエンジニアが実践する思考整理法～テクニカルライティングを用いた課題解決の基本
PDF
メトリクスによるソフトウェア品質把握と改善－ 演習を交えた品質測定評価の落とし穴とコツの習得 －
PDF
セールスアニマルになろう　スタートアップ初期の営業戦略
PPTX
緊急Ques - コードのメトリクスに基づくリファクタリング戦略
PDF
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
PDF
20171129 01 講演資料_チームレベル agile からエンタープライズ dev_ops へ

More Related Content

PDF
心理的安全性を 0から80ぐらいに上げた話
PDF
ビジネスパーソンのためのDX入門講座エッセンス版
PPTX
DXとかDevOpsとかのなんかいい感じのやつ　富士通TechLive
PPTX
オーバーエンジニアリングって何？ #devsumi #devsumiA
PDF
フロー効率性とリソース効率性、再入門 #devlove #devkan
PDF
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
PDF
「顧客の声を聞かない」とはどういうことか
PDF
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
心理的安全性を 0から80ぐらいに上げた話
ビジネスパーソンのためのDX入門講座エッセンス版
DXとかDevOpsとかのなんかいい感じのやつ　富士通TechLive
オーバーエンジニアリングって何？ #devsumi #devsumiA
フロー効率性とリソース効率性、再入門 #devlove #devkan
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
「顧客の声を聞かない」とはどういうことか
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic

What's hot

PDF
ユーザーインタビューするときは、どうやらゾンビのおでましさ
PDF
Design Sprint と Lean UX: 顧客からの学び方
PDF
ChatGPTの ビジネス活用とセキュリティ
PDF
Design Sprint Process / デザインスプリントの実際のプロセスについて
PDF
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
PDF
ピッチをする前に知っておきたかったこと　スタートアップの資金調達
PDF
チケット駆動開発の解説～タスク管理からプロセス改善へ
PDF
大企業アジャイルの勘所 #devlovex #devlovexd
PPTX
心理的安全性と、Veinの紹介　Psychological safety and introduction of Vein
PDF
マイクロにしすぎた結果がこれだよ！
PDF
今なら間に合う分散型IDとEntra Verified ID
PDF
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
PDF
アジャイルな見積りと計画づくり勉強会
PPTX
アジャイルメトリクス実践ガイド
PDF
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
PDF
TDD のこころ
PDF
トップエンジニアが実践する思考整理法～テクニカルライティングを用いた課題解決の基本
PDF
メトリクスによるソフトウェア品質把握と改善－ 演習を交えた品質測定評価の落とし穴とコツの習得 －
PDF
セールスアニマルになろう　スタートアップ初期の営業戦略
PPTX
緊急Ques - コードのメトリクスに基づくリファクタリング戦略
ユーザーインタビューするときは、どうやらゾンビのおでましさ
Design Sprint と Lean UX: 顧客からの学び方
ChatGPTの ビジネス活用とセキュリティ
Design Sprint Process / デザインスプリントの実際のプロセスについて
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
ピッチをする前に知っておきたかったこと　スタートアップの資金調達
チケット駆動開発の解説～タスク管理からプロセス改善へ
大企業アジャイルの勘所 #devlovex #devlovexd
心理的安全性と、Veinの紹介　Psychological safety and introduction of Vein
マイクロにしすぎた結果がこれだよ！
今なら間に合う分散型IDとEntra Verified ID
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
アジャイルな見積りと計画づくり勉強会
アジャイルメトリクス実践ガイド
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
TDD のこころ
トップエンジニアが実践する思考整理法～テクニカルライティングを用いた課題解決の基本
メトリクスによるソフトウェア品質把握と改善－ 演習を交えた品質測定評価の落とし穴とコツの習得 －
セールスアニマルになろう　スタートアップ初期の営業戦略
緊急Ques - コードのメトリクスに基づくリファクタリング戦略

Similar to 経営のアジリティを支えるDevOpsと組織

PDF
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
PDF
20171129 01 講演資料_チームレベル agile からエンタープライズ dev_ops へ
PDF
xOps: エンジニアがスタートアップの成長の原動力となる日
PDF
Developer Summit Summer 2013 C1セッション CA Technologies
 
PDF
[db tech showcase Tokyo 2018]　#dbts2018 #A11 『システム開発によろこびと驚きの連鎖を』
PDF
企業組織論としてのオープンイノベーション
PPT
110518＿本気で考える！ I T人財育成研究部会 討議資料
PDF
ビジネスデザインにおけるモデルの発展的活用＜価値創造モデルとは＞
PDF
Ci&T Anti-Software Factory Pattern
PPTX
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
PDF
Itエンジニアとして身に付けるべきビジネス＆プロジェクト・デザイン
PPTX
上司が信用できない会社の内部統制～第32回WebSig会議「便利さと、怖さと、心強さと〜戦う会社のための社内セキュリティ 2013年のスタンダードとは？！...
PDF
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ～エンタープライズのDevOpsを加速させる運用改善Tips～
PDF
エンタープライズ、アーキテクチャ、アジャイルのこれから
PDF
【TFSUG】プロダクトオーナーシップ
PDF
「事業と一体化するシステム…」桑原里恵
PPTX
20240223中小民間労組交流集会講演資料（佐賀県産業労働部産業DX・スタートアップ推進グループ）
PDF
ｎｄｓと要求開発
PDF
20131213 itサービスに求められる人材像
PPTX
アジャイルジャパン2015 講演資料
 
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
20171129 01 講演資料_チームレベル agile からエンタープライズ dev_ops へ
xOps: エンジニアがスタートアップの成長の原動力となる日
Developer Summit Summer 2013 C1セッション CA Technologies
 
[db tech showcase Tokyo 2018]　#dbts2018 #A11 『システム開発によろこびと驚きの連鎖を』
企業組織論としてのオープンイノベーション
110518＿本気で考える！ I T人財育成研究部会 討議資料
ビジネスデザインにおけるモデルの発展的活用＜価値創造モデルとは＞
Ci&T Anti-Software Factory Pattern
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
Itエンジニアとして身に付けるべきビジネス＆プロジェクト・デザイン
上司が信用できない会社の内部統制～第32回WebSig会議「便利さと、怖さと、心強さと〜戦う会社のための社内セキュリティ 2013年のスタンダードとは？！...
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ～エンタープライズのDevOpsを加速させる運用改善Tips～
エンタープライズ、アーキテクチャ、アジャイルのこれから
【TFSUG】プロダクトオーナーシップ
「事業と一体化するシステム…」桑原里恵
20240223中小民間労組交流集会講演資料（佐賀県産業労働部産業DX・スタートアップ推進グループ）
ｎｄｓと要求開発
20131213 itサービスに求められる人材像
アジャイルジャパン2015 講演資料
 

More from Recruit Technologies

PDF
新卒2年目が鍛えられたコードレビュー道場
PDF
カーセンサーで深層学習を使ってUX改善を行った事例とそこからの学び
PDF
Rancherを活用した開発事例の紹介　～Rancherのメリットと辛いところ～
PDF
Tableau活用4年の軌跡
PDF
HadoopをBQにマイグレしようとしてる話
PDF
LT（自由）
PDF
リクルートグループの現場事例から見る　AI/ディープラーニング ビジネス活用の勘所
PDF
Company Recommendation for New Graduates via Implicit Feedback Multiple Matri...
PDF
リクルート式AIの活用法
PDF
銀行ロビーアシスタント
PDF
リクルートにおけるマルチモーダル Deep Learning Web API 開発事例
PDF
ユーザー企業内製CSIRTにおける対応のポイント
PDF
ユーザーからみたre:Inventのこれまでと今後
PDF
Struggling with BIGDATA　－リクルートおけるデータサイエンス/エンジニアリング－
PDF
EMRでスポットインスタンスの自動入札ツールを作成する
PDF
RANCHERを使ったDev(Ops)
PDF
リクルートにおけるセキュリティ施策方針とCSIRT組織運営のポイント
PDF
ユーザー企業内製CSIRTにおける対応のポイント
PDF
リクルートテクノロジーズが語る 企業における、「AI／ディープラーニング」活用のリアル
PDF
「リクルートデータセット」 ～公開までの道のりとこれから～
新卒2年目が鍛えられたコードレビュー道場
カーセンサーで深層学習を使ってUX改善を行った事例とそこからの学び
Rancherを活用した開発事例の紹介　～Rancherのメリットと辛いところ～
Tableau活用4年の軌跡
HadoopをBQにマイグレしようとしてる話
LT（自由）
リクルートグループの現場事例から見る　AI/ディープラーニング ビジネス活用の勘所
Company Recommendation for New Graduates via Implicit Feedback Multiple Matri...
リクルート式AIの活用法
銀行ロビーアシスタント
リクルートにおけるマルチモーダル Deep Learning Web API 開発事例
ユーザー企業内製CSIRTにおける対応のポイント
ユーザーからみたre:Inventのこれまでと今後
Struggling with BIGDATA　－リクルートおけるデータサイエンス/エンジニアリング－
EMRでスポットインスタンスの自動入札ツールを作成する
RANCHERを使ったDev(Ops)
リクルートにおけるセキュリティ施策方針とCSIRT組織運営のポイント
ユーザー企業内製CSIRTにおける対応のポイント
リクルートテクノロジーズが語る 企業における、「AI／ディープラーニング」活用のリアル
「リクルートデータセット」 ～公開までの道のりとこれから～

経営のアジリティを支えるDevOpsと組織

  • 1.
  • 2.
    Page 2 Page2自己紹介志田 一茂株式会社リクルートテクノロジーズITマネジメント部 執行役員①2006年～2010年SierからリクルートのIT部門へ転職。新規Webサービスのアジャイル開発の推進を担当。②2011年～ 2012年スマートデバイスアプリ(iOS, Android)のアジャイル開発/運用組織の立ち上げ。全社のスマートデバイス戦略を担当。③2013年～執行役員担当事業会社のIT戦略の立案・推進を担当④2014年～主要サービスでのビジネス高速化に向けDevOps推進組織を立ち上げ中。
  • 3.
    Page 3 Page3Agenda1. リクルート会社概要3. 短期スピードを求めたAgile開発事例4. エンタープライズ領域でのDevOps実現の事例5. ITがビジネスを牽引する為に2. リクルートのビジネスとIT活用
  • 4.
    Page 4 Page4リクルート会社概要創立 1960年「大学新聞広告社」としてスタートグループ従業員数31,841名連結売上高 約12,999億連結経常利益 1,256億グループ企業数162社(国内＋海外)リクルート事業紹介http://www.recruit.jp/company/about/data/※数値は２０１５年３月末時点
  • 5.
    Page 5 Page5リクルート会社概要2012年10月 新経営体制へ移行リクルート→5つの事業会社+3つの機能会社へ
  • 6.
    Page 6 Page6リクルート会社概要リクルートグループ各社の現在・将来のニーズを見据えて競合優位性の高いIT・ネットマーケティング基盤を開拓、ビジネス実装することによりリクルートグループの競争優位を構築していく。IT・ネットマーケティング領域の専門部隊。リクルートグループをITで牽引する企業ですリクルートテクノロジーズのミッション
  • 7.
    Page 7 Page7リクルート会社概要リクルートグループ各サービスリクルートテクノロジーズビジネス視点のITマネジメントサービス開発部隊サーバーセキュリティ社内インフラサービスインフラ基盤ビッグデータ次世代 R&D大規模プロジェクト推進共通基幹システムソリューション別専門部隊ビジネスニーズ×ソリューションリクルートテクノロジーズの組織サービス開発部隊×ソリューション別専門部隊
  • 8.
    Page 8 Page8Agenda1. リクルート会社概要3. 短期スピードを求めたAgile開発事例4. エンタープライズ領域でのDevOps実現の事例2. リクルートのビジネスとIT活用5. ITがビジネスを牽引する為に
  • 9.
    Page 9 Page9リクルートのIT活用～’90年代S/W As a System高品質WaterfallITBusinessITBusinessITBusiness～’00年代S/W As a Service短納期/低コストAgileOffshore‘10年代S/W As a BusinessビジネスバリューLean StartupDevOpsソフトウェア-ビジネスの相関とプロセスの変遷
  • 10.
    Page 10 Page10リクルートのIT活用～’90年代S/W As a System高品質Waterfall～’00年代S/W As a Service短納期/低コストAgileOffshore‘10年代S/W As a BusinessビジネスバリューLean StartupDevOps【紙の時代】本誌制作を支える手段としてのIT活用【Netシフトの時代】Net商品でのマネタイズを支える手段としてのIT活用【ITが源泉の時代】ITがビジネス創出のコアコンピタンスへリクルートのプロダクト変遷とIT活用の変化
  • 11.
    Page 11 Page11リクルート会社概要http://www.recruit.jp/company/about/data/多岐にまたがる事業領域あらゆる領域の"不"を解消する
  • 12.
    Page 12 Page12リクルート会社概要350200267スマホアプリの主要ブランド数ネットサービスの主要ブランド数「紙」のブランド数（市販誌、無代誌、ムック）出典:日経ビジネス 2014/04/07号リクルートグループのブランド(サービス数)
  • 13.
    Page 13 Page13Agenda1. リクルート会社概要3. 短期スピードを求めたAgile開発事例4. エンタープライズ領域でのDevOps実現の事例2. リクルートのビジネスとIT活用5. ITがビジネスを牽引する為に
  • 14.
    Page 14 Page14リクルートのIT活用～’90年代S/W As a System高品質WaterfallITBusinessITBusinessITBusiness～’00年代S/W As a Service短納期/低コストAgileOffshore‘10年代S/W As a BusinessビジネスバリューLean StartupDevOpsソフトウェア-ビジネスの相関とプロセスの変遷
  • 15.
    Page 15 Page15アジャイル適用の背景リリース直後から最大の効果を生むビジネス→ 品質重視のシステム開発情報誌Agile適用の検討へ差別化機能もスグに競合に模倣される参入障壁の低下競合より早くリリースする事がビジネス価値→ 短納期重視のシステム開発Net急速なNetシフトに伴う開発を取り巻く環境変化
  • 16.
    Page 16 Page16リクルート会社概要http://www.slideshare.net/devsumi2009/12a525詳細はデブサミ2009の事例紹介参照独自Agile開発スキーム “SWAT” 構築
  • 17.
    Page 17 Page17SWATのサマリプロセス新サービス短納期立上げに特化した独自のAgileスキームを構築組織/体制開発部門のみ専門組織化社員PM＋外部エンジニア常駐基盤 アプリケーション開発のみ標準化構築実績2006年～2008年の３年弱新規25サービスの構築平均納期1サービスの開発期間は平均して約3～4か月生産性開発生産性(FP計測ベース)で約40～50FP/人月ゴール：初期リリースまでの納期短縮と、当時は一定の成果を生み出すもその後、3つの大きな課題に直面！
  • 18.
    Page 18 Page18リクルートにおけるAgile開発SWAT2.0説明資料@2008 FITシステム基盤推進室 ASG2006年1月短納期FSソリューション“Rapid”2007年4月SWATの正式ソリューション化“SWAT1.0”リリース2008年10月SWATのバージョンUP“SWAT2.0”リリース① 独自Agile開発スキームの継続運営・展開課題☑ 最初はライトなルールが徐々に複雑化。覚えられない…
  • 19.
    Page 19 Page19SWATで顕在化した課題ビジネス 開発 運用Slow Quick Slow効果的なビジネス施策を継続的に短サイクルで打ち出せない。品質担保の観点、アーキテクチュア制約、インフラ制約などで素早くリリース出来ない。☑ リリース後のエンハンス開発フェーズにおいて、短サイクルで効果的な企画出し、高速な運用が困難に② 立ち上げ後にWater-Scrum-Fallに陥る課題ビジネス企画サービス企画システム開発システム運用
  • 20.
    Page 20 Page20SWATで顕在化した課題☑ ビジネスの拡大と共に体制拡大/高まる品質要求に対して独自Agileスキームが限界→W/Fモデルでスピードを失う成長 成熟 再成長/衰退新規Agile開発小規模/シンプル一体型/少人数納期③ 組織体制の物理スケール対応の課題大規模/複雑分業型/大人数品質W/F開発
  • 21.
    Page 21 Page21Agenda1. リクルート会社概要3. 短期スピードを求めたAgile開発事例4. エンタープライズ領域でのDevOps実現の事例2. リクルートのビジネスとIT活用5. ITがビジネスを牽引する為に
  • 22.
    Page 22 Page22リクルートのIT活用～’90年代S/W As a System高品質WaterfallITBusinessITBusinessITBusiness～’00年代S/W As a Service短納期/低コストAgileOffshore‘10年代S/W As a BusinessビジネスバリューLean StartupDevOpsソフトウェア-ビジネスの相関とプロセスの変遷
  • 23.
    Page 23 Page23エンタープライズ領域への挑戦☑ 新規サービスでAgile導入は組織内で定着化した一方、収益源泉の主要サービスは大規模・分業のW/Fモデル成長 成熟 再成長/衰退新規Agile開発W/F開発小規模/シンプル 大規模/複雑一体型/少人数 分業型/大人数納期 品質エンタープライズ領域の開発再加速への挑戦再加速主要10数サービス200弱ビジネス収益を支えるトップブランド群将来のビジネス収益を得るための投資
  • 24.
    Page 24 Page24エンタープライズ領域への挑戦24ビジネス部門大規模プロダクトの組織分業構成と責務IT部門ビジネス企画サービス企画システム開発システム運用☑ ビジネス部門はKPI、IT部門はQCDに責務を負う分業構造中長期ビジネスKPI短期サービスKPI短期システムQCD中長期システムQCDアプリエンジニア インフラエンジニアプロデューサー ディレクター
  • 25.
    Page 25 Page25エンタープライズ領域への挑戦25ビジネス部門大規模プロダクトの企画～開発～運用プロセスIT部門ビジネス企画サービス企画システム開発システム運用☑ 機能間の連携で無駄は多いが安定するサイクル設計要件定義設計 製造 テストW/F ITIL
  • 26.
    Page 26 Page26エンタープライズ領域への挑戦26ビジネス部門長期の継続開発で徐々に蓄積する負がスピードを阻害IT部門ビジネス企画サービス企画システム開発システム運用☑ 相互の責務についての信頼がなければ改善は難しいアプリ密結合化データモデル複雑化パフォーマンス課題EOSLの対応施策の肥大化個別要件の多様化破壊的競合の台頭市場の不確実性遅い,高い,品質悪い！（怒！！！！）効果的な施策がない！だったら、やらない！
  • 27.
    Page 27 Page27エンタープライズ領域への挑戦混乱からの改善の道筋…重視した4つのポイントプロセス 一気通貫でのプロセスの構築組織/体制 所属を超えた一体型の体制の構築基盤 全体が効率化する環境/基盤の構築文化/風土 改革を進める風土・経営の覚悟☑ DevOpsではCAMSとCALMSSと定義され始めているが、下記を整合性を持って変革していく方針を立てた。
  • 28.
    Page 28 Page28サービス企画システム開発W/Fエンタープライズ領域への挑戦28全体最適の足掛かりにHUBとなる企画-開発のAgile開発化の実現に最初に着手ビジネス部門 IT部門ビジネス企画システム運用サービス開発Agile☑ 前述したSWATでのAgileノウハウを活用し多段構成を解消
  • 29.
    Page 29 Page29プロセス最適化参考URL：http://www.scrumalliance.org/certificationsまずベースとなる共通概念、体系的な理解促進☑ SWAT時の独自Agileの継続運用課題を反省を踏まえ、デファクト且つトレーニング体系の整ったScrumを適用
  • 30.
    Page 30 Page30エンタープライズ領域への挑戦ビジネス部門と一緒に相互理解の促進を図り一体感醸成
  • 31.
    Page 31 Page31サービス企画システム開発エンタープライズ領域への挑戦31ビジネス部門 IT部門ビジネス企画システム運用Scrumチーム各機能のメンバーをアサインしScrumチームを構成☑ 開発部門に閉じずビジネス部門のキーマンもアサイン
  • 32.
    Page 32 Page32エンタープライズ領域への挑戦32独立したScrumチームを編成し自己組織化を促すビジネス部門 運用部門ビジネス企画システム運用☑ 分離と共にScrumチームへ可能な限り権限を委譲ScrumチームPODevOps任せる！(気になるけど)信じてる(怖いけど)
  • 33.
    Page 33 Page33エンタープライズ領域への挑戦33必然的に前述したWater-Scrum-Fallの課題に対峙ビジネス部門 運用部門ビジネス企画システム運用サービス開発Scrum☑ 前後とのサイクルラグはScrumだけでは改善されない開発部門
  • 34.
    Page 34 Page34エンタープライズ領域への挑戦34最終的なゴールは全体スループットの向上ビジネス企画システム運用サービス開発☑ 各機能のサイクルスピードを同期しムダを無くす設計が必要
  • 35.
    Page 35 Page35エンタープライズ領域への挑戦35前後を接続するプロセス設計の検討ビジネス企画システム運用サービス開発☑ Scrumチームの課題に対して最適な解決方法論の選択Scrum
  • 36.
    Page 36 Page36エンタープライズ領域への挑戦36データドリブンの仮説検証型のビジネス企画へシフトビジネス企画システム運用サービス開発☑ 粒度の大きい案件の割に効果が出ない企画立案課題を解決LeanStartupScrum
  • 37.
    Page 37 Page37エンタープライズ領域への挑戦37ScrumSprint2Weeksビジネスと開発の接続設計の明確化とサイクル同期☑ 仮説検証型シフトで案件粒度が細分化しAgile適合度向上☑ まずA/Bテストを実施、結果を持って正式リリース
  • 38.
    Page 38 Page38エンタープライズ領域への挑戦38DevOpsをチームと運用部門の共通概念に設定ビジネス企画システム運用サービス開発☑ ScrumとITIL異なる改善サイクル差異をDevOpsで解決ScrumLeanStartup DevOps
  • 39.
    Page 39 Page39エンタープライズ領域への挑戦39Sprint2Weeks開発チームの改善が全体のITSMの推進に繋がる設計☑ スプリント毎に技術負債リストを作成・更新☑ 短期課題の改善目標を共通ミッションとして設定技術負債短期課題中長期課題組織戦略へScrum ITIL
  • 40.
    Page 40 Page40エンタープライズ領域への挑戦ITS/BTSツールSCMS/W構成管理CI継続的インテグレーションツールテスト環境サービス本番環境検品CD継続的デプロイメントツール継続的モニタリング基盤継続的コラボレーション基盤継続的デリバリー基盤コラボレーションツールScrumチームモニタリングダッシュボードチームが効率的に動く基盤を試行錯誤で構築中モニタリングツール
  • 41.
    Page 41 Page41エンタープライズ領域への挑戦41モニタリングダッシュボードA/Bテスト分析結果新機能UI/UX改善パフォーマンス改善企画立案PODevデータ分析Opsチームが情報をシェアするモニタリング基盤が効果大☑ 立場を超えて新企画立案や課題解決案が出る状態に
  • 42.
    Page 42 Page42エンタープライズ領域への挑戦42異なる方法論/概念を取り入れつつ全体最適をとったビジネス企画システム運用サービス開発☑ 自己組織化したScrumチームがボトムアップで課題を解決ScrumDevOpsLeanStartup
  • 43.
    Page 43 Page43エンタープライズ領域への挑戦43広義にDevOpsとはビジネス全体の加速を促す事ビジネス企画システム運用サービス開発☑ CI環境、リリースの自動化などに目が行きがちだが組織のアクティビティ全体への貢献に高い価値を生み出すDevOps
  • 44.
    Page 44 Page44DevOps推進のサマリ開発プロセス共通言語しやすいScrumを基軸にDevOps/LeanStartupの概念と接続組織/体制開発部門内部に閉じず、関連する部門を巻き込み組織再編成基盤アプリ×インフラ基盤チームを支える業務基盤構築実績 主要2サービスで一年実施中リリースサイクル2週間スプリントを継続し安定・向上現在は部分的に1週間スプリントビジネス貢献投入人月ベースでは純減で、ビジネスKPI/SLA目標を達成ゴール：サービスの継続的成長をITでリードする
  • 45.
    Page 45 Page45Agenda1. リクルート会社概要3. 短期スピードを求めたAgile開発事例4. エンタープライズ領域でのDevOps実現の事例2. リクルートのビジネスとIT活用5. ITがビジネスを牽引する為に
  • 46.
    Page 46 Page46変革を進める上でのスタンス目的と手段を混合しない“XXXX”は手段であり、目的ではない。IT課題を把握・改善提案できるのはIT部門のみ。愚痴るな、声に出して問題提起・改善提案しろ。目先の目標ではなく、中長期の目標達成を優先する。残業するなパワープレーの対応は将来の負債を増やすだけ。何かを変えるアクションには必ずネガティブな意見は出る。信念を持って、粘り強く推進する覚悟と努力が必要。IT部門のマネージャとして心掛けている事（＝日々、部下に言っている小言）
  • 47.
    Page 47 Page47経営層の意識改革集客 営業商品企画システム開発増員クライアント企業増員カスタマー広告費増額IT投資を増員では無く、自己組織化、クロスファンクション化の推進投資へ☑ 開発において体制拡大はスピードダウンの元凶になる
  • 48.
    Page 48 Page48経営層の意識改革FixedParameterVariableParameterScopeTime Resource従来の概念 転換後の概念TimeScopeResourceIT部門はマネジメントパラメータの転換を行う☑ 体制とリリースサイクルを固定化し、チームの習熟に伴いアウトプットが徐々に増えるという考えにシフト。
  • 49.
    Page 49 Page49経営層の意識改革従来の開発検証型の開発ビジネス価値時間案件ビジネス価値時間検証 検証 検証 検証・市場への早期リリース・確実なROIと投資抑制経営がプロセス差異を理解し使い分ける・ 想定するビジネス価値の過大評価・ デリバリ制約
  • 50.
    Page 50 Page50経営層の意識改革☑ 企画立案～リリースまでのリードタイムを圧縮する必要ビジネス部門が要する時間IT部門が要する時間ビジネス部門が要する時間IT部門が要する時間ビジネス部門が要する時間IT部門が要する時間IT部門内に閉じた施策では期間短縮は限定的☑ 経営の合意を持ってビジネス部門と連携して全体最適
  • 51.
    Page 51 Page51密結合経年劣化したアーキテクチュアアーキテクチュアマネジメント☑ 経年劣化した大規模システムは部分切り出しつつアジャイル化システムCシステムBシステムA次世代アーキテクチュア密結合経年劣化したアーキテクチュアシステムCシステムBシステムA密結合経年劣化したアーキテクチュア次世代アーキテクチュアシステムCシステムBシステムB肥大化・密結合化したシステムでAgile開発は困難ビジネス優先度の高いサブシステムを切り出し刷新
  • 52.
    Page 52 Page52アーキテクチャ指針の転換サイトA サイトBソースコード ソースコードサイトA サイトBソースコード ソースコードソースコード（共通部分）従来 アジャイル開発チーム 開発Aチーム 開発Bチーム☑ アーキテクトとして推奨される共通化が逆に足枷になるケースもシステム屋都合の共通化はアジャイルの妨げになる
  • 53.
    Page 53 Page53組織・体制の整備☑ 組織の距離を縮める＝組織変更 or プロジェクト化部門間調整の無駄、重複検討タスクの無駄・・・マネジメントライン複数化による承認プロセスの無駄インタラクティブな企画・要件検討を推進する。認識合わせの為のムダな中間成果物作成の時間を無くす。☑ 物理的な距離も縮める＝ワンロケーション可能な限りセクショナリズムを排除する
  • 54.
    Page 54 Page54さいごにご清聴ありがとう御座いましたSpeed for Enterprise～デベロッパーがエンジンとなって企業ビジネスを加速させていきましょう～
[8]ページ先頭
©2009-2025 Movatter.jp