proj-inclusive 定例 2025-03-22
手順
（１）ScrapboxにGoogleアカウントでログインする
（２）このScrapboxプロジェクトに参加する
Scrapboxの操作方法
箇条書き（「・」）：文頭で「スペース」or「タブ」
スペースを増やすたびに入れ子が深くなる
水平線（章を区切る線）：改行2回
見出し： [*** タイトル]
* が増えるほど文字が大きくなる
別ページへリンク： [ページ名]
用語を [] で囲みリンク化しておくと、同じ用語が登場するページとリンクすることもできます
ビジョン
お金を持っていようと持っていまいと老若男女が一緒に社会を考え行動する
自己紹介名前、このPJでやりたいこと、一言
右上のメニューで create my pageすると、 ctrl+i で自分のアイコンを設置できます
Koichiro ShiratoriKoichiro Shiratori.icon：SHD出てましたー。初心忘るべからず……！
Naoki AkazawaNaoki Akazawa.icon: 最近、何やかんやで延期してたガンダムをようやく見に行きましたw
syuparn syuparn.icon: Claude Codeにコードを読ませたり文章を書かせたりして遊んでました
Arai Yusuke(SD)あらいゆうすけ.icon:新PCを購入からの、空手教室行ってからの、来週末全日本AIハッカソンへw
ふるはしfuruhashi.icon : サマータイムに突入して19時まで明るいです。変。
タイムスケジュール
22:00-22:10 説明、各自のニーズや野望の共有
22:10-22:30 進捗報告→今後の流れの議論
22:30-22:50 開発タイム：開発・作戦会議
22:50-23:00 ネクストステップ
進捗報告（YWT＝①やったこと、②わかったこと、③次にやること、を共有）
OpenFisca(バックエンド)開発
わかったこと：ソースコードの場所を見つけた（コードリーディング中）
次にやること：Blawxの動作原理を調べる（チュートリアルができるとよい）
（スプリント）実運用を行う上で必要な検証を実施
ルールの作成者が扱えるようにするためのセキュリティ構成、インフラ構成の検証
furuhashi.icon Blawx作者とコンタクト中。現在は1人で趣味として開発しているらしい。生成AIを取り込んだversion2をクローズドで開発中とのこと。
OpenFisca Editor検証
やったこと：
わかったこと：
次にやること：
支援みつもりヤドカリくんアプリのフロントエンド改善
やったこと：
わかったこと：
次にやること：
拡張性を持たせるためのステートの持たせ方を変更する
デザインチーム
やったこと：特になし
わかったこと：
次にやること：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日の国連総会で制定されました。
基本方針
スプリントを通して、局所的にリソースを集中して開発やPRを推し進める。
また、スプリントの勢いを利用して、対外的なアピールを行いコミュニティ形成や連携活動を進める。
スプリントのスコープ
ヤドカリくんの将来像の検討
ヤドカリくんv2の開発のリリース
PRとコミュニティメンバー（個人、組織）の拡大
スプリントの開発スコープ
UIのアップデート
UIについてのこれまでの積み残しを解決
(確定)困りごとに関連する窓口の紹介
トップページを新デザインに変更
一問一答形式のレイアウト実装
一問一答形式の全項目展開
フロントエンドのリファクタリング
特定疾病の見積もり結果表示
結果画面に表示された制度の地域ごとの問い合わせ窓口表示
Blawxの導入のための検証
今のヤドカリくんは新しい制度への対応にそれなりにコストがかかる状態。また少し広い目線で見るとより多くの参加者を巻き込んでいきムーブメントとして成立させることも重要。そこで、ヤドカリくんユーザー、開発者（我々）に加えて、制度を追加するユーザーを作って、対応コストを下げつつコントリビューターを増やしていけるようにするのが目的。
Openfiscaを利用しつつもヤドカリくんで助かる人を増やすという意味でさらに新しい要素を積極的に取り込んでいこうという意味合いもある。
furuhashi.icon 非エンジニアに新しい制度をBlawxで試験的に実装してもらえれば効果検証ができそう
KPI（ソーシャルムーブメントとしての成功を定義する）
成果物の公開
ヤドカリくんv２のお披露目（Output）
防窮研究会の研究成果のお披露目（Output）
ヤドカリくんv3の構想（Output）
furuhashi.icon どのように広報（宣伝）して、ユーザーフィードバックやGoogle Analyticsの収集・解析をするかを考えられると、外部へのアピールや今後の取り組みにつながりそう
ムーブメントとしての成功（参加者向け）
ヤドカリスプリント終了時の参加人数（現状：人→人）
フィードバック数（件）
関わり代が広がる（潜在参加者向け）
Good First Taskの参加数
GoodFirstTaskの数
10月までのTODO
GoodFirstTasks（チュートリアル）として何がいいかを考える
目的）新しい参加者が軽く参加できる仕組み（フロー）として
アイデア）予防するためのアイデア募集
アイデア）月一での新歓
アイデア）マテリアルを見る
財団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は高パフォーマンスな代わりに高コスト
低パフォーマンスでも低コストな技術スタックとうまく組み合わせ、棲み分けができると良い
こちらによせすぎると存在意義がぼやける
制度リストの案も一案
制度の改定情報を定期的に集める方法
制度が増えると人手で改定に気づくのが難しくなる
自動で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アドレス)
ボタンを押すとOSとブラウザの種類を表示
不具合報告の際コピペして添付してもらう
次回日程、TODO
4月5日（土）22:00~23:00