hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

Devlove現場甲子園2015東日本大会に参加してきました

前日の夜まですごく行くかどうか悩んでいましたが、Devlove現場甲子園2015東日本大会にいってきました。

 

 

市谷さんの話に出てきた『エモい』について

エモというのは音楽のジャンル(ロック系?)からきているのかと思います。
詳しくはないのですが、ちょっと長くいうとエモーショナルハードコアという名前で、その派生としてスクリーモなどがあるそうです。
ちょっと聞いたりしたこともありました。
Wikipediaを引用すると

 

エモ - Wikipedia

 

疾走感溢れ、正確なリズムとラウドなギターをベースにしたバンドサウンド(ギター、ベース、ドラムによる一般にハードコアやパンクで使われる楽器での演奏)に副次的な演奏(ピアノ、 キーボード、 シンセサイザーなどの演奏)を用いて、哀愁のあるメロディと情緒的なボーカルを乗せる

という感じ。

音楽に対して、「この曲はエモい」などという流れがあったのではないかと認識しています。
エンジニアリングにも、似たような感情で表現する形容詞として「エモい」が使われるようになったのではないでしょうか?


『受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス』
ヴェルク 田向裕介さん

 

Devlove関西で聞いた boardの田向さんの話と、次のDocBaseの天野さんの話がもう一度聞きたくて勢いで東京までいった感じです。
基本的には同じお話だったので、前に書いたブログ記事と内容がかぶってしまいます。
ですが、やっぱりすごく面白かった。忘れていることも多かったし。
意思決定に関しての明確な方針がある(コストのかかる合議制は取らない)のがやっぱりいいと思いました。
自分がメンバーだったとしてもそんなところに時間はかけてほしくない。
差分としてあったことですごく面白かったのが、実験的にユーザーの個別相談会をやってみたという話。
時間を1時間予約してもらって、個別に密に相談する。
お客様からも意外と好評で、田向さんとしてもイシューの吸い上げだけでなく営業にもなるのですごくよかったとのこと。
開発者とユーザーのつながりがワンストップであることがやっぱり非常に重要だなーと思いました。
営業の人のヒアリング結果を開発者に伝える、ということではないところが重要。
カスタマーサポートをエンジニアがやってみる経験って田向さんのように直接のコミュニケーションではないですが自分もやったことがあり、いろんなことがわかります。
1回目ではっきり行って良かった感が感じられました。


『試行錯誤と改善を繰り返し、チームの開発力を高めた方法』
KRAY 天野 充広さん

 

お話はDocBaseの開発に限らず、チームを育てるという話がメイン。

サービスの価値を理解していない
開発メンバーが指示待ち
言われたものだけを作っている
だめなものをだめと言えない

といったことをなくすことで、メンバー全員が主体的に動いていくチームを目指す。
やっぱり自己組織化というキーワードがしっくりくるお話です。

自分に身近に感じられないものでは価値が判断できないという話はなぜドッグフーディングで作るのかという話につながるし、スクラムなんかがなぜ必要かということにつながると思います。

個人的にも意思決定のプロセスは優しい独裁のほうがいいんだろうな、とは思いますが、協調して働くためには意思決定のプロセスだけでなくメンバー間の良好な関係が築けているかも重要だと思います。
この話のテーマの1つだと思うけど、「メンバーの成長」を実現するにもやっぱりメンバー同士の関係性重要だと思います。
そのためのチームビルディングだし、スクラムのようなフレームワークだとおもいます。
メンバーの一人が提案によって「週1回一人2000円を会社が負担して、みんなでランチを行い、仕事の話はしない」ということをやっているそうです。
会社が負担というところがいいですね。
勉強にしても、好きに勉強していい時間が週4時間あるとのことで、いいなぁと思います。

朝会やKPTのやり方の話も良かったです。
KPTって、前のDevlove現場甲子園2015西日本大会で久保明さんが話されていた、行動科学と関連してくると思います。
「行動をほめる」習慣作りがすごくいい感じかも。

こうした様々な取り組みの結果、「他のプロジェクトで使えるようにプラグインで公開する」などの自律的な行動が増え、場のことは現場の人を信頼して任せることができるようになったとのこと。
プロダクトを小さく作って繰り返し検証するという話ももう一度聞きたかったけど、今回の話も面白かった。


『Developer Infrastructure』
Wantedly 坂部広大さん

 

企業などの採用ページの入力にwantedlyの情報を自動で入れるajaxのボタンを導入した話。
質問であったのですが、あらかじめ効果の高いであろうサイトと交渉して事前に一緒に作業してテストまでやっていてから公開したとのこと。

wantedlyの文化 

Code Wins arguments
議論よりもその場でコードを書いてみて検証するほうが確かである

User First
バズりやすいというか、ツッコミを受けやすい
単にユーザーの言うことをきくのではなく、ユーザーの本質的なニーズに気づくことが大事。

確かにと納得させられる話。
言われたことをやるだけではインフラチームは務まらないと言われることが多いと思いますが、インフラチームだけじゃないよなーと思います。

インフラチームのKPIをどうしたらいいの、といった話が続いて
上限KPIが10%も改善しないような施策はやらないとか仮説をどう立てるかということが重要になるとのこと。
MVP的なアプローチなのかなーと思いました。

インフラチームはコードを書かないけど、自動化やセルフサービス化によってインフラのコード化をすればいい。


サービスが拡大すると開発チームばかりが増大する問題。
タスクが溜まってインフラチームが帰れなくなり、インフラチームがボトルネックになる。
わかる。。。。
ここで、解決するためにメンバーを増やすということではなく、インフラチームの質を底上げする都いうアプローチを取ったそうです。

WHAT: 何を実現するか?

変化に強いインフラ、変化を避けるインフラではなく、むしろ変更を前提とするインフラを実現するとのこと。

インフラのコード化によって、依頼の形式がissueではなく、プルリクになった!

ここで疑問があったので、あとで質問してみました。

「1つ目の質問として、開発チームにインフラの知識が必要になるのではないですか?
2つ目の質問として、開発チームも依頼しやすくなる? 開発チームとインフラチームの対立をひき起こしにくくなるとか副次的な効果があったら嬉しいんですけどないですか?」

回答としては、インフラチームはインフラのことをアプリチームに教え、アプリチームはアプリのことをインフラチームに教えるという勉強会を隔週でやっているそう。
それは仲良くなれる上にプルリクで依頼というのもやりやすくなるなと思いました。素晴らしいなー

情熱プロジェクトと痛み分けタスクをどっちもやる。
普段アプリのエンジニアの話ばかりを聞くことが多いので、今回の話はすごく参考になりました。
前もヴァル研さんの話で聞いたけど、その時と違ってなぜこういう取り組みがいるのかというのが身にしみている感じです。

インフラエンジニアの人たちにももっと紹介したい話だと思ったので、Devlove関西でも、もう一度坂部さんの話が聞きたいと思いました。

why
インフラチームのモチベーション管理
インフラチームが依頼されたタスクをこなすだけでなく、自分たちのやりたいことを実現するには
インフラチームとアプリチームの歩み寄りを実現するには

 

 

『プロジェクト管理しないという提案』

株式会社ZIG CTO 森 英寿さん

 

はっきり言って知らないことが多すぎて頭の中がちょっとオーバーヒートしました。

技術をコアにしたスタートアップ特有であるかもしれないプロジェクト管理です。
自分の感じたこととして、コミュニケーションにコストをかけることで社内の雰囲気・文化・ビジョン・会社の軸を醸成することが大事なのかなと思いました。
それをやる前提条件としてお互いの信頼が絶対の前提条件。
スタートアップでぶち当たる「資金調達して、アプリを成功に導く、つまり前半で説明されていた通り、出してすぐはバーンレートが赤字を垂れ流し、プレッシャーになったりする壁」に、3人の組織として立ち向かう際に軸がぶれていては話になりません。
作りながら文化も醸成していく。
過去のissueを管理したり思い出して何かやるより、今上がっているissue(絶対の信頼がある仲間から上がっている課題です)を解決することが重要。
確かにそうなるだろうなと想像はできました。
本当に重要な課題は何回も出てくるし、逆に何回も出ることでその度に新しい改善方法を考える機会が得られるというのも確かにそうだ、と感じました。

面白かったのは、スタートアップとして、の段階を通り過ぎた後はエンジニアなどの採用をどうするのかというお話で、そこについては初めてだからわからないので逆にWantedlyの坂部さんに質問をされていました。

坂部さんの回答としては、エンジニアのスキルを持った人が「前職はこうだったから」というロジックで行動して会社のビジョンなどとマッチせずに離れていくのを防ぐには、やっぱりビジョンなどについても結論だけで話すのではなく、徹底的に話し合う必要が出てくるとのこと。
そういう段階においては、過去の経緯が多少わかるようにWhyとWhat(あるいはDone内容の記述かなと自分は思いました)を管理していく、マネジメントも必要になるのではないかという回答でした。
1個前の坂部さんの講演も聞いてて良かった感が非常にありました!


でもやっぱり1回じゃわかりきれなかったので『も゙っがい゙』的な気持ち強かったです。


『ゲーム開発2つの現場』
スクウェア・エニックス 岩本翔さん

 

(この辺もう完全に自分の電池キレ気味だったかもしれません。申し訳ないです)
1年ほど前よりサウンドプログラマとして、サウンドを制御するためのサウンドドライバやサウンドデータを作成するためのオーサリンツールを作っているそう

マルチプラットフォームで マルチチャンネルで、いろんなサウンドのフォーマットで音を鳴らさないといけないので難しい。
音量を調整するだけでなく、負荷の問題も制御したり、開発環境がいろいろことなるが、いろいろ同時にサポートする必要が有るそう。


上から指示されたことを計画通りにやれということではない
「『やっていいですかね?』じゃねーよ、『できました』って言え」

すごすぎる。でもただしいというか。

スタンドプレーの結果から生じるチームワークが主体だけど、スクエニ全体がそうじゃなくて、サウンドチームは独立国家

朝会などなくて、本当の裁量労働
コードレビューなどはしないが、読めばわかるというレベルの高い人が集まっているため、全体は把握している

元は朝会やるとかいろんな試行を繰り返して、今の形になっているとのことだし、これからもずっと変わるのかもしれないと感じました。

部内ではマイルストーンはないが、別の部署から 使ってる側からの都合で予定が決まるそうです。
仕様書などなくて、実装された物が仕様で必要になればドキュメントも用意するとのこと。


自由に仕事できる モチベーションは高いけど、何をやればいいか自分で考えないといけない、何をやったか自分でアピールしないといけないとのこと。

きついけどやりがいしかない感じがします。

「ゲームの発売日とかは理由書けば休める。」

 


Aiming 相良 拓哉さん

 

オンラインゲームのクライアント側の開発をやっているとのこと

朝会・夕会は基本なく、その理由の一つとしてプロジェクトでサーバサイドなど全部入れると30人を超える

ほぼ毎日研究のため他社ゲームで遊んでいる → ゲームの共通言語ができた


社内勉強会
結構いろんな人が多すぎて絶対に情報の共有が必要
技術だけでなく運営にか関わる法律の話、例えばコンプガチャ問題やマーケティングの話なども

 

勉強会は持ち回り?
運営を相楽さん 運営サポート5人
月1回 運営会議 「こういうのってしっておかないとまずくね?」みたいなことを決める
逆に、「やりたいんだけど」っていってくれるひとがいる 勉強会の枠を使ってもらう

勉強会の運営会議かー。これ全然ゲーム開発関係なくいいやり方だと思います。
ダイアログのなかでもでたけどお菓子配るとかの工夫もいいですね。
違う現場の社内勉強会のやり方、もっと知りたいかも。

毎週やろうとすると辛くなる。結構フィードバックない
開催したらくるけど何もない。続けるためには無理にやらない

なんだかんだオファーするとやってくれる
いつやってくれるかきいてこないと、日程をある程度決めておく
日時近くなったらできますか、と聞く リスケ

アンケートやってみると、よいとか非常によいとかのフィードバックが多い
モチベーションになる

ちょっとずつ勉強会に関わる人を増やしていく

岩本さんから勉強会のフィードバックのもらい方についてのTIPSのアイディアが!
dwango勉強会 付箋を配っておく その場で感想をもらう

こうやってその場で改善の提案が出るところが素晴らしいです。

魔導書買おう。


全体の感想

結局のところ、ほとんどの現場で無駄なリソースを使う余裕なんてないんだと感じました。
本当に必要なもののみに注力する、ボトルネックを改善する、全体の収益に一番影響を与えるものを徹底的にこだわって改善する
現場に今必要なことって、現場ごとにやっぱり違う。

肌感覚も大事だけど、その辺の見える化やメトリクスについてもエンジニアリングの文脈でいっぱい出てきているのかな、、、みたいなことも考えました。

 

発表者の皆様、スタッフの皆様、参加者の皆様、会場の運営者のYahoo株式会社様、ありがとうございました。

Devlove現場甲子園2015 西日本大会に参加してきました

Devlove現場甲子園2015 西日本大会

初めてスタッフとして参加
会場の司会担当になりました。
緊張しすぎて結構つまるところも多かったので会場の皆さんやスピーカーの皆様方にはご迷惑をおかけしました。
メモを取る余裕もほとんどなかったので、以下はほぼなんとなく覚えていることの感想がほとんどになります。

 

『ユーザーに向き合う最前線』
Yahoo株式会社 山本学さん

世の中に公開されているさまざまなサービス(API)と、ものをIoTで結びつけるHUBとなるサービスであるmyThings。
そのサービスを開発者としてだけでなく、エバンジェリストとして広めていくことになったエンジニアとしてのキャリアのあり方、みたいな話だったと記憶しています。
人の目に露出する、使ってもらう、ファンを作る、などの切り口で考えた時、メディア発表だったり、ハッカソンだったり、Devloveのような勉強会だったり、あるいはハンズオンだったりのチャネルの違いでできること、広まることが違うとのこと。
ヌーラボの染田さんとロール的な立ち位置の変わり方が対称的だなーと思いました。2人で対談とかしてみてログとってみても面白いんじゃないかなーと思ったりします。


『Misocaチームの自己組織化への取り組み』
株式会社ファントムタイプ 小久保 祐介さん

 

Misoca自体はクラウド上で請求書を作って送れるプロダクトの名前でもあり、会社の名前でもあるとのこと。小久保さんは協力会社。
昔はカウボーイスタイルで個々の裁量に任せっぱなしだったのを自己組織化したチームに少しずつ少しずつ改善していったという話。
agileの手法やツールを導入するにも、そのチームにあったやり方があってそれを模索する。
pivotalトラッカーが合わなかったら付箋を貼るホワイトボードのタスクボードでやってみるとか。

去年devlove甲子園西日本大会のaチームさんの「Agileごっこで始めてもいいじゃない。でもやめんな」という話を思い出します。
朝会だけ導入するとか、チームごとにKPTのやり方を変えてみるとかあったような。しかも名古屋だったような。

ポエム駆動開発とまではいかないまでも、日常のモヤモヤをポエムにすることで他人のやっていることや考えていることが伝わるみたいな話もあった。
しかも使っているツールesa.io。ポエムを書くならesa.io?

そして逆襲のスクラムはちょっとかっこよかった。
スクラムとかアジャイルとか限らず継続的に改善する雰囲気って大事だなーと思いました。


『君が居て僕が居る マネジメントと開発メンバのDiffトーク(そして現場からは、誰も居なくなりそう)』
NECソリューションイノベータ株式会社 アジャイル開発推進センター所属 石崎 浩太郎さん
経営管理センター所属 西 秀和さん

DevLove広島のメンバーのお二人。
会場が2つのモニタを別々の表示に使えるとのことで、急遽2人別々のプレゼン画面を表示しながらやることに決めたそうです。
(もちろん、前もって2画面版と1画面版は用意されていたようですよ)

指示棒がライトセーバー。しかも「ブン。。。。ブン。。。。」的な効果音が常になりっぱなしで面白かった。
大手ISPの案件を受託開発する会社でアジャイルなどをどのように導入していったか、どのように改善していったかといった話だったと思います。
2人は別々の会社で、リーダーとパートナー会社のメンバーだったとのこと。
はじめは全然意思疎通もできなかった。
だんだん改善して、それこそ自己組織化された結果・・・
このチームのリーダー?スクラムマスター?いらないよね、とメンバーから外されたというお話も。。。。
会社の半期くらいの事業リストをみんな繰り返しで見る話が面白かった。
やっぱり会社としてやりたいことがわかってるとみんな共感とか納得して、プロダクトを作るモチベーションになるとおもいます。


『自動化とは何か?ゲーム開発において実践した自動化とは?』
プラチナゲームズ株式会社 森田 和則さん

 

個人的に衝撃的だった「ベヨネッタ2のゲーム開発のデバッグにおいてコントローラの操作を自動化する」というブログ記事の執筆者です。
はてブで見て「まじか」となりました。
今回はその話ではないですが、ゲーム開発における自動化の意義についてやそのやり方など。
意義はクリエイティブに集中するために自動化する。
エンジニアだけじゃなく、グラフィックのデザイナーさんなども含めて、簡単に更新する処理ができるようにxmlのファイルベースで日々のビルドによる、ゲームの負荷などのパフォーマンスをJenkinsとか色々使って可視化しているとのこと。
誰でもできるためにDBなんか使わずにファイルベース。

やっぱり本当にクリエイティブのみに集中したいという考え方に共感します。
前もAsiyan automation allienceでもゲーム開発者の方が話されていたように、どこの開発現場でも本当に必要ならばそこで作ってしまう文化がゲーム開発現場にはあるんじゃないかと思いました。
セキュリティなどの考え方についてもゲーム開発の現場では、Webなんかと比べても非常にシビアだとか。
普段自分と関わることのない現場の話が聞けて面白かった。


『サービスx現場』
株式会社モノタロウ 牛島真一さん

チームをうまくまわすだけでなく、そのマネージャークラスでもアジャイルにコミュニケーションをやりましょうという、言わばスクラムオブスクラム的なお話なのかなと思います。
チームが違うとお互いのリリースに関心を持っていなかったり、急に別チームに依頼をしても、「もう今回のスプリントに入らない」みたいな問題を解消しようと。
チームの関心をわかるためにマネージャの朝会をやったり、朝会時に使うタスクボードで他のチームのリリース予定などに自分のチームが、(たとえばDBを見てるグループとWebのアプリのグループが)「このリリース、うちのグループも関係してるなー」と思ったらシール貼って意思表示するみたいなことをやっている。

マネージャー陣の時間は潤沢にはないので、効率的にまわさないと「この時間本当にいるの?」的なことが飛び交っているんじゃないかとか色々思われますが、諸事情があって感想書きにくいです。
でもどんなことでもやってみて継続的な改善のサイクル回すって大事だと思います。繰り返しになるけど。
最後の質問は「そっとしておこう・・・」でいてほしかった的な感じだったです。


『エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方。』
コニカミノルタ株式会社 久保明さん

MVPの再演です。

TEDみたい、という感想もあったようですがまさしくその通りかと。
練りに練られたプレゼンでした。
覚えていることベースで書きます。

 

他人の幸せを考えるためにはまず自分が幸せになること
エンジニアにとって幸せとは?

リーダーの自分がガントチャート書くのが苦手なら、得意な人にやってもらってもいいじゃん。
成長するのは良いことだ、から、成長しないことは悪いことだ にしないように

そのためには行動科学がいいですよーと

 

ダイアログで久保さんと話させてもらいましたが、自己組織化とか自律的なメンバーの行動をうながすために、チームからリーダー的な立ち位置の人が手を引くのも手だけど、やるなら段階的にとか。
そして、本をオススメされました。


「マンガでよくわかる 行動科学で成果が上がる組織を作る 教える技術」1, 2巻


次の日に買いました。
久保さんものすごく面白い人だと感じました。


いろんな現場知れて本当に楽しい。

 

発表者の皆様、他のスタッフの皆様、参加者の皆様、会場の運営者のエムオーテックス様、ありがとうございました。

 

esaとDocBaseのサービス開発のDiffの話 #DevKan

2015年11月28日に実施された表題の勉強会に参加してきました!

devlove-kansai.doorkeeper.jp

speakerdeck.com

KRAY 天野 充広(@amachin)さん

そう言えば、ホッテントリからKRAYさんの記事ブックマークしてた!

git pull と git pull –rebase の違いって?図を交えて説明します! | KRAY Inc

esaさんとは実は仲がいい

以下、メモ的な内容になりますが、DocBaseさんのお話になります。
少し開始時刻に間に合わなかったので、途中からになります。

なぜ作ったのか?

  • 社外秘の情報がいっぱい
  • ユーザー数による課金

その結果

  • 外部の開発パートナーと共有しづらい
  • クライアントと共有しづらい
  • アルバイトやインターンを招待しづらい

問題点「有用な情報が関係者全員で共有できない」

一部の人だけが使えないツールの問題はうちの会社でもあります。
結局のところプロパー社員以外も含めて全員に共有するにはメールしかなかったり。
一番共有したい手順やヘルプトピックなどが共有できなかったり。

ドキュメントを作るのは大変(というイメージ)

  • ちゃんとしたドキュメントを書かなきゃ。
  • 間違った情報を書いてはだめだ

その結果

  • ずっと下書きのまま。
  • 小さな情報は共有しづらい
  • きちんとしたドキュメントを作るのは大変。

この辺でesaさんにはWIP機能があるんですよね、という話が入った。
DocBaseのスライドなのに「esaの命題」というタイトルになっています。
人数少なかったのもあって、参加者と発表者そして、esa深谷さん、赤塚さんも質問や発表内容の捕捉に加わってもらいながら、いい感じに質問のキャッチボールができてました。
WIPって何て説明すればいいんだろう?仕掛中?   うちの会社では、プルリクエストにWIPというプレフィックスをつけて出す場合がかなりあります。 esaさんはWIP機能で「未完成でもいいんだよ」とハードルを下げて、「ドキュメントを書く」ということを促しているそうです。 DocBaseさんでもWIP機能は検討したそう。

DocBaseの命題:チームの情報共有を活発にさせたい

情報共有が活発になると

  • 新しい知識が共有され、チームメンバーが成長できる
  • 暗黙知形式知にしたい
  • チームが力を最大限に発揮出来る

DocBaseの特長

  • URL一つだけの小さな情報も気軽に投稿できる
  • Slackなどにながれる有用な情報をためておける

このコードおかしいから直したい、だとか流れて消えてしまうにはもったいない情報なのかなと思います。
本当によくあることだと思います。

小さく始める

  • 小さな情報をまとめて有用な情報にできる
  • まとめ機能は手順書を作るときに役立つ

関係者全員で情報共有できる

  • 柔軟な権限設定:組織全員だったりプロジェクトごとだったり
  • シンプルなUIでエンジニア以外も使いやすい
  • ユーザー数無制限

  • いろんなアプリごとにデザインのスクリーンショットをとったりしている

  • スクリーンショット貼り付けの機能は、メンバーがいつの間にか入れていた
  • ヘルプセンターに機能の使い方がかれている ** テーブルを超簡単に作成する方法など

  • esaはマークダウンでスライドにできる ** かなり使われている!

  • メモを開いたときに可変にならない 画像の問題があった 広げる機能を作る予定

  • esaは画像についてはオリジナルを出している

アクティブユーザー2倍

  • 共有されたドキュメント数 2ヶ月で1万増

esaとの出会い

  • DocBaseのプロトタイプを作っている時期
  • 別の仕事で飲んでいたときに、同じタイミングでお互いに内々に作っていたのがわかった (うわ、やりづらくなったなぁ、というのはあった。) (出してから、お互い情報共有して)

設計と開発

新サービスを作りたい

  • 受託も楽しいけど

小さく始めるしかない

 サービス検討を小さく

Amazonを真似して、プレスリリースを作る

  • サービスの概要、問題アピールポイントなどをプレスリリースの形式でまとめます。
  • ワーキングバックワード法

モック画面を作る

  • 一番価値があると考えている画面を作って検討
  • 10ぐらいのアイデアから1つに絞り込んだ。

  • 企画会議

  • お菓子を置いてお菓子を食べながら

作るもの決まったぞ!

社内の意見など

  • リソース割くけど、利益出る?

小さく始める

小さなチーム作り

  • 最初のチームはエンジニア3人と私の4人。
  • 受託開発と並行

価値検証したい部分だけ作る

  • モック画面を開発合宿で作って、社内で検証
  • 日光にあるペンション ついたらすごい大雪になって、次の日の朝すぐに帰った 帰りの電車の中でも作った

ドッグフーディング

  • 社内でリリース

社内インタビュー

  • 小さく早く回す

プチ合宿

  • 金曜15時から18時までカフェに集まって開発

社内の意見

  • EvernoteやQiita:teamあるけど使ってくれるの?

小さく始める

  • 社内のみで公開

  • アイディアもすぐやめれる サービス自体も。。。

  • ログインの機能などいろんないらないものはつくらなかった。

  • 社内でリリースした機能を公開 Evernote

  • 仮説検証のサイクルをまわしやすい

感想ですが、ドッグフーディングであると同時に完全に仮説検証可能な最小限のプロダクトで何回も仮説検証を回すという、MVPのアプローチになっていると思います。

社外10社くらいに限定公開

  • 自分たち以外にも役立つか判断しやすい
  • 実験的な機能を盛り込みやすい
  • 完璧をめざさなくていい
  • 価値がないとつかってくれないのでわかりやすい

  • 中途半端な機能実装もまだ実験的なので、ということがいえた

クローズドβで少しずつ公開

  • 事前登録してもらって1週間に10社ずつ招待
  • サポートにたくさん意見をもらえた
  • アップデート後のはんのうがわかりやすい
  • まだ辞められるという安心感
  • そろそろ後戻りができなくなるという不安感

質問: ペルソナを作ったり、アーリーアダプターにユーザーインタビューとかした?

  • 自分たちが使ってみたいユーザ ドッグフーディング
  • こんなプロトタイプがあるんですが、つかってみたいですか?
  • 3社くらいは興味なし、2社くらいは使ってみたい

質問: バージョンの切り方 どこまで作ったらリリースみたいなこと

  • あいまい
  • 2週間のイテレーションのサイクルで出せる方が良い
  • esaの場合はできた段階で出す。

社内のこういうことがしたい、という思いに共感して

課題

  • 検索改善 ElasticSearch
  • 複合で検索できるように
  • elastic searchをAWS側に
  • サービス側からはindexのみにしてセキュリティのリスクを下げる
  • デザイン改善
  • より伝わりやすくするための生理機能
  • 規模が大きい組織向けの大規模対応
  • 画像以外のファイルも対応、ファイル添付
  • もっとスマホから使いやすくするスマホ対応改善

質問: 企画会議などで社内の冷静な意見が出ていた頃、開発メンバーは企画者の思いに共感していたの?(この質問は自分がぶつけてみました)
* 最初は半信半疑だった * なぜなぜ分析などで「なぜ情報共有するのか」などを繰り返した * ドッグフーディングで、社内の意見もクライアントの意見も集まるようになって「これはいけるぞ」という雰囲気になってきた。

なんか本当に素晴らしいと思います。

そしてesaのお話

speakerdeck.com

esa LLC 深谷 篤生(@fukayatsu)さん 赤塚 妙子(@ken_c_lo)

情報を育てたい

  • 最初から完璧を目指さず

WIP

  • 途中でもとりあえず共有
  • みんなにも共有するけど、積極的に通知はしない

WIPをつけるときのきもち

  • こんな感じで考えているんだけど、細かいツッコミはやめてね
  • WIPはエクスキューズ ゆるい感じにする
  • できなかったことができる 書けなかったことが書ける

自分のために書く「ドキュメント」

ユーザー属性

  • チーム規模: 1〜126ユーザー
  • 有料ユーザーの30パーセントが個人ユーザー

一人ユーザーが多い

  • メモ整理アイデアまとめ原稿執筆など
  • alt Evernote
  • 家庭内esa 夫婦カップル
  • 育児や夕食の連絡
  • ゲームのコミュニティ

プログラマ好みの機能・設計

  • 高いカスタマイズ性
  • API
  • シンプルでフラットな設計
  • UIは基本英語

プログラマ好みにした理由

プログラマでもわかりやすい

質問: 見た目テーマ変えないの?

楽しいから、毎日作り続けてる

  • ユーザーのフィードバックがイシューになる
  • 982フィードバック 1000を取った人には何かaword

土日が活発・次点で木曜日

リリースノート9月から100

  • 週1、2回

標準的なリリースのサイクル

  • ユーザからのフィードバック 自分で思いついた機能をGitHubのissueに
  • GitHub Flowにしたがってブランチを作るい、適宜pushしながら実装
  • 導線だけつぶして、公開していることも

毎日がドッグフィーティング

  • 周囲の仲間達とesaで日報を共有
  • 業務委託先の会社でもesa
  • esa社のesa
  • 実家への連絡もesa
  • IT強くなくてもギリギリつかってもらえる
  • DocBase 子供の教育方針 交通事故にあったときの種々の連絡先

スケジュール・ノルマはなし

  • 締め切りによる心理的負担を減らして、より良い選択をしたい
  • 締め切りによるその後の開発も窮屈になってしまう。

Staging環境

  • まだない
  • 本物のデータで確認

Heroku

障害監視

  • Pingdom + PagerDuty
  • サービスダウンしたときに携帯に電話

リリースノート

  • esa上で運営してドッグフーディング
  • webhookで受け取ることができる
  • メール slack

質問: やりたいことをきめるのはどうする?
* 二人同時並行 お互い手伝う * mockまではつくってる これはなしだよ みたいな話はする。 * どうしても収束しない場合は放置 ABなどはしない

カスタマーサポート

フィードバックに5分で返信する

質問に対して、「はい/いいえ」よりも良い返事がある

  • 「xxの機能はありますか?」
  • ユーザの問題はなんだろうか
  • それを現状の機能で解決できるだろうか
  • 他にも応急的な策はあるか?

バグ修正や簡単で効果的な機能追加はその場で実装してすぐにリリース数r

  • サポート中はモチベーションが一番高い

いろいろなチャンネルを使う

  • Web/e-mail/Twitter/直接
  • エゴサーチ

  • 既存の機能の改修ならすぐできる

  • フィードバックが同僚の意見の代わり
  • 井戸端というチャットツールでもフィードバックをもらっている

イベントでプレゼンする

  • 特に技術系のイベントでの登壇

技術系のイベント・コミュニティにツール提供のスポンサーをする

  • 運営チーム向けにesaの1チームを無償提供する
  • 東京Node学園祭2015
  • RubyKaigi2015
  • Wikiガチ勢からのフィードバック

Twitterであそぶ

  • esaアカウント

モチベーション とても大切

  • for motivaated teams
  • 使う人 作る人 両方大切

フィードバックをもらう

  • クレームは宝
  • どんな厳しい意見

リリースノート書きたい

  • 書くのが楽、楽しい
  • リリースノート駆動開発

esaらしさ

esaらしい」こと

  • 上から何かを強要しない
  • 気づいたらそこにあった

「無名の質」

esa LLCについて

2人でいろいろやる

開発者、経営者、ユーザ

2人だと開発スピードは遅い?

  • 現段階ではそうでもない感じ
  • 意思決定のスピードの速さ
  • 多少苦手だった営業などもesaのためだったらやれる 視野が広がる
  • 稼ぐべきお金が少なくて済む
  • 決定権は50・50
  • 得意な領域が違うのでケースバイケース

もともと趣味から始めた

  • Qiita:teamのクローンを2013年の11月につくって満足して放置していた
  • 開発合宿でブラッシュアップした
  • pplog
  • 知り合いのエンジニアさんにiphoneアプリを作ってもらった直後に、深谷さんが勝手にandroidアプリを作っていた 知り合う
  • Qiita:teamフロー

会社よりもプロダクトが先

  • esaのサービスコンセプトが会社のコンセプト

We are not startup.

  • 出資を受けていない
  • 急激に拡大することを目指していない

経済状況

  • 受託とesaの秀英きトントンくらい
  • 週に数日スタートアップのお手伝い
  • フルコミットの受託は受けられない
  • esaの収益だけで食べていくことが当面の目

これから

  • ネイティブアプリ
  • 決済連結機能
  • 検索改善
  • スピードアップ
  • alt Wiki的な可能性
  • GitHubPageのesa

使われても楽しい 自分たちで使っても楽しい

趣味から始めた「楽しさ」をどこまでも維持したい

質問: 大企業 外に繋げないなど オンプレミスはできないの? GitHubEnterpriseのように
* クラウドに依存している S3とかあるので難しいが検討したい。

質問: オフラインモード * 深谷さんがその場でイシュー作ってました!!

感想

esaの新コンセプトであるmotivated teamsですが、この会は参加者が少なかったのもありますが、本当に発表者、そして発表してないほうの発表者、参加者のあいだで活発に質問や意見交換が行われていて、すばらしい会でした。
主催の中村さんも、いつもこんなセッションができたらいいのにというお話をされていました。

この会のあと、電車で帰るときに中村さんに「(この2チームのように)Productに共感して開発したい」という気持ちを伝えたのですが、「共感は出来なくても理解、納得して作らないといけない」との言葉をいただきました。 esaやdocbaseのようにプロダクトに寄り添う仕事がしたいし、 受託案件だったとしてもやることに納得できる案件をとってきてくれるんじゃないかと信頼をして仕事がしたいです。

繰り返し、DocBaseの開発チームの話ですが、

  • 最初は開発メンバーも納得していなかった
  • そこからMVP的なアプローチ、ドッグフーディングで小さく小さく検証しながらプロダクトを育ててきた
  • 社内の冷静な意見もそうやって説得してきた。

というエピソードを聞いて、最もMotivated teamsにふさわしいチームなのではないかと感じました。 最もesaにふさわしいチームがdocbaseを作っていた。つまり、貴族主義は最初から間違っていたんだよ、ザビーネ!

esaとdocbaseこんなになかいいことも知れたし、2つのプロダクトの今後についてフワフワした期待感とともに非常に気になります。

発表者の3名様、DevLove主催の中村さん、参加者の皆さま、そして会場を提供してくれたTAMさん、本当にありがとうございました。

『board』のサービス開発の現場 #DevKan

『board』のサービス開発の現場 #DevKan

ヴェルク株式会社代表取締役 田向 祐介さん

2015年9月18日にあった表題のDevlove関西の勉強会に参加してきました。

 

devlove-kansai.doorkeeper.jp

 

boardとは

the-board.jp

 ドッグフーディングとは、自分たちの作ったものを自分たちの業務でも実際に使うという開発スタイルだそうです。(※指摘により修正しました)

会社としては受託の事業がメインで受託が好き が、波がある

なぜ受託が好きなのか、ということを質問してみましたが、自分の知らないいろんなビジネスに携われるからとのこと。

 

私も前職はSIerでしたので、新しいビジネスプロセスにかかわれるときは面白かったです。つらいときはつらかったけど。

そういうつらい状態をなくすために、いい案件を受託するといった努力もしているそうです。

 

自社サービスの運用を開始した。

本業の受託とのバランスが難しい。

 

受託の会社なので、要件の検討などはお客様がやったものが降ってくる

つまり、要件の検討などの経験がない。

 

最初に作ったのはiphoneアプリ

ブレストのやり方を習得

  • イデア100個を1時間に出す
  • 整理する

繰り返し

 

想像以上にうまくいかない!

 次にやったのがスマホアプリCMS「Patto」

初めての自社サービス事業

営業はいないのでインバウンドマーケティング

ソリューション型なのでお客様の要望を聞く受託に近い

自分たちに近い領域からはじめることが大事

 これは本当に思います。

自分の知らないことをいきなり始めようとしてもうまくいかないだろうなぁ・・・

とはいえやらないといけないときもあるのですが

要件どおりに作ることではなく顧客の満足を目指すならば

 

そして4年目にboardのサービスを始めた

受託が炎上していたら自社サービスの開発は出来ない。

(会社の)自分への依存度を下げる

どういうことかというと、代表である自分がほとんど営業して案件をとってきて案件の実現や管理部分も自分がこなしてしまうことが多かった。

そういうことからの脱却を目指すために、やったのはリスク感覚の一致

トライアンドエラーを繰り返すことで、「アラートあげすぎ」などの違和感をなくしていった。

 これはあるあるですね。

能力のあるなし、にかかわらず心配しすぎのせいで前に進めない、リスクを取れないということを自分もしてしまいがちです。

そういった部分が一致しているチームでないと仕事はすごくやりにくい。。。

boardは会社を経営するうえでほしいから作った

(受託IT会社の)経営者視点で開発

売り上げの予想なども出来るようにしたい

開発している自分たちがユーザ

ドッグフーディングできるか?

→自分たちが検証

本質的なニーズを探り出す

機能としては満たすが業務としてはあっていない、というようなことをなくす。

自分事なので調査がいらない。

 これがわかるのは本当に大きい。

要件の通りに作ったのに、結果として顧客の業務を円滑に進めることが出来ないということは多々ある。

顧客と常に対話できる状態ならいいのですが(そういう状態を作り出すところがアジャイルの真髄だとは思います。)

 

ドッグフーディングのデメリット

自分に最適化されすぎて、一般のユーザにとって正しくない可能性

初めて見たときの感覚を失い、新規ユーザへの配慮がなくなる

 

 

この問題の解決のために、テストやる人には詳細な実装内容を伝えず始めて使う状態でやっている。

本当はユーザビリティテストなどをやったほうがいいんだろうけど、受託をやりながら、しかも週に1度のリリースサイクルを実現しているためやっている時間がない。

サービスインして自分たちだけで本番環境を試す仕組み

 

本番環境がいちばん正確ですね

無駄なものを作らない

いついつまでというリリースポイントを決める

リリースは一週間に一回

少し足りないくらいでリリースする

最初は怖い

ユーザに言われなかったら実はいらない機能だったことがわかる。

言われたら対応することで、顧客の要望にこたえることにもなる。

 なるほど。したたかな感じ。

中途半端なかかわりのメンバーはなくす

案件の波やタスクの内容とタイミングを調整する

 

ユーザはIT業界が圧倒的に多い

会社半分くらいが2~10人

 

受け入れ中で暇だった9月のシルバーウィークに寝ずにプロトタイプを作った

欲しい機能 使い勝手 の6割くらいは9月末までに実装

10月に社内テストを実施し、2月にClose, 5月にPublic Beta

5月は受託で忙しく、製品化した8月までほとんど機能は追加していない

 何か作ったりするときにはやっぱり寝ずにやるくらいの勢いが要りますね。

 
優先度の決め方について

自分が欲しいもの

やってないことのうち 納得できるもの

声の大きい人の意見を優先しない。

全部やったらシンプルさがなくなる

boardを好きになってくれるユーザが増えてきた

そういうユーザの求める優先度もだんだん同じに

 不思議な感じがします。

 

コストかけすぎない

受託もやりながら

広報とSEOは協力を仰ぐ

汎用性はない → 差別化

 

大事なこととして、受託もboardの開発も大きな山を作らないこと

リリースは週に1度

山があるとほかのことがとまってしまう。

開発だけやっても何にもならない。

 確かに、大きな案件に集中しすぎてしまうとほかの案件にまったく手をつけられない状態になることがよくあります。

マルチタスクにしないことも大事だと思いますが。。。

小さいタスク1週に1個

中タスク 月1個

大タスク 年1個 (大規模なリファクタリングとか)

技術的な負債の返済

 

ペースの維持

 チェンジオブペースなんて使う必要はないですね。(言ってみたかっただけ)

ロードマップは公開していて、一貫している

合議制はとらない!

 作ってるのが2人とのことですが、ダイアログのときにも出たけれどやさしい独裁者みたいな感じに思えます。

経営者視点だけで気づかないこと

  • 捺印申請の機能

期限のみ入れれるようにした

捺印申請出す側としては「上司に日付だけの申請は失礼」という意見があり、コメントを入れられるようにした。

独自の習慣などの要望はお断りする勇気を持つ

カスタマーサポートは自分でやっていて、何でやらないかをとうとうと論理づけて伝える。

 これは単純にすごいです。

 

開発ロードマップを公開することで、ロードマップがあるから使うことにしましたといったユーザも出てきた。

公開ロードマップがあることで自分へのいいプレッシャーになる

時間がない ので メルマガやユーザビリティテストはできない

UI, UXをがんばっていても業務にフィットしていないと意味はない。

まさにその通り、だとおもいます。広義のUXには業務にフィットすることも入ると思うけれど 

売込みをする側からこの機能がUIこれだけ使いやすくすればユーザにとってメリットがあり、使ってくれる人が増える、売り上げが増えるといったことを考えていたとしても、結局業務にあっていないと意味がないんですよね。

この辺、小さく作って検証のサイクルを速く回すといったMVP的な最適化がなされている気もします。

(ユニット)テストは後回し

最初書かないとずっと書かなくなるといわれるが、がんばって書く

リリースの規模が小さいと

  • テストが楽
  • ストレスが小さい

でも主な目的はRailsがバージョンアップしたときのテストのため。

 そのため、カバレッジはがんばってあげる。

リリース時のテストは項目は出さない

テスト項目を出すと自分の見えている範囲しかテストしない

 うっ。

私もリリース前のテストは自分が変更した部分の確認といった感じになりがちですね。

このやり方のほうがいいのかも

ここで最初のほうに出たリスク感覚の共有といったことも生きてくるのでは。

CSは月100件

平均応答時間8分 即時対応

使えるだろう、と思った機能が使いにくいといったことがあるとき、反応がすぐ感じられる

サポートの実績を公開している

CS応対にはintercomというサービスを利用

固定費を最小にしている 継続のため

逆にintercomのようにこのくらいのコストは許容できるといった外部サービスはどんどん利用する

自分にあったスタンスで開発を続ける

 

 

 ダイアログも面白かったです。

チームの人数が重要ではないかという意見があり、ベンチャーなどのチームはメンバーが4人でも多いのではないかと。

意思決定はやさしい独裁者が理想。

「こういったドッグフーディングのサービス開発の導入をするにはどうしたらいいか?」

という話題には新しい技術を学ぶタイミングと、やりたいことを結びつければよいのではないかということでした。

そのために自分の欲しいものリスト(ネタ張)を作っておくことは大事です。

 

田向さん、ありがとうございました。

プレゼンの技術 #DevKan

2015年8月15日にあったDevlove関西の表題の勉強会に参加してきました。(書いてるの1月以上後になります。)

devlove-kansai.doorkeeper.jp

プレゼンの技術 考え方編

谷本 心さん
Achroquest Technology
JavaOne /Java Day Tokyoスピーカー
@cero_t

スライド資料リンク
プレゼンの技術 1 考え方


引用部分は主にスライドにそのまま書いてあることで、ほかの文はその場で発表者の方が言っていたことや、自分の感想を含みます。

プレゼンで大切なことは何か?

相手にメッセージを伝えること

相手の行動に影響

具体的には、「そのプロダクトを使ってもらう」「勉強のきっかけにしてもらう」など。
伝わって行動を変えるということがゴールですね。

自己紹介は大切
自分のポジションを明確にする。
自己紹介で示すポジション = メディア力 
「この人が入ったから説得力がある」

同じことをいうにしてもその人がどのポジションでいうことかということを明確にする → 説得力が生まれる。

プレゼンに大切な4つのこと

  1. 共感
  2. 価値の提供
  3. ストーリー
  4. メッセージ

1. 共感
問題意識の共有

共感または共感の裏返し

相手が共感しそうなエピソードや問題を選択すること。

× Java楽勝すぎフイタ
Javaのここが難しい

相手に伝わることを考えるとこの辺大事そうですね。
ひとりよがりな感じにならないようにしたい。

2.価値の提供
知識の共有 → ふーん
経験の共有 → みんな知りたい。それつかったらどうなるの?
思想の共有 → 理解できない

必ず先に「経験の共有」をしてから「思想の共有」へ

経験の共有一番大事。
あとで出てきますが、背景知識や共通認識が異なることによって生じる理解力の差がないようにしなければならないですね。

3. ストーリー
プレゼンは映画のようなもの
聴衆の心理を的確に誘導
序破急 3部構成ぐらいがちょうどいい

全く質の異なる2つの話を1つのセッションに詰め込んだ → 聴衆も混乱する

1番伝えたいメッセージを中核に据えて周りを肉付けするとストーリーを作りやすい

4. メッセージ

一番大事 相手に伝えたいことは何か?


せいぜい1つか2つしかおぼえてかえられない

「プレゼンターの思想」 が メッセージ

最初からメッセージありきにする必要はない
メッセージはプレゼンを作っている間に気づいたりする

一度メッセージが明確になればそれを目立たせるように演出すれば良い

何を伝えて相手の行動を変えるか?
せいぜい1つか2つしか覚えていられない、って関係ないけどジョジョ6部思い出しますね。
1つか2つしか覚えられないから、聴衆は必死にメモを取るわけです。

まとめ

  • 序 共感
  • 破 経験
  • 急 思想

さらにプレゼンの価値を上げるために大切な3つのこと

  • 笑い

大事。
プレゼンで学ぶのではなく、プレゼンできっかけを得てそれから自分で学ぶ
刺激を受けて楽しむために、プレゼンはエンターテインメントにする必要がある。

  • 裏切り

共感からの裏切りや共感からの意外性
聴衆にとっての「新発見」が重要
共感できない考えが時には新発見になる

  • 感動

感動こそ、人を動かすもっとも大きな感情

その他、、
夜中に書いたものは思考の視野が狭くなっている
面白いと思ったものが朝見るとあれってなることも。

感想としては『「経験から得た」プレゼンターの思想を伝えること』ができて、その結果として聞いた人が何か行動してくれれば勝ちという感じに思いました。
「ふーん」にならないようにするために、大事にすべきことはまずその1点かなと。

伝えるための試行錯誤、と言うか道草

@irofさん(Java界隈のプログラマ)

自分が一番初めに出たDevlove関西のテスト自動化についての勉強会でもGebとかを使ったテストを紹介されていた記憶があります。

スライド資料
伝えるための試行錯誤というか道草。

開発者コミュニティでのプレゼンでの話をします。

一般的なプレゼンでなく、背景知識が似やすい場であるということでしょうか?

やってきたこと

練習、練習、練習

やっぱり練習大事。。

本番は次の練習
練習場を確保する

自分主催なら何してもいいじゃん
知り合いだけの場なら話しやすいじゃん

継続は力
スタイルの模索 プレゼンツール

どれも一長一短
使ってると楽しい 
とりあえずKeynoteに落ち着いている

zen いいものだ。。。 準備に画像探しで時間が超かかるのでやめ。
高橋メソッド 自分のキャラに合わない

ふりかえり

楽しいことはいいことだ
いろいろツール使ってJSやpythonの知識はつく
テキストでかけることが重要

いまんとこKeynote


プログラマ
時間あんまりない
開発者コミュニティにはなす

普段してることをはなす

プレゼンに時間かけるよりコードの1行でも書くかドキュメントの1つでも読むほうがよいものが出来る。

思っていること

ハイコンテキスト 場に合わせた話

コミュニティのプレゼンと現場のプレゼンとかは全然違う
テクいプレゼントエモいプレゼンもぜんぜん違う

解釈までコントロールしようとしない → 軍隊を作るわけではない

「普段」の確認に良い
スライドにまとめるのは知識の再確認ができるし、

メッセージに目が向けられるとも限らない
メッセージは話者にとっては重要だけど、聴衆にとっては当たり前と思ってることのほうが重要な場合もある

おまけ:コミュニティで話したことない人へ
話すハードルを下げてみる

感想として、ツールやスタイルにこだわりすぎるのは自分も合わない気がします。
ですが、やっぱり発表の場を増やすことや練習を繰り返すことが着実に力になるとわかりました。
自分も「1行でもコードを書くべき」という意見には賛成です。(自分はそこまで実践できてないけど...。)


プレゼンの技術 実践編

再び谷本さん

スライド資料
プレゼンの技術 2 実践編

じゃあ具体的にどうすればいいの?

歴史と思想の話

ピラミッド
理 世の道理を明らかにし社会を作る額の時代
心 心を支配し、価値を作る芸の時代
知 知恵と情報の商の時代
物 工の時代
体 農の時代

1.体を鍛えて勝つ
2.用具や技術で勝つ
3.戦術・戦略で勝つ
4.心理戦で勝つ
5.知らんがな

1.操作に慣れて勝つ
2.連続技で勝つ
3.返し技を覚えて勝つ
4.心理戦で勝つ
読み合いでやる人とルールでやる人
ルールでやる人のほうが強い 読み負けた人はダメージを受ける
5.ゲームの真理で勝つ
コミュニティで勝つ

ウメハラ このゲームとはどういうゲームなのかというのを考えている 真理を追究

最近、↓の本買いました。
格闘ゲームの場面展開はものすごく速いけど、このゲームとはどういう(どうすれば勝てる)ゲームなのかという「視点」を大事にして戦う、自分をビルドアップすることの大切さが書いてあります。
谷本さんも読んでるかもしれないけどどうなんだろう。www.amazon.co.jp

プレゼンも同じ
さっきまでのはほとんど知のフェーズ
笑い、裏切りは心のフェーズ

体と物は?

1. 体のフェーズ

練習しろ
発表

大事なプレゼンのときは社内で3回くらいリハーサルしています

CA Tech Kids
むちゃくちゃプレゼンがうまい小学生

毎週、テンプレート通りの簡単な発表を繰り返す
3ヶ月に一度、親も読んで大きな発表をする

アドリブでなく台詞は全て暗記

プレゼンだけでもうまくなるにはこうした練習が必要。
考えてみれば当たり前のことだけど...。

TPOと自分に合ったスタイルで
Zenスタイル
印象がよく伝わる xむっちゃ時間かかる

こんな風に話したいという目標を見つける
憧れではなく目標で

マインドマップ書いてますか?

プレゼンの構造とマインドマップは抜群に相性が良い
発散 整理 構造化

物事を発散させる思考プロセス → マインドマップ

マインドマップで薄いところをあとから広げるのは不可能
知らないことを無理やり調べながら書く必要はない
本当に自分が話せることを話そう

プレゼンの秘訣は「仕事を頑張ること」

すごくいい仕事をしたり、すごく悩んだりしたこと

「誰」に向けて話す = コンテキスト

ハイコンテキスト
1を聴いて10を知る

ローコンテキスト
1をきいて1を知る

もっと低いローコンテキスト

背景知識や共通認識が異なることによって生じる理解力の差

プレゼンを聞く相手に合わせて共感の内容と説明の厚さを変える

心のフェーズ

プレゼンターよ、芸人たれ

プレゼンは脚本でプレゼンターは役者です

自分が好きなストーリーを脚本に

笑点の前半を参考にしよう

プレゼンを聞く相手に合わせて共感の内容と説明の厚さを変えるというのは、逆のパターンで言うとirofさんのいっていた「自分主催なら何してもいいじゃん」というやつかなあと思います。
話すのを背景知識の共有が出来たハイコンテキストの場に限定してしまえば、敷居は低くなると思います。
何も博愛主義的に聞きに来る人みんなが大事、というよりも本当に伝えたい層限定に伝えるほうが楽かな、、とはおもいます。
プレゼンの秘訣は「仕事を頑張ること」、まさにその通りであってほしいところです。
プレゼンの資料を作るタイミングが逆に自分の仕事を振り返るタイミングにもなるそうです。
その振り返りで自分の仕事がきっちり出来ていなければプレゼンの質に影響しそうです。

谷本さん、irofさん、ありがとうございました。

『クラウド時代のエンジニアの役割〜AWSを使い続けて気づいたこと〜』#DevKan

2015.07.24にあった表題のDevLove関西の勉強会に参加してきました。

クラウドアーキテクチャを変え、エンジニアの役割も変わる

佐々木拓郎さん NRIネットコム株式会社

www.slideshare.net

概要

クラウドファーストからクラウドネイティブへ
オンプレミスの提案だけだと「なんでクラウドの提案もないのか?」というようなことを訊かれるクラウドファースト時代になってきている。
データとその処理をサーバで変換する必要があった3-Tierのクラウドアーキテクチャから、データやストレージまたは計算処理(Lambda)に対して直接操作ができる2-Tierアーキテクチャが実現されつつある。

サーバの構築がほぼ不要で、パーツの組み合わせだけでサービスの構築が可能

Lambdaで計算処理はサーバレスでできるようになったが、APIとして利用するためにはサーバが必要だった。。。

Amazon API Gateway
が、「Amazon API Gateway」がLambdaやAWSの各サービスをHTTP/sのProxyとして呼び出せるAPI作成支援サービスとしてつい先日登場した。
とんでもないインパクトで、フレームワークの登場とにている→コードを記述する量がとんでもなく減る

クラウド時代のエンジニアの役割について

インフラなども含めてコード化できることが必須かつ、コード化される範囲が広がるので、その上に何を付加できるのかといったアーキテクチャの知識も必要になってくる

赤魔道士的な立ち位置
黒も白もつかえる器用貧乏 → クラウドという強力なアイテムがあると何倍も力が増幅される?

ガチガチではなく、変化を楽しんで対応出来る能力を身につけよう

アプリエンジニアからクラウド専用のインフラエンジニアになってみて

佐藤瞬さん NRIネットコム株式会社

www.slideshare.net

概要

AWSを触り始めて感じたのは、ドキュメントや手厚いサポートなどの「情報量の多さ・取得のしやすさ」
つまったのは、ネットワーク周り
ほとんどがプログラマブルに構築できる → コードか必須になってきている

AWS構築のコード化

CloudFormation 便利。テンプレートのJSONつらい (たしかにそう。。。)

kumogataでCloudFormationのテンプレートをrubyで記述

OSミドルウェアの構築

  • Chef クライアントが必要
  • Ansible Yamlがつらい

そこでItamaeです。ChefとAnsibleのいいとこ取り

デプロイのコード化
fabricとのこと。なぜcapistranoではないんだろう?

運用のコード化
hubotとslackでChatops。セキュリティの観点からあまり深いことはやらせていない

こちらの発表でも「API Gateway」の衝撃について触れられてました。
「楽しそう。でもインフラエンジニア廃業かな。。。」

これからのサービスの構築

まずサーバレスで構築(フロントエンド/モバイル+API Gateway/Lambda)

サーバレスでは厳しい面について、EC2上にアプリケーションサーバ

  • ユーザ認証
  • RDSとの接続
  • クローズドなネットワーク

インフラエンジニアとしては、EC2上にアプリケーションを構築する上で、何がサーバレスで問題だったのか、どうやったら解決するか、アプリケーションにはどのような要件が必要かという現状を把握できることが必要。

感想

クラウドファーストだけでなく、クラウドを徹底的に活用すること前提の時代もすぐそこまで来ているのだなーと感じました。
自分はアプリエンジニア寄りなので、APIgateway及びLambdaは早く触らないといけないと思います。
Dockerの勉強会でも言われていましたが、技術に依存してしまうのではなく変化を楽しんで適応する能力が一番重要だとのことでした。
そのためにはどの方向から攻撃が来ても受け流せる猫足立ちを身につけないとですね。
インフラエンジニアでもフロントエンドを勉強し始めているとのこと。
ほんとに隣接した領域の知識も必要になってきている感じです。
お二人ともありがとうございました。
とりあえず紹介されていた本買ってみよう。

『自分戦略〜エバンジェリスト編〜』#DevKanに参加してきました。

2015.04.18に行われた標題のDevLove関西の勉強会に参加してきました。

スライドは公開されていない発表もあったため、今回は感想だけです。

長沢智治はなぜエバンジェリストになってしまったのか?なぜやり続けるのか?

長沢智治さん

感想

ベルトを巻いておられます。 ディケイドの模様
エバンジェリストは製品中心と思い込んでいましたが、顧客・企業・製品のバランスをとっていくということが大事ということになるほどと思いました。
エバンジェリストである以前に、「現場自身が変わる能力をもたせたい」という目的のために行動しているという感じを強く受けました。
そのためにもっているエバンジェリストとしての武器として、「その気にさせる」影響力、「コミュニティ・市場に通りすがって助ける」行動力が大事なのかなと感じました。 キャリアとしてエバンジェリストを考えた時に、その元となる熱意・モチベーションと自分の行動・成果を管理するためのマネジメーントの能力を兼ね備えていないと続けていくのは難しそうだと感じました。


「#てらだよしおがんばれ」 の誕生秘話について

寺田 佳央さん

感想

プライドと意地、大事だと感じました。
謝罪会見になってしまったというお話については、渦中に飛び込んでみて正直に伝えるということをやってみることで成長に繋がっていくというストーリーが伝わってきました。
悲惨な状況から、JavaOneTokyoを必死に成功に導いたときの男泣きの写真がかっこよかったです。

エバンジェリストに必要なのは
「覚悟と情熱」
『「**」にたいしては誰よりも一番愛していると思えること』

そういう覚悟や情熱を得られるのは、長沢さんもおっしゃられてたように正直に技術やコミュニティに向き合っているからだと思います。


「モノづくりのとマーケティングのはざまからエンジニアの役割を考える」

染田 貴志さん

感想

「染田、エバンジェリストやめるってよ」という出落ち!

起業してCTOになったときの「対価を得ることの難しさ・大切さ・売り上げが0になっていることは辛い・悔しいという原体験」からくる覚悟・熱意というのが非常にインパクトが大きいと感じます。
自分もそういう覚悟・熱意というものを何とかして得たいです。 ヌーラボに参画してからはモノづくりの目的が「少しでも世界をよりよくする、だけではだめでその結果、自分たちも幸せになる」という風に変わり、エンジニアリングとマーケティングのアンバランスの解消を手伝うためにグレーゾーンに踏み込んでいく、そのためのエバンジェリストというお話でした。
エバンジェリストというロールをやめたとしても、エンジニアとマーケティングの橋渡しをしていくことを続けるそうです。
うちの会社でも「ビジネスを考える人と開発をする人が日々一緒に働く」ということの大事さが骨身にしみています。 エンジニアリングのこともわかってくれているPOの案件では非常に仕事がやりやすいです。
そういう架け橋をかけてくれるのはとても大事だと思います。