技術開発部の相原です。好きな --feature-gates はServiceTopologyです。 この記事は LIFULLアドベントカレンダー の16日目です。 去年のエントリでは Istio を本番環境に導入するまで と題して、私のチームが進めているアプリケーション実行基盤刷新プロジェクトでのIstioの導入についてお伝えしました。 移行に至るまでの経緯などはそのエントリをご覧ください。 あれからしばらくが経ち、ようやく主要サービスの(ほぼ)全てをKubernetesに移行することができましたので今回は移行を実現するまでに行った取り組みを紹介したいと思います。 移行にあたってやったこと 健全化 構成の見直し アプリケーションサーバの見直し Containerize SIGTERMへの対応 環境ごとの値を外から与えられるように 可観測性の向上 Prometheus Exporter実装による可視化 ログフォーマットの標準化と構造化 移行を支えた仕組み 負荷テスト Shadow Proxy Kubernetes Manifest作成補助 今後の移行を支える仕組み ガイドラインの整備 育成・啓蒙 移行にあたってやったこと 移行前の状態としては、去年のエントリでお伝えした通り数年前にオンプレミスからAWSに移行し、それに伴ってマイクロサービス化を推進している、というものでした。 ただマイクロサービス化が推進されているとは言ってもIstio導入のモチベーションになったように分散システム的な難しさに対する解決策も持ち合わせていなければ、アプリケーション自体もそれに即した構成や設計になっておらず、マイクロサービス化の実現からは程遠い状態でした。 そうした課題を受け、我々のチームではKubernetesに移行するにあたって大きく分けて3つの対応が必要だと置きました。 まずは対象アプリケーションの 健全化 、そして Containerize と 可観測性の向上 です。 ここからはそれぞれの対応について詳細に触れていきます。 健全化 構成の見直し オンプレミスからAWSへの移行をリフト&シフトで進めてきたこともあり、OSのバージョンやアプリケーションが利用するライブラリ・ミドルウェアのバージョンが古いままになっているという状態でした。 またプロビジョニングスクリプトもなんとなくはあるものの、実際に本番環境で動いているものと微妙に差異があったりというような状況で、まずはここの健全化から着手することにしました。 これを機に極力Alpine Linuxでライブラリやミドルウェアのバージョンを上げながらプロビジョニングをし直し、Alpine Linuxへの切り替えが難しいものはAWSでKubernetesを運用しているということもあってAmazon Linux2に載せ替えていきました。 もちろんKubernetesに移行するにあたって不必要となるミドルウェアの削除や構成の変更が必要となるものにも適宜対応する必要があるので、このタイミングでFHSへの準拠なども済ませながらアプリケーションの構成をあるべき姿にしていきます。 アプリケーションサーバの見直し アプリケーションサーバも同様に適切な設定がされているとは言えない状況でした。 LIFULLの主要サービスではRuby, PHPの採用が多く、Giant VM Lockを備えるRubyはもちろんのこと、PHPでもCPUのコア数に応じてアプリケーションサーバのプロセス数を調整する必要があります。 KubernetesのHPAではCPUバウンドなアプリケーションは基本的にCPUの使用率でオートスケールすることを期待するため、ここの調整が足りない場合アプリケーションサーバのプロセスを使い果たしているにも関わらずスケールアウトの閾値までCPUを使いきれないという事態が起きてしまいます。 そこで、以下のような手順でアプリケーションサーバのプロセス数の見直しを行いました。 本番相当のトラフィックのシナリオテストを用意して、シングルコアでの性能限界を明らかにする KubernetesのDownwardAPIを用いてコンテナの requests に指定したCPUのunit数に応じて動的にアプリケーションサーバのプロセス数を変更できるようにする DownwardAPIによって requests したCPUのunit数を環境変数として取得できるので、それを用いてプロセス数を設定するようにする シングルコアの性能限界をもとにトラフィックのピーク時にアプリケーションサーバが数台落ちても問題ない程度までスケールアップさせる 仮にピーク時トラフィックをアプリケーションサーバ4台で捌ける程度までスケールアップさせてしまうと1台落ちた時のインパクトが大きい Kubernetesで Pod を Evict から保護する Pod Disruption Budget の台数が落ちることは考慮しておくこと リソース割り当て量を1コアなどと細かくしてコンテナ単位でスケールアウトするという戦略も考えられますが、モニタリングシステムへの負荷が高まったりアプリケーションのCopy on Writeの効率が悪くなってしまうため好ましくありません。 この他にも今までおざなりになっていたヘルスチェックの見直しなども行い、ヘルスチェックがリバースプロキシだけでなくきちんとアプリケーションサーバまで到達しているのか、Pod内にRedisなどのレプリカを持つ場合きちんとレプリケーション遅延を見ているか、といった点を考慮しながら適切なヘルスチェックを設定しています。 Containerize SIGTERMへの対応 Kubernetes移行においてもっとも大切なアプリケーションのContainerizeのための対応はSIGTERMの適切なハンドリングです。 SIGTERMをGraceful Shutdownとして認識しないウェブサーバやアプリケーションサーバは少なくなく、そうしたアプリケーションをそのままデプロイしてしまうとKubernetesではPodの終了時にリクエストが欠損してしまいます。 アプリケーションがシグナルを解釈できるのであればアプリケーションの改修、そうでなければ preStop フックを使ってSIGTERMが送られる前にGraceful Shutdownが実行されるよう対応を行う必要があります。 また、この際KubernetesのEndpoints ControllerによるEndpointの更新とコンテナへのSIGTERMの送信の順番が保証されないという点にも注意しなければなりません。 つまり、SIGTERMが送られてからもリクエストが到達してしまう可能性があるということで、SIGTERMが送信される前に実行される preStop によって一定秒数のスリープを入れるかSIGTERMを受け取っても一定秒数新規のリクエストを処理できるようにする必要があります。 後者の対応をしている例としては CoreDNS の health プラグインの lameduck などが挙げられます。 CoreDNS では lameduck を利用することでKubernetes環境における安全なGraceful Shutdownに対応しています。(kopsなどで単純にCoreDNSを使うようにするとこの設定がされていないためご注意ください) 環境ごとの値を外から与えられるように Twelve Factor Appにあるように、Kubernetesにデプロイするアプリケーションでは環境固有の値は環境変数から与えられるように作ることが好ましいです。 The Twelve-Factor App （日本語訳） 個人的にはドキュメンテーションの観点からコマンドラインのオプションとして与えられるように作ることを推奨していますが、今回は既存アプリケーションの移行ということもあり純粋に環境変数から読むような変更を加えていました。 アプリケーションでの対応が難しい場合はConfigMapとして設定ファイルを切り出したり、 envsubst を使うなどして環境固有の設定に対応することになります。 他にはphp.iniの memory_limit やアプリケーションのロガーの logrotate といったKubernetesに移行することで不要となる設定・実装の調整や、LIFULLではIstioを採用しているためIstioによって提供されるRetrying, Timeout, Circuit Breakerに伴う実装の調整などを行いました。 可観測性の向上 Prometheus Exporter実装による可視化 Kubernetesでは cadvisor や kube-state-metrics から得られるメトリクスで概ねの監視を行うことができますが、アプリケーションの監視となるとこれらの情報だけでは足りません。 アプリケーションサーバのアクティブなプロセス数やin-flightなリクエスト数、ヒープのサイズやGCのメトリクスなど気にしなければならない点は多くあります。 元々Prometheusをクラスタの監視に利用していたため、移行した全てのアプリケーションにPrometheus Exporterの実装を行いました。 基本的にはOpenCensusを利用しつつも、対応していない言語・アプリケーションサーバでは適宜ライブラリを利用しつつ監視に必要なメトリクスを公開するようにしていきます。 LIFULLが運営する LIFULL HOME'S ではトラフィックに季節要因があるため、PrometheusのLong-term Storageとして thanos を運用して長期のメトリクスを保存しています。 github.com ログフォーマットの標準化と構造化 メトリクスときたら次はログです。 LIFULLでは今まで各ウェブサーバのデフォルトのログフォーマットを利用していることが多かったため、まずはログフォーマットの標準化から始めました。 ロガーによってはJSONに対応していなかったりするので、ここでは標準のログフォーマットとしてLTSVを定義しました。 LTSVとはTab-separatedなLabelとValueの組み合わせのフォーマットです。 そしてそれをfluentdでパースしてJSONに構造化、そしてCloudWatch Logsに流すためログをラベルごとにグルーピングして投げるようにしました。(fluentd-kubernetes-daemonset辺りを丸使いしてCloudWatch Logsに流すと一つの巨大なロググループが生成されて使いづらいので自前でfluentd pluginを書いて対応しています) また、歴史的背景からログに秘匿情報が含まれていて閲覧できる開発者に制限があるといった問題があったため、秘匿情報のマスキングを行えるfluentd pluginもあわせて開発し、全ての開発者が当たり前にログを閲覧できる環境を整えました。 これまた歴史的背景によるアーキテクチャからistio-proxyを導入できなかったアプリケーションがあるため実現には至っていませんが、アクセスログは将来的にはIstioの logentry に逃がす予定があります。 新規に開発するマイクロサービスを対象に分散トレーシングの徐々に導入を増やしていたり、アプリケーションの脆弱性情報の収集と可視化、APIエンドポイントごとのエラーレート・レスポンスタイム可視化といった取り組みも進めています。 またちょっと変わったところでアプリケーションが利用しているリソース量からかかっているコストを按分するような仕組みも作っています。 移行を支えた仕組み ここからはこうしたアプリケーションのKubernetes移行を支えた仕組みについて書きます。 負荷テスト Kubernetes移行においては、先に述べたSIGTERMのハンドリングのテストや正しくHPAの閾値通りにスケールアウトするかどうかのテスト、またVPAなどはありつつも割り当てるリソース量のキャパシティプランニングなども必要となるため、負荷テストあるいはベンチマークといったことが大切になります。 Istioコミュニティの fortio であればKubernetes内で特定のアプリケーションに気軽に負荷をかけることができるのですが、スケールアウトなどのテストでは本番トラフィックと同等のものでないとテストの意味を成しません。 また、複数台からの負荷のエミュレーションを行いたいといった要求もあったため、シナリオテストが可能な vegeta を複数台で並行実行可能なKubernetes Controllerを開発して利用しています。 github.com 作りは単純で、KubernetesのJobの仕組みを使ってCRDによって定義された内容の負荷テストを並行実行するというものです。 これを利用して入念なテストを行うことで大きなトラブルなく移行を進めることができました。 Shadow Proxy 前項で移行を試みるアプリケーションが本番トラフィック相当を捌けることは確認できましたが、移行後もアプリケーションの全ての機能が稼働するかどうかまでは確認できていません。 そうしたことをテストするために我々のチームではShadow Proxyパターンによるテストを実施しています。 Shadow Proxyパターンとはサーバに対するあるリクエストをミラーリングして別のサーバにも送信するというテストの手法で、Traffic MirroringやShadowingとも呼ばれていてIstioでもTraffic Mirroringとして機能が用意されています。 istio.io Kubernetes移行においてはNATされたIPが変化することによって外部APIへのIP認証で弾かれたり、多くの場合プロビジョニングをし直しているためサーバ構成が変化して特定の機能が動かなくなったりすることがままあります。 観測範囲でもgolangの特定のOracleクライアントライブラリがKubernetes移行によって動かなくなるといったことを確認しており、こういった網羅的なテストは必須だと考えます。 そのため前段のリバースプロキシに、あるいは前段のリバースプロキシのアクセスログを元にして、Shadow Proxyを用意してKubernetes上で一定期間リクエストを捌いて動作を確認するといった工程を実施しています。 また、LIFULLではBuckyという自動システムテストツールを開発しており、併せてBuckyによるテストも実施することで移行後も正常にアプリケーションが稼働することを確認しています。 www.lifull.blog Kubernetes Manifest作成補助 Kubernetes Manifestを書く際には考慮しなければならないベストプラクティスが多くあり、不慣れな開発者が理想のKubernetes Manifestを書き上げることは非常に困難です。 そこで、我々のチームでは1枚のyamlを記述するとLIFULLにおける最適な構成のKubernetes Manifestをkustomize形式で出力するコマンドラインツールを用意しています。 Helm や、Microsoftの Open Application Model のように独自のCRDを定義することも選択肢としてはあり得ますが、柔軟性・移行のしやすさ・将来的に開発者に流暢にKubernetes Manifestを書いて欲しいという思いから今の形に落ち着きました。 他にも監視用のダッシュボードやアラートの設定を生成するブートストラップのようなものを用意するなど、移行をスムーズに進めるためのツール群を開発しています。 今後の移行を支える仕組み これで主要サービスの(ほぼ)全てがKubernetesに移行されたわけですが、LIFULLでは 「あらゆるLIFEを、FULLに。」 ということで今後も多くのサービスを開発し運用していかなければなりません。 そこで未来への取り組みも徐々に始めているので最後にそちらを紹介して終えたいと思います。 ガイドラインの整備 アプリケーションの品質を一定以上に保つため、上述のSIGTERMへの対応や環境固有の値の取り扱いなどといった、いわゆるクラウドネイティブなアプリケーションの開発をするためのガイドラインを整備しています。 このガイドラインには他に例えば以下のような内容のものがあります。 ランタイムの起動速度の遅いVM言語などを採用する場合はコンテナのスケールメリットと相反することを理解すること 無暗なインメモリキャッシュはライフタイムの短いコンテナと相性が悪いことを理解すること Prometheus 用のメトリクスを公開するための /metrics エンドポイントを用意すること Istioから提供されるCircuit Breakerのような機能を再実装しないこと Istioが提供する機能の再実装を推奨しないことは移植可能性などを鑑みると賛否ある気はしますが、こういったガイドラインを整備することでKubernetes及びそのエコシステムから提供される恩恵を開発者が最大限享受できたり、開発されるアプリケーションの品質の担保ができるよう取り組んでいます。 育成・啓蒙 非常に良くないことなのですが、このプロジェクトは半年前まで私一人でKubernetesを中心としたアプリケーション実行基盤の構築・運用とアプリケーションの移行を行っていて、現在はメンバーが1人ジョインしたものの社内でこの2人に知見が集中している状態になってしまっています。 そこで我々のチームでは 留学 と称した期間限定の他部署メンバーの受け入れや、社内勉強会の開催を始めました。 留学 は短期のタスクを用意して全社から留学を希望するメンバーを募り、その期間我々がサポートをしながらタスクをこなしてもらうという取り組みです。 これにより社員にこの領域の知見をつけてもらうと共に、中長期的なキャリアの選択肢として意識してもらうということを狙っています。 日々の運用や移行以外にも認証基盤の開発や時系列分析によるスケジューリングの最適化など、よりよいアプリケーション実行基盤にするための改善活動を続けていることもあって、週次の成果を全社に公開したり定期的にリリースノートを公開するといった取り組みも始めています。 育成や啓蒙は目下最大の課題で、今後はここに注力していくことになりそうです。 そんなLIFULLではメンバーを募集しているのでまずはカジュアル面談からでもいかがでしょうか。 hrmos.co

こんにちは！品質改善推進ユニットの 藤澤 です。 この記事は LIFULLアドベントカレンダー3 の15日目です。 今年のアドベントカレンダーは何を書こうかと考えていたところ、CTOからお題が飛んできました。 ゼロから立ち上げてきたというのは正しくなく、最初に立ち上げた方は他にいまして、取り組みの一つひとつもみんなの積み重ねですが、現在この組織で歴史を一番長く知っている人間として、代表してLIFULLの品質組織の歴史や取り組みをご紹介したいと思います。 誰に何を伝えたいか 品質管理・品質保証の仕事は正解がありません。ビジネスドメインや会社の文化、構造によって、やるべきことは変わってきます。 しかし事業会社における品質担当者が実際どんな仕事をしているかについての情報は、勉強会が盛んな現在においても、見かける機会が多くありません。 そこで、この記事では当社の品質組織に関して、これまでの歴史や取り組みをまるっとお伝えして、どこかで悩んでいるどなたかの、何かのご参考になることがあれば嬉しいなと思います。 LIFULLの品質組織の現在 現在のLIFULLの品質組織は、一つのユニットの中で、5つのグループに分かれて活動しています。 品質改善推進ユニット QAグループ いわゆるソフトウェアテストの専門部署。「テスト計画コンシェルジュ」と呼んでいる社内向けサービスや探索的テストなどのテストに関する技術でものづくりチームを支援。 SETグループ Software Engineer in Test。テストを自動化する技術を駆使しして不具合流出を阻止。デプロイフローの改善も担当し開発者体験の向上を目指している。 ユーザーファースト推進グループ 人間中心設計やユーザーテストに関する技術と知見を提供。ユーザーの本当の声を集めて事業部に提供している。 セキュリティ グループ ソフトウェアセキュリティの専門化チーム。脆弱性診断、各種ガイドライン整備、セキュリティを可視化する仕組みを作り、プロダクトセキュリティをものづくりチームと一緒に守りつつ、緊急時には対応支援も行う。 品質管理グループ 品質組織が立ち上がった時からある老舗のグループ。社内障害情報の把握や社内横断的なルールの調整、開発に関するツールの整備などをはじめ、品質良くするために必要なことであれば、分野を問わずサポートからヒップキックまで何でもやる。 現在はこれらの5つのグループが開発チームと一緒になってサービス開発を行っていますが、LIFULLの品質組織の始まりは9年前、「品質管理グループ」という名前の、たった2名の一つのグループとして始まりました。 以下、3年づつ初期、中期、後期に分けてどんな取り組みを行ってきたかご紹介します。 LIFULLの品質組織の歴史 初期(2011年~2013年頃) 2010年10月頃からグループ立ち上げ準備がはじまり、2011年4月に「品質管理グループ」という部署が正式に発足しました。 記憶に残っている最初の仕事は、当時サービス品質において一番インパクトが大きい問題であったインフラ故障に起因するサービス停止の問題でした。この当時はまだオンプレ環境でサービスが稼働していたのですが、夜間や休日の障害対応体制が整備されておらず、障害発生時には社員ではなく役員がデータセンターに駆けつけて対応し、復旧するまでに4時間もかかるケースがある時代でした。 インフラエンジニアにデータセンターの近くに引っ越してもらう この課題について、以下のようなアプローチで検討を行いました。 インフラ障害によるサービス停止のインパクトを1時間あたりの売上損害金額として算出 障害発生からリカバリーまでの対応を時系列で可視化(例: 認知から状況把握まで15分、データセンター移動まで60分...など) 可視化されたリードタイムと損失金額から目標復旧時間を定め、解決策を検討 結果、障害対応を行う可能性のある部署の方にデータセンターの近くに引っ越していただいたり、そのための手当を会社として導入したりしました(現在はクラウド化によってこの取り組みは今はありません)。 実はこれは私の中途入社後の初仕事だったのですが、必要ならば社員の住居や会社の賃金体系にまで影響するような提案をしても、嫌がられるどころかどんどん話が進んでいきました。この体験が後々、LIFULLの品質組織として取組みを検討していく際に 役割を超えて何かをやっちゃだめ、なんてない と考えられるようになる原体験となりました。 この2011年から始まる3年間では次のような取り組みを行いました。 障害対応 至急の対応が必要な障害が発生したら、全社共有されるチケット管理システムに必ず起票してもらうようにしました。障害チケットが起票されると、障害対応を行っているチームのところにいって、できるだけ邪魔にならないようにしつつ様子を伺い、影響や対応状況を把握して、必要な情報展開を社内に行うようにしました。 これを繰り返すことで以下のような効果がありました どのシステムとどのシステムがつながっているのかが分かってくる 誰がどのシステムに詳しいのかが分かってくる 結果として事後分析や改善のための取り組みの際に社内で動きやすくなる テスト自動化 当時のLIFULL HOME'Sはすでにたくさんの開発者がおり、日々アップデートされるため、サービス全体の仕様を完全に把握するということが不可能な状況でした。また複数のチームが同時に開発を行っているため、影響範囲の考慮漏れによる障害も少なくありませんでした。 対策として回帰テストの自動化を開始。最初はSeleniumIDEというブラウザ操作を記録・再生可能な仕組みを使って回帰テストの自動化を行いましたが、メンテナンス性の低さによりプロジェクトを途中で断念。Page Object Patternを採用したフレームワークをPythonで構築し、第一世代の回帰テストとして運用し始めました。 Pythonによるテスト自動化はある程度うまくいきましたが、LIFULL HOME'Sが掲載する物件情報の表示確認テストにおいては、確認項目の多さとHTMLレイアウトが変更される頻度の高さから、テストスクリプトのメンテナンスコストの増加が懸念となっていき、これを解決する方法として画像の差分比較によるテスト方法がグループ内で提案され、検証活動がこのころに始まっています。 よくある考慮もれチェックリストとRFP 現在も当社で使われている「開発チェックシート」というチェックリストは、このころ導入されました。 障害分析や、開発者アンケート、インタビューの結果をまとめた、設計・実装・テストにおいて確認しておきたい項目をまとめたチェックリストです。 すべてのリポジトリではありませんが、頻繁に開発されているリポジトリでは、このチェックリストの確認が開発の必須工程になっています。 また外注開発におけるRFP(Request For Proposal)の必須化もこのころに行いました。LIFULLは内製開発の経験は多いのですが、外部のパートナー企業と開発を行う経験が少なかったため、外部パートナー企業との開発を内製と同じような感覚で進めてしまって、プロジェクトの途中で問題が生じることがありました。 現在は、一定予算以上の開発ではRFPが必須になっており、テンプレートの提供だけでなく、RFP作成自体も支援する社内向けサービスを品質管理グループから提供しています。 中期(2014年~2016年頃) 初期を「1. 障害対応を起点とする情報収集」、「2. RFP/開発チェックシートによる予防」、「3. 自動テストによる水際阻止」を特徴とすると、中期の特徴は「テスト技術の強化」と「自動テストの進化」です。 「品質管理グループ」と「QAグループ」の2グループ体制へ 開発チェックシートや自動回帰テストの実施によって、組織を横断して年に複数回出現するような類似の障害は減っていったのですが、そういった全体的なアプローチだけでは個別のプロジェクトへの支援は十分ではありませんでした。「このプロジェクトでは絶対にバグを出したくない」と開発者が思うようなプロジェクトで障害を出さないようにするには、テストの技術そのものを高める必要がありました。 組織を分離してスコープを狭めることで、そのスコープの能力を高めるスピードを上げることができると考えました。 そこでグループを2つに分離し、新設された「QAグループ」ではテスト技術を中心とした活動を高めることにしました。 LIFULLでのQAのあり方 会社肝いりの施策や、リスクが高いプロジェクトについてはQAグループが参加し、テストの計画や設計を行います。 また、QAメンバーが直接的に関与しなくても、開発チームがテストの質を高められるようにする取り組みとして「テスト計画コンシェルジュ」という社内向けサービスを行っています。これはプロジェクトにとってちょうどよい品質を作れるように、開発チームとQAが会話をしながら、60分でテスト計画を作成する活動です。また直接支援依頼を受けていない施策も含めてリスク評価を行っており、QA側から声をかけることもあります。このあたりは以下のスライドにまとめられていますので、よろしければこちらもご覧ください。 【Ltech#6 】LIFULLでのQAのあり方 from LIFULL Co., Ltd. www.slideshare.net テスト自動化の進化 初期フェーズで運用が始まっていたPythonで構築したフレームワークですが、数年が経過し、テスト実行時間の増加、大量のメンテナンス、テストシナリオの可読性の低下などの課題が顕在化してきました。 またLIFULL HOME'Sでは週2回(火曜・木曜)をリリース日としていましたが、より高頻度かつ柔軟なリリース調整を可能にするために月~木であれば毎日リリースできる体制に変更することを目指して、自動テストも改善する必要がありました。それまでに構築していた自動テストでは、毎日リリースするにはメンテナンスのコストが高すぎたのです。そこで「運用コストを半減させること」を目指して、LIFULL第三世代の自動テストフレームワークの構築をこのころに開始しました。 このフレームワークでは以下のような機能を盛り込みました。 テスト実行だけでなく、レポートティング機能によって結果を確認しやすくする 自動リトライによってFlakyなテストの結果確認の負担をへらす テスト自動化処理の詳細と、テストシナリオの記述を分離し、かつ成約を設けることで可読性、メンテナンス性を向上させる このフレームワークはその後、OSSとして公開しています。 www.lifull.blog また、初期の頃に検証が始まっていた画像差分テストの仕組みが、このころには2世代目に進化し、 JaSST で発表したりしていました。 この仕組みはその後も改善が続けられ、先日OSSとしても公開しました。 www.lifull.blog 中期のその他の取り組み 長くなってきたので短めに書きますが、この時期に行ったその他活動は以下のようなものがあります。 主要リポジトリのGithub移行とブランチ戦略導入 全社標準のプロジェクト、ナレッジ管理システムとしてJira/Confluenceの導入 サイトレスポンスタイムの継続的監視環境の構築 セキュリティ開発ガイドライン整備とセキュリティ勉強会の実施 ユーザビリティテストの開始 RFPだけでは予防できなかった問題への解決としてのプロジェクトマネジメント支援への進出 後期(2017年~2019年頃) このころ、品質組織内でよく利用していた品質モデルは以下の図です。 このモデルから、Webサービスにとって重要なのは次の4属性であるとしていました。 有用性 (機能性、正確性): 利用者の「成果を挙げられる」または「制約を取り除ける」機能を提供できているか 可用性 (信頼性): 使いたいときに、ストレスなく利用できるかどうか 使用性 (ユーザビリティ、アクセシビリティ): 簡単に、誰でもどんな状況でも使えるか 安全性 (セキュリティ): 安全は守られているか この品質モデルを推進すべく新たに「ユーザーファースト推進グループ」「セキュリティグループ」、そして週4リリースの実現や自動化技術の社内展開で頼もしさを増していた「SETグループ」の3つを加えて、現在の5グループ体制の形が出来たのがこの時期です。 この時期に開始した活動は以下のものがあります。 ユーザーテスト サービスの質を数字だけで判断するのではなく、本当のユーザーの声を聞くことを推進する活動を開始しました。 下図は開発工程におけるユーザーテストの種類とタイミングを説明したものです。 脆弱性診断と脆弱性可視化 Webの脆弱性診断だけでなくスマホアプリケーションの静的解析環境および脆弱性診断を開始しました。 以下のツールやドキュメントに大変お世話になりました。 github.com mobile-security.gitbook.io 失敗DB 開発における失敗情報を蓄積、振り返りを促進する仕組みをConfluence上で構築しました。 品質ダッシュボード 品質モデルに基づく数値をダッシュボード化。収集した情報をDataDogで可視化しています。現在取得している情報には以下があります。 稼働率 HTTPステータス レスポンスタイム アクセシビリティ SEO適合度 SSL証明書有効期限:残日数 変更影響度 (年) (障害報告件数 / リリース件数) まとめ 非常に簡単にですが、私達の品質組織の歴史と取り組みをご紹介させていただきました。 失敗や反省も山程あります。本来は失敗したことのほうが情報として価値があるのかもしれませんが、書き始めると本当に書ききれないので今回は割愛させていただきました。もしそのあたりも含めてご質問やもっと聞いてみたいという方が、もしもいらっしゃいましたら遠慮なく こちら までご連絡ください。いっしょにディスカッションして世の中の品質組織の仕事をみんなでより良くしていきましょう。 また現在、LIFULLでは仲間を募集しております！ カジュアル面談も受付していますのでご興味ある方は是非ご参加ください！ hrmos.co

こんにちは！ LIFULLのSETグループ (Software Engineer in Testグループ)の Ruey です。 前回はE2Eテストで使うテストフレームワーク「Bucky」を公開しました！ www.lifull.blog そして今回はVisual Testingで使う画像差分検知ツール「Gazo-san」を公開しました！ github.com この記事はVisual Testingと「Gazo-san」のポイントを紹介したいと思います。 目次 Visual Testingについて なぜVisual Testingが必要か Visual Testingツールの三要素 撮影機能 📷 差分検知機能 🔍 レポート機能 📑 E2Eテストとの違い E2Eテストは動作の保証、Visual Testingは見た目の保証 Visual Testingはメンテナンス不要 LIFULL SETグループのVisual Testing 撮影部分 差分検知部分 レポート部分 Gazo-san差分検知の仕組み Gazo-sanのポイント パーツごとの差分検知について 最後に 参考資料 Visual Testingについて Visual Testingは皆様も時々耳にすることがあると思います。 ですが、 私が調べた限りでは正式な定義がないようです。 ※ 日本語訳もないので、本記事は全部Visual Testingと表現します。 あるVisual Testingツールのサイトを参照すると、 「Visual testing is how you ensure that your app appears to the user as you intended.」と書かれています。 つまり、 Visual Testingはウェブアプリの「見た目」がユーザーにとって望ましい状態であることを保証するテストです。 参照元： https://applitools.com/blog/visual-testing?nab=4 なぜVisual Testingが必要か フロントエンドの開発だと、htmlやcssやjavascriptなどの組合せによりサイトの見た目がしばしば変更されます。 「見た目」 に影響する要因が多いので、実装後の表示が望ましくない変化（例えば、文字化けや表示崩れなど）、たまにコード上と自分の開発環境では気づかない状況があります。 その際に直接ユーザーと同じ環境でアプリを開いて、目視で確認したほうが安心だと思います。 Visual Testingツールの三要素 でも目視で確認すると、大変ではないですか？😇 実装前後のサイトキャプチャーを取らないといけない。。。 サイトのフルサイズキャプチャーが長いので見辛い。。。 モバイルデバイスと同じ画面を確認しないといけない。。。 細かい差分を目で認識し辛い。。。 数十、数百個のケースを確認すると目が疲れる。。。 いろんな問題点がありますが、良いツールがあれば解消出来そうです。 上記の問題点をまとめると、次の三要素を満たす機能があれば楽にテストできると思います。 撮影機能 差分検知機能 レポート機能 撮影機能 📷 キャプチャーがないと見た目の差分が比較出来ないです。 しかし、レグレッションテストなので、実装前後のタイミングで撮影することが重要です。 ユーザーと同じ見た目で確認したいので、キャプチャーのサイズと特定のモバイル端末の指定も重要です。 差分検知機能 🔍 実装前後のキャプチャーの差分を検知する部分です。 これにより、チェックが必要な部分と必要でない部分が切り分けられるので、確認の工数を削減できると思います。 下図はGazo-sanで差分を検知する例です： 赤い部分は差分がある部分、それ以外は差分がない部分です。確認する時は、赤い部分のみチェックするだけで良いです。 レポート機能 📑 数十、数百の差分画像を確認するのも大変なので、レポート形式だと見やすく、確認の工数も削減できると思います。 テストケースの管理と明確なトレーサビリティも重要なので、ダッシュボードで管理できれば分析も楽になると思います。 E2Eテストとの違い 開発前後の「見た目」の変化を確認するテストなので、レグレッションテストにも含まれます。 同じレグレッションテストによく使われているE2Eテストと比べて、それぞれ保証できる部分は少し違います。 E2EテストはUIの操作を行って、アプリの機能が正しく動作することを保証するテストです。 E2Eテストは動作の保証、Visual Testingは見た目の保証 E2EテストではUIを操作する時にclassやidなどの属性で要素を指定して操作を行います。 その際に、例えば操作対象の要素が違う場所に変わっても、操作が問題なく実行できることが多いです。 つまり表示崩れなどがあった場合、検知できない可能性があります。 そこで、アプリの 「見た目」 の変化を保証するために、Visual Testingを組みあわせて使うのが効果的だと思います。 Visual Testingはメンテナンス不要 ページの要素を操作するE2Eテストはアプリケーションの変更内容に合わせてテストコードを修正する必要があります。 Visual Testingはキャプチャーを撮って比較するだけなので、変更に合わせてのメンテナンスはありません。 ただし、アプリケーションのデータ不備の対応やテスト対象の見直しなどは発生します。 LIFULL SETグループのVisual Testing SETグループがVisual Testingを行う理由は下記の二つです。 見た目の変化を保証するため E2Eテストと組合せてより大きな範囲をカバーするため E2Eテストは実装するための工数がかかりますが、Visual Testingは確認したいページのキャプチャーがあれば実行が可能です。 E2Eテストで確認や実装がし辛い部分をVisual Testingで担保する作戦です。 SETグループは既成のVisual Testingツールを導入しておらず、先ほどの三要素をそれぞれ対応してVisual Testingを実現しています。 撮影部分 Headless Chromeを利用して、サイトのキャプチャーを撮っています。 差分検知部分 今回OSSとして公開した「Gazo-san」を利用して、差分画像を作成しています。 詳しい説明はGazo-san差分検知の仕組みで説明します。 レポート部分 静的サイトのテンプレートを用意し、各ケースの差分詳細ページを作っています。 チェックが必要なケースを見やすくしています。 詳細ページの例： 以上の組合せでリリース前にレポートが自動で生成され、確認が必要な画像差分とその該当ページのチェックを行います。 差分は開発の仕様通りならテストパス、明らかにおかしい場合は該当開発チームに連絡するようにしています。 SETグループのVisual Testingは統合環境で行われており、各開発チームの実装が互いに影響がないかを確認することで、システムテストレベルでアプリ全体の「見た目」を担保しています。 まだまだ改善点があると思いますが、運用自体は問題なく、毎日10分間で150ケースぐらい確認できています。 Gazo-san差分検知の仕組み Gazo-sanの仕組みを紹介する前に、画像差分の検知方法について紹介します。 画像の差分検知の仕組みは大きく分けると、二種類あると思います。 厳密な比較：ピクセルごとの比較 (Pixel perfect testing とも呼ばれます) 曖昧な比較：アルゴリズムによる類似度での比較 (類似度算出のアルゴリズムは色々あります) 厳密な比較は差分を画像上で色を付けてアウトプットすることが多いです。 曖昧な比較は差分は表示されませんが、類似度がアウトプットになります。(True/Falseもしくは %) 厳密な比較 曖昧な比較 メリット 差分を細かく検知できる 1. サイズ違う画像も検知できる 2. 差分が多い場合に影響がない デメリット 1. サイズが違う画像に弱い (差分の箇所が分かりづらい) 2. 差分が多すぎると見辛くなる (赤く塗られた部分が目立つ) 差分を細かく表示することができない Gazo-sanのポイント Gazo-sanは厳密な比較に当てはまりますが、差分の表示箇所が分かり辛い問題に対応するため、特殊な仕組みを使っています。 それは二つの画像をそれぞれ パーツごと分けて、マッチングしたパーツのみ差分を比較 することです。 デモ画像を用いて説明します。 パーツごとの差分検知について 1. 比較する画像入力 変更前 変更後 2. それぞれパーツ画像を作成 変更前 変更後 3. パーツマッチングと差分検知 マッチングし、差分がない マッチングし、差分がある マッチングしない 4. Output画像作成 diff画像はマッチングしたパーツを赤枠で囲み、差分がある部分を赤く塗りつぶしています。 Output_diff delete画像は修正後の画像と比較して、消えたパーツを緑枠で囲んでいます。 Output_delete add画像は修正前の画像と比較して、追加されたパーツを緑枠で囲んでいます。 Output_add このパーツ分けの仕組みによって、サイズが多少ずれても差分表示が見やすくなります。 最後に LIFULLのSETグループはリリース前にVisual Testingを行い、 見た目 がユーザーにとって望ましい状態であることを保証しています。 「 見た目 」のデグレを発見した実績も何回かありますので、Visual Testingがあった方が安心だと思っています。 Gazo-sanを使えば簡単にVisual Testingが出来ます。 皆さんも是非お試しください。 また、Gazo-sanの他にもVisual Testing専門のツールは沢山あります。 自分のチームに合うツールを選択して使ってみるのが良いかと思います。 Gazo-sanも改善できるところはまだまだあると思っているので、issue、PullRequestもお待ちしてます。 皆さんも楽しくVisual Testingをやっていきましょう！ 参考資料 5分でわかるVISUAL TESTING FOR HTML5 What is Visual Testing? A comprehensive explanation. - Applitools Blog

CTOの 長沢 です。 この記事は LIFULLアドベントカレンダー の11日目です。 現在LIFULL(単体)は正社員160名超のエンジニアの組織になっており、それぞれ特徴的で素晴らしいメンバーが沢山在籍しています！ そのような組織の中で、CTOとしてエンジニア組織や戦略を考えることが多いのですが、 今回は、マネジメントしてきた中で、経験から学び今現在も意識している育成に関することを抜粋して書こうと思います。 CTOとしてやってきたことなどの取り組みは、 昨年のAWSJさんが主催のCTO Night&Dayイベントで登壇させていただいた時の資料なども合わせてご覧いただければと嬉しいです！ 【CTO Night＆Day 2018】CTOとしてエンジニアに対して責任を持ち続けること from LIFULL Co., Ltd. www.slideshare.net こちらのような話は、また、別記事でまとめます。 主にマネージャー・リーダー向けの観点が多いですが、そうでない方々も一人ひとりが意識すれば動きやすくなるかな、と思います。 キャリアデザインに沿った育成がとても大事 評価は育成 メンバーのキャリアデザインを知る 「動機の源」を知る 適切に情報を伝える 1on1 準備 初めての相手に聞くこと 毎回聞くこと 4半期に1度ほど聞くこと 最後に キャリアデザインに沿った育成がとても大事 これは、言わずもがな、ですね。 会社が 組織として継続的に成果を出し、競争に勝ち抜いていく上で、個々のメンバーが成長して活躍することは必要不可欠 だと思っています。 特に、各個人のキャリアデザインに沿わせながら育成をしていくことは内発的動機観点、モチベーションの観点でも非常に大切です。 別の話になりますが、中途採用ももちろん非常に強力な方法です。 LIFULLでは採用基準を、大切な順に ビジョンフィット カルチャーフィット ポテンシャル スキルフィット と全職種共通で定めています。 評価は育成 評価は育成において、非常に大切なポイントです。 (会社によっては評価制度において、人事評価＝育成のためのフィードバックと切り分けられている場合もあると思いますが、その場合は「フィードバック」を指す) 被評価者の成長につながる評価をすることが重要です。 例えばとある行動や仕事に対して、たとえば、◎(非常に良くできている)、◯(できている)、△(課題がある)の３段階の評価があったとします。 △を付けた場合は、その理由は説明するとおもいます。 　 ところが◯を付けたときに、なぜ◎でないか、という理由を説明をする人は少ないのです。 3段階評価において1番上ではないので、 ◯だった人にも◎になるためにどういう事ができれば良いか、を示してあげること は育成上重要であると考えています。 また、成果に対する期待値のすり合わせが半年毎の「評価」のタイミングのみだと効果は薄いので、 日々のコミュニケーションや、場合によっては1on1などでこまめにすり合わせすることは大事だと思っています。 メンバーのキャリアデザインを知る メンバーのキャリアデザインは育成において非常に重要なポイントです。 育成は個人のキャリアデザインを軸とし、会社の業務で求められている部分を重ねながら実際の仕事に落としていくと、 それを実行するメンバーのモチベーションとなり、会社にとっても良いことであると実感しています。 マネージャーは個人のキャリアデザインと業務を重ねながら、時には新しい業務(もちろん事業価値との接続があるもの)を考えて提案したりします。 また、もし個人のキャリアデザインがまだふわっとしていれば、一緒に形作っていきます。 キャリアにおける3年後、5年後のイメージは、できれば「具体的なロールモデル」がいたほうが、レベル感についてマネージャーとメンバー間で共通の認識が持てるのでおすすめです。 しかし、経験上実際にロールモデルが明確にいる人は少なく「ぴったりハマる人はいない」という回答が多いようなので、「例えば〇〇のスキルでは誰くらいー」とか、「〇〇という行動してる人って例えばー」というように、一つ一つ掘り下げると意外と出てきたりします。 逆に、「ロールモデルが明確にいる」という人の場合も、「その人のどの部分が良いと思っているのか」を詳細に聞かないと間違った理解になる可能性があるので注意が必要です。 私は以下のようなことをよく聞いています。 あなたの目指す3年後5年後のイメージに対しては、現在の状態から、 * 足りないスキルがあるか？あるならそれははなにか？ * 足りないスキルがないなら、何が課題か？単純に時間軸の問題か？ * 足りないスキルを身につける行動がイメージできているか？ キャリアにおける、3年後、5年後のイメージに対し、 * それぞれのロールモデル、今の時点でこれくらいの人という具体的イメージがあるか？ うまく回答が出てこないようなら一緒に考えます。むしろ、最初からうまく描けている人は、ごく僅かです。 それと個人的に注意したいのは、 ３年後のイメージに対し、スキルと言うより 経験 がたりない、というのはよく聞きますが、 「経験」の指すところを掘り下げれば「意識しているスキルの要素」があると思っています。 例えば「大規模システムの開発、運用の経験」ですと、”トラフィックが日で〇億PVなインフラ”なのか”100人で開発しても耐えうるアーキテクチャ、開発の仕組み、チーム分け”なのか、などです。 「経験」という言葉は、やって初めて必要なものが見えてくる、ような部分があるとは思うので、 極力、スキルレベルまで落とし込んで「足りないのはなにか」をお互いに意識できると成長への明確な足がかりになります。 また、注意したいのは、各個人のキャリアデザインにおいて理解なしに「え、それは無理じゃない？」のように否定しないことです。 人の可能性は開けていますし目指さなければ何事も得られないのは事実なので、以下のそれをうまくできるかをまずは一緒に考えます。 「動機の源」を知る その人が、どんな時にモチベーションが上がるのか。 表層として出てきた、相手の「意見」や「行動」の背景を、その人の経験・価値観・その時の感情などの面から掘り下げて知る というようなものです。 参考： learning-21.org 私は各メンバーとの最初の1on1で 「今までで一番楽しかった仕事ってどんなものですか？」 と聞いています。 出てきた具体的な経験について、 「それはどういうところが楽しかったのですか？」とか、「〇〇プロジェクトもそれと似てるとは思うけど、それとの違いはどういうところだったのですか？」 など、さらに掘り下げて立体的に理解していきます。 それによりどんな仕事がどういう理由で楽しかったのか、などを知ることができます。 ここで大切なのは、 どういう仕事を楽しいと思うか、どんなことに価値を感じるのか、 というところです。 それを知ることによって、その後、近い仕事をアサインすることができ、楽しく高いパフォーマンスを出すことができます。 過去には 「あ、すごい苦労していたり大変そうだな、と思ってみてたけど、このメンバーにとって、あの仕事は楽しかったんだ！」 というような事を知ることができて、その後の仕事を任せることに役立った経験があります。 適切に情報を伝える 組織において、何かを決めたときに決めたことをメンバーに伝えるときの伝え方は非常に重要です。 伝わり方次第でメンバーのモチベーションが大きく変わります。 その時、メンバーからいろいろな質問が飛んできます。 言わないように気を付けている言葉は以下のようなものです。 どうしてだろうね？ よくわからないんだよね。 私もよく知らない。 私は本当はそう思わないんだけどね。/私は反対なんだけどね 上の人がこう言ってたから などです。 上記のような言葉を多用してしまうと、組織全体に不信感が蔓延してしまいます。 「自分がメンバーに自信をもって説明できる（＝自分が理解できる）まで、問う・考える」のが責務だと考えインプットを意識しています。 そうしていれば、単純に知識不足でよく分かっていない点などを自ずと学ぶことにつながり、知識もついて一石二鳥です。 ただ、自分でも理解できてなかったり本当に知らないことを無理に理由をつけて、 「無理やり納得」させようとすることはしないようにもしています。シンプルですがとても大切だと思います。 「メンバーの方が気付く（気付いている）」 ということはごまんとあるので、質問されて分からなかったことは、 「あ、ごめんそれはわからないや、ちょっと聞いておくね」 だったり、 良い提案に対しては、 「確かにそうだね、その方向で提案してみようか」 と、素直になりましょう。 素直さは大事ですね。 1on1 これまで記載したことを実行していく上で1on1の場は大事だと考えており、定期的に実施しています。 過去の経験上、頻度は長い1回、より、細かく多めに、を心がけたほうが良いと思っています。 当時9人メンバーがいたグループマネジメントで、1名ずつの時間が非常に長くなってしまう(1.5hとか)傾向がありました。 約3週間に1度程度しか各メンバーと1on1できませんでしたが、それを毎週全員と30分、と決めて実施してみました。（その中で込み入った話になりそうな時は、別途時間を抑えたり） メンバーの感想は、適宜気軽に話ができるので、その方がいいという意見をもらいました。（わざわざ話しかけて聞くほどじゃないことや、些細な気になったことを聞ける、など) 私としても、早期になにかの芽を発見できるので良かったです。 シニア、ジュニア、メンバーのレベル問わずその方がいいという感覚です。 話す内容は相手や状況によって都度変えますが、大体以下のようなアウトラインで話しています。 初めての1on1、毎回、4半期に一回でそれぞれ聞くことを大きく分けたりもしています。 準備 一人ひとりのメモを用意 相手と共有できるように その場で唐突にだと話の種を思いつくことに時間を割いてしまうので、相手にも事前に書き込んでもらえるようにする 自分用のメモを用意するかしないかは、任意。 初めての相手に聞くこと 上に記載した「動機の源」を聞きます。 あと自己紹介しましょう。 毎回聞くこと 最近の調子 最近の仕事 最近ハマっていること 休みや帰った後の時間の使い方(ここは特に人による) 楽しかったこと 楽しくなかったこと キャリアに対して 最近キャリアへ近づいている印象をもつか 成長している実感は？ もっと成長を促進できる方法、サポートできることはないか 今の不安 今、不安なことはないか 今後不安になりそうなこと 上司、会社への要望（不満、というと出てこないことが多い） 私への改善点、してほしいこと 会社のここを良くしたいというところ その他・気になったこと 今困っていることはあるか 4半期に1度ほど聞くこと 楽しかった仕事 ここ三ヶ月で仕事が一番楽しかったのはいつか なぜそれがそんなに楽しかったのか きつかった仕事 ここ三ヶ月で仕事が一番辛かったのはいつか なぜそれがそんなに辛かったのか  印象的な出来事について ここ三ヶ月で一番心に残っている出来事は なぜそれほどまでに心に残ったのか 最後に 書いてみましたが、エンジニアのマネジメントに限った話ではないと思いましたが、もし役に立つ部分があれば幸いです。 色々と書いて長くなってしまいましたが、そんな事を意識しながら日々やっております！ また、そんな事を意識しているマネージャーもたくさんいます！ 現在、LIFULLでは仲間を募集しております！ カジュアル面談も受付していますので興味ある方は是非ご参加ください！ hrmos.co

こんにちは！　LIFULLのエンジニアで、Ltech運営チームの１人 @サム です！ もうすぐ年末ですね、Ltechも今年最後の開催になります。 Ltechとは 株式会社LIFULL主催の、技術（エンジニアリング・テクノロジー）をテーマにしたイベントの総称です。 特定の技術に偏らず、様々な技術をピックアップしていきます。 今回は、2019/11/08(金)に開催した、 Ltech #9「WAKATE Meetup」についてレポートします！ lifull.connpass.com Ltech#9 WAKATE Meetup Ltech初の新卒5年目までの若手エンジニアの為のMeetupです！ 「 自分と同世代の若手エンジニアってどんなことをしているんだろう？ 」 社内のエンジニアのそんな疑問から若手対象のMeetupイベントを行うことになりました。 参加された方は エンジニア仲間を作りたい方 同年代がどんなことをしているのか知りたい方 最近興味を持っている技術ネタを交換したい方 LIFULLの若手社員と話したい方 と思っていただけている方が多いと思います。 もちろんLIFULLからも、若手のエンジニアが５名以上も参加してくれました！ まずは諸注意等の説明のあと、LIFULLエンジニアから自己紹介、最後に参加者の自己紹介をしました。 皆さん、エンジニアと言っても色々な業務に携わっており、自己紹介だけでも大変楽しめました！ 挨拶は終わり、本題のミートアップが始まりました！！ 懇談会中は、次のようなテーマが発表され、 今どういう仕事をやっているのか 気になっている技術 エンジニアとしてスキルアップの為にしていること 今後のキャリアプラン 参加者はテーマについて語り合ったり、思う存分コミュニケーションを取れていると感じました。 私はもう「若手」とは言えないので今回は裏方に回りましたが、参加された人たちの会話を聞いて、自分もやる気と情熱を受け取ることができました！ こういった機会はなかなか無いので、今後も開催できればと思います。 最後に Ltech では、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは。クリエイターの日運営委員のきのしたです。 突然ですが、皆さんは「LIFULL Fab」をご存知ですか？ 弊社は、Fabスペース(アナログ・デジタル工作機器が利用可能な工房)も運営しており、そこには3Dプリンターやレーザーカッター、ShopBotなど、クリエイターならテンションが上がること間違いなしの機器が揃っているんです！ fab.lifull.com こんな素敵なスペース、使うしかない！ということで、「クリエイターの日」のイベントの一環として、 レーザーカッターでお菓子に彫刻するイベントを社内向けに開催しました。 ※クリエイターの日とは？ 希望者が、3ヶ月ごとに最大7営業日を使って、好きなものを開発することができるLIFULLの制度です。 LIFULLでは、マーケティング能力や技術開発能力を高めてイノベーションを創造するため、通常業務の枠を離れて、新たな技術や手法に取り組む機会となっています。 どうやってお菓子に彫刻するの？ レーザーカッターでお菓子に彫刻する、ってどういうこと？！という方のために、レーザーカッターの仕組みも踏まえて、解説いたします。 レーザーカッターとはその名の通り、強いレーザー光を用いて素材を焼き切ったり、表面を焦がしたりすることで素材を加工するデジタル工作機器です。 デジタルデータをもとにレーザー光の出力を詳細にコントロールできるため、簡単に精密な加工を誰でも行うことができます。 今回はお菓子の表面を少し焦がす程度にレーザー光を調整して、用意したデジタル画像をお菓子に彫刻しました。 表面を焦がしているだけなので、加工した食品を食べても特に問題はありません。 また、手書きで描いたイラストや、その場で描いたものも、簡単に取り込んでデータ化できました。 手書きのイラストから、細かい模様・図柄まで、色々な模様を彫刻して楽しめそうですね！ どんなものができたの？ ではさっそく、どんな彫刻をしたのか見ていきましょう！ こちらは娘さんの似顔絵を、クッキーに彫刻してくださったパターンです！ ラッピング用品も用意したので、彫刻したクッキーを素敵にプレゼントできました。 こちらは、弊社のサービス「LIFULL HOME'S」のノベルティカレンダーで登場したイラストを彫刻されたものです！ デジタルで作った均一な線も、そのまま綺麗に出力されています。 異動となってしまった上司へ、似顔絵を彫刻したクッキーをプレゼントされた方もいました。 世界に一つの、心のこもった似顔絵プレゼントですね！ 同じ部署の方のチャットツールのアイコンを彫刻して、プレゼントされている方もいらっしゃいました！ さいごに 今回イベントを開催してみて、お菓子など身近なものを題材とすることで、営業の方など普段ものづくりをされない方でもFabスペースやレーザーカッターなどの機器に興味を持っていただけたと思いました。 また、社内のクリエイターも、レーザーカッターを使ってみて、「これで楽器が作れるかも」「版画もできちゃうかもね！」と、新しいアイディアも浮かんでいました。 LIFULLでは、LIFULL Fabを使った様々なイベントを企画しています。 イベントの様子はFacebookで発信していますので、是非ご覧ください！ www.facebook.com また、LIFULL Fab以外でもLIFULLでは様々なクリエイター向け社内イベントを開催しています。こちらも興味がある方は是非ご覧ください！ www.lifull.blog recruit.lifull.com

こんにちは、株式会社LIFULLの塩澤です！ 今回は、2019年9月3日(火)に開催した、 「Ltech#8 LIFULL HOME'S 技術的負債との闘い」についてレポートします！ lifull.connpass.com Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。 特定の技術に偏らず、様々な技術の話を展開していく予定です。 Ltech#8 LIFULL HOME'S 技術的負債との闘い 今回のテーマは「HOME'Sの技術的負債との向き合い方」についてです。 LIFULLの技術横断組織に所属するエンジニアより、技術的負債に対する向き合い方や取り組みについて話してもらいました！ それでは各発表をお伝えします。 技術負債解消モチベーションへの取り組み 【Ltech#8】技術負債解消モチベーションへの取り組み from LIFULL Co., Ltd. www.slideshare.net 技術的負債を抱えるシステムに対して、その負債の特徴からシステムを切り分けて解消へアプローチしていくお話です。 理想的な解決へ向けての方針が決まっても、やはり優先度やビジネスへの影響など、 大きな壁があり負債を解消していくのは難しいものです。 そこで、今ある資源で負債の解消ができるような仕組み作りと実践をはじめました。 また、仕組みづくりだけでなく、負債解消の仕組みと価値を現場だけでなく上流へも伝えることで、 負債解消の仕組みが組み込まれていくようになりました。 結果、現実的に負債の解消ができるような仕組みづくりと、仕組みが開発の中で回るように普及させることで、 持続的な負債の解消が小さくとも進んでいくようになりました。 目の前だけでなく上流に目を向けて、負債解消の意義を伝えるだけでも変化がうまれます。 レガシーシステム・プロセス改善史 【Ltech#8】レガシーシステム・プロセス改善史 from LIFULL Co., Ltd. www.slideshare.net LIFULL HOME'S には、コードの肥大化やCIの運用が続かないなどの課題がありました。 そのようなレガシーシステムの課題に対して、どのような施策を行い、どんな結果となったのかの改善の歴史についてのお話です。 以下のような施策を行うことで、事業がより成長できる環境作りを進めました。 ドメイン知識のドキュメント化&勉強会 設計規約、レビュー方針の策定&ピアレビューの実施 ドキュメントの集約 アーキテクト活動・ソリューションアーキテクト 静的解析、CI 自動テストの拡充、各種バージョンアップ レガシーコードのリファクタリングをモブ設計・モブプロ 各施策の実施前と実施後で効果が現れましたが、中には新たな課題が生まれたものも。 いくつかピックアップすると、ピアレビューを導入し、レビューの結果をピアレビュアーが確認することで、 レビュアーの育成をしています。そうすることで、誰でもレビューができるようになりました。 ものづくりが事業別の組織になった際には、機能の重複やレガシーシステムに明るい人がいなくなるなどの課題がありましたが、 技術横断部署にレガシーシステムに詳しいアーキテクトグループを設けることで、 アーキテクチャやインフラ設計などの各種の相談を行えるようにしました。 などなど、改善に向けた色々な施策をお聞きすることができました。 今後も闘いは続いていきそうです。 技術的負債返済・実装改善に関する事例紹介 【Ltech#8】技術的負債返済・実装改善に関する事例紹介 from LIFULL Co., Ltd. www.slideshare.net 実際の現場でコードリファクタリングをするために活用されているツール・サービスについて、 より実践的な活用事例の紹介です。 今回は以下のことについてお話をいただきました。 Code Climate活用事例 効果的な負債返済計画 Datadog APM活用事例 Buckyの活用事例 負債返済計画については弊社の体制も含めて、4つの体制について紹介していただきました。 弊社では、開発チームと技術的負債の解消チームとは別に、負債の原因を分析して解消するチームを別で設けており、 技術的負債が生まれにくい状態を実現しています。 静的解析ツールだけでなく、Datadog APMを利用することで、実行順序やボトルネックを考慮した 効果的な改善ができた事例はとても勉強になりました。 より実践的な技術的負債の返済計画と各種ツールの長所短所を組み合わせることで、 プロダクトの発展を止めることなく、技術的負債を解消していくことが可能になりました。 懇親会の様子 最後に、登壇者と参加者の方を交えた懇親会です！ Ltech名物の唐揚げです 体に良いスムージーも 盛り上がった懇親会となりました 最後に Ltech では、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは！LIFULL HOME'Sのアプリ開発チームの山川です。 6/3〜6/7にはWWDC2019が開催され、iOS13の発表やARKit 3、SwiftUIなどをはじめとする新技術の発表がありましたね。 本日は、そのWWDC2019で発表された新技術に関する共有会を行ったので報告致します！ その名も 「令和最初のDeveloper's Living 〜WWDC2019〜」 です。 lifull.connpass.com 2年前にもWWDCの共有会は行ったのですが、今年は会場をLIFULL HUBのイベントスペースで開催しました。LIFULL HUBを使って行うのは今回が初めてで、より近くで発表を見学できる空間となりました。 2年前のイベントの記事はこちらです。 www.lifull.blog LIFULL HUBとは 弊社の2Fにあるコワーキングスペースです。 今回のようなイベントを開催できるイベントスペースや、仕事に取り組めるワークスペースなどを提供しています。 LIFULL HUBへ 発表 Reality Composerで簡単AR実装！ 弊社の青木 孝乃輔の発表です。 Reality Composer を使ってデモアプリを作成し、その作成方法の共有を行いました。 なんと、当時 AR歴3日 という経歴でLTに挑みました、すごい。 極力楽にAR体験を作成する 従来、ARアプリを作成する場合は、平面検出や3Dモデル作成、タップ判定や物理衝突...といった具合にやらなければいけないことが多かったです。 しかし、Reality Composerでは3Dオブジェクトを直感的に作成でき、アプリに組み込む時もドラッグ&ドロップし、簡単な設定は自動的に生成してくれます。 これにより、今まで手を出してこなかったDeveloperがARアプリ作成に動き出すことが期待されますね！ Motion Capture 弊社の池田 和洋の発表です。 Motion Capture に関する発表を行いました。 リアルタイムに人間の動きをトラッキング Motion Captureは、カメラで人間を映し出すとその人の動きをリアルタイムでトラッキングし、動きをキャプチャします。 発表では、キャプチャの仕方について共有しました。 一行の初期設定の宣言をし、ボディの検知をする処理を書くだけで、もう人間の動きをトラッキングすることができます。 これを活用して、人間のジェスチャをトリガーとして価値を提供するような新たなサービスが増えるかもしれませんね！ 今年こそ、普及する？！HomeKit Sam Akada 様の発表です。 HomeKit の利用例を、実際のデモを通して発表いただきました。 ホームアプリで家のあらゆるものを操作できる ホームアプリを使用することで、HomeKitに対応しているアクセサリを操作することができるようになります。 これにより、自宅の照明のオン/オフをSiriにやってもらったり、Macからエアコンの操作をしたりすることができるようになります。 発表では、Siriを使って実際にデバイスを操作するデモを行っていただきました。 ちなみに、デモで扱ったデバイスは 全て自作 ！ ハードウェアまで開発して実演されるのは、会場がとても盛り上がりました。 WWDCでの発表ではセキュリティカメラのサポートや外部攻撃をシャットアウトするHomeKit対応ルーターが紹介されていました。 今回の発表と絡めて、より安心してホームアプリを使えるようになり、ホームアプリのユーザが増えそうです！ 既存アプリをiPadOSで複数Window対応 @fromkk 様の発表です。 今回のWWDCで発表された iPadOSで、既存アプリを複数Windowで表示する やり方について発表いただきました。 同じアプリの複数表示には注意も必要 画面を分割することによって、同じアプリを並べてコピペが楽にできたり、楽しそうな操作ができそうだなとワクワクしますが、実装時には注意することが何点かあります。 例えば、必要な宣言をしていないと画面が真っ黒になったり、同じデータを扱っている場合はコンフリクトが発生することがあるそうです。 これらを踏まえて、たくさんテストをしてアプリの品質を高めることが求められそうです。 また、来年4月までに対応を求められるので、早めに動き出すことも大切です。 懇親会 4名の発表が終わった後は、参加者の皆様で交流会をしました！ LIFULL HUBでの交流会は仕切りが少なく開放的であったため、皆さん交流をたくさんされていて盛り上がっていました。 懇親会の終盤には、WWDCの会場でしか手に入れることのできない超レアなグッズを景品とした抽選会が行われました。 見事抽選に当選した皆様、おめでとうございました！ 最後に 全体的に、これまで実現するのに難しかった技術が お手軽に、かつ素早く実現できる ことを感じさせる印象がありました。 今回のイベントでは Reality Composer Motion Capture HomeKit iPadOSでの複数Window表示 が発表・共有されましたが、WWDCでは他にも多くの技術が取り上げられました。 これらの技術が今後、どのように数々のサービスに活用されていくのか楽しみですね！ WWDCでの発表から時間が経っていたにも関わらず今回の共有会に集まっていただいた皆様、ありがとうございました！

LIFULLでエンジニアをしている清野です。 今回は2019年6月20日に行われた「Ltech#7 Salesforce de 夜ふかし(22時完全撤収)」のレポートを書いていきます。 lifull.connpass.com Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。 特定の技術に偏らず、様々な技術の話を展開していく予定です。 Ltech#7 Salesforce de 夜ふかし(22時完全撤収) 今回も最近のLtechと同様にスピーカー3名によるセッションと懇親会というイベントでした。 LIFULLではSalesforceにおけるCoE（Center of Excellence）をミッションとする部署があり、 所属するエンジニアをメインに労働集約型の業務フロー改善、全社の生産性向上に向けた社内基盤システム開発等に取り組んでいます。 私自身はSalesforceエンジニアではないので、今回の勉強会は完全に素人のような状態で聞くことになりました。 それでは各セッションのレポートです。 LIFULLにおけるSalesforceの歴史 ＋ 開発環境周りについて 【Ltech#7 】LIFULLにおけるSalesforceの歴史＋開発環境まわりについて from LIFULL Co., Ltd. www.slideshare.net LIFULLでは2013年頃からSalesforceを利用しています。 元々はLIFULL営業担当の為に導入されたSalesforceでしたが、その後色々と統合され、今では社内インフラとなるくらいに情報が集まっています。 LIFULLの開発体制としては 基本的に内製 リリースは毎週1～3回 開発は複数の部署 Salesforceエンジニアは20数名 リリースが週1～3回というのは自分の感覚だと予想より多かったです。 個人的にはエンジニアとしてソース管理がしにくいという話題が気になりました。 やはりSalesforceというプラットフォームがあるおかげで、通常のWebアプリケーション等とは運用が違うようです。 このあたりはSalesforceエンジニアの方も苦労しながらやっているんだなと感じました。 Salesforceを活用したCRM、個人情報管理、レポートシステム等の開発事例 【Ltech#7 】Salesforceを活用したCRM個人情報管理、レポートシステム等の開発事例 from LIFULL Co., Ltd. www.slideshare.net LIFULLが目指すCRMは散在している情報を集め、繋げ、相互活用していくCRMです。 先ほどのセッションにも出てきましたが、オムニチャネルを実現し、最高のユーザ体験を提供したいという思いでこのCRMを目指しています。 LIFULLにおけるSalesforceを活用したシステム開発事例としては大きく4つが紹介されました。 個人情報管理 Salesforce上に個人情報を格納するデータベースを構築し、サイトからのお問い合わせ情報を登録。 Salesforceがメンテナンスの時にもデータを登録する為、AWS(API GatewayやLambda等のサーバレスアーキテクチャ)とSalesforceを組み合わせて、Salesforceへのデータ登録APIを実現。 問い合わせ機能 Salesforceの「サイト」機能で問い合わせフォームを実装。 サイトから問い合わせがくるとSalesforceに問い合わせデータと個人情報が登録される。 レポーティング機能 SalesforceのデータをBigQueryへ連携。 BigQuery + Tableauで各種レポートを生成。 その他 LINE連携をすることにより、アンケート回答データに応じてエンドユーザ様へ様々なお知らせメッセージをLINEで配信。 Salesforce単独で出来なくても、他のシステムと連携することで色々なことが可能になることが分かるセッションでした。 Pardotによるマーケティングオートメーション 【Ltech#7】Pardotによるマーケティングオートメーション from LIFULL Co., Ltd. www.slideshare.net PardotとはSalesforceのB向けマーケティングオートメーション（MA）ソリューションで、LIFULLでは2018年から利用されています。 Pardotから発行されるトラッキングコードによって、Webサイトに訪れたユーザの行動をトラッキングすることが可能です。 LIFULLでの活用事例 顧客のセグメンテーションと購買意欲に応じたキャンペーンメール配信 LIFULL各サイト(B向け)のトラッキング 商談失注時のフォロー対応の自動化 メルマガ開封データを元にした電話営業の効率化 クライアントの興味関心に合わせたアプローチがこのPardotによって可能になっています。 懇親会 お楽しみの懇親会です。 毎回恒例のから揚げ。新たにハンバーガーも追加されました。前回に続きスムージーも。 懇親会はとても賑やかでした 最後に Ltech では、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは。クリエイターの日運営委員のはなおかです。社内のモノづくりイベント『創民祭』が開催されましたので、その様子を共有させていただきます。 今回は、文字通り"平成最後の創民祭"となりました！平成最後にふさわしく、様々なプロダクトが展示されました。 創民祭とは？ 創民祭（そうみんさい）とは、業務や「クリエイターの日」、プライベートで創った物など、LIFULL社員が作ったプロダクトをお酒を飲み、ピザ・寿司を食べながらお披露目するイベントです。近年はWebに限らず、ジオラマやイラスト等、多種多様なプロダクトが展示されています。 前回の様子はこちら www.lifull.blog クリエイターの日とは LIFULLでは、マーケティング能力や技術開発能力を高めてイノベーションを創造するため、通常業務の枠を離れて、新たな技術や手法に取り組む機会を設けています。 希望者は、3ヶ月ごとに最大7営業日を使って、好きなものを開発することが可能です。 展示内容 前回同様、Webに限らずいろんなプロダクトが展示されました。以下に展示内容をご紹介します。 最近社内で密かなブーム！自作キーボード 最近社内で少しずつ増えている自作キーボード。今回、LIFULLでも特に自作キーボード好きで知られるエンジニアに自作キーボードを展示してもらいました！ とにかくキーボードを作るのが好きで、光るキーボードや左右分離型など、いろんなキーボードが展示されていました。 キーの配列やサイズ、押し心地など、とにかく色んなことにこだわっていて、自作キーボードに対する愛が伝わってきました。 ちっさな自作キーボードもあるよ！meishiキーボード 初心者向け自作キーボード「meishi」を展示してくれました。 はんだづけ未経験でも４時間ほどで作れるそうです。初心者でもこのサイズなら挑戦できそうですね！ IoTを活用！HeatMapを使ったオフィス環境情報の可視化 RaspberryPiとGCPを組み合わせて、オフィスの温度を可視化してくれました。フロア内のどこがどのくらいの温度かをスプレッドシートで可視化してくれるので、オフィス環境の改善に役立てそうです。 セキュリティ面の問題に苦労したらしく、IP制限で工夫した話などを聞かせてくれました。 蛍光灯で音楽ができる！蛍光音 蛍光灯を使って音を出す、世にも珍しい楽器です。蛍光灯から出ているノイズをピックアップで拾うことで、ギターみたいに音を出すことができるそうです。 エフェクターを使って音を歪ませることも可能だそうです。バンドで演奏とかできたら面白そうですね。 リモートなのに職場にいるみたい！Augmented Office VRとARを使って、よりリアリティのあるリモートワークを実現できる新しいリモートワークアプリです。 リモートワークなのに、職場にいるように仕事ができます。これを使えば会社に行かなくても仕事ができる時代が来る！かもしれません。 Webページを見ながらchatできる！Cown ブラウザ上にチャット画面が表示され、同じページにいる人たちとチャットができるサービスです！以前ブラウザとして開発していた物を、Chrome拡張として開発し直したそうです。 プラグインは公開済みなので、 Cown - Chrome Web Store から利用することが可能です。 Smarthome展示場 今話題の「スマートホーム」の体験ができます。MESHというデバイスを使って、触る、動かすなどの信号から家電を操作します。例えば部屋が明るくなったら、それをトリガーにテレビを付けたり、人が横切ったらiPadのカメラで写真を撮ったりできるようになります。 スマートホームの技術を使って、次の時代のサービスづくりに繋げたいとのことでした。 EATREE CAKE LIFULL Table Presents「地球料理 -Earth Cuisine-」（ https://table.lifull.com/earthcuisine/ ）という、食べることが地球のためになる、地球の新たな食材を見つけるプロジェクトである第一弾「Eatree Plates」から、「Eatree Cake 〜木から生まれたケーキ〜」も参加しました。このケーキは、森林環境を良くするために出る”間伐材”を材料としています。国内外のメディアでも取り上げられて話題になりました。 「Eatree Cake 〜木から生まれたケーキ〜（ https://table.lifull.com/eatreecake/ ）」は、ECサイトで販売中です。 イベント 今回は特別企画で、社員がVtuberになってトークする「LIFULL Vtuber トークイベント」を開催しました！VRoidや3Teneといったツールを使って、リアルタイムでVtuberの方々にトークを行っていただきました！ 最後に 平成最後の創民祭、その一部をちょっとだけお伝えしました！展示物やイベントのバリエーションが広がり、よりユニークなイベントになってきています！ LIFULLでは、一緒に働くメンバーを募集中！新卒も中途も絶賛採用中です。ご応募お待ちしてますので、ぜひみてください！ recruit.lifull.com

こんにちは！LIFULLのSoftware Engineer in Testグループ（通称：SETグループ）のヒキモチです。 我々SETグループは先日、自動システムテストツール「Bucky」のOSS化を行いました！ github.com github.com Buckyは元々社内の自動テストツールとして使われていたものなので、 それをOSSとして公開するためには色々と苦労がありました。 この記事ではその苦労やそこで得た知見などを共有できたらと思います。 目次 そもそもなぜOSS化するのか OSS化までの道のり 1. リファクタリング 2. システムテスト導入 3. RubyGems.orgへの登録 公開後のお話 使い手のことを考えられていなかった 問題 解決策１：ハンズオン資料を作成 解決策２：READMEの構成を変更 ruby version gem release 自動化 最後に そもそもなぜOSS化するのか 「LIFULLエンジニアの認知度の向上のため」 サービスとしての「LIFULL HOME'S」の認知はされていますが、 それを作っているエンジニアの認知度はまだまだ低いと感じています。 オープンソースとして公開することでLIFULL全体のエンジニアの認知度の向上に繋がればよいなと思っています。 「使ってほしい」 単純に自分たちの作ったものを使ってほしいと思っています。 自分たちが日々使っていて便利だと感じているからこそ、 世の中の人達にも使ってほしいという思いがあります。 「外からのフィードバックを受けることで、より使いやすいものに進化させたい」 公開はしましたが、まだまだ使いにくい部分はあります。 Buckyをよりよいものにするために、外部からの意見を積極的に取り入れたいと思っています。 Issues、Pull requests待っています。 OSS化までの道のり 1. リファクタリング 会社の冠をつけて公開するのでソースコードはある程度きれいにしておく必要がありました。 静的解析はRubocopとCodeClimateを連携させて行いました。 Code ClimateとGitHubを連携し、コード解析・テストカバレッジの測定を行う。 GitHub issue連携機能を使い、Code ClimateからGitHub issueを作成。 SETGメンバーが分担してリファクタリング。 ローカルでの確認は Code Climate CLI を用いる。 CodeClimateを使うことで、指摘事項のGitHub issue管理が容易になり作業効率が上がりました。 またmaintainabilityやtest coverageとして評価が可視化されるので、リファクタリングのモチベーション向上にも繋がりました。 A~Eで評価が行われる maintainabilityの推移 バッジもいい感じになりました codeclimate.com 2. システムテスト導入 品質向上のため、システムテストを導入することにしました。 ユニットテストでは担保できない、buckyコマンドやテスト実行の動作を保証するためです。 テストフレームワーク「Bats」を使い、bashの終了ステータスやコンソール出力を期待値として扱うことで実現しました。 github.com 仕組みは以下のとおりです。 １．GitHubへのpushをトリガーにCircleCI上に以下のコンテナを立ち上げる 　・テスト実行対象コンテナ（nginx） 　・selenium-standaloneコンテナ 　・テスト実行コンテナ（bucky） ２．Batsにより、buckyコマンドを実行しnginxコンテナ内のサンプルページに対してテストを実行し、正常な動作が行われるかどうかを検証する システムテスト周りは こちら に実装してあります。 3. RubyGems.orgへの登録 パッケージとして扱えたほうが便利なので、 GitHubへの公開と同時にRubyGems.orgへの登録も行いました。 bucky-core | RubyGems.org | your community gem host 公開後のお話 使い手のことを考えられていなかった 公開したは良いものの、実際に使うためのドキュメントが整備されていませんでした。 具体的には以下の問題がありました。 問題 READMEを見てもgem install後に何をすればいいかわからない 当時のREADMEのUsage に従ってもテストを実行することはできませんでした。 Bucky-managementをどのように利用すればいいのかわからない テスト実装・実行はBucky-coreの機能ですが、テストレポートはBucky-managementの機能です。 READMEを見てもどのように連携して利用すればよいかわからない状態でした。 解決策１：ハンズオン資料を作成 クイックスタートするためのハンズオン Bucky-management使用したハンズオン qiita でもハンズオンを作成しました。 解決策２：READMEの構成を変更 Setupを追加しました。 Setupにはインストールしてからテストコードを実装する手順を記載し、Usageにはテスト実行手順を記載しました。 ■ Before - Bucky-Core - Overview - Feature - Set connection infomation for database - Usage - Install - Run test - Implemente test code ~省略~ ■ After - Bucky-Core - Overview - Feature - Setup - Install - Implement test code - Set connecting information for database - Usage - Run test - Rerun test ~省略~ ruby version gemspecにrequied_ruby_versionの指定をしていなかったため、 公開時は必要rubyバージョンが1.0.0以上となっていました。 慌てて 修正 を行いました。 gem release 自動化 RubyGemsへのリリースも自動化しています。 GitHub上でreleaseタグを作成するとそれをトリガーに以下の処理が行われます。 バージョンファイルの書き換え masterブランチへpush gemのパッケージ化 RubyGemsへリリース 詳しくは以下の記事をご覧ください。 RubyGemsリリースを自動化した話 - Qiita 最後に 開発者以外もyaml記法さえ知っていれば簡単にテストコードが書けるようになっていますので、 ぜひ使ってみてください。 詳しい使い方はGitHubリポジトリの README もしくは hands-on を参照ください。 まだまだ改善すべきところはあると思っているので、 我々も開発していきますし、issue、PullRequestもお待ちしてます。

LIFULLエンジニアで、Ltechの運営チームの @サム です！ 今回は、2019年04月23日平成最後の Ltech #6 「 Quality Talk Night！ 」についてレポートします。 Ltech とは Ltech(エルテック)とは、「 LIFULLがお送りする、技術欲をFULLにするイベント 」です。 特定の技術に偏らず、様々な技術の話を展開していきます。 Ltech #6「Quality Talk Night！」 今回の Ltech のテーマはQAやSET、テスト技術などについてです！ LIFULLでは品質改善推進の専門部署があり、品質管理やセキュリティ、QAやSETエンジニアのチームだけでなく、UX・UIに対して専門的なアプローチをするチームがあります！ それぞれのチームでの、主に不動産・住宅情報サービス「LIFULL HOME'S（ライフル ホームズ）」での取り組みについて余すことなくお伝えします！ LIFULLでのQAのあり方 【Ltech#6 】LIFULLでのQAのあり方 from LIFULL Co., Ltd. www.slideshare.net LIFULL HOME'S では、週4日リリース、月にすると200~300件のプロジェクトがリリースが行われています。 プロジェクトには プランナー、エンジニア、デザイナー が担当していますが、専属のQA／テスターはいません。 そのため、プロジェクト内のチームでテスト仕様書の作成から実施までやります。 品質保証組織（QA）は、LIFULLのプロジェクトにどう関わっているのか？ プロジェクトに介入して、プロダクトやテストの品質向上支援をおこなっています。 実例 QAサポート コンサルテーション（お悩み相談） テスト設計支援・代行 探索的テストによる支援 テスト計画コンシェルジュ テスト計画書の作成を代行するサービス スケジューリングなどを含めた全てではなく、テストスコープの明確化、テストアプローチの合意までを行う QAとプロジェクトチームが話し合って、互いに腹落ちするテストアプローチやリスクを定義 リスクマネジメント 企画された施策に対してリスク判定を行い、リスクが高い施策についてはQA側からアプローチを行う LIFULLにおけるQAは、”１つ”のプロダクトではなく、”LIFULL”のプロダクトの品質保証を行っています。 リリース前の最終防衛線、LIFULL HOME'Sの自動回帰テスト 【Ltech#6 】リリース前の最終防衛線　LIFULL HOME'Sの自動回帰テスト from LIFULL Co., Ltd. www.slideshare.net LIFULL では、GitHubを使っていますので、GitHub Flowでプロジェクトの開発を行っています。 そのため、自動回帰テストの実施タイミングとしては、Developブランチで、自動テストフレームワーク「Bucky」を使っています。 自動テストフレームワーク「Bucky」についてはこちらをご参考ください。 qiita.com この「Bucky」を使って自動回帰テストをおこなうことで、実際にプロダクトにおける問題をリリース前に検知することができました。 「Bucky」はOSSとしてGitHubに公開されています。 GitHub - lifull-dev/bucky-core: System testing framework for web application. GitHub - lifull-dev/bucky-management LIFULL ユーザビリティへの取り組み LIFULLユーザビリティへの取り組み from LIFULL Co., Ltd. www.slideshare.net LIFULLには、「ユーザーファースト推進グループ」というのがあります。この部署では「ユーザに対する品質」を担当しており、Webやアプリを開発している各部署から、ユーザーテストの依頼を受け、サービス評価と関係する社内コンサルを実施しています。 ユーザーファースト推進グループでは、目的によって4種類に分けた評価を行っております。 専門知識に基づく評価 ＋ ユーザによる評価（ユーザビリティテスト） 社員でユーザビリティテスト ＋ 専門知識に基づく評価 リモートユーザビリティテスト ＋ 専門知識に基づく評価 社外の方でユーザビリティテスト ＋ 専門知識に基づく評価 これらの結果から、操作での勘違い、ミス、混乱、気になるところを、全部書き出しリストにし、優先順位をつけて総合的に判断し、取り組む課題を決めていきます。 優先順位の項目の一つとして、ユーザーへの影響を「ユーザ体験に基づく深刻度」として評価しています。ユーザビリティを評価するときのポイントとしては、「正しく実施する」よりも「結果がサービスの改善に使われる」ことを優先します。 何はともあれ 自分たちのサービスに対して、使いにくい、こうしたほういい、こうしたいなど、各々意見はあると思いますが、 それは開発者・関係者の意見でしかありません。 大切なのは、実際に使う人が使えているかどうかです。 ユーザーが理解しやすいか使いやすいか、確かめながら試しながら、改善を繰り返して、よりよいプロダクトにしていきましょう。 懇談会の様子 最後に Ltech では、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは、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というチームで作っていけたら、楽しいなと思います。