Google I/O 2018初日キャッチアップ所感

普通にぐっすり寝て朝起きてからTLと公式ブログあたりを見ながらキャッチアップした。現地のみなさんには感謝しかない :pray:

色々あったので雑に所感をまとめておきたい。間違いもあると思うので何かあれば優しく指摘してくれると嬉しい。

App Bundle

developer.android.com

新しいapp publishingの仕組みで、ユーザーがダウンロードするアプリのサイズを小さくできるのがメリットっぽい。公式ページの Stop managing multiple APKs という力強いタイトルが印象的だった。

自分の所属しているKyashのアプリでは、multiple apkで5個のアプリに分割することでアプリサイズが1/3くらいになっていたのだけど、それも必要なくなるのか。「Good bye Multiple apk」というPRを作る日も近い。

このApp Bundleの目指すところはアプリの肥大化を防ぐというところで、multiple apk以外にもDeliver features on-demandという機能ごとに配布する仕組みというのを用意している。ユーザーの属性ごとに分けた時に、新規ユーザーにとっては使わないような機能を別モジュールに分けておいて、そのユーザーが必要になったタイミングでfeature moduleをダウンロードして使うことができるという話のようだ。Kyashの中では今のところそんなに使わなくてもいいかなーと思ったけど、メルカリでは本人確認の部分だけ切り出すみたいな使い道がありそう。使いどころベストマッチだ。

課税対象になったユーザーの本人確認とか法律上必要だけどめったに使わない機能には最高だと思ってます

— Tomoaki Imai (@tomoaki_imai) 2018年5月9日

Enable modules to run instantly, without install と言っているのは、Instant Appsのことだろうか。Instant Appsなー、Instant Appsを導入したら視聴時間が5倍に増えたという動画アプリの話がちらっと出ていたけど、正直あんまり実感がなくてなんでそうなるんだ？って印象である。Web版リリースしてるならWeb見ればよくない？Instant Appsの何が優位なのだろうか。そもそもWebがない場合とか、操作感の違いをユーザーが敏感に感じ取って数字に出るとか？いまだによくわかっていない。

発表の様子を見るかぎり、on demand機能を使おうが使うまいが機能ごとに細かくfeature moduleを切っておくのは筋が良さそうだなと感じた。Instant appsだけだと設計難しいし管理が煩雑になるしあんまりメリットないんじゃないかと思っていたけど、どうやら世はfeature multi module時代らしい。slicesのように一部の機能を外だしすることを考えても、分けておく方がよいのだろう。KyashではAuthと送金部分をfeature moduleに分けておくと、今後面白いことをしやすいのかもしれないと思った。マルチモジュールの実践についてはkgmyshinさんの本を読もうな

kgmyshin.booth.pm

ちなみにdynamic deliveryはAndroid5.0以上のみっぽい。すでにminSDKを21にしていたKyashでAndroid開発したい人ウォンテッド。

A fundamental component of Dynamic Delivery is the split APK mechanism available on Android 5.0 (API level 21) and higher.

ConstraintLayout

すぎょい。アニメーションエディタすぎょい。 morphをあんな感じでいじれたら楽しいだろうなと感じさせるデモだった。自分はまだGUIエディタを信じきれないところが大きいのだけれど、ConstraintLayoutのchainくらいはGUIを使い始めているし、ちょっとずつGUIとも仲良くしていかないといかんなと思った。

AbsoluteLayoutが死んだらしい？RelativeLayoutの番も近いので、Goodbye RelativeLayoutというIssueを立てた。こういうのは一日一善でちょっとずつ書き換えていくのがよい。

Navigation Editor

すぎょい。これが欲しかったという人も多いのではないか。これもGUIかーみたいな気持ちにちょっとなったけど、xml依存の考えは捨てて仲良くなるのが良いのだろう。

Navigation Editorからの派生か、できればSingle Activityにしとけよみたいなスライドもちらっと見た。まじか。 別にできなくはないけど、Fragmentだけでやっていくのかーという気持ちになった。Navigationいい感じに使えば問題ないのだろうか。Navigationに関してはすぐにCodeLabをやっておいたほうがよさそう。まあ公式にSingle Activityの方がいいと思うで、みたいな感じで言ってくれるのはありがたい。

↑ と思ったけど自分の勘違いで、むしろ逆に画面遷移にFragmentむやみに使うなってことらしい。安心した

アプリ全体ではなく1つのEntry point、って言ってたから1画面1Activityで、画面遷移にやたらとFragment使うな！って文脈かとー

— mochico@I/O2018 MountainView (@_mochicon_) 2018年5月9日

twitter.com

Material2

相変わらずドキュメントが充実していてすごい。Sketchのプラグインもあるとはいたれりつくせりだと思った。 個人的には指針にブレがなければ変化に対してはとてもポジティブな印象である。Flutter向けのコンポーネントも公開されてる。

Material themingはカスタマイズするための指針という認識であってるのだろうか。エディタも用意されてるらしい

material.io

年々ユーザーが迷いなく使えるように手厚くしてくれている気がする。ありがたい。 個人的に気になるのは、このエディタで編集したテーマをそのままコードにエクスポートできるのかというところ。 Material designが出てきた時にさ、テーマでいい感じに見た目が共通化できるって話になってすげええって思ったけど、結局primaryColorってどこに適用されるんだっけ？とかこの色ここに反映されんの？！みたいになってつらかった思い出がある。今回そのへんも解決されると嬉しいなと思った。

これからしばらくGitHubでMaterial Design2ショーケースみたいなサンプルアプリが爆増しそうな予感。

Gallaryというデザイン共有ツールもよさそう。弊社デザイナー氏に共有したら、興味を持ってはいたものの、また覚えること増えるのかw週末やっていき！みたいなことを言っていた。わかる。めっちゃわかる。本当にいろいろ変わって大変だよね。一緒にやっていこうな。

Google Assistant

普通に人間じゃんと思った。むしろここまできたら次はキャラづけしていくしかないやろ。 サイコパスのキャンディーとかドミネーターとかタチコマとか夢が広がる話であるが、おそらくそういうことはやらなそう。

真面目な話をすると、Google Homeの対応とか早めにちゃんと考えて実装しておくのがよさそうだと思った。 Kyashで「Kyashでkobakeiに1000円送金して」とか言ってできるようにしておくのがいいかも。嫁さんに話したら「なんで声に出してそんなこと言わなきゃいけないんだ、恥ずかしいじゃん」とか言われそうだけど。

---

Material Design2はもっとキャッチアップしたい。 この発表の内容、こう取り入れたら本業アプリでも活かせそうだねみたいな話を社内メンバーとできるのは楽しいなと思った。とりあえずApp Bundleは迷わず対応しておけばいいんじゃないかな。と言ってもdeliver feature on demandをやらない限り実際にやることはほとんどないけども。

真面目な文章にカッコを多用するのはやめたほうがいいのではないか

うまく言語化できないんだけど、カッコを多用するのはやめたほうがいいと思ってる。言語化できていない以上自分の感覚による好みでしかないのだけれど、雑に考えをまとめておきたい。

どういう文章かというとこういうやつ。

カッコを多用するのはやめたほうがいいと思ってる（もちろん例外はあるが）。言語化できていない以上自分の感覚による好みでしかないのだけれど、雑に考えをまとめておきたい（言語化には時間がかかるのでまだ整理ができていない）。

Twitterでは文字数上限と空気感のせいかあんまりいなくて、特にFBの投稿に多い印象ある。

なんでよくないと思うかというと説明が難しいのだけど、なんか文章が練られていないような印象を与えるんだよな。言い訳がましいというかいちいち面倒くさいというか。雑に例えると、対面で話しているときに「その時にミッちゃんがね、あっミッちゃんっていうのは仲いい友達なんだけど〜」みたいな感じの補足の仕方と似ている。

自分もパッと考えて話すのが苦手で、話すときはこんなふうになってしまうんだけどね。けど文章は練る時間があるから別だと思う。

すべての文章に対してそんなに気を遣う必要はないんだけど、真面目な文章や意識高めな文章を書く時は気を遣ったほうがいいと思う。真面目な話でカッコを多用すると伝えたいことをちゃんと練って伝えられないようなまとまりのない文章になる。すごく悪い言い方をすると馬鹿っぽく見えてしまう。

じゃあどうすればいいかというと、まずカッコの中の文章が必要なのかどうかチェックするといい。カッコの中身は大抵言い訳だ。誤解されるの怖くて言い訳書きたくなる気持ちもめっちゃわかる。わかるんだけど必要かどうか一度確認したほうがいい。その上で本当に必要ならカッコの前に持ってきて文章を整えるか、脚注にするほうがいい。

この感覚は自分だけなのだろうか。気になるところである。

何も起きなかったことを評価する

猫を２匹飼っているんだが、２匹目のツーがワンパクで常にいたずらを考えて生きている。しかしごく稀にいたずらを"しないで"いい子にしていることがある。そういう時に「偉いねぇ〜」と褒めようとして考えたことを雑にまとめておきたい。「何もしなかった」あるいは「何も起きなかった」ことをどう評価すべきなのかということだ。

猫の例だと、おとなしくしていたことに対する評価をする上で２つの問題がある。

まず、よく考えたらそもそも偉いわけではない。普段のいたずらが過ぎる分、相対的に偉く見えているのだ。この行動を褒めて評価してしまっていいのかという点。不良が更生して称賛されるのに似ている。

２つ目は、なぜ褒められたかわからないのではないかという点。何もしなかったことに対して褒めるという行為は、本人にとってもなぜ評価されたのかわかりづらい。もしくは本人はわかるかもしれないが、まわりから見たら何が評価に値するのかわからないことがある。常にいい子にしている猫ワンがこの評価を見たら不服に思うかもしれない。

こういう話は人間界の仕事の場でも悩ましいところである。たとえばインフラは何も起きないで安定可動していることが素晴らしい。アプリを作っている人もバグが起きないことは評価されるべきだ。

猫ツーのように、すでに何かが「起きている」状況での相対的評価はやりやすい。傾向に対して改善したかを見て、改善具合に対して評価すればよい。

対して、絶対評価は難しい。縁の下の力持ちは縁の下にいるから見つけにくいし、いなくなったら今の日常が壊れることを想像しにくい。健康な時に病気の時のことを想像して感謝できる人は少ないよね。

適切に定量的に評価するにはどうしたらいいのだろうか。

何も起きないことが評価されるべき仕事の場合には、想定とプロセスを評価すべきなのかもしれない。アプリのバグ0件だったとしたら、バグがなくなる工夫を必ずしているはずだし、バグがなくなったことで他に時間をかけられるようになったはずである。こういうのを深堀りすれば適切に評価できるのかもしれない。

問題は、その深堀りはめんどくさいということだ。他者にわかってもらえるくらい説明するのは意外とめんどくさいのだ。結局、何も起きないことの価値をわかっている人が評価するしかないのかもしれない。

とか考えているうちに猫ツーがエサを食い終わり、猫ワンのエサを漁ろうとしていた。何も起きないことの価値を本人がわかっていないこともあるのだ。

技術書典4 く-52で『Flutterミニレシピ』という薄い本を出します

ときが経つのは早いもので、もう当日である。そして快晴である。ﾔｯﾀﾈ!!

30ページくらいの薄いFlutterの本を頒布します。500円です。

すみません、12時くらいに売り切れました :bow:

いやーFlutterはドキュメントがめちゃくちゃイケてるから「そもそもワシがこれを書く意味って何かな？」っていう葛藤の連続だった。

Flutterのインストールとかはドキュメント読んでできる前提で、細々とした実装のレシピを7つくらい書いた。目次とか読んで気になったら買いに来てください。

表紙も自分でかいたんだけどめっっっっちゃ時間かかった。絵師さんは神。すごい。

個人的には可愛い表紙がかけた。Flutterには「ときめく」って意味があって、胸がときめくような感じの表紙をかくぞと決めてたのでよかった。

心残りはたくさんあるけど、それは次に活かすとしてまぁ楽しもう。く-52で僕と握手！

「ちゃんと」という言葉が与える印象

今日も今日とてインターネッツは怒りに満ちている。

chantoという働く女性向け雑誌の中吊りを見て、不快感を感じる人がいたようである。

朝から奥さまがご立腹です。

働く女性のための雑誌「chanto」かぁ。そもそも名前が呪いだもんね。働く女性のためなのに「ちゃんと」はひどい。 pic.twitter.com/yxPBrzhgoo

— 39歳、パパ初心者 Aug,2016 (@taiki_no_papa) 2018年4月11日

個人的には「ちゃんと」という言葉には何も感じなかったので怖いなーと思った。無意識のうちに誰かを傷つけてしまうのってつらいよね。

気になったので「ちゃんと」という言葉の意味を調べてみると、こう書いてあった。

1. 《副・ス自》すべきことをきちんと行うさま。「仕事を―する」。規準にかなって整っているさま。 「ゆがめず―並べた」
2. 《副》ぬかりなく。まさしく。 「―知ってるぞ」

どうやら言葉自体にはそんなに悪い意味はなさそうだ。

ではなぜこの言葉に不快感を覚える人がいるかというと、「ちゃんと」のあとに続く言葉にいい思い出がないのだろう。

「もっとちゃんとやれよ」「◯◯くんはちゃんとできてるのに」「ちゃんとしなさい」のように、「ちゃんと」のあとに続くのは厳しい指摘が多いのかもしれない。

いやーこういうのは育ってきた環境によるから難しいよね。雑誌の企画者の神経を疑うみたいなコメントあるけどさ、もしかしたら企画者の方は「ちゃんとできたね！」みたいなポジティブに褒められる環境で育ってきたのかもしれないじゃん。だとしたら悪気0%だよね。

働く女性は家事も子育ても本当に大変だと思う。そんな時には「時短できない家事はない。（あなたももっとchantoやろうね）」というふうに読んでしまうのは仕方ないことだ。

大事なのは、同じ言葉でも受け取る人の経験やその時の精神状態によってだいぶ印象が変わってしまうということを心に留めておくことだ。これは想像力と思いやりの問題だ。

想像力の話でいえばさ、この雑誌の企画をした人も企画から校正まで色々大変だったと思うよ。それにこの雑誌のターゲット層ってたぶんこういう言葉自体ではなく実際のノウハウに集中したい人なんじゃないかな。たしかに言葉のチョイスはあんまりよくなかったのかもしれないけど、実際の記事内容がクソかどうかを判断しないかぎりあんまり感情的にディスるのもよくないよなと思った。

数字目標と悪手

雑にまとめる。今所属している会社の話ではない。

ダサいけどやれば短期的には数字が上がる施策というのが存在する。

ダサいという表現は主観が混じっているし攻撃的な言葉だけれど、めんどくさいのでここではダサいと表現する。

例を上げると、ウザいPush通知とかだね。自分がユーザーだったらウザくてアンインストールしちゃうよなと思いながらも、全体の数字を見ると上がったりするからたちが悪い。

小さな組織なら軌道修正しやすいんだけど、異なる数字目標を持つチームが複数できてきたりすると、部分最適の集合みたいになる。

全体を考えて数字以外の責任を持つつよい役割の人をおいたほうがいいという組織課題な気もする。そりゃ短期間で設定された数字上げることに責任を持ってたら視野が狭くなるのは仕方ないよな。それかいっそトップダウンの命令でやっていったほうがいいのかもしれない。

友達のエンジニアさんから「アプリの通知ちょっと多いですよね」とか言われたら辛い気持ちになるんだよな。わかる。わかるんだけどごめんってな。

こういう感覚をわかってもらうにはどうすればいいのだろうか。組織を変えない前提だとすると、Slackにヘイトツイートを流すようにするとか？あるいはまずは一緒に数字を改善して信頼を得たほうがいいのかもしれない。同時に、Push通知を送る対象のセグメントを改善してウザくないようにもできる。もしかしたら抽出の条件を変えられなくて困ってるのかもしれないしね。

ダサいことをやってると中の人が萎えたりするので危険だ。しかしできることならダサいことをやっている理由を深堀りしたほうがいい。何事も歩み寄りが重要だ。まぁそんな元気がすでにないなら会社を離れてもいいかもしれない。

デジタル画入門10日目 : 影を塗ったりした

影を塗ってみたらちょっとずつ表紙っぽくなってきた。

ただ、もともと目指していた透明感のある絵ではなく、重厚感のあるボテっとした絵になってしまったかもしれない。

これはデジタル画の色彩調整とかでなんとかなるのだろうか。もう時間がないのでこのまま塗っていって完成させるぞい。