こんにちは、LIFULLの人事 水村です。 本日は、私が日頃いろいろと相談相手になってもらうこともある、LIFULLのシニアデザイナーの一日に密着したので、ご紹介したいと思います！ 紹介するのは、中途入社して今年で5年目、現在はLIFULLのシニアデザイナーを務める山田和代です。 ―仕事内容は？ 前職まではデザインプロダクションで広告、web、媒体問わずクライアントワークを請け負っていました。LIFULLでは主に、LIFULL HOME'S 賃貸物件領域のサービスデザインから販促ツールの制作などに関わっています。直近では、タレントを起用したプレゼントキャンペーンのプロジェクトに参加したりしました。今現在は、目下LIFULL HOME'SのUI改善施策に取り組んでいます。今日は、その打ち合わせもありますよ。 ーそうなんですね！　よければ、あとでちょっと参加させてください。 ーちなみに、今日は「1日密着」ということなのですが、山田さんの朝は？ 自宅を8時半くらいに出て、会社最寄の半蔵門駅から歩いて通っています。今の時期は、出社途中に皇居周辺の桜が見えて、とっても爽快な気分で出社していますよ～ 千鳥ヶ淵。LIFULL本社の先にある春の風景です。 半蔵門駅から千鳥ヶ淵に向かって2分程歩くとLIFULL本社入口です。 ―今の季節、めちゃくちゃ気持いいですよね。 　 半蔵門は外国人の方も多く、いろいろな面で五感を刺激される環境ですよね。　 ―ではでは、今日一日よろしくお願いします！ 　　　　　　　　　　 　　　　　　　　　 　　　　　　　　　　　　　 　　　　　　　 10:00〜　メール、チャットツールなどのチェック 11:00〜　先日ヒアリングをした案件の要件整理 12:00〜　同じグループに所属する若手デザイナーへのフィードバック 写真左が山田。真剣な表情です... 13:00〜　社屋1階にある「LIFULL Table」でランチ 焼き魚、カレーなどの馴染みある定食から、玄米や野菜を使ったヘルスコンシャスなメニューまで。 バランスの取れた食事を毎日楽しめるミックススタイルのデリ食堂。 14:00〜 進行中案件のデザイン作業 ―あ、賃貸の仕事じゃないですねこれ。 そうなんです。LIFULLのデザイナーは自分が日頃担当する仕事以外に、「横断案件」といってLIFULLブランドに紐づく多様なプロジェクトのデザインを担当することになっています。 15:00〜 先日リリースしたプロジェクトの振り返りミーティング ―振り返りミーティングって、具体的にどんなことを話しているんですか？ 私がメインで担当しているLIFULL HOME'SのUI/UX向上プロジェクトでは、プロジェクトごとにチームを組んで進行するんですが、私が施策の効果そのものと同じくらい重要視しているのが、チームの成長とムードの醸成です。 プロセスでどんな点がよかったか、あるいは問題があったかを都度ふりかえって改善策を出し実行することで、チームの開発スピード、何より士気やムードをあげて、より早く利用者に価値を提供できるようにしたい、と考えています。 水村さんって、LIFULL HOME'Sのようなポータルサイトで住まい探しして、悲しい経験したことって、ありますか。 ―あります！ 残念ながらまだまだ、ありますよね...。それぞれの人の「暮らし」に大きく影響するであろう住まい探しで、ポータルサイトが利用者の「邪魔」をしちゃいけないと思うんですよね。邪魔してる場合じゃないっていうか。 LIFULL HOME'Sは、賃貸物件、中古物件、新築マンション、新築戸建てなどなど、さまざまな「住まい」の情報を提供していますが、一貫して誇っているのが、その掲載物件数の多さです。より多くの選択肢から、自分が実現したい「暮らし」をかなえてくれるような住まいに出会っていただきたい。そのために、営業、開発チーム一丸となってサービス向上に取り組んでいます。 さらに、私たちが提供したいのは「掲載物件の多さ」だけではないんですよ。LIFULL HOME'Sでは、最近「したい暮らしに、出会おう。」をテーマにした 「 LIFE LIST 」 というサービスを立ち上げたんですが、これは通勤時間やエリア、間取りなどのスペック情報から探す従来の物件探しではなく、その人のしてみたい“暮らし”から、それを叶える物件をさがすことができる新しいサービスです。 このサービスにも、LIFULLが掲げるコーポレートメッセージ 「 あらゆるLIFEを、FULLに。 」 の文脈がストレートに受け継がれています。今日の昼に私とミーティングをした、同じグループのデザイナー・大信田さんが立ち上げ時からデザインを担当し、それから一貫してUI/UX改善も担当しているんですが、「LIFE LIST」は記事の内容が本当にバラエティに富んでいるので、ぜひより多くの方々に見ていただきたいです！ ―！！　住まい探しで泣いたあの時の私に教えてあげたい... 新しい暮らしに想いを馳せて住まい選びをする人が悲しむのではなく、幸せな気持ちになれるといいですよね。 ―...そういえば、山田さんはクリエイティブ本部の所属ですが、自席は賃貸事業部のフロアなんですね。 （ LIFULLでは、部署ごとにフロアがわかれており、クリエイティブ本部のデザイナーの多くが現在は7階に自席を設けている中、山田の席は賃貸事業部のいる4階です。 ） 所属は CCOの川嵜 を中心にした「クリエイティブ本部」という名称の、「LIFULLのデザイン」を一手に引き受け統括する部署ですが、私は通常業務でLIFULL HOME'Sの賃貸物件領域を多く引き受けているので4階にいます。そのほうが営業さんや、他の開発スタッフと綿密にコミュニケーションがとれるので。 賃貸のチームは皆個性が強いけれど、互いを尊重するメンバーばかりです。接していて本当に毎日楽しいし、刺激を受けます。LIFULLが掲げるコーポレートメッセージ 「 あらゆるLIFEを、FULLに。 」 とは、あらゆる人の人生やその多様性を尊重するようなものだと私は理解しているんですが、その考え方が、人材採用にも反映されているのかなーと感じてます。 16:00〜 フレーム/プロトタイピング作成 これは、LIFULL HOME'Sでもとても重要な機能のUIなのですが、訪れた利用者にとって誤解がないように、期待に応えるものになるように、企画者やエンジニアと細かく相談しながらデザインをしています。 ―１つ１つのデザインに、ユーザの暮らしを変えるまでのストーリーや想いが込められているんですね。 ―（その後、もくもくと山田はデザインをしていった...） 19:30頃　退社 今日は、最近クリエイティブ本部に入社したデザイナーの歓迎会があるのでこのあたりで退社です！ 以上、デザイナー山田の一日でした！　 彼女は普段から勉強熱心で、社外の勉強会などにも積極的に参加したり、自分でデザイナー向けのイベントを企画・開催したりしています。 デザインのノウハウとか聞けたら～と思って軽いノリで1日密着してみましたが、そこには ユーザーと、サービスと、チームと真摯に向き合い続ける デザイナー山田がいました。 今回ご紹介したようなLIFULLのクリエイティブのこと、デザイナーのことについてもっと知りたい、と感じていただけた方は、ぜひこちらのイベントにお越しください！ lifull.connpass.com お読みいただき、ありがとうございました！

こんにちは、LIFULL HOME'Sでアプリディレクターをしているスケガワです。 今回は、新しくアプリディレクターやアプリ担当者になった方が「知ってたほうが良さそう！」と思う基礎知識について書いていこうと思います。  記事を書こうと思ったきっかけ そもそも「アプリディレクター」ってどんな仕事？ １．組織図とチーム体制、ポジション（職種）への理解 ２．アプリ市況 ２－１．基礎を押さえる AppAnnie アカデミー Playbook for Developers （アプリで成功するには） グロースハックジャーナル ２－２．AppleとGoogleの動向を追う ２－３．最強は勝手に情報が集まってくること ３．基礎的なマーケティング知識 ４．基礎的なプランニング知識 ５．他職種についての理解 ヒューマンインタフェースガイドライン マテリアルデザインガイドライン iOSデベロッパードキュメント Androidデベロッパードキュメント ６．アプリディレクターが持つべき姿勢 ６－１．チームで1番全力であれ ６－２．ミーハーであれ ６－３．シニカルであれ ７．まとめ   記事を書こうと思ったきっかけ 未来の新人アプリディレクター向けに良い情報を残したい！と考えたためです。 私は2014年にLIFULLに新卒入社して、1年目からアプリディレクター（社内的な職種はサービス企画職）としてお仕事をしています。もうすぐ丸5年になります。 学生時代にWebやスマートフォンアプリの開発に関して何の知識や経験もなかったどころか、「ディレクターってなに？」「マーケティングってなに？」な状態だったので、アプリやWebサイトの開発の最前線である程度仕事ができるようになるまで、結構苦労しました。 今回「これからアプリディレクターやアプリ担当者になる人」が最高のスタートを切れるよう、「新卒当時の自分にアドバイスするならどうする？」という視点で書きました。 最後までお付き合いいただければ幸いです。  新卒1年目の私。イキイキしてる。 そもそも「アプリディレクター」ってどんな仕事？ アプリ開発や運用の現場において、チームの舵取り役や潤滑油となる職種です。具体的には 改修施策のプランニング プロジェクトのディレクション 担当プロダクトのモニタリングと分析 社内外のステークホルダーとの調整 などを担当業務とする職種になります。 ただし、他社さんの話を聞くと、いわゆる「アプリディレクター」や「アプリ担当者」と一口に言っても組織によって業務内容は様々。特に事業会社の場合、一概に「これがディレクターや担当者の業務領域だ」とは言い切れないのも実情です。   １．組織図とチーム体制、ポジション（職種）への理解 まずは自分が配属された組織やチーム、職種が「なぜ存在するのか？」を理解してください。この理解を通して下記のようなことが見えてきます。 どんな知識やスキルが業務に必要なのか？ 最終的なアウトプットが何なのか？ もし自分で考えて検討がつかなければ、必ず上長や先輩に確認をしましょう。 私自身は先述の通り、入社時に「ディレクターってなに？」な状態だったので、明後日の方向に努力をしてしまうことも多くありました。適切に努力をして、効率よく業務を進めていくためにも、組織やチーム、職種への理解は押さえておきましょう。   また、特にアプリディレクターを始めとする企画・進行管理系の職種では、『組織図の理解』をしっかりとしておくのが個人的におすすめです。 「どこの部門が、何を目的に、どんな業務を行っているのか？」がわかると、社内外の折衝・交渉を行う際にとても機能します。どんなコミュニケーションにも当てはまりますが、「相手がされて嬉しいこと」と「相手がされて嫌なこと」を理解しておくことは重要です。 もう一歩踏み込むと「組織は戦略に準ずる」ので、組織図やチーム体制を理解することは、会社やチームの戦略を理解することと同義です。戦略的思考はアプリディレクターにとって大きな武器となるので、そういった観点からも、組織（戦略）への理解を深めておいて損はないでしょう。    ２．アプリ市況 アプリディレクターは、アプリ開発チームという船の船頭です。アプリディレクターがアプリの市況を把握していないのは、船頭が天気を把握してないようなもの。しっかりと最新の動向を追っていくべきです。 また、組織観点で言うと、アプリ担当者は『会社とアプリ業界をつなぐ窓口』とも言えます。嘘でも「会社の中で、自分が1番アプリに詳しい」という立場をとるべきです。 下記にポイントを3つまとめました。参考にしてみてください。 ２－１．基礎を押さえる まずは大前提となる基礎知識を身に着けていきましょう。 前提が理解できているとチームメンバーや同業者とのコミュニケーションのスピードも上がりますし、市況に対して鼻が効くようになります。 下記３つのメディアに一通り目を通すことで、ある程度網羅することができると思うので、まずは１つだけでもいいので、少しずつ読み進めていくことをおすすめします。 AppAnnie アカデミー https://www.appannie.com/jp/academy/ AppAnnieは世界中のアプリ開発者が利用しているマーケティングツールで、AppAnnieが提供している記事やレポートはアプリ業界のデファクトスタンダード的な立ち位置になっています。AppAnnieアカデミーでは、基礎的な内容を学べるレッスンが複数用意されているので、一通り目を通しておくことをおすすめします。 Playbook for Developers （アプリで成功するには） https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=j Googleが提供しているアプリで、アプリ運営の基本的な考え方が学べます。Androidアプリ寄りの内容ですが、iOSアプリにも十分応用できる考え方が多いです。 グロースハックジャーナル https://growthhackjournal.com/ アプリマーケティングツールの『Repro』が運営しているメディア。アプリのグロースハックに関するメディアだと質・量のバランスが最も良いと感じています。   ２－２．AppleとGoogleの動向を追う アプリ業界におけるプラットフォーマーであるAppleとGoogleは、定期的に新技術やガイドラインについて発信しています。彼らの基本方針や戦略を理解することが、アプリ業界の最前線、ひいては未来を見通すことに役立ちますので、Apple・Google関連のニュースは積極的にキャッチアップしましょう。 まずは最も大きなカンファレンスであるWWDCとGoogle I/Oの発表内容を漁ることから始めても良いと思います。2019年もそれぞれ開催されますので、ぜひチェックしてみてください。 developer.apple.com events.google.com   ２－３．最強は勝手に情報が集まってくること 自分から情報をとりに行くことも重要ですが、もっと重要なことは自分に情報が集まるように環境を構築しておくことです。 TwitterやFacebookなどのSNSで有益な情報を流してくれる人をフォローしたり、チーム内のSlackやChatWorkで情報をやり取りする文化を醸成したり、キュレーション系のサービスを利用するのも良いと思います。   ３．基礎的なマーケティング知識 アプリはあくまで手段です。サービスとユーザーとの接点の1つにすぎません。アプリだけで部分最適にするのではなく、サービス全体を俯瞰した上で全体最適がされている状態が望ましいです。 マーケティングの基礎的な知識があると、サービスを俯瞰的に分析し、中長期的な視点で施策を打っていく戦略的な思考が養われます。アプリディレクターはプロダクトオーナー的な立ち回りも求められますから、ぜひ身につけておきたいですね。 有名どころですが、『 ＵＳＪを劇的に変えた、たった１つの考え方 』は良著です。わかりやすくマーケティングの基礎をインプットできるので、ぜひ手にとってみてください。 USJを劇的に変えた、たった1つの考え方 成功を引き寄せるマーケティング入門 作者: 森岡毅 出版社/メーカー: KADOKAWA/角川書店 発売日: 2016/04/23 メディア: 単行本 この商品を含むブログ (5件) を見る   よりプロダクト開発の実務に即したの知識を得たい場合には、『 A/Bテストの教科書 』もおすすめです。A/Bテストという冠はついていますが、KPIマップやPDCAの回し方など 、アプリやWebサイトの成長させていくために必要な考え方についても触れられています。  A/Bテストの教科書 作者: 野口竜司 出版社/メーカー: マイナビ出版 発売日: 2015/12/09 メディア: 単行本（ソフトカバー） この商品を含むブログ (1件) を見る     ４．基礎的なプランニング知識 アプリを継続的に成長させていくためには、質の高い施策を沢山考える必要があります。アプリディレクターの業務の中でも最もコアに近い領域になるため、ここが苦手だとアプリディレクターは務まりません。 施策を考える際には、プランニングの知識があると非常に生産的です。ロジカルに考える部分はもちろん、発想やひらめきの部分についても先人たちの残してくれたフレームワークや考え方を活用することで、質と量の両面で良い結果が得られます。積極的に先人たちの知識を借りましょう。 『 ブレイクスルー ひらめきはロジックから生まれる 』は、プランニングの基礎知識をわかりやすく学べる良著です。小手先のフレームワークというよりか、より本質的な考え方や姿勢について書かれているため、一読してみることをおすすめします。 ブレイクスルー ひらめきはロジックから生まれる 作者: 木村健太郎,磯部光毅 出版社/メーカー: 宣伝会議 発売日: 2013/04/04 メディア: 単行本（ソフトカバー） この商品を含むブログ (4件) を見る     ５．他職種についての理解 ＋αの要素にはなりますが、一緒に仕事をすることが多いデザイナーさんとエンジニアさんの考え方についても押さえておくとチームでの仕事が捗ります。 本当は実際に自分の手を動かして体験してみるのが理想ですが、まずは何となくでいいので公式ドキュメントを眺めることから始めてみると良いと思います。 それぞれの基礎的なドキュメントのリンクを貼っておくので、早速挑戦してみてください。 ヒューマンインタフェースガイドライン https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/ iPhone・iPadアプリのUI / UX デザインのガイドラインをまとめたドキュメントになります。日本ではiPhoneのユーザーシェアが高いため、Webサイト等もこれに準拠してデザインされていることが多いですね。 マテリアルデザインガイドライン https://material.io/design/ GoogleのUI / UX デザインのガイドラインをまとめたドキュメントになります。主にAndroidアプリを想定して作成されたものではありますが、iPhone・iPadやWebサイト等のUI / UX デザインにも活用できます。 iOSデベロッパードキュメント https://developer.apple.com/jp/documentation/  iOSアプリの開発者向けドキュメント。正直私もちんぷんかんぷんなものも多いですが、気になったものを斜め読みするだけでも、良いと思います。 Androidデベロッパードキュメント https://developer.android.com/docs?hl=ja  Androidアプリの開発者向けドキュメント。iOSアプリと比較すると情報がまとまっているので参照しやすいと思います。     ６．アプリディレクターが持つべき姿勢 基礎知識とは少し異なりますが、アプリディレクターが持つべき姿勢についても書きます！いよいよ暑苦しくなってきましたが、あともう少しで終わるので、どうかお付き合いください！ ６－１．チームで1番全力であれ 最も大事な姿勢です。 アプリ開発の現場においてはチームプレイが基本。特にアプリディレクターはデザイナーさんやエンジニアさんなど、自分以外のメンバーに活躍してもらって、初めて価値が発揮されます。どれだけ改善施策を考えても、実際にアプリをリリースしなければ絵に書いた餅でしかありません。デザイナーさんやエンジニアさんに『気持ち良く動いてもらえる』ことは、良いディレクターの必須条件でしょう。 そんな時に有効なのが、『チームで1番全力』であることです。 あくまで私の経験則ですが、チームで最もPJに時間を割いている、チームで最も施策のことを考えている、チームで最もプロダクトを愛している、そんな姿勢のディレクターはメンバーからも信頼されますし、チームの原動力になります。 アプリディレクターに必要なものは挙げればキリがありませんが、『チームで1番全力』であることに知識やスキルは不要です。誰にでもできることだからこそ、絶対に外してはいけない姿勢だと思います。 ６－２．ミーハーであれ 先述の通り、アプリ業界のトレンドは移り変わりが激しいです。人によっては「節操がない」と感じてしまうくらいグルングルン変わります。そんなトレンドをしっかりとキャッチアップしていくのがアプリディレクターです。発生する波には全部乗るくらいの勢いでトレンドに乗っかってください。 ミーハーというと聞こえは悪いですが、人並み以上の好奇心と挑戦心がなければなかなかできないことです。自信を持ってください。 ６－３．シニカルであれ 「ミーハーであれ」と全く逆のことを言っているようですが、プロダクトをブラッシュアップするためには、既存のプロダクトを批判的に捉え、課題を抽出・分析することが重要です。何度も言うようにアプリディレクターは開発チームの船頭・舵取り役ですので、チーム内で率先して役割を担ってください。 特に自分自身が「このPJを進めたい！」「この施策を必ず成功させたい！」という時はどうしても盲目的になりがちですから、自分自身のこともシニカルに捉えられるよう、頭の片隅で常に意識していたいですね。    ７．まとめ アプリディレクターは、担当アプリにおいては「小さな経営者」のようなものです。ビジネス的視点からテクノロジーやデザインの視点まで、求められる知識やスキルも非常に多岐に渡ります。ちゃんと押さえようとすると、それなりに大変です。 それでも担当アプリを成長させて、ユーザーの利益や会社の成長に貢献できるのは単純に楽しいです。私は、よく育成ゲームに例えるのですが、毎日楽しくプレイさせてもらっています。 また、アプリというプロダクトの特徴なのですが、アプリストアにユーザーから直接「LIFULL HOME'Sのおかげで良い家が見つかりました！」とか「〇〇の画面が使いづらい…」といったレビューをいただけるのはとても嬉しく、やりがいがあります。 ※下記、私の担当のアプリ達です。ぜひ使ってみて、感想をレビューしていただけると幸いです お部屋探しならライフルホームズ 不動産物件検索アプリ LIFULL Co., Ltd ナビゲーション 無料 今回挙げた内容は本当に基礎的な内容ばかりですが、アプリ領域以外にも活用可能なものも多いので、知識・スキル獲得の下敷きとして参考にしてもらえれば幸いです。  それでは！ アプリディレクター歴5年の私。イキイキしてる。

こんにちは！LIFULLでエンジニアをしている市来（いちき）です。 2019/02/21（木）に弊社にて開催させていただきました、「Ltech#5 LIFULL HOME'S 機械学習Night2　若手エンジニアが語る機械学習事例」についてレポートいたします。 Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。 特定の技術に偏らず、様々な技術の話を展開していく予定です。 Ltech#5 LIFULL HOME'S 機械学習Night2　若手エンジニアが語る機械学習事例 Ltech #5は弊社若手エンジニアにLIFULLにおける機械学習事例を語ってもらいました！ 勉強会の様子 機械学習のための分析基盤の構築 現在構築中の機械学習のための基盤について、実装したことの紹介とこれからの課題について語ってもらいました。 機械学習を用いた間取り画像の自動解析 人間の骨格認識技術を応用した、間取り図を解析して3Dモデルを作る事例について紹介しました。 説明可能な機械学習～チャットボットと価格査定を通して～ 説明可能な機械学習という切り口から、自身が携わったチャットボットと不動産価格査定の事例について紹介しました。 各発表後の質疑応答では、深く踏み込んだ質問や鋭い質問も多数いただき、非常に活発な会となりました。 また、当日の発表資料については一部公開しておりますので、ぜひご覧ください。 lifull.connpass.com 懇親会の様子 今回もLtech名物の「からあげ」をご用意いたしました。 からあげを食べ比べながら、機械学習の話題を中心に情報交換ができ、閉場ギリギリまで盛り上がりました！ ご参加いただきました皆様、ありがとうございました。 AI戦略室からのお知らせ！ 今回登壇したエンジニア3名が所属するAI戦略室では、今年経験豊富なアドバイザーをお迎えしました。 LIFULL、AI戦略室エグゼクティブフェローに 矢野 和男氏が就任 | 株式会社LIFULL（ライフル） 鹿内 学さんがLIFULL AI戦略室 データサイエンスパートナーとしてジョインしました！ - LIFULL Creators Blog なお、機械学習エンジニアの仲間も募集しています。 hrmos.co また、2019年3月4日-6日に長崎で開催される「 DEIM2019 」には協賛企業として参加を予定しています。 様々な方々と連携しながら、LIFULLが保有するビッグデータに機械学習を適用し、住まい探しのユーザー体験を革進するような取組みを続けていきますので、どうぞご期待ください！ 最後に Ltech#5のテーマとして、「LIFULLならではの勉強会にしよう」と弊社での実例を交えた勉強会とさせていただきました。 実例を交えた勉強会ということもあって技術についてもさることながら、実際のプロダクトに活かすための質問や意見を多数いただくことができ、ご参加いただいた皆様の身になる勉強会ができたのかなと思っております。 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは！　 木村 修平@LIFULLジンジニア(エンジニア人事) (@kimkimniyans) | Twitter です。 この度、2018年10月に新設したAI戦略室に、鹿内学さん（ facebookアカウント ）がデータサイエンスパートナーとして協力いただけることになりました！ 鹿内さんは現在、株式会社シンギュレイトのChief Scientific Officer（CSO）として活動されており、これまでには パーソルキャリア株式会社 でデータサイエンティスト支援サービスの Data Ship や、ダイレクトリクルーティングサービスの ミイダス のプロジェクト統括をされています。 ピープルアナリティクスに先駆的に取り組まれる日本でも有数のデータサイエンティストです！ LIFULLのAI戦略室では、AIで住み替えの次の体験を探求するため、様々なことに取り組んでいます。 具体的には、 主に不動産領域においてデータサイエンスでの４つの見える化を進めています。 * 物件情報（スペック情報） * 物件価値の透明性（価格相場、価格査定） * 住宅・不動産性能評価 * 不動産会社やスタッフ評価 鹿内さんには、 こういったミッションをクリアするための組織や業務をさらにブラッシュアップしていくアドバイザリー業務で協力いただきます。 鹿内さんより意気込みを 不動産は、「一所懸命」という言葉があるような古くからの価値。 いまになると、賃貸はもちろん、民泊などで新しい価値も育ちつつあります。 そんな、古くて新しい価値をとりまく不動産のデータ、それに関わる人・才能との仕事を楽しみにしてます！ LIFULL HOME'Sデータを研究開発用に公開もしています。 自分がハブになって、他の産業との統合的な新しいデータ活用も考えられれば嬉しいですね。 一緒にデータサイエンスで革進していくエンジニアを募集中！ 鹿内さんやAI戦略室のエンジニア達とデータサイエンスで世の中を革進していきませんか？ 興味のある方は以下をご覧いただき、エントリーしてください！カジュアル面談も随時やってます！ hrmos.co hrmos.co

こんにちは！たからべです。通常業務ではデザインを担当しています。 今回の記事は、全くデザインの話ではありません。 有志で開催した社内イベント「おさんぽそん」が面白かったので、共有いたします！ おさんぽそん？ おさんぽそんとは、「おさんぽ」+「アイディアソン」を組み合わせた新しいイベントです。 弊社には「クリエイターの日」という業務時間の10%を利用して自由にものづくりができるという制度があり、よくWebサービス開発や技術検証に利用されています。 今回は「いつも社内の課題解決ツールを作ることが多いですが、もしかして社外に出たら他のアイデアも浮かぶのでは！？」 という仮説から、「クリエイターの日」のイベントの一環として開催しました。 当日の参加者は、社員5名 + 運営メンバー3名。 エンジニアやデザイナー、リサーチャー、サービス企画・・・職種も経験も違う多種多様の方々にご参加いただきました！ 今回の記事では、そんな「おさんぽそん」を開催して面白かった気づきを共有いたします。 おさんぽそんの実施内容 2チームに分かれて、各テーマを決めておさんぽに向かいました。 行き先は、Aチームは「廃墟」、Bチームは「高輪ゲートウェイ」です。どちらも面白そうですね！ まずはAチームからご紹介します。 Aチーム「廃墟」 ただ「廃墟にいきたい」という思いで、以下のスポットに行きました。 ・代々木会館：廃墟のようですが、現在もお店が開店しているらしい ・中野ブロードウェイ：かつてシャッター街になりかけたが、復活したらしい ・下谷小学校（上野）：廃校になってから放置されているらしい ・虎ノ門五丁目：廃屋が連なっているらしい ※本当は中野ブロードウェイは予定されていなかったのですが、中野にあるお目当ての廃墟がなかったので急遽中野ブロードウェイに行きました！ 代々木会館 見た目こそ廃墟ですが、数店舗は今も営業を続けていました。 飲食店の他に中国古書店もあるなど現代のショッピングモール的雰囲気があります。 どうして廃墟同然と化してしまったのか興味深い建物ですね。 活気あふれる中野ブロードウェイ サブカルチャーの象徴たる店舗がたくさん入っている中野ブロードウェイ。 実は中野ブロードウェイもかつては集客力の低下が進んでいたようですが、サブカルチャーの聖地として復活を遂げているそうです。平日昼にもかかわらず多くの人で賑わっていました。 この復活劇は非常に参考になりそうですね！ THE・廃墟の数々 「下谷小学校（上野）」と「虎ノ門五丁目」は、現在も存在していました。 上野に関しては、廃墟と化した小学校と、周りのオフィスビルとの対比が印象的です。 虎ノ門五丁目は、これぞ廃墟と言わんばかりの廃墟が多く見受けられました。 中には取り壊し中の廃墟もありました。都心ですし、できるだけ土地を有効活用していく方針なのでしょうか。 ここでとある気づきが！ 虎ノ門を始め、都心のような地価が高い土地では現状が廃墟でも壊せば買い手がつきますが、地価が低い土地はどうしていけばいいのでしょうか… Aチームは、この気づきについてアイデアを出すことにしました。 アイデア：廃墟の魅力を活用したお店を集約する ヒントは中野ブロードウェイと代々木会館から。 ◎中野ブロードウェイ：サブカルチャーの店舗が密集！→その場所自体に興味を持ってくれて人が集まる △代々木会館：テーマがバラバラ。というか1店舗しかない→人集まらない… 例えば、今回行った下谷小学校のように、閉校した学校を利活用するのであれば、 1教室ごとに店舗かまえるとか面白いんじゃないでしょうか。文化祭みたいで楽しそうですね！ Bチーム「高輪ゲートウェイ」 お次は、Bチーム「高輪ゲートウェイ」です。 予想外の駅名に決定した高輪ゲートウェイ駅が建設予定の場所に向かいました。 あれ？全然盛り上がってない 「ニュースでもやってたし、反対運動とかやってそう」 「”高輪に新駅誕生！”とか垂れ幕かかってそう」 「地元のお店が、なにかと高輪ゲートウェイに絡んだ商品とか出してそう」 など、新駅フィーバーが起きていると予想しながら、新駅誕生予定地の品川⇔田町をおさんぽ。 しかし、何やら普通の景色… たまたま俳句会を楽しんでいた方々に聞き込みをしたところ 「ゲートウェイって語呂が悪くて詠みにくいのよ」とまで言われていました。 新駅ができれば、駅の周りには新しく商業施設も建ち、 今よりも便利・快適に住むことができるはずなのに、予想以上に盛り上がっていないのはなぜなのか？ その盛り上がらなさをヒントに、何かアイデアに変えていこうという話になりました。 盛り上がらなさの要因、それは「遠さ」ではないか？ これだけ世間を賑わせた「高輪ゲートウェイ駅」が近くで建設されているのにもかかわらず、あまり興味がわかないのは何が原因なのか。 それは「距離が遠いことによる進捗のわかりにくさ」ではないかと考えました。 図の通り、歩道から駅までは目算でおよそ100m。遠い！完成予定も2022年ごろ。遠い！！ 遠すぎる＋進捗がわからなすぎて、興味もなくなってしまうのも致し方ないですね…。 ここで気づきが！ この、事象から遠いことによる興味のわかなさ…。 高輪ではさほど問題ではないかもしれませんが、オフィスではいかがでしょうか。 オフィスでの例 LIFULLの麹町オフィスは8F建てのオフィスビルで、3F〜8Fまでが執務スペースです。 おおまかには部署ごとに階が分かれているのですが、正直、階が違うと1つ1つの施策の進捗や結果は分からないというのが現状です。 定期的に施策共有会が開催されており施策共有の密度は高いのですが、1〜2ヶ月単位で開催されるので日常的には進捗がわかりません…。 そこで！利用するのは、オフィスの各階に設置されているサイネージ。 普段は全社的なお知らせや支社の様子が表示されています。 ここに「違う階の施策の進捗や結果」を表示すれば、「あそこのサービスめっちゃ成果出しているな〜！なんでなんだろ？」「あそこのサービスこの施策やって失敗しているなら、こういうのはどうなのかな？」など、他の階のことにも意識を向けることで、今よりも主体的に仕事ができるようになるのではないでしょうか！ おさんぽそんを開催してみて 良かった点 廃墟チームは「廃墟を活かせる題材を決め、集約して活用すると良い」 高輪ゲートウェイチームは「遠いことによる当事者意識の欠如があるなら、進捗共有できるようにすると良い」という発見がありました。 通常、アイディアソンは、解決したい課題（例：街のごみ問題等）やテーマ（例：VRを使ってうんぬん!等）ありきで開催されると思うのですが、 今回のおさんぽそんは、あえて運営からテーマを設定せず好きなところに行って良い！という状態で参加していただきました。 そのため、そもそも課題を見つけられるかな？という不安もあったのですが、都心のおさんぽは色々ツッコミどころが多くこの記事で記載していること以外にも多くの発見があったようでした。 部署や職種が違う人たちとチームを組んでおさんぽに行ったことで、 同じものを見ても気づくことが違い、自分にはない視点で観察できたとのことでした。 見つかった気づきを元に、その課題を直接解決する方法ももちろんありますが、 その課題、同じようなところにある！（例：高輪ゲートウェイ→オフィス） という発想につながったのはすごく面白かったです。 改善できる点 一方で、次回から改善していきたい点も見つかりました。 想像すれば課題も解決策も思いつくようなテーマにしてしまうと、外に出ていく意味が薄れてしまいます。 今回は運営側では「おさんぽして見つけた課題から何かアイデアを出してみよう」としか伝えておらず、 後は各チームで、考えたいテーマ・行きたい場所を自由に決めてもらいましたが、次回からは、運営側と参加者側ですり合わせていこうと思います。 今回はアイデア出しにかける時間や方法も自由に行っていただきました。 当日の時間配分が見えず、アイデアを考える時間が足りない＋疲労により、アイデア出しが消化不良になってしまった部分もあったかと思われます。 おさんぽして現地調査をすることも大切ですが、アイディアソンというからには最終的には何かしら解決するツールを考えることも楽しんでいただきたい… 参加者が無理することなく実現できるように、そういった仕組みのイベントを心がけていきたいですね。 おわりに LIFULLでは今回のおさんぽそん以外にも、社内外問わずクリエイター向けの社内イベントを開催しています。 ご興味ある方はぜひご覧ください！ www.lifull.blog www.lifull.blog www.lifull.blog recruit.lifull.com

こんにちは！LIFULLでエンジニアをしている中（あたり）です。 2018/12/20（木）に弊社にて開催させていただきました、「Ltech#4 Dotfiles Casual Talks」についてレポートいたします。 Ltechとは Ltech(エルテック)とはLIFULLがお送りする技術欲をFULLにするイベントです。 特定の技術に偏らず様々な技術の話を展開していく予定です。 Ltech#4 Dotfiles Casual Talks Ltech#4 はLT形式だったり、その場で github の dotfiles ファイルを表示して語る形式だったりで発表していただきました。 そのときの内容をご紹介させていただきます。 まずは乾杯をしてから LTの 1 番手を私が努めさせていただきました。 資料 speakerdeck.com 日頃使っている .bashrc, .gitconfig, .vimプラグイン, setup.sh について話させていただきました。 .bashrc に記載している alias, PS1 について .gitconfig に記載している alias について vim の便利なプラグインについて setup.sh について このブログを読んでくださったかたの参考に少しでもなれば幸いです。 私の dotfiles はこちらにあります。 github.com nasa9084さん 次にnasa9084さんに 実際に dotfiles をプロジェクターに表示させながら語ってもらいました！ peco や ghq の使い方や .gitconfig の alias などを紹介していただきました！ .gitconfig について unstage = reset -q HEAD -- など覚えにくいコマンドを alias に設定している emacs を日頃使っており、ricty というフォントを使っている 矩形選択のやりかたにこだわりがある twitter も emacs でやっている 感想 peco や ghq について私はまだ使ったことがなかったので是非試してみたいと思いました！ 覚えにくいコマンドを分かりやすい単語で alias を貼っているのはとても快適そうですね！ emacs 使いはやはり、 twitter もエディタでやっちゃう人が多いのでしょうか笑 ミヒャエルさん 次にミヒャエルさんにも 実際に dotfiles をプロジェクターに表示させながら語ってもらいました！ プロンプトをこだわっておりプロンプトに顔文字が表示されるようにしている 前回のコマンドが失敗していると顔文字が泣いている感じになる 成功するとシュッとする感じになるようにしている shell は fish を使っている ターミナルは、alacritty を使っている hammerspoon というツールを使っており Mac で GUI でしなければいけない操作をコマンドで使えるようにしている 例えばウィンドウを半分にするようなマウスを使わないといけない操作をコマンドでできるようにしている setup.sh を昔は書いていたが、Makefile の練習がてら Makefile で setup できるようにした 感想 プロンプトに顔文字が表示されているのはとても癒しですね！ かつコマンドの実行結果が分かるのも便利だなと思いました！ いろいろとご紹介いただいた中でも hammerspoon はぜひ私も使ってみたいなと思いました。 ウィンドウ半分割は、Windows ではデフォルトであるショートカットですが、 Mac ではなくて、少し不便に感じていたので、私も取り入れてみたいです！ まいけるさん 次にまいけるさんにも 実際に dotfiles をプロジェクターに表示させながら語ってもらいました！ ミヒャエルさん同様 alacritty を使っている 1年ぐらい前から使っているが日本語も問題なく使えている vim のレンダリングを早くしたいのでそういった理由でも使っている tmux の設定は GitHub - gpakosz/.tmux: 🇫🇷 Oh My Tmux! My pretty + versatile tmux configuration that just works (imho the best tmux configuration) これに良い感じの設定がたくさん入っており参考にしている tmux でこだわっている部分として 矩形選択モードと行モードで今どちらなのか分からないことがあったため、それが分かるようになる PR を投げてmerge してもらった vim-polyglot というのが便利 違う言語を触るたびにカラースキーマを設定するのが面倒ですが vim-polyglot はメジャーな言語のシンタックスハイライトをほとんどカバーしているので いちいち設定しなくてもよいので便利 感想 alacritty 使っている人が 2 連続で驚きました。 私も vimmer なので使ってみたい気持ちが高まりました。 tmux の矩形選択モードへのこだわりはすごいですね！ 私も最近色々な言語を触る機会が増えてきたので vim-polyglot もぜひ使ってみたい気持ちになりました！ LT会が終わって 私はもう数年 Dotfiles を更新しておらず現状の設定に満足していたのですが、 今回他の人の設定を教えてもらって、まだ知らない便利な機能が多くあることを知りました。 Dotfiles は極論言うとなくてもなくてもなんとかなるものですが あるととても便利なものであり、なかなか機会がないと更新しようという発想が出てこないものなので こうやって他者の設定を共有することは新たな気づきがありとても良いものだと思いました。 楽しい勉強会になり最後にみんなで写真を撮りました。 最後に 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

親戚のおじさんからのあだ名は「保土ケ谷スタイル」。 どうも、アプリディレクターのすけがわです。 普段はLIFULL HOME'SのAndroidアプリのプランニングと開発ディレクションを担当してますが、今回はAndroidアプリとは何の関係もありません。申し訳ございません。   雑談、得意ですか？ 藪からスティックで恐縮ですが、みなさん雑談は得意ですか？ 年末年始という季節柄、年に1度会うかどうかという親戚や旧友と再会する機会も多いと思います。 もしかしたら、「どんな話題を話したらいいかわからない…」、「いまいち盛り上がらない…」とお困りの方も少なくないかもしれません。   今回は不動産情報サービス「LIFULL HOME'S」のサービス担当者である私が太鼓判を押す、 絶対に盛り上がる雑談の話題「住まい」 について書いていきたいと思います。   なぜ「住まい」が鉄板の話題なのか？   ビジネスの現場でも活用されているから みなさん 「木戸に立ちかけせし衣食住」 ってご存知ですか？これは雑談の鉄板とされている話題の頭文字をつなげた造語です。 これらは主に商談やミーティングなどのビジネスの現場で、本題に入る前の「アイスブレイク」として活用されています。売上や生産性が厳しく求められる場面でも長年活用されている話題ですので、その効果と信頼性は非常に高いと言えるでしょう。   き：季節（気候） ど：道楽（趣味） に：ニュース（時節） た：旅（旅行） ち：知人（友人） か：家庭（家族・親戚） け：健康（病気・怪我） せ：世間（流行・社会情勢） し：仕事（職業・お金） 衣：衣服（ファッション・身なり） 食：食べ物（食生活・グルメ） 住：住まい（家・引越し）   私も自分自身の雑談を振り返ってみると、ほとんどの話題が上記のいずれかに該当することがわかります。これをさらに「し × 衣（仕事での身なりの話題）」、「け × 食（健康に良い食べ物の話題）」などのように組み合わせていくことで、話題のバリエーションが増やせていけそうですね。 そしてこの「木戸に立ちかけせし衣食 住 」に 「住まい」もしっかりとランクイン しております。「住まい」の話題はビジネスの現場でもよく話されているんですね。   住まいの話題は広げやすい 雑談の基本は連想ゲーム （ いわゆるマジカルバナナ）が基本です。「住まい→引越し→住まい探し→理想の住まい→譲れない条件→おすすめのエリア→そのエリアでの思い出」と言うように無理なくリレーをしていければ、お互いに気持ちよく雑談することができるでしょう。 住まいの話題は、話題自体に多くの連想ワードが含まれます。また、連想されるワード自体も、さらに連想を生みやすいワードとなっており、雑談の連想ゲームが途切れづらい傾向にあります。 あくまで1例ですが、以下に住まいから連想できる事柄や話題を書き出してみました。 カテゴリ 関連する事柄 家 家賃、間取り、築年数、その他スペック 地域・エリア 雰囲気、自治体の制度 引越し 住まい探しの条件・Chips 最寄り駅 乗り入れてる路線、ターミナル駅へのアクセス よく行く場所 買い物、遊ぶ場所 通勤・通学 電車や車の乗車時間、混み具合 生活リズム 起床時間、就寝時間、ルーチン 近所付き合い お隣さん情報、ゴミ捨て事情 実家との距離 帰省の頻度、所要時間 現在の住まい 良いところ、悪いところ 理想の住まい 10億円当たったら？ 過去の居住遍歴 生まれてからこれまでに住んだ家・地域 どうでしょう？ ざっと書き出した話題だけでも、全てについて触れようと思ったら1時間や2時間では全然足りないと思います。 「雑談ですぐに間が持たなくなってしまう…」という方は、上記に書き出した事柄について、自分の話と相手の話を50：50の割合で話す（聞く）ようにすれば、きっと上手く間をつなぐことができますよ。   ちなみに私は、妻のご両親との初めての顔合わせで、大いに活用しました。 普段から雑談は「めちゃめちゃ得意！」というタイプではないのですが、最初のご挨拶からお別れまで、終始楽しくお話することができたことを覚えています。ありがとう！住まい！ 普段の雑談でも活用できていて、「横浜に引越してびっくりした東横線あるある」は、私の中でも1，2を争う鉄板です。ついつい何度も話してしまいます。   「住まい」の話題をチョイスすることで、思わぬ副産物も 「住まい」に関する雑談は多くの人が共感しやすく、盛り上がりやすい話題ではありますが、引越しや住み替えという切り口で考えると、人生でそう何度も経験できることではありません。 物件の購入となれば、一般的には一生に1度でしょうし、引越しの回数で考えても、恐らく片手で数えられる人がほとんどではないでしょうか？   もしあなたが、直近1年くらいで引越しや住み替えを検討されているのでしたら、周囲の人と雑談を通して思わぬ情報が得られるかもしれません。 その土地土地の住み心地や、住まい探しで重視すべき条件、契約での失敗談などは聞いておいて損はないと思います。 特に自分よりも年上の人の経験談は非常に参考になると思いますので、年末年始で親戚に久しぶりに会うという方は、ぜひ   と、積極的に話を切り出してみてください。 きっと次回の住み替えがより良いものになるはずです。   私自身も、親戚のおじさんと会ったときにはよく現在住んでいる家やエリア（横浜市の保土ケ谷区）の話題になります。話しすぎて、何故か私のあだ名が「保土ケ谷スタイル」になってしまうほどです。（今では髪をバッサリ切ると「よ！保土ケ谷スタイル！」と煽られます…） 逆におじさんからも、家のリフォームの話やDIYの話、家を買った（建てた）時の話など沢山のお話を聞いています。 そろそろ物件の購入も検討しようかな？と考えている私としては、雑談として楽しいだけでなく、1つの人生の教訓として参考にさせてもらっています。   なお「住まい」に関する雑談をしていて、「引越ししたいな！」という気持ちが高まったら、ぜひLIFULL HOME'Sを利用してみてください 手前味噌ですが、Webサイトもスマホアプリもどちらも物件数が豊富で使いやすいですよ。   LIFULL HOME'S Webサイト http://www.homes.co.jp LIFULL HOME'S PCサイト スマートフォンアプリ iPhone / iPad お部屋探しならライフルホームズ 不動産物件検索アプリ LIFULL Co., Ltd ナビゲーション 無料   Android play.google.com 家賃や購入価格の相場感を掴むのにも活用できるので、LIFULL HOME'Sで情報収集すれば、さらに雑談を盛り上げるネタが見つかるかも？ 「住まい」の話題のリスクと対処法 どんな話題にもリスクがあります。人によっては、住まいに関連する話題で触れてほしくない事柄もあるでしょう。 例えば、離婚やストーカー被害などネガティブな理由からやむを得ず住み替えをした場合などです。 これらは当事者自身がすでに消化済みで笑い話にできるくらいであれば問題ないと思いますが、少しでも話しづらそうな雰囲気を感じたらあまり深掘りはせず、関連する別の話題にシフトするのが得策でしょう。   何度も言うように、 「住まい」の話題の利点は関連する事柄の多さ です。急に話題をシフトしたとしても無理矢理感は比較的発生しづらいので、臆せずシフトしましょう。 他の事柄にも共通しますが、「思い切りの良さ」は「気持ちよさ」に繋がります。思い切りが重要です。   もし、本当にどうしようもない状況になってしまったら、全力で笑いましょう。最終的には笑顔です。大丈夫、何とかなります。 まとめ いかがでしたでしょうか？ いかに雑談において「住まい」の話題が鉄板で、年末年始にフィットした話題であるかがご理解いただけたかと思います。 今回は「住まい」という話題にフォーカスしてみましたが、みなさんは鉄板の話題はありますか？もし「〇〇は絶対に雑談盛り上がるぜ～」ってのがあれば、Twitter等のSNSでぜひシェアしてくださると嬉しいです。   それではみなさん、良いお年を！ ※この記事はあくまで1例のご紹介となります。活用した際の結果については一切責任はとれませんので、予めご了承ください。

どうもみなさんこんにちは！まっつんといいます。 LIFULL HOME'S 賃貸事業部のWebディレクター兼プランナーです。 普段はサイトの分析や改善施策立案などの業務をしております。 チバさんが Day1の記事 を投稿されたのに続き、僕もDay2のレポートを書かせていただきます！ 各セッション内容ごとにスライド資料や参加者のコメントのリンクも貼りましたので、適宜ご覧ください。 「プロダクトマネージャー・カンファレンス 2018 - 愛されるプロダクトを創ろう」の参加レポート [ day2 ]です！ 2018.pmconf.jp ※忙しい方は一番下の感想をお読みください！ セッション内容ごとのまとめ [07-01] Welcome Talk 関 満徳 グロースエクスパートナーズ株式会社（ITコンサル会社） このイベントのコンセプトになっている「愛されるプロダクトを作る」。 これについての解説でした。 「PMがプロダクトを愛しているのは当然だが、メンバーも関われてうれしい楽しい誇らしいという最高の状態に持っていく必要がある。」 「自分のやりたいことを関係者を巻き込んで作る。」 「そのために何を考えてどうしていくのかに触れていきたい。」 愛されるプロダクトは、愛されるゆえにいろんな人を巻き込める。 そういうものづくりこそ、あらゆるLIFEをFULLにできるわけですね～ [07-02] 巨大なFinTech事業開発におけるプロダクトマネジメント 甲斐 真一郎 株式会社FOLIO 代表取締役 CEO 最も印象に残っているのは、 「PMとは一人一人がプチ社長である」 という言葉。 かつてLINEは災害時のためにプロダクトをたった2週間で開発し、開発者が社長になりました。 社長になる気はなくても、社長になれる商品にできる可能性はあるので、 良い商品を作れるかどうかはPM次第ということです。 甲斐さんの経験で、関連する3つのサービスを同時に作る時の苦労が面白かったです。 3つともKPIが 異なる フロントとバックは共通リソース インターフェースのデザインは統一しつつも機能は全く別 結果として、兼務が生じてリソースの取り合いになったり、要件の優先度が入れ替わったりと、 現場がかなり混乱したらしいです。 そこで見出した解決策が、先ほどの 「一人一人がプチ社長」 でした。 プロダクト境界の明確化と、そのための組織境界及びミッションの明確化によって、 それぞれが主体的かつ独立に最善を追求できるようになったのが、成果につながったそうです。 それぐらいの高い視座を持ってものづくりがしたいですね！ 2018.pmconf.jp [07-03] C向けアプリのPM経験者から見た、B2B Saasのプロダクトマネジメント 今井 義人 株式会社マネーフォワード MFクラウド経費本部 本部長 プロダクトオーナー マネーフォワードのPMさんです。 この講演では、B2CとSaasのビジネスモデルにおけるPMの役割の違いについてお話いただきました。 Saasは色々な面でやりやすそうなことが分かりました。 Saasとは簡単にいうと、プロバイダ側のコンピューターでソフトウェアを立ち上げ、それをネットワーク経由で使わせてもらう仕組みのようです。 なるほど僕のような新人にはよく分からんですね。 Saasの良いところ（対BtoB） 課金してもらえれば収益が入り続ける 製作の傍らで営業が稼いでくれる。同時稼働。 明らかな課題を1個1個確実につぶしていける 2018.pmconf.jp [07-04] 気がついたらプロダクトマネージャーになっていた（仮） 塩出 晴海 Nature株式会社 代表取締役 CEO ネイチャーリモという、スマホをリモコン代わりにできるIoT製品のPMさん。 そのネイチャーリモの開発ストーリーを説明していただきました。 その苦労話から学んだことは下記 プロダクト開発の過程において、失敗は避けられない。だからこそ、最悪のパターンを想定し、そのリスクを取れると判断したなら、 失敗を恐れず進む べき。 顧客の声を聴いて開発・改善 を行う。 フレームワークを使わず、 自分の頭で考えて判断 する。 PJの成功が目的である以上、 できることは何でもやる 。 塩出さんは数々の苦労を乗り越えて、常に顧客目線で良い製品を作った方です。 顧客のために何でもやる姿勢が大事なのだと思いました。 2018.pmconf.jp [07-05] リクルートの横断組織で考えるプロダクトマネジメント（仮） 宮里 裕樹 株式会社リクルートコミュニケーションズ ICTソリューション局 アドバンスドプロダクト開発部 部長 PMが活躍する組織のお話でした。 PMの資質は下記4つに分かれており、それぞれに合わせた成長機会を持つことが大事とのことです。 ビジネスプロデュース プロダクトマネジメント プロダクトリード ITディレクション 自分はどの資質があるのかなと思いました。 2018.pmconf.jp [07-06] 顧客、会社、チームをHappyにするプロダクトマネジメント ～観点・プロセス・レバレッジ～ 山下 徹朗 楽天株式会社 Vice Senior Manager プロダクト開発の成功へ導く観点とプロセスについてご教示いただきました。 以下の3つの本質的な問いを常に持ち、それぞれに担当者をつけてPMがリードする 　 A.Business： 会社にとってどんな意義を作るのか 　 B.UX： どんな嬉しい経験、習慣にするのか 　 C.Marketing： どんな風に惹きつけるのか PMの仕事は常に本質を問い続けること だ、というお話が印象的でした。 その本質に基づいてチームをリードし、メンバーや会社の強みを最大限活かすことで、 よい製品づくりに繋がるのだろうと思いました。 2018.pmconf.jp [07-07] Build Narrative in Product 池田 明啓 株式会社ドワンゴ サービス開発本部　副本部長 ユーザーストーリーを理解することの重要性をご教示いただきました。 PMとはプロダクトが社会貢献するまでのストーリーを構築する人 であり、ユーザーが活用するストーリーを理解する人である。 ストーリーを理解できていないと、量でごまかそうとしてしまう。 その結果使われない機能が増えてしまう。 スターエンジニアに頼ってしまうと、抜けた際の学習コストがネック になる ドワンゴにはプロダクト開発の7つのステップがあり、それぞれに責任者を置いて開発を進めている ライブコーディングやライブシェアなど、学習をより手軽にする方法を導入 ドワンゴはプロダクト開発の手順が体系化されている印象を受けました。 ストーリーを組み立て、それに基づいて開発を行うケーススタディがプレゼン資料にまとめられているので、 是非ご覧ください！ 2018.pmconf.jp [07-09] The mindset of building the product that user will love Jasper WU 株式会社メルカリ UX consultant PMのためのデザインシンキングのお話でした。 導入はubarと自転車の話です。 目的地に行こうとubarを利用したかったが、実は自転車の方が早かった。 この場合、自分にとっては、その目的地に早くいくことが大事だったことになります。 同じように、PMが考えなければならないのは、 誰にために、何をするか ということです。 そこでPMは下記3つのことを常に頭に置いておく必要があります。 １．Understanding 　ユーザーを理解すること。ユーザーには次の4タイプあり、それぞれとの接点を持つことが大事 　Targetユーザー：ターゲット 　Indirectユーザー：直接のターゲットではないが、その周りに関係性を築ける人々 　Extremeユーザー：製品が極端に愛され、または嫌われる理由を知ることがヒントになる 　Descendantユーザー：未来に与える影響を考える ２．Teamwork 　開発の過程を考え、多様なバックグラウンドを持つメンバーと話す ３．Fail fast 　早く失敗することが最も早く勉強する方法。 　アジャイルを回してとにかく失敗→改善を繰り返すこと。 WEBの仕事をしていると、なかなかユーザーの生の声に触れる機会がありません。 しかし、 ユーザーの幸せを願って製品を作る以上、その声を聴く機会を作っていくことが重要 だと思いました。 メルカリのように、ユーザーを集めて交流したり、イベントを開催したり。 うちの組織でもできることかと思います。 2018.pmconf.jp [07-10] 北米・アジア・欧州のプロダクトマネジメントとスマートニュースのプロダクトマネジメント 宮田 善孝 スマートニュース株式会社 プロダクトマネージャ スマートニュースではチームが遠隔で共同作業をするそうで、年に一回世界中の社員を集めてカンファレンスを行っています。 この講義では北米・アジア・欧州のPMの事例と、スマートニュースの事例をご紹介いただきました。 北米：General Assembly 概念の紹介といった講義と、チームプレゼンとフィードバック。一般的。 アジア：Product management festival カンファレンス方式。PMの責任と役割について。 プロダクトマネージャーVSシニアリーダーになることがあるが、それぞれの役割は下記。分担しよう。 PM→製品に責任を持ち、ヴァーチャルなチームを動かしていく。 SL→組織的チームを持ち、指揮命令だけでなくメンタリング等も行いチームのパフォーマンスを向上させる 欧米：Turning Fest プロダクト開発の各機能とのつながりについて。 良いチーム→AutonomyとAlignmentが高い状態。 Alignment： 一つの目標に迎える状態。 Autonomy： 個々のメンバーが高いパフォーマンスを発揮する状態。 PMの役割は目標を示すことであり、メンバーのやり方にいちいち口出しはしない その後スマートニュースの事例をご紹介いただきましたが、その中で特に理想のチームのお話が興味深かったです。 PMの仕事はビジョンを設定することであり、メンバーに命令したりオーナーシップを取ることではない。 立ち上げ時は何時間も議論し、認識を合わせるが、後は進捗確認を30分行う程度。 みんながファンクションごとに責任を持っていればアメーバ状に動く AutonomyやAlignmentを高めるのがPMの仕事 なのだと思いました。 2018.pmconf.jp [07-11] 中国のプロダクトマネジメントのリアル 陈兆伟 (Chen Zhaowei) バイドゥ株式会社 プロダクトマネージャ 中国のプロダクトマネジメントは今どうなっているのかを共有いただきました。 大きな流れとして、アメリカに倣ったPMの育成やプロダクト開発から、自国向けに最適化するイノベーションが進んでいるようです。 アリババ、WeChatなどが最たる例ですね。 今や中国はスマホ普及率70％、利用者数は10億人。 中国でイノベーションが進んだ要因は2つあるようです。 １．貧富のギャップ 農村での4G回線が使えて、安くて速いサービスのニーズが極めて大きかったこと。 ２．ITと各産業とのコラボ どこでも電子決済が可能で。病院の診断結果もスマホで確認できる。 新しいビジネスチャンスがどんどん生まれています。 また、中国のPMとアメリカのPMとの違いも面白かったです。 １．アメリカのPMは技術とMBAが必要ですが、中国のPMは社会のニーズとビジネスに詳しければ大丈夫。 ２．アメリカは優秀なPMに権力を集中させるが、中国はPMの下にPMがついて細かくミッションを設定する。 お話を聞いていて、 ビジネスチャンスのあるところにPMが必要になる のだと思いました。 ビジネスの機会を創っていくこと、そしてそこでニーズに応えられる商品開発力を持つこと。 それが日本のPMにおいても重要だと思いました。 2018.pmconf.jp [07-12] Anycaにおけるプロダクトマネジメント 馬場 光 株式会社ディー・エヌ・エー オートモーティブ事業本部 Anyca事業責任者 PMに必要な能力についてお話しいただきました。 それは姿勢と責任に分けられる、下記の7つです。 姿勢 リーダーシップ・パッション ユーザーへの誠実さ 目的思考 責任 インサイト発見・目標設定 長期目線・プライオリティ 判断・説明 コミュニケーション これらについてエニカの事例をご紹介いただきました。 目標はぶれないように固めること、役割を分担すること、ユーザー接点を作ること、などなど。 興味深かったのは課題抽出のお話で、新機能がユーザーに使われなかったとき、どのようにクローズ判断をしたかということです。単に使われていないだけで切り捨てるのではなく、解決すべき課題が無いか、どこか別の場所で効果が出ていないか、など考えた末に判断するそうです。 機能を作ることより、無くす判断の方が難しい のだろうと思います。 2018.pmconf.jp [07-13] [ワークショップ] 日本のプロダクトマネージャーは今何をすべきか 最後に参加者を巻き込んで、「なぜ愛されるプロダクトを作らなければいけないのか」をテーマに議論をしました。 ビジネスモデル的には以下の3つがあります。 顧客生涯価値LTVの増加 広告宣伝からSNSへの移行 顧客獲得コストの最小化 しかしそれら外向きな理由ばかりではありません。 まずはプロダクトを作る 自分たちがそのプロダクトを愛する こと 愛されるプロダクトを作ることで、 自分たちも幸せになる ものづくりをすること それにより、 ものづくりが社会に幸せをもたらす ものにすること それが愛されるプロダクトを作る理由なのだと思います。 2018.pmconf.jp 参加してみた感想 入社して初めてPMという言葉を知った僕には、大変刺激的な内容でした。 スピーカーのみなさんのお話を聞いて、PMとして重要なのは下記事項だと思いました。 常に目的を掲げ、 本質を追い求める こと チームワークを築き、 ビジョンを示し認識を合わせる こと ユーザーとの接点を作り、 ユーザーの声を聴いて開発 をすること ユーザーのストーリー を描き、真に求められるプロダクトを作ること 成功のためには主体的に何でもやり、 どんどん失敗する こと そして何より、PMとして最も大事なことは、 そのプロダクトを誰よりも愛すること だと思いました。 誰かに愛されるプロダクトを作るためには、まず自分が愛せるものでなくてはならない。そんなプロダクトを、LIFULLというチームで作っていけたら、楽しいなと思います。

こんにちは！Ltech運営チームの井坪（いつぼ）です。 12/11（火）に弊社にて開催させていただきました「Ltech#3 【podcast × IT】LT Night!」についてレポートいたします。 Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。 特定の技術に偏らず、様々な技術の話を展開していく予定です。 Ltech#3 【podcast × IT】LT Night! Ltech#3はLT形式で発表していただきました。 そのときの資料をご紹介させていただきます。 docs.google.com Podcastを聴く場所は人それぞれだと思いますが、泳ぎながら聴いたりサウナで聴くのは独特ですね！ speakerdeck.com 普段触れない領域の話を聴くことで知識を得るきっかけになり勉強になっているそうです。参考になりました！ speakerdeck.com 聴いているPodcastを分析するなんてデータサイエンティストならで面白い発表でした！ speakerdeck.com 業務等でも他職種について理解するのは大事なので、お互いの知らないことを理解できるのはとても良いですね！ www.slideshare.net 社内の方と社内向けPodcastは取り組んでいるプロジェクトの共有や他部署との交流、宣伝などメリットは多いそうです！ qiita.com 限られた時間内や定期的に配信するとなると難しそうですね。 社内向けPodcastをやってみようと考えている方は参考にしてみて下さい！ 懇親会の様子 今回もLtech名物の「からあげ」をご用意いたしました。 からあげを食べならPodcastネタを中心に技術系の情報交換ができ盛り上がっていました！ ご参加いただきました皆様、ありがとうございました。 最後に 12/20（木）に「Ltech#4 Dotfiles Casual Talks」を開催いたします。 皆様のご参加お待ちしております。参加方法は以下のconnpassからお申し込み下さい。 lifull.connpass.com 今後もLtechを積極的に開催していきますので、 ぜひ気になった方はconnpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは、技術開発部の相原です。 この記事は LIFULLアドベントカレンダー の16日目です。 LIFULL では アプリケーション実行基盤を刷新すべく、Istio がバージョン 0.2.0 の頃から検証を開始し、現在 1.0.4 を利用しています。 AWS 上で kops を利用して Kubernetes を構築しその上に Istio を展開するという構成です。 EKS は利用していません。 ここに至るまでそれなりにハマりどころ、考慮すべき点に遭遇したので今回はそのことについて書きたいと思います。 以下の文章は kops 1.10.0 Kubernetes 1.10.11 Istio 1.0.4 を前提としていることをご了承ください。 はじめに 本番導入までの障壁 istio-proxy のオーバーヘッド Resource Quota を有効化した時に Istio の Sidecar が Inject できない Istio コンポーネントの HPA がうまく動かない Istio コンポーネントの可用性を上げる Kubernetes クラスタを Production Ready に近づける CNI plugin を変更する kops でデプロイしたインスタンスで ext4 のハードリンクが枯れる externalTraffic: Local の罠 fluentd-kubernetes-daemonset で文字コードでハマる おわりに はじめに LIFULL HOME'S サービス開始から20年が経ち、コードベースも次第に巨大になってきました。 そしてコードベースが巨大になるにつれて、デプロイ速度の鈍化やメンテナンス性の低下が目立つようになり、開発速度が低下していきました。 そうした変化を受けて LIFULL では、数年前のオンプレミスからの AWS 移行を契機にマイクロサービス化に踏み切ります。 サービスを適切な単位で切り分けてデプロイを独立化し、開発チームに権限を移譲することで分業化に成功しました。 しかし、年月が経ち新たな課題が見え始めました。 それはマイクロサービス化による車輪の再発明と分散システムとしての難しさです。 それぞれのチームがロギング・監視基盤やデプロイフローを個別に構築したり、各アプリケーションごとに Retrying や Timeout を実装することにより、従来の体制と比較して重複する機能が多くなってしまいました。 加えて、下流のサービスに巻き込まれる形での障害も目立つようになり、分散したアプリケーションをうまく運用するという難しさにも直面することになったのです。 そこで我々がとった選択肢が Kubernetes の導入によるアプリケーション実行基盤の統一と、 Service Mesh である Istio 導入によるマイクロサービスに必要な機能の一貫した提供でした。 Istio は Retrying, Timeout や Rate Limitting に加え、CircuitBreaker のようなマイクロサービスに必要な機能を提供するソフトウェアです。 Kubernetes の導入によって開発者への権限の移譲はそのままにロギング・監視基盤やデプロイフローをアプリケーション間で流用した上で、その Istio を導入して開発コストの削減と分散システムとしての信頼性の向上を狙いました。 トラフィックの質が違う複数のアプリケーションを同じインスタンスに同居させることでコストの最適化にも繋がりますし、アプリケーション間のネットワークの距離も縮まるためパフォーマンスへのインパクトも期待できるはずです。( KEP: Topology-aware service routing として可能な限り距離の近い Pod にルーティングする仕様が提案されています) github.com 加えて、ベンダーロックインからの解放も期待できるということで熟考の上決断に踏み切りました。 本番導入までの障壁 ここからは実際に本番導入に至るまでの障壁について紹介します。 istio-proxy のオーバーヘッド Retrying, CircuitBreaker, Rate Limitting など様々な機能を実現する istio-proxy ですが当然そのパフォーマンスへのオーバーヘッドは 0 ではありません。 導入するアプリケーションの性質に応じて慎重に導入の是非を考慮すべきです。 istio-proxy によるオーバーヘッドについてはドキュメントにあるのでそちらをご参照ください。 istio.io ドキュメントにあるように istio-proxy では 1 リクエストにつき概ね 10ms 程度のオーバーヘッドが生じます。 手元の環境でのパフォーマンステスト結果としてもほとんど同様の結果が得られました。 10ms と言われるとアプリケーションの性質によっては微々たるもののように感じますが、仮に対象のアプリケーションが直列で他の API に対して複数回リクエストするとき、そのリクエスト数分だけこのオーバーヘッドが生じることになります。 istio-proxy はその性質上、OUTBOUND のトラフィックに対する処理の比重が大きいという特徴があります。 VirtualService によって実現される Retrying, Routing は OUTBOUND トラフィックに対して発生しますし、CircuitBreaker, Connection Pooling を司る DestinationPolicy に関してもそうです。 一方で INBOUND のトラフィックでの主な処理は Rate Limitting くらいなもので、これはつまりリクエスト元に対する Sidecar の Inject さえやめればパフォーマンスが大きく改善するということを意味します。 深刻なオーバーヘッドが生じた場合はこのような観点から Sidecar の取捨選択を行うべきです。 当然同様の機能をアプリケーション内に実装することに比べれば、多くのケースにおいて istio-proxy でやる方が高速ですし、機能の標準化の観点からも有意義ですが、Sidecar の有無に関してはアプリケーションの性質に応じて慎重に判断する必要があるでしょう。 Resource Quota を有効化した時に Istio の Sidecar が Inject できない Kubernetes には Resource Quotas という namespace ごとにデプロイ可能なリソース量を制限する機能があります。 これを namespace に対して有効化すると Container に対してリクエストするリソース量、上限まで利用できるリソース量を指定することが義務付けられるというものです。 ある namespace にリソースを際限なく消費されると困るので一般的にこれを使って制限をかけることになります。 通常、LimitRange で default, defaultRequests を指定することで各 Container にデフォルトのリソース量を設定することが可能なので特に気にしませんが、Istio の Sidecar の Inject はこの LimitRange の前に実行されてしまうため 1.0.4 現在ではこれに対して別途対応が必要です。 まず、Sidecar である istio-proxy です。 istio-proxy のリソースは values.yaml から指定できるので以下のようにパッチを当てます。 当然 CPU の利用量はリクエストに応じて増加するためここは随時調整します。 --- install/kubernetes/helm/istio/values.yaml 2018-12-16 00:00:47.590948200 +0900 +++ install/kubernetes/helm/istio/values.yaml 2018-12-16 00:00:33.263144300 +0900 @@ -28,10 +28,10 @@ global: resources: requests: cpu: 10m - # memory: 128Mi - # limits: - # cpu: 100m - # memory: 128Mi + memory: 128Mi + limits: + cpu: 1000m + memory: 128Mi # Controls number of Proxy worker threads. # If set to 0 (default), then start worker thread for each CPU thread/core. しかしこれだけではまだデプロイは成功しません。 実は Istio の Sidecar をデプロイしようとすると istio-init という iptables などの設定を行う initContainer が起動します。 Resouce Quota を設定した namespace では initContainer にもリソース指定が義務付けられるためこちらも対応する必要があります。 しかし istio-init 用の設定は values.yaml にないためこちらは少々ハックが必要です。 これは Istio 1.1.0 でリリース予定です github.com まず、Sidecar を Inject するためのコンポーネントである istio-sidecar-injector の設定ファイルに値を渡せるように sidecar-injector-configmap.yaml にパッチを当てましょう --- install/kubernetes/helm/istio/templates/sidecar-injector-configmap.yaml 2018-12-16 05:17:35.419691832 +0000 +++ install/kubernetes/helm/istio/templates/sidecar-injector-configmap.yaml 2018-12-16 05:19:11.799894444 +0000 @@ -43,6 +43,8 @@ data: - NET_ADMIN privileged: true restartPolicy: Always + resources: +{{ toYaml .Values.global.proxy_init.resources | indent 10 }} {{- if .Values.global.proxy.enableCoreDump }} - args: - -c これで sidecar-injector-configmap.yaml が values.yaml の内容を解釈できるようになりました。 あとは先ほどの istio-proxy と同じようにリソースを指定するのみです。 こちらは初期化処理をするためだけのコンテナなのでリソースを多く必要としません。 --- install/kubernetes/helm/istio/values.yaml 2018-12-16 00:00:47.590948200 +0900 +++ install/kubernetes/helm/istio/values.yaml 2018-12-16 00:00:45.304157200 +0900 @@ -99,6 +99,13 @@ global: proxy_init: # Base name for the proxy_init container, used to configure iptables. image: proxy_init + resources: + requests: + cpu: 10m + memory: 128Mi + limits: + cpu: 10m + memory: 128Mi # imagePullPolicy is applied to istio control plane components. # local tests require IfNotPresent, to avoid uploading to dockerhub. これで晴れて Sidecar をデプロイできるようになりました。 Istio コンポーネントの HPA がうまく動かない istio-ingressgateway, istio-policy などのコンポーネントはリクエスト量によってスケールする必要があるためあらかじめ HPA が用意されています。 しかし何も設定しないままデプロイしてしまうと、istio-pilot などの一部のコンポーネントには適切なリソースが確保されますが、その他のコンポーネントはデフォルトのリソース確保量が小さすぎるため常にスケールのトリガーが発火してしまい HPA が期待通りの動きをしません。 Istio コンポーネントにおけるデフォルトのリソース確保量を設定する項目があるのでそちらを調整して解決します。 --- install/kubernetes/helm/istio/values.yaml 2018-12-16 00:00:47.590948200 +0900 +++ install/kubernetes/helm/istio/values.yaml 2018-12-16 00:00:16.539089300 +0900 @@ -163,8 +163,8 @@ global: # block in the relevant section below and setting the desired resources values. defaultResources: requests: - cpu: 10m - # memory: 128Mi + cpu: 100m + memory: 128Mi # limits: # cpu: 100m # memory: 128Mi これで HPA が適切に動作するはずです。 Istio コンポーネントの可用性を上げる Istio コンポーネントの HPA はまだ十分ではありません。 デフォルトの設定ではそれぞれのコンポーネントが1台ずつデプロイされるのみで、最大でも5台にまでしかスケールしません。 これでは可用性に欠けるため適切な設定を施します。 数が多いためすべての設定はしませんが以下のようなパッチを当てて台数を調整しましょう。 --- install/kubernetes/helm/istio/values.yaml 2018-12-16 00:00:47.590948200 +0900 +++ install/kubernetes/helm/istio/values.yaml 2018-12-16 00:00:50.688467300 +0900 @@ -226,9 +226,9 @@ gateways: labels: app: istio-ingressgateway istio: ingressgateway - replicaCount: 1 - autoscaleMin: 1 - autoscaleMax: 5 + replicaCount: 3 + autoscaleMin: 3 + autoscaleMax: 10 resources: {} # limits: # cpu: 100m Kubernetes クラスタを Production Ready に近づける 単に kops で Kubernetes を AWS に構築しただけでは、そのまま運用を始めるには心許ないです。 Node, Pod のスケールアウトもできなければ、運用に必要なメトリクスも不足しているという状況です。 Kubernetes コミュニティにはそれらを補うための素晴らしいソフトウェアがあるのでそれを利用しましょう。 まずは Node のオートスケールの実現です。 これに関しては kops が addon を提供してくれているので素直にそれを利用しましょう。 github.com これを利用することで Pod のスケールアウト時にリソースが必要なタイミングで新たな Node が起動します。 次は Pod です。 以前から利用されていた heapster は 1.11 で deprecated となり、代替のソフトウェアとして kubernetes-incubator/metrics-server が開発されています。 github.com HPA はこれらのソフトウェアから取得できるメトリクスに依存しているため導入しましょう。 更に、監視という観点では Pod ごとのメトリクスが取得できているのみでは不足に感じることがあります。 本来必要となるメトリクスは Deployment などの Kubernetes リソースごとの抽象化されたメトリクスです。 Kubernetes は標準でそのような機能を持ち合わせていないため、そのためのソフトウェアである kubernetes/kube-state-metrics を導入してその要求を実現しましょう。 github.com Node の異常を Events の形式で通知してくれる kubernetes/node-problem-detector も監視の役に立ちます。 github.com Kubernetes の Events は CrashLoopBackOff や FailedScheduling などの監視に有意義な情報を取得できるものですが、ここで取得できるのはあくまで Kubernetes 内で起きていることのみです。 しかし、 kubernetes/node-problem-detector を利用することで Node 内におけるカーネルのデッドロックや OOMKiller の発生をその Events に統合して通知してくれます。 これにより運用に必要な情報は揃ったはずです。 最後は認可の部分です。 Kubernetes はデフォルトで認証認可の仕組みがありますが、AWS を利用している場合 IAM を認可と紐付けたいと考えるでしょう。 その場合は kubernetes-sigs/aws-iam-authenticator (旧 heptio/authenticator) が役に立ちます。 github.com これを導入することで IAM Role ごとに権限を管理することができるので、開発チームへの権限委譲がスムーズになるでしょう。 CNI plugin を変更する kops で デプロイした時にデフォルトで利用される kubenet という方式ではルーティングに AWS のルートテーブルを用いる関係上、クラスタ内のノード数が 50 に制限されてしまいます。 これを解決するために様々な CNI plugin がありますが、AWS の場合は VPC のセカンダリ IP を用いる amazon-vpc-routed-eni が素直な選択肢に思えます。 ですが私達は移植性を考慮して、手に馴染んだソフトウェアでもある、クラスタ内に仮想の L3 ネットワークを構築する Project Calico を採用しました。 www.projectcalico.org 影響範囲が大きく安易な選択をできない部分ですが、少なくともデフォルトの状態では今後のスケールに対応できないため、慎重に選択する必要があります。 kops でデプロイしたインスタンスで ext4 のハードリンクが枯れる kops は AWS に Production Ready な Kubernetes クラスタをデプロイするための素晴らしいツールです。 しかし、現時点ではそのまま運用するためには多少の問題点があるのでそちらについて説明しましょう。 kops ではドキュメントにあるように Debian を Tier 1 サポートとしています。 github.com ここで注意すべきなのはこの Debian にインストールされている Docker Daemon のバージョンです。 この Debian にインストールされているのはバージョン 17.03.2 の Docker Daemon で、残念なことにこのバージョンの Docker Daemon のストレージドライバは overlay です。 overlayfs はレイヤー内のオブジェクトをハードリンクとして親のレイヤーと共有することで知られています。 その性質のため overlayfs では非常に多くのハードリンクが使用されるという特徴があります。 しかし、ext4 におけるハードリンクの上限は 65000 です。 overlayfs を利用するインスタンスを長期に渡って運用していると必ずこの上限に引っかかる時が来るでしょう。 これを解決する最も単純な解決策は kops edit cluster にて以下のサービスをクラスタ内で有効化することです。 このサービスを有効化することで Container から参照されていないイメージが定期的に削除されます。 - name: prune-images.service roles: - Master - Node manifest: | [Unit] Description=prune images [Service] Type=oneshot ExecStart=/usr/bin/docker image prune -a -f - name: prune-images.timer roles: - Master - Node manifest: | [Unit] Description=prune images [Timer] OnCalendar=*-*-* 23:59 Persistent=true [Install] WantedBy=timers.target そして最もよい解決方法は overlay2 にストレージドライバを切り替えることです。 幸い kops は overlay2 を利用する Ubuntu のイメージもサポートしているためそちらに切り替えることでこの症状を大幅に改善することができます。 しかし Ubuntu は kops コミュニティから Tier 1 サポートを受けておらず、安定性とはトレードオフになります。 また、Debian では NVMe のインスタンスがサポートされていないという問題点もあります。(以前は Validation エラーが出なかったためハマりどころだった) c.f. github.com externalTraffic: Local の罠 Kubernetes で Service を Type: NodePort でデプロイする時、デフォルトで設定される externalTraffic: Cluster では kube-proxy がそれぞれの Pod に平等にトラフィックを振り分ける関係上、Source IP がその kube-proxy が稼働しているインスタンスの IP になってしまうという問題があります。 これを解決するための手段として externalTraffic: Local を設定するというものがありますが、現在 AWS でこれを実現するためには Type: LoadBalancer な Service に service.beta.kubernetes.io/aws-load-balancer-type: "nlb" を設定してデフォルトで利用される Classic Load Balancer の代わりに Network Load Balancer を利用する必要があります。 本来であればこれで externalTraffic: Local による Source IP の保持が可能になりますが、Network Load Balancer のサポートはまだ beta のため致命的なバグが存在します。 それは VPC の DHCP Options Set の domain-name に依存しているというものです。 この問題に関しては以下の Issue で触れられています。 github.com domain-name が設定されていない場合、kube-proxy が localEndpoints を見つけることができずロードバランシングされなくなります。 この問題は Kubernetes 1.13 で解消する見込みです。 進捗は以下からトラッキングできます。 github.com fluentd-kubernetes-daemonset で文字コードでハマる AWS で Kubernetes を導入する場合、 fluent/fluentd-kubernetes-daemonset を用いて CloudWatch Logs にログを流すのが恐らく一番安上がりで簡単です。 github.com しかし、古き良き日本企業には一つ問題があります。そう、文字コード問題です。 fluent-plugins-nursery/fluent-plugin-cloudwatch-logs では CloudWatch Logs にログを流す際にログを JSON にエンコードしようとします。 しかしこの時、ASCII-8BIT な文字列が流れてきてしまうと UndefinedConversionError として JSON エンコードに失敗してしまいます。 こうなるとログの転送は停止しやがてバッファが溢れてしまうので手を打つ必要があります。 これを解決するには repeatedly/fluent-plugin-record-modifier を使うのがいいでしょう。 github.com Container の command や lifecycle によるハックでプラグインを追加することも可能ですが、新たにイメージをビルドする方が素直だと思います。 プラグインを追加したら以下の filter を fluent/fluentd-kubernetes-daemonset の ConfigMap に追加すれば解消するはずです。 <filter **> type record_modifier char_encoding utf-8 </filter> おわりに まだ枯れているとは言えない領域でそれなりにハマりどころはありましたが、適宜コミュニティへのコントリビューションをしつつ今のところ致命的な問題に遭遇せず運用できています。 Istio を導入することで、今まで車輪の再発明をしていた Retrying, Timeout や Rate Limitting を実行基盤側からアプリケーションに提供することができるようになり、アプリケーションの開発速度向上に寄与することができました。 加えて、CircuitBreaker による障害影響の局所化や、Fault Injection をはじめとした Chaos Engineering に着手する準備も整い、さらなるアプリケーション実行基盤の改善が期待できそうです。 今回 Kubernetes, Istio の導入と共にロギング・監視基盤やデプロイフローの刷新などにも着手していて、LIFULL の技術開発部では分散したアプリケーションをいかにうまく運用するかという点に注力しています。 もしこの辺りに興味のある方がいればまずはカジュアル面談からいかがでしょうか。 https://hrmos.co/pages/lifull/jobs/011 hrmos.co デリバリープラットフォームとして利用している Spinnaker の導入に際して、AWS で Spinnaker の Kubernetes V2 Provider を利用するのにも多少のハックが必要でしたがそれはまたの機会に。

はろーはろー！チバです。 LIFULL HOME'S 賃貸事業部のWebディレクター兼プランナーです。 普段はKPI可視化やサイト改善施策を手掛けるといった業務をしているので、「 プロダクトマネージャーに求められること」や「ユーザーと両想いになるサービスを作るには」を考え抜くことが必要です。 もちろん社内での知見共有も活発におこなわれていますが、今回はメンティのまっつんと2人で会社を飛び出して業界の先輩方の 「愛されるプロダクト」の事例 を聴くために参加してきました！ 「 プロダクトマネージャー・カンファレンス 2018 - 愛されるプロダクトを創ろう」の 参加レポート [ day1 ] です！ 2018.pmconf.jp ※写真撮影していなかったため文字ばかりです ※公開されている関連資料、記事のリンクを貼っているので詳細はそちらを参照ください セッション内容ごとのまとめ [06-01] Welcome Talk 関 満徳（プロダクトマネージャー・カンファレンス 実行委員長） fullvirtue (@fullvirtue) | Twitter もう一つの基調講演のような感じでした。 「自分たちが作り上げたプロダクトが愛されるためにどういうことをしてきたか、どういうことをしていきたいかについて話してください」 このときの関さんの言葉を聞けたので、今日の講演はどういった目線で聴けばいいんだろうを意識できたように思えます。 [06-02] 基調講演: プロダクトマネージャーとは 丹野 瑞紀（プロダクトマネージャー・カンファレンス 実行委員） twitter.com 基調講演であることから、「（PM1年生向け）プロダクトマネージャーの役割」を主軸としたお話。 プロダクトマネージャーの役割の基本のキ 事業目標を達成するためのもっとも効果的な打ち手を考えるのがプロダクトマネージャーだ と言い切られたときに、プロダクトマネージャーは事業会社の組織における課長や部長のような立場の方がなるのかな？と思いました。 事業目標ができたら、まず作る機能を決めるのがプロダクトマネージャーの役割。 具体的には、「売上前年比50%増」といった事業目標（KGI）に対して適切な重要成功要因（CSF）を設定し、機能提案（PRD）をすること。 ただし、機能提案（PRD）とプロダクトの間には大きな溝がある。 プロダクトの機能と事業目標の間には”大きな溝"がある。その溝をエンジニア・デザイナーと協働しながら埋めていくのがプロダクトマネージャー。 ここまで聞いたところで、冒頭で理解した「課長や部長のような立場の方がなる」の理解が誤っていたことに気づきました。 今回のプロダクトマネージャーはRollのひとつとして語られているんですね。 LIFULLでいうところの、サービス企画職がそういった役割になることが多いです。 「行動≠購入」AIDMAの意味が変わった 「AIDMA」モデルの提唱が始まったのは、1920年代。 そのときと比べて、コンシューマーの行動原理が変わっている。 つまり、”A"ctionは ❌行動≠購入 ⭕行動＝利用開始 の方が適しているのではないか、ということ。 「AARRR」モデルの登場 では、利用開始→購入はどういったモデルなんですか？というところで、「AARRR」モデルの登場です。 収益化までつなぐには愛が必要。 「継続利用」が「新規ユーザー獲得」への新たな動線を紡いでくれる。 「継続利用」する人は「紹介」をする。「紹介」してもらうには、「顧客に愛される」ことが必須。 「顧客に愛される」の指標と成り得るのは、「友達に勧める可能性はどれくらいですか？」 。 これまでは推奨度をNPSなどで測っていたが、プロダクトによってはLTRが向いている。 medium.com 関連資料、記事 pmconf2018 keynote speech - Speaker Deck #pmconfjp 2018 まとめ Part.1 「Welcome Talk」〜「基調講演: 愛されるプロダクトを創るべき「3つの理由」」 - Togetter [06-03] FiNCのこれまでの苦悩と今、それとこれから 犬飼 敏貴（株式会社FiNC） twitter.com ヘルスケアの大きな課題「続けたいけど続けられない」がペインポイント 。 「三日坊主」の発生理由は、未来に獲得できるメリットを現時点において実感して信じることができないから。 「ヘルスケアリテラシー」が高い人ほど行動ニーズが高いが、 利用者を増やすには、「ヘルスケアリテラシー」が低く、弱いユーザーにこそヘルスケアサービスが必要。 つまり、 行動ニーズが弱い人に愛してもらえないと長期的に愛してもらえるプロダクトにはできない ！ 「リテラシーが低い人ほど行動ニーズは低い」 こういう構造は他の領域でも言える な〜と思いながら聴いてました。 継続10のファクター 「継続10のファクター」はいわゆる「お約束」となり得るもののこと。 「継続10のファクター」が指標となり、それをユーザーの利用状況にあてはめて○△✕-の四段階で評価した ことで、プロダクトの価値理解や整理が共通認識化できた。 ニーズ育成のための0ベース思考 0ベースを怖がらず、ユーザーバリューの本質を提供する。 プロダクトから本当にユーザーが幸せになるための価値を伝え、ユーザーの新しい行動ニーズとなるように育成していく。 もっとも障害となるのが「一瞬で理解できないUI」。文字の説明を使わずに、情報の優先度やデザイン構成で価値を伝えることにチャレンジしている。 高効率PDCA 高速ではなく高効率 → 精度の高い仮説立案 をしている。 明確な目的・現状把握・変数理解・複数手段が簡潔に正確に伝わるように、会議フォーマットが定義されており 意思決定をスマートに されているとのこと。 精度の高い仮説とは、こうした立案者の考慮+レビュー体制を整えている状態で立案できる ってことなんですね。 やみくもにPDCAを回すと方向を誤ったまま進んでしまうことに気をつけましょう、といったお話でした。 関連資料、記事 未来を作るプロダクトづくりへの挑戦 - Speaker Deck #pmconfjp 2018 まとめ Part.2 「未来を変えるプロダクト作りへの挑戦 ～FiNCの今までとこれから～」 - Togetter [06-04] 世界で愛されるプロダクトを作ろう 熊谷 亘太郎（楽天株式会社） 海外から日本への旅行者が増えた結果、Booking.comが楽天トラベルの半分の売り上げ規模になってきてる。（まじかと思ってBooking.com使ってみたけどなるほど使い勝手いいしゲストハウスの掲載も多いですね） 世界で通用するプロダクトは、最初からGeneralizeを視野に入れている 。 日本に閉じず、世界で求められる要件をはっきり理解することが、世界に出ていくプロダクトをつくるうえで重要。だから刷新をきめた。 PMとしてのコミュニケーションで大事なこと posivive *問題は必ず解決できるという態度 positiveな態度を取っていると、人がついてくる open communication issueを深く掘り下げて最適な解決策を提供 バグトリアージで、プロダクトマネージャーだけが言えること cut feature 「機能を削ろう」 won't fix 「これはやらない（改修しない）」 発生したbugはすべて直すべきかというとそうじゃないっていうのが人によって認識ずれがち 。 重要度と緊急度から判断して、そもそも機能自体を失くそうという判断もあるし、影響小さくエッジケースなのでいったん直さずに置いておく判断もある。 それの判断をPMができる。限られた時間をいかにに重要な部分に使えるかが鍵！ 関連資料、記事 #pmconfjp 2018 まとめ Part.3 「世界で愛されるプロダクトを作ろう」 - Togetter [06-05] [対談] 食文化を支えるプロダクトマネージャーの仕事術 荒井 茂太（株式会社ノンピ 取締役）／及川 卓也（プロダクトマネージャー・カンファレンス 実行委員） 多様性溢れる組織になったことなどのお話全般為になりましたが、特にプロダクトにも通ずると思ったメモを共有します。 グーグル社食（無料のカフェテリア）での食べ残し問題を解決する為にやったこと サラダバーをセルフサービスで盛れるようにしている。 「美味しかったから、今回はもっと食べよう」といって過剰な量をとってしまいがち 。 それにより、食べ残しが問題となっていた。 そこで2つの試みを実施した。 社員が下げ膳する際に、スタッフが「お口に合いませんでしたか？」「体調悪いですか？」と声をかけた 食べ残しの処分も自分たちでさせた。捨てさせることで捨てられている量を可視化させて自分が食べる限界量を学習してもらった 以上2つの試みで食べ残しが減少した件、Webサービスへも活用できる事例となりそうと感じました。 関連資料、記事 食文化を支える プロダクトマネージャーの仕事術 #pmconfjp #pmconfjp 2018 まとめ Part.4 「［対談］食文化を支えるプロダクトマネージャーの仕事術」 - Togetter [06-06] クチコミサイトからプラットフォームへの挑戦プロセス 吉松 徹郎（株式会社アイスタイル） 皆知ってる@cosmeのお話。 実は、 口コミの多い人気商品と、実売データ（POS）は連動性が薄い 。 メーカーにとっては、 * コンシューマー→消費者 * カスタマー→小売店 なので小売店の仕入れ量を変えることが必要。 メーカーは消費者データを持っていないが、@cosmeは膨大な量のユーザーデータを持っているから今後はそれを活用したプラットフォームの構築を強化していきたい。 関連資料、記事 20181106 istyle pm coference #pmconfjp 2018 まとめ Part.5 「クチコミサイトからプラットフォームへの挑戦プロセス」 - Togetter [06-07] プロダクトマネージャーにもコーチは必要だ 鈴木 雄介（グロース・アーキテクチャ＆チームス株式会社） 成長するとコミュニケーションは増える。 顧客からの機能要望 技術的な課題とコスト/スケジュール 会社の方向性とプロダクトの方向性 運営を効率的に回すための要望 増えたぶん、もちろんコミュニケーションの偏りと認識齟齬が生まれる。 そこで、 スーパープロダクトマネージャーを求めるのではなく、組織としてプロダクトマネージメントに取り組むべき ことを必要と説く！ 共有するから自律的に動けるのであり、そうすることによって組織としてプロダクトマネジメントに取り組むことができる。 例えば、 リードタイム、リリースサイクル、プロセスなどの【リズムの共有】 アイデア段階、検討中、実装可能などの【ステータスの共有】 売上、コスト、フィードバックなどの【KPIの共有】 以上を共有せずにプロダクトマネージャーとしての振る舞いは求められない。 これらのコーチングが必要であればご相談ください、とのこと。 関連資料、記事 プロダクトマネージャーにもコーチが必要だ - #pmconfjp 2018 #pmconfjp 2018 まとめ Part.6 「プロダクトマネージャーにもコーチは必要だ」 - Togetter [06-08] ユーザーと両想いになるサービスの作り方 金田 悠希（株式会社エウレカ） twitter.com リリース前、リリース後、拡大期の各フェーズで戦略が違う。 1. リリース前：先行プレイヤーとどう価値を分けるべきか 先行事例の観察と、うまく行ってるタイプの満たしている価値の言語化。 これは満たさなきゃダメだよねって軸探し（当たり前クオリティの追求かな？）。 2. リリース直後：価値をどのように拡げていくか 市場でNo.1でないと意味がない、ユーザーは覚えていてくれない。 また、ネットで出会うということへの不安が強い日本。「安心」であることは常に重要な価値として守りながら成長を目指した。 しかしあるとき、 女子大生「Pairsって安心で利用できているのに、なんでああゆうクリエイティブ（局部を強調したような広告）を利用しているんですか？」 と言われてクリエイティブを守らなければダメだとあらためて意識。 3. 拡大期：市場を拡大しながら自分たちも成長する 現在やっていること * 幸せレポート：実際どう出会って結婚までいったのかを取り上げている * 実際のお客様に会いに行って利用してくれてありがとうを言いに行く * カスタマーサクセスに注力している * 競合の機能を追従するのでなく、ユーザーの変化と向き合う 関連資料、記事 ユーザーと両想いになるサービスの作り方 - Speaker Deck #pmconfjp 2018 まとめ Part.7 「ユーザーと両想いになるサービスの作り方」 - Togetter [06-09] インターネットテレビ局「AbemaTV」プロダクトの変遷 長瀬 慶重（株式会社サイバーエージェント） twitter.com プロダクトマネージャーとは マネージャー：組織成果を最大化させる プロダクトマネージャー：プロダクトの成果を最大化させる 「オンデマンド」ではなく「リニア」よりに作ったのは、テレビのように受け身で情報や娯楽を得られることが、「ネットからマスメディアを作る」に近いと感じたから。 流入に成功した施策 AbemaTVのコメントtwitterシェア機能は、Abemaでコメントするとその前後10秒くらいの動画がTwitterに投稿できる（Twitterカードの仕組みのことかな？）。 インフィードが当たり前になってきており、ユーザー的にもTwitter上で広告動画が再生されることは当たり前になっている。 そういった、 ユーザーを取り巻く「当たり前の事象」を逃さず に利用する。 話題を絶やさない工夫 事業を加速させる開発も優先しがちだが、 ある一定のタイミングで話題性を埋める・技術的チャレンジができるローンチ をかけている。 そうなると、その分野は エンジニアからのアイデアや発想が必要不可欠 。 リニア・オンデマンドを分けなかった理由 リニアとオンデマンドの共存（オンデマンドのナビゲーションをどこに配置するかに2年かかった）を決断した事象は、 「見逃し録画機能」がユーザーの当たり前 になっていたことから。 「テレビといえばビデオ録画だよね。入れないとね」といった 当たり前 は採用していく。 関連資料、記事 インターネットテレビ局「AbemaTV」プロダクトの変遷 #pmconfjp 2018 まとめ Part.8 「インターネットテレビ局「AbemaTV」プロダクトの変遷」 - Togetter 500億の先行投資をしている「AbemaTV」のGrowth戦略とは？ | 株式会社AbemaTV [06-10] 事業ドメインを絞り込むことで磨かれるプロダクトマネジメントの手法 清水 智雄（ピクシブ株式会） 短期間で多数のサービスをリリースできた理由 事業ドメインを絞ると、社員全員が同じドメインにいることとなる。 そのため、 体制変更が柔軟・高速に行えるし技術の統一やドメイン知識が高いレベルで共有される 。 仕事をしていく中で自然と知見が蓄積されるし、場合によっては 技術の応用が効くのでより高速でのリリースが可能。 ユーザーの理解者 プロダクトマネージャーは特定領域（ドメイン）のプロフェッショナルになることが重要 。 誰よりも その領域について理解し、流れを把握し、考え、未来を描くことができ れば、誰よりも一歩先を歩み続けることができる。 例えば、ピクシブは「創作活動」にまつわるドメインにおいては世界中の誰よりも理解し、考え続けることができる。 理解者であることがユーザーに伝わると、ユーザーからも次第に愛されていくプロダクトとなる。 関連資料、記事 事業ドメインを絞り込むことで磨かれるプロダクトマネジメント - Speaker Deck #pmconfjp 2018 まとめ Part.9 「事業ドメインを絞り込むことで磨かれるプロダクトマネジメント」 - Togetter [06-11] 愛されるプロダクトマネージャーのプロダクトマネジメント~愛されるためにまずは成果を残す~ 金山 裕樹（株式会社ZOZOテクノロジーズ） twitter.com プロダクトマネージャーチームの結成のためにリクルーティングを開始。 採用専任チームはなく、1年以内に数字が必要であり、社内にロールモデルとなるPMがいない…といった不利状況があったため、自らがダイレクトリクルーティングすることとした。 リクルーティングのMUST条件 失敗を恐れず挑戦できる：U30 若手寄りであること 行動から学びを得ることができる：教育バックグラウンド（出身高校偏差値65以上） 学ぶ習慣や学び方を知っている・経験したことがあるであろうフィルタのひとつ チームから尊敬を勝ち取れる：ネット業界在籍 必ずしも有名人でなくともいいが、ネット業界における経歴を持っている人 オンボーディング施策「花を持たす」 優秀な人を採用しても「あとよろしく〜」はできない。 入社までではなく、活躍させられるところまでが採用 。 入社前にトップ、PM間で入社3ヶ月以内に達成する成果を明確にする トップがその成果にコミットし達成する 成果を社内に大きくアナウンスする 花をもたせて信頼を得ることができ、 花をもたせることでその人の振る舞いは変わる。優秀な人がさらに成果を出してくれる状態に できる。 関連資料、記事 愛されるプロダクトマネージャーの プロダクトマネジメント - Speaker Deck #pmconfjp 2018 まとめ Part.10 「愛されるプロダクトマネージャーのプロダクトマネジメント~愛されるためにまずは成果を残す~」 - Togetter [06-12] LINE開発の舞台裏とプロダクトマネージャー 入江 和孝（LINE株式会社） twitter.com プロダクトマネージャーは「愛され」なくなることも往々にしてあるので、「愛され」はじめることがとにかく重要という語り出し。 PMの仕事は成果でしか見えることが出来ない 意思決定や部門間調整が多く仕事をしていないように見えちゃう 上流の業務にいたり頻繁な意思決定の変更が多いので警戒されやすい LINEのプロダクトマネージャーに求められること 目に見える数値の変化だけでなく、 文化の違いや変化を理解し続ける努力 意見を尊重した上で結論を出す 決断力 ＆時には自分の意見を曲げる 柔軟性 熱量の高い市場の声に耐えながら、 本質と向き合い続けるタフさ 多くのユーザーフィードバック ほんの一部のユーザーが騒いだら炎上 ユーザー像やペルソナ像が絞れない ユーザーのITリテラシーに下限がない ユーザーリサーチ（ゲリラリサーチ）やってみた 日本人「LINEトーク画面にクリスマスで雪降らせるのは北半球だけでええやろ」 タイ人「うちにも降らせて！」 日本人「は？（現地へ行ってみる）」 タイの街並みは、クリスマスシーズンには雪モチーフのイルミネーションで溢れてる。 日本人「なるほど。 思い込みでユーザを取り巻く環境を決めつけていた のか」 関連資料、記事 LINE開発の舞台裏とプロダクトマネージャー #pmconfjp 2018 まとめ Part.11 「LINE開発の舞台裏とプロダクトマネージャー」 - Togetter LINE開発の舞台裏について話してきたこと｜Kazutaka Irie｜note [06-13] 失敗をデザインする 泉 雄介（ラクスル株式会社） 何を開発するかを決めていないと莫大な予算がかかってしまう。 よく誤解されがちなのが、「ソフトウェア開発は安い」と思われていること。むしろ莫大なお金がかかる！ 六本木ヒルズの建設費は2,600億規模だが、みずほ銀行のシステムは4,000億規模 と言われている。 リリースしてから失敗に気づいても遅い。 だからリリースする前に失敗をたくさんする。失敗する前提でプロセスを組む。 例えば、 ラグビー選手は雨が降るとパスが狂うので、雨が降った想定でボールに石鹸を塗って練習する などしている。 同じ失敗に気づくのであれば、安く作ったもので失敗したほうが損も少ない。失敗に備えろ！ プロトタイプを作って→ユーザーテストして→プロトタイプ作って→ユーザーテストして…の繰り返し。 その際、 ユーザーテストから仮説ではなくFactを探す、「実際何に困ったのか？」 を。それをユーザーインタビュー対象者そのものを意識して、「石川さんはこういった状況のときにこういった操作ができずに困り〜」などの文脈で話す。 仮説が正しいかどうかを検証し、学ぶことを仕事にする。 関連資料、記事 https://2018.pmconf.jp/assets/files/speakers-contents/pmconfjp2018_raksul.pdf #pmconfjp 2018 まとめ Part.12 「失敗をデザインする」 - Togetter [06-14] クロージング 関 満徳（プロダクトマネージャー・カンファレンス 実行委員長） twitter.com 【感想】参加してみて 昨年参加できずに悔しい思いをしたので、今年こそは！とカンファレンスサイトのオープンを待ち焦がれていました。 それぞれのスピーカーによってプロダクトマネージャーの定義が異なっていましたが、組織の規模やプロダクトのステージによって話は変わるかとも思うので、結果的によかったと思っています。 また、“プロダクト”マネージャーの話だったので、他のカンファレンスと比べても ユーザーへ価値を届けることに対する話題へ熱量が集まっていた ように感じられました。 テーマが「愛されるプロダクトを創ろう」なので、より熱さを感じたのかもしれません。 今回参加したことで、 顕在ユーザーに今以上に愛されるLIFULL HOME'Sにしたい 、 潜在ユーザーにLIFULL HOME'Sを選んでもらいたい！愛されたい！ と思える熱量がより高まりました。 すぐにでも試してみたいといった事例も多く、本当に参加してよかったです。 さっそく社内でも共有していきたいと思います。 今後の参加レポ投稿予定 あと2つほど、プロダクトマネージャーConference2018で記事を公開する予定です。 day 2参加レポート（メンティのまっつんが後日公開してくれる予定） 総まとめ座談会（2人で全2日間のセッション内容について得た学びをフリートークする予定） 乞うご期待ください！ チバ

こんにちは。 木村 修平@LIFULLジンジニア(エンジニア人事) (@kimkimniyans) | Twitter です。 昨今エンジニア経験者が開発部門以外のポジションで仕事することも増えてますね。 そんなエンジニアあるあるで、 ちょっとスクリプト書くだけで周りから魔法使いか神扱いされる っていうのがありまして。 例に漏れずそんなことがあって大変うれしいのですが、悦に浸るだけではもったいないので何したか吐き出しておきます。 GAS初学者の方にもお役に立てれば。 　 　 お題は、『インフルエンザ予防接種の希望日程を申し込むフォーム』です。 これまでは希望に応じて日程ごとに振り分けを手作業でやっていたそうで、すごい時間かかっていたようです。 　 　 画面イメージとざっくり仕様 　 回答送信時に、希望日程ごとの定員上限数と突き合わせして定員上限に達していればフォームから選択肢削除。 例）11/1(木)15:00-16:00、11/1(木)16:00-17:00、11/1(木)17:00-18:00、11/2(金)15:00-16:00、11/2(金)16:00-17:00、11/2(金)17:00-18:00 設問は日程の選択肢プルダウンとその他リクエストのテキストで両方非必須。 選択肢から削除された場合、削除された旨をchatwork（専用のグループチャット）に通知。 すべての選択肢が削除された場合、全日程満員である旨と次の設問にリクエストを記載してほしい旨の選択肢を追加。その選択肢の定員数上限はもちろんなし。 今回は送信タイミングでの回答数チェックはしていません。なので厳密には上限を超えることがあります。 FormApp使ってガシガシっと いくつかの.gsファイルに分割したのでそれごとにコメントで説明します。 片手間タスクだったのでレビューも受けてないし雑でごめんなさい。 公式リファレンスは こちら です。 main.gs グローバル変数である必要ないけどまとめて記載。global領域だとconstで定数宣言できない（？）みたいです。 var ROOM_MAXIM = 40; // 日程ごとの最大人数 var ARY_CHOICE_VAL = [ "11/1(木)15:00-16:00" , "11/1(木)16:00-17:00" , "11/1(木)17:00-18:00" , "11/2(金)15:00-16:00" , "11/2(金)16:00-17:00" , "11/2(金)17:00-18:00" ] ; // 選択肢VALUEを配列に確保 var CHOICE_LENGTH = ARY_CHOICE_VAL.length; // 選択肢の数 var TMP_NEW_CHOICE_VAL = "全日程満員です。次の設問で希望の日程を入力してください" ; // 通常選択肢が全て無くなった後に追加する選択肢VALUE var STR_TARGET_TITLE = "希望日程" ; // 処理の対象とする質問タイトル名 /** * フォーム送信時イベント（初期処理） */ function onSend(e) { reBuildItem(e.response.getItemResponses()); //functionの引数eからイベント発生時の回答時のレスポンス取得して受け渡し } onSendメソッドをプロジェクトのトリガー（フォーム送信時イベント）に設定しています。 編集タブ→「現在のプロジェクトのトリガー」で設定できます。 ui.gs 回答データとの突き合わせとUI項目の操作。前者は別メソッドにしたいっちゃしたいけどまぁいいです。回答データの取得もここでコールしてます。 /** * 選択肢の再構築 * * @param {array} 選択肢ごとの回答カウントデータ配列 */ function reBuildItem(rAnswer) { var form = FormApp.getActiveForm();　 //アクティブなformオブジェクトを取得 var items = form.getItems(); // フォームのUI項目を取得 var allAnswer = getAnswer(); // 全回答の取得 // 今回の回答を取得（※プルダウンUIで未選択の場合は回答データに含まれない模様です※） var nowAnswerVal = rAnswer [ 0 ] .getResponse(); var nowAnswerTitle = rAnswer [ 0 ] .getItem().getTitle(); if (nowAnswerTitle == STR_TARGET_TITLE) { // 「希望日程」プルダウンで未選択の場合は何もしない（項目タイトルで判断） for ( var i = 0; i < items.length; i++) { // UI項目分ループ var item = items [ i ] ; var itemTitle = String (item.getTitle()); var itemType = String (item.getType()); // UI項目のタイプ if (itemType == "LIST" && itemTitle == STR_TARGET_TITLE) { // リストボックスかつ項目タイトルが対象の場合 var choiceArray = [] ; var arrayCount = 0 var flgChoiceNone = false ; // 回答突き合わせ後選択肢が残るか否かのフラグ for ( var j = 0; j < CHOICE_LENGTH; j++) { // リスト選択肢分ループ var choiceVal = ARY_CHOICE_VAL [ j ] ; var flgSet = false ; // 上限内か否かのフラグ if (flgChoiceNone == false ) { // 選択肢がまだ残っている場合 if (j == 0 && nowAnswerVal == TMP_NEW_CHOICE_VAL) { // 選択肢が全て無くなった後の追加選択肢のチェックはスルーする flgChoiceNone = true ; } else { if (allAnswer [ j ] < ROOM_MAXIM) { // 回答上限チェック flgSet = true ; } } } if (flgSet == true ) { // 回答上限に達してない選択肢は退避 choiceArray [ arrayCount ] = choiceVal; arrayCount++; } else { if (choiceVal == nowAnswerVal) { // 今回の回答だった場合 sendChatwork(nowAnswerVal); // 満枠になったことをchatwork通知する } } } if (arrayCount == 0) { // 選択肢が全てなくなった場合 choiceArray [ arrayCount ] = TMP_NEW_CHOICE_VAL; // 追加選択肢をセット } // リストボックス作り直し item.asListItem().setChoiceValues(choiceArray); } } } } 　 ちなみに、''Logger.log(hoge);''でログ出力できます。デバッグに必須です。 実行後、表示タブ→ログから確認できます。 answer.gs 回答データの全取得と選択肢ごとにカウントして返します。 /** * 回答データの取得 * 回答データが取得できない（例外の場合）エラースロー * * @return {array} 選択肢ごとの回答カウントデータ配列 */ function getAnswer() { var form = FormApp.getActiveForm(); var formResponses = form.getResponses(); // 全回答内容を取得 var aryAnswerCount = [] ; // 選択肢分配列定義 for ( var k = 0; k < CHOICE_LENGTH; k++) { // 配列をゼロで初期化（fillメソッド使えないので） aryAnswerCount [ k ] = 0; } var flgAnswer = false ; for ( var i = 0; i < formResponses.length; i++) { flgAnswer = true ; var formResponse = formResponses [ i ] ; // 回答ひとつ分を取得 var itemResponses = formResponse.getItemResponses(); // 質問項目を取得 for ( var j = 0; j < itemResponses.length; j++) { 　 // 回答内容をひとつずつチェック var itemResponse = itemResponses [ j ] ; var question = itemResponse.getItem().getTitle(); var answer = itemResponse.getResponse(); if (question == STR_TARGET_TITLE) { // 項目タイトルが対象の場合 var x = ARY_CHOICE_VAL.indexOf(answer); if (x != -1) { // 選択肢ごとに回答数カウント aryAnswerCount [ x ] ++; } } } } if (flgAnswer == false ) { // 例外：回答がまだなければエラー吐いて終了 throw new Error( "not Answer" ); } else { return aryAnswerCount; } } chatwork.gs バックオフィスも含めて弊社公式に採用しているchatworkのとあるグループチャットに満枠になったら通知するメソッドです。 chatwork通知の方法はググったらすぐ出てくるので詳細は割愛します。 chatwork通知例 /** * chatwork通知処理 * * @param {string} 回答した選択肢タイトル */ function sendChatwork(rChoiceVal) { const CW_TOKEN = "hogehoge" ; //チャットワークトークン const CW_ROOM = 1111111; // 通知先のチャットルームID var client = ChatWorkClient.factory( { token: CW_TOKEN } ); // チャットワークAPI var strBody = "[info][title]Googleフォームから通知[/title]インフルエンザ予防接種で以下の日程が満席になりました。 \n " + rChoiceVal + " \n " + "[編集用URLでも記載するといいと思います]" + "[/info]" ; client.sendMessage( { //チャットワークに送る room_id: CW_ROOM, body: strBody } ); } 　 結論 色々できそうでできなかったり もっとちゃんと考えればやれることとか違うやり方とかあるんでしょうけど、GASでのフォーム操作は結構なパワープレイな感じでオススメしません。 要件がシンプルな場合はいいかと思います。 とはいえ、特に今回のようなバックオフィスタスクの負荷軽減には役に立つと思うのでちょっとのjsスキルと利他の気持ちでパパっとやれるのはいいですね。 LIFULLでは当たり前のようにこういった周囲へのサポートがあります。 よかったら参考にしてください。

こんにちは！　 木村 修平@LIFULLジンジニア(エンジニア人事) (@kimkimniyans) | Twitter です。 今年も残すところあと僅か。2018年やり残したことはないですか？ 12月は皆さん仕事に遊びに忙しいと思いますが、LIFULLも精力的に活動しています！ 皆さんにお知らせしたいことがたくさんあるので紹介しちゃいます。 　 Ltech #3 ＆ #4 12/11(火)に Ltech#3 【podcast × IT】LT Night ! を開催いたします！ lifull.connpass.com 昨今盛り上がっている技術系Podcastをネタにライトニングトークする、年末らしくワイワイ楽しい会にしたいと思います。 ちょっとしたおつまみやドリンクもご用意しております。 また、参加者全員投票で選出されたベストスピーカーにはちょっとした景品をご用意しております。 LT枠まだご応募可能ですのでご応募お待ちしております！ そして、 12/20(木)には、Ltech#4 Dotfiles Casual Talks を開催予定です！ lifull.connpass.com こちらもご参加登録お待ちしております！ 奮ってご参加ください。 CTO 長沢 翼のキャリアインタビュー記事のご紹介 エンジニア@type 様にCTOの長沢 翼（ Tsubasa Nagasawa (@nagasawatsubasa) | Twitter ）のキャリアをテーマにしたインタビュー記事が公開されました。 type.jp 新卒入社からCTOに就任したキャリアの秘訣を熱く語っています！ ぜひ御覧ください。 LIFULL job talk データサイエンティストや機械学習エンジニア向けに、 この秋新設しました『AI戦略室』の戦略やエンジニアリングについてお伝えするイベントを12/17(月)に開催します！ lifull.connpass.com 過去から積極的に機械学習などの技術を積極的に利用・研究しておりましたが、新たに部署を構え更に注力していきます。 ご好評で既に満枠となっておりますが、今後、追加開催も検討しておりますのでご期待ください。 PHP Conference 2018 いよいよ開催が迫ってきましたPHP Conference 2018にスポンサー＆ブース出展の予定です。 【告知】PHP Conference 2018にスポンサーします！ - LIFULL Creators Blog 新ノベルティも出来上がってきましたのでぜひブースに遊びにきてください！ ホームズくんのカワイイクッキーや新ステッカーをご用意していますよ。 Advent Calendar 2018 そして12月といえばAdvent Calendarですね！ LIFULLもQiitaで公開していますのでぜひご覧になってください。 今年もLIFULL Advent Calendar 2018をよろしくお願いします - LIFULL Creators Blog 　 　 最後までご覧いただきありがとうございました。 2018年最後の一ヶ月、楽しんでいきましょー！ 　 Information LIFULLでは、一緒に働くメンバーを募集しています！ ご興味がある方ぜひご覧いただきご応募ください。 hrmos.co

こんにちは。クリエイターの日運営委員のおおばです。 今回は、社内のモノづくりイベント『創民祭』が開催されましたので、その様子を共有させていただきます。 2015年から始まった創民祭も早いもので、7回目の開催になりました。 創民祭とは 創民祭（そうみんさい）とは、LIFULLで半年に1回開催される社内展示会です。 お酒を飲んだり、ピザを食べながら、業務の成果や「クリエイターの日」、プライベートで創ったものをお披露目するイベントです。 前回の様子はこちら。 www.lifull.blog 今回のテーマ せっかく足を運んでもらうので、よりLIVE感を大切に！と企画を進めました。 そして、今回もたくさん魅力的なブースが展示されました。 今までのブース出展に加え、今回からの初企画！「ライブコーディング対決」や「にがおえやさん」などのイベントも開催し、有志による「コーヒーやさん」、「スムージーやさん」も出展してもらえました。   展示内容 今回、過去最多の13ブースです！ 内容もWebに限らず色々なクリエイティブが出展されるようになってきています。 当日、出展されたいくつかのプロダクトを紹介していきます。 イラストレーターさんがで描いてくれる！『にがおえやさん』 創民祭に来場した人を、その場で似顔絵をかく、そのまんま「にがおえやさん」！ 弊社デザイナー + エンジニア の計4名が協力して描いてくれました。 お客さんの特徴を捉え、わずか数分で仕上げていく、イラスト力が光ります。 若手 vs 若手のペアプロバトル！『ライブコーディング対決』 お題に沿ってペアで開発していく、そしてその様子が実況されていく、その名も…「ライブコーディング」イベント！ 新卒3年目エンジニアの2人 vs 新卒2年目エンジニア + デザイナーの対決でした。 進捗を実況解説されるプレッシャーの中で、黙々と実装を進める面々。最後はベテランエンジニアが審査をします。 今回はVue.jsを使って、機能面にこだわった3年目チームの勝利！！2年目チームはリベンジマッチを決意しました。 廃棄野菜を再利用したスムージー『Clean smoothie』 写真はすごい緑で野菜の味がしそうですが…飲んでみると冷たくて美味しいです！野菜嫌いでもおいしくいただけました。 実はこのスムージー、弊社の事業提案制度で生まれた「Clean smoothie」というサービスです。 Instagramやってます。（ http://picdeer.com/clean_smoothie_ ） オフィス向けに廃棄野菜や規格外野菜を買い取ってスムージーを作り、農家もオフィスワーカーも、みんな元気な社会を目指してるとのことです。 導入企業、仕入先農家両方を絶賛募集中ですので、気になる方はご連絡を！ 弊社ではもうおなじみ『コーヒーやさん』 弊社では水曜15時にコーヒーやさんがきます。正確には、コーヒーが趣味の社員がリフレッシュルームでコーヒーを振る舞ってくれます！ 今回は出張コーヒーやさんで、創民祭でも美味しいコーヒーを淹れてくれました。 今回は特別な豆を使ってくださったらしい…！どうやら豆ごとに最適な淹れ方があるらしく、贅沢な一時でした。 趣味で作成したandroidアプリ『割り勘オンライン』 趣味で作成されたという会計アプリ！ 飲み会などで誰かが立て替えた後、自分の返すお金を計算してくれるアプリ。 カラオケ、二次会…とイベント別で勘定するのではなく、まとめて一人何円です！と計算してくれる機能。 忙しいときでも手早く計算できて、実用的ですよね。 『ジオラマ作品展示』 創民祭は過去、アプリやWebサービスが多かったのですが、、、初！ジオラマの展示になります！ 実は過去、様々なコンテストでも入賞経験があるという実力者！ 『単に景色を切り取るのではなく、作品の中にストーリーを感じられる。』そんな作品づくりを心がけているそうです。 「模型大好き！」（ http://www.mokeidaisuki.com/ ）というサイトでも、ジオラマの様子が公開されていますので、気になった方はそちらもチェックしてみてください！   ちょっと不思議で怖い、でも可愛いイラスト『Gothic Gallery』 プライベートでイラスト制作を行っている方の展示です！ 「あなたの日常に毒とスパイスを」をコンセプトに、ちょっと不思議で怖い、でも可愛い…そんなイラストです。 コピックペンで描いたあと、PCで色塗りや仕上げをしているとのこと！ 丁寧な仕上がりでとても可愛いイラストばかりでした！ 『オンラインブレスト』 オンラインでブレストができる「オンラインブレスト」！ 以前の創民祭でプロトタイプが出展されていましたが、パワーアップして再登場！ こちらも事業提案制度から生まれたプロダクトなのですが、実際に他社でも利用が開始しています。 創民祭の間も、「こんなものづくりイベントやってほしい！」というテーマで実際にブレストが繰り広げられていました。 公開中のオンラインブレストサイトはこちらです。 https://brest.nabimoon.com/ 手書きもいいけどメールでも感謝を伝えよう『サンクスカード Web』 弊社には「サンクスカード」という、感謝を伝えたい人にメッセージカードを渡す文化があります。 これまでは名刺サイズのカードに筆記する形だったのですが、有志によりついにWebサービス化されました！ サイトにメッセージを入力すると、相手にメールが届きます。 クリエイターの日の活動で開発しており、裏側はサーバーレスで動いています。 その他 その他、LIFULL HOME'Sの新機能開発や、ハッカソンで開発したIoTのアプリケーション、街の雰囲気が分かる地図のアプリケーションなど、魅力的なプロダクトが出展されていました。 また、Lightning TalkではAIとレコメンドについてのお話を噛み砕いて伝えてくれたり、Sonic Piというライブコーディング可能なシンセサイザーを使った、エモすぎる発表も素敵でした。 最後に 第7回目の創民祭。 内容も回を追うごとにパワーアップしており、どんどん多様になってきています。 こういったイベントで刺激をうけると、モノづくりの楽しさを実感して、自分自身ももっと新しいことに挑戦していきたいと感化されますね！ それでは！ 次回、半年後の創民祭もご期待下さい！ LIFULLでは、一緒に働くメンバーを募集しています！ご興味がある方ぜひご覧いただきご応募ください！ hrmos.co

エンジニアの鈴木( Kentaro SUZUKI (@szk3) | Twitter )です。 ついに本日で re:Invent 2018は終了になりました。よって、参加レポートもこれで最後になります。 すこしre:Playに触れた後に、総括していきます。 re:Play 昨晩 Keynote 2日目の夜は、re:Playというパーティーが開催されました。 reinvent.awsevents.com 自分も参加してきましたが、昨年以上にド派手で楽しい思い出になりました。 Twitterなどで探すと、動画を上げてらっしゃる方が多いので是非一度ご覧頂きたいと思います。 翌朝、re:Playも明け最終日を迎えた会場は人も少なくなり 会場全体が撤収モード になります。 そんな光景を見ていると、「あー、今年も終わっちゃった...」と実感が湧いてきます。 では、 re:Invent 2018 総括 です。 re:Invent 2018 を振り返る 参加期間中は、この記事 + Qiitaを含め合計8つのフィードバックを出すことができました。 総括としてブログを振り返っていきます。 参加レポート1 この記事では、「なぜre:Inventに参加するのか？」について自分なりの答えをシェアしています。 カンファレンスが始まる前に、現場にいる方に読んでもらいたく投稿しました。 www.lifull.blog 参加レポート2 新しく発表されたRoboMakerについてハンズオンした内容になります。 まさかRobot来るとは思わなかったわー。 www.lifull.blog 参加レポート3 - The Quad / Chalk Talk re:Inventは聞く一方だけではありません、体験したり、ディスカッションする場も設けられています。 www.lifull.blog 参加レポート4 - Keynote AWS CEO Andy JassyのKeynoteを受け、思うことをまとめました。 （なので紹介されたサービスについては記述されてません！） www.lifull.blog 参加レポート5 - DeepRacer ML学習環境としてのDeepRacerは、大人も子供楽しめるので要チェックですね。 www.lifull.blog 参加レポート6 - AWS SDK for JavaScript (TypeScript) 新しいJSの AWS SDK は TypeScript で書き直されています。それについてのChalk Talkに参加してきた内容のフィードバックです。 www.lifull.blog まとめ 自分は、今回で3回目の参加になります。 1回目も2回目も、かなり刺激が強かったのですが、3回目でも昨年と違うブレイクスルーを実感できるのは、 それだけ心を揺さぶられる振り幅が大きいからだと感じています。 同じ場所、同じ空気、同じタイミングで re:Inventに参加するという共通項が、世界中の開発者が楽しそうに参加してくる大きな理由のひとつ だと毎年感じます。 新しい出会いもたくさんありました。 企業同士で具体的なテーマについてディスカッションさせて頂いたり、 近くで生バンドが爆音で演奏している中、組織や抱える課題についてお話させていただいたり、 DeepRacerのWorkshopで同じテーブルになった方と一緒にレース場に行ったり、 re:PlayではAWSの中の方とお話させていただくことができました。 また、Facebookでのre:Invent 2018 コミュニティーグループには何度となく助けていただきました。 皆様の素晴らしいホスピタリティにはかなり支えていただきました。ありがとうございました。 今年もre:Inventに参加することができて本当にうれしく思います。 送り出してくれた、家族・会社・同僚には感謝しかありません。 次のアクションは、このre:Inventの経験や出来事をどう活かすかです。 帰国したら自分にできることで、社内外に貢献し続けていきたいと思います。 コミュニティグループ含め、現地でお話させていただきました皆様ありがとうございました。 re:Cap等ご予定あって、登壇者に困っている方は Kentaro SUZUKI (@szk3) | Twitter までお気軽にご連絡ください！ いろんな視点でフィードバックできます！ ひきつづき頑張るよー

お疲れ様です。基盤Gの今井です。 Hands-on Labsに参加してきたので、所感を記載いたします。 Hands-on Labsとは 　検証用のサンドボックス環境で実際にAWSサービスを実習を行います。 　カタログから、実習対象サービスと内容を選択し、シナリオに沿って自分のペースで学習が可能です。 　また、申込み予約が不要で、席が空き次第、実施可能なのもありがたかったです。（回転が早いため、ほぼ待つことなく参加できました。） 　 開催場所 　The Venetian（主要会場）にて、開催されます。 開催時間 　登録用の初日と、最終日を除き、毎日以下の時間で参加可能でした。 11/26 08:00 ~ 16:00 11/27 08:00 ~ 16:00 11/28 08:00 ~ 16:00 11/29 08:00 ~ 16:00 参加に関して 　ラボ参加に関して、最初にアカウント作成が求められます。登録時のメールアドレスがアカウントになりますが、登録後に対象メールアドレス宛にアカウント認証用メールが送信されます。その為、即時、確認が可能なメールアドレスで登録されることをお勧めいたします。 　また、シナリオは全て英語でしたが、何をすれば良いのかが分かりやすく、手順を間違うことはありませんでしたので、英語初心者＆専門知識無しでも、安心して参加できました。 各Hands-on Labs内容と感想 Introduction to Amazon EC2 Auto Scaling 　AWS EC2 Autoscallingを１から構築する手順が、分かり易く纏められていました。 Introduction to Amazon Machine Learning 　機械学習を用いたクラス分類の精度評価のための混同行列を学びつつ、機械学習の初期導入が学べました。 　上記Auto Scalingと同様に、こちらも１から構築する手順が、分かり易く纏められており、導入・学習としては良かったです。 　また、Machine Learning（※AWSサービス名）が必要な設定を任意で対応してくれるため、初心者でも機械学習がやりやすかったです。

お疲れ様です。基盤Gの今井です。 各Keynoteに参加してきたので、所感を記載いたします。 Keynoteとは 　AWSに関する基調講演となり、AWS全体に関する内容が発表されます。今年も、11/28(火)、11/29(水)、11/30(木)と計3回開催されました。 　新機能・サービスも併せて公開され、発表された機能・サービスのセッションが即時公開されるため、注意が必要とのことです。今回は、11/28にAWS DeepRacer発表後にMGMでWorkshopが公開されていました。 開催場所 　The Venetian（主要会場）にて、開催されます。 但し、その他の会場（ARIA、Bellage、Mirage、MGM）と公式アプリでライブ公開され、視聴可能です。発表後1時間程度の遅れはありますが、以下のYoutubeチャネルでも視聴可能となります。 www.youtube.com 開催時間 　大体、08:30 開始で約2時間 ~ 2時間半の間で開催されます。主要会場での参加人数がかなり多いため、参加するなら開始１時間前から並ぶか、ライブ配信で閲覧されるのも1つの手だと思われます。 アプリ 　Keynoteでは、同時通訳で行われ、以下のアプリをスマホにインストールし、告知されるWIFIに接続するか、Keynote会場時に入口左側のTranslation Table でヘッドセットを借りることで、通訳された内容を公聴可能でした。 Hearing Hotspot Williams Sound, LLC Productivity Free play.google.com 各Keynote内容 11/27(火) 　AWSパートナーのためのエコシステムやglobal allianceでした。（次のセッションがあったため、あまり聞けなかった） 11/28(水) 　Keynoteとしては、さすがメインだけあって、今回も大量の新サービスが公開されていましたが、個人的に気になるのは以下のサービスでした。 　※各コンテンツの概要は、 AWS re:Invent 2018 で発表された新サービスと機能 | AWS で確認できます。 AWS Control Tower AWS Security Hub AWS Managed Blockchain AWS Lake Formation Amazon Timestream SageMaker Ground Truth Amazon SageMaker RL Marketplace for machine learning Amazon Elastic Inference 11/29(木) 　前日が完全新規サービスが多かったのに対して、この日は既存サービスの拡張が多めでした。その中でも、個人的に気になるのは以下のサービスでした。 ALBでLambda functionをターゲットとして、選択可能 LambdaでのCustom Runtime の利用可能 参加した感想 　昨日のDevSecOps関連システムインフラ系のセッションなどでも感じましたが、システムを代替しうるマネージドサービス公開の可能性を考慮し、システムを単一機能で、システム間を疎結合にて構築し、構造をシンプルかつフレキシブルに変更可能に設計する事が今以上に必要になってきたと考えています。

お疲れ様です。基盤Gの今井です。 Japan Nigthtに参加してきたので、所感を記載いたします。 Japan Night Japan Nightとは 　日本からのre:Invent参加者限定のパーティーです。 登録 　登録は、AWS re:Invent 2018 japanのサイトにて登録可能です。Japan Night単独でも大丈夫でした。 開催場所・日時 　今回は、ARIA で11/27(火) 18:45 開始。 当日参加に必要なもの 　以下のものが必要でした。 プリントした参加チケット パスポート 参加ノベルティ 参加した感想 　今回は800人以上の方が参加され、かなり混んでいました。が、いろんな方々と交流することができ、楽しかったです！！

エンジニアの鈴木( Kentaro SUZUKI (@szk3) | Twitter )です。 Amazon.com CTO Werner Vogels が登壇するKeynoteでは、Serverless関連の大型アップデート・新サービスが大量に発表されました。 Wernerの動画はコンテンツも良いのですが、AWS CEO のAndyと同様にプレゼンの勉強になるのでオススメです！ www.youtube.com どうしても派手なアップデートに目が行きがちな re:Invent ですが、 各会場で行われるセッションでは、re:Invent前に発表された 地味だけど嬉しいアップデート についても紹介されます。 今回は AWS SDK for JavaScript の Version 3についての Chalk Talk に参加してきたのでレポートします。 Introduction to Version 3 of the AWS SDK for JavaScript (TypeScript) … Introduction to Version 3 of the AWS SDK for JavaScript (TypeScript) Chalk Talkでディスカッションする内容は、約10日くらい前にアナウンスされた新しいAWS SDK のものです。 aws.amazon.com AWS SDK for JavaScriptは現在v2ですが、開発者プレビューのversion3が公開されています。 リポジトリはこちらになります。 github.com version３の特徴を見ていきましょう。 TypeScript 一番の変更点ですが、 TypeScript で書かれています。 TypeScriptによる恩恵は、エディタによる補完や型推論などを通じて開発効率に現れます。 Google社内でも公式言語として採用されていますし、 www.publickey1.jp かの有名なVSCodeもTypeScriptで書かれています。 github.com ちょっと話がそれますが、VSCodeは re:Inventで発表されたAWS Toolkitsの対応エディタ(現時点ではpreview)のひとつに選ばれるくらい人気があります。 New – AWS Toolkits for PyCharm, IntelliJ (Preview), and Visual Studio Code (Preview) | AWS News Blog VSCodeを触ったことがなく興味のある方は、以前まとめた記事が参考になるかもしれません。 よろしければご覧ください。 qiita.com モジュール化 aws-sdk v2がモノリシックな設計だったのに対し、 v3ではモジュール化を意識した設計 になっています。 そのため、v2に比べていくらかサイズが小さくなっています。 SDKのサイズが小さいことはダウンロードやアップロード時間も短くなるので良いことですね。 一般的なWebにおいては、 速さは正義 です。 v2の特徴としては、使わないAWS Serviceのクライアントなどもまるっとインクルードされていた為、サービスクライアントを個別にインポートする必要はありませんでした。 しかし、それは本当に便利だったのでしょうか？ たとえば、S3のサービスクライアントしか使わないようなアプリに対して、EC2やEMRなどのサービスクライアントは不要だと思います。 なので、各ソースコードで必要最低限のサービスクライアントをインポートすることでコードの軽量化を含め多くの恩恵が受けられるようになることは、自然な流れだと思いました。 また、ブラウザ側とnode.js側のSDKを分けることで影響範囲を少なくすることにも成功しています。 たとえば、StreamなどNode.jsとブラウザでインターフェイスが違うようなものに関しても、両方のパッケージで適切に処理することができます。 いい感じですね、モジュール化。 プロミス化 各サービスクライアントの非同期的なAPI呼び出しは、コールバックからプロミスに変更されました。 (v2でもAWS Requestオブジェクトのpromise()関数からPromiseオブジェクトを取得することはできます) いままでは、Promiseオブジェクトを取得する際はpromise()関数を呼び出す必要がありました。 v3ではpromise()関数を経由せずにPromiseオブジェクトが取得できるため、スッキリかけそうです。 さらに aync/await で 統一されていると可読性も高くて嬉しい ですね。 グローバルな設定の廃止 v2では各クライアントのコンストラクタに設定を渡すと、グローバルな設定とマージされるような挙動をします。 そのため、この機能が一部の状態下において混乱のもとになっていました。 そのようなフィードバックを元に、 v3からは各サービスクライアントごとに設定することになります。 これは個人的にはすごく良い変更だと思っていて、昨今のアーキテクチャではマルチリージョンで運用するサービス増えているし、 状態としてサービスクライアントに閉じ込めるのはとても自然に感じます。 質問 Chalk Talkだったので、テスト周辺モジュールについて直接質問してみました。 Q「aws sdkってテストがめんどくさいんだけど、mock とか stubとかそういう機能をオフィシャルにサポートする無いの？やっぱりsinonとかproxyquire使ったほうがいい？ 」 A「そういう予定はないけど、aws-mockとかあるから使ってみたら。あと○ｘｋｌｓｊｆｗｆｋｊ....」 ... ふむ。なるほど。 わからん。。。 残念ながら英語力不足で最後のセンテンスを聞き取れませんでした。 反省としては、会話の中のaws-mockというキーワードを得ることで満足してしまったところです。 遠慮せずに、「もっとゆっくり話して」って言えばよかったですね。。。 多様な英語に触れてコミュニケーションの経験値を積んで行こうと思います。 ちなみに、その後、ホテルに戻ってきてリポジトリのソースコードを読んでると、テストコードではMockはjestを使っているようでした。 jestjs.io まとめ このChalk Talkの参加人数は、ざっくり約30人くらいでした。 他のセッションと比べると圧倒的に会場も小さく、人も少ないです。 ですが、小さい会場において、 手を伸ばせばすぐ届く距離感だからこそ、登壇者の勢いや伝えたい箇所が強く伝わって来るような気がします。 前回のChalk Talkと比べて、登壇者とリスナーが新しいSDKについて積極的にディスカッションしていたのも印象的でしたね。 個人的な参加目的のひとつとして「AWSのエンジニアに 技術的な質問を英語でする 」という ミッションをひとつを達成できたので、一歩前進 という意味でも満足したChalk Talkになりました。 Chalk Talkのような小さいセッションでも手を抜かないのが、re:Inventのいいところ ですね。 次回は、re:Invent 2018 の総括です。

エンジニアの鈴木( Kentaro SUZUKI (@szk3) | Twitter )です。 AWS のカンファレンス re:Invent に来ています！ これでもかというくらい新サービスが発表されるので、嬉しい悲鳴とはいえキャッチアップが結構大変です。 そんな人に向けて、これはスゴい！と思うサービスを厳選した記事をQiitaに投稿していますので、ご覧いただければ幸いです。 qiita.com さて、本記事では先日発表された DeepRacerについてのレポート です。 https://aws.amazon.com/jp/deepracer/ より引用 aws.amazon.com AWS DeepRacer DeepRacerは、Keynote 1日目の中で発表されました。 機械学習を学ぶための取っ掛かりとして、こんなに面白そうなものがでてきたのは自分が知る限り初めてです。 Keynote最中に、amazon.comでの販売が発表されたので、即カートにいれました。 決済のタイミングで、去年のDeepLensのことが頭をよぎります。 これは、もしや。。。 ビンゴ、 日本には発送できない とのこと。残念すぎる。。。 そして、Keynoteを最後まで見た後は次のセッションに向かう為にバスに乗りました。 Workshop 弊社CTO 長沢( Tsubasa Nagasawa@LIFULL CTO (@nagasawatsubasa) | Twitter )と「Workshopが追加されたら行ってみよう」みたいな談笑をしながら、 re:Inventアプリでスケジュールをチェックしていると、なんと！ Workshopある じゃん！ 次のセッションをキャンセルしてDeepRacerのWorkshopに向かうことにしました。 当初の予定から フレキシブルに予定を変えられるのも、re:Inventの楽しみ方のひとつ ですね。 しかし、ふたりがかりでチャレンジしても 一向に予約が取れません 。かなりの数のリピートセッションが表示されてるにもかかわらず全部ダメそう。。。 しかたがないので、ダメ元でWalk-up(予約できなかった人)の列に並ぶことにします。 バスが会場に付き、足早にWorkshopの開催される場所に向かうと、もうすでにかなりの行列が。。。 最後尾に並び、あとは入れることを祈るのみです。 Workshop開催10分前ぐらいになると、Walk-upに並んでいた人が部屋に案内されていきました。 もっと全然ダメかと思いきや、意外とすんなりとテーブルに付くことができました。 運がいい 。 さぁ、いよいよWorkshopが始まります。ワクワクしてきました！ Workshopの内容は、以下のリポジトリに沿って行われました。 github.com やることを簡単に説明すると、サーキットのコースをよく早くゴールに辿り着けるように機械学習させたモデルを作ってみようという内容です。 そのモデルの学習経過とシミュレーション内容は、AWSのWebコンソール上で全て確認できるようになっています。 ここにも、 昨日 レポート したRoboMakerのシミュレーション技術 が使われているようでした。 各自自分のペースで資料に沿って、Workshopを進めていきます。 学習が終わるのを待つ間に、Workshopでは同じテーブルの参加者同士でどうやったら精度があがるのか？みたいな会話をしました。 結局、学習に時間がかかりLab1までしか終わりませんでしたが、Workshopの終わりにサプライズが。 DeepRacer ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!! ファシリテーターの方が、講演台の下から取り出したのは紛れもなく 実物のDeepRacer!!! また、Workshopで作ったモデルを特設会場のDeepRacerにデプロイして走らせることが可能で、Workshop参加者はDeepRacerが頂けるとのことでした！ Amazing （っていうか一体いくらかけてるの???）すぎる。 MGM Speedway 特設会場はめちゃくちゃ広く、本気の遊び心に溢れています。 このサーキットは観客としてみることもできるので、ナレーターがレースの様子をレポートしたり、参加者へのインタビューを行ったりしていました。 本格的過ぎますね。 まとめ 自分もWorkshop後日にサーキットに行きましたが、残念ながら自分のモデルで走らせることはできませんでした。 その時間帯は参加者が多く、次のセッションにどうしても出たかった都合上、自分の順番が回ってくるまえにその場を離れることになったからです。 DeepRacerは、大人向けだけでなく子供向け（むしろこっちがターゲット？）としてもかなり有益だと思います。 こういう体験でテクノロジーを学び、そのテクノロジーを使って世界を変えていく。 DeepRacerを通じて、そんなループを回す子供たちがたくさん出てきそうな予感がしました！