「ざっくりわかる DevOps ～ ビジネスよ！これがおれたちの力だ！」に参加してきた #agilesamurai #横浜道場
- 横浜道場 特別編 「ざっくりわかる DevOps ～ ビジネスよ！これがおれたちの力だ！」 - アジャイルサムライ読書会 横浜道場 | Doorkeeper
- 2013/07/23 #agilesamurai #横浜道場 特別編 「ざっくりわかる DevOps ～ ビジネスよ！これがおれたちの力だ！」 - Togetter
『DevOps』。こちらのキーワードも、最近IT業界で良く聞くようになって来ております。とは言うものの、中々捉えづらい部分もあったり、また実際現場に採り入れてみてはいるものの思った成果が...という方も多いのでは無いでしょうか。
そんな折、"ざっくりわかる"と題して長沢 智治さんによるDevOps入門的位置付けとも言えるような講演が『アジャイルサムライ』読書会 特別編の枠で開催されると知り、この日参加して来ました。開催会場は株式会社アットウェア様。永らく回を重ねて来た横浜道場も、残すところ後2回程でシリーズ終了となるそうです。
自己紹介
経歴・近況等の自己紹介の後、今回小物を2点長沢さんの方からご紹介。1つはこちら、KOKUYOのフィンガープレゼンター『黒曜石』。そしてもう1つはマイクロソフトの新しいタブレットPC、『Surface』。実際今回の講演もこの2つを用いて実践されており、便利且つカッコエエな〜、と思った次第でした。(Surfaceでは声でスライドの操作も出来るそうですよ！)
長沢さんは本編に入る前に、『DevOpsがビジネスを左右するような状況になって来ている。開発だけアジリティを高めても仕方がない、運用も高めなければならない状況であり、運用時の諸問題にも機敏に対応して行かなければならない。また、DevとOpsの間の壁が問題視されており、現場によって何をどうすれば良いかは異なってくる。皆さんの環境にはどんなDevopsが必要なのか、今日の話は叩き台にしてもらえればと思います。』と開発現場を取り巻く状況に軽く触れました。ちなみに当日参加者のDev:Opsの割合としては7:3くらいと言ったところでしたでしょうか。
発表資料
当日の発表資料は以下になります。(リンクをクリックして御覧ください。)
ビジネス
『リーンスタートアップ』で出てくるこの画(Customer Development:顧客開発)。
- [Iteration]では、カスタマーを見つけて、本当のカスタマーと言えるかどうかを吟味する。ここがズレていると、ビジネスがドライブしない。繰り返した上でしっかりとした顧客を定義し、[Execution]で回していく。
- でも普通にやって、これ(iteration)が回せるか？→否。
- ITのパワーを借りて検証しないと出来ない時代になって来ている。競合他社よりも早く回すにはITのパワーが必須。
もう1枚、『Build Measure Learn』の画。
- これも短いサイクルでどんどん回す必要がある。
- これらを回すことでビジネスモデルが成熟していく。
TDDはご存知でしょうか？ざっくり拡大解釈してしまうと、それのビジネス版のようなものです。まずやってみて、結果を検証し、リファクタリングしていく。
ビジネスのリズムの変化
- 今までのビジネス：モデルが確立したら安定稼働が良しとされていた。サスティナブル、変化を最小限に。
- これからのビジネス：変化に対応、変化を武器に。機を見て敏に判断する事が必要に。"実測駆動"。新しいチャレンジをしていく。未経験の部分が多い。
- 今ビジネスで起こっている事は、アジャイル・リーンな部分が大きい。
- ビジネス/開発/運用のリズム、今はどうなっている？
- 良くあるケース：3つともバラバラ。見直しを掛けるサイクルがそもそも違ったりしている。それぞれの性質、粒度が異なるので必ずしもおなじになるとは限らない。
- しかしビジネスを加速させていくためには融合せざるを得なくなる。
- サイクルが短くなり、お互いを同期・尊重していく事を模索して行かなければならなくなる。
ビジネスのトレンド
- 新たな価値を創出する新技術(これがドライバになりつつある)
- 利用者への直接的な貢献:出来るだけ利用者に近いところでビジネスを起こしていく事が強くなる秘訣。
- 多様なデバイスと活用シーン
- クラウド時代の到来
- 利用者はビジネスをそんなに意識してない。欲した事がデバイスを通じて利用者に提供される。そんな時代になって来ている。なので利用者へ直接、という点が重要となってきている。
- Enterpriseの場合、利用者にあたる人は...会社の業務担当者(従業員)。
- 競争の激化：上記のような事をやって行かないと、競争に負けてしまう。
- 技術的革新、利用者ダイレクト、競争の激化。その中でビジネスを加速させていくには...？技術は活用せざるを得ない状況に。
戦略的なIT
以下の図はマイクロソフト社が掲げる、今後の『アプリケーション開発とライフサイクル管理』に於けるアーキテクチャ構成図。
- 自社に閉じた形でサービスを利用するだけでなく、外部サービスへの接続へも絡んでくる。
- Devopsを考える場合、こういったアーキテクチャも意識しなければならない。
- 大きな枠で考える事によって、運用するにあたって、何を考えなければいけないのか。何でもかんでもクラウドやサーバに置けば良い、というものでもない。
- 色々とやらなければいけない事は多い。その中でもIdentity FederationとWeb APIs(REST/ODATA)はポイント。
ITの戦略的役割
- 先手必勝なビジネスを牽引
- マーケットに追随、マーケットをリード
- ビジネス価値を継続的に提供
- バランスの取れたビジネスアジリティ 品質/スケール/法令遵守
- 見直しをどんどんかけて行く必要がある。かといってガバナンスを忘れて良い訳では決して無い。
- 品質:ここで言うのは『ビジネスの品質』。この辺りのバランスを取らなければならない。
- 規模の経済を最大化
ビジネスとIT
両者はだんだんと融合していく形に...！(ﾊﾞﾊﾞｰﾝ)。どっちも不可欠な存在になっているのです。(ｷﾘｯ
以下の図も、長沢さん自身、良く利用されているものです。10年単位で状況を整理したもの。5年位前から、ITという言葉が、陳腐化？しBT(Business Tech-)に変わってきている節もあるようです。
- 1990年代
- ビジネスモデルは確立、要求定義はしやすい。
- ビジネスにITがインパクトをあんまり与えていない。
- 意思決定はIT部門側。
- 2000年代
- Webの時代、IT有効と見られつつある。
- ビジネスモデルに対してITが関与 / ITに対してビジネスパーソンが関与。経営者層が絡む。
- QCD(S)が非常に求められるようになって来ている。
- 2010年代
- その時々で必要な物を提供。今その時に必要な機能・サービスが求められる。
- IT計画と投資は顧客中心に。
- 予算、責任をCIO(Chief Information Officer)が色々な権限を持つと言うよりは、それが顧客にシフトしていく形に。イメージとしてはCMO(Chief Maekrting Officer)？
- 市場を見た上でそれに応じたIT投資をしていく事が求められる。
- この時代になると、Devopsをやって当たり前に。
Road to DevOps
- これまで
- 要求は定義しやすい/長い計画を立てて全体実施が許される/最終的に出来たものを提供。(でも出来た機能の65%は使われていない？とかって良く言われるけど←でもその辺もあんま関係無い。)
- これから
- これからのモデルは変化が求められる。固まってない状態から対応しなければならない。
- 継続的に、計画→リリース。定期的に優先順位の高いものから着手→リリースへ。これが不定期なものだと対応しづらくなる。期待値がコントロール出来ない。スパンが長くなると,要求を出している側も(たぶん)忘れる。
- 提供されるモデルも段々変わってきている。
DevOps
- 大事なのはビジネスのアイデアと課題。以下にそれを実現するか。実現後はより良いアイデアを出して、ビジネスの対策を立て、加速させていく。
- Dev/Opsでサイクルが周り、課題が出たら開発→提供・運用→… ビジネスに対してITが貢献出来る、となるのだが。実際は壁が立ちはだかってくる。
- ビジネスに貢献するアプリやサービスを早期にデリバリーしたい/復数のアプリを運用し、総合的なビジネス価値を提供し続けたい。
- 運用・開発環境が異なるので再現できない→直せない、という問題も。
- ビジネス・機会損失→、ひいては縮小ということを招く恐れも。
- ビジネスアイデアがあったとしても開発がブラックボックス、明瞭ではない/運用の不必要なプロセス、フットワーク軽く出来ない側面も。
- 双方の守らなければならない部分によってうまくいかない部分もやはりある。
- IT=DevOps
- Devopsが回る＝継続的デリバリーが出来る状態に。
- Why DevOps
- サイクルタイムとMTTRを出来るだけ短くする事がポイント。
- サイクルタイム: ビジネスアイデアが出てから実現・提供するまでの時間。
- MTTR: (Mean Time To Repair)障害発生から復帰までの時間。
- サイクルタイムとMTTRを出来るだけ短くする事がポイント。
- What DevOps
- 幾つかのカットでやらなければいけないこと
- ビジネスシナリオを明確に、やるべきもの、運用要件も明確に: ログを吐かないアプリケーションって無いよね...
- 明確な優先順位、短い計画と見直し
- 品質の作り込み、継続した品質確認(可能であれば本番環境に近い形で)
- 正しく、無理なくデプロイ
- 正しく、無理なく受け取り、把握…どの要件が盛り込まれているか
- 動くソフトウェアの共同所有
- 障害の切り分けと分析/連絡/追跡
- 実行可能な、意義あるフィードバック
- 勿論これ以外にも色々な課題があるが、これらを回し続けて行く事が必要。
- 切り分けを行う仕組みは発達してきつつある。
- 幾つかのカットでやらなければいけないこと
というように理想形を掲げて見るも、やはりDevとOpsを分けてしまうような様々な問題も。
機敏なアイデア獲得と短い計画と承認
以下がリンクするようにしなければならない。
- ビジネスシナリオを正しくキャプチャ、理解する事: 正しい意思決定/正しい理解/正しい期待値
- 動くソフトウェア:期待通りの振る舞い、正しい確認
- Operation Readiness(運用への備え)
- [Problem]: 運用要件を満たしていないソフトウェア
- [Solution]: 早期の要求獲得と品質の作り込み
- [Value]: ビジネス価値に到達するソフトウェアへ
以下の様な構図が理想形。
短いサイクルでの開発とテストの継続的実施
- 長〜い、仕掛かり: 手遅れ/期待値、時代遅れ
- 動くソフトウェア？: レガシーコード？それって石橋叩いてる？
- Just-in-time Delivery ...これはまさに『スクラムによるタイムボックスと検査と適応』の一枚絵。アジャイルによって得た知見と、親和性は高い。
- [Problem]: 顧客ニーズにアライン出来ない開発サイクル
- [Solution]: アジャイルプラクティスとカイゼン
- [Value]: ビジネス価値に到達するソフトウェアへ
稼働してからが本番！ビジネスの足を引っ張らない
- 障害！: 起きることを前提に.../本番を迎えたら運用の仕事でしょ？/再現しません(ｷﾘ
- 問題の切り分け？: アプリ？インフラ？/ログは？/知見溜まってる？
- Mean time ro Repair(MTTR)
- [Problem]: 運用中の障害検出と解決が極めて困難
- [Solution]: 本番稼働環境でも開発プラクティスを実践
- [Value]: MTTRの短縮
- ビジネス/アプリ中心のシステム運用
- [これまで]まず器(サーバ等)有りき、そこに対してアプリを乗せる。
- [これから]アプリを先に考えて、乗せる場所は自由に選べる時代に。App中心の時代に。
Mean time to repair - 本番稼働中の対応の最適化へ
開発側と運用側、体制なども含めて諸々違う点が。それらを踏まえた上で、どうコラボレーションしていくか。
まとめ
講演の結び。大事なのは今回学んだ事を持ち帰り、各自の現場で共有し・議論する事です！と長沢さんは強調。
そして締め。『DevOpsでは、DevもOpsも皆Pig(ブタ)さんです。お互い身を切って頑張りましょう。』とスクラムで有名な『鶏と豚』の例えを引用して講演を纏める形となりました。(※詳しくはRyuzeeさんの以下エントリをご参考に)
という訳で講演内容はここまで。『ざっくり』と銘打ってはいますが、かなり詳細に分り易く、且つ濃厚な内容だったと思います。冒頭・そして締めでも長沢さんがコメントされたように、これらを踏まえて各々の現場で、DevとOpsの側面から議論を重ね現場を見直し、改善を進めていくアクションを起こして行かないと加速するスピードについて行けなくなってしまうのだろうなぁ、という危機感を感じる部分はありました。長沢さん及びスタッフの皆様、ありがとうございました！
