どうも エンジニアの「市場価値」を向上する をキーワードに活動している @サム です。今回は LIFULL HOME'S におけるLINEを活用した施策「 LINEで新着物件通知を受け取る 」を紹介したいと思います。 なぜやるのか 不動産は年末から３月末にかけて住み替えシーズンのため、毎日のように新しい物件が LIFULL HOME'S に公開され、選べる物件の数も増えています。 この時期は住まいを探す人も増え、この記事を読んでくれているあなたも同じ経験があったのではないでしょうか。 物件を探す方法はいくつもありますが、基本はエンドユーザが自ら LIFULL HOME'S などの検索サービスを利用する、いわゆる「能動的」なものになります。 住まいに希望する条件は変わらなくても、検索しないと新しい物件に関する情報は手に入りません。 そこで LIFULL HOME'S では新着物件をお届けする「 新着物件お知らせメール 」という機能があります。しかしこの機能を使うにはメールアドレスの登録が必要になるため、Webサイトでの登録が必要だったりといくつかの手順をおこなう必要があります。 とても便利な機能ですが、利用するまでに必要な煩わしさやメールアドレスを登録しなければならない敷居の高さがネックとなっております。 そこで LINEを活用することで次の利点があります 。 簡単に登録できる 使い慣れたLINEを利用できる スマートフォンに最適化されたデザイン LINEで新着物件通知を受け取るとは その名前のとおり、 毎日決まった時間に希望に沿った物件をLINEでお知らせしてくれる機能 になります。 LIFULL HOME'SのWebサイトを使って物件を探した際に、希望に沿った物件がその日に見つからなかったとき、次の考えに繋がることが多いと思います。 諦める 希望の条件を緩めて改めて検索する せっかく理想とする暮らしに沿った検索条件なのに、その日に 諦めてしまったり条件を緩和すると満足度は下がって しまいます。 しかしいつ理想とする物件が見つかるか分からないのに探し続けるのはそれなりの労力がかかります。 そこで本機能である「LINEで新着物件通知を受け取る」を使うことで、あなたの 希望する条件にマッチする物件が見つかれば「自動的にLINEに通知してくれる」 大変便利な機能になっております。 登録方法 1. 物件一覧ページの「LINEで受取るボタン」をタップ！ 2. LINEで「LIFULL HOME'S」のアカウントを友だち追加！ 3. トーク画面に通知が届いたら登録完了！ どのような仕組みになっているのか この機能を実現するためにいくつかのアプリケーションを横断しています。 この機能の中心にあるのが「 EOS （ Elastic Omni-channel Service ）」と呼んでいるオムニチャネル用のAPIアプリケーションです。 EOSはオムニチャネル戦略を実現するために作られたアプリケーション で、今回はLINEの機能にフォーカスしていますが、いずれはメールやSMS、CRMツールとの連携など、様々なサービスに成長していくものです。 LINEで新着物件通知を受け取るは、エンドユーザのお気に入りの検索条件を圧縮文字列にすることで、複雑になりがちな検索条件を共通で使えるように設計されました。 この設計にすることで、ログインが不要になり住み替えシーズンに間に合うようサービス提供するまでのコストも削減できました。 最後に 今後も LIFULL HOME'S はLINEを活用し、エンドユーザにより便利な機能をお届けしていきます。 もちろんオムニチャネル戦略としてLINEだけではなくSMSやメールなど様々なチャネルを利用し、エンドユーザ１人１人に沿ったサービスを開発していきます。 サービスを開発することでエンドユーザが理想の住まいに出会えるよう手助けできればと思います。 告知 LIFULL では Ltech という LIFULLエンジニアが中心となってエンジニアの技術欲を満たすような実例を交えた勉強会 を開催しています。 コロナ禍でもZOOMを使ったオンラインで開催するなど、今後もLtechを積極的に開催していきますのでぜひ気になった方は、connpassでメンバー登録をよろしくお願いします！ lifull.connpass.com twitter.com

プロダクトエンジニアリング部の佐藤です。 今回はLIFULLの開発において実際に使われている技術スタックの一例としてLIFULL HOME’S 引越し手続きを紹介いたします。 LIFULL HOME'S 引越し手続きとは Nuxt.js TypeScript Context Nuxt Community 認証 Nuxt 3に向けて まとめ LIFULL HOME'S 引越し手続きとは 住み替えの際、各事業者(電気・ガス・水道)の住所変更手続きを一括で申請できるサービスです。 主なシステム構成はこちらです。 Nuxt.js GAE(Google App Engine) Firebase 今回はNuxt.jsについてどのように活用しているか見ていきます。 Nuxt.js LIFULLでは新規でのフロントエンドの開発においてNuxt.js(Vue)での開発事例が増えてきています。 serverMiddlwareプロパティにおいて各APIのBFFとしてexpressを使うこともあります。 nuxtjs.org serverMiddleware プロパティ - NuxtJS TypeScript TypeScriptを採用しています。 yarn dev での開発時に素早くフィードバックを受けられて便利です。 www.typescriptlang.org Vue 3以前のプロジェクトではクラススタイルでNuxt Property Decoratorを使い、TypeScriptでVueファイルやVuexを記述しています。 https://github.com/nuxt-community/nuxt-property-decorator Context Nuxt.jsのContextではこちらの図を参照することが多いです。 ja.nuxtjs.org Contextからstoreやredirectなどの便利なメソッドやパラメータを利用できます。 コンテキスト - NuxtJS Nuxt Community Nuxt Communityのpackageを積極的に使い、エコシステムの恩恵を受けています。 github.com 主に以下のpackageを採用しています。GTMやサイトマップなどの車輪の再発明をなくし、機能の作り込みに集中できると実感しています。 @nuxtjs/device @nuxtjs/gtm @nuxtjs/sitemap @nuxtjs/pwa 最新のNuxt.jsを使い始めれば、@nuxt/componentsや@nuxtjs/dotenvなども取り込まれており、Nuxt.jsのDX(Developer Experience)が良くなり続けていることを実感できます。 認証 認証周りでは以下のようなnpm packageを活用しています。 express-session openid-client passport 関連してOAuth 2.0やOpenID Connectについて知る機会もあります。 https://tools.ietf.org/html/rfc6749 https://openid.net/connect/ Cookieの管理ではSameSite属性を意識しています。 HTTP Cookie の使用 - HTTP | MDN Nuxt 3に向けて これからの開発では @nuxtjs/composition-apiを使用してvue 3のcomposition-apiでの開発を進めています。 github.com Composition APIのドキュメントを参照しながら、新しい記法にも慣れていきたいですね。 Composition API | Vue.js まとめ 今回は実際にWebサービスを開発していて、どんな技術を意識しているのか見てきました。 LIFULLのWebエンジニアは日々技術のキャッチアップを行い、UXやDXの高いアプリケーションを開発することで、エンドユーザーや開発者などすべてのステークホルダーに取って良いWebアプリケーションの構築を進めています。 カジュアル面談もやっていますので、プロダクトエンジニアリング部のビジョンである「 強い個人・最高のチームになることで、価値創造を加速させ続ける 」や、LIFULLが目指している「 あらゆるLIFEを、FULLに。 」に興味がある方は是非お話しましょう！ hrmos.co

輪読会のテーマと題材 なぜ輪読会か 学習効率を高める工夫 3つのパート 1枚プレゼンテーション 振り返り(気付きと疑問点) 簡単なクイズ まとめ iOSアプリ開発チームの池田です。 iOSアプリチームでは週1回1時間という時間をとって定期的に輪読会を開催しています。こちらの輪読会の内容と、学びの効率を高めるために工夫していることについてご紹介できればと思います。 輪読会のテーマと題材 今回のチーム内での輪読会のテーマは「通信関連の基礎固めと一貫した知識の習得」です。 iOSアプリ開発の施策を進めている中でネイティブアプリのフロント側での開発が多くなっており、インフラ関連の知識に触れる機会が実務でかなり少なくなっていました。 こういった機会が少ないことでメンバーの中でのインフラ関連の知識について、なんとなく理解しているけど固まっていない、知識が断片化しているといった状況が生まれていました。 この状況を改善するためにインフラ関連の知識、その中でも土台となる通信関連の知識をつけようということで上記のテーマが採用されています。 また、このテーマに合う題材として「ネットワークはなぜ繋がるのか 第2版」を選んでいます。「ネットワークはなぜ繋がるのか 第2版」では通信に関して、ハードウェアの部分から、ソフトウェアの部分まで幅広く扱っており、基礎固め、一貫した知識の習得に合う題材です。 ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識 作者: 戸根 勤 発売日: 2007/04/12 メディア: 単行本（ソフトカバー） なぜ輪読会か 基礎固め、一貫した知識の習得という目的を考えると本を利用した学習が最適だと考えチーム内で話し合った結果、輪読会形式での開催を決定しています。 何かを題材にして実際に手を動かす、本以外の題材での学習なども検討していますが、実際に手を動かすことは動くものができることでなんとなく理解してしまうことが懸念され、本以外での学習は情報の断片化が懸念されます。 そういった懸念がなく、本を利用した輪読会形式がテーマには合っており採用になっています。 学習効率を高める工夫 学習効率を高める工夫として、復習を短サイクルで多くできるようにしています。その他としてただインプットするだけでなくアウトプットに繋げる、制約を作ることによって練度を高めるといったことを取り入れています。 それらを実現するために3つのパートで輪読会を構成しています。これらの中身について説明していきます。 3つのパート 1回の輪読会を構成している3つのパートは以下になっています。 1枚プレゼンテーション 振り返り(気付きと疑問点) 簡単なクイズ 1枚プレゼンテーション 1枚プレゼンテーションでは個々人で輪読会開催日までに対象になっている章を読んできて、その内容を何かしらの形式でA4用紙1枚にまとめてきます。 まとめ方は個々人の自由になっており、図示や手書きでまとめるメンバーもいればテキストベースで要点をまとめるメンバーもいます。 こうしてまとめたサマリを各々輪読会開催日にプレゼンします。 1枚のサマリにまとめることでただ読むだけではなく、考えてアウトプットすることに繋がります。また、制約として1枚にコンパクトにまとめなければいけないことで、何度も考え要点を絞る必要が出てくるため、自分の中での復習と情報の整理に繋がり、練度が上がってきます。 更にそれをプレゼンする必要があるので、人に説明できる形にするという部分でも練度が上がっていきます。 チーム内には3人のメンバーがおり三者三様のプレゼンをするため、自分がまとめている情報からの差異も生まれるためプレゼンを聞くことも復習に繋がります。 振り返り(気付きと疑問点) 振り返りの中では、各々がサマリをまとめる中で感じた気付きや疑問点の抽出を行いこれも輪読会内で発表します。 この振り返りの中では、断片化していた知識が繋がったことに対する気付きや、理解しきれなかった疑問点などが発表されます。 理解しきれなかった疑問点については会の中で議論され、疑問解消と腹落ちに繋がります。 気付きや疑問点を持ったメンバー以外も、自分になかった視点で改めて学んだ情報を見ることになるので、より深い理解に繋がります。 簡単なクイズ 簡単なクイズパートでは、前回の輪読会で学んだ範囲について独断と偏見による復習クイズが出題されます。 ここでは単純な復習もあれば、本の中身の情報だけではないより発展的な部分まで触れたものについても出題されます。 例えばDNSの説明がされている章では、「AWSが提供しているDNSサービスはなんでしょう？」のようなクイズです。 本の中ではクラウドサービスの情報は触れられていないため、本の内容から広げて知識習得に繋がるようこういったクイズ出題をしています。 このパートでは1週間で抜けかけている情報を再度復習することによる知識の血肉化、知識をただ得るだけではなくそこから更に広げるという部分に繋がってきます。 まとめ iOSアプリ開発チームで進めている輪読会で採用している学習効率を高める工夫、それを実践するパートについて紹介させて頂きました。 クイズパートをやる中で、パッと出てこないけどこんな話あったなという内容があったり、覚えている内容が本来の回答と微妙にずれていたり、1週間という期間でも復習が大切なことが痛感されました。 今後の輪読会やその他スキル向上に繋がる施策の中でも復習をうまく重ねられるような仕組みを取り入れながら、同じ時間の中でも学習効率を高められるように工夫して進めていければと思います。 輪読会や、スキル強化に繋がる取り組みをされる中で何かの参考になれば幸いです。

こんにちは。エンジニアの加藤です。 普段はLIFULL HOME'Sの注文住宅領域にてエンジニアグループのマネジメントを担当しております。 マネジメントに携わり3年目となりますが、エンジニア組織の成果を定量的に測る難しさを常に感じておりました。 そのような中、今期より全社的にKPIマネジメントが導入され、その考え方を元に自身の担当するエンジニアグループとして目指すべき指標が明確化されたため、今回はその内容を紹介したいと思います。 KPIマネジメントについて 弊社では中尾隆一郎さんが提唱するKPIマネジメント（ 最高の結果を出すKPIマネジメント ）を取り入れており、そちらには以下の4つのメインキャラクタ（ 4MC ）が定義されています。 Goal 最終的に目指すべき状態。 KGI Key Goal Indicator = 重要目標達成指標 最終的に期末に到達したい最も重要な目標数値。 CSF Critical Success Factor = 重要成功要因 最重要プロセス = 事業成功の鍵。 KGIを達成するためにいくつかあるプロセスの中から、最も重要なプロセス。 KPI Key Performance Indicator = 重要業績評価指標 KGIの先行指標であり、CSFの数値目標。 最も重要なプロセスであるCSFをどの程度実施すれば、期末にKGIを達成できるかを表した数値。 KPIマネジメントでは上記4MCの関係性を理解したうえで適切に設定し、運用・計測・改善することが重要となります。 グループ目標としての4MC KPIマネジメントを構成する4MCに対し、私たちのグループでは以下のように設定致しました。 Goal 開発生産性の向上 KGI 開発生産力 = 価値創出数(= Pull Requestマージ数) / 開発に関わるコスト(= 人件費 + 業務委託費 + システム利用料) CSF 1タスクにかかる開発速度の向上 KPI Pull Requestマージ数 これらの4MCを選定したプロセスを紹介していきたいと思います。 Goal・KGIの選定 まずGoalとKGIについてですが、弊社では各組織単位においてそれぞれ4MCを設定し、KPIマネジメントの運用を行っております。 そのため、私がマネジメントするグループの上記組織であるユニット・部においても同様に4MCの設定がなされております。 そこで、ユニット・部を含めた組織全体として同じ方向性を持ち意識を揃える意図として、最終的な目標であるGoalとKGIは上位組織を踏襲することと致しました。 ただし、目標を達成する上での課題や状況、最適なプロセスは組織ごとに異なると考えられるため、Goalに対しての手段（CSF、KPI）はグループとして検討を行います。 CSFの選定 中尾さんの提唱するKPIマネジメントではCSFを選定する上でのポイントは以下のように言われております。 現場でコントロールでき、努力で変化するプロセス（季節要因、外的要因などは排除） 実行していればGoalに繋がるプロセス 複数候補の中から一番弱いプロセス これらを踏まえCSFを選定するにあたり、まずはKGIを構成する要素を分解し以下の2つをCSFの候補として比較致しました。 価値創出数 開発に関わるコスト 開発に関わるコストは人件費やシステム利用料などであり、ある程度固定費としてかかるため、価値創出数に対し現場の努力により変動する幅の狭い要素であると判断しました。 そのため、この時点で開発に関わるコストはCSFの候補から除外し、 価値創出数を増加 させるプロセスを深堀りすることと致しました。 KGIの要素である価値創出数はPull Requestマージ数に置き換えているため、Pull Requestマージ数の増減に影響する要素を以下のように分解しました。 実開発時間(= 総業務時間 - 運用時間 - ミーティング時間 - 社内行事時間) / 1タスクあたりの開発時間 * 1タスクあたりのPull Request数 これらの要素に対し分析を行い、最終的なCSFの決定を行います。 総業務時間 総業務時間を増加することで価値創出数が増加 各メンバーの業務時間を単純に増やすことで総業務時間を増加できる ただし業務時間の増加 = 残業時間の増加となるため、 本質的でなくCSFには適さない 運用時間 運用時間を削減することで価値創出数が増加 運用業務の削減、効率化、自動化することで運用時間の短縮を図ることができる 体感として運用業務が発生することで意識が分散し、実時間以上に生産性の妨げになっている可能性がある しかし、日次採算システム上、全体に占める割合は約5% 改善すべきポイントではあるが、 最重要プロセスとはいい難い ミーティング時間 ミーティング時間（以降MTG）を削減することで価値創出数が増加 不要なMTGの廃止、必要なMTGのみへの参加、MTGの効率化などにより削減可能 ただし日次採算システム上、全体に占めるMTGの割合は13%ほど 在宅勤務により必要なコミュニケーションも存在するとの考え方もあるため、 一番弱いプロセスとしては考えづらい 社内行事時間 社内行事時間を削減することで価値創出数が増加 社内行事時間は全社的に設けられているイベントに対しての時間のためグループとしてコントロールしづらい そのため極めて定数に近い要素となるため、 CSFには適さない 1タスクあたりの開発時間 1タスクあたりの開発時間を削減することで価値創出数が増加 開発タスクに着手してから完了となるまでのリードタイムを削減する 実行するためには開発プロセスの改善やシステム基盤の整備（リファクタ、リプレイス、仕組み化、標準化など）など様々なアプローチが考えられる エンジニアに裁量があり、主体となって実行する部分であるためコントロールがしやすい 現状システムの複雑性や技術的負債が開発生産性を妨げている大きな要因となっている これらにより考えられるアプローチを実行したうえで開発時間を短縮することが、 最も重要なプロセスであると考える 1タスクあたりのPull Request数 1タスクあたりのPull Request数を増加することで価値創出数が増加 レビュアーの1回のレビューにかかる負担を減らすなど開発生産性の向上に対しての一定の効果が表れる可能性がある ただ1タスクあたりのPull Request数を上げることだけを最重要プロセスとして捉えると、小手先での調整でも可能となり、本質的な取り組みから離れてしまう懸念がある そのため、ここでは CSFの対象としては除外する 上記より、最終的に私たちのグループでは「 1タスクにかかる開発速度の向上 」が最重要プロセスであると捉え、CSFとして選定しました。 また、弊社では以前より日次採算システムを全社的に導入しており、一人ひとりが各業務ごとにどれだけ時間を費やしているかを計測しております。 体感では運用業務に多くの時間を費やしている印象もありましたが、実際に計測数値を確認してみると割合としては少ないと分かったことから、事実を元に分析をする上でKPIマネジメントと日次採算システムの組み合わせの有効性の高さを感じました。 KPIの選定 CSF同様、KPIにも選定する上でのポイントがあり、以下のように言われております。 シンプルで分かりやすい指標 CSFとの整合性が取れている指標 現場でコントロール可能な指標 即座に計測・入手できる指標 CSFは1タスクにかかる開発速度の向上であるため、それを計測する指標としては1タスクあたりの開発時間がKPIとして考えられます。 しかし、現状では各開発タスク毎にどれだけの時間がかかっているかを正確に計測する仕組みがなく、「即座に計測・入手できる指標」であるという部分にマッチしません。 また、計測に際しての運用も複雑になる懸念があるため、現状KPIとしては適さないと判断し、別の指標を検討致しました。 そこで、1タスクにかかる開発速度の向上を計測する指標を選定するため、改めて価値創出数を算出する要素を確認します。 価値創出数(Pull Requestマージ数) = 総業務時間 / 1タスクあたりの開発時間 * 1タスクあたりのPull Request数 ここで各要素に着目し、それぞれ定数と変数に分類しました。（ 青：定数 、 赤：変数 ） 定数と変数に分類したことにより、1タスクあたりの開発時間の変化に比例して、Pull Requestマージ数が増加すると捉えることができると思います。 そのため、Pull Requestマージ数がKPI候補となり得るのではないかと考え、KPI選定のポイントと照らし合わせても以下の理由で最適であると考えました。 シンプルな値で分かりやすい 上記の式によりCSFとの整合性が取れている （開発時間の短縮を）現場の努力で改善可能 ダッシュボードより既に容易に計測可能 上記より、最終的に私たちのグループでは「 Pull Requestマージ数 」をKPIとして選定しました。 ただし、このKPIには注意点も存在します。 総業務時間と1タスクあたりのPull Request数が定数であることが前提であるため、この2つの要素が現状から大きく変化する場合、正しく成果が計測できないこととなります。 そのため、定期的に上記2つの数値は確認をし、変化が大きい場合はKPIを見直すことをルールとして定め運用します。 KGIとKPIの目標値について KPIマネジメント導入の初年度ということもあり、今期に関しては現状からの105%成長で設定しました。 2020/10〜2020/12をサンプリング期間として定め、こちらの期間の3ヵ月の平均値をベースに105%成長した数値を目標値として設定し、2021/1〜2021/9までの9ヵ月間の平均値にて計測します。 目標値を平均値としている理由には、繁忙期やプロジェクトのフェーズにより数値のばらつきも発生すると考えられるため、平均して一定のパフォーマンスが発揮されているかを測る意図があります。 まとめ 以上が私の担当するエンジニアグループがKPIマネジメントの考え方を元に目標指標と定量的な目標値を導いた内容となりますが、まだスタートラインに立った状態であると思います。 今後、設定した目標に対し実行・計測・改善を繰り返し、より生産性の高いエンジニア組織へと成長していきたいと思います。 今回の記事を通じ、私と同じようにエンジニア組織の定量的な成果計測に悩む方の一つのヒントになれば幸いです。

こんにちは。エンジニアの松尾です。 私がエンジニアチームのマネージャーになって1年が経過しました。日々の仕事に慣れてはきたのですが、徐々に部署内外で引き受けるタスクが増えてきたことで重要度が高いタスクの消化が難しくなってきていました。 そこで、LINE株式会社のブログで共有されていた下記の記事を参考に、ワークショップ形式で仕事の見える化と棚卸しに取り組みました。 引き継ぎのスムーズ化を図るため、LINE企画室が行った「お仕事解体ワークショップ」とは？ 今回は 「メンバーによる私の仕事の棚卸し」 と 「上司の仕事の棚卸し」 の両方に取り組んでみたので、する側/される側の両面についてまとめてみたいと思います。 やったこと メンバーによる私の仕事の棚卸し きっかけ メンバーとの1on1で私とメンバーの仕事量のバランスについて話していたときに 前述の記事 が話題にあがり、「今持っている仕事をもっと引き継いでも良いのでは」という話になりました。ちょうど組織が変更されて新しいメンバーが私の部署に合流したタイミングでもあったため、自部署の仕事を洗い出す意図も込めてワークショップの開催を決めました。 仕事の洗い出し マネージャーしか知らないこと、メンバーしか知らないこと、のように「自分が抱えこんでいるタスク」を積極的に付箋に書き出しました。各自の手が止まっていく中で私の付箋書き出しが淀みなく進む光景を見て、メンバーからは「そんなことやってたんですか…」という声もあがりました。 引き継ぎする項目の決定 書き出した後には付箋を色で分類します。今回は黄色をデフォルトとして 「ほかの人にやってほしい（引き継げそう）」 をオレンジに、承認作業のような 「誰にも引き継げない」 を青に変更しました。 分類された私の仕事 次に、引き継げる可能性のあるタスクを うれしみ（引き継げるとうれしい） と ムズみ（引き継ぐのは難しい） の2軸でマッピングしました。 マッピングされた私の仕事 記載内容の詳細や不明点についてはメンバーからの質問に応じて説明していきました。 引き継ぎ内容の決定 マッピングの結果を見ながら、KPTのTryを決めるようなイメージで取り組みを決めていきます。例として下記のような対応がメンバーの意見で決まっていきました。 MTGのファシリテーション -> 特定メンバーに委譲/輪番制 外部からの問い合わせ窓口 -> チケット発行と割り振りのしくみ作り 手作業で行っていた運用作業 -> プログラムによる自動化 各種ソースレビュー -> チームの階層を作って分散 解体されてみると「こんな簡単に引き継げるのに、なんで1人で抱えてたんだろう」という気持ちになります。 上司の仕事の棚卸し きっかけ 私自身の手が空いたことで少し余力ができたので、そのぶん上司の仕事を巻き取ることもできるのではと思い立ちました。上司の立場の仕事を見ることでより高い視座を持って現状の仕事に取り組みたいという意図もありました。 ワークショップの内容 私を対象にしたときとほぼ同じ内容でしたが、「 Google Jamboard ではスペースの制限が厳しかった」というふりかえりを活かして miro を利用しました。 私の上司は組織のマネージャーでありエンジニア職のマネージャーでもあるため、部署以外でも採用や組織開発といった役割を担っています。そのため、タスクを洗い出したうえでまずカテゴリ（ロールに近いもの）を分類しました。 分類された上司の仕事 これらを俯瞰し意識しつつ、うれしみ/ムズみマッピングに付箋を置いていきます。 マッピングされた上司の仕事 採用や組織開発など引き継ぎの難しい仕事が多かったので、ムズみの強くないものを積極的に引き継ぐ（なくす）結果となりました。意外と単純な作業もあるので下記のような対応をしていく予定です。 承認作業: 権限を委譲して代理できる人を明記 自部署全体ミーティングの仕切り: 段取りをまとめて引き継ぎ ルーチン、単純作業: リマインド設定、自動化 わかったこと あくまでも弊社で実践してみた一事例ではありますが、私が体験した両方の立場で感じたことをまとめます。 解体される立場での気付き 🙅‍♂️ タスク量を客観的に見て管理できていない 自分のタスクの量を過去のピーク時と比較して調整しがちであることに気付きました。 本来はチーム内でのバランスや心の中でのうれしみも踏まえて割り振るべきなので、基礎的なことではありますが取り組み方を変えようと思います。実施前より人にタスクを渡す判断の材料が増えたと感じています。 🙆‍♂️ 意外と引き継ぎはWin-Winで着地できる 引き継ぎ先の仕事を増やしてしまうのが申し訳ないと思っていましたが、取り組み方と工夫によってプラスにもなることがわかりました。 たとえば私は朝会のファシリテーションを雑務ととらえて積極的に誰かに渡すことをしませんでした。ところがあるメンバーは「リモートで話す機会が減ったので、ほかの人に直接語りかける機会は貴重」ととらえて取り組んでくれているようです。 解体する立場での気付き 🙅‍♂️ 自分から見えないタスクは想定以上に多い 本人が「これは自分の仕事だから」と（悪く言うと）思考停止して外に出していないタスクがあり、チーム全体で見ると無駄につながっているケースが意外とあることに気付きました。 引き継ぎの可能性を自身で判断せずにまずは洗い出せるという点は、このワークショップの良さだと感じました。 ️🙆‍♂️ 見えるようになっただけでも価値がある 権限やスキルの問題で引き継ぎが難しいことも多々あります。ですが現時点でのタスクをほかの人に割り振れなかったとしても、新しく増やさないように対策を練ることはできそうです。 また、メンバーが将来同じ立場になることも考えられるため、その仕事を事前に見て体感できるという点でも価値があると思います。 次やること 定期的に仕事を棚卸しする機会を設けることが重要だと感じました。特に組織が変更されるタイミングとの相性が良さそうですので、今後も折を見てワークショップを開催していきたいと思います。 一方でワークショップを高頻度で開催することは難しいです。朝会での共有やかんばんの活用などを個々人に任せ過ぎず、日ごろのタスクを正しく可視化していければと思います。 まとめ 仕事を渡すのが苦手な人はマネージャーに限らずたくさんいると思います。そんな人も今回紹介したワークショップのように、何らかの機会を作ってぜひ引き継ぎを検討してみてください。 ちなみに、私の仕事を解体するワークショップの企画と進行はまるっとメンバーがやってくれました。快く引き受けてくれたメンバーには感謝しています。 これによってさらに良いチームを作ろうと気持ちも引き締まったので、メンバーにも別の何かで還元していければと思います。

QAグループの星野です。 昨年の2020年11月に公開された『LIFULLのQAの取り組みについて』にてQAグループの主だった活動について紹介されました。 本記事では、こちらで概要だけ紹介されている"リリース前リスク分析を起点としたQAのアクション"についてご紹介致します。 QAが プロジェクトメンバーとして参画していないプロジェクト を対象とした取り組みになります。 www.lifull.blog また、今年2021年1月にはそれらの活動の中からテスト計画の作成を行う『テスト計画コンシェルジュ』について紹介がありました。 QAがプロジェクトに対して直接的にアプローチする取り組みについてはこちらの記事をご覧ください。 www.lifull.blog RiskManagementNoteについて なぜ行っているか どんなことをしているのか どう行っているのか ET検討会について なぜ行っているか どんなことをしているのか どう行っているのか まとめ RiskManagementNoteについて なぜ行っているか LIFULLでは設計や実装を行っているエンジニアたちがテストにも責任を持っています。 テスト設計や実施のみを専門としている組織は存在しません。 よって、すべてのプロジェクトにQAチームが必ずしも直接的に関与する必要がありません。 しかし、自分たちの関わっていないプロジェクトで本番障害が発生しユーザーへ不利益が発生したときに「関係ありません」と知らんぷりは絶対にしません。 自分たちが直接的に関わっていてもいなくても、本番障害を自分たちで防げる可能性があったなら責任があると考えています。 大きなリスクを抱えたプロジェクトになるべく気がつけるように各開発部署の情報を抽出し、人の目で改修要件や仕様書を確認しています。 どんなことをしているのか 抽出したチケット情報からプロジェクトのドキュメントを参照して改修要件などを確認します。 基本的にはプロジェクトの比較的序盤、改修要件が定まっている段階のものが調査対象になります。 改修内容や影響範囲やリリースの予定日など様々な情報をまとめ、 調査/分析した結果をQAチームで確認し、なにかしらの対応が必要かどうかを検討しています。 どう行っているのか プロジェクトの情報を見ながらリスク、特にプロダクトリスクを考えます。 改修箇所で問題が起こった場合に「重要度：システムの機能への影響」「優先度：低下するシステムの価値」「発生確率：遭遇し得るユーザーの規模」の3軸で定量的に数値を出します。 それに加え、改修要件を見ながら「テストは十分に検討されているか」「過去の障害から予測できる障害はないか」「他プロジェクトと改修範囲がバッティングしていないか」「自動e2eテストで検知できるか」などを考えながら定性的なリスクを挙げていきます。 これらの定量的、定性的な情報からプロジェクトへQAが関与するかどうかを判断しています。 ET検討会について 続いてET検討会についてです。ETというのはExploratory Testingの略称で、探索的テストを指しています。 RiskManagementNoteではプロジェクトの比較的序盤で調査をしているのに対し、ET検討会ではリリース直前のものを対象に扱います。 なぜ行っているか 私が入社した時点ではRiskManagementNoteのみで、ET検討会は行われていませんでした。 あるとき、リファクタリングやSEO対策のための小さなプロジェクトが増え始め、1日にリリースされるプロジェクト数が大幅に増えた時期がありました（多い日には1日に30件程度リリースされていた）。 開始からリリースまでの期間が短い小さなプロジェクトが増えたことで、 RiskManagementNoteのチケット調査では網から漏れて掬い上げられないプロジェクトが出てきたり、 QAがRMNの検討フェーズに入った時点でリリースを翌日に控えているなど対応が追いつかなくなってきました。 また、小規模なリリースとはいえ、それだけの数がリリースされるとなると統合時に何があるかわかりません。 開発チームがテストをしていると言っても、他チームのリリースによる影響まで考慮して見ることは難しいためQAが水際作戦でケアすることにしました。 リリースについてはチケットで管理されているため、RiskManagementNoteで網から漏れてしまったプロジェクトもここで拾い上げることができます。 どんなことをしているのか 当初はリリース周りのチケットを手動で集めていましたが、現在は自動的に抽出し何件のリリースが控えているのかをbotが教えてくれます。 こちらもRiskManagementNoteと同様に「どんな障害が起こり得るか 」「類似する障害はないか」「テストは十分に行われているか」などの観点でプロジェクトの情報を確認します。 他、ET検討会が始まったときの「同時にリリースされる施策で衝突しそうなものはないか」といったものも気にしています。 どう行っているのか ここで対象とするものは翌営業日にはリリースされてしまうため、その日のうちに探索的テストを実施します。 開発チームが所有する環境で既に開発チームによるテストは実施されており、 QAが確認する環境はそれとは別のテスト環境であるため、開発チームのテストには影響がありません。 また特別な環境の準備も不要なので自由なタイミングで実施することができます。 リリースを止める際にも判断含め時間が必要になるため、QAチームはなるべく迅速に探索的テストに取り掛かります。 そのため、(少なくとも自分は)チャーターを入念に準備することはあまりせず、挙げたリスクを中心に実施しています。 まとめ QAの間接的なプロジェクトへのアプローチをご紹介しました。 プロジェクト内のエンジニアがテストに責任を持っているとしても、（少なくとも私は）QAが不要になることはないと考えています。 冒頭で直接的なアプローチとしてご紹介している テスト計画コンシェルジュ などの取り組みも含め、 開発チームが自分たちのつくりたいものに注力できるように、出来上がるものがより良いものになるようにサポートするのがQAの役目だと感じています。 LIFULLのQAチームはテストの設計や実施のみを専門とするような組織ではなく、 横断的な組織だからできること、開発したエンジニアがテストに責任を持っているからできること、 そういった「自分たちだからできること」とET会が始まったように「状況に応じて必要な行動を取ること」を大事にしているチームだと思います。 ここに書いている取り組みが、読んでくださっている方々の組織にそのまま適応できるかはわかりませんが少しでも参考になれば幸いです。

技術開発部の清水です。好きな食べ物は 広島風 お好み焼きと 広島県産 牡蠣と 広島県産 穴子です。 拡張に次ぐ拡張でサービスは便利なものに成長していく一方でソースコードは次第に複雑になっていきます。 そのまま放っておくと積み上げた技術的負債により開発コストが上がっていき、最悪の場合にはサービスの発展を停止させてしまう可能性もあります。 このような理由から、弊社では技術的負債を着実に返済していくべく生産性・技術的負債の可視化をMetabaseで行っています。 可視化する情報元はGithub API、CodeClimateQuality APIの2つのみです。 生産性の可視化 本流ブランチにマージされたPR数（生産数） 本流ブランチにマージされたPRによる意味のある変更行数（生産規模） 本流ブランチにマージされたPRの平均レビュー応答数（生産を助けた人員の労力） 本流ブランチにマージされた「1コミッターあたりの」PR数（1生産者あたり生産数） 開発者のコミッター・レビュアーとしての行動バランス 技術的負債の可視化 技術的負債の現況と現在に至るまでの推移 REMEDIATION_TIMEを自分ごとにできるようにする 本流ブランチにマージされたPR別のREMEDIATION_TIMEの推移 コミッター別REMEDIATION_TIME変動累積値 効果の高いリファクタリング対象ファイルの選定 おわりに 生産性の可視化 本流ブランチにマージされたPR数（生産数） 開発者にとって 生産性 とは何でしょうか。様々なご意見が予想されますが、生産性ではなく 生産数 ということであれば 本流ブランチにマージされたPR数 は開発者が身近に感じやすい一つの指標かと思います。 本流ブランチにマージされたPR数 PRは「 ある要件を満たすためにまとまったソースコードの変更」 であると言えますし、本流ブランチにマージされて初めて価値を生み出すという特徴があります。但し、これを「生産性」と結びつけるためにはいくつかの要素が加味されていません。PRの規模は大小様々ですし、PRをレビューした人員のコストも様々で、期間内に何名のコミッターが活動したのかも様々です。これらを可視化していきます。 本流ブランチにマージされたPRによる意味のある変更行数（生産規模） 意味のある変更行数というのは、空行やコメントなどを除いた行数です。 変更行数の多いPRは 切り戻しの難しさ もありますが、 レビュアーのレビューコストを増幅 します。 適切な粒度に分割できるようになると、レビュアーは少ない変更に集中してレビューすることができ、ひとつの生産にかける時間の総合を短縮することにつながります。 本流ブランチにマージされたPRによる意味のある変更行数 本流ブランチにマージされたPRの平均レビュー応答数（生産を助けた人員の労力） PRをマージするまでの期間に、 コミッター・レビュアー間でコメントの応酬を行った回数 です。 本流ブランチにマージされたPRの平均レビュー応答数 レビュアーが即座には受け入れられない疑問や質問の余地のある実装は、レビュアーのレビューコストを増幅するものです。 少ないレビュー応答数でPRがマージできるようになるような、わかりやすい実装やレビュー依頼は、レビュアーの労力を下げますし、ひとつの生産にかける時間の総合を短縮することにつながります。 本流ブランチにマージされた「1コミッターあたりの」PR数（1生産者あたり生産数） 前述した 「本流ブランチにマージされたPR数（生産数）」をその期間アクティブであったコミッター数で割った値 です。 生産数が順調に増えていたとしても、人員が増えたことによる結果なのであれば、アプリケーション起因の生産効率は変わっていないと考えられます。 本流ブランチにマージされた「1コミッターあたりの」PR数 100人で100PRをマージできる状態と、50人で50PRをマージできる状態では、生産効率はともに1とし 100人で200PRをマージできる状態は2であり、100人で100PRをマージできる状態に比べて2倍の生産効率であるという考え方です。 （=少ない人数でも多くのPRをマージできる状態が生産性の高いソースコード） この値がより大きく「本流ブランチにマージされたPR数（生産数）」も大きいのであれば「生産量・生産性ともに上がった」と言えるではないでしょうか。 （ただし、その変更の内容が設定ファイル・READMEの変更のみである可能性もあるため、PRの変更内容から判定し、それらを除外する必要はあります。） 開発者のコミッター・レビュアーとしての行動バランス ある開発者は実装ばかりを、ある開発者はレビューばかりをしている という状況はよくあると思いますが、そのような状況が続くと 属人化 の可能性が高まります。 コミッターの集中、レビュアーの集中を避けられるように、開発者のコミッター・レビュアーとしての活動バランスを、全体の開発者における相対的な分布図で表しています。 開発者のコミッター・レビュアーとしての行動バランス 水色の丸ひとつひとつが開発者で、X軸がコミッターとしての生産活動数、Y軸がレビュアーとしての生産活動数になります。丸の大きさは変更行数に比例し、コミッターとしての活動数が少なくても、その1つの開発が巨大である場合には大きく表示されます。実際にはカーソルをあわせると開発者名が表示されますが、ここでは伏せています。よりバランスの良い状態（左下から右上への直線に近似する状態）を、チーム全体で目指していくとチームとして開発者の活動バランスが高く、属人化がされていないと予測されます。 ここまでが「生産性」に関する指標です。いかがでしょうか。 これらの情報は全てGithub APIから取得した情報を元に可視化が可能です。 続いて 「技術的負債」 に関する指標です。 技術的負債の可視化 技術的負債の情報はCodeClimateQualityのAPIから取得した情報を元に可視化しています。 codeclimate.com 技術的負債の現況と現在に至るまでの推移 下記はあるプロダクトにおける技術的負債の推移を月次・週次・日次・PR別という粒度で推移グラフを出力したものです。 技術的負債の現況と現在に至るまでの推移 上段は現況を表し下段は現在の数値に至るまでの月・週・日・PRマージ別の推移を表しています。 ここではまず、そのRepositoryの技術的負債に関する現況と現在に至るまでの推移を把握することに努めています。 推移グラフの赤線は、 REMEDIATION_TIME（推定修復時間） です。これは健全な状態に直すまでにかかる時間の想定値であり最重要視しています。 緑線は IMPLEMENTATION_TIME（推定実装時間） です。これはこの状態になるまでにかけられた時間の想定値です。 灰線は TECHNICAL_DEBT_RATIO（技術的負債比率） です。これは規模の異なる複数のリポジトリを比較する際に有効な値です。 このRepositoryでは5月から9月まで順調にREMEDIATION_TIMEを減らしていき10月に微増した。 まず、このようなことが言えるかと思います。 なお、これらの指標はCodeClimateQualityの下記の記事で説明されています。 codeclimate.com REMEDIATION_TIMEを自分ごとにできるようにする 多人数で開発するRepositoryの場合、いくら技術的負債を可視化しても 自分ごととして考えづらい という難点があります。 また、その改善結果が正しく見えないことには、モチベーションは上がりづらいと思います。 本流ブランチにマージされたPR別のREMEDIATION_TIMEの推移 「あるPRでは1時間増加、次のあるPRでは13時間削減した」 というPR別のREMEDIATION_TIMEの推移をみることができるようにしています。 ここまでくると、どのPRにより、負債が削減・増加したのかは明らかで、それが自分の実装・レビューによるものであるのかも明らかです。 （画像では説明に不要な具体的な情報は伏せております） 本流ブランチにマージされたPR別のREMEDIATION_TIMEの推移 コミッター別REMEDIATION_TIME変動累積値 「ある開発者が一定期間内に複数の開発を繰り返すことで、ある開発時には100時間増加させたけど、後日別の開発時には200時間削減し総合的にこれまで100時間の削減をおこなった。」 このようなことが後でわかるように、コミッター別REMEDIATION_TIME累積を出力しています。 左は、よりREMEDIATION_TIMEをより大きく削減したPR、右は、コミッター別REMEDIATION_TIME累積を示します。 （画像では説明に不要な具体的な情報は伏せております） コミッター別REMEDIATION_TIME変動累積値 効果の高いリファクタリング対象ファイルの選定 いよいよ技術的負債に問題意識が生まれ、技術的負債の返済に時間をとれることになったとします。 では、限られた時間でまずどのファイルを変更すればいいのでしょうか。 CodeClimateQualityでは静的コード解析上のボトルネックは教えてはくれます。 しかし、当然のことですが静的コード解析であるため 開発プロセスや組織構造、実行順序などを考慮した物 ではありません。 その結果、単純に静的コード解析上のボトルネックに従うばかりでは 「コードは複雑だけどほぼ誰も触らないファイルを全力でリファクタリングしてしまう」 可能性があります。 静的コード解析上の大きな改善とならないとしても、できることなら限られた時間で、より改善効果を感じられるファイルをリファクタリングしたいものです。 高頻度で変更されたり、多くの人に変更されるファイルは、小さな改善数値でも大きな改善結果を感じられるはずです。 このような理由で、変更回数の多いファイル、変更者の多いファイルを各種指標に添えて可視化しています。 （画像では説明に不要な具体的な情報は伏せております） 効果の高いリファクタリング対象ファイルの選定 弊社ではこのようなダッシュボードを様々なRepositoryを対象に出力しています。 複数のRepositoryをこのような同じ測りで比較してみると次第に面白い傾向が見えてきます。 実装量が増えるにつれてREMEDIATION_TIMEも増えるRepositoryばかりではない。 X年しか経過していないがREMEDIATION_TIMEがX年以上増えてしまうRepositoryが存在する。 特定の開発者が物凄い勢いでREMEDIATION_TIMEを返済しているRepositoryが存在する。 特に最後の「特定の開発者が物凄い勢いでREMEDIATION_TIMEを返済しているRepositoryが存在する」このケースの気づきは、 技術的負債を返済してくれた人と功績を可視化 することだと思います。 同じRepositoryを開発する皆に恩恵がある尽力の結果ですので、称賛されるような文化醸成がされていくことでモチベーション向上にも繋がりますし素晴らしいことと考えています。 おわりに エンジニア職以外の方には技術的負債返済にコストをかけるメリットが伝わりにくい と言う声をお聞きしたことがあります。 上記のような重視する指標を提示し、交渉相手の重視する指標を提示してもらい、どのような影響を与えるのかを示すことができれば 技術的負債返済の必要性を理解していただき、交渉が円滑になるのではないでしょうか。 最後までお読みいただきありがとうございました！

こんにちは。Ltech運営チームの井坪です。 今回は、2021年1月18日(月)に開催した『Ltech#13 事業開発エンジニアとは？~実装は甘え~』についてレポートします。 lifull.connpass.com Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。特定の技術に偏らず、様々な技術の話を展開していく予定です。 事業開発エンジニアとは？ 今回のテーマは『事業開発エンジニアとは？』です。 エンジニアと一言で言っても、アプリケーションエンジニアやフロントエンドエンジニア、QAエンジニアなど各方面の様々なエンジニアが活躍しています。 今回はその中でも、『事業開発エンジニア』というLIFULL HOME'S以外の新規事業にフォーカスしたエンジニアの方に語っていただきました！ 3時間でプロトタイプをユーザーにお届け！LIFULLの高速仮説検証プログラムとは？ 3時間でプロトタイプをユーザーにお届け！LIFULLの高速仮説検証プログラムとは？ from LIFULL Co., Ltd. www2.slideshare.net 最初は、LIFULLの新規事業を加速させるための高速なプロトタイプの提供と仮説検証についてです。 以下の3つのプロセスを行い、高速なプロトタイプの提供を行ってます。 ユーザを主語にした仮説を構築(1h) 検証方法の設計(1h) 実装(1h) このプロセスを繰り返し行うことで、仮説検証で結果が出ないままリリースしても結果が出ず、『フェイルファースト』が鍵になることが見えてきました！ 価値のあるプロダクトかどうか検証せず「きっと上手くいくはず」と実装し市場やユーザに対して甘い期待をするのではなく、実装する前に仮説検証を行いプロフェッショナルとして実装に甘えず取り組んでいます。 大規模サイト開発と新規事業開発の経験から見たそれぞれの違い 大規模サイト開発と新規事業開発の経験から見たそれぞれの違い from LIFULL Co., Ltd. www2.slideshare.net 次は、LIFULL HOME'Sと新規事業での開発経験から感じた違いについてです。 ※発表内容は発表者個人の見解になります。 以下の点について、お話していただきました。 開発の優先度 エンジニアの裁量 エンジニアとしての担当領域 PJメンバーとしての担当領域 求められる姿勢やスキル それぞれの良いところ/辛いところ 開発において納期・品質はどちらも重要ですが、新規事業ではある程度の品質を担保しつつより早くリリースすることで、ユーザ検証を行い、事業にスピード感を出すことで競合他社に差を付けるメリットがあるようです！ 新規事業ではメンバーが少ないことが多く、開発は分業できず1人で担当する領域が広く必要なことは判断して対応していく必要があり、求められる姿勢やスキルは、エンジニアリング以外にも事業の成長に必要な企画を考えたり数字を分析したりも必要になってくるそうです。 最後に 今回は、新規事業に取り組む事業開発エンジニアに発表していただきました。 参加者からの方から、新規事業開発時の心構えや当事者の想い、プロトタイプ開発の意義を理解できたなどコメントをいただけ、LIFULLでの事例ではありますが参考になったのではないかと思います。 Ltechでは、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

テスト計画コンシェルジュとは テスト計画コンシェルジュの流れ 1:施策の概要を聞く 2:テストアイテム、テストスコープを明確にする 3:どのテストレベルでテストすればよいか考える 4:テストのアプローチを組み立てる 5:プロダクトリスクを挙げ、そのリスクが考えたアプローチでケアされているか確認する まとめ こんにちは。QAグループの松谷(まつや)です。 みなさんはテスト計画を行なっていますか？ テスト計画では、「どのテストレベル」で「どの対象」に対して「どのようなテスト」をしていくかという、テストのアプローチを定めることが大切です。 このテストのアプローチの有無によって、プロダクト全体としてMECEで効率的なテストになるのか、抜け漏れが多い残念なテストになってしまうかが決まってきます。 今回は、プロジェクトチームと共にテスト計画を作成する「テスト計画コンシェルジュ」をご紹介します。 テスト計画コンシェルジュとは テスト計画コンシェルジュは、横断組織であるQAグループによるテスト計画作成代行サービスです。 プロジェクトチームからテスト計画コンシェルジュの依頼を受け、テスト計画ミーティングを行います。 そのミーティングでプロジェクトチームと一緒にテスト計画を考えます。 このときスケジューリングなどを含めた全ての計画を行うわけではありません。 我々とプロジェクトチームが話し合って、テストスコープを明確にし、互いに腹落ちするテストのアプローチを定義します。 テスト計画コンシェルジュの流れ テスト計画コンシェルジュは、プロジェクトチームから依頼があったときに実施します。 依頼はチケットで管理されています。その際の入力項目は以下です。 施策概要 規模（人数と全体工数） 開発拠点 開発期間 既存リスク このチケットで概要や規模感を把握し、テスト計画コンシェルジュのミーティングをセットアップします。 1:施策の概要を聞く ミーティングが始まりましたら、最初にテスト計画の対象となる施策の概要を聞きます。 施策の全体像を聞き、どういったことを実現したいのか把握します。 依頼チケットでもおおよその概要は把握してから臨んでいますが、認識のすり合わせを行なっていきます。 2:テストアイテム、テストスコープを明確にする 概要を聞きつつになりますが、徐々に話を掘り下げ、その施策のテストアイテムを洗い出していきます。 概要からわかるテストアイテムもあれば、 「○○は関わってこないのですか？」 「あ、そうですね。影響があるかと思います」 と、問答することで新しく浮かび上がってくるテストアイテムもあります。 他施策やシステムとの関わりなどは、横断組織である我々だからこそ気づく場合もあります。 さらにテストアイテムについて質問を交えながら話を掘り下げ、テストスコープを把握していきます。 「不安だからとりあえず全体的に」といった話も出ます。 ですが、テストする機能は何で、テストしない機能は何かをはっきりさせないと、テスト工数が膨れ上がってしまいます。 3:どのテストレベルでテストすればよいか考える テストする機能を細かく分けていくと、テストする粒度が見えてきます。 例えば以下のような粒度です。 ロジックがメインで計算結果を確認したほうがよい機能 CRUDのような処理や、インターフェイス部分を確認したほうがよい機能 他機能やシステムとの連携が多く、それらを通してテストしたほうがよい機能 これらが見えてくると、どのテストレベルでそれらのテストを行うかが見えてきます。 見えてきましたら、テストする機能をどのテストレベルで行うか当てはめていきます。 ユニットテスト 統合テスト システムテスト （受け入れテスト） テストレベルを考慮しない場合、ほとんどのテストがシステムテストに偏っていくので注意が必要です。 4:テストのアプローチを組み立てる ここまでで、どの機能を、どのテストレベルでテストするかが見えてきました。 次は、それらについてどのようにテストをするか、テストのアプローチを組み立てていきます。 テスト計画の段階ですので、プロダクトに対しての全体的なテストの枠を組み立てるイメージです。 詳細なテストの組み立てはテスト設計段階で行うことになります。 ここでは行うべきテストタイプや、探索的テストといったテスト方法を挙げて組み立てることが多いです。 （私はついついテスト設計段階のことまでしてしまうこともあります…） 各機能のことだけではなく「システムテストに入ったらまずは大きなバグを見つける目的での探索的テストをしましょう」といった作戦も伝え、テストの流れも組み立てることもあります。 この「どのようにテストをしていけばいいか」というアプローチが見えることにより、プロジェクトチームはテスト工程が見え、やるべきことがわかり、安心します。 5:プロダクトリスクを挙げ、そのリスクが考えたアプローチでケアされているか確認する 最後にプロダクトリスクを聞いていきます。 プロダクトリスクはそのまま聞いても意見が出ないことがあるので、以下のようなことを聞きます。 不安なこと 起きて欲しくないこと この際、プロジェクトリスクとプロダクトリスクの双方の意見が出てきます。 ここではプロダクトリスクにフォーカスします。 プロダクトリスクはテストによってケアできるためです。 このとき挙がったプロダクトリスクが、先に組み立てたアプローチでケアされているか確認します。 この活動が、アプローチの抜け漏れチェックとして働いています。 例えば 「実際の業務フローでちゃんと動くのか不安」 といったリスクが上がったら 「業務フローを使ったシナリオテストを追加しましょう」 と漏れていたアプローチに気づき対応することができます。 まとめ QAグループが行なっているテスト計画コンシェルジュの紹介でした。 テスト計画は、時間がかかりそう、という理由で敬遠されがちです。 ですが、何も計画も立てずにテストに臨んだ場合は、非効率なテストになったり、抜け漏れが発生する可能性が非常に高いです。 恐らく最後にはテスト計画にかける労力以上に膨大な労力が費やされてしまうでしょう。 今回紹介したテスト計画コンシェルジュでは、機能をいくつか追加といった規模の施策の場合、60分のテスト計画ミーティング内で行われます。 この時間でしたら敬遠するほどの長時間でもないですし、アジャイル開発にも組み込みやすいのではないでしょうか。 最後に2011年の"Ten Minute Test Plan"を紹介して終わりたいと思います。 huddle.eurostarsoftwaretesting.com

こんにちは！ プロダクトエンジニアリング部の吉永です。 今回は2020/12/28(月)に社内イベント「かぞく参観日」で開催したプログラミング体験教室について紹介したいと思います！ アジェンダ かぞく参観日とは？ プログラミング体験教室について プログラミング体験教室の講師を引き受けた背景 プログラミング体験教室の教材テキストについて プログラミング体験教室のカリキュラムについて 実施してみて まとめ かぞく参観日とは？ 「かぞく参観日」はLIFULLで働いている社員のご家族の皆さまに、LIFULLについて知っていただきたく開催している社内イベントです。 毎年年末に開催しており、昨年まではお子様達に実際にオフィスに訪問してもらい、オフィス内を見学したり、様々なイベントに参加してもらうイベントでした。 が、今年は新型コロナウィルスの影響もあり、オフィスへの訪問はせず、Zoomでのオンライン開催となりました。 初めてのオンライン開催ということもあり、事前準備などで 色々と苦労した点についても紹介していきます。 プログラミング体験教室について 例年開催しており、人気のあるプログラムということで、オンライン開催となった今年度も開催することになりました。 オフライン開催だった2019年は「 PETS 」という実際にさわって学ぶ教材を使ったプログラムを開催したようです。 今年度は完全オンライン開催ということで、ハードウェアを絡めたプログラミング体験は遠隔サポートの難易度が高いので難しいだろうと判断し、PCやタブレットで実施可能な教材を使用する前提で実施する内容を検討しました。 プログラミング体験教室の講師を引き受けた背景 私は前職で2016年から毎年4月～9月ごろまで、新入社員向けのプログラミング研修の講師を務めていました。 研修講師を務める前までは、どちらかというと自分自身へのインプット中心で、後輩や部下のOJTなどは業務だから行っているという気持ちで取り組んでいました。 仕事だから仕方なくという姿勢で取り組んでいた私のマインドを切り替えてくれたのが、2016年に初めて携わらせていただいた、新入社員向けのプログラミング研修の講師という仕事でした。 IT企業の新入社員といっても、昨今の人材不足の影響もあり、学生時代にプログラミング未経験で入社されてくる方も近年はかなりの数でいらっしゃいます。 プログラミング未経験の新入社員でも、3ヶ月間の研修を受けて配属されるまでの間に簡単なWebアプリケーションを構築できるまでに成長することができ、そんな方々のサポート、教育に携わることの「楽しさ」が恐らく今の私の教育関連への関心の高さを形成したのだと思っています。 自分の知識をアウトプットすること、説明する人毎に異なる観点で説明して理解してもらうこと、これらの「楽しさ」に気づくことができ、エンジニアとしてよりレベルアップできたと感じることができたので、現在ではインプットした内容を如何に早く、第三者に分かりやすい内容でアウトプットできるかということが私の学習サイクルになっています。 そんな背景もあり、LIFULLに転職した今でも、週一回の社内サークル活動にて非エンジニア向けのプログラミング教室を開催しています。 参考までに開催している教室で使用している教材記事の一覧です。 qiita.com qiita.com qiita.com qiita.com qiita.com qiita.com qiita.com qiita.com 今回はその活動を知ってくれていた人事部の方からお声がけいただき、かぞく参観日のプログラミング体験教室の講師を引き受けることになりました！ プログラミング体験教室の教材テキストについて 前職で講師を務めていましたが、研修のカリキュラムや、研修で使用する教材テキストの開発などには関わっていなかったので、1から自分で内容を検討するところから始めました。 その際に大事にしたことは プログラミングを楽しいと思ってもらえること プログラミングの基本である、逐次・反復・分岐を詳細に説明することなく理解してもらうこと シンプルな動作を行うパーツを組み合わせて、少し複雑な動作を行うことができることを理解してもらうこと の３つです。 これら3つの要素を意識して作成した教材テキストをQiitaにて公開しています。 qiita.com qiita.com 体験教室当日は プログラミング体験～Scratchでプログラミング入門～ひらがな多め版 の記事をZoomで共有しながら実際にプログラミング体験をしてもらいました！ ひらがな多め版を作った背景ですが、下記のような要件がありました。 今回の体験教室の対象年齢を小学校３年生以上としていた 体験教室が終わった後も復習で使えるように、お子様が読める文字で教材を作っておきたかった 事前準備で教材とは別の資料を試しに全文ひらがなで作ってみたところ、とても読みづらい資料になった よって全てをひらがなにするのではなく、小学校３年生までに習っている漢字を残して、習っていない漢字をひらがなにしたかった 習っていない漢字を調べるのは大変なので、事前準備を手伝ってくれたメンバーがテキストをペーストすると、小学校３年生までに習っていない漢字を赤字で表示してくれるWebツールを見つけてくれました。 正直このツールがなかったら全文ひらがなか、そのまま漢字を残した原文のままかのどちらかにしていたと思うので、このような便利なツールを見つけてくれたメンバーとこのWebツールを作ってくれた作者さんに感謝します！ ※このツールを使ってみたい方は検索エンジンで「習っている漢字」などのキーワードで検索してもらえると見つかると思います！ プログラミング体験教室のカリキュラムについて テキストの次はカリキュラムですが、教室の枠が1時間だったので、1時間でチュートリアルから演習問題作成までを行ってもらうことを考慮して設計しました。 概要説明・・・10分 概要説明で使用したスライドの大まかな内容です。 下記に加え、お子様向けにイラスト多めのスライドを作成していただきました。 プログラムとは？ プログラムとは、コンピュータで動かしたいモノの「動きのじゅんばん」や「どうやって動かしたいか」を文字で書いて、コンピュータがその文字を読んで動かしているよ！ どうぶつの森で、虫をつかまえたり、魚つりをしたりするのもプログラム！ ポケモンGOで、モンスターボールをなげるのもプログラム！ パパ・ママが作っているLIFULL HOME'Sで、おうちをさがすのもプログラム！ プログラムってどうやって作るの？ コンピュータで動かしたいモノの「動きのじゅんばん」や「どうやって動かしたいか」を文字で書いて作っていくよ！ その他にも、今日みんなでいっしょにたいけんする「スクラッチ」のように、図形を組み合わせて動かしていく作りかたもあるよ！ プログラムを作る人のことを、「プログラマー」とか「ソフトエンジニア」と呼ぶよ（よびかたは他にもたくさん！） みんなが大人になってはたらく時には、もしかしたらプログラムの作り方はかわっているかもしれないよ…！ プログラマーってどんなお仕事なの？ コンピュータで動かしたいモノの「動きのじゅんばん」や「どうやって動かしたいか」を文字でたくさん書いてプログラムを作るお仕事だよ！ いきなりたくさんの文字を書くと、まちがえてしまうこともあるので…システムの全体図とか流れ図を作ったりするよ！ 「動きのじゅんばん」や「どんな動きにするか」イメージがついたらたくさん文字を書いていくよ！ 「動きのじゅんばん」や、「文字で書いた動き」が正しく動いているかチェックするよ！ プログラマーって楽しいの？ たいへんなこともあるけど、楽しいことの方が多いよ！ 自分で作ったプログラムが家族や友だちに使ってもらえるとうれしいよ！ 「べんりだね！」とかんしゃされることもあってとてもうれしいよ！ プログラマーに向いている人ってどんな人？ こんな人がむいているよ！あてはまらない人でもプログラマーになりたいって思ってちゃんと勉強すれば、だれでもなれるよ！ 新しいゲームがでたらすぐにほしいって思う人 算数がすきな人 図工の時間にモノづくりするのがすきな人 ゲームを自分で作ってみたい人 きょうやること 「スクラッチ」っていう、プログラムをかんたんに作れるソフトを使って、プログラムを作ってみるよ！ どうやったら音がなるかな？どうやったらキャラが動くのかな？みんなで考えてみよう！ これでみんなもプログラマーデビューだ！ Scratchチュートリアル・・・15分 プログラミング体験～Scratchでプログラミング入門～ひらがな多め版 の ねこを歩かせてみよう の旗を押して猫を歩かせるところまでをZoomで画面を共有しながら操作方法の説明を行いました。 演習時間・・・20分 参加してくれたお子様の親御さんのサポートのもと、教材テキストの流れに沿いながら演習問題を解いてもらいました。 演習問題発表会・・・10分 作成した演習問題を発表してもらいました。 演習問題解答例解説・・・5分 解答例の簡単な解説を行いました。 実際に事前に設計したカリキュラムの時間割とは少し違ってしまったのですが、当日の流れを見て、概ね上記のような流れで実施しました。 実施してみて 事前リハーサルで小学校一年生のお子様がいらっしゃる方に協力してもらい教材テキストの流れを一通り実施してみたところ、下記のフィードバックを得ることができました。 チュートリアルはあまり説明しすぎるとお子様が飽きてしまうので、操作方法などの概要を教えた後は、お子様に自由に操作してもらった方が良い。 演習問題の枠にあまりとらわれず、直感的に思いついたことをお子様にやってもらった方が良い。 マウスの操作方法など、PCの基本操作がわからないので、その辺りの操作方法からサポートしてもらえると良い。 これらを踏まえ、当日実施してみたところ、どのお子様もみな真剣な表情で演習問題に取り組んでくれていました。 演習時間は少しもくもくとやる雰囲気になってしまったので、もう少し皆でワイワイできるような雰囲気づくりを講師としてできれば良かったなと思いました。 発表会はマストにするのではなく、「皆に共有したい人ー発表してくださーい」、くらいのライトな感じにする方が良いと思いました。こだわりの作品を作成途中で無理やり発表させてしまうことは本意ではなく、またこの教室の目的はあくまでプログラミングを「楽しんでもらう」ことだったので、この辺りの配慮が欠けていたなと反省しています。 まとめ お子様向けのプログラミング体験教室を実施してみて、新入社員向けのプログラミング研修とはまったく別の観点や配慮が必要だということに気づくことができ、個人的には非常に多くのことを学べた、良い機会でした。 今回実施してみての一番の収穫は「お子様の発想力は大人を凌駕することがある」ということでした。 演習問題などの枠組みを用意してあげることも重要ですが、その枠から自由にはみ出てもらい、自由に作ってもらうことで運営側が想像もしない成果物を作ってくれるということを知れたのはとても良かったです。 教える側の想像を超えてくるものを見ることができるのはお子様向けプログラミング体験教室の醍醐味であり、教える側にとってもより教える楽しさを味わうことができるので、また教室を開催したいなと思えました！ カリキュラムや教材テキストを作る側の苦労も体験することができ、今までは研修を実施するだけだったので、また一歩レベルアップできたかなと思います。 とはいえ、まだまだカリキュラムや教材テキストに関しては素人だと思いますので、色々な先人達の例を参考にしながら、自分なりのカリキュラムや教材テキストをもっと高いレベルで作成できるようになっていきたいと思います！ 2020年からプログラミング教育が小学校で必修化され、今後ますます関心が高まっていく分野と思いますので、今後教材開発やカリキュラム作成に携わる方々の参考にしてもらえれば幸いです。 最後に、今回のプログラミング体験教室開催にあたりご協力いただいた方々、お忙しい中スライド作成やリハーサルなどにご協力いただきありがとうございました！ 私一人では到底実施することはできず、チームの力で実施することができた、とても良い教室でした！ 以上となります。 最後までご覧いただき、ありがとうございました。

こんにちは！ 株式会社LIFULLで LIFULL HOME'Sアプリ Android開発チームの衛藤です！ Android開発チームでは、不動産業界の不を解消すべく、これまでに最新テクノロジーを率先しプロダクトに反映し続けてきました。 現在のアプリバージョンはv12.12.0(ブログ執筆時点)となっており、12回ものメジャーバージョンアップを重ねてきたのかと思うと感慨深いものがあります！ 私がLIFULLにジョインしたのは2014年7月。それまで存在していたアプリをフルリニューアルし、新たなv1.0.0として開発をしている最中のことでした。 中途採用のためAndroidの開発知識は少しはあったものの、内製開発自体は初めての体験だったため、チーム開発を含め非常に新鮮だったことを今でも思い出します。 さて、今回の記事はその6年間でLIFULL HOME'S Androidアプリがどのような変遷を遂げてきたかについて紹介しようと思います！ 仕事の箸休めタイムにでも、リラックスして眺めて頂けると嬉しいです！ LIFULL HOME'S AndroidアプリUI・UXの変遷 画面別に紹介 トップ画面 まずは起動時のトップ画面の変遷です。v1系からv12系になるまでの間、約4回のUI変更が行われています。 v1.0.0では、完全リニューアル版として新規リリースされました。ToolbarやNavigation Drawerが導入され、より使いやすくなったアプリとして生まれ変わりました。 トップ画面はしばらくこの状態が続き、v4.0.0でマテリアルデザインが導入されることで、より洗練されたUXとなりました。 v4.6.0では「特集」という、検索条件が予め設定されたテーマを検索できる機能が追加されました。 v4.8.0では、特集がタブ化され、ここで初めてBottomNavigationが導入されています。 さらにv4.10.0では、タブが廃止され、特集がトップ画面上部のエリアに大きく配置換えされました。この上部のエリアは、Firebase RemoteConfig + ReatimeDatabaseにより動的に変更可能な領域となっており、季節要因やその他状況に応じて柔軟に特集を出し分けることが可能となっています。 仕組みについては、以前iOSメンバーがイベントで登壇した資料があげられています。 LIFULL HOME'S Firebaseによる特集配信 from 庸介 高橋 www.slideshare.net 現在の最新バージョンv12系では一気にリニューアルされ、トップ画面が２つに別れています（後述のホーム画面）。 物件一覧画面 物件の一覧画面はそこまで大きく変更はされていませんが、細々とUI変更や便利機能が追加になっています。 特に、v5.5.0では掲載物件の間取り図が表示されるようになり、より視覚的にイメージしやすくなっています。 その他にも、物件一覧画面から物件をお気に入り登録する、といったことも可能になっています。 ※ 実在する物件にはモザイクをかけています。ご了承ください。 物件詳細画面 続いて物件の詳細画面です。上部に画像、そこから物件の詳細情報が続く画面設計は変わっていませんが、細かい機能追加がされてきました。 v5.1.0では物件パノラマ機能が追加になり、物件の部屋内部を360度パノラマで閲覧できるようになっています。 この「物件パノラマ」は私自ら機能提案を行いリリースまで行った初めてのプロジェクトとなりました。 その他にも、ストリートビューや初期費用概算（賃貸のみ）といった機能も追加されています。 その他のUI/UX変遷 やることリスト v4系では、「やることリスト」がリリースされました。 面倒な物件探しや入居前にやること、独自のマイタスク追加などチェック形式で整理することが可能な機能です。 優等列車情報 v5.1.0では路線・駅選択画面に「優等列車・始発駅」表示機能が追加になりました。 この機能は、私が家探しをする過程で不便と感じたことがきっかけで機能を提案し、プロジェクト化が決まりました。 またこのプロジェクトについては、エンジニアリングのみではなく企画立案から経験してみたいと上司に打診し、仕様策定・効果測定・APP実装・バックエンド実装含めてすべて一人で完遂したプロジェクトとなりました。 かざして検索 v8.0.0では、新しい検索体験である「かざして検索」がリリースされました。 時期としては2018年で、AI・機械学習がより実践的に各企業に取り入れられるようになったあたりでしょうか。LIFULLでもいち早く導入を行いました。かざして検索は、端末のカメラで建物をかざすと空き部屋情報が確認できるといった、これまでとは全く違う検索体験を実現しました。 初期の実装当時は独自で認識モデルを構築したのですが、その後2019年にML KitでもObject Detection and Trackingが発表され、早速アプリで対応させ、またMaterial Design for Machine Learningを導入しUXも大きく変更しています。スピード感をもって取り入れたことにより、Google I/O Extendedにて事例として紹介されました。 （42分14秒あたり） www.youtube.com それ以外にも各Webメディアやテレビにも取り上げられ、話題を呼んだ新機能となりました。 地図検索 v9.0.0では待望の「地図検索」が登場しました。 これまでは路線・駅・地域を指定することのみ可能でしたが、このバージョンからは地図上から物件を探すことが可能になりました。 自分の住みたい地域を表示し、場所を確認しながら物件を探せるため、より直感的に操作できるようになっています。 また、地図上で範囲を指定する「お絵かき検索」や気になる場所からの徒歩・車での所要時間とともに検索できる機能もあるため、好みの条件に応じて柔軟に検索することが出来るようになりました。 AIによる賃貸物件の提案機能 アプリで2つ目の機械学習機能のリリースで「AIによる賃貸物件の提案機能」というものがリリースされました。 過去に閲覧した物件をもとに、おすすめ物件をAIが提案する機能となります。 この機能はLIFULLのAI専属チームが開発した機械学習モデルを利用し、それをアプリに組み込んだプロジェクトとなります。 Instant Apps Google I/O 2016にて、「Instant Apps」が発表されました。ユーザーがアプリをインストールせずに、一時的にアプリの一部をダウンロードし利用できる機能です。 発表後、早速社内で取り組みを開始し、アプリのモジュール構成を刷新してInstant Apps対応を行いました。 機能としては、以下の2つに絞られています。 特集から物件の一覧が検索できる機能 物件の詳細が閲覧できる機能 ストアの「今すぐ試す」から起動することや、URIから直接物件の詳細画面を立ち上げる（アプリをインストールしていなくても）といったことが可能になりました。 また、アプリインストール動線を設置し、インストール後にInstant Appsで使っていた検索条件やお気に入り物件等を引き継いで利用することも可能になっています。 物件問合せ機能をネイティブ実装へ 気になった物件や内見したい物件に問合せを行う機能がありますが、もともとはWebのスマートフォンページを表示していました。v9.0.0の頃のスクリーンショットは、Webのスマートフォン用ページです。 物件の問合せ自体は問題ありませんが、Webページのためどうしても読み込み速度や操作感がネイティブアプリと比べて劣ってしまいます。 そこで、バックエンドAPIから準備し、ネイティブ実装として開発がスタートしました。 v10系でリリースを行い、そこから細々とUIをチューニングし、現行版（v12系）で落ち着いています。 UIとしてはほんの数画面のみですが、住まいを探しているユーザーと物件をマッチングする重要な機能のため、かなりの期間をかけて完成まで導いたプロジェクトとなりました。 ダークテーマ 業界に先駆けてダークテーマを導入しました。 この機能についてもエンジニア提案によるもので、同じく企画立案・効果測定含めてエンジニアが作り上げたものです。 Google Play Developersにも取り上げられ、注目が集まりました。 developer.android.com マイページからホーム画面へ v1.0.0の頃から存在した機能に「マイページ」というものがあります。検索履歴やお気に入り物件、保存した検索条件などをまとめた機能です。このマイページについても細かくUIアップデートを重ねていました。 既述の「AIによる賃貸物件の提案機能」もかつてはマイページに存在していました。 しかし、よりパーソナライズ化した機能を目指し、v12.0.0からは「ホーム」画面に移り変わりました。 UIも大きく変わり、機能的にもよりユーザーに寄り添ったコンテンツが表示されるように生まれ変わっています。 これまでの取り組みについては、2020年末にGoogle Developers JapanのYoutubeでも取り上げられました。 www.youtube.com まとめ 以上、過去6年間のLIFULL HOME'S Androidアプリ UI/UXの変遷を振り返ってみました。 v1.0.0の頃のUIからすると、かなりモダンに生まれ変わり、便利な機能もたくさん追加されました。 完全内製開発という強みを活かし、職種関係なく細かい機能提案や議論が盛んにされ、それが受け入れられる社風であることがここまでの変遷を可能にしてきたのではないかと感じています。 Androidは年々OSがアップデートされ、新たに利用できる技術が続々と登場してくる変化の激しい世界です。 新技術をいち早く取り入れ、より便利に利用できるプロダクトを世の中にリリースすることが重要です。 技術をキャッチアップし続ける必要はありますが、より良いプロダクトへと繋がる技術を提案し、自発的に導入できるのはエンジニアとしても楽しく働ける環境であることは間違いありません。 これからも、住まい・暮らしに寄り添い、便利にサービスを利用して頂けるよう、チームメンバー一丸となりプロダクトを発展させていきます。 最後まで読んで頂き、ありがとうございました！ 時間があれば、ご自身で携わられているサービスの変遷を振り返ってみてはいかがでしょうか！ 最後に LIFULLでは、そんなプロダクトを一緒に盛り上げて頂ける仲間を募集しています！ ご興味がある方、ぜひ以下の応募フォームよりエントリーくださいませ！！ hrmos.co 「面接までは考えてないけど、社風や事業内容聞いてみたい…」という方向けに、カジュアル面談も実施しています（採用合否には関係ありません）。 カジュアル面談は以下からご応募ください！ hrmos.co

こんにちは。LIFULL でネイティブアプリのスペシャリストをしている菊地です。 普段は LIFULL HOME'S アプリ（iOS, Android）の開発チームで Tech Lead をしています。 2020年12月3日（木）、4日（金）に開催された Google Developers ML Summit に BigQuery で実現するユーザーの傾向に合わせたレコメンドシステム というセッションで登壇させていただきました。 cloudonair.withgoogle.com 当日はまさかのトップバッターということもあり、ライブ Q&A でどういった質問が来るか？そもそも質問くるのか！？という緊張感が凄かったです。 ここでは時間の都合でセッションの中で回答できなかったことや、もう少し詳しいお話を書かせていただければと思います。 Google Developers ML Summit とは Google Developers ML Summit は年に一度、Google Cloud 主催で ML（Machine Learning） に関する技術・事例の紹介などを行うために様々な開発者が一同に集まるイベントになります。 データサイエンティスト、アプリケーション開発者向けに、最新の Google Cloud AI や、機械学習サービスの活用例の紹介。 TensorFlow、Cloud AI などの活用事例、機械学習モデルの開発や利用、データサイエンティスト/機械学習エンジニアを繋げるプラットフォーム「Kaggle」の紹介 公式サイトより 講演資料は こちら で公開されています セッション内容 今回、登壇させていただいたセッションは、 BigQuery で実現するユーザーの傾向に合わせたレコメンドシステム になります。 内容としては、LIFULL HOME'S の Android アプリに実装した 「お気に入り傾向が似ているほかのユーザーがお気に入りに入れている物件をレコメンドする」 機能について、開発のきっかけや、どのようなものを比較・検討したうえで実現したか？というものを発表しております。 ※ こちらもチェック！好みが近い人が閲覧した物件 と表示されている部分が今回実装したものになります。 開発する際の課題と解決 開発する際に課題として上がってきた項目は主に下記の３つになります。 1. レコメンドに必要な学習データをどう集めるか？ レコメンドを行うためには学習データとしてユーザーの行動を集める必要があります。 今回は、Firebase Analytics を既に導入していたため、「物件をお気に入りに追加した」というイベントを計測し、Firebase にある BigQuery Export を利用することで実現しました。 2. レコメンドエンジンをどのように構築するか？ レコメンドエンジンの実現には、GCP では様々な方法で実現することができます。 検討した方法 Recommendations AI BigQuery ML Cloud Data Proc AI Platform 選択したもの 元々の選択肢にはなかった BigQuery による協調フィルタリング を選択しました。 ※ 詳細についてはぜひセッションまたはスライドをご覧いただければと思います。 3. レコメンド結果をアプリからどうやって利用するか？ レコメンドエンジンが抽出したレコメンド結果をアプリから利用するためにどこに置くか？について検討する必要がありました。 アプリから呼び出せる API を作って BigQuery を直接読み取る、別で DB を用意するなど様々なものが考えられます。 今回は、Firestore にユーザー毎の Document が存在していたことから Document 配下に直接書き込む事で、アプリからの直接参照も行えるなどメリットがあったため、Firestore を選択することにしました。 構成図 今回、最終的に構築されたレコメンドシステムのアーキテクチャはこちらの図のようになります。 レコメンドシステム全体の処理としては下記のような３つで構成されております。 アプリから「物件をお気に入りに追加した」というイベントを Firebase Analytics で取得し、BigQuery Export を用いて BigQuery にデータをためる Cloud Scheduler で毎日一度起動する Cloud Functions（Pub/Sub 経由） が BigQuery に対してクエリで協調フィルタリングを行い、抽出結果を Firestore に格納する アプリから Firestore に対して、ユーザー毎の Document にアクセスし、3 で生成された抽出結果（レコメンド結果）を取得する 開発秘話（裏話） 開発のきっかけ LIFULL HOME'S アプリの開発チームでは、普段からこういう機能を提供できないか？こんなことをしたら楽しんでもらえないか？という話をかなりの頻度で話しています。 これはそういうことを話す時間を設けているわけではなく、 ただの雑談 でそういう話をすることがあり、雑談が盛り上がってそのまま開発までしてしまうことがあります。 今回の不動産物件レコメンドシステムについては、 アプリ内でユーザーの行動に合わせたレコメンドって少ないよね？ 好みとかに合わせたものってないかも？ というところから始まり、 ECなどでよく見る "この商品をお気に入りに入れた人はこちらもお気に入りに入れています" みたいなのが提供できるといいかも！ と盛り上がっていったことがきっかけになります。 盛り上がった後には、ちゃんと既に提供しているレコメンドとの違いや、このレコメンドで提供できる価値があるか？というところも話した上で検討が始まりました。 開発までにかかった日数 今回、調査や検討にはかなりの時間がかかりました。 というのも 雑談から始まったプロジェクト であること、 最初はチーム全体ではなく数名 で盛り上がって調べていた、ということが挙げられます。 設計や調査に時間をかけたこともあり、一番時間がかかったのはアプリでどう見せるか？という企画面になります。 全体を通しては実際に開発することが決まってからリリースまでには一ヶ月もかからず開発することができました。 iOS アプリとの相性 今回、LIFULL HOME'S の Android アプリで開発を行いましたが、開発したレコメンドシステムは、すべてバックエンド側のため iOS アプリでも利用が可能です。 いつ頃リリースされるか？まったく同じ内容でリリースされるか？ということは決まっておりませんが、それぞれのプラットフォームのユーザーの特性やアプリの体験に合わせた形で再利用して活用できればと考えています。 AWS や Azure ではなく GCP で開発した理由 LIFULL HOME'S アプリでは、以前から Firebase を導入しています。またマイクロサービスとして AWS、GCP の両方を使い分けています。 そのため、AWS か GCP のどちらかでの開発を行うというのが決まった状態でスタートしました。 最終的には、レコメンドエンジンの中核となる BigQuery に合わせたというのがありますが、Cloud Functions のトリガーによる Firebase の拡張が豊富なこと、既に構築しているアプリ向けプッシュ通知のシステムを GCP で構築していたため、より手軽に開発ができるということで GCP を選択しました。 予算のお話 セッション中に何度も「費用感が・・・」といった形で何度も予算の話を出しておりました。 今回のプロジェクトは元々予算がなく、他のプロジェクトの予算を削減してこちらに回すという形で捻出しました。 費用をかければもっと手軽にレコメンドシステムを実現することは可能ですが、それぞれの構成案の費用間やメリット・デメリットを知っておくことは今後のためにもなると考え、徹底的に費用に拘ってレコメンドを実現する手段を探すことにしました。 人件費なども考えると普通に BigQuery ML などで構築した方が・・・という場合もありますが、同じようなことを検討されている方々でそれぞれの環境に合わせてどうやって実現していくか？ということを考える際の参考になれば幸いです。 データサイエンティストとの関わり方 今回は、レコメンドエンジンの核となる BigQuery で協調フィルタリングを行う部分について、データサイエンティストに相談に乗っていただきました。 BigQuery で協調フィルタリングでがきることはわかっていましたが、実際にクエリを書くとなるとアプリチームのスキルだけでは時間がかかってしまいます。 そのため、普段から BigQuery なども使いこなしているプロに相談しようとなり、弊社のデータサイエンティストにこういうことをやりたいんですけどと相談したところ、数時間後には試験的なクエリを提供していただき開発を一気に進めることができました。 まとめ 今回、Google Developers ML Summit で発表させていただいた BigQuery で実現するユーザーの傾向に合わせたレコメンドシステム についてご紹介させていただきました。 こちらで紹介させていただいたレコメンドは、LIFULL HOME'S Android アプリ内にてご利用いただけます！！ ※ レビューいただいたコメントは中の人が見て返信してますので、ぜひアプリの使い勝手やご意見などを気軽にコメントいただけると嬉しいです！いただいたコメントはアプリの改善にも活かしていきます！ play.google.com セッションの中でも触れましたが、個人的には BigQuery ML を試したいという思いはあったのですが、お金という現実と向き合って"やりたいことをどう実現するか？"と"費用という問題とどう戦っていくか？"というところについてこだわって進めたプロジェクトになります。 今回の内容がレコメンドを作ってみたいと考えている方の参考になれば幸いです。それぞれの構成の詳細についてはセッションスライドに記載があるので、ぜひご覧ください。 LIFULLではメンバーを募集しております！ カジュアル面談もありますのでご興味ある方は是非ご参加ください！ hrmos.co

こんにちは。 プロダクトエンジニアリング部の岩見です。 賃貸のバックエンドを主に担当しています。 私が新卒入社して以来の一番大きな施策であるLINE物件問合せについていろいろとお話できればと思います。 初投稿です！よろしくお願いします！！ LINE物件問合せ LIFULL HOME'Sの賃貸サイトは12月1日に大きなリリースを2つ行いました。 1つ目は 叶えたい条件で探す です。 2つ目はLINE物件問合せです。 後者はプレスリリースをしていないのですが、下記のようにすでに存在する「電話・メール・見学予約」に加えて「LINEで相談する」ボタンを追加し、LINEを使用して物件問合せが行える機能です。（対応している物件のみボタンが表示されます） LINE物件問合せはとても気軽に物件問合せができるのでぜひ使ってみてください！！ まだすべての物件でLINE物件問合せが利用可能な状態ではありませんが、日に日に増えていく予定です！ LINE物件問合せ 大まかな処理のフロー ざっくりとではありますが、以下が問合せ処理のフローです。 エンドユーザーがLINEボタンをタップする。 OAuth認証にもとづいて認証・認可を行う。 不動産会社が所有するLINE公式アカウント宛に問合せメッセージが送信される。 エンドユーザーと不動産会社間のトークルームが作成されて、メッセージのやりとりが可能になる。 問合せ情報を保存する。 以下は実際に使用していたアクティビティ図です。 私が担当したV5チームはフロントエンド~REST APIまでが担当領域です。 view関連やBFFへのリクエストを担うフロントエンド、賃貸マーケット固有の処理やREST APIへのリクエストを担うBFF、LINE物件問合せ共通ロジックを担うREST APIの3つです。アクティビティ図の後半に記載されていますが、反響情報システムやメール配信システムとの連携も必要になってきます。そのため、V5チームは各システム開発担当者や関係者との調整もメインで旗振りをしていました。 アクティビティ図 開発コソコソ話 以下3点について経験談も交えて説明していきます。 チーム構成 LFTV 個人的な苦悩 チーム構成 大まかなチーム構成は下記の通りです。 体制図 全体を見るチーム、問合せデータの送信までを担当するV5チーム、問合せデータを処理して課金計算を行うシステムを担当する料率課金チーム、不動産会社向けの画面改修を行うManagerチームの計4チームの体制でした。 図にも記載している通り、私はV5チームの技術リーダを努めました。新卒2年目ということもあり、まだ大きな責務はないとプロジェクトスタート時期は思っていましたが、全くそんなことはありませんでした。全体を見ているPMから予想を超える裁量を与えていただき、「あれもこれも自分で決めていいの!?」と戸惑ったぐらいです。今までは小さな施策において裁量権はありましたが、ここまで大きな裁量権をいただけることにとても驚きました。 若手だからというのは関係なく、気軽に意見を言い合える関係性を築けており、企画にも意見を出し仕様変更をした部分もありました。 LIFULLという会社は、若手だとしても1人のプロとして見ている・接する文化であることをあらためて実感しました。 LFTV LIFULL Tech Vietnam の略で、ベトナムにあるLIFULLの子会社です。 チーム構成図だとV5->ブリッジエンジニアの下に位置しています。今回の施策では一部APIをLFTVに実装していただき、そのレビューを私含めた本社社員が行う体制を取りました。 私はベトナムの方とお話をすることやオフショア開発を経験することも初めてでした。そのため、コミュニケーションコストが大きくなることを考えると本社だけで完結した方が早いのではないかという不安が大きくありました。 しかし、日本側のブリッジエンジニアの助力もあってLFTVとのコミュニケーションコストは想定よりとても少なかったです。むしろ、コミュニケーションを円滑に進めるためにドキュメントをしっかりと作成したことが本社のチーム間でのコミュニケーション効率化に役立ちました。 今後はこの経験をブリッジエンジニアとともに広めていき、LFTVとの連携する領域を拡大していくことに貢献できればなと思っています。 個人的な苦悩 設計や実装 すでにLINEで不動産会社へ問合せができる LINE会社問合せ が実装されていましたが、3,4年前のコードで現在では推奨されていない設計方針であったり、技術的負債になる実装箇所がいくつもありました。 今となってはコードの臭さを以前よりは探知できるようになりましたが、設計・実装当初はあまり嗅ぎ分けることができずに、fixに時間を要してしまいました。 先輩が 良くも悪くもコードは人を育てる とおっしゃっていて、本当にその通りだなと強く実感し反省をしていました。その後は、本来あるべき姿やどうしてこのような状況になってしまったのかをモブプロで丁寧に説明していただき、良い方向へ成長できました。 技術リーダー 冒頭のチーム構成にも記述しましたが、V5チームの技術リーダーを任せていただきました。チーム開発においては個々人が具体的にどのような動きをするのかを明文化した方が認識の齟齬が少なくなり、余計なコスト発生を抑えることにつながるかと思います。せっかくの機会なので今回はあえて、技術リーダーが何をするかを深く問わずに自身で考えて行動することにしてみました。 いろいろと調べて思考した結果、V5チームのテックスペシャリストになってV5チームの技術に関することならなんでも聞いてくれ！という状態になることを目指しました。 そこからは必死に過去のドキュメントやコード、コミットメッセージ等まで細かく調査を行い知識を吸収することに注力しました。同時に、レビューイ・レビュアーとしても行動し、少し時間が足りないなぁと思う時が多々あったのも事実です。 今までは小さなタスクのみで自身のスループットを把握していたのですが、今回の経験でより精密な定規を手にできたと思っています。 最後に 長々と散りばめて記述してしまいましたが、私が一番お伝えしたかったのはこんな若手にも大きな裁量権を与えてくれる良い方々に恵まれ、一気に成長できたということです。 あらためて良い環境であることを実感するとともに、今後も精進していきたいと思います！！ 繰り返しになりますが、LINE物件問合せをよろしくお願いします！！

こんにちは。クリエイターの日運営委員のヨンジュンです。社内のモノづくりイベント『創民祭』が開催されましたので、その様子を共有させていただきます。 今回はコロナ禍のため、Spatial Chatというサービスを使い、初のリモートによる創民祭開催となりました！ 創民祭とは？ 創民祭（そうみんさい）とは、業務や「クリエイターの日」、プライベートで創った物など、LIFULL社員が作ったプロダクトをお披露目するイベントです。近年はWebに限らず、ジオラマやイラスト等、多種多様なプロダクトが展示されています。 前回の様子はこちら www.lifull.blog Spatial Chatとは？ スペース上を自由に動き回って近くにいる人と会話ができる、 「距離感」のあるウェブ会議サービスです。 画面上のアイコンを操作すると、相手との距離によって音量が変化し、まるでリアルな場で会話しているように距離感を感じながらコミュニケーションをとることができます。 spatial.chat クリエイターの日とは LIFULLでは、マーケティング能力や技術開発能力を高めてイノベーションを創造するため、通常業務の枠を離れて、新たな技術や手法に取り組む機会を設けています。 希望者は、3ヶ月ごとに最大7営業日を使って、好きなものを開発することが可能です。 展示内容 前回同様、Webに限らずいろんなプロダクトが展示されました。以下に展示内容をご紹介します。 LINEから簡単登録！我が家の行きたいところリスト 出展者のチバさんのおうちでは、家族の行きたいところリストをLINE Messaging APIとGASで管理して、家族のグループチャットから行きたいところを登録できるようにしているそうです。 気軽に行きたいところをシェアできて、家族でのおでかけが捗りそうですね！ チバさんは企画職とのことですが、GASやLINE Messaging APIを使えばエンジニアではない方でも簡単にものづくりできるので素敵ですね。 詳しくはこちら： https://qiita.com/rechiba3/items/6e999d1e360442f4f38a 気楽にありがとうを送りあえる！Chatworkでサンクスメッセージ LIFULLでは、感謝の気持ちを伝えたい仲間に贈るメッセージカード「サンクスカード」があるのですが、 出展者のあたりさんはChatwork上でサンクスカードを送りあえるシステムを作ってくれました！ また、botにリプライをすることでもらったサンクスカードの数を集計できるそうです。 リモートワークでも気軽に感謝の気持ちを送りあえそうですね。 FabスペースでDIY！ペット向け家具 LIFULL本社の1FにあるFabスペースにあるレーザーカッターやShopBotを用いたペット向け家具を出展してもらいました！ なんとデザインから出力、やすりがけ等まですべてFabスペースで行なったそうです。ペットの安全を配慮して、釘の代わりに木を使っているとのこと。愛を感じますね！ オンラインでは見せづらい形のある制作物でしたが、制作風景なども含めてわかりやすく展示していただきました。 紹介したペット向け家具は「Make a good Market」から購入できるそうです！ Make a good market： https://magmarket.lifull.net/ https://www.instagram.com/makeagoodmarket/ PE CHALLENGE LIFULLのPE部(プロダクトエンジニアリング部)では、エンジニア主導だからこそできる「住生活を革進する」取り組みとして「PE CHALLENGE」を実施しています。 その第一弾として、ユーザーと不動産会社のコミュニケーションを活性化するシステムの開発を進めているとのことで、今回はプロトタイプのデモを見せてもらいました。 最後に 初のリモート創民祭、その一部をちょっとだけお伝えしました！ LIFULLでは4月からリモートワークが続いており、大人数で集まってわいわいする機会がなかったのですが、 スペチャを使うことでまるでリアルで集まっているような雰囲気を味わえましたし、社員の皆さんのものづくりへの愛が伝わってくる素敵な会になりました。 そんなLIFULLでは、一緒に働くメンバーを募集中！新卒も中途も絶賛採用中です。ご応募お待ちしてますので、ぜひみてください！ recruit.lifull.com

LIFULL秘書の新垣です。この記事は LIFULLアドベントカレンダー2 の24日目です。 担当させていただいているお二人（取締役、CTO）の管掌がいずれも主にエンジニア組織のため、今年も参加させていただくことになりました。 昨年の記事はこちら↓ www.lifull.blog 「秘書って在宅勤務できるの？」と聞かれることが多かった2020年。 LIFULLでは 新しい働き方として在宅勤務とオフィス勤務を併用した勤務ルール を適用しており、これは役員も秘書も同様です。 そこで今回は、コロナ前後における業務変化について３つに限定し紹介します。 スケジュール調整の変化 コミュニケーションの変化 戦略発信量の変化 （予めですが、今回は技術革新の要素はないです。ご了承ください。。） スケジュール調整件数は1.2倍（200件/月→240件/月） 皆さんはコロナ前後において日々の会議数に変化はありますか？ 私が担当しているお二人はほぼすべての会議がオンラインになり時間の刻み方が細かくなったため、総会議数が増えました。 ざっと1.2～1.5倍です。 というと「調整が大変そう！」という印象を持つかもしれませんが、実はそうではなく省力化で楽になりました。 理由は明確で、増えたことよりも減ったことの方が多いからです。 増えたこと：調整件数 減ったこと：1件あたりの調整ステップ 増えたこと＜減ったこと 減ったことの代表は会議室の確保。 今までは その会議の目的や役員の前後予定の動線を勘案し 会議室を押さえていました。これが時に難易度が高く、１つの会議室を押さえるために多くの予定をパズルのように組み替えることもしばしば。ところが現在は2要素の構成だけで会議が開催できます。 before コロナ：会議＝人×時間×場所 with コロナ　：会議＝人×時間 場所の概念がなくなったことは非常に大きな 変化 進化だと感じています。 ちなみにベトナムの開発系子会社 LIFULL Tech Vietnam Co.,Ltd. への出張や 海外カンファレンス参加のための出張もありましたが、これらもすべてオンラインに移行しました。 参加費・旅費交通費等の実費の削減に加え、私達の事務処理工数（人件費）もかなり削減しているのではないかと思います。 なお昨年紹介したGoogleフォームによるスケジュール調整受付は、今も非常に良いツールとして活用しています。 鍵となるのは 必要な情報を一回で得られる仕組みを作ること 。 適切な情報入手が調整スピードと正確さに繋がり、それが役員ひいては事業のパフォーマンス最大化に繋がるという意識を持ち続け、 今後も改善を繰り返していきます。 コミュニケーションの工夫 日々のコミュニケーションにも変化がありました。 まず、LIFULLには秘書室という空間は存在せず、一人ひとりが独立して担当役員の隣の席に座らせていただいています。 それは、 私たちはそれぞれの担当役員の成果にコミットしている ためであり、 役員の目標達成の支援のため、コミュニケーションの量・質ともに重きを置いている からです。 近い距離にいることで得られることは非常に多く、その日の役員の空気感で私たち自身その日の動きを変えたりもしています。 また近距離だからこそ自然発生する雑談からは、多くの0→1アイディアも生まれていました。 ところが一斉に在宅勤務になり、 リアルタイムで状況が把握できない、タスクが把握できない、感情が把握できない・・ いまどういう状態にあるかが見えない という環境になりました。 とくにCTOに関しては複数の組織長を兼務しているため、秘書とのコミュニケーションが整わないと影響を受ける組織が多く出てきてしまいます。 そこで取り入れたのは ・月と金：30min mtg（月：Weekly plan/金：G-POP *1 、KPT ） ・火－木：10min mtg（当日発生×緊急以外の報連相） いずれも夕方に設定することで、1日、1週間、1か月を振り返るという行為にも重きを置いています。 ちなみにこれらは「ゴールと道順が決まっている成果」には有効ですが、先述の自然発生的なアイディアの創出と実行にはまだ工夫が必要です。 コーチングを駆使しているものの、これを遠距離において無意識的に創り出すことが目下の目標です。 before コロナ：近い距離にいることで五感含めたコミュニケーション with コロナ　：遠い距離にいるからこそ毎日計画的にコミュニケーション 差分　　　　 ：自然発生的に生まれる0→1創出と実行 AIに代替される可能性がある職種と言われている秘書。 AIに代替されない付加価値はココ（↑差分）にあると考えているため、今後も差分を作り出し続け、その質を上げる方法を模索していきます。 戦略発信量が激増、裏側は超省力化 最後に戦略発信量に関してです。 新しい働き方に伴い 新しいコミュニケーションルール が策定され、 戦略共有の場である総会の開催数を増やしました。 また開催方法も、リアルからオンライン（Zoom/Webiner）にシフトしました。 ▼開催数の変化 本部総会（100~600名） 　before コロナ：年１回　1～1.5h 　with コロナ　：年12回　 0.5h 部総会（50~100名） 　before コロナ：年4回　 1～1.5h 　with コロナ　：年12回　 0.5h 開催の裏側には担当部門秘書が関わっているため、フロー図にしてみました。 Before@リアル After@オンライン 1つひとつのステップ処理時間も、ステップそのものも、だいぶ省力化できているのが分かるかと思います。 オンライン化により自然となくなったものもあれば、高頻度の開催を実現するために自ら省力化したものもあります。 環境の変化が後押しし、自業務のBPRもゼロ発想でおこなうことができました。 ちなみに余談ですが、秘書グループは常に密にやりとりをしており互いの状況が手に取るようにわかるため、 LIFULL HOME'S事業本部長秘書は「ウェビナー芸人（600名規模でウェビナー運営しているため）」、 私は「総会芸人（時期により週に7件総会を運営しているため）」というあだ名で呼び合って 遊んで 運営しています。 おまけ：エンジニアの組織をフォローするにあたり心がけていること 最後に、クリエイターズブログということなのでこれらの組織をフォローするにあたり心がけていることを今年ver.で考えてみました。 今年は「オンラインツールを試して先に失敗してみた」ことかなと思います。 たとえば初夏のオンライン街バルという全社員参加型交流イベント。 30個ほどある選択制のイベントのうちの１つをremoを使って運営してみましたが、 zoom以外のツールを使っているイベントはこの１つだけでした。 （Clusterを使ったアバター×VR空間イベントはありました！） 私自身はそもそもITに弱くツールに疎くとても苦手意識が強いのですが、安定志向じゃつまらないという思考が上回り、 気づけば参加者40名に操作レクチャーをしていました。 イベント開催後は参加者等が自部署に取り入れており、広がりを感じました。 また、Spatial.Chatでエンジニアイベントを開催した日もありました。 これも「いつもと同じじゃつまらないから使ってみよっと！」がきっかけでした。 正直ほぼハプニングだらけでしたが、後日様々な部署で「Spatial.Chatはこうすると失敗していたからこうしたほうがいい」というやりとりがされていたので、 みんなが失敗しちゃいけない場面で失敗しないように、私が先に失敗していてよかったなーとひそかに思いました。 社内外問わずエンジニア主催で様々なイベントを開催しているので、間接的でも小さなことでも、なにかしらの役に立てていたら嬉しく思います。 lifull.connpass.com LIFULLはこの1年で働く環境が変わりました。 が、環境が変わっても誰もが楽しく挑戦できる機会がたくさんあります。 ご興味のある方はぜひ一度ご連絡ください。 hrmos.co 2021年もクリエイターたちに助けてもらいながら、バックオフィスの小さな 革新 革進をしていけたらと思います。 *1 : https://nminstitute.jp/

こんにちは！テクノロジー本部の花塚です！ 最近気になっている脆弱性は、Envoyに見つかったHeap Buffer Overflowである CVE-2019-18801 です。 この記事では、セキュリティエンジニアがジョブチェンジをしてKubernetesチームにジョインした話、その後の取り組みについて紹介させていただきます。 私事ですが、今年の10月にKubernetesチームにジョインすることになりました。 Kubernetesチームは、以下の記事で、「KEELチーム」として紹介されています。 www.lifull.blog KEELチームは、Kubernetesをベースとしたアプリケーション実行基盤を開発しています。 詳しくは上記の記事をご覧ください。  セキュリティエンジニアからジョブチェンジしました 今年の１月に以下のようなブログを書きました。 www.lifull.blog 内容から分かる通り、ジョインする前は、セキュリティに関係する業務を行っていました。 KEELにジョイン後は、ソフトウェアエンジニアとしてキャリアを歩んでいくことになり、具体的には、以下のようなことをしていくつもりです。 KEELというアプリケーション実行基盤のセキュリティを強固にする KEELを使用する開発者への適切なアドバイスを行う アプリケーション実行基盤として求められるソフトウェアの開発/機能提供 今後はセキュリティのスペシャリティを活かしながら開発に関わっていきたいと思います。 さて、ここからはジョブチェンジをすることになった経緯についてお伝えします。  KEELチームに留学 現在LIFULLのほぼ全ての主要サービスはKEELで管理されており、今後も管理されるサービスの数は増えていく予定です。 今後あらゆるサービスがKEELで管理されることが当たり前になると、セキュリティエンジニアとしてKubernetesに関連するセキュリティにも目を向けていかなければなりません。 幸いLIFULLには「留学制度」という、一定の期間、他部署の業務を経験できる制度が存在したので、それを利用しました。 実際にKEELチームの業務を経験することで、より効率よくKubernetesをキャッチアップすることを目的としていました。  他人事から自分事にしていく 留学期間にKEELの業務をしていると、以前から自分が思い描いていたことを強く感じ始めました。 それは、「セキュリティエンジニアではなく、ソフトウェアエンジニアとしてLIFULLのセキュリティを支えていきたい」ということです。 LIFULLのセキュリティエンジニアは、各開発チームごとに所属するのではなく、セキュリティに関するチームとしてまとまっています。 各開発チームにセキュリティエンジニアが所属するという組織体制は、とても理想的なのですが、プロダクト数や開発チームが多い場合は、なかなかスケールすることができません。 また、専門家がまとまることで得られるメリットもいくつかあると思います。 しかしながら、開発チームの外部に所属しているセキュリティエンジニアは、一度は以下のようなことを思ったことがある方は少なくないかもしれません。 ドメイン知識がないので、脆弱性の影響を調査しにくい エンジニアに対して注意喚起や依頼をすることが多い セキュリティに関する文化をどのように作っていけばいいか分からない KEELはアプリケーション実行基盤を提供しているため、さまざまなプロダクトや開発者と接点を持つことができます。 そのような理由を含めKEELチームへの留学中、「開発者として中からセキュリティを支えていける人になろう」と決心しました。 最近では、各開発チームごとにセキュリティを担当する役割として「セキュリティチャンピオン」という言葉をよく耳にしますよね。 mercan.mercari.com そのような役割を持つ人を今後増やしていけれたらなと思っています。  ジョインしてからの取り組み ここからは、KEELにジョイン後「ソフトウェアエンジニアとしてセキュリティを支えていく」ために取り組んだことについて紹介します。  脆弱性対応方針の策定 自分は、ジョイン後すぐにKEELチームの「脆弱性対応方針の策定」に取り組みました。 「脆弱性対応方針の策定」とは何かを説明すると、脆弱性情報を入手した時にチーム内でどのような動きをするのかを話し合い、ドキュメント化することです。 この取り組みには、脆弱性情報を入手した時に後回しにせずに危機感を持って対応していけるようにしようという意図がありました。 チームの行動指針を決める上で重要な事は、「 チームメンバー全員で話し合う 」ということです。 負債解消のための行動指針のようなものは、当事者たちの意見を汲み取らずに外部が一方的に決めた場合、 反感を買ったり、理由も分からないまま行動させてしまいます。 文化を作っていくためには、押し付けではなく、きちんとメンバー間で対話することがとても大切です。 この議論は、GitHubのIssue上で行われました。議論の結果が以下となります。 「Attack VectorがNetwork」の脆弱性情報を入手した時にIssueを作成する Issueを作成後、影響を調査し、メンバーで対応方針を決定する 脆弱性情報の入手先は、脆弱性可視化基盤でKEELの脆弱性を一定把握していることを前提に、各ソフトウェアのリリースノート、コミュニティの情報としています。 最終的に決められた方針はとてもシンプルですが、議論の内容はとても価値があるものでした。 議論の中で、メンバーの1人が「脆弱性は別に特別なものではなく、単なるバグに過ぎない。普通のバグ対応と同じように対応していけばいい」と発言していました。 実際、脆弱性を調査する際に攻撃手法の知識が充分でなくても、調査できるケースも多くあります。 「脆弱性を特別扱いしない」という考え方は、セキュリティに関する文化を作っていくためにもっと広めていきたいと感じました。  方針の策定後 方針は決まりましたが、その後上手く運用できるか不安でした。強制力が伴わない方針の場合、本人たちのやる気というものが運用に関わってくるからです。 しかし、心配は無用でした。自分以外のメンバーから積極的に脆弱性に関する質問や共有が行われ、方針通りに動くことができています。 自分たちが納得して作り上げた方針はここまで上手くいくのかと、とても驚きました。 運用はまだ始まったばかりなので、今後もチーム全員で改善していきたいと思います。  おわりに 非常に簡単でしたが、セキュリティエンジニアがジョブチェンジをしてKubernetesチームにジョインした話、その後の取り組みについて紹介させていただきました。 ジョインしてまだ2ヶ月ですが、今後はソフトウェアエンジニアとしてKEELチームを支えていくことになります。 今回技術的な内容を紹介できなかったので、次はセキュリティ以外の内容でCreators Blogに登場できればと思います。 また、LIFULLではメンバーを募集しております。カジュアル面談もありますのでご興味ある方は是非ご参加ください！ hrmos.co

LIFULLで技術マネージャーをやっています、花多山です。 早速、タイトルと違う肩書きを名乗ってみましたが、決して嘘ではありません。そして、記事執筆時点において、LIFULLにプロダクトマネージャーという正式な役職はまだ存在しておりません。 LIFULLでエンジニアと企画を両立する 現在、LIFULLはこのような組織体制になっています。 私はというと、LIFULL HOME'S事業本部に所属していますが、その中でエンジニア部門と企画部門の部門長を兼任しております。実のところ、LIFULLではこのような職種をまたいだ兼任はあまり例がありません。 この働き方は私から志願したものですが、理由としては、担当プロダクトの課題発見〜市場投入に至る一連の開発プロセスに、誰よりもコミットしたいという想いからでした。 これってプロダクトマネージャー？ 世間で言うところの、プロダクトマネージャーという役割に近いと思ってますが、書籍『 INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント 』（以下、『INSPIRED』）に書かれている、プロダクトマネージャーの働き方とはちょっとばかり違うなと若干の違和感を感じているのも事実です。 INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント 作者: マーティ・ケーガン 発売日: 2019/11/01 メディア: 単行本 それは、プロダクトが目指すビジョンやそのビジョンを実現するための戦術を描くところまでは、私自身が中心的な役割を果たしますが、それ以降のプロダクト開発プロセスの大部分に関しては、基本は現場の開発チームに裁量を委ねて、私はその進行状況を確認するという役割に身を置いているからです。 一方で『INSPIRED』で描かれているプロダクトマネージャーは一連のプロダクト開発プロセスをエンジニアやデザイナー達と共に併走する存在であり、そこが今の私との大きな違いと言えます。 もちろん、開発中のプロダクトが、先に作ったビジョンや戦術とずれていると感じた時は、軌道修正を促すのも私の役割ではありますし、事業的な成果が事前に定めた目標に届かない場合に、リカバリーする手段を講じるということも、やらなければいけません。 ただ、現場によるプロダクトの課題発見から始まり、開発のイテレーションを実施するなどといった、プロダクト創出の一番の醍醐味にあたることには直接関与せず、本当にこのポジションが自分の理想なんだっけ？と思うこともあります。 開発チームへのプラス作用 じゃあ、お前は普段何の仕事してるのよ？と思われるかもしれませんが、上記のようなプロダクト開発チームを複数管理しており、加えてエンジニアの採用や育成といった、LIFULLのエンジニア全体の成長に寄与する取り組みを生業としています。 そんな私が今のポジションにこだわっている理由は、開発チームに間違いなくプラスの作用を生み出せていると実感しているからです。 LIFULL HOME'Sにおける開発体制 現在のLIFULL HOME'Sでは、冒頭で示した図のように、エンジニア部門、企画部門、デザイン部門が越境して、プロダクト開発チームを構成するという職能別組織を軸とした開発体制を敷いています。同じ職種による意思疎通を図りやすい反面、エンジニアと企画といった職種間でのコミュニケーションには、それなりの習熟度を要します。 裁量を委ねることによる２つのメリット 私が担当しているプロダクト開発チームはというと、デザイン部門との連携はあるものの、こと私が率いているエンジニアと企画間においては、プロダクトの方向性を左右する選択を迫られた際、私が意思決定を下すか、配下のエンジニアと企画のリーダーで決めてもらい、事後報告を受けるということで事足ります。 特に後者のように、現場に多くの裁量を委ねることで、 ①チームにスピード感を生み出せる ことと、 ②メンバー一人ひとりの意識をプロダクトのアウトプット（出力）ではなく、アウトカム（成果）に向けやすい というのが最大のメリットではないかと思っています。 エンジニアとしてのキャリアパス 今のポジションが、自分自身にとって本当に理想の働き方かどうか、この記事の執筆を機会に考えてみましたが、結局のところ、この働き方はアリだという結論に至りました。 それは、エンジニアというバックグラウンドがあるからこそ、力を発揮できる役割であり、そして何より、担当プロダクトの成果に誰よりもコミットできるのは、間違いなく私だと思うからです。そういった意味で、LIFULLにおけるプロダクトマネージャーとしてのキャリアパスをさらに切り開いていきたいと改めて感じました。 『INSPIRED』にもこういう一節があります。 プロダクトマネージャーこそが製品の成功に責任を持ち、説明責任を負う人だと考えるのである。 製品が成功するのは、開発チームの全員がすべきことをしたからである。だが製品が失敗したとき、責任はプロダクトマネージャーにある。 *1 ※ 誤解のないように補足しますが、プロダクトマネージャーの中には、エンジニアに限らず様々なバックグラウンドを有し、私なんか足元にも及ばないくらいすごい実績のある方々も存在すると思います。ただし、エンジニアと直接深いやり取りができるというのは、大きなアドバンテージだと思うのです。 キャリアとしっかり向き合える環境 そして私自身、LIFULLだからこそ、次なるキャリアとしっかり向き合うことができていると感じています。 LIFULLでは、半年に一度、部署異動・職種変更を申告する 『キャリア選択制度』 というものがあり、社員の新しい挑戦や成長を支援しています。また2019年から、業務時間の10%を使って、他部門の仕事に挑戦できる社内兼業制度 『キャリフル』 を開始しています。キャリフルについての詳しい説明はこちらをご覧ください。 副業・兼業が当たり前の時代、私たちは社内兼業制度「キャリフル」を活用する。｜LIFULL公式note 今回の記事を通して、LIFULLのエンジニアとして、こういうキャリアパスもあるよということを知ってもらえれば何よりです。 最後に、LIFULLではメンバーを募集しております。カジュアル面談もありますので、ご興味ある方は是非お話しましょう！ hrmos.co *1 : 引用元： INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント|マーティ・ケーガン

こんにちは、LIFULLのSET(Software Engineer in Test)の Ruey です。 前回は自動テストの指標とEMTE(Equivalent Manual Test Effort)に関する記事を書きました。 www.lifull.blog そして先日開催された STAC 2020 でも同じテーマで登壇させていただきました。 EMTEを使って自動化の費用対効果をわかりやすく表現する from JYERUEY www2.slideshare.net この発表では自動テストの評価指標の中でEMTEと関連がある3つの指標のみ紹介しました。 今回はそれ以外の指標の説明と使い方を紹介したいと思います。 はじめに 自動テストの評価指標 (メトリクス) 分類する 恩恵系 自動化メリット 工数系 自動テスト運用系 同じ欠陥によるケース失敗率 自動テストの実行時間 自動テストのケース数 自動テストのケース成功/失敗数 自動テストの結果誤判定数 自動テストのカバレッジ 品質系 分析ツールの結果メトリクス 自動テストのコードの欠陥密度 自動テストシステムのコンポーネントの効率性 指標の使用例 シナリオ1 シナリオ2 シナリオ3 シナリオ4 おまけ 最後 はじめに ISTQB CTAL-TAE(Advanced Level Test Automation Engineer)のシラバスで自動テストの13個の指標が書いてありますが、それぞれの説明が一言だけで、細かい使い方などは一切説明はされておりません。 そこで、私はシラバスの内容と自分の自動テストの経験をもとにまとめました。本記事を読んで、評価する時にどの指標を使うかをイメージができれば幸いです。 なお、世の中全部の自動テストの目的や構成などが同じにはなりませんので、この記事を読んだ上で自分の自動テストに合わせて調整し、計測指標を使っていただければいいと思います。 自動テストの評価指標 (メトリクス) 自動テストを評価するときにいろいろな指標を測って、テストの目的が達成しているかを確認します。 ISTQB CTAL-TAEのシラバスにある13個をそれぞれ翻訳しました。 次の章は指標を分類してそれぞれの指標の説明と使い方を紹介したいと思います。 ※ 翻訳も個人でやりましたので、他の方の訳し方と違う可能性があります 外部要因指標 自動化メリット 自動テストの構築工数 自動テストの結果分析工数 自動テストのメンテナンス工数 同じ欠陥によるケース失敗率 自動テストの実行時間 自動テストのケース数 自動テストのケース成功/失敗数 自動テストの結果誤判定数 自動テストのカバレッジ 内部要因指標 分析ツールの結果メトリクス 自動テストのコードの欠陥密度 自動テストシステムのコンポーネントの効率性 分類する 使い方とタイミングを合わせて、下記四種類に分類します。 ※ ここは個人で考えた分類であり、シラバスでは特に分類していません 恩恵系 工数系 自動テスト運用系 品質系 恩恵系 恩恵系の指標は自動化により得られたメリットです。 自動テストの実装と実行後のタイミングに集計することができます。 使うタイミング： テスト自動化により、改善できた部分を確認したいとき 指標： 「自動化メリット」 自動化メリット シラバスでは「自動化メリット」指標をさらにいくつかの小指標で分けています。 手動テストから節約できた時間 (Number of hours of manual test effort saved) 手動から自動にして、節約できた時間です。これは一番わかりやすいメリットだと思います。 計算式は「手動でのテスト実行時間」ー 「自動でのテスト実行時間」です。 工数系の指標と併用すると費用対効果のグラフもかけると思います。詳細は 前回の記事 を参照してください。 回帰テストで節約した時間 (Reduction in time to perform regression testing) この指標は上と同じ、自動化して節約できた時間です。回帰テストは基本同じ手順、長期間の運用で何回も実行するので、自動化を導入しやすいです。 計算式は「自動化前の回帰テスト実行時間」ー 「自動化後の回帰テスト実行時間」です。 追加で達成したテストサイクル (Number of additional cycles of test execution achieved) テストサイクルが自動化により早くなると開発効率も上がると思います。 例えば、以前はリリース前に必ず実行する回帰テストのケースが多すぎて、実行時間が長く一週間で2回しかリリースできない状況でした。ですが、自動化によるテストの実行が非常に短縮された結果週に5回リリースできるようになりました。 追加で実行されたテストケースの割合 (Number or percentage of additional tests executed) 以前実行できない部分もできたので、これもメリットがわかりやすい指標だと思います。 全テストケースに対して自動化したケースの割合 (Percentage of automated test cases related to the entire set of test cases) 部分的に自動化をした状態では、基本的に自動化した部分の効率がよくなるので、全体の効率もよくなると思います。 この指標は高い程メリットが多いと思います。 カバレッジの増加 (Increase in coverage) より多くのケースが実行できるので、カバーできる範囲も大きくなると思います。 この指標は高い程メリットが多いと思います。 自動化することでより早く発見した欠陥数 (Number of defects found earlier because of the TAS) テストの実行が早くなったので、欠陥があればより早く発見できます。自動化による開発サイクルのテストシフトレフトもあるので、より早い段階で欠陥を見つけることができます。 自動テストでしか拾えない欠陥数 (Number of defects found because of the TAS which would not have been found by manual testing) 自動化は手動より短時間で大量のケースが実行できるようになるので、信頼性テストや負荷テスト的なケース実行もできるようになります。それにより、手動で検知できない欠陥を見つけることができます。 工数系 工数系は13個の指標のうち工数で取得するものです。 目標段階で予定した工数以内で、自動テストができたかの確認指標です。 自動テストのメイン作業の消費工数の確認するため、以下を測ればいいと思います。 使うタイミング： チームの想定する工数内に収めるため、自動テストの消費工数を確認したいとき 指標： 「自動テストの構築工数」 「自動テストの結果分析工数」 「自動テストのメンテナンス工数」 前回の記事でこの部分を紹介したので、今回は割愛します。 工数系の指標に興味があれば、是非 前回の記事 を参考にしてください。 自動テスト運用系 自動テスト運用系は自動テストの効果を測る指標です。 自動テストの効果は短期間ではあまり参考にできないので、長い期間で継続的に集計した方がおすすめです。 使うタイミング： 自動テストをしばらく運用し、効果を確認したいとき。または自動テストを見直したいとき 指標： 「同じ欠陥によるケース失敗率」 「自動テストの実行時間」 「自動テストのケース数」 「自動テストのケース成功/失敗数」 「自動テストの結果誤判定数」 「自動テストのカバレッジ」 同じ欠陥によるケース失敗率 普段のコードは疎結合が大事だと思いますが、テストコードも同じです。 一箇所に問題が発生して、影響を受けたケースが多くなると自動テスト結果分析の時に確認しづらくなります。 この指標はなるべく低い状態がいいと思います。 自動テストの実行時間 一番シンプルな指標、低い程効率がいいです。 手動の実行時間と比較したいときにEMTEで変換してもいい指標です。 自動テストのケース数 自動テストの規模確認用の指標。規模がどんどん肥大化すると実行速度に影響がでやすいですし、結果分析の時も確認しづらくなります。 ※ ケースが多いほどカバレッジが高いわけではありません。 自動テストのケース成功/失敗数 自動テストの状態確認用の指標です。 普段は自動テストの結果として使っています。成功率はリリースできるかのクオリティゲートとしても使われることがあります。 また、常に失敗するケースが存在する場合、効果がないテストケースが存在することが分かります。 失敗数が少ない方がいい指標です。 自動テストの結果誤判定数 自動テストの信頼性の指標です。False PositiveとFalse Negativeがあります。 False Negativeは成功になるテストケースを失敗に判定されるので、多くなると自動テストの信頼性が下がり、結果があまり参考にならない状態になります。 逆にFalse Positiveは失敗になるテストケースを成功に判定されます。テストケースの検証メソッドの実装ミスの恐れがありますし、そして、見つけられる欠陥も見つからない状態になるかもしれません。 できるだけ誤判定数が減った方がいい気がします。 自動テストのカバレッジ 自動テストの担保範囲の確認指標です。 よく知られている指標だと思います。自動テストが機能もしくは要求・要件をどれぐらいカバーできているかを表します。 運用コストにもよりますが、この指標はできるだけ高くすべきだと思います。 品質系 内部要因の指標は全部品質系になります。 普段の開発でコードの品質を意識すると思いますが、テストコードも同じく品質が大事です。 長く運用したいなら自動テストのコード品質を意識すべきだと思います。 使うタイミング： 自動テストの品質を確認したいとき 指標： 「分析ツールの結果メトリクス」 「自動テストのコードの欠陥密度」 「自動テストシステムのコンポーネントの効率性」 分析ツールの結果メトリクス 普段のコードと同じく、静的解析などのツールを利用して、いろいろなメトリクスを測ります。よく取るメトリクスはLOC(Line of code)、コード複雑度、技術負債の返済期間など。 どのメトリクスを見ればいいかは決まっていないですが、項目ごとに納得できるしきい値を守りましょう。 自動テストのコードの欠陥密度 テストコードも同じく欠陥があります。 計算式は「欠陥数」／「コード総行数」です。 1行のコード内におよそどれぐらいの欠陥があるかの指標です。 欠陥密度は高い程、欠陥が現れやすいので、低い状態を維持した方がいいです。 自動テストシステムのコンポーネントの効率性 自動テストはテストコード自身の影響以外にも影響される部分が多いです。 自動テストの品質はテストコードだけではなく、自動テストシステム全体で見るべきだと思います。テスト対象の反応速度は毎回同じではなく、負荷による変化もあるので、自動テスト全体の効率に影響が出ます。 自動テストコードの実装は各コンポーネントの効率と変更の可能性を考慮し、調整し続けるべきだと思います。それを怠ると、Flakyのケースは多くなります。 指標の使用例 自動テストの指標は評価するときに使われます。 ここからは各シナリオで、どの指標を利用して評価するかを見ていきましょう。 シナリオ1 重大なリリースがあって、大量のページをリリース前に全部チェックをしたい。 自動テストは一回のみ利用します。 ポイント： 「短期利用」、「広範囲のカバー」 使う指標： 「恩恵系」 短期利用なので、工数系、自動テスト運用系、品質系は特に考えなくていいと思います。 大量のページをチェックしたいので、恩恵系の「増えたカバレッジ」、「追加で実行できたケース数」を集計し、目標のページ数を達成したかの確認ができます。 シナリオ2 既に手動の回帰テストがありますが、チームの工数が厳しい状態です。 自動化して工数を節約したいし、自動テストの運用工数を最小限にしたい。 ポイント： 「運用工数」、「節約」 使う指標： 「工数系」、「恩恵系」 節約時間は恩恵系の「手動テストから節約できた時間」で分かります。 構築した後工数系の指標を測ることで、実際に前より工数の合計が少なくなっていることが確認できますし、構築にかかる工数が節約されることにより還元される期間も分かります。 シナリオ3 大規模のシステムに3年以上運用できる自動テストを導入したい ポイント： 「長い運用」 使う指標： 「品質系」 長い運用であれば品質系の指標を測りましょう。 静的解析ツールを導入し、自動で「分析ツールの結果メトリクス」が取れれば、テストコードの状況が把握できます。大体の静的解析ツールは品質の評価点を表示すると思いますので、想定内の品質の評価点で構築できたかを確認できますし、今後の運用で技術負債が増えることもすぐ把握できます。 運用しながら、静的解析ツールの指摘で継続的にテストコードの品質を守りましょう。 シナリオ4 既に運用中の自動テストを効果を確認し、見直しが必要な部分を確認したい ポイント： 「効果を確認」 使う指標： 「自動テスト運用系」 しばらく自動テストを運用したら、自動テスト運用系の集計はできると思います。 また、現状確認しつつ傾向も分かると思いますし、以前より劣化した指標がリストアップできます。 すると、各指標に対して、自動テストの状態に合わせた対策を考えられます。 おまけ 上記の指標で自動テストの評価ができますが、ビジネスの観点で予算から考えたい時もあるかと思います。 その場合は工数系の指標を担当者の人件費として計算すれば考えやすいでしょう。 そして自動テストの実行時間などは各サーバーの運用代で置き換え計算が出来ます。 ビジネス目標： 今期の予算50万で自動テストを構築する。 金額変換： 人件費は2000円/hr サーバー代は1000円/hr 計算： 今回の自動テストの構築工数は50時間 運用工数は一回の実行で30分 毎営業日でテスト1時間実行 今期の金額は： ※ 一期は120日で計算 構築50hr + 毎日30分の運用工数 * 120日 + 毎日1時間のサーバー実行 * 120日 = 50* 2000 + 0.5 * 2000 * 120 + 1 * 1000 * 120 = 100,000 + 120,000 + 120,000 = 340,000円 　 今期の予算内で出来ました！ 最後 今回は全部の指標に対して説明と使い方を紹介しました。 皆さんも少しイメージができましたでしょうか。 実際には自動テストを構築する前に何を測るべきかを決められないと思うので、 状況に合わせて自動テストを試し、いろいろな指標を実際に測ってみればより分かると思います。 ぜひ自分の自動テストに必要な指標で評価しましょう。

こんにちは。Ltech 運営チームの菊地です。 今回は、2020年12月8日（火）に開催した「Ltech#12 エンジニア150名以上を抱えるCTOとマネージャがマネジメントを語ります！」についてレポートします。 Ltech とは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。特定の技術に偏らず、様々な技術の話を展開していく予定です。 エンジニア150名以上を抱えるCTOとマネージャがマネジメントを語ります！ 今回のテーマは、「エンジニア150名以上を抱えるCTOとマネージャがマネジメントを語ります！」になります。 LIFULL には現在 150名以上のエンジニアが所属しています。 そのエンジニア組織をどうマネジメントしているのか？をテーマに CTO とエンジニアリングマネージャに語ってもらおうという内容になります。 CTOの考えるエンジニアマネジメント２ CTOの考えるエンジニアマネジメント2 from LIFULL Co., Ltd. www2.slideshare.net ちょうど一年前の 2019年12月に CTO の長沢が投稿した「LIFULLのCTOの考えるエンジニアマネジメント」という記事を元にして、2020年12月現在のマネジメント論を語っていただきました。 www.lifull.blog マネジメントとは 現場のエンジニアマネージャに聞いてみても メンバーが自信を持って仕事できるようにする お金を管理する 決まった方向に向かってきちんと方針にずれないように導いていく 意思を示して引っ張る プロジェクトを成功させる など様々な回答があり明確なものはない中で、CTO の考えるマネジメントは「ヒト・モノ・カネを使って成果を最大化する」ということ。 エンジニアマネジメントにおける「ひと」 会社を運営するのも、価値を生み出すのも人。価値創造にも価値獲得にもとても大事 組織の目指すものと個人のやりたいことをマッチさせていくために、組織と個人のそれぞれに対してどのようにアプローチするか といった内容について、一年前と現在の違いを交えて発表いただきました。 Q&A Q. 目標設定に会社や組織としてのルールって何かありますか？目標方針や数など。それとも完全自由ですか？ 目標設定のルールとしては、MBO を採用しています。 行動のガイドラインを図るための項目 社是に対する利他に対する項目 半期の目標 業績への目標 の４段構成のフォーマットに沿って、実施している 詳しくは弊社 CPO 羽田の著書「日本一働きたい会社のつくりかた」という本に書いてます。 www.amazon.co.jp Q. 定性的な目標の評価はどのように行っていますか？工夫していることなどありますか 定性的すぎると「利他貢献」のような人のためにやることの評価が難しくなってしまうので、そういったものについては行動を評価し、そういった行動を推奨するようにしている Q. ネガティブなフィードバックはどのようにしていますか？ 指摘が人に向かわないようにフィードバックしている。どういうことがあったか？どういう影響があったか？というファクトを集めて伝えるようにしている。 単純に技術力が足りないというような場合は、こういうことはできて欲しいという要求を伝えつつも、合わせてどういう風にすればできるか？という次に繋がるやり方を考えて伝えている。 LIFULL のエンジニアマネージャによるパネルディスカッション LIFULL のエンジニアリングマネージャ陣から代表して、 エンジニア専門職とマネージャを歴任している三木 と 新規事業領域で活躍している山﨑 の2人から、実際に現場で行っているマネジメントなどについて語っていただきました。 Q. メンバーのキャリアデザインと会社の業務をどうバランスをとって実現させるのか？ 三木 ） 本人の趣向を尊重する形を重視。 明日からこの仕事やりたくないので異動したいとかは無理だけど、それに向けた準備などをしつつその人がいなくても大丈夫な環境作りをしながら行ってもらえる様にしている。 山﨑 ） 新規事業ではやりたいと思って来た人でも消耗しきっちゃって新規事業が無理ってなる人もいる。 技術が好きでやっていたが、ビジネスやマーケティングなどの新しい道に興味を持ってうつっていく人もいるため、本人に確認しながら合う場所を検討しながら配置転換などを検討する Q. エンジニアマネージャは自身の技術的な成長に関してどう考えているのか？ 山﨑 ） 新規事業の創出は、技術無くして実現できないためトレンドをしっかりと捉える必要があるので、キャッチアップする時間を取っている。 手を動かせないからできなくなると言わずに、常にキャッチアップするようにしている。 三木 ） 実装はほぼしなくなったが休日に家で少し触る程度だが、新しい技術にアンテナをはるということを気をつけている 過去の経験から、新しい技術がどういったものか？は読めばある程度把握できる。 ただ実際に触っていないため、メンバーから細かいとこを聞かれると困ることがあるので、そういうものはメモして覚えたり、わからないと伝えて説明してもらうことでキャッチアップしている。 Q. リーダー、マネージャとして自分が間違っているのでは？本当にこれでいいのだろうか？と思うことはありますか？ 三木 ） 全て自分が正しいと思っていない。正解が複数ある中で、なんで私はこの選択をしたを説明して、他の選択肢も否定はせずメンバーなどと相談して選択する。 山﨑 ） こういった前提条件の中でこういった理由で決めるが、それが最善か？はわからないため、もっといい選択肢がないか？を探すためにメンバーとコミュニケーションなどを行うことを考えている。 Q. マネージャになるために必要なスキルはなんでしょうか？ 山﨑 ） 大きく分けて、ピープルマネジメントとテックマネジメントがあると思います。 テックマネジメントは会社や事業によって違ってくるので、技術力を徹底的にあげるために ひたすらものを作る ピープルマネジメントのほうが鍵で、組織の中でマネージメントをやるのであれば、経営者が求めるものを咀嚼して組織にしっかり伝える。 それを実現するためにメンバーとの日々の対話が大事。 三木 ） 昔は引っ張っていくマネジメントをしていたが、今は支えていくマネジメントをしている。 マネージャの不安がメンバーや組織全体に対して伝搬していくので、何があっても状況把握をするためなるべくクールでいることが大事 Q.（色々な経緯を経て）部下との関係性が悪化してしまった場合はどうされてますか？異動の前にまず修復を考えると思いますが、どのように関係修復を試みますか？また、部下同士の関係性悪化にはどう対処しますか？（エンジニアはコミュニケーションが不得手な人が多いので… 三木 ） メンバーの足りないところを補い合ってチームとして成果を出していけばいいと考えている。あくまでも個人ではなく組織として最大限の成果をどう出していくか？というのを考えて、視点を変えて行こうという話をする 山﨑 ） 起きていることを因数分解して課題は何か？という基本的な現状把握をすることで大抵のことはなんとかできる。 関係悪化のトリガーになっているのは何か？をしっかり把握すると、色々なことが混ざって言語化できていないことが多いので、分解するとシンプルになるのでそうやって解決している 部下とのコミュニケーションは自分も悪いところはないか？というのを気をつけながらやりとりをしている。 Q. エンジニアだからこそのマネジメントというのはありますか？ 三木 ） 基本的にエンジニアに対してもそれ以外に対しても同じマネジメントをしているが、エンジニアはコミュニケーションが不得手な人が多いのでというのがあるので、内面に思っていることをどう出してもらうか？というのを工夫している 山﨑 ） エンジニアをマネージメントする観点では、相手が何を伝えたいのか？を傾聴してマネジメントすることを意識している 最後に 今回は、CTOと現場のマネージャの方々に登壇していただき、マネジメントについて語っていただきました。 マネージャを目指している方やマネジメントで悩まれている方に向けて、なかなか聞くことができないような話をお伝え出来たのではないかと思います。 Ltech では、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

CTO の 長沢 です。 早いもので2020年も終わりそうですね。新型コロナによってLIFULLは大きく働き方も変わり色々と変化のある一年でした。 せっかくの機会なので、2020年のLIFULLの技術関連についての出来事をまとめていきたいと思います。 LIFULL の基幹事業である LIFULL HOME'S、LIFULL全体の事業系のインフラ部門、情報システム部門、などについて書いていきます。 全社のQA部門についてはその部門のマネージャーが書いている記事をご覧ください。 www.lifull.blog AIに関しての取り組みも個別記事でご覧ください。 www.lifull.blog こちらの記事で記載してある内容に関しては私が「ざっくり考えて方向性だけ出したり組織を組成してやってきた話」であり、実際に各種を進めているのは優秀なエンジニアマネージャーやエンジニアのみんなです(引き抜かないでください)。 目次 事業部内での技術組織の組成 事業系インフラ部門での取り組み アプリケーション実行基盤の刷新 検索エンジン強化 データ基盤の強化 社内全体のAWS利用のコスト最適化 データベースマイグレーションのためのチーム組成 エンジニアとしての情報発信 情報システム 最後に 事業部内での技術組織の組成 LIFULL HOME'Sはここ5年間ほど、賃貸、中古流通、注文住宅、分譲マンション、分譲戸建、等、各マーケットに組織を切り分けた事業部制を採用していました。 事業部制は「 ユーザーの声を聞いて作って売るというサイクルをスピード感を持って回す 」という目的でした。当時LIFULL HOME'Sにはプロパーで100名ほどのエンジニアがおり、それぞれのマーケットに振り分けられていました。 うまく機能していた部分も多分にありましたが、システムという観点で見ると大部分が上記のマーケットを横断したシステムとなっていました。 (LIFULL HOME'Sは意味のある単位で範囲でサービスを分割していくことを進めていますが、長くからある部分はまだモノリシックな部分が多いです) そのため、複雑に絡み合った共通機能が多く、非機能要件を中心としたシステム改善も一つの部門では手を付けにくい状態でした。 また、各チームでのサイロ化が進んでいたため、人員の硬直化や横断で開発すれば効率がいいものがやりにくくなってしまうという状態もありました。 *1 それらの問題に着手しつつ、今後のLIFULL全体の変化に対応していくため、2019年10月にLIFULL HOME'S内にエンジニアを集めた技術組織を組成しました。 その時にやっていくこととして掲げていたものは以下です。 また、インフラ部分で起こっている変化に対してLIFULL HOME'Sのエンジニアとしても対応していける力・体制を整えていくことも目的の1つでした。 大きな変更において、そのメリットを最大限に享受するためには、システムに乗る側もしっかりと利用できる必要があります。 (システムだけの話ではないですよね) www.lifull.blog 実際にLIFULL HOME'Sのエンジニアのみんなには、 一定の割合の時間をリファクタリングに割くこと 各マーケットを横断して利用できる機能は共通して作っていくこと(効率化できる部分を発見して提案、実装していく) といったことなど目標にももってもらい進めてきました。 またエンジニアリングマネージャーには、 PLという観点で、技術的にかかっている各種コストの最適化(横断で利用できるものはする等) というものも担ってもらっていました。(コストを抑えるべきところは抑えて、かけるべきところにはしっかり投資していきたいですよね) そうして1年ほどやってみて、 リファクタリングがしっかりと文化として根付いてきた (これはエンジニアのメンバーにも言ってもらえたのでとても嬉しかったです)というのを感じています。 リファクタリングやってるメンバーが全社で表彰されたり とエンジニアだけではなくビジネスサイドを含めた組織全体として理解されているのは嬉しいことです。 実際に成果としても色々できました。 www.lifull.blog www.lifull.blog www.lifull.blog www.lifull.blog もう一つの大きな狙いであった、部門横断での全体最適(LIFULL HOME'S全体の共通機能やコスト等)に関しても、一定の成果を出すことができました。(システム関連コストでは全体利益への貢献も少なくない金額でありましたが詳細は割愛させていただきます) また、事業部制のときもエンジニア同士の距離は近かったのですが、実際に部門が同じになったことで、今まで以上にメンバー発案の勉強会が増えました。 能動的にみんなで技術研鑽をしていこうというチームで感動しています。 この組織と取り組みは関しては2020年10月からの新しい期でも継続しているのでアップグレードしながら引き続きやっていきたいと思います。 事業系インフラ部門での取り組み こちらは、LIFULL HOME'S事業本部の話ではなく、テクノロジー本部という全社を横断した技術部門の話です。 アプリケーション実行基盤の刷新 2年ほど前から、「車輪の再発明を抑制しつつ、LIFULLのアプリケーション実行基盤を革めアプリケーション開発者の価値提供の速度を加速させる」ということを目的に、動いていましたが、それが全体に適応されてから1年少しが立ちました。前述したLIFULL HOME'S内の新サービスに関してもこの環境で乗るようになりカバー範囲は7割を超えており、今後もより強めていく部分です。 詳しくは以下のアプリケーション実行基盤チームの記事をご覧ください。 www.lifull.blog 検索エンジン強化 LIFULLにはLIFULL HOME'Sをはじめ「検索サービス」が多くあります。その中で検索機能においてどんな事ができるか？は会社としての強みになってきます。そこを強化すべく、検索エンジンを中心にやっていくチームを組成して強化に取り組んでいます。 現在の検索エンジンはSolrですがチームを組成してから今まであまりできていなかったバージョンアップがしっかりとされるようになっていたり、また事業部ともやり取りして機能を追加していったりと着実に進めることができています。 そのうちチームの取り組みもブログなどで紹介されると思います。 データ基盤の強化 現在、社内では多くの部門でデータが活用されています。 www.lifull.blog 今までも構築はされていたのですが、それを全社の基盤として構築・運用していくべく、ここ一年間は技術横断の組織でチームを固定化して取り組んできました。 多くのデータの連携が進んでいます。 こちらも、そのうちチームの取り組みもブログなどで紹介されると思います。 社内全体のAWS利用のコスト最適化 各サービスを分割して運営しており、様々な部門でAWSを利用しています(アカウントも切り分けている)。 そうすると各チームごとに知識の差が生まれ知らない間に余剰なインフラコストがかかるということが発生していたため、効果の高い投資を今後も行なっていくために、膨れ上がったコストを適正化する(≒不要コスト削減)必要がありました。 そこで、今年はクラウドアーキテクトの 鈴木 に横断して取り組んでいってもらっていました。 www.lifull.blog 実際にかなりのコスト削減を実現でき、その分新たなシステム投資を行うことができました。 データベースマイグレーションのためのチーム組成 LIFULLでは創業以来ずっと利用されてきたデータベースがありますが、そちらのマイグレーションに取り掛かっています。 こちらは2年ほど見込まれる非常に息の長いプロジェクトですが、まずは構成を大きく変えず載せ替えるという方法で進めていっています。 過去に何度か頓挫していることもあり、専任のチームを組成し取り掛かっていくことにしました。今年の4月頃から開始でまだ半年ですが確実に進んでいます。 エンジニアとしての情報発信 技術部門から様々な発信がされたのも嬉しかったことです。 今年になってから発信に力を入れようということで、様々な発信が行われました。 技術の発信には その時の課題とその解決方法や、利用している技術などを発信することで、世の中の技術部分に少しでも貢献する(世の中の技術に対してタダ乗りにならない) 発信して外部からのフィードバックを得られるかもしれない エンジニア個人としても名前を出して発信することにより知ってもらえる LIFULL に興味を持ってっくれる仲間が増えるかもしれない というような意図をもってやっています。 特に1番目は大事だと思っていて 『利他主義』を掲げている会社 ですので技術の情報でも得た情報は閉じてないほうがいいですよね！ 情報システム ここは今年、世の中の状況も相まって大きく変化がありました。 外出や出張がある職種がおりましたので、もともと社内NWへVPNで接続できる環境はあったのですが、 社内NW側の機器の関係で同時接続できる人数に上限がありました 。 新型コロナが流行り始めた2020年1月頃のタイミングで何かあってもいいようにサーバーの調達をベンダーと開始していました。(その時はこんなに流行るとは思っていませんでしたが) 3月にもなると、いよいよ雲行きも怪しくなってきた&VPNのサーバーの増強は4月頃になりそうということだったので、もともと導入していた統合認証基盤を活用し一部のシステムで安全に利用できそうなものに関してはVPNなしでも接続できるようにしていきました(ゼロトラストっぽく)。 また、統合認証基盤に対応していないシステムに関しては、新たに契約したクラウド型のVPNも利用しながらIP制限をしつつ利用していきました。 家のインターネットがないという社員へは会社貸与のスマートフォンの通信容量を増やしテザリングにて業務にあたってもらうようにしました。 そんなこんなで非常に慌ただしかったですが、緊急事態宣言のときまでには物理的なものを扱わない業務の社員に関してはほとんどリモートでの業務ができるようになっていました。 諸々環境が整ったことに加えて、社員みんなのお互いが助け合う姿勢により、目立った生産性の低下も起きておらず、会社としても新しい働き方として原則週2日の在宅勤務と定め、状況や業務を考慮し個々の判断で在宅勤務は週4日まで可能で、最低週1日出社というスタイルを続けていこうと決めて進めています。 またコスト構造を見直して改善を図るきっかけにもなったのもあり、正社員の月例給与を約10％増額する等、従業員のベースアップを実施しました。 lifull.com 2020年の10月からは情報システム部でもエンジニアリング要素を一段と強め会社をリードしていくために、新しい戦略も描き組織の構造も大きく刷新しました。 ゼロトラストネットワークの構築を始めいろいろなことをやっていきますので私自身非常に楽しみです。 これも、ブログなどで紹介されると思います。 最後に 振り替えると本当に色々あった約一年間だなぁと改めて思います。 私個人的には「今まで進めていた取り組みが、少しづつ繋がってきた」ということを強く感じる一年でした。 LIFULLでは新しい中期経営計画も始まり、社会課題の解決に向けて取組むことをしていきます！ 仲間になってくれる人を大募集中ですので「 あらゆるLIFEを、FULLに。 」することに興味がある方は是非お話しましょう！ hrmos.co 今年もありがとうございました。 *1 : 組織の形に関してはその時の組織が抱える課題によって事業部制、機能別、その他など様々な選択肢がありますし、それぞれにメリット・デメリットがあると思いますので一概に「何が良くて何がだめ」という話をしたいわけではございません。