ひつじのにっき

mhidakaのにっきです。たまに長文、気が向いたとき更新。

メルペイのエンジニアリングマネージャーとして働いています

今年も一年、おつかれさまでした。

この日記を書いている時点では12月27日です。弊社の暦に従えばあと2営業日ぐらいありますが、すでに仕事を納めたひとも多いので誤差の範疇でしょう。

あなたは誰?

メルペイでAndroidのエンジニアリングマネージャーをしているmhdiakaです。

日記をよんでいるみなさんが観測できる範囲だと技術書典というイベントの主宰やDroidKaigiというカンファレンスのオーガナイザーやKotlinFestのお手伝い、四半期ごとに2~3冊、年に10冊程度の技術書を執筆したり編集したり、たまに寄稿などしています。これだけよむと働いてるのか?って思いますよね。(このあたりの作業は業務時間もつかっているので)働いてます。

最近また技術書をつくりました。今の期間だけ予約してるのでAndroid開発してるひとは見てね

techbooster.booth.pm

エンジニアリングマネージャー振り返り

さて本題です。僕はエンジニアリングマネージャーという役割は組織次第で求められる内容が違うと考えています。なので、この振り返りがエンジニアリングマネージャーという役割を俯瞰的に考える役に立つかわからないなぁ、と感じてます。

でも、年末だし、自分の区切りがいいのでメルペイという新しい組織(このまえ1年目の誕生日を迎えました)のなかでの経験を書いておこうと思います。

具体的な事例とかは書けないのだけどAndroidチームのはじめてのエンジニアリングマネージャーを経験しているので「そういうEMもいるよな」という一形態として何かの参考になれば幸いです。

※この記事は個人の見解であり、所属する組織を代表するものではありません。

なぜEMになったか

ひらたくまとめると「EMがいるほうがエンジニアリングがスムーズで、ちょうど僕が組織にコミュニケーション・働きやすい環境を整備する上での課題を感じ、解決したかった」からです。なので、じゃあやりますと手を上げたのが今年の5~6月あたりです。(直接聞いたわけじゃないけど、EMへは同僚のBackend EMのcocoitiが推してくれたんだとおもう。この流れでよく信頼して任せてくれたなぁ、と今になって感じている)

次の記事に詳しいので興味がある人は読んでください。説明が大変なので詳細は割愛します。

会社のミッションとValues

メルペイはメルカリのグループ企業なんですがミッションは少しちがってます(Valuesは一緒)。 

そもそも僕はソウゾウからの異動だったので会社のミッションに強い共感があって入社したという性質の人間ではなかったんですよね。ソウゾウではエキスパートという役割だった(いまも兼務している)ので社会貢献やコミュニティ・OSSへのコントリビュートの意識が強く感じていたのを覚えてます。実は不良な社員かもしれない。

ミッション:

 信用を創造して、なめらかな社会を創る。

Values:

 Go Bold ー大胆にやろう

 All for One ー 全ては成功のために

 Be Professional ー プロフェッショナルであれ

メルカリという会社ではミッションやValues(行動指針みたいなの)を共有できているかがめちゃくちゃ大事です。組織の中でコミュニケーション、それこそ会議、Slack、会話どこでも使われてるんですよね。

でもメルペイは急成長してて中途の社員もドンドンはいってくる。加速度的な拡大なのでミッションとValuesで会話できるようにならないと目線が合わない。マネージャーとして働く上では死活問題になりつつあった。

最初のマネージャー研修でメルカリ社長の小泉さんに「Valuesはとにかく飽きられるぐらいしつこく使ってほしい」「このマネージャー、またValuesの話してるよって思われるぐらいでちょうどいい」って教えてもらってて、

なんとなくの理解を言語化して繰り返して伝えることを意識して実行してました。Valuesが会社に根付いていることの何が良いかというと、行動の判断基準を形作れるのがすごい。マネージャーが何かを言わなくてもメンバーでプロダクトのために必要なことをValuesに即して考えて、実行できてるシーンを何度も見ては「なるほどなぁ、これが自律する組織か」と妙な関心をしてたのを覚えてる。

それからは話す時もValuesを積極的に使うようにしてます(たまに社外でも使ったり、メンタリングしようとしてしまって良くない)。

正直、自分自身はマネージャーとして何かメンバーに仕事の指示をしたかと言われるとタッチしてない自覚があって、プロジェクトアサインやチーム間の調整とかエンジニアリングの環境を整えることに注力して過ごしてた。

マネージャーとしての気付き

僕からみたメルペイは自由な職場です。裁量を持って良いプロダクト・サービス開発に打ち込める。でも会社が抱える課題はめちゃくちゃあるから順風満帆という意味ではなさそう。他の会社で1年かけておきるような変化が3ヶ月で発生してると思うぐらい活発に動いてる。

とくに組織が大きくなる中で未整備の事柄が目についてしまうことも多くて、例えばマネージャーの数がたりてなかったり(本来マネージャーがケアすべき内容が抜け落ちるのでストレスがかかる)、チームを超えた共同作業に努力を払う必要がある(これはプロジェクトが大きくて関係者が多いことに起因するかもしれないし、初めてというだけで、もっと大きなプロジェクトをやってる側からみると妥当なコストなのかもしれない)。

入社してから数えて2年弱しかたってないんだけど、この組織は常に新しい課題に直面しつつ、前に進んできたので致命的な課題が放置されることはまずないだろう。

メルペイでは仕事を進めるためには、問題をシャットアウトするより、課題解決に一緒に取り組んで価値を最大化するほうが効率的だと感じる(もちろん問題の種類によってはNoというべきものもあるんだけど、マネージャーに持ち込まれる問題の殆どが複雑なもので単純な判断が出来ない事が多い。これは単純な問題はValuesに基づいてちゃっちゃと解決してしまっている事象の裏返しなのだとおもう)。

マネージャーとして何をやったか

働きやすい環境を作るのに腐心していた。会社で進めたのはモバイルエンジニア全員へのiMac Proの導入や開発端末の購入/整備、プロジェクトの初期検討、見積、開発推進、関連するピープルマネジメント。

正直EMをはじめた最初の1~2ヶ月はストレスも大きかったし、うまく回すためのなにかが足りてなかったとおもう。ほとんどの事柄は回りの環境に助けられたことと試行錯誤を通じて手に入れたと感じてる。マネジメントをするのは初めてではなかったのだけど前の職のスキルが生きたかといわれると部分的にしか使えなかった。

そういう中で自分に足りない未知のスキルを手に入れようと思うととにかく経験してすばやく失敗・成功を繰り返すしかない。 

大事なのは「失敗するかもしれないが、こいつは俺のことを助けてくれるやつだ」という信頼だと感じていて、そのためにはマネージメントを手伝いだしてすぐに自分が何を考えているのかという所信表明を社内Wikiに書いたりした(メルカリに所属しているひとだけが見れるので、運良くアクセス権があるなら探してみてもいいかも)。信用貯金は大切だなぁと。

振り返るとAndroidのEMが1人ということもあり社内のほぼすべてのプロジェクトをみている。正直人智を超えている気がするが、やればできた。これは素養があったとみるべきで、普段からイベント運営や執筆などでマルチスレッドで動くくせがあったのでなんとかなったのかもしれない※。

※クオーターの振り返りがまだなのでいま時点でメンバーからの評価は聞いてない。なので本当に自分がよいマネージャーであったかは不明だと書き添えておく(個人的に評価をされる側というのは本当に苦手だがこれは慣れの側面はありそう)。

そのなかでも半年でAndroidチームの開発者数を倍にしたことは良くも悪くも影響があったと感じてて、良い影響は開発プロジェクトの並列化、速度の向上で、単純にやりたいことができるのは良いことだ。一方、短期でのオンボーディングの難しさもそうだし、Non Japanese Speakerも多い(英語も頑張って学習し直している)。さらにAndroid開発で10人を超える規模というのはほとんどの人が経験したことがない未知の世界ではなかろうか。まるでわからないのでいろんな事例を集めた(海外のカンファレンスでは結構事例がシェアされているのでおすすめ)。

当然、ミッションに共感して入社してきた人たちには転職を良いものと感じて欲しいので、そのための努力はたくさん払った。自分自身も優秀なひとたちと一緒に働くことはいつになってもワクワクする。今後効率化や新しいテクノロジーの導入など僕では成し遂げられないことがチームワークによって実現できると思うと最高に面白い。

幸いにしてチームを支えてくれる組織的な支援もあり(これは急ピッチで整備された良い点だ)、技術組織ではCTOのsowawa, VPoEのhidek、ほかのEMsが一緒になってエンジニアリングを考えてくれてる(階層化が発生していないフラットな組織を維持している)。

追伸1:蛇足だけどメルペイにはマネージャー合宿や開発合宿、全員でオフサイトするという文化があるんだけど福利厚生だと感じるぐらいには面白い。

追伸2:余談だけど人の頭のなかにはオンメモリでWorkする容量の上限があって並行作業が多いとドンドン抜け落ちる。とくに僕の場合、コーディングとマネジメントは食い合わせが悪くてコンテキストスイッチのコストが高いのでコードは書いていない(書くEMもいる)。

2019年の自分

ここまでEMの話を書いていて、ちゃぶ台をひっくりがえすようで申し訳ないが、2019年1月からはエンジニアリングマネージャーというロールからは一旦離れて、もともとのエキスパートチームという社会貢献と社内開発のバランスをとった役割にもどります。

これはいくつか理由があるんだけど、ひとつめは最初から期限を切って、パフォーマンスを最大化しようと決めていたこと。ふたつめは新しい課題にうまく対応できるEMが入社してくれたから。

ひとつめは、エキスパートの業務とエンジニアリングマネージャーを兼務している状況は長く続けるのは難しいだろうなという視点があった。二足のわらじの状態を長くしててどちらも全力で打ち込めましたかと言われたとき、他のタスクが目に入っていると、どちらも100%というのは難しい(IT業界での0.5人月を信じてはいけないというはなしはよく聞くと思う)今回は期間のほうを短く設定して、どっちも最大限頑張って課題を解決しようという意識でのエンジニアリングマネージャーでした。これは受け入れてもらえたし、必要なことは出来たと思う。

ふたつめは、メルペイ・メルカリはどんどん変わっていく組織だということ。自分が在籍してる短い期間でもめちゃくちゃ変化している。みんなそれを楽しみながら過ごしてる。そういう組織だとEMが解決するべき課題もどんどんかわっていくので今回は新しいAndroid EMのひとがこの問題を解くのに適任だと感じただけ(そっちのほうが効率的ならチームが100%機能するためにサポートしようという状況。この行動は別にマネージャーというロールがなくてもできることなので)。

余談

この日記を読んでメルペイ・メルカリのEMに挑戦してみたい、話を聞いてみたいという人がいれば採用もしているので探してみてもいいかもしれない。優秀で面白い人達がいるので仕事が合うかどうかをじっくり見てほしい。そういうのじゃなくてお前の話に興味があるから聞きたいとかあれば一緒にランチにでもいきましょう。

エンジニアリングマネージャーというロールは僕にとっては面白かったし、メルペイではエンジニアと不可逆の役割でもない(ただの役割なので必要に応じて行ったり来たりするものだという認識がある)。エンジニアリングを良くしていくための一つの手段なでしかない。マネージャーというロールでは直接コードは書かないけど課題解決のために組織をこえて色んな人とも話す機会も持てたし、解決できる問題の種類も増えたとおもう。

全然、別の話では、いつだったか忘れたけどCTOのsowawaと1on1してると雑談のなかで経営とかちゃんと勉強しても良いかもねーって話題があったのでその頃から経営学べるといいかもなーと考えたり、社内でもDroidKaigiもあるのでそっちも手がかかるよねー、と声かけしてサポートしてもらったりもあるし、出展がたのしすぎてか技術書典6、やっていきましょう!みたいな声も聞こえてきている。人生なかなか飽きないなぁ、というかんじ。

僕にとってのDroidKaigiがどんなに面白い場所なのか書く日記

ひつじです。

DroidKaigiおわったんですよ。みなさん、おつかれさまっした!!!!!!!

このエントリはブログタイトルどおり、ひさしぶりの個人の日記並の感想文です。読んでも得られることは、ひつじのひととなり*1がわかる以外のメリットは無さそうです。

f:id:hdk_embedded:20180210013900j:plain

1000人規模のイベント(珍しい規模だけど特別ではないと思う)をどうやって運営したかという部分も興味があるひといるかもしれないので、ちゃんとしたまとめは別途やるかもしれないけど今回は、この一年間オーガナイザーとして関わってきたDroidKaigiが終わったあとの感想文です。読み進めてもヤマとオチはないので理解いただきたい。なお時系列も無視されているので気をつけて。

DroidKaigi 2018が終わった夜と、はじめてのDroidKaigi

DroidKaigi 2018が終わった2月9日の夜、スタッフでささやか*2に打ち上げた帰り道。

f:id:hdk_embedded:20180210000339j:plain

電車に遅延があって手持ち無沙汰なときのお話。「みんな帰れたかなー」と考えながらTwitterを開いたときにたまたま見たもの。

 

 

 このときは🐑も疲れててTweetの文脈を読み間違えて「わかる。わかるぞー。2018の感想ブログかー、はやいな。さすが @konifar さんだな」とおもって開いたら最初のDroidKaigi 2015の感想ブログだった。すぐ気づいたけどなんとなく懐かしい気持ちで読み進めてたら次のような文章が。

f:id:hdk_embedded:20180213002643j:plain

こにふぁーさんは、去年は公式アプリのオーガナイザーをしてて今年はアプリのサポートとして色々と手伝ってくれたマブダチなんですが、こにふぁーさんですらAndroidに不慣れで初めてのときがあったんだな、と不意に気付いた瞬間でした*3

DroidKaigiが初めてのひとをつなぐ場所として機能しているなら、それは少なくとも僕にとっては、とてもよいことだなと満足感に浸ったところで電車が来たので気持ちよく帰った*4

高校生が来たDroidKaigi

f:id:hdk_embedded:20180208093423j:plain

今回のDroidKaigiはWantedlyさんの協力でスカラーシッププログラムを実施してました。これを利用して高校生が参加してくれていたみたい*5

bigbuddha.hatenablog.jp

自分が高校生のころはゲームに夢中で、カンファレンスにいくなんて全然考えもしなかったので良い時代になったもんだなぁと他人事のような感想すらでてた。たくさんたくさん楽しんでくれたなら嬉しい*6

DroidKaigiはエンジニアが主役のカンファレンス。はじめて参加するひとも楽しんでもらえるように、さらには参加した人全員が満足してもらえるように、という気持ちをこめて作ってる。1000人の参加者ともなるとそりゃもういろんなことがあるんだけど、それ以上に一同に集まって会話する熱量っていうのは、ものすごいパワーがある(といいなとおもってやってる)。

スカラーシッププログラムを通じて何か得てくれたらそれだけで嬉しい。最初は高校生くるとかオジサンはマジ驚いたけど、冷静になるとエンジニアリングに年齢なんか関係ないし、驚くのは失礼だわ。スカラーシップを通じて参加できるようになったのなら主宰の役割を果たせたかもなと来てくれた本人には関係ないところで勝手に満足した。

DroidKaigiを支える技術

DroidKaigiの運営メンバーのほとんどはエンジニアです。これまで何度か触れてるの知ってる人が多いかもしれない。大体70名ぐらいが活動してる*7

つまるところ完全なボランティア&運営メンバーは余暇の時間を使ってるわけなんだけど、🐑は運営メンバーは好きなことをして欲しいと伝えてる(はず。しんどいこと、つらいことはしなくていいと本気で思っていて、そういうのはぜんぶ言い出しっぺの🐑がやればいい話)。

一年もやってると色々な取り組みがあるんだけど、受付の話を少しだけ。詳細はこっちを読んで欲しいです。

komatatsu.hateblo.jp

前回の受付破綻は本当に @komatatsu は悔しく思ってて2018はそれはもう入念に計画をたてて、準備をしてきたんですよ。今回は1000人規模で難易度は前回よりもあがる、カンファレンス当日の作業を考えると受付の並列数を単純に上げることは人的リソースを考えると不可能。結局のところ解決策を探すのに大事なのはリハでした。エンジニアっぽくいうと本番環境を再現した結合テスト

リハでは当日の会場を仮想的に用意して(もちろん1000人を用意するわけではないのだけど)受付作業が完了するまでの速度を求めたり*8、なんども手を動かしてまだみぬ当日の様子を想像した結果、辿りついたのがセルフチェックインアプリ。受付が秒で終わるので本当に革新的だった*9

f:id:hdk_embedded:20180208092914j:plain

こういうのは想像だけで議論すると空転してダメなのでプロトタイプでもなんでも作ってみるのが本当に大事。

あとは彼のブログでもすこし書かれているとおり、セルフチェックインアプリの準備が増えたこともあり当日の準備時間が押してしまっていたので🐑は直前に「受付が遅れたら入場を優先する。そのときは諦めてくれ」と伝えました*10

f:id:hdk_embedded:20180208091407j:plain

当日の🐑の役割は、できることとできないことを見極めて、その場でYes/Noのジャッジすること、判断材料を得るために歩き回って話をして誰よりも状況を把握すること。1000人の安全を守り、快適な環境を維持するという最大の優先事項があるので、これに少しでも反する事象があればNoということ。何かあったときは責任をとることでした。

心の準備をしてもらうために受付リーダーの彼には早めに「諦めろ」って伝えておきました。結果的には、開始時間の数分前にセットアップが完了したので最初の一般参加者10人をシステムテストとして迎え入れました*11

もちろん今回の方法が完璧ではなくて、迷惑をかけてしまったところがたくさんみつかってるのでそんな経験にあってしまった参加者さんには申し訳ないと思ってるんだけど、受付のチームは混乱なく、9時20分から10時までの40分で900人のホール座席をいっぱいにしてくれました。ありがとう。おつかれさまと伝えたいです。

ほかにはスポンサー、カメラ、Web、ネットワーク担当のブログがあがってるので興味あれば見てね。

sho5nn.hatenablog.jp

damenaragyouza.hatenablog.jp

mstssk.blogspot.jp

s-shimotori.hatenablog.com

いろんな立場のDroidKaigi

あなたは一般参加者でしたか?出展参加でしたか?登壇者として参加しましたか?運営メンバーでしたか?あ、参加してなくても問題ないです!資料や動画は今後まとめてなるべく早い段階で公式サイトとYouTubeに公開予定です!

 

DroidKaigiも回数を重ねるごとに学んでPDCAを回しています。その中には「写真撮影班の時刻を同期する」「入口すぐに地図を用意する」など地味なものもありますが🐑がやってることに登壇者と話すことがあります。

こにふぁーさんのブログで触れられていたのでこの日記にもメモしておこうかな、と。 

konifar-zatsu.hatenadiary.jp

 DroidKaigiは、技術共有とコミュニケーションを目的に開催しています。そのためには適切な雰囲気で話しやすい環境でやってもらったほうが聴講側と登壇者の距離感が近くなって聞きやすくなったり、その後話しやすかったりすると考えてて、可能な限り話しかけるようにしてます*12。一日目とかは会場対応などしてて回りきれてなかったので来なかったゾ、という人もいるかも。ごめんね。

余談ですが、こにふぁーさんのときは

「イェーイ!!!」と言いながら入ってきて

だったけど顔をみたら本人が一番胃が痛そうでした。空気がピリピリしてるとみんな身構えちゃうので、一緒にはなして笑えれば、それだけでみんなが持って帰る良いことの総和が増える。メリットしかないですよね。

今回はたまたま登壇者視点でしたが、一般参加者も一緒ではじめて一人できたひととかはすごい不安なんですよ。居ていいかな、とか場違いじゃないかなとか。すこしでも話してみて楽しんでもらえたら、と思ってます。

それと2日目からアクセシビリティシートがふえました。

 これは @red_fat_daruma の発案で「相談なんですが…」と持ちかけられたのを覚えてます。ぼくも車椅子のかた、足が不自由なかたがいるのを知っていたのに「シートを用意する」という発想にはたどり着いてなかったので、話を聞いたときに「ぜひやるべきだ」と答えました。すこし気になるツイートもあったので掲載しておきます。

大丈夫。この措置はDroidKaigiを全員が楽しむために必要な措置だったと🐑は考えています。決してあなただけのための措置ではありません。 DroidKaigiは行動規範にもあるとおり、みんながお互いを尊重し、制約を気にせず、技術のことを考えられる場です。そしてそれに気づいたのは🐑ではなく運営メンバーです。世の中、いろんな視点があると思いますが、より良い環境にするためにいろんな意見を取り入れる工夫ができたら、と思います。

一般参加者、出展、登壇者、運営スタッフ、海外から来たよ、国内からきたよ、学生だよとかとか、どんな立場であってもDroidKaigiには技術のはなしをしにきています。立場によってできることはちがっていて、登壇者としては発表を、参加者は費用を負担し、いろんな立場の人が場を共有しています。これからも技術共有やコミュニケーションのための場所として🐑が出来ることをやっていきたいです*13

みんなが好き好きに「DroidKaigiはワシが育てた」っていってくれるといいなぁ。

あなたにとってのDroidKaigi

🐑にとっては振り返るとまだまだ改善したいところがあって、エレベータのキャパシティが足りずに1Fへの移動に行列ができるとか、ランチボックスの配布、Day.2の登壇者はずっと緊張してたのでDay.1の講演ききくにくかっただろうし、もっと快適な空間づくりとか、タイムテーブルも選ぶの難しいですよね、分身したくなるし。

名札に日本語が使えなくて(印刷業者の都合。でも海外参加者もいるし良かったかも?)申し込み時の名前欄に日本語をいれたひとはもれなく🐑の直筆名札になりました(マジックで書かれた人の名札は当たりというべきかハズレというべきか迷いますが全部、僕が真心こめてお名前を書きました!)。

f:id:hdk_embedded:20180207180808j:plain

今年のDroidKaigiで出来たこともあります。コードラボやハンズオンで初学者の導入を手伝ったり、オフィス・アワーで十分な質問時間を確保したり、多くのセッションをホストして選択肢の幅が広がりました。

初学者も上級者も技術のことに集中できる環境を目指しています。そして初学者が素早く上級者になれるような手伝いがしたいです。いまのAndroidは多くのことを学ぶ必要があります。上級者だけが高速道路を走っているような状況ではきっと初学者のあいだに大きな溝ができてしまいます。なので技術共有を通して誰もが高速道路を走れるようにできるといいな、とおもいます。

通常の技術カンファレンスよりコミュニケーション要素が多くなってるな、と感じてもらえると狙い通りかも*14。今年のDroidKaigiはAndroidだけではなく、その周辺技術についても広く取り扱い、クライアントの視点からいろんな技術をみれたと思います。いろんな技術に触れて知っていることが今後の開発では(何かあった時に思い出したり気付けるので)大事じゃないかな、と思います。

 

さて友人の話をします。DroidKaigiで広報を手伝ってくれてた @KeithYokoma が子どものようにはしゃぐんですよ。Romain Guy氏とChet Haase氏とで話したって*15

keithyokoma.hatenablog.com

Google I/Oでは2人のセッションは満員で、そりゃもう有名なエンジニアなんですよね。🐑「すごい人だと思うけどはしゃぎすぎじゃねwww」って言ったら「完全にミーハーですけど、これがいいんですよ、RomainとChetですよ!」(意訳)って返してくるんですよね、横幕さん。話してるとぼくも嬉しくなってきちゃう。

人によっては誰かと会って話す、何気ないことでも一番貴重な体験になります。だれかに声をかけた、かけられた、そんな単純なことでも強いモチベーションにつながります。

この一年をみてもAndroidやその他の技術を取り巻く環境は変化していきます。DroidKaigiも変化を受け入れながら前に進めると、より多くの人が楽しくすごせるといいな、と感じてます。

ひつじは皆さんにとってDroidKaigiがどんなところであってほしいか、とても聞きたいです。何処かに書いたならメンションでおしえてください。たくさん読みたいです。

f:id:hdk_embedded:20180209201900j:plain

長いようで短い2日間おつかれさまでした。またどこかで会いしましょう!

*1:ひつじとなり?

*2:かどうかは異議があるかもしれない盛り上がり方だった。たぶんヘトヘトになったあとのビールでみんなテンションが上がったんだろね。そこかしこで無事終わってよかった、もっとこうしたかった、あれは最高の取り組みだったなど熱い感想が繰り広げられてて、もちろん最後にはただの酒盛りになってたよ

*3:しかも自分が声をかけようとしていたことすら忘れてた

*4:🐑は「🐑とあなた」という一対一の関係を大事にしているのだけど、初めてのひとが参加して抵抗なく受け入れられるなら、その場所は誰かと誰かをつなぐ素晴らしい場所=コミュニティとして機能しているのだろう

*5:このあたりは選考とかをすべておまかせしていたので当日になってから把握したんですけど、二度見するぐらい驚きました

*6:余談ではあるがスカラーシップ実施にあたって冠スポンサーがあるのは一般参加者の参加費は参加した本人のために使いたかったから。あくまで付帯する取り組みなので「取り組みが気に入った、じゃあそれにお金を出しましょう」と言ってくれるひとのお金を使うべきだろうなというロジックが🐑のなかにはあった

*7:うち毎月のミーティングにでているアクティブ率は40名ぐらいなので常時みんながコミットメントしてるわけではなくてまだらなところがある。途中の作業とかもお互いで補完しあいながらアレコレすすめてるんですよ。今後も無理せずやるための工夫をしていきたい

*8:多数の名札から受付担当者が探してピックするのは平均2分ぐらいかかってて、何度改善しても似たようなものに。ここで人力はありえないと判断した

*9:なお他の選択肢としては事前に名札を送付する方法があるけどこれもまた個人情報収集がネックとなり現実的ではないとして却下した

*10:実は彼のブログにある椅子の上にパンフレットをおく計画でしたが、遅延があったのでそのための人員を割くのを諦めて入口での配布に切り替える人員最適化オペも裏で平行実施してた

*11:受付担当者が慣熟するため、更になにかあったときの混乱を減らすクッションの役割を果たす工夫です

*12:プレゼンのスキルなどもあるとはおもうのですが本質の技術の話に集中するために使うべきスキルでなんか話術だけのはなしなると、🐑がよくわからなくなるからここでは触れません

*13:少ない労力で技術的な知見のリターンが大きいとさらに嬉しいという下心もあります

*14:当然モクモク聞きたいひともいるとおもうのでそういう人を排除したいわけではありません。選択肢があっていいなと考えてます

*15:USからきたスゴいAndroidエンジニアの2人です

DroidKaigiでAndroidのアーキテクチャの成立を理解するためのセッションをします

ひつじです。

DroidKaigi 2018 Day.1 / 12:50-

2月8日に開催するDroidKaigi 2018で「Android Back to the Future」というセッションをやります。

このセッションはAndroidにおけるアーキテクチャの成立に触れ、これまでの試行錯誤の過程(プラットフォームの課題、どのようなアプローチで解決してきたか)を振り返りながら、モバイルアプリの設計を知るセッションにできればいいな、と考えてます。

ただの座学では理解しにくいところもあるので、会場から質問や意見をもらいながらのでディスカッション形式で進めてみたいです(うまくいくかは未知数。準備万端で望みます!)。

このあたりの調査は自書の「Android アプリ設計パターン入門」(今回は紹介がメインではないので記事の最下段にリンクしておきました)で触れた内容ですが、未読の方、初学者の方はもちろん、これまでのAndroidについても知りたいというかたに参加をおすすめします。基本的にはいろんなアーキテクチャに触れる前提知識を培えるものです。それぞれのアーキテクチャに立ち入った厳密な話はできないと思います(はなしのながれで触れるかもしれませんが)。

Android Back to the Future

 当日のディスカッションの進み方次第では明後日の方向へ進む可能性もありますのでライブ感を楽しんでもらえるとうれしいです。 ちょっと真面目すぎると発言しにくいかと思い、当日のスライドテイストは緩めです。

f:id:hdk_embedded:20180207122158p:plain

2018年の東京、新宿に住むエンジニア、マーティ・マクフライAndroid歴史学者であるドロイド博士(通称ドク)を手伝って、タイムマシンの実験を行う。タイムマシンに改造されたデロリアンDMC-12が到着した先にはガラケーしか存在しない時代だった。デロリアンに乗った2人は現代のAndroidまで帰ってこれるのか?!

懐かしい映画をモチーフに進めていければとおもってます。それではデロリアンに乗ってAndroidの歴史を振り返ってみましょう。いってきます。

f:id:hdk_embedded:20180207122053p:plain 

DroidKaigiではたくさんのセッションがあってどれも楽しみです。

 当日は選ぶのに困りそう。あー、はやく明日が来ないかな。

 

Android アプリ設計パターン入門

Android アプリ設計パターン入門

  • 著者:日高 正博,小西裕介,藤原聖,吉岡 毅,今井 智章,
  • 製本版,電子版
  • PEAKSで購入する

 

 

Androidアプリ設計の技術書をクラウドファンディングで執筆しました

本を書きました

2017年7月に投稿したブログポストの続きです。Androidアプリの設計パターンを紹介しようとおもって書き始めた技術書のクラウドファンディングです。本日2018年1月31日に一般販売が始まりました!

 

Android アプリ設計パターン入門

Android アプリ設計パターン入門

  • 著者:日高 正博,小西裕介,藤原聖,吉岡 毅,今井 智章,
  • 製本版,電子版
  • PEAKSで購入する

本の内容

本書はアプリの設計を知り、考えるための議論に使える本として執筆しました。書きたいことを表現するためになんども書き直し、完成まで死ぬほど時間がかかった技術書です(2017年10月~12月の余暇のほとんどを費やした)。

ちなみに私以外の執筆者の感想はこちらから読めます。あわせてどうぞ。

tsuyogoro.hatenablog.com

tomoima525.hatenablog.com

実際、この本をよんで設計が出来るようになるかというと胸を張って「間違いなくはじめの一歩を踏み出せる」一冊と答えます。実際には読んでもあなたのアプリは完成しないかもしれないし、失敗するかもしれません。でも右も左も分からないということはなくなります。もちろん大成功するかもしれませんがそれはきっとあなたの力です。

本書ではアーキテクチャを学び、議論する前提を組み立てることを大事にしていて、結局のところ、設計とは何かを大いに考えさせる技術書になりました。「設計を完全に理解しているか」と問いかけられると誰もが不安を覚えると思います。特定の分野に限って考えても、とてもとても難しいことです。

アプリの設計には開発者の理念や思想が反映されているべきで、それらはアプリの要件や開発チームの練度・性質で千差万別の形があります。方法論だけをみて設計の評価は出来ないし、実装だけをみて評価することもまた出来ません。

このような事情に悩んだ結果、本書では実際の開発事例をみながら議論をすすめる構成にしています。実際にあったことを丁寧に解説し、手法と実装の両面からアプリ設計、アーキテクチャ追体験できます。

第1部ではGoogleアーキテクチャサンプルリポジトリをベースに現代のAndroidアプリの設計手法の基礎を学べます。MVPやMVVMが登場した背景からモバイル分野での適用を知れます。ライフサイクルなどモバイル特有の事情についても触れています。

第2部では、サイバーエージェント、メルカリ、そしてOSSとしてのDroidKaigi 2017のカンファレンスアプリを取り上げ、いろんな設計を成り立ちから紹介しています。なぜ選んだのか、どうしてこうなったのか、というコードからは分からない部分と実際やってみてどうだったか、という評価まで含めて解説しています。本の内容として失敗したことを書くのは抵抗がありましたが、良いところも悪いところも包み隠さず知ることが一番だと思い「ここは失敗だった」「当時は乗り気じゃなかったが、振り返ってみると良策だった」など忌憚のない意見を書いてもらっています。MVPやMVVM、Flux、そしてReact Nativeと幅広く事例を集められたと自負しています。

第3部は未来の話です。Android Architecture Componentsを取り上げ、どのように使うべきか議論を進めています。

Androidアプリの設計は、まだまだ道半ばでようやく基礎が整ったに過ぎません。2018年をみても設計手法にアップデートがあるはずです。たとえばDroidKaigi 2018のリポジトリには今すぐ使えるKotlinのアプリ開発の知見が集まっています。本書はそのようなこれからの設計を議論する基礎になれば、という思いを込めて作りました。ぜひ手にとって見てください。 

色々な意見をお待ちしています。「いやー、これはきつい」「ここの章は参考になるな」「この視点はなかった」など何気ない一言がきっかけで良い設計に変わるかも。

クラウドファンディングでよかったこと・わるかったこと

まず出資者のみなさんの応援があったことで制作の原資を獲得できました。ありがとうございました。当初見込んでいた良いところはたくさん提供できる(今回、個人ではほぼありえない数千冊部以上を印刷できました)ことで文句なしのメリットNo.1です。

意識してない中で嬉しかったところは、執筆の最中にも応援してもらったことがめちゃくちゃ励みになりました。通常、執筆というのは自分との闘いで書籍が販売されるまでは孤独なものです。今回は書いてることがみんな知ってたのでいろいろな人から「がんばってください」「期待してます」「無理しないで」と声をかけてもらえ、モチベーションに繋がりました。

またα版やβ版というかたちで意見を交わせたのもよかったです。自分がここはどうだろうな?と悩んだ部分は読者からの的確な指摘があって、やっぱり気持ちが伝わるんだなということを再確認できました(見直しつつ妥協なく書きました)。プロの編集者の方に校正してもらいながら、クオリティを上げられた点もよかったです。

他方でクラウドファンディング達成後の書籍販売ルートは基本的に口コミと手売りに頼ることになります。PEAKSはポッとでてきた出版社にすぎず、取次経由でたくさんの書店にならべることはできません。発売日に全国の書店に並ぶことはやっぱりスゴいことなんです。

ですので、この本をよんで良い本だと感じたら是非、隣の開発者に教えてあげてください。著者一同よろこびます。クラウドファンディング、同人誌のような著者と読者が近い形態はフィードバックを得やすく、とても好きな雰囲気を感じてます。

Android アプリ設計パターン入門

Android アプリ設計パターン入門

  • 著者:日高 正博,小西裕介,藤原聖,吉岡 毅,今井 智章,
  • 製本版,電子版
  • PEAKSで購入する

さいごに

実はクラウドファンディングであるメリットを最大限活かして本の表紙や紙質、フォントサイズやレイアウト、細かい点までmhidaka(私です)がアレコレと口をだしました(PEAKSの方々に大変迷惑をかけながら!レイアウトチェックや紙の指定のために事務所までお邪魔しました)。更に電子書籍も2種類用意してもらい、片方はPDFのしおりやコピペが完璧にできるもの、もう片方は書籍そのままに美しいクオリティのもの、と2本立てです。これも執念というか趣味の領域ですね。どちらも欲しい人が居そうなので両方つくって提供しちゃうか、という感じです。

f:id:hdk_embedded:20180131114827p:plain

電子版(機能重視)

f:id:hdk_embedded:20180131115217p:plain

電子版(紙面レイアウト)

ただいまリフロー版(EPUB)も試しているのでKindleとかで固定レイアウト以外でよみたいよ、という人がいたらお問い合わせください。

ここから番宣です。一般販売記念キャンペーンで最初のロットは割引価格の2800円で提供中です。また本書の出資者が紹介した場合、紹介プログラムにより販売価格の30%が出資者に還元されます。全国津々浦々の書店に置けないのでチャレンジしてみましょう、となった新しい取り組みです。なんか面白そうなので一肌脱ぐぜ!という方はぜひ試してみて下さい。

Android アプリ設計パターン入門

Android アプリ設計パターン入門

  • 著者:日高 正博,小西裕介,藤原聖,吉岡 毅,今井 智章,
  • 製本版,電子版
  • PEAKSで購入する

 

謝辞

まずはじめに、クラウドファンディングの出資者のみなさん。出資ありがとうございます。なによりの励みとなりました。

そして、サイバーエージェントの社員のみなさん、メルカリの社員のみなさん、DroidKaigi OSSアプリのコントリビュータのみなさん、みなさんの知見が書籍になりました。ありがとうございます。

PEAKS出版のみなさん。本書を制作するにあたり力強いサポートをいただきました。ありがとうございます。

著者の小西裕介さん、藤原聖さん、吉岡 毅さん、今井 智章さん。このような荒唐無稽な執筆を快諾いただき、ありがとうございます。いつも無茶をいう私を笑顔で受け入れてくれ、開発に関する知見を惜しみなく提供くださいました。

八木さん、今回は忙しくてだめだったけどまた一緒に書こうね。

TechBoosterに寄稿いただいてる著者のみなさん。みてる?がんばったよ!冬コミとか技術書典とかあまり動けなくてごめんね。いい本が出来たよ!また一緒にいい本つくろうな(Androidモダンプログラミング ~Kotlin&Gradle実践入門~の電子版やらなきゃ…)。

本音

頼む!ひつじのリンクからたくさん売れてくれ!!!

Androidアプリ設計の技術書をクラウドファンディングで執筆します

本を書きます!

技術書のクラウドファンディングサービス「PEAKS」でプログラミング解説書「Android アプリ設計パターン入門」のファンディングをはじめました。みなさんの応援が、書籍を作る原資になります。よろしくおねがいします

Android アプリ設計パターン入門」

f:id:hdk_embedded:20170703093536j:plain

PEAKS(ピークス)|日高 正博 小西裕介 藤原聖 八木 俊広 - TechBoosterの新刊!「Android アプリ設計パターン入門」執筆プロジェクト

本の内容はリンク先から「プロジェクト概要」に思いの丈を書き綴りました。

アプリの設計を知り、考えるための議論に使える本を目指してます。プログラミングにおいて設計は重要な要素ですが、それ自体が目的ではありません。ソースコードを通じて何が実現できるか、という視点で良い選択(プロジェクトごと異なる解があるはず)を選べるようになりたいという気持ちです。特に第2部では生きたプロジェクトをテーマにプロダクトコードをベースに設計についてみていけるといいな、と思ってます。

クラウドファンディングの理由

本書がクラウドファンディングのカタチをとったのはいくつか理由があるのですが、ひとつは紙の本を作るのに、ページ数に比例してお金がかかるということです。部数を増やせば単価は安くなりますが、過度な発注での在庫リスクのせめぎ合いに悩まされます(本書は完成時250ページ以上!)。

同人誌(TechBoosterのBoothにmhidakaがいままで作ってきた本があるよ!)として作るのには「Androidアプリ設計を自由に議論するのにいささか余白が足りなさそう」&「せっかくだからみんなの課題を聞いてみたい」という気持ちもありました。そこで第10章は

第10章 みんなの広場

出資者の設計上の課題をきいて、一問一答形式で案を出すコーナー

というAndroid開発者が抱える設計の不安を共有し、よりよりプログラミングについて考えられれば、というコーナーにしています。めちゃくちゃ時間がかかる章になりそうですが、色んな意見を聞く機会になるし、クラウドファンディングぽさを楽しんほしいな、と思います。

著者(執筆に巻き込まれた人)紹介!

mhidakaが急に訪ねてどうしてもあなたの記事が読みたい、と無理を言って声をかけたひとびとです。それぞれが沢山アウトプットをだしているひとたちで、一線級のエンジニアです!

小西裕介さん(Konifar)

KonifarさんはQuipperで働くかたわらDroidKaigiアプリをOSSアプリとして開発するなど無限のバイタリティ(!)とベースにある技術的な裏付けがすごいドラえもんアイコンの人です。ブログでは独自の視点からハッと気づかせるような記事が多く、担当を予定してる「第5章 OSSにおける設計者の役割」も今から楽しみです。

藤原聖さん

Shibuya.apkやサイバーエージェントのCA.*のオーガナイザー。めっちゃたくさんイベントをホストしています。本書ではFluxアーキテクチャArchitecture Componentsを担当してます。アーキテクチャコンポーネントGoogle I/O 2017で発表されたばかりの注目度Maxなライブラリです。一方、全然こなれてないので使い方そのものについて議論していき、便利な使い方を提示できればいいな、と担当をお願いしました!

八木 俊広さん

アーキテクチャおじさん。クックパットに居た頃から尋常じゃない仕事量について風のうわさが耳に入ってきました。TechBoosterでもKotlinの記事などエッジなところを書いてもらっていて、八木さんの知識でしか書けないなー、という解説記事がちらほら(たとえばコミケで一緒に作った本では第5章 詳説Kotlin 1.1 async/awaitを担当。内部実装まで調べて解説してくれてます)。今回もGoogle I/O 2017で発表のあったKotlin正式サポートを受けて、第9章 Kotlinが設計に与える影響を担当してもらえました。またチーム開発について考える第7章 チームとアーキテクチャも楽しみです。

さいごに

個人としては、どんどんAndroid開発が難しくなっていく中で(少なくとも覚えることが格段に増えていっている)技術共有が大事だし、もっと重要なファクターになるとおもってます。

なのでTechBooster(夏コミがんばってかいてます!)やDroidKaigi(来年度計画始まりました!)をやっていってます。技術全体に視点を広げると技術書典なども開催しています(技術書典3の受付はじめました!)。

PEAKSは未成立だと決済されない系クラウドファンディングです。気に入ったらぜひ購入ください。1人が出資してくれたらそのお金で2冊つくれる!よし!余分にできた1冊はmhidakaが責任を持って普及活動するぞ!という気持ちです。

peaks.cc

よろしくお願いします。今後もまとまった知識として本を作って頒布していきたいです。

 

株式会社ソウゾウに入社した

2月より株式会社ソウゾウ(Souzoh,Inc)でお世話になっている。

そろそろ1ヶ月(2月は多少短いのだけども)たつので忘れないように感想をまとめておこうと思う。何か日記っぽいなとおもったけど、そもそもブログタイトルが「ひつじのにっき」なのでそれも気にしないでいきたい。

読み返してみると友達への私信っぽい感じになってるけど、やはりこれも気にしないでいようかな。

あ、どうも。mhidaka(🐑)です。Androidエンジニアとして過ごす傍ら、技術の共有や普及活動に興味が強くて技術書典を主宰したり、DroidKaigiの代表をつとめたり、講演したり、技術記事を執筆したり勉強会を開いたりしています。 

何の仕事をしてるの。

一ヶ月もたって社内がわかってきた…わけではない。実はまだ社内のプロダクトにはあまり貢献していない(もちろんプロダクトのリポジトリをみてPRやIssue、レビューなどは目を通してるけども大したことじゃない)。何をしてるのかといえばDroidKaigiのことをフルタイムでやってる*1。これは自分でも驚いてる。

ちょっと🐑のことを知ってる人なら「何をバカなことを。いつもフルタイムで応答するだろ」「そもそもいつ寝てるんだ」「お前はいったい何インスタンス起動しているんだ」とジョークが始まることも多いので混乱するかもしれない。

この場合のフルタイムは業務時間、ずっとっていう意味であってる。自分の場合は入社にあたってコミュニティ活動(社外へのアウトプット)を業務中にも認めて欲しいという要望は出していたんだけど、入った日に「今は忙しい時期だとおもうから全力でコミットしていいよ」と言われたときは驚いた。

社内の同僚に説明しても、みんな驚いたあと口を揃えて「いい会社だなぁ」と言って納得してたので本当にそうなんだろうな、と思う*2

個人的にはDroidKaigiが落ち着いたら社内のプロジェクトにも触れていきたいと考えてるけど(もちろん技術の普及やコミュニティへの貢献も継続するよ)、このあたりの詳しい話を聞きたい人は、しばらくたってから声をかけてくれると嬉しい。もうすこし突っ込んだ話もできるとおもう。会社のミートアップやイベントには参加予定なので、そこで捕まえてもらっても大丈夫(外から入ったばっかりの感想が聞きたいなら今がチャンスだ)。

アウトプット

というわけで今はモバイル分野、Androidエンジニアが楽しめるカンファレンスができるようにDroidKaigiの準備を頑張ってる。

チケットは昨晩売り切れて*3スタッフ、スピーカー、出展者などなど含めると1000人弱のカンファレンスに成長した。海外からの参加者も増えていて、大変うれしい。一方でやることも指数曲線的に増えていて(多分カンファレンスの規模が500人を超えてくるあたりに境界線がある)微力ながら手伝っている、というのが正直な感想。

比率でいうと30~50人のスタッフが準備を進めているなかでは個人が40時間/週の工数をつかっても単純作業の一部を肩代わり(1人あたり1時間分ぐらい)するだけなので実際のイメージとしてはスタッフが動きやすいよう「交通整理をして情報を集約してまとめる」「施設、外部との調整」「準備物の発注作業」などボトルネックの解消を心がけて進めてる。

自分の時間をかければかけるほど多くのボランティアスタッフに支えられてるのが身にしみて分かるし、会社がこういう活動をサポートしてくれて僕のお給料がでるのはとても不思議な気持ちになる*4。コミュニティや企業の枠を超えて、むこうにいるAndroidエンジニアひとりひとりのために働いてる気もしてくる(要望があったら遠慮なくいってね)。

なにはともあれ3月9日/10日のDroidKaigiのために精一杯がんばってるので参加する予定の人は目当てのセッションを楽しんで欲しいし、好きな技術ではしゃいでほしいというのが本音です。

周りの環境

となりに@operandoOSさんがいて、もひとつ向こうに@_ishkawaさんが座ってる。チームはとても小さい(ソフトウェアエンジニアは3~4人、関係者全員でも5~10人ぐらいだろうか。2枚のピザ理論を守っている)。社内wikiが育っていて、ものを書く文化圏なので馴染みがある。

もっと会社の様子を知りたいひとはmercan(メルカン)Mercari Engineering Blogが良いかも。

ほしいものリスト

Amazonウィッシュリスト、じつは初めて使うんですごいドキドキしてます。

www.amazon.co.jp

やっていくぞ。

*1:mhidakaはDroidKaigiの代表者をしてます

*2:これまでの🐑の活動や技能を評価してくれた側面もあるのかもしれないけど、それでもスゴいなぁ、と感じた

*3:∩(・ω・)∩万歳

*4:まだ慣れてない

DroidKaigi 2017 開催にむけて

代表者としてDroidKaigi 2017のプレスリリースを書きました。

github.com

本エントリはDroidKaigiを知らないひとに届けたくて、そして来てほしくて書きました。運営の体制とかに触れています。セッションの紹介とかは追々書きたいな、と思います。セッションタイムテーブルも公開されているのでぜひ見て下さい。

TL;DR

今年も3月9日、10日にやるので来てね。運営も頑張るよ。初学者向けのセッション、ハンズオンから普段聞けないめっちゃ濃い話まで色々あるよ。一緒にお祭り楽しんでください。

f:id:hdk_embedded:20170127160527p:plain

 

DroidKaigi 2017の進捗

DroidKaigi 2017、はやいもので開催まで40日となりました。1月31日には最後の下見にいきます(ちょっと話が飛びますが新宿にはベルサール西新宿とベルサール新宿グランドの2つだと思ってたんですが、ツイッターベルサール新宿セントラルパークも教えてもらいました。3つあります。DroidKaigiの会場はベルサール新宿グランドなので気をつけて下さい)。

閑話休題。今回のDroidKaigiは最大5セッションを2日間実施します。そのため実は前日も準備日として確保しています。前日設営ではネットワーク、セッションルーム、展示&お菓子ルームなどの準備が待ち構えてます。

来週の下見の段階では椅子や机のレイアウト、音響、電源、インターネットなどの懸念事項を確認して計画に反映していきます。大規模カンファレンスだとこのあたりの作業がやはりい一番負荷がかかり、手が空いた人で助け合ってる感じです。

運営メンバーごと役割を決めて情報を集約→効率的に動く仕組みとして、結構こまかく担当が分かれてまして、ざっくりと書いても次のような感じです。

  • 会場:keima, tsuyoyo
  • Tシャツやグッズ系:tezooka, wariemon
  • Webサイト:mstssk, wm3
  • パンフレット:iwata_n
  • 食事:mogutaso
  • 広報:KeithYokoma
  • 搬入/搬出:matsuyama, teshi04
  • 協賛:shogo, kmats_
  • オフィスアワーなどの企画:suino, mochico
  • 受付:komatatsu, kaorii
  • アプリ:konifar
  • 事務局:wiroha
  • タイムテーブル:daruma
  • 会計:ken5scal
  • ネットワーク:pochi、CONBUさん

各カテゴリの番長的な人を挙げてみました。そこから更に細分化して、個々のタスクを運営メンバーみんな*1でえいや、と回してる状態です。

今ざっくり書いても複雑だな、、、と驚いたんですが規模的には搬入/搬出だけでもダンボール50箱ぐらいあるんですよね。これだけ多いと、どこからいくつ来る、みたいな管理は必要になってしまってやっぱり担当者が欲しくなる、という具合です。タスク粒度に合わせて運営メンバーが協力しあってます。

ありがたいことにDroidKaigiは回を重ねるごと、どんどん成長してきました。純粋に嬉しい気持ちです。その一方で運営においては会場、ネットワーク、電源、海外スピーカーさんのアテンド*2、タイムテーブルの構築などなど規模に応じて加速度的に複雑になる部分もあり、初めてのものをGitHubのIssueやProject、Slackなどエンジニアが使いやすいツールを使って&探してきて試しながら回しています。

僕らが提供したい価値

一体なにが、ここまでしてカンファレンス運営に突き動かすのか、という部分はすごく不思議に思います*3

改めて考えてみみると、そこにあるのは年に一度のお祭、エンジニアが主役のカンファレンスを作って楽しみたい、という部分だと思います。

運営メンバーとして自分たちが楽しむのももちろんなんですが発表する立場のひと、参加する立場のひと、すべてのひとが開発に関わる者として技術情報や開発の知見を共有できる場というのは、すごく価値があると思います*4

あと現金なはなしで恐縮なんですが、なんだかんだでフィードバックもらえると嬉しいです。「楽しかったです」「あのセッション、めっちゃ良かったです」「ご飯が美味しかったです」とか声が聞こえると担当者がめっちゃ喜びます。もちろんセッションへのフィードバックは発表者のひとも嬉しいし、モチベーションになります。なので会場でスタッフに声をかけてもらえると嬉しいです*5。みんなの前じゃちょっと聞きにくいな、というときのために今回は発表者へ直接質問できるオフィスアワーなど落ち着いて話ができる場も用意しています。

チケット情報

さて、最後にDroidKaigi 2017のチケットご案内です。

droidkaigi.connpass.com

各種参加チケット、取り揃えております。当日のセッションタイムテーブルも公開できた*6のでチラ見してみてください。

f:id:hdk_embedded:20170127172332p:plain

会場で会えることを願って。それでは。

 

 

*1:実は名前を書ききれなかった人が倍ほどいまして、書ききれなくてごめんなという気持ち

*2:下手ながら英語でなんとか

*3:私自身、代表として楽しんでるんですがやっぱり大変なものは大変だと思うんですよね

*4:蛇足ですが協賛企業にもこのあたりのエンジニアが主役という趣旨を伝えた上で協賛してもらってます

*5:Twitterの #droidkaigi ハッシュタグでも見てます!

*6:mstsskやkonifarさんが複雑な部屋配置をJSONソースコードに落とし込むのに頭を抱えた