DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/4599
Togetter
http://togetter.com/li/537974
以下の書籍をターゲットとした読書会なのです。
 | アジャイルサムライ−達人開発者への道− (2011/07/16) Jonathan Rasmusson 商品詳細を見る |
場所はいつもの横浜、アットウェアさんです。
参加者は30名くらいでしょか。
今回は特別編ということで、Microsoftの長沢さんによる、DevOpsをテーマにしたの講演がありました。
特別編ということもあり、またテーマがいま流行のDevOpsということもあり、満員御礼です。
私、ちょうどこの道場告知の2週間前くらいに、社内のDevOpsをテーマにしたワーキングに放り込まれました。
んで、DevOps勉強せなあかんなぁ、どーしよかな、とか思ってたら横浜道場の告知が！
これはまさしく俺のための道場！
ということで告知が出て、速攻申し込んだら前から2番目だった。
以下、長沢さんの口頭説明を中心に、個人メモ。
■講演 by 長沢さん
■[P.3] Developers Summit 2013 Summer
・8/1のDevelopers Summit 2013 Summerで、基調講演でDevOpsについて講演する。
[S1]DevOpsは開発現場とビジネスの間に何を生むか？ ： http://event.shoeisha.jp/detail/46/session/83/
・あと、セッションA2でも講演する。
[A2]DevOps × Enterprise ： http://event.shoeisha.jp/devsumi/20130801/session/87/
■[P.4] DevOpsがビジネスの成功を左右する時代へ
・開発だけアジリティを高くしてもしょうがない。運用も機敏に対応しないといけない。
・DevとOpsの壁が問題視されている。
・現場の立場によって何をどうしなきゃいけないかは変わる。
・ツールや自動化を導入すればいいよね、という単純な話ではない。
■[P.5] 本日の目的
・重要なのは、今から何しなきゃいけないのか、その先、半年、3年後、5年後どういう状態になっているのかを考えること。
・「運用者はいらなくなるのでは」、「開発の知識がいるのでは」といった不安が取り除ければいいかな、と思っている。
■[P.6] 本日の内容
今日は3本立てで話をする。
・ビジネス
・戦略的なIT
・DevOps
■[P.8] Customer Development
・この図は、リーンスタートアップに出てくる。
・欧米ではこれが適用できると言われている。
・カスタマーを見つけてきて検証して、本当にカスタマーと呼べるかを確認する。
・ちゃんと検証を繰り返して、しっかりとした顧客を定義して回していく。
・普通にやってて、このイテレーションが回るかを考えないといけない。
・ITの力を借りたりとかして、競合他社よりも早くやることが必要。
■[P.9] Build - Measure -Learn
・この図はリーンスタートアップのモデルを示していて、いま注目されている。
・ビジネスモデルが変わっても、このサイクルを回していることによって対応できる。
・この図は、TDDのビジネス版。
・真ん中にDevとOpsとBizがいる。
■[P.10] ビジネスのリズムの変化
・変化はあまりしないように、という考え方がある。変化を求めない。
・これからは変化に対応しないといけない。そうしないとビジネスモデルが古くなって、競合他社に負けたりお客が離れたりする。
・変化してインパクトを市場に与えることを取り入れていかなきゃいけない。
・成長し続けること。
・ビジネスを動かして検証して、育てていく。実測駆動。
・新しいチャレンジをするので、未経験に対して実践しやすいモデル。スクラムに近い。
・DevOpsはアジャイル、リーンなやり方に影響を受けている。ビジネス駆動。
■[P.11～P.14] リズム
・これまでは、開発(Dev)と運用(Ops)とビジネス(Biz)のリズムがバラバラということが多かった。
・それぞれの見直し時期が異なるとかの問題があった。
・それぞれ必ず同じリズムになるとは限らないが、ビジネス駆動を加速させるには融合せざるを得ない。
・それぞれがお互いのリズムを尊重しながら進める。
■[P.15] ビジネスのトレンド
・新技術が新たな価値を生み出すドライバとなる。
・新技術を活用して製品を作ったりサービス拡大したりして、ビジネスの進化を支える。
・利用者に直接貢献するようなビジネスモデルが増えている。
・できるだけ利用者の近い所でビジネスを起こすことが強いビジネスになる。
・デバイスとか組み込み系とか、目に見えないものが価値を提供する。
・お客さんは意識しないが、欲したことがデバイスを通じて自分のところに手に入る時代になる。
・検索して手に入れるのではなく、自然に提供される時代になる。なので利用者直接ということを意識せざるを得ない。
・エンタープライズだと、利用者はコンシューマだけではない。従業員も利用者になる。企業間連携も生まれる。
・技術的革新でビジネスが激化し、競争が激しくなる。
・なので技術を活用せざるを得ない。
・競合他社に負けないビジネスモデルをリフレッシュしながら進んで行かないといけない。
■[P.17] Microsoftが提唱している今後のアーキテクチャパターン
・利用者はデバイスから入っていくが、裏側では様々なサービスが動いている。それがContinuous Service。
・Continuous Service層により、自分たちが意識することなく情報が取得できる。外部サービスとの連携もある。
・DevOpsはこういうアーキテクチャを意識する必要がある。
・DevOpsはこれらのアーキテクチャをひっくるめて考える。
・Identity（認証）とAPIは裏で絶対絡んでくるので、意識しておかないと開発も運用も回らない。
■[P.18] ITの戦略的な役割
・一番良いのは先手必勝。
・マーケットをITの力で挽回する。
・一過性じゃなく、継続的にビジネス価値を提供する。一発屋で逃げるのはダメ。
・バランスが必要。ビジネスの賞味期限が短くなっているので、見直しが必要。
・ただ、ガバナンスを忘れてはいけない。
・コンプライアンスとビジネス品質とのバランスをとらないとけない。
・それを主導でやろうとするとすごい負担。
・なのでITの力を借りて可能な限り自動化する。あとスケールアップする。
■[P.19～P.22] ビジネスとIT
・ビジネスとITはだんだん融合して、互いに不可欠な存在になりつつある。
・ビジネスの成長をITの力を借りて盛り上げていく。
・1990年代 [ITが"便利"と認識され始めた]
- ビジネスが確立された状態で、より便利にするためにITを使うという考え。
- 技術的な意思決定はIT部門が行っていた。
・2000年代 [ITが"有効"だと認識され始めた時代]
- ITに対してビジネスパーソンが関与してくる。
- 技術的な方向性は経営者層が絡んでくる。
- QCDSが求められる時代。
・2010年代 [ITが"不可欠"と認識され始めた時代]
- ジャストインタイム(JIT)
- IT計画と投資は、顧客中心に。
- CIOから顧客寄りに権限が移行し始めた。
- 具体的にはCMOやマーケティングオフィサーに権限がどんどん移っていく。
・ワールドワイドで見ると、今は2010年代の段階に来ていて、DevOpsが必要となっている。
・ただ、なんでもかんでもDevOpsが必要なわけではない。1990年代とかはDevOpsは必要なかった。
・Information TechnologyからBusiness Terchnologyへ。
■[P.24] Road to DevOps
・昔は、ビジネスモデルが確定しやすかった。
- 長い計画を立ててリリースするのが許されていた。
- 定義を固定 → 完全に作る
・これからの時代は、ビジネスモデルが変動しやすい。
- 要求は変化するという仮定で進める。
- ただ、なんでもオンデマンドで対応するわけではない。
- ポイントは、「定期的に、計画」。不定期だと期待値がコントロールしづらくなる。
・昔と今で提供モデルが変わってきている。
■[P.26～P.30] IT = Dev + Ops
・DevOpsを説明するのに、いつもP.26の図を使う。
・大事なのはビジネスのアイデアとか課題。それをITを使っていかに克服するか。
・アイデアをソフトにして開発する必要がある。そのあと運用する必要がある。
・エンタープライズだと「開発が無い」、「パッケージカスタマイズだけ」、ということあある。
・エンタープライズは2種類ある。
①基幹システム、ERP
②カスタマーアプリケーション
・前者①は既存のパッケージを買ってきて済ませる。
・後者②は競合優位性を出すための、会社で使わないといけないアプリ。B to CのCが絡むとこがカスタマーアプリケーション。
・前者①は開発がないことがあるが、後者②は必ず開発が絡んでくる。
・DevとOpsのサイクルがうまく回って続いていると、ビジネスに対してITが貢献できている状態にある。
・実際はDevとOpsの間に壁があって進まない。
・運用と開発が分かれていると以下のような弊害が起きる。
①運用で起きたバグが開発で再現できない。。。
②開発したアプリが運用でデプロイできない。。。
・運用と開発の壁を取り払って、リズムを作っていく必要がある。
■[P.31～P.32] IT ≒ Dev + Ops
・混沌
開発がブラックボックスで誰がなにをやってるかわからない。
・重量級
承認作業がたくさんある。
⇒ 守らなきゃいけない課題があるので解決していかなきゃいけない。
■[P.33] IT = DevOps
・これは、Microsoftが出している図。
・この図が回っているとDevOpsがうまく行っている。
・この絵が持っていきたいTo Be。この図は是非覚えておいてもらうといい。
■[P.34] Why DevOps
・2本の線がある。サイクルタイムとMTTR。
■[p.35] DevOps | Why Cycle Time
サイクルタイム ＝ ビジネスアイデアが出てきてから動くソフトを出すまでの時間
- 試行（思考）するビジネスの根幹。短ければ失敗のリカバリが効く。
- 「テスト駆動ビジネス」のドライバとなる。
■[p.36] DevOps | Why MTTR
MTTR ＝ 障害が発生してから治すまでの時間
- 動かない状態が極力ないようにする。
- 壊れること前提に運用戦略を考えることが重要。
・サイクルタイムとMTTR、この２つをとにかく短くすること。これによって価値を提供し続けられる形になる。
■[P.37] What DevOps
・この図で挙げているのは代表的なもの。
・「やるべきもの」のビジネスシナリオ、運用要件をちゃんと明確にする。
・各フェーズで品質を作り込む。可能な限り本番環境に近い環境でテストを回す。
・運用に渡す際には、どの要件がそこに盛り込まれているのか、どこにバグがあるのか、そういう情報を開発から運用に渡すこと。
・よくあるのが、「開発したモノの状況がよくわからないので、頻繁なリリースが怖い」と言う状態。
→ なので、最大限の情報を渡せるようになれば限定でもリリースできたりする。
・開発のリソースを運用と共同所有することが重要。ソースコードだけでない。
・開発者が運用まで持っていく、一人が全部やる、というのも共同所有の一つ。
■[P.40] 機敏なアイデア獲得と短い計画と確認
・ビジネスシナリオをしっかりキャプチャする。
・決めたビジネスシナリオは、動くソフトウェアときちんとリンクしないといけない。そこのトレーサビリティは必須。
■[P.41～P.42] Operation Readiness
・早い段階からやることを明確にしましょう
・品質を挙げれる状態にしましょう
・本番環境に近い状況にしましょう
運用を含めたビジネスアイデアがバックログに入っていて、開発と運用を回していける。本番と近い状態でテストが回っている。トレーサビリティがとれたものがデプロイされると、状況がわかる。
■[P.43] 短いサイクルでの開発とテストの継続的実施
・長い仕掛かりはやめましょう。
・動くソフトウェアはどういうものかをしっかり見極める。
■[P.44] Just-in-Time Delivery
・ビジネスモデルがあんまり変化しないならウォーターフォールでもよい。
・スクラムの「検査と適用」のモデルが取れると良い。
■[P.46] 稼働してから本番！ビジネスの足をひっぱらない
・障害が再現しませんとか、デプロイした後は開発の仕事じゃなく運用の仕事だ、といったことがないように。
・問題の切り分けがしっかりできることが重要。
■[P.47] Mean time to Repir(MTTR)
・最近は仮想化技術で、本番と近い環境を再現できるようになってきた。
■[P.48] ビジネス／アプリ中心のシステム運用
・今のインフラとアプリの関係は、器ありきで考える。まず置き場所を決めてアプリを作って乗せる。
・先にアプリを考えて、乗せる側は自由に選べる時代にもうすぐなる。アプリ中心になる。
■[P.49] Mean Time to Repair
・開発側の問題解決フローと、運用が障害を検知してから解決するまでのフローは違う。
・これを踏まえた上で開発と運用のコラボレーションを考えていく必要がある。
・開発側は運用側の改修依頼を受けて始めて障害に気づく。障害情報が足りないなら運用側からもらう。
・開発側で問題解決しても、運用側はそれを検知できない。治ったといっても、どこが原因だったのかとかが分からない。
・開発と運用でリソースを共有してると、そういうことがなくなる。
・サイクルは全く違うが共同所有することでうまいリズムを作ることは可能。
・あるいは、開発側がまるごと運用も丸抱えするか。でもそれは大変。
■[P.50] まとめ
●DevOpsをざっくりと感じたつもりになる
・それで自分のDevOpsを考え、やるかやらないかを決める。
・サイクルの絵と、サイクルとMTTRを短くすることは覚えておいて欲しい。
●今から準備することをなんとなく感じる
・自動化でうまくやる。
・今注目されているのは、仮想化でなく、それを如何に効率よく自動で運用していくか。
Dev:基礎がため、継続的縲怐A自動化
Ops：自動管理、インフラ最適、開発の理解
●漠然とした、期待と不安を共有する
■[P.53] 宣伝：これからのデリバリーサイクルを知りたい人向けの書籍
 | アジャイルソフトウェアエンジニアリング ~ 基本概念から継続的フィードバックまで (マイクロソフト関連書) (2012/05/24) Sam Guckenheimer、Neno Loje 他 商品詳細を見る |
・@AgileSeBookBot というTwitterアカウントで定期的に呟いている。
■[P.55] TFSUG
・TFSに関係ないアジャイルとかDevOpsとかの現場に近い勉強会もたくさんやっている。
■[P.56] Are you a pig?
・有名な「ブタとニワトリ」の話。
・DevOps = DevもOpsも、みんなpig.
・We are Pig!
★感想：
タイトルに「ざっくりわかる」とありますが、確かに「ざっくり」とDevOpsを理解することができました。
具体的に「これをこうしなさい」という話はあまりなく、それよりもDevOpsの思想や心構えについてが中心ですね。
DoorKeeprに「今後のたたき台として利用してください」とありましたが、具体的なアクションを起こすのは聴講者次第！ということでしょう。
長沢さんの主張は明瞭で、プレゼンも上手く、非常に理解しやすい内容でした。
この日のお話を聞いて私が個人的に思ったのは、SIerのSEはDevOpsがある程度、あたりまえの状況にあるのではないか？ということでした。
弊社は「拝承」とか「～していただきたく」とか「この木なんの木～♪」とか、巷で良い噂をまったく聞かない某SIerなのですが、一応、SEは要件定義もするし、設計もするし、インフラ面もお守りするし、稼動後の運用・保守に至るまで面倒を見ます。
開発だけする、運用だけする、という状況は少なくとも弊社ではほとんど有り得ない。
（プログラミングを自分であんましない弊社のエンジニアをSEと呼んでいいかは置いといて）
なのでもっと単純に考えて、DevとOpsをもっともっと融合させよう！という趣旨で私はDevOpsを今のところ捉えてます。
そんなことをいろいろ考えさせられる講演で、大変参考になりました。
あと、やっぱエバンジェリストさんはお話上手ですね。。。
私も新人研修とか設計講座とかの研修講師を担当してるのですが、とても参考になりました。
皆様、ありがとうございましたー
ハンカチも扇子も忘れずに今日は帰ったぞ！・・・と思ったら、折り畳み傘を忘れてきた！ うぅぅ、道場主様、毎度スミマセン。次回、傘立てから忘れず持ち帰ります。 #agilesamurai #横浜道場
— makopi23 (@makopi23) July 23, 2013
- 関連記事
-
- 「TDD Boot Camp Tokyo 2013-07」に参加しました
- 横浜道場 特別編 「ざっくりわかる DevOps ～ ビジネスよ！これがおれたちの力だ！」に参加しました
- SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました。
