貿易部門の帳票業務を、ひとつのシステムに。
食品を扱う商社の貿易部門で、Excel と紙で回していた帳票の「作成・申請・承認」を電子化する社内システム。原価計算から発注、信用状、コンテナ通関まで。性質の異なる7種の帳票を、参照できる既存UIがない状態から、配色・入力UI・全画面まで一貫してデザインしました。
新しくすることと、現場が慣れた操作を壊さないこと。そのあいだに、どう線を引いたか。何を選んだかだけでなく、何を捨てたかまで書いています。
起票する人と、承認する人。
帳票をつくって、申請する。
7種の帳票から選ぶ → 一覧・新規・編集・詳細は共通のレイアウト → 保存するたびに版が積み上がる。50項目を超える帳票も、Excelと同じ感覚のまま入力できる。
経路をたどって、承認する。
申請の経路をステッパーで、いまどこまで進んだかをタイムラインで確認 → 承認、または差し戻し。誰がいつ何をしたかが、画面に残る。
差し戻して、版を重ねる。修正して再申請すると、版が新しく積み上がる。過去の版は閲覧のみで巻き戻さない。監査で問われたときに、経緯をそのまま辿れる状態を保っている。
帳票7種 × 一覧・新規・編集・詳細に、承認とリビジョンの2系統が横断する。90を超える画面が、この一往復の上に載っている。
※守秘義務に配慮し、実際のプロジェクトをもとに、社名・商品・氏名・金額などのデータと、ロゴ・画面の一部をポートフォリオ用に匿名化・再構成しています。
Excelの帳票業務を、壊さずにWebへ。
食品を扱う商社の貿易部門では、輸入にまつわる多くの帳票を Excel と紙でつくり、申請・承認していました。このプロジェクトは、その一連の業務を電子化し、作成から承認までを一元管理するための社内システムです。
扱う帳票は、原価計算書・販売予定表・発注書（P/O）・稟議書・信用状依頼書・コンテナ通関予定表など全7種。それぞれ項目も性格も異なります。わたしはデザインを単独で担当し、参照できる既存UIがない状態から、配色の設計・入力UIのパターン・7種すべての画面を、要件定義と並行しながらつくっていきました。
多くて、複雑で、現場は長年Excel。
帳票は7種、しかも1枚あたりの項目が多い。コンテナ通関予定表にいたっては50項目を超えます。素直に「ラベルと入力欄」を並べるだけでは、どこに何を入れればいいのかが、すぐに分からなくなります。
そして現場は、長年 Excel で業務を回してきました。操作感を変えすぎれば、電子化しても使われません。新しくすることと、慣れた操作を壊さないこと。その両方が要りました。
加えて、仕様は動きながら固まっていきます。毎週の先方レビューで決まっていくため、動く画面で認識を合わせる必要がありました。作り手も複数人、AIも併用する。放っておけば、色も余白もばらけていきます。
考えたこと、決めたこと。
確定していない仕様は、勝手に埋めませんでした。分からないところは「？」を残したまま、つくって・見せて・ずれを直す往復で、少しずつ輪郭を出していく。デザインが、要件定義そのものを前に進める役割も担っていました。
読みやすさから、配色を決める。
コーポレートグリーンを起点にしつつ、明るい緑を本文に使うと読みにくい。その一点から配色を組み直しました。本文は深い緑を基準色に、明るい緑はボタンなどの操作にだけ使う。ステータスや帳票の種類にも意味のある色を割り当て、すべてを1つのトークン（design tokens）で一元管理しています。
入力の性質で、UIを選び分ける。
OS標準の select は全廃しました。候補が多い選択は検索付きのプルダウンに、少数の二択・三択はセグメントに、複数選択はチェック式に。日付は横タイムラインで、金額は記号を前に置く。「ラベル＋入力欄」の単調な羅列を避け、入力の性質に合わせてかたちを選ぶ、という指針を立てました。
Excelの操作感を、残す。
コンテナ通関予定表は、あえてセルを直接編集できるグリッドにしました。新しさよりも、現場がそのまま乗り換えられることを優先した判断です。出航後に分かる「空箱・サンプル品」を後から行に足せる導線も、実際の運用に沿って設計しました。
決めたことの、裏側で捨てたもの。
最初は、項目を素直に並べたプロトタイプをつくりました。50項目を超える帳票では一覧性が落ち、どこに何があるのか追えない。つくってみて分かったことです。そこから、3つを手放す判断をしました。
-
モダンな見た目を捨てて、移行コストを取った。
コンテナ通関予定表は、あえてExcelのようなセル編集のグリッドにしました。いまのWebアプリらしい見た目ではありません。それでも、長年Excelで回してきた現場がそのまま乗り換えられることを優先しました。
-
スマホでの操作性を捨てた。使われ方を確かめたうえで。
セル編集のグリッドは、画面が狭くなるほど扱いにくくなります。ただしこの帳票が使われるのは事務所のPCで、スマホで入力する運用は想定されていない。何も考えず落としたのではなく、使われ方から逆算して切った判断です。
-
担当者ごとの項目を、つくらなかった。
「この担当ならこの項目も要る」という要望はありました。ただ人ごとに項目を足していけば、共通の型は崩れます。項目は増やさず、備考欄で補う運用に寄せてもらいました。統一を守るために、個別最適を断っています。
7つの帳票を、ひとつの設計言語に。
帳票は7種、それぞれに一覧・新規・編集・詳細の画面があります。これらを別々につくるのではなく、共通のレイアウトに集約し、帳票ごとの違いだけを宣言するかたちにしました。1つの設計を直せば、すべての帳票に効く。一覧・詳細・フォームを合わせると90を超える画面が、同じデザイン言語の上に載っています。
帳票には「履歴」と「承認」もついてまわります。保存するたびに版（リビジョン）が積み上がり、過去の版は閲覧のみ・巻き戻しはしない。監査の観点から、そのルールを画面で明確にしました。承認は、申請の経路をステッパーで、いまどこまで進んだかをタイムラインで見せています。
レビューの往復を、プロトタイプ自体に組み込む。
仕様が動きながら決まっていくこのプロジェクトでは、毎週のレビューをどれだけ滑らかに回せるかが要でした。そこで、フィードバックをやり取りするための機能を、プロトタイプそのものに組み込みました。画面の右下からいつでも「気になった点」を送れて、送られた内容はページのURL付きで一覧化され、開発側とクライアントが同じ場所で双方向にコメントできます。
「答えを先に埋めず、つくって・見せて・ずれを直す」。ふだん大切にしている進め方を、ツールの側から支える仕掛けです。この機能も、企画とUI設計はわたしが行い、実装はAIに書かせて用意しました。（投稿やコメントは Slack にも流れ、開発の会話に自然に乗ります。）
進め方と、自分の担当。
7種の帳票を、突き合わせる
性質の違う帳票を並べ、共通化できる型と、帳票ごとに残すべき違いを、レビューを重ねて整理しました。
読みやすさを軸に、色を体系化する
本文・操作・ステータス・帳票種別の色を意味づけし、トークン（SSOT）として一元管理しました。
ネイティブselectを、全廃する
入力の性質でUIを選び分ける指針を立て、検索付きプルダウン・セグメント・タイムラインなどに置き換えました。
帳票7種の全画面を、共通化して設計する
一覧・新規・編集・詳細に加え、承認とリビジョンの体験まで、90超の画面をひとつの言語で設計しました。
一貫性を、仕組みで守る
禁止パターン集とレビュー手順を用意し、担当が一人でも、複数人でも一貫性が崩れない体制にしました。
つくって、見せて、確かめながら。
本システムは、要件定義と並行するプロトタイプとして進めました。毎週のレビューに動く画面を出し続けたことで、認識のずれによる手戻りを小さくできたと感じています。参照できるUIがない状態から、7種の帳票を含む90超の画面が、ひとつの設計システムの上にそろいました。
いちばん難しく、いちばん手応えがあったのは、「新しくすること」と「現場の操作を壊さないこと」のあいだに線を引くことでした。Excelの操作感を残すか、独自のUIに寄せるか。その都度、対話で決めていく。答えを先に埋めず、つくって・見せて・直すを重ねる。ふだん大切にしている進め方が、そのまま生きた仕事でした。