SlackをTwitterのタイムラインライクに閲覧できるクライアントを作った

予定だったけどちゃんと作れた。やったぜ。
感想っぽい内容なのでQiitaではなくブログにしといた
というわけで簡単に振り返り


この記事はオプトテクノロジーアドベントカレンダー3日目のエントリーです。

2日目は @m4buya さんの AWS re:Invent 2018でGameDayに参加した話です

4日目は弊社CTO@hiraivaさんの「【評価期間だよ全員集合】Opt Technologies の評価制度について」です


何をつくった

Slackの複数チャンネルの投稿を1つのタイムラインとしてTwitterライクに閲覧できるクライアント

なぜつくった

  • 分報が沢山あって、流し見程度に眺めておきたいけど、チャンネルを行き来するのがだるい。Twitterみたいに1画面で見たいという欲求から
  • また、開発合宿というまとまった時間を取れるタイミングがあったので、いい機会だった

いつつくった

先日社内でやった開発合宿(とその準備期間)

だれとつくった

自分とエンジニアもう2人とデザイナー1人

簡単な紹介

自分

  • フロントエンドエンジニア
  • Nodeでサーバーサイドも多少書ける(運用は未経験)
  • 企画の発起人

エンジニアA氏

  • 競プロマン(先日の社内ISUCONで一緒にやった人)
  • 普段はバックエンドScala+フロントエンドReact+Redux+TypeScriptのプロダクトで主にバックエンド中心
  • SlackのAPI把握・自分の構築したフロントの考え方を事前に吸収してくれてフロントの機能をばっちり作ってくれたり、当日の圧倒的稼働に助けられた

エンジニアB氏

  • オブジェクト指向設計に一家言あるマン
  • 普段はバックエンドScala+フロントエンドAngularJS+CoffeeScriptのプロダクトで主にバックエンド中心
  • 仕様を振る舞いからの予測ではなく、はっきりした情報源をもとに構築してくれる安定感に助けられた

デザイナーC氏

  • 行動力がありデザイン力がありコーディングまでこなすマン
  • 普段はデザインから折衝からいろいろやってそう(あまり詳しくない)
  • brewとかGitとかPostCSSとかReactとかガンガン使いこなしてくるタイプで、今回Storybookで構築した環境をもとに全てのデザイン構築・実装に助けられた
  • 命名とかロゴデザインもしてくれた

どのように作った

技術スタックの話

サーバーサイド

Express+passport.js+Redis+socket.io+ @slack/client

SlackのRTM APIから取得出来るメッセージをそのままフロントに流す役割。
@slack/clientをブラウザで動かせない・RTM APIを利用する際に必要なOAuth tokenのscope制御の関係(詳しくは別の記事にて説明予定)で、必要になってしまった 役割としては薄いのでサクッと自分が作っちゃえって作ってみたら思ったより難しくて苦労した。。。

サーバーサイドは @slack/clientの存在からnode一択だった
WebフレームワークはExpressじゃなくてKoaにすればよかったかなあとasync/await書いててunhandledPromiseRejectionを発生させたときに思った

フロントエンド

React(create-react-app2.1)+Redux+TypeScript+UI-Router+redux-observable+redux-aggregate+Storybook+reg-suit

メッセージの受信はsocket.ioを使ってサーバーとのWebSocketで取得
リアクション付与やemoji一覧取得などは slack というまんまなクライアントがあったのでこれで。

メンバーにReact経験有りマンが多めだったのと、最近自分が開発してるプロジェクトがcreate-react-app-typescriptを利用しているので、メンバー構成の関係とcreate-react-app2.1のTypeScript対応どうなのかを見るためにこんな感じの構成に。

要求されるUXの実装が複雑になることが想定されたので、そうなってもいいようにredux-observableを入れて柔軟に実装出来るようにしたものの、そこを充実させるまで実装はできなかったので特に意味がなかった感じになってしまったのは残念。今後に期待(?)

企画の話

POやったことないので手探り。

簡単な流れとしては、

思いつき
API調査
→合宿チーム決め(ここでメンバー募集。概要の簡単なプレゼン)
→自分の考える最強のクライアント像を改めて共有・その前提でのプロダクトバックログを提示
→メンバー全員で簡単な意見出しとバックログの整理、競合調査
→(ココらへんに並列して利用者がどの程度いそうかのヒアリングもした)
→合宿で目指すスコープを決定
→GitHubProjectsを使ってTodo/Doing/Doneの管理とissueのラベルを使ってスコープを明記
→みんなでやるぞー!おーっ!した
→(合宿後に)使ってみた人の感想を聞いたりして今後の方向性の参考に←イマココ!

今回はとにかく「使い物になるプロダクトを生み出す」ことに注力したいと考えていたのでここは割と大事にしたステップだった。
そもそも自分が使いたいと思えるようなサービスだったし、エンジニア以外にもウケるのではないか?という目論見があった(最近エンジニア以外にもSlackが使われ始めていて、中でも分報が割と流行っている)ので、実際に自分たちで使おうと思えて、その上でいろいろな人に使ってもらえるようなものにするにはどうすればいいか?というところはちゃんと考えるようにした

ポイントだと思ったのは、「これはSlackクライアントの再実装なので、本家クライアントでいいじゃん。にならないようにする」点。
コンセプトの「1画面で複数投稿が流れてくるタイムライン」は間違いなく本家にはない体験を提供できるが、これだけでは弱いと思われたので、どこにこのプロダクトの価値を置くか?がチーム内で話し合うときは議論の中心だった(と思う

結果として、どこまでやるか?の検討と実現についてはかなり上手いラインでスコープを引けてちゃんと実現まで漕ぎ着けたのでここは上手くいったと思う
「この機能は価値が高いか?」という観点で当日の稼働中も優先度を決定して自分たちの行動指針にすることが出来たのはGoodだった

「全員で議論」については諸説ありそうだけど、今回は全員がモチベ高くやりたかったのもあり納得感を重視して全員で議論でいいかなと思った。
今後続けていくときに方針をどう決定していくかという点はどうしようかまだ考えてないけど、趣味プロダクトなのでそんなにガチガチにやらなくてもいいかなって感じ。

開発の進め方の話

当初の想定では以下のような分担を想定してた

  • サーバサイドの構築
  • フロントの基盤構築
  • SlackAPIからデータを受け取ってstateを更新する処理
  • コンポーネント作成とコンポーネントが必要とするインターフェースの定義
  • デザイン周りの設計・コーディング
  • 本番環境の構築

レイヤーごとに分担するような切り方。
大体うまく行ったけど、「SlackAPIからデータを受け取ってstateを更新する処理」と「コンポーネント作成とコンポーネントが必要とするインターフェースの定義」の分担は流石に上手くいかなかった。
当たり前だけど、APIから何が取れるかわからないと何が実現できるかわからないので、そこだけ先に決め打ちして進めようとしても何もわからん!になるだけだった
結果として、レイヤーごとではなく機能毎っぽい割り方になった。例えば「タイムライン画面でemojiを出せるようにする」と「スレッド画面で関連するメッセージ一覧を出せるようにする」という感じ。

当日の作業分担は細かい作業も多かったので割とノリでぶつかるぶつからないを話し合ってその場でサクサクあれやるこれやるを決める感じで進められたので、なんというか、マンパワーで解決!完!で振り返ってみての面白みはあんまりない

合宿という特殊な状況なので開発の進め方は普段と違うアプローチになるな、というのが感想。

開発通してみて良かった点としては、

  • フロントの状態管理設計は基本的に自分が方針を決めて秩序が保てるように出来ていたこと、実際にそのおかげで非常にスムーズに実装が出来た部分があったこと
  • Storybook使ってデザインの調整をしやすいように出来ていて、そこベースでデザイン部分の開発を進められたこと
  • フロントアーキテクチャの考え方・実際のコードの書き方などを事前にメンバーに十分に共有していたおかげで当日バッチリ稼働出来たこと

微妙だった点としては、

  • 自分が好きじゃないだからと言う理由で lint-stagedを入れなかったけど、メンバーがみんなしてformatかけないでCIコケるをやらかしていたので、入れておくべきだった
  • StorybookでComponentに流すべきデータの構築が当日は結局追いつかなかったので、結局プロダクトを動かしながらデザインすることになっていたこと
    • 時間的制約のある中なので、これはしょうがない気もする

合宿終わったあとのこと

  • まだユニークユーザー30人弱ぐらいだけど使ってもらえてて嬉しい
  • バグが多くてごめんの気持ち
  • サーバーが不安定(Slack APIのRate limitかかってメッセージ飛んでこなかったりする)でごめんの気持ち
  • 機能が足りてなくてごめんの気持ち
  • 開発全然進められてなくてごめんの気持ち

日中に意見が多く来るんだけど、日中は仕事してるので対応できないというツラミが・・・

やってみての感想

楽しかったです(小並感

実際、企画立ち上げから、デザイナーさんと協業しながらやったり、エンジニア自身も作りたいものを作る、というモチベーションでやって、しかも1stスコープで考えていた機能はほぼ実現できていて、全体的に見てすごく楽しいプロダクト開発になったなという気持ち。
今後機能拡充していきたい気持ちは沢山あるんだけど、果たしてどこまで頑張れることやら