2021年09月30日

海外のイベント

前回お話しした通り、昨日、E-INVOICING EXCHANGE SUMMIT VIENNAに登壇しました。これは電子インボイスに関する国際会議で、ヨーロッパでは年に一回開催されています。

今回は、新型コロナウイルス禍の影響により、ウィーンの実会場とオンライン配信のハイブリッド運営。私はウィーンの実会場に行きたかったところですが、今回はそうもいかずZoom経由での参加になりました。前日にデジタル庁の方が日本のPeppolに対する取り組みを発表していたこともあり、今回のイベントでは日本が注目の的でした。

私は、民間の立場から電子インボイス推進協議会(EIPA)の活動を紹介しました。持ち時間は15分。この種の登壇としては、まず最初にユーモアで場を温めるのが定石。ということで、「カンファレンス最終日の最後のセッションということで、皆さんお疲れだと思うけど、ここ日本はもう午後10時だから、勘弁してよ」と笑いをとりにいったのですが、配信設備の関係でこちらからは会場の反応を伺うことができず、場が温まったのかどうかもわからず、やや不安な滑り出しとなりました。

仕事上、英語でやり取りする機会はそれなりにありますが(OpenPeppolとの定例は2週間に一度開催していますが、もちろんすべて英語です)、多数のオーディエンスがいる国際会議での発表は実に久し振り(前回はおそらく2016年にLendIt USAで登壇した時)。久し振り、なおかつ今回は場の空気が読めないリモート参加で私にしては珍しく少し緊張しました。

2021092901.png
自分の登壇時にスクリーンショットは撮れなかったので、これは待機中の様子

私のプレゼンを自宅で作業しながら聞かれていた関係者の方からは、ご家族から「この人、日本人? フランス人の英語に聞こえる」と言われたとのことでした(笑)。私は中高の英語の先生がアメリカ人(と日本人)だったので、かつてはネイティブの方からは「あー君の英語は、アメリカだよね、しかもカリフォルニア」と言われていたのですが、最近は英語で話す機会が減ったこともあり、ちょっと質が落ちたようです(泣)。今回、私がお話しした内容(資料)については、EIPAのウェブサイトで公開しています。

さて、今回はリモート参加となった訳ですが、会場の様子を見ていて驚いたのが、(パッと見)皆マスクをしていないこと。欧州でも感染者数はまだそれなりにあるはずですが、もうAfterコロナということなのでしょうか。そういえば、11月にアメリカはLas Vegasで開催される大規模イベントにお誘いいただいたのですが(これも日本からの参加は残念ながら断念する見込み)、こちらはワクチン接種/マスク着用が条件となっていました(陰性証明では不可)。基準は異なりますが、新型コロナウイルスが根絶されずとも、日常生活であり、社会的活動を取り戻す方向になっているのかと思います。

日本でも今日で緊急事態宣言が終了となります。まだ新型コロナウイルス禍がなくなった訳ではありませんが、良くも悪くも新型コロナウイルスと共存しつつ、日常生活であり、社会的活動を取り戻していく転換点になることを願っています。ちなみに、来年のヨーロッパでのE-INVOICING EXCHANGE SUMMITは来年9月にLisbonで開催とのこと。Lisbonには一度行ったことがありますが、いい街です。来年こそは現地で参加したいところです。
posted by 岡本浩一郎 at 22:03 | TrackBack(0) | 弥生

2021年09月28日

日本もPeppolに参加

デジタル庁のウェブサイトでひっそりと取り上げられていますが、9/14(火)にデジタル庁がOpenPeppolのメンバーとして加入しました。これまでにもお話ししてきましたが、OpenPeppolというのは、Peppolという電子インボイスの仕様を管理し、国際的なネットワークを運営している管理団体です。

日本においてPeppolをベースとした電子インボイスの仕組みを運営するためには、原則として国内における管理主体(Peppol Authority)が必要となります。この管理主体はその国の行政機関が担うことが一般的であり、日本の場合はデジタル庁がPAとして機能することとなり、その第一歩としてデジタル庁がOpenPeppolにメンバーとして加入したということになります。OpenPeppolのサイトにおいても、日本におけるPAとしてデジタル庁の名前が既に掲載されています。

これまでEIPAではデジタル庁(内閣官房)と協力しながら、OpenPeppolと日本におけるPeppolの利用に向けた検討を進めてきましたが、あくまでも議論/検討フェーズ。議論はまだまだ続くのですが、今回のデジタル庁のOpenPeppol加入は、正式な運用に向けての第一歩ということになります。

2021092801.png

電子インボイスは欧州を中心に導入/利用が進んでいますが、日本もようやく正式にこの電子インボイスの世界にデビュー(?)したことになります。今日からウィーンでE-INVOICING EXCHANGE SUMMIT VIENNAという電子インボイスに関する国際会議が開催されており、今日開催された"Global Developments in Peppol"というセッションでは、デジタル庁から2名が登壇し、日本におけるPeppol導入に向けた取組みを発表しました。

2021092802.png

実は私も明日の"OpenPeppol Developments"というセッションで、EIPAの立場から、日本におけるPeppol導入に向けた取組みを発表することになっています。ウィーンでの会場開催とリモート開催のハイブリッドなので、日本からも参加できるのですが、1セッションのためだけに参加するには少々お高いんですよね(リモート参加でEUR900なり)。私の持ち時間は15分だけですので、さすがにそのためにEUR900払って見てくださいとは言えません(苦笑)。資料については、後日EIPAのウェブサイトで共有できると思います。

ちょっと意外かもしれませんが、海外ではこの種のカンファレンスがもう普通に開催されるようになってきています。私もよければウィーンでとお誘いを受けたのですが、行くことはできても帰ってからの隔離措置があるため、泣く泣く断念しました。ウィーンは行ったことがないので、行ってみたかったなあ、というのが正直なところです(笑)。
posted by 岡本浩一郎 at 23:28 | TrackBack(0) | デジタル化

2021年09月24日

何がインボイス(適格請求書)なのか(その2)

前回は納品書と合算請求書(月締請求書)それぞれについて、何をもってインボイスとなるのかについてお話ししました。納品書や請求書という名称自体は実は何の意味もありません。名称によらず、[1] インボイスに記載が必要な事項が満たされており、仕入税額控除の適用ができる、と同時に[2] 買手に支払いを求める文書である、ものがインボイスとなります。

2021092401.png

では、今度は前回と異なるパターンを見てみましょう。まずはこちら。これは前回の一つ目の例とほとんど同じです。名称は納品書。ただ、前回の例と異なるのは、前回は税額に関する記載がない(結果的に総請求額も記載されていない)のに対し、今回は税額に関する記載があり、総請求額も記載されているということです。

結果的にこの納品書は、インボイスに記載が必要な事項である、以下の6つを全て満たすことになります。

(1) 売手(適格請求書発行事業者)の名称および登録番号
(2) 取引年月日
(3) 取引内容(軽減税率の対象品目であればその旨を明示)
(4) 税率ごとに区分して合計した対価の額および適用税率
(5) 税率毎の消費税額
(6) 買手の名称

ですので、名称としては同じ納品書ですが、前回の例と異なり、今回の納品書はインボイスになりえます。インボイスです、と断定はせず、インボイスになりえます、というやや曖昧な言い方をしましたが、これはもう一つの条件である[2] 買手に支払いを求める文書であるかどうかで左右されます。名称としては納品書であっても、インボイスに記載が必要な情報が記載されており、この納品書をもって支払いを求めるという合意が売手と買手の間でなされていれば、これはインボイスになります。

いや、ちょっと待ってください。この納品書に対して、このような月単位でまとめた請求書が発行されていたらどうでしょうか。

2021092102.png

これは前回の二つ目の例と同じです。じゃあやっぱり、納品書は納品書であってインボイスではない、その代わりこの請求書がインボイスになるのでしょうか。

実は先ほどの納品書とこの請求書の組合せには問題があります。細かくはまた別途お話ししたいと思いますが、先ほどの納品書とこの請求書でそれぞれ税額の計算を行っているからです。インボイスでは、税率毎に端数処理は1回と決まっています。納品書と請求書でそれぞれ税額の計算を行うと税額に矛盾(一致しない)が発生しえます。前回の例では納品書では税額の計算を行っておらず、合算請求書でのみ税額の計算を行っていました。これであれば矛盾は発生しえないですし、端数処理は1回ですから問題はありません。

2021092402.png

今回の納品書の場合は、こんな「請求書」との組合せであれば問題ありません。

この「請求書」自体では税額の計算を行っていません。納品書で計算された税額を引用し、対象期間で集計しているだけです。ただ、このケースでは、この「請求書」はインボイスにはなりません。この場合は、納品書がインボイス([1] インボイスに記載が必要な事項が満たされており、仕入税額控除の適用ができる、と同時に[2] 買手に支払いを求める文書である)、逆にこの「請求書」は、名称こそ請求書であっても、実態としては支払案内という位置付けになります。一定期間の間にこれだけの納品があり、それぞれに対し納品書(兼請求書)で請求済みです。ただ、念のために、期間合計を再度送付しますので、お支払いの程お願いします、というものです。つまりこれまでにお話ししてきた月まとめ請求書であり、インボイスではないということになります。

インボイス = 請求書という定義自体は必ずしも誤っている訳ではないのですが、その判断は名称ではなく、記載されている中身で判断することになります。今一度自社が発行している納品書/請求書にどういった情報が記載されているのか、何がインボイスに該当するのか、考えておきたいところです。
posted by 岡本浩一郎 at 22:40 | TrackBack(0) | 税金・法令

2021年09月21日

何がインボイス(適格請求書)なのか(その1)

前回は、合算請求書(月締請求書)と支払案内(月まとめ請求書)の違いについてお話ししました。合算請求書がインボイスとなるのに対し、月まとめ請求の場合には、納品書がインボイスとなり、月まとめ「請求書」は実はインボイスではないということをお話ししました。月まとめ請求の場合には、月まとめ「請求書」は実はインボイスではない? 一体どういうことでしょうか。

インボイスというのは適格請求書の英語名称ですから、単純に考えれば、「請求書」という名前がついていればインボイス、そうでなければそれはインボイスではない、と判断しがちです。しかしそれは正しくありません。インボイスかどうかは、名称ではなく、どういった情報が記載されているか、また、その用途で決まります。

2021092101.png

まずは、一つ目の例を見てみましょう。B商事株式会社からA株式会社への9/15付けの納品書です。これは納品書であって、インボイスではありません。ただそれは納品書という名前だからではなく、インボイスに必要とされる記載事項が満たされていないからです。

インボイスに記載が必要な事項は、以下の通りです。

(1) 売手(適格請求書発行事業者)の名称および登録番号
(2) 取引年月日
(3) 取引内容(軽減税率の対象品目であればその旨を明示)
(4) 税率ごとに区分して合計した対価の額および適用税率
(5) 税率毎の消費税額
(6) 買手の名称

一つ目の例を見ていただくと、(1)/(2)/(3)/(4)/(6)については記載がありますが、(5) 税率毎の消費税額が記載されていません。ですからこの文書はインボイスとはなりませんし、この文書をもって仕入税額控除を適用することはできません。

この文書は、基本的に納品内容を買手に伝えるものであって、この文書をもって買手に支払いを求めるものではありません。支払いを求めるのであれば、消費税の額も記載し、その合計の支払いをしてもらわなければなりませんから。すなわち、この文書は、[1] インボイスに記載が必要な事項が満たされておらず、仕入税額控除の適用ができない、と同時に[2] 買手に支払いを求める文書ではない、から、インボイスではありません。

2021092102.png

次に二つ目の例を見てみましょう。これはB商事株式会社からA株式会社への9月分の納品に対する請求書です。9月中の複数の納品から1つの請求書が作成されていますから、従前からお話ししている合算請求書(月締請求書)です。この文書は、先ほどご説明したインボイスに記載が必要な事項が全て記載されています。先ほどはなかった(5) 税率毎の消費税額も右下に記載されていますね。

また、この文書は買手に支払いを求めるものです。消費税の額も記載されており、支払うべき金額が明確になっています。すなわち、この文書は、[1] インボイスに記載が必要な事項が満たされており、仕入税額控除の適用ができる、と同時に[2] 買手に支払いを求める文書である、から、インボイスとなります。

次回は月まとめ請求書について、なぜインボイスとならないのか、をお話しします。
posted by 岡本浩一郎 at 23:12 | TrackBack(0) | 税金・法令

2021年09月16日

月締請求書と月まとめ請求書

前回までにお話ししてきたように、Peppolをベースとした電子インボイスの日本標準仕様(JP Peppol)では、日本で一般的な商慣習である合算請求書(一般的には月締請求書)をサポートします。都度請求書では、1納品書 = 1請求書となりますが、合算請求書はN納品書 = 1請求書。合算請求書では、月末など所定のタイミングでN通(複数)の納品書を合算して請求書を発行します。

一方で、同じN通の納品書を基に作られる「請求書」ですが、実態として合算請求書と大きく異なるパターンがあります。正式名称はないのですが、ここでは便宜上月まとめ請求書と呼びます。このケースでも、納品後すみやかに納品書を発行し、月末など所定のタイミングで複数の納品書を合算して月まとめ請求書を発行します。

ん、合算請求書(月締請求書)と月まとめ請求書で何が違うの?と思われるかもしれません。というか、そう思いますよね。

2021091601.PNG

違いは、合算請求書(月締請求書)の場合は、インボイス(適格請求書)は合算請求書であるのに対し、月まとめ請求書は実はインボイス(適格請求書)ではないということです。この場合は、納品書がインボイスも兼ねているのです。つまり合算請求書(月締請求書)の場合には、納品書はインボイスではなく、合算請求書がインボイスとなるのに対し、月まとめ請求の場合には、納品書がインボイスとなり、月まとめ「請求書」は実はインボイスではないということです。

では、月まとめ請求書は何なのか、というとこれは支払案内という位置付けになります。一定期間の間にこれだけの納品があり、それぞれに対し納品書(兼請求書)で請求済みです。ただ、念のために、期間合計を再度送付しますので、お支払いの程お願いします、というものです。

なかなか難しいですね。EIPA標準仕様策定部会でも、この点でかなり悩んだので、ある意味悩んで当然です。これをすっきりと理解するためには、そもそも何がインボイス(適格請求書)なのか、ということを理解する必要があります。次回は、何がインボイス(適格請求書)なのかという点について改めてお話ししたいと思います。
posted by 岡本浩一郎 at 22:00 | TrackBack(0) | デジタル化

2021年09月14日

合算請求書は何が違うのか

前回電子インボイス推進協議会(EIPA)として、Peppolをベースとした日本標準仕様(JP Peppol)の策定を進めるにあたって、まずは日本の商慣習を確実にサポートするために、日本で必要とされる業務プロセスの整理から着手したとお話ししました。結果的に、事前の想定通り、月締請求書など、合算型のインボイス(Summarized Invoice)がギャップであることを確認したこと、その上で、JP Peppolにおいては、合算型のインボイスをサポートすべきと結論付けた、とお話ししました。

2021091401.PNG

前回お話ししたように、現状のPeppolは納品書と請求書が1:1に対応することが前提となっています。これは日本でも存在する業務プロセスです。明確に区別するために、これを都度請求書と呼ぶことにします。都度請求書では、1納品書 = 1請求書となり、納品後すみやかに請求書を発行することになります。実務としては、納品書がないケースも、逆に納品書が請求書を兼ねており、明示的な請求書がないケースもあります。ただ、ここで重要なのは、請求の対象が一回の納品に限られているということです。

これに対し、合算請求書はN納品書 = 1請求書となります。合算請求書は一般的には月締請求書と呼ばれることが多いと思いますが、合算するサイクルは必ずしも月締めではない(例えば、2週間に一回、あるいは2ヶ月に1回)ため、汎用的な名称としてこれを合算請求書と呼んでいます。合算請求書では、月末など所定のタイミングで複数の納品書を合算して請求書を発行します。

都度請求書の場合には、請求の対象が一回の納品に限られているため、その納品が確かになされているかを確認すれば支払の是非を判断することができます。これに対し、合算請求書の場合には、請求の対象が複数の納品にまたがるため、支払の是非は、合算請求書上の明細がどの納品に由来しているかを識別し、その納品が確かになされているかの確認が必要になります。

支払の是非をシステム的に判断し、処理を自動化できるようにするためには、都度請求書の場合には、請求書単位で由来となっている納品書が(納品書番号などで)特定できれば大丈夫です。これに対し合算請求書の場合ではどうなるか。合算請求書は請求の対象が複数の納品にまたがるため、特定のための納品書番号が複数になります。これを請求書単位で由来となっている納品書番号を複数持つという考え方もありますが、どの明細がどの納品由来なのかが一意に特定できず、処理としては難しくなります。どの明細がどの納品に由来しているかを一意に特定できるようにするためには、明細単位で由来する納品書番号を持てるようにする必要があります。

前回、JP Peppolは合算請求書(月締請求書)をサポートしますと書きました。これは、都度請求書と合算請求書のデータ構造(データモデル)は全く一緒とした上で、明細単位で納品書番号への参照情報を持てるようにしたことによって、参照する納品書番号が1つであればそれは都度請求書、複数あればそれは合算請求書として処理できるようにしたということです。
posted by 岡本浩一郎 at 23:37 | TrackBack(0) | デジタル化

2021年09月10日

ワクチン2回目

新型コロナウイルス・ワクチンの1回目の接種からあっという間に3週間が経ち、今週水曜日に2回目の接種を受けてきました。

今回も予約時間の13:30ちょうどに会場に。今回も待つことなく、予診票の確認、医師による予診、実際の接種、15分間の待機、と見事な流れ作業でした。13:32(!)には接種が済み、13:45過ぎには会場を後にすることができました。

2021091001.jpg

今回の接種も、あれ、もう打ったの、という感じ。筋肉注射なので痛いというイメージでしたが、実際にはそんなことはありません。2回目ということで余裕があり、接種していただいた看護師さんと少しお話ししたのですが、通常のインフルエンザ等の予防接種と比べ、接種量が少なく(0.3ml)、また針が細いのだそうです。確かにあっという間に終わるのは、接種量が少ないからなんでしょうね。

2回目は副反応がキツイかも、ということで、帰り際に解熱鎮痛剤を購入して帰宅。厚生労働省では、アセトアミノフェンや非ステロイド性抗炎症薬(イブプロフェンやロキソプロフェン)などの市販の解熱鎮痛剤での対応が可能としていますが、私の行った薬局ではアセトアミノフェンを使用した薬は売り切れ。ある意味ワクチン接種が進んでいるということなんでしょう。

心配していた副反応ですが、接種当日は、目立った変化はありませんでした。大事をとって早めに寝ることに。翌日起きてもあまり変化は感じません。うーんちょっとだるいかな、という感じ。翌日は、極力予定を入れないようにしていたのですが、それでもぽろぽろと予定は入ってしまい、結局5件、5時間の予定が入っています。

日中にうーん、少し熱っぽいかなと体温を測ると、わずかに熱があるようです。痛いとか、辛いということはないのですが、だるいという感じ。だるいため、バリバリ仕事をするぞ、とはなりませんでしたが、途中途中休憩をはさみつつ、予定を全てこなすことができました。夕ご飯を食べる頃には、少しラクになってきたかなという感じ。それでも念のため、昨日も早めに寝ることに。

そして今日は全く平常です。接種した腕のリンパ節がちょっと痛いかなぐらいで、それ以外は全く平常。昨日はやるべきことだけど最低限こなすという感じでしたが、今日は通常のペースです。

事前の情報では副反応がどうなることかと心配していましたが、結果的には案ずるよりは産むが易しだったな、と感じています。もちろん個人差はあるのだと思いますが。ワクチン接種が2回完了したとしても、引き続きマスク着用、Social distancing等の予防措置は必要です。またこの先も年に一回のワクチン接種が必要になるのかもしれません。それでも徐々に日常の生活に戻っていく一歩になることを願っています。
posted by 岡本浩一郎 at 16:41 | TrackBack(0) | パーソナル

2021年09月08日

アルトア与信モデルをりそな銀行へ

アルトア弥生オリックスの3社から本日同時にプレスリリースを行っていますが、このたび、アルトアの会計データ与信モデルをりそな銀行に提供することが決まりました。

2021090801.png

アルトアは、2017年12月に、会計データを利用し、AIで与信判断を行うオンライン融資サービスを開始しました。ただ、この時点から、アルトア自身が融資するだけではなく、金融機関がアルトアの与信エンジンを利用することによって、アルトアと同じような利便性の高い融資サービスを提供することが当たり前となることを目指して活動してきました。

これをアルトアでは、LaaS(Lending as a Service)と呼んでいます。LaaSとは、融資を提供する金融機関に対し、融資機能をサービスとして提供する仕組みです。アルトアは、データとAIを活用したより高度な与信判断や、オンライン完結型のより利便性の高い融資の仕組みをパッケージ化されたサービスとして提供します。

当初からLaaSを事業の柱の一つとして位置付け、様々な金融機関と協議を続けてきましたが、正直に言って、苦戦してきました。金融機関として大いに興味はあるものの、なかなか自行で採用するところまでは辿りつきませんでした。アルトアの取組みはいわゆるFinTechの一部をなすわけですが、一口にFinTechと言っても、金融機関から見て周辺領域(これまでにやったこともないし、知見もない)なのか、本丸なのか(これまでにもやってきたことであり、競争力の源泉として強いこだわりがある)で、採用に向けてのハードルが全く異なることを実感してきました。言うまでもなく、アルトアがサービスとして提供する「融資」は金融機関にとって、本丸中の本丸です。その本丸において、興味深いものの、目新しいものを採用してもらうことは当初想像していたより圧倒的に難しいことでした。

その間、アルトアは自社融資サービスを継続し、ある意味、実証実験を続けてきました。その中で新型コロナウイルス禍という未曾有の事態においても、しっかりと与信機能を発揮できるということも(意図せずではありますが)実証できました。

ただ、本ブログでもお話ししたように、アルトアの自社サービスはこの春に終了し、事業としてはグループであるオリックスに移管をしました。3年以上続けてきた自社融資サービスによって、充分な実績は積めたこと、また同時に、自社融資サービスとLaaSの二兎を追うのではなく、LaaSこそ事業の唯一の柱であると明確に位置付け、いわば背水の陣で臨むという判断です。

そして今回、ようやく、りそな銀行にアルトアの与信モデルを提供するという合意が得られ、発表をするに至りました。アルトアから移管した先となるオリックスを除くと、LaaSの第一号案件となります。個人的にはりそな銀行という、もともと与信モデルの開発能力に定評のある金融機関に認めていただいたことが最大の成果だと思います。りそな銀行は、日本銀行の金融高度化センターによるAIを活用した金融の高度化に関するワークショップでも「AIを活用した信用評価手法の現状とこれから」と題したプレゼンテーションを行っていることからわかるように、データとAIを活用した信用評価において先進的な取り組みを行ってきています。そのりそな銀行に、アルトアの与信モデルを評価いただき、りそな銀行の融資をさらに高度化させうるツールとして選んでいただいた訳ですから。

今回はまず提供に向けて合意したという発表です。実際にアルトアの与信モデルを活用したりそな銀行による融資サービスの開始は年内を予定しています。りそな銀行によるサービスがしっかりと立上り、事業者の方に利便性を実感していただけるように、しっかりとサポートしていきます。
posted by 岡本浩一郎 at 21:23 | TrackBack(0) | アルトア

2021年09月06日

8月のトレーニング

いつの間にやら9月。最近はすっきりしない天気が続き、ちょっと肌寒いなと感じることも増えてきました。暑ければ暑いで早く涼しくなればと思いつつ、涼しくなったら暑さが恋しくなるとは人間って勝手ですね。

さて、今年はトライアスロンに挑戦するとお話ししましたが、参加を予定している千葉シティトライアスロン大会(10/10)まであと一ヶ月ちょっととなりました。本当は地元横浜の横浜シーサイドトライアスロン大会(9/26)をデビュー戦として考えていたのですが、残念ながら新型コロナウイルスの感染拡大を受け、横浜の大会は8月早々には開催中止が決定。千葉の大会については10月開催ということもあり、今の時点ではまだ開催予定です。

本番が近付いてきているということでトレーニングに励まねばならないのですが、8月は天候不順とワクチン接種後の運動控えのために(言い訳?)、あまりトレーニングを積めませんでした。改めて確認してみると、スイミングが7回/16.5km、バイクが2回/41.3km、ランニングが6回/56.7km。天気の影響を受けにくいスイミングはまずまずの回数/距離でしたが、バイクは練習不足が否めません。

残りは一ヶ月ということになりますが、9月に入って涼しくなってきたということもあり、ラストスパートをかけたいところです。昨日日曜日は、曇りがちで絶好の練習日和ということで、これまでにやったことのなかった一日3種目に挑戦してみました。本番はスイム/バイク/ランの順番ですが、折角であればできるだけ泳ぎたいということで、バイク/ラン/スイムの順番です。

2021090601.png

結果としては本番の距離(スプリント)で計測すると、スイミング(750m/平泳ぎ)が18分20秒、バイク(20km)が約53分、ランが28分50秒程度でした。千葉シティトライアスロン大会の制限時間は、スイムがスタートから30分、バイクがスタートから1時間20分、ランがスタートから2時間ということで、第4の種目と言われるトランジション(競技間の切り替え、トライアスロンではウェアやシューズなどを替える時間も制限時間に含まれる)にどれぐらいの時間がかかるのか見通せないのは不安要因ですが、何とか制限時間はクリアできるかな、というところです。

本番前に怪我をするのでは本末転倒ですから、引き続き無理のない範囲で練習を積みたいと思います。とはいえ昨日から一転、今日は朝から晩まで打合せ続きで、Apple Watchによるとエクササイズの時間はわずか3分と悲しい限りですなのですが(笑)。
posted by 岡本浩一郎 at 21:55 | TrackBack(0) | パーソナル

2021年09月02日

業務プロセスの整理

電子インボイス推進協議会(EIPA)では、昨年12月の平井大臣への提言を経て、2021年1月に標準仕様策定部会を組成し、Peppolをベースとした日本標準仕様(JP Peppol)の策定を進めてきました。

具体的に策定作業を進めるにあたっては、かなりの作業量が見込まれることから、部会の中で、検討作業に一定の時間を費やすことができる会員をボランティアとして募集し、コアチームを組成、このコアチームが、Peppolの国際管理団体であるOpenPeppolと協議をしながら策定を進めてきました。また同時に、行政側の受け皿となる内閣官房IT戦略総合室と連携を取りながら進めてきました。内閣官房IT戦略総合室といえば、そう、昨日正式に発足したデジタル庁の母体となった組織です。

標準仕様の策定にあたっては、最初から詳細仕様の検討を行うのではなく、まずは日本の商慣習を確実にサポートするために、日本で必要とされる業務プロセスの整理から着手しました。

Peppolは元々の名前(Pan-European Public Pocurement Online: 汎欧州公共調達オンライン)が示す通り、欧州発祥の仕組みです。このため、Peppolの土台には、EN16931-1という欧州の電子インボイス標準規格が存在します。コアチームでは、まずこのEN16931-1で定義されている12の業務プロセスを検証し、日本の商慣習とのFit/Gapを分析を実施しました。

2021090201.png

結論としては、これは事前の想定通りですが、月締請求書など、合算型のインボイス(Summarized Invoice)がギャップであることを確認しました。欧州等でも複数の納品書をもとに合算された合算型のインボイスは存在しますが、一般的とは言えません。このため、現状のPeppolでは、合算型のインボイスはサポートされていません。つまり、現状のPeppolは納品書と請求書が1:1に対応することが前提となっています。これに対し、月締請求書をサポートしようとすると、納品書N通をまとめて1通の請求書とするというN:1の関係性をサポートする必要があります。

ここで考えるべきは、そもそも本当に月締請求書が必要なのかどうか。これはまた改めてお話ししたいと思いますが、デジタルを前提として考えると、業務効率の向上と早期の業績把握を通じた経営のリアルタイム化の観点から、日本においても請求業務は合算型から都度型に変わっていくべきであると考えています。しかし一方で、2023年10月の時点において電子インボイスが一般的に利用される状態を目指すためには、一旦は概ね現状の業務プロセスのままでも電子インボイスを利用できるようにすべきと考えました。このため、JP Peppolにおいては、合算型のインボイスをサポートすべき、と結論付け、検討を進めてきました。

そうです、JP Peppolは月締請求書をサポートします。欧州発の仕組みを日本で活用するという中で、ある意味わかっている人ほど(海外では月締請求書が一般的でないとわかっている人ほど)、月締請求書はどうなるんだ、と心配されていました。実際、その懸念は妥当だった訳ですが、OpenPeppolにも合算請求書の必要性を理解してもらい、晴れてJP Peppolでサポートすることとなりました。
posted by 岡本浩一郎 at 21:38 | TrackBack(0) | デジタル化