proj-inclusive 定例 2025-02-08
手順
（１）ScrapboxにGoogleアカウントでログインする
（２）このScrapboxプロジェクトに参加する
Scrapboxの操作方法
箇条書き（「・」）：文頭で「スペース」or「タブ」
スペースを増やすたびに入れ子が深くなる
水平線（章を区切る線）：改行2回
見出し： [*** タイトル]
* が増えるほど文字が大きくなる
別ページへリンク： [ページ名]
用語を [] で囲みリンク化しておくと、同じ用語が登場するページとリンクすることもできます
ビジョン
お金を持っていようと持っていまいと老若男女が一緒に社会を考え行動する
自己紹介名前、このPJでやりたいこと、一言
右上のメニューで create my pageすると、 ctrl+i で自分のアイコンを設置できます
Koichiro Shiratori.iconKoichiro Shiratori：京都は雪が積もってます。いまも降っている……
syuparn.icon syuparn：DifyはAIをハッカブルにしてくれると強く感じました
Naoki Akazawa.icon naoki akazawa: ガンダムの映画見にいこうと思ってます。ネタバレ厳禁ですw
あらいゆうすけ.iconArai Yusuke(SD): 明日はマラソン大会です
Eiko Goto.icon：咳ゴホゴホ、本日 中森さんの家計講座day3だったのに、痰がらみ咳すぎで、欠席。。。
タイムスケジュール
10:00-10:15 説明、各自のニーズや野望の共有
10:15-10:30 進捗報告→今後の流れの議論
10:30-11:50 開発タイム：開発・作戦会議
11:50-12:00 ネクストステップ
進捗報告（YWT＝①やったこと、②わかったこと、③次にやること、を共有）
OpenFisca(バックエンド)開発
やったこと：
わかったこと：
次にやること：Blawxミドルウェア等の設定をバグとりする？（syuparn.icon的には1年以上かかりそう）
Django（Pythonのwebフレームワーク）が詳しい方がいればヤドカリ・スプリントで直してもらうのもあり？
OpenFisca Editor検証
わかったこと：コーディングは必要だが、自由記述欄から世帯情報を読み込み見積もり結果を返せた
次にやること：音声入力ができたらもっと使いやすくなる？・料金等調べる
支援みつもりヤドカリくんアプリのフロントエンド改善
やったこと：数字入力が重複する不具合修正、市区町村ソートを市区町村それぞれの50音順になるよう改善
わかったこと：OS、ブラウザ起因の不具合は分かりづらい
次にやること：
拡張性を持たせるためのステートの持たせ方を変更する
デザインチーム
やったこと：特になし
わかったこと：
次にやること：TOPページ実装確認/UI刷新進める/ヤドカリくんスタンプ
政策シミュレータ・インクルーシブチャート
やったこと：情報交換（シミュレータどんなもの）→データ申請完了！
わかったこと：合成人口データを活用して、生活困窮に陥るきっかけをシミュレーションで見出せるか？
次にやること：
人工合成データ審査待ち
その他
対外連携：H、F、G、M
ロジックモデルは折にふれてみんなで更新していく
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刷新など）
ヤドカリ・スプリント
文化祭みたいな感じのノリ
実行委員会
ソーシャルアクション、ムーブメント
ヤドカリ・ソーシャルアクション（防窮の社会実装）→ヤドカリ・スプリントがその構成要素
期間
2025年4月〜10月
公開のタイミングなどは社会的な動きに合わせていきたい。
防窮サミット（10月17日：貧困撲滅のための国際デー）
International Day for the Eradication of Poverty
1987年10月17日、フランスで10万人を超える人々が極度の貧困、飢餓、暴力の犠牲者に敬意を表すために集まったことをきっかけに、1992年12月22日の国連総会で制定されました。
最終ゴール
みんなの夢を語る
ユースケース
内容（アプリについて）
前提条件整理
スケジューリング
要件定義
タスク分解
作業（デザイン、開発、）
レビュー、テスト
公開
※法人H、財団M関連のインプットあり、整合的な開発プロセスが必要？→体制？
その他のコンテンツ
調査研究
家計管理
事前情報ヒアリング
現在の問い合わせ状況
法人K
法人H
法人W
法人HF
Sゼミ
研究チーム
→知見の共有、ユーザーの拡大
→広がりの可視化
→ソーシャルアクション（AI、防窮）
防窮＝予防
→公募など
みんなで作って保有するアプリ（やどかり）
1対1、パートナーミーティング（まず来てもらう（裾野）→具体化、月例など）
入口の半自動化→交通整理
アプリの修正項目やスコープ
案件的動き
オリジナルの動き
情報の公開方法
虎の巻：
どこまで書くか？
全部（ビジョン、防窮研、防窮研究会、proj-inclusive）
動画から資料にする
対象メンバー；白取、SD、syuparn、赤澤、古橋、Ohtaさん、Amy
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案内を追加★
ヤドカリ・スプリントの最初で、どこまでヤドカリくんで対応するかということを考えたい
進化を阻害しない設計
アプリの拡張性
制度改定の運用容易性
品質を維持できるか
etc.
みんなで育てられるようなものにしていきたい
openfiscaは高パフォーマンスな代わりに高コスト
低パフォーマンスでも低コストな技術スタックとうまく組み合わせ、棲み分けができると良い
こちらによせすぎると存在意義がぼやける
制度リストの案も一案
用語の訳語について
今後日本語以外（特に英語）でヤドカリくんやproj-inclusiveの紹介をする機会が増える
→アプリ名や用語について定訳を用意した方が興味を持った人が調べやすい
SEO的にも有利
Scrapboxに訳語をまとめたページがあると表記に迷わないと思ったのですがいかがでしょうか？
例：「支援みつもりヤドカリくん」 <-> "Support Estimate Yadokari-kun (Hermit Crab)"
Eiko Goto.icon まとめたほうが良いですね！統一大事ですね！正式つくらなくてはですね
法人Hとの連携
学会報告
フィードバック、アプリ改修依頼あり
カナダとの連携
制度の改定情報を定期的に集める方法
制度が増えると人手で改定に気づくのが難しくなる
自動でGitHubに制度更新情報にもとづいて変更issueを立てられるのが理想
どこか管理されている情報源があればそこを参照したい
データベースやAPI等で公開されていればその情報を定期的に参照すればよい
更新されるタイミングも重要（〇カ月後に更新されます）
例
↑有料
公的なRSS的なものがあればSlackチャンネル等に流せる
防窮コミュニティに、どうやって情報を集めているか質問？
メーリングリストに参加
法人Gとの連携
概要（マストな事項）
論点
連携の可否（判断のタイミング？）
協定締結主体
マンパワー（負担・報酬を考えた公平性）
現在抱えている作業との独立性の確保
proj-inclusiveの目指すところ
先方の関与のあり方
Cにご相談？
不具合報告用の環境取得ボタン追加
ヤドカリくんにフィードバックを頂いた際、ブラウザ、OS固有の不具合だとそもそも再現できず、どのような不具合が存在するのかすら分からない
別の似た不具合が解消されたタイミングで直ったと判断していて気づいていなかった
そもそも利用者がどんな環境で不具合にはまったかが分かればバグ特定が早くなる
ボタンで環境情報が取得できれば、利用者がそれをコピペして不具合報告と一緒に渡せる
UIについて（と、そもそも必要かどうかについても）意見を頂きたいです
置き場所：
見積もり結果のページの下の方に書く★
いったんここに置いておく
後で改修して移動すればよい
サイドバーのようなところからいつでも飛べるようにする
こちらの方がすぐ報告できる
報告方法：
どの導線でもいけるようにフォームに不具合と一緒に貼ってほしい旨を書いておく
技術者：ボタンを押して出てきた環境情報をGitHubのissueに貼る
研究調査等の協力者：アンケートからフィードバックを得る場合、（任意で）不具合に関するアンケート項目に貼る？
自由回答欄に「不具合があった際に、協力いただけるのであればコピペしてアンケートに貼ってください」
もしくは、ボタンを押すと不具合報告フォームが直接開くようにする？
利用者のgmailアドレスが見えてしまうのが難点
匿名フォームある？
情報：
ブラウザの種類（Chrome, Firefox etc.）
OSの種類(Windows, Mac, Linux, Android etc.)
(プライバシーに関わるものはNG。例: IPアドレス)
次回日程、TODO
2月22日（土）10:00~12:00