ODRの「システム」を議論する時がきた【たまプラビジネス余談放談】20220408
法務省 司法法制部より政府webで「ODRを国民のものとするアクションプラン」が公表された。資料には日付が３月として表示されている。２００８年に会社登記して活動を開始してから１４年。１４年目はなんの節目っぽくもないが、形のないものをやり始めると関係各所が動くまでにそんなにかかるんだなとわかった。
ODRのシステムを議論する時がきた
ODRも「システム」であるので、システム論は必須だと考えるが上記法務省の資料では、
「ODR事業への参入支援 」
・ 技術支援(情報提供、研修支援)
・ 事業者によるODR提供への働きかけ
という記載となっているので本質的なシステムが活躍するのはもう少し時間がかかりそうだ。なによりそれ（ODR）でADRビジネスを軌道に乗せられる事業者が出てこないと、そして、それらの事業者らによって、そこにシステム間の競争が生まれてこないと、経済的には「システム屋（事業者）」達の活躍は限定的だ。
「ODRシステム」は、「システム屋」システム事業者が開発することになる（だろう）が、ODRが「ADR＋デジタル技術」とあり、ADRが認証制度である以上、システム事業者が自由に効率的なものを開発するのではなく、制度をベースにしたITシステムとなる。
過去に業務のシステム化がどうやって進んでいったのか
ところで過去に業務のシステム化がどうやって進んでいったのか。例えば、どの企業にも必要だった給与計算を振り返ると、業務＝給与計算自体はどの企業にも独自のもの、または、会計事務所等が用意したものがあった。最初はこれをシステム化することが行われた。計算方法は用意されていたのでシステム会社は最初は下請け開発としてこれを理解してプロセスをIT化していった。その後、パッケージ化や身につけたノウハウをもとに、事業者が主体的な開発に進んでいった。（技術的には、汎用機の共用システム、オフコンやPCによる独自のシステム開発、パッケージ化による標準化、クラウドによるサブスクリプション型などが開発されてきた）この流れは他の業務システムでも概ね同じような流れと考えられる。
費用負担については、初期の下請け開発では発注元が負担し、ノウハウを身につけたあとのパッケージ化においては、システム事業者がコア部分の開発費を負担し、カスタマイズする場合は、発注者が負担する折半となる場合もある。最終的には、システム事業者が主体的に費用負担して開発したクラウドシステムのサブスクリプション的な提供のビジネスモデルとなる。
ODRの場合
ODRの場合も同じような流れに乗るのだろうか。
先の給与計算と比較すると、給与計算の部門は経理部か人事部、ADRは法務部だ。ADRが給与計算業務の位置付けになるが、給与計算ほどADRが企業に浸透しているとはいえないだろう。そもそも企業にADRが浸透する以前に、制度もこれから構築されていく段階だ。受託開発システム事業者が開発に関わるのは最初は限定的だろう。当初はシステム導入の対象は一般企業ではなくADR事業者になる。システムの導入数も限定的になる。
システム開発のアプローチ
システム事業者の参入可能性は別途議論するとして、システム開発のアプローチはどうなるか。
（１）業務のシステム化＝＞ ADR手続きのシステム化
給与計算がそうだったように、規定されたADRの手順をシステム化していくアプローチ。大きくは、申し立て、交渉、調停、和解のプロセス、詳細には、紛争内容の登録、書類の提出、相手方への連絡、応諾、本人認証、期日設定、webミーティング期日、裁定、合意などの一連の手続きを包括的にシステム化する。または部分的なシステム化もある。例えば申し立て、書類提出、期日の話し合いの部分だけをシステム化するなど。いずれにしてもまず、「手続きがあってそれをシステム化していく」アプローチ。地味だがこれが一番確実でわかりやすい。日本の場合、第一段階はこれになるのではないだろうか。事例としては、web会議による期日話し合い、海外事例ではSmartsettleや離婚ODRなど事例が多い。日本では、包括的なシステムとしてSmart Judgement（デロイトトーマツ）、Teuchi（ミドルマン株式会社）などがある。
（２）プロセス・リエンジニアリング
情報システムではそれまで多くは（１）のアプローチだったが１９９０年ごろから、業務をシステム化するのではなく優れたシステムに業務を合わせて劇的な成果をあげる手法がとられた。BPR（Business Process Re-engineering）と呼ばれた。ODRでは、eBayのアプローチがこれに相当する。すなわち、申し立てを自由に記述していくのではなく、蓄積されたノウハウをもとに予め分析された苦情、紛争類系を絞り込み表示してしまい、利用者の苦情紛争を早く導き出し、一定期間反応がなければ解決とみなす、などのBPRシステムとしたことにより、紛争解決のスピードと顧客の満足度を向上させる効果を生み出した。現在では全世界で年間６０００万件の紛争を処理している。
（３）周辺システムからのアプローチ
周辺システムなども含めて個別の細かいニーズに応じてシステムを開発する。例えば、類似紛争の検索、類似裁定結果の検索、オンライン陪審的SNS（米国Sidetaker、中国カンガルー陪審団など）、離婚後の共同親権のコミュニケーションシステムなどがある。
早い試行錯誤
筆者が３０年ほど前に米国大使館のセミナー（ちなみに臨席の聴講者はソフトバンクを立ち上げたばかりの孫氏だった。）で日本市場を開拓にきていた米国ソフト会社の社長が語っていた、「カウボーイアプローチとサムライアプローチ」というのがある。前者は、迅速に作り始めてプロトタイプを作り出し、試用・試行錯誤により実用的なシステムを作り出す。開発過程で多くの人を巻き込む方式。後者は、じっくりと理想形を考え抜き、着手は遅くても完璧なシステムを作り出すアプローチだ。
日本はすでに後発組だ。ADR市場のためにも、カウボーイアプローチで、ODRに関わるADR事業者を巻き込み、試行錯誤によって実用的なこなれたシステムを作り上げていく方法が適しているのではないかと考える。それを早期に実現するためには、一から構築を目指すよりは、すでに開発された日本製のシステムを業界も巻き込んで共同採用したり、別のシステムを共同で開発し、共同利用で磨き上げていく方法だ。
アクションプランにもあるように、
・ 関係するADR法関係規律を見直す等の制度整備
・ 運用面の推進につき、幅広い関係者と認識を共有した上、連携して取組を実施
されることを望み、期待する。
「検討」がゴールではなく、早く「検討を実施」の次の段階へ。
ODRの「システム」を議論する時が（やっと）きた。
来週にはもう少し詳細なシステムの機能について書いてみる。
