こんにちは、新UX開発部の二宮です。 LIFULLでは、 Qiita Organizationsを利用 しており、その一環として、昨年からアドベントカレンダーを行っています。 このLIFULL Creators Blogに比べて、Qiitaではより技術メンバー個人の情報発信・共有にフォーカスしており、アドベントカレンダーでも技術メンバー個人の苦戦や発見を共有してもらっています。 LIFULL Advent Calendar 2017 LIFULL その2 Advent Calendar 2017 アドベントカレンダーは、元々 昨年 に「LIFULLでもやったら面白いんじゃないか」「社内外に他のメンバーのことを知ってもらえるんじゃないか」と気軽な感じで数人に声をかけて始めました。当時はそもそも枠が埋まるのかどうかも不安だったのですが、今年も2つ用意したカレンダーが順調に埋まっています。 また、特に今年の新卒メンバーも名乗りをあげてくれた（内容はGo言語, BigQueryなど）のが私個人は嬉しいです。 弊社のエンジニア・デザイナーの素のがんばりを知るきっかけとして、それぞれの記事をご覧いただけると嬉しいです。

磯野です。 日曜日に帰国しました。帰りの飛行機は空いていて隣が空席だったため、広く使えて快適なフライトでした。 4日目のキーノートでのDeepLensの発表でワークショップの存在を知り、DeepLensのワークショップには参加できませんでしたが、ワークショップとは何だろうと疑問も抱いたので参加して来ました。 参加したセッションは三つです。 ALX305 - Designing Far-Field Speech Processing Systems with Intel and Amazon Alexa Voice Service ABD340 - NEW LAUNCH! Stream video from edge devices to AWS for playback, storage and processing using Amazon Kinesis Video Streams ALX307-R - [REPEAT] Integrate Alexa into Your Product Using the AVS Device SDK ワークショップの流れ 参加したどれもがある入力(音声/動画)を受け取って、AWS側のサービスと連携するものということで、RaspberryPiと対応した入力デバイスが提供されました。 参加したワークショップが全てハードウェアを使ったものだということで、傾向が似てしまった可能性はありますが、いずれのワークショップも Session Level:Advanced (300 level) ではありますが、初心者でも取り組みやすくなっていました。 実際の流れはこんな感じです 最初の30分程度で構成システムの説明 作業内容のpdfの共有 pdfにしたがってのワーク わからないこと・うまくいかないことがあれば講師、サポートメンバーに質問する ワークが終了次第、各自解散 ALX305 - Designing Far-Field Speech Processing Systems with Intel and Amazon Alexa Voice Service Far-Field、つまり離れた場所からの音声を認識し処理するデバイスでAlexaを呼び出す開発キットを使って行うものです。 Amazon Echo を自分で作成する為のキットと思ってもらえればだいぶ近いと思います。 提供していただいたものは以下の4つです。 RaspberryPi3 MicroSD (OSやソースコード) Intel Speech Development Kit イヤホン 提供されたインテルの音声キットとRaspberryPiを組み合わせてハードウェアを構築し（基盤むき出しですけど）、そこでAVS(Alexa Voice Service)デバイスSDKを利用したサンプルコードをビルドし、実行することが目的です。 OSやら基本のソースやらが全て設定済みのSDカードも提供されているので、簡単にできました。 ワークショップの内容はこちら https://avs-dvk-workshop.github.io/ ABD340 - NEW LAUNCH! Stream video from edge devices to AWS for playback, storage and processing using Amazon Kinesis Video Streams NEW LAUNCH! について：キーノートで発表されたサービスに関するセッションであることを表しています。 このワークショップはKinesis Video Streamsの発表を受けて実際に使ってみる為のワークショップです。 Kinesis Video Streamsに動画データを配信する為、RaspberryPiにカメラのキットを繋いで、動画配信プログラムを実行します。 参照はKinesis Video Streamsの標準の動画ビューアーで行います。 提供していただいたものは以下の3つです。 RaspberryPi3 MicroSD (OSやソースコード) RaspberryPi Camera Module V2 ワークショップの内容は非公開でした。 外部IPからのダウンロードをできないようにしていたので、ここでも公開はしないでおこうと思います。 ALX307 - [REPEAT] Integrate Alexa into Your Product Using the AVS Device SDK [REPEAT] について：人気のあるセッションはすぐに埋まってしまいますが、希望者があまりに多い場合には、追加でセッションが開催されます。 とても人気のあるものだと[REPEAT 2], [REPEAT 3]のように増えていくことになります。 こちらは、USBマイクをRaspberryPiにつけて行うワークショップです。ABD340との違いは、Far-FieldではなくHands-Free端末向けという部分です。 提供していただいたものは以下の3つです。 RaspberryPi3 MicroSD (OSやソースコード) USBマイク イヤホン これを利用して作られるようなデバイスとしては、スマートフォンやスマートウォッチなどでしょうか。 マイクの性能・接続方法とそれによるビルド方法の違いを除いて同じような内容だったので、内容についてより深く理解することができました。 ワークショップの内容はこちら https://avs-sdk-workshop.github.io/ ワークショップに参加しての感想 そこまで高度な技術力は要求されていないので、セッションレベルがAdvancedだとしても興味がある場合には参加してみることをお勧めします。 なお、質問の際は講師の方が席まで来て、しっかり状況を確認して話してくれるので、多少の英語力があれば大丈夫です。 ワークショップは2時間という限られた時間ですので、基本的な部分を中心に学ぶこととなります。そこから、より深く学ぼうとすれば、後ほど自分で調査し、拡張していく、といった取り組みを行う必要がありそうです。 興味があるけど、どこから手を付けるべきか・・・というときには、最初の一歩としてのハードルを下げる、良い内容だと感じました。 次回にまとめの投稿を行って本シリーズは最後したいとおもいます。

エンジニアの鈴木(健)( @szk3 )です。 AWS re:Invent 2017 最後の参加レポートになります。 今回は参加レポートとしてLIFULL Creators Blogに投稿してきたので、これらの内容をベースに振り返ります。 振り返り Day 0 - re:Invent への道のり 出発から現地入りしていよいよ始まるイベントへの期待をレポートしました。 www.lifull.blog Day 1 - re:Invent の熱気 ついに始まったre:Invent 2017の現地の熱気についてのレポートです。 www.lifull.blog Day 2 - GameDay への参加 GameDayに参加し、世界中から来たエンジニアと組んで戦った様子や結果を書きました。 www.lifull.blog Day 3 - Keynoteでの新サービス発表 Keynoteでの発表やセッションの様子、新しく発表されたデバイスDeepLensについて書きました。 www.lifull.blog Day 4 - Alexa ハッカソンへの参加 Alexaハッカソンに参加し、メンバーとの出会いやハッカソンの様子についてお伝えしました。 www.lifull.blog Day 5 - 振り返り 本記事になります。 今年も 圧倒的な数の新サービスの発表 がありました。 3日目の参加レポート にも書きましたが、MLのコモディティ化によるAIの開発が圧倒的に楽になっていく未来がどんどん具体性を帯びてきています。 また、エンタープライズ向けのニッチな機能がどんどん提供されていくあたりに、AWSの顧客ドリブンの姿勢が見えました。 AWSの顧客ドリブンな姿勢は、以下リーダシッププリンシパル(OLP : Our Leadership Principles )にまとまっています。こういった、 素晴らしい行動原理があるからこそ毎年のように凄まじい数のアップデートや新サービスの提供が可能になる のでしょう。 www.amazon.jobs 冒頭にも書きましたが、本記事で参加レポートは終わりになります。 Day 0に書いた本レポートの目的は、「海外カンファレンスに興味を持つエンジニアを増やす」でした。 今回書いた記事がきっかけになり、ひとりでも多くの方に 「自分も行ってみたい(自分でも行ける)！」と思っていただければ幸い です。 この経験をどう活かすか？ イベントへの参加した後は、熱気にほだされているので調子のいいことをいろいろ言いたくなります。（自戒を込めて） ですが、本当に重要なのは、この 経験を実務にどのように活かすか です。 活かし方は、人によってコンテキストが違うので、一概にこうしたほうがいいというのはありません。 ですが、エンジニアとして考えた時に、「ディスカッション」「アクション」の２つとして抽象化できるのかなと思います。 ディスカッションについては、「お客様や自社のアプリに対して新しく発表された新サービスがどこに使えそうか」や「海外カンファレンスの費用対効果」等、 いろんな切り口で話合うことができる と思います。業務時間に取らなくてもカジュアルにランチで話すだけでもエンジニアの交流や活性化につながり、十分に効果があると思います。 アクションについては、「新発表サービスを使った新機能開発」、「社内外に向けたフィードバック」、「新発表サービスにハンズオンした内容などを情報発信」や「社内ハッカソンの開催」など、できることはたくさんあります。 きちんと行動に落とし込み、 アウトプットとして評価できるような形で次につなげていくのが重要 だと思っています。 まとめ 去年は「海外のカンファレンスに参加するということ」というフィードバックを書きましたが、これは今年もre:Inventに行った経験から間違ってないと確信しました。 www.lifull.blog 個人的な話で言うと、今回から参加スタイルがに変化がありました 。聴講型から参加型へと大きくシフト したことです。 ハッカソンやワークショップだったり実体験ベースのアクションができたのは大きな収穫であり、 昨年との大きな違い です。この経験は大変有意義だったので、社内に対していろいろとやりたいことが増えました。 この経験をスキルアップとアウトプットの質・量の向上に活かして行きたい と思います。 最後に、1週間もの長い間、業務や家庭を顧みずにチャレンジさせてくれた、 会社・同僚・家族へ深い感謝の気持ちを表したい と思います。 やっぱり今年も楽しかったです！本当にありがとうございました！

エンジニアの鈴木(健)( @szk3 )です。 Keynote の二日目では、Alexa for businessやlambdaのgo対応など興味津津なサービスがたくさん発表されました。 本来ならKeynoteのレポートがメインにくるのですが、今回は前回の予告どおり、 Alexaのハッカソンに参加してきました ので、その様子をレポートしたいと思います。 ハッカソンのお題は、「 Hack Your Office : Build Alexa Skills that Help You at Work」という 仕事で役立つAlexaのスキル の開発になります。メインテーマは 生産性向上 です。 会場までの道のり 昨日、急遽会場変更のお知らせメールが来ており、Mirageという会場になりました。 会場に向かう途中、これまでに蓄積してきた寝不足も相まって、だんだん不安になってきました。 朝食を食べて現場に行こうと思ったのですが、re:Inventのアプリで調べると Bootcamp attendees only の文字が。。。対象外っすね、自分。 まぁ、コーヒーさえ飲めればいいので、スタバでゲットしたコーヒー片手に会場のホテルに到着しました。 re:Inventでは、たいていの会場ホテルにカジノがあり、実際にセッションやハンズオンが行われる部屋までは結構な距離があります。 その為、カジノの中にはre:Invent関係者が立っていて、セッションが行われる場所まで誘導してくれます。 今日も、「真っすぐ行って左だよー」と声をかけてくれたので、サンキューと答えると「今朝の朝食は全員入れるよー」と教えてくれたので、ラッキーなことに戦いの前に朝食にありつくことができました。 Alexaハッカソン チームを組む 朝食を軽く済ませ、少し早いですが会場に向かうとそこにはすでに行列ができていました。 最後尾に並んで10分くらいしたら開場し、SWAGとしてAlexaのパーカーを頂きました。 自由席っぽいのでふらふらしていると、日本人らしき2人組がいたので、こちらから話かけさせていただきました。 「日本人の方ですかー？」「これって個人戦なんですかね？」「二人はチームなんですか？」などと、今思えば少し質問しすぎだったと思います。 そんなこんなで色々話しているうちに、そのチームに混ぜていただけることになりました。正直、Alexaの経験は少なかったのでとても助かりました。 チーム数は、会場をざっとみわたすと約50チームくらい。1チーム 2-4名くらいのチームでした。 ハッカソン スタート！ ハッカソンのスケジュールは、9時から実装スタート、作ったAlexaスキルが動くデモの提出締め切りが13時55分と 結構タイト でした。 約5時間の間にアイデア出し、設計・実装、アイデアの説明（文言・画像）作成、デモ動画の作成とアップロード と やるべきことが多岐に渡ります 。 時間がないので分業が基本スタイルになるのですが、アイデアのブレストだけは分業できないので、そこはみんなで行います。 お互いに「いいアイデアありますか？」というふりになったので、 前回のハッカソン でStenから学んだことを活かし、 自分から積極的に考えやアイデアを伝えました 。 まず、すぐに思いつくようなアイデア（だれがどこにいるのかを教えてくれる、議事録を読み上げる、ミーティングのファシリテーターをやらせる等）は今回のようなハッカソンでは避けるべきという話をしました。インパクトがないわりに実装に時間がかかりそうというのが想像できるからです。 次に、日本から来ているということを活かしたいということ。差別化できるポイントは何か？と考えたときに、日本の文化を取り込むというのは、このハッカソンにおいて少数派になるであろうと思ったからです。 最後に、 弊社のサンクスカード の簡易版のような「ありがとう」をAlexa経由で蓄積できる機能と、誰が一番サンクスフルなのかを教えてくれる機能の２つを実装するというアイデアを伝えました。 これは、 Voice User Interfaceを使って「ありがとう」を可視化する というアイデアです。 「ありがとう」はシンプルだし世界共通であるので 誰にでもわかりやすい 「ありがとう」と言われた人は自分が誰かの役に立ったことのフィードバックを得られるので、 もっと良い行動が促進され、結果的に生産性があがる こと ということを軸に訴求したい考えていました。 また、このアイデアの 一番良い点は実装がシンプルにすむ ことで、ハッカソンが個人戦だったときにAlexa習熟度の低い自分が猛者と戦うためのひとつの戦略でもありました。 ２人とも方向性は悪くないと言ってくれたのと、ブレストに時間がかかりすぎるのがもったいないので、早速実装に入ろうとなりました。 役割分担をする際に、お互いのスキルセットを確認し、メンバーのひとりがすでにAlexaスキルを2つもローンチしている経験者であることがわかりました。 当初は、Alexaスキルの根幹である「lambda側の実装」と、Alexa側のインテントやスロットなどの「モデルの実装」の２つに作業分担しようと思いましたが、この短い時間なら経験者がひとりでまるっと手を動かしてしまったほうが早いと考え、実装的な作業をその方にお願いして、残りの二人は 提出資料の整備しながら、設計・実装への指摘やエラー発生時のデバッグのサポートをするような形を取りました。 はじめに、自分が仮実装してきたAlexa側のモデルを共有し、実装メンバーは自身のアカウントでアイデアを実装していきました。 3人で行う変則的なペアプロミングみたいな感じです。 後から知ったのですが、 その時の様子がre:Inventの公式Twitterアカウントにツイートされていました 。 Teams are hard at work developing Alexa Skills that help you at work! #hackathon #reInvent pic.twitter.com/49xJNyzwZB — AWS re:Invent (@AWSreInvent) 2017年11月30日 その後は、ひたすら動くようにするまでトライしつづけました。 時間的な制限があるハッカソンでは 何を捨てるかが重要 になってくると思います。 今回は、トラブルシュートにかなり時間がかかってしまったので、実装をモックに切り替えるか否かの難しい判断が迫られるシーンが何度かありましたが、最終的にはみんなで知恵を出し合って動かせるところまで行きました。 その時点で残り5分。 そこから急いでデモ動画を取りYoutubeへアップロードし、スキルの紹介画像・ハッカソンと作ったものに対する文言・ソースコードをまとめあげました。 本当にギリギリだったのですが、 きっかり締め切り時間に提出 することができました。 その時のデモ動画がこちらです。 チーム全体でやりきった感が強く、良い疲労感がでていたと思います。 審査 そこから審査が始まりました。審査は各テーブルに各国のAlexa関連の技術者が2名づつやってきて、作品のデモ・ソースコード・どういう経緯で作ったのかなどをチェックされました。 その後は審査待ちになり、あとは発表を待つのみです。審査待ちの間は1時間を軽く超え難航しているようでしたが、その待ち時間にハッカソンを戦ったメンバーとセルフィーを撮ったり、賞金何に使おうかー（入賞するつもりだった）なとど楽しい時間を過ごしました。 入賞者発表 ようやく入賞者の発表のタイミングがやってきました。 気になる結果は。。。 入賞ならず！ 残念。 GameDayと違い順番も表示されないので、差がよくわかりませんが、とにかく6位以内には入ることができませんでした。 まとめ GameDayのときも思いましたが、チーム戦のハッカソンでは個人の能力が問われます。 常日頃から自分の強みと弱みを的確に理解し、チーム戦において自分が最大限貢献できることは何なのか？ そういったことを意識しておくことが大切だと感じました。 もうひとつ感じたのは、たった6時間程度でも同じ目的を持って一緒に作業すると、その日初めて会ったのに、昔からの友人のような感覚が芽生えるということです。 つまり、 同じ目的に対する行動を、お互いが真摯に積み重ねるプロセスが心理的安全性を上げる ということなんだと思います。 今回も、たくさんの気づきを得ることができました。 この機会をベースに、オフィスをもっともっと楽しく便利にしていけたらと思います。 次回は AWS re:Invent 2017 参加レポートの最終回になります！

エンジニアの鈴木(健)（ @szk3 ）です。 今回は、re:Invent 2017の3日目のレポートになります。 Keynoteと参加したセッションについてお伝えします。 Keynote featuring Andy Jassy 今日は、AWS CEO Andy Jassy の基調講演（Keynote）です。毎年、このKeynoteではたくさんの新サービスが発表されます。 今年も鼻血がでそうなくらい 大量の新サービスが発表されました 。 あまりにも大量なのでひとつひとつに付いては書きませんが、 兎に角スゴイ です。 AI・IoT・機械学習をベースにしたサービス・データベース系の拡充系が特に多かったように思います。 また、GoogleにあるようなTranslate系や、Kubernetesを使ったサービスが出てきていて、他クラウドに対するウィークポイントが埋められてきたように思えます。 個人的にめちゃくちゃ気になるのは、 DeepLens です。 https://aws.amazon.com/jp/deeplens/ から引用 これは、カメラに機械学習ができる環境が乗っている感じで、カメラで撮った画像をリアルタイムにディープラーニングができるそうです。 後から知ったのですが、DeepLens発表後に新しいハンズオンセッションが公開され、そこに参加すると DeepLensがもらえる という大盤振舞いがあったそうです。 その為、参加者が殺到しReserved seatの方すら入場できず、セキュリティガードのような方たちが来て事態の収拾に応られていたとのことでした。急遽、明日にハンズオン枠が大量にもうけられましたそうですが、速攻でSoldOut状態に。 実際に触っていろいろやりたかったので、気づけずに めちゃくちゃ残念 です。 セッション 本日は、Alexa周りとAmazon FreeRTOSという新サービスのセッションに参加してきました。 その中からひとつだけピックアップします。 「It's All in the Data: The Mchine Learning Vehind Alexa's Systems」というAlexaの裏側で動く仕組みについてのセッションで、Alexaの単語認識の方法や端末側とクラウド側での役割の違いなどを聞くことができました。 発声データがシステムによってどのように処理され、精度を向上させるためにできることについて説明がありました。これはめちゃくちゃわかりやすいセッションだったので、Alexa開発者には 是非オススメ したいです。 AWS re:invent 2017: It’s All in the Data: The Machine Learning Behind Alexa’s AI Sys (ALX319) 日本でもEcho dotが発売され、自分も購入してお試し中ですが、Alexaにはめちゃくちゃ可能性を感じる一方、システムとしての作り込みは今まで以上に気を使うことが多そうで、セッションの中でも「test, test, test」と書かれている部分が印象的でした。 Noodle Asia ベネチアンに、Noodle Asiaというお店があります。 美味しいとの噂を聞いて、一度言ってみたいねと話していたところで、弊社磯野とCTO長沢と本日はこのお店で夕食を食べようという話になりました。自分は少し遠いAriaという会場にいたので、シャトルバスに乗り合流すると、日本から来た方とテーブルを共にしていました。 いろんな話が聞けてとても楽しい時間を過ごすことができました。 話の流れでDeepLensの話題になると、なんと DeepLensの実物 持ってらっしゃる方がいて見せていただくことができました！ その方は、ハンズオンを中心に参加しているとのことで、そういう背景もあり必然的に手にしていました。実物は想像より少し大きくCoolなガジェットという印象でした。うらやましい。。。 まとめ 毎年のことながら、 Keynoteを見ると技術トレンドがわかってきます 。 やはり、時代の流れとして、機械学習のコモディティ化が促進されることで、今までにないサービスが簡単に開発できるようになりそうです。そして、機械学習には学習のためのデータが必要で、そういったデータを格納するストレージの強化、そのデータを運ぶネットワークの強化など、実に AWSエコシステムでシナジーが効くサービス開発が行われている 印象を受けました。 また、AWSの方に聞いたのですが、AWSは顧客ドリブンなのでユーザの声を集めて、要望の多いものに対して開発優先度が変わるそうです。ユーザの声を集め、直接的なニーズを掘り出し続ける姿勢こそがAWSの拡大の一つの要因かもしれません。 次回は、「Hack Your Office: Build Alexa Skills that Help You at Work」という仕事で役立つ Alexaのスキルを開発するハッカソンへの参加レポート になります！ ちなみに DeepLensは来年4月に発売される予定ですが、Pre-Orderできそうだったので意気揚々と申し込みましたが日本には発送できないとのことでした。そのうち手に入れたら、触った感触をフィードバックしたいと思います。

こんばんは。磯野です。 先日に引き続き、GameDayに参加してきましたので、その結果報告をしたいと思います。 GameDayとは？ 入場まで 入場から着席まで 内容 良かった点 最初にSlackのチーム/GitHubのOrg.を作ったところ ノートを持って行ったこと 反省点 開始直後のタスクの整理がたりなかった Get to know your team 英語力 最終結果 結論 GameDayとは？ ある企業のサービスを極端なリクエストの増減に対応しつつ、要求を満たすように改善し、得点を競うハッカソンです。 詳しくはこちら reinvent.awsevents.com また、GameDayを成功させるためのTipsも上がっていますので、ぜひ参照してみてください。 aws.amazon.com 実際のところre:Inventのセッション申し込み開始時点では全く興味がなかったのですが、日本からのre:Invent参加者向けプレイベントでお会いした方に参加を勧められ、悩んだ結果現地でしかできないことをすべきという結論に達し申し込みをしました。 その際、一緒に行く予定の鈴木にGameDay参加を焚きつけられたりしたわけですが、そんな鈴木もGameDayに参加してくれたのは 本人の記事 にある通りです。 入場まで re:Invent会場で提供される朝食が6:00-8:00ということもあり、6時半起床、7時過ぎにはホテルを出ました。 朝食の内容は鈴木の記事にあると思うので、特に書きませんがマフィンなどを美味しくいただきました。 そのあと8時半くらいにGameDayの会場についたのですが、マフィンやコーヒーなど軽食が用意されており、無理に早起きして朝食に行く必要もなさそうです。 入場から着席まで 入場時に自分のスキルを確認され、そのスキルにしたがってテーブル番号を指定されます。 英語についての不安もあり、覚悟して行ったのですが、テーブルの4人のうち3人が日本人という、アウェー感の全くないチーム構成でした。 周りを見回すと、全部で60チーム程度あり、日本人らしき顔がちらほら、少なくとも1割くらいはいたのではないかなと思います。 説明開始の10時まで時間があったので、軽く自己紹介をし、Slackのチーム/GitHubのOrg.を作って開始を待ちました。 内容 GameDayの内容について細かく書くことは避けますが、ユニコーンレンタル社の危機をAWSの色々なサービスを使って解決して行くことがミッションです。 それぞれ、時間の経過や前問の回答とともに少しずつオープンされるので、次々と新しい問題起こる、本番さながらのシチュエーションです。 説明にもある通り色々な問題があり、詳しい情報がない中、サービスを継続し、問題を見つけ、いかに解決いていくかというのが焦点になります。 良かった点 最初にSlackのチーム/GitHubのOrg.を作ったところ 開始前のテーブルに集まった段階で提案していただき対応できたので、その後の動きが楽になりました ノートを持って行ったこと 英語が伝わらなくても、図に書けば伝わる！という思いから nu board を持って行きました。 2ページしか使わなかったので、ただのノートでも全然良かったという気はしなくもないですが、図でのコミュニケーションは大事ですね。 反省点 開始直後のタスクの整理がたりなかった まずはどんなことが必要で、何をするのか、というのを事前にチームで共有し一覧化すべきだったと感じています。 今回の内容に関しても、そこまで高度なスキルが必要なものが多いわけではなく、AWSの知識や今何をすべきか知っていることが重要だったと思うので、まずはみんなでタスクを文字として洗い出して、作業を分担すべきだったかもしれません Get to know your team 8つのTipsの2番目です。チームのことを知ろう！ということで、自己紹介で軽く聞いたり話したりしましたが、 AWSのどのサービスが使えて、それ以外にどう行ったところに強いのか、弱いのかという話を一覧にしてもよかったなと思いました。 振り返ってみたときに、細かい何ができて何ができないのかをあまりしっかり把握できてなかったなと気づかされました。 タスクの整理と一緒で、得意な人に割り振ったりなどが簡単にできた 英語力 弊社は希望者がオンライン英会話を利用できるようになっており、それをやっていたことで多少なりとも助けになりました。 まだまだ自分の足りない点の自覚もできて来たので、何らかの形で継続して来年は英語怖い状態から卒業したいと思っています。 最終結果 開始時の説明で16時と言っていたのですが、スケジュール上は19時だったので悠長に構えていたらいきなり終了してしまいました。 その際、手をつけていた問題は解決できずにそのまま終了です。 順位はおそらく、21位です。 良くもなく悪くもなくですがみんな初参加と考えたら悪くない結果ですよね。 自分が足を引っ張らず貢献できていたら違う結果になったかもしれないと悔やまれます。 （個別の結果がまとめて発表されたわけではないので、最後に見た順位です。確実な数値ではないです。） チームのみなさんありがとうございました。 優勝チームや上位のチームにはユニコーンのぬいぐるみが進呈されていました。 終わった後に前でもらっている人を見かけたので、行けばもらえたのかもしれません。 結論 GameDayのようなものを社内でも開催できたら楽しい＆AWSのスキル向上につながるなと考えています。 単純なハッカソンではなく事前に枠の用意された問題を協力して解決することでサービスのことをもっと知ることができます。 また、速くものを出して行く、今回あまりできませんでしたが、エラーやアクセスを監視するなどの視点にも繋げることができるのではないかと思います。 帰国したら、こういったハッカソンにはできるだけ参加したりしながら知見をためて、 社内でも開催できるようにしていきます。

エンジニアの鈴木(健)（ @szk3 ）です。 re:Invent 2017の2日目のレポートになります。 前回 予告したとおり、 GameDay に参加してきました。 本記事は、その参加レポートになります。 GameDayとは GameDayとは、 危機的な状況にあるスタートアップのアプリケーションをAWSの知識を使っていい感じにする ハッカソンです。 いい感じとは、サービスの安定化だったりCI/CDの構築だったり、実務でありがちなシチュエーションへ適切な対応を施すイメージを持ってもらえれば大体あっていると思います。 内容の詳細は、 こちらのリンク から御覧ください。 GameDayまでの道のり GameDayには弊社磯野も参加するため、すこし早めに一緒に部屋を出てベネチアンで朝食を取りました。 英語でのコミュニケーションに不安を感じる二人とは対照的な すっきりとした青空が印象的 でした。 少し肌寒い感じでしたが、気持ちのいい朝日を浴びて会場に向かいます。 会場入り 会場に入場する際にSeat reservedを確認してもらい、受付へと促されました。 受付では、AWSやビッグデータなど複数の項目に対する経験について5段階評価で応えると、「君は28番テーブルだよ、これがバーコードね」みたいな感じで 簡単に席が決まります 。 バーコードは、会場テントの再入場に必要なようでした。 会場は結構人がいて、後から聞いた話だと ざっくり60チームくらい参加してる という話でした。 1チーム4人なので、 約240人が参加 することになります。 ドキドキしながら自分のアサインされたテーブルに向いました。すると、チームメンバーの1人は日本人で某有名企業のビッグデータ周りを担当されている方でした。こんな日本人が少なそうなところで珍しいなと思っていたら、なんと磯野のチームは3/4が日本人だったそうです。 メンバーに日本人がいるからと行って、 英語で会話しないわけがない のですが、母国語が話せるメンバーが身近にいるというのは安心感がありました。 そんな感じで、自分の配属されたテーブルはSten, Hiro, Matt, Ken（現場での呼び名、左上から時計回り）が揃いました。 アイスブレイク お互い軽く自己紹介をし、自分のターンで弊社のことを質問されたので、「realestate search serviceを提供しているよ」と答えたらピンとこなかったらしく、「like zillow」と付け加えたらすぐに理解してもらえました。 グローバルな視点で競合するサービスを押さえておくと、意外なところで役に立ったりする ものです。 お互いの自己紹介が終わった辺りで、英語を使ったコミュニケーションへの不安を払拭するため、「コミュニケーションツールどうする？Slackでいいかな？」と自分から提案してみました。 すると、「OK、おれが作るよ」といってMattが作ってくれました。じゃ、メアドこれだから招待よろしくって感じでサクッと環境が整っていきます。 なんか、 始まってもないのにいい感じじゃないか！ とイケそうなイメージが膨らんできました。 開始まで暇だねー、などと雑談しながら待っているとSlackでチームが立ち上がりました。 すかさず、Hiroが The Top Eight Tips for GameDay Success という記事を共有してくれました。 利他すぎる ではありませんか！ 実はこの記事は自分も読んでおり、そこに書いてあるジョーク「 Bring cookies for the support staff! 」を真に受けて、クッキーを持ってきていました。なので、「クッキーもってきたよ！みんなで食おうぜ！」と、みんなにシェアできました。 GameDay そうこうしてると、運営によるGameDayのブリーフィングが始まりました。 スタッフが回って来て、各テーブルにチームのハッシュキーが書かれた紙を置いていきます。 これを使ってGameDayのダッシュボードにログインするようです。 しかし、みんな一斉に会場のWi-Fiに乗ったせいか、 ネットワークが異常に重くログインできない状態 が続きました。 ネットワークへ繋がりにくい問題は後々まで会場全体を苦しめることになります。 運営からチーム名決めてというアナウンスがありました。 日本だと「どうするー？何にするー？」と忖度が始まり、ふわふわしがちなのですが、Stenが複数のチーム名候補をビシッと出してきました。この姿勢には刺激を受けました。 Slackで投票し、チーム名はRoute28に決定です。 ブリーフィングの中で印象的だったのは、「HOW TO GET BACK TO SUCCESS?」という成功へ回帰するため行動指針です。 5つの行動指針の頭文字を取ってSTACK と名付けていました。いい行動指針ですね。 ブリーフィングが終わった頃には、全員がログインできておりダッシュボードが確認できる状態になっていましたが、 新しい画面を開くたびにWi-Fiと繋がらない問題が多発し、ローディング画面で待たされることが続きました。 全員がGameDayのダッシュボードが開けるようになると、全員で最初の問題を確認する動き方になりました。 Mattが自分の端末で途中まで作業していたので、そこをサポートする形になりました。 ちなみに、ダッシュボードの画面構成は、現時点での自チームの得点と総合ランクや、チームに付与されたAWSアカウントのコンソールへのログインリンクなど、GameDayに必要なものがコンパクトにまとまっていました。 問題の形式は、GameDayの説明の一文「Can you support and evolve this application over time to achieve the most efficient architecture?」にあるように、時間の経過で増えていくメインの問題と、ミニゲーム的な問題に分かれていました。 メイン側の最初の問題を全員ですぐに解いた後で、MattとStenが「分業しようぜ。」って言ってくれたので、メインの問題に自分とMattが取り組み、ミニゲームが二問あったので、それぞれをStenとHiroが分業して取り掛かることになりました。 メインの問題は、MattのMacを使ってAWS Consoleを見ながらペアプロのような形で進めました。自分の役割はオブサーバです。 ふたりでやり始めた２問目は、比較的簡単な問題だったのですぐに完了しました。その上で、システム安定化の為に冗長化の対応をしていました。 それくらいのタイミングで10位になったので コレは行ける！と思っていた のですが、 その後は徐々に順位を落とし、アップダウンを繰り返しながら 最終的には23位 でした。 わりと余裕があったのは最初の30分くらいで、あとの約6時間は作業履歴も残ってないくらい 本当にあっという間 でした。 個人的には、自分のスキルを活かしチームがハマっているポイントにアドバイスをして解決に導くことができたり、自分でもあまり触れたことの無いサービスを使って問題を解決したり、 積極的に参加できてとても楽しい時間 になりました。 当初不安だった英語でのコミュニケーションも終わってみればなんとかなったなという感じで、 朝の気分は一体何だったんだ と今になれば思えます。 まとめ 初対面の方と一緒に技術的な課題を解決することは自分にとってすごく刺激になりました 。 残念ながら結果は残せませんでしたが、Mattに「It is pretty good!」と言われて気付いたことがあります。 このチームは全員がGameDayに初参加でした、 そのような状況で上位 1/3 付近に食い込めたのはよかったじゃないか という考え方です。 年齢を重ねると、失敗に対する恐怖と不安で初動が遅れたり、動けなくなることが多々あります。 その要因のひとつとして、常に減点方式で考えがちになり動かなければ減点（失敗）もないと勘違いしてしまうからです。 （実際はゆるやかに退化していくだけです） 考え方を加点方式に変えるだけで、ずっとポジティブになり再チャレンジへの活力が湧いてきます。 結果に対するマサカリは否が応でも世間が投げてくれるので、事実は事実できちんと受け止めた上で、ポジティブに考えるのはとても大切ですね。 おじさんになるとできてあたりまえに見られるので褒められることが少なくなりますが、挑戦する行動を増やし人の成長を促すのは基本的にはポジティブ・フィードバックだと思っています。 Mattの何気ない一言から、 普段なかなか意識しにくい大切なことに再び気づくことができた のが、今回の大きな収穫になりました。 チャレンジした結果の失敗は、新しいチャレンジを生むと考えています。 目的意識を明確に、新しいことにどんどんチャレンジしていきたいと思います。 次回は、いよいよ re:Inventの山場、Keynoteについてレポートします。

こんにちは。田中です。 11/28に開催された、Adobe MAX Japan 2017に参加してきました！ そして、Adobe XDのセッションスピーカーとしても登壇させていただきました。 発表スライドもこの記事の最後に載せていますが、発表内容は今後別で記事でもまとめようと思います。本記事はAdobe MAX Japanのレポート寄りです。 Adobe MAX Japanとは Adobe社主催のイベントで、新製品や新機能の発表、Adobe製品担当者やゲストスピーカーによるAdobe製品にまつわる数多くのセッション、ワークショップの開催、協賛企業各社の展示、大規模なBEER BASHなど、まさにフェスのような一大イベントです。 10月に開催された米国の「Adobe MAX」では、晴れてメジャーバージョンとなったAdobe XD、人工知能「Adobe Sensei」等の新機能の発表が大いに盛り上がったそうですが、1ヶ月ほど跨いだ日本のAdobe MAX Japanでもこういった製品は注目の的だったようです。 私からは、そんな大注目のAdobe XDの導入事例についてお話させていただきました。ちびるかと思いました。 なお私のセッションは17:50からで、セッションパートとしては最後の時間帯。 日中仕事があったのでAdobe MAX Japanは途中参戦でしたが、自分の出番の前後で展示など色々と見て回ってきたので、 そのうち少しだけご紹介したいと思います。 Illustrator30周年記念展示 Illustratorの30周年記念として、過去連載してきたIllustratorのインタビュー記事で毎回掲載していた、クリエイター30人分のイラスト作品を展示していました。 Illustratorって生まれてから30年も経つんですね。 思えばはじめて触ったAdobe製品は、高校生の時に借りて遊んだIllustratorでした。当時はパスが上手く扱えず、適当にいじっているうち偶発的に生まれたチューリップ的な物体を印刷して喜んでました。懐かしい。いつもお世話になっております。 Illustrator新機能「パペットワープ」 かわいい こちらはIllustratorの新機能です。 Intelさんの展示ブースに設置されたマシンで動いていました。 ワンちゃんのイラストにひび割れのような網がかかっています。この中の●を動かすとワンちゃんが動いてくれます。イラストのいろいろな部分が連動して反応するので、何とも言えない生々しさがあります。 これで人物イラストの手を動かしたり、あるいは植物のような有機物のイラストを調整するといった事にも使えるかもしれません。 またこの機能、噂によると話題のAdobe Senseiを利用しているそうです。 アドビ工房 こちらではコースターやキーチェーン、缶バッジなどを自作することが出来ます。レーザーカッターやUVプリンタまで設置されていました。クリエイターの祭典を謳うAdobe MAX Japan、こうしたワークショップはとても充実していました。 Adobe Sensei × Stock 人工知能 アドビ先生 。何度聞いても可愛い名前です。 昨年の米国MAXで初のお披露目でしたが、今年は更に進化してAdobe CCにおける様々なツールで連携が進んでいるようです。 ここではAdobe Stockという素材ライブラリにSenseiを応用した、4つの最新機能をデモンストレーションしていました。面白かったので細かくご紹介します。 「Concept Canvas」 1つ目は、カンバスにタグ付けされたオブジェクトを自由に配置すると、その構図や位置、割合から類似画像を探してくれる機能です。例えば、カンバスに「beach」「sky」をそれぞれざっくり範囲を指定すると、その通りのレイアウトの写真が出てきます。「child」を足せば子どもがいる写真を探してくれます。 普段写真素材を探す時、「雰囲気が良いやつ見つけたけど、欲しいイメージと構図が違う！」といった理想との微妙なギャップを胸に、ライブラリを舐めるように漁り続ける事ってあると思います。この機能なら「晴れた海で、右に人物、左はヌケの写真欲しいなー」みたいな痒いところにも手が届きそうです。 「Selective Similarity」 2つ目は、ある写真の特定の部分を手がかりに別の写真を探してくれる機能です。 写真を準備し、部分的に赤いマスクをかけると、その部分をフィーチャーした写真（あるいは排除された写真）がたくさん出て来ます。猫様の顔にマスクを掛けて、御顔のアップ写真を探したり、ビーチに人がいる写真を元に人にマスクをかけて、逆に人のいないビーチを探したり。これも色々と応用の効きそうな機能です。 「Stacker」 3つ目は、色やキーワード等の要素を指定し、それに見合った画像を探してくる機能。そう言われると、一見普通の素材ライブラリの検索機能と同じように見えますが、人工知能だからこそ出来る機能をしっかり実現しています。 例えば”程度”を自由に指定できる点。 「WALKING」というキーワードを指定しつつ「fast」を指定し、fastのスライダーをMAX100にすると、すっごいスピード感で人物が歩く写真が出てきます。 逆にfastのスライダーを-100にすると、今度はゆっくり散歩してそうな老夫婦。おお。しかも操作する度にシームレスに再検索が掛かっていくので探すだけでも楽しそうです。 「Sketch with Style」 4つめは、絵を描くと類似の画像を拾ってきてくれる機能です。 私も試しにメガネを描いてみました。するとSenseiがイラストをメガネと認識して、右側に本当にメガネの写真を出してくれました。素晴らしい。 さらに、成長したのび太のような絵を描き足してみました。 するとゴリラの素材を出してくれました。確かに輪郭がそこはかとなく類人猿寄りだったかもしれません。あるいは私が昔、教科書の余白という余白をゴリラだらけにして遊んでいた事をSenseiは知っていたのでしょうか。 これらの機能はまだ日本語未対応でローンチはされていないようですが、画像検索だけでも未来を感じました。早く使いたい。 そして最後にSenseiの開発メンバーの方と写真を撮らせていただきました。当初、周りのお客さんから日本語で「先生の先生だ！」とはしゃがれて少し困惑した様子でしたが、とても気さくな方でした。ありがとうございました。 MAX STORE 売店。 この写真は夕方頃でしたが、嵐の後のようにすっからかんです。 本当は後ろの棚に製品アイコンのクッションや靴下などあったのですが、飛ぶように売れてこの状態。中には開場前に並び、開場と同時に駆け込んで買っていく猛者もいたそうな。すごい。日曜の朝市か。でも確かにクッション欲しい。ちなみにアイコンクッションは今のところ米国でしか作っていないレアアイテムだそうです。 ほか、エディトリアルに映像、パラグライダーをうつ伏せブランコ+VRで体験するブースなどなど、本当にたくさんの展示がありました。全ては見切れなかったほど。大変見応えがありました。 セッション登壇 私のセッションでは、導入して分かったXDの魅力を3つにまとめてお話しました。XDのセッションは他の時間でも幾つか行われていましたが、その中でも私のパートは最後の時間帯だったので、ちょっと変化球なネタも仕込みつつお話させていただきました。 緊張しまくるわたし 喋るわたし なおセッション会場は満席。今回のAdobe MAX Japanでは、どのセッションブースも同じ状態だったようです。本当にありがとうございました。 終了後に質問してくださった方も、ありがとうございました。中には私と同じようにコーポレートサイトのリニューアル案件でXD導入を検討されている方もいらっしゃいました。私の話がお役に立てれば幸いです。そのためにあの場に立ちました。陰ながら応援しております。 さて、その後は調子に乗ってBEER BASHの波に身を投じます。この時の黒ラベルは最高でした。会場ではイベントの最後にプレゼント抽選もやっていました。 最後、メッセージを自由に書ける壁に人が集まってました。 私も隅っこにゴリラを残しました。 Adobe MAX Japan 2017、こうして大盛況の内に終了、あとは打ち上げでひたすら呑んだくれました。ご来場いただいた皆様、Adobeシステムズの皆様、出展、デモをされていた皆様、スピーカーの皆様、イベントを支えてくれた皆様、本当にありがとうございました。 ▼XDセッションのスライド 事例に学ぶAdobe XDフル活用の極意。 Photoshop / Illustratorとの 連携から仕様書作成まで from LIFULL Co., Ltd.

鈴木(健)（ @szk3 ）です。 前回のレポート では、フライトから参加者登録、そして会場を視察するところまでをお伝えしました。 今回のレポートでは、初日の状況や現地の雰囲気を中心にお伝えしたいと思います。気楽に読んでいただければ幸いです。 はじめに 本日からセッションに参加するわけですが、本参加レポート シリーズでは技術的に細かい話はしません。 後日公開される資料を見たほうが確実だと思うのと、 現地で感じたことを中心にフィードバック したほうが 参加レポートとしてはよりリアルになると考えるためです。技術の話が少ない！と思われるかもしれませんが、ご了承ください。 本日から本番です！ 自分は今回のイベント全体を通して、Ariaという会場を中心に組み立て、音声認識・サーバーレス周りを軸にセッションを組みました。 そして、re:Invent 2017の幕開けに選んだのは 「How Voice Technology Is Moving Higher Education to a New Era」というセッションでした。たまたま CTO長沢 と同じだった為、一緒に行くことにしました。 セッションに向かう途中 ものすごい長蛇の列ができてると思いきや、参加者登録（レジスト）の列 でした。 レジストの場所までは、エスカレーターがあるので、安全のため入場規制を行っているようでした。 人が対応しないといけないものは、なかなか簡単にElasticにはできませんね。 自分たちは先日中にレジストを終えていたので、すんなり部屋に入ることができました。 「How Voice Technology Is Moving Higher Education to a New Era」では、アリゾナ州立大学で学生達がどのようにAlexaを使っているかについての事例紹介でした。とても示唆に富む発表で、 時代の流れとして Voice Interface への転換期に来ている のはなんとなくわかっていたけど、実際に使われている様子を見るとより鮮明に理解することができました。この事例を応用し、会社に戻った時に開かれるハッカソンでEcho dot + Alexaで何か実装してみようと思います。 人、人、人 ふたつめのセッションは、席の予約(Seat Reserved)できず 予約待ち(Walk-up seat) でした。つまり当日席が空いてたらWalk-up seatの列に並んだ順に入れてくれるという仕組みになります。 セッションの会場に行ってみると、人の数が多すぎてWalk-up 待ちの列を並ぶどころか、 どこが列の最後なのかもよくわからないほどの混雑 でした。 会場に入れなかった人向けに、大部屋にでかいモニターを付けて中継してくれるTheaterと呼ばれるサブ会場もあるにはあるのですが、 そこも人で埋め尽くされて前が見えない という状態。。。去年以上の人の多さと盛況ぶりを感じました。 ベスト・プラクティス的なセッションの人気は高いので、セッション公開時に予約できなかった時点で辛い戦いが待っていることがほぼ確定していたようです。 とにかく人が多い 印象です。 一旦そのセッションを諦めて、別のセッションへ行くことにしました。 当日でもフレキシブルにスケジュールを変えられる のがre:Inventの良いところでもあります。座席予約が埋まってさえいなければ、すんなり入れてくれます。 登録しなおしたセッションは、「Now Hear This: How Earplay Architects an Alexa Radio Rrama」でした。セッション自体はいい内容だったのですが、途中マシントラブルが発生し、画面が映らない時間が結構長く続きました。デモには魔物が住むって誰かが言ってたのを思い出し、本番の怖さを再認識しました。 ランチ 先程のセッションを終えて、時間が空いたのでランチに並びます。ランチについて事前に情報共有はありませんでしたが、昨日くらいに突如追加されたようです。話は逸れますが、ランチ待ちで並んでいた時に「Is this line queued for lunch?」と話かけられました。queueといえばSQS！という安直な発想しかない自分にとって、queueという単語を技術のドキュメント以外で普通に使われているのを聞き、親近感が湧きました。このような 単語のリアルな使い方が学べるのは海外カンファレンスの良いところ だと思います。 ランチは 去年より豪華で美味しい印象 です。チキンとビーフというタンパク質ががっつりとれる食事になっています。機内食の炭水化物 on 炭水化物 に打ちひしがれていた自分にとって最高の食事になりました。やっぱり肉が好きです。ちなみに前に並んでいた方は、このステーキを3つくらい皿に盛っていました。 食欲にもスケールを感じます 。 ランチを食べ、午後からさぁ行くぞ！となったところで、 雲行きが怪しく なります。 Walk-up seat 今回自分の登録している午後のセッションは全てWalk-up seatでした。結構早めにセッションの予約をしたつもりだったのですが、全世界同時にセッションの登録が開始されたせいなのか、参加者が増えたせいかわかりませんが、とにかくSeat reserved が取れない状態でした。でも、日本にいたときはそんなに悲観しておらず、並べば入れるだろう的に楽観的に考えていました。 しかし、 いつだって現実はそんなにあまくありません。 そもそも、どこがWalk-upの最後尾なのかわからないくらい人が並んでおり、がんばって並んでも途中で「会場が一杯なので入れません！」みたいな扱いを続けて3回もらいました。 Walk-up seatは基本的には30分前に来てねというアナウンスになっているのですが、30分前に来たくらいでは全くもって時既に遅しでした。違うセッションを見たら1時間後のセッションのWalk-upに長蛇の列ができていました。 これは完全に見誤った結果であり、もう少し早く損切りをして行動を変えていれば、ひとつくらいはセッションが見れたかもしれません。1日にセッションを詰め込むより、絶対見たいセッションに1時間以上前から並ぶ作戦を取らないといけないようです。 もちろんセッションが開催される会場の大きさやコンテンツにもよるし、入れなかった人(OVERFLOW)用の振替ステージもあるのですが、大抵入れないセッションはOVERFLOWも溢れかえっているので、結局全然見れない状態でした。 前回はここまで入れないということはなかったので、 経験がマイナスに作用する結果 になりましたが、その分空いた時間でアウトプットの整理を進めていました。 QUAD 気を取り直し、QUADと呼ばれる場所を回ってみることにしました。ここにはスポンサーブースがあったり、レゴでピタゴラスイッチ的なものを作るスペースがあったり、認定者ラウンジがあったりと 何かと楽しい場所 です。 認定者ラウンジとは、AWSの資格保有者のみが使えるラウンジで、そこで認定者Tシャツをもらえました。今年はロールプレイングゲーム的なデザインになっており、配布していたステッカーのキャラクターはそれぞれ資格に対応しており、親しみがわくようなデザインになっていました。 JAPAN NIGHT！ 一旦、ホテルに帰宅し、夜からは日本人同士のネットワーキングに参加してきました。 今回のre:Inventには日本人は1200名ほど参加しているらしいのですが、このパーティーには500名くらい参加しているとのことでした。自分も たくさんの方とお話させていただきました。いろいろと勉強になることが多く、大変有意義な時間になりました 。ありがとうございました。 まとめ 初日は、昨年の経験が活かせた部分と活かせなかった部分が混在する結果になりました。 原因は複数考えられますが、今日の反省を活かし、残りの期間を最適化していきたいと思います。 明日は、GAME DAYに参加します。 英語は自信がないので不安要素が若干高めですが、出川先生を見習って 「人間だから伝わるよ」という言葉を胸に頑張りたい と思います。

エンジニアの磯野です。AWS re:Invent 2017 参加レポートを鈴木が公開していますが、自分も鉄は熱いうちにということで、レポートを書きたいと思います。 いきなりですが、まず行く前に気になっていたことや到着して気づいたことをまとめた番外編お送りします。 初日は長沢、鈴木と一緒に行動していたのですが、多少の感じたことの違いはありますし、個人的に6年ぶりのアメリカということであまり気にせずに記載します。 疑問1：日付変更線を跨いだ時にiPhoneのアクティビティはどうなるのか？ 疑問2：AT&TのSIMはauのSIMロック端末で使えるのか？ 感想1：遠い！本当に遠い 感想2：みんな本当に優しい 疑問1：日付変更線を跨いだ時にiPhoneのアクティビティはどうなるのか？ 結果は1日が伸びる！でした。 フライト当日(2017/11/26 00:00:00+0900 - 2017:11:27 00:00:00-0800)に41時間(24時間+時差17時間)中31時間もスタンドしたということで、スタンドの数値が大きすぎる気もしないでもないですが、1時間に1分立てばOKなので、気にしないことにします。 なお、帰りは逆になるため、-17時間によって連続達成記録が絶たれてしまうであろうことに戦々恐々（言い過ぎ）としてます。 疑問2：AT&TのSIMはauのSIMロック端末で使えるのか？ auならAT&TのSIMをそのまま使えるという話はいくつかのブログで見かけていたのですが、記事が少し前だったり、出たばかりのiPhoneXということで、多少の違いがあったのでドキドキしながらも検証してみました。 （通話ができないとイベント中の緊急連絡などに困りそうだったので、一応SIMロック解除済みのiPhone6S Plusも持ってきています） 結果は使える！でした。 通常であればSIM差し替えの際にはアクティベーションが必要になるはずですが、その操作もいらずに差し替えただけですぐに使えるようになりました。 なお、APNプロファイルをiPhoneに設定している場合、消さないと接続できるようにならないので、みなさんご注意ください。 （一緒にSIMを購入した 弊社CTO がそれで関係のない何度も再起動させられていました。） また、SIMについて、今回はラスベガス・ストリップ沿いにあるショッピングモール内のAT&Tの露店で購入しました。 マッカラン空港のバッゲージクレーム周辺とタクシー乗り場に出る前の建物内に自販機がありますが、AT&Tではなかったので見送っています。 SIMフリーの場合にはそちらでの購入もいいかと思います。 感想1：遠い！本当に遠い サンフランシスコやロサンゼルスではそこまで感じなかったのですが、ラスベガスは視覚から感じる距離と、実際の距離の違いが極端に大きくて、歩いても歩いてもつかない感が本当に強いです。 周りにある何もかもが、日本であったら1/3から1/2くらいのサイズなんじゃないかというくらい大きくて見た目での距離感と実際の距離の乖離が激しくなっているのかなと思っています。 （これはこの記事を書いている滞在2日目になっても慣れないです） 感想2：みんな本当に優しい オンライン英会話をやるようになって4ヶ月くらい経過しました。できないなりに忘れていた記憶が蘇ってきて、多少はやりとりできるかなぁと思ってきてみたのですが、実際に対面で話してみると、想像以上にできなすぎてこれはダメだろというレベルになっています。 でも現地のみなさん（主に店員さんや各ブースの方、AWS内の案内担当の方）は仕事だということもあるとは思いますが、色々サポートしてもらえて助かっています。 明日はGameDay(re:Invent内のハッカソン)に参加予定なので、これはさらに不安ですがなんとか頑張ります。 明日以降は参加セッションの軽い共有とGameDayのことを書く予定です。書かなかったら察してください。 以上です。この内容が海外に慣れていない＆英語に苦手意識がある方の心配を多少なりとも軽減できたら幸いです。ではあと何回か、よろしくお願いします。

エンジニアの鈴木(健)（ @szk3 ）です。11/27から12/1まで行われる AWSのカンファレンス re:Invent 2017に来ています 。 戻ってからゆっくりフィードバックするつもりでしたが、せっかくのこの雰囲気や熱を感じたままに伝えたくなり、 急遽 、参加レポートを書くことにしました。 本記事はDay0ということで、日本を発ってから現地到着までの流れと、明日を本番に控えた会場の様子をまとめます。 参加レポートについて 昨今では海外のTech系カンファレンスに参加する方が増えてきたように感じます。弊社でもWWDCやGoogle I/O など著名どころには毎年参加するようになりました。今回は、 AWS のお祭り re:Invent 2017についてレポートしたい と思います。 このレポートの目的は、「海外カンファレンスに興味を持つエンジニアを増やす」になります。この記事がきっかけになり「自分も行ってみたい(自分でも行ける)！」と思っていただければ幸いです。 日本からラスベガスまでの道のり 自分のコンテキストだと、「つくば」 から 「ラスベガス」という道のりになります。まず、高速バスで約1時間程ゆられて成田空港に向かいました。最近のバスには電源が付いており、とても便利になりました。 今回は、3人が同じフライトで残り1人は別フライトになりました。ツアーという形ではなく、カンファレンス参加チケット・フライト・ホテルの手配まで自分達で行ってます。初めての場合はツアーでの参加のほうが安心感がとても高い為、ツアーをおすすめします。逆に、自分たちで全部手配すると自由度が高くなります。この辺は、海外旅行慣れしているかいないかで大きく変わってくると思います。 成田空港で弊社メンバーと合流し、両替など所用を済ませたらすぐに出国手続きをしました。出国後は、 CTO長沢 の謎カード(プライオリティパス)の恩恵を受け豪華なラウンジへ行きました。 「赤いきつね」や「わかめラーメン」が食べ放題 です。 フライトは、成田からサンフランシスコで国内線に乗り換えてラスベガスへのルートです。成田からサンフランシスコまでは、片道9時間15分です。日付変更線をまたぐので、日曜の午後5時に出発して、日曜の午前10時（現地時間）に到着するため、不思議な感覚になります。長時間のフライトは馴れないと辛く感じますが、今回は秘密兵器としてノイズキャンセリングヘッドホンを導入しました。まさに 神アイテム！！ でしたので、長時間のフライトには是非声を大きくしてオススメしたいと思います。 サンフランシスコに着くと現地は雨でした。天候不良により乗り換えは約2時間ほど遅延しました。 待っている間は、機内食で足りないビタミンをフルーツで補給したり、コーヒーを飲んでリフレッシュしたり、各自タブレットを使って勉強するなど有意義に時間を過ごしました。2時間の遅延でようやくサンフランシスコを出発することになりましたが、フライト時間も少し伸びてラスベガスに到着したのはその2時間後でした。 イベントへの参加者登録、そして会場視察まで マッカラン空港に到着したらまずはSIM探しです。しかし空港で値段と通信量に見合うSIMが見つからなかった為、一旦後回しにして先にホテルにチェックインすることにしました。 空港でタクシーを拾いホテルへ。タクシーの運転手さんは、前も見ないで話しかけてくる陽気な方でしたが「ちゃんと前見ろ！」と強く 英語で言い返せるほどのハートは持ち合わせておりません でした。 無事にホテルにチェックインできたので、今度はre:Inventのイベント自体に参加者として登録(レジスト)しにいきます。 自分たちのホテルに一番近いAriaという会場に向かいます。そこで見つけたのは、壁一面に書かれたre:Inventの文字！おおぉ！ テンション上がる！！！ レジストは、ブルーバックのイケてるチェックインカウンターで行います。 登録にはパスポートが必要 ということで、こんなところにも海外カンファレンスっぽさを感じます。 無事にレジストを終えSWAGへ。SWAGとは " Staff we all get " の略で、参加者全員がもらえるお土産のようなもの です。昨年度はパーカーとEcho dotが大判振る舞いされましたが、今年はシンプルな薄手のパーカーでした。みんな試着してサイズを確認してから希望のものをもらう流れです。シンプルなパーカーですが、これを着ているとちょっとした連帯感が出てきます。 そして今回は 6つの会場で約500以上のセッションが公演される ため、本年度からシャトルバスが導入されることになりました。会場の下見も兼ねて、その シャトルバスによる移動にチャレンジ です。 シャトルバスは、その時の交通量にも依存するので思った通りの時間に着くとはかぎらないのですが、それでもおおよそ5分間隔で出ているとのことなので長距離の移動には積極的に利用していきたいと思います。ちなみに 会場の移動では最大徒歩45分かかる そうです。 実際Ariaから、いつものメイン会場であるVenetianへシャトルバスで移動すると約15分くらいでした。 Venetianはいつもの貫禄を見せつけて、 本年度も期待が膨らむ装飾が施されていました 。明日がとても楽しみです！ まとめ 以上、簡単に日本を出発して、カンファレンスへの参加者登録、会場視察までの流れになります。自分は昨年も来ましたが、 本年度も来れて本当によかったなと感じています 。明日からはre:Inventの本番が始まります。現地でしか味わえない雰囲気を随時ブログにて更新していきたいと思いますので、最終日までよろしくお願いいたします！

こんにちは。LIFULLのWEBデザイナーのshinoです。 LIFULLではWEBデザイナーが主体となって、ユーザー中心にデザインするための方法を学び・実践する「HCD/UXサークル」があります。 私は2017年4月からこのサークルに参加し、仲間とお互いにサポートしあいながら、勉強と実践を交えて切磋琢磨しています。 今回の記事では、LIFULLのWEBデザイナー職のビジョン・役割からみたHCDの位置づけや、HCD/UXサークルについてご紹介します。 目次 そもそもHCDとは？ LIFULLのWEBデザイナー職のビジョン・役割からみたHCDの位置づけ HCD/UXサークルについて サークルの活動風景 2017年度上期（4月～9月）の活動概要 各チームの目標や活動内容 そもそもHCDとは？ HCDとはHuman Centered Design（人間中心設計）という意味です。 ユーザーを中心にものをつくるための考え方のことを指します。 ※詳細については、人間中心設計推進機構の定義をご覧ください。 HCDとは | HCDコラム | HCD-Net LIFULLのWEBデザイナー職のビジョン・役割からみたHCDの位置づけ LIFULLのWEBデザイナー職のビジョンは「デザインで、新たな価値の創出にドライブをかける」です。 このビジョンの実現を目指して、これからのLIFULLのWEBデザイナー職は 1. トレンドや競合、他分野の表現を考慮し、目的を踏まえつつ、新鮮な表現ができる。 2. ユーザーのニーズと施策の要件に沿いながら、最適なUI設計や情報設計を行なうことができる。 3. 施策の背景を理解し、デザイン・ユーザー・業界に関する高い知見を基に提言することで、新たな価値創出に寄与する。 の3つの能力がより一層求められます。 この3つ能力の中で、ユーザーに関しての知見を身につけるために、サークルではHCDを学んでいます。 HCD/UXサークルについて サークルの活動風景 HCD/UXサークルが発足したのは2015年で、今年で活動を始めて3年目になります。 弊社の社員で人間中心設計推進機構認定の人間中心設計専門家であるオガワからのサポートを受けながら、2017年度上半期（4月～9月）はオガワを含め9名で活動をしました。 HCD/UXサークルは昨年2016年から月10時間以内で業務時間を使用するということが認められています。私達はこの10時間と業務後の時間を利用して、勉強会の企画や開催を行いました。 活動中は和気藹々と、活発に意見を交わしながら学んでいます。 2017年度上期（4月～9月）の活動概要 2017年上期は初めてサークルに参加するメンバーも多かったので、HCDのベースとなる一般論を学ぶ基礎力チームと、より実践的にHCDの考え方を用いてデザインや評価ができるように学ぶスキルアップチームとの2チームに分かれました。 それぞれのチームで自分たちが学びたいことを決めて勉強会を企画し、お互いに参加しあって学びました。 各チームの目標や活動内容 　 基礎力チーム スキルアップチーム 目標 HCDの基本的な知識をつける。（UI/UX・ユーザビリティ・HCDなどの言葉を、認識の齟齬がない状態で使えるようになる。） WEBデザイナーとしてスキルアップするために、HCD視点でデザイン・評価ができるようになる。 活動内容 「UXデザインの教科書」読書会 章ごとに担当を割り振り、読書をして学んだことや気づいたことをパワーポイントにまとめて共有しました。 BAD UIを見つけて原因を探り・解決策を考える。 HCD視点での着眼点を鍛えるために、「失敗から学ぶユーザインタフェース」の読書会を行って学びつつ、身の回りにあるものやWEBサイトを題材にして、BAD UIに対する指摘を行いました。 参考書籍 安藤 昌也 著 UXデザインの教科書 中村 聡史 著 失敗から学ぶユーザインタフェース 勉強会 月に1回。2時間程度 月に1回。2時間程度 振り返り 1. ただ読むだけより、まとめることで理解が深められた。 2. UXやHCDの全体感を知ることにより、自分の興味のある箇所や業務で行いたいことを明確にすることができた。　など 1. 漠然とよくないと思っていたUI・デザインをHCDの視点で考察・説明できるようになった。 2. 先に読んだ本に合わせて学んだことにより、理解を深めやすかった。　など 今回は、LIFULLのWEBデザイナー職のビジョン・役割からみたHCDの位置づけや、HCD/UXサークルについてご紹介させていただきました。 次回は、各チームが取り組んできた活動の詳細や、結果どう成長したのかなどを詳しくご紹介したいと思います。 つづく

こんにちは。 LIFULL HOME'Sアプリのデザイナーのこばやしです。 デザイナーの3Dモデル作り全3編中、第2編は「モデリング編」です。メッシュオブジェクトで形をつくり・整える行程の基本操作（コマンド）・便利機能をまとめました。ツールの操作やモデリング前の下準備については 準備編 をご覧ください。 www.lifull.blog メッシュオブジェクト編集の基本操作 全選択と解除 「A」キー 任意の範囲選択・選択解除 「C」キー 押し出し 「E」キー インセット（面を内側に押し出す） 「I」キー 面張り（辺作り） 辺 or 点選択 →「F」キー 選択された辺で囲われた部分に面を張ることができます。 ループカット 「Ctrl+R」キー 面を任意の数で分割することができます。 頂点を滑らかにする 「Ctrl+V」キー→Smmth Vertex メッシュオブジェクトの基本操作（コマンド）として、これらはよく使うと思うので、コマンドを覚えておくとよいです。 次に、便利機能です。ホームズくんを作るときにも使用しています。 メッシュオブジェクト編集の便利機能 ミラー（Mirror Modifier） 左右対称のオブジェクトを作るとき、片方つくったらもう片方は鏡面として自動的に同じものが仕上がる機能です。ホームズくんだと胴体や腕などで使用してます。 メッシュオブジェクトを選択→「 Modifierタブ 」→「 ミラー 」 ミラー接面が裂けないように「 クリッピング 」をチェック これでミラー設定完了です。左右対称のメッシュオブジェクトを作りたい時に便利です。 細分割曲面（Subdivision Surface Modifier） 面を自動計算して分割してくれます。ホームズくんだと蝶ネクタイなど曲線が細かいオブジェクトに使用しています。 オブジェクトモードだとメッシュオブジェクトはどちらも細かいですが、 編集モードの実際のメッシュオブジェクトは大雑把な形です。 細分割曲面を使うことで、大雑把なメッシュオブジェクトでもきれいな曲線を自動で計算して造形を整えてくれます。 クリース 細分割曲面（Subdivision Surface Modifier）を使用した際のエッジの鋭さを決めることができるパラメーターです。滑らかさを調整・なくしたいときに役立つ機能です。ホームズくんだと帽子のつばの付け根などで使用しています。 Before After テクスチャペイント おそらくデザイナーが一番楽しい工程ではないかと思います。作ったメッシュオブジェクトに色をつけていく作業です。正確には メッシュオブジェクトに貼り付けるテクスチャ画像を作る行程 です。 例えばこういう画像をつくることになります。 ホームズくんの胴体（服）のメッシュオブジェクトのテクスチャ画像です。下記のように作られた胴体のメッシュオブジェクトに対して、展開図のようなテクスチャ画像に色を塗ったものです。 Blender上で、直接3Dモデルに対して色を塗ることもできますし、画像を出力して他のツールで塗ることもできます。個人的には使い慣れているツールで作業するのがよいと思います。 おすすめの作業工程 Blender上でざっくりと色を付ける Photoshopなどの使い慣れたツールで細かい表現や色を塗る Blenderに入れなおして微調整する ホームズくんのテクスチャでこだわった部分はコート影・裾表現です。貼り付けるメッシュオブジェクトに凹凸を作っていないので、テクスチャでそれっぽく表現しています。 気を付けるところとしては「立体に画像を貼り付けている」という点です。下書きのイラストデータをそのまま貼り付けると、立体であるため、パーツ幅が変わってきて違和感がでてきてしまいます。メッシュオブジェクトが球体であれば、基本的には各パーツが離れて見えたり、伸びて見えたりしてしまうため考慮が必要です。 テクスチャが完了したら、いよいよアニメーションを設定して3Dモデルを動かしてみましょう。 実際の動くホームズくんが見れるAppはこちら です。 LIFULL HOME'S(ライフルホームズ) LIFULL Co., Ltd ナビゲーション 無料 アニメーション編へつづく。

こんにちは。 LIFULL HOME'Sアプリのデザイナーのこばやしです。 2017年9月にiOS ARKitを使った新機能「 ARお部屋計測 」をリリースしました。 この機能は「カメラをかざすとホームズくんが出現して、走ってお部屋を計測」してくれます。ここで登場するホームズくんの3Dモデルを作成しました。 www.lifull.blog iOS ARKit・Android ARCoreの技術により、AR/VR対応の端末・アプリが増えていくことを考えると、デザイナーがモデリングをする機会が増えてくると思い、私と同じく 3Dモデリングをしたことがないデザイナー向け に調べたコト・苦労したコトをまとめました。 全3編の構成で、1編目は「準備編」です。 はじめに 私は「習うより慣れろタイプ」です。そのため、初歩的な内容の記事になりますが、3Dモデリングの初心者入門として読んでいただければ幸いです。 3Dモデルの役割 「ARお部屋計測」では、アテンドとして3Dホームズくんが登場します。3Dモデルを用いることにより、世界観の演出に効果があり、情報をエモーショナルに伝えることができ、表現に広がりを与えてくれます。 iOSのLIFULL HOME'Sアプリで実際にご覧いただけます。 LIFULL HOME'S(ライフルホームズ) LIFULL Co., Ltd ナビゲーション 無料 モデリングのツール 今回はBlenderというツールを使用しました。Blenderはオープンソースの3DCG制作ツールです。 https://blender.jp/ 理由 無料。（開発規模によってライセンスは要確認です） ARKitやUnityとの相性がよい。 操作が独特 「何かオブジェクトを選択する」「手のひらツールのように画面を動かす」などの慣れ親しんだ操作が、Blenderでは異なる操作になります。とりあえず触ってみる自分のようなタイプの人間が最初に困惑するポイントだと思うので、基本操作をIllustratorと比較してみます。 オブジェクトの選択 Illustrator：左クリック Blender： 右 クリック 右クリックはプロパティという固定観念。 視点を移動する（手のひらツール的な動き） Illustrator：space+左クリック＆ドラッグ Blender：Shift+ ホイール押し込み ＆ドラッグ ホイールを押し込むという発想。 視点のズーム Illustrator：option+ホイール Blender：ホイール これはわかりやすい。 AdobeソフトとBlenderを往復して作業しているときは誤操作ばかりしていました。そして「視点操作」は、マウスホイールを頻繁に使用しますので、ホイール付きマウスでの作業をお勧めします。 視点移動のショートカット オブジェクトを各方面から確認するためのショートカットです。よく使う機能なので覚えておくと便利です。 「1キー」正面から 「1キー+ctrl」背面から 「3キー」右面から 「3キー+ctrl」左面から 「7キー」頭上から 他にも、各軸に15度づつ回転、設置したカメラビュー表示などテンキーで操作できます。 モデリングの準備 作業がしやすい画面分割 3Dなので色々な角度でオブジェクトを確認します。主に作業するメインビューと、上からと横からの固定ビューを常に開いて操作していました。作業しながら自分なりによく使う画面を分割表示しておくと作業が捗るかと思います。 下絵を配置する ホームズくんがモデルなので、形状は頭に入っていますが、細かいパーツのバランスなどを感覚で作っていくのは難しいので、3Dモデルの下絵を準備し設置します。 3D View上で「N」キーを押して「プロパティパネル」を表示 「下絵（Background Images）」をチェック 絵を配置する方向、配置するフォーマットを指定 下絵を開くと表示 各画面毎に設定が可能なので、正面・横・頭上・背面からの下絵を準備できると作りやすいです。 今回はモデル作りの前提と実際にメッシュオブジェクトに触れる前工程で調べたコトをまとめました。次回は具体的に3Dモデリング時の便利機能などをまとめようと思います。 つづく

こんにちは、新UX開発部でLIFULL HOME'Sアプリのサービス企画をしていた島田真寿美です。 （記事アップ時には別部署に異動しているため過去形です） 今回は、LIFULL HOME'S iPhoneアプリがiOS11新機能「ARKit」に対応するまでのストーリーをお伝えしたいと思います。 ARKitに対応しました ARKitを使った「ARお部屋計測」 LIFULL HOME’S iPhoneアプリ内に「見学メモ」という機能があります。 物件見学時に「見学メモ」を利用し部屋を撮影すると、撮影した時間と位置情報を利用して、写真を一つのフォルダにまとめる機能です。 今回はこの「見学メモ」をよりユーザー価値の高いものにするべく、ARKitを使い「ARお部屋計測」を開発しました。 「ARお部屋計測」は、カメラを立ち上げると部屋の中にホームズくんが出現します。 部屋の角をタップするとホームズくんが走り出し、そのまま一周すると1cm単位で壁の長さが計測され部屋の寸法が画像化、保存される機能です。 iOS11の方は「右下便利機能タブ > 見学メモ > 間取りをつくる」から体験してみてください。 走行中は目がキラッキラ iOS新機能への対応 2017年9月20日にiOS11がリリースされました。 iPhone/iPad使いのみなさんもアップデートされたでしょうか。 LIFULL HOME’Sアプリも徐々にiOS11ユーザー の割合が増えています。 LIFULL HOME'S iOSアプリ開発チームでは、毎年Appleの発表する新機能をいち早く取り入れてリリースしています。 自社のサービスに合う/合わないはありますが、iOS Developerは星の数ほどいれど、ここまで能動的に取り組めているアプリはそれほど多くはないのではないかと思います。 ・LIFULL HOME'S iOSアプリの対応遍歴 2015年5月　Apple Watch対応 （現在はサービス提供終了） 2016年9月　iMessage Stickers、Rich Notifications対応 2017年3月　Apple TV対応 今年は、iOS11がリリースされる2日前の9月18日に、iOS11の新機能ARKitに対応したバージョン3.13.0をリリースしました。 LIFULL HOME'S(ライフルホームズ) LIFULL Co., Ltd ナビゲーション 無料 なぜ毎年のように新機能開発に取り組むのか？ リソースが有り余ってるからよ！というわけもなく、毎回 (((今回はあかん))) を乗り越えてチームで協力して対応しています。 LIFULL HOME’SアプリチームにもKPIがあり、もちろん業績貢献としての数値目標もあります。 人員を割いてApple WatchやApple TVなどの新デバイス、iOSの新機能に対応するよりも、アプリのCVRやDAU向上施策を行ったほうが短期的には数値目標の達成に繋がるでしょう。 しかし、「新技術への対応による技術力向上」「ユーザーへ新しい体験の提供」など、短期的な数値では測れない価値を創出することで、『常に革進することで、より多くの人々が心からの「安心」と「喜び」を得られる社会の仕組みを創る』という経営理念の実現したいと思い、日々取り組んでいます。 ARKit開発してる場合じゃない 複数の施策がすでに並行しており、今回は稀に見る過密スケジュール。「機能を可能な限り削いで、壁の長さを測るだけならギリいけるか？」の状態でした。 しかし、最終的にリリースしたものは、ホームズくんがシーンに応じてアニメーションや表情を変えながら走り計測してくれるという、計測よりもホームズくんの調整に工数がかかったものになっています。 なぜ工数をかけてホームズくんを追加する？ 「ARKitの開発」が目的になると、ユーザーへの価値提供ではなくチームのエゴのための開発になってしまいます。 「LIFULL HOME’Sだからできること、ができないのであればやらない」を共通指標として、ディレクター・エンジニア・デザイナーが集まってやる/やらないの議論を重ねました。 ARお部屋計測をはじめ、LIFULL HOME'S iOSアプリでは「ユーザーとのコミュニケーション」「楽しさ」「使いやすさ」にポイントを置いています。 ただ「壁の長さが測れる」という機能では、ユーザーに機能価値は提供できても、機能を使う中でエモーショナルな体験は提供できません。 それは「LIFULL HOME’Sだからできること」ではなく、違うアプリが提供しても良い機能になってしまいます。 例えば、ARKitを使う場合、平面を認識するまでユーザーにiPhoneを動かして部屋を見回してもらう、という作業が発生します。 テキストで「平面を認識するためカメラを動かしてください 」と訴求することもできますが、ユーザーにとっては「作業」となり、「楽しい」ものではなくなります。 ARお部屋計測では、カメラを立ち上げるとまず最初に「ボクを探してねっ」というメッセージが表示され、ホームズくんとユーザーとのコミュニケーションが始まります。 「ホームズくんを探す」ことでカメラを動かしてもらい、平面が認識されたらホームズくんが登場し「見つかっちゃったっ」とリアクションします。 この一連の流れにより、「作業」を「コミュニケーション」に変え、「楽しさ」に繋がるように調整しています。 また、ホームズくんが走って部屋を計測するため、 ・ホームズくん出現時：走るためのストレッチ中 ・1周走り終わった時：ぜぇぜぇ疲れている というようなストーリーにし、最後は「頑張ったから画像を見てね」というホームズくんのメッセージにより、自然とユーザーが行動するような動線にしています。 「部屋の計測ができた」という機能価値を提供すると同時に、このような双方向のコミュニケーションを通してホームズくんのブランディング訴求も担っています。 「ホームズくんがいるサービス」という認知の向上から、最終的にロイヤルユーザーとしてアプリを活用し続けてもらえるよう心がけています。 はじめて3Dホームズくんを作るデザイナーとレクチャー中のエンジニア だんだん動いてきた リリース後 ナビゲーションカテゴリとARKitカテゴリにダブルでフィーチャーされました。 iOS11のリリースと同時リリース、ホームズくんが走る、このどちらかが欠けていたら、おそらく掲載されていないと思います。 うれしい まとめ 「面倒」を「楽しく」したい 私はユーザーが「楽しい」体験となることを軸に置いてこれまで施策をしてきました。 住み替え経験のある方は、住み替え最中に「面倒」と感じる部分がいくつもあったかと思います。 なかなか気になった物件に出会えない、引っ越しの荷物をまとめるのが面倒、、など。 アプリ改善の中で面倒を解決できることを前提として、多くの方に訪れる住み替えという活動が、人生の中で少しでも楽しい期間にできることでユーザーに選ばれるアプリとなり、結果業績への貢献にもつながると信じて取り組んでいます。 おまけ メインエンジニアは新卒1年目 今回、「ARお部屋計測」のメインエンジニアを今年４月入社のたらちゃんが務めてくれました。 私やデザイナーからのフィードバックをもとに、計測した値の見やすさやホームズくんとコミュニケーションが取れるような走行スピードなど、連日細部まで調整してくれました。 SNS投稿用に、「は、恥ずかしいです…」と言いながらも人通りの多い社内で廊下に寝転んだりと、リリース後も体を張ってくれています。 まだ（撮影終わんないん）ですか？と今までにない強い口調のたらちゃん たらちゃんのARKitについての記事はこちら qiita.com 新卒活躍中！メンバー募集中だよ！ LIFULL気になってきたって方、絶賛メンバーを募集しています。 弊社1FのLIFULL Tableのランチを食べるついでに、一度来てみてください。 紅茶ブリュレめちゃおいしいです。 以下よりご応募お待ちしてます！ http://recruit.lifull.com/recruiting-information 最後までお読みいただき、ありがとうございました。

LIFULL FinTechの島田です。 LIFULL FinTechで運用する LIFULL保険相談サイト の一部ページにAMP（アンプ）を導入しました。 その際に検討した内容とリリース後しばらく運用してみて得られたAMPに関する知見を共有いたします。 AMP（Accelerated Mobile Pages） AMPはGoogle社とtwitter社が共同で推進しているプロジェクトです。 もともとはネットワーク環境や端末のハードウェアリソースが足りない地域向けにデザインされたものと言われています。 AMPはAMP-HTML、AMP-JS、AMP-CACHEの3つのコンポーネントで構成されています。 AMP-HTML AMP-HTMLはAMP用にHTML5の拡張として設計されたHTMLです。 AMPページとして認識されるために通常のHTMLとは異なる記述が求められます。 大きいところとしては以下の3点かと思います。 imgタグの代わりにamp-imgタグを使用する必要があります cssはhead内に展開する必要があります 構造化データを挿入してページタイプを宣言する必要があります ページタイプについてはすべてのカテゴリがカバーされているわけではありませんが、自サイトと乖離したページタイプを宣言するとスパム行為としてみなされる恐れもありますので注意が必要です。 定義済みページタイプはAMP Projectの ガイド をご参照ください。 AMP-JS AMPページではAMPプロジェクトが認可するJavascript以外は実行できません。 ここがAMPページを作る上でつらいところでもあるのですが、軽量化とキャッシングのために必要なものだと受け入れましょう。 サイトによってはGoogle Tag Manager（GTM）を使用してASPなどが提供するカスタムJSを実行しているケースも多いと思います。 その場合もカスタムJSは実行できませんので注意が必要です。AMP用のGTMコンテナを作成し コンテナ内で許可されているタグ のみ実行可能になります。 開発時に調査した際にはAMPページから一度非AMPページへ遷移させて計測ポイントを経由させているサイトもありました。ただこの場合はユーザの遷移が１段増えますのでユーザビリティの観点から仕様の検討が必要だと思います。 AMP-JSには基本的なUIはカバーされています。LIFULL保険相談でもグローバルメニューや写真表示、アコーディオンなど、AMP-JSのコンポーネントを使用して運用中の非AMPページとUI的に遜色無いレベルのものを作成できました。 AMP-CACHE AMPページを作成する場合に既存ページをどのように扱うか、サイトのURL戦略とすり合わせが必要になります。サイトの流入数に影響を及ぼしますので自サイトのAMP化のロードマップと既存のサイト戦略を慎重に整理して考える必要があります。 アダプティブデザイン AMPページを新規に作る（１） 既存のモバイルページをAMP化する（２） レスポンシブデザイン AMPページを新規に作る（３） 既存のモバイルページをAMP化する（４） PC向けとモバイル向けのページをそれぞれのURLで配信している AMPページを新規に作る（５） 既存のモバイルページをAMP化する（６） web検索で事例がよく上がるのは（１）のケースだと思います。多くの実績があり資料も豊富なのですが、このケースではページが３種類（PC向けページ、モバイル向け非AMPページ、モバイル向けAMPページ）出来上がることになります。同一URLでページの種類が増えるとそこにかける改修コストもn倍になってしまうデメリットもあります。 今回AMP化を検討したページはユーザの回遊フロー上、末端のページになりますので頻繁に改修が入り得るものでした。さらにクライアントからの入稿データが直接表示されるものでもありました。 また、偶然にもGoogle社のAMP推進担当の方とお会いすることができました。参考事例が少ないことに対するリスクはコミュニケーション量で回避できましたので、既存のモバイルページをAMP化する（２）の方針を選択しました。 UAによる振り分け 検索ボットがAMPページを見つけるためには以下の方法があると言われます。 sitemapの送信 非AMPページのlink-rel属性 ダイレクトアクセス web上の資料では2の経路でAMPページが検索ボットの目に止まることになります。LIFULL保険相談の事例では既存ページのサーバが直接AMP-HTMLを返します。PC向けとモバイル向けでボットが別になっているので問題ないとされつつも事例があまりないということで、実験の結果を経てAMP-CACHEにモバイル向けページの内容がキャッシングされることが確認されました。 AMP対応してわかったこと AMP化を実装して感じたことがいくつかありました。 SERPをイメージする URL設計から実際に AMPページとしてインデックスされるところまでシナリオをイメージできるか、ということになります。AMP化する以上はAMP-CACHEに載り自然流入やリッチカードによるSEO効果を得たいところです。ただGoogle社のサーチに関する情報は秘匿されており確たる情報がありません。その中でも理論的な道筋と実証によりひとつずつシナリオを練り上げる必要があります。 URLの設計 既存のwebサイトでよくあるのはURLの最後に「/amp」のようなものがついていてそれがAMPページとなっているケースが多いです。ただURLはパンくずと厳密に対応させているサイトも多いと思います。この方法だとURLが示す情報構造が崩れ、設計上の柔軟性が失われかねません。また前述の通りページの種類も増えますので運用コストも増加します。とはいえ既存ページをAMPページで上書きすることによる技術的・ビジネス的なリスクを許容できるかどうかを判断する必要があります。 Javascriptが制限される これはもうどうしようもないですね。言ってもしょうがないところがあります。とはいえajaxを使いたかったり計測用のカスタムタグを入れたかったりすることは多いと思います。すでにリリース済みの運用ページならなおさらだと思います。また、AMPを導入することを前提にしているとそこが技術的な判断の境界線になります。Javascriptが制限はされますがその分ロードする外部ファイルがスリム化されますのでダイレクトアクセスでもロード時間が短縮されることが多いと思います。AMPを導入する際には機能的な面からもメリットとデメリットを天秤にかけ長期的に検討する必要があると言えます。 まとめ AMP導入によりインデックスも得られ、高速なレンダリングが実現できユーザビリティの向上が得られました。また国内の保険業界の中でもいち早く最新技術を導入することに成功しました。AMPは制限が多いことは事実ですがPWAなどと共に今後の技術展望も開けています。今回サイト内のすべてのページで導入するまでは至っていませんが、今後はAMPの効果を最大化させていきたいと思います。本記事がAMP導入において有益な情報となりうることを願います。

お久しぶりです。技術開発部の相原です。 昨年度は技術基盤部として mrubyを導入したり していましたが今は少しレイヤーが開発寄りになりました。 とはいえ依然として技術基盤も見ていて、最近はご多分に漏れず機械学習を用いた技術基盤の改善に興味があります。 そんな中でここ数ヶ月メインの業務の合間の時間を使って試験的に機械学習を導入していたので、今回は技術的負債の高利子クレジットカードと呼ばれる機械学習を導入する中でどのような工夫をしたかということについて書きたいと思います。 機械学習については門外漢なので、ここではモデルの訓練などのプラクティスに関しては触れません。 (一部暗黙的に深層学習を前提としている箇所がありますのでご了承ください) 技術的負債の高利子クレジットカード Data Dependencies Cost More than Code Dependencies System-level Spaghetti Dealing with Changes in the External World Digdagによるアプローチ Digdagとは 実際にワークフローを構築してみる データの取得 学習 fine-tuning 予測 MItamaeによるワークフロー定義ファイル生成の自動化 最後に 技術的負債の高利子クレジットカード 機械学習は運用における課題が多いことから技術的負債の高利子クレジットカードと呼ばれることがあります。 初出は恐らくGoogleが2014年のNIPSで発表した論文 Machine Learning: The High Interest Credit Card of Technical Debt で、論文中では以下の要因によって技術的負債が生み出されるとされています。 複雑なモデルが外部データに依存することによるシステムの抽象境界の侵食(Complex Models Erode Boundaries) コードへの依存性よりも強いデータへの依存性(Data Dependencies Cost More than Code Dependencies) 複雑なパイプラインの乱立に代表されるシステムのスパゲッティ化(System-level Spaghetti) 不安定な外部世界への依存(Dealing with Changes in the External World) 今回はこれらの課題を解決して安定運用を実現すべく、この中のシステム面に着目しました。 Data Dependencies Cost More than Code Dependencies データへの依存性が強いことに関する問題として、入力として与えられるデータが不安定であることによるモデルへの影響が挙げられます。 入力値となるデータの一部が欠損している可能性やそもそもデータの品質に問題があるケースが考えられ、またデータが時の変化によって活用されなくなったり精度に寄与しないことが後から分かることもあります。 そのためシステムとしてこれらの措置を講じることで不安定なデータによるモデルへの影響を検知できるようにする必要があります。 入力データの静的解析 入力データのバージョン管理 不要な特徴量を取り除くための継続的な精度測定 System-level Spaghetti 機械学習を用いたシステムが陥りやすい問題としてグルーコードデザインパターンというものが存在します。 これは一つのシステムで多くの問題を解決しようとした際に発生しやすく、データの前処理に係る複雑なパイプラインの乱立によってシステムの大部分をグルーコードが占めることとなります。 こうしたグルーコードデザインパターンはシステムのメンテナンスを困難とし、時として再実装が必要となるケースもあります。 また機械学習を用いたシステムは往々にして膨大な設定を必要としますが、これらの設定はモデルに大きな影響を及ぼすものの、コードに関するテストは行われやすい一方で設定のテストは軽視されがちな傾向もあります。 他にも構築したシステムを自立させるためにはタスクのスケジューリングも必要となり、更に転移学習を適用するとなるとそれらのスケジューリングにも依存関係を持たせる必要が出てくることを考慮する必要もあるでしょう。 そのためシステムとしては以下のような要件が求められることになります。 パイプラインの責務の分離 設定値のバージョン管理とテスタブルな設計 各タスクのスケジューリングと依存管理 Dealing with Changes in the External World 機械学習を用いたシステムは外部世界の変化に直接影響される事が多くなります。 外部世界が安定することは稀であり、複数の特徴量から学習していた場合にそれらの特徴量に相関がなくなりモデルに影響を及ぼすといったケースが考えられます。 外部世界の変化によるモデルへの影響を検知するため、システムには以下が求められることになります。 精度のモニタリングとアラート サニティチェックとしての異常値の検出 Digdagによるアプローチ ここからはそれぞれの課題についてDigdagを用いてどのようなアプローチを取ったかということを紹介していきます。 Digdagとは まずはじめに Digdag とはオープンソースのワークフローエンジンです。 .dig というyamlによく似た設定ファイルによって各ジョブの順序や並列度、リトライ処理や処理に失敗した際のアラート処理を定義することができます。 サーバモードで起動することによって常駐してワークフローの定期実行のスケジューリングを行うことも可能で、その際にワークフロー間の依存関係を持たせることも可能です。 今回は機械学習における複雑なワークフローに対してこのDigdagを適用しました。 実際にワークフローを構築してみる これまでのシステムに求められる要件をまとめると以下のようになります。 入力データの静的解析 入力データのバージョン管理 不要な特徴量を取り除くための継続的な精度測定 パイプラインの責務の分離 設定値のバージョン管理とテスタブルな設計 各タスクのスケジューリングと依存管理 精度のモニタリングとアラート サニティチェックとしての異常値の検出 これを踏まえてワークフローを構築してみましょう。 データの取得 # daily_etl.dig schedule : daily> : 00:05:00 +foo : _retry : 3 +get_foo_metrics1 : sh> : SESSION_TIME=${session_time} python elasticsearch_client.py foo metrics1 1day > foo_metrics1_daily.csv +vaidate_foo_metrics1 : sh> : bash data_validator.sh foo_metrics1_daily.csv +commit_foo_metrics1 : sh> : bash commit.sh foo_metrics1_daily.csv +get_foo_metrics2 : sh> : SESSION_TIME=${session_time} python elasticsearch_client.py foo metrics2 1day > foo_metrics2_daily.csv +vaidate_foo_metrics2 : sh> : bash data_validator.sh foo_metrics2_daily.csv +commit_foo_metrics2 : sh> : bash commit.sh foo_metrics2_daily.csv まず最初に作ったのは入力データにまつわるワークフローです。 ここではデータの取得・静的解析・バージョン管理を逐次的に行います。 各プログラムの内容についてはドメインによって大きく変わるので、以下のように定義します。 elasticsearch_client.py.py : 引数に与えられたクラスタ名、メトリクス名、期間を元にElasticSearchからメトリクスを取得する data_validator.sh : 引数に与えられたデータの静的解析を行う commit.sh : 引数に与えられたデータをオブジェクトストレージに保存してバージョン管理を行う Digdagでは session_time 変数としてワークフローが開始された時間を保持しているため、逐次的に処理をした場合でも各ジョブに同一の時間を与えることができます。 また、 _retry パラメータで任意の回数リトライさせることも可能です。 Digdagがワークフロー間の依存関係を持てることから、ここでは学習・予測とはワークフローを分けることで再利用性を高めています。 学習 # daily_train.dig schedule : daily> : 00:10:00 +wait_daily_etl : require> : daily_etl +foo : +train : _parallel : true +train_foo_metrics1 : sh> : python train.py foo metrics1 foo_metrics1_daily.csv +train_foo_metrics2 : sh> : python train.py foo metrics2 foo_metrics2_daily.csv +cross_validation : _pararell : true +cross_validation_foo_metrics1 : sh> : python cross_validation.py foo metrics1 +cross_validation_foor_metrics2 : sh> : python cross_validation.py foo metrics2 _error : sh> : bash notify.sh 学習を行うにはまず事前にデータを取得している必要があります。 Digdagでは require オペレータでワークフロー間に依存関係を持たせる事ができるので、これによってデータの取得を待ってから学習を行う train.py を実行します。 _pararell パラメータを指定すると以下のジョブを並列に実行することができます。 また、学習を行う際には過学習に気をつけなければなりません。 そこで交差検証をして過学習が起きていた際にexit status 1を返す cross_validation.py を用意して、エラー時に発火する _error パラメータを利用して精度のモニタリングを行います。 fine-tuning 転移学習を適用して日次の学習結果を利用した週次のfine-tuningを行いたいといった複雑な依存関係も定義することができます。 # fine_tuning.dig schedule : weekly> : Mon,01:05:00 +wait_daily_train : loop> : 7 _do : require> : daily_train session_time : ${moment(last_session_time).add(i, 'day' ).format()} +foo : +train : _parallel : true +fine_tuning_foo_metrics1 : sh> : python fine_tuning.py foo metrics1 +fine_tuning_foo_metrics2 : sh> : python fine_tuning.py foo metrics2 loop オペレータで require による待ち受けを繰り返しで行うことによって日時の学習結果が出揃ったら実行という依存関係を実現しています。 予測 もちろんdaily, weekly以外にも柔軟なスケジュール定義が可能です。 予測といった頻繁に実行したいワークフローは以下のように定義します。 # predict.dig schedule : minutes_interval> : 5 +foo : +predict : _parallel : true +predict_foo_metrics1 : sh> : python predict.py foo metrics1 +predict_foo_metrics2 : sh> : python predict.py foo metrics2 _error : sh> : bash notify.sh 先ほどと同様に異常値が検出されたらexit status 1を返すようにしてアラートすることでモデルが正常に予測できているかどうかをモニタリングすることが可能です。 予測とは別のワークフローでPrediction Biasを記録してモニタリングするといったアプローチも有効になります。 その際は require オペレータで predict.dig を依存とするとうまく動くでしょう。 MItamaeによるワークフロー定義ファイル生成の自動化 ワークフローエンジンはDigdag以外にも多く存在しますが、Digdagの特徴はDSLでプログラマブルにワークフローを定義できる点にあると思います。 そこで今回はワンバイナリで動いてmrubyでプロビジョニングを記述できる MItamae を利用して、プロビジョニング時にワークフロー定義ファイルも自動生成するようにしました。 yaml = YAML .load_file( File .join(__dir__, ' ../config.yml ' )) file ' /opt/ml/predict.dig ' do jobs = yaml.each_with_object( '' ) do |( key , value ), string | value.keys.each do | metrics_name | string << <<- EOS + #{ key } : +predict: _parallel: true +predict_ #{ key } _ #{ metrics_name } : sh>: python predict.py #{ key } #{ metrics_name } EOS end end content <<- EOS schedule: minutes_interval>: 5 #{ jobs } _error: sh>: bash notify.sh EOS end これはMItamae( Itamae )の表現力とDigdagのDSLがあってこそで、事前に機械学習に用いる設定値とともにワークフロー生成に必要な情報を記述した以下のような config.yml を利用してワークフローを自動生成します。 そのため異なる設定値もこの config.yml に設定を追加するだけでデプロイすることが可能となります。 # config.yml foo : metrics1 : fine_tuning : - 'weekly' lstm : unit : 10 window_size : 10 metrics : elasticseaerch : index : 'foo_metrics1' metrics2 : lstm : unit : 6 window_size : 6 metrics : elasticseaerch : index : 'foo_metrics2' ワンバイナリで動くプロビジョニングツールということもあり、別の環境で十分なテストをしてからプロダクションに入れるといったような事も容易になるでしょう。 これによってワークフローの構成管理をコード化してレビューフローに乗せるだけでなく、設定値についてもそのプラクティスを適用し、同時にテストしやすい仕組みも実現することができました。 最後に 疑似コードだらけになってしまいましたが、論文中にもあるように機械学習を用いたシステムを安定運用するためにはエンジニアとリサーチャーの歩み寄りが重要であると考えています。 実際にこうしたワークフローエンジンを導入することでエンジニアリングのノウハウを機械学習を用いたシステムにも適用することができました。 今回は小規模なシステムのため一人で構築してしまいましたが、論文中にはエンジニアとリサーチャーが同じチームで働いているという記述もあり、大規模なシステムになるにつれその重要性は高まるでしょう。 機械学習を用いたシステムはまだまだ運用実績が少ないですが、技術的負債の面にもしっかりと目を向けて安定運用を目指していきたいです。 ご利用は計画的に。

こんにちは！ 新卒採用デザイナー職担当の水村です。 今回は、「デザイナーの企業選び」をテーマに、LIFULLに新卒入社した若手デザイナー3名のインタビューをお届けします。18卒・19卒の学生の皆さんの参考になれば嬉しいです！ では、さっそく話を聞いていきましょう！！ (左)ニックネーム：こさい 新卒3年目。大学時代は、学校でデザイン全般について学びながら、アルバイトでWEBサイトの制作に従事。1～2年目は「LIFULL HOME'S」新規サービスのサイトデザイン、プロモーションを目的とした紙、リアルイベント、ノベルティのデザインからディレクションまで幅広く携わる。3年目から自ら希望を出して異動した部署でデザイン、企画から、広告運用まで担当。 (中)ニックネーム：ぼこ 2017年入社のピカピカの新卒1年目。大学時代はプロダクトデザインを専攻しながら、学生団体に所属し、地域活性化のための冊子を制作。デザイナーとして参加した全国規模のHackathonでの優勝経験あり。入社後は、「LIFULL HOME’S」でデザイナーとして修業中！ (右)ニックネーム：がらし 新卒2年目。学部時代はロボット工学を専攻し、大学院では人間工学に基づくWebアニメーションについて研究。Life is techのインターンも経験。現在は「LIFULL HOME’S」のAndroidアプリのデザインやプロモーション動画の編集などを担当。 就活の軸 水村：早速だけど、3人はどんな軸で就活していたの？ がらし：初めてのインタビューなので緊張しますね(笑)。 水村：飾らずに素で話してもらえたらOKですよ！ がらし：僕はとにかくデザインやものづくりが大好きで、同じ熱量でものづくりをしている会社を探していました。最初から絞ることはせず、けっこう多くの企業を見ていましたね。 こさい：私は人に喜んでもらうのが好きな性格なので、ユーザー目線を最も大切に働きたいと思っていました。そういう意味で、ものづくりに真剣な会社を探していましたね。 ぼこ：私も大学時代の地域活性化の活動などから、人の暮らしを良くしたいという想いがあって、それを叶えられる会社で働きたいと思っていました。自社サービスの会社と制作会社で迷いましたが、対クライアントではなく対エンドユーザーの立場でサービスをつくりたいと思い、最終的には自社サービスの会社に絞って就活をしていました。 水村：ぼこちゃんは、大学ではプロダクトデザインを専攻していたけど、どうしてWebデザイナーを選んだの？ ぼこ：Webデザインは、ユーザーの反応に対してすぐに改善することができるので、PDCAを早く回せるのがいいと思いました。プロダクトデザインは一度つくってしまうと後から変更するのが難しく、時間もかかるので、私には前者の方が合っているなと思ったんです。ユーザー目線で常にいいものをつくり続けたいと考えていました。 LIFULLを選んだ理由 水村：3人とも多くの会社を見ていた中で、LIFULLを選んだ理由って何？ こさい：なんだか3年前の面接を思い出しますね(笑)。 がらし：LIFULLは、真剣にユーザーのことを考えている社員ばかりで、単純にかっこいいなって思いました。この人たちと働きたいって。 ぼこ：私も先ほどの通り「人の暮らしをよくしたい」という想いがあったので、LIFULLはドンピシャでしたね。暮らしの「不」を解消するというビジョンにとても共感できて、「あ、ここしかない！」と。 こさい：逆に、私は疑い深いので(笑)、他に内定をいただいていた2社ととても迷っていましたね。 水村：とても迷っていたよね(笑)。こさいさんは、迷っていた中で何が決め手だった？ こさい：最終的には、がらしとぼこちゃんと同じですね。一番の決め手は、LIFULLは本当にユーザーの暮らしや人生を考えてサービスをつくっていると感じたことですね。選考で会った一人ひとりの社員からとても伝わってきました。 がらし：僕も、言っているだけではなく、実行しているのがカッコいいなと思いましたね。LIFULLは、アプリのレビューページのユーザーのコメントに対して、とても細かく返信していたのが印象的でした。 水村：デザイナーに限らず、LIFULLのビジョンや利他主義という価値観に共感して入社を決める人がとても多いよね。採用担当者としても、スキルだけではなくLIFULLのビジョンや文化に合っているかを重視して採用活動をしています。 LIFULLでのキャリア・働き方 水村：みんなは、入社してからどんなことに挑戦してきたの？ ぼこ：私はまだ入社4か月ほどですが、サイトのバナーやクライアントに配布する卓上カレンダーのデザインなど、ユーザーやクライアントが目にする部分の制作を任せていただいています。 こさい：LIFULLは、早い段階から任せてもらえるよね。私も入社して数ヶ月でCMや交通広告といったプロモーションに関わる大きなプロジェクトに携わらせてもらいました。私はいろいろなことに興味があったので、その後も広告からサービスまで幅広いデザイン業務に取組んできました。 がらし：僕は、LIFULL HOME’Sの新築一戸建てマーケットと中古一戸建てマーケットの統合というプロジェクトに関わらせてもらいました。既存の仕組みを変えるという非常に大きなプロジェクトでしたが、デザイナーは2年目の僕1人だけでした。大変なこともありましたが、PM、エンジニア、ディレクターと協力し、何とか約3ヶ月間で完遂！入社2年目でもこういった大きなプロジェクトを任せてもらえることは、プレッシャーもありましたが、その分やりがいを感じました。 こさい：プレッシャーを感じることはあるよね。(笑) でも、その先に実感する成長もある。１年目に「快適通勤検索」という新規サービスの立ち上げに参加した際、企画から関わらせてもらいました。ユーザー目線で本当にいいサービスにするために、他職種のメンバーと社歴の長短に関係なく本気でぶつかりながら議論して制作したのは良い経験になりました。3年目の今年からLIFULL HOME’Sの不動産投資部門に自分で希望を出して異動しました。サービスをより良くするために、これまでの経験を活かしてデザインだけでなく企画や広告運用にも携わらせてもらっています。 こさい：LIFULLには、キャリア選択制度があり、自分から手を挙げて部署異動や職種変更ができるので、自分のやりたいことに挑戦しやすい環境だと思いますね。 ※キャリア選択制度：半年に1度、上司と面談を行い、中長期的なキャリアビジョンを明確にし、異動希望や職種変更の希望を申請することが可能。毎回希望者の約60%が承認されている。 ぼこ：日常の業務でも、先輩や上司が親身になって相談にのってくれるので、自分の意見やアイデアを言いやすいです。むしろ新人かどうかなど関係なく意見を求められます(笑)。 がらし：LIFULLは、「あらゆるLIFEを、FULLに。」することを目指している会社なので、まずは会社や個人として「こうしたい」というビジョンや意志を起点に仕事をしているのだと思います。デザイナーに限らず多くの社員が自分の想いを持って働いていますね。 こさい：自社サービスの会社なので、デザイナーでも企画段階から関われることも多いですしね。自分のやりたいことや想いを大切にしたい人にとっては、ベストな環境だと思いますね。 就活生へメッセージ 水村：最後に、就活生の皆さんへメッセージをお願いします！ ぼこ：ものづくりをするときに大切にしているものは、それぞれ違うと思います。カッコいいデザインが好きな人、新しいものをつくるのが好きな人・・・。その自分の軸に合ったものづくりをしている会社に入れば、きっと仕事は楽しいと思いますよ！ がらし：僕も同じ感覚です。自分の好きなことややりたいことをやってほしいですね。そうすればモチベーション高く働けます。あとは、一緒に働く「人」も大切にしてほしいですね。 こさい：新卒は自分で自由に選べる貴重なタイミングなので、後悔のないように色々な会社を見てください！そして、ぜひ自分のやっていきたいことに挑戦してほしいなと思います。 水村：3人ともありがとうございました！就活生の皆さんに、少しでも参考になれば嬉しいです！！では、またお会いしましょう～！ ◆LIFULL　デザイナーセミナー開催中!!◆ URL： 株式会社LIFULL （旧ネクスト）新卒採用 エントリーページ

こんにちは。LIFULL HOME'Sの、主に賃貸領域のサイトデザインを担当している山田 和代と申します。つい先日、LIFULLのデザイナーによる外部に向けた勉強会＆交流会である「デザイナーの放課後　#1 サービスを成長させるデザイナーとは？」を開催しました！　本日はその様子をご紹介します。 「デザイナーの放課後」とは このイベントを立ち上げた理由や経緯をご紹介します。もともとLIFULLではデザイナー・フロントエンドエンジニア同士でお互いの仕事のナレッジを共有し合う会を実施しており、その会を母体に「外部の方に向けて発表し、交流の場としてはどうか？」と提案したのがきっかけです。 また、自分たちの仕事を外部の方に向けてご紹介することで発見があるのではないか、外部の方にもっとLIFULLのデザイナーのことを知っていただけるといいのではないか、といった思いもこめてイベントを立ち上げました。 そんな期待をこめた「デザイナーの放課後」、記念すべき第1回には、「NAVITIME」「ZOZOTOWN」のデザイナーさんをゲスト登壇者としてお迎えしました。 オープニングの様子 「イベントをやろう！」と意気込んでからずっと「聴講者の方は集まってくれるのだろうか…」という不安が最も大きかった気がしますが、当日には関係者の方も含めて満員の大盛況！　ほっと胸をなでおろす瞬間でした。 司会は、LIFULL HOME’S iOSアプリ担当のデザイナー、小泉 きなみがつとめました。緊張で「今にも踊り出しそう」とつぶやく小泉。 冒頭のLTタイムでは、サービスをデザイナーの力でより魅力的にし、成長させていくにあたっての考え方や仕事の進め方などについて、比較的大規模なサービスを運営する事業会社のデザイナーからの発表を行いました。 LT1　「つながる」サービスをつくる　LIFULL HOME'Sにおけるデザイナーの役割 トップバッターは、弊社のLIFULL HOME'S事業本部 流通UXユニットの鈴木 亜依です。ハリネズミと紫色をこよなく愛するデザイナーで、卓越したコミュニケーションスキルで社内でも頼りにされている存在です。 鈴木からは、先日リリースされた「LIFULL HOME’S 住宅評価」の開発秘話をまじえて、LIFULL HOME'Sの開発体制においてデザイナーはどうありたいか、どのようなシーンでデザイナーが貢献できているか、という点について発表を行いました。鈴木らしいパッション溢れるLTで、社内から見学に訪れたLIFULLの社員も、興味深く聞いていたようでした。 LT2　サービスを成長させるデザイナーのリーダーシップ 次にお話いただくのは、株式会社ナビタイムジャパン デザイン部 髙橋 将太さん。デザイナーでありながら、ウォーキングやお散歩など、歩くことに興味がある人向けのアプリ「ウォーキングNAVITIME-ALKOO-」のプロジェクトマネージャーをつとめる髙橋さんは、デザイナーがPMとしてプロジェクトに携わるお話を聞かせてくださいました。 LT3　ZOZOTOWNのデザイナーの「役割」と「考え方」 最後に登壇していただいたのは、ZOZOTOWN・WEAR等を運営する株式会社スタートトゥデイ工務店のデザイナー　樋口 智丈さんです。樋口さんは、フロントエンドのリーダーもされているそうです。 樋口さんからは、ZOZOTOWNのデザイナーは「仕事を自事（自分の事）（自然な事）としてとらえて考える」というマインドでデザインしているというお話や、具体的な施策の考え方に触れた発表を行っていただきました。 ディスカッション ここから進行を私（山田）に替わりまして、登壇者の方々に会場のみなさんから質問をいただきながらディスカッションする時間を設けました。 私から質問させていただいたものの一つはこちら、「デザイナーとエンジニアの比率はどのくらいか」。サービスを成長させるにあたって、デザイナーとエンジニアの比率に「黄金比」はあるのか？！　という疑問を日頃抱いていたため、このような質問を投げてみました。ここでは、鈴木から「デザイナーもっと欲しい」という声が漏れ出ました。 会場のみなさまからもたくさんの題材をいただきまして、そのなかの一つ、「採用に関して工夫している点は」という声には、樋口さんからスタートトゥデイ工務店の採用サイトに関してのコメントをいただき、会場が沸く瞬間も。 最後に 最後にご用意したビアバッシュの場には、多くの方に参加いただき、大盛況でした！　スタッフ一同、心から安堵し、喜ばしい時間となりました。初回とあって、準備は終始ワタワタとしていましたが、笑顔で帰っていってくださった方が多く見受けられ、「開催してよかった…！」と強く感じました。 「デザイナーの放課後」は、第2回、第3回と続けていきたい取り組みですので、お越しいただければ幸いです。 こちら にて、LIFULLのデザイナーやエンジニアが運営するイベントの多くを告知しております。ぜひ一度、ご覧になってみてください。

こんにちは。LIFULLの新卒2年目マーケターの松井です。 今回は、7月に開催されたマーケター総会について共有させていただきます。 マーケターの人材育成やキャリア像を考える方のご参考の一つになれば幸いです。   マーケター総会とは？ LIFULLでは、マーケターに関わらず、エンジニア、デザイナーなど職種別の総会を定期的に実施しています。   人材育成の考え方として、 組織別の人材育成と、職種別の人材育成の双方 を重要視しており、職種別の総会は、職種ごとの目指す方向を共有するビジョンシェアリングの意味を込めて開催されています。   また、今年の5月にLIFULLでは、改めて マーケターのキャリア像を明確に定義 しました。 LIFULL マーケターのキャリア像に ついて 以下の内容が、LIFULLにおけるマーケターのキャリア像として掲げられています。   マーケターとしてタイムレスなスキルを保有し、 マーケティング・コミュニケーションをトータルプロデュースできる人材    文章ではこのように定義されているのですが、まだマーケターの実務経験が浅い自分自身にとって、 「マーケターとしてのタイムレスのスキルとは？」「マーケティング・コミュニケーションをトータルプロデュースできるってどういった状態？」 と言ったように、中々腹落ちしきれない部分がありました。   今回の総会は、そういったマーケターのキャリア像、マーケターに求められるスキルを具体的にイメージするために、ベストインクラスプロデューサーズの代表取締役社長　菅 恭一氏を外部講師としてお招きして開催されました。   第一部「デジタル時代のマーケティングプロデュース術」      菅氏には、「デジタル時代のマーケティングプロデュース術」というタイトルでご講演いただきました。   菅 恭一氏(ベストインクラスプロデューサーズ) 1998年朝日広告社入社。食品、流通、金融、人材、不動産など多業種における、デジタルマーケティングの戦略構築、コンサルティングを担当したのち、2004年に次世代型デジタルマーケティング組織を起案。以降10年間のリーダーシップを通じてトリプルメディア領域におけるコミュニケーションプランニングとデータドリブンなマーケティングマネジメントをシームレスに実践する組織基盤を構築。 2015年4月、データドリブン型コミュニケーションシナリオの開発を軸に、デジタル時代の企業と生活者の関係構築を支援するマーケティングプロデューサー集団、株式会社ベストインクラスプロデューサーズの創業の参画、代表取締役社長に就任。   マーケティング活動のプロセス明確化の重要性 講演の冒頭は、マーケターを取り巻く環境やマーケターが抱える課題をベースとして、 マーケティング活動を構造化し、プロセスを明確にする必要 があるというお話をいただきました。以下のスライドがその事例となります。     プロセスに落とすメリットとして、菅氏は 「プロジェクトに入る前にゴールまでのプロセスがあると、振り返りし易い」 というお話がありました。上記のようなフレームワークに落とし込む重要性を、実際にプロデュースしたクライアントの案件の事例も踏まえて、説明いただきました。 マーケターに求められるスキル要件   その上で、マーケターに求められるスキル要件について、以下のように定義されていました。 １．プロデュースする力　 ２．データを読む力 ３．シナリオを作る力   目指すべきは、 「プロデュースする力」を持ち、「データを読む力」「シナリオを作る力」のいづれか(3つのスキルのうち2つ)を兼ね備えているハイブリッド人材 というメッセージを受け、第一部の講演は終了しました。   第二部　トークセッション   第二部では、上記のご講演を基に、以下の点についてLIFULLマーケター職種長の菅野(すがの)氏と菅氏でトークセッションを行いました。     菅野　 最後のスライドで、プロデュースする力、データを読む力、シナリオを作る力を持つハイブリッド人材のお話がありました。   それぞれ3つのスキルに関しては、LIFULLのマーケターのスキルマップでも、データ活用やコミュニケーション設計は入っていて、プロデュースする力は社内調整力やプレゼンテーションスキルといった要素として含まれおり、 それぞれマーケターとして保有すべきタイムレスなスキルとして定義されています。   ただ、「なぜハイブリッド人材が重要なのか？」については、現状社内のマーケターに説明ができていませんでした。菅さんは、 なぜスペシャリスト人材ではなく2つ以上兼ね備えているハイブリッド人材が重要なのか？ と考えていらっしゃるのかをお伺いしたいです。   菅氏　 よくT型人材と言われるように、 1つは自分の強みとなる領域は持った方が良いと思います。 たとえばデータを読む力がありますとか、アクセス解析ができます、運用型広告はハンズオンで運用できます、と言ったような。   ただ、それを部分最適ではなく、自分の掘り下げてやっていることを、 もう少し大きな目線で事業の問題の解決にどうつながっているのか？という視点で専門性を活かしていこうと思うと、戦略を考えないといけないと思っています。   よく、若手でデジタルマーケティングを初めてやる方は、リスティングやSEOなどからスタートすることが多いと思いますし、それはそれで良いですが、それだけだとキャリアとしては、大きい意味での事業貢献にはつながりにくい。 それを活かしながら、もう少し大きなレイヤーで売り上げを伸ばすとか、数を増やすとか、先ほどのマーケティングモデルを描きながら自分は何をするのか？というのはすごく大事だと思います。   菅野 　ちなみに 先ほどの3つのスキルの中で多い組み合わせなどはありますか？   菅氏　プロデュースする力、シナリオを作る力の組み合わせが多い かなあと思います。データに関しては、 データの専門性を持っていることと、データに対してのリテラシーがあることはちょっと違う と思っていて、データにものすごく深く行かれる方は特殊能力だなと思っています。   なので、 プロデューサーは、ものすごく専門性が高い方が深く行き過ぎるところを、もう少しビジネスに焦点をあててデータの切り方をディレクションできたりするのは重要です。 データが全くわからないとちょっと困っちゃいますね。そう考えると、プロデュースする力、シナリオを作る力のセットが多いですが、 データが分かるプロデューサーはそんなに多くないので、これからより求められると思います。   菅野 　こちらに関連して気になったのは、 先ほどの3つのスキルと仕事の組み立て方について、ある限られたポジションの人しかできないのでしょうか？それとも細分化された１つの業務の中でもできるのでしょうか？   菅氏　できると思うし、是非やった方が良いと思います。 プロセス自体は、経験があった方がうまくいくこともあるんだとは思いますが、 そこは経験関係なく、一人でやるのでなく、たとえばシニアの方、ジュニアの方、ミドルの方と同じチームで同じプロセスを設計してみるのが重要だと思います。   菅野 　次に マーケターの能力開発 について、先ほど出たマーケターが身につけるべきスキルはどのように獲得するか？についてお伺いしたいと思います。実際、どうようにすれば身につくのでしょうか？   菅氏　 当たり前といえば当たり前なんですが、 マーケティングの基本的なフレームワーク、3Cであったり、戦略づくりの中ではSWOTとかベーシックなフレームワークは持った方が良いですよね。 たとえばリスティング広告やるにしても、そういった視点は取り入れた方が重要だと思います。タイトル、ディスクリプションをつくるといった業務の中でも、どのマーケット、どのセグメントの人を取りにいくのかを考えながら運用するのが重要です。   そういったことを考えない時によくあるのが、現場では預かっている予算と取らないといけない数があると思うんですが、そうすると取りやすいところにどんどんシフトしていってしまうこと。 数字上は会社から預けられているKPIは達成しているんですが、そもそも、そのプロダクトはどういうお客さまに買って欲しいのか、愛して欲しいのかとギャップが出てくるケースがあると思います。 その結果、効率よく取れたけれども商売としては長続きしないといったことが起こりやすいです。   そういったギャップを埋めるためにどういったコミュニケーションの設計やチューニングが必要か？というのを課題にして動かすことが重要。先ほどの戦略の話があると、数字があるけど実は違うんだよねが分かってきます。   なので 実務をやりながら戦略を考えるというのが重要 だと思います。   菅野　 社内でも、マーケティング研修というものを開催していて、社員がフレームワーク嫌いにならないような取り組みをしています。   次に伺いたいのは、 マーケターのキャリアデザイン について。マーケターはどんなキャリアを築くと良いというのを伺いたいです。   菅氏　　 最終的にはジェネラリストかスペシャリストか、という分かれ道がどこかで来ると思っています。身も蓋もないことを言うと、個人のやりたい方で、と思っています。笑   ただ、足りてないなと思うのは、ジェネラリストの方だと感じています。 スペシャリストは若い段階から色んなスペシャリティを身につけられるので、そういった入り口で良いと思っていますが、やっぱり複数の領域に共通言語を持って話ができることが、マーケティングは1人で、1社で完結できることはほとんどない中で重要になってきます。 たとえば 広告代理店、ITベンダー、コンテンツの制作会社といった違うスペシャリストにマーケティングの目線で、それぞれの言語に対して６，７割の共通言語で話ができて、全体を構造化してマネジメントすることがすごく大事 なんですけど、そこができる人材は少ないと思っています。   菅野　 最後に、LIFULLのマーケターにメッセージをお願いします。 菅氏　 僕のオススメは、是非 プロセスをやって欲しい と思っています。感覚的に進めてきたことが手順化されてきて、その手順自体が良いときも悪いときがある、暗黙知が形式知化され、チームに共有してチーム力が上がっていくのを感じているので、ぜひやっていただきたいです。   あとはデジタルに限らずですが、 どういうお客さまにどういう価値を提供したいのかという、そもそもの事業やサービス理念の部分と、実際に現場で起きていることのギャップを大事にして欲しいです。 数字でいえば取れてたとしても、本当に自分たちの価値がお客さまに伝わっているのか？とか、伝えたい方にちゃんと愛してもらっているのか？という部分。 この2つがくっつかないからこそ、マーケティングは面白いんだと思っています。 ギャップを意識するのと、そのギャップを埋めるために何をするのか？の目的意識がすごく大事にできればなと思います。本日はありがとうございました。   その後、会場の参加者から質問を受け、マーケター総会は終了しました。  終わりに 参加した社員の声 社員A 「個人的には、マーケティングのプロセスが形式知化されていない問題はハッとするものがありました。だからといって型（フォーマット）を増やしていきましょう、という単純な話ではないですが。価値ある気づきが多くありました。」   社員B 「トップダウン型（設計主導）とボトムアップ型（施策主導）の話がありましたが、（世の中にはおそらくボトムアップ型が多いので）敢えてトップダウンをもういちどちゃんとやりましょうよっていう話なのかな？と理解しました。一方で複雑化するマーケティングにおいてはバランスが大事なのでちゃんと両方の視点を持つことが必要なのでしょうね。」   個人的な感想としては、自分自身の関わっているマーケティングを見つめなおし、マーケターとしてどこを目指すべきかを考える非常に良い機会となりました。日々の業務に追われれば追われるほど、プロセスを省略して、数字の部分しか見えなくなる傾向が個人的にあるのですが、数字の部分とサービス理念といった部分といったより戦略に近い部分を意識しながら、業務に励んでいければと思います。   最後に、LIFULLでは新卒/中途関わらず、一緒に働くメンバーを募集しています。 ご興味を持っていただけましたら以下のリンクよりお気軽にご連絡ください。 株式会社LIFULLの採用/求人一覧    総会の全スライドはこちら LIFULLマーケター総会スライド（2017/07）