Caribou

「Caribouは、複雑なSKU構造を意識することなく、ビジネスの意図をシステムに反映できる橋渡しとなりました。」

02—What is a SKU

SKU（Stock Keeping Unit／在庫管理単位）とは、企業が在庫を管理するために、特定の商品や商品のバリエーションごとに割り当てる、英数字で構成された固有の識別コードです。

このケーススタディでは「SKU」という言葉が繰り返し登場します。SKUの複雑さは、Caribouを設計することになった主要な課題の一つでした。

03—コラボレーション商品のローンチは、見た目以上に複雑だった

コラボレーションは、一見すると次のようなシンプルな要件から始まります。

「この10種類のデザインを4月1日にAPACで発売し、指定された商品・機種に対応させる。」

しかし、実際には各デザインに複数の条件や制約が紐づいていました。

• 商品との互換性

• 対応機種

• 地域ごとの販売可否

• 販売開始・終了時期

• ストア上での表示ルール

• 除外条件や特別な表示要件

最終的には、これらの条件を10地域のECサイトそれぞれに合わせた技術的な商品設定へ落とし込む必要がありました。

さらに、同じIPであっても地域ごとのライセンスチームが別々の契約を持つ場合があり、使用できるデザイン、販売期間、テーマ、契約条件なども異なっていました。

04—ミスの本当のコストは、ミスそのものではなく、そこからの復旧だった

繰り返し発生していた問題の一つが、誤って予定より早く販売を開始してしまうことでした。

契約上の販売開始日時より前に、コラボ商品がストア上で購入可能になってしまうことがありました。ライセンスチームが問題に気づいても、自分たちですぐに販売を停止することはできませんでした。

そのため、緊急時の対応は次のような流れになっていました：

この緊急対応も、完全なロールバックとは言えませんでした。

商品を非表示にすることで通常のストア上からは見えなくなりますが、すでに商品ページのURLを知っているユーザーや、商品をカートに追加していたユーザーは、引き続きアクセスできる可能性がありました。また、チーム間で対応を調整している間に、10〜20分程度の対応時間が発生することもありました。ライセンス契約の内容によっては、予定より早い公開によって契約上・金銭上の問題につながる可能性もありました。

旧システムはミスが起こり得る一方で、問題発生後の復旧が困難でした。

この気づきによって、デザイン上の課題そのものが変わりました。

「誰もミスをしない」という前提でシステムを設計することはできません。

05—再設計の前に、まずワークフローそのものを再構築する必要がありました

単純に改善できるような既存のプロセスマップはありませんでした。誰もが「何かがおかしい」と感じていました。Operationsチームには大きな負担がかかり、ローンチのたびに多くの作業が発生し、問題が起きても原因を特定することが困難でした。しかし、なぜそうなっているのかについて、チーム間で共通した理解がありませんでした。

既存システムの制約、過去に作られた回避策、地域ごとの例外、そして個人ごとのやり方が長年積み重なり、プロセスは徐々に複雑化していました。すでに退職した社員が作ったワークフローさえ残っていました。そのため、ディスカバリーは一種の「ワークフローの発掘（workflow archaeology）」になりました。

各チームに「どんな機能が欲しいですか？」と聞くのではなく、実際に現場で何が起きているのかを一つずつ再構築することから始めました。

リサーチを通して、組織には複雑なプロセスが存在する一方で、そのプロセス全体に対する共通認識がないことが明らかになりました。ワークフローや知識は、各部門に分散していました。

• ライセンスチームは、ビジネスルールを理解している

• オペレーション担当者は、SKUの仕組みを理解している

• デザインチームは、プリント素材を理解している

しかし、それらがどのようにつながり、最終的なストア上の動作になるのかを、全体として把握している人はいませんでした。

06—複雑さを隠す、情報は隠さない

最初のイテレーションでは、まずデータベース上の作業を効率化しようと考えました。技術的には、最も速い解決策はシンプルでした：

• 構造化されたSKUデータをアップロードする

  • 大量のデータを一括処理する

  • すべてを一度に更新する

これが、「Batch Import（一括インポート）」機能になりました。

効率的な方法ではありました。しかし、私たちがより大きな裁量を持ってもらいたいと考えていたユーザーに対して、実際とは異なる前提を置いていました：

ライセンスチームはコラボレーションの内容を理解していましたが、SKUの構造までは理解していませんでした。

この解決策は、ユーザーの考え方ではなく、システムの仕組みに合わせて最適化されたものでした。ライセンスチームへのヒアリングを通じて、この前提そのものを見直す必要があることに気づきました。システムにとって最も効率的なワークフローが、必ずしもユーザーにとって最も理解しやすいワークフローとは限りません。

07—混沌からシステムモデルへ

さまざまなケースを横断して分析し、そこに共通するルールを見つけました。

調査を進める中で、多くのケースが見つかりました。

• 新しいコラボレーション

• 新しいスマートフォン機種

• 新しい製品ライン

• 新しいプリントデザイン

• 対応製品・機種の変更

• 発売日の変更

• 対象地域の変更

• 表示ルールの例外

• 既存設定の更新

これらのケースを一つひとつ個別に設計してしまうと、解消しようとしていた複雑で断片的な仕組みを、再び作り出すことになります。

そこで私は、さまざまなケースを共通のルールへと整理するため、ファネル型のプロセスを用いました。

意図的にプロセスを4つの段階的なレイヤーに分解し、それぞれが前のレイヤーを土台として進む構造にしました。この階層構造は、リサーチを通して明らかになった繰り返し発生するビジネス上の意思決定を整理し、誰もが理解できる共通のワークフローへと落とし込んだものです。

ユーザーは各レイヤーを順番に進みます。必要な項目が未入力、または正しく設定されていない場合、それに依存する次のレイヤーの操作はできません。これにより、重要なステップの抜け漏れを防ぎ、各意思決定がどのようにつながっているのかを明確にしました。

目指したのは、単に作業を簡単にすることだけではありません。社内の各チームが合意したワークフローを、システム上でも確実に守れる仕組みにすることでした。さらに、依存関係やシステムの状態を可視化することで、設定上の問題をユーザー自身で発見・解決し、ITチームに問い合わせる前に対応できるようにしました。

Create Design Code —「何が存在するか」を定義する

ライセンスチームが、あるコラボレーションに含まれるプリント素材の数を把握した時点で、その数に対応するデザインコードを作成します。例えば：

プリント素材10点 → デザインコード10枠

デザインコードを作成すると、Caribouはデザインチームの素材データベースと同期します。デザインチームが対応する素材を完成させると、その画像がCaribou上に表示されます。

次のレイヤーへ進む前の確認も、PT01、PT02といったコードだけを見るより、実際の画像を見ながら確認するほうが直感的で分かりやすくなります。

また、このレイヤーには「マスタースイッチ」機能も実装しました。これにより、元の商品設定を変更することなく、各プリント素材の有効・無効を切り替えることができます。

Print Asset Management—技術的な関係性を、理解しやすいビジネス上の選択肢へ

プリント素材が登録されたら、ユーザーは次の関係性を設定します。

プリント素材 ↔ 製品ライン ↔ 対応モデル

内部では多数のSKUの組み合わせによって管理されていますが、ユーザーがそれらを理解する必要はありません。代わりに、「056」のような技術コードではなく、「iPhone 16 Pro」のような馴染みのある製品名やモデル名を使って設定できます。

また、前のステップで選択した内容に応じて、関係のない選択肢を減らしていきます。例えば、スマートフォンケースを設定している場合、他の製品ラインを候補として表示する必要はありません。

次の判断を求める前に、選択肢を絞り込む。
これまでユーザー自身が頭の中で理解しておく必要があった複雑な関係性を、システム側で吸収する設計にしました。

Design-spec List—ストアフロント上の表示ルールを可視化

Caribou導入以前、ストアフロントの設定は非常に手間のかかる運用作業でした。Appleが新しいiPhoneモデルを発売するたびに、オペレーション担当者が10地域すべてのストアフロントの商品画像を手作業で更新する必要がありました。

多くのコラボレーションでは標準の表示ルールを適用できましたが、一部の印刷アセットには個別の対応が必要でした。例えば、暗い色のケースではデザインが見えにくくなる場合や、ライセンス契約上、特定の商品カラーへの使用が制限される場合がありました。しかし、こうした例外ルールは引き継ぎや担当者個人の知識に依存することが多く、後から更新することが困難でした。

Caribouでは、ストアフロントの表示設定を体系的に管理できる仕組みを導入しました。ユーザーは、「この印刷アセットを最新のiPhoneモデルに表示する」といったルールを設定し、10地域すべてのWebサイトに一括で適用できます。さらに、より細かな表示制御を可能にするため、以下の設定タイプを定義しました：

• Spec Whitelist：表示を許可する仕様

• Spec Blacklist：表示を制限する仕様

• Default Spec：デフォルトで表示する仕様

• No-show Spec：ライセンス上の制約により表示しない組み合わせ

これにより、各印刷アセットをストアフロント上でどのように表示するかをより細かく制御できるようになり、同時に、これまで個人の知識に依存していた例外ルールも一か所で管理・確認できるようになりました。

Design Launch—同じ作業を10回繰り返さずに、地域ごとの公開設定を管理

以前の公開フローでは、オペレーション担当者が地域ごとに公開タイミングやストアフロントの状態を繰り返し設定する必要がありました。

Caribouでは、同じ設定を適用する地域をまとめて管理できるようにしました。

以前：

• 台湾 → 設定

• アメリカ → 設定

• フランス → 設定

• …

Caribouでは：

• 4月1日 10:00 → 選択した地域に一括適用

Caribouが各地域のストアフロント設定や、それに伴うタイミングのロジックを自動的に処理することで、ユーザーは複雑なシステム処理ではなく、「どの地域で、いつ公開するか」という本来の意思決定に集中できるようになりました。

09—安心して設定できるための設計

設定を完了できるだけでは不十分でした。ユーザーは、その結果が自分の意図どおりになっているかを確認できる必要がありました。

以前のワークフローでは、設定を完了しても、その内容が本当に正しいかを確実に確認する方法がありませんでした。これほど大規模な設定では、それ自体が大きなリスクになります。

そこでCaribouでは、ユーザーの記憶に頼るのではなく、現在の設定状態を常に可視化し、いつでも確認できるように設計しました。

リカバリーを考慮して設計しましたが、まず重視したのはミスを未然に防ぐことです。
Caribouでは、各操作によって何が起こるのかを明確に示すだけでなく、依存関係に沿ったガイドと確認ステップを設けることで、変更が本番環境に反映される前に、設定ミスが発生する可能性を減らしています。

ミスを防ぐだけではなく、ミスから安全に復旧できる仕組みも設計しました。

前述した予定より早く公開されてしまった事例から、重要なことが分かりました。どれだけインターフェースでユーザーを適切に導いても、ミスを完全になくすことはできません。複雑な業務フローや要件は変化し、人は締め切りのある状況で作業します。だからこそ、問題が起きた後のリカバリーも設計の一部として考える必要がありました。

マスタースイッチ機能により、特定のプリントデザインに問題が発生した場合、ユーザーはそのデザインだけを直接無効化できます。対応範囲をプリントデザイン単位に限定することで、商品全体の設定に影響を与えることなく問題を切り離せます。

対応フローは、次のようにシンプルになりました。

1. 問題を検知

2. ライセンスチームがCaribouを開く

3. 該当するプリントデザインを無効化

4. 問題を封じ込める

これにより、スピード・安全性・アカウンタビリティのバランスを取ることができました。問題に最も近いチームがすぐに対応できる一方で、誤って商品全体の設定を変更することはできません。また、Caribouには「誰が・いつ・何を変更したか」が記録されます。

ユーザーに無制限の操作権限を与えたのではなく、問題が起きたときに安全に復旧できる手段を提供しました。

10—ガイド付きワークフローだけでは対応できない場合

ガイド付きの階層構造で大部分の業務フローには対応できるものの、すべての例外ケースをカバーできるわけではないことは分かっていました。
まれに発生する例外のためにメインの操作フローを複雑にするのではなく、基本フローはシンプルに保ち、頻度の低いケースには別の操作方法を用意しました。例えば：

• 新しいスマートフォンモデルが追加された場合

• 新しい製品ラインが発売された場合

• 製品ラインに新しいカラーが追加された場合

• 既存の数千件の関連設定を一括で更新する必要がある場合

こうした作業まで毎回ガイド付きワークフローで行うと、かえって新たな非効率が生まれてしまいます。

そのため、Batch Import（一括インポート）機能は残しました。

Batch Importをより効果的に活用できるよう、大量データの処理に特化した専用インターフェースを設計しました。経験のあるユーザーは、最初にガイドに沿って操作方法を理解すれば、その後は大規模なデータ変更を効率よく行えるようになります。

さらに重要なのは、これによってオペレーション担当者が設定作業全体に関与する必要がなくなったことです。 経験のあるライセンスチームのメンバーが自分たちで作業を管理し、新しいメンバーにも操作方法を教えられるようになりました。その一方で、複雑なSKU構造を理解する必要はありません。

最終的に、このプロジェクトでは意図的に2つのワークフローを共存させました。
Batch Importはガイド付きワークフローの代替でも、「Version 2」でもありません。 ユーザーの経験レベルや業務シナリオによって適した操作方法が異なるため、それぞれに適したワークフローを用意しました。

11—成果：オペレーションへの依存から、管理されたセルフサービスへ

成果は、単に管理ツールが速くなったことではありません。チームとシステムの関係そのものが大きく変わりました。

再設計したワークフローにより、設定にかかる時間を約1週間から半日程度まで短縮しました。ライセンスチームは、複雑なSKU構造を理解しなくても、自分たちでプリントデザインのルールを管理できるようになりました。また、マーケティングやカスタマーサービスも、共通のシステムを通して同じ設定内容を確認できるようになりました。

さらに重要なのは、これまで人が手作業で結びつけていた情報を、システムが結びつけるようになったことです。
ライセンスチームがビジネスルールを定義し、デザインチームがアセットを制作し、Caribouがそれらを一つのシステム上でつなぎ合わせます。その結果、オペレーション担当者はコラボレーション設定のワークフローから完全に外れ、ほかのオペレーション業務に集中できるようになりました。

この役割の変化は、プロジェクトにおける最も大きな成果の一つでした。

「人が情報をつなぐ」仕組みから、「システムが情報をつなぐ」仕組みへと変わりました。

振り返り——複雑さは消えたわけではない

このプロジェクトは、私にとって非常に印象深い経験となりました。始まりは、オペレーション担当者の隣に座り、誰にとっても大きな負担となっていた、約1週間にわたる業務プロセスを観察することでした。

私が以前から最も興味を持っているのは、プロセスそのものの裏側にある「人の動き」です。人はどのように作業を進め、どこでつまずき、なぜその行動を取るのか。振り返ってみると、このプロジェクトから得た最も大きな学びの一つは、デザイナーとして単に効率よく問題を解決するだけでは不十分だということでした。その解決策を使う人が、どのように理解し、どのように感じるのかまで考える必要があります。

最初の解決策そのものが間違っていたわけではありません。しかし、効率化を大きく進める一方で、ユーザーに何を理解してもらう必要があるのかを十分に考慮できていませんでした。この経験を通して、「複雑さ」とどう向き合うべきかについて、私自身の考え方も大きく変わりました。

Caribouは、既存システムが抱えていた複雑さそのものをなくしたわけではありません。
本来その複雑さを理解する必要のなかった人たちから、その負担をシステム側へ移したのです。