・公式サイト
http://event.shoeisha.jp/devsumi/20130801/
・講演関連資料のまとめ
http://codezine.jp/article/detail/7305
昨日、基調講演についてブログ書きました。
「Developers Summit 2013 Summer」に参加しました ～其の１～ 基調講演 http://t.co/JWqsFA27ys 2週間も経ってしまいましたが、どうせ会社に聴講報告メモ出さにゃならんし、自分の復習にもなるしということで、今更。
— makopi23 (@makopi23) August 15, 2013
今日はその続き。手元のメモをダラダラを書き起こしてみる。
■【A1】基礎からわかるDevOps
吉羽龍太郎 氏
セッション概要：http://event.shoeisha.jp/detail/46/session/84/
Togetter：http://togetter.com/li/541311
メモを取ったファイルがどっかいっちゃったので省略・・・
吉羽さんの講演スライド、充実してるのでそちらで。。。
■【A2】DevOps × Enterprise
長沢智治 氏
セッション概要：http://event.shoeisha.jp/detail/46/session/87/
Togetter：http://togetter.com/li/541323
■戦略的なITがビジネスの成功を左右する時代へ（P.5/42～）
・DevOpsはビジネスからの要請である。
・ビジネスアジリティに対応するのにITの力が必要である。
・IT自身もアジリティを意識しないといけない。
・それでビジネスに変化を与えないといけない。
■ビジネスモデル（P.8/42）
・今は、ITの力を使ってビジネスを立ち上げる時代。
■意思決定（P.9/42）
・昔は、IT部門はコストセンターだった。
・今の時代は経営者は当たり前に絡んでいる。ビジネスの相手の動向に応じて状況が変わる時代。
・今はIT部門だけの領域ではない。
■エンタープライズアプリの進化（P.12/42）
・アプリの進化について見ていくと、「基礎体力的なIT」と「攻めのIT」の2種類がある。
・前者（基礎体力的なIT）はパッケージカスタマイズが代表例。
→ これは他社もやっている。長い人月のサイクルでコンテンツを蓄積していくタイプ。
→ 今は「基礎体力的なIT」だけでは勝てない。
→ 競合他社に勝つビジネス、やったことないビジネスにチャレンジする必要がある。
・欧米では、他社に勝つために投資している。それをカスタムアプリケーションと呼んでいる。（攻めのIT）
■エンタープライズのITのユーザー（P.13/42）
・ユーザはコンシューマだけじゃなく、従業員も入る。
・より最適な形でコミュニケーション、コラボレーションして事業を推進しなくてはならない。
・「それってスタートアップでやってる事だよね」とか「エンタープライズだと適用できないよね」という声が必ず挙がる。
・でも、それが段々スタンダードになる。
・エンプラでもDevOpsやらないと勝てないよね、という事例が増えている。
■ムーブメントはすでにエンタープライズに（P.14/42）
・エンプラのITは、インフラの自動化は進んでいる。
・仮想化するだけじゃなく、上手く使っていくとこまで来ている。
・パブリッククラウドとプライベートクラウドをシームレスに連携させている。
・インフラは整っている前提で、アプリでどう価値を生むかを考えていく段階。
■DevOps（P.16/42）
・Microsoftは2011/6からDevOpsを使い始めている。
・継続価値のデリバリーを提供している。
・継続的フィードバックのコンセプト。
■Ops（P.18/2）
・システムの自動管理はもうできている。
・運用は長期戦。SLAとかが絡んだり、いかに継続するかが重要となる。
・最近は、クラウドとか自動バックアップが充実してるので、ディスクが壊れたとかは気にしなくなってきた。
・それよりも気にするのは、「アプリが使えなくなった」。アプリが動かない、というのはなかなか治らない。
・Opsから見ると、自動管理の中にアプリが乗り切れてない。
■Dev（P.19/42）
・「開発ってブラックボックスだよね」、「出てきたものは使われないものだよね」となってしまいがち。
・でも、ビジネすにはアプリが必須。重要なのは、変化に如何に対応するか。
・作って終わり、というものはない。ビジネスモデルが変化する時代なので、アプリも変わり続ける必要がある。
■P.20/42
・DevとOpsの立ち位置にはギャップがあるので、それを理解することが大事。
・共通のゴールを持つこと、自動化や共同所有が大事。
■P.22/42
・DevOpsには課題がたくさんある
・私はDev側だからOpsは関係ない、という姿勢はダメ。
■Operations readiness（P.24/42）
・品質を作り込んでおかないと、運用にしわ寄せが行く。
・サイクルタイムの期間が長すぎたら、使われなくなる。
・定期的かつ短い期間で提供する。アジャイルのプラクティスが参考になる。
■Mean Time To Repair - MTTR （P.26/42）
・できるだけ本番環境にしわよせこないようにしたい。
・開発の段階で、本番に近い状況で回ってる状況にしたい。
■【B3】DevとCustomersの協業を目指すサステイナブルSIの進め方
鈴木雄介 氏
セッション概要：http://event.shoeisha.jp/detail/46/session/91/
Togetter：http://togetter.com/li/541339
■DevOpsと最近のトレンド（P.7/44）
・運用と開発が協力しあうムーブメント。
・小さなリリースをたくさんしていく、というアジャイルのメソッドを使った開発・運用の仕方。
■リーンスタートアップ（P.10/44）
・ITを企画する部門も、指標化して評価して、フィードバックしていくことが現在の流れ。
■IT系トレンド概要（P.11/44）
・企画・開発・運用の３つのトレンドがまわるのが昨今のトレンド。
・グロースハッカーは真ん中。
グロースハッカー（Growth Hacker）とは？
・プロダクトやサービスのGrowth（＝成長）をhackする人たちを指すらしい。
・「ユーザー獲得担当エンジニア」などとも呼ばれているらしい。
・参考文献： IT自分戦略研究所 http://jibun.atmarkit.co.jp/lcareer01/special/gh/01/01.html
■まとめ（P.12/44）
・DevOpsは個別のプラクティスがどうこう、じゃなくて全体で考える。
・流れの原点はアジャイルだと思っている。
・アジャイルを全体にぐるぐる回していきましょう、があるのかな、と思っている。。
・アジリティが大きなテーマ設定。
■アジリティを支えるツール群（P.13/44～）
・ツールをなんで使うのか？を考える上で、セグメントが３つ（企画/開発/運用）に分かれているのがポイント。
・３つのセグメントで、それぞれ立場の違うメンバがフィードバックを求める。
・その結果をバックログとして管理するのにツールが大事になってくる。
■Atlassian製品の紹介（P.18/44～）
・（省略）
■エンタープライズはどうなんだ？（P.30/44）
・ITサービスのアジリティを出して行く時に、エンタープライズでどうやっていくのか。
■エンタープライズ業界（P.32/44）
・ITだけで完結しない業務がある。
■エンジニアの配置（P.33/44）
・IPAの調査結果： 日本は米国と違って、ユーザ企業側にエンジニアが少ない。
→ なので、受託しないといけない。
■SIerの役割（P.32/44）
・でも、受託は利益相反になる。
■エンプラでのアジリティ（P.35/44）
・顧客をフィードバックループに巻き込むのことが大事。
・でも、めんどくさいじゃん。
■取り組み(3)（P.39/44）
・CIはお客さんにとって価値じゃないので、きちんと継続的リリースするところまで持っていくことが重要。
■組織パターン（P.41/44）
・4.2.6節「顧客たちを巻き込め」
・Q&A表をExcelで送りつけるようだと上手く行かない、と書いている。
・自由なコミュニケーションが大事。
■まとめ（P.42/44）
・SIerが変えていこうと思わないとエンタープライズは変わらない。
■【B4】国産業務PaaSを担いで稼ぐ方法 ～SIerの生き残る道の1つとなるか？ ～
吉田雄哉 氏/林哲也 氏/安立雄亮 氏
セッション概要：http://event.shoeisha.jp/detail/46/session/94/
Togetter：http://togetter.com/li/541343
■パブリッククラウド（P.7/43）
・日本でのクラウドはキャズムを超えて、Early Majorityを超えてピークに差し掛かっているくらい。
■顧客は何を求めてる？（P.9/42）
・顧客は、業務知識を持ってるエンジニアを求める。
■事例紹介
省略
■まとめ
・クラウドベンダーを見ると、似たようなものが横にある状態。
→ 差がよくわからない。
→ でもアピール側からすると、できることをいろいろ言わないと、まな板の上に乗れない。
→ なのでユーザがきちんと選ぶ必要がある。いろいろあって、「選べること」が重要と認識する。
■【A5】黒帯デベロッパーたちにきく！「DevOpsって本当のところどうなのよ？」
大石良 氏/宍倉功一 氏/伊藤直也 氏
セッション概要：http://event.shoeisha.jp/detail/46/session/96/
Togetter：http://togetter.com/li/541332
■今日の見所
・スーツ派が勝つか、ギーク派が勝つか。
■宍倉さんのDevOps（P.12/40）
・10名チームのうち、インフラ担当は1名。
・最初は手作業でデプロイをしていた。
・Eightをリリースする際に、インフラをすべてAWSに移行した。
・運用側と開発側で何ができるかを話したところ、以下のような話が出た。
- EC2インスタンスを自動で構築したい
- デプロイを簡略化したい
→ 3週間で運用の仕組みを考えた。大石さんのところに相談した。
・Chefとかを連携させた。そこがスタート。
・開発側と運用側が同じツールを見るようにしている。
→ お互い有用な情報を出す自前のツールを作って、シンプルに見せれるようにした。
■伊藤直也さんのDevOps（P.14/40）
・はてなで、二人か三人でサーバ1,000台を担当。
・最初は手作業でやってたが、追いつかなくなった。
・開発の要望に運用が答えられなくなって、DevとOpsに距離ができた。
・データセンターに繋げばOSのインストールとか自動でやってくれるツールを導入してから、楽になった。
・インフラを自動化することをやって当たり前の考えになった。
・はてなCTOの田中さんがpuppetに着目した。
・「テスト駆動インフラ構築」は宮下さんが2007年に公演してて、2009年のFlickerの発表より前からあった。
■DevOpsの定義（P.15/40）
・DevとOpsがくっついて、アプリの文脈を取り入れてやっていきましょう。
・DevとOpsの溝をなくして、同じ方向を向いて走りましょう。
・今は、Chefとかpuppetとかを使ってやっていきましょう、という狭い話が多い。
・今はクラウドが当たり前になって、サーバの上げ下げや手動構築が大変になった。
・サーバの構築機会が劇的に増えた。なのでDevOpsを意識する場面が増えた。
■宍倉さんにとってのDevOpsのメリット
・開発に対しての品質とかスピードにメリットがある。
・短期間の間にリリースしてフィードバックを得て次に活かすか、が重要。
・DevとOpsで、互いにツールを理解する文化ができて、スピードが加速することができるところがメリット。
・工夫としては、DevとOpsの席を物理的に近くするようにした。
・あと、仕様会議もDevとOpsが話しあって進めるようにした。
■問題提起（P.19/40）
・DevOpsが良いのはわかったけど、使われないのには理由があるはず。
・現実として、開発と運用って契約が分かれてたりするので、そこがネックとか。
■「DevOpsってハードル高すぎない？」という意見に対する、宍倉さんの考え（P.21/40）
・大丈夫です。
・お互いの教育が必要。
・Infrastructure as Codeと言われるが、これまでインフラ担当はプログラミングはしなかった。
・でも、今はWebとかに情報が多い。
・DevとOpsでペアプロとかやれば、Opsがプログラミングを勉強できる。
■P.20の②③に対する、伊藤さんの考え（P.22/40）
・③は誤解。考え方が逆になっている。
・運用担当者の頭にしかなかった暗黙知や手順書をコードで表現する。
・コードをリポジトリに入れてシェアすれば、見える化した状態で保存できる。
・新しい人が入ってきてもそれを流せば同じことができる。属人性を省く処方箋となる。
・②についてだが、DevOpsはアジャイルの文脈と近い。
・なんでもアジャイルやればいいわけではない。
・DevOpsも同じ。契約上、運用と開発が分かれているのにDevOpsを無理にはやらない。
・でも、やれるならやればいい。
・DevOpsはキーワードが独り歩きしている。
・アジャイルが今響かなくなってきているから、DevOpsというキーワードが出てきた。
・既存のやり方にストレスを感じているのをなんか変えていきたい。その１つがDevOpsである。
・Webサービスとか自分たちで見てて、リリース後も見ていく状況では、DevOpsはやったほうがいい。
・AWSとか使うんだったら、仮想化でハードがソフトになったので、既存のやり方を疑ったほうがいい。
・今はソフトになって、ハードの制約がなくなったのに、従来とやり方を変えてないのはおかしいんじゃないか。
■Biz側からツッコミ（P.26/40）
・DevとかOpsとか、企画営業からみたらどーでもいい。なんかメリットあるのか？
■宍倉さんの回答
・早くアウトプットしてフィードバックを受けるにはDevOpsが必要となる。
■Biz側からのツッコミ（P.28/40）
①予算が開発と運用で分かれていた時どーする？
②DevOpsってサービス開発にしか使えないんじゃ？
■伊藤さんの回答
・①はそのとおり。
・アプリ開発とインフラ構築運用には差がある。そーゆう組織にする努力は必要。
・結局は何をゴールにしたいか。
・Ops側が自動化して楽にしたいというのもアリだが、ビジネスのスピードを上げたいのでアジャイルは常識。
・ゴールはそこ。そこはマネジメントの問題。
・DevとOpsが同じゴールを向いて走れるようにする。DevとOpsの間を埋めるのはマネジメント。
・②は、必ずしもそうではない。
・これから継続的開発はあたりまえになる。
・DevOpsの使えるところからやっていく。
■SIにDevOpsを導入するには？（P.32/40）
●宍倉さん
①小さなところからやる
②自分のまわりから、お互いが連携できるところはなんだろう、と１つ１つ会話してやっていく。
●伊藤さん
・最近、クライアントからAWSを使って欲しい、アジャイルやってほしい、といったようなリクエスト増えた。
・それは、期待に答えて欲しい、というメッセージ。それ自体が目的ではない。
・どうやるかより、そもそも何がしたいのかを決めないとダメ。
・プロセスだけ効率化しても意味はない。
・そこから定義していくことが大事。
★感想：
DevOpsについて、いろんな方からいろんな観点でお話を聞くことができました。
DevとOpsが共通のメトリクスで判断をしていく話とか、Infrastructures as Codeの話とか、できるところからやっていけたらいいかな、と思ってます。
少なくとも弊社の現状では、コード書ける人ばっかじゃないので、すべてDevOpsやるのは難しいかなぁ、と。
でも、インフラ屋さんもDevOpsの概念くらいはまず理解してほしいと思う。
・・・と、いろいろ悩むのであった。
デブサミの皆様、有意義なお時間を提供いただきありがとーございました。
- 関連記事
-
- "勉強会「HerokuではじめるRailsプログラミング入門 （テキスト輪読）」 第5章 モデルとテーブル"に参加しました
- 「Developers Summit 2013 Summer」に参加しました ～其の２～ 午後の部
- 「Developers Summit 2013 Summer」に参加しました ～其の１～ 基調講演
