#droidkaigiに行ってきて思ったことをダラダラ書いてみる
初めてDroidKaigi参加したので、ちょっとまとめるのが遅くなってしまったが記憶が新鮮なうちに考えていたことを残しておきます。 https://droidkaigi.github.io/2017/timetable.html
参加したセッション
参考までに参加したセッションは以下。
How to apply DDD to Android Application Development
リリース自動化と効率のよいリリースフローを求めて
インスペクションとAndroid Lint Custome Ruleによる、単一責任実装の実践
Data Bindingで開発を気持ちよくしよう
Android Resources Refactoring
オフラインファーストなアプリケーション開発
How to remodel current testing environment
What's New in RxJava 2.0
Android ORMの選び方
How to implement material design animation
Kotlin + RxJava + Dagger2 + Orma + Retrofit で作るAndroidアプリ
2つのアプリ、1つの設計のデザイン指針
エンジニアが武器にするMaterial Design
LayoutManagerをつくろう
特に強く印象に残ったこと
特に印象に残ったテーマを以下に記していきます
オフラインファーストなアプリケーション開発
https://speakerdeck.com/zaki50/ohurainhuasutonaapurikesiyonkai-fa Realmすごい…。今のチームでもRealmいれてるけどバージョンが昔すぎて全然キャッチアップできてないことがわかった。 オフラインの時の体験を考えるってアプリならではの観点だから新鮮＆そこにも踏み込んで考えていけるのがアプリのいいところ。
実際今のアプリってどれくらいオフラインファーストにされているんだろう
すごくこのセッションの内容に刺激を受けたので、オフライン状態で今のアプリがどれくらい使えるのか触ってみた。
- Facebook、instagram、googleフォト、メッセンジャー、Google Play Musicはオフラインでもだいたい使える
- instaは前に読み込んでいた10件くらいはオフラインでも見えるようになってる。追加読み込みだけできない。
- twitterは微妙。ツイートはできる（iphoneのみ）けどタイムラインは見れない
- Google Play Musicはすごくて、自分の評価した曲はオフラインでも聞けるようになってる。おかげで端末が圏外であることに気づかなかった。
今のチームのプロダクトはどうなんだっけ
アプリの業務仕様上最新の情報を常にリクエスト投げて確認しなくてはいけないので、通信エラーにすごく厳しいアプリになってる（オフライン時は通信エラーダイアログが出てで画面遷移できない）。オフライン時にアプリを立ち上げるとマジでなにもすることができないアプリになってた。
今まで「通信状況の悪さ」はアプリでは担保せず、ユーザーの状況が悪いんだよというふうに伝えてきた。けどこういう簡単に実装できるプラットフォームが出てきたりすると、通信状況というのはユーザーの責任ではなくアプリの責任になっていくのではないか？本当は通信エラーで画面遷移できないとかは、こっちの勝手な仕様のためにユーザビリティ落としているってことになるんだよなぁ。
なのでこれからはより通信状況に依存しないアプリの操作体験を作っていかなきゃいけなさそう、作っていきたい。 実際有名なトップレベルのアプリはオフラインでもある程度操作できるようになっているし、通信状況がないこともとても控えめに伝えるようになってる。気づきそうで普段意識してない観点を考えるきっかけになってよかった。
エンジニアが武器にするMaterial Design
https://speakerdeck.com/seto_hi/enziniagawu-qi-nisurumaterial-design webと比較してアプリのデザインてグラフィカルなスキルだけでなくOSの標準の挙動とかOSが推奨しているデザインも把握していなきゃいけないよね→かなり負担なのでは？というところからアプリのユーザー体験みたいなところにエンジニアがもっと関わっていこうよ、というお話。特に、Androidは「iOSのデザイン、これAndroidにして」事件が多発しているし同じ課題を持っている人は多そう。
KPIの置き方のはなし
企画の人にとってはKPIに直つながる案件をしたいというのは当たり前なんだけど、時たま「ユーザビリティを多少落としてでも」アクションがあがる施策をやる判断になってしまうことがある。そういう時にわかってはいるんだけどもやもやするという経験があって、そういう時に「いやいや、ユーザビリティ落とすのはダメでしょ、なぜなら」を言えるエンジニアになりたい、けど言えない&うまく説明できない自分。この答えの一つが「エンジニアが武器にするMaterialDesign」なんだと思っている。本当はユーザビリティがKPIにつながっていること&重要さを証明できればいいのだが、現状難しいのかも。
キャリア戦略として
自分の会社はいわゆるグラフィカルデザイナーとUXデザイナーが別職種としているので、エンジニアがUXのところまで踏み込む武器のつけかたを見たことがなかったので、すごく刺激的だった。自分も興味がある分野だったので、これからどこ武器にしていくんだっけ？の参考にとてもなった。もうすごくステキな話で本当に聞きに行ってよかったと思った。
その他
他の会社の開発環境が聞けるの、すてき
なかなか会社内にいると開発環境も似たり寄ったりなので、他の会社の開発環境が聞けてとても刺激的だった。世の中のプロダクトがこんなにRxJavaやDaggerなどの今時のライブラリを使って開発してるとは…。ライブラリを入れる入れないはちゃんと判断が必要だけど、若干の悔しさを感じて帰ってきた。
企業ブース、すてき
CyberAgentのブースで看板サービスのbuild.gradleを公開します！という企画をやっていて、開発イケてます！ということがよく伝わってうまいプロモーションだと思った。転職考えてたら絶対候補にはいると思う笑
他にもいっぱいノベルティもらってとにかくはしゃいできた。
アプリのOSS化、すてき
あとは今年はDroidKaigiのアプリにコントリビュートするぞ！と決めていて、なかなかレベル高くてひよっていたけどちっちゃいバグフィックスでコントリビュート達成した。いつもネットで見ているアイコンの人たちにコメントしてもらえたり、コントリビューター一覧に名前が載ったり、はかなりモチベーションあがった（マージされた夜は興奮してしまって眠れなかった）。ただの参加者からDroidkaigiに自分も関わってるんだぞ！と思える感じ、最高。
まとめ
DroidKaigiのセッションはスライドも動画も後で見れるのだがやっぱり当日行って全部の時間なにかしらセッションを聞きに行くのがすごく良いことだよなと思っている。後で動画で〜だったら自分の知っている範囲で課題感持っているところしか見ないと思うので、新しい分野を聞きに行く点で生で参加するメリットはあると思う。アフターパーティに出れなかったのが残念。
ということですごく良い経験をしました。来年も参加したい。今後は登壇にもチャレンジしていきたい！
