Column (No. 12) – PPP共通データ仕様協議会　共通データ仕様公開サイト

[付録] 仕様の進化

　ある事業者との打ち合わせの中で「一般的に仕様というものは変化していくので、なかなか採用するタイミングが難しい」という発言がありました。この発言はデータ仕様に限ったことではないのですが、ここではデータ仕様に関して変化するかもしれない仕様に対しどの様に対応すれば良いのかについて考えてみましょう。

■仕様が進化する理由

　変化する仕様への対応を考える前に、なぜ仕様は変化するのか考えてみましょう。

　データ仕様などのデジタルの世界では、必ず仕様は時代と共に変化します。例えばスマホやPCの周辺機器を購入しようとするとUSBやWiFiのバージョンが記載されている事がよくあります。USBでしたら最も普及しているUSBのコネクタはUSB-A (Type-A Standardコネクタ)と呼ばれるものだと思いますが、実はおなじUSB-Aでも数年ごとに仕様が強化されていてバージョンが異なっているものが数種混在しています。USBのコネクタの進化のポイントは主に供給電力と通信性能です。つまり、どんどん速くなっていたり沢山の周辺機器を繋げる様になっていたりするわけです。同じようにWiFiもどんどん速くなっていますよね。今では動画もサクサク視聴できるのが当たり前です。他にもPCでよく使われているWindowsも数年に一度はバージョンアップしており、古いパーションのものはサポートが無くなったり、新しいPCでは動かなかったりしますよね。

　この様にITとかデジタルを始めとするテクノロジーの世界では、必ずと言っていいほど仕様は進化していきますし、バリエーションも複数あるのが普通です。では共通データ仕様に関係の深い「データ仕様」という観点でいうと、仕様の変化を促す理由には以下がある様に思います。

変更理由	説明
世の中の進化	共通データ仕様には「設備」のデータモデル(電子データ用の帳票)がありますが、設備の種類は年々増えています。現在では電気自動車の充電設備も随分普及してきましたし、今後はスターリンクのアンテナの様な設備も設置されるのかもしれません。建物の屋上にはドローンの発着場も設置されるようになるのかもしれません。　この様に、「設備」に限らずデータ仕様は世の中の変化に合わせて必ず進化します。PPP共通データ仕様協議会がデータ仕様を共通化する「コミュニティー」であると称しているのはこの様な進化を皆で議論しながらタイムリーに取り込んで行けるようにするためです。
ニーズの拡大	電子データはある目的で作成したとしても別の目的でも流用可能です。そうすると、その「別の目的」によっては新たな情報を追加して欲しいというニーズが出てくるかもしれません。例えば、建物の情報を災害時の避難所を管理する目的でも活用したいと考えた場合、「避難所コードも登録できる様にして欲しい」という新たなニーズが出てくるなどです。　この様な場合は、項目を追加する仕様変更になります。項目を追加しても、以前からデータを利用している既存の利用者には影響がありません。古いデータではその項目が無いという状態もあり得ますが、共通データ仕様は知らない項目が増えていても動作が変わらない規格に準拠しているので問題は発生しません。一方、データを登録する側はどう対応する考える必要があります。登録するデータの価値を高めるために新たな項目にもデータを登録する事もできますし、登録しないという選択肢もあります。また、別の参加者が追加した項目の情報を追加する事も可能です。　余談ですが、CSVでデータ交換やデータ蓄積をしている場合は、表の形式でデータ全体を一括してやり取りするため、項目を追加するとデータの利用者と提供者の双方に影響が発生します。CSVは人間が表として活用する際に適した形式です。データ交換や蓄積には利用しない方が無難と言えます。
基盤技術の進化	昔々のデータ仕様は非常にコンパクトに策定されていました。これは通信が遅く高価だったなどが原因でした。コンパクトなデータ仕様は通信量が少ない代わりに使い方が難しく発展性も無く、保守や開発のコストが大きいものになっていました。通信が高速化してくると、コンパクトさよりも使いやすさや拡張性に優れた新たな方式が徐々に生み出され、入れ替わってきました。共通データ仕様のータモデルはデジタル庁の推奨モジュール(Fiware/Orion)の準拠規格であるNGSI V2に準拠しています。NGSI V2は自由度が高く拡張性も大きい方式です。しかし、このNGSI V2も現在では最新の規格ではありません。更に自由度が高く同時に厳密なデータの表現も可能なNGSI-LDというものが最新です。従って、将来デジタル庁がNGSI-LDに移行するのであれば、データ仕様も変更の要否を議論する時代が来るかもしれません。もし変更するのであれば、ツール等による変換が必要となります。因みに、共通データ仕様では将来NGSI-LDへ変換する際に障害になりそうな記述は極力避けています。
デジタル化の進展	現在の共通データ仕様は人間の作業をデジタル化する事を想定して策定されています。従って、人間にとってあまり細かくなりすぎないようにある程度「丸め」て定義してあります。先々、施設情報のデジタル化が当たり前になり人間がイチイチ登録操作をしない時代が来ると、電子データとして登録する情報は細かくなっていきます。これは「丸め」る作業はコンピュータにとっては却って煩雑ですし、丸めると情報が失われデータの価値が低下してしまうためです。　逆に、デジタル化が進展するとデータ仕様が簡略化される可能性もあります。例えば、建物の設計を行う「BIM (Building Information Models) 」にはWebAPIでBIMの内容を検索するIFC Web Serverという考え方々あります。将来もしこれが一般化すると、BIMと共通データ仕様に同じ情報を登録する事は無駄ですから、共通データ仕様の一部は使わなくても良い様になるかもしれません。例えば床面積などの建築物の情報はBIMから取得すればよい様になるわけです。　この様なデジタル化の進展がどの程度のスピードで現実のものになるのかは予想がつきませんが、このような隣接領域も良く注視していく必要があります。

■仕様の変化への対応

　変化していく仕様に対する対応は、現状の業務が採用している仕様に大きく依存します。この場合の業務はデジタル化されていなくても構いません。デジタル化されていなくても、用語の共通化は重要ですから。

　以下は、現在の業務がどの様な仕様を使っているかの観点で分類し、対応をまとめました。

現在の仕様	説明
決まっていない	例えば、報告書に記入する際の用語の定義が担当者任せであったり、事業所や部門ごとにバラバラであったりする場合です。　この場合は共通データ仕様の採用の可否を考える必要はありません。元々仕様が無いのですから、直ぐにでも共通データ仕様を採用し、もし共通データ仕様に不足があれば提案すべきでしょう。躊躇する理由は何も無い様に思います。
非公開の独自仕様	事業者独自の仕様で統一されている場合です。　この場合は選択肢は二つあります。ひとつは独自仕様を続ける方法。もうひとつは共通化された仕様にする方法です。どちらを選択するのかは事業者の戦略に依存しますので、どちらにすべきだと一概に言うことは出来ません。　独自仕様を続けることはデジタルの世界ではかなりの困難と投資が必要ですが、成功した例もあります。データ仕様ではありませんが、マイクロソフト社のWindowsやアップル社のiPhoneが好例でしょう。どちらも独自仕様ですが、その仕様をある程度公開し、アプリベンダなどの仲間を世界中に獲得する事でひとつの経済圏を構成する事に成功しています。すべての仕様を非公開にしたままで成功した事例は筆者の知る範囲では無いように思います。　共通化された仕様にする方法には二つの方法があります。ひとつは、独自仕様を公開して他社にも利用を求め、共通化して行く方法。もう一つは、PPP共通データ仕様協議会に仕様を公開して共通データ仕様との融合を求める方法です。　前者はシェアが大きい事業者であれは可能ですが、データを組織を超えて交換する事で業務の効率化や価値向上を図るデジタル化の考え方と矛盾する部分もあるので、良く考える必要があります。　後者の場合、PPP共通データ仕様協議会では既存の仕様と比較して、どの様に対処すべきか議論することになります。既に策定して公開している仕様を変更する事には困難が伴いますが、採用している団体が増えれば増えるほどこの困難は大きくなります。早い内の提案がおすすめです。　余談ですが、デジタルの世界では変化していく仕様の違いを吸収するために「辞書」という考え方を導入する場合があります。ここでは辞書については説明しませんが、全て完全に一致させる事だけが共通化ではありませんので、ご相談下さい。
一部は公開された仕様を採用	PPP共通データ仕様協議会が公開している共通データ仕様とある程度重なる分野で公開された用語が存在します。例えば、ある施設管理の団体では壁や床の仕上げに関する書籍を出版しており、書籍内では用語は細かく統一されています。　この場合はその団体と協議して共通化を図る事を検討します。PPP共通データ仕様協議会は新たな仕様を策定する活動ではなく、仕様を共通化して普及する活動です。従って、一部であっても既に共通化され公開されている仕様や用語があるのであれば、積極的に共通化を働きかけていきたいと思います。

【補足】仕様変更の種類

　以下に仕様変更の主な類型と協議会の考え方をまとめました。

仕様変更の種類	説明
新規データモデルの追加	新たなデータモデルを追加するケースです。この場合、既存のデータモデルを使っている利用者には影響はありません。勿論、データを提供する側は、新たなデータモデルのデータも提供するのかどうかのビジネス判断は必要となります。
既存データモデルへの新規項目の追加	既に記載した様に、既存のデータモデルに対し項目を追加しても互換性は保たれます。
既存の項目の仕様変更	この仕様変更は互換性を保つことが出来ない可能性がありますので、出来る限り避ける必要があります。もしそれでも変更が必要な場合、その項目の利用者がいるのかなど、協議会のメンバに確認するなどの対応が必要となります。
用語の追加	既存の用語に関係なく新たな用語を追加しても互換性は保たれます。例えば設備の種類にドローンが離着陸する「ドローンポート」を追加しても異存の利用者に影響はありません。
用語の定義変更	既存の用語の定義自体を変更してしまったり、既存の用語を分割して複数の用語を定義する場合です。この場合は互換性が担保できるとは限りません。例えば「遊具」と言う用語を「ブランコ」「滑り台」「鉄棒」などに分割する様な場合です。　この場合は互換性を保つためには何らかの対応が必要となります。例えば、用語を階層化するとか、分割する用語を採用するのは特定の施設に限るなどです。どちらにせよ、協議会や関係WGのメンバに諮り対応を決めていく事になります。