本日、青色申告会の相談業務の最終日でした。

前回と同じく、相談者は紙の申告書を持ってきて、税理士がそれをチェックします。

手計算なのでミス多発・・という記事を前に書きました。

今回もミスが何度か・・。

そもそも電卓をたたくのも遅いし、手計算は本当に私にとって苦手なことなんだなと痛感しました。

やっぱり手書きの申告書は作るのもチェックするのも大変

今日はちょっと視点を変えて青色申告相談業務で見えてきた業務プロセスの疑問点を書いてみます。

なんで同じこと何度もやっとる?

青色申告会を批判するわけではありませんが(^^;

一番気になったのが

「なんで同じこと何度もやっとる?」

です。

例えば、こんな事例です。

相談者は途中まで下書きした申告書を持ってきます。(この時点で最後まで完成させないのであればあまり意味なし)

税理士(私)は、数値をチェックし、間違いがあったら直し、手計算で合計を集計します。

(本来、どうせ電子申告送信するのでこのときパソコンに打ち込んでしまえばいいのですが)

私が集計した下書きを、今度は職員さんが手計算でチェックし(ここで間違いが結構ある)、申告書に清書し、それをもう一人の税理士さんが電子申告用にまた入力して電子送信をかけます。

ちょっとまてよ、何度同じ作業が発生してるんだ?

と考えてみたら4回(①相談者が自分で下書き→②私が数値チェック・下書き追加・集計→③職員さんが数値チェック・清書→④もう一人の税理士が電子申告用に入力)

発生していました。

その業務プロセスは最短か?

今回の業務プロセスの件は極端かもしれませんが、普段の業務でも

「この業務プロセスは最短か?」

を考えることは重要です。

特に、同じ作業(入力など)が発生していないか、確認することが大事です。

書き込み・入力は1度で終わらせなければなりません。

今回の例でいけば、相談者は相談したいことと、申告書に必要な資料を持ってきていただければ税理士がその場で電子申告用の入力を行えます。

手計算でやるよりはずっとミスが少ないはずです(言い訳ですが)。

また、何も手書きでの申告書を作成してわざわざ職員がそれを清書する意味はないはずです(電子送信するのですから)。

入力・チェックを分けるにしても最短で2プロセスで済むはずです。

業務の見直し(ライブラリ・テンプレートの活用)

以前、「最速の仕事術はプログラマーが知っている」という本を紹介したときに、

同じことを2度以上行わないためにも業務に関するライブラリ・テンプレートを活用しましょうという文章を引用しました。

[読書日記]最速の仕事術はプログラマーが知っている Programmer’s SPEED HACKS 清水亮

業務プロセスをライブラリ化・テンプレート化することはただ単に

電卓を早く打つようにする、ソフトに早く入力する、

といった力業ではなく業務そのものを見つめ直すきっかけとなります。

「なんでこんなに時間がかかるんだろう・・」

と思った時こそ業務効率化のチャンス。

重複した作業がないか、ライブラリ・テンプレートを活用できないか、見直すきっかけとしましょう。

まとめ

根がせっかちなのか、青色申告会の相談業務で感じた業務プロセスの疑問を書いてみました。

業務にどっぷりと浸かる前に考えなければいけない業務プロセスの最短化。

これをきちんとできるかどうかでその後の時間の余裕が全然違ったものとなるでしょう。

編集後記

最近仕事の比重があがって好きな事ができていないなあ、と反省。

週末は、好きなアクセサリー作り再開したいと思います。

« »