標準仕様における連携要件の振り返りと、今後の勝手な展望など その２
モグです。お疲れ様です。
その１では、この3年半ほどの間における連携要件の成長、というより苦闘の道のようなものを振り返りました。様々な理由があって、当初描いていた構想、方針のようなものは、明らかに道半ばの状態で、移行期限である2025年度を迎え、サービス提供にあたっての諸課題は「事業者間調整」により解決することとなったということですね。
繰り返しますが、この苦闘に関わられた方々を責める気持ちは一切なく、本来どこを目指すべきなのか、そのためには今後どういうアプローチで進めるべきなのかについて考察していきたいと思います。
道半ばの方針を再確認する
いくつかの当初方針のうち、以下の2点が道半ばといえそうです。
○リアルタイム連携だけでなく、バッチ処理も含めた処理のタイミングも連携方法に含める。
・・・「バッチ処理も含めた」というより、「ファイル連携によるバッチ処理主体」になっているという意味では道半ば
○法令上データのfrom to が定まっている連携は、標準準拠システムに実装できるように明確に規定。独自施策やワンスオンリー等を実装できるように、API連携可能なように規定。
・・・言うまでもなく道半ば
○SOAPから、実装エンジンが不要でクラウド利用との親和性の高いRESTにする。
・・・こちらは、技術要件として記載されているので、道半ばということはないと思います。ただ、APIの仕様としての不足感はあるので、そのあたりは追って触れられればと思います。
今後のアプローチに向けての考察
「相互運用性」ってよく聞くけどなんだっけ？
今後の展望として、道半ばとなっている方針に対してどうアプローチすべきかを考える必要がありますが、そこにかなり関係しそうなこととして、また、このあたりの議論をする際によく聞く用語である「相互運用性」について掘り下げておきたいと思います。
２ 基本方針には、次に掲げる事項を定めるものとする。（中略）イ 電磁的記録において用いられる用語及び符号の相互運用性の確保その他の地方公共団体情報システムに係る互換性の確保に係る事項
このとおり、標準化において相互運用性を確保することは、法律でも定められています（法律の専門家ではないので、このような表現が正しいかまではわかりませんが）。ただ、前述したような連携要件の整備方針よりも、さらに上位の目的として「相互運用性」を捉えておく必要はありそうですね。
では、基本方針にはどのように定められているでしょうか。
連携要件の標準とは、各標準準拠システムが機能標準化基準に適合できるようにし、かつ、標準準拠システム以外のシステムと円滑なデータ連携を行うことができるようにするため
ここ以外の箇所の記載が該当するようであれば申し訳ないのですが、おそらくは相互運用性の確保に関する基本方針での定めというのは、ここの記載を指すものと理解しています。
ここで、相互運用性とはなんなのか、もう少し具体化しておく必要がありそうです。APPLICでも「相互接続確認」というイベントや仕様書がありましたが、どう違うのか、とか。
インターオペラビリティ（interoperability）とは、複数の異なるものを接続したり組み合わせて使用したときに、きちんと全体として正しく動作すること。また、その度合い。
相互運用性(interoperability)は、「きちんと全体として正しく動作する」というところがポイントなんだろうと思います。
「相互接続性」って何だろう？
一方で、似たような用語ですが相互接続性という用語もあり、それを理解するため、関係ありそうなドキュメントとして、APPLICの相互接続確認仕様（公開されています）を、改めて読んでみました。簡単に言うと、リクエスタとレスポンダ間でエラーなく正しく電文が授受できていることを確認する内容となっており、業務ユニット全体として正しく動作することを確認するところまでは手順として定めていません。このことから、相互接続性とは、文字通り接続できるかどうかということだと思います。
わかりやすい例では、IF仕様どおりに電文授受できていても、データを出す側がA処理の更新前の情報なのか更新後の情報なのかの相違によって、データを受ける側の期待する挙動と変わってしまうことは、普通に考えられますね。このような場合、相互接続性は満たしているが、相互運用性は満たしていないということが言えそうです。
結局のところ、標準化基本方針で示されていることは？
話は戻りますが、標準化基本方針に記載のある「各標準準拠システムが機能標準化基準に適合できるように」については、「機能標準化基準に適合」＝「連携先業務全体が正しく動作する」と読み替えることができそうですので、まさに法律の求める「相互運用性を確保」に合致するということが言えそうです。うん、よかった！（標準仕様における機能要件の良し悪しは、ここでは別の話です）
同じく記載のある「標準準拠システム以外のシステムと円滑なデータ連携を行うことができるように」については、相互運用性については特に言及されておらず、どちらかというと円滑に相互接続性を確保することができるようにしておこうね、というニュアンスで理解することができそうです。まあ、対象さえ定義・限定できないであろう、標準外のシステム含めて相互運用性を担保するのは、普通に考えて難しそうですね。
2024年夏の方針「転換」とは、こういうこと
「その１」にて、”いわゆる「事業者間調整」にて課題を解決することとなった”と記載しました。このことは2024年6月の第1回共通機能等課題検討会にて説明があったのですが、非常に唐突感もあって会議としては発散気味だったこともあり、あまり間を空けずに第2回が開催されました。第2回が開催されるまでの間、事業者個別のヒアリングや意見照会もあったようで、丁寧に調整しようとされていることは感じました。事業者間調整により連携の課題を解決する方針となった背景や理由については、第2回の資料を参照するのが良いと思います。
個人的には、デジタル庁としても一生懸命検討・調整に動かれていることも感じていましたし、私としては「では、その事業者間調整をどのように進めるか、お客様のご協力をどうやって得るか」の方に頭が切り替わっており、結論に対して異論を申し立てるつもりは全くありませんでした。
今になって改めて振り返ると、この時の資料では、「システム毎に異なるデータの持ち方や連携項目を一意にすることで、 従来よりも円滑なデータ移行及びデータ連携を実現する」とあります。ん？相互運用性は担保されるということは言っていないですね。それどころか相互接続性についても一歩後退していて「従来よりも円滑に実現する」と言っているだけと読めます。それって前の資料からもそうなっていましたっけ？資料が膨大なのと目が疲れてしまうのできちんと確認はできていません。
この会議だったか、前後の会議だったか失念しましたが、「基本的には方針は変わっていないです」という見解を複数の方からお聞きした記憶があるのですが、冷静にみるとやっぱり変わっていると受け止めるべきところだと思いました。その変わり度合いが、根本的に変わっているとみるのか、移行期限を控えての現実的な判断によるチューニングレベルとみるのかは、立場や価値観によるところなのでしょうね。
目指すべきレベルと、アプローチ案
目指すべきレベルの整理
なんとなくですが、連携要件の目指すべきレベルは、以下の3つの段階に分けられるのではないかと思います。相互運用性、相互接続性については、ここまで述べてきたとおりですが、もう一つ「今回は、形式、フォーマットを統一する」という主旨の発言も何度か聞いた気がしています。これを「インタフェース形式の統一(formal unification)とします。英語力ゼロの私が、Web英訳しただけの造語なので、学術的に不正確である等の突っ込みはしないようお願いします。
相互運用性の確保(interoperability)
相互接続性の確保(connectivity)
インタフェース形式の統一(formal unification)
インタフェース形式の統一ができていて、相互接続性が確保できないということはあるでしょうか。私はあると思います。その典型的な例として、まさに昨年フォーカスされた、最新フラグ、履歴番号、削除フラグ等の定義がされていない状態が、それにあたるでしょう。
見た目上の形式や設定項目（桁数や型など）が同じであれば、連携処理そのものはfatal errorにはなりませんが、上記の項目のように、ファイルの中でどのレコードを対象にして処理するかを特定するための項目が定義されていない、もしくは連携元先で異なる状態であれば、必要な情報を必要な処理の中に取り込むことができないわけで、その状態は相互接続性が確保されているとは言えない、と私は思います。
相互運用性は、必要な情報を必要な処理の中に取り込むことは当然できる状態であり、それに加えて、前述したとおり、その情報のステータス（連携元システムにおける処理シーケンス中どのステータスなのか）が特定できている状態である必要があると考えています。相互接続性が確保できる＝staticなデータ連携が可能、相互運用性が確保できる＝dynamicなデータ連携が可能、と言い換えてもいいかもしれません。
2025年に達成できるレベルとは
これらの用語整理を踏まえて、2025年に我々が迎える状態を表現すると、
「インターフェースの統一は実現したが、相互接続性は（リファレンス等を参考にしながら）事業者間調整にて担保し、相互運用性は明文化されていないものの、やはり事業者間調整にて担保する。」
という状態なのだと思います。相互運用性の確認は、連携元先で合同のシステムテストにて、お互いに連携だけでなく、連携前後の処理を含めて、システム全体が期待した挙動のとおりとなるか、そして業務運用がまわるかを評価しない限り、なかなか見えにくいケースも多いのではないかと想像します。
現在、事業者間調整に苦慮されている方も多いと思いますが、まずは上記の状態以上ではないことを踏まえ、必要以上にリファレンスに頼らずに調整するしかないと私は思います。リファレンスが提示されないから調整が進まないと言う時期でもないし、リファレンスが出たところで根本的には相互運用性の確保まで行きつかないので、現場としては割り切って調整するしかないのではないかと。
ただし、本来我々が目指すべきレベルは、やはり相互運用性の確保なのだろうと思います。それが2025年には行きつかないという現実があるだけです。
相互運用性を確保するためのアプローチ
では、相互運用性を確保するには、どうすればよいのでしょうか。
私は、大きく２通りのアプローチがあると考えています。
一つは、ファイル連携を主体としたままアプローチする方法です。既に述べているように、連携する情報のステータス（連携元システムにおける処理シーケンス中どのステータスなのか）が特定できている状態は、連携要件そのものをいくら詳細化しても実現できず、各業務の要件を詳細化するしかありません。機能別連携仕様、もしくは基本データリストにおける「標準仕様書関連箇所」に記載のある機能要件について、標準化基本方針に記載のあるとおり、(a)どのような場合に、(b)どのデータを、(c)どの標準準拠システム等に対し、どのように提供（Output）又は照会（Input）するかについての要件を、書ききるということです。特にaについては、機能別連携仕様に書くのではなく、連携元業務の機能要件として具体的に定義する必要があります。
これによって、業務内の処理シーケンス中、どのステータスのデータを連携するかが特定できるはずです（条件によってはbとして記載すべきこともあるかもしれません）。処理シーケンスとの関係性だけでなく、履歴管理方法についても定義すべきかもしれません。具体的なDB構造（論理設計、物理設計）は事業者の実装によるところですが、基本データリストとしてどのような考え方で履歴を管理するかを定義する必要はあるように思いますね。ここは業務要件、制度要件だと思います。
私は、これ以外の機能要件については、必須要件からオプション要件に落とすくらいでもよいと考えているのですが、データ要件・連携要件に関連する機能要件だけは妥協してはいけないのではないでしょうか。
もう一つのアプローチは、今一度API連携中心の世界観で標準仕様を見直す方法です。
前述の「ファイルの中でどのレコードを対象にして処理するかを特定するための項目が定義されていない、もしくは連携元先で異なる状態」は、まさにファイル連携だから発生してしまうことなのです。APIの仕様をきちんと詰めれば、このようなことは発生しません。
ただし、この場合も、一つ目の案で記載した「連携元業務の機能要件として具体的に定義する必要」はあります。さらに踏み込んで、バッチ処理中心の処理シーケンスから脱却すれば、「どのステータスのデータを連携するか」みたいな悩みもなくなりそうですが、これはこれで行政の制度や事務運用を考えると、非常にハードルが高く別の問題が発生するので、ここでは深く掘り下げません。
どちらがいいかというと、見直すのは2026年以降になるということ、また、どちらのアプローチもそれなりのパワーを必要とすること(仕様の検討もさることながら、各事業者がパッケージの実装をそれなりのボリュームで見直さなければいけなくなります)も考慮すると、私は後者の方で一生懸命検討した方がよいのではないかと思います。その方が元々目指していた方針に、さらに一歩近づけるわけですから。が、このあたりは、ステークホルダー間でしっかり議論しないといけませんね。
強調したいのは、どちらのアプローチをとったとしても、連携要件のみを精査するのではなく、各業務の機能要件を精査する必要があるということです。
はあ、疲れた。一旦ここまでとして、次回以降は、APIのあり方とか、疎結合とか、現場目線から論じていきたいと思います。