日記2025-06-20
キャパが足りなくなると言葉がキツくなりがちなので気をつける
- 組織図を欲しがる人も関連してるかも
- ネガティブ・ケイパビリティ
nishio おっ、登録人数が1000人を超えてた
nishio 1000人以上の人にやって欲しいことを分配しようとすると普通は個々人に合わせて調整する余裕がないから一律で割り振ることになりがちなのだけど、この方法なら個々人が選択肢の中からやりたいものを選んで実行するので個々人は得意なことはたくさん行われる。 nishio 重要なタスクはスコアを増やせばいいし、需要が下がったタスクはスコアを減らせばいいし、新しくやって欲しいことができたらタスクを追加したらいい。すべてのタスクがこれでいいわけではないが、なるべくたくさんやって欲しい系のタスクの1000人以上のサポーターでやっていく上ではとても良いやり方だ nishio これの話
nishio: 今までにない規模で政治をゲーミフィケーションする社会実験が行われている。この最初の実験に参加できる機会はあと1ヶ月くらいしかないのでぜひ体験してみて欲しい。この開発自体がオープンソースで日々ガンガン行われている。 チームみらいアクションボード チームみらいアクションボード
Qiitaに技術記事を書いたらいい気がしている
Noteに書くより良いのではと
寄付金可視化を支える技術
- Stripe APIからデータをとって可視化
- Stripe管理画面へのアクセス権を与えると誰から寄付があったか見えてしまうのでアクセスできる人を絞らざるをえない
- 実装自体は簡単でChatGPT o3にPythonで書いてといったら書いてくれた
- それを使ってデータをとってみる作業を手元で試行錯誤してからGitHubに入れて、あとはDevinに「これでデータが取れるから参考にして」っていったら大体できた
- 不明瞭要件を明確化するスキル
- データソースは？
- 1個のStripe口座からデータをとるだけかと思ったら違った
- そもそも2024年に作った個人の政治団体の口座と、2025年に作った政党の口座とがある
- そしてStripe経由ではなく銀行振込が行われるケースもある
- 1個のStripe口座からデータをとるだけかと思ったら違った
- 出力先は？
- Google Spreadsheetに書いてLooker Studioで可視化したいと言う要件と、ウェブサイトで表示したいのでGET APIを作ってくれと言う要件が来ていた
- これ両立しないし、そもそも表示したいデータが異なるのでは
- 結論
- 銀行振り込みを記帳するGoogle Spreadsheet(A)
- 2つのStripe口座と(A)を読んで合算するGitHub Actions
- 日毎にまとめた時系列データをGoogle Spreadsheetに出力、これをLooker Studioで可視化
- Webサイト向けにGET APIが必要な件は、JSONを生成してGistにアップロードすることにした
- データソースは？
- Devinが大活躍
- Webサイトに関しても「APIを叩いて表示して」と言ってAPIと画面デザインの画像を渡すだけで大体うまくいった
- 最終的に少し人間が整える必要はあった
- これはDevin動画の「最初と最後を人間がやって、中をDevinがやる」という活用パターンに合致しているね
- Stripe APIからデータをとって可視化
サポーター地理分布可視化を支える技術
- 詳細に住所をとると個人情報としての扱いが必要になって負担が増えるし、そもそも欲しいわけではない
- しかし「大体どこにいるのか」の情報は欲しい
- →郵便番号
- 初期の構成
- Google Formでボランティア登録
- Google Spreadsheetに入る
- Google App ScriptでAPIを叩いて郵便番号を住所に変える
- 要件の変化
- アクションボードリリース
- Google Formで登録した人と、チームみらいアクションボードだけ登録した人、重複を排除して合算したい
- アクションボードに入った人にGoogle Formにもう一度入力してっていうのは微妙
- どちらの入口を好むかは人によって異なるので両方維持したい
- アクションボードのデータはSupabaseに入っている
- Google App Scriptで扱うには少し荷が重い
- データ分析パイプラインをまるっとGitHub Actionsに移行することにした
切り替えの数日前には完了してLooker Studioに入れていたが、本番切り替えすると問題に気づく
- 大阪市に穴が空いてるのはおかしいのでは？
- 雑にDevinに振ったら破壊された
Devinの活用度合いの可視化？
政策PRを支える技術
- データ収集
- Devin
1000人と言わず200人くらいで大部分の「人の話を聞こうとする人」は情報洪水に溺れてしまい、一部の「人の話を聞かずに言いたいことを言う人」だけが自説を主張して喧嘩し始めるのが難点ですね。(nishio/Slack)
- そういうニーズがあるのはよく観測されている
- Discourseないの？という質問があった
- 「人間と会話したい人」と言ってる人のうち「他人に自分の話を聞かせたい人」が少なからずいると思う
- でも100人の場で自分が1話したら99聞かないとバランス取れない
- 他人が価値を感じる話をしているかどうか
- 他人が価値を感じない話をしている人の周りからは他人が去っていく
間違った人を入れないための審査コストを節約して先に入れた上で、不適切であればbanするってのは仕方ないことだと思う
- 目的達成のためのグループなので目的達成にネガティブな影響を及ぼす人は排除すべき
日記2025-06-19←日記2025-06-20→日記2025-06-21 100日前 日記2025-03-12 1年前 日記2024-06-20