Androidエンジニア デザイン部を主催&発表しました

ハロー、瀬戸です。
新年度もよろしくお願いします。

2018/3/28にこれを主催&発表しました。

nohana.connpass.com

なぜやったか

誰もデザインエンジニアの勉強会を主催してくれなかったからです。

エンジニアとデザイナーの間には壁があると思っていて、その壁を壊していきたいと思っています。
そのためにエンジニアとしてはデザイン方面に進出していく必要があり、そのための一歩として勉強会を開催しました。

最初は個人開催にしようかと思ってたんですが、会社がとても好意的だったので会社主催にすることにしました。

想定外の参加者数

想定以上に好評でびっくりしました。

まず、応募開始1時間で発表者の4枠と参加者の40枠が埋まる。
増枠しても1晩で発表6枠と参加者70枠が埋まる。
その後もどんどん参加登録されて最大でキャンセル待ち60人くらいになりました。

Androidエンジニアとタイトルにつけたんですが、iOSの人とかデザイナーの方も参加登録してくれていてすごいなーと思いました。

当日もこちらの数えた範囲では参加枠で70人中61人が参加、欠席のうち半分は当日繰り上がりの人でした。とても良い参加率だったと思ってます。
知り合いが40人くらい来てくれたので、多分そのおかげもあります。
皆様本当にありがとうございます。

発表について

僕が聞く限りは、発表面白かったという声がものすごく多かったです。
これ教えてくれ！っていう話が多かった気がするんですが、結果気になってます。

懇親会について

iOSDCで聞いたパックマンルールがいいなと思ったので、みなさんにお願いしました。
僕が人の話に入っていくのが得意じゃないのですが、あれだと楽だなーと思ってます。
結構守ってくれていた気がします。ありがとうございます。

議論の場にして欲しいなーと思ってたんですが、結構みなさん色々議論されていた気がします。

僕はできるだけ多くの人と話そうとしたんですが、全然話せなかったです。
1組と5分くらいだけ話すと最初から決めてました。雑な対応だと思われてたらごめんなさい。
懇親会100時間くらいもらって全員とUI議論したいですねー

次回について

やります。次回はもうちょっとテーマ絞ろうかと思ってます。
それ以上は未定です。
Google I/Oから帰ってきたら本気出す。
待ちきれない人は自分で主催してください。

UIとかデザインの話は大好きなので、勉強会でなくてもいつでも気軽に話しましょう！

自分の発表について

speakerdeck.com

Material Designの世界を破っていく話＋Viewまわりの知識でデザイナーとの関係をうまく回そうという話をしました。
エンジニアが実装力をつけて実装するのは当たり前なんですが、もうちょっと目線を広げてデザイナーの役に立つ方面で考えたらいいんじゃないかなぁということです。

どうでもいいですが、書道茶道華道弓道とかやってる和風男子です。あとサ道と北海道と鉄道が好きです。

以下主催する側情報。

主催する側情報

個人としても弊社としても勉強会の主催が初めてだったので、色々と大変でした。

主催

疲れます。
帰り道はまっすぐ立てませんでした。

会場

mixiグループなので自社会場使えたのが楽でしたが、社内手続きとかもあって面倒でした。
会場貸してくれる会社があるなら頼るのも手だと思います。
そうすると自社名が売れないのでトレードオフです。

社内の役割分担とか工数とか

準備はだいたい自分1人でやって、5人日くらい使いました。
ノウハウがたまったので次は2~3人日くらいで終わると思います。

当日のことは現場監督役を作って、その人に全部任せました。
司会やりつつ発表者やりつつ現場の面倒を見るのは無理なので、これで正解でした。

あと受付2人と色々担当3人くらいです。
グループの人が片付け手伝ってくれてすごい助かりました。

注文した量とか
80人くらい来ると思って以下の量を頼みました。

アルコール類 : 120本 (参加者数×1.5本)
ソフトドリンク : 2L * 6本
ピザ : L * 8枚 (参加者数÷10枚)
寿司 : 20人前 (参加者数÷4人前)
お菓子 : キットカット * 2, オレオ * 2, ぽたぽた焼き * 1

他の勉強会を参考にしたのですが、食事も飲み物も全然足りなかったです。
飲み物に関しては、会の最初で乾杯するスタイルにしたことが原因かなと思っています。
食べ物は完全に見積もりミスです。オードブル類頼むべきだったんですかねー。
寿司はやっぱりお高いので、次回どうするかわからないです。

こういう系の情報はもっと共有されると嬉しいですね。

今後

ずっと社内でやるのか、ずっとノハナ社主催でするのかとか色々考えています。
どちらにも良いこと・悪いことがあるので自分の考え次第なのかなと思ってます。

やっていくぞ！以上！

スタンディングデスクを試してみた

唐突に社内にスタンディングデスクのお試しコーナーができました。
会社の先輩がモニターに当選したらしいです。
(なおこのブログはモニターとか関係なく勝手に書いているだけです)

せっかくなので試してみました。
この記事は機種の感想云々よりもスタンディングで仕事してみた感想です。

結論として、大変良いのでまた使います。

機種

Loctek社のM2Bかなと思います。
サイトが見にくいです。

https://www.fleximounts.jp/deskriser/

スペック

見た目

こんな感じです

社内にスタンディングデスクのお試しコーナーができたので試してみたけどめっちゃ良かった。ノリノリで集中できる。でもiMacの高さが2mくらいになるのでやや怖い。 pic.twitter.com/eTLd8p7xQy

— setoh (@seto_hi) 2018年3月27日

 機能

スマホ立てが付いていて大変良いです。
しかも下からケーブルが刺せる設計です。
QAチームの方は端末を3台並べてテストしてました。なるほど強い。

高さ

僕は身長が179cmなのですが、高さMAXにするとiMac(27インチ)の中心あたりとちょうど目線が合う感じです。
僕はIDEを画面下部に配置する人なので、MAXでもちょっと低かったです(なのでかさ増ししました)。

良い点

結構机が広いです。ちゃんと安定してます。
あとキーボードが一段下げて置けます(キーボードの高さ調節はできないみたいです)。

悪い点

個人の好みかと思いますが、キーボードの部分の奥行きが狭いです。
机がやたらと滑るのでパームレストが動いて不愉快でした。

あとキーを叩くとiMac揺れすぎ。
机の問題というよりもiMacの問題な気がします。
地上1.5mくらいのところにiMacを置いてるので、揺れると落ちないか結構不安でした。
固定するものが欲しいかも。

使ってみて

疲労具合

僕は座り疲れをするタイプで8時間座るとお尻の筋肉ががだいぶ疲れてしまうのですが、立ちなのでその点の疲労はほぼなくなりました。
肩こりについても、立ち姿を意識していたせいか普段より楽な気がします。
思いっきり猫背で立つのは逆に難しい。

その分、少し足が疲れます。
お昼をはさんで4時間くらい仕事をしたあたりから無意識に足のポジションを変えていました。
普段一切立ち仕事をしないので、最初はこんなもんかなと思います。

立ち姿勢や無理をしないようにしないと足腰をやりそうな感じがしました。
昨日の夜に背中がつりそうになりました。
運動不足です。

集中具合

めちゃくちゃ集中できました。びっくりしてます。

座っていると気が散っていろいろなことをやりがちなのですが、立ちだとタスクに集中できてとても良かったです。
今日はTwitterとかもあんまり見ず、大変良い進捗が出ました。

今日たまたま絶好調だっただけかもしれませんが、月1くらいで来る超集中DAYくらい集中できました。
この集中が毎日続くなら購入考えるレベルです。

その他

音楽を聴きながら仕事をしているんですが、今日はやたらとノリノリになれました。
手拍子したり踊り出しそうなくらいだったので、クラブとかはこんな感じなんだろうなぁと思いました。

どう使うのがよさげか

多分1日フルでスタンディングはつらそうな気がします。
以前はほぼ立ち仕事のバイトをしていたのですが、足が超疲れてました。
僕の使い方としては基本立ちで、疲れたりつまらないタスクをやるときは座ればいいのかなという印象です。

あと立ちのときの椅子の扱いどうしたらいいんでしょうかね。
邪魔ですよね。

また試して更に良い使い道を見つけていきたいです！

デザインと関わるエンジニアの悩みポイント

ハロー、@seto_hiです

今月末に Androidエンジニア デザイン部 #1 という勉強会をやるのですが、参加申し込みの際にアンケートを取ってみました。
内容はシンプルに「デザインに関して聞きたい話などがありましたらご記入ください」というものです。
1割くらいの方が回答してくれたのですが、大きく3つのジャンルに分類できるかなと思いました。
「実装」「組織」「デザイン」です。

自分なりの回答を書いていきます。
全部の悩みに対して「わかる」と言いたくなりました。
勉強会の懇親会でもこの話題で盛り上がってくれればと思っています。

次回の勉強会はジャンルごとに分けるのが良いのかな〜とか考えました。

1.実装の悩み

思ったよりこの内容が多かったです。エンジニアですしね。

Android4系のサポートコスト

うちの会社は割と諦めてます。サポートはするけど、完璧なMaterial Designの再現は目指しません。死にゆくOSにコストをかけるほど人が余っていないです。
半分くらいはshadowがつけれない問題かと思うのですが、ToolbarとButton以外はほぼ諦めています。
BottomNavigationは1pxの灰色の線を書くようにしてなんとかしています。

styles.xmlやthemes.xmlの定義の方法

いろいろな方が記事を書いてくださっていたようなので、読まれると良いかと思います。
styles.xmlとtheme.xmlで分けるのは良いと思ってます。

paddingのdp定義どうするか問題

うちは全然定義していないです。
paddingやmarginについてはそんなに再利用性があるものだと思っていません。

padding_8dpみたいな変数作るよりは普通に8dpって書いた方が効率良くないですか？
かといってpadding_smallみたいなのは抽象的すぎて使いにくいかと。
paddingを全部dimens化するのはちょっと冗長かなと思います。

難しい、他社事例を聞きたいです。

作りたいViewを実装する方法

ViewやViewGroupの内部実装を知ることが一番かなと思います。
onMeasureとonLayoutをとonDrawを自由自在に使いこなせると強いです。
僕はかなり使いこなしていると思います。Canvasは友達です。

あとはAnimationとかAnimatorとかTransistionとかDrawableとか覚えましょう。

2.組織の悩み

社内のデザイン意識を高める方法社内にMaterial Designを広める方法
社内でMaterial Design導入を説得する方法

これはデザイナーの悩みであって欲しいのですが、そうもいかないですよね。僕も2年前に直面しました。

弊社の場合は社内Material Design勉強会をやってことで意識が高まったのですが、そううまくいかないこともあると思います。
その場合、無理に進めることは良くないことかと思います。
Material Designに対して誤解があるケースも多々あり(ルールが厳密すぎるなど)、その誤解を解いたら話が進むようになるかもしれません。
また、単純接触効果じゃないですが良いところを地道にアピールしていくことは大事だと思います。
そのためには自分がしっかりとMaterial Designを理解しておくことが大事だと思います。

あと社内のエンジニアからデザインのことを語られるとイラッとくるデザイナーは少なからずいると思います(逆にデザイナーからコーティングについて上から目線で語られたら少しイラッとしますよね？)。
そんな場合には社外からMaterial Designに詳しい人を呼んできて話してもらうと良いのではないでしょうか。

手を尽くしても全くダメならば転職したらいいんじゃないですか(雑なアドバイス)

iOSと同じデザインからの脱却
AndroidらしいUIの構築方法

超わかる。

最低限、「Android(Material Design)らしいUI」を説明できるようにならないとこれは解決できないと思います。
また、すべてのiOS向けデザインを簡単にコンバートできる正解はない、というのが僕の意見です。
画面の設計意図を考えて、それをAndroid(Material Design)風に表現するとどうなる？というのを考えていくのが流れかな思ってます。

おがぱんさんの発表に期待してます！

デザイナーはどこまでやるべき？エンジニアはどこまでやるべき？

わかりません。多分答えはないですよね。
デザイナーとコミュニケーションを取って、お互いが不幸にならないとかお互いの最高速度が出る方式を意識しているつもりです。

あとお互い敬意を持つことも大事だと思います。お互いの専門領域は踏み込まないとか。

デザイナーがxml触る方法

実在してるかは知りませんが、これやってる会社は本当にすごいなーと思います。
どうやってやりはじめたのか是非知りたいです。

(エンジニアのレビューコストとかQAコストが高くなるので僕は否定的です)

デザイナーとのコミュニケーション

難しいです。わかりません。
組織論みたいな話になってくるのでもっと勉強して回答できるようにしたいです。
絶対に波風を立てないようにするよりも、必要な時は全力で殴り合う方が良いデザインが生まれるのではと思ってます。

後任のために議論の結果はどこかに残しておくべきで、僕はできるだけGithubに書くようにしています。
でもGithubで議論を始めると長くなるので、2往復くらいしたら口頭のコミュニケーションに切り替えて、その結果をGithubに書く感じです。

3.デザインの悩み

エンジニアなのにデザインに悩んでいる皆さん。欲張りですね。最高だと思います。
今は色々と確立されていない気がします。頑張って道を作っていきましょう。

良いツール教えて
ツールの使い方教えて

逆に教えてください！
早くSketchのプロトタイプが気になるので試したい...

アイデアをデザインに落とす方法

難しいです。ひたすら案を出してひたすら手を動かすイメージです。
最近はある程度パターン化できてきた気がします。
まだ言語化できていないので、言語化できるように頑張ります。

iOSとのデザイン統合化

細かいところは別として、画面の中心部はそこまで大きな差が生まれないのかなと思い始めて来ました。
iOSとAndroidで同じような体験を提供できる(OS間差異にそんなに影響されないアプリ)は、目指すゴールが両OSで近いと思うので、自然と画面設計も似てくるのではと思います。当然、API的にそうでないアプリもあると思ってます。

すべてを同じにするのは無理だよね〜(違うよね)というのは確信があります。

Material Designの中での自社の色の出し方

難しいです。悩んでます。

うちの会社はエモいアプリなので、画像をガイドラインよりも大きくしたりとかそういう部分で挑戦しています。

あとPrimary ColorとAccent Colorのちりばめ方は大事ですね。
少なすぎず、多すぎずみたいな。説明できない...
Accent Colorは10%以下にすべきというのはどこかで読みました。

Material Designどこを守るべき？どこなら破ってもいい？

Material Designはガイドラインでありプラットホームなので、自由にやっていけば良いと思います。
ただし、そのためにはガイドラインの理解が必要です。
理解した上で、その点をどうするかの判断をすべきだと思います。
理由があればガイドラインを破れば(超えていけば)良いと思いますし、理由がないならば破らない方が良いと思います。

御社なりのMaterial Designを見るのが大好きです。

勉強会ではこの内容について、弊社のアプリの事例を発表をする予定です。
資料作り頑張ります！
あと会場準備も！😇

詳解DroidKaigiの発表準備裏側

発表準備の詳しい話をあんまり聞かない気がするので書きます。
何かの参考になれば。

準備工数

多分100~150時間くらいだと思います。

FrameLayout、LinearLayout、RelativeLayoutの内部実装読むのに10時間くらい、
ConstraintLayoutの内部実装読むのに50時間＋αくらい、
スライド＋原稿作成に20時間くらい、
発表練習＋修正に30時間くらいでしょうか。

多分全発表者の中でもトップクラスに時間がかかってると思います。愛です。ConstraintLayoutが想像の110倍くらい複雑だったのでしょうがないです。
他の人がどのくらいの時間かけて準備したか知りたいですね。

11月中は休日と平日の帰宅後を費やして、12月と1月は休日だけ作業しました。
独身貴族で暇なのでこのくらいの時間が確保できます。
暇とはいいつつも今会社で新規案件をやっていて、アプリエンジニアとアプリデザイナーを兼任していて、ちょうど今が山場なのでさすがにしんどかったです。

11月12月で事前調査をして、
12月半ばくらいからスライドを作り始めて、
年末年始に発表原稿を書いて、
1月は練習しつつ修正という感じでした。
1月半ばに社内向けの壁打ちをやったので、その頃にはほぼほぼ資料完成してました。

発表原稿

本邦初公開、こんな感じです

発表中は多分文章が目に入ってこなくなると思ったので、重要なところを太字で書くようにしました。
これはとても良いです。オススメです。
抑揚をつけてしゃべることを意識しているので、そのあたりにも役立ちました。

僕は実際にしゃべる言葉で発表原稿を書く派です。
「完全に理解しましたね？ふぅーん..はぁ..」とかも全部書いてます。

発表で意識したこと

とにかく、多くの情報を与えることを意識しました。

今回のセッションは理解を深めるものでなく、知らないことを知るものだったと思っています。
なので、聴衆に情報を投げまくって、少しでも新しいことを知ってもらえたらなという考えです。取捨選択はそちらでしてねと思ってました。

人間は2倍速再生くらいの映画を認識できるとどこかで聞いたことがあります。(ソースが思い出せませんが)
なので、めちゃくちゃな早口であっても認識してもらえるだろうと思い、あのプレゼンスタイルになりました。

去年の発表は50分でスライド50枚くらいでしたが、今年は30分で90枚くらいです。
発表する内容によって発表方式を変えます。

発表を失敗しないために

どうしたら発表で失敗しないか。
発表で失敗する可能性がある項目を減らせばいいんです。

発表原稿を書いていないとアドリブでしゃべることになり、発表内容がぶれる可能性があります。
発表中にパニックになれば言葉が出てこなくなる可能性があります。
これらは失敗のリスクになります。
なので発表原稿を書きました。しゃべる文章で書いていているのもそのためです。

発表時間をオーバーするリスクもあります。
恐らく多くの発表は一番最後に重要なメッセージを言うので、そこを時間制限で切られるのは痛手です。
僕は各章ごとに時間を計測して、発表が想定よりも早い/遅いというのをわかるようにしていました。
時間が余ったら言う内容、時間が足りなかったら省く内容を決めていました。
ここまでやっておけば当日アドリブで余計なことを言わない限り、よほどのトラブルがない限り時間オーバーしないと思います。
発表の再現性を高めることも大事です。

発表内容がつまらなくて失敗するということもあります。
僕は聞きに来てくれそうな人に「何を期待しているか、何が聞きたいか」ということを結構質問しました。
コアユーザーにヒアリングをするのは仕事でも同じだと思います。

資料の事前公開

資料の事前公開も失敗を減らす手段のひとつです。
聴衆の人は思ったよりもセッションの詳細を読んでくれません。
こちらが発表する内容と聴衆が期待している内容が異なると「発表がつまらなかった」と言われる可能性があります。
時間をかけて準備したプレゼンに対して、本筋でない部分で批判をされる。これは最悪です。

そのリスクを減らすために資料を事前公開しました。
考えてみれば、資料がほぼ完成しているのに当日まで公開しない意味は特にないと思います。サプライズ感くらいでしょうか。

感謝

資料の事前公開ですが、僕の見た範囲だと前日の時点で10人以上の方が行ってくれたように思います。
まさか賛同していただける方がいるとは思っておらず、とても驚きました。
白山さんやこにふぁーさんや日高さんに取り上げていただいたことも大きかったと思います。
ありがとうございました。

謝罪

ただし、資料の公開についてはやり方が良くなかったと反省しています。
「資料公開しようと思っている」ツイートに想定以上の反響があり、かなり拡散していただけました。
結果として資料が完成していない発表者の方にプレッシャーをかけてしまったように思います。
ただでさえ資料作りは大変なのに、余計なプレッシャーを与えてしまったことには大変申し訳なく思っています。
ユーザーの気持ちを考える仕事をしているにも関わらず、ツイートを読んだ人の気持ちを考えられなかったことは恥です。

もう少し、何かうまい方法を考えたいと思います。

準備姿勢

準備時間が3ヶ月あり長丁場なので「気持ちが折れないように」という点を意識しました。
去年の準備は断酒をしたり飯食わなかったりと滅茶苦茶ストイックにやったんですが、体調崩したり気持ちが折れかけたりと後半に息切れ感がありました。
そもそも断酒と発表成果に関連性はあるんだっけ？無駄じゃない？と思ってやめました。

僕は訓練された人間なので、酒を飲みながら資料作ったりConstraintLayoutのコード読んだりしてました。できます。
発表原稿はだいたい年末年始に酒飲みながら書いたものです。Powered by 日本酒です。
おかげで去年よりも楽しく準備ができたと思います。

何が本当に必要なことがを考えましょう。仕事と一緒ですね。

来年に向けた改善点

・効率的に調査・資料作成できるようになりたい
・スライドの見た目をもう少し改善したい
　・でもあまり本質でない気がする
・体重を維持する手段を考える
・健康を維持する手段を考える
・睡眠時間を維持する手段を考える

DroidKaigi2018で発表しました

改めまして初めましてハロー、@seto_hi です。

DroidKaigi2018で「詳解ViewGroupのレイアウト内部実装」を発表しました。
恐らく3本くらいDroidKaigiに関するブログ*1を書きますが、これは発表についての記事です。

発表者と会場です。全く緊張してなくて、発表前に余裕で自撮りしてました。

資料

speakerdeck.com

資料の付録

1. 詳解 RelativeLayoutの内部実装 // Speaker Deck

2. ConstraintLayoutの機能の実現 // Speaker Deck

3. ノハナ社のレイアウト戦略 // Speaker Deck

1と2は発表の延長戦ですが、3はViewGroupの使い分けなどを書きました。
ものすごく有用*2だと思っているので是非読んでください。
こんな図とか入ってます。

セッションについて

朝一のセッションであり、かつ実用性があまりないセッションにもかかわらず、多くの人に来ていただいて驚きました。
日本にこれだけの数のViewGroupが好きなエンジニアがいるならば、日本の将来は明るいと思います。
また半分くらいの方が事前に資料を読んでくださったようで、事前公開した意味はとてもあったのかなと思っています。想像以上です。

今年は声が枯れることもなく、練習通りのことができたのではないかと思います。 
発表時間は手元の計測だと29分56秒でした。完璧ですね。

「メモを取らない方が良い」ということを言ったせいだと思うのですが、ツイートも少なくてセッションの感想が全然見えていません。
セッションに来てくれた知り合いに感想を聞いて回ったりするくらい見えていません。
よかった！という話は当然嬉しいですが、発表で不満だった点、理解が難しかった点が聞きたいです。それを聞けないと発表者として成長できません。
Twitterでも勉強会で会った際にでも是非教えてください。

オフィスアワーは質問が少なく、暇でした。
カンファレンスの良いところは、発表者が同じ会場にいて、直接会話することができることだと思っています。
質問をしない・感想を言わないのならば、アーカイブされた動画を家で見てるのと変わらないと思います。

発表内容について

発表の40分前にConstraintLayout1.1.0-beta5が公開される事件はありましたが、ちゃんと内部実装を読んでから発表しました。

「早口だけどわかる、完全に理解した(わかってない)*3」といういったような感想が何件かあって嬉しかったです。狙い通りです。*4
Cassowaryについては何をしているかをなんとなく理解してもらえればよく、それ以上のことは狙っていませんでした。なので完全に理解できなかったとしてもそれが正しいと思います。Cassowaryすごい、ConstraintLayoutすごい、それだけ分かってくれればいいんです。

みんな大好きレイアウト

Romain GuyとChet Haaseのセッションや、ConstraintLayoutのセッションでもレイアウトまわりの話が上がっていました。
ちょうど自分のセッションで話した部分が多く出てきて、謎の感動がありました。

資料にちょこっと書いたTraversalRunnableとかマニアックな話がRomainとChetのセッションでも出てきてマジか！マジなのか！！！と思いました。
ConstraintLayoutのセッションでもRelativeLayoutは2回measureするよねみたいな話があって、これ付録に書いた話だ！と感動しました。

自分のセッションが先だったので良かったですが、逆だったら爆死していたと思うので本当によかったです。

ConstraintLayoutの中の人と話した

ConstraintLayoutのセッションのオフィスアワーでNicolas RoardとJohn Hofordと話しました。英語全然得意じゃないけど突撃しました。
以下の内容は間違っている可能性があります。

「今朝ConstraintLayoutについて発表したけど、直前のアップデートには驚いたよ」と言ったら「どうなるか心配だったよ〜」的なことを言われました。そうですね。

Optimizerの存在意義について聞いたのですが、僕の発表した通りの内容で合っていたと思います。
ConstraintLayoutは基本的には高速、でも計算量がレイアウトと見合わない場合がある、そういった時に使うんだということです。

ConstraintLayoutのセッションでは2.0で計算が速くなると言っていました。
これも聞いたところ、よくあるレイアウトについてはOptimizerで解決できるようにしてsuper fasterにするということを言っていたと思います。(英語を全然聞き取れなかったのでちょっと自信がないです)
なぜsuper fasterになるかは、僕のセッションを聞いた人なら完全に理解できると思います。

内部実装を読んでいるときにもOptimizerはもう少し頑張れると思うんだけどな〜ここを強くするのかな〜という感想だったので、読みが当たって嬉しいです。

中の人と話せるなんてめっっっっっっちゃ貴重な機会だったのでとても嬉しかったです。
ConstraintLayou最高！って言いそびれたのが反省です。

最後に

いろいろな方への感謝を言いたいです。

まずは素晴らしい場を提供してくださった運営の方々、本当にありがとうございました。

Cassowaryの理解に大変役立つ発表をしてくださった @inamiyさん、本当に感謝しています。どこかで直接お礼を言いたいです。

かなり早い時期からセッション楽しみにしているよーと言ってくれたむーむーさんとふじたくさん、ありがとうございました。2人に楽しんでもらえることを目標にして準備頑張っていました。

セッション聞きに来てくださった皆様、ありがとうございました。フィードバック待ってます。

以上、まだどこかでお会いしましょう。
DroidKaigiが終わったので3月の勉強会の準備せねば...

*1:発表、準備、プレゼンとか

*2:もっともっと有用にしたい、でも何書いていいのかわからない

*3:某画像をスライド内で使いたかったけど著作権的に諦めた

*4:このあたりも別途記事にします

DroidKaigi2018「詳解 ViewGroupのレイアウト内部実装」の資料を事前共有します

Hello! @seto_hiです。

2/8の DroidKaigi 2018 の2日目の10:30〜「詳解 ViewGroupのレイアウト内部実装」という発表をします。
朝一ですが濃いセッションをやります。覚悟してください。

DroidKaigi、順調に行けば週末に資料公開すると思います。見てもらえればある程度のレベル感と内容が伝わって、CfP読んだイメージと内容が違ったという事故は減るかと。逆に資料だけ見て満足する勢が来なくなるリスクはあるけど、それは僕以外の人にはプラスになるので全く問題ないです。

— setoh (@seto_hi) 2018年1月31日

このツイートの有言実行です。
この件の詳細については、DroidKaigiの振り返り記事に書こうと思います。

なお、資料についてはすべてRC(Release Candidate)版です。
小さな修正は確実に入ります。また、間違いや間違っていそうな点がありましたら遠慮無くマサカリをお願いします。誤った内容を発表したくないので。

セッション資料

ご査収ください。 

speakerdeck.com

このスライドを見て、「思っていたのと違う」「全く理解できない」「完全に理解した(していた)」という方は、申し訳ありませんが今回の発表のターゲットではありません。別のセッションに行かれた方が良いかと思います。
「3〜7割くらい理解できた、説明を聞いてもっと理解を深めたい」という方は是非セッションを聞きにいらしてください。パーティーでもセッション前でも後でも質問大歓迎です。
発表を聞くだけなら後日動画を見ることもできますが、発表者と話すことはDroidKaigiの2日間しかできません。話しましょう。
完全に理解した方は、別の機会で深く話しましょう！

ConstraintLayoutについてはかなり浅い内容になってしまっています。
もっと内部の深い話をしようと思っていたのですが、ひとりでDroidKaigiが開催できるくらいの内容になってしまいそうなので今回は省きました。
需要はなさそう、どこかで発表したいという気持ちはあります。

付録

なんとこのセッションには3つの資料があります。
付録の内容について、セッションでは一切触れません。
最初に勢いだけでスライドを作っていたのですが、60分くらいの内容になってしまいました。かといってお蔵入りにするのも惜しいので公開します。

付録1 詳解 RelativeLayoutの内部実装

発表ではFrameLayout、LinearLayoutしか触れませんが、RelativeLayoutについても調べました。
循環参照の検知の実装はとても面白いので、資料を読んだ後に是非コードも読んでみてください。

speakerdeck.com

付録2 詳解 ConstraintLayoutの機能の実現

本来はセッションに含む予定だったのですが、時間の関係で省きました。
申し訳ありません。詫びスライドです。

speakerdeck.com

付録3 ノハナ社のレイアウト戦略

これは本当のおまけです。
セッションの内容が実用的でないので、少しくらい実用的なものを提供しよう気持ちです。
レイアウトどうしてますか、どうしたらいいですかとよく聞かれるので、良い機会だと思って明文化してみました。
もっと内容を拡充したいので、質問や要望などをお待ちしております。

speakerdeck.com

最後に

資料を公開しましたが、自分の発表の価値は資料だけではないと思っています。
文字や図だけでは伝わらない内容を理解させるために日々発表練習を重ねています。
当日はご期待ください。

DroidKaigiでお会いしましょう！

エンジニアがアプリデザインに関わっていくために必要なこと

あけましておめでとうございます。
最近業務で新規アプリを作ってるのですが、アプリデザイナーも兼任してます。
やっていく中で必要だなぁと思うことがあったので書き連ねます。

今のチームではAndroidエンジニア兼アプリデザイナーの自分と、プロダクト全体のデザインを見ているデザイナーがいます。
UIに関しては自分が担当して、配色やエモい画像とかはデザイナーが担当する流れになっています。

技術

「簡単に実装できること」を知っておくべきだと思います。
どうでもいいところなのに実装工数がかかる、みたいなデザインを作ってしまったらエンジニアがデザインをやる意味がありません。
「簡単に実装できること」を知るには網羅的に勉強をする必要があってまぁ大変です。
経験を積むしかないんでしょうか。

「どこまでなら実現できるか」を知ることも必要だと思います。
こだわる部分はこだわったUIにすべきで、それがどこまでなら実現できるかを知っておくべきです。
自分がViewGroup芸とかCanvas芸をやっているのはこのためです。

あとアニメーション系を簡単に実装できるようになっておくべきです。
Material Designだと意味を伝えるためにアニメーションは超重要です。が、それ以外にも微妙なデザインをよく見せるためにも使えます。
AndroidだとAnimation(Animator)やTransitionあたりですかね。
Transitionは便利なのにみんな使ってない感があるので勿体ないと思います。

知識

Material DesignとかHuman Interface Guidelinesは理解しましょう。
読むだけではダメです。理解するんです。

他人に説明できることを目標にすると良いと思ってます。
昔デザイナー相手にMaterial Design勉強会をやったのはいいプレシャーでした。

ツール

画面のレイアウト案を表現できるツールを使えるようになっておくべきだと思いました。今だとSketchあたりでしょうか。
業務でやるなら画面遷移図とか作る必要があると思いますし、自分以外のエンジニアへのデザイン指示をするにも必要です。

あと簡単なアイコンくらいは作れるようになっておくと良いと思います。
ちょっと直したい、みたいなときに自分で手を動かせるのは便利です。
SVGを生でいじるのはよくやるけどオススメしないです

センス

美的センスを付けましょう。
センスという言葉は色々ニュアンスがありますが、ここでは「何が優れたデザイン・美しいデザインであるかを理解し、デザインを自分で再現できる」という意味で使います。
デザインに関わるものに触れる機会を増やすことで美しいデザインが何かを理解できるのではないかと思っています。自分は他社アプリを触ったり美術館に行ったり本を読んだりしています。
デザインを再現できるようになるためには手を動かすしかないと思います。何もしなければ何も上達しないので悩んで手を動かして試行錯誤して経験を積むしかないです。

余談ですが、自分は深澤直人さんのシュッとしたデザインが好きでそれに近いデザインを作りがちなのですが、家族向けサービスにあんまり合わなくて悩んでいます。

もの

デザイナー感を出すためにiMacを買うといいと思います。冗談です。
iMacは画面が綺麗なので持っておくと良い気はします。画面が大きくてマルチタスクに便利ですね。

人

相談相手になってくれるデザイナーがいると心強いです。
デザイナーは経験が豊富なので、強いなというのを再認識しました。
師匠になってくれるデザイナーがいると最高だと思います。
師匠欲しいです。

以上！

3月にアプリデザイン好きなエンジニア向けの勉強会やりますよ！ご期待ください！