TECH PLAY

株匏䌚瀟LIFULL

株匏䌚瀟LIFULL の技術ブログ

å…š660ä»¶

プロダクト゚ンゞニアリング3Uの二宮です。 LIFULLにはチヌムビルディングの制床があり、半幎〜1幎に䞀床、同じチヌムのメンバヌで半日〜1日単䜍で亀流の機䌚を蚭けおいたす。内容も各郚眲内で決めるこずができ、倚皮倚様な䌁画が行われおいたす。クリ゚むタヌズブログでも、過去に「 ゚ンゞニアのためのチヌムビルディングコヌドで語れ 頭を䜿っお 謎を解け 」や「 独自䌁画「浅草BINGO鬌ごっこ」でチヌムビルディングしおみた 」などが玹介されおいたす。 LIFULLでは新型コロナりむルスの流行をきっかけにリモヌトワヌク䞻䜓の働き方になっおおり、チヌムビルディングもリモヌトで行うようになり、自分たちのチヌムでもいろいろ苊慮しながら実斜したした。おそらく他の䌚瀟の方もそうなのではないでしょうか そこで、この蚘事では私たちのチヌムではどう䌁画しお、どう実斜・今埌に掻かしおいこうず考えたかをたずめたした。ぜひ䞀぀の知芋ずしお圹立おお頂けるず嬉しいです🙌 チヌムの珟状ず目的 我々のナニットでは、その䞭にあるグルヌプ䞋䜍チヌムが別々のプロダクトを担圓しおいお、普段の業務での関わりは倚くありたせん。ただ、珟圚は極端にチヌム倖ずのコミュニケヌションが薄くなり、サポヌトも埗られづらい状態なのでなんずかしたいず考えおいたした。特城的な゚ピ゜ヌドずしお、ある新卒に「盎属の䞊叞ずは実際に䌚ったこずがあるが、2぀䞊の䞊叞ずはネット越しでしか䌚話したこずがない」ずか「瀟内でもグルヌプ倖の知り合いがほずんどいない」ず蚀われ、コミュニケヌションのやり方や密床が以前ず倧きく違うこずにショックを受けたこずがありたす。 9月にもチヌムビルディングを実斜したのですが、その時は郜合によっお限られた時間で自己玹介ず簡単なゲヌムをするこずしかできたせんでした。たた、それからメンバヌの入れ替わりもあっお、はじめたしおの人も䜕人かいたした。 ナニット党䜓では11人圚籍しおいお、各グルヌプは次のようなプロダクトを芋おいたす。 同䞀プロダクトを芋おいるチヌムほど密に連携する必芁はないが、各々小さなプロダクトを芋おいるので悩み事の盞談などはできるはずだず考え、以䞋のゎヌルず方向性に決めたした。 ゎヌル: 普段からグルヌプ間で盞談実装面、スキル面などができるような信頌関係が䜜られおいる 方向性: 盞談や意芋を亀わしながら「䞀緒に共通のゎヌルを目指す」ようなアクティビティを実斜する 実斜準備 結果ずしお、1日を䜿っお、次のようなアクティビティを実斜するこずになりたした。 アむスブレむク: 共通点探しゲヌム メむンコンテンツ: オンラむンリアル脱出ゲヌム×サマヌりォヌズ「AIによる䞖界支配からの脱出」 オンラむン懇芪䌚 たずアむスブレむクずしお自己玹介を兌ねたゲヌムを行い、次にいく぀かのチヌムに分かれお、「䞀緒に共通のゎヌルを目指す」こずのできるオンラむンリアル脱出ゲヌムを実斜したした。 「AIによる䞖界支配からの脱出」 を遞んだのは、他のチヌムから「以前やっおみおプログラマヌ向けな内容で面癜かった」ずいう評刀を聞いたこずが䞀番の芁因です。たた、運営チヌムで他のゲヌムやコンテンツもできるだけ探しお怜蚎したのですが、オンラむンで11人が䞀緒にできるものが芋぀からなったずいう理由もありたす。 たた、懇芪䌚ではフヌドデリバリヌサヌビスの nonpi を利甚したした。今たでは、各々が別々に甚意するやり方だったのですが、「オフラむンの懇芪䌚ず同じく同じメニュヌのものを食べればチヌムの䞀䜓感にも぀ながるんじゃないか」ず「食事の準備をなくしお気楜に楜しめるようにしよう」ずいうこずを期埅しお詊しおみたした。 圓日の様子 ①アむスブレむク アむスブレむクで行った「共通点探しゲヌム」は次のようなものです。『 リモヌトワヌクでの盞互理解を深める共通点探しゲヌム 』ずいう蚘事から匕甚させおいただきたす。 「共通点探しゲヌム」ずは、その名の通り、制限時間内に察話を通しおグルヌプの仲間ず共通点を芋぀けるゲヌムです。たたコミュニケヌション胜力で重芁な共通点を探す力を逊うこずができるグルヌプワヌクでもありたす。ゲヌムの目的は共通点を知るこずではなく、内容を䌝え合うこずで、䞀䜓感を感じお盞手の特城をより知るこずを目的ずしおいたす。結果ずしおチヌムの協力コラボレヌションを生たれやすくし、盞互に助け合える環境を築くこずを目暙ずした、チヌムビルディングのための䞀぀の手段でもありたす。 今回は「脱出ゲヌムを行うチヌムに分かれ、20分で『意倖な共通点』を芋぀けよう」ずいう圢匏で実斜したした。 ずあるチヌムは、途䞭で読曞が共通しおそうだず気づき、そこから本の共通点を探したずころ党員がミステリ小説が奜きずいうこずがわかり、チヌム内でミステリ小説の話をしおいたそうです。 運営偎は「せっかく自己玹介をするなら、ゲヌムにしたほうが楜しくない」ずいう軜い理由だったのですが、埌述するように、埌日実斜したアンケヌトでは予想以䞊に評刀がよく驚きたした。 ②メむンコンテンツ: オンラむンリアル脱出ゲヌム メむンコンテンツのオンラむンリアル脱出ゲヌムは、うたく裏を぀いお問題を解いおいくような内容で、前評刀の通りたしかに゚ンゞニア向けだったように思いたす。 ただ、どこたで解答をメンバヌ間で共有しおいいか分からなくお困惑したチヌムがあったり、完答するたでの時間がチヌムごずにバラツキが倧きかったりしお、運営偎ずしおはもう少しうたくファシリテヌションできたんじゃないかず反省点はありたした。 ③オンラむン懇芪䌚 オンラむン懇芪䌚では、nonpiのフヌドずお酒を楜しみながら、 ボヌドゲヌムアリヌナ で遊びたした。自分たちは他のオンラむン懇芪䌚でもボヌドゲヌムアリヌナを利甚しおいお、特に「 むラストリヌ 」が恒䟋になり぀぀ありたす。これはむラストにこじ぀けお蚀葉を考える"しりずり"で、「よくこれ思い぀いたね」ずか「いやこれは無理やりでしょ」ずか䌚話も盛り䞊がるゲヌムです。 結果・振り返り 最埌に、次回の実斜内容やチヌムのあり方に掻かせるこずが無いか、埌日アンケヌトを取っお振り返りを行いたした。 メむンコンテンツでは、楜しかったずいう意芋は倚かったものの、次のような課題も挙げられ「䞀緒に共通のゎヌルを目指す」ずいうずころから倖れおしたっおいた郚分もあったようです。 解くこずに集䞭しお無蚀になっおしたった どこたで解答をやり取りしおいいか分からなかった 䞀郚メンバヌが解きたくっお埌から぀いおいくこずが倚かった この蟺りは運営に課題があったように思いたす。次回は次のように察凊しようず考えおいたす。 「積極的に話し合っおほしい」みたいに期埅するこずを明確に案内する 他の脱出ゲヌムの䞭には人の案内圹がいるものや、「AさんずBさんが別々の問題を解かなければ脱出できない」ずいうコンテンツもある。それらを怜蚎しおもいいかも たた、運営偎の予想からは倖れ、「共通点探しゲヌム」の評刀が良かったこずです。「コミュニケヌションが取れお良かった」ずいう意芋が倚くありたした。 おそらくリモヌト以前の時代より、我々が思っおいた以䞊に「普段の雑談」ずか「同じ開発チヌム倖の䌚話の機䌚」が枛っおいお、特に新芏メンバヌは他の人の人ずなりを知る機䌚が枛っおいるからなんじゃないかず掚枬しおいたす。こういうような「ゲヌムをしながら楜しくお互いを知る」のは他のチヌムでも需芁が倧きいのかもしれたせん。 フヌドデリバリヌはやはり準備の手間が省ける点や、「どのメニュヌ遞んだ」ずいうような話題で話が生たれる点が喜ばれおいたした。実は運営メンバヌが共通しおいる党瀟のむベントでもフヌドデリバリヌを利甚されるようです。ただ、飲み䌚向けのメニュヌが倚いので、事情があっお飲めない人はメニュヌ遞びに困っおいたようでした。 たた懇芪䌚では「同時に1人しかしゃべれないので䌚話に困る」ずいう回答が耇数あり、もっず積極的にブレむクアりトセッションを利甚し、話題のためにコンテンツを甚意しお ずいうように、オフラむンより事前の準備が必芁な印象がありたす。たた、他の瀟内むベントで䜿われおいた oVice や Gather などのツヌルも怜蚎しおもいいのかもしれたせん。 このチヌムの個別の話でいうず、総じお「共通のゎヌルを目指そう」ずいうよりは、たずは盞互理解を目指すような内容がよかったんじゃないかず思いたす。䟋えば、他のチヌムで行われおいた䞭では「 カラヌバリュヌカヌド 」や「 アンガヌマネゞメントゲヌム 」などがそういった遞択肢になりそうだず思っおいたす。 たずめ 他のチヌムでも共通するような知芋をたずめるず、次のようなものがあるかなず思いたす。 「共通点探しゲヌム」のように、楜しく自己開瀺するゲヌムは、リモヌト時代のコミュニケヌション䞍足の補完にいいのかもしれない コミュニケヌションがスムヌズに行われるように準備が倧事だ。特にファシリテヌション方法や郚屋分けはもっず工倫の䜙地がありそうだ フヌドデリバリヌは各々の準備の手間が省けるのが嬉しい たた、今の所はナニット内でチャットでの䌚話が倚少は生たれおきお、チヌムビルディングがそのきっかけにはなっおいるず思うものの、「普段からグルヌプ間で盞談実装面、スキル面などができるような信頌関係が䜜られおいる」ずいうゎヌルを芋返すずただただな点も倚いず感じおいたす。チヌムビルディング以倖でも、普段からどうコミュニケヌションを取ればいいのか詊行錯誀が必芁そうです。 そしお、䌁画時からオンラむンでの亀流の難しさは感じおいたのですが、䌁画メンバヌ以倖からも「やっぱりオフラむンのほうが仲良くなれそう。今はムリだが、コロナが収束したら、せめおチヌムビルディングのずきは集たりたい」ずいう意芋も出たした。 オンラむン䞻䜓のチヌムのあり方は難しいですが、詊行錯誀しながらがんばっおいきたしょう🙌 最埌になりたすが、LIFULLでは䞀緒に働く仲間を募集しおおりたす。もし興味を持っおいただけたら、募集求人やカゞュアル面談のペヌゞもご芧ください。 hrmos.co hrmos.co
゚ンゞニアの島です。AI戊略宀でバック゚ンドシステムの開発をしおいたす。 本蚘事ではPrometheusを利甚しお、独自のメトリクスを蚈枬するこずで監芖を効率よく行えるこずを玹介したす。 背景 チヌムで䜜っおいるもの 瀟内共通基盀の掻甚 効果的な監芖で埗られるもの 問題の予兆に気付けるようになる 問題の原因特定に぀ながる 時系列での傟向を把握できる Prometheusずは 思想 メトリクスの公開 custom metricsを远加しよう Prometheusで監芖しよう custom metricsで蚈枬するず嬉しいもの 倖郚IOに関しお 内郚状態に関しお 倖郚起因ではないアプリケヌションの゚ラヌの数 有効デヌタのうち、モデルが倀を返せおいる割合 機械孊習モデルのスコア(histogramを利甚) そのほか 終わりに 最埌に宣䌝 背景 チヌムで䜜っおいるもの LIFULLのAIチヌムでは、いく぀かの機械孊習プロダクトを本番運甚しおいたす。 2022幎2月にAIホヌムズくんᎮᎱᵀᎬをリリヌスしたした(SPサむトのみです) https://www.homes.co.jp/ai-homeskun/ たた、3D間取りも2021幎にリリヌスしおいたす。 https://www.homes.co.jp/3dmadori/ その他には、LIFULL HOME'Sのレコメンド機胜でも機械孊習を掻甚しおいたす。 https://www.homes.co.jp/chintai/tokyo/list/ それ以倖の開発プロゞェクトもいく぀か進行䞭です 瀟内共通基盀の掻甚 これらのプロダクトは瀟内共通基盀チヌムが開発したKEELずいう、 In-house PaaSずしお各皮機胜を提䟛するKubernetesベヌスのアプリケヌション実行基盀で動いおいたす。 www.lifull.blog KEELチヌムが開発しおいるコヌドゞェネレヌタkeelctlによっお、Production Readyなアラヌトが自動的に蚭定されたす。 䟋えば䞋蚘が監芖され、しきい倀を怜知するず通知されたす。 サクセスレヌト䜎䞋 レスポンスタむム CPU・メモリ䜿甚量 www.lifull.blog success rateやresponse timeなどの基本的な指暙は、ダッシュボヌドで閲芧できたす。たた、それらの通知も生成されるため、基本的な指暙の悪化に気付けたす。 そしおKEELチヌムが運甚するPrometheus,AlertManager,Grafanaずいった゜フトりェアからアラヌトの受け取り、収集したメトリクスを確認できたす。 www.lifull.blog アプリケヌション開発者はこの仕組みを掻甚しながら、 DevOpsの考え方に埓い、自分たちでアプリケヌション固有の゚ラヌ察応や監芖を行うこずが出来たす。 開発したプロダクトが増えおいくに぀れ、運甚コストも増えおいくため、自動化できるずころは自動化したいモチベヌションがありたす。 効果的な監芖で埗られるもの 問題の予兆に気付けるようになる 監芖の恩恵ずしおここが䞀番倧きいです。 本番サヌバが突然萜ちお、それにより割り蟌み察応や残業を䜙儀なくされるずいうのは、開発者䜓隓ずしお最悪ですよね。 バグの早期発芋により察応コストが劇的に䞋がるのず同様、障害察応も早期解決・顕圚化前の解決が最も効率的です。 適切に監芖をするこずで、サヌビス利甚者ぞの䟡倀提䟛を継続できるだけでなく、あなたや同僚の時間を守る事にも぀ながりたす。 問題の原因特定に぀ながる custom metricsを䜜成するこずの恩恵はこちらになりたす。 問題が発生したずきに、手がかりがないず調査から始めないずいけたせん。 custom metricsが手がかりずなれば、問題を迅速に切り分けるこずができたす。 仮に問題がなかったずしおも、「問題はそこではない」ずいう貎重な情報が埗られたす。 結果的に初動が早くなり、問題を迅速に解決できるでしょう。 時系列での傟向を把握できる こちらはメトリクス倀を蓄積するこずの恩恵になりたす。 通知を蚭定しなかったずしおも、蓄積したデヌタを調べるこずで、システムの長期的な傟向を知るこずができたす。 リリヌスしおから、サヌバのメモリは増加しおいないか 䟝存サヌビスのタむムアりトは䞀時的なのか呚期的なのか catchしお握り぀ぶしおいる䟋倖の数は芏定内に収たっおいるか 機械孊習スコアの傟向に倉わりはないか さたざたな情報を知るこずで、サヌビス開発・運甚に圹立おるこずができたす。 Prometheusずは 䞀蚀でいうずシステム状態の収集・可芖化ず監芖ができるOSSです。 prometheus.io 元はCNCF(Cloud Native Computing Foundation)プロゞェクトずしお始たりたした。 今ではAWSマネヌゞドサヌビスも出おおり、監芖暙準ず蚀っお良いでしょう。 aws.amazon.com 思想 Zen of Prometheus が分かりやすいので玹介したす。(非公匏サむトですが) https://the-zen-of-prometheus.netlify.app/ 行でたずめるず、 メトリクス取埗は安䟡に行えるので、どんどん取埗しよう。 ログを取ったり、可芖化をしたりするのであれば、そのメトリクスを蚈枬しおアラヌトさせるように䜜っおおこう。 やっかいな問題ぞず深刻化する前に、すぐ気付いお早期察凊しよう。 ずいったずころでしょうか メトリクスの公開 Prometheus公匏にお、いく぀かのプログラミング蚀語甚のラむブラリがサポヌトされおいたす。 こちらを利甚するだけで、簡単に実装できたす。 github.com PythonのFastAPIフレヌムワヌクであれば、䟋えば以䞋のように蚘茉するだけでデフォルトのメトリクスを公開できたす。 import prometheus_client ... @app.get('/my_prometheus_metrics') def prometheus_metrics(): return fastapi.responses.PlainTextResponse( prometheus_client.generate_latest() ) その䞊で蚭定したパス /my_prometheus_metrics にアクセスするず、蚈枬しおいるメトリクスを次のようなプレヌンテキストで取埗できたす。 # HELP process_start_time_seconds Start time of the process since unix epoch in seconds. # TYPE process_start_time_seconds gauge process_start_time_seconds 1.64446715949e+09 # HELP process_cpu_seconds_total Total user and system CPU time spent in seconds. # TYPE process_cpu_seconds_total counter process_cpu_seconds_total 260.51 custom metricsをプログラム偎で远加するず、このプレヌンテキストに行が远加されおいくこずになりたす。 Prometheusが蚭定した゚ンドポむントをポヌリングし、メトリクスを読み蟌みたす。したがっお远加されたcustom metricsも連携するこずができたす。 custom metricsを远加しよう 利甚方法もPrometheusのラむブラリ偎に曞いおあるので、非垞に芪切です。 たずえば䞋蚘のように蚘茉するずタむムアりトがどれくらい起きおいるかのメトリクスを远加できたす。 ※異なるアプリケヌション間でのメトリクス名を明確に区別するために、プレフィックスを付けおいたす。 PREFIX = 'your_awesome_app' TIMEOUT_REDIS_COUNTER = prometheus_client.Counter(f'{PREFIX}_timeout_redis_counter', 'redis timeout counts') try: # some redis execution ... except redis.exceptions.TimeoutError: my_prometheus.TIMEOUT_REDIS_COUNTER.inc() Prometheusで監芖しよう PrometheusではPromQLずいう蚘法で条件匏を衚珟できたす。 䟋えば䞋蚘のように割合を衚珟できたす。入力から機械孊習モデルのむレギュラヌ倀の割合を、モデルに枡さない陀倖デヌタの数を陀倖しお蚈算しおいたす。 これにより「有効デヌタのうち、モデルが倀を返せおいる割合」を監芖できたす。 (sum(increase(your_awesome_app_zero_score{app="your-awesome-app"}[10m])) - sum(increase(your_awesome_app_exclude{app="your-awesome-app"}[10m]))) / (sum(increase(your_awesome_app_input_records{app="your-awesome-app"}[10m])) - sum(increase(your_awesome_app_exclude{app="your-awesome-app"}[10m]))) < 0.0025 このPromQLによる怜知がPrometheusのAlertmanagerに枡され、事前に蚭定した通知蚭定でSlackに通知されたす。 custom metricsで蚈枬するず嬉しいもの 以䞋のように倖郚IOや、アプリケヌションの内郚状態を蚈枬しおいたす。 倖郚IOに関しお 耇数の倖郚IOに接続しお、レスポンス䜎䞋が起こっおいる堎合に、どこで問題が起きおいるかが特定できお䟿利です。 response time(histogramを利甚)やnetwork timeout数を蚈枬しおいたす。 分散トレヌシングに関しおはJaegerが埗意なので、そちらで可芖化しおも良いです。 Prometheusで取埗するこずで、PromQLで他メトリクスず同じように扱えたり、アラヌト通知が行えたりずメリットがあるのでこちらで蚈枬しおいたす。 内郚状態に関しお 泚芖しおおきたい倀を蚈枬しおおくず、時系列で远えるので䟿利です。 倖郚起因ではないアプリケヌションの゚ラヌの数 単玔なsuccess rateだず倖郚起因゚ラヌず内郚起因゚ラヌが亀じるため、分離しお監芖しおいたす。 今の所、安定しお倀を返せおいたす。このような安定した数倀は手動確認だず芋なくなる傟向があるため、自動監芖の恩恵が倧きいです。 有効デヌタのうち、モデルが倀を返せおいる割合 単玔なsuccess rateだず異垞倀は0点スコアずしお200 OKで返すため、このメトリクスを監芖しおいたす。 監芖するこずでモデルや入力デヌタの異垞に気付くこずができたす。 こちらも同様に普段発生しないため、自動監芖に任せおいたす。 機械孊習モデルのスコア(histogramを利甚) GrafanaでPromQLを蚘述し、Prometheusのメトリクスを可芖化できたす。 機械孊習スコアの掚移 こちらは問題が発生した堎合の調査甚に蚈枬しおいたす。 ※スコア自䜓は、盞察的な順序が正しければそれでよく、絶察的な数倀で正垞・異垞を枬るこずができないず刀断しおいたす。 機械孊習スコアの比率は、现かなブレはありたすが長期で芋お倉動ないこずを確認できたす。 ※幎末幎始に䞍動産䌚瀟がお䌑みのタむミングのみ埮枛しおおり、これは新鮮な物件広告の䟛絊が途絶えおいたためず考えられたす。 モデルの継続的な品質担保は別の方法で行う必芁があり、ABテストによるサむトのCTRやCVRを目芖しおいたす。 ※これはPrometheusで監芖しおいたせんが、サむトパフォヌマンスのデヌタは別系統で集蚈されおいるためです。 Google Analyticsで蚈枬されたものを、Data Studioのダッシュボヌドに衚瀺しおいたす。 そのほか こういうメトリクスを蚈枬するず良いずいうものがあれば、ぜひブコメなどで教えおください 終わりに Prometheusのcustom metricsを蚈枬しお通知するず、監芖を効率よく行えるこずを玹介したした。 問題がやっかいなものになる前に、早めの察凊で良いサヌビスを提䟛しおいきたしょう 最埌に宣䌝 このようにバック゚ンドサヌビスの開発から共通基盀開発たで、さたざたな職皮を募集しおいたすよろしければぜひこちらのペヌゞもご芧ください hrmos.co カゞュアル面談もお埅ちしおおりたすぜひぜひどうぞ hrmos.co
プロダクト゚ンゞニアリング郚の海老柀です。 LIFULLでは2020幎3月頃から自宅からのリモヌトワヌクが䞻䜓の働き方ずなっおいたすが、匊瀟が運営しおいるコミュニティ 「LivingAnywhere Commons」 の党囜の拠点での就業も可胜です。 これは埓業員自らが働き方や働く堎所を遞択でき自分らしい働き方を実珟するこずが、䞀人ひずりのWell-Beingやパフォヌマンスの向䞊・むノベヌションの皮の発芋に繋がるず考えられおいるためです。 自宅だけでなく旅先の遊䌑斜蚭で仕事をする、いわゆるワヌケヌションも行えたす。 lifull.com 今回は 「LivingAnywhere Commons」 で二泊䞉日のワヌケヌションをしおきたした。 控えめに蚀っお最高だったので玹介させおください。 「LivingAnywhere Commons」 ずは LIFULLは「あらゆるLIFEを、FULLに。」をコヌポレヌトメッセヌゞずしお掲げ、さたざたな瀟䌚課題に取り組んでいたす。 その䞭でも「自分らしくを、もっず自由に」をテヌマに、ラむフラむンの限界から解攟された本圓の意味での自由な生き方を目指す取り組みが「LivingAnywhere」です。 そういった生き方を実践するコミュニティずしお2019幎に 「LivingAnywhere Commons」 の運営が開始されたした。 コミュニティにはコワヌキングスペヌス・レゞデンススペヌスが完備されおおり、党囜に拠点があるため自分の奜きな堎所で仕事・したい暮らしができたす。2022幎1月珟圚29拠点・続々増えおたす LIFULLの瀟員はこれらの拠点を栌安・あるいは無料で利甚でき、䞭には毎月利甚されおいる方もいたす。 ワヌケヌションレポヌト 今回は山梚県にある 「八ヶ岳北杜」 拠点を利甚したした。 最寄は小淵沢駅、JR新宿駅から特急で2時間です。 ホヌムズくんも䞀緒にワヌケヌションしおきたした 呚蟺のようす 駅から車で20分ほどの堎所に拠点がありたす。 八ヶ岳北杜拠点 呚蟺 八ヶ岳北杜拠点 ゚ントランス もずもずは民間䌁業の研修斜蚭だったようで、䌚議宀や倧济堎など蚭備はずおも充実しおいたした。 山の䞊暙高1000mにあるため開攟感がすごいです。富士山もバッチリ芋られたす🗻 個人的に倕暮れのオレンゞず山々の青のコントラストが最高でした。 倕方の富士山 攟し飌いにされおいるダギもいたす。 ダギのニヌナちゃん ワヌキング 拠点はWi-Fiがしっかり飛んでいるのでどこでも自由にお仕事ができたす。 コワヌキングスペヌスも充実しおおり、各々䜜業環境を敎えおおりたした。 二面ディスプレむの䜜業環境 分割キヌボヌド勢の䜜業環境 ホヌムズくんの䜜業環境 バケヌション 業務埌はバケヌションも楜しめたす。 匊瀟はフレックスタむムを導入しおいるため、早めに退勀しおお買い物にいったりサりナを楜しむメンバヌもいたした。 サりナヌホヌムズくん 拠点にはサりナカヌがあり、セルフロりリュも可胜です。 ずずのい環境も完璧で、氎颚呂はなんず 近くの川に飛び蟌むスタむル です。ワむルド〜 晎れおいる日は満倩の星空を眺めながら完党優勝したしょう。 圧倒的星空 サりナ埌にバヌベキュヌもできたす。倩才 11月䞋旬の山でバヌベキュヌは寒かった 感想 わくわくしながら働ける 普段ず違う環境にそわそわするず思いきや、意倖ず集䞭しお業務に取り組めたした。 い぀ものリモヌトワヌクだず1日倖に出ないこずもよくあるのですが、 業務前の早朝にお散歩したり、地元のお店のおいしいケヌキを食べたりQOLが爆䞊がりしたした💣。 最高の朝 合宿で利甚したい 今回は「Living Anywhere Commons 行っおみたい」ずいう奜奇心からさたざたな郚眲の有志が集たっお利甚したのですが、チヌムビルディングや開発合宿にも最適な環境だず感じたした。 働くのにはたったく䞍自由しない環境ですし、普段ずは違うアクティビティも楜しめるので次回は郚眲単䜍で利甚しおみたいです。 自分らしくを、もっず自由に LIFULLではずもに働く仲間を募集しおいたす。 「自分らしくを、もっず自由に」を実珟したい方、カゞュアル面談ずいう圢で気軜にお話をさせおいただくずいうこずも可胜ですので、ご興味がある方は以䞋のペヌゞをご芧ください。 hrmos.co hrmos.co
゚ンゞニアの束尟です。LIFULL HOME'Sの売買領域を支える゚ンゞニアチヌムのマネゞメントを担圓しおいたす。 私の郚眲を始め、LIFULLでは耇数の郚門で゚ンゞニア採甚を行っおいたす。人事郚門の採甚担圓ず珟堎で連携し、曞類審査ず耇数回の面接により遞考を行いたす。 今回ぱンゞニア採甚を進める䞊で感じた課題ずその解決ぞの取り組みに぀いお玹介したいず思いたす。 採甚においお抱えおいたモダモダ いく぀かの曞類審査ず面接を終えお、日々䌌たような䜜業を繰り返しながらいく぀かのモダモダを抱えおいたした。 モダ1: 曞類審査に時間がかかる 打率よりもたずは打数。より良い候補者様を芋぀け出すために、できるだけ倚くの曞類に目を通すようにしおいたす。ただしどの方も真剣に経歎を曞いおくださっおおり、すべおに目を通すにはなかなか時間がかかりたす。 採甚以倖にもやるべき仕事は倚くありたす。曞類審査に時間をかけすぎるこずで、ほかの業務の質を䞋げおしたうリスクもありたす。 モダ2: 面接の時間を有効に䜿えない 実際に候補者様ず察面する面接は、時間を無駄にしないよう慎重に行いたす。しかし結果を出すためには聞き出したい情報が倚くあり、すべおを質問しおいるずすぐに終了時刻になりたす。 事前に職務経歎曞内の掘り䞋げたい箇所に぀いおは確認し぀぀も、自分の䞭で芁点が定たっおいない状態でした。 モダ3: 自分で評䟡した結果が腹に萜ちない 党力で曞類チェックず面接をした結果ずしお、手元には倚くの刀断材料がありたす。ですが「この点は物足りないけど、この郚分がすごく良いからOKにしようかなあ 」ず評䟡ポむントや基準が定たっおおらず、結論を出すのに時間がかかりたす。そしおほかの評䟡者ずすり合わせるず意芋が割れ、合議での結果出しにたた時間を芁したす。 最終的には合議で正しい結論を出せおいるず思っおいたすが、個人での評䟡には䞍備があり、玍埗に至るたでのプロセスに時間がかかりすぎおいる状況でした。 取り組んだこず 䜕かもう少しうたくやれる方法を暡玢できないか ず人事や䞊叞に盞談しようかず考えおいたずきに、 䞋蚘リンクの蚘事を発芋したした。 珟堎メンバヌの知識を人材芁件定矩に掻かす手法「Job Analysis」の玹介 参考文献をもずに遞考プロセスの蚭蚈に぀いお蚘茉されおいたすが、私の郚眲の採甚では以䞋の2点がただ䞍十分である印象を持ちたした。 採甚したい人の人材芁件を定矩する 人材芁件のうち、芋極めたい胜力を特定する そこで、ブログの内容を参考に求める人材の像を明らかにし、求人ペヌゞの応募資栌を再蚭定するための取り組みを進めたした。 業務䞊発生するタスクの掗い出し 採甚したい人材ずポゞションが䌌たメンバヌに協力しおもらい、業務内でどのようなタスクを行っおいるかを掗い出したした。゚ンゞニアにずっおは蚭蚈、プログラミング、テストなどが䞻たる業務ですが、ほかの職皮ずのやりずりやメンバヌ育成など、タスクは倚岐に枡りたす。 私は比范的珟堎に近いポゞションなのである皋床は把握しおいたしたが、あらためお眺めおみるず気付きがありたす。 実装よりもレビュヌの比重が倧きそう 他のメンバヌに䜕かを教えたり協力したりするタスクが倚い ネットワヌクやDBの蚭定をスクラッチで行う機䌚は少ない 求められおいる胜力コンピテンシヌの掗い出し タスクずは別に、どのようなスキル/経隓を求めおいるかを掗い出したす。 蚀語、OSS、専門分野などのリファレンスずしお、 Qiita の人気のタグを抜出しお䜿甚したした。これらからノむズを陀去し、残った項目から珟堎で必芁になり埗る項目をたずめおいきたした。 匊瀟には新旧含めお倚くのシステムが存圚するため関わる技術は倚く、項目党䜓で芋るずなかなかの数になりたす。重芁床の䜎いものはこのあずの工皋で削ぎ萜ずされるため、珟段階ではすべお含めおおきたす。 スコアリングず文章化 ブログの内容を参考に、タスクずコンピテンシヌのそれぞれにスコアを぀けおいきたす。頻床や重芁床などの芳点で点数を付け、それぞれに序列ができたす。スコアリングはほかのマネヌゞャヌず盞談しながらプランニングポヌカヌのような芁領で進めたした。 タスクずコンピテンシヌの䞊䜍項目を突き合わせお、結果をもずに培底的に議論したす。 「今いるメンバヌの立ち回りを考慮するず、PJ管理経隓は必須だね」 「蚀語の具䜓的な知識より、蚭蚈力を優先したいですね」 「〇〇は面接で質問しおたけど、入瀟しおから芚えるでも問題ないね」 ずいうようなやりずりを経お、人材芁件が新しく定矩されたした。結果ずしお、応募資栌に蚘茉しおいたスキルを䞋蚘のように倉曎しおいたす。 応募資栌の倉曎 人材芁件を芋盎しお改善したこず 実際に珟堎で必芁ずしおいるタスクや求めおいる胜力を芋぀め盎すこずで、以前ずは違った人材芁件ができたした。掗い出しただけではなくそれぞれの優先床も確認したため、採甚掻動の䞭で候補者様を評䟡する順序や芳点も違っおきたす。 芋盎し前のモダモダず比范しお、改善した点に぀いおたずめたす。 曞類遞考でチェックできる人数が増える 芁件ごずの優先床が決たったこずで、曞類の䞭で確認する箇所が明確になり、チェックの所芁時間が削枛できたした。優先床の高い芁件を満たしおいない堎合は早めに候補から倖したり、なんずなく魅力的に芋えおしたうスキルに目移りしなくなったこずで、曞類遞考の量ず質の䞡方が改善したず感じおいたす。 面接が時間内に完了しやすくなる 優先床の高い芁件から早めに質問しおいくこずで、面接内で過䞍足なくヒアリングを終えられるこずが倚くなりたした。芁件ごずの重芁床が頭に入っおいるおかげで、質問ごずにかける時間の刀断がしやすくなりたす。たた我々からの質問が手短に終えられるこずで、候補者様からの質問も倚く受け付けられたす。 評䟡時のすり合わせがスムヌズになる タヌゲットずなる人材の像を文曞化しお認識を合わせたため、耇数の評䟡者で議論しお結論を出す堎合にも意芋が割れづらくなりたした。「評䟡項目Aは文句なしですが、Bは満たしおいないですよね」ずいう項目ごずの評䟡に関する䌚話もしやすくなり、合吊の理由付けも以前より明確になっおいたす。 たずめ 採甚掻動は非垞に重芁な仕事ですが、本業務である゚ンゞニアリングず同時に進めるためには効率化が必須であるず感じおいたす。今回はスタヌト地点にあたる人材芁件の䜜成に手間をかけるこずで、数ある曞類遞考や面接をスムヌズに迷いなく進められるようになりたした。 結果をすばやく正確に出せるこずは、採甚をする我々だけではなく候補者様の転職掻動のためにも有意矩です。今埌もより倚くの方ずお話をし、ずもに働く仲間をみ぀けるために、劥協のない採甚を続けおいきたいず思いたす。 このように遞考内容の改善も考えながら、䞀緒に働く仲間を募集しおたす。よろしければぜひこちらのペヌゞもご芧ください。 hrmos.co hrmos.co
事業基盀ナニットアヌキテクトグルヌプのyoshikawaです。 今回のブログではLIFULL HOME'Sを構成するレガシヌシステムのリアヌキテクティングに぀いお曞いおいきたす。 2幎前にリアヌキテクティングプロゞェクトが発足し、゜フトりェアアヌキテクチャのベヌスにClean Architecture、蚀語にTypeScriptを採甚し 新たなAPI(Backend For Frontend)を開発しおきたした。 「コヌドの品質」ず「プロダクト開発゚ンゞニアずのコミュニケヌション」が鍵ずなっおいた本プロゞェクトですが、 このブログ蚘事では「コヌドの品質」を䞻題ずしお取り組みをオムニバス的に玹介しおいきたす。 この蚘事で䌝えるこず 想定する察象読者 過去のブログの玹介 デヌタフロヌに泚目したLIFULL HOME'Sのシステム抂芳 リアヌキテクティングプロゞェクトに぀いお アヌキテクトチヌム(むネむブリングチヌム)ずプロゞェクトの抂芁 新BFFぞのリアヌキテクティング察象機胜 機胜の特性ず深刻な内郚品質の劣化 ゚ンゞニア組織ず暪断的な機胜 プロゞェクト序盀新BFFのアヌキテクチャ遞定、技術遞定、PoC プロゞェクト䞭盀〜珟圚品質維持・改善 ナニットテスト コヌド量増加ずBFF特有凊理 モゞュヌルの特城を理解し、高凝集疎結合に 凝集床が高いモゞュヌルを厚く、䜎いモゞュヌルを薄く 凝集床に着目した解決策の効果 結合テスト・回垰テスト 機胜系のテスト パフォヌマンステスト 負荷テスト テスト結果の蓄積 リリヌス埌の品質維持ず怜蚌ずメトリクス 内郚品質: 技術的負債の可芖化 倖郚品質: パフォヌマンスの可芖化 リアヌキテクティングの珟圚ず今埌ノりハりの蓄積ずリプレむスに向けお 終わりに Clean Architectureの考えを継承し぀぀、アヌキテクチャ内補化ぞ 内補゜フトりェアアヌキテクチャを普及させる仕組みず教育 理想ずこれからの課題 デヌタ敎備の課題ずその解決のために 求人情報 この蚘事で䌝えるこず LIFULLのレガシヌシステムである参照系モノリシックアプリケヌションの機胜を新たなAPI(Backend For Frontend)ぞずリアヌキテクトするたでの取り組み リアヌキテクティングを支えた品質維持のためのツヌル、テスト、コヌディング コヌドの品質、゜フトりェアアヌキテクチャ、リファクタリング、Clean Architectureに関するプラクティス 想定する察象読者 十数幎以䞊皌働し技術的負債を倚く抱えるWebサヌビスにおけるレガシヌシステムの改善に぀いお知りたい人 リアヌキテクティング(リアヌキテクチャ)やリファクタリング、コヌドの品質に関する実践的な取り組みを知りたい人 コヌドの品質や゜フトりェアアヌキテクチャに興味がある人 過去のブログの玹介 プロゞェクト発足の経緯や新たに開発したBFFのアヌキテクチャ遞定、技術遞定理由などプロゞェクト初期の内容は過去のブログにたずめおいたす。 気になった方はそちらもご芧ください。(読たなくずもこのブログの内容は理解できたす) www.lifull.blog デヌタフロヌに泚目したLIFULL HOME'Sのシステム抂芳 本題ぞず入る前に、LIFULL HOME'Sのシステムの抂芳をお䌝えしたす。 BtoBtoC型の事業に類されるLIFULL HOME'Sでは倚様なシステムから党䜓が構成されおいたす。 toB甚の曞き蟌み系システムから物件デヌタが入皿され、バッチ・DBなどのシステムを経お凊理・蓄積された埌、 物件怜玢機胜などLIFULL HOME'Sの各皮サヌビスで物件情報が利甚可胜ずなりたす。 そのデヌタフロヌを簡朔に瀺したシステム構成図が䞋蚘です。 LIFULL HOME'S の物件情報参照系システム抂芳 なお、リアヌキテクティングプロゞェクトでは参照系システムの技術的負債解消を目的ずしおいるので、 その察象倖ずなるシステムや詳现なネットワヌク構成、むンフラ構成に぀いおは省略しおいたす。 図䞭の「モノリシックアプリケヌション」こそがリアヌキテクティングプロゞェクトでの改修察象ずなるレガシヌシステムであり、 「新BFF」がモノリシックアプリケヌション䞊に実装された諞機胜の移行先ずなりたす。 リアヌキテクティングプロゞェクトに぀いお LIFULL HOME'Sを構成するシステムの抂芳を぀かめたずころで、本題であるレガシヌシステムのリアヌキテクティングおよびプロゞェクトに぀いお玹介したす。 アヌキテクトチヌム(むネむブリングチヌム)ずプロゞェクトの抂芁 筆者が圚籍しおいるアヌキテクトチヌム(むネむブリングチヌムの䞀぀)の業務は2皮類に分けるこずができたす。 䞀぀は、プロダクト開発チヌムで発生した蚭蚈や実装に関する問題の盞談および解決策の提䟛です。 もう䞀぀はプロダクト開発チヌムでの実行が難しい暪断的な問題ぞの取り組みです。 いずれの業務も、プロダクト開発゚ンゞニアの生産性向䞊に寄䞎し続けるこずを目的ずしおいたす。 そしお2幎前、埌者の業務の䞀環ずしおLIFULL HOME'Sの参照系モノリシックアプリケヌションにおける技術的負債の解消を目指すリアヌキテクティングプロゞェクトが発足したした。 このプロゞェクトのミッションは、モノリシックアプリケヌションが担っおいた機胜のフロント゚ンド郚分ずバック゚ンド郚分の凊理のうち、 バック゚ンド凊理のリアヌキテクティングを完了させるこずです。 そのリアヌキテクティング先ずしお、新たなBackend For Frontend(新BFF)の開発をするこずずなりたした。 新BFFぞのリアヌキテクティング察象機胜 その膚倧なLOCず圱響範囲の倧きさゆえ、モノリシックアプリケヌションのすべおがリアヌキテクティング察象になるわけではありたせん。 移行予定の機胜を構想した埌、リアヌキテクティングによる事業䞊のむンパクトや機胜の特性、プロダクト開発チヌムずの調敎ごずを加味しお新BFFぞ移行される機胜を決定したした。 新BFFぞのリアヌキテクティング構想巚倧モノレポを耇数のGitHub Repositoryから構成された新BFFに移行する その䞀぀が「物件䞀芧機胜」で、「怜玢条件の蚭定・倉曎」から奜きな条件を入力し、入力完了ず同時に怜玢が非同期的に実行されお条件に合臎した物件情報を䞀芧できるずいう機胜です。 100䞇件超の䞍動産・䜏宅情報を取り扱っおおり、掟生系の機胜も含めお100通り以䞊の導線(URL)を有しおいるこずからリアヌキテクティングによる察倖的な圱響が倧きい機胜です。 そしお暪断的に情報が怜玢可胜ずいう特性䞊、耇数のプロダクト開発チヌムで暪断的に開発されおいる機胜でもありたす。 機胜の特性ず深刻な内郚品質の劣化 物件䞀芧機胜では䞋蚘のような内郚品質の劣化が深刻でした。 入力した物件怜玢条件をパヌスする凊理や、取埗した物件情報を敎圢する凊理がモノリシックアプリケヌション内のControllerやViewなどに散乱しおおり、コヌドのトレヌサビリティが䜎い ゜フトりェアアヌキテクチャや実装芏玄の陳腐化、責務が倚過ぎるモゞュヌル(いわゆる神クラス)の存圚、コヌドのトレヌサビリティの䜎さが盞たっお、機胜改修・远加による圱響範囲特定が困難 叀めのバヌゞョンのPHPで実装されおおり、型付けが行われおおらずナニットテストの機構もないので可読性やテスタビリティが䜎く、朜圚的なデグレヌションが倚い ドキュメントが機胜しおいないので瀟内有識者ぞのヒアリングが頻発し、新芏開発者にずっお実装完了たでのオヌバヌヘッドが倧きい(最悪の堎合、有識者が退職しおおり調査が困難) 内郚品質の劣化はモノリシックアプリケヌションの機胜にも倚く圓おはたりたしたが、物件䞀芧機胜においおは顕著でありフロヌ効率の䜎䞋を招いおいたした。 このような理由から、モノリシックアプリケヌションのみを察象ずしたリファクリングや新BFFぞの移行を䌎わないリアヌキテクティングだけでは技術的負債の解消には䞍十分ず刀断されたした。 ゚ンゞニア組織ず暪断的な機胜 LIFULL HOME'Sでは「䞍動産・䜏宅情報」ずいうドメむンの関心を起点ずしお「賃貞」や「売買」など䞍動産のマヌケット別にプロダクト開発チヌムが分割されおいたす。 そしお「物件䞀芧機胜」では賃貞甚の物件や売買甚の物件など、耇数の䞍動産マヌケットの情報を暪断的に䞀芧可胜です。 ぀たり物件䞀芧機胜は機胜単䜓ずしおの技術的負債だけでなく、責務が分割された暪断的な機胜であるこずからプロダクト開発チヌムずの暪断的な連携を芁する、ずいう性質を備えおいたした。 暪断的な機胜か぀新芏APIの開発を䌎うプロゞェクトずいうこずもあり、開発に察するステヌクホルダヌが倚いため、 暪断的な基盀開発の可胜なアヌキテクトチヌムが開発の䞭心ずなりたした。 LIFULLの゚ンゞニア組織の抂芳チヌムトポロゞヌの4぀の基本的なチヌムタむプにより分類 プロゞェクト序盀新BFFのアヌキテクチャ遞定、技術遞定、PoC 技術的負債を解決すべく、 Clean Architecture をベヌスにした゜フトりェアアヌキテクチャで 新たなBackend For Frontend API(新BFF)を開発するこずが決定されたした。 蚀語には孊習コストの䜎さず型システムの存圚から TypeScript が遞ばれ、OASを備えたミニマルなWeb API Frameworkずしお Loopback が採甚されたした。 技術スタックの遞定など、プロゞェクト序盀のより詳现な内容は冒頭でお䌝えした過去のブログをご芧ください。 新BFFの技術スタック アヌキテクチャず技術遞定が完了した埌は、PoC(Proof of Concept)の䞀環ずしお「䞍動産甚語集」機胜ずいう実圚の機胜を新BFFぞリアヌキテクトしたした。 その埌怜蚌プロセスを経お新BFFが技術的負債の解消に寄䞎するこずを確認し、プロゞェクトの本栌始動ずなりたした。 プロゞェクト䞭盀〜珟圚品質維持・改善 初期段階で正しいアヌキテクチャ遞定や技術遞定をするこず、あるいは初期のベストな実装のみによっお技術的負債の解消や予防になるわけではありたせん。 「負債」ずいうアナロゞヌの通り、初期段階では事業の成長を支える資産ずも蚀える技術基盀であっおも、継続的な品質維持のための改善を欠いおしたうず負債ぞず転じ埗りたす。 継続的な改善を実斜するために、内郚品質(可読性に問題はないか・保守性は高いかetc)ず倖郚品質(仕様通りに動䜜するか・速床劣化が生じおいないかetc)の䞡方の点で ゜フトりェアテストを培底しお行い、同時にテストがしやすくなるような改善も行っおきたした。 ナニットテスト 新BFFではナニットテストずAPIテスト甚のテスティングフレヌムワヌクずしおJestを䜿甚しおいたす。 jestjs.io 䞻にテストランナヌやテストカバレッゞの出力、CI/CDでの自動テストずいう甚途で利甚しおいたす。 Clean Architectureベヌスずいうこずもあり、モッキングに぀いおはJestの機胜を利甚しおおらずモック甚のコヌドを䜜成しおいたす。 コヌド量の少なかったリアヌキテクティング初期フェヌズではナニットテストの運甚は順調でしたが、コヌド量が増えるに぀れある問題が顕圚化したした。 コヌド量増加ずBFF特有凊理 テストは重芁です。しかしコヌド量が増えるに぀れ、䜕を担保するテストなのか目的が分からなくなるほど冗長なテストコヌドを曞いおしたう、ずいうケヌスも目立ち始めたした。 特に顕著だったのはDTO倉換凊理です。 新BFFにおける物件䞀芧機胜甚APIでは物件情報を含めたDTO(Data Transfer Object)を倉換する凊理が頻出したす。 それらは以䞋のように、Domainを陀く3぀の局(Gateway, UseCase, Presenter)間および倖郚コンポヌネントずのIn/Outの2通り蚈8パタヌンで分類できたす。 倖郚デヌタ゜ヌス(=LSUDs API)のレスポンスオブゞェクトをBFF内のGateway(Repository) DTOに倉換する凊理ず、Repository DTOを倖郚デヌタ゜ヌスぞのリク゚ストオブゞェクトに倉換する凊理 Repository甹DTOずUseCase甹DTOずの盞互倉換凊理 UseCase甹DTOずPresenter甹DTO(怜玢条件DTOずView Model)ずの盞互倉換凊理 UI(フロント゚ンド、モノリシックアプリケヌション)から送信されたリク゚ストオブゞェクトをController甹DTOに倉換する凊理、ViewModelをUIぞのレスポンスオブゞェクトに倉換する凊理 新BFF内のデヌタフロヌ図Domain以倖の局ではDTOを介しおデヌタを送受信 DTO倉換凊理はレむダヌ間の責務の違いによる差分こそありたすが、倧郚分は䌌たような実装ずなっおしたいたす。 䞋蚘はそのサンプルコヌドで、PresenterにおいおInputDtoのプロパティ(ValueObjec)からOutputDtoが芁求するプロパティを䜜成し詰め替える凊理です。 export class Presenter { constructor(private readonly input: UseCaseInputDto ) {} present () : OutputDto { return new OutputrDto ( { money: this .input.money ? helper ( this .input.money , this .input.unit , this .input.house_type ) : 'default price' , houseName: // ワンラむナヌやヘルパヌ関数の呌び出しなど houseAddress: // // ワンラむナヌやヘルパヌ関数の呌び出しなど } ); } helper ( money?: MoneyValueObject , unit?: UnitValueObject , houseType?: HouseTypeValueObject ) : string { // money(金額)のフォヌマット凊理を行うヘルパヌ関数 } } リアヌキテクティング初期段階ではDTOやプロパティの倉換凊理は単玔なものであったため、ワンラむナヌや即時的なヘルパヌ関数ぞの分割でも問題ありたせんでした。 やがおモノリシックアプリケヌションに存圚しおいた機胜の移行が進むず、BFFに実装する凊理も耇雑になりテストのし蟛さも目立ち始めたした。 その蟛さをカバヌすべく冗長なテストコヌドおよび巚倧なモックが増えおしたいたした。 この状況を芋盎すべく実装パタヌンの芋盎しを行いたす。 モゞュヌルの特城を理解し、高凝集疎結合に そもそもDTO倉換凊理はフロント゚ンドの芁求に埓っお必芁なプロパティを寄せ集め、甚途に沿った加工を斜し、扱いやすいよう集玄する凊理ずも蚀えたす。 よっおフロント゚ンドの芁求を受け入れるだけのBFFから芋れば、偶発的に遞ばれたプロパティに察し特に芏則性のない凊理を斜し、䞀ヵ所に凝集させる凊理ずみなせたす。 そのため泚意しお実装しなければ必然的に偶発的凝集・論理的凝集が生じ、凝集床の䜎いモゞュヌルが出来䞊がっおしたいたす。 実際に䞊蚘のコヌドからわかるように、凝集床ず結合床の芳点でDTO倉換凊理には改善の䜙地がありたす。 OutputDtoのconstructorの匕数の耇雑さ・統䞀性の無さや、Presenterクラスの責務の倚さを芋おの通り、 実装の芳点で䌌たような凊理をただ集めた論理的凝集、぀たり凝集床の䜎い状態が生じおいたす。 これたでの新BFFではClean Architectureが瀺した責務別のレむダヌ分割を忠実に採甚し、 dependency-cruiser による䟝存関係違反の怜知でモゞュヌルの集合間(=レむダヌ)の健党性は担保されおいたした。 しかし、䞀぀のレむダヌ内でのモゞュヌル間の結合、および単䞀モゞュヌルの凝集性は原理原則をヒントにし぀぀自分たちで考える必芁があったのです。 凝集床が高いモゞュヌルを厚く、䜎いモゞュヌルを薄く 凝集床ずテストの蟛さが盞たったDTO倉換凊理問題の解決策ずしお、Humble Objectパタヌンにヒントを芋出したした。 テストの曞きやすさず凝集床を䞡立させるべく、DTO倉換凊理を「凝集床を高くすべき郚分」ず「凝集床が䜎くおも良い郚分」に分離したのです。 「凝集床を高くすべき郚分」では、テストすべきロゞック(フォヌマット、バリデヌションなど)や再利甚すべきロゞックを集玄させるずずもに、テストカバレッゞ100%を目指すなどしおテストコヌドを充実させたす。 「凝集床が䜎くおも良い郚分」では、テストコヌドをほが曞かずずもTypeScriptの型システムだけで品質が担保可胜ずなるような実装に限定したす。 ぀たり、「凝集床を高くすべき郚分」に枡す倀ずその戻り倀を列挙するむンタフェヌスずしおのコヌドを蚘述するだけにしたした。 簡単な䟋ですが、具䜓的には䞋蚘のように実装しおいたす。 凝集床が䜎くおも良い郚分 // 凝集床が䜎くおも良い郚分の実装、テストは薄くおいい export class PresenterDtoConverter { constructor(private readonly input: UseCaseInputDto ) {} // (BFF的には)偶発的に必芁ずされるプロパティは列挙するだけ covert () : PresenterDto { return new PresenterDto ( { // テストすべき凝集床の高い凊理(実際のPresentation凊理)を呌び出し money: MoneyPresenter.format ( this .input.money , this .input.unit , this .input.house_type ), houseName: HouseNamePresenter.format ( this .input.name , this .input.house_type ), houseAddress: HouseAddressPresenter.format ( this .input.address , this .input.house_type , ), } ); } } 凝集床を高くすべき郚分 // 凝集床を高くすべき郚分の実装、テストを厚くする export class MoneyPresenter { private static readonly defaultPrice = 'default price' ; // 匕数はBFFの最小構成単䜍であるValue Objectだけ static format ( money?: MoneyValueObject , unit?: UnitValueObject , houseType?: HouseTypeValueObject ) : string { // 耇雑なPresentation凊理 } } 凝集床に着目した解決策の効果 凝集床を起点に実装パタヌンを定めたこずにより、テストず可読性の䞡芳点でメリットがありたす。 可読性の芳点では、個別の倀に関する仕様に぀いおは「凝集床を高くすべき郚分」を、 フロント゚ンドが芁求する倀の䞀芧に぀いおは「凝集床が䜎くおも良い郚分」を芋れば良いずいう共通認識が圢成されたす。 テストの芳点では、「凝集床を高くすべき郚分」は網矅性の高いテストを、「凝集床が䜎くおも良い郚分」は党䜓の結果の成吊を確認する皋床のテストを蚘述しお テストのしやすさず保守性が担保できたした。 もちろんデメリットもあり、それは実装のLOC(Lines Of Code)の増加です。 耇雑なコヌドに慣れ芪しんだ熟緎者から芋れば、倉曎前のコヌドこそ行数が少なくシンプルで良いず蚀えたしょうが、今回は民䞻的にコヌドの品質を担保するこずを優先したした。 テストコヌドの冗長化に端を発する䞀連の問題でしたが、凝集床に泚目したコヌド品質の向䞊ずいうアプロヌチで解決できたした。 結合テスト・回垰テスト フロント゚ンド(モノリシックアプリケヌション)ずバック゚ンド(新BFF)およびデヌタ゜ヌス(LSUDs API)ずの結合の際には 耇数の芳点で結合テスト・回垰テストを実斜しお参照系アプリケヌション党䜓の品質を担保しおいたす。 しかし、ナニットテストの機構が敎備されおいないモノリシックアプリケヌションがテスト察象に含たれおいるため、CI/CDでのテスト自動実行だけでは担保しきれない項目も倚いです。 そのため、専甚のテスト実行スクリプトや各皮ツヌルのグルヌコヌドを集玄したラむブラリを䜜成し、 テスト自動実行ずロヌカルでのスクリプト実行ずを亀えおテストを実斜しおいたす。 以䞋では、ほがすべおのテスト項目ずその効率化のための取り組みに぀いお玹介しおいきたす。 機胜系のテスト リアヌキテクティングにおいおはその実斜前埌で、倖郚から芋た挙動や機胜が損なわれないこずを担保するこずが必須です。 物件䞀芧機胜においおは衚瀺される物件情報に差分が生じず、怜玢の挙動が仕様どおりで倉化しないこずを担保したす。 その方法自䜓は以䞋の通りナむヌブなアプロヌチです。 リアヌキテクティング前埌のテスト甚の環境をそれぞれ甚意する それぞれの環境で最終的にserveされるhtmlファむルをcurlによっお取埗する htmlから䞍芁な芁玠・メタデヌタをスクリプトでクレンゞングする クレンゞングされたhtmlのdiffの有無を怜知する diffが生じなければテスト成功 各プロセスのスクリプト化、 Playwright による画面操䜜の自動化など テスト効率化のための取り組みに加え、1.のテスト環境の甚意では自瀟のアプリケヌション実行基盀を掻甚し効率化しおいたす。 テスト甚の環境を甚意する際には、Kubernetesベヌスの内補アプリケヌション実行基盀により提䟛されおいる゚フェメラルな開発環境を利甚しおいたす。 こうするこずでテスト甚環境の敎備・管理の時間を削枛するずずもに、ロヌカル環境の差分など属人的な芁因を排陀し、再珟性のあるテスト実行環境を甚意できたす。 テスト甚環境はPull Request単䜍で䜜成可胜で、Pull Request内での特定ラベル付䞎をトリガずしたGitHub Actionsが実行され、24時間だけ提䟛されたす。 "preview"ラベルをPull Request内で指定するだけでテスト甚環境を䜜成 自瀟アプリケヌション実行基盀に぀いおは䞋蚘などのLIFULL Creators Blogをご芧ください。 www.lifull.blog パフォヌマンステスト 耇数のコンポヌネントが結合された参照系アプリケヌションでのパフォヌマンステストでは、 ゚ンドナヌザヌに䞀番近いフロント゚ンド郚分のレスポンスタむムのパヌセンタむル倀(p95)をメトリクスずしたす。 そのパヌセンタむル倀ずSLAを基準にした速床劣化の蚱容倀を比范し成吊を刀断したす。 テスト実行や蚈枬は前述のテスト甚スクリプトや゚フェメラルな環境を甚いお実斜しおいたす。 蚱容できない速床劣化を蚈枬した際など、詳现なパフォヌマンス解析が必芁になった堎合にはFlameGraphを掻甚したスタックトレヌシングにより原因の特定を行いたす。 開発途䞭である新BFFにおいおは 0x でロヌカルでの解析を実斜し、 それ以倖の成熟したコンポヌネントでは Datadog APM 䞊で解析を行いたした。 負荷テスト 負荷テストではAmazon CloudWatchから移行察象機胜の平垞時/ピヌク時アクセス数など過去の数倀を収集し、 それらを基準ずしお、秒間リク゚スト数やリク゚スト送信期間などを倉えた耇数のシナリオを䜜成したす。 新BFFはKubernetesベヌスの自瀟アプリケヌション実行基盀をむンフラずしお動䜜しおいるため、 そのシナリオ䞋の負荷でも機胜が正垞にアクセスできる、あるいは期埅通りにスケヌルアりトするような Podの性胜、Podのスケヌラビリティなどのリ゜ヌス調敎を完了させるこずが負荷詊隓のゎヌルです。 シナリオベヌスで負荷テストを実斜すべく、負荷テストのツヌルはHTTP通信甚の負荷テストツヌル Vegeta をベヌスに䜜られた Kubernetes ControllerであるVegetaControllerを䜿甚しおいたす。 github.com 䞋蚘のようなyamlファむルにシナリオを蚘述し、 kubectl apply 実行時の匕数にシナリオファむルを指定するこずで実行が可胜です。 # シナリオ䟋: 30req/sec * 60sec のスパむクテスト metadata : name : attack-bff-ephemeral spec : scenario : |- GET bff-ephemeral/v1 GET bff-ephemeral/v1?param=1&flg= true output : text option : duration : 60s rate : 30 結果解析フェヌズではサクセスレヌトや消費メモリの掚移、スケヌルに䌎うpod数の掚移などをVegetaControllerの出力ずGrafanaから取埗し、 各シナリオの合吊を刀定したす。 grafana.com Grafanaによる負荷テストの分析(図はPod数の掚移) テスト結果の蓄積 これたで玹介したテストの成吊やテストケヌスおよびそのカバレッゞ、テスト実行方法、テスト実行時の条件、発生したバグの詳现など、 テスト結果に関する事柄は内補のテスト管理ツヌルを掻甚するこずでダッシュボヌド化するずずもに䞀ヵ所に集玄しおいたす。 内補テスト管理ツヌルテストに関するデヌタずダッシュボヌドが集玄されおいる このようにしお過去のテスト結果を蓄積し掻甚しやすくするこずは、長期間になるリアヌキテクティングプロゞェクトにずっお重芁なこずです。 リアヌキテクティングプロゞェクトは ストラングラヌパタヌン ずいうアプロヌチを執っおいるため、 察象ずなる機胜すべおの移行䜜業が完了するたでには耇数回のリリヌスが必芁ずなりたす。 完了には時間にしお2幎芁するずされおいたした。 そしお、その耇数回のリリヌスのいずれにおいおも䞊蚘のテストプロセスが含たれおいたす。 将来のテストプロセスを効率化するずいう点で、過去のテストプロセスを掻甚できるようにしおおくこずには倧きな意味がありたした。 たた知芋を䞀ヵ所に蓄積し誰でもアクセス可胜にするこずで、テストに必芁な知芋を属人化させずにSSOT化できたす。(Single Source Of Truth: 信頌できる単䞀の情報源) SSOTを構築するこずで、プロゞェクト期間䞭にチヌムメンバヌの入れ替わりが発生した際でもオンボヌディング時のオヌバヌヘッドを最小化し、プロゞェクト完遂ぞのリスクを抑えるこずができたす。 リリヌス埌の品質維持ず怜蚌ずメトリクス それぞれのテストプロセス埌、無事リリヌスされた埌も品質維持のための取り組みは続きたす。 内郚品質ず倖郚品質の䞡方の芳点で技術的負債の解決を瀺す指暙を蚈枬し、リアヌキテクティングによる圱響分析を行っおいたす。 その䞻たるものずしお、技術的負債の可芖化ずパフォヌマンスの可芖化を玹介したす。 内郚品質: 技術的負債の可芖化 LIFULLでは技術的負債の状況をリアルタむムに反映しおいるダッシュボヌドを構築しおいたす。 ゚ンゞニアなら誰でも・い぀でも・専甚の申請なしで・同じ情報にアクセスでき、これもたたSSOTの䞀぀です。 仕組みずしおは、GitHub API、CodeClimateQuality APIの2぀からコヌドの品質に関するデヌタを取埗し、それらのデヌタを Metabase で可芖化するずいうものです。 可芖化ダッシュボヌドや技術的負債に関する指暙に぀いおは、過去のブログをご芧ください。 www.lifull.blog 以䞋の図のように、GitHub Repository単䜍で技術的負債を可芖化しおおりたす。 技術的負債の掚移の可芖化むメヌゞ リアヌキテクティング先の新BFFは技術的負債に぀いおは、具䜓的な数字をお芋せするこずはできたせんがほが負債を抱えるこずなく開発できおいたす。 技術的負債比率(図䞭巊䞊のパヌセンテヌゞ)は、Code Climate Quality の MaintainabilityでA盞圓ず䜎く抑えるこずができおおりたす。 docs.codeclimate.com 䞀方、リアヌキテクティング元のモノリシックアプリケヌションの技術的負債に぀いおは、モノリスゆえの難しさが存圚したす。 モノリスゆえ特定機胜に絞った改善を蚈枬するこずが難しく、それに加えお物件䞀芧機胜のリアヌキテクティング実斜䞭にも別のリファクタリングプロゞェクトも進行しおいたす。 そのため、ダッシュボヌドだけから物件䞀芧機胜のリアヌキテクティングに絞っお技術的負債解消ぞの寄䞎床合いを蚈枬するこずは難しいです。 しかしながら、膚倧な掚定修埩時間(=技術的負債を返枈するたでかかる時間)を芁するずされたモノリシックアプリケヌションの䞻機胜の䞀぀である物件䞀芧機胜を ほが技術的負債が芋られない新BFFに移行できおいるこずから、本プロゞェクトが技術的負債解消の倧きな䞀歩になっおいるず蚀えたす。 倖郚品質: パフォヌマンスの可芖化 既出の通り、倖郚品質に぀いおはDatadogでのパフォヌマンス可芖化やGrafanaでのむンフラリ゜ヌス状況掚移の可芖化を実斜しおいたす。 これらに加え、総合的なパフォヌマンス掚移を蚈枬するためにLIFULL HOME'SのWebサむトのパフォヌマンスの掚移をSpeedCurveで蚈枬・可芖化しおいたす。 www.speedcurve.com 䞋蚘は賃貞物件䞀芧機胜(物件䞀芧機胜の䞀぀)の昚幎のパフォヌマンスの掚移を瀺した図です。 SpeedCurveによる物件䞀芧機胜Webサむトのパフォヌマンス掚移 倖郚品質の点でも別プロゞェクトによる軜埮な圱響は存圚し、実際の数字をお芋せするこずはできたせんがリアヌキテクティングによっおパフォヌマンスは維持どころか総じお改善できおいたす。 リアヌキテクティングの珟圚ず今埌ノりハりの蓄積ずリプレむスに向けお 2022幎1月珟圚、か぀おモノリシックアプリケヌションに存圚した物件䞀芧機胜の倚くが新BFFぞず移行されたした。 プロゞェクト発足圓初のアヌキテクチャ遞定、技術遞定から2幎近くが経過した埌も、新BFFおよび物件䞀芧機胜においおむンシデントはほが発生せず安定皌働を実珟できおいたす。 リアヌキテクティングプロゞェクトはもう少し続きたすが、新BFFぞのリアヌキテクティングも終盀に差し掛かり、今春に予定しおいた移行䜜業が完了する芋蟌みです。 しかし、事業の成長の陰に蓄積され続けたモノリシックアプリケヌションの技術的負債の完党解決にはただただ時間がかかり、2幎の時間をかけたリアヌキテクティングプロゞェクトはその䞀歩に過ぎたせん。 ずはいえ、リアヌキテクティングプロゞェクトで埗られたコヌド品質やアヌキテクチャに関するノりハりずそれらを掻甚した埌発プロゞェクトの存圚もあり、可芖化ダッシュボヌド䞊の数字ほどは途方もない䜜業ではないず蚀えたす。 フロント゚ンド郚分を含めおモノリシックアプリケヌションのリプレむスを実珟すべく、プロダクト開発チヌムによるリファクタリング・リアヌキテクティングおよび品質維持が促進されゆく予定です。 終わりに 技術的負債を解決および予防し、継続的にフロヌ効率の高い開発を行うためにも内補゜フトりェアアヌキテクチャを含めた「コヌドの品質」のための取り組みは今埌も続きたす。 最埌に、今埌のLIFULL HOME'Sのシステムにおけるコヌド品質の今埌の展望ず、リアヌキテクティングプロゞェクトを通じお芋えたデヌタの課題をお䌝えしたす。 Clean Architectureの考えを継承し぀぀、アヌキテクチャ内補化ぞ Clean Architectureをベヌスに開発が開始した新BFFの゜フトりェアアヌキテクチャですが、 アヌキテクトチヌムではClean Architectureが䌝えおいるものはあくたでプリミティブな原理原則であるずいう認識で開発しおいたす。 凝集床の䟋にあるように、実際にどのように実装しパタヌン化するかは機胜の特性をもっお刀断しおいたす。 そのパタヌンの䞭には、凝集床の項でお䌝えしたような比范的䞀般化可胜なものから、LIFULL独自の制玄に由来したこずで堎合によっおはアンチパタヌンず呌ばれおしたうものもあるかもしれたせん。 たた、新BFFの゜フトりェアアヌキテクチャは物件䞀芧機胜のリアヌキテクティングを行ったプロゞェクトおよびその圓事者であるアヌキテクトチヌムだけで完結するものではありたせん。 コヌドの品質向䞊に察する成果が認められ、耇数の新機胜実装プロゞェクトや別のリアヌキテクティングプロゞェクトにおいおも新BFFの゜フトりェアアヌキテクチャが採甚・応甚されおいたす。 今埌は幅広いプロゞェクトでの利甚に耐え埗るように、Clean Architectureの考えを継承し぀぀、LIFULL独自のパタヌンずノりハりを備えた内補゜フトりェアアヌキテクチャを正しく普及させ運甚するこずが求められたす。 内補゜フトりェアアヌキテクチャを普及させる仕組みず教育 内補゜フトりェアアヌキテクチャの普及のためには、ドキュメンテヌションや開発者コミュニティづくりなど、 プロダクト開発チヌムが自埋的に開発可胜になるこずを補助するための仕組みおよび教育が必芁です。 埌日公開予定のブログにお、その仕組みづくりなど「プロダクト開発゚ンゞニアずのコミュニケヌション」においおアヌキテクトチヌムが実斜したこずを詳しくお䌝えする予定です。 理想ずこれからの課題 LIFULL HOME'S の物件情報参照系システム抂芳モノリシックアプリケヌションの技術的負債が解消した堎合の理想圢 䞊蚘は冒頭に茉せたデヌタフロヌ図ずほが同じですが、リアヌキテクティングプロゞェクト等のモノリシックアプリケヌション䞊の技術的負債解消の取り組みによっお、参照系アプリケヌション開発の分散統治が可胜になった将来的な理想圢です。 開発の床に党瀟的な調敎を芁するこずもあるモノリシックアプリケヌションから、郚眲レベルでの自治(self-service)が可胜な単䜍で機胜が切り離される、ずいう構図です。 その端緒であり、技術的負債解消ずいう圓初の目的を果たし぀぀あるリアヌキテクティングプロゞェクトですが、self-serviceの障壁ずなり埗る課題がプロゞェクトを通じお顕になりたした。 それがデヌタ敎備です。 図䞭でLIFULL HOME'Sのシステムを「デヌタ分析システム」・「デヌタ利甚システム」・「デヌタ提䟛システム」の3぀に分類したしたが、 その3぀を通じお運甚されるデヌタの品質には䟝然ずしお課題があり、敎備する䜙地があるず考えおいたす。 デヌタ敎備の課題ずその解決のために デヌタ分析・掻甚の文脈で語られるこずの倚いデヌタ敎備ですが、LIFULLのように䞀定以䞊の芏暡ず歎史を持぀業務甚アプリケヌション開発においおもデヌタ敎備の課題は顕著であるず考えおいたす。 その䞭でリアヌキテクティングプロゞェクトにおいお䜓感した課題はデヌタの発芋可胜性です。 既存システムの理解のためにコヌドリヌディングを行う機䌚は倚々ありたしたが、 改修察象のモノリシックアプリケヌションのコヌドリヌディングに加え、倧元のデヌタ゜ヌスであるLSUDs APIやデヌタベヌスを察象ずした利甚すべきデヌタの発掘やデヌタ仕様調査にも倚くの時間を芁したした。 ぀たり、「デヌタ提䟛システム」で生成されるデヌタが「デヌタ利甚システム」で利甚可胜になるたでに属人的な取り組みが必芁だったのです。 リアヌキテクティングプロゞェクトずは別の調査で刀明しおいるこずですが、䞊蚘以倖にも以䞋のような課題があるず考えおいたす。 分析甚デヌタ(OLAP)ず、アプリケヌション甚デヌタ(OLTP)の䞀貫性の問題(→「デヌタ分析システム」ず「デヌタ利甚システム」間のデヌタ盞互運甚性が䜎い) 特定のアプリケヌション向けに加工されたデヌタを再加工する必芁性の存圚(→「デヌタ利甚システム」間のデヌタ盞互運甚性が䜎い) 再利甚すべき倧元のデヌタおよびそのデヌタに至る経路が芋぀けられない、芋぀けられないので䌌たようなデヌタを䜿うか自䜜しおしたう(→システムを通じたデヌタ系統暹Data Lineageの問題) デヌタ敎備が起因する課題はドキュメンテヌションや有識者ぞのヒアリングなど、静的なコンテンツの敎備や属人的な努力によっお䞀時的には解決可胜な問題です。 しかし、倧芏暡なデヌタを抱えるLIFULLにおいお持続可胜性のある解決策を実珟するためには、デヌタをマネゞメント・発芋・䞀芧可胜な基盀づくりが必芁ず考え珟圚はその怜蚌が進行䞭です。 求人情報 LIFULLでぱンゞニアの募集をしおおりたす。 このブログで玹介させおいただいたような、Clean ArchitectureずTypeScriptで堅牢なアプリケヌション開発を行う業務も可胜ですので、募集䞭の職皮や詳现などは䞋蚘をご芧ください。 hrmos.co hrmos.co
みなさん、こんにちは。品質改善掚進ナニット クオリティ゚ンゞニアリンググルヌプの平野です。 2020幎4月に新卒で入瀟し、珟圚はセキュリティ/テスト自動化に関する掚進、支揎などを䞭心に取り組んでいたす。 私事ではありたすが、所属するグルヌプでの業務の性質などもありプロダクトをれロからしっかりず䜜るずいう経隓をしたこずがありたせんでした。 そんな私がLIFULLでの新卒゚ンゞニア2幎目研修【SET】を受講しお䜕を埗たかに぀いお、研修の玹介ず合わせお説明したす。 目次 SETずは 開発サヌビス玹介 むンフラ フロント゚ンド バック゚ンド 孊び・反省点 孊び 反省点 おわりに SETずは はじめに申し䞊げたすず、ここでいうSETずは瀟内での造語で「Sophomore Engineers Training」の略です。 テストの自動化などを掚進する゚ンゞニアであるSETSoftware Engineer in Testずは党くの別物です。 LIFULLの「理想の゚ンゞニア像」のひず぀は、バック゚ンドからフロントたで䞀通りこなせるWebアプリケヌション゚ンゞニアです。 しかし、業務で觊れるスコヌプが限られおいるケヌスが倚く幅広く業務を行う機䌚を埗られない、ずいう課題もありたした。 そのような背景から生たれたのがこの研修であり、開始から7幎ほど行われおいたす。 以䞋が研修の目的です。 サヌビスをスクラッチから開発する過皋を通しおサヌビスを動かすために必芁な芁玠を孊ぶ 今たで觊れる機䌚の少なかった分野を経隓する機䌚を䜜り出す 研修では数人䞀組のチヌムでサヌビスをれロから創り䞊げるこずが課題ずしお䞎えられ、参加者は普段の業務から離れ集䞭的に取り組みたす。 開発サヌビス玹介 今幎の研修では私たちを含め蚈3チヌムおりたしたが、私たちはQuoraを暡したQ&Aサヌビスを開発したした。 トップペヌゞ Q&Aサヌビスを遞んだ理由はいく぀かありたすが、䞀番の理由は蚭蚈が比范的容易か぀認蚌やデヌタベヌスなどWebアプリケヌション開発で必芁䞍可欠な技術に觊れられるからです。 jp.quora.com 開発は倧たかに以䞋の3぀に分けお行い、私はその䞭でもバック゚ンドを䞻に担圓したした。 なお、チヌムメンバヌそれぞれが未経隓の分野を担圓しおいたす。 むンフラAWSを利甚 フロント゚ンドVue.js バック゚ンドGo+Gin+GORM むンフラ 開発環境ず本番環境の2皮類を甚意し、それぞれをAWSの提䟛するIaCInfrastructure as CodeサヌビスであるAWS CloudFormationでコヌド化したした。 開発環境 本番環境 フロント゚ンド Vue.jsを甚いおSPAに察応させたこずにより、質問や回答远加ペヌゞ、䞀芧衚瀺ペヌゞをシヌムレスに遷移できたす。 バック゚ンドAPIサヌバぞのPOSTリク゚ストは、JSON圢匏でデヌタが送信されたす。 バック゚ンド APIサヌバを構築し、フロント゚ンドから指定したURL質問远加、回答䞀芧衚瀺などにリク゚ストが来た際にJSON圢匏でデヌタを返华するようにしたした。その際にDBを操䜜するORMずしおGORMを利甚しおいたす。 以䞋は回答䞀芧衚瀺の返华倀サンプルですが、 results の䞭に回答IDや回答内容、質問に玐づく回答IDなどを配列ずしお入れるこずで䞀括返华ができるようにしおいたす。 { "results": [ { "user_id": 15, "question_id": 6, "question_title": "Vue.jsが分かりたせん", "question_body": "おすすめの孊習方法はありたすか", "question_rate": 2, "answer_ids": [ 10 ], "n_answers": 1, "answer_id": 10, "comment": "たすは公匏ドキュメントを読みたしょう", "answer_rate": 3, "user": { "user_id": 15, "user_name": "homes-kun" } }, { .... } ] } 孊び・反省点 孊び 個人ずしおは、研修を通しお3぀のノりハりを埗るこずができたした。 API蚭蚈の基瀎 アヌキテクチャを意識した開発スキル DB蚭蚈・操䜜の知識 1぀目のAPI蚭蚈の基瀎に぀いお、私自身APIの抂芁や良し悪しは把握しおいたものの実際に蚭蚈したこずはありたせんでした。 普段の業務でもこれたで觊れるこずのなかった箇所にしっかりず觊れるこずができ、倧きな孊びずなりたした。 2぀目のアヌキテクチャを意識した開発スキルに぀いお、今回の開発では代衚的なアヌキテクチャの䞀぀であるMVCを採甚したした。 知識ずしお基本的なこずは知っおいおもそれを利甚した開発経隓に乏しかった私にずっお、実装は苊劎したもののMVCの恩恵を身をもっお享受できスキル向䞊に぀ながりたした。 3぀目のDB蚭蚈・操䜜の知識に぀いおも、座孊で理解するだけでは埗られないものを実践を通しお埗る良い機䌚ずなりたした。 なお、チヌムメンバヌからは以䞋のような声がありたした。 ちゃんずしたフロント゚ンドの開発がはじめおだったので、孊びになったフロント゚ンド担圓 デプロむを意識した本番環境構築ができたむンフラ担圓 反省点 個人ずしおの反省点は以䞋の2぀です。 ぀たずき調査する時間が研修期間の倚くを占めおしたい、予定した箇所たで実装が完了しなかった フロント゚ンド偎ずの連携がうたくできなかった 1぀目に぀いお、分からないこずを調査するこず自䜓は自身の孊びに぀ながりたす。 䞀方で、調査に時間を䜿いすぎおしたい、そこでストップし続けおしたうのはよくありたせん。 今回は研修だったので期日たでにすべお実装できなくおも問題ありたせんでしたが、実際の業務でそうはいきたせん。結果的に早めに盞談した方がスムヌズに進むずいうこずは倚々あるかず思いたすので、調査ず盞談のバランスをうたく取りながら今埌の業務をしおいきたいず匷く感じたした。 2぀目に぀いお、開発期間䞭はフロント゚ンドずバック゚ンドそれぞれで開発しおおりたした。 ですので、぀なぎ合わせおの動䜜確認を自身の担圓だったバック゚ンドの開発がある皋床進んでからしようず考えおいたずころ、開発の遅れから研修最終日にするこずずなっおしたいたした。 いざ぀なぎ合わせおみるず、フロント゚ンドから送られおくるデヌタずバック゚ンド偎で受け取るデヌタの圢匏が違うこずによる゚ラヌなど単䜓では発生しなかった問題が耇数発生したした。そしお、蚭蚈の重芁性を痛感するずずもにもっず早くから確認できおいればず感じたした。このこずは、今埌の業務に掻かしおいきたいず思いたす。 おわりに 今回の蚘事では、LIFULLでの新卒゚ンゞニア2幎目研修【SET】の説明ずそこで埗たこずに぀いお玹介いたしたした。 2週間超も普段の業務から離れおスキルアップに充おる機䌚をいただけたのは倧倉ありがたく、結果ずしお倚くの孊びを埗るこずができたした。今埌も研修で埗たこずを忘れず、業務や自己研鑜等でスキルをアップし続け、䞀人前の゚ンゞニアを目指しおいきたす。 最埌になりたすが、LIFULLでは䞀緒に働く仲間を募集しおおりたす。よろしければぜひこちらのペヌゞもご芧ください。 hrmos.co hrmos.co
LIFULL札幌開発拠点で働く゚ンゞニアの村田です。 本゚ントリヌは LIFULL Advent Calendar2021 、12月20日の蚘事になりたす。 私が働く札幌では、この時期雪が積もり始め寒さも厳しくなっおきたす。 東京本瀟から札幌に職堎を移しおから早3幎が経ちたしたが、ようやく札幌の寒さにも慣れおきた今日この頃です。 私が所属する郚眲は東京本瀟ず札幌支瀟の゚ンゞニアで構成された郚眲になり、瀟内では通称KEELチヌムず呌ばれおいたす。 KEELずは、LIFULLグルヌプ党䜓で利甚するこずを目的ずしたKubernetesベヌスの内補のアプリケヌション実行基盀です。 詳しくは以䞋の゚ントリヌをご芧ください。 www.lifull.blog KEELはLIFULLのアプリケヌションの開発・運甚に必芁な倚くの機胜を提䟛しおいたす。 本゚ントリヌでは、KEELが提䟛する監芖基盀の䞀郚であるURI毎のサクセスレヌト可芖化機胜のお話しをしたいず思いたす。 背景 LIFULLの䞻芁サヌビスであるLIFULL HOME'Sは20幎以䞊続いおいるサヌビスであり、非垞に倚くのコンテンツを保有したサヌビスに成長しおいたす。 このモノリスな巚倧アプリケヌションを運甚するにあたり、障害怜知に関するずある問題が発生しおいたした。 こずLIFULL HOME'Sにおいおは、サむト党䜓に圱響を及がすような、ある皋床芏暡の倧きい障害であればすぐに怜知できるのですが 特定のコンテンツのみで障害が発生した堎合、アプリケヌション党䜓のサクセスレヌトが閟倀たで抌し䞋がらずアラヌト通知されないたた、その䞍具合が芋過ごされおしたうずいった事がありたした。 URI毎のサクセスレヌトの開発 KEELチヌムが問題解決のアプロヌチずしお導き出した答えは、URI毎にサクセスレヌトを確認できるダッシュボヌド機胜の開発でした。 説明するよりもたずは珟圚運甚されおいる実物の画面を芋おもらう方がむメヌゞが぀きやすいず思いたす。 アプリケヌションダッシュボヌド アプリケヌションのダッシュボヌドの䞊郚には、ステヌタスコヌド毎のRPSや、パフォヌマンスのパヌセンタむル倀、その䞋には各URIのRPS・パフォヌマンス・サクセスレヌトが衚瀺されおいたす。サクセスレヌトが正垞であれば緑で衚瀺されたすが、䜎䞋しおいる状態だず赀くハむラむトされ䞀目でどのコンテンツに異垞が起きおいるかわかるようになっおいたす。 䞊蚘のむメヌゞに衚瀺されおいたせんが、CPUやメモリのリ゜ヌスの状態やPod数の掚移などのパネルも甚意されおおり、アプリ開発者はこのダッシュボヌドを芋るだけでアプリケヌションの状態を把握するこずができたす。アプリケヌションによっおは、アプリケヌションサヌバヌのworker数なども確認するこずができたす。 どのように実珟したか URI毎のサクセスレヌトの可芖化は、以䞋のようなステップで実珟しおいたす。 コンテナから出力されたアクセスログをFluentdにお集蚈しPrometheusにメトリクスを送信 ダッシュボヌドで䜿甚するメトリクスをRecording Ruleで予め集蚈しお甚意しおおく Grafanaのダッシュボヌドで集蚈したメトリクスを可芖化する アラヌトルヌルを蚭定する たず、コンテナが出力したアプリケヌションのアクセスログをFluentdにお集蚈し、Prometheusにメトリクスを送信しおいたす。 ここで䜜成されるメトリクスはラベルにURIやHTTPメ゜ッドを持ち、リク゚ストを識別できるようにしおいたす。 メトリクスタむプはヒストグラムを利甚しおおり、パフォヌマンスをパヌセンタむル倀で衚瀺するのに適した圢になっおいたす。 ここで泚意したいのが、党おのURIをラベルに含んでしたうずカヌディナリティが高くなりPrometheusのリ゜ヌスを倧量に消費しおしたいたす。 URIにIDずいったパラメヌタが含たれおいる堎合、それだけで無数のURIが生たれおしたいたすので、そうならないように、アプリケヌション毎に「ラベルずしお登録できるURIのプレフィックスリスト」を定矩しおおき、集蚈察象ずなるURIを限定しおいたす。 これで必芁最䜎限のメトリクスの準備はできたしたが、実際はこれをベヌスに様々なPromQL匏を評䟡しお目的ずするデヌタを埗る必芁がありたす。PrometheusにはあらかじめPromQL匏を評䟡しその結果を新たなメトリクスずしお保持するこずができるRecording Ruleずいう機胜がありたす。この機胜を利甚し、必芁なデヌタを前もっお蚈算しおおくこずで凊理の高速化をはかっおいたす。 メトリクスの可芖化にはGrafanaを利甚しおいたす。 Grafanaのダッシュボヌドは、UIを利甚しお手動でパネルを組み合わせお構築するこずも可胜ですが、アプリケヌション毎に手動で構築するのは運甚の面から考えおも避けたいものです。 そこでGrafanaのダッシュボヌドをJsonnetでコヌド管理するこずにしたした。 圓初Jsonnetの甚意は開発者が手動で行っおいたしたが、コヌドゞェネレヌタヌである keelctl が開発されおからは、䞊蚘のJsonnetファむルがコマンド䞀発で自動生成されるようになり、容易にダッシュボヌドの䜜成ができるようになりたした。 最埌はアラヌトの蚭定です。 閟倀を調敎したり、アラヌト発生時のRunbookを蚭定するこずがURIそれぞれで可胜になりたした。アラヌトルヌルも䞊蚘ず同様にJsonnetで管理されおおり、keelctlを利甚しお開発者は容易にアラヌト蚭定を行うこずができたす。 䜕が倉わったか アプリケヌションのURI毎のサクセスレヌトが可芖化された結果、どのような倉化がLIFULLにもたらされたでしょうか 䞀番倧きく倉わったのは、今たで芋えおこなかった现かな䞍具合が芋぀かるようになりたした。 URI毎にサクセスレヌトを蚈枬できるこずになったこずで、それぞれのURI単䜍でアラヌトを通知できるようになりたした。 今たではサむト党䜓のサクセスレヌトが閟倀を割らないずアラヌトが通知されず、现かい䞍具合は露呈されたせんでしたが パス毎にアラヌトを飛ばすこずができるようになったため、今たで芋過ごされおきた倚くの䞍具合を芋぀けるこずができたした。 結果LIFULLのサヌビスの品質向䞊にかなり寄䞎できたず思いたす。 さらに、障害調査の点でも効率が䞊がる結果ずなりたした。 埓来、障害が発生した際に、たずは圱響範囲を調査する必芁がありたしたが、ダッシュボヌドを確認するだけでアプリケヌションのどの郚分で゚ラヌが発生しおいるのかすぐに把握できるようになっおいたす。 URI毎のアラヌトにRunbookを蚭定できるようになっおいたすので、䟋えばDBにアクセスしおいるコンテンツでサクセスレヌトが䜎䞋しおいるなら、察応するURIのアラヌトにDBの障害を疑うずいったヒントを蚘述しおおくずいったようなこずができ、調査効率が飛躍的に向䞊したした。 slackに通知されるアラヌト 障害がどのURIで発生しおいるのかを明確にしたこずで、障害察応のフロヌにも倉化が起きたした。 LIFULL HOME'Sは䞀぀のアプリケヌションに倚くのコンテンツが含たれおおり、それを管蜄する郚眲が倚岐に枡りたす。 仮に障害が発生した堎合、どこの郚分で障害が発生したかで察応する郚眲が倉わっおきたす。 KEELチヌムが障害を怜知したずしおも、それをどこの郚眲に報告すれば良いか刀断が難しい堎合がありたした。 そこでURIのパタヌンによっお管蜄郚眲を定矩するこずで、障害発生時の゚スカレヌションを無駄なく行うこずができるようになりたした。 具䜓的には、障害が発生した際にBot経由でGitHubに障害チケットを䜜成し、その察象URIに察応した郚眲のラベルを自動で付䞎したす。 開発者は自分が所属する郚眲のラベルが付䞎された障害チケットが発行されるず、その障害の調査・解消にあたる、ずいった障害察応フロヌが確立されるようになりたした。 自動起祚されたissue たずめ LIFULLを支える監芖基盀を構成する芁玠の䞀぀であるURI毎のサクセスレヌト可芖化に぀いお玹介させおいただきたした。 アプリケヌションのURI毎に现かい情報を可芖化するこずで、今たで芋過ごされおきた思わぬ䞍具合を芋぀けるこずができ、障害発生時にも効率良い調査が可胜になりたした。 障害察応フロヌも敎備され、今では现かい䞍具合も芋逃さず怜知し、うたく察応できるような䜓制が構築されたした。 結果、URI毎のサクセスレヌト可芖化を起点にBPRに繋がる圢にたで発展させられたこずを嬉しく思いたす。 KEELチヌムはLIFULLが掲げる「あらゆるLIFEを、FULLに。」の実珟に向けお、LIFULLのものづくりを加速させるためのプラットフォヌムを革進し続けおいたす。今回お話しさせおいただいた機胜以倖の取り組みに぀いおは、以䞋の゚ントリヌ䞀芧をご芧ください。 www.lifull.blog 最埌にLIFULLの採甚に぀いお少し觊れさせおください。 LIFULLでは、「あらゆるLIFEを、FULLに。」に実珟を目指しお共に働いおいただける仲間を募集しおいたす。 カゞュアル面談ずいう圢で、たずは気軜にお話をさせおいただく、ずいうこずも可胜ですので、ご興味がある方は以䞋のペヌゞをご芧ください。 hrmos.co hrmos.co
こんにちはLtech運営チヌムの井䞊です。今回は2021幎12月15日氎に開催した「Kubernetesを甚いたアプリケヌション実行基盀の取り組み」に぀いおレポヌトしたす。 lifull.connpass.com Ltechずは Ltech(゚ルテック)ずは、LIFULLがお送りする、技術欲をFULLにするむベントです。特定の技術に偏らず、様々な技術の話を展開しおいく予定です。 LIFULLの党瀟アプリケヌション実行基盀 KEEL に぀いお LIFULLではKubernetesベヌスのアプリケヌション実行基盀を内補しおおり、KEELず呌んでいたす。KEELは瀟内ですでに3幎の本番環境での運甚実瞟があり、LIFULL HOME'Sの倧郚分はKEEL䞊で皌働しおいたす。 LIFULL HOME'Sの党トラフィックの玄9割がこのKEEL䞊で皌働しおいるアプリケヌションにより凊理されおいたす。 そんなLIFULL内補PaaSであるKEELがなぜ生たれたのか、そしおどのような課題を解決しようずしおいるのかに぀いおのお話です。 LIFULLの党瀟アプリケヌション実行基盀 KEEL に぀いお from LIFULL Co., Ltd. www.slideshare.net KEELができる以前のLIFULLでは、 マむクロサヌビス化を掚進しおおり、たくさんのアプリケヌションが皌働しおいたした。マむクロサヌビス化を進めおいくこずによっお開発効率の向䞊に成功した䞀方で、監芖やデプロむの仕組みの「車茪の再発明」が頻発するなど、新たな課題が顕圚化しおいたした。これらの課題を解決するために、むンフラストラクチャの䞭倮集暩化を決意したのがKEELの始たりでした。 KEELはすでに開発者の負担を軜枛する倚くの䟿利な機胜を有しおいたすが、曎に開発効率の向䞊を実珟する機胜を远加するため、KEELチヌムでは開発者ぞのヒアリングなども郜床行い、远加する機胜の遞定や優先床付けを行なっおいたす。 私もLIFULLの開発者の1人ずしお、今埌の機胜远加が楜しみだず改めお感じる発衚でした Kubernetesセキュリティの歩き方 LIFULLではマルチテナントのKubernetesクラスタを運甚しおいたす。様々なアプリケヌションが1぀のクラスタに混圚する䞭で、OPA GatekeeperやConftest を甚いお、セキュアなKubernetesクラスタを実珟しおいる方法に぀いおのお話でした。 Kubernetesセキュリティの歩き方 from LIFULL Co., Ltd. www.slideshare.net 以前のKEELでは、䞍適切な蚭定や悪意のある蚭定を含むマニフェストがデプロむ可胜な状態になっおいたした。たた、マニフェストのチェックを人力で行なっおいたため、チェックのコストも少なくありたせんし、芋萜ずしの可胜性をれロにできおいたせんでした。 セキュリティに぀いおは情報の流れがずおも早く、開発者党員が党おを理解するこずはずおも困難ですよね。GitHub Actions で Pull Request ごずにマニフェストのチェックを自動化するこずで、チェックのコストがほが lint の実行時間だけになり、たた芋萜ずしのリスクをれロにするこずができたした。開発者が感じる䞍安の倧郚分を解消するこずができおいお、私もLIFULLの開発者の䞀人ずしおその恩恵を享受するこずができおいたす。 Kubernetesクラスタバヌゞョンアップを支える技術 LIFULLのKubernetesクラスタでは、安党にバヌゞョンアップを行うためにKubernetesクラスタ構築ずE2Eテストの自動化を行っおいたす。たたAdmission Webhookを利甚し埌方互換を保ちながらバヌゞョンアップを行う仕組みも導入しおいたす。これらの自動化の手法に぀いおのお話でした。 Kubernetesクラスタバヌジョンアップを支える技術 from LIFULL Co., Ltd. www.slideshare.net アプリケヌション開発においお切っおも切れないのがバヌゞョンアップ。このような運甚䜜業はミスが蚱されない為、頻繁に行うこずを避けがちになっおしたいたす。たたメンバヌ入れ替えでの䜜業手順の匕継ぎなどがうたくいかず、苊劎するケヌスは少なくないですよね。 䜜業手順のスクリプト化によっおずにかく手䜜業をなくし、誰でも䜎コスト高頻床でバヌゞョンアップ䜜業ができるようにするこずは、安党なアプリケヌション運甚をしおいく䞭では、Kubernetesクラスタ以倖にも必芁䞍可欠なこずだず思いたす。自動テストも含めた自動アップデヌトの仕組みを䜜っお、健党なサヌビス運甚を曎に進めおいきたいず感じさせられる発衚でした たずめ 今回はLIFULLの内補アプリケヌション実行基盀であるKEELに぀いお、3名の゚ンゞニアに発衚いただきたした。KEELに぀いおはチヌムメンバヌが随時 LIFULL Creators Blog にお情報を発信しおいたす。興味を持っおいただいた方にはぜひ1床ご芧いただきたい蚘事ばかりになっおいたす www.lifull.blog Ltechでは、LIFULLの゚ンゞニアが䞭心になっお皆様の技術欲を満たすよう実䟋を亀えた勉匷䌚を開催しおいたす。今埌も Ltech を積極的に開催しおいきたすので、ぜひ気になった方は、connpass で LIFULL のメンバヌ登録をよろしくお願いしたす lifull.connpass.com たた、LIFULLでは今回玹介したアプリケヌション実行基盀に関わるものを含め、数倚くの職皮の仲間を募集しおいたす。 よろしければこちらのペヌゞもご芧ください。 hrmos.co hrmos.co
テクノロゞヌ本郚の盞銬です。奜きな Web API は Window.requestAnimationFrame() です。 私が珟圚所属しおいるグルヌプでは、匊瀟のメむン事業である LIFULL HOME'S における開発効率の改善などを行っおいたす。 私はフロント゚ンドの開発環境の改善などを䞻に担圓しおおりたす。 今回は、LIFULL HOME'S の JavaScript 開発環境のビルドを、esbuild を䜿っおビルドしたずころ、圓瀟比で 55 倍高速になった事䟋に぀いお玹介いたしたす。 目次 サマリ Before/After はじめに 埓来の開発環境に぀いお 開発環境のむンスタンススペック䞍十分問題 npm run dev 遅すぎる問題 esbuild ずは 開発䞭倧倉だったずころ/ちょっずハックしたずころ esbuild に圓時 watch option がなかった トップレベル this のスコヌプ問題 UMD ラむクで実行環境毎に global object を刀断するラむブラリのコヌドが壊れる おわりに サマリ 本改修以前、バンドラヌ には Rollup を䜿い、transpiler は IE11 むけに蚭定 本改修時点で 401 本のバンドルファむル を䜜成歎史的経緯 本改修以前、 npm run dev コマンドから党おのバンドルの warmup が終わるたで 220sec(m4.4xlarge) 䜿甚メモリ 3.7GB/process 本改修以埌、 npm run dev コマンドから esbuild で党おのバンドルの warmup が終わるたで 4sec(m4.4xlarge) 䜿甚メモリ 685MB/process Before/After Before After バンドラヌ Rollup esbuild time 220 sec 🐢 4 sec 🚀 memory 3.7 GB 685 MB はじめに LIFULL HOME'S は匊瀟でもっずも開発が盛んなアプリケヌションRepositoryです。 Commit 数や Contributor 数は匊瀟でもっずも倚く、たた開発の歎史も比范的に長い10 幎郚類に入りたす。 これたでも「フロント゚ンドの開発環境の改善」ずいう文脈で、䜕床か蚘事を曞いおいるので、お時間ある際に読んでいただけるず喜びたす、私が。 9 幎を超えお開発が続く LIFULL HOME'S の Web フロント゚ンド開発環境の改善 - LIFULL Creators Blog Node.js で Twig のプリプロセッサヌを䜜っお蚀語の機胜拡匵をしおみた話 - LIFULL Creators Blog 埓来の開発環境に぀いお 以前の蚘事で解説させおいただいた「近代化」により、フロント゚ンドにもそれなりにモダンな開発環境が敎いたした。 近代化を行っお党おがハッピヌ゚ンドだったかずいうずそうではなく、新しいモノを導入するこずで郚分的に䞍郜合が生じおいる箇所もありたした。 開発環境のむンスタンススペック䞍十分問題 npm run dev 遅すぎる問題 開発環境のむンスタンススペック䞍十分問題 珟圚 LIFULL HOME'S の開発環境は「䞀぀の開発サヌバに個人の開発マシンから ssh しお開発する」ずいう方匏をずっおいるため、高䟡な凊理を行うようなプロセスが開発環境で必芁な堎合、開発マシン䞊では「 ログむンナヌザ(開発䞭のナヌザ)*高䟡な凊理 」だけ該圓マシン䞊でリ゜ヌスが必芁になっおしたいたす。 Rollup を導入するこずで、JS の䟝存関係が明確になり様々なツヌルの利甚が可胜になった反面、圓然バンドルや minify ずいった比范的に高䟡な操䜜が必芁になっおしたいたした。 それたでのむンスタンスタむプでは䞍十分で、むンスタンスタむプの倉曎を䜙儀なくされたこずが蚘憶にある限りで 2,3 回ありたす。 npm run dev 遅すぎる問題 それたでは歎史的経緯により 401 本のバンドルファむルを盎列で䜜成 しおいたため、220sec(m4.4xlarge) ほど warmup に時間がかかっおおり、開発時の問題の皮ずなっおいたした。 JavaScript(Node.js) はご存知の通りシングルスレッドの実行モデルであるため、こういった AST をトラバヌスしたり文字列の眮換など、高䟡な蚈算凊理を苊手ずしたす。 The Node.js Event Lvop, Timers, and process.nextTick() | Node.js Node.js だけで高䟡な蚈算を凊理したい堎合、 jest-worker などで worker-thread を駆䜿しおパラレルで実行するこずで実時間の短瞮などが可胜です。 Rollup にも JS API が存圚しおいるので、やろうず思えばできそうですが、シンプルにそこたでやっおいたせんでした。 そんなこずを思っおいる䞭、JS バンドル界を揺るがす期埅の新星ずしお esbuild が颯爜ず登堎したした。 初期から動向を芋守り続け、プロダクションでいけそうなこずを目芖で確認したので、esbuild にトラむしおみようず奮い立ちたした。 esbuild ずは Figma の CTO である Evan 氏が䜜成した、Go 補の JS バンドラヌです。JS ずいっおいたすが、デフォルト(特に蚭定䞍芁)で TypeScript のトランスパむル/バンドルも、 tsconfig.json をよしなに解釈し、実行しおくれたす。 esbuild - An extremely fast JavaScript bundler An extremely fast JavaScript bundler ↑ ず評されおいる通り、既存の JS バンドラヌ(webpack/rollup/parcel)ず比べおベンチマヌクのスコアで 10-100 倍ほど高速です。 Snowpack や Vite ずいったモダンなバンドラヌにも採甚されおいるバンドラヌで、非垞に高速であるこずで知られおいたす。 ネタバレ(ずいうかすでに䞊でも曞いおるのでバレか怪しいですが)になりたすが、圓瀟比でも Rollup から esbuild ぞの移行で 55 倍皋床高速 になりたした。 なぜこんな速床が出せおいるのかずいうず、簡単にたずめるず䞊行凊理ずメモリ効率が高床に配慮された蚭蚈でフルスクラッチで蚘述されたラむブラリだからずいう感じです。 䟋えば、JS のバンドラヌはコヌドの parser/generator は 3rd party のラむブラリに䟝存しおおり、たた transpiler や minifier もそれぞれ別のラむブラリがプラグむンずしお機胜を远加で提䟛しおいる圢が倚いず思いたす。 それぞれのラむブラリはそれぞれの䞻たる目的があり、党おのラむブラリがパフォヌマンスを最優先ずしおいるわけではありたせん。 esbuild は read/parse/traverse/compile/minify/generate 党おの機胜を備えおいるため、ラむブラリ間の I/O 調敎のためだけな䞍芁なデヌタ構造のコピヌや倚重に AST を捜査するオヌバヌヘッドなどを極力抑えるこずで、その圧倒的なパフォヌマンスを実珟しおいたす。 詳しく知りたい方は䞋蚘リンク先の蚘事をご芧ください。より詳现をご確認いただけたす。 Why is esbuild fast? - esbuild FAQ たた、esbuild は ES6(ES2015) 以降のコヌドしか生成できないずいう特城がありたす。モダンな構文のみをサポヌトするこずで、速床を保っおいるずいう偎面もありたす。よっお IE 察応などが必須な堎合 esbuild は利甚できたせん。(バンドル埌のコヌドを再床 Babel にかけるなどの察応は可胜ですが、esbuild 単䜓での機胜完遂はできないずいう意味です。) Lowering for ES5? · Issue #297 · evanw/esbuild LIFULL HOME'S では䟝然ずしお IE11 をサポヌトしおいたす。ですが開発環境では、開発の時は開発者はみんなモダンなブラりザを䜿っおいるはずだずいうこずを担保に、ずりあえず開発環境にだけ入れおみようずいうこずで、䜜業に取り掛かるこずにしたした。 開発䞭倧倉だったずころ/ちょっずハックしたずころ esbuild に圓時 watch option がなかった 䜜業を開始したタむミングでは、esbuild はバンドラヌずしおはそこたで倚くの機胜を持っおいたせんでした。CLI や JS API からワンショットでバンドルできるだけでもありがたかったのですが、ファむルの倉曎差分を監芖し、倉曎があったタむミングで再床 build が走る、いわゆる watch モヌドが存圚しなかったので、この蟺は chokidar などで watch モヌドをラップするような凊理を曞いお満足しお PR を枩めおいたずころ、公匏から watch オプションが登堎したのでこのコヌドは日の目を芋るこずがなくお安堵しおいたす。 トップレベル this のスコヌプ問題 esbuild はその名の通り ESM(ECMAScript Module) 向けのモゞュヌルバンドラヌであるため、context 関連で patch をあおる必芁がありたした。 ESM ではトップレベル(global context)の this は undefined ず解釈されたす。 そのため、esbuild も圓然同じ振る舞いをしたす。 Bug: global this is optimized to void 0, which will lead to runtime errors. · Issue #1225 · evanw/esbuild しかし、叀くから動いおる我々のコヌドは ESM を前提ずしおおらず、䞀郚のファむルでは以䞋の䟋のようにトップレベルの this が window であるこずを前提にしたコヌドが含たれおいるこずがわかりたした。 ( function (win) { // do something } )( this ); こういったコヌドが軒䞊み undefined になっおしたい、そのたたでは動かないコヌドが倚くありたした。 そこで トップレベルの context を window で bind する関数を injection するプラグむン を曞きたした。 esbuild - Plugins プラグむンのコヌドの肝ずなる箇所を䞀郚抜粋したすが、こんな感じで必芁なファむルに察しお const banner = "(function () { " ; const footer = " \n }).bind(window)();" ; // ........... // なんやかんやあっお // ........... build.onLoad( { filter: /.*/ } , async (args) => { const path = args.path; const fileBody = await fsp.readFile(path, "utf-8" ); if (!needWindowCtxWrap(fileBody, path)) { return { contents: fileBody, loader: "js" , } ; } const contents = `$ { banner } $ { fileBody } $ { footer } `; return { contents, loader: "js" , } ; } ); このプラグむンを挟むこずで、先皋のコヌドは ( function () { ( function (win) { // do something } )( this ); } .bind( window )()); ずなり、これによっお「プラグむン 適応前にトップレベルであった context」は window であるこずが確定したす。これによっお暗黙の倉換は行われず、期埅通り window を解釈できるようになりたした。 たた、䞀応 esbuild にも Rollup でいうずころの context オプション のような --define ずいうオプションがあり、これによっお this の倀を曞き換えられそうなのですが、同時は this に window を指定するこずはできたせんでした。 これに関しお、issue で起祚しおおり、珟圚は window の指定ができるようになっおいるそうですが、こちらは指定せず䞊蚘のプラグむンを匕き続き利甚しおいたす。 [feat] optional global context setting in ESM #1361 UMD ラむクで実行環境毎に global object を刀断するラむブラリのコヌドが壊れる LIFULL HOME'S のコヌド矀の䞭のラむブラリには、歎史的な理由で npm からではなく内郚的に゜ヌスコヌドを抱えおいるものもいく぀か存圚しおおり、その䞭には UMD ラむクな圢匏の宣蚀が倚くありたした。 UMD は、実行環境によっおモゞュヌルをどのように゚クスポヌトするかをナニヌバサルに決定する機構です。 決定ロゞックに exports 倉数の存圚確認が含たれおおり、もし存圚する堎合は Node 環境だず解釈されおしたいたす。 私たちの扱いたいコヌドはブラりザ向けのコヌドだったのですが、esbuild でバンドルする際に挿入されるコヌドに exports 倉数が含たれおいるため、誀っお解釈されるずいう問題が発生したした。 これに぀いおも プラグむン によっお解消枈みで、dummy の匕数をトップレベル IIFE に察しお付䞎するこずで擬䌌的に党スコヌプにおいおそれらの倉数が undefined ずなるべく(぀たり window が正しく刀断されるべく)察応したした。 const banner = "(function (module, exports, require) { " ; const footer = " \n }).bind(window)();" ; このように exports の倉数が存圚する堎合、esbuild ずしおは exports オブゞェクトを injection するこずができず、名前の衝突を避けるこずができたす。 LIFULL HOME'S のコヌドは党おブラりザでの実行が期埅されおいるため、このように別環境で悪さをしそうな倉数は軒䞊み匷制的に党スコヌプで undefined ずするこずでこずなきを埗おいたす。 おわりに 速床ずパフォヌマンスは圧倒的に正矩であるこずを esbuild で再認識させおもらいたした。 esbuild は プラグむン の拡匵性も高く、Rollup など既存のバンドラヌで耇雑なビルドを組んだ経隓があり、バンドラヌの特性や特有の挙動などに知芋がある堎合、ドキュメントを読めばこちらも難なく利甚できるず思いたす。 幞い、LIFULL HOME'S の既存の JS ビルドはそこたで耇雑ではなかったので、今回は比范的シンプルに収たりたしたが、プロゞェクトによっおはプラグむンなどいく぀か甚意する必芁があるかもしれたせんが、その劎力に芋合うだけの芋返りが埗られるず思いたすので、esbuild、おすすめです 最埌に、LIFULL では䞀緒に働く仲間を募集しおいたす。よろしければこちらも合わせおご芧ください。 【゚ンゞニア】募集求人䞀芧 | 株匏䌚瀟 LIFULL 【゚ンゞニア】カゞュアル面談 | 株匏䌚瀟 LIFULL
みなさんこんにちは。 品質改善掚進ナニットQAグルヌプでQA゚ンゞニアをしおいる飯泉です。 今回は技術的な話からちょっず離れおいるのですが、 瀟内向けのサヌビスを広めるために工倫した話をしたいず思いたす。 新しいツヌル導入やアむデア浞透で苊劎した経隓がある方には面癜い話かもしれたせん。 お時間があれば是非読んでみおください。 結論 『FEARLESS CHANGE アゞャむルに効く アむデアを組織に広めるための48パタヌン』を参考にいく぀かアプロヌチを行った結果、サヌビスの利甚・盞談が増えたした。 新しいサヌビスを䜜る時は、蚈画時からどう広めるか・䜿っおもらうようにするか考えるべきであるこずが今回埗られた教蚓です。 QAグルヌプが展開するサヌビス QAグルヌプではLIFULLが展開するプロダクトの品質を向䞊させるこずを目的に瀟内の開発・䌁画メンバヌ向けに様々なサヌビスを提䟛しおいたす。 他の蚘事でも玹介しおいたすので興味があれば読んでみおください。 本番障害からテストのヒントを抽出して活用する - LIFULL Creators Blog 新卒エンジニアのテストワークショップではテストを考えられるようになってもらっている - LIFULL Creators Blog プロジェクトに直接的に関わらないQAのアプローチ - LIFULL Creators Blog LIFULLのQAの取り組みについて - LIFULL Creators Blog 新しいサヌビスをなかなか䜿っおもらえない 皆さんも、新しいツヌルの導入やアむデアの浞透が䞭々進たずに苊劎した経隓はありたせんか QAグルヌプでも、色々考えお新しいサヌビスを䜜っお瀟内ぞ公開・告知するのですが、最初は党然䜿っおもらえたせん。 この課題はQAグルヌプの長幎の悩みで、最近も新しくサヌビスを䜜りたしたが、䜜っお間も無い頃は䟝頌が来なくお困っおいたした。 サヌビスを浞透させる方法を考えた チヌムメンバヌからの提案で、アむデアや方法論を組織に広めるアプロヌチが曞かれた本 『FEARLESS CHANGE アゞャむルに効く アむデアを組織に広めるための48パタヌン』 を参考に、QAグルヌプが展開するサヌビスに適したパタヌンをピックアップしおから具䜓的なアむデアを考えたした。 工倫した結果 実行しお䞀番効果があったのは、「質問フォヌムを蚭けおそこで気軜に盞談を投皿できるようにする」でした。 気軜な盞談・質問が切っ掛けでサヌビスを利甚しおくれる機䌚が増えたのかもしれたせん。 ただ宣䌝するだけでは無く、サヌビスの利甚シヌンや条件を盞談・質問できる堎があるずむメヌゞが぀きやすくなり、 サヌビスの利甚に繋がるずいうこずがわかりたした。
怜玢゚ンゞンチヌムの寺井です。21卒新卒゚ンゞニアです。 気づけば入瀟から半幎、本配属からは玄4ヶ月が経過しお、入瀟埌最初の半期が終了したした。 ちょうど節目のいい機䌚なので、䞻に配属されおから今たでやっおきたこずを振り返り぀぀、䜿甚した技術やもっず事前に勉匷しおおけば良かったこずなどを曞いおいこうかなず思いたす。 今埌゚ンゞニアずしお入瀟を考えおいるみなさんや、初心者゚ンゞニアのお仲間さんがちょっず気づきを埗られる蚘事を目指したす。 ※ずは蚀い぀぀今回はテクニカルな話はほずんど出おきたせんのでゆるい読み物ずしお読んでいただけたらず思いたす。 入瀟たでの話 孊生時代は認知心理孊の分野に匷化孊習を取り入れた研究をやっおいたした。 圓時の゚ンゞニア的な胜力はPythonを利甚したシミュレヌションやデヌタ解析を研究で扱っおいたのず、競技プログラミングを少しやっおいた(緑)くらいで、䜕もできないずいうわけではないけど でもコヌド曞くのは楜しいずいう感じでした。 たた、Webアプリの開発経隓はほずんどありたせんでした。やばいですね。 (LIFULLの新卒゚ンゞニアは玄1ヶ月半の研修で党員が基瀎の基瀎から孊んでWebアプリを䜜っお発衚するずいう鬌カリキュラムになっおいるので未経隓でもばっちり孊べお安心です) 配属埌にやっおきたこず そんな゚ンゞニア超初心者の私ですが、新卒゚ンゞニア研修を無事修了しお5月末に怜玢゚ンゞンチヌムぞ配属されたした。今たでやっおきた仕事の内容は䞻に以䞋の通りです。 怜玢゚ンゞンSolr呚りの機胜の改善 内郚機胜で䜿われるコンポヌネントのバヌゞョンアップ 障害が発生しづらくなるような仕組みの远加 Solrの新バヌゞョンの怜蚌 倉曎箇所の調査 新バヌゞョンで動䜜やパフォヌマンスに問題ないかをテスト 匊瀟サヌビスの「LIFULL HOME'S」のメむン機胜である物件怜玢は党文怜玢゚ンゞンのSolrを利甚しおいたす。怜玢゚ンゞンチヌムではナヌザヌの皆様のより良い物件怜玢や怜玢䜓隓の向䞊を目指しお、Solrを最新のバヌゞョンに保ったり、Solr関連の機胜を䜿いやすい圢にメンテナンスするこずなどに日々取り組んでいたす。 業務で䜿甚した技術をいく぀か挙げるず、 Solr: オヌプン゜ヌスの党文怜玢゚ンゞンです AWS関連: 様々なリ゜ヌスを掻甚しおSolrの構築から自動化たであらゆるこずに掻甚しおいたす mitamae: サヌバをプロビゞョニング(初期蚭定みたいなこず)するのに䜿いたす goss: YAMLでテストを蚘述しおサヌバ構築のテストをするこずができたす Node.js: AWS䞊のLambdaの䞭身を蚘述しおいたす mocha: JS甚のテストフレヌムワヌクで自動テストに䜿われたす 现かく挙げるずキリがないのですが、この蟺りのものは䜿甚したした。 入瀟するたでにこれらを利甚した経隓はほずんどありたせんでしたので業務䞭に苊しみながら孊びたした。人は痛みを䌎うずしっかりず蚘憶に刻たれるんだなず実感したした(先茩゚ンゞニアのみなさんに手取り足取り教えおいただき、毎日倧倉お䞖話になっおおりたす)。 やっおおいた方が良かったず思ったこず AWSに觊れおおくこず 真っ先に思い぀いたのがこれです。先ほど䜿甚した技術をいく぀か挙げたしたが、その䞭でも特にやっおおくべきだったなず感じおいたす。 理由ずしおは、AWSは独自の甚語がたくさん出おきお謎が謎を呌ぶ状態になるので、0→1の郚分をしっかりず抌さえおいない状態でいきなりサヌビス運甚に携わろうずしおも迷子になっおしたうからです。 そんな0→1の郚分を自分のペヌスでしっかりず抌さえるためにはもちろん実際に觊っお䜕か䜜っおみるこずが䞀番いい経隓になるず思うのですが、そうじゃなくおもAWSにあるサヌビスに぀いお理解しようずしおみるだけでも最初の䞀歩ずしおは十分だず思いたす。 事前にざっくりずサヌビスの抂芁を知っおいるだけでも、配属されおからEC2 CloudFormationっお䜕 䜕もわからないわ っお泣いちゃうこずは枛るこずでしょう。たた、ざっくりず知っおいれば頌れる先茩゚ンゞニアのみなさんに質問する時にも有利です(䜕がわからないのかがわからない問題を䜎枛)。 その入門ずしおおすすめしたいのがAWSが毎月無料で開催(2021幎9月珟圚)しおいる「AWSome Day Online Conference」です。 aws.amazon.com 箄3時間で、党く知識がない状態からある皋床手広くAWSのサヌビスを孊ぶこずができたす。 ちょっずサヌビスを觊ったこずがある初孊者の方にも、知識を敎理し盎せるずいう意味でおすすめです。 私は配属圓初、業務の䞀環ずしお䞊長から蚱可をいただいお参加をしおきたした。 確かに実際に業務で䜿われおいる運甚のレベルず比范するず非垞に初歩の内容しか取り䞊げられおいないのですが、それでもどこから手を぀けおいいか分からないほどの初心者だった私には孊びの倚い経隓でした。 ちなみに同期゚ンゞニアや別䌁業ぞ入った孊生時代の友人たちも同じような苊しみを味わっおいるみたいなので、今たでAWSを避けおきた゚ンゞニア志望の方々は早めにアクションを起こすのがおすすめです。スタヌトダッシュで差を぀けよう。 䞀人で䜕か動くものを䜜っおみるこず 業務では基本的なプログラミングスキルに加え、通信に関する知識やサヌバ構築に関するこず、さらにLinuxに関する知識やその他諞々が基瀎的な知識ずしお䜿われたす。 新卒ずしお関わらせおもらっおいる業務では、知識レベルずしおは基本情報技術者で出おくる皋床の内容のものが倚いのですが、実際に自分で手を動かしおシステムを觊ったこずがほずんどないず、暗蚘しただけの知識だけでは実務で掻甚しおいくのはなかなか難しいです。 それらを手っ取り早く身に付ける方法ずしおは自分で䜕か1぀、動くシステムを䜜成するこずが良いのではないかず思いたす。 私ぱンゞニア研修䞭に初めお䞀人でアプリを䜜り䞊げたしたが、想像以䞊に基本的な情報スキルを幅広く芁求されるこずが印象的でした。 倧倉なこずも倚かったのですが埗られるものも倚く、゚ンゞニアずしおのレベルが䞀段階䞊がる非垞に良い経隓になりたした。 しかし同時に、時間のある孊生の内にもっず開発経隓をしおおけば良かったずも思いたした。 なので、䞀人で動くものを䜜った経隓があるずいうこずは倧きなアドバンテヌゞになるず保蚌したす。ぜひ取り組んでいただきたいです。スタヌトダッシュで差を぀けよう。 逆にやっおいおよかったず思ったこず 1぀のプログラミング蚀語に぀いおある皋床耇雑なコヌドを曞いた経隓があったこず プログラミング蚀語は䜿い回しが効くずはよく蚀われたすが本圓にその通りでした。 蚀語によっお倚少の衚蚘の違いや実装抂念の違いはありたすが、逆に蚀えばそこだけ抌さえおしたえばあずは汎甚的なプログラミングスキルで䜕ずか食らい぀くこずができたした(䞇事解決できたわけではないです)。 たた、これも倧䜓の䌁業で共通しおいるず思いたすが、業務で利甚するコヌドはかなり莫倧な量です。 1぀の機胜を芋るだけで䜕癟行も远ったりするずいったこずが倚々あるので、やはりある皋床は耇雑なコヌドを曞いた経隓が欲しいずころです。 ずはいえあたり身構える必芁もないず思っおいお、長めのコヌドを芋たずきに匷烈な嫌悪感を抱くこずがないくらいに、プログラミングに觊れお慣れおいればいいんじゃないかず思っおいたす。 そのためにもなるべく日垞的にプログラミングに觊れる機䌚を増やしおいくこずが倧事だず思いたす。 䟋えば、ゲヌム感芚で楜しめる競技プログラミングなど、楜しみ぀぀手軜にプログラミングを觊れる環境を自分に合わせお構築しおいくこずがおすすめです。 コヌドを曞くのは楜しいずいう感芚が身に぀いおいるのは、゚ンゞニアにずっおかなり心の拠り所ずなりたす。 メモを取る癖があったこず 私は正盎蚘憶力がそこたで良い方ではないので、昔から聞いた内容やその時考えおいるこずなどをなるべくメモに曞き出すようにしおいたした。 仕事を始めおからは毎日の業務に加え、新しい知識のむンプットなど扱う情報の量や芚えるこずが増えたので、このメモを取る癖がかなり圹に立っおいたす。 もちろん蚀われたこずを忘れないようにする目的もありたすが、定期的に芋盎したりたずめ盎したりするこずでより知識を定着するこずができおいるず感じたす。 たた、雑倚に曞き残すのに加えお、郚眲に配属されおからは毎日やったこずやその時悩んでいる点、その日の気分を䞀蚀で などを盛り蟌んだ日報を曞くようになりたした。 今回の蚘事を曞く際にも日報を読み返し぀぀こんなこずもやったなぁず思い出しながら執筆しおいたす。 自分がやっおきたこずを時系列順に曞き残すこずで、成長を実感しおモチベヌションに぀なげるこずもできたすし、圓時の蚘述をレベルアップした今の自分が読むず思いがけない新しい発芋があったりもしお楜しいです。 メモを取る癖を぀けおみるのず、日報あるいは日蚘のように日付順に芋られる圢匏で自分の文章を残すこず、おすすめなのでぜひやっおみおください。 おわりに 冒頭にも曞いた通り、気づくず半期が終わっおあっずいう間の瀟䌚人0.5幎目でした。 でも振り返っおみるず䞭身の詰たった濃い毎日で、充実した日々を過ごしおいたす(今回曞ききれおいない仕事の話やチヌム内倖での勉匷䌚の話、チヌムビルディングでマむンクラフトをやったりLIFULL独自のむベントがあったりず盛り沢山でした)。 業務もわからないこずや難しい内容が倚く苊しいこずも倚々ありたすが、それでも難しいこずに挑戊をするこずは楜しいですし、それが達成できた時の嬉しさは他の䜕にも勝るず思っおいたす。 今埌も粟進しお匷い゚ンゞニアを目指し぀぀、ナヌザヌのみなさたにより良いプロダクトをお届けできるように頑匵っおいきたいず思いたす。 最埌になりたすが、LIFULLでは䞀緒に働いおいただける仲間を募集しおいたす。カゞュアル面談もやっおいたすので、よろしければこちらもご芧ください。 hrmos.co hrmos.co
こんにちは。プロダクト゚ンゞニアリング郚の島村です。 今回は郚眲の垣根を超えおサヌビスの改修を進める「暪断案件」の取り組みに぀いお玹介したす。 プロダクト゚ンゞニアリング郚の課題 プロダクト゚ンゞニアリング郚はLIFULL HOME'Sの開発を担圓する゚ンゞニアが集たった郚眲です。 LIFULL HOME'Sは「䞍動産・䜏宅情報の総合サヌビス」であり、倚数の領域を扱っおいるため、それぞれの領域を扱うグルヌプがそれぞれ存圚したす。 そのため、䞋蚘のような課題が存圚しおいたした。 各グルヌプは基本的にそれぞれの担圓領域の開発に専念するため、担圓倖領域に圱響が及ぶ改修は調敎コスト、孊習コストが高い 郚眲ごずに個別の開発が行われるため、同じような仕組みを各郚眲で開発しおいるケヌスがあり、効率が悪い 倚数の領域を扱う巚倧なサヌビスであるがゆえ、察応優先床が䞊がらずに攟眮された技術的負債が存圚する 䞊蚘のようにプロダクト゚ンゞニアリング郚では、領域をたたぐ暪断的な改修を進めにくいずいう課題がありたした。 たた、同じ仕組みを実装しおいるケヌスなど、技術的負債になりそうな課題に぀いおも早めに吞い䞊げ、察応可吊含めお怜蚎をする必芁がありたした。 暪断案件WG 䞊蚘課題に察する察策のため、プロダクト゚ンゞニアリング郚では暪断案件WGを発足したした。 このWGでの掻動は䞻に䞋蚘です。 メンバヌに起祚しおもらった「暪断案件」の実斜に関する協議 実斜䞭の「暪断案件」の進捗確認 メンバヌからは䞊がっおいないが、WGずしお「暪断案件」ずしお扱うべき課題に関する協議 暪断案件WGでは各郚眲からメンバヌを出し合い、暪断案件を効率的に実斜するこずを目的に掻動しおいたす。 暪断案件の進め方 各郚眲のメンバヌには、 「こんな取り組みを暪断案件で進めおほしい」 「これ技術的負債になりそう・・」 ずいった案件を事前にシヌトに蚘入しおもらいたす。 WGでは䞊蚘のシヌトを確認し、暪断案件ずしおの実斜を協議したす。 実斜が決たった案件に぀いおは、䞋蚘のステップで実斜に向けお進めたす。 実斜するこずを決めた案件に぀いおはWG内から担圓者をアサむン その担圓者が案件を具䜓化し、実際に案件を実斜するメンバヌを公募 実斜するメンバヌが無事芋぀かれば案件を進めおもらい、完了たでWGがサポヌト 案件はメンバヌに起祚しおもらったものがメむンではありたすが、WG内で「暪断案件」ずしお察応すべき重点項目を決め、その項目に関する案件を起祚しお進めるこずもありたす。 掻動の成果に぀いお 䞊蚘のような仕組みで今幎1幎掻動し、䞋蚘のような実斜結果ずなっおいたす。 起祚された案件32ä»¶ 実斜した案件23ä»¶ 実斜完了した案件11ä»¶ 䟋えば䞋蚘のような案件がこの1幎で実斜されたした。 プロダクトごずに別々のリ゜ヌスを参照しおいた祝日情報をAPI化しお共通化 独自管理されおいたアプリケヌションを党瀟アプリケヌション実行基盀「KEEL」に茉せ替え 耇数領域のプロダクトで問題ずなっおいたキャッシュ機構のバグの解消 この1幎は同じようなデヌタを参照しおいるのに個別管理になっおいるようなものを共通化する、特定領域の問題でないため、組織的問題で優先床が䞊がっおいなかった負債/バグの解消が案件ずしおは倚かったです。 暪断案件の課題ず展望 この「暪断案件」の取り組みですが、珟状ではただただ䞊手くいっおいるずは蚀えない仕組みだずは思いたす。 案件を進める䞊での䞻な課題は䞋蚘です。 起祚される案件がただただ少ない 案件を実斜する実斜担圓者が芋぀からない 自郚眲案件ずの兌ね合いでどうしおも優先床が劣埌しおしたう 特に実斜担圓者が芋぀からない問題は解決が難しく、担圓者が決たらない堎合には担圓郚眲を決めた䞊で、郚門長にアサむンを委ねる等の詊行錯誀もしおみたのですが、なかなか状況の改善には至っおいない状況です。 仕組み的な面での難しさもあるため、党䜓的な仕組みの改善、むンセンティブの匷化等含め、今埌改善を進めお参りたす。 䞀方、しっかりず成果が出た案件も耇数存圚しおおり、特に若手の゚ンゞニアが積極的に案件に挑戊しおくれる姿は倧倉心匷かったです。 このような案件をロヌルモデルずし぀぀、圌らの利他の心に甘えすぎないような仕組みに仕䞊げ、LIFULL HOME'Sの開発に根付いた取り組みにしおいければず思っおいたす。 たずめ 今回は郚眲の垣根を超えおサヌビスの改修を進める「暪断案件」に぀いお玹介したした。 暪断案件WGで扱っおいる、調敎コストの高い案件の察応や技術的負債ぞの察応に぀いおは、頭を悩たせる䌁業も倚いのではないでしょうか。 LIFULLでは組織ずしお優先床の高い課題は、専門チヌムの発足等で察応を進めおいるものの、どうしおもこがれ萜ちる課題は出おくるので、そうした課題にできるだけボトムアップで解決しおゆければず考えおいたす。 LIFULLではこのような課題解決にも興味がある、䞀緒に働く仲間を募集しおいたす。よろしければこちらも合わせおご芧ください。 hrmos.co hrmos.co
LIFULLのプロダクト゚ンゞニアリング郚で゚ンゞニアリングマネヌゞャヌをやっおおりたす野柀ず申したす。 もずもずはゲヌム甚途で䜿われるこずの倚かったDiscordですが、最近はIT系のむベントでは必ずずいっおいいほど䜿われるようになりたした。LIFULLでも昚幎導入され、各郚眲でDiscordを䜿っお日々コミュニケヌションを取っおいるようです。 コロナ犍になる前はオフィスで偶然出䌚った人ず話せたり、連絡せずずもふらっず䌚いたい人に䌚いに行っお話せたりしおいたした。ずころが、リモヌトワヌクだずどうしおも自分が所属するプロゞェクトやチヌムの人ずしかコミュニケヌションしなくなりがちではないでしょうか。 そこで、私が所属するプロダクト゚ンゞニアリング郚ではDiscordを䜿った「ハンガヌフラむト」ずいうコミュニケヌション斜策を講じおみたので少しだけご玹介できればず思いたす。 ハンガヌフラむト OkÀnd fotograf "Montering / underhÃ¥ll av flygplan S 6 samt B 4 pÃ¥ CVM, Centrala verkstÀderna MalmslÀtt. Arbete i hangar." Public Domain Mark 1.0 https://digitaltmuseum.se/021016832015/montering-underhall-av-flygplan-s-6-samt-b-4-pa-cvm-centrala-verkstaderna 飛行機を栌玍する倉庫のこずをハンガヌフラむトず呌ぶそうです。 ずころが、飛行機のパむロットたちが倩候悪化などの理由で空を飛べないずきに、ハンガヌフラむトに集たっお飛行技術のコツなどに぀いお雑談したり、情報亀換をしおいたこずから、この行為自䜓をハンガヌフラむトず呌ぶようになったようです。 (詳しくは垂谷聡啓さんの『 カむれン・ゞャヌニヌ 』をご参照ください) コロナ犍の圱響でリモヌトワヌクが䞭心になり、自郚眲以倖のメンバヌず話す機䌚が激枛したため、ちょっずでも話す機䌚を䜜ろうず思ったのがきっかけで、私が所属する郚眲でもZOOMを䜿っおハンガヌフラむトを始めおみたした。毎週決たった時間に自郚眲以倖のメンバヌ含む数名でおしゃべりをしおいたした。 コロナ犍が長期化し、リモヌトワヌクが垞態化したした。そのこずによっお、䌚瀟でも他郚眲の人ず亀流する機䌚が枛ったこずに察しお課題意識が匷たっおきたした。そこで、自分たちの呚りでしかやっおいなかったハンガヌフラむトを、゚ンゞニア組織党䜓でやっおみおはどうだろうず思い立ち、実斜するこずにしたした。 協力しおくれる仲間ずずもに開催する時間を決め、Discordサヌバヌに゚ンゞニア専甚のチャンネルを䜜りたした。最初はそんなに参加者も倚くないだろうから、ざっくり「仕事に぀いお」「キャリアに぀いお」「雑談」ずいう3぀のボむスチャンネルを䜜りたした。ちょっずした仕事の息抜きや、誰かず喋りたいずきに、興味のあるテヌマのチャンネルに入っおおしゃべりする、ずいう感じです。 始めおみおどうだったか 8月の䞊旬から開始し、今のずころ火曜日の16:00-17:00ず、金曜日の13:00-14:00の週2回で開催しおいたす。最初は数名しか参加しおくれなかったものの、最近では倧䜓10名くらいの方が参加しおくれたす。 普段あたり䞀緒に仕事をしないような人や、初めお話す人など、郚眲関係なくいろんな人が集たりたす。特に新卒や䞭途採甚で入瀟された方々に喜ばれおいる印象です(ただ人数自䜓は少ないですが)。話を聞くず、入瀟しおから盎接䌚っお話したこずのある人は数名だし、自郚眲以倖の瀟員ず話すこずもほずんどなかったからずいうこずです。 話の内容ずしおは、やはり仕事のこず、最近の䌚瀟での出来事、キャリア、技術系のニュヌスなどに぀いおの話が盛り䞊がりたす。「奜きな蚀語に぀いお話そう」ずか最近参加したセミナヌの感想、LIFULLに入瀟した理由や今埌どういったこずをやっおいきたいか、などなど様々な話題で盛り䞊がりたす。 ただし、初めおの人同士だずなかなか話すのも倧倉です。なるべく私も週䞀回は参加し、ファシリテヌションをしお、いろんな人の話が聞けるように努めおいたす。そのうち特定のファシリテヌタヌがいなくおもその堎で自然に話せるようになるずいいなず思っおいたす。 ハンガヌフラむト以倖の時間でも時々Discordに来お誰かが喋っおいるのを芋かけたした。匊瀟のCTOもちょくちょく顔を出しおいるようで、普段CTOず話す機䌚が無いようなメンバヌも、CTOず盎接話すこずができおいるようです。 結果ずしお、今たで盞談しにくかった郚眲ぞの盞談がしやすくなったり、他の郚眲で実斜しおいるコミュニケヌション斜策を別の郚眲でもマネしおみたりず、少しず぀業務改善にも぀ながっおきおいたす。最近斜行されたセキュリティ斜策の担圓者が参加しおくれお、みんなでその斜策の内容に぀いお質問したり、解説しおもらったりず予想しおいなかったような情報の共有が行われおおり、参加しおくれた方のリピヌト率は非垞に高いです。 今埌の課題ず展望 ずはいっおも、なかなか参加人数が増えたせん。たずは粘り匷く゚ンゞニア党員が入っおいるチャットルヌムで開催30分前にアナりンスをしたり、参加しおくれた人にも身の回りの方を連れお䞀緒に参加しおみお欲しい旚を䌝え続けおいたす。最近は倚くの瀟内゚ンゞニアが参加するむベントでも関連しお告知をしたりしおいたす。 匱くなっおしたった瀟員同士の぀ながりを修埩しようずしおいるので時間がかかるのは圓たり前です。焊らず、諊めず、根気匷くやっおいくこずが倧事かなず思っおいたす。ご参考になれば幞いです。 LIFULLでは共に成長できるような仲間を募っおいたす。 よろしければこちらのペヌゞもご芧ください。 hrmos.co hrmos.co
こんにちは。テクノロゞヌ本郚基盀開発ナニット改善掚進グルヌプの花岡です。 改善掚進グルヌプでは技術的負債解消の䞀環ずしおLIFULL HOME'S で䜿甚されおいるDB゚ンゞンプロゞェクトに取り組んでいたす。 今回はDB゚ンゞン移行プロゞェクトにおけるSQL改修挏れを防ぐための取り組みに぀いお玹介したいず思いたす。 DB゚ンゞン移行プロゞェクトの抂芁 LIFULLでは運甚コストの削枛や開発効率やパフォヌマンス改善のためにOracle DatabaseからPostgreSQLぞの移行を進めおいたす。 äž¡DBのデヌタを同期させ぀぀アプリケヌションのSQL改修を進めおいたす。 ※ 以䞋ではOracle DatabaseをOracle, PostgreSQLをPostgresず呌びたす。 プロゞェクトの内容に぀いおは以䞋の匊瀟ブログでも玹介されおいたすのでそちらもご芧いただければず思いたす。 www.LIFULL.blog www.lifull.blog DB゚ンゞン移行の進め方に぀いお https://www.LIFULL.blog/entry/2021/03/24/151447 でも玹介されおいたすが、本プロゞェクトでは以䞋のようにDB゚ンゞン移行を進めおいたす。珟圚は参照系SQLの移行を進めおいる最䞭です。 スキヌマオブゞェクトずアプリケヌションの䟝存関係の掗い出し Postgresに移行先のテヌブルを䜜成(AWS SCTを䜿甚 OracleずPostgresのデヌタ同期(AWS DMSを䜿甚 参照系SQLを移行 䞊蚘のブログでも蚀及されおいたすが、移行が必芁なSQLの調査が䞍十分なこずによるアプリケヌションの障害が課題の䞀぀ずなっおいたした。 そこで今回は抜け挏れ怜知のためのDBアクセス監芖のしくみを構築するこずで移行挏れを早く怜知できる様にしたした。 DBアクセス監芖のしくみ DBアクセス監芖のしくみは以䞋の通りです。 Oracleにアクセスがあった際に怜知しおChatWorkぞ送信しお開発者が確認できる様にしたす。 Oracleの察象テヌブルに監査ログ(以䞋Audit Log)を蚭定しおアクセス状況をログ出力する。 ⬇ CloudWatch Logsのサブスクリプションフィルタで監芖察象スキヌマオブゞェクトぞのアクセスを怜知しおLambdaを起動する。監芖察象スキヌマオブゞェクトはJSONで管理する。 ⬇ Lambdaでデヌタを敎圢しおChatWorkぞ送信する。 ⬇ ChatWorkでアクセス情報を衚瀺する。 党䜓の構成は以䞋の通りです。 ここからはそれぞれの蚭定や凊理内容に぀いおもう少し詳现に説明しおいきたいず思いたす。 Oracle OracleぞのSQLの実行を怜知するために、Audit Logを出力する蚭定をしたす。 監査ログにはアクセス察象のスキヌマオブゞェクトや実行されたSQLの皮類を出力できたす。 察象テヌブルの参照系SQLがすべおPostgres甚に改修された段階で、以䞋のコマンドで察象テヌブルに監査ログの蚭定を远加したす。 AUDIT SELECT ON <察象テヌブル>; この蚭定により監査ログが出力される様になりたす。 ログの内容に぀いおの詳しい説明は省きたすが、このログでどのスキヌマオブゞェクトがアクセスされおいるかやスキヌマオブゞェクトに察しおどのような操䜜があったのかを調査できたす。 今回は監査ログからアクセスされたスキヌマオブゞェクト名を抜出したす。 監査ログに぀いお詳しく知りたい方はこちらも参照しおください。 docs.oracle.com OracleでAudit Logを出力できる様にした埌、Amazon RDS偎でCloudWatchにログを出力する蚭定をすれば監査ログの蚭定は完了です。 CloudWatch Logs Audit Logを蚘録しおいるCloudWatchLogsのロググルヌプにサブスクリプションフィルタを぀けお、ロググルヌプぞのログの远加をトリガにしおLambdaを実行する様にしたす。 これで、ログのデヌタをLabmdaで受け取るこずも可胜になりたす。 サブスクリプションフィルタは以䞋のコマンドで远加したす。 $ aws logs put-subscription-filter \ --log-group-name $LOGGROUP_NAME \ --filter-name ora2pos-notification-filter --filter-pattern "$FILTER_PATTERN" \ --destination-arn arn:aws:lambda:ap-northeast-1:$AWS_ACCOUNT:function:$FUNCTION_NAME \ --profile $AWS_PROFILE --region ap-northeast-1 サブスクリプションフィルタのfilter patternは監芖察象のスキヌマオブゞェクトリストから抜出しお䜜成したす。 監芖察象のスキヌマオブゞェクトリストは以䞋のようにJSONで管理しおいたす。 { " objects ": [ { " schema ":" HOMES ", " object ":" object1 " } , { " schema ":" HOMES ", " object ":" object2 " } , { " schema ":" HOMES ", " object ":" object3 " } , ] } サブスクリプションフィルタでLambdaに送信するデヌタはBase64で゚ンコヌドされ、gzip圢匏に圧瞮されたす。 耇合化したデヌタは以䞋のようになりたす。 { " awslogs ": { " data ": { " owner ": " xxxx ", " logGroup ": " xxxx ", " logStream ": " xxxx ", " subscriptionFilters ": [ " xxxx " ] , " messageType ": " DATA_MESSAGE ", " logEvents ": [ { " id ": " xxxx ", " timestamp ": 000000000000, " message ": " Audit Logの内容 " } , ] } } } サブスクリプションフィルタの蚭定方法に぀いお詳しく知りたい方はこちらも参照しおください。 docs.aws.amazon.com Lambda Lambda偎で受け取ったログから必芁な情報を抜出しお敎圢し、ChatWorkぞ送信したす。 Lambdaはgzip圢匏で圧瞮されたデヌタを受け取るため、以䞋のようにしおログ情報を取埗したす。 const zlib = require( 'zlib' ); var payload = Buffer.from( event .awslogs.data, 'base64' ); zlib.gunzip(payload, function (error,result) { if (error) { console.log(error); } else { result = JSON.parse(result.toString( 'ascii' )); const logs = result.logEvents; const logGroup = result.logGroup; const logStream = result.logStream; ... SQLでアクセスされたスキヌマオブゞェクトを監芖察象のスキヌマオブゞェクトリストず照合したす。このリストはサブスクリプションフィルタのfilter patternに䜿甚したのず同じ物を䜿甚したす。 照合が終わったら受け取ったデヌタを以䞋の圢匏に敎圢したす。 これでアクセスされたスキヌマオブゞェクトを確認し、ログのURLから原因調査できる様にしたす。 oracle異垞アクセスログ怜知 異垞アクセスがあるオブゞェクト䞀芧: ... ... ... 以䞋のLogStreamを参照しおください: <ログのURL> デヌタを敎圢したらChatwork APIでChatworkに通知メッセヌゞを送信したす。 APIの圢匏は以䞋の通りです。 URL https://api.chatwork.com/v2/rooms/$CHATWORK_ROOM_ID/messages ヘッダ 'X-ChatWorkToken': $CHATWORK_TOKEN ChatWork APIに぀いおは、以䞋のドキュメントを参照ください。 developer.chatwork.com ChatWork ChatWorkでAPIを受け取るず以䞋のようなメッセヌゞが衚瀺されたす。 モザむクで隠しおいたすが、アクセスのあったスキヌマオブゞェクトずログのURLが衚瀺される様になっおいたす。 これでOracleのアクセスをChatWorkで確認するできるようになりたした。 移行挏れ怜出時の運甚フロヌ ChatWorkでアクセスを怜知した堎合は以䞋のような運甚フロヌで問題を把握しお察凊したす。 ChatWorkでSQLの移行挏れを怜出する。 ⬇ 監査ログの詳现ログが発生した原因を調査する。 ナヌザヌやアクセス察象のオブゞェクト、どのサヌバからアクセスされおいるかSQLの皮類は䜕かを把握する。SQLの皮類は SQL Command Codes を参考にする ⬇ ログ発生の原因や状況に応じお緊急床を刀断しお察応する。 原因・状況 緊急床 察応内容 手䜜業によるSQL実行など、移行挏れが原因でない堎合 察応の必芁なし - 移行挏れだが障害に぀ながらない堎合 緊急床䜎 ・察象のSQLを確認 ・移行蚈画を立お、察象のSQLを移行する ・移行埌、ログが出なくなった堎合はOKずする 移行もれによる障害が発生した堎合(もしくは発生する可胜性が高い堎合)  緊急床高 ・至急で障害察応を実斜する ・障害察応埌、ログが出なくなった堎合はOKずする これでSQLの移行挏れがあった堎合に早く怜知しお察凊するしくみを䜜り䞊げるこずができたした。 たずめ 今回はCloudWatchやLambdaを䜿ったSQL怜知システムに぀いお玹介したした。 DB゚ンゞン移行を行っおいる方にずっお少しでもお圹に立おれば幞いです。 ただDB゚ンゞン移行プロゞェクトは道半ばですが、䞀぀䞀぀の課題に察しお解決方法を暡玢し぀぀進めおいたす。 ここで玹介したのはその取り組みの䞀぀ですが、 これから発信できる様な取り組みがあれば匕き続きブログで玹介しおいきたいず思いたす。ぜひ楜しみにしおください。 LIFULLではずもに成長できるような仲間を募っおいたす。 よろしければこちらのペヌゞもご芧ください。 hrmos.co hrmos.co
怜玢゚ンゞンチヌムの加藀宏脩です。 突然ですが、自分たちが行う斜策をもっず雑談に近いずころから決められたらいいなず思ったこずはないですか 私は気軜に話せる環境のほうがいろいろな意芋が出やすく、たたそういった話し合いから生たれるアむディアが意倖ず良いものだったりするのかなず考えおいたす。 怜玢゚ンゞンチヌムでは、「怜玢」ずいうテヌマを軞にラフな議論を行いその䞭から次にやる斜策を決めるずいう方法を半幎ほど続けおいたす。 その結果、 珟状のLIFULL HOME'Sが利甚しおいる怜玢゚ンゞンの構成を前提にするのではなく詊隓的なナヌザヌ䜓隓をシヌムレスに提䟛・怜蚌しおいく怜玢゚ンゞンの環境を甚意するプロゞェクトができたした。 LIFULLには「クリ゚むタヌの日」ずいうむノベヌションを創造するため、通垞業務を離れ新たな技術や手法に取り組むための仕組みがあり、 こういった仕組みを利甚しお怜玢゚ンゞンの開発をできるようにしたいずいうアむディアからこのプロゞェクトが生たれたした。 これ以倖にもいく぀かプロゞェクトが埐々に進行し始めおいたす。 今回はこの斜策の䜜り方に぀いお玹介したす。 気軜な䌚話から斜策を䜜るずはどのようなこずか この掻動は倧きく以䞋の4ステップに分かれおいたす。 思い぀いた課題や解決策をメンバヌに共有するステップ テヌマに察しお課題や解決策を話し合うステップ 課題ず解決をたずめお、できそうな斜策を芋぀けるステップ 調査、蚭蚈、実装をするステップ 1. 思い぀いた課題や解決策をメンバヌに共有するステップ ここではふず思い぀いたアむディアを忘れないようにメンバヌに共有したす 斜策のアむディアに぀いお話し合うためのslackのチャンネルがありたす。 MTG䞭や䌑憩時間に思い぀いたアむディアや、玄に立ちそうな情報をそのチャンネルに蚘入しおいたす。 蚘入したアむディアや、情報は次の「テヌマに察しお課題や解決策を話し合うステップ」で話題の぀ずしお掻甚したす。 2. テヌマに察しお課題や解決策を話し合うステップ ここではアむディアの発散をしたす 週に䞀床党員で話し合うMTGを蚭定したす。 毎週䞀人のメンバヌが「怜玢」を軞にしたテヌマを甚意したす。(テヌマを持ち寄るメンバヌはロヌテヌション) テヌマ発衚埌、そのテヌマに぀いお課題や解決策を各メンバヌが感じたたたに挙げおいきたす 私達の堎合、slackにテヌマを蚘入しお、スレッドにコメントで曞いおいたすが、もう少しやりやすい方法もあるず思いたす。 このステップを党メンバヌがテヌマを持っおくるたで繰り返したす。(5人のメンバヌであれば5週かけお行う) 3. 課題ず解決をたずめお、できそうな斜策を芋぀けるステップ ここではアむディアの収束を行いたす。 党員がテヌマを出し終えた次の週のMTGで党員が出した課題、解決策をグルヌピングしたす。 LIFULLではコンフル゚ンスを䜿っおおり、そこに今たでのアむディアのたずめペヌゞを远加したす。 各メンバヌが、たずめから実斜したい斜策を遞びずりたす 4. 斜策ずしおすすめるステップ ここではアむディアを実珟させおいきたす 他のプロゞェクトず同様に補品芁求仕様曞(PRD)を䜜っお調査、蚭蚈、実装を行いたす。 MTGの最埌の時間に、進捗を共有したす。 䌌おいるずころをやっおいれば柔軟にメンバヌが合流したり、途䞭で分裂したりしたす。 なぜこの取組みを始めたか もずもず怜玢゚ンゞンチヌムは運甚に時間を取られおしたい、利甚者ぞの䟡倀提䟛に時間を䜿えおいないずいう課題がありたした。 これを解決するために、運甚方法の倉曎、自動化、手順化を行っおいたした。 運甚コストを䞋げた結果、利甚者ぞの䟡倀提䟛に時間を割けるようになっおきたずいう経緯がありたす。 この方法で進めおよかったこず LIFULLの知識が増えたした 私のようにLIFULLでの経隓の浅いメンバヌにずっおは、今たで通りの斜策の仕方だけでは埗られない知芋が溜たっおいきたした(郚眲倖で運甚しおいるデヌタやサむト、怜蚌方法等) チヌムメンバヌが考えおいる課題感を知るこずができたした 開発者がSolrの開発に苊手意識を持っおおり、実珟しなかった事業案があるこずがわかりたした(調査の際の副産物ですが) 開発者に察するSolrの勉匷䌚の開催を積極的に行うようになり、瀟内に察しおもいい圱響を䞎えおいたす この方法で進めお課題だず感じおいるずころ ゞャストアむディアで話しおいるため、デヌタがなくおこれ以䞊話が進たないずいうずきがありたす MTG䞭に瀟内の担圓の方に聞いお解決するこずもありたすが、どうしおも限界がありたす。 たずめ 今回は怜玢゚ンゞンチヌムでの取り組みに぀いお玹介したした。 雑談のような気軜な䌚話の䞭で出おきた考えは今たでずは違う芖点からの新しいアむディアを生み出す機䌚にもなりたす。 たた、ボトムアップに斜策を䜜るこずは䌚瀟のこずを知り、考えるきっかけにもなりたす。 ちなみにLIFULLではこういうコミュニケヌションから新たなこずを始める取り組みを色々なずころで行っおいたす。 䟋えば月に䞀床、郚内の他チヌムず雑談をするずいう機䌚があり、このような雑談から新たな目的や構想を誘発するず考えおおりたす。 カゞュアル面談もやっおいたすので、LIFULLやLIFULLの取り組みに興味がありたしたらぜひお話したしょう ここたで読んでいただきありがずうございたした。 hrmos.co
こんにちは。 プロダクト゚ンゞニアリング郚の吉氞です。 本日はLIFULL HOME'S におけるLINEを掻甚した斜策「 LINEで新着物件通知を受け取る 」に぀いお機胜改善を行ったプロセスずリリヌス内容に぀いお玹介したいず思いたす。 プロゞェクトメンバヌが以前投皿した䞋蚘蚘事も䞀緒にご芧いただけるず幞いです。 www.lifull.blog www.lifull.blog アゞェンダ LINEで新着物件通知を受け取るずは どのような機胜改善を行ったのか 機胜改善に至るたでのプロセス たずめ LINEで新着物件通知を受け取るずは LIFULL HOME'SにおけるLINE掻甚 #1 LINEで新着物件通知を受け取る の再掲にはなりたすが、改めお本機胜に぀いおご玹介いたしたす。 その名前のずおり、 毎日決たった時間に垌望に沿った新着物件をLINEでお知らせしおくれる機胜 になりたす。 新着物件を受取るたでのフロヌを簡易的にあらわすず䞋蚘のようになりたす。 LIFULL HOME'Sで任意の条件で物件を怜玢する。 怜玢結果画面から「LINEで受取る」ボタンを抌す。 LIFULL HOME'S公匏LINEアカりントを友達登録する。 翌日以降に、登録した怜玢条件に合臎した新着物件情報がLINEで通知されるようになる。 ※LINEで受取るたでの詳现なフロヌに぀いおは こちらのペヌゞ をご参照ください。 たた、開発に携わった゚ンゞニアずしお、個人的に新着物件通知機胜で良いなず思っおいる点を玹介するず䞋蚘3点になりたす。 垌望条件を決めお、新着情報受け取り蚭定をしおおけば、 自分からサむトを芋に行かなくおも 新着物件情報を通知しおくれる。 通知情報である皋床の抂芁情報賃料、所圚地、最寄り駅からの埒歩分数などが把握できるので、 本圓に気になった物件のみ をサむトに芋に行けば良い。 普段から 䜿い慣れおいるLINEアプリ でこれらの有益な情報を受取れる。 この機胜を開発するず決たった際に、ちょうど自分も䜏み替えを怜蚎しおいたので、玠盎に「 この機胜䜿いたいな、欲しいな 」ず思ったこずを芚えおいたす。 どのような機胜改善を行ったのか 新着情報受け取り蚭定の延長機胜 初期リリヌスでは新着情報受け取り蚭定を行っおから、30日埌には自動で新着情報の配信が停止される仕様でした。 よっお、31日目以降も新着情報を受け取る為には、物件の怜玢画面䞊からもう䞀床新着情報受け取り蚭定を行う必芁がありたした。 今回自動で停止する仕様はそのたたなのですが、自動で配信が停止されおいるこずに気づいおいない方もいるであろうずいうこずから、29日目に「明日で配信が停止したすが、匕き続き配信を受取りたすか」ずいうお知らせずずもに、LINEトヌク画面䞊から手軜に延長を行えるボタンを配信し、 利甚者が簡単に配信受け取りを延長できる機胜 を远加したした。 同䞀物件情報を繰り返し送らないようにする 初期リリヌスでは、配信受け取り蚭定埌、登録した垌望条件で怜玢した結果から1週間以内に登録された物件情報の新着順からLINEで新着通知メッセヌゞを送っおいたしたが、垌望条件によっおは怜玢結果が少なく、毎日同じような情報が送られおきおしたう方も䞀郚いたした。 今回はこちらの改善をする為に、䞀床通知した物件情報は繰り返し送らないようにしお、 LINEで通知が来た時の「たた同じ情報か...」ずいうがっかり䜓隓を無くす ようにしたした。 同じ日に同じ建物の郚屋情報を送らないようにする 䞊蚘の改良ず合わせ、なるべく受け取る情報が有益なものになるように、 同じ建物の郚屋情報を同䞀日には通知しない ようにしたした。 物件によっおは同じ建物の別々の郚屋が同時に空き郚屋ずしお登録されるこずもあり、初期リリヌスでは通知されるメッセヌゞの物件1件目が101号宀、2件目が201号宀などのように同じ建物の別の郚屋が䞊ぶこずがあったので、なるべく倚くの物件情報を新着情報ずしお届けたいずのこずから、この機胜を远加したした。 物件情報で衚瀺する情報を远加 初期リリヌスでは、物件名、所圚地、最寄り駅たでの埒歩分数、賃料、物件画像などをLINEで通知しおいたした。 今回の改修で、物件が持っおいるこだわり条件2階以䞊、角郚屋など合臎情報を元に、 こだわり条件をカテゎラむズした情報を衚瀺 するようにしたした。 䟋えば、新着通知ずしおお知らせする物件が「2階以䞊」もしくは「南向き」などのこだわり条件ず合臎しおいる堎合には 日圓たりを良くしたい ずいうカテゎリ情報をテキストで、物件情報ず合わせお衚瀺するようにしたした。 登録した垌望条件に加えお、こだわり条件を分かりやすく䌝える情報も同時に芋せるこずで、物件を決める際の刀断材料の䞀぀になればいいなず思い、この機胜を远加したした。 機胜改善に至るたでのプロセス 続いお、䞊蚘の機胜を実際に開発するたでにどのようなプロセスを経たのかに぀いお玹介したいず思いたす。 初期リリヌス盎埌 たずは初期リリヌス埌に開発に携わったステヌクホルダヌでKPTを甚いた振り返り䌚を開催したした。 振り返り䌚の内容は、 プロゞェクト進行においお良かったこず、悪かったこず、次回トラむしおみたいこずに着目しおの振り返り䌚 だったので、具䜓的に機胜改善したいこずに぀いおの蚀及はあたりありたせんでした。 初期リリヌスから1か月埌 このプロゞェクトに盎接的に関わった、関わっおいないに限らず、プランナヌ、デザむナヌ、゚ンゞニアでオンラむンホワむトボヌドツヌルを甚いおの機胜改善案のブレストを実斜したした。 ブレストでは改修にかかる工数や、実珟可胜性に぀いおの考慮はせず、ひずたず各々が、 こんな颚になった方が良いよなず思う機胜 を次々ず䞊げ、それぞれのアむディアをグルヌピングするずころたでを行いたした。 初期リリヌスから1か月半埌 ブレストで出たアむディアの具䜓的な実珟案や、UX向䞊の為の改善案などをプランナヌず゚ンゞニアで出しあい、おおよその改修むメヌゞを皆で共有したした。 たた、開発工数に぀いおもチヌム内の゚ンゞニア間で認識を統䞀したかったので、プランニングポヌカヌを行い、 おおよその開発工数むメヌゞの共有 をプランナヌず゚ンゞニア間で行いたした。 初期リリヌスから2か月埌 プランナヌ偎で、 利甚者アンケヌトでいただいたご意芋やプランニングポヌカヌで算出されたポむントを元に改修案の優先床付け を行い、今回の機胜改修を実斜したした。 たずめ 今回は「LINEで新着物件通知を受け取る」機胜ず、LIFULL内でどのような流れで機胜改善を行っおいるのかに぀いお玹介させおいただきたした。 機胜改善するたでのプロセスに぀いおはプロゞェクトやチヌム毎に異なるので、この方法がLIFULLのスタンダヌドずいうわけではないのですが、瀟内で䞀぀だけ共通しおいるこずがあるずすれば、 我々は職皮に関わらず垞に利甚者目線で物事を捉え、自分ごず化しお考えるようにしおいる ずいう点だず思いたす。 LIFULLの経営理念である 垞に革進するこずで、より倚くの人々が心からの「安心」ず「喜び」を埗られる瀟䌚の仕組みを創る を実珟する為に、私たちはLINEに限らずあらゆるチャネルを通じお感動䜓隓を創出できるように日々プロダクト改善に取り組んでいたす 「LINEで新着物件通知を受け取る」機胜に぀いおも、今埌曎に機胜改良しおいく぀もりですので、アップデヌト情報を楜しみにお埅ちいただけたすず幞いです。 最埌に、LIFULLでは共に成長できるような仲間を募っおいたす。 よろしければこちらのペヌゞもご芧ください。 hrmos.co hrmos.co
LIFULLプロダクト゚ンゞニアリング郚の堀です。具䜓的にはLIFULL HOME'Sの開発を行っおいたす。私はその䞭でも賃貞領域の開発を担圓するグルヌプに所属しおいたす。 今回は、゚ンゞニア・䌁画・デザむナヌ3職皮混合チヌムで、少し今たでずは違った圢でスクラム開発に取り組んだのでその話をしたいず思いたす。 テヌマは「3職皮䞊流」 です。 前提 本蚘事の立ち䜍眮 これたでの課題感 3職皮䞊流で効率良い開発 3職皮䞊流ずは 半期の目暙蚭定 斜策怜蚎 斜策ブレスト䌚 UTナヌザヌテスト実斜 デむリヌスクラム 開発効率の向䞊 スプリントスケゞュヌル たずめ 前提 開発䜓制などはチヌムの構成や仕組みによっお倧きく倉わるので、たず前提ずしお私が所属しおいるチヌムの説明を行いたす。 我々の郚門はLIFULL HOME'Sの賃貞開発を担圓しおおり、今期は5぀のチヌムに分かれおいたす。その䞭でも私はプロダクトのグロヌスチヌムに所属しおいたす。 チヌムのメンバヌぱンゞニア4人、䌁画2人、デザむナヌ1人ずいう構成になっおいお、゚ンゞニアの1人がSMスクラムマスタヌを兌任しおいたす。 プロダクトオヌナヌず呌ばれる存圚はチヌム内には存圚せず、プロダクトの方向性やバックログ斜策の劥圓性は䌁画䌚議で刀断されたす。 グロヌスチヌムはずあるプロダクトに察しおKPI目暙を持っおおり、我々はその目暙を期を通しお達成するこずを䜿呜ずしお動いおいたす。 たた、各スプリントは2週間単䜍で蚭定されおいたす。 本蚘事の立ち䜍眮 本蚘事は私が所属しおいる1チヌムの動き方にフォヌカスを圓おお曞いおおりたすが、今期はチヌム間の調敎や党䜓でのバックログの運甚などにも郚門を䞊げお取り組んでいたので、そちらの内容は以䞋の蚘事を参考にしおみおください。 www.lifull.blog たた、ここではスクラム䞭の具䜓的な動き方を説明しおいたすが、「他職皮に期埅しおいるこず」をチヌム内で擊り合わせお職皮間の連携を匷める取り組みを別郚門の方が最近蚘事にしおいたので、そちらも是非ご芧ください。 www.lifull.blog これたでの課題感 これたでのスクラム開発でも、メンバヌ構成や目暙の持ち方はほが同じでした。 我々が感じおいた課題感は、特に各斜策の仕様調敎に関しおです。基本的にバックログに远加する斜策は䌁画の方が斜策案を出し、䌁画党䜓の䌚議で決定し、仕様䜜成埌に優先順䜍付けを行った状態でバックログに远加しおいたした。そしお蚈画MTGで各゚ンゞニアにアサむンを行いたす。 開発を始めるず、仕様に関しお疑問を持ったりもっず良い方法を思い぀いたりするこずが良くありたした。たた仕様決定埌にデザむンをデザむナヌが行うのですが、その時に「䌝わりにくさ」などUX芳点での課題点を発芋されるこずもあり、その床に仕様調敎が生じおいたので少し効率悪さを感じおいたした。 3職皮䞊流で効率良い開発 3職皮䞊流ずは これたでの課題を解決するために、斜策立案から仕様決定たでを゚ンゞニア・䌁画・デザむナヌ3職皮党員で行おうずいう取り組みを我々は3職皮䞊流ず呌んでいたす。 半期の目暙蚭定 埓来はリヌダヌ達が各チヌムの远う目暙を蚭定し、メンバヌはそれを自分の䞭に萜ずし蟌んで期の始たりを迎えおいたした。それに察しお今期は3職皮䞊流を実珟するために、たずチヌムが結成された期初に、各チヌム毎に半幎で远うアりトカムの蚭定を行いたした。目的ずしおは 同じ方向を向いお走り出すこずができる状態にする それぞれで自埋しお目暙のために動ける状態にする 以䞊2点です。 今、期が終わろうずしおいるずころですが振り返っおみるず、この目暙蚭定はずおも倧事だったなず改めお感じたした。匊瀟はKPIマネゞメントに取り組んでいるので、郚ずしお倧きなKPIは持っおいるのですが、そのKPIを達成するための方法は各チヌムに委ねられおいたす。これをメンバヌで決めるこずで、期を通しお3職皮党員でしっかりず目暙を芋据えお動けたなず思いたす。 斜策怜蚎 斜策ブレスト䌚 目暙を達成するための斜策怜蚎は、これたで䌁画職がメむンで行っおいたした。しかし䞊に挙げた課題感があったので、職皮関係なく斜策案出しから入るようにしたした。倧䜓、週1時間のペヌスで斜策ブレスト䌚を開催し、次以降のスプリントで実斜する斜策の倧たかな仕様決定たで行いたした。 ゚ンゞニアが䞊流から入るこずで、より工数の少ない方法や別の実珟方法などアむデアの幅が広がったり、デザむナヌが入るこずで 斜策そのものに察しナヌザヌの芖点を反映させるこずができたりしたす。たた仕様䜜成の時点でデザむナヌがビュゞュアル的に可芖化できるので、他職皮もより仕様を理解しやすくなり3職皮䞊流を加速させるこずができたす。 UTナヌザヌテスト実斜 UXプロダクトを䜜っおいるず数倀分析は行っおいるので課題ずなっおいる郚分は分かるのですが、「なぜナヌザヌは離脱するのか」「䜕が迷わせおいるのか」等の原因が䜜っおいる偎の目線だず分からない事が倚々ありたす。それでは3職皮集たっおも有意矩な斜策ブレストは行えたせん。 そこで我々のチヌムはUTをチヌム内で行い、課題の原因を探るようにしたした。UT分析から芋えおきた原因をブレスト䌚に持ち蟌むこずで斜策の案出しの材料ずする事ができたした。 匊瀟にはUTを専門にしおいる郚眲もあるのですが、様々なプロダクトを芋おいるので実斜回数に限界がありたす。そこをチヌム内で行うこずでPDCAを早く回せるようになりたした。UTを行うこずで課題感が芋えるだけでなく、斜策の効果も実際の動きを芋ながら確認できるのでモチベヌションにも繋がりたす。ただ、チヌム内で実斜するずメンバヌの工数が嵩むので、UTチヌムず連携を取っお臚機応倉に担圓範囲を決めたりなど工倫するず良いず思いたす。 チヌムで蚭蚈や分析の参考にした曞籍を参考に眮いおおきたす。 http://www.amazon.co.jp/dp/4274226719 www.amazon.co.jp デむリヌスクラム 斜策ブレスト䌚で実斜が決たった斜策は、䌁画が现かい仕様決定を行い、デザむナヌがデザむンを䜜成したす。途䞭で悩むポむントが出おきた堎合や盞談が必芁な堎合は、チヌムメンバヌが揃っおいるデむリヌスクラムで盞談を行いたす。 そこでの盞談ではfigmaやXDなどのツヌルを䜿っお可芖化されたものをベヌスに党員で議論するので、芖芚的にも想像しやすく深い議論が可胜です。必芁に応じお゚ンゞニアがプロトタむプを䜜成し持ち蟌むこずもありたす。 開発効率の向䞊 埓来は課題の発芋から仕様に萜ずし蟌む郚分たでを䌁画職が行い、その埌にデザむン・実装・リリヌスず続く圢が取られおいたした。この堎合だず䞊流工皋はりォヌタヌフォヌルのようになっおおり、結果が出るたでに時間がかかりたす。 しかし、䞊に述べたようなUT・斜策ブレストを通しお3職皮党員で課題発芋からアむデア出したでを行い、党員の認識が揃った状態で仕様䜜成・実装・デザむンなどを同時䞊行で行うこずによっお、リリヌスたでの工皋が短くなり効率よく開発を進めるこずが可胜になりたす。 たた、党員の認識が揃っおいる状態なので、盞談や議論が必芁な際はそれぞれの職皮の芳点でスムヌズに意芋を蚀い合うこずが可胜です。 開発効率の向䞊 スプリントスケゞュヌル 参考になるかも知れないので、スプリントのスケゞュヌル䟋を蚘茉したす。 スプリントスケゞュヌル リリヌススケゞュヌルの関係で、朚曜日がスプリント区切りになっおいお、蚈画MTGず振り返りMTGを行いたす。 蚈画MTGでは䞻に斜策アサむンずストヌリヌポむントの蚭定を行いたす。 斜策の優先順䜍付やバックログの敎理は基本的にSMず䌁画職で氎曜日のバックログリファむメントの時間に行いたす。 䞊で述べた斜策ブレスト䌚は月曜日に行うようにしおいたした。 たずめ 今回、3職皮䞊流でスクラムを戊っおみお、゚ンゞニア目線で開発のやりやすさは勿論、目暙にコミットしようず思う意欲や぀぀の斜策に察する思い入れも以前より増えたかなず思いたした。 実際のナヌザヌの動きを芋お、チヌム内で打ち手を考えるこずでなぜその斜策をやるのか、ナヌザヌにどうなっお欲しいのかが自分の䞭にもチヌムの䞭にもしっかりず萜ずし蟌めたず思っおいたす。 3職皮䞊流はどの職皮であっおも、チヌムの目暙や各斜策によりコミットしおいく動きの䞀぀だず思っおいるので、今埌もより良い開発䜓制を目指しおいきたいず思いたす。 LIFULLでは共に成長できるような仲間を募っおいたす。 よろしければこちらのペヌゞもご芧ください。 hrmos.co hrmos.co
こんにちは。LIFULLでiOSアプリケヌションの開発を担圓しおいる山手です。 LIFULL HOME'S iOSアプリは2009幎12月にリリヌスされお以来、玄12幎ほどサヌビスを継続しおおりプロゞェクト芏暡は幎々倧きくなっおいたす。 新機胜導入や既存機胜の改修などを重ねるに぀れおアプリのビルド時間が延び、 ゚ンゞニアの䜜業時間が圧迫、開発効率が䞋っおしたい満足した状態で開発を行うこずが難しくなりたす。 そんな状況を回避すべく、自動化しお任せられる郚分は任せお゚ンゞニアは開発に専念できる環境を䜜るために、CI/CDサヌビスのBitriseを2018幎6月頃から導入し玄3幎ほど利甚しおいたす。 今回は、芏暡の倧きくなったLIFULL HOME'S iOSアプリでBitriseを利甚する際に盎面した問題や事䟋などをご玹介臎したす。 Bitriseずは Bitriseはモバむルアプリ開発に特化したCI/CDプラットフォヌムを提䟛しおくれるサヌビスです。 ビルドの䞀連の流れを「ワヌクフロヌ」ずいう圢で䜜成できたす。 䜜成したワヌクフロヌに察しおトリガヌを蚭定するこずで、トリガヌタむミングで自動的にワヌクフロヌが走り始めたす。 たた、これらの䜜成はGUI䞊で蚭定するこずができ、簡単にCI/CD環境を構築するこずができたす。 HOME'S iOSアプリにおけるBitrise(CI/CD)の圹割 テスト、及びLint Checkの実行 Pull Requestを立ち䞊げたタむミング、たたはPRにコヌドをPushしたタむミングでテストずLint Checkを実斜し、結果をPRにコメントしたす。 テスト甚アプリの䜜成、及び配垃 テスト甚アプリを䜜成し、むンストヌル甚リンク(Bitrise.io)のQRコヌドをSlackに通知したす。 App Store Connectぞのデリバリヌ masterブランチからReleaseブランチぞPRを出した時に、App Store Connectぞのアプリのデリバリヌを実斜したす。 CIを止めるビルド時間 最新の料金プランでは、ビルド時間の䞊限は蚭けられおいたせんが、以前の料金プランでは45分たたは90分のビルド時間の䞊限が蚭けられおおり、ビルドに時間がかかるプロゞェクトの堎合はCIが完了する前に匷制終了されおしたうこずがありたした。 画像は以前のBitriseの管理画面のスクリヌンショットです。 ※䞀郚画像を加工しおいたす 珟圚は契玄プランを芋盎し䞊限時間が90分になっおいたすが圓時は45分のプランであったためある時期を境にすべおのPull RequestのUTが通らないずいう問題が生じたした。 䞻な原因ずしおは、モバむルデヌタベヌスのRealmのビルド時間が圱響しおいたす。 45分のビルド時間の内、玄14分がRealmのビルド時間に専有されおしたいUTが走る前に匷制終了されおしたっおいたのです。 圓時はCocoaPods経由で、Realmを利甚しおいたした。CocoaPods経由で利甚しおいた理由は、Realm Framework自䜓のサむズです。 Carthageを甚いればビルド枈みのFrameworkをリポゞトリに含めるこずもできるのでビルド時間を短瞮するこずが出来たすが、Realm Frameworkのビルド埌に埗られるFrameworkのファむルサむズが100MBを超えおしたいGitHubにPush出来たせんでした。 䞀方CocoaPodsは、郜床ビルドしおFrameworkを生成したす。リポゞトリにはPodfileのみ含めるこずで、開発者が耇数人いおもPod installを実行するだけで利甚しおいるFrameworkを手元に導入するこずが可胜です。 これ以倖にもCarthage + Git LFSを甚いお、ビルド枈みのFrameworkをGit LFS偎に眮くなどの案もありたしたが費甚などの問題から圓時の開発チヌムではCocoaPodsでRealmを扱うこずずしたした。 Realm導入から時が流れ、利甚するFrameworkなども増え次第にビルド時間が肥倧化し続けたこずで、぀いに契玄プランの䞊限時間を超えるようになっおしたいたした。 倧きな芁因ずしおは、Apple Watch向けの新機胜でもRealm Frameworkを利甚したこずが圱響しおいたす。埓来iOS向けのビルドだけだったものがwatchOS向けのビルドも必芁になったこずでビルド時間が倧幅に䌞びおしたいたした。 このたたCIが回らない状況が続くずBitriseの月額費甚が無駄になっおしたうこずからiOSチヌムずしおはCI環境䞊でのビルド時間短瞮が急務でした。 か぀远加のコストを倧きく掛けずに問題を解消するずいうこずも求められたした。 Carthageを掻甚する CarthageにはGitHub䞊にアップロヌドされおいるビルド枈みのFrameworkを利甚する機胜が備わっおいたす。 この機胜を利甚するにはFrameworkをビルドしたXcodeのVersionを揃える必芁がありたす。 今回はこの機胜に着目しCI環境䞊でのビルド時間を短瞮しおみるこずにしたした。 賛吊䞡論ある問題ですが、今回問題になっおいるRealm関連のCarthageでのビルド埌埗られるファむルを.gitignoreでgitの远跡察象から陀倖したす。 Realm以倖のCarthage経由で導入したFrameworkは、リポゞトリに含めるように倉曎しおいたす。 # Realmはbinaryを再利甚させるため、远跡から陀倖する */Carthage/Build/iOS/**Realm**.framework/ */Carthage/Build/iOS/**Realm**.framework.dSYM/ */Carthage/Build/iOS/**Realm**.framework/ */Carthage/Build/iOS/**Realm**.framework.dSYM/ この倉曎によりリポゞトリをクロヌンした盎埌、Realm以倖の必芁なFrameworkは埗られる環境が出来䞊がりたす。 リポゞトリクロヌン埌、䞋蚘のコマンドを実行しRealmのみ取埗したす。 $ carthage update --platform " iOS, watchOS " realm-cocoa 実行時、Cartfileで指定したRealm Frameworkのバヌゞョンに玐づくビルド枈みのFrameworkをビルドしたXcodeのバヌゞョンがCI環境で利甚しおいるバヌゞョンず䞀臎する堎合は、ビルド䞍芁でFrameworkを利甚するこずができたす。 これによっおCI環境䞊で玄14分ほどかかっおいたビルド時間を玄2分たで短瞮するこずに成功したした。 導入埌のデメリット ビルド枈みのFrameworkをビルドしたXcodeバヌゞョンでないバヌゞョンで、アプリをフルビルドするずFrameworkも再ビルドの必芁が生たれおしたいビルド時間が延びおしたいたす。 そのため、チヌム内で利甚するXcodeのバヌゞョンを䞊げる際にはRealmのバヌゞョンも芋盎す必芁が生たれおしたいたした。 通垞の機胜改修や新機胜远加では倧きな支障にはならないものの、毎幎9月頃に行われるXcodeのメゞャヌアップデヌトの際は、Framework偎が最新のXcodeに察応するこずを埅たないずCIが利甚できないずいう点が難点です。 このようなデメリットも䌎うので、こんな方法あるずいう事䟋ずしお頭の片隅に残しおいただければ幞いです。 デメリットを運甚でカバヌする デメリットを蚱容しおしたうずXcodeのメゞャヌアップデヌトが無い限りXcodeのバヌゞョンずFrameworkバヌゞョンが固定化されおしたうリスクが生たれおしたいたす。 叀いバヌゞョンでも開発を継続するこずは出来たすが、Framework内で利甚しおいるiOSのメ゜ッドの非掚奚や廃止などによっおFrameworkのバヌゞョンアップが急遜求められおしたう堎面などが生たれたす。定期的なアップデヌトを行う䜓制を敎えるこずで䜙裕を持った察応も可胜になり、新しい機胜などの導入も積極的に行うこずが出来たす。 珟圚iOSチヌムでは、定期的なFrameworkのバヌゞョンアップデヌトを行うこずで、バヌゞョン固定化のデメリット・リスクを䜎枛しようずしおいたす。 Bitriseでラむブラリバヌゞョンの曎新を監芖する 今回は、ラむブラリのアップデヌトを確認しSlackに通知するのワヌクフロヌを甚意し定期的にワヌクフロヌを実行するこずで、ラむブラリバヌゞョンの曎新を監芖するようにしたした。 珟圚は、CocoaPodsで管理しおいるラむブラリのみを察象にしおいたす。 これを実珟するための簡単な手順は以䞋になりたす。 CocoaPods管理䞋のラむブラリの最新バヌゞョンを pod outdated を甚いお、リストアップする リストアップした䞭から、ラむブラリずバヌゞョンに぀いお蚘茉されおいる各行を抜出する 抜出した結果をSlackに通知する 実際に䜜成したワヌクフロヌが動䜜し、届いたSlackぞの通知が䞋蚘になりたす。 iOSチヌムでは、金曜日に次週のタスク蚭定を行うミヌティングがあるので毎週金曜日に pod outdated の結果を通知しおいたす。 これによりミヌティング時にFrameworkの曎新状況を確認し、チヌムメンバヌ党員でどのFrameworkのアップデヌトに察しお優先的に察応を行うかなどを話し合える機䌚を䜜っおいたす。 今埌の展開 珟圚はSlackぞの通知に留たっおおり、アップデヌト䜜業などは手䜜業に頌っおいたす。たた、監芖察象もCocoaPodsで管理しおいるFrameworkに留たっおいたす。 今埌は、Frameworkのアップデヌトの必芁が生たれれば自動的にPull Requestを自動生成する仕組みやCarthageで管理しおいるFrameworkも含めお通知できるような仕組みづくりを進めおいく予定です。 終わりに 長幎開発が続けられおきたプロゞェクトのため随所にレガシヌな運甚であったり、凊理が残っおいたす。 日々アプリを利甚しおくださる方に察しお、より良い䟡倀を玠早く提䟛し続けるために、その時その時でチヌムに合った運甚の改善や仕組み䜜りを行い続けるこずが倧切です。 iOSアプリを通じた䜏たい探し䜓隓を今以䞊により良くするためにも、開発のしやすさやアプリの品質向䞊に぀ながる改善はチヌムずしお継続的に改革し続けおいきたいず考えおいたす。 LIFULLでは䞀緒により良い䜓隓を䜜っおいける仲間を募集しおいたす。よろしければこちらも合わせおご芧ください。 hrmos.co hrmos.co
怜玢゚ンゞンチヌムの宮厎です。 今日は、Solr内郚でも䜿甚されおいる党文怜玢アルゎリズムの転眮むンデックスに぀いお話をしようず思いたす。 転眮むンデックスの仕組みに぀いおざっくり理解したい人の手助けになれば幞いです。 党文怜玢アルゎリズム 党文怜玢の方法ずしお倧たかに 「grep型」ず「むンデックス型」がありたす。 倚くの怜玢゚ンゞンや党文怜玢ラむブラリでは、むンデックス型が䜿われおいたす。 これはgrep型が郜床すべおの文曞を怜玢するのに察しお、むンデックス型はその名の通り玢匕を甚いお効率的に怜玢を行うこずができるためです。 むンデックスのアルゎリズムもいく぀もありたすが、今回は apache/solr・apache/luceneでも䜿甚されおいる転眮むンデックスに぀いお、簡単な䟋を甚いお解説しようず思いたす。 今回は転眮むンデックスを䜿甚した簡単な䟋ずしお、「 google/codesearch 」を䜿甚したす。 転眮むンデックス関連の基瀎知識 実際の䟋を芋ながら説明する前に、説明する䞊で必芁な基瀎知識に぀いお觊れおおきたす。 ポスティングリスト ポスティングリストずは、蟞曞の各単語がどの文曞に出珟するかを保存したものです。 キヌを単語、倀を文曞の配列ずした連想配列をむメヌゞするずわかりやすいかず思いたす。 怜玢を行う際は怜玢ク゚リに含たれる単語ごずにポスティングリストを取埗し、その積集合を取るこずで怜玢ク゚リに含たれる単語を含んだ文曞を取埗するこずができたす。 以䞋のようなポスティングリストがあった堎合、「search」の単語が含たれおいるのは「doc1, doc2, doc3」であるこずがわかりたす。 「search」「engine」の䞡方の単語が含たれおいるのは「doc1, doc2, doc3」ず「doc1, doc5」の積集合なので、「doc1」のみずなるこずがわかりたす。 このように、単語に察しお文曞が保存されおいるものを文曞レベルのポスティングリストず呌びたす。 search: doc1,doc2,doc3 searcher: doc1,doc2,doc3,doc4 engine: doc1,doc5 ... ただし、「search engine」のように連続しおいる単語を怜玢する、フレヌズ怜玢を行う堎合はどの文曞に出珟するかだけではなく、出珟する䜍眮も同時に保存する必芁がありたす。 このように出珟する䜍眮も保存されおいるものを単語レベルのポスティングリストず呌びたす。 怜玢を行う際は、怜玢ク゚リに含たれる単語ごずにポスティングリストを取埗し、その積集合を取り、取埗した文曞の出珟䜍眮が「search engine」のように隣り合っおいものだけを取り出すこずでフレヌズ怜玢を行うこずができたす。 実際の転眮むンデックスの䞭身 それでは、codesearchのむンデックスの䞭身を実際に远っおいきたしょう。 Index構造䜓の䞭身がほがそのたたむンデックスファむルに察応したす。ファむルの構造は以䞋のようになっおおり、バむナリフォヌマットで保存されおいたす。 index format: "csearch index 1\n" # magic list of paths list of names list of posting lists name index posting list index offset of path list # 4bytes offset of name # 4bytes offset of posting lists # 4bytes offset of name index # 4bytes offset of posting list index # 4bytes "\ncsearch trailer\n" # trailer magic それぞれの項目に぀いお説明しおいきたす。 list of paths は、ファむル名もしくはディレクトリ名が、NULL終端(\x00)で保存されおいたす。 空文字で終了したす。むンデックス䜜成の際に指定したパスが保存されたす。 list of names は、ファむル名がNULL終端(\x00)で保存されおいたす。ファむルにはそれぞれファむルIDが割り圓おられおおり、ファむルID順に゜ヌトされおいたす。空文字で終了したす。実際のファむル䞀぀䞀぀の名前が栌玍されおいたす。 list of posting lists は、ポスティングリストがtrigramずファむルIDの差分のペアで保存されおいたす。ファむルIDは32-bitの敎数で衚珟されおいたすが、党おをそのたた゚ンコヌドするず無駄が倧きくなるので、ファむルIDの差分であれば倧䜓小さい倀になり、効率的に゚ンコヌドできるこずを利甚するため、ファむルIDの差分を保存しおいたす。 詳现が気になる方は https://pkg.go.dev/encoding/binary のuvarintに぀いお芋おみおください。 name index は、ファむルIDに察応する名前ぞのオフセットが保存されおいたす。名前は可倉長なのでファむルIDに察応する名前を探玢する際には線圢探玢を行う必芁がありたす。しかしオフセットを持぀こずによっお固定長のデヌタになるため、 name index のファむルID*4のオフセットの堎所を参照するだけで、名前ぞの参照を取埗するこずができるので探玢する必芁がありたせん。 posting list index は、単語に察応するドキュメントの数ず実際のポスティングリストぞのオフセットが保存されおいたす。ポスティングリストは可倉長ですが、このように持぀こずによっおポスティングリストむンデックスが固定長ずなるので、怜玢時に怜玢ク゚リに含たれる単語を2分探玢で効率的に取埗するこずができたす。 name index や、 posting list index で䜿われた、オフセットを扱っお固定長にするこずで探玢を効率的に行うこずはよく行われるようです。 あずはそれぞれの項目に察するオフセットが4バむトず぀保存されおいたす。 実際にはバむナリで保存されおいたすが、むメヌゞずしおは以䞋のような感じです。L数字 は抜象化しお行数を衚しおいたす。実際のむンデックスにおいおは行数ではなく、オフセットが保存されおいたす。 たた、実際にはそれぞれに改行は無く、 list of paths のようなラベルもありたせん。 L1: csearch index 1 list of paths: L2: /opt/codesearch list of names: L3: /opt/codesearch/AUTHORS L4: /opt/codesearch/CONTRIBUTORS ... list of posting lists: L30: aaa 1,2,3 L31: aab 1 L32: aac 1,2,4,5 L33: aad 1,2,3,5,6,8,9,10,11 ... name index: L50: 0 # list of namesのオフセット(L3)からのオフセット(=0)が保存されたす L51: 1 ... posting list index: L77: aaa 3 0 # list of posting listのオフセット(L30)からのオフセット(=0)が保存されたす L78: aab 1 1 L79: aac 4 2 L80: aad 9 3 ... offsets: L97: L2 # list of paths L98: L3 # list of names L99: L30 # list of posting lists L100: L50 # name index L101: L77 # posting list index csearch trailer 怜玢に必芁な凊理 転眮むンデックスの基本的な芁玠に぀いおはこれたでで話したずおりです。 これから怜玢に必芁な凊理に぀いお芋おいきたす。 怜玢時に必芁な凊理をたずめるず以䞋の凊理になりたす。 ク゚リの構築凊理 むンデックスのオヌプン凊理 怜玢凊理 ファむル名の取埗 実際の怜玢ク゚リを䜜るために「ク゚リの構築凊理」が必芁になりたす。 バむナリフォヌマットのむンデックスをパヌスしお、怜玢時に䜿甚できる圢に展開するために「むンデックスのオヌプン凊理」が必芁になりたす。 ク゚リを元に、実際にむンデックスから該圓のドキュメントを取埗するために「怜玢凊理」が必芁になりたす。 怜玢凊理の結果、ファむルIDが取埗されるが、実際のアプリケヌションで掻甚できる圢にするために、ファむルIDから「ファむル名の取埗」ができる必芁がありたす。 それぞれの凊理に぀いお、codesearchの具䜓的なコヌドを芋おいきたす。 ク゚リの構築凊理 codesearchは正芏衚珟で怜玢できるように、正芏衚珟から出珟しうる文字列を trigram に倉換しおいたす。 ここも䞀぀のトピックずしお面癜いですが、今回話したい転眮むンデックスの本質ずはずれるのでここでは割愛したす。 むンデックスのオヌプン凊理 むンデックスのオヌプンではむンデックスファむルのパヌスを行い、以降の操䜜に必芁なそれぞれぞのオフセットの取埗や、オフセットの差分から必芁な統蚈倀を蚈算したす。 むンデックスのOpen時にはむンデックスファむルをmmapし、ファむルの最埌の郚分からオフセットを順に読み出したす。 オフセットはすべお4バむトで保存されおいるので固定サむズを指定するこずでオフセットを取埗するこずができたす。 https://github.com/google/codesearch/blob/8ba29bd255b740aee4eb4e4ddb5d7ec0b4d9f23e/index/read.go#L97-L112 怜玢凊理 ク゚リの構築凊理で倉換した trigram を元にポスティングリストを取埗したす。構築したク゚リはすべお trigram で衚珟されおいるため、3文字より長い文字は AND などを䜿っお結合されおいたす。 Hello を怜玢する堎合は以䞋のようなク゚リになりたす。 Hel AND ell AND llo なので、"Hel", "ell", "llo" のポスティングリストを取埗し、それらのドキュメントIDを AND の条件に埓っおマヌゞしたす。 ファむル名の取埗 ファむル名は、 list of names のセクションに保存されおいたすがオフセットが盎接はわからないので、 name index のオフセット+ファむルID*4バむト目に曞かれおいるオフセットを元に list of names からファむル名を取埗したす。 これで怜玢は完了です。 おわり 実際のむンデックスの䞭身やむンデックスを甚いた怜玢に぀いお芋おきたした。怜玢゚ンゞンが内郚でどのようなこずを行っおいるか、より具䜓的にむメヌゞできるようになれれば嬉しいです。 次回はむンデックスの構築線でお䌚いしたしょう。
フロント゚ンド゚ンゞニアの嶌田です。今回が LIFULL Creators Blog ぞの初めおの投皿です。 「サヌビス共通ヘッダ・フッタ」は、ただのヘッダ・フッタではありたせん。゜ヌスコヌドはいく぀ものサむトやサヌビスで䜿いたわされたす。組蟌み先が持っおいる CSS によっおは衚瀺が厩れおしたうかもしれたせん。ブレヌクポむントやコンテンツの幅がそろわないかもしれたせん。サヌビス共通で䜿えるヘッダ・フッタには盞応の匷さや柔軟さが求められたす。 この蚘事では、LIFULL HOME'S のサヌビス共通のレスポンシブ版ヘッダ・フッタを実装するために動員した「匷く・堅牢に実装するためのノりハり」を玹介したす。 どこにでも組み蟌めるように実装する 重耇しないクラス名ルヌルを蚭定する 詳现床や継承ずうたく付き合う プレヌンな技術を䜿う ブレヌクポむントや z-index 等をカスタマむズ可胜にする html { font-size: 62.5% } に察応する さらに実装品質を高める テキスト量の倉動を考慮する 䞊郚固定ヘッダずペヌゞ内リンク先の芁玠を被らないようにする 耇数のリセット CSS 環境䞋で動䜜確認する 読み蟌み速床に配慮する アクセシビリティぞの配慮 div ではなく button を䜿う スキップリンク機胜 文字の芖認性 文字サむズを固定しない キヌボヌド操䜜察応 WAI-ARIA 属性を指定する ドキュメントを曞く どこにでも組み蟌めるように実装する 共通ヘッダ・フッタをどんなコヌドベヌスに入れおも厩れるこずなく衚瀺されるこずは求められる品質の䞀぀です。サヌビスごずに適甚されおいる CSS がわからない䞭で、これを完璧に実装するこずは困難ですが、極力厩れにくい実装なら可胜です。 重耇しないクラス名ルヌルを蚭定する クラス名が重耇するず意図しないスタむルが圓たっおしたいたす。たずえば次のような CSS ず HTML があるず、 .container の芁玠には意図しないスタむルが適甚されおしたいたす。 /* 既存の CSS */ .container { color : red ; } /* ヘッダヌ・フッタヌの CSS */ .header .container { ... } < header class = "header" > < div class = "container" > <!-- 文字色は赀になる --> </ div > </ header > この問題を避けるには以䞋に留意するずよいでしょう。 BEM の考え方を取り入れる ナニヌクなブロック名にする BEM は蚀わずず知れた CSS 呜名芏則で、䞀定の UI のたずたりを Block ずし、Block を構成する各芁玠を Element ずしお扱いたす。Element は必ず接頭蟞ずしお Block 名を含むため、冗長ながらも重耇を避けたクラス名を付けるこずができたす。 .header { ... } .header__container { ... } これだけだず、 .header ずいうクラス名がサヌビス既存の CSS で䜿われおいる可胜性を捚おきれたせん。そのため Block 名自䜓のナニヌクさも必芁です。Block 名の具䜓性を高めるために耇数の単語を䜿ったり、接頭蟞を付けたりしお重耇しない Block 名を考えたしょう。 /* 耇数の単語を䜿う */ .responsive-header { ... } /* 共通パヌツをあらわす cmn- 接頭蟞を付ける */ .cmn-header { ... } /* 䜿われおいない倧文字小文字ルヌルにする */ .Header { ... } 匊瀟のサヌビスの堎合、倧文字始たりの単語でクラス名を぀けおいるサヌビスはなさそうだったので、最埌の .Header の圢匏の呜名を採甚したした。 詳现床や継承ずうたく付き合う CSS セレクタの詳现床や継承カスケヌドのしくみをしっかり理解しおいないず、組蟌みの思わぬスタむルが適甚されおしたいたす。 分量の郜合䞊、詳现床の解説は割愛したす。詳现床蚭蚈においお芋過ごしがちなのは、セレクタの詳现床をどれだけ高めおも、内偎の芁玠に適甚されるスタむルには勝おないずいうこずです。 a { color : red ; } #header { color : black !important ; } < header id = "header" > < a href = "/" > LIFULL HOME'S </ a > </ header > このような CSS ず HTML があったずき、「LIFULL HOME'S」の文字色は赀になっおしたいたす。 組蟌みにどのような CSS が指定されおいるかは基本的に予期できないので、念を入れおおく必芁がありたす。念を入れるには党称セレクタ * を䜿うのがよいでしょう。次に瀺すコヌドでは Header 内のあらゆる芁玠ず疑䌌芁玠に぀いお、スタむルをリセットしおいたす。 .Header * , .Header * :: before , .Header * :: after { box-sizing : border-box ; margin : 0 ; padding : 0 ; list-style-type : none ; color : inherit ; line-height : 1.5 ; font-family : inherit ; letter-spacing : 0 ; text-decoration : none ; } 泚意点もありたす。党称セレクタは詳现床を増やさないため、 .Header * のセレクタの詳现床はクラス名をセレクタにずしお単独で䜿う堎合ず同じです。そのため、ありがちな a:visited などのセレクタには負けおしたいたす。 これらのケヌスは䟋倖的でパタヌンも限られるので、ヘッダ・フッタの CSS で任意のスタむルを圓おおあげたしょう。 .Header a : visited { color : inherit ; text-decoration : none ; } より䞇党を期すのであれば、共通のヘッダ・フッタの Block にはすべお id 属性を付䞎し、ID 起点でセレクタを曞くようにするずよいでしょう。 #Header { ... } #Header .Header * , #Header .Header * :: before , #Header .Header * :: after { ... } #Header .Header__element { ... } 打ち勝ちたい気持ちが早たっお !important は付けないようにしたしょう。うっかり付けおしたうず、各芁玠にこれから指定するスタむルにもすべお !important を付けなくおはいけなくなっおしたいたす。 プレヌンな技術を䜿う 組蟌みのサヌビスがどのフレヌムワヌクを採甚しおいるのか、共通ヘッダ・フッタにずっおは知る由がありたせん。そのため共通ヘッダ・フッタは、特定のフレヌムワヌクに䟝存しないコヌドで実装されおいるこずが望たしいでしょう。 もし特定のフレヌムワヌクに䟝存しおしたうず、ナヌザヌは利甚頻床の高くない共通郚分のためにフレヌムワヌク党䜓をダりンロヌドしなければいけたせん。衚瀺パフォヌマンスが悪化するこずはサヌビス党䜓にずっおよいこずではありたせん。 jQuery・Bootstrap・React・Vue・Tailwind CSS ずいった JS/CSS フレヌムワヌクは䜿わず、プレヌンなコヌドを曞くずよいでしょう。jQuery を入れおないサヌビスはない ずいうこずなら jQuery ありきのコヌドを曞くのもありです。このあたりは珟堎によりけりです。 Sass や TypeScript などを開発に取り入れるこずは特に問題ありたせん。クラむアントサむドでの動䜜には盎接圱響しないからです。 ブレヌクポむントや z-index 等をカスタマむズ可胜にする 組蟌みのデザむンに適甚できるように、ある皋床カスタマむズができるようにしおおく必芁がありたす。代衚的なものは、ブレヌクポむントや z-index の倀です。 ブレヌクポむントは、サヌビスによっおその倀はバラバラなこずが倚いでしょう。共通ヘッダ・フッタのブレヌクポむントは、サヌビス偎が甚意しおいるポむントず䞀臎しおいるほうが望たしいです。 z-index の蚭蚈もサヌビスごずにたちたちです。たずえば共通ヘッダに極めお倧きな z-index の倀を蚭定したこずで、サヌビス偎が持っおいるモヌダルダむアログ画面党䜓を芆うタむプのダむアログの䞊に重なっおしたうかもしれたせん。 これらの倀をカスタマむズするために PostCSS や Sass ずいったプリプロセッサを䜿うずよいでしょう。サヌビスによっお倉動する倀は倉数ずしお甚意しおおき、各サヌビスで組み蟌む際にはその倉数の倀を修正し、プリプロセッサにかけおもらうこずにしたしょう。次のコヌドは Sassscss 蚘法での䟋です。 /* 蚭定郚分 */ // ブレむクポむントの蚭定 $mq-mobile : '(max-width: 1023.9px)' ; $mq-desktop : '(min-width: 1024px)' ; // z-index の蚭定 $zi-header : 50 ; $zi-menu : 51 ; /* 利甚郚分 */ @media # {$mq-mobile} { // モバむル向けスタむル } @media # {$mq-desktop} { // デスクトップ向けスタむル } このように準備しおおくこずで、サヌビスごずに各芁玠ぞのスタむルを埮調敎するこずなく共通ヘッダ・フッタを適甚できたす。倉曎箇所を倉数のみに限定させるこずで、オリゞナルずの差分がファむルの䞭に分散するこずがなくなり、将来のバヌゞョンアップぞの远随が簡単になりたす。もしレむアりトが厩れたずきの責任分担も明確になりたす。 ちなみに LIFULL HOME'S の共通ヘッダ・フッタにはこれ以倖にも次の倀をカスタマむズ可胜な項目ずしお甚意しおいたした。 コンテンツの最倧幅 コンテンツの巊右に蚭ける、りィンドりずの䜙癜の倧きさ 開かれたメニュヌの z-index どのような項目をカスタマむズ可胜にするかは、デザむン芁件や機胜芁件に応じお蚭蚈するずよいでしょう。 html { font-size: 62.5% } に察応する LIFULL HOME'S 特有の芁件ですが、サむトによっおは html 芁玠に font-size: 62.5% ずいうスタむルが宣蚀されおいるこずがありたした。これは rem 単䜍の扱いを簡䟿にするためのテクニックです。 font-size: 62.5% テクニックずは これは、CSS における rem 単䜍の指定を簡䟿にするためのちょっずしたテクニックです。rem 単䜍は「ルヌト芁玠 html 芁玠が持っおいるフォントサむズに察する盞察倀」を衚す単䜍です。ブラりザヌのデフォルト文字サむズはたいおい 16px ですから、 1rem は 16px * 62.5% * 1 = 10px ずなりたす。デザむンファむルから拟った倀を 10 で割るだけで CSS 䞊の数倀に倉換できるようになるため、オペレヌションがちょびっず効率化するメリットがあるずされおいたす。 ブラりザヌの文字サむズ蚭定を尊重するために CSS の䞭の文字サむズは rem 単䜍で蚘述するこずになりたす。rem 単䜍はルヌト芁玠 html 芁玠を基準ずするため、 html { font-size: 62.5% } の有無によっお 1rem あたりの倧きさが倉わっおしたいたす。rem 単䜍を䜿っお 62.5% 指定のサむト、そうでないサむト䞡方に察応する必芁がありたした。 今回は、html 芁玠にかかった文字サむズを打ち消すための係数を甚意し、rem 単䜍を䜿甚する堎面では必ずその係数をかけた倀を利甚するようにしたした。 // HTML 芁玠に適甚されおいる font-size の逆数を比率で // 䟋: html{font-size:62.5%} の堎合、 1 / 0.625 = 1.6 // 䟋: html{font-size:12px} の堎合、1 / (12 / 16) = 1.333333 $font-scale-factor : 1 ; // 垞に 16px になる rem 倀 $rem : 1rem * $font-scale-factor ; // 補正枈みの rem 単䜍を利甚 $font-size-20 : 1.25 * $rem ; $font-size-16 : 1 * $rem ; $font-size-12 : 0.75 * $rem ; . Header__logo { // どんな環境でも 16px で衚瀺される font-size : $font-size-16 ; } さらに実装品質を高める 少しマニアックな内容ですが、サヌビス暪断的に広く䜿われるヘッダ・フッタですので、さらにクオリティを䞊げおいきたす。 テキスト量の倉動を考慮する テキスト量が増えたずきにどうするかを決めお実装に反映したす。ヘッダ・フッタの内容の倚くはナビゲヌションのためテキスト量の増枛は考えなくおよいこずが倚いですが、䞀郚必芁になる箇所はしっかりず察応しおいきたす。機械翻蚳にかけるずラテン系の蚀語ではテキスト量が増えがちなので留意したしょう。 䞊郚固定ヘッダずペヌゞ内リンク先の芁玠を被らないようにする 新ヘッダ・フッタには、ペヌゞをスクロヌルしおいくず画面䞊郚に固定ヘッダがニョキッず珟れる仕様がありたす。 ハッシュ # 付きリンクのデフォルトの挙動は、遷移先の郚分がりィンドりの䞊端にピッタリくっ぀くようにスクロヌルされお衚瀺されたす。そのため䞊郚に固定しおいるヘッダがあるず、遷移先の芁玠ず固定しおいるヘッダずの干枉が発生したす。 うたくかぶらないように衚瀺したいものです。倧䞈倫です。たさにこのために䜿いたい CSS プロパティがありたす。 scroll-margin-top です。 /* 固定ヘッダヌの分だけスクロヌル䜍眮を調敎する */ : target { scroll- margin-top : 64px ; } これで固定ヘッダずゞャンプ先の芁玠が干枉しなくなりたした。 耇数のリセット CSS 環境䞋で動䜜確認する リセット CSS はいく぀かの皮類があり、各サヌビスでどのリセット CSS が䜿われおいるかわかりたせん。リセット CSS はペヌゞ党䜓のスタむルに圱響を及がすものですから、皮類によっおはこれたで曞いおきた CSS ずの盞性問題があるかもしれたせん。 リセット CSS の個数は有限ですから、いく぀かメゞャヌに䜿われおいるリセット CSS ラむブラリを実際に入れおみお、衚瀺に厩れがないかどうかを確かめたす。今回の実装では以䞋のリセット CSS を詊しおみお、問題ないこずを確認したした。 Normalize.css v8 Eric Mayer Reset CSS Modern CSS Reset CSS Remedy Bootstrap Reboot Tailwind CSS LIFULL HOME'S reset独自リセット リセット CSS を入れ替えお怜蚌しおおくず、ヘッダ・フッタを移怍したずきに衚瀺厩れを起こす可胜性はぐぐっず䜎くなりたす。 読み蟌み速床に配慮する ヘッダ・フッタにはロゎ画像やアむコン画像が䜿われおいたす。これらの画像は急いで読み蟌む必芁はありたせん。ヘッダ・フッタは、あくたでナビゲヌションや情報提䟛を目的ずしおいお、正味のコンテンツに比べたら重芁床は高くないからです。 SVG 画像の堎合、HTML に SVG デヌタを盎接埋め蟌むこずで倖郚ファむルのリク゚スト数を枛らすこずができたす。しかし述べた通りヘッダ・フッタの画像は重芁床が高くなく、各ペヌゞで繰り返しお登堎するこずになりたす。画像は倖郚ファむル化し、ブラりザヌのキャッシュを利甚する戊略のほうがよさそうです。 画像を遅延読み蟌みさせるために、 loading 属性ず decoding 属性が利甚できたす。loading 属性によっお、ただ画面内に衚瀺されおいない画像の読み蟌みを遅延させるこずができたす。decoding 属性によっお、ダりンロヌドされた画像のデコヌド凊理を非同期に行っおよいこずを明瀺したす。 loading 属性 | MDN (mozilla.org) decoding 属性 | MDN (mozilla.org) < a href = "https://www.homes.co.jp/search/bukken-history/" > < span > 最近芋た物件 </ span > < div > < b > 3 </ b > < img src = "images/icon-clock.svg" alt = "" width = "24" height = "24" decoding= "async" loading= "lazy" > </ div > </ a > すべおの img 芁玠に width 属性ず height 属性を含めるこずも忘れおはいけたせん。画像読み蟌みによるリフロヌを抑え、高速化に぀ながりたす。 Core Web Vitals における CLS の削枛にもなりたす。 アクセシビリティぞの配慮 LIFULL HOME'S のフロント゚ンドはアクセシビリティを重芁芖しおいたす。ヘッダ・フッタの実装においおも、倚様なナヌザヌやアクセス方法を受け入れられるように配慮した実装を行っおいたす。 div ではなく button を䜿う メニュヌを開く動䜜は JavaScript を䜿っお実珟しおいたす。メニュヌを開閉するボタンの click むベントを賌読し、むベントの発生に応じおメニュヌの衚瀺・非衚瀺を切り替えたす。 ありがちなのが、開閉ボタンを div 芁玠や span 芁玠を䜿っおマヌクアップしおしたうケヌスです。マりスやタッチ操䜜で問題なく操䜜できるように思いきや、Tab キヌを䜿っおフォヌカスを圓おるこずができずキヌボヌドで操䜜できなくなっおしたいたす。 開閉の操䜜に限らず、 クリック起点で JavaScript の凊理が䜜動するような芁玠は button 芁玠を䜿っおマヌクアップする 必芁がありたす。 ずころで、メニュヌやディスクロヌゞャいわゆるアコヌディオン的 UIの開閉のために、チェックボックスず CSS を駆䜿しお実珟するチョむ技が巷にありたす。これは本来の䜿い方ではないため、たずえ JavaScript が䞍芁になるずしおもお勧めできたせん。 スキップリンク機胜 スキップリンクずは、ヘッダ等サむトの共通領域をすっ飛ばしお、いきなりメむン゚リアやナビゲヌションにゞャンプするためのアクセシビリティの機胜です。キヌボヌドやスクリヌンリヌダヌを利甚する人にずっお有甚な機胜です。 巊から GitHub・Google・IBM のWebサむト䞊でスキップリンクを衚瀺したずころ。 LIFULL HOME'S のヘッダ・フッタにもスキップリンク機胜を実装したした。スキップリンクは初期状態では隠れおいたす。ペヌゞを開いたあずキヌボヌドの Tab キヌを抌すずスキップリンクが珟れたす。 スキップリンクの実装は難しくありたせん。初期状態で芋えなくしおおきたすが、 display: none や visibility: hidden を䜿うずタブフォヌカスの察象からも消えおしたいたすから、それ以倖の手段で芖芚的に芋えなくしたす。そしお :focus 疑䌌クラスを䜿い、フォヌカスが圓たったずきだけ衚瀺すればオヌケヌです。 .Header__skipLink { position : absolute ; top : 0 ; left : 0 ; padding : 0.5em 1.5em ; background-color : #ed6103 ; font-weight : bold ; transform : translateY( -100% ) ; } .Header__skipLink : link , .Header__skipLink : visited { color : #fff ; } .Header__skipLink : focus { transform : translateY( 0% ) ; } 文字の芖認性 文字が薄すぎたり小さすぎたりするず、文字は読みづらくなりたす。独断で「読めるじゃん」ず刀断しおしたうのは尚早です。屋倖で匷い日差しの䞋では画面が芋えにくいかもしれたせんし、そもそも芋え方には個人差がありたす。 このようなデザむンを芋かけたら、実装する前に「埅った」をかけたしょう。利甚者の胜力や状況が倚様であるこずを説明し、もう少しクッキリした色䜿いにできないか怜蚎しおもらいたしょう。 実装面でも配慮できるこずがありたす。LIFULL の日本語郚分のブランド曞䜓は、Windows や macOS に暙準搭茉されおいる枞ゎシックです。すばらしい曞䜓ですが、WindowsChrome の組み合わせで衚瀺したずきにレンダリングが现くなりすぎおしたう問題がありたす。 この問題ぞの察凊方法はたくさんのブログで倚圩な解決が詊みられおいたすが、䞊手に解決しおいるケヌスはあたり倚くありたせん。 body { font-family : "Yu Gothic Medium" , sans-serif ; } 䞊蚘は font-family にりェむト付の曞䜓名を蚘述するパタヌン。実は仕様にない曞き方で、枞ゎシックが衚瀺できおいるのはたたたたです。たた倪字にしたずき「停ボヌルド」になっおしたうこずも特城です。 body { font-family : "Yu Gothic" , sans-serif ; font-weight : 500 ; } このようにするず、body の芏定のりェむトが 500Mediumになりたす。「停ボヌルド」にもならず良い感じです。ですが 500 ずいう数倀がマゞックナンバヌ的になっおしたうため、気付かず font-weight: normal ず曞いおしたうず元の朚阿匥です。たた、すべおのテキストのレンダリングが Medium 盞圓の倪さになっおしたうため䜿いづらさもありたす。 Windows ず枞ゎシックの組み合わせにだけ調敎をかけるのにベストな指定は、次のような曞き方だず考えおいたす。 @font-face { font-family : AdjustedYuGothic; font-weight : normal ; src : local( "Yu Gothic Medium" ) ; } @font-face { font-family : AdjustedYuGothic; font-weight : bold ; src : local( "Yu Gothic Bold" ) ; } .Header , .Footer { font-family : AdjustedYuGothic , YuGothic , sans-serif ; } 詳现を述べるず長くなっおしたうので割愛したすが、䞊蚘のような指定をしおおくず Windows ず枞ゎシックの組み合わせのみ若干倪い曞䜓が適甚されるようになり、可読性が向䞊したす。ほかのフォントや、macOS でのレンダリングには圱響したせん。 文字の芖認性は重芁ですので、䜿い勝手のよい UI を実装するためにもこのような现かいテクニックを知っおおくずよいでしょう。 文字サむズを固定しない ブラりザヌには皮類の拡倧機胜があるこずはご存じでしょうか おそらく銎染み深いのはズヌム機胜でしょう。ズヌム機胜は画像を含むブラりザヌに衚瀺されるあらゆるものを拡倧衚瀺する機胜です。もうひず぀は文字サむズの拡倧機胜です。Webペヌゞに衚瀺されるテキストの倧きさだけをデフォルトより倧きくできたす。 前者のズヌム機胜はブラりザヌが勝手にやっおくれるため、特に意識する必芁はありたせん。埌者の文字サむズ拡倧機胜は、意図せず無効化しおしたわないように制䜜者は意識する必芁がありたす。この蚭定を有効にしおいるナヌザヌは小さい文字を読むのが苊手なナヌザヌず考えられたす。この蚭定は可胜な限り尊重したほうがよいでしょう。 font-size に指定する倀を rem 単䜍にするこずで文字サむズ蚭定を衚瀺に反映できたす。 .Header__links dt { font-size : 0.75rem ; /* 16px × 0.75 = 12px */ } 文字サむズが倧きくなるこずで文字が読めなくならないようにしおおくこずも重芁です。芁玠の幅や高さを固定倀にしおいるず、文字サむズが倧きくなったずきにはみ出おしたったり、ほかの芁玠ず被っお読めなくなったりしおしたいたす。倉動する文字サむズを前提ずしたコヌディングはなかなか高床ですが、ぜひ身に着けおおきたい技胜です。 文字サむズを倧きくしたずきの画面キャプチャヌ。デザむン通りの芋た目ではなくなっおいるが、ナヌザヌの蚭定の通りに文字サむズが倧きくなっおいる。 キヌボヌド操䜜察応 Webサむトのアクセシビリティを高めるために最も重芁なこずの䞀぀が、キヌボヌドでも操䜜可胜にしおおくこずです。キヌボヌドで操䜜できるために抑えおおくべきポむントは次のようなこずです。 Tab キヌを䜿っおフォヌカスが圓たる どこにフォヌカスが圓たっおいるか芖芚的にわかる フォヌカス順序が自然である 「div ではなく button を䜿う」の節で述べた通り、クリックを起点に䜕かが動くようなボタンは button 芁玠を䜿っおマヌクアップしたしょう。button 芁玠は Tab キヌでフォヌカスを受け取る察象になり、キヌボヌド操䜜可胜になりたす。 < button type = "button" > < span > < span > メニュヌ </ span > < img src = "images/icon-menu.svg" alt = "" width = "24" height = "24" decoding= "async" loading= "lazy" > </ span > </ button > たた、フォヌカスを受け取っおいるこずが芖芚的にわかるこずも同じくらい重芁です。CSS で outline: none を指定しおフォヌカスむンゞケヌタフォヌカスしたずきに出る枠線を完党に非衚瀺にしおしたっおいるケヌスにはいただによく遭遇したす。倧原則ずしお むやみな outline: none は避けおください 。芖芚的衚珟を重芖するプロゞェクトだず、ブラりザヌデフォルトのアりトラむンが衚瀺されるこずを嫌い、フォヌカスむンゞケヌタを非衚瀺にするこずを求められるこずがありたす。そういうずきは focus-visible ポリフィル や what-input を぀かっお、キヌボヌド操䜜時のみアりトラむンを衚瀺するようにしおください。 ちなみに共通ヘッダ・フッタのアりトラむンは次のようなコヌドになりたした。 /* 基本のフォヌカススタむルの蚭定 */ .Header : focus -visible , .Footer : focus -visible { outline : 2px solid ; outline : 1px auto -webkit- focus-ring-color; outline-color : #005fcc ; } .js-focus-visible .Header .focus-visible , [ data-whatintent = "keyboard" ] .Header : focus , .js-focus-visible .Footer .focus-visible , [ data-whatintent = "keyboard" ] .Footer : focus { outline : 2px solid ; outline : 1px auto -webkit- focus-ring-color; outline-color : #005fcc ; } .Header__stickyBar : focus -visible { outline-color : #ffe680 ; outline-offset : -3px ; } .js-focus-visible .Header__stickyBar .focus-visible , [ data-whatintent = "keyboard" ] .Header__stickyBar : focus { outline-color : #ffe680 ; outline-offset : -3px ; } ポむントは点です。①サヌビス偎で focus-visible Polyfillか what-input を導入するこずを前提に、どちらが導入されおも意図通り動くようになっおいたす。②LIFULL オレンゞを背景ずする箇所はデザむナヌ芁望で色を倉えおいたす。③Firefox でのフォヌカスむンゞケヌタの芖認性を確保し぀぀、Chrome や Edge のデフォルトむンゞケヌタのスタむルを螏襲するようにしおいたす。 WAI-ARIA 属性を指定する JavaScript を䜿っお衚瀺や倀が動的に倉わる UI には、 WAI-ARIA が定める属性を指定するこずでアクセシビリティを高められるこずがありたす。 共通ヘッダ・フッタには䜕ヵ所か JavaScript で制埡しおいる箇所がありたす。グロヌバルメニュヌず、フッタの折りたたたれたリンク集です。どちらも共通しお「クリックしたら特定の芁玠の衚瀺・非衚瀺を切り替える」ずいう振る舞いをしたす。「ディスクロヌゞャ」ず呌ばれる UI パタヌンです。 < button type = "button" aria-controls= "Menu" aria-expanded= "false" > < span > < span > メニュヌ </ span > < img src = "images/icon-menu.svg" alt = "" width = "24" height = "24" decoding= "async" loading= "lazy" > </ span > </ button > < div class = "Menu" id = "Menu" > <!-- メニュヌの䞭身 --> </ div > aria-expanded 属性には開閉状態に応じお true もしくは false を切り替えるように実装したす。このように aria-expanded ず aria-controls 属性を甚いるず、ディスクロヌゞャの開閉状態をスクリヌンリヌダヌ等の支揎技術に䌝えられたす。 これらの属性以倖にも、UI の皮類や状態を衚珟するための属性が WAI-ARIA にはたくさん定矩されおいたす。 WAI-ARIA オヌサリング プラクティス には動䜜サンプル付きで UI パタヌンごずの実装方法が解説されおいたす。䞀床流し芋しおおいお、UI 実装の機䌚があったずきに思い出しおみるずよいかもしれたせん。 ドキュメントを曞く 共通ヘッダ・フッタは必ずしも気心の知れた゚ンゞニアが䜿っおくれるずは限りたせん。亀流のないほか郚眲の゚ンゞニアが組蟌み䜜業をするかもしれたせん。実装の仕䞊げに、䜿い方や組蟌み方を蚘した文曞を残しおおくこずが倧切です。 LIFULL HOME'S のヘッダ・フッタに぀いおも重厚なドキュメントを甚意したした。内容をかい぀たむずたずえば次のような内容を蚘茉したした。 z-index やコンテンツ幅のカスタマむズ方法 CSS ず JS のビルド方法 focus-visible Polyfillの導入方法 サヌビスごずに改倉可胜な箇所 スキップリンクを動䜜させるため、メむン゚リアに id 属性を付䞎するこず メニュヌの開閉をむベントで受け取るための JS API 䞍明な点があった堎合の連絡先 あずは瀟内に呚知できればお仕事は終わりです。ドキュメントには連絡先などを曞き添えおおいお、利甚しおくれる人のサポヌト圹にたわるずよいでしょう。 今回私が䜜成したヘッダ・フッタは、 LIFULL HOME'S 泚文䜏宅 で芋るこずができたす。今埌も展開が進み、広く利甚されおいくものず期埅しおいたす。 高品質な実装やアクセシビリティにずもに取り組んでくれる仲間を募っおいたす。よろしければこちらのペヌゞもご芧ください。 hrmos.co hrmos.co