proj-inclusive 定例 2024-12-07
後：
手順
（１）ScrapboxにGoogleアカウントでログインする
（２）このScrapboxプロジェクトに参加する
Scrapboxの操作方法
箇条書き（「・」）：文頭で「スペース」or「タブ」
スペースを増やすたびに入れ子が深くなる
水平線（章を区切る線）：改行2回
見出し： [*** タイトル]
* が増えるほど文字が大きくなる
別ページへリンク： [ページ名]
用語を [] で囲みリンク化しておくと、同じ用語が登場するページとリンクすることもできます
ビジョン
お金を持っていようと持っていまいと老若男女が一緒に社会を考え行動する
自己紹介名前、このPJでやりたいこと、一言
右上のメニューで create my pageすると、 ctrl+i で自分のアイコンを設置できます
Koichiro ShiratoriKoichiro Shiratori.icon: 歯医者の歯科検診の予約が取れたけどクリスマスイブ……
syuparn syuparn.icon: 先週は大掃除をしていました
oyuuuhanoyuuuhan.icon:今日はゆっくりできます
Amyさん
Akazawaさん
タイムスケジュール
10:00-10:15 説明、各自のニーズや野望の共有
10:15-10:30 進捗報告→今後の流れの議論
10:30-11:50 開発タイム：開発・作戦会議
11:50-12:00 ネクストステップ
進捗報告（YWT＝①やったこと、②わかったこと、③次にやること、を共有）
OpenFisca(バックエンド)開発
わかったこと：OpenFiscaよりも柔軟に（金額以外の計算も）扱えることが分かった/使い分けられそう
すごいKoichiro Shiratori.icon*4
syuparn.icon 告知とscrapbox, notion準備
OpenFisca Editor検証
やったこと：
わかったこと：
次にやること：
支援みつもりヤドカリくんアプリのフロントエンド改善
やったこと：
わかったこと：
次にやること：拡張性を持たせるためのステートの持たせ方を変更する
デザインチーム
やったこと：特になし
わかったこと：
次にやること：TOPページ実装確認/UI刷新進める/ヤドカリくんスタンプ
政策シミュレータ・インクルーシブチャート
やったこと：情報交換（シミュレータどんなもの）→データ申請完了！
わかったこと：合成人口データを活用して、生活困窮に陥るきっかけをシミュレーションで見出せるか？
次にやること：
人工合成データ審査待ち
その他
対外連携：H、F、G、M
ロジックモデルは折にふれてみんなで更新していく
9月以降のGUI刷新
方針
Figma刷新版 におおたoyuuuhan.iconさん作成のトップページ案と、以降のページの案がある Chakra.uiのコンポーネント・スタイルの範囲内で、トップページのスタイルを以降のページにも適用したい
トップページの動きのあるデザインや、以降のページのフロントエンド実装はイシュー化して、フロントエンドエンジニアのコントリビュートを募る予定
水色（背景）と黄色（文字）のコントラスト比はアクセシビリティ的に見にくいかも？(参考サイト) 検討事項
スマホのレイアウトをベースとしておおたさん検討中
ユーザービリティを考えるとまだもっと全体のフローは最適化しないとなという印象
以下の質問が大きな分岐となるため、一旦これらを中心に考えるのがいいかと感じました。見落としがあるかもですが、これ以外は比較的シンプルな分岐になるかと感じています。
病気があるかどうか
配偶者がいるかどうか
furuhashi.icon 子供、祖父母の有無も同時に質問しますか？
何人いるか→一人一人に対して同じ質問群
質問のカテゴリを示す
同様の内容の質問は全世帯員分まとめて聞くと入れやすい？
誰についてか分かりづらいので今は人ごとに聞いている
世帯構成等基本情報 -> それぞれの世帯構成員の情報 ->
アトミックな質問とそれをグルーピングした質問群を前の質問項目によって出し分ける
質問フォーマット
フォーム形式
❌うまくカテゴリ分けしないと脈絡がなくなる
❌スマホでスクロール必要な画面が出てくると負荷を高く感じてしまうかも
⭕️特にPCだとフォームで一覧化されている方が見やすいかも
一問一答
❌ページ数が多くなるかも
完全な一問一答でなくてもよく、いくつかの質問を同じページにまとめてもいいかも
⭕今後の拡張がしやすい
⭕ユーザーが聞かれている質問に集中しやすい
参考サイト
進め方
以下並行して行う（いずれも現状期限はない）
対外連携でのフィードバック事項
現在のレイアウトに対して修正
トップページのデザイン刷新
はじめはデザイン案をFigmaで作成、比較するところから
案は固まったら関係各所に頭出ししたい
色々な利用者、関係者の方に意見を伺って慎重に進めたほうがよい
手戻りできる範囲で進める
決まった後で開発内容をissue化、コントリビューターが取れるようにする
質問フローのデザイン刷新
上記同様、トップページとは独立して進められる
ローカルでの「アプリ体験会」の開催可能性
例：ユーザーに対してのレイアウト形式(一問一答orフォーム式等)のABテストができるかもしれない
Figmaを見せる or プロトタイプ
一般の方向けなので実際に動いて触れるものの方が分かりやすい
一方、そこまで実装を進める必要があるので工数が増える
フロントエンド実装難易度によっても設計方針が変わるため、こちらで開発をある程度進めた段階で行いたい
レイアウト改定にあたりこの形式を採用したという裏付けにもなる
デザインの進め方について改めて確認 (12/07)
トップページと入力のウォークスルーは別々に進められる
トップページ
入力のウォークスルー
条件分岐が分かるまでレイアウト設計が止まっている
条件分岐網羅しなくてもUI設計は進められる？
今やっていることが一段落してから進めた方がよい
レイアウトが大幅に変わるため、（許可を貰う必要は無いにしても）各関係団体へ事前調整が必要
刷新によってバグが大量に出てしまう等の問題は避けたい
リソースが十分に確保できた状態で進めたい
やるなら一気に進めたい
新UIの必要性、取り組みに関して関係者と握っているタイミングがあればそこにスケジュールを合わせる
刷新のアナウンスも兼ねて
現状は必須ではない
社会的に意味があるタイミングを狙うのも手
例
新年度（新生活で生活環境が変わる）のタイミング
生活困窮者支援関連の活動がある日
コミュニティの立ち位置、認知度の足場を固めるためにも、発表の場と絡めてスケジュールを考えるのは有効
困りごとに関連する窓口の紹介を追加する件は、新UIの方がやりやすい？
窓口紹介の件をUI改修のスコープに含まれるか否か
要件定義を行いタスクに分割
継続的(2~3か月毎)に中規模の開発を行うより、単発的(年1)に大規模な刷新を行う方がよい？
「会社」よりは「文化祭」的な開発の進め方の方が合っている？
SHDのスプリントに合わせて、オフライン会（3月）に要件定義する？
事前告知する
分ける場合、分けない場合
分けないほうがトータルの開発量が少ない
分けたほうが窓口紹介機能のスケジュールのリスクが少ない★
外部との連携が未経験なので、知見を積むために安全に進めたい
その後改めてUI開発の要件定義を始める
※世界貧困撲滅デー (International Day for the Eradication of Poverty)
日程: 毎年10月17日
目的: 国連が定めた公式の記念日で、貧困撲滅の重要性を啓発する日です。世界中でイベントやシンポジウム、キャンペーンが行われます。
背景: 1992年に国連総会で採択され、1993年から正式に記念日として認められました。
ヤドカリ・スプリント（仮）（UI刷新など）
防窮スプリント（仮）、防窮Era（仮）、防窮マラソン（仮）、防窮キャンペーン（仮）、カーニバル
文化祭みたいな感じのノリ
実行委員会
期間
2025年3月〜9月？
公開のタイミングなどは社会的な動きに合わせていきたい。
内容
前提条件整理
スケジューリング
要件定義
タスク分解
作業（デザイン、開発、）
レビュー、テスト
公開
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月21日（土）10:00-12:00
定例はどうする？
コアな話があれば別日に設ける
活動の紹介と報告事項（概要がメイン）は冒頭に話す