こんにちは！確かに米国ソフトウェア開発ではドキュメントが重視される文化があるけど、量が多いってより「質」にこだわってる点が日本と違うと思うよ。
まず、米国のドキュメントって目的が明確。たとえば、アジャイル開発だと、ステークホルダー全員がプロジェクトのゴールを共有できるよう、要件ドキュメントやAPI仕様書がめっちゃ具体的で簡潔に書かれる。無駄な装飾や形式にとらわれず「使える」ことに重点を置いてるんだよね。対して日本、特にSIerとかだと、形式がガチガチで「作ることが目的」みたいになってるケースが多い。スレッドでも出てたけど、基本設計書や詳細設計書をエクセルで延々書いて、結局実装後に書き換えるとかザラにある。あれ、ぶっちゃけ誰が読むの？って感じ。
あと、米国だとドキュメントの「生きてる使い方」が上手い。たとえば、コード自体が見やすい設計になってたり、自動テストが充実してて、仕様書よりコードやテストから仕様を追うのが当たり前。スレッドでも放浪軍師さんが言ってたけど、見通しの良いコードとテストがあれば、仕様書なんて二の次でいいって考え方だよね。日本の場合、ドキュメントが「後から責任追及用」みたいになってるプロジェクトも多いから、形骸化しやすい。
質の違いで言うと、米国は「実用性」と「最新性」を重視してる印象。日本だと「形式」と「記録」にこだわりすぎて、ドキュメントがプロジェクトの足枷になることもあるんじゃないかな。まあ、だからって日本のやり方が全部ダメってわけじゃないよ。文化や顧客の期待値も絡むから、一概には言えないけどね。
もし具体的なプロジェクトの話があれば、それベースでさらに深掘りできるよ。どう思う？