takashi-ntさんのページ | デジタル改革アイデアボックス

あなたと創るデジタル社会

デジタル改革アイデアボックス


takashi-ntさんのマイページ

ウェブサイト
http://systemfa9.com
自己紹介文
公共システムのシステム開発を20年近く行ってきました。 特に、保健所のシステム開発を行うなかで、医療期間との連携に強い懸念を抱いていました。 今回、保健・医療統合システムという形でご提案をさせて頂きたいと思います

投稿したアイデア 3

国と地方のデジタル基盤について

takashi-ntさん

国と地方のデジタル基盤の中で、病床情報についても触れられていましたが、医療機関との情報連携の良し悪しは自治体と該当の医師会の関係によるところが大きいと思います。 今回 国家としてのデジタル改革にあたって、日本医師会との間で情報のやりとりについてガイドラインを決められ... » 詳しく

  • 1ポイント
  • 1
  • 0コメント

保健 感染 管理 システム(再)

takashi-ntさん

一度 保健総合システムを提出させて頂きましたが、データの一部に不備がありましたので再度提案させて頂きます 今回のコロナ禍で明らかになったのは、 pcr検査→本人通知→隔離先管理→感染者フォロー という流れを保健所の人的パワーに頼っていた流れに注目して次の図を作成しました ... » 詳しく

  • 2ポイント
  • 2
  • 0コメント

保健総合システム

takashi-ntさん

今回のコロナ感染の中で 保健所 と医療機関の連携が重要だと思い、 健康保健システムを考えました 詳細は下記のurlに概要図を上げました ポイントは 次の点です 1 pcr検査で陽性が判明した場合、医療機関の情報を把握して、適切な保護を行う 2 陽性者のフォローは、itを活用... » 詳しく

  • 2ポイント
  • 2
  • 0コメント

お気に入りアイデア 0

まだお気に入りがありません。

投稿したコメント 34

[事務局]第3回データ戦略TFへのご意見をお願いします。

#030
本日の日経に今国会に自治体の仕様を統一する法律を提出する記事が出ていました だんだんすごいことになってきました

by takashi-ntさん - 2020/12/03 19:28 問題を報告

工程表を観まさせて頂きした。かなり盛り沢山の内容になっていますね。
気になったのは データモデル作成のプロセスと推進の仕組みを同時に進めて
いくのは、工程として無理がありませんか まずデータモデルを作成してその検証をしてから推進の仕組みを作成してはどうでしょうか データモデルを作成するプロセスでもかなり色々な問題が生じると思いますが

by takashi-ntさん - 2020/12/02 11:31 問題を報告

データ戦略へのご意見をお願いします!![事務局]

#133
今回のデータ戦略は、全てで100点満点を取ろうとするのではなく、80点でも
早期にリリースをすることを目指すべきでしょう。 よしんば、データ戦略で100点のベースレジトリーができたとしても それはシステムを作る側の自己満足になってしまう可能性もあります。それよりもuiを含めたシステム全体をリリースして
ユーザーの判断を仰ぐ方が より多くの人に使われていくと思います

by takashi-ntさん - 2020/12/01 10:06 問題を報告

#131
データ戦略の方向性ですが、平井大臣や河野大臣のお話から察するに、次の様な手順でデータを整備していく方向が望ましいのではないでしょうか
1 行政手続きに関係するデータを整備する
2 保健、医療に関係するデータを整備する
3 不動産情報、立地情報などを整備する
4 外部のオープンデータを取り込む
これらを整理して作業を進めていく方向がいいのではないでしょうか

by takashi-ntさん - 2020/11/29 10:20 問題を報告

#128
システム開発の現場では、よくある議論を尽くすというシステム技術者の陥りやすい問題だと思います。 私が参画したシステムで明日カットオーバーという日に
いきなり打ち合わせを初めて、結局朝までかかりました。
今回のデータ戦略の資料を拝見していると、そのことが脳裏をよぎりました。
以前にも 工程表を作成させていただいたのは、少なくとも大日程だけでも
作成した方がいいのではないでしょうか。
携帯電話も ガラケイの時代にnttの仕様を全てテストを完璧にする為に 膨大な工数を行っていました。 これに対して、スマホの時代になるとbest effort という形で進めて行きました。 これがスピード感に繋がったと思います。
以下のurlに工程表をあげています。https://drive.google.com/file/d/1yUXvGrnOG9gcP9lvlxOdKRdFiCbazSD6/view?usp=sharing

by takashi-ntさん - 2020/11/28 11:23 問題を報告

#126 少し説明がたりませんでした。 このアメリカの話は、自動運転技術の先の話として、スマホ呼び出し配車システムの事業があります。 彼らは、本気で近い将来そういうことが起きると真剣に思って事業化しているのです。 この辺りがアメリカの底力の様な気がします

by takashi-ntさん - 2020/11/27 18:49 問題を報告

#124 現実にアメリカでは、evとカーシェアリングを組み合わせでいつでもどこでも車を呼び出せるシステムを本気で試作している企業があります。 その構想で
は今の駐車スペースの90%が不要となる試算があるそうです。

by takashi-ntさん - 2020/11/27 10:51 問題を報告

[事務局]第2回データ戦略TFへのご意見をお願いします。(データ整備)

#016 想定されていないケースが出てくるというのは、システム開発では起こりえることでしょう。 その為に、今回のコンセプトであるuiから作成するという開発方式をとって、ui ⇄ベースレジストリー の連携を蜜にする必要があるのではないでしょうか。 これからの工程も優先的なプロジェクトを抽出して、進めていき問題点を解消しながら進めていく方式がいいのではないでしょうか。

by takashi-ntさん - 2020/11/15 05:34 問題を報告

#011 和暦 西暦 問題は、2000年問題の時にシステムの内部的には西暦になっているハズですが、これも前例主義の一つですかね

by takashi-ntさん - 2020/11/13 08:58 問題を報告

今後の工程ですが、ベースレジストリー に優先順位をつけてグループごとに
ベースレジストリーを作成していく方法がいいのではないでしょうか
以下のurlに工程案を挙げさせて頂きました
ご確認ください
https://drive.google.com/file/d/1yUXvGrnOG9gcP9lvlxOdKRdFiCbazSD6/view?usp=sharing

by takashi-ntさん - 2020/11/12 15:55 問題を報告

データ戦略へのご意見をお願いします!![事務局]

#115
第2回の資料が公開されたら コメントしてください。

by takashi-ntさん - 2020/11/09 16:43 問題を報告

#112
デジタル改革のチームとしては、一度にはできないので国や地方公共団体から
進めていくのでしょう。 この欄に寄せられた意見にも様々なデータがありましたのでデータ整備と並行して、ベースレジストリーデータの分類を行われたらいかがでしょうか。

by takashi-ntさん - 2020/11/07 15:18 問題を報告

#110 政府や地方公共団体のオープンデータ、パーソナルデータの整備を優先的に行い、それをベースに作業を進めていくということでしょうか。
保健医療のシステムを考えると、医療機関とのデータ連携が必要となると思いますが、それは次のステップということでよろしいでしょうか。

by takashi-ntさん - 2020/11/07 14:43 問題を報告

#108  データ戦略の策定に当たって、このタスクフォースのアウトプットとしては
どの様な地点を想定されているのでしょうか。
1 ベースレジストリー の基本的な枠組みを決定
2 ベースレジストリー のデータ構造を決定
3 今後のサービス開発への橋渡しとなるベースレジストリー の作成
それぞれによって、議論の論点が変わっていくのではないでしょうか

by takashi-ntさん - 2020/11/07 12:32 問題を報告

#105  ベースレジストリー と一括りにしていますが、現状で使用可能ものは
使用する様な切り分けが必要ですね。

by takashi-ntさん - 2020/11/06 09:46 問題を報告

ベースレジストリー の進め方について、内閣官房様のご意見のなかで気になった点があったので。述べさせて頂きます。
1 スケジュールについて 
   スケジュールは年内を目標に作成されるということですが、それはベースレジストリーの内容が決まらないので、作成できないのでしょうか。 今回のプロジェクトを進めるに当たって平井大臣が仰っていたユーザーインターフェイスを決めてからデータを決めるという方式をとるのであれば スケジュールを決める際にも
その様な配慮をする必要があるでしょう。
2 ベースレジストリー とユーザーインターフェイスについて
   今回のプロジェクトでは、ユーザーインターフェイスとベースレジストリー が常に緊密に連携をとりながら進めていくのが望ましいと思います。

by takashi-ntさん - 2020/11/06 07:02 問題を報告

ベースレジトリーのデータの扱いですが、個人データなどのマスター的なデータとGPSなどのトランザクションデータは、扱いは分けた方が扱いやすいのではないでしょうか。
ベースレジストリー には、官のデータと医療機関の情報などの民間のデータも同じ扱いにするのでしょうか。
以上のことを踏まえて概要図を作成してみました。https://drive.google.com/file/d/1zP5QkhMIof4BwUExgSGpUgeDWn6W7mlw/view?usp=sharing

by takashi-ntさん - 2020/11/05 13:58 問題を報告

データ戦略の資料をみて 私なりのスケジュールを作成してみました
ご参考までにご覧ください
https://drive.google.com/file/d/1PZfLTnm0YabF8FYXCTe9diG4zKl958H4/view?usp=sharing

by takashi-ntさん - 2020/11/03 15:20 問題を報告

#089 これからだとは思いますが、この資料には どの様な時期に何をするという
工程案がないのが残念ですかね

by takashi-ntさん - 2020/11/03 10:35 問題を報告

データ戦略の一番のポイントは、ベースレジトリーをいかに充実したものにするかどうかでしょう。 それには、いろんな機関から情報が集められるかでしょう。
と言っても霞ヶ関のメンバーがハイハイと情報を提供するとは思えません。
ベースレジトリーを作成する際に、身近で小さなカテゴリーから初めてはいかがでしょうか。そのカテゴリーでサービスを開始するような方向で進めてはいかがしょうか。

by takashi-ntさん - 2020/11/03 04:36 問題を報告

#086 マイナンバーは、アーリーサクセスの戦略で出てきたと思いますが、本丸はデータ戦略に基づいてベースレジストリーを構築することではないでしょうか。
私が、この漢字の問題を上げたのは、メーカーごとのjis第2水準を超えた漢字コードは、よく間違えて変換されてしまうことがあるということです。この問題は、外字みたいに字が化けてしまうと問題がわかりやすいのですが、第2水準準拠の漢字は、もっとらしい漢字に化けて発見が難しいということです。

by takashi-ntさん - 2020/11/02 21:00 問題を報告

はしご高、複数の渡辺などの旧字体廃止

#023 自治体の漢字のなかで、旧字体の漢字が大変ではなく戸籍に登録する際に独自の漢字が登録してしまったことにあると思います。
このような漢字は、現在使われていない漢字もかなり存在するのではないかと思います。  このような漢字は、本人に確認して類字に置き換えていくというのも一案だと思います。 但し、本人に確認せずに漢字を変えることは問題ですね。

by takashi-ntさん - 2020/11/01 10:48 問題を報告

データ戦略へのご意見をお願いします!![事務局]

日本のデータ戦略が外国に比べて遅れている問題の1丁目1番地は、漢字の取り扱いではないかと思います
漢字の取り扱いをまとめましたhttps://drive.google.com/file/d/1D3gflLcF1ZQHegZUy4VTeoDrS8lZaJ7t/view?usp=sharing

by takashi-ntさん - 2020/10/30 22:55 問題を報告

はしご高、複数の渡辺などの旧字体廃止

#014 日本独自の漢字の問題は、ハードウェアメーカーの漢字コードが全面変換対応でないことと、戸籍で使われている漢字を使っていることがあると思います  その辺を以下にまとめました
https://drive.google.com/drive/folders/1gf4fDn8T6swgTOGmA873OOIfFCXkS-uM
少し 話がずれますが、携帯電話がガラパゴス化した一つの要因として 船舶用通信の仕様をドコモが引っ張って全体の仕様を重くしたことがあります
この際、戸籍の漢字を忠実に再現するという呪縛から逃れたらどうでしょう

by takashi-ntさん - 2020/10/30 18:43 問題を報告

データ戦略へのご意見をお願いします!![事務局]

データ戦略を諸外国と比較する上で、大きな足かせとなるのが、縦割り行政と
漢字コードの問題ではないでしょうか
漢字コードの問題と解決方法についてまとめてみましたhttps://drive.google.com/drive/folders/1gf4fDn8T6swgTOGmA873OOIfFCXkS-uM

by takashi-ntさん - 2020/10/30 17:15 問題を報告

はしご高、複数の渡辺などの旧字体廃止

#012
自治体が独自に使っている外字は、戸籍で使われている漢字を再現しようとして作られた物でしょう。 この漢字については一度本人確認を行い、現在も使用されているのなら、戸籍の表示は今の外字をイメージデータとして使用し、通常の住居表示は類字の漢字を使用する了解を得る方法がいいのではないでしょうか

by takashi-ntさん - 2020/10/30 16:19 問題を報告

UI/UXに優れた使いやすいシステム/サービスを作るにはどうしたらよいか(第2回対話を受けて)

#014 今回のような未知のシステムを作っていく場合は、スパイラルで開発を進めることが望ましいと思います。 今回私が言いたかったことは、
uiの設計を進める際に、ドキュメントをベースに進めるのではなく実際の画面を見ながら進めていく方法がいいのではないでしょうか。
実際のシステム開発を進める際には、htmlベースで画面を作成して設計していく方法がいいのではないでしょうか。 その時には、データベースもできていないでしょうし、処理部分もできていないでしょう。
しかし、ユーザーのイメージを明確にするには十分でしょう

by takashi-ntさん - 2020/10/30 13:00 問題を報告

#008  開発の予算を要求する際に、アジャイル方式で開発する際にはその予算を考えて予算取りをしてもらう必要があります。 注意しなければいけないのは
自治体などの公共系システムでは、予算を決めるのは前年度だということです。
民間のように予算をすぐにとることはできないということです。

by takashi-ntさん - 2020/10/30 07:11 問題を報告

#005 uiの設計でいくら綺麗なドキュメントを作成しても実際の画面を見ると意見が変わることは、日常茶飯事です。 というより一般のユーザーがドキュメントを見て実際の画面を想像することはできません。 実際の画面を見せて確認することが望ましいと思います。
システム開発を行う際に、ウォーターフォール型でデータを決めてから画面を設計する方式は、変えていくことが望ましいと思います

by takashi-ntさん - 2020/10/30 07:05 問題を報告

確かに作って終わりという側面もあると思いますが、公共系システムにおいて
小さく作って大きくしていくような形の予算がとり難い一面もあると思います。
ハードメーカーであれば、ハードのメンテナンス費用の中にソフトウェアの
メンテナンス費用を盛り込むというような形で費用を組み込むことが多いのでは
ないのでしょうか
近年、財政を圧縮するということで費用が圧縮されたのではないでしょうか

by takashi-ntさん - 2020/10/29 17:03 問題を報告

No one left behind(誰一人取り残さない)

システムを作ることを自分の技術を発表する場所と思っている人が
多いのでしょう 。
システムは、使ってもらってなんぼです。 ユーザーが使い安く設計することを
勘違いしているのかもしれません。

by takashi-ntさん - 2020/10/29 15:00 問題を報告

はしご高、複数の渡辺などの旧字体廃止

自治体で、オープンなシステムを実現する場合に問題になるのが住所、氏名を
共有できないということです。 その中で問題となるのが、漢字コードではないでしょうか。 
自治体の漢字を難しくしているのが、1 コンピュータメーカーごとにJis第2水準
を超えた漢字 Jis 第2水準準拠という部分が異なることです。 この問題は、各メーカーが協議して漢字コードのテーブルを作成すればできると思います。
もう一つは、戸籍で受けつけた漢字を使用するという点です。
この漢字について、本人確認を行い戸籍の表示以外は、類字を使用することを
承諾してもらうことです。 システム的には、戸籍のみ使う漢字はイメージデータとして扱い、戸籍を表示する時のみイメージデータを使用し、それ以外は類字を使うという方法がいいのではないでしょうか。

by takashi-ntさん - 2020/10/29 05:53 問題を報告

この漢字の問題は、戸籍の漢字と同じモノを表示するということに起因しているのではないでしょか 戸籍の表示と通常の住居表示を分ければ 問題は簡単になるでしょう

by takashi-ntさん - 2020/10/28 04:46 問題を報告

梯子高などの漢字は、いわゆる外字の問題と思われがちです。 それよりも根深いのは、システムを導入しているメーカーごとにjis第2水準以外のjis第2水準準拠と呼ばれる漢字コードが各メーカで異なることです。
この部分を各メーカーが変換テーブルを作成して漢字が変換できれば、純然な外字だけならば、この問題は解消できるでしょう

by takashi-ntさん - 2020/10/27 16:02 問題を報告

投票履歴 5

保健総合システム

高評価コメント 1

他のユーザからの評価(★の数)の平均が4以上のコメントを表示しています。

評価の平均値
5
コメント日時
コメントしたアイデア

はしご高、複数の渡辺などの旧字体廃止

梯子高などの漢字は、いわゆる外字の問題と思われがちです。 それよりも根深いのは、システムを導入しているメーカーごとにjis第2水準以外のjis第2水準準拠と呼ばれる漢字コードが各メーカで異なることです。
この部分を各メーカーが変換テーブルを作成して漢字が変換できれば、純然な外字だけならば、この問題は解消できるでしょう

ページの先頭へ