Devlove現場甲子園2015東日本大会に参加してきました
前日の夜まですごく行くかどうか悩んでいましたが、Devlove現場甲子園2015東日本大会にいってきました。
市谷さんの話に出てきた『エモい』について
エモというのは音楽のジャンル(ロック系？)からきているのかと思います。
詳しくはないのですが、ちょっと長くいうとエモーショナルハードコアという名前で、その派生としてスクリーモなどがあるそうです。
ちょっと聞いたりしたこともありました。
Wikipediaを引用すると
疾走感溢れ、正確なリズムとラウドなギターをベースにしたバンドサウンド（ギター、ベース、ドラムによる一般にハードコアやパンクで使われる楽器での演奏）に副次的な演奏（ピアノ、 キーボード、 シンセサイザーなどの演奏）を用いて、哀愁のあるメロディと情緒的なボーカルを乗せる
という感じ。
音楽に対して、「この曲はエモい」などという流れがあったのではないかと認識しています。
エンジニアリングにも、似たような感情で表現する形容詞として「エモい」が使われるようになったのではないでしょうか？
『受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス』
ヴェルク 田向裕介さん
Devlove関西で聞いた boardの田向さんの話と、次のDocBaseの天野さんの話がもう一度聞きたくて勢いで東京までいった感じです。
基本的には同じお話だったので、前に書いたブログ記事と内容がかぶってしまいます。
ですが、やっぱりすごく面白かった。忘れていることも多かったし。
意思決定に関しての明確な方針がある（コストのかかる合議制は取らない）のがやっぱりいいと思いました。
自分がメンバーだったとしてもそんなところに時間はかけてほしくない。
差分としてあったことですごく面白かったのが、実験的にユーザーの個別相談会をやってみたという話。
時間を１時間予約してもらって、個別に密に相談する。
お客様からも意外と好評で、田向さんとしてもイシューの吸い上げだけでなく営業にもなるのですごくよかったとのこと。
開発者とユーザーのつながりがワンストップであることがやっぱり非常に重要だなーと思いました。
営業の人のヒアリング結果を開発者に伝える、ということではないところが重要。
カスタマーサポートをエンジニアがやってみる経験って田向さんのように直接のコミュニケーションではないですが自分もやったことがあり、いろんなことがわかります。
１回目ではっきり行って良かった感が感じられました。
『試行錯誤と改善を繰り返し、チームの開発力を高めた方法』
KRAY 天野 充広さん
お話はDocBaseの開発に限らず、チームを育てるという話がメイン。
サービスの価値を理解していない
開発メンバーが指示待ち
言われたものだけを作っている
だめなものをだめと言えない
といったことをなくすことで、メンバー全員が主体的に動いていくチームを目指す。
やっぱり自己組織化というキーワードがしっくりくるお話です。
自分に身近に感じられないものでは価値が判断できないという話はなぜドッグフーディングで作るのかという話につながるし、スクラムなんかがなぜ必要かということにつながると思います。
個人的にも意思決定のプロセスは優しい独裁のほうがいいんだろうな、とは思いますが、協調して働くためには意思決定のプロセスだけでなくメンバー間の良好な関係が築けているかも重要だと思います。
この話のテーマの１つだと思うけど、「メンバーの成長」を実現するにもやっぱりメンバー同士の関係性重要だと思います。
そのためのチームビルディングだし、スクラムのようなフレームワークだとおもいます。
メンバーの一人が提案によって「週１回一人２０００円を会社が負担して、みんなでランチを行い、仕事の話はしない」ということをやっているそうです。
会社が負担というところがいいですね。
勉強にしても、好きに勉強していい時間が週４時間あるとのことで、いいなぁと思います。
朝会やKPTのやり方の話も良かったです。
KPTって、前のDevlove現場甲子園2015西日本大会で久保明さんが話されていた、行動科学と関連してくると思います。
「行動をほめる」習慣作りがすごくいい感じかも。
こうした様々な取り組みの結果、「他のプロジェクトで使えるようにプラグインで公開する」などの自律的な行動が増え、場のことは現場の人を信頼して任せることができるようになったとのこと。
プロダクトを小さく作って繰り返し検証するという話ももう一度聞きたかったけど、今回の話も面白かった。
『Developer Infrastructure』
Wantedly 坂部広大さん
企業などの採用ページの入力にwantedlyの情報を自動で入れるajaxのボタンを導入した話。
質問であったのですが、あらかじめ効果の高いであろうサイトと交渉して事前に一緒に作業してテストまでやっていてから公開したとのこと。
wantedlyの文化
Code Wins arguments
議論よりもその場でコードを書いてみて検証するほうが確かである
User First
バズりやすいというか、ツッコミを受けやすい
単にユーザーの言うことをきくのではなく、ユーザーの本質的なニーズに気づくことが大事。
確かにと納得させられる話。
言われたことをやるだけではインフラチームは務まらないと言われることが多いと思いますが、インフラチームだけじゃないよなーと思います。
インフラチームのKPIをどうしたらいいの、といった話が続いて
上限KPIが10%も改善しないような施策はやらないとか仮説をどう立てるかということが重要になるとのこと。
MVP的なアプローチなのかなーと思いました。
インフラチームはコードを書かないけど、自動化やセルフサービス化によってインフラのコード化をすればいい。
サービスが拡大すると開発チームばかりが増大する問題。
タスクが溜まってインフラチームが帰れなくなり、インフラチームがボトルネックになる。
わかる。。。。
ここで、解決するためにメンバーを増やすということではなく、インフラチームの質を底上げする都いうアプローチを取ったそうです。
WHAT: 何を実現するか？
変化に強いインフラ、変化を避けるインフラではなく、むしろ変更を前提とするインフラを実現するとのこと。
インフラのコード化によって、依頼の形式がissueではなく、プルリクになった！
ここで疑問があったので、あとで質問してみました。
「１つ目の質問として、開発チームにインフラの知識が必要になるのではないですか？
２つ目の質問として、開発チームも依頼しやすくなる？ 開発チームとインフラチームの対立をひき起こしにくくなるとか副次的な効果があったら嬉しいんですけどないですか？」
回答としては、インフラチームはインフラのことをアプリチームに教え、アプリチームはアプリのことをインフラチームに教えるという勉強会を隔週でやっているそう。
それは仲良くなれる上にプルリクで依頼というのもやりやすくなるなと思いました。素晴らしいなー
情熱プロジェクトと痛み分けタスクをどっちもやる。
普段アプリのエンジニアの話ばかりを聞くことが多いので、今回の話はすごく参考になりました。
前もヴァル研さんの話で聞いたけど、その時と違ってなぜこういう取り組みがいるのかというのが身にしみている感じです。
インフラエンジニアの人たちにももっと紹介したい話だと思ったので、Devlove関西でも、もう一度坂部さんの話が聞きたいと思いました。
why
インフラチームのモチベーション管理
インフラチームが依頼されたタスクをこなすだけでなく、自分たちのやりたいことを実現するには
インフラチームとアプリチームの歩み寄りを実現するには
『プロジェクト管理しないという提案』
株式会社ZIG CTO 森 英寿さん
はっきり言って知らないことが多すぎて頭の中がちょっとオーバーヒートしました。
技術をコアにしたスタートアップ特有であるかもしれないプロジェクト管理です。
自分の感じたこととして、コミュニケーションにコストをかけることで社内の雰囲気・文化・ビジョン・会社の軸を醸成することが大事なのかなと思いました。
それをやる前提条件としてお互いの信頼が絶対の前提条件。
スタートアップでぶち当たる「資金調達して、アプリを成功に導く、つまり前半で説明されていた通り、出してすぐはバーンレートが赤字を垂れ流し、プレッシャーになったりする壁」に、３人の組織として立ち向かう際に軸がぶれていては話になりません。
作りながら文化も醸成していく。
過去のissueを管理したり思い出して何かやるより、今上がっているissue(絶対の信頼がある仲間から上がっている課題です)を解決することが重要。
確かにそうなるだろうなと想像はできました。
本当に重要な課題は何回も出てくるし、逆に何回も出ることでその度に新しい改善方法を考える機会が得られるというのも確かにそうだ、と感じました。
面白かったのは、スタートアップとして、の段階を通り過ぎた後はエンジニアなどの採用をどうするのかというお話で、そこについては初めてだからわからないので逆にWantedlyの坂部さんに質問をされていました。
坂部さんの回答としては、エンジニアのスキルを持った人が「前職はこうだったから」というロジックで行動して会社のビジョンなどとマッチせずに離れていくのを防ぐには、やっぱりビジョンなどについても結論だけで話すのではなく、徹底的に話し合う必要が出てくるとのこと。
そういう段階においては、過去の経緯が多少わかるようにWhyとWhat(あるいはDone内容の記述かなと自分は思いました)を管理していく、マネジメントも必要になるのではないかという回答でした。
１個前の坂部さんの講演も聞いてて良かった感が非常にありました！
でもやっぱり１回じゃわかりきれなかったので『も゙っがい゙』的な気持ち強かったです。
『ゲーム開発2つの現場』
スクウェア・エニックス 岩本翔さん
（この辺もう完全に自分の電池キレ気味だったかもしれません。申し訳ないです）
１年ほど前よりサウンドプログラマとして、サウンドを制御するためのサウンドドライバやサウンドデータを作成するためのオーサリングツールを作っているそう
マルチプラットフォームで マルチチャンネルで、いろんなサウンドのフォーマットで音を鳴らさないといけないので難しい。
音量を調整するだけでなく、負荷の問題も制御したり、開発環境がいろいろことなるが、いろいろ同時にサポートする必要が有るそう。
上から指示されたことを計画通りにやれということではない
「『やっていいですかね？』じゃねーよ、『できました』って言え」
すごすぎる。でもただしいというか。
スタンドプレーの結果から生じるチームワークが主体だけど、スクエニ全体がそうじゃなくて、サウンドチームは独立国家
朝会などなくて、本当の裁量労働
コードレビューなどはしないが、読めばわかるというレベルの高い人が集まっているため、全体は把握している
元は朝会やるとかいろんな試行を繰り返して、今の形になっているとのことだし、これからもずっと変わるのかもしれないと感じました。
部内ではマイルストーンはないが、別の部署から 使ってる側からの都合で予定が決まるそうです。
仕様書などなくて、実装された物が仕様で必要になればドキュメントも用意するとのこと。
自由に仕事できる モチベーションは高いけど、何をやればいいか自分で考えないといけない、何をやったか自分でアピールしないといけないとのこと。
きついけどやりがいしかない感じがします。
「ゲームの発売日とかは理由書けば休める。」
Aiming 相良 拓哉さん
オンラインゲームのクライアント側の開発をやっているとのこと
朝会・夕会は基本なく、その理由の一つとしてプロジェクトでサーバサイドなど全部入れると30人を超える
ほぼ毎日研究のため他社ゲームで遊んでいる → ゲームの共通言語ができた
社内勉強会
結構いろんな人が多すぎて絶対に情報の共有が必要
技術だけでなく運営にか関わる法律の話、例えばコンプガチャ問題やマーケティングの話なども
勉強会は持ち回り？
運営を相楽さん 運営サポート５人
月１回 運営会議 「こういうのってしっておかないとまずくね？」みたいなことを決める
逆に、「やりたいんだけど」っていってくれるひとがいる 勉強会の枠を使ってもらう
勉強会の運営会議かー。これ全然ゲーム開発関係なくいいやり方だと思います。
ダイアログのなかでもでたけどお菓子配るとかの工夫もいいですね。
違う現場の社内勉強会のやり方、もっと知りたいかも。
毎週やろうとすると辛くなる。結構フィードバックない
開催したらくるけど何もない。続けるためには無理にやらない
なんだかんだオファーするとやってくれる
いつやってくれるかきいてこないと、日程をある程度決めておく
日時近くなったらできますか、と聞く リスケ
アンケートやってみると、よいとか非常によいとかのフィードバックが多い
モチベーションになる
ちょっとずつ勉強会に関わる人を増やしていく
岩本さんから勉強会のフィードバックのもらい方についてのTIPSのアイディアが！
dwango勉強会 付箋を配っておく その場で感想をもらう
こうやってその場で改善の提案が出るところが素晴らしいです。
魔導書買おう。
全体の感想
結局のところ、ほとんどの現場で無駄なリソースを使う余裕なんてないんだと感じました。
本当に必要なもののみに注力する、ボトルネックを改善する、全体の収益に一番影響を与えるものを徹底的にこだわって改善する
現場に今必要なことって、現場ごとにやっぱり違う。
肌感覚も大事だけど、その辺の見える化やメトリクスについてもエンジニアリングの文脈でいっぱい出てきているのかな、、、みたいなことも考えました。
発表者の皆様、スタッフの皆様、参加者の皆様、会場の運営者のYahoo株式会社様、ありがとうございました。
