Today Fortkle Learned.

知らないことの方が多いので今更調べています。さらに一歩先に行けたら嬉しいです。

『管理画面チラ見せ♡ナイト #3』に参加しました!

5/24 に開催された「管理画面チラ見せ♡ナイト #3」に参加してきました。 久しぶりの勉強会でメモ取るのが下手過ぎましたが、一応簡単にブログにまとめておきます。。

イベント概要

各企業が独自で開発しているWebサービス管理画面。 お問い合わせ対応やKPIのモニタリングなど大事な要素が詰まっている部分ですが なかなかその部分が共有されません。 そこで各社のどんな管理画面を使っているのかを発表しあうはこびとなりました。

http://connpass.com/event/31779/


株式会社ベストティーチャー / 今 佑介 氏

感想

英語学習系のサービスをやっているベストティーチャーの今さんの発表。今回は「マンツーマン英会話」のサービス提供時に発生する「生徒・先生がレッスン時間に来ない、遅刻する」問題に起因するオペレーションコストを下げる施策の話だった。

「レッスン時間に相手が来ない問題」については画面上に「相手が来ないボタン」を設置したり一定時間経過後に「レッスン振替ボタン」を設置することでメールの問い合わせを減らすことに成功した。次に「先生がちょっと遅刻する事が続いてクレームに繋がる問題」については「先生着席機能」を実装した。これにより先生がちょっと遅れることが減っただけでなく、着席時間やキャンセル率など数字で講師の質を判断できるようになった。

結果、これらの施策によりキャンセルによるオペレーションコストがゼロになり、先生がちょっと遅れるクレームもゼロになったとのこと。

メモ

www.slideshare.net

## Q&A
- Q. ツール等は?
  - A. bootstrap、rails。active admin嫌い。
- Q. どうやって優先順位つけて管理画面を作っていく?
  - A. コストが掛かっている箇所(インパクトの大きい所)から自動化。愚直に。

株式会社アクトキャット/角 幸一郎 氏

感想

コードレビューの自動化を行うGitHub連携サービス「SideCI」を運営している角さんの発表。

アクトキャットではなんと全員がSQLを書ける環境なので管理画面はMUSTではないと前置きしつつ、管理画面を作る場合は常に「SQLで運用できないか」と比較して価値を発揮できる場合のみ実装するとのこと。スタートアップやベンチャーなどエンジニアリソースが貴重なフェーズにおいて、「管理画面は時間を生み出すための投資」という考えは納得出来た。

例として、ユーザーからの問い合わせ対応をそれまでDBに直アクセスして開示可能な情報だけに加工してユーザーに返信していたが、管理画面を作ることで例えば5分かかっていた対応が30秒以下に短縮された。また、クーポン発行もDBにレコードをINSERTするだけでできるが、管理画面に発行画面を作ることで誰でも発行できるだけでなく、入力値に制限をかけられるようになったとのこと。

一貫して管理画面とは「自動化、省力化、ミスの防止などリソースを生み出すための投資」というスタンスだったのが好印象だった。2回同じSQLを書いたら管理画面化を検討するとのこと。

メモ

## Q&A
- Q. ツール等は?
  - A. bootstrap、rails。active admin嫌い。

Crevo/ 緒方 広道 氏

感想

動画のクラウドソーシングとプロジェクト支援サービスを行っているCrevoの緒方さんの発表。管理画面でも全文検索をしたいが、様々な課題にぶつかった中でAmazon Elasticsearch Serviceを採用した話だった。

全文検索を実現したいとなったときに「複数DBにまたがる、SQLだとつらい、早く実装してリリースしたい、運用/監視が大変、検索用DBの構築が大変、Railsへの組み込みが大変」といった様々な課題があった。その中で構築が楽で簡単に試せるフルマネージドなサービスである「Amazon Elasticsearch Service」を採用して全文検索を実現した。Railsへの組み込みはElasticsearch::Modelというgemで対応、監視はCloudwatchのみでやっているとのこと。通知はslack(Cloud Watch→Amazon SNS→Lambda→slack)。

「管理画面だからこそ新しい技術に挑戦できる」というのは僕の働いている会社でも同じで共感できた。


株式会社エウレカ / 鉄本 環氏

感想

オンラインデーティングサービス「pairs」を担当している鉄本さんの発表。いくつか例を挙げて管理画面を紹介していた。

例えばユーザー情報の画面は、主にカスタマーサポートがユーザー管理を行う目的で使用している。ユーザー固有のバグを確認するために「pairsログイン」という "そのユーザーで実際にログインしてみる” 擬似ログイン機能があるが、擬似ログインしたことで実際のユーザーに影響が出ないように初回ログインボーナスやあしあと機能などは動作しないような仕様にしているとのこと。
また、アカウントに依る徹底した権限管理を行っており、先のユーザー画面にアクセスできるのはカスタマーサポートを行う人でも特に必要な人のみで鉄本さん自身もログイン権限がないらしい。ここまで徹底しているのは凄い。

次に、データ分析を目的に使用されているのダッシュボードの紹介。re:dashというサービスを採用して様々なデータを分析し見える化するようにした。しかし、誰でもダッシュボードを作れるようにしたところカオス化してしまったため、重要な指標を見逃さないように分析チームが公式ダッシュボードを作成したこと。そんなre:dashのダッシュボードもビジュアライズの豊富さ、集計コストの削減、データの定義ブレの防止などを理由に現在tableauへの移行を検討中とのこと。

おまけで見せてもらったCouplesの管理画面含めて、デザイン・権限管理・機能面などわりと管理画面が充実・コストがかかっていてサービスの規模を感じた。

メモ

## Q&A
- Q. メッセージ等の審査は?
  - A. 外部のベンダーさんに依頼している。csvで吐き出し、結果をcsvで取り込んで相互にやり取りしている。社内でチェックすることはない。
- Q. 管理画面のログインユーザーの認証はどうやっている?
  - A. IDとPWの発行でやってる。IP制限で社内のみアクセス可。

株式会社トレタ / 上ノ郷谷 太一 氏

感想

飲食店向けの予約・顧客台帳サービスを展開するトレタの上ノ郷谷さんの発表。

管理画面、といいつつトレタのサービス紹介?だった気がしないでもないが、発表でのデモは圧巻でユースケースをとことん突き詰めて仕様に落とすとここまで「使いやすい」画面が作れるのかと感心した。

管理画面といえば少ない工数の中でとりあえず「作る」というところに目が行きがちなので単純なCRUDの画面でも実際の利用者と細い仕様を詰めながら実装すれば「使われない管理画面」を量産することは避けられるなと思った。飲食店らしくなるべくキーボードを使わずタップで操作できるようにしたり、利用者が次に何をしたらよいか迷わないような画面設計にしたり、と参考になる部分は多くあった。

youtubeにそれっぽい動画があったので貼っておく。

www.youtube.com


Wantedly / 天野 葵 氏

感想

スタートアップではおなじみのWantedlyの天野さんの発表。企業側が使う「候補者管理機能」のリニューアルの話だった。

Wantedlyにおける候補者管理は応募してきたユーザーを候補者として扱い、「未選考」「連絡済」「採用済」などステータスを変更して管理していく設計になっている。
既存の候補者管理機能の問題点として2つ、「長く使えば使うほど使いづらくなること」と「候補者が多くなればなるほど使いづらくなること」をあげていた。今回のリニューアルはそれらを解決することを目的の1つとしていて、まずは既存の候補者管理機能のヘビーユーザーであろうWantedly社内の採用チームに話にいったところなんと一部 Githubを使っていた!!!/(^o^)\

ということで(なのかは明言していないので分からないがおそらく)新しい候補者管理機能は、Githubに大きくインスピレーションを受けてつつ、候補者1人につき1チケットが立つようになっていてチケット上でコメントのやり取りをできるようにした(従来のメモ機能の上位互換)。また、これまで6〜7種類ぐらいあったステータスも3種類まで減らし、その分ラベルを付けられるようにして企業ごとに違う採用ステータスに対応できるようにした。要望の多かったステータスの一括編集もできるようにしたとのこと。

こちらもトレタさんと同様に純粋な社内用管理画面ではなかったが、課題点としてあげられていた「期間やデータ量が増えると使いづらくなる」という問題は重要な視点だと思っていて、これを開発段階から意識して管理画面を作れると「あれ?開発環境ではいいと思ったんだけどな?」というズレがなくなって良いなと思った。


現場からは以上です。