proj-inclusive 定例 2024-11-23
手順
（１）ScrapboxにGoogleアカウントでログインする
（２）このScrapboxプロジェクトに参加する
Scrapboxの操作方法
箇条書き（「・」）：文頭で「スペース」or「タブ」
スペースを増やすたびに入れ子が深くなる
水平線（章を区切る線）：改行2回
見出し： [*** タイトル]
* が増えるほど文字が大きくなる
別ページへリンク： [ページ名]
用語を [] で囲みリンク化しておくと、同じ用語が登場するページとリンクすることもできます
ビジョン
お金を持っていようと持っていまいと老若男女が一緒に社会を考え行動する
自己紹介名前、このPJでやりたいこと、一言
右上のメニューで create my pageすると、 ctrl+i で自分のアイコンを設置できます
Koichiro ShiratoriKoichiro Shiratori.icon：消えちゃったので再書き込み！ 4名は参加してました！
MIYAMOTO Ryota pal4de.icon: 初参加！ C4J SummitでPJにお誘いいただいたエンジニアです
syuparn.icon syuparn summit翌日はコーヒーフェスに行っていました
Eiko Goto.icon
タイムスケジュール
10:00-10:15 説明、各自のニーズや野望の共有
10:15-10:30 進捗報告→今後の流れの議論
10:30-11:50 開発タイム：開発・作戦会議
11:50-12:00 ネクストステップ
進捗報告（YWT＝①やったこと、②わかったこと、③次にやること、を共有）
OpenFisca(バックエンド)開発
やったこと：↓をissue化
次にやること：ドキュメント化できることがあれば記載
OpenFisca Editor検証
やったこと：
わかったこと：
次にやること：
支援みつもりヤドカリくんアプリのフロントエンド改善
やったこと：
わかったこと：
次にやること：拡張性を持たせるためのステートの持たせ方を変更する
デザインチーム
やったこと：TOPページFIX
わかったこと：
次にやること：UIについてエンジニアのかたに声をかける
政策シミュレータ・インクルーシブチャート
やったこと：情報交換（シミュレータどんなもの）→データ申請完了！
わかったこと：合成人口データを活用して、生活困窮に陥るきっかけをシミュレーションで見出せるか？
次にやること：
人工合成データ審査待ち
その他
対外連携：H、F、G、M
ロジックモデルは折にふれてみんなで更新していく
Code for Japan Summit 2024
特にエンジニアに知ってもらい、参加してもらう機会として貴重
日時：2024年11月16日(土)
参加費：無料（懇親会は有料）
収容人数：400名程度（宿が埋まりやすいらしい）
基本でようと思ふ アピールに良い
実績、マイルストーン
自治体と企業の協力を得られる場として
技術的な交流、インプットの機会としても
♨
行く人 今わかっている人
Eiko Goto.icon 15日泊、16日泊予定 ohtaさんのツインご一緒させていただくよてー （直前まで周防大島）
oyuuuhan.icon
syuparn.icon
Naoki_Shima.icon
Koichiro Shiratori.icon
あらいゆうすけ.icon：途中参加かもしれません
Naoki Akazawa.icon：前日までタイ🇹🇭にいて、関空から突撃します。
パンフレット持参→A4片面カラー（連絡先はなし、名刺とセット）
セルフでコピー（紙質なども各自で決定）
似たようなことを発表している人と話す（どういう発表かを事前チェック）
フライヤー配布
報告：新メンバー加入あり！！！
報告：g0vの報告で、9つの事例報告のうちの1つとして紹介されました！！！
9月以降のGUI刷新
方針
Figma刷新版 におおたoyuuuhan.iconさん作成のトップページ案と、以降のページの案がある Chakra.uiのコンポーネント・スタイルの範囲内で、トップページのスタイルを以降のページにも適用したい
トップページの動きのあるデザインや、以降のページのフロントエンド実装はイシュー化して、フロントエンドエンジニアのコントリビュートを募る予定
水色（背景）と黄色（文字）のコントラスト比はアクセシビリティ的に見にくいかも？(参考サイト) 検討事項
スマホのレイアウトをベースとしておおたさん検討中
ユーザービリティを考えるとまだもっと全体のフローは最適化しないとなという印象
以下の質問が大きな分岐となるため、一旦これらを中心に考えるのがいいかと感じました。見落としがあるかもですが、これ以外は比較的シンプルな分岐になるかと感じています。
病気があるかどうか
配偶者がいるかどうか
furuhashi.icon 子供、祖父母の有無も同時に質問しますか？
何人いるか→一人一人に対して同じ質問群
質問のカテゴリを示す
同様の内容の質問は全世帯員分まとめて聞くと入れやすい？
誰についてか分かりづらいので今は人ごとに聞いている
世帯構成等基本情報 -> それぞれの世帯構成員の情報 ->
アトミックな質問とそれをグルーピングした質問群を前の質問項目によって出し分ける
質問フォーマット
フォーム形式
❌うまくカテゴリ分けしないと脈絡がなくなる
❌スマホでスクロール必要な画面が出てくると負荷を高く感じてしまうかも
⭕️特にPCだとフォームで一覧化されている方が見やすいかも
一問一答
❌ページ数が多くなるかも
完全な一問一答でなくてもよく、いくつかの質問を同じページにまとめてもいいかも
⭕今後の拡張がしやすい
⭕ユーザーが聞かれている質問に集中しやすい
参考サイト
進め方
以下並行して行う（いずれも現状期限はない）
対外連携でのフィードバック事項
現在のレイアウトに対して修正
トップページのデザイン刷新
はじめはデザイン案をFigmaで作成、比較するところから
案は固まったら関係各所に頭出ししたい
色々な利用者、関係者の方に意見を伺って慎重に進めたほうがよい
手戻りできる範囲で進める
決まった後で開発内容をissue化、コントリビューターが取れるようにする
質問フローのデザイン刷新
上記同様、トップページとは独立して進められる
New! ローカルでの「アプリ体験会」の開催可能性
例：ユーザーに対してのレイアウト形式(一問一答orフォーム式等)のABテストができるかもしれない
Figmaを見せる or プロトタイプ
一般の方向けなので実際に動いて触れるものの方が分かりやすい
一方、そこまで実装を進める必要があるので工数が増える
フロントエンド実装難易度によっても設計方針が変わるため、こちらで開発をある程度進めた段階で行いたい
レイアウト改定にあたりこの形式を採用したという裏付けにもなる
Facing the Ocean 8/17-18@横浜
東アジア合同ハッカソン
フォローアップ
code for koreaの方で韓国で行政学を大学で教えられている方とのお話しや、gov0の関係者で 「アジアでcivic hack pjでどのようにlocal govと連携しているかを調査している」とのこと。code for san jose, san francisco, 成功事例あるかもとのこと
カリフォルニアのcivic techの事例 は以下かも？
財団Mアプリ実装
有償開発可（無償開発の人に「お願い」はしない、ご紹介、ご案内）
有償開発メンバーが増えた場合、期間、開発内容
2024年10月～2025年9月
自治体と連携見込み
１）制度追加
自治体Fとの連携、解像度の高い情報掲載？
２）UI改善
超番外編）LINEスタンプ？ LINE広報？ （LINEの併用によるアプリの付加価値向上）
他の相談窓口からの学び
定期的なリマインドが大切（ヤドカリくんの場合、LINE botから3か月に1回お役立ちニュースなど？）
←大学公式LINE等窓口があればそことも連携ができると導線が増える？
まずはハードルが低いところをおすすめするのが大切
ヒアリングはエンジニアリングというよりも研究の側面が強いため、その知見も必要
プロジェクトマネジメントも必要
線を引く、手を動かす（追加制度が既実装制度とどれだけ似ているか）→フロー
プロジェクト安定稼働のためには、既存のものとどれだけことなるかを見積る時間を取る→期限を決めるの順番のフローにした方が安全
型化
現状は追加個所を暗黙知で選択している
フロントエンド側は一問一答方式のほうが制度追加に強い（拡張性）
バックエンド側はopenfisca上密結合しているが、フロントエンド形式に依存しなくなる方が柔軟に設計できる
１）誰に聞けばいい？
２）プロジェクトのマネジメント（タスクの性質）
プロマネは仕事が無限に広がりがち（どのくらい制度を定型化できるか、制度追加なら型は決まってくる）、非定型な仕事（出たとこ勝負）のプロマネはかなり大変
要件定義が抽象的なほどプロジェクトマネージャーの負担は上がる
この形式にはなるべくしないようにしたい
開発対象が決まった後タスクに切り分けるのはPMの担当予定
リソースと期限が決まっているため、実現可能/不可能を判断する役割
自治体が使いたい機能を直接受けるというよりも、その利便性向上のための研究の調査への利用という関係性
ニーズを探るのは研究者チーム、その検証のために追加する制度の実装の実現可否をプロマネに相談する流れ？
10月29日（火）19:00-20:00の防窮研究会にて自治体の方より地域ニーズのご報告→協議
アイデア
ライフイベントによる困りごと別の制度一覧を表示する機能？
「困りごとがある」ボタン→「リンク集」でもよい？→金額見積にも移れる
「失業した」→一覧と一行説明とURLが表示される（個別最適化しない）
絞り込んだ方が良い
正確な窓口まで出さなくても、どのような場所に相談すれば良いかを出すだけでも良い
金額計算のフローに繋がるのが差別化点
定量的に見積もりが出せる制度が良い？
せっかく作るのであれば車輪の再発明にはならないほうがよい
困りごとに対応した窓口が出るだけでも繋がりやすくなる？★
例：こども食堂、ハローワークの窓口が出る
末尾に定量的に示せない制度に対しても見積もり結果に出せる
具体的な自治体が出せなくても、リンク集を繋げるだけでも良い
グーグルマップのリンクでも
ヤドカリくんの課題
制度の網羅性がまだ不十分
何も出ないとやる気をなくす、アクションが途切れてしまう
一方、窓口に繋ぐためには出てくる情報が多すぎても迷ってしまう
ヤドカリくんの役目は？
支援制度が出る→こういうものがあるよと示せる
より「窓口に行きたくなる」（窓口に繋がる）、そのために見積もり額が算出可能なものを主眼に置いている
数字がでることで窓口に繋がりやすくなるという仮説にもとづいている
↑をスコープの主眼に置く、計算できるものだけでも
リンク集実装によって、網羅的な対応をしていく予定があるというメッセージを与えると利用者、運営者にすれ違い
リンク等の更改にも増えるほど保守コストもかかっていく
利用者は網羅性が低いものはそもそも使わないという課題もある
チャットボットに繋ぐ手もある
LINEのハードルが高い？解答欄のチャットボットも利用者が少ない（現状）
やるならLINEの導線を最初にする必要がある
0件のときの文言にLINE案内を追加★
用語の訳語について
今後日本語以外（特に英語）でヤドカリくんやproj-inclusiveの紹介をする機会が増える
→アプリ名や用語について定訳を用意した方が興味を持った人が調べやすい
SEO的にも有利
Scrapboxに訳語をまとめたページがあると表記に迷わないと思ったのですがいかがでしょうか？
例：「支援みつもりヤドカリくん」 <-> "Support Estimate Yadokari-kun (Hermit Crab)"
Eiko Goto.icon まとめたほうが良いですね！統一大事ですね！正式つくらなくてはですね
GitHub Projects を利用したタスク管理
招待できる人は招待済み
白取さん、古橋さん、しゅぱーんさんは招待済み
残りの方については、Projectにメンバーを招待するには、どうやらGitHubのOrgの方にまず招待する必要があるようなので、そちらの招待を進めてその後プロジェクトに招待します。
法人Hとの打ち合わせ
フィードバックあり
カナダとの連携
制度の改定情報を定期的に集める方法
制度が増えると人手で改定に気づくのが難しくなる
自動でGitHubに制度更新情報にもとづいて変更issueを立てられるのが理想
どこか管理されている情報源があればそこを参照したい
データベースやAPI等で公開されていればその情報を定期的に参照すればよい
更新されるタイミングも重要（〇カ月後に更新されます）
例
↑有料
公的なRSS的なものがあればSlackチャンネル等に流せる
防窮コミュニティに、どうやって情報を集めているか質問？
法人Gとの連携
概要（マストな事項）
論点
連携の可否（判断のタイミング？）
協定締結主体
マンパワー（負担・報酬を考えた公平性）
現在抱えている作業との独立性の確保
proj-inclusiveの目指すところ
先方の関与のあり方
Cにご相談？
次回日程、TODO
12月7日（土）10:00-12:00