米国IRSの納税ツール Direct FileがGitHubに公開！
引用元：https://news.ycombinator.com/item?id=44182356
ソースコード公開は大変じゃないと思うんだ。税システムとの連携とか、今の税法にちゃんと合ってるか確認する方が大変でしょ。でも、ソースコードが公開されてても、政権が変わったらこういう部分って潰されちゃうんじゃないの？
これってビジネスチャンスになりそうだね。
いや、このプログラムの目的はまさにそのビジネスチャンスをなくすことだったはずだよ。
なんで？政府の成果を改善してお金をもらうことに、何か問題でもあるの？
政府がみんなにやらせてることに、普通の人がお金を払う必要はない、って考え方だよ。海外の人で、税務署が持ってる情報を確認・更新するだけでいいことに驚いてる人が多いって聞いたことある。政府を恐れさせるマーケティングツールとして見てないからだね。
前に話したことあるけど、関連するからまた話すね。
2021年に2020年分の税金申告したら、数ヶ月後にIRSから大きな株取引を申告し忘れて8000ドル払えって手紙が来たんだ。7000ドルが税金で1000ドルが罰金。
7000ドルは別にいいんだけど、何でIRSが知ってるのに自分で申告しなきゃいけないの？ソフト買って紙の情報打ち込むなんて、IRSが持ってる情報と照合するだけなのに。修正が必要な場合のためにソフトがあるのはわかるけど、それ以外で必要とは思えないな。
ちなみに、IRSの人はすごく丁寧で助かったよ！変な話聞いてたけど、全然そんなことなかった。
政府が作った問題を解決するのがビジネスチャンスになるべきじゃないよ。そもそも政府がそんな問題を作らなきゃいいんだから。
うん、全くその通りだね。ちなみに、リポジトリにはこう書いてあるよ：”Direct Fileは、アメリカ合衆国内国歳入法（26 USC）を外部の指示や出版物なしで納税者が知っておくべき平易な質問として解釈します。納税者の回答は標準的な税務フォームに翻訳され、認可された公共利用のために利用可能なIRSの近代化されたe-File（MeF）APIに送信されます。”
だから理論的には今でも役立つんだけど、君が言うように簡単に変わっちゃう可能性があるね。
IRSが持ってる情報で税金請求書を送ってくれたら、会計士が足りない情報で調整するだけで済むのになぁ。送られてきた金額を払えば終わりでしょ。そしたら楽なのに。
税法には「EITC」みたいに、見ただけじゃ意味が分からない言葉がいっぱいあるんだよね。説明がないと一般人には絶対無理だよ。
＞IRSが取引を知っていて、私が税金を十分に払ってないと文句を言えるなら、それはIRSが既に私が送ってる情報を持っているということだ。あなたは、1099-Bフォームの情報だけで税金が決まるって勘違いしてるよ。IRSは今年の婚姻状況や、IRSに報告されてない控除や他の収入なんかを知らないんだ。全部あなたが申告しないと分からないんだよ。
米国外の人間として言うと、個人が会計士を雇う必要があるなんて、信じられない。私みたいな簡単な経済状況ならスウェーデンでは5分で申告できるし、両親の複雑なケースでも会計士はいらないくらい簡単だよ。TurboTaxとかIntuitとか、そういうのが米国の税金をややこしくしてるんだ。
このソースコードが法律のユニットテストになったら面白いよね。税法が変わる時はGitHubでコードも変わって、矛盾はテストで見つかる。裁判所の解釈も新しいテストになる。人間の判断はなくならないけど、政治の気まぐれも論理で表現できる。これは素晴らしいアイデアだね。
米国国内に住んでる身としては、政府に私の完璧な情報がない今の状況に満足してるよ。100ドル会計士に払って、税金でそれ以上の額を節約できる方が良いんだ。
それは難しいと思うなぁ。法律の解釈があるから、無理かもしれない。でも、そうなったら良いとは思うよ。法律とコードが、キーボードで意図を定義する点でどれだけ似てるか、よく考えるんだ。
そうだね、税金申告ロビーのために働く政治家や役人が、このソフトウェアを役に立たなくするような税法変更を入れる可能性は十分にあるよね。
＞政府が完璧な情報を持ってない。そう思ってるなら、そう言い聞かせてればいいんじゃない？（それがどうでもいいとしてもね）実際、W2をもらってるなら、IRSはもうそれを持ってるんだよ。
死にかけの船がオープンソースにするのは、このソフトウェアを修正して再販できるグループが、これをベースラインとして使うためだよ。TurboTaxが利益を出しつつ、 drastic changes（抜本的な変更）が必要な時に十分安い価格で提供できるかって話だよ。
税法ってあいまいなとこ結構あって、税務調査とか裁判でやっと決まるケースもあるんだよね。例えば、ソーラーパネル設置したとき、屋根修理費も税額控除になるかIRSのヘルプラインに聞いてもダメで、業者と意見が食い違ったんだ。結局、数年後の裁判で「ダメ」って決まって、業者の言うこと聞かなくてよかったと思ったよ。
税務ソフトってこういうのどう対応すんだろ？「監査保護」とかあるけど、どこまで見てくれるんだか。全部ユーザー任せにすんのもリスキーだよね。
あと、IRSの専門用語って分かりにくいこと多いんだよ。「スケジュール」ってフォームのことらしいけど、全然スケジュールっぽくないし！
W2収入だけならDirect Fileで楽勝かもね。でも個人事業とか一人LLC（単一メンバーLLC）とか、法人形態がちょっと複雑になると大変だよ。税金逃れしようと思えば、いくらでも面白いことできそうじゃない？（私はやんないけどね）
億万長者が信託とか慈善財団とか使ったら、どうなるか想像してみてよ。
税務署が把握してない情報もあるはずだよ。例えば、個人的な取引で損したこととかね。それが利益を相殺する可能性もあるんだ。
納税者の回答は標準的な税務フォームに変換されて、IRSのModernized e-File（MeF）APIってのに送られるんだって。このAPIはTurboTaxみたいな他のソフトも使ってるから、そう簡単にはなくなんないよ。
システム連携自体はそんなに難しくないんだ。
いやいや、APIなんて簡単に使えなくなることだってあるさ。APIを悪用されたり、「正規ライセンスのないソフト」がエラー起こしたりとかって言い訳でね。ライセンスってのは「APIを使う許可」のことね。
あと、APIを有料化する動きだってあるかも。「なんでこのサービス無料なんだ！？」ってね。法人化必須にして、商業アカウント作らせて、支払い方法登録させて…とか。
見てみろよ、別に本気じゃないのに、APIをなくす巧妙な手口が dozens も思いついたぜ。
税務署が「既婚か独身か世帯主か（確定申告ステータス）」とか、彼らに報告されてない控除や他の収入を知らないっていうけど、それって有料の税務準備業者にIRSが乗っ取られて、税務申告を不必要に複雑にされてるからじゃない？
IRSはみんなの税金トランスクリプト上のデータを持ってるんだから、それ見せて「これでOK」か「修正する」か選ばせるだけでいいはずなのに、わざわざ1099とかのデータを自分で手入力させて、税務署が持ってるのと同じか確かめるっていう無意味な「正直テスト」を課してるんだ。
Direct Fileこそ、IRSがデータ持ってるんだから、この機能をつけるべきだったよ。データを自動で入力させるのは効率的なんだから。
IRSのルールが変わるときは、見本になる実装と、たくさんのテストが必須になってほしいね。
そうだね、だから修正できるシステムがあるのは全然いいと思うよ。でも、一番いいのは「税務署から手紙が来て、それ見て問題なければサインして送り返す」っていうのがデフォルトになることなんだ。
ほとんどの人にとって、それなら10分くらいで終わるんじゃない？
それは「正直テスト」じゃないよ、アメリカの所得税システムが進化してきた結果なんだ。元々はIRSもデータがずっと少なくて、みんな紙で申告してたんだ。
例えば、ブローカーが1099でコスト根拠を報告するのを議会が義務付けたのは2008年になってからだよ。これはみんながキャピタルゲインを減らすためにコスト根拠を過大申告するのを減らすためだったんだ。
Biden政権下でIRSはW2とか1099のデータを公開しようとしたんだ。IRSのウェブサイトにログインすれば、IRSがあなたの名前で持ってるW2や1099をダウンロードできるよ。
反税活動家たちはこういう一歩一歩にずっと反対してきたんだ。税務申告が面倒じゃなくなれば、彼らの反税主張を買う人が減るからね。
IRSが彼ら悪質な税務準備業者に乗っ取られてるわけじゃない、議会が乗っ取られてるんだ。IRSは議会が明確に許可しないとデータで多くのことはできない。そして共和党が反税活動家と、反税活動家が税務準備会社と寝てるんだ。
Schedule Cで水道光熱費の何パーセントが控除できるか決めるときのunit testとか、顧客との食事中の会話が「実質的にビジネス関連の事項」だったか判断するunit testとか、どうやって書くつもり？
俺が言いたいのはさ、このプロジェクトの難しさって、相互運用性の部分じゃないってことだよ。
ほら、ほとんどの人にとっては本当に10分なんだってば！
もっとコメントを表示（1）
これってJavaじゃ普通なの？気になるコード見てみてよ
https://github.com/IRS-Public/direct-file/blob/9dd76a786ea69…
うん、政府の仕事でさ、誰にも読めないコード書いて一生食っていきたいならね。それか、超ワイドモニターを売ってる商売人ならそうかもね。
Javaでも他の言語でも、ああいう書き方見たことあるよ。もちろん、推奨されるやり方じゃないけどさ。
Spring Boot webflux 使ってる俺から言わせてもらうと、あれはかなりヤバいコードだな。あんなにネストしちゃダメ。リアクティブフローの外で atomic reference 使うとか、webflux の使い方わかってない証拠だよ。まぁ、webflux 自体が全然簡単じゃないし、開発者体験もクソだけどな。
確かにネストされてるけどさ、全体は1080pのモニターに収まるって！
読めなくてデバッグできない、ってのが、俺がソフトウェア見てきた中で、ずーっと好まれてきたやり方だな！
俺には完璧に読めるように見えるけどな。10年以上 Java の仕事してない俺でもね。具体的に何が問題なの？
長年Javaを触ってきたけど、あのコードを見たら目が痛くなったわ。たぶんリアクティブ（reactor.core.publisher.Mono）が原因だろうね。画面一つに収めようとしたのかな？チームリーダーだったら、もっとシンプルにするよう求めるけどな。
これって、C#のasync/awaitみたいに、自動生成のステートマシンがないとこうなっちゃうってことなの？
webfluxは全く使いやすくないし、開発者体験も最悪だよね。まあ、ほとんどのJavaフレームワークでそうだけど…。Java 8以降は素晴らしい言語だと思うのに、コミュニティは信じられないほど複雑なパターンを重ねてツールを作る傾向があるんだよな。
個人的には、12段階くらいのインデントと5層のネストで頭が変になりそうだけど、単に俺の脳みそが小さいだけなのかも。
仮想スレッドが出てきた今、新しいプロジェクトでWebFluxを使うのは考えにくいよね。
この視点は問題をうまく説明してるね。これ、ユニットテストがほぼできないよ（関数全体をテスト単位にしないと）。深くなればなるほど、それぞれのラムダ式が何してるのか分からなくなるんだ。
ウィンドウの概念を捨てて、テキストエディタをフルスクリーンで使うならまあいいけど。左右で差分表示する時は、もうご愁傷様だね。
同意だわ。実際にバックプレッシャーが必要ない限り（俺が見てきたほとんどのユースケースでは不要）、あれは単純なAPI呼び出しを難読化してるだけだよ。
ああ、そうだね。Micronautが今、ちょうどいい感じのスイートスポットって感じかな。
これ、JavaのReactive Programmingじゃん。操作が終わったら実行されるコールバックを返すやつ。Mono＜T＞っていう戻り値の型を見ればすぐわかるよ。
んー、まあね。よくあるパターンだけど、すごい手抜き実装だわ。ほとんど別クラスとか関数にリファクタリングできるし、そうすべきだろうね。でも、ほとんどのJava devは気にしないんじゃない？ダサいし Bad Practiceだけど、個人の好み次第でアリかも。動くしね。
そういえば LLMはこういうコードに対して、逆方向にやりすぎちゃうんだよ。些細な1行lambdaですら、全部関数とかクラスにバラバラにする。正直、君がリンクしたこのコードよりそっちの方がイラつくね。
まあね。正直、Reactiveにする必要ないかもだけど。
テストカバレッジ100%！
（指を後ろで交差させながらね）
おいおい、その調子だと数世紀後にはズームレベルが900%とかになって、読めたもんじゃなくなるぞ…
Javaはよくわかんないけど、.flatMap(…)って C#の .SelectMany(…)と同じっぽいね。これはMonadic Bindオペレーターとして有名。C#の Query Syntaxも、.SelectManyを繋げたのと同じ。Haskellの Do-notationにも似てる。
だから、プロジェクトのどっかに Monadicな Scalaコードがあるなら、これって Scalaで考えて Javaに翻訳した結果なのかなー、って思うわ。
Atomicsは変だけど、Reactorって、どうしても順次的な Blocking処理が必要になるときに、コード構造がぐちゃぐちゃになりがちなんだよね。
これ、Reactive Programmingをちゃんと理解してない開発者によくあるパターンだよ。Angularプロジェクトでも RxJSのせいで似たようなの見かけるし。
.onErrorResume か。Javaは嫌いだけど、これで On Error Resume Next の時代に戻れるなら、考え直すかもね。
Java以外の開発者には難しそうに見えるけど、俺が見てきた大半のクソ企業よりJava streams APIとかreactorライブラリの使い方が全然マシだよ。
HPとかHPEとかDXCで働いてたとき、社内“sso”認証アプリでバイト配列をbase64エンコードじゃなくて文字列結合してたの見たことあるぜ。
見た感じコールバック地獄っぽいな、Javaだけど。Async/awaitがあれば解決するのに、Javaだからなあ。
クソ違うね。でも俺も見たことあるよ、自称webscale性能を追い求める賢しらなtech leadが推奨するからな。そいつらは通常のblocking codeとの比較benchmarksはやらないんだ、自分の思い込みがバレるのが怖いからさ。んで、そいつらは別のとこ行って、残された奴らがそのhubrisの後始末をするハメになるんだ。
code以外にも、＼docs＼design
[0]の下には素晴らしいdesign documentsやnotesがいっぱいあるんだ。user flowsの詳細なprocess diagramsとかね（残念ながらzip filesに入ってるからonlineでは直接見れないけど、flow1.zipとflow2.zipを見てみて）。0: https://github.com/IRS-Public/direct-file/tree/main/docs/des…
もっとコメントを表示（2）
誰か興味あったら、repoはここで見つかるよ。https://github.com/IRS-Public/direct-file
これはserviceだよね。もしgovernment側のlisteningを何らかのideologueで止められたらどうなるの？
このforked versionが物理的に郵送するためのformsをprint outするようにならない限り、digital hostとcommunicateできないこのsoftwareを持っていてもuselessじゃん。
＞ Unless this forked version will then print out a bunch of forms for someone to physically mail in
まあそうだよ、これはessence税 return preparation softwareがずっとやってきたことの本質だ。end resultはform 1040（と必要と判断されるadditional forms）のboxesにfillするcompleted set of valuesで、それをelectronically fileするか、paperにwritten/printedしてat an office or by mailでreturnedできるんだ。
米国以外のcountriesではそうじゃないね。taxesやり始めてからprintoutなんて見たことないよ。
IRSは決まった形式でe-filingを受け付けてるから、それ自体は危険じゃないよ。e-filingと紙の申告の税務証明書見ても、提出方法に関わる項目以外、本質的な違いはないんだ。
e-filingをどうやって見るのか全然わかんないな。PDF送るの？ それともAPIにデータ送るの？ 巨大な政府機関としては、人間が見やすいように「他のと同じ」PDF形式を欲しがるのはわかるけど。
ファイルをコミットする代わりに、うっかりサブモジュールポインターとして新しいリポジトリ作っちゃった人なんていない？ https://github.com/IRS-Public/direct-file/commit/2f3ebd66932…
あと面白いのは、これUSのだからCC0を使えず、世界中のCC0とは別に、これはパブリックドメインだって明確にする必要があるってこと。
別の言い方すると、カリフォルニア州USに拠点があるクリエイティブ・コモンズは、国内最大のソフトウェア作者（政府）が使えるライセンスを出してないってことか。皮肉抜きに、その食い違いは気になるね。
カテゴリー間違いだよ。
パブリックドメインはライセンスじゃなくて、状態のこと。クリエイティブ・コモンズは世界的な組織で、特定の地域だけじゃない。クリエイティブ・コモンズには世界の法律を調和させる権限はないよ。https://creativecommons.org/public-domain/pdm/https://creativecommons.org/public-domain/cc0/
つまり、著作権を考えてみて。著作権者は好きなライセンスを適用できるし、新しいバージョンではいつでもライセンスを変えられる。パブリックドメインは著作権を明確に放棄することで、作者はどんなライセンスも強制できなくなるんだ（誰でも作品を持って行って自分のものだと宣言したり、ライセンスを適用したりできる）。PS: USでは、著作者人格権は著作権とは違って、著作権のように譲渡できないはずだよ。
できないんじゃなくて、パブリックドメインのものにライセンスを提供するのが無意味ってことだよ。あと大事なのは、これらの作品は誰かが宣言したからパブリックドメインになったんじゃなくて、単にUS政府が行った仕事だからってこと。著作権が自動なのと同じで、©マークを付けたときだけ適用されるわけじゃなく、あれは情報表示なだけだよ。
お気に入りの言葉＞「私たちは絵空事を政策の選択肢に変えたんだ。」もう誰もDirect Fileは不可能なんて真顔で言えないよ。復活させるには、選ばれたリーダーが違う選択をするだけでいいんだから。＜br＞でも一番悲しいのは、チームが解散しちゃったこと。彼らが届けようとしてた大きなインパクトを無視されたんだ。Direct Fileに関わった期間で一番誇りに思えるのは、あのチーム自身なんだ。彼らの使命への熱狂的な献身。常にちゃんとやろうとする気配り。お互いへの信頼と愛。
＞除外されたコード＜br＞Direct Fileの開発に使われた全てのソースコード、ドキュメント、メタデータがこのリポジトリに含まれてるわけじゃないんだって。具体的には、PIIとかFTIみたいな情報や国家安全保障システム向けコードは除外されてる。これらの制約のために、一部の機能は削除されたり書き直されたりしてるらしいよ。削除された部分がどんなものか、すごく気になるね。
あれはきっと、公開するリリース全部に付けてる定型的な注意書きだよ。何が除外されたか推測されないように、特定のリリースだけじゃなく全部に付けてるのかもね。
残念ながらこのプログラムは今の政権に潰されつつあるんだ。でもこのリポジトリは素晴らしいね。Scalaのファクトグラフは超 neat だし、それのチュートリアルもすごく丁寧に作られてる。開発に相当力を入れたのがわかるよ。
これに関わってたみんなは、最初のコードを書く前から、次に共和党が権力握ったら潰されるってわかってたんだろうね。それが起きる前に動くソフトをリリースできたのはすごい成果だよ。でも、税金関連のロビー団体が強すぎて腐敗してるから、誰もこれが続くだなんて思ってなかったはずだ。
君が正しいといいんだけどね。慣性の力ってのは両方向に働くんだ。もし今の政権が民主党であと4年続いてたら、Direct FileもAffordable Care Actみたいに十分に定着して、取り除くのがすごく難しくなってただろうね。ACAも完璧じゃなかったけど、共和党は何度も廃止を誓ったのに、いざ権力握るとできないみたいにさ。
君の言う通りならいいんだけど、今の政権はこれまでのところ、たくさんのプロジェクトや人生、役割、組織を破壊するのにほぼ限界がないみたいに見えるよ。そして野党も、基本的に彼らがやりたいことを邪魔されずにやらせてる。「小さいプラカード掲げて、しかめっ面する」のが「何かしてる」ことになるなら話は別だけど。
上院では、あらゆるものに対してフィリバスターを強行して、最大限の議事妨害を仕掛けることができる。ダックワース議員が提出した反トランス法案に対して、60票集められずにフィリバスターを破れなかったようにね。下院では、というか下院の外で、彼らのメディア戦略を今の10000%くらい良くして、Trumpについて毎日8回、様々なメディア環境で強力でバズるような、小気味良いメッセージを継続的に届けられるだろう。
