2013年08月18日makopi23のブログmakopi23が日々の生活で感じたことを気ままに綴るブログです。Summer」に参加してきました。・公式サイトhttp://event.shoeisha.jp/devsumi/20130801/・講演関連資料のまとめhttp://codezine.jp/article/detail/7305昨日、基調講演についてブログ書きました。2週間も経ってしまいましたが、どうせ会社に聴講報告メモ出さにゃならんし、自分の復習にもなるしということで、今更。2013今日はその続き。手元のメモをダラダラを書き起こしてみる。吉羽さんの講演スライド、充実してるのでそちらで。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は関係ない、という姿勢はダメ。readiness(P.24/42)・品質を作り込んでおかないと、運用にしわ寄せが行く。・サイクルタイムの期間が長すぎたら、使われなくなる。・定期的かつ短い期間で提供する。アジャイルのプラクティスが参考になる。(P.26/42)・できるだけ本番環境にしわよせこないようにしたい。・開発の段階で、本番に近い状況で回ってる状況にしたい。Incorporated.■DevOpsと最近のトレンド(P.7/44)・運用と開発が協力しあうムーブメント。・小さなリリースをたくさんしていく、というアジャイルのメソッドを使った開発・運用の仕方。■リーンスタートアップ(P.10/44)・ITを企画する部門も、指標化して評価して、フィードバックしていくことが現在の流れ。3つのトレンドがまわるのが昨今のトレンド。・グロースハッカーは真ん中。Hacker)とは?・プロダクトやサービスのGrowth(=成長)をhackする人たちを指すらしい。・「ユーザー獲得担当エンジニア」などとも呼ばれているらしい。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だけで完結しない業務がある。日本は米国と違って、ユーザ企業側にエンジニアが少ない。受託しないといけない。■SIerの役割(P.32/44)・でも、受託は利益相反になる。■エンプラでのアジリティ(P.35/44)・顧客をフィードバックループに巻き込むのことが大事。・でも、めんどくさいじゃん。■取り組み(3)(P.39/44)・CIはお客さんにとって価値じゃないので、きちんと継続的リリースするところまで持っていくことが重要。・Q&A表をExcelで送りつけるようだと上手く行かない、と書いている。・自由なコミュニケーションが大事。■まとめ(P.42/44)・SIerが変えていこうと思わないとエンタープライズは変わらない。Majorityを超えてピークに差し掛かっているくらい。まとめ・クラウドベンダーを見ると、似たようなものが横にある状態。アピール側からすると、できることをいろいろ言わないと、まな板の上に乗れない。ユーザがきちんと選ぶ必要がある。あって、「選べること」が重要と認識する。・スーツ派が勝つか、ギーク派が勝つか。■宍倉さんのDevOps(P.12/40)・10名チームのうち、インフラ担当は1名。・最初は手作業でデプロイをしていた。・Eightをリリースする際に、インフラをすべてAWSに移行した。・運用側と開発側で何ができるかを話したところ、以下のような話が出た。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)・大丈夫です。・お互いの教育が必要。Codeと言われるが、これまでインフラ担当はプログラミングはしなかった。・でも、今はWebとかに情報が多い。・DevとOpsでペアプロとかやれば、Opsがプログラミングを勉強できる。■P.20の23に対する、伊藤さんの考え(P.22/40)・3は誤解。考え方が逆になっている。・運用担当者の頭にしかなかった暗黙知や手順書をコードで表現する。・コードをリポジトリに入れてシェアすれば、見える化した状態で保存できる。・新しい人が入ってきてもそれを流せば同じことができる。属人性を省く処方箋となる。・2についてだが、DevOpsはアジャイルの文脈と近い。・なんでもアジャイルやればいいわけではない。・DevOpsも同じ。契約上、運用と開発が分かれているのにDevOpsを無理にはやらない。・でも、やれるならやればいい。・DevOpsはキーワードが独り歩きしている。・アジャイルが今響かなくなってきているから、DevOpsというキーワードが出てきた。・既存のやり方にストレスを感じているのをなんか変えていきたい。その1つがDevOpsである。・Webサービスとか自分たちで見てて、リリース後も見ていく状況では、DevOpsはやったほうがいい。・AWSとか使うんだったら、仮想化でハードがソフトになったので、既存のやり方を疑ったほうがいい。・今はソフトになって、ハードの制約がなくなったのに、従来とやり方を変えてないのはおかしいんじゃないか。■Biz側からツッコミ(P.26/40)・DevとかOpsとか、企画営業からみたらどーでもいい。・早くアウトプットしてフィードバックを受けるにはDevOpsが必要となる。・アプリ開発とインフラ構築運用には差がある。ゆう組織にする努力は必要。・結局は何をゴールにしたいか。・Ops側が自動化して楽にしたいというのもアリだが、ビジネスのスピードを上げたいのでアジャイルは常識。そこはマネジメントの問題。・DevとOpsが同じゴールを向いて走れるようにする。DevとOpsの間を埋めるのはマネジメント。・2は、必ずしもそうではない。・これから継続的開発はあたりまえになる。・DevOpsの使えるところからやっていく。■SIにDevOpsを導入するには?(P.32/40)●宍倉さん1小さなところからやる2自分のまわりから、お互いが連携できるところはなんだろう、と1つ1つ会話してやっていく。●伊藤さん・最近、クライアントからAWSを使って欲しい、アジャイルやってほしい、といったようなリクエスト増えた。・それは、期待に答えて欲しい、というメッセージ。それ自体が目的ではない。・どうやるかより、そもそも何がしたいのかを決めないとダメ。・プロセスだけ効率化しても意味はない。・そこから定義していくことが大事。★感想:DevOpsについて、いろんな方からいろんな観点でお話を聞くことができました。Codeの話とか、できるところからやっていけたらいいかな、と思ってます。少なくとも弊社の現状では、コード書ける人ばっかじゃないので、すべてDevOpsやるのは難しいかなぁ、と。インフラ屋さんもDevOpsの概念くらいはまず理解してほしいと思う。・・・と、いろいろ悩むのであった。デブサミの皆様、有意義なお時間を提供いただきありがとーございました。コメント(0)|-->プロフィールAuthor:makopi23某メーカーでソフトウェアエンジニアやってます。趣味はバスケ、筋トレ、プログラミングなどなど。