ケース 04 — OneDegree Global — 2021年

中小規模の保険会社のために、基幹業務を簡素化しデジタル化することで、体験をどう改善できるか。

企業: OneDegree Global
担当: シニアプロダクトデザイナー
プラットフォーム: Web、SaaS
期間: 2021年

プロジェクト概要

IXT は、中小規模の保険会社が引受・契約管理・保険金支払といった基幹業務をデジタル化するためのエンタープライズ SaaS です。2.0 リリース後、私は数字を一つ間違えれば実損につながる領域を中心に、UI・インタラクション・モーションの設計を継続的に担当しました。

フロー自体は専任の UX デザイナーが定義しており、私はその定義を実装可能な画面・状態・仕様に翻訳する役割でした。とはいえ実行にも UX の視点は必要で、情報の階層、タスクの流れ、そして「ユーザーがどこで間違えうるか」を常に判断の基準に置いています。

モジュールは Product、Policy、Application、Claim、Member の5つ。設計の重心は前の3つに置きました。

目標

プロダクト・事業側との合意

金融規制がとりわけ厳しいアジア市場において、中小規模の保険会社が新商品をより速く投入できるようにすること。

プラットフォームが約束していたのは規模を伴うスピードでした。そのため設計課題の置き場所も自ずと決まります。保険を美しく見せることではなく、規制と計算に囲まれた業務を、毎日それを回す人にとって耐えられるものにすることです。

課題

中小規模の保険会社は、基幹業務のデジタル化にあたって高い運用摩擦と現実的な導入障壁を抱えています。難しいのはツールではなく、乗り換えのコストのほうです。

引受業務が非効率。 紙と手作業の工程、長い承認の連鎖。それが使い勝手の悪いレガシーシステムにそのまま持ち込まれています。
デジタル化にはコストがかかる。 小規模な保険会社が持たないリソースを要求する——それこそが、いまだに紙が残っている理由です。

スコープ

Product・Policy・Application

5つのモジュールのうち3つを優先。事業要件と、日々の担当者のニーズが最も重なる領域を選びました。

プロダクトマネージャーと提供価値と方向性を整理し、競合比較を行い、アクチュアリーや保険商品担当者へのエキスパートインタビューにも同席しました。事業要件の確定が最優先で、かつ最も間違えやすい部分でもあります。保険のルールは、外側からの推測では当たりません。

設計上の難所

保険商品は保険料と保険期間の複雑なロジックを抱え、複数商品が組み合わさると規則同士が絡み合います。制約は、既存のフレームワークの内側で、デザインシステムを膨らませずに明快さを届けることでした。

新しいパターンは二度払う費用です——デザインで一度、実装でもう一度。ですから各画面で最初に問うのは、既存のコンポーネントで担えないか、でした。

進め方

定義 → UI → 状態 → プロトタイプ → 再利用

業務フローとルール定義をそろえる
判断ポイントと例外を、手戻りの安い早い段階で PM・UX と確認。
フローを実装可能な UI に翻訳する
情報密度の高いフォームと表を、階層・グルーピング・段階的開示で構造化。
状態・バリデーション・エッジケースを定義する
エンジニアと共に、検証・警告・確認・ローディング・空・エラーを設計。計算過程は正しいだけでなく、説明できる必要がありました。
プロトタイプで曖昧さを減らす
静止画では決着しないもの——表の操作や段階的なフロー——には軽量なプロトタイプとモーション検証を。
再利用可能なパターンで広げる
タイポグラフィ、余白、コンポーネントの使い方を文書化し、システムを拡張せずに一貫性を保ちました。

枠組み

全モジュールが継承するもの

一貫したページの枠

どのモジュールも同じ枠で開く。読み手は着いた時点で、どこを見ればいいかをすでに知っている。

ワークベンチは縦に長く、情報量も多い。ここでの「迷わないこと」は親切ではなく前提です——現在地を見失った読み手は、何をするより先に地図を作り直すことになります。

キャンバス: 左ナビゲーションと、ゆとりを取った中央のコンテンツキャンバス。
コンテキストヘッダー: 契約・商品 ID、現在のステータス、主要な日時を常に見せ続けます。
セクション: 密度の高い内容はカード単位のブロックに割り、表は比較が必要な一覧にだけ使いました。

ワークベンチの枠02

独立した閲覧モード

閲覧のための状態は、読み取り専用で「ある」だけでなく、そう言う必要がある。

編集のあと、その内容は確認され、共有され、承認されます。安全なのに安全に見えない画面は、キーひとつで何かが変わりうるものとして扱われ続けます。

読む順序: 情報を構造化されたブロックとして、フォームではなく上から順に読めるものとして提示します。
語らせる: 無効化されたフィールドと読み取り専用のスタイルが状態を語るので、どちらのモードで開いたかを覚えている必要がありません。
まとめ方: 内容は階層に沿ってまとめられ、生のフォーム項目をスクロールせずに要点を確認できます。

閲覧の画面03

ナビゲーションとバージョンの状態

ナビゲーションは二つの問いに同時に答える必要があった——いまどこにいるか、そして編集しているのは本番か。

判断の多い業務では領域間の行き来が絶えず、商品は一つのものではなく状態を持つバージョンの連なりです。どちらの問いにも、寄り道せずに答えが出る必要がありました。

レールと一覧: 全体領域を示す固定のアイコンレール、その内側に現在のワークスペースのセクション一覧。内容が詰まってきたら折りたためます。
予測できること: 展開可能なグループを含め、ラベルと階層をそろえたので、「あの設定はどこか」を予測できます。
バージョンの状態: 公開予定、公開中、取り下げ済み——バージョン選択はその状態をラベルの外ではなく中に置くので、すでに手を伸ばしていたコントロールの上で問いに答えられます。

ナビゲーションとバージョン状態05

読む

まず確認 —— すべての画面が最初に置かれる状態

契約サービシング

サービシングは確認の状態で開き、操作はすべて意図して手を伸ばすもの。

サービシングは生きた契約に対する影響の大きい操作です。画面が最初に置かれた状態こそ最も多くの作業が行われる状態なので、既定が「うっかり何かを変えてしまう易さ」を決めます。

文脈: 「どの契約か」「状態は何か」「どの期間を見ているか」に即答が要ります。サマリーヘッダーが証券番号、主・副ステータス、主要メタデータ、そしてステータス変更のアクションを保持します。
操作: 既定は確認——読むためのカードセクション——とし、アクションは外に出しました。全体操作は右上、行単位は表の中、文脈依存のものはその場に。誤操作は起こりにくくなります。
リズム: どのタブも同じ型に従います。契約の文脈、セクションナビ、カードブロック、そして密度の高い一覧には表。Policy Parties、Policy Details、Billing、Excluded Item を通じて同じ形です。
状態: Effective と Pending、Overdue と Paid、更新の関係。状態には明快なラベルとバッジを与え、例外は自らシグナルを出し、ステータス変更は常に同じ場所に置きました。
請求: Billing は「いま注意すべきこと」から設計しています——次回の支払と支払方法を最上部に、その下に照合用のステータスタグ付き全スケジュール。Excluded Item は行単位の編集と削除を持つ例外専用の作業領域です。

サービシングの画面04

プラン閲覧

契約書のような内容を、法的に効力を持つ細部を削らずに読めるものにする必要があった。

プランの内容は密度が高く入れ子です——主条項、条件、特約。どれも薄めることができないので、変えられるのは組み方だけでした。

階層: 法文を抱えたフォームではなく、実質的なタイポグラフィ階層と余白を持つドキュメント型のビューア。
まとめ方: グルーピングは条項同士の関係を一続きに平坦化せず、そのまま反映しています。

プラン閲覧02

詳細フィルタ

絞り込みは引き返せるものでなければならない——現在地を失わない、誤って確定しない。

ワークベンチの一覧には柔軟な絞り込みが要り、しかもフィルタは正解に至るまで何度も試されるものです。外したときの代償はゼロに近くある必要があります。

ページではなくパネル: ヘッダーから下りるドロップダウンなので、絞り込む対象である一覧の文脈が、絞り込む行為で失われません。
構造: 項目 × 演算子 × 値の構造で複数条件にも耐え、型ラベル付きのオートコンプリートが不整合を防ぎます。
安全な試行: 適用とキャンセルを置いたので、試すことと確定することが別の行為になります。

フィルタパネル

日付ピッカーの位置

動かす

数字を一つ間違えると高くつく場所

ここまでは、誰も何も変えていないあいだにこのプラットフォームがしていることでした。ここから先は、誰かが変えているときの話です。このプラットフォームではそれは、間違いが高くつく場所と言い換えられます。

編集画面

複雑な入力は設定を誤りにくくなければならない——しかもモジュールごとにパターンを学び直させずに。

多くの項目が計算とその後の挙動に効きます。ここでの誤りは打ち間違いではなく、顧客のもとへ届く誤った数字です。

階層: 長いフォームを一貫したセクションとブロックに構造化。見出し、余白、揃えが「何が仲間で、何が何に依存するか」を語ります。
再利用: ドロップダウン、トグル、行追加、インラインヘルプ、表内アクションを標準化。同じ操作はどこでも同じ挙動になります。
状態: 編集可能と読み取り専用、必須と任意、検証と警告——これが、防げたミスと出荷されたミスを分けます。

編集の画面04

ルールエディタ

ルール記述には専用の作業空間が要る一方で、プラットフォームの一部であり続ける必要があった。

高度なルールは設定するものではなく書くものです。集中して書くことと属性を素早く見つけることを両立させ、その最中もエラーが読める必要がありました。

配置: 左にツール、右にコンテンツ——ワークベンチと同じ配置なので、文脈の切り替えが安く済みます。
探し方: 属性セレクタは折りたたみ式で、開けば検索、閉じれば集中。その背後に二通り——階層フィルタでの一覧と、型の手がかり（Num、Enum）付きの検索、そしてコピペを減らす挿入アクション。
フィードバック: コンパイル結果と構文ガイドを専用の領域に置き、デバッグがページを離れないようにしています。
面: 明るい UI に対して暗いエディタ面——ラベルなしでこれはコードだと言えます。

ルールエディタ05

プロダクトモジュールのその他

ルール一覧と、その背後の料率表

これらが何か: 引受ルール一覧の三つの状態——まだ何もない、下書き、公開済み——と、同じ一覧をより密に見せた表示、そして料率が書き込まれる Excel 形式の料率表です。
注記: 元のケーススタディはこの5枚を「More product module screens」という見出しの下に置き、それ以上は何も書いていません。ここにあるのも同じ理由です——モジュールの一部であり、実際に作られたもの。出典が主張していないことは、ここでも主張していません。

ルール一覧と料率06

解約ウィザード

このプラットフォームで最も重い操作は、各判断を明示的かつ確認可能にする必要があった。

ここでの小さな誤りは連鎖します——返戻金の誤り、請求の誤り、書類の不一致。しかもそれは多くの場合、時間に追われながら一部解約の途中で起こります。

ステップ: 対象選択・解約情報・返戻計算の3ステップと、常時表示の進捗インジケータ。
段階的開示: 既定は最小限に保ち、特約の選択は一部解約のときだけ現れます。
注意: 中央一列のレイアウトと任意ラベルが、注意を効く項目へ導きます。
検証: 返戻プレビューは合計の前にプラン別内訳を出すので、確定する前に数字を確かめられます。

解約フロー04

デザインシステム

Area → Fundamentals → Components & Patterns

プラットフォームがモジュールをまたいで広がるにつれ、手戻りを増やさずに拡張できる共通の UI 言語が必要になりました。私はコーポレートアイデンティティから視覚的な土台を作り、それをチームが適用できる規則に変換しました。

実際のプロダクト構造を写している。 Area、次に Fundamentals、そして Components & Patterns——ガイドラインをプロダクトと同じ順に辿れます。
Area レベルの規則がモジュール横断の一貫性を生む。 ナビゲーション、ヘッダー、コンテンツ領域がどのワークベンチでも同じ挙動になり、それがずれを防ぎます。
コンポーネントは規則とセットで出す。 レイアウト・状態・使用例を一緒に置いたので、複雑なフォームは再設計ではなく組み立てになります。
インタラクションの文書化がハンドオフの摩擦を減らした。 選択の挙動、アクションの配置、検証の状態を書き下ろしたことで、実装が解釈作業ではなくなりました。

Area

ワークベンチがどう組み立てられるか —— モジュール間のズレを止めるための規則。