こんにちわ、エンジニアの鈴木( Kentaro SUZUKI (@szk3) | Twitter )です。 今年もAWS のカンファレンス re:Invent に来ています！ ラスベガスは連日快晴で、いよいよ本日からre:Inventが本格的に始まりました。 そして、昨日のイベント発表されたロボットアプリケーションの開発を支援する新サービス AWS RoboMaker はだいぶ衝撃的でした！！ 発表されたタイミングで、セッションとワークショップが追加されたので、 初日から予定を組み替えて参加してきましたのでフィードバックします。 aws.amazon.com AWS RoboMaker ってなんなの？ 端的にいうと、 ロボットアプリケーションの開発支援サービスの総称 です。 ロボット開発って（慣れない人にとっては）めちゃくちゃ難しいんです。 今後のことを考えると、ロボットが活躍できるシーンは右肩上がりになることは想像に難くありません。 ですが、ロボットを使ってイノベーションを起こそうという人の絶対数が足りてない現状があります。 なぜ足りないかというと、 そもそもロボットアプリケーションの開発が様々な面で難しかったり、開発の準備や手間に時間がかかったりする ことが開発者不足の原因のひとつとして挙げられます。 つまり単純化すると、 難しい → 人が少ない → イノベーションが起きづらい という構造になっています。 こういった流れを変えるべく、簡単にロボットの開発ができるような環境を整え、開発のハードルを下げることで、 新たな開発者を取り込みイノベーションを起こしやすくしよう というコンセプトのもとAWS RoboMakerは誕生しました。 そして、ロボット開発を構成する主要機能（デプロイ、テスト、シミュレーション、ロギングなど）を、 AWS RoboMakerとして、いままで培ってきたAWSサービスと統合させることで実現している と考えられます。 では、さっそくセッションの内容から見ていきましょう。 Announcing AWS RoboMaker: A New Cloud Robotics Service 本セッション スライドより引用 このセッションは大きく分けると２部構成でした。 一つは、冒頭にあげたような、AWS RoboMakerについての説明を中心に、内部で使われるROS(Robot operating system)や、RoboMakerの構成要素の説明などの ガイダンス的な説明 。 もう一つは、実際にケアに使われる ロボットのデモ がメインでした。 まず最初に、ロボットアプリケーションの開発が難しい理由について内容に触れ、 それらをどのように解決するかという内容で、ブレイクダウンしていきます。 テスト、Cloudへの拡張、デプロイ、シミュレーションといったテーマに沿いながら大枠の解説がありました。 個別の説明は省きますが、シミュレーションについて思うことは、 いままで個人が用意するのがかなり難しいと感じる部分だと思うので重宝する機能になりそう です、またハード側との問題の切り分けに大きく貢献しそうだなとう印象です。 詳しい内容は後日動画が公開されるので、そちらを見ていただくのが確実です。 そして、セッションの最後には、実際に実装されたロボットが登場します。 デモでは、ロボットの姿を表示したWebページが用意され、登壇者がロボットにふれるとセンサーが反応してWeb上に反映されるというようなデモでした。 反応速度もよく、かなり安定しているという印象 を受けました。 本セッション スライドより引用 Use AWS RoboMaker to Develop a Robot Application to Track and Find Fido 本セッション スライドより引用 午前中のセッションが終わり、本日最後の枠では、 RoboMakerでロボットアプリケーションを作るWorkshopに参加 しました。 こちらは、2時間を超えるWorkshopとなりますが、基本的にはHelloworld的なアプリが２つ用意されているので、そちらを手順に沿って実装していく形になりました。 本来はワークショップ中に2つのロボットアプリケーションを実装する予定でしたが、 Workshopならではのトラブルも発生し、 残念ながら内容を最後まで消化することができません でした。。。 ただ、 現場に居合わせたAWSの方々の支援や、同じセッションに参加されていた日本人の方々とお話させていただくことで理解を深めることができました。ほんとうにありがとうございました！ なので、フィードバックらしいフィードバックができるほど理解できたわけではありませんが、 最終的には 一つのロボットアプリケーションを作り、シミュレーションするところまで出来ました。 まとめ もちろんハード側のことには一切ふれていないので、実際に動くものを作るとしたら他の知識も必要です。 ただ、 開発周辺の環境だけでも楽になれば、開発への心理的・技術的ハードルが下がり、スピード感もかなり違ってくる と考えます。 子供教育の観点でみても、ロボット開発はかなりホットで面白い分野だと思います。 また、 Robotics Anywhere はすでに始まっており、この流れは止めることはできない でしょう。 そんな時流に乗って登場した AWS RoboMakerは開発者の間口を広げる素晴らしいサービスだと思います。 今後も動向を追いつつ、自分でも何か作ってみたいと思います！

こんにちわ、エンジニアの鈴木( Kentaro SUZUKI (@szk3) | Twitter )です。 今年もAWS のカンファレンス re:Invent に来ています！ re:Inventでは、毎年1000を超えるセッション等が行われます。 reinvent.awseventsjapan.com そのため、個人としてカバーできる範囲はどうしても少なくなってしまいますが、動画が後日公開されるため、内容に関しては後日キャッチアップすることが可能です。 では、なぜ動画でキャッチアップできるのに、わざわざ高いコストをかけて現地に来る必要があるのでしょうか？ それはやはり、 現地でしか味わえないライブ感を味わうため だと思います。 ライブ感とは、実際にAWSの開発者とディスカッションできたり、ハッカソンやワークショップに参加したり、他社交流だったり、 人それぞれ だと思います。 とにかく フィードバックして伝えていくことが大切 で、この体験を活かす為の最初の一歩だと考えています。 以下は、自分が書いた2年前の参加レポートになりますが、当時考えていたことは今でもそんなに変わっていません。 www.lifull.blog 今年も とにかく楽しんで行こう と思います！ 参加者の皆様、現地では仲良くしてください！ よろしくお願いいたします！！

こんにちは、LIFULLのPythonエンジニアの二宮です。 昨年 に引き続き、今年もLIFULLではQiita Organizationの企業アドベントカレンダーを行います。 LIFULL Advent Calendar 2018 LIFULL その2 Advent Calendar 2018 LIFULL その3 Advent Calendar 2018 昨年の繰り返しになりますが、このLIFULL Creators Blogに比べて、Qiitaではより技術職メンバー個人の情報発信・共有にフォーカスしており、アドベントカレンダーでもそれぞれの工夫や発見を共有する予定です。 「株式会社LIFULLってどんなメンバーがいるの？」「どんな技術が使われてるの？」って興味を持たれている方は、それぞれの記事をご覧いただけると嬉しいです。 それでは、12月1日からの更新をお楽しみに！

こんにちは！LIFULLでジンジニアしている木村 @kimkimniyans です。 秋も深まって外に出るのも家でのんびりするのも何をするにもいい季節になってきましたが、知ってますか？ 油断してるとあっという間にさむいさむい冬がやってきます。イヤですね寒い冬。 しかしっ、そんな寒さも吹き飛ばすアツいイベント、 PHP Conference が今年も開催されます！ 開催日：2018/12/15(土) 会場　：大田区産業プラザ PiO PHP Conference 2018にLIFULLもスポンサーをさせていただいています！ 企業ブースも出させていただく予定になっていまして、 新バージョンのホームズくん＆LIFULLステッカーやおやつタイムに最適なオリジナルお菓子 をお配りする予定です。 ぜひブースにもお越しください♪ PHPは弊社国内主力事業であるLIFULL HOME'Sのサーバサイド言語で採用しており長いお付き合いです。 PHPの国内ビッグイベントをサポートできることをとても楽しみにしています♪ LIFULL Tシャツを着た弊社スタッフを会場で見かけましたらぜひお気軽にお声がけください 。 それでは会場でお会いしましょう！ エンジニア積極採用中！ PHPエンジニアはもちろん、各種エンジニア募集中です！ご興味ある方ぜひ覗いてみてください。 hrmos.co recruit.lifull.com

概要 初めまして！ LIFULLでWebエンジニアとして働いて3年目、LIFULL HOME'Sの中古物件領域でエンジニアをしている齊藤 裕介です。 趣味の将棋にちなんで、ニックネームで 名人 と呼んでもらっています。 先日自部署で行った 「浅草BINGO鬼ごっこ」 という独自企画のチームビルディングがかなり盛り上がったので、ぜひ社外にも発信したいと思いブログを書きました。 拙い文章ですが、よろしくお願いします。 チームビルディングとは LIFULLでは、同じ部署のメンバーで半日〜1日単位で交流の機会を創るチームビルディングという制度があり、半年〜1年に一度各部署で実施します。 内容も各部署内で決定してよく、例えばバーベキューやリアル脱出ゲームといった遊び系から、性格診断を実施してメンバー同士でお互いの隠れた一面を知るといった真面目なものまで様々です。 「浅草BINGO鬼ごっこ」とは さて、ここでチームビルディングのネタとして決定した「浅草BINGO鬼ごっこ」のルールを解説します。 3チームに分かれる鬼ごっこです 。鬼は交代制で常に1チームが鬼になります 全チームに、 浅草の名所が各マスに書かれたBINGOカード が配られます ヒトチーム（逃げるチーム）はマスに書かれた名所に訪れその 写真を他のチームにシェアすることで、BINGOのマスを開ける ことができます 鬼チーム（追うチーム）は BINGOのマスを開けれません 。シェアされた写真をヒントに、ヒトチームを発見すると、鬼を交代できます ゲーム終了時点で 最もBINGO数が多いチームの勝利 ！！ 朝11時開始で、昼休憩を挟んで夕方まで実施。そのあとは飲み会です！🍺 簡単に言うと、ヒトチームは「名所の写真」というヒントを鬼に提供しながら逃げ、鬼はそのヒントを頼りにヒトを見つけます。 ヒトチームは逃げている限り、名所を訪れマスを開け続けられるため、勝利に近づきますし、鬼はヒトを捕まえないと勝利が遠のきます。 これが「浅草BINGO鬼ごっこ」です 細かいルール さらにこのゲームを成立させるため、事前に会議を重ね細かいルールを作成していきました。 街中なので、走って移動はしない（当たり前ですが） 鬼がヒトを捕まえる条件は、お互いが認識したら（物理的に捕まえるのはキケン） ヒトチームはBINGOを開けて写真アップロード後、 15分その場に待機しなければならない 鬼とヒトが交代したら、 次の鬼はその場に5分間待機してヒトが逃げる時間を作る その他諸々・・・ BINGO 肝心の浅草の名所が書かれたBINGOはこちらです。 全チーム共通で同じBINGOを持って鬼ごっこに挑みます。 企画の流れ これらの企画は僕を含む部署内の有志で業務時間の合間を縫ってこっそり仕上げました。 ゲーム性も重要ながら、チームビルディングとして大切な 「他のチームメンバーの考えていることを考える」 ということが起きるルールに仕上げていくプロセスは大変面白かったです。 実録「浅草BINGO鬼ごっこ」 スタートダッシュ 某日午前11時、東京メトロ浅草駅にやってきた部署メンバーによる、チームビルディングがスタートしました。 チームは4名のAチーム、Bチーム、Cチームの3チームに分かれて実施しました。 最初の鬼はCチームです。まずはA、B両チームが出発し、その15分後にCチームが出発します。 僕たちAチームは雷門といった浅草駅にほど近い名所を埋めるとすぐ鬼に見つかるので、 「浅草演芸ホール」 まで歩いていき、BINGOを埋めて写真を他チームにシェアしました。 Bチームの方は 「花やしき」 をその1分後にアップロードしました。 ここで両チームとも15分待機になります。 さあ、鬼のCチームはこの15分の間にどちらのチームを見つけに来るのでしょうか・・・？ドキドキ・・・ 新卒K君の戦略 Aチームには今年新卒エンジニアとして入社したK君が居ます。 彼はとにかく戦略を考えるのが得意なようで、BINGOのマス目に懸命にメモを書き込みながら、「最も効率的にBINGOを埋める、かつ移動が効率的にできる順路」を考察していました。 「鬼チームが最初にBチームを見つけた場合は、Aチームは引き続きヒトチームなので次はここに行く」「鬼チームが最初に我々Aチームを見つけた場合は、Bチームが引き続きヒトチームだが、次に行くのはこのへんだろうから、鬼として先回りする」といった分析を始めます。 この辺は新卒の個性が分かって、チームビルディングとして非常に意義深いなあと思った瞬間でした。 衝撃のジェラート ただ、鬼のCチーム、13分経過しても全く姿が見えません。このままだと15分経過し、ヒトのABチームは再び違う名所に移動できます。 そうなるとABチームはCチームに比べ2つ分の穴が空いていないことになり、ゲーム序盤にして大きなハンデを背負うことになります。 一体どうしたのでしょう・・・ そこに、衝撃の写真が私たちにシェアされました。 なんとCチーム、ヒトチームを追いかけずにジェラートを食べているのです。 ゲーム性を追求するAチームとは打って変わって、「チームビルディングでしょ？楽しんで何が悪いの？ゲームは二の次」とばかりにジェラートを楽しむCチーム。 ABチームに衝撃が走る一方、これまたチームメンバーの個性が出て、チームビルディングとしてはある意味良いことが起こったなと思いました笑。 Cチームには同じく新卒のNさんが居るのですが、この展開に困惑していないのだろうか、いやむしろ上手に溶け込みそうだなとかをAチームのメンバー同士で話すのも、他のチームのことを考える切っ掛けになって良かったです。 2枚抜きで忖度 笑っていられないのはむしろヒトチームである我々Aチームです。 こちらは大真面目に戦略を考えているのに、鬼チームがジェラートを食べていては話になりません。 新卒のK君も「このゲームは全チームが勝ちに向かうからこそ面白いルール。こんなことが起きると成立しない！」と息巻いています（僕はその発言を聞いて、さりげなく面白いルールと言ってくれて嬉しいなと呑気なことを考えていましたｗ）。 鬼チームに見つけてもらわなければゲームが動かない。しかし自分たちが見つかるとBチームに対して遅れを取ってしまう。 ここでK君がひねり出した妙案が 「2枚抜き」 です。 先程のBINGOの写真、よく見ると「カレーの自販機でカレーを買って公園で食べる」と「田原公園」というマスがあります。 つまり、「カレーの自販機でカレーを買って”田原公園”で食べ」ながら、その写真を他チームにシェアすれば、マスを2つ同時に開けれるのではないか！？ ということにK君が気づきました（もちろん、2枚抜きがこの2マスにおいて可能なことは企画時に織り込み済みですが、こんな早期に気づかれるとは嬉しい誤算でした）。 ポイントは、2枚抜きをすると、その場に待機する時間が15分×2で30分になることです。 30分もあれば、Cチームがさすがに我々のチームをを見つけることができ、鬼が交代になってゲームが動くだろうと。 かつ、2枚抜きをしているのでBチームに対して大きく遅れを取るわけではありません。ゲームを動かすために忖度はしますが決して負けないぞというスタンスです笑 以上から、Aチームは 2枚抜きすることで鬼にあえて捕まる 、という作戦を実行しました。 道中でカレーの自販機に立ち寄ってカレーを買いながら、浅草南部の田原公園に移動し、写真を撮影しました。 初の鬼交代 田原公園で30分も待つことになったAチームは、コンビニでアイスを買ってきて食べながら雑談して木陰でゆったりとした時間を過ごしていました。 ここまで煽ればさすがに来てくれるだろうと思いつつ、例えばBチームを捕まえに行ったり、また寄り道をされてしまえば、この作戦は無駄になってしまいます。 そのとき・・・！ ついに、Cチームと巡り会うことができました！初の鬼交代です。時既に12時18分。実に開始1時間以上経過して初の交代となりました。 その後 さて、ここまででどのようなゲームか何となくご理解いただけたのではないでしょうか。このあとも熱戦が続きましたが、詳細は割愛させていただきます！ 優勝したのは2枚抜きの勢いそのままに3BINGOを達成した、戦略家の新卒Kくんを擁するAチームでした！ まとめ 良かったところ チームメンバーの考え方はもちろん、他チームのことも読み合いになりお互いの考え方を知れる 浅草自体が、道も入り組んでいる一方名所が多いなど、今回のゲーム特性に適していた ヒトがBINGOを開けたら15分待機の時間設定がちょうどよかった 新卒一年目も参加しやすい 終わった後の飲み会で、他チームの話を聞くのが楽しい デザイナーのOさんが素敵なしおりを作ってくださり、気分をアゲて取り組めた 改善点 夏に実施したため暑すぎた。春か秋が望ましいと思います 人気のないスポットを書いたマス目が最後まで埋まらなかったこと 改善点はあるものの、観光を楽しみながら、他チームのことを知れてゲームとしても面白い「BINGO鬼ごっこ」、ぜひチームビルディングで採用してみてはいかがでしょうか！ 読んで頂きありがとうございました。

こんにちは！LIFULLのPythonエンジニアの二宮です。 先日 PyCon JP 2018 が開催され、弊社もSilver Sponsorとして参加させて頂きました。私個人としては、PyCon JP 2018のボランティアスタッフとしても活動していました。 LIFULL社内ではPHPやRubyでの開発が多いのですが、 プライスマップ の価格推定システムや、 物件画像のカテゴリー分類 などの機械学習を使ったシステムを中心にPythonを利用しています。 PyCon JP 2018とは PyCon JP 2018はご存じの通りプログラミング言語Pythonのカンファレンスで、他の言語のカンファレンスに比べ、 統計・機械学習やWEBアプリケーション等、幅広い用途で利用されているPythonならではのトークが聞けるのが特色だと思います。 実は私自身は、自社がスポンサーになったことと知り合いから誘われたのがきっかけで、今年からPyCon JPの事務局チームとして、各企業スポンサーやメディアとの連絡や、17日ランチタイムのジョブフェアを担当しました。 （自社のブログに書くのも少し変ですが、）スポンサー企業やメディアご担当の方々、スタッフの皆様、ジョブフェアのモデレーターを引き受けてくださったScalaMatsuri座長の麻植さん、改めてありがとうございました。 当日のトーク発表について 私自身は、特に招待講演の中山浩太郎さんの『 東大松尾研流 実践的AI人材育成法 』と、 大元司さんの『 niconicoにおけるコンテンツレコメンドの取り組み 』を 楽しみにしていたのですが、当日はちょうどその時間にスタッフ作業が入ってしまって聞けませんでした。 ちなみに大元さんには、スタッフとして PyCon JP 2018の登壇者座談会 でも取材させていただいています。他の方々も含め、日々の勉強やコミュニティ活動について学ばせて頂きました。 当日は、メディアスポンサーに寄稿する記事の取材（実際に参加したトークについては、各メディアで公開される記事を執筆中ですのでそちらをお楽しみに！）や、設営や片付け等で人手が必要な時間も多く大変でしたが、普段参加しているカンファレンスの、スタッフ側の工夫や努力を知ることができたのも貴重な経験でした。 残念ながら見逃してしまったものについては、YouTubeの PyCon JP公式アカウント で公開されているので、少しづつ見ていこうと思います。 今年はトークの発表者側にLIFULL社員がいなかったので悔しいですね。これを読んでいるLIFULL社員はPyCon JP 2019でトークのプロポーザルを出しましょう！もちろん私自身もチャレンジします💪 当日の会場の様子 トーク以外の話でいうと、お弁当やパーティーのメニューにビーガンやハラール向けのものがあったり、日本語の他に英語でもやり取りがあったり、海外の方や多様な参加者への配慮がなされていたのも印象的でした。 スタッフ活動でも、国内・海外問わず何度か登壇者や参加者とやり取りする機会があり、その度にちょっと緊張してしまいました。 Pythonのロゴをあしらったお菓子に長蛇の列が生まれていましたね。お菓子を食べながら、参加者同士に自然とコミュニケーションが生まれるような工夫もあったように思います。 当日のブースやオープニング・クロージングも印象的だったんですが、こちらも各メディアで公開される記事をメンバーで執筆中なので、そちらを楽しみにしてください🙇 さいごに 株式会社LIFULLでは、Pythonを使って不動産やWEBのデータを分析・開発したい機械学習エンジニア・データサイエンティストや、技術コミュニティに貢献したいエンジニアも募集しています。一緒に働きましょう！ hrmos.co 私自身もデータサイエンティストな感じを出していますが、普段はPythonやRubyでアプリケーション開発しております。LIFULL社内のエンジニアの普段の様子は LTech などの勉強会でご紹介しておりますので、ぜひ遊びに来てください！

こんにちは。 この時期になるとイベントへの参加意欲が高まる、人事の水村です。 先日builderscon tokyo 2018が開催されたのですが、LIFULLもスポンサーとして参加させていただきました。 　　　 　　 builderscon tokyo とは 「知らなかった、を聞く」 をテーマとした技術を愛する全てのギーク達のお祭りです。（引用：builderscon tokyo コーポレートより） 9/7(金) 弊社ホームズくんと参加してきましたので、レポートします！ 　　　　　　　 　　　　　　 受付 青Tシャツを着たbuilderscon tokyo 2018運営スタッフの皆さんにやさしく誘導いただき、迷うことなく受付へ到着。 ノベルティの入ったエコバッグとbuilderscon tokyo 2018オリジナルTシャツをいただけます。 名前とTwitterアイコンを印刷してもらった名札を受け取り、いざオープニングセッションへ向かいます。 　　　　　　　　　 　　　　　　　　 　　　　　　　　 オープニングセッション開始！ 「今年は私は喋りません！」という事前コメントがbuilderscon主宰の牧さんからあったため、何が起きるのか緊張しながら待っていたところ。。。 突然おしゃれなムービーが始まりました！ 会場の空気が徐々に温まっていくのを感じます。 良い空気になったころムービーが終わり、満を持して主宰の牧さんがご登場！ 今年は語りたくなかったのでムービーを用意しました、というおちゃめなつかみで builderscon tokyo 2018 がスタートしました。 　　 　　　 平日金曜日にも関わらず会場はほぼ満席、その後のセッション「 Envoy internals deep dive 」も、その後の サイボウズさん ランチセッション もほぼ満員でした。 来年参加される方は、各回早めに会場に行かれることをおすすめします！ 　　 セッション　　 私は、GUEST SPEAKERのお一人で、EnvoyのアーキテクトのMatt Kleinさんのセッションを拝聴させてもらいました。 「Envoy」とは、マイクロサービスを運用していく上で発生するネットワーク課題を解決するOSSのソフトウェアだそうです。 プログラミング言語・バージョン・フレームワークがバラバラな各サービスをつなぐ複雑なネットワークに対して、あらゆる言語・アプリケーションに対応し、監視運用の複雑性を解消するようにつくられたそうです。 弊社でもマイクロサービス化を進めているため、とても興味のある内容でした。 講演・質疑応答は英語で行われたのですが、親切なことに運営の方々が自動翻訳機を貸してくださっていました。 さらに嬉しいことに、登壇者のMattさんご本人がとても丁寧な英語で話してくださっていたので、翻訳機なしでも概要をつかむことができました。 しかし「ネットワークインフラストラクチャ」についての講演は知識のない私にとってハードルが高く、時間いっぱい調べながら必死に参加させてもらいました。 　　　　　 　　　　　　　 　　　　　　　 スポンサー buildersconには、５つのセッション会場があるのですが、そこでは各セッションの幕間でスポンサーCMを見ることができます。 弊社もサービス関連CMを流させていただいたのですが、各社それぞれの色が出たCMを見ることができとても楽しめました。 弊社CMは、不動産・住宅情報サービス「LIFULL HOME'S」ほか、開発提供しているサービスを皆さんに知っていただけたらと思い、用意しました。 個人的に印象に残ったのは、物語の中でさりげなく自社ノベルティを紹介されていた他社様のCM。 思わずノベルティのある会場に走りました。🏃🏽 　　　 　　　 　　　　　　　　 スポンサー各社それぞれの形で builderscon tokyo を盛り上げられていました。 私が見ることができたのは一部でしたが、CMのほか フォトブース や ランチセッション も盛り上がっていました。 ※フォトブースで撮影されたものは、 buildersconのinstagram で自動アップされています。 　　　　　　　　　　　　　　　 　　　　　　　　　　　　　 　　　　　　　　　　 　　　　　　　　　　　　　　　　　 builderscon運営チーム の皆さま スピーカー＆スポンサーの皆さま 楽しい時間をありがとうございました！！ 来年のbuilderscon tokyoは、今年の振返りを踏まえ また盛り上げられるよう、ネタをもって参加させていただけたらいいなと思います。

こんにちは！Ltech運営チームの引持(ひきもち)です。 本日は９月の初めに弊社にて開催させていただきました「Ltech#2 meetup 〜オフショア開発現場のリアル〜」の模様をお伝えします！ Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。 特定の技術に偏らず、様々な技術の話を展開しています。 Ltech#2 meetup 〜オフショア開発現場のリアル〜 Ltech #2はオフショア開発についてパネルディスカッション形式で行いました。 今回はLtechとして初めて外部からゲスト（株式会社モンスター・ラボ 浅子様、株式会社じげん 横山様、株式会社オルトプラス 三ヶ尻様）をお招きして開催させていただきました。 パネルディスカッションの様子 タイトルの通り、オフショア開発現場の「リアル」を熱く語っていただきました！ 色々な議題で語っていただきましたが、その中からいくつか紹介させていただきます。 オフショアに向いている施策・向いていない施策 オフショア開発をやりやすいチーム体制とは 日本のエンジニアの関わり方 オフショア開発での品質の担保の仕方 etc. 普段聞けないようなオフショア開発の深い部分まで聞くことができ、とても勉強になりました。 また、ご参加いただいた方からも質問が飛び交いとても活発な会になりました。 （写真左より）株式会社モンスター・ラボ 浅子様、株式会社じげん 横山様、株式会社オルトプラス 三ヶ尻様、弊社 アーキテクトG 冨田、LIFULL TECH VIETNAM Co., Ltd 藤田 懇親会の様子 Ltech名物である「からあげ」を今回もご用意させて頂きました。 からあげの食べ比べが大変好評で、非常に盛り上がっていました。 オフショア、マネジメントに対する関心が高い方が多く、パネラーを中心に活発な議論が行われていました。 最後に 今後も引き続きLtechを開催していきます！ そして引き続きからあげもご用意させていただきますので、ぜひぜひご参加下さい！ 気になった方はconnpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは！ LIFULL HOME'S事業本部 技術開発部の小賀野と申します。 普段フロントエンドやBFFなどの開発を行っているエンジニアです。 さて、今年もiOSエンジニアにとっての一大イベントの1つであるiOSDC Japan 2018が開催されました。 LIFULLは、昨年のドリンクスポンサーに引き続き、 今年はゴールドスポンサー＋前夜祭＆LT大会ビアスポンサーとして協力させていただきました。また、今年はなんとLIFULLから2人が登壇いたしました！ 8/30(木)〜9/2(日)に開催されたiOSDC Japan 2018に参加してきましたので、 一部ではありますがその様子をお届けしたいと思います！ iOSDC Japanとは iOSDC Japanは、2年前より開催されているiOS関連技術をコアのテーマとした技術者のためのカンファレンスです。今年で3回目の開催になるそうですね！ 参加者はiOSエンジニアがほとんどではありますが、「iOSエンジニアに聞いて欲しいトーク」という枠が設けられるなど、iOSエンジニア以外の方々も登壇されています。 内容としては、アーキテクチャの話題や最新のiOS技術の話題など多種多様で、 今年は昨年よりも1日長い開催期間となり、とても多くのトークが行われておりました。 その中でも私が特に注目したトークを少しご紹介したいと思います！ iOSとgRPC Googleの開発したRPC(Remote Procedure Call)フレームワークであるgRPCですが、今年のiOSDCではこのgRPCに関するトークが多くありました。 iOSエンジニアの為のgrpc-swift入門 @tikidunpon このトークでは、gRPCやProtocol Buffersを使用するメリット、実際にSwiftのコードを生成するための方法について紹介されていました。 特に、iOSエンジニアとしてはOptionalの扱いについてが気になるところですね。 gRPCを使用することで、クライアントのコードを自動生成することができるので、APIの仕様と実装の乖離を減らすことができる grpc-swift では、ブロッキングなものとノンブロッキングなものの両方のSwiftのコードを生成できる Protocol Buffersにより、JSONに比べてペイロードサイズを削減できる oneof を使用することでSwiftのOptionalを表現することは可能であるが、他の言語で使用できない可能性を考えるとあまり得策ではない speakerdeck.com grpc-swiftを使ってiOSアプリでも快適なgRPC通信を行う @KyoheiG3 このトークでは、gPRCによるクライアント実装だけでなく、サーバ実装の話までがされていました。また、実際にgrpc-swiftを使用した上でのクライアント側でのつらみを紹介し、そのつらみを解消するために自分たちで作成したライブラリの紹介もされていました。Unaryについてだけではなく、Bi-Directional Streamingなどの他の通信方式についてもサンプルを交えながらわかりやすく説明されています。 grpc-swiftでは、timeoutをリクエスト個別に設定することはできないが、登壇者の作成した grpc-swift-client を使用することで、リクエスト単位にtimeoutを設定することができるようになる HTTP/1.1しか使用できない環境ではgRPCを使用することはできないが、Protocol Buffersのみの使用でも通信容量の削減などメリットはある とはいえバイナリベースなので、 Charles などでエラー時のデバッグを行いにくいのが少しネック speakerdeck.com まだiOSアプリでgRPCを本番環境で運用している企業はそれほどいないようでした。ただ、gRPC関連のトーク数や会場でのトークの観覧者数を見る限りでは、今後検討してみたい・使用してみたいという企業が多いのではないでしょうか。 差分更新 今年はTableViewの差分更新関連の話が多くありました。差分更新ライブラリの内部的なアルゴリズムの話やチューニング方法の話などがありました。 差分アルゴリズムの原理について @horita_yuya このトークでは、TableViewやCollectionViewの差分更新用ライブラリに採用されているアルゴリズムの中でも特に優位性の高い「Myers Algorithm」・「Paul Heckel Algorithm」について紹介されていました。それぞれの差分更新アルゴリズムの詳細な方法から計算量がどれほどになるかまで触れられていました。 Myers Algorithmの計算量はO(ND) Paul Heckel Algorithmは、 DifferenceKit や RxDataSources に使用されている差分更新アルゴリズム、計算量はO(N) 計算量がO(N 2 )であるアルゴリズムを採用するライブラリも存在するが、パフォーマンスをとるか機能面をとるかしっかりと考えて検討すべき 現在、差分更新系のライブラリでは、機能面・パフォーマンス面をとっても DifferenceKit 一択なのではないか speakerdeck.com 5000行のUITableViewを差分更新する @banjun このトークでは、差分更新の方法だけでなくXcodeのInstrumentsを利用したパフォーマンスチューニングの方法まで紹介されていました。私もInstrumentsを利用したチューニングを行ったことがありますが、各メソッドの実行時間が細かく見れるため、ボトルネックとなっている箇所を特定しやすいので非常に便利ですね。 XcodeのInstrumentsのTime Profilerを使うことで実行アプリのCPU負荷のグラフやスタックトレースの各段ごとの実行時間が確認でき、ボトルネックになっている部分を特定しやすい RandomAccessControllを使おう Genericsを除去しよう speakerdeck.com 普段何気なく使用するライブラリには様々なアルゴリズムが使われており、もちろんすべてのアルゴリズムには計算量がつきものです。実装上の使い勝手や機能面だけではなく、より良いパフォーマンスを出すためにも使用するライブラリがどんなアルゴリズムで実装されているのかを把握することも選定の基準の一つであるということですね。今回の差分更新の話のような内部実装を理解できるトークは非常に貴重でした。 iOSエンジニアに聞いて欲しいトーク iOSエンジニア以外の方から見たiOS技術についての話をするトークがいくつかありました。普段主にWebの開発を行っている私が特に注目していた内容です。登壇されている方はほとんどがWebフロントエンジニアの方のようでした。 フロントエンドエンジニアからみたiOS開発 @ohayou_kenchan このトークでは、iOS技術とWebフロントエンド技術の似ているところについての比較を交えつつ、iOSエンジニアもWebの開発ができるのではないかという話をされていました。私は、iOSの開発もフロントエンドの開発もしたことがあるため、改めて聞いてみると確かに似ているところもあるなと共感するところがありました。個人的には、Swiftでいうprotocolのデフォルト実装がTypeScriptではやりづらいこともあり、Swiftのほうが書きやすい印象がありますね。 viewが表示される直前の処理や直後の処理など、iOSにおけるUIViewControllerのライフサイクルとReactやVueにおけるライフサイクルは似ているものが多く、メソッドをフックしたときの処理がイメージしやすい(Swiftでいう viewDidAppear とVueでいう mounted など) SwiftとTypeScriptが似ている Swiftにおける let と var は、TypeScriptにおける const と let に対応している 他にもTypeScriptには、Type(TypeAnnotation)やinterface、any型などSwiftと似ている部分が多い speakerdeck.com iOSエンジニアが知るべきProgressive Web Apps開発のエッセンス @laiso このトークでは、PWAとiOSとの関係性についての話からiOSエンジニアがWebアプリに注目しておいたほうがいい理由について紹介されていました。SafariがService WorkerをサポートしたということでPWAが再び話題になりましたが、その実態についての話もされていました。 Appleが公式にPWAに対応したという話はなく、あくまでService WorkerにSafariが対応したいうだけの話であって、PWAすべてに対応したと内容が拡大解釈されてしまっていた PWAによりiOSで初めてWebアプリをホーム画面に追加できるとの記事もたまにあるが、ホーム画面への追加だけならiOS2のころのSafariの機能で昔からできた SafariにはiOS/macOSに密結合した機能が多いため、PWAをiOSで使用するには他のベンダーブラウザをデフォルトにできない SwiftやOSSライブラリのエコシステムに参加することで、iOSもより早い速度で進化していくことができるのではないか 特にServer-side swiftはまだまだコントリビュートする余地がある speakerdeck.com 昨年はKotlinをAndroid開発言語に選定したというGoogleからの発表もあり、SwiftとKotlinというようなiOSとAndroidの関係性の話が多くされていましたが、今年はWebとネイティブアプリの関係性についての話が多く、参加者の興味・関心もよりあったような印象でした。 かざして検索 LIFULL HOME'S「かざして検索」リリースの裏側 @HanawaTakuro LIFULLからも塙が「LIFULL HOME'S「かざして検索」リリースの裏側 」というタイトルで登壇いたしました。「かざして検索」は、建物をかざすだけでその建物の物件情報を閲覧できる今年の5月にリリースされたLIFULL HOME'Sアプリの新機能となります。こちらのプロジェクトにおいて、実際に物体検出をするためにCoreMLやVisionフレームワークをどのように使用したか・工夫したかなどについて紹介されています。かなり濃い内容となっていますのでぜひスライドをご覧ください！ LIFULL HOME'S「かざして検索」リリースの裏側 from Takuro Hanawa www.slideshare.net また、「かざして検索」も非常におもしろいアプリ体験となっていますので、こちらもぜひ使ってみてください！ lifull.com その他トーク その他、ここでは紹介しきれなかったおもしろいトークがありましたので記載いたします。 Swiftにコルーチンをもたらすための話 Swiftの生みの親によるasync/await for Swiftを徹底解説し、新しい非同期処理の手法を理解する @yimajo iOS周りの技術の総まとめ State of the Union ~2018年のアプリ開発事情~ @huin イベントの様子 毎年iOSDCでは多くの企業ブースが設けられたり、ランチやドリンクが提供されたりと、トーク以外でも参加者が楽しめる内容となっておりますので、その一部の様子をご紹介いたします。 ブース iOSDCでは毎年多くの企業がブースを出しています。 ブースではiOSにまつわるアンケートやちょっとしたゲームのようなものが行われており、立ち寄るとノベルティがもらえたりなんかします。 いくつかのブースでは昨年に引き続き、iOSの開発手法にまつわるアンケートが行われていました。CyberAgentさんでは、アーキテクチャはMVCやMVVM・Clean Architectureのどれなのか、UIはSyoryboardで管理するのかコードで管理するのかなどの内容がありました。 DeNAさんは少し細かな内容で、Optionalのアンラップ時は変数を同じにするかしないかなど個々人で記述にズレがでそうなものと、とても興味のある内容となっていました。 ちなみに私は、アーキテクチャはMVVM、UIはコードベース、Optionalのアンラップ時に変数名は変えない派です。 ルーキーズLT 毎年恒例の夕方より行われるLT大会では、ビールや酎ハイなどが振る舞われ、お酒を飲みながら参加することができます。同じく前夜祭でもお酒を飲みながら参加することができたのですが、前夜祭・LT大会ともにLIFULLがスポンサーとしてビールを提供させていただきました。お酒があるとまた雰囲気が変わっていいですね。 また、こちらのLT大会は今年からはルーキーズLTという位置付けで、登壇経験があまりない方々が気軽に登壇できるように配慮されたものでした。 LIFULLからは又来が「ARKit2.0でAppleが伝えたいアプリ体験を考える」というタイトルで登壇いたしました。今年の秋にリリースされるiOS12から使用できるARKitの新機能でどんなアプリ体験を提供すべきかについて紹介しています。最新のiOS12についてやARKitについて興味のある方はぜひスライドをご覧ください！ ARKit2.0でAppleが伝えたいアプリ体験を考える - Speaker Deck ランチ 参加者が無料でいただけるランチです。3種類の中から選ぶことができ、今年は昨年に比べ、より満足のいく内容となっていました。今年はどうやら会場で作っていたようですね。 懇親会 懇親会は毎年多くの方が参加され、チケットも争奪戦となっています。 お酒はクラフトビールから日本酒まで、料理もオードブルだけでなく、ハンバーガーやケバブなどたくさんの種類が提供されていました。 運営の方々が工夫されていることもあり、初めての方でも気軽に会話に参加することができます。iOS関連の話などで非常に賑わっておりました。 まとめ 開催が3回目ということもあり、iOSを始めたばかりの方からベテランの方までの多くの人が参加され、トーク内容も多種多様でした。特に今年から開催されたルーキーズLTでは、昨年iOSDCに参加された方の中で「来年こそは自分も登壇したい！」と思っている方々が多く登壇されているとのことでした。なかなかカンファレンスという場にいきなり立つのは。。という方も多いと思うので、このように敷居を下げてくださるのは非常にありがたいですね！より一層のiOSコミュニティの盛り上がりが感じられる、非常に有意義なカンファレンスでした！ 最後になりますが、LIFULLではネイティブアプリ好きなエンジニアやWeb好きなエンジニア、カンファレンス好きなエンジニアの方を募集しています。 ご応募お待ちしています！ hrmos.co

こんにちは！ Ltech運営チームの比下(ヒゲ)です。 本日は、6月に弊社にて開催した技術勉強会「Ltech #0 RubyKaigi2018報告会」と 7月に開催した「Ltech #1 LIFULL HOME'S 機械学習Night」の模様についてレポートいたします！ Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。 特定の技術に偏らず、様々な技術の話を展開していく予定です。 Ltech #0 RubyKaigi2018報告会 Ltech第一弾として、RubyKaigi2018に参加した弊社社員による報告会を開催しました。 急遽開催したため告知期間が短く、参加者が少なかったため、少し寂しい感じではありますが、勉強会後の懇親会は非常に盛り上がっていました！ 勉強会の様子 セッションの中で気になった点を中心に、当日の会場の様子など、 現地でしか感じられない雰囲気についても話が行われました。 当日の資料は、connpassのイベント詳細ページよりご覧いただくことができますので、 気になった方はぜひご覧ください。 lifull.connpass.com 懇親会の様子 懇親会はお酒やおつまみを食べながら、和気あいあいとした雰囲気で行われ、 あっという間に時間が過ぎ、参加者はまだ話し足りていない様子でした。 途中、弊社社員によるLTも実施しています。 写真はLTを聞いている様子です。 Ltech #1 LIFULL HOME'S 機械学習Night 弊社での機械学習の活用事例を紹介する本イベントは、大変ご好評をいただき、イベントを告知してからすぐに満席近い参加者登録がありました。 2度の増枠を行いまいたが、おかげさまですぐに満席となりました！ 多くの方にご参加いただき本当にうれしいです。 勉強会の様子 LIFULL HOME'Sでの活用事例として、「広告費最適化」「画像判別」「サーバの負荷予測・異常検知」についてお話させていただきました。 質疑応答では、サーバ構成や開発期間など突っ込んだ質問も多く行われ、機械学習への関心の高さがうかがえました。 当日の資料の一部を公開していますので、こちらも気になった方はぜひご覧ください。 lifull.connpass.com 懇親会の様子 勉強会後の懇親会では、いろいろなお店の唐揚げをご用意いたしました。 物珍しさに写真をSNSにUPしていただくなど、こちらも非常に盛り上がっていたと思います。 開催予告：Ltech#2 meetup 〜オフショア開発現場のリアル〜 2018/9/4(火)に「オフショア開発」をテーマにパネルディスカッション形式でお話いたします。 今回はなんと、オルトプラスさん・じげんさん ・モンスター・ラボさんからゲストをお迎えして、 オフショア開発現場のリアルを余すことなくお話していただきます！ すでにオフショアを経験されている方から、これから検討するかもという方まで、「オフショア開発」というキーワードにピンときたエンジニアで集まり情報共有しましょう！ イベントの詳細と参加登録はconnpassからお願いします！ lifull.connpass.com 当日は、勉強会の後に懇親会も予定しています。 LIFULL社員と話してみたい、とりあえずLIFULLに行ってみたいという方も、ぜひお気軽にご参加ください。 最後に 今後もLtechを積極的に開催していきますので、 ぜひ気になった方はconnpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは、LIFULLでデザイナーをしております池上あかねです。 本日は、8/7（火）に弊社にて開催された、LIFULLのデザイナーが主催する勉強会＆交流会「デザイナーの放課後」第3回の模様についてレポートいたします！ デザイナーの放課後とは 「デザイナーの放課後」は、LIFULL社内で開催されていたデザイナー・フロントエンドエンジニアがお互いのナレッジを共有し合う会を母体に、「LIFULLを外部の方に向けて発信し、来ていただいた方にも交流の場となるように」という思いをこめて立ち上げられたイベントです。おかげさまでこのイベントも第3回目の開催となりました！（パチパチ） いままでの開催レポートはこちら 「デザイナーの放課後 #1 サービスを成長させるデザイナーとは？」開催レポート！ - LIFULL Creators Blog 「デザイナーの放課後 #2 ユーザーを魅了し続けるためにデザイナーがしていること」開催レポート！ - LIFULL Creators Blog ＃３「デザイナーが語る『ブランディング』の現場」 第3回目の開催テーマは 「デザイナーが語る『ブランディング』の現場」 です。 LIFULLは「あらゆるLIFEを、FULLに。」をビジョンに掲げ、 本社移転・社名変更などのリブランディングをおこなってから２０１８年４月で１周年を迎えました。 LIFULL FLOWERをはじめとする様々な新規事業において、 これまで以上にデザイナーが「ブランディング」に携わる機会が増えてきているため、 外部の方のお話を聞きながら、あらためて考えてみる機会としてはどうかという流れから、 このテーマを取り上げることになりました。司会は新卒２年目であるLIFULLのデザイナー、木下香菜が務めました。 デザイナーが携わる領域の中でも事業全体や自社製品の核となる「ブランド」をつくっていく、 そんなとても大きなテーマですが、 ChatWork株式会社さんと株式会社サイバーエージェントさんを迎えてお話をしていただきました！ デザインによる付加価値の乗算。新規事業「LIFULL FLOWER」リブランディング まずはLIFULLのシニアデザイナー　田中忍から、 新規事業のLIFULL FLOWERについて１からブランドをどう立ち上げたか、 どのようにブランディングに携わっているかについて話してもらいました。 「開けた瞬間花瓶になる、旬の定期便」 LIFULL FLOWERは２０１８年２月にスタートした、お花のサブスクリプション（定額制）サービスです。 毎月、自宅や職場など指定した場所に季節を感じられる違う種類のお花が届き、パッケージを開けたらそのまま飾ることができて、水換えも不要でお花を楽しむことができます。 事業の発端は、生花の流通の問題を解決することから始まりました。 事業立案者が花農家の出身で、「なんとか生花業界の問題を解決したい」というところから、 まずは生花の流通モデルを再構築し、WEB発注・サブスクリプションで流通するサービスとしてスタートさせました。 しかし、これだけで果たしてユーザーにとっての価値になっているのでしょうか。 業界課題を解決できるビジネスモデルを、さらに消費者にとって価値のあるものにしたい。そのためにリブランディングを行うことになりました。 どのようにリブランディングをしているか 一番重要なのは、 「ターゲットとビジネスモデルを掛け算すること。ターゲットが最もうれしいものを探し、強いコンセプトをたてること」 と、田中は語ります。 LIFULL FLOWERのリブランディングは「FAST＆FRESH」というコンセプトを打ち立てるところから始まっています。 まず、お花を楽しむ習慣のない人にターゲットを絞り、その人たちがお花を買わない理由のなかにあった「面倒くさい」という言葉に着目。 次に、WEB上で注文したら花が届く手軽さを「FAST」、市場から鮮度が保たれている花が毎月直送されてくる側面を「FRESH」という言葉に変換し、「FAST&FRESH」という全体を通貫するコンセプトとして明確に定め、このコンセプトを元にプロモーションや商品のパッケージなどをデザイン。最後に、ユーザーの利点を「STYLISH／EASY／SMART」に分解、「FAST&FRESH」と合わせて4点の訴求点に整理し、コミュニケーションに落としたそうです。 デザイナーの役割 普通の人の感覚を持ち、普通の人が自分たちのビジネスをどういう風に思うかを意識して、デザインに落としていくこと。それが「ブランド」になっていく。いいデザイン・いいブランドを作るために、たくさんスケッチをして、たくさん出し惜しみをせずにアイディアを出していくことが、ブランディングにおけるデザイナーの役割として大事だ、と田中は結びました。 この「出し惜しみをせずに」というのが日々の業務の中でもなかなか難しいなと感じてしまうのですが、LTの中でも「これはコンセプトからブレるのでボツになりました」とボツになったアイディアも紹介されていたり、１からブランディングを考えるうえでのポイントだけでなく、デザイナーが携わっていくあらゆることへのヒントがたくさん詰まったLTでした。 ChatWorkという組織をデザインする部署の仕事 続いて、ChatWork株式会社のデザイナー　守谷絵美さんから、組織文化のブランディングという視点と組織が大きくなっていくなかで文化の共有をどのようにしているかについてお話しいただきました。 ChatWorkについて ChatWorkは、チャットで仕事ができるビジネスコミュニケーションツールとして、世界中で185,000社（※イベント開催時点）が導入しているサービスです。 自社で培った働き方のノウハウをプロダクトに反映していこう、ということがサービスの始まりでした。 守谷さんが所属するデザイン部は、プロダクトのUIデザインをはじめとした会社全体の様々なデザイン領域に携わっているそうです。 事業＝会社という形で、今までは組織も少数精鋭で１社につき１クラス分という人数でやってきており、一人の社長が目に届く人数におさまっていました。 小さい組織の時は組織の体制・雰囲気がそのままブランドとして現れてくるので、自然と全員が同じ認識をもっていることができました。 しかし、事業拡大に伴って開発体制の強化を進めており、これからどんどん組織が拡大していくことを見越していくと、今度は新しく入ってくる人にはその雰囲気がわからなかったりします。 「ChatWorkでは唯一、デザイン部が社内のすべての部署・職域にはたらきかけることができる部署なので、今度は、社内の人たちにどうやってブランドを共有していくかがデザイナーの役割になっていきました。」と守谷さん。 組織とチームの拡大に向けて 組織の文化を反映したり継承した概念を全社に伝えていくにあたって、特にチームビルディングの重要性が大きく関わっているそうです。 チームビルディングを通じて、まず心理的安全性を構築したうえで、全社にサブリミナル効果でデザイン思想やミッションを伝播させていく。 そうすることで、新しく入ってきた人にも、他部署から外部のデザイナーさんに依頼する仕事に対しても、明文化された内容がより伝わりやすくなり、組織とチームの拡大にもブレないように対応していくことができるということでした。 会社をブランディングしていくこと 他にも、デザイナーが組織やチームの規模にあわせて会社の動きを変えていった例として、 移転された社屋ではデザイナーからリノベーションの企画を持ち込み、オフィスを「社内の文化に基づいたデザイン」にするためのデザインプロジェクトが始まったそうです。 コミュニケーションの場所として、みんなが社内で気軽に飲み会などいろんな集まりができるようにとバーカウンターを設置したり、社内に部活があるほど映画好きなメンバーが多いことから一番広い会議室をシアタールームとして使えるようにしてしまうなど、オフィスに社内の文化が現れるよう自分たちの手でもDIYしてつくりあげていったそうです。なんと、オフィスデザインの際にはLIFULLの社屋も参考にしていただいたそうです、ありがとうございます！ 週に１回みんなでランチをして雑談したり、堅苦しい部署定例でもおやつを持ち込んでわいわいやってみるとか、 コミュニケーションがしやすい環境づくりというのを、デザイナーが主体となってつくっている ことに驚きました。 もちろんチャットで「このデザインどうかな？」など気軽に相談もできたり、心理的安全性のある組織になっていることが、ChatWorkさんの社内の風通しの良さ、雰囲気の良さに繋がっているのだなというのが伝わってくるLTでした。写真で紹介されたオフィスが素敵だったので、ぜひ遊びにいってみたいです！ ［　　　］なマスメディアを目指す。AbemaTVのブランディングとデザイン 最後に、株式会社サイバーエージェントのアートディレクター　前澤拓馬さんから、AbemaTVをどのように知ってもらいブランドを育てていくかについてお話しいただきました。 AbemaTVはまだ２歳半 AbemaTVの大きな目標として「マスメディアをつくる」。 そのために、今回のタイトルにある［　　　］の部分に入る言葉が強みや得意分野になって、「ブランド」と言えるものになってくるのですが、AbemaTVはそれが「まだない」状態。 AbemaTVはサービスを開始して年齢にしたら２歳半。 マスメディアになるという大きな目標に向けて、まだ特定のものに絞りきらず、AbemaTVの強みになる可能性があるものをどんどん試して広げて行っているところとのこと。 どのようにブランディングをするか 一般的なブランディングのステップとしては 知ってもらう 好きになってもらう 信頼してもらう が基本であり「３つ目のステップまできて、はじめてブランディングとして成功しているんじゃないかと思っています。」と、前澤さん。 知ってもらうという認知のところでは、まず自分が何者か知ってもらう必要があり、そのあとにどういうサービスか、AbemaTVの場合はインターネットTVである、無料であるというポイントが重要になります。 そのため、はじめに出した広告では情報を最小限に「Abemaくん」「無料で楽しめるインターネットテレビ局」というシンプルな内容で打ち出し、街のあちこちで展開していきました。 その後にタレントさんを起用した広告を出し、サービスにメジャー感を印象づけていったそうです。 少し変化球のような事例では新聞の折り込み広告も出していて、AbemaTVで実際に放映する番組をテレビ欄形式で表現したクリエイティブの広告にすることで、手にとった方に「なんだこれ、いつものTVとは違うのかな？」というインパクトを与えることができたということでした。 コンテンツの良さを伝え、育てていく 知ってもらうことができてくると、今度はアピールするだけではなく「コンテンツの良さを伝える」ことに集中する方にシフトしていきます。 AbemaTVは従来のTVっぽいイメージのアートワークとは異なる、AbemaTVらしいビジュアル作りに注力しています。また、様々な番組を企画する中で「恋愛リアリティショー」のような人気ジャンルが生まれています。現在は、曜日や時間によって番組をグルーピングしていく、というような番組のコンテンツを印象づけするための流れを作ることもしているそうです。 「『ブランディング』というのは、成熟した企業やサービスにおいてはサービスが持つ要素の見え方自体がブランディングというか、どういう企業やサービスにしたいかによって見え方が変わってきますが、AbemaTVの場合、それぞれの要素がまだ小さい状態。なので、 その中で強みになる要素を見つけ、大きく育てることがブランディング になってきます。なので、あらかじめどういう形にするかを決めすぎず、可能性があるものをどんどん伸ばしていく。それが自然と面白い形になっていったりっていうのがあるので、そこを育て、強みを作っていく、というのが我々のミッションであり、考えていくところだと思っています。」と、前澤さん。 LTを通じて、サービスを成長させていくためのブランディングとして現在のステップを見極めた適切なプロモーションをされているというのが印象的でした。これからAbemaTVがどのように成長して、どんなマスメディアになっていくのか、ワクワクします！ ディスカッション ここから司会をLIFULLの事業開発グループ 對馬政隆にかわり、ディスカッションへと移りました。この時間では、今回はconnpassを通じて事前に来場者のみなさまからいただいた質問を素材に、登壇者にお話をしていただきました。 ブランディングを推進するために大事にしていることや、ブランディングをやっているなかでの失敗例など、やはり「どのようにブランディングをしているのか」についての質問がとても多かったです。 中でも「効果測定をどのようにしたらいいか」という質問がとても多く、それに対しての回答では、 「定量的な判断というのは難しく、成功したかどうかは測りづらい。だからこそブランディングというところに、企業のトップだったり優秀なクリエイターが関わって、先にあるイメージを強くもって、ぶれないようにやっていくこと。」 簡単に測ることはできないものと思って、ビジョンに対してぶれることなく、絶対に成功させる！という気持ちでやっていくことの方が大事だということでした。戦略やそれに対する効果測定はもちろん大切ですが、その先の世界を見据えて道をつくり続けていくことがデザイナーができることとして重要だとあらためて感じました。 また、ChatWorkさんがコミュニケーションをテーマにLTしていたこともあり、会場からは組織づくりのお悩みや社内への情報共有で困ったことなども質問にあがっていました。 最後に 当日はなんとか台風の直撃は免れましたが、雨だったにも関わらず40名にご来場いただき、ありがとうございました！ 私は「デザイナーの放課後」の１回目からスタッフとして参加しておりますが、このイベントも少しずつ成長して、小さな「ブランド」のような形になっているかな？　と、お話を聞いていて感じることができました。 目標としている「放課後のような交流の場」というだけでなく、特にスキル的なものにフォーカスしすぎない、広くナレッジの共有ができる、そういったところがこのイベントの個性として徐々に現れてきているのかな、と感じています。 以上、デザイナーの放課後＃３開催レポートでした！ LIFULLではLIFULL FLOWERをはじめとした様々な事業において、共により良いサービスをつくっていく仲間を募集しております！エントリーお待ちしております。 recruit.lifull.com また、次回の開催情報も こちらのconnpassページ でお知らせいたします。他にもLIFULLのデザイナーやエンジニアが開催するイベントがたくさんありますので、ぜひチェックしてくださいね！

残暑お見舞い申し上げます LIFULLでデザイナーをしております長谷部です。 立秋とはいえ、真夏日が続いておりますが、皆さまいかがお過ごしでしょうか？ これまで「上澄み編」「だって人間だもの編」とお話ししてきました。 今回で最終回ですが、完成するまでの検討や微調整などデザインの地道な作業のお話ができたらと思います。 デザイナー以外の方はそんなものかと、ベテランの方は生暖かく読んでいただけたらと思います。 www.lifull.blog www.lifull.blog 微調整ってどんな事？ 余白やサイズ感の調整、文字のカーニング処理などなど、だいたいのレイアウトが決まった後の詰めです。 余談ですが、デザインってある程度形になると、周囲的には出来た感が生まれちゃって、デザイナーとそれ以外の職種でギャップ生まれがちじゃありませんか？ 本題に戻りま〜す。 実際に完成前に出していたデザインを使って、1つひとつ紹介します。 小さなシンボルになった時に成り立つものは何か 夏を連想させるアイテムをシンボルにして並べる部分の案だしについてです。 何の絵か分かって、そのシンボルが何を指しているのかわかるものはどれか作ってみて判断していきました。 例えば、LIFULLグループのシンボルはライン画で構成されているので、ベタ面は使用せずに表現したいです。 「水色の枠」 で囲った部分を見ていただきたいのですが、浮き輪やビーチボールを表現しようとした時は、ベタ面とそうでない面が交互にならないと、パッと見でわかりにくくなってしまいます。 夏を連想するにはもってこいなのですが…これでは難しいですね…。 次に、 「ピンクの枠」 です。同じ理由でスイカを表現しようと思った場合も球体のままの状態での表現は難しそうです。 カットした状態を試してみました。半分だと小さくしなくてはならず種や皮の表現に行き詰まりました。三角カットにすると、ぽくなったように思います。 今度は、 「黄緑の枠」 を見てください。アイスキャンディーを表現しました。 凍らせた時の型の形をラインで表現しましたが、きのこの山にも見えなくもない…。なので上からチョコレートでコーティングしたような形を試してみました。 リストバンドになる部分のサービスシンボルは、何個表示が適しているか コーポレートロゴが埋もれてはならぬ。だけれど「LIFULLと一緒に外遊びを楽しもう！」だしそんなに離したくはない… だからってシンボルが小さくなり過ぎると、シンボルが何か分からなくなる。 と、いった部分の検討になります。 ロゴの両サイドに3つずつ並べるか、4つずつにするかですが、量は多いですがサイズ感的に4つずつの方が、ロゴが立つと判断しました。 また、微妙にLIFULLロゴのシンボルよりも他のサービスシンボルを小さくするなどの調整を行いました。 シンボルの線量や太さ、角の形状 小さく使うのに調整したシンボルを、ただ拡大しただけでは間延びしました。 ※時と場合にもよりますので、今回の場合についてはです コンセプトをはっきり表現するにあたり、麦わら帽子だとわかりやすい方が良いので、もう少し詳細に表現するように調整を入れました。 また、大きく扱う部分のシンボルですが、全部同じ太さの線ではなく、バランスを取るために微妙に線の太さを変えています。 それだけでは無く、リボンの切れ込みの角度を和らげるなどして、線の結合部分のムギュッと感をおさえたりしています。 大小全てのシンボルにおいて、ラフの段階では線端を丸型線端（Illustratorで簡易的に設定できるので）で作成していたのですが、最終段階で、LIFULLのシンボルの線端や角の形状に合わせ、オリジナルの形に調整しています。 ロゴを拡大しただけのフォーカスは大きすぎる 中に入るものとのバランスをとってサイズ調整する必要があります。まぁ、当たり前の対処ではあるのですが、フォーカスのサイズ感だけで20パターンぐらいは比較して決めています。もう最後は自分の決めだと思いますが…。 背景の違いによるフォーカスサイズの違い 左右で配置しているフォーカスですが、オレンジに白のフォーカスを置いているときと、白にオレンジのフォーカスを置いている時でサイズを変えています。白は膨張色なので大きく見える為、白に置いているオレンジフォーカスの方を少し大きくしているのです。 2018って重要？でもアクセントは必要 完成前に出していた案のうちの2枚 アクセントになるので、大きくしてバランス取りたくなっちゃうんですよね。私は。 それでバランスは整ったように見えるんですが、今度はこれで一番に伝わって欲しいことってなんだっけ？となり、今度は極端に小さくしてしまったり…。 今回は大きくしすぎずに文字間を広く取る形をとりました。 最終案 今回のが正解だったのかわかりませんが、「ちょうどいい」って難しいですね。 目立たせたくないけど、わからないと元も子もない リストバンドとして使った時に裏面になる部分で、「虫除けリストバンド」であることをお知らせする部分の処理です。 ボツになったパターン一部 輪にして装着する時に、裏表がわかりやすくなるようにグレーにしました。 誰もがこの存在を「虫除けリストバンド」だとわかっているのであれば、特に記載しなくて良い部分です。 デザイン的にもあまり目立たせたく無いわけですが、この案件において、わからなかったら元も子も無いのですよね。 なので、はっきりと「虫除けリストバンド」と記載することにしましたし、初期段階で想定していたグレーよりも、本番では濃いグレーを指定しています。 番外編 手に見えない 突っ込まれて笑いました。なんか人に腕を見せる時って拳を握っているイメージがあって、なんでか拳のイラストを頑張っちゃったんですよね。 でもここで必要なのって「どこに身につけるか分かりやすいこと」であって、その時の仕草の正確性では無いわけです。開いた状態の手に直しました。 料金別納郵便 ここってルールにのっとる必要はありますが、自由にデザインできる部分なこと知ってましたか？ 私は、知りませんでした。（忘れているだけかも知れませんが） 今回は、シンプルに会社ロゴを配置する形にしましたが、これも色々と試してみています。 例えば、子会社含めグループ全体で使う想定のものなのに、1サービスのキャラクターになってしまうのですが、ホームズくんゲスト登場パターンなども。 すごく恥ずかしいですが、自分でも「無いな」と思うものも、最終アウトプット前には結構出してます。 モノグラムパターンとか…もう…個人情報を保護してるみたいですよね（笑）。 ミシン目を入れるところのベタを1mm上げる 入稿後に修正したのですが、印刷時のズレを考慮してミシン目などカットする想定の時はベタ面が被らないように加工用の微調整も必要になってくるみたいですね。 ※ものや状況によって、対処もまた変わってくると思うので、都度こう言った調整はあるものと思います 版分け これまでも特色印刷の入稿はそれなりにやっていましたが、全部印刷会社さんの方で良い感じにしてくれていたので、初めての体験でした。 特色印刷になるので、色ごとに版を分けたデータを入稿しています。 オレンジの版 グレーの版 終わりに グリーティングカード一つとっても細かく見れば検討する部分はたくさんあって、本当にその選択がベストだったと自信を持つには、それぞれの場所でパターンを出し検証する作業が発生しますよね。 ちなみに…色でいうと白が一番虫が寄ってこない説をネットで見つけまして。 今回においては、リストバンド部分は絶対白地が良いという虫除けに対する想いが初期段階から強く… 背景色の割？のパターン出しは比較的少なかったと思います。 そして、コンセプトを形にする時、それぞれのパーツがあるべき場所へカチッとハマった瞬間って、なんとも言われぬ爽快感ですよね！！！ このプロジェクト、規模的には小さいかも知れませんが、その「爽快感」と「やりきった感」を感じることができました。 時間的制約もあるので、途中泣きそうになりましたが、結果非常に楽しかったです！！

　こんにちは！チームで熱狂しながら開発したいサービス企画のスズキです。 今日はLIFULLで行っている「ふりかえりのオブザーバー制度」を紹介します。 みなさん「ふりかえり」をしていますか？ 　ふりかえりとは、プロジェクトの終了後や途中で、あるいはトラブルの発生時に行うもので、プロセスや結果について「ふりかえって改善すること」です。 　プロジェクトやメンバーの状況に合わせて、やり方はいろいろありますがLIFULLではKPTがよく使われているようです。 　ただ「ふりかえり」が開発フローとして定められているわけではないので、プロジェクトによっては実施するタイミング異なっていたり、そもそも行っていないところもあるようです。 ふりかえりのオブザーバー制度とは？ 　制度はその名の通りで、プロジェクトのふりかえりにオブザーバーとして相互参加する仕組みをつくりました。 上の図はちょっと固いイメージですが、事前にふりかえり実施を告知して、参加者を募って実施するというそれだけです。 良いことしかないッ！この制度 受入側 受入先の負担ほぼなし 受入先は特になにも準備をすることもないので負担がありません。 参加者からのFBがもらえる 参加者からアンケートを通じて客観的なアドバイスがもらえます。 参加側 普段の素の姿を見ることができる 同じ社内だけど知らないことって多いですよね。勉強会や情報共有ではわからないことがわかります。 どんなノリでやれば良いのかわかる 本を読んでもチェックインとかどんなノリでやれば良いのか不安になったことないですか？体験できる場は貴重です。 問題の解決方法がわかる（かも？） 同じ問題を抱えているチームは多いので解決方法を教え合ったり、解決できなくても悩みが軽くなったりします。 　と立ち上げたときから良いことしかないと思っていたこの制度です。ですが、オブザーバーの受入をハードル高く思われてたり、タイミングが合わないといったことがあるので、これをクリアしてマッチングの数を増やすことが次の課題だなと思っています 。 例）私のチームのふりかえりはこんな感じでしたが褒めてもらいましたよ 　3月から開始して8月現在で18プロジェクトで受入、43名の方に参加をしてもらいました。ありがとうございます！ 参加者からの感想を紹介 ということで、ふりかえりに参加した方からの感想を紹介したいと思います。 職種：エンジニア ナガサキさん 参加した動機 他のチーム・PJの進め方や課題、振り返りと解決策を知ることで、自チームの参考にしたかった。 得られた気づき 部署やサービスが全然違っても、振り返りで出てくる課題は似ているものなんだ、ということが一番大きいです。また、客観的に振り返りを見ることで、振り返りの進め方を改めて考え直すきっかけを得られました。例えば、事前にKP（チームによってはTまで）を記載して集まることで時間の節約はできますが、集まった意見を読み拾い上げることに時間が割かれてしまい、議論や課題の共有は浅くなる印象です。 参加して変えようと思ったこと 人数ｘ開発期間に比例して振り返るべき内容が増えるので、覚悟して時間を取るようにすること。 今試してみたいことは、別部署の方にファシリテーターをしてもらうこと。 職種：サービス企画 ウシクボさん 参加した動機 自分が参加する振り返りの効果を高めるヒントを得たかったため。 得られた気づき 自分がPJに参加していたら見逃してしまうだろう課題も、オブザーバーとしての客観的な視点から気づくことができた。 他のPJの具体的な振り返り方法を見ることができ、自分が行う際の振り返りにも取り入れやすい。 参加して変えようと思ったこと 客観的な視点を得るため、自分達の振り返りでもオブザーバーを受け入れるようになった。事前にどの程度個人で準備をするか、そのためにどんな書式を用意するのが自分たちに合っていそうか、集まる時間をどのように使うかを再検討し振り返りの仕方を改善することができた。　　 職種：エンジニア ノザワさん 参加した動機 新しいチームが招集され、イチからチーム作りをしなければならなかったため、社内でどんな振り返りやプロジェクト運営が行われているかを知りたかったから。 得られた気づき 活発なチームは、メンバーひとりひとりがチームの目的や目指すべきクオリティをよく理解していて、その文脈において自分は何ができるかをよく理解できていると思いました。さらに言えば、一人ひとりが職種やチームにとらわれず、広い視野を持って、自然に発言・行動ができていると感じました。 参加して変えようと思ったこと 一人ひとり言いたいことが、振り返り会でちゃんと言えるようにしたいと思いました。また、普段気にしなかった相づちや、身振り・手振り、表情などが積み重なって、そのチームの雰囲気を作ったりするので、良いチームを作ろうと思ったら、そういった身体的なところからリラックスできるように工夫しようと思いました。　　 おわりに 　チームづくりや現状のプロジェクトやふりかえりの仕方に悩んでいる方は、他のチームのふりかえりにお邪魔してみてはどうですか？ 　そしてこの制度が良いなって共感してくださった方は、ぜひとも、あなたのチームのふりかえりにオブザーバーを参加させてあげてください。 ※制度のコンセプト：宣教師やミツバチのように、学んだことを拡めていきましょう

夏ですね！暑いですね！LIFULLでデザイナーをしております長谷部です。 前回は完成したハガキの内容についてお話しました。いわゆる綺麗な上澄み部分です。 今回は、完成に行き着くまでの人間模様（私ひとりの）をお話できたらと思います。 実はわたくし、子どもを保育園に預けて時短勤務をしておりまして、ちょっとばかり時間の制約があります。 同じ状況の方は共感を、そうでない方はそんなものかと思って読んでいただけたらと思います。 さかのぼること4月下旬、社内デザイナー間で「LIFULL暑中見舞いコンペ」が開催されました。 募集要項はこんな感じです。 ◆募集内容：2018年のLIFULL暑中見舞いのデザイン（ハガキ＆HTMLメール） LIFULLのトーン＆マナーに則してデザインしてください。 素材、印刷ギミックなど自由に考え、デザインアイデア、予算など総合的に判断して選考します。 ★以下の要項の物を応募先まで提出ください ①ラフスケッチ：完成時のイメージ（手書きorデジタルデータ。作りこんでない状態のもの） 　⎿メッセージの記載を考慮したもの ②プレゼンテーション：デザインの説明、コンセプトがわかるもの ③リファレンス（こんなかんじの！他社事例など完成時が予測できる補足資料などあれば） ◆選考基準： ・LIFULLブランドに沿った内容 ・LIFULLにフィットしたデザインの新しさ(素材も含め） ・実現性（コストなど） ・サイズ：ハガキサイズ（郵送できるサイズ） ギミックってワクワクしちゃいますよね。何かを何かしたら何かになっちゃうとか見えるとか？そんなちょっとした仕掛け、大好物です！！！ ただ、自分のメイン業務もあり、任意参加でしたので、一旦スルーしてました。。。 そんなある日のこと、このメイン業務で進めていたデザイン（自分では超良いアイデア思いついちゃった！と思ってた）のキービジュアルが、作ってみたら（すげー）変だったんですよ。認めたくなくて、小手先でやり方20パターンくらい試したんですが全部変でした。もう惨敗です。お手上げです。そしてよぎりました。 あ！ハガキのデザイン考えちゃお〜♪ 晴れてコンペに参加することになりました。 デザインするにあたって考えたことは「 上澄み編 」で書いたコンセプトと以下のラフにだいたい詰まっているので省きます。 提出したデザインラフ ラフ中に書いてあるテキストは以下 ※ラフなので、インターネット検索でヒットしたものを使用しているので一部ぼかしています いつもよりちょっとだけ長く寄り添うGreeting 年賀はがきにしても暑中見舞いにしても多くのGreetingCardは、届いて目を通した次の瞬間、引き出しの中にしまわれる運命だと思う。 そこを、粋にもう一花咲かせられないか？（粋に：置き場所に困ったり、捨てづらさは感じさせたくない） また、暑中見舞いらしい季節感を出せないかと考え「虫除け」にしてみました。 デザイン説明 あらゆるLIFEをFULLにする為に、色々なサービスを展開している LIFULL分のレジャーという表現にしました。夏のレジャーを思う存分楽しむ為に蚊の撃退でひと役買えたらという思いです。 切り取ると使い捨てリストバンドになる。 ※大人用となると25cmくらい必要そうなのでだいぶ定形外に・・・。 フォーカスの中が、花火や魚釣りや虫取り、海水浴の様に、 夏を思わせて、虫除けが必要そうなシーンのアイテムをアイコンにしたものが入る ラフには装着バリエーションも含めました ラフ案提出の際には定型ハガキでリストバンドになる仕組みは、考えたけど思いつかなかったので、もう閃めかないまま出しました。 え〜いっ、出〜しちゃお〜 ※ちなみに、この案以外にももう一案、もっと安直なやつも応募してました それから… 忘れかかった5月末、担当のアートディレクター（以下ADとします）から連絡がありました。要はもっと現実的なリストバンド部分のアイデアが出ないか？と言った内容でした。 もちろん「考えます！」と即答。 ヤベーよ、それ考えるの放棄してた部分！（汗）ぎゃー、思いつく？自分！ねぇねぇ？ （一旦帰宅） 家にあったハガキで（プライベートで作った年賀はがきが発注ミスで大量に余ってた。この辺も鈍臭い。）、色々切ったり折ったりしながら考えました（Youtubeやゼリーで釣って息子の気を逸らせながら）。 そして、バッグに挟む栞ならなんとかできそう？と思いつきADへ連絡しました。 そして返答がきました。 「ポイントはやはり、身につけてアクティブに外に出る的な部分だと思いますので、手首に巻けるか、シールか…（省略）」 ガーン(￣◇￣;)。やっちまったぜ自分。自分で思ってたポイント自分で壊したパターンじゃないかよ！！（とりあえず息子の頭皮の匂いを嗅いで気持ちを落ち着ける） 息子を風呂に入れたり、悪戦苦闘の末寝かしつけたりしてから、もう一度落ち着いて考えてみること1時間後… あ！思いついたぜ〜っ！ プロトタイプ作ってみたところ、まぁ使えます。 バンドとして両はしのマチがブサイクかな？と思いはするもののADに連絡してみました。 幸い、同じ案で解決していました。 やっぱ遅かったかー。思いついたのはよかったけど、先を越されたのは超悔しい！ あとは実際のデザインに入っていきます。 コンセプトは決まっているので、広げる方向性は決まっていますが、レイアウトを色々試していきました。 イケそうな案から見るからにイケてない案まで出ました。デザインってやってみないと分からないことも多々ありますよね。 そうやって広げては収束させ、収束させた案でまた…広げを繰り返して、大枠こんな感じですねとなった段階で、AD経由でクリエイティブディレクター（以下CDと言います）にチェックしてもらいました。 その時のデザインは以下です。 結果… コンセプトとして、「虫除けリストバンドをして外に出かけてレジャーを楽しもう！」ということであれば、メインL字フォーカス部分にはレジャーを表現したものの方が良い。 リストバンド部分にはサービスのシンボルマークが入るべきではないか。 と言った内容です。 確かに(￣◇￣;)！やばいホントだ。全然ダメじゃないか自分（　ＴДＴ） リストバンドへの繋ぎが分かりやすいとか、そっちの機能面にしか頭が行ってなかったーーーoh。 このあと方向性のOKをいただいたのは入稿日の2日前の昼。。。 色々格闘の末、入稿にはなんとか間に合いました。 間に合ってよかった…。時短勤務のもどかしさを本当に突きつけられた日々だった…。 実際に完成したデザインは前回の投稿をご覧ください。 www.lifull.blog 個人差はあれど、そう簡単にアウトプットは出ませんね！割と泥臭い気がしてます（え？私だけ？）。 コンセプト云々に限らず、慣れた仕事でも第三者の視点で思いも寄らない見落としが見つかったりします。 今回もたくさんの人に協力してもらい最終アウトプットに行き着きました。 次回は、「出がらし編」です。最終アウトプットに行き着くまでの、デザイン細部の処理や検討事項についてお話します。

暑中お見舞い申し上げます LIFULLでデザイナーをしております長谷部です。 暑い日が続いておりますが、皆さま、いかがお過ごしでしょうか？ このたび、暑中見舞いのデザインを担当させていただきました。 実際に仕上がった完成物がこちらです。 裏面 表面 こちらのハガキ、下部のミシン目を切り離すと、使い捨ての虫除けリストバンドになる仕掛けになっています。どうやって使うのかを写真と共に解説しましょう。 ミシン目にそって切り離します。 ミシン目に沿って中央を開きます。 開いたら、輪にします。 手首や腕に装着します。 個人的な感想ですが、輪がピッタリフィットするあたりまで上げてしまった方が煩わしさが出ないと思います。 （腕の細い人はミシン目を全部開かずに穴を小さく装着すると良いと思います。) ざっとこの様なものを作りました。 受け取った方には、小難しいことは考えず「おもしろい」とか「へー」とか…？ もういっそ何も思わず流れるように虫除けアイテムの1つとして使っていただきたい訳ですが、どんなに小さなものにでも目的やテーマに沿ったカタチがあり、そこに行き着くドラマがありますよね。今回はそんな作り手側の想いや要素背景などお話できたらと思います。 デザイン背景 コンセプト LIFULLと一緒に外遊びを楽しもう！ 想い 夏、レジャーシーズンの到来です。海に山に外遊びの機会が増える楽しい時期です。 そんな夏のレジャーを思う存分楽しむ為に蚊の撃退でひと役買いたい。 そして、役目を終えたら潔く去っていくようなサッパリした存在でいたい。 各デザイン 要素解説 ①コピー 「あなたのレジャーLIFEを、FULLに。」 「あらゆるLIFEを、FULLに。」する中で、暑中見舞いでは、レジャーLIFEにフォーカスするイメージです。 LIFULLのロゴについてはインタビュー記事がありますのでそちらを〜。 lifull.com ②麦わら帽子 夏の野外レジャーを連想させるものとして、選びました。 実際は、ベタな麦わら帽子を被っている人はそう多くは無いように思っているのですが、日本人にはパッと夏を連想できるアイテム（世代ありますか？）として染みついているのかなぁ？という考えです。 しかも、遊びを限定しないんです。場所も山でも海でも近場だって良い。それぞれのレジャーを受け取り手側に委ねる感じが良いなと思いました。 ③サービスシンボル 実際に身につける部分になります。LIFULLにあるサービスアイコンを並べ、コンセプトにある「LIFULLと一緒に外遊びを楽しもう！」を表現しています。 夏を連想させるアイコンも混ぜることで、楽しもう！を強めました。 ④メッセージ記入エリア ダルマの目を入れるように、ハガキを出す人が最後にそれぞれの言葉を加えて完成するイメージです。 もし出来たらという程度に心の中にとどめていたのですが、『スペースは空いているからそこにでも書いておいて』じゃなくて、ちゃんとその言葉が置かれる場所というのが作りたかったです。 印刷仕様 ハガキサイズは定型ですが、ミシン目を入れたり、カラーインク以外に虫除けインクも使いますので、デザインを詰める前から印刷会社さんと打ち合せをして、プロトタイプをいくつか作りながら進めていきました。 色んな進め方があると思いますが、今回、型になる割合などはこちらから指定しています。 印刷会社さんと詰めることは、具体的には以下です。 宛名印刷分として何ミリ必要で、リストバンド部分を何ミリ取れるか。 リストバンドの強度を考え、輪にした時の両サイドは何ミリ残すか。 紙の材質や厚さはどれにするか。 何色刷りにするのか（予算とのバランスもあります）。 最終的に使用したインクは、特色カラー2色（Pantone2018c、Pantone429c）＋虫除けインクになりました。紙は、虫除けの香りが一番出やすいとのことでしたので「マットポスト紙」を選びました。 虫除け効果を優先させるため、刷り銀やニスなどの特殊印刷を控えました。 何で効果が薄れるのか聞き忘れたのが心残りです・・・ ハガキ一つでも結構色々ありますよね。 今回は最終アウトプットになった言わば上澄み部分のお話をしました。 次回は、デザイン以外の完成に行き着くまでのプロセス、「だって人間だもの編」をお話するつもりです。

こんにちは！ LIFULLのジンジニア（人事＋エンジニア）の木村です。 今年の夏は猛暑が続いてますが、エンジニアを更に熱くするカンファレンスが立て続きに開催されますね！ LIFULLも「乗るしかない、このビッグウェーブに」ということでスポンサー協力させていただくことになりました！ 画像引用元： https://iosdc.jp/2018/ 、 https://builderscon.io/ 、 https://pycon.jp/2018/ 第一弾！ iOSDC Japan 2018 （8/30～9/2） ゴールドプラン＆前夜祭/LTビールスポンサーとして参加予定です！ 新機能 「かざして検索」 をリリース、各メディアにも取り上げていただいて、好評を博しておりますLIFULL HOME'S iOSアプリ。 そのアプリ開発チームからLT大会での登壇も予定されています。ぜひ遊びに来てください。 おいしいビールを呑んで暑い夏を乗り切りましょう！ LIFULL HOME'S(ライフルホームズ) 不動産アプリ LIFULL Co., Ltd ナビゲーション 無料 第二弾！ builderscon tokyo 2018 （9/6～9/8） 技術を愛するギークのお祭りbuiderscon tokyoのスポンサーします！ 休憩・入れ替え時に会場内スクリーンでCM動画を流させていただく予定です。 トークテーマも多岐にわたっており、どれを聞こうか迷いそうですね！ 一緒にこの夏祭りを楽しみましょう♪ 第三弾！ PyCon JP 2018 （9/15～9/18） PythonユーザーのためのカンファレンスPyCon JPにシルバースポンサーで参加します！ LIFULLのAI関連チームを中心にPythonの利用は増えています。 機械学習をテーマに先日主催した イベント も大盛況でした！ lifull.connpass.com データサイエンティスト＆機械学習エンジニア、鋭意募集中です！ 最後に 週末、一週間おきに大きなイベントが催される熱い夏になりそうですね！ LIFULLもエンジニアの夏を盛り上げるため微力ですがサポートしていきます。 もしLIFULL Tシャツ着てる者を会場で見かけたらぜひお声掛けください！ホームズくんステッカーを持ってお待ちしております！ 楽しみましょう！！ エンジニア採用あります！ 各種エンジニア募集中です！ご興味のある方ぜひ覗いてみてください。 hrmos.co recruit.lifull.com

エンジニアの鈴木(a.k.a すずけん )です。 先日(7/4)、恵比寿の街を舞台に街バル（弊社従業員向けイベント）が行われました。 本記事では、街バルでプロデュースした AWS IoT Enterprise Button を使ったアイデアソン について、企画内容や実際やってみた感想などを紹介したいと思います。 IoTボタン の使い方を悩んでいる方に、ひとつのアイデアとして参考になれば幸いです。 全社イベント「街バル」 街バルとは、会社で立案・実施されたイベントで今回がはじめての試みになります。 各プロデューサーが好きな企画を立てて、日頃あまり接点のない方と企画を通して交流を持つためのイベントです。 プロデューサーとして立候補した人数は実に合計100名を超え、計25個もの企画が恵比寿の街のどこかで同時に行われました。 (実行委員の皆様、本当にお疲れ様でした🙇） その街バル企画において、自分は「 AWS IoT Enterprise Button Ideathon 」という企画を立案し、プロデューサーの１人として参加しました。 AWS IoT Enterprise Button Ideathon はじめに、 AWS IoT Enterprise Button について軽く説明をします。 AWS IoT Enterprise Button とは AWS IoT 1-Click サービス専用のIoT デバイスで、 ボタンのクリックに様々なアクションを関連付けることができます。 今年の5月後半くらいに、ようやく国内でも販売が開始されました。 発売開始直後は、すぐに在庫無しになっていましたが、現在は購入できるようです。 Enterpriseと入っていますが、別に企業向けというわけではありません。 普通に個人で購入し簡単に動かすことができます。 IoTボタンの具体的な利用事例だと、コーヒーを淹れたらボタンを押してSlackに通知する等、 何かみんなに知らせたいことがある場合などに使われているようです。 当初の企画段階ではボタンを使ったハッカソンの予定でしたが、参加者は "エンジニアだけとはかぎらない" のと、 "エンジニアであっても短い時間で慣れない実装をしようとするとアイデア自体が小さくなりそう" な予感がしたため、アイデアソンという形に切り替えました。 運営側は、先日のDevSecOpsのコンテストで一緒に優勝してきた磯野が運営リーダーになり弊社のエンジニア４名でプロデュースしました。 www.lifull.blog アイデアソンの形式は、以下の様にしました。 １チームは３名で構成される 最終的なアイデアは一枚の絵にまとめてもらう チームごとにアイデアを1分でプレゼンする プレゼン後に、参加者全員で投票を行い優勝を決める チーム分けの工夫として、メンバー各自が ファシリテーター (進行担当)、 クリエイター (成果物担当)、 セールス (プレゼン担当)と１人づつ役割を当てることにしました。役割がはっきりしたほうが 余計なことを考えずにアイデア出しに集中できる と考えたからです。 また、企画の壁打ちをしている最中に、 アイデアソンとはいえやっぱりボタン押したいよね？ ということになり、 ボタンを使った班分けシステムと、投票システムを急遽作ることになりました。 バックエンドの実装は自分が行い、フロントサイドは他のメンバーにお願いしました。 最終的に社内に広報された参加者募集の資料は以下のようになりました。 資料内画像引用: https://www.amazon.co.jp/dp/B075FPHHGG 班分けシステムと投票システム 開催日まで時間がなかったので、システム構成は極力シンプルに作りました。 班分けシステムも投票システムも同じアーキテクチャで、データ保持先のDyamoDBのデータ保持形式が違うくらいです。 仕組みとしては、 ボタンが押されるとLambdaがトリガーされて、DynamoDBへデータを書き込みます。 DynamoDBからDynamoDB streamにイベントが流れ、それをLambdaで拾ってIoT Coreにリレーします。 IoT CoreはS3にホストされたSPAとMQTT over websocketで通信し、SPAはイベントをハンドリングして画面に反映します。 IoTボタンは10チーム(10個)と班分けに1個で、合計11個使いました。 個人ではこんなに購入しないので、ちょっと壮観です。 また、IoTボタンのネットワークは、ポケットWiFiを経由させることにしました。 これは、ポケットWiFiのWAN側を切り替えられるようにしておくことで、 複数のIoTボタンにネットワークの再設定をする手間を減らすためです。 当日 アイデアソンは恵比寿のレンタルスペースで開催する為、早めに現地入りしてシステムの動作確認をする予定でした。 ですが、現地入りしてすぐに参加者用のドリンクが配送されてきます。 動作確認とドリンクの保冷を天秤にかけて、結局30人分のドリンクを冷蔵庫に詰め直す作業をすることにしました。 前日動作確認を済ませておいたので後回しでも大丈夫だろうと判断したのですが、思いの外作業が終わらずどんどん時間がなくなっていきます。。。 結局、早めに来た参加者にいろいろと手伝ってもらい、現地での作業とシステムの動作確認を完了させることができました💦 参加者が全員集まったところで、アイデアソンの説明が始まり、ついに班分けのタイミングがきました。 「班分けします！」とアナウンスし、いざ！班分けというタイミングでDynamoDBのテーブルを確認すると、 誰もボタンを押して無いはずなのにすでにデータが入っています 😨 なんと、参加者がそこら辺に置いておいた班分け用のIoTボタンを何度か押していたことが発覚しました。。。 登録データの初期化などを急いで済ませ、もう一度仕切り直しです。 順調に一人つづボタン押して行き、チームと役割が決まっていきます。 あと残り二人というタイミングで、「あれ？なんかおかしい、 青いランプが点滅 してますよ」ということに。。。 完全に想定外でした。。。 IoTボタンは、 6秒以上長押しするとセットアップが始まる 仕様になっているのです。 タイムスケジュールが押していたのと、しばらくボタンが反応しなそうだった *1 こともあり、班分けが終わっていない残り二人を空いてるチームに振り分けました。 そんなトラブルもありつつ、アイデアソンがスタートすると、 各チームがどんどん活性化していく のがわかりました。 当初は、もっとゆるふわな感じになるかなと想定していたのですが、いつの間にか結構ガチなアイデアソンになっていました。 1時間を超えるアイデア出しが終わり、プレゼンが始まりました。 どのアイデアもおもしろく、示唆に富む内容で、面白いアイデアがたくさん出ました。 各アイデアはIoTボタンが付けてあるダンボールに貼り付けられており、 全てのプレゼンが終わった後は、みんなで各アイデアのIoTボタンを押して投票する流れです。 そして、いよいよ結果発表。。。 一位のチームには全員にAmazon Echo dot, 二位のチームには全員にAWS IoT Enterprise Button が贈呈されました！ また、最後に「最も〇〇だったで賞」として「辛口」、「恵比寿」、「自由」のテーマに沿ったアイデアを出してくれたチームに、それぞれウィルキンソン（辛口）、YEBISU（恵比寿）、オールフリー（自由）のAmazon Dashボタンが贈呈されました。 最後の開票時に盛り上がりのピークを迎え、 参加者がみんな笑顔になっているのを見て、 プロデュースして本当に良かった と感じました。 （投票システムはトラブルなく期待どおりに動いて本当によかったです😋） その後、全員で後片付けをし AWS IoT Enterprise Button Ideathon は幕を閉じました。 まとめ 以上が今回プロデュースした企画と実際の出来事になります。 個人的な感想としては、街バルは次回もあるとは限らないので、 こういうチャンスに 積極的に参加することができてよかった と感じています。 また、運営を通じて得るものが多くあり、また一つ経験を積むことができました。 IoT ボタンの利用用途を考える際、どうしても業務や生活を便利にする為に何ができるのか？という視点になりがちですが、こういった（ あまり役に立たない ）楽しいことにも十分にフィットするので、 IoTボタンの可能性は無限大 だなぁと感じました。 IoTボタンは簡単につかえて、アイデア次第でいろんなことができるので、 これからもどんどん使っていって事例を共有していけたらと思います！ *1 : 落ち着いてアプリ側からキャンセルすればよかったのですが、この時は気づきませんでした。

こんにちは！LIFULL HOME'Sの新築一戸建てマーケットでデザイナーをしているkobarieです。 このたびLIFULL HOME'S新築一戸建てでは「来場スタンプ押すともらえる！ LIFULL HOME'S ご来場キャンペーン」を開始しました！ 今回はこのキャンペーンでのデザイン過程やこだわりをお伝えしたいと思います。 「来場スタンプ押すともらえる！ LIFULL HOME'S ご来場キャンペーン」とは？ 本キャンペーンは、LIFULL HOME'Sを利用したユーザーが新築一戸建てを見学して、物件の感想を送ると、Amazonギフト券がもらえるというユーザーの来場促進を目的としたキャンペーンです。 ユーザーは、見学先のモデルハウスや不動産会社の店頭で、スマートフォンにデジタルスタンプを押印することでキャンペーンに参加ができます。 現在、全国の約8,000物件の現地・モデルハウスで実施中です。 キャンペーン詳細はこちらをご覧ください https://www.homes.co.jp/visitor/kodate/about/ デザイン試行錯誤・こだわり 今回プロダクトを作る上で特に気をつけたことは、リアルとデジタル、家と現地とを往来するキャンペーンのため、それぞれのタッチポイントに合わせたUXデザインを行うことでした。 ユーザーがサービスを利用している状況に合わせたゴール設定、使いやすさ、わかりやすさを追求しました。 現地でポップを認知してもらいたい 現地では、ポップがユーザーとの最初の接点となるため、まずはポップを認知してもらう必要がありました。 これを解決するため、ブランドカラーであるオレンジ色を全面に出し、ポップ自体の存在感を高めました。 キャッチコピーもキャンペーン名ではなく「2,000円分もれなくもらえる！」というユーザーの興味喚起を直接促す言葉で訴求しました。 また、ポップの大きさも実際の利用シーンを想定して、いくつもの試作品を作りサイズパターンを検討しています。大きさを検討する上ではこんな課題がありました。 大きすぎると店頭で邪魔になってしまう 小さすぎるとユーザーに気がついてもらえない 高さを出しすぎると、重心が不安定になり倒れやすくなってしまう 試作品を何度も作り直しながら、チーム内だけでなく営業職や他部署のメンバーにもヒアリングした結果、A4サイズが一番適しているとの意見で一致し、一般的な卓上ポップより大きめのA4サイズで決定しました。 細かい説明テキストは読まれない これはポップに入れる要素を検討する段階で上がってきた課題です。 当初は、左面に各ステップの説明テキストを置き、キャンペーンの参加手順を詳細に伝えることを重視した設計にしていました。 なぜならば、現地では我々がその場でフォローを行うことはできないため、ユーザーが自身で参加手順を理解し、各ステップを行う必要があるためです。省略した説明では、やるべきことがユーザーにきちんと伝わらないのではないかと考えていました。 ところが、実際に試作品を用いたユーザーテストを行ってみると、詳細テキストを読むことなく ユーザーはQRコードを発見すると、すぐにスマホを取り出し撮影するというケースが続出したため、シンプルな説明に変更しました。 スタンプ端末の使い方が伝わらない 皆さんは「デジタルスタンプ」を使ったことがあるでしょうか？ この1年程で見かける機会も増えてきましたが、このユーザーテストを行った時点では 実際に使うのは初めての人が多く、使い方を知らない人が多かったです。 ユーザーはしばし悩んだ後、ポップや画面の案内から正しい使い方を理解してスタンプを押す、といったケースが多く、中にはスタンプを押すことができずにテストを終了したケースもありました。 そこで、2つの解決策を講じました。 ポップにスタンプを手に持っている写真を入れ、視覚的に伝えたり スタンプ画面に、アニメーションでスタンプを押す様子を表示させたりしました。 プロトタイプを何度も作成し検証を重ねた結果、その後のユーザーテストでは使い方の誤認が激減したため、この課題についてはある程度クリアできたことになります。ここは本当にテストで課題を見つけることができて良かった点です。 スタンプのインタラクションにこだわり もう1点デザインで今回こだわった箇所として、スタンプを押した時に表示される絵柄があります。 ユーザーがスタンプを押したことに対するインタラクションにこだわり、エンジニアとも話し合いスタンプの日付を表示させました！ まとめ 今回キャンペーンの制作物をデザインするにあたり、常に"ユーザーはどう思うか"ということを意識しながら進めました。ただ漠然とユーザーの立場で考えるだけでなく、その時のユーザーの置かれた状況など背景にある事情も含めて考えることで、その場面では何が必要かといった判断がしやすくなります。 また、デザイン業務のプロセスにユーザーテストを取り入れたことで、当初想定しなかったいくつもの課題を発見することができました。 チーム内で議論を重ねて作ったプロダクトであっても、実際にユーザーに使ってもらうことで思いもよらなかった課題を発見できたり、そこから更に改良を加えることができたりと、ユーザーテストの有用性を改めて感じました。 今後もこういったプロセスや考え方を取り入れながら、ユーザーによりそったデザインを作り続けたいと思います。

初めまして。流通事業部UXU開発2Gの吉田です。普段はLIFULL HOME'Sの中古物件領域の開発を担当しています。 前の記事のナガサキさんと同じく私もRubyKaigi2018に三日間とも参加してきましたのでレポートを上げます。 ただ、三日間の講演をすべて書くとなると非常にボリュームが多く読む方も疲れてしまうと思うので各講演を三行にまとめてみる、という試みで書きます。 Day1 Keynote by @yukihiro_matz [JA][Keynote] Keynote / Yukihiro "Matz" Matsumoto @yukihiro_matz このことわざを元にしたKeynoteはボリュームが多いので各セクションごとに三行とさせてください…。 名は体を表す クラス名やメソッド名、変数名といった概念に適切な名前をつけることで使い勝手を良くする必要がある プロジェクト名は求心力、旗印となるので大事 Googleが検索の覇権を握っている今日ではググラビリティを考慮した名前付けをする必要がある Time is Money お金と言っているが実際には価値 いかに短い時間で価値提供ができるか、それを実現するために各コミュニティやツールがある 動作速度も重要で、そのためにJITコンパイラや並列実行機能の強化をしていく 塞翁が馬 Rubyは死んだとよく言われているが波があるので気にしない Python2→3もRuby1.8→1.9も破壊的な変更のせいでユーザがついてこれずコミュニティが分断してしまった過去がある Ruby2→3にするときは同じ轍を踏まないように進める Analyzing and Reducing Ruby Memory Usage by @tenderlove https://speakerdeck.com/tenderlove/reducing-memory-usage-in-ruby メモリの使用量を下げたい場合、まずはコードを読むかmalloc stack traceをしてどこでメモリを使用しているかを確認すること Ruby2.6ではrequire済みのファイルの探査方法においてRubyのハッシュを作成するのではなくCの文字列を直接参照するようにしたため省メモリになる Ruby2.6ではDirect ISeq Marking（直接命令シーケンスマーキング）という技術を導入することでGCのための配列が巨大化せずに済むので省メモリになる Hijacking Ruby Syntax in Ruby by @joker1007 & @tagomoris Hijacking Ruby Syntax in Ruby from SATOSHI TAGOMORI Binding、TracePoint、Refinements、Ripperと様々なクラスを使ってfinal, abstract,overrideなどJavaLikeな継承とかを強制させるgemを書いた@joker1007さん 同じくTracePointを用いてリソースの切断を確実に、コード上はスマートに実行できるwith_resourcesとGoのdefer機能をRubyのgemとして実装した@tagomorisさん（ただしいずれもプロダクションには適用しないほうがいいとのこと） これらのクラスを使った黒魔術はくっそ楽しいけどデバッグが大変なので覚悟が必要 All About RuboCop by @bbatsov https://speakerdeck.com/bbatsov/all-about-rubocop-rubykaigi-2018 .rubocop.ymlの作成には--auto-gen-configを使うのもよいしgryを使うのも良い Rubocop1.0はRails用のAPIをコアから取り除いたら。近い内にリリース予定 スムーズな移行のためにmryの利用を推奨 RubyGems 3 & 4 by @hsbt RubyGems 3 & 4 from Hiroshi SHIBATA RubyGems2.7だけが安定版で2.5, 2.6はセキュリティメンテナンスしかされないのでもう使わないで RubyGems3.0はRuby2.2以降を対象としたものでdeprecateとなっている機能の削除、新しくdeprecateになるやつのwarningを出すなどRubyGems4.0に向けた移行バージョン RubyGems4.0はRuby2.7か3.0に合わせてリリース予定でコンサバティブオプションの導入や--user-installをデフォルト扱いにする意向 A parser based syntax highlighter by @p_ck_ https://speakerdeck.com/pocke/a-parser-based-syntax-highlighter 既存のシンタックスハイライターは正規表現で書かれていてバグりやすい＆読めなくて辛いのでRipperを使ってIroというRuby*Vim向けシンタックスハイライターを自作した 対象としてyamlもpythonもサポートしており、今後はslimとMarkdownもサポートしたい オンラインで試せる https://ruby-highlight.herokuapp.com/ Day2 My way with Ruby by @ktou My way with Ruby https://slide.rabbit-shocker.org/authors/kou/rubykaigi-2018/ フリーのソフトウェアを使ってRubyでできることを増やす活動をしていた バリデーション機能付きのRSS/Atomパーサが欲しくて自作した→その流れで内部的にRSSパーサを使っていたREXMLのメンテナーになっていた、というような感じ 一人でやるには限界があるので一緒にやってくれる人を募集している Faster Apps, No Memory Thrash: Get Your Memory Config Right by @codefolio https://docs.google.com/presentation/d/1-WrYwz-QnSI9yeRZfCCgUno-KOMuggiGHlmOETXZy9c/edit#slide=id.p 高速なアプリケーションを作るためには不要なコードは消す、環境変数のチューニング、jemallocを使う、最新版のRubyを使う GCは遅いので無駄な処理を入れないことでGCを走らせない、いくつかの小さいオブジェクトをいくつも持つよりも大きなオブジェクトを1つ持つほうがメモリ効率が良いときもあるなどそういったリファクタリングも必要 GC.statやGC::Profilerを使ってメモリの状態を見よう Guild Protype by @ko1 http://www.atdot.net/~ko1/activities/2018_rubykaigi2018.pdf GuildとはThreadsに置き換わる新しい並行プログラミングのための機構でRuby3に導入予定 分散するほどでもない処理量のものに関してはGuildを使わないほうが高速になる場面もあるが、適切に使えればvCPUの数に応じてWorker数を増やせば効果を発揮する GCのタイミングでcriticalエラーが発生するなどまだ課題がある Type Profiler: An analysis to guess type signatures by @mametter 型解決のシステムとしてはSteep、RDL、Sorbet(by Stripe)の3つが有名所として挙げられるがMatzの意向としては外部ファイルに設定を書くSteepが合っている しかし自分で型を書くのはしんどいので、コードを解析して自動で型ファイルが生成されるようになればよいというところでRubyのコードをTypeProfilerという中間ファイルのようなものに変換しTypeDBに問い合わせて「この使い方であればこの型である」といった構想に行き着く 3パターンほどプロトタイプを作ってみたが課題もあり、道半ば Day3 The Method JIT Compiler for Ruby 2.6 by @k0kubun https://speakerdeck.com/k0kubun/the-method-jit-compiler Ruby2.6-preview2に入っているけどバグってるからプロダクションでは絶対に使わないで 検証コードではRuby2.0より5倍ほど、OptCarrot（Ruby製NESエミュレータ）では2〜3倍高速化できたが、Railsでは遅くなってしまった 検証したところRuby→C→RubyというCからRubyの呼び出しの過程で遅くなっていることが判明したのでRuby→Rubyに変えたら高速化できた C is dead How happy they became with H2O/mruby, and the future of HTTP by @i110 & @kazuho [JA] How happy they became with H2O/mruby, and the future of HTTP / @i110, Kazuho Oku @kazuho mrubyを使ってimgのリサイズリクエストを捌くようにした話 nginxのconfに記述してリクエストを捌くやり方はテスタビリティも低く（設定を変えるたびにreloadしてcurl？）、デバッグもしづらい mrubyを使うことでputsで環境変数も確認できるしmruby-mtestというGemを使うことでテストも書けるので運用効率が上がった goreplayというアクセスログからリクエストを再現できるツールを使い計測したところ高速化も確認、本番導入もしたが全体的には高速化につながった（一部リクエストは若干の遅延） EarlyDataヘッダとhttp status 425を標準化したときの話 バグの多いクライアントが存在するために新しいプロトコルを導入しようと思った時点でダミーの拡張でもいいから先に流しておいて、今後クライアントにエンバグさせないという工夫が必要 httpは高速化のために103 ealry hintsなどの設定が複雑化していっているのでmrubyやrackを用いてシンプル＆プログラマブルな書き方をしていく必要がある つまりC is dead（Cで書かれているapacheやnginxで頑張るな、というジョーク） 終わりに 一部書けていない講演もありますし、三行に収めるために内容を削ぎ落としているため多少語弊を招く箇所もあるかも知れません。 詳細は記載の資料を読んでいただくなりしていただければと思います。 また、先日LTechという自社イベントの第0回という形でRubyKaigi2018の参加報告をさせていただきました。いくつかの講演に関してはもう少し細かく報告しております。 次回のLTechは記念すべき第1回として 機械学習で開催予定 です。ありがたいことに既に参加応募をたくさん頂いており予定人数を超えてしまっていますが補欠枠は引き続き募集しておりますのでご興味があれば登録の程をお願いいたします。 また第二回以降も鋭意企画中ですので興味をお持ちの方は是非connpassのLIFULLページからメンバー登録をお願いいたします。 lifull.connpass.com またLIFULLではRuby好きなエンジニアや、カンファレンス好きなエンジニアの方を採用も募集しています。こちらのご応募もお待ちしております。 hrmos.co

こんにちは！LIFULLでLIFULL HOME'Sの開発を担当しているナガサキです。 先日RubyKaigi 2018に参加して来ました。この投稿では、RubyKaigiの様子や初めてカンファレンスに参加して感じたことを書いてみます。 まず、RubyKaigiについて簡単にご紹介します。 RubyKaigiは、毎年日本で開催されているRubyの国際カンファレンスです。 Rubyの生みの親のMatzさん（まつもとゆきひろさん）をはじめ、世界中のRubyistが会し講演します。 今年は宮城県仙台市の国際センターで開催され、公式発表によりますと、1000人以上参加したそうです。 rubykaigi.org スポンサーブース LIFULLは今回初めて、RubyKaigiのプラチナスポンサーをさせて頂きました。 （写真に写っているのは弊社の人事です。） 当日の会場では、スポンサーブース用に1部屋用意されており、各社がサービスの案内や、ノベルティの配布を行っていました。 私も1 Rubyistとして各社のブースにお邪魔させていただきましたが、素敵なノベルティをいただけたり、各社のRubyの活用事例を聞けたりと大変楽しませて頂きました。 講演 メインホールでは毎日朝一で基調講演が行われ、そのあと3会場で各講演が同時進行していました。 日本語・英語のセクションが半々という感じで、日本語から英語への翻訳機が貸し出されていました（逆はなし）。 私は大学院時代に国際学会に参加したことがあるのですが、ポスター発表がない以外はRubyKaigiもほとんど同じでした。 学会でもそうですが、普段なかなか触れることのない技術や知識を仕入れられるのが、カンファレンスならではの良さだと思います。 今回私は、Truffle Rubyやmrubyなど、CRuby以外について知見を得ることができ、大変刺激になりました。 詳細は下記公式サイトの動画を是非ご覧ください。 Parallel and Thread-Safe Ruby at High-Speed with TruffleRuby - RubyKaigi 2018 How happy they became with H2O/mruby, and the future of HTTP - RubyKaigi 2018 参加してみて 私が初めて参加して感じたことをまとめると、 RubyKaigiのコンテンツは、Rubyの活用事例というより、Ruby自体をどうしていくかという内容 気づいてみれば当たり前なんですが、想像以上にコアな話が多かったです 英語の公演が多く、日本語の公演者であっても、英語で質問を受けて当たり前に英語で応対していた 英語がんばろうと思いました 普段興味を持ちにくい分野について知識を仕入れられる、世界中のRubyistと交流できる、と行くだけでも得るものが多い LT会やハッカソンに参加したことはありましたが、カンファレンスには初参加で、新鮮な刺激を得られました LIFULLでのこれから 上でも書きましたが、RubyKaigiで得たものは多く、仙台まで行ってよかったです。これまでもWWDCやAWS re:Inventなどに毎回数名のエンジニアが参加していましたが、もっと様々な機会に参加できるようにして いきたいと思いました。RubyKaigi後に弊社ジンジニアも含め、そんな思いやこれからの体制について熱く語り合いました（こういう場を得られるのも出張ならではかもしれません）。 また、自社の技術利用事例や研究成果ももっとアウトプットしていきたいという思いから、LTechというイベントを定期開催することになりました！ 先日まさにRubyKaigi報告会と題して、私も#0で発表させて頂きました。CRuby以外の可能性について、簡単ですがまとめています。 lifull.connpass.com 次回は機械学習で開催予定です。 lifull.connpass.com #1は既に参加応募をたくさん頂いておりありがとうございます！ 引き続き開催していきますので興味をお持ちのかたはconpassのLIFULLページからメンバーにご登録いただけると嬉しいです。 最後になりますが、LIFULLではRuby好きなエンジニアや、カンファレンス好きなエンジニアの方を募集しています。ご応募 お待ちしています！ hrmos.co