adish intelligence

アディッシュ株式会社のエンジニアブログです。

Bing Search API v2 から v5 へ移行した話

この記事は Gaiax Advent Calendar 2016 の3日目の記事です。

こんにちは、アディッシュ株式会社(以下、adish)・ALICEチーム*1の白木です。
（何も考えずに今年も12/3が空いていたのでこの日に参加予定を入れたら去年のGaiax Advent Calendarでも12/3だったので、深層心理で12/3が好きなのかも。）

Gaiax Advent Calendarでいきなりadishなる会社名を名乗りましたが、adishはGaiaxのグループ会社で、去年と同じく今年もGaiax Advent Calendarに参加しています。

記事の背景

f:id:shirakiya:20161202103905p:plain

タイトルからお分かりになる通り、Gaiax Advent CalendarでBing Search APIについての記事を投稿しようとしているわけですが、これはadishで利用している外部APIの1つなので、題材としました。
利用している理由は、このブログで以前投稿した「PythonでBing Search APIを使って画像データを集める方法」という記事の中で説明をしているのですが、adishでは今年めっきりバズワードになった ディープラーニング を用いた機械学習技術を画像認識タスクに利用しており、その際の検証目的で使う画像の取得にBing Search APIを用いています。

上の記事で紹介しているのは、Bing Search API v2についてで、これはMicrosoft DataMarketから利用登録を行うものでした。
しかし、2016年7月1日から新しいバージョンのBing Search API v5がMicrosoft Cognitive Services上でリリースされ、同時に旧バージョンのBing Search API v2が使えなくなる、というアナウンスがなされました。

そしてその旧バージョンの利用期限が 2016年12月15日 までとなっています。

・・・

期限ギリギリッ!!!!!!!!

はい、そういうわけで今回は、v2からv5へ移行すべくして移行したその作業手順と、画像取得を主とした新しいAPIの使い方について紹介します。

Bing Search API v5を使うまで

ありがたいことに、Microsoftからv2からv5に移行する人向けに専用の記事を用意してくれていますので、それを参考に進めてみます。
https://msdn.microsoft.com/en-US/library/mt707570.aspx

あと前提として、Microsoftアカウントを持っていることとします。もし持っていない場合はこちらから新規登録してください。

※ Bing Search API v5（無料版）の利用はMicrosoft Cognitive Services上で行うものであり、Microsoft Cognitive Servicesに登録できていれば利用可能です。Microsoftアカウントの他に、GithubアカウントやLinkedinアカウントがあればサインアップが行えるようですが、今回はMicrosoftアカウントを使った方法を説明します。

Microsoft Cognitive Servicesからサブスクリプションキーを取得する

まず、サブスクリプションキーを取得します。これはAPIキーのようなもので、Microsoft Cognitive Servicesのアカウントを持っていれば取得可能です。

まず、Microsoft Cognitive Servicesのサインアップページからサインアップし、アプリ連携するとCognitive Services上のマイページに行くことができます。

f:id:shirakiya:20161202095415p:plain

ここから画面右にある「verification」からアカウントの確認を行います。押すとメールが送られてきて、その中に添付されているURLを押すと確認完了になる、よくあるやつです。
それを終えると、次に「Request new trials」というボタンが画面右下にあるので、これをクリックすると無料で利用可能なAPIの一覧が、無料枠の説明と共に表示されます。

f:id:shirakiya:20161202095436p:plain

その中にある「Bing Search」と利用規約同意にチェックを付けると、サブスクリプションキーが発行されます。

f:id:shirakiya:20161202095457p:plain

f:id:shirakiya:20161202095513p:plain

ちなみに、この画像のようにサブスクリプションキーが2つ発行されますが、これは

Each service returns a primary and secondary key. Both keys are tied to the same quota, so you may use either key.
https://msdn.microsoft.com/en-us/library/mt712546.aspx#Anchor_0 より

とのことで、どちらを使っても良いようです。

Bing Search API v5の種類

Bing Search API v5は、

  • Web Search API（Webページ+画像+動画+ニュース）
  • News Search API（ニュース検索）
  • Image Search API（画像検索）
  • Video Search API（動画検索）

の4つに分かれており、{News|Image|Video} Searchはそれぞれニュース、画像、動画のみ取得することができますが、Web Searchはその全ての情報を取得することができます。
ただ、ニュース・画像・動画等全て入っていることは担保されているわけではなく、検索クエリによってはWebページだけの場合が合ったりするので、基本は欲しい情報に適したAPIを使う必要がありそうです。

今回は画像検索の結果を得たいので、Image Search APIを使うことにします。

Image Search APIを使う

次に実際にAPIを使ってみることにします。
APIのドキュメントは、

にまとめられているので、詳しくはこちらをご参照ください。

Request Header

Bing Search APIを使うには、Request Headerに Ocp-Apim-Subscription-Key={取得したサブスクリプションキー}を加えてることで正常なResponseが得られます。
（User-Agent,X-MSEdge-ClientID,X-Search-ClientIPも積極的に設定してね、とも書いてあるのですが、これを設定した時の影響は調査していません、ごめんなさい。）

Endpoint

Endpointは以下の通り。

https://api.cognitive.microsoft.com/bing/v5.0/images/search

クエリパラメータ

クエリパラメータで必須なのは、qのみで、こちらに検索したい文字列を指定します。
オプションのパラメータは、

を参考に指定してください。
例えばよく使うのは、

  • count: 1度の検索で何件取得するか（デフォルト: 35件、最大: 150件）
  • offset: 検索トップからどれだけスキップした後の画像を取得するか
  • mkt: どの地域での検索結果を得るか（日本であれば ja-JPを指定する。

などでしょうか。ちなみに count は、v2だと $top というパラメータ名であったりと、こうしたパラメータ名の変更や利用できるパラメータの変更が多くあるのでパラメータに関しては特に要チェックです。

レスポンス

実際にリクエストしてみます。
今回は、日本での検索で "リンゴ" という検索文字列を指定し、結果2件だけ受け取る、というリクエストを行いました。

  • Request URL
https://api.cognitive.microsoft.com/bing/v5.0/images/search?q=%e3%83%aa%e3%83%b3%e3%82%b4&mkt=ja-JP&count=2
  • Response
{
  "_type": "Images",
  "instrumentation": {
    "pageLoadPingUrl": "https://www.bingapis.com/api/ping/pageload?IG=89CB4863E5DC43F9804095E7823C1036&CID=27CB8EF3C20E62CC2C89872DC31C6375&Type=Event.CPT&DATA=0"
  },
  "webSearchUrl": "https://www.bing.com/cr?IG=89CB4863E5DC43F9804095E7823C1036&CID=27CB8EF3C20E62CC2C89872DC31C6375&rd=1&h=P17B0qhd32lnjN5_RH7oKgCuhapuQtRSZ6r-fx_BC3U&v=1&r=https%3a%2f%2fwww.bing.com%2fimages%2fsearch%3fq%3d%25E3%2583%25AA%25E3%2583%25B3%25E3%2582%25B4%26FORM%3dOIIARP&p=DevEx,5028.1",
  "totalEstimatedMatches": 948,
  "value": [
    {
      "name": "Illustratorで林檎を描いてみた ...",
      "webSearchUrl": "https://www.bing.com/cr?IG=89CB4863E5DC43F9804095E7823C1036&CID=27CB8EF3C20E62CC2C89872DC31C6375&rd=1&h=XC5oD8iG4FFpgigR6S8K5sYJGxtYq1tMKugZUr4_6Js&v=1&r=https%3a%2f%2fwww.bing.com%2fimages%2fsearch%3fview%3ddetailv2%26FORM%3dOIIRPO%26q%3d%25e3%2583%25aa%25e3%2583%25b3%25e3%2582%25b4%26id%3d89C28207FC57BC63DDAFED0425CC32B3901B10FF%26simid%3d608001155137668054&p=DevEx,5006.1",
      "thumbnailUrl": "https://tse3.mm.bing.net/th?id=OIP.M992c7d29fcff00d731f580975bee5352o0&pid=Api",
      "datePublished": "2014-08-01T23:44:00",
      "contentUrl": "http://www.bing.com/cr?IG=89CB4863E5DC43F9804095E7823C1036&CID=27CB8EF3C20E62CC2C89872DC31C6375&rd=1&h=ncKfI_uF6wfrn08gg4KKgbx-LqVWyO1LWh6APvnGNoc&v=1&r=http%3a%2f%2fcdn-ak.f.st-hatena.com%2fimages%2ffotolife%2ff%2fforeverLab%2f20140327%2f20140327203348.jpg&p=DevEx,5008.1",
      "hostPageUrl": "http://www.bing.com/cr?IG=89CB4863E5DC43F9804095E7823C1036&CID=27CB8EF3C20E62CC2C89872DC31C6375&rd=1&h=dpKYzf4HQGiCt8ahRdWfqt5-tlua-3hgX96PGlBpV90&v=1&r=http%3a%2f%2fforeverlab.hatenablog.com%2fentry%2f2014%2f03%2f27%2f205248&p=DevEx,5007.1",
      "contentSize": "50081 B",
      "encodingFormat": "jpeg",
      "hostPageDisplayUrl": "foreverlab.hatenablog.com/entry/2014/03/27/205248",
      "width": 640,
      "height": 427,
      "thumbnail": {
        "width": 300,
        "height": 200
      },
      "imageInsightsToken": "ccid_mSx9Kfz/*mid_89C28207FC57BC63DDAFED0425CC32B3901B10FF*simid_608001155137668054",
      "imageId": "89C28207FC57BC63DDAFED0425CC32B3901B10FF",
      "accentColor": "C84403"
    },
    {
      "name": "奇跡のリンゴ』上映中！中村 ...",
      "webSearchUrl": "https://www.bing.com/cr?IG=89CB4863E5DC43F9804095E7823C1036&CID=27CB8EF3C20E62CC2C89872DC31C6375&rd=1&h=xMJhqVdP-6nMW2NYP88Y_WuWz138HJsNH-SAlb3sjLk&v=1&r=https%3a%2f%2fwww.bing.com%2fimages%2fsearch%3fview%3ddetailv2%26FORM%3dOIIRPO%26q%3d%25e3%2583%25aa%25e3%2583%25b3%25e3%2582%25b4%26id%3dBC8E6F42DC222DC074E1952452F1332F200CCFE8%26simid%3d608026022994903221&p=DevEx,5012.1",
      "thumbnailUrl": "https://tse2.mm.bing.net/th?id=OIP.M52d8fb557aa4e3fa34feeb0af6beaa6eo0&pid=Api",
      "datePublished": "2016-03-19T15:30:00",
      "contentUrl": "http://www.bing.com/cr?IG=89CB4863E5DC43F9804095E7823C1036&CID=27CB8EF3C20E62CC2C89872DC31C6375&rd=1&h=3aTuMYOrZfWvXFmmaTs_HIeoppH5-wEUxgD1cweybhk&v=1&r=http%3a%2f%2fwww.arakawaoki.co.jp%2fnews%2fwp-content%2fuploads%2f2013%2f06%2f8facebad793516c2228e862ca9b783d6.jpg&p=DevEx,5014.1",
      "hostPageUrl": "https://www.bing.com/cr?IG=89CB4863E5DC43F9804095E7823C1036&CID=27CB8EF3C20E62CC2C89872DC31C6375&rd=1&h=4gsI4XakrhOoP7ZS2xGE06wnzCahftXnzIdAvK6HNdU&v=1&r=https%3a%2f%2fwww.arakawaoki.co.jp%2fnews%2f%3fp%3d2525&p=DevEx,5013.1",
      "contentSize": "41278 B",
      "encodingFormat": "jpeg",
      "hostPageDisplayUrl": "https://www.arakawaoki.co.jp/news/?p=2525",
      "width": 560,
      "height": 372,
      "thumbnail": {
        "width": 300,
        "height": 199
      },
      "imageInsightsToken": "ccid_Utj7VXqk*mid_BC8E6F42DC222DC074E1952452F1332F200CCFE8*simid_608026022994903221",
      "imageId": "BC8E6F42DC222DC074E1952452F1332F200CCFE8",
      "accentColor": "3F0E04"
    }
  ],
  "nextOffsetAddCount": 0,
  "displayShoppingSourcesBadges": false,
  "displayRecipeSourcesBadges": true
}

画像情報はvalueの中に配列で入っています。
当然ですがオプション指定によって、かなり検索結果が変わるので、便利ですね。

Pythonでリクエストする

一応PythonでAPIをcallしてレスポンスを受け取る超簡単なコードを記しておきます。
（requestsは外部モジュールではありますが、非常に使い勝手が良いのでこちらを用いています。）

# -*- coding: utf-8 -*-
import requests

query = 'りんご'
endpoint = 'https://api.cognitive.microsoft.com/bing/v5.0/images/search'
headers = { 'Ocp-Apim-Subscription-Key': <SUBSCRIPTION_KEY> }
params = {
    'q': query,
    'mkt': 'ja-JP',
    'count': 2,
    'offset': 0,
}
response = requests.get(endpoint, headers=headers, params=params)
print(response)  #=> 上記のJSONのレスポンスが得られる

以下のMicrosoftのページに行けば各言語の簡単な使い方を記してくれていますので、こちらを参考にしてみるのも良いと思います。
https://dev.cognitive.microsoft.com/docs/services/56b43f0ccf5ff8098cef3808/operations/571fab09dbe2d933e891028f

さいごに

以上にBing Search API v5の紹介を行いました。
旧バージョンについては、

https://datamarket.azure.com/dataset/bing/search

からAPIの利用を停止するか、もしくは2016年12月15日になれば使えなくなるはずなので放っておいても良いでしょう。これにて移行…というか完全に新しくv5を始める、という感じでしたが、無事年を越すことができそうです。

*1:ALICEチームとは機械学習に関する開発を行っているチームです。アディッシュの技術開発部のチーム構成については以前投稿した記事をご覧頂ければと思います。

過誤(分割表)と二値分類の性能評価について

こんにちは、ALICEチーム*1の白木です。

今回は機械学習の性能評価の中で、最も基本的な"二値分類の性能評価"について投稿します。

二値分類とはその名の通り、例えば「真 / 偽」「リンゴである / リンゴでない」「捨てるもの/ 捨てないもの」のように、二種類のグループに分ける作業のことで、二項分類・二クラス分類と呼ばれることもあります。

機械学習のように確率論の上で成り立つ技術において、機械がこの分類作業を「正しく行えているか」評価を行った上で、リリースなどの判断を行うべきで、そうした性能評価はとても重要です。実際、機械学習はそれそのもののアルゴリズムを理解・習得するのも重要ですが、どうやって評価を行うのか、の観点も同時に必要となります。

そこで、二値分類の性能評価を行う上で、抑えておくべきワードの「過誤」「分割表」「評価指標」についてまとめて紹介します。

過誤

過誤とは「あやまり」の意味であり、機械学習の文脈で話すと、分類を行った結果の「間違え方」を表すワードとして用いられます。
この過誤は特に「第一種過誤」と「第二種過誤」と呼ばれる定義として知られています。

第一種過誤

第一種過誤とは「偽陽性」とも呼ばれ、文字通りに解釈すると「ニセの陽性」です。
つまり 「本来陰性であるが、陽性と(間違えて)判断した」 状態を指す言葉です。

ここで言う「陽性」とは「リンゴである / リンゴでない」の二値分類で言えば「リンゴである」という属性を持つ状態のことを指し、「陰性」は「リンゴでない」という属性を持つ状態のことを指します。*2

第二種過誤

第二種過誤とは「偽陰性」とも呼ばれ、文字通りに解釈すると「ニセの陰性」です。
つまり 「本来は陽性であるが、陰性と(間違えて)判断した」 状態を指す言葉です。

分割表

以上の2種類の過誤の定義を踏まえて、判断を下した結果は以下の4つの条件に分類することができます。
以下のような表は「分割表(Confusion Matrix)」と呼ばれ、二値分類の結果を簡単に眺めることができるので、この表を元に結果をまとめると良いです。

f:id:shirakiya:20161128155118p:plain

「実際の状態」は、判定対象物が実際に持つ状態を指し、二値分類では正例に該当する場合は「Positive」、負例に該当する場合は「Negative」と表します。
「判定結果」は、分類器が結果として出力する分類結果のことを指し、二値分類では正しく分類することができた場合は「True」、間違えて分類した場合は「False」と表します。*3

4つの条件それぞれには「True Positive(TP)」というような名称が付けられています。

  1. True Positive (TP)（実際に正例であるものを正例と判断したもの）
  2. False Negative (FN)（実際には負例であるものを正例と判断したもの、第一種過誤）
  3. False Positive (FP)（実際には正例であるものを負例と判断したもの、第二種過誤）
  4. True Negative (TN)（実際には負例であるものを負例と判断したもの）

1つのケースとして、今まで説明で使っていた「リンゴである / リンゴでない」の場合だと、分割表は以下のようになります。

f:id:shirakiya:20161201092151p:plain

性能評価指標

次に性能評価。二値分類での性能評価によく用いられる指標は、

  • 正答率(Accuracy)
  • 適合率(Precision)
  • 再現率(Recall)
  • F値(F-measure)

の4つです。それぞれの指標について説明していきます。

正答率(Accuracy)

正答率(Accuracy)は、判定結果と実際の状態がどれだけ一致しているかを表す指標です。つまり 全体の判断の正しさ を表す指標となります。
計算式は以下の通り。

f:id:shirakiya:20161128155941p:plain

分割表で言うと、オレンジ枠で囲った全ての条件に該当したものの総和を使って、オレンジ背景にした条件に該当したものの和を割った数字となります。

f:id:shirakiya:20161128160003p:plain

ただし、正答率は評価に用いるデータのそれぞれのPositive/Negativeデータ点数の大小の影響を受けやすい数値であり、本当に正しさを測れているのかどうかに注意する必要があります。（極端に考えると、Positiveなデータが9,990個あるのに対してNegativeなデータが10個しかない場合で、TPが9,990、TNが0だとしたら、9990/10000 = 0.999 となりますがTNは全く上手く判定できていない、という状態になります）

適合率(Precision)

適合率(Precision)は、正しいと判定した結果に対して、実際の状態が正であるものの割合です。つまり 判定した結果の正しさ(正確性) を表す指標となります。
計算式は以下の通り。

f:id:shirakiya:20161128161304p:plain

分割表で表すと、True Positive（オレンジ背景）を、判定結果が正例なものの総和（オレンジ枠）で割ったものです。

f:id:shirakiya:20161128161342p:plain

「確実にリンゴであるものを抽出して欲しい」というような要求の場合は、この適合率で高い数値を出している状態が望ましい、ということになります。
また、上記の計算式では「正例の判定」に着目していますが、逆に「負例の判定」に対しても同様の考え方で導入可能です。

再現率(Recall)

再現率(Recall)は、実際の状態が正のものに対して、正しいと判定した結果の割合です。つまり 実際に正の状態のものをどれだけ正と判定して網羅しているか(網羅性) を表す指標となります。 計算式は以下の通り。

f:id:shirakiya:20161128161856p:plain

分割表で表すと、True Positive（オレンジ背景）を、実際の状態がPositiveなもの（オレンジ枠）で割ったものです。

f:id:shirakiya:20161128161923p:plain

「リンゴであるものの取りこぼしを極力小さくして欲しい」というような要求の場合は、この再現率で高い数値を出している状態が望ましい、ということになります。

F値(F-measure)

統計的に誤差が発生しうる分類器において、適合率と再現率はトレードオフの関係にあります。
つまり、適合率を高くしようとすれば、(例えばより厳しい閾値等が用いられた上で正と判断させるようにするため)TPの絶対値が小さくなり、その分FPが大きくなります。ゆえに上記計算式より再現率が低下してしまいます。

F値(F-measure)は、このトレードオフ状態を考慮して、総合的な性能の評価尺度として適合率・再現率の調和平均を取ったものです。
計算式は以下の通り。

f:id:shirakiya:20161128162444p:plain

つまり

ベン図で考えることとします。

f:id:shirakiya:20161129102655p:plain

ピンク色の集合が「判定した結果、正例だと判断した集合」で、緑色の集合が「実際に正例である集合」を表すとします。
究極的には、この二色の集合が一致している状態が理想的な状態だが、そんなわけにもいきませんので、適合率・再現率をそれぞれ大きくなるように振るとどうなるのかを図示してみます。

適合率が大きくなるように振った場合

適合率が大きくなるように振った分類器の場合、ベン図は以下のようになります。

f:id:shirakiya:20161129102710p:plain

適合率の計算式から、

「適合率が大きくなる」=「FNが小さくなる」

なので、上のベン図のように「正例と判断した集合の面積（ピンク色の集合の面積）」に対して「TPの集合の面積の割合（ピンク色の集合と緑色の集合が重なり合っている領域）」が大きくなっている様子が見て取れるかと思います。つまり「正例と判断した結果、実際に正例であることが多い状態」が直感的に理解できると思います。
これは本当に正しいと厳しく判断したものを正と判定するような分類器であり、同時に、網羅度を表す再現率が小さくなることがこの図からわかります。

再現率が大きくなるように振った場合

一方で、再現率が大きくなるように振った分類器の場合、ベン図は以下のようになります。

f:id:shirakiya:20161129102723p:plain

再現率の計算式から、

「再現率が大きくなる」=「FPが小さくなる」

なので、上のベン図のように「Positiveである集合の面積（緑色の集合）」に対して「TPの集合の面積の割合（ピンク色の集合と緑色の集合が重なり合っている領域）」が大きくなっている様子が見て取れると思います。見方を変えると「正例と判断した集合（ピンク色の集合）」が「Positiveである集合」を覆っている状態でもあります。これが、まさに再現率を大きくすると"網羅度"が大きくなっている効果を表しています。

まとめ

  • 過誤（第一種過誤、第二種過誤）
  • 分割表
  • 評価指標項目

について、二値分類の文脈から紹介しました。機械学習において、このような評価指標(評価関数)を用いて、分類器等の性能評価を行うことが求められます。
当然、問題設定によって使うべき評価関数は変わってくるため、新たに取り組む際には注意して選定することが重要です。
タスクに適さない評価を用いている場合は、本番稼働させた際に全然機能せず、地獄を見ること必至なのでよく注意して取り組みましょう！(自戒)

*1:ALICEチームとは機械学習に関する開発を行っているチームです。アディッシュの技術開発部のチーム構成については以前投稿した記事をご覧頂ければと思います。

*2:通常は「リンゴである」を陽性と捉えて進めることが多いですが、一方で「リンゴでない」側を陽性としてしまっても良く、取り組んでいるタスクの性質を元に何を陽性にするかを決めます。

*3:ケースによっては、判定結果において正例に該当した場合を「True」、負例に該当した場合を「False」とすることもあるようです。

全社合宿を支えた SPA アプリ開発 〜 React + Rails でプログレッシブ Web アプリ構築〜

皆さんはじめまして。2年目新卒エンジニアの坪井(@ufo_ocha)です。普段は先日リリース致しましたhitoboの主にフロント周りを開発しています。

f:id:ufo_ocha:20161108002332j:plain

さて、Gaiaxグループでは年に2度、夏と冬に全社合宿を行っています。冬は事業部毎の発表など真面目なコンテンツがメイン、夏はみんなで集まり仕事を忘れて遊びましょうと交流がメインとなっています。だいぶ時間がたってしまっていますが、今回は9月に実施した夏合宿で運営として参加し、合宿用アプリを作成した話です。少しではありますが、当日の様子はこちらからどうぞ。

子ども・パートナーも参加！ガイアックスグループ夏合宿の軌跡

アプリ要件

今回の要件ですが、ざっくりと

  • 合宿のしおり
  • 参加メンバーのプロフィール閲覧
  • コンテンツのフォトロゲイニング

となっています。これは僕ではないのですが、昨年度の冬合宿でしおりをスマホで閲覧しやすいWebページで提供したところ、見やすくてよいと評判だったので、今年もしおりはWebページで提供しようと決まりました。であれば、コンテンツも全てスマホでできるようなものにすると楽しいのでは？ということで、このような要件に決まりました。

実装するにあたって

そんなこんなで始まったこのプロジェクトですが、技術選定や実装上で考えたことなどを紹介したいと思います。

React + Redux

全てをスマホで見る前提でしたので、なるべく体験が良くなるようにSPA(Single Page Application)にしてプログレッシブウェブっぽくしようと考えました。業務でも個人的な趣味でもReactを使っていたので、ビューライブラリとしてReact。Flux構成としては無難にReduxを使うことにしました。何度か使っていて慣れていたこともありますし、今回は状態管理が複雑になることはなさそうだったので、Reduxはシンプルに作れそうだと考えたからです。

react-toolbox

デザイン面であまり時間をかけたくなかったので、react-toolboxを利用しました。選定にはGaiaxグループ同期の@__kyrieleison__の以下の記事を参考にさせてもらい、助言をもらい、挙句実装を手伝ってもらいました。感謝！！

早く・それなりの UI を実現する React コンポーネントセット 16 選

上の記事でも多数紹介されていますが、数ある中からreact-toolboxに決めた経緯を少し。コンポーネントセットを使うにしても自分でCSSを書かなければならない部分は結構多いですよね。そのような自分で書く部分とコンポーネントセットで必要なスタイルの管理が別になるのが嫌だったので、まず以下のように絞りました。

  1. material-ui + JSXのstyleでCSS in JS
  2. react-toolbox + CSS Module
  3. react-mdlでCSSは完全別管理

この中で、1はJSXのstyleでCSSを書くのは hover など、擬似クラスが使えないため、Reactのstateで状態を管理して自分で変更せねばならず、ツラいしお手軽ではない。CSSを読み込むだけでいい3にしようかと思ったのですが、当時react-mdlは一部パッチ当てないと上手く動かない（今はどうなのかわかりません）という情報を耳に挟んだため、素直にいけそうな2のreact-toolboxを利用することに決めました。

実際やってみると、Webpackの設定などで多少すんなりいかない部分はあったのですが、その他の部分を書き慣れているCSSで書けるということと、当初の考え通り別に管理する必要がなく楽でした。

Rails

以上のSPAをRailsの上にのせることにしました。今回ログイン前提なので、サーバーサイドレンダリングは必要ないですし、なんでも良かったのですが、SPA部分に集中したかったので、レールに乗ることに。最終的には認証・API・管理画面をのせたのですが、見た目を気にしなくてよい管理画面のscaffoldはやはり便利でした。その他のライブラリも充実していますし、やはりぱぱっと作るにはRailsが便利ですね。

ただ、Rails上のJSの管理をどうするかという問題があります。今回はsprocketsをはじめから切ってnpmによせました。このあたりは以前Qiitaにまとめた

Rails + モダンJS環境(Webpack)で新規アプリ作成

と、ほぼ同じ構成ですので、気になる方はご参考ください。

認証

Gaiaxグループでは社内でGoogleアカウントを利用しています。そのため、今回は認証にGoogleログインを利用し、ログインできるアドレスを会社のドメインに制限しました。この部分はSPAにせず、RailsでOmniAuthを使って実装、ログイン部分とAPI, 管理画面以外は全てReactを読み込むビューを返すようにしました。こうやって認証情報をRailsのセッションにもたせてやることで、フロントからAPIを叩く際にもcookie情報を含めてやるだけで認証が確認できます。ログインしてなければエラーを返し、SPA側でログイン画面にリダイレクトさせるような処理にしました。

ログイン前提でのSPAでしかこのやり方は使えないと思いますが、ソーシャルログインというSPAでは煩わしい部分をRailsに任せることができるのが良かったです。また、APIを分離する場合にも、以下のようにレンダリング+認証とすることによって、認証とロジックの部分を分離でき、APIサーバーをシンプルに保つことができます。

f:id:ufo_ocha:20161108002204p:plain

若干のオーバーヘッドは気になりますが、hitoboでは実際にこのような設計で構築しました。hitoboのアーキテクチャの話もまた機会があれば、ブログに書きたいと思います。

プログレッシブ化

「おい！タイトル！？」とか言われそうですが、結論から言うとこれはダメでした。

現状Safariはプログレッシブに必要なキャッシュしてオフラインで使用、Webプッシュ通知をつかさどるService Workerが未対応です。更に合宿の出欠の際にアンケートを取ったところ、約9割がiPhone。先進国の中でも日本はiPhoneのシェアが7割程、IT企業であれば9割というのは納得の数字です。時間のない中で1割のためにServiceWorkerを使って実装するというのはコストに合わないと思ったので見送り。

ならばと思い、 apple-mobile-web-app-capable を設定し、ホームに追加してもらうことで、ナビゲーションバーを表示せずアプリのように使ってもらおうとしました。しかし、これにも罠があって、apple-mobile-web-app-capable を設定し、ホームに追加したボタンから開いた場合、

  • Safariのcookie, local storageは共有されない
  • JSの遷移以外（aタグ等）はSafariで開いてしまう

という仕様があります。今回の場合、Googleログインの部分が普通にaタグでの遷移だったので、ログインしようとするとSafariが立ち上がってしまいます。そこでログインしてもcookieが共通でないため、ホームに追加したボタンから開いた場合にログインできないという状態になりました。これについては工夫することでなんとかできそうでしたが、仮になんとかなったとしてもcookieが共通でないためにGoogleアカウントにもログインしなければなりません。弊社では2段階認証が必須なため、わざわざログインするのも手間。残念ながらこちらも見送ることにしました。

個人的にServiceWorkerはReactなど、フロントを書く機会が増える！と期待しているのですが、現状ではSafariが対応しないことにはどうにもならないですね。今後に期待！！

懺悔

さて、アプリの要件でも少し触れましたが、 「参加メンバー全員のプロフィール閲覧」という機能を実装しました。はじめにログインした際に名前や顔のわかるプロフィール画像などの情報を入力してもらい、それの一覧と詳細を表示するというただそれだけの機能です。参加者も130人ほどだったので、ページングもない簡単なものです。

　

簡単なものなのですが......

　
　
　
　
　

プロフィール画像のリサイズをしておらず、一覧を開くだけで何MBもの画像ファイルを130も読み込むという膨大な通信を発生させてしまいました。たった40x40pxを表示するために・・・

その他にもコンテンツのフォトロゲイニングでスマホで撮った写真のアップロードなどあり、 参加した社員130名のスマホのデータ通信量を2日の合宿で相当吹き飛ばす という悪行を成し遂げました。ちなみに僕自身はテストで何度も確認したこともあって、次の日に通信制限がかかりました。（あと半月残ってるのに）

言い訳をさせてもらうと、もちろんリサイズが必要なことを知らなかったわけではなく、

  • クロッピングを実装してリサイズしてからアップロードする
  • S3のPUTイベントにフックしてLambdaでリサイズを走らせる

のどちらかにしようとは考えていました。のですが、とりあえず、足りない部分作るのが先だと後回しにしているとあれよあれよと時間が過ぎ、わりと直前まで本番環境として用意した環境でWebSocketが上手く繋がらなくてあたふたし、そのままに。。。

いやー、やることはちゃんとやらないとダメですね。社員の皆様本当にすみませんでした！

感想

上記に書いた以外にも、時間なくて細部作り込めておらず悔しい思いしたりとか、合宿間近の2週間はこのプロジェクトと普段の仕事が両方共デスマっぽくなってめっちゃ辛かったとか（実際にこっちは合宿の日という期限があったので本当にデスマでしたがｗ）いろいろありました。ただ、合宿に参加していただいた社員の方に（データ使用量は吹き飛ばしましたが）楽しんでもらえて嬉しかったですし、足りない部分は多かったにせよやってみたかったことがアプリ制作を通して試せて良かったです。やはりこうやって、作ったものを使ってもらってはじめて学べることは多いなと再認識しました。

まとめ

  • React + Reduxはエコライブラリも充実していて、割りと枯れてきている
  • サクッと作るにはreact-toolboxなどのコンポーネントセットは便利
  • SPAではレンダリング＋認証とAPIサーバと分けると楽
  • プログレッシブは現状では実用的ではない
  • Safari頑張って！！！
  • データ通信量&表示速度の観点から画像はリサイズしましょう

アディッシュ技術開発部では10%ルールという、仕事の時間の10%は自由に使っていい時間があります。今後もそういった時間を使って、最新技術を試してみたり、その技術を使って社内ツールなど、実際に使われるものを作ってみたり、ドンドンチャレンジしていこうと思います！！

皆が嫌いな英語

こんにちわ。最近フィリピンのタガログ語を片言ですが理解できるようになってきました岡安です。

フィリピン事情について語る連載記事の2つ目です。

  1. 私が感じるフィリピンという国。<前編> <後編>
  2. 皆が嫌いな英語。 <- 今日はここのお話です。
  3. マニラで進めているプロジェクトや、現地のIT開発会社について。

日本国外で仕事をする上で、英語もしくは現地語の修得はほぼ必須と言っても過言ではありません。 中には日本語だけでという稀な例もありますが、現地での生活も含めると現実的には厳しいと思われます。 よく駐在員だという話をすると「すごーい！英語ペラペラなんだね」と言われますがそんなことはありません。

今の私が英語でできること。

  • メールのやり取り。
  • 業務会議。
  • 外部業者との調整。
  • 電話。
  • 同僚や友達との冗談含めた会話。
  • 役所や買い物など普通の生活。

よく詰まりますし、辞書引くことも多いですが概ねできます。TOEICの模試は十分な個人的に満足する点数取れました。しかしネイティブには程遠いなぁと思います。 言葉に詰まることはあまり無くなった気がします。

中学〜高校〜大学と英語の授業は必ずありましたが、自慢ではありませんが英語の単位習得はギリギリの成績であり、自分でもなぜ授業をパスできたのか不思議でなりません。 特に高校の英語の授業は成績が悪すぎて居残りの常連でした。

というのも、私は日本で生まれ日本で生活するのに英語を修得する理由がさっぱり理解ができなかったからです。

30歳の頃、私用でヨーロッパに行く機会がありました。2度めの海外です。1度目はツアーでしたので団体行動ばかりで会話の必要はありませんでしたが、その時は初めての一人旅。 日本語は通じません。もちろん英語も話せません。 お金が無かったのでドミトリーに宿泊。すると相部屋になった女の子が話しかけてきて暇なら一緒に観光しようと誘ってくれました。彼女は香港から来たバックパッカーで年もほぼ同じ年でした。 結局2日間、彼女と行動を共にすることになり、つたない英語というより単語を駆使してコミュニケーションをしようとするものの、多分ほとんど通じていなかったと思います。 彼女はとても熱心に僕の言葉を理解しようとしてくれていました。

用事も済み、帰国の途についた私は飛行機の中でとても悔しい思いをしました。 「なぜ英語を勉強してこなかったのだろうか。」その時に英語を勉強する理由を見つけました。 世界にこれだけの人がいるのに、ほとんどコミュニケーションを取れないその苛立ち。それが英語を始めるきっかけになりました。

通常ここで日本の英語学校に行く事を思い浮かべますが、お金が無いのでそれはパスしました。 その中でいくつかトライしたものをご紹介します。ご参考程度にですが。

英語の本を読む！（★）

好きな映画の英語書籍を数冊取り寄せました。数ページ読んで挫折です。苦でしかありませんでした。 ある程度文章が読めるようになってからでないと挫折します。もう少し覚えてからですが新聞のほうが読みやすいです。短い文章で完結しますので。

ソーシャルメディア（★★★★）

当時外国人の友達とコミュニケーションを取る為にFacebookを始めました。元々の目的はそうだったのですが日本でも流行し、日本人の友達も増えましたが、元々は英語だけでFacebookの投稿やコメントを書きなるべく日常的に英語に触れる機会を作りました。8年程英語と日本語で投稿しています。

ボランティアの外国人向け観光ガイド（★★★）

言語ですから話をすることは必要不可欠です。でも日本で英語を話す機会なんてと思って見つけたのは東京を観光する外国人のボランティア団体に2年間所属しました。 メールも英語、ガイドも英語。ここ自体で英語力を修得するわけではなく、伝えられなかったことをどう表現したら伝えられるのかという課題を作ること。その課題を家で勉強する事。それとヒアリング力を高めることが出来ました。 副産物としてここで何人も友達ができました。しかもタダです。

海外ドラマ・映画を見る。（★★★）

テレビドラマの発音は滑舌も良く、ネイティブの発音がリアルに聞けるので有効です。英語の字幕をつけるのが大事です。はじめは何言ってるかわかりませんが、何度も見た映画を英語字幕にして見るようにしました。子供向けアニメのほうが若干表現が難しくありません。 じっくり見ることもありますが、はじめは耳を慣らすために流してるだけでいいと思います。 今は字幕があれば比較的ストーリーを追いかけられるようになりました。 好きなドラマはBreaking BadとSHERLOCKです。 今でも海外ドラマは好きでよく家で流しています。

英会話の学校（★★★★★）

やはり最後はプロに習うのが一番良かったです。マニラに赴任して非常に格安でレッスンを週に2回。1回2時間を受けるようにしました。約1年間続けることでボキャブラリー、英単語、ヒアリング力、発音全てにおいてレベルアップしました。やる気が無い時は先生をいじって遊びました。もちろん英語です。 少し覚えてくるとビジネス英語が不安になってきます。ここはやはりプロに習うのが一番でした。日本だと高いですがマニラだと格安です。英語の先生は大変厳しい方ですが。

友達と飲み会（★★★★）

間違ってもいいので話すべきです。でもその勇気がという時に少しだけお酒の力を借りると躊躇いがなくなり、話せる勇気が出来ます。相手が解らないという顔をしたら、別の表現で言い直せばいいのです。友達なので間違ってもいいですし、コミュニケーションの取り方は格段に成長します。

旅に出る。（★）

意外と使う単語やフレーズは限られてますので成長は見込めません。

海外で出会い、きっかけをくれた彼女は今でも連絡を取り合っていますし、香港や日本で前よりもマシに会話ができるようになりました。 私には好奇心と意思疎通をしたいという欲求で英語を覚えました。友達とは困らずコミュニケーションが取れます。ただ、ビジネスの世界になると厳しく要求がされます。 それと年を取ったら覚えられないという事はないという事を合わせてお伝えしたいです。

多少できる。で海外住んでしまって大丈夫です。そこから必死に覚えますので。 それに子供だって言葉を覚えていると考えたら少し気が楽になりませんか？ 「間違えていいも大丈夫」僕はこれに怯えていた期間が長すぎた気がします。

最後に世界中に友達ができるととても楽しいということをお伝えさせていただきます。 いつか海外の友達全員の住んでる土地にお邪魔しにいくのが夢です。

英語苦手だから…と諦めている方がいたら、是非興味のある分野でトライしてはいかがでしょうか。

「第5回 Machine Learning 15minutes!」で発表してきました。

こんにちは、ALICEチーム*1の白木です。

2016/10/22(土)に第5回 Machine Learning 15minutes!が開催され、発表してきましたので、その発表内容と感想についてショートに報告します。

f:id:shirakiya:20161024172019j:plain

Machine Learning 15minutes!とは

Machine Learning 15minutes!は、その名の通り「機械学習」を中心に、ビジネスへの応用例や技術の部分について15分以内の発表を行い、知見の共有を行うイベントです。個人的には「事例を知ることができる」こと、懇親会を通して人のネットワークが広げられることが魅力的なイベントです。（実際にこのイベントの懇親会で色んな方と出会うことができました。皆様、これからもよろしくお願いします！）

発表

今回、私は「経験ゼロのWeb企業が機械学習に取り組んだ話」と題して、企業として、また個人として機械学習とは無縁だった状態から、約半年間取り組みを行った中で得られた「重要だったこと」を事例紹介・知見共有的に発表しました。
スライドは以下をご参照いただくとともに、国内の人工知能専門メディアのAINOWさんでもイベントレポートがありますので、ご覧いただければと思います。

↓ AINOW 第5回 Machine Learning 15minutes! イベントレポート
ainow.ai

内容について

今回発表した内容は、特に重要と感じた、以下の5項目です。

  1. 「今を知る」情報収集
  2. 高速で仮説検証を回す
  3. すぐに成果を求めない
  4. 教師データ作成のフローを作成する
  5. 目標を明確に定義する

「今を知る」情報収集

機械学習初学者の方は「何から手をつければいいのかわからない」と一度は思われたと思います。
そこでオススメするのが、片っ端から情報収集すること。
ディープラーニングはまだ新しい技術で、2006年にヒントン先生がブレークスルーを果たした後、話題になったのは2012年のILSVRCなので、今からの世の中の情報を抑えておくだけでも、その適用範囲・使い方の情報等がたくさん出ていると思います。そうした情報を自動で収集して、Slackにバンバン送るということをしました。

ちょうど話題にもなっていることもあり、世の中的に初心者向けの記事や、発展的な内容の記事、新しいアルゴリズムに関する記事、適用事例に関する記事等がたくさん出されており、何から手をつければいいのかわからないという状況から、今の課題に則した技術選定が行える状況になれると思います。

高速で仮説検証を回す

機械学習の経験が無い状態だと、進める中で発生する課題（例えば精度が出ないとかデータセットをより効率的に集めたいなど）が出てきたときに、その課題に対する解決策が、すぐにはわかりません。そうした課題の解決策の中には既に論文の中で紹介されているものがあるかもしれませんが、実際問題、該当の論文をすぐに探し出すのも慣れていなければ難しく、今直面している課題に本当に適用可能なものかの確証を得るのも難しいです。

そこで「何をやろう」「どうしよう」とアレコレ迷う前に、実際に自分の手で解決策となりえる仮説を立ててやってみる、つまり高速でPDCAを回すのが良いです。
やってみる中で、やってみた施策に対する結果を比較して見ることにより、その因果を経験的に学ぶことができますし、さらにその施策を行う中で機械学習ライブラリツールの使い方も覚えられ、次のPDCAがさらに高速で回せるようになります。

すぐに成果を求めない

機械学習はとにかく時間がかかります。機械学習エンジニアが実作業として行うべきことは以下のものが考えられます。

  • インプット: アルゴリズムの学習、情報収集、ライブラリとその使い方を調べる、写経する 等
  • 実作業: 実装、学習(Train)、学習結果の評価・考察 等
  • アウトプット: 経験による暗黙知を形式知化するための文章化・資料化
  • さらに: 精度向上を狙ってあの手この手をする

（※実際に経験したものを列挙してみたので、他にもあると思います。）

これらの作業は絶対的に必要で、しかも機械学習は必ず上手くいくというものではなく、精度を実サービスで使えるまでに相当な時間がかかってしまいます。また、機械学習は用意できるデータセットに影響される部分が大きく、精度を出すために、もう一度データセットを精査・取得しないといけない等も考えれます。なので「長い目で待つことは想定の内に入れておく」ことが求められます。
（発表後日、「ただし、中長期的な成果はゴリゴリに求める」と上司に言われて「ヒエッ」っとなったのはいい話）

教師データ作成のフローを作る

この話はプロジェクトで「教師データ」を必要とし、さらにアノテーション作業を行わないといけない場合に限定した話です。

教師あり学習を行う場合では、教師データは絶対的に必要になり、その作成には時間がかかることが多いです（こうした課題に対して、教師データを自動生成するという取り組みもあります）。
エンジニアには技術的な作業に集中して欲しいし、一方で、何度も言いますが、教師データは必要なもので、人の手によるアノテーション作業は一度だけとも限りません。教師データが精度に与える影響が支配的な機械学習では、アノテーションのルールが悪くて精度が悪いだとか、そもそもアノテーション作業の精度が悪いなどのケースがあったり、データを追加するためなどの理由から、複数回発生したりします。

そこで、業務フローとして、予め教師データを作成するフローを作成しておくことがオススメです。
弊社では、投稿監視作業などを行うメンバーに協力してもらって、アノテーションルールを明確に記載したルールブックを渡すと共に作業を依頼しています。アノテーションルールが最終的な精度に与える影響が大きいことがわかっていますので、そのルールは誰がやっても同じようなアノテーションができるように細かに定義しています。

目標を明確に定義する

取り組み当初、弊社では取り組みの目標を「〇〇な画像を自動分類し、ソリューションとして提供する」として、分類器開発を行っていました。
開発を進めていき「再現率90%、適合率60%の分類器ができた」のですが、ここから次の開発方針を決めるのに苦戦しました。精度を上げたいという思いはありましたが、やみくもに精度を上げるといっても、そこに優先度が無いと方針を決めるのは難しいです。

そこで、検討を行い、目標を「〇〇という戦略で、△△な企業に対して、□□というソリューションを提供する。そのためには、最低限の性能として再現率80%以上、適合率は70%以上の性能を持った分類器が必要だ」と詳細に決めました。
このような詳細な目標設定がなされたおかげで、「次の改善の方向性として、現状は目標に対して再現率は高くて適合率が低い状態なので、クラス判定の閾値設定をもう少し厳しめにしてみよう」と考えることができました。
Web開発では「こんな機能が欲しい」に対して「できた」or「できない」のゼロイチの世界ですが、機械学習は精度100%は不可能なので、ゼロイチで考えることができません。なので、詳細に目標を定義する必要があるわけです。

さいごに

スライド後方にもありますが、これらの話は改めて考えるとこれらはおおよそ「仕事をする上で重要なこと」であって「機械学習に限った話」でもなかったりするんですよね。でもいざ取り組んでみると意識の外にいってしまうことでもあるしで、 当たり前を当たり前だと言う ことは重要だと思っています。 今後、個人・会社で機械学習を用いたプロジェクトを始められる方々にとって、何かのお役立てができていれば幸いです。

アディッシュ技術開発部では、今後も取り組みの中で得られたことを積極的に社外へと発信していく所存です。（このブログもそうですが）
逆に発表できるだけの技術や知見をどんどん溜めないとですね！よし、やってくぞ！

*1:ALICEチームとは機械学習に関する開発を行っているチームです。アディッシュの技術開発部のチーム構成については以前投稿した記事をご覧頂ければと思います。

3Q（7月～9月）の成果報告会を実施しました

はじめに

　皆さんはじめまして。adish技術開発部.雪風チーム所属の田原と申します。
　前回の掲載から随分時間が経った気もしますが...それは気のせいということで。

　さて、adish技術開発部（以下TEC）では、四半期毎(1Q毎)に成果報告会があります。 これは以下を目的として、2015年より実施しています。

  • 前Qを振り返りの報告
    • 自分のやってきた業務
    • 新しく知見を得た技術
    • 熱い思い（？）
  • プレゼンテーション技術の向上
  • ドヤる

　今回は、10/14に行われた、3Q（2016年6月〜2016年9月の活動）の成果報告会について、勝手ながら私の印象に残ったトピックを、印象に残ったスライドとともにピックアップしてレポートします。 なお、諸事情によりスピーカーの写真がない状態ですが（ただ単に撮ってないだけ...）、弊社を含むガイアックスグループは「佐藤健率」が高い人が多かったらしいです（社内技術展示会「さきがけ展示会」を開催しました - Gaiax Engineers' Blog）。 なので、ここはひとつ、いろんな佐藤健（？）の顔を思い浮かべながら、以下ご覧いただければと思います。

発表順はbotで決めます

　ところで、「発表順を決める」場合にどんな方法を採りますか？ 　昔だと「じゃんけん」とか、人数が多ければ「あみだくじ」とか、サイコロとかもあるのかな... TECの成果報告会では、『Software Design』にも登場したことのある「gaiachan」というbotに決めさせてます。

f:id:tech-adish:20161019165052p:plain

　ちなみに「gaiachan」は、順番決め以外にも、いろんなことができます。 詳しくは、雑誌『Software Design 2016年1月号』をご覧ください。

Software Design 2016年1月号｜技術評論社
第1特集「はじまっています。ChatOps」
Case5:組織にChatOpsを根付かせるために～GaiaxのChatOps実現までの軌跡～

iOSアプリ開発者が、Webアプリの開発をやってみた話

　gaiachanに指名された、トップバッターは片山さん。TEC唯一無二の、iOSアプリ開発エンジニアです。その片山さんが、iOSアプリの開発から離れ、WEBアプリのメンテナンス開発をすることになった、そのときの思いを語りました。

f:id:tech-adish:20161018184846p:plain

　...その苦労わかります。
　WEBアプリの開発経験のある方はご存じだと思いますが、開発環境を構築する場合に、サーバーを１個たてることから始めますよね。 今はVagrantなどもあり、サーバー調達の敷居は低くなりましたが、それでもNginxやMySQL他必要なミドルウエア、そしてPerl,cpanモジュールなどアプリ開発用言語など、いろいろインストールしなければなりません。 ansibleなどのプロビジョニングツールを使用するにせよ、最初は何のどのバージョンをインストールするか、セコセコ書いてあげなければなりません。 新規開発ならともかく、メンテナンス開発の場合、稼働中のものにバージョンを合わせる必要があるが、時間が経ってると、そのバージョンがなかったりとかで、当時の環境構築手順のドキュメントに沿ってやったとしても、うまくいかない場合がままありますよね。 エミュレーション環境もエディタもUI開発支援も全て揃ったXcodeは確かにすごいですよね。

Perlプログラミングを学ぶのに最適な本

　続いては私、田原が、３Ｑ業務の振り返りと、最近思ったことを話しました。
　iOS10にアプデしたら、ロック解除が変わってイライラした話とかありますが、ここはポジティブに。最近感動したのは、『雅なPerl入門』という本です

f:id:tech-adish:20161019172246p:plain

　私も、ラクダ本とかリャマ本とかロングテール本（最近そんな呼び方があるんだって知りました）などを、安くないお金を出して、重たいのでヒーヒー言いながら持って帰ったりしてましたが、たぶん実際に読んで役に立った部分をまとめると、この本の薄さになるんでしょうね...それくらいよくできてます。初心者の方はもちろん、重たい本で学んだ中級以上の人も、知見の整理に是非読んでみてください。
えっ！？非売品...残念。
　先輩や知り合いのPerlエンジニアに頼んで、みせてもらいましょう...

google apps Scriptのお作法

　続いては、本ブログの5回目「adishの技術開発部とは」にも登場しました、井上さんの発表です。 井上さんからは、「Google Apps Scriptのお作法」のお話しでした。

f:id:tech-adish:20161019105003p:plain f:id:tech-adish:20161019105021p:plain f:id:tech-adish:20161019105045p:plain

　ExcelVBAと比べると、まどろっこしくてわかりにくい書き方だな、なんて思いましたが、クラウドである以上、APIリクエスト回数とかやりとりするデータ量の爆発は、ユーザーにとってもgoogleのサービスにとっても致命的になりますからね。納得。

UI/UX改善の話

　続いて登場は、その生意気さ貫禄とスキルレベルに、もう5年目くらいかと思っていたら、まだ2年目だったという坪井先生です。
　先ほど片山さんのときに「唯一無二のiOSエンジニア」といいましたが、実は坪井先生も書けるみたいです。最近はReact.jsがお気に入りみたいです。
　さらにはRailsもPerlも使えるマルチリンガルプログラマです。ちなみにPerlはあまり好きじゃないみたいです。
　そんな坪井先生の発表で印象に残ったのは、先日プレスリリースもありましたhitoboのスタッフが使用する画面のUI/UXの改善のお話しでした。

f:id:tech-adish:20161019173247p:plain

　何でもかんでもすぐに対応してしまうのはよくないと思いますが、「なるべく要望はすぐ叶える」という姿勢は大事だと思いました。あと、「１画面で完結するを掲げる」というのもいいですよね。
　最初にこういったポリシーを決めて作業をするという姿勢にすごく共感しました。

プレゼンテーションを成功させるための４つのポイント

続いては、スーパーママエンジニア、菊池さんの発表です。 最近はブロックチェーンに関するプロジェクトに携わっており、先日、その知識を見込まれて、SMART CONTRACT CONFERENCE 2016にも、スピーカーとして登壇しました。 そんな、菊池さんからは、大舞台での経験を元に、プレゼンテーションを成功させるためのポイント４つについて、発表がありました。

f:id:tech-adish:20161019105148p:plain f:id:tech-adish:20161019105200p:plain f:id:tech-adish:20161019105220p:plain f:id:tech-adish:20161019105230p:plain

1. 構成を見直す

　スライド資料を作った後で、その流れで言いたいことが伝わるかとか、前置きの紹介が長すぎないかとか、盛り上がりとか、第3者の立場で見てみる

2. 練習する

　トータルな時間はもちろん、ひとつひとつのスライドにかける時間とか、間とか。壇上にあがってやる場合は、身振り手振り目線の配り方などの立ち居振る舞いを、実際にやってるつもりで練習する また、壇上でやる場合、スクリーンから離れると見にくい場合もあるので、フォントと文字サイズは大事

3. 準備する

　ノート（カンペ）はプリントアウトして持っておく。いざとなったらカンペを読めば、最低限プレゼンは進行する（真っ白になってとまらない） ...という準備と心構えが、大舞台での安心感、緊張を抑えることにつながる。

4. 基本が大事

　別に特別なテクニックはいらない。基本が大事。

　巷には、パワポの使い方を初めとする、成功するプレゼンテクニックに関する本や情報があふれてますが、なかなか覚えきれないし、覚えて実施しようとしても大変ですよね。 とりあえず４つ押さえておけば、大舞台でも大丈夫。いいですね。 ちなみに、テクニックでいうと、アニメーションの使い方。パワポはいろいろアニメーション効果がありますが、

  • 聴衆の先読みを防ぐためにも、アニメーションは使うべし
  • ただし、いろんな効果を使うのではなく、フェードもしくはスライドインだけでいい
  • 伝えたいポイントは、別スライドにして、フェードやスライドインとは別のアニメーション効果にするとよい

ということです。 プレゼンで悩んでる方は是非参考にしてください

機械学習の成績を劇的に改善！

　続いては、本ブログの４回目「adishにインターン生としてjoinしました！」にも登場してくれた、インターン生の岩渕さんから、「画像認識のディープラーニング」に関して、検出の成績をあげるための試行錯誤に関する話がありました。

f:id:tech-adish:20161019173126p:plain

　この表だけでは、何がどうなのかよくわからないと思いますが... 理論的な詳しい話とか、追試のできる技術的な話とかは、また別の機会に岩渕さんから本ブログで発表してもらうことにしましょう。 ちなみに、この赤い数字の部分は、とある方法によって成績が劇的に上がったということですが、そのやり方は「夜突然のひらめきが降りてきた」らしいです。 んーっ、セレンディピティ...

プロジェクトあるある/運用あるある

　続きましては、仏の顔無制限のやさしきエンジニア西谷さんより「運用しているといろいろありますね」ということで、3Qのシステム運用業務の中での、いろいろ困ったことを発表されました。

f:id:tech-adish:20161019081108p:plain

　技術だけではどうにもならないこと、「私」の力だけではどうにもならないこと、システムを運用していると、いろいろありますよね。 読者の方の中にも、そういった「あるある」経験あると思います。 いろいろ都合もありますので、詳しくは書けませんが...

React.jsとCSSに挑む

　さて、お次は、私と前述の良書『雅なPerl』とを巡り合わせてくれました、白木さんの登場です。
白木さんは本ブログの2回目と3回目を執筆しています。
PythonでBing Search APIを使って画像データを集める方法
ITエンジニアのためのDeepLearning #6 レポート

　先に発表した岩渕さんの師匠でもある、白木さんなので、ここはよくわからない興味深い機械学習の話かと思いきや、先ほどの坪井さんと同じhitoboのスタッフの方が使用する画面の開発をすることになり、React.jsやcssとお付き合いするようになった話です。 白木さんは「React.jsは触ったことない」「cssはそこらへんの大学生レベル（どんなレベルだ？）」ということで、これではイカンということで、以下をかかげて自主練したそうです。

f:id:tech-adish:20161019081825p:plain

　さきほどのプレゼンの話もそうですが、やはり不得手だけどやるしかないってときは、自主練あるのみですね。 　ちなみに私は「else if」なのか「elsif」なのか「elseif」なのか、あと「leaveとlast」とか「continueとnext」とか、ごっちゃになるときあります。 この辺言語を作った人の思想が表れている？

業務改善/愛ある採用

　続いての登場は、adish のフィリピンオフィス（adish international）バナナチームのボス、岡安さん。本ブログの6回目、7回目に記事を書いてくれてます。
2016-08-25 私が感じるフィリピンという国 (前編)
2016-09-02 私が感じるフィリピンという国 (後編)

岡安さんの発表で印象に残ったトピックはこれです。

f:id:tech-adish:20161019181923p:plain

　SASとは、本ブログの第１回目「エンジニアブログ始めました」にあるソーシャルアプリサポート事業（Social App Support）のことです。
TAHMS（タムスと発音）とは、SAS事業に携わるスタッフの方たちが使用する稼働管理システムのことです。このシステムは岡安さん率いるフィリピンオフィスの開発チームが作りました。 開発者にとって、みんなが使ってくれているということが、一番の喜びだと思います。
　私も、直接TAHMSを使ってるわけではないですが、TAHMSより出力されたレポートを見せていただいて、大いに役立つことがありました。
　稼働管理状況を「WORK（作業中）」「REST（休憩中）」「ETC（その他）」「BLANK（未入力）」というカテゴリで色分けしてグラフが出せるみたいなのですが、そこで６チームのグラフを比較した際に、他の５チームに比べてBLANKが突出してるチームがありました。事情をヒアリングしてみると、特殊な運用業務フローのために業務過多になっているということでした。
　TAHMSのような稼働管理システムは、いろいろな所で使われていると思います。未入力が多い場合には「未入力を減らそう」みたいな感じのアクションを取るのが一般的だと思います。導入間もない場合は、それもアクションとして正しいと思いますが、横並びで比較して突出している場合、「なぜ未入力が多いのか」について深く掘り下げることが大事であると、気づかされました。
　あと、新しく採用した４人のメンバーについての紹介がありましたが、なんか愛を感じられてよかったです。ほっこりしました。

Perlエンジニアとしての矜持に感銘

トリをつとめたのは、福本さん。@papixと言ったほうがわかる方も多いのではないでしょうか。 歳は親子ほど離れてますが、私もリスペクトしているPerl Mongerです。

そんな福本さんの発表で印象に残ったスライドはこれです。

f:id:tech-adish:20161019113747p:plain

Perl向けにマイグレーションツールや、ActiveRecord的世界観を提供できるスキルがあるのが、単純にうらやましいです...。
ところで、これに関して面白いやりとりがありました。

坪井さん：「そこまでやるなら、Rails使ったほうがいいんじゃないですか？」
福本さん：「...そんな無粋なこと言わない...」

...そう、無粋なんですよ...。その気持ちよくわかります。

こだわりのある出張料理人が、出張先で万能包丁を使うのではなく、わざわざ自分の使い慣れた包丁を持ってきて料理することと、同じ感覚ではないでしょうか。
福本さんのPerlエンジニアとしての矜持を垣間見て、感銘を受けました。
（ほら、Rubyistの方もcron使わずにwhenever使ったりするじゃないですか...。今はちがうのかな...）
※あくまで個人の主観です。正しい/正しくないの問題ではないのでご了承ください。

　さて、こんな感じで、成果報告会のレビューの中から、私が独断で印象に残った各メンバーのスライドと発表内容をピックアップして、レポートさせていただきました。
　より突っ込んだ、参考にできるレベルの技術的な話などについては、また別の機会にでも、各メンバー（私も含め）に書いてもらいますので、乞うご期待。

私が感じるフィリピンという国 (後編)

adish のフィリピンオフィス（adish international）に勤務する岡安と申します。
前回に続き、今回もフィリピン情報をお伝えします。

f:id:adinoue37:20160823175736j:plain
  1. 私が感じるフィリピンという国。 <- 今日はここの後編
  2. 皆が嫌いな英語。
  3. マニラで進めているプロジェクトや、現地のIT開発会社について。

治安は？

渡航前に友人や家族から心配されたものです。当の私も知識が無く不安でした。
実際は悪いところもあればそうでもないところもあります。
ただ、「何と比較するか」であり、東京と比べたら悪いです。フィリピンの中には東京よりも治安の良い地域もあります。

物価は？

（執筆時のレートです）
国産品は安いですが、輸入品は日本よりも割高に感じます。
国産で安いものとして、移動代は日本の都心のバスを200円だとすると近距離のジプニーという乗り合いバスで15円、タクシーは渋滞にもよりますが10キロで300円位。野菜は高地で取れるので若干高め。ビールは70円程度。タバコは130円程度。生うには市場ですが1キロ1800円です。ココナッツは1つ100円程度で買ってますが、それでも田舎に行けば安いと言われます。アメリカの映画が日本より1ヶ月早く封切り、しかも500円くらい。（ただし字幕なし）

高いものは、日本でも有名な大手アパレルメーカーの衣類などの外国製品、ラーメンが1000円程度、電気代は日本と同じで収入比に比べ高いです。
ワインや乳製品はとても高く、物ではありませんが所得税も高いです。ガソリンは日本より2割安いですが物価感覚を考えればとても高く感じます。
あとホテルは東京よりも少し安い程度でとても高いです。

その他のフィリピンという国について

書ききれないので少し雑になりますが以下のようなものも。

カルチャーショックだったこと

  • 9月にメリークリスマスと言われ、12月はテンション高すぎて仕事にならない。
  • すごーく日本のアニメ好き。
  • 給料が月に2回。1回だと月末までに使いきっちゃうから。
  • スプーンとフォークで食事。
  • 全員がちゃんと英語を話せるわけではない。学校で勉強した人だけ。
  • フィリピン人はほぼ泳げない。学校で習わない。
  • 誕生日の人が周囲におごらないといけなく、逃げる為に誕生日に休む人も。
  • LGBTにとても寛容。ただ祖父母世代は駄目みたい。
  • お葬式は一週間かけて盛大に宴会をする。
f:id:adinoue37:20160823175827j:plain

意外と良いところ

  • 優秀な人材を日本より採用しやすい。
  • 会話が英語で全部済む。
  • ビールを5本程度頼むと、1本おまけされる。
  • 地方の海がとても綺麗。しかもまだ荒らされていない。ただし遠い。
  • どこでも英語表記だし、英語が話せれば生活に困らない。
  • 思ったより和食屋がある。
  • 利用したい通販サービスが無いのでお金を使わなくなった。
  • 花粉症がない！
  • 近隣のアジア諸国に短時間で安く行ける。
  • 日本と時差が1時間しかなく、あまり遠くない。
  • 夏服だけなので荷物が少なくて済む。洗濯が楽。

辛いところ

  • 空港がすごく混む。経済発展を反映？
  • 渋滞が辛い。通勤ラッシュ時は車の移動を諦める。
  • インターネット（回線、携帯）が遅くて高くて辛い。
  • お役所の対応が遅い。プロバイダーも。
  • 急に公的な休みが決まる。1週間前とか。
  • お一人様席が基本存在しない。一人でレストランに行くと辛い。

結局どこでもコミュニケーション

人との接し方については苦手ながらに最大限気を使う努力を怠りません。
この国では私は外国人ですし上司だからとか年上だからって威張ってはいけません。あくまでもこの国の人々をリスペクトして仕事をさせてもらわなければなりません。当然この国のルールには従わないといけないしましてや日本ではこうだ！なんて事は絶対に言ってはいけません。
また、彼らはとてもナイーブな性格の持ち主が多く、とても傷つきやすいですので問題があった時もやんわり理由を親身に聞くことを心がけてます。

今私が感じること

過去にMade in Japanがもてはやされた時代がありました。よく考えると先人が妥協をせず物作りに励んだ結果だと私は考えます。
私は他国でそれが出来ないとは思っておらず、一生懸命仕事すれば、国も人種も関係の無いどこでも可能だと考えます。（ノウハウの蓄積はあると思いますが）

今は渡航前に目的としていた「組織でシステム開発」が順調に出来るようになり、ようやくスタート地点に立てたところです。これからどんどん仕事を進めていける事に 喜びと興奮を自分に感じてます。
また、将来今私と仕事をしてる彼らが、仕事をしっかり覚え、外国人が主導ではなく彼ら自身でビジネスができている状態がいつか来る日を夢みています。

次は海外での仕事で切り離せない「英語」についてフォーカスを当てます。
ちなみに私の英語レベルは高校で赤点（落第）取ったレベルです。
その観点からおこがましくはありますがご説明させていただきます。