一休.com Developers Blog

一休 Frontend Meetupでエンジニアとデザイナーがフロントエンド開発の知見について紹介しました

Thu, 20 Feb 2025 10:19:06 +0900

kymmtです。

先日2月10日に、一休のフロントエンド技術にフォーカスしたイベント「一休 Frontend Meetup」を開催しました。

ikyu.connpass.com

一休 Frontend Meetupとしては2年半ぶりの開催となりました。

このイベントでは一休開発チームのメンバーが登壇し、各サービスのフロントエンドについて工夫や知見を紹介しました。この記事ではイベントの様子を紹介します！

当日のハッシュタグは#ikyu_devでご覧になれます。

発表

『一休.com のログイン体験を支える技術〜Web Components x Vue.js 活用事例と最適化について〜』

1つ目の発表は、認証基盤などの開発に携わる渥美さんによる『一休.com のログイン体験を支える技術』でした。

一休の各サービスが利用している社内認証基盤では、ユーザーのログイン／SMS認証の際に表示するモーダルウインドウなどを提供するアセットを配布しています。この発表では、ユーザー体験も考慮してスムーズなログインできるモーダルウインドウをWeb ComponentsやVue.jsを用いて開発する方法について紹介しました。

『Webパフォーマンス改善〜宿泊予約サービスでの取り組み〜』

2つ目の発表は、CTO室で全社的なフロントエンド改善に取り組む卯田さんによる『Webパフォーマンス改善〜宿泊予約サービスでの取り組み〜』でした¹。

宿泊予約サービスの一休.comのWebパフォーマンス改善では、指標として主にCore Web Vitalsの値をトラッキングしています。改善の方針としては、特定の箇所をカリカリにチューニングするより、ユーザー体験重視で全体的に遅くならないよう気をつけています。

発表では、実際に改善活動で指標を監視するために使っているLooker StudioやDatadogのダッシュボードをデモを交えつつ紹介しました。また、フロントエンドに関する知見を収集するための方法についても紹介しました。

『一休の世界観を形にする、ガイドラインとデザインシステム』

3つ目の発表は、一休.comレストランのデザイナー高橋さんによる『一休の世界観を形にする、ガイドラインとデザインシステム』でした。

一休では、デザイナーを中心に「一休らしさ」を実現するためのIKYU Design Guidelineを策定し、各サービスを横断してブランドイメージの一貫性を保つようにしています。

ガイドライン策定による成果として、デザインシステムの運用と各プロダクトへの適用や、デザイナーとエンジニアの協働がやりやすくなったので、一休らしい世界観の提供に役立っているという話がありました。

『飲食店予約台帳を支えるインタラクティブUI設計と実装』

最後の発表は、RESZAIKO台帳のエンジニア白井さんによる『飲食店予約台帳を支えるインタラクティブUI設計と実装』でした。

RESZAIKOは一休が飲食店向けに提供している予約管理のSaaSです。RESZAIKOが提供するサービスの1つとして、今回発表のテーマになった予約台帳サービスがあります。

発表では、iPadのようなタブレットで操作しやすい予約台帳サービスのインタラクティブUIを設計する方法について、

UIをインタラクティブにするための基本的な方法
Canvasの使いどころ
コンポーネントとしてUIのレイヤーを実装することで責務を整理する手法

などを中心に解説しました。

おわりに

「一休 Frontend Meetup」での一休のフロントエンド技術領域に関する発表の様子を紹介しました。一休では、宿泊予約やレストラン予約の領域でユーザーファーストなサービスを作りたいというフロントエンドエンジニアを募集しています！

hrmos.co

当日は40人ほどの方に来場いただきました。ご来場いただいたみなさま、ありがとうございました！

資料非公開です↩

Jotai を使った Dependency 管理とテスト技法

Mon, 23 Dec 2024 19:11:34 +0900

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

一休レストランのフロントエンドアーキテクトを担当してる恩田(@takashi_onda)です。

はじめに

先日の JSConf JP 2024 で「React への依存を最小にするフロントエンドの設計」という内容で登壇しました。

speakerdeck.com

発表では駆け足になってしまった、React への依存をしていない Vanilla JS 部分をどのように構成しているのかを、Dependency 管理とテストの文脈でご紹介したいと思います。

Dependency とは Dependency Injection の Dependency です。タイトルも「Jotai を使った DI とテスト技法」とした方が伝わりやすいとは思います。ですが、厳密には injection していないので、あえて Dependency という表現に留めています。

以下 Dependency や依存関係という言葉を使っているときは Dependency Injection の Dependency のことだとご認識ください。

アーキテクチャ

まずは、前提となるアーキテクチャの概観から説明します。

ステート管理には Jotai を利用しており、primitive atom にはステートマシンの state だけを持つ、ステートマシンを中心に据えた設計¹を採っています。

derived atom はステートマシンから導出しています。図にあるように jotai-tanstack-query の queryOptions もステートマシンの derived atom です。これにより、状態が遷移する度に必要に応じて fetch が走り、最新のデータが表示されます。

const isReservable$ = atom((get) => { /* snip */ })

export function useIsReservable() {
  return useAtomValue(isReservable$)
}

React コンポーネントは末端の derived atom を見ているだけなので、ロジックとは疎結合を保っています。

余談ですが、atom の命名として、かつての RxJS に倣い suffix として $ を利用しています。以降のコード片でも同じ命名としているので $ は atom と思っていただければ。

const transition$ = atom(null, async (get, set, event: CalendarEvent) => {
  const current = get(calendarState$)
  const next = await transition(current, event)
  if (!isEqual(state, next)) {
    set(carendarState$, next)
  }
})

const selectDate$ = atom(null, (_get, set, date: string) => {
  set(transition$, calendarEvent('selectDate', { date: toDate(date) }))
})

export function useSelectDate() {
  return useSetAtom(selectDate$)
}

状態遷移は transition 関数を writable derived atom としていて、すべての変更・副作用は状態遷移を経由して実現しています。

Flux アーキテクチャではあるものの、React コンポーネントからはフックで得られた関数を呼ぶだけの独立した作りであり、表示側同様にロジックの構造とは疎結合になるように留意しています。

Dependency の管理

上述のアーキテクチャでは状態遷移を起点に、データの取得・更新など、外部とのやりとりが発生します。

テストが多くを占めますが、利用場面によって、その振る舞いを切り替えたいときがあります。

ここでは、 Jotai を Dependency の格納庫である Service Locator として活用する手法についてご紹介します。

Jotai で function を管理する

まずは軽く Jotai の TIPS 的なお話から。

Jotai では primitive atom, derived atom いずれも atom 関数で作成します。その実装では typeof で第一引数が function かどうかを判定して、オーバーロードを行っています。

すなわち、そのままでは function を atom の値として扱えません。 derived atom とみなされてしまうためです。

そこで、以下のようなユーティリティを作成しました。

function functionAtom<F extends Function>(fn: F): WritableAtom<F, [F], void> {
  const wrapper$ = atom({ fn })
  return atom<F, [F], void>(
    (get) => get(wrapper$).fn,
    (_get, set, fn) => {
      set(wrapper$, { fn })
    }
  )
}

テスト時に function を test double に切り替える程度であれば、functionAtom ユーティリティだけで対応できます。具体的には GraphQL クエリを実行する関数を管理しています。

export const callGraphql$ = functionAtom(callGraphql)

テストコードでは以下のように test double で置き換えています。

describe('queryRestaurants$', () => {
  test('pageCount$', async () => {
    // arrange
    const store = createStore()
    store.set(callGraphql$, vi.fn().mockResolvedValue(/* snip */))
    // act
    const page = await store.get(pageCount$) // drived from queryRestaurants$
    // assert
    expect(page).toEqual(7)
  })
})

Jotai Scope で Dependency を切り替える

次は、もう少し複雑なケースです。

コンポーネントの振る舞いを利用箇所によって切り替えたい、という場面を考えます。カレンダーやモーダルダイアログで見られるような、複数の操作を持つ複雑なコンポーネントを想定してください。

React で素直に書くならコールバックを渡し、コンポーネント root で Context に保持して、コンポーネントの各所で使う形になるでしょう。

type Dependency = {
  onToggle: (facet: Facet) => boolean
  onCommit: (criteria: SearchCriteria) => void
}

const Context = createContext<Dependency>(defaultDependency)

export function Component(dependency: Dependency) {
  return (
    <Context value={dependency}>
      <ComponentBody />
    </Context>
  )
}

export function useOnToggle() {
  return use(Context).onToggle
}
export function useOnCommit() {
  return use(Context).onCommit
}

さて、そもそもの動機に戻ると、React に依存したコードを最小限にしたい、という背景がありました。ロジック部分は Vanilla JS だけで完結させるのが理想的です。

言い換えれば、Jotai だけで Dependency を切り替える仕組みを作りたい、ということです。そこで atoms in atom と jotai-scope を利用することにしました。

コードを見ていただくのが早いと思います。

type Dependency = {
  toggle$: WritableAtom<null, [Facet], boolean>
  commit$: WritableAtom<null, [SearchCriteria], void>
}

const dependencyA: Dependency = {
  toggle$: atom(null, (get, set, facet) => true),
  commit$: atom(null, (get, set, criteria) => {}),
}

const dependencyB: Dependency = {
  toggle$: atom(null, (get, set, facet) => false),
  commit$: atom(null, (get, set, criteria) => {}),
}

type Mode = 'A' | 'B'
const mode$ = atom<Mode>('A')

// atom を返す atom
const dependency$ = atom((get) => {
  switch (get(mode$)) {
    case 'A': return dependencyA
    case 'B': return dependencyB
  }
})

if (import.meta.vitest) {
  const { describe, test, expect } = import.meta.vitest
  describe('dependency$', () => {
    test('mode A toggle', () => {
      // arrange
      const store = createStore()
      store.set(mode$, 'A')
      // act
      const { toggle$ } = store.get(dependency$)
      const result = store.set(toggle$, facetFixture())
      // assert
      expect(result).toBe(true)
    })
    test('mode B', () => {
      // snip
    })
  })
}

Jotai だけで Dependency の切り替えが完結しました。

あとは React とのグルーコードです。

ここで Jotai Scope が登場します。 React コンポーネントでは、振る舞いを切り替える区分値を指定するだけになりました。

export function useToggle() {
  return useSetAtom(useAtomValue(dependency$).toggle$)
}

export function useCommit() {
  return useSetAtom(useAtomValue(dependency$).commit$)
}

export function ModeProvider({ mode, children }: PropsWithChildren<{ mode: Mode }>) {
  return (
    <ScopeProvider atoms={[mode$]}>
      <Init mode={mode} />
      {children}
    </ScopeProvider>
  )
}

function Init({ mode }: { mode: Mode }) {
  const setMode = useSetAtom(mode$)
  useEffect(() => {
    setMode(mode)
  }, [mode, setMode])
  return null
}

テスト技法

一休レストランでは単体テストに Testing Library を利用していません。

React に依存するコードを最小化することで、Vanilla JS だけで単体テストやロジックレベルのシナリオテストを実現しています。

純粋関数で書く

基本的な方針として、derived atom とその計算ロジックは峻別しています。言い換えれば Jotai の API を利用している部分とロジックの本体となる関数を分離するようにしています。

値を取得する derived atom の例です。

const c$ = atom((get) => {
  const a = get(a$)
  const b = get(b$)
  return calc(a, b)
})

function calc(a: number, b: number) {
  return a + b
}

if (import.meta.vitest) {
  const { describe, test, expect } = import.meta.vitest
  describe('calc', () => {
    test('1 + 2 = 3', () => {
      expect(calc(1, 2)).toEqual(3)
    })
  })
}

テストコードには Jotai への依存はなく、ただの純粋関数のテストになります。

writable derived atom も同様です。

const update$ = atom(null, (get, set) => {
  const a = get(a$)
  const b = get(b$)
  set(value$, (current) => calcNextValue(current, a, b))
})

function calcNextValue(value: Value, a: A, b: B): Value { /* snip */ }

更新処理の中で次の値の計算を純粋関数として分けておけば、引数を与えて返り値を確認するだけの、もっともシンプルな形のテストとして書けるようになります。

実際のコードでは、上述したように、ロジックの中核にステートマシンを据えているので、ステートマシンにイベントを送って次状態を確認するテストがそのほとんどを占めています。

describe('calendar state machine', () => {
  test('日付を変更すると、選択されている時間帯にもっとも近い予約可能な時間を設定する', async () => {
    const fetchTimes = vi.fn().mockResolvedValue({
      restaurant: {
        reservableTimes: ['11:30', '13:00', '18:30', '20:30', '21:00'],
      },
    })
    const { transition } = createStateMachine(fetchCalendar, fetchTimes)
    const current = createCurrent()
    const result = await transition(
      current,
      calendarEvent('selectVisitDate', { visitDate: asDate('2024-10-26') })
    )
    expect(result.value).toEqual('READY')
    expect(result.context.visitTime).toEqual({
      ...current.context,
      visitDate: '2024-10-26',
      selectedVisitDate: '2024-10-26',
      visitTime: '18:30',
    })
  })
})

シナリオテスト

最後に、ロジックレベルのシナリオテストについてご紹介します。

今まで見てきたように、画面上での操作は、ロジックレベルで見ると、ステートマシンの一連の状態遷移になります。言い換えれば、ユーザーの操作に対応する状態遷移と、ステートマシンから派生する derived atom の値がどうなっているかを確認することで、ロジックレベルのシナリオテストが実現できます。

長くなるので一部だけ抜粋しますが、以下のような形でテストを書いています。

Jotai には依存していますが、一連のユーザー操作とそのときどんな値が得られるべきかのシナリオが Vanilla JS だけでテストできるのがポイントです。

test('人数・日時・時間未指定で、日付だけ選択して予約入力へ', async () => {
  const store = createStore()
  store.set(calendarQueryFn$, async () => reservableCalendar)
  store.set(timesQueryFn$, async () => reservableTimes)
  store.set(now$, '2023-10-25T00:00:00.000+09:00' as DateTime)

  // 初期表示
  await store.set(transition$, calendarInitEvent())
  expect(store.get(visitDate$)).toEqual('2023-10-26')
  expect(store.get(visitTime$)).toEqual('19:00')

  // 日付を選んだとき
  await store.set(selectDate$, toDate('2023-11-04'))
  expect(store.get(visitDate$)).toEqual('2023-11-04')
  expect(store.get(visitTime$)).toEqual('18:30')

  // ...
})

おわりに

ここまで読んでいただきありがとうございました。

本記事がフロントエンド設計を検討する際の一助となれば幸いです。

一休では、本記事でお伝えしたような課題をともに解決するエンジニアを募集しています。

www.ikyu.co.jp

まずはカジュアル面談からお気軽にご応募ください!

hrmos.co

記事では XState を紹介していますが、現在は独自のステートマシン実装への置き換えを進めています。軽量サブセットである @xstate/fsm がバージョン 5 から提供されなくなったこと、型定義や非同期処理の機能不足が理由です。↩

Cloud WorkflowsとCloud Tasksを使って日次のバッチ処理を作る

Thu, 19 Dec 2024 15:48:26 +0900

宿泊システムのバッチ処理について（背景・課題）
新たに必要になったバッチ処理をどうやって作るか
Cloud Workflows + Cloud Tasks を使ったバッチ処理
リリース後の運用
- Cloud Tasksのキュー設定の調整
- 異常終了時の検知を強化
まとめ
おわりに

宿泊プロダクト開発部の田中（id:kentana20）です。

このエントリーは一休.com Advent Calendar 2024の19日目の記事です。

今回は一休.com宿泊のとあるプロジェクトで必要になった 「ホテル・旅館の商品データを日次で更新する」 という処理を

Cloud Scheduler
Cloud Workflows
Cloud Tasks

とWeb APIで構築、運用している事例をご紹介します。

宿泊システムのバッチ処理について（背景・課題）

一休.com 宿泊には、業務に必要なデータ作成や更新を行うバッチ処理が多く存在します。たとえば

投稿されたクチコミ評点を集計してホテル、旅館のスコアを更新する
前月分までの宿泊予約データをもとにユーザーにポイントを付与する

などです。これらのバッチ処理は宿泊システムの中でも古い部類に入る技術スタック（ASP.NET(C#/VB)）で作られており

スピーディに開発できない
バッチ処理の開発に慣れているメンバーが限られている

といった課題がありました。

新たに必要になったバッチ処理をどうやって作るか

今年の春頃に実施したプロジェクトで「ホテル・旅館の売れ筋商品（プラン）を日次で洗替する」という処理を新たに作る必要が出てきました。

ざっくりとした要件は以下のような内容です。

一休.comに掲載している一部のホテル・旅館を処理対象とする
処理対象のホテル・旅館に対して、直近XX日間の予約を集計して売れ筋商品（プラン）を抽出する
対象の売れ筋商品（プラン）に対してフラグを立てる
処理対象のホテル・旅館は増えたり、減ったりする
売れ筋商品の洗替は日次で行う

前述の背景・課題があったため「新しい開発基盤を作ってバッチ処理をスピーディに開発できるようにする」ことを考えてCTOに壁打ちをしたところ「新しい開発基盤を作る前に、そもそもこれはバッチで作るのがベストなのか？」というフィードバックをもらいました。具体的には

一休.com宿泊では、歴史的経緯*1から、オンライン処理できないものをほとんどバッチで作っている
現在では、そもそもバッチでまとめて処理せずに、非同期化・分散処理をする選択肢もある
バッチで作るのが本当にベストなのか、ほかの選択肢も含めて検討したほうがよい

といった内容でした。このフィードバック内容を踏まえて

（もともとの案）新たにバッチ開発の基盤を作る
マネージドなクラウドサービスを組み合わせて作る

を検討し

今回実施したい作業はシンプルな処理の組み合わせで実現可能であること
並列、分散処理を考えやすい要件であること（ホテル・旅館単位で処理しても問題ない）

といった理由から、最終的に2を選択しました。

Cloud Workflows + Cloud Tasks を使ったバッチ処理

クラウドサービスについて、一休では、AWSとGoogle Cloudを併用しています。新しく作るサービスではGoogle Cloudを使うケースが増えている一方で、一休.com 宿泊ではまだ事例が少なかったこともあり、今回はGoogle Cloudを使うことにしました。

処理フロー

Cloud Scheduler
Cloud Workflows
Cloud Tasks

の3サービスと、シンプルなWeb APIを組み合わせた設計にしており、以下のような流れで動いています。

処理フロー

Cloud Workflows

cloud.google.com

Cloud Workflowsは、マネージドなジョブオーケストレーションサービスです。ワークフローに定義された処理順（ステップ）に従って

Google Cloudのサービスを実行する
任意のHTTPエンドポイントにリクエストする

などを実行することができます。公式ドキュメントにも日次のバッチジョブの例が載っており、バッチ処理がユースケースの1つであることがわかります。

ワークフローで実行したい内容（ステップ）をYAML形式で記述します。以下は、今回作ったワークフローのイメージです。

main:
  steps:
    - init:
        assign:
          - queueName: "cloud-tasks-queue-name"
    - getTargetHotels:
        call: http.get
        args:
          url: "https://api.example.com/hotels"
          auth:
            type: OIDC
          query:
            target: true
        result: hotelData
    - createCloudTasks:
        palallel:
          for:
            in: ${hotelData.body.hotels}
            value: hotel
            steps:
              - createTask:
                  call: googleapis.cloudtasks.v2.projects.locations.queues.tasks.create
                  args:
                    parent: "projects/${sys.get_env('GOOGLE_CLOUD_PROJECT_ID')}/locations/${sys.get_env('LOCATION')}/queues/${queueName}"
                    body:
                      task:
                        httpRequest:
                          httpMethod: "PUT"
                          url: "https://api.example.com/hotels/${hotel.id}/popular"
                          headers:
                           Content-Type: "application/json"
                          oidcToken:
                            serviceAccountEmail: ${"application@" + projectId + ".iam.gserviceaccount.com"}

Workflowsから外部APIを呼び出す

getTargetHotels のステップで、Web APIへリクエストして対象のホテル・旅館を取得しています。 auth でOIDCを指定していますが、これによってWorkflowsからのAPIリクエストにAuthorizationヘッダを付与することができます。

ワークフローからの認証済みリクエスト | Workflows | Google Cloud

呼び出されるAPIで、このヘッダを使ってIDTokenを検証することで、Workflowsからのリクエストであることを保証しています。*2

以下は、IDTokenの検証をするミドルウェアのサンプル実装（Go）です。

import (
    "fmt"
    "net/http"
    "strings"

    "google.golang.org/api/idtoken"
)

// IDトークンを検証するミドルウェア
func AuthMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // Authorization ヘッダからBearerトークンを取得
        authHeader := r.Header.Get("Authorization")
        if authHeader == "" {
            http.Error(w, "Authorization header is required", http.StatusUnauthorized)
            return
        }

        token := strings.TrimPrefix(authHeader, "Bearer ")

        // IDトークンの検証
        _, err := idtoken.Validate(r.Context(), token, "")
        if err != nil {
            // トークンの検証に失敗した場合はエラーを返す
            http.Error(w, "Invalid ID Token", http.StatusUnauthorized)
            return
        }

        // トークンが有効であれば、次のハンドラーを呼び出す
        next.ServeHTTP(w, r)
    })
}

APIのレスポンスをもとにCloud Tasksにエンキューする

createCloudTask のステップで、Web APIで取得した hotelData.body.hotels に含まれるホテル・旅館ごとにCloud Tasksにエンキューしています。前述したように実行順序を考慮する必要がないため、parallel を使って並列処理しています。

また、 oidcToken を指定することで、Cloud TasksがAPIリクエストを送る際にOIDCトークンを付与することができます。これによってWorkflowsからのAPIリクエストと同様に、API側でIDTokenを検証することができます。

Cloud Tasks

cloud.google.com

Cloud Tasksについては、昨年のAdvent CalendarでCTO室の徳武が詳細に解説していますので、ぜひご覧ください。

zenn.dev zenn.dev

Web API

Cloud Workflows/Cloud Tasksが呼ぶWeb APIは、以下の2つを用意しました。

処理対象のホテル・旅館を取得するAPI（GET）
指定されたホテル・旅館IDをもとに売れ筋商品を更新するAPI（PUT）

どちらのAPIも、特定のユースケースに合わせたAPIという形ではなく、単一のリソースを取得/更新するというシンプルな仕様にして再利用可能な設計にしています。

この設計にしたことによって、リリース後に「ホテル・旅館が管理システムから任意の操作をした際に、売れ筋商品を更新したい」というユースケースが出てきたときも、2のAPIを使って対応することができました。

リリース後の運用

このWorkflowsを使ったバッチ処理をリリースした後に、安定運用のためにいくつか変更したポイントがあるのでご紹介します。

Cloud Tasksのキュー設定の調整

Cloud Tasksの設定が適切ではなく、Web APIへの秒間リクエスト数が多すぎてレスポンスが遅くなるという事象があったため

最大ディスパッチ数
最大同時ディスパッチ数

などを調整しました。

キュー設定変更のPull Request

異常終了時の検知を強化

異常があった場合に、受動的に気付けるように

Workflowsのエラー処理を調整する
エラーログ（Cloud Logging）をSlackに通知する

といった対応をしました。

まとめ

Cloud Workflows + Cloud TasksとWeb APIを組み合わせたバッチ処理を実装した事例をご紹介しました。個人的な所感としては、以下のようなメリットを感じています。

Cloud Workflowsはある程度複雑な処理も定義できるため、バッチ処理で必要な手続きをアプリケーション内部に書かずにシンプルなWeb APIとの組み合わせでバッチ処理を作れる
データの更新処理は特に、処理単位を小さくする＆ Cloud Tasksなどのキュー処理を使うと並列実行やエラー時のリトライをマネージドにできるので、運用が楽になる
- 実際に、キュー設定の調整をする前は初回エラー → キューのリトライによって成功する、といったケースがあり、運用上問題になることはなかったです

また、今回は採用しませんでしたが、一休社内ではCloud Run Jobsを使ったバッチ処理の基盤も整ってきており、冒頭にご紹介した課題に対して複数の解決方法ができつつあるので、既存のレガシーなバッチ処理も少しずつ刷新していきたいと考えています。

おわりに

一休では、事業の成果をともに目指せる仲間を募集しています。

www.ikyu.co.jp

まずはカジュアル面談からお気軽にご応募ください!

hrmos.co

明日は @yamazakik の「一休バーチャル背景を作ったはなし」です。お楽しみに!

*1:非同期ジョブキューの仕組みがない時代に作られたバッチが多く残っています

*2:実際には、この保証だけでなくほかの方法も含めて安全に運用できるように設計しています

一休.com の情シス / コーポレートIT 変遷、6年を経てどう変わったのか

Mon, 16 Dec 2024 19:06:30 +0900

はじめに

id:rotom です。社内情報システム部兼 CISO室所属で ITとセキュリティを何でもやります。

このエントリは 一休.com Advent Calendar 2024 16日目の記事です。昨日は id:naoya による TypeScript の Discriminated Union と Haskell の代数的データ型でした。その他の素敵なエントリも以下のリンクからご覧ください。

qiita.com

2018年のアドベントカレンダーにて「一休における情シスの取り組み」を紹介させていただき、一定の反響をいただくことができました。早いものであれからすでに6年が経過しました。6年も経つとコーポレートIT も変遷しています。

user-first.ikyu.co.jp

これまで特定の製品・サービスの事例などは断片的に紹介していましたが、6年ぶりに改めて全体像をお話したいと思います。

なお、主に私が進めてきたコーポレートIT、セキュリティ分野に注力して紹介します。ネットワーク、インフラ分野でも非常に多くの変遷・改善がありますが、同僚の ryoma-debari のエントリや、HPE 社のプレスリリースなどもご覧ください。

qiita.com

www.arubanetworks.com

取り組んできたこと

組織体制の変化

before: システム本部
after: コーポレート本部

社内研修資料より

一休の情報システム部門は前身となるインフラチームからの流れを汲んでエンジニア部門に所属していましたが、部署ごとバックオフィス部門に異動しました。

情シスがエンジニアとバックオフィスどちらに所属すべきか、という議論に定説はなく各の組織文化に依る部分がありますが、一休においてはバックオフィス部門に所属することで、人事総務、財務経理、法務などとの連携が円滑になり、後述する本社オフィス移転などの大規模プロジェクトもスムーズに進めることができたと思います。

一休はここ数年で新規事業が複数立ち上がり、ビジネスとしても大きく成長しており、ともなって従業員も増加していますが、情シスのチームは非常にコンパクトに運営できており、2024/12 時点で専任の社員は2名です。ゼロタッチデプロイやプロビジョニング、ChatOps を始め、業務の自動化・改善が進み、ルーチンワークが占める割合が減ったためです。引き続き情シスの省力化に取り組みます。

オフィスファシリティの刷新

before: 赤坂
after: 紀尾井町

紀尾井町オフィスラウンジ

長らく赤坂見附のトラディッショナルなビルに3フロア借りていましたが、2022年に当時のZホールディングス、現・LINEヤフーの本社が入居する東京ガーデンテラス紀尾井町紀尾井タワーへ移転しました。先日は情シスカンファレンス BTCONJP 2024 の会場にもなりました。

移転のタイミングで多くのオンプレミス資産を廃棄し、昨今のインターネット企業らしいモダンなコーポレートIT へ刷新をしました。 固定電話や FAX を廃止した 話や、入退室管理などのファシリティ周りの話については、下記エントリに詳細を書きましたので合わせてご覧ください。

user-first.ikyu.co.jp

なお、本社移転ほどの規模ではありませんが、6年間で 支社・営業所の立ち上げは6拠点、移転は8拠点 で実施しており、ほぼ常にどこかの拠点へ飛び回っていました。地方拠点においてもオンプレミスで持つ資産は廃止を進め、本社同様に固定電話や FAX、有線 LAN を廃止した非常にコンパクトなインフラ構成になりました。

Slack Enterprise Grid 移行

before: Slack Business Plus
after: Slack Enterprise Grid

10年お世話になっております

一休は2014年より Slack を利用しています、もう11年目になります。そんな10年の節目（？）にプランを最上位である Enterprise Grid へアップグレードしました。

2つあったワークスペースは1つの OrG の配下に統制され、監査ログ API やデータ損失防止（DLP：Data Loss Prevention）などのエンタープライズ組織向けのセキュリティ機能が利用可能になり、よりセキュアに利用できるようになりました。

Slack はカジュアルにコミュニケーションがとれる便利なツールである反面、情報漏えいの発生源になるリスクもあります。適切に監査・統制することで、利便性と安全性を両立していきます。

クレデンシャル情報を書き込むと自動的に検知・削除・警告をします

Enterprise Grid 向け機能のひとつである「情報バリア」については、2023年のアドベントカレンダーで解説しています。

user-first.ikyu.co.jp

デバイス管理の刷新

before: オンプレミス IT資産管理ツール
after: Microsoft Intune / Jamf Pro

Mac の標準スペックは 2024/12 時点でM4 Max（RAM 64GB）、社内に Intel Mac は0

以前は Windows と Mac それぞれの OS 向けの資産管理ツールをオンプレミスのサーバー上に載せており、オフィスのサーバールームで元気に稼働していました。 Windows Server の EOL のタイミングなどもあり、フルクラウド型のモバイルデバイス管理（MDM：Mobile Device Management）への移行を検討し、Windows は Microsoft Intune、Mac は Jamf Pro を選定しました。

MDM 導入前は入社準備でデスクに PC、iPhone、iPad を数十台並べてひたすらセットアップする光景が風物詩でしたが、Windows は Windows Autopilot、Mac、iPhone、iPad は Apple Business Manager と連携した Automated Device Enrollment によりゼロタッチデプロイが可能になり、キッティングにかかる工数を大幅に削減できました。

www.microsoft.com

www.jamf.com

iPhone / iPad については当時すでに別の MDM が導入されていたのですが、後にリプレイスを行い、現在は Mac と合わせて全て Jamf Pro で統合管理されています。これらの製品は MDM として広く知られているものなので、詳細な説明は割愛します。

当時の一休はエンジニアも含めて Windows の割合が非常に高く、 Windows / Mac 比率 8:2 という状態からの Jamf Pro 導入でした。マイノリティである Mac は冷遇されがちでほぼ野良管理、自己責任での利用という状態から、Jamf Pro により適切に管理・統制された状態まで進めることができました。

Windows 混在環境における Jamf Pro 導入については、 Jamf Connect も含め導入事例、プレスリリースで広く紹介していただいています。

www.jamf.com

EDR / SIEM 導入

before: オンプレミスアンチウイルスソフト
after: Microsoft Defender for Endpoint, Microsoft Sentinel

エンドポイントセキュリティもIT資産管理ツール同様、オンプレミスで稼働するアンチウイルスソフトを利用していました。

サーバーの保守運用コストがかかるだけではなく、デバイスへの負荷が大きい、最新 OS への対応が遅い、パターンマッチングでの検知・検疫はできる一方で、侵入後のリアルタイム検知ができないなどの課題もあり、EDR（Endpoint Detection and Response）型のセキュリティ製品へのリプレイスを検討している中で、Microsoft Defneder for Endpoint（以下、 MDE）を導入しました。

www.microsoft.com

Mac については Jamf Protect という製品もありますが、Windows / Mac / iOS / iPadOS などマルチ OS に対応している点からも、Apple デバイスも MDE で運用しています。

同時期に SIEM（Security Information and Event Management）として Microsoft Sentinel を導入しており、MDE や Microsoft Defender for Identity などで検知したログは Microsoft Sentinel に集約され、インシデントは Slack に通知され、リアルタイムに検知・分析・対応ができる運用をしています。

azure.microsoft.com

ライセンス・アカウント管理の改善

before: Google スプレッドシート
after: Snipe-IT, Torii

更新せずに放置していると here メンションがついて赤くなります

Google スプレッドシートなどでがんばっていたIT資産・ライセンス管理については Snipe-IT というOSS の IT資産管理ツール（ITAM：IT Asset Management）を導入しました。 OSS なので自前でホスティングすれば費用はかからず、hosting packages を利用すればランニングコストを支払い SaaS のように利用することもできます。

snipeitapp.com

Snipe-IT に登録された情報をもとに Slack に更新期日の近いライセンスを通知することで、うっかり失効してしまう、自動更新してしまい事後稟議になってしまう、といった事故を防いでいます。

また、近年では SaaS 管理プラットフォーム（SMP：SaaS Management Platform）というジャンルの、いわゆる SaaS を管理する SaaS が登場しています。国産ではジョーシスなどが有名ですが、グローバル SaaS を非常に多く取り扱う一休では Gartner の Magic Quadrant でも高く評価されている Toriiを選定 しました。

www.toriihq.com

こちらでコスト可視化や Microsoft Entra ID の SCIM（System for Cross-domain Identity Management）によるプロビジョニングに対応していない SaaS の棚卸しを実施していきます。まだ導入して日が浅いため、運用設計のノウハウが溜まってきたらどこかでアウトプットできればと思います。

ヘルプデスクの改善

before: Google フォーム
after: Jira Service Management

6年前のエントリでは Google フォームでヘルプデスク対応を行っていると書きましたが、その後、Halp という製品を導入し、Halp が Atlassian に買収されたことで、Jira Service Management（以下、JSM）に統合されました。 Slack のプレミアムワークフローが無償化したことから移行も検討していますが、現時点ではまだ機能に不足を感じており、JSM での運用を続ける予定です。

www.atlassian.com

従業員は Slack に普通に投稿するだけでチケットが自動起票され、クイックに対応可能です。出張や外出が多い営業社員もスマートフォンからスムーズに問い合わせができます。ヘルプデスクでよくある DM 問い合わせ問題も解決しています。

ヘルプデスク改善のあらましについては、下記エントリをご覧ください。

user-first.ikyu.co.jp

Slack 打刻 / 勤怠打刻自動化

before: Web アプリ / モバイルアプリ
after: Slack / Akerun 連携

Slack から打刻できるのはとても便利

一休では勤怠管理システムとしてチムスピ勤怠（TeamSpirit）を利用しています。勤怠打刻をする際は Web アプリから打刻するか、Salesforce のモバイルアプリを利用する必要がありました。ブラウザを立ち上げて、アクセスパネルアプリケーションから TeamSpirit を開いて打刻をする、というのは少々手間であり、勤怠打刻漏れもよくおきていました。

corp.teamspirit.com

TeamSpirit が Slack 連携機能を提供開始した際には早速設定を行い、Slack で打刻が完結するようになりました。

その後、全社で利用していた入退室カードリーダーをオンプレミスのシステムから Akerun というクラウド型のカードリーダーへリプレイスを行いました。サムターンに設置するタイプの Akerun Pro のイメージが強いかもしれませんが、オフィスビルの電子錠の信号線と連携できる Akerun コントローラーという製品を選定しました。

akerun.com

これによりクラウドサービス上で統合管理ができるようになっただけではなく、API を提供していることから勤怠管理システムとの連動もできるようになりました。こちらも TeamSpirit との API 連携を行うことで、オフィスに出社している際は、オフィスへの初回入室時刻が出勤打刻、最終退室時刻が退勤打刻に自動連携 されるようになりました。

corp.teamspirit.com

パスワードマネージャー全社展開

before: 1Password (高権限者のみ）
after: Keeper

Keeper のログは全て Slack App 経由でチャンネルへ自動通知

パスワードマネージャーは以前から 1Password を利用していましたが、一部の特権を持つエンジニアのみで利用されていました。一般の従業員は個別にパスワードを管理している状態であり一定のセキュリティリスクを感じており、パスワードマネージャー全社展開を検討していました。

数百人規模に展開する際は ITリテラシーの高くないメンバーにも使っていただくことになりマスターパスワードを紛失してしまった際の懸念や、組織変更への対応の運用負荷に懸念がありました。

そこで SAML による SSO、SCIM によるプロビジョニングに対応した Keeper へリプレイスを行い、全社展開を行いました。導入時の話は事例化もしていただいたので、詳細はこちらもご覧ください。

www.zunda.co.jp

PPAP 廃止

before: PPAP, ファイル共有ツール
after: mxHERO

一休はソフトバンクグループの会社でもあり、ソフトバンクグループは Emotet などのマルウェア対策のため、2022年にパスワード付き圧縮ファイル（いわゆる、PPAP：Password付きZIPファイルを送ります、Passwordを送ります、Angoka、Protocol）を廃止しました。

www.softbank.jp

一休も従来のセキュリティポリシーでは社外へ機密性の高いファイルを送付する際は PPAP で送信するルールでした。またメディア事業など外部と大容量のファイルをやりとりするチームへは個別にファイル共有ツールのアカウントを払い出す運用を行っていました。このセキュリティポリシーの改定と、代替となる手段の整備を進めました。

PPAP 代替ツールについても多くの製品がありますが、一休では経済産業省などの官公庁やエンタープライズ企業でも実績のある mxHERO を導入しました。

www.mxhero.com

cloudnative.co.jp

メールの添付ファイルを自動的にファイルストレージの安全な共有リンクに変換して送信することから、誤送信をしてしまった場合もファイルを消したり、アクセス権限を解除したりすることで、情報漏えいを防止することができます。これにより PPAP を代替できると考えました。一休ではファイルストレージとして Google ドライブを利用しているため、mxHERO と Google ドライブを組み合わせて導入することを検討しました。

Google ドライブは Box と比較すると制限が多い

しかし、Google ドライブは Google アカウントが前提となっていることが多く、Box と比較すると制限事項が多くありました。特に共有リンクに有効期限が付与できないと、共有が不要になったファイルも、設定変更を忘れると URL を知っていれば永久的にアクセスできてしまう可能性があり、解決する必要のある課題でした。 Box の導入も検討しましたが、既存のファイル共有ツールを比較するとランニングコストが大幅に上がってしまうことから断念しました。

GAS の実装で実質的に共有 URL に有効期限を設定

そこで、GAS（Google App Script）によるスクリプトで対象の共有ドライブ内のフォルダを、送信日時タイムスタンプから1週間経過したら自動削除する 、という実装を行い、実質的に共有リンクに1週間の有効期限を設定することにしました。

これにより PPAP を廃止してセキュリティ上のリスクを低下できるだけではなく、従業員はただメールにファイルを添付するだけでよくなったためユーザビリティも向上し、また、ファイル共有サービスの解約によりアカウント管理などに伴う情シスの管理工数も削減することができました。

注意点としては 25MB を超える大容量ファイルは mxHERO のルーティングより Gmail 側の Google ドライブ URL への自動変換が実施されてしまうため、mxHERO 経由で送信することができません。そのため、大容量ファイルについては手動で共有リンクを発行する運用をしています。こちらも GAS により有効期限を設定していますが、手動で発生している作業も将来的にはより自動化を進めたいと考えています。

ファイルサーバー移行・廃止

before: オンプレミス Windows Server
after: Google ドライブ（ Google Workspace Enterprise Plus ）

一休には複数のオンプレミスのファイルサーバーが存在しておりましたが、AWS EC2 上への移行を経て、2023年にGoogle ドライブへの移行が完了し、完全に廃止 しました。

さらっと書きましたが、長年運用していたファイルサーバーにはブラックボックス化したマクロの組まれた Excel が潜んでいたり、情シスでもアクセスしてはいけない機微な情報を保管したフォルダがあったりと一筋縄で行くものではなく、全社を巻き込んでの数年がかりのプロジェクトでした。ファイルサーバーの運用を行っている情シスの皆さんなら、この大変さを察していただけるのではないでしょうか・・・

なお、ファイルサーバーは複合機からスキャンしたファイルの置き場にもなっていましたが、オンプレミスのプリンタサーバー廃止と合わせてクラウドプリントに移行しており、スキャンしたファイルの置き場も Google ドライブに移行しました。

SASE 導入の見送り

before: VPN
after: 未定

一休のネットワーク構成は現時点ではいわゆる境界型セキュリティであり、社外から社内リソースへ接続する際にはリモート VPN で接続を行います。「脱・VPN」に向けて以前より　SASE（Secure Access Service Edge）の導入を検討しており、今年はいくつかの製品を PoC（Proof of Concept / 概念実証）まで実施しました。

大きな工数をかけて検証を行ってきましたが、特定の通信に対するパフォーマンス低下、開発環境への影響が PoC 期間中に解消せず見込みも立たなかったことから、残念ながら導入に至ることはできませんでした。

導入は見送りにはなりましたが、PoC を通じて貴重なノウハウを得ることができました。脱・VPN やゼロトラストネットワークの実現に、SASE 導入は必須ではなく、あくまで1つの手段であると考えています。デバイストラストなど別のアプローチからも、ユーザビリティを両立したセキュリティを目指していく予定です。

まとめ

オンプレからクラウド / SaaS 中心のモダンな IT へ

解体されるサーバールームとラック

細かなプロジェクトを上げるとキリがありませんが、ここ数年の取り組みをまとめると、オンプレミスからクラウドへの転換期であったと思います。それ故に創業当初からオンプレミスの資産がなく、フルクラウドでコーポレートIT を構築している IT企業から見ると目新しさはなく感じると思います。

一休も外から見るとモダンなIT企業に見えるかもしれませんが、1998年に創業し間もなく四半世紀を迎える会社です。多くの資産を抱えた組織であり、クラウドへの移行やゼロトラストネットワークの実現は一朝一夕で実現できるものでありません。クラウドサービス / SaaS も導入することは目的ではなく、その後の運用設計が重要となってきます。引き続きモダンなコーポレートIT環境を目指して最適化に向けて取り組んでいきます。

色々やった。これからどうするか

これまでは導入事例の取材や、ブログ、勉強会やカンファレンスで発表で外部へアウトプットできる、わかりやすい実績がありました。一方で、クラウド / SaaS も導入・移行フェーズが終わり運用に乗った今、今後はそういった機会も少なくなり、直近は地道な改善活動が多くなってくると思います。（これをチーム内では筋トレタスクと呼んでいます）

目下の課題が解消に向かいつつある中、いかに課題を見つけ出し、ボトムアップでチーム、組織、ビジネスの課題をテクロノジーで解決していくか、を考え筋トレのように日々改善を進めていきます。直近は現状の VPN の代替となる手段の検証と実装、セキュリティアラートの監視最適化、 DLP を活用した情報漏えい対策の強化、中長期的にはパスキーを活用した社内パスワードレス化に向けて取り組んでいく予定です。よい成果が得られた際はまたアウトプットをしていきます。

エンジニア採用中です !

前述の通り、一休の情シスはコンパクトに運営しているため採用をしておらず、現時点で増員の予定もありません。一方で、ソフトウェアエンジニア、SRE、データサイエンティスト、ディレクターなど多くの職種で積極的に採用をしております。

ご興味のある方は以下から Job Description をご覧ください。カジュアル面談もやっています !

www.ikyu.co.jp

TypeScript の Discriminated Union と Haskell の代数的データ型

Fri, 13 Dec 2024 15:22:24 +0900

この記事は一休.com Advent Calendar 2024 の15日目の記事です。
予定より早く書き上げてしまったので、フライングですが公開してしまいます。

TypeScript の Discriminated Union (判別可能な Union 型) を使うと、いわゆる「代数的データ型」のユースケースを模倣することができます。一休のような予約システム開発においては「ありえない状態を表現しない」方針で型を宣言するためによく利用されています。

「あり得ない状態を表現しない」という型宣言の方針については以下の URL が参考になります。

Designing with types: Making illegal states unrepresentable | F# for fun and profit

このユースケースで Discriminated Union を使う場合、それは文字どおり「型の判別」のために使われます。この場合、判別の手がかりとなる「ディスクリミネーター」はただの分岐のためのシンボル程度の役割にしか見えないでしょう。しかしこれは、本機能の部分的な見方でしかないと考えています。

Haskell など、TypeScript のように模倣ではなく、型システムに代数的データ型がネイティブに組み込まれているプログラミング言語では、代数的データ型こそが新たなデータ型とデータ構造を宣言する手段です。代数的データ構造とパターンマッチを用いて、一般的なオブジェクトだけでなく、リストや木構造などのデータ型を構築・操作することができます。こちらのメンタルモデルから見ると、代数的データ型こそが、データの構築と分解を型安全かつ表現力豊かに扱う基盤を提供するものであり、型駆動開発を支える根幹であると捉えることができます。

本記事では TypeScript の Discriminated Union による代数的データ型の模倣についてまずその基本を確認し、その後 Haskell の代数的データ型の文法をみていきます。後者をみて先のメンタルモデルを獲得したのちに前者を改めて眺めてみることにより、新たな視点で TypeScript の機能を捉えることを目指します。

TypeScript の Discriminated Union (判別可能な Union 型)

TypeScript の Discriminated Union (判別可能な Union 型) を使うと、他のプログラミング言語でいうところの代数的データ型のユースケースを模倣することができます。Discriminated Union はディスクリミネーター (もしくはタグ) と呼ばれる文字列リテラルにより Union で合併した型に含まれる型を判別できるところから「タグつき Union 型」と呼ばれることもあります。

typescriptbook.jp

Discriminated Union をうまく使うと、アプリケーション開発において「存在しない状態」ができることを回避することが出来ます。存在する状態のみを型で宣言することで「存在しない状態ができていないこと」を型チェックにより保証することができます。書籍 Domain Modeling Made Functional などでも語られている非常に有用な実装パターンであり、一休が扱う予約などの業務システム開発でも頻繁に利用しています。

少しその様子を見てみます。

典型例として、何かしらのシステムのユーザー (User) について考えます。ユーザーには会員登録済みの会員 (Member) と、会員登録はしていないゲスト会員 (Guest) の区分があるというのは、よくあるケースでしょう。会員はユーザーID、名前、メールアドレスなどの値をもつが、ゲストはそれらが確定していない。

このときユーザーID が null なデータをゲストユーザーとして扱うという実装もあり得ますが、null チェックが必要になるし「ID が null なのがゲスト」という暗黙の仕様を持ち込むことになってしまいます。null に意味は与えたくありません。

そこで以下のように、Member と Guest を定義します。

type User = Member | Guest

type Member = {
  kind: "Member"
  id: number
  name: string
  email: string
}

type Guest = {
  kind: "Guest"
}

User 型のオブジェクトがあったとき、そのオブジェクトが Member 型なのか Guest 型なのかは kind プロパティの値によって判別できます。この kindプロパティが型の判別に使われるディスクリミネーター (あるいはタグ) です。

例えば、Member か Guest かでプレゼンテーションを分けたいというときは以下のように switch 文により Union 型を分解し、それぞれの型ごとに処理を記述することができます。

function showUser(user: User): string {
  switch (user.kind) {
    case "Member":
      return `ID: ${user.id}, Name: ${user.name}, Email: ${user.email}`
    case "Guest":
      return "Guest"
    default:
      assertNever(user)
  }
}

export function assertNever(_: never): never {
  throw new Error("Unexpected value. Should have been never.")
}

assertNever は網羅性チェックのためのイディオムで、これを置くことでナローイングの結果 User 型に含まれるすべての型に対し処理を定義したかを、コンパイル時にチェックすることができます。

以下の絵は実装途中の VSCode です。Member に対する処理は記述したが Guest に対する処理はまだ記述していない段階。コンパイラがエラーを出してくれています。

網羅性チェックによるコンパイルエラー

そして kind プロパティすなわちディスクリミネーターはリテラル型になっており、補完が効きます。

ディスクリミネーターの補完が効く

このように、Union により構造の異なる複数の型を合併しつつもディスクリミネーターによってそれを分解することができ、ナローイングによって型や網羅性チェックが効くことから、代数的データ型をエミューレトできていると言われます。ディスクリミネーターに基づいた switch 文での型の分解は、さながら「パターンマッチ」のように捉えられます。

仮に Discriminated Union を使わず、ゲストユーザーを「ID が null」で表現したとすると以下のように定義することになります。

type User = {
  id: number | null
  name?: string
  email?: string
}

この場合、たとえば ID が null にも関わらず name や email が null でない、という「ありえない状態」を表現できてしまいます。

これは Record 型が AND (積) に基づいたデータ構造の宣言であり、3 つのプロパティがそれぞれ「ある・なし」の 2パターンを取り、その積で合計 8 パターンの状態を取れてしまうことに起因しています。8パターンの状態の中には、実際にはあり得ない状態が含まれます。「ある・なし」の分岐は ID に関してだけでよいのに、ほかの 2 つのプロパティまでそれに巻き込まれてしまった結果です。

Union 型は OR (和) に基づく合併なので「ID、名前、メールアドレスがある」 Member に、「プロパティがない」 Guest の状態を「足している」だけ。状態の積は取りません。よって合併しても状態が必要以上に増えません。

Making illegal states unrepresentable (ありえない状態を表現しない) というのはこういうことです。

実際のユースケース ··· 絵文字アイコンあるなしの表現

もうひとつ、我々の実際のアプリケーションでの実例の中から、簡単なものを紹介します。

我々の作ってる飲食店向け予約台帳システムには顧客管理の機能がありますが、顧客にタグ付けして分類することができます。タグは視認性向上のため絵文字が設定できるようになっています。

タグには絵文字が使える

タグを新しく作るときは絵文字を設定することができます。絵文字は設定しても、しなくても OK という仕様になっています。

絵文字は設定しても、しなくても OK

さて、このタグ用のアイコンである TagIcon のデータをどう管理するか、型を考えます。

「アイコンがない」というのを null で表現しようとしがちですが、「アイコンなし」という状態はそれはそれで存在する状態と考えることもできます。これを NoIcon という型にしてみます。「ない」を「ある」とみなすことで、状態を定義することができました。

結果、以下のように Union で表現することができるでしょう。こうして null に意味を持たせることを回避します。

type TagIcon = EmojiIcon | NoIcon

type EmojiIcon = {
  kind: "Emoji"
  symbol: string
}

type NoIcon = {
  kind: "NoIcon"
}

型を宣言したからには、この型の値を生成できるようにしましょう。コンストラクタ関数を定義します。このとき、型名と関数名を同じにするコンパニオンオブジェクトパターンを使うと良いです。

function EmojiIcon(symbol: string): EmojiIcon {
  return { kind: "Emoji", symbol }
}

function NoIcon(): NoIcon {
  return { kind: "NoIcon" }
}

少し話しが脱線しますが、EmojiIcon の symbol の文字列が確かに絵文字かどうかをチェックすることで、値の完全性をより厳密にすることができます。

function EmojiIcon(symbol: string): Result<EmojiIcon, ValidationError> {
  return symbol.match(/\p{Emoji}/gu) ? ok({ kind: "Emoji", symbol }) : err(new ValidationError('Emoji ではありません'))
}

プロダクトの実装ではそうしていますが、例外をどう扱うかなど本稿とは関係のないトピックが出てきてしまうので以降省略します。

もとい、これで型、つまりは値の構造の定義とその生成方法を定義できました。あとは先にみた User の例のように、アイコンが絵文字か・絵文字なしかで処理を切り分けたいときは kind プロパティでパターンマッチ的に分解すればよいです。

function toHTMLIcon(icon: TagIcon): string {
  switch (icon.kind) {
    case "Emoji":
      return icon.symbol
    case "NoIcon":
      return ""
    default:
      assertNever(icon)
  }
}

export function assertNever(_: never): never {
  throw new Error("Unexpected value. Should have been never.")
}

追加の仕様で絵文字だけでなく、オリジナルのアップロード画像も扱いたいとしましょう。その場合は Union に新たに ImageIcon 型を追加すればよいでしょう。

type TagIcon = EmojiIcon | NoIcon | ImageIcon // ImageIcon を新たに併合

type EmojiIcon = {
  kind: "Emoji"
  symbol: string
}

type NoIcon = {
  kind: "NoIcon"
}

// これを追加
type ImageIcon = {
  kind: "Image"
  url: string
  name: string
}

ImageIcon 型を Union に追加すると、パターンマッチしている分岐で網羅性チェックが働き、期待通り、コンパイルが通らなくなります。型に応じた処理を追加します。

function toHTMLIcon(icon: TagIcon): string {
  switch (icon.kind) {
    case "Emoji":
      return icon.symbol
    case "NoIcon":
      return ""
    case "Image": // これを追加しないとコンパイルエラー
      return `<img src="${icon.url}" alt="${icon.name}" />`
    default:
      assertNever(icon)
  }
}

実際に作った型を値として使う場合は、以下のような使い方になります。

const icon1 = EmojiIcon("🍣")
const icon2 = NoIcon()
const icon3 = ImageIcon("https://example.com/image.png", "Example Image")

console.log(toHTMLIcon(icon1)) // 🍣
console.log(toHTMLIcon(icon2)) //
console.log(toHTMLIcon(icon3)) // <img src="https://example.com/image.png" alt="Example Image" />

Discriminated Union により型を構造化し、コンパニオンオブジェクトパターンで生成を実装し、switch 文によるナローイングでパターンマッチ的に分解を実装しました。null を使わず NoIcon という状態を導入したおかげで見通しよく、静的検査を有向に活用しながら実装できました。

ディスクリミネーターは、ただの判別用のシンボル?

ここまででも十分、Discriminated Union の有用性が確認できますが、仕組みとしてはオブジェクトのプロパティに kind など適当なプロパティ名でディスクリミネーターを忍ばせた程度にも見えます。

TypeScript レイヤではナローイングによって型チェックが効くなど上手いこと機能していて座布団一枚! という感じ (?) もありますが、JavaScript のレイヤーでみるとただオブジェクトのプロパティの文字列で分岐しているだけのようにも思えて、そんなに本質的な事柄なのか? とも思えてしまいます。

Discriminated Union が表現できるものは、この程度のものと思っておけばいいのでしょうか? いいえ、という話を続けてみていこうと思います。

Haskell のデータ型宣言

代数的データ型を「模倣できる」 TypeScript ではなく、代数的データ型を型システムにネイティブで搭載しているプログラミング言語、たとえば Haskell で同じ実装がどうなるのか、見てみましょう。

以下のように実装できます。

import Text.Printf (printf)

data TagIcon = NoIcon | EmojiIcon String | ImageIcon String String

toHTMLIcon :: TagIcon -> String
toHTMLIcon NoIcon = ""
toHTMLIcon (EmojiIcon symbol) =  symbol
toHTMLIcon (ImageIcon url name) = printf "<img src=\"%s\" alt=\"%s\" >" url name

main :: IO ()
main = do
  let icon1 = NoIcon
      icon2 = EmojiIcon "🍣"
      icon3 = ImageIcon "https://exmaple.com/image.png" "Example Image"

  putStrLn $ toHTMLIcon icon1
  putStrLn $ toHTMLIcon icon2
  putStrLn $ toHTMLIcon icon3

TypeScript での実装に比較すると分量がかなり短くなっています。とは言え、コードが短いかどうかはあまり重要ではありません。より詳細に見てみましょう。

まず、TypeScript のケースとは異なりコンストラクタの明示的な実装がないことに気がつきます。

そして toHTMLIcon 関数の引数でパターンマッチをしていますが、TypeScript のディスクリミネーターに相当するのは文字列リテラル的な値ではなく NoIcon EmojiIcon ImageIcon などのシンボルです。Haskell ではこれを「データコンストラクタ」と呼びます。データコンストラクタにより TagIcon 型の値を分解することができています。

TagIcon 型の宣言にもデータコンストラクタが使われています。データコンストラクタはデータ型の形状や構造を定義するものとしても使われます。

data TagIcon = NoIcon | EmojiIcon String | ImageIcon String String

そして値を生成するときも、データコンストラクタが使われています。

  let icon1 = NoIcon
      icon2 = EmojiIcon "🍣"
      icon3 = ImageIcon "https://exmaple.com/image.png" "Example Image"

このように Haskell ではデータコンストラクタが「タグ付き Union」におけるタグ相当ですが、データコンストラクタは型に基づいた値の分解、データ型の構築、値の生成と、データ型にまつわる操作を提供するものになっています。

TypeScipt で Discriminated Union とコンパニオンオブジェクトパターン、switch 文と複数の文法を組み合わせて模倣していた機能が、Haskell ではデータコンストラクタという仕組みによって、より密結合された、統一的なかたちで実現されています。これが Haskell における代数的データ型（Algebraic Data Types, ADT）の特徴です。

そして Haskell では新しい型とデータ構造を定義する基本的な方法が、この data キーワードによる宣言です。 ···ということは、このデータコンストラクタを中心とした代数的データ型の文法でより複雑なデータ構造とその型を宣言することができることを意味します。

代数的データ型でより構造的なデータ型を扱う

永続データプログラミングと永続データ構造 - 一休.com Developers Blog で紹介した、二分木 (による永続データ配列) の実装を見てみましょう。実装詳細には立ち入らず、雰囲気だけみてもらえばよいです。

-- データ型の宣言
data Tree a = Leaf a | Node (Tree a) (Tree a)

-- 木を根から走査。パターンマッチと再帰で辿っていく
read :: Int -> Tree a -> a
read _ (Leaf x) = x
read i (Node left right)
  | i < size left = read i left
  | otherwise = read (i - size left) right

write :: Int -> a -> Tree a -> Tree a
write _ v (Leaf _) = Leaf v
write i v (Node left right)
  | i < size left = Node (write i v left) right
  | otherwise = Node left (write (i - size left) v right)

size :: Tree a -> Int
size (Leaf _) = 1
size (Node left right) = size left + size right

fromList :: [a] -> Tree a
fromList [] = error "Cannot build tree from empty list"
fromList [x] = Leaf x
fromList xs =
  let mid = length xs `div` 2
   in Node (fromList (take mid xs)) (fromList (drop mid xs))

main :: IO ()
main = do
  let arr = fromList [1 .. 8 :: Int]

  print $ read 3 arr -- 3

  let arr' = write 3 42 arr

  print $ read 3 arr' -- 42
  print $ read 3 arr  -- 3

重要なポイントとしては、コメントに書いたとおり (1) 完全二分木の木構造を data キーワードのみで宣言していること、(2) 木の中から目的のノードを探すにあたりパターンマッチで分解しながら走査していること、の 2 点が挙げられます。

データ型の宣言を改めてみてみましょう。

data Tree a = Leaf a | Node (Tree a) (Tree a)

Tree 型が再帰的に宣言されているのがわかります。再帰データ型が宣言できるため、木のようなデータ構造を代数的データ型により構築することができます。

さて、こうして木を実装する例をみると代数的データ型は、冒頭でみたような、ただの型を合併して判別する機能というものではなく、まさに「データの型と構造を構築するためのもの」だというのがわかります。

同様にリスト構造の List 型を自前で実装してみましょう。リストの走査として先頭に要素を追加する cons 関数と、リストの値それぞれを写像する mapList 関数も実装してみます。

data List a = Empty | Cons a (List a) deriving (Show)

empty :: List a
empty = Empty

cons :: a -> List a -> List a
cons = Cons

mapList :: (a -> b) -> List a -> List b
mapList _ Empty = Empty
mapList f (Cons x xs) = Cons (f x) (mapList f xs)

-- テスト出力
main :: IO ()
main = do
  let xs = cons 1 (cons 2 (cons 3 empty))

  print (mapList (* 2) xs) -- Cons 2 (Cons 4 (Cons 6 Empty))

先の二分木に同じく、data キーワードにより再帰データ型を定義してリストのデータ構造を構築しています。mapList 関数ではパターンマッチを用いてリストを走査し、リストが保持する値に写像関数を適用しています。データコンストラクタが、データ構造の構築とパターンマッチによる分解双方に利用されていることがわかります。

このように Haskell のデータ型は「値がどのように構造化され、意味づけられるか」を定義する手段です。データコンストラクタはその手段を提供し、構築と分解という双方向の操作を統一的に扱えるようにします。

この観点に立つと、データ型とデータコンストラクタの役割は次のように整理できそうです。

データ型は、プログラム内の「概念モデル」を定義する
データコンストラクタは、そのモデルの構築ルールを提供する
パターンマッチによる分解は、そのモデルを解析し操作する方法を提供する

TypeScript に同様のメンタルモデルを持ち込む

Haskell のデータ型の宣言をここまで見てから、改めて TypeScript に戻ってきましょう。代数的データ型に対するメンタルモデルが大きく更新されているはずです。

その視点で、改めて Discriminated Union よる代数的データ型の模倣を見てみましょう。「 kind プロパティは分岐目的のもの」ではなく Haskell 同様「データ型を構築、分解する手段」として捉えることができるのではないでしょうか?

さて、TypeScript の型システムも Haskell 同様、再帰データ型は宣言できます。先の Haskell で実装したリストを、TypeScript で、これまでみた Discriminated Union、コンパニオンオブジェクトパターン、switch 文によるパターンマッチのイディオムで、実装してみます。

type List<T> = Empty | Cons<T>

interface Empty {
  kind: "Empty"
}

interface Cons<T> {
  kind: "Cons"
  head: T
  tail: List<T>
}

function Empty(): Empty {
  return { kind: "Empty" }
}

function Cons<T>(head: T, tail: List<T>): Cons<T> {
  return { kind: "Cons", head, tail }
}

type map = <T, U>(f: (a: T) => U, xs: List<T>) => List<U>

const map: map = (f, xs) => {
  switch (xs.kind) {
    case "Empty":
      return Empty()
    case "Cons":
      return Cons(f(xs.head), map(f, xs.tail))
    default:
      assertNever(xs)
  }
}

export function assertNever(_: never): never {
  throw new Error()
}

const xs: List<number> = Cons(1, Cons(2, Cons(3, Empty())))
console.log(map(i => i * 2, xs))

以下が実行結果です。Discriminated Union で構造化されたリストと、各値が写像により倍化された結果が得られています。

$ deno run -A list.ts
{
  kind: "Cons",
  head: 2,
  tail: {
    kind: "Cons",
    head: 4,
    tail: { kind: "Cons", head: 6, tail: { kind: "Empty" } }
  }
}

TypeScript でも無理なく、再帰データ構造を実装できました。

比較してみると TypeScript による代数的データ型は模倣だけあって、Haskell ほど簡潔に表現することはできません。一方で、それをどのようなメンタルモデルで捉えるかは、プログラミング言語の文法には左右されないでしょうから、Haskell のそれ同様に捉えてもよいでしょう。簡潔性は及ばないものの、機能的にはさほど遜色のない実装をすることができました。もちろん、より複雑なパターンマッチを要するものまで実現できるかどうかや、ランタイム性能の影響まで考慮すると Haskell 同等とまではいきませんが。

目論見どおり、TypeScript の Discriminated Union に対する印象をアップデートすることができたでしょうか? できていることを願います 😀

実務で Discriminated Union を用いて再帰データ構造を宣言する、という機会はあまりないとは思いますが、それがただの Union で併合された型を判別できるものと小さく捉えるのではなく、本稿でみた通りデータ型の構築と分解の観点で捉えておくと視点が拡がるでしょうし、より広範囲に適用していってよいものだという確証が得られるのではないかと思います。

余談

TypeScript と Haskell を比較する記事を、過去に幾つか書きました。

TypeScript の型システムは JavaScript の上に後付けされたものということもあり、非常にプラクティカルで便利である一方、個人的には、やや散らかっていてその全体像や各機能の本質を掴みにくいと感じています。Haskell など表現に妥協の少ないプログラミング言語と比較し、相対化することでより深い理解に繋がることは多いです。

雑にまとめると Haskell やれば TypeScript 書くの上達する
— naoya (@naoya_ito) 2024年11月16日

Enjoy !

Design Doc でチームを跨いだ開発を円滑に行う

Mon, 09 Dec 2024 14:36:48 +0900

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

宿泊事業本部　ユーザー向け開発チームの原です。一休.com と Yahoo!トラベルの主にフロントエンドの開発を担当しています。

今回は、普段の開発でコードを書き始める前段階で Design Doc を作ることで、円滑な開発を進められるようになったというお話をします。

チーム構成について

まず、前提を共有するために私達が普段どのような体制で開発しているかを説明します。
私が所属している宿泊事業本部ユーザー向け開発チームは、一休.com と Yahoo!トラベルの主に toC のユーザー向けの機能開発をしています。ユーザー向け開発チームのメインのミッションはユーザー体験を向上させることであり、そういった施策の機能開発を素早くリリースできることを大事にしています。
一方、プロダクト開発においては機能開発だけではなく、プログラミング言語や依存ライブラリのアップデートや、アーキテクチャの見直しといったシステムの健全性を向上させる取り組みも重要です。
機能開発とシステム改善を同じチームが両立して行えることが理想的かもしれません。しかし、Nuxt でできたフロントエンドのアプリケーションに関しては、施策に関する機能開発はユーザー向け開発チームが、システム改善はフロントエンド改善チームという専任のチームが担当しています。
これは、変化の激しいフロントエンド開発でベストプラクティスを追い求めるには施策開発とシステム改善をする責務を分けたほうが進めやすいという判断によるものです。
実際、フロントエンド改善チームの取り組みにより、

Nuxt2 から 3 へのアップデート
Options API から Composition API への書き換え

といった Vue/Nuxt 界隈の進化に追従したり、

GraphQL の client-preset の導入
デザインシステムの推進

なども機能開発を止めずに完了しています。こういった取り組みにより、かなり開発者体験がいい環境で日々機能開発ができています。

少し古いエントリーですが、フロントエンド改善チームの取り組みは以下でご確認できます。 user-first.ikyu.co.jp

開発チームと改善チームが分かれている状態においては、うまくコミュニケーションを取らないと問題が生じます。
お互いどんな取り組みをするのか共有しないと、

開発チームの施策で触るコードと、改善チームのリファクタリングしたいコードがコンフリクトする
改善チームが行ったリアーキテクトを開発チームがちゃんと理解しないとベストプラクティスではない実装をしてしまう

といったことが起こり得ます。
特に「ベストプラクティスではない実装をしてしまう」というのは避けたい問題です。
そのため、開発チームが実装した機能は小さな修正を除いては基本的に Pull Request (以下 PR) でレビューしてもらうことになっています。
実際レビューの際に、最適な実装にたどり着くまで時間がかかってしまったということが何度かありました。

前置きが長くなりましたが、こうした別のチームにコードレビューを依頼するとき、円滑な開発を進めるために私が必要だと思っていることを紹介します。

コードレビューについて

私はレビュアーとしてコードをレビューするのは非常に労力のかかる仕事だと思っています。
よく「実装が終わって PR を出したので、もう少しで完了します」みたいなことを言ってしまいがちですが、コードレビューは実装と同等か、場合によってはそれ以上の負担が発生しうる作業だと思っています。
というのも、Approve されるとリリースできるという運用においては、レビュアーの仕事はコード書く人(レビュイー)と同等の責任が発生するためです。
いきなり数百行、数千行規模の差分が発生する修正をレビューするときには

その施策や修正の背景
実現するための最適な設計になっているか
その diff を取り込むことでどんな影響が起こり得るか

などを考える必要がありますが、それらを一から考えるのは、コードを最初から書くのと同じくらいの負担がかかるものです。
上記のような考慮はコードを書く側(レビュイー)は当然考えたうえで実装しているはずなので、レビュイーからレビュアーにうまく伝えられると負担を軽減できます。
どういった工夫でレビュアーの負担を軽減しようとしているかを紹介します。

いきなりコードを書かない

先程も述べたような差分が数百行、数千行規模の PR をいきなりレビューしてもらうのは、PR の description やコメントをいくら丁寧に書いたとしても、レビュアーの負担は大きいです。
そこで実装に入る前の段階で Design Doc を作成して、大筋の実装内容について合意を取るようにしています。
Design Doc は以下のようなアウトラインで書いています。

## このドキュメントの目的
## やりたいこと
// ここではビジネス的な視点でなぜこの施策をするのかを書きます
## 仕様
// ここでは上記のやりたいことを満たす機能要件を書きます
## 対応内容
// ここではシステム的な視点でどんな対応が必要なのかを書きます

Design Doc の目的は、実装者とレビュアーの間で大まかな実装の合意をとることです。

新規ページ作成を例にすると

URL をどう命名するか
コンポーネントの階層と、各コンポーネントをどう命名するか
サーバー(GraphQL)からデータをどのように取得するか
機能要件を満たすロジックをどう実装するか
- 既存のロジックで使えるものは何か

などを Design Doc で決定します。
特に命名は先に決めておくと実装、レビューともに楽です。

(↑ 既存のロジックを使えるというアドバイスがもらえる)

Design Doc で事前に実装方針の合意をとることで、「なぜこのような設計にしたのか」をレビュアーがレビュー時に考える必要がなくなります。また、レビューする段階で大まかな実装イメージがついているので、レビューの負担が軽減されると考えています。

Pull Request を出す際に気をつけていること

Design Doc との乖離がある場合

Design Doc で実装方針の合意をとれたら、実装をして、完了したらレビューに出します。
当然、実装する中で Design Doc で決めた通りにいかなかったり、もっといい方法が見つかったりすることもあるでしょう。
それを何も共有せずレビューに出してしまうとせっかく実装方針を決めた意義が薄れてしまいます。
Design Doc 時の決定と大きく変わる場合は、レビューを出す前に Design Doc 自体を修正して、もう一度合意を取り直すようにしています。
Pull Request の Description やコメントにその旨を書くだけで伝わるような些細な変更の場合は、レビュー段階でそれを伝えるようにします。

レビュアーの負担を最小限に

当然ですが、レビューを依頼する前に自分で見つけられる粗は見つけておくべきなので、自分がレビュアーのつもりでセルフレビューをします。
施策とは直接は関係ないリファクタリングなど、レビュアーが「これはなぜいま修正が必要なのか？」と疑問を持ちそうな箇所はコメントを残しておきます。

動作確認方法
影響する既存機能が元通り動いていることをどうテストしたのか

といった情報も記載します。
また、実装していてもっと良い書き方があるはずだが思いつかなかったような場合、どんなことを試してうまく行かなったということを残しておくとよいでしょう。

最後に

今回はチーム間を跨いだレビューで私が気をつけていることを紹介しました。
常にペアプロ・モブプロを行っていたり、チームの成熟度が高い場合は Design Doc を作成することの必要性は薄いかもしれません。
ただ、実装タイミングでどんな意思決定がなされたのかという情報は、時間が経った後から見返す際、有用になります。
また、

レビューのコストは実装と同じくらいのコストになり得る
レビュアーの負担はレビュイーの工夫次第で軽減できる

というのはどこでも共通する話だと思います。

永続データプログラミングと永続データ構造

Tue, 03 Dec 2024 09:11:33 +0900

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

昨今は我々一休のような予約システム開発においても、関数型プログラミング由来のプラクティスを取り入れる機会が増えています。

例えば、値はイミュータブルである方が扱いやすい、関数は副作用のない純粋関数にする方がテスタビリティなども含め何かと都合がよい、そういう場面では積極的に不変な値を使い、関数が冪等になるよう意識的に実装します。ドメインロジックを純粋関数として記述できると、堅牢で責務分離もしやすく、テストやデバッグもしやすいシステムになっていきます。

ところで「関数型プログラミングとはなんぞや」というのに明確な定義はないそうです。ですが突き詰めていくと、計算をなるべく「文」ではなく「式」で宣言することが一つの目標だということに気がつきます。

文と式の違いは何でしょうか?

for 文、代入文、if 文などの文は、基本的には値を返しません。値を返さないということは、文は直接結果を受け取るものではなく、命令になっていると言えます。文は計算機への命令です。

一方の式は、必ず返値を伴いますから、その主な目的は返値を得る、つまり式を評価して計算の結果を得ることだと考えることができます。

customer.archive()

と、文によって暗黙的に customer オブジェクトの内部状態を変更するのではなく

const archivedCustomer = archiveCustomer(customer)

と、引数で与えられた customer オブジェクトを直接変更することなしに、アーカイブ状態に変更されたコピーとしての archivedCustomer オブジェクトを返値として返す、これが式です。この関数は純粋関数として実装し、customer オブジェクトは不変、つまりイミュータブルなものとして扱うと良いでしょう。

式によるイミュータブルなオブジェクトの更新は TypeScript なら

export const archiveCustomer = (customer: Customer): Customer => ({
  ...customer,
  archived: true
})

と、スプレッド構文を使うことで customer オブジェクトのコピーを作りつつ、変更したいプロパティを新たな値に設定したものを返すように実装します。

このように、引数で与えたオブジェクトは直接変更せず、状態を変更した別のオブジェクトを返すような関数の連なりによって計算を定義していくのが関数型プログラミングです。

このあたりの考え方については、過去の発表スライドがありますので参考にしてください。

実際、我々の一部プロダクトのバックエンドでは TypeScript による関数型スタイルでの開発を実践しています。以下はプロダクトのコードの一例で、Customer オブジェクトに新しいメールアドレスの値を追加するための addEmail 関数です。先の実装に同じく、スプレッド構文を使って元のオブジェクトを破壊せずに、メールアドレスが追加されたオブジェクトを返します。

const addEmail =
  (address: EmailAddress) =>
  (customer: Customer): Customer => {
    const newAddress: CustomerEmail = {
      id: generateCustomerEmailId(),
      address,
    }
    return {
      ...customer,
      emails: [...customer.emails, newAddress],
    }
  }

ドメインオブジェクトの状態遷移はすべて、この式による状態遷移のモデルで実装しています。

永続データプログラミング

さて、本記事のテーマは「永続データ」です。永続データとは何でしょうか?

式を意識的に使い、かつ値をイミュータブルに扱うことを基本としてやっていくと、何気なく書いたプログラムの中に特徴的な様子が現れることになります。

以下、リスト操作のプログラムを見てみましょう。リストの先頭や末尾に値を追加したり、適当な値を削除する TypeScript のプログラムです。リストをイミュータブルに扱うべく、値の追加や削除などデータ構造の変更にはスプレッド構文を使い、非破壊的にそれを行うようにします。

// as1: 元のリスト
const as1 = [1, 2, 3, 4, 5];

// as2: 新しいリスト (先頭に 100 を追加)
const as2 = [100, ...as1];

// as3: 新しいリスト (末尾に 500 を追加)
const as3 = [...as2, 500];

// as4: 新しいリスト (値 3 を削除)
const as4 = as3.filter(x => x !== 3);

console.log("as1:", as1); // [1, 2, 3, 4, 5]
console.log("as2:", as2); // [100, 1, 2, 3, 4, 5]
console.log("as3:", as3); // [100, 1, 2, 3, 4, 5, 500]
console.log("as4:", as4); // [100, 1, 2, 4, 5, 500]

更新をしても元のリストは不変なので、as1 を参照しても更新済みの結果は得られません。リスト操作の返り値を as2 as3 as4 とその都度変数にキャプチャし、そのキャプチャした変数に対して次のリスト操作を行います。こうしてデータ構造は不変でありつつも一連の、連続したリスト操作を表現します。

データ構造を不変にした結果、リストが更新される過程の状態すべてが残りました。リストを何度か更新したにも関わらず、変更前の状態を参照することができています。as1 を参照すれば初期状態を、as2 や as3 で途中の状態を参照することができます。このように値の変更後もそれ以前の状態が残るさまを「永続データ」と呼びます。そして永続データを用いたプログラミングを「永続データプログラミング」と呼びます。

値をイミュータブルに扱うと必然的にそれは永続データになるので、永続データプログラミングはそれ自体、何か特別なテクニックというわけではありません。一方で、値が永続データであることをはっきりさせたい文脈上では「永続データプログラミング」という言葉でプログラミングスタイルを表現すると、その意図が明確になることも多いでしょう。

以下の山本和彦さんの記事では、関数型プログラミングすなわち「永続データプログラミング」であり、永続データを駆使して問題を解くことこそが関数型プログラミングだ、と述べられています。

筆者の関数プログラミングの定義、すなわちこの特集での定義は、「⁠永続データプログラミング」です。永続データとは、破壊できないデータ、つまり再代入できないデータのことです。そして、永続データを駆使して問題を解くのが永続データプログラミングです。

また関数型言語とは、永続データプログラミングを奨励し支援している言語のことです。関数型言語では、再代入の機能がないか、再代入の使用は限定されています。筆者の定義はかなり厳しいほうだと言えます。

第1章　関数プログラミングは難しくない！―初めて学ぶ人にも、挫折した人にもきちんとわかる | gihyo.jp

命令型プログラミングにおいては変更にあたり値を直接破壊的に変更します。変更前のデータ構造の状態を参照することはできません。リストの破壊的変更は、基本的に (式ではなく) 文によって行われるでしょう。文を主体としたプログラミング··· 命令型プログラミングでは、永続ではないデータ、つまり短命データを基本にしていると言えます。一方、式によってプログラムを構成する関数型プログラミングでは、関数の冪等性を確保すべくイミュータブルに値を扱うことになるので、永続データが基本になります。

イミュータブルな値によるプログラミングをする際、そこにある値は不変であるだけでなく、同時に永続データなのだということを認識できると、プログラミングスタイルに対するよりよいメンタルモデルが構築できると思います。

Haskell と永続データプログラミング

やや唐突ですが、イミュータブルといえば純粋関数型言語の Haskell です。先の TypeScript によるリスト操作のプログラムを、Haskell で実装してみます。

main :: IO ()
main = do
  let as1 = [1, 2, 3, 4, 5]
      as2 = 100 : as1
      as3 = as2 ++ [500]
      as4 = delete 3 as3

  print as1 -- [1,2,3,4,5] 
  print as2 -- [100,1,2,3,4,5]
  print as3 -- [100,1,2,3,4,5,500]
  print as4 -- [100,1,2,4,5,500]

Haskell はリストはもちろん、基本的に値がそもそもがイミュータブルです。リスト操作の API はすべて非破壊的になるよう実装されているので、変更にあたり TypeScript のようにスプレッド構文でデータを明示的にコピーしたりする必要はありません。裏を返せば、変更は永続データ的に表現せざるを得ず、式によってプログラムを構成することが必須となります。結果、Haskell による実装は自然と永続データプログラミングになります。

関数型プログラミングすなわち永続データプログラミングだ、というのは、この必然性から来ています。

永続データの特性を利用した問題解決

永続データプログラミングは不変な値を使うことですから、それを実践することで記事冒頭で挙げたようなプログラムの堅牢性など様々なメリットを享受できるわけですが、「変更前の過去の状態を参照できる」という、値が不変であるというよりは、まさに「永続」データの特性が部分が活きるケースがあります。

わかりやすい題材として、競技プログラミングの問題を例に挙げます。

atcoder.jp

問題文を読むのが面倒な方のために、これがどんな問題か簡単に解説します。入力の指示に従ってリストを更新しつつ、任意のタイミングでそのリストの現在の状態を保存する。また任意のタイミングで復元できるようするという、データ構造の保存と復元を題材にした問題です。

ADD 3
SAVE 1
ADD 4
SAVE 2
LOAD 1
DELETE
DELETE
LOAD 2
SAVE 1
LOAD 3
LOAD 1

こういうクエリが入力として与えられる。

空のリストが最初にある
クエリを上から順番に解釈して、ADD 3 のときはリスト末尾にを追加する
DELETE なら末尾の値を削除
SAVE 1 のときは、今使っているリストを ID 番号の領域に保存、LOAD 1 なら ID 番号の領域からリストを復元する
クエリのたび、その時点でのリストの末尾の要素を出力する

という問題になっています。

この問題を永続データなしで解こうとすると、リストを更新しても以前の状況に戻れるような木のデータ構造を自分で構築する必要がありなかなか面倒です。一方、永続データを前提にすると、何の苦労もなく解けてしまいます。

以下は Haskell で実装した例です。やっていることは、クエリの内容に合わせてリストに値を追加・削除、保存と復元のときは辞書 (IntMap) に、その時点のリストを格納しているだけです。問題文の通りにシミュレーションしているだけ、とも言えます。

main :: IO ()
main = do
  q <- readLn @Int
  qs <- map words <$> replicateM q getLine

  let qs' = [if null args then (command, -1) else (command, stringToInt (head args)) | command : args <- qs]

  let res = scanl' f ([], IM.empty) qs'
        where
          f (xs, s) query = case query of
            ("ADD", x) -> (x : xs, s) -- リストに値を追加
            ("DELETE", _) -> (drop1 xs, s) -- リストから値を削除
            ("SAVE", y) -> (xs, IM.insert y xs s) -- 辞書にこの時点のリストを保存
            ("LOAD", z) -> (IM.findWithDefault [] z s, s) -- 辞書から保存したリストを復元
            _ -> error "!?"

  printList [headDef (-1) xs | (xs, _) <- tail res] -- 各クエリのタイミングでのリストの先頭要素を得て、出力

Haskell のリストは永続データですから、値を変更しても変更以前の値が残ります。その値が暗黙的に他で書き換えられる事はありません。よって素直にリストを辞書に保存しておけばよいのです。一方、命令型プログラミングにおいてリストがミュータブルな場合は、ある時点の参照を辞書に保存したとしても、どこかで書き換えが発生すると、辞書に保存された参照の先のデータが書き換わるためうまくいきません。

永続データ構造

さて、ここからが本題です。TypeScript でリストを永続データとして扱うにあたり、スプレッド構文によるコピーを使いました。

// as2: 新しいリスト (先頭に 100 を追加)
const as2 = [100, ...as1];

// as3: 新しいリスト (末尾に 500 を追加)
const as3 = [...as2, 500];

すでにお気づきの方も多いと思いますが、値の更新にあたり、リスト全体のコピーが走ってしまっています。一つ値を追加、削除、更新するだけでもリストの要素件に対し件のコピーが走る。つまりの計算量が必要になってしまいます。永続データプログラミングは良いものですが、ナイーブに実装するとデータコピーによる計算量の増大を招きがちです。

Haskell など、イミュータブルが前提のプログラミング言語はこの問題をどうしているのでしょうか?

結論、データ構造全体をコピーするのではなく「変更されるノードとそのノードへ直接的・間接的に参照を持つノードだけをコピーする」ことによって計算量を抑え、不変でありながらも効率的なデータ更新が可能になるようにリストその他のデータ構造が実装されています。つまり同じ「リスト」でも、命令型プログラミングのそれと、不変なデータ構造のそれは実装自体が異なるのです。抽象は同じ「リスト」でも具体が違うと言えるでしょう。

変更あったところだけをコピーし、それ以外は元の値と共有を行うこのデータ構造の実装手法は Structural Sharing と呼ばれることもあります。Structural Sharing により不変でありながら効率的に更新が可能な永続データのデータ構造を「永続データ構造」と呼びます。

永続データ構造については、以下の書籍にその実装方法含め詳しく記載されています。

純粋関数型データ構造 - アスキードワンゴ

もとい、例えば Haskell のリストは先頭の値を操作する場合はです。先頭要素だけがコピーされていて、それ以降の要素が更新前後の二つのリストで共有されるからです。

同じく、先の実装でも利用した Data.IntMap という辞書、こちらも永続データ構造ですが、内部的にはパトリシア木で実装されていて、値の挿入やキーの探索は、整数のビット長程度の計算量 ··· をデータサイズ、をビット長としたときに収まります。

Haskell で利用する標準的なデータ構造 ··· List、Map、Set、Sequence、Heap は、すべてイミュータブルでありながら、値の探索や変更がや程度の計算量で行える永続データ構造になっています。(なお、誤解の無いよう補足すると、ミュータブルなデータ構造もあります。ミュータブルなデータ構造は手続き的プログラミングで変更することになります)

永続データ構造を利用することによって、永続データプログラミング時にもパフォーマンスをそれほど犠牲にせず、大量のデータを扱うことが可能になります。裏を返せば、永続データプログラミングをより広範囲に実践していくには、永続データ構造が必要不可欠であるとも言えます。関数型プログラミングは値が不変であることをよしとしますが、そのためには永続データ構造が必要かつ重要なパーツなのです。

TypeScript その他のプログラミング言語で永続データプログラミングを実践するとき、純粋関数型言語とは異なり、素の状態では永続データ構造の支援がないということは念頭に置いておくべきでしょう。

TypeScript や Python で永続データ構造を利用するには?

TypeScript の Array、Map、Set などの標準的なデータ構造はすべて命令型データ構造、つまりミュータブルです。命令型のプログラミング言語においては、どの言語も同様でしょう。一方、プログラミング言語によっては List、Map、Set などの永続データ構造バージョンを提供するサードパーティライブラリがあります。

Immutable.js (JavaScript / TypeScript)
pyrsistent · PyPI (Python)

これらのライブラリを導入することで、TypeScript や Python で永続データ構造を利用することができます。しかし、実際のところこれらの永続データ構造の実装が、広く普及しているようには思えません。

永続データ構造は業務システム開発にも必須か?

結論からいうと、命令型のプログラミング言語で業務システム開発をする場合には、必須ではないでしょう。

永続データプログラミング自体は良い作法ですが、業務システムにおいては、大量データのナイーブなコピーが走るような実装をする場面が少ないから、というのが理由だと思います。

Haskell のような関数型言語を使っているのであれば、永続データ構造は標準的に提供されていて、そもそも必須かどうかすら気にする必要がありません。永続データ構造のメカニズムを全く知らなくても、自然にそれを使ったプログラムを書くように導かれます。

命令型言語を使いつつも、永続データプログラミングを実践するケースではどうでしょうか? 速度が必要な多くの場面では、いったん永続データを諦め、単に命令型データ構造を利用すれば事足りるので、わざわざ永続データ構造を持ち出す必要はないでしょう。ドメインオブジェクトの変更をイミュータブルに表現するためコピーする場合も、せいぜい 10 か 20 程度のプロパティをコピーする程度で、コピー 1回にあたり数万件といったオーダーのコピーが発生するようなことは希でしょう。

よって業務システム開発において Immutable.js や pyrsistent のようなサードパーティライブラリを積極的に使いたい場面は、先に解いた競技プログラミング問題のように、永続データ構造の永続である特性そのものが機能要件として必要になるケースに限られるのではないか? と思います。

Immutable.js の開発が停滞しているのは、フロントエンドで永続データ構造の需要が乏しいからでしょう。このようなデータ構造自体は非常に重要な概念で、多くのプログラミング言語に存在します。我々フロントエンドエンジニアが依存するブラウザの内部でも、効率的なデータ処理のために多用されているはずです。しかし、フロントエンドエンジニアがイミュータブルに求めているのは処理速度ではなく設計の改善です。だからこそ、Immutable.js に代わって Immer が隆盛したのでしょう。

Immutable.jsとImmer、ちゃんと使い分けていますか？

一方、純粋関数型言語で競技プログラミングのような大きなデータを扱うプログラミングを行う場合、永続データ構造は必須ですし、また永続データ構造を利用していることを意識することでよりよい実装が可能になると思っています。個人的にはこの「永続データ構造によって、より良い実装が可能になる」点こそが本質的だと思っています。

先の競技プログラミングの実装を改めてみてみます。

main :: IO ()
main = do
  q <- readLn @Int
  qs <- map words <$> replicateM q getLine

  let qs' = [if null args then (command, -1) else (command, stringToInt (head args)) | command : args <- qs]

  let res = scanl' f ([], IM.empty) qs'
        where
          f (xs, s) query = case query of
            ("ADD", x) -> (x : xs, s) -- リストに値を追加
            ("DELETE", _) -> (drop1 xs, s) -- リストから値を削除
            ("SAVE", y) -> (xs, IM.insert y xs s) -- 辞書にこの時点のリストを保存
            ("LOAD", z) -> (IM.findWithDefault [] z s, s) -- 辞書から保存したリストを復元
            _ -> error "!?"

  printList [headDef (-1) xs | (xs, _) <- tail res] -- 各クエリのタイミングでのリストの先頭要素を得て、出力 (※)

このプログラムでは、クエリのたびに、その時点でのリストの値を出力する必要があります。が、上記のプログラムでは (クエリのたびに都度出力を得ているのではなく) クエリを全部処理し終えてから、最終的な出力、つまりプレゼンテーションを組み立てています。(※) の実装です。

データ構造が命令型データ構造の場合、こうはいきません。ある時点のデータ構造の状態はその時点にしか参照できないため、プレゼンテーションをそのタイミングで得る必要があります。

一方、永続データ構造の場合、各々時点のデータ構造の状態を後からでも参照できますし、メモリ上にデータ構造を保持しておいても Structural Sharing によりそれが肥大化することもありません。このプログラムのように、中核になる計算 ··· つまりドメインロジックをすべて処理し終えてから、改めてプレゼンテーションに変換することが可能です。プレゼンテーション・ドメイン分離の観点において、永続データ構造が重要な役割を果たしています。この考え方は、実装スタイルに大きな影響を与えます。

この点に関する詳細は、競技プログラミング文脈を絡めて話す必要もあり長くなりそうなので改めて別の記事にしようと思います。

さて、業務システム開発には必須とは言えないと私見は述べましたが、命令型プログラミング言語でも値を不変に扱うとき、このナイーブなコピーが走る問題を意識できているかどうかは重要でしょう。多くの関数型言語においてはこの課題を永続データ構造によって解消しているということは、知っておいて損はありません。

永続データ構造の実装例

「永続データ構造」というと字面から何かすごそうなものを思い浮かべるかもしれませんが、その実装方法を知っておくともう少し身近なものに感じられると思います。永続データ構造の中でも比較的実装が簡単な、永続スタックと永続配列の実装を紹介して終わりにしたいと思います。実装の詳細については解説しませんが、雰囲気だけみてもらって「何か特別なことをしなくても普通に実装できるんだな」という雰囲気を掴んでもらえたらと思います。

永続スタック

Haskell で実装した永続スタックの一例です。再帰データ型でリストのようなデータ構造を宣言し、API として head tail (++) など基本的な関数を実装します。

代数的データ型でリンクリスト構造を宣言し、先頭要素への参照を返すように実装します。先頭要素を参照したいとき (head) は、先頭要素への参照からそれを取り出し値を得るだけ。先頭以外の要素を得る、つまり分解したいとき (tail) は次の要素への参照を返す。これだけで永続スタックが実装できます。

二つのスタックを結合する ((++)) ときはどうしてもかかってしまいますが、その際も双方のリストをコピーするのではなく古いリストの一方だけをコピーし、のこりの一つは新しいリストで共有されるように実装しています。

import Prelude hiding ((++))

data Stack a = Nil | Cons a (Stack a) deriving (Show, Eq)

empty :: Stack a
empty = Nil

isEmpty :: Stack a -> Bool
isEmpty Nil = True
isEmpty _ = False

cons :: a -> Stack a -> Stack a
cons = Cons

head :: Stack a -> a
head Nil = error "EMPTY"
head (Cons x _) = x

tail :: Stack a -> Stack a
tail Nil = error "EMPTY"
tail (Cons _ xs) = xs

(++) :: Stack a -> Stack a -> Stack a
Nil ++ ys = ys
Cons x xs ++ ys = Cons x (xs ++ ys)

main :: IO ()
main = do
  let s0 :: Stack Int
      s0 = empty
      s1 = cons (1 :: Int) s0
      s2 = cons (2 :: Int) s1
      s3 = cons (3 :: Int) s1

      s4 = s1 ++ s3

  print s0
  print s1
  print s2
  print s3
  print s4

出力結果は以下です。

Nil
Cons_1_Nil
Cons_2_(Cons_1_Nil)
Cons_3_(Cons_1_Nil)
Cons_1_(Cons_3_(Cons_1_Nil))

永続配列

永続配列は、配列といっても命令型の配列のように連続した領域を索引で参照できるようにするモデルではなく、完全二分木で表現します。

値は葉に持たせて、インデックスによる参照時には根から二分木を辿って目的の葉を特定します。そのため、参照時の計算量はではなくとなります。

二分木による配列の表現

更新時には「変更されるノードとそのノードへ直接的・間接的に参照を持つノードだけをコピーする」という考えに従い、根から更新対象の葉までを辿る経路上のノードをコピーする経路コピーという手法を使います。経路をコピーするといっても、木の高さ程度ですから更新も結局になります。

経路コピーについては Path Copying による永続データ構造 - Speaker Deck のスライドがわかりやすいと思います。

{-# LANGUAGE DeriveFunctor #-}

import Prelude hiding (read)

data Tree a = Leaf a | Node (Tree a) (Tree a) deriving (Show, Functor)

fromList :: [a] -> Tree a
fromList [] = error "Cannot build tree from empty list"
fromList [x] = Leaf x
fromList xs =
  let mid = length xs `div` 2
   in Node (fromList (take mid xs)) (fromList (drop mid xs))

read :: Int -> Tree a -> a
read _ (Leaf x) = x
read i (Node left right)
  | i < size left = read i left
  | otherwise = read (i - size left) right

write :: Int -> a -> Tree a -> Tree a
write _ v (Leaf _) = Leaf v
write i v (Node left right)
  | i < size left = Node (write i v left) right
  | otherwise = Node left (write (i - size left) v right)

size :: Tree a -> Int
size (Leaf _) = 1
size (Node left right) = size left + size right

main :: IO ()
main = do
  let arr = fromList [1 .. 8 :: Int]
  print arr

  print $ read 3 arr

  let arr' = write 3 42 arr

  print $ read 3 arr'
  print $ read 3 arr

永続スタック、永続配列の実装を簡単ですが紹介しました。

何か特殊な技法を使うというものではなくスタック、配列などの抽象が要求する操作を考え、その抽象に適した具体的で効率的なデータ構造を用意する、というのが永続データ構造の実装です。

まとめ

永続データプログラミングと永続データ構造について解説しました。

不変な値を使い、式でプログラムを宣言すると永続データプログラミングになる
永続データプログラミングでは、変更前の値を破壊しない。変更後も変更前の値を参照できるという特徴を持つ
関数型プログラミングすなわち永続データプログラミングである、とも考えられる
永続データプログラミングにおけるデータコピーを最小限に留め効率的な変更を可能にする不変データ構造が「永続データ構造」
業務システム開発において、永続データ構造は必須とは言えない。パフォーマンスが必要な場面で、永続データ構造を持ち出す以外の解決方法がある
大量データを扱うことが基本で、かつ値を不変に扱いたいなら永続データ構造は必須
一般のシステム開発においても機能要件として「永続」データが必要になるなら、Immutable.js とかを利用しても良いかも
関数型プログラミングが、不変でありながらも値の変更をどのように実現しているかは永続データ構造に着目するとよく理解できる

というお話でした。

途中少し触れた、永続データ構造を前提にした計算の分離については別途あらためて記事にしたいと思います。

追記

以下に記事にしました。

zenn.dev

一休.com Developers Blogの執筆環境2024

Mon, 02 Dec 2024 16:53:33 +0900

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

kymmtです。

当ブログ「一休.com Developers Blog」は、以前からはてなブログで運用しています。そして、今年からは執筆環境を少し改善しました。具体的には、GitHubを用いて記事の作成や公開ができるようにしました。

この記事では、当ブログの執筆環境をどのように改善し、ふだん運用しているかについて紹介します。

HatenaBlog Workflows Boilerplateの導入

従来は、執筆者が記事をローカルやブログ管理画面のエディタ上で書き、なんらかの方法でレビューを受け、公開するというフローでした。このフローで一番ネックになりやすいのはレビューで、Slack上でレビューが展開されがちになり、議論を追いづらいという問題がありました。

そこで、執筆環境の改善のために、はてなさんがβ版として公開しているHatenaBlog Workflows Boilerplateを利用して、記事執筆用のリポジトリを整備しました。

github.com

これは、GitHub Actionsのはてなブログ用reusable workflow集であるhatenablog-workflowsを用いた、はてなブログ記事執筆用のリポジトリテンプレートです。

リポジトリを整備した結果、GitHub上ではてなブログの記事をMarkdownファイルとして管理したり、GitHub Actionsで原稿の同期や公開などの操作を実行できるようになりました。

現在は、記事執筆のフローは次のようになっています。

下書き用pull request (PR)作成actionを実行
手元にブランチを持ってきて執筆
ときどきコミットをpushしてはてなブログに同期し、プレビュー画面で確認
PR上でレビュー
公開できる状態にしてPRをmainにマージし、自動で記事公開

普段開発に携わっているメンバーはGitHubに慣れています。そのようなメンバーがPR上でブログ記事執筆やレビューができるようにすることでの執筆体験向上を図りました。とくに、レビューをPRで実施することで、あるコメントがどの文章に対するものなのか分かりやすくなる点は便利だと感じています。社内のメンバーからも、

ブログが GitHub で管理できるようになったのは、レビューの観点でホントありがたい

という感想をもらっています。

記事のネタ管理

記事のネタはGitHubのissueとして管理しています。どの執筆PRでネタが記事になったのかや、ネタに関する細かいメモも記録しています。情報の一元化の観点では、スプレッドシートなどで別管理するよりは好ましいと思います。

校正

校正はtextlintを利用しています。pull_requestトリガーでtextlintによる校正を実行するGitHub Actionsのワークフローを設定しています。ワークフローは.github/workflows/textlint.yamlに次のようなものを置いています。

name: textlint

on:
  pull_request:
    paths:
      - "draft_entries/*.md"
      - "entries/*.md"

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
      - run: npm ci
      - name: Add textlint problem matcher
        run: echo "::add-matcher::.github/textlint-unix.json"
      - name: Lint files added/modified in the PR
        run: |
          git diff --diff-filter=AM origin/main...HEAD --name-only -- '*.md' | xargs npx textlint --format unix

.github/textlint-unix.jsonは次のとおりです。

{
  "problemMatcher": [
    {
      "owner": "textlint-unix",
      "pattern": [
        {
          "regexp": "^(.+):(\\d+):(\\d+):\\s(.*)$",
          "file": 1,
          "line": 2,
          "column": 3,
          "message": 4
        }
      ]
    }
  ]
}

これでPR画面上にtextlintによる校正結果が表示されるようになります。

textlintで現在使っているルールは次のとおり最低限のものです。技術記事もテクニカルライティングの一種であるとは思いますが、Web上で気軽に読んでもらう類のものでもあるため、文体にある程度個性が出るのは問題ないと考え、そこまで厳しいルールにはしていません。

ja-no-abusage: 日本語の誤用チェック
ja-unnatural-alphabet: 不自然なアルファベット検知
preset-japanese: 日本語文書向けのプリセット
- 読点の数、てにをは、文の長さなど

レビュアー

記事ファイルが配置されるディレクトリのコードオーナーに技術広報担当者を設定して、担当者のレビューが通れば記事を公開してOK、というフローにしました。現在は2名の担当者で回しています。

HatenaBlog Workflows Boilerplateを利用しているという前提で、.github/CODEOWNERSを次のように設定しています。ここで@orgにはGitHub orgの名前が、teamには技術広報担当者からなるteamの名前が入ります。

/draft_entries/ @org/team
/entries/ @org/team

この設定に加えて、リポジトリのbranch protection rulesとしてmainブランチでコードオーナーのレビューを必須にすることで、必ず技術広報担当者が目を通せる仕組みとしています。

とはいえ、各記事の内容については執筆者のチームメンバーのほうが深く理解していることも多いです。ですので、内容の正確性という観点ではチームメンバーどうしでレビューしてもらい、技術広報担当者は会社の名前で社外に公開する記事としてふさわしいかという観点でのチェックをすることが多いです。

余談: HatenaBlog Workflows Boilerplateへのフィーチャーリクエスト

上記のBoilerplateを用いてリポジトリを運用しているうちに、ほしい機能が1つ生まれたので、該当リポジトリのissueを通じて機能をリクエストしました。

github.com

具体的には、下書きPRを作成したとき、そのPRはdraft状態になっていてほしいというものです。GitHubの仕様上、PRがdraftからready for reviewになるとき、コードオーナーへレビュー依頼の通知が送られるようになっています。ですので、記事を書き始めるときのPRとしてはdraftとするのが自然と考えた、というものです。

結果、機能として無事取り込んでいただけました。ありがとうございました¹。

staff.hatenablog.com

おわりに

この記事では2024年の当ブログの執筆環境について紹介しました。GitHubを起点とする執筆環境や自動化を取り入れることで、執筆体験を向上できました。この記事も紹介した仕組みで書きました。引き続き、このブログで一休での開発における興味深いトピックをお届けしていければと思います！

機能リリース後に、draft機能がGitHubの有料プランの機能であることに伴うフォローアップもしていただきました。ありがとうございました↩

一休はRust.Tokyo 2024にゴールドスポンサーとして協賛します

Fri, 29 Nov 2024 12:17:30 +0900

kymmtです。

11/30に開催されるRust.Tokyo 2024に一休はゴールドスポンサーとして協賛します。

rust.tokyo

一休でのRustの活用

一休では一休.comレストランにおいてRustの活用を進めています。昨年に当ブログで活用の様子を紹介した際は、当時開発が進んでいたレストラン予約サービスWeb UIのバックエンドにおけるユースケースだけに触れていました。

user-first.ikyu.co.jp

それから1年弱経過した現在では、Rust活用の場はさらに広がっており、Rustを書いているメンバーも増えてきています。

Rust.Tokyoのゴールドスポンサー

2024年はRustでWebサービスを開発するのがますます現実的な選択肢として挙がるようになった年だったのではないかと思います。たとえば、RustでWebアプリケーションを開発するための本が複数発売されるなど¹、学習リソースは着実に揃ってきています。このような環境のなかで、一休もRust採用企業として活用事例の共有などを通じてコミュニティを活性化させることが重要だと考えています。

以上のような状況に基づいて、一休はこのたびRust.Tokyo 2024にゴールドスポンサーとして協賛させていただくことになりました。当日は会場で

スポンサーセッション登壇
ブースの出展

をやります。

スポンサーセッションでは、トラックAで15:25から「総会員数1,500万人のレストランWeb予約サービスにおけるRustの活用」と題してkymmtが発表します。2024年現在の一休.comレストランにおけるRust活用の様子のスナップショットとして、システムの設計や技術的なトピックについて紹介する予定です。

また、会場ではブースを出展する予定です。技術広報チームを中心に、一休.comレストランのエンジニアとしてkymmtが、ほかにも宿泊予約サービスの一休.comのエンジニアとEMがブースに参加する予定です。一休のサービス開発の様子について興味があるかたはぜひお越しください。

おわりに

11/30に一休はRust.Tokyo 2024にゴールドスポンサーとして協賛します。参加者のかたは当日会場でお会いしましょう！

https://bookclub.kodansha.co.jp/product?item=0000398182 や https://www.shoeisha.co.jp/book/detail/9784798186016 など↩

TSKaigi Kansai 2024とJSConf JP 2024に一休のエンジニアが登壇します

Fri, 15 Nov 2024 11:36:58 +0900

kymmtです。

今月は

11月16日に京都で開催されるTSKaigi Kansai 2024
11月23日に東京で開催されるJSConf JP 2024

と、JavaScript/TypeScriptに関するカンファレンスが2つ開催されます。今年は、一休.comレストランのフロントエンドアーキテクトを務めるエンジニア恩田 (@takashi_onda)がこれらのカンファレンス両方に登壇します。

1週違いで開催されるそれぞれのカンファレンスでは、一休.comレストランのフロントエンド開発をきっかけとする内容のトークテーマを携えて登壇します。この記事では、現在絶賛発表準備中の本人からのコメントも交えつつ、発表内容について紹介します！

TSKaigi Kansai 2024: 構造的型付けとserialize境界

kansai.tskaigi.org

TSKaigi Kansai 2024は、TypeScriptをテーマとして2024年5月に東京で開催されたTSKaigi 2024から派生した地域型カンファレンスです。

本カンファレンスでは、16:00-16:30に「カミナシ堂」会場で「構造的型付けとserialize境界」というタイトルで恩田が発表します。

以下、恩田からのコメントです。

京都在住なので、地元でお話しできるのが楽しみです。一休では僕のように関西やその他の地域に在住しているエンジニアも複数います。発表を聞いていただき興味を持たれた方は、お気軽にお声がけください。

JSConf JP 2024: Reactへの依存を最小にするフロントエンドの設計

jsconf.jp

JSConf JP 2024は、Japan Node.js Association様により運営されている、JavaScriptをテーマとする大規模カンファレンスです。

本カンファレンスでは、11:10-11:40にトラックBで「Reactへの依存を最小にするフロントエンドの設計」というタイトルで発表します。この発表は、本ブログで以前公開した記事「React / Remixへの依存を最小にするフロントエンド設計」をもとに、今回あらためてJSConfでお話しするものです。

user-first.ikyu.co.jp

以下、恩田からのコメントです。

一休レストランのフロントエンド開発では、疎結合な設計を心がけていて、ほとんどのロジックは Vanilla JS だけで完結しています。そのような書き方を可能とする、バックエンド開発で培われた知見をフロントエンドに適用する手法についてお話ししたいと思います。

おわりに

この記事では、TSKaigi Kansai 2024とJSConf JP 2024でのエンジニア恩田 (@takashi_onda)の発表内容について紹介しました。

参加者の方は、それぞれの会場でぜひ発表を聞きに来ていただければと思います！

Vue Fes Japan 2024に登壇 & ランチスポンサーをしました

Tue, 29 Oct 2024 16:31:02 +0900

CTO室プラットフォーム開発チームのいがにんこと山口(@igayamaguchi)です。

先日、Vue Fes Japan 2024が開催され、一休は登壇とスポンサーをしました。その紹介をします。

Vue Fes Japan 2024が開催

10月19日(土)に日本最大級の Vue.js カンファレンス、Vue Fes Japan 2024 が開催されました。一休は当カンファレンスでプロポーザル採択による発表と、ランチスポンサーとしてランチセッションでの発表を行いました。この記事ではその発表の概要を紹介します。

一休で行った発表は2つです。

Vue.js、Nuxtの機能を使い、大量のコピペコードをリファクタリングする
Nuxtベースの「WXT」でChrome拡張を作成する

Vue.js、Nuxtの機能を使い、大量のコピペコードをリファクタリングする

1つ目の発表は自分がプロポーザルを送り採択された発表です。一休.com、Yahoo!トラベルで発生したコピペ問題の原因と解決策の話です。

speakerdeck.com

一休.com、Yahoo!トラベルでは大量のコピペコードが発生していました。それにより何かを変更するときに作業がN倍になってしまい、開発スピードが落ちていました。今回の発表ではこの問題の原因を紐解き解決していった話をしました。コピペ問題といっても原因は様々です。ワークフローに問題があったり、コピペが発生せざるを得ない技術的背景があったり。それぞれに対応しています。内容をざっくり抜き出すと、以下のようになります。

開発ワークフローに問題がありUIのコピペが横行していたので、ワークフローの見直し、UIコンポーネントの作成
デザイン差分を小さくしてコードの統一
Option APIでロジックが共通化できていなかったので、Composition APIを導入して共通化、さらには責務わけのためのコンポーネント分割

詳細は発表資料をご覧ください。

Nuxtベースの「WXT」でChrome拡張を作成する

2つ目は新規プロダクト開発部の星野によるランチセッションでの発表です。「WXT」というOSSを使用し、Chrome拡張を作成してみた話です。

speakerdeck.com

何かを便利にしようとChrome拡張を使おうと思った時、自分の求めるChrome拡張が存在しなかったり、信用できない開発者のChrome拡張を使用したくないということがあります。この問題を解決するために「WXT」というOSSを使用してChrome拡張を開発した話をしました。

WXTはNuxtベースで開発できる拡張機能開発フレームワークです。Chrome拡張を開発するにはいくつか設定ファイルを作成したりChrome拡張特有の作業が必要でとても面倒なのですが、WXTを使用することでこの作業がとても簡単になります。しかもNuxtを使用している人には分かりやすいインターフェースになっており、Vue.js/Nuxtを触っている開発者にはとても開発しやすいものになっています。さらにはVue.jsだけでなくReactなど他のUIフレームワークを使用して開発することもできます。

自分でChrome拡張を作りたいという方はこの発表を参考にWXTを試してみてください。

おわりに

Vue Fes Japan 2024での一休の発表を紹介させていただきました。

Vue Fesですが、発表者、かつ一視聴者として参加してみて、すごく熱があるカンファレンスでした。参加者も多く、Vue.jsだけでなくViteの話も聞けて、さらにRolldownやoxcの話を開発者から聞けるという場は国内ではなかなかないと思います。そのような場で発表できたこと、スポンサーをできたことはとてもありがたかったです。

2025年も開催されるとのことなのでまた楽しみです。

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

hrmos.co

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

www.ikyu.co.jp

「一休×AEON 事業会社のサービスを支える基盤開発トーク」を開催しました

Fri, 04 Oct 2024 12:10:28 +0900

はじめに

kymmtです。

先日2024年9月18日に、「事業会社のサービスを支える基盤開発トーク」と題してイオンスマートテクノロジー（以下AST）さんと合同で技術イベントを実施しました。

ikyu.connpass.com

イベントでは、各会社の事業を支える基盤プロダクトの開発や運用における苦労や工夫について登壇者の方々にお話しいただきました。

この記事では、このイベントの様子や発表の内容を紹介します。なお、X（旧Twitter）でも#ikyu_aeonというハッシュタグで当日の様子がご覧になれます。

会場

会場は、一休のオフィスも入っている東京ガーデンテラス紀尾井町内のLODGEでした。

当日は、一休／ASTのメンバーも合わせて計30人程度の方にご来場いただきました。また、イベント開始前に、ASTのもりはやさんからトップバリュ製品やイオンで販売中のお菓子を来場者向けに提供していただきました。

#ikyu_aeon
わいわい！！トップバリューとイオンで買ってきたお菓子をデプロイしました！！ pic.twitter.com/p3qZmhdD2K
— もりはや (@morihaya55) September 18, 2024

発表

『歴史あるプロダクトにマイクロサービスを導入するプロセス』

1つ目の発表は、一休の菊地さんによる『歴史あるプロダクトにマイクロサービスを導入するプロセス』でした。

一休のプロダクトを横断して利用されるマイクロサービス群（社内では一休プラットフォームと呼んでいます）を開発するチームでは、個別のプロダクトへのマイクロサービス導入も進めています。長い歴史を持ちコードベースが複雑なプロダクトにマイクロサービスを導入するには、技術課題の解決にとどまらず、積み重なった仕様を解きほぐして関係者と調整を進める必要もあります。

この発表では、そのような課題に直面した一休.comレストランへのポイント管理マイクロサービス導入の事例を紹介いただきました。発表のなかで、デッドコード削除や仕様の調整のような地道な取り組みから、プロダクトとマイクロサービスを疎結合に保ちつつ連携する仕組みを解説していただきました。

『1000万DLを超えたiAEONアプリ：完全停止を防ぐ耐障害性と信頼性の設計』

2つ目の発表は、ASTの范さんによる『1000万DLを超えたiAEONアプリ：完全停止を防ぐ耐障害性と信頼性の設計』でした。

iAEONアプリは実店舗のレジ前で会員バーコードを表示するようなユースケースを想定しており、障害が発生して利用不可になることを可能な限り避けたいという要件があります。一方で、複雑なバックエンド側の一部で発生した障害がアプリに伝播することで、アプリが利用不可になることも過去あったとのことでした。

この発表では、上述したような特性を持つiAEONアプリの耐障害性を高めるための取り組みについてお話しいただきました。とくに、デバイス上のキャッシュなどを活用してフロントエンドであるiAEONアプリ上のエラーをできるだけ局所化する手法について詳しく解説いただきました。App StoreやGoogle Play StoreにおけるiAEONアプリの評価が結果的に向上したとのことで素晴らしいと感じました。

『宿泊予約サイトにおける検索と料金計算の両立』

3つ目の発表は、一休の鍛治さんから『宿泊予約サイトにおける検索と料金計算の両立』でした。

宿泊予約サイトである一休.comやYahoo!トラベルでの料金に関する業務ルールは複雑です。また、ユーザーが宿泊したい部屋をさまざまな条件に基づいて検索するときに、その複雑な業務ルールで算出される料金の検索サーバであるSolrで計算する必要があります。

この発表では、そのような一休.comの検索要件の複雑さの解説や、要件を満たすためにSolrのプラグイン機構を活用していることについて解説いただきました。SolrのプラグインはJavaで開発することができ、Javaの機能を活用できるので、Solrクエリをメンテナブルに保ちつつ、複雑な料金計算を検索時に実行できているとのことでした。

『SRE改善サイクルはチームを超えて - ダッシュボードを眺める会の取り組み』

4つ目の発表は、ASTのもりはやさんから『SRE改善サイクルはチームを超えて - ダッシュボードを眺める会の取り組み』でした。

New Relicなどを活用したシステムメトリクスを概観できるダッシュボードは、非常時に障害の原因を探るためのものとして非常に便利です。一方で、定点観測することで、日々のシステムの状態や、障害になり得る変化を見つけることができます。

この発表では、ASTのSREチームを中心にダッシュボードを定期的に眺める会を設けることで、メトリクスの変化や改善ポイントを発見して深掘りする機会を意図的に作り出す取り組みについてお話しいただきました。システムの信頼性を高める機会を作り出すのはもちろん、会を通じて「ザイオンス効果（単純接触効果）」でチームビルディングにも寄与している点が素晴らしいと感じました。

おわりに

「事業会社のサービスを支える基盤開発トーク」の様子について紹介しました。

各社のサービスの基盤プロダクト開発について社内外のエンジニアの工夫や知見が聞ける、とてもおもしろいイベントになりました。ご来場いただいたみなさま、ありがとうございました！

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

hrmos.co

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

www.ikyu.co.jp

情シスカンファレンス「Business Technology Conference Japan 2024」にブロンズスポンサーとして協賛します

Thu, 12 Sep 2024 16:25:06 +0900

コーポレート本部社内情報システム部兼 CISO室 id:rotom です。

10/12(土) にハイブリッド形式で情シス向けのテックカンファレンス「Business Technology Conference Japan 2024（BTCONJP 2024）」が開催されます。

btcon.jp

btajp.connpass.com

昨年オンライン開催された BTCONJP 2023 では私が登壇者として本社を東京ガーデンテラス紀尾井町へ移転し、オフィスファシリティ・コーポレートIT を刷新した話というテーマで発表させていただきましたが、今年は core staff として運営に参画しており、所属企業である一休はブロンズスポンサーとして協賛しております。

Identity, DX & AI, Device Management, Zero Trust, Cyber Security, Business Technology の6つのテーマに沿った12のセッションや、イオン / イオンスマートテクノロジー CTO の山﨑賢氏による基調講演を用意しています。詳細は以下のプレスリリースをご覧ください。

prtimes.jp

オフライン会場は一休本社も入居する、東京ガーデンテラス紀尾井町紀尾井タワーのLINEヤフー株式会社本社です。

map.yahoo.co.jp

LODGE での懇親会も予定しておりますので、ぜひ現地でご参加ください！

プロンプトエンジニアリングをしよう - 一休.comでの検索システム改善事例

Tue, 10 Sep 2024 18:04:10 +0900

はじめに

こんにちは。宿泊プロダクト開発部の宮崎です。

みなさん、生成 AI 使ってますか？

近年、AI の進歩はめざましく、文章生成や画像生成はもちろん、動画生成も実用的なレベルで出来るようになっています。

ChatGPT が話題になったのが 2022 年の 11 月なので、たった 2 年足らずでここまで来ているという事実に少し恐ろしくもありますね。AGI(汎用人工知能)の実現もそう遠くないのかもしれません。

一休でも AI 技術は注目していて今年の 6 月に、まさに生成 AI を使ってホテル検索システムの改善を行いました。

この記事では、その時に学んだプロンプトエンジニアリングの重要性について書いていこうと思います。

生成 AI を使ったホテル検索システム

今回我々が実装したのはフリーワード・文章でもホテルを検索できるシステムです。

以下のようなユーザーの自由な入力に対して、適切なホテル・旅館を返したいというのが目的でした。

福井でおいしいご飯が食べられる宿
沖縄　子供と楽しめる宿
静岡で犬と泊まれる宿

今までは、このような入力の場合、形態素解析をして検索を行っていました。しかしその場合、「子供と楽しめる」だと「子供」「楽しめる」に分割して検索するので、本来の意味「子供と楽しめる」とは少し結果が違っていました。

よって文章の入力に対しては意味を考慮して検索ワードを切り出す必要があります。

私たちが行ったのは、AI にユーザーの入力を解析させ意味毎に区切り、検索条件 area, condition に分解させるというものです。以下に具体的な例を示します。

例：ユーザーの入力：「銀座の夜景が楽しめる」

↓ これを AI で解析して分解する。

求める出力： { area:銀座, condition:[夜景が人気] }

従来は「銀座」「夜景」「楽しめる」で分解されていたのが、「銀座」「夜景が人気」に分解する。このようにして json 形式で返してくれれば、既存のシステムで検索できます。この分解を生成 AI にやってもらおうと考えました。

実際の検索結果

具体的にどんな検索になったのか、実際にリリースしたものを使ってみましょう。

まず、行きたい施設について文章を入力し、検索ボタンを押す。

今回は「東京近郊でサウナがあって禁煙」と入力してみました。

以下の結果が表示されます。東京近郊の都市で、サウナが人気、そして禁煙で検索されていますね。このように、ユーザーの入力ワードをシステムで検索できるよう AI で分解するというのが今回行った改善です。

実装における課題

ただ、この仕組みを実装する上で、1 つ大きな課題を抱えていました。

それは単純な話で、コストの問題です。

当時、私たちはこの分解に GPT-4 を使っていました。理由は他の AI と比較して GPT-4 が一番結果が良かったからです。（このプロジェクトは去年の秋ごろに始まったため、選択肢があまりなかったというのもあります。）

しかし、GPT-4 だとコストが高く、1 回の検索に 10 円以上かかることが分かりました。

どうしてそれほどコストがかかるのかというと、プロンプトが長いからです。

一休では、例えば近畿というエリアは「近畿(大阪以外)」と「大阪」という風に分けられています。このような一休独自のエリアの分け方や、用語を AI が解釈できるようにプロンプトに詰め込んでいるので、どうしてもその分プロンプトが長くなってしまうのです。

プロンプト例：

扱うエリア名は以下です。
- 北海道
  - 札幌
  - 函館・湯の川・大沼
  - 旭川・富良野・稚内
  - ...
  - ...

<<以下、地名がずらりと後に続く…>>

解決案

GPT-4 ではコストがかかる。プロンプトを短くするのも難しい。そこで考えたのは、GPT-3.5 Turbo を使うことでした。これを使えば GPT-4 の 1/60 の値段になるので、コストの問題は簡単に解決できます。

ただし、これが最初からできていれば苦労はしません。

例えば「大阪でサウナと温泉が楽しめる」なら、GPT-4 は

{ area:大阪, condition:[サウナ,温泉] }

と出力されるのに対して、GPT-3.5 Turbo は以下の様に間違うことが多かったです。

いくつかのキーワードが欠けている

例：{area: 大阪,condition: [サウナ] }
入力がそのまま入ってしまっている

例：{area: 大阪,condition: [サウナと温泉が楽しめる] }

こういった間違いに対して、最初はファインチューニングで精度を上げようとしました。ファインチューニングは既存のモデルに追加でデータを学習させて、微調整するというものです。

参考：https://platform.openai.com/docs/guides/fine-tuning

しかし、これも上手くいきませんでした。

例えば condition の解釈精度をチューニングすると area 解釈精度が悪化したり、逆もまた然りであちらをたてればこちらがたたず状態に…。

結果的にプロンプトを 2 つに分けて area 用と condition 用、のようにしてみましたが、精度の割にはコストが 2 倍に増えてしまって断念しました。

※補足：精度の検証には新しくデータセットを作成しました。入力キーワードと、どのように分解して欲しいかの回答のセットです。これらを用いて生成された回答の一致率を測定しています。

プロンプトエンジニアリングをしよう

頼みの綱のファインチューニングもうまくいかず、頭を悩ませていた時のことです。

私は OpenAI 社のファインチューニングのドキュメントを読んでいました。チューニング精度を上げるための秘訣が書かれていればと思ったのです。

するとその時、以下の一文が目に留まりました。

Fine-tuning OpenAI text generation models can make them better for specific applications, but it requires a careful investment of time and effort. We recommend first attempting to get good results with prompt engineering, prompt chaining (breaking complex tasks into multiple prompts), and function calling,

引用：Fine-tuning (https://platform.openai.com/docs/guides/fine-tuning/fine-tuning)

簡単に言うと、ファインチューニングの前にまずはプロンプトエンジニアリングやプロンプトチェイニング（タスクを複数に分割する）をしましょう、ということです。

私はこの時まで、プロンプトエンジニアリングを軽視していました。プロンプトの修正で出力が改善されれば苦労しないだろうと。

ですが、このドキュメントを見ながら自分の今のプロンプトを見返すと、推奨されている書き方をほとんどしていないことが分かりました。

よって、半信半疑でありながらも、とりあえずドキュメントに従ってプロンプトエンジニアリングを行いました。

すると驚くべきことに、GPT-3.5 Turbo でも GPT-4 と同等の精度を出すことができたのです。

難しいことは何もしていません。ただ、プロンプトを修正しただけです。

それだけでコストが 1/60 になり、今年の 6 月にこの機能をリリースすることができました。まず最初にやるべきはプロンプトエンジニアリングだったというわけです。

※補足：現在は GPT-3.5 Turbo ではなく、 GPT-4o mini を使っています。

プロンプトエンジニアリングについて

ここからは具体的にどういったプロンプトをどう修正したのかについて書きます。

OpenAI のプロンプトエンジニアリングのガイドラインを参考に以下の修正を行いました。参考：https://platform.openai.com/docs/guides/prompt-engineering

はっきりと簡潔な指示を出す

簡潔な言葉で何をしてほしいかを指示しました。

★ 修正前のプロンプト

現在、日本のホテルを検索するシステムを開発しています。システムは以下の機能を持っています。

＜＜システムの説明　※ここでは省略。実際は 50 行くらい使ってホテルや宿泊条件など、機能の詳細な説明をしていた。＞＞

ここで、以下のユーザーのホテル検索クエリに対して、上記の機能を使って絞り込むのが適切だと判断したのなら、その条件を教えてください。

★ 修正後のプロンプト

あなたは優秀なクエリ分析システムです。
ユーザーのホテル検索クエリが与えられますので、それを分析して、どんな条件で検索すればいいのかをjson形式で回答してください。回答には、三重引用符で提供されたデータのみを使って答えてください。

このヒントは以下に書かれていました。 https://platform.openai.com/docs/guides/prompt-engineering/tactic-include-details-in-your-query-to-get-more-relevant-answers

ステップバイステップで考えさせる

以前は 1 つの指示+複数のルールで指示していましたが、これをステップバイステップの指示に切り替えました。

★ 修正前のプロンプト

ここで、以下のユーザーのホテル検索クエリに対して、上記の機能を使って絞り込むのが適切だと判断したのなら、その条件を教えてください。
その際、以下のルールを守ってください。

1. JSON形式で教えてください。
2. たとえば、ユーザーのホテル検索クエリ「ペットと泊まれる 新潟」の場合、
  {area: ["新潟"], condition: ["ペット"]}
  というJSONを期待します。
3. ...
4. ...

★ 修正後のプロンプト

以下の思考フローを用いて、ステップバイステップで絞り込んでいくことを想定してください。
ステップ1：ユーザーのクエリを確認し、エリアに該当するものを抽出してください。
ステップ2：ステップ1で抽出したワードを出力のareaのキーに追加してください。
ステップ3：...
ステップ4：...

このヒントは以下に書かれていました。 https://platform.openai.com/docs/guides/prompt-engineering/tactic-specify-the-steps-required-to-complete-a-task

セクションを区別する

エリア名称や、用語一覧を渡しているのですが、ここを引用符などで区切りました。

★ 修正前のプロンプト

以下にシステムで扱える用語一覧を示します。
* サウナ
* 禁煙
* 喫煙
* 室内プール
* ...
* ...

★ 修正後のプロンプト

以下にシステムで扱える用語一覧を示します。
"""
* サウナ
* 禁煙
* 喫煙
* 室内プール
* ...
* ...
"""

このヒントは以下に書かれていました。 https://platform.openai.com/docs/guides/prompt-engineering/tactic-use-delimiters-to-clearly-indicate-distinct-parts-of-the-input

例を付ける

出力の例を付けました。上述したように、以前はルールを使って回答を制御していて、1 つか 2 つしか例を付けていませんでした。

それを以下の様に例を増やしました。

★ 修正後のプロンプト

以下は、出力のjsonの例です。

例1：「絶景と温泉」というユーザーのクエリの場合、以下の条件を出力してください。
{ condition : ["絶景","温泉"] }

例2：「浜松でうなぎ料理を楽しめる旅館」というユーザーのクエリの場合、以下の条件を出力してください。
{ area:["浜松"] condition: ["うなぎ料理"] }

例3：...

例4：...

このヒントは以下に書かれていました。 https://platform.openai.com/docs/guides/prompt-engineering/tactic-provide-examples

以上がメインとなるプロンプトの修正です。これらは本当にガイドラインに従って足りていないものを書き換えただけです。

それだけで約 35％の精度改善となったので、同じような悩みを抱えている方はぜひ試していただきたいです。

おわりに

今回、プロンプトエンジニアリングの効果を十分に理解することができました。

ただ、考えてみれば、人が人に仕事を任せる時は当然相手の立場やスキルを考えて指示を出します。これをどうして AI でやらないのか。 AI も AI の理解しやすい命令の構造があり、それをプロンプトエンジニアリングで最適化する。

人の気持ちを考えるように AI の気持ちを考える。

いい仕事をするためには人も、 AI も関係なく、相手を思い遣る心が大切なのだと思いました。

オフライン技術勉強会「事業会社のサービスを支える基盤開発トーク」を開催します！

Tue, 03 Sep 2024 17:58:08 +0900

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

この度、一休とイオンスマートテクノロジー合同で技術勉強会「事業会社のサービスを支える基盤開発トーク」を開催します！ ikyu.connpass.com

このイベントでは

一休.com、Yahoo!トラベル、一休.comレストランを運営する一休
iAEONアプリ等を開発・運営するイオンスマートテクノロジー

両社のシステムを支える基盤の開発についてお話しします。

様々なお話をしていただく予定ですが、一休から1つ「歴史あるプロダクトにマイクロサービスを導入するプロセス」について紹介します。
この発表では一休.comレストランにマイクロサービスを導入したときの取り組みについてお話しします。一休.comレストランはWebサービスとして18年もの歴史があるサービスです。歴史の長いサービスになると全てが新しい技術でできているわけではなくレガシーなアーキテクチャのものもあります。それらを考慮しながらマイクロサービスを導入していった泥臭い取り組みについてお話しする予定です。

他にも以下のようなトークを予定しています。

宿泊予約サイトにおける料金計算の格闘
1000万DLを超えたiAEONアプリ：完全停止を防ぐ耐障害性と信頼性の設計
SRE改善サイクルはチームを超えて - ダッシュボードを眺める会の取り組み

それぞれの開発で取り組んでいる課題についてリアルな話をお送りします。どのトークもとても面白い内容になると思います！

そして今回はオフラインで開催します。場所は一休本社も入居する東京ガーデンテラス紀尾井町17階にあるLODGEです。 https://www.z-lodge.com/www.z-lodge.com

懇親会もありますので、ご来場いただいた方はぜひ登壇者や他の参加者の方と交流していただければと思います。
ぜひお越しください！

React / Remix への依存を最小にするフロントエンド設計

Mon, 05 Aug 2024 14:26:26 +0900

CTO 室の恩田(@takashi_onda)です。

一休レストランのフロントエンドアーキテクトを担当しています。

Intro

一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。

user-first.ikyu.co.jp

一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。

今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。

この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜のオンラインイベント

offers-jp.connpass.com

にもご参加いただけると嬉しいです。この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。

なぜ依存を最小にするのか？

React / Remix を使っていて依存しないってどういうこと？と疑問を持たれる方も多いでしょう。まずはその動機からご説明します。

フレームワークやライブラリより寿命が長いプロダクトは珍しくありません。栄枯盛衰の激しいフロントエンドでは、そういったサービスの方がむしろ多いのではないか、とも感じます。

一休レストランのサービス開始は2006年です。同じ2006年に jQuery 1.0 がリリースされました。まだ、フロントエンドという言葉が生まれる前の時代です。

一休レストランは、そんな時代から二度のリニューアルを経ながら（今は二度目の真っ最中）継続しているサービスです。これからも広く使っていただけるよう日々、開発を進めています。

したがって、将来、エコシステムが大きく変わったとしても、その変化に少ない労力で追随し続けられることが重要となります。

フロントエンド領域も成熟してきているので、今後は、エコシステムが激しく入れ替わるような状況はもう訪れないかもしれません。それでも、フレームワークやライブラリレベルでみると、メジャーバージョンアップは数年単位で見れば避けられず¹、その中には破壊的変更を伴うものもあるでしょう。

バックエンド設計に倣う

バックエンド設計では、フレームワークへの依存を最小化する、という考え方が古くからあります。

すなわち、バックエンドの世界では、指針となる原則や、依存を最小にして疎結合にする技術が確立しているのです。

偉大な先人達の肩の上に乗るため、その知見はどういったものなのかを確認したいと思います。

依存性逆転の原則 (Dependency Inversion Principle)

ボブおじさんこと Robert C. Martin が提唱した SOLID 原則をご存知の方は多いと思います。その SOLID 原則の D 、依存性逆転の原則がフレームワークへの依存を最小化するための根幹の考え方になります。

（少々長くなるので、ご存知の方は読み飛ばしてください）

簡潔に説明すると、

高レベルモジュールであるドメイン層が自身の必要とする抽象 (interface) を定義し
低レベルモジュールにあたるインフラ層がその抽象を実現する詳細 (class) を実装する

ように設計すべし、という原則です。

高レベルモジュールが低レベルモジュールに直接依存するのではなく、低レベルモジュールが、高レベルモジュールの要求しているインターフェースの実装を提供する。言い換えると、低レベルモジュールが高レベルモジュールの抽象に依存することから、依存性逆転の原則と呼ばれます。

少し雑に言えば、高レベルモジュールにあたるのが我々の開発するプロダクトです。低レベルモジュールがフレームワークやライブラリと、それらを使ったインフラ層に相当します。

よく用いられる Repository の例で説明します。

プロダクトが知っているのは自身で定義した Repository の interface のみです。プロダクトが Repository の実装を構成するライブラリやフレームワークの API を直接呼ぶことはありません。 Repository の interface もフレームワークが要求する interface から独立しています。

フレームワークへの依存が疎結合になりました。

腐敗防止層 (Anti Corruption Layer)

他にもバックエンドで培われた依存を最小化するテクニックとして、腐敗防止層は欠かせません。

DIP に比べると、シンプルでわかりやすいと思います。

ライブラリや外部のサービスを利用するときに wrapper を挟み、変更の影響をその wrapper に閉じこめるという手法です。インターフェースや実装が安定しなかったり、将来交換する可能性が考えられるような場合に、特に有効です。

フロントエンドにどう適用するか？

「余計なことをしない」素直なフレームワークが大前提

現代のフロントエンド開発では、(メタ)フレームワークを利用することが一般的です。

まず、フレームワークに求められる要件を考えたいと思います。

「余計なことをしない」とは？

逆を考えるとわかりやすいかもしれません。

全部面倒を見てくれる、手厚いけれど、複雑な規約があり、その裏側がどうなっているかわからないフレームワークを思い浮かべましょう。フロントエンド・バックエンドは問いません。過去を振り返れば、だいたいどの言語にも一つはありそうです。

このような全部入りフレームワークは、

そのフレームワークが想定しているユースケースの範疇でコードを書けていて、
運用面でも安定しているのであれば、

とても優れた開発効率や開発体験が得られるでしょう。

ですが、フレームワークが用意してくれているレールから外れないと実現が難しい要件は往々にして存在します。そんな要件に遭遇してしまうと、フレームワークそのものに手を入れる以外の回避策しか見つからないことが多く、詰みます。²

また、そんな要件に出会わなかったとしても、そのフレームワークに密結合状態で依存しているだけで弊害は存在します。たとえばメジャーバージョンアップで破壊的な変更が加えられたとき、その変更に追随するための苦労は過去にそのようなフレームワークを使ったことがある方なら想像に難くないと思います。

Remix の採用

さて、逆の状況を踏まえた上で、あらためてフロントエンドの世界で「余計なことをしない」フレームワークの条件を考えてみましょう。

標準 API の尊重、ブラックボックスがない、なだらかなアップデートパス、実装がシンプル、といった条件が挙げられます。

現時点において React ベースでは Remix が条件を最も満たしていると判断し、以前ご紹介したように、一休レストランでは Remix に乗り換えることを決断しました。

その上でバックエンド設計の原則に従い Remix API への依存は最小限になるよう努めています。

疎結合なアーキテクチャを実現するためには、逆説的ではありますが、フレームワークがそれを可能とする作りになっていることが重要なのです。

Remix だと、なぜそれが可能になるのかは、最初にご紹介したオンラインイベントでもお話する予定です。

React 非依存の Vanilla JS だけで使えるライブラリを選ぶ

一休レストランでは以前ご紹介した XState に加えて Jotai と TanStack Query を利用しています。

いずれも React に依存していないという共通点を持ちます。

TanStack シリーズは Vanilla JS のコアと各フレームワークへのアダプタで構成されています。

Jotai は TanStack シリーズのようにフレームワーク独立を謳っているわけではなく、React で使うことを前提とした状態管理ライブラリですが、公式サイトにも

Now with a store interface that can be used outside of React.

とあるように v2 からは、Vanilla JS で利用できる状態管理ライブラリとしての側面も持つようになりました。

コアの Vanilla JS 部分と React アダプタが別れているため、他のフレームワークと組み合わせて使うことが可能です。たとえば Vue や Svelte, SolidJS のアダプタを作っている方もいるようです。

React / Remix での DIP

具体例として、一休レストランの soft navigation 機能をご紹介します。

一休レストランでの soft navigation では Remix の useLocation や useNavigate を直接使っていません。

アプリ側で、

useLocation に対応する useNavigationContext
useNavigate に対応する useEventNavigate

というカスタムフックをそれぞれ定義しています。

DIP の観点から見ると、useNavigationContext, useEventNavigate の signature が、高レベルモジュールの定義する抽象に相当します。

具体的に見てみましょう。

export function useNavigationContext(): NavigationContext {
    // implementation
}

関数が first-class citizen なので signature (interface) さえ変わらなければ、

type UseNavigationContext = () => NavigationContext
export const useNavigationContext: UseNavigationContext = createUseNavigationContext()

極端な例ですが、呼び出し元のコードを変えずに、後から実装を動的に差し替える形にすることも可能です。³

さて、これらのフックは Remix の useLocation や useNavigate に加え Jotai, XState を利用して実装しています。このフックの実装自体が、DIP における低レベルモジュールが実装する詳細にあたります。

もちろん、アプリで定義しているこれらのフックは、単に DIP を実現するためだけに導入しているわけではありません。あくまで、サービス固有のユースケースを実現するための機能を付加した抽象層になっています。⁴

ユースケースを具体的に見てみましょう。

ユーザーが一休レストランで予約をするとき、人数日時などの予約条件や空席状況に応じて、次に表示するステップを切り替えたい場面があります。このステップ、すなわち遷移先の切り替えは、固定的なナビゲーションではなかなか実現が難しい機能です。

また、レストランの空席状況は刻々と変化するので、その時点の状況に応じた動的な画面遷移が必要となります。

このようなユースケースに対応するため、ナビゲーションロジックは XState を使ったステートマシンで定義しています。そして、ステートマシンが次の操作に相当するイベントをもとに次の画面(状態遷移)を決定する仕組みを取りました。

useNavigationContext はステートマシンの現在のステートとそのコンテキストを返し、useEventNavigate はステートマシンにイベントを送信する関数を返しています。

コンポーネント設計

最後に、フロントエンドのアーキテクチャにおいて、本丸となるコンポーネントの設計について説明します。

コンポーネント、カスタムフック、Vanilla JS ロジックの三層で構成しています。

コンポーネント

コンポーネントは表示だけの責務を担う、テンプレートエンジン的な位置付けです。

function CourseFilter() {
  const facets = useAvailableFacets()
  return (
    <div>
      {facets.map((facet) => (
        <FacetButton key={facet.key} facet={facet} />
      ))}
    </div>
  )
}

function FacetButton({facet}: {facet: Facet}) {
  const toggle = useToggleFacet()
  const onClick = useCallback((_: MouseEvent<HTMLButtonElement>) => {
   toggle(facet)
  }, [toggle, facet])
  return (
   <button type="button" aria-pressed={facet.selected} onClick={onClick}>
     {facet.label}
   </button>
  )
}

基本的に、フックで取得した値を表示したり、イベントハンドラにバインドしている以上の仕事はしていません。

カスタムフック

カスタムフックは Vanilla JS ロジックとコンポーネントを繋ぐアダプター層です。

function useAvailableFacets() {
  return useAtomValue(availableFacetsAtom)
}

function useToggleFacet() {
  const set = useSetAtom(toggleFacetAtom)
  return useCallback((facet: Facet) => {
     set(facet)
  }, [set])
}

Jotai の atom と接続するだけの薄いアダプターになります。⁵

Vanilla JS ロジック

Jotai の atom から先が、Vanilla JS (TypeScript) で書かれたロジックです。

ただの TypeScript コードなので、可搬性が保証されます。

自動テスト

自動テストは、単体テストと e2e テストのみでカバーしています。

単体テストでは React Testing Library を一切使用していません。このことからも、React への依存が最小限になっていることが伝わるかと思います。

Vanilla JS ロジックは、そのほとんどを純粋関数として実装しているので、複雑な fixture のセットアップも不要で vitest で高速にテストが可能です。

依存の最小化で得られる利点

確実に発生するシナリオとして、フレームワークのメジャーバージョンアップに伴う破壊的な変更の影響を受けにくくなる、という点が挙げられます。

React 19 や React Router v7 (fka Remix v3) でどう変わる？

現時点で判明している範囲からの判断ではありますが、影響はほぼゼロになるだろうと見ています。

直接 Remix API を呼んでいる箇所は、これまで見てきたように DIP の低レベルモジュールにあたるフックの実装内に閉じています。また、その構造上、Remix API の呼び出し箇所も最小限に抑えられているため、仮に変更が必要になっても、手を入れないといけない箇所は必然的に最小限に留められます。

加えて Remix 自体もその設計哲学で、メジャーバージョンアップで導入される機能や変更は future flag として段階的に適用できる形で提供されます。破壊的な変更は伴うとはいえ、バージョンアップに追随する負担が抑えられたフレームワークと言えるでしょう。

例えば Server Component もオプトイン的に必要な箇所にだけ適用できるような仕様が検討されています。

React 19 や React Router v7 についても前述したオンラインイベントでお話しする予定ですので、興味のある方はぜひご参加ください。

極端な例だが、仮に他のフレームワークに置き換えないといけなくなったら？

コンポーネント設計でお伝えしたように、薄いコンポーネント層を移植するだけで対応できます。

TypeScript で書かれたロジックは、Vanilla JS というその性質上、変更することなくそのまま使えることには説明の必要もないでしょう。

Outro

依存ライブラリやフレームワークのメジャーバージョンアップ程度では、ほとんど揺らがないアーキテクチャができました。

あらためて前提を振り返ってみると、長い歴史を持ち、継続可能性が極めて高いサービスだからこその選択であるとも言えます。スタートアップで、MVP でとにかく試行錯誤を高速に繰り返したい、といった状況下では、また別の選択肢があると思います。

かなり長くなってしまいましたが、ここまで読んでいただきありがとうございました。この記事が、フロントエンドのアーキテクチャを考える上での一助となれば幸いです。

一休では、本記事でお伝えしたような課題をともに解決するフロントエンドエンジニアを募集しています。

www.ikyu.co.jp

まずはカジュアル面談からお気軽にご応募ください!

hrmos.co

React 19 や React Router v7 のリリースが近づいています。↩
Remix への移行を決めた理由の一つです↩
実際には素直に関数として実装しています。事前に定義しなくても関数の signature が interface として機能することを示すための例です。↩
実を言うと、最初から現在の設計に辿りつけていたわけではありません。当初は Remix の nested routes を駆使する案を検討していました。その過程でチームメンバーから示唆をもらい、ステートマシンを使ったアプローチに切り替えました。もし、当初案のままであれば DIP と正反対の状態になっていたと思います。↩
Jotai のようなライブラリを利用しない場合は useSyncExternalStore を使って、ロジックを React と疎結合にできます。↩

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

Wed, 17 Jul 2024 15:24:52 +0900

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

一休では「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を活用しています

Tue, 25 Jun 2024 18:03:12 +0900

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

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

Mon, 27 May 2024 12:03:28 +0900

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

一休では月に一度、社内エンジニア向けに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については以下の記事もご覧ください
  - https://user-first.ikyu.co.jp/entry/2022/07/01/121325
宿泊予約サイトの検索処理チューニング
- 国内宿泊サイトの検索処理には複数のシステムが関わっています。それらを複合的にパフォーマンスチューニングしてレイテンシを半減させた実践的なテクニック紹介でした
レストラン予約サイトフロントエンドの今とこれから
- YADOLINKに続きレストラン予約サイトもReact/Next.jsで構築していました。Next.jsによる状態管理の落し穴や今後の展望についての発表でした。詳細は他の技術ブログで詳しく書いているため、ご興味のある方は以下の記事もご覧ください
  - https://user-first.ikyu.co.jp/entry/2023/12/15/093427
  - https://user-first.ikyu.co.jp/entry/2023/12/22/190342

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

一休には、データサイエンス部・アーキテクトチーム・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

Tue, 21 May 2024 09:57:13 +0900

kymmtです。

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

一休の社内勉強会
2024年にこれまで実施した勉強会
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 の導入を見送ったのか

Mon, 15 Apr 2024 15:02:49 +0900

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 からの移行機能が提供されることも期待できます。

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

おわりに

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

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

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

Thu, 28 Mar 2024 11:56:31 +0900

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

背景

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

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

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

https://t.co/Y0SPmDE4yZ

この記事のコメントみてると、少し我々のシステムの要件が伝わってないというかそこの説明が記事に不足しているように思った。ので以下その補足
— naoya (@naoya_ito) March 29, 2024

現在の実装

スパは予約を受け付けるために在庫の管理をしてます🎁 データベースで在庫テーブルを持っていますが、ベタな管理をしています。特定の施設・日・在庫の数を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)

実装例

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

INSERT INTO Example(Bits) VALUES (n);の nに相当する値を在庫がある時間帯からビットへ変換して格納
検索時に時間を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

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

Wed, 13 Mar 2024 12:49:07 +0900

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

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

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

従来の開発プロセス

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

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

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

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

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

改善の方針

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

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

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

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

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

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

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

導入の様子

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

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

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

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

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

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

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

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

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

ツールの適切な運用

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

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

user-first.ikyu.co.jp

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

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

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

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

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

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

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

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

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

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

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

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

結果

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

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

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

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

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

これから

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

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

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

hrmos.co

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

www.ikyu.co.jp

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

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

Mon, 25 Dec 2023 13:22:15 +0900

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

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

一休レストランの Rust バックエンドが正式リリースされました。https://t.co/7N4VGv5ej9 このページのスマートフォンビューはバックエンドが Rust で書かれた GraphQL になってます
— naoya (@naoya_ito) October 4, 2023

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

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

Rustを選定した理由
現在のバックエンドのユースケース
- レストラン情報の取得
- 予約の確保
現在のアーキテクチャ
各モジュールの紹介
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アプリケーションは無効な値を入力されたり外部のサービスとの通信に失敗するなど、つねにロジックが失敗する可能性があります。そのようなロジックでは返り値としてResult¹を使うことで、確実にエラーをハンドリングできます。また、?演算子を利用することで、コードを簡潔に保ちつつエラーハンドリングできるのも便利な点です。

他には、一休レストランだと予約可能な時間や食事コースの検索結果などでコレクションを操作する場面が数多くあります。このようなときに、イテレータと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

一休レストランではanyhow::Resultを利用しています↩

開発ディレクターの進化と挑戦

Sun, 24 Dec 2023 09:09:02 +0900

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

宿泊プロダクト開発で開発ディレクターをしています、橋本と申します。
ついにクリスマスイブ。残すところこの記事を含めて2つとなりました。
本日の記事では開発ディレクター1年目の奮闘劇を皆さんに紹介したいと思います。
同じディレクターの方はもちろん、何か新しいことに挑戦している皆さんに届くと嬉しいです。

簡単に経歴紹介

新卒でNWインフラの会社に入社し、エンジニアとして法人顧客のサービス導入をサポートをしてきました。 AWSの運用、セキュリティ商材の導入、NW機器の導入運用、スマホ管理サービス導入など様々な分野を担当し、直近では技術営業として提案メインでの活動に従事していました。

5年目になったころ、サービスの導入ではなく、サービスを作ることに興味を持ち、プロダクト開発という新しい分野にチャレンジすることを決めました。
そこから社内の制度を活用し、現在は一休にお世話になっています。

奮闘劇

インプット多量死をなんとか免れた序盤

入社前に開発ディレクターとはなんぞやということですごく簡単な資格だけ取りました。
Webディレクション | Web検定（ウェブケン）
一般的なWeb業界の用語がメインで、実際に何をする役割なのかはふわっとだけ学びました。ただ、実際に入社してみると、言葉通り「右も左もわからない」状況でした。

社内で使われているツールで触ったことがあったのがGmailとSlackだけで、進め方以前に使い方がわからない。。
業務フローについて説明を受けるも、表面的なところだけ分かった気になってしまう。。
SQLも書けないのでデータ抽出を頼まれても時間がかかる。。
操作方法について聞くも1回では理解できないので、録画をして後で自分でコンフルにまとめる日々。。
なによりアウトプットが何もできない状態でした。

そこで自分が意識したのは、

わからないことはわからないままにしない
一度教えてもらったことは、次回からは一人でできるようになる

とにかく周りに迷惑をかけないように、渡されたタスクはミスなくこなせるようにすることを日々考えていました。
まずは仕事に慣れること、一人分の仕事ができるようになることを目指してがむしゃらに取り組む日々でした。

とにかくインプット量が多くて整理しきれなくなりそうになるのをなんとか踏ん張った2カ月。
2カ月目で起きたのが常に追いかけまわしていたディレクターの先輩が産休に入られるという出来事。。。

必死に犬掻きをする中盤

産休に入られた先輩から複数プロジェクトのディレクションを引き継ぎました。
正直、やってやる！という気持ちと、自分が主体になることでプロジェクトが失敗するのではないかという不安で、精神的には余裕のない状態でした。
実際に業務に取り掛かると、
引き継いだ業務をうまく進めようと意気込むが、頑張りどころと向かう先がイマイチ合っておらず、日々犬掻き状態。。
チームからはディレクションとしての役割を求められるが調整業務にも何日も時間をかけてしまう状態。。

今振り返るとこんな状態でした。

進め方や要件、仕様について各所と調整をしているつもりが、状況や要望を聞いてきて持って帰るだけの伝書鳩になっていた
ユースケースを複数考慮できず出戻りが発生することが多かった
自分がやるべき最低限タスクができていないのに、改善や新規の提案など背伸びをして何か価値を出そうと空回りしていた

振り返るとなかなか恥ずかしいですね、、

この状況を打破すべく意識したことは

取り組む前に進もうとしている方向の認識合わせを行う
悩むポイントはこまめに壁打ちを行う

チームマネージャーに週1回、プロジェクトの進め方やチームのコンディションについて会話をする時間をいただきました。これがとても大きかった…！
この時に必ず自分の考えをもって臨み、ギャップを埋めていくことに努めた結果、
敷いてもらったレール上を進めることはできるようになってきました。

では次は自ら動けるようにならねば。。。

自分の役割が何となくわかってきた今

複数のプロジェクトを経験することで、プロジェクトの初期、中盤、リリース前、リリース後のぞれぞれのタイミングでディレクションがやるべきことがわかってきました。
「あのプロジェクトと同じように、こう進めていきます」といえるようになったのは大きい。
今後の動きを予測して動けるようになったこともあり、チームメンバーや他部署から依頼をされることも増えてきました。
さらに成長を感じたところとしては、【考えるタスク】を少しずつこなせるようになったこと。
調整業務やチームの開発を前に進めることだけではなく、本来のディレクション（方向を示す）という意味での【考えるタスク】を担当し、チームがその方向に進んでいくという体験が少しずつできるようになってきています。

最近ではこのようなことに悩んでいます。

開発目線になりすぎてビジネス観点（価値あるもの適切なタイミングで世に出すためにはどうすべきか）が漏れてしまうことがある

これは同じ悩みをお持ちの方もいらっしゃるのではないでしょうか。
開発ディレクターは開発メンバーと過ごす時間が多いこともあり陥りがちな思考だと思います。安全にミスなく進めるためにはとても重要ですが、忘れてはいけないのは、
リリースをすることがゴールではなく、【価値のあるプロダクトを生み出すことがゴールである】ということです。

例えばA案が良いと思って進めていたけれど、リリース直前になってB案の方が顧客の満足度も高く、売上にもつながるとわかったケースがあるとします。
開発チームとしては、直前で変更を加えなくてはいけない、リリース日の延長はなるべく避けたい、という状況はストレスにつながると思います。
しかし、私たちが進むべきゴールは【価値あるプロダクトを生み出すこと】です。
開発チームには負荷がかかりますがディレクターとしてはサンクコストではなく、プロダクトの価値を見るべきです。

私は同様の経験を通じで、ディレクターは開発目線とプロダクトオーナーのどちらの目線も持つことがとても重要だと身をもって学びました。
ディレクターとして働き始めた当初は、ディレクターって正直いなくても開発は進むよな…と自分の価値を見つけられずにいました。
今では、プロダクトの価値を最大化すること、さらに開発チームとプロダクトオーナーの両者が最も進めやすい方法を模索することがディレクションの価値だと思っています。

今後に向けて

今の私が意識し、目標にしていることを宣言させてください。
私は、エンジニアより技術力はない。
私は、マーケターよりも市場の把握や予測に強くない。
私は、営業よりも現場の考え方が理解できていない。
けれど、チームの推進力を高め、開発によって生み出されるプロダクトを価値あるものにする力は誰よりも持てるようになりたい。

そのために2つのことを意識していきたいと考えています。

チームマネジメントについて学び、チームに合った進め方でさらに推進力を上げていく
ビジネス目線を常に意識し、開発で生まれるサービスが価値あるものになるようにディレクションを行う

一人のディレクターとしてチームや会社にとってなくてはならない存在になることを目指してきます。

最後に一言

勇気を出して、別業界かつ別職種にチャレンジしたことを本当によかったと思っています。
辛い時もありますが、日々自己成長できていると実感することができています。
この場を借りてチームメンバー、同じエンジニアメンバー、一休の皆さんに感謝の気持を伝えたいです。いつも温かいアドバイス、ありがとうございます。
これからも明るさと元気を取柄に頑張ります！

一休レストランの XState 導入記

Fri, 22 Dec 2023 19:03:42 +0900

このエントリーは一休.comのカレンダー | Advent Calendar 2023 - Qiita の22日目の記事です。

レストランプロダクトUI開発チームの鍛治です。一休レストランのフロントエンドを担当しています。

一休レストランでは ~~Next.js App Router~~ Remix を採用しています。

user-first.ikyu.co.jp

昨年の終わり頃から始まった一休レストランのリニューアルですが、フロントエンドは Nuxt v2 (Vue 2) から Next.js App Router (React) に、という大きな切り替えで、不慣れだった我々は React 初心者がひっかかる落とし穴を全部踏み抜いてきました。

例えば、チュートリアルに従って useState で変化する状態を定義して、最初はそれで全てがうまくいっていました。機能追加していく過程でいつの間にか一つ増え二つ増え、あとはズルズルと。ふと我に返ると一つのコンポーネントに10個もの useState が生えてしまっていました。その結果、 &&, ||, ?? のオンパレードと三項演算子だらけの JSX だけが残りました。何度も何度も読み返してるのに、コンポーネントが今どんな状態にあるのか、さっぱり把握できない…

他にも、

バケツリレーコールバック
useEffect 問題

といった落とし穴を踏み抜いてきました。

フロントエンドの状態管理って本当に難しいですよね。

あらためて本日は React 状態管理改善の第一弾として useState 濫用からどう抜け出したのかについてお話しします。

コールバックや useEffect 問題は来月以降の記事でご紹介する予定です。

useState の難しさ

まずは一番初歩的なところから考えてみましょう。

複数のuseStateフックを使用する場合、予期しない状態の組み合わせが発生する可能性があります。

function Sample() {
 const [show, setShow] = useState(false);
 const [disabled, setDisabled] = useState(false);
 const toggle = useCallback(() => {
   setShow((prev) => !prev);
 }, []);
 const toggleDisabled = useCallback(() => {
   setDisabled((prev) => !prev);
 }, []);
 return (
   <>
     <button onClick={toggle} disabled={disabled}>
       show
     </button>
     <button onClick={toggleDisabled}>disable</button>
     <SampleModal show={show} />
   </>
 );
}

このシンプルな例では、show（モーダル表示用）と disabled（ボタン無効化用）の二つの状態を管理しています。

しかし、たった二つしかないのに show === true && disabled === true のように、ボタンが無効化されているにも関わらずモーダルが表示されている、という矛盾した状態を表現できてしまいます。useState で管理する状態が増えれば増えるほど、矛盾した状態を生んでしまう可能性は高くなります。

この問題を解決するためには、コンポーネントの粒度を小さくし、useState には primitive 値を入れず構造化されたデータを用いて、ありえない状態を生まないようにするのが自然な発想でしょう。


type State = Initial | Disabled | Modal


type Initial = {
 type: 'Initial'
 disabled: false
 show: boolean
}


type Disabled = {
 type: 'Disabled'
 disabled: true
 show: false
}


type Modal = {
 type: 'Modal'
 disabled: false
 show: true
 modalData: ModalData
}


function Sample() {
 const [state, setState] = useState<State>({ type: 'Initial', disabled: false, show: false })
 const open = useCallback(() => {
   setState({ type: 'Modal', modalData: 'data', disabled: false, show: true })
 }, [setState])
 const toggleDisabled = useCallback(() => {
   if(state.disabled) {
     setState({ type: 'Disabled', disabled: true, show: false })
   } else {
     setState({ type: 'Initial', disabled: false, show: false })
   }
  }, [setState])
  return (
   <>
     <button onClick={open} disabled={state.disabled}>
       show
     </button>
     <button onClick={toggleDisabled}>disable</button>
     <SampleModal show={state.show} />
   </>
 )

useState + union 型では足りなかった

上述した実装のように、union 型によって不正な状態が作られなくなりました。

遷移はイベントハンドラ内で暗黙的に記述されます。上記のモーダルでは状態が2つしかなく、シンプルな実装なので遷移の全体像を把握できていますが、状態の数が増え遷移が複雑になると遷移の全体を把握するのが困難になり、人為的に遷移先を決定するロジックをテストする必要があります。結果、誤って不正な遷移が紛れ込む場合があります。

例えば、一休レストランでは空席確認カレンダーという機能があります。

空席確認カレンダー

上記空席確認カレンダーの状態遷移図は以下のようになります。黒色で囲われているのが状態で、灰色で囲われているのが遷移イベントです。

カレンダーの状態遷移図

状態が7個、遷移イベントが20個あり、イベントハンドラ内での遷移先を決めるロジックが複雑になってしまい不正な遷移を起こしてしまう可能性がありました。

このような不正な遷移を人為的ではなく機械的に防ぐために、state machine を導入します。

state machine とは？

state machine は複数の「状態」と「状態間の遷移」で構成されます。

上述した web 画面のシナリオを例にすると「フラットな状態」（通常の状態）から「モーダルが開いた状態」への遷移は「 show ボタンをクリックする」というイベントによって行われます。

「モーダルが開いた状態」では再度「show クリック」イベントが発生しても、そのイベントに対応する状態遷移は定義されていないので、それ以上何も起きません。

また「フラットな状態」から最初に disabled ボタンが押されて（disable イベントが発火して）「ボタンが無効化された状態」になると、そこで仮に show イベントが発火しても、同様に show イベントに対応する状態遷移が定義されていないので、「ボタンが無効なのにモーダルが開いてしまう」という矛盾した状態が生じません。

モーダルの状態遷移図

state machine では、あらかじめ定義した状態とその状態間の遷移しか存在しないので、予期しない状態に陥ることがありません。state machine を導入すると、アプリケーションロジックを明確かつ宣言的に定義できるのが非常に魅力的なポイントです。

XState (state machine) の導入

state mcahine を導入するために、XState を使った状態管理方法を導入することを決定しました。

もちろん他の解決策もあったと思います。

例えば、弊社 CTO が以前ご紹介した TypeScript の discriminated union （タグ付きユニオン型）で状態を、関数で遷移を表現する手法はその一つであり、弊社プロダクトで実績あるソリューションであることは間違いありません。

techplay.jp

ただ、現在の自分達では、制約のない状況下でうまく型を定義して、状態を完全にコントロールできるという自信は持てませんでした。state machine もどきの不完全な物を生み出してしまわないか不安があったのです。

XState であれば state machine を正しく定義することを強制されます。技術としてのフレームワークに留まらず、思考のフレームワークとしてガイドレールを提示してくれる点を評価しました。

XState とは？

stately.ai

state machineを作成することができる非常に高機能なライブラリです。

例えば、フロントエンドのサンプルとしてよく用いられる TODO リストを XState で実装*1すると以下のようになります。

type TodoList = {
 items: {
   id: number
   name: string
   completed: boolean
 }[]
}


type TodoEvent = Add | Toggle | Disable | Enable


type Add = {
 type: 'ADD'
 item: {
   id: number
   name: string
   completed: boolean
 }
}


type Toggle = {
 type: 'TOGGLE'
 id: number
}


type Disable = {
 type: 'DISABLE'
}


type Enable = {
 type: 'ENABLE'
}


type TodoState = { value: 'ACTIVE'; context: TodoList } | { value: 'INACTIVE'; context: TodoList }


export const machine = createMachine<TodoList, TodoEvent, TodoState>({
 initial: 'ACTIVE',
 states: {
   ACTIVE: {
     on: {
       ADD: {
         target: 'ACTIVE',
         actions: assign((ctx, event) => ({ items: [...ctx.items, event.item] })),
       },
       TOGGLE: {
         target: 'ACTIVE',
         actions: assign((ctx, event) => ({
           items: ctx.items.map((item) =>
             item.id === event.id ? { ...item, completed: !item.completed } : item
           ),
         })),
       },
       DISABLE: 'INACTIVE',
     },
   },
   INACTIVE: {
     on: {
       ENABLE: 'ACTIVE',
     },
   },
 },
})

まず state として TODO を追加したりトグルを変更が可能な状態の ACTIVE と、なにもできない状態の INACTIVE を定義します。

次に、各 state が各イベントを受け取った時にどの状態に遷移するか、すなわち状態遷移を on で定義し、その状態遷移時の副作用としてのデータ更新を actions で指定することで、state machine が完成します。

XStateでは、内部情報として context （詳しいことは後のセクションで説明します）を持ちます。ADD イベントでは context である items に新しい TODO を追加しています。

XState で定義した state mahine では、INACTIVE の状態で ADD や TOGGLE のイベントに対する状態遷移を定義していないので、ありえない状態に遷移しないことが保証されます。。

context

context とは、state machine が扱う状態の「詳細」や「変動する部分」を吸収して、複雑な状況に対応する仕組みです。

state machine 、厳密には有限状態機械（FSM: Finite State Machine）の「有限」は、あくまで数学的な「有限」です。

実際のアプリケーションでは、管理しなければならない状態に紐づくデータや条件が複雑で、有限状態機械を原理的に適用すると、たとえ「有限」であっても、人間の認知能力ではとうてい把握しきれない膨大なバリエーションを生み出してしまいます。

有限状態機械を現実的に利用するために状態とその状態に関連するデータを分離して、context という形で保存・管理します。

例えば以下のように、ユーザーの入力やアプリケーションの現在の状態など、状態自体ではなく、状態の「内容」を表すデータのことです。

予約する人数日時
予約の際に選択する支払い方法
使用するクーポン情報

予約入力の状態遷移図

XState で管理すべきでない状態

XState で全ての状態を管理すべきと言ってるわけではありません。ボタンを押すとモーダルが表示される状態遷移は、XState で管理してしまうと却ってオーバーエンジニアリングになってしまいます。

また、以下の場合は状態として持つべきではありません。

状態遷移から独立しており、値が操作の過程で変化しないもの

例えば、API レスポンスは state machine の遷移に変化する値ではないので XState で管理すべきではなく、useState で管理すべきです。

XStateで管理すべき基準としては

1つのコンポーネントで useState が3つ以上定義されている
何かアクションを起こした時の遷移先が2つ以上ある

場合だと思ってます。（プロダクトによって基準は違うと思うのであくまで目安です）

XStateを導入して良かったこと

フロントエンドの改修が容易になった

state machine によりありえない状態ができないことが担保されているので、フロントエンドの改修をする際に大きいバグが起きなくなりました。

実装前の仕様 / モデリングの議論ができるようになった

state machine が画面のドメインモデルとなるので、画面や機能を作成する際にどのような state machine にするか議論することで、意図せずも画面や機能のモデリングの議論ができるようになりました。

所感

XState による state machine という考え方のガイドレールができたことで、条件文を最小限にする state mahine のメンタルモデルが形成されてきたように思います。

また、上述したように全て XState で管理すべきだとは思ってません。適材適所で XState をうまく活用していきたいです。

さいごに

一休では、より良いサービスを作ってくれる仲間を募集しています！

www.ikyu.co.jp

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

hrmos.co

*1:XState 4 ベースのコードです。XState 5には近日中に移行予定です

Cloud Runで開発用環境を沢山作る

Sat, 16 Dec 2023 11:27:05 +0900

概要

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

RESZAIKO開発チームの松村です。

一休では各サービス毎に、開発中のサービスの動作を社内で確認できる環境があります。それぞれmain(master)ブランチと自動的に同期している環境と、特定のブランチを指定して利用できる環境の2種類があります。

今回、RESZAIKOの新規サービス(予約画面)に対してブランチを指定してデプロイできる環境を作成したので、その方針と反省点と今後について記述していきます。

現在運用中の予約画面

開発環境を作る理由

一休では長らく、EKS上に複数の環境を用意して、ブランチを指定すると開発環境にデプロイするシステムが利用されてきました。一般的にこのような環境を構築するのは以下のような理由が挙げられます。

動作確認
- マイクロサービスで、異なるブランチ同士の組み合わせで動作確認がしたい
- ローカルだと何故か再現しない
- デプロイがちゃんと動くか確認したい
他人と成果物の共有
- リリースできるほど動作に自信は無いが、ステークホルダーと内容を共有したい

本サービスではPrismaを利用してDBのスキーマをアプリのコードと同じリポジトリで管理しているため、複数の新機能を平行して開発していく場合に開発環境が1つだと、DB定義が衝突したりして尚更大変です。そこで、複数の開発環境を作成できるようにしました。

本サービスは基盤にGoogle CloudのCloud Runを使用しています。 Cloud Runは特に設定しなければアクセスがある時だけコンテナが起動するようになっているので、EKSを使用した場合よりスペックやコストをあまり気にせず環境を増やしていけます。

実現方法

サーバはCloud Runで動いていて、デプロイは Github Actionsで行っています。そのため、開発環境用のGithub Actions Workflowを作成していきます。

デプロイを行うGithub Actions Workflowの作成

本記事の主旨から外れるので詳しく説明しませんが、 Google CloudにはGithub Actionsと連携してデプロイを行うための機能が各種用意されているので、参考にしてWorkflowのyamlファイルを作成します。

name: backend.demo.create

on:
  workflow_dispatch:
    inputs:
      name:
        required: true
        type: string
        description: "Environment name to deploy"

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: "Checkout"
        uses: actions/checkout@v3

      # SecretからGCPの認証用のjsonを読み出す
      - id: "auth"
        uses: "google-github-actions/auth@v0"
        with:
          credentials_json: "${{ secrets.gcp-dev-service-accont-key }}"

      - name: "Set up Cloud SDK"
        uses: "google-github-actions/setup-gcloud@v0"
        with:
          install_components: 'alpha,beta'
      # 以下ビルド・デプロイの記述

Workflowの呼び出し

Workflowに workflow_dispatch を定義することで、外部からREST APIでWorkflowを呼び出すことができます。開発環境用のアプリを作成して、そちらからREST APIで必要に応じてWorkflowを呼び出してあげます。

POST https://api.github.com/repos/test/test-repo/actions/workflows/backend.demo.create/dispatches
Content-Type: application/json
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
X-GitHub-Api-Version: 2022-11-28

{
  "ref":"feature/branch-to-test",
  "inputs":{"name":"demo-1"}
}

実装された運用

ブランチデプロイサービス画面

こんな感じのアプリを作成しました。ブランチ名を入力して Deploy を押すと、デモ環境に該当のブランチがデプロイされます。いつ、誰が、どのブランチをデプロイしたかを記録するようになっています。削除機能はまだ実装していないので、使い終わったらmainブランチを手動で適用する運用になっています。

反省と将来

折角Cloud Runを使っているのに、既存の他サービスの仕様に引きずられた実装にしてしまいました。特に以下の点が良くないです。

設定ファイルをコピペして増やしていたので、環境を増やす毎に同じような設定ファイルが増える
環境毎に社内用のドメイン( [env-name].dev.reszaiko.com のような)を作っていたので、環境を増やす度にDNSとSSLの設定が必要になる

このため、気軽に環境を増減させる事が困難になっていて、既存の問題をそのまま引き継いでいます。

使わなくなった環境を戻し忘れてそのまま占有し続ける
空いている環境がない場合、他の環境を使っている人とコミュニケーションして融通してもらう必要がある

このままデプロイ環境を作るなら

ブランチデプロイ環境として、全てのブランチに対して自動的にデモ環境を作成、破棄するのが理想です。コンテナのビルドやDBやサーバの用意、デプロイは既にGithub Actionsで行うようにしていますし、開発環境へのアクセスはCloud Routerを利用して振り分けているため、 dev.reszaiko.com/[branch-name]/ のように環境毎のパスの追加もGithub Action上で構築できます。

また、特に開発環境を必要としない軽微な修正に対しても無制限に環境を作るのを防ぐために、以下の手段が考えられます。

dev-**** のように、特定のprefixを持つブランチに対して自動で環境を作る
既存のデプロイ用UIを拡張して、環境数を増やしたり減らしたりできるようにする

前者はブランチが消えれば自動で環境が消えるので、使わなくなった環境が残ってしまうというよくある問題が解消できます。後者はUI上で存在する環境の把握やアプリへのリンク、DBのリセットなど機能を追加する事ができて便利です。

開発環境を作らないと駄目なのか

そもそもブランチデプロイ環境が必要か、という問題もあります。

開発中のブランチを長期間利用していると本番環境との乖離が大きくなり、mainブランチにマージする際に入念なチェックが必要になります。 RESZAIKOの予約チームではトランクベース開発のように頻繁にリリースする手法を導入するか議論していますが、このような手法では開発中の機能はフィーチャーフラグを利用して出し分けるのが適しています。

RESZAIKOでは LaunchDarkly というフィーチャーフラグ機能を提供してくれるSaasを導入しているため、コストをかけてブランチデプロイ環境を開発していくよりは、フィーチャーフラグを適切に利用する体制を整備し、開発環境はmainブランチと同期したものだけで運用していく方がいいかもしれません。

まとめ

使用している技術やサービスは日々新しい物が導入対象になるので、最適な開発手法というのはその時に合わせて検討する必要があります。次に記事を書くときは「トランクベース開発に合わせたフィーチャーフラグの運用法」みたいなのが書けるように頑張ります。

一休では、共に働くエンジニアを募集しています。

www.ikyu.co.jp

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

hrmos.co

一休レストランで Next.js App Router から Remix に乗り換えた話

Fri, 15 Dec 2023 09:34:27 +0900

このエントリーは一休.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 に軍配があがるようです。

宿泊管理システムのフロントエンド設計と改善の変遷

Thu, 14 Dec 2023 09:11:16 +0900

宿泊の管理システムについて
新しい管理システムについて
開発初期のフロントエンド設計
初期ローンチ後の課題
改善した内容
現在と今後
- 今後やりたいこと
- 改善を継続するためのポイント
まとめ
おわりに

宿泊プロダクト開発部の田中（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によって発生しないケースもあります

ADR を1年間書いてみた感想

Wed, 13 Dec 2023 11:51:12 +0900

宿泊開発チームでエンジニアをしている @kosuke1012 です。チームで ADR を書き始めて1年くらい経ったので、その感想を書いてみたいと思います。

この記事は一休.comのカレンダー | Advent Calendar 2023 - Qiita の13日目の記事です。

ADRとは

アーキテクチャ・ディシジョン・レコードの略で、アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録していくものです。

出典はこちらで、

Documenting Architecture Decisions

わかりやすい和訳は以下の記事が、

事例は以下の記事が分かりやすかったです。

〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(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 Developers Blog

一休 Frontend Meetupでエンジニアとデザイナーがフロントエンド開発の知見について紹介しました

発表

『一休.com のログイン体験を支える技術 〜Web Components x Vue.js 活用事例と最適化について〜』

『Webパフォーマンス改善 〜宿泊予約サービスでの取り組み〜』

『一休の世界観を形にする、ガイドラインとデザインシステム』

『飲食店予約台帳を支えるインタラクティブUI設計と実装』

おわりに

Jotai を使った Dependency 管理とテスト技法

はじめに

アーキテクチャ

Dependency の管理

Jotai で function を管理する

Jotai Scope で Dependency を切り替える

テスト技法

純粋関数で書く

シナリオテスト

おわりに

Cloud WorkflowsとCloud Tasksを使って日次のバッチ処理を作る

宿泊システムのバッチ処理について（背景・課題）

新たに必要になったバッチ処理をどうやって作るか

Cloud Workflows + Cloud Tasks を使ったバッチ処理

処理フロー

Cloud Workflows

Workflowsから外部APIを呼び出す

APIのレスポンスをもとにCloud Tasksにエンキューする

Cloud Tasks

Web API

リリース後の運用

Cloud Tasksのキュー設定の調整

異常終了時の検知を強化

まとめ

おわりに

一休.com の情シス / コーポレートIT 変遷、6年を経てどう変わったのか

はじめに

取り組んできたこと

組織体制の変化

オフィスファシリティの刷新

Slack Enterprise Grid 移行

デバイス管理の刷新

EDR / SIEM 導入

ライセンス・アカウント管理の改善

ヘルプデスクの改善

Slack 打刻 / 勤怠打刻自動化

パスワードマネージャー全社展開

PPAP 廃止

ファイルサーバー移行・廃止

SASE 導入の見送り

まとめ

オンプレからクラウド / SaaS 中心のモダンな IT へ

色々やった。これからどうするか

エンジニア採用中です !

TypeScript の Discriminated Union と Haskell の代数的データ型

TypeScript の Discriminated Union (判別可能な Union 型)

実際のユースケース ··· 絵文字アイコンあるなしの表現

ディスクリミネーターは、ただの判別用のシンボル?

Haskell のデータ型宣言

代数的データ型でより構造的なデータ型を扱う

TypeScript に同様のメンタルモデルを持ち込む

余談

Design Doc でチームを跨いだ開発を円滑に行う

チーム構成について

コードレビューについて

いきなりコードを書かない

Pull Request を出す際に気をつけていること

Design Doc との乖離がある場合

レビュアーの負担を最小限に

最後に

永続データプログラミングと永続データ構造

永続データプログラミング

Haskell と永続データプログラミング

永続データの特性を利用した問題解決

永続データ構造

TypeScript や Python で永続データ構造を利用するには?

永続データ構造は業務システム開発にも必須か?

永続データ構造の実装例

永続スタック

永続配列

まとめ

追記

『一休.com のログイン体験を支える技術〜Web Components x Vue.js 活用事例と最適化について〜』

『Webパフォーマンス改善〜宿泊予約サービスでの取り組み〜』

Vue.js、Nuxtの機能を使い、大量のコピペコードをリファクタリングする