「エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方」の再演 #DevKan
2016年1月22日に開催された表題の勉強会に参加してきました。
エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方。
<話し手>久保 明(@HappyLuckyAkira)さん
やっぱりプレゼンが面白い！
自分のプレゼンと比べるべくもありません。
学び方についてですが、とくに勉強会に参加するときに無理にアウトプットを出そうとか、会社で参加した勉強会の内容について共有しようとか、そういう構えはしなくてもいいんじゃないかというふうにおっしゃってました。
まったくその通りだと思います。
とりあえず聞くだけ聞いてみて面白くて楽しかったらオッケーだと思います。
アウトプット出すにしても徐々に徐々に、段階的にでいいと思います。
派生開発についての勉強会については質問も上がっていたけど、自分も気になります。
開発は変化を前提としているほうがありがたいですけど、そうではない場合どうしたらいいんだろう。
あり方については深い、、、、とおもいます。
時々自分のエンジニアとしてのあり方間違っているのではないかとか、何のために生きているんだろうか思う次第です。
そういうときはステレオポニーの『星屑カンテラ』を聞いています(どうでもいい)。
ワークについて
ペットボトルからコップに水を入れる動作の手順を説明するチェックリストをつくる、というのをやりました。
自分は１５ステップでしたが、お手本は２７ステップ。
以下に、「これくらいはわかるだろう」という思い込みで省略されているのかということが分かりました。
いろんなことを省略して阿吽の呼吸のハイコンテキストでコミュニケーションができるのが理想だと思いますが、それを目指すためには差をちゃんと埋めていく努力が大切かなあとおもいます。
そのほか質問でありましたが、バグとか起きても犯人捜しでネガティブにならずに、このタイミングで見つけてくれてありがとうというふうに思いましょうとのこと。
場の空気を換えるのは難しいそうですが、そういう認知のバイアスを変えていくのも継続してやることで自然とチームの雰囲気改善につながるんじゃないかと思いました。
久保さん、会場のロックオンさん、スタッフの皆さまありがとうございました。
『それぞれの現場で実践した【自動化】の話』に参加・発表してきました #DevKan
2016年1月18日にあった表題の勉強会に参加・発表してきました。
自動化とは何か？ゲーム開発において実践した自動化とは？
<話し手>森田 和則(@pg_morita)さん
DevLove現場甲子園西日本大会の再演です。
２度目になりますが「ベヨネッタ２のゲーム開発のデバッグにおいてコントローラの操作を自動化する」というブログ記事の執筆者です。
バグチェック作業の自動化について
自動化の意義はクリエイティブなことに集中したいから。
そしてなるべくコードを書くという作業を減らしたいから、というのもあるそうです。
ブログ記事の動画を見せてもらいましたが本当に素晴らしいです。
ゲームの負荷などのパフォーマンスを表示する処理ではjQueryを使いこなしてすごく見やすいビューを作っています。
意外なことにjQueryプラグインを使うのがかなり好きなのだとか。
クリエイターさんがVFXなどを変更して結果としてパフォーマンスが落ちたときに、一発でわかるという感じです。
自分はまだまだプロダクトのため、開発で本当にやりたいことに集中するための自動化というのができていないため見習っていきたいです。
特にテスト系をもっとしっかりやりたい。きちんとしたXPやりたい。
森田さんありがとうございました！
ECサービスフロントエンドエンジニアがリリース改善やブラウザ自動テストに取り組んでみた話
発表したスライドは以下になります。
初めてなのもあり、つたない発表で申し訳ありません。
(※ スライド中の、「第２部 完」の画像は手書きです)
会場のサイバーエージェントさん、お聞きくださった方、スタッフの皆さま、本当にありがとうございました。
Accountableの解釈の誤りと自分事化、そして意思決定の明確なルールについて
Accountableの誤訳
アジャイル系の本やスライド資料などを見たときに、一部でAccountableを「説明責任」と訳していると思いますが、Accountableは説明責任ではないはずです。
Accountableの英語の語感については以下の３つの記事が詳しいです。
これらの記事を合わせて読むと、Accountableの意味は
- 「誰が責任を取るのか?」という時に使われる
- 端的に言いかえると「落とし前をつける責任」である
- 落とし前をつける = 引責辞任する、賠償金を支払う、 減俸、 懲戒処分とかをうける
新聞で、～の責任を取って辞任した、みたいな内容のときにはaccountableが使われるということみたいです。
なので、アジャイルとかの日本語の書籍や資料(スライドなんかも)で『説明』『説明する』ではなく、「説明責任」という言葉が出てきた場合は要注意。
本当はもっと、「落とし前をつける責任を持つ」「何かあったときに後始末を必ず請け負う」ということについて書かれていることが多いとおもいます。
エクストリームプログラミング第２版でも、「経営幹部は、XPチームに勇気、自信、『説明責任』を提供する」と書かれていますが、ここは『落とし前を付ける責任』と読み替えるほうが自然だと思います。
トヨタ生産方式に言及して、作業者を含めた全員が品質に責任を持つという話も書かれていますし、原文にもaccountableやaccountabilityについての記述があることは確かなのです。
(でも該当の記述の原文をちゃんと見たわけではないので間違っていたら申し訳ありません)
コーチングで使われるAccountableと自分事化について
ビジネスコーチングを過去に受けたことがありますが、コーチはAccountableとVictimの対比でAccountableのことを説明されていました。
Accountableはほぼ「自分事化」「自己責任化」という態度で、Victimはその逆で「犠牲的」「主体的でない」「誰々のせいで私は～することができない」という態度という説明だったと思います。
当然ですが、Accountableになるほうが良いとアドバイスを受けました。
気を付けなければいけないと思っているのが、物事に対し自分が「誰々のせいで私は～することができない」という犠牲的な態度になっていないかということです。
本当にそうなのか？ということを考えてみることが自分事化だと思います。
Accountableと意思決定の明確なルールについて
適切な意思決定プロセスとメンバとの良好な関係が築くことが一番大事、よく言われてることです。
特に意思決定のうまいやり方についてはすごく気になっていて、いろんなひとにチームや組織の意思決定をどうしているか、ということを質問したりしています。
上の真ん中の記事を結構前に見たのですが、久々に読み返していて、以下の内容が目に留まりました。
“Mike is responsible for holding Sally accountable. Tom is responsible for holding Mike accountable. I am responsible for holding Tom accountable.”
「マイクはサリーをアカウンタブルにしておく責任がある。トムはマイクをアカウンタブルにしておく責任がある。俺はトムをアカウンタブルにしておく責任がある。」
つまり、
「マイクはサリーに落とし前をつける責任を持たせる義務がある。トムはマイクに落とし前をつける責任を持たせる義務がある。俺はトムに落とし前をつける責任を持たせる義務がある。」
と、言い換えてもよいと思います。
そこで、「これは意思決定の明確なルール作りにつながるのでは？」と思い至りました。
『プロジェクトの進捗』や『プロダクトの品質』や『いきいきした仕事』についてaccountabillityを明確にさせておく、ということができていれば意思決定のルールをどう決めればよいかわかりやすいんじゃないかなと考えています。
自分の仕事の、「進捗やプロセス」「品質」「いきいきした仕事」に対してAccountableになりきれるように努力していきます。
アジャイルコーチというロールについて
エンジニアの学ぶべきことの深度は日々増加していて専門性も高くなり、そのために協調して働くスキルが必要になってきていると思います。
付け加えて言うなら、深くなってるんだから潜るのには勇気がいります。
誰もが教科書やコードを読んで、教えてもらうことなく技術を使いこなせるとは限りません。
たとえ技術力や意思力でヘタレだったとしても、そういった未知の領域に潜っていく勇気を与えてくれるのがスクラムやらXPであると思います。
スクラムやXPが生産性にすぐに直接影響を与えることが大きいとは自分は思っていません。継続的にやってこそ効果が出ると思います。
スクラムやXPの具体的な内容についてはここでは言及しませんのであしからず。
ただわかっているのは、やみくもにそういったプロセス改善のフレームワークを用い、プロジェクトがうまくいかないこともあると思います。
根本的な原因は、そのフレームワークそのものにあるのではなく、プロダクトの品質をキーにしたマネジメントをしていないということだったりします。
あるいは人同士の相互作用でプロダクトができるのを無視して、信頼関係の醸成やコミュニケーション(特に意思決定のルール)を軽視していたりすることだったりもします。
原因はともかく、うまくいっていないという現実の課題に踏み込まないまま、プロセス改善のフレームワーク(の上辺だけ)を適用しようとすることだけに注力しようとするのは自分は非常に危険だと思っています。
(そんな状態が続くとエンジニアのフレームワークに対する嫌悪感がたまり、悪のオーラ力がたまってハイパー化します。あるいは、エンジニアのソウルジェムが濁っていき、魔女化します。)
上手くいかないときはアジャイルコーチに頼ってみよう
そこで出てくるのがアジャイルのコーチです。
僕の知っているアジャイルコーチの最初に言った一言は「スクラムの教科書的な答えが知りたいですか？開発をうまく回したいんですか？」という内容です。
スクラムを単純に教えてくれる先生ではありません。
現場の課題に踏み込み、信頼して任せるということ
よく言われることだと思いますが、(良くないOJTのように)放任するというのと、信頼して任せるのは違います。
最初の段階では、アジャイルコーチはチームに問題があるかどうかを観察し、その課題に対してチームがちゃんと踏み込めるようにお膳立て(ファシリテーション)します。
具体的には、振り返り(retrospective)の効率的なやり方としてタイムボックスを提案してみたり、ときには簡単なワークショップもその場でやったりもします。
僕たちのチームの最初の課題として、KPTのproblemが浅く、tryの理由づけとして機能が弱かったというのがありました。
それを解決するのになぜなぜ形式でチームに問題の掘り下げをさせ、ボトルネックになっていることは何かということを追求させました。
やってるのはあくまでもお膳立てですが、ちゃんと現場の課題に踏み込みます。
コーチはそうした観察とデウスエクスマキナのような(だとちょっと言い過ぎかもしれませんが)交通整理を繰り返して、ある程度になった時点でチームを信頼して任せてくれたと思います。
決して教科書読ませてワークショップやって良かったねして、あとは自分でやれという感じではないです。
(新入社員の初年度研修などはそういうふうにせざるを得ない事情もあると思いますが・・・)
アジャイルコーチ、何となく良さそう！
アジャイルコーチとして、ファシリテーションの技術だけでなく、アジャイルに限定しない問題解決のプラクティスの引き出しが重要になると思います。
あくまで個人として感じたことですが、いいコーチはチームの困ってることを助け、自信を着けさせてくれると思います。
皆さんがアジャイルコーチというロールについて知らなかったのでしたら、「何となく良さそう」と思ってもらえるとうれしいです。
windows10のマシンにvagrantを入れて、ubuntuを動かす
やりたかったことはタイトルの通り。
vagrantとvirtualboxをインストール
http://www.vagrantbox.es/ から、ubuntu 14.04のURLをコピーし、以下のコマンドを実行
$ vagrant box add ubuntubox https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-$ vagrant-disk1.box $ vagrant init ubuntubox
vagrant upで「Waiting for machine to boot.」で止まって失敗
そのままvagrant upしたのですが、以下のところで止まりました。
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
数分待っても変わらないので、原因を調べてみることに。
まずは以下の記事を参考にしました。
- http://blog.shibayu36.org/entry/2013/03/17/175405
- http://blog.suusuke.info/2013/12/03/vagrant-up-%E3%81%A7%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%8C%E5%87%BA%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AB%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8/
virtualboxのguiを有効にするのがどうやら原因の解明にいいらしいということで、以下のようにVagrantfileのコメントアウトを外しました。
config.vm.provider "virtualbox" do |vb|
# # Display the VirtualBox GUI when booting the machine
vb.gui = true
#
# # Customize the amount of memory on the VM:
# vb.memory = "1024"
end
再度vagrant upをやってみると以下の記事に出てくる、「ホストマシンの仮想化支援機能(VT-x/AMD-V)が使用できません。ゲストOSは64ビットCPUを検出できず、起動できません。」というダイアログがでました。
http://qiita.com/super-hot-engineer/items/21e4456b8318db877f5b
ググったらこんなことが 「ホストマシンのBIOS設定でVT-x/AMD-V を有効化してください」 とりあえずググったページの通りにやってみよう。 たぶん自分のPCの仮想化支援機構が無効になっているようだ。
motherboardのCPU設定でvirtulizationを有効にする必要があるっぽい。
わからない人はマザーボードのBIOSメニューでとにかくCPU関連をあさりまくるしかないです。
ボードによってはもしかするとなかったりすることもあるのかも。
BIOSを変更して再起動し、やっとubuntuの14が動きました。
ありがとう、ぼくのサンドロック
参照先の元記事を書いてくれた皆様に感謝いたします。
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株式会社様、ありがとうございました。
Devlove現場甲子園2015 西日本大会に参加してきました
Devlove現場甲子園2015 西日本大会
初めてスタッフとして参加
会場の司会担当になりました。
緊張しすぎて結構つまるところも多かったので会場の皆さんやスピーカーの皆様方にはご迷惑をおかけしました。
メモを取る余裕もほとんどなかったので、以下はほぼなんとなく覚えていることの感想がほとんどになります。
『ユーザーに向き合う最前線』
Yahoo株式会社 山本学さん
世の中に公開されているさまざまなサービス(API)と、ものをIoTで結びつけるHUBとなるサービスであるmyThings。
そのサービスを開発者としてだけでなく、エバンジェリストとして広めていくことになったエンジニアとしてのキャリアのあり方、みたいな話だったと記憶しています。
人の目に露出する、使ってもらう、ファンを作る、などの切り口で考えた時、メディア発表だったり、ハッカソンだったり、Devloveのような勉強会だったり、あるいはハンズオンだったりのチャネルの違いでできること、広まることが違うとのこと。
ヌーラボの染田さんとロール的な立ち位置の変わり方が対称的だなーと思いました。２人で対談とかしてみてログとってみても面白いんじゃないかなーと思ったりします。
『Misocaチームの自己組織化への取り組み』
株式会社ファントムタイプ 小久保 祐介さん
Misoca自体はクラウド上で請求書を作って送れるプロダクトの名前でもあり、会社の名前でもあるとのこと。小久保さんは協力会社。
昔はカウボーイスタイルで個々の裁量に任せっぱなしだったのを自己組織化したチームに少しずつ少しずつ改善していったという話。
agileの手法やツールを導入するにも、そのチームにあったやり方があってそれを模索する。
pivotalトラッカーが合わなかったら付箋を貼るホワイトボードのタスクボードでやってみるとか。
去年devlove甲子園西日本大会のaチームさんの「Agileごっこで始めてもいいじゃない。でもやめんな」という話を思い出します。
朝会だけ導入するとか、チームごとにKPTのやり方を変えてみるとかあったような。しかも名古屋だったような。
ポエム駆動開発とまではいかないまでも、日常のモヤモヤをポエムにすることで他人のやっていることや考えていることが伝わるみたいな話もあった。
しかも使っているツールはesa.io。ポエムを書くならesa.io?
そして逆襲のスクラムはちょっとかっこよかった。
スクラムとかアジャイルとか限らず継続的に改善する雰囲気って大事だなーと思いました。
『君が居て僕が居る マネジメントと開発メンバのDiffトーク（そして現場からは、誰も居なくなりそう）』
NECソリューションイノベータ株式会社 アジャイル開発推進センター所属 石崎 浩太郎さん
経営管理センター所属 西 秀和さん
DevLove広島のメンバーのお二人。
会場が２つのモニタを別々の表示に使えるとのことで、急遽２人別々のプレゼン画面を表示しながらやることに決めたそうです。
(もちろん、前もって２画面版と１画面版は用意されていたようですよ)
指示棒がライトセーバー。しかも「ブン。。。。ブン。。。。」的な効果音が常になりっぱなしで面白かった。
大手ISPの案件を受託開発する会社でアジャイルなどをどのように導入していったか、どのように改善していったかといった話だったと思います。
２人は別々の会社で、リーダーとパートナー会社のメンバーだったとのこと。
はじめは全然意思疎通もできなかった。
だんだん改善して、それこそ自己組織化された結果・・・
このチームのリーダー？スクラムマスター？いらないよね、とメンバーから外されたというお話も。。。。
会社の半期くらいの事業リストをみんな繰り返しで見る話が面白かった。
やっぱり会社としてやりたいことがわかってるとみんな共感とか納得して、プロダクトを作るモチベーションになるとおもいます。
『自動化とは何か？ゲーム開発において実践した自動化とは？』
プラチナゲームズ株式会社 森田 和則さん
個人的に衝撃的だった「ベヨネッタ２のゲーム開発のデバッグにおいてコントローラの操作を自動化する」というブログ記事の執筆者です。
はてブで見て「まじか」となりました。
今回はその話ではないですが、ゲーム開発における自動化の意義についてやそのやり方など。
意義はクリエイティブに集中するために自動化する。
エンジニアだけじゃなく、グラフィックのデザイナーさんなども含めて、簡単に更新する処理ができるようにxmlのファイルベースで日々のビルドによる、ゲームの負荷などのパフォーマンスをJenkinsとか色々使って可視化しているとのこと。
誰でもできるためにDBなんか使わずにファイルベース。
やっぱり本当にクリエイティブのみに集中したいという考え方に共感します。
前もAsiyan automation allienceでもゲーム開発者の方が話されていたように、どこの開発現場でも本当に必要ならばそこで作ってしまう文化がゲーム開発現場にはあるんじゃないかと思いました。
セキュリティなどの考え方についてもゲーム開発の現場では、Webなんかと比べても非常にシビアだとか。
普段自分と関わることのない現場の話が聞けて面白かった。
『サービスx現場』
株式会社モノタロウ 牛島真一さん
チームをうまくまわすだけでなく、そのマネージャークラスでもアジャイルにコミュニケーションをやりましょうという、言わばスクラムオブスクラム的なお話なのかなと思います。
チームが違うとお互いのリリースに関心を持っていなかったり、急に別チームに依頼をしても、「もう今回のスプリントに入らない」みたいな問題を解消しようと。
チームの関心をわかるためにマネージャの朝会をやったり、朝会時に使うタスクボードで他のチームのリリース予定などに自分のチームが、（たとえばDBを見てるグループとWebのアプリのグループが）「このリリース、うちのグループも関係してるなー」と思ったらシール貼って意思表示するみたいなことをやっている。
マネージャー陣の時間は潤沢にはないので、効率的にまわさないと「この時間本当にいるの？」的なことが飛び交っているんじゃないかとか色々思われますが、諸事情があって感想書きにくいです。
でもどんなことでもやってみて継続的な改善のサイクル回すって大事だと思います。繰り返しになるけど。
最後の質問は「そっとしておこう・・・」でいてほしかった的な感じだったです。
『エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方。』
コニカミノルタ株式会社 久保明さん
MVPの再演です。
TEDみたい、という感想もあったようですがまさしくその通りかと。
練りに練られたプレゼンでした。
覚えていることベースで書きます。
他人の幸せを考えるためにはまず自分が幸せになること
エンジニアにとって幸せとは？
リーダーの自分がガントチャート書くのが苦手なら、得意な人にやってもらってもいいじゃん。
成長するのは良いことだ、から、成長しないことは悪いことだ にしないように
そのためには行動科学がいいですよーと
ダイアログで久保さんと話させてもらいましたが、自己組織化とか自律的なメンバーの行動をうながすために、チームからリーダー的な立ち位置の人が手を引くのも手だけど、やるなら段階的にとか。
そして、本をオススメされました。
「マンガでよくわかる 行動科学で成果が上がる組織を作る 教える技術」1, 2巻
次の日に買いました。
久保さんものすごく面白い人だと感じました。
いろんな現場知れて本当に楽しい。
発表者の皆様、他のスタッフの皆様、参加者の皆様、会場の運営者のエムオーテックス様、ありがとうございました。
