請求書・見積書をクラウドでかんたん作成。販売管理まで効率化できる「board」

boardを使った業務設計・運用設計のポイント

業務の進め方や請求書の扱い方は、会社ごとにさまざまです。そうした中でboardを使い始めると、これまでとは異なる業務の進め方が前提になっていると感じられる場面があるかもしれません。

本記事では、boardの具体的な操作方法ではなく、どのような業務の考え方や業務設計を前提に、このツールが作られているのかを整理していきます。

boardは、見積もりから受注、納品(サービス提供)、請求に至るまでの業務を1つの流れとして管理し、その結果として請求書が発行される状態を作るためのツールです。この前提を理解しているかどうかで、boardの使い勝手や評価は大きく変わってきます。

この記事では、まず「なぜ請求書発行を起点に業務を組み立てると苦しくなりやすいのか」を整理し、その上で、業務を「点」ではなく「線」として捉え直す視点を紹介します。最後に、その考え方を前提として、boardがどのような業務設計を想定しているのかを見ていきます。

なお、こうした業務を流れとして捉え直す考え方や、日々の実務に落とし込むための整理方法については、拙著『業務設計の教科書新しいタブで開く』でも詳しく解説しています。本記事で扱う内容は、その一部を請求業務の文脈に当てはめたものと考えていただくとわかりやすいかもしれません。

boardをこれから使いこなしていきたい方や、現在の運用に違和感を持っている方にとって、日々の業務を見直すヒントになれば幸いです。

執筆者:武内 俊介
税理士、業務設計士、リベロ・コンサルティング代表
金融のシステム企画部門、会計事務所、数社のスタートアップのバックオフィスを経て、独立。
既存の業務やシステムの使用方法を徹底的にヒアリングしながら、最適な業務フローとシステムの構成を設計し、業務からシステムまで再構築の実績多数。
業務設計の支援を手がけるリベロ・コンサルティング代表をメインで活動中。
*当記事は寄稿記事です。

目次

  1. なぜ請求書発行を起点にすると業務が苦しくなるのか
  2. 業務を「点」ではなく「線」で捉え直す
  3. boardが前提としている業務設計と運用の考え方
  4. おわりに

なぜ請求書発行を起点にすると業務が苦しくなるのか

多くの企業では、請求書発行は締め日を基準に動く業務として位置づけられています。締め日が近づいてから、請求対象となる契約を確認し、納品の状況を整理し、必要な情報を集めた上で請求書を作成する。この進め方自体は、決して特殊なものではなく、一定の合理性を持った方法として広く採用されています。

1〜7の工程に分けて、請求書発行を起点にした業務がどのようにして負のループを生んでいるか図示。

しかし、このように業務を組み立てると、請求書発行は「その月にやるべき作業」として位置づけられ、情報収集や確認は締め日のタイミングで行われることになります。見積もりや受注の段階でどのような条件だったのか、どこまで納品が進んでいるのかといった情報は、請求書発行の段階でまとめて確認するという前提で業務が回っています。

その結果、作業のピークは締め日付近に集中します。見積書や契約書、作業報告など、必要な情報を関係者から集め、内容を突き合わせ、金額や条件を確認する作業が短期間に一気に発生します。これは請求書発行に向けて情報をそろえて、形にしていく前提である以上、ある程度は避けられない面もありますが、この進め方を続けていると、次のような問題が起きやすくなります。

たとえば、締め日になってから確認に着手するため、見積もり時の条件と実際の納品内容が一致していないことや、数量や金額にズレが生じていることなど、さまざまなミスや不足が、その段階になって初めて明らかになります。こうしたミスや不足は、実際にはもっと前の業務の段階で発生していますが、確認のタイミングが締め日以降に置かれているため、問題に気付くのも必然的にその段階になります。

業務がこのような経過をたどると、締め日から請求書の発行日までの限られた期間の中で、確認と修正対応に追われることになります。本来であれば、作成した請求書を落ち着いてチェックする時間を確保したいところですが、その余裕がなく、確認が不十分なまま発行してしまうケースも少なくありません。請求ミスが発生すると、再発行や月次決算のやり直しなどの対応に追われることになり、対応に追われているうちに次の締め日が近づいてきます。こうした経過をたどって、同じ状況が繰り返されるという負のループに陥っている企業も少なくありません。

問題解決を先送りにするリスク

もちろん、そのような場合でも、経験豊富な担当者であれば、限られた時間の中で状況を把握し、過去の知見を元に一定の対応ができるかもしれません。しかし、それは個人の経験や判断力に強く依存した状態です。誰が担当しても同じように回せる業務になっていなければ、担当者の変更や不在がそのまま業務リスクになります。

また、取引件数や請求件数が少ないうちは、この進め方でも問題が表面化しないこともあります。しかし、事業が成長し、扱う案件や請求の量が増えてくると、締め日直前に発覚するミスや不足の件数も増えていきます。確認や修正にかかる時間が膨らみ、チェックに割けるリソースはさらに削られます。その結果、請求ミスが頻発し、業務全体が不安定になるリスクが高まります。

従来、多くの企業では、このような状況に対処するために、「対応する人員を増やす」という施策が選ばれてきました。しかし、人員を増やす対応はコスト増につながりやすく、加えて近年では、そもそも十分な人材を確保すること自体が難しくなりつつあります。

この問題を本質的に解決するためには、請求書を発行するという「点」だけを見るのではなく、見積もりから受注、納品、請求に至るまでの業務を1つの流れとして捉え直す必要があります。

業務を「点」ではなく「線」で捉え直す

ここまで見てきた業務の進め方では、請求書発行を起点に業務を組み立てているため、締め日前後に業務が集中し、ミスや手戻りが起きやすくなります。ここで問題になるのは、「ミスが起きること」自体ではありません。見積もりや受注、契約内容の取りまとめが煩雑になりやすいのは、お客様を相手にする業務である以上、一定程度は想定しておく必要があります。また、情報のズレや抜け漏れが発生することも、業務の性質上、完全に防ぐことは難しいものです。

問題の本質は、それらのズレやミスに「いつ気付けるか」という点にあります。たとえば、見積書と納品書の数字に差異があることに気付いた場合、どちらの数字が正しいのかを営業担当者に確認したり、出荷データを洗い直したりするという追加の業務が発生します。このような対応によって業務量が増えると、締め日から請求書発行日までの短い期間に負荷が集中します。その結果、内容のチェックや担当者自身による最終的な見直しにリソースを割くことができず、発行段階での新たなミスも発生しやすくなります。問題はミスの有無ではなく、確認作業が業務プロセスの最終盤で行われている点にあるのです。

ここで一度、請求書発行という業務を「どのような視野で捉えるか」という観点から整理してみましょう。

業務の流れを点で見た場合と線で見た場合の上下2段に分け、2つの流れがどのように異なるのかを図示。

まず、請求書発行を単体の業務、いわば1つの「点」として捉える場合です。この見方では、視野は請求書を作成する作業に限定されます。必要な情報さえそろっていれば、それらを集計し、書類として出力するだけの業務であり、請求書発行そのものはそれほど難しい作業ではありません。

一方で、業務を「線」、すなわち見積もりから受注、納品、請求に至るまでの一連のプロセスとして捉えてみると、どうでしょうか。請求書に記載される内容は、どこで決まり、どの段階で確認されるべきなのか。見積もりの段階で決めた条件が受注時に正しく引き継がれているか、納品やサービス提供の過程で当初の前提に変更が生じていないか。こうして視野を大きく広げることで、「請求書を発行する」という作業の前に、確認しておくべきことがたくさんあることがわかります。

請求書発行の作業は、これら一連の業務プロセスの最終工程に過ぎません。業務プロセス全体の中で見れば、請求書を作ること自体が価値を生むわけではなく、それまでの業務内容を確認し、結果を確定させる役割を担っているだけです。だからこそ、改善すべきは請求書発行という「点」ではなく、見積もりから請求に至るまでの「線」、すなわち業務プロセス全体であり、「締め日を迎える前に、どこまで整理と確認を終えられているか」が重要なのです。

次は、この考え方を前提に、boardがどのような業務プロセスを想定して機能設計されているのか、そして日々の運用の中で、どのようにこの「線」の考え方を実践していけるのかを見ていきます。

boardが前提としている業務設計と運用の考え方

ここまでに述べてきたとおり、請求書発行をめぐる問題の多くは、発行作業そのものではなく、その前段階にある業務プロセスの組み立て方に起因しています。その問題の根幹には、見積書、納品書、請求書など1つの受注・契約の中で複数の書類が存在し、それらを別々に作成したり、管理したりしていることがあります。

案件と書かれた1つのフォルダーの中に見積書・発注書・納品書・請求書・領収書が含まれている様子を図示。

boardは、見積書や請求書といった書類単位ではなく、1つの受注・契約を表す「案件」という単位で情報を管理する設計になっています。一般的には、見積書を作るところから取引が始まるケースが多いと思いますが、boardでは見積書の作成も「案件」という業務プロセスの一部として位置づけられています。そのため、boardの画面には「見積書を作成する」というボタンがありません。あるのは「案件登録」という入口のみで、案件に紐づく形で見積書や請求書などの書類が一連の流れとして扱われます。書類ごとに内容を作り直すのではなく、案件に登録された情報を各工程で使い続ける設計になっています。

私も初めてboardを触ったときは、「見積書を作りたいだけなのに、なんでこんなに面倒な構造になっているんだ」と感じたことを今でも覚えています。しかし、複数の案件を作り、納品書・検収書を出力し、月末に請求書を作成するようになって、ようやく「案件」という概念の意味が理解できました。boardでは、「案件」という上位概念の下に書類が存在しています。案件のフェーズに応じて必要になる書類は、ある程度共通化されているので、都度作るのではなく、「あらかじめ作っておいたものを発行する」という考え方なのです。

もちろん、これまで見てきたように、見積もり、契約、納品などの過程で内容が変更されることも頻繁にありますが、明細の内容を変更した際は「書類単体で保存」か「他の書類に反映」かを選んで保存することができるようになっています。つまり、boardではそもそも「請求書だけを作る」ということは想定されておらず、見積もり、納品などの結果として、請求書が存在しているという思想が体現された構造になっているのです。

boardの大きな特徴は、見積もりの段階から取引情報を登録し、その情報を受注後、納品、請求へと引き継ぎながら使い続けられることにあります。業務がこのように組み立てられると、「締め日になってから情報を集めて確認する」という状況が起こりにくくなります。

請求書は「作成する」ものではなく「確定させる」もの

業務を1つの流れで捉えると、請求書は新しく「作成する」ものではなく、それまでに管理してきた情報を「確定させる」ものになります。見積もりや受注、納品の段階で必要な確認が済んでいれば、請求書発行時に行う作業は、最終確認と確定だけになります。結果として、締め日直前に確認作業が集中することもなくなり、チェックに十分な時間を確保しやすくなるのです。

こうした考え方は、商談や案件といった単位で業務を管理するSFA/CRMの発想に近いとも言えます。ただし、boardは大企業向けのSFAなどとは異なり、中小企業の実態に合わせて、複雑な設定や運用を必要とせず、「案件」という枠組みの中で書類と業務の流れを自然につなげられる点に特徴があります。

このように、boardは業務プロセス全体の流れを意識し、最終的に必要となる請求書から逆算して業務を組み立てていくという考え方を、日々の実務の中で無理なく実践できる形に落とし込んでいます。

おわりに

本記事で見てきたように、boardは見積もりから受注、納品、請求に至るまでの業務を1つの流れとして捉え、その結果として請求書が自然に発行される状態を作るためのツールです。

請求書発行に課題を感じている場合、つい「入力を楽にする」「チェックを減らす」といった操作面の改善に目が向きがちです。しかし、本当に見直すべきなのは、請求書を作る直前の作業ではなく、それまでの過程にある業務の組み立て方そのものかもしれません。

業務を「点」ではなく「線」として捉え、締め日を迎える前に整理や確認が進んでいる状態を作ることができれば、請求書発行は特別なイベントではなく、普段の業務の延長として位置づけられます。boardは、そうした業務のあり方を前提に設計されています。

現在の運用に違和感を持っている方や、これからboardを使いこなしていきたいと考えている方は、ぜひ一度、業務全体の流れという視点から、自社の請求業務を振り返ってみてください。その観点を持ってboardを活用することで、日々の業務の進め方が変わっていくはずです。

一覧に戻る
90秒でわかるboard
請求業務でお困りの方必見!
\ 継続率99.5%の支持 /
詳しい情報を見る

ユーザーの声

一元的に管理できるようになり、従来の請求業務にかかっていた時間を45%短縮

ビューロ・ネットワーク税理士法人様の事例より

ITが得意ではない人でも使いやすく、すぐに慣れて業務を任せることができた

法律事務所LEACT様の事例より

boardのヘルプページは充実しているので、困ったときにすぐに自己解決できますし、サポートに問い合わせても返信が早く、内容も丁寧かつ的確です

辻・本郷 ITコンサルティング株式会社様の事例より

会計ソフトに付属している請求書機能よりも、boardを使った方が請求・会計の連携がスムーズになると感じています

合同会社プロースト様の事例より