開発経済学における構造主義
経済学、とりわけ開発経済学の分野において、構造主義は1940年代〜1960年代の主流派であった。ここにおける構造主義とは、発展途上国の経済構造は先進国のそれとは異なるものであり、それゆえに経済格差が発生している、という考えである。南北問題などもこの経済構造の違いが原因で起こるとされた。
こうした構造主義では、先進国と発展途上国で適用すべき経済理論を使い分けなければならないとされたが、1960年代以降に主流派となる新古典派経済学によってこの考え方は否定されることとなる。構造主義にかわって主流派となった新古典派経済学では、先進国と同様に発展途上国でも経済市場のメカニズムは同じように機能する、という考えにもとづく自由主義的アプローチがなされた
この考え方は否定されることとなる
どのように否定されるの？
否定（というより「理論的にも実証的にも一般理論としては採用しない方向に主流が移った」）されたポイントは、だいたい次の筋道です。※構造主義にも多様な系譜（ラウル・プレビッシュ、ECLA/セパル、ヌルクセ、ローゼンシュタイン＝ロダン、ハーシュマン等）があるので、ここでは「1940–60年代の開発構造主義の中心的主張」に絞ります。
構造主義は、途上国には
これに対し新古典派（およびその後継の「新しい開発経済学」）は、
つまり否定の中心は、「途上国では市場メカニズムが根本的に違う／機能しない」という強い断絶命題の方です。
（“市場の失敗”は認めても、それは一般理論の内部で扱う、という方向に寄った。）
構造主義と結びつきやすかった政策は、関税・数量規制・為替統制・国営企業・計画などを通じた 輸入代替工業化（ISI） です。理屈は「途上国は一次産品依存で交易条件が悪化しやすいから、工業化を保護して進めるべき」。
これが否定された代表的経路は、政策評価（経験則）です。
一方で、同時期に 輸出志向（東アジアNIEsなど） が相対的に高成長を示し、「保護と統制が成長の必須条件」という含意が説得力を失っていきました。
（もちろん東アジアも産業政策はありましたが、“一律の内向き保護”ではなく、輸出規律や競争導入があった点が対比されがちです。）
構造主義の重要論点の一つが、いわゆる プレビッシュ＝シンガー仮説（一次産品の交易条件が長期的に悪化しやすい）です。
これ自体は現在でも研究対象ですが、主流派の扱いは概ねこう変わりました。
結果として、「南北格差の根本原因＝交易条件悪化」という強い位置づけは相対化されました。
1960年代以降の主流派化は、内容だけでなく研究作法（方法論）の転換でもあります。
その結果、構造主義的に語られていた現象（失業、二重構造、低生産性、外貨制約など）が、
新古典派が否定したのは主に、
で、逆に言うと「途上国に構造的問題がある」こと自体は、現在でも多くの経済学者は否定していません。違いは、それを一般理論（市場＋制度＋市場の失敗）で扱うか、途上国固有の別体系で扱うか、そして政策が「一律の保護主義」になりがちかどうか、です。
必要なら、あなたが想定している「構造主義」が プレビッシュ＝ECLA型なのか、ビッグプッシュ/不均衡成長なのか、構造インフレなのかで、どの論点がどう批判されたか（論争史・代表的論文）をもう少し具体的に整理できます。どの系譜の構造主義を指していますか？
つまり構造というマクロレベルの違いはあるけど、事態を改善するなら構造を変えるよりも、ミクロレベルの仕組みや問題を変えた方が現実的だとわかってきたということ？
大筋は近いですが、その言い方だと少し誤解を招きます。主流派が移ったポイントは「マクロの構造はあるが、マクロを捨ててミクロだけにした」というより、
以下、あなたの言い方に対応させて整理します。
「現実的」というより、新古典派以降は
ただし、ここでいう「ミクロを変える」は「小さなことだけやる」ではなく、制度・政策でインセンティブ構造を変えるという意味で、場合によってはかなり大きな改革（貿易自由化、国営企業改革、金融改革、土地制度改革など）も含みます。
構造主義の核にある「産業構造転換（農業→工業→サービス）」「生産性の異なる部門間の労働移動」「外貨制約」みたいな論点は、今も重要です。
否定（弱体化）されたのは主に、
の部分です。
つまり「構造を変える必要はない」ではなく、
“構造転換は大事だが、何でも保護・統制でやるのが正しいとは限らない。どの失敗をどう補うかを精密に”に近いです。
主流派の変化は、「マクロかミクロか」より
という“研究作法”の転換が大きいです。
その結果として、「構造」を政策ターゲットにする場合でも、
「マクロな構造差は認めつつも、途上国を“別の経済学”で扱うのではなく、一般理論の枠内で市場の失敗や制度の問題として分解し、検証可能な形で政策を設計する方向に主流が移った」
が近いです。
どの「構造主義」を念頭に置いていますか（ECLA/プレビッシュ型の交易条件・ISI、ビッグプッシュ、不均衡成長、構造インフレなど）？それによって「ミクロ化」で置き換えられた具体的メカニズム（為替の過大評価、金融抑圧、政治的レントなど）の対応関係をもっとピンポイントに示せます。
ありがとう。構造主義については理解できた。 次に、私がやりたいことを話そう。私は組織のパフォーマンスと従業員体験は構造によると思っている。コンウェイの法則もそうだよね。つまり構造次第で、自ずとパフォーマンスと従業員体験の限界が決まってくるのではないかと。 それゆえ、構造をどうつくるかが重要だと考えている。たとえば teams や slack などのチャットしか使ってなければ、チャットの構造で実現できるところまでしか行けない。チャットではなくノートや wiki やチケットに頼れば、チャットでは行けない水準に行けるだろう。組織についても、階層的な組織では限界がある。階層を崩した組織をつくることで、階層を超えたパフォーマンスと体験が得られるはずだ。 この考え方の妥当性を知りたくて、構造主義という歴史について調べていたのです。
あなたの問題意識（「成果や体験の上限は“構造”でかなり決まる」「だから構造設計がレバレッジになる」）は、十分に妥当です。しかも開発経済学の構造主義がその後“否定”された経緯は、むしろあなたの議論を強くするヒントにもなります。ポイントは次です。
組織論・社会科学では昔から、構造が行動を誘導し、結果（パフォーマンス）と当事者の経験（従業員体験）を系統的に制約するという見方があります。
あなたの例で言う「チャット中心だとチャットの“構造”が上限になる」も同型で、媒体が“何が可視化され、何が記憶され、何が合意として固定されるか”を決めるので、アウトカムに上限が出ます。
開発経済学で構造主義が主流でなくなったのは、「構造が重要じゃない」からではなく、主に次の点が弱かったからでした：
これを組織に移すと、あなたの主張を強くするには
「階層が悪い／チャットが悪い」と一般論で終えるのでなく、
というメカニズム分解が鍵になります。これはあなたの考えを否定するどころか、「設計論」に変換するための型です。
階層には限界があります（遅い、情報が歪む、現場知の吸い上げが弱い、承認待ちが発生する）。一方で、階層を崩すと別の上限も生まれます（意思決定の収束、責任の所在、優先順位付け、衝突解決、標準化）。
なので実務的には「階層 vs フラット」ではなく、たとえば：
のように、階層の機能を別の“構造”で代替できるかが勝負になります。
妥当性を確かめるなら、構造を次の3層に分けて観察すると議論が締まります。
構造変更（例：チャット→チケット化、RFC導入、権限移譲、チームトポロジー変更）を入れた前後で、これらのボトルネック指標がどう動くかを見ると、「構造が上限を決める」がかなり実証的に語れます。
あなたがやろうとしているのは、開発経済学で言えば「構造が大事」という直感を捨てることではなく、構造→メカニズム→介入点→測定まで落として、一般化可能な設計原理にすることだと思います。
もしよければ、次のどれを主戦場にしたいですか？
1) ツール/ドキュメント体系（チャット中心からの脱却）
2) 意思決定（階層の代替設計）
3) チーム境界（Conway/Team Topologies的な設計）
選んでもらえれば、その領域で「構造が上限を作るメカニズム」と「設計の選択肢」「失敗パターン」をもう少し具体化して整理します。
設計とは構造をつくることだと思ってましたが、メカニズムも設計に含まれるのですね。 でも IT の開発だとメカニズムはないですよね、構造だけですよね。アーキテクチャもそうですし、 人間を相手にした組織だと、より複雑になるのでメカニズムも必要ということですかね。
「メカニズム」はあります。むしろ IT開発（ソフトウェア/プロセス）こそメカニズムの塊で、あなたが「構造」と呼んでいるものの多くは、実体としては「構造＋それが動く仕組み（ルール/プロトコル/インセンティブ/制約）」のセットになっています。
整理すると見通しがよくなります。
構造は「形」、メカニズムは「形が狙った通りに機能するためのルールとフィードバック」と考えると近いです。
たとえばマイクロサービスは「分割」という構造だけでなく、
みたいな“作動条件”が揃って初めて性能が出ます。分割（構造）だけ真似すると壊れますよね。これがメカニズムです。
Scrum/Kanbanも「役割とイベント」という構造に見えますが本体は、
という制御の仕組みです。
ソフトウェアでもメカニズムは必要ですが、組織ではさらに
ので、構造だけ置いても期待通りに動かないことが増えます。だから、組織設計ではメカニズムを明示的に作る必要性が高い、という理解で合っています。
例：
「チャット中心」でも、構造だけではなく暗黙のメカニズムが動いています：
これを改善するのが、wiki/チケット/RFC等の構造変更であり、同時に
もしよければ、あなたが今一番変えたい対象はどれですか？
1) 情報の流通（chat→docs/ticketsへの移行）
2) 意思決定（階層の代替：委譲・合意形成・衝突解決）
3) チーム境界（Conway/依存関係の再設計）
選んでもらえれば、「構造」と「メカニズム」を分けて、具体的に何を設計すれば上限が上がるかをテンプレ化して提案します。
最後に、ここまでの議論を私の質問とそこから得られた洞察を軸に、10行以内で整理して。
1) 開発経済学の構造主義は「途上国は先進国と経済構造が違うので別の理論・政策が必要」と主張した。
2) その後の主流は「構造の違い自体は認めつつ、一般理論の枠内で“どの市場がなぜ失敗するか”に分解して説明・検証する」へ移った。
3) 否定された核心は「断絶（途上国専用理論が必要）」「一括処方箋（保護・統制・計画が基本戦略）」の強さだった。
4) あなたの関心は、組織においても「構造がパフォーマンスと従業員体験の上限を決める」という構造主義的直感にある（Conwayの法則等）。
5) その妥当性は高いが、強い主張にするには「構造→結果」をメカニズム（情報流・意思決定・調整コスト等）で因果分解する必要がある。
6) 「構造を変える」ことは重要だが、単にフラット化／ツール変更ではなく、狙い通りに動かす作動条件が要る。
7) ここでいう作動条件が「メカニズム」（ルール、プロトコル、フィードバック、制約、例外処理）。
8) IT開発も例外ではなく、アーキテクチャやプロセスは構造＋メカニズム（CI/CD、レビュー、互換性規約、可観測性など）のセットで成立している。
9) 組織は人間要因で逸脱しやすいので、構造だけよりもメカニズムを明示設計する必要性がより高い。
10) 結論：構造が上限を作るという直感を活かす鍵は、「構造＋メカニズム＋測定（ボトルネック指標）」まで落として設計論にすること。