ひつじのにっき

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で購入する