Webサイトのお助け隊

請求書と見積書を、いつまで表計算ソフトのファイルを複製して作り続けるのか。番号を振り間違える、去年のひな形が混ざる、担当者のパソコンにしか最新版がない。この状態を解消したくてWebでの発行を検討し始めるものの、市販のクラウドサービスは自社の書式に合わせられず、かといってフルスクラッチは高い。小規模な事業者からの相談で一番多いのがこの中間の悩みです。実際に作ってみると、費用を左右するのは帳票のデザインではなく、入力画面をどこに置くかという一点でした。

作るのは4つの部品

請求書発行の仕組みは、どんな規模でも同じ4つに分解できます。データを入力する画面、入力した内容を保存する場所、帳票の形に整えて出力する処理、そして相手に渡す経路です。この4つのうち、既存の仕組みに乗せられるものがいくつあるかで見積りが決まります。

たとえば、宛名・件名・明細・金額を持つデータを保存するだけなら、WordPressのカスタム投稿タイプとカスタムフィールドで足ります。新しくテーブルを設計する必要が出るのは、明細行を可変で持ちたい、番号の採番を厳密に管理したい、過去の版を残したい、といった条件が入ってからです。独自テーブルを足すときの設計はWordPressに独自テーブルを足すときの設計と$wpdbの使い方で書いています。

出力方式は3つ、選ぶ基準は「書式をどこまで再現するか」

台紙に差し込む方式は、既にある紙の書式を1ミリも変えたくない現場と相性が良い一方、明細が1行増えるごとの座標計算を自分で書くことになります。逆にHTMLから生成する方式は行数の変動に強く、代わりに書式の見た目を作り直す作業が発生します。3つ目は実装が最も軽く、社内でしか使わない見積書なら十分に成立します。どれが正解かではなく、既存の書式をどこまで再現する必要があるかで決めてください。

費用を決めるのは、入力画面をどこに置くか

出力よりも先に決めるべきなのが入力画面です。ここには3つの置き場所があります。

一番上を選べるなら、それが一番安く、一番早く動きます。一覧画面も検索も権限管理も、WordPressが最初から持っているものをそのまま使えるからです。「管理画面に見積書という項目が増えて、そこから作る」という形は、使う人にとっても学習コストがほぼありません。

前提が崩れた案件

請求書と見積書の作成システムを、既存のWordPressサイトに載せる案件を受けたことがあります。当初の見積りは「既に入っているプラグインを改修する」という前提で組んでいました。ところが作業を進めた後で、入力画面が実はプラグイン側ではなく、親テーマのカスタム投稿機能として実装されていることが判明します。プラグインからは上書きできない構造で、見積りの前提そのものが崩れました。

この案件から得た教訓ははっきりしています。既存システムを改修する仕事では、着手前に「その機能がどのレイヤーで実装されているか」を必ず特定することです。プラグインなのか、テーマなのか、コアに手が入っているのか。この調査は工数として見積りに織り込むべきもので、無料の下調べで済ませようとすると今回のように後から破綻します。

そしてもう1つ、制約が見つかったときは、可能な限り早い段階で追加見積りとして提示することです。作業の終盤に切り出したため、依頼側は予算的にも期間的にも判断ができなくなりました。進行中は確認用のテストURLとログイン情報を常時共有し、未実装の項目を一覧で見せ、設計図の画像を渡す。この3つは実際に効きました。ただし、テスト環境のログイン情報が平文でやり取りされる案件では、納品後にパスワードを変更してもらうところまでを手順に入れてください。

同じ形式のページを増やせる形にしておく

帳票に限らず「同じ書式のページを何枚も作りたい」という要望に対しては、単発でページを作るのではなく、固定ページのテンプレートとして作るのが正解です。試験結果の表を掲載するページを作った案件では、テンプレート化したことで、以後は依頼者自身が同じ形式のページを何枚でも増やせるようになりました。1回の作業で、その後の発注が不要になる形に持っていける典型例です。

このとき効いたのが、カスタムフィールドの初期値です。ページ内に必ず載せる必要のある注意文を、Advanced Custom Fields の description フィールドとして持たせ、テンプレート側に正式な文言を初期値として設定しました。新規ページを作れば、その文言が最初から入っている状態になります。請求書や見積書でいえば、振込先、支払期限の但し書き、登録番号といった毎回同じ内容がここに当たります。人が毎回コピーして貼る運用にすると、いつか抜けます。

PDFをページ内に表示する要件は、PDF Embedder のようなプラグインと [pdf-embedder] ショートコードで解決できました。PDFを画像に変換してページに貼るという案も検討しましたが、不要でした。着手前の時点では実現できるか確証がなかったため、「PDFのまま扱えるか確認します。難しければ画像化して掲載する形でも対応できます」と代替案をセットで伝えています。結果的に使わなかったとしても、この伝え方をしておくと双方のリスクが下がります。

渡し方と、見られたくないものの守り方

発行した帳票をWebで渡す場合、URLを知っている人が誰でも開ける状態になっていないかを確認してください。機密資料のページを作った案件では、次の5点をセットで実装しました。noindex,nofollow の指定、ヘッダーとフッターの非表示、右クリックとコピーの禁止、WordPressのパスワード保護ページ、アップロードできる形式をPDFに限定すること。この組み合わせで「簡単には持ち出せないページ」として成立します。

ただし限界も正確に伝えるべきです。右クリックやコピーの禁止は oncontextmenu や oncopy による簡易なJavaScript制御にすぎず、開発者ツールを開かれれば無効化できますし、JavaScriptを切られれば効きません。スクリーンショットも防げません。Web上で完全な複製防止は技術的に不可能です。

実務上もっと重要なのは、PDFファイル自体の直URLです。埋め込みプラグインはPDFをサーバー上のアップロードディレクトリに置くため、ページにパスワード保護をかけても、ファイルのURLを知られれば素通しで開けます。本当に見せたくないものを扱うなら、.htaccess でアップロード先への直接アクセスを制限するところまでを設計に含めてください。会員ごとに見せる帳票を変えたい場合の考え方は会員限定サイトの作り方、会員管理・決済・閲覧制御をどう組むかで扱っています。

請求書番号は、下書きを1つ消しただけで飛びます

作った直後は気づかず、半年後に問題になるのが番号の採番です。請求書番号を投稿IDから生成すると、下書きを作って消しただけで番号が飛びます。年度をまたいだときに連番をリセットするかどうかも先に決めておく項目です。もう1つ、発行済みの帳票を後から編集できる仕様にすると、相手に送った内容と手元のデータが食い違います。発行した時点の内容を別に保存して固定するか、編集したら新しい版として残すか、どちらかを選んでください。

既に古い業務システムで請求書を発行していて、それを置き換えたいという相談も少なくありません。その場合は、まず現行システムのどこにデータがあるかを確認するところから始まります。判断の材料はEC-CUBE・CakePHP・Movable Typeの古いシステム、延命か作り直しかにまとめました。

よくある質問

市販のクラウド請求書サービスではだめですか

書式が標準的で、社内の運用も特殊でないなら、そちらのほうが安く確実です。自作を検討する価値があるのは、既存の書式をそのまま使う必要がある場合、既に持っている顧客データや案件データと連動させたい場合、そして帳票の発行が別の業務の一部として組み込まれている場合です。単に帳票を作るだけなら、作らない選択が正解になることもあります。

既存のWordPressサイトに載せられますか

載せられます。ただし、そのサイトが独自テーマや独自プラグインで作られている場合、機能がどこに実装されているかを先に調べる必要があります。ここを飛ばすと、改修できる前提で進めた作業が途中で止まります。調査の工数を最初に確保しておくことをお勧めします。

PDFで出すのと、印刷できれば十分なのはどちらですか

相手に送るならPDF、社内で回すだけなら印刷で足ります。判断材料は、受け取る側がファイルとして保存する必要があるかどうかです。保存が必要ならPDF化を実装し、その場で確認して押印するだけなら印刷用のCSSを整えるほうが早く安く済みます。

作った後、自分たちで書式を変えられますか

どこまでを変更対象にするかを最初に決めておけば可能です。文言や振込先のように文字列だけを変える範囲は、カスタムフィールドや設定画面に出しておけば管理画面から変更できます。一方で、罫線の位置や項目の並び順まで自由に変えられるようにするのは、それ自体が帳票デザイナーを作る仕事になり、費用の桁が変わります。