デブサミ2017summer のレポート（と呼べるのかは謎）

# 何を書いている？
2017/07/28開催のデブサミ2017に初参加してきたので
そこで感じたことを、自分なりに綴っていきたいと思います
セッションの詳しい内容については、公開資料があったのでそちらをご覧ください（タイトルにリンクつけてます）

## デブサミとは？
正式名称は **Developers Summit 2017 Summer**

毎回テーマが決まっていて、それに合わせた情報交換がなされています
今回は **エンジニアコミュニティが推進する、新しい企業文化と開発の現場**

主に登壇者が発表を行うセッションに参加して、ノウハウや事例だったりを聞けて、学べる場
他には、スポンサー企業のブースがいくつか出店しているので、そういったものにもふれあえる感じ

## 参加したセッションと、そのレポート（と呼べるのかは謎）

###### [エンジニアコミュニティを推進する企業文化 ～楽天での5年間のコミュニティ活動・社内勉強会からみえてきたこと～](https://speakerdeck.com/kawaguti/engineer-community)

登壇者：川口さん

以前勤めていた会社で、コードの管理やプログラミングの経験が浅い人に対する教育や
業務の引き継ぎに困っていた川口さんが、それを解決した方法と
現在勤めている会社でのコードの管理や勉強会・コミュニティを運営する際のコツをお話してくださいました

■個人 to 個人でコードの管理を引き継ぐのは難しい
・チームで引き継げばいい
・3種の神器（参照：達人プログラマー）を導入してみた

■勉強会開いてみたけど、めっちゃ大変
・モチベーション・スケジューリング・場所・人集めには、コツがいる（資料へ）
・上司との関係をうまく保たないと、勉強会すら開かせてもらえない（最低でも停戦状態に…）
　→　対人関係は重要。でも商売とかプロジェクトのコツと大差ないよ

■そしてわかった、**チーム単位での引き継ぎ**
・業務は引き継げるけど、スキルはすぐには引き継げない
　→　常に全て引き継げるようにするために、チームで引き継ぐ形になった
・チームで引き継げば皆がノウハウを学べるし、誰かが抜けても問題ない

■”**オーラの泉エフェクト**”大事（↓言葉自体はわからないけど、中身はとても大事だと思った）
・自分以外の他者がやっていれば、それは普通になる

* 所感

普段勉強会やコミュニティを複数運営しているだけあって、聞きやすかったです。とても。
運営未経験者の僕でも、失敗談や成功のコツなどをイメージできました。
自分がすぐに開催する側にはならないだろうけど、自分にもできるかもなんて思える充実した講演でした。

---
###### [Yahoo! JAPANのコミュニティが生み出す価値](https://www.slideshare.net/techblogyahoo/yahoo-japan-78334100)

登壇者：善積さん

社内コミュニティが活発化した背景と、運営のコツをお話してくださいました
サンドイッチもらえた＼(^o^)／


■企業がコミュニティを形成する目的
・**採用**
・**成長**（今回の内容はこっち）

■出面の増加によるリソース不足
・2008年：PC/ガラケー
　→　採用はWEBエンジニアのみ
・現在：PC/iOS/Android/スマホWEB
　→　それぞれがチームで開発している
・数年後には、さらに幅広い出面になって、リソースが追いつかなくなるかも
　→　価値のあるプロダクトを継続して提供することが難しくなっていく…

■上記の状況を打開するために、社外のコミュニティに頼ってみるのはどうか？
・自分たちの課題の解決になるとは限らない
・行った人と行かなかった人とのギャップが生まれる
・領域をまたぎにくい…
　→　企業自身がコミュニティを形成するのはどうだろう？

■課題を解決することを目的にするコミュニティ
　→　**外に行くだけでは解決できない課題を解決するコミュニティを形成する！**

■社内コミュニティ運営の留意点
・課題を解決する場として定着させる
　→　勉強しに行くのではなく、課題を解決しにいけるように（勉強は手段。あくまでも課題を解決したいから勉強する）
・縦軸の領域をまたげるようにする
　→　イベント運営は領域をまたいだメンバーで行う（例：デザイナーがエンジニアの課題を把握し、解決）

■社内コミュニティの運営を実現するうえで乗り越えたこと
・オープンに開催する（会議室は参加しづらい。人目につくところで開催する）
・小さな成果をとにかく拡散する(チャットとかでも全然OK)

■課題を解決するコミュニティで生まれたもの
・バーティカルな領域をまたげそうな成果を発揮
・導入すべきツールの意思決定(例：購買チームが現場のニーズを普段から知ることで、より良いツール選定ができる)

**抱えている課題があればコミュニティで解決を!!!!**

* 所感

絵文字使われていて、親しみやすく見やすい資料でした。Yahooっぽい。
同じ領域のなかでは解決できない課題も、縦軸の領域を超えてコミュニティを形成していくことで
別視点からの見方やアプローチで課題を解決できるコミュニティを形成できるもの。
割と僕の勤める会社では日頃から行われている気がしていますが、具体的な事例を聞くことで学ぶことも多かったです。

---
###### [コミュニティ活動がもたらす自身と会社への変革](https://speakerdeck.com/konparu/komiyuniteihuo-dong-gamotarasuzi-shen-tohui-she-hefalsebian-ge)

登壇者：金春さん（苗字珍しいすごい。AWSの日本コミュニティ（JAWS-UG）の代表もしたことあるすごい人）

コミュニティに参加いアウトプットすることで個人と会社に何が起こるのか
金春さんに実際に起こったこととその背景をお話してくださいました

■コミュニティに対するはじめの印象
・内輪ノリが激しい。メリットなさそうだし、あまりいい印象ではなかった
・2011年にAWSのコミュニティに参加してみた　→　勉強になるな〜。>> また参加しようかな。 >> 楽しいいい！

■コミュニティに参加してみて感じたこと
①**登壇は勉強になる**
・大したこと話してないけど感謝された（めっちゃ嬉しかった）
②**運営は楽しい**
・社外の友達も増える（日本全国に！）
・大人の文化祭という感じのワクワク感
③**アウトプットできる人が大切**
・アウトプットする人にはチャンスが来る(誰か見てるし、世の中がそういう人を求めている)
④**エンジニアにとってコミュニティは成長エンジン**
・自分のポジションを明確にしてくれる
・リスクを取れる状況を作り出せる

■コミュニティ開催にあたって、コミットした方がいいこと
・ビジョンの明確化
・開催情報の確約
・ルールの明文化

■この様なコミットを続けていると
・**ビジネスにも変化が出てきて、個人でも会社でも受ける仕事も多くなった！**
・自身の信用度(この人が言うなら正しい的な)もあがった
・**コミュニティから採用(うちにおいでよ)とかもできるように**（つよい）
・社内の雰囲気も変わった(コミュニティ出身の人は熱い)

■コミュニティの価値
・人はいつでも何かを変えたいと思っている
・でも、何かを変えるにはリスクを取る必要がある
・**アウトプットしている人は食いっぱぐれない**（声をあげれば、誘ってくれる）
　→　だからリスクをとって、やりたいことや、何かを変える行動を起こすことができる

* 所感

コミュニティにコミットすることで、エンジニアとして成長できる。
と具体的な事例と共に紹介してくれたので、妄想が広がりました。
自分はエンジニアになって1年だけど、早めにこういうの聞けてよかったと思っています。
新人のエンジニアさんには聞いて欲しい内容です。
今までほぼコミュニティには参加してきませんでしたが、挑戦してみるのもいいかも。（登壇するほどの度胸はない）

---
###### [モンスターストライクにおけるDevOps(SRE)の取り組み 〜世界累計利用者数4,000万人に至るまでの絶え間ないインフラ改善〜](https://www.slideshare.net/secret/tW7zzhmjIXGDmq)

登壇者：伊藤さん

XFLAG（モンスト枠）でのチーム内の、SREの事例とその所感をお話してくださいました

■一般的なSREって？
・運用業務は20~70%で遷移
・運用メインではない
・課題をソフトウェアエンジニアリングで解決する
・開発運用との境界線がない
　→　あれ？これってDevOpsと同じじゃ？
・SREの方が定義安定している
　→　が、実際は呼び方の違い程度

■XFLAGでのSRE
①構成
・マネージャーいない
・タスクのお願いはできるだけしない

②ミッション
・イベント等でスパイクするトラフィックを捌けるシステムにする
・システムの運用

③よかったこと
・開発者はインフラ周りが得意ではないが、知恵の横展開ができた

■XFLAGのOnCall
・当番は1週間交代
・アラートから20分以内に対応を開始できるように
・アラートは平均3.9回/週（減ったらしい）
・PagerDuty使ってるよ

■実際にチームでやったこと例
①DBの水平分割
・14億件のレコードで圧迫されていたDBをshardingで解決した（難しかった…）

②おまけ
・明確なコードレビュワーいない
・それぞれが互いのコードをレビューしているよ

■まとめ
・作って終わりじゃない（生かされるものをつくることが使命）
・自分たちの目標を達成することだけにこだわらない（KPIの設定・上司の理解も必要）
・やりたいことは事業をすること（何があってもそれをブロックしない。メリットがあれば全力でそれを支える）

* 所感

言葉自体を耳にしたことはあるけれど、SREを実際にやっている事例を聞いたのは初めてでした。
弊社では普段DevOpsをやっているのですが、冒頭で言っていた通りでそんなに変わりはないと感じました。
何よりユーザがとてつもなく多いサービスを全力で支えているチームはかっこいいなと感心しました。事例も規模が違う…
モンストは個人的に大好きだからセッション参加したけど、モンストに関するお話はほぼなしで少し物足りなかったですw

---
###### 組織と文化のリファクタリング

登壇者：海野さん・内山さん

海野さんが **[組織のリファクタリング](https://speakerdeck.com/livesense/kurieitazu-zhi-falserihuakutaringu)** として、どうやってクリエイター組織を再編したか
内山さんが **[文化のリファクタリング](https://speakerdeck.com/livesense/wen-hua-falserihuakutaringu)** と題して、社内勉強会での事例をお話してくださいました。

といいつつ、僕自身がこの組織に属しているので
感想だけ書きたいと思いますw

* 所感

僕自身、組織のリファクタリングの記事にある怒涛の再編期間をメンバーとして過ごしました。
正直この講演で話していたこと全てを知っていた訳ではないですが、振り返るとそういう事だったのかと考えさせられます。
確かに事業部長の権限が強い影響で、現場が混乱するみたいなことは多々ありました。
それを権限の程よい譲渡という形でリファクタリングした後は
現場の意見も反映されてより自立した組織になれたと感じています。
評価制度についても
僕自身がビジネスからエンジニアに転身しているので、ビジネス側として評価されることはないだろうけど
元々エンジニアとして仕事をしている人と同じ評価基準っていうのも中々厳しいよなあと思っていました。
それを明文化してもらったので、自分の目指すところがより明確になって業務にも取り組みやすくなったと実感しています。

勉強会のリファクタリングは、マンネリ化してしまったものを
趣旨は変えずに中身をリファクタリングすることで再生させていった過程が素晴らしいなと思いました。
これまで開催されていることは知っていて参加はしていなかったけど、参加してみようかな。。。！

## 総括

デブサミは初参加でしたが、とても充実した時間を過ごせたし、自分の為になる話ばかりで終始頷いていました笑
今回のテーマでもある**コミュニティ**。
社内コミュニティにしろ、外部のコミュニティにしろ
エンジニアにとって勉強・成長・採用・交流。ほんとに様々なメリットがあって
それを頭ではぼんやりと認識してはいましたが、実際の事例を聞くことでしっかりイメージできましたし
ノウハウも学べた気がしています。

僕自身はあまりコミュニティとか勉強会とかに参加する機会があまりなかったので（デブサミも初参加レベル）
今回のお話をきっかけにいろいろ挑戦してみようかなと思いましたし、そう思えた事が一番大きいと思っています。
自分の場合はアウトプットがとても苦手なので
そういったこともコミュニティや勉強会に参加することで成長できそうかなって思えました。
まずは参加 >> 次は発表してみる >> 主催なんて事ができたらエンジニアライフが充実しそう！
（発表からはハードル高すぎですがw）

こんな感じで僕なりのレポートを終わりたいと思います。
登壇者のみなさんありがとうございました<(_ _)>
また次回もデブサミ参加しよう！！！