タグ:エモい ( 2 ) タグの人気記事

d0252816_22330503.jpg


3月9日〜10日と2日間にわたって開催された、国内のAndroid開発者向け大型カンファレンス「DroidKaigi 2017」の二日目にて、『いまからはじめるAndroid 6.0対応 〜Android 7.0から8.xを見つめて〜』というタイトルで発表しました。

いまからはじめるAndroid 6.0対応 // Speaker Deck
(補足)サブタイトルがないのは、スライドのデザインの都合上です。

脳内のシミュレートでは20分でいい感じと思っていたら、実際は30分ギリギリでした。だいたい脳内シミュの1.5倍かかるという貴重な知見を得ることができました。

発表時にも触れましたが、コードを出した解説は今週中にQiitaの方で公開させていく予定です。いちおう発表後の反応から

1. Runtime Permissionを通常実装する場合とPermission Dispatcherを使った場合
2. Volley+GSONとOkHttp3+GSON、Retrofit+GSON

という順で公開していきます。あとこっちの方で(Qiitaだと技術系記事になってないので)なんであの3つを危ないと触れたのかも書きます。

それと今回の発表でもところどころでエモい感じのトークをしましたが、これには意味があります。

正直なところ、Android 6.0対応に必要な技術的な情報はもうかなりの量が投稿されているという認識があって、「やり方がわからない」で困ってる人はもうほとんどいないんじゃないかというのが自分の認識です。じゃあなんで6.0対応をしていないかというと、その必要性をチームだったり上司だったり、もしくはエンジニア自身が認識できていないのが一番の理由にあるんじゃないかと思ったからです。

今回触れた通信部分の変更とRuntimePermissionの追加は、前者は「ユーザーが変更に気づくことのない変更」ですし、RuntimePermissionは「エンジニアひとりだけでは進めづらい(周りの認識や協力が必要になる)変更」です。こうした変更は個人アプリであれば自身の意志で進められますが、仕事でチーム開発であれば自身からの提案が必要不可欠です。そしてこうした提案は、プロデューサー職やデザイナー職の方からされることはまずありえませんし、必要なことであればそれはきちんとエンジニア側から提案しなければいけないし、そしてこれは必要な提案であるということを伝えたいことで、あんな感じの発表になりました。

それと本当にWantedlyでスカウトメール取得可にしたときは、たくさんの企業からアプローチがありましたし、エンジニアの提案を尊重してくれそうな企業さんもいくつかありました。スライドの最後に「転職しよう」と書いたのは冗談ではなく、そのアプリに本気で人生を賭けるつもりがないのであれば、きちんと提案や相談を受け入れてくれる企業にいって、どんどんそこのアプリを良くしていってもらいたいです。みなさん、いいアプリ、作っていきましょう。

最後になりますが、当日参加した全ての皆様、スタッフのみなさま、おつかれさまでした。

[PR]
d0252816_19514465.png
【結論】
マネーフォワードで「砂場プロジェクト」の必要性を話してきました。
結論で言うと、そもそもマネーフォワードの人たちは「そんなのとうにやってるわい」って感じだったので失敗したなって気分になりました。

【本題】
先日、元エキサイトの上司で現マネーフォワード所属の方に誘われて、マネーフォワードの社内LT会に参加してきました。

直近でやったプロジェクト(?)と言えば『ズンドコキヨシゲーム』なんですけど、Google Play Game Service絡みは実装してるけどまともに話せるほどに調査していなかったので、こんなアプリを作ることの価値みたいなのを話すことに決めていました。
いや、でもそんな感じで発表していないな……。
要はエモい話です。
いや、でも「エモい」ってこういうことを言うんだっけ……? 業界用語よく分からない……。

資料はこちら>https://speakerdeck.com/yamacraft/sha-chang-puroziekutofalsesu-me

人それぞれでしょうが、新技術への興味が強いエンジニアほど、仕事上のプロジェクトでそれをフィードバックできないことへのストレスは大きいと思っています。とはいえ、中には仕事上のプロジェクトにフィードバックさせるには、明らかにリスクが大きすぎる場合もあります。
そんな中で「我慢する」という選択肢をエンジニアがとってしまうことは、ストレスだけでなく自身がレベルアップするチャンスも失ってしまいます。
そういった意味で、砂場(SandBox)的なプロジェクトを持っておくことはとても重要でないかと思った、という話です。

ここでいう「砂場プロジェクト」と「個人プロジェクト」とは別モノというか、個人プロジェクトの中にある砂場プロジェクトという位置づけです。
砂場プロジェクトとは、あくまでも「技術を試す場所」であって第三者の満足度や利益を追求するものではありません(それが目的ならともかく)。
「自分が自由に組み立てて、自由に崩せる」プロジェクトを用意し、自分の「技術の遊び場」をもっておくことで、少なくとも技術面に関してストレスの逃げ場を作れる機会が生まれるので、出来が如何にせよ(公開する必要はないので)積極的にプロジェクト作っていくのはオススメですよ。自分はそういう意味で、Google Play Game Serviceの遊び場としてズンドコキヨシゲーム作りましたっていうお話でした。

で、これは別件なんですけど、こういう時に「作りたいけど作るプロジェクトが浮かばない……」っていう人たちも当然いて、それも兼ねた「汎用的な研修課題」みたいなプロジェクト仕様書の存在ってあると便利なのかなって前職のときから考えていたので、その辺の資料は後日作成予定です。(Google Play Game Serviceの知見含む)
[PR]
by yamacraft | 2016-04-06 20:00 | いろいろ