板に戻る 全部 本家 最新10 1-

組織横断番号 @00083

1ONGAENZOU 2020/10/09 20:47 ID:542
省庁には、書類や作業に番号付けを行っています、当然組織横断番号になっていません。
省庁それぞれにある番号に、横串を通す番号体系を考えなければなりません。
そうしないとデーターが機能しないからです。
#省庁横断型番号 の付番、そしてデーターを機能させる事です。


組織横断型システムの設計には、数学力・論理代数学的素養が要求されます。
世界的規模でのインターネットおよびデーターベースの構築運用経験が必要です。
受け手に回る官僚側にも、同様の素養が要求されます。

縦割りの打破は、各省庁、地方自治体で必要なデータを検索、利活用出来ることです、公文書が利活用出来ていれば、管理も自ずと出来るようになります、利活用の乏しい物を厳重管理せよと言っても、誰もやる気にはなれません。
もちろん機密保持は重要です、利活用が進むのは良いが、勢い余って機密が漏れてはなりません。
省庁横断型番号には機密のレベル、公開のレベルも含まれねば成りません。
2m.hidehiro 2020/10/27 14:10 ID:c67
反対
番号だけなら変に意味あり番号で、妙な番号管理システムを稼働させるより、UUIDにしてしまったほうがいい気がします。
3ONGAENZOU 2020/10/27 15:19 ID:542
賛成
>>2 早速のコメントありがとうございます。
私としては、トップレベルドメイン(TLD : top-level domain)のような体系を考えていたのです。
番号と言っても、英字、数字、日本語などが入り、構造化されていて、人間でも可読できるものと考えています。
体系を組むのは難しく、インターネットの専門知識を持ち、世界規模でのシステム運用経験者など、設計に参加する必要があります。
4m.hidehiro 2020/10/27 16:57 ID:c67
反対
>>3

意味あり番号付与は明確に反対です。
反対に切り替えました。

意味あり番号には多く問題点がありますが、代表的な所を。
まず、変化に非常に弱い。省庁再編の度に番号体系を修正といった事になります。

また、意味を持たせるとシステム外の影響で番号変更が起きます。結果、システムでは内部的に別途意味なしユニークID付与する事になります。この場合、情報を番号っぽく表示しているに過ぎません。

ですので、そのユニークIDをそのまま使い、属性を結びつければよいのです。

番号から情報照会できれば番号に意味は不要です。それこそITの力でQRコード等で照会すればいのです。
意味あり番号はそれができなかった時代のもので、デジタル化を前提とすれば不要です。

説明してるサイトありますのでご紹介します。
brevis.exblog.jp/2615881/
www.otsuka-shokai.co.jp/..oku-code-taikei.html
5ONGAENZOU 2020/10/27 18:25 ID:542
賛成
>>4 返信ありがとうございます。
確かにおっしゃられるとおりです。
トップレベルドメイン(TLD : top-level domain)を引き合いに出しましたが、TLDの後ろにはIPアドレスがあるわけで、IPアドレスには領域の大きさに応じて、クラスはありますが、一意番号です。
その意味では、一意番号があって、番号を名前付けする形にするのが合理的です。
名前は辞書を変えることで(IPアドレスで言えばDNSを変更する)組織変更に対応できます。
m.hidehiroさんのコメントに同意します。
6m.hidehiro 2020/10/27 18:35 ID:c67
反対
>>5
その場合、わざわざ番号風の名前にする必要はないのではありませんか。
例えば

日本-デジタル庁-0010-ABCD-xxxxxxxx

というような表示より

所管:デジタル庁
分類:一般文書
部署:ABCD課
通番:xxxxxxxx

と直接表示された方が人間の可読性がよいと思われます。
その番号風の表記を作っても、二重管理になるだけでメリットがないです。
7ONGAENZOU 2020/10/27 18:55 ID:542
賛成
>>6 早速のコメントありがとうございます。
検索のやりやすさを考えたとき、日本-デジタル庁-0010-ABCD-xxxxxxxx{検索}のほうが良いのではと思うのです。
検索時の表記には、一部を正規表現にすることで、複数の対象をピックアップ出来るようにします。
機密文書の場合、機密レベルによって、その旨をメッセージする、存在その物が機密の場合、検索対象にしない、などです。
私が提案した趣旨は、「データーを機能させる事」にあります。
検索や、データーを加工しての集計、Ai的発想として、検索結果を教師データーとして、問いかけ(クエリー)に対する抽出、近未来予測などでデーターをより活かすことです。
8m.hidehiro 2020/10/27 19:08 ID:c67
反対
>>7

よくわかりませんが、検索したいならば、

所管:[ (入力欄) ]
分類:[ (入力欄) ]
部署:[ (入力欄) ]
通番:[ (入力欄) ]
【検索】

と言うフォームのほうが明らかに分かりやすいと思うのですが。紙の台帳ではないのですから。
仮に、一行で入力させる方式が良いのならば、フォームをそのように設計すればよく、番号そのものをそのようにする必要はないと思います。

機密文書等は意味なし番号であろうと意味あり番号であろうと、属性情報として持たせるべきものであり、そのために番号を意味ありにする必要はありませんし
むしろ、番号から機密情報であることがわかったら全く意味がありません。
セキュリティならば、番号から情報が漏洩することも意味あり番号の欠点の一つです。

データを機能させると言う理念はわかりますが、そのための方法に意味あり番号にするのは逆効果ではありませんか。
もしそうしなければデータが機能しなくなると言うお話ならば、それらについての詳細をご教示いただければと思います。
9ONGAENZOU 2020/10/27 20:54 ID:542
賛成
>>8 コメントありがとうございます。
番号に機密属性を持たせると言うことでは、ありません。
例えば末尾が9999で有れば機密としたら、ここに機密がありますと宣伝していることになります。
検索キーは一意番号またはニモニックの他、タイトルや本文に含む、文字列でも良いわけです。
一意番号は、検索結果にヒットした場合、表示されるものであり、機密故にヒットしなければ、何も表示しなくて良いわけです。
もちろん一意番号又は番号に割り当てられたにもニモニックを、知っている人が入力した場合、閲覧可能であれば、その文書またはそのありかを返す、機密であればレベルに合わせて、メッセージを返すか無視するかです。
一意番号又は割り当てられたにもニモニックも含め、一行表示の方が、わかりやすいと思います。
ideabox.cio.go.jpとするのと
[内閣官房]
[IT担当室]
[デジタル改革アイディアボックス]
[88889999]
とするのと、どっちが使いやすいか、と言うことだと思います。
10m.hidehiro 2020/10/27 21:26 ID:c67
反対
>>9

わかりにくかったようで申し訳ありません。
私のコメントの趣旨は、検索に意味ありの番号は関係ないのではないかと言うことであり、細かな検索の仕様なり、表現の方法を指摘しているわけではありません。

セキュリティについても、仰るお話は、番号に意味を与えたら問題があると言う事を補強しているように思うのですがいかがでしょうか。

また、仮に「一行表示の方が、わかりやすい」と言う意見が有るとしても、それは属性をそのように表示すればよいだけであって、番号を紙台帳で管理していたような時代に戻す理由にはならないと思います。
データと表示方法を分けて考えるのはIT化の基本だと思いますがいかがですか。

繰り返しになりますが、そういった枝葉ではなく、そうしなければデータが機能しなくなると言うお話があるならば、それらについての詳細をご教示いただければと思います。
11ONGAENZOU 2020/10/28 01:46 ID:542
賛成
>>10 コメントありがとうございます。
 >>検索に意味ありの番号は関係ないのではないかと言うことであり
それはその通りだと思います。
 >>データと表示方法を分けて考えるのは
データー本体、その存在場所(例えばブロックチェーン上のどこか)、一意の番号、一意の番号に対応するニモニック、各要素についてそのあり方を個別に設計し、統合してゆくのが手順だと思います。
データーを機能させると、データーがもれなく管理できるは、別々の設計になると思います。
12sophia 2020/10/28 20:29 ID:54b
素朴な疑問なのですが、
文書番号ってそれが一意に決まればそれで良くないですか?

いつ何処が出した文書か文書番号を見てそれが分かるほうが便利に思うのですが、で、現状そうなっていると思うのですが、

組織横断番号が必要な理由が今ひとつピンと来ないのです。
13m.hidehiro 2020/10/28 21:15 ID:c67
反対
>>11
バズワードを並べていらっしゃいますが、番号を意味ありにしなければそのような複雑な事情を巻き込んだ事をする必要がないのではありませんか。

>>12
統合番号の必要性は、マイナンバーと同じだと思います。
今の縦割り行政や、データの寿命が短命で他で活用しない前提とすれば不要なのかも知れませんが、それは目指している所ではないのではありませんか。
14sophia 2020/10/28 22:23 ID:54b
>>13

いま簡単に見てきました。私は役所関係の者ではなく元IT屋です。

厚生労働省の通達に
健政発第xxx号
医薬発第xxxxxxx号
のような振り方がされていて、

法務省の通達に
民商第xx号
法務省矯総第xxxx号
のような振り方がされています。

発信者ごとに重複しない番号が振られていればどの文書か特定できますし、発信者ごとに重複しない名称(健政とか医薬とか民商の部分)になっていれば一緒くたに登録されていても検索は可能で他の役所の文書から引用も可能と思うのですが、

DBに登録する際に内部的に一意になるように番号を振るのでしたら、それは必要とは思いますが。
15kareidscope1123 2020/10/28 23:37 ID:96a
>>13 統合番号って必要ですか
利用パターンが全く想像できませんが
現状>>14のようにすでに体系的な番号付がなされています
これで十分なのでは?
強いて言うなら番号は一年でリセットされるため、同じ文書番号の文書が発出されることになりますが
大抵「令和○年○月○日付け○○○第○○号」という使い方なので、日付まで入れればユニークな番号になります

現状から何が足りてないのでしょう
16ONGAENZOU 2020/10/29 04:43 ID:542
賛成
>>14 コメントありがとうございます。
 >>DBに登録する際に内部的に一意になるように番号を振るのでしたら、それは必要とは思いますが

投稿の目的は 『公文書が利活用出来ていれば、管理も自ずと出来るようになります』にあります。

そのためには公文書の総目次が必要ではないかと考えたのです。
手書きなど非電子化文書でも、目次に相当する部分は、DBに入れておくべきと思います。
これが出来ていれば、検索も一発で出来ます。
文書その物には、保管期限があり、期限で廃棄されますが、文書の存在を示す記録は、永久保管で必要と思います。
廃棄された場合でも、文書のタイトルや前書きの要約、廃棄に関わった組織などの記録は総目次として残すべきと思うのです。
一方で一覧性が高くなると、機密保持の問題が出てきます、機密保持はその考え方をきちんと作り込まないと、いけないと思います。
17ONGAENZOU 2020/10/29 04:56 ID:542
賛成
>>13 コメントありがとうございます。
 >> データの寿命が短命で他で活用しない前提とすれば不要なのかも知れませんが、それは目指している所ではないのではありませんか

目指しているところではありません。
総目次DBを作り、文書には期限があっても、目次その物は永久保管して文書の利活用を図ることにあります。
18m.hidehiro 2020/10/29 10:17 ID:c67
反対
>>14
>>15

アイデアを出されている方の意図と違うかもしれませんが、私としては、でお話します。基本的にはPLMの概念に近いものです。

表に出る従来ナンバリングされているような書類以外でも、全ての情報資産にIDを付けて管理追跡活用出来るようにする、と言う事だと思っています。
IDを付与できるのは、書類に限らず作業指示、録画録音、写真など、基本的には情報資産すべてです。

そうして付けられたIDは、その情報が生産された時から一意のIDで、廃棄までずっと同IDで表されます。なので、公文書アーカイブまで考えると、無限に近い数と、半永久的に使える番号体系である必要があります。
故に、複雑な意味あり番号にすると管理が破綻します。また、UUIDのように一定の規則に従えば、独立して発番できる仕組みである方が望ましいです。

内部IDで十分ではと言うご指摘ですが、便宜上見やすいように従来型の整理記号を付与することはあっても、正式番号は統一IDで定義しなければ多重管理になると思っています。
19kareidscope1123 2020/10/29 12:36 ID:96a
>>18
012の番号付になんの問題があるんですか?
その機能であれば運用を変えるだけで機能するかと思います
要は[年月日]-[省課室等]-[文書番号]というデータフォーマットなだけですから
一意に定まり、ほぼ無限の数があり半永久的に使用できるでしょう
20m.hidehiro 2020/10/29 13:10 ID:c67
反対
>>19

その番号体系の場合、例えば部署が統廃合になると、そのたびに体系が変わっていきます。組織名を入れた次点で、番号が新たに生まれる事は、組織の寿命より短くなります。
保管するだけで考えるならばそれでも良いような気が資するかも知れませんが、それを引き継いだ他の部署がそのデータを利用したらどうなるか。
一意の番号で決まる必要があるので、データ保存や利用の観点からは番号は変更できないのですが、実際にはそういった運用は難しいのではないでしょうか。

また、番号が他と被っていない事をどのように保証したら良いでしょうか。例えば、北区、は日本に10箇所以上あるようです。これを区別できる様にしていくとなると、住所を全部入れるような話になっていきます。
そして、これには時間軸もあります。現在過去は少なくとも、そして未来もできる限り考えて被らないようにしなければなりません。その区別を日付を使ってやるのは妥当でしょうか?
例えば、過去の情報資産に番号を付けて整理するときはどうしたらよいでしょうか?

と言い始めたら切りが無い感じで理由はたくさんあります。
21HCODEV 2020/10/31 16:43 ID:915
反対
秘密情報等を記録する行政文書の一覧表|内閣官房
www.cas.go.jp/..nri/dai2/siryou2.pdf

相当カオスですよね。

保管方法、複製、情報取扱区域、提供、送達方法、廃棄方法等は番号に含めず、別パラメータとして構造化・半構造化データで持つのが良いでしょう。
22kareidscope1123 2020/10/31 20:34 ID:96a
>>20
上げられた問題は問題になっていないように思いますが。
>部署の統廃合
[省課室等]の部分が変更になりますね。
過去の資料は旧課室名のままの番号で利用すればいいだけでは?
法令上でも建設省第何号とかの文章が有効のまま使われていたりします

>番号が他とかぶっていないこと
地方公共団体コードを先頭につけておけばいいのでは?
課室等については組織内で調整すれば十分でしょう。
文章自体には発出元の組織が示されてるので、書面に記載する文書番号としては非表示にしておいてもいいので。

>時間軸
西暦を入れておけば9999年まではかぶりませんね。
別に4桁にこだわらずとも桁を増やせばいくらでも対応できますし。
23ONGAENZOU 2020/10/31 20:55 ID:542
賛成
>>21
早速のコメントありがとうございます。
他の方のご意見にもありますが、文書の属性情報は、一意番号やその番号に対応するニモニック(IPアドレスとURLのような関係)とは別の話だと思います。
いわゆるメタ情報をどこにどう持つか、別個の設計になると思います。
電子化されない文書や、廃棄済み文書も、存在記録は残しておく必要があります。
24m.hidehiro 2020/10/31 22:54 ID:c67
反対
>>22

全般に、発刊番号の話をしていると勘違いされていませんか。過去の文書の話を拝見して、どうやらそこからズレているような気がいたしました。

また、現状で問題が無い、と言う事を仰りたいのだと思いますが、全般に、現状で問題であるから、デジタル庁の発足と、それに伴うアイデアを募集している、と言う前提に立っていただくというところかなと思います。
その上で、


>番号が他とかぶっていないこと
>地方公共団体コードを先頭につけておけばいいのでは?

ご自分で仰っていただいていますが、横断で使うと言う前提なので、

>課室等については組織内で調整

となってしまう時点で、十分ではありません。

>時間軸
>西暦を入れておけば9999年まではかぶりませんね。

単純に時間を識別番号を使ってはいけない、と言うのはシステム設計の基本だと思いますがいかがですか。
あらゆる情報資産全般に使用するので必ず衝突が起きます。過去の情報資産を整理する場合には使えないコードになります。
25ONGAENZOU 2020/11/01 00:15 ID:542
賛成
>>22
最初に言い出しましたONGAENZOUです。
一連の論議、番号が一意の連番である必要があるか、の問題だと思います。
組織横断が前提で、一括管理のためですから、例えば同じ時間に同じ部署から発番依頼があったときなどを考えていかなければ成りません。
もう一つは飛び番号が許容できるかの問題があります。
飛び番号があると、番号と番号の間に、別の番号が入り込む余地があるので、順序列が確保できなくなる恐れがあります。
発番メカニズムを一カ所に集中させ、順序の列を確保する必要があります。
文書管理の場合、廃棄文書もその存在過程をの残す必要があるので、一度出された番号は永久使用(再割り当て禁止)となります。
タイトル、組織属性や、機密属性、文書の要旨などは、メタタグとして別途管理する必要があります。
最終目標は、データーを機能させる事にあります。
26kareidscope1123 2020/11/01 00:25 ID:96a
>>24
私のスタンスとしては、文書管理について横断的なデータベースに集約するというのは一定の理解をしますが、
そのためにわざわざ新しいスキームを作る必要はないと考えます。(多少の運用変更で十分対応可能と思う。)

>現状で問題であるから、デジタル庁の発足と、それに伴うアイデアを募集している、と言う前提
問題提起と解決法の提示、それに対する賛否、第三の方法の提示全て含めてアイデアボックスだと思いますが。

>横断で使うと言う前提なので、十分ではありません。
何が十分でないのですか?
地方公共団体コードも付加すればユニークなIDが振られますよね。

>単純に時間を識別番号を使ってはいけない
あなたが提案したUUIDも時間をキーにしてますよね。
27kareidscope1123 2020/11/01 00:40 ID:96a
>>25
>例えば同じ時間に同じ部署から発番依頼があったときなどを考えていかなければ成りません。
現状の文章管理システムで対応されています。同時に発番依頼が来た場合は当然別の番号が振られます。

>順序列
現状の文書管理システムで対応されています。ただし、現行システムだと文書番号の順序と文書の日付が前後することがあります。(番号の確保は起案時に行い、文書の日付は決裁時の日付となるため、決裁にかかる時間によって前後する。)

>メタタグとして~
何かしらのデータベースに登録するでしょうから、そこに登録されることになるでしょう。
28ONGAENZOU 2020/11/01 01:02 ID:542
賛成
>>27
早速のコメントありがとうございます。
教えてください
 >>現状の文書管理システム
誰がシステムを作り、誰が管理していますか。
 >>順序列
kareidscope1123さんが言われる順序とは、どこを起点にした順序ですか。
組織内順序ですか、官公庁全体組織集合ですか、地方自治体まで含みますか、それとも官民合同組織まで含みますか。

お手数ですが、回答いただければ幸いです。
29kareidscope1123 2020/11/01 10:29 ID:96a
>>28
>誰がシステムを作り、誰が管理していますか。
総務省で整備している「一元的な文書管理システム」です

>どこを起点にした順序ですか。
各課室ごとに連番が振られています。

少なくとも国ではそういうシステムが10年程前から稼働しています。
30m.hidehiro 2020/11/01 10:59 ID:c67
反対
>>26

>>24 でも指摘していますが、文書管理のIDと言う理解は間違いです。

繰り返しになりますが、現状で問題であるから、デジタル庁の発足と、それに伴うアイデアを募集している、と言う前提に立っていただくというところかなと思います。
アイデアと議論で既に「問題提起と解決法の提示」は行われています。
それに対し、あなたは「問題と解決方法」をせずに、既存で十分と言っているに過ぎない状況です。
客観的に情報資産管理は十分ではないと思います。
自治体コードを付与する、と言った話もされており既存の仕組みは不十分と理解され始めている所は伝わってきますが、あと一歩です。もう一度議論を読み返してみて下さい。

もし、第三の方法としてデジタル化が不要だとするならば、せめて「問題提起」について丁寧に網羅的に理由を明らかにしていただけると議論がより深まると思いますがいかがですか。

>あなたが提案したUUIDも時間をキーにしてますよね。

はい。ですがUUIDは単純に時間を使ってはいませんので問題が無いです。
31kareidscope1123 2020/11/01 11:29 ID:96a
>>30
>既存で十分と言っているに過ぎない状況です。
そうです。既設で十分では?といっています。
問題提起されていはいますが、現状のシステムで十分対応できるのでは?という意見です。
だから何が問題だと考えているのか確認しているのです。

情報資産管理が不十分だというのには同意しますが、新しい番号システム・データベースを一から構築すべきという意見には同意できません。
自治体コードの付与程度であれば少々の改良で済むでしょうから

>ですがUUIDは単純に時間を使ってはいませんので問題が無いです。
私の示したIDも単純に時間を使っていないから問題ないですよね?
32ONGAENZOU 2020/11/01 12:42 ID:542
賛成
>>29
早速のコメントありがとうございます。
もう一つ質問です。
 >>どこを起点にした順序ですか。
 >各課室ごとに連番が振られています。

例えば総務省が、他省庁又は地方自治体の文書を検索したい、閲覧したいと成ったとき、検索と閲覧は、ワンストップの操作で可能なのでしょうか。
文書番号を知っていれば、その番号を入力し、番号がわからなければ、タイトルや内容から検索できるのでしょうか。
電子化されている文書の閲覧は、機密指定などがされていなければ、省庁間、又は地方自治体に断り無く閲覧できるのでしょうか。

お手数ですが、よろしくお願いいたします。
33kareidscope1123 2020/11/02 13:27 ID:96a
>>32
多くの行政文書は基本的に機密性2情報(関係者限り)になるので、他の組織から直接閲覧する事はできません
これは起案時に設定されるもので、基本的には当該課室のみに設定されています

このため、現状では組織をまたぐ文書の閲覧はできません
34ONGAENZOU 2020/11/02 15:19 ID:542
賛成
>>33
コメントいただきありがとうございます。
 >>現状では組織をまたぐ文書の閲覧はできません

デジタル改革アイデアボックスは、デジタル庁設置の準備段階での、アイデア投稿であり、機密指定でないものは、幅広く利用することが前提との考えに立って組織横断番号の投稿をしております。

事務局より発行されている「ベース・レジストリの概要」☆ www.kantei.go.jp/.._tf/dai1/siryou2.pdf において、ベースレジストリとして、官民共通のベースを作ると明示されています。

「データ戦略の策定について」 ☆ www.kantei.go.jp/.._tf/dai1/siryou1.pdf においても広く基盤を作るとされています。
もちろん今後の具体案作りで、現実的に乗せられる物はどこまでか、と言う論議はなされてゆくと思います。

組織横断的基盤は考えるべきなのだと思います。
35便器株主 2020/11/28 18:03 ID:7fc
賛成
将来的にはマイナポータルに全ての行政手続きの窓口が統一されるという構想があります。

既に日本年金機構、ハローワークがマイナポータルでのデータを受け付け始めました。

この際届け出ごとにzipファイルには到着時刻による名前が自動で振られるのですが、中身に関わらずこの時刻の数字がある意味管理番号になってしまいます。

もし今のマイナポータルの仕組みのままだとマイクロ秒迄拡張しても同じ番号が出来てしまう可能性があるように思います。(おそらく申請時刻と受け付け時刻をずらせないので…)

ですから何か新しい管理の仕組み、キーの仕組みが必要なことは間違いないです。

今のマイナポータルや新e-Govの仕様を前提にする必要はないのですが、整理すべき課題だと考えます。
36ぶんたぬきん 2020/11/28 18:26 ID:471
中立
ちょっと判断が難しいので、組織横断番号を自分なりに整理すると、
 1.一時的に利用される、国民/地域在住の方などからの申請。
 2,申請受け付け後に付番される、宛先組織内の管理番号
 3.組織間連携が必要な場合の連携用番号・・・
などのほかに、組織改編時には、項番2のトレーサビリティも必要という感じでしょうか?

何とも実現が難しい気がします・・・
菅首相の縦割り廃止にはつながると思いますけれど、実現はハードル高い気がします。

データ到着などの同時性をユニーク化する為にはシリアライズ化が必須と思います。
一方では、負荷分散には非同期分散処理が必須なのでシリアライズは困難となりますので、採番方式は困難を極めると思われます。

以下、妄想ですが・・・
国民を1億3千万として、常時1-2割で何らかのイベントが国や自治体などの複数個所で発生するとして・・・

日本国全体の規模でユニーク採番するだけで、相当大規模なクラスタが必要ですが、シリアライズ化だと負荷分散できない訳で・・・
37便器株主 2020/11/28 19:16 ID:7fc
賛成
マイナポータルの申請APIと行政側の接続APIに関する仕様はベンダーに公開されていますが、肝心のセールスフォース社のVPNの仕組みが不明なのでセールスフォースと組んだNTTデータの中の人が書き込みをしてくれないと本当のところは解りませんが、マイナポータル内にはデータを置かない仕組みなので、申請側と行政が両側でログを持たなくてはならないのではないかと思えます。

しかし恐らく中間サーバー等のようなログ監視の仕組みはマイナポータル上にはないようです。


民間の申請APIと行政の接続APIのログが相違した場合法律的にはどう扱われるかと考えると「このままでは駄目だ」というところまではわかります。

アカマイテクノロジーズに負荷分散をやって貰っても、管理の仕組みはちゃんと考えないといけません。
38雪見餅 2020/11/28 22:37 ID:8d1
中立
国の好きにすればいいと思います。
39ONGAENZOU 2020/11/29 03:23 ID:542
賛成
>>35 >>36
コメントありがとうございます。
採番については一意性の確保のため、慎重な検討が必要と思います。
この考えはデーターの保存検索再利用により、データーを機能させる事が趣旨です。
公文書など膨大な数を管理するためには、IPアドレスとURLのような関係をもった仕組みが必要と思うのです。
番号にはニモニックを振ってわかりやすい形を作る考えです、IPアドレスとURLのような関係を作れれば、と思っています。
番号割り当てと事象の発生を完全に同期させる必要があるか、各ノードから事後申請的に(時間差を伴って)行うか、いろいろ考えられると思います。
40yama 2020/11/29 03:36 ID:b83
E4=東北道、E6=常磐道、JK=京浜東北線みたいに省庁ナンバリング的な感じなら良いのでは。内閣府ならNH、経産省ならKS、とかでしょうか。今の名前は名前で、使いたい人は使う的な。
41ONGAENZOU 2020/11/29 05:53 ID:542
賛成
>>40
コメントありがとうございます。
この考えは、新たなデーターがシステムに関与した時点で(認定と採番のやり方は難しいですが)データーに一意の番号を割り付けるものです。
ニモニックは番号に対して付与します、IPアドレスとURLのような関係です。
42ぶんたぬきん 2020/11/29 10:39 ID:471
中立
>>40 ご提案は、組織横断番号を採番する、サーバの負荷分散的に効果あると思います。

申請とかの負荷が集中するのも避けられて良いですね。
府県別にサーバ分割できれば、なお望ましいです。

  投票
本家に投稿する場合はここから