はてなブックマーク

株式会社ハローで飲食店向け業務支援サービス「Respo」の開発をしている ysirman です。 主に、Ruby on Rails を使ったバックエンドの開発を担当しています。 プロダクトを継続的に開発していると、いつの間にか「もう使われていなさそうなコード」が増えていきます。 いわゆるデッドコードです。 Respo は「おいしい料理を作る。それ以外は全部、おまかせください。」というコンセプトのもと、予約管理から POS レジまで幅広い機能を提供しています。 その分、過去の仕様や一時的な対応がそのまま残り、結果としてデッドコードになっている箇所も少なくありません。 私は既存プロダクトに対する機能追加・仕様変更を繰り返す中で、 「これ、もう使われていない前提で実装していいんだっけ？」 「消したいけど、影響範囲が分からなくて怖い」 という場面に何度も遭遇してきました。 デッドコードの存在に気づ

1. はじめに 1.1 記事の目的 私はハローでカスタマーサポート向けAIサービス「helloX」 の開発を担当しています。入社後に電話領域を学び始めましたが、知れば知るほど奥が深く、技術的にも面白い分野だと実感しています。 その電話技術の面白さを紹介するために、この記事では、 Twilio と Asterisk を組み合わせ、いわゆる“固定電話”のように Twilio番号で外線の発着信 と 着信時の同時呼び出し を行える最小構成のIP電話を作ろうと思います。 1.1.1 helloX とは？ helloX は、電話の応対から後処理（ACW）までを自動化 するカスタマーサポート向けAIサービスです。既存ツール／社内データと連携し、従来は人手が必要だった後処理まで自動化します。 ユースケースの例としては以下のようなものがあります: 未収督促・債権回収：顧客データと同期し、督促プロセスを自動化

CTOの杉本です。 旅先の南米ペルーでこの文章を書いています。アンデスの山奥まで旅して、マチュピチュを見てきました。世界は広いがその気になればどこでもいつか辿り着ける程度には狭いのだな、と感じています。 ハローでは、エンジニアが開発する際にコーディングAIを活用すること(Cline, Cursor Agent, Claude Code など)を必須にしました。 社内エンジニアにとっての鉄の掟である Notion の開発ガイドラインにもこのことを記載しています。 同時に、エンジニアがコーディングAIを自由に実験・試行錯誤できるように"AI使い放題"に近い形で制度を整備して運用をしています。 今回は、スタートアップでコーディングAIを最大限に活用するためにどうしているかを共有します。 コーディングAI活用は、2025年最大の low hanging fruit なぜコーディングAIを活用するの

CTOの杉本です。 「コードレビューが忙しくて開発の時間がとれない」というのは、ある程度役割が広がったエンジニアからよく上がる不満だと思います。 コードレビューはチーム開発で重要な活動ではありますが、「コードレビューで使う時間に対してどれだけの価値を出せるかを意識できていない」ことが原因の一つにあることが多い、と僕は思っています。 僕自身も立場上日々のコードレビューの負担が重く、うまく開発が進まないと感じていた時期がありました。時間対価値を意識して思い切ってやり方を変えてからは、コードレビューの負担の重さを感じることは少なくなりました。 今回は、僕個人が運用しているコードレビューへの考え方について書きます。 コードレビューの目的 そもそもコードレビューは何のためにやるのでしょうか？ 僕が思うに、コードレビューの目的は「品質担保」と「開発者の成長」です。 最低限のコード品質・リリース品質を担

ハローWeb高速化シリーズはご無沙汰となりました。今回は"何を以って高速化したといえばいいのか？"という話をします。 率直に、Page Speed Insightsに対してこんな思いがありました。 80点以上合格点とされているが、無理では？ 速くなっているはずなのにスコアに現れなくてつらい Core Web Vitalsの登場で「とにかくはやく"表示する"」よりも「はやくストレスなく"触れられる"」ことの重要性が増してきた Page Speed Insights、もしかしたらあまり見なくてもいいのでは？説を抱き、AutoReserveでのパフォーマンス改善を通してこの説は正しいかもしれないと実感した筆者が、"Web高速化 パフォーマンス改善においてはPage Speed Insightsを見ない方が幸せになれる"という主張を以って話を進めていきます。 Next.jsにリニューアルしました

グローバルなレストラン予約サービス、AutoReserveの開発をしているjavascripterです。 今回は、ハローでのautoreserve.comのアーキテクチャの変遷についてお話しします。 概要 AutoReserveは最初Next.jsで構築され、その後SPAに移行し、最終的に再びNext.jsに戻るという珍しい技術選択をしています。 この記事では、各アーキテクチャの移行の背景と、大規模アプリケーションの段階的移行の実践について解説します。 AutoReserveについて AutoReserveは世界中のレストランの予約が可能なグローバルサービスです。iOS・Android・Webの3プラットフォームで展開しており、各アプリ100ページ近くある大規模なアプリケーションです。 モバイルアプリはReact Native (Expo)で開発しており、当初のWeb版はNext.jsで構

javascripter です。ハローでは、初期メンバーとしてプロダクトのローンチ前からAutoReserve の開発に関わっています。 前回の記事に引き続き、筆者が社内で書いている技術ガイドラインについて紹介します。 はじめに ハローでは、高品質なコードを維持し、開発チームの技術レベル向上を図るため、チーム横断的に、有用な技術Tips、ベストプラクティス・コーディングガイドラインなど情報をNotion上に集約し、自由にエンジニアが閲覧・編集できるようになっています。 この取り組みの目的は以下の通りです： コード品質の向上と統一 開発チームメンバーの技術スキル向上 「どう」直すかでではなく「なぜ」そう修正すべきかまで理解してる人を増やす 効率的な開発プロセスの確立 前回の記事については、こちらを参照下さい。 Reactベストプラクティス: react-hooks/exhaustive-de

javascripter です。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 今回は、筆者が社内で書いている技術ガイドラインについて紹介します。 はじめに ハローでは、高品質なコードを維持し、開発チームの技術レベル向上を図るため、社内で継続的に技術Tipsやガイドラインの整備・蓄積を行っています。 チーム横断的に、有用な技術Tips、ベストプラクティス・コーディングガイドラインなど情報をNotion上に集約し、自由にエンジニアが閲覧・編集できるようになっています。 この取り組みの目的は以下の通りです： コード品質の向上と統一 開発チームメンバーの技術スキル向上 「どう」直すかでではなく「なぜ」そう修正すべきかまで理解してる人を増やす 効率的な開発プロセスの確立 新メンバーのオンボーディング支援 今回紹介するドキュメント 今回は、その中から「reac

大変ご無沙汰しております、今年度もあと少しです。この記事ではAutoReserveでのCLS改善についてお話します。 Web高速化シリーズ第2弾となります、第1弾「メンバーを巻き込み、分析基盤を整える」も併せてご覧ください。 CLSはきちんと改善を行えば必ず満点の25点を取ることができる、Page Speed Insightsの中でもある意味特別な指標です。CLS以外の指標は「~するまでの”時間”」を示しますが、CLSだけは「1画面のなかでコンテンツがずれた”総量”」を示しているためです。秒数を削るのはある程度限界がありますが、「コンテンツがずれないようにする」のはほぼ完璧に対応することができます。 Page Speed Insightsが登場してすぐの頃はCLSは5点しか持っていませんでした。 5点にしてはUXへの影響が大きいなあと思っていたら、バージョン8で15点、現在のバージョン10

2023年もあと少しです。スパッと区切りをつけるよりも2024年にバトンを渡すような過ごし方をしたいなと思い、この記事を書き始めました。 2023年はAutoReserveにとって飛躍の年でした。海外レストランの予約開始をはじめとする多くの機能をリリースし、プレスリリースも多く出し、ユーザー数の大台を突破しました。 また飲食店向けに提供しているAutoReserve for Restaurantも今年大きな成長を遂げました。今年だけで30以上もの飲食店さまにご協力いただき導入事例を掲載させていただきました。 しかしその代償もありました。多くの機能をリリースし大きな成長を遂げた筋肉痛として「ページスピードの遅さ」が露見しました。さまざまな機能をスピーディにリリースしながらページスピードを高い水準で維持するのは至難の業です。 夏頃にオーガニック流入を増やすためにSEO周りの改善を始めたところ、

javascripter です。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 ハローでは、開発効率の最大化のため継続的に新しい技術を取り入れています。 今回は、AutoReserveのReact Native製アプリにExpo Routerという、Next.jsのファイルベースのルーティングに似たルーターのライブラリを導入した事例を紹介します。 作業時点でのExpo Routerの最新版stableがv1だったため、解説もv1についてになります。現在はExpo Routerはv2がリリースされているため、最新版では一部、記事での解説と異なる可能性があります。 AutoReserveアプリの技術スタック AutoReserveのネイティブアプリはReact Nativeで書かれており、またウェブ版は、Reactで書かれています。 今回はReact N

uiu です。 株式会社ハローでは AutoReserve を運営していますが、サービスの裏側で飲食店やユーザーのサポートのためコールセンターを運用しています。直近では日本語だけでなく英語等多言語でのカスタマーサポートを提供しています。 昨年、カスタマーサポートが利用するコールシステムを、外部のIP電話サービス(MiiTel) から Twilio Flex を使った内製のコールセンターシステムに切り替えました。 Twilio Flex 製システムを運営し始めてから半年以上経つなかで、カスタマイズの知見などが見えてきたので、今回紹介しようと思います。 背景 カスタマーサポートではIP電話サービスを利用していましたが、当時以下のような課題がありました。 サポートの品質向上のため、ダッシュボードでの可視化や分析をしたいができることが限られていた 社内CRMとの連携や自動化をしたいがカスタマイズ性

uiu です。ハローでは普段バックエンド開発をメインに担当していますが、創業以来片手間でインフラも担当しています。 ハローでは、少数精鋭のメンバーの意識をプロダクト開発に集中するため、インフラ面では Cloud Run などマネージドなサービスを最大限に活用しています。 今回は、久しぶりにインフラに意識の一部を捧げ、いくつかの眠れない夜を過ごす機会があったので、インフラ面の話について紹介しようと思います。 スタートアップと PostgreSQL AutoReserve はサービス立ち上げ以来、DB は PostgreSQL、APPサーバーは Ruby on Rails のバックエンド構成で運用してきています。 特に PostgreSQL は立ち上げ以来安心して使い続けられている技術要素です。サービス運用から(ある規模までの)分析まで PostgreSQL だけで回せる点は、少人数でプロダク

はじめに はじめまして、株式会社ハローで業務委託として開発をしている@0906kokiです。 今回の記事では、React Nativeで開発されているRespo by AutoReserveで、Expoを最大限に活かしたE2Eテストの導入実装について書きたいと思います。 背景 飲食店向けにセルフオーダーや予約台帳の機能を提供するRespo by AutoReserveは、React Nativeで開発されております。 今回、RespoにE2Eを導入した目的に関しては、以下のような点が挙げられます。 手動テストの場合、テストをスキップ or 見逃していたケースがあったので、毎回網羅的にテストできるようにし、QAの質を上げたい 頻繁に本番デプロイできるようにする コミットごとにテストできるようにすることで、QAを待たず事前にデグレを検知できる (今後) ライブラリのアップデートなど、全てのテス

javascripterです。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。今回の記事では、AutoReserveでおこなっているコード共通化の取り組みについて紹介します。 背景 AutoReserveのネイティブアプリはReact Nativeで書かれており、またウェブ版は、Reactで書かれています。 ウェブ版では、React Native for Webという、React上でReact NativeのコンポネントのAPIを使えるようにするライブラリを使用しています。 React Native for Webを採用したことで、ハローでは現在、エンジニア1人でiOS、Android、ウェブの全てのプラットフォームに同時展開できるようになりました。 また、不具合修正やデザインの修正も、一箇所を修正するだけで同時にできるようになりました。それぞれのプラ

javascripterです。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 突然ですが、Reactを使用する際、コンポネントのロジックや状態が増えてきたとき、みなさんはどうされてるでしょうか。 関数コンポネントでは、一般にcustom hooksとしてまとめて切り出すことが多く行われていると思います。 今回の記事では、useState/useRef + custom hooksという単位で切り出すのではなく、 クロージャを使いロジックや状態をコンポネントの外に持たせるようにリファクタリングすることで、コードの見通しが良くなる、という事例を紹介します。 JavaScriptにおけるクロージャとは、関数が外側のスコープの変数などへの参照を保持できる機能のことです。ここではクロージャとして実装しましたが、同等のことはclassを使っても実装できます。 A

uiu です。 前回の記事 『なぜ Next.js をやめたのか？』 では、Reactベースのウェブフロントエンドで、サーバーサイドレンダリング(SSR)をしない選択をすることで、アーキテクチャをシンプルに保っているという話を紹介しました。 アーキテクチャをシンプルに保つ工夫のおかげで、ウェブとアプリのコード共通化が簡単になり、1人のエンジニアが最小限の労力で複数プラットフォームに変更を入れることが可能になっています。 Dynamic Rendering はスケールしないのでは？メンテが大変なんでは？ という質問があったので、今回は実際どのように Dynamic Rendering を運用しているかについて紹介したいと思います。 結論を簡単に言うと、キャッシュが効くためサーバーコストは高くなく、またサーバーレス環境で動いてるため運用のメンテナンスコストも低いです。 サーバーコストは当然 S

javascripterです。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 この記事では、AutoReserveウェブ版が、Next.jsを一度採用したがやめ、その後create-react-app + react-routerの構成に移行した経緯を書きます。 ウェブ版開発の背景 AutoReserve はAIが電話予約を代行してくれる飲食店向け予約グルメアプリで、現在はiOS / Android / ウェブにサービスを展開しています。 元々はReact Native製のネイティブアプリのみ展開していましたが、ユーザ獲得の面でウェブ版が必要となったため、 追加でウェブ版を実装し、現在の3プラットフォームでの展開に至ります。 最初の技術選定 ウェブ版の最初のバージョンでは、フレームワークとしてNext.jsを採用しました。Reactで書け、SEOのた

はじめまして！ 株式会社ハロー、マーケティングチームです。日頃は、サービス全体の設計やAutoReserveの問い合わせ数増加施策などグロース全般を担当しています。 4月は新社会人や転職してこれからマーケターとしてやっていくという方がいると思います、そういう方に向けて「Webマーケティングって何をすればいいの？」という質問に自分なりに回答をしてみたいと思います。合わせて各トピックにおいて参考となりそうな本についても紹介します。 Webマーケティング戦略を考える前に大事にしたいこと いきなり残酷な話ですが世の中のほとんどのサービスは、思った通りには伸びません。 これを読んでいる方も 「こういうサービスを作ったら絶対売れる」 「○○の悩みを解決したら確実に成功する」 と思ったことはないでしょうか？ 私も同じように、幾度となく同じようなことを考えたことがあります。例えば、「寝坊する人が多いから、

uiu です。ハローには創業時に入社し、エンジニアとしてAutoReserveの開発にゼロから関わってきました。現在はバックエンドをメインに担当していますが、領域横断的に開発することを得意としています。 2022年の初めに AutoReserve にあるWebフロントエンドをすべて Vercel に移行しました。 Vercel に移行するのと同時に Turborepo を導入しました。現在、4サービスのWebフロントエンドを monorepo として運用しています。 AutoReserve は、AIが代わりに電話してくれる飲食店向け予約グルメアプリです。iOS / Android アプリ、 Web アプリを提供しています。 また、セルフオーダーシステム AutoReserve Order を提供しており、レストランすべての業務をサポートできるプラットフォームを目指しています。 背景 Aut