最初からXLSXで出すどうせExcelで開くのだから
データ出力といえばCSVが定番だ。だが役所のデータをCSVで出すと、先頭のゼロが消え、コードが日付に化け、文字が壊れる。そして利用者は、結局それをExcelで開く。ならば最初からXLSXで出せばいい。NGWの出力はXLSXにした。文書管理シリーズ第6回。
CSVは、いちばん無難で、いちばん罠が多い
システムからデータを出す、というと、まずCSVが思い浮かぶ。どんな環境でも開ける、いちばん無難な形式だ。だが、役所のデータをCSVで出すと、無難どころか、罠だらけになる。
役所のデータは、CSVが苦手とするものばかりでできている。コード値は「01」「008」のように先頭にゼロが付く。電話番号も、受発番号も同じだ。ところがCSVをExcelで開くと、先頭のゼロは容赦なく消える。「1-2-3」のような区分は、勝手に日付へ化ける。文字コードがひとつずれれば、氏名の漢字がまるごと文字化けする。CSVは値をただ並べただけの、型も書式も持たないテキストだから、開いた側のアプリが「よかれと思って」解釈し直してしまうのだ。
どうせ、Excelで開く
そして——ここが肝心なのだが、CSVを受け取った職員は、ほぼ間違いなく、それをExcelで開く。集計するにも、加工するにも、印刷するにも、Excelが使われる。CSVは通過点にすぎず、最終的な行き先はいつもExcelなのだ。
だとしたら、話は単純になる。行き先がExcelだと分かっているなら、最初からExcelの形式(XLSX)で出せばいい。 わざわざ型も書式も落としたCSVにして、開いた先で壊れるのを、利用者に直させる——その回り道に、意味はない。
NGWの出力は、XLSXにした
そこでNGWは、データ出力をXLSXで行うことにした。
——といっても、これはつい最近の話だ。長らくNGWも、データはCSVで出していた。職員から「CSVで出してください」と頼まれるのが常で、こちらもその要望どおりに応え続けてきたからだ。だが、そうやって出したCSVが行き着く先は、結局いつもExcelだった。だったら最初からXLSXで——と踏み切ったのは、ごく最近のことである。
サーバ側で PHP_XLSXWriter というライブラリを使い、本物の .xlsx ファイルを組み立てて渡す。CSVと違って、XLSXなら最初から、こういうことができる。
- 型が保たれる … 「008」は「008」のまま。先頭ゼロも、コードも、日付への誤変換もない。文字列は文字列として出せる。
- 文字化けしない … 文字コードの取り違えで氏名が壊れる、という事故が起きない。
- 書式まで整えて渡せる … 見出し行、列幅、罫線、シートの分割——開いてそのまま読める・使える状態で届く。簿冊目録も、背表紙も、この形で出している。
利用者は、ダウンロードして開くだけでいい。整え直す手間も、壊れた値を直す手間も、要らない。
手間は、作り手が引き受ける
もちろん、XLSXを組み立てるのは、CSVを一行吐くより手間がかかる。列幅を決め、書式を指定し、シートを構成する。その手間は、作り手であるNGW側が引き受ける。
だが、その一度の手間で、何十人・何百人という利用者の「開いて、直す」手間が、まるごと消える。これは印刷を全てPDFにした話と、まったく同じ思想だ。出力の最終形をこちらで固めておけば、受け取る側は、迷わず使える。作り手が一度苦労して、使い手が毎回ラクをする——その配分こそが、正しい。
AIとの協働作業での学び
「とりあえずCSV」は、作り手にとっていちばんラクな逃げだ。だが、そのラクは、開いた先で値が壊れるという形で、利用者へ静かにツケが回る。大事なのは、データが最終的にどこで開かれるかを見据えて、出力の形を決めることだ。
役所のデータは、どうせExcelで開かれる。ならば最初からXLSXで。先頭のゼロひとつ守るために、出力の形式ごと変える。地味だが、こういう「利用者が直さなくて済む」の積み重ねが、道具の信頼をつくっていく。
(文書管理シリーズ第6回。前回は紙印刷を全てPDFに。)