Yaravan — 誰も書き留めてこなかったアフターサービス業務のサービスデザイン

各工程は文書ではなく関門で終わった。要件は、事業部門の責任者に向けた50の直接的な選択式の質問、ブランドと元資料のレビュー、そして競合9社のベンチマークから得たもので、成功の基準は一つ。エンジニアリングが根本的な問いを一つも聞き直さずに着手できることである。

そこで準備度の監査を実施し、結果は不合格だった。59の情報源と31のプロセスを対象に、判定はNOT_READY。阻害要因は12、未解決の矛盾は4つ、役割は互いに食い違う3つの分類体系に分かれていた。第2ラウンドは判定に反論しなかった。範囲をブランドが実際に所有する13のプロセスに絞り、その後の修正で受付、診断、修理、返送、部品を加えて22まで広げた。

Figmaファイルには画面が一つもない。インターフェースは文章で仕様化し、デザインの労力は誰も説明できなかった部分、つまり業務に注いだ。最初のページは表紙ではなくルールのページで、14の部品からなるコンポーネントライブラリと6つのハウスルールが置かれている。フローは言語と同じく右から左へ流れる。空白には「要確定」と記し、推測した名前や数字で埋めることはない。矛盾は解消せずに記録する。色だけで意味を伝えることはなく、必ず形とアイコンを伴わせる。

ファイル全体の形を決めるルールが一つある。何を描いてよいかは、主張ごとに、その裏付けとなる証拠で決まる。証拠は5段階に分かれ、最上位の実行可能なコードならスイムレーンを完全に描けるが、最下位の根拠がまったくないものは描くことが禁じられ、注記だけが許される。段階が低いほど、描いてよいものは少なくなる。

だからファイルは、欠けているものについて正直である。ある階層が途中で止まる箇所では、注記ボードが何が欠けていて、なぜなのかを示す。サービスマップとスイムレーンの注記は、自らの数の内訳を22に合わせて締めくくる。文書化されていない手順を図にすれば、ルールが禁じる創作と同じものになる。ただ、より説得力があるだけだ。

アーキテクチャには6つの階層があり、それぞれが異なる問いに答える。顧客による保証の有効化は、そのすべての階層で描かれた数少ないプロセスの一つであり、全体の積み重なりを示してくれる。マクロマップ上では、担当者、アウトプット、ステータスを持つ1枚のカードである。レベル1ではエンドツーエンドのカードになる。トリガー、担当者、開始と終了のイベント、4つのフェーズ、判断ゲート、受け取るものと引き渡すもの、コードが強制する統制 — そして「要確定」と記されたKPIとSLAである。承認された計算式も時間も、どの情報源にも存在しないからだ。

レベル2はサービスブループリントである。顧客の行動、タッチポイント、そして相互作用線、可視線、内部相互作用線のそれぞれの側でスタッフとシステムが行うことを、各ステップが残す記録と統制まで描く。ここでは、顧客が出発点とする印刷ラベルが、システムの管理外にあるタッチポイントであることがわかる。印刷はシステムの外で行われるからだ。ファイルはそのタッチポイントも描いている。表面と裏面からなる印刷用の保証カードで、バリエーションは10種類ある。レベル3は、同じ手順をアクターごとのレーンを持つスイムレーンに変える。

レベル4と5は、それを運用する人のためのものだ。業務手順書は4つのプロセスを一度に扱い — 業務手順書とプロセスは一対一ではない — 「未承認」の印が押され、承認者とレビュー日は「要確定」のまま残されている。作業手順書は顧客自身が行う7つのステップで、顧客のために書かれたチェックリストが付く。コードに使う文字には0、O、1、I、Lが含まれないため、印刷ラベル上の文字を読み違えることはない。

業務を図にしたことで、どの文書にもなかった発見が生まれた。スイムレーンとして描いた14のプロセスのうち、そもそもSMSを送るのは2つだけ — ログインコードと保証の有効化 — だった。そのため、メッセージ文面の草案はちょうどその2つのマップに入れた。マクロマップ上の4つのプロセスにはカードがない。根拠として挙げられた資料が存在しないからである。

ある階層を正直に描けない箇所では、注記がその代わりを務める。6つの作業手順書はまだ書けず、それぞれに名指しされた理由がある。リセットの仕組みがない、所有権をめぐる争いの経路がない、請求書番号の書式がない、未解決の矛盾がある、写真の基準がない、引き取られない品物についての方針がない。修理品質の業務手順書には、作業手順書の番号をまったく割り当てなかった。実施者がまだ決まっていない手順のために番号を確保すること自体が、一つの主張になってしまうからだ。

ファイルは自らを監査してもいる。カバレッジマトリクスは22のプロセスそれぞれを、その情報源、存在する階層、欠けているものと照らし合わせる。完了が6、不完全が6、矛盾が1、要確定が9。クローズ済みとされていた3つの空白を再び開いている — クローズ済みであることは、組織によって解決されたことと同じではない。そして、情報源が引用された内容を実際には述べていなかった箇所では、自らの引用を取り下げている。

8枚の役割カードが、各役割の目的、職務、固有の権限、意図的な除外、空白を示し、どのカードでもKPIとSLAは「要確定」と記されている。問いがほとんどを占めるカードもある。ある役割はコードに存在し、アクセス権も持っているが、どの業務文書、組織図、業務手順書もそれを定義していない。そのため、それが実在する役割なのか、既存の役割の別名なのかを事業側が決めるまで、そのレーンは破線で描かれている。

責任分担マトリクスは、4分の3までしか導けなかった。Responsible（実行責任者）、Consulted（相談先）、Informed（報告先）はコードから導けたが、Accountable（説明責任者）は導けなかった。コードが語るのは誰が操作を実行できるかであって、誰がその結果に責任を負うかではないからだ。マトリクスはその列を空けたまま、そう明記したバナーを付けて公開され、意図的な除外 — 職務の分離 — を赤で示して、空白と取り違えられないようにしている。取り消しの上限額を設定する役割は、取り消しを承認できない。自分の上限を自分で引き上げられてしまうからである。

アクセスモデルも同じように扱った。あるページは、コードが強制する8つの構造的な統制を示している — デフォルトで拒否すること、役割がページの存在を知ることさえできないよう403ではなく404を返すこと、そしてデフォルト値を創作しないこと。「デフォルト値を創作することは、誰も承認していない方針を黙って公開することを意味する。」その隣では、アフターサービス部門のスタッフ自身による役割の提案 — 8つの役割、76の項目 — を、「統合せず、すり合わせもせず」、項目ごとに横に並べてコードと照らし合わせている。76のうち完全に実装されているのは3つで、20は承認済みのアーキテクチャ上の決定と矛盾している。そしてページは自らの限界を明記している。提案が正しいかどうかについては、判定を下さない。

業務は、その中心にある約束にいくらかかるのかにも答えなければならなかった。保証は、発行された日には何のサービスも提供しない。あるのは、一定期間内に端末が故障すれば誰かが支払うという約束だけだ。請求が来るのか、いつ来るのか、いくらかかるのかは、その日にはすべて不明である。だから今のうちに資金を取り置かなければ、約束の裏付けは何もなくなる。

資料は、その債務を発行から終結までたどり、誰がそれを賄いうるかを示す。そして、それぞれの答えがブランドの正体を語る。小売企業がコストを吸収するならコストセンター、販売者がコードを買うなら独立した事業、輸入業者が支払うならネットワークを運営するパートナーである。推奨には「決定ではなく提案」と明記している。

資料の結びは、コスト順に並べた管理策 — 最も安いものはフィールド一つ — と、担当者と選択肢を付けた10の判断で、そのうち8つは数字が一つもなくても今日下せる。