ひつじのにっき

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

僕にとっての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ソースコードに落とし込むのに頭を抱えた

技術書が生まれる経緯

冬コミで出した技術書「なないろAndroid」「The Web Explorer 3」「わかる!ドメイン駆動設計」の3冊について、先週から電子書籍の販売が始まっています。タイミングがよいので、難産だった「わかる!ドメイン駆動設計」の生まれた経緯を書いておこうと思います。f:id:hdk_embedded:20170122233404p:plain

techbooster.booth.pm

上記サイトではAndroidやWebの最新情報、技術書の作り方本など色んな書籍を扱ってます。ぜひみてください。

きっかけは読書会

本書は読書会を通じて生まれました。メンバーは大体4人(やんざむともちこと@tacksmanとひつじ)で、たまに@sys1yagiさんとかが参加。毎週リアルに集まるのは大変だったのでビデオハングアウトで週1回、1時間。始めたのは2016年4月~(継続中)。オンラインだったのが地味によくて、参加と継続のハードルを下げられています。

本は厚くて有名なエリック・エヴァンスドメイン駆動設計と実践ドメイン駆動設計です。

www.amazon.co.jp

どちらも大変良い本なのは間違いないですが如何せん厚い。読書会の目的である実践レベルでDDDを理解したい、という前提では「読み終わる」ということと「本文を解釈して意味を噛み砕き、理解する」は天と地ほどの差がありました。

読書会では、あらかじめ1~2章読んでおいて分からないところを質問しあったり、いままでの経験とすり合わをしたりと、意見交換をしながら理解を確かめて進めました。締切とモチベーションの維持のための読書会、って感じです。準備が大事なので赤線を引いたり、知らない用語がでてきたら調べておいたり。

メンバーの課題意識

読書会を進めるにあたって気づいたことをいくつか。何かを理解する時に、都合の良い比喩や他の概念などを使わずに書いてある内容をうまく説明するのが思った以上に難しい。メンバーは実力のあるエンジニアであることは間違いない*1のですが、技術者としての背景が違うので当然だと思っている前提は当然ではない、という感じ。

ドメインモデルって何を指している用語なの?」「ここでコンテキストっていってるけどコンテキストの境界の意味だよね?」と解釈を話すときは、特に言葉に注意しないと混乱してしまう感じです。

課題意識はもうひとつあって、どうやってモバイルアプリに適用するか考える事。原書はAndroidiOSなどが活躍する前のモノなので、モダンな開発についての示唆が直接的に得られるわけではない感じです。モバイルアプリ開発(プロジェクト)で実践していく上で何が難しいのか、どこに気をつけるのか、どんな工夫ができるか、という実務を前提に議論しています。

議論するタイミングでは技術者としての背景が違う事実が役に立っていて「あー、これは気づかなかったな」とか「確かにそういう時すごい便利だよな」っていう会話が楽しいです。

読書会で気づいたこと

DDDは難しい。言葉通りの意味でDDDの考え方、概念として腑に落とすのに時間がかかるという話もあるんですが、難しさに入門しにくさというのを感じました。

原書では網羅的な解説をしていて、かいつまむのも全部読んだ後に適切なところを探すという感じなんですよね。でも「興味があるんだけど」という人にいきなり1000ページの書物を投げつけるのは忍びない。そこで厳密性の議論は一旦おいておいて、ざっくりと概念を理解する、重要な考え方を学んだほうがいいのでは、知った上で原書を読むとより理解がはやいのでは、というのが「わかる!ドメイン駆動設計」の執筆の動機です。

わかる!ドメイン駆動設計

techbooster.booth.pm

ただ解説するんじゃなくて物語を通じて理解できる構成にしました。物語のストーリーは、やんざむ*2が頭をひねって考えた。

親しみを覚えてもらいたくてアプリ開発者のもちこちゃん*3など可愛らしい挿絵で登場人物が生き生きと動いてくれます。

冬コミの新刊のなかでは一番下調べができていた(4月から読書会をしていたのでゆうに6ヶ月は調べてた)のだけども、わかりやすく表現できているか、曖昧なところはないかなど納得いくまで何度も何度も書き直して、草稿の原型が残っている箇所は殆どなくなってしまいました。

作中はAndroidアプリをテーマに話は進みますが、基本的には味付け程度でモダンな現代の開発現場でDDDを使っていく話になっています。そういうわけで対象者はDDDに興味がある開発者、という感じです。今回はコンテキストマップまでが解説の対象になっています。次(技術書典2だな?)では物語を前に進めてモバイルアプリでのDDD適用について知見を盛り込めればな、と考えてます。

組版とか

いままでB5サイズで技術書をつくっていた(組んでいた)のですが、今回は気軽に手にとって読めるようにTechBoosterでは初めてのA5サイズを採用しています。本書にあわせてレイアウトを刷新*4しました。会話シーンなども多いのでRe:VIEW記法を拡張したり、挿絵にはキャプションを入れないようにする(技術書ではキャプションが入るのがほとんどなのだけど小説は挿絵でキャプションなしが主流だったりします)などなど目に見えない組版での工夫も入ってます。

続刊にあたっては「わかる!ドメイン駆動設計」にも多少手が入る可能性もありますが、しばらくは技術書と一緒に成長していきたいな、と思っています。

*1:筆者自ら書くにはとても手前味噌を感じたけど

*2:あんざいゆき。現在ちょうどMaster of Fragmentの改訂を手伝っているが、🐑の編集作業がストッパーになっている事実をここでお詫びしておく

*3:他にも実在する人物を参考にキャラクターデザインをしているけど本人とは一切関係ないフィクションです

*4:新規作成したRe:VIEWのA5レイアウトは公開予定。綺麗に組み上がりました