一休.com Developers Blog

一休のエンジニア、デザイナー、ディレクターが情報を発信していきます

エンジニア主導でデザインシステムを導入してみた

レストランプロダクト開発部の矢澤です。

一休では「RESZAIKO」というプロダクトの開発を行っています。 この開発を進めるにあたり、UI/UX に関するいくつかの課題があり、エンジニア主導でデザインシステムを構築することにしました。

本記事では、エンジニア主導でデザインシステムを構築することになった背景や、実際に取り組んだ内容について赤裸々にお話しします。

デザインシステムの導入を検討しているものの、最初の一歩を踏み出せずにいる・あるいは何から始めればよいかわからないチームにとって参考になれば幸いです。

そもそも RESZAIKO とは

RESZAIKO は飲食店の予約管理を DX する SaaS 事業で、現在3つのプロダクトを提供しています。

  • 複数予約サイトの在庫を一括管理する「サイトコントローラー」
  • 予約や顧客情報を管理する「予約台帳」
  • 店舗独自の予約ページを提供する「Web予約」

現在は3つのプロダクトがありますが、元々はサイトコントローラーだけを提供しており、予約台帳とWeb予約は後発のプロダクトとしてリリースしました。

デザインシステム作成の背景

後発プロダクトの開発を進めていく中での課題

私たちはサイトコントローラーがある状態で、「予約台帳」と「Web予約」の開発に着手しました。 同時進行で開発することになったこの2つの後発プロダクトは、既存プロダクトであるサイトコントローラーの UI/UX を参考にして設計・開発を進めていましたが、さまざまな課題に直面しました。

課題① スピード感を持ってデザインを固めていくことが難しい

RESZAIKO にはサイトコントローラーの開発時から社内に専任のデザイナーがいなかったため、社外のデザイナーと週一回のミーティングでデザインを進めています。 限られた時間で多くの画面のデザイン調整を行うことは難しく、簡単な画面はエンジニアがデザインすることもありました。しかし、デザイナー以外デザインルールの把握ができていない状況であったため都度認識を合わせる必要があり、スピード感を持って進めていくことができませんでした。

課題② プロダクト間で UI/UX の統一感を生み出しづらい

RESZAIKO は飲食店のスタッフが3つのプロダクトを横断して使用することを想定しています。横断して使用しても違和感のない操作を提供するために UI/UX を合わせる必要がありましたが、デザインや操作感に関する知見を開発チーム間でうまく共有できず、差異が生じてしまうことがありました。

これを防ぐために、社外のデザイナーに Figma 上でコンポーネントの置き場を作成してもらいました。 しかし、各プロダクトで使用するための仕組み化ができず、操作感の統一も Figma 上で十分に表現されていなかったため、うまく運用することができていませんでした。

課題③ デザインのクオリティの担保が難しい

同一プロダクト内で同じコンポーネントを使用していても、余白の取り方やコンポーネントの組み合わせ方など細かい部分まで統一することは難しいです。実際に、既存箇所を参考にしてできた画面は、大枠は同じでも完璧には揃えられておらず、画面ごとに少しずつ違いが出てしまいました。 また、デザインに関するチェック基準がないため、チーム内でのレビューもある程度までしか確認できず、デザイナーのレビューも毎回細部までチェックすることができない状態でした。

このような課題を感じながら当初は開発を進めていましたが、リリースが近づくにつれ、デザインのスピード感がボトルネックになり始めました。 そこで、エンジニアの中から比較的 UI/UX にこだわりをもつ3人が集まり、RESZAIKO デザインシステムを作成することになりました。

デザインシステム構築の流れ

このようにしてデザインシステムを作ろうという話になったものの、メンバーがエンジニアだけだったため、デザインシステムに関する知見が不足していました。 そこで、知見を得るために「ちいさくはじめるデザインシステム」という本を読むことにしました。

ちいさくはじめるデザインシステムbnn.co.jp

この本は、SmartHR 社のデザインシステムの取り組みを例にデザインシステムの構築・運用の方法について書かれています。 私たちはこの本を参考に以下の流れで進めていきました。

コンセプト設定

デザインシステムは、流行っているからや、なんとなくデザインの課題が解決しそうという理由で作成しがちです。 しかし、「ちいさくはじめるデザインシステム」には前提として目的が必要であると記載されていたため、まずデザインシステムを作成する目的を改めて定めるところから始めることにしました。

デザインシステムには正解がなく、「デザイン」という何らかの目的を機能させるための「システム」であり、システムとして成立させるために何らかの目的が必要

集まったエンジニア同士で現在感じている課題点を挙げ、それらの解決には何が必要なのか、どのような状態が理想なのかを話し合いました。 その結果、以下のようなデザインシステムのコンセプトとして明文化しました。

デザインシステム コンセプト

  • デザインと開発を効率化し、課題解決に集中できる環境を作り、リリースや改善サイクルを早くする
  • デザインに一貫性をもたせ、ユーザービリティとアクセシビリティを向上させる（サービス単体）
  • 3つのプロダクトを違和感のないユーザー体験を提供する
  • 非デザイナーとデザイナーとのコミュニケーションとして使用し、共通認識を作る手段とする
  • 非デザイナーが自走して簡易的なデザインを行えるようにする（デザインのよりどころにする）

構成決め

コンセプトを決めたところで、次にデザインシステムをどのような構成で実際に作成していくのかを検討しました。

構成を決めるにあたって、まずは他社のデザインシステムではどのような項目を採用しているのか調べました。 「ちいさくはじめるデザインシステム」にあるとおり、全てを網羅する必要はないため、調べたすべての項目を採用するのではなく、必要なものを取捨選択したり独自で項目を追加したりしました。

スタイルガイドには様々な種類がありますが、すべてを網羅している必要はありません。必要や目的・組織などに応じて柔軟に選ぶことができます。

私たちが特に参考にしたデザインシステムは、「SmartHR Design System」「Spindle」「デジタル庁 デザインシステム」の3つです。 「SmartHR Design System」はトークンやコンポーネントなど基本要素が網羅されているため、アウトライン作成の参考にしました。 「Spindle」は定義したコンポーネントの使用ルールがわかりやすくまとめられていたため、デザインルール作成の参考にしました。 また、今回作成するデザインシステムは元々コンポーネント置き場として使用していた Figma に定義したいと考えていたため、「デジタル庁 デザインシステム」のまとめ方を参考にして作成することにしました。

レビュー

デザインシステムのコンセプトと構成が決まったところで、他のプロダクトのデザインシステムを作成している方にレビューを依頼しようということになりました。 一休.com ではすでにデザインシステムが構築されているため、その作成に携わったデザイナーやエンジニアにレビューを依頼しました。

user-first.ikyu.co.jp

レビュー会では、定義するコンポーネントに対してどのように使うのかルールを記載した方が良いというアドバイスをいただきました。 これを受け、もともとルールは「デザインパターン」という名目でレイアウトに関することを定義する予定でしたが、これを「デザインルール」という名称に変更し、コンポーネントの使い方まで定義することにしました。 また当初は Figma 上でガイドラインの定義のみを行う予定でしたが、せっかくエンジニアが作成しているのだからライブラリまで作成したらどうかと提案をいただき、ライブラリの作成も試みることにしました。

そして、最終的に決定した構成がこちらです。

  • 利用の手引き: デザインシステム構築の目的・利用方法
  • デザインフィロソフィー: RESZAIKOプロダクトが大切にしていること
  • デザイントークン: デザインシステムにおける最小単位のスタイル定義
  • コンポーネント: UIを構成するための最小単位のパーツやアイコン
  • デザインルール: デザイントークンやコンポーネントを使用する際のルール
  • ライティングガイド: です/ます調や句読点の打ち方
    • チェックリスト: デザインシステムに則っているか判断するための確認項目

この中でも、まずは最小限でリリースしてみようということになり、主要部分となる「デザイントークン」「コンポーネント」「デザインルール」の策定を初回リリースの目標として進めていくことにしました。

作成

レビューのフィードバックを受けたところで、デザインシステムの作成に着手しました。 本業の実装も並行で行っていて、あまり時間を確保できない中、Figma に各自がトークンやコンポーネントを追加し、週に1回3人で集まってお互いが作成したものにフィードバックを行うという流れで進めました。 また、3人の中で合意が取れたものは、社外のデザイナーに確認してもらい、エンジニアとデザイナーの双方が問題なく使用できるように整えていきました。

実際にできたデザインシステムの一部をお見せします。

デザイントークン

コンポーネント

デザインルール

β版リリース！

初回リリースとして掲げていた「デザイントークン」「コンポーネント」「デザインルール」の作成がある程度完了したところで、β版のデザインシステムとしてチームに展開しました。

現在は、実際に社外のデザイナーや開発メンバーに利用してもらい、元々の定義で不十分だった内容を拡充したり、新たなUIについては都度定義を追加したりしています。 デザインシステムを通じて、デザイナーとのコミュニケーションが円滑になっただけでなく、エンジニア同士でもデザインに関する会話ができるようになり、コミュニケーションツールとしても機能しはじめています。

まとめ

本記事では、RESZAIKO デザインシステムの導入背景からβ版リリースまでの流れをご紹介してきました。

エンジニア主導でデザインシステムを構築してみると、前提知識が不足していたことから調査しなければならない事柄が多く、最初の段階ではリリースまでたどり着けるのか不安に感じることもありました。 しかし、実装で必要になるコンポーネントやデザインルールが明らかなので、Figma への定義のフェーズに移ってからは特に迷うことなく進めることができました。 自分たちが実装時に必要としているものをダイレクトに反映することができることは、エンジニア主導で作成するメリットだと思います。

今回デザインシステムを導入したことにより、当初感じていた3つの課題は解決できたのかという点についてですが、解決できた部分もあればもう少し手を加える必要がある部分もあると感じています。

課題① スピード感を持ってデザインを固めていくことが難しい

デザイナーとエンジニアの共通言語ができたことにより、デザインに対する質問の精度も上がり、コミュニケーションが取りやすくなったため、これまでよりスピード感を持って開発が進められるようになってきました。

今後は、さらにデザインルールなどをアップデートし、デザインについて考えやすい環境を整えていければと思います。

課題② プロダクト間で UI/UX の統一感を生み出しづらい

各プロダクト間でコンポーネントを検討しデザインに反映することがなくなったため、導入前よりも統一感を出すことができるようになりました。 しかし、実装レベルでの統一がまだ十分ではありません。これを解決するために、UI ライブラリとしてパッケージ化し、RESZAIKO の各サービスに反映していければ、さらに課題の解決につながると考えています。

課題③ デザインのクオリティの担保が難しい

ルールが定まったことで、誰が作成しても差異が出ないようにする基盤は整えられましたが、チェック時の効率はまだ改善の余地があります。 より効率的に確認できるようにするため、チェックリストの作成など、デザインシステムの拡張も進めていきたいと考えています。

運用を始めたばかりの現段階では、まだ全体的に改善の余地が多く残っています。 これからさらにデザインシステムをアップデートし、利便性を高めていきたいと考えています。

おわりに

全く知見がない中で始めたデザインシステムの作成でしたが、ありがたいことにデザインシステムをオープンに運用している企業が多く、参考にできるものが豊富にありました。そのおかげで自分たちなりにアレンジしてなんとか形にし、プロトタイプまで持っていくことができました。 知見がない中で、またエンジニア主導でデザインシステムを導入しようとしている方々にとって、この経験が一つの手がかりになれば嬉しいです。

RESZAIKO デザインシステムはこれからもっとアップデートさせていくので、今後もブログで発信していきます！

一休ではともに良いサービスをつくっていける仲間を募集していますので、興味を持っていただけたら、ぜひ一休の採用サイトをご覧ください。

Go Conference 2024にスポンサーしました & 一休はGoを活用しています

Go Conference 2024にスポンサーしました

CTO室プラットフォーム開発チームの山口(@igayamaguchi)です。

先日6/8(土)に一休でGo Conference 2024にスポンサーをさせていただき、スポンサーブースを出展しました。 gocon.jp

来ていただいた方はありがとうございます！

来ていただいた方と話していく中で、一休がGoを使っていることを知らない方がたくさんいることに気づきました。逆に、最近使い始めたばかりのRustの事例についてご存知の方のほうが多かったのです。これは、次のRustについての記事が多くの方に読まれたことによる影響だと思います。

user-first.ikyu.co.jp

実際には一休はGoを使っているサービスがたくさんあります。その点をアピールするため、この記事では一休のどのサービスでGoが活用されているかを紹介します。

一休がどのサービスでGoを使っているか

まず、一休ではいくつものサービスを提供しています。

会社紹介資料より抜粋

この中でGoが使われているサービスは以下の赤枠で囲われたサービスです。

ご覧の通り、Goが使われているサービスは多いです。
また、ユーザー向けのサービスとは別の社内プラットフォームでもGoが使われており、実際は上の図で表されている箇所以上にGoが活用されています。

ここからは、各サービスでのGo利用事例を個別に紹介していきます。

国内宿泊予約サービスでの活用

まず、一休の中で最も大きなサービスである国内宿泊予約においてGoは活用されています。
一休では国内宿泊予約サービスとして一休.comとYahoo!トラベル(LINEヤフー株式会社から運営を委託)を運営しています。

https://www.ikyu.com https://travel.yahoo.co.jp

宿泊施設を探すための検索を実行するバックエンドがGoで書かれています。バックエンドはgqlgenを用いたGraphQLサーバーになっており、ホテルやプランの検索、料金、在庫検索といったロジックが実装されています。他にも、全文検索エンジンであるSolrのインデクシングや、施設管理画面の一部APIなどもGoで書かれています。

ホテルの予約を行う処理、予約情報の閲覧ページはVB.NETですが、こちらも後々Goに置き換えていく予定です。

ふるさと納税、海外宿泊予約

国内宿泊予約サービス以外にもいくつかのサービスでGoは活用されています。
例えば宿泊予約時に割引クーポンを受け取れるふるさと納税サービスや、海外宿泊予約です。

https://furusato.ikyu.com/ https://www.ikyu.com/global/

これらのサービスは、社内では新しめということもあり、バックエンドは検索から予約まですべてGoで実装されています。

一休プラットフォーム

ユーザー向けサービス以外に、社内向けプラットフォームでもGoは使われています。一休ではいくつものサービスを運営しており、サービス間で共通のアカウントを利用し、貯めたポイントをサービス横断で使用したり、同じ決済の仕組みを使ったりできます。

そういった機能を各サービスで再実装することなく提供するために、一休プラットフォームとして複数のマイクロサービスを実装し、運用しています。具体的なサービスとして、現在は会員サービス、ポイントサービス、決済サービスがあり、これらはすべてGoで実装しています。

現在移行中の一休プラットフォームの図

一休プラットフォーム開発の実例については、2023年のイベントでの資料も参照してください。

speakerdeck.com

Goを選定してよかったこと

実際に国内宿泊予約や一休プラットフォームの開発に携わっているメンバーから、Goを選んでみてよかったことを聞いてみました。

  • 並行処理が言語組み込みで入っている。しかもそれが使いやすい
  • 言語仕様がシンプルで、入門から使えるようになるまでの時間が短い
  • 業務ロジックが大事なので、シンプルかつ堅く書けるのがよい
  • 一括処理や会計管理で大きめのデータを扱うときは非同期処理も書ける

総じて、Goは「シンプル、かつすばやく、それでいて堅牢に作れる」ことを重視する一休の技術選定方針に合致すると感じています。

おわりに

この記事では、一休がGo Conference 2024にスポンサーさせていただいたこと、一休では幅広くGoが使われていることを紹介しました。一休では、これからも生産的かつ高効率にサービスを開発／運用できるGoを活用して、サービスを成長させていきます！

一休では、ともに良いサービスをつくっていく仲間を募集中です。

hrmos.co

カジュアル面談も実施しているので、お気軽にご応募ください。

www.ikyu.co.jp

エンジニア向け社内イベントのご紹介と運営を経験してわかったこと

こんにちは。宿泊プラットフォーム開発チームの菊地です。

一休では月に一度、社内エンジニア向けにIkyu Tech Talkを開催しています。2022年から始まり、ありがたいことに2024年3月で丸2年を迎えることができました。
この記事では、Ikyu Tech Talkの2年間のふりかえりをしていきます。

また、私は社内イベントの主催が初挑戦だったので、どうやったらイベントを盛り上げられるのかと悩んだときもありました。
そこで、同じように自分の会社でTech Talkを開催してみたい人に向けてイベント運営の知見もお伝えしたいと思います。

開催のきっかけ

もともと定期的なプロジェクトの成果報告会はあるものの、業務で得たエンジニアリングの知見の共有をする場は設けられていませんでした。
あるとき「技術についてざっくばらんに話す場が定期的にあると楽しそう。一緒にやらない？」と声をかけてもらい、面白そうだったのでやってみることにしました。

Ikyu Tech Talkとは?

「技術のことならなんでもOK」と題して社内エンジニアに発表者をやってもらう60分の社内イベントです。 月に1回ペースでZoom開催しています。
カテゴリ別に過去の発表を抜粋してご紹介します。

自己学習の発表

個々人の技術研鑽の発表回です。業務では知ることができない興味関心分野を知ることができました。

  • GitHub Copilotで 次世代のコーディング体験
    • 正式リリース直後の2022年6月にGitHub Copilotについて発表してもらいました。これをきっかけにCopilotの業務利用を行うことになりました！
  • TypeScript による型レベルプログラミングに入門した話
    • 型定義の表現力の高さを活用して、tscにアルゴリズムを実行させるデモが鮮烈でした

プロジェクトのふりかえり

案件が終わったタイミングで、チームの皆さんに振り返りもかねて発表をしてもらいました。新しいフレームワーク・ツールを積極的に採用するスタンスなこともあり、初挑戦の技術のフィードバックが多かった印象です。チャット欄もおおいに盛り上がりました！

  • 宿特化型SNS YADOLINKでのアーキテクチャ選定
    • 一休で初めてReactを用いた事例でした。当時よくGraphQLクライアントとして選定されていたApollo Clientに対しての適不適の考察も興味深い内容でした。Apollo Clientについては以下の記事もご覧ください
  • 宿泊予約サイトの検索処理チューニング
    • 国内宿泊サイトの検索処理には複数のシステムが関わっています。それらを複合的にパフォーマンスチューニングしてレイテンシを半減させた実践的なテクニック紹介でした
  • レストラン予約サイトフロントエンドの今とこれから

専門性の高い部署の知見を広める

一休には、データサイエンス部・アーキテクトチーム・SEO対策チームといった専門性の高い部署があります。なかには「もっと早く知りたかった」「入社時の資料にしてほしい」という声をいただく発表もありました。

  • 猫でもわかる一休のデータ分析基盤(参加型)
    • 一休のデータサイエンス部は、各プロダクトのデータをもとに分析基盤を提供しています。分析基盤の全体像をキャッチアップできただけではなく、データ基盤を安定させるための実践的なテクニックが非常に面白い発表でした
  • 一休のサービスを支える インフラのはなし
    • プロダクトのネットワーク構成やデプロイフローについて、SREチームが解説しました。特に入社したての人にとっては垂涎の資料でした

Tech Talkの成果

Ikyu Tech Talkは完全任意参加のイベントとして運営してきましたが、開発組織メンバーの半数以上が参加し続けてくれています！
ここまで続けられてきたのは「エンジニアリングの話をするのが楽しいから」というのに尽きると思います。その一方、会社としてTech Talkを開催することで以下のような成果が得られました。

チームを超えてナレッジを共有できる

これまでは、成果報告会などのビジネス的な成果を知る場はあったものの、互いのナレッジを知る機会はなかなかありませんでした。Tech Talkはエンジニアリングの話を聞く場として貴重な機会になりました。

実際にSlackを探してみたところ、Tech Talkの発表を受けて他のチームのソリューションを取り込んでいるやりとりもありました！

発表時のZoomのチャット欄では、「ウチでは○○を使ってます」というように参加者からの知見も多く寄せられ、双方向での知見交流が生まれたのも成果だと思います。

発表の機会があることで、個々人の知識がよりブラッシュアップされる

プロジェクトに没頭している間は、知識が表面的なままになっていることがあります。Tech Talkを目標に、知識の精査や最新情報の確認をすることで、それらを自分の知見として昇華するきっかけにできます。

たとえば、あるプロダクトの新規リリースを行ったチームに発表をお願いしたところ、初期開発時の技術選定の是非を振り返った発表をしてくれました。
選定したソリューションの選定基準だけではなく、不採用にした他の案の理由や今振り返るとその選択は妥当だったのかの洞察も述べていて、今後の技術選定にとって価値のある資料になったと思います。

カジュアルに自己発信の経験を積む場を提供できる

自己発信の機会は貴重ですが、いざ外部の勉強会で発表しようとすると初心者には足が重いこともあります。 Tech Talkでは顔見知りが参加者なので、カジュアルに発表の経験を積むことができます。 採用活動をしている会社にとって社外で発表してくれるエンジニアは貴重ですが、Tech Talkを練習場として提供することができます。

社内イベントの運営をしてわかったこと

この記事を読んでいる方のなかには、以下のような悩みを持った人もいるかと思います。

  • 自分の会社でも社内イベントを開催してみたいけど、どうやったら盛り上がるだろうか、どう始めたらいいだろうか?
  • 社内イベントを開催してるけど人がなかなか集まらない、集まっても盛り上がらない
  • 登壇をお願いしても断られる、つらい

ここからは、社内イベントを開催したい方に向けて、Ikyu Tech Talkで得た運営のノウハウをお伝えします。

イベントがコンスタントに続けられる仕組みにする

Tech Talkの運営方針として、エネルギーが必要すぎて続けられなくなるよりもかけるエネルギー少なく長く運営できるイベントにすることを決めていました。
Zoom開催としたのも、イベント設営と集客に疲弊したくなかったからです。開催頻度も月1回くらいで「たまにやればいい」という気持ちで始めました。

発表を依頼したりイベント告知等の作業など、イベントの運営はただでさえ負担が大きいです。そのため、開催コストをできるだけ下げるのは非常に有用だったと感じました。
また一休ではリモートワークが導入されておりオフラインイベントにすると参加側の敷居も高くなってしまうため、双方にとってオンライン開催が最適でした。

発表者に対するリターンを設定する

発表準備や当日の精神的な負担が大きいので、モチベーションを高めるためにリターンを設けました。 具体的には「Tech Talk賞の開催」と「発表ごとに感想・メッセージの受付」を行っています。
　 Tech Talk賞とは、半期に一度、最も面白い発表をしてくれた人を投票で決め表彰するイベントです。一休各サービスで使用できるポイントを贈っています。

また、毎度の発表後には、参加者に発表の感想・メッセージを書いてもらってそれをまとめてお渡ししています。発表中はどうしても参加者のリアクションがわからなかったり、面白い発表だったかなど不安を感じる人も多いです。実際に発表者の方からも、発表のフィードバックがもらえてよかった、という声をいただきました。

一方で、メッセージの回収率が20%程度にとどまっているのが今後の課題です。対策としてイベント中にメッセージの記入時間を設けたらどうかと検討中です。

Zoomのコメント機能を活用して積極的な参加を促す

多くの参加者にリアクションしてもらいイベントを盛り上げるため、Zoomのコメント機能を活用しました。
質問や感想をその場で話すには緊張してしまう人もいるため、テキストベースでコメント欄に書き込んでもらう形式にしました。書かれた質問は、発表の区切りの良いタイミングで司会が拾いその場で発表者に回答してもらいました。

また、司会以外の運営はちょっとした感想も意識的に書き込むようにし、コメント欄を盛り上げることを心がけました。今ではコメント欄がフランクな感想を言える場所として定着したため、とてもよい試みだったと思います。

まとめ

以上が社内イベント運営のノウハウです。 社内イベントでは、運営・発表者・参加者それぞれが継続できる仕組みを作ることが最も重要だと感じました！

さいごに

ここまで読んでくださりありがとうございます！
今回は社内イベント Ikyu Tech Talkの紹介と、社内イベントの運営をしてみて得た学びをまとめました。本記事が自社のエンジニア組織を盛り上げたい方の力になれたら幸いです。

また、いつもIkyu Tech Talkに参加＆登壇してくださっている一休のエンジニアの皆さんへ。
この場を借りて感謝の気持ちを伝えさせてください。皆さんがポジティブに参加してくれるおかげで、Ikyu Tech Talkが楽しいイベントとして継続できています。いつも参加いただき本当にありがとうございます。

さいごになりますが、一休では社内イベントに積極的に参加してくれる、アウトプットが得意なエンジニアを募集しています。
興味がわいた方は、以下のリンクから面接応募及びカジュアル面談へのご参加をぜひぜひお願いいたします！！！

https://www.ikyu.co.jp/recruit/engineer/

https://hrmos.co/pages/ikyu/jobs/1745000651779629061

一休の社内勉強会のご紹介2024

kymmtです。

一休では、技術力の底上げを目的として、さまざまな社内勉強会を開催しています。この記事では、今年2024年に入って社内で実施していた勉強会について紹介し、一休での勉強会の雰囲気を伝えられればと思います。

一休の社内勉強会

社内勉強会は輪読会の形式で実施することが多いです。参加意欲の高い人ができるだけ多く参加できる曜日と時間を決めて、週次で開催する形式をとっています。

読む本の決め方については、ボトムアップで決めることが多いです。先日は、次に読みたい本をSlack上でPollyを使った投票形式で募り、『なっとく！関数型プログラミング』を読むことになったりしました。

進め方については前日までの準備と当日で分かれています。

  • 前日まで: 章ごとに担当を決める場合は担当者が、決めない場合は参加者全員がその回で読む範囲に基づいて概要や疑問点、コメントをConfluenceのページとしてまとめる
  • 当日: 担当者／ファシリテータが会を進行しつつ、資料に基づいて参加者が議論しつつ書籍を読み進める

Confluenceに「勉強会」というスペースがあり、そこに勉強会の資料が集積されています。

また、のちほど説明するとおり、輪読会以外にハンズオン形式でのイベントを開催することもあります。

2024年にこれまで実施した勉強会

『A Philosophy of Software Design』輪読会

ソフトウェアの複雑性に着目し、複雑性をいかに制御するかという観点でソフトウェア設計や実装の方法論が議論されている書籍です。

A Philosophy of Software Design, 2nd Edition: Ousterhout, John: 9781732102217: Amazon.com: Books

この本はこれまでの通説とは異なる著者独自の観点からの主張が含まれる、という特徴があります。この主張を適切に咀嚼しつつ（いい意味で）批判的に読み進める態度が求められ、おもしろい輪読会になったと思います。

また、基本的には原著しか選択肢がない本なので、洋書を読む練習にもなりました。英語自体は平易で、書評記事などがWeb上に多く存在することから、調べながらなら難しい本ではありません。とはいえ、平易な文であっても意味を取り違えてしまうケースもあるので、そのあたりも注意して読んでいくのは多くの参加者にとって勉強になりました。

『Webフロントエンド ハイパフォーマンス チューニング』輪読会

タイトルから受ける印象とは異なり、実際はブラウザの仕組みについて詳しく書かれている書籍を読む会です。

gihyo.jp

フロントエンドをこれから学習していきたいメンバーに、まずブラウザの仕組みを知ってもらうのがいいのではということで開催されました。

この勉強会については、別の記事で詳しく紹介する予定です。

フロントエンドワークショップ: Reactハンズオン

社内エンジニアのフロントエンドに関する技術力を底上げするための「フロントエンド技術力向上委員会」メンバーが主催しているのがフロントエンドワークショップです。第1回のワークショップでは、フロントエンドの経験が薄い人や、これまでReactを触ったことがない人向けに、Reactで簡単なToDoアプリを作るハンズオンを実施しました。

ハンズオンでは https://github.com/tak-onda/frontend-workshop-react/ のリポジトリを利用しました。

輪読会は基本的にオンラインで実施していますが、このハンズオンは社内のラウンジと呼ばれるスペースを使って、みんなでワイワイ取り組むためにオフライン開催しました。

ふだんサーバサイドやプラットフォーム中心に開発しているエンジニアが最近のフロントエンドについてキャッチアップできるイベントになりました。

2024年の今後の勉強会

2024年5月からは投票多数で選ばれた『なっとく！関数型プログラミング』の輪読会を開催しています。

www.shoeisha.co.jp

近年は、関数型プログラミングのエッセンスを含んだ言語やライブラリが広く使われるようになっています。既存のコードベースが関数型ではないとしても、堅牢なソフトウェアを作るためには、関数型の考えに親しむことで得られるものも多いだろうと考えています。

『なっとく！関数型プログラミング』を読み終えたら、次は『Domain Modeling Made Functional』を読むのがいいのではないかという話もすでに出ています。

pragprog.com

また、フロントエンドワークショップの第2弾として、Reactで作ったToDoアプリにJotaiで状態管理を、Vitestでテストを組み込むワークショップも開催予定です。

一休では今後も継続的に勉強会を開催していく予定です！

一休では、ともに良いサービスをつくっていく仲間を募集中です。

hrmos.co

カジュアル面談も実施しているので、お気軽にご応募ください。

www.ikyu.co.jp

なぜ我々は GitHub Copilot Enterprise の導入を見送ったのか

CTO 室の恩田です。

今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。

きっかけ

とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。

それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる？」の一言で、有志が集って評価プロジェクトが始まりました。

雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした（笑）。

この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜日の朝にアップグレードが完了しました。 GitHub Team から GitHub Enterprise Cloud に、Copilot Business から Copilot Enterprise への変更です。

そうして評価プロジェクトが動きはじめました。

評価にあたって

Copilot Enterprise が有効になったことを確認したあと、集った有志がどう評価を進めようか話しはじめたところで、CTO からレビューしてちゃんと意思決定しようね、との補足をもらいました。

その要旨は次の二点です。

  • 会社で支払うライセンス管理は、ほとんど使ってないのにとりあえずもらっておくなど、なあなあになりがち
  • 評価は定性的でよい、インパクトのあるユースケースがどれだけ見つかるかが重要

個人的には、コストに見合う価値をどう定量化するかという観点でばかり考えていたので、後者の指摘には新鮮な視点をもらえたように思います。 定量化を前提にすると評価プロセスが重たく固定的になってしまい、様々な視点からの素早い意思決定には繋がらなかったことでしょう。

結果、プロジェクトに集まったメンバーが各自の興味のある観点で分担して、どういうユースケースが実現できると開発体験にインパクトを与えられるか、で評価することになりました。

いくつか抜粋すると、

  • ドキュメントを集約する場として knowledge bases は Confluence からの移行に値するか？
  • レガシーコードの理解にあたり認知負荷をどれぐらい軽減してくれるか？
  • PR サマリーの自動生成で開発プロセスがどの程度改善されるか？

といった観点になります。

評価

冒頭でお伝えしている通り、2024年4月現在、一休のコードベースやドキュメントを学習させた限りにおいては、GitHub Copilot Enterprise は時期尚早という結論になりました。

ここでは評価していく中で、具体的にどんなことがわかったのかをご紹介したいと思います。

knowledge bases は使えるか？

もともとプラットフォームエンジニアリングの文脈で、開発者の認知負荷を軽減させるために、ドキュメントをどうしていくかという議論が少し前からありました。

knowledge bases は2024年4月現在 GitHub リポジトリ内の markdown ファイルのみを学習します。 Copilot Enterprise を導入することになると、ドキュメントを今後は GitHub リポジトリで管理していく必要があります。

一休では現在、多くのチームが Confluence を使ってドキュメントを管理しています。

非エンジニアにとっても扱いやすく、階層的に情報を整理することができ、世界的に広く利用されているナレッジマネジメントサービスです。 特にドキュメントを同時編集したり、リアルタイムでインラインコメントを入れる機能は、一休でもミーティングの場で活用されています。

そういった現在享受している Confluence の良い点を失ってでも、なお余りある価値を Copilot Enterprise がもたらしてくれるのかが焦点でした。

上述の通り、knowledge bases にインデックスさせるデータは markdown ファイルで構成された GitHub リポジトリとして用意する必要があります。そこで、スペースを一括して markdown に出力する Confluence プラグインを導入し、それを使って knowledge bases 用のリポジトリをいくつか作成しました。

その上で、様々な質問で評価してみましたが、概念の学習がまだまだ限定的であるように感じられました。

ひとつ具体例を紹介したいと思います。

一休レストランは現在３バージョン存在します。

オリジナルの一休レストランは restaurant というリポジトリで作られました。 リニューアル時に restaurant2 が作られ、それ以後、オリジナルは restaurant1 や略して res1 と呼ばれるようになりました。

今回 knowledge bases に取り込んだドキュメントにも restaurant1 や res1 という記述が多数あります。 にも関わらず、res1 などのキーワードを含めた検索では、オリジナルのリポジトリである restaurant に関する回答が返されることはほぼありませんでした。 数字の有無が影響しているのか、restaurant2 に関する情報ばかりが要約されて返ってくることが多かったです。

他にも LLM でよく言われているように、knowledge bases においても、日本語で学習させたにも関わらず、英語で質問した方がより優れた回答になる傾向が見られました。

レガシーコードの理解にあたり認知負荷をどれぐらい軽減してくれるか？

一休は20年以上の歴史を持つサービスです。

継続的にモダナイゼーションを進めてはいるものの、まだまだレガシーコードが残っています。

そのようなレガシーコードを読んで理解することは、現状の振舞いや仕組み、そこに至った経緯を把握するために、避けて通れない作業です。

レガシーコード上でわからないことを GitHub Copilot Chat が適切に要約して回答してくれると、あちこち行ったり来たりすることなく、着目すべきコードに集中して読むことが可能になります。 ひいては開発生産性の向上にも寄与してくれるのではないか、と期待していました。

  • 新しく入社した開発者がレガシーなリポジトリを見るとき、どこを読めばいいかを示してくれるか
  • 営業スタッフやカスタマーサービスから問い合わせがあったとき、現状や経緯についてのピンポイントな質問に答えられるか
  • リポジトリの全体感がどうだ、とかそういう質問に答えられるか
  • もっと踏み込んで、検索にとどまらず改善策など示唆にあたる情報を提示してくれるか

具体的には上記のようなユースケースです。

このようなシナリオを評価するために、評価者が十分に理解しているような内容について、適切なまとめを返せるか、というテストを行いました。

このあたりは業務に深く関わってくる内容なので、具体例を紹介することは難しいのですが、たとえば、

複数のリポジトリを横断して内容をまとめる必要があるのですが、リポジトリ間でコードやコメントの質に差が大きく、より質の高いリポジトリに回答の内容が引っ張られてしまっている（ように見えた）

無関係の情報が回答に含まれないように、プロンプトの書き方や、knowledge bases にインデックスさせる情報を工夫する必要がある

XXX の API を呼びだしているところを探して、という質問で、関係のないプレゼンテーション層のコードを返してきたり、リポジトリのコードをあまり学習しているように感じられなかった

といった意見があり、期待した結果を得るにはハードルが高いなという印象でした。

もちろん、命名やコメントを含めてレガシーコード自体の品質に問題があることは否定できません。 ですが、そのようなコードベースであっても適切に情報を抽出できなければ、レガシーコードを扱う上での助けにはならないのが実情なのです。

PR メッセージ自動生成

Pull Requests のメッセージを自動で生成する機能は現状英語しかサポートされていません。

ソフトウェアエンジニアとして英語ドキュメントに触れる機会は多いといっても、社内コミュニケーションはもちろんのこと日本語です。 人に読んでもらうための PR メッセージが母語でなければ、当然、その効率は著しく下がってしまいます。 ノンバーバルな情報が得られない文章によるコミュニケーションにおいて、重要となる細かなニュアンスを伝えることも難しくなります。

また、英語であることを差し引いたとしても、生成される内容が現状ではそこまで有用とは言えませんでした。

たとえば、どのようなファイルにどのような変更をおこなったかという what の情報はうまく要約してくれます。 しかし、その PR の変更が必要となった背景や変更の意図といった why の情報は期待したほどには盛り込まれません。

レビューにあたって what は差分を見ればわかります。 ですが、その変更が適切かどうかを判断するために欲しい情報は why なのです。

もちろん why をコードのみから読み取るのは人間でも難しいので、コメントの形で補足する必要があります。 しかし、コメントを書いたとしても、コードの変更箇所に関する限定的な内容となってしまいがちで、そもそもの背景や目的を網羅するのは現実的に難しいところがあります。 結果、PR の説明として期待するほどの内容にはなりませんでした。

将来的には Issue や git の履歴を利用して、背景情報を補ってくれるようになることを期待しています。

総じて PR メッセージ自動生成は機能自体が発展途上であり、現時点で導入したとしてもそこまで大きな恩恵を受けられるわけではなさそうだという結論に至っています。

学習の対象が限定的

他にも評価の過程で以下のような声が挙がりました。

DB 定義書を開くのが手間なので聞けたら便利だと思ったが、Excel ファイルを読み取ることはできなかった。

回避策として Excel の DB 定義ファイルから markdown に変換して knowledge bases リポジトリに登録してみました。

自動生成された markdown という制限付きではあるものの、テーブル間の関係を学習できていないように思えます。 たとえば、ある機能に関連するテーブル定義の全体像を説明して、といった質問には適切な回答が得られませんでした。

ADRのリポジトリがあるので、これをインデックスして仕様を聞けたら便利だとおもったが、issueは対象外だったのでうまくいかず。。。

GitHub に蓄えられた情報は git リポジトリ以外にも Issues や Pull Requests, Wiki が存在します。

LLM にとって、もっとも学習しやすい対象であるテキスト情報の上、過去の経緯を追う上でも重要な情報が含まれています。

にも関わらず、Copilot の学習対象外であるため、これまで蓄積してきた情報にもとづく知見を抽出することはできませんでした。

近い将来の導入に向けて

上述した通り、残念ながら、現時点ではすぐに効果が得られるようなユースケースは見つかりませんでした。

ですが、日進月歩を文字通り体現している LLM の発展を見る限り GitHub Copilot Enterprise を導入する未来は近いとは考えています。

したがって、いざ導入するとなったとき、すぐに有効活用できるよう準備は進めておくのがよさそうです。

今回は採用を見送ったものの、評価内容を踏まえてコードとドキュメントの二つの観点で、どういった準備をしておくべきかの認識を共有して評価プロジェクトを終了しました。 といっても頑張って準備する類の活動ではなく、頭の片隅においておこう、という程度の対策です。

最後にその対策をご紹介して本記事を終えようと思います。

コードに意図が伝わるコメントを残す

自動生成された Pull Requests のメッセージは修正した内容の要約という what であって、その修正がどういう意図でなされたか、レビューにあたって特に重要な why は含まれていません。

もちろん、それはコードに意図や理由にあたる情報がないためであって、Copilot が why を説明するメッセージを生成できないのも当然です。

GitHub の Blog でも、Copilot を使う上でのベストプラクティスとして LLM に context を提供することの重要性を説いている記事が公開されています。

ということで、ごく当たり前の結論ではありますが、コード自体に why や why not がわかるコメントをしっかり残すように意識していこう、となりました。

奇しくも同時期に行っていた A Philosophy of Software Design の輪読会でコメントの重要性についての議論をしていたのも功を奏しました。 コードに意図が伝わるコメントを記述する、というプラクティスが各チームに浸透してきており、今後 LLM に与えられる context が増えていくと見込んでいます。

また、副次的な効果として、フロー情報になってしまいがちな PR と異なり、ストック情報と言えるコード上のコメントは認知負荷を軽減してくれています。 普段から触れるコードだけで意図が伝わる状態と比べたとき、なにかしら問題が起きてから git の履歴や関連する PR を追う作業は、不要な課題外在性負荷でしかありません。

なお、前段で PR メッセージ生成の評価の中でコメントを追加しても why を含んだ内容は生成されなかった、という評価結果をご紹介しました。 これは、あくまで現時点で未成熟なだけであって、将来に向けての布石としては、コメントを充実させていくことには意味があると捉えています。

今後はコメントに加えて、どうすれば LLM フレンドリーなコードになるか、という観点での新しいコードの書き方も確立していくでしょう。引き続き動向を追いながら、新しい種類のコードの品質向上に努めていきたいと思います。

ただ、このような新しいプラクティスが浸透するのには時間がかかります。 Copilot の今後の進化で、ブランチと紐付けた Issue や PR に代表される、コードに関わる既存の context をうまく利用してくれるのでは、と個人的には期待しています。

ドキュメントの準備はあえて何もしない

近い将来の導入に向けて、今からドキュメントを GitHub に移行していくことも検討しました。 しかし、現時点では、あえて何もしないことを選択しました。

GitHub Copilot Enterprise がナレッジマネジメントの分野においても、LLM 時代のスタンダードになるかどうかはまだ判断しきれなかったからです。

もちろん、コードそのものに加えて Issue や PR の情報を持っているという強みがあるので、非常に有力な候補であることには疑う余地はないでしょう。

ですが、今はどの会社も LLM を自社製品にどう組み込むか最優先で試行錯誤しているのは間違いなく、どの製品が最終的に勝者となるかは未知数です。 Google が後発の検索エンジンであったことを忘れてはなりません。

一休では、前述したように多くのチームでドキュメンテーションに Confluence を利用しています。 Atlassian でも Atlassian Intelligence という AI 拡張機能が提供されはじめています。 Confluence には AI を利用した要約や検索、社内用語やプロジェクト用語の自動定義などの魅力的な機能が近日中に提供されるようです。

GitHub もまた、knowledge bases を単にリポジトリ中の文書を学習するだけに留めず、Copilot の中核となる機能として発展させる施策を進めているのではないかと予想しています。 たとえば Issues や Discussions, Pull Requests など GitHub に蓄えられた他の情報との統合は容易に想像できるところです。

加えて、忘れてはいけない観点として、ナレッジマネジメントサービスにとって、既存機能の重要性には変化がないことには触れておきたいと思います。 LLM による新しい検索体験は非常に強力で魅力的なフィーチャーであることは確かです。 しかし、情報の構造化やチームでの同時編集のしやすさ、他サービスとの連携といった、もともとの価値を見失うことがないよう留意していくつもりです。

将来、他のナレッジマネジメントサービスを採用することになったとしても、knowledge bases リポジトリの準備でご紹介したようにデータ移行はさほど難しくはありません。加えて、この分野で高いシェアを持つ Confluence からの移行機能が提供されることも期待できます。

引き続き動向を注視しながら、あらためて判断することになりそうです。

おわりに

一休では、よりよい価値を素早くユーザーに提供できるよう、開発生産性の向上にもチャレンジしていただける仲間を募集しています。

興味を持っていただけたら、ぜひ一休の採用サイトをご覧ください。

データベースの在庫の持ち方をビットで管理してる話

こんにちは、一休.comスパ(以下、「スパ」)の開発を担当しているshibataiと申します🙏 今回はスパのデータベースの在庫の持ち方で試行錯誤した話をさせていただきます。

背景

2024-03-29追記: 一休.comスパにおける在庫の特徴について

一休.comスパが扱う「在庫」は、「ある日付の特定の時間に対する空き枠」です。以降の説明では、スパ施設ごと、日付ごと、また時間ごとに増えていく「在庫」をいかに効率よく扱うかについて説明しています。

詳細については次のスレッドも参照してください！

現在の実装

スパは予約を受け付けるために在庫の管理をしてます🎁 データベースで在庫テーブルを持っていますが、ベタな管理をしています。 特定の施設・日・在庫の数を00:00をt0000とみなして15分おきにt0000・t0015..t2345まで格納してます🤔 在庫テーブルのイメージは以下です。

shop_id inventory_id inventory_date t0000 t0015 (省略) t1300 t1315 (省略) t2345
1 1 2024-01-01 0 0 ... 1 0 ... 0
1 2 2024-01-01 0 0 ... 0 1 ... 0

この設計は在庫の調査時に在庫数を確認しやすいのですが、レコード挿入時にtxxxの形にしたり、描画時にtxxxをtimeに変換する必要があったりと、実際に在庫を含めた描画を行う処理に難ありでした😞 チーム内で相談した結果、検索で描画する際は時間の配列(例: ['10:00', '11:15', '12:45'])を圧縮したビットを使うようにしました。

shop_id inventory_id inventory_date timeBits1 timeBits2
1 1 2024-01-01 1 0
1 2 2024-01-01 64 2

具体的な実装は後述しますが、カラムをビットで管理する場合のメリット・デメリットは以下です。

【メリット】

  • あるスパンごとのカラムを大量に持たずにビットの表現で圧縮できるのでデータ容量を抑えることができる
  • 動的にカラムを決めるために一般的にオーバーヘッドの大きいと言われるリフレクションを使わなくていいため、ビット値を用いると比較的高速に検索可能
  • 施設単位やプラン単位などで在庫有無をサマライズしたい時、ANDやOR検索で柔軟な条件指定が可能

【デメリット】

  • テーブルをSELECTで検索するだけでは状態がわからない(値を変換しなければならない)ため、デバッグやクエリ構築の難易度が上がる
  • ビット値と時間の配列の間を相互変換するライブラリの用意が必要
  • ビット値はBIGINT型でも桁溢れする場合があるので、Bit1とBit2といったようにある部分で分割する検討が必要

以下からはビット演算の仕組みと、実際にどういうイメージで検索するかを説明します👀

ビット演算とは？

データをビット列(0 or 1で構成される)とみなして演算します。 メリットは、値に対してANDやOR検索ができることです。 例えば1/2/3をビット列で表した場合、00000001/00000010/00000011です。 1と2でビットOR演算を行うと、

   00000001
OR 00000010
-------------
   00000011

各ビットを縦に見て、少なくとも一方に1がある場合、結果のそのビット位置は1になるので、演算結果は10進数の3です。 実際にSQLServerで検索する際にAND演算を使う例を出すと、

CREATE TABLE Example (
  Bits INT
);

INSERT INTO Example(Bits) VALUES (3);
SELECT * FROM Example　WHERE Bits & 1 = 1; // Bits列の値と1のビットANDが1に等しい行を選択するのでヒットする
SELECT * FROM Example　WHERE Bits & 2 = 2; // Bits列の値と2のビットANDが2に等しい行を選択するのでヒットする
SELECT * FROM Example　WHERE Bits & 4 = 4; // 3（00000011）と4（00000100）はそれぞれに1が立っている位置が違うのでヒットしない

Pythonの代表的なORMであるSQLAlchemyを使う場合は以下のように書けます。

query.filter(Example.Bits.op("&")(bits1) == bits1)

実装例

ビット演算で在庫管理するには、たとえば次のように実装します。

  1. INSERT INTO Example(Bits) VALUES (n);の nに相当する値を在庫がある時間帯からビットへ変換して格納
  2. 検索時に時間をquery.filter(Example.Bits.op("&")(bits1) == bits1)として検索し、取得できたBitsカラムを時間帯に変換

なので、デメリットでもお伝えしましたとおり、ビット値と時間の配列の間を相互変換するライブラリの用意が必要です。 今回は先人達が実装してくれていたライブラリが社内にあったため、ありがたく使わせていただきました。

変換の考え方

例えば00:00-23:45で15分スパンとしたとき、1日は96区切りです。 10:00 ~ 19:00に在庫が存在するを表現すると以下のようになり、96bitsで時間が有効であれば1が立つと考えることができます👼 要件によっては00:00で終わりではなく、24時以降の表現をしたい場合もあるので、1日の区切り数やスパンをどうするかはプロジェクトの定義によって決めて下さい。

    |0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16  17  18  19  20  21  22  23  |
    ||   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
    <000000000000000000000000000000000000000011111111111111111111111111111111111100000000000000000000>

1に関して、96bits(12bytes)のままではバイトオーダーの都合上扱いづらいので16bytesに変換すると、b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xf0\x00\x00'で、先頭~8bytesまでと9~16bytesまでの値を取得できます。これをbits1とbits2カラムとして格納します。 変換の一部をPythonでの実装してみると以下です。 実際の社内では複数のユースケースに対応できるように、より複雑なことをしてますが、社内のソースコードをそのまま載せられないのでサンプルコードのみです🙏

bits = '000000000000000000000000000000000000000011111111111111111111111111111111111100000000000000000000'
bytes_array = int(bits, 2).to_bytes(16, byteorder='big')
bits_int1 = int.from_bytes(bytes_array[0:8], byteorder="big", signed=True)
bits_int2 = int.from_bytes(bytes_array[8:16], byteorder="big", signed=True)

print(bits_int1) # 0
print(bits_int2) # 72057594036879360

2.に関しても逆の処理を行えば良く、検索したい時間をビットに変換し、データベースから時間帯をAND演算で取得。取得できたbits1/bitsをbytesに変換しつなげて、96bitsを復元します。 あとは0と1の状態によって、00:00から15分おきに繰り返しで判定することで時間帯を復元できます🍿 変換の一部をPythonでの実装してみると以下です。

bits_pair = (0, 72057594036879360)
bytes_int1 = bits_pair[0].to_bytes(8, byteorder="big", signed=True)
bytes_int2 = bits_pair[1].to_bytes(8, byteorder="big", signed=True)
reconstructed_bits = format(int.from_bytes(bytes_int1 + bytes_int2,  byteorder="big"), '096b')
print(reconstructed_bits) # 000000000000000000000000000000000000000011111111111111111111111111111111111100000000000000000000が復元される

以上が相互変換するイメージでございます。

最後に

時間をビットで持つ実装の他にもチューニングしたため、単体での評価はできていませんが、今回の取り組みを通してスパの検索画面の描画は従来から1/3~1/5程度時間短縮することができました。 よって、ビットでの管理は今回スパの課題の解決手段としてはとても有効だったと考えます。 前述の通りデメリットもありますが、課題の解決手段の一つとして参考になれば幸いです！

一休では、ともに試行錯誤しながらよいサービスを作ってくれる仲間を募集しています！

hrmos.co

カジュアル面談も実施していますので、ぜひお気軽にご連絡ください！ www.ikyu.co.jp

開発プロセスをインクリメンタルに改善する

一休.comレストランのエンジニアのkymmtです。

2023年度の下半期、一休.comレストランの開発チームでは開発プロセス改善に取り組みました。改善は小さい単位で徐々に進め、バックログの作りかたやカンバンの運用方法を改善することで、フロー効率の向上、開発ペースの把握、チーム内外からの進捗の見える化ができるようになりました。

この記事では、このようなインクリメンタルな開発プロセス改善の取り組みについて紹介します。

従来の開発プロセス

主に2023年度前半の開発プロセスは次のような形でした1。

  • プロダクトのリリースに必要なタスクが長いバックログとして存在し、ひたすらタスクを消化
  • その状況に課題を感じ、区切りを入れるために2週間のスプリントを導入

この時点では、スプリントは2週間ごとに状況を確認するためのもので、目標に対するふりかえりや、次のスプリントの計画を作るためのものとしては活用していませんでした。

この開発プロセスに起因して、チームメンバーは次のような課題を感じていました。

  • どの機能に紐づくかが一見してわかりにくい技術的タスクや、やることが曖昧な項目がバックログにある
  • タスクは進んでいるが、ひとまとまりの機能ができるのに時間がかかる
  • 開発ペースを見通しにくく、今後の予定についてチーム内外に説明責任を果たしにくい
  • スプリントを導入したものの、スプリント終了時の残項目が完了しなかった理由など、開発のボトルネックを深掘りできていない

改善の方針

先述した課題を受けて、開発プロセスをできるだけ早く改善したいという機運が生まれました。しかし、スクラムなど大きめの方法論をチームに導入するのはこれまで例がなく、ある種の理想的な開発プロセスには近づけますが、効果が出るまでに時間がかかりそうでした。また、著者(kymmt)は入社直後だったので、技術的なキャッチアップと並行してプロセス改善をサポートしたいという状況でした。

そこで、アジャイル開発のプラクティスをインクリメンタルに導入してプロセスを改善することにしました。

ここで、それらのプラクティスの生まれた理由や避けるべき罠は理解したうえで、課題の解決に必要なものを選択的に導入するという点に気を配りました。最近出た本だと『アジャイルプラクティスガイドブック』は参考になりました。

2023年度後半からの開発プロセス

上記の方針に基づいて、2023年度下半期からは、チームで次のような改善活動に取り組みました。

  • 顧客価値に直結する開発はユーザーストーリーとして項目を整理し、その下で技術的タスクを分解／整理する
  • カンバン上でユーザーストーリーを左から右に流すようにして、顧客価値がどの程度生み出せているか、ボトルネックはどこかを見える化する
  • ユーザーストーリーに対する規模の見積もりとベロシティの計測を繰り返し、開発の見通しを立てられるようにする

これらの活動はある小規模なプロジェクトから始めて、次にもう1つの中規模なプロジェクトに横展開することで、徐々にチーム全体に活動範囲を広げました。

導入の様子

小規模の開発プロジェクトへの導入

すでに述べたとおり、2週間ごとに期間を区切るという枠組みだけ導入されていました。今回はそれを足がかりに、まずは小さい規模の開発プロジェクト（強いていうならエピック）に対してプラクティスを導入していきました。

まず、事前にユーザーストーリーとして開発項目を改めて明らかにしつつ整理し直しました。そして、それらに優先度をつけてバックログ上で並び替えました。あくまでも例ですが、次のようなイメージです。

名前 優先度
ユーザーが関連するレストランの一覧を閲覧できる 高
ユーザーが人気のレストランの一覧を閲覧できる 中
ユーザーが近隣のスポットに基づくレストランの一覧を閲覧できる 低

（ここでは一休.comレストランの利用者のことを「ユーザー」と呼んでいます）

そのうえで、項目の規模を相対見積もりしました。ストーリーに必要な技術的タスクについて認識を合わせながら、それぞれの項目の相対的な規模を比較します。現在に至るまで、フィボナッチ数列に基づくストーリーポイント(1, 2, 3, 5, 8)を使っています。ここでは、プロジェクトに携わる3人ほどで、規模の感覚を揃えて見積もりをしました。古典ですが『アジャイルな見積りと計画づくり』もあらためて参考にしました。

これらの項目を左から右に「To Do」、「In Progress」、「In Review」、「Done」のレーンを持つカンバンで管理します。これまでベロシティを計測したことがなかったので、見積もり実施後の初回スプリントでは、優先度に基づいてバックログの項目を「To Do」に並べ、優先度が高いものから取り組みました。また、できるだけ複数ストーリーを取らない（マルチタスクにならない）ように進めました2。

この時点でバックログの項目が整理された状態でカンバン上に現れ、関係者から見て進捗がわかりやすくなりました。また、スプリントを繰り返すなかで、カンバン上にあるストーリーを左から右に流すために複数人で手分けするような動きもできるようになりました。この点が効いて、目標期日をきつめにとっていましたがプロジェクトの作業を完了できました。

一方で、一部の開発プロジェクトだけに改善を適用していたので、チーム全体の開発ペースの計測ができていませんでした。これについては、次の中規模の開発プロジェクトであらためて進めました。

ツールの適切な運用

カンバン導入と前後して、コードベースとプロジェクト管理の距離が近いほうがチームの好みに合っていたので、従来Jiraを使っていたところをGitHub Projectsに移行し、これまで述べた運用に沿うようにカンバンや項目のメタデータを整備しました。また、チームで合意した運用方法はドキュメントとして明文化しました。

GitHub Projectsの効果的な利用方法については、以前このブログでitinaoが紹介しているのでぜひご覧ください。

user-first.ikyu.co.jp

できるだけ業務に支障がないように、Jiraにあったデータも移行しました。こういう移行はやり切るのが大事なので、GitHub APIを利用して必要なデータを極力自動でGitHub側にインポートしました。

一休.comレストラン開発チームのカンバン
一休.comレストラン開発チームのカンバン

項目間の依存関係を示しづらいなどの課題感もありますが、現在はおおむね現状を把握しやすいカンバンを運用できています。

中規模の開発プロジェクトへの導入

前述のとおり、ある程度プラクティスの導入による効果が出てきたので、著者(kymmt)が直接担当しているわけではない別の中規模プロジェクトについても導入してみました。

このフェイズでは、メンバー全員がプラクティスを実践できるように、プロジェクトを進めるメンバーと一緒にストーリーの単位で項目を整理し直し、方法のコツなどを共有しました。さらに、それらの相対規模の見積もりも一緒にやることで、規模に対する感覚をチーム全体で揃えていきました。

もとは「状態管理追加」、「UI実装」のような技術的タスクの単位で項目が並べられていましたが、項目間の依存関係やまとまりを顧客価値として整理することで、何が実現できるか明確になりました。また、カンバン上でユーザーストーリーの粒度で左から右に1つずつ開発項目を流せるようになりました。チームメンバーからも作業が進めやすくなり、1つ1つのユーザーストーリーのリードタイムが向上したという声をもらいました。

加えて、見積もりされたバックログ項目に取り組む中で、チーム全体のベロシティも安定して見えるようになってきたので、今後の開発の見通しを立てやすくなりました。

一休.comレストラン開発チームのベロシティ
一休.comレストラン開発チームのベロシティ

スプリント開始時にチームで計画づくり

以前は前のスプリントの残項目をそのまま次スプリントに移す3というプロセスでしたが、現在はビジネスの状況やすべきことの優先度、またチームのベロシティも都度確認して、目標を決めてバックログを作っています。

結果的に前スプリントで残った分も次のスプリントでやりましょうになることはあるのですが、なにも考えずに移すのではなく議論をしたうえで必要なら移すというプロセスを経るようにしています。

結果

2023年度下半期に次のような開発プロセス改善活動をおこないました。

  • 顧客価値に直結する開発をユーザーストーリーとして項目を整理
  • カンバン上で顧客価値につながる開発の進捗やボトルネックを見える化
  • ユーザーストーリーに対する規模の見積もりとベロシティの計測で開発ペースを見える化
  • スプリントの計画づくりで目標を定め、そのために必要なバックログを作る

もともと技術的にしっかりしたチームだったので、これらの改善活動の結果でフロー効率をよくすることで、以前よりリードタイムの向上や安定が見られるようになりました。

また、ストーリーに基づいた開発項目の見える化によって進捗がチーム内外からわかりやすくなり、デモやレポーティングなど組織運営に必要な業務も進めやすくなりました。先の計画を立てやすく、予定変更にも柔軟に対応できるようになってきています。

他には、計画づくりに意識的に取り組むようになったので、ずるずると開発してしまうことが減りました。ビジネスの推進に必要なことがなにかを都度確認しながら開発を進められています。

これから

すでに始めている取り組みとして、継続的に各チームメンバーがプロセス改善できるように、開発プロセスに関する知識をインプットする読書会を週次で開催しています。先日『カンバン仕事術』を読み終えたところです。

課題としては、技術的に専門性のあるメンバーに下周りの整備のようなタスクが集中したり、緊急の差し込みタスクをシステムに詳しいメンバーが多めに取りがちだったりと、メンバー間のスキルの差によってWIPが多くなったりすることもあります。こういうときにタスクを取捨選択したり、メンバー間で知識を共有していく方法については、既存のプラクティスも参照しながら継続的にチームで考えていくつもりです。

一休では、ともに良いサービスをつくっていく仲間を募集中です。

hrmos.co

カジュアル面談も実施しているので、お気軽にご応募ください。

www.ikyu.co.jp

  1. 著者(kymmt)は入社前〜入社直後なので聞いた話も含みます↩
  2. WIP制限に基づく方針ですが、このとき数値はとくに指定していませんでした↩
  3. Jiraの機能でそうなっていたというのもあります↩

一休レストランのふつうのRustバックエンド開発

この記事は一休.com Advent Calendar 2023 25日目の記事です。

一休レストランでは、よりスムーズな予約体験の提供を目的とするシステムのリニューアルを進めています。その一環として、2023年10月から、レストラン個別ページの表示から予約までのスマートフォンビューにおいて、バックエンドのサーバをRustで書かれたものに置き換えました。

本番運用が始まって3か月近く経ちましたが、これまで安定して継続的な開発と運用ができています。これはRustだからと構えることなく、「ふつう」のバックエンド開発を心がけてきたからだと考えています。

Advent Calendar 2023最終日は、一休レストランの開発チーム一同から、一休レストランのRustバックエンド開発の様子をお届けします。

Rustを選定した理由

一休レストランのリニューアル計画が始まったころ、一休では宿泊予約サービスや社内の基盤サービスを中心としてGoが標準的なバックエンドの技術スタックでした。

一休レストランの開発でも、宿泊予約サービスでの経験があるメンバーのスキルセットに基づいてGoを使うこともできました。その一方で、この方針だと社内の技術ポートフォリオがGoに偏ってしまうという懸念もありました。

一休では、社内で蓄積する技術的知見に多様性を持たせ、結果として状況に応じて最適な技術選定ができるように、複数のプログラミング言語を使うことを意図的に選択しています。

株式会社一休 会社紹介資料 / introduce-ikyu - Speaker Deck より一休の技術選定の方針について

そこで、チームメンバーの中にRustに詳しいエンジニアがいたことも助けになり、Rustをバックエンドの言語として採用するかどうかを検討しました。

Rustの採用による狙いは次のとおりです。

  • まず置き換えたい参照系処理のCPU利用効率を上げて、高速なバックエンドサーバとする
  • 今後のさらなる開発を見据え、メモリ安全、型安全な開発体験を実現する
  • 技術的知見の多様性という点で、関数型のメンタルモデルでプログラミングできるエンジニアを増やす

同時に、Rustの採用に対する次のような懸念も上がりました。

  • 初めて使うエンジニアにとっては学習に時間がかかる
  • ライブラリの自作が必要となるケースもありそう

Rustは公式ドキュメントやdocs.rsのリファレンスなどでドキュメントが充実しているので、学習曲線は急ではあるものの、学習自体は進めやすいと判断しました。

ライブラリについては、Rustから一休の基幹DBであるSQL Serverにどうやって接続するかという技術的な検証が必要でした。最終的には、Prismaが公開しているTiberiusというSQL Server用のDBドライバをベースとして、ある程度アプリケーションから使いやすいインタフェースのライブラリを整備することで開発が進められると判断できました。

これらの議論や調査に基づいて、一休レストランのバックエンドでRustを採用することになりました。

現在、一休レストランのバックエンドを開発するエンジニアは3人います。そのうち2人は、一休レストランの開発をきっかけに、はじめてRustを本格的に利用し始めました。豊富な学習リソースやRustに詳しいメンバーのヘルプを通じて、プロジェクト開始前の学習ではStringと&strの違いを理解するところから始めたメンバーも、プロジェクト開始後はスムーズに開発できるようになりました。

現在のバックエンドのユースケース

ここからはRustでバックエンドを「ふつう」に開発するための、設計や実装における面白いポイントを紹介していきます。

現在は主に次のユースケースでバックエンドを利用しています。

レストラン情報の取得

店舗情報や予約可能時間など、レストランの情報をお客様に提供するための情報を取得します。機能はGraphQLのクエリとして提供しています。

今回はレストラン個別のページの表示から予約までのフローの置き換えを開発スコープとしたので、現在はこのユースケースが大半を占めています。後述のとおりコードベース上もデータの読み出しに関するコードが多いです。

予約の確保

お客様から入力いただいた情報をもとに予約を確保するエンドポイントをGraphQLのミューテーションとして提供しています。また、実際の予約処理は、予約処理モジュールを持つ既存の社内別サービスに委譲しています。

現在のアーキテクチャ

現在、アプリケーションのアーキテクチャとしてコマンドクエリ責務分離(CQRS)に基づいた構造を採用しています。つまり、データを読み出すだけのクエリと、データの作成や更新をするコマンドで、利用するモデルを分離する方式をとっています。

また、たとえばクエリの場合、DBとSolrそれぞれについてデータアクセス層を設け、GraphQLのデータローダーのようなシステムの界面に近い層からは、データアクセス層を通じてクエリモデルの形式でデータを取得します。

モジュールとその依存関係

これらのモジュールはCargo workspaceを用いて管理しています。この点についてはあとで詳しく説明します。

各モジュールの紹介

上述した図における各層を構成するモジュールについて紹介します。

ドメインモデル

CQRSにおけるクエリとコマンドで利用するモデルを実装している層です。ドメインモデルは他のどのモジュールにも依存しません。また、クエリとコマンドは別モジュールとするためにcrateを分けています。

クエリモデルの例としては、レストラン詳細画面で表示する店舗情報があります。これらのデータは実際は複数のテーブルに存在しますが、クエリモデルはそのような実装詳細には依存せず、クエリの結果としてほしい構造を定義しています。実際には、SQL ServerもしくはSolrから得たデータをクエリモデルに変換して利用します。

#[derive(Debug, Clone)]
pub struct Restaurant {
    pub id: RestaurantId,
    pub name: String,
    pub description: Option<String>,
    // ...
}

コマンドモデルの例としてはお気に入り店舗登録用のコマンドモデルなどが存在します。こちらはまだ数が少ないので割愛します。

データアクセス層

実際のデータを取得するためのロジックを実装している層です。現在は、一休の基幹DBであるSQL Serverや、検索サーバであるSolrからデータを取得しています。このデータアクセス層の利用者に対して、取得したデータをもとにモデルのインスタンスを返します。つまり、ドメインモデルに依存します。

クエリを実行するときは、Serdeやserde_withを利用して、データストアから取得した生データをDTOにデシリアライズします。

mod dto {
    // ...

    #[serde_with::serde_as]
    #[derive(Debug, serde::Deserialize)]
    pub struct Restaurant {
        #[serde(rename = "restaurant_id")]
        #[serde_as(as = "serde_with::TryFromInto<i32>")]
        id: RestaurantId,

        #[serde(rename = "restaurant_name")]
        name: String,

        // ...
    }
}

さらに、このDTOからクエリモデルに変換するためにstd::convertのFromトレイトやTryFromトレイトを活用しています。詳しくは後述します。

GraphQLとHTTPサーバ

バックエンドはGraphQLを通じてフロントエンドにクエリとミューテーションを提供しています。このGraphQL APIの実装にはasync-graphqlを利用しています。async-graphqlはコードファーストでGraphQLスキーマを定義できるcrateです。

github.com

// Restaurant {
//   name
// }
// のようなスキーマをコードで定義

pub struct Restaurant(pub query_model::Restaurant);

#[async_graphql::Object]
impl Restaurant {
    async fn name(&self) -> &str {
        &self.0.name
    }

    // ...
}

また、HTTPサーバとしてはAxumを利用しています。

github.com

これまではGraphQLなのでエンドポイント1つで済んでいましたが、最近は社内の他サービスと通信するためにインターナルなREST APIを作る機会も増えてきています。

ライブラリ

アプリケーションを構成するモジュールとは別に、独立したロジックをまとめたライブラリとしてのcrateもいくつか作成してworkspaceに含めています。これらのライブラリは他モジュールから利用されます。

たとえば、先述したTiberiusをベースにしたDBドライバや社内サービスのクライアント、他にはログなどの横断的関心事を扱うライブラリが存在します。

Rustによる開発のふりかえり

よかったこと

Rustはビジネスロジックを書くのにも便利

Rustの言語機能として、所有権やライフタイムのようにメモリ安全性を意識したものがよく注目されます。さらに、Webアプリケーションバックエンドを書くうえでは、OptionやResultに代表される関数型言語のエッセンスを取り込んだ機能や、データ変換にまつわる機能も非常に便利だとあらためて感じました。

一休レストランは15年以上の歴史があるサービスです。このようなサービスは、しばしば歴史的事情からなるデータ構造やコードを多く持っています。たとえば有効な値とnullの両方が存在しうるカラムを扱うこともあります。このときにOptionを利用することで、ビジネスロジック上でnullにまつわるバグを避け、match式やif let式によって値がないケースをつねに考慮できます。

また、Webアプリケーションは無効な値を入力されたり外部のサービスとの通信に失敗するなど、つねにロジックが失敗する可能性があります。そのようなロジックでは返り値としてResult1を使うことで、確実にエラーをハンドリングできます。また、?演算子を利用することで、コードを簡潔に保ちつつエラーハンドリングできるのも便利な点です。

他には、一休レストランだと予約可能な時間や食事コースの検索結果などでコレクションを操作する場面が数多くあります。このようなときに、イテレータとmapやfilterのようなイテレータアダプタを利用することで、コレクションにまつわるビジネスロジックを簡潔に書けるのもよい点だと感じています。

アプリケーションの各層で型安全にデータを変換

先述したように、このアプリケーションでは複数のモジュールで責務を分けています。よって、そのままではデータアクセス層でデータストアから取得した生のデータをDTOを経由してクエリモデルに変換するロジックを書く必要が出てきます。

ここで、FromトレイトやTryFromトレイトを用いて型安全なデータの変換を実装することで、層の間で安全にデータを受け渡しできます。たとえばDTOをクエリモデルに変換するためにFromトレイトやTryFromトレイトをDTOに対して実装し、適切にモデルへ変換できるようにしています。

impl From<dto::Restaurant> for query_model::Restaurant {
    fn from(d: dto::Restaurant) -> Self {
        query_model::Restaurant {
            id: d.id,
            name: d.name,
            // ...
        }
    }
}

このようにモデルに対して変換のためのトレイトを実装しておけば、あとはfrom／try_fromやinto／try_intoを使うだけで層の間の型安全なデータ変換が可能になります。

Cargo workspaceを活用した開発

Cargo workspaceを活用してモジュール間の依存関係を制御しながら開発できているのもよい点です。

リポジトリのルートディレクトリにあるCargo.tomlでは、workspaceのmembersとしてアプリケーション内の各モジュールを指定しています。そして、それらのモジュールをcrateとして実装し、各crateのCargo.tomlではアーキテクチャを意識して他のcrateへの依存関係を設定することで、意図しない依存はコンパイラによってエラーにできる構造にしています。

# ルートディレクトリのCargo.toml
[workspace]
resolver = "2"
members = [
    "backend/*",
]

# データアクセス層のCargo.toml
[package]
name = "backend-data-access"
version.workspace = true
authors.workspace = true
edition.workspace = true
publish.workspace = true

[dependencies]
backend-query-model = { workspace = true }

また、モジュールをcrateに分離したことで、コードを変更したときに、変更のあったcrateとそのcrateに依存するcrateだけを再ビルドすればよくなりました。結果として、毎回アプリケーション全体をビルドせずに済み、開発時のビルド時間の短縮にも貢献しています。

パフォーマンスの向上

もちろんパフォーマンスの向上も当初の狙いどおり達成できた点であり、よかったことの1つです。

バックエンドはGoogle Cloud Runで運用しています。現在は年末年始でレストラン予約が非常に増える時期ですが、ピーク時でも3台程度のインスタンスでリクエストを受けることができています。

また、一休レストランのバックエンドの一部をRustに移行したことで、従来のPythonのバックエンドにおけるKubernetes DeploymentのReplicaSet数を次のように60程度から40程度に減らすことができました。

Wed 4以降はPythonバックエンドの負荷をオフロードできた

他には、バックエンドの高速化にともなってサービス全体の構成を最適化することで、一休レストラン全体のパフォーマンスが向上しました。こちらについてはチームメンバーのkozaiyが次の記事に詳しく書いたのでご覧ください。

user-first.ikyu.co.jp

もっとよくなると嬉しいこと

エコシステムのさらなる成熟

Webアプリケーションバックエンドを開発するうえで、さらにプラットフォームのRust対応が拡充されると開発が楽になりそうです。

たとえば、現在はCloud Runを使っているので、APMとしてCloud Traceを利用することにしました。しかし、公式にはRustのSDKが提供されていないことから、独自のライブラリを開発することで対応しています。

まとめ

この記事では、一休レストランにおいてRustを採用した理由と、Rustによる「ふつう」のWebアプリケーションバックエンド開発の様子について紹介しました。

Rustを採用したことで、期待どおり性能面で大きなメリットを得ることができました。また、RustやCargoの機能を適切に活用することで、生産性を保ちつつ今後の継続性も考慮した設計で開発を進めることができています。

新たにRustを利用し始めたチームメンバーからは、Rustに対する感想として

  • 自分自身にプログラミングを教えてくれる言語だなと思いました
  • プログラミングする上で、気にすべきポイントを気にさせてくれる言語

という声もあがっています。

今後のバックエンドの展望としては、よりよい予約体験の提供やレガシーシステムの改善を目的として、

  • 高速なレスポンスが求められるレストラン検索
  • レストラン予約のロジックなどのレガシーかつコアドメインであるモジュール

についてもRustで置き換えていく予定です。このような箇所では、高いパフォーマンスや型に守られた開発体験を提供してくれるRustを活かすことができるだろうと考えています。

このような技術的なチャレンジができる一休レストランのバックエンド開発に興味があるかたは、ぜひカジュアル面談応募ページや求人ページからご連絡ください。

hrmos.co

www.ikyu.co.jp

  1. 一休レストランではanyhow::Resultを利用しています↩
Copyright© 株式会社一休®, All Rights Reserved.