届いたのは不具合の報告ではなく、給与明細の設計図だった

9月12日の朝に、Eから届いたのは不具合の報告ではありませんでした。給与明細をこう作り直したい、という1枚の図です。手で線を引いて、どの数字をどこに置くか、どの行を大きくするかまで書いてありました。彼は創業のころから一緒にやっている仲間で、画面についての報告はこれまでもたくさんくれています。ただ、報告と設計は別のものです。

そのときの給与明細を書きます。1枚の表で、行が23ありました。基本給があって、手当がいくつか続いて、税の行があって、社会保険の行があって、いちばん下に差引支給額が来ます。並び順は、私たちが計算している順番そのままでした。計算の順に上から下へ置けば、読む人も同じ順に読むだろうと考えていたのだと思います。少なくとも、なぜこの順なのかを誰かに聞いた覚えがありません。

Eの図は、23行を3つのかたまりに分けていました。いちばん上は、受け取る金額ひとつだけです。ほかの数字より大きい字で置いて、その周りには何も入れない。2つ目が、その金額の元になった支給の内訳。3つ目が、差し引かれたものです。図の余白に、理由が短く書いてありました。最初に見るのは1つの数字だから、と。

受け取る人が明細をどう読むかも、彼は具体的に書いていました。多くの人は立ったまま、数秒で見る。まず自分の口座に入る金額を探して、それが先月と同じかどうかを確かめる。違っていれば、そこで初めて内訳を読む。写真に撮って手元に残す人も多い。彼の図の上半分は、その数秒のために空けてありました。

私たちは、明細を会社の側の書類として作っていました。会計の担当者が見て、金額が合っているかを確かめるための紙です。だから計算の順に並んでいました。実際には、この紙をいちばん多く読むのは、受け取る本人です。誰の書類かを取り違えたまま、私たちは行の並びだけを整えていたことになります。

差し引きのところにも、彼の指摘がありました。税の行と社会保険の行が、手当のあいだに散らばっていたのです。加えて、本人から差し引く分と、会社が別に負担している分が、同じ列に同じ見た目で並んでいました。BPJSのように、事業主の負担と本人の負担の両方がある項目では、これが読み違えのもとになります。

実際、テストで配った明細を見た人から、この金額も自分から引かれているのか、という質問が来ていました。引かれていません。会社が別に払っている分です。計算はどこも間違っていません。間違っていたのは、その数字が何なのかを示すための置き方のほうでした。数字が正しいことと、正しく伝わることは別です。

9月19日に直した形を書きます。3つのかたまりにして、A4の表をやめ、A5の紙1枚に収まるようにしました。会社が負担している分は3つ目のかたまりから外して別の場所に移し、あなたの支給額からは差し引かれていません、と1行添えてあります。行数そのものは減っていません。減らしたのは、最初の数秒で読む必要のある行の数です。

ここでひとつ断っておきます。私は税理士ではありません。今回変えたのは見せ方だけで、税額や社会保険料の計算そのものには手を入れていません。明細に載せる項目や、それぞれの金額の扱いは国の制度で決まっていますので、そこは必ず専門家に確認してください。

仕組みの側も直しました。私たちが用意していた報告のフォームには、不具合の内容、という欄しかありませんでした。壊れているところを書いてください、という形です。提案を置く場所も、こう作りたいと書く場所もありません。Eは結局、フォームを使わずに図を送ってきました。私たちのフォームは、彼のいちばん価値のある仕事を受け取れない形をしていた、ということです。いまは提案の欄を足してあります。

Eのことを少しだけ書きます。彼は創業のころから一緒にやっているインドネシア人の仲間で、ジャカルタではなく、ここから少し離れた町にいます。そこで実際に配られている給与明細を、彼は見ています。私が見ているのは、役所の仕様書と自分たちの画面です。同じ製品を作っていても、手元にある現物が違います。

依頼と設計は、持ってくる側の負担がまるで違います。直してほしい、なら、困っていることを書けば済みます。こう作りたい、を持ってくる人は、先に自分で考えて、そのうえで断られる可能性を引き受けています。だからこちらが返すべきなのは、早い返事と、採らなかったときの理由です。今回は採りました。届いた図のとおりに作って、どこを変えたかを本人に送りました。