tigersun2000さんのページ

大規模にAPI化を行いAPI連携によって、仕組みを作っていくような、
マイクロサービスアーキテクチャを検討し、システムの部分利用を可能にし、
別プロジェクトで作成された機能の再利用が行えるようにすべき。

by tigersun2000さん - 2017/03/31 02:22 問題を報告

紙で目視チェックを行う為に、ミスが発生し、再提出という作業が発生している。
システムの場合は、ミスがあった場合には提出時点に気づけるので、無駄な時間が発生しない。

by tigersun2000さん - 2017/03/31 02:18 問題を報告

ガイドラインが合致するかは、仕様をレビューしてもらうか、ガイドラインのチェックシステムを作って、開発した人が自分で確認できる仕組みが必要です。文章や人だと解釈が入りますが、システムには解釈の余地はありません。基本的にはシステムにチェックさせるべきだと思います。

by tigersun2000さん - 2017/03/31 02:16 問題を報告

自前主義、独自主義を捨てて、オープンに成果物を共有しながら全体最適を図っていくような仕組みづくりをすべき。それが民間にも取り入れられ、官に限らず、同様の目的を持つ組織全体で成果物の再利用・再開発。改善の取り込みが進むような社会が進めばと思います。

by tigersun2000さん - 2017/03/31 02:13 問題を報告

PC用よりもすでにスマホ向けの方がニーズが高い。
このサイトも含めスマートフォンに標準的に対応すべきだと思う。

by tigersun2000さん - 2017/03/31 02:11 問題を報告

作るところがゴールではなく、利用され、より改善されていくべきなので、
運用・改善を含め、システム開発・運用を進めて行くべき。
またその際のKPIを数値として継続的に取っていくことで、
開発されたシステムの良し悪しの比較が行える。

良いシステムをモデルとして、よりよいシステムを開発できるように、
運用も含め仕組み化していくべきだと思う

by tigersun2000さん - 2017/03/31 02:09 問題を報告

全員の合意を取っていては改革は進まないので、
政府CIO室や各CIO補佐官が積極的に責任を取って実行できるような権限を付与し、
成功や失敗を公開しながら、果断に進めていける仕組みを導入すべき。
またリスクを取る以上は失敗を許容し、次の学びとして進めていける仕組みが必要。

by tigersun2000さん - 2017/03/31 02:01 問題を報告

利用者中心の設計にすべき。

by tigersun2000さん - 2017/03/31 01:53 問題を報告

無理だと思えるような目標を立てると、やり方を改革しないと出来ないことになる、
ちょっと頑張れば出来る目標だと、抜本的な改善案は出てこない。

by tigersun2000さん - 2017/03/31 01:52 問題を報告

全員がもらえるようにすると予算的に破たんするという話を聞いたことがあるが、
申請しない人が損をする設計もどうかと思う。

by tigersun2000さん - 2017/03/31 01:50 問題を報告

#005
非常に勉強になりました。ありがとうございます。

by tigersun2000さん - 2017/03/31 01:26 問題を報告

APIさえ公開すれば使い勝手良くは民間が出来ますので、どんどん民間に任せられるようにしていただきたいです。

by tigersun2000さん - 2017/03/31 01:15 問題を報告

この意見は初めて聞きました。その通りだと思います。

by tigersun2000さん - 2017/03/31 01:13 問題を報告

日本をよくするために同一のソースコードを出入りのベンダーが一緒に編集していくような未来が来ればいいと思います。
同一目的の再開発をすべて撲滅したいです。

by tigersun2000さん - 2017/03/31 01:10 問題を報告

電話するような業務を想定するとふりがなは必須だと思います。
また名前を並べ替えるなどの業務も発生することもあると思いますので、
ふりがなは基本整備すべきだと思います。

by tigersun2000さん - 2017/03/31 01:09 問題を報告

転入届を実施したら、自動的に転出元の自治体に転出したと連動するという事ですよね。
その通りだと思います。

by tigersun2000さん - 2017/03/31 01:05 問題を報告

場所を移動して作業が出来るようにすることが、デジタル化を進めることになり、それが効率化につながっていきますので賛成です。作業の進め方としても、利便性を梃に現場の理解を得ながら進めていくべきだと思います。

by tigersun2000さん - 2017/03/31 01:02 問題を報告

やる方がいいと思うんですが、官庁の調達や契約となじまないという問題があります。
コードフォージャパンが実施した浪江町の事業では一部アジャイルを活用して開発をしていますが、以下が参考になります。

浪江町におけるタブレットを利用したきずな再生・強化事業─住民参加型の課題定義から開発プロセスまで─
https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&item_id=158454

by tigersun2000さん - 2017/03/31 00:58 問題を報告

こういう事業があります。

文字情報基盤整備事業 | IPA
http://mojikiban.ipa.go.jp/

その成果として法人番号公表サイトでは縮退マップが使われています。
ただ、なぜか外字も残ってます。文化は戸籍だけにして、住民票など実務領域は正字だけにすべきだと思います。

JIS縮退マップとは
http://www.houjin-bangou.nta.go.jp/download/

by tigersun2000さん - 2017/03/31 00:52 問題を報告

複数省庁あるから、それぞれの政策が喧嘩状態になったりするので、統合すべきだと思います。
確か、政府CIO室が出来る際にIT調達庁の話題もあった気がしますがなくなったのかな。。。

by tigersun2000さん - 2017/03/31 00:50 問題を報告

文字、語彙、APIこれをセットで整備することが肝要だと思います。

by tigersun2000さん - 2017/03/31 00:47 問題を報告

#013
　地方公共団体情報システム機構は代理店であり、『町字ファイル』は国土地理協会( http://www.kokudo.or.jp/master/index.html )の製品になります。ファイルとしては国内有数なのですが、町名字名までであり、番地まではフォローできません。

　例えば2016年12月1日に
　　神奈川県相模原市の中央区宮下本町二・三丁目の一部及び緑区東橋本三・四丁目の一部
　が
　　東京都町田市
　になりましたが、
　番地単位で市区町村合併があり、町字単位での統廃合分割などがなかった場合には、何も検知ができません。

　厳密にやりたいのですが、厳密の定義がないので、各団体でばらばらに標準化され、ばらばらな形式でデータ公開されることになっているのだと思います。

by tigersun2000さん - 2017/03/30 17:57 問題を報告

#001
使いたいというところに使ってもらえればと思うんですけどね。
例えば豊島区版があれば、政府向けの意見とは別にあります。

by tigersun2000さん - 2017/03/16 14:56 問題を報告

ちょっと趣旨が明確ではなかったです。すいません。

#001
こちら別スレッド( @0004 )でも議論されていますが、
住所で地理空間扱う事に限界があるように思いますので、
住所を定義することになる不動産登記や、住居・建物登記情報については、
生のGISデータとして公開してほしいというのが要望です。

建築許可などの申請も電子データで必要な人もいると思いますが、
本トピックの趣旨としては、生のGISデータとして公開してほしいという事です。

#002
このトピックではGISの生データを、データとして公開してほしいという事になります。
※別件としてこのサイトの登記情報のオープン化もニーズは高いと思います。

by tigersun2000さん - 2017/03/16 02:39 問題を報告

論点をなんとなくまとめてみました。間違ってたらごめんなさい。

住所の標準化に関する課題
①住所から場所の一意性を確保することが非常に困難
②住所の表記の標準化がされていない
官庁での利用に関する課題
①申請する際の住所、公開住所が標準化されていない
→データ連携する際に、利用者に住所の標準化をするための投資が必要になる
③組織によってばらばらな標準住所を利用している
→重複投資が発生している
民間での利用に関する課題
①住所から場所の一意性を確保できない為、
　法人情報から法人番号を付与することが困難
→住所の標準化がされていない為に、不正確な情報が多い
②住所正規化ファンクション、APIが整備されていない
→正規化された住所が提供される方法ではなく、
　標準化された正規化手段が提供される事でも問題は回避できる。
標準化に関する動き
①ISO/TC 211にて議論が進んでいる
　http://www.gsi.go.jp/GSI/isotc211.html
②語彙データベース基盤の住所
　http://imi.go.jp/ns/core/

by tigersun2000さん - 2017/03/16 02:19 問題を報告

#008
課題3については、その通りで、画一的な表記方法がないまま、
各市区町村が申請されたまま住所を受け付けることが、
住所情報を同一だと見分けることの困難性を高めています。

画一的な住所表記方法を定義し、組織を超えて同一住所表記を使う事で、
同一住所については、機械的に同一だと判断をすることが可能になります。

データに関しても自治体が持っていますが、システムは国が整備することもあると思いますし、
申請情報をまとめるような仕組みを作って、自治体に使ってもらっていることもありますので、
国や自治体にかかわらず、住所を使う際には標準化された住所としてデータを集めて、
標準化された住所を公開してほしいと思います。

そのうえで、公開するには申請を受け付ける際に標準化された住所を入力すると、
変換が不要になる為、最初から標準化した仕組みを受け付け時に使っておけば、
End2Endで画一的な住所を扱うことができるので、その方がよいという事です。

by tigersun2000さん - 2017/03/16 01:54 問題を報告

#008
課題2については、
『住所をキーにして検索するという考え方自体が、ちょっと実現性や正確性の面から厳しい』
という点はまず、困難性としてはあると認識しています。

しかし、現実問題、民間企業ではこれをやらないと業務が出来ないという問題があります。

取引が始まれば法人番号をもらうことも可能だと思いますが、
取引が始まる前の営業中の状況では、もらった名刺や雑誌、紹介、法人リスト購入等
様々な標準化されていない法人データを営業業務上扱うことを求められることは
かなりありますし、今後もなくならないと思います。
※標準化された住所を使わないと営業ができないわけではないので。

その中でメイントピックにも記載してあるように、
『法人名称』と『住所』しか商法上、法人登記上は
法人を見分けるユニークなキーがない状況なので、
正確性の高い住所情報を元に名寄せし、法人番号をなんとか付与できないか、
日本中の法人がトライしていると思います。

その為、法人番号では代替え手段にならず、
標準化住所がやはり必要だという事だという結論です。

by tigersun2000さん - 2017/03/16 01:40 問題を報告

#007
まず、基本的に課題1～3についての課題認識は概ね同一です。

追加でコメントするならば
課題1については、『画一的な表記方法が欲しい』という点については、
目的としては、『画一的な表記方法が欲しい』という事を前提に、
ISO/TC 211で議論されているだけでなく、画一的な表記方法が出来た際には、
役所の届け出、免許書住所、登記などが組織を超えて、表記と住所語彙が利用され、
住所情報が公開されて、民間事業者でも利用ができる用になる事、
つまり、役所から出てくる住所は
すべて標準化された住所情報を元にしたオープンデータが出てくることが望ましいです。

また画一的な表記方法は民間でも利用でき、民間事業者が住所を管理するときにも、
同一の表記方法、マスタメンテナンス方法で外部からも継続的に利用できることが望ましいと考えています。

利活用については、標準化を行うという事を起点として、
組織を飛び越えた標準化と、その先の民間事業者の利活用を考えたいところです。

by tigersun2000さん - 2017/03/16 01:30 問題を報告

#005
無理が出るのはある意味しょうがないことだと思います。
無理が出るからとあきらめず、お互いの業務を見合わせ、合理化できるところは、
合理化するように、担当部署が話し合って、落としどころを探る事が出来れば、
重複システム投資や、重複業務をなくすこともできるんじゃないかと思います。

by tigersun2000さん - 2017/03/15 03:39 問題を報告

ただただ賛成。

by tigersun2000さん - 2017/03/15 03:29 問題を報告

小さな業務改善には予算がつきにくいという事もあるので、
小さな部分に対応できるように、エンジニアを積極的に雇い、
官庁の中の小さな改善を積極的に行える体制をとるとよいと思います。

by tigersun2000さん - 2017/03/15 03:25 問題を報告

#003
手段については、民間事業者が競争して作ればいいんじゃないかと思うんですよ。
政府はとりあえずはデータ提供というところに限定してもいいように思います。

by tigersun2000さん - 2017/03/14 12:46 問題を報告

#001
過去受注した官庁のホームページ作成業務の中では、基本的に必ずアクセス解析は求められました。
ただ、公開されているのは珍しいのではないかと思います。

by tigersun2000さん - 2017/03/11 10:33 問題を報告

プロセスで結果をヘッジできるわけではないアジャイル開発やユーザーテストだから国民視点で開発ができるわけではないので、一概に導入したらよいというわけではないのですが、契約が硬直的なため、開発の最中に新しい機能を考えついたとしても、開発の途中で大幅に納品要件を変えることが出来ないことは問題であると考えています。
　その為、契約書の在り方、調達の在り方から見直すべきではないかと思います。

by tigersun2000さん - 2017/03/08 15:45 問題を報告

IT投資の判断基準を明確にして、PDCAを回すというのは賛成です。ただ、ITプロジェクトの7割が失敗するといわれる中、何を失敗とみなして、どう改善を回すのか定義が難しそうですね。

by tigersun2000さん - 2017/03/08 15:19 問題を報告