ブラウザ拡張を用いた業務改善手法

買物情報事業部の根岸(@negipo)です。今回はブラウザ拡張を日常業務でどう使っているかについて紹介します。

ブラウザ拡張とは

ブラウザ拡張は、ブラウザによるウェブとのインターフェースをJavaScriptやCSSを用いて自分好みにカスタマイズする機能です。Google Chromeを利用していればChromeウェブストアなどで公開されている拡張をインストールできるでしょう。一方で、開発したブラウザ拡張を自分で使うために、Chromeウェブストアによる公開と言うプロセスを踏むのは面倒です。日常的にウェブのインターフェースを改変する道具としてブラウザ拡張を使うためにはいくつかの手法がありますが、僕はGithubのdefunktさんが作ったdotjsを使っています。詳細は省きますが、今開いているページでalertを出すぐらいの機能であれば10秒で開発作業を終えることができると思います。

また、dotjsで作成したスクリプトを配布して拡張をチームの人などに使ってもらうのはやや敷居が高いため、そういったことをやりたいのであれば素のChrome拡張として実装したり、あるいは全く別種のオートメーションを導入したりするといったことが必要でしょう。

ブラウザ拡張を用いた業務改善手法

変更しづらいアプリケーションの挙動を変更する

さて、日常業務で扱っているアプリケーションに問題があって書き換えたいのであれば、本来はそのアプリケーションを改修をするのが正しい道です。実際にクックパッドで内製されている社内情報共有システムなどは常に改善が進んでいます。一方で世の中にはGitHub Enterpriseや勤怠管理システムなどの容易に改変できないアプリケーションが存在します。そこを好き勝手に便利にできたら便利そうですね。それでは具体的に何をどう変更するのか見てみましょう。

コミュニケーションを自由に改変する

ブラウザ拡張によるインターフェースの改変といえば、一般的にはウェブにある情報を自分のブラウザで表示するときに何らかの改変を入れて便利にすることができるだけに見えますが、実際にはフォームのテキストフィールドの挙動を変更したりするなどして自分からウェブにアウトプットする際にも変更することができます。これを利用してウェブのさらに先にいるチームメンバーとのコミュニケーションを改変することができます。

僕の ~/.js/githubenterprise.cookpad.com.js を今見たら下記のような機能が含まれていました。

• 1) outdated diffを自動的に開く
• 2) console.log, debugger, XXX などの注意すべきdiffが含まれていたらチカチカする
• 3) Pull Requestã‚„Issueの新規作成時に空のフィールドに下記のようなテンプレートを流し込む
• タイトルにレビューの締切として2時間後の時刻を自動挿入
• チームメンバーから2人選んでメンション
• ユーザーストーリーやKPI、簡易チェックリストなど、デスクリプションに必要な要素のテンプレート

(1)のoutdated diffを開く開かないというような設定はまさにパーソナルな好みの問題であり、シンプルにブラウザ拡張の便利さが現れていると思います。

(2)は自分の実装他人の実装問わずやばそうな実装が検出できるので便利です。こういった実装を検出するオートメーションの方法はいろいろあると思いますがレビューのインターフェース上でチカチカしているという点が好みです。

(3)は自分のアウトプットを他人に届ける際に、その内容をわかりやすく伝えるために便利な部分です。特に締切の明示とかはサツバツとすることがあるので賛否両論だと思いますが、僕が所属しているチームでは緊急性がわかりやすくなるので付加しているメンバーが多いです。緊急性が低ければ適当に明日の夕方とかを締め切りにしています。

確信がないインターフェース改修のプロトタイピングに用いる

まったく別の軸の話として、ある日僕はレスポンスタイムの状況が音で聞こえたら便利かもしれないなと思ったのですが、唐突に社内のレスポンスタイムのモニタリングシステムから音がし始めたらきっとモニタリングどころではなくなってしまうでしょう。事前にブラウザ拡張でプロトタイピングすることで、チームに影響を与えることなく確信のない改修がもたらす体験を改善することができます。

今現在クックパッドで使っているモニタリングを行っているウェブアプリからは上記のような音がしていて、何か問題があると高音のサイン波を発してくれるため、サービスの状況がわかりとても便利なのですが、この機能が実際に取り込まれるまでには下記のプロセスを踏みました。

• Web Audio API + dotjsで簡単に実装する
• 長期間使ってこれはいいのではという気持ちになったので社内情報共有システムにスクリプトを公開する
• 思ったより反応がよくて受け入れられそうだったのでモニタリングシステムにPull Requestする
• 取り込まれてみんなが使いはじめる

ほとんどのアプリケーションで共通していることだと思いますが、体験の改善は現実のデータに基づいて現実のユースケース下で行うことが望ましいと思います。ブラウザ拡張を用いて、効果の最大化をリリース前に検証できることには価値があると考えています。

おわりに

世界とのつながりかたを変える簡単な方法として、ブラウザ拡張は便利な道具です。道具を磨いて楽しく暮らしたいですね。