こんにちは。 プロダクトエンジニアリング部の岩見です。 賃貸のバックエンドを主に担当しています。 私が新卒入社して以来の一番大きな施策である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 : 組織の形に関してはその時の組織が抱える課題によって事業部制、機能別、その他など様々な選択肢がありますし、それぞれにメリット・デメリットがあると思いますので一概に「何が良くて何がだめ」という話をしたいわけではございません。

技術開発部改めKEELチームの相原です。 今回はLIFULLの全社アプリケーション実行基盤 KEEL について紹介いたします。 全社アプリケーション実行基盤 KEEL とは KEELとはLIFULLグループ全体で利用することを目的としたKubernetesベースのアプリケーション実行基盤です。 keel は船の竜骨を意味する英単語で、 spinnaker/keel や keel-hq/keel と名前が被ってしまっていますが、LIFULLという船を支える屋台骨となるため2018年初頭から開発・運用を続けている内製のプロジェクトです。 マルチテナントなシングルクラスタで、 コンテナオーケストレーション ネットワーク サービスメッシュ デプロイ メトリクス ログ 分散トレーシング セキュリティ ワークフローエンジン をはじめとしてアプリケーションの運用で必要になる多くのものを責任範囲として提供しています。 その他にも各種マニフェスト生成ツールや認証基盤の開発にProxySQLやRedis, memcachedクラスタの提供、アプリケーションフレームワークの提供とKEELへのアプリケーション受け入れなど広範的に開発者を支援しています。 既にLIFULLのアプリケーションの大部分がこのKEEL上で稼働しており、新規開発のアプリケーションの多くもこのKEELに載せることを前提に開発されてきました。 背景 LIFULL HOME'S サービス開始から20年以上が経ち、コードベースも次第に巨大になってきました。 そしてコードベースが巨大になるにつれて、デプロイ速度の鈍化やメンテナンス性の低下が目立つようになり、開発速度が低下していきました。 そうした変化を受けて LIFULL では、数年前のオンプレミスからの AWS 移行を契機にマイクロサービス化に踏み切ります。 サービスを適切な単位で切り分けてデプロイを独立化し、開発チームに権限を移譲することで分業化に成功しました。 しかし、年月が経ち新たな課題が見え始めました。 それはマイクロサービス化による車輪の再発明と分散システムとしての難しさです。 それぞれのチームがロギング・監視基盤やデプロイフローを個別に構築したり、各アプリケーションごとに Retrying や Timeout を実装することにより、従来の体制と比較して重複する機能が多くなってしまいました。 加えて、下流のサービスに巻き込まれる形での障害も目立つようになり、分散したアプリケーションをうまく運用するという難しさにも直面することになったのです。 そこで我々は、統一されたアプリケーション実行基盤を開発して分散システムの難しさを解決すると同時に車輪の再発明を防ぐことを狙うことにしました。 結果として開発者がアプリケーションをローンチするまでの負荷が大きく下がり、効率を落とすことなくシステムの分離度を適切に保つことができるようになりました。 KEELチームとこれまでのアウトプット もともとは私一人で開始したこのプロジェクトも今では4人のメンバーがジョインして大きくなってきました。 我々のミッションは「 LIFULLのものづくりを加速させるアプリケーション実行基盤を実現する 」ことです。 LIFULLのものづくりを加速させることで、LIFULLの目指す「 あらゆるLIFEを、FULLに。 」という世界観実現にアプリケーション実行基盤というスケーラブルなアプローチで貢献します。 KEELチームにはその実現にあたって必要なスペシャリティを持ったメンバーが集まっていて、今後チームからのアウトプットを増やしていくためその紹介としてこのエントリを書くことにしました。 これまでは以下のようなエントリを書いてきました。 www.lifull.blog www.lifull.blog www.lifull.blog www.lifull.blog www.lifull.blog www.lifull.blog www.lifull.blog www.lifull.blog www.lifull.blog www.lifull.blog まとめ LIFULLにはKEELという全社アプリケーション実行基盤があり、アプリケーションの運用に必要な多くのものを提供しながら広範的に開発者を支援しています。 今後我々KEELチームからのアウトプットを増やしていきますのでご期待いただけると幸いです。 カジュアル面談もやっていますので、一緒に「 LIFULLのものづくりを加速させるアプリケーション実行基盤を実現する 」、ひいてはLIFULLが目指している「 あらゆるLIFEを、FULLに。 」することに興味がある方は是非お話しましょう！ hrmos.co

品質改善推進ユニットの中野です。 LIFULLでは、2015年に開発プロジェクトの支援を目的としたQAチームを立ち上げ、これまで様々な活動を行なってきました。 この記事では、QAチームの現在の取り組みや実行に至った経緯や考えなどを書いていきたいと思います。 組織の変遷に関しては、以前弊社の藤澤が投稿したブログがありますので、そちらもよろしければ、あわせてご参照ください。 www.lifull.blog QAのミッション QAチームは、プロダクト開発に関わるものづくりのメンバーが、安全かつ高速にリリースを繰り返すことを支援し、安心して開発に取り組める状況をつくることにあります。 さらにその先には、プロダクトライフサイクルにおけるステージ、サービスの特性、開発チームのプロセスや成熟度に合わせて、各チームにあったテスト戦略を見出し、改善を後押しすることで、ストレスの少ないものづくりが行われていくための仕組み作りを継続していきたいと考えています。 プロジェクトへのQAの関わり方 社内には異なる規模、異なるスケジュールで様々な開発や保守のプロジェクトが動いています。 QAは、LIFULLの各事業領域のサービスやプロジェクトの品質を向上させることを目指しています。 全てのプロジェクトへ均等な支援を行うのではなく、支援内容は、テスト技術の不足を補う視点で、プロジェクトの状況をモニタリングしつつ決定しています。 全体の活動イメージは下記の通りです。 各支援内容の目的は下記の通りです。 リスク分析・・・プロジェクトの施策内容、開発要件などを確認して事業インパクトやプロダクトリスクを把握し懸念があればサポートする テスト計画コンシェルジュ・・・テスト計画の作成を支援することでテスト戦略やアプローチを整理し、テストの効果や効率を向上させる リリース前リスク分析・・・プロジェクトの状況やテスト内容を把握しQA側でリスク低減のアクションの必要有無を判断する QAテスト・・・リリース前のテスト（主に探索的テスト）を実施し問題があれば開発側へフィードバックする QAサポート・・・開発プロジェクトにQAとして参加し、テスト全体、もしくは、一部分を担うことでプロジェクトのQCDを向上させる パフォーマンス監視・・・リリース後のパフォーマンスを監視し、問題があれば開発側へフィードバックする 本番障害分析・・・本番運用中に発生した障害情報を分析し、将来の開発に役立つようにテストなどの改善を検討する 関わり方の決定は、リスク分析を起点にQA側でアプローチする場合もあれば、ものづくりからの支援依頼を元に、テスト計画コンシェルジュや、QAサポートを行う場合もあります。 QAサポートの支援内容はプロジェクトによって様々で、相談だけで完結するものもありますし、レビューや特定のタスクだけを請け負う場合もあれば、プロジェクト全体を通してテストマネージメントを行う場合もあります。 テスト計画コンシェルジュ ユーザーにとってちょうど良い品質作りを効率よく行うために、テストのアプローチに過不足が出ないように「テスト計画コンシェルジュ」というサービスにより、テスト計画の作成代行やレビューの支援などにも力を入れています。テスト計画をサービスとして切り出している理由は、テスト計画の中で適切なアプローチの決定が、テストプロジェクトの明暗を分ける要因だと考えているからです。 言い換えれば、テスト計画の精度が高ければ、後工程にQAチームが関わらなくても開発チームのメンバーでテストを効率よく進めることができるのではないかと思っています。 余談ですが、このテスト計画コンシェルジュを始めた頃に比べると、数年たった今では、必要に応じて開発側でテスト計画を作ってテストの検討を進めてくれることも多くなったと感じています。 下記はテスト計画コンシェルジュの効果の期待を表したイメージです。 リリース前リスク分析を起点としたQAのアクション プロジェクトに参加しない場合でも、直近のリリース情報を元にQA側でリスクに応じて成果物の確認などを行います。 さらに必要に応じてリリース前のQAテスト（探索的テスト）を実施し問題があれば開発チームにフィードバックします。 テストにおける改善活動 開発チームの状況によって対応は様々ですが、成熟度が高いチームでは、品質に関わる活動をチームで考え、最適なテストやレビューなどを実践していきます。 また、安心して開発に集中できるようなストレスが少ない環境作りもQAチームの重要な役割だと考えています。 QAの活動としては以下のような取り組みを実施しています。 新卒エンジニアや様々な職種向けの研修の実施 探索的テストのチャーターの保守 テストツールの開発 テストデータの提供 システムテスト標準の作成 最後に 年々、支援を求められるプロジェクトの数も増え、難易度も上がり続けていますが、現場におけるテストの最適化や、テスト資産の利活用などまだまだ改善できる領域がありますので、現場に寄り添い継続的に改善に努めたいと考えています。 また、この記事では概要の説明に留めましたが、個々の取り組みについても、また別の機会に記事を公開する予定でいます。

AI戦略室の椎橋です。弊社で取り組んでいるディープラーニングの活用事例を紹介します。 空飛ぶホームズくん 空飛ぶホームズくんとは、平面の間取り図から3Dの部屋を生成する技術を用い（※特許取得済み）、バーチャル内見できるVRサービスです。詳細は以下のリンクに書いてあります。 lifull.com 平面の間取り図から３Dの部屋を生成する技術では主にディープラーニングを使っていて、今回はその計算処理について紹介します。 先行研究 間取り図の画像解析の先行研究では"Deep Floor Plan Recognition Using a Multi-Task Network with Room-Boundary-Guided Attention"があります。 https://openaccess.thecvf.com/content_ICCV_2019/papers/Zeng_Deep_Floor_Plan_Recognition_Using_a_Multi-Task_Network_With_Room-Boundary-Guided_ICCV_2019_paper.pdf これは間取り図のセマンティックセグメンテーションタスクの研究で、論文の資料を抜粋すると下図で(a)の入力画像に対して(b)が正解ラベルがになり(c)が推論結果として出力するディープラーニングモデルをつくるというものです。 論文の添付画像から抜粋 ニューラルネットワークの構築の考え方は下図にあるように部屋の種別(room type)か部屋を構成する境界(room boundary)かで2つの出力層を設けることできれいに壁とドアの位置を推論できるというものです。 論文の添付画像から抜粋, ニューラルネットワーク構築の考え方 LIFULLでの実装 LIFULLでは上記の先行研究のベースのアルゴリズムを踏襲しつつ、３Dモデルを作るためにいくつか変更を加えました。最も大きな変更は部屋の種別(room type)と境界(room boundary)に加えて、キッチンカウンターやトイレなどのiconを第3の出力層として新たに追加しました。下の画像だと左が元画像、中央がroom typeとroom boundaryのラベル、右がアイコンのラベルになります。セマンティックセグメンテーションではピクセル単位に分類タスクを行うので、画像の中央と右は各ピクセルにラベルを0,1,2,...と割り当てて可視化のために対応するRGB値で塗ってある画像になります。セマンティックセグメンテーションタスクの出力データ、すなわち、ピクセル単位にラベルを割り当てたデータのことを本記事ではセマンティックデータと呼ぶことにします。 LIFULLでのニューラルネットワーク構築の考え方 その他の変更点については本記事の最後に添付するslideshareをご覧ください。 推論後の後処理 後処理としてセマンティックデータから輪郭抽出して３Dモデルの生成に必要なデータ形式に変換します。opencvのfindcontours関数で輪郭抽出します。下の画像で左がセマンティックデータで1ピクセルごとにラベルが割り当てられていて、右が輪郭抽出後のデータで、白点で表したポリゴンの端点情報のみから可視化したデータになります。セマンティックデータは画像サイズ数の値を保持していて、変換後では白い点の数だけの値を保持していることになります。 推論結果(左)と輪郭抽出結果(右) 輪郭抽出することで間取り図のどこに何があるかをデータに落とし込むことができました。そこから平易な計算をすることで人間が間取り図をみて解釈できる情報を得られます。具体的には以下の項目です。 アイコンの向き 下図でキッチンカウンター、トイレ、洗面台を使うときに人間が位置する方向に白丸をつけました。これがないと３Dにしたときに違和感のある配置になってしまいます。 アイコンの向き判定結果 導線生成 人間が部屋間を行き来するための導線を計算できます。google mapにあるようなウォークスルーを実現するのに必要です。 導線生成 バルコニーの壁と室内の壁の判別 画像で見るとバルコニーの壁と部屋の壁は区別がつきませんが、常識的に考えてバルコニーは外の景気がみられるように高さが低くなっています。一方で室内の壁は天井まで高さがあります。下図でバルコニーの壁(緑)と室内の壁(赤)を色分けできています。 バルコニーの壁と室内壁の判定(右) グラフ構造 下図で廊下(corridor, 黒で囲ったノード)からldk(DK),west(洋室),out(家の外),bath_toiket_washing_room(洗面所)にエッジが引かれているように部屋がどのように結合されているかをグラフ構造にして知ることができます。2LDKの間取りで1つの部屋がリビングとつながっていないほうがいい、バルコニーに行き来できる部屋が２つある、などの2LDKよりもさらに細かい条件を検索できるようになります。 その他 その他としては縮尺を概算できたり、窓とドアの区別ができたりして、これらの人間が解釈できる要素を取り出していくことでより現実に近い３Dモデルの生成が可能になります。 最後に 間取り図のディープラーニング活用事例を紹介しました。間取り図の解析は機械学習界隈では頻繁に出てくるテーマではないので目新しさがあったと思います。弊社ではレコメンドやチャットボットなどの汎用性の高い技術でなく不動産のドメインに特化した研究開発も行っています。ドメイン特化の研究開発は世界で事例が少ないこともあり、難易度は低くないですが、その分やりがいはあるかと思います。 弊社では、執筆日(2020年11月)時点で機械学習エンジニアを募集しています。カジュアルな面談で弊社の様子をお伝えすることもできます。興味ありましたらご覧ください。 https://hrmos.co/pages/lifull/jobs/010-0041 hrmos.co LTechでも発表しました 【Ltech#11】ディープラーニングで間取り図を3Dにする from LIFULL Co., Ltd. www.slideshare.net

こんにちは、プロダクトエンジニアリング部の二宮です。 昨年に引き続き、今年も LIFULLのQiita Organization で企業アドベントカレンダーを行います🎉 LIFULL Advent Calendar 2020 LIFULL その2 Advent Calendar 2020 LIFULL 統計・機械学習編 Advent Calendar 2020 「株式会社LIFULLってどんなメンバーがいるの？」「どんな技術が使われてるの？」「どんな風に仕事しているの？」と興味を持たれている方は、それぞれの記事をご覧いただけると想像頂けると思います。 このLIFULL Creators Blogに比べて、Qiitaではより技術職メンバー個人の情報発信・共有にフォーカスしており、アドベントカレンダーでもそれぞれの工夫や発見を共有します。 それでは、12月1日からの更新をお楽しみに！

お久しぶりです、Ltech運営チームの秀野です！ 今回は、2020年10月29日(木)に開催した『 Ltech#11 不動産領域のAI活用最前線 〜初完全リモート開催〜 』についてレポートします！ Ltechとは Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。特定の技術に偏らず、様々な技術の話を展開していく予定です。 今回はなんと、Ltech初のリモート開催です！ インターネット万歳！！ 不動産領域のAI活用最前線 記念すべき初リモート開催となる今回のテーマは、『不動産領域のAI活用最前線』です。LIFULLの社長直轄のAI部門であるAI戦略室のみなさんから、ディープな話をしてもらいました。 AI戦略室については、こちらの記事でも触れていますので是非ご覧ください。 www.lifull.blog それでは各発表のレポートです。 ディープラーニングで間取り図を3Dにする 【Ltech#11】ディープラーニングで間取り図を3Dにする from LIFULL Co., Ltd. 最初の発表は、「空飛ぶホームズくん」の裏側で間取り図を3Dにするアルゴリズムについてのお話です。「空飛ぶホームズくん」は、3Dの街を移動しながら気になる部屋の中を見ることができる VR x AI のプロトタイプアプリです。 japan.cnet.com 間取り図をディープラーニングを使ってセマンティック画像に変換し、そこからポリゴンデータを生成することで3D化していきます。 セマンティックセグメンテーションのタスクで工夫した点として、壁/ドアなどの線と部屋をわけて処理する点があります。また、部屋をグラフ構造で持っていたり、非常に面白い内容でした。 人の作った間取り図ですから、機械学習といえども人による地道な作業が必要なんですね。ドアのない部屋、不動産会社のロゴ入り画像、などなど色々あります… 余談ですが、長時間のアノテーション作業で身体を壊しそうだったけど、筋トレをしていたことで救われた話には感動しました！ 住まい探しにおける対話AIの自然言語解析技術 【Ltech#11】住まい探しにおける 対話AIの自然言語解析技術 from LIFULL Co., Ltd. 続いて、自然言語による物件検索・地域検索を目指して開発している自然言語解析器についてのお話です。対話形式で物件を探すため、会話を検索条件に落とし込んでいきます。 形態素解析は行わず、シンプルに先頭から辞書を引いて解析しています。私もLIFULL HOME'Sのフリーワード検索で辞書を整備したことがありますが、画像解析の話と同じようにこちらも地道な作業が必要です。 結果を見てみると、ルールベースでもそれなりの結果が出ているようですね。 Q&Aでは、不動産関係のコーパスがないという話も出ていました。 LIFULL HOME'Sの住まいの窓口というサービスでの対話を使えないかと思いましたが、センシティブな内容が多いので使うのは難しそうだな…と思い直しました。 ガウス過程回帰を用いた広宣費予測と可視化 【Ltech#11】ガウス過程回帰を用いた広宣費予測と可視化 from LIFULL Co., Ltd. 休憩を挟んで次の発表です。 マクロな視点で広宣費を月あたりどれくらいかければ、目標を達成できるのかを可視化するツールを作成したお話です。 今回の発表の中で、私が最も理解できなかった発表となります！難しいぶん詳細に発表して頂けました。ざっくり言うと予算とリターンを軸にした関数を知りたい、ということです。 時系列予測のタスクを解くため、ガウス過程を使った回帰モデルを使っています。 ドメイン知識を入れ込みやすい 予測が分布で得られるので不確実性がわかる 過学習しない と、いった特徴があるようです。 私はチンプンカンプンだったのですが、発表後のQ&Aでは参加者の方からたくさんの質問があがっており、アンケートの結果などからも満足頂けたようで良かったです。 Kubernetesを利用した機械学習モデルの本番適用例 【Ltech#11】Kubernetesを利用した機械学習モデルの本番適用例 from LIFULL Co., Ltd. 大トリは、少し趣向を変えてインフラも交えたお話です。 LIFULLではKubernetesチームが開発・運用支援ツール「KEEL」を作ってくれています。そちらを活用しながら、物件の「おすすめ順」生成に機械学習を活用しました。 www.lifull.blog 機械学習のモデルを運用する上で、最初の選択肢としてAWSのSageMakerを利用する方法もありますが、柔軟なAPIを提供するために前述の「KEEL」を利用しました。 物件の検索結果を「おすすめ順」でソートするために、事前推論でスコアを検索エンジンに取り込んでおきます。 検索エンジンへのデータ投入処理がこちらのAPIに依存している以上、大量のデータが投入された時の安定性が課題でしょうか。現在は、APIのスケールしきい値は小さめに、CPIリミットは大きめにすることで、負荷のバラつきにうまく対応しています。 アフタートーク 最後に、登壇者全員でざっくばらんにアフタートークをしました！ コロナ禍が予測に与えた影響のような時事的な話題や、AI戦略室を有効活用してもらうために事業部側とどのように付き合っていくのか、など組織的な課題も聞けました。 専門的な領域であるほど、その活用は難しくなっていきます。 「AIコンサルタント」という職種を用意することで、ビジネスとの橋渡し役を置くアイデアは、今後AIの民主化を進め事業を加速してくれるだろう、と感じました。 最後に Ltech では、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。 今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします！ lifull.connpass.com

こんにちは！ LIFULLのSETエンジニアの Ruey です！ 今年の3月にISTQBの自動化エンジニア資格 CTAL-TAE (Advanced Level Test Automation Engineer)を取得しました。TAEの勉強で自動テストの効果を測るメトリクスが幾つかあることが分かりました。その中で工数を測るメトリクスをEMTE(Equivalent Manual Test Effort)単位で表現することが推奨されています。しかし、その時は説明を見てもこれに換算すれば何か嬉しいか分かりませんでした。 ちょうどある開発グループで自動テストを導入する案件がありましたので、実際のプロジェクトでメトリクスを計測し検証してみました。様々な知見が得られたので、今回はこの単位の紹介と使用例を紹介したいと思います。 目次 はじめに 自動テストのメトリクス EMTEとは EMTEを使って表すことができるメトリクス 支援案件 概要 自動テストの導入目的 テスト作業の効率化と工数の削減 テスト作業におけるヒューマンエラーの排除 品質の維持 支援方法と内容 結果検証と分析 EMTEに換算する 実行時間を換算する メトリクスを換算する EMTE使う際の注意点 工数と節約の費用対効果 最後に はじめに SETチームはLIFULLにある他の開発チームの自動テスト導入支援を行っています。 支援メニューは以下のとおりです： テストフレームワークの使い方紹介 テストケース作成のサポート 自動テスト環境構築のサポート 自動テスト実装のサポート CI/CD構築のサポート 自動テスト運用支援 自動化関するその他の疑問の相談 今回は依頼案件で構築した自動テストを使って、メトリクスを実際に測定して検証してみたいと思います。 自動テストのメトリクス ISTQB CTAL-TAEの シラバス では、自動テストのモニタリング、効率、効果を測るためのメトリクスとして以下が紹介されています。(細かい説明はシラバスを参照してください) External TAS metrics Automation benefits Effort to build automated tests 　⬅︎ 今回使うメトリクス Effort to analyze automated test incidents 　⬅︎ 今回使うメトリクス Effort to maintain automated tests 　⬅︎ 今回使うメトリクス Ratio of failures to defects Time to execute automated tests Number of automated test cases Number of pass and fail results Number of false-fail and false-pass results Code coverage Internal TAS metrics Tool scripting metrics Automation code defect density Speed and efficiency of TAS components 補足 : TAS(Test Automation Solution)は本文で「自動テスト」を表現しています。 数は多いので、今回は特定のメトリクスのみ取ってみます。 EMTEとは EMTEはEquivalent Manual Test Effortの略で、 いわゆる自動テスト全ケースを全て手動で行う場合の工数です。工数を測るメトリクスの単位として推奨されています。 EMTEは時間の単位として扱います。 例： 自動テスト実行時間→30分 全ケースを手動で行った場合→180分 であったとすると、 180分が1EMTE になります。 自動テスト実行時間をEMTEで表すと 0.16 EMTE になります。 EMTEを使って表すことができるメトリクス EMTEは工数関連のメトリクスに使われており、下記の三つになります 自動テストの構築工数 （Effort to build automated tests）： 自動テスト実行する環境構築、テストケース設計、テストケース実装などの 初期コスト 。 自動テストの結果分析工数 (Effort to analyze automated test incidents)： 自動テスト実行後の結果確認。Flakyのテストの再実行やデグレーションが発生しているとかの確認と分析などの 運用コスト 。 自動テストのメンテナンス工数 (Effort to maintain automated tests)： 自動テストのテストケースの修正やテストデータの整備などの 運用コスト 。 これから支援案件で構築した自動テストについてこの三つのメトリクスを計測して、検証と分析したいと思います。 支援案件 概要 まだ自動テストがないTチームに自動システムテストフレームワークBuckyを使ったE2Eテストシステムの構築を提案し、テストケースの選定戦略やテストケースの作成などの支援、またはメンバーにE2Eテストの知識やメンテナンスの方法を教えていきます。最終目標はSETチームの支援なしで自動システムテストが運用・保守される状態を目指します。 自動テストの導入目的 テスト作業の効率化と工数の削減 テストを自動実行できれば手動で行っていたテスト工数を大幅削減できる。複雑なシナリオや準備に時間がかかってしまうテストも何度でも繰り返して実行することができます。 テスト作業におけるヒューマンエラーの排除 テスト作業の漏れや見落としを防ぎます。 品質の維持 障害になるとビジネスに多大な影響を及ぼす機能について継続的に自動回帰テストを実行することでソフトウェア（サイト）の品質を維持させます。 リリース前にデグレを発見することで、素早く、絶えずソフトウェア（サイト）を改善を行えます。 支援方法と内容 週定例を開催： ・定期的に相談できる窓口を作る ・構築状況の共有 ・自動テスト知識の教育 ・ペアプロでテストケース作成と実装 システム構築： ・自動システムテストフレームワークBuckyの実行環境構築 ・構成や実行方法などを教える ・CIとの連携設定 結果検証と分析 支援内容が無事に完了し、テストケースが自動で実行されています。 リリースフローにも自動システムテスト結果の確認する工程を組み込むことで必ずチェックされる仕組みになりました。 実行時間について： 自動テスト実行時間は 531s 全ケースを手動で行う時間は 5650s ( 1 EMTE = 5650s ) EMTEを使って表すことができるメトリクス を使って分析します： メトリクス 時間 自動テストの構築工数 349200s 自動テストの結果分析工数 1800s 自動テストのメンテナンス工数 1800s 工数は時間を出しましたが、時間のみだと実際の効果が分かり辛い状態でした。 EMTEに換算する 1 EMTE = 5650s 実行時間を換算する 自動テスト実行時間は 0.094 EMTE 計算式【 531 ÷ 5650 ≒ 0.094 】 全ケースを手動で行う時間はもちろん 1 EMTE EMTEに変換したら、手動で実行する時の工数と相対的に比較できます。すぐに分かったことは二つあります。 自動テスト実行時間は0.094 EMTE、手動テストの0.094倍の時間となりかなり効果がある 一回の自動テスト実行は手動より0.906 EMTEの時間が節約ができる。 計算式【 1- 0.094 = 0.906 】 節約された時間を他の開発やテストに充てられるので、自動テスト還元効果になります。 メトリクスを換算する メトリクス 計算式 EMTE 自動テストの構築工数 349200s (構築工数) ÷ 5650s (1EMTE) 61.81 自動テストの結果分析工数 1800s (結果分析工数) ÷ 5650s (1EMTE) 0.32 自動テストのメンテナンス工数 1800s (メンテナンス工数) ÷ 5650s (1EMTE) 0.32 メトリクスから分かったことは、初期コストの自動テストの構築工数は一見自動テストを全て手動で行う場合の61倍大きい数字ですが、これは節約された時間で割ると 68回 の自動テストが運用されれば、構築工数が還元されることが分かります。毎日実行で考えたら、二ヶ月くらいの運用でプラス効果になると思います。 計算式： 【 自動テストの構築工数 ÷ 一度の自動テスト実行で節約できる工数 = 何回の自動テストで還元できるか 】 【 61.81 ÷ 0.906 ≒ 68.22 】 さらに運用コストも考慮した場合、自動テストの結果分析工数と自動テストのメンテナンス工数が毎回発生するとは限りませんが、仮に毎回両方発生しても節約時間を超えていないので、自動テストはマイナス効果が出ないと思います。 判定式： 【 一度の自動テスト実行で節約できる工数は結果分析工数とメンテナンス工数の和より大きいのか 】 【 0.906 > (0.32 + 0.32) → True 】 EMTE使う際の注意点 自動テストは実行すればするほど節約された時間として還元されますが、通常の運用以外の実行では還元されません。 例えば開発フローにおいて1リリースに対して1回自動テストを実行する運用（通常の運用）なら、この1回の実行が節約された時間として還元ができます。それ以外の再実行などは最初のテスト結果と同じなので、テスト自体の効果はなく節約された時間として還元できません。 参考記事： Automation benefit measured by EMTE - good or bad? 工数と節約の費用対効果 先の節約時間と還元を図にすると、費用対効果がより分かりやすく表示できます。 (仮で毎回発生)運用コスト + 初期コスト と 削減工数 初期コストと運用コストを計算すると自動テストが233回運用されれば、工数が還元されます 初期コスト と 削減工数 初期コストのみ計算すると自動テストが68回運用されれば、工数が還元されます 最後に EMTEを実際に使ってみたら、自動テストの効果が分かりやすく伝えられることがわかりました。 自動テストはよく初期導入コスト、学習コスト、運用コスト、メンテナスコストが高いから導入しないことが多いですが、どのくらい高いのかはあまり具体に表現できないケースが多いです。それは普段の工数は時間で表現していますので、長いか短いのかが分からないためです。EMTEで換算すれば手動で実行する場合と相対的に比較できるので、実際に自動テストは消費した工数より、プラス効果になるのかがすぐ分かります。 もしくは何回分の実行で初期コストの還元の目標を立てて、自動テストの実行時間を逆算し、導入したい自動テストが目標時間に満たせるかの判断材料としても使えるかなと思います。 みなさんも是非EMTEをご活用していただければと思います。

こんにちは！ LIFULLのエンジニアの孫です。 メールやLINEを利用した開発作業をメインにしています。 今回は自分が担当していた物件更新情報LINE受け取り機能の仕組みについて紹介したいと思います。 物件更新情報LINE受け取り機能とは LIFULL HOME'Sに掲載されている新築マンションでユーザが希望した物件の情報が更新された際にLINEに通知がくる機能です。 ▼物件更新情報LINE受け取り機能紹介ページ https://www.homes.co.jp/smp/mansion/shinchiku/line/update-message/about/ ユーザが求めている情報をより早くより近くに届けるための施策となります。 この施策を進める中で一番気を付けていたLINEから受け取る個人情報の扱いがキーになっていたので その個人情報の扱いを中心にどういう仕組みで開発していたのか記載していきます。 処理概要 機能紹介ページに記載されているステップの裏側で動いている処理を簡単に記載しますと以下の流れになります。 全体の構成図 ※LINE User IDとは 各LINEチャネルでユーザを識別するための識別子。 構成的にLINEユーザ情報を各システム間で連携する必要だったため 機密チームと綿密に相談しながら考えた上、上記のような構成になりました。 詳細は以降述べます。 LINEログイン認証機能の仕組み ▼LINE側の処理については以下を参照ください。 https://developers.line.biz/ja/docs/line-login/integrate-line-login/ AWS KMS、ElasticCached利用について 現状LINE User 情報を連携する方法としてAWS KMS、ElasticCacheを利用しています。 呼び元にPOST APIを用意し直接更新処理を叩くのも可能でしたが、今後の拡張性を考慮すると当機能を呼び元に属しないものにする必要がありました。 なので許容されたIPのみで利用できるGET API用意し、呼び元からはキーにて暗号化されたLINE User 情報を取得・複合化することで独立的で安全に個人情報を連携できる仕組みになったと思います。 Marketing Cloud 配信処理について Marketing Cloudとは Marketing Cloudはセールスフォースが提供するMAツールです。 メールやLINEへの送信自動化や分析する処理を比較的に簡単に作れます。 www.salesforce.com 処理内容 Marketing Cloudではデータを外部からファイルで連携のためにSFTPサイト、SafehouseとGPG暗号化方式などを提供しています。 ※Safehouse とは 認証されたユーザのみがアクセスできるファイル保存場所です。 アクセスユーザはMarketing Cloudとは個別で管理されています。 help.salesforce.com なのでAutomation（Marketing Cloudで言う一連の自動化処理）を作成する際、連携されたGPGファイルをSafehouseへ転送、GPG複合・解凍行うことで個人情報へのアクセスをできるユーザを最大限制限しています。 まとめ 現状この仕組みは「物件更新情報LINE受け取り機能」で使っていますが、他にもLINEを介してユーザへ届けるべき情報があれば活用できるものにしていると思いますので今後、利用される施策が増えていくように頑張りたいです。 また、LIFULLではエンジニアメンバーを募集しております！ ご紹介のミッションを担当する求人です。ご興味ある方は是非ご応募ください！ https://hrmos.co/pages/lifull/jobs/010-0030 hrmos.co

みなさま、はじめまして。AI戦略室の嶋村です。 我々AI戦略室では、機械学習・深層学習・数理最適化・時系列解析・画像処理・自然言語処理などの技術を活用した様々な研究開発プロジェクトを推進しています。私はそれらのプロジェクトを統括する研究開発マネージャの立場にいます。 今回、LIFULL全社に対して研究開発成果を大々的に公開する『AI成果展示会』を開催しました。その目的や内容、どのような反響を得たのか、皆さまにご紹介します。 AI戦略室とは？ はじめに、AI戦略室について簡単に紹介をさせて下さい。 AI戦略室は、2018年に設置された社長直轄のAI部門です。『創造と革進で喜びを届ける』というビジョンを持ち、LIFULLが持つ様々なビッグデータにAI技術を活用し、新体験につながるサービスを創出することを目指しています。将来的な競合他社との差別化を見据えた『AI技術シーズの創出』と、短中期的な事業貢献につながる『AI技術シーズの活用』の、2つのミッションを持ち、AI技術をビジネス実装するべく日々研究開発に取り組んでいます。 組織の設置から早2年が経とうとしており、最初は少人数で始まった組織も、会社とともに成長を続けています。最近では、日本語がネイティブ並みにペラペラな多国籍のメンバも在籍しています。メンバそれぞれの個性や強みを最大限に活かせるように、以下の3つの役割を設定しています。これらの役割同士で円滑に連携することで、研究開発を加速させています。 AIコンサルタント ビジネス課題を抽出して、チーム内で連携することにより、ビジネス課題の解決まで推進する役割 データサイエンスエンジニア ビジネス課題から技術課題を抽出して、課題解決のための技術を開発し、効果検証して導入を促進する役割 AIエンジニア ビジネス課題に適した技術を選定し、実サービス上で、実運用に耐えうるシステムを開発する役割 さらに、社外との連携も深めており、同分野で著名な方々とも協業させていただいています。 日立製作所社　フェロー　矢野 和男氏（ AI戦略室エグゼクティブフェロー ） シンギュレイト社　Chief Scientific Officer　鹿内 学氏（ AI戦略室データサイエンスパートナー ） 人工知能学会　編集委員長　清田 陽司氏（AI戦略室主席研究員） 以上の体制で研究開発に取り組んでいます。最近の研究開発成果を少し紹介すると、例えば『 VRで「したい暮らし」探しを実現するAndroidアプリ「空飛ぶホームズくん」プロトタイプを不動産テックEXPO（大阪）で公開 』への貢献があります。こちらは深層学習を活用し、間取り図画像から3D表示用ベクトルデータの自動生成システム部分を我々AI戦略室が実装しました。 AI成果展示会 さて、本題である、AI成果展示会に話を移します。 まず、AI成果展示会の目的に触れます。一般論になりますが、研究開発組織はコストセンターになりがちで、事業部と距離が遠いことも珍しくはありません。もしそのように認識され続けると、いずれ組織が解体される恐れもあり、それは会社全体の弱体化につながります。そのため、研究開発組織が近視眼的に売上や利益ばかりを見る必要はないものの、会社全体に対してどのような貢献をする組織なのか、自身でしっかりと認知し、その成果が会社の貢献につながると認知してもらう必要があると考えています。 そこで、AI戦略室の活動や成果を認知してもらい、組織のプレゼンスを向上させ、社内で円滑に連携できる関係性を作り新たなサービスの共創につなげるために、AI成果展示会という形で社内に発信する場を設けました。AI成果展示会の開催後に成功したイメージを明確にするため、以下のスローガンを設定しました。 活動の意義を認めてもらう（全社員に） 投資したいと思ってもらう（経営層に） 活用したいと思ってもらう（実サービスで） この展示会の運営チームは、新卒を含む若手中心で形成しました。それは、新卒のメンバはまだ配属されて数ヶ月ですが、「運営チームの活動を通じて組織全体の活動が俯瞰して見えること」「先輩社員とのコミュニケーションが活発になり組織強化につながること」「重要な役割を持ってもらうことで貴重な経験を積み今後の推進も期待できること」などの面で成長してもらいたいと考えました。こちらの運営チームの奮闘により、部署内のメンバが一丸となって進められたと思います。 今回は「目玉企画となる招待講演」と「各メンバのプロジェクトのセッション」を行い、合計19件の発表を行いました。 目玉企画となる招待講演は、データサイエンスパートナである鹿内さんに『AIって何？研究開発って何？』というテーマで話していただきました。AI技術の最近の動向や、AIが何をしているのか、AIの基本的な用語について説明があり、社内での理解が深まったのではないかと思います。さらに、研究開発の難しさや特徴、研究開発組織との連携方法や信頼関係構築の重要性など、ピープルアナリティクスの専門家としての意見も大変参考になりました。 『AIって何？研究開発って何？』 データサイエンスパートナ鹿内学 招待講演に続いて、パネルディスカッションを開き、『研究開発と技術開発の共通点は？違いは？〜シナジーを生み出すために』のテーマついて座談会がありました。研究開発と技術開発の共通点や相違点について意見が交わされ、研究開発組織であるAI戦略室が他部署からどう見えるのか等、我々にとっても興味深い座談になりました。 『研究開発と技術開発の共通点は？違いは？〜シナジーを生み出すために』 データサイエンスパートナ鹿内学 　×　 CTO長沢翼 　×　 ジンジニア木村修平 「各メンバのプロジェクトのセッション」の一例として、LIFULL HOME'Sでの物件レコメンドに関する発表を紹介します。この発表は、不動産情報サイトであるLIFULL HOME'Sにおいて、よりユーザに魅力的な物件を提案するためのレコメンドアルゴリズムを開発した取り組みです。発表者はデータサイエンスエンジニアとして仮説検証しながら、率先してシステム開発もした良いプロジェクトですので紹介しました。下図に示すように、機械学習モデルをプロダクトで活用する際の流れが示され、モデル開発・システム開発・実証実験（A/Bテスト）のそれぞれの段階での工夫について発表がされました。図の通り、現在はA/Bテストを繰り返してより良いレコメンドアルゴリズムを開発しており、本運用で稼働できるように日々仮説検証を進めています。 これらの発表の一部は弊社エンジニア向けイベントである Ltech でも10月後半に発表予定ですので、ぜひご参加いただければ嬉しいです。以下の発表が行われます。 深層学習を用いた間取り図画像の解析 広告宣伝費最適化 機械学習を活用したレコメンド 自然言語処理による対話文章解析 これまで写真でご紹介した通り、Zoomを活用してオンラインで開催しました。前回は半蔵門本社でポスターセッションを行い、リアルなフィードバックを得ることができたのですが、今は新型コロナウイルスの影響下のため開催方法には悩みました。弊社では9月30日は期末の多忙な時期なのですが、しっかりと我々の成果がお伝えできたのではないかと思います。また、もっと他部署の社員が気軽に参加でき、有意義な意見交換ができるようにする必要性も感じたため、次回はより良いやり方を模索していきたいと思います。 おわりに 以上がAI戦略室によるAI成果展示会の開催レポートです。いくつか課題は見つかったものの、AI戦略室が一丸となり、期の締めくくりとして盛大にAI成果展示会を開催できて嬉しいです。10月からの新たな期もどんどん研究成果を出していきたいと思います。 今後は社内だけでなく、社外での発信も増やしていきたいと考えています。その際は是非みなさまにもAI戦略室からの発信を届けられればと思います！ また、LIFULLではメンバーを募集しております。AI戦略室でAIエンジニアも募集予定です！ カジュアル面談もありますのでご興味ある方は是非ご参加ください！ hrmos.co

こんにちは！クリエイターの日運営委員の松岡です。 みなさんは「スマートホーム」という言葉をご存知でしょうか？ 例えば「家に近づくとエアコンが自動的に起動する」「音声でテレビを操作できる」など、スマートホームとは、様々なデバイスをインターネットに繋ぐことで便利な生活ができる家のことを指します。 LIFULLではコロナの影響もあり在宅ワークが基本の状態になっており、自宅の生活を豊かにする需要が高まっています！ そこで「クリエイターの日」のイベントの一環として「おうちハック！」と銘打って最新のテクノロジーを用いたオンラインハッカソンを開催しました！ ※クリエイターの日とは？ 希望者が、3ヶ月ごとに最大7営業日を使って、好きなものを開発することができるLIFULLの制度です。 LIFULLでは、マーケティング能力や技術開発能力を高めてイノベーションを創造するため、通常業務の枠を離れて、新たな技術や手法に取り組む機会となっています。 開催概要 まずハッカソンのテーマは「スマートホーム関連機器を使って自宅での生活をより便利にする仕組みを作る」としました！ また期間としては1週間の中の空いている時間で作業・開発をしてもらい、それぞれの自宅でスマートホーム関連機器を用いた仕掛けを作っていただきました。 最終日では実際に仕掛けを動画に撮った上で発表をしていただき、その結果順位を決定し、優勝者には豪華賞品を贈呈する形としました。 発表内容 それでは発表内容を見ていきましょう！ １．シェアハウスのリビングをキリンに深夜監視させてみた 最初の発表は、こちらのMESH、IFTTT、Nature Remoを使ったアイデアです。 シェアハウスに暮らしていると、誰かが消してくれるだろうと思ってつい電気を消し忘れてしまう。 そんなシェアハウスの課題解決のため、このアイデアが生まれたとのことです。 まず、 MESHで人がリビングにいなくなったこと、及び部屋の明かりが付いていることを検知 します。 次に IFTTT経由で、Nature Remoが照明を消し、LINEがグループに通知を送る という仕組みです。 電気代を節約できたという実績もあり、シェアハウスでなくても活用が可能そうな素晴らしいアイデアだと思います。 ちなみに今回は実験的にMESHを使いましたが、Nature Remoにも人感センサーがあるため、MESHを使わなくても実装は可能です。 ２．よく行方不明になるプテラノドンをすぐに見つけられるようにした 続いての発表は、tileとGoogle Homeを使ったアイデアです。 娘さんが大事にしている人形「プテラちゃん」をなくなった時に、手軽に見つけられるようにするアイデアです。 アプリで操作すると音を鳴らせるタグ、 tileをGoogle Homeに連携 させ、「プテラちゃんを鳴らして」と言うと プテラちゃんに付いたtileが鳴る という仕組みです。 tileだけでも便利ではありますが、幼児だけで扱える音声デバイスとあえて連携させたアイデアです。 仕事や家事で忙しい時、手軽に使えるのが魅力的です。 ３．私が求めていたのは話し相手でした 3つ目の発表は、在宅だとどうしても座りっぱなしになってしまうため、運動不足を解消したい！というアイデアです。 デモではIoTデバイスの Nature Remoを利用 し、自身の動きを計測することで 座りっぱなしを検知 しておりました。 「立派なお腹ですね。ダラダラ働いていないで外でも走ってきてはいかがですか。」と Google Homeに話しかけられる ことで運動を促す仕組みのようです。 製作者は「運動不足解消を目指していたけど、Google Homeに話しかけられて嬉しかった」とのことで、在宅によって本当に不足していたのは話し相手だったというのはとても共感できる部分です。 AWS LambdaでNature Remoからデータを取得し、アラームでSlackやGoogle Homeに通知するなど、裏側の部分もしっかり作り込まれた作品でした。 ４．1分でできる！簡単IoTで防犯対策 最後の発表者は、meshを使うことで誰もが気軽に防犯対策ができるアイデアを考えてきてくれました。 実は空き巣の被害は鍵を閉めていなかったことが原因である割合が最も高いとのことです。 MESHのMoveで 動き傾きなどが検知することができるため、ドアのサムターン（鍵の部分）に貼り付けて 鍵の開閉を検知 します。 設置が終わったらMESHのアプリをダウンロードして、デバイスの傾きとメール通知をアプリ上で簡単に紐づけることができるようです。 アプリ連携からメール通知 まで１分で完了したとのことで、とても手軽に利用できることがわかります。 問題提起から誰でもできることで予防策を提示するところまでしっかり考えられたアイデアでした。 結果発表 優勝は「 私が求めていたのは話し相手でした 」となりました。 在宅での運動不足という課題を解決するだけでなく、Nature Remoから取得したデータをAWSのCloudWatchやLambdaと連携したりするなど技術的にもいろいろ実装されていたのが高く評価されました。 まとめ 今回はハッカソンという形でしたが、エンジニアだけでなく企画の社員にも参加していただけました。また、成果物の発表会にはたくさんの方が参加してくださいました。 最近は、MESHなどをはじめコードを書かなくても簡単なプロダクトが作れてしまったりするので、これを機に興味を持った方が次のイベントに参加して少しずつ社内のこのようなイベントも盛り上げていければいいなと思いました。 開催日：2020年9月18日 弊社では、一緒に働くメンバーも募集しています。 recruit.lifull.com

プロダクトエンジニアリング部のカマトです。 普段はマーケティング・エンジニアとして、LIFULL HOME'SでLINEやメールを活用したサービスの開発に従事しています。 今回は業務でシステムの刷新を行う中で、アーキテクトにクリーンアーキテクチャを採用し初めて経験しましたのでこちらについてお話しをさせていただきます。 新しいアーキテクトに触れるときは、このレイヤーは何を担当しどのような概念でどのような機能を持たせればいいのか？と理解するをするまでいつも苦戦するのですが、クリーンアーキテクチャは特に登場人物が多く今まで以上に大変でした。 このクリーンアーキテクチャの処理の流れを日常のものに置き換えれば、別な視点で理解が深まるのではと考え、各レイヤーの概念を定食屋のフローに落とし込んで表現をし振り返りをしてみようと思います。 参考にしたイメージ図に沿ってのレイヤーと概念ですので、これにそってなければクリーンアーキテクチャではないということはないです。 クリーンアーキテクチャはこうすればいい！や、このような思想でやってください！というものではないので暖かい目で見ていただけれたら嬉しいです。 さてクリーンアーキテクチャというと、この図がよく出てくると思います。 出典：The Clean Code Blog https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html これともう一つ。 出典：図解クリーンアーキテクチャ https://qiita.com/kz_12/items/bc79102247b86626fc72 こちらもよく見ますね。 この図の構成を定食屋さんのフローに置き換えて表現したものがこちらになります。 かなり強引なものですが各概念をレイヤー毎に説明をさせていただきます。 Enterprise Business Rules Entities まず、どの定食屋さんでもお客さんに提供するために必要なものは料理のメニューですね。 唐揚げ定食であれば 唐揚げが5個 サラダ ご飯 味噌汁 といった内容です。 Application Business Rules 調理開始 Use Case Interactor  コックさんが厨房に立ちフロアスタッフが伝票置き場(Input Boundary)へ置いてくれた伝票に書かれた注文情報を見て、メニュー内容(Entities)を思い出し料理をします。 料理に必要な食材の指示を出し(Data Access Interface)、材料が集まり料理(Output Data)が完成したら受け取り口に料理を並べ、横に伝票(Output Boundary)を置いておきます。 注文情報 Input Data お客さんの注文仕方は様々です。 厨房のコックさんが作業しやすいように注文内容を整理した言葉に変換してます。 からてい 一つ → 唐揚げ定食 1人前 伝票置き場 Input Boundary フロアスタッフの人は厨房に入りませんので、整理した言葉(Input Data)で作った伝票をコックさんがメニューを出してくれるところに置いておきます。 必要材料の指示 Data Access Interface コックさんが倉庫・冷蔵庫(Data Access)から用意して欲しい食材を指示します。 受け取り口 Output Data コックさんの元に材料を届けると材料が揃ったので料理を開始します。 ここで完成した料理を受け取り口に料理を並べます。 伝票置き場 Output Boundary ここでフロアスタッフがどの注文に対しての料理なのかをわかるように、料理の横に伝票を置いておきます。 Interface Adapters テーブル(注文をうける) Controller 次にどこのお店でもお客さんがする行動である注文です。 フロアスタッフがお客さんから注文を受け取ります。 ここでうけた注文は伝票を使い(Input Data)、作ってもらいたいメニューを調理場へ伝えます。(Input Boundary) 提供準備 Presenter 厨房から出された料理を受け取り口で受け取り(Output Data)、提供するテーブルを伝票で確認したら(Output Boundary)お客さんが気持ちよく食べられるよう、お盆に食器、箸やスプーン、フォーク味噌汁なども揃えてテーブルへ運びます。 テーブルViewModel お客さん(View)がいるテーブルへ料理を提供します。 倉庫係 Data Access コックさんからの依頼通り(Data Access Interface)に、様々な業者に発注していた食材がある(倉庫・冷蔵庫)から調理に必要な食材を取り出して送ります。 倉庫・冷蔵庫 Data Base 倉庫や冷蔵庫には様々な業者に発注した食材や調味料が並んでいます。 倉庫係さん(Data Access)が必要なものを発注をしたり、取り出したりします。 お客さん View 注文された料理が来たらお客さんは食事を開始します。 依存関係について クリーンアーキテクチャで重要になると思われる依存関係(上位のモジュールは下位のモジュールに依存してはならない。)ですが、以下のように表現しています。 メニュー内容(Entities)が唐揚げ5個から3個になったらコックさんの振る舞いも変わり、倉庫係の方が倉庫や冷蔵庫から用意する材料も変わります。 コックさんが別な人に変わったら、レシピも変わるので、倉庫や冷蔵庫から出す材料は変わるかもしれません。ですが毎日出しているメニュー内容に変わりはありません。 そして倉庫や冷蔵庫が変わったとしても必要になる材料は変わらないので、コックさんの指示に影響は出ないはずです。 依存関係逆転の原則 もう一つクリーンアーキテクチャで大事な依存関係逆転の原則ですが、こちらは振る舞いを下位モジュールへの作業の依頼(伝票や用意してもらう食材の指示)という形で表現してみました。 これによりフロアスタッフの方や、倉庫係の人に依存せずコックさんは作業を続ける事ができます。 (一応ここでの表現の中での話ですが、上位モジュールが立場が上というわけではありません。) まとめ どうでしょうか？かなり強引でしたので、間違っている表現もあると思いますが、思ったよりいい感じなのではと・・・。 ちなみに自分は学生の頃にファミレスでアルバイトをした経験があるくらいしか料理の経験はありません。 難しい言葉で半分くらい理解して進めるといざという時にどうだったかな？と手が止まってしまいますが、こういった自分が普段使っている言葉に変えて整理してみるとすんなり入ってきませんか？ クリーンアーキテクチャに限らず普段の業務などで、ここはこういう表現の方がいい、こうした方がわかりやすいというものを考える機会にしていただけたら嬉しいです。

こんにちは、LIFULLでLINEやメール周りを担当しているエンジニア三宅です。 LIFULL HOME'Sでは、これまでエンドユーザとのコミュニケーションは次のとおりでした。 オフライン：店舗（LIFULL HOME'S 住まいの窓口）、電話 オンライン：Web、メール、チャット しかし、エンドユーザの利用率や利便性を考え、2019年からLINEを使ったコミュニケーションサービスの配信を開始しました。 現在ではLINEで物件相談が出来たり、一人一人の住み替えステップに応じたメッセージ配信をおこない、ユーザのアクションによって適切な情報を配信するサービスを提供するなど、よりオンラインでのコミュニケーションが強化されています。 今回はLIFULLで提供しているLINE活用の取り組みの中から「住み替えサポート」を紹介したいと思います。 住み替えサポートとは？ 住み替えステップに合わせた便利機能で、住まい探しから引越しの準備までをLINEでサポートする機能です。 住み替えに役立つ情報やお得なキャンペーン情報もお届けします。 以下詳細です。 物件レコメンドメッセージ LIFULL HOME'Sで問合せをした物件と似た物件をメッセージでお届けします。 住み替えステップに応じたメッセージ 住み替えステップ（物件見学予定、物件見学済み、物件契約済み、転居完了）に応じたメッセージをお届けします。 以下は見学予定の方メッセージです。 賃貸で反響を行うと、自動で画面下部のリッチメニュー が「住み替えサポート」専用のものに変更されます。 以下は見学完了の方のメッセージです。 以下は契約完了の方のメッセージです。 リマインド機能 物件見学日を登録しておくと、前日にリマインドメッセージをお届けします。 お役立ち情報配信 物件見学必要な持ち物チェックリストや引っ越し後の手続きなど住み替え完了までに必要な情報をお届けします。 以下は「引っ越し一括手続きサービス」のお知らせです。 注）上記の画像は2020年10月現在のサービス画像の為、変更の可能性があります どんな風に動いてる？ 「住み替えサポート」がどのようにして動いているか少し説明させてください。 住み替えサポートの処理概要は以下となっています。 ①サンクスメッセージ LIFULL HOME'Sで物件問合せをしてくださった方にLINEでメッセージを配信します。 ②ユーザのアクション（友達になった、メッセージのボタンをクリックしたなど）があるとLINE社を通じてwebhook APIへ通知される 「LIFULL HOME'S公式アカウントに友達になった」、「弊社から配信されたメッセージ内のボタンをクリックした」などのアクションがあった場合、LINE社を通じて、webhook APIに通知されます。 ③webhook APIからアクションに応じた処理を行う。 ユーザのアクションによって処理を分けるのですが、大まかには以下の３つになります。 アクションをデータベースに格納する 即時メッセージ配信用のAPIにリクエスト リッチメニュー(*1)の切り替え ④条件に合致したユーザに対してLINEメッセージを配信する メッセージ配信は大きく分けて２つあります。 弊社では即時メッセージ配信は独自APIを使っており、定期メッセージ配信はMarketing Cloud(*2)というツールを使っています。 即時メッセージ配信（ボタンタップ時に即時メッセージ配信） 定期メッセージ配信（ユーザの状況に応じた定期メッセージ配信） LINE株式会社が提供しているMessaging APIを用いて開発を行っています。 次のドキュメントを参考にすれば、さほど開発は難しくありません。 developers.line.biz 「住み替えサポート」は、最適なタイミングで、ユーザが必要とするコンテンツが配信される事に価値がある機能です。 そのため、ユーザのアクション単位で処理を行うことで、セグメントごとに配信するメッセージを切り分けています。 *1 リッチメニュー とは LINE公式アカウントのトークを訪れた際、画面下部に大きく開くメニューです。 「 リッチメニュー｜LINE for Business 」より引用 *2 Marketing Cloudとは www.salesforce.com 開発時の小話 上記の処理概要部分でも記載しましたが、メッセージの配信は、LINEの「Messaging API」を利用しています。 「Messaging API」は、JSONでUI・UXを表現しますが、その仕様上、HTML+CSSのように細かいデザインの調整を行うことができません。 できない例 空白行の縦幅の微調整 画像サイズの微調整 文字サイズの微調整 そのため、デザイナーと相談しながら、できる範囲で最適な物をチョイスしながら進めました。 非常に見やすくなっていると思うので、是非見てみて下さい！ LINE活用のその他事例紹介 今回は細かくは記載しませんが、その他にも様々な施策があります。 軽く紹介させてください。 サンクスメッセージ 処理概要のところで少し触れましたが、LIFULL HOME'Sで物件問合せをしてくださった方に送るメッセージです。 LINE株式会社が提供する「通知メッセージ」というサービスを使っており、LINEに登録されているユーザの電話番号と、LIFULL HOME'Sで物件問合せをする際に入力されたユーザの電話番号とを照合させることで、友だち登録していないユーザーに対してもメッセージを送ることができます。 LINEで問合せた物件が確認できるのでLINEをよく使う方には便利な機能となっています。 AIおウチ診断 検索条件を決めることなく理想の物件をAIが学習・提案してくれる機能です。 質問に答えていくだけで理想の住まいが楽しく検索できる機能となっています。こちらの診断を元により理想の住まいへのイメージを膨らませていただければ幸いです。 物件更新情報LINE受け取り機能 現状は新築分譲マンション領域において、情報の更新があったらLINEで通知してくれる機能です。 新築分譲マンションは完成までに時間がかかるので、未完成の状態でLIFULL HOME'Sのような物件検索サイトに掲載されます。 随時情報が更新されるのですが、物件の情報に更新が入るとLINEで通知してくれるので非常に便利な機能です。 どれも便利・面白い機能ですので、是非使ってみてください！ 最後に 今では公式アカウントの友達数は180万人を超えています。 もっと一人一人に沿ったタイミングで、最適なコンテンツを届けられるように「ユーザに寄り添ってサポートできる」「もっと痒いところに手が届く」サービスにしていきたいと思います。 今後、新たなLINE活用も進めていく予定ですので、是非「LIFULL HOME'SのLINE公式アカウント」をご活用ください。 LINE公式アカウントは こちら から

技術開発部の相馬です。好きな JS モジュールバンドラーは Rollup です。 表題のとおりですが、今回は Node.js を使って PHP のテンプレートエンジンである Twig のプリプロセッサーを作り、言語機能の拡張をしてみた話についてご紹介したいと思います。 はじめに 弊社のメイン事業である LIFULL HOME'S の開発の歴史は長く、技術的負債と呼ばれるモノも多く存在しています。 これらの問題に対し、現在弊社ではエンジニアが組織として負債の解消に取り組むような体制が整っています。 フロントエンドの開発環境の改善については、以前ご紹介したので次の記事をご覧ください。 www.lifull.blog 今回は、テンプレートエンジンにまつわる改善についてご紹介したいと思います。 LIFULL HOME'S のサーバーサイドは PHP（Symfony）で構築されており、テンプレートエンジンには Twig を採用しています。 Twig には構文拡張の機構が備わっており、対応するトークンパーサーやノードなどを PHP のコードとして記述し、エクステンションとして登録することで独自のタグを解釈させることなどが可能です。 twig.symfony.com しかし、当然のことながらこれらは Twig コードが PHP を生成するタイミングでのコンパイル時にしか干渉できず、ツールとしての再利用性はほとんど存在しません。 そこで、時代は AST（Abstract syntax tree）ということで「Node.js で Twig の parser/traverser/codegen を作ってしまおう！」という決断をしました。 Twig の三種の神器（parser/traverser/codegen）作成に関する詳細は、次の記事をご覧ください。 www.lifull.blog 作成言語に Node.js を採用した理由については、 以前 Node.js 環境を整えたのでそのまま利用できたこと 開発陣が JavaScript の取り扱いに長けていた のが主な要因でした。 神器が整えば、あとは lint なり format なり好きにし放題ということで、手始めに言語のプリプロセッサーを作ってみることにしました。 なぜプリプロセッサーを作るのか？ Twig のバージョンを上げず に、擬似的に上位バージョンの API やメインストリームには存在しない API などを実装することができるからです。 一般的に、言語のメジャーバージョンアップなどビッグチェンジを含むようなインフラ寄りの改修にはテストを含め多くの工数がかかると思います。 これは弊社の Twig にも当てはまることで、歴史的な理由でアップデートが非常に困難（年単位での改修コストがかかる）な状態にあります。 そのため、開発者は数年前の機能（開発効率）のまま、現在も開発せざるを得ないという状況です。 開発効率の他にも、言語特性による脆弱性など LTS ではないバージョンを使い続けることのデメリットは多く考えられます。 このような状況でも、なんとかして開発効率をよくしたい、実装/レビューコスト削減など DX を高めたいという想いの元で生まれたのがプリプロセッサーを作るという考えでした。 プリプロセッサーを挟むことで実際のランタイムのバージョンでは扱えない構文が存在していても、実際のランタイムで扱えるよう機械的に変換することで、ランタイムへと干渉せずとも擬似的に機能拡張を行うことが可能です。 JS における Babel のように、特定のランタイム環境においても実行可能な状態として最新の構文をダウングレードコンパイルするように、Twig のプリプロセッサーにおいても特定の Twig のランタイムバージョンに合わせて出力を変更できるよう設計しました。 作ったプリプロセッサーについて ここからは、作成したプリプロセッサーがどのようなものかについて触れてゆきたいと思います。 初期構想 PJ 初期段階で実装/導入したい内容としては次のようなことを考えていました。 Single File Component 構文拡張 xembed lint plugin ベースの拡張 Single File Component Vue.js や Svelte のようなモノを想像していただければ問題ないと思います。 テンプレートと同一のファイル内に style と script を記述し、影響範囲を狭めてそれぞれのファイル間の物理的距離を縮めるのが狙いです。 CSS に関しては Scoped CSS などで知られているように、テンプレート側と CSS の AST Node をマッチさせることで煩わしい class 命名からの開放なども可能だと考えていました。 構文拡張: xembed Twig には embed という構文が存在していて、これがそれなりに便利で開発サイドからも需要の高い構文でした。 twig.symfony.com しかし、LIFULL HOME'S で導入されている Twig バージョンは embed に未対応のバージョンで利用することはできませんでした。 embed を利用できないため、似たようなテンプレートを作成したい時にテンプレートの複製を強いられてしまい、開発効率にも大きく寄与する構文であったため、これとほぼ同等の機能をプリプロセッサー側で実装することにしました。 <!-- コンパイル元のファイル --> {% xembed 'Bundle::tmp/overlay.base.html.twig' only %} {% block modal %} {% include 'Bundle::tmp/modal.html.twig' only %} {% endblock%} {% endxembed %} <!-- コンパイル後のファイル --> {% include "Bundle::xembed/88e0f115ebf99c3d31d738856b176767d0c229e7.html.twig" only %} <!-- 88e0f115ebf99c3d31d738856b176767d0c229e7.html.twig --> {% extends "Bundle::tmp/overlay.base.html.twig" %} {% block modal %} {% include "Bundle::tmp/modal.html.twig" only %} {% endblock modal %} やっていることは単純で、手動で行うテンプレートの複製をプログラムで透過的に自動で行えるようにしました。 また、仮に Twig のバージョンアップがあった際、本家の embed をそのまま置換可能なように embed の構文と同じインターフェイスをとるようにしました。 lint Twig 開発上で起こしてしまいがちなミスを事前に防ぐことができるよう lint ツールを統合しています。 onSave でファイルのコンパイルと同時に lint を走らせることで、早いタイミングで開発者にフィードバックを与えるのが目的です。 用意した lint の種類としては次の 2 つです。 use only keyword in includeBlock avoid Dynamic include in includeBlock use only keyword in includeBlock Twig には include というキーワードで他のテンプレートを利用することができるのですが、この際に only というキーワードを使って変数スコープを指定することができます。 <!-- 変数スコープを指定しない -> children.html から現在のテンプレート上の全ての変数を参照可能 --> {% include 'children.html' %} <!-- 変数スコープを指定する -> children.html では with によって渡された foo のみが参照可能 --> {% include 'children.html' with {'foo': 'bar'} only %} only をつけていないことで、変数スコープの特定が非常に難しく、修正やリファクタの際に調査コストが大きく膨む要因となってしまいます。 これを、 only をつけていない実装があれば、自動で標準出力へと表示するようにしています。 warning: not exist only keyword in IncludeBlock at: tmp/parent.twig - {% include 'children.html' with {'foo': 'bar'} %} avoid Dynamic include in includeBlock こちらも include に関する内容で、動的なテンプレート名の構築を避けて欲しいという内容のものです。 <!-- このように template 名に変数を指定することが可能です --> {% include params.template.view {"foo": "bar"} only %} パラメータ名に読み込むテンプレート名を入れることで、場合によってはサーバサイドのかなーり深いところまで遡る必要があるため、こちらも調査コストが高くつきやすいです。 また、ファイル検索する際に grep で引っかからず影響調査から漏れてしまう可能性も高いです。 これらの理由から、動的な名前解決は非推奨として次のような出力をするようにしています。 warning: dynamic include was detected in IncludeBlock at: tmp/parent.twig - {% include params.template.view {"foo": "bar"} only %} plugin ベースの拡張 プラグインによって機能拡張がしやすい設計としました。 plugin 設計は Rollup を参考にしました。型ファイルをお見せするとこんな感じです。 export interface IPlugin extends PluginCtx { name: string ; postbuild?: ( metaOrRootAST: SourceMapMeta | any , path: string ) => Promise < void >; postGenerateAll?: () => Promise < void >; } export type LifeCycleValue = 'postbuild' | 'postGenerateAll' ; import type { SourceMapMeta } from '@/core' ; import type { PluginCtx } from '@/plugins/pluginCxt' ; ファイルの build（parse）が終わったタイミングで hook する function を記述し、ソースコードを生成する前に AST へ干渉できるようにしているのでアウトプットされるコードを変更することが可能です。 先ほどの lint の plugin はこんな感じで実装されています。 import { extractWithoutOnlyIncludeNode , generate } from '@/ast/twig' ; import { log } from '@/util/console' ; export default ( { silent } : { silent: boolean } ) : IPlugin => { return { name: 'warnWithoutOnly' , postbuild: async ( ast: any , path: string ) => { if ( silent || ast === null ) { return; } const res = extractWithoutOnlyIncludeNode ( ast ); if ( !res?. length ) { return; } log ( `warning:` , `not exist only keyword in IncludeBlock \n at: ${path}` , 'yellowBright' ); res.forEach (( node ) => { log ( ` -` , `${generate(node)}` , 'yellowBright' ); } ); } , } ; } ; // types import type { IPlugin } from '@/plugins' ; （AST 側が TS で実装されていないので、Node の型情報がないので現状は any で濁しています） ボツ案 初期構想から実際にリリースするまでに削られた機能たちとその背景について触れてゆきたいと思います。 Single File Component Style や Script を DOM 側と連携/制御させることが難しかったので諦めることにしました。 JSX などは HTML タグを JS オブジェクトとして扱うことができる一方、Twig では Twig の構文上 HTML タグをそれぞれ AST Node として扱うことは難しいです（unnkown な filter などが HTML タグの中に混在する可能性があり、構文解釈が難しい） よって、Twig の Parser では HTML 部分はほとんど Raw string として扱うことしかできず、HTML Node に対してプログラムによる高度な制御ができませんでした。 Twig にはファイルの継承機能も備わっており、継承が発生した際の script の変数/実装スコープ制御もかなり大変そうな（導入しても扱うことがかなり大変そう）ことがわかったので諦めることにしました。 想定していたリスク 「技術的負債を解消するために言語やフレームワークを拡張することで新たな技術的負債を生んでしまわないか」ということは常に考慮していました。 オレオレ実装や秘伝のタレとして負の遺産的に継承されることは避けられるように、後方互換性や前方互換性についても留意して設計/開発を行いました。 戻しやすく捨てやすい、これをモットーに開発できたことが、途中オーバーエンジニアリングで道を踏み外しそうになった時の支えとなりました。 独自言語（？）を作ってみてわかった感想 テンプレートエンジン +α ライクなモノを作ろうとしてみてはじめて分かった知見もいくつか紹介してみたいと思います。 拡張子とハイライト問題 初期構想時はファイルの拡張子も変えてみようかという話もありました。 その際、Github にプッシュしてコードを見たときにまったくコードハイライトがされていないということが発生しました。 Github 側の実装に当てはまらない拡張子はプレーンテキスト（？）のように扱われてしまうようで、とてもコードレビューできる状態ではありませんでした。 ソフトウェア開発において、Github は大きな役割を担うインフラ的存在になってしまっているため、これを無視することはできませんでした。 （後日知ったのですが、Github にはハイライトを管理するリポジトリが存在しているらしく、ここに PR を送れば独自拡張子などにもハイライトを当てることができるようです github/linguist ） まとめ 実のところ、ほとんどの実装は Twig の Parser 側が占めているので、プリプロセッサー側の処理はほとんどなくかなり薄い実装です。 紆余曲折あり当初の設計からはだいぶ機能を削っての導入になりましたが、今回の PJ を通して普段のアプリケーション開発では味わうことができないよい経験ができたと思います。 レガシーなテンプレートエンジンにもリッチな開発体験を、というキャッチフレーズで今後も邁進して参りたいと思います。