【DMM meetup #25 〜動画配信事業部のシステムカイゼン実録〜】に参加しました

DMM meetup #25 ~動画配信事業部のシステムカイゼン実録~

https://dmm.connpass.com/event/202838/

に参加してきたので、そのときのレポート

事業部紹介からのはじまりの軌跡

動画サービスが、DMM において最初期に作られたサービスである

つまり、レガシーな状態がある。

2017

社長が変わって、プロダクトファーストな文化になった。

ある日、動画事業部で EC をやってくれと言われた。

メンバー全員で、ユーザは何に困っているのかを考えた。

仕組みを作ることで、他事業も高速に事業を成長させられるようにしようとなった。


これまでのKAIZEN紹介

開発プロセスの改善

以前の環境

  • LAMP 環境
  • CVS
  • 本番デプロイは rsync

開発環境が使いづらい

  • クラウド上に環境をつくることで、自由に利用できるようにした
  • 環境構成をコード化して属人化を解消
  • 常に最新に環境を保てるようにした

バージョン管理に難あり

  • git, github の導入
  • ブランチ運用の整理をした
  • レビュー効率も上がった

ロールバックが大変

以前までは

  • 巻き戻した状態で再コミット -> 再度 rsync
  • 対象ファイルが多いと大変

今では

  • commit revert するだけで OK

異常に気付きにくく、調査もしづらい

以前までは

  • 数百台のサーバーがそれぞれにログを吐いている
  • サーバーメトリクスもとっていない

今は

  • ログはクラウド保存
  • メトリクスも取れる
  • 通知を slack に飛ばすようにした

動画ECサービスのリプレイスを目指して()

DMM 動画について

国内トップクラスの作品数を誇る動画配信サービス

現在のシステム構成

LB -> WebServer -> DB

という構成

WebServer は事業部毎にサーバーが分かれている

  • LB からの応答のみするサーバー
  • LB からの応答も受けるし、DB 接続もするサーバー

の種類がある

システムの課題

  • 最初期から運用されているシステムのため、仕様を把握し切れていない状態
  • アーキテクチャが定まっていないため、機能追加に時間がかかる

システムの改善内容

少しずつ修正するのは大変(どこで障害が起こるか分からない)だったので、

リプレイスをしようとなった。

  • API の刷新
  • フロントエンドの刷新
  • DB スキーマ最適化、バージョン更新、クラウド化

API の刷新の進め方

マイクロサービスアーキテクチャを採用


マルチモジュールを利用したプレイヤー共通化作戦

Android アプリ の話

アプリについて

  • 視聴機能だけのアプリ(playstore
  • ストア機能付きのアプリ

この 2 つはソースコードは別々なため、機能追加の際に工数がかかる。

ソースセット共通化アセット

共通の機能については、共通ソースセット内に作る

昔は、app モジュールに全機能があり、密結合していた

今は、マルチモジュール化している

  • 画面・機能毎に分割

新卒一年目のエンジニアもKAIZENしてみた!

動画の分析を、先輩に相談しながら進めていた。

リモートワークでコミュニケーションがとりづらかった。

そこで、動画分析をするツールを自分で作った。

結果、早く仕事を終わらせることができた。

Androidエンジニア デザイン部 #2に行ってきました

Androidエンジニア デザイン部 #2

https://nohana.connpass.com/event/94621/

に行ってきたので、そのときのレポートブログ

LT1つ目:InvisionのAndroidアプリでみる4つのデザイン基本原則

エウレカのFutagawaさん

資料

以下、LTを聴きながらのメモ

今日話す内容

  • Invisionとは
  • 4つのデザイン原則とは

Invisionとは

モックでデザインを簡単に作れるやつ

4つの原則とは

  • Proximity:近接
  • Repetition:反復
  • Alignment:整列
  • Contrast:コントラスト

Proximity:近接」

グループ化した要素は近くに、そうじゃない要素はより遠くに

まとまりある要素同士の距離は、まとまりのない要素同士の距離よりも短くする。

Alignment:整列」

画面内の全ての要素が他の要素と視覚的なつながりをもつようにする。

Repetition:反復」

アプリの全体を通してなにかの特徴を繰り返す。

「Contrast:コントラスト」

同じ要素でないものははっきりと異ならせる。

例えば、タイトルとアップデート時間は全くことなるものなので

文字の濃さを変えたりする。

 

ノンデザイナーズ・デザインブック

https://book.mynavi.jp/ec/products/detail/id=22176

非デザイナーでも読みやすい。

たまにPDFを配ってるときとかもある。



LT2つ目:「ありがたいUI」をもっと大事にしたい。

資料

以下、LTを聴きながらのメモ

 

デザインに対する持論

デザインって広義的な意味でいっぱいあるが

大切にしたいと思っていることがある。

デザインって、かっこいいとか美しいとかクールと思われがちだ。

かっこいいからインストールするとか、そういう訴求力もあるが

かっこいいから使い続けてるとかはあまりない。

使い続ける理由としてかっこいいからというのはあまりない。

※ただし、アイコンは除く

 

ありがたいと思えるアプリ

twitterの画像表示がありがたい。

複数枚あるとスライドできるが、

消したいときは、下から上にスワイプする。

これの嬉しいところが、タイムラインを眺める動作と変わりない動作でできる。

これがもし、画面上のほうに×ボタンとかで閉じる UI だったら、少し手間になる。

CamScannerの画像切り抜き

タップ部分が拡大表示される。細かく調整ができる。

座標の調整が確認しやすい。

マルチウィンドウ対応アプリ

例えばyoutubeをバックグラウンド再生できる。

AbemaTVのCM中にtwitterみるとか、そういうことができる。

 

これらのアプリにある機能がありがたいので

他のアプリに乗り換えられない。

クールとか美しいアプリというのも大切だが、

ありがたいUIも大切。



LT3つ目:Google I/O 2018

Googleの方のLT

自社アプリ、IOSched について。

 

IOSchedは、

Androidアプリを作っている人に、リファレンスとして見てもらえるように作られている。

 

2018年の見所

  • 秘伝のたれのソースコードをフルスクラッチ
  • Kotlin
  • Architecture Component

UIの面でもベストプラクティスをやろうとしている。

マテリアルデザインで出したい。

だが、I/Oがあるまではマテリアルデザインで出せない。というジレンマがあった。

なので、デザインを2つ作った。

 

今年の見所

Lottieというアニメーションのライブラリを使っている。

カウントダウンを実装している。

githubにソースコード公開しているので、DLしてぜひ見て見てね。

 

ナビゲーション

去年まではナビゲーションペインで作っていたのだが

ナビゲーションボトムに切り替えた。

view pager

1つのviewはマテリアルデザインでいうところの1つの要素

なので、viewとviewの間には区切りが欲しい。

いろんなアプリはその区切りを入れてないので、入れることによりくっきり見える。

ボトムアップバー

これもライブラリの中に入っている。

ここはアクションのメニューを並べる。

fabが据えられる位置を決められる。

たとえばGmailみたいなアプリで、詳細画面に行ったときは返信するボタンになるとかで、

返信ボタンは左に出したいとかだったら、アニメーションを使う。

スナックバー

これまではfabを押し上げるような形だったが、

fabの上に出しましょうとしている。

ボトムシート

一時的な状態を出すのにすごくいい。

必須要素をぜひ知っていただきたい。

 

Googleのアプリをだすときにクリアしなければいけないこと

  • タッチフィードバック
  • 色のコントラスト。背景と文字のコントラストが十分かどうか?
    accesibility checkerというアプリで、チェックできる。
  • 色だけで情報を表さない。必ず文字も入れる。色弱の人がわからないので。
  • 前の画面ってなんだっけ?とならないようにアニメーションをつけるようにする。
  • talkbackでの動作


LT4つ目:Kyashはなぜ使いやすいのか

ノハナの方のLT

資料

以下、LTを聞きながらのメモ

 

今回のアンケート(connpassの参加フォームで「UIが好きなアプリは?」という質問があった)でも、

Kyashが一番評価がよかった。

1. シンプル

Navigation Drawerがない。

  • 機能が絞れている。
    我々は、多機能にしがちだが、Kyashは機能が絞られててよい。
  • 階層が浅い
    画面スタックが最大でも3階層
    人間は画面について覚えにくいが、3階層しかないので覚えやすい。
  • 画面内の要素が多くない

これらのこと = アプリで迷子になりにくい。

2. 操作感のあるUI

請求画面と送金画面が大体似ているが、

画面の下の操作が少し違う。

 

画面遷移

下から出てきて、前の画面が消えるようになっている。

横スライドで画面が変わったりもする。

画面の連続性を出すためにいい。

3. こだわり

39円を送ると、thank you というアニメーションが出る。

一見意味ないことのように思える(これでユーザ数が増えるとか思えない)が、こだわりがあってよい。

ギフトコードの画面についても、細かいアニメーション(プレゼントボックスがカタカタ動く)がある。

これも意味ないと思うが、こういったこだわりのアニメーションを実装したりすることで、

ファンが楽しくなって、ファンが増えていく。



以下、懇親会で周りの人と喋ってて知ったこと

  • https://material.io
    マテリアルデザインについて書かれている。
  • なるほどデザイン
    初心者向けのデザインの本。読みやすい
    https://www.amazon.co.jp/dp/B012VJNW6Q/
  • Xamarin
    Android, iOSアプリどちらも一度に作れる
  • Human Interface Guidelines
    iOSアプリを作るときのデザインのガイドライン

「割り勘オンライン」をリリースしました

趣味で作っているAndroidアプリ

「割り勘オンライン」を728日にGoogle Playで公開しました。

https://play.google.com/store/apps/details?id=com.jp.acchan.groupdutch

 

「割り勘オンライン」は

立て替えが何度か発生する関係の人との間で役にたちます。

領収証をとっておく必要がなく、

何をいくら立て替えたのかをスマホで共有することができます。

 

また誰がいくら多く払っているのかを

ボタン1つで計算することができます。

こんなときに使ってほしい

友達と旅行中に立て替えが発生するとき

旅行をしていて、

「今回ガソリン代払っとくよ~」とか

「今回レンタカー代払っとくよ~」と、立て替えをして

旅行が終わってから精算。ということがないでしょうか。

 

そんなときに、「割り勘オンライン」を使えば

誰が何を支払ったのかのメモをアプリで共有することができます。

 

また、立て替えた結果、誰がいくら多く払っているのかを

すぐに計算することができます。

恋人とお財布を分けてて、きっちり精算したいとき

私自身がそうだったのですが、

恋人と例えば

「今日スーパーで買い物してきたよ」とか

「コンビニまとめて払っておくね」とかしているけど

きっちり精算したい人はいませんか?

 

1ヶ月分のレシートを残しておいて

1でレシートを計算して精算、ということは面倒ですが、

「割り勘オンライン」があれば、レシートを取っておく必要も

電卓で計算する必要もありません。

 

まだリリースしたばかりで
至らない点が多いと思いますが、
気になった点や改善点があればレビューに書き込んでいただけると
幸いです。