お久しぶりです。 半年ぶりになってしまった 技術基盤部の相原( kaihar4 )です。 今回は、私が入社した直後あたりから続いている社内勉強会のTech Talk Lunchについてと、そのTech Talk Lunchを長く続けていくために取り組んでいる仕組みの紹介をしていきたいと思います。 Tech Talk Lunchとは 長く続けていくための仕組み トピックを限定しない トピックは持ち寄り ランチタイム開催 社内勉強会を続けるメリット 技術的視野の広がり 他部署との関係構築 発信の習慣化 情報収集の習慣化 さいごに Tech Talk Lunchとは Tech Talk Lunchとは、その名の通りお昼に開催される私が知る限り社内でも有数の長く続いている定期開催の社内勉強会です。 毎週月曜日の13時から14時までの1時間、前の週の最新ニュースを中心に各自がトピックを持ち寄り、1人5~10分程度を目安に持ち寄ったトピックを自由に共有します。 持ち寄るトピックに制限はなく、現在でもビジネス的なものからアカデミックな論文の紹介、土日に読んだおすすめの技術書に面白いウェブサービスの紹介まで、様々なトピックが共有されています。 また、共有形式もスライドを用意するといったことはなく、大抵はウェブページを見ながらであったり、用意していても簡単なメモ書き程度で、緩く共有するというコンセプトとなっています。 最初はチームのメンバー3人でスモールスタートしたTech Talk Lunchも、こうした開催方法を続けた結果、それほど大きくない会議室で開催しているものの毎度満員御礼となり、参加者も新卒1年目からベテランエンジニアにマネージャまでと幅広く参加する社内勉強会となりました。 長く続けていくための仕組み ここからは、このTech Talk Lunchが長く続くために取り組んでいる3つの仕組みについて紹介していきます。 トピックを限定しない 一つは、トピックを限定しないという点です。 Slackなどの特定コミュニティで顕著な現象として、トピックごとにチャンネルを分けることによって話題が分散し、それぞれのチャンネルでの絶対的な発言数が減少するというものがあります。 そこで、そういった参加者の分散による過疎を防ぐため、Tech Talk Lunchではトピックを限定しないという方式を取っています。 エンジニアそれぞれの得意な領域によって情報収集手段が異なることに加え、技術情報とは誰がそのニュースについて言及しているかによって情報の価値が異なります。 自分が流し読みしてしまう技術情報も、その分野のキャッチアップをしている人にとっては価値のある情報であることが多くあります。 そういったことから、Tech Talk Lunchではトピックを限定しないことによって参加者の間口を広げ、自分の情報収集手段では知り得ない情報・知り得ない価値を得られるというコンセプトとなっています。 その結果として、ビジネス的なものからアカデミックな論文まで多様な技術情報が集まる社内勉強会となり、多くの参加者を確保することに成功しました。 トピックは持ち寄り Tech Talk Lunchでは特定のスピーカーというものは存在しません。 トピックは参加者それぞれが持ち寄り、決められた時間ごとに交代で共有しています。 これに関して懸念したのは、スピーカーへの負荷の集中によって運営継続が難しくなることです。 1回1時間とはいえ、持ち回りでスピーカーがトピックを用意することは難しく、必然的に頻度を減らす必要が出てきてしまいます。 また、Tech Talk Lunchにはそれぞれが能動的に技術情報を収集してほしいという想いがあることから、トピックを各自が持ち寄るという決断をしました。 人に対して物事を説明するには、情報のインプットのみで終える時に比べて高い情報の理解度が求められます。 そういった機会を、普段人に説明することがない人にも提供することで、社内の情報共有が活性化されるという効果も見られました。 加えて、持ち寄ることのハードルを下げるため共有方法は自由としており、多くの参加者は事前にトピックのURLを用意だけして当日に臨みます。 結果として、スピーカーの負荷が軽減されることで安定した運営が実現され、活発に情報を共有する文化が醸成されました。 ランチタイム開催 次はランチタイムでの開催です。 弊社では基本的に13時から14時までの1時間が休憩時間として確保されています。 Tech Talk Lunchではより多くの人が参加しやすいよう、この時間を使ってランチを食べながらカジュアルに開催するという形式を採用しています。 これ以外の時間に開催しようとするとどうしてもコアタイム後の16時以降となり、業務都合や私用で参加できない人が多く出てしまいます。 また、長時間の勉強会となると途中退室が可能なものの、拘束時間が長くなってしまいますが、1回の開催時間が1時間と短いため、参加者の心理的障壁も下げられ気軽に参加できるような環境になっていると考えます。 1回の開催時間が短い点に対しては頻度を上げることによって対応しており、取り扱うトピックが最新ニュース中心ということから、毎週月曜日に開催するようになっています。 これにより参加者の情報収集が習慣化され、参加者の情報感度が高くなるという効果が見られるとともに、常に鮮度の高い情報が得られるようになりました。 この仕組みによって毎回安定した人数を参加者として確保することができ、長く続けていくことに寄与しています。 社内勉強会を続けるメリット Tech Talk Lunchを長く続けることで社内勉強会を続けることによるメリットが見えてきてました。 技術的視野の広がり 私が特に強く感じているのは技術的視野の広がりです。 Tech Talk Lunchではアカデミックな情報も活発に共有されており、中でも機械学習のトピックは技術トレンドも相まって頻出トピックの一つです。 今まで遠くに感じていたアカデミックな分野も、気軽に質問できる環境が作られたことによって身近に感じられ、今ではプライベートでのソフトウェア開発に用いるようにまでなりました。 これにはかなり強くTech Talk Lunchが影響していると実感していて、インターネットに溢れる玉石混合の情報の中から、専門家の意見を直接聞くことができるというのは非常に大きなメリットでした。 カジュアルに共有するというコンセプトのため、気になったことを気軽にその場で質問できるような雰囲気であることもプラスに働いています。 他の参加者の中にも、ここで得た知見を業務に適用している例があり、特定のトピックに特化した勉強会でこうした体験をすることは難しいことを考えると、トピックを限定せずそれぞれが持ち寄るという運営形式の強みを感じました。 他部署との関係構築 次は他部署との関係構築です。 多様なトピックが集まることからわかるように、Tech Talk Lunchには様々な部署から様々なスキルセット・様々な役職の参加者が集まっています。 これにより普段あまり知る機会のない他部署の取り組みや、ベテランのエンジニアやマネージャの考え方などを知ることのできる貴重な機会にもなりました。 例えば、トピックとしてあがってきた他社の技術的取り組みについてベテランのエンジニアと議論したり、他社の評価制度の事例についてマネージャの意見を聞くというのは、普段の生活ではもちろんのこと他の勉強会でも実現は難しいと考えます。 これもトピックを限定せずそれぞれが持ち寄るという運営形式の強みと言えるでしょう。 発信の習慣化 次は発信の習慣化です。 会社内では人に技術的なことを説明するという機会はそれほど多くありません。 社内勉強会は多くありますが、発表資料の用意や技術レベルのハードルなどからどうしてもスピーカーは偏ってしまう傾向があり、多くの人にこういった機会がないというのが現状です。 その中でカジュアルに情報を共有する場であるTech Talk Lunchはそういった人たちの受け口としても有効でした。 事実私はそれほど外部での発表を行ってきませんでしたが、Tech Talk Lunchによって発信することの習慣化がされました。 また、多様なスキルセットの参加者が集まっている性質上、技術的コンテキストが共有されていないため、分かりやすく説明するということに非常に気が使われます。 こうした環境で発信を習慣化することによって、自身の理解が深まるのはもちろんのこと、発信することに対する心理的障壁も下がるといった効果が感じられました。 情報収集の習慣化 最後は情報収集の習慣化です。 私の今までの情報収集手段は翻訳などのなんらかの第三者によるフィルタがかかった2次ソース・3次ソースからがメインとなっていました。 その中で、毎週最新のニュースを収集する習慣がついたことにより、言語問わず意識的に1次ソースからの情報収集を行うようになりました。 他の参加者からも継続して情報が集まることで、常に身の回りに新しい情報が集まるようになり、技術的な引き出しが以前に比べて格段に増しました。 結果として、プライベートでのソフトウェア開発で最新技術を採用し、それを業務にも生かすという非常にいいサイクルが構築されることとなり、公私ともにいい影響が得られていると実感しています。 さいごに このように仕組みを工夫することによって、運営側に負担をかけることなく社内勉強会を続けることができています。 個人的にも参加することによるメリットを強く感じており、部署間の連携の強まりや技術力の底上げなど、組織として考えた時にも有意義であると感じています。 情報は発信する人のもとに集まるとよく言われます。 これはTech Talk Lunchが強く表していて、それぞれが発信することによってとても刺激的なコミュニティを形成することに成功しました。 とりとめがなくなってしまいましたが、そんなTech Talk Lunchと弊社では新たな仲間を募集しています。

こんにちは。 HOME'Sデザイナーで、4月で入社3年目になるshinoです。 今回は同期デザイナーの莉亜と「FLOWERS by NAKED」というデジタルアート展に行ってきたので、そのレポートをいたします！   FLOWERS by NAKEDとは 「日本で一番早いお花見を、日本橋で。」をテーマにしたイベントで、春一番が吹くと桜吹雪が舞い上がるストーリー性とインタラクティブ性のある空間のなか、生花・オブジェ・映像・香り・飲食など五感で花の新体験を楽しむことができるデジタルアート展です。 過去にNAKEDの別の展示を鑑賞したことがあったので、今回もとても楽しみにしていました！   イベントレポート 平日の夕方を狙って行ったので、空いていてゆっくり見ることができました。   会場の中に入ると、まず、桜舞う大きな本のプロジェクションマッピングがお出迎えしてくれます。 さらになかに進むと、たんぽぽの綿毛に息を吹きかける仕掛けや、美しい花々の映像、竹林と光の回廊などがあり、とても幻想的でした。 特に一番印象に残っているのは、展示のメインでもある桜のインスタレーションです！ 仄明るい桜色の照明に照らされた大きな桜のオブジェの下で、ドリンク片手に踊りを鑑賞し、テーマのとおり本当にお花見をしている気分を味わうことができました。   HOME'Sデザイナーは、HOME'SをはじめとするWEBサービスの運用開発をメインの業務としています。 業務上、こういったインスタレーションだったり、インタラクティブなアートに触れる機会が少ないので、とても良い刺激になりました。   ※写真は掲載許可をいただいています。   まとめ 前述したとおり、HOME'Sデザイナーは、HOME'SをはじめとするWEBサービスの運用開発がメインの業務です。 業務上、触れる機会が少ない技術や表現などは、自ら機会を作り出してどんどんインプットしていきたいと思います。   ちなみに、弊社では社内制度として、業務の枠を離れて、新たな技術や手法に取り組むことができる機会があります。   ①クリエイターの日 希望制かつ承認制で、四半期の最大7日間を使って研究・開発が行えます。     ②クエイティブアワード アイデアアワードとプロジェクトアワードの2部門があります。 特に、半期に1回開催される「アイデアアワード」はテーマに沿った「アイデア」を競います。   こういった機会を利用して、アウトプットもしていきたいと思います！     最後まで読んでいただき、ありがとうございました！  

MathJax.Hub.Config({ tex2jax: {inlineMath: [['$', '$'], ['\\(', '\\)']]} }) ; こんにちは、ＭＡＭ開発グループの椎橋です。 ＭＡＭとはマーケティングオートメーションの略で、マーケティングに関する機械学習アルゴリズムを作ったり、データ分析をして改善につなげたりしています。 今回は社内制度の クリエイターの日 を2日間利用して、社員旅行の班分けの最適化モデルを作りました。 以前はこの制度を利用してサーバ・ミドルウェアの勉強をしました。 nextdeveloper.hatenablog.com 弊社の社員旅行は多くの社員が参加し、最高に盛り上がる大イベントです。 社員旅行委員が予算の見積もりからスケジュールまで計画を立ててくれるのですが、 そのスケジュールの中にアクティビティと呼ばれるイベントがあります。 これは班に分かれて観光やスポーツなどを楽しむというもので、私は昨年そば打ちを体験しました。 複数あるアクティビティのうち参加できるのは一つだけな上に、人数の上限が設定されているために希望したアクティビティに参加できるかどうかは分かりません。 昨年は社員旅行委員が抽選と手動調整によって班分けを行いましたが、数時間かかったらしいので最適化モデルを作ることにしました。 データ抽出 まずは、計算に用いるデータを準備します。 Google フォームで社員の希望調査を行い、集計結果を以下のように変換します。 名前ID 性別 group_1 group_2 group_3 group_4 id_1 1 1 3 -1 2 id_2 -1 2 3 1 -1 id_3 -1 3 1 2 -1 性別カラムは男性なら1,女性なら-1を取るようにし、各アクティビティの希望順位をgroupカラムに記します。希望していないアクティビティには-1を割り当てました。 定式化 次にこの問題を数式に変換します。 定数 まずは定数を以下のように定めます。 説明 表記 参加する社員[人] $N$ 班(アクティビティ)の種類 $ M $ 班 $j$ の上限人数[人] $g_j$ 社員 $i$ の班 $j$ への希望度 $h_{ij}$ 社員 $i$ が男性なら 1, 女性なら -1 を取る $s_i$ $h_{ij}$は希望順位から算出した定数で、算出方法は割愛します。また、添え字集合を以下のように定義しておきます。 $$I \mathrel{\mathop:}= \{1,\ldots,N\}$$ $$J \mathrel{\mathop:}= \{1,\ldots,M\}$$ 変数 次に、問題を解くための変数を以下のように設定します。 説明 表記 社員 $i$ が班 $j$ へ参加するなら 1, 不参加なら 0 を取る $x_{ij}$ これにより、$x_{ij}$を任意の $i$, $j$ に対して定めることで班分けを一意に決定できます。 モデリング 上記を用いてモデリングします。 まず、$x_{ij}$は 0 もしくは 1 を取る変数で、参加できる班は 1 つのみであることから、 $$ x_{ij} \in \{ 0, 1\},\ \forall i\in I,\ \ \forall j \in J $$ $$ \sum_{j \in J}{x_{ij}} = 1, \ \ \forall i \in I $$ という式を作れます。これは以下のような行列形式で考えるとわかりやすいです。 group$_1$ group$_2$ $\cdots$ group$_{M}$ 社員 $i$ $x_{i1}$ $x_{i2}$ $\cdots$ $x_{iM}$ 社員 $i$ は一つの班に属するのでいずれかが 1 でそれ以外はすべて 0 になり、それを上記の式で表しています。そして、すべての社員に対してこの式を満たさなければいけないので、各 $i$ に対して制約が設定されています。 各班には人数の上限が設けられているために、 $$ \sum_{i\in I}{x_{ij}} \leq g_j, \ \ \forall j \in J $$ を加えます。今度は班 $j$ についての制約で行列形式のデータを列で見るとわかりやすいです。 group$_j$ 社員 $1$ $x_{1j}$ $\vdots$ $\vdots$ 社員 $N$ $x_{Nj}$ 列で和を取れば班 $j$ に属する人数を計算できるので、これが班 $j$ の上限人数以下になるようにします。 そして、目的は希望度を最大化しつつ班の男女の人数の比率をできるだけ等しくすることで、以下のようにします。 $$maximize: \sum_{i\in I}\sum_{j\in J}h_{ij}{x_{ij}} - \alpha\max_{j\in J}\left({\left|\dfrac{\displaystyle \sum_{i\in I}{s_ix_{ij}}}{g_j}\right|}\right)$$ 第一項は希望度の総和、第二項は疑似男女比差を表しています。 班 $j$ に属する男性、女性の比率の差は $\displaystyle \left|{\sum_{i\in I}{s_ix_{ij}}}\big{/}{\sum_{i\in I}{x_{ij}}}\right|$ で表せますが、計算を容易にするために班の合計人数を班の上限人数に置き換えて疑似男女比差とみなし、定数 $\alpha>0$ を掛けています。標準形に変換する際は新たな変数 $y$ と以下の制約を加えれば実現できます。 $$ y \geq \dfrac{\displaystyle \sum_{i\in I}{s_ix_{ij}}}{g_j}, \ \ \forall j\in J$$ $$ y \geq -\dfrac{\displaystyle \sum_{i\in I}{s_ix_{ij}}}{g_j}, \ \ \forall j\in J $$ これにより $y$ は $\displaystyle \max_{j\in J}\left(\ {\left|\sum_{i\in I}{s_ix_{ij}}\big{/}g_j\right|}\ \right)$ 以上の値を動くことができますが、目的関数値を極力下げないようにするために最適解で $y^*$ は$\displaystyle \max_{j\in J}\left(\ {\left|\sum_{i\in I}{s_ix_{ij}}\big{/}g_j\right|}\ \right)$ になります。 以上をまとめますと、以下のモデルで書けました。 \begin{align} maximize && \sum_{i\in I}\sum_{j\in J}h_{ij}{x_{ij}} - \alpha y && \\ subject\ to && \sum_{j\in J}{x_{ij}} = 1, && \forall i \in I\\ && \sum_{i\in I}{x_{ij}} \leq g_j, && \forall j \in J\\ && g_jy \geq \sum_{i\in I}{s_ix_{ij}}, && \forall j \in J\\ && g_jy \geq - \sum_{i\in I}{s_ix_{ij}}, && \forall j \in J\\ && x_{ij} \in \{ 0, 1\}, && \forall i\in I,\forall j \in J\\ && y \in \mathbb{R} && \end{align} 実装 設計ができたので、Pythonで実装します。 import pulp '''省略''' problem = pulp.LpProblem( "problem" , pulp.LpMaximize) x = pulp.LpVariable.dicts( "x" , ( range (n), range (m)), 0 , 1 , "Continuous" ) '''省略''' ポイントは$x_{ij}$を0-1変数(Binary)ではなく$[0,1]$ の実数変数(Continuous)にしていることです。理由は行列のユニモジュラ性を利用していて、最適解で $x_{ij}$ は整数になることが保証されているためです。組み合わせ問題は変数を増やすと爆発的に計算量が増加しますが、この緩和を適用できると変数が増えても比較的容易に最適解を求められます。 結果 最後に最適化と抽選式で結果を比較します。抽選式は、希望人数を加えても班の上限に達しないならば抽選せずに確定させ、そうでなければ抽選によって班に加えるメンバーを選出する決め方です。比較は希望した班に割り当てられた人数を集計して行い、実行環境はIntel® Core™i5-6200U CPU @2.3GHz, メモリ8GB でした。 昨年の社員旅行で用いられたデータ（一部加工, $N=411, M=14$）で計算すると以下のようになりました。 最適化 抽選式 第一希望 339 349 第二希望 62 20 第三希望 10 13 希望外 0 29 最大男女差比 30% 15% 計算時間 0.6秒 0.3秒 抽選式では希望外の班に割り当てられた社員がいるので、この後手動で調整する必要があります。一方で最適化の結果ではその現象は起きていません。次にデータの規模を大きくして$N=10000, M=100$としました。 最適化 抽選式 第一希望 8318 8512 第二希望 1591 620 第三希望 91 270 希望外 0 598 最大男女差比 33.3% 30% 計算時間 162秒 16秒 この規模になると最適化の効果が顕著になりますね。 まとめ クリエイターの日を利用して社員旅行の班分け最適化モデルを作りました。整数条件を不要としたモデルにすることで変数が増えても比較的容易に計算できるのが特徴でした。エンジニア支援制度が充実したネクストでは鋭意エンジニア採用中です！新卒・中途問わず、ご興味を持たれた方は是非下記ページを御覧ください。 http://recruit.next-group.jp/

こんにちは、AmazonESでElasticsearch2.3を使っての環境構築が終わった直後にElasticsearch5.1が利用可能になってショックを受けてる技術基盤部の磯野です。 ちょっとだけ時間ができたのでzipkinのバックエンドをAmazon Elasticsearch Serviceに差し替えてみました。 CassandraとElasticsearchどっちにしようかなぁと悩んでいたのですが、zipkinがいつの間にかElasticsearch Serviceに対応していたのでサーバー構築したくない病発症中のためノータイムでElasticsearch Serviceに決定しました。 Amazon Elasticsearch Serviceの起動 アクセスポリシー zipkinサーバーの設定 zipkinサーバーのIAM Roleの設定 設定を変更してみて インスタンスの負荷の減少 コスト削減 検索高速化 ServiceName,SpanNameの取得が遅い問題 まずは今回やったことまとめです。 Amazon Elasticsearch Serviceの起動 Elasticsearch domain nameはzipkin, Elasticsearch versionに(当時)最新の2.3を利用しています。 アクセスポリシー 以下のように設定しています。 zipkinの動いているEC2インスタンスのロールとsnapshotを取得するためのlambdaのロール、そしてkibanaの為に社内からのアクセスをIPで許可します。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Principal ": { " AWS ": [ " arn:aws:iam::[account-id]:role/zipkin-server ", " arn:aws:iam::[account-id]:role/zipkin-snapshot-lambda " ] } , " Action ": " es:* ", " Resource ": " arn:aws:es:ap-northeast-1:[account-id]:domain/zipkin/* " } , { " Sid ": "", " Effect ": " Allow ", " Principal ": { " AWS ": " * " } , " Action ": " es:* ", " Resource ": " arn:aws:es:ap-northeast-1:[account-id]:domain/zipkin/* ", " Condition ": { " IpAddress ": { " aws:SourceIp ": " [office-ip-address] " } } } ] } zipkinサーバーの設定 以前 こちら で記載したのとほとんど変わりません、最新版をインストールし、必要な環境変数を指定して起動します。 ES_AWS_DOMAIN, ES_AWS_REGIONを指定することでインスタンスのIAMロール利用して自動的にホスト名を取得してくれます。 sudo STORAGE_TYPE = " elasticsearch " ES_AWS_DOMAIN = " zipkin " ES_AWS_REGION = " ap-northeast-1 " java -jar /opt/zipkin/zipkin.jar zipkinサーバーのIAM Roleの設定 ES_AWS_DOMAIN, ES_AWS_REGIONからホスト名を取得するためにzipkin-serverのロールに権限付与が必要です。 （ホスト名[ES_HOSTS]で指定すればこの設定は不要です。） { " Version ": " 2012-10-17 ", " Statement ": [ { " Sid ": " Stmt1484898974000 ", " Effect ": " Allow ", " Action ": [ " es:DescribeElasticsearchDomain ", " es:DescribeElasticsearchDomains " ] , " Resource ": [ " * " ] } ] } 設定を変更してみて インスタンスの負荷の減少 見て分かる通り1/25前後で入れ替えています。 CPU負荷も減り、トレースデータを受け付けるインスタンスの台数も減らせています。 コスト削減 EC2インスタンスの台数を半分にしました。 またESについてはRDSの時よりも台数は増えましたが小さいインスタンスにしたため、コストとしては半分程度になっています。 検索高速化 MySQLの時に比較して高速にレスポンスが返却されるので負荷を気にせずに検索できます。 ServiceName,SpanNameの取得が遅い問題 MySQLの時はSQLのチューニングとテーブルにインデックスを張って高速化していたのですが、Elasticsearchのことがまだわかっていないので、どうしたらいいかわからず遅いままです。 検索と同様、チューニングできると思うので今後考えていきたいと思います。

エンジニアの鈴木です。主にAWS周りのことをやってます。 11月末から1週間ほど、AWS(Amazon Web Service) が主催するカンファレンス re:Invent 2016に参加してきました。開催場所はラスベガスでした。 今回得た経験を踏まえ、 海外のカンファレンスに参加するということ について思うことをまとめましたのでフィードバックします。 ただし、「海外のカンファレンスに参加すること」という意味合いで汎化して書いたつもりですが、実際はre:Inventにバイアスが掛かっています。 なので、 re:Inventに参加するということ と読み替えてもらったほうが適切かもしれません。（その判断は読者の皆様におまかせします。） また、たった一度のre:Inventへの参加という偏った主観であることと、re:Inventで得た技術的な内容のフィードバックはこの記事に含まれないことにご留意ください。 海外のカンファレンスに行ったことがない企業所属のエンジニアの方や、そのエンジニアの上司の方に読んでいただけたら嬉しいです。 まずはじめに、 「なぜ海外のカンファレンスに参加するのか？」 という問いについてです。 主観ですが、端的に 「現地でしか得られないものがあるから」 になります。 （当たり前） では、現地でしか得られないものとはなんでしょうか？ それは個人の主観になるのでコレだ！というものに限定できません。 ですが、それは確実に存在し参加者へ影響を及ぼすと思います。 これだとフワッとしているので、少し視点を変えます。 シンプルに メリット・デメリット を考えていった時に、最終的に 送り出した企業・実際に行った人の両方にメリットがある と感じました。 その理由を「参加させる企業のメリット」、「参加者のメリット」として以下にまとめます。 参加させる企業のメリット まず初めに、費用を持つ立場から見た視点で見ていきます。企業（上司）サイドの話です。 企業が海外のカンファレンス参加を経費として認めてくれるパターンがあります。自分もそのパターンでした。 海外のカンファレンスに参加するにはコストがかかります。 実際にかかる経費は、普通に考えて 渡航費用・イベント参加費・現地での滞在費・出張中の人件費等があります。 日常的なコストと相対的に比較すると”安い”とは声を大にして言えません。 それでも自分は参加したほうがメリットが大きいと感じました。 その理由を見ていきます。 参加者の変化を促せる 普段と違う環境は、個人に対し確実に影響を与えます。 参加するイベントが提供する情報は、もともとその個人にとって興味のある分野のはずです。なので、限られた時間の中で、新しい知識を得たり新しいリレーションを築くことは、必然的にポジティブな方面への変化を促せると感じました。 自社の抱える 社員がポジティブに変化することは、企業にとって大きなプラス になると思います。 採用においてメリットを生む 昨今のエンジニアの争奪戦は人事的には頭の痛い問題です。 ビジネスをドライブしていける人材を確保していくことは大変重要ですが、優秀なエンジニアは複数社からの内定が出ることが多いので、どうやって自社を差別化するかがポイントになります。 その際、積極的に海外のイベントに参加することができる体制がある会社であることをアピールできれば、 採用の後押しとしてのメリットを生む ことができると思います。 社内エンジニアへの影響 会社で参加実績が作れると、自分も来年もしくは再来年は行けるかもしれないという期待がエンジニアに膨らみます。 期待が膨れれば、その技術に対してもっとコミットしようと思うし、 スキルが上がれば生産性にも影響がある でしょう。 素直で謙虚なエンジニアほどしっかりスキルを身につけて次のチャンスをものにしようと行動すると思います。 参加者のメリット 次に、参加者側からの視点です。 毎晩飲みにいけます。って話ではありません。（あながち間違っていませんが） 百聞は一見にしかずとはまさにこのことで、普段とは全く違う角度から経験値が上がります。 特に初参加であればその傾向は顕著でしょう。 参加者が得られるメリットとその理由を見ていきます。 海外とは無縁な人ほど、良い意味で変化の振り幅が大きい 普段、外に出て行く機会が少なく社内で黙々とプロダクトを開発しているエンジニアには、カンファレンスへの参加で受ける影響が大きく、それに比例するように変化の振り幅が大きくなると感じました。 自分に起きたわかりやすい例でいうと、英語に対するハードルが下がったり、新しい分野への興味が湧いたり、諸々ありますが、 はっきりとした変化が感じられました 。 普段得がたいリレーションが築ける機会がある 前提として、今回はツアーでの参加になります。ツアーにはそもそもリレーション強化の懇親会などがインクルードされていました。 なので、何のリレーションのない個人が現地で０からリレーションを築いたという内容ではありませんのでご留意ください。 海外までイベントに参加しにいくと言うことはそれなりに労力がかかります。その労力をかけても参加したい人たちが集まっているので、みんな話が通じやすくフレンドリーだと感じました。そのイベントが提供する技術的な分野に対し、最初から多くの共通項を持っているからなのかもしれません。 同じ時期、同じ場所に集まると思いもがけない出会いがあった りします。 自分の場合、カンファレンス最終日にとあるレジェンド的な方とたまたま席が隣になりお話しさせていただく機会がありました。その会話の中で自分が感じていたことの誤解が解けたり、海外のカンファレンスへの参加について同じような思いを抱いていることがわかったり、自分の行動範疇では到底得ることのできないようなお話をさせていただくことができました。 世界の広さを感じられる 本当にいろんな人がいます。そして、参加者全員がその分野に興味があって集まってきています。 世界中から集まってくるエンジニアと一緒にセッションを受けていると、公表されているサービス利用者の数字から 想像できる以上のインパクト がありました。 参加人数が多いカンファレンスであればあるほど、その傾向は顕著だと思われます。 英語へのハードルが下がる 出国前は何かと不安でした。自分はそんなに英語ができる方ではないからです。 ですが、行ってみたら意外となんとかなりました。なんとかなると 自信がつきハードルが下がる のを感じました。 セッションのスライドはわかりやすく簡易な英語で書かれていることが多いし、登壇者にはプレゼン慣れしている方も多いです。その登壇者が簡易な英語のスライドをベースにして話が進むので、セッションの内容も理解しやすかったです。（実際、街中のブロークンな英語の方が理解するのに苦労しました。） まとめ いままで延べてきた通り、海外の技術系イベントに参加するということは、 企業にとって短期的に見ても長期的に見ても良い投資 だと思います。 それは情報の鮮度的なメリットもありますが、もっと大きな要因として、現地に行くことでしか得られない人の成長を加速させる可能性がいろんな側面に秘められていると感じるからです。 ただ、上記に記述しましたメリットを享受するには、 一つ重要な前提条件 があります。 それは、参加者が 自らの言葉でフィードバックすることが必要 だということです。 企業にとって、 費用対効果のあるなしはフィードバックの質や熱に大きく依存する と思います。そのフィードバックが次回に向けた参加判断基準になります。 昨今では日本にいても情報が得られるタイミングは同じになりました。 なので、日本に居て情報をキャッチアップすることは容易であり、費用もかかりません。 ですが、現地でしか得られないものがあります。 だから、 自分で感じることが重要 で自分の言葉でフィードバックすることが大切だと思います。 もし海外の技術系イベントに参加したいと考えているエンジニアの方は、いまから積極的にアピールしましょう。ひょっとしたら会社が経費を持ってくれるかもしれません。 （仮に会社の選考から漏れたとしても自腹来てらっしゃる方もたくさんいます。） 企業や決済者は、エンジニアにどんどん旅をさせることをオススメします。さまざまな面で短期的にも長期的にも割のいい投資になると思います。 そして、参加者は、社内・社外・自分・次に行くかもしれない人のためにフィードバックをしましょう。 あなたのフィードバックがみんなを少しづつ良い方向にナビゲートする最初の一歩になる かもしれません。 このフィードバックが誰かの役に立てば幸いです。

はろーはろー！チバです。 今回は、22期2Q（7-9月の間）で「クリエイターの日」制度を利用しておこなった、 社内クラウドファンディングシステム「FU-SHA」 の企画〜リリースまでの取り組みの様子をお送りします！ クリエイターの日制度を利用するに至った経緯 2016年11月に、「アイデアアワード」という 社内アワードに応募していたところ、グランプリを受賞 することができました＼わーい！／ そのときの応募していたアイデアが「社内クラウドファンディング」。 一般社員の投票で選ばれたネタなので、みんなの期待を感じられてとても嬉しかったです。 クリエイターの日とは 度々当ブログにて開催報告をしている弊社の開発合宿制度です。 「こういう目的のために、こんなものを作りたいんです！」と申請すれば、職種関係なく、誰でも業務時間の10％を使い、合宿形式で研究・開発を行うことができます。 変化の激しいICT分野のマーケティング能力、技術開発能力を高め、イノベーションを創造するため、通常業務の枠を離れて、新たな技術や手法に取り組む機会を設けています。希望するクリエイターは、個人またはチームで特設プロジェクトの提案を行い、承認されたプロジェクトについて業務時間の10％を使い、合宿形式で研究・開発を行います。 http://creators.next-group.jp/ 「アイデアアワードで受賞できたからには、クリエイターの日制度を利用してカタチにしたい」と思い、参加を決意、応募しました。 クリエイターの日取り組みプロセス 今回の開発フローはこんな感じで進みました。 1. 立ち上げ - Process of Initiating チーム結成 社内に呼びかけ、趣旨に賛同してくれた2人を仲間に3人体制で参加を決めました。 チバ、ヤノ、タカラベの3人で社内クラウドファンディングの立ち上げに向けてプランニングを始めます。 リーンキャンバスを利用して思考の整理 リーンキャンバスとは、ビジネスモデルの企画のために用いられるツールです。 限られた1枚のスペースにぎゅっと詰めることで、本当に伝えたい計画「本質」をシンプルに経営者に伝えられたり、チーム内でシェアすることができます。 今回のクリエイターの日では、活動開始前に休日1日だけ集まり、「合宿」と銘打ってリーンキャンバスの作成をおこないました。 3人のチームで必要なスコープを絞り、期間内に成果物を用意できたのは、簡潔にまとめられた計画書があったからこそだと思います。 2. 計画 - Process of Planning 限られたリソースでのスコープ計画 チバ、ヤノ、タカラベの普段の業務上のスキルセットは下記です。 チバ：ディレクター ヤノ：ディレクター タカラベ：デザイナー 普段、フロントの企画・設計・コーディングなどを業務としている3人なので、システムの組み込みはやらないメンバー。 しかしチバ、ヤノの2名にもともと制作経験があったこと、また、タカラベのスキルがフルスタックな事から下記のようにページやパーツ、フェーズ毎に役割を再配分しました。 チバ：ページ構成のコーディング - ワイヤフレームの作成、デザインカンプの作成などを割愛することを心がけた制作フェーズ ヤノ：フォームのマークアップ、ローカルへのデータ保存実装 - 創民祭の「デモ映え」のために組み込み作業を優先してもらう タカラベ：メインデザイナー - 基本の色彩計画、マテリアルの統一のために見栄えに関しては1人に集中してもらう 今回のプロジェクトの範囲、およびスコープを明確に共有していたため上記のように振り切って制作に挑みました。 3. 実行 - Process of Executing 大まかな計画の芯を立てた後は、実装に入ります。 細かい仕様書のようなものは存在しないため、机を並べて「小さな意思決定」を口頭で確認しながら進めます。 その際に、 チーム3人の目的がぶれないために用いた手法がフレームワークの実践です。 顧客の心を捉えるフレームワーク マーティ・ケイガン「Inspired: 顧客の心を捉える製品の創り方」 Amazon CAPTCHA 製品化によって具体的にどんな問題を解決するのか？ 誰のためにこの問題を解決しようとしているのか？ 市場の大きさは？ 製品化の成功をどうやって評価するのか？ なぜ当社がこの製品化をやるのに最適なプレイヤーといえるのか？ なぜ今なのか？ どうやって製品を市場に送り出すのか？ 成功のために絶対必要な要素は何か？ これらを前提とした上で最終的な提案は何か？（やるかやらないか？） 上記心得を事前にすり合わせておき、デザインの方針や機能の提案などぶれないようにします。 ユーザビリティ10原則 ヤコブ・ニールセン「ユーザビリティに関する10のヒューリスティクス (問題解決に役立つ知見) / Ten Usability Heuristics」 website-usability.info システム状態の視認性を高める 実環境に合ったシステムを構築する ユーザーにコントロールの主導権と自由度を与える 一貫性と標準化を保持する エラーの発生を事前に防止する 記憶しなくても、見ればわかるようなデザインを行う 柔軟性と効率性を持たせる 最小限で美しいデザインを施す ユーザーによるエラー認識、診断、回復をサポートする ヘルプとマニュアルを用意する 上記はすべての評価はできなかったものの、今後の課題を挙げる良いデザインレビューができました。 ラベリングから操作性まで、一つの目線で様々な方面を見ることができるのでおすすめです。 4. 監視 - Process of Monitoring and Controlling ベンチマークの設定 「私たちはここまでのレベルに達しなければならない」を明確に するべく、世間のクラウドファンディングサービス、ユーザー投稿型のサービスを観察して特徴を羅列させていました。 品質コントロールのために、それぞれのサービスを使ったときの感情を書き留めておけるように工夫。 「この行動を起こしたときの感情を忘れないようにしたい！」というときには、見た目の印象とともにシナリオを文章で綴っておく ことも大切にしました。 5. 終結 - Process of Closing 最後に、成果物の報告フェーズを置きました。 社内システムの開発となると、然るべきところに「いいよ、やっちゃおうよ」と言ってもらうことが必要になります。 そのために、 創民祭参加者がデモンストレーションできること いのさんランチ（社長とランチできる制度）でα版のお披露目をして好感触を得ること を報告の場として選びました。 ここまでのフェーズは、すべて上記2点達成のために立てた計画です。 創民祭の結果 nextdeveloper.hatenablog.com おかげさまで、最優秀賞をいただくことができ、チームメンバーで 美味しいお寿司をご褒美 にいただきました(๑´ڡ`๑) 写真はヒラマサのお寿司、粒マスタードを乗せたものです。 創民祭でいただいた最優秀賞は、参加してくださった皆さんの投票によって決まります。 つまり、この票は社員皆から「期待されている」ということでもあります…！ このプロダクトはα版を抜けてさらに良いものへアップデートされていくでしょう！していきます！！！！ 2年後、3年後には社員がこのプラットフォームを使っている光景を実現させるために、 チームFU-SHAはたくさんの期待と応援を受けて回り続けます。 22期3Q（10-12月の間）の活動予定 3Qも、「クリエイターの日」制度を利用してFU-SHAのアップデートをおこないます。 今回はメンバーに新たにエンジニアのオオバを加え、システムとして稼働できるようになることを目指します。 またこの場を借りて、皆さんに楽しくてわっくわくするようなご報告ができることを楽しみにしています(^O^) ご期待くださいっ！チバでした。

こんにちは、新卒デザイナーの五十嵐です。 私はアプリチームに配属になり、主にアプリのストア内の画像・動画や集客バナーの制作をしています。 何事にも根拠が必要ということを学びながら、日々ものづくりライフに励んでおります。 今回は、私が携わった Androidアプリの宣伝用画像におけるA/Bテスト についてお話したいと思います。   そもそもAndroidアプリの宣伝用画像とは Androidアプリの宣伝用画像とは、下記の画像のオレンジの部分です。 はじめにユーザの目に止まり、おもてなしする部分になりますね。   A/Bテストを行う目的など Androidアプリの宣伝用画像はアプリの説明を視覚的に行い、ユーザーを引き付けるのに効果の高いツールです。 つまり、訴求性の高い画像であれば、アプリのインストール数が増えると考えられます。 そこで今回は、 元々のAndroidアプリの宣伝用画像と、より訴求性が高いと考えて制作した画像とでA/Bテストを行い、どの画像が一番インストール数が多いかを検証しました。 目的：インストール数を増やす 検証：宣伝用画像のクリエイティブを数パターン制作して比較する 手段：A/Bテスト ターゲット：20代後半〜30代の女性 1回目のA/Bテスト まず最初に、以下のことを考えてみてください。 あなたは20代後半〜30代の女性でお部屋を探しています。住まい探しアプリをインストールして、部屋を探そうと思い、Google Playで検索してHOME'Sというアプリを見つけました。 ３つの画像のうち、どれが「インストールしてみよう！」という気持ちになりますか？   ■結果 上記の3パターンの画像でA/Bテストを行った結果、一番アプリのインストール数が多かったのは... Bパターンの 「間取り画像を追加して、住まい探しアプリのイメージを強く訴求したパターン」 でした！！！！！   ■考察 Bパターンが一番アプリのインストール数が多かったことにより、 間取り図をいれると元々のAndroidアプリの宣伝用画像よりも、 住み替え後のイメージがわきやすくなる と考えられます。 また、今回は20代後半の女性をターゲットと考えていたので、 女性向けに訴求するから、間取りに独立洗面台を作ろう 年齢的にも同棲を考えた人が多そう＝2LDKにしよう といった2点の要素を間取り図に取り入れたことも、ターゲットに住み替えをイメージさせるのに役立ったのではないかと考えています。 2回目のA/Bテスト 1回目のA/Bテストの結果と考察を踏まえ、2回目のA/Bテストを行うことになりました。 2回目では、1回目のA/Bテストで一番インストール数が多かったBパターンと、カップルに強く訴求したパターンとで、どちらの画像が一番インストール数が多いかを検証しました。 ■カップル訴求の理由 集客バナーでは、カップル訴求バナーの効果が高いという結果がありました。 よって、ターゲットの年齢的にも同棲を考えた人が多いのではないかと考え、実際にソファに座っているカップルを見ることで、強く訴求できるはずという仮説を立てました。 ■結果 上記の2パターンの画像でA/Bテストを行った結果... ほぼ同じという結果 でした！！！！！ ■考察 結果がほぼ同じだった、直接的な要因はわからないのですが、 カップルのイメージが強すぎたのではないか ということが考えられます。 そのため物件探しのイメージから乖離していると感じられてしまい、効果がイマイチだったのかと思います。 部屋全体が映り、風景としてカップルがいるくらいの写真にすると、効果が出たのかもしれません。 まとめ A/Bテストを通して思ったこと、学んだことをまとめます。 Google PlayではA/Bテストの環境が整っているのでやるべき デザイナーは制作物のどんな要素に対しても根拠をもって制作しなければならない いままでの数値やターゲットを狙ったクリエイティブに仮説を立てて検証をする テスト環境が整っており、何がインストールの要因になるのかを考えるのも楽しいので、ぜひ検討してみてください！ 最後に あたかもたんたんと制作したような記述ですが、実は完成するまで何回も修正を経て上記のアウトプットになりました。 間取りを一つ作るのにも、当初はお仕置き部屋（ドアのない部屋）を作ったり、驚くほどコンパクトなお風呂の間取りを作ったりしていました。 チェックやアドバイスをもらって初めて、「確かにこんな間取り住みたくない！」と気づくくらい、ミスを見過ごすことが多かったです。 その度にセルフチェックリストに書き込んで、見直してを繰り返しては、「自分のデザインに対して客観的に見る習慣や視野を養わないと」と思う日々ばかりでした。 次回は、より効果が出る仮説と細部まで拘ったクリエイティブのものを作りたいと思います。気になる方はGoogle Playを見に来ていただけると嬉しいです。 スマートフォンでご覧いただけると、宣伝用画像がみられます！ play.google.com 以上です。ではでは。

こんにちは！ 新卒1年目エンジニアの佐藤茉弥（さとうまや）です。 今回は、先日10/4(火)に開催されたネクストの社内イベント「第3回創民祭」の様子についてレポートさせていただきます。 創民祭(そうみんさい)とは 聞き慣れない言葉かと思いますが、「創民祭」は、 業務内外で作ったプロダクトを発表し合うお祭り です。 各展示ブースでは、プロダクトに関して説明を聞くのみではなく実際に触れることもできます。 半年に1回のペースで開催されていますが、とても刺激になる楽しいお祭りです！お酒と軽食も出ます！ 前回までの開催の模様はこちらの記事をご覧ください。 当日の様子 （（ざわざわ・・・！）） にぎわってきました！ 前回に引き続き、今回も DJさん が来て下さいました！ かぶりものはちょっと暑そうでしたが、 おかげで 会場の賑わいもHOT になってきました！！ 新卒1年目同期や研修後の内定者 もたくさん見に来ていました！ 興味深い発表があったようです。 なんと今回は特別ゲスト、 社長の井上 も参加しています！ 役員の山田 も興味津々です！ 展示プロダクト紹介 エントランスプロジェクション 新オフィスのエントランス で表示する、プロジェクション制作の展示がありました。 ホームズくんを動かして、1人1人の社員と会話することができます。 制作していたときに、こちらの画面の中のキャラクターになりたい社員を募集していたので、私も描いてもらっています！ ぺろぺろキャンディーがなかったので、お酒を持って撮影してきました（笑） 似顔絵制作ツール「NEXT STAFF MAKER」 こちらは私の同期である、 新卒1年目のデザイナー4人組チーム が作ったツールです。 自分に近いパーツを選択していくと、ホームズくんっぽい自分の似顔絵アイコンを作ることができます！ 開発しているところにも潜入してきましたが、とても楽しそうに制作・開発していました。 W3C push api基盤 push通知といえばスマートフォンアプリですが、このプロダクトは、開発者が複数行のjavascriptをサービスに追加するだけで、 W3C push apiを用いたブラウザへのpush通知を実装できるというツールです。 Webサイトを見ていないユーザにもブラウザを開いてさえすれば、リアルタイムで通知を送ることができます。 Webサイトを見ているユーザに対しては従来のnotificationでも可能です。 さらにスマートフォンのユーザにはブラウザを開いていない状態でも通知を送ることが可能です。 (下記の構成図でいうと「新しい物件が登録されました」にあたります) 弊社のサービスにどんどん新しい技術を取り入れ、 会社をリードしてくれるプロダクト でした。 ぬいぐるみハック・ディープラーニングでファブリックデザイン こちらの展示ブースでは、異様な動きをするクマさんがお出迎えしてくれました。 最近流行の ファブリックデザイン を 物件の間取り図を元に制作する という発想に聞いていた人も食い入るように聞いていました。 R言語で構築した社内用分析ツールキットのデモ エンジニア以外でも、 容易にアクセス数などのデータを知ることができる社内用分析ツール の発表をしていました。 こういうものが社内でもどんどん取り入れられるようになると、職種に問わず、だれもが知りたいときに知りたい情報を知ることができそうです！ このツールを作るにあたり分析用プログラムの開発フローをまとめた結果、分析タスクの運用・共有が簡単になったそうです！ そこで得られた知見の一部はQiitaにも投稿されていますので、こちらをご覧ください。 Amazon CloudSearchを用いたcrontab検索システム Amazon CloudSearchでLinuxサーバの「crontab」を検索するシステムです。 見た目の派手さはありませんが、 複数のサーバーでのcrontab管理の辛さを解消する 素晴らしいプロダクトです。 詳しい内容はQiitaに投稿されていますので、こちらをご覧ください。 社内クラウドファンディングPJ「FU-SHA」 「自発的に "うごきたい！" と思える社内の仕組みを創る」 をビジョンに作られた 社内クラウドファウンディング・プラットフォームの展示です。 ネクストには、アイデアアワードという制度があり、社内のアイディア募集コンテストのようなものも行っています。 そちらで賞をとったアイディアが開発され、展示されました！ インタラクティブjson incremental diggerツール 開発したjidはgo言語で書かれた Json Intaractiveフィルターツール です。 jsonをコマンドライン上で対話的にフィルタリング＆選択でき、とても便利です。 とても簡単＆スピーディですよね。 jidはgithubで公開されています。 「使ってみたい！」という方はこちらからお試しください！ Exercise Mouse 人事（採用担当） も、 全身を使ってのマウス操作 に挑戦していました！ ジャンプするとクリックできます！ 私も挑戦しましたが、セグウェイに近いものを感じました。 エンジニアの運動不足を解消できそうです。 受賞プロダクト tech賞 技術が一番光っていたプロダクトに与えられる賞、tech賞に輝いたのは・・・ 「「　 Amazon CloudSearchを用いたcrontab検索システム 　」」！！！ おめでとうございます！！！ 山田賞 役員山田が選んだのは・・・ 「「　 W3C push api基盤 　」」！！！ 役員山田からなにか嬉しいプレゼントがあるかもしれません・・・！ 最優秀賞 最優秀賞とは、観覧した人の投票によって決められる 「誰もが心を動かされたプロダクト」に贈られる賞です。 堂々の最優秀賞は・・・ 「「　 社内クラウドファンディングPJ　「FU-SHA」 　」」！！！！ 今後の活躍にも期待です！ 最後に 創民祭は今回も大盛況でした！ 内定者時代からすべての創民祭に参加してきた私ですが、 参加すると、 「もっと自分も何か作りたい！技術力をつけたい！」 と感じました。 次回の開催も楽しみです！ 以上、第3回創民祭レポートでした。

こんにちは。デザイナーのshinoです。 IT業界で働くすべての方やWebサービス事業に興味のある方に、お知らせです。 11月28日(月)に、弊社主催で5社合同勉強会を開催いたします！ このブログではその勉強会について、ご案内させていただきます。   5 Sessions DELI. とは？ 「ユーザーのライフイベントに寄り添うこと」 をミッションとしている、株市会社みんなのウェディング・弁護士ドットコム株式会社・ウォンテッドリー株式会社・株式会社ノハナ・株式会社ネクストの５社合同で開催する勉強会です。 各社の旬で美味しい話 （Delikatesse） をお届け（Delivery）します！！   開催日時・場所・参加費について 【開催日】2016年11月28日(月） 【受　付】19時15分〜　3階にて受付開始 【場　所】ネクスト本社　東京都港区 港南二丁目3番13号 品川フロントビル　3階 【交　通】JR・京急本線 品川駅（港南口より徒歩3分） 【参加費】無料   タイムテーブルについて   申込み方法について 下記イベントページより参加をお申し込みください。（事前アンケートへのご協力をお願いします） connpass.com   Twitterについて Twitterにて、公式ハッシュタグを用いてツイートされた内容は、後日Togetterでまとめます。 #5sessions_deli に関するツイート   コラボ企業様について 株式会社みんなのウェディング 結婚に関する情報の提供サービスや口コミサイト「みんなのウェディング」を運営 www.mwed.co.jp 弁護士ドットコム株式会社 日本最大級の弁護士検索・法律相談ポータルサイト「弁護士ドットコム」を運営 corporate.bengo4.com ウォンテッドリー株式会社 運命のチームや仕事に出会えたり、人脈を広げ、ビジネスの情報収集に使えるビジネスSNSを運営 www.wantedly.com 株式会社ノハナ フォトブックアプリ（nohana）を運営 nohana.co.jp 株式会社ネクスト 住宅・不動産ポータルサイトHOME'Sを運営 www.next-group.jp   年末年始に向けて忙しい時期かとは思いますが、どうぞぜひお越しください！     //

こんにちは、新卒三年目のナガサキです。 新卒一年目の椎橋くんがブログを書いていたので、私も負けじと書いてみます。 nextdeveloper.hatenablog.com まずは簡単に自己紹介をさせて頂きます。 私は2014年に弊社（株式会社ネクスト）に入社しましたが、この年は30歳になる年でした。大学院で博士課程まで進み、就職しようと思ったときにはそんな歳になっていました。。新卒研修中の健康診断で、一人だけバリウムを飲むことになり、先輩に気を遣って頂いたのはこれまででも私くらいでしょう。 さらに私はエンジニアとして入社したのですが、当時はほぼプログラミング初心者でした。プログラミングといえば、研究の中で簡単なシミュレーションのプログラムをC++で書いたり、Rでデータ解析をしたくらいの経験しかありませんでした。Webに関してもhtmlを独学で学び、当時書いていたブログ内でタグを使ったりする程度で、今思うとよく採用しようと思ってもらえたものです。 簡単といいつつ自己紹介が長くなってしまいましたが、こんな私でも三年目で大きな仕事を任せて頂ける、というお話を今回はお届けしたいと思います。 プロジェクトの概要 2016年10月からHOME'Sの一戸建て領域は大きくリニューアルしました。 以前のHOME'Sは、 新築一戸建て（分譲） 中古一戸建て（新築仲介含む） という2カテゴリに分かれていました。 このカテゴリ分けは、一戸建てを取り扱う不動産会社が「売主（または代理）」であるか、「仲介」であるかという、物件の取り扱われ方に依った分け方でした。 一見すると不動産会社の都合じゃないか？と思いそうですが、一戸建てを探すユーザーにとっても、仲介手数料が必要かどうかという大きな違いがあります。 しかし、ユーザーにとってその違いは本当に意味があるのか、一戸建てを探すユーザーは「新築」なのか「中古」なのかという軸で検索できた方がわかりやすいのではないか？という議論が数年に渡り続き、本年リニューアルを実施することになりました。 リニューアルした現在のHOME'Sでは、 新築一戸建て 中古一戸建て という2カテゴリで一戸建てを検索できるようになっています。 不動産・賃貸・住宅情報（マンション・一戸建て）ならHOME'S【ホームズ】 プロジェクトチームの体制 今回のリニューアルプロジェクトでは、私と、もう一人の同期エンジニアの二人で開発リーダーを務めました。担当分けはざっくりと、私が開発周り、同期エンジニアがテスト計画を担当して進めました。また、メンバーは新卒二年目の後輩2人と業務委託の方1名という、とても若く社歴の浅い開発メンバーでした。 前段のプロジェクト（一戸建て領域での改修やABテスト）があり、その際にHOME'Sに詳しい先輩エンジニアからある程度ノウハウを得られたとはいえ、リニューアルプロジェクトにアサインされたメンバーは上記の若いメンバーだけでした。そのチームで、旧カテゴリに従って過去数年開発・運用されてきたHOME'Sサイトを、新カテゴリに適応させなければなりませんでした。 実際の開発タスク 対応すべき箇所もかなり多く、それぞれの開発タスク1つをとっても、いざ取り掛かり影響範囲の調査を行うと、当初の見積もりよりも工数が肥大化することがよくありました。（プロジェクト当初に私が知らないことだらけの中で見積もったものが荒すぎたと反省しております。。） また、既に運用されているサイトの改修となりますので、技術的に新しいことにチャレンジする方法は取りづらい状況でした。 具体例を一つ上げますと、旧カテゴリのそれぞれで利用されていた検索条件を、新カテゴリで利用できるようにするタスクがありました。 弊社の物件検索システムでは、カテゴリ毎にそれぞれの物件にタグをつけ、それを用いて検索を行っています。つまり、ただ物件のカテゴリを以前のものから新しいものへ移せばよいというわけではなく、それぞれのカテゴリで「正しく」検索できるように、タグのつけかえも丁寧に行わなければなりませんでした。調査の占める割合が高く、決して楽しいとは言えませんがとても重要なタスクでした。 このようなタスクが多い中で、自分自身を含む開発メンバーのモチベーションを維持し、さらに全体の品質を落とさずにスケジュールを守る、ということがリーダーとしての私に期待されている役割だったと思います。（もちろん、私たちリーダー二人の上にはマネージャがいて、適宜アドバイスを頂いていました。） リーダーとして気をつけたこと 小規模の開発案件を任されたり、中規模開発に一メンバーとして参加したことはこれまでにもありましたが、やはりリーダーとして全体を見る・考えるということは一味違いました。 今だれがなにをしているのか、どのタスクが誰にふさわしいのか、タスクごとのスケジュールとメンバーの成長のバランスをどう取るのか。。。 悩みながらではありましたが、自分の中で下記の目標を立て、常にそれを意識してメンバーと接するようにしました。 スケジュールを守る バグ・障害を出さない リニューアル前よりも”良い”コードにする 1, 2は社会人、またエンジニアとして当然の目標かと思いますが、自分自身とメンバーの成長を考えた時、3が出てきました。 影響範囲の広さや、テスト工数の大きさにビビって小手先の改修を行うのではなく、その部分の実装はどうあるべきなのかを常に考え、実装とソースレビューを行うようにしました。 リニューアルが終わった今となって、自己評価ではありますがすべて達成でき、後輩もきっと成長してくれたと思っています。 本プロジェクトを通して得たもの 今だから言えるのですが（といいつつ担当のマネージャには当初から正直に打ち明けていました）、プロジェクトが走りだした当初は不安でしょうがなかったです。 本当にこのメンバーでできるのだろうか？ 自分が開発メンバーを引っ張っていきプロジェクトを回せるのだろうか？ しかし、やり終わった今となっては心から「やってよかった、成長できた」と感じます。言ってしまえばなんでもそうなんですが、やらなきゃわからないことばかりでした。 一エンジニアとして新しい技術に興味もあり、いろいろ試してみたいと思います。ただ、ユーザーに使ってもらえるサイトにすることを第一に考えた時、いろんなアプローチがあるんだ、という当たり前の気づきも得られました。 一言で言うと、また大きい案件やりたいな！って思うくらい、充実した仕事でした。 最後に 長々と書いてしまいましたが、このエントリをまとめますと、下記2点となります。 初心者だろうと、経験が浅かろうと、熱意と正しい考え方があれば成果を出せる ネクストは入社年度や年齢関係なく、挑戦しがいのある大きな仕事をまかせてもらえる環境がある そんなネクストでは鋭意エンジニア採用中です！新卒・中途問わず、ご興味を持たれた方は是非下記ページを御覧ください。 http://recruit.next-group.jp/

　こんにちは。ネクストのデザイナー新卒1年目のおおしだです。 　タイトルにもありますが、私自身がっつりデザインを学んできた！というわけではなく、大学は技術寄り、学生時代のアルバイトではコーディングを主にやっており、デザインに関しては独学で少し手をつけたことがある…という程度でした。 （すでにデザイナーとして働いている、すでに学んできている！という方に対しては知ってるよそんなこと！という内容かもしれませんが確認がてらお付き合いください！） 　入社してから早いもので6ヶ月…デザインをするにはどのようなことが大事なのか等々、これまで学んだことをご紹介したいと思います！ 1. 優先順位をつける 　入社以来、私がこれまで行ってきたものはWebページの改修やポスター制作等でしたが、どれにもテキストや画像ありきのものです。 一言にテキストと言っても、場所や大きさは見せたいもの、ことによって変わってきます。そんなとき、 どんな人に対してのデザインなのか 何を優先して伝えたいのか その環境にあったデザインか を考えるようにしています。 たとえば壁に掲示するためのポスターの制作をする場合、 その道を通る人はどんな人が多いのか その中でもどんな人に何を伝えたいのか どんな時間帯に見られることが多いのか ということを考える…等です。 これを考えることで「ペルソナをおいてみる」・「全体の配色を決める」であるとか「どんな文字の大きさ・ジャンプ率でレイアウトを組むのか」を考えるきっかけにしています。 2. 言葉にする 1にも関わってくることになりますが、 ヒアリングをする力 自分自身の意見や考えを言葉に落とし込む力 は必要です。 　優先順位をつける前に、何のためにデザインをするのか（目的）、誰に対して行うのか、どんなデバイスでみることを想定しているのかを営業さんから、またはディレクターさんに確認することが必要です。 また、そのようなことを自分自身で考えることもあるので、日頃からデザインをする前に気をつけておく部分でもあります。 　それらに関連したことで以下のお話を社内の先輩からお聞きしました。 「想いとロジックを同時に実現することが大事であり、ビジネスでデザインを行うならばQCDを場所・場合に合わせてバランスよくそろえなければならない。」 QCDとは Q:Quality（品質）　C:Cost（費用）　D:Delivery（納期） のことです。 これに関しても事前に規模感、納期、それにかけるコストをヒアリングし、自分なりの言葉に落とし込み、思いとどめておくことが重要になります。 これは自分自身まだできておらず日頃勉強中です（汗） 3.ルールを決める 　デザインをIllustrator等でつくり出す前にまずはノートに描き出してみます。 例えばポスターやバナーの場合、優先順位を元に、文字の大きさのルール・余白のルール・配色のルールを決めてみます。 文字の大きさ ： コーディングするように考えると決めやすいかもしれません。 最も伝えたいものはh1、説明文はpのようにフォントサイズや色、その意味を考え決めていきます。 これを考えておくことでコーダーさんにデザインデータを渡す際にも組みやすいデザインになると思います。 余白 ： 文字の上下左右には余白が生まれます。 全体の余白が揃っていれば全体も揃って見えます。 どの部分を大きく・どの部分を引いて見せるのか、どのくらいの対比で余白をつけるかを決めます。 配色 ： ベースカラー：70％ メインカラー：25％ アクセントカラー：5％ になるように配色を決めています。 3色以外にも用いたい色がある場合はベースカラー、メインカラー、アクセントカラーのバランスを崩さない程度に加えます。 　これらのルールを決めておくことで後々の理由付けをする際や、ほかの方にデザインを伝える際に説得力が増すと思います。 4. 問いつづける 　デザインを行い、チェックをお願いする…という場面は必ずあると思います。 何度もチェックをしてもらい、指摘をお願いすることを繰り返すと余分にコストがかかることになります。 その工数を防ぐためにも！チェックをお願いする前に一呼吸おいて 本当にこれが最善の案なのか 目的にあっているのか このデザインにした理由はなんなのか を自分自身に問い続けることが大事ではないか…と考えます。 　私自身、一度チェックをお願いしてご指摘いただいたことを見落として再度チェックをお願いしてしまったことが何度もありました。 自分自身のチェックは本当に大事です。 チェックする方がどんなところを見るのかを考え、これまで自分が失敗してしまったことを書き出してまとめておくことをしてから、少し改善したように思います。 5. 視野を広げる 　よく陥ってしまいがちなのが、現状のデザインばかりを見てその中で完結してしまうことです。 踏襲をする。という意味では品質を保つことができるのかもしれませんが、新規で制作をする際、新しいデザインでつくるとなった際には 引き出しがあればあるほどよいデザインが生まれやすいのでは…と考えます。 　今人気のサービスや、デザイン系のブログをチェックすることはよい刺激につながると思います。 私自身やっているのは電車の中の広告や、ポスター、CM等で使われているフォントやレイアウトについて考えてみることです。 　どのくらいのフォントや大きさか、余白はどうとっているのか、何を伝えたいものなのかを考えてみるととても勉強になります。 それらの広告やポスターをコーディングするとなったらどのタグを用いてどうコーディングするのかを考えてみても面白いです。 　以上、私にとってデザインをする上で大事なことを5つあげてみました。 正直この記事を書いていて、自分自身これらのことをできているのか、ということを振り返るよい機会になりました。 　ちなみに…以下これまでに制作してきたものの一部です。 6月時点 　→　 9月時点 → 　それぞれ左が初期に出した案、右が先輩方にチェックをしていただいた後に完成したものになります。 　6月に行ったものは賃貸住宅フェアというイベントに飾られたパネルのデザインです。 以前は文字組みや、余白に関して感覚で行っている部分があり、整えることができていませんでした。 　何をどんな順位で見せたいのかを考えるべきとのご指摘を受け、背景に色を引いたり、 文字の大きさを意味づけすることを意識し、完成させることができました。 　9月のものは卓上のカレンダーのデザインを行ったものです。 　このカレンダーの制作過程で変更した点はたくさんありますが、 当初、積もった雪を表現しようと地面の色を白くしていたため、 カレンダー部分と同化してしまっていました。 しかしそれでは実際にカレンダーを手にした人が違和感を感じるとの指摘を受け、 地面を明るい灰色に修正し、カレンダー部分との境目をわかりやすくしました。 　これまでの半年間を振り返り、入社時よりは、理由のあるデザインかどうか、どう考えれば伝わるものなのかを考えられるようになったと思います。 　入社してからデザインを学ぶ上で心に残っているのは、ある機会に耳にした 「センスがなくてもデザインはできる」 という上司の言葉です。そもそもデザイナーの方はセンスの塊ではないのか？と思っていたので衝撃的でした。 　その言葉を心に留めて、今回上げた基礎の部分がしっかりとできるようデザインの筋肉をつけていこうと思います。

こんにちは。 新卒2年目デザイナーのshinoです。   制作職、特にデザイナー・コーダーのみなさんは、通勤時間などのスキマ時間にスマホでウェブサイトを見て、「あ！このデザインいいな！」「この配色ステキだなあ」「このサイト、どうやってコーディングしているんだろう？」と思ったことがあるのではないでしょうか。   ただ、そういうときほど、PCを利用できない状況だったりしますよね。   わたしは、「会社や自宅に着いてからじっくり見よう…。」と保留にして、そのまま忘れてしまった経験がよくあります笑   できれば、気になったデザインはその場で保存したい！ コーディングもその場で確認したい！   そこで、今回はわたしが日ごろから利用している 「デザイナー・コーダー向けちょっと便利なiPhoneアプリ４選」 について、良いところと注意点を踏まえてお話ししたいと思います。   1.上から下まで画面をキャプチャー！ アプリ名：画面メモSS 画面メモSS - スクリーンショットを無音でフルサイズ保存できる無料アプリ urecy ユーティリティ 無料  ※ 互換性： iOS 8.0 以降。iPhone、iPad、および iPod touch に対応。   良いところ スマホサイトの気になるデザインを保存する際に重宝しています！ 撮ったスクリーンショットはアプリに保存＆タグでの管理ができるので、あとで探しやすいのもうれしいところ。もちろんカメラロールに保存もできます！   ▼例：アプリでホームズサイトのスクリーンショットをとってみた   注意点 transitionなどの効果がついている場合、透過・半透過した状態で保存されてしまうことがあります。   2.お手軽にカラーパレット作成！ ColorSchemer CHROMAom ユーティリティ 無料  ※ 互換性： iOS 4.0 以降。iPhone、iPad、および iPod touch に対応。   良いところ www.colourlovers.com COLOURloversというサービスと連携しているので、利用の際はアカウントを作成することをおすすめします。 アカウントを作成することで、作成したカラーパレットはPC・スマホ双方で確認・利用することができます！ カラーを指定する方法は何種類かありますが、おすすめは写真からの作成です。 綺麗な風景写真や電車内の広告で気になった配色を、カラーパレットとしてお手軽に保存できます。   ▼例：アプリでカラーパレットをつくってみた   注意点 カラー指定はセルフで指定をする必要がありますが、その分こだわったカラーパレットが作れると思います。   3.SublimeText風　HTML Viewer！ HTML Dual Viewer Makoto Nishimoto ユーティリティ 無料  ※ 互換性： iOS 8.4 以降。iPhone、iPad、および iPod touch に対応。   良いところ 左にブラウザ画面、右画面にHTMLソースが同時に表示され、それぞれの画面の幅調整も簡単に行えます。 Google検索にも対応しているので、URLを直接打つ必要がないのもいいですね。   ▼例：アプリでホームズサイトのHTMLソースを見てみた   注意点 HTML Viewerなので、CSSは確認できないですし、PC画面と比較するとやはり見づらい感じは否めないですが、スキマ時間にサッと見る分にはとても使いやすいと思います。   4.HTMLだけじゃ物足りない！aタグもCSSもScriptもimageもぜーんぶみたい！ Source Viewer Piet Jonas 辞書／辞典／その他 ¥120 ※互換性： iOS 4.3 以降。iPhone、iPad、および iPod touch に対応。   良いところ タイトルのとおり、リンクもCSSもScriptもimageもぜんぶ見れるのがうれしいですね。 特にCSSとScriptはブラウザで見れるようになっていたり、メールで該当ファイルのURLを送れるようになっています。   ▼例：アプリでホームズサイトのHTMLソースをみてみた（自動コード折りたたみ済）   ▼例：リンクもCSSもScriptもimageもぜんぶ見れます   注意点 有料なので、ダウンロードするには少し敷居が高いかもしれません。 また、HTMLに対応したCSSをピンポイントで見ることはできませんし、自動コード折りたたみ機能はありますが、厳密ではないようなので、場合によっては見づらいと感じるかもしれません。 HTML・CSSをそれぞれスキマ時間にサッと見る分には良いアプリだと思います。     いかがでしたでしょうか？ ご紹介した以外にも、多種多様な使えるiPhoneアプリがたくさんあります。 そのなかで自分にとって使いやすい、お気に入りアプリを見つけてみてはいかがでしょうか。   ほかにも、このiPhoneアプリ使いやすいよ！というのがありましたら、ぜひコメントで教えてください！ では！    

こんにちは、新卒入社１年目の椎橋です。普段の業務ではデータを予測したり、広告費を最適化したりと、データサイエンス業務を行っています。 今回は社内留学制度を利用して技術基盤部に留学してきました。社内留学制度とは、他部署に一定期間所属して業務をこなしながらスキルを磨いたり、新たな挑戦をしたりできる制度です。私は計算用サーバを使って大規模な計算ができるようになりたくて、その勉強のために留学しました。 技術基盤部は主にインフラの構築・監視・運用やレガシーシステムの刷新、他部署への技術支援などの非常に重要な業務を行っており、HOME'Sのサービスやエンジニアを支えている部署です。 留学で行ったタスクは、HOME'Sのウェブアプリケーションをサーバで動かすために必要なミドルウェアを洗い出し、ansibleを使用してサーバを構築することでした。 構成を理解する 構築してHOME'Sを動かす 感想 構成を理解する まずはHOME'Sが動作するために必要なミドルウェア及び各種設定内容などを調査し、理解する必要がありました。初めは何から進めればよいかもわからず、まさにゼロから始めるlinux生活でした。先輩に聴き、書籍やウェブページなどで調べて、関連するファイルを読みました。例えばhttpdを調べたときは、以下のように記述されていました。ただし、コメントアウト内容は実際のconfファイルには記述されていません。 $ view httpd.conf ... #サーバの基点ディレクトリ ServerRoot "/usr/local/apache2" #ポート番号を指定 Listen 80 ... それぞれの行で何を設定しているのかを調べていくと再び知らない言葉に遭遇し、それを調べて・・・というのを繰り返しました。 構築してHOME'Sを動かす AWSのインスタンスを新規作成し、調査した各種ミドルウェアのインストールや設定などを行い、HOME'Sのサイトが閲覧できれば一先ずＯＫなのですが、ここでも問題が起こりました。 下記のように、一つ一つコマンドを調べながらhttpdの設定を行っていきました。 $ sudo yum install httpd #httpdをインストール $ sudo chkconfig httpd on #httpdの自動起動設定 $ sudo /etc/init.d/httpd start #httpdの起動 この後、モジュールやバーチャルホスト、ドキュメントルートなどの設定を鈍足ながら行いました。しかし、あまり考えていなかったために元々のサーバと異なるバージョンのhttpdをインストールしていました。早く気づいていればNEW GAMEすることもできたのですが、すでに、ファイルの追加や書き換えをした後でしたので、作業済のファイルを残したままバージョンのみを変更しようと試みました。結果的にはバージョンの変更と共に設定すべき事項が多く、私では解決できなかったので、始めからやり直すことにました。バージョン確認は重要であることを痛感しました。 最終的な結果としては、なんとかHOME'Sをブラウザで表示できるようになったところで時間切れとなり、まだ設定すべき事項はあったのですが、完遂できませんでした。ansibleにも辿り着けず、当初の目標は達成できませんでした。 感想 タスクは終わりませんでしたが、コンピュータが苦手な私には良い勉強の機会になりました。独学では理解できなかった概念を身につけられたように感じます。私の本来の業務では、異常検知や最適化のプログラムを作成していますが、留学後にlinuxを触ってみたら、RやPythonの環境構築からcronで定期実行するまでできるようになりました。これで計算可能な問題が広がり、数理モデリングの制約が緩くなったような気がします。 挑戦したい人が挑戦できるような環境が社内に整っていることが伝われば幸いです。

こんにちは。おうちハッカーの石田@リッテルラボラトリーです。 みなさんは、 ReTech って言葉を聞いたことはありますか？ おそらく聞いたことのあるFinTechは、Financial Technologyの略で、金融をITや情報技術で新しいサービスを生み出したり、既存の問題を解決する動きのことです。 ReTechは、 Real Estate Tech の略で、 不動産領域の問題をテクノロジーで解決する 動きのことです。 アメリカでは、FinTechは既に様々な分野で技術が導入され、レッドオーシャン状態になっているため、次に来るのはReTechだ！と言われております。 http://www.mckinsey.com/ 　　 *1 こちらは、各産業において、どの程度情報技術が入っているかを示した図となります。 金融、保険については、図の上の方でほとんど緑となっており、かなり技術が入ってきていることが分かります。 一方で不動産領域は赤や黄色ばかりで、まだまだITが入ってきていません。 実際に米国では、Real Estate Techに対する投資が増加しているそうです。 zuuonline.com *2 そこで先日、 FIT2016 第15回情報科学技術フォーラム@富山大学 で行われたイベント企画、 「Real Estate Tech：不動産×IT 〜ITが拓く不動産の未来〜」に参加してきました。 *3 今回は日本における不動産×ITに携わる、 大手不動産ポータル、スタートアップ、研究者たちが一堂に会したReTechの最先端技術 の発表の模様をお届けしようと思います。登壇者の方々はこちらとなります。 ビジネスサイドとアカデミックサイドそれぞれ3講演ありましたので、前編では、ビジネスサイドの３講演をご紹介します。 「HOME'Sデータセット」提供を通じた不動産領域におけるオープンイノベーション促進の取り組み トップバッターとして、弊社の清田から発表させて頂きました。 「あなたにおすすめの物件はこれ！」といった物件の推薦は弊社でも研究を行っていますが、不動産物件の推薦アルゴリズムはとても難しいことが分かっています。 本や服といった商品などとの違いとして、ユーザーがより時間をかけて選ぶこと、立地や性能などの条件が複雑であること、同じ物件は一つしかないことなどがあります。 また選択に時間をかけると、賃貸で考えていたが購入してもいいかもと変わったり、家賃が高くて希望の駅が変わったりします。 そのため、「 このお部屋を見ている人は、こんな物件を見ています 」が通用せず、協調フィルタリングなどの一般的な推薦アルゴリズムでは効果が小さいと考えています。 こちらは、住まい探し行動を可視化した図です。 最も単純な住まい探し行動は、検索→問い合わせ→来店→内見→契約、といった流れですが、 HOME'Sで検索した数日後に、物件名の検索でHOME'Sに帰ってくるパターンがあります。これはおそらく、HOME'Sを見て内覧して、別の物件を紹介されたが不安なので、物件名で検索してHOME'Sにたどり着いたというパターンと推測されます。住まい探し行動には様々なパターン・ストーリーがあり、有効な物件の推薦がとても難しいです。 また他の課題として、 長期にわたって影響する意思決定をどのようにサポートするのか 、ということがとても重要です。 住まい探しの選択は、数年から数十年に渡ってその本人や家族に影響を与えますが、選択の際には将来どのような問題に直面するか分かりません。 そのギャップをどのように埋めてあげるか、ということが重要になってきます。 このように人生に大きく影響を与える住まい探しは、 複雑な意思決定プロセスをたどるため、様々な分野の知見を集めて学際的に取り組む必要 があります。 そこでオープンイノベーションの取り組みとして弊社は2015年11月より、 「HOME'S」の物件・画像データセットを研究者に提供 しております。 ありがたいことに、国内・国外合わせて35の研究機関の方に使って頂いており、データセットを用いた研究も発表されつつあります。 研究分野は、情報学をはじめとして、建築学、経済学、都市学などさまざまな分野に及んでいます。 講演スライドは、こちらに公開しております。 「HOME'Sデータセット」提供を通じた不動産領域におけるオープンイノベーション促進の取り組み from Yoji Kiyota www.slideshare.net SUUMOでの分析事例と不動産データ活用の未来 野村眞平様、李石映雪様（株式会社リクルート 住まいカンパニー ） SUUMOを運営している株式会社リクルート　住まいカンパニーのご講演でした。前半は野村様から、SUUMOにおける今までのデータ分析の取り組みを紹介されました。 さまざまな取り組みをしており、特に東大の松尾先生との共同研究である、将来のCVRを向上させるための推薦アルゴリズムの研究が興味深かったです。 人は何かを選ぶとき、様々なものを比較検討して選んで初めて、納得感のある選択をすることができます。 例えば、1億円, 3000万円, 5000万円の物件を見て、5000万円の物件に決める、といったことです。 納得感のある家探しのために、不動産情報ポータルとしては、 幅広い選択肢をユーザーに提供すること が重要です。 直近の問い合わせされやすそうな物件を推薦すると、同じような物件ばかり出てきて、視野が狭くなってしまいます。 そこで 次の次に問い合わせがされやすそうな物件も含めて検討 することで、幅広い選択肢を提示し、将来的な問い合わせ率の向上を目指す研究を行ったそうです。 後半は、李様が現在進行している研究についてお話しされました。 SUUMOでは、実験的にユーザーと不動産会社が直接チャットできるサービスを提供しているそうですが、そのログを用いて チャットの応答と来店率の研究 を行っているそうです。 このように、どのやり取りが来店率に影響を与えているかを分析しています。具体的な日時の話題になると、かなり来店率が高くなっていることが分かります。 これらを分析を通して、 ユーザーに来店してもらうには、不動産会社はどのような応答を行えばいいのか、支援する仕組み を作っていくとのことでした。 他にも、リアルタイムな個人最適化レコメンドページ、画像解析などの取り組みをご紹介いただきました。 推薦システム、画像解析、自然言語処理など幅広い分野でReTechをリードしていらっしゃると感じました。 実践的！　人工知能×機械学習 iettyの場合 小川泰平様（株式会社ietty 代表取締役社長） iettyは、自分の住みたい部屋の条件を登録すれば、最適な部屋をプッシュしてくれる——お部屋“探され”サイトです。 現在、不動産取引を行う際には、 重要事項説明を対面で行わなければいけない 、という決まりがあって完全にオンラインにできません。 しかしこれを 2017年を目途に法律を改正し、オンラインでの契約ができるようになり 、ネット証券・ネット保険に続き、ネット不動産仲介の分野が成立する予定です。 iettyはいち早くトライアルの業者として、オンライン化を進めているスタートアップです。 現在、ユーザーとのやり取りにおいては、 人手によるものと人工知能の自動応答によるもののハイブリット となっています。 人手の案内では、案内したユーザーの 4.28% が部屋の内覧まで行きますが、あまり多くのユーザーを案内することができません。 一方人工知能の案内では、非常に多くのユーザーを案内することができる一方、推薦アルゴリズムの精度の低さから、わずか 0.07% しか内覧に行きません。 まだまだ人による案内にはかなわないのが現状です。 しかしながら、人工知能での推薦の質を向上させることができれば、より多くのユーザーが内覧・契約までたどり着き、収益を劇的に向上させられる大きな可能性があります。 そこでさまざまな手法を実装し、試しているのですが、ベンチャーならではのやり方で評価を行っているそうです。 学術の分野で推薦アルゴリズムの評価は、データセットを分割し、ROC曲線などで定量的に評価します。 しかしiettyでは、まずは実装してみて、 プロの目で判断、とにかくサービスに実装してみて評価という素早い動きでサイクルを回して評価・改善 を行っています。 すぐに実践投入という、とてもベンチャーらしいやり方で素晴らしいと思いました。 後半に続く ここまで、ビジネスサイドの事例を紹介しました。次回はアカデミックサイドの不動産関連研究について紹介します。 *1 : 本イベントを企画された東大・山崎先生が導入に使われた資料となります。 *2 : 同じく山崎先生が導入に使われた資料となります。 *3 : 近い日程でFIT2016という同名のイベントが行われたようです。もう一つのFIT2016は日本最大のFinTechのイベントだそうです。 http://www.nikkin.co.jp/fit2016/

こんにちは。技術基盤部の磯野です。 ちょっと間が空いてしまいましたが引き続きZipkinです。 今回は Ruby + Sinatra で動いている Webアプリケーションへのトレーサーの導入です。 前々回の記事 → Zipkinを導入してみた（サーバー編） 前回の記事 → Zipkinを導入してみた（PHP編） 構成 CompositeAPIでの処理の流れ RestAPIでの処理の流れ 処理の流れを追跡するためのリクエストヘッダ app.rbの設定 (CompositeAPI, RestAPI共通) monkey_patch/zipkin_tracer の実装 HTTP::Requestクラス用のzipkinトレース処理用メソッド 使い方 結果 終わりに 構成 Rubyのライブラリは公式の zipkin-tracer を導入します。 構成はこのような感じです。 画像のアプリケーション・フレームワーク → Zipkin Sinatra CompositeAPIでの処理の流れ トレースデータの初期化(trace_id, span_idはWebサーバーからのリクエストヘッダに設定されている) マルチスレッドで非同期にRestAPIを複数呼び出し、その際にトレースデータを記録し、追跡するための情報をリクエストヘッダに付与する トレースデータを集計しjson形式でzipkinサーバーにhttpで送信する RestAPIでの処理の流れ トレースデータの初期化(trace_id, span_idはCompositeAPIからのリクエストヘッダに設定されている) 各データベースや全文検索エンジンなどにリクエスト送信、必要に応じてトレースデータを記録する トレースデータを集計しjson形式でzipkinサーバーにhttpで送信する 処理の流れを追跡するためのリクエストヘッダ 前回の記事 で説明しているので詳細は省きますが、以下はそのHTTPヘッダとその説明です。 HTTP Header Type 説明 X-B3-TraceId 64 encoded bits *1 リクエストごとに共通のID、これで追跡情報を紐付ける X-B3-SpanId 64 encoded bits *1 計測ごとに一意に決まるID X-B3-ParentSpanId 64 encoded bits *1 直前の計測のSpanId X-B3-Sampled Boolean (either “1” or “0”) *2 サンプリング対象かどうか X-B3-Flags a Long - *1 内部データは数値ですが、ヘッダに付与する際は16進数表現した文字列に変換します。 詳しくは以下URLの「HTTP Tracing」を参照してください。 http://zipkin.io/pages/instrumenting.html app.rbの設定 (CompositeAPI, RestAPI共通) 以下のように ZipkinTracer::RackHandler を useするだけですが、マルチスレッドでは正常に動作しなかったので、パッチを当てています。 class Application < Sinatra :: Base configure do require ' zipkin_tracer ' require ' monkey_patch/zipkin_tracer ' use ZipkinTracer :: RackHandler , { server_name : ' composite_api ' , service_port : 80 , sample_rate : 0.0 , json_api_host : http :/ /zipkin.example.com } end end monkey_patch/zipkin_tracer の実装 モンキーパッチはこんな感じです。 アプリケーション自身のTraceを親としたトレース情報を作れるように設定 スレッドで動くようにMutexでの同期処理を追加 parent_idがnilの場合zipkinが例外を吐くのでnilの場合リクエストに含めない（v0.18.2で修正済み） Trace .module_eval do class << self remove_method :with_trace_id def root_id @root || self .id end def with_trace_id (trace_id) first = false @root ||= begin first = true trace_id end self .push(trace_id) yield ensure self .pop @root = nil if first end end remove_method :stack , :push , :pop def mutex @mutex ||= Mutex .new end def stack mutex.synchronize do @stack ||= [] end end def push (trace) mutex.synchronize do @stack ||= [] @stack .push(trace) end end def pop mutex.synchronize do @stack ||= [] @stack .pop end end end Trace :: Span .class_eval do alias_method :to_h_original , :to_h remove_method :to_h def to_h data = to_h_original data.delete( :parentId ) if data[ :parentId ].nil? data end end Trace :: ZipkinTracerBase .class_eval do remove_method :spans , :store_span , :reset def mutex @mutex ||= Mutex .new end def spans mutex.synchronize do @spans ||= [] end end def store_span (id, span) mutex.synchronize do @spans ||= [] @spans .push(span) end end def reset mutex.synchronize do @spans = [] end end end HTTP::Requestクラス用のzipkinトレース処理用メソッド zipkin-tracerにはfaraday-middlewareが付属しているので、faradayを利用している場合にはほとんどそのまま利用できます。 今回はHTTPクライアントとしてNet::HTTPを直接使っている為、リクエストクラスにヘッダを追加する処理とZipkinのトレースデータの登録処理をまとめて行うメソッドを定義しています。 module CompositeAPI class ZipkinTracer class << self def trace_with_http_request (req) trace_id = Trace .root_id.next_id b3_headers.each do | method , header | req[header] = trace_id.send(method).to_s end return yield unless trace_id.sampled? res = nil Trace .with_trace_id(trace_id) do local_endpoint = Trace .default_endpoint remote_endpoint = Trace :: Endpoint .make_endpoint( ' 0.0.0.0 ' , 80 , ' restapi ' , local_endpoint.ip_format) Trace .tracer.with_new_span(trace_id, req.method.to_s.downcase) do | span | uri = URI .parse(req.path) span.record_tag( Trace :: BinaryAnnotation :: URI , uri.path, Trace :: BinaryAnnotation :: Type :: STRING , local_endpoint) span.record_tag( ' http.query ' , uri.query.to_s, Trace :: BinaryAnnotation :: Type :: STRING , local_endpoint) span.record_tag( Trace :: BinaryAnnotation :: SERVER_ADDRESS , ' 1 ' , Trace :: BinaryAnnotation :: Type :: BOOL , remote_endpoint) span.record( Trace :: Annotation :: CLIENT_SEND , local_endpoint) res = yield span.record_tag( Trace :: BinaryAnnotation :: STATUS , res.code.to_s, Trace :: BinaryAnnotation :: Type :: STRING , local_endpoint) span.record( Trace :: Annotation :: CLIENT_RECV , local_endpoint) end end res end def b3_headers { trace_id : ' X-B3-TraceId ' , parent_id : ' X-B3-ParentSpanId ' , span_id : ' X-B3-SpanId ' , sampled : ' X-B3-Sampled ' , flags : ' X-B3-Flags ' } end end end end 使い方 req = Net :: HTTP :: Get .new( ' http://restapi.example.com/path/to/resource?key=1 ' ) CompositeAPI :: ZipkinTracer .trace_with_http_request(req) 結果 以下の赤で囲った部分が今回の作業により記録されるようになります。 終わりに zipkin導入に関しては一旦以上で終わりになります。 今回、WebSite, CompositeAPI, RestAPIの３層構造のアプリケーションにzipkinを導入しましたが、普段見れない各サービスの積み重ねの部分が視覚化できた事はとても有意義でした。 軽く見ただけでも、以下のような問題に気付く事が出来ました。 各APIやミドルウェアの呼び出しでどこがボトルネックになっているか（視覚的に認識できる） CompositeAPI → RestAPIの部分で並列にリクエストを投げられるところで直列で行っている CompositeAPI → RestAPIの呼び出しを無駄に行っていた(キャッシュでごまかしていた為初回のみ遅い) まだ各サービスの改修には至っていませんが、これらを一助としてサイトの高速化やマイクロサービス化を推進していけそうです。

こんにちは。 ホームズくんを描いたりしている"ママデザイナー"のモリです。   入社6年目。昨年出産をして、この4月に復職しました！ 出産してもデザイナーとして働ける環境があることだけで、本当にありがたや、ありがたやですね。 そして、この夏。 3週間（週2日）在宅ワークしてみました！   在宅ワークをしてみて良かったこと、困ったことをお伝えします。     そもそもなぜ在宅ワークするのか もともと、子どもは4月から保育園に預けていたのですが、転居のため保育園も転園に。   転園先が決まっても、じゃあ初日から9h(8:00~17:00)保育お願いします！ ...というのは子どもも保育園も大変ですよね。   なので、どの保育園でも基本的には保育開始日から5日前後は慣らし保育期間を設け、1日数時間ずつ保育の時間を増やしていき、徐々に9hの保育に慣れるようにします。 つまり、その期間通常の通勤、勤務ができなくなります。 なので、会社のありがたい制度を利用して、週に2日在宅ワークをすることになりました。 (弊社では現在週2日が最大です)     まずは業務環境 勤務時間 9:00~16:00(休憩1h含む) 子どもは保育園に預けてあります。 PCは会社から貸与されたノートPCとiPadPro（＆applepen） 社内メールは見れます。 社内環境アクセスできます。 skypeMTGできます。 adobe系ソフト使えます。 ちょっとしたやりとりはChatworkで 基本的に問題なく業務はできました！不便だと思うこともほぼなかったです。 この環境を整えてくださった方々に感謝。   やってみて良かったこと すっぴん可(社会人は礼儀程度のお化粧はするものと教わりました) 裸足で良い 空調が思いのまま 声をかけられたり電話もならないので音楽を聴きながら作業ができました。 考えることに集中できました。 休憩時間で自炊できるので、節約に。 通勤時間がなくなるため、朝の準備、夕飯の買い物・支度に余裕ができました。 子どもを預ける時間が2h減って、いつもより長く一緒にいられました。 子どもの急な熱などによる保育園からのお迎え要請にもすぐに対応できます。   やってみて困ったこと 貸与されたPCはデザイナー用ではないのであまり解像度もよくないのと、 色もうまく見れない。 (PCを変えるorディスプレイの調整をすればいけるかも？) 社外秘を取り扱うことになるので印刷ができず、印刷ものの色がわからない。 貸与されたPCはデザイナー用ではないので、基本のフォントしかインストールされていない。 (デザイナー在宅ワーク用PCがあればよいかも。) ちょっと言えば、ちょっと見せればわかることを 文章にして伝えるのが面倒くさい 寂しい オフィス、チームの空気がわからない。     まとめ まずは働く人として。 私はデザイナーはやはりコミュニケーションが大切だと思っているので、 「毎日在宅ワークで」 というのはコミュニケーションに時間がかかるため厳しいなと感じました。 また、チームの中での連携という部分でも難しい点は多くあると思います。   後輩の育成に関しても、注意したり、ほめたりというのは その場にいるからこそできることだと思うので、この点にも在宅ワークの課題はあると思います。   しかし、週に数日という条件であればコミュニケーションの部分も大きな負担ではないと思いますし、 むしろ限られたコミュケーションの時間でいかに正確に伝えるかということも工夫せざるを得なくなるので、 効率が良くなる部分もあると思います。   また作る人として、考えることや手を動かすことに集中できる環境があるというのは とても良いと感じました。 (これは頑張ればオフィスでもできるかもしれないですが、なかなか難しいですね。)   最後に母としてですが、 通勤の時間(2時間強)がなくなっただけで、朝夕のバタバタがなくなり、 時間と心にだいぶ余裕ができたというのが正直な感想です。 心に余裕が生まれると、良いアイデアが！、、、、 とは言い切れませんが、仕事にも子育てにも良い効果はあるかと思います。   もしこの２時間が余裕としてあるのであれば、１時間は業務時間として増やせるかもしれませんし、 そのまま子供と触れ合う時間として残しておくのも良いかもしれません。 1時間早く帰れれば、子供の通院などもだいぶ楽ですね。   在宅ワークになると現状のような時間給が適切なのかなど、 いろいろ検討すべき点は多くあると思いますが、 働くママにとって在宅ワークは本当に救いの手になりそうです。    

  こんにちは。 HOME'Sアプリのデザイナーのこばやしです。   Androidアプリを育てていくと、ひとつの課題に行き当たります。 アプリリソースサイズです。   機能追加、ダイナミックな画像表現などで、気づいたら「ゲームアプリ？」と思うほどリソースサイズが増えているかも…。 そんな時、ひょっとしたら劇的にスリム化できるかもしれない方法をご紹介します。 HOME'S Androidアプリでも実際にやった内容です。 ==== Google deveroparsの記事「 Google Play におけるアプリのダウンロード サイズの削減 」に記載もある WebP が今回紹介する内容です。 googledevjp.blogspot.jp   記事の一文に、 3. APK の構成要素のサイズを減らすことによる最適化: たとえば、JPEG ではなく WebP を使用するなど効率的なファイル形式を使ったり、未使用コードを削除するために Proguard を使用したりします。 とあります。   記事にもあるように、インストールする際にアプリサイズが大きいと通信量を気にしてしまい、それが要因で優れたアプリでもインストールされない、なんてこともあるかもしれません。 そこで今回、画像リソースをWebPに変換することでどのぐらいアプリリソースを削減できるのか。 そしてHOME'S Androidアプリにおいて、実際どのぐらいリソースを削減することができたのかをお話します。 webP（Weppy＝ウェッピー）とは Googleが開発した圧縮形式で、従来の形式よりもファイルサイズを小さくすることを目的としています。 Googleが持つVP8コーデックを用いたWebMという動画フォーマットをベースとしており、WebMの1フレームだけを切り出したものがWebPで、それをRIFFという軽量なコンテナに格納した形式になっています。 https://developers.google.com/speed/webp/   特長 可逆 / 非可逆圧縮が可能 透過 (アルファチャネル) が可能 写真の圧縮にも向いている アニメーションが可能 写真画像においても効果的に圧縮できるのが非常に強い特長だと思います。 ※非可逆のWebPはAndroid OS 4.0以降でサポート、ロスレス圧縮のWebPは4.2.1以降でサポート   サポート Chrome Opera (12.0~) Android Browser (4.2~) Chrome for Android JPEGやPNGといったメジャーな画像保存形式のようにはまだ普及しておらず、現段階だとかなり限定的に効果を発揮する形式だといえます。 http://caniuse.com/#feat=webp   ツール WebP Library Pixelmator Leptonica Photoshop Plugin WEBPコンバーター 公式のライブラリ、オーサリングツールなどで生成できます。 比較 アプリ内で実際に使用しているPNG画像、それをWebP化した画像で比較してみます。 ※WebPは表示させるためにブラウザで表示したものを撮影しています。容量はWebPのものを記載 WebP 2.88KB png 6.73KB このポーズのホームズくん、可愛い。 小さめのイラストですが、およそ半分に削減できています。 見栄えも変わりありません。 次は写真、複雑なビットマップ画像で試してみます。 WebP 27.4KB PNG 560KB 先程のイラストより高い圧縮率となりました。 肉眼ではほとんど区別つかないですが、およそ1/20のサイズに…これはスゴい。 実際にアプリで見てみます。 before after 意図したとおりに表示されてます。 大丈夫そうです。   アプリで使っている画像をどんどん置き換えてみる   Android studioのAnalyze APKを使い、容量が大きい画像をWebPに変更してみました。 すると… 13.2MBから6.3MBとおよresの 容量が半分に。 半分です。 ※2016年8月時点 画像リソースはアプリ全体の半数以上を占めていましたが、WebPを用いることで簡単に削減すること成功ができました。 画像の品質は下げたくない、けれど容量を使いすぎるのも…という課題に対しても効果的です。 アプリの表示速度や低スペック端末への配慮としても、一役買ってくれそうです。 まとめ 可愛い名前なのにスゴいやつ！ iOS対応やブラウザの対応拡大が待ち遠しい。 実は以前にもWebPを試したことがありました。 しかし当時は挙動が安定していなく使用を断念しました。 最近は4.x系でもSVGをフルサポートするなど、Androidアプリ開発環境がグングン良くなっています。 そんな中で改めて試してみたWebPはAndroidアプリでリソースを削減する手段としてとてもおすすめです。 「 Android Appにおいて、かつサポートしているOSバージョンが4.1.x以上の場合はおすすめ 」といえるのではないかと思います。 ですが、これから普及していくであろう新しい規格のため、考慮すべき点もあります。 「WebPとは」のところで記載してある、サポート範囲と特長のAndroid OSバージョンによる制約を改めて確認し、上手に利用してみてください。

   はじめまして！新卒入社１年目のミーコです。 初めてデザイナーズブログを書きます！よろしくお願いいたします。 今回は「ネクストのデザイナーってどんな人がいて、どんなことしてるんだろう？」や「新卒のデザイナーってなにするの？」というような就活セミナーや面接では聞けないであろう情報も含め、新卒１年目から見たネクストデザイナーの１日をモリモリ紹介いたします！   まずは私の自己紹介から。 ３月に大学を卒業し、４月に株式会社ネクストに入社しました。社会人１年目のひよっこデザイナーです。 ネクストに入社を決めたのは〜・・・長くなるのでやめておきますが人に喜んでもらえるようなデザイナーになりたいと常に思いながら日々、業務をしております。   ざっくりと１日を紹介すると です！本当にざっくりですね。でもこんな感じです。 それではこれから細かく紹介していきますねっ！   出社 始業開始は10時です。 10時に会社にいれば早く来てもゆっくりきても大丈夫です。 出社後は１日のタスク・メールを確認し、お仕事スタート！    仕事（午前） 入社５ヶ月目ですが、今までやってきた仕事は 広告やバナーの制作 民泊事業に関するインフォグラフィックスの制作 ホームズくんを使用したイラスト制作 ▼例  竹うちわのデザイン ラッピングバスのデザイン ▼例 ビーチサンダルのデザイン などなどです。これはほんの一部なのでさらに書き出せばもっともっと色んなことしてますヨ。   自分がデザインしたものが世に出ていると思うと嬉しいですよねっ！ ネクストデザイナーは１年目からこんな嬉しい経験ができますよ〜＾＾☆   デザインをする上で ・ラフ案は最低３つ以上出す ・何のために、誰のために作るのかを考える を大事にして制作しています。   ラッピングバスをデザインする時は、 いつ・どこで・なぜバスを走らすのか、それによってどうなるべきなのかを考えたり、バスを乗る人の気持ちになってデザインしました。 わからないことがあればいつでもグループの先輩や、周りの方に助けてもらっています。 丁寧に指導してくださるネクストの社員の皆さんは本当に優しいですよ〜＾＾☆   お昼休み デザイナーやエンジニアのものづくりメンバーは基本社内にこもっているのでお昼休みが唯一デスクから離れて外に出るチャンスです！ コンビニで買って食べることもありますが、外に食べに行くことが多いです！ 同期・先輩や、お世話になった採用人事の方、なんと秘書の方ともランチに行けます！ 品川のランチを制覇することが今期の目標です。  定食や～ お肉料理など～ 肉・魚・米・うどん・そば・ラーメン・パスタなど食べたいものは品川には揃っているので毎日美味しいものを食べられます。幸せです。 昼休みはちゃんと１時間取れますよ〜＾＾☆   仕事（午後） お腹いっぱい〜になったところで午後の仕事スタートです。 午前中にやっていたことの続きだったり、ミーティングが入っていたりなど19時まで業務をこなしています。 あっ、15時になったら会社にくる郵便を社内の人に配達しています。これも新卒の重要な任務です！ 社内の人の顔と名前を覚える＆覚えて頂くチャンス！今ではすっかり配るスピードも速くなりました！   退社 新卒は残業しちゃダメと言われているので19:00になったら帰っても大丈夫です。 入社前の勝手なイメーシでは遅くまで仕事してるんだろうな〜と思っていましたが、そんなことはないはずです。 これはあくまで新卒デザイナー個人の意見なので、わかりませんが・・・・ 私は19時過ぎたらきりの良いところで作業はやめて、日報を書き20時には退社できるようにしています。 帰宅してコーディングの勉強（通称：地獄のcodingトレーニング）に励んでいます。   こんな１日です。いかがでしたか？？   伝えたいことは３つ！   新卒1年目からジャンルにとらわれないものづくりができる ネクストは優しい人が多い お昼においしいご飯がたべられる  以上です。   最後までご覧頂きありがとうございましたっ 次回の更新ではちょっと特別な1日を紹介しちゃいます！お楽しみ！ では！  

はじめまして、技術基盤部の相原( kaihar4 )です！ 今回は、アプリケーションのクラウドサービスへの移行の一環で、 Amazon S3から取得した画像URLを含むファイルを元に、そのURLの外部画像を取得して返す機能 を mruby で書き直してAWSに移行した話をしていきたいと思います。 この機能は元々モノリシックなアプリケーションの一機能として動いていたもので、これを切り出してAWSに移行するというのが今回私に与えられたミッションでした。 このアプリケーションは歴史が長く、その間ほとんどメンテナンスされていませんでした。 ディストリビューションは古くPHPのバージョンも4系、したがってそのまま持っていくという選択肢はなく、AWS上に新規にインスタンスを構築することになります。 弊社にはAPI部分をPHPからRubyに移行する方針があるということもあり、Amazon Linux上にRubyで書き直したこの機能を移行するというのが妥当な線でした。 しかしアプリケーションの性質上Unicornはプロセスモデル的に適さないですし、そもそもこれだけの機能のためにアプリケーションサーバを用意するということにも違和感がありました。 そこであがってきたのが、 mruby でこの機能を実装し ngx_mruby で動かすという選択肢です。 mruby であればRubyと(ほぼ)同じシンタックスで実装することができ、それを ngx_mruby で動かすことでウェブサーバがそのままアプリケーションサーバとして振舞うことができます。 開発者を多く確保できる mruby と弊社での運用実績があるnginx、これらを使う旨を運用チームへ相談の末、このプランで行くことに決まりました。 このように置き換わるイメージです。 元々キャッシュをするように作られていなかったので、この機会にRedisによるキャッシュも入れました。 ロゴ: Amazon S3 , redis ここからは mruby と ngx_mruby についてと、いかにこれらでこの機能を実装したかについて書いていきます。 本エントリを通してmruby + ngx_mrubyでアプリケーションを実装するという選択肢の現実味を感じていただければと思います。 mrubyとは ngx_mrubyとは mruby + ngx_mrubyでアプリケーションを実装するには YAMLから情報を取得する クエリストリングを元にAmazon S3からファイルを取得する 取得したURLをRedisにキャッシュする 取得したURLにリクエストして画像を取得して返す まとめ mrubyとは mruby とは ISO を元に実装されたRuby1.9互換のシンタックスを持つ組み込み向けの軽量言語です。 様々な分野に活用事例があり、ウェブの領域でも mod_mruby や ngx_mruby などで利用されています。 最近では h2o に採用されたことも記憶に新しいですね。 この言語の最大の特徴は軽量言語ゆえの省メモリな設計です。 mruby 本体には必要最低限の機能しか実装されておらず、例えばファイルの読み書きやHTTPのリクエストなどはサポートされていません。 これが組み込み向けとされる所以で、これのお陰で非常に少ないメモリで動作することが可能です。 そして、この必要最低限の機能を支える仕組みがmrbgemsです。 mrbgemsとはRubyで言うところのRubyGemsにあたるもので、有志が mruby にない機能を実装しmrbgemsとして多数公開しています。 このC言語または mruby 自身で書かれたmrbgemsを mruby と共にコンパイルすることで、それらが起動時に読み込まれ、その機能を利用できるという仕組みです。 mgem-list に登録されたmrbgemsであれば、 mruby 側が自動で依存関係を解決してくれるという強力な仕組みも備わっています。 これらを利用することにより、 mruby には一般的なプログラミング言語と遜色ない機能が実現されているのです。 ngx_mrubyとは 次は、先ほど mruby の活用事例としても紹介した ngx_mruby です。 ngx_mruby は、nginx上で mruby を実行できるようにするnginxの拡張です。 同じく先ほど活用事例として紹介した mod_mruby はこれをhttpdで実現したものとなります。 ngx_mrubyを使うことで、以下のようにnginx内で mruby を実行することができます。 location / hello { mruby_content_handler_code ' proc = Proc . new do | env | [ 200, { "Content-Type" => "text/plain;charset=utf-8" }, ["Hello World" ] ] end run proc '; } これらを使って mruby でウェブサーバの設定ファイルを記述することで、他の mruby を実行できるウェブサーバと設定を共有することができます。 秘伝のrewriteルールなども mruby で記述することによってウェブサーバ間で使い回すことができ、さらにはテストコードを書く事で保守しやすいものへとリファクタリング可能です。 このウェブサーバ上で mruby を実行できる仕組みを使ってアプリケーションを実装するというのが今回の主題です。 mruby + ngx_mrubyでアプリケーションを実装するには さて、ようやく本題です。 今回実装する機能の要件は以下の通りです。 アプリケーションを実装する際によくある要件だと思います。 YAMLから後述のRedisに接続するための情報を取得する 与えられたクエリストリングを元にAmazon S3からファイルを取得する Amazon S3から取得したファイルからURLをパースする そのURLをRedisにキャッシュする そのURLにリクエストして画像を取得して返す これらをmrubyでどうのように実現するのか順に追っていきましょう。 YAMLから情報を取得する アプリケーションを開発する際には、大抵設定ファイルを読み込んでRDBMSなどへの接続情報を得るといったことが必要になると思います。 これを mruby で実装するとどのようになるか見ていきましょう。 これは以下のような処理で実現することができます。 YAML .load( File .open( ' /path/to/yml ' ).read) 使用しているのは以下のmrbgemsです。 mruby-yaml mruby-io mruby-yaml では YAML.load_file は実装されていないため、 mruby-io で File.open と IO#read を使っていますが、Rubyでも動く完全Ruby互換のコードとなっています。 ただ、これをRedisに繋ぐたびに実行するのはio的にコストなので、初回だけの実行にしたいところです。 しかし、 ngx_mruby ではリクエストごとに mruby のオブジェクトが初期化されてしまいます。 そこで使うのが mruby-userdata という、mrb_state構造体を介してオブジェクトを mruby プログラム間で共有するためのmrbgemsです。 初回に mruby-userdata を使用して接続情報をmrb_stateに入れておき、以降はそこから取り出すことで無駄な処理をなくすことができます。 ngx_mruby には mruby_init という起動時にのみ実行されるディレクティブがあるので、以下の処理を記述したファイルを指定することでこれを実現することができます。 mruby_init /path/to/init.rb; server { } # init.rb config = Userdata .new( ' config ' ) config_file = YAML .load( File .open( ' /path/to/yml ' ).read) environment_config = config_file[ ENV [ ' ENV ' ]] config.redis = environment_config[ ' redis ' ].map {| k , v | [k.to_sym, v] }.to_h mruby-env を使えば、 ENV 定数によって環境変数を取り扱うことができるので、環境変数によって読み込む設定を切り替えるといったことも可能です。 環境変数は単純に /etc/sysconfig/nginx から渡すことができます。 # /etc/sysconfig/nginx export ENV=production クエリストリングを元にAmazon S3からファイルを取得する 次はAmazon S3へリクエストを投げる部分です。 ngx_mruby では rack-based-api を採用しているので、以下のようなファイルを mruby_content_handler ディレクティブに指定することで mruby を実行することができます。 末尾の cache をつけると mruby のコードをnginxがキャッシュするようになります。 location /hello { mruby_content_handler /path/to/client.rb cache; } # client.rb class Client def call (env) end end run Client .new Kernel.#run に渡すオブジェクトは #call メソッドを実装している必要があるのでProcオブジェクトでも可能です。 そして、その #call メソッドの引数として得られる env オブジェクトにクエリストリングをはじめとした情報が格納されています。 env['QUERY_STRING'] に丸ごと入っているので以下のようにパースすると扱いやすいです。 # client.rb class Client def call (env) params = env[ ' QUERY_STRING ' ].split( ' & ' ).map {| kv | kv.split( ' = ' ) }.to_h end end run Client .new 次にAmazon S3に繋ぐ処理ですが、今回はAmazon Linuxを使用しているため、IAM RoleからAccess Tokenを取得してきてそれを使いたいところです。 http://169.254.169.254 からHTTPで取得するため、 mruby-simplehttp を使います。 またこれも同様に毎回取得する必要はないので、先ほどの mruby-userdata を使って init.rb で初回時にのみ実行するようにしましょう。 IAM Roleの名前は可変なので mruby-env を使って ENV 定数により環境変数から与えることにしています。 # init.rb . . . metadata = Userdata .new( ' metadata ' ) metadata.iam_role = ENV [ ' IAM_ROLE ' ] json_credentials = SimpleHttp .new( ' http ' , ' 169.254.169.254 ' , 80 ).get( " /latest/meta-data/iam/security-credentials/ #{ metadata.iam_role }" ).body metadata.credentials = JSON .parse(json_credentials) # /etc/sysconfig/nginx . . . export IAM_ROLE=remote_image mruby にはもちろん標準でjsonモジュールはありませんので、レスポンスのjsonのパースにはmrbgemsを使います。 類似のmrbgemsが多数存在しますが、ここでは mruby-iijson を使っています。 あとはここで取得したクレデンシャルを用いてAmazon S3にリクエストするのみとなります。 init.rb で起動時に mruby-userdata に入れてあるので取り出してリクエスト時に使用します。 Amazon S3へのリクエストにはちょうどいいmrbgems、 mruby-aws-s3 があるのでこれを使いましょう。 #3 にてIAM Roleから得られるSecurity Tokenに対応したので今回のようなパターンでも利用することができます。 便宜上、先ほどパースしたクエリストリング内にAmazon S3から取得する 画像URLを含むファイル へのパスが含まれているものとします。 # client.rb class Client def call (env) params = env[ ' QUERY_STRING ' ].split( ' & ' ).map {| kv | kv.split( ' = ' ) }.to_h metadata = Userdata .new( ' metadata ' ) credentials = metadata.credentials s3 = AWS :: S3 .new(credentials[ ' AccessKeyId ' ], credentials[ ' SecretAccessKey ' ], credentials[ ' Token ' ]) response = s3.download(params[ ' path ' ]) end end run Client .new これでAmazon S3から 画像URLを含むファイル を取得することができました。 ここでの注意点として、初回時にのみクレデンシャルを取得するようにしていると、これらのクレデンシャルが期限切れになった場合に対応することができません。 Access Key IdもしくはSecret Access Keyが異なっている場合は 400 が、Tokenが異なっている場合は 403 が repsponse.code として得られるのでクレデンシャルの再取得の処理が必要です。 取得したURLをRedisにキャッシュする Amazon S3から取得した 画像URLを含むファイル はjsonなので、ファイルから外部画像のURLをパースする処理は、先ほどと同じ手順で response.body をパースするだけなので割愛します。 ここではAmazon S3へのリクエスト数を減らすためにRedisでキャッシュを行います。 これもよくあるパターンですが、もちろん mruby でも実現可能です。 これには mruby-redis を使います。 接続情報は先ほど init.rb にて取得してあるのでそれを使います。 # client.rb class Client def call (env) . . . config = Userdata .new( ' config ' ) redis = Redis .new(config.redis[ :host ], config.redis[ :port ]) redis.set(key, target_url) end end run Client .new 実際にはRedisのキャッシュの有無を確認してAmazon S3へリクエストを送るかどうかを判定する必要がありますが、ここでは割愛します。 今回はRedisにAmazon ElastiCacheを利用していてバックエンドのRedisが複数台いるため、負荷分散のために都度コネクションを張っていますが、特にそういった事情がない場合は、Redisのコネクション自体を mruby-userdata で共有して使いまわすことでコネクション開始時のオーバーヘッドを無くすことができます。 取得したURLにリクエストして画像を取得して返す 最後の処理です。 HTTPのリクエストを送るために、先ほどクレデンシャルを取得するのに使用した mruby-simplehttp を使います。 またこの例では、 mruby-http を使用してクエリを組み立てています。 ngx_mruby が採用している rack-based-api では、 Kernel.#run メソッドの引数に与えるオブジェクトが #call メソッドを実装している必要があることに加え、レスポンスとして返す #call メソッドの返り値が以下の例にあるような status code 、 header 、 body を含んだ配列でなければならないという制約があります。 # client.rb class Client def call (env) . . . uri = HTTP :: Parser .new.parse_url(target_url) request_query = uri.query ? "#{ uri.path } ? #{ uri.query }" : uri.path response = SimpleHttp .new(uri.schema, uri.host, uri.port).get(request_query) unless response.code.to_i == 200 return [ 404 , { ' Content-Type ' => ' text/plain;charset=utf-8 ' }, [ ' not found ' ]] end [ 200 , { ' Content-Type ' => ' image/jpeg ' , ' Content-Disposition ' => ' inline ' }, [response.body]] end end run Client .new このように配列をメソッド内で返すことで、ついに取得した画像をレスポンスとして返すことができました。 長くなりましたが、以上でこのアプリケーションのおおまかな処理は完成です。 まとめ このように、軽量言語の mruby でも強力なmrbgemsを駆使することで一般的なプログラミング言語と遜色ない処理を実行させることができました。 言語自体の単純な実行速度はRubyと比べると一長一短 *1 で単純にどちらが早いとは言い切れませんが、より少ないメモリで動作し、別途アプリケーションサーバを必要としない mruby の採用は一考の価値がありそうです。 弊社ではすでにこのアプリケーションが本番環境で動いており、200万req/dayを受けながら安定稼働しています。 mruby でこういったアプリケーションを書くことの是非は今後の運用を通して判断していきたいです。 *1 : RubyではC言語で実装されていたメソッドがmrubyだとmruby自身で実装されているケースがあり、その場合はmrubyの方が実行速度が遅い

こんにちは！新卒入社2年目デザイナーのカンバラとタカラベです。 2人とも、HOME'Sのサイト改修やノベルティの制作などをしております。デザインテクニックと合わせて、不動産業界の動向も日々勉強の毎日です！ そんな中、DIYに詳しい先輩デザイナーにお誘いいただいて、人気に火がついていると噂の『カスタマイズ賃貸』で最先端をいく賃貸マンション「 ロイヤルアネックス 」にご訪問させていただきました。 カスタマイズ賃貸？ロイヤルアネックス？ 「 ロイヤルアネックス 」とは、東京都・豊島区にある13階建ての賃貸マンションです。 単純に広さや設備の部分を見ると一般的なマンションとほぼ同じです。が！実際は満室状態が続いており、部屋によって入居待ちが出ているほど！ 「な、なぜ賃貸マンションに入居待ちが！？」 人気の秘密のひとつには、『カスタマイズ賃貸』のマンションだということでした！ カスタマイズ賃貸とは、注文住宅や新築だけでなく、賃貸でも居住者が部屋の壁紙や床材などを自由にカスタマイズできるお部屋のことです。 そんなロイヤルアネックスでカスタマイズ賃貸を仕掛けたのは、株式会社メゾン青樹の青木純さん。 実は、以前弊社で中古マンションの敏腕事業責任者として名を馳せていた方で、退職後にご実家の賃貸マンションを引き継がれたそうです。 賃貸マンションでも、もっと暮らしを楽しめる人を増やしたい。 そのために、壁紙を選べるようにしよう。 青木さんの想いが、今のロイヤルアネックスの原点だったそうです。  これが賃貸！？カスタマイズ賃貸の紹介 青木さんをはじめ、ロイヤルアネックスの方々にたくさんの素敵なお部屋を見学させていただきました！ 今回は、私たちが特に興奮したカスタマイズ賃貸を2部屋ピックアップします。 かっ可愛すぎる！！これなら私もできるかも！サラさんのお部屋 1部屋目は株式会社メゾン青樹の新入社員である、サラさんのお部屋をご紹介します！  サラさんのお部屋は、ビビッドな黄色と青の原色に彩られた壁と、「額縁柄」の壁が絶妙な調和をみせております。 ベッド正面に貼られたいろんな形の「額縁柄」の壁紙には、ところどころスケッチや小物類が飾られ、本物の「額」のような役割を与えられています。 冷蔵庫の扉や本棚の側面に黒板塗料を吹きかけており、チョークで字や絵が描けるようになっているのも素敵でした。 驚くべきことに、壁紙や床材はサラさんご自身が貼ったそうです！どこで材料を仕入れたのかも優しく教えてくださり、「なんだか私にもできそう！」と思わせてくれたお部屋でした。 ちなみに、ご入社されたきっかけは何だったのでしょう？同じ新卒入社の身として気になり、こっそり伺ってみました。 大学時代にまちや地域に興味を持ち、 活動している中で青木さんと出会いました。 リノベーションスクールへの参加を通して、青木さんの取り組みに関わりを持ちはじめ、その後、入社を誘ってもらいました。 「ほしい暮らしをつくること・人やまちとつながりのある暮らし方」がここでならできるのではと思って、入社を決めたんです！ なんて素敵なのでしょう... そんなサラさんは、会社と自分の部屋が同じ建物にあるため、通勤はエレベーターで30秒。Instagram「 30秒通勤女子の日常 」で日々の暮らしを発信されています。是非ご覧ください！ 全てオーダーメイド！ルーム名は「KOJAK」 ロイヤルアネックスには壁紙だけでなく、間取りも自由に変えてしまう「オーダーメイド賃貸」のお部屋もあります！ なんと、隣り合ったワンルームが2部屋空いたのがきっかけで、仕切っていた壁を壊して、1部屋に繋げてみたそうです！ そのため、こちらのお部屋は玄関が2つあり、お邪魔する前から驚きでした！（写真が残っていなくてごめんなさい…） 内装も入居者の方のセンスが光る素敵さ。鮮やかなタイルの敷き詰められたキッチンや、ステンドグラスのついた押入れ収納が、大人のオシャレな空間を作り出していました。  カスタマイズ賃貸の魅力 皆さん、ロイヤルアネックスのカスタマイズ賃貸はいかがでしたでしょうか？ 見学した私たちは、1つ1つの部屋がアトラクションのように見えて、それはもう、わくわくしっぱなしでした！ なんといっても、 どこにでもあるごく普通の小さくて真っ白な部屋が、 少し手を入れるだけでその人オリジナルの空間になること 。 賃貸マンションに持っていた固定概念が、崩れていくような衝撃でした。 意外とカスタマイズは簡単にできる カスタマイズ賃貸に興味を持った人の最初のハードルは、「やってみたいけど、手間がかかる」ではないでしょうか。 賃貸マンションを自分好みのお部屋にするには、お金も時間も、手間もかかると思いがちです。 しかし、今回の訪問でお話を伺ったところ、貼ったり剥がしたりできる壁紙や、床に乗せて組み合わせるだけでできる無垢の木を使った床材なども増えてきたそうです！ こういった手軽な材料も増えてきたことにより、カスタマイズへのハードルが 一気に 下がっているそうですよ！ HOME'Sができること 今回、私たちはロイヤルアネックスに訪問して、カスタマイズ賃貸の魅力、そこに住む人々の幸せそうな暮らしかた、大家さんの熱い想いを肌で感じることができました。 HOME'Sは住まい探しのポータルサイトであり、均一で精度の高い物件情報を多くのユーザーに届けることを目指しています。 しかし、それだけではなく、ロイヤルアネックスのような魅力的で新しい暮らし方も提案していきたい！そう思わせてくれる場所でした。  そのためには、まずカスタマイズ賃貸というもの自体を多くの人に知ってもらう必要があります。少しずつではありますが、下記のようなキャンペーンを通して、カスタマイズ賃貸への取り組みを始めております。 www.homes.co.jp ※2016年7月12日現在、キャンペーンは行っておりません。  HOME'Sは、今後も住まいについて様々な取り組みを行っていきます！ぜひご期待ください！  ロイヤルアネックスの中にある飲食店「 都電テーブル 」にもお邪魔し、美味しいご飯をお腹いっぱいいただきました！ 最後には青木さん、サラさん、見学者で集合写真を撮りました！