コネヒト開発者ブログ

コネヒト開発者ブログ

0からAndroidチームとしてチームビルディングをやってみた

f:id:tommy_kw:20180326191437p:plain

こんにちは

こんにちは、Androidエンジニアの富田です。コネヒトのAndroid専任エンジニアは僕1人で心細い状況だったのですが、昨年11月にAndroidエンジニアの関根さんにジョインしていただき、晴れてAndroidエンジニア2名体制となりました。そこで今回はAndroidエンジニアが1名から2名になったことでチームとして始動しましたので、チームビルディングについて共有したいと思います。「我々はどこから来たのか」、「我々は何者なのか」、「我々はどこに行くのか」というゴーギャンの3つの問いを参考に、過去、現在、未来とそれぞれ振り返り、未来を創造したいと思います。

過去 〜Androidエンジニア1名体制〜

1人でAndroid版ママリを開発していた時は周囲を巻き込むことなく黙々とIssueに取り組んでいました。アウトプット面に関して言えば、コネヒトは開発ブログを書く文化が浸透していて昨年だけで46本の開発ブログが公開されています。僕もその文化に便乗させてもらってKotlin関連のブログを公開することでコネヒトのAndroidのプレゼンスを少しでも高めようとしました。

tech.connehito.com

しかし、1人でプレゼンスをあげることに限界があり、さらにサービスや事業拡大と共に自分自身が属人化や単一障害点になっていることに気づきチームビルディングについて意識するようになりました。加えて僕は自分ゴト化や周りを巻き込むのが苦手なので、これを機にスモールなチームで主体性を身につけて会社やサービスに対して貢献、または知識を還元したいと思いました。

現在 〜Androidエンジニア2名体制〜

その後嬉しいことに関根さんにジョインしてもらいました。ここからAndroidチームとしてゼロスタートするのですが、まず僕たちが何を目指すのかディスカッションしてみると、「自己完結型のチーム」、「エンジニア自身の成長」、「社外に対してプレゼンスを高める」などの目標、課題がみつかり、具体的に次のように目標を設定してチームビルディングに取り組みました。

プロダクトの品質を高めるチーム

ネイティブアプリの解析系ツールはたくさんありますが、ツールが多すぎてうまく活用できていないと感じた事はありませんか?コネヒトでも同様に Google AnalyticsMixpanelBigQueryFirebaseAdjustなど多くのツールを利用していたため、データの所在がわかりにくいという問題がありました。

先日永井さんの記事でも紹介されていましたが、コネヒトでは非エンジニアでもデータ出しに対する敷居を下げるために「データの民主化」が促進されており、データの一元化やカジュアルにデータ分析できる環境が整っています。ネイティブエンジニアはあまりSQLを触る機会が少なかったため、社内でRedash勉強会を開いて施策に対して僕らでSQLを書き、ダッシュボード化や効果の見える化を推進しました。tech.connehito.com

アンチフラジャイルなチーム

下記のいとしょさんの記事でも言及されていますが、変化を楽しみ、進化を続けるチームになるべく、以下の3点をやり遂げたいと思っています。

  • 職能・職域に囚われない
  • 小さな失敗を繰り返して成長する
  • ルールなしで自走出来るようにする tech.connehito.com

具体的にAndroidチームとして実際に行ったことは以下の通りです。

  • スプリント毎にKPTを用いた振り返り
  • 毎日朝会をすることでチームとしてやることを明確化

コネヒトの開発チームは1スプリント2週間単位の開発体制を導入しています。開発チームとは別にAndroidチームとしてKPTを用いた振り返りを実施し、「Kotlin率80%」、「クライアントチームで時間をとってRedashで施策に対しての見える化」、「リグレッションテストの作業分担」などのトライを行いました。また振り返りでは、「支え合い」、「自走サポート」などを心がけていたため、チームだけでなく、組織としての個人目標についても困ったことがないか共有し合っていました。

エンジニアが成長している

DroidKaigi 2018のアプリのコードが公開された日に自発的にお互いカンファレンスアプリにコントリビュートできました。残念ながら2018年のCfP応募は落選したためコネヒトからは誰もDroidKaigiに登壇できなかったのですが、「来年こそはDroidKaigiで登壇したい!」、「スタッフになりたい!」など自然と新しい目標が生まれました。

github.com

github.com

ママリのAndroidアプリはJavaとKotlinが混在するアプリで半年前までKotlin率が60%だったのですが、現在はKotlin率84%となりました。Kotlin率を上げるためだけにコンバートを行っているわけではなく、例えば仕様を理解するためやリファクタリング時にコンバートしていて、地道にですがKotlin率100%が見えてきました。 f:id:tommy_kw:20180612211105p:plain

社外に対してもプレゼンスをあげる

Connehito Marchéというコネヒト初の社外勉強会を開催しました。白金高輪界隈では、あまり勉強会が開催されいない印象でしたが、多くの方にLT登壇していただき少しプレゼンスをあげることができました。引き続き白金高輪界隈を盛り上げて行きたいと思います。 tech.connehito.com

僕がKotlinにコントリビュートしている関係で、関根さんにもKotlinのコントリビュートにチャレンジしてもらいました。最初のコントリビュートに対して少し敷居が高いと感じていたため、Dev Dayを活用してハンズオンを行いPRまで投げてもらうところまで進めました。Dev Dayとは普段の業務の中で取り組めない課題の解決や業務の改善を通じてコネヒトをより良くする日を設けています。今後の目標はAndroidエンジニア全員がKotlinにコントリビュートしてコントリビュート率を100%にすることです! github.com

未来 〜サービスデザインチームへ〜

目標に対して引き続きトライすることに変わりないのですが、特にサービスデザインを出来るチームを目指したいと考えています。サービスデザインとは、課題に対して一方的な価値の提供ではなく、共創という観点からさまざまな人々を巻き込んでその能力を引き出しながら、これまでにないサービスを作り出す方法です。以下のきよえさんの記事ですが、これがチームビルディングを行う上で良いヒントとなっています。デザイナー、非エンジニアだけでなく、エンジニアもサービスデザインをすることによってより良い関係性を生むと思いますし、クローズドなコミュニティを展開する僕たちエンジニアもプロダクトや組織の良さを発信し続けなければならないです。 note.mu

決意

「過去を振り返り」、「現在を見つめて」、「未来を思い描く」これらをステップごとに振り返ることによって、今後のやるべきことが明確化されました。改めてAndroidチームとして僕たちの存在意義ってなんだろうとディスカッションしてみると、「ママの一歩を支えるため」、「Androidユーザが快適にアプリを利用できる」、「質の高いママ向けアプリを提供するため」などのキーワードがありました。これらを達成するためにサービスデザインを実現できるチームへと変化して行きたいと思います。

サーバーサイドエンジニアがPhpStormでJSを書くために設定したこと

f:id:supermanner:20180612125259p:plain いつもコネヒト開発者ブログを読んでくださっている皆さま、こんにちは。 サーバーサイドを書いている結城(@super_manner)です。
最近は通勤途中に海外ドラマのシリコンバレーを見ることにハマっています。 好きな登場人物はギルフォイルです。過激なワードのリスニング力が上達しましたw

さて、導入の自己紹介やタイトルでも触れましたが、私はコネヒトでは普段サーバーサイドを担当しており、PhpStormを使用してAPIを書いているのですが、ひょんなことから最近はフロントエンドのIssueにもチャレンジすることになりました。
すごく新鮮なので、毎日楽しくコードを書いています(^^)

初めは社内のフロントエンドエンジニアから便利なパッケージを教えてもらえることもあり、JSを書くときのみAtomを使用していたのですが、数ヶ月つづけていると、フロントエンドとバックエンドを書くときでエディタを切り替えるのがやっぱりめんどくさい!!!と感じるようになりました。
そこで、コーディングに使用するツールを今まで使用してきた馴染みのあるPhpStormに寄せてしまうことにしました。

いろいろ強力な機能を持っているPhpStormですが、今回はこれがないとJSを書くときに辛いなぁと感じた基本的な「Flow」と「Prettier」の設定についてご紹介します。
意外とまるっとまとまっている日本語の記事がなかったので、参考になれば幸いです。

参考:コネヒトのフロントエンドについての記事です 👇 tech.connehito.com

Flowの設定

コネヒトでは型チェックにFlowを使用しています。 下記の手順で設定することによって、型が間違っているとFlowのタブが立ち上がり教えてくれます。

  1. Preference -> Language & Frameworks -> JavaScript を開く
  2. JavaScript language versionを Flow に設定 (すると Flow and JSX in ECMAScript6 も読んでくれました)
  3. Flow package or executable の項目にFlowのpathを記入する

f:id:supermanner:20180606191449p:plain

型が変だと、このようなタブが開きます 👇 f:id:supermanner:20180606191523p:plain

prettierの設定

すでに多くの方が導入されているであろうprettierも一緒に設定してしまいます。ファイルの変更をリアルタイムに検知して修正してもらいたいので、File Watchersを使います。JetBrainsのブログにわかりやすくまとまっていたので参考にしました。 今回はeslintの設定を噛ませているのでprettier直実行ではなくeslintでの実行となります。 コネヒトの環境はこちらの記事でご紹介しているので、興味があれば見てみてください! (githubはこちら) tech.connehito.com

  1. Preference -> Tools -> File Watchers を開く
  2. +を押して新規作成し、好きな名前をつける
  3. 整形対象のFileと監視対象のScopeを選択する
    1. 今回はtypeはJavaScriptにしました
    2. Scopeは余計な設定系のJS Fileまで監視しないように設定しておくのがいいかなと思います
  4. Tool to Run on Changeに必要なものを記載していく
    1. Programの項目に, eslintの実行ファイルのpathを記載
    2. Arguments に eslintrc --fix $FilePathRelativeToProjectRoot$ を記載
    3. OutPut paths to refreshに -c /path/to/.eslintrc --fix $FilePathRelativeToProjectRoot$ を記載
    4. Working directoryに $FilePathRelativeToProjectRoot$を記載
  5. お好みでAdvanced Optionsを設定

f:id:supermanner:20180606191735p:plain

こちらもSyntax Errorがあると、タブが開いて教えてくれます👇 f:id:supermanner:20180606191813p:plain

ちなみに、IDE自体の設定なのですがAuto Saveの設定をしていると何回もFile Watcherが走って大変重いので、差支えがなければ外しておいたほうが良いかもしれません。 この辺りはまだまだ未知の設定がありそうなので、もっと早く出来る設定があれば是非共有していただきたいです!

また、本エントリーでは触れていませんが、Extra Toolとして設定して任意のタイミングで実行する方法も公式ブログにありますので見てみてください!

最後に

私はなんとなくずーっとJSに苦手意識を持っていたのですが、普段自分が使っているツールを使いつつ自動でやってくれるところは任せていくことで、 だんだんと苦手意識も薄まりフロントエンドのコーディングが楽しくなってきました(^^)
とはいえ、まだまだ知らないことがたくさんあるので日々のIssueと向き合いながら勉強していきたいと思います! もし同じようなことを思っている方がいて、この記事がちょっとでも踏み出す一歩になれば幸いですmm

広報から見るAWS Summit 2018に登壇するメンバーを支える開発部

こんにちは。コネヒト開発ブログに初登場、広報担当の地田です。

今回は、広報担当からみたコネヒト開発部についてご紹介をさせていただければと思います。

AWS Summit 2018について

今回、コネヒト開発部についてご紹介するにあたり、欠かせないのがAWS Summit 2018。

AWS Summit はクラウドコンピューティングコミュニティーが一堂に会して、アマゾン ウェブ サービス(AWS)に関する情報交換、コラボレーション、学習を行うことができる日本最大級のクラウドコンピューティングカンファレンスです。 AWS Summit は世界 23 ヵ国以上 33 か所以上の都市で開催され、東京では 2018 年 5 月 30 日〜6 月 1 日、品川にて開催します。 AWS Summit Tokyo 2018 では、基調講演、お客様事例、ユースケースセッション、AWS の最新テクノロジー動向や多種多様な業種や企業規模でのクラウドサービス活用例など、150以上にもおよぶ AWSならではのセッションをご提供します。また、展示スペースではスポンサー企業様のソリューションの他、AWS や Amazon の最新サービスについても見て、触れて、学べる展示を実施します。(AWS Summit 2018のページより)

www.awssummit.tokyo

本イベントで、初めての開催となる「Startup Architecture of the year」という「アーキテクチャ」にフォーカスを当てたピッチコンテストがあり、そこに当社のエンジニア永井の登壇が決まりました!

詳細はこちらから。 aws.amazon.com

広報担当の気持ち

「AWS Summit 2018という大規模なイベントの登壇が決まった!」「すごい!」ととってもうれしいことだと喜んだ反面、広報として登壇をするメンバーをどうやって支えてあげたらいいんだろう、、、と思いました。

わたし自身が(当たり前ですが)すごく技術に詳しいわけではない、資料作成のサポートができるわけでもない、いいアドバイスができるわけでもない、どうしよう。。。

そして、わたしなりにできることとして思いついたのが、プレゼンのフィードバックをする会を設けるということです。

エンジニアのメンバーであれば、比較的LT文化があったり勉強会でノウハウを発表するということが日常的にあるほうだと思いますが、こういった数百人が集まる大規模なイベントで、かつ、ピッチコンテンストという形で登壇をするというのはいつものLTとは少し違うのではと考えたからです。

メンバーの一歩を支える開発部を召集

早速Slackで開発部のメンバーを召集してみました。

f:id:connehito:20180604181253p:plain

日頃から開発部は「技術の力を使って、メンバーの一歩を支える」ということをしている部署です。

わたしのこういった投稿にも、すぐ快く集まってくれました。

プレゼン練習

f:id:connehito:20180607124803j:plain プレゼン練習を始める前に、下記のポイントをお伝えしました。

  • 今回登壇するイベントはどんなイベントなのか(会場の雰囲気を伝えることの大切さ)

  • 開発部のメンバーにどこのポイントを中心にフィードバックをしてもらいたいのか(わたしが支えきれない技術的観点のサポートをしてほしい)

  • プレゼンに対して感じたことは、率直に何でも素直に伝えてほしい

特に重要なことは、プレゼンのフィードバックは否定やダメ出しではないということです。 今回のプレゼン練習をすることで、よりよくしていくためのプラスの取り組みであるということを伝えました。

実際にプレゼン練習をすると、いろいろなメンバーからのありがたいアドバイスもあり当初の資料とは異なる形で最終的に仕上げることができ、今回伝えたいポイントが伝わりやすい形に修正されたのではと思っています。

プレゼン本番

f:id:connehito:20180604183258j:plain

CTO100名を前に、普段の勉強会とは異なる雰囲気の中、「ママ向けNo.1アプリ『ママリ』の成長を支えるコンテナ技術とAmazon ECS」と題し堂々とプレゼンを行いました!

結果的には、賞を受賞することはできませんでしたが、ピッチ時間4分以内でしっかりと内容をまとめ、今までのフィードバックをもとに改善した形で話しきりました。

プレゼン資料はこちら。 speakerdeck.com

まとめ

今回、プレゼン練習は1回目のフィードバックをもとにどう改善されたのか確認するために本番までに2回開催をしました。2回目の開催はフィードバックをしてくれた開発部のメンバーから言い出してくれたことでした。

開発部のメンバーがしっかりとメンバーの一歩を支えているというのを実感し、また開発部全体の取り組みとして捉えているんだとちょっとした感動を覚えた広報でした。

そして、登壇の際には事前にメンバーを集めてプレゼンの練習をすることの大切さも同時に学び、簡単にできることなので是非他社の方も参考にしていただければ幸いです。

Re:データ民主化の実現とRedash 〜よりデータを活用するための命名規則をどうするか〜

こんにちは!PHPなんかを書いている金城 (@o0h_)です。
先日、弊社某部長に薦められて「かくかくしかじか」を読みました。 これが非常に良かった。 個人的には、2巻の「ふーん」「いいじゃない」「え マジすか」「マジだよ」「ハイ 次の人」のシーンが好きだな〜と思いました。

かくかくしかじか

かくかくしかじか

やはり、信頼できる人のレコメンドや想いというのは・・"一旦素直に受け止めてみる"のが良いものだ、と改めて思った経験でした。

ありがとうございました。

さて、先日のエントリーで弊社におけるRedashの導入と活用(展開)についての取り組みに関して紹介がありました。

tech.connehito.com

相変わらず「どうしたら最高の効率・効用を社内にもたらせるのか」を考える日々ですが、その後また社内での運用について考えた部分があるので紹介です。

クエリ/ダッシュボードの命名規則について。

f:id:o0h:20140315123316j:plain

続きを読む

Connehito Marché #2 ~webフロントエンド市~ での中継について

f:id:dachi023:20180522145017j:plain

こんにちは。2017年11月にAndroidエンジニアとしてJoinした関根(@katsutomu)です。初めてコネヒト開発者ブログに登場させて頂きます。先日コネヒトマルシェの第2回を開催致しました。詳細は安達の投稿した記事をお読み頂ければと思います。 tech.connehito.com

さて、今回は筆者が先日のコネヒトマルシェで取り組んだことについてご紹介させて頂きます。どうぞ宜しくお願い致します。

Connehito Marché #2を盛り上げるために

まずはこちらのツイートをご覧ください。

typoだらけのツイートを貼って何事かと思うかもしれませんが、実はこの日は拙作の音声認識ツイートアプリで認識された内容を元に会場の様子の中継を行なっておりました。このツイートは下記の写真の赤丸部分においてあるAndroid端末からの配信です。

f:id:katsutomu0124:20180528200200j:plain

つまりこちらのツイートは弊社伊藤の会場案内の内容を音声認識し、ツイートされたものとなります。

ヘッド まだちょっと怒られていない方いるちょっとまだ来られていない方がいる
AFTERSCHOOL のパートに入りたいと思うんですけどもそれではLTのパートに入りたいと思うんですけども

とそれぞれ喋っていたと記憶してしております。今回のイベントでは会場案内と弊社の伊藤と安達のLT発表中に前述のアプリを使用し中継を行わせて頂きました。中継内容はそれぞれ下記のツイートにスレッド形式で纏まっていますのでもし興味があれば是非ご一読ください。

安達のLTの中継ツイート

伊藤のLTの中継ツイート

ツイート中継の裏側

きっかけ

もともとこのアプリは弊社の開発部で半期に一度開催している開発合宿というイベントで制作いたしました。この合宿は社内メンバーやママリの誰かの一歩を支えるための開発を行う合宿です。当初の目的は、社内メンバーの下記の課題を軽減出来ないかという思いからでした。

  1. ミーティングでの議事録を取るコストを減らしたい
  2. ユーザーインタビューで質問に夢中になりメモを取り忘れる

ただ先述のツイートを見る通り雑音の多い環境や複数人で会話をするような用途では、まだまだ誤変換が多い状態だったので課題の解決には結び付きませんでした。が、逆に誤変換を楽しめないかと考え、コネヒトマルシェでの中継に利用することを思いつき今回の実験に臨みました。

内部実装について

本アプリはGoogle Cloud Speech APIのAndroid用のサンプルコードに手を加えて制作を致しました。 github.com

今回実装したのはSQLiteでローカルストレージに保存する機能と認識されたテキストをツイッターへ配信する機能のみで音声のテキスト変換部分の機能はGoogleCloudPlatformのサンプルアプリをそのまま流用しています。音声からのテキスト変換はサンプルアプリをビルドする環境があれば、すぐにでも試すことができるので是非触ってみてください。

なおSpeech APIは有料となります。使いすぎにはご注意ください。

ツイート中継を行なってみて

メリット

誤認識がとにかく面白い

とにかく誤認識で、妙な言葉に変換されていて、読んでいるとついつい笑ってしまいます。本当はなんと喋っていたのかが気になってくる効果が生まれているというフィードバックも頂きました。

懇親会でのコミュニケーションが盛り上がる

音声認識のアプリをきっかけに懇親会でお声がけを頂いたり、懇親会での会話の内容をツイートに配信して楽しみました。今回の狙いでもあるコネヒトマルシェを盛り上げることに一役買うことができたかと思います。

デメリット

LTに集中できない

公共の良俗に反する単語がツイートされないようにNGワード機能を実装し対策をしていたのですが、それでも妙な単語がツイートされないか心配でした。そのため、筆者は二人のLTを聴きながら、どんな言葉がツイートされているか監視をしていのですが、その為、LTに集中することが出来ませんでした。次回はしっかりとNGワード対応を行いLTを聞くことに集中できるようにしたいと思います。

最後に

今回は誤変換を楽しむことがメインになりましたが、正確に認識されることも多く音声認識技術の発展には目を見張るものがあると感じました。今後もしっかりとキャッチアップし、正確な中継を行える日を楽しみにしようと思います。

実は、今回ツイート中継を試してみようと決めたのはコネヒトマルシェ開催の三日前でした。時間がない中で私からの申し出を温かく受け入れアドバイスをくれた社内のメンバーと、そして何より当日にツイート配信にお付き合い頂いたご来場の皆様に改めて感謝いたします。次回はLT発表者に事前承諾を頂いた上で、全てのコネヒトマルシェの様子をお伝えできたらいいなと思っています。その際は、LTに集中できるだけのNGワード対応を行いますので、是非宜しくお願い致します!

追伸

今回の主題とは全く関係ないのですが筆者の相棒である富田のI/O Extended 2018 Shibuyaのレポート記事もご一緒にどうぞ!!! tech.connehito.com

I/O Extended 2018 Shibuyaに行ってきました

https://connpass-tokyo.s3.amazonaws.com/thumbs/6a/a4/6aa4ca577ef554902df3b174c589b017.png

こんにちは

Androidエンジニアの富田です。先日、I/O Extended 2018 ShibuyaにBlog枠として参加させていただきました。I/O Extended 2018 ShibuyaとはMaterial Designに特化したイベントで、IO2018で発表された新しいMaterial Designについてのお話が多く大変興味深かったので内容をレポートしたいと思います。間違いや認識の違いがありましたら、ご指摘いただけますと幸いです。

goodpatch.connpass.com

Material update

Google合同会社 鈴木拓生さんによる「リデザインされたMaterial Design」についてです。

そもそもMaterial Designって?

Material DesignとはGoogleが2014年に発表したデザインフレームワーク。元々は社内用のフレームワークだった。なんで社内用にフレームワークを作っていたかというと、サービス間のUIが異なっていて使いにくかったため。GmailとGoogle Calendarでは異なるUIだったので、慣れない人にとっては操作しづらかった。そこでタブレット、モバイル、デスクトップなどに最適化されたフレームワークを過去のデザインシンキング、デザイン資産を使って作り、きちんとOSSとして公開したものがMaterial Design。2014年はGoogle PlayでMaterial Designを利用したアプリが0個だったのに対して、今や150万ものアプリが存在する。一方問題もあり、フレームワークを利用しているためどうしてもアプリの独自のカスタマイズ性が難しい。これを解決するためにできたものがMaterial Theming。

Material Themingって?

E2Eの考え方でブランドに沿った形でデザインをシステマチックに作ることができる機能。ブランドにあったボタン、スライダーなど様々なコンポーネントを利用できる。

Material DesignとMaterial Themingの違いは?

  • 変わっていないところ
    • 物質的なものをメタファーとして使っている
    • 必要な機能をレイヤーごとにヒエラルキーを作って表現する
    • プライマリーカラー、セカンダリーカラー
    • フォントをきちんとヒエラルキーを並べて使う
  • 変わったところ
    • ボタンの形などの表層的なところはカスタマイズしている
    • コンポーネントの組み合わせによってアプリを構築する
    • 英文はRobotoフォント、英文じゃないものはNoto Sansフォントを推奨していたが、より多くのフォントをサポートするようになった
    • アイコンは1パターンから2パターンになった。自分たちのサービスにあったものを選べる

Material Designを使っているとGoogleアプリっぽくなっちゃう問題

元々Googleの社内向けデザインフレームワークなのでGoogleっぽいデザインになってしまうのは当然。今回はGoogleも一つのMaterial Themingユーザとなり、Material ThemingをカスタマイズしたGoogle Material Themingを開発した。その使用例としてGmail、Google News、Google Pay、Google Homeなどでは、Google Material Themingを使用している。今後、他のGoogleアプリについても同様にGoogle Material Themingに移行していく予定。

Google以外にMaterial Themingを使ったアプリは?

Pocket Casts、Lift、ZapposがすでにMaterial Themingを利用している。

Material Themingをカスタマイズする方法

material.ioのガイドラインを参照するとわかるように今回material.ioが大きくアップデートされ、Material Tools、Material Componentsなどが発表された。Material Designは、デザイナーだけではなく、デベロッパーも使うもので、プラットフォームについてはFlutter、Android、iOS、Webで動く。Material Designはあくまでもデザインフレームワークなのでデザイナーはクリエティブな部分に注力してもらいたい。

マルチプラットフォーム

マルチプラットフォームとしてReact版を開発中。Flutter、Android、iOS、Webと対応されているがAndroid、iOSとは微妙に違いがあり、細かいところでプラットフォームにあった設計をしている。チュートリアルが準備されており、学びたい人は各プラットフォームで触ることができる。デベロッパーの場合は全てOSSで見れるようになっているので、機能拡張やバグなどがあればレポートをお願いします。

Material Themingの使い方

  • Android
    • com.google.android.material:material:バージョンをgradleファイルに追加
    • Jetpackの関係でサポートライブラリはandroidxに入りますが、materialのサポートライブラリは別途切り離されて開発され続ける
  • iOS
    • CocoaPodsを使ってインストール
  • Web
    • nodeモジュールとしてnpm installでインストール
  • Flutter
    • 最初から入っているので何もする必要がない

みんなでデザインシステムを構築

みなさんが使っているアプリケーションや導入した過程で使いづらいところに対してフィードバックを送ってほしい。Google Material ThemingのようにGoodpatch Material Themingがあってもよくて、自社で使うときにカスタマイズしたMaterial Themingを使うのもあり。さらにJapan Material Themingといったような、みんなでデザインシステムを作っていくようなやり方を一緒にできると良いです。

UIデザイナーのためのMaterial Designの理解と実践

株式会社グッドパッチ 蔡漢翔さんによる「UIデザインーのためのMaterial Desingの理解と実践」についてです。

Material Designのサイト

Material Designサイトには、ガイドライン、デザインツール、コンポーネントがある。Material Designとはデザインシステムで、デザインシステムとはスタイルガイド、コンポーネントライブラリ、デザインから実装までの一つのデカイシステム。サイト上ではデザイン、デベロッパー、ツールのカテゴリ分けされている。

メタファーを使ってわかりやすくMaterial Designについて考える

僕たちが毎日使っているアプリ、Webサイトを料理としてメタファーをつけると、デザイナーとデベロッパーはシェフで料理を作る人。デザインシステムは、料理を作るためのキッチン、調理器具、レシピ、食材などいろんなものを集めるデカイシステム。では、Material Designは料理教室。Foundation、Component、Toolは料理教室の中の料理の基礎知識を教えることで、調理済みの食材や便利なキッチン道具が準備されている。つまり、料理教室は料理の基礎が分かれば誰でも美味しい料理が作れる。Material DesignはUIの基礎が分かれば誰でも美しいアプリを作ることができるデザインシステム。Material Designは、デザインシステムを作るためのデザインシステム。

普段の業務にMaterial Designをどう導入する

Sketch、Material Theming Editorの2つツールを使って次の3つをやってみる。

  • Color
  • Typography
  • Components

Color

Material Designはベースの色システムがある。メインはプライマリー、セカンダリーがあり、その他にバックグラウンド、サーフェース、エラーの色がある。色システムを作るには、自分のデザインスタイルに合わせてプライマリーカラー、セカンダリーカラーを選択すると、マテリアルシステムは2つの色によってカラーパレットを自動生成される。

Typography

文字について大事な内容として、文字を揃えるときはBaselineで揃えること。Line-heightを4の倍数にする。そうすることで全てのテキストオブジェクトを4の倍数に揃えることができる。英語じゃない言語を使うとき注意することがあり、Line-heightを多めに取る必要がある。Titleより小さい文字の時、日本語フォントは英語フォントよりも小さくする必要があるが、プラグインを使うことによって自動的に調整される。

Components

アトミックデザインとは物質を構成する原子、分子、有機体などのメタファーを使ってUIの構成要素を5段階に分解するデザイン方法論。どのオブジェクトを原子、分子に指定することが難しいが、自分の組織が素晴らしいUIシステムを構築するために効果的にコミュニケーションするのに役立つはずです。つまり、アトミックデザインを5段階に分解できなくても、チームが効率的にやりやすい形にする方がいいかもしれない。

Google IO2018からの学び

Google IO2018の会場Wifiパスワードは「Make good things together」でこの中で一番大切なことは「together」。UIデザイナー、デベロッパーなど実際にデザインから実装するまで関わる人間はたくさんいる。みんなのおかげでユーザに優しいプロダクトをリリースすることができる。

Material Theming対応の前に知っておきたい、エンジニア側の対応コスト

株式会社ノハナ 瀬戸優之さんによる「Material Theming対応の前に知っておきたい、エンジニア側の対応コスト」についてです。

Material Componentsとは

Material ComponentsとはMaterial Themingを簡単に実装するための専用ライブラリ。エンジニアはこれを使うと実装コストが下がり、Android、iOS、Web、Flutter向けに提供されている。iOSはそれほどコストが高くないが、アップデート回数が多いこととGithubのIssue数が1000ある点に不安がある。AndroidはAndroid Studio 3.2、compileSdkVersion AndroidP対応とコストが高くまだ対応できている会社は少ない印象。Flutterは一行importするだけで導入できるが、導入している会社は少ない。

Material Componentsはどれくらい実用的に使えるか

ボタンの角を完全に丸くしたり、真四角、切り落としなどができる。しかしまだAndroidでは一部Componentsは提供されていない。それらをカスタム実装する方法もあるがコストが高い。ロードマップが公開されているので、Material Componentsがどのように対応して行くのかわかるのでチェックしてみてください。

すぐに使えるComponents

Bottom App Bar、Buttons、Chipsは使える。ただAndroidだけ角を丸くできない。

ちょっと待ちなComponents

Backdropは7月対応予定。Extended FAB、Tooltipsもまだで、Color Themeは一部のコンポーネントが8月対応予定。だいたいのコンポーネントが8月対応であるが、Material Desing Componetnsに対応していなくても実装できる。しかしそれ相応にエンジニアの実装コストがかかるので本当に使いたいかどうかは、会社で色々考えてやりましょう。

gallery.io

galleryとZeplinを比較をすると、galleryには次の利点があります。

  • 無料で使える
  • Gmailアカウントと連携している
  • Material Designのコンポーネントのガイドラインがワンクリックで見える
  • スマートフォンアプリがあるのでデザインの確認がしやすい
  • Material Theming Editorと親和性が高い

一方ダメなところは、リリースしたばかりなのでまだ機能が整っていない。画像やアイコンのダウンロードが全部の解像度向けにダウンロードできない。ただとにかくフィードバックを送ってほしいと書いてあるので、フィードバックを送っていくことで我々好みのgalleryになっていくかもしれない。

我々の対応

デザイナーの方はエンジニアの方と話し合って、対応できるタイミング、対応すべきタイミングを調べてもらう。Material Designのアップデートに注目して何がどこまでできるのかをエンジニアの方にチェックしてもらって会社のベストのタイミングでガッと対応するとバリューを出せそう。

Material Designの設計思想を探る

株式会社グッドパッチ 丸怜里さんによる「Material Designの設計思想を探る」についてです。

新しいMaterial Designについて考察

Material Designガイドラインの序章で語られるPrinciplesの章で新たに二つのデザイン原則が加わった。デザイン原則は大きく以下の5つに分かれている。

  • メタファー表現
  • 大胆、行き来、意図的
  • モーションは意味を与える
  • 柔軟な基盤
  • クロスプラットフォーム

特に下の2つの「柔軟な基盤」、「クロスプラットフォーム」。iOSに提供されているMaterial Design Componentsの実装集が存在するが、これこそクロスプラットフォームを強く意識されているということがわかる。

Material Designのガイドラインで大きくプロジェクトが3つ掲げられている

体験の統一、視覚言語としてのデザイン、ビジュアルの柔軟性という3つが掲げられており、特にビジュアルの柔軟性が新しく追加された要素。今までのMaterial Designは厳格さがあったが、Material Themingでは柔軟性というキーワードが意識されている。Material Themingはコードレベルでデザインが体系化されており、構造やインターフェースを維持したままビジュアル部分のカスタマイズができる。

UXの5階層モデルに当てはめる

UXの5階層モデルには、表層、骨格、構造、要件、戦略がある。構造以下インターフェースとしては不変的であり、より表層に近いものはMaterial Themingを使って挿げ替えることができる。

FABについて

FABの振る舞いはコンテキストでもっとも主要なアクション。行動につながるアクションを提供するボタンであり、もっとも主要なアクションのため複数ではなく、特にモバイルのような画面が小さいではスクリーン内に一つを利用したほうが良い。またFABそのものが別のオブジェクトとして展開できる。

FABをiOSと比較

iOSは右上にその画面の主要なアクションが配置される。これがMaterial DesignのFABに当たるのかもしれない。見栄え的なところでiOSのバーボタンはFABと違って見え辛くその存在に気づきにくい課題がある。ユーザビリティーテスト段階で右上に主要ボタンを配置してもなかなか気づかれなかった。そのため、FABの一目見てわかる存在はiOSよりもMaterial Designの方が優れていると言えるかもしれない。

Bottom App Barについて

Bottom App BarをFABと一緒に使い合わせることによって、今まで上にあったものが下に降りて来て指に届きやすく使いやすくなった。

Elevationについて

Material Designは高さの概念が明確に定義されていて、影によって高さのサーフェースの高さを表現している。これはそもそもデバイスには奥行きがあって、紙のメタファーと言われるサーフェースが重なっている。

Backdropについて

手前にレイヤーがあって、奥にもうひとつレイヤーがある。これを分解してみると、背景レイヤーと前景レイヤーがあり主従関係になっている。主のレイヤーに対してメインコンテンツを配置して、従のレイヤーは前景レイヤーに対するオプションや検索だとフィルター設定などの使い方ができる。Backdropにおけるフォーカスの遷移過程は2ステップあって、前景レイヤーがデフォルトであって、次に背景レイヤーを操作する。これを踏まえてみると、BackdropとiOSのセミモーダルビューに似ているように見えるが、レイヤーを分解してみるとレイヤーの役割が逆転している。

モーションについて

Material Designに限らず、意味のあるモーションは体系化されていて、The 12 Principles of UX in Motionこれがモーション理論がよくまとまっている。モーションの価値は以下の通りで、Material Designもモーションについて体系化されて詳しく説明されているので先ほどの記事と併せて読むと理解が深まる。

  • 非文字言語での対話
  • 動きによって意味を与える
  • 意味のない動きをなくす
  • 時間軸に沿った状態を表現する
  • 未来を示唆する

最後に

貴重なお話を聞くことができて楽しかったですし、特にFlutterはアリババが一番使い倒しているというのは非常に興味深かったです。僕はエンジニアなので、Material Themingを適切に導入できるように日々アップデート情報をキャッチアップしてさらにデザイナーさんに共有していこうと思いました。ありがとうございました!

Slackの新機能「Actions」で遊んで見る

こんにちは、 凪のお暇を読んで「なんか・・めっちゃMP持ってかれた・・・」という経験をしたのが先月でした。 続きが楽しみでありつつ、願わくば元気な時に出てほしい・・・

PHPとかやってます金城(@o0h_)です。

さて、昨日は突発サク飲みを経て帰宅後、だらだら〜っとインターネットを見ていたのですが。
Slackから「どやどやどや!」なアップデート情報が飛び込んできまして、今日は早速触ってみたよ!という記事を書きます。

Slack Actionsについて。

https://cdn.mamari.jp/authorized/amana_5b05438c-c9ac-4004-bb19-0019ac120005.jpg

続きを読む