Quantcast
Channel: クックパッド開発者ブログ
Viewing all articles
Browse latest Browse all 726

管理下にないウェブサイトを適切に改修するために

$
0
0

株式会社トクバイの根岸です。みなさん、SSSランキングの調子はどうでしょうか。僕は今朝家を出たときには766位でした。一睡もしてません。

さて、今回もブラウザ拡張を作ったよという話です。"外部サイト向けバナー・リンク"という、我々の管理下にないウェブサイトに設置するウィジェットなどの管理・改修をどのように行っているのかについて書きました。

外部サイト向けバナー・リンクについて

トクバイが運営しているクックパッド特売情報は、今日のチラシが見られる、お買い物をするひとたちのためのサイトです。閲覧できるチラシ情報自体は、基本的にはスーパーの店員さんによって管理がされています。 では店員さんがなぜチラシをアップロードするのかというと、単純な観点でものを言えば、販促のためです。 それでは、なぜ、販促ができるのかというと、様々な認知・再訪チャネルがクックパッド特売情報には存在し、お買い物をするひとたちがクックパッド特売情報にやってきやすいようになっているからです。 このチャネルはいくつもありますが、その中のひとつが"外部サイト向けバナー・リンク"という機能になります。

技術的には、iframeでcookpad.comからサーブしているコンテンツをウィジェットやバナーとして参照可能なように提供したり、適切な実装がなされているリダイレクタ(特定の店舗にチラシがあったらチラシの1枚目・無かったら店舗ページにリダイレクトする、みたいな)へのリンクを提供したりということをしています。これらをスーパーの店員さんが自社のウェブサイトに貼ることで、お買い物をするひとたちにチラシ情報が知られて、販売が促進するという形ですね。

運用上の課題

管理下にないウェブサイトに提供しているコンテンツを適切に管理・改修するには、求める内容によって様々な手法があると思います。結論を先に書いてしまいますが、我々は人力で頑張って管理するという方法を選択していました。バナーを貼ってみたのですがという連絡を受けて、目で見て、電話をかけて、このようにしてはどうでしょうかと営業さんからスーパーの店員さんにお話するのが適切だと考えています。これは、技術的な利用のされ方に対する判定とは独立して、お買い物をするひとたちにとって設置されたバナー・リンクが合目的かどうかを人間が判断する必要があるからだと僕は考えています。

さて、最近になって子会社化によるブランド変更に伴い、バナー・リンクを全面的に刷新することになりました。しかしあらためて全面的にチェックし直そうとすると、実はこれまで行っていたチェックでは問題があることに気づきました。

端的に言うと、技術的な部分のチェックが非常に複雑で、これまでは不十分だったということになります。

6種類の提供されているバナー・リンクが適切なリソースから提供されているかをチェックするには、その内容を判定するために、目のあたりに非人間的な正規表現が実装されている必要があります。もちろんhtmlの基礎的な知識も必要です。またぱっと見て、公式が提供しているバナーなので大丈夫かと思いきや、じつは少しだけ改変した画像にリンクを貼っているという状況もありました。そのようなもののチェック作業を繰り返していると人間は疲弊します。

そしてもちろん、機械的にチェック可能な部分に人間のリソースを割いてしまうことは、とてももったいないことです。より重要な、お買い物をする人たちのための判定が、上手くできなくなってしまうからです。

この、人力でチェックして案内に至るというプロセスの機械的なチェックの部分を、システムで解決するというのが今回のエントリーのテーマになります。

解決

普通に考えると脳髄眼球と管理下にないウェブサイトの間にはコントローラブルなシステムが入る余地がないように見えますが、もちろん、あります。ブラウザ拡張です。

実を言うとこのチェックには専任の担当者が以前いて、僕は例のごとくdotjsで管理機能を提供していました。機能としては、◯✕の判定を各リンクに対して判定しサイト右上にずらっと並べるという簡易なものです。ところが、dotjs scriptでこのチェック機構を担当者に渡して運用するのは問題がありました。

  • 開発が終了しました
  • 証明書周りでどうしてもインストールが煩雑になるため、エンジニア以外にはチーム内運用が難しいです
  • インストール後の修正の適用が難しいです

結果として営業チームでは担当者の離職に伴いロストテクノロジー化、眼球正規表現の時代に戻ってしまいました。申し訳ありません。

先程も申し上げたブランド変更に伴って全外部サイトの再チェックが走るにあたり、dotjs scriptをChrome拡張に書き換えました。多少ヒアリングして○△✕の3段階に変更し、どのステータスのバナー・リンクがどこにあるのかわかるようにしました。レポジトリ管理して、rakeタスクで公開フローを進められるようにする、という感じでメンテナンス性の向上も図っています。

また、業務にChrome拡張を利用する上で結構重要なtipsとしてChrome拡張は限定公開可能という点があります。覚えておいて下さい。

そんな感じで、現任の主担当者にドキュメントと、動作チェックのためのテストサイトを共有して、チーム内で運営してくださいね、よろしくお願いします。とお渡ししました。

結果

パッと作ったブラウザ拡張によって、結果として、膨大なドメイン知識が必要な状態から、✕って表示されたら直すのを進める、という一発アクショナブルな状態になりました。✕でました、はい管理しておきます、ご連絡しました、直りました!という感じで、ステータスを機械的に形式化したことによってチーム内に共通言語ができ、恊働がうまくいくようになりました。バナーっぽく見えるからメンテ不要に見えて、実はお手製の画像、というようなパターンも非常に簡単に認識出来るようになりました。一つのページのバナー・リンクのステータスが全て右上に出ているので、OKになるとオールグリーン感が出てわりとうれしいと言う声も聞きました。

あとはもちろん、新規の実装などで判定の基準が変わることもありますが、そう言った更新もすぐに反映されるようになりました。リリースしてしばらくは積極的に営業チームから状況を引き出して都度改善を入れていましたが、即時反映されるのでとても楽でした。

Chrome拡張、便利ですね。コンテンツの質を担保するために人手が入ることは、時には必要で、適切なことですが、機械でやるべきことは機械でやりたいです。頑張っている営業チームと、店員さん、サービスを使ってくれているお買い物をするひとたちに感謝しながら、みんなに便利そうなものを開発して、いい感じになっていくのを眺めているのは、とてもたのしいなと毎日思っています。


Viewing all articles
Browse latest Browse all 726

Trending Articles