こんにちは！ 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

こんにちは。新卒3年目デザイナーおおしだです。 以前には、「経験0からデザインをする上で大事なこと5選」を書きました。 www.lifull.blog もうあれから2年経ちます…驚きです。 今回は私がデザイナーとして開発に携わった、いろんな街の情報コンテンツ「まちむすび」に関して書こうと思います。 まちむすびとは？ 「まちむすび」は、気になる「まち」や知らなかった「まち」のことを実際に住む人の声や各種データから知ることができる、 街の情報がつまった情報コンテンツです！ 引越しをしたいと思ってウェブサイトなどで家を探してみると、候補にいろいろな駅が出てきてどこを選んだらいいかわからない！ということ、ありませんか？ どの駅が、あるいはどのまちがどんな場所なのかわからないまま引越しをするのは不安ですよね。 実際に住み替えをするのに必要な情報を最適な形でユーザーに届け、住み替えに役立てていただきたいという気持ちから生まれたのが この「まちむすび」です。 内容を少し紹介すると まちごとにいろいろな評価が見られたり ランキング形式でまち周辺の雰囲気がわかったり まちへの口コミがみられたり そのまちの家賃相場がわかったり などなど、「まちむすび」には気になる情報が盛りだくさんです。 なぜ「まちむすび」になったのか この「まちむすび」という名前が決まるまでは、ボツ案が何十個も出たりなどしながらメンバーでの話し合いが続きました。その中で、 街に関する言葉を入れたい みなさんに覚えて使ってもらえるような、端的でかつインパクトのあるものにしたい コンテンツの特徴である、街と街をつなぎ、まちとユーザーも繋げることを表したい というところから 「まち」と「むすぶ」という言葉が浮上しました。 「まちむすび」というサービスの意味 街の情報一つ一つが一つのコンテンツとなって集まる 街と街、人と人、そして街を人をつなぐ、結ぶ 開発者がお互い協力して、街に住む人の声を形にしていく という意味を込めて「まちむすび」に決定しました。 「まちむすび」が目指すこと 「まちむすび」が目指していることは、”住み替えに役立つ「まち」の情報を提供する事”です 住み替えの後に判明するような「まちの情報」を住む前に提供する事で、より多くの人々に、心から満足するような家との出会いに繋げ 「このまちに住んで良かった」「まちむすびで探して良かった」と思ってもらう事を目指しています。 今よりもさらに「まち」から家を探す、ということが広まって欲しい、それによって満足のいく住み替え体験をより多くの人に提供したい、 そんな気持ちで日々開発を行なっています。 「まちむすび」デザイナー目線の誕生秘話 「まちむすび」のデザイナーとしてアサインが決まった時、私は嬉しい気持ちでいっぱいでした。 自分自身、街情報のコンテンツが住み替えの時にあったなら引越しに失敗しなかったのに…という気持ちや 純粋に新しいコンテンツのデザインをしてみたい！という思いがあったため、嬉しい気持ち反面 大規模PJのデザイナーとして初めてアサインされたことに不安も半分、というところでした。 しかしながら、PJメンバーと一緒に、この要素はこうあるべきだ、こういう見せ方だったらユーザーにとって魅力的に感じてもらえるはず、 ユーザーの流入や遷移から何を優先させて画面に表示させるべきか、など、話し合いを重ねリリースまでたどり着きました。 「楽しかった、でも大変だった、もっとユーザーに寄り添ったデザインにしたい」というのが今の気持ちです。 デザインのこと 「まちむすび」のデザインでは、ユーザーに親近感をもってもらいたい、街を探すことをポジティブに捉えて欲しいという想いから イラストやアニメーションにこだわっています。 （是非是非、まちを探してスクロールして見てください！ https://www.homes.co.jp/machimusubi/ ） 私にとって今回挑戦だった部分は、イラスト部分に用いているアイソメ図です。 「はじめましてアイソメ」 という感じでした。 （ちゃんと描いています！） 基本的にIllustratorを用いて描いています。 もともとは正方形の図形を平面・右側面・左側面でそれぞれ変形を行うことをアクションを使うと効率的に作ることができます。以下は一例です。 平面 拡大・縮小（垂直:81.65% 水平:70.71%）→ シアー（30度）→ 回転（-30度） 右側面 拡大・縮小（垂直:81.65% 水平:70.71%）→ シアー（30度）→ 回転（30度） 左側面 拡大・縮小（垂直:81.65% 水平:70.71%）→ シアー（-30度）→ 回転（-30度） 左を組み合わせていくと、右のようになります。 まちむすびの今後 「まちむすび」は、どんどん新しいコンテンツや改修を行なっていく予定です！ 乞うご期待。 「まちむすび」を使ってくださる方が好みのまちや、今まで知らなかったけど好きになれるまちに出会えるように もっとこのコンテンツをよくしていきますので、ぜひ、街の情報コンテンツ「まちむすび」をご活用ください。 https://www.homes.co.jp/machimusubi/

こんにちは。クリエイターの日運営委員会の工藤です！ 先日第6回創民祭が開催されましたので紹介させていただきます！ 創民祭とは？ 創民祭（そうみんさい）とは、業務や「クリエイターの日」、プライベートの成果など、LIFULL社員が作ったプロダクトをお酒を飲み、ピザ・寿司を食べながらお披露目する場です。 こんな感じで仕事終わりにビールを飲みながらやりました！！ 前回の様子はこちら www.lifull.blog 多種多様な展示プロダクト 当日に展示されたプロダクトを紹介します！ VR Surprise VR空間に写真やメッセージをのせることのできるサービスです！誕生日の時などのサプライズでこういったサービスがあるとデータとして思い出が残り続けるので、嬉しいですね！ オリンピック バス運行状況マップ バスのリアルタイムの現在地を地図上に表示することでバス利用をサポートするサービスです。コンテストに出すために2日間で開発したみたいです。オリンピックで使うことを想定していて、オリンピック会場からバスを検索することができます！ AIも活用しオンラインで気軽に議論！オンラインブレストサイト オンライン上でたくさんの人が気軽に社会課題の解決のために議論できるサービスです。集まらなくても遠隔でブレストできるので、アイデアとかを考えるときにとても便利ですね！ LIFULL Vuilders LIFULL Fabにて3Dモデリングなどを行い作成された椅子です。頑丈で人が乗っても全然平気でした！ちなみにLIFULL Fabとは弊社が運営するFabスペースとなっております。 lifull.com チャットボットプロトタイプ ホームズくんと対話しながら、疑問を解決することができるチャットボットです。従来のチャットボットより運用不可を減らすことを目指して開発されました。技術的にかなり工夫されていました！ みんなの空き家！活用Collection 空き家ってたくさんあるけどどうしていいかわからないって人のために活用事例を紹介するサイトです。14営業日でインフラから構築し、リリースまで行ったみたいです！実際にリリースされているのでぜひ見てみてください。 https://www.homes.co.jp/akiyabank/usecase/ 前だけ向く地図 地図を読むのが苦手な人のためにコンパスのように目的地に向かって前を向き続ける地図です。世界最小スマホ「Jelly pro」を用いて開発されたので、時計のように腕に付けることができます。方向音痴にはとても便利ですね！！ 個展 Webやアプリだけでなく、個展もあります！飾っていたらついつい立ち止まって見ちゃいますね！これまでは一般的なWebサービスやアプリでの出展が多かったですが、こういったアート寄りのプロダクトも出てくるとうれしいですね！ LT大会 最後に最近恒例となっているLT大会もありました。登壇者は5名でどれも盛り上がっていました。 結果発表 BEST SPEAKER賞 新サービスに必要なことは全部アイドルマスターシンデレラガールズが教えてくれた 社員からの投票で最多の投票数を集めたLTに送られる賞です。 テック賞 AIも活用しオンラインで気軽に議論！オンラインブレストサイト 技術的に優れているプロダクトに送られる賞です。 山田賞 LIFULL Vuilders 弊社役員の山田が推薦する賞です。 最優秀賞 みんなの空き家！活用Collection 社員からの投票で最多の投票数を集めたプロダクトに送られる賞です。 最後に 創民祭も6回目を迎え、Webサービスやアプリ以外にも出展の幅が広がってきました。ものづくりの組織として成長していきたいですね！ LIFULLでは、一緒に働くメンバーを募集中してます。 ご応募お待ちしてますので、ぜひみてくださいー！ lifull.com

こんにちは！ デバイスソリューションU開発Gの池田です！ とうとうWWDCも最終日！ 現地からお届けしたいと思います！ 最終日の会場 最終日は木曜日のBash(公式の打ち上げパーティーのようなもの)の夜の後、セッションも少し早い時間で終わります。 そういった状況もあり、会場は人もかなり少ないのかと思っていましたがそうでもなさそうです！ 空席もありますが今日も多くの人がセッション会場に足を運んでいます。 ランチタイムも人がいっぱい！ セッション 最終日は月曜日〜木曜日の4日間より2時間早く終わることもあり、セッションの数は少ないです。 以下のセッションに参加してきました。 Designing Notifications Adding Delight to your iOS App Designing Notifications 通知で提供するユーザー体験についてどう考えどう設計していけばよいかのお話でした。セッションを受けて以下のトピックについてピックアップして書こうと思います。 通知の許可 通知での価値提供 通知の許可 通知の許可で気をつける点は以下3点があがっていました。 初回の起動での通知許可をとらない 通知が価値があることだということを伝える 通知と関連あるタイミングで表示する 例では、通知許可を求めるダイアログ内で、「継続して通知を希望しますか？」というような文章でユーザー自身が通知でのコンテンツ購読を続けるか否かを選べる形で伝える方法が良い例としてあがっていました。 通知での価値提供 通知での価値提供は以下3点に気をつけるとよいとされていました。 意味がある内容で明確な情報を提供する アプリを起動してもらう理由として利用しない 必要な情報だけ通知され、必要でない情報は通知をOFFできるなど設定を適切に設計する 1.2.を満たすシンプルな例として、天気アプリで「もうすぐ雨が来ます。」のような通知が良い例としてあがっていました。 3.については例えばニュースアプリで興味があるカテゴリだけの通知に絞れて、興味がないカテゴリは通知をOFFにできる例などがあがっていました。 Adding Delight to your iOS App ユーザーにより良い体験をしてもらうための様々な内容が話されていました。 外部ディスプレイサポート、レイアウト駆動のUI、起動の高速化、スムーズなスクローリング、ユーザー体験の連続性、様々な便利なデバッグ方法の6点について話をしていたのですが、ここでは起動の高速化、スムーズなスクローリング、ユーザー体験の連続性について触れます。 起動の高速化 話がされていたのは以下3点です。 反応を早く返せるようにする 本当に必要なものだけ利用する 計測して改善する 1.に関しては application(_:willFinishLaunchingWithOptions:) 、 application(_:didFinishLaunchingWithOptions:) 、 applicationDidBecomeActive(_:) で処理をたくさんさせない、大きなデータセットの読み込みを避ける、データベースが整理されているかをチェックするなどすることでユーザーに対して早くレスポンスを返すようにという話がされていました。 スムーズなスクローリング 以下3点について話がされていました。 Time Profiler、Core Animation Instrumentsを活用する メインスレッドの処理を削減する 視覚効果やマスキングは重いので節約して使う しっかり計測すること、画面描画に関わる処理は極力軽くすることが重要とのことでした。 ユーザー体験の連続性 Handoffの活用、Spotlight検索、Siri Shortcuts等も合わせて利用し、ユーザーの体験を連続的に作っていくと良いという内容でした。 今回発表のSiri Shortcutsもどういった形でこれからいろいろなアプリのユーザー体験に繋がってくるのか、今後が楽しみです！ Bash 最後に昨日の夜開かれたBashの様子をお届けし、WWDC 2018のレポートは終わりにしようと思います！ セッション等は18:00まで行われ、Bashは19:00から開催されます。 会場に入りました！奥にはライブが行われるステージが見えます。 会場入り口で絵文字のピンバッジをもらえました！かわいいです！ ドリンクやフードも無料で提供されています。 会場では様々なゲームが野外に設置されています！ 光る的入れや、 エアホッケーや小さいカーリングのようなゲームや、 巨大なジェンガなんてものもドカッと置いてあります！ Bashでは毎年有名なアーティストのライブがあり、会場をガンガン盛り上げます！ 今年のアーティストは「Panic! At The Disco」でした！すごくかっこよく、会場もすごい熱気でした！！！ そんな楽しい時間はどんどん過ぎ、夜もふけていきます。 そんなこんなでいつのまにか終了時間の22:00！会場には余韻を楽しむ人々がちらほら。 こうして楽しく盛り上がったBashも終了です！ 本日で最終日だったWWDCは本当に楽しく刺激のあるカンファレンスでした！！！今回得たものを持ち帰ってしっかりユーザーにいいものを届けていければと思います！！！ 最終日のレポートはここまで！ありがとうございました！！！

こんにちは! 開発Gの又来です！ WWDC4日目！早いもので残すところ今日を含めてあと二日になりました！ 会場限定グッズ 今日は朝早くから会場限定グッズを求めて並びました。 一部グッズを紹介したいと思います。 トートバッグですね。割と生地がしっかりしているので長く使えそうな一品。 MacBook(?)メモ帳です。カラーバリエーションも豊富！ 「これMacBookです」とか絶対言わないでくださいね。つまらないです。  AppleのロゴTシャツです。 すごくシンプルで買い物をしている大半の人が購入していました。 個人的にバックパックが欲しかったのですが、まさかの初日に全て完売したそうです。。くやしい！ AR Great Experience ARKitを使用する際に気をつけるべき箇所を紹介していました。 認識中はアイコンなどをアニメーションさせて「認識中」だということを伝える ラベルなどは近づいても離れてもオブジェクトが同じサイズで見えるようにしてあげる 詳細などはディスプレイの最前に表示させる(AR上ではなく画面にオーバーレイさせる) タップ+ジェスチャーで移動や拡大縮小などの動きを加える 片手で操作できるように心がける この他にも、モデルを作成する際に反射を考慮したテクスチャを貼るようなことについて触れていました。 まるで実際にそこにあるかのようなリアリティのある、金属の光の反射をテクスチャの貼る順番などでうまく表現していました。 今回のiOS12へのアップデートではデフォルトのアプリとして「Measure」が搭載されました。 開発者がより面白いコンテンツを作るためのTipsがこのセッションでは紹介されていたと思います。 認識中のアニメーションの追加やモデルの移動などはユーザー体験の向上に繋がるので挑戦してみたいです！ Life of a Button デザイナー向けのセッションになります。 「トーストを焼く」ボタンをどうやって表現するかについてデモを行いながら触れています。 ボタンの状態 待ち(Ready) 実行中(Making) 終了(Done) この3つの状態をうまく切り分けて表現していました。 それぞれの状態で、 アプリが何をしているのかを人々に知らせる テキストの説明、アイコンで伝える 視覚、聴覚、時間の経過に伴う触覚の変化を見せる を意識してデザインすると良いです。 また、サウンドは音の高さや大きさなど、オブジェクトのサイズを考慮するとより良い体験が提供できます。 全体的な内容として、 物理的な世界がインスピレーションを与えることができる ユーザーインターフェイスは、あなたが見ている以上のものである 物事を試して学ぶ ことが大事だそうです。 ALTCONF WWDC会場横で開催されているALTCONFに行ってみることに！ Marriottのホテルが会場、、、 中はとても綺麗です。会場にはいくつかブースが出ていたのでのぞいてみました。 ノベルティがすごい！！ シャツにペン、シールや水筒まで！！残りわずかだったらしく、この後訪れた方はもらえなかったみたいです。 以上Day Fourの様子でした！ Day Lastに続く！

こんにちは！デバイスソリューションU開発Gの池田です！ WWDCも3日目！中盤戦です！ 現地から中盤戦の様子をお伝えします！ 会場の様子 朝の最初のセッション時間の作業スペースの様子です。 昨日夜は会場広場でパーティーがあったおかげか空席も結構あり、穏やかな朝です。 好きな席を選んで優雅にモーニングを食べながら、作業時間をとることができました。 奥の方にCompanyStoreの行列が見えますがここの賑わいはどの時間も変わらずです。列の長さは2日目になっても変わりません。(閉店直前&遠目から見た感じですが、16:00-17:00頃になると少し列も空いていたように見えました。) 会場の外も人は多くなく空きスペースが見えます。 ここからセッションが終わって空き時間、そしてランチの休憩時間になると人がどわーっと押し寄せます！ これがランチの作業スペースの様子！人いっぱい！ 席が全然とれません！ 外の様子です。 こっちも人いっぱい！どこのスペースもランチタイムはたくさんの人で溢れています。 そんな今日のランチはローストビーフサンドイッチを選びました。このサンドイッチはとっても美味しかったです！ 以下はランチボックスとスプライトやコーラなどのドリンクを提供している野外バーカウンターの様子。 ランチタイムは世界各地から来たエンジニアとコミュニケーションする機会でもあります。 今日はイスラエルから来たエンジニア2名とお話することができました。ARのビル内設備模様替えアプリを見せて頂いたのですが、リアルに現実空間と重ねて建物内の設備を切り替えれるアプリでかなりクオリティと実用性が高く、感動しました。 今回のWWDCで発表されたARKit 2に対応するの？？と聞くと、発表されたばかりなので将来ね。 とのお話でした。 ランチタイムで楽しい時間を過ごしリフレッシュ！午後のセッション&ラボに向かいます！ セッション 本日は今回のWWDC18で発表されたSiri Shortcutsのセッション「Building for Voice with Siri Shortcuts」に参加してきました。 Building for Voice with Siri Shortcuts Siri Shortcutsを利用すればアプリのアクションをショートカット登録し、ユーザーが手軽に日々のルーチンタスクを実行できるようにできます。 また、簡単な呼び出しフレーズを設定してそのフレーズをSiriに伝えると手軽にアクションが実行できます。 紹介されていた例ではスープをオーダーするアクションで、"Chowder Time."とSiriに伝えるとスープの種類をチャウダーに指定してオーダーができるというものでした。 このセッションではアプリのアクション作成とショートカットへの登録、ユーザーに対するレスポンスのカスタマイズ、ショートカットアクション作成のベストプラクティスが紹介されていました。 アクションの作成とショートカットの登録 ショートカットに登録できるアクションは以下2種類です。 NSUserActivity Intents これらのアクションを作成し、それぞれに対応した方法でショートカット登録を行います。 NSUserActivity は、 becomeCurrent() メソッドを呼ぶことでショートカット登録が行われます。 Intentsは、 INInteraction クラスの donate(completion:) メソッドを利用してショートカット登録が行われます。 ユーザーに対するレスポンスのカスタマイズ Intentsを利用するとユーザーへのレスポンスをカスタマイズできます。 カスタマイズのレスポンスとして以下4つのレスポンスが紹介されていました。 ユーザーのアクションに合わせて各種返答をすることができます。 Confirmation Success Information Error ベストプラクティス ベストプラクティスとして、ユーザーに見せる内容(アクションのタイトルとサブタイトル)と呼び出しフレーズの最適化の話がありました。 アクションのタイトルとサブタイトルの最適化 タイトルとサブタイトルはユーザーに良く伝わる内容に最適化する必要があります。例で上がっていたのはクラムチャウダースープを注文するアクションです。 良くないパターンはタイトルが"A clam chowder from Soup Chef"、サブタイトルが"The best way to get soup"となっているパターン。良いパターンはタイトルが"Order clam chowder"、サブタイトルが"To One Apple Park Way"となっているパターン。 良い例の方が明確に何が起こるか(注文すること、Apple Park Wayに到着すること)がユーザーに伝わる内容になっています。 呼び出しフレーズの最適化 呼び出しフレーズを最適化する際は、「短く覚えやすいこと」が重要というお話でした。できれば3語以内で以下のようなワードが良いとのことでした。(日本語の例もあがっていました！) Chowder Time. チャウダーたべたい アクションの作成、フレーズの設定、最適化を行いユーザーにとって最適なアクションのサジェストが進んでいけば日々のルーチンがすごく楽に、楽しくなっていきそうです！ これからのSiri Shortcutsの発展が楽しみです！ ラボ 今日はUser Interface Design LabとSiri Shortcuts Labの2つのラボに行ってきました。 User Interface Design Lab User Interface Design Labでは実際アプリを使って頂きながら様々改善についてのアドバイスを頂きました。 何のために画面内の要素があるのか、質問なども織り交ぜながら理解して頂き、良い！いらない！こうした方がいいのでは？？など率直に建設的な意見をたくさん頂くことができました！ 説明にも絵を描きながら説明して頂きとても分かりやすかったです！ 30分という短い時間でしたがとても濃く楽しい時間でした！ Siri Shortcuts Lab Labで以下聞いた3点について質問と回答です。 【質問】 Custom Intentが使えるようになったが以前のような決まったドメイン以外でも使えるのか？ サジェストは自動なのか、手動で何か行う必要があるか？ サジェストをされる境界値はどういったものなのか？ 【回答】 使える。 自動。時間や場所、頻度によって自動でサジェストされる。 ここについては具体的には教えていただけませんでした。(当然ではあるのですが。) 1.は再確認で聞いた質問だったのですが、これまでメッセージング、支払い、ライドシェア等領域が限られていたSiriがいろいろな分野に解放されたという意味で大きな変更だと思います。 これからサジェストと連携してさらに発展していきそうですね！ 楽しみです！ おまけ 昨日会場を後にしようとしていたら急遽大声で、 「ユニコーンターイム！！！！！」と叫び声があがりました。 ビクッとしてそちらを見るとユニコーンのピンバッジを配っていました！ 表情に癒されます...。 以上Day Threeの様子でした！ Day Fourに続く！！！

こんにちは! 開発Gの又来です！ WWDC2日目！今日もたくさんの収穫がありました。 初日はKeynoteがメインでしたが、今日からはセッションとラボについて触れていきます！ その前にWWDC前日に行ったバッジ交換やApplePark、WWDCでのお土産などを紹介したいと思います。 WWDC前日 私たちは日曜日にバッジ交換に行きました。 前日から会場は賑やかな様子。 スタッフの方々が気さくに話しかけてくれたり、ハイタッチしたり元気いっぱいな様子でした！ お決まりの記念撮影⭐ Apple Park せっかくSan Joseに来ているので、Apple Parkにも足を運びました。 Visitor Centerは一面ガラス張りの建物です、、！ WWDCでバッジを交換してきた参加者の方々が続々と流れてきていました！ 屋上からはオフィスビルがチラリと。 当然ながら一般人は中には入れませんが、そもそも中がどのようになっているのかは未公開です。唯一わかるのは中には池があること。とても気になりますが、ここでは写真を撮ってWWDC初日に備えました。 WWDC 2日目 朝食を頬張りながら今回のWWDCのお土産を見に行くことに。 初日とは違い、スペースも余裕がある感じ。 Company Storeの列はこんな感じ。 この時は「あぁ、建物の中でお土産を買うのか」と思ってました。 残念！まだ中にも列があります。 10人ずつ呼ばれて中に入っていくのでここでようやく買い物開始かと思いきや、、、 最後に長蛇の列が！！ ようやくここでグッズが見える位置まで来ました。(写真右端にうっすら見えるのがTシャツコーナーです。) odwallaゲット！ 買い物が終わると、なにやらodwallaが配布されていることを聞きつけ、早速探しにいくことに あっさり発見！念願の初odwallaです。 ※odwallaとは、スティーブ・ジョブズのお気に入りだったドリンクらしいです。 朝食に飲んだオレンジジュースより美味かったです。 長い買い物を終え、いざセッションへ！ What's New in ARKit 2 今回発表されたARKit 2についての内容になります。 大きく分けて6つの機能が触れられています。 Improved face tracking Environment texturing Image detaction and tracking 3D object detection Persistent experiences Shared experiences その中でも特に気になった、Shared experiencesについてまとめたいと思います。 Shared experiences AR空間の共有。同時に複数人で同じAR空間を見る事ができます。 また、ARKitには現実空間におけるユーザーのデバイスの位置を特定するために使用するすべての空間マッピング情報が含まれており、 このマッピングの情報を使ってAR空間の共有や保存を可能にしています。これが今回追加されたWorldMapです。 WorldMappingStatus WorldMapをキャプチャするには、あらかじめ空間を認識しておく必要があるみたく、今どのくらい取得するのに適した状態かステータスを確認する事ができます。 notAvailable 空間マッピング情報を全く取得・認識できていない状態。 このときに呼び出すと、エラーが発生してしまうので、利用させないような工夫が必要です。 limited WorldTrackingを行うには、現在のデバイス位置の周辺の領域をまだ十分にマッピングしていない状態。 一応この状態でも保存はできますが、読み込み時に位置がずれたりする場合があります。 この状態で保存するのは好ましくないので、もう少し認識させる必要があります。 extending この状態になっていれば、デバイスの位置とそこから見えるシーンをマッピングするためのデータを取得・保存できます。 mapped 空間マッピング情報の取得・認識は十分です。 ここから新たに別のデバイスやセッションで読み込みを行うことで、保存したWorldMapの位置・状態が高い品質で再現できます。 AR Quick Look ARがアプリ無しで手軽に試せるものになります。 読み込んでAR上に表示。平面検出やオブジェクトの移動やスケールの拡大縮小が可能。 Safari メール メッセージ ニュース メモ ファイルアプリ などの基本的なアプリからARでプレビューできます。 ※普通のアプリからでも問題なく利用できます。 また、ウェブ上ではAR対応のバッジが自動表示されたり、ドラックアンドドロップ自動対応していたりと、開発側で意識するようなことが少なくなりました！ Introducing Create ML Playgroundを利用して数行のコードと学習データでモデル作成をして実際にアプリに組み込むまでの基本的な内容でした。 このセッションでは、画像の学習方法を2種類のやり方で説明していました。 Playgroundを利用してドラッグ&ドロップで実行する方法 APIを利用してファイルの場所を指定して実行する方法 ※Playgroundで利用する場合はmacOSをtargetに指定してプロジェクトを開始させてください。importがうまくいかない場合があります。 画像の学習には10枚から対応、学習させる画像データに偏りを持たせないようにすれば問題ないです。 画像サイズに関しても小さすぎなければ利用可能です。(299×299ピクセル以上) こんな簡単に学習用のモデルが作成できるようになるとは思いもよりませんでした。 かなり気軽にできるので皆さんもやってみてください！！ ラボ ARKitラボに行ってきました！ラボではAppleのエンジニアに直接質問ができます。 英語が苦手な私はあらかじめ質問する内容を考えてきてアプリを見せながら話をしました。 ARKit2で出来るようになったことを取り入れた、新しい体験を一緒に考えてくれたりと、かなり親身になって応えてくれました。また、英語が聞き取りにくい箇所についてはメモを書いてもらったりと、大変参考になる機会が得られました。 明日はWWDC中盤戦です！ セッションやラボに参加してフィードバックをしたいと思います！ Day3に続く！

こんにちは！デバイスソリューションU開発Gの池田です。 とうとう始まりました！WWDC1日目！ 現地からレポート記事をあげていこうと思います！ Keynote 本日は朝から並んでKeynoteに参加してきました。 Keynoteは朝10時からのスタートです。 長蛇の列が予想されたので5時起きで会場に向かいます。あたりは薄暗い。 ホテルの近くのGishという駅から路面電車のVTAに乗って会場に到着し、列に並びはじめました。 なかなか進まず40分後...。 やっと会場が見えてきました！ さらに10分後...。 もうすぐです！ 会場入り口ではAppleのスタッフが迎えてくれます！ 踊っていたりハイタッチしてくれたり！テンション高いです！ 会場内では所々歓声が上がります。熱気が高まってきました！ 会場に入るとコーヒーやパンなど無料で提供されています。 中には白いボールのような形の食べ物もありトリュフチョコかと思ってパクッと一口。 全然甘くない。。😩ただのおしゃれに丸められたバターでした。。。 気を取り直してコーヒーで流し込み、パンとオレンジジュースもぐいぐい飲み、朝食は完食しました。 あとはKeynoteに備えるだけです。 そしてそこからなんだかんだ待つこと1時間超...。 とうとう！Keynoteの会場に入りました！ アプリアイコンがいっぱい並んで紹介されています！ Keynote始まりました！ ティム・クックさんです！ iOS、watchOS、tvOS、macOSと発表されていきました。 iOSはAR(拡張現実)、Siri、ML(機械学習)の進化が発表、Memojiも発表されましたね！ watchOSは、Activityの対決モード、ワークアウトの種類追加、トランシーバー機能追加など。 tvOSは、サウンドの向上、新しいランドスケープ画像の追加など。 macOSはダークモードの追加、Finder、iPhoneと連携したContinuity Camera機能などが発表されました。 AR、Siri、MLについて触れたいと思います。 AR(拡張現実) ARでは複数人でAR空間を共有できる機能が発表されましたね。 会場内では実際にデモアプリを使ったゲームができるエリアがありました。 現実には何もない木目のまっさらなテーブル上にARの積み木とスリングショット砲台が出現し、相手の砲台にボールを当て3個倒したら勝ちというゲームで、実際体験しましたがすごく面白かったです！ はたからみるとただの木目のテーブルにiPadを向けて真剣にうろうろする大人がいるという。異様な光景です。 Siri Siriは日課を分析して次の行動をおすすめしてくれる提案機能や、カスタムの言葉を登録しておけば複数のアプリでの作業を自動的に順序だてて実行してくれるショートカット機能が発表されました。 例えばTileアプリをよく使っていて、TileアプリからSiriにショートカット機能を登録しておくと、Siriに「I lost my keys」と伝えると自動でTileアプリを開いてくれるなど。 メッセージに合わせたアクションを自動で実行してくれます。 ML(機械学習) ML関連ではモデルをXcode上で作成できる「Create ML」が発表されました。 MLのモデル作成はPlayground上でできます。 画像の識別モデルを作成する場合は、画像をPlayground上にドラッグ&ドロップするだけで自動で学習し、CoreMLで利用できるモデルが素早く作成されます。 学習にかかる時間も少なく、できるモデルの容量も抑えられ、Playgroundで手軽に作れます。 デモを見ていて、CoreMLを利用した画像識別機能を作成する際はかなり便利に使えると感じました。 今後機械学習分野はiOSの中でもさらに発展していきそうですね。 Firebase party at WWDC18 本日はWWDCが終わったあと周辺イベントで開催されていたFirebase Party at WWDC18に参加してきました。 シアトルから来たエンジニアと少し話しました。 今年初参加で来られたそうです。元々Web系のバックエンドなどやられていてエンジニア歴は8年。iOSを始めてから3年とのことでした。 なんでiOS始めたの？？と聞くと、Webでサービス提供しているとブラウザの影響などで考えなければいけないことが多く、iOSは統一してサービスを提供できるためそこが魅力と感じてiOSデベロッパーになったそうです。 なかなかこういう場でないと出会えない方々と出会え、話しができたのが貴重な機会でした。 明日からは本格的にセッション、ラボが開催されます。 しっかり吸収し、アウトプットに繋げていきたいと思います！ Day Twoに続く！！！

エンジニアの鈴木 (a.k.a すずけん )です。 今回、AWS Summit TOKYO 2018 で開催された「 AWS Secure Code Contest - DevSecOps の実践を通じたチーム対抗静的コード解析バトル - 」に参加し、🏆 優勝 🏆することができました！！ AWS Secure Code Contest 午前の部の優勝チーム、sushisecopsのヒーローインタビューです！得意分野を分担して見事優勝を勝ち取りました😆 優勝チームには一万円分のAmazonギフト券を差し上げました🎁 午後の部もまだ参加可能。ご興味のある方は14時半迄に新高輪3階の天平まで！ #AWSSummit #devops pic.twitter.com/7Zfgnc9V6x — アマゾンウェブサービス (@awscloud_jp) 2018年5月31日 この記事では、 このイベントの振り返りと今回の学び について共有したいと思います。 コンテストの内容については本記事では触れません が、良い結果を残すためのヒントになるようなオープンな情報には触れています。 AWS Summitの楽しみ方のひとつとして、このようなイベントに参加してみようと思う人の参考になれば幸いです。 AWS Secure Code Contest 参加動機 まずはじめに参加動機からです。端的に２つ理由がありました。 自分の力を試したいという気持ち このタイミングでしか楽しめないことがしたい 一つづつ見ていきます。 前者に関しては、「他社のエンジニアとの共同作業において普段自分が行っていることが効果的なのかを確認したかった」という側面と、「自身の市場価値の確認」という意味がありました。 つまり、 現在の自分の立ち位置を見つめ直す機会にしたい という目的です。 後者に関しては、 AWS Summitの楽しみ方をひろげる という目的がありました。 昨今のイベントにおいてセッションが動画で公開されるのはデファクトになりつつありますし、自分がやるより遥かに早いタイミングと精度でブログにまとめてフィードバックしてくださる方もたくさんいます。 つまり、情報の取得を目的とした点においては、特別な理由(イベントの雰囲気を肌で感じるなど)がない限り、非同期で済む場合が多くあります。 逆に、ワークショップやハッカソンなどはその場その瞬間にしか存在していません。 AWS Summitをより楽しむ為に、 非同期では味わえない経験をしたい という目的です。 事前準備 じゃあ、コンテストを最大限楽しむためにどのような準備をしたのかというと、「問題を予測する」、「やらないことを決める」の２つです。 コンテストという性質上、 あわよくば優勝🍣したい という気持ちがありました。 「問題を予測する」為に最初にしたことは情報収集でした。といっても、やることは単純で今回のワークショップのページを確認しながら、関連しそうなワード（aws devsecops）でググっただけです。 すると、AWS のDevOps系のブログが引っかかりました。読んでみるとなんとなく今回のワークショップに近そうな雰囲気があります。きっとこんな感じで出題されそうだなと予想し、一旦ここで紹介されているgithubのサンプルコードを実際に動かしてみるところまでやっておきました。 aws.amazon.com 次に、「やらないことを決める」です。募集要項やFAQを参考に、コンテストに必要そうなスキルと自分のスキルセットを照らし合わせて、やらないことを決めました。 具体的には、「pythonについて勉強はしない」と決めました。 募集要項に、「簡単な Python のコーディング能力が必要」とありますが、正直どれくらい必要なのかわかりません。ですが、FAQには「基本的なプログラミング言語の理解と Python の理解があれば問題ございません。」と書いてあります。 自分はpythonが書けません。 求められるのものとしては、単純なコードなら他の言語の知識を生かしてなんとなく読み込める状態であればいいと理解し、pythonについて時間を割くことはしないと決めました。 当日 当日、弊社エンジニアの磯野も参加するとのことで、待ち合わせをし一緒に会場に向かいます。 会場で受付を済ませ席に案内されると、すでに2名着席しており「あれ？なんか見たことがあるぞ」と言われました。 その方は以前 re:Invent 2017のGameDayで別チームで参加されており、re:Partyでお話させていただいたことがあり、すでに面識がありました。 昨年参加したGame Dayについてのレポート: AWS re:Invent 2017 参加レポート Day 2 - LIFULL Creators Blog また、もうひとりの方も、弊社と合同勉強会を開いたこともあり、一昨年のre:Inventにも行かれたとのことで共通項がありました。 もうこの時点で、かなりフレンドリーな状態😊 です。 同じ経験をしているという共通項がコミュニケーションを円滑にしてくれました。 コミュニケーションは日々も大事ですが、このような瞬発力をもとめられるワークショップでは更に重要だと考えているので、 お互いの意見がしっかり言い合えるような雰囲気が醸成されたチームにジョインできたのは、運がよかったな と思います。 お互いについて自己紹介したあとは、コンテストが始まるまで終始リラックスした雰囲気で過ごせました。 主催者側からチーム名を決めてくださいとのアナウンスがあり、「何がいいっすかねー？」「"hogefuga"でどうっすか？」「www」「エンジニアといったら🍣か🍕ですよね？」「中トロはどうですか？」「寿司食いたいなぁー」「じゃあ、今日のイベントにちなんで、 SushiSecOps はどうですか？」みたいな流れで、ふわっとチーム名が決まりました。 いよいよ、コンテストが始まります。 主催者からコンテストの趣旨説明があり情報公開がされました。各自およびチームで設定が始まります。 このとき自分たちのチームでまず行ったのは、課題に対するアプローチ方法の検討です。 はじめは、課題一つに対して、ひとり張り付こうみたいな流れがあったのですが、「１課題に対して２人１組で取り組んだほうがハマった時に対処が早くなると思うので、そうしたい」と自分から提案し採用されました。これは、昨年のGame Dayで得た教訓を有効に活用できた瞬間でした。 あとはもう全力で問題文を読み込み、目の前の課題に集中するのみです。 時折、運営の方が「いまトップですよ！」など励ましの言葉を掛けてくれました。正直スコアに関しては気にしている余裕がないほど課題の量と理解に悩まされました。 終盤、他チームに追い抜かれたものの、最後の最後でわずか0.3ポイント差で接戦を制しました。 この画像はコンテスト終了後、運営の方に掲載許可を頂いています あっという間の2時間でした。 振り返り 勝敗が全てとは思いませんが、 優勝できたことは素直にうれしい😊 です。 ですが、結果を出せたのは 良いチームメンバーに恵まれたなど、運の要素も強かった と思います。 チームメンバー各自の能力が高いに越したことがないのですが、それはマストではないと思います。 チームとして自分の価値を最大化するために、 どのような貢献ができるのかを考え実行できることが大事 なのではないでしょうか。 また、限られた時間でのアウトプットを出すために、GameDayでの経験がとても役に立ったと実感できたのは良い経験になりました。 まとめ 今回の経験から、個人的な学びもたくさんありました。その学びの中から強いて２つほど挙げてまとめとします。 1. 勝敗は運の要素も強いが、準備をしておいて損はない 勝負ごとに運の要素はありますが、勝率に関しては自分で工夫できる余地は意外とあるのかなと思います。 事前にできることを「自分でしっかりと考えて準備しておく」という、すごくシンプルなことがなかなかできなかったりするものです。 自戒を込めて、次に生かしたいと思います。 2. 打席に立つことの重要性 当たり前ですが、バッターボックスに立たないと、アウトになることすらできません。 このようなコンテストに参加することは、普段得ることができないエンジニアとしての経験として良いものになると思います。 また、GameDayという打席に立ったからこそ、今回の結果につなげることができたので、点が線につながったと感じることができました。 これからも、積極的に打席に立って楽しんで行きたいと思います。 最後に、一緒のチームで戦ってくれた、田中さん・福井さん・磯野さん、および運営の方々へ リスペクトを込めて、ありがとうございました！！！