サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ブラックフライデー
user-first.ikyu.co.jp
この記事は一休.com Advent Calendar 2025の 5日目の記事です。 私は毎年この時期になると Haskell に関する記事を投稿していますが、今年もまた Haskell を題材にしつつ、今回は Haskell を使うことがプログラミング中の思考にどのような影響を与えるかについて考察してみようと思います。 LLM と「言葉が思考を形づくる」という直感 LLM (Large Language Models、大規模言語モデル) は次にくる言葉を予測しているだけなのに、それが知性のように見える。「言葉の推定」でプログラミングすらできてしまうという事実に誰もが驚いたところだと思います。 LLM を本当の知性とみなすかどうかは議論の分かれるところだと思いますが、LLM の原理をみるに、少なくとも「言語」が推論や思考の形式に深く影響するという直感は正しいのではないかと思います。 とこ
この記事は一休.com Advent Calendar 2025の2日目の記事です。 レストランプロダクト UI 開発チームの鍛治です。一休.com レストランのフロントエンドを担当しています。 2025 年 4 月、PayPay グルメ の全面リニューアルが完了しました。このリニューアルでは「一休.com レストラン」と「PayPay グルメ」の 2 つのサービスを 1 つのコードベースに統合しています。 一休レストラン・PayPay グルメではリニューアルプロジェクトを契機に Tailwind CSS から Panda CSS への置き換えを進めています。 また置き換えやってるのか 1 と思われるかもしれませんが、もちろん理由あっての導入です。本稿では、なぜ導入したのか、それにより何が得られたのかをご紹介したいと思います。 PayPayグルメについて 本記事で登場する「PayPayグル
この記事は一休.com Advent Calendar 2025の1日目の記事です。 一休.com レストランの開発を担当している恩田(@takashi_onda)です。 はじめに 昨日 2025/11/30 に開催されたフロントエンドカンファレンス関西で、「細粒度リアクティブステートのスコープとライフサイクル」というタイトルで発表を行いました。 speakerdeck.com 発表ではまたしても終盤が駆け足になってしまいました。本稿では、その際に十分に触れられなかった論点のうち、特にスコープに焦点をあて、その課題と解決案をご紹介したいと思います。 細粒度リアクティブステート 細粒度リアクティブステート (fine-grained reactivity) 1 とは、Solid や Svelte 5 の Runes で謳われている、UI を必要最小限な単位でリアクティブに更新するフロントエン
はじめに こんにちは。一休データサイエンス部の平田です。 一休.comは主に国内の宿泊施設を取り扱う予約サイトですが、インバウンド需要の高まりを受け多言語対応を進めており、2025年の3月に国際サイトをリリースいたしました。対象言語は英語、中国語(繁体字・簡体字)、韓国語、タイ語、ベトナム語、マレー語、インドネシア語です。 一休.comトップページのメニューから言語を切り替えることができます 一休.com英語版のトップページ 一休.com英語版のホテル紹介ページ 今回は主にデータとして存在する日本語をどうやって翻訳したかということと、その注意点についてフォーカスして書いていきます。 自動翻訳サービスの選定 自動翻訳の必要性 ユーザーに見える部分を全て翻訳するため、かなり多岐に渡るテーブルが対象になり、文字量にして約10億文字を翻訳する必要があります。翻訳後の分量で言えば8つの言語で翻訳する
概要 初めまして、CTO室のいがにんこと山口(@igayamaguchi)です。一休.com/Yahoo!トラベルのフロントエンドの開発を担当しています。 この記事ではWebアプリケーションのフロントエンドの画面実装をボトムアップに実装することのメリットと、その方法を紹介します。 ボトムアップに画面を実装する ボトムアップに画面を実装する、というのは小さなコンポーネントや処理から実装をしていき、それを組み合わせて徐々に大きなコンポーネントを作り、最終的に画面を作る実装方法です。 昨今のWebアプリケーションの実装で使用するReactやVueといったフレームワークはHTML、CSS、JavaScriptなどをディレクトリ、コンポーネントとしてまとめて実装することができます。この機能を利用し、 input、ボタンといった小さなコンポーネントを作成 上記のコンポーネントを使用しさらに大きなコンポ
この記事は一休.com Advent Calendar 2024の23日目の記事です。 一休レストランのフロントエンドアーキテクトを担当してる恩田(@takashi_onda)です。 はじめに 先日の JSConf JP 2024 で「React への依存を最小にするフロントエンドの設計」という内容で登壇しました。 speakerdeck.com 発表では駆け足になってしまった、React への依存をしていない Vanilla JS 部分をどのように構成しているのかを、Dependency 管理とテストの文脈でご紹介したいと思います。 Dependency とは Dependency Injection の Dependency です。 タイトルも「Jotai を使った DI とテスト技法」とした方が伝わりやすいとは思います。 ですが、厳密には injection していないので、あえて
はじめに id:rotom です。社内情報システム部 兼 CISO室 所属で ITとセキュリティを何でもやります。 このエントリは 一休.com Advent Calendar 2024 16日目の記事です。昨日は id:naoya による TypeScript の Discriminated Union と Haskell の代数的データ型 でした。その他の素敵なエントリも以下のリンクからご覧ください。 qiita.com 2018年のアドベントカレンダーにて「一休における情シスの取り組み」を紹介させていただき、一定の反響をいただくことができました。 早いものであれからすでに6年が経過しました。6年も経つとコーポレートIT も変遷しています。 user-first.ikyu.co.jp これまで特定の製品・サービスの事例などは断片的に紹介していましたが、6年ぶりに改めて全体像をお話したい
この記事は 一休.com Advent Calendar 2024 の15日目の記事です。 予定より早く書き上げてしまったので、フライングですが公開してしまいます。 TypeScript の Discriminated Union (判別可能な Union 型) を使うと、いわゆる「代数的データ型」のユースケースを模倣することができます。一休のような予約システム開発においては「ありえない状態を表現しない」方針で型を宣言するためによく利用されています。 「あり得ない状態を表現しない」という型宣言の方針については以下の URL が参考になります。 Designing with types: Making illegal states unrepresentable | F# for fun and profit このユースケースで Discriminated Union を使う場合、それは文字
この記事は 一休.com Advent Calendar 2024 7 日目の記事です。 宿泊事業本部 ユーザー向け開発チームの原です。 一休.com と Yahoo!トラベルの主にフロントエンドの開発を担当しています。 今回は、普段の開発でコードを書き始める前段階で Design Doc を作ることで、円滑な開発を進められるようになったというお話をします。 チーム構成について まず、前提を共有するために私達が普段どのような体制で開発しているかを説明します。 私が所属している宿泊事業本部 ユーザー向け開発チームは、一休.com と Yahoo!トラベルの主に toC のユーザー向けの機能開発をしています。ユーザー向け開発チームのメインのミッションはユーザー体験を向上させることであり、そういった施策の機能開発を素早くリリースできることを大事にしています。 一方、プロダクト開発においては機能開
この記事は 一休.com Advent Calendar 2024 の3日目の記事です。 昨今は我々一休のような予約システム開発においても、関数型プログラミング由来のプラクティスを取り入れる機会が増えています。 例えば、値はイミュータブルである方が扱いやすい、関数は副作用のない純粋関数にする方がテスタビリティなども含め何かと都合がよい、そういう場面では積極的に不変な値を使い、関数が冪等になるよう意識的に実装します。ドメインロジックを純粋関数として記述できると、堅牢で責務分離もしやすく、テストやデバッグもしやすいシステムになっていきます。 ところで「関数型プログラミングとはなんぞや」というのに明確な定義はないそうです。ですが突き詰めていくと、計算をなるべく「文」ではなく「式」で宣言することが一つの目標だということに気がつきます。 文と式の違いは何でしょうか? for 文、代入文、if 文など
この記事は一休.com Advent Calendar 2024の1日目の記事です。 kymmtです。 当ブログ「一休.com Developers Blog」は、以前からはてなブログで運用しています。そして、今年からは執筆環境を少し改善しました。具体的には、GitHubを用いて記事の作成や公開ができるようにしました。 この記事では、当ブログの執筆環境をどのように改善し、ふだん運用しているかについて紹介します。 HatenaBlog Workflows Boilerplateの導入 従来は、執筆者が記事をローカルやブログ管理画面のエディタ上で書き、なんらかの方法でレビューを受け、公開するというフローでした。このフローで一番ネックになりやすいのはレビューで、Slack上でレビューが展開されがちになり、議論を追いづらいという問題がありました。 そこで、執筆環境の改善のために、はてなさんがβ版と
コーポレート本部 社内情報システム部 兼 CISO室 id:rotom です。 10/12(土) にハイブリッド形式で情シス向けのテックカンファレンス「Business Technology Conference Japan 2024(BTCONJP 2024)」が開催されます。 btcon.jp btajp.connpass.com 昨年オンライン開催された BTCONJP 2023 では私が登壇者として 本社を東京ガーデンテラス紀尾井町へ移転し、オフィスファシリティ・コーポレートIT を刷新した話 というテーマで発表させていただきましたが、今年は core staff として運営に参画しており、所属企業である一休はブロンズスポンサーとして協賛しております。 Identity, DX & AI, Device Management, Zero Trust, Cyber Security,
はじめに こんにちは。宿泊プロダクト開発部の宮崎です。 みなさん、生成 AI 使ってますか? 近年、AI の進歩はめざましく、文章生成や画像生成はもちろん、動画生成も実用的なレベルで出来るようになっています。 ChatGPT が話題になったのが 2022 年の 11 月なので、たった 2 年足らずでここまで来ているという事実に少し恐ろしくもありますね。AGI(汎用人工知能)の実現もそう遠くないのかもしれません。 一休でも AI 技術は注目していて今年の 6 月に、まさに生成 AI を使ってホテル検索システムの改善を行いました。 この記事では、その時に学んだプロンプトエンジニアリングの重要性について書いていこうと思います。 生成 AI を使ったホテル検索システム 今回我々が実装したのはフリーワード・文章でもホテルを検索できるシステムです。 以下のようなユーザーの自由な入力に対して、適切なホテ
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか? R
レストランプロダクト開発部の矢澤です。 一休では「RESZAIKO」というプロダクトの開発を行っています。 この開発を進めるにあたり、UI/UX に関するいくつかの課題があり、エンジニア主導でデザインシステムを構築することにしました。 本記事では、エンジニア主導でデザインシステムを構築することになった背景や、実際に取り組んだ内容について赤裸々にお話しします。 デザインシステムの導入を検討しているものの、最初の一歩を踏み出せずにいる・あるいは何から始めればよいかわからないチームにとって参考になれば幸いです。 そもそも RESZAIKO とは RESZAIKO は飲食店の予約管理を DX する SaaS 事業で、現在3つのプロダクトを提供しています。 複数予約サイトの在庫を一括管理する「サイトコントローラー」 予約や顧客情報を管理する「予約台帳」 店舗独自の予約ページを提供する「Web予約」
Go Conference 2024にスポンサーしました CTO室プラットフォーム開発チームの山口(@igayamaguchi)です。 先日6/8(土)に一休でGo Conference 2024にスポンサーをさせていただき、スポンサーブースを出展しました。 gocon.jp 来ていただいた方はありがとうございます! 来ていただいた方と話していく中で、一休がGoを使っていることを知らない方がたくさんいることに気づきました。逆に、最近使い始めたばかりのRustの事例についてご存知の方のほうが多かったのです。これは、次のRustについての記事が多くの方に読まれたことによる影響だと思います。 user-first.ikyu.co.jp 実際には一休はGoを使っているサービスがたくさんあります。その点をアピールするため、この記事では一休のどのサービスでGoが活用されているかを紹介します。 一休がど
こんにちは。宿泊プラットフォーム開発チームの菊地です。 一休では月に一度、社内エンジニア向けにIkyu Tech Talkを開催しています。2022年から始まり、ありがたいことに2024年3月で丸2年を迎えることができました。 この記事では、Ikyu Tech Talkの2年間のふりかえりをしていきます。 また、私は社内イベントの主催が初挑戦だったので、どうやったらイベントを盛り上げられるのかと悩んだときもありました。 そこで、同じように自分の会社でTech Talkを開催してみたい人に向けてイベント運営の知見もお伝えしたいと思います。 開催のきっかけ もともと定期的なプロジェクトの成果報告会はあるものの、業務で得たエンジニアリングの知見の共有をする場は設けられていませんでした。 あるとき「技術についてざっくばらんに話す場が定期的にあると楽しそう。一緒にやらない?」と声をかけてもらい、面白
CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる?」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした(笑)。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜
こんにちは、一休.comスパ(以下、「スパ」)の開発を担当しているshibataiと申します🙏 今回はスパのデータベースの在庫の持ち方で試行錯誤した話をさせていただきます。 背景 2024-03-29追記: 一休.comスパにおける在庫の特徴について 一休.comスパが扱う「在庫」は、「ある日付の特定の時間に対する空き枠」です。以降の説明では、スパ施設ごと、日付ごと、また時間ごとに増えていく「在庫」をいかに効率よく扱うかについて説明しています。 詳細については次のスレッドも参照してください! https://t.co/Y0SPmDE4yZ この記事のコメントみてると、少し我々のシステムの要件が伝わってないというかそこの説明が記事に不足しているように思った。ので以下その補足— naoya (@naoya_ito) March 29, 2024 現在の実装 スパは予約を受け付けるために在庫の
一休.comレストランのエンジニアのkymmtです。 2023年度の下半期、一休.comレストランの開発チームでは開発プロセス改善に取り組みました。改善は小さい単位で徐々に進め、バックログの作りかたやカンバンの運用方法を改善することで、フロー効率の向上、開発ペースの把握、チーム内外からの進捗の見える化ができるようになりました。 この記事では、このようなインクリメンタルな開発プロセス改善の取り組みについて紹介します。 従来の開発プロセス 主に2023年度前半の開発プロセスは次のような形でした1。 プロダクトのリリースに必要なタスクが長いバックログとして存在し、ひたすらタスクを消化 その状況に課題を感じ、区切りを入れるために2週間のスプリントを導入 この時点では、スプリントは2週間ごとに状況を確認するためのもので、目標に対するふりかえりや、次のスプリントの計画を作るためのものとしては活用してい
この記事は一休.com Advent Calendar 2023 25日目の記事です。 一休レストランでは、よりスムーズな予約体験の提供を目的とするシステムのリニューアルを進めています。その一環として、2023年10月から、レストラン個別ページの表示から予約までのスマートフォンビューにおいて、バックエンドのサーバをRustで書かれたものに置き換えました。 一休レストランの Rust バックエンドが正式リリースされました。https://t.co/7N4VGv5ej9 このページのスマートフォンビューはバックエンドが Rust で書かれた GraphQL になってます— naoya (@naoya_ito) October 4, 2023 本番運用が始まって3か月近く経ちましたが、これまで安定して継続的な開発と運用ができています。これはRustだからと構えることなく、「ふつう」のバックエンド
このエントリーは 一休.comのカレンダー | Advent Calendar 2023 - Qiita の22日目の記事です。 レストランプロダクトUI開発チームの鍛治です。 一休レストランのフロントエンドを担当しています。 一休レストランでは Next.js App Router Remix を採用しています。 user-first.ikyu.co.jp 昨年の終わり頃から始まった一休レストランのリニューアルですが、フロントエンドは Nuxt v2 (Vue 2) から Next.js App Router (React) に、という大きな切り替えで、不慣れだった我々は React 初心者がひっかかる落とし穴を全部踏み抜いてきました。 例えば、チュートリアルに従って useState で変化する状態を定義して、最初はそれで全てがうまくいっていました。機能追加していく過程でいつの間にか一
概要 この記事は 一休.com Advent Calendar 2023 16日目の記事です。 RESZAIKO開発チームの松村です。 一休では各サービス毎に、開発中のサービスの動作を社内で確認できる環境があります。 それぞれmain(master)ブランチと自動的に同期している環境と、特定のブランチを指定して利用できる環境の2種類があります。 今回、RESZAIKOの新規サービス(予約画面)に対してブランチを指定してデプロイできる環境を作成したので、その方針と反省点と今後について記述していきます。 現在運用中の予約画面 開発環境を作る理由 一休では長らく、EKS上に複数の環境を用意して、ブランチを指定すると開発環境にデプロイするシステムが利用されてきました。 一般的にこのような環境を構築するのは以下のような理由が挙げられます。 動作確認 マイクロサービスで、異なるブランチ同士の組み合わせ
このエントリーは一休.com Advent Calendar 2023の15日目の記事になります。 CTO 室の恩田です。 現在は一休レストランのフロントエンドのリアーキテクトを手がけています。 今日はその中で Next.js App Router から Remix に乗り換えた話をご紹介したいと思います*1。 背景 6日目の記事で香西から紹介させていただきましたが、2023年10月に一休レストランのスマートフォン用レストラン詳細ページをリニューアルしました。 一休レストランの Rust バックエンドが正式リリースされました。https://t.co/7N4VGv5ej9 このページのスマートフォンビューはバックエンドが Rust で書かれた GraphQL になってます— naoya (@naoya_ito) 2023年10月4日 ちなみにフロントエンドも、旧バージョンは Nuxt v2
宿泊の管理システムについて 新しい管理システムについて 開発初期のフロントエンド設計 コンポーネントは4レイヤー方式を採用 UIのコンポーネントライブラリを採用 これ以上の設計、方針は決めなかった 初期ローンチ後の課題 改善した内容 1. コンポーネント設計の見直し ディレクトリ構成の変更 大きくなったコンポーネントの分割 Fragment Colocationを導入してコンポーネントのインターフェースとFragmentを整理 2. 業務処理(composables)の分割 3. 型安全に開発できるように厳しいlint設定に変更 4. 秩序を保てる開発体制、ドキュメントの整備 現在と今後 今後やりたいこと 改善を継続するためのポイント まとめ おわりに 宿泊プロダクト開発部の田中(id:kentana20)です。 このエントリーは一休.com Advent Calendar 2023の14
宿泊開発チームでエンジニアをしている @kosuke1012 です。チームで ADR を書き始めて1年くらい経ったので、その感想を書いてみたいと思います。 この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita の13日目の記事です。 ADRとは アーキテクチャ・ディシジョン・レコードの略で、アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録していくものです。 出典はこちらで、 Documenting Architecture Decisions わかりやすい和訳は以下の記事が、 アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト アーキテクチャの「なぜ?」を記録する!ADRってなんぞや? #設計 -
こんにちは。宿泊開発チームの菊地です! このエントリは 一休.com Advent Calendar 2023 12日目の記事です。昨日は id:rotom によるSlack Enterprise Grid における情報バリアの設計でした。その他の素敵なエントリも以下のリンクからご覧ください。 qiita.com 私はEmbulkを使って、各プロダクトの請求データを集約する機能を担当しました。今回は、Embulkの紹介とふりかえりをしていきたいと思います! 背景 課題 解決策 Embulkとは? 今回の課題に対してEmbulkがマッチした理由 union: 複数のデータソースを連結する config.ymlの記述例 lookup: 複数のデータソースを結合する config.ymlの記述例 ふりかえり とくに良かったこと config.ymlの取り回しのよさが開発スピードをあげてくれた c
この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita 10日目の記事です。 昨今は Web アプリケーション開発の世界でも、関数型プログラミングのエッセンスを取り入れるような機会が増えてきました。 とはいえ、一つのアプリケーションを 1 から 10 までがっちり関数型プログラミングで構成するというわけではなく、そのように書くこともあればそうでない従来からの手続き的スタイルで書くところもあるというのが現状で、どこまで関数型プログラミング的な手法を取り入れるかその塩梅もまちまちだと思います。まだ今はその過渡期という印象も受けます。 本稿ではこの辺りを少々考察してみたいと思います。 先日、Qiita Conference 2023 Autumn で以下のテーマで発表を行いました。 この発表では「関数型プログラミング最強!」という話をしたわけではなく、
この記事は 一休.com Advent Calendar 2023 6日目の記事です。 一休レストランの開発チームでエンジニアをしている香西です。 今回は Solr クエリの速度改善についてお話します。 背景 2023年10月、一休レストランのスマートフォン用 レストラン詳細ページをリニューアルしました! UI/UX の見直しとともに、使用技術も一新しました。 バックエンド言語:Python から Rustへ フロントエンドフレームワーク:Nuxt.js から Next.jsへ*1 スマートフォン用 レストラン詳細ページ 課題 「日付を選ぶカレンダーの表示が遅い」 社内限定リリースの直後、多方面からこの声が聞こえてきました... レストランへ行く日付を選ぶカレンダーは予約フローの第一ステップなので、表示速度が遅いことは致命的です。 特に、設定データ(料理のコース種類・席の種類など)が多いレ
次のページ
このページを最初にブックマークしてみませんか?
『一休.com Developers Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く