都知事杯後〜2023年度末の展望（プロダクト編）
あくまで案です。現実的でなかったり項目や順番にご意見あればお願いします。（ どなたでも編集いただいて構いません）
It's just a suggestion. Please let us know if it is not realistic or if you have any comments on the items or order. (Any one can edit it.)
English version is at the bottom
都知事杯で夢と風呂敷が広がったので、そこからどうやって持続可能なサービスを構築・提供・展開していくか、一旦現状を整理・見直して、展望を考えたいです。
もちろん、これから東京都をはじめとした自治体や社会福祉団体のサポート・フィードバックを受ける中で、やり方を変えていくことはあると思います。
ただ、現時点で何ができそうか、するべきなのかを整理しておくと、軸がぶれずにより良いプロダクトができると考えています。
以下書き出してみましたが、考えられていない観点があったり、他にもできることがたくさんあると思うので、適宜追記してください。疑問・異論も遠慮なくどうぞ！
OpenFisca バックエンドAPI
現状の整理
制度自体が複雑かつ、整理されて作られていないため、OpenFiscaで吸収して整合をとるのは限界がある
特に特定の親族の属性を参照する制度はOpenFiscaで表現しづらい
今は「あなた」が成人の前提ですが、子供がユーザーの場合はEntityの考え直しになる。。対応するかどうかは要検討
対応する場合計算速度の問題も発生する？
対応制度を追加する度に、同じ情報を用いる実装ずみの制度と整合が取れるよう、過去の実装の見直しが必要になることが多い
同じ名前のVariable（計算式）は同じ制度を表す場合も、同名の全く別の制度を表す場合もある
特定の制度用にモデル化した計算式が他の制度では使えなかった
OpenFiscaのフォーマットがかっちり決まっているので、そこから外れた形で拡張しにくく、無理にやると品質の担保が困難になる
OpenFisca自体の調査をしたい
税金や年金なども対応できるかもしれないが、膨大な作業量が必要になり、困窮者支援のフォーカスからも少しずれてくる
一方、控除、社会保険料は無視すると一部制度で対象者が下振れする問題もあり
どこまで対応するかのガイドライン
株式会社compassさんが、行政と連携してひとり親支援制度の算出アプリを開発しているそうなので、今後連携の話があるかも。バックエンドAPIとして提供することも可能 DX junkyard
今後の方針案（フォーカスを絞る）
⭐️今後追加できる・するべき制度は5~10個程度？それ以上は難しそう
⭐困窮者支援制度を今一度洗い出し、対応する制度を行政職員等の有識者の声をもとに絞り込む
五月雨式に制度追加するのではなく、目標を決めて一旦そこまで対応するのが良さそう。
⭐決められた条件から適用可否が判定しやすく、金銭給付・貸付の制度のみ対応した方が良い。以下のような制度は対応難しい。
⚪︎⚪︎を希望する人対象（条件から一意に決まらない）
✖️✖️が利用できる （金銭以外のサービス）
制度適用可否判定・金額算出以外の処理はフロントエンドやチャットボットに任せた方が良さそう。
優先順位を付ける際の実装難易度の観点を洗い出す（例：親族に対する条件分岐が多い）
制度の実装場所を整理したい
1. 制度によらない一般的な概念（年齢、学年、都道府県etc）
2. 複数の制度から共通して参照される制度（所得、所得控除etc.）
3. 特定の制度でのみ参照される要素
重複やバグを防ぐために2.と3. を区別しやすい状態にしておきたい
同じ名前の別制度も命名を整理したほうが良い？
furuhashi.icon OpenFiscaの変数がグローバルなので、どうしても密結合になってしまう…。制度によって粒度もまちまちなので、対象制度を制限するか複雑すぎるロジックを省略するしかない？
生活困窮者がマイナンバーカードをどれくらい持っているか
窓口のデータ管理をどうするか(DB必要？)
DX junkyardさんの側でAPI提供してくださる？
できない場合も現状と同じフロントべた書きで対応可能
フロントエンド
⭐基本的なことから対処する必要がある。これをせずにUIの改善は難しい
対象制度が増えてきたので、入力に必要な項目がだいたいわかってきた。
⭐入力項目が多いので、フォームを見直し、ユーザーの負担を軽くする必要がある
カテゴリ分け
複数ページで段階的に入力
⭐問い合わせ先の表示をどうするか。制度ごとの問い合わせ先を増やす場合、どのように表示するか。
⭐多言語対応
まずは英語から。多国語対応の枠組みを作るのに時間がかかるが、一度作ってしまえば追加は多少楽になる。枠組みを作るところまでは年度末までにやりたい
何ヶ国語目指す？外国語話者の協力を募りたい
現場、コロナ渦では英語だけあれば良いわけではなかった（中国語、ネパール語etc.）
専門用語の定訳については都に確認するのがよいかも
画像保存では日本語も付けると渡した先の現場の方がとまどわない
URLで結果を共有できるようになれば、画面の言語を切り替えることで言葉の壁を超えられるようになるかも？あぜがみ.icon
多言語対応に加えてやさしい日本語も追加するとより多くの外国語話者をカバーできるのではmu.icon
細かいUIの工夫
トップページに対象制度一覧を表示できるようにするなど
⭐イラストやデザインを充実・洗練させる。70点から100点を目指すにはデザイナーの力が必要。
チャットボットの多言語の設定を要確認、で質問できないため
チャットボット
森本さん、検討・追記いただけるとありがたいですfuruhashi.icon
OSSとしての透明性の確保、品質の担保のため、より開発ドキュメントを整備したりテスト（動作確認）の証跡を残すことが必要になってきそう furuhashi.icon
ノーコード開発はどうやって上記を実現している？
furuhashi.icon確かにAIの説明性を担保するのは難しいですね。人の手で設定しているところはできるだけ見れたらと思うのですが、閲覧権限で良いのでコアメンバーに各種設定ページのアクセス権を付与してもらうことは可能でしょうか？
もりもとだいき.iconプロンプトの全てをgit hubに載せるのが一番手っ取り早いかもしれません。miiboの管理者権限の付与にはお金がかかるみたいです。ちゃっかりしてますよね。
開発過程が見えると他の方も開発参加しやすいと思います
もりもとだいき.icon今後開発する部分において、共同で進められる部分は進めたく思います！一方でAIの方ではデータの質が結構効いてくるので、そこは注意したいなと思います。
furuhashi.icon了解です！
チャットボットはポテンシャルが高い分、何からどのように機能拡張していくか見当がついていませんfuruhashi.icon
もりもとだいき.iconせっかくなら東京都の方とも話してみたいですね！都知事杯の運営の方も、もしかしたらアシストくれるかも？
ユーザーの行動変容を促すアプローチ？
もりもとだいき.icon
チャット履歴の解析
ユーザがどのような疑問・不安を持っているかを統計データとして行政に提出できるサービス開発
https://scrapbox.io/files/653dbab2e84724001c74e827.png
https://scrapbox.io/files/653dbac810a161001b4643cc.png
グルーピングとネガティブ・ポジティブワードの出力
東京都の公式LINEとQAの拡張、なぜ窓口に行かないのか・ 支援制度を受けるのは恥ずかしいなどの意見収集
支援制度のQAと各区の公式LINEの拡張
miiboの所有権をproj-inclusiveに譲渡(共通のgoogle アカウントを使用)
furuhashi.icongoogle accountはいろいろなサービスに紐づいているため、複数人で使うのは望ましくないようです。クラウドサーバーでは、管理者を防窮研究所のアカウントにして、それと同等か弱い権限を開発者に付与して共同管理しています。
もりもとだいき.iconしらとりさんと相談ですね。管理者権限を付与するのに毎月のお金がかかるので際どいとこですよね。
月1万円程度であれば社団法人で出すこと可能なので、早めに社団法人管理に移行したい
LINEボット設定ページの複数人管理は可能？
もりもとだいき.iconスタンダードプラン（月1万円)では、閲覧権限が5人新規で付与されます。
furuhashi.iconフリープランだとメッセージが月1000通までなので、これも社団法人管理に移行した方が良さそうですね
LINE BOTからの発信の検討
どうやってデータを取るか？
質問を待つ
リマインダー機能を付ける
3日後にリマインド、どれだけ繋がったか、繋がらない場合の理由などのデータが取れる
行政にとって効果を確認しやすい
Google Analytics（GA）
あぜがみ.icon個人的にGAを使ってみたいので、ヤドカリくんでできそうなことを記載します。（勉強中ですが）
GAを活用することでのメリット
利用実績を可視化しておくことで、この先の自治体との連携やビジネスに繋げる時にも良いアピールになる
ユーザーの行動を分析することでサービスとしての改善点が見えるかも
実際にできそうなこと
アクセス状況
どの地域から（市区町村など）
GAの地域情報よりも、フォームの入力情報を集計できた方がより実態に近い結果が取れる
どの端末から（スマホ/PCなど）
どの入口から（LINE Bot、xxのQRコード、SNSなど）
自治体ごとの利用の程度が分かれば自治体にフィードバックできる
行政LINEからの流入・コンバージョンの実績が取れれば、他の行政への展開もやりやすくなりそう
etc...
コンバージョン率
「計算する」がクリックされた（計算結果画面迄進んだ）率
チャット機能が使われた率
結果画面から窓口に繋がった率
etc...
その他
離脱ページの特定
よく表示される制度
各ページの滞在時間
etc...
具体的なタスク
可視化したい内容の絞り込み
UIが完全に固まってから対応したほうがいいことが多いので、簡単なものから対応する
どの程度のデータを収集するか、ユーザーの属性情報
GTMのタグの設定、埋め込み
上田さんに対応していただいたので、疑問点があれば上田さんに確認する
ダッシュボードの作成（Looker Studioを使うかも）
プライバシーポリシーとかも整理していかないと
（直近のアクセス状況）
https://scrapbox.io/files/653e00c8cccab0001c63a8f1.png
チャットボット
https://scrapbox.io/files/653e012109abc7001c8cd084.png
政策シミュレータ
ましかさん、検討・追記いただけるとありがたいですfuruhashi.icon
年度末に東京都のデモイベントがあるので、何かしらの動くアプリ（プロトタイプ）があると、いろんな場面で話を広げやすそうfuruhashi.icon
その他
エンジニアの仲間を集めるために、アドベントカレンダーに投稿してもよいかも
（エンジニアの）アドベントカレンダー = 12月に毎日1記事ずつ技術記事を持ち寄って公開するお祭り
furuhashi.icon楽しそう!
ヤドカリくんの技術的な仕組みを説明することで興味を持ってもらう
広報
project-inclusiveのX(Twitter)アカウント作る？えいみーさん中の人！
Below in English
The Tokyo Governor's Cup spread our dreams, so we would like to organize and review the current situation and think about the future, how to build, provide, and develop sustainable services from there.
Of course, I think we may change our approach as we receive support and feedback from local governments and social welfare organizations, including the Tokyo Metropolitan Government.
However, I believe that if we sort out what can be done and what should be done at this point, we will be able to maintain our focus and create a better product.
I've written it down below, but I'm sure there are points of view that I haven't considered, and there are many other things that could be done, so please add them as appropriate. Please feel free to ask any questions or objections.
OpenFisca backend API
Organizing the current situation
Since the system itself is complex and not well-organized, there are limits to how OpenFisca can absorb and harmonize it.
Each time a corresponding system is added, past implementations often need to be reviewed to ensure consistency with previously implemented systems that use the same information.
Since OpenFisca has a fixed format, it is difficult to expand it in a way that deviates from it, and if we force it, it will be difficult to guarantee quality.
It is necessary to investigate the specifications of OpenFisca itself and examples of how OpenFisca is used overseas.
It may be possible to deal with taxes and pensions, but it would require a huge amount of work, and the focus would shift slightly from supporting the needy.
It seems that Compass Co., Ltd. is developing a calculation app for the single parent support system in collaboration with the government, so there may be talks of collaboration in the future. Can also be provided as a backend API Future policy proposal (narrow focus)
⭐️Are there 5 to 10 systems that can/should be added in the future? It seems more difficult than that.
⭐ Identify support systems for people in need once again and narrow down the corresponding systems based on the voices of experts such as government officials
Rather than adding new systems in sequentially, it would be better to set a goal and address it once.
⭐It is easier to determine whether or not the application is applicable based on the predetermined conditions, and it is better to deal only with the system of monetary benefits and loans. The following systems are difficult to deal with.
Targeted at people who desire ⚪︎⚪︎ (cannot be determined uniquely based on conditions)
✖️✖️ can be used (non-monetary services)
It is better to leave the processing of determining whether the system is applicable or not and calculating the amount other than to the front end or chatbot.
list up points of view to estimate implement difficulty
1. general concepts independent to specific systems (age, school grade, prefecture etc.)
2. systems referred by several systems (income, deduction etc.)
3. items only referred by a system
2. and 3. should be distinct to prevent bugs and duplications
furuhashi.icon I see. However, all variables of OpenFisca have to be global. So the logic tightly coupled... This is also the case with actual systems, so it seems necessary to choose whether to limit the number of compatible systems or omit overly complex logic.
front end
Gergana, I would be grateful if you could review and add your comments furuhashi.icon
⭐It is necessary to deal with basic things such as linters, tests, and state management (introducing Recoil, etc.)
It is difficult to improve the UI without doing them.
As the number of applicable systems has increased, we have come to understand the items required for input.
⭐Since there are many input items, it is necessary to review the form and reduce the burden on the user.
Categorization
Step-by-step input on multiple pages
How should contact information be displayed? If we want to increase the number of contact points for each allowance or loan, how should they be displayed?
⭐Multilingual support
Detailed UI improvements
⭐Enrich our illustrations and designs. Aiming for 70 to 100 points requires the help of a designer.
Chatbot
Morimoto, I would be grateful if you could review and add your comments furuhashi.icon
In order to ensure transparency and quality as an OSS, it becomes necessary to maintain development documentation and leave a trail of testing (operation confirmation) furuhashi.icon
How does no-code development achieve the above?
Chatbots have a lot of potential, but I have no idea where to start and how to expand their functionality furuhashi.icon
Compass Co., Ltd. seems to be using a LINE chatbot for career consultation, so it may be useful to ask them about their case studies? An approach that encourages user behavior change?
Policy simulator
Mashika-san, I would appreciate it if you could review and add comments furuhashi.icon
If there is a working app (prototype) at the end of the fiscal year, it will be easier to spread the proposal in various situations furuhashi.icon
Others
Post an article to an advent calendar so that engineers get interested in our project
engineer advent calendar: a festival in December to post articles written by many engineers
they are released one by one everyday until Christmas, like "advent calendar" candies
describe technical details about Yadokari-kun