一休.com Developers Blog

一休のエンジニア、デザイナー、ディレクターが情報を発信していきます

一休.comホテルリストの表示速度を従来比2倍にしました

宿泊事業本部フロントエンドエンジニアの宇都宮です。

2018年度下期は、一休.comホテルリストページ スマホ版の速度改善に取り組んできました。その結果、ページのデザインはそのまま、機能面はリッチにしつつ、プロジェクト開始前の約2倍のスピードでページが表示されるようになりました。

本記事では、高速化のためにどのような施策を行ったのか紹介します。

なお、Webサイトの高速化手法については、ホテル詳細ページ高速化プロジェクトを実施した際にも記事を書いています。これらの記事で紹介している手法(たとえば、Imgixによる画像最適化等)については、記述を省略しています。あわせてご覧ください。

また、今回高速化の対象としたホテルリストページには以下のURLでアクセスできます(スマホで開くか、PCの場合はUAをスマホに偽装する必要があります)

https://www.ikyu.com/sd/tokyo/140000/

f:id:ryo-utsunomiya:20190227130107p:plain:w320
ホテルリストページ

プロジェクト開始前の状況

下記画像は、プロジェクト開始前の、PageSpeed Insightsの計測結果です。

f:id:ryo-utsunomiya:20190227094518p:plain:w480
PageSpeed Insights: プロジェクト開始前

パフォーマンス監視SaaSのCalibreでは、計測結果は以下のようになっていました。

f:id:ryo-utsunomiya:20190227094944p:plain:w480
Calibre: プロジェクト開始前

遅い4G回線相当の設定(下り1.4Mbps)とはいえ、Time to Interactiveに10秒以上かかっているのは遅いです。主要な指標(First Meaningful Paint、Speed Index、Time to Interactive)をそれぞれ半分にして、FMP 2秒、Speed Index 2.5秒、Time To Interactive 5.5秒くらいになれば、低速回線でもある程度快適に使えるサイトといえるでしょう。

改善結果

PageSpeed Insightsのスコアは従来の2倍以上になりました。

f:id:ryo-utsunomiya:20190227154455p:plain:w480
PageSpeed Insights: 改善後

Calibreでも指標が軒並み改善しています。TTIがFMPやSpeed Indexよりも早くなっているのは、APIレスポンス待ちでCPUがIdleになっているタイミングがあるからだと思われます。FMPまでの時間は半減しています。Speed Indexも改善していますが、もう一声ほしいところ。

f:id:ryo-utsunomiya:20190227155059p:plain:w480
Calibre: 改善後

計測が難しいため直接の指標にはしていませんでしたが、トップ(https://www.ikyu.com/sd/) => ホテルリストの遷移スピードは、体感的にはかなり速くなったように感じられます。これはFirst Contentful Paintの大幅改善(3.69s => 0.65s)が効いていそうです。


(2019-03-04 追記)本記事の「改善後」よりさらに高速化しました。2019-03-04現在のパフォーマンスは下記記事を参照してください:

user-first.ikyu.co.jp

やったこと

パフォーマンス目標値の設定

高速化を実施するには、まず目標となる値を設定する必要があります。目標設定に際しては、(1) 自分たちのサイトの要件から実現可能な数値であること (2) 競合と比較して遅くないこと の2点が重要だと考えています。また、可能であれば、競合よりも速くして、速度で差別化できると、なお良いでしょう。

今回のプロジェクトでは、Expediaのスマホ向けリストページをベンチマークにして、高速化に取り組みました。

このページは高度な最適化を施されており、PageSpeed Insightsのスコアは63点と、競合の中でも群を抜いて速いページです。

f:id:ryo-utsunomiya:20190227095620p:plain:w480
PageSpeed Insights: Expedia

そこで、今回のプロジェクトでは、以下の2段階のゴールを設けて高速化に取り組みました。

  1. PageSpeed Insights 50点以上、主要指標(FMP/Speed Index/TTI)で20%以上の改善
  2. PageSpeed Insights 65点以上、TTI 5秒以内

1は最低限達成したいゴール、2はややチャレンジングなゴールです。

施策1: ikyu-analytics-clientの最適化

一休では、アクセス解析ツールを内製しています。これはikyu-analyticsと呼ばれ、一休.com等では、ikyu-analyticsのクライアントライブラリを読み込んで使用しています。

パフォーマンスの観点で、ikyu-analytics-clientには大きな問題がありました。アクセスログの記録を 同期XHRで 行っていたのです。

私自身、Firefox等で、メインスレッド同期XHRのDeprecation Warningが出ていることは以前から認識していました。が、これがどの程度悪影響を及ぼしているのかは、分かっていませんでした。

しかし、昨年12月、WebPageTestのBlock機能を使ってikyu-analytics-clientの読み込みを行わないようにしたところ、ページの読み込み完了までの時間が約1秒短くなることに気づきました。

ikyu-analytics-clientのJSはサイズも小さく、やってることもアクセスログの送信程度です。したがって、ikyu-analytics-clientがもたらしている遅延のほとんどは、同期XHRのレスポンス待ち時間だと推測しました。

そこで、データサイエンス部と連携して、ikyu-analytics-clientのアクセスログ送信の非同期化に取り組みました。

具体的には、 navigator.sendBeacon()が使える場合はこれを使い、使えない場合は非同期XHRを行うようにしました。

navigator.sendBeacon() は比較的新しいAPIで、iOSでは11.1以上でないと使えません。非同期なデータ送信を確実に行えるという、非同期XHRにはない特長を持っています。一方、非同期XHRは送信中に画面を遷移したりページを閉じたりすると送信がキャンセルされます。これについては、データサイエンス部と協議し、非同期XHRのキャンセルによるログの送信失敗は許容する、という合意を取りました。

ikyu-analytics-clientの非同期化後、PageSpeed Insightsのスコアは10点改善しました。

f:id:ryo-utsunomiya:20190227103703p:plain:w480
PageSpeed Insights: ikyu-analytics-client非同期化後

ikyu-analytics-clientは、一休.comの全ページのみならず、一休レストランなどでも使用されているため、一休が運営しているサービス全体で、読み込み完了が1秒速くなりました。

逆にいうと、ikyu-analytics-clientが同期XHRを使っていたことで、一休のサービス全体が1秒遅くなっていたということです。 ブラウザのWarningにはちゃんと耳を傾けるべし という教訓を得られました。

施策2: コードの大幅な書き直し

ホテルリストページは、従来、ASP.NET WebForms + jQueryというスタックで実装されていました。これらを、ホテルページと同様、ASP.NET MVC(+Web API) + Vue.jsというスタックに置き換えました。

また、機能面では、検索実行時に毎回画面遷移していたのを改め、ページ内で再検索が行われるようにしました。

速いJavaScript/Vue.jsアプリケーションを書くための方法については、下記記事に書いた内容を踏襲しているので、省略します。

一休.comスマホサイトのパフォーマンス改善(JavaScript編) - 一休.com Developers Blog

これに加えて、リストページの実装において特徴的なこととして、今回、Vuexは使いませんでした。

Vuexを使わなかった理由は、リストページはデータの流れがシンプル(検索APIからレスポンスを受け取り、描画するだけ)かつ、コンポーネントが素直なピラミッド構造になっていて、props down/events upで必要なデータの受け渡しを全て表現できたためです。また、Vuex Storeのコードは肥大化しがちなため、パフォーマンスの観点からの懸念もありました。

ただし、Vuexを完全に捨てたわけではなく、今後の改修で必要になれば、Vuexを導入する可能性はあります。

この書き直しによって、パフォーマンスは大きく改善しました。

f:id:ryo-utsunomiya:20190227105859p:plain:w480
PageSpeed Insights: リライト後

この時点で、ストレッチゴールの「PageSpeed Insights 65点以上」を達成できました 💪

施策3: 初回検索のAjax化

当初の目標を超えることができましたが、もう一押し改善できそうなポイントが残っていました。

施策2までの段階では、ページ初回表示時の検索処理は、サーバサイドで行っていました。SEOのためのtitleタグ、metaタグや、SNS等で共有する際に必要な情報(twitter card、facebook OGP等)を書くには検索結果を知っている必要があります。また、Botの中にはJavaScriptを実行しないものもあります。したがって、SEO関係のタグは、サーバサイドで書いて、初回レスポンスのHTMLに含める必要がありました。

一方、パフォーマンス改善の実験として、画面の初期表示時にサーバサイドで検索を行わずAjaxで行うようにしたところ、FCP/FMP/Time to Interactiveのそれぞれについて0.5秒程度の改善が見込めることがわかりました。

SEO関係のタグもJavaScriptで書くようにできれば、初回表示時に検索をサーバサイドで行う必要がなくなり、画面の初期表示はさらに速くできます。この問題の解決のためには、2つのアプローチが考えられました。1つはSSR、もう1つはDynamic Renderingです。

SSR(Nuxt.js)を採用しなかった理由

SSRを行って、JSの初回レンダリングの終わったHTMLを返すようにすれば、SEOの問題は解決します。

しかし、結論からいうと、SSR(Nuxt.js)は採用しませんでした。一休.comのアプリケーションの特性を考えると、SSRの導入によって遅くなる可能性が高いと考えたためです。

下記画像は先日Googleが公開したRendering on the Webというドキュメントから抜粋したものです。

f:id:ryo-utsunomiya:20190227112031p:plain
Rendering on the Web

Nuxt.jsを使ったSSRは、この表の「SSR with (Re)hydration」に該当します。一方、現行の実装は「Full CSR」です。この2つを見比べると、「SSR with (Re)hydration」の方がConsが増えているのがわかります。

SSR with (Re)hydrationは、サーバサイドでレンダリングを行い、フロントエンドでも、Full CSRと同等のリソースを読み込んで、状態の引き継ぎ(Rehydration)を行います。単純に考えると、Rehydrationの分、Full CSRと比べて計算量が増えます。

実際には、SSRを入れると遅くなるという単純な話ではなく、SSRでしかできない最適化を入れることで、Full CSRより速くできます。

しかし、「SSR後のHTMLをCDNでキャッシュする」という強力な最適化手法は、一休.comのアプリケーション要件では、あまり効果的ではありません。宿泊日程等の検索条件に応じて細かく画面を出し分ける必要があるため、同じHTMLを返却できるリクエストの数が多くないためです。

アプリケーション要件の見直しを行い、キャッシュフレンドリーな設計にすればSSRを導入する余地があります。しかし、今回のプロジェクトのスコープにはUIの刷新は含まれていません。現状の画面仕様では、Full CSRの方がパフォーマンスが出ると判断しました。

Dynamic Renderingの導入

Dynamic Renderingとは、bot向けに静的HTMLを配信する方法です。これによって、JS描画済みの静的HTMLをGooglebot等が取得するようになるので、metaタグ等をJSで書いても問題なくなります。

詳細は下記ドキュメントを参照してください。

ダイナミック レンダリングの使用方法  |  検索  |  Google Developers

一休では、Rendertronを使ってDynamic Renderingを行っています。 Rendertronの導入にあたっては色々苦労もあったようですが、これについては akasakas さんが書いてくれると思うので、ここでは詳しく触れません。

Dynamic Renderingによって、SEO関係のタグをJSで書く準備が整ったため、初回検索のAjax化に至りました。

この結果、冒頭の「改善結果」で紹介しているパフォーマンスが実現できました。

今後の展望

フロントエンドに関しては、パフォーマンス上のボトルネックのほとんどを解消した状態にもっていきました。一方、サーバサイドの検索APIについては、レスポンス速度がまちまちで、遅いときは1.5秒ほどかかることがあります。さらなる高速化のためには、検索APIの速度改善が必要そうです。

また、スムーズに宿泊施設を探すには、検索導線(トップ・リスト・ホテル)の全体的な回遊性が重要です。検索導線のSPA化等によって、ページ間のスムーズな移動を実現するような施策も検討しています。

We are hiring

hrmos.co

クラウド移行とSREについて講演をしました。

当社のクラウド移行とSREについて講演をしました

2019/1/30にitsearch+様で当社のクラウド移行とSREについて講演をしました。

news.mynavi.jp

発表資料はこちらです。ぜひ、ご覧ください。

speakerdeck.com

昨年11月に書いた以下の記事の内容に具体的な事例を交えつつ、当社のSREの取り組み方について発表をしました。

user-first.ikyu.co.jp

発表にも書きました通り、今後もコンテナ技術等、新しい技術を活用しつつ、ビジネスの成長を支える技術基盤開発、SREを実践していきたいと思います。We are hiring!!

hrmos.co

hrmos.co

おまけ

最近勉強になったSRE関連のリソース


この記事の筆者について

  • システム本部CTO室所属の 徳武 です。
  • サービスの技術基盤の開発運用、開発支援、SREを行なっています。

Bonfire Frontend #3で「一休.comのフロントエンドパフォーマンス改善」の話をしました

宿泊事業本部でフロントエンド開発をしている宇都宮です。

昨日(2019/1/24)、LODGEで開催された、Bonfire Frontend #3に登壇させていただきました。

Bonfire Frontend #3のテーマは「パフォーマンス改善」で、各社がパフォーマンス改善ネタを持ち寄って発表する会でした。

私は「一休.comのフロントエンドパフォーマンス改善」というタイトルで、フロントエンド全般のパフォーマンス改善についてお話ししました。

slides.com

フロントエンドのパフォーマンス改善においては、デファクトスタンダードな計測ツールであるLighthouseの使い方に習熟することが重要だと思っています。

また、2019年1月現在、Lighthouseを利用した計測環境として最もアクセスしやすいのがPageSpeed Insightsです。ただ、PageSpeed Insightsの計測には前提条件や若干の癖があるため、その辺の話も交えて、PageSpeed Insightsの話を厚めにしました。

その後は一休で行っているパフォーマンス改善の大まかな戦略や、今後のフロントエンドパフォーマンス改善に向けたアーキテクチャの構想などをお話ししました。

具体的なパフォーマンス改善の施策については、先月のIkyu Frontend Meetupで発表した下記スライドもあわせてご覧ください。

slides.com

speakerdeck.com

一休では、使いやすい予約サービスの提供のため、引き続きパフォーマンス改善活動を進めていきたいと思っています。

hrmos.co

一休.comホテルページのスマホ版からjQuery依存を取り除くためにやったこと

f:id:ryo-utsunomiya:20190117125131p:plain

一休.comでWebフロントエンドを開発している宇都宮です。

先日、一休.comホテルページのスマホ版から、jQueryを取り除きました。jQueryを取り除いた経緯、やったこと、結果について書きます。

ちなみに、ホテルページには以下のURLでアクセスできます(スマホで開くか、PCの場合はUAをスマホに偽装する必要があります)

https://www.ikyu.com/sd/00001290/

なぜjQueryを取り除いたのか?

JavaScriptサイズの削減のためです。一休.comホテルページは、以前は合計で約300KBのjsファイルを読み込んでいました(300KBはgzip後の転送量なので、実ファイルはもっと大きいです)。

よくいわれる「jsは170KB以内ルール」は、回線速度のベースラインが400Kbpsという前提1です。一休.comの平均的ユーザはもっと良質の回線2を使っているので、170KBまで切り詰めようと思っているわけではありません。

しかし、jQueryで実装されている処理は、最近のDOM APIを使えば代替可能です。ブラウザAPIの統一が進みつつある現在、jQueryを使う理由はないのでは? と考え、jQuery依存を取り除くプロジェクトを進めました。

どうやったのか

jQueryを使用している箇所は多かったため、細かくプルリクエストを切って、都度masterにマージしていく方針で進めました。

結果的に、修正プルリクは12個、総変更行数は±2500行程度になりました。

また、メインプロジェクトと並行して進めていたため、去年の8月頃から着手して、完了は先週でした。約4ヶ月かかった計算になります。

何をやったのか

ここからは、やったことを細かく書いていきます。

jQuery.ajax() => fetch に置き換え

jQuery.ajax() を、ブラウザの標準APIである fetch に置き換えました。fetchが利用可能なのはiOS 10.3以上なので、polyfillも導入しました。

github.com

※ライブラリをバンドルすると、全てのユーザにpolyfillを配信することになります。パフォーマンス観点からは、polyfill.iofetchが使えない場合のみpolyfillを使うのも良いと思います。

基本的には、Promiseを使っているところはそのまま置き換え、コールバックを使っているところはPromiseベースに書き換えました。1カ所だけ同期のajaxを使っているところがあったので、そこは非同期に書き直しました。

$.ajax('https://www.ikyu.com/api/...', {}).then(data => data);

const data = await fetch('https://www.ikyu.com/api/...').then(res => res.json());

fetchのpolyfillを採用した理由

比較したのはXMLHttpRequest(XHR)とaxiosですが、

XHRと比べると、

  • Pros
    • fetchはPromsieベースで、高レベルなAPIになっている
  • Cons
    • iOS 10.2以下ではpolyfillの読み込みが必要

axiosと比べると、

  • Pros
    • fetchはWebの標準APIであるのに対して、axiosはjQuery.ajax風の独自API
    • polyfillなので将来的にライブラリの読み込みをなくせる
    • whatwg-fetchはaxiosよりもサイズが小さい
    • axiosが提供しているような高度な機能(Universal JS、リクエストのキャンセル、transform/intercept等)は今のところ必要ない
  • Cons
    • 機能が少ない(たとえば、タイムアウト機能がない)

という感じかなと思います。

fetchのConsについては、

  • XHRを生で使うのは可読性の観点からはありえない
  • fetchに足りない機能は必要に応じて補うことができる

という理由から実質的に問題ないと考えて、fetchのpolyfillを採用しました。

DOM操作を標準APIに置き換え

jQueryで行っていたDOM操作を、全てブラウザの標準APIに置き換えます。jQuery => DOM APIの置き換えに関する包括的なドキュメントは以下がおすすめです。

github.com

ここでは、今回のプロジェクトで実際に使った置き換えのみ紹介します。

要素の取得

jQueryの $() は単体の取得とリストの取得を透過的に扱えるようになっていますが、DOM APIでは区別が必要です。

$(selector);

// 1個だけ取る
document.querySelector(selector);
// 要素のリストを取る
document.querySelectorAll(selector);
// 要素のリストを取って、一括操作する(NodeList.forEachはiOS 9では使えないので配列化している)
[...document.querySelectorAll(selector)].forEach(/**/);

注意が必要なのは存在しない要素へのクエリです。jQueryは、存在しない要素に対するクエリを発行して、返却されたオブジェクトにメソッドを発行しても、エラーにはなりません。存在したりしなかったりする要素に対する処理をjQueryで行っている場合、DOM APIへの置き換えは一手間必要です。

// エラーにならない
$('こんな要素はない').show();

// document.querySelector()の結果はnullなので、styleへのアクセスでエラー発生
document.querySelector('こんな要素はない').style.display = 'block';

show/hide

$el.show();
$el.hide();
$el.toggle();

el.style.display = '';
el.style.display = 'none';
if (el.ownerDocument.defaultView.getComputedStyle(el, null).display === 'none') {
  el.style.display = '';
} else {
  el.style.display = 'none';
}

実際に使う際は、関数化したほうがよいでしょう。

addClass/removeClass

class操作はclassListで置き換え可能です。IE 10以上対応なので安心。

$el.addClass('class');
$el.removeClass('class');
$el.hasClass('class');

el.classList.add('class');
el.classList.remove('class');
el.classList.contains('class');

html/text

$el.html(html);
$el.text(text);

el.innerHTML = html;
el.textContent = text;

アニメーション

jQueryのアニメーションAPIは手軽に使えて高機能なので、完全な置き換えは難しいです。 ユースケースに合わせて、CSSアニメーションに置き換えていくのがよいでしょう。

これについても https://github.com/nefe/You-Dont-Need-jQuery が参考になります。

You Don't Need jQueryには載っていない、アニメーションを伴うスクロールは以下のように実装しました。

/**
 * 指定した要素までスクロールする
 * @param {string} selector スクロール対象のHTML要素のCSSセレクタ
 * @param {number} step スクロール幅(px)
 * @param {number} timeout スクロールを行う間隔(ms)
 */
export function scrollToElement(
  selector,
  { step = 100, timeout = 16 } = {},
) {
  const target = document.querySelector(selector);
  if (!target) return;

  // 目的地のY座標
  const destY = target.offsetTop;

  // 目的地が現在位置より上にある場合は上(負のstep)、下にある場合は下(正のstep)にスクロール
  const stepWithDirection = destY < window.scrollY ? -step : step;

  const scrollByStep = () => {
    if (Math.abs(window.scrollY - destY) > step) {
      // step よりも距離が開いているときはscrollByで近づく
      window.scrollBy(0, stepWithDirection);
      setTimeout(scrollByStep, timeout);
    } else {
      // step 以下の距離まで近づいたらscrollToでピッタリ移動する
      window.scrollTo(0, destY);
    }
  };

  setTimeout(scrollByStep, timeout);
}

$.ready()

$.readyはブラウザの対応状況にあわせて load と DOMContentLoaded を使い分けてくれます。が、すでにDOMContentLoaded未対応ブラウザ(IE 8以前)は滅びているので、DOMContentLoaded のみでOKでしょう。

$.ready(function() {
  // 処理
});
$(function() {
  // 処理
});

document.addEventListener('DOMContentLoaded', () => {
  // 処理
})

イベントフィルタリング

jQueryだと、「doument配下のclickイベントを全てキャッチし、そのクリック対象、およびクリック対象の親要素が特定の属性をもつ場合にだけハンドラを実行する」という処理が、以下のように簡単に書けます。

$(document).on('click', '[data-xxx]', eventHandler);

これをDOMの標準APIで実装すると、少々面倒です。

function findParentByAttribute(target, attributeName) {
  let el = target;
  while (el.parentNode) {
    if (el.getAttribute(attributeName)) {
      return el;
    }
    el = el.parentNode;
  }
  return null;
}

document.addEventListener('click', event => {
  if (!findParentByAttribute(event.target, 'data-xxx')) return;
  // handle event
});

jQueryの使用を防ぐ目印

jQueryを取り除く作業をしたファイルには、先頭に以下の記述を追加して、jQueryを使ってはダメなことがわかるようにしました。

// このファイルではjQuery使用禁止!
const $ = undefined;

このコードは、ローカル変数の $ を定義して、undefinedで初期化します。これによって、グローバルな $ はローカルの $ でシャドウされます(グローバルな $ は上書きされませんが、シンボルの探索ではローカルの $ が優先されます)。さらに、$ の値はundefined なので、 $() などの呼び出しを行うとエラーが発生します。constなので再代入もできません。

これでも、 window.$window.jQuery 、jqueryのimportなど、jQueryにアクセスする手段は残されています。が、一休.com開発チームの規模やスキルを考えると、この方法で十分と判断しました。

なお、上記コードはES Modules(またはwebpack)環境での動作を前提にしています。ES Modulesはファイル毎のスコープを切ってくれますが、ES Modulesを使っていない場合も即時関数でスコープを切ることで同じことができます。

(function(){ // ファイルの先頭
  // このファイルではjQuery使用禁止!
  const $ = undefined;
...
})(); // ファイルの末尾

jQuery削除の効果

f:id:ryo-utsunomiya:20190117155101p:plain
jQuery削除前

f:id:ryo-utsunomiya:20190117154713p:plain
jQuery削除後

↑は、jQuery削除前後のPageSpeed Insightsのスコアです。どちらも71点。Time To Interactive/First CPU Idleは改善していますが、SpeedIndexは悪化しています。この程度の変動は何も変更しなくても起きるので、スコアが変わるほどのインパクトはなかったということですね。

パフォーマンス改善の観点からは、jQuery削除は、コスパが悪かったという結論になるかと思います。たぶん、同じ時間を別のタスクに使えば、もっと改善できたはず…。

なお、今回この結論に達したのは、既存コードのjQueryへの依存度が高かったからという理由もあります。サクッと取り除けるような状態なら、もっとコスパは良かったと思います。また、一休.comのホテルページスマホ版においては効果がなかったということであり、条件が異なれば、別の結果が得られると思います。

まとめ

パフォーマンスの観点からは、ロードするJSの量を減らすことは重要です。一方で、JSライブラリ30KB程度の削除だと、誤差の範囲程度の改善効果しか得られない、ということもわかりました。塵も積もれば山となるので、無駄ではないと思いますが、もっとコスパの良い改善施策を実施していきたいところです。

告知

Bonfire Frontend #3が、1/24に開催されます。テーマは「パフォーマンス改善」です。今回、Yahooグループのよしみで(?)お声がけいただき、登壇する機会をいただきました。今回の記事のような、一休.comで進めているパフォーマンス改善のお話しをしようと思っているので、是非ご参加ください!(すでに満席ですが、1/18に抽選なので、まだ間に合います)

yj-meetup.connpass.com


  1. http://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/

  2. 一休.comでは回線速度のベースラインを1.4Mbpsで考えています。LighthouseのSlow 4G相当です。

一休の1 to 1マーケティングを支えるプラットフォーム

データサイエンス部・大西 id:ohke です。

一休の1 to 1マーケティングを支えるプラットフォームについてお話したいと思います。

1 to 1マーケティング

一休の主力である宿泊予約サービスは今年で19年目、レストラン予約サービスも13年目を迎え、会員数も800万人を超えました。
一休のサービスを「知らなかった」から「知っている」という成熟フェーズに入ってきますと、集客に加えて、1 to 1マーケティングがより重要になってきてます。

一休の1 to 1マーケティングで大事にしていることは3点です。

  • 施策に必要なデータは全てデータウェアハウス (DWH) へ集約する
  • オートメーションツール (内製のWebアプリケーション) でターゲットの抽出、コンテンツの作成、配信を一元管理する
  • ユーザごとにコンテンツを最適化する (レコメンド)

f:id:ohke:20181228105756p:plain

DWHとETL

1 to 1マーケティングでは、ユーザの過去の行動に基づいて施策を実施していきます。
そのため、予約情報 (サービスのテーブルデータ) 、アクセス情報 (Google Analyticsと内製のリアルタイムログ収集ツール1) 、およびそれらと紐付くマスタデータなどは、全てDWHに集約しています。

DWHには、SQL Server (RDS) を使っています。SQL Server Management StudioやRedashでSQLを書けば、誰でも集計・分析を行えるようになります。

DWHへの日々のETL (抽出・加工・格納) は極めて重要になります。
ETLが失敗・遅延すると、データにアクセスできなくなり、1 to 1マーケティングに支障を来してしまいます。マーケティングの文脈以外にも、DWHは、CEOをはじめ各事業部長や集客チーム・UI/UXチームの定点観測や意思決定に利用されるため、データが無い・間違っていることによる影響は甚大です。

一休ではETLを管理するツールとして、Apache AIrflowを導入・運用してきました

user-first.ikyu.co.jp

日次だけで約400タスク (1タスクが1つのテーブルのエクスポートなどと対応します) 、さらに週毎・時毎などのタスクもあわせると、そこそこ大規模なETLとなります。

f:id:ohke:20181228125559p:plain

DWHとETLを健全な状態に維持し続けるために、以下の改善・運用も行ってます。

  • 社内の各部署から依頼されるDWHへのデータ追加や計算方法変更への対応
  • 各部署で自然発生的に持っていたETL処理もAIrflowへ統合
  • 事業担当者 (マーケタや営業) が実行するクエリのチューニング
  • 滞留クエリの自動検知・除去

オートメーションツール

1 to 1マーケティングでは、その名の通り、ユーザ一人ひとりに寄り添ってなければなりません。しかし一方で、アプローチするユーザ数も減らしたくないので、必然的に、少数のユーザに深くターゲットした施策をたくさん実行する必要があります。

1 to 1マーケティング施策の実行にあたっては、大まかに、ターゲットの抽出、コンテンツの作成、配信という3段階の作業を行います。
従来は他社のマーケティングメール配信サービスを使ってきましたが、数十以上の施策を実施するにあたって、大きな壁にぶつかりました。

  • ターゲットやコンテンツに埋め込む値の抽出は、マーケタの日々の手運用に頼られていたため、スケールしない
    • SQLで抽出したCSVファイルをファイルサーバにアップロードする、ということを施策ごとに行っていました
  • 配信は他社のサービス任せとなる (一休でコントロールできない) ため、事故無く運用するためには習熟が必要

また、メールだけではなく、サイトに来訪しているユーザにもアプローチするために、以下の新しいチャネルも要件として生まれていました。これらのチャネルをサービスに密に組み込んでしまうと、施策のたびにマーケタと事業部のエンジニア・デザイナが協同せざるえないため、クイックに施策を実行できなくなります。

  • サイトメッセージ: サイト上でのお知らせやクーポン配布に使われます
  • ポップアップ: サイトメッセージよりも訴求力が強く、クーポン配布に使われます

そこで、ターゲットの抽出・コンテンツの作成・配信を一元管理するオートメーションツール (Webアプリケーション) を内製することで、上の課題の解決を図りました。

  • ターゲットやコンテンツに埋め込む値の抽出を、DWHへ発行するSQLで記述できるようにする2
  • テキストやHTMLを編集できるようにすることで、自由にデザインを変更・プレビューできるようにする
  • 配信のチャネル (メール or サイト上のメッセージ or サイト上のポップアップ) 、日時、優先度などを確認・変更できるようにする
  • 配信は全てオートメーションツールで行うため、基本的には事業部のエンジニア・デザイナとコミュニケーションする必要が無い

f:id:ohke:20181226165711p:plain

オートメーションツールの導入と、その後のマーケタの細やかな施策設計によって、現在では毎日100近くの施策がこのツールから実行されています。

f:id:ohke:20181226163558p:plain

日々の効果測定は、Google Analyticsなどを使って収集し、Redashでビジュアライズして、Slackに通知するというカジュアルな方法を採ることが多いです。

f:id:ohke:20181227145344p:plain

オートメーションツールそのものは以下のアプリケーション構成となっています。

  • サーバサイドは、Python + Flask + SQL Alchemy
  • フロントエンドは、React
  • CI/CDは、CircleCI + CodeDeploy

オートメーションツールからの配信は、チャネルごとに異なる機構で行っています。

  • メールは、サービスと同等の構成をマーケティング用に構えました3
  • サイトメッセージとポップアップは、RDS (SQL Server) に配信リストを渡し、API (Go) 経由でサービスからアクセスすることで実現しました
  • それぞれの配信結果もDWHへETLすることで、開封率の集計や効果測定を行ってます

f:id:ohke:20181228104528p:plain

レコメンド

いくらオートメーションツールで簡単にユーザへ配信できるようになったとしても、そのユーザにとって嬉しい情報でなければなりません。

ホテルやレストランの予約を提供している一休にとって、「そのユーザがどのホテル or どのレストランをおすすめされると喜ばれるか」というのは、サイトでの検索結果やリマーケティング施策では重要なテーマです。特に、ユーザの直近の行動を反映できないリマーケティング施策 (例えば、数ヶ月前に宿泊したユーザを対象としたメール) では、興味を引くコンテンツとなっていないとユーザの心が離れる (要するにウザいと思われる) 要因となってしまいます。

一休では、サイトでの検索結果やリマーケティングメールに表示されるホテルやレストランのリストは、各ユーザの過去の行動を反映したものとなってます。レコメンドと呼んでいます。
具体的には、ホテルやレストランでの行動 (予約やアクセスなど) を元に、アイテムベースの協調フィルタリングを用いて、類似したホテルやレストランをおすすめするというロジックになっています。これらのロジックもDWH上のデータを使って計算しています。

サイトでの検索結果にも同様のロジックでレコメンドしてますが、リアルタイムな情報を使う必要があること、および、サービスに組み込むために堅牢性が求められることから、APIとして提供してます。
このAPIは以下のような構成となっています。こうしたサービスから利用されるアプリケーションの開発・運用もデータサイエンス部の役割です。

  • 実装はPython + Flaskで、全てオンメモリに展開してリクエスト都度で計算してます
  • インフラは、ECS + ElasticBeanstalk
  • CI/CDは、CircleCI

課題は山積みです

今回お話した中でも、まだまだ取り組めていない課題はたくさんあります。

  • DWH/ETLやオートメーションツールの安定化
    • 営業時間前にデータが出揃ってないと、集計・分析や施策の精度が落ちてしまうので、ETLの品質を担保し続けていかないといけません
    • そこまで熟達していないマーケタがSQLやデザインを自由に記述できるので、大きな事故につながらないようにシステムで細やかに予防する必要があります
      • 「検証配信」や「計算する」(件数チェック) はそのための仕組みとなってます
  • 配信タイミングの最適化
    • このユーザには朝8:00、そのユーザには夜7:00など、ユーザごとにチャネルに触れる時間帯が異なる
    • そのユーザがチャネルに触れる時間帯を狙ってアプローチしたい
  • 協調フィルタリングによって売り上げのリフトに成功していますが、更なるUX向上のために別のアプローチを模索中
    • 協調フィルタリングでは、ライトユーザの場合には情報が不足しているため、レコメンドによるリフトが小さくなってしまいます (いわゆるコールドスタート問題)
    • ヘビーユーザでも、ユーザの嗜好が常に一定では無く、ユーザのコンテキスト (目的、一緒に行く人、気分など) を汲み取る必要があります
      • 以前イタリア料理店に行ったからと言って、未来永劫イタリア料理店に行くとは限りません
    • リアルタイムのユーザ行動を反映しながら、その時点でそのユーザにとって最もフィットするホテル or レストランをおすすめできるようになることを目指してます

上に加えて、データサイエンス部としては他にも様々な課題に取り組んでいます。

  • 急増するレストランへの営業活動を最適化する
  • 抽象的なワードでも良い感じにレストランを検索できるようにする
  • クーポン施策の最適化 (損益分岐点の予測など)
  • などなどなどなど...

データサイエンス部では、こうした取り組みを4人で遂行しています (2018/12現在) 。

一緒に取り組んでいただける仲間を募ってます

DWHやETLの改善に燃える!

一休の経営や施策の根幹を成すデータの安定供給のために、自ら設計・構築・運用できます。

内製アプリケーションをクイックに開発・改善したい!

フロントエンド、バックエンド、インフラ、CI/CDを自分で考えて開発できます。

統計モデリングや機械学習でもっとかっこよく課題を解決したい!

高価格帯のサービスECサイトですので、他のサービスと一線を画したテーマの問題に取り組めます。

自ら考えた施策でもっとユーザに愛されるサービスへ育てたい!

CEO直下で施策の立案・遂行・改善に取り組めます。


  1. 詳しい経緯はこちら → データ分析基盤、その後 - 一休.com Developers Blog

  2. 一休のマーケタはSQLを書けます。

  3. 詳しくはこちら → 新メール配信基盤への移行 /ikyu-mail-platform - Speaker Deck

イベント登壇のお知らせ ~1/30(水) 一休com on クラウド ~ 急成長を支える技術基盤とSRE~

こんにちは。今日はイベント登壇のお知らせです。

1/30(水) にマイナビさんが主催する「ITSearch+」のイベントに弊社エンジニアの 徳武(id:s-tokutake) が登壇します。

一休com on クラウド ~ 急成長を支える技術基盤とSRE ~

今回は「技術基盤、SRE」をテーマとして

  • 一休.com / 一休レストランのクラウド移行

を軸に、以降前後でインフラ、技術基盤の仕事がどのように変わってきているか、サービスの成長を支えながら開発生産性をどう上げているのかなどを具体的な事例をもとにお話する予定です。

お申込みはこちらから。

news.mynavi.jp

ご興味のある方はぜひご参加ください。

またイベント開催後に、発表スライドをもとにレポートを書きたいと思いますので、こちらもお楽しみに!

履歴テーブルについて

この記事は一休.com アドベントカレンダーの25日目の記事です。

レストラン事業部エンジニアのid:ninjinkunです。

一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。

業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。

そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。

履歴テーブルのパターン

まず以下の図をご覧ください。

f:id:ninjinkun:20181225190812p:plain

込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。

図にあるとおり、たいていのユースケースでは以下の3パターンの実装に落とし込めるのではないかと考えています。

  1. バージョンテーブル
  2. ログテーブル
  3. ElasticSearchやBigQueryなどに放り込む

いきなり「バージョンテーブル」や「ログテーブル」などの単語が出てきましたが、これは自分が「履歴テーブル」を細分化するために使っている言葉です。以下でそれぞれについて説明します。

1. バージョンテーブル

アプリケーションから特定のバージョンを参照する必要があるので、以下の様にバージョン番号を保持するテーブルを作ります。

元データテーブル

価格が変わる商品の例です。IDと最新のバージョン番号を保持しています。

id version price
1 2 1,000
2 1 2,000
3 3 10,000

バージョンテーブル

今までの価格変動がバージョン毎にすべて記録されています。

id item_id version price
1 1 1 1,100
2 2 1 2,000
3 3 1 11,000
4 3 2 10,500
5 1 2 1,000
6 3 3 10,000

2. ログテーブル

基本的にアプリケーションから参照しない前提であり、参照する場合も一覧で確認用に表示するくらいなので、バージョン番号などは不要です。

元データテーブル

id price
1 1,000
2 2,000
3 10,000

ログテーブル

元データテーブルと同じカラム + ログ用の作成日を持つ。更新があったものをどんどん放り込んでいきます。最新かどうかは作成日で判断します。

id item_id price log_created_at
1 1 1,100 2018-11-10 12:00:00
2 2 2,000 2018-11-10 12:01:00
3 3 11,000 2018-11-10 12:02:00
4 3 10,500 2018-11-15 12:00:00
5 1 1,000 2018-11-18 11:00:00
6 3 10,000 2018-20-10 13:00:00

3. ElasticSearchやBigQueryなどに放り込む

こちらのパターンについては一休では採用していないので詳細がないのですが、社外のエンジニアに履歴について相談した際に「うちではこうしているよ」という事例として聞いたものです。

リーズナブルな解決策だと思うので、どこかで採用したいと考えています。

テーブルの詳細

テーブル設計の詳細についても触れておきます。

別テーブル vs イミュータブル

自分が最初に履歴テーブルを見た時に感じたのは「履歴として独立したテーブルは必要なのか?」という疑問でした。履歴として独立したテーブルが無くても、同じテーブルに変更を全て残すように設計すれば、別テーブルはなくても履歴は作ることができます。自分はこれをイミュータブルパターンと呼んでいます。

これの議論については以下のエントリが参考になります。

自分が見ている範囲では、上記エントリの2のパターン、つまりイミュータブルでは無く、別テーブルに元テーブルと同じカラムを作ってを記録するのが最終的に一番穏当な落としどころになるケースが多いようです。

自分が考えるそれぞれのメリット、デメリットは以下の通りです。

メリット デメリット
イミュータブル テーブルが1つで済んで綺麗に見える
書き込みが一回で済む
select する際にmax()で最新の行を絞り込む必要がある(activeフラグなどで解決は可能だが、テーブルロックを掛ける必要が発生すると思われる)
別テーブル 見た目で履歴であることがわかりやすい 2つのテーブルに同時に書き込む必要がある

イミュータブルパターンにもメリットはあるのですが、結局わかりやすさと実装のしやすさから別テーブルパターンが採用されることが多いようです。

データベーストリガー vs アプリケーション側でコピー

別テーブルとして設計する場合、データをコピーする実装にはデータベーストリガーとアプリケーションコード(要トランザクション)の2つの選択肢があります。メリットとデメリットは以下の通りです。

メリット デメリット
トリガー DB側でコピーが自動的に走るために漏れが無い アプリケーションとトリガーに実装が分かれてしまうので後から動きが追いづらい
トリガのデプロイを先にしないとエラーが発生するので、デプロイ時に気を遣う必要がある
コード データの管理が全てコードに集中するので、動きが追いやすい
テストが書きやすい
トランザクションを張り忘れると大変

バージョンテーブルのパターンでは、バージョンテーブルはアプリケーションから参照されるので、アプリケーションに属する機能だと考えられます。この場合はアプリケーションコードで実装する方が自然だと思います。

一方でログテーブルのパターンでは、アプリケーションの機能として捉えるか、ただのログとして捉えるかは解釈が分かれるところです。実装方法もトリガーとコード、どちらも選択肢に入ると思います。自分はトリガはDB側の設定を見に行かないと挙動が把握できないので、極力アプリケーション側で実装したいと思っています。ただ、現場では後から証跡を残して欲しいと言われる事も多く、その場合に短時間で証跡テーブルを実装するにはトリガが選択されることも多いです。

おわりに

初めは違和感を感じていた履歴テーブルですが、これは時系列データのモデリングなのだと考えることで、今では素直に受け入れられるようになりました。

このエントリでお伝えしたいことのほとんどは最初の図に入っていますので、もし良ろしければもう一度ご覧ください。

f:id:ninjinkun:20181225190812p:plain

ここで漏れているパターンも当然あると思いますので、ぜひ皆さんの考える最強の履歴テーブルについても教えていただけると嬉しいです。うちはイベントソーシングで全部解決しているよ!などの事例も知りたいです。

一休における「情シス」の取り組み

この記事は一休.com アドベントカレンダーの24日目の記事です。

qiita.com


社内情報システム部の大多和(id:rotom)です。 一休には2018年8月に入社し、情報システムエンジニアとして、IT を活用した業務改善、オフィス環境の構築を中心とした社内の「情シス」業務全般を担当しています。

本エントリでは、表立って登場することの少ない「情シス」が普段何をしているか、ご紹介していきます。

情シスのお仕事

f:id:rotom:20181220172319j:plain

社内情報システム部は「システム本部」に所属しており、現在 6人 のメンバで業務を行っています。 一休における情シスは以下の2つの側面を持っています。

コーポレートエンジニアリング:社内ツールやシステムの導入及び管理運用、bot やスクリプト開発による業務の効率化などの業務改善の他、オフィスの IT インフラ環境の構築、改善など、IT を活用し、より社員がよりパフォーマンスを発揮できる環境を構築する、いわゆるコーポレートエンジニアとしての業務を行う

ヘルプデスク:入退社に伴う PC やiPhone、iPad などのモバイルデバイスの調達、キッティング、ライセンスの管理や、新入社員への PC のオリエンテーションの他、社員からのPC や社内システム、IT ツールに関する問い合わせや、トラブルシューティング、修理依頼などの短期的な課題解決を行う IT サポートを行う

それぞれの側面から見た一休における情シスの強みと弱み、そして、これから進めていくことについて紹介します。

コーポレートエンジニアリング

強み

一休で利用しているほとんどの社内ツール/システムでは、シングルサインオンかつ2段階認証(2FA)を導入済であり、社員の利便性とセキュリティを両立させています。

オフィスでは高速なネットワークを整備しており、全国の支社においても同一の SSID/パスワードで Wi-Fi を利用することができ、東京本社と同等の環境で業務を行えるように構築しています。

弱み

一休.com一休.com レストラン を始めとする一休のサービスは全てクラウド(AWS)上で稼働しています。 一方で、レガシーな社内システムや一部のファイルサーバはオンプレミスで構築されており、クラウドに移行ができていません。

災害などで東京本社が機能しなくなった際も業務が止まらないよう、社内システムにおいても「脱オンプレ」を行う必要があります。

これからやること

前述の通り、現状行えていない社内システムのクラウド移行を進めています。 また、営業現場からの要望の多い LINE WORKS の導入や、 システムによる受付業務の刷新など社内業務フローの改善に取り組んでいきます。

line.worksmobile.com

ヘルプデスク

強み

PC のキッティングに伴う単純なセットアップ作業はバッチにより自動化されています。また、メーリングリストの作成や PC やモバイルデバイスの MAC アドレス登録などの細かい作業についても、Slack bot にクエリを投げるだけで行えるようになっています。

f:id:rotom:20181221182923p:plain

f:id:rotom:20181221183243p:plain

以前は口頭、電話、Slack と複数の窓口があり煩雑だった問い合わせ対応については、Google フォームによる投稿に一本化し、 必要事項を記入すれば専用の Slack チャンネルへ自動投稿されるように改善されており、情シスメンバが早急に状況を判断し対応できるようになっています。

弱み

PC のセットアップについては多くが自動化されているものの、一部人の手を介す必要のあるものがあります。 現状はキッティング作業を外部リソースへのアウトソースを行っていますが、こちらも自動化を進めなければなりません。

これからやること

今後も事業急成長に伴う社員増大が見込まれます。PC 1台にかかるセットアップの工数を少しでも減らす為の自動化、効率化を継続的に進めていきます。 社内で最もユーザの多い Windows においては Windows Autopilot の導入も視野に入れています。

docs.microsoft.com

社内ツール/システムの紹介

一休では多くのツール/システムが活用されています。その中からいくつかご紹介します。

Slack

slack.com

一休では全社で Slack を導入しており、エンジニアやデザイナーに限らず、営業や事務のメンバともチャット上でコミュニケーションを取っています。 各チームで業務上のやりとりを行うチャンネルの他、勤怠連絡、PC や書籍、オフィス備品の購入依頼や名刺の発注、総務や情シスへの問い合わせを行う専用チャンネルなども用意されています。

f:id:rotom:20181220210321p:plain

また、多くの Slack bot が稼働しており、情シスにおいてはメーリングリストの作成や、入退社に伴うアカウントの作成/停止などの業務は bot により自動化されています。 障害通知を始めとする多くの情報も Slack に連携される仕組みとなっており、社内インフラとして日々利用されています。

「ぽ」は一休で最も多く使われている Slack bot のひとつです。 社員情報検索、会議室予約や、オフィスの座席表や内線番号、Wi-Fi のパスワードなど、今知りたい情報をすぐに検索できる辞書ツールとなっています。

f:id:rotom:20181220205501p:plain

詳しくは以下のエントリで解説されています。

user-first.ikyu.co.jp

G Suite

gsuite.google.com

一休では全社で G Suite を導入している為、 Gmail や Google カレンダー、Google ドライブが業務で利用されています。 また、多くのスプレッドシートが Google Apps Script によりスクリプトが組まれており、 Slack への連携や業務自動化に活用されています。

f:id:rotom:20181220210039p:plain

情シスにおいては、スプレッドシートに入力された人事情報をトリガーとしたアカウントメンテナンスの自動化や、 更新期日の迫ったライセンスや保守契約についてリマインドを行うスクリプトなどを実装し業務の効率化に取り組んでいます。

Azure Active Directory

azure.microsoft.com

Slack や G Suite を含む、一休で利用している多くの社内ツール/システムはAzure Active Directory によるシングルサインオン(SSO)構成となっています。

社内ツール/システムごとにアカウントの ID/パスワードの管理が異なると、社員がパスワードを忘れて問い合わせが発生する、社員の離職に伴うアカウントメンテナンスの工数が大きい、ヌケモレが発生するといった問題が想定されます。

一休では PC にサインインする ID/パスワードでほぼ全ての社内ツール/システムを利用することができます。 また、離職者に対しては Azure Active Directory のアカウントを停止することで、社内ツール/システムへのアクセスを防ぐことができます。

Microsoft Authenticator

Microsoft Authenticator – オンライン アカウントの安全なアクセスと管理

一休では Azure Active Directory による SSO に加え、Microsoft Authenticator による二段階認証(2FA)を行っています。 SSO は複数の ID/パスワードを管理しなくても良い、というユーザの利便性が高い一方で、1つの ID/パスワード が盗まれたときのリスクが高いとも解釈できます。

f:id:rotom:20181220204846p:plain

そこで、一休では各自のスマートフォンに 2FA 用のアプリケーションをインストールして頂いており、アプリケーション側からの承認を得ない限り、 ID/パスワードを知っていても社内ツール/社内システムにはログインできない仕組みをとっています。

Vimeo

vimeo.com

一休では毎月の月初に全社員が東京本社ラウンジに集い、月次の実績報告や社員同士の交流を行う共有会・パーティを開催しています。 各支社のメンバも月初には東京に集まっていましたが、業務都合が付けられずに参加ができないメンバもいました。

f:id:rotom:20160704180322j:plain

また、東京本社で定期的に開催される社内勉強会や、社員向けの説明会にを各支社のメンバに向けてもリアルタイムに共有したいという強いニーズがありました。

そこで、情シスでは動画配信プラットフォームである Vimeo を導入し、東京本社の様子を生中継することにしました。 同様のサービスとしては YouTube Live が挙げられますが、パスワード保護機能を搭載し、よりセキュアである Vimeo を選定しました。

配信機材としては Cerevo 社の LiveShell.PRO を購入することで、HD 画質の高品質なストリーミング配信を実現しました。

liveshell.cerevo.com

Chromebox for meetings

gsuite.google.com

一休では事業急成長に伴い、東京、大阪、名古屋に続き、沖縄、福岡、京都、横浜と次々とブランチオフィスが開設していきました。 事業所が増えることにより、東京本社と各支社間でリアルタイムに Web 会議を行いたいというニーズが高まりました。

Web 会議システムは多種多様にありますが、一休では Chromebox for meetings を導入しました。 この製品は Chrome OS を搭載した Chromebox という PC を Web 会議(Hangout)専用にカスタマイズしたものです。

f:id:rotom:20181221104508j:plain

選定理由として一休では G Suite を導入していることから全社員が Hangout を利用できる状態にあること、 Chromebox for meetings は Hangout に機能を絞ったシンプルなユーザインタフェースであることから導入を決定しました。

IT 部門の担当者が社内ツール/システムを選定する際は、極力安い製品を選んでしまったり、自分たちの IT リテラシー基準で選んでしまったりと、IT 部門目線になってしまうことがあります。 ユーザファーストのカルチャーとする一休の情シスにおいてはユーザである社員にとって使いやすいか、という点を最重視して機器選定を行いました。

尚、現在は Chromebox for meetings は生産を終了しており、後継種の Chrome devices for meetings が販売しています。

最後に

情シスのエンジニアが行っている業務は、事業部でプロダクト開発を行っているエンジニアと比べると地味かもしれません。 しかし、ユーザ(= 社員)と最も近い距離で直接ニーズやフィードバックを聞くことのできる、非常にやり甲斐のある立場であると考えています。

一休においては、多くの業務が社内ツール/システムや bot により自動化、効率化されていますが、未だ人の手を介している業務フローも多く存在します。 そうした社内の業務課題の解決、改善を継続的に行い、社員が「本来やるべき業務に時間を使える」環境を作り上げるのが情シスのミッションです。

これからも一休 情シスは社内の業務改善、サポートを続けていきます!

一休 情シスではアルバイトスタッフを募集しています!

www.wantedly.com

明日は今年最後のアドベントカレンダー id:ninjinkun による履歴テーブルについてです!