---
tags: opendata,hackday,govtech
title: OpenData作成支援ツール
description: Socialhackday template
---
# OpenData作成支援ツール（プロトタイプ版）
###### tags: `hackday-projects`,`hackday`,`opendata`,`govtech`

:::info
- :fire:start from: 2022/06/25
- :up:update: 2022/06/22
- HackdayのHackMD(全体)はこちら: https://hackmd.io/@codeforjapan/SHDguide
:::

## プロジェクト概要 Overview：
### コンセプト
データモデルの整備状況と足並みをそろえて、機能アップデートしていくことを目指したオープンデータ作成支援ツール

#### ツールのコアバリュー
- 手元にあるCSVファイルを定義書の要件に沿った形式に楽に整形できる
- 操作はツールの案内にしたがってマウスとキーボードをポチポチするだけ
- 定義書の更新に追従できるような柔軟なシステム設計

#### 副次的なねらい
- 整形に用いるバリデータやフォーマッタの関数はオープンソースモジュールとして公開することで、他の事業者や主体が再利用できるようにする。
- データ作成に取り組むことが退屈な単純作業ではなく、すこしでも楽しくなるようなゲーム要素を含んだインターフェースにする。

### Why(なぜ始めたのか)
デジタル庁の取り組みとして、地方自治体のオープンデータ活動を活性化させるものがあります。自治体が公開するオープンデータが増えてくることで、事業者がそのデータをつかってサービスをより便利にしたり、それをもとにした新しいアプリの開発ができるようになったりします。例えば、サンフランシスコでは市が調査した飲食店に対する衛生検査の結果を公開し、それをYelp(食べログみたいなやつ)が用いて衛生スコアとしてアプリ上に表示するような事例があります。

しかし、ただデタラメにデータを公開していれば良いわけではなく、機械判読可能でかつ、フォーマットが揃ったデータであることが望まれます。自治体が公開しているオープンデータの種類は増えてきているものの、理想の形で公開されていないものが多いのが現状です。

### What(どんな課題を解決したいのか)
本プロジェクトでは政府が公開している[推奨データセット](https://www.digital.go.jp/resources/data_dataset/)で指定されているものを対象とします。
推奨データセットには17種類のデータが指定されており、それぞれのデータには10近くの項目（住所や位置情報、電話番号など）があり、各項目の共通フォーマット/ルールが[項目定義書](https://cio.go.jp/sites/default/files/uploads/documents/opendata_suisyou_dataset_teigisyo.xlsx)として策定されています。
この項目定義書に書いてある通りに地道に手作業でデータ作成を進めていくことも可能ですが、ルールそのものが複雑だったり、ルールが書いてある場所が異なるのでリンクをたどる必要があったり、単純な手作業でなく、複雑な手作業になります。その結果、ヒューマンエラーを避けられなかったり、オープンデータ作成にはじめて取り組もうとするときの学習コストが高かったりする問題があります。

そこで、本プロジェクトではデジタル庁が策定するオープンデータのフォーマット/ルールにそって、推奨データセットで指定されているデータの作成を支援するツールを開発します。

**ペーパーモックサンプル**
<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vQZGuiEaRYv1hyWHZ4qJzKSR_vjRJ8KgOUP9LTkdq8lrqR9MPAA4-IiM8G-4s7yesik12Do_Mx3SjwF/embed?start=false&loop=false&delayms=3000" frameborder="0" width="723" height="523" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>

#### ツールのコアバリュー
- 手元にあるCSVファイルを定義書の要件に沿った形式に楽に整形できる
- 操作はツールの案内にしたがってマウスとキーボードをポチポチするだけ
- 定義書の更新に追従できるような柔軟なシステム設計

#### 副次的なねらい
- 整形に用いるバリデータやフォーマッタの関数はオープンソースモジュールとして公開することで、他の事業者や主体が再利用できるようにする。
- データのフォーマット/ルールが書いてある定義書そのものがアップデートされる可能性が大いに考えられます。オープンデータの整備を行う人たちがそれぞれ独自に定義変更による仕様変更に対応していては非効率です。一つの理想として、定義変更への対応はこのプロジェクトで公開するオープンソースだけよいということになればその無駄を省けることになります。
- データ作成に取り組むことが退屈な単純作業ではなく、すこしでも楽しくなるようなゲーム要素を含んだインターフェースにする。
- 複雑な手作業を単純な手作業にするだけでなく、その作業自体が楽しいものになるツールをつくることで、よりたくさんの良いオープンデータが増えていくことにつながると考えています。

### How（どのように・何をつくって取り組んでいるのか）
開発言語・フレームワーク
Typescript、React

ユーザーインターフェースはReactでつくりながら、データのLinter/Validator/Formatterはnpmパッケージとして公開しようと考えています。

### 仮ロードマップ
#### Phase1
推奨データセットと項目定義書をよみながら、どんな項目があり、どこにあるルールにそう必要があるのかを揃える。
どのデータ/項目から取り組むことがよいのか優先順位をつける。
Linter/Validator/Formatterの精度、定義、要求を決める。
etc...

#### Phase2
一つのデータ（避難所が良さそうだがPhase1の議論を踏まえたい）を決めてMVPをつくってみる。
etc...

#### Phase3
今整形途中のデータがどれぐらい良いデータなのかをスコア化したり、ゲーミフィケーションを考えてみる。
etc...

---
:::info
プロジェクトメンバー Contributers :smile:
- 継続参加：[name=Kazuki Imamura] [name=Yuki Kawabe] [name=y-chan] [name=のんたん]
- 初参加：[name=おおた] [name=いしはら] [name=ひろみん] [name=くらさわ]
:::

:::warning
連絡先 Contact:zap:
- Github: https://github.com/codeforjapan/OpenDataTools
- Slackチャンネル: `#proj-opendata_support_tool`
:::

---
> ハックデーの項目をコピーペーストしていくと、そのまま活動ログになります。
> 別途活動風景や写真などを加えたり、項目を足していただいても構いません。
#### yyyy/mm/dd ハックデー or ミーティング

## 2022/10/03 ミーティング
### プロジェクト方針
- 設計方針に関するコミュニケーションはもう少し言葉にしよう
- 動くものベースでのコミュニケーションのほうがよさそう

### 画面設計
- インポート => 自動処理 => ラベル正規化 => 中身

### 次回について
たっくんに高知県のユーザーテストのデバイス環境をきく。セキュリティなど。

## 2022/09/21 ミーティング
### チェックイン
- いまむら：今日は社内のMTGで疲労しています
- やたがい：CCCが一段落したのでこっちにももっと貢献していきたい
- 萩原：つくりたいオープンデータができました
- たっくん:おなかいたい
- のんたん：仙台でリマさんと語り合いました
- じんのうち：一昨日、風邪っぽかったんですが、治りました
- むらゆー：大学疲れました
- y-chan: 明日から山梨
- りょーま：パーソナルジムマジでやばい

### スケジュール確認
**高知**
- まだ元データもらっていない。
- いつユーザーテストするのがよいか？
- データ上がってきたらすぐにテストできると良さそう（開発は10月中）。
- 11月にユーザーテストをして、振り返りを終えるのが11月30日
- 12月はユーザーテストを受けた修正に当てるバッファ
- figmaをデジ庁に見せる（10月初旬）
- 9月最終週にデザイン作業（のんたん・今村）

### issue・タスク
- データマネージャ
- どんどん片付けていく
- ファイルインポート、バリデータあたりはwebclientに組み込めば動くと思う
- 最後のステップ
- 完成したデータをどう表現するか
- **地図ページは並行して作業できる**
- 太田さん、石原さんにメンションしてみる
- 正となるデータがあるとうれしい
- 登別市 https://ckan.hoda.jp/dataset/noboribetsupublic_facility
- 別海町 https://www.harp.lg.jp/opendata/dataset/106.html
- webclient
- 一連の流れをモックレベルで作ってみる
- りょーま
- 中身の処理を順番につくっていく
- 都道府県あたりとか
- Renさんにメンションしてみる
- フロントコーディング
- ChakraUIいれてるので、基本的にはCSS書かずにできると嬉しいかもです。スタイルProps => https://chakra-ui.com/docs/styled-system/style-props

- figma
- ムードボード
- どこかの時点でデジ庁に見せておいたほうがいい

- github
- proj-ost_git でコメントなど含めてながすようにする。

## 2022/09/07 ミーティング
### チェックイン
- たっくん：寝て起きた
- のんたん：疲れています
- りょーま：釣果0です、夜も行く予定です、獲りたい
- いまむら：いちじくを食べた。次回はいいです
- y-chan：SHAREVOXっていうソフト作ってて大忙し

### y-chanの宿題
#### ムードボード
- ダッシュボードのデザイン
- フォーマル / カジュアル
- フォーマルなUIはあまり見つけられなかった
- フォーマルというと一昔前になる
- 固いイメージ
- 今回の目的は「やさしさ」
- 角丸とか
- カジュアルになりすぎないくらいの「やさしさ」
- カラーの統一
- デジタル庁の「青」
- ポイントで黒とか
- 今回はロゴがないので締まるポイントがない
- テーブルっぽいアイコンとか？
- ユーザー関係のUIは不要
- ステップを左サイドバーに配置するのはどうか
- ページ戻る問題
- 背景で柔らかさを演出するテクニック
- 作業することが優先なので、中身の作業空間は操作性を求めて、デザイン的な柔らかさは背景で演出

#### ユーザーとは
- 「公務員」つまりたっくんだよ
- 「ソフトウェア」より「アプリ」に慣れている

のんたんが一旦引き取ります。

### タスク進行の組み直し
- デザイン関連
- のんたんがザクザク進めます。
- フロントとデータマネージャの繋ぎ
- npmのパッケージにして、
- githubにリンクを貼って、限定公開npmにする（りょーま）
- バックエンドを分離するので、開発時に事前設定が必要
- ドキュメントを整備（りょーま）
- フロント
- コンポーネント作成
- のんたんの作業と並行してやる
- ざっくりパーツ分け
- ガワをざっくり作る
- Hooks実装
- DataManagerの関数を使って、{[key: any]: any}[]的なやつを順番に処理する汎用関数とかつくる
- 地図の実装を太田さんにお願いする
- ダミーデータが欲しい
- 9/12の週に高知県下のデータが戻ってくる予定
- きたらslackで通知する（たっくん）
- コンテンツ部分
- あったらいいなというところなので、ギリギリでも大丈夫
- figmaの権限を減らしたい
- 10/6までは今のままの権限で使用可能

### 定期的にレビューを入れる？
- 最後にどんでん返しくらわないように、途中でレビューを入れた方がいい
- デジ庁側に確認します（たっくん）

### もくもく会
- 出入り自由のZoom
- 9/11（日）は作業予定（のんたん）
- 土日祝でやりましょう
- 13:00-18:00（仮）
- 今村がZoom立てます

## 2022/08/27 SHD
### (1)OpenData作成支援ツール（プロトタイプ版）

#### HackMD URL:
https://hackmd.io/aUSwRjujRjOGB5mozD2q-w

##### プロジェクト概要 Overview：
デジタル庁の取り組みとして、地方自治体のオープンデータ活動を活性化させるものがあります。オープンデータはただデタラメにデータを公開していれば良いわけではなく、機械判読可能でかつ、フォーマットが揃ったデータであることが望まれます。しかし自治体が公開しているオープンデータの種類は増えてきているものの、理想の形で公開されていないものが多いのが現状です。
そこで、本プロジェクトではデジタル庁が策定するオープンデータのフォーマット/ルールにそって、推奨データセットで指定されているデータの作成を支援するツールを開発します。

##### プロジェクトメンバー Contributers：
- [name=Kazuki Imamura] [name=りょーま] [name=y-chan] [name=Kota Yatagai] [name=Junya Ishihara] [name=Kazuho OHTA] [name=hayashi noriko] [name=Hiromi Hagiwara] [name=住職] [name=Yu Muramatsu] [name=Ren]

##### Slackチャンネル・連絡先・アクセス方法 Contact：
- Github: https://github.com/codeforjapan/OpenDataTools
- Slackチャンネル: #proj-opendata_support_tool

##### 今日の作業内容 Today's Mission：
`完了したら[ ]にxを入れる`
- 今日はもくもくと作業をします！コーディング、レビューなど、じゃんじゃんやっていきましょう！
- [ ] フロントからどうデータマネージャを呼び出すかを検討
- 案1)npmにする
- 案2)exportする
- ページ実装を試してみる
- いしはら・やたがい
- [ ] パーツのバリエーション出し with のんたん
- いまむら・Ren
- [ ] 各ページ（機能）の実装
- [ ] データマネージャ各項目の実装
- やたがい
- [ ] 自動変換周りの処理を検討
- [ ] トップページのコンテンツ検討
- ひろみん

##### こんな人にきて欲しい People needed：
- 世の中のオープンデータを充実させていきたいひと。
- オープンデータに関する活動をしたことがあるひと。現場経験やワークショップ経験などなど
- BADなデータが生み出されるのを阻止したいひと。

##### figmaモック検討
- ページを戻る場合の挙動
- ブラウザバック
- 戻るボタン
- 自動保存？明示的にボタンを押して保存？
- 自動保存がいい
- （ページルーティングでいけるのでは？）
- 「保存されたものが消えますよ」的なワーニングを表示する
- ダイアログUIを表示する
- 押しがちなボタンと押さながちなボタンがある問題
- 親切ではあるけど鬱陶しい
- 文言を工夫する
- 任意のページに移動するのを許容するか（優先度：低）
- ２ページ前に戻りたいor最後のページに行きたい、といった場合
- ファイルのダッシュボード的なものに溜めていく？
- 成形したデータを保存していく領域が必要？
- ストレージ的なものは考えていない。SPAの状態管理でできる範囲で実装
- ダウンロードしたものを改めてプレビューできるページがあるといいかも
- アラート・ワーニングの表示の仕方
- 重要な内容であることが多い
- 見逃さないようなUI
- 自動変換のプログレス表示
- アニメーション表示にしたい
- こういう感じのやつ
- 「何かが進んでいる」というのがわかればいい
- パーセンテージはなくていい
- キャンセルボタンは必要？
- 何かの原因で止まった時のためのエラーハンドリングは要検討
- 疑問）データ項目名の正規化はどう実装する？
- ホワイトリスト
- 現状のデータを見て調整していく
- ユーザーテストの時点ではこのページ自体いらないかも。優先度を下げてもいい
- 次の段階の開発にまわす
- Excelアップロード
- データ項目名の正規化

##### フロントからどうデータマネージャを呼び出すかを検討
- package.jsonがwebclientの下にあるので、datamanagerと連結するのに一工夫必要

##### 本日の成果 Today's Outcome：
`中間報告・最終報告で追記する箇所です`
1. チーム名「供養寺門前払い」（仮）
1. aa
1. aa

##### 本日の嬉しかったこと・ありがとう Today's Fryinghigh：
`最終報告で追記する箇所です`
1. aa
1. aa
1. aa

## 2022/08/24 ミーティング
### チェックイン
- りょーま：明日Joiさんとのレコーディングなんですが、あれよあれよと7人の登壇者になってしまいましたｗ あと画角かわりました
- のんたん：今日は５時に起きました
- 陣内さん：最近は毎日おそうじロボットを使っています
- 今村さん：五十肩がみるみる回復しています
- 太田：今週の土曜日には岐阜にいます

### タスク分解
#### 設計系
- エラーコード
- **フロントからどうデータマネージャを呼び出すか**←SHDで検討（==priority:high==）

#### フロントエンド
- [PR#39](https://github.com/codeforjapan/OpenDataTools/pull/39)をマージ
- UIフレームワークの検討（Chakra?）
- **パーツのバリエーション出し with のんたん**←SHDで作業（==priority:high==）
- **各ページ（機能）の実装**←SHDで作業（==priority:high==）
- テスト実装←SHDで作業（priority:low）
- １ページ目のコンテンツを考える←SHDで作業（priority:low）
- マップ表示実装←SHDで作業（priority:low）
- エラーメッセージ等の演出的な部分を考える←SHD開発系じゃない人向け

#### データマネージャ
- **各項目を進める**←SHDで作業（==priority:middle==）
- データマネージャーの優先順位ですが、必須項目、推奨項目、なにもなし項目、独自　みたいな感じかなと思いますー
- **自動変換周りの処理**←SHDで検討（==priority:middle==）
- 全角半角とか
- どんな自動変換が必要そうか

#### ドキュメント系
- 開発環境構築、言語とかのReadme←SHDで作業（priority:low）

### 今後のスケジュール（※SHDで検討）
- 定例ミーティングは隔週
- 基本的に非同期で進める

## 2022/08/17 ミーティング
### チェックイン
- りょーま：台風で旅行が延期になりました
- のんたん：今日は午後ずっと休みなく会議
- 太田さん：今週末、来週末瀬戸市にOSMイベントにいくよ
- 石原さん：いまどきの子はtiktokで情報集めがち
- むらゆーさん：CfJインターン、東京都コロナサイトやってるよ
- やたがいくん：徹夜で10時間カラオケしてきました(2人で110曲)
- 陣内さん：CfAサミットのYouTubeがあがってない
- 今村さん：後遺症大変。味覚嗅覚は戻った

## figmaモックを検討
- STEP2 データ種別を変えるとチェック項目も変わるようにする
- チェック項目が変わったことがわからないかも
- そもそも項目を選択する必要ってありますか？
- いきなり多くのエラーが出ると萎えるので
- ハードルを下げてあげる
- アップロードする前にデータ種別を選べたほうがいいかも
- 推奨データセット以外もやりたいことがあるかもしれない
- STEP1の前に説明文が必要
- アップロードの時に項目名がわかるので、チェック項目も自動で出せるのでは
- 「住所」の項目がないのに、チェック項目で「住所」があるとエラーにしかならない
- 「緯度経度」として入力されていた時、「緯度」「経度」のチェック項目はどうなるのか
- 最後のステップまで行って、結局最初に戻されるのはつらい
- 「チェックできない」という表示が必要
- エラー表示が必要。先には進める
- ユーザーテスト用の実装
- 未実装の部分をどう表現するか
- 技術的にできるところと手作業でやらざるを得ないところを分ける
- 想定できないケース
- 実際のデータを見ていって経験則的にバリデーターをいじっていくのが一番近道な気がしますね
- カラムが合っているというのが大前提
- プロトタイプではExcel対応はしない

## 2022/08/10 ミーティング
### チェックイン
- りょーま：figmaのコンポーネントをマスターしたい。アイスコーヒーは氷をいれてからコーヒーを淹れるほうが冷える。
- のんたん：ネットが不安定なのは娘の携帯ゲームのせい
- いまむら：後遺症がひどいです
- たっくん：きっと夏バテ
- おおた：気分は夏休み…

### ワイヤーフレームのレビュー
[ワイヤーフレーム（Figma）](https://www.figma.com/file/TSMMVFAsUwkosBmY7S1FSd/opendata_support_tool-UI?node-id=2%3A5025)
- りょーまさん
- 標準テンプレートと簡易テンプレート
- バリデートする項目が選べる
- テーブル内より修正リスト内で修正できるほうがいいかも
- セルに色付けするのも考えたが、赤くなっているセルは見たくない
- テーブルのビューワもいらないかも
- 太田さん
- ツール上で編集することは一旦おいておく
- エラー件数、エラー警告
- エクセルで修正させるのを習慣化して、今後そのエクセルをマスターデータとしていければ
- エクセルのversionに追従しないといけない問題あり
- はやし
- 一時ダウンロードが都度できる
- フローのステップ表示
- エラーが出ているところだけフォーム表示
- 保存に後にマップビューワーがあってもいいかも
- 文字コードなど自動変換系は操作されたらその旨をだしてあげたほうが良い。
- 変換処理中にローディングを出す
- 一瞬だからあまり意味ないかも
- 心理的障壁がなくなる感じがいい（たっくん）
- テーブルはビューワーとしてあったほうがいい？
- 全部テーブルで表示されちゃうとあると変な場所をいじってしまう。
- フィルターかけて表示させていくほうがよさそうだから、テーブルはいらないと思う（たっくん）
- ステップ表示は最初からあったほうがいい
- 自動の前処理（文字コード変換など）はAWSの画面みたいに１ページにまとめちゃってもいいかも
- 一つのセルを何度も更新しないようにしたい
- 一つのセルに複数のエラーが出た場合はそれらをまとめて1回で修正できるようにしたい
- 全角にこだわりがある人がいたら...？
- 一回ダウンロードを促す
- アルファベット/記号/数字は半角に強制的に変換しちゃっていいのでは
- そもそもこのツールを使うところはそんなこだわりはないと思う
- 半角カタカナはこだわりがありそうなので変換しない
- 簡易テンプレート
- 必須項目ではないものを非表示にする
- 必須項目ではないものをグレーアウトしておく
- どこまでをホットモックとするか
- テスターはいくらでもお願いできる
- とりあえず１項目だけで最初から最後までのステップを通しでモックを実装してみる

## 2022/08/03 ミーティング
### チェックイン
太田さん：草加にいってCode for SOKA的な事を念頭に考えつつ飲み会
のんたん：のどがやばい
陣内さん：19歳がノンアルを頼んでおどろき
やたがいさん：↑これ僕ですｗ
石原さん：五十肩をなおすために麻酔治療を試してみました
y-chan：コンタクトデビュー
りょーま：みなとみらいの花火大会がありました

### サンプルのレビュー
- 
- 日本地図のpolygonはどう書くのか？
- 石原さんからサンプルソース共有いただく
- https://github.com/geolonia/japanese-admins <- 市区町村ごとのポリゴンデータです。市区町村コードで呼び出せるAPIになっています。
例えば東京都調布市
https://github.com/geolonia/japanese-admins/blob/master/docs/13/13208.json
- 他のissueも同様にクラスを作成していく（市区町村など）
- バリデーション後に間違いを正す関数が必要かどうか？
- 半角全角の修正コンバーターはあっても良さそう
- 既存のものがありそうな気もする
- 中途半端なコンバーターになる可能性が高いのでは？
- どういった体験が求められているかにもよる（具体化したい）
- カラムの内容エラー出力が出せれば、以降同じ感じで増やせれば
- エラーメッセージは文字列で良いのか？
- 形式の正誤判定は必要（エラータイプを決める？）
- メッセージは文字列で良さそう
- 先頭行から処理している
- X行目Xを指定ができた方が良いのか？
- セルを個別に判定していくのか
- csv全体を確認→修正→修正箇所のみの判定処理
- エラー処理については、バリデーションが出来上がってきた段階で再考する
- エラーのプロパティについてはissue28で残しておく
- https://github.com/codeforjapan/OpenDataTools/issues/28
- ワイヤーフレーム（デザインUI）
- ロードマップのもとになるものを考えたい
- 機能としてはミニマムで、ユーザーの動きがイメージできるワイヤー

### 今村さんのreactのPR
* https://github.com/codeforjapan/OpenDataTools/pull/34
* 問題なさそうなのでりょーまさんがマージしてくださる

### 開発環境どうしてる？
* docker使うのが共通化しやすい
* nodeのバージョンは何が良いか？（nodebrewとか）

### スケジュール
* 今月中：ワイヤー・ロードマップ作成
* みんなでやる
* 各々Figmaでワイヤーを描いてみて、来週共有する（メイン画面と余力があればサブも）
* miroのTypeBを基準に書く（余力があれば別案も）
* 編集用Figmaを準備してファイルにインバイトする（林担当）
* 行政職員がデスクトップで作業する。職員になりきって考える。
* https://hackmd.io/aUSwRjujRjOGB5mozD2q-w#20220719-%E3%81%9F%E3%81%A3%E3%81%8F%E3%82%93%E3%83%92%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0
* 9,10月：実装ガリガリ（学生夏休み活用月間として期待！）

### プロジェクトNFTどうおもう？
- 来週

## 2022/07/27 ミーティング
### フローチャートとタスク詳細化の振り返り
- [参考：Frictionless Data](https://frictionlessdata.io/)
- 高知県
- 8/16以降でデータ作成に着手してもらう
- 11月に出来上がったデータをツールに食わせるテストを行う
- 小さくていいのでプロトタイプを作る(8/3にレビュー）
- コマンドラインで入力から１項目チェックして出力するまで（りょーま）
- テストケースベースで関数作る
- UIデザインはどうする？（8/3以降）
- プロトタイプをベースにUIと紐づける
- フロントのベースは着手し始める（今村）

## 2022/07/23 SHD
### (2)OpenData作成支援ツール（プロトタイプ版）

#### HackMD URL:
https://hackmd.io/aUSwRjujRjOGB5mozD2q-w

##### プロジェクト概要 Overview：
デジタル庁の取り組みとして、地方自治体のオープンデータ活動を活性化させるものがあります。オープンデータはただデタラメにデータを公開していれば良いわけではなく、機械判読可能でかつ、フォーマットが揃ったデータであることが望まれます。しかし自治体が公開しているオープンデータの種類は増えてきているものの、理想の形で公開されていないものが多いのが現状です。
そこで、本プロジェクトではデジタル庁が策定するオープンデータのフォーマット/ルールにそって、推奨データセットで指定されているデータの作成を支援するツールを開発します。

##### プロジェクトメンバー Contributers：
- [name=Kazuki Imamura] [name=りょーま] [name=y-chan] [name=Kota Yatagai] [name=Junya Ishihara] [name=Kazuho OHTA] [name=hayashi noriko] [name=Hiromi Hagiwara] [name=住職]

##### Slackチャンネル・連絡先・アクセス方法 Contact：
- Github: https://github.com/codeforjapan/OpenDataTools
- Slackチャンネル: #proj-opendata_support_tool

##### 今日の作業内容 Today's Mission：
`完了したら[ ]にxを入れる`
- [ ] できあがりのイメージを共有する
- [ ] 改めてタスクの洗い出し

##### こんな人にきて欲しい People needed：
- 世の中のオープンデータを充実させていきたいひと。
- オープンデータに関する活動をしたことがあるひと。現場経験やワークショップ経験などなど
- BADなデータが生み出されるのを阻止したいひと。

##### 本日の成果 Today's Outcome：
`中間報告・最終報告で追記する箇所です`
1. オープンデータ公開済み＆未公開の自治体職員の気持ちになって、オープンデータ完成までのフローチャートを考える
1. [想定エラー集](https://docs.google.com/spreadsheets/d/1wRg87PS7FruiYhPEwR_l27dlPwbVyD9vymDxpjcG2Aw/edit#gid=0)のアップデート
1. フローチャートを元に[Issue](https://github.com/codeforjapan/OpenDataTools/issues)を作成


##### 本日の嬉しかったこと・ありがとう Today's Fryinghigh：
`最終報告で追記する箇所です`
1. フローチャートから、より詳細な仕様に落とし込めてよかった。私がNFTをもらいにいっている間にissueがじゃんじゃん立っていて嬉しかったです！（今村）
1. aa
1. aa

## 2022/07/19 たっくんヒアリング
高知県で公開していない自治体がある。そこで、何もないところからどういうフローでデータを作成していくのかをヒアリングすることで、これから公開するデータを揃えていく自治体にも寄り添ったツールにしたい。

### オープンデータをつくろうとしたときのよくあるフロー
1. まず最初に出したいデータが役所のどこかにないかを探す。
- 例えば公共施設であれば、電話番号を管理している課ならもっていないか？などアタリをつけながら探す。
- ものによってはそのままデータセットにするケースはあると思う
- 課や係によってデータのフォーマットが違う可能性があるので、それらを統合して一つのデータにすることが稀にある。最近は少ないかも？
2. 世の中的にはフォーマットが揃っているらしい、と気づき、情報担当がテンプレートをつくる。
- →テンプレートを作成→各課に配る
3. 推奨データセットの存在に気づく
- →そのフォーマットに沿うようにする
4. 細かな調整をせずに出すパターンと、独自フォーマットに進化するパターン
4.1 元々のデータと推奨データセットを比較して、同じっぽいから元々のデータでいいや、っていうパターン（多少の項目名の違い（名前・氏名とか）・列の順番の違いを良しとする）
4.2 推奨データセットは十分ではないと思うから、「俺の考えた最強のオープンデータ」を出していき、独自の発展を遂げるパターン

印刷物として作ったものであっても正とするデータになりうる。（いくら紙エクセルでも）

- 高知県については、最初からこちらがフォーマットを配ってデータを入力してもらうことが可能
- 項目名がそろっていることの意図や意義、重要さはわかっていない。
- 項目名の正確さは気にしない
- データを標準化するメリットを伝えても、なかなか理解されないとおもうが、それはそれでいい
- 標準化の失敗→自治体の声を聞きすぎている
- 何回も繰り返してもいい

**ひとり情シス問題**
いつか異動があるにも関わらず、相談する相手もいないので独自路線に傾くことがある。属人化してしまうと、次の担当者にとっては謎なデータになる。

### これがいちばん大変だった・これ人間がやる必要なかったことはある？

- これ人間がやらなくていいじゃんと思った作業はあるか？
- 人間がやる必要なかったと思ったことはない。
- そもそも機械が吐き出せる状態になっているデータがない（紙エクセルなどはあるが）ので、手作業でやるしかない。

- 推奨データセット自体最近のものであり、登場以前は好きなデータを好きに公開していた
- 制限がないと自治体職員は仕事がやりづらい。どういうふうに公開したらいいのか、取り組んでいる他の自治体を見てもばらばら
- ある程度のテンプレートが必要となった
- それで登場したのが推奨データセット

- 推奨データセットのデータ定義を読み解くのが難しかった
- 説明も難しい
- 「フォーマット＋具体例」が欲しい
- 必要最低限の項目がまずはあればよい
- むしろ、すべての項目が見えているとこんなデータも用意しないといけないのか...うちの自治体ないよ...となる。

### 見えてきたツールのひとつのありかた
- 10行ぐらいお試し（練習）で入力
- ここはしっかりフォーマットに合わせていくようにする。
- エクスポートしてエクセルで編集
- エクセルのほうが編集しやすいだろう。
- 50~100件ぐらい入力したら再度webアプリにインポートしてチェック
- 全部やったあとに全然ちがったら悲しいので。

### 私とあなたのオープンデータに齟齬がある問題
つづく...

## 2022/07/13 ミーティング
### 11月ユーザーテストまでのロードマップ
- 10月末にどういった姿になっていたいか
- どういう体験を届けたいか
- ユーザーは自治体職員
- インプットとアプトプットをしっかり作る
- webでcsv入力する→オープンデータができる
- ペルソナを決める
- １自治体に限定するとか
- 具体的なcsvを取り上げる
- 15自治体集める予定（たっくん）
- 高知県の自治体
- ８月に研修を行う予定
- 2週間に１回のペースでオープンデータについてのフォローをする
- 割とオープンデータの公開まではできている
- が、結構いい感じのデータ具合
- 自治体の進み具合によってレベル分けしてもいいかも
- 土佐市の公共施設一覧がフリースタイルっぽい
- shift-jisである
- utf-8に無言で変換しちゃうのが良さそう
- アラート的に教えてあげることは必要そう
- 項目が自由
- マスターデータはどこにおく？
- もうちょっとDXする？
- 緯度経度・電話番号が空→「埋めてみよう」
- 操作説明不要←ハードルが高い
- 何かしらの操作説明がありながら目的を達成できる
- 操作説明をどこに用意するか
- UXを検証するのであれば操作説明がない方がいい
- オープンデータとしての精度を追求したほうが良さそう
- デジ庁がお手本オープンデータを公開してないの？
- デジ庁は認証機関ではないのでお手本は存在しない
- それはCode for Japanでやる仕事かも
- 公共施設一覧のオープンデータで作られるアプリを想定する
- 閾値を決める手がかりにする
- 自治体の人たちが前後でどんなことして、このデータ作ってるのかが私はあまりよくわからないなとお手本もそれによる気もしていてそれぞれの自治体による気がするけど
- 使い方案からだすと、精度のイメージもできそう
- テストケースを作るためにお手本がないと限界がわからない
- 今回は高知県の「理想のオープンデータ」を考えてみてもいいかも
- バッドデータのパターンが多すぎる
- 高知県の15自治体のscheme一覧を作ってみる
- テストデータを作るのにも役立ちそう
- 理想のオープンデータの形が見えてきそう

## 2022/07/06 ミーティング

### 実装項目詳細
https://hackmd.io/t1FwhrwDT1y9_rb1ZCT7fw?edit

### 想定エラー集
- ジャンル分けして検討しようと構想
- 実装項目詳細に紐づけて考える？
- 緯度経度
- 日本の緯度経度範囲かどうかをみる
- 緯度経度が「35.454794, 139.631201」と一つのセルにいれてしまうことも...
- 最後にプレビューで地図にマッピングしてくれる。
- [想定エラー集のスプシ](https://docs.google.com/spreadsheets/d/1wRg87PS7FruiYhPEwR_l27dlPwbVyD9vymDxpjcG2Aw/edit?usp=sharing)

### デザインメモ
- [のんたんデザイン Miro](https://miro.com/app/board/uXjVOqFoL3A=/
)
### 雑談
- 自治体職員さん、バリデーターからも怒られたら可哀そう

### タスク分け
※githubのissueに書いてから作業に着手してください！

- 想定エラー集：y-chan、下山
- Utility関数：今村
- Validator/Linterのたたき台：石原
- データ項目の正規化：りょーま

## 業務連絡
- SHDのHackMDを早めに書いておいください

## 2022/06/29 ミーティング
### 新規プロジェクトメンバーの自己紹介
- 太田さん：webエンジニア、Code for SAITAMA
- 石原さん：Georonia、Code for Chohu、coder DOJO、
- 萩原さん：Code for Japan、
- Yatagai：去年CCCインターン、留学からかえってきたよ、

### 6/26 SHDの共有
- バリデーター、フォーマッター、ゲーミフィケーション的なUIUX含めてうすーく作れると良い
- [例 : マンホールの写真を撮っていくゲーム](https://www.huffingtonpost.jp/entry/story_jp_61763fb1e4b010d93312d3e2)
- バッドなOD
- あたりをつけるにあたって、下山さんや高木さん等に聞いてみても良いのではないか
- 意図して間違えているもの
- 美データと言われているものがもしかして間違っているかも？
- [北海道の美データ1](https://www.harp.lg.jp/opendata/dataset/search/?s%5Barea_id%5D=146)
- [北海道の美データ2](https://ckan.hoda.jp/organization/noboribetsu)
- [戸田市の迷データ](https://www.city.toda.saitama.jp/life/7/59/248/)
- [川口市の美データ](https://www.city.kawaguchi.lg.jp/soshiki/01020/020/5/4512.html)
- [日野市の味わいぶかいデータ](https://www.city.hino.lg.jp/cgi-opd/opendata_detail.cgi?id=1a929a16ce97cfe8ff0163af92496dee57f04935)

- バリデーター
- 先進自治体のOD（オッケーOD）をもとに、コマンドライン的なものからつくってはどうか
- 上記コマンドラインをUIが呼ぶような進め方
- [参考：BODIKバリデーター](https://utility.bodik.jp/validator)
- チェック品質がザルだとユーザ的には悲しいのではないか
- 項目の〇、◎から始めて良いのではないか
- レベルで分解して進めていくと良いか
- レベル１：◎/○/無　のチェック
- レベル２：～～～
- レベル３：～～～
- 目指すプロトタイプ
- 1種類のODをもとにきちんとチェックできるようなプロトタイプを目指す
- 公共施設（重要視されている・横展開しやすい）
- リンターをオープンソース
- 非同期かつ多言語で開発が進むのではないか
- CSVだけではなく、Excelにも対応できるとよいか
- 正規表現
- 文字コード変換

#### 宿題候補
- バッドODを自分の地元からみんな探してくるとか（公共施設一覧からいく？）
- 実装面でのタスク詳細化（りょーまさん）
- 最低限必要な機能をあげる（太田さん）
- 想定エラー集（y-chan）

> 太田
> 自治体オープンデータの取り組み率はわかってたけどもっと詳細を見たくて
>
> 地方公共団体へのオープンデータの取組に関するアンケート結果・回答一覧
> https://cio.go.jp/policy-opendata#survey
>
>令和2年度の回答一覧をGoogleスプレッドシートにUP
>https://docs.google.com/spreadsheets/d/1NrIkpE79783qidRcmtqTfKqRqyQyaOMsPKMv4lpH8SY/edit?usp=sharing
>
> 先進自治体ってどんなものか、の観点として
> - 推奨データセット基本14種類をすべて満たしている自治体
> - 
>- オープンデータ一覧を公開している自治体
> - これ公開しているのは結構重要と思った
>- データ数
>などをいじりつつさぐってみていましたがまとまらず
>next: 　オープンデータ一覧自体を比較

---

## 2022/06/26 SHD
##### 今日の作業内容 Today's Mission：
- [ ] 大項目１
- [x] タスク１
- [ ] タスク２
- [x] タスク３ [name=山田][name=佐藤][name=鈴木]
- [ ] 大項目２

##### こんな人にきて欲しい People needed：
- 世の中のオープンデータを充実させていきたいひと。
- オープンデータに関する活動をしたことがあるひと。現場経験やワークショップ経験などなど

##### 本日の成果 Today's Outcome：
`中間報告・最終報告で追記する箇所です`
1. aa
1. aa
1. aa

##### ディスカッション
- アウトプットのサンプルが見えるとモチベーションが上がるかも（地図表示・献立表チラシetc）
- ジオコーダーは欲しい
- 自治体を横断して地図表示する（データを公開していない自治体の可視化にもなる）
- みんなで作っている感を出す（「新しく〇〇市が参加しました！」とか）
- 公開したオープンデータのアクセス数・ダウンロード数が見えると嬉しいかも
- 自治体のデータのみで活用は考えにくい。民間のデータも一緒に活用するイメージを持てればいいかも
- オープンデータが実際の生活の中でどのように活かされるのかが想像しにくい
- コードで入力させる項目はマッピング作業が必要（初期のプロトタイプでは実装しなくてよいと思う）
- バリデーターやフォーマッターはいろんな言語で実装してモジュール化したい
- いずれAPIにしたい



##### 今後の作業予定
- BADなオープンデータのサンプルを拾ってくる
- バリデーター・フォーマッターに必要なUIの要件定義を行う