もう2日経ってしまって出遅れ感満載の上、続きもののエントリの間に挟むってのもなんだなあ、って気がしていますが、こんにちわ。

タイトルの通り、渋谷くんだり行ってきました。

そもそもDevOpsってなんぞやという方はこちらで。⇒http://partake.in/events/b5472f43-5bc0-42d0-9469-dc70d7d95b24

僕はDev側で、発表者の方達と違うのは、自社サービスじゃなくて受注開発という違いはあります。

またこのエントリだけじゃないですが、あくまで私個人の意見としてみて頂ければ幸いです。（怒られた時の保険）

とりあえず全体通して思ったことと質問できなかった！事

• 他の方のツイートやブログのエントリにあるようにOps側の話が多かった
  • 開発者側のスタイルの話とかどうOps側とコミュニケーションとってるかとか聞きたかったかなと。
• Dev vs. Opsになってむっちゃギスギスしたことが無かったか
  • どうやって終結したのか
  • あっても自分たち（発表者）から話づらいとは思いますがｗ
    • 逆に一般の開発側の人への要望とかがあれば…反省します…
• 思っていたよりも自分の環境とリンクしている所が気がした
  • 自分の環境がレガシーレガシーしていると思っていたんだけど、他の会社さんでも残ってる所は残ってるんだな、と。
    • いや、だからよかったーという話ではなく。
    • やんなきゃなあと思ってた所の改善案というかその細かいステップを聞けると嬉しかったかも。

共感したとか勉強になった箇所

• 同じ方向に向く文化づくりって大事
  • 頭では分かってるんですけどね…具体的にどうやって？ってのが難しい。確かにツールを入れれば解決する話じゃないし、じゃあコミュニケーションを取ればいいって言われてもどこまで？いやもうそんな発想になってるってこと時点ダメっしょとか。でも人間だもの。みつを。
• 安定化すればOK、というわけではなく、事業を最大化するのが目的
  • 仰る通り。ぐうの音もでない。
• PV*レスポンスタイム=総応答時間をリスト化して総応答時間から対処する
  • 例えばお金に直結するような大事なページを考慮してもいいかもしれませんね。
• 最初から理想系をゴールとしない
  • スモールスタートは大事。
  • 開発者側は拡張性を持たせることの意識作りも大事。

所感

• ちょっと話は横道にそれるんですけど、「関係者各位の意見を取り入れすぎない」ってことも重要かなって思ってます。いや関係者の意見を聞くってことはもちろん大事なんですけど、そればっかり考えると進むものも進まないし、本当の目的を見失ってしまう場合もあるんじゃないかなって。「じゃあパフォーマンスチューニングとして～いれましょうか」って話になった場合、最終的なGoの決断ってDev側？Ops側？それともそうじゃないプロデューサー的な人？まあ誰でもいいんだけど、ある程度強権を発動することも大事なんじゃなかろうかと思ってます。
• またちょっと別の話なんですけど、どうすればお互いの痛みってわかるんだろうって話。それは極論お互いがお互いの仕事をしてみるしかないと。なので諸富さんがブログで仰ってるように交換留学って、どこかに弊害はでると思いますが、DevOps上は有効なんじゃないかなって思います。