心を込めて、全文、タイピングしました
しばらく、要求から設計書を AI に生成させる試みをしていました。作成した設計書は、GitHub のプロダクションコードのリポジトリで管理されるため、そのまま実装のインプットとして使えます。
その過程で、タイトルのことに思い至りました。なぜ同じメンタルモデルを使うべきでないかというと、これら2つの行為は、収束と発散の方向が逆だから（正確には、収束と発散のうち、力点を置く割合が大きく違うから）、です。具体的に述べます。
プログラミングは、自然言語で記載されたなんらかの実現したい仕様を、プログラミング言語を用いて、実現するよう記述していく行為と考えられます。この行為は、システムの言葉への変換という過程を経たのち、期待通りの動きになるようロジックが修正されていきます。AI によるプログラミングでは、プロンプトやコンテキストを調整させながら、期待する振る舞いに近づけていくという意味で、これらは収束という方向に力点が置かれているように感じます。コードレビューで指摘される内容についても、理想の形に収束させるための指摘というものがよくあるかと思います。
一方で、設計書の場合は、最終的な成果物については、何らかのドキュメントに収束されるものの、その過程で行われる（行うべき）行為は、どちらかといえば、発散だと考えます。要求をシステムで実現するために、アプリケーションとして、データベースとして、ネットワークとして、観点を出し切り、それぞれの懸念事項を詰め、意思決定マトリクスを利用して方針を決定する。あるいは、プロダクトマネージャー / デザイナー / エンジニア / カスタマーサポートといった各種ロールの側面から、または QCD の観点から、トレードオフを考慮した上で、意思決定を行う。ここで行っているのは、あらゆる選択肢を出し切った上で、方針を決定し、合意することだと考えます。そのときの考え方は、どちらかといえば発散であり、早いうちかの収束は、後工程での考慮漏れの原因になります。設計レビューの指摘は、漏れている観点が挙げられることを期待される面があり、これも発散と捉えられると思います。
「発表資料を作るときにいきなりパワポを立ち上げるな」という言葉があります。まず書く内容や展開を書き出す（発散）過程から始まり、アウトラインなど詰まった段階で、パワポに落としていく（収束）ものであり、これも似た話だと思いました。