2017/02/20
Developers Summit 2017 に参加してきました!
目次
こんにちは、エンジニアのあらきです。先日2/16に、Developers Summit 2017に参加してきました。
アトラスでは毎年何人かのエンジニアが参加しており、今年も4人のエンジニアが参加しました。
今回は私が参加したセッションの概要と所感を書いていきます。
Developers Summitとは
ITエンジニア向けに最新トピックを発信しているイベントです。2003年から始まり、東京では夏・冬と年に2回開催されます。
さまざまな開発ジャンルの課題に応える講演形式のセッションや展示、書籍販売もあり、参加者とコミュニティとITベンダーとの交流の場になっています。
1セッションはだいたい40分くらい。ちょっと慌ただしく感じるかもしれません。
Developers Summit 2017の概要
- 会場:目黒雅叙園(東京)
- 日程:2/16(木)、2/17(金)
- テーマ:「エンジニアとして生きる、技術の先にある現実に踏み出す」
- 裏テーマ:「ポストDevOps時代の働き方」
参加したセッションの概要と所感
【16-D-2】Elastic Stackを利用した異常検知
私が開発を担当しているConfitというサービスでElasticsearchを利用しているので、後学のために参加してきました。
概要
- Elastic社は昨年、行動分析大手のPrelertを買収した
- Prelertで提供している教師なし機械学習による異常検知が、Elastic Stackで利用できるようになった
- 現在はベータ版提供中で、2017年上半期リリースが目標
- セッションでは、ECサイトでの購買におけるブラウンアウト(瞬断)をPrelertで検出する、というデモが行われた(Elastic {ON} TOKYO 2016でも同様のデモでPrelertの紹介をしていたよう)
- 教師なし学習なので、「こういう時にエラーにしてね」ということを教え込まなくても、データさえあればすぐ始められる
【16-D-L】エンジニアが働きたい場所で働けるために、チームに必要なこと
概要
「働く場所の自由化」を推進していく中で必要なこと、についてのお話でした。
- ワークスタイル変革のために必要な要件は、「ツール・制度・風土」の3つである。サイボウズを例にあげると以下のようなもの。
- ツール
- VPN
- 持ち出しPCのICカード認証
- テレビ会議システム
- GitHub/Slack
- グループウェア
- 制度
- セキュリティ規制(PC持ち出しルール、クラウドサービス利用ルール)
- ウルトラワーク(台風や荷物受け取りなどの理由で突発的な在宅ができる制度)
- 選択型人事制度(育児、介護、通学や副業など個人の事情に応じて、勤務時間や場所を決められる制度)
- 風土
- チャレンジして改善する
- 多様性を認め合う
- 公明正大(嘘つかない、誤魔化さない、質問責任・説明責任を果たす)
- 自立
- ツール
- 3要件を満たしていくための障壁はチームによって異なるが、一つ一つ減らしていくこと
- 働く場所の自由化に対するありがちな勘違いとして、以下のようなものがある
- 働く場所の自由化は、社員のQOLのためだけ
- 福利厚生の一環
- みんなが同じ場所で働くのがいいに決まっている
- 生産性の向上、災害への対策、人材確保の観点からいっても、働く場所の自由化は会社にとって必要なこと
働く場所の自由化を必要とする人は増える
働く場所の自由化に対するありがちな勘違い、の話が特に印象に残りました。
今でこそ働く場所の自由化を認める企業も多いですが、それでも多くの人は今までの社会人経験の中で「みんなが同じ場所で働く」という働き方をしています。
そうすると「今までそのやり方でうまくやってきた」という気持ちが強く、「みんなが同じ場所で働くのがいいに決まってる」という気持ちを取り払うのは簡単ではありません。
しかし、これから社会人になる人が新人の頃から「同僚が違う場所で働いているのは、普通のこと」という感覚を持っていれば、組織の中での心理的障壁は少しずつ小さくなっていくのではないでしょうか。
セッションの中でも話がありましたが、労働人口自体が減っている中で、働く場所の自由化を必要とする人は今後増えていくでしょう。もしそうなれば、そうした人たちの受け皿になれる会社である、ということは大きな強みです。強みというよりも企業として必須要件になるかもしれません。
アトラスでもリモートワークを進めていますが、今回のセッションを通じてその必要性を再確認しました。
【16-B-3】パネルディスカッション「エンジニアが創るプロダクトの未来 ~エンジニアからプロダクトマネージャーへ~」
概要
エンジニア出身のプロダクトマネージャであることについて、様々なテーマでディスカッションが行われました。プロダクトマネージャの仕事内容やプロダクトマネージャに向いているタイプなどがテーマでした。
エンジニア出身のプロダクトマネージャーであることの強みは?というテーマでは
- 実現可能性が感覚的にわかる(突拍子も無いアイディアをエンジニアに提示することがない)
- 作らずに実現できないか?という視点でも考えられる。ソフトウェアはコードを書いた途端にバグの温床になる、ということも知っている。
- AIや機械学習などはそもそもテクノロジー自体がわからないとやっていけないが、そういうものへの抵抗がない
などの意見が挙げられました。
エンジニア出身であることは大きな強み
私の周りにいるプロダクトマネージャも皆エンジニア出身者ですが、確かに、プロダクトマネージャ自ら新しいツールや技術を試し、導入を推進しているイメージがあります。また、時にはエンジニアと一緒にコードを覗いたり、技術的な面でのアドバイスもしてくれます。
一緒に働くエンジニアにとって、そういうプロダクトマネージャは単なる「管理者」ではなく、「良きお手本であり相談相手」という認識があります。エンジニア出身のプロダクトマネージャであるということは、エンジニアと信頼関係を作っていく上で大きな強みになるのではないでしょうか。
【16-A-4】市場で勝ち続けるための品質とテストの技術
概要
2部構成のセッションでした。第2部はネットワークトラブルによりCyber Dojo以降の話が駆け足になってしまったのが少し残念でした。
- 第1部は、Lean XPというアジャイル開発手法を使ってペアプログラミング(ペアプロ)とテスト駆動開発(TDD)を進めていく方法、がテーマ
- ペアプログラミングの進め方のポイント
- ソースコードは全てペアプロで作成し、毎日ペアを替えてやる
- ペアの片方を新しい人にして、残った人は新しくペアになった人に自分の作っている機能を説明する
- これを繰り返すことで、全員が仕様に詳しくなる
- そもそもペアで書いていないコードは認めない
- そのためにgit duetを使ってログを残している
- ペア以外で作ったソースは認めないので、ルールとして全員定時で帰ることにしている。残業は一切していない。
- ペアプログラミングの進め方のポイント
- 第2部は、テスト自動化をいかに組織に定着させるか、がテーマ
- テスト自動化は習わせるより慣れさせろ
- TDDやペアプロを学ぶためのクラウドサービスCyber Dojoをぜひ使ってほしい
- ブラウザさえあればTDD・ペアプロを体感できる
- 同じ課題を複数人で解いたり、各メンバーの課題の進捗状況も管理できる
- TDDやペアプロを学ぶためのクラウドサービスCyber Dojoをぜひ使ってほしい
- テスト自動化を進めていくと、マンネリ化する時がある
- 短期の目標設定と振り返りなど、チームに適切な刺激を与え自発的な成長を促そう
- テストルール・テストコーディング規約をメンバーに作ってもらうと、自然と自分たちで考える癖がつき、自主性のあるチームが作れる
- テスト作成に集中できる環境を作ることも、テスト自動化の一環
- テスト自動化は習わせるより慣れさせろ
ソースコードは共同所有物、という意識をもつ
ペアプロを通じて「ソースコードは共同所有物」という考えを徹底させている、という話が印象に残りました。この考えは、自律的なチームを作っていく上で大事なポイントだと感じました。
全員が仕様に詳しくなるという点もそうですが、例えばバグがあった時に「この機能は○○が作った」「自分はさわっていない」という意識があると、コードではなくその機能を作った「人間」に非難の目が向きがちです。
また、良い機能を作った場合にも、その機能を作ったエンジニアだけが賞賛されがちです(エンジニアにとって自信につながるので、必ずしも悪いことではないですが)。
ソースコードは共同所有物という意識を持つことで、「良いことも悪いこともチームとしての成果であり、チームで解決していくものだ」という認識を持ちやすくなるのではないかと感じました。
最後に
今回私はDevelopers Summitに初めて参加したのですが、それぞれの会社が様々な工夫をしているのが感じられ、刺激になりました。話を直に聴けたことで「もっと改善したい」という強い想いを持って日々工夫を重ねているんだな、ということが実感を伴って伝わってきました。
また、話の中に登場するトピック(「DevOps」など)をなんとなく感じるだけでも、こういったイベントに参加する意味はあるのではないでしょうか。
夏のDevelopers Summitも楽しみです!