Changing Infrastructure operation by DevOps And Agile Development

Interop Tokyo 2013 【NC-16】
DevOpsとアジャイルで変わる
インフラの現場
NECビックローブ株式会社
サービス開発本部吉野宗壱
基盤システム本部土屋太二

Copyright(C) NEC BIGLOBE, Ltd. 20132
自己紹介
吉野宗壱
（Yoshino Shuichi）
BIGLOBE内で
アーキテクト、スクラム
マスターとして活動中

ＢＩＧＬＯＢＥの会社概要
会社名ＮＥＣビッグローブ株式会社
設立日２００６年７月３日
資本金１０４億円
株主
組織
体系図
・・・付加価値の高い
サービス企画/営業
・・・高い技術力をベースにした
サービス基盤の構築/運用
＊NEC：78％、住友商事：7％、大和証券・三井住友銀行：5％、電通・博報堂：2.5％
ネットサービス事業部
（ISP事業）
ビジネスサービス事業部
(プラットフォーム事業)
ネットマート事業部
（EC・コンテンツ事業
携帯コンテンツ事業
アプリマーケット事業)
メディアサービス事業部
（広告事業）
事業戦略室
戦略的アライアンス推進
新事業開発本部
新サービスの開発
基盤システム本部
サービスインフラの
構築と運用
サービス開発本部
サービスアプリケーション
システムの開発と運用
取締役会経営企画本部監査役経営監査室

ＢＩＧＬＯＢＥの事業領域
 コンシューマ向けサービス
接続サービス
特色あるWebサービス
 企業向けサービス
クラウドサービス
パーソナルクラウドを中心にコンシューマ/企業向けにビジネスを展開

本日の提供価値
みなさまが社会／会社／組織を変えていく、
第一歩目のヒントになれば幸いです。
• 我々を取り巻く時代の流れ
• DevOpsとは？
• アジャイル（スクラム）とは？
• BIGLOBEの「DevOps」と「アジャイル」

もくじ
1. 我々を取り巻く時代の流れ
2. アジャイルとは？
3. DevOpsとは？
4. BIGLOBEの「アジャイル」と「DevOps」
5. まとめ
6. インフラの現場の具体事例（from 土屋）
7. 質疑応答

ご注意
事前に入手可能になっている
PDF資料と差異があるスライドには、
スライドの右上に
マークがついていますので、ご注
意ください。

もくじ
3. DevOpsとは？
5. まとめ
7. 質疑応答

参考：[新経済連盟]http://jane.or.jp/event/summit2013/
「新経済サミット2013」のお話

「インターネット登場によって情報伝達速度が
上がり、予測不可能な時代となった。これまで
の事業計画を立て、プランを実行するという
ルールに沿った事業の進め方が通用しなく
なった」
「テクノロジーの進化によって、イノベーションコス
トも下がってきている。その中で、中央管理型の
組織から、無秩序でカオス型の組織になり、そこ
からイノベーションは生まれてくる」

「やるかやらないかを会議で議論し、考えるコスト
が、やるコストを上回ってしまう。パーミッションレ
スにしないと、破壊的なイノベーションはできな
い」
「イノベーションコストが下がっているからこそ、
失敗を許容してやってみることが大事。走りな
がら考えるくらいのスピード感をもってリスクを
取るべきだ」

考えるコスト
やるコスト考えるコスト
やるコスト
過去現在
仮想化
自動化
コモディティ化
オープ
ン化

参考：[IPA-SEC]http://sec.ipa.go.jp/reports/20120611.html
• 非ウォーターフォール型開発（アジャイル型開発）が欧
米の競争力であることが明らかになった。
• 2009年度の第3四半期に実施した調査で、約35%の開発プロジェクト
でアジャイル型開発手法を採用
• 2010年の調査で、はじめてアジャイル型開発はウォーターフォール型開発を超えた。
• 米国では、ソフトウェアに対する投資は「自社開発（内製）」「市販パッケー
ジソフトの利用」が約2/3をしめている。
• 米国のプロジェクトの形態の特徴は、3割が内製していること。
• デンマークでは政府が発注するソフトウェア開発をアジャイル型開発で実施すること
を推奨している。
「走りながら考える」＝「アジャイル型」
がデファクトになってきている。
「非ウォーターフォール型開発」のお話

「走りながら考える」
走りつづけながら
「機能を提供する」＆「機能を維持する」
開発と運用が一緒に走り続けないといけない
DevOpsのブーム到来
「DevOps」流行の背景

やるコストが
考えるコストを
下回る
走りながら考える
開発手法
「アジャイル」
開発と運用の一体化
「DevOps」
競争激化
プロセスの
イノベーション
プロセスの高効率化
適用スコープの拡大
ここまでのまとめ

すべては
変化に強くなるために！
http://www.flickr.com/photos/dunedinnz/5097629627

もくじ
3. DevOpsとは？
5. まとめ
7. 質疑応答

アジャイル開発とは
“「アジャイルソフトウェア開
発宣言」の「４つの価値」と
「１２の原則」の価値観に
基づいた開発手法の総称“
http://agilemanifesto.org/

アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
http://agilemanifesto.org/iso/ja/

(1)私たちは以下の原則に従う: 顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
(2)要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
(3)動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
(4)ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
(5)意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
(6)情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
(7)動くソフトウェアこそが進捗の最も重要な尺度です。
(8)アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
(9)技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
(10)シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
(11)最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
(12)チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

スクラムは、アジャイル開発の一手法
Scrum
役割
成果物
イベント
プロダクトオーナー（ＰＯ）
スクラムマスター（ＳＭ）
チームメンバー（ＴＭ）
プロダクトバックログ
スプリントバックログ
インクリメント
スプリント
スプリント計画
デイリースクラム（朝会）
スプリントレビュー
スプリントレトロスペクティブ
（ふりかえり）

プロダクトオーナーは、プロダクトの唯一の責任者
• プロダクトバックログの管理者で優先順位付け
の最終決定権限を持つ
• プロダクトのビジョンを示す
• 開発チームに機能や価値を説明して理解して
もらう責任がある
• プロダクトの価値を最大化するために機能と
優先順位を定める
• 作業の結果を受け入れるまたは拒否する

スクラムマスターは、スクラム全体をうまく回す責任者
• 支援と奉仕をする
• 障害事項を取り除く
• スクラムチーム全体が自律的に協働できるよう
にする
• スクラムのプロセスがうまく回るように教育する
• ファシリテート、コーチ、メンター
• 変革推進者

チームメンバーは、動作するプロダクトの開発責任者
• ３人～９人で構成する
• プロダクトの開発をする
• 全員揃えばプロダクトを作れる
• プロダクトバックログの項目を完了状態にして
プロダクトの価値を高めていく

Copyright(C) NEC BIGLOBE, Ltd. 201325 出展：http://www.mountaingoatsoftware.com/scrum/figures
プロダクト
バックログ
スプリント
バックログ
デイリー
スクラム
スプリント
インクリメント
（出荷判断可能な
ソフトウェア）
順位付けされた
要求の一覧
１スプリント分
のタスクの一覧
毎日１５分以内に
昨日やったこと、
今日やること、
課題を共有
期間の長さが
均一のタイムボックス
スプリントで完成され
た機能で、出荷判断
可能なソフトウェア
スプリント
計画
スプリントレビュー＆
スプリントレトロスペクティブ
スプリントでやる事を決める
スプリント中の成果である機能をデモする
＆ふりかえりをする

続きは
BIGLOBEの「アジャイル」と「DevOps」
の章で

もくじ
3. DevOpsとは？
5. まとめ
7. 質疑応答

DevOpsとは
開発と運用の「エコシステム」を構築・維持すること
スプリント
デリバリー
開発
スクラム
モニタリング
フィードバック
運用
自動化
セルフ化
自律化
１つの
チーム

非DevOps
開発
開発
チーム
WF型
PDCA
定期的な
情報共有だけ
運用
チーム
・プロダクトの成長が鈍化
・問題が複雑化しやすい
WF型
PDCA
運用
デリバリー間隔が長い
→ バッチサイズが大きくなる
→ 問題が複雑化しやすくなる
・メンバがセルフでモニタリングできない。APIがない
→ 他者への依頼が必要
→ フィードバックサイクルが長くなる
→ プロダクトの成長が鈍化

DevOpsとは
再掲
スプリント
デリバリー
開発
スクラム
モニタリング
運用
自動化
セルフ化
自律化
１つの
チーム

１つのチーム
DevOps化するためのアプローチ（チーム）
チームビルディング
■価値
・構築→検証→学習のサイクルを素早く回し、
変化に対応しながら最高のパフォーマンスを発揮する
■プラクティス
・プロセスやツールよりも個人と対話
→ 毎日の対話する、対話によるふりかえり、役職ではなく役割
・包括的なドキュメントよりも動くソフトウェア
→ 継続的デリバリー（CI）環境、環境の継続的なカイゼン
・契約交渉よりも顧客との協調
→ 継続的なフィードバッグ（自動化、セルフ化、自律化）
・計画に従うことよりも変化への対応
→ チームの成長、自己組織化（コーチング）

DevOps化するためのアプローチ（開発）
継続的デリバリー
（Continuous Delivery）
■価値
・ビジネスプランを素早く評価できる
（コストの予測可能性が上がる）
・全てを自動化する。（繰り返し可能にする）
・完了は「デリバリーされたこと」を意味する
・品質メトリクスを利用する
・CIの環境を継続的に改善する
・バイナリは一度だけビルド（環境によってビルドが異な
ることは避けよう）
・デプロイするメカニズムはすべての環境で完全に同一
（本番環境にしか必要ない作業はNG）
・デプロイメント時にスモークテストする
・問題が起こったらラインを止める。（無理やりパッチを
当てたりハックしない）
スプリント
デリバリー
開発
スクラム

DevOps化するためのアプローチ（開発）
継続的デリバリー
（Continuous Delivery）
スプリント
デリバリー
開発
スクラム
独自の
デプロイメント
システム

DevOps化するためのアプローチ（運用）
自動化、セルフ化、自律化
■価値
・ビジネスプランを素早く評価できる
（コストの予測可能性が上がる）
・評価観点を追加、変更することが容易
・他者に依頼する必要がないため、時間が
かからない
・モニタリング可能な指標を自動で収集する（自動化）
・指標は、見たい人自身で収集できる（セルフ化）
・指標は、APIを利用することで取得できる（自律化）
・APIを利用したインテグレーションシステムを作り出す
（自律化）
モニタリング
運用
自動化
セルフ化
自律化

DevOps化するためのアプローチ（運用）
自動化、セルフ化、自律化
モニタリング
運用
自動化
セルフ化
自律化
※Google Analytics™はGoogle Inc.の登録商標です。

DevOpsとは
再掲
スプリント
デリバリー
開発
スクラム
モニタリング
運用
自動化
セルフ化
自律化
１つの
チーム

もくじ
3. DevOpsとは？
5. まとめ
7. 質疑応答

開発の内製化＋アジャイル化のお話
開発を
内製化＋アジャイル化
運用を
開発と運用を
１つのチームで実施
２００X~
２０１１~ ２０１２~
２０１３~
開発も運用を一体で推進
開発・運用のほぼ全てを外部委託
１９９X~
開発を
外製化＋ WF型
運用を
外製化＋ WF化
２００X~

開発を
運用を
開発と運用を
２００X~
２０１１~ ２０１２~
２０１３~
開発、運用は外部委託
１９９X~
開発を
外製化＋ WF型
運用を
外製化＋ WF化
２００X~

アジャイル開発手法として
「スクラム」
というプラクティスを採用

Copyright(C) NEC BIGLOBE, Ltd. 201341 © NEC BIGLOBE
2012年度 2013年度2011年度
13
チーム
21
チーム
+
α
アジャイル開発の拡大(チームベース)
5チーム
新事業領域による
試行開始
業務システム領域
拡大
全面展開
(基盤含む)
立上期確立期試行期

Copyright(C) NEC BIGLOBE, Ltd. 201342 http://www.flickr.com/photos/desiitaly/2201907500/
なぜ、スクラムに
取り組んだのか

Copyright(C) NEC BIGLOBE, Ltd. 201343 http://www.flickr.com/photos/jurvetson/7119907039/
従来の開発は
全ての要件を定義し
一気に作るが…

http://www.flickr.com/photos/soldiersmediacenter/6966568190/
当てるのが難しい

http://www.flickr.com/photos/59937401@N07/5858004830/
リリース
して検証
しないと
わからない

http://www.flickr.com/photos/carbonnyc/4740025131/
市場の変化
～スピード加速へ～

http://www.flickr.com/photos/pmiaki/3121294571/
市場の変化
～素早く具現化へ～

“変化が起こる“ことを前提に
”頻繁に軌道修正する”ことを
当たり前の組織にしたい
スクラム導入の理由

http://www.flickr.com/photos/jdhancock/3772013250/
どのように、スクラムを
適用したのか？

スクラムとの出会いスクラムとの出会い
１枚の記事が
きっかけ
http://cedec.cesa.or.jp/2010/program/BM/C10_P0187.html
http://d.hatena.ne.jp/Aqu/20100905/1283715639

“新サービスをスクラムで開発
してリリース“
”結果を出した”
http://www.flickr.com/photos/bellergy/4046550338/sizes/m/in/photostream/

４つの変化とその効果
① マインド
② 顧客視点
③ 品質
④ 開発生産性

① マインド
② 顧客視点
③ 品質
④ 開発生産性

変化① ：マインド
•自発性
•カイゼン
•成長意欲

変化① ：マインド（自発性）
• 自発性(脱請負)
– 仕事に対する取り組む姿勢(意思)の変化
– リーダーだけでなく、開発メンバー全員の変化
– 自己組織化
開発メンバー自身のプレゼンより

特定のリーダはいない
一人一人が考えて行動

変化① ：マインド（カイゼン）
• より良くしたいというカイゼンマインド
– 自律的に問題を抽出し、継続的にカイゼン
– 朝会、ふりかえり、見える化（タスクボードなど）
開発メンバー自身のプレゼンより

開発
毎日
デイリー
スタンドアップ
ミーティング
(朝会)
チームへ
タスクボード
バーンダウンチャート
(見える化)
スプリント
プランニング
(計画)
開発
スプリント
（１～4週間）
プロダクトへ
スプリントレビュー
(デモ)
ふりかえり
変化① ：マインド（カイゼン） -ふりかえりの定着-

変化① ～マインド(成長意欲)
エンジニアとしてより腕を研く
外部研修の受講回数UP 技術系の書籍の購入数UP
研修や書籍をきっかけとして
エンジニアとしての成長を

変化① ～マインド(成長意欲)
自主的に勉強会をほぼ毎週開催
プロダクトオーナー勉強会
スクラムマスター勉強会
UX勉強会
PHP勉強会
プログラミングコンテスト
TDD勉強会
CI勉強会
開発合宿
スクラム勉強会
ランチ勉強会

① マインド
② 顧客視点
③ 品質
④ 開発生産性

変化② ：顧客視点(チーム)
• 新事業チーム(リーンスタートアップ)
ミルフォトブック
プロダクトの価値を追求する
チーム全員でプロダクトの価値を考えて開発
なぜプロダクトを開発するのかを共有

変化② ：顧客視点（ユーザテスト）
ペーパープロトタイプ

企画の人
開発
の人
開発者
デザイナ
全員で
ユーザと
向き合う
企画も
デザイナも
開発者も
変化② ：顧客視点（一般ユーザのユーザテスト）
一般の人
一般の人

変化② ：顧客視点（社内ユーザテスト)
社内ユーザで
モニター評価

データを加工して
さらにわかりやすく
変化② ：顧客視点（グロースハック）
エンジニア自身が自分で考えて計測

グロースハック勉強会
（マーケティングとエンジ
ニアリングの融合）

① マインド
② 顧客視点
③ 品質
④ 開発生産性

変化③：品質
 コミュニケーションギャップの減少
 品質意識の向上(出荷判定会議の廃止)
 保守性の向上
障害（リリース後）の件数が
１年間で約50%減少

分析設計実装
テス
ト
分析
テスト
設計
実装
従来（WF）：リレー方式スクラム
縦割り組織一丸となったチーム
ｔｔ
変化③：品質
（コミュニケーションギャップの減少）
GAP GAPGAP

変化③：品質（アジャイルチーム化）
期２０１１下期２０１２上期２０１２下期
障害件数の
削減割合 0％ 20% 48%
アジャイル化した
チームの割合 4% 24% 62%
チーム化の進捗/成熟に伴なって、
障害件数も減少！

変化③：品質（障害のふりかえり）
常にチーム内でふりかえりをして、
コミュニケーションをとることを重視
従来の形式的な
再発防止の検討を止める

変化③：品質（POと一体の活動）
朝会
KPI作り

スクラムの役割
プロダクト
オーナー
スクラム
マスター
チーム
メンバー
プロダクト
プロダクトの唯一の責任者
動作するプロダクトの
開発責任者
（機能横断チーム）
スクラムチームが
成果を最大化
できるように
促進する責任者
同じチーム
になる！
プロダクト共同所有

変化③：品質(出荷判定の廃止)
品質意識の向上
出荷判定会議

変化③：品質
（従来の出荷判定会議の主な課題）
• 品質状況やリスク、課題の確認を行っていたが
やらされ感で実施していた
• 出荷判定に合格することを目的に会議していた
• 合格してもバグが出ることがあった
• 顧客が望んでいるものと開発者が考えているも
のを書類や数字で確認するのに限界があった
儀式になり機能してない

変化③：品質
（出荷判定会議の改善内容）
• 出荷判定会議の儀式をやめた
• チーム全員でデモ（動くソフトウェア）を確認して、
出荷可能かを判断した

変化③：品質
（出荷判定会議廃止後の変化）
• チーム全員が何を持って完了かの定義を明確にして意
識して行動するようになった
• テスト駆動開発（TDD）や継続的インテグレーション（CI）
などを積極的に導入して品質強化を図った
• 自己組織化されたチームになった
• 顧客（PO）との対話が増えた
• リリーススピードが速くなった
ルールから習慣へ

変化③：品質
（保守性の向上）
従来のプログラム品質
・機能が実現できてること。(バグがないこと)
ビジネスのスピードシステムの複雑化
変化に強いソフトウェア
(保守性)
循環複雑度自動テスト(カバレッジ)

7.1
コードの複雑さをｉｆ文やｆｏｒ文の数から算出する
低いほどコードの保守性・拡張性が高くなる
循環複雑度
循環複雑度
56.0 某従来型
請負PRJ
某内製
アジャイル
チーム
内製チームがより良いプロダクト(コード)を考えることが重要

ソースコードの静的解析
（メソッド複雑度）

コードカバレッジ
83%
プロダクトコードがテストコードによりテストされた割合
高いほどバグが入り込みにくい
コードカバレッジ
自動テスト
常に自動でテストを動かして、
変化に強いソフトウェアを作っていくことが重要
某従来型
請負PRJ
某内製
アジャイル
チーム
0%

① マインド
② 顧客視点
③ 品質
④ 生産性

ベロシティ
(アジャイルにおける生産性の単位)
18SP→25SP
変化④ ～生産性向上(1チームの生産性)
約1.4倍
• とあるチームの3ヶ月の推移
（2012/11⇒2013/2)
アーキテクチャの整理
(リファクタリング)
チームの成長

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
再掲

開発を
運用を
開発と運用を
２００X~
２０１１~ ２０１２~
２０１３~
１９９X~
開発を
外製化＋ WF型
運用を
外製化＋ WF化
２００X~

運用が分離されていることの問題
1. カイゼンする気持ちがない
2. 目的意識が希薄
3. 費用対効果がマイナス

実績工数精算にしていたため
改善する動機が発生しにくい
http://www.flickr.com/photos/waitingfortheword/5573145362

http://www.flickr.com/photos/mananasoko/8003197568
対応
ミッションを議論し、
KPIを自分たち（全員）で
設計する

「Why」が消えていく
伝言ゲーム
http://www.flickr.com/photos/dotbenjamin/2843144877

WhyWhy
http://www.flickr.com/photos/royskeane/413103429/
Whyを共有
対応
Why
How
What
ゴールデン・サークル

http://www.flickr.com/photos/pohan-camera/2695052909
割にあわないと
見捨てられた「機能」たち

対応
www.flickr.com/photos/ist4u/6108818214
骨を拾い、魂を吹き込み、成仏させる。
（業務横断、システム横断の
視点で効果を見直し）

対応
www.flickr.com/photos/ist4u/6108818214
WhyWhyWhy
How
What

運用の内製化＋アジャイル化の成果
【品質】
作業障害率
半年間で
50%減少
【コスト】
運用保守費
1年間で
20%削減

開発を
運用を
開発と運用を
２００X~
２０１１~ ２０１２~
２０１３~
１９９X~
開発を
外製化＋ WF型
運用を
外製化＋ WF化
２００X~

http://www.flickr.com/photos/jodiepedia/296531689/
開発と運用チーム
シャッフル！

http://www.flickr.com/photos/jodiepedia/296531689/
組織の構造改革！
管理職：減↓、エンジニア：増↑
チームを主体としたフラット組織運営

アジャイルなフラクタル組織
３つの階層が同じ役割のメンバ、プロセスで機能する組織構造
DEVSM
PO
DEVSM
PO
DEVSM
PO
D
E
V
S
M
P
O
D
E
V
S
M
P
O
ディビジョンクラスチーム
クラス
チーム
クラスとは
注力すべき事業・プロジェクトを上手く進めるための集合体。
複数のチームで構成し、固定化された集合ではなく流動的に変化する。
共通のマーケット、プロダクトと形成すべきコアコンピタンスが存在する

【事業責任】マネージメント
クラス２クラス１クラスN
マネージメントの変化
チーム
チーム
【推進】メンバ、チームの戦略・事業推進の場と仕組み
・・チームチーム・・
・・
チーム
チーム
チームチーム・・
チーム
一体・フレキシブルにローテーション
【運営】チームを活性化・効率化させる場や仕組み
シェアアピールワーク朝会定例議論勉強会
ゴールＫＰＩ人材獲得技術開発特許戦略
新事業
ＱＣＤ
育成
売上拡大
予算業績品質ｺﾝﾌﾟﾗｲｱﾝｽ

スクラムの役割
プロダクト
オーナー
スクラム
マスター
チーム
メンバー
プロダクト
プロダクトの唯一の責任者
動作するプロダクトの
開発責任者
（機能横断チーム）
スクラムチームが
成果を最大化
できるように
促進する責任者
同じチーム
になる！

もくじ
1. 我々を取り巻く、時代の流れ
3. DevOpsとは？
5. まとめ
7. 質疑応答

やるコストが
考えるコストを
下回る
走りながら考える
開発手法
「アジャイル」
開発と運用の一体化
「DevOps」
プロセスの
イノベーション
プロセスの高効率化
適用スコープの拡大
まとめ

まとめ
スプリント
デリバリー
開発
スクラム
モニタリング
運用
自動化
セルフ化
自律化
１つの
チーム
チームを中心に！
人にフォーカス

すべては
変化に強くなるために！

おまけ（我々が工夫した点）
①安全な場を作る
②チームの成長にフォーカス
③個人の成長を促す

①安全な場を作る
http://www.flickr.com/photos/trysil/7005482071
• 周囲とは違う動きをするチームを種から育てる
• 既存から隔離する。邪魔しない。
• 本音でしゃべれる環境
• 小さな成功体験の積み重ね

• ビジョンの共有
• チームの状態を見える化
• 既存のパラダイムからの脱却
• チームを信じてまかせる
毎週
ワークショップ
ビジョンの共有

• ビジョンの共有
• チームの状態を見える化
• 既存のパラダイムからの脱却
• チームを信じてまかせる
• 出荷判定会議の廃止
• 案件承認システムの廃止
• 既存の見積り方法の廃止
やってもいいんだ！
既存のルール/承認
（思考停止の原因）
の排除

Keep
良かったこと
Problem
悪かったこと
Try
改善すること
Contribution
なりたい姿
貢献
© NEC BIGLOBE
③個人の成長を促す
エンジニアとして、
どうなりたいのか？
そして、それがチームに
どう貢献していくのか？
個人の成長だけでなく、それによって
チームにどう貢献するのかを意識することによって、
自身の成長のモチベーションにつなげる
会社内の
人事評価制度
とは別に実施

http://business.biglobe.ne.jp/
NECビッグローブ
ＢＩＧＬＯＢＥビジネスサービス
アジャイル開発研修プログラム
実践者が教えるアジャイル開発の基礎
ビジネス環境の急速な変化に対応するため、リーンスタートアップやアジャイル開発といった無駄のない柔軟な開発が求められています。
複雑で変化の激しい問題に対応するためのフレームワークである「スクラム」によるアジャイル開発は、価値あるソフトウェアを世に送り出すための無駄のない柔軟な開発を行う方法論です。
無駄のない柔軟な開発を行う方法論
アジャイルとは？
ウォーターフォールとの違いは？
アジャイル導入のメリット・デメリットは？
何故アジャイルなのか？
そんな疑問や課題にお応えする研修プログラムです。マスコットキャラクター
アジャイルちゃん

■なぜアジャイルなのか
■ワークショップ１
■アジャイル・スクラム概要
■ワークショップ２
■自己組織化
■ワークショップ３
コース概要
■顧客が本当に求めているモノを最短で提供するための「アジャイル開発」
代表的なアジャイル開発手法のスクラムをベースに、アジャイル開発の基本概念とメリット、ウォーターフォールをはじめとした従来の開発手法との違いを修得します。
研修プログラムの特長
■アジャイル開発のメリットをワークショップで体感できる
何故アジャイル開発が求められているのか、アジャイル開発とは何かといった基本概念の講義に加え、ウォーターフォールなど従来の開発手法との違いやアジャイル開発のメリットを体感でき
るワークショップを実施します。アジャイル開発の導入検討中あるいは導入後に課題を感じている企業向けに、導入成果の最大化へのヒントを提供します。
■Webや書籍では得られない、実践者による現場で活用できる独自の研修プログラム
米国Scurm Allianceの認定資格「認定スクラムマスター」並びに「認定スクラムプロダクトオーナー」を取得し、アジャイルコーチやスクラムマスターとして、Ｗｅｂサービスやアプリなどを開発し
た経験を持つBIGLOBEの開発者が、実感している成果や導入にあたっての障害など、現場の体験談を交えながらアジャイル開発のポイントを解説。また、関連セミナーなど登壇経験を活かし
た独自の研修プログラムを制作。
NECビッグローブ株式会社ビジネスサービス事業部
TEL : 03-6479-5692 e-mail： bizinfo@bcs.biglobe.ne.jp
※電話番号はおかけ間違えのないようご注意ください。（受付時間）9:00～12;00、13:00～17:00 土日祝日、弊社所定の休日を除く
NECビッグローブ株式会社〒141-0032 東京都品川区大崎一丁目11-1（ゲートシティ大崎ウエストタワー） BB300018
詳しいサービス内容・料金・導入のご相談は、下記へどうぞ。
●本紙に掲載された社名、商品名は各社の商標または登録商標です。
2013年5月現在
アジャイル開発研修プログラム
「BIGLOBEアジャイル開発研修プログラム」
本研修プログラムはNECラーニング株式会社が提供しています。
紹介サイト http://www.neclearning.jp/courseoutline/courseId/SD071/
コース内容(1日間） 9：30～17：30 ※プログラムは順番・内容等を変更する場合があります。
午前午後
到達目標
■他者にアジャイル開発の基本概念を説明できる。
■他者にウォータフォール開発とアジャイル開発の違いを説明できる。
■アジャイル開発のメリットを理解して現場で活用できる。
■プロダクトの価値を追求する
■ワークショップ４
■アジャイルな見積りと計画づくり
■ワークショップ５
■イテレーション開発
■ワークショップ６
■ふりかえり
■ワークショップ７

もくじ
3. DevOpsとは？
5. まとめ
7. 質疑応答

自己紹介
土屋太二（つちやたいじ）
– 2011年日本電気株式会社入社
– 同年、ＮＥＣビッグローブ株式会社に出向
業務
– データセンタのネットワーク開発・検証
– SDN開発チームに参加
2013/6/13
©2013 NEC BIGLOBE, Ltd. 118

(2013年4月22日プレスリリース)
BIGLOBEデータセンターの仮想化を実現
〜最先端のOpenFlow技術を活用〜
DevOpsとアジャイル開発を取り入れることで
独自開発に成功
クラウドコントローラ
「ｍｏｍｉｊｉ」
ＳＤＮ
サーバ
【仮想化】
ネットワーク
【仮想化】
2013/6/13
http://www.biglobe.co.jp/pressroom/release/2013/04/130422-a

1. BIGLOBEの目指すデータセンター
2. momiji 概要
3. DevOps & アジャイルの実践
4. 今後のチャレンジ
2013/6/13

2. momiji 概要
2013/6/13

BIGLOBE データセンタ事業
• 法人企業向けに、サーバ / ネットワークなど
のインフラ環境を提供
OS
ハードウェア（サーバ）
ネットワーク
ミドルウェア
アプリケーション
コンテンツ
ユーザ
BIGLOBE
IaaS
( Infrastructure as a Service )
PaaS
( Platform as a Service )
SaaS
( Software as a Service )
2013/6/13

インフラ構築の流れ
２週間
５日間
運用
数分
インフラ
設計
企画
要件定義接続
サーバ
構築（仮想化）
ネットワーク
構築
（サーバ・ネットワーク設計）
要件定義から運用開始まで３週間を要する
2013/6/13

ネットワーク構築に必要な作業（２週間）
（３）ＩＰアドレス、ＶＬＡＮ番号など
機器の数だけ払い出す
データセンター
構築作業者
ネットワーク
技術者
（１）必要なリソースを決定
ex)ルータ、スイッチ
ロードバランサなど
（２）リソースを確保し接続
（４）機器1台ずつに
ログインして設定
（５）サーバとネットワークを接続
ex)サーバ１台づつに
ルーティング設定などが必要
2013/6/13
ネットワーク技術者と構築作業者による作業が必要

• サーバは仮想化により構築が効率化
データセンターのインフラの現状
次はネットワークで仮想化を！
サーバ
【仮想化】
データセンターのインフラ
ネットワーク
【仮想化
非対応】
物理ネットワーク
- 専門技術者が設計
- 構築に時間がかかる
２００８年頃～仮想化
- オンデマンド：柔軟に拡張
- 数分で構築
- リソースの有効活用
2013/6/13

【ネットワークの柔軟性】
ファイアーウォールや
専用ネットワークを自由に使えない
・セキュリティ強化が困難
・クラウドサービスと
基幹システムを
安全に接続できない
ネットワークがインフラ構築のネックに
スピード：○
スピードと柔軟性を両立させたい！
柔軟性：○
柔軟性：× スピード：×
＜クラウドの場合＞＜ＳＩの場合＞
・自由度は高いが
構築時間がかかる
2013/6/13

BIGLOBEが目指すデータセンター
クラウド
高
低
遅
速
理想の
インフラ構築
ＳＩ
スピード
柔軟性
スピード：○
柔軟性：○
2013/6/13

2. momiji 概要
2013/6/13

データプレーン
(一般的な商用ハードウェア)
コントロールプレーン
(ユーザがプログラム可能な制御ソフト)
(ユーザがプログラム可能な各種プロトコル)
データプレーン
(ベンダの独自ハードウェア)
SDN(Software Defined Networking)の登場
• 2009年頃からOpenFlow, VXLAN, NVGRE, STT…が登場
• オープンソースによる実装も登場
必要なネットワーク機能を自ら実装できる時代に
コントロールプレーン
(ベンダー独自の制御ソフト)
(ベンダーが実装した各種プロトコル)
2013/6/13
従来のNW機器

インフラ構築のを実現スピード柔軟性
「ｍｏｍｉｊｉ」
仮想化したサーバとネットワークを一括コントロール
ＳＤＮ
サーバ
【仮想化】
ネットワーク
【仮想化】
SDNを導入することで
データセンターの仮想化に成功
2013/6/13

NW機器VXLANOpenflow
スイッチ
サーバ
最新の機器・技術、ニーズの変化に柔軟に対応
・・・
 機能のモジュール化とオープンソースの積極採用
クラウドコントローラー「ｍｏｍｉｊｉ」
リソース管理
・・・
サーバ
コントローラ
構成管理
OpenFlow
コントローラ
VXLAN
コントローラ
NWサービス
コントローラ
ミドルウェア
コントローラ
Mysql
Heartbeat
・・・
クラウドコントローラ「momiji」を独自開発
2013/6/13

OpenFlowとVXLANを組み合わせた
先進的なネットワークを実現
 標準化されたプロトコルでデータセンター間接続を実現
 ＶＬＡＮの数の制限から解放（4000→1600万）
2013/6/13

「momiji」によるインフラ自動構築
• パソコン上で１０数項目を選択するだけ
２週間の作業が約１０分に
複雑なインフラも
自動で構築可能に
2013/6/13

柔軟なネットワーク構築が可能に
クラウドのスピードで柔軟性の高いインフラを構築可能
ネットワークサービス
ＩＰアドレス種別
ファイアウォール
ルーター
ロードバランサ
グローバルＩＰアドレス
プライベートＩＰアドレス
持ち込みＩＰアドレス
クラウドサービスと
基幹システムの接続
クラウドサービスで
個人情報を安全に管理
2013/6/13

momiji 導入による効果
２週間
５日間
運用
数分
インフラ
設計
企画
要件定義接続
サーバ
構築
ネットワーク
構築
約１０分に短縮
サーバとネットワーク両方を短期間で構築可能に
2013/6/13

2. momiji 概要
2013/6/13

DevOps & アジャイル
を導入した狙い
2013/6/13

ゴールが見えない
2013/6/13

手探り
2013/6/13

2013/6/13
97629627
変化に強いシステムを
作りたい

2013/6/13
開発力を
上げたい

アジャイルにたどりつく
2013/6/13

開発スケジュール
• 2012年1-3月: NW仮想化技術の調査検証
• 2012年4-9月: momiji 基本機能の開発
• 2012年10月-2013年3月: 試験導入
運用機能の開発
UIの開発
• 2013年4月～：本格導入
2013/6/13

開発スタート
2013/6/13

まずは
ネットワークチームで
サンプルを作る
2013/6/13

第一の壁
あれ。作れない。
2013/6/13

必要となる技術に大きなギャップ
• これまでのネットワーク技術者の業務
– ネットワークの設計
– 各ベンダの独自UIを使ったネットワーク構築
2013/6/13
• momiji開発で必要となる知識・能力
– インフラ運用全工程のノウハウ
– オープンソースを使いこなすサーバやOSの知識
– 大規模ソフトウェアの開発ノウハウ
– NW仮想化標準プロトコルの知識と実装力

ネットワーク技術者
だけでは無理orz
2013/6/13

まずは
メンバーを集める
2013/6/13

• ネットワーク技術者（NECビッグローブ,運用）
• サーバ技術者（NECビッグローブ,運用）
• ソフトウェア技術者（NECビッグローブ、開発）
• OpenFlow技術者（NECクラウドシステム研究所、
開発）
各チームから精鋭を招集
2013/6/13
各分野のノウハウを集結
– BIGLOBEインフラの運用ノウハウ
– クラウドシステムのソフトウェア実装ノウハウ
– OpenFlowを始めとする仮想NWの実装ノウハウ

チームを作る
2013/6/13

アジャイルについて学ぶ
2013/6/13
• アジャイルを実践しているサービス開発
チームのメンバーにコーチ役をお願い
• インフラチームに合うように、少しずつ味付け
していく

チーム全員を同じバスに乗せる
• インセプションデッキの作成
2013/6/13

チーム分け
• １チーム5〜6名になるようにチーム編成
開発チーム
仮想ネットワーク
開発チーム
ネットワーク
技術者
スクラム
マスター
アジャイル
コーチ
ソフトウェア
技術者
ネットワーク
技術者
OpenFLow
技術者
サーバ
技術者
スクラム
マスター
プロダクト
オーナー
ソフトウェア
技術者
ネットワーク
技術者
2013/6/13
ソフトウェア
技術者

あらためて
開発スタート
2013/6/13

実践したこと
2013/6/13

アジャイルの基本を
忠実に実践
2013/6/13
朝会
毎日
見える化
開発
計画開発
スプリント
（１～4週間）
デモ
ふりかえり

2013/6/13
朝会
毎日
見える化開発

朝会
• 各自の状況や認識を共有
– 昨日やったこと
– 今日やること
– 抱えている問題
2013/6/13
朝会
毎日
見える化開発

開発
2013/6/13
朝会
毎日
見える化開発

チケットによるタスク管理
2013/6/13
朝会
毎日
見える化開発

タスクの消化率をチームで共有
バーンダウンチャート
2013/6/13
朝会
毎日
見える化開発

2013/6/13
計画開発
スプリント
（１～4週間）
デモふりかえり

スプリントプランニング（計画）
• プロダクトオーナーが作ったバックログを元に、
メンバーがタスク（4H程度）に落とし込む
バックログアイテム見積もり
ルータにVLANインタフェースを作成するための情報
を DBに入力、管理できる
1
ルータにVLANインタフェースを設定できる 2
momijiで作成した同一サービスＩＤ内のフィルタ設定
追加が行える
3.5
評価環境構築 3
結合テスト 5
2013/6/13
計画開発
スプリント
（１～4週間）
デモ
ふりかえり

開発、開発、開発
2013/6/13
計画開発
スプリント
（１～4週間）

スプリントレビュー/デモ会
• 定期的に機能単位でリリース出来ていること
を確認
• ステークホルダーにも進捗共有
2013/6/13
計画開発
スプリント
（１～4週間）
デモ
ふりかえり

ふりかえり
• Keep(良かったこと) / Problem（ダメだったこと）
/ Try（解決アプローチ）
2013/6/13
Keep
Problem
Try
バーンダウン
できた！
残業多くてつらい
わからないときに
すぐ聞けない
OpenFlowが
よくわからない
○○さんがタスク
とれるようになった
OpenFlow
勉強会やる
プロジェクトルーム
を作る
チームの
定時退社日をつくる
デモ成功！
最高のパフォーマンスを
出すためのルールを
チームで考え、作り、実行する
計画開発
スプリント
（１～4週間）

一か月ほどで
チームの問題点が
見えてくる
2013/6/13

第二の壁
タスクが属人化
2013/6/13

メンバーに距離感がある
ネットワーク
技術者
ソフトウェア
技術者
OpenFlow
技術者
2013/6/13

そもそも距離がある
ネットワーク
技術者
ソフトウェア
技術者
OpenFlow
技術者
2013/6/13

ネットワーク
技術者
ソフトウェア
技術者
OpenFlow
技術者
ネットワーク設計が
得意
クラウドシステムの
ソフトウェア実装が
得意
OpenFlow実装が
得意
得意領域があまりに違う
2013/6/13

ネットワーク
技術者
ソフトウェア
技術者
OpenFlow
技術者
ウォーターフォール文化の名残り
設計するから
あとは任せた。
やりたいこと
決めてもらえれば
作るよ。
OpenFlow、
NW仮想化のことなら
どんとこい！
2013/6/13

ネットワーク
技術者
ソフトウェア
技術者
OpenFlow
技術者
それぞれに戸惑い
あれ、仮想ネットワーク
どうやって設計するの？
あれ、OpenFlow
どうやって
実装するの？
あれ、クラウドシステムの
運用ってどうやってるの？
2013/6/13

もっと互いを知る必要がある
ネットワーク
技術者
ソフトウェア
技術者
OpenFlow
技術者
2013/6/13

お互いを知るために
実践したこと
(メンバーから出たアイディアを実践)
2013/6/13

プロジェクトルームを作る
• メンバー全員が一緒になってカンヅメ
• つまづけばすぐに聞ける体制づくり
2013/6/13

勉強会
• インフラの設計、 OpenFlowや仮想ネットワー
クの仕組み、流用しやすいコードの書き方
• とにかく教え合う
2013/6/13

ペアプログラミング
Photo By esti-
http://www.flickr.com/photos/esti/4638056301/
初心者
上級者
2013/6/13

コードレビュー
• すべてのコーディング関係のタスクに
コードレビュータスクを追加
機能Aの実装
[レビュー]
機能Bの実装
機能Bの実装
[レビュー]
機能Bの実装
• 実装者以外が取ること
• 10分以内で完了すること
2013/6/13

チームに変化が現れる
• ノウハウ伝授に時間がかかるものの、
少しずつチームの開発力の幅と底力がついた
• メンバー全員に責任感が生まれた
• メンバー全員が意見交換をできるようになった
• メンバー全員で自ら問題点、解決策を考え、
実行する文化が根付いた
2013/6/13

DevOps,アジャイルを導入した効果
• ゴールの形を相談しながら、着実に開発を進
めることができた
• 重要度が高い機能、ニーズが強い機能から
順にリリースできた
• 定期的にフィードバックをもらう仕組ができた
• 開発力の向上ができた
2013/6/13

DevOps,アジャイルで
うまくいかなかったところ
• 開発拠点に距離があると、まともなコミュニケー
ションができない
• コア技術の伝授は、なかなか効率が上がらない
• パケットを転送する部分には通信断が発生させ
られないため、頻繁なリリースができない
2013/6/13

考察：
DevOps, アジャイルが有効なケース
• DevOps
– 運用者が開発に参加できるリソースがある
– 導入後も継続的にフィードバックサイクルを回せ
る
• アジャイル開発
– 完成形を探りながらの開発
– チーム全体の開発レベルを向上させたい
2013/6/13

考察：
DevOps, アジャイルが難しいケース
• DevOps
– 運用と開発の壁が大きい
– 一度きりのリリースで開発が終了してしまう
• アジャイル開発
– メンバーの開発拠点が離れている
– 一時的な通信断を一切許容できない部分の開発
• ただし「通信断が発生する部分」以外の定期リリースは
可能
2013/6/13

考察：変わりゆくインフラの現場
• 激しい変化の中でインフラが対応していくに
は、スピードアップが必要不可欠
• 内製化により、スピーディかつ継続的に
磨き上げる開発体制が求められている
2013/6/13
Photo by Beverly & Pack
http://www.flickr.com/photos/walkadog/3432078139/

2. momiji 概要
2013/6/13

BIGLOBEデータセンターの新たなチャレンジ
２週間
５日間
運用
数分
インフラ
設計
企画
要件定義接続
サーバ
構築
ネットワーク
構築
数分に
2013/6/13

• 「やりたいこと」を決めるだけで
インフラが自動的に構築される
インフラ設計を不要にする
新発想のデータセンター
５日間
数分
アクセスが増えた
のでサーバを倍
増したい
個人情報を集め
るのでセキュリ
ティを強化したい
基幹システムと繋
げて、決済機能を
追加したい
＜従来＞
複雑なネットワーク設計図を作成
ネットワークの専門知識が不要

まとめ
• DevOpsとアジャイルを実践することで、
先進的な技術を活用した「momiji」の
独自開発に成功した
• 激しい変化の中でも生き残れるインフラ
を実現するためには、自ら革新し続ける
開発体制が必要になってくる
2013/6/13

もくじ
3. DevOpsとは？
5. まとめ
7. 質疑応答

【質疑応答１０分】
※本セッション終了後も、本ルー
ム周辺にいますので、お気軽に
お声がけください。

長時間
ご清聴
ありがとうござい
ました。

2013/6/13

Changing Infrastructure operation by DevOps And Agile Development

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Changing Infrastructure operation by DevOps And Agile Development

Similaire à Changing Infrastructure operation by DevOps And Agile Development (20)

Plus de Taiji Tsuchiya

Plus de Taiji Tsuchiya (18)

Dernier

Dernier (10)

Changing Infrastructure operation by DevOps And Agile Development