エンジニアの松尾です。LIFULL HOME'Sの売買領域を支えるエンジニアチームのマネジメントを担当しています。 私はプロダクト開発チームでのコミュニケーションに関心があり、以前は プロダクト開発に関わる3職種の連携 についての記事を書きました。現在も有志メンバーで、プロダクト/チーム作りを「いい感じ」にする活動を行っています。 今回はその活動の中で、輪読会を通してプロダクト開発を振り返った話を紹介します。 輪読会で実現したかったこと 職種間での意見交換 前述の記事でも紹介したように、現在LIFULLのプロダクト開発組織は職能別に分かれており、各領域の専門性を高めやすい構造になっています。相対的に職種間での連携が希薄になる懸念もあるため、議論の場を積極的に設けるようにしています。輪読会の設計や書籍の選定においても「職種間での対話が増えること」という部分は重視しました。 担当マーケット間での意見交換 私の部署の担当領域は「売買」ですが、その中にも「新築一戸建て」「中古マンション」「注文住宅」などの区分があり、プロダクト開発チームも分かれて存在します。それぞれが異なるコンテキストで成長してきたチームですので、チーム間で意見交換するのも有意義だと考えました。 「プロダクトマネジメント」の理解 LIFULLではプロダクトマネジメントの教科書的な立ち位置で「 INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント 」（以下、「INSPIRED」）を参考にしています。多くのマネージャーがこの書籍を読んだうえでプロダクト開発の改善に取り組んでいますが、現場では未読のメンバーも多かったため、輪読会をして考えをすり合わせようという話になりました。 輪読会の作り 参加者 職種、所属チーム、年次、入社区分の多様な14名で実施しました。 当日までの準備 自主的に参加を決めてくれたメンバーのみでの実施でしたので、全員が事前に書籍を読んできてくれることが期待できました。そのため、全員に各章で「印象に残ったところ」や「現場とのギャップ」を事前に記入してもらいました。万一事前に読めなかった場合でも、これらを読むことで議論に参加できます。 当日の議論 事前記入の内容を元に「改善できそうなこと」について議論しました。各回を区切りの良い50ページ程度に分け、全9回での読了となりました。 議事録のフォーマット: 事前記入部分と当日記入部分で分ける 輪読会を終えての気付き プロダクト開発組織としての課題 書籍の内容と現在の組織でのプロダクト開発とではギャップがある部分も多々あり、いくつかの課題（＝伸びしろ）を発見できました。議論の中では下記のような声が多かった印象です。 製品のビジョンを常に頭に置いて、長期的な視点での価値提供を心がけたい 顧客やエンドユーザーの理解にうまく時間を使っていきたい 1週間に10個くらいのペースでアイデアを検証できるしくみを目指したい LIFULLでのプロダクト開発 一方で、「他部署にあるノウハウを活用すれば、効率的により良いプロダクト開発に近付いていけるのでは」という意見もありました。 弊社には UXリサーチを専門とする部署 があり、いつでもユーザーテストやインタビューについての相談ができます。また、オンラインでインタビューができる uniiリサーチ というサービスも提供しており、社内でも活用されています。新規事業を専門に扱う部署では、日々高速にアイデアが検証されています。 今後は社内ももちろんのこと、社外とも積極的に意見を交換することでより良いプロダクト開発を目指していきたいと感じました。 まとめ 「INSPIRED」から多くの学びを得つつ、LIFULLのプロダクト開発に伸びしろを感じられた輪読会となりました。今回議論したことを具体的にアクションに移しつつ、より良いプロダクト開発チームを目指していきます。 最後に、LIFULLではともに成長していける仲間を募集しています。詳細は募集求人やカジュアル面談のページをご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング3Uの二宮です。 リモートワークでは、ふとした時に便利なツールやTipsを教えてもらうことって減ってしまってませんか？ そこで私たちは「個人的に生産性向上のためにやっていることをなんでも共有する」という内容のグループワークを実施し、実際にいくつかの面白いツールや方法論をいくつか知ることができました。今回はその内容を紹介します。 グループワークの目的や経緯 私たちの月次定例では毎回30分のグループワークの時間を取っていて、そこで様々なワークを行なっています。 以前のチームビルディングの記事 でも書いたように、私たちのユニットは複数のプロダクトを担当するグループに分かれています。そのプロダクトの状況やフェーズが異なるため、コミュニケーションの必要性は感じつつも、こうした機会をどう活かすかを試行錯誤しています。 今回「個人の生産性向上」に注目し、「個人的に生産性向上のためにやっていることをなんでも共有する」というテーマのグループワークをやってみました。その経緯を詳しく説明すると、次のようなものです。 私たちは普段、生産性向上の取り組みとして、PRのマージ数等のいくつかの指標を見ながら、それぞれのチーム（グループ）で改善活動を行なっており、一定の成果が上がっている 一方で、リモートワーク中は個人の開発ノウハウは伝えづらい。それを補完するものが欲しい ちなみに、他には次のようなワークをやりました。 新卒から他のメンバーへの質問（たとえば会社のことや、仕事の心構え、趣味のことなど） ECRSフレームワーク を使ってみて、自分たちの無くせる仕事を考えてみよう（これは他部署でやってよかったものを取り入れました💪） LT大会 繰り返しにはなりますが、メンバー個人の意見としても、リモートワークでは一人で集中して仕事するような時間は確保しやすい代わりに、隣の同僚に便利なコツを教えてもらうようなタイミングは減っているように感じます。100%のリモートではなく週に何回かは出社しているのですが、結局それぞれのグループ（プロダクトチーム）内でしかコミュニケーションできないことが多く、新型コロナウィルスの感染状況によって出社できない時期もあります。 そのため、こうした機会は久しぶりで新鮮な感覚でした。 実施した内容 やったことはすごくシンプルで、要約すると「ブレイクアウトルームに分かれ、個人的にやっていることをひたすら出して共有する」という内容です。 全体説明: 2分 チーム（ブレイクアウトルーム）に分かれて、JamBoardにひたすら挙げる: 3分 各チーム内で共有する: 20分 各チームから「これは是非ともみんなに共有したい！」というベストプラクティスを選んで共有する: 5分×3チーム 実際のJamBoardはこんな感じです。 話題に挙がったもの 次に、実際に薦められたものを紹介します。 ウルトラワイドモニター 私にとって特に衝撃的だったのが、 こちらのウルトラワイドモニター です。「画面を6分割(!)できるから快適だ」という話をしていて、普通サイズのデュアルディスプレイより快適さは増しそうです。 ただ、私の使っている机のサイズには大きすぎるので、個人的な採用は見送りました😅 また、机の上のスペースの有効活用のために、モニターアームを薦めている人も何人かいました。 WEBサービス すぐ使い始めたのは Google Cloud Search というサービスです。LIFULLではGoogle DriveやGmail、公式のアナウンスにはGoogle Groupsを使っていて、それらを一括で検索できます。 例えば、 以前このブログでも紹介されたLIFULL Tech Hubという社内カンファレンスイベント について調べてみると、次のように、公式アナウンスや当日の発表資料が一括で検索できることがわかります。 開発ツール ユニット内ではVSCodeの利用者が多く、当然そのプラグインも紹介されていました。レビューや相談時には、Open in GitHubは役立ちそうです。 Open in GitHub （GitHubの該当箇所のURLが取得できる） Edit csv （csvの中身をスプレッドシートのように編集できる） Jupyter Notebook （分析ツールのJupyter NotebookをVSCode内で利用できる。remote sshとの組み合わせ可） Awesome Emacs Keymap （キーバインドをemacsにする） 他にもツール関連では、次のようなものを挙げられてました。 fish shell を使う Karabiner-Elements を使って、US配列 Macのコマンドキー単体で英数/かなを切り替えられるようにする Scroll To Text Fragment Bookmarklet（指定の箇所までスクロールするURLを作るブックマークレット）を使う これは素のGoogle Chromeの右クリックで可能になっていました。便利〜！ Chromeの別ユーザーを作成して、複数のAWSアカウントにログインする 仕事術やTipsなど 「6~7割くらいで一旦レビューを出す」とか「一通り作ったら見せてみる」など、いわゆる仕事術もいくつか挙げられていました。 できるだけ早く終わらせる。6~7割くらいで一旦レビューを出す できるだけキーボードのショートカットを使う。そのためにマウスを禁止する！ 文章や言葉の前に、手書きで図を描いて考える VSCodeでお気に入りの画像を背景にすることで業務効率をアップさせる 3つ目は私も実践しています。これがそのまま人に共有できると便利なので、もっとホワイトボードっぽいツールが発展してきてほしいですよね…。 まとめ 自分が当たり前だと思っていたツールや方法も、意外と他の人から見ると知らないもので、「え、そんな便利なものあったの」と思うこともあります。こうしたグループワークを行うことで、簡単に棚卸し&共有できそうです。 また、この定例の後でもしばらくチャットで雑談が盛り上がっていて、便利ツールの紹介や自慢話は、エンジニアならいつでも盛り上がる鉄板ネタなんじゃないかとも感じました。もしかすると初対面同士のアイスブレイクにも向いているテーマなのかもしれません。 最後に、LIFULLでは一緒に働く仲間を募集しております。興味を持っていただけた方は、募集求人やカジュアル面談のページもご覧ください。 hrmos.co hrmos.co

　こんにちは！LIFULLプロダクトエンジニアリング部の 鄭 在淳（ジョン・ジェスン） です。 2022年4月1日に新卒で入社して、4月末に日本に入国したLIFULLの韓国人エンジニアです。 　この記事ではコロナパンデミックの中で、どのような過程を通じて外国から入社し、リモートワークでどのように研修と業務に取り組んでいるのかについてお話したいと思います。始まる前に 中村さんの LIFULLの新卒エンジニア研修 in 2020 趙さんの 外国人が日本に来た３年間の生活×お仕事 のような記事もありますので、関心がある方は是非一緒にご覧ください。 目次 目次 入社前 外国から入社することに対する不安感 入社1ヵ月前に日本入国制限解除 リモートで参加した入社式と新卒研修 入社後 LIFULLでのリモートワーク リモートワークのための様々なツール 配属後 自由なチームコミュニケーション 多様に協業する開発カルチャー 最後に 入社前 外国から入社することに対する不安感 　私のように日本または海外で就職を考えている方々が最も不安に思っている部分が「もし、色々な事情で入社日前に入国できなかったらどうしよう」ということだと思います。 　特に、まだコロナパンデミックが流行っているので、さらに不安を感じると思います。 昨年、私も韓国に住んでいましたので、すべての選考をオンラインで行って内定を受けましたが、「もし入国できなくなったらどうしよう？」という不安感がありました。 　しかし、LIFULLにはリモートワークのための社内システムやツールなどが導入されており、私のような外国人社員がCOVID-19のような特別な事情で日本に入国ができなくなってしまったとしても、海外にいながら入社し業務を開始できたり、日本の銀行口座がなくても給与を国際送金で受け取れる仕組み等をパンデミックが発生した後に急ぎ整えてくれていました。 　こういった入社前の不安に対して、新卒採用担当者から内定後の労働条件の説明と共に詳しく説明して貰えたので、韓国から日本の会社に入社することに対して安心できました。 入社1ヵ月前に日本入国制限解除 　幸い入社1ヶ月前、ビジネス目的の日本入国制限が解除され、入社日に合わせて日本に入国できるようになりました。 入社前に連絡を取り合っていた同期たちと会えるというときめき、新しい場所での新生活を始めるというドキドキ感などがあったので、初めて入国制限解除ニュースを見た時はとても嬉しかったです。 　しかし一方で、1カ月以内に両替や家探し、書類申請や発給などの入国に必要な準備をすべて終えられるかという悩みがありました。そのように一人で悩んでいたところ、新入社員教育を担当する人事担当者が先に連絡をいただき、「入国を急がなくてもいいので、必要な手続きや準備が終わった後に入国日程をゆっくり調整しましょう」とおっしゃってくださいました。 　このように配慮して頂いたおかげで、私は焦りを感じずに少しずつ入国準備をすることができ、入社日以後に行われた新卒研修にも集中して参加できました。 リモートで参加した入社式と新卒研修 　LIFULLでは新入社員がリモートワークに関係なく、スムーズに入社準備ができるよう業務に必要なPC（エンジニアとデザイナーはWindowsとMacの中で自由に選択可能）と教材を自宅に送ってくれます。私も韓国に配送して頂いてスムーズに入社準備ができました。 　また、オンラインとオフラインで並行して行われた入社式でも、両会場の状況をリアルタイムで共有して頂いたおかげで、リアル感と満足感を感じながら入社式を楽しめました。その後、オンラインで行われた新卒研修を受けていたところ、連休のゴールデンウィーク中に日本に入国し、約3ヶ月間生活を続けています。 入社後 LIFULLでのリモートワーク 　最近、コロナウイルスによって多くの方がリモートワークを経験したことがあると思いますが、「リモートワークの方がかえって不便だ」と思っている方もいらっしゃると思います。特に、私のように引っ越し直後にインターネット環境が整っていない状態で、すぐにリモートワークをすることが難しくなるかもしれません。 　しかし、LIFULLでは、業務用として全社員に支給されているiPhoneのデータテザリングを活用すれば、場所の制約なしに（周辺のセキュリティ対策が完備しているという前提の下で）リモート勤務ができます。 私も入国直後、約3週間問題なく業務ができました。そして、社内では様々な地域に拠点がある LAC （自社の地域創生サービス）に行ってDigital nomadを追求している方もいらっしゃいます。 　また、フレックスタイム制度があり、コアタイム11～16時は勤務する必要がありますが、1ヵ月の所定労働時間を満たせば、始業と終業時刻を規定の範囲内で自分で決められます。規定の中で、自由に勤務時間帯を決定できるので、リモートワークとシナジー効果が発揮され、最高の業務効率を上げることができます。 リモートワークのための様々なツール 　LIFULLではコミュニケーションによく使われるメール以外にも、全社コミュニケーションツールとしてSlackを導入しています。その他にもGoogle WorkspaceやJira・Confluenceなどのツールも多様に導入していて、全社員とコミュニケーションを取ったり、業務に必要な各種申請や資料検索をオンラインで簡単に行うことができます。 　特に、うちの部署では「Gather Town」を導入しており、リモート勤務中にもリアルタイムで自然にコミュニケーションができます。また、スクラムを効率よく進めるためにMiro、Plapoなども幅広く導入しているので、リモート勤務の生産性が向上しています。 配属後 自由なチームコミュニケーション 　現在、LIFULL HOME'Sのプロダクトエンジニアリング部に配属され、主に LIFULL HOME'S 不動産アーカイブ の開発業務を担当しています。LIFULLにはメンター制度があり、配属後の技術的なオンボーディングをサポートしたり、「コミュニケーションシート」や「基礎力チェックシート」などを活用した毎週の振り返りを通じて、考え方やキャリアなど幅広い視点について交流ができます。 　そして、週1日はコミュニケーションデイ（コミュデイ）に指定されていて、オフィス勤務（上長の承認で調整可能）をしています。コミュデイには各グループまたは部門のメンバーが対面業務を進めることで、関係の強化を図ることができます。私は初出社日にコミュデイを終えて、先輩社員たちと一緒に会社の近くの居酒屋で楽しく飲み会をしました。 　また、チームビルディングには社員1名あたりの部内コミュニケーション費が支援され、私が配属されている部署では先日の6月、 高尾山LAC に行ってきました。同じ部署の組織員たちがお互いに知り合うプログラムを実施し、BBQや懇親会などを楽しみながらメンバー間の距離感を縮めることができました。 多様に協業する開発カルチャー 　私が部署に配属され初めて実装した施策は、新機能である 物件の画像一覧ページ でした。新機能を実装して、既存のプロダクトに追加することでしたので、基本プロダクトの仕組みを損なうことなく機能仕様書に合わせて実装することが重要でした。 　ただ、ドキュメントで作成する機能の仕様書だけを見て実装するのではなく、エンジニアと企画者、デザイナーが１つのチームになってプロダクトを運営しているため、開発中に困ったり大変だったりする点があれば、いつでもチームメンバーと相談できます。特に、うちのチーム内で導入している「Gather Town」を通じて気になることがあれば、簡単に声をかけて素早く解決できました。 　また、チーム内にはプロダクト管理のためのスクラムフレームワークを導入しています。スプリントを開始する際、チームメンバー全員が期間内に創出しようとする価値について計画（スプリントプランニング）を立てます。スプリント終了前にはお互いに成果物についてレビュー・称賛し（Winセッション）、KPT方式で振り返り（レトロスペクティブ）しています。このようなスクラムイベント以外にもソースコードレビュー・テストなどを行い、持続的な改善による柔軟でスピーディーな成果を出しています。 最後に 　LIFULLのエンジニア組織は エンジニアとして経営をリードする ことで活躍するというスローガンを掲げています。短期的に技術の幅を広げるだけでなく、技術を手段として中長期的に社会課題解決に貢献していくことを目指しています。 　LIFULLのコーポレートメッセージである「あらゆるLIFEを、FULLに。」を実現することには国籍、年齢などの制限はないと思います。私と一緒にLIFULLの同志になって、価値創出を最大化して行きませんか？ hrmos.co hrmos.co

いつもお世話になっております。検索エンジンチームの秀野です。 試験的な取り組みとして、社内通貨LIFULL COINを使って新規事業提案制度の審査会で投げ銭投票を行いました。結構時間が開いてしまったのですが、その時の紹介をしたいと思います。 LIFULL COINについては、過去に紹介したことがあるので、よろしければこちらの記事もご覧ください。 社内通貨LIFULL COIN x Slackでピアボーナス - LIFULL Creators Blog 新規事業提案制度SWITCHとは LIFULLには、SWITCHという新規事業提案制度があります。年間150件以上の提案があり、そのいくつかは事業化もされています。 事業化フロー中に何回か審査があり、最終審査会では従業員も発表を聴くことができます。その最終審査会で、LIFULL COINを使って従業員に投げ銭投票をしてもらいました。 投げ銭投票を導入することで、従業員も評価に参加することができるようになります。 それによって、従業員はより当事者意識を持って自社の新規事業提案を聞くことができますし、発表者にとってもより多くの人の関心度や評価を知ることができるのではないかと思います。 SWITCH - LIFULLの社内新規事業提案制度 | LIFULL STARTUP STUDIO LIFULL COINで出来たこと 投げ銭投票の説明をする前に、簡単にLIFULL COINで何が出来るか説明します。LIFULL COINには通貨として基本的な機能があります。 社内通貨として コインの発行（Mint） コインの焼却（Burn） Webベースの口座管理アプリケーション 口座の開設 残高確認 送金 送金履歴 コインの分配（クールダウン型ベーシックインカム） Slack bot リアクションに連動したコイン付与（ピアボーナス） ピアボーナス受信通知 残高確認 ピアボーナスランキング なので、投げ銭投票を行うには、下記のような手順を踏めば比較的簡単に実現できると思っていました。この時までは。 発表者の口座、聴衆（従業員）の各口座、を作成 聴衆の口座にコインを投票用に分配 聴衆が自身の口座から、発表者の口座にコインを送金（投げ銭投票） 発表者の口座ごとに投票金額を集計 最初の投げ銭投票 審査会での投げ銭投票は何度か行われました。 聴衆はスマホ片手に発表を聴き、任意のタイミングでコインを投げ銭します。投げ銭は、手元の10000コインから定額（100コイン/500コイン/1000コイン）をボタン1つで送ることができます。 発表を聞いていて感心したら、そのタイミングで1000コインボタンを3回押して3000コイン投げ銭する、そんなイメージです。 出金を行えるのは、秘密鍵を使って振込先となるスマートコントラクトをデプロイした発表者のみです。期間指定で着金と出金を制御して、投げ銭と総取りが可能な期間を制御しました。 不正投票に対する懸念点 LIFULL COINはブロックチェーンで管理しているので、送金を行う場合は秘密鍵での署名が必要になります。当時かぶれていた私は秘密鍵をユーザー側で管理したいと思い、ブラウザのローカルストレージに保存するという罪を犯してしまいました。ダメなことは分かっていたのですが、社内システムだし、鍵が盗まれても実害はないし、一旦いいだろうという判断(？)です。 その結果、良くも悪くもブラウザのプロファイル単位で口座開設が可能になり、投げ銭投票の際に複数口座を開設し不正投票を行える、という懸念がありました。 LIFULL COINには、利用者全体の価値観で評価された価値にコインを発行するという目標もあったので、話し合いの結果従業員の価値観に任せてみることにしました。不正投票があったらあったで、そういうことだったというだけです。 ド直球の不正投票 審査会での投げ銭投票自体はつつがなく行われ、投票結果の発表、表彰まで無事に行われました。 しかし、結論から言ってしまうと、ここで優勝した発表者に対して不正投票が行われていました。複数の口座を開設し、コインを受け取り、短時間で大量に投げ銭するというド直球のものでした。いい負荷テストになりました（半壊した）。 ちなみに、投げ銭投票で優勝した発表者は、不正がなくても優勝していました。不正分のコインを差し引いても、最もコインを獲得していたのです。そのため、表彰は結果通りに行われました。 残念ながら人間はそんなに強くないようです。今回の件は次回への課題となりました。 最後の投げ銭投票 しばらくして、またSWITCHの審査会と投げ銭投票が行われました。前回の投票から基本的な仕組みは変わっていません。 前回、不正投票があったことから何らかの対策を考える必要がありました。いくつか案がでたものの、どれもコストがかかりそうだったので今回は「クアドラティックボーティング（ Quadratic voting ）」という投票方法を参考にして対策を考えてみました。以下QVと略します。 クアドラティックボーティング（Quadratic voting）とは 一言でいうと「金で票を買えるが、1票買うごとに価格がえらく高騰していく投票方法」です。 また、下記のような運用ルールがあります。 投票者は一定のコインを付与される 票を購入して投票できるし、買わずに蓄積することもできる 票を購入するのに必要なコインは となる 1票買うと1コイン、2票買うと4コイン、3票買うと9コイン、・・・というように合計 票を購入するのに必要なコインは となる仕組みです。 言い方を変えると、1票目は1コイン、2票目は3コイン、3票目は5コイン、・・・となります（これをMarginal Costと言います）。 QVについてはこちらの記事が詳しいです。 「個人が公共財に影響を及ぼすために支払うコストは、個人がもつ影響の割合ではなく、その二乗（quadratic）に基づく必要がある」というなぜ票数の二乗なのか、といった説明がなされています。 alis.to 不正投票防止の工夫と欠点 QVにはいくつか欠点もあるようです。 コインを配布し蓄積ができることで、談合によりコインの融通や買収が行われやすい点です。 こういった問題は既存の投票でも起こりうるものの、1票目が安いことからコインの融通より投票者の買収のほうが行われやすそうです。 不正をなくす仕組みのせいで不正されては元も子もないので、投票者にはQVを導入することを伏せたまま投票してもらいました。 投票者は投票したコイン数がそのまま発表者の得票数になっていると思っているはずです（コイン数＝得票数）。 実際は、投票されたコイン数の平方根を得票数として計算しました（ ＝得票数）。 この仕組みでも、大量の投票があった場合は少なくない得票数に換算されてしまうのですが、前回の経験からその前にシステムが高負荷で全壊するはず、という確信がありました。 結果 まず、不正自体が行われませんでした・・・いや、それでよかったのですが。 発表から集計、表彰までつつがなく行われ無事に終了することができました。 QV自体の感想としては、今回の仕組みだと元々QVのメリットの1つである「投票者個人の思いの丈」を乗せるような投票はできなくなるのですが、優先順位付けを行う投票では有効なのではないかなと思いました。 今回のように様々な社会課題に対する解決策が並び評価される場では、やはり投票者の関心度を票に乗せられるQV本来の仕組みが活きるように思います。 また、いずれ機会があれば集計処理だけでなく、票をNFT化して購入から投票まで実装することで、社会課題解決への共感や関心の高さを票に乗せられるような仕組みを作りたいと感じました。 LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。エンジニアの加藤です。LIFULL HOME'Sの注文住宅領域を支えるエンジニアチームのマネジメントを担当しています。 弊社では昨年度よりKPIマネジメントを導入し、さまざまな組織課題の解決や目標達成に向け活用しています。 私がマネジメントするエンジニアチームでも同様に開発生産性向上を目標とし、KPIマネジメントの手法を用いて実現への取り組みを実施してきました。 そのような中、今回はこの半期においての私のチームでの取り組みについて紹介したいと思います。 KPIマネジメントの概要や今までの取り組みについては以前 こちら のブログでも投稿いたしましたので、よければ併せてご覧ください。 www.lifull.blog CSF・KPIの選定 KPIマネジメントは4MCと呼ばれる4つの主な要素（Goal, KGI, CSF, KPI）から成り立っています。 そのうち、GoalとKGIはエンジニア組織全体で目線をそろえるため、共通的な目標・指標を設定しています。 Goal 開発生産性の向上 KGI 一人当たりのPullRequestマージ数（前期比115%UP） そのため、各チームでは今期を通して一人当たりのPRマージ数を115%増加させるために必要なCSF、KPIの選定を行います。 私のチームではこれらの選定にあたりまずはデータを元に現状を把握するところから取り掛かりました。 現状把握 「時間」に焦点を当て、総業務の内どれだけの時間を開発またはそれ以外の業務に費やしているのか、実装プロセスの内どの工程にどれだけの時間を費やしているかを整理したものが以下の表となります。 構成要素 コントロール可否 計測可否 前期の状況 総業務時間 全体 × ◯ 開発時間 ◯ ◯ 54% 運用時間 ◯ ◯ 3.6% MTG時間（組織系） △ ◯ 前期までは測定不能 MTG時間（開発系） ◯ ◯ 1タスクあたりの開発時間 全体 ◯ × 開発着手からPRマージ ◯ × 1stコミットからPRマージ ◯ △ 平均：254.27時間（約10.6日） 開発着手からPR作成 ◯ × 1stコミットからPR作成 ◯ ◯ 平均：130.94時間（約5.5日） PR作成から1stレビュー ◯ ◯ 平均：54.95時間（約2.3日） PR作成からマージ ◯ ◯ 平均：123.33時間（約5.1日） CSFとKPIを選定する上でのポイントとして、KPIマネジメントでは以下のことが言われています。 CSFは現場でコントロールでき、努力で変化するプロセスであること KPIは即座に計測・入手できる指標であること これらから、各データに対してはコントロール可能であるか、計測可能であるかどうかも併せてまとめました。 選定 データを見える化したことで意外な事実に気付きました。 これまでは主観的に社内関係者からの質問・相談対応や定期・不定期問わずの運用業務が多く、開発時間を逼迫する要因だと思っておりました。 しかし、実際のデータを確認することで運用業務にかかる時間は4%弱しかなく、50%以上の時間は開発業務に充てられていたのです。 そこで、今改善すべきプロセスは開発に充ている時間を増やすことではなく、開発工程の中にあると想定し一つの時間に着目しました。 それが「 PR作成からマージ 」の時間です。 この時間は主にコードレビューにかかる時間を表していますが、平均約5.1日かかっており、実装時間（1stコミットからPR作成）とほぼ同等の時間を要していることが分かりました。 そのためコードレビューにかかる時間を短縮することが、開発生産性を高めるための最も重要なプロセスであるとしてCSFに選定しました。 CSF コードレビュー時間の短縮 KPI PullRequest作成からマージまでのリードタイム PDDSサイクルを回す 4MCが決定したら日々の業務の中で実行し改善サイクルを回すことが重要です。 PDCAが普段よく耳にする言葉であるかと思いますが、 最高の結果を出すKPIマネジメント の中では PDDSサイクル が提唱されています。 PDDSサイクルは Plan （よく考え）- Decide （すばやく絞り込み）- Do （徹底的に実行し）- See （きちんと振り返る）で構成されます。 私のチームでもPDDSサイクルを意識し日々の改善活動に取り組んでいます。 具体的なアクションに落とし込んで実行する CSFはKGIの達成のため最も重要なプロセスとなりますが、それだけ決まっていれば日々の業務の中で行動を変えられるわけではありません。 そのため私のチームでは、CSFの実現につながる具体的なアクションを 一つ 週次で決め、実行しています。 今まで実行したアクションの実例を少し紹介します。 長期間残っているPullRequestの整理 改善活動を実行するためには、正しくデータを計測できることが重要です。 しかし、現状長い時間コードレビューされず放置または後回しにされたPullRequestが存在し、それらがあるタイミングでマージされることで直近のリードタイムが正しく計測できない問題がありました。 そのため、まずはそのような長期間残っているPullRequestをすべて洗い出し、不要な修正はClose、必要な修正は優先的にコードレビューすることですべてのPullRequestの整理を行いました。 その結果、計測結果にノイズを発生させるようなPullRequestはすべてなくなり、正しく計測できる状態へと変化しました。 コードレビュー期限の明確化 コードレビューの時間を引き伸ばす次なる要因としては、プロジェクトチーム横断的なタスクにありました。 基本的にチームの各メンバーはプロジェクトに参画し、主にプロジェクト内で開発活動を行うことになります。 一方で突発的な開発作業やリファクタリングなどのコード修正が発生することもあり、これらの実装およびコードレビューはプロジェクトとは切り離して実施されます。 そのため、このようなタスクはついつい後回しにされがちで結果PullRequestを作成してから放置される傾向にありました。 これらの課題を解決すべく、コードレビュー依頼者はあらかじめレビュー期限を明確化し、期限内にレビュー可能なメンバーが引き受けることとしました。 レビュアーの指定 レビュー期限を明確化することで、横断的なタスクであっても長期間PullRequestが残り続けることはなくなりましたが、次なる課題も見えてきました。 コードレビューを依頼する際Slackでメンバー全体に投げかけているのですが、お見合いが発生しレビュアー決定まで無駄な時間が発生していたのです。 そのため、依頼者がレビュアーを指定し、直接調整することでほかのメンバーとのお見合いを防ぎました。 定期的に計測し振り返る アクションを実行することで日々状況が変化するため、その変化を計測し振り返り、次なる打ち手を検討することが重要となります。 私達は毎週の定例ミーティングにて以下の枠組みで計測・振り返りを実施しています。 KPI・KGIの計測結果確認 今週のアクションに対しての振り返り 次週のアクション決定 これらPDDSサイクルを実行することで、コードレビューにかかる時間は徐々に短縮され結果として表れてきています。（PR作成からマージ：123.33 → 36.55） KPI計測結果（投稿時の直近数週間） まとめ 今回はKPIマネジメントを活用した開発生産性向上への取り組みを共有させていただきました。 組織課題について同様に頭を悩ます方も多くいらっしゃるかと思います。この記事がそういった方々の一つのヒントになれば幸いです。 また最後にLIFULLでは一緒に働く仲間も募集しているので、よろしければこちらも併せてご覧ください。 hrmos.co hrmos.co

はじめに こんにちは！AI戦略室の曽迪(ｿﾃｷ)です。LIFULL社内の技術や知見を集結させて議論するイベント: LIFULL Tech Hubの運営リーダーを担当しています。今回はLIFULL Tech Hubについて紹介します。 LIFULL Tech Hubとは LIFULL Tech Hubとは、過去に「AI戦略室成果展示会」という名称で開催されたイベントをさらに発展させた全社カンファレンスです。 そもそも私が所属するAI戦略室は、事業部とは独立した組織であるため事業部との距離感が生じやすく、研究開発組織として活動や成果を発信し会社全体に存在意義を認知してもらう必要がありました。「AI戦略室成果展示会」はその流れで開催されたものとして、以来定期的に全社イベントとして開催してまいりました（ 過去のAI戦略室成果展示会の紹介 ）。 これらのイベントを開催する過程において、社内には私たちと同じ課題を持っている部署やメンバーがいることに気づきました。つまり、近視眼的なプロジェクトにおいては日の目を浴びないような、埋もれがちな技術や知見を持っている社員が想像以上に多いということです。 そこで「AI戦略室成果展示会」という名称を、LIFULLのコアな技術や知見が集まる場という意味を込めて「LIFULL Tech Hub」という名称に変更し、職種を問わずに誰もが社内の技術を発信・傾聴できる社内カンファレンスとして開催することになりました。 今期の開催状況 今期のLIFULL Tech Hubは6月7日にオンラインで開催されて、来場者が合計140名の大盛況となりました。今期は15件の発表があり、エンジニアだけではなく企画職も登壇され、幅広いテーマで発表が行われました。発表はZoomのブレイクアウトルーム機能を利用したポスターセッションで行われました。 発表テーマ 発表は合計15件ありましたが、今回はその中の３つをピックアップして紹介したいと思います。 3D間取りの現状と今後の活用 こちらはAI戦略室が担当しているプロジェクトです。 LIFULLでは物件の間取り図から3Dイメージを作成する技術に取り組んでおり、2021年3月より、「LIFULL HOME'S 3D間取り」としてサービスを公開しました。このサービスでは、3Dの物件イメージを構築することで、まるで実際に物件の内見ができるかのような体験ができるサービスとなっています。3D間取りの現状と今後の活用について紹介しました。 開催中の様子 過去に投稿した3D間取に関する記事： 間取り図をディープラーニングで解析して3Dモデルをつくる - LIFULL Creators Blog KEELチームと話そう KEELチームは全社アプリケーション実行基盤 KEELを開発したチームです。 エンジニアと何でもカジュアルに相談や疑問、リクエストなどはここで話せます。エンジニア向けのKEEL導入の相談、インフラ周りで困ったことなどの相談する場です。 KEELの資料 過去で公開したKEELに関する記事： Ltech#20 Kubernetesを用いたアプリケーション実行基盤の取り組み 開催レポート - LIFULL Creators Blog LIFULLの全社アプリケーション実行基盤 KEEL について - LIFULL Creators Blog RSpecの技術的負債をチームで解消した話 RSpecの技術的負債をチームで解消した話の内容を中心に、運用しやすいテストコードのあり方やテストコードの悩みについて議論しました。そのほか、売却査定のチームで行ったCodeBuildによるCI導入やフロントエンド領域のVite導入についてや、開発スピードを上げるためのチーム作り方の秘訣など、盛り上がりそうなテーマで話しました。 開催中の様子 過去で公開した関連記事： RSpecの技術的負債をチームで解消した話 - LIFULL Creators Blog Vite Backend Integration 👋 レガシーJS - LIFULL Creators Blog 特別講演 LIFULL Tech Hubは通常の発表後、特別講演も設置しています。特別講演は他社から研究者を招待しています。特別講演は技術の話以外に、働き方の話も紹介しています。 AI戦略室データサイエンスパートナーの鹿内 学氏に「データではじめようイノベーションを目指す組織開発」というテーマで話していただきました。 HRの分野に精通した同氏が、イノベーションを起こす組織に共通する「信頼」を構築するために、日々のデータをどのように見るべきかを事例を交えつつ紹介していただきました 人事組織の社員のみならず、ものづくりに携わる私たちにもたいへん参考になりました。 開催中の様子 運営上の工夫 誰でも気軽に参加できる環境作り 全社イベントにおいては心理的な負担・作業的な負担を最小限にするために、発表形式としてポスターセッションを選択しました。発表テーマ不問、ポスター（スライド）1枚あれば誰でも発表できます。自分の都合に合わせていつでも入退場可能な形式を整えました。運営側としては最小限のコストで最大限の効果を目指して運営できました。 案内と集客 発表者として参加する場合、エントリの方法からイベント当日の発表までの流れなどの情報を簡潔に準備しました。発表者は資料一枚を見れば、イベントの参加方法が分かります。 聴講者に関しても、全社広報で頻繁に開催の案内を出しました。多くの部署に参加していただき交流を活性化させたいので、上位層の承認を得てカレンダーに予定を追加し、全社的な交流を図りました。 部署間で交流することで知見を共有できるような環境作り 技術と成果物などの紹介だけではなく、アイデアベースの議論などさまざまなテーマの情報発信が可能です。コミュニケーションが活性化するのため、発表形式をポスターセッションにしています。聴講者と発表者間のコミュニケーションがしやすくになります。普段は拾えない他部署からの声を拾うことによって、部署間の横断的な交流による知見の共有ができる場を作りました。 開催後の反響・影響 LIFULL Tech Hubは社内からさまざまな反響がありました。開催後のアンケートの結果、4.3点の高い満足度（5点満点）になりました。参加者からの声としては、 「プロジェクトの技術共有を期待していました。実際、期待通りの共有を受けることができて満足です。」 「技術で解決できそうなアイデア出しをするような場所にもなっていたので、とても楽しかったですー！」 というポジティブフィードバックがありました。 一方で、課題としては、 「社内の多くの部署に参加してもらうためには、さまざまなSlackチャンネルで広報して欲しかった。」 「LIFULL Tech Hubに参加できなかったという方から、当日の各発表内容、動画で見れないかご要望をいただきました。」 といったような集客や運営方法に関するフィードバックをもらいました。次回以降を開催する際には、より多くのメンバーが気軽に参加できるような運営体制を整えていきたいです。 終わりに このような誰でも技術やアイデアを発信できる場は、全社的に必要かと思い、これからも継続的に開催していく予定です。LIFULL Tech Hubが社内にさらに良い影響を大きくするために、今後は開催後に部署間の連携が促進されるようなカンファレンスにしていきたいと思います。 hrmos.co hrmos.co

こんにちは！ LIFULLエンジニアの吉永です。 本日はエンジニアの自己研鑽について、自分はどんなことをやってきたかを紹介します。 ソフトウェアエンジニアを目指している人や、ソフトウェアエンジニアとして今後のキャリアプランに悩んでいる人の参考になれば幸いです。 私については、以前noteへ投稿した下記の記事に自己紹介と略歴が記載されているので、宜しければご参照ください。 note.com アジェンダ 自己研鑽の方法と変遷について 2007年～2009年頃 2010年～2014年頃 2015年～2019年頃 2020年～現在（LIFULLに入社してから現在） まとめ 最後に 自己研鑽の方法と変遷について 私は2007年4月にソフトウェアエンジニアとしてのキャリアをスタートし、2015年3月までは放送機器の組込ソフトウェアエンジニアとして働いていました。 思い返してみると、自己研鑽の為のインプット手法や内容がだいぶ変わってきたので、それぞれの年代ごとにざっくりと内容をまとめます。 2007年～2009年頃 新卒で配属されてからの3年間はひたすら先輩の作成したプロダクトのコードや設計資料を読み漁り、 ドメイン知識を身に付けることに重きを置いてました。 よって、自己研鑽もドメイン知識に役立つ事柄が多く、例えば書籍で言うとマスタリングTCP/IPの 入門編 と 応用編 、 C言語による標準アルゴリズム事典 などを購入して読んでました。 当時は組込ソフトウェアエンジニアなので、メインの開発言語はC言語、組込機器でもネットワークに接続することが必須となり、システムインテグレーターの方々が放送システムに採用する際にSNMPによるステータス監視に対応できているか？ファームウェアアップデートなどのメンテナンスはFTPやHTTPを用いて、ネットワーク越しにできるように考慮されているか？などが求められており、パケットキャプチャソフトでTCP/IPパケットをキャプチャして、デバッグ時にどちら側の問題かの切り分けをする必要もあり、 これらの知識を得る為にネットワーク知識をつけました。 また組込機器はROMサイズがかなりシビアでC言語のサードパーティーライブラリを採用することが難しく、世の中一般的にはOSSで公開されている、 枯れた技術でも自分たちで実装する必要 （例えばJPEG画像のデコードとかトゥルータイプフォントの展開処理とか）もよくあったのでアルゴリズム事典のコードを参考にしたり、 玄人の書いた難解なコードも読み解けるよう にしていました。 また、チーム内でトレンド情報にアンテナを貼ろうという施策を実施していた時期は毎日チームメンバーが日替わりで気になったIT系のニュース記事をメールで共有していたので、 IT系のプレスリリースはこの頃から良く見るようになっていた と思います。 2010年～2014年頃 この頃辺りから組込機器だけでなく、Windows GUI開発を行う機会も増え、Windows GUI開発ではVisual C++というMSが独自に作ったC++ベースの言語を使っていたので、学生時代に少しだけ勉強して、 雰囲気で理解したつもりになっていたオブジェクト指向についてを再度勉強しなおしていました。 なので、独習シリーズの C++ / Java / C# と 独習UML を購入して良く読んでいました。 結果的にはC++で開発する時だけでなく、組込機器の開発時にC言語でも オブジェクト指向を意識してプログラミングできるようになっていた り、UMLのアクティビティ図やステートマシン図、コンポジット構造図はWindows GUIだけでなく、組込機器の設計資料などにも採用するようになりました。 ※それまではわりとフリーフォーマットで図を描いていて、フローチャートぐらいしか規定された図がなかったのでUMLである程度のフォーマットを規定してくれていることが先輩方からも好評でした。 あとは2014年頃にAndoroidとiOSのアプリをプライベートで作成したりして、直接当時の業務と関りはないが、色々な知見を得るってこともやったりするようになりました。 2015年～2019年頃 2015年4月からはWebアプリケーションエンジニアに転身したので、インプット方法はそれまでの書籍メインから、 Webで検索するというのがメインになっていきました。 ※組込系はそもそも環境依存系の問題なので、ググっても情報が見つからないことが多く、Windows GUIもその当時は既にC#がメインの開発言語になっており、C++関連の情報はヒットしても古い情報ばかりみたいな感じだったので・・・ 2016年からは新入社員向けのプログラミング研修講師をやるようになったことで、インプット中心だった自己研鑽ですが、 プライベートでのアウトプット機会が増えていきました。 講師をやるうえで、自分が理解していることを目の前にいる受講生にどのようにして伝えたら分かりやすいだろう？この人はどんな個所でつまずいているんだろう？ということを考えるようになったので、 アウトプットして、自分で見返してみることで客観的に見れるようになっていった と思います。 アウトプットの代表的なものでいうと、Webで新しい言語に取り組む際によくやっていたのは、学生時代に作ったLinuxで動作するGUIのオセロアプリケーションをその習得対象の言語で書きなおし、言語の基本的な書き方を習得するようになりました。 github.com 上のリンクは個人のGitHubアカウントですが、色々な言語でオセロを実装しています。 コードは正直、自分で見返してみてもイマイチなのですが、手っ取り早くその言語に慣れるのに都合がよかったので、この手法をよくとっていましたね。 2020年～現在（LIFULLに入社してから現在） LIFULLに入社してからは資格取得奨励制度があり、 会社としても資格取得を応援してくれている ので、IPAのスペシャリスト試験を受験して資格を取得することにも取り組むようになりました。 IPAのスペシャリスト試験は自分自身の理解度の確認、理解したつもりだった事柄を再度復習できることから、継続的に取り組んでいます。 下記はその取り組みの結果です。 2020年10月・・・情報処理安全確保支援士試験 合格 2021年04月・・・ネットワークスペシャリスト試験 不合格 2021年10月・・・データベーススペシャリスト試験 合格 2022年04月・・・ネットワークスペシャリスト試験 不合格 勉強方法は始業前か終業後に30分～60分くらい参考書を読んだり、過去問を解いたりを試験の2ヶ月前くらいから継続的に行うようにしています。 ネットワークスペシャリスト試験が自分としては難関なのですが、諦めずに来年もまた受験しようと思っています！ また、LIFULLに入ってからは エンジニアの発信を組織が奨励してくれている こともあり、Qiitaに投稿する機会が増えました。 qiita.com Qittaにアウトプットすることで自分自身の備忘録にもなり、普段の業務で作成する設計資料類を作成するスピードが向上した気がするので、アウトプットを定期的に行うことはとても良いと思います。 まとめ インプットは大事だがアウトプットも重要なので、 学んで満足の状態からは早めに脱した方がいい と思います。 私自身、組込エンジニア時代はインプット中心であり、業務外でのアウトプット機会はあまりありませんでした。 今思うとこの頃にもアウトプットをしていたら、きっとインプットした内容をより早く深い理解の状態へ持っていくことができていたのではないかなと思います。 ソフトウェアエンジニアは常に勉強をし続け、自己研鑽することを求められますが、大事なのは質や量よりも、 継続していくこと だと思っています。 私自身気分が乗らない日もありますし、毎日勉強し続けているわけではありませんが、 継続するコツは、自身のキャリアビジョンを解像度高く持っておく ことだと思います。 ゆくゆくはこういうスキルを身に付けたい、こんなエンジニアになっていたい、などなるべく具体的なイメージを持ち、 そのイメージと現在の自分とのギャップを埋める為に必要なことは？というように思考できると、おのずと行動に繋がっていく と思いますので、ご自身の将来像を具体的にイメージしてみてください。 ちなみに私のキャリアビジョンは、抽象度が高い状態の内容では 「あいつに任せとけばなんとかしてくれる」と周囲から思ってもらえるエンジニアになりたい でして、新卒研修受講後の決意表明で上司や先輩に宣言しました。 これは今でも私のベースにありますが、もう少し具体的なキャリアビジョンとしては、自分自身のスキルや知見は引き続き身に付け続けていくが、得た物をチームメイトにもフィードバックしていき、チームメイトだけでなく将来エンジニアになりたい人のサポートができるような 縁の下の力持ち的な役割 と、 開発チームを牽引していくテックリード 的な両面の働きができるエンジニアになりたいと思っています！ 最後に 最後まで読んでいただきありがとうございます。 LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

どうも エンジニアの「市場価値」を向上する をキーワードにLIUFLLで活動している @サム です。 今回は「LINEやメールなどを通じてリテンションに繋げていくエンジニアチーム」の紹介をしようと思います。 そもそもリテンションとはなにか？ Webマーケティングにおいて「1:5の法則／5:25の法則 *1 」というのがあり、いかに既存顧客を維持しつつ離脱させないかが重要だと言えます。 1:5の法則とは、新規で顧客を獲得するには既存の顧客の5倍はコストがかかる 5:25の法則とは、顧客離れを5%改善すればその利益率は25%改善される リテンションとは既存顧客との関係を維持していくためのマーケティング活動のこと *2 で、継続的にリテンションを続けることによってコストと利益率の改善をおこないます。 リテンションとエンジニアの関係 リテンションとはマーケティングにおけるプロセスの１つで、既存顧客との安定的な関係性を継続していくための手法をリテンション・マーケティングと言います。リテンション・マーケティングを実施するには、膨大な顧客情報のセグメントとパーソナライズが必要になり、それを人がこなすには限界があります。そのため基本はMA（マーケティング・オートメーション）ツールを利用するのが一般的です。 MAツールはSalesforce Marketing CloudやAdobe Marketing Cloud、国内だとSATORIなどがあります。数ある中からMAツールを選ぶ際、コストや使いやすさ、サポートの有無などの判断軸で選ぶと思います。新規でサービスを始める際は問題はありませんが、既存から継続されているサービスにMAツールを導入するには、現状のサイト構成をふまえた上で適切なものを選択する必要があります。どんなにコストが安く使い勝手がよいMAツールでも導入するサービスとの相性が悪ければ、その効果を最大限発揮することはできず、結局売上の最大化には繋がりません。 現状のシステム構成を理解し、分析までを視野に入れてMAツールを導入・利用できる人が重要となってきます。リテンションとエンジニアの関係は、マーケティングとエンジニアリング、２つのスキルを兼ね備えた人が携わることでリテンション・マーケティングの効果を最大限発揮できると思います。 LINEやメールなどを通じてリテンションに繋げていくエンジニアチーム LIFULL HOME'Sでもリテンション・マーケティングは重要な戦略の１つとして捉えており、冒頭で記載してあるとおりリテンションに関わるエンジニアをインタビュー形式で紹介していこうと思います。 Interviewee Profiles キム 　Application Engineer 2020年1月に中途入社、前職では社内向けAPIシステムの開発やインフラ構築など幅広く担当。今はメール配信システムのフルリニューアルに従事。 吉永 　Application Engineer 2020年8月に中途入社、入社後はメール関係のCRM、MAツールの連携、リテンション施策に従事。今後はより連携を強化し、パーソナライズした配信システムの構築を行いたい。 河西 　Application Engineer 2021年4月に中途入社、入社後すぐにコロナ禍で在宅勤務に。これまでLINEを活用したアプリケーション開発やMAツールを使ったメール配信システムの開発に従事。 チームの魅力について教えてください キム ：Webと同じくエンドユーザーに近い所で、色々チャレンジができる環境だと思います。これまではシステムのリニューアルなどを担当することが多かったですが、これからはサービスの改善にチャレンジしていきたいです。 吉永 ：Goをつかったモダンな開発環境で、技術選定から入れたことだと思います。エンジニアでも企画職と同じく、ユーザ目線で企画の上流工程から携わることができ、LIFULLのエンジニア像である「テクノロジーで経営をリードする」を体現できる・発信できるところだと思います。 河西 ：発言・検討したことを実際にチャレンジできるところだと思います。またテクニカルスキルを磨く制度が会社として用意されているところなど、エンジニアの活躍・育成の場が風土として整っているところですね。 エンジニアでも表立ってチャレンジできる風土と制度、そして上流工程から関わっていくことでシステムだけでなくサービスの成長も感じることができるのが、チームの魅力ってかんじでした。 チームが抱えている課題があれば教えてください キム ：最近は新規開発が多く、プロダクト・サービスのメンテナンスが出来ているかどうかが気になりますね。今のシステムをリニューアルした際はパフォーマンス周りの議論もありましたが、最近はリファクタリングにかける時間が無いのも感じました。 吉永 ：開発した機能の効果測定は出来ていますが、１つ１つのPDCAまでは手を伸ばせていないと感じました。既存機能の改修よりも新規機能の開発、現状のリソース内でできることを選んでしまっています。 河西 ：いまは規模が大きな施策が動いているので開発期間が長くなってしまうのが大変ですね。吉永さんと同じ意見ですが、PDCAをまわすようにもっとサービスを育てていくような熱いものがあってもいいかも。 開発の割合が既存の改修よりも新規開発に寄ってしまっていることが課題ですね。逆に言えばリソースさえあれば新規開発は進めつつ、既存のリファクタリングやPDCAをまわす余裕も生まれるということですね。 転職して思ったこと 今回のインタビューした方は1〜2年に以内に入社した人が多かったので、転職した感想を教えてください。 キム ：転職は色々なものにチャレンジする機会だとおもってください。これまでは難しいことが多かったですが、現職だとやりたいことばっかりやれています。 吉永 ：前職ではバグ対応等のリカバリなど、押し付けられてしまう状況が多かったです。LIFULLは社是に「利他主義」を掲げているためか、だれか拾ってくれる、一緒に考えてくれることが多くチームとして動けています。 河西 ：上場企業ということで堅いイメージがありましたが、実際はフランクな風通しでした。挑戦できる文化、支える制度も充実していて、身構えなくてもやりたいことが見つかるといった印象をうけました。 会社としての考え方や風土、制度がエンジニアを成長させるキッカケになっていることがわかりました。 まとめ 今回は「LINEやメールなどを通じてリテンションに繋げていくエンジニアチーム」の紹介をインタビュー形式で書かせてもらいました。 本来であれば仕事の詳細も含めお伝えできればと思いましたが、表に出せる内容が少なく本来の魅力をすべて伝えきれないのが残念です。 ただ、このチームでは　 アプリケーションエンジニア【LIFULL HOME'S（ユーザーコミュニケーション領域）】 　の中途採用を募集しており、より詳しい話を聞く機会がありますのでぜひご一読頂ければと思います。 hrmos.co hrmos.co *1 : 「 1:5の法則／5:25の法則 」Mitsue-Links Co.,Ltd. *2 : 「 リテンションとは？ 」Synergy Marketing, Inc.

フロントエンドエンジニアの嶌田です。2022 年 4 月からアクセシビリティ推進グループ（以下推進グループ）に在籍しています。今回はこの新しくできた部署について簡単に紹介します。また、会社や私がアクセシビリティに取り組む理由を語ってみようと思います。 弊社プロダクトのアクセシビリティを推進する取り組みは、これまでも有志が集まるワーキンググループの形で存在していました。ワーキンググループについては以前に Ltech という社外イベントで紹介しました。今年度からの新設部署はワーキンググループの流れを汲んでおり、推進活動に本腰を入れてコミットしていくために新設された部署です。 参考： Ltech#14 「LIFULL HOME'S」のフロントエンドについて語り尽くします！ 開催レポート - LIFULL Creators Blog 推進グループは上長１名に、ほぼフルタイムでアクセシビリティにコミットするメンバー２名で構成されています。 アクセシビリティ推進グループの取り組み 推進グループのミッションは大きく２つに分かれます。プロダクト改善活動と、啓蒙・教育活動です。 プロダクト改善活動は、いまある LIFULL のプロダクトに手を入れてアクセシビリティ品質を改善していく活動です。現在の LIFULL のプロダクトには、キーボードやスクリーンリーダーで利用しづらい箇所が数多くあります。アクセシビリティを念頭に設計・実装されていなかったためです。そのため、このような問題を検出し、修正していく活動をしています。また、事業部やプロジェクトチームから持ち込まれる相談に乗ったり、デザインや実装のレビューを実施したりしています。 もう一方の啓蒙・教育活動は、プロダクト開発においてアクセシビリティが担保されるしくみを作っていく取り組みです。アクセシビリティの必要性や実践方法をレクチャーしたり、ガイドラインを策定し開発プロセスに組み込むといったことをしています。 このプロダクト改善活動と啓蒙・教育活動はどちらも重要と考えています。プロダクト改善活動に偏っては、新しくアクセシブルでないプロダクトが生み出されていく流れをとめられません。反対に啓蒙活動に偏っては、既存のプロダクトがはらむ問題点を解消しないまま先送りし続けることになってしまいます。 LIFULL とアクセシビリティ 専門部署を作る程度にはアクセシビリティに本気の姿勢をみせている弊社ですが、そもそも LIFULL はなぜアクセシビリティに取り組むのでしょうか？ LIFULL は「あらゆるLIFEを、FULLに。」というメッセージを対外的に発信しています。世界中のあらゆる人々の人生を、安心と喜びで満たそうというメッセージです。「あらゆる」という言葉に込められているのは文字通り、能力や属性によって分け隔てすることのない、すべての人というニュアンスです。くわえて ACTION FOR ALL や LIFULL STORIES など、住宅弱者を支援するサービスや、多様な価値観や暮らしを応援するメディアを運営してします。 このようなサービスを展開する会社として、アクセシビリティに取り組まない理由はありません。 私とアクセシビリティ ここからは私のごく個人的な話になります。筆者は現在、企業でアクセシビリティを牽引していく役割を務めていますが、キャリアはこれまで一貫してウェブのフロントエンドを担当するエンジニアでした。私はいったいどういう経緯でアクセシビリティに興味をもち、何が楽しくて今の業務に携わっているのでしょうか？ アクセシブルな UI との出会い 私のアクセシビリティへの興味は、元をたどってみるとネイティブ UI に対する劣等感が根底にあったように思います。OS やブラウザーが備えている UI がキーボードによる操作性や一貫性・堅牢性を備えていることは肌で感じていました。くわえて、キーボードショートカットを駆使することで、マウスの時よりずっと効率的な作業もできる。一方で、自分が実装するウェブの UI は、見た目だけそれらしく見せたハリボテを作っているような違和感を持っていました。中身が伴っていなくて、ネイティブ UI に対して劣ったものを作っている…と感じていたのです。 ところがウェブにも、堅牢でキーボード操作に対応した UI が存在していることに気付きました。Adobe AIR や Dojo Toolkit、jQuery UI といったプロダクトへのあこがれを通じて、WAI-ARIA というものの存在を知りました。ウェブアプリケーションをアクセシブルにするための仕様です。WAI-ARIA に準拠した実装をすれば、ウェブでもキーボード操作に対応した UI を実装できるのだと知りました。「私が作りたいものの指針はここにあったんだ」と思いました。 いつもよいものを作りたい デザインと実装が別々の価値基準で作られる制作体制にあまり満足していませんでした。「デザインを実装で再現する」とか、逆に「実装都合をデザイナーに飲んでもらう」ような作り方にモヤモヤしていたのです。一見、お互いの価値観をすり合わせをしていて素敵な制作チームだとも思えます。しかし相手が主張してくる内容によっては必ずしも同意できることばかりではなかったりして、最終的に納得のいかないまま渋々ながら一方が折れる…といったことにもなりかねません。 キーボード操作を実装したいという私の思いも、プロジェクトの目的と照らしたら「エンジニアの自己満足」と一蹴されてしまっていたかもしれません。 デザインと実装とは、そういう緊張関係の間に成り立つものではなかったはずです。何かお互いが「これはよい」と思えるものを共有しながらものづくりができればよいのに…と思っていました。 アクセシビリティに向き合い始めてから、アクセシビリティが自分の求めていたものじゃないかと思えるようになりました。アクセシビリティこそが、ウェブサイトを作るためにデザイナーと実装者とで共有できる品質の指針や価値基準になりうるのではないか…と。 アクセシビリティを中心に据えると、私があこがれていたキーボード操作できる UI も大手を振って実装できるようになるし、私の劣等感もぬぐい去られるような気がしました。 ウェブへの恩返し 小学校のころに初めてホームページを作って以来、ゲームのコミュニティサイトの運営などを通じていろいろな人と出会い、貴重な経験もしてきました。「ウェブにおける自分」の人格は自分の中でも今も大きな比重を占めています。多感な時期に私の創作意欲の受け皿になってくれたことも、今ウェブの仕事をして食べていけていることも、感謝してもしきれないくらいの恩がウェブにはあるのです。 自分にはこれしかできないから…というのはまあそうですが、私はウェブに恩返しをしていきたい。では、どういう形で恩返しができるか？ と考えた結果、自分が関われる範囲において、ウェブがウェブらしくあるように貢献していきたいと考えるようになりました。 「ウェブらしさ」とはなんでしょうか？ 十人十色答えは違いそうですが、アクセシビリティこそがウェブらしさなのだと私は考えます。ウェブサイトを作るとき、アクセシブルにしてくれというウェブの声が聞こえてくる気がするのです。 そんなこんながあり、私にアクセシビリティを推進していく気概ができあがってきたようです。 LIFULL はアクセシビリティ「やっていき」 ２年前に入社した時から細々と社内でアクセシビリティを推し進めてきました。ワーキンググループでいくつか実績を積み上げて、100 人以上のエンジニア組織の中に運よく専門部署が立ち上がるまでになりました。 この実績は明らかに私だけのものではありません。私が入社する前にもアクセシビリティを重要視してデザイン・実装をしていたメンバーがいます。旗振り役としての経験の乏しい私の背中を押してくれたメンバーや上長がいます。ほかの会社で同じく推進役をしている先輩諸氏、そのアドバイスや実績、アウトプットにも大いに助けられています。そもそも、LIFULL という会社が社是として「利他主義」を掲げている会社であることも推進しやすさに大きく影響しているのだと思います。 しかも、私たちの活動はまだまだこれからというところです。コミュニティから受け取ったものをしっかりと成果にかえつつ、私もまたコミュニティに還元できるように努めてゆこうとあらためて感じています。 LIFULL はプロダクトのアクセシビリティを重要と考えています。継続的にプロダクトや制作プロセスを改善してまいります。今後も LIFULL のアクセシビリティにご期待ください。 🙂 LIFULL は一緒に働けるクリエイターを募集しています。アクセシビリティへの取り組みが良いね👍と思ったら、求人をぜひご確認ください。 hrmos.co hrmos.co hrmos.co hrmos.co

はじめに エンジニア二年目、寺井です。 先日行われた AWS JumpStart というAWS初学者向けイベントに参加した際のレポート記事になります。 ■ イベント概要 AWS JumpStart はAWS初学者のエンジニアの方々を対象とした、実践的な研修プログラムです 将来的にAWS活用をリードする人材になるための第一歩をスムーズに踏み出せるようなプログラムをご提供します 単なるAWSサービスの学習だけでなく、要件に合わせて適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容となっております 例えば、以下のような方々にもオススメです！ ・AWSの名前は知ってるが使ったことは無い ・EC2等の単体サービスは触ったことあるが、全体のアーキテクティングは経験がない ・クラウドネイティブなアプリケーションを設計する上で重要な観点を知りたい 例によって初心者エンジニア向けな記事となっておりますよろしくお願いします。 この記事が参考になりそうなレベル感 AWS未経験 ~ AWSﾁｮｯﾄﾜｶﾙ なエンジニアのみなさん 後述しますが、AWSを全く触ったことがなかったり、エンジニア関連の技術を何も触ったことがないという方にはかなりキツめなイベントでした。内容についてもレポートをしていきますので、参加してみたいけど今の自分のレベルでは不安...という方もぜひ読んでレベル感を察していただけたらと思います。 全体のスケジュール 完全オンラインでのスケジュールです。画像だと文字が潰れてしまっているかもしれませんが、朝9時から夕方6時までぎっしりと詰まった内容ということが伝わると幸いです。 朝9時集合はキツかったです。 1日目前半 ~グループワークではじめまして~ まずは全体説明とウォーミングアップを兼ねたチャットでの自己紹介がありました。内容を見ていると職種はけっこう様々なエンジニア職が集まっていて、年齢層は幅広め、ただAWSサービスを利用した経験があまりないと言った人が多かったです。社会人向けのイベントでしたが、インターンをしている学生さんもいました。参加者は全体で80名程度、サポートをしてくれるAWSの方が3名でした。 その後は簡単なAWSサービスの紹介LTがありましたが、事前学習用動画として一時間程度の入門動画を観るよう指示があったので、その内容の復習になります。 そして二日間の日程を通じて行われるアーキテクチャ設計のお題を出されました。お題はこちら、 グループワークお題 こんな要件を満たすサービスのアーキテクチャ設計をしてくれというお題ですね。納期は翌日です。ちなみにこのお題を出される際にちょっとしたシナリオも一緒に用意されていたのですが、要約すると「ブラック企業に就職してしまった新人エンジニアの俺たちが、入社二日で会社の命運を握るサービスのアーキテクチャ設計を任された件」って感じです。気になった方はぜひ参加してみてください。 その後、各チームに分かれてグループワークが始まりました。 私と一緒のチームになったのは全員同じくらいのエンジニアレベルで、バックボーンは様々だったのですが全員がエンジニア歴1〜2年のグループでした（他のチームもいくつか見ましたがレベル感としてはほとんどの人が同じくらいだと思います。たまに初心者か...？って感じの強そうな人がいたような気もしますが）。 お互いはじめましてでしたが、全員が同じくらいの初学者ということもあり特に緊張することもなくグループワークに入っていくことができました。 さて、今回のように初心者エンジニアが集まると「誰も正解がわからない」、「何をどうしたらいいのかが全くわからない」という状況になりがちです。 そんな時でも安心なのが、グループワーク全体日程を通じて三回、オフィスアワーというAWSの人に直接相談できる機会が設けられていたことです。 初回の相談時はどうしたらいいのかが全くわからず、設計図もそれっぽいものを並べただけという悲惨な状況でしたが、「この要件を満たすためには例えばこういった機能が必要そうで、これを調べてみるといいかも」といったアドバイスをいただくことができ、無事に軌道に乗るところまで持っていくことができました。 少しでも知見のある分野ではそれぞれが積極的に意見を出すといったチームワークも発揮しつつ、それっぽい設計図ができてきたところで初日のグループワークの時間が終了。作業時間は三時間ほどあったはずですが、一瞬で過ぎ去っていった印象です。 普段の業務もこれくらいの速さで時間過ぎればいいのに。 1日目後半 ~スケーラブルなWebアプリを作るハンズオン~ 1日目後半はグループワークを中断して、実際にAWSサービスを使ったハンズオンを行いました。 内容としては、「複数のアベイラビリティーゾーンを作成、それぞれのパブリックサブネットにECSとFargateタスクを設定してELBを接続、最後にそれぞれのプライベートサブネットにRDSをリーダーとプルレプリカ1台ずつ起動」というものです。図にすると以下のような設計になります。 ハンズオン完成図 ここまで書いてある意味がよくわからないといった方には中々やりごたえのある内容だったのではないでしょうか。とはいえ丁寧な解説手順書があり、わからない人向けに個別フォローまでやってくれるので迷子になってしまうといったこともなく安心です。 一方で、ここまで書いてある意味がそれなりにわかる方には正直あまり効果の無い内容だと感じました。リソースの作成や設定まで全て手順書に細かく書いてあるので自分で特に設計等を考える必要もなく、あーこの設定ね、とポチポチするだけで完成してしまいます。また、基本的にそれ以上突っ込んだ内容は取り扱わず、AWSの方々も途中の設定で詰まってしまった方のフォローにずっと回っていたので、早く終わってしまった人は各々好きなことをしていてください状態でした。その間に設計の課題を考えることができたのでありがたかったのですが、私にとってはこのハンズオンではあまり得られるものがなかったかなと感じます（理屈はわかっていても実際に自分の手で一から作成した経験は無かったので学びになったといえばそうかもしれませんが）。 という内容を最後のアンケートで書いたのでもしかしたらこの後の回では内容が変わっているかもしれません。 2日目 ~グループワーク追い込み編~ たった二日間の日程ですが、納期が目前に迫っている（という設定）ので朝からグループワークの続きです。 着々と要件を満たした設計を実装しつつ、オフィスアワーの質問も活用して一通り設計が完成してきました。 初日はボロボロだった設計もこの段階になるとさらなるブラッシュアップのために機能を追加するといったフェーズになってきます。 そんなこんなで出来上がった最終的な成果物はこちら。 アーキテクチャ設計完成図 オ ー ル サ ー バ レ ス にしました。やはりサーバレス...サーバレスは全てを解決する...！ちなみに発表会では全部サーバレスだと...！？みたいな感じでちょっとざわついていました。 ※この設計図で全要件が担保されているのかと、そもそもこの構成で動くWebサービスができるのかは未検証です。もし何か不備に気付いてしまったベテランのみなさまは寛大な心でスルーしてください。 この構成に仕上げるまでの流れとしては、 チャット機能でリアルタイム性を実現するためにWebSocketをAPI Gatewayで実装 API Gatewayの後ろにつける実行部分としてはメンバーが使用経験があって、かつスケーリングできてAZ等の設定も考える必要のないLambdaで実装 それに合わせてDynamoDBにデータ保存 + OpenSearchを使った検索機能 その他仕様に合わせて調整 といった段階を踏みました。 発表会では質疑応答の時間があり、その後講評をいただきました。それぞれの主な内容としては、 質問： サーバレスに振り切ったモチベーションとしてはどういったものがあったのか。 -> 上述の構成に仕上げるまでの流れの内容をそのまま回答。 想定されるアクセス流量はこの設計で耐えられるのか。 -> 我々の見立てではLambdaのスケーリング機能でなんとかなる想定。同時実行数に関しても上限緩和申請をして対応すればなんとかなりそうという見込み。 講評： 今回のようなサーバレスの多い設計だと短期間での実装には非常に適しているが、Managedなサービス部分が増えるほど自由にカスタマイズできる部分が少なくなっていくのでそういった部分まで考えられると良いかも。 Lambdaの実装部分に関してはもう少し考慮の余地があって、例えばアクセスに耐えられるかの部分は平均だけではなくピーク時の流量を想定して耐えられる設計なのか、関数の実行時間がどれくらいかかりそうなのかまで考えられるとより適した設計が見えてくるかもしれない。 討論を重ねてグループ内ではそれなりに納得のいく形に仕上げたつもりでしたが、深い部分まで考えを巡らせることが十分にできなかったなと感じました。 また、仕様書を表面的になぞっただけの設計にとどまらず、実際に運用した際に生じてくる問題部分まで考えを及ばせる必要があることに改めて気づかされました。 企業がプロダクトとして出すものとしてはかなりお粗末なものになってしまったと痛感しましたが、実際の業務でやらかしてしまう前に経験を積むことができたのは大きな収穫だったと思います。 おまけ ~別チームの設計~ 発表会では4チームごとに分かれて発表を行ったのですが、チームによって設計方法から粒度までかなり異なっていたのが面白かったです。例を挙げるとキリがないので少しだけ紹介すると、 チャット部分のリアルタイム性はAWS AppSyncで実装 処理部分をECS+ASGの設定で実装（ハンズオンでやった内容を応用） セキュリティ部分に注力して認証やIAM設定をガチガチに設定していたチーム 実運用まで想定したリソース選択まで踏み込めていたチーム などが見られました。 所感 二日間フルタイムの日程だったのですが、終わってみるとあっという間のプログラムでした。グループワークの時間だけでも合計で7〜8時間程度はあったのですが全然話し足りないという感想でした。 また、グループ全員がほとんど同じレベルだったのがかなり良かったと感じます。誰かに任せてやってもらえばいいやではなく、自分が全力で参加しないと完成しないという気持ちになりましたし、他のメンバーも同じような思いで参加していたのではないでしょうか。結果としては全員が何かしらの部分で活躍できる機会があったように思います。 また、発表会を通じて自分たちの設計したアーキテクチャへのFBをいただけたことと、別グループの設計の発表も聞くことができたこと、最後にはAWSの方から実装例の共有もあったりと、短い時間で非常に多くの学びがありました。 おわりに ある程度AWSを触ったことがあるといった人が実務に近い設計の経験を積むといった文脈では非常に有意義なイベントだと感じました。今後の業務で学んだことを活かしていきたいですね。 一方で、全くAWS触ったことないという人にとってはグループワークの話し合いに着いていくのがかなり大変だったと思いますし、吸収できる学び量もけっこう変わりそうな気がします。とはいえ、最低限の講義パートやハンズオンもあったので、少しでもサービスを触ったことがあるなら十分食らいついていけるのではないでしょうか。 今年度は全部で4回同一内容のイベントが開催されるので、本記事を最後まで読んでいただいたみなさんも参加してみてはいかがでしょうか。 最後になりますが、LIFULLでは一緒に働いていただける仲間を募集しています。今回希望してイベント参加をしたように、エンジニアが成長できる機会が盛り沢山の職場です。カジュアル面談もやっていますので、よろしければこちらもご覧ください。 hrmos.co hrmos.co

こんにちは、 LIFULLプロダクトエンジニアリング部の趙(ﾁｮｳ)です。 苗字からわかると思うんですが、国籍は中国です。 中国で大学卒業して一人で日本に来てから3年間になりました。 せっかくの機会なので、外国人が日本に来たこの三年間の生活とお仕事について話したいと思います！ 日本とLIFULLに来るきっかけ 私の大学は中国の大連理工大学で、大連には日本の企業は多いので、日本語専門及び日本語強化の専門が提供する大学が多いです。自分の専門も「ソフトウェア(日本語強化)」です。 日本語強化というのは、専門のソフトウェア以外の英語をやめて、代わりに日本語の授業を受けることです。専門のおかげで卒業してからある程度の日本語を話せます。 そもそも日本語できるから海外に生活するわけではないですが、ある機会でネオキャリアが中国に来て面接会を開催しました。十数社の会社が参加しまして、LIFULLはその一員です。 私は友人から誘われたので、就職会の参加を決め、各会社を回っていって、LIFULLのホームページのデザインが一番良くて(私はフロントエンドに興味ある)、利他主義の経営理念も気に入って、LIFULLの面接を申請しました。日本語で面接受けるのは初めてなので、すごく緊張しました！ そして面接で話もはずみ、LIFULLに入社することができました！ LIFULLのお仕事 入社 入社したばかりの時は使う環境と言語は大学時代に学んだこととは大きく差があり、環境構築や最初のタスクをこなすだけでも大変でした。ありがたくてメンターさんが優しく教えてくれてすぐ慣れてきました。 一年目で物件情報管理のシステムと追客システムを担当させていただき、すごく勉強になった一年でした。 色々触れること 二年目からは組織変更でLIFULL HOME'Sの開発を担当させていただきました！ やったことは主に不動産検索サービスの設計と開発です！ 他には接客力ランキングページの作成とか↓ LIFULLタグの開発にも参加させていただきました！ そして三年目からまた新しい組織に配属されていてB向け領域に行きました！ メインの担当はWEBの設計、開発とメンテナンスです。 その他に、グループで担当しているシステムがKEEL環境で稼働しているので、KEEL環境に関しての調整、メンテ、新しい環境作り、デプロイとかの業務もやらせていただきました！ www.lifull.blog KEELに関しての業務によってKEELチームと基盤チームのメンバーと相談する機会が一気に増えてきました、他部署のみんなの魅力も感じました。 コロナ時代 入社2年目からコロナが流行して、2020年3月の頭から在宅勤務になっていて、業務の進み方は大きく変わりました。 まず在宅になったことで通勤時間がなくなりました。そして家に仕事するなら部屋の明るさと温度調節自由でもっと安心と集中できる環境を作れるようになりました。 最初リモートワークでコミュニケーション不足になると思いましたが、Zoom、oViceとかのサービスを使ってオンライン飲み会とキックオフをやるのも意外と盛り上がれる！MTGとかも会議室予約しなくてもやれるし、コミュニケーションにも特に影響を感じませんでした。 一人で海外に暮らす体験 言語 日本に来る外国人は、日本語学校を申請して日本に来てから日本語を学ぶのが多いですが、私はちょっと違って中国で日本語を学んでから直接に就職するので、まだ慣れてない状態で職場に行く最初は大変でしたQAQ。毎回他メンバーと話す時はすごく集中して、話す前は必ずノートで話したいのを書いて準備してきました。MTG中みんなの話を追いつかない場合もありました。でも部署の皆さんは私と話すときは意識的にゆっくり話してくれたり簡単な単語を使ったりをしてくれてるのはすごくありがたいでした。 みんなのおかげで日本語の職場をだんだん慣れてきました。 住所 日本に来たときはしばらく日本に働いてる友達の家に住んで、仕事しながら部屋探しをしました。小さい１Kでしたが、私の日本の初めての住むところでした、退社して帰宅後毎回愈されます！ 二年間住ませて、その後コロナになっていて、快適な環境で仕事をしたほうが良いと思い家を購入しました。 ちなみに家探しはもちろんLIFULL HOME'Sで！ 興味 日本のアニメと漫画は世界中にも有名で、私も子供時代からジブリとか、ナルトとコナンを見ながら育てられてます。日本に来てからももちろん、漫画、アニメとゲームを楽しんでます！ 最近PS5を購入もできました！ まとめ 素晴らしい三年間でした。 自分がやりたいならすぐやる人間なので（迷えば、敗れる！）日本に来ても、LIFULLに来ても、家を買うとかでも、数日間だけで決まったんです。それが良いのか悪いのか人によってですが、自分がこういう未知×チャレンジだらけの生活が好きです！ 一人で海外で暮らすのは確か勇気が必要ですが、一歩踏み出したら、きっと今まで見たことない風景が見えます！ 新しい世界に踏み出す自分とそのチャンスをくれるLIFULLに感謝します。 hrmos.co hrmos.co

こんにちは、プロダクトエンジニアリング部の鈴木です。 私達のチームでは、 リファクタDays の取り組みとして、APIサーバのテストコード（RSpec）のリファクタリングを行いました。 このリファクタリングにより、テストコードの記述量が大幅に削減され、数年間利用してきたAPIコントローラのテストコードを作業時間にして2週間程度で移行できました。 この記事では、どのようにしてチームでRSpecを改善したのか全体像をお伝えします。 APIサーバが抱えるテスト実装の課題 主な改善内容 ディレクトリ構成を整備・統一する テストの雛形を自動生成する モック・スタブ化をVCRで自動化する テストコードの期待値も自動で作る テストコードから実装の振る舞い以外を追い出す チームでの改善の進め方 まとめ APIサーバが抱えるテスト実装の課題 私達のチームが管理しているサービスでは、バックエンド（APIサーバ）が、RubyのSinatraフレームワークによるBackends For Frontend（BFF）構成となっています。 コントローラのテストは、RSpecで記述しており、APIサーバへの問い合わせ結果を検証しています。 APIサーバでは外部APIへの問い合わせが多く行われており、テストコードでは外部APIには問い合わせないよう、ダミーデータを返すためのモック・スタブ化が多く行われています。 そのため、図のようにサービスの機能追加・改修の度に、モック・スタブ化を行っていました。 これにより、テストコードの実装工数・コード量・管理の負担が増加し、サービス実装の足枷となりつつありました。 また、テストコード全体の構成にも明確なルールはなく、伝統的に書かれている構成を参考に実装している状態には、チームとして課題感を抱えていました。 負債解消前のテスト基盤 主な改善内容 まず、初めに刷新後のAPIコントローラのテスト作成方法を図示します。 刷新後のテストコードの作成は、ツールからテストコードの雛形を生成し、リクエストパラメータやテストコードを追記して作成します。 また、モック・スタブ化や期待値の作成は初回時に自動的に行われるため、実装者は生成された内容が正しいか確認するだけで良いようになっています。 負債解消後のテスト基盤 この仕組みに変更するためどのような対応をしたのか、各章で詳しく解説いたします。 ディレクトリ構成を整備・統一する テスト関連のディレクトリ構成は、実装コードと同じディレクトリ構成になるように変更することで、実装との対応関係を明確にしました。 先に、大まかな実装（src/配下）とテスト関連（spec/配下）のディレクトリ構成のイメージを記します。 ここでは、例として src/app/resource/mansion.rb という、APIのコントローラを対象としたテストのディレクトリ構成を記載しました。 . ├── spec #テスト関連 │ ├── app #テストコード │ │ └── resource │ │ └── mansion │ │ ├── helper.rb #テスト準備コード │ │ └── mansion_spec.rb #テストコード │ ├── fixture #期待値ディレクトリ │ │ └── app │ │ └── resource │ │ └── mansion │ │ └── result.json #mansion_spec.rbで利用する期待値 │ ├── helper #共通テスト準備コード │ ├── tools #テスト作成自動化用のツール群 │ └── vcr_cassettes #モック/スタブ情報（VCRカセット） └── src #実装 └── app └── resource └── mansion.rb spec/app配下にあるテストコードと、fixture/配下のテストコードの期待値ファイルは、実装側のsrc/以降のファイル名までをディレクトリ構造として配置するようにしています。 単純な話のようですが、今まではルールが明確でないなど、独自の共通化により異なるディレクトリ構造が生まれているなど全体像が把握しにくい状態でした。 全体のディレクトリ構成を整備・統一を初めに行うことで、新規実装者でも全体像を把握しやすく、後述の自動化も行いやすくなります。 テストの雛形を自動生成する テストコードを書くために共通で必要なファイルやコードは、自動生成することで実装者が楽をできるように仕組み化しています。 テストコード雛形作成のツールでは、テスト対象のAPIのエンドポイント（/mansion get）を指定して実行すると、適切なディレクトリにspecの雛形ファイルが配置されるようになっています。 雛形作成コマンドの実行例 ruby spec/tools/make_templates.rb /mansion get コマンドによって作成されたテストコードの雛形イメージ #./spec/app/resource/mansion/mansion_spec.rb # frozen_string_literal: true require_relative 'helper' describe Resource::Mansion do let(:params) { {} } # 必要に応じてリクエストパラメータの定義 # リクエストパラメータのバリデーションテストコード describe '#valid?' do it_behaves_like 'valid?', %i[] end # getリクエストのテストコード describe '#get', :vcr do let(:endpoint) { '/mansion' } let(:result_file) { 'mansion.json' } include_context 'expected_result' end end その他も、テストコードの作成に注力できるよう、ファイルの読み込みなどを極力自動化しています。 モック・スタブ化をVCRで自動化する 外部APIのモック・スタブ化には、 VCR を利用することで、モック・スタブ化を自動化しました。 今まで、外部APIに問い合わせる箇所は、テスト実行時には問い合わせないようモックを作成し、ダミーデータを返すスタブを記述していました。 モック・スタブ化にはRSpec標準の RSpec Mocks を用いてきました。 しかし、この方法は下記のような問題が発生しており、実装の負担になっていました。 外部APIのリクエストパターン分だけ、モック・スタブ化用のコード（ allow().to receive().and_return() ）を記述する必要がある モックを共通化するために、テストコードに shared_context()/include_context() が頻出する 外部APIへの問い合わせ結果の代わりとなる、スタブデータを作成する必要がある スタブデータが実際の問い合わせ結果と異なり、テストの問い合わせ結果と実際のAPIの結果が乖離する これらの問題の解決策として、VCRを用いました。 VCRは、Net::HTTPやFaradayといった様々なHTTPライブラリを、外部APIへの問い合わせが発生したタイミングで自動的に WebMock 等にモックします。 更に、問い合わせ結果をファイル（vcr_cassettes/配下）に初回のみ自動的に書き出ます。これをVCRではカセットと呼び、スタブデータとして自動的に利用します。 1度VCRの設定をしてしまえば、テストコードへの記述は、外部APIに問い合わせるコードが含まれるテストコードの context/it ブロックに :vcr を記述するだけで機能します。 describe '#get', :vcr do # このブロック中の外部API問い合わせを自動でモック・スタブ化 end この仕組みにより、下記のメリットが得られました。 モックコード・スタブデータを記述する必要がなくなる モック・スタブの記述がテストケースから無くなり、テストコードが読みやすくなる モック記述漏れにより、外部APIに問い合わせてしまうことがなくなる スタブデータが、実際の問い合わせ結果と同じなため、決定論理的なテストを行える 一方、ファイルを自動生成する都合で、describe/context/itにマルチバイト（日本語）を使いにくくなることが課題としてあがりました。 デフォルト設定のVCRは、 describe/context/it の命名で、スタブデータのディレクトリとファイルを作成します。 それにより、命名に日本語が入っているとディレクトリ・ファイル名の日本語がエンコードされ、CLIやGit操作うまくできなくなりました。 解決方法は、下記が考えられます。 CLIやGitを、マルチバイトでも問題ないように設定する VCRの設定でスタブデータのディレクトリを明示的に指定する describe/context/it を半角英数で記述しする 私達は、汎用性のため describe/context/it を半角英数で記述しすることを選択しました。 それ以外の殆どの課題は、VCR側の設定をカスタマイズすることで吸収できました。VRCは汎用性の高いライブラリだと思います。 テストコードの期待値も自動で作る テストコードの期待値も、初回テスト実行時にAPIのリクエスト結果から自動的に作成されるようにしています。 テストコードの期待値は include_context 'expected_result' の内部で下記のように、初回テスト実行時のみ作成と検証をしています。 fixtureディレクトリ配下に、テストコード用の期待値が存在するか確認する 存在しない場合、テストでのAPI問い合わせ結果を、期待値としてfixtureディレクトリ配下に書き込む 存在する場合、期待値ファイルを読み込み、作成は行わない テストを実行し、期待値とテスト実行結果を検証する 気をつける点として、初回テスト実行時はテスト結果と期待値が同じになるため、APIへの問い合わせ結果はどうであれテストを通過してしまう点です。 これについては、異常な期待値が生成されないよう、APIへの問い合わせ結果に問題があるときは警告を表示するよう対策をしています。 また、期待値が正しい値になっていることは、実装時とレビュー時に確認するようフロー化しました。 テストコードから実装の振る舞い以外を追い出す 最後にテストコードの見通しを良くするために行った対応として、テストコードにはテストコードのパターンごとに、実装の振る舞いに影響する受け取る値（引数）と返す値（期待値）のみを定義するようにしました。 これにより、テストコードから誰が見ても実装の挙動がわかりやすくなるようにしています。 具体的には、実装の振る舞いには関係の無い、テストを実行するのに必要なコード（準備コード）をhelperファイルに切り出しました。 helperファイルに移されるコードの例としては before や after ブロックで行うような、日時の固定や外部API以外（AWSリソース等）モック・スタブ化などの処理です。 準備コードを切り出すためのhelperファイルは2種類の配置方法を用意しました。 各テストコードでしか必要のないhelperのコード：各specファイルと同列のhelper.rbに配置。 日時の固定など、複数のテストコードでも利用するような共通のhelperコード：spec/helper/配下から共通で呼び出されるように配置。 日時固定の共通helper # ./spec/helper/contexts/time.rb # VCRカセットの生成時間で日時を固定する共通準備コード shared_context 'freeze_time' do before do travel_to(VCR.current_cassette&.originally_recorded_at || Time.now) end end 共通helper呼び出し用 # ./spec/helper/spec_helper.rb require './spec/helper/contexts/time' # 共通で読み込む準備コードを定義 def basic include_context 'freeze_time' end 個別helper（S3のモック・スタブ化） # mansion/helper.rb require './spec/helper/spec_helper' # mansion/mansion_spec.rbの実行に必要な、S3バケットのモック・スタブ化 shared_context 'stub_aws_s3' do let(:s3_resources_params) { { region: 'ap-northeast-1' } } let(:s3_resources) { instance_double('s3_resources') } let(:s3_client) { instance_double('s3_client') } before do allow(Aws::S3::Resource).to receive(:new).with(s3_resources_params).and_return(s3_resources) allow(s3_resources).to receive(:client).and_return(s3_client) end end テストケースのコード # mansion/mansion_spec.rb require_relative 'helper' describe Resource::Mansion do basic # 共通準備コードの読み込み describe '#get', :vcr do include_context 'stub_aws_s3' # 個別で必要な準備コードの読み込み let(:params) { { mansion_id: 123 } } let(:endpoint) { '/mansion' } let(:result_file) { 'result.json' } include_context 'expected_result' end end これにより、テストコードからは実装の振る舞いがわかりやすくなり、コードの見通しを良くしています。 これらの対応の結果として、大幅に自動化とテストコードの棲み分けがされたため、実装者が考慮しなければならない点が下記に集約されました。 テストコードごとのリクエストパラメータの記述 外部API以外のモック・スタブ化 期待値が想定される値になっているかの確認 テストコードも、8万行程度あったものが約4千行にまとめられ、20分の1となり大幅に改善できました。 チームでの改善の進め方 改善に向けては、 リファクタDays の時間の時間を使ってチームで進めてきました。 リファクタDaysとは、部署全体で進めている、技術的負債の解消とそれによる価値創造の加速を目的とした取り組みです。 我々のチームでは、月に1日業務とは別にリファクタDays時間を確保し、チームで管理しているサービスの技術的負債の解消をしております。 今回のRSpecリファクタリングは、下記のような流れで進めました。 サービスの課題をブレインストーミング形式で洗い出す テストコードの課題点をブレインストーミング形式で洗い出す テストコードの改善方針を定める チーム全員でリファクタリングを行いながら、改善の障壁を洗い出す チームで障壁について解決案を議論・解消 4から5を繰り返す テストコードの課題洗い出しブレストシート 初めから、RSpecの改修を目的にしていたわけではなく、チームでサービス全体からボトルネックを洗い出すところから始めました。 RSpecの改善が決まってからは負債解消をするにはどうするのがよいか、リファクタリングを実施しながら改善の検証を繰り返しました。 その結果として、チーム全員が納得できる改善結果にできました。 まとめ テストコードは、実装の保守・運用に必要なものですが、テストコードの記述に時間がかかると、実装工数増加に繋がり価値創造の妨げになりかねません。 今回は、テストコード作成の自動化と適切なファイルの棲み分けを行うことで、 次の価値創造の高速化に繋げました。 LIFULLでは、なかなか手を付け辛い技術的負債の解消も、チームのKPIとして掲げることで、精力的に取り組んでおります。 気になった方は求人情報も御覧ください。 hrmos.co hrmos.co

はじめに こんにちは！LIFULLのプロダクトエンジニアリング部でフロントエンドエンジニアを担当している竹本です。 今回はチームで初導入した「デザインスプリント」について どのような手法で導入したか 導入して感じた利点と現状の課題 を共有します。 デザインスプリントとは デザインスプリントはサービスの開発を効率よく進めるために各ステップごとにチームメンバーで議論してプロトタイプを作り、高速で価値を検証するプログラムです。 各ステップでは、リサーチ、プロトタイピング、ユーザーテストに則ったプログラムで構成しています。 これを何度も繰り返し研磨することでサービスの理想形を探究し続けるといった点が今回の目標になります。 チームでどのように実施したか まず今回の基本構成としましては、以下のようなプログラムに分けて実施しました。 DAY1 理解...競合調査やデータ分析による課題定義 DAY2 発散...課題を元に解決するHMW(How Might We)を作成する DAY3 決定...書き出したアイデアからプロトタイプを作成するアイデアを選出する DAY4 プロトタイプ...アイデアをベースにプロトタイプを作成する DAY5 検証...プロトタイプをユーザーがどのように使うのかを観察して仮説検証を行う 上記のプログラムを１つずつ簡単に説明していきたいと思います。 DAY1 理解のプログラム このプログラムでは、ユーザーのプロセスを徹底的かつ具体的に追いかけます。 今回はユーザー調査とKA法を用いて人々が求めている本質的ニーズや体験価値を導き出すこととしました。 ユーザー調査 ターゲットにとっての本質的な価値とは何かを探るためにユーザー調査を行います。 今回は、「住まい選びを始める段階の人が、どのように情報に触れて、どのように住まい選びを始めているのか」という題材の元、 デプスインタビューを実施しました。 大まかに分けてユーザー調査前に整理したリサーチ要件は以下になります。 背景 調査が必要な経緯、現在のステータスなど 目的 調査で知りたいこと ゴール どのような結果・状態が達成されていればインタビューは成功か 明確にすること どのようなことを知ることができたら、ゴールを達成できるか こうしたリサーチ要件を元にユーザー調査を行い、得られた結果を元に、KA法を用いて分析していきます。 KA法 KA法を用いたステップとしては以下になります。 「出来事」を読んでなるべく具体的にそのシーンをイメージとして思い浮かべる そのシーンに自分を置いてみて、行動したときの自分の心の動きを感じとる 自分の心の動きを投影して、ユーザーの価値観だったらどうなるか類推する 類推した心の動きから、「出来事」に含まれる価値を捉えて「心の声」として表現する 「出来事」と「心の声」を踏まえて、「〜する価値」というフォーマットにする KA法を用いてできる「出来事」「心の声」「〜する価値」の例 DAY1では様々な価値を発散し、グループ化した上でその価値を提供する既存製品・技術を書き込むまでを行いました。 ここで完成したものは「価値」を整理した価値マップと既存製品、技術マップになります。 DAY2 発散のプログラム このプログラムでは、以下の順序でHMW(How Might We)を作成し、その中から重要なHMWを抽出することがゴールとなります。 DAY1で完成した「価値マップ」を利用し、HMWをチーム内でできる限り作成する HMWの付箋をグループ化する 各メンバーが重要だと思うHMWに投票して、課題をまとめる。 HMW(How Might We)とは、「どうすれば~」から始まる簡潔な言葉で付箋を書いていく手法の１つです。 これにより付箋に書かれるフォーマットの統一と、課題について焦点を当て易くできます。 HMWの例 各メンバーが出したHMWをグループ化した上で重要だと思うHMWを投票により数個選んでDAY2のプログラムは完了となります。 DAY3 決定のプログラム このプログラムではDAY2で選出したHMWを元にアイデアの発散と抽出を行うことがゴールとなります。 課題ごとにアイデアを発散する アイデアを整理し、グループ化する 良いと思ったアイデアにメンバーが投票する どのアイデアをプロトタイピングするか決定する アイデア発散の例（黄色がHMW,オレンジがアイデア） アイデアの整理、グループ化が終わり次第、プロトタイプ作成を行うアイデアを数個選んでDAY3のプログラムは完了となります。 DAY4 プロトタイプのプログラム このプログラムでは採用したアイデアからチーム分けを行い、プロトタイプ作成のために作業時間を取りました。 プロトタイピング手法は最終的にテストできる形であれば良いのでチームごとで最も得意な形式で作成して頂きます。 プロトタイプを完成させた段階でDAY4のプログラムは完了となります。 DAY5 検証のプログラム このプログラムでは各プロトタイプのテストと検証を行いました。 実際にプロトタイプを使っていただくために、今回テスターは社員を協力してもらいました。 各テストが終わり次第、出た意見を元に考察し、反映する内容・次のアクションを決めました。 導入して感じた利点と現状の課題 それでは、デザインスプリントの各プログラムを回して感じた利点や課題について共有します。 利点について 統一された認識の元でのアイデア創出 短い間でプログラムを実施したため、DAY1で固めた認識が定着しプロトタイプを作成するまでに大きくずれることはありませんでした。 メンバーごとで分かれて作業した後もチームとして一体感を持ち、プロトタイプを作り上げられたと感じています。 短時間で密なプログラムによる効率的なコミュニケーション 短い間に長時間チームメンバーとコミュニケーションを取る仕組み上、メンバーの相互理解も並行して進んだように感じました。 これにより、デザインスプリント外でも職種間のやり取りがよりスムーズになりました。 課題について デザインスプリントのスピード感 本来5日間通して行うプログラムですが、今回はデザインスプリントをやりつつ並行して通常施策の作業を進めていたため、プログラムの間は1週間ほど空いてしまったケースもありました。 故にデザインスプリントで重要な要素の１つであるスピード感は意識し切れていなかった可能性があります。 プログラムごとに時間を空いてしまう場合は、前回のプログラムでは何を行ったかログを残しておき、次のプログラムでもすぐ考えられるように準備をしておくとスムーズに思考しつつプログラムを進めることができると感じました。 どんなサービスについてデザインスプリントを実施したか 今回、デザインスプリントを活用したサービスは住まいインデックスというサービスになります。 住まいインデックスは住み替えの予算、ユーザーにあった地域などのような住まい探しにおける悩みを解消するサービスです。 lifullhomes-index.jp まとめ デザインスプリントの初導入した手法と感じた利点、課題などを紹介しました。このように初導入でも挑戦できる環境は整っています。 今後デザインスプリントを導入検討している方々の参考になれば幸いです。 最後になりますが、LIFULL では一緒に働く仲間を募集しています。よろしければこちらも合わせてご覧ください。 hrmos.co hrmos.co

こんにちは！テクノロジー本部事業基盤ユニット改善推進グループ所属の王です。 現在はLIFULL HOME'Sの各種サービスが参照するデータベースをOracleからPostgreSQLに置き換えるDB移行プロジェクトの業務を担当しています。 今回のブログのテーマは、DB移行プロジェクト内の課題を解決するため、PostgreSQLデータベースの拡張機能oracle_fdwの使用検証および検証中の気付きです。 DB移行プロジェクトの詳細については、こちらのブログを参考にしていただけるとうれしいです。 www.lifull.blog www.lifull.blog www.lifull.blog DB移行プロジェクトの課題 oracle_fdwを使用検証するきっかけとしてはDB移行プロジェクトにある課題の解決です。 課題について説明します。 DB移行作業におけるテーブルの依存関係 DB移行プロジェクトで移行する予定のさまざまなSQLの中には、一つのSQLで複数のテーブルにデータ参照している場合があります。例としては複数テーブルの結合があるSELECT文、テーブルの参照結果を別テーブルにINSERTするなどです。 これらのSQLによって、DB移行作業におけるテーブル間の依存関係が発生しています。たとえば、テーブルAとテーブルBが同じSQLに使われる場合、テーブルAへのDB参照を完全に移行するため、テーブルBへのDB参照を変更する必要があります。 複雑なテーブル依存関係が課題 複雑なテーブル依存関係はDB移行作業に支障を与えて移行プロジェクトの課題となっています。 今回DB移行プロジェクトにさまざまな複雑なSQL文を移行する必要があります。SQLに使われるテーブルは数多くあり、DB移行におけるテーブルの依存関係は非常に複雑となっています。 移行する予定テーブルの中で、仮に一つのテーブルのDB参照が移行先に変更することが難しい場合、依存関係を持つほかのテーブルにも影響してしまい移行できなくなります。 上記の状況は実際にプロジェクト内で発生しています。複雑なテーブルの依存関係によって、部分的な移行進捗の遅れはプロジェクト全体の進捗に大きく影響する可能性があるため、現在プロジェクトの一つの課題となっています。 oracle_fdw 上記テーブルの依存関係による影響を減少させるために、oracle_fdwというPostgreSQLの拡張機能を導入することを検討しています。 oracle_fdwとは？ oracle_fdwはPostgreSQLの拡張機能の一つです。 FDWとは、外部データラッパー(Foreign Data Wrapper)の略称です。Postgresにはさまざまな外部データラッパがあり、Postgres以外のデータソースをアクセスする仕組みです。oracle_fdwはその中の一つです。 Oracle上のテーブルやビューをPostgreSQLの外部テーブルにマッピングすることにより、PostgreSQLからOracleデータベースにアクセスして、データを取得することが可能となります。 oracle_fdwに関する詳しい説明は以下の資料が参考になると思います。 外部データとの連携 ～FDWで様々なデータソースとつなぐ～ Oracleデータベースにアクセスする ～oracle_fdwの基本的な使い方～ また、oracle_fdwはOSSとしてGitHubに公開されています。関連情報も以下から取得できると思います。 laurenz/oracle_fdw なぜ課題の解決に役立つ？ oracle_fdwを使用することで一つのSELECTで複数のテーブルをJOINしている場合でも、異なるDBインスタンスにあるテーブルどうしをJOINしてデータを取得できます。 この特性を活かすことによってSQLを移行する時に、SQLに使われるテーブルを全部移行先のPostgreSQLにデータ参照変更が必要という制限はなくなります。 移行する予定テーブルの中で、仮に一つのテーブルのDB参照が移行先に変更することが難しい場合、依存関係を持つほかのテーブルにも影響してしまい移行できなくなります。 すなわち、上記のようにしばらく移行が難しいテーブルが存在する場合でもそのテーブルの参照だけOracleのままにしてほかの依存テーブルはPostgreSQLに参照することとなります。 検証作業での気付き oracle_fdwはまだ現段階使用の検証しており、実際にプロジェクト内で使用するのが始まっていないですが、検証作業をしてみていくつか気付きがあったので共有します。 PostgreSQLにインストール oracle_fdwのインストールは以下のページの記載を参照することがお勧めです。 インストールガイド 注意点は下記となります。 oracle_fdwの使用にはPostgreSQLのバージョンが9.3以上を要求しています。AWS RDSの場合、PostgreSQL 12.7、13.3、14およびその以降のバージョンしか導入できない制限があります。バージョン関連の情報は Amazon RDS でサポートされる PostgreSQL のエクステンション に参照可能です。 OracleへのアクセスにはPostgreSQLサーバにOCI(Oracle Call Interface)ライブラリのインストールが必要です。バージョン11.2以上を要求しています。 使い方 画像引用元: https://www.postgresql.fastware.com/postgresql-insider-fdw-ora-bas 上記の図に示すようにPostgreSQLの外部テーブルとOracleのテーブルのマッピング関係を設定する上で、PostgreSQLからOracleテーブルのデータをアクセスできます。 連携先のOracleデータベースの各種情報を利用して、下記の手順で設定する。 oracle_fdwのエクステンション（EXTENTION）の作成 CREATE EXTENSION oracle_fdw でPostgreSQLのエクステンションを作成する必要があります。 外部サーバの作成 Oracleのホスト、ポート、データベース名を格納する外部サーバを作成する CREATE SERVER ora_sv FOREGIN DATA WRAPPER oracle_fdw ## ホスト、ポート、データベース名を設定する OPTIONS (dbserver 'host_ora:1521/XEPDB1') PostgreSQLユーザーに外部サーバの使用権限をつけることも必要です GRANT USAGE ON FOREIGN SERVER ora_sv TO postgres; ユーザーマップの作成 OracleユーザーとPostgreSQLローカルユーザーとのマッピングする ## Oracleデータベースのユーザー名、パスワードを設定する CREATE USER MAPPING FOR postgres SERVER ora_sv OPTIONS ( USER 'ora_user', PASSWORD 'xxxx'); ユーザーマッピングすることで、Oracleユーザーと同じアクセス権限をもらう 外部テーブルの作成 最後、PostgreSQLに外部テーブルを作成して、Oracleテーブルとのマッピングを設定する CREATE FOREIGN TABLE f_ora_tbl( ## 主キーカラムはkeyオプションで設定する id int OPTIONS (key 'true'), name varchar(64), t_data timestamp) ## スキーマ、テーブルを設定する SERVER ora_sv OPTIONS (SCHEMA 'ORA_USER' , TABLE 'ORA_TBL'); テーブルのマッピングには以下の注意点があります。 テーブルカラム定義は、Oracle側のテーブルカラムと同じ種類のデータ型を定義する必要があります。異なるデータ型を指定する場合、oracle_fdwが自動的にデータ変換が行います。 OracleとPostgreSQLテーブルカラムのマッピングはカラムの順序をそれぞれ対応させる、外部テーブル作成する時はカラムの順番は要注意です。カラムの順番が間違っている場合、正しいデータアクセスが行われない可能性があります。 Oracle側のテーブルデータを更新する場合は、主キーカラムすべてにkeyオプションの設定が必要です SQLパフォーマンスへの影響 oracle_fdwを使うSQLを発行する場合、SQLの実行にOracleとPostgreSQL間の通信が発生します。ローカルのテーブルアクセスと比べて、データベース間の通信速度、通信容量の制限に影響があるため、SQLのパフォーマンスには影響する場合もあります。 連携先のOracleデータベースから大量のデータを取得する場合、SQLのパフォーマンスが落ち、PostgreSQLおよびOracleにも負荷をかける可能性があるため、実際の使用には要注意です。 PostgreSQL外部テーブルへのアクセスがある2つのSQLから説明したいと思います。 SQL A select count(*) from ora_tbl s join tbl g on s.id=g.id and (s.id=952 or s.id=948) Execution Time: 5.935 ms SQL B select count(*) from ora_tbl s join tbl g on s.id=g.id and (g.id=952 or g.id=948) Execution Time: 2656.699 ms * ora_tblは外部テーブル、tblはローカルテーブル。 上記2つのSQLは外部テーブルとローカルテーブルの結合を行い、絞り込み条件にあうレコード数を取得しています。 SQLの実行結果は一致していますが、SQL Aの実行時間はSQL Bより明らかに短いです。 SQLの実行計画から原因を特定すると、以下のことが分かります。 SQL A explain analyze select count(*) from ora_tbl s join tbl g on s.id=g.id and (s.id=952 or s.id=948) "Aggregate (cost=24004.50..24004.51 rows=1 width=8) (actual time=5.837..5.838 rows=1 loops=1)" " -> Nested Loop (cost=10000.29..24002.00 rows=1000 width=0) (actual time=0.430..5.566 rows=1153 loops=1)" " -> Foreign Scan on ora_tbl s (cost=10000.00..20000.00 rows=1000 width=14) (actual time=0.407..3.479 rows=1153 loops=1)" " Oracle query: SELECT /*727d818c0e8c5e5fc8c1ba25f14f1951*/ r1."COL_1" FROM "ORA_TBL" r1 WHERE ((r1."ID" = 952) OR (r1."ID" = 948))" " -> Index Only Scan using pk_tbl on tbl g (cost=0.29..4.00 rows=1 width=6) (actual time=0.001..0.001 rows=1 loops=1153)" " Index Cond: (id = s.id)" " Heap Fetches: 706" "Planning Time: 1.569 ms" "Execution Time: 5.935 ms" SQL B explain analyze select count(*) from ora_tbl s join tbl g on s.id=g.id and (g.id=952 or g.id=948) "Aggregate (cost=20019.19..20019.20 rows=1 width=8) (actual time=2656.574..2656.578 rows=1 loops=1)" " -> Hash Join (cost=10016.56..20019.18 rows=1 width=0) (actual time=276.345..2656.376 rows=1153 loops=1)" " Hash Cond: (s.id = g.id)" " -> Foreign Scan on ora_tbl s (cost=10000.00..20000.00 rows=1000 width=14) (actual time=0.400..2549.151 rows=717509 loops=1)" " Oracle query: SELECT /*90e1158c8e451061bc34a219bd77fa69*/ r1."ID" FROM "TBL" r1" " -> Hash (cost=16.53..16.53 rows=2 width=6) (actual time=0.028..0.030 rows=2 loops=1)" " Buckets: 1024 Batches: 1 Memory Usage: 9kB" " -> Bitmap Heap Scan on tbl g (cost=8.60..16.53 rows=2 width=6) (actual time=0.023..0.027 rows=2 loops=1)" " Recheck Cond: ((id = '952'::numeric) OR (id = '948'::numeric))" " Heap Blocks: exact=2" " -> BitmapOr (cost=8.60..8.60 rows=2 width=0) (actual time=0.017..0.019 rows=0 loops=1)" " -> Bitmap Index Scan on pk_tbl (cost=0.00..4.30 rows=1 width=0) (actual time=0.013..0.013 rows=1 loops=1)" " Index Cond: (id = '952'::numeric)" " -> Bitmap Index Scan on pk_tbl (cost=0.00..4.30 rows=1 width=0) (actual time=0.004..0.004 rows=1 loops=1)" " Index Cond: (id = '948'::numeric)" "Planning Time: 1.377 ms" "Execution Time: 2656.699 ms" 実行計画のForeign Scanの部分を注目してください。 SQL A " -> Foreign Scan on ora_tbl s (cost=10000.00..20000.00 rows=1000 width=14) (actual time=0.407..3.479 rows=1153 loops=1)" " Oracle query: SELECT /*727d818c0e8c5e5fc8c1ba25f14f1951*/ r1."COL_1" FROM "ORA_TBL" r1 WHERE ((r1."ID" = 952) OR (r1."ID" = 948))"" -> Foreign Scan on ora_tbl s (cost=10000.00..20000.00 rows=1000 width=14) (actual time=0.407..3.479 rows=1153 loops=1)" SQL B " -> Foreign Scan on ora_tbl s (cost=10000.00..20000.00 rows=1000 width=14) (actual time=0.400..2549.151 rows=717509 loops=1)" " Oracle query: SELECT /*90e1158c8e451061bc34a219bd77fa69*/ r1."ID" FROM "TBL" r1" 主な実行時間の差はForeign Scanから生じます。 Foreign ScanはOracleのアクセスする時に発生します。SQL Aの場合、Foreign Scanから取得するレコード数は1153です。SQL Bの場合、Foreign Scanから取得するレコード数は717509です。 結論として、oracle_fdwの使用する時、OracleとPostgreSQLの通信データ量はSQLのパフォーマンスに大きく影響します。 oracle_fdwを使う時のSQLパフォーマンスが気になる場合、Explain文でSQLの実行計画を分析してSQLチューニングすることがお勧めです。実行結果にあるForeign Scanの回数およびレコード数を抑えるSQLチューニングはSQLパフォーマンスの向上に役立つと思います。 oracle_fdwを使うSQLの性能を影響する要因はほかにもあるため、気になる方は下記の記事を参考できると思います。 Oracleデータベースにアクセスする ～oracle_fdwを使いこなすために～ まとめ 以上PostgreSQLのoracle_fdw拡張機能を検証してみた話でした。読んでいただきありがとうございます。 まだ実際にDB移行プロジェクトには導入していないため、導入後のメリットとデメリットまたはプロジェクトへの影響はまだ不明です。今後また機会があればブログを書いて共有したいと思います。 また最後にLIFULLでは一緒に働く仲間も募集しているので、よろしければこちらも併せてご覧ください。 hrmos.co hrmos.co

こんにちは、LIFULLでエンジニアとして働いている中島です。 私は2010年入社なので現時点で12年程同社で働いています。 長い方ではありますが、LIFULL社はそれよりずっと長く歴史のある会社で、多種多様なメンバーがいます。 その中には自分の意思で職種変更をしたメンバーや、自身の職種がそもそも時の流れとともに無くなり、変わらざるをえなかった方々もいます。 本記事では、フロントエンド領域に関わる職種変更に伴い、LIFULLではどのような課題があったか、また、メンバーの技術ギャップを埋めるためにどのようなサポートを行ったかについて紹介させていただきます。 コーダー職種からフロントエンド職種へ 育成を現場へ サポートの内容 その後の会社への影響 最後に one more thing コーダー職種からフロントエンド職種へ 5年程前、世の中のフロントエンドエンジニアに求められる技術スタックが大きく様変わりし、それまでマークアップ、CSSコーディングを生業にしていた方々はその際に大きな転換期を迎えたのではないでしょうか。 その世の中の転換が正しかったのかは私には分かりませんが、弊社でも同じように世の流れに沿う形でコーダー(マークアップを主とする)職種がなくなり、フロントエンドエンジニアという職種(あるいはもう少しプランナー、デザイナー寄りの職種)への変更の話がでて職種の新設、廃設がおきました。 会社としては移行対象者に対してはそれぞれサポートを試みましたが自学自習がベースにあり、業務時間を利用した学習の許可や、学ぶためのオンライン講座等の提供といった感じのものが多く、本人のモチベーションに依存している側面があり、人によっては中々厳しそうな現実が見えていました。 育成を現場へ 人事規定の変更なので人事側と技術マネージャーが主体となって動くわけですが、そこからのアプローチだと工夫しなければ既出の課題を抱えてしまうので、もともと自分の業務時間の数割を割いて行っていた技術育成の枠を使って移行メンバーのサポートをさせてもらないかと打診してみました。 (対等な同僚で且つ自分から望んだわけではない職種変更にあったメンバーにサポートという表現を使うのは随分と偉そうですが表現が難しいのでサポートという表現で記述していきます) 移行メンバーは10人程なので有志のメンバーで数人ずつ担当すれば現実的に対応可能なのかなと思っての提案だったのですが願ったり叶ったりということですぐにその運用が開始されました。 サポートの内容 弊社の場合、コーダー職からフロントエンド職への移行にあたっての最大の難所はJavaScriptなわけですが、幸い技術育成のためのドキュメントや理解度を図るための課題はもともと別の方々を対象にした技術育成を行っていた際に作っていたのでそれを再利用した方法で行うことができました。 JavaScriptそのものに対する学習カリキュラム 目的と内容については以下の通りです。 言語特性の理解(初級) 変数 式 値の種類 関数宣言 関数式 スコープ if for Array 言語特性の理解(中級) スコープチェイン クロージャ functionが一級オブジェクトであることの理解と意識の植込み 高階関数 再帰 コンテキストの理解 thisの決定原理 thisの束縛 call/apply classical実装パターンの理解 constructor/new prototype inherit class syntax DOM Modelおよび周辺技術の理解 DOM Scripting イベント バブリング・キャプチャリング 非同期について Ajax/JSONP 設計パターンの理解 オブザーバーパターン メディエイターパターン ストアパターン 各種ライブラリの再実装 10人もいれば全員に向けて会を開くのが最小コストにも見えますが、もともと興味があったメンバーが集まってるという前提があるわけでもないので個別に時間をもうけてお互いのマインドを理解しあい、心理的安全性を高めることに重きをおきながら毎週行いました。(今年で2年、それ以前から受けてた方もいらっしゃるので長い方は4年ほど) HTMLコーディングをバックグラウンドにもつ方々が多かったので、最近ではある程度言語理解が深まった後はJavaScriptのツールチェインとかaltJSの分野ではなくアクセシビリティを高めるために付随して必要になってくるJavaScriptを学ぶという方向性で授業内容を組み立てるようにしました。 具体的にはWAI-ARIA Authoring Practices 1.1(現在は1.2)で取り扱われているUIパターンの読み込み、実装練習になります。 www.w3.org WAI-ARIA Authoring Practicesで紹介されるUIパターンのうち、カリキュラムとして採用したもの Alert Disclosure Dialog Tabs Feed Listbox MenuButton Menu or Menubar Carousel Combobox Grid そのほかのUIパターンについてはこれらを履修後に読み込みだけを実施 これはそれまでの言語理解のための授業に比べると、自身のもともとある強みを拡張する方向の内容になるのでモチベーションの高まりを感じることができてとてもいい選択でした。 (人によってはその後サーバサイドに興味を持ちRubyやNodeでのアプリケーション制作の演習などに進んだケースもあります) その後の会社への影響 今LIFULLではいくつかのWG(ワーキンググループ)があります。 その中にはLIFULL HOME'S全てのフロントエンド開発をより良くしていこうというWG、全サービスを対象にアクセシビリティ向上を推進していこうというWGなどもあります。 私はその両方に所属しているのですが、フロントエンドを改善していく方のWGでは、デザイナーからこのサポートを経てフロントエンドエンジニアに転身された方が活躍してくれていたりします。 彼ら・彼女らにしかないバックグラウンドを生かした取り組みもあり、デザイナーとの橋渡しやスタイルガイドの作成など幅広く成果を出してくれています。 アクセシビリティの推進活動を行うWGにおいては、会社の全サービスを対象に推進活動を行うため、もともと数人のWGメンバーでは当然各PJに参入して実装支援を行う...とまではいかない現実がありました。 しかし、それぞれのPJには代わりにこのサポートをうけてくださった方々が入っていることが多く、そこで得た知識を実務に生かしてくれており、WGとしてはアクセシビリティレビューの請負や啓蒙活動、相談対応を、現場の転身組は実装でそれを力強く支えるという関係性ができつつあります。 最初は単純に移行をサポートしたいという気持ちだけで始まったものですが、それが回り回って波状的に会社を前進させる力となっているのを感じます。 最後に 近年フロントエンドエンジニアの採用事情はかなり厳しいと聞きます。 採用ばかりではなく内側に眠っている多くの才能にも目を向けていきたいですね。 one more thing LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

エンジニアの内藤です。LIFULL HOME'Sの売買領域を支えるエンジニアチームのマネジメントを担当しています。 弊社エンジニア部門では 強い個人・最高のチームになることで価値創造を加速させ続ける というビジョンを掲げています。 これは新しいサービスの開発や機能改善による足元での価値提供だけでなく、開発生産性を向上させることで長中期的により多くの施策をまわせるようになり価値提供を最大化させることを目指してのものです。 そこで私たちのグループは個人のスキル（テクニカル・ポータブル）・環境（プロダクト・ツール）・体制（チーム・業務フロー）を改善していくことにも取り組んでいます。 自分たちの開発生産性を向上させるのに何をしたら良いのか、自分事として捉えてもらうためにもグループのメンバー全員でディスカッションしました。 その中でメンバーから発案があったものの１つが 裏HOME'S斬り と名付けたものでした。 「HOME'S斬り」とは 裏HOME'S斬り の前に、LIFULLでの HOME'S斬り の取り組みについて説明します。 弊社では HOME'S斬り と称して、入社したての社員にLIFULL HOME'Sを使い倒してもらい、課題を見つけてその改善アイデアを発表してもらうことをよくやっています。 これは主に下記の目的のためにおこなっています。 サイトにどんなページや機能があるのか把握してもらう まだ慣れていなので、第三者的視点でサイトの課題を見つけてもらう サイトを長く運用・改修していると機能や見た目に慣れてしまい、課題に気付かなかったり課題と思えなくなってしまうことが多々あります。 社歴が長い社員にとっても新鮮な気付きを得られる機会で、非常に有益な場となっています。 「裏HOME'S斬り」とは 裏HOME'S斬り とは、この HOME'S斬り をHOME'Sの裏側であるプロダクトのソースコードを対象としてエンジニア目線でおこなうことです。 取り組みのねらい 裏HOME'S斬り を実施することは下記のようなメリットがあると考え、実行することにしました。 システムの負債に対する意識のレベルが共通化される ⇒　若手のスキル向上 改善案を実施すればリファクタリングが行なえる ⇒　プロダクトの負債の解消 メンバー発案なので自分事と捉えて活動できるのではないか ⇒　主体性発揮の機会・経験（チーム力向上） 実行における工夫 エンジニアがソースコードの課題を見つけて改善案を出すことは、下手するとディスるだけになってしまう懸念がありました。 ※その場に実装した人がいるかもしれないのに・・・ また、業務の負荷になる作業が増えてしまうと本末転倒なので下記のようなルールを定めました。 既存のコードには敬意を持って接しましょう 斬るべき対象はエンジニア目線であればいい ここのロジックもっとスマートにできないか データ構造が気持ち悪い これもう不要だよね アクセシビリティもっと考えられるはず etc がっつりプレゼン資料は作らなくてもいい 対象の場所がわかればOK 発表後、「直したほうがよいか」「すぐにできるか」あたりの軸を参加者で評価する 評価した結果 ふりかえり 通常業務に影響がでないように2ヶ月に1回ぐらいのペースで数回実施してきましたが、良かった点・改善すべき点がそれぞれ幾つかありました。 良かった点 ソースコードの負債に対する意識が強くなった 普段の業務でソースコードを見る際に改善点をより気にするようになった どう直すのが良いか議論が白熱することもあり、より深く本質的に捉えるようになった アクセシビリティの課題など一部のものは改善実施までおこなえた 純粋に楽しんで活動できた 改善すべき点 開発効率の向上を意識し過ぎたせいで「すぐにできるか」という点で該当するものが少なくなり、実施に移せないものが多かった 実施できそうなものも誰がいつやるかという点で曖昧になってしまい、実施まで進められないものもあった 期待していた自主性発揮についてはあまり効果がなかった 途中で「直したほうがよいか」に該当するものは規模に関わらずタスクチケットを作っておき、後ほど余裕がある時に対応できるようにするなどブラッシュアップしながら実施していました。 しかし、改善実施まで完了させるにはまだまだ工夫が必要なことが見えてきました。 例えば、すぐできそうにない規模のものでも負債解消度の高いものはプロジェクト化を検討したりすることで、実行まで進めることができそうです。 まとめ 上記のように 担当者を決める ・ 改善実施に使える時間を確保する ための仕組み化をできるだけ通常業務に影響を与えない形で構築できれば、より多くの改善実施の成果まで辿り着けると考えています。 引き続き 楽しんで活動できる利点を活かしたまま 、成果を出すために 裏HOME'S斬り の改善を続けていきたいと思います。 また最後にLIFULLでは一緒に働く仲間も募集しているので、よろしければこちらも併せてご覧ください。 hrmos.co hrmos.co

テクノロジー本部のyoshikawaです。 最近のLIFULLでは、自社が所有するデータの活用を目的に数多くの取り組みが実施されています。 今回はデータの発見可能性(Data Discovery)を向上させるための基盤構築を目指して実施したPoC(Proof of Concept)とそのOSSの選定について紹介します。 当初は「自社データの再利用性を高めたい」という広い意味を持った要件で開始したプロジェクトでしたが、 Data Discoveryがボトルネックになっていると判明し、解決策としての基盤構築に向けてPoCを実施することとなりました。 現場の課題調査からOSSの選定と試験運用まで一連のトピックをまとめていきます。 初期フェーズ: 現場調査と課題抽出 FAIR原則 データ利用の現場から抽出した課題 ボトルネックの特定と解決策の選定 PoCの開始 OSSの選定 Datahubとは Metadata ingestion PoCの評価指標 PoCの結果 Data Discovery Platform導入への期待 Data Discovery Platformはあくまでも必要条件 これからの展開 求人情報 初期フェーズ: 現場調査と課題抽出 昨年秋、「自社データの再利用性を高めたい」という目的とともにプロジェクトがスタートしました。 筆者をはじめ、プロジェクトメンバーにはデータエンジニア的なバックグラウンドを持つ人はおらず、まずは現場調査を通じ探索的に解決策を導出することとなりました。 ディスカッションや調査の際には記録を手続き的なドキュメントとして残すのではなく、 IBIS(Issue Based Information System) という手法と オンラインホワイトボードのMiroを活用することで、議事録作成をDialogue mapping化しDAGとして残しました。 miro.com 現場調査のフェーズは2ヵ月にわたり、なおかつ多くのステークホルダーに対して実施したため、 過去のやりとりと現在の関心事との関連を視覚的に把握しやすい形式で議論を行うことで議論の発散と収束を視覚化できたのは効果的でした。 MiroでのDialogue Mapping: 議論の現在地や目的を可視化 FAIR原則 データの再利用性を高めたいという観点でスタートしたものの、この時点ではデータエンジニアリングの観点が不足していたこともあり最終的な成果の定義に難儀してしまいました。 民間企業だけではなくアカデミックにおいてもデータ活用の問題は存在していると考えリサーチを行ったところ、データ共有の原則であるFAIR原則を発見しました。 biosciencedbc.jp FAIR原則を知り、これまでに自分たちが焦点を当てていたデータの再利用性とは、相互に関連する4つの原則のうち1つに関連するものでしかないと認識しました。 これ以降は、データ活用にまつわる複数の問題を念頭に置きつつ、ディスカッションや後続となるインタビュー調査を実施しました。 データ利用の現場から抽出した課題 データ分析者やAIエンジニア、プロダクト開発を行うアプリケーションエンジニアや企画職などデータに関連する職種の方々に協力いただきインタビュー調査を行いました。 その結果を要約すると、下記のような課題が得られました。 データの格納場所やデータの情報(メタデータ)あるいはデータの存在自体が不明、または特定のチームや個人のナレッジとして埋没している データの派生系が多く、利用価値のあるデータ・起源となるデータなどユニークなデータが発見できない 発見したデータが更新されているのか、誰が管理しているのかが不明で利用開始するまでに問い合わせが発生する いわゆるデータのサイロ化に起因する問題が目につきます。 これらインタビュー調査の結果を踏まえ、あるべき解決策は静的なドキュメンテーションや属人的な助け合いの仕組みの強化ではなく、 「自動で最新の状態に追従可能で、統一された形式に沿って管理・運用されたデータが入手可能な基盤」であると結論づけました。 ボトルネックの特定と解決策の選定 ここまでの調査は現場の開発者・分析者へのインタビューなどを通じてボトムアップ的に行われてきました。 調査で得られた生の課題の集まりに対して優先的に取り組むべき課題と解決策を選ぶために、書籍"The Self-Service Roadmap"にて導入されていた考え方を取り入れました。 The Self-Service Roadmapにおいては、データ活用の主たる指標とも言える"Time to insight"(知見を得るまでの時間)を "Discover", "Prep", "Build", "Operationalize"の4つのフェーズに分割することが提唱されています。 自分たちの調査によって集められた課題は、Discoverのフェーズ、特にデータセットあるいはそのメタデータの検索の課題に該当すると判断しました。 つまり"Data Discovery"こそが開発・分析現場のボトルネックとなっており、優先的に取り組むべき課題であると判明したのです。 PoCの開始 The Self-Service Roadmapにおいてself-service data platformが立ち行かなくなるアンチパターンとして、 問題を理解しないまま技術にだけ投資してしまうことと、一度に多くの問題を解こうとすることが挙げられています。 アンチパターンに陥らないためにも今回のプロジェクトではData Discoveryに焦点を当て、 これを持続的に解決可能な基盤を導入すべく、技術選定とそのPoC(Proof of Concept)から始めていきます。 OSSの選定 近年、海外を中心としてModern Data Stackという言葉とともに最新のデータ基盤周辺技術に注目が集まっています。 日本でも注目されているdbtのブログにて、Modern Data Stackの来歴とともに展望を読み取ることができます。 blog.getdbt.com Data Discoveryの分野だけでなく、Modern Data Stackを構成する技術は多岐に渡り、 解決したい問題領域や抱えるデータセットの量、事業フェーズなどの制約条件に沿って適切な技術を選定する必要があります。 今回の場合は「 "多様なデータソース" に対して "Data Discovery" を向上させるための "基盤(Platform)" の "PoC" を行いたい」という制約に基づき、 LinkedInとAcryl DataによるOSSである "Datahub" を選びました。 datahubproject.io Data Discoveryの向上を目指せるMetadata Platform系のOSSにはAmundsenやApache Atlas、Open Metadataなどがありますが、 PoC期間内での構築しやすさ・運用可能性、利用者(社内開発者・分析者)向けのUXや機能性を考慮した結果、Datahubを選定しました。 OSSの採用以外の選択肢には、社内で利用しているGoogle CloudのData Catalogを充実させるという選択肢もありましたが、 LIFULLのデータセットはAWSやGCPなど複数のインフラで稼働しているため、中立的なDatahubを試用することとなりました。 Datahubとは 公式ドキュメントでは下記のように説明されており、多様で複雑なデータエコシステムにおけるMetadata PlatformとしてData Discovery, Data Observability, Federated Governanceを実現させることが特徴として挙げられています。 Data ecosystems are diverse — too diverse. DataHub's extensible metadata platform enables data discovery, data observability and federated governance that helps you tame this complexity. Data Discoveryという点ではElastic Searchによるメタデータの検索やWebブラウザのようなUI、Datahub独自のシンプルで拡張性のあるメタデータスキーマによって実現されています。 このようにしてプロダクト開発者や分析者などデータ利用者にとってはシンプルな機能を提供しつつも、 Push型のデータ更新アーキテクチャによる最新のデータへの追従やData Lineageの取得によるObservabilityの確保と、 AWSのIAMのようなRBACによりFederated Governanceの実現を目指すことができ、継続的な運用に耐えうるカタログスペックを有しています。 また、DatahubではQuick Start用のDocker Imageやhelm chartsも用意されており、ローカル環境での試用やPoCが容易に実現可能です。 今回のPoC期間中でもhelm chartsを利用し、LIFULLの検証用Kubernetes環境上に1日程度でデプロイできました。 デプロイしたDatahubのトップ画面 Metadata ingestion RDB(MySQL,Postgres,etc),DWH(BigQuery,Snowflake,etc),BI(Tableau, Looker)など多岐にわたるデータソースから、カラムの物理名やスキーマ情報などのmetadataのingestionが可能です。 ingestされたmetadataに対してはUIやAPI経由で編集することが可能で、データに関するナレッジなどTeam Metadataも集約することが実現できます。 PoC期間中ではFederated Governanceの観点を検証しきれませんでしたが、基盤の管理者がingestionを中央集権的に管理・実行するのではなく データソースに近いプロダクト開発エンジニアやデータソース運用者がDatahub上のmetadataのOwnerとなることで、 自分達のTeam Metadataは自分達で管理しつつ横断的なプラットフォームで第三者が入手・検索可能にし、self-serviceなデータ基盤を実現できるのではないかと考えています。 例えば、DDDにおけるユビキタス言語を制定した後はDatahub上に載せて、チーム内外の認識の齟齬を減らせることが期待できます。 Metadata ingestionの実行後イメージ: タグやTermsからmetadataが検索できる PoCの評価指標 Datahubによって実現されるData Discovery Platformが本当に現場のData Discoveryを実現するかを評価することに加え、 大元の課題であったデータ活用の促進を実現できるかを検証するために、いくつか設問を用意しData Discovery Platformの利用者にアンケートをお願いしました。 例えば以下の2つです。 設問1. Datahubで構築したData Discovery Platformは、欲しいデータを発見するまでの時間を短縮するか？ 設問2. Datahubで構築したData Discovery Platformは、データを発見してからデータを活用開始するまでの時間を短縮するか？ The Self-Service Data RoadmapにおけるDiscoverにおけるメトリクス:"Time to find"への貢献度を設問1で収集し、 Discoverというmilestoneを含めたデータ活用開始までの時間短縮への貢献度を設問2として収集しています。 別途、性能評価やマシンリソースの消費度合い、費用など非機能的な要件の評価も行います。 PoCの結果 社内のデータ基盤エンジニア・データ分析者・アプリケーション開発者・技術マネージャーなどにData Discovery Platformは利用され、アンケートを実施いただけました。 その結果、設問1については9割が好意的な回答で、設問2については好意的な回答が5割、否定的orわからないという回答が5割でした。 Data Discovery Platform導入への期待 設問1で好意的な回答が大半を占めたことから、Data Discovery Platformを意図して構築されたプラットフォームが 現場のData Discovery向上に寄与することが立証できたと言えます。 データ発見という観点で既存の社内ツールや技術基盤に対する競合優位性があったことは確かですが、 今後全社的に運用する場合、ingestするデータセットが増加し玉石混合なmetadataを持ってしまうリスクもあるので注意は必要です。 Data Discovery Platformはあくまでも必要条件 一方、設問2では半数が「いいえ」あるいは「わからない」など好意的とは言えない回答であったことから、 Data Discovery Platformの実現はあくまでデータ活用のための必要条件であり、十分にデータを活用するには他にも解決すべき課題があると考えています。 ただし好意的な回答が少なかった外部要因として、PoC期間に十分なmetadataを用意できなかったという要因もあるので、 ingest自体を効率化するような仕組みを検証していきたいと考えています。 これからの展開 今回のPoCを経てData Discovery Platformの導入が開発現場・分析現場のデータ活用を促進する一歩となることを立証できました。 ただ、あくまでPoCが成功したに過ぎず本格的な稼働に向けては運用面での課題も存在します。 魅力的な技術や目新しい技術の多いModern Data Stackですが、"right tool for the right job"を原則としてこれからの基盤構築を行っていきたいところです。 求人情報 LIFULLではエンジニアの募集をしており、カジュアル面談も実施中です。 募集中の職種など詳細は下記をご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の佐野です。 LIFULLでは2020年3月頃からリモートワークが主体の働き方になっています。 出社して働いていた頃と比較すると、同じグループのメンバーとは日々業務を進める上でコミュニケーションは取っているものの、他部署のメンバーとのコミュニケーションが少なくなった...という話もちらほらと。 偶発的なコミュニケーションも必要だ！とのことで社内サークル活動を推奨する制度が出来上がりました。 2022年1月末でサークルは74。多い！ どこかのサークルに入っている人は747人。めっちゃ多い！！ 上記の通り社内サークルは沢山存在していますが、その中でも今回は、私が主催者となって活動している映画サークルについてご紹介します。 映画サークルについて 映画サークルといっても、敷居は限りなく低く（ここ重要）、私の主催しているサークルは基本月1回の活動です（多いと疲れてしまうので）。 リモートワークが主体の働き方に合わせて、活動もオンラインで行っています。 基本メンバーは7名で活動しており、職種・部署はバラバラです。 このサークルで初めて知り合った方が多数で、対面で会ったことのないメンバーも中にはいます。 普段だと、同じ部署や同じ職種の人と知り合うことがほとんどなので、色々な職種・部署のメンバーと気軽にコミュニケーションが取れるのはサークル活動の強みだと感じています。 サークルで観る作品は、Netflixの中からメンバーが面白いと思ったものを観る形をとっています。 Netflixはたくさん作品があるので飽きません。 「映画」とサークル名についていますが、実際には映画に限らずドキュメンタリーなど色々な作品を観ています。 サークル開催 開催日が決まったらオンラインで集合して、速攻番組を観る…というせっかちスタイルではなく、大体の時間帯にオンラインで集合します。 業務ではないのでここはゆるく始めます。 作品を観る前後30分くらいは雑談タイムを設けていまして、その時にみんなで観る作品を雑談しながら決める形にしています。 こんなものを観たい、どんな番組が面白かった、スタートレックが好きだ、等の雑談を和やかにしています。 普段自分では観ない作品も観れますし、みんなの趣味趣向が知れて大変面白いです。 作品との偶発的な出会いが期待できます。 ちなみに作品を見るときは、「再生しまーす」で同タイミングで再生ボタンを押すようにして、各人の環境で作品を観ています。 また、サークル活動にはサークル活動費として会社から補助が出ます。 そのためサークル開催日には予算内で思い思いの飲食物を購入して、サークルでの時間を楽しんでいます。 1月の活動日には、エンジニアの青木さんも飛び入りで参加して和やかに過ごしました。 そのときは、「ミッドナイトアジア」というドキュメンタリーを観ました。 サークルに飛び入り参加してみての感想 今回飛び入り参加させていただいた青木です。 リモートワーク中心となる前は社内ですれ違えば会話していた面々と、 本当に久しぶりにお話しすることができました。 社員数が増えても、業務だけだと接点って増えるわけではないんだな、こういう機会があるのって大事なんだな、と実感しました。 「ミッドナイトアジア」は、まぁ自分では手を伸ばさない作品でサークルならではのチョイスで楽しめました。 まとめ 今回は私が主催する映画サークルについての紹介でしたが、先述した通り多種多様なサークルが存在しています。 ゲームや数学、エンジニアが他職種の方にプログラムを教えるサークルもあります。 サークル活動を通して普段の業務で関わることのない他部署の知り合いも作れますし、コミュニケーションも取りやすくなると思います。 自分で主催するもよし、サークルに入るもよし。 リモートワーク主体の働き方になりましたが、今回紹介したサークル活動以外にもコミュニケーションを取りやすくするための取り組みが盛んに行われています。 1日誰とも会話していない...なんてことも解決するかも！？ LIFULLでは一緒に働く仲間を募集しております。 もし興味を持っていただけたら、募集求人やカジュアル面談のページもご覧ください。 hrmos.co hrmos.co

こんにちは、エンジニアの加藤です。LIFULL HOME'Sの注文住宅領域を支えるエンジニアチームのマネジメントを担当しています。 皆さん、技術的負債の解消やリファクタリングなどどのように行っていますか？ 長年の開発業務により蓄積された技術的負債は、開発生産性を低下させる要因として多くの方の頭を悩ませているかと思います。 私の所属する部署では開発生産性の向上をミッションとして掲げており、技術的負債の解消はミッションを達成するための重要な要素となっています。 そのような中、私たちのチームでは「リファクタDays」という取り組みを通じ、約半年間技術的負債の解消を含むシステム改善に努めてきたので、今回はそちらについて紹介したいと思います。 技術的負債の解消を行う上での課題 開発生産性を上げるため技術的負債の解消が重要である一方、LIFULL HOME'S 注文住宅の機能開発を担当するエンジニアであるため、常にプロジェクトに配置されておりサービス開発を行う必要があります。 そのため、負債解消とサービス開発を両立させるためには、限られた時間の中でバランスよく実行することが重要となります。 昨期以前は組織で技術的負債の解消計画を立てつつ、実行は担当するプロジェクトの状況を加味しつつ各メンバーの裁量に任せておりました。 しかし、ときにはプロジェクトを優先して負債解消への取り組みを劣後せざるを得ない状況もあり、計画に対し思うように進捗させるのが難しい場面もありました。 上記の結果を踏まえ、一番の課題は負債解消に取り組む時間を十分に確保できないことであると捉え、仕組み化により課題解決を図る方法を検討しました。 リファクタDaysという取り組み プロジェクトと両立させるための仕組み 前述の通り、サービスを成長させるためプロジェクトを遂行することも重要な職務であるため、プロジェクトと両立させることは不可欠です。 そのため、どのように負債解消に取り組む時間を確保するかが重要となります。 プロジェクトを計画する上で、不確定な要素はなるべく排除しておきたいものです。 エンジニアがプロジェクト外の開発をいつどれだけ行うか不明瞭である状態では計画も立てづらく、プロジェクトの遂行にも影響を及ぼします。 これらの影響を抑えるよう、負債解消への取り組みは一定周期ごと一定期間実施することとし、あらかじめ半期分時間を確保することとしました。 また、負債解消に取り組む上でも効率化は重要です。 タスクにより粒度や規模は異なるため、1日で完遂するものもあれば数日に及ぶものもあります。 開発途中で手を止めることは開発効率を低下させる要因となるため、連続した数日間を集中して取り組むことができる期間として確保することとしました。 これらをもとに以下のルールを定め、この期間を「リファクタDays」と名付けました。 3週毎3日間利用し実施 実施日は水、木、金の連続した3日間 開始日の朝11時にキックオフを実施し、期間内で実施するタスクを各自ピックアップする 原則この期間はプロジェクトに纏わる活動（開発・MTGなど）は行わない 原則スケジュールの変更は行わない（休暇・祝日が被る場合も） 目的は開発生産性を上げること 開発生産性を上げるためには技術的負債の解消以外にも様々なアプローチがあります。 例えば、運用業務の効率化やリファクタリングによりソースコードの保守性を高めること、システムコストを削減することで人的リソースのコストに回すなど。 リファクタDaysの目的は開発生産性を向上させることであるため、技術的負債の解消に限定せず上記を含めたシステム改善全般を取り組むべきものとして位置付けています。 周囲の協力を得ることが重要 これらの取り組みを考えても周囲の関係者の理解と協力を得ることなしに実行はできません。 特にプロジェクトをともに遂行するプロダクトマネージャーや企画職のメンバーの協力は不可欠です。 リファクタDaysの目的や効果を伝えるだけでなく、ルールのすり合わせや実施後のヒアリング、実施内容の見える化など様々な取り組みを行いました。 これらにより理解を得られ快く協力してもらえたことが、リファクタDaysを遂行するための大きな後押しとなっています。 リファクタDaysでの効果 現在約半年間リファクタDaysを実施してきましたが、時間確保の課題は解消され、プロジェクトと両立しつつ一定のペースでシステム改善を積み上げることができています。 システム改善数の推移 また、LIFULL HOME'S 注文住宅へのリリース数も昨期半年間と比較して一月あたり平均約1.5倍に増加し、高い水準で安定していることから開発生産性向上への効果も感じられます。 LIFULL HOME'S 注文住宅 月別リリース数 まとめ 技術的負債の解消や開発生産性向上は多くの組織で抱える課題であり、重要な取り組みの一つであると思います。 今回紹介させていただいたリファクタDaysの事例が、皆さんの課題解決に少しでもお役に立てたら嬉しいです。 また最後にLIFULLでは一緒に働く仲間も募集しているので、よろしければこちらも併せてご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の二宮です。 LIFULL では「エンジニアいつでも相談」という名前で、 GitHub Discussions を使った社内向けの Q&A フォーラムを有志で運営しています 🙌 このフォーラムは「あるシステムについて誰か詳しい人に相談したい」とか「設計についてチーム外にも相談したい」とか、エンジニアリングで困ったことをなんでも聞ける窓口になることを目指しています。最近ではアーキテクトチームや QA チームなどの公式の窓口としても利用でき、質問の内容に応じて適切な部署や人がアサインされる体制も整い始めました。 従来は相談相手を見つけるのにも苦労したり、そもそも窓口が用意されていなかったりすることもあり、社内アンケート調査等でよく情報共有が課題に挙がっていました。そこで、社内向けの Q&A フォーラムを用意することで、その問題の一部を解消しつつあります。 エンジニアいつでも相談の利用方法 まず利用方法を紹介します。エンジニアいつでも相談の GitHub リポジトリが用意されていて、その Discussions にフォーラムが用意されています。 ここで過去の質問を検索・起票できます。詳しい案内はトップのハウスルールが掲載されており、初めての人でもあまり迷わずに操作できると思います。ハウスルールには次のような内容が記載されています。 GitHub Discussion 上で過去の質問の検索を行う 解決した場合、Vote をする 既存の質問で解決しなかった場合、「Q&A🙏 」カテゴリで起票する フォーラムに質問が投稿されると、質問の回答者となるチームに通知されます。GitHub Actions によって、タイトルや内容によって各チームにメンションを付けたり、Slack 通知を飛ばす機能が実装されています。もちろん、それ以外の社員も回答できます。 質問者は、問題が解決したら、回答の中からベストアンサー（Mark as answer）を選んでクローズします。 このように、一般的に想像するフォーラムの機能はそろっており、通知の自動化なども必要に応じてすぐに実装できます。 GitHub Discussions を利用するメリット 過去のツールの変遷 実は、エンジニアいつでも相談は、発足当初から以下のような思いは一貫しています。しかし、ツール面ではいくつかのものを渡り歩いてきました。 社内のドメイン知識や社内ルールが分からず悩んでほしくない 将来的にエンジニアの共助・評価・成長につなげたい 具体的には以下のような変遷がありました。 Google グループをフォーラムとして利用する フォーラムを使わずに有志でチャット上で質問・回答をする GitHub Discussions でストック化を促進 まず、Google グループではなかなか質問自体が集まりませんでした。これは、普段利用しているツールではなく、業務の導線にないからだったと思っています。 （ただし、Google グループは、 GitHub アカウントを持っていない社員からの質問も受け付けられる点でメリットがあると思います。発足当初は職種からエンジニアへの質問も想定していて、現在はそこのコミットメントは諦めた形になります） また今から考えると、アサインや通知の自動化がやりづらく、この状態でスケールさせることも難しかったと思います。 次に「普段利用しているサービス上なら質問・回答がやりやすい」という仮説のもと、専用のチャットルームを用意して、有志でそこで質問・回答するようにしました。これはコンスタントに質問が行われるようにはなったものの、「あれ？どれが回答済みなんだっけ？」というやや混乱した状態にもなっていました。またせっかく回答しても、その場限りでナレッジにならないという歯がゆさもありました。 Discussions を利用するメリット それらと比較して、Discussions を利用することについて、以下のメリットを感じています。 業務で普段利用しているサービスであること Q&A が直接ナレッジとして蓄積できること GitHub Actions で自動化ができ、Pull Request で変更を受け入れられること 内容がオープンであること 1, 2 は、ほかのツールとの比較で自然にわかると思います。3 について補足すると、たとえば「GitHub Actions によって各チームに通知を飛ばす」機能は、Discussions 起票時に以下のようなシェルスクリプトを起動することで実現しています。 if [[ "$CATEGORY" = "Q&A" ]]; then ( regexp="([kK]eel|KEEL|[dD]ocker|[kK]ubernetes|ECS|EKS|[pP]rometheus|[gG]rafana|[vV]irtual[[:space:]]?[sS]ervice|[dD]ev[oO]ps|[vV]1[cC]luster[bB]ootstrap|[sS]pinnaker|[sS]elf([-]|[[:space:]])?[hH]osted([-]|[[:space:]])?[rR]unner|J-?SOX)" if [[ "$TITLE" =~ $regexp ]] || [[ "$BODY" =~ $regexp ]]; then addDiscussionComment "$ID" "KEEL: ${KEEL_TEAM}" fi ) ( regexp="([aA]rchitect|アーキ|設計相談|[bB]ff|BFF|[nN]c[aA]pp|[nN]ext[cC]ore|lhv5|[pP]roject[xX]|PJX|pjx|[fF]ront|ベストプラクティス)" if [[ "$TITLE" =~ $regexp ]] || [[ "$BODY" =~ $regexp ]]; then addDiscussionComment "$ID" "Architect: ${ARCHITECT_TEAM}" fi ) # 以下略 この通知スクリプトに各チームが通知内容を設定するようにしています。チーム側からこれらの修正を Pull Request として送ってもらうことで、運営チームはあまり負荷を感じることなくメンテナンスできます。 また、一度の投稿で、複数のチームに相談できるというメリットもあります。たとえば「何かのプログラムの問題について QA とアーキテクトに相談したい」というとき、以前はそれぞれの jira で起票する必要があったのですが、今では統一されたフォーラム上で一度に相談できます。 今後の展望とまとめ このように、GitHub Discussions を利用することで、あまり負担なく便利な社内フォーラムが用意できます。 当初は何人かで集まって「誰に質問すればよいか分からんから俺らで作ろうぜ」と勝手にやっていただけなのですが、投稿されたほとんどの質問は何らかの形で解決でき、上記のような便利な状態を実現できました。これは、運営メンバー外で質問をチェックや運営へのフィードバックをしてくれている社員も多くいてくれたおかげだと思っています。 また、従来はチーム内で閉じていた技術的な議論がチーム外も巻き込んだ形で行われているなど、想定していた以外のところでもうれしい事例も生まれています。引き続きよりよい開発文化のために貢献できればうれしいです。 最後に、LIFULL では一緒に働くエンジニアの募集をしています。この記事だけでは普段の開発の様子は分からないと思いますが、ぜひほかの記事も読んで興味を持っていただけたらうれしいです。カジュアル面談もあります。 hrmos.co hrmos.co