ビジネスアジリティを支えるDevOpsƒドマップセミナロードマップセミナーAUTUMN2013AUTUMN 2013 ビジネスアジリティを支えるDevOps ～システム開発と運用の新たな関係～

ITロドマップセミナ AUTUMN 2013ITロードマップセミナー AUTUMN 2013

ビジネスアジリティを支えるDevOpsビジネスアジリティを支えるDevOps

～システム開発と運用の新たな関係～

2013年11月22日

野村総合研究所情報技術本部先端ITイノベーション部

上級研究員田中達雄上級研究員田中達雄

本日の講演内容

１ D O とは何か１．DevOpsとは何か

２．先進企業の取り組み内容

３．DevOpsの取り組みを開始するには

４．まとめ

Copyright（C） 2013 Nomura Research Institute, Ltd. All rights reserved. 1




４．まとめ


DevOpsの言葉の意味

DevOpsとは、開発者と運用者が協力して開発したものを素早くリリースできるようする取り組み、思想、コンセプト（概念）。

開発者運用者

新しいプログラム開発者

（Development）運用者

（Operation）

開発したものを素早くリ現在の環境を安定させたい

プログラム

開発したものを素早くリリースしてほしい

現在の環境を安定させたい

開発者運用者

DevOps

（Development）（Operation）

お互い協力して開発したものを


お互協力して開発したもを素早くリリースできるようにしよう。

なぜ今、DevOpsがこれほど注目されるのか

ビジネスとITが密接な関係に市場の変化に応じてビジネス・アジリティ（迅速さ）が加速

ITをビジネスで活用するだけでなく

ITそのものがビジネス（サービス）（）

ITに対してもアジリティ（迅速さ）が強く求められはじめている


ビジネス部門は商品やサービスを早く開発して市場に投入したいがビジネス部門と開発部門の間にはギャップがある

ビジネス開発ギャップ

市場ギャップ

運用ギャップギャップ

早

要求・

決・変

・漏

ニーズ

不明

※

言わ

れるか早

く開発し

があいまい

決まらない

変わる

漏れる

ズ／ウォン

、不確か、

われた通りに

かどうかは分

したい

いいン

ツが

、あいまい

に作っても売

分からない

い


ビジネス部門と開発部門のギャップを埋める手法としてAgile開発が登場


市場ギャップ

運用ギャップギャップ

早

要求・

決・変

・漏

ニーズ

不明

※

言わ

れるか早

く開発し

があいまい

決まらない

変わる

漏れる

ズ／ウォン

、不確か、

われた通りに

かどうかは分

したい

いいン

ツが

、あいまい

に作っても売

分からない

Agile開発Lean Startup

い

Copyright（C） 2013 Nomura Research Institute, Ltd. All rights reserved.

Agile開発Lean Startup

6

開発部門と運用部門の間にもギャップがある


市場ギャップ

運用ギャップギャップギャップ

早

要求・

決・変

・漏

ギャップ

現在

させ

決め

イク

早

ニーズ

不明

※

言わ

れるか早

く開発し

があいまい

決まらない

変わる

漏れる

在のシステ

たい

められたリ

ルを守る

早くリリー

ズ／ウォン

、不確か、

われた通りに

かどうかは分

したい

いい

ムを安定

リリースサ

ースしてほ

ンツが

、あいまい

に作っても売

分からない

Lean Startup

ほしい

Agile開発

い


Lean Startup Agile開発

7

開発部門と運用部門の間のギャップを埋める手法としてDevOpsが登場


市場ギャップ

運用ギャップギャップギャップ

早

要求・

決・変

・漏

ギャップ

現在

させ

決め

イク

早

ニーズ

不明

※

言わ

れるか早

く開発し

があいまい

決まらない

変わる

漏れる

在のシステ

たい

められたリ

ルを守る

早くリリー

ズ／ウォン

、不確か、

われた通りに

かどうかは分

したい

いい

ムを安定

リリースサ

ースしてほ

ンツが

、あいまい

に作っても売

分からない

Lean Startup

ほしい

Agile開発 DevOps

い


Lean Startup Agile開発 DevOps

8

DevOpsの範囲と役割


運用ギャップ

市場ギャップギャップギャップギャップ

狭義なDevOps広義なDevOps 狭義なDevOps


DevOpsの範囲と役割


運用ギャップ


DevOpsAgile開発＋Lean Startup ＋W-Model

TDD, RBT

目的DevOps

開発したものを素早くリリースする

Agile開発＋Lean Startup ＋早く開発する

開発スピード向上

１他の方法論との組み合わせ１．他の方法論との組み合わせ

複数の方法論から必要な要素だけを組み合わせ、自社オリジナルの方法論を組み立てる


DevOpsの内容


運用ギャップ


DevOps目的

Agile開発＋Lean Startup ＋W-Model

TDD, RBT

DevOps開発したものを素早くリリースする

Agile開発＋Lean Startup ＋早く開発する

１他の方法論との組み合わせ


Ｂ．ツール

１．他の方法論との組み合わせ

Ａ．体制・人

ビジネス運用運用/基盤の専門家

継続的デリバリの自動化


開発品質保証テストの専門家11

DevOpsに対するいくつかの疑問

DevOpsは開発スピード向上のため？DevOpsは開発スピド向上のため？

D O はビジネジリが要求さDevOpsはビジネスアジリティが要求される分野のシステム開発だけに適用する？

ビジネスアジリティを追及するがゆえに品質は多少犠牲にする？

DevOpsでは開発者が運用者のスキルを身に着ける必要がある？





４．まとめ


事例）Nationwide ～品質を高めるためにDevOpsに取り組む～

本社：米国オハイオ州コロンバス

さまざまな保険および金融サービスを提供する世界大手企業の1社

年間投資額億ド年間IT投資額12億ドル

品質を高める問題を早く

品質を高める問題早見つける

成果例

ビジネス開発運用問題問題

成果例ディフェクトを５０％改善ダウンタイムを７０％削減保険業界の品質のベンチビジネス開発運用問題問題

運用に関する問題ビジネスに関する問題

保険業界の品質のベンチマークで32の開発部門のすべてがTOP25%に入っている

Agile開発 DevOps＋年前組が


5年前から取り組んでいたが、品質がついてこないと意味がないむしろ品質の方が重要

事例）Nationwide ～品質を高めるためにDevOpsに取り組む～

Agile開発 DevOps＋

運用ビジネス開発品質保証

開発チームを編成（約10名）

現在、400名、32チーム今後、800名、50チームに増強予定オフショアは減らし、基本、オンサイト開発開発後の維持メンテも開発者が担当

運用ビジネス開発品質保証

要件定義の初期段階から

２週間ごとにリリース

開発後の維持メンテも開発者が担当

要件定義、開発、テスト、デリバリ初期段階から運用、テストについても検討

要件定義、開発、テスト、デリバリ・・・

テスト自動化はCucumber※を使用

テスト期間：８週間～１０週間 ⇒ ２週間ツールによる自動化も行っているが、早期に品質が作り込まれるため、テスト後の修正が減ったことも大きな要因早期質作込、後修減大要因

DevOpsの取り組みは、開発スタイルを変えること1年を超えるITプロジェクトは全体の30%。DevOps対象システムの中にも3年 7年という長期プロジクトがある


※Rubyの受け入れテストを自動実行するツール

中にも3年、7年という長期プロジェクトがある体制、環境を重視

事例）REI ～アジャイルサンドイッチを解消～

正式名称： Recreational Equipment Inc. 非公開企業

本社：米国ワシントン州ケント

屋外クリポ品米国大手年売上億ド超屋外レクリエーション、スポーツ用品の米国大手チェーン。2012年の売上19億ドル超。

ビジネス開発

ギプ

運用

半期ごと

2010年 ★Agile開発スタート

ギャップ四半期ごとのリリースサイクル

2010年 ★Agile開発スタートアジャイルサンドイッチ

ビジネス開発運用

しかし・・・

スロー

クイック

スロー

ビジネス開発

目的：早く開発する


ク目的：早く開発する



2011年 ★D O スタト

四半期ごとのリリースサイクル

2011年 ★DevOpsスタート

運用に関する問題も開発初期段階から検討

ビジネス開発運用品質保証

２週間ごとにリリス

自動化ツールによる十分なテスト

要件定義、開発、テスト、デリバリ要件定義の初期段階から運用テストに



ツール：Cucumber Jenkins Puppet Github を使い自動化運用、テストについても検討

ツル：Cucumber, Jenkins, Puppet , Github を使い自動化




2011年 ★D O スタト

四半期ごとのリリースサイクル撤廃

2011年 ★DevOpsスタート

運用に関する問題が開発初期段階から検討

ビジネス開発運用品質保証

２週間ごとにリリス

自動化ツールによる十分なテスト

要件定義、開発、テスト、デリバリ要件定義の初期段階から運用テストに



ツール：Cucumber Jenkins Puppet Github を使い自動化運用、テストについても検討

ツル：Cucumber, Jenkins, Puppet , Github を使い自動化

DevOpsは開発スタイルの変革REI comだけでなく POSシステム開発にも取り組んでいる


REI.comだけでなく、POSシステム開発にも取り組んでいる後工程のための設計書は書かない ⇒ マニュアル的なドキュメント＝Wiki維持メンテは、オンシェア、オフショアに委託

事例のまとめ

Nationwide DRW Target Gamestop REI目的 ◎品質 ◎スピード

○スピード ○品質

対象システム規模や特性・分野に関係なく適用

REI全自主開発全システム全自主開発

gameinformer.com

REI.com,POS

開発体制オンサイト※同じ場所で開発、コミュニケーションの質を重視した体制

チーム編成ビジネス、開発、運用、品質保証

サポート体制オンサイトオンシェアサポート体制オンサイト※開発した人がサポートもする

オンシェアオフシェア

アジャイルカンバン方式スクラム方式

ドキュメント Wiki ※従来型の設計書は一切書かないコード重視、マニュアルに近い発想のドキュメント

継続的ﾃﾞﾘﾊﾞﾘ Jenkins Chefを多用自動化は必須


継続的ﾃﾘﾊﾘ Jenkins、Chefを多用自動化は必須他、Cucumber, Github, Puppetなど

DevOpsに対するいくつかの疑問に対する回答

DevOpsは開発スピード向上のためだDevOpsは開発スピード向上のため？

けではない！DevOpsは開発スピド向上のため？

D O はビジネジリが要求さDevOpsは開発スタイルの変革であり、適用する分野は問わない

DevOpsはビジネスアジリティが要求される分野のシステム開発だけに適用する？

品質を犠牲にするものではないビジネスアジリティを追及するがゆえに

品質を犠牲にするものではない品質は多少犠牲にする？

DevOpsでは開発者が運用者のスキルを身に着ける必要がある？

運用者を開発チームに入れる





４．まとめ


DevOpsの取り組みを開始するためのプロセス

開発のプロセスも業務フローの１つ問題点、ボトルネック、無駄を顕在化コストに置き換える

開発業務フローの可視化コストに置き換える

人のアサイン、組織の変更、環境の整備などはトップマネジメントの理解と後押しが必要これがないと真に開発スタイルを変革することできない

意思決定者を説得＆承認これがないと真に開発スタイルを変革することできない

優秀な人材をアサインする※人材の流動性が米国と比較し低い日本では難しい面がある

優秀なエンジニアをアサイン※人材の流動性が米国と比較し低い日本では難しい面がある

人を集めただけでは不十分メンバの意識改革

優秀

場合によってはこれまでの価値観を変える必要がある

関わった人に確信を持たせる・周りを納得させるには

メンバーの意識改革

関わった人に確信を持たせる・周りを納得させるには分かりやすい成功事例を提示・積み重ねることが重要最初の成功体験


人材育成・拡大・普及普及・拡大していくには特に人材育成面が重要になる人材育成は基本OJT

事例）Target ～トップマネジメントの理解と後押しを得る活動～

本社：米国ミネソタ州ミネアポリスウォルマートに続く全米第二位のディスカウント小売りチェーン（全米１７８８店：2013年

7月時点）年間売上約800億ドル7月時点）、年間売上約800億ドル年間IT投資額は16億ドル

何をしたのか？

ビジネス部門クリススに「プライスチ

開発部門＋運用部門＋品質保証部門動くものを2週間ごとに開発&リリス

2012年6月 DevOpsの取り組みを開始

クリスマスに「プライスマッチ」を提供したい

動くものを2週間ごとに開発&リリースビジネス部門の要件を確認しながら開発を進める

スイブルチェアー（ｺﾐｭﾆｹｰｼｮﾝを密に）

開発期間１年⇒4か月で開発

組織というサイロを壊す


開発期間１年⇒4か月で開発（本PjはDevOps初Pj、現在であれば8週間で開発可能）

事例）Target ～トップマネジメントの理解と後押しを得る活動～

今一番の問題は何かをビジネス、開発、運用部門のメンバーにインタビュー。これら問題のためにいくら損しているかを算出（概算。けっして正確ではないが）

開発業務フローの可視化

CIO、４名のDirector（1,000～3000名を統括する役職、Vice Presidentの下）、４名のSenior Group Manager（300～500名を統括）、2名のGroup Manager（40～50名を統括）に説明

意思決定者を説得＆承認Manager（40 50名を統括）に説明

スマートなエンジニア15名を社内公募で選抜優秀なエンジニアをアサイン

社員のインセンティブを変え、リーダーの意識改革も同時に行うすべてが安定していることが最善⇒リスクをとらない⇒失敗すると×がつく

失敗を「善」とする ⇒ 早く失敗して早く学ぶメンバーの意識改革

失敗を善」とする早く失敗して早く学ぶ社員教育＝メソドロジー（カンバン方式、TDDなど）、ツール

最初のDevOps適用が「プライスマッチ」通常１年以上かかるプロジェクトを４か月で完了

最初の成功体験通常１年以上かかるプロジェクトを４か月で完了

これからの課題。人材面は求人採用で対処。人材育成・拡大・普及


DevOpsへの取り組みを推進できる人材の確保は米国でも困難

事例のまとめ：DevOpsの取り組みを開始するためのプロセス

開発業務フローの可視化

Target Nationwide REI GameStop

意思決定者を説得＆承認

開発業務フロの可視化

ビジネス部門とIT部門のトップ20名でステアリング

自分たちの開発スタイルを認めてもら

努

優秀なエンジニアをアサイン

意思決定者を説得＆承認トッ名でテアリグコミッティを設立・運営

社内公募開発センター少数精鋭の

えるよう努めている

Agile開発優秀なエンジニアをアサイン 15名全体を改革

評価の見直し

少数精鋭のチーム編成

カリスマ的な運用部門

Agile開発メンバーを軸に編成

メンバーの意識改革

「プライス保険業務 REI com

評価の見直し教育評価の見直し

カリスマ的なリーダーが牽引

gameinformer

運用部門の説得

最初の成功体験

採用＋OJT 社内公募採用＋OJT

「プライスマッチ」

保険業務システム

REI.com

採用＋OJT

gameinformer.com


人材育成・拡大・普及採用＋OJT 社内公募

＋OJT採用＋OJT 採用＋OJT




４．まとめ


まとめ組織横断のチームを作る環境を作る

２．トップマネジメントの理解と後押し

評価を変える

発ビジネス開発ギャップ

運用ギャップ

市場ギャップ

目的 W-Model

TDD, RBT

DevOps開発したものを素早くリリースする

目的Agile開発＋Lean Startup ＋

W Model

早く開発する

１他の方法論との組み合わせ


自社の状況や目

Ｂ．ツール

１．他の方法論との組み合わせ

Ａ．体制・人

継続的デリバリの自動化優秀なエンジニア採用

自社状況的に合わせ必要な方法論から必要な要素を選択

ビジネス運用運用/基盤の専門家

継続的デリバリの自動化優秀なエンジニア採用ドキュメント⇒コミュニ

ケーション（質：対面）組織対組織⇒人対人


開発品質保証テストの専門家推進役の確保推進役の確保

まとめ

DevOpsも中身が伴わなければ期待する効果は得られない

名存実亡名存実亡

トップマネジメントの理解と後押し他の方法論との組み合わせ他の方法論との組み合わせ

体制・人ツール


Documents

ビジネスアジリティを支えるDevOpsƒドマップセミナロードマップセミナーAUTUMN2013AUTUMN 2013 ビジネスアジリティを支えるDevOps ～システム開発と運用の新たな関係～