スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

Developers Summit 2014 1日目

Developers Summit 2014の1日目に参加しました。

少しずつ印象に残った箇所の感想を。(書けたところまで。)

参加したセッション
13-A-1 クラウドがもたらした多様な破壊と想像(新野 淳一さん、玉川 憲さん、他)
13-E-3 クラウド時代の環境構築・デプロイ自動化戦略(吉羽 龍太郎さん)
13-C-4 iOSにAndroid、百花繚乱モバイル開発環境を比較する(細川 淳さん)
13-A-5 成功と失敗の狭間に横たわる2つのマネジメント(中村 洋さん)
13-A-6 Mobageを支えるテストエンジニアリング(中川 勝樹さん)
13-B-7 何故クックパッドのサービス開発は日々進化しているのか(庄司 嘉織さん)

13-A-1 クラウドがもたらした多様な破壊と想像(新野 淳一さん、玉川 憲さん、他)
クラウドが破壊しそうなものと創造するものを、
エンタープライズ・スタートアップ双方の立場から3名ずつ話を伺うという、豪華な内容。

 破壊しそうなもの
  従来型のSI
   売り上げ維持には、短期で多くの案件をこなす
   中小企業でも大企業並みの仕事ができる
  労働集約的なシステム運用
   運用もプログラミングへ、Chefなどの自動化ツールが必須
  オンプレミス、パッケージソフトウェア

 創造するもの
  サービスモデル
   パッケージ展開は難しいものがサービスによってグローバルで勝負できる
   DevOps的なオペレーションがカギ
  ビッグデータの活用
  モバイルを含むマルチデバイス展開
  活発なコミュニティによる個人の成長
   クラウド活用には多数の技術知識が求められる。
   これらを会社や先輩が教えてくれますか?
   変化が激しく多様な技術は、OJTや社内教育だけで身につけられる時代は終わろうとしている
   勉強会、ブログ、SNSなど、コミュニティが個人の成長につながる時代がやってきた

 我々は、クラウドによる破壊から逃れて創造をしよう

サイバーワークス 大石さん
 いつもの切腹ネタから。
 時間のかかる旧型SIを破壊し、クラウド型SIを創造する、という内容。
 営業と技術の境目がなくなりつつある。

⇒ドラッカーの「明日というものは、平凡な仕事をしている無名の人たちによって今日つくられる。」を引用しつつ、エンジニアに希望を与える話はうまい。そういう話だと知っていても、感動。
 また、最近エンタープライズのオーダーが多く来ているが、エンタープライズ・サービス2つの世界の「橋渡し」をどうやっていくかが、勝負どころという内容は、結構共感できる方が多い内容ではないだろうか。

13-E-3 クラウド時代の環境構築・デプロイ自動化戦略(吉羽 龍太郎さん)
昨年のワンクリック・デプロイの内容に近いが、アマゾン所属になったところで、クラウドと関連づけたセッション。
(クラウドだからこそ)多数の設定を自動化してリスクを減らす。
クラウドならではの解決方法(一時的にサーバーを複数系統たてて一気に全部入れ替える)なども紹介されていた。

13-C-4 iOSにAndroid、百花繚乱モバイル開発環境を比較する(細川 淳さん)
あまり俯瞰的にモバイル開発環境をみてきたことがなかったが、実際に触ってきた経験談を聞くことができ、参考になったセッション。

⇒どうしても私は両方をネイティブで作ってしまいがちだけれども、みんながそれを受け入れられる訳ではないから、ハイブリッドもこれからはウォッチしていくいくつもり。

13-A-5 成功と失敗の狭間に横たわる2つのマネジメント(中村氏)資料
期待マネジメントとモチベーションマネジメントの2つを取り上げる、シンプルな構成。

期待マネジメントは「関係者が互いに持っている期待を明らかにし適切に調整する」こと。
ここまでやってくれる「はず」と思っていたところがすり合っていないと、うまくいかない。
お互いの期待を表明して摺り合わせる。関係者全員と、定期的に。
ドラッガー風エクササイズで問うてみる。

モチベーションマネジメントは「関係者のやる気(士気)を安定して、目標に向かうようにする」こと。
モチベーションは何気ないことで乱高下するし、人によって「鍵穴」は違うのだけれど、
マネジメントできるのは自分自身。周りは手助けしかできない。

褒めるのではなく「一緒に喜ぶ」
その先にある光景を一緒に見に行く、語る(共感できていることが前提)

Actionとして、周囲への期待を表明し、逆に周囲からの期待を聞くこと。

⇒昨年のDevLOVE現場甲子園の内容がさらに進化して登場。
 スライドの写真で、おそらくチーム内でAction部分を行ったと思われるボードがあったのだけれど、
 ああ、あれはやってみたいなと思う。
 (ユーザーだったり、同じチームでもやり方を選ぶメンバーはいそうですが。)
 もっとも、それをやるための期待を表明しても、それをそのまま受け取っているかは分からない訳で、
 いやおれはそんなこと期待されても、というのはありそう。

13-B-7 何故クックパッドのサービス開発は日々進化しているのか(庄司 嘉織さん)
実際の開発現場の話に始まり、最終的には「文化の共有」が大事という話(と解釈)。

 実際の開発現場
  model数1,136。気が狂ってる。どうやって安定して動かしているか?
  設計中の議論がissuesで管理され、一目瞭然。
  デザイナーもPull Request。
  ユーザーサポートもGithubで。

 文化
  社員ひとりひとりにユーザーがいる。
  社外の開発者に貢献することが求められている。
  情報共有。
  なるべくルールを作らない。ルールにしない。
  それが正しいと思ったら行動する。

 「文化を共有し信頼し実行」

⇒個々の内容は、そのまま自分の現場にというわけにはいきませんが、よい「文化の共有」ができると、こういういいことがあるのだ、というのは伝わってくる。そのために、とっても努力しているのだろうなと。
 説明の中で、金曜日Deploy禁止というのがあったけれど、自分のPJもやっているので親近感。土日はしっかり休むのは基本かも。それにしても、ひきつけられるプレゼン・・・。

コメント

非公開コメント
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。