makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「Developers Summit 2013 Summer」に参加しました ~其の2~ 午後の部

2013/8/1(木)「Developers Summit 2013 Summer」に参加してきました。

・公式サイト
http://event.shoeisha.jp/devsumi/20130801/

・講演関連資料のまとめ
http://codezine.jp/article/detail/7305

昨日、基調講演についてブログ書きました。


今日はその続き。手元のメモをダラダラを書き起こしてみる。


■【A1】基礎からわかるDevOps
吉羽龍太郎 氏
セッション概要:http://event.shoeisha.jp/detail/46/session/84/
Togetter:http://togetter.com/li/541311

夏サミ2013【A1】基礎からわかるDevOps from Developers Summit


メモを取ったファイルがどっかいっちゃったので省略・・・
吉羽さんの講演スライド、充実してるのでそちらで。。。


■【A2】DevOps × Enterprise
長沢智治 氏
セッション概要:http://event.shoeisha.jp/detail/46/session/87/
Togetter:http://togetter.com/li/541323
夏サミ 2013 A2 セッション資料 #natsumiA2 from Tomoharu Nagasawa


■戦略的な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
Devsumi summer 2013_b2_share from グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.


■DevOpsと最近のトレンド(P.7/44)
・運用と開発が協力しあうムーブメント。
・小さなリリースをたくさんしていく、というアジャイルのメソッドを使った開発・運用の仕方。

■リーンスタートアップ(P.10/44)
・ITを企画する部門も、指標化して評価して、フィードバックしていくことが現在の流れ。

■IT系トレンド概要(P.11/44)
・企画・開発・運用の3つのトレンドがまわるのが昨今のトレンド。
・グロースハッカーは真ん中。

グロースハッカー(Growth Hacker)とは?
・プロダクトやサービスのGrowth(=成長)をhackする人たちを指すらしい。
・「ユーザー獲得担当エンジニア」などとも呼ばれているらしい。
・参考文献: IT自分戦略研究所 http://jibun.atmarkit.co.jp/lcareer01/special/gh/01/01.html

■まとめ(P.12/44)
・DevOpsは個別のプラクティスがどうこう、じゃなくて全体で考える。
・流れの原点はアジャイルだと思っている。
・アジャイルを全体にぐるぐる回していきましょう、があるのかな、と思っている。。
・アジリティが大きなテーマ設定。

■アジリティを支えるツール群(P.13/44~)
・ツールをなんで使うのか?を考える上で、セグメントが3つ(企画/開発/運用)に分かれているのがポイント。
・3つのセグメントで、それぞれ立場の違うメンバがフィードバックを求める。
・その結果をバックログとして管理するのにツールが大事になってくる。

■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
国産業務PaaSを担いで稼ぐ方法 ~SIerの生き残る道の1つとなるか? ~ from PIPED BITS Co., Ltd.



■パブリッククラウド(P.7/43)
・日本でのクラウドはキャズムを超えて、Early Majorityを超えてピークに差し掛かっているくらい。

■顧客は何を求めてる?(P.9/42)
・顧客は、業務知識を持ってるエンジニアを求める。

■事例紹介
省略

■まとめ
・クラウドベンダーを見ると、似たようなものが横にある状態。
 → 差がよくわからない。
 → でもアピール側からすると、できることをいろいろ言わないと、まな板の上に乗れない。
 → なのでユーザがきちんと選ぶ必要がある。いろいろあって、「選べること」が重要と認識する。


■【A5】黒帯デベロッパーたちにきく!「DevOpsって本当のところどうなのよ?」
大石良 氏/宍倉功一 氏/伊藤直也 氏
セッション概要:http://event.shoeisha.jp/detail/46/session/96/
Togetter:http://togetter.com/li/541332
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」 from Serverworks


■今日の見所
・スーツ派が勝つか、ギーク派が勝つか。

■宍倉さんの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というキーワードが出てきた。
・既存のやり方にストレスを感じているのをなんか変えていきたい。その1つが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)
●宍倉さん
 ①小さなところからやる
 ②自分のまわりから、お互いが連携できるところはなんだろう、と1つ1つ会話してやっていく。

●伊藤さん
・最近、クライアントからAWSを使って欲しい、アジャイルやってほしい、といったようなリクエスト増えた。
・それは、期待に答えて欲しい、というメッセージ。それ自体が目的ではない。
・どうやるかより、そもそも何がしたいのかを決めないとダメ。
・プロセスだけ効率化しても意味はない。
・そこから定義していくことが大事。


★感想:
DevOpsについて、いろんな方からいろんな観点でお話を聞くことができました。
DevとOpsが共通のメトリクスで判断をしていく話とか、Infrastructures as Codeの話とか、できるところからやっていけたらいいかな、と思ってます。
少なくとも弊社の現状では、コード書ける人ばっかじゃないので、すべてDevOpsやるのは難しいかなぁ、と。
でも、インフラ屋さんもDevOpsの概念くらいはまず理解してほしいと思う。

・・・と、いろいろ悩むのであった。

デブサミの皆様、有意義なお時間を提供いただきありがとーございました。
関連記事
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://makopi23.blog.fc2.com/tb.php/99-06902099
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad