読者です 読者をやめる 読者になる 読者になる

hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

DevLOVE関西『「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜』に参加してきました。

5つも発表があって盛りだくさん。 中でも気になった1つについて感想を。

AWS,DevOps絡みの話(仮)」見川 孝太さん

スライド背景のスターウォーズのレゴがかわいい。

内容の紹介

ずばりDevOpsではなくて、協力する文化をどう作り上げるかというお話。

  • Dev = 開発
  • Ops = インフラ

開発側: 仕事としては設計、開発、本番環境の構想、デプロイ、アプリケーション補修、アプリケーション運用などがある。
そんな中でインフラ側への不満として、「要求した環境にならない」「開発じゃない運用の増大」などがある。。。

インフラ側: 仕事としてはネットワーク保守(内外)、サーバ運用保守(OSまで)、セキュリティ対策、サービスの監視などがある。
インフラ側としては「不透明なアプリケーションのデプロイ」、「検証不足をネットワーク責任転化」「監視の増大」、「(ネットワークレイヤを開発のひとが)よくわかっていない要望」、「開発の理想押し付け」などの不満があった。

セグメント主義的な問題もあり、お互いに不満もあったが、どうにかしたいと思っていた。

そこで、運用負荷、環境を解決するためにAmazon Web Serviceを導入した。
AWSの導入はツールとして有用なだけでなく周辺の文化もついてくる。

  • Amazon自体の企業文化
  • コミュニティ(JAWS)

開発もインフラも基本エンジニアなので共通の話題ができ、APIベース、コードベースで使用できる。

開発側はインフラに踏み込むことができ、物理的な制約に縛られない構成を自分たちでコントロールでき、運用の増大(スケール)も自動化できる。

インフラ側はインシデント対応、火消し的な仕事ではなく新しいことを試す創造的な仕事ができる。

AWS導入でお互いの得意分野を補い合って業務効率化できました。めでたしめでたし?

ではなくビジネスレイヤーのことも考えよう。

Biz = 営業

ビジネスの成功には三者の協力が必要 本来目指しているものは同じはずなのに主とする仕事の違いで食い違いが起きる。

インシデントの対応でも

  • 営業->ユーザへの報告優先
  • 開発、インフラ->復旧優先

二者間の会話が不足していると収束した後に問題になったり

問題点:

  • 同じ技術系であるインフラと違い、共通言語がない。
    そのため現場がテクニカルなところに踏み込んで話せない。
  • 積もり積もった不満が表面化

改善:

  • 古い決め事の見直しと意識合わせ 開発・インフラが知ってる取り決めと、営業が知ってる取り決めが一致してなかった DevOpsをするということじゃなくてもお互いが同じところを目指していることを意識合わせ
    参考:The Phoenix Project

  • 壁を越えるためのスタンプカードを導入

  • 部、チームではなくプロダクトのゴール の話をもっとしましょう

目指すのは協力する文化の定着

感想

自分もこの開発とインフラの問題の開発側で同じようなことを経験してるので身にしみます。
デプロイの自動化を実現するためにこういうサーバがほしいんだ、ということを伝えてもやはりネットワークレイヤなどの知識が不足していて、「よくわかっていない要望」を出すことになってしまっていないか気をつけねばと思います。 DevOpsやアジャイル開発を追求するのは結構なことだけども、協力する文化を築き上げなければと思います。
というより、そういった開発を目指すのであればまず「仲良くなる」ことからですね。

ビジネスレイヤの人でいえばうちの会社では商品開発やマーケティングの人なのですが、やっぱりビジネスのゴールを共有することが大事だなとこの話を聞いて痛感しました。
マーケティング領域の方からは会社の目標は一つですよ!(だからマーケティングのデータ分析のためにエンジニアをこっちにください)とよく言われるのですが。。。

ビジネスレイヤの人と共通の言葉で語れる基盤を用意することもすごく重要だと思います。
別の方の発表でありましたがDSLの活用などはその役に立つのかな?
ゴールや会社全体のオペレーションをビジネスレイヤ、Dev、Opsで共有して、もっとよいプロダクトを世に出せるように頑張りたいと思いました。