proj-inclusive Social Hack Day 72 2025-10-25
後：
手順
（１）ScrapboxにGoogleアカウントでログインする
（２）このScrapboxプロジェクトに参加する
Scrapboxの操作方法
箇条書き（「・」）：文頭で「スペース」or「タブ」
スペースを増やすたびに入れ子が深くなる
水平線（章を区切る線）：改行2回
見出し： [*** タイトル]
* が増えるほど文字が大きくなる
別ページへリンク： [ページ名]
用語を [] で囲みリンク化しておくと、同じ用語が登場するページとリンクすることもできます
ビジョン
お金を持っていようと持っていまいと老若男女が一緒に社会を考え行動する
自己紹介名前、このPJでやりたいこと、一言 Self-Introduction
右上のメニューで create my pageすると、 ctrl+i で自分のアイコンを設置できます
- Naoki Akazawa Naoki Akazawa.icon: さみぃ
- syuparn syuparn.icon
タイムスケジュール
11:30-12:30 ヤドカリスプリントやinclusiveの活動について概要
12:30-15:00 振り返り
15:40-17:00 振り返り
ヤドカリ・スプリントについて
ヤドカリ・スプリント
文化祭みたいな感じのノリ
実行委員会
ソーシャルアクション、ムーブメント
ヤドカリ・ソーシャルアクション（防窮の社会実装）→ヤドカリ・スプリントがその構成要素
期間
2025年4月〜10月
ゴール
ヤドカリくん新UIリリース
防窮サミット開催
スプリント振り返り: ヤドカリくん開発
やったこと
課題の整理
https://scrapbox.io/files/68fc87afaf1992cbf80ccea3.png
コミュニティ
コミットするメンバーが偏る、コミットできる量が時期によりむらがある
バス係数が低い（ほぼ1）
※バス係数：チームの冗長性の指標。「チームのうち何人がバスで事故に遭うとプロジェクトが止まるか」（=何人で仕事内容を共有しているか）をあらわす しかし、すでにユーザーがついているためプロジェクト停止や品質低下を放置できない状態
仕事の可視化が必要？（下記ロードマップへ続く）
特技が活かせる体制でない
UIデザイナーが間接的にコミットしている状態
情報
ドキュメントが少ない
開発で迷った際にコードを読み込む必要がある
プロジェクト構造
開発ケース別のガイダンス
デザインを変える場合
フロントエンドのページ遷移のロジックを変える場合
計算結果の金額を更新する場合
etc.
ヤドカリくんとは何か？
実はOpenFisca-Japanのリポジトリには記述が無い
ヤドカリくん全体をどうしたいかを可視化できていない
ロードマップを作る（下記）
アーキテクチャ
test, lintを拡充したい
ページを動かさないとバグが分からない
ページ遷移で場合分けが多い
本来ページ遷移の状態管理はロジック単体でテストされるべき
フロントエンドのロジックとレイアウトを分割したい
「特技が活かせる体制でない」の原因
Reactのページ遷移の仕組み等も読み込まないとデザインに変更が入れられない
（枠外のメモ）
バス係数を上げるには？
ナレトラやコミットする人を増やす必要がある
（前提としてボランティアとして参加していただいているので、）
コミットにも段階がある
I: inclusiveの活動を知り、issue単位での何らかの貢献をする
II: プロジェクト単位での貢献をする（何かのゴールに対するオーナーシップを持つ）
III: 全体的な設計を把握し今後の方針を考える / 設計をメインで考える
バス係数の観点では I->II （オーナーシップを持つ）が増えると良い
Iが増えるにはgood first issueを用意するのが良い
good first issueに求めるもの
設計についての学びがある
オンボーディングとして使用できる
独立していて比較的軽めの内容
コントリビューターに感謝を伝えるため、リリースノートに今回のバージョンのコントリビューター一覧を載せる
ロジックとレイアウトを分ける設計
ヤドカリくんのページ遷移とその条件を一目、一か所で管理できる必要がある
正しい状態遷移になっているか判断できないと品質は担保できない
案
configファイルに状態遷移図を定義し、そこからコードとテストを自動生成 Naoki Akazawa.icon
状態クラスに全状態と遷移条件を定義し、各ページでそれを呼び出し、状態ごとにユニットテスト実施 syuparn.icon
できるだけフレームワークを使用したい
フレームワークを使えば、それを知っている人にとって学習コストが下がる
ライブラリ側のドキュメントも充実している
今後のロードマップ
https://scrapbox.io/files/68fc87c6f7ebdec0527f1dc3.png
役割を整理し、それぞれに対してロードマップを引きたい
やることごとにリーダーとなる旗振り役が必要
まずは旗振り役を決めるところから
ベストエフォートのため期限は決めない
ただし(1)制度の対応のみ受託し期限が決まっている可能性があるため、
「バス係数」の観点から、それぞれのチームで複数メンバーが動けるとよい？
やっていきたいこと
1. 制度の改修、追加対応
2. コミュニティの拡大（blawxで支援団体の方も制度計算の開発ができるように）
3. 支援者側用のUI、UX
4. 品質と分業のバランスのためのツール→これ自体がロードマップの課題意識
5. 分業しやすいアーキテクチャ
6. コスト最適化
7. オンボーディングのためのドキュメント
8. OpenFiscaにひもづかない、選択肢にない情報を拾う
分類
デザイン、UI
担当：？
2. コミュニティの拡大（blawxで支援団体の方も制度計算の開発ができるように）
3. 支援者側用のUI、UX
5. 分業しやすいアーキテクチャ
7. オンボーディングのためのドキュメント
チャットボット
担当：？
6. コスト最適化
7. オンボーディングのためのドキュメント
8. OpenFiscaにひもづかない、選択肢にない情報を拾う
バックエンド
担当：syuparn.icon
1. 制度の改修、追加対応
2. コミュニティの拡大（blawxで支援団体の方も制度計算の開発ができるように）
7. オンボーディングのためのドキュメント
インフラ（Google Cloud、PyPI等）
担当：Naoki Akazawa.icon
2. コミュニティの拡大（blawxで支援団体の方も制度計算の開発ができるように）
6. コスト最適化
7. オンボーディングのためのドキュメント
ネクストアクション
旗振り役を決める
ドキュメントを作る
次回日程、TODO
proj-inclusive内で隔週土曜に開催
11月??日（土）??:00~??:00
スプリントが終わったので時間変える？