このエントリーは 一休.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 で、新バージョンは Next.js です。一休レストラン React に寄せることに決めました。React Server Component を使った実装になっており、こちらも後者の方が体感速度は速いと思います。 — naoya (@naoya_ito) 2023年10月5日 あらためてリニューアルでの技術的な変更点を再掲すると： バックエンド言語：Python から Rust へ フロントエンドフレームワーク：Nuxt v2 から Next.js App Router へ つまり、このエントリは先日リリースしたばかりの Next.js から Remix に乗り換えた、という話になります。 図らずも、昨今盛り上がっている Next.js 論争 *2 に足を踏み入れることになりました。 Next.js App Router について まずは disclaimer として、あくまで一休レストランにおいて Next.js App Router が "not for us" であっただけで Next.js そのものに対する評価ではないことは申し添えておきます。 その上で、ここでは Next.js App Router を採用した経緯と、実際に採用してみてどんな課題に遭遇したのかを簡単に説明したいと思います。 当初 Next.js を採用した経緯 採用を決めたのは Next.js 13 の発表直後、一休レストランのリニューアル計画が動きはじめた頃になります。 以下が主に評価した点ですが、 メタフレームワークとしてデファクトスタンダードとしての地歩を固めつつあったこと 弊社内の別プロダクトで Next.js (Pages Router) の採用実績が複数あること そして toC サービスである一休レストランにとって、カリカリにチューニングできそうな React Server Component が非常に魅力的なフィーチャーであったこと 特に最後の React Server Component が採用の決め手となりました。 先日の Next.js 14 で発表された Partial Prerendering もそうですが、toC サービスの欲しい機能をピンポイントに突いてくるニクいフレームワークです。 Next.js の Pain Points そもそも今回のリニューアルにおけるビジネス上のゴールは、一休レストランで予約するとき、お店に電話をかけたときのようなスムーズな体験を提供する、というものでした。 しかし、社内レビューや canary release の過程で見つかったユーザー体験の問題を改善するにあたって、Next.js App Router では実現が難しそうな課題がいくつか見つかってきました。 History API の state を触れない リニューアルしたスマートフォン版一休レストランは以下のような画面遷移になります。 レストラン詳細ページ 空席確認カレンダーモーダル 人数・日時を選択する空席確認カレンダーのモーダル表示がポイントです。 *3 ここでの選択は予約にいたるまでの一連の流れのワンステップなので、操作中はブラウザの「戻る」やリロードで開いた状態を維持したいモーダルです。 ただ、その状態で URL が LINE などで共有されたときは、モーダルのない詳細ページが開いて欲しい場面でもあります。 Next.js App Router の Link コンポーネントや useRouter フックでは History API の state を操作することはできず、URL を変更せずにブラウザ履歴を積んだ上で画面表示を変更することができません。 Cache-Control ヘッダを自由に設定できない Next.js App Router では Cache-Control ヘッダは Dynamic Functions が利用されたかどうかと Route Segment Config で設定した値を元に Next.js 自身が出力する仕様となっており、利用者が自由に値を設定することはできません。 例えば searchParams を参照しただけで Dynamic Functions と判定され、強制的に Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate が出力されてしまいます。 Fastly を CDN として利用している一休では、 Cache-Control ヘッダを制御できない *4 という制限は、パフォーマンスやインフラ負荷に影響を与える大きな問題です。 また、レストラン詳細ページ以降のページだけが今回のリニューアル範囲のため、 bfcache が無効になってしまうのも、既存ページとの遷移でユーザー体験に悪影響を及ぼします。 継続的なアップデートに懸念を覚えた Next.js のパッチバージョンを上げたときに production build でだけ 500 エラーが発生するという問題に幾度か苦しめられました。 App Router で運用している世界の様々なサイトで同じ問題が発生していたら大きな Issue になっているはずで、一休レストランのコード、もしくは利用ライブラリのいずれかに原因があったことには間違いないとは思います。 現象の再現状況の特定が難しく、加えて調査に十分なリソースを割けなかったという背景もありましたが、正確な原因が掴めず仕舞いとなってしまったことには歯痒い思いとともに、懸念が残りました。 Remix への乗り換え 上記の課題を解決するため、最終的には Remix に乗り換えることを決定しました。 Remix を採用した理由 Next.js App Router で抱えていた課題の裏返しになるのですが、そもそもの Remix の設計指針である、 Web 標準 API を尊重している点 *5 を特に重視しました。 History API 改善したかったクライアントサイドのナビゲーションを例に取ると、Remix の提供している Link コンポーネントや useNavigate フックは History API *6 の薄い wrapper になっていて state を利用することが可能です。 具体的には、Remix 自身もスクロール位置の維持をはじめとするクライアントサイドナビゲーションの管理に History API state を利用していて、Remix API で利用者が指定した state は History API state では、 { " usr ": { " state ": [ " set ", " from ", " Remix API " ]} , " key ": " dgfkntlh ", " idx ": 2 } 上記の例のように Remix が定義する History state の構造の中の "usr" キーの中に格納されます。 この構造を理解していれば、直接 History API replaceState を呼ぶことで Remix の遷移は抑止しつつ state だけを置き換えるような運用も実現できます。 Cache-Control ヘッダ Next.js Pages Router の getServerSideProps に相当する Remix の機能に loader があります。 loader の引数や返り値は Web 標準の Request / Response なので Cache-Control にも出力したかった値を設定でき、CDN やブラウザキャッシュをコントロールする自由を取り戻しました。 その他 他にも Next.js App Router の Async Server Component に相当する効果 *7 が得られる defer など、toC サービスである一休レストランにとって魅力的な機能を備えています。 検討した代替案 Remix 以外に検討した対策についても簡単にご紹介します。 Next.js に patch をあてる Cache-Control ヘッダの問題は Next.js の設計方針そのものでどうしようもないので、 pnpm patch でヘッダを出力している Next.js の当該コードを上書きしてしまう対策 *8 も試しました。 ですが Cache-Control を制御したい path が増える度に patch を更新するのは手間がかかって煩わしいし、ヘッダを書き換えられるようになるだけで、ナビゲーション問題は解決できません。 Pages Router への切り替え Pages Router への切り替えも少しだけ検討しました。 一休の他プロダクトで Pages Router の実績はあるので安定性に不安はありませんが、React Server Component に期待したパフォーマンス面はあまり期待できそうにありません。 *9 また Vercel の開発リソースも App Router にほぼ向けられているだろうし、現時点において Pages Router を選択するのは将来性も見込めないと判断しました。 Remix 置き換えで得られた効果 ちょうど Remix 版をリリースして一週間経過したところですが、以下のような効果が得られています。 継続的なアップデート 2023-12-18 追記 つい先日の 12/14 にリリースされたばかりの Remix 2.4.0 まで、問題なく追随できていることをご報告しておきます。 Fastly の cache hit ratio が 63% → 68% に 置き換えの目的の内の一つである CDN とブラウザキャッシュの有効活用です。 背景で紹介していますが、リニューアル対象はスマートフォン用のレストラン詳細ページ以降のみで、一休レストラン全体から見れば、ごく限られた範囲でしかありません。 にも関わらず、一休レストラン全体の cache hit ratio を 5% ポイント近く向上させることができました。 インフラの効率化もさることながら、Fastly のキャッシュから返ってくるときのレスポンス速度は圧倒的に高速なので、ユーザー体験を向上させる改善に繋がったことが何よりも嬉しい成果です。 Cloud Run の効率化 ここは意図していませんでしたが Remix 乗り換えで得られた嬉しい副作用です。 メモリ使用量が 1/4 に Cloud Run Memory Utilization グラフの通りメモリ使用量が 1/4 に減りました。 一休レストランは夕方から夜にかけてアクセスのピークを迎えるのですが、その間も安定して同じ水準を保っています。 コンテナ起動時間が 1/2 に Cloud Run Startup Latency Next.js では 20 秒強かかっていたコンテナ起動時間が 10 秒に縮まりました。 Next.js 時代からの課題ですが、ローカルでは一瞬で起動するのに、Cloud Run だと起動に時間がかかってしまう問題は調査中です。 所感と最近の議論 Remix に乗り換えての 個人的な 所感になりますが、Web 標準 API がそのまま使えて、利用者が思った通りにコントロールできる非常に扱いやすいフレームワークだと感じています。 上記はあくまで私の印象になるので、最近の Next.js の議論で特に参考にさせていただいたリソースを紹介します。 Why I Won't Use Next.js Next.js 論争の火種になった Kent C. Dodds の記事 Why I'm Using Next.js Kent C. Dodds の記事に対する Lee Robinson によるアンサー記事 Mozaic.fm ep135 Monthly Ecosystem 202311 Next.js 14 や上記の議論について Next.js App Router での MPA フロントエンド刷新 サイボウズさんの App Router 導入知見。所感が趣き深い。 しずかなインターネットの技術構成 Zenn の作者でも知られる catnose さんの記事。App Router を見送った理由を参照されたい。 今後の展望 現時点ではまだ Remix に置き換えただけで、ようやく改善のための足回りが整った、という段階です。 引き続きよりよいユーザー体験を目指して、本丸のナビゲーションの改善、CDN キャッシュ効率向上によるレスポンスの高速化を進めていきたいと思います。 おわりに 今回の一休レストランの問題だけでなく、フロントエンド領域で難しい課題をまだまだ抱えています。 一休では、事業の成功を技術面からともに支える仲間を募集しています。 www.ikyu.co.jp まずはカジュアル面談からお気軽にご応募ください! hrmos.co *1 : 同じ一休レストランフロントエンドのリアーキテクトの一環で XState を導入した話は 22日目の記事 でご紹介しています。 *2 : 後段で紹介します。 *3 : カレンダーの状態管理についての紆余曲折については 22日目の XState の記事 で紹介しているので、ご笑覧いただければ幸いです。 *4 : Fastly のキャッシュ制御は Surrogate-Control ヘッダで、ブラウザキャッシュのための Cache-Control ヘッダは VCL など他の手段で上書きすることはできますが... *5 : Remix サイトのトップページ に "Focused on web standards and modern web app UX" と掲げられています。 *6 : Navigation API が早く普及して欲しい... *7 : 正確に述べると fetch 処理は loader に一元化して Promise を defer を使って返す必要があります。 *8 : この問題は他の利用者も困っているようで Next.js の Issue 内に patch をあてる workaround が紹介されています。 *9 : Remix 公式ブログの Next.js との比較記事 で詳解されていますが Pages Router と比較すると Remix に軍配があがるようです。

宿泊の管理システムについて 新しい管理システムについて 開発初期のフロントエンド設計 コンポーネントは4レイヤー方式を採用 UIのコンポーネントライブラリを採用 これ以上の設計、方針は決めなかった 初期ローンチ後の課題 改善した内容 1. コンポーネント設計の見直し ディレクトリ構成の変更 大きくなったコンポーネントの分割 Fragment Colocationを導入してコンポーネントのインターフェースとFragmentを整理 2. 業務処理（composables）の分割 3. 型安全に開発できるように厳しいlint設定に変更 4. 秩序を保てる開発体制、ドキュメントの整備 現在と今後 今後やりたいこと 改善を継続するためのポイント まとめ おわりに 宿泊プロダクト開発部の田中（ id:kentana20 ）です。 このエントリーは 一休.com Advent Calendar 2023 の14日目の記事です。昨日は @kosuke1012 による ADR を1年間書いてみた感想 でした。このチームの活動に刺激を受けて、自分のチームでもADRを導入して現在も活用しています。 今回は自分が担当している一休.com宿泊の管理システムのフロントエンド設計について、この1年ほどで行った改善をお話します。 宿泊の管理システムについて 一休.com宿泊の管理システムは、一休社内とホテルの2面で構成されていて、利用者は一休の社内スタッフとホテルの担当者がおり、それぞれ以下のような業務に活用しています。 一休社内のスタッフ ホテルの作成、一休全体の予約の管理 など ホテル担当者 ホテル情報の管理、商品の在庫や料金設定 など 宿泊の管理システムイメージ 新しい管理システムについて 1年半ほど前から、この管理システムに大きめの機能追加をするプロジェクトが発足し、現在も続いています。 このプロジェクトは社内スタッフ向け、ホテル担当者向けの両面をカバーする必要があったのですが、新機能を開発をするにあたり 新機能は中長期での開発・運用を想定していること 既存システムで採用しているフレームワークやコードベースが古くなっており、新機能をスピーディに開発していくのに難があったこと 新機能は既存システムに依存せずに作れそうなこと などの点から、既存のシステムとは別に新システムをゼロから開発する方針を決めました。 新システムのテクノロジースタックは、先行して刷新をしていた一休.com、Yahoo!トラベルの画面に合わせる形で フロントエンド: Nuxt.js、TypeScript、Apollo Client、Tailwind CSS バックエンド: Go、GraphQL（gqlgen） という構成にしました。 Nuxt.jsについては開発開始時点ではRC版だったv3を採用しました。 開発初期のフロントエンド設計 コンポーネントは4レイヤー方式を採用 Components配下は pages features objects elements の4レイヤー構成を採用しており、各レイヤーの役割は以下のとおりです。 レイヤー 役割 具体例 再利用性 外部アクセス 反証 pages ページ固有のコンポーネント群 ページ固有の API アクセス、表示を担う ホテル管理ページ ✕ ◯ 複数ページで使われるもの features 機能を持った共通コンポーネント API アクセスをする グローバルヘッダー ◯ ◯ API アクセスをしない ページ固有の UI objects アプリケーション上の機能、デザインのひと固まりとなるコンポーネント サイドメニュー ◯ ✕ API アクセスをする ページ全体を実装 ボタンなどプリミティブな要素 elements HTML のサブセットとなるもっともプリミティブなコンポーネント アプリケーション全体の統一感に寄与するコンポーネント チェックボックス ボタン ◯ ✕ API アクセスをする 様々なコンポーネントを用いたデザイン状のかたまり この設計は一休.comのユーザー向けシステムに倣った形で、 Atomic Design と当時の一休レストランで採用していた ITCSSによるレイヤードアーキテクチャ をベースに、宿泊サービスの開発に合わせてカスタマイズした設計となっています。 実際の画面だと、こんな形で用途に応じて各レイヤーにコンポーネントを作成してUIの開発をしています。 コンポーネントのレイヤー例 UIのコンポーネントライブラリを採用 デザイナーがいないプロジェクト 一覧（テーブル）や入力フォームがよく登場する管理画面で一貫したUIを素早く提供したい という点から、Vue/Nuxtで利用できるUIコンポーネントライブラリとして、Alibabaグループが開発しているElementのVue3対応版であるElement Plusを採用しました。 A Vue 3 UI Framework | Element Plus 当時はVuetifyとElement Plusを比較検討したのですが フォームの画面ではVuetifyよりも書きやすい 当時のVuetifyはVue3サポートが完了していなかったがElement Plusは対応済（現在はVuetifyもVue3をサポートしています） Element Plusの方がTailwind CSSとの親和性が高い といった点からElement Plusを選択しました。 当時RCだったNuxt.js v3に対応したUIコンポーネントライブラリは多くありませんでしたが、現在は Vuetify や Quasar などのライブラリが対応しており、選択肢が広がっています これ以上の設計、方針は決めなかった ほかにも開発方針として コンポーネントの分割方針をどうするか Composition API（コンポーネントとロジックの分離）をどう活用するか 社内スタッフ向け、ホテル向けと2面ある管理画面のUIでコンポーネントを共用するのか など、初期に決めるべきことはたくさんあったのですが、機能開発をいち早く進めるためにこれらの方針を明確に定めずに開発を進めてしまいました。 振り返ると、これはとても良くない判断で、むしろ早く作るためにもっとじっくり設計や開発方針を練るべきだったと考えています。 初期ローンチ後の課題 2022年4月～9月 ... 初期開発 2022年12月～2023年3月 ... 大きめな機能追加 を経て、その後も機能追加や改善を続けていくことになったのですが、機能追加の際に以下のような課題を感じました。 新たにコンポーネントを開発する際に迷うことが多い コンポーネントのインターフェース（Props）をどう定義するか GraphQLのFragmentをどう使っていくべきか エラーメッセージをどこにどう書くか コードの見通しが良くない 入力項目が多いフォーム画面のロジックを扱うcomposablesが肥大化していて、見通しが悪い 型を厳密に扱えていない as, anyを使っている箇所があり、型の安全性を担保できていない記述がある これらを踏まえて、チームメンバーとも相談をした上で中長期で開発・運用していくためにフロントエンドの設計を改善することにしました。 改善した内容 宿泊事業を成長させるためのプロジェクトという前提があるため、ビジネスとして必要な機能追加をしながら、少しずつ以下の改善を行い、現在も継続しています。 1. コンポーネント設計の見直し ディレクトリ構成の変更 前述のコンポーネントレイヤーのうち、特にobjects配下にコンポーネントが多く存在しており、見通しが悪かったため、以下のルールで分別しました。 社内、ホテル、共通のコンポーネントを分別する構成に変更 ディレクトリ 役割 inside 一休社内スタッフ用の管理画面のみで使用するコンポーネント accommodations ホテル向けの管理画面のみで使用するコンポーネント shared 2つの管理画面で共用するコンポーネント 大きくなったコンポーネントの分割 大きいものになると1コンポーネントで1,000行に近いサイズになっていて、見通しが悪かったため 1コンポーネント350行程度を目安とする というガイドラインを定めてコンポーネントを分割しました。分割時にコンポーネントの依存関係を明確にするために、以下のルールで分割後に再配置をしました。 components └objects └inside └HotelDescription └HotelDescription.vue（親コンポーネント) └components ├child1/child1.vue（親コンポーネントのみで使う子コンポーネントその1） └child2/child2.vue（親コンポーネントのみで使う子コンポーネントその2） Fragment Colocationを導入してコンポーネントのインターフェースとFragmentを整理 改善前はルールを敷かずにFragmentによるGraphQLクエリの共通化をしていました。 以下はコード例です。 fragment HotelFragment on Hotel { id name description address rooms } // HotelFragmentを必要とするコンポーネント // idとdescriptionがあれば良いが他の情報も含んだFragmentをPropsとして要求してしまっている < template > < div > {{ id }} < /div > < div > {{ description }} < /div > < /template > < script setup lang = "ts" > interface Props { hotel: HotelFragment } < /script > これにより オーバーフェッチが発生していた *1 共通化しているFragmentの配置場所が定まっていない という課題があったため、Fragment Colocationを導入しました。 Fragmentによるデータの宣言を強制しているRelayの設計を参考に、以下のようなルールでコンポーネントのインターフェースとFragmentを扱うようにしています。 Fragmentファイルは利用するコンポーネントと同階層に配置する コンポーネントのインターフェース（Props）はFragmentの型で定義する Fragment名は「コンポーネント名 + GraphQLスキーマの型名」で命名する 改善後のファイル配置とコード例はこんな形です。 components └objects └inside └HotelDescription（コンポーネントのディレクトリ） ├HotelDescription.vue（ホテルの説明文を表示するコンポーネント) └HotelDescription_Hotel.frag.graphql（コンポーネントが利用するFragment） コンポーネントのインターフェース < script setup lang = "ts" > interface Props { hotel: HotelDescriptionHotelFragment } < /script > Fragment fragment HotelDescriptionHotel on Hotel { id description } プロジェクトで利用しているGraphQL Code GeneratorのClient PresetではFragment Maskingという機能が提供されていて、これによってFragmentで取得するフィールドは利用するコンポーネント以外からは参照できないように隠蔽化もできますが、まだこの機能は有効にしていません。 the-guild.dev 2. 業務処理（composables）の分割 Vue.jsのComposition APIの設計に沿って、コンポーネント内のロジックをcomposablesに書いていく方針で進めていましたが、入力内容が多いフォームの画面では 登録や変更処理などのふるまい フォームの初期状態 Validation などが1箇所に書かれており、記述量が多く見通しが悪くなっていました。 これを解決するために、ルートに lib/domain というディレクトリを設置して フォームの初期状態 Validation を分離する設計に変更しました。 lib └domain └Hotel ├HotelForm.ts └HoetlValidator.ts // HotelForm.ts export type HotelForm = { name?: Scalars [ 'String' ] description?: Scalars [ 'String' ] ... } // HotelValidator.ts export function useHotelValidator ( form: HotelForm ) { const descriptionCheck = ( description: string ) { // descriptionに対するチェック処理 } const rules = computed < FormRules >(() => { return { description: [ { validator: descriptionCheck , trigger: 'change' , } , ] , } } ) return { rules , } } // composables export function useHotel () { // HotelFormの初期化 const hotelForm: HotelForm = reactive ( { name: undefined , description: undefined , } ) // Hotelに関する業務処理 ... return { validationRules: useHotelValidator ( form ) .rules , } // validationを使うFormを持つVueコンポーネント < template > < Form :model = "form" :rules = "validationRules" > ... < /Form > < /template > < script setup lang = "ts" > import { useHotel } from './composables' const { form , validationRules , } = useHotel () < /script > 3. 型安全に開発できるように厳しいlint設定に変更 初期開発時はeslint, prettierによるコードフォーマット、型検査は導入していましたが、非nullアサーション（!）や型アサーションによるasやany型の利用を制限していませんでした。 この結果、本来は型ガードやアサーション関数を使って型を保証するべきところを!, asを使ってコンパイルエラーを回避したり、any型を不用意に使うケースが出てきてしまいました。 （以下でもasやanyの危険性について語られていて、TypeScriptによる型の安全性を享受するために避けるべき、と書かれています） 敗北者のTypeScript #TypeScript - Qiita これを踏まえて 非nullアサーション 型アサーション any型 の利用箇所を撲滅してlintで制限することにしました。小さい単位で作業を分割して進められるように 修正対象箇所がわかるようにwarningを出すようにlintを変更 地道にwarningが出なくなるように書き換え warningがなくなったらlint設定を変更してerrorにしてCIで止まるようにする というステップで作業を実施しました。 asの撲滅のためのpull request CIで止まるようにlintでエラーになるようにするpull request 非nullアサーションは完全に撲滅できましたが、型アサーションとanyの利用は改善の途中です。 4. 秩序を保てる開発体制、ドキュメントの整備 1~3でだいぶコードに秩序がある状態になりましたが、今後の開発によって悪化しないように以下を実施しました。 コードレビューの強化 CODEOWNERによるレビューを必須にして、定めた設計方針に沿った内容になっているかを識者がレビューする体制に docs.github.com ドキュメントの整備 コンポーネントのレイヤーと役割、Fragmentの利用方針、スタイルガイドなどをリポジトリのWikiにまとめて開発やレビューでの指摘に活用 Wiki（抜粋） 現在と今後 これらを積み重ねた結果 components配下はかなり見通しがよくなり、秩序がある状態になった 設計・開発をする際の指針ができており、レビューも指摘しやすくなった など、改善の効果を感じています。先月末～現在にかけて、新機能を開発しているのですが、フロントエンドの開発はとてもスムーズで、迷うことがほぼなくなってきました。 今後やりたいこと 引き続きプロジェクトを進めながら改善を続ける状態を維持したいと思っています。 具体的に考えている大きめの改善テーマとしては @Vue/apollo（@vue/apollo-composable）の脱却 v4のβ期間が長く、バージョンアップによって意図しない不具合が入ったことがあるため、別のGraphQLクライアントへの変更を検討中 E2Eテストの整備 機能追加・変更時のリグレッションテストを効率的に行うため、Playwrightを導入してE2Eテストを整備、CIに組み込む予定で改善中 などがあります。 改善を継続するためのポイント プロジェクトで開発する際に違和感を感じたら、熱量があるうちにIssueにする（コードレビューや開発しながらやるとよい） 上がったIssueを開発者で議論・認識合わせをしておく 機能開発とセットで改善することを常に考える 改善のネタを常に仕込んでおいて、機能開発をする際に「あ、あれ一緒にやりません？」みたいな形で組み込んで機能追加とシステム改善を同時にやっていくのが理想だと考えています。 まとめ 一休.com宿泊の管理画面のフロントエンド設計について、開発初期から現在までの変遷と今後について紹介しました。 本来は開発初期に決めておくべき内容を決めなかったことでローンチ後に改善することになってしまいましたが、まだシステムが大きくないタイミングで改善を進められたことは良かったと思っています。 一緒に改善を進めてくれているチームメンバーにとても感謝しています。 今後もこのシステムで 大きなビジネス成果につなげる 中長期で開発・運用していけるシステムにする を両立してやっていけるように、引き続きやっていきたいと思います。 おわりに 一休では、技術的にも妥協せず、事業の成果をともに目指せる仲間を募集しています。 www.ikyu.co.jp まずはカジュアル面談からお気軽にご応募ください! hrmos.co 明日はtak-ondaの「一休レストランで Next.js App Router から Remix に乗り換えた話」です。お楽しみに! *1 : Apollo Clientのキャッシュや、GraphQLサーバのLoaderによって発生しないケースもあります

宿泊開発チームでエンジニアをしている @kosuke1012 です。チームで ADR を書き始めて1年くらい経ったので、その感想を書いてみたいと思います。 この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita の13日目の記事です。 ADRとは アーキテクチャ・ディシジョン・レコードの略で、アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録していくものです。 出典はこちらで、 Documenting Architecture Decisions わかりやすい和訳は以下の記事が、 アーキテクチャ決定レコードの概要  |  Cloud アーキテクチャ センター  |  Google Cloud アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ #設計 - Qiita 事例は以下の記事が分かりやすかったです。 〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録 - スタディサプリ Product Team Blog ADRを導入したねらい 機能を追加したり改修したりする際は、チーム外のメンバー含む様々な人との議論を経て、仕様やアーキテクチャが決定されていくと思います。 そうした議論を経た最終的な決定は実際のプロダクトやアーキテクチャ図などに表現されるのですが、「どうしてそのような仕様やアーキテクチャになっているのか」と言った部分を後から知りたくなったりすることがありました。 これは ADR で解決したい課題そのものと言って良いものなので、チームで ADR を書いていってみよう！という話になりました。 採用したフォーマット いろいろなフォーマットがあるようなのですが、まずは以下のようなフォーマットで記載しました。 # タイトル タイトルには、一目で論点がわかるタイトルを記載します。可能な限り具体的で、それでいて簡潔なタイトルを心がけると良さそうです。（これが難しい） # ステータス draft, proposed, accepted, rejected, deprecated, superseded 原典のフォーマットには draft はありませんが、この段階で決定を除いて記載しておいて、MTG で決定みたいに進めたいシチュエーションがあったので、追加してみました。 proposed で一旦完成で、チーム（またはチーム間）で合意ができたら accepted にするのが良いかと思います。 別な議論などで決定が覆された場合、当該 ADR の決定を修正するのではなく、当該 ADR (ADR: 1 とする) のステータスを ( rejected: ADR: 2 に伴い ) とした上で、別途新しく ADR を起こし ( ADR: 2 とする )、そのステータスを (proposed: ADR: 1は破棄 ) などとすると良いです。 # コンテキスト コンテキストには、その ADR の決定が求められている背景や、対応案、対応案に対する評価を記載します。 # 決定 コンテキストを踏まえた決定を、受動的ではなく、肯定的かつ能動的に記載します。 # 影響 この決定の結果生じる影響を記載します。これは、決定の結果得られるメリットのほか、コンテキストで記載した対案を選択しなかった故のデメリットであったりも記載すると良いと思いました。 また、決定の結果、今後チームで意識しなければならないことであったり、改めて必要になる機能やその ADR を記載しても良いと思います。 Michael Nygard さんのフォーマット そのままに draft ステータスだけを追加しています。「ADR を書くときのコツ」の項で後述しますが、draft ステータスは結論が決まっていない段階で ADR を書くのに便利です。このフォーマットで1年運用してみましたが、必要十分だなという感じでした。 ADRの格納場所 私のチームではドキュメントシステムに Confluence を利用していたので、 ADR もそこに記載していきました。そのほかの選択肢としては、プロダクトの GitHub のリポジトリに置く案もあったのですが、そうするとプロダクトを横断する ADR や、具体的なプロダクトが決まっていない柔らかい段階での ADR の置き場に困ったりするので、 Confluence に落ち着きました。 ADR は自分たち以外のいくつかのチームでも書くようになったのですが、その管理方法はチームによりけりでした。 例えば GitHub Projects を利用したタスク管理 - 一休.com Developers Blog のチームでは、ADR 専用のリポジトリを作った上で、GitHub Issues に記載していったようでした。これなら先述の問題はクリアできています。 プロジェクト管理に GitHub Projects を用いている場合は GitHub に一元化することが出来て相性も良いため、GitHub Issues に記載していく方法が良いかもです。 書いてみたADRの例 個々のADR ADRに番号を振ってプロダクトや案件ごとにまとめています 書いてみてよかったところ ADR を書いてみてよかったことをいくつか書いてみます。 1. 「ここの設計どうしてこうなってたんだっけ？」に困らない ADR を書いた1番のモチベーションです。これが解消するのは非常に助かりました。自チームだけではなく、他チームが困っているときに「ｽｯ…」と ADR をスマートに差し出すこともできました。 2. 議論の効率が上がる 以下の複数のポイントで、開発する中での議論の効率が上がりました。 議論が蒸し返らない 1.とも重なるのですが、議論になるような仕様上/設計上のポイントでその背景を思い出すのに手間取ったり、（新事実が見つからない限りは）「やっぱりこっちの方がいいのでは」みたいな話にならないので、議論の効率が上がります。 意思決定するべきことが明確になる 「ADR を書くときのコツ」項で後述するのですが、あらかじめ draft の状態で ADR を記載しておくことで、意思決定しなければいけない項目が明確になり、議論の中であいまいにせず意思決定するようになり、議論の効率が上がります。 意思決定したことが明確になる ADR を導入してから、MTG の最後に「hoge の件 ADR に書いておきましょう」といった会話が増えました。これによって、意思決定したことをクリアに言語化することになり、議論の効率が上がります。 仕様検討～決定までのフレームワークができる チームで議論が必要になった際に「じゃ、ADR 書いてまとめておきましょう」という流れができるのが結構良く、検討の中心となるメンバーが増えたり変わったりしてもフレームワークに沿って進めることで議論のレベルを保ちやすくなります。 3. 新規メンバーが立ち上がりやすくなる 新しく参画したメンバーが疑問に思うであろうポイントに ADR があるケースが多いので、キャッチアップしやすいという意見も上がりました。 ADR を書くときのコツ 良い ADR を書くのには割とコツがあることがわかってきたので、気づいた点を書いてみます。 1. タイトルは体言止めにせず、文にする 「hoge について」や「hoge の設計」など、体言止めにするのではなく、「hoge は fuga とする」といったように、タイトルを文にします。 こうすると、タイトルをみるだけで内容が一発でわかるほか、ADR を書く際にも論点がクリアになり、記載や議論の効率があがりました。 2. 結論が決まっていなくても ADR を書きはじめてしまう 結論が決まっていない段階であっても ADR を書きはじめることで、何を決める必要があるのかが明確になってよかったです。 未定のところは実際に hoge などと書いておいて、それを元に議論して、決定事項で hoge を埋める感じです。 3. コンテキストを SCQA フォーマットで書く コンテキストの章で、結論に至るまでのギャップをいかに埋めるかというのが大切なのですが、これが慣れるまで結構難しいです。 その際のフォーマットとして、SCQA というのが有用でした。『考える・書く技術』という本で紹介されているフォーマットなのですが、 S: Situation 状況 C: Complication 複雑化 Q: Question 疑問 A: Answer 答え Situation でまず状況の説明をして、それに続く Complication で、今回の Question やその Answer が必要になるトリガーを説明します。 www.diamond.co.jp 上で記載した ADR の例で行くと、 S: (Slack リンク) での記載の通り、未付与のトランザクションに対して、PayPayの取消が発生することは考えられる。 C ~ Q : この場合に、 1. 新たに取消トランザクションを作成した上で、新規と取消のトランザクションを見て付与取消バッチに判断してもらうのか 2. 既存のトランザクションを論理削除するのか の2通りの対応がありうるが、どちらにするか。 1.のメリットとしては、 ... などのメリットがある一方で、 ... というデメリットはある。 のような感じです。 このフレームワークは、ADRに限らず、割と複雑な PR の Description を書く際にも有用だなと思いました。 ちなみに SCQA フォーマットは『スタッフエンジニア』という本でも紹介されていて（私もそれで知りました）、 曰く、 多くの議論で、冒頭の段落が巧みに構成されているだけで重要な対話に火が灯る。 だそうです。シビれますね。 bookplus.nikkei.com 4. コンテキストに、もうほぼ結論の手前まで書いてしまう 前述の通り、コンテキストで背景の共有 → 問題意識の共有、と進めた上で「決定」の項目で結論を書くのですが、コンテキストにどこまで書くかというのが悩みどころです。 これは好みもありますが、もうほぼほぼ結論の手前まで「コンテキスト」の項目に書いてしまえば良いと思いました。 コンテキストで結論の手前まで書いた結果、読み手が「決定」を読んだ感想としては『でしょうね～』となるくらいまで書いてしまって良いのではないかなと思います。 5. とにかく軽量にする 優先順位として、 開発する中での重要な意思決定の記録を漏らさないこと > リッチな ADR を書くこと として、1つ1つの ADR を軽量にして、記載するハードルを下げることを意識すると良さそうです。 1つ1つの ADR にあまり力を入れすぎると、だんだんと書かなくなっていってしまうことがありました。 6. アーキテクチャに限らず、仕様上の決定も ADR に記載していく ADR はアーキテクチャ以外の決定の記録にも有用でした。それらの決定が、アーキテクチャ上の決定に影響を与えることもあるため、同じ ADR として並べて管理しておくと便利でした。 ADR では足りないところ ここまで説明してきた ADR ですが、それだけでは足りないなと思う部分もありました。 検討する単位が大きいものを1つのADRで書こうとするのは厳しい 「hogehoge の仕様検討、といった粒度のものを一つの ADR がチームで出てきたのですが、決める論点が多かったり、発散したりしてしまってあまりうまくいかなかった」という意見がありました。 「ADR を書くときのコツ」の項に「タイトルは体言止めにせず、文にする」「とにかく軽量にする」と記載しましたが、逆に言うと、これが出来ないようなテーマについては、ADR には向かないのではないかと思いました。 「全体として今どうなっているのか」を示すドキュメントはADR とは別にほしい ADR は、ここの意思決定やその背景を記述するドキュメントですが、それに加えて、やはり「全体として今どのような設計になっているのか」といったドキュメントは必要だなと思いました。いわゆる Design Docs がそれにあたると思います。 Design Docs があり、その個々の設計に至った意思決定やその背景がADRとして残されていると理想的なのではないかと思います。全体としての What を Design Docs に記載して、Why を ADR でサポートするイメージでしょうか。 Design Docs とのすみわけ Design Docs には、Why に答える項目を含めたフォーマットもあったりするので、チームの中で ADR と Design Docs のすみわけの指針がそろっていると良さそうです。一つの観点として「Design Docs が実装でのフィードバックに基づいて継続的に更新される性質を持ち、一方でADRはスナップショットである」という性質の違いがありそう、との意見が出ました。 以上から、Design Docs と ADR の性質の違いをまとめてみます。 反映するもの 時間軸 答える対象 Design Docs (特に実装以後) 実装 今 What ADR 意思決定 スナップショット Why 表中 Design Docs と ADR としてまとめていますが、必ずしもそれぞれのフォーマットでフルに記載する必要はないかもしれません。 例えば ADR はログの形で簡易的に記載していったり、逆に Design Docs も必要な部分だけ記載する、といった判断もあるかもしれません。 これらの項目があることを考慮しておくと、必要十分なドキュメントを用意していけるのではないかと思いました。 さいごに 一休では、ともに試行錯誤しながらよいサービスを作ってくれる仲間を募集しています！ www.ikyu.co.jp カジュアル面談も実施していますので、ぜひお気軽にご連絡ください！ hrmos.co

こんにちは。宿泊開発チームの菊地です！ このエントリは 一休.com Advent Calendar 2023 12日目の記事です。昨日は id:rotom による Slack Enterprise Grid における情報バリアの設計 でした。その他の素敵なエントリも以下のリンクからご覧ください。 qiita.com 私はEmbulkを使って、各プロダクトの請求データを集約する機能を担当しました。今回は、Embulkの紹介とふりかえりをしていきたいと思います！ 背景 課題 解決策 Embulkとは？ 今回の課題に対してEmbulkがマッチした理由 union: 複数のデータソースを連結する config.ymlの記述例 lookup: 複数のデータソースを結合する config.ymlの記述例 ふりかえり とくに良かったこと config.ymlの取り回しのよさが開発スピードをあげてくれた config.yml.liquidのサポート 注意したほうがいいこと 任意のクエリでlookupしたいときは、CSVを一度経由する必要がある GCSへのCSVアップロードプラグインにはstorage.objects.listが必要 まとめ 小ネタ：Embulkのメンテナンス体制が新しくなったとのこと！（2023年3月） さいごに 背景 一休では、これまでプロダクト毎に請求書発行機能が実装されていました。私のチームでは、2023年10月に施行されたインボイス制度 *1 の対応として、全プロダクトの請求書を適格請求書形式に改修することになりました。 今後法律が改正されることも考慮して、既存の実装を個別に修正するのではなく、請求書マイクロサービスに一元化して各プロダクトから利用するという方針を立てました。 課題 一休ではプロダクト毎に個別のDBを持っています。プロダクトによって採用しているDBMSも様々です。全プロダクトの請求書を発行するためには、個別に管理されているデータを統合する必要がありました。また社内向けに、複数DBをまたいだ情報を書き出したCSVの発行が求められていました。 これらの要件を満たすため、複数のデータソースからデータを集約して別のデータソースに出力する手法を検討しました。 解決策 この課題を解決するために、Embulkを使って各プロダクトのDBからデータを集約することにしました。 Embulkとは？ www.embulk.org Embulk is an Open-source Pluggable Bulk Data Loader to/from varieties of storages, file formats, databases, cloud services, and else. Embulkはあるデータソースからデータを吸い出し、別のデータソースへ転送するためのETLツールです。また、 Pluggable とあるように、Embulk本体は基本的な処理順序（inputプラグインを実行し、filterプラグインを実行し、outputプラグインを実行する）のみを制御しており、利用者は個々のユースケースに合わせたプラグイン *2 の組み合わせで処理を実現します。 簡単に動かしてみたい方は、embulkのコマンドでquick startが提供されていますので、試してみてください *3 。 embulk example { dir } 今回の課題に対してEmbulkがマッチした理由 Embulkでは、プラグインを組み合わせることで 複数データソースをまたいだ操作 が簡単に記述できます。今回の要件では、次の２つの操作ができることが非常に強力でした。 union: 複数のデータソースを連結する unionプラグイン を使うことで、複数のDBからのデータ取得処理を書くことができます。また、一休ではプロダクト毎にPostgresやSQL Serverなどの異なるDBMSを使っているため、適切なinputプラグインが異なります。union プラグインはソースとなる input もまたプラガブルになっており、任意の input プラグインを組み合わせられる自由度の高さも非常にありがたかったです。 config.ymlの記述例 in : type : union union : - name : product_hoge in : type : sqlserver url : product_hoge_jdbc_url user : product_hoge_db_user password : product_hoge_db_pwd query : | SELECT hoge_id AS common_id, amount, tax_fee FROM product_hoge_table filters : - type : column add_columns : - { name : product_code, type : string, default : "hoge" } - name : product_fuga in : type : postgresql host : product_fuga_db_host port : product_fuga_db_port user : product_fuga_db_user password : product_fuga_db_pwd database : product_fuga_db_name query : | SELECT fuga_id AS common_id, charge AS amount, tax_fee FROM product_fuga_table filters : - type : column add_columns : - { name : product_code, type : string, default : "fuga" } out : type : postgresql host : common_db_host user : common_db_user port : common_db_port password : common_db_pwd database : common_db_name table : common_table mode : merge merge_rule : [ "product_code = S.product_code" , "id = S.common_id" , "amount = S.amount" , "tax_fee = S.tax_fee" ] lookup: 複数のデータソースを結合する csv_lookupプラグイン を使うことで、DBから取得した情報に対し、CSV のデータを SQL の left join のような形で結合できます。このプラグインでデータベースと CSV を結合した帳票を得ることができました。処理自体も非常に軽量で、例えば、6,000件のDBレコードに対し18,000行のCSVをlookupしたCSVを発行するジョブは平均5分18秒で実行できました *4 。 config.ymlの記述例 exec : min_output_tasks : 1 in : type : sqlserver url : hoge_db_jdbc_url user : hoge_db_user password : hoge_db_pwd query : | SELECT hoge_key, hoge_col_1, hoge_col_2 FROM hoge_table filters : - type : csv_lookup mapping_from : - hoge_key mapping_to : - fuga_key new_columns : - { name : fuga_col_1, type : string } - { name : fuga_col_2, type : string } path_of_lookup_file : "ref/fuga.csv" out : type : file path_prefix : ./out file_ext : csv formatter : type : csv header_line : true charset : UTF-8 ふりかえり Embulkを導入し、予定通りにインボイス対応を完了することができました！実際に使ってみて得た知見をまとめます。 とくに良かったこと config.ymlの取り回しのよさが開発スピードをあげてくれた Embulkでデータ移送のジョブを6個、CSV発行のジョブを12個担当しましたが、慣れてからは1日1ジョブのペースで開発を進めることができました。Embulkはconfig.ymlにテンプレートにしたがってSQLやプラグインの実行を記述していくだけで、非常に取り回しがよかったのが開発速度を後押ししてくれました。 config.yml.liquidのサポート Embulkではconfig.ymlへの変数埋め込みのために、Liquidテンプレートをサポートしています *5 。たとえばunionプラグインを使ったconfig.ymlの記述例では、DB接続文字列を指定しています。 type : union union : - name : product_hoge in : type : sqlserver url : product_hoge_jdbc_url user : product_hoge_db_user password : product_hoge_db_pwd query : | SELECT col_1, col_2, col_3 FROM product_hoge_table しかし、実際にはDB接続文字列はリポジトリ管理すべき情報ではありませんし、構築環境ごとに専用DBに接続したいものです。そのため、Liquidテンプレートを使い、環境変数から以下のように接続文字列を読み込む実装にしました。 type : union union : - name : product_hoge in : type : sqlserver url : {{ env.HOGE_JDBC_URL }} user : {{ env.HOGE_DB_USER }} password : {{ env.HOGE_DB_PWD }} query : | SELECT col_1, col_2, col_3 FROM product_hoge_table 注意したほうがいいこと 任意のクエリでlookupしたいときは、CSVを一度経由する必要がある 先ほど、複数のデータソースを結合したCSVの生成に csv_lookupプラグイン を紹介しました。プラグイン一覧から、lookup 先にDB テーブルを直接参照できる {db}_lookup プラグインが提供されていることにお気づきの方もいるでしょう。 これらの {db}_lookup プラグインは設定ファイルで指定したテーブルとカラムから自動で lookup する仕組みになっていて、任意のクエリ（SELECT 文）は指定できません。 *6 。そのため、内部表をサブクエリにしたいケースではこのプラグインが利用できないことに注意が必要です。今回は回避策として、内部表の部分をローカルにCSV出力するEmbulkジョブを実行し、出力したCSVに対して csv_lookupプラグイン でlookupすることにしました。 GCSへのCSVアップロードプラグインにはstorage.objects.listが必要 社内向けにCSVを公開するため、Google Cloud Storageへ保存したいという要件がありました。当初は gcsプラグイン を利用して、Embulk内部でGCSへのアップロードまで実行しようと考えていましたが、実装してみると次のエラーが発生してしまいました。 Caused by: java.lang.RuntimeException: org.embulk.config.ConfigException: org.embulk.util.retryhelper.RetryGiveupException: com.google.cloud.storage.StorageException: {my_service_account}@{my_project}.iam.gserviceaccount.com does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist). ライブラリの内部実装を確認したところ、バケットの存在確認のためにObject Listを取得するようになっていたためでした *7 。今回は、なるべく最小のPermissionsに絞ったサービスアカウントを利用したかったため、ローカルに出力したCSVをgsutilでアップロードするスクリプトを組みました。 まとめ ここまで読んでいただきありがとうございました！使ってみて、EmbulkはPluginが豊富でとても強力なツールであることがわかりました！ETLや複数データソースをまたいだCSV生成を行う際には導入を検討してはいかがでしょうか。 小ネタ：Embulkのメンテナンス体制が新しくなったとのこと！（2023年3月） EmbulkはFluentdの開発者である古橋氏によって2015年に公開されました *8 。その後、氏が創設者であるTreasure Data社によって運用や設計の改善が行われてきましたが、2023年3月からは、社に限定せず広くコアチームを結成し設計検討を行っていく方針が発表されました *9 。その経緯については、Treasure Data社のTech Talk2022の発表資料にてより詳しくまとめられています。 イベント資料｜TreasureData Tech Talk 2022 - TECH PLAY［テックプレイ］ 業務としてのOSS開発のアンビバレンスなど、かなり実情に即した部分まで言及されており示唆に富んだ発表資料でした。私はOSS開発の経験はありませんが、事業会社でエンジニアリングを行ううえでビジネス優先度は常に考慮すべき観点ですので、非常に考えさせられました。 あらためて、OSSメンテナの皆様、いつもありがとうございます！ さいごに 一休では、ともに試行錯誤しながらよいサービスを作ってくれる仲間を募集しています！ www.ikyu.co.jp カジュアル面談も実施していますので、ぜひお気軽にご連絡ください hrmos.co *1 : インボイス制度の概要｜国税庁 *2 : List of Embulk Plugins by Category *3 : EmbulkでMySQLに大量データを投入してみる - その１ #MySQL - Qiita *4 : このケースはSQL自体がやや重かったり、後述の理由からEmbulkを内部で多重実行していますので本来はもっと早いと思います *5 : Embulk: Configuration *6 : GitHub - InfoObjects/embulk-filter-mssql_lookup *7 : embulk-output-gcs/src/main/java/org/embulk/output/gcs/GcsAuthentication.java at 427f9fdc677885a7467606393f6a343ceda2c4c9 · embulk/embulk-output-gcs · GitHub ] *8 : 並列データ転送ツール『Embulk』リリース！ - Blog by Sadayuki Furuhashi *9 : Embulk maintenance goes open | Embulk

はじめに Enterprise Grid 移行と課題 情報バリアとは 情報バリアの設計 IDPグループの作成 情報バリアの有効化 情報バリアの設定 実現 終わりに CM のお時間です はじめに 社内情報システム部 兼 CISO室 コーポレートエンジニア id:rotom です。一休のコーポレートIT・セキュリティ領域はだいたい全部見てます。 このエントリは 一休.com Advent Calendar 2023 11日目の記事です。昨日は id:naoya による TypeScriptでどこまで「関数型プログラミング」するか ─ 「手続き Haskell」から考察する でした。その他の素敵なエントリも以下のリンクからご覧ください。 qiita.com 一休は今年、全社利用しているコミュニケーションツールである Slack を Enterprise Grid へ移行しました。 Enterprise Grid はその名の通り大規模なエンタープライズ組織向けの管理機能・セキュリティ機能が拡充されたもので、他のプランとは大きく思想が異なります。 Enterprise Grid について取り上げたエントリは多くありますが、その中でも 「情報バリア」 について詳しく書かれた記事が無かったので、本エントリで解説します。 Enterprise Grid に関する詳細な説明はここでは割愛するので、公式ドキュメントをご覧いただくか、Slack サポートにお問い合わせください。 slack.com Enterprise Grid 移行と課題 一休ではエンジニアに限らず全ての従業員が Slack をコミュニケーションツールとして利用しています。 これまではビジネスプラスプランで利用してきましたが、監査ログや DLP などの機能を利用し、よりセキュリティ・コンプライアンス体制を強化するため、Enterprise Grid へ移行することにしました。 一休には従前、日常的に利用している一般のワークスペースと、機密情報を取り扱うワークスペースの2つのワークスペースが存在しました。 これらのワークスペースは完全に独立しており、機密情報は一般のワークスペースに持ち出すことができないよう厳しく統制されていました。 今回 Enterprise Grid に移行するにあたり、マルチワークスペースに対応することから、この2つのワークスペースは1つの OrG 配下に置くことにしました。 この際、仕様として OrG 配下のユーザーは、 自分が所属していないワークスペースのユーザーに対してもダイレクトメッセージやハドルミーティングが可能 です。 ワークスペース間でのダイレクトメッセージやハドルミーティングを禁止する設定は行えず、情報の持ち出しを防ぐために対策が必要でした。 情報バリアとは この問題を解決するために、Enterprise Grid の情報バリアという機能を利用しました。 Slack 管理者でもビジネスプラス以下のプランの方は聞いたことがない人も多いと思います。あるいは、既に Enterprise Grid で運用している組織でも利用していないことが多いかもしれません。 slack.com 簡単にまとめると、 特定の IDPグループ間でのダイレクトメッセージやハドルミーティングを禁止することができる機能 です。 また IDPグループという聞き慣れない用語が現れましたが、これは Okta や Microsoft Entra ID などの IdP（Identity Provider）のグループを Slack 上に連携させ、チャンネルやワークスペースと紐付けることができる Enterprise Grid の機能 です。 slack.com この機能を利用することで、擬似的にワークスペース間のダイレクトメッセージ・ハドルミーティングを禁止にすることができると考えました。 情報バリアの設計 ここからは実際に情報バリアの構築した手順を解説します。これから情報バリアの利用を開始しようとしている方は業務影響のない Sandbox 環境で検証してから設定することを推奨します。 IDPグループの作成 IdP として利用している Microsoft Entra ID 側に一般ワークスペース、機密情報ワークスペースそれぞれに所属するユーザーを追加したグループを用意します。 このグループは SCIM（System for Cross-domain Identity Management）により、対応する IDPグループを OrG 上に作成され、Microsoft Entra ID 側のグループに追加されたユーザーの Slack アカウントが自動的に追加されるようになります。 IDPグループは複数のワークスペースやチャンネルと接続することが可能ですが、今回の用途ではそれぞれのグループに対応するワークスペース1つずつに接続します。 これにより Microsoft Entra ID 側で対象のグループに追加されたメンバーは、自動的にワークスペースへ追加されます。 なお、IDPグループの名称変更やユーザーの追加・移動・削除は Slack OrG 管理画面の GUI 上は行えません。全て SCIM で連携されているので IdP 側で変更し、プロビジョニングする必要があります。 API による操作は可能なので必要に応じて SCIM API を利用して操作することは可能です。 情報バリアの有効化 情報バリアは標準で利用できないオプトイン機能なので、 OrG オーナーより Slack サポートチームに連絡をして有効化する必要 があります。 OrG 管理者やワークスペースのオーナーでもリクエストができないので、ご自身が OrG オーナーではない場合は OrG オーナーにリクエストを依頼してください。 リクエストは /feadback で「 {yourdomain}.enterprise.slack.com で情報バリアが利用できるように機能を有効化してください。」のよう送信すれば OK です。 機能が有効化されると OrG 管理コンソール > セキュリティ > 情報バリアの項目が開けるようになります。 情報バリアの設定 情報バリア内から「障壁を作成」ボタンを押すと情報バリアを作成することができます。なぜかここではバリアが障壁と訳されていますが、気にしないでください。 ここではプライマリーグループにIDPグループ（一般）、障壁の対象にIDPグループ（機密情報）を入力しました。対象は複数の IDP グループを指定することが可能です。 実現 ここまで設定が完了すると、IDPグループ間で情報バリアが作成されます。 別のワークスペースに所属するユーザーのダイレクトメッセージ画面を開くと、このようにポリシーによって送信ができない旨メッセージが表示され、送信ができなくなります。 情報バリアの設定は OrG 画面から設定後、即時反映されるわけではなく少しラグがありました。設定後は少し時間をおいてから動作確認を行うことをおすすめします。 これにより、IdP グループ間の情報バリアの設定で実質的にワークスペース間のダイレクトメッセージ・ハドルミーティングを禁止することができました。 終わりに Enterprise Grid への移行時に発生した課題と、情報バリアを使って解決した話を書きました。 要所のみ掻い摘んで記載しましたが、Enterprise Grid への移行は他の SaaS の シンプルなプランアップグレードではなく、イニシャルコストとダウンタイムを伴いながら環境を丸ごとお引越しする ことになるため、本件以外にも想定外の様々な課題があり、Slack（Salesforce）マネージャー / アーキテクトにサポートいただきながらプロジェクトを完遂できました。 個人的にはSlack 認定管理者試験で学んだ Enterprise Grid の知識を実践で活用することができ、今年最も成長できたプロジェクトのひとつだったと思っています。 私も Enterprise Grid 管理者 1年生なので内容に誤りや、もっと良い方法があるよ！といったご指摘 / ご助言があれば X や 情シス Slack などでご連絡いただけると嬉しいです。 CM のお時間です 一休では現在コーポレートエンジニアの採用は行っていませんが、ソフトウェアエンジニアをはじめ、多くの職種で積極的に採用を行っています。 選考をともなわないカジュアル面談からも受け付けておりますので、お気軽にご応募ください 👋 www.ikyu.co.jp 明日は id:Kikuch1 による 請求書発行のためにEmbulkを使って爆速でデータを集約した話 です

この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita 10日目の記事です。 昨今は Web アプリケーション開発の世界でも、関数型プログラミングのエッセンスを取り入れるような機会が増えてきました。 とはいえ、一つのアプリケーションを 1 から 10 までがっちり関数型プログラミングで構成するというわけではなく、そのように書くこともあればそうでない従来からの手続き的スタイルで書くところもあるというのが現状で、どこまで関数型プログラミング的な手法を取り入れるかその塩梅もまちまちだと思います。まだ今はその過渡期という印象も受けます。 本稿ではこの辺りを少々考察してみたいと思います。 先日、Qiita Conference 2023 Autumn で以下のテーマで発表を行いました。 この発表では「関数型プログラミング最強!」という話をしたわけではなく、プログラムを関数型で考えるというのはこれこれこういうメンタルモデルにもとづいていて、一方で手続き型で考えるというのはこういうメンタルモデルにもとづく、という整理をしました。 より具体的には 関数型プログラミング ··· 式によって計算を宣言し、関数を適用することで値を得る 手続き型 (命令型) プログラミング ··· 文によって計算機に対し命令を行う。命令によって状態を更新することで結果を得る と整理できるだろうという話をしました。 この発表の中で、蛇足的に以下のようなスライドを用意していました。 宣言的な記述はどちらかといえば純粋関数型的なパラダイムに基づくもの、命令的な記述は手続き的なパラダイムに基づくものと考えられる一方「純粋関数型言語」の Haskell はすべてのコードが宣言的になるかと思いきや、案外、手続き的な記述をすることもあるし、一度手続きを使うとそこから命令のコンテキスト以下は、手続き的なパラダイムに影響を受けることになります。 後に改めて触れますが、Haskell は「純粋関数型言語」としてのイメージが強いですが、上記のように、戻り値を戻さない (※ 実際にはユニット型を返してはいる) 手続き的なプログラミングが可能です。可能、というよりは、例えばミュータブルなデータ構造を更新したいときなどは、手続き的に書くのが自然です。 このように純粋関数型言語を使うにあたっても、関数型プログラミング / 手続き型プログラミングは一つのプログラムの中で混在する、混在していいものだということがわかります。 TypeScript でどこまで「関数型プログラミング」する? Haskell の話に触れましたが、普段は私のチームのプロダクトは GraphQL バックエンドも含めて TypeScript でアプリケーション開発を行っています。 この TypeScript でのバックエンド開発については TypeScript による GraphQL バックエンド開発 - Speaker Deck のスライドでも詳しく解説していますが、やや関数型プログラミングよりのスタイルで開発を続けています。 以下のスライドで、その雰囲気が少し伝わるかと思います。 アプリケーションを記述するにあたり各種関数は、基本的に値を返す「式」として定義します。 計算は場合によっては失敗に分岐することがありますが、失敗は Result 型によって表現します。例外をスローすることはしません。そして Result 型を返す関数の合成 ··· 上のスライドの andThen などによって計算のパイプラインを作って実行します。 「Result」はその名前だけを見ると計算の結果だけに関与する部分的な型にも見えますが、実際には Result を導入すると計算構造の構築に Result のもつ合成を使うのが基本になり、実装スタイルに大きな影響を与えます。 例外を使わず合成によって一連の処理を構成するため、基本的にそのロジックの過程では大域脱出しません。結果、計算の流れが一方通行になります。また、Result によりおきうる失敗が全て明示されており、型によってそれを無視したプログラミングはできないようになっています。この両者の制約によってより堅牢な実装が可能になっています。 こう書くと、この宣言的プログラミングのスタイルや Result はとても良いもので何のトレードオフもないものに思えるかもしれません。しかし、やはりそんなことはありません。制約がかかる以上「いや、そこは手続き的に書いたら簡単なのに」と思うことはよくありますし、値が Result に包まれているおかげで、中身の値が欲しいのにいちいちコンテナを意識して実装をしなければならなかったり、面倒ごともあります。 こうなってくるとやはり「たとえどんな場合でも宣言的に、関数型ライクに書くのが良いのか?」という疑問がもたげてきます。 開発当時は、チームでもそういう話題になることもよくありました。手続き的なプログラミングは極力避けて、常に関数型プログラミング的に書くべきなのか? どうなんでしょう? という疑問です。 手続きを Result のコンテキストに閉じる ··· neverthrow の fromPromise / fromThrowable ところで Result の実装には supermacro/neverthrow: Type-Safe Errors for JS & TypeScript というライブラリを使っています。 neverThrow には計算の合成に必要な基本的な関数が諸々定義されていますが、その中に一風変わった fromPromise や fromThrowable という関数があります。 その名の通り Promise (async / await も含む) や例外による大域脱出が使われている手続きを、Result のコンテナの中に閉じ込めるための関数です。これを使うことで、Result を返さないサードパーティのライブラリなども含めて、Result を使った自分たちの関数と合成することが可能になります。 視点を変えれば、この fromPromise や fromThrowable を使えば、Result を使いつつも、そのコンテキストの中では async / await を使ったり、例外を使ったりといった「作用のある手続き」を用いたプログラミングをすることができる... というわけです。 例えば以下は実際のプロダクションのコードの中にある、一部の実装です。 これは内部的なマイクロサービスへの HTTP リクエストのための関数ですが、相手側のサービスに無駄なリクエストを投げすぎないよう Redis にキャッシュさせながら問い合わせを行う、という実装になっています。Redist へのアクセスは keyv を使います。 非同期 IO で、かつ Redis を間に挟みながらオリジンの HTTP サーバーへのアクセスを行う実装です。昨今の Web アプリケーション開発ではよくある典型的な実装ですが、これを Result の合成で宣言的に書こうとすると Result が多段になりかなり面倒な実装になってしまいます。 そこで、手続きの流れは普段通り手続き的に async / await で書きつつ、その関数を前述の fromPromise によって Result のコンテキストに包みます。これで「手続き的に書いた方が良い場面ではそうする」ことができます。 const restoreAccessToken = ({ keyv, key, requestFunc } : { keyv : Keyv; key : string; requestFunc : requestAccessToken }) => (requestArgs : requestAccessTokenArgs) : ReturnType < requestAccessToken > => { const promise = async () => { // キャッシュを検索 const value = await keyv . get(key) if (value) return { access_token : value as string, expires_in : 0 , token_type : 'Bearer' as const, } // キャッシュになかったらリクエストする return requestFunc(requestArgs) . match( (response) => { // キャッシュに格納 keyv . set( key, response . access_token, (response . expires_in - 600 ) * 1000 ) return response }, (error) => { throw error } ) } // fromPromise で Result に包む。エラーの型が unknown になってしまうのに注意 return fromPromise(promise(), (error : unknown) => error instanceof AuthenticationError || error instanceof ValidationError || error instanceof NetworkError ? error : new NetworkError(error as string) ) } このように全てを Result を使って関数型/宣言的に··· とするのではなく、非同期 IO が絡み合う箇所など、手続的に書く方がシンプルに書けるということもよくあるわけです。 関数型プログラミングに固執せず、手続き的に書けばいい時はそうすればいい、ということになります。じゃあその「手続き的に書けばいいとき」というのは一体どういう時なんでしょうか?　こういうときはなかなか、TypeScript だけをやっていてもよくわかりません。 そこで他の言語、手続きも書ける純粋関数型言語 Haskell ではどのような考えに基づいてみんな実装しているのか、その例を少し見てみることで相対化してみましょう。ただし当然この短い記事で全部を見ることはできません。いくつかの典型例に着目して見ていくことにしましょう。 Haskell でも手続き型で記述するケース 先述の通り Haskell は「純粋関数型」言語ですが、純粋関数型即ち関数型でしか書けないわけではなく実際には手続き型で記述することもよくあります。むしろ積極的に手続きを使う場面もあります。 なお、手続きHaskellについては、以下の書籍がおすすめです。30ページほどの薄い本なので、さっと読めます。 booth.pm IO を行いたいとき IO というのは外界の世界とのやり取りを、計算機に命令する手続きだと考えられます。「計算機に命令する」のですから、自然と手続き型 (命令型) のコードを書くことになります。 main :: IO () main = do name <- getLine putStrLn ( "Hello, " ++ name) 見ての通り putStrLn からは戻り値を受け取っていません。つまり「文」に相当する記述になっています。 厳密には putStrLn は文ではなく IO () 型の値を返す式です。他の返値を受け取らない式も同様なのですが、ここでは説明のため手続き型プログラミングでいうところの文相当だと思ってください。 ところで main の後ろに do という記述があります。何気ない記述ですが、これこそが Haskell の手続きプログラミングを可能にするものです。 上記を do 記法を使わずに記述することもできるわけですが、 main = getLine >>= ( \ name -> return ( "Hello, " ++ name)) >>= putStrLn その場合 Monad 型のバインド演算子 >>= を使って関数合成で記述することになります。 getLine 関数によって端末からの入力値を受け取ることができますが、それは外界からやってきた値であり、IO 型のコンテナに入っています。それを扱うため、上記のような少し変わった記述が必要になります。 do 記法はこのイディオムを逐次で記述できるようにするシンタックスシュガーです。つまり上記のバインド演算子による実装は、do を脱糖した場合の記述です。 do 記法があることで、コンテナの中に入った値を扱いやすくなります。結果、作用を起こしてその結果を受け取ったりする記述が容易になります。計算機に命令して作用を起こし、その結果を得る··· 手続き的プログラミングそのものですね。 do 記法を使わずに記述していけば見た目は関数の合成になるわけですが、そうした方がいい理由は特にありません。たとえば複数の値を一つずつ出力していきたいのであれば mapM や traverse などを無理して使わなくても、素直に for_ で手続き的にループを回して出力すれば良いのです。 import Data.Foldable (for_) main :: IO () main = do for_ [ 1 .. 10 ] $ \ i -> do print i ミュータブル配列を使いたいとき Haskell のデータ構造は基本、イミュータブルです。 しかし場合によってはイミュータブルなデータ構造だけでは効率的な実装が不可能な場合があります。 その典型例といえば、配列です。先日 Haskell の Array という記事でも投稿しましたが、Haskell にはイミュータブルな配列と、ミュータブルな配列があります。両者を都度変換して使うこともできます。 イミュータブルな配列は以下のように使います。 {-# LANGUAGE TypeApplications #-} import Data.Array.IArray import Data.Array.Unboxed (UArray) main :: IO () main = do let as = listArray @ UArray ( 0 , 5 ) [ 3 , 1 , 4 , 1 , 9 , 2 :: Int] print $ as ! 2 ! 演算子が配列への添字アクセスを行う関数で、もちろん O(1) です。 問題は配列の更新です。 イミュータブルなデータ構造は直接は書き換えられないので、更新時にはコピーが発生します。 main :: IO () main = do let as = listArray @ UArray ( 0 , 5 ) [ 3 , 1 , 4 , 1 , 9 , 2 :: Int] as' = as // [( 0 , 4 ), ( 1 , 8 )] -- 配列要素の更新 -- [4,8,4,1,9,2] print $ elems as' このとき配列全体がコピーされるので、更新関数 // の計算量は O(n) になります。 単一の特定の要素を更新する場合は O(1) で済んで欲しいわけですが、イミュータブルな配列ではそれは不可能です。O(1) での更新が必要なときはミュータブルな配列を使うと良いでしょう。 import Data.Array.IO (IOUArray) import Data.Array.MArray main :: IO () main = do as <- newListArray @ IOUArray ( 0 , 5 ) [ 3 , 1 , 4 , 1 , 9 , 2 :: Int] writeArray as 0 4 writeArray as 1 8 print =<< getElems as このようにミュータブルな配列を書き換えるのには writeArray などの関数を使います。この関数は「値を更新しろ」という命令を行うものですから、戻り値はありません。すなわち文 (相当) になります。 上記のミュータブル版の実装を見ると、 writeArray の戻り値を受け取っていないだけでなく、イミュータブル版の実装の時には出てこなかった <- や =<< などの演算子が必要になっています。詳細は割愛しますが、これらはやはり「データ構造を直接書き換える」という作用の結果必要になるもので、IO やミュータブルなデータの更新などの作用を起こすと周囲にも影響が及ぶことが見て取れます。 同様の例として、先の発表スライドの以下のページを見てください。Union-Find (Disjoint Set とも呼ばれます) というデータ構造とそのアルゴリズムを実装した時の比較です。 Union-Find は内部的に集合の管理をするわけですが、その管理用のデータ構造にイミュータブルなデータ構造を使った場合と、ミュータブルなデータ構造を使った場合のインタフェースの比較を行なっています。 左の、Union-Find がイミュータブルになケースでは、Union-Find 内の実装はもちろん、Union-Find を利用する側の実装もイミュータブルにそれを使うことになるので式で宣言します。より宣言的に、関数型プログラミング的にプログラムを構成することになります。 一方、右側のミュータブルな Union-Find はどうでしょうか。 左の実装とは異なり、 forM_ (先の for_ と同じです) や unless など戻り値を伴わない制御構造文的なものを使った実装になります。これは無理にそうしているわけではなくて、ミュータブルなデータ構造を更新するのには文を使うことになり、その結果、制御構造も値を戻さない文を使うことになるだけです。作用によってデータを更新する、ミュータブルなデータ構造を使うとそれを皮切りに、そのコンテキストの実装は自然と手続き型になることを意味します。 ということはそのままプログラム全体を構成していくと、プログラム全体が手続き的になってしまいます。そこでミュータブルなデータ構造を改めてイミュータブルなデータ構造に変換するなどして、作用への依存を切って、関数型での記述に戻していくこともできます。 なお、Union-Find はそのデータ構造の都合上、ミュータブルなデータ構造を使って構成する方が望ましいと考えています。具体的にはクエリ時に経路圧縮をすることによってデータ構造内部のバランシングを行うわけですが、このバランシングに作用を伴うためです。詳しくは以前 Haskell で Union-Find とクラスカルのアルゴリズム に記述しました。 手続き的に書く方が「わかりやすい」ケース IO や ミュータブルなデータ構造の例は、作用があるゆえ結果的に自然と手続き的に書くに至るというようなケースでした。 積極的に手続き的プログラミングを選択したというよりは、半ば受動的に、手続き的に記述するようなケースです。 では、その積極的に手続き的プログラミングを選択したいケースも見てみましょう。 以下 AtCoder の競技プログラミングの問題を題材にしますが、問題の内容は重要でありませんので詳細を理解する必要はありません。問題を解くためのコードの形がどんなものになるかにだけ着目していってください。 次の再帰による深さ優先探索 (DFS) の問題を解いてみます。 atcoder.jp グラフが与えられる、頂点 1 を出発点にして探索を行った時、同じ頂点を複数通らないパスを数え上げていったときその個数 K を出力する。ただし K が 10 6 より大きくなる場合はそこで数え上げをやめる。という問題です。DFS を行えばいいだけの問題に見えますが、経路を数え上げた結果上界に達したら計算を打ち切る... いわゆる枝刈りが必要です。 この手の再帰を回しながら数え上げをする実装は、手続き型で書くと思いのほか簡単です。 以下は Python による実装です (ChatGPT に書かせました) 数え上げは再帰関数のスコープを跨いで行う必要がありますが、カウンタ値 k を global で関数のスコープ外で生存できるようにし、上界の 10 6 に達したら早期 return で大域脱出すれば良いだけでです。 import sys sys.setrecursionlimit( 10 ** 7 ) # Input n, m = map ( int , input ().split()) g = [[] for _ in range (n)] for _ in range (m): u, v = map ( int , input ().split()) g[u - 1 ].append(v - 1 ) g[v - 1 ].append(u - 1 ) visited = [- 1 ] * n k = 0 def dfs (v): global k k += 1 if k > 10 ** 6 : k = 10 ** 6 return visited[v] = 1 for u in g[v]: if visited[u] == - 1 : dfs(u) visited[v] = - 1 dfs( 0 ) print (k) 同じような実装を Haskell で、純粋関数で書こうとするとグローバル変数や大域脱出に相当するところをどうするか悩むことになります。 以下は最初に書いた、純粋関数で実装した実装です。 dfs nextStates visited v = do let visited' = IS.insert v visited us = filter ( `IS.notMember` visited') (nextStates v) foldl' ( \ k u -> if k >= 10 ^ 6 then k else k + dfs nextStates visited' u ) (length us) us main :: IO () main = do [n, m] <- getInts uvs <- replicateM m getTuple let g = graph2 ( 1 , n) uvs k = dfs (g ! ) IS.empty ( 1 :: Int) print $ min ( 10 ^ 6 ) (k + 1 ) foldl' で畳み込みをする際に上界を超えていたらそれ以上は再帰を行わない、ということを途中で行なっています。 再帰をまたいだカウンターのものを用意するのではなく foldl' の計算結果のアキュムレータを再帰関数が返したものを受け取って、さらにそれをまた foldl' の初期値にして... ということを繰り返しており、その動きを頭の中で想像しようとするとなかなか大変···認知負荷で頭がパンクしそうになります。 Python の実装に比べると、ずっと難しく感じますね。なお、誤解がないよう説明すると、ここではコードの読みやすさが簡単・難しいという話をしているわけはなくて、計算の構造、計算を実際に頭の中で追うときの認知負荷の観点で簡単か、難しいかを論じています。 もとい、先の Python の実装のように再帰関数のコンテキスト中にカウンタ値を共有して計算を打ち切るような実装はできないのものでしょうか? そこで手続き型プログラミングです。 State モナドを使うと、関数の実行コンテキスト間で値を共有しながら計算を進めることができます。実質的に、関数の実行コンテキスト内部に閉じたグローバル変数のように使えます。 dfs nextStates visited v = do let us = filter ( `IS.notMember` visited) (nextStates v) modify' ( + length us) k <- get when (k < 10 ^ 6 ) $ do forM_ us $ \ u -> do dfs nextStates (IS.insert v visited) u main :: IO () main = do [n, m] <- getInts uvs <- replicateM m getTuple let g = graph2 ( 1 , n) uvs k = execState (dfs (g ! ) IS.empty 1 ) 0 print $ min k ( 10 ^ 6 ) State モナドの更新には、例によって戻り値のない命令 modify' などを使います。カウンタ値が上界を超えたら再帰を呼ぶ必要はないし、純粋関数でやっていた時のように値を戻す必要もないので戻り値のない when により分岐を制御します。 dfs 関数の中が、手続き的になりました。こちらの方が計算の流れは簡単に追うことができるでしょう。 この問題は比較的シンプルではあるので、純粋関数で構成してもなんとかなるかなとは思います。 一方、再帰を呼ぶ、呼ばないの分岐がより複雑になってくると再帰から戻ってきた値をどう結合するかも含めて考えるときの認知負荷が大きくなり、きつくなってきます。 再帰関数による全探索の、別の問題を見てみます。 atcoder.jp この問題は、縦長の畳、正方形の畳がある決まった数が与えられたとき、それを部屋の中にちょうどよく敷き詰められるか? というパズルを再帰的に全探索することで解く問題です。 詳細は割愛しますが、こちらの問題も State モナドを使って手続き的に記述することで、先のグラフ問題同様に、再帰を継続するしないの選択や、数え上げを、戻り値を戻すことを意識せずに実装できるので比較的、頭の中にあるモデル通りの実装が可能です。 これを純粋関数でやろうとすると再帰から戻ってきた値をどう扱うか、書けないわけではないですが、少し面倒になるでしょう。 dfs (h, w) _ _ s [] = do modify' ( + 1 ) dfs hw a b s (v @ (i, j) : vs) | Set.member v s = dfs hw a b s vs | otherwise = do when (a > 0 ) $ do let ! yoko = (i, j + 1 ) ! tate = (i + 1 , j) when (inRange (( 1 , 1 ), hw) yoko) $ do dfs hw (a - 1 ) b (Set.insert yoko $ Set.insert v s) vs when (inRange (( 1 , 1 ), hw) tate) $ do dfs hw (a - 1 ) b (Set.insert tate $ Set.insert v s) vs when (b > 0 ) $ do dfs hw a (b - 1 ) (Set.insert v s) vs main :: IO () main = do [h, w, a, b] <- getInts let vs = range (( 1 , 1 ), (h, w)) k = execState (dfs (h, w) a b Set.empty vs) ( 0 :: Int) print k IO を扱いたいとき、ミュータブルなデータ構造を扱いたいとき、再帰関数の例のように手続き的に書く方がわかりやすいとき、など Haskell での手続きプログラミングの例を見ました。いずれの例も、無理をして手続き的に書いているわけではありません。関数型言語を使うからと言って、式による計算の宣言、つまりは関数型プログラミングに固執する必要はないことがわかります。 do 記法や State モナドは決して特別なものではなく言語の基本機能として用意されているものです。つまり、その場その場に応じて適切なパラダイムを選択する ... 関数型と命令型のマルチパラダイムでコードを実装しても特に問題ないからこそでしょう。 ただし手続き型の命令に伴って副作用が現れる場合に、Haskell は型やモナドによって明示的にそれを扱っています。そのため比較的安全に、手続き型プログラミングを純粋関数型プログラミングの中に混在させることが可能になっている... というところが大きなポイントです。これによって都度パラダイムを行き来してもプログラム全体を破壊することなく、堅牢な記述を続けることができるというわけです。 まとめ Haskell の手続きプログラミングの例を見ました。Haskell でも手続き的プログラミングをする場面というのは案外多くあることがわかります。そしてその、関数型プログラミングと手続き型プログラミングのパラダイムの行き来をスムーズにするのに、do 記法や型が重要な役割を果たしています。 手続き型プログラミングの副作用を安全に隔離しながらも記述のオーバーヘッドを抑えるのに do 記法が貢献しているとも言えます。 裏返せば、do 記法のような文法の支援のないプログラミング言語で無理に純粋関数型だけでやっていこうとすると「ここは手続き的に書けばいいのに」という場面で柔軟な方針が取れず、自分で自分の足を撃っているような状況に陥るかもしれません。例えば Result はモナドのようなものですが、Result が入れ子になって多段になると、すぐにコードが複雑化します。(Rust など、最近のプログラミング言語には Result が組み込みで用意されているものもありますが、そこにはプログラミング言語による文法の支援が、セットで付いています。) TypeScript には関数型プログラミング言語的な側面があるとはいえ、一方で Haskell の do 記法 (やモナド) のようなプログラミング言語組み込みの機構はありません。よって、純粋関数型言語と完全に真似たスタイルでやっていこうとすると、少し困難が伴うかもしれません。 ここまでで分かったことを列挙すると以下のような考察になります。 明示的に作用を起こしたいのであれば手続きを使えば良い。ただし Haskell はその結果の作用から、純粋関数の世界を守ってくれる機構がある。それがない言語では、作用が伴う時その影響をどう管理するかが論点になる TypeScript には do 記法がない。(パターンマッチや代数的データ型も、エミュレートはできるものの十分とはいえない )。そして TypeScript で記述するようなアプリケーションは非同期 IO をたくさん行うものが多い。···にもかかわらず完全関数型スタイルでやっていくというのには道具が足りてない (と思います) TypeScript でも無理なく宣言的に書けるところはそうすれば良いだろう。同様に、手続き的に書く方がいい場面では (もしその手続きに副作用を伴うなら、それを手続きのスコープに留めることを何かしらで担保しつつ) 手続きで書くので良さそう。「関数型プログラミング」に固執する必要は (Haskell ですらそうなのだから、道具の足りてない TypeScript ではなおのこと) ない。 純粋な値だけで構成されるようなロジックの場合は、イミュータブルかつ宣言的に書いていってもなんら不便はない 副作用のあるところと、純粋に書けるところを分離することでその併用が可能になる。その点で、高階関数による Dependency Injection を積極的に使って業務ロジックの IO への依存を切っていくのは良いプラクティスと言える neverthrow には各種合成関数、 fromPromise や fromThrowable などで、コンテナに入っている値を扱いやすくする機構はあるものの、やはり十分とはいえず。 プログラミング言語そのものがそれをサポートしている言語などに比較するとやはり不便はある。(私たちはシステムが扱っている業務の都合上、その不便を受け入れてでも堅牢性の方を優先しました) 後日さらに理解が深めた結果、私自身がこの考察を否定することもあるかもしれませんので、その点はご了承ください。 長々とした文書をここまで読んでいただき、ありがとうございました。

この記事は 一休.com Advent Calendar 2023 6日目の記事です。 一休レストランの開発チームでエンジニアをしている香西です。 今回は Solr クエリの速度改善についてお話します。 背景 2023年10月、一休レストランのスマートフォン用 レストラン詳細ページをリニューアルしました！ UI/UX の見直しとともに、使用技術も一新しました。 バックエンド言語：Python から Rustへ フロントエンドフレームワーク：Nuxt.js から Next.jsへ *1 スマートフォン用 レストラン詳細ページ 課題 「日付を選ぶカレンダーの表示が遅い」 社内限定リリースの直後、多方面からこの声が聞こえてきました... レストランへ行く日付を選ぶカレンダーは予約フローの第一ステップなので、表示速度が遅いことは致命的です。 特に、設定データ（料理のコース種類・席の種類など）が多いレストランでは、カレンダーの空席状況を取得するのに15秒以上かかることがあり、このままでは正式リリースできない状況でした。 空席カレンダーの UI 一休レストランでは、各レストランの空席情報を全文検索システム Solr にインデックスし、予約できる日を Solr で検索して空席状況を取得しています。 Solr には、レストランの設定データごとにドキュメントを作成しインデックスしています。そのため設定データが多いレストランは検索対象のドキュメント数が膨大になり、検索に時間がかかっていました。 やったこと 検索マイクロサービスを経由するのをやめた Solr へのアクセスは「フロントエンド → バックエンド → 検索マイクロサービス → Solr」という流れで行われます。 従来からあった検索マイクロサービスのオーバーヘッドが大きかったため、検索マイクロサービスを経由するのをやめて、「バックエンド → Solr」に直接アクセスするようにしました。 検索マイクロサービス（C#）で行われていた Solr クエリの組み立てや、Solr からのレスポンスをオブジェクトに変換し在庫計算を行う処理を、バックエンド（Rust）に移行しました。 ワイルドカードを使うようにした Solr にインデックスされているデータのなかには、日付ごとに異なる情報が含まれています。これらの情報は、それぞれ特定の日付（例：231025）を含むフィールド名で表現されています。 "231025Close_tdt": "2023-10-21T00:00:00Z", "231025VisitTimeFrom_tdt": "2023-10-25T18:00:00Z", "231025VisitTimeTo_tdt": "2023-10-25T18:30:00Z", "231025HasInventory_b": true, "231025HasRotationOrBlockTime_b": false, "231025Inventory_ti": 1, "231025SalesUpperLimitOver_b": false, 例えば、先1か月分の各日付の情報を取得する場合、以下のような Solr クエリを生成していました。 // 変更前 fl=231025Close_tdt,231025VisitTimeFrom_tdt,231025VisitTimeTo_tdt,231025HasInventory_b,231025HasRotationOrBlockTime_b,231025Inventory_ti,231025SalesUpperLimitOver_b,231026Close_tdt,231026VisitTimeFrom_tdt,231026VisitTimeTo_tdt,231026HasInventory_b,231026HasRotationOrBlockTime_b,231026Inventory_ti,231026SalesUpperLimitOver_b,231027Close_tdt,231027VisitTimeFrom_tdt,231027VisitTimeTo_tdt,231027HasInventory_b,231027HasRotationOrBlockTime_b,231027Inventory_ti,231027SalesUpperLimitOver_b,231028Close_tdt,231028VisitTimeFrom_tdt,231028VisitTimeTo_tdt,231028HasInventory_b,231028HasRotationOrBlockTime_b,231028Inventory_ti,231028SalesUpperLimitOver_b,231029Close_tdt,231029VisitTimeFrom_tdt,231029VisitTimeTo_tdt,231029HasInventory_b,231029HasRotationOrBlockTime_b,231029Inventory_ti,231029SalesUpperLimitOver_b,231030Close_tdt,231030VisitTimeFrom_tdt,231030VisitTimeTo_tdt,231030HasInventory_b,231030HasRotationOrBlockTime_b,231030Inventory_ti,231030SalesUpperLimitOver_b...つづく field list で「231025のフィールド群,231026のフィールド群,231027のフィールド群 ...」のように、特定の日付が含まれるフィールド群を個別に指定していましたが、日付部分（231025）をワイルドカード（??????）に置き換えて「??????のフィールド群」という書き方に変更しました。 // 変更後 fl=??????Close_tdt,??????VisitTimeFrom_tdt,??????VisitTimeTo_tdt,??????HasInventory_b,??????HasRotationOrBlockTime_b,??????Inventory_ti,??????SalesUpperLimitOver_b この変更により、設定データが多いレストランではレスポンスタイムが約 1/5 に短縮され、大きな改善効果が得られました！ 100件ずつ並列で取得するようにした 最初に、検索結果の総件数のみを取得し、総件数を100で割って何回取得すればよいか判断し、100件ずつ並列で Solr にリクエストを送るようにしました。 Rust で Solr から結果を取得するサンプルコードです。 search_calendar にカレンダーの検索条件を渡すと、まず Solr から総件数を取得し、そのあと100件ずつ検索結果を取得します。 pub async fn search_calendar ( & self , input: & model :: CalendarInput, ) -> anyhow :: Result < Vec < model :: Date >> { let rows = 100 ; let query = CalendarQuery (input. clone ()); // 先に総件数のみを取得する let total_count = self . get_solr_data ( & query, 0 , 0 ).await ? .response.total_count; let query = & query; // 100 件ずつ取得する let futures = ( 0 ..total_count. div_ceil (rows)). map ( | n | async move { self . get_solr_data (query, n * rows, rows).await }); let res = futures_util :: future :: try_join_all (futures).await ? ; // 以下略（Solr の結果をもとに返り値を作る） } 不要な Solr クエリを削る 改めて Solr クエリに削除できる部分がないか見直しました。 不要なフィールドを取得していないか ユーザーの指定条件によって削除できるフィールドはないか 無駄に group , sort の機能を使用していないか といった観点でチェックを行いました。 成果 この改善により、カレンダーの空席状況を取得するのに15秒程かかっていたのが2～3秒程度に短縮され、スムーズな UX をユーザーに提供することができました！ また、システム観点でも大きな効果がありました。 今回の速度改善対象は、スマートフォン用 レストラン詳細ページのカレンダーの検索処理でしたが、Solr 全体のパフォーマンスが向上しました。 Solr の CPU コア使用率が半分以上減少 Solr 全体のレスポンスタイムが450ミリ秒から200ミリ秒程度に短縮 Solr の CPU コア使用率が半分以上減少 Solr 全体のレスポンスタイムが450ミリ秒から200ミリ秒程度に短縮 一休レストランの Solr に関する改善点はまだ多くありますが、少しずつ着実に取り組んでいきたいと思います。 さいごに 一休では、ともに良いサービスをつくっていく仲間を募集中です！ www.ikyu.co.jp カジュアル面談も実施しているので、お気軽にご応募ください。 hrmos.co *1 : Next.js で起きた課題については 一休.com Advent Calendar 2023 15日目の記事で解説予定です。

宿泊開発チームでエンジニアをしている @itinao です。 昨年の10月に入社しました。 今回は GitHub Projects を利用したタスク管理について記載します。 なんとなーく GitHub Projects 使うと、KANBANにしてみたり リストにして使ってみたり で終わってしまいます。 もっと色々できるんだよってことが伝えられればと思います。 背景 どんな機能があるか Custom Fields Views Group by Slice by Workflows ISSUEと Pull requestの紐づけ Insights タスクの進め方 タスクの洗い出し 見積もり 現状の課題と今後の展望 まとめ さいごに 背景 一休ではチームごとにタスクの管理方法が違い、 Google Spreadsheet・GitHub Projects・Jiraなど、チームごとにタスク管理の方法が異なっています。 各ツールの印象は、、 Google Spreadsheet 作り込めば便利なんだけど、壊れやすい... Jira 過去に使って、エンジニア目線だと操作感とかそんな好きになれなかったなあという印象があった.. GitHub Projects エンジニアだととっつきやすいのと、ツールをアレコレ移動しなくて済む 個人的には Jira か GitHub Projects を使いたくて、 できれば GitHub Projects を選択したいという気持ちがありました。 そのモチベーションでやり方を考え、現在はこの記事の管理方法で落ち着いています。 どんな機能があるか この4つを抑えておけば良いです。 Custom Fields / Views / Workflows / Insights ざっくり概念。 Custom Fields 下記の種別でパラメータを作成でき、Draft / ISSUE / Pull request に値をセットすることができます。 docs.github.com 種別 設定できる内容 Text テキスト Number 数値 Date 日付 Single select 決められた項目のみ選択できる Iteration 決められた間隔の時間ブロックを作り、その時間ブロックを選択できる ★ 自身のチームではこのようなパラメータを作って運用しています。 名前 種別 設定内容 例 Status Single select タスクの状態 Backlog / In progress / In review / Done Epic Single select 作業階層の最上位の単位で、チームが目指す大きなゴールのようなもの Epic1 / Epic2 / Epic3 / 改善 / ... Estimate Number 見積もり 1, 2, 3, 5, 8, 13, ... → フィボナッチ数列で運用しているため、Single selectにしたいところだが Insights で積算を表示させたいので Number Sprint Iteration 区切りになる開発期間 Sprint1, Sprint2, Sprint3, ... Function Single select どこの機能か リポジトリに近いイメージ 管理画面Backend, 管理画面Frontend, ユーザー画面Backend, ... Priority Single select 優先順位 高, 中, 低 → 普段は使わないが、バグチケットなどで目印が欲しいときに使う Views Table / Board / Roadmap のLayoutで、Draft / ISSUE / Pull requestを表示することができます。 Group by, Slice byが良い感じです。 Group by 設定した項目でグルーピング化し、表示してくれる Slice by 設定した項目でフィルタリングし、左にメニューが表示される ★ 自身のチームでは、ざっくり、、4つの Viewを良く使っています。 種別 イメージ 説明 利用シーン プロダクトバックログ GitHub Projects全体のチケットをEpic単位で絞り込めるようにしている 全体のタスクを眺める時 見積もりをする時 スプリントバックログ 現在のSprintのタスクをAssignees単位で絞り込めるようにしている 朝会/夕会で各々の作業を報告する時 自身のタスク 自身がアサインされているタスクをSprint単位で絞り込めるようにしている 自身でアサインされているタスクを確認する時 ADR タスク管理という軸ではないが、議論したことを書いておく ・専用のリポジトリのISSUEを表示している ・GitHub Discussionsでも良い 議論の場 Workflows 自由度は低いですが、 Draft / ISSUE / Pull request の操作をHookとして、特定のアクションを行うように設定ができます。 ★自身のチームでは、このような設定をしています。 ISSUE / Pull requeset をProjectsに追加した時、Statusを Backlogに設定する ISSUE / Pull requeset をクローズした時、Statusを Doneに設定する Pull requeset をマージした時、Statusを Doneに設定する ADRのリポジトリに ラベル: ADR のISSUEを作成した時、このProjectsに設定する → チケットの整理をしたくなるフェーズで Auto-archive items を設定する ISSUEと Pull requestの紐づけ ISSUEと Pull requestを紐付けることができ、 これを設定するとマージされたタイミングで紐づいている ISSUEがクローズされます。 Workflowsとセットで使うことで、自動的にステータスをDoneに更新することができます。 ★ Pull requestのマージ → ISSUEのクローズ → Custom Fieldsのステータスが Doneになる ※ 注意点としては複数のPull requestを ISSUEに紐づけている場合、1つでもマージされるとISSUEがクローズされてしまう Insights Draft / ISSUE / Pull requestの状態を参照し、グラフを作ることができます。 ★ 自身のチームではこのような設定をしています。 種別 イメージ 説明 Burn Up 作成されているISSUEとクローズされているISSUEの傾向を確認できる EPIC Epicごとのタスク量を確認できる（縦軸はチケットの合計） Velocity Sprintごとの進行速度を確認できる（縦軸はEstimateの合計） Plan Sprintごとに割り当てられているタスク量を見ることができる（縦軸はEstimateの合計） タスクの進め方 自身のチームでは、このようなステップでタスクを進めています。 まずはタスクの洗い出しと見積もりです。 タスクの洗い出し 見積もり ↓ スプリントごとにタスクのアサイン〜開発〜整理を繰り返す タスクのアサイン 開発 タスクの整理 タスクの洗い出し スムーズに見積もりを行うために、何をどこまでやるかが整理できてると良いです。 なのでチケットに概要、どこまでやるかなどを書くルールにしています。 タスクの範囲が曖昧だと見積もりがブレがちになります。 ## 概要 ◯◯を設定できるようにしたい ## やること - ◯◯が設定できるようになってる - backendと疎通し、DBにデータが保存できるようになっている - mainブランチにマージできている ## 補足 - GraphQLスキーマは決定している状態からスタート 見積もり 下記のようなルールで決めていきます。 チケットの重さは 1, 2, 3, 5, 8, 13, .. （フィボナッチ数列）で書き、人日では表さない チケットの重さは 相対評価 タスクA が 2で、タスクB が 8だった場合、B の工数は A の工数の 4倍あると見積もる ○ タスクCが 2よりもかかりそうだけど、5まではいかないなあ。。と思ったら 3を設定 ○ タスクをこなしていくと徐々に成熟していくイメージ 最初のうちはマトリクスを作って意識統一する 1: 数分で終わり、やる内容は明確、リスクがない 2: 数時間で終わり、やる内容は明確、リスクがない 3: 1日で終わり、やる内容は少し整理が必要、リスクがほとんどない 5: 数日で終わり、やる内容は整理が必要、リスクを考慮 8: 1週間で終わり、やる内容は複雑、リスクがある 個人の裁量で決めず、チームで決定する あの人だったら慣れてるから 1日で終わりそうだけど、、自分はもっとかかるかも × （ブラウザでプランニングポーカーをするサービスがあるので、そちらを活用する） できる限り小さい数字にする 小さくするのは手間だったりするので、手間にならない程度に分解する 分解することでタスクの解像度が上がる ○ チームで決められた値を見積もりに使うことで、 スプリント内でチームがどれくらいチケットを消化できるかが見えるようになります。 現状の課題と今後の展望 運用していると下記のような課題点が出てきました。 サブタスクを作りたい 少し大きなチケットを消化する際にチケットを分けたくなることもあるが、現状サブタスクが作れない docs.github.com 2023年10月時点でプライベートベータ バーンダウンチャートが見たい いまの進行速度だといつごろ開発が完了するのかを見たくなるが、現状見れない Slice byは2023年8月に追加されて使いやすくなったように、今後の進化に期待です。 github.blog 今後の展望としては Qaseのようなテスト管理ツールと連携し、 自動テストの実行と絡めた バグチケットの連携まで出来るようになれれば良いなと思っています。 qase.io まとめ タスクのチケット化・見積もりをする癖をチームに作るのが最初の課題かなと思います。 スプリントごとにやることを決め、そのチケットを見ながら朝会などで会話する スプリントでどの程度タスクをこなせたのかを測り、いつ頃までに開発が完了するのかが分かるようになる このようなフローになればチームの透明性も確保できて良い感じです◯ GitHub Projectsで 小中規模の開発に十分耐えられるので、ブラッシュアップしながら継続して使っていきたいと思います。 さいごに 一休では、ともに良いサービスをつくっていく仲間を募集中です！ www.ikyu.co.jp カジュアル面談も実施しているので、お気軽にご応募ください。 hrmos.co

ヤフー株式会社より出向しております、卯田と申します。 主務で、 一休.com および Yahoo!トラベル のフロントエンド開発を担当しています。 兼務で、ヤフー株式会社の全社横断組織で Webパフォーマンス改善の推進 を行っております。 本稿では、直近半年弱(2023年2月〜8月)で、断続的に行っていた一休.comのパフォーマンス改善について振り返ります。 開始が2023年2月となった理由は、Nuxt3バージョンアップ以降にパフォーマンス改善活動に着手したためです。 一休.com/Yahoo!トラベルのNuxt3バージョンアップ詳細については、以下のブログをご覧ください。 user-first.ikyu.co.jp サイトパフォーマンス改善の意義 改善の方針 方針1: Core Web Vitalsを改善する 方針2: 重要課題から優先的に対応する 改善の進め方 可視化 ブラウザサイド サーバーサイド 優先順位決め 具体的な改善内容 CLSの改善 こだわり条件更新時に発生するレイアウトシフト クチコミ画像表示時に発生するレイアウトシフト LCPの改善 リソースの読み込み順序の改善 documentのgzip圧縮 サーバーサイドKeep Aliveの実装 SQLの最適化 検索システムのバージョンアップ FIDの改善 LCP、FID、CLS、3つの指標が良好になった後 結果 今後 CLSの改善 LCPの改善 スタイルの計算とレンダリングの最適化 Apollo Clientのキャッシュ計算処理 算出方法の改善期待 FID(INP)の改善 パフォーマンス改善によるビジネス貢献 最後に サイトパフォーマンス改善の意義 サイトパフォーマンスは、 「お客様に上質な体験を提供するための重要非機能要件」 と考えています。 一休.comは、「心に贅沢を」をコンセプトに宿泊予約サイトを提供しております。 こちらのコンセプトのもと、便利な機能やUIをお客様に提供したいという気持ちで日々開発しており、パフォーマンスに関しても同じです。 お客様に気持ちよくサイトをご利用いただくためにも、パフォーマンスを維持することは非常に重要であると考えています。 改善の方針 方針1: Core Web Vitalsを改善する パフォーマンス改善の指標は、サイト全体のCore Web Vitals(フィールドデータのLCP・FID・CLS)としました。 PageSpeed Insightで示すと、赤枠の箇所です。 GoogleではCore Web Vitalsを以下のように定義しています。 Core Web Vitals は、Web 上で実際にユーザーが体験するユーザー エクスペリエンスに関する重要な観点の測定を目的とした一連のフィールド指標（データ）です。 Core Web Vitals には指標と各指標のターゲットとなるしきい値が含まれており、これらを参考にすることで、運営するサイトでのユーザー体験が "良い"、"改善が必要"、"悪い" のいずれの状態にあるかを開発者が定性的に理解できるようになります。 引用: https://web.dev/i18n/ja/defining-core-web-vitals-thresholds/ LCP : Largest Contentful Paint (最大視覚コンテンツの表示時間): 読み込みのパフォーマンスを測定するための指標です。優れたユーザー エクスペリエンスを提供するためには、ページの読み込みが開始されてからの LCP を 2.5 秒以内にする必要があります。 FID : First Input Delay (初回入力までの遅延時間): インタラクティブ性を測定するための指標です。優れたユーザー エクスペリエンスを提供するためには、ページの FID を 100 ミリ秒以下にする必要があります。 CLS : Cumulative Layout Shift (累積レイアウト シフト数): 視覚的な安定性を測定するための指標です。優れたユーザー エクスペリエンスを提供するためには、ページの CLS を 0.1 以下に維持する必要があります。 引用: https://web.dev/i18n/ja/vitals/ また、Core Web Vitalsを改善するためのパフォーマンス指標として、ラボデータ(synthetic monitoringと言う場合もあります)とフィールドデータ(RUMと言う場合もあります)の2種類を提供しています。 Lab data : Lab data is determined by loading a web page in a controlled environment with a predefined set of network and device conditions. These conditions are known as a lab environment, sometimes also referred to as a synthetic environment. Field data : Field data is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users' individual experiences. Because field data is based on real-user visits, it reflects the actual devices, network conditions, and geographic locations of your users. 引用: https://web.dev/lab-and-field-data-differences ラボデータとフィールドデータの関係において重要なことは、フィールドデータの改善が主たる目的であり、ラボデータは、あくまでフィールドデータを改善するための補足情報であるということです。 ユーザー体験を改善することが目的であることを鑑みると、フィールドデータ、さらにはその中でも最も重要と位置付けているCore Web Vitalsが、改善すべきパフォーマンス指標として適切です。 もちろん、Core Web Vitalsを改善するためにブレイクダウンした値として、ラボデータのスコアを改善指標とすることもできますが、あくまで参考程度に留めています。 Core Web Vitalsの3つの指標のバランスも重要と考えています。 LCP、FID、CLSの特定の指標が非常に良い状態を目指すのではなく、3つの指標が満遍なく良好な状態を目指しています。 Core Web Vitalsの良好に関する詳細は、以下のページをご覧ください。 web.dev 方針2: 重要課題から優先的に対応する パフォーマンス改善は、重要課題（大きく改善が見込める領域）から取り組むことで効率的に改善できます。 改善に時間をかけたにも関わらず、対して改善しなかったでは意味がありません。 特に、解決したい課題を理解せずにTipsベースで取り組むのは注意です。 「xxxでCore Web Vitalsが改善しました！」という記事をみて、同じ手法を取り入れてみたが、イマイチだったという経験がある方もいらっしゃるかもしれません（私もあります）。 そのようなことにならないよう、重要な課題から優先して対処していくことを念頭におきました。 もちろん、全て正しいアプローチで進められたわけではありませんが、常にチーム内で心掛けていました。 改善の進め方 可視化 まずは、重要課題を把握するために、現状を可視化しました。 ブラウザサイド ブラウザサイドのパフォーマンス可視化には、 GoogleのCodelabsに掲載されている資料 を参考に、Looker Studioのダッシュボードを作成しました。 こちらがとても役立っています。データ量次第では、無料で構築可能です。 ダッシュボード(一部非掲載) サーバーサイド サーバーサイドのパフォーマンス可視化には、もともと一休で導入しているDatadogの ダッシュボード と トレース機能 を利用しました。 全体把握には、ダッシュボードを使って、サーバーサイドのレイテンシを可視化しています。 以下はダッシュボードに載せている図の一例で、レスポンスの75パーセンタイル値の推移です 75パーセンタイルレスポンスタイム より詳細を見るためにはトレース機能を活用します。 デフォルトのプリセットで、ある程度のタスクをトレースできます。 デフォルトで表示されないタスクのトレースを試みたい場合、Node.jsであれば dd-trace-js のwrap関数で、traceしたい処理をwrapします。 以下は、 東京のホテル・旅館 のリクエストをトレースしている図です。赤枠は詳細トレース用にwrapしたApollo Clientのキャッシュ計算処理です。 そのほかにもネットワークリクエストの流れを把握できます。 Datadog APM Trace 優先順位決め 可視化したところ、3つの指標で特にスマートフォンのCLSが不良でした。 そこでまずはスマートフォンのCLS改善に取り組みました。 次に、LCPも良好ではなかったためLCPの改善に取り組みました。 FIDは良好であった、かつ、2024年3月にINPに置き換わるということが2023年3月に周知されたため、後対応としました。 補足 INPは、ユーザー操作に適切に画面が反応できているかを示す指標です。 不良な状態であるということはユーザーの操作を阻害していることを意味しています。 したがって、Core Web Vitalsが2024年3月に置き換わるタイミングに関わらず、可能であれば早急に改善したい課題です。 ただし、今後計測のエコシステムが整ってくるだろうという楽観的な希望もあり、節足に取り組むことはしないとチームで判断しました。 INP - web.dev 2023年8月執筆時点で、Chromiumのみが対応 - w3 別タブでリンクを開いた際に、極端にスコアが悪くなってしまう問題- chromium INP変更履歴 - chromium 具体的な改善内容 具体的な改善内容を、改善に取り組んだ時系列、CLS、LCP、FIDの順に紹介します。 ※パフォーマンス改善で実施した改善施策のうち、分かりやすい施策を中心に紹介します。 CLSの改善 上記で作成したダッシュボードを利用することで、 どのDOM要素が どれくらいの頻度で どれくらいの大きさ レイアウトシフトしているかを一覧できるようになりました。 下の画像左のプロット図をご覧ください。 Looker Studio CLS ダッシュボード 右上にプロットされている点が、頻度が高く、大きくレイアウトシフトしているDOM要素を示しています。 この図に従い、右上に存在するDOM要素から順にレイアウトシフトを特定し、改善を施していきました。 以下に、分かりやすい事例として2つ、頻繁に起きていた事例と大きくレイアウトシフトしていた事例を紹介します。 こだわり条件更新時に発生するレイアウトシフト こだわり条件を変更した際に、「夕朝食付」が消え、「エリア・駅名・キーワード」が表示されます。 この一瞬で、検索フォームの高さが変わることでレイアウトシフトが発生していました。 レイアウトシフトの大きさとしてはそこまでですが、頻繁に発生している事例です。 色々な条件で検索するお客様にとっては、度々ガタついており、目障りな印象を抱いていたかもしれません。 こだわり条件更新時のレイアウトシフト クチコミ画像表示時に発生するレイアウトシフト お客様の投稿したクチコミ画像を表示するモーダルです。 画像領域の高さ指定をしていなかったため、画像読み込みの間、領域の高さが0となっていました。 頻度は低いですが、レイアウトシフトの大きさとしては非常に大きい事例です。 ※図はYahoo!トラベルですが、一休.comでも同様です。 クチコミ画像のレイアウトシフト LCPの改善 リソースの読み込み順序の改善 ChromeのDev Toolsのネットワークタブで、リクエストウォーターフォールを確認したところ、大量のJavaScriptとCSSをpreloadしており、LCPとなる画像を取得するタイミングが遅れていました。 修正前のネットワーク LCP画像に Resource Hints を定義することで一定の改善も見込めますが、ページごとに個別最適した実装が必要で少し手間がかかります。 より、サイト全体に効果があるアプローチとして、すでにNuxt3のGitHubで 議論 されており、解決方法まで示されていたので、こちらを先に採用することにしました。 結果的には、この改善はNuxt3で動いているページ全体への効果が非常に大きく、計測ページ全体で、400msほどLCP改善しました。 本修正は、JavaScriptのloadを遅らせるため、FIDに悪い影響が出る懸念もありましたが、結果的には問題ありませんでした。 ネットワーク前後比 ※上記課題は、2023年8月25日リリースの Nuxt 3.7 experimental機能でも改善が図られています。以下のように、headNext機能を有効化することで検証できます。 export default defineNuxtConfig({ experimental: { headNext: true } }) documentのgzip圧縮 Nuxt3ではdocumentのgzip圧縮をできていませんでした。 そこで、Nuxt3が採用しているhttpフレームワークの unjs/h3 のpatchを独自で用意しました。 レスポンス直前にdocumentをgzip圧縮する処理を追加しています。 gzip 前後比 サーバーサイドKeep Aliveの実装 DNS LookupやTCP connectionをバックエンドへのリクエストの度に行っていたため、HTTP(S)/1.1 KeepAliveの実装をしました。 ※ Node.jsのバージョン19からデフォルトで有効になる機能 です。 Datadog APM Trace - KeepAlive SQLの最適化 非常に遅いSQLです。 SQLの実行のみで1.4秒近く時間を要しています。 対象のデータベースはSQL Serverを使っています。 SQL Server Managementで実行プラン を確認し、不足しているインデックス情報に従い、インデックスを設定し直すことで改善しました。 検索システムのバージョンアップ 検索システムにはApache Solrを使っています。 古いバージョンのApache Solrを使用していたため、まずは改善土壌を整えるべくバックエンドチームが4月から3ヶ月ほどかけてバージョンアップを行いました。 バージョンアップを行う過程で DeprecatedとなったFieldType を改修したところ、検索システムのレイテンシが劇的に改善しました。 Solr クエリのレイテンシー Solrのドキュメントにレイテンシが改善すると記載されてはいたものの、正直想定していた以上の結果だったとのことです。 （嬉しい誤算ですね。こういうこともあります。 ） 結果として、検索システムを呼び出している画面のLCPが200ms改善しました。 FIDの改善 上述の通り、FIDは当初より良好であったことと、INPへと置き換わることが周知されており、後対応としました。 今後は、INPの改善に取り組んでいきたいと考えています。 LCP、FID、CLS、3つの指標が良好になった後 機能開発で、パフォーマンスが悪化することもあります。 週1で、パフォーマンスチェックをする機会を設け、惰性で悪化することを防ぎました。 悪化した場合には、Looker Studioのダッシュボード、Datadog、一週間のコミットを照らし合わせ、改善しています。 幸い、一休.comのフロントエンド開発ではビッグバンになるようなリリースが極めて稀なため、変更コード量も限られており、悪化したとしても原因を特定することには苦労していません。 結果 下図は、直近6ヶ月弱のCore Web Vitalsの推移です。 線が下に行くほど、良い状態を示しています。 2月,3月の改善着手初期でCLSとLCPが大きく改善し、以降、3つの指標が要改善となるのを防ぎつつ、SolrのバージョンアップでLCPがさらに改善しました。 CLSは、良好の範囲内で一時的に悪化しておりましたが、作業時間を確保できたところで改善を施し、元の水準までスコアを戻しています。 スマートフォン デスクトップ Googleが毎月更新している Chrome User Experience Report でもフィールドデータの大まかな傾向を確認できます。 下図は、一休.comのCrUXダッシュボードです。 緑色の領域が良好を示しています。 2022年11月に比べ、2023年8月では良好の割合が増えていることが確認できます。 上:スマートフォン / 下:デスクトップ 一休.comのCrUXダッシュボードの詳細は、以下のページでもご覧いただけます。 lookerstudio.google.com 今後 CLSの改善 CLSは、この6ヶ月間でも、機能改修で、幾度か悪化することがありました。 引き続き監視しつつ、良好を維持できるようにします。 LCPの改善 スタイルの計算とレンダリングの最適化 スタイルの計算とレンダリングに時間がかかっています。 CSSセレクタのパフォーマンスを Microsoft Edgeのパフォーマンスツール で確認したところ、*, ::after, ::before のCSS変数の計算が大半を占めていました。 セレクターパフォーマンス CSS変数を埋め込んでいるのは、Tailwindのベーススタイルです。 GitHubで検索してみたところ、Tailwindのリポジトリで 同様の議論 をしていました。 DOMサイズが大きい場合に顕著に悪化する問題で、一休.comは全体的に初期表示時のDOMサイズが大きいサイトなため影響を受けています。 最もDOMサイズが大きい トップページ で、開発環境検証してみたところ、スタイル計算のパフォーマンスが改善されることを確認できました。 他のページへの修正影響を確認した上でリリースしたいと考えています。 また、ブラウザサイドでの画像のリクエストタイミングが、最善ではありません。 LCPの値が好ましくない、かつ、お客様訪問の多いページ・デバイスからResource Hintsもしくは Fetch Priority 属性を実装し、改善を図りたいです。 Apollo Clientのキャッシュ計算処理 Apollo Clientのキャッシュ計算処理に時間を要しています。 実装改修コストも非常に高いですが、重要なページから異なるGraphQL Clientへの移行を始めています。 user-first.ikyu.co.jp 算出方法の改善期待 Googleでは"soft navigations"に関するLCP算出方法の変更を検討しています。 一休.comでは"soft navigations"を多用しており、ユーザーが体験したパフォーマンスにより近くなると期待しています。 developer.chrome.com FID(INP)の改善 CLSで行った手法同様、まずはINPの計測環境を整備します。 そして、不良かつ頻繁に発生するイベント（動作）を特定し、改善に最も効く重要なイベントから最優先で改善を行っていきたいです。 パフォーマンス改善によるビジネス貢献 現状、パフォーマンス改善によって、どれだけビジネスに貢献できたは把握できておりません。 ヤフー株式会社の全社横断組織にて、ビジネス指標（直帰率、離脱率、コンバージョン率など）とパフォーマンスの相関を計測する環境が整備されつつあるので、 次は、Yahoo!トラベルで、ビジネス貢献にもつながるパフォーマンス改善に取り組んでいきたいです。 最後に 株式会社一休では、上質なウェブ体験を一緒に実現してくださる方を絶賛募集していますo( ^▽^ )o~♪ 一緒に、宿泊・飲食予約の未来を作りましょう！ hrmos.co

はじめに こんにちは。宿泊検索チームの渥美 id:atsumim です。 最近は検索改善のプロジェクトを行っており、特にキーワードでの検索の改善を行っています。 今回はその中でこの1年くらいの改善についてお話しします。 言葉の定義 先にこの記事で用いる言葉の説明をします。 ハード検索 指定した条件と完全に一致する結果のみを返す検索方法です。 今回は ID に 変換される 検索のことを指します。 ID なので一文字でも違うと、異なる条件として取り扱われます。 より具体的に言えば、下記の検索パネルから選択できる条件はすべて ID に変換されます。 例えば箱根は are=160418 となります ソフト検索 指定した条件と部分的に一致する結果も返す検索方法です。 今回は ID に 変換されない 検索(つまり純粋なキーワード)のことを指します。 例えば 一休 と検索したときに 一休み や 一休さん などの結果が含まれることになります。 より具体的に言えば、上記の検索パネルからできないキーワードのことになります。 箱根かに問題 🦀 ことの発端は「かに」でした。 まずは下記のスクリーンショットをご覧ください。 一年前の一休.com で「箱根, かに」を検索した画面です。 検索結果A 検索結果B 同じ条件であるはずの「箱根」「かに」の検索結果が異なることがわかります。 検索結果Aでは56件、検索結果Bでは96件となっています。 また、表記も 箱根, かに と 箱根 かに で微妙に異なっています。 なぜこのようなことが起きたのでしょう。 原因は検索方法の違いにあります。 検索結果A 「ハード検索 + ソフト検索」の検索方法です。 細かく見ると「ハード検索: 箱根 , ソフト検索: かに 」という検索になります。 一休.com で使われるクエリパラメータに変換すると ?are=160418&kwd=かに という形になります。 検索結果B 一方、検索結果B は「ソフト検索」のみの検索方法です。 細かく見ると「ソフト検索: 箱根, かに 」という検索になります。 一休.com で使われるクエリパラメータに変換すると ?kwd=箱根 かに という形になります。 ソフト検索では、クチコミの文章や施設・プランの紹介文などからもデータを取得しています。 そのため、施設が実際に箱根になくても、 箱根 というワードがクチコミに入っていると検索結果に表示されてしまっていたのです。 また、クチコミのデータの中には「穏や かに 過ごせました」や「静 かに 楽しめました」などの文章が入っています。 これもソフト検索で「かに」に引っかかってしまい、本来箱根の旅館でかにを食べたいのに全く別の結果が返ってきている状態でした。 これを「箱根かに問題」と呼びます🦀 システム的な問題 「箱根かに問題」が根本的になぜ起きたのか、原因はシステム構成にありました。 元々の検索システムの構成は下記のようになっていました。 Before システム構成 先に図の説明をします。 キーワードを検索すると、まずバックエンドからサジェストAPIが呼び出されます。 サジェストAPI は 1つの単語 に対して「キーワードを変換したID( are など)」または「変換できなかったキーワード( kwd )」を返却します。 この「ID に変換できなかったキーワード」に対してキーワードAPIが呼ばれます。 キーワードAPI は前述の通り、「クチコミ」や「施設の説明文」などの文章からキーワードにマッチした施設のデータを返却します。 それを元に検索結果がフロントエンドで描画されます。 これが元々の構成です。 問題点 問題となっていたのは、サジェストAPI です。 本来、その名の通りキーワードに対応するサジェストを表示するために使うのが サジェストAPI です。 本来のサジェスト用途 しかしこれを検索のために使っていたために問題が起きていたのです。 サジェストAPIはそもそも 1つの単語 しか受け取りません。 つまり、例えば「箱根 かに」という2語のキーワードを1語として受け取り「 kwd=箱根 かに 」というように解釈してしまいます。 これはサジェストの用途であれば問題がないのですが、検索用途では問題になります。 本来「箱根」は are=160418 という ID に変換されるべきなのです。 また、返ってきた kwd に対してフロントエンドでも変換を行う実装が入っており、検索周りの実装を複雑にしていました。 これが「箱根かに問題」の実態です。 もちろん「かに」だけが問題が起きるわけではなく、上で見たように2語以上の単語を検索すると問題が起こるようになっていました。 上記をまとめると、箱根かに問題は下記の2つに分解できます。 使うべきではないサジェスト API を検索に使っている 「箱根」がキーワードとして認識されている キーワード検索に関する実装がフロントエンドにも漏れ出している キーワード API の精度が高くない 「穏や かに 」などのキーワードを含まずに純粋な「かに」を抽出したい マイクロサービスの導入 前者の「使うべきではないサジェスト API を検索に使っている」という課題はマイクロサービスを立てることで解決しました。 以下が新しいシステム構成です。 フロントエンドのキーワード解釈の実装もこのマイクロサービスに寄せています。 After このマイクロサービスは、例えば { " keyword ":" 箱根 かに " } というリクエストに対して { " areaIds ": [ " 160418 " ] , " keyword ": " かに " } というレスポンスを返します。 キーワードをクエリに変換するサービスなので「クエリサービス」と名付けました。 これは我々が求めていたシンプルな形のものです。 かにも綺麗に分かれています₍₍⁽⁽🦀₎₎⁾⁾ また、元々サジェストAPI はデータサイエンス部の管轄で、属人的になっていました。 しかし、今回クエリサービスはデータサイエンスのメンバーだけでなく、検索チームがオーナーシップを持って開発するように取り決めをしました。 適合率を上げる 一方、後者の「キーワード API の精度が高くない」という課題に関しては長期的なメンテナンスが必要です。 我々はこの課題に対して「ハード変換できるキーワードを増やす」というアプローチを取りました。 専門的に言うと長期的には「再現率」を改善し、短中期的には「適合率」を上げるようにしたのです。 今までは 箱根 などのエリアや、 朝食付き といったメジャーな検索条件に関しては、すでにキーワードから ID に変換できていました。 しかし「市区町村名」や「グループホテル名」などに関しては ID 変換をしていませんでした。 これらを変換し、適合率を上げるようにした、というわけです。 ID 変換できるキーワードが増えると、キーワードAPI に流れるキーワードは減るので、結果的により検索精度が上がります。 進め方 ソフト検索されているキーワードを監視して、検索需要が高いものから優先して ID 変換するようにしました。 これらはワードクラウドで視覚的に見えるようにしており、文字の大きいものほど検索需要が大きいキーワードということになります。 執筆時の一ヶ月前(2023/07/21)の実際のデータを載せます。 この時点ではグループホテルが変換できていませんでした。 グループホテル変換前の様子 ふふ や ドーミーイン , 星野リゾート が大きい割合を占めているのがわかると思います。 では「グループホテル名」を ID 変換できるようになった今の様子を見てみましょう。 グループホテル変換後の様子 ふふ や ドーミーイン などのグループホテルはなくなり、 オールインクルーシブ がデカデカと台頭するようになりました。 (星野リゾート系列は一休では取り扱いがなく、ID がないので 界 , 星のや , omo などが変換できず残っていますが、)全体がまるっと変わったのが見て取れます。 このように検索需要のあるキーワードをハード変換することで精度の高い検索結果を提供する、というのがここ数ヶ月の改善です。 並行してキーワードAPI は随時改善しており、「かに」などの食材については純粋な「かに」が抽出できるようになっています。 将来の展望 システム構成を見直し、ハード変換のカバレッジを上げて今期は過ごしてきました。 しかし、まだまだキーワード改善の余地はたくさんあります。 直近では ChatGPTに自社の情報を組み込みたい① - 一休.com Developers Blog で書かれているように、ChatGPT を使って検索体験を全く異なるものにできないか検証をしています。 「ユーザーの頭の中にあることをそのまま検索できる」ような検索体験を提供できるよう、引き続き開発を行っていきます 🦀 さいごに 一休では随時エンジニアを募集しています。 上記のような検索改善に興味がある方はぜひ下記からご応募ください。 www.ikyu.co.jp カジュアル面談も実施しているので、話だけ聞きたい！という方でもお待ちしております。 hrmos.co

はじめに 宿泊UI開発チームでソフトウェアエンジニアをしている原です。昨年の10月に入社しました。 私の所属する宿泊プロダクト開発部では主に 一休.com と Yahoo!トラベル を開発しており、今回お話するのは、両サービスのトップページ、施設一覧ページ、施設詳細ページなどの主要な導線のフロントエンドを担う Nuxt.js で作られたアプリケーションのインフラとデプロイについてです。 今回はこのアプリケーションにカナリアリリースの手法を取り入れて、より安全にリリースできるようになった話をします。 カナリアリリースとは カナリアリリースとは、複数の実行環境を用意しアプリケーションの新旧のバージョンを同時に稼働させ、一部のユーザーに絞って新環境を公開するリリース手法です。 カナリアリリースによって新バージョンに不具合があった場合でもユーザー全体に影響を及ぼすことなく、リスクを低減してリリースすることができます。 導入のきっかけ 一休では昨年から今年にかけて、宿泊プロダクトのNuxt.jsのバージョンを2系から3系にアップグレードしました。 詳しくは 一休.com、Yahoo!トラベルのNuxtをNuxt3にアップグレードしました をご覧ください。 user-first.ikyu.co.jp 上記のブログ記事の「リリース戦略」の項にあるように、メインブランチの内容が反映されているNuxt2バージョンの環境と、検証用ブランチのNuxt3バージョンの環境を立てて、Fastlyでユーザーの振り分けを行っていました。 無事にNuxt3へのバージョンアップが完了し、検証用環境がお役御免になったと思っていたところ、検索フォームの実装をまるごと置き換える大掛かりなリファクタリングが行われました。 同一アプリケーション内で条件分岐によるfeature flagは元来行われていましたが、それを差し込むのも難しいくらい大きな差分が発生するリファクタリングになりました。 そこで影響範囲が大きいリリースになるので失敗のリスクを最小限にしたいと考え、バージョンアップの検証用の環境をカナリア環境と銘打って引き続き使用することにしました。 カナリア環境の実現方法 以下が簡単な構成図です。 システム構成図 EKS 宿泊プロダクト内のシステムの多くは EKS で稼働していて、この Nuxt.js アプリケーションも EKS で動いています。 クラスタ内に通常バージョンが動作しているものとは別にカナリア環境用のデプロイメントを作成し、そこでカナリアバージョンのアプリケーションを動かします。 Fastly 通常環境とカナリア環境どちらにリクエストを向けるのか振り分けをFastlyで行っています。 以下コード例です(変数やCookieは仮のものです)。 sub vcl_recv { // リクエストの振り分け if (req.http.Cookie:new-environment-v1) { set req.http.new-environment-v1 = req.http.Cookie:new-environment-v1; } else { set req.http.new-environment-v1 = false; // カナリア環境に10%リクエストを振り分ける if (randombool(10, 100)) { set req.http.new-environment-v1 = true; } set req.http.new-environment-v1-new-cookie = "new-environment-v1=" req.http.new-environment-v1 "; max-age=31536000; path=/; secure; httponly"; } ... // req.backend はfastlyがリクエストを流すオリジンを指定する if (req.http.new-environment-v1 == true) { set req.backend = new-environment; } else { set req.backend = normal-environment; } } sub vcl_deliver { // Cookieの付与 if (req.http.new-environment-v1-new-cookie) { add resp.http.Set-Cookie = req.http.new-environment-v1-new-cookie; set resp.http.Cache-Control = "no-store"; unset req.http.new-environment-v1-new-cookie; } ... } 大まかな処理の流れを説明すると、 リクエストを新旧どちらの環境に向けるのかを識別するCookieの有無を確認 Cookieが付与されていなかったら、 randombool関数 で一定の割合で新旧どちらに向けるかを決める 新旧どちらかのオリジンにリクエストを流す 新環境へリクエストした場合、次回リクエスト時も新環境へ向けられるようにCookieを付与 という流れになっています。 このアプリケーションは初回リクエスト以降はNuxtサーバーへのリクエストが不要なSPAになっているため、旧環境へ向いていたが動作中に新環境へリクエストしてしまい動作に不具合が生じるといったことも起こりません。 Nuxtのビルド成果物はS3にアップロードしており、アプリケーションが必要とする静的ファイルはカナリアリリースとは関係なく取得することができます。 運用方法 アプリケーションリリース方法 通常バージョンのアプリケーションはreleaseブランチへのマージを契機にCIで自動的にimageをビルド、pushをしてリリースされます。 カナリアバージョンも同様に canary-release ブランチへのマージを契機にカナリア環境へリリースされます。 スケールイン、スケールアウト カナリアリリースを使用していない間はインフラコストの削減のため、podの最小レプリカ数を最小限にしています。 カナリアリリース開始時に流すリクエストの割合に応じてpodの最小レプリカ数を引き上げます。 リクエスト割合の調整 上述のvclのrandomboolの割合を変更します。 この際に割合が正しく反映されるように new-environment-v1 といった変数やCookieのsuffixのバージョンもインクリメントさせる必要があります。 以下カナリア環境へのリクエスト割合を10%から0%に変更する際のコード差分の例です。 sub vcl_recv { - if (req.http.Cookie:new-environment-v1) { - set req.http.new-environment-v1 = req.http.Cookie:new-environment-v1; + if (req.http.Cookie:new-environment-v2) { + set req.http.new-environment-v2 = req.http.Cookie:new-environment-v2; } else { set req.http.new-environment-v1 = false; - if (randombool(10, 100)) { - set req.http.new-environment-v1 = true; + if (randombool(0, 100)) { + set req.http.new-environment-v2 = true; } - set req.http.new-environment-v1-new-cookie = "new-environment-v1=" req.http.new-environment-v1 "; max-age=31536000; path=/; secure; httponly"; + set req.http.new-environment-v2-new-cookie = "new-environment-v1=" req.http.new-environment-v2 "; max-age=31536000; path=/; secure; httponly"; } ... - if (req.http.new-environment-v1 == true) { + if (req.http.new-environment-v2 == true) { set req.backend = new-environment; } else { set req.backend = normal-environment; } このように割合変更(カナリア環境へのリクエストを取りやめることも含む)をする度に、コードの修正が必要になります。 カナリアリリース導入の効果 Nuxtをはじめとしたライブラリのバージョンアップや、コード差分が大きく影響範囲の大きなリリースに対するリスクを大幅に軽減できるようになりました。 またこのNuxtアプリケーションは、宿泊事業部内の複数チームが開発しているのですが、カナリアリリースの概要やリリース手順書といったドキュメントの作成をしたり、リリースの都度レクチャーすることで、どのチームもカナリアリリースによって安全にデプロイできるようになりました。 課題 上述の通りカナリア環境へのリクエスト割合を変更するたびにVCLの変数のsuffixを変更する必要があり、そこそこ面倒な作業になっています。 また、カナリアリリース実施中に通常環境のリリースがあった際にその内容をカナリア環境に取り込む必要があります。そのため常に通常バージョンのリリース動向をチェックする必要があり、これもそれなりの負担があります。 これらを自動化などでコストを軽減できないかと模索中です。 最後に 一休ではプロダクトの機能開発をしながらボトムアップで開発基盤の改善もしたい！というエンジニアを大募集中です。 カジュアル面談も実施しているので、お気軽にご応募ください。 www.ikyu.co.jp hrmos.co

はじめに こんにちは、一休.comデータサイエンス部の平田です。 みなさんChatGPT活用してますか？ 一エンジニアとして便利に使ってはいるものの、自社サービスにどのように組み込もうか模索しているところも多いかもしれません。 一番の利用先として思いつくのが、自社の情報をもとに質問に答えるチャットボットではないでしょうか。 その中では、ハイコンテキストな検索（例えば、「東京から2時間以内で子供も楽しめるアクティビティがあって、景色も良い宿」のような）にも答えられるとボットの価値が増します。 ChatGPTが事前に学習した内容では古く、正確ではないためそういった検索に応えるのはかなり厳しいです。 そのため、こちら側が持っているデータを渡してあげる必要があるのですが、今回はその自社の情報をどう組み込むのか、という部分についてご紹介します。 素のChatGPTでは？ ChatGPTに例えば「熱海で子供も楽しめるアクティビティがあって、景色も良い宿を教えてください」 を聞いてそのまま納得できる内容が返ってくるなら、組み込むだけで済むのでかなり楽です。 まずは試してみます。 熱海は温泉地として有名で、子供から大人まで楽しめる観光地がたくさんあります。以下は、子供も楽しめるアクティビティと景色の良い宿泊施設の一例です。 アクティビティ: 熱海海洋公園: 水族館で、色とりどりの魚やイルカショーなどが楽しめます。 熱海梅園: 季節によっては梅の花が楽しめる庭園で、散策やピクニックが楽しめます。 熱海サンビーチ: 夏場は海水浴が楽しめるビーチで、子供たちに人気です。 MOA美術館: アートに興味を持つ家族には、美術館の散策もおすすめです。 宿泊施設: アタミセイザンリゾート: 子供向けのプールや遊び場があり、家族連れに人気。部屋からの海の眺めも素晴らしいです。 ホテルニュー熱海: 温泉が楽しめる宿で、子供用のアメニティも充実しています。海を一望できる部屋もあります。 熱海温泉 ホテルマイクローネ: 子供向けのプレイルームやプールがあり、温泉も楽しめます。部屋からの景色も良いです。 これらの施設は、子供向けのアクティビティと素晴らしい景色を楽しめるため、家族旅行にぴったりです。予約時には、子供向けの設備やサービスがあることを確認すると良いでしょう。最新の情報や詳細は、公式ウェブサイトや旅行サイトで確認することをおすすめします。 アクティビティと宿を出してくれるのでぱっと見は良さそうですが、熱海海洋公園はありませんし、宿泊施設に至っては3つともありません。 ChatGPTの学習データは2021年9月までのものなので、かつてはあったのかもしれません。 やはり、最新性のある情報を提供させるために、こちらから与えてあげる必要がありそうです。 情報を組み込む方法 ファインチューニング 質問文と答えの対を大量に用意し、それを事前学習されたモデルに対してさらに学習させることでオリジナルのモデルを作る方法があります。 platform.openai.com 質問文と答えの対を人手で作るのも難しいので、ChatGPTにやらせます。 response = openai.Completion.create( engine=COMPLETIONS_MODEL, prompt=f"""次の複数の口コミから、５０文字以内の日本語の質問文を１つ生成してください。 \n\nテキスト: {context}\n\n質問文:\n1.""", temperature=0.8, max_tokens=400, top_p=1, stop=["\n\n"] ) prompt=f"次のテキストに基づいて質問に答えてください\n\nテキスト: {row.context}\n\n質問文:\n{row.questions}\n\n答え:\n1.", ただ、質の高い対を大量に作るのは難しく、学習としてもあまりいい結果になりませんでした。（例はcurieモデル） 上手くいった例 上手く行かなかった例（こちらを向かう海を渡る…？） 8/22にcompletionモデルではなく、chatのモデルである gpt-3.5-turbo-0613 を対象にしたファインチューニングができるようになりました。 chatのモデルで行うともしかしたらいい結果が得られるかもしれません。 （↓見ると難しそうですが…） ChatGPT の Fine-tuning を試したけど上手くいかなかった話 埋め込みベクトル表現 ファインチューニング以外にも情報を渡す方法としては、プロンプトに必要な情報がまとまった文章を加えておき、 それに基づいて文章を生成してもらうというものがあります。 そのためには、「どの情報を渡すか」という部分をこちらで選択する必要があります。 ChatGPTのtoken数の制限、価格を考慮すると全てを渡すことはできません。 必要最低限の量を渡す方法として、クエリをベクトル化して、あらかじめベクトル化した情報と類似度が高いものだけをプロンプトに加えるようにします。 ファインチューニングと比較したとき、渡す情報をコントロールしやすいメリットがある反面、プロンプトが肥大化しやすいというデメリットがあります。 検証 今回は、口コミの中から必要な情報だけを抽出できるのか？というところをトライしてみます。 ベクトルで類似度をスコアリングしたのち、各項目について言及しているかどうかを正規表現で正誤判定させることにしています。 検証ではOpenAIのembedding APIを使用しています。対象は単語になっていますが、任意の文章をベクトル化することができます。 また、英語だと精度が良いらしいですが、ベクトルマッチングにおいてもそうなのかついでに調べてみます。 ちなみに翻訳にはdeepL APIを使いました。 querys = {'朝食': ['朝食', '朝ごはん', '朝ご飯', '朝御飯', '朝餉', 'ブレックファースト'], 'ペット': ['ペット', '犬', 'わんこ', 'ドッグ', 'わんちゃん','愛犬','ワンコ','ワンちゃん'], '花火': ['花火'], '絶景': ['絶景', '景色がいい', '景色が良い', '景色のいい', '景色の良い'], 'バリアフリー': ['バリアフリー', '車椅子', '車いす', '足が悪い', '脚が悪い'], '有名建築家': ['有名建築家','隈研吾','安藤忠雄','北川原温','坂茂','山口隆','岸本和彦']} target_query = '有名建築家' target_vec = get_embedding([target_query])[0]["embedding"] target_query_eng = translate_text([target_query])[0] target_eng_vec = get_embedding([target_query_eng])[0]["embedding"] df['test'] = df.review_text.apply(lambda x: any([q in x for q in querys[target_query]])) df['jpn_score'] = df.embedding.apply(lambda x: calc_cossim(target_vec, x)) df['eng_score'] = df.embedding_english.apply(lambda x: calc_cossim(target_eng_vec, x)) ROC曲線は、スコアの閾値を0~1で動かしたときに、横軸に疑陽性の率、縦軸に真陽性の率をプロットしたものです。 下側の面積をAUCと呼び、1なら完全な分類、0.5ならランダムな分類と同程度の精度だと評価されます。 朝食（日本語） 朝食（英語翻訳） 項目 日本語 英語翻訳 朝食 0.83 0.88 ペット 0.92 0.85 花火 0.95 0.97 景色 0.90 0.83 バリアフリー 0.63 0.78 有名建築家 0.95 0.95 単語によって、日本語が良かったり英語が良かったりバラバラですね。 明らかに英語の精度が良くなるかと思ったので意外でした。 有名建築家は正解データ数が少ないので両者高くなっています。 実際の口コミ抽出例 施設、キーワードを入力するとマッチした口コミを返すAPIを作りました。 口コミの一部分を返すことで、プロンプトが長くなるのを防ぐ工夫もしています。 以下はkeyword=温泉をとある施設の口コミを対象に入れたときの一例です。 一つ目は「温泉」がちゃんと入っていますね。二つ目は温泉に近い「温水プール」が入っています。 { "hotel_id": "00002627", "review_id": "1000022712", "review_text": "３連泊させていただきました。主にホテルにこもって過ごすことを前提にお伺いしましたが、客室はとても居心地がよく、朝焼けがとても綺麗に見えました。 また、プールもこじんまりとしていますが十分楽しめました。 特に23時までオープンしていることからナイトプールはとても綺麗なライティングで、夜空も綺麗に眺めることができました。 また、料理のレベルが高く、味も見た目にも楽しめるものばかりでした。 盛り付けはとってもオシャレでした（部屋食もよかった）。 接客は過度なものはなく、他のホテルに比べるとややあっさりした印象ですが、感じの良い方達ばかりでした。 温泉・お風呂は星４つにしたのですが、特段不満に感じることはありませんでした（水圧、綺麗さなどどれも満足）。 館内至るところ、アロマの香りが楽しめたのもよかったです。またお伺いしたいです。ありがとうございました。", "score": 0.75787675, "matches": [ { "match_text": "温泉・お風呂は星４つにしたのですが、特段不満に感じることはありませんでした（水圧、綺麗さなどどれも満足）。館内至るところ、アロマの香りが楽しめたのもよかったです。", "positive_score": 0.89829713, "score": 0.75787675 }, { "match_text": "また、プールもこじんまりとしていますが十分楽しめました。", "positive_score": 0.89906454, "score": 0.71830595 } ] }, { "hotel_id": "00002627", "review_id": "1001226432", "review_text": "10月30日宿泊\n客室はゆったりしていて寛げる\n温水プールは温かく景色が良い\n レストランはおしゃれな空間で\n雰囲気が良い\nスタッフは一生懸命で好感が持てる\n来月またお世話になります", "score": 0.7502389, "matches": [ { "match_text": "10月30日宿泊\n客室はゆったりしていて寛げる\n温水プールは温かく景色が良い", "positive_score": 0.779632, "score": 0.7502389 }, { "match_text": "レストランはおしゃれな空間で\n雰囲気が良い", "positive_score": 0.79234755, "score": 0.7080128 } ] } まとめ 今回は自社の情報をChatGPTに組み込む方法をご紹介しました。 しかし実はまだ、冒頭の「熱海で子供も楽しめるアクティビティがあって、景色も良い宿を教えてください」に応えられるものが出来ていません。 これは、全国の施設情報をベクトルマッチングで一部に絞っていてもなお量が多くてプロンプトに埋め込むことができないからです。 解決方法についてはChatGPTの次の記事でお伝えできればと思います。 また一休では、ともに良いサービスをつくっていく仲間を積極募集中です！応募前にカジュアルに面談をすることも可能ですので、お気軽にご連絡ください！ hrmos.co

2023/719に、TECH PLAYでマイクロサービス/サービス分割をテーマにしたイベントを開催しました。 techplay.jp 発表資料はこちらです。ぜひご覧ください。 speakerdeck.com speakerdeck.com

CTO室プラットフォーム開発チームの山口( @igayamaguchi )です。 プラットフォーム開発チームではさらに内部でプロジェクトチームが分かれており、私はフロントエンド改善チームというチームでリーダーをしています。 フロントエンド改善チームでは主に一休.com、Yahoo!トラベルのフロントエンドの改善を行っております。 今回は一休.com、Yahoo!トラベルで使用しているNuxtのバージョンを2から3にアップグレードしたお話をさせていただきます。 一休.com、Yahoo!トラベルではトップページや検索ページ、ホテル・旅館の詳細ページなど主要なページのフロントエンドはNuxtで開発されています。 NuxtのバックエンドにはGo+gqlgenでGraphQLのサーバーを立てており、NuxtからはApolloを使用してバックエンドと通信を行っています。 このNuxtのバージョンは2となっており、それを今回3にアップグレードしました。 なぜバージョンを上げたのか 話は2022年7月半ばにさかのぼります。 当時は宿泊事業におけるフロントエンド開発の課題について議論をしていました。 一休.com/Yahoo!トラベルではフロントエンドのコードの共通化を行っており、同じリポジトリ内の同じコードで両サイトを実現しています。 user-first.ikyu.co.jp しかし当初はうまくいっていた一休.com/Yahoo!トラベルのコード共通化、コンポーネント共通化も課題が生まれ、開発速度が大きく落ちてきていました。 上記はフロントエンドの現状のコードの問題をレポーティングしたときの資料から抜粋したものです。 上記画像のようにコードの重複が多く発生していました。(SDとは一休社内におけるスマホを指す用語です) 何か変更をしようとすると一休.com/Yahoo!トラベルとPC/スマホで別々になったコードに変更を加える必要があり変更箇所が4倍になるようになっていました。 この問題に対してデザインシステムを作ることで小さなUIコンポーネントやスタイルの共通化をすることが出来ました。 user-first.ikyu.co.jp しかしVueの状態やGraphQLに絡んだ処理などロジックに関連する処理の共通化がまだうまくいっていませんでした。 これはうまく抽象化、共通化する手段がNuxt2/Vue2では提供されていないことが問題でした。 Mixinなどを使えば可能ではありますが、Mixinでは見通しが悪くなる可能性が高く暗黙的な抽象化が行われあまりよい形にはなりません。 そこでVue3で登場したComposition APIです。 https://vuejs.org/guide/introduction.html#composition-api これを使うことで処理の共通化が行いやすくなり、コードの無用な重複も解消することができます。 Nuxt3/Vue3に移行すると他にも利点があり、以下に簡単に記します。 設計を全く違うものにできる Composition APIを使うことができると設計が全く変わる。より良い抽象化、共通化が可能になる 状態管理の選択肢が増える。(useState, Piniaなど) 型が効いて安全に Vue3に上がることでVolar(vue-tsc)と組み合わせて型が効くように 開発環境が爆速に Viteが本当に早い 他にもSuspense、Teleport、ビルドの最適化、などいいことはたくさん。 色々利点がありますがやはり設計が改善できる、ということが大きいです。 Nuxt3の方がより良い方法でコンポーネント、状態管理の設計ができるため移行を決断したのが7月末です。 8月くらいから実際に移行に向けての3人のチームメンバーで作業を進めて2月頭にリリースしました。 （最初期は4人で途中からメンバーの異動があったため基本的に3人） 移行指針 まずは最初に移行の指針を立てました。 それは 最低限のコストで移行する というものです。 Nuxt3にアップグレードする理由はより良い設計にして開発をしやすいようにするためです。 移行しながらきれいな書き方にすることもできますが、その場合移行期間が延びるのと、リリース時にビッグバンリリースとなってしまいます。 移行のコストとリスクを最小限にするためにこの指針を立て、プロジェクト進行時には常にこの指針に従い意思決定を行っていきました。 移行戦略 次に移行戦略を立てました。 Nuxt3/Vue3のドキュメントを読み、Nuxt3/Vue3の破壊的変更を洗い出し、タスクの一覧化、移行戦略を立てました。 移行戦略では以下のことを定めました。 Nuxt Bridgeを使うか タスクの切り分け ブランチ運用 ミニマムに検証をする リリース戦略 Nuxt Bridgeを使うか NuxtではNuxt Bridgeというモジュールが提供されています。 https://github.com/nuxt/bridge Nuxt2に対してこれを導入することで、Nuxt2でありながらNuxt3の機能を利用できる前方互換性のあるレイヤーです。 これを使うことでNuxt2のままNuxt3に対応するコードに徐々に移行するということができます。 しかし私たちはこれを使わない選択をしました。 1つ目の理由はNuxt Bridgeに対応していないモジュールがあることです。 私たちの使用しているNuxt moduleでは、Tailwind CSSなどが例として挙げられます。 そういったモジュールにどういった対応が必要になるのか、そこの対応にどのくらいの時間がかかるか予測できませんでした。 最悪開発が止まりリリースができなくなる可能性がありました。 2つ目の理由は二度テストを行う必要があることです。 上記のモジュール対応もあり、移行時にはサイト全体のテストを行う必要があります。 Nuxt2からNuxt Bridgeに移行するときとNuxt BridgeからNuxt3に移行するときで2度テストを行わなければいけません。 これらの理由によりNuxt Bridgeを使わずNuxt3への移行を行いました。 この決断は後に意思決定もシンプルにすることができ非常によかったです。 あらゆる対応がNuxt Bridge、Nuxt3両方を意識するのではなくシンプルにNuxt3のことだけを考えればよくなりコストが下がりました。 タスクの切り分け アップグレードをするためにタスクを対応タイミングに応じて切り分けを行いました。 大まかには以下の3つです Nuxt2/Vue2の状態で対応 Nuxt3/Vue3の状態で対応 リリース前に対応 まず1つ目のNuxt2/Vue2の状態で対応可能なものです。 Nuxt3/Vue3の破壊的変更はNuxt2/Vue2の状態でも対応できるものがあります。 例えばfunctionalコンポーネントがVue3で廃止されたためfunctionalコンポーネントを通常のコンポーネントに変更したり、Vueのfiltersが廃止されたため関数に書き換える、といったものです。 2つ目はNuxt3の状態で対応可能なものです。 1つ目を行ってからNuxt2/Vue2のときに対応できないNuxt3/Vue3の破壊的変更の対応です。 例えばモジュールやプラグインの書き換えです。 3つ目はリリース前に対応するものです。 これはテスト、画面の確認などです。 さらにタスクとは別にこのプロジェクトでやらないことも明記してリスト化するようにしました。 例えばNuxt3/Vue3に移行することでComposition APIが使えるようになるわけですが、「変更を最小限にするために移行時にComposition APIへの書き換えは行わない」、というように理由とともにやらないことを明記してリスト化していました。 実際に作業を進める上でもチームで議論して都度都度これは今やるべきではないとなったものを追加していました。 ブランチ運用 作業を進めるために作業ブランチをどうやって運用するかを決めました。 前述のタスクの切り分けを基に以下のようなブランチ運用を行うようにしました。 破壊的変更に対してNuxt2/Vue2の時点で対応できるものをまず対応してmasterマージ 事前対応できるものが終わり次第Nuxt3移行用のブランチを作成、そのブランチに対して残りの破壊的変更の対応をマージ 各施策のブランチがmasterにマージされた場合、適宜Nuxt3移行用のブランチに取り込み このようにブランチを運用することでNuxt3移行リリース時にマージするコードの変更は最小限になるようにしました。 ミニマムに検証する Nuxt3/Vue3を初めて触る際は様々な挙動がわからず悩む時があります。 そういったものを実際のプロダクトで検証しようとすると手間です。 そのため最小限でプロダクションに近しいNuxt3のboilerplateを用意し、そこで様々な実装の検証を行うようにしました。 リリース戦略 本番リリースでは一休.com、Yahoo!トラベルそれぞれを順々に公開するようにしました。 一休.comで10%のユーザーに公開 問題がなければ一休.comで100%のユーザーに公開 問題がなければYahoo!トラベルで10%のユーザーに公開 問題がなければYahoo!トラベルで100%のユーザーに公開 ユーザーの振り分けはFastlyで行い、あるユーザーは常にNuxt2、あるユーザーは常にNuxt3を見るように設定を行いました。 この時、一部のページ、例えばトップページだけNuxt3を公開する、ということはしませんでした。 理由はNuxtがSPA的なJSを使用したページ遷移がありそれを振り分けるのは難しいと判断したためです。 このように移行戦略を立ててNuxt3へのアップグレードを開始しました。 作業を開始する前に ここまでで戦略を立てて作業を始める準備は整ったのですが、ここでもう一つ作業を開始する前に取り組んだことがあります。 それがNuxt3/Vue3のドキュメントをチームで読み漁ったことです。 プロジェクトを始めた当初はNuxt3/Vue3について解像度が低く当初に洗い出したタスクで過不足がないか、どのくらい時間がかかるのかはかなり不透明だったため、解像度を上げるためにやってみようということで始めました。 毎朝1時間~1時間半ほどチームでZoomで集まりドキュメントを画面共有しながら読みました。 チームメンバーはNuxt2/Vue2の開発経験はあったため、Vueはマイグレーションガイド( https://v3-migration.vuejs.org/ )を、Nuxt3は頭からドキュメント( https://nuxt.com/ )を読んで機能差分について話しながら読み進めました。（当時Nuxt3はマイグレーションガイドが作成途中の項目が薄かったためドキュメントを頭から読んでいます。今なら https://nuxt.com/docs/migration/overview を読めばよいと思います） 結果チームメンバーそれぞれに基礎知識がつきタスクや対応方法の議論が活発になる土壌を作れたためよかった試みでした。 移行作業 ここからは実際に行った移行作業の具体的なお話をします。 とはいえ基本的には前述のNuxt、Vueそれぞれのマイグレーションガイドを読み、破壊的変更となるものを対応しています。 そこで今回、私たちが躓いたものや独自の対応をしているものを紹介させていただきます。 defineComponent/defineNuxtComponent Nuxt2/Vue2でVueコンポーネントを作成するときに Vue.extend を使っていましたが、Nuxt3では defineNuxtComponent を使う必要があります。 https://nuxt.com/docs/api/utils/define-nuxt-component 今回、破壊的変更は別ブランチを立てて変更をしていくためmasterブランチマージ時に発生する変更は小さくしたいです。 そのためmasterブランチ上でも defineNuxtComponent を使用出来るようにaliasとなる関数を用意しました。 /** * defineComponent */ import Vue from 'vue' import { VueConstructor } from 'vue/types' type VueExtend = VueConstructor [ 'extend' ] // @ts-ignore const defineComponent: VueExtend = ( options ) => Vue.extend ( options ) export { defineComponent } /** * dynamic import */ export function defineAsyncComponent ( f: Function ) : Function { return f } これを用いてmasterブランチに各コンポーネントを Vue.extend から defineComponent に書き換えました。 import { defineComponent } from '~/nuxt3-alias' export default defineComponent ( { // 中のoption apiはそのまま } ) Nuxt3移行ブランチでは以下のようにaliasを差し替えるだけでよいのでリリース時の変更が最小限になります。 import { defineAsyncComponent as _defineAsyncComponent } from 'vue' import { defineNuxtComponent } from '#imports' const defineComponent = defineNuxtComponent export { defineComponent } const defineAsyncComponent = _defineAsyncComponent export { defineAsyncComponent } fetchフック Nuxt2ではfetchフックという各コンポーネントで非同期にデータ取得、設定を行うことができる専用のhookが用意されています。 https://nuxtjs.org/docs/components-glossary/fetch/ これがNuxt3では使うことが出来ないようになっていました。 useAsyncData useFetch というものが使えるようになっていてそちらに置き換えが必要です。 https://v3.nuxtjs.org/getting-started/data-fetching しかし useAsyncData useFetch を使うにはComposition APIへの書き換えが必要です。 これには時間がかかることが予想されたのとmasterブランチとの差分が大きくなってしまうのでfetchフックをそのままにどうにかできないか検討しました。 最終的には以下のようなプラグインを作り、fetchメソッドをそのまま解釈できるようにして対応しました。 難点が1つあって、fetchフックを使用するときは nuxt2FetchKey というキーを定義する必要があるのと、fetchフックを使用するコンポーネントが画面で複数個所で呼ばれないことを前提にしています。 export default defineNuxtPlugin (( nuxt ) => { nuxt.vueApp.mixin ( { async serverPrefetch () { if ( ! hasFetch ( this )) { return } if ( this .$options.fetchOnServer === false ) { return } await this .$options. fetch .call ( this ) if ( ! nuxt.payload.data ) { nuxt.payload.data = {} } nuxt.payload.data [this .$_fetchKey ] = this .$data this .$_fetchResolve () } , created () { if ( ! hasFetch ( this )) { return } this .$_fetchKey = this .$options.nuxt2FetchKey this .$_fetchPromise = new Promise (( resolve ) => { this .$_fetchResolve = resolve } ) } , async beforeMount () { if ( ! hasFetch ( this )) { return } if ( ! window .__NUXT__ ) { window .__NUXT__ = { data: {} } } const serverData = window .__NUXT__.data [this .$_fetchKey ] if ( serverData ) { Object .assign ( this .$data , serverData ) window .__NUXT__.data [this .$_fetchKey ] = undefined return } await this .$options. fetch .call ( this ) } , } ) } ) function hasFetch ( vm ) { return ( vm.$options && typeof vm.$options. fetch === 'function' && ! vm.$options. fetch .length ) } 使用するコンポーネント側 export default defineNuxtComponent ( { nuxt2FetchKey: "defineNuxtComponentFetchKey" , async fetch () { // 非同期に何かを取得して設定する } , } ); headメソッド Nuxt2で使用することができるheadメソッドの内部実装がNuxt3で変わり、computedを解釈することができなくなっていました。 例えば以下のようにheadメソッド内でcomputedを使用しているとundefinedになります。 export default defineComponent ( { head () : MetaInfo { return { title: this .hoge , // undefinedになる } } , comptued: { hoge () { return 'hoge' } } , } ) これに対応するために独自にプラグインを作り、Nuxt2と同じような動きをできるように、 xxx.call(this) によるVueコンテキストを注入しての実行、実行後の値をwatchにより監視し、変更後に useHead を使用してmeta情報への適用をするようにしました。 export default defineNuxtPlugin (( nuxt ) => { nuxt.vueApp.mixin ( { data () { return { head: undefined , } } , created () { if ( ! this .$options.oldHead || this .$options.head ) return this .$watch ( () => { return this .$options.oldHead.call ( this ) } , // @ts-expect-error ( newValue ) => { this .head = newValue } , { immediate: true , deep: true } , ) this .$_fetchPromise?.then (() => { this .head = this .$options.oldHead.call ( this ) } ) useHead (() => this .head ) } , } ) } ) コンポーネントを使用する側は head というメソッドを oldHead というメソッドに書き換えるだけで正しくcomputedが解釈できるようにしました。 export default defineNuxtComponent ( { oldHead () { return { title: this .hoge , } } , comptued: { hoge () { return 'hoge' } } , } ) 他にもいくつか問題があり対応をしています。 Apollo NuxtのApolloモジュールは現在Nuxt3対応がされていますが、つい最近まではNuxt3に対応していませんでした vue-apolloを直接使用しNuxtのプラグインとして独自実装 Storybook NuxtのStorybookモジュールは現在もNuxt3は未対応のまま @storybook/vue3を使い独自に実装 axiosの脱却 ApolloのRestLinkへ移行 他にもここには書ききれないほどに様々な対応をしていますが、この記事では省略させていただきます。 私たちはかなり早い段階でNuxt3対応を始めたことでNuxt3のバグを踏むということも多々ありました。 今であればバグも減り、ドキュメントも整ってきているのでもう少し早く移行を進められるかもしれません。 しかし早い段階で対応できたことで本来実現したかった設計の改善に着手できており、この面ではよかったと思っています。 終わり 現在はNuxt3を使って更なる改善に挑戦中です。 この記事がこれからNuxt3へのアップグレードを行う方々の力になれば幸いです。 一休では一緒に働く仲間を募集しています。まずはカジュアル面談からお気軽にご応募ください！ hrmos.co

YADOLINK事業部デザイナーの李と申します。 YADOLINKは、一休が運営する「ホテルや旅館など”宿”が大好きな人たちが集まるSNS」です。宿に特化したサービスだからこそ宿泊体験を気兼ねなく投稿でき、深い共感を得られます。 web版を2022年4月19日に公開し、iOSアプリを2023年1月24日（火）にローンチしました。 YADOLINK by 一休.com IKYU Corporation 旅行 無料 apps.apple.com 1. 写真投稿SNSの “ベーシック” を考える どこまでInstagramに寄せるべきか？ YADOLINKは写真投稿が主要な手段のSNSです。広く知られている写真投稿SNSにInstagramがありますが、「インスタっぽいものだよ！」と簡単に伝えることで、最初の利用するハードルが下がると考えました。どのようにInstagramに寄せて、どのように差別するかを最初に検討しました。 フィードUI Instagramの最も基本的なUIはホーム画面に表示される通常の投稿フィードです。 多くのユーザが使い慣れているUIであるため、YADOLINKでもユーザーの投稿をフィード形式にすることを決定しました。しかし、Instagramのフィードをそのままにするのではなく、YADOLINK独自のユーザーニーズに合わせて、情報整理を行い、以下の部分を差別化することにしました。 1.　 宿に特化したサービスのため、宿泊施設が一番重要な要素となり、フィードに宿泊施設名を表示するように追加した。 2.　 投稿全体に対しての説明だけでなく、写真ごとに説明＆思いを記述できるようにキャプションを追加した。 3.　 「いいね」をするハードルを下げるため「いいね数」だけを表示して、「いいね」をした人のリストは非表示した。 4.　 ユーザーの体験をよりスムーズにするため、ページ遷移せずにコメントできるようにコメントのUIをモーダルにした。（アプリのみ） 5.　 初期リリース時には、お互い知らない人同士の投稿にいいねやコメントすることのハードルが高いと思われるため、いいね数やコメント数が少なくても投稿するモチベーションを高めるため、「閲覧数」という指標を表示することを決定した。 ２列フィードUI 中華圏を中心とした新興SNSを参考に 初期リリース時にはフィードUIのみが提供されましたが、一覧性が低く1スクロールで1～1.5の投稿しか見られない、タイムラインに流れている投稿が自分がフォローしている人の投稿に限らず全ての投稿が表示されるなどの課題がありました。 この課題を解決するために、下記の2つの改善を行いました。 1. YADOLINKでは中華圏を中心とした新興SNSでよく見られる「2列フィード」のUIを導入しました。これは、生活必需品とは異なり、宿みたいな嗜好品を「気になるからとりあえず見てみたい（予約意欲までいかない場合も含む）」という場合、ユーザーのニーズが漠然としていることが多いです。「行きたい宿を探す」というより「漫然とユーザーの投稿を眺めている内に行きたい宿を見つける」という仕様がYADOLINKユーザーに最もマッチすると考えました。「行きたい宿が決まっている」場合は、YADOLINKよりも一休.comの方を利用するユーザーが多いかもしれません。「小紅書」という中国のSNSの2列フィードUIは、このようなユーザーの気持ちにとことん寄り添い、参考になりました！ ※「小紅書」(RED) は、2022年2月時点、登録ユーザー数3億人の動画や写真などを共有できる「インスタグラムとアマゾンが合体したようなアプリ」です。 2. ２列フィードUIの導入に伴い、トップページは「おすすめ」「フォロー」「新着投稿」の三つのタブに分けられ、それぞれがタイムラインとして閲覧できるようになりました。 宿の写真が引き立っていることを一番大事に 一休.comというサービス従来の上質感を残しつつ、新しいサービスとしての活発・躍動感も表現できるようにデザインしています。 主役である宿の写真が引き立っていることを一番大事にしています。InstagramなどのSNSで流行っている写真の上に文字入れインパクト系の画像は上位表示させないなど、一休.comの上質な世界観を取り入れています。 2. SNSは “アプリが命” YADOLINKはWebからスタートしましたが、最初からアプリを意識していました。なぜならば、SNSは「アプリが命」だと考えられているからです。頻繁に開かれるものであり、毎回ブラウザを開くことは大変面倒です。「いいね」「コメント」「フォロー」などの機能にもリアルタイムのプッシュ通知が不可欠です。アプリではウェブサイトで実装が難しいインタラクションも実現できるため、ユーザーの没頭を促し、ストレスなく操作することが期待できます。 下記の図のようにアプリでは ・スワイプでタブ移動、ページ遷移できるようになった ・インタラクションでおすすめ投稿一覧と投稿詳細間がスムーズな往来になった WEB 　 APP アプリ開発に伴い、その他の改善点も整理してみました。興味がある方ぜひ触ってみてください〜 ・新しく実装された関連投稿で次々に行きたい宿が見つかる ・いいねの傾向に基づいたおすすめ投稿の精度向上 ・写真選択段階に並び順を変えられるように ・投稿画像の縦横方向を指定できるように ・トリミング時の画像拡大・縮小 ・入力画面にてスクロースせずに全ての項目を入力できるように ・キャプションの追加などはページ遷移→モーダルに変更 ・自分の投稿へのコメント通知により素早く返事ができるように ・他にも自分への投稿へのいいねやフォロー通知が受け取れる ・受け取りたい通知はカテゴリごとに制御可能 3.まとめ 「YADOLINK」は、お宿を訪れた方が自分で撮影した写真を投稿できる「宿特化型SNS」です。写真を中心に、ユーザーが直感的に好みの宿を探しやすいインターフェースを提供しています。自分自身では言語化できないニーズを発見したり、まだ知らなかった「自分好みのお宿」との偶然の出会いを演出します。 これまで一休にはSNSサービスがありませんでしたが、YADOLINKをきっかけに新しいUIUXに取り組み、試行錯誤しながら多くのことを学びました。 特定のジャンルを絞らないSNSとは異なり、宿泊施設に特化したSNSであるため、ユーザー層や利用頻度などが比較的限定的ですが、UIUXの改善により、より多くのユーザーに愛用していただけるよう努めています。 一休では、ともに良いサービスをつくっていく仲間を積極募集中です。応募前にカジュアルに面談をすることも可能ですので、お気軽にご連絡ください。 hrmos.co

はじめに 社内情報システム部 / CISO室 所属 コーポレートエンジニアの 大多和（ id:rotom ）です。 2022年12月5日、一休は本社オフィスを港区赤坂から千代田区紀尾井町の東京ガーデンテラス紀尾井町 紀尾井町タワーへ移転しました。 ヤフーや PayPay、ZOZO をはじめ、Zホールディングス各社やデジタル庁も入居するビルです。 新オフィスのコンセプト、概要についてはプレスリリースをご覧ください。 prtimes.jp 当社は2022年4月に働き方を刷新し、オフィスワークとリモートワークのハイブリッド制を導入しました。従業員がより高いパフォーマンスを発揮できるよう、オフィスワークの日を職種ごとに週1・3・5回に分けています。移転後の座席は、出社回数に応じて、フリーアドレス・グループアドレス・固定席の「ハイブリッド」とし、オフィス勤務時には従業員同士が円滑にコミュニケーションを取れるよう設計しました。 一休は2022年4月より リモートワークとのハイブリッド勤務となるように働き方が大きく刷新 されました。 本社移転に伴い、ただ現状のインフラのまま引っ越すだけではなく、上記のような時勢に合わせた新しいオフィスファシリティの構築、PBX や FAX のほかオンプレミスサーバーを撤廃した、クラウドネイティブでモダンなコーポレートIT への刷新も行いました。 今回はその取り組みの一部をご紹介します。 この記事は corp-engr 情シス Slack（コーポレートエンジニア x 情シス） #1 Advent Calendar 2022 15日目の記事でもあります。他の素晴らしい記事は以下のリンクからご覧ください。 adventar.org オフィスファシリティ まずはオフィス環境についてご紹介します。一休の前オフィスは5階・6階・7階の3フロアに分かれていましたが、 今回の移転で10階のワンフロアに統合 されました。 これまでの3フロアの床面積を合計しても、なお新オフィスのワンフロアのほうが広いという一休史上最大規模のオフィスです。 執務室 執務室はエンジニアに限らず、営業、バックオフィスなどを含む 全ての座席にエルゴヒューマンのチェアが設置 されています。 後述しますが、今回の移転のタイミングで 各席に置かれていた固定電話を廃止 し、机上への配線は OA タップのみという非常にすっきりしたデスクになりました。 エンジニアエリア 前述の通り、職種に応じてオフィスへの出社日が決まっており、エンジニア職は週1 オフィスワークの職種です。 そのため、各事業部のソフトウェアエンジニアやデータサイエンティストなどの席は、 従来の固定席を廃止しフリーアドレス化 しました。 エンジニア席には LG 製の 4K ディスプレイが標準で配備されています。 USB PD（Power Delivery）給電に対応 しているため、出社時も充電アダプタを持ち歩く必要がなく、USB-C ケーブルを接続すればモニタへの出力と充電を同時に行うことができます。 会議室 / 個室ブース / 集中スペース コロナ前は会議室で対面で行っていたミーティングは、コロナ禍に Zoom や Google Meet を利用したオンラインミーティングへと移行しました。 そのため、新オフィスでは大人数向けの会議室より、1on1 などで利用できる小規模の会議室や、 遮音性の高いオンラインミーティング用の個室ブースや、囲いで覆われた集中ブースで多く設置 されています。 会議室の壁はホワイトボード になっているため、ブレインストーミングなどに最適です。 オフィスは非常に広く、座席も大量にあるのですが、エンジニアにはここが一番人気のようです。 めちゃくちゃ広くて席たくさんあるのにソフトウェアエンジニアにはここが一番人気 pic.twitter.com/3WBj4yyxvv — naoya (@naoya_ito) 2022年12月6日 また、窓際には予約不要で利用できるフリースペースは多く設置されており、ちょっとした打ち合わせにサクッと利用できます。 晴れた日のカウンター席は景観がよく、素晴らしい夕日が差し込むおすすめスポットです。 ラウンジ 社内で「ラウンジ」と呼ばれているのが休憩や食事、社内イベントなどに利用されるリフレッシュスペースです。写真の「イソテーブル」と呼ばれる什器はヤフーで使われていたものを譲り受けました。新オフィスのコンセプト「サステナビリティ」を体現しており、早速ティーブレイクやちょっとした打合せで活用されています。 前オフィスでは、コロナ前はラウンジのあったフロアに全就業員が集まり、経営陣からの実績報告やケータリングの料理やお酒を楽しむパーティーが開催されていました。 また、技術コミュニティのIT勉強会や、外部の経営者をお招きした MANABIBA と呼ばれる経営対談も活発に行われていました。 これらのイベントはコロナ禍では YouTube Live や Zoom ウェビナーを活用した配信方式へ の切り替わっていました。 オフィスワークとリモートワークのハイブリッド制となった今、このラウンジも 会場・配信の双方に最適化されたAV システムに刷新 しました。 社員食堂 / カフェテリア / コンビニ / コワーキングスペース 東京ガーデンテラス紀尾井町 紀尾井タワーはヤフーをはじめ、Zホールディングス各社が多く入居するオフィスビルです。 一休も同じビルへ同居することでヤフーのオフィス設備の一部を利用させていただいています。 1つ上の11階には BASE11 と呼ばれる社員食堂・カフェテリアがあります。紀尾井町は前オフィスの赤坂と比べ飲食店街からは少し離れた場所に位置するため、外食をするには移動しなければなりません。オフィス内に社員食堂があることで、安くて美味しいバランスの採れた食事を日替わりで食べることができ大変便利です。 about.yahoo.co.jp 同フロアにはZホールディングスのアスクル・出前館が運営するコンビニ Yahoo!マート の店舗もあり、オフィスから出なくても食事や日用品を購入することもできます。 about.yahoo.co.jp また、コロナ前は一般の方へも公開していたコワーキングスペースの LODGE は現在はZホールディングス従業員向けに公開されています。 lodge.yahoo.co.jp 一休のオフィスはワンフロアですが、このようにヤフーのオフィス設備も利用させていただくことで快適に業務を行える環境が整っています。 コーポレートIT ここからはコーポレートITの話をします。移転前のオフィスにはサーバールームがあり、オンプレミスで稼働しているサーバーが複数ありました。 これらのオンプレミスサーバーは以前より AWS への移行や SaaS へのリプレイスなどクラウド移行を継続して行っており、移転前の時点ではプロキシサーバーと PBX を残すのみとなっていました。 今回の移転のタイミングでプロキシサーバーをクラウド移行を完了し、固定電話も廃止することで PBX を撤廃し、 新オフィスからはサーバールームが無くなりました。 電話 / Dialpad Enterprise 前オフィスではサーバールームに PBX が設置されており、事業部や本部ごとに電話番号を持ち、各席には固定電話機が設置されていました。 コロナ感染拡大に伴い、全社的に在宅勤務の体制が取られた際に、コールセンターや一部部署で先行して利用していたピュアクラウド型のビジネスフォンシステム Dialpad を全社導入しました。 www.dialpad.co.jp 固定電話の番号を Dialpad で発番した 050 の番号に即時転送をかけることで、オフィスに出社することなく、在宅でも受電対応が行える環境を構築しました。 このときの取り組みは大規模な導入になったため、Dialpad Japan の導入事例としてもご紹介いただいております。 japan.blog.dialpad.com Dialpad はフルクラウドであることから非常に管理がしやすい一方で、IP 電話であるため電話番号が 050 番号でした。 当時は 050 番号から 0120 を始めとするフリーダイヤルへ発信できないことや、03 番号への着信の転送への折返しの際も先方には 050 番号が表示されてしまうため出ていただけないことがある、といった課題感もありました。 この課題を解決するためには自社でゲートウェイを設置する必要があり、フルクラウドである恩恵を得られにくいものでした。 www.softbank.jp 2021年9月に Dialpad Air 0AB-J という新オプションが登場し、 ゲートウェイなどの機器を設置不要で 03 番号（0-ABJ）が利用可能 になったことから、今回の移転のタイミングで オンプレ PBX を脱却し、Dialpad へ一本化 することを決めました。 この際、利用部門が大きく拡大することから グループ数が無制限となる最上位プランであり、Azure AD による SAML/SSO や SCIM にも対応した Enterprise にアップグレード を行いました。 現在は元から固定電話のないエンジニアをのぞく、全ての部門で Dialpad を利用しています。 FAX / FAX PLUS Enterprise PBX を同じく、オフィスに設置されているオンプレミス機器として FAX の存在がありました。 事前のヒアリングから事業部、管理本部ともに FAX はすでに業務でほぼ利用されていないことは分かっていましたが、官公庁やビルの防災センター、クレジットカード会社など、一部 FAX でしか受付を行えない組織との取引手段として、FAX は今後も残す必要がありました。 従来の FAX はアナログ回線を引き込み複合機から送信するものでしたが、これもオフィスからではないと送受信が行えないため現在の働き方には合っておらず、フルクラウド型へ移行しました。 選定したのは FAX PLUS というスイスのオンライン FAX サービスで、 マルチプラットフォームかつ Web アプリから利用可能 なものです。 www.fax.plus 海外 SaaS ではあるのですが、 日本の FAX 番号を取得することが可能 です。2022年12月時点では 050 番号のみ利用可能で、03 番号などの 0-ABJ は利用できません。 050 番号の取得には日本の法律により審査が必要で、登記簿謄本や代表者（または委任を受けた担当者）の本人確認書類などの提出が求められます。サポートとは英語でのやりとりなので難易度は少し高めでした。 FAX PLUS も 最上位である Enterprise プランを契約し、Azure AD による SAML/SSO や SCIM を構築 しています。 また、 Slack とのインテグレーションが可能 であり、FAX を受信した際は Web アプリを開くことなく、Slack のチャンネルから直接 PDF で閲覧・ダウロードが可能です。 入退室管理 / Akerun コントローラー オフィスの入退室を管理するセキュリティ製品も、移転前にオンプレミスサーバー型のものからクラウド型のものへリプレイスを行っていました。 Akerun コントローラー という製品です。 akerun.com Akerun というと、WeWork などのレンタルオフィスに工事不要で設置ができる Akerun Pro のイメージが強いかもしれません。 今回選定している Akerun コントローラーは、専門業者の工事により、 既設のオフィスビルの電子錠や自動ドアにも対応 したものです。 corp.teamspirit.com また、Akerun は勤怠管理システムである TeamSpirit と API 連携を行うことが可能 であるため、 オフィスに出社した際には出勤・退勤が自動打刻 されるように設定を行いました。 一休は北海道から沖縄まで多くの拠点を持ちますが、 全ての拠点で Akerun へのリプレイスが完了 しており、勤怠打刻の自動化は多くの従業員に喜んでいただけています。 終わりに 今回の移転ではモダンなオフィス・コーポレートIT環境へ一気に推進することができており、キラキラなオフィス環境にも見えるかもしれません。 一方で、タイトなスケジュールの中でのオフィス移転は、想定外のトラブルも含め多くの課題もあり、 まだまだ改善・進化の余地が残されています 。 情シス / コーポレートエンジニアとして、エンジニアを含む 従業員体験を向上 を目指し、皆さんがより快適に業務を行うことができるオフィス・コーポレートIT 環境を目指して、引き続き全力でやっていきます 💪 突然ですが、ここで CM のお時間です 一休ではソフトウェアエンジニアをはじめ、多くの職種で積極的に採用を行っています。 選考をともなわないカジュアル面談からも受け付けておりますので、お気軽にご応募ください 👋 www.ikyu.co.jp エンジニア採用の Twitter アカウントも開設し、イベント告知などを発信しています。こちらもフォローお待ちしております。 twitter.com また、今回ご紹介した話はコーポレートITの取り組みの一部です。より深堀りした内容を Business Technology Conference Japan（BTCONJP） というITのカンファレンスでもお話させていただく予定です。 ご都合の合う方はこちらも是非オンラインにてご参加ください 🙏 btcon.jp

プロダクト開発部デザイナーの安松と申します。 10/3、新サービスの「一休.comふるさと納税」がローンチしました。 選んだ宿がある自治体に寄附をすると、一休.comで使える割引クーポンを返礼品として、web上で受け取れるというサービスです。 一休.comの宿泊予約とは違ったサービスですが、予約へとつながるサービスをどのようにデザインに反映させたか、また 一休.comの宿泊デザインシステム の活用やFigmaを使ったことを振り返ります。 目次 １） ふるさと納税サイトで意識したこと ２） 宿泊のデザインシステムを活かせるか ３） Figma導入後、初のゼロからデザイン ４） まとめ 1. ふるさと納税サイトで意識したこと サービスコンセプトのすり合わせ モックを作成するにあたりビジネスサイドから、サービスの概要やターゲット層に加え、一休.com（宿泊）のUIを活かしたい、とにかくシンプルに…などの要望をもらいました。また、今回のプロジェクトは、短期期間での開発ということもあり、主要な導線の要素が大筋決まっていたので、画面イメージを早く作り詳細をすり合わせながら「どんなユーザー体験にしたいか」のヒアリングや掘り下げ、他のデザイナーからのフィードバックを受けながらの作成です。 デザインにどう反映したか まずは既に一休.comを使っていただいているユーザーがターゲットです。どのようにデザインに反映したかまとめます。 ユーザーが「寄附」と「予約」を混乱しないように 宿泊と同様に宿から選ぶのですがあくまで「寄附」をするサイト。宿の情報などは最低限にして「予約」に関する宿の情報やプランは、宿泊サイトで確認していただくような作りです。行き来することも考え、メインとなる画像の見せ方も差別化しました。 宿のカードも差別化のため、ベースは活かしつつ意図的にデザインを変更しています。 シンプルかつスムーズに 情報もシンプルにしたので、使用する色も少なくし、目立つアクセントカラーをCTAボタンとして寄附完了までの道しるべを明確にすることで、迷わずスムーズに手続きいただけるよう意識したポイントです。 安心して寄附していただけるように 高額の寄附かつ変更やキャンセルができないため、特に寄附やクーポンに関する注意事項の配置や寄附金額・返礼品としてもらえる割引クーポン額の表示には気を付けました。 2. 宿泊のデザインシステムを活かせるか ふるさと納税サイトを着手するの少し前から、宿泊では デザインシステムの導入 を始めており、デザインツールをXDからFigmaに移行し、デザインコンポーネントを大小さまざまな粒度で作成しています。こちらを活用することで宿泊のUIを活かしつつ、ふるさと納税サイトを組み立てようと考えました。実装上はコンポーネント化されておらず、宿泊のように、デザインとコードの連動はしていません。 実際にどの部分を採用したか一部をご紹介します。 タイポグラフィー 一休らしさを担うタイポブラフィー全般（書体・サイズ・太さ）はそのまま使用しています。 フォームのUI・パーツ 一休.comのユーザーが使い慣れているUIを活かすため、入力画面や決済画面はページ全体、ラジオボタンや入力フォームなどのパーツもほぼそのまま取り入れています。 タブデザイン 実装面でも宿泊と同様のTailwind CSSを採用していたこともあり、角丸やシャドウ、padding/marginなどの細かい部分も同じように使えたのもよかったことです。 このように別サービスでも、一休.comの宿泊デザインシステムで定義したデザインの基本要素や粒度の細かいコンポーネントが活用でき、「一休.comのUIを活かしたい」にも繋がったのです。また、活用したことで統一や上記で挙げた部分を考える時間は、他の作業に当てることができました。 user-first.ikyu.co.jp 3. Figma導入後、初のゼロからデザイン 宿泊でFigmaを使い始めた際、ツールの使い方に慣れず苦悩していました。さらに、既存サービスである宿泊デザインシステムではどのコンポーネントにするかを現状のデザインを見ながら考えていましたが、今回は新規サービスであったため、現状のデザインはない状態で新しいデザインの検討やパターン出しをすることに苦労しました。慣れないツールと新規サービスという2つの難しさが重なったことが辛かったです。 テキストスタイル・色の定義で大失敗、慣れるまで時間がかかった デザインする中で、宿泊のコンポーネントを変更して使いました。それは問題のないことですが、ふるさと納税側で新しく定義する色を試行錯誤している段階では、Color Stylesで定義せずに進めていました。 結果様々な画面でパターンを出した後に定義を追加したため、作成済みのモックで色やテキストの置き換え作業が発生してしまいました。 仮の状態で後から微調整をするからこそ、定義をしておくべきでした。また、色の選考の際は定義したカラーリングごとにフォルダを作るなどをして、Figmaの便利な機能を活用できそうです。 コンポーネントも散らかり気味で、同じようなものができたり、手動で置き換え作業も何度もしましたが、最終的にページを横断して使うコンポーネントはまとめて管理し、ライブラリとして公開した後は、変更を加えると反映される状態になっていきました。ある程度デザインが固まったときにコンポーネントの見直し・整理をするというのも大事かもしれません。 4. まとめ デザインに入る前に「どんなユーザー体験にしたいか」を掘り下げ事前に話し合ったことで、新しい機能や改善の際も、検討中の時にそれがぶれていないか？と一つの指標になり、チームが同じ方向を向けたと思います。 また、ふるさと納税では、宿泊のデザインシステムがあって本当によかったと感じています。統一感やスピードの面で活かすことができたためです。ただ、別サービスでも使用するという目的で作られていないため、今後の扱いは改めて検討する必要はありそうです。 そんな中、一休のサービスを横断したガイドラインを作成するプロジェクトが、デザイナー主体で始動しました。どのサービスを使ってもユーザーにとって素晴らしい体験ができるよう、さらに進化をしている最中ですので、今回の経験が少しでも役立てばよいなと思います。 一休では、ともに良いサービスをつくっていく仲間を積極募集中です。応募前にカジュアルに面談をすることも可能ですので、お気軽にご連絡ください。 hrmos.co

こんにちは、プロダクト開発部の野口です。 一休にはたくさんの施設紹介ページがあるのですが、その中でもキュレーションページという流入数が高いページがありました。それをメイン動線であるリストページに統合したので、その経緯や裏側をご紹介します。 一休の施設掲載ページはたくさんある 一休には施設をまとめて掲載するページがたくさん存在します。 リストページ(メイン動線) https://www.ikyu.com/area/ma000000/t105/si1/?adc=1&asc=01&cid=20221008&cod=20221010&hoi=1,2&lc=2&mtc=003&per_page=20&pn=1&ppc=2&rc=1 キュレーションページ https://www.ikyu.com/theme/t105/ 観光ページ 特集ページ などなど。。。 その中でも今回はキュレーションページをリストページに統合したというお話です。 どうして統合したの？ キュレーションページは検索するためのページというよりも、検索エンジンからの流入口として用意されているものになります。そのため閲覧数は一休の中でもかなりいいほうなのですが、受動的な情報ばかりなので残念ながら予約までたどり着く割合は低かったのです。 一方でメイン動線であるリストページは検索に特化しており、ユーザが能動的に欲しい情報を要求し、的確な情報を表示できます。そのため予約までたどり着く割合も高く、メイン動線としての役割をしっかりと全うしています。 この2つを統合することで流入数と予約割合のどちらも高めたいというのが狙いになります。 苦労したこと キュレーションページというのは、「地域xテーマ」ごとにページが生成されており、施設はランキング形式で表示されています。(先に掲載した画像は各キュレーションページの親ページになります) 一方でリストページはさまざまな条件で検索ができるのですが、キュレーションページと同じように「地域、テーマ」による検索もできます。しかもランキング形式での表示もできるため、キュレーションページと同じようなページを再現できます。 しかしながら、同じ条件で検索してもキュレーションページに表示される内容と異なることがあったのです。 原因はランキング生成ロジックがそれぞれのページで異なっていたからです。 もちろんどちらも八百長ということはなくデータに基づいてランキングを生成しているのですが、細かい条件が少しずつ異なり、結果別の施設が表示されてしまったのです。 実装方針ですが、キュレーションページには親ページが存在し、親ページでもランキングを掲載しており、その親ページは残すという前提がありました。そのためリストページにキュレーションページのロジックを持ってくる必要があります。しかし一休ではアーキテクチャを更新している最中で、キュレーションページ側は旧アーキテクチャ、リストページ側は新アーキテクチャと別れてしまったためロジックの移植はしないことにしました。代わりにキュレーション側のアーキテクチャで「エリアIDとテーマID」を受け取ってランキングを返すAPIを作成し、それをリストページのアーキテクチャが叩くことにしました。 進捗は順調・・・かと思ったら・・・ 大体のページではランキングの結果が一致するようになり開発は順調かと思われたのですが、一部のページに限ってランキングの結果が合わない状況に直面しました。 キュレーションページのURLをよくよく見てみると、なにやら見たことない数字がいました。 https://www.ikyu.com/theme/a140000/g10/101/ 「a140000」は東京を表すエリアIDで、「101」というのがテーマIDになります。「g10」は何者だ・・・？ キュレーションページに詳しい方に聞いてみると、どうやらキュレーション関連のページ限定の概念であるジャンルIDをいうものもページ生成に影響しているようで、「地域xテーマ」ではなく「地域xテーマxジャンル」で生成されているとのことでした。 ここで困ったことが起きました。 APIの方は単にジャンルIDも指定できるようにすればよかったのですが、リストページではジャンルIDという概念がないため、そもそもAPIのパラメータに含めることができなかったのです。 ジャンルIDを無視することも検討したのですが、それだとキュレーション親ページに表示されている施設とリストページに表示されている施設が異なってしまう可能性があります。一休ではユーザファーストを掲げているため、そんな体験は許されません。 そこでリストページのアーキテクチャにジャンルIDという概念を組み込むことにしました。「リストページ」に組み込むのではなく、「アーキテクチャ」に組み込みます。このため当初予定していたよりも多くの改修が必要になり、リリース予定日も延長してしまいました。 ですが、最終的には要件を落とすことなく、ユーザ体験も悪化させずにリストページに統合することができました。先のリンクを開くとリダイレクトしてリストページが開くのですが、「g10」の部分を変えることで結果が変わることを確認できると思います。 統合を終えて 今回の統合では要件を落としたり、無理やり実装したりという部分もいくつかあったためちょっと悔しい思いも残っています。 しかし訪れた人が予約した割合を比較してみると、統合前に比べて約1.6倍ほどに増えていました。少しでも使い勝手が良くなったと思い、端的に嬉しかったです。 今後のプロジェクトでもより良い体験を提供できるよう精一杯努力して参ります。 hrmos.co

前回好評だった一休と出前館のオンライン・イベント Frontend Meetup の第2回を開催します。 イベント後のアーカイブ動画を公開しませんのでご興味がある方はぜひご参加ください！ 日時：9/29(木) 18:00~20:00 費用：無料 場所：オンライン（Zoom） お申し込みは以下のリンクからお願いします。 ikyu.connpass.com 時間 内容 登壇者 18:00 ご挨拶 18:05 - 18:25 一休. com/Yahoo!トラベルのNuxt3移行における開発プロセス 杉田 隆紀 18:25 - 18:45 React 18 に見るユーザーファーストなローディング表示 yoshiyamay 18:45 - 19:05 Testing for Demae-can App 黒澤 慎治 19:05 - 19:35 パネルディスカッション 20:00頃 終了

Apollo Client は複雑 Apollo Client が向いているケース 一休.com に Apollo Client は必要ないかもしれない では何を使えばいいの？ 複雑なアプリケーションには Apollo を使えばいい？ もう一つのリッチなクライアント、Relay の話 結局、何を使えばいいのか この記事は一休 × 出前館 Frontend Meetup でお話した内容をブログにまとめたものです。 user-first.ikyu.co.jp speakerdeck.com GraphQL クライアントと聞いて一番に思い浮かぶライブラリは何でしょうか？ 多くの方にとっては Apollo Client ではないかと思います。npm trends を見ても Apollo Client のダウンロード数は urql や relay などほかのクライアントと比べ圧倒的です。 実際、一休でも 一休.com や YADOLINK で Apollo を利用しています。 サービス GraphQL クライアント 一休.com Apollo Clinet YADOLINK Apollo Client レストラン座席管理画面 なし (axios) （新）EC① urql （新）EC② urql （新）予約管理画面 Relay しかし、Apollo Client は 「一番有名だから」という理由で使っていいほど無難なライブラリではありません。どちらかといえば、使い所を選ぶ癖のあるライブラリだと私は考えています。 この記事は一休での採用事例を交えながら GraphQL クライアントの選び方についてお話します。もしかすると、Apollo Client はあなたのプロダクトに合っていないかもしれません。 Apollo Client は複雑 以下の図は主要なクライアントライブラリをバンドルサイズが小さい順に並べたものです。これは正確な指標ではありませんが、バンドルサイズの大きさと、機能の豊富さ・複雑さは比例していると考えると Apollo や Relay が比較的複雑なライブラリだということがわかります。 name minified + gzipped cross-fetch 2.8kB graphql-request 7.6kB urql 8.5kB @apollo/client 40kB react-relay 55kB バンドルサイズを小さくするために、別のクライアントを使えと言ってるわけではないことに注意してください。バンドルサイズも重要ですが、"必要最低限の機能を持っているライブラリを使う" ことが大切です。 さて、GraphQL クライアントの仕事とは何でしょうか。突き詰めると HTTP リクエストを発行してAPIサーバーと通信することです。実は専用のクライアントを使わずとも fetch で GraphQL サーバーと通信ができます。 では cross-fetch のようなシンプルなクライアントと比べ、なぜ Apollo Client はこんなにもバンドルサイズが大きいのでしょうか？ 通信以外に Apollo が提供している機能とは何でしょうか。 その答えは公式ドキュメントに書いてあります。 Apollo Client is a state management library that simplifies managing remote and local data with GraphQL. ― Apollo Clientは、GraphQLを使用してリモートデータとローカルデータを簡単に管理できる状態管理ライブラリです。 Apollo Client は "状態管理" ライブラリなのです。 Apollo Client を導入する際は、まず「このアプリケーションに状態管理ライブラリは必要か？」という問いに答えなければいけません。答えがNoであれば Apollo Client は必要ありません。 かつてSPAと状態管理ライブラリはセットでした。どのプロダクトのコードを覗いても必ず状態管理ライブラリが入っていました。しかしグローバルな状態のデメリットが認知された現代では、状態管理ライブラリはアプリケーションにとっても必須のパーツではありません。 Apollo Client が向いているケース Apollo Client が向いているアプリケーションとはどんなものでしょうか？ Apollo Client は "Mutation が頻繁に発生し、かつ Mutation 後に refetch できない" 性質を持つアプリケーションで真価を発揮します。例えば、Twitter や Instagram、我々が運営しているものだとYADOLINKのようなSNSに向いているでしょう。キーワードは『無限スクロール』です。 YADOLINK 無限スクロールにより複数ページのデータ取得した後、特定のアイテムに Mutation を実行するときを考えてみます。例えば、投稿に「いいね」するという操作です。「いいね」が完了すると、投稿のハートアイコンに色が付き、いいねがカウントアップします。 Apollo Client は Mutation のレスポンスを元に1ラウンドトリップで特定の投稿の値を書き換えます。これは Apollo Client の特徴である、"正規化されたキャッシュ" のおかげです。 mutation { likePost ( postId : Int ! ) { postId likeCount isLiked } } 反応速度を少し犠牲にすれば、 Mutation 後にページを丸ごと再取得することで同じことが実現できます。実際、urql の Document Cache では Mutation 後に関連するクエリを再取得することでUIを更新します。 しかし無限スクロールによるページネーションを実装している場合は、現在の状態を復元するために複数ページ分のリクエストを発行する必要があるため、すべてのデータを再取得する戦略が現実的ではありません。 逆に言うと、そもそも Mutation がほとんど発生しないアプリケーションや、Mutation 後にデータの再取得によってUIの更新をすることが許されるケースでは Apollo を使う必要はありません。 一休.com に Apollo Client は必要ないかもしれない さて、では Apollo Client を採用しているもう一つのアプリケーション、我々の看板サービスである「一休.com」はどうでしょうか？ 実は一休.comは Query がメインで Mutation がほとんど使われていません。 ECサイトという性質上、一休上で発行されるリクエストのほとんどは "検索クエリ" です。最も重要な操作である "予約" はもちろん Mutation ですが、予約処理後に別ページへ遷移するので Mutation 後にローカルの状態を更新する必要はありません。他にも、クーポンの獲得・お気に入りの追加といった Mutation がありますが、これらもデータの再取得をすれば十分です。 検索 ... Query 予約 ... Mutation クーポンの獲得 ... Mutation お気に入りの追加 ... Mutation 大は小を兼ねる、という一面もあり Apollo Client は一休.comで必要なユースケース "も" カバーしているため、普段の開発では Apollo を使うデメリット感じることはほとんどありません。 しかしエッジケースにおいて、過分なライブラリを使っているせいでトラブルに巻き込まれることがあります。たとえば、一休.com ではIEからのアクセスに対して、Apollo の Store を fork した自前のキャッシュ機構を使うような実装になっていました。これは Apollo Client のキャッシュの正規化がIE上の特定のデータで非常に時間がかかってしまうためです。ひと月以上の時間をかけて Apollo Client のコードを読み、workaround を実装しました。 また、Apollo のプラグインの対応状況が芳しくないせいで、Nuxt3 へのマイグレーションが遅れてしまっています。 もっと軽量なライブラリを使っていれば、こういったトラブルにも巻き込まれいなかったでしょう。自分たちが必要な "一番ミニマムな実装" を採用することが重要だと学びました。 では何を使えばいいの？ では、Apollo が必要ないというケースではどのクライアントを使えばいいでしょうか？ urql や graphql-request がおすすめです。 Apollo が正規化されたキャッシュを持つのに対して、urql は Document Cache というシンプルなキャッシュ機構を採用している点が特徴です。urql は Mutation の実行後に Mutation の戻り値と同じ __typename を取得している Query をすべて再取得します。少し乱暴なようにも感じますが、この方法で十分というアプリケーションも多くあるはずです。 また、Next.js を使っているなら swr + graphql-request という組み合わせも良いでしょう。graphql-request はもっともシンプルな GrapQL クライアントで、状態管理機能を持ちません。クライアント固有の状態がなく、APIレスポンスのキャッシュとして状態を扱うだけであればこの組み合わせがマッチします。swr は Vercel が作っているだけあって、Next と組み合わせてSSRするのも簡単なので要件によってはこちらを検討してみてください。 複雑なアプリケーションには Apollo を使えばいい？ ここまで、「シンプルなアプリケーションにはシンプルな GraphQL クライアントを使おう」というお話をしてきました。では、複雑なアプリケーションでは Apollo Clinet を使うのが正解なのでしょうか？ 実はそうではありません。複雑なアプリケーションの中には Apollo と相性が悪いものも存在します。それはサーバーのAPIキャッシュとは別に、リッチな状態を持つアプリケーションです。例えば、われわれが運営しているアプリケーションだと、レストランの席管理画面などがこれに該当します。 座席管理画面 これは日付ごとに何席を一休レストランに提供するかを管理する "在庫カレンダー" と呼ばれる画面です。カレンダー内で日付を選んで、席毎にその日の提供座席数を決定します。曜日一括操作などもあり、サーバーとすぐに同期しない状態操作が多く存在します。 Apollo にはサーバーと同期する状態の他にローカル固有のデータを操作する機能も提供しています。これは Reduxや Vuex が提供する状態管理と同等のものです。一休.com では一部のこの Local State Management の仕組みを利用していますが...正直なところ Redux, Recoil などの専門の状態管理ライブラリと比べてインターフェースがこなれておらず、あまり使いやすいとは言えません。 Apollo で "ローカルの状態管理もできる" ことは確かですが、複雑な状態管理には素直に状態管理ライブラリを入れることをおすすめします。この場合は GraphQL クライアントで状態管理する必要はなくなるので、Recoil + graphql-request などの組み合わせ検討すると良いでしょう。 上記の座席管理画面では GraphQL クライアントは使わずに axios でAPIサーバーと通信し、Vuex で状態管理を行っています。axios で GraphQL の型の恩恵をあまり受けられていないので...もし作り直すとしたら axios ではなく、 graphql-request を使い、GraphQL Code Generator でコードと型の自動生成を行いたいです。 もう一つのリッチなクライアント、Relay の話 最後に、Apollo Client と並んで高機能な Relay について少し触れます。Relay も正規化されたキャッシュを持つ GraphQL クライアントです。ユースケースとしては Apollo Client とほぼ同じだと考えていいでしょう。 では Apollo ではなく、 Relay を使うべきなのはどういったときでしょうか？ 以下のケースでは Relay を検討してもいいでしょう。 コードの自動生成 + Fragment Colocation したい ページネーションされた要素に対して頻繁に要素の追加・削除を行う React の Experimental な機能をいち早く試したい Relay には Relay Compiler というコンパイラが付属しています。コンパイラの仕事はコード内の graphql タグから型情報を含むファイルを自動生成することです。GraphQL Code Generator 相当の働きをしているというとわかりやすいかもしれません。また Relay でアプリケーションを作ると自然と Fragment と Component が一致する Fragment Colocation スタイルになります。 Relay には便利なディレクティブがいくつか追加されていますが、私が注目しているのは @appendNode @prependNode ディレクティブです。これは connection に対する要素の追加を宣言的に行えるディレクティブです。Apollo Client で要素を追加する際は手続き的にはキャッシュを操作する必要がありますが、Relay ではそれらの操作はライブラリ内に隠蔽されます。Facebook で利用されているだけあってSNSを作るのに便利な機能がほかにもあります。 Relay は Meta 製のライブラリだけあって React の実験的な機能の取り込みが早いです。Suspense についても Suspense が Experimental の頃から対応していました。今後も先進的な機能が先取りされる可能性があります。ドキュメントが足りないのが懸念点ですが、トータルでは筋がよく、React エコシステムの未来を反映しているライブラリだと考えています。 一休ではとある新規サービスの予約管理画面を Relay を使って開発中です。 社内向け管理画面のようなシンプルな管理画面にはシンプルな状態管理機構を持つ graphql-rquest / urql が向いていると思います。ただ、この予約画面はレストランの方も使うSaaSのような位置づけの管理画面なのでUXを重視して Relay を採用しています。 YADOLINKはSNSですし、GraphQL Code Generator でのコード生成、Fragment Colocation も採用しているため、現在リリース中のアプリケーションの中ではYADOLINKが一番 Relay と相性が良さそうです。YADOLINKのアプリ版を React Native で作ることを検討しているので、その際は Relay が第一候補です。 結局、何を使えばいいのか さて、まとめです。 Apollo Client が圧倒的な知名度を持っているので Apollo Client を批判するような内容になってしまいましたがそうではありません。 Apollo Client が向いているアプリケーションもあれば、もっとシンプルなクライアントで十分な場合もあります。 最後に簡単なフローチャートを掲載します。 ECサイトや管理画面には Apollo は too much かもしれません。 Apollo Client や Relay、urql + GraphCache のようなリッチなクライアントはSNSのようなユーザーの Mutation が頻繁に発生するサイトに向いています。 GraphQL クライアントの選び方