2016年も「契約書フロー」や「稟議書フロー」が根強い人気

今年最後の投稿です。2016年も毎週欠かさず業務テンプレを配信することができました。これもひとえに読者の皆様からの「応援メッセージ」や「いいね」のおかげです。

はい。来年(2017年)も頑張ります。

さて当ブログでは、これまで過去7年間に渡る合計500本以上の記事(と800近くのテンプレート)を公開していますが、今年2016年は、どんな記事が良く読まれたのでしょうか? 早速、今年一年間のアクセスログを調べてみました。

<トップ5記事>

やはり「契約書」や「稟議書」のオンライン承認(ペーパレス化)は根強い人気テーマの様です。(注:日本語版の調査結果です)

今ならどう書く?「契約書承認フロー」

しかし、この記事、すでに6年も前の記事です。

毎日毎日、業務プロセスを描いている身としては、やっぱり「今なら違うプロセスをお勧めするなぁ」などと思うワケです。(現在、日本語での Google 検索で「契約書 ワークフロー」の検索1位になっているので、「よく読まれる」のは仕方ないのですが。。。)

ということで、今年最後の記事は「契約書承認プロセス」をシンプルに描き直してみたいと思います。

[契約書承認プロセス(2010-11-12)]

政治家や官僚達のワーク・ライフ・バランス


日本も他の先進国と同様、既存の「福祉国家の路線」に限界を感じている。

つまり「行政のスリム化」(簡素な効率的政府)という基本方針については、どの政党も合意するところとなっている。時代の流れには逆らえない。

※ ◆1930年代に起きた倒産の連鎖(世界恐慌)を経て、人類は「単なる自由放任主義」を否定し、大きな政府による「社会保障」を肯定するに至った。 ◆1970年代に起きた経済の停滞(オイルショック)を経て、人類は「福祉国家の非効率」を自覚し、小さな政府による「競争社会」への回帰を容認するに至った。 ◆1990年代以降の企業活動は国境を越え税収確保も困難となり、またインフラ維持や医療費増加もあり、結果として既存の「福祉国家路線」は立ち行かなくなる。


しかしながら「国会における行政効率化の議論」は全くかみ合わない。

たとえば、(1)「ハンコ行政」をやめる、(2)「特殊法人の民営化」を推進する、(3)「健保・年金・所得税などのバラバラ徴収」を一元化する。。。 議論すべき改革の方向性は多種多様だ。しかしどんな方向であっても、大きくなってしまった政府を「小さくする方法」や「小さくする手順」について、合意を形成するのは容易ではないようだ。

その結果、国会議員達は同じような質問を繰り返し、内閣は同じような答弁を繰り返す。

『質問書』は深夜に提出され、『答弁書』は夜中に作成され、『大臣レクチャー』は早朝に行われる。国会自身が「行政の肥大化」を助長させている。彼らの言う「生産性向上」は、もはや寝言でしかない。


国会議員による質問方法


そもそも国会議員の仕事は、テレビ映りの良い「議場パフォーマンス」ではない。

民間に言わせれば、朝9時から夕方まで大臣ほか時給の高い人達を拘束しつづける委員会審議なんぞ、単なる「長時間会議」にしか過ぎない。もし「取締役会」が朝から晩まで開催され、挙げ句の果てに一部の取締役達が「退席アピール」をしているとすれば、投資家達はどう思うだろう?

内閣提出法案や国政全般について正すべき事項があると感じるなら、「質疑」よりも「質問」(質問主意書)をもっと多用すべきだ。そして、(民間のFAQサイトではないが)、質問をするときは過去の質問(FAQ)を参照すべきだ。あえて同じ質問をしたいなら、「FAQ-20161213-01 の答弁内容に変化はないか?」と聞けば良い。そうすれば内閣は「はい」とクリックするだけでよくなる。

「審議時間が短い」とだけ連呼する議員に、「国益」を語る資格はない。(むしろ質問の数をKPIとせよ)

[内閣答弁作成プロセス]

「現場の業務プロセスが見えない」?


2016年秋、日本では『キュレーション・メディア』による「パクり行為」が大きく報道されている。

そもそも「情報を整理する行為」は価値のある作業であり、誰でも整理記事を投稿できる「情報共有サイト」(キュレーション・プラットフォーム)も価値ある存在と言える。しかし、サイト運営会社(東証一部上場企業)自身がクラウドソーシングを通じて記事を量産し、そのアウトソースの中で「パクり」をマニュアル化していた実態が明るみになったのだ。

キュレーション記事の制作プロセス

たしかに、
"当社は、この記事の情報及びこの情報を用いて行う利用者の判断について、正確性、完全性、有益性、特定目的への適合性、その他一切について責任を負うものではありません。"
という免責注記はあった。しかし、当のサイトが「健康や命に関わる記事」を集める情報共有サイトであったため、「著作権侵害」というよりもむしろ「モラル」が問われた形だ。そして、結果としてCEOが「記事制作のプロセスに問題がある」と謝罪する状況になったのだ。

DeNAプレス:CEOからのお詫びとご説明
"他サイトからの文言の転用を推奨していると捉えられかねない点がございました。この点について、私自身、モラルに反していないという考えを持つことができませんでした。(中略)。自分自身として心の底から自信の持てるプロセスを構築していくことを約束します。"

真実かどうかは知る由もないが、おそらくは「本当に業務プロセスが見えていなかった」のだろう。(と信じたい)。では、運営会社が責任をもって記事を書く必要がある場合、どのような業務プロセスを構築すれば良かったのだろうか?

[記事作成プロセス]
「業務フロー設計を試してみたいのですが…」

『プログラミング』の世界においては「唯一の道はプログラムを書いてみること」と言われる。事実、プログラミングを始める時、誰しもが "Hello World" という文字列を表示させるプログラムを書く。これと同様に『モデリング』の世界でも「業務プロセスを描いてみること」はとても大切だ。


以下の業務プロセスは、「メール受信」で開始され、「チャット投稿」で終わる。

そもそも業務プロセスとは、何かの『キッカケ』で始まり、そして幾つかの『工程』が続くものだ。しかし、この例には『チャットに投降する』という処理工程が1つあるだけだ。しかもそれは「コンピュータによる処理」(自動処理)であって「人による処理」は一切ない。(何ということだ!)

[チャット投稿フロー]

「請求データの入力、面倒。。。」

銀行入出金やカード支払などのログが「自動仕訳」されるようになり、ひと昔前と比べて「経理の入力作業」は随分とラクになった。

しかし、特に『売上高』に関して言えば、『入金』のタイミングを待っていたのでは遅すぎる。やはり『請求書』を発行した時点で『売掛金売上』にしたい。。。というか、しなければならない。
  • 2016-11-22: 売掛金 120,000 / 売上高 120,000 = ホームページ制作(A社向け)
  • 2016-12-31: 普通預金 120,000 / 売掛金 120,000 = ホームページ制作(A社向け)

ちなみにその逆に、『請求書』を発行した時点では、(『入金』があった時点でも)、『売上高』にできないケースだってある。
  • 2016-12-31: 普通預金 120,000 / 前受金 120,000 = 保守2017-01~2017-12(A社向け)
  • 2017-01-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-01分
  • 2017-02-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-02分
  • 2017-03-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-03分
  • 2017-04-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-04分
  • 2017-05-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-05分
  • 2017-06-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-06分
  • 2017-07-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-07分
  • 2017-08-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-08分
  • 2017-09-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-09分
  • 2017-10-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-10分
  • 2017-11-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-11分
  • 2017-12-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-12分

いわゆる「振替伝票」(振替レコード)の作成方法や作成タイミングについては、業種業態だけでなく会社方針によっても様々だ。とは言え、その作成作業そのものは、ぜひとも「自動化」したい。

以下のワークフローでは、『請求書』が上司承認された瞬間、
  • 顧客に請求書PDFがメール送付され、
  • 複数行の「振替レコード」が自動計算され
  • インポート用ファイルが自動生成される。
経理担当は自動生成された Excel-CSV ファイルを、会計システムにアップロードするだけで「入力作業」を終えることができる。

[請求書発行プロセス]
「法人カードのセイで、経費全体が把握しづらい」

業務プロセス改善は「ムダな業務」や「手間のかかる手続き」を減らす。しかし、それにともなって「人間によるチェック」は手薄になる傾向がある。

たしかに「ワークフローの4大アプリ」
  • 立替金精算フロー
  • 調達購買フロー
  • 勤怠報告フロー
  • 稟議フロー
のような発生頻度の高い業務において、「業務効率化をすすめた結果、抜け道(不正方法)ができてしまった」とすれば問題だ。ただ「省力化・無人化」と「チェック体制の強化」はトレードオフの関係になることが多い。結局のところ「自社に合わせた落としどころ」を模索しかないのだ。


以下の経費精算フローは『立替金を精算すること』が主目的の月次申請型の業務フローだ。

この例では、同時に立替金としての精算を要しない経費(ゼロ円立替)について、承認を得られるように工夫されている。これは「クレジットカードでの支払い」や「仮払金を受けている旅費」についての事前の上司承認を無くしてしまうという発想だ。

申請者自身にとっても、一度の申請で「手間が省ける」だけでなく「毎月どの程度の会社経費を使っているか自覚できるようになる」という効果があるだろう。

[経費および立替金の報告]
「年末調整、書くの、メンドクサァーイ!」

日本では年末になると、全ての会社で「2枚の書類」の提出が命じられる。給与所得者達は毎年恒例の紙を見て「あぁ年の瀬なんだなぁ」などと思う。そして、記入し始めると相変わらずの面倒さにイライラする。(その後、管理部門は記入モレの多さに溜息をつく。)

◆[マル扶]扶養控除等(異動)申告書の受理と内容の確認
「家族の住所は "(同上)" って書いてイイんだったっけ?」
「マイナンバーは "提供済番号と相違なし" って書くんだっけ?」
「ていうか、家族の生年月日がワカラナイ・・・」

◆[マル保]保険料控除申告書/配偶者特別控除申告書の受理と内容の確認
「定期保険特約付終身保険、、、長いって」
「60歳支払開始据置終身年金保険、、、長いって」
「郵便貯金・簡易生命保険管理機構、、、だから長いって」

たしかに年に一度きりの「季節行事」ではあるのだが、楽しめるものではない。日本中の5000万人が30分イライラするとして、どれほどの GDP が損なわれている事だろう?? (せめて「手書き」からは早々に脱却したい)
※ ちなみに「1億枚の紙」や「それを保管するための書庫」がモッタイナイという話については、『電磁的方法による提供の承認』という話になる。要するところ、『源泉徴収に関する申告書に記載すべき事項の電磁的方法による提供の承認申請』の提出が必要となるのだが、詳細については、また別の機会に。。。


以下の2つのワークフローは、申請者が申請し、管理部が確認受理するワークフローだ。すべてがオンラインで完結する。

しかも次年度からは前年の申請データを「再利用して開始」すれば良い。前年申請をこのフローで提出した人なら、[マル扶]の『平成28年』を『平成29年』に、[マル保]の『平成27年』を『平成28年』に書き換えるだけで終わる。(「家族が増えた」とか「保険を変えた」とか、そう言った事情がないという前提)

[扶養控除申請フロー / 保険控除申請フロー]