社内プロジェクトのガチ縛りでマジ詰んでる

author: Excell21782025-09-14T09:36:26Z

今勤めてる会社でやってるプロジェクトが社内向けの管理ツールで、非プログラマの社員の作業を楽にするやつなんだが。

問題はこれを作る開発チームが使う技術をほとんど決められないこと。チームリードが事実上 vanilla JS（純粋なJavaScript）しか使わせないって決めてて、HTMXもStimulusJSもその他の便利系ツール全部禁止。バックエンドはCodeIgniter 4だな。

HTMXダメって理由が「今あんまり広まってないし、将来ブラウザの互換性で問題が出るかも」って主張なんだけど、正直それってどうなんだよって感じ。

さらに追い打ちで、全部のJavaScriptを単一ファイルに書けと。import/exportやきちんと関心分離するのは禁止。理由は「全部1つのファイルにまとめた方がデバッグしやすい」だそうだ。いやいやマジかよと。

正直途方に暮れてて、これが将来プロジェクトの失敗につながるんじゃないかと心配してる。俺はチーム入ってから色々情報源から勉強してJSスキル伸ばしてきたし今も勉強中だけど、うちのチームはどっちかって言うとバックエンド寄りで、素のJSを単一ファイルに押し込められるのはしんどすぎる。

で、ひとつ案としては、少なくともその単一ファイル内でクラス構成にして、バックエンドの各ビューごとに1つクラス割り当てて、各クラスに固有のメソッドを持たせるとか考えてる。多少はマシになるはず。

みんなはどう思う？似たような縛りで対応したことある奴いる？この状況を少しでもマシにするためのアドバイスとかあったら教えてくれ。よろしく頼む。

1firedogo2025-09-14T09:41:19Z

制約はキツいけど、ライブラリ増やさずにちゃんと合理化はできるぞ。
ランタイムは単一ファイル、リポジトリは複数ファイルで管理しろ。
src/ を機能ごとに分けて、超シンプルなビルドで1つの app.js を吐く。
たとえば cat src/**/*.js > app.js やランタイム依存ゼロの esbuild を使う、みたいな感じ。
リードには単一ファイルを渡して、君はモジュール化されたコードとソースマップをちゃんと保持するんだな。

グローバル汚染は避けてネームスペース＋IIFEでまとめる。
例: window.App = {}; (function(App){ /* feature A */ })(window.App); 各機能は独自クロージャ内にして App に登録。

<body> に data-page="invoices" を付けて、app.js 内でコントローラをマップして { invoices:initInvoices, reports:initReports } みたいに今のページだけ実行する。
イベントは document に対してイベントごとに1つのリスナーだけ付けて、e.target.closest(‘[data-action=x]’) でルーティングする。散在するリスナーはマジでやめろ。

ユーティリティは最小限に: qs/qsa、on()、ajax(fetch)、pub/sub。
当たりは100〜200行で収める。
フレームワークは使わず、コピペを減らす設計にしろ。
‘use strict’ 入れて ESLint回して、各コントローラの周りは try{init()}catch(e){App.log(e)} にしておけ。
ファイル冒頭に目次(TOC)を置いて「単一ファイル」でもナビできるようにするのが鉄板。VS Code の //#region ブロックは折りたたみで便利。

ビルド工程が禁止されてるなら、それでも同じ構造を保て。セクションを明確に分けて1つの App オブジェクトにまとめればOK。あなたの「ビューごとのクラス」案も fits するし、単に App.controllers に登録すれば終わりだな。
2_SnackOverflow_2025-09-14T13:55:58Z

単一ファイルって発想はやりすぎだろ。
メリット見えないし欠点ばっかだ。
バニラでUIロジックを再利用したいなら web components の方がまだマシだと思う。
3HarryBolsac2025-09-14T13:33:21Z

提案するならPoC作って見せつけるのが一番効くぞ。
チームリードの間違いは実演でしか壊せない。
特に問題になってるのが『JSを単一ファイルにまとめる』って点なら、JSモジュール使いつつ基本機能を保つやり方をデモしてやれ。
古いブラウザで動くことを示せば説得力増すし、そうでなきゃ babel とかポリフィルが必要になるって話も合わせて出せ。デバッグワークフローの比較も実務例で見せるといい。
どうしてもうまくいかないなら、正直に転職も選択肢に入れとけ。
4dunkelziffer422025-09-14T15:42:29Z

制約いくつか変だけど回避策はある。

HTMLは素直にフルページリロードにしてしまえ。HTMX/Unpolyが使えないなら速度面で不利にはなるが、2025年でもSSRで十分戦える。

CSSはSCSSに頼らなくていい。今はCSS変数やネストでかなりいけるし、BEMを使えば管理しやすい。

JSはStimulusが使えなくても、WebComponentsをネイティブで使うか、下の手法みたいな進め方で行ける: https://makandracards.com/makandra/503891-unobtrusive-javascript-helper-progressively-enhance

要はツールが制限されてても実現方法はあるってことだな。
5union4breakfast2025-09-14T09:48:35Z

それ意味わかんないんだけど。HTMXが互換性の問題を起こすってどういう話？あれはただのライブラリだろ。全部同じファイルに突っ込んでスパゲッティになればデバッグが楽になるって、いつの伝説だよ。

CMS作ってるならチームリードに Astro を使えるか聞いてみたら？

ところで、チームリードって技術者なの？どうやってリードになったのか気になるわ。
6csg792025-09-14T15:05:04Z

HtmxはただのJavaScriptだぞ。
7New_Dimension34612025-09-14T15:57:27Z

多分チームリードは古典的なアーキテクチャを好んでるんだよ。PHPのMVCバックエンド＋薄いバニラJSってスタックは長年使われてて、速くて堅牢だから放棄する理由を見つけにくい。君が現代JSにFOMO感じてるだけの可能性もある。

アーキテクチャを混ぜるのは経験がないと危険だ。失敗すると長期的な問題になるのを俺も見てきた。もし変えたいなら、慎重に計画して動くこと、そして動くプロトタイプを示すことが必須だな。
8michaelbelgium2025-09-14T16:36:56Z

HtmxはHTML属性って認識でいいよ。
9maqisha2025-09-14T20:08:55Z

PM、大丈夫か？って言いたくなる気持ちは分かる。
10danielkov2025-09-14T20:13:35Z

ある点ではチームリードの言うことも分かる。多分最近コーディング始めたばかりで流行りのフレームワークに飛びつきたがってるだけだと思う。君のチームはバックエンド寄りで、学習コストを最小にして成果を出したいはず。

HTMX導入で何がどう改善するのか、根拠を示してないのは致命的だ。まずこれに答えろ: 解決したい問題は何か？なぜ今それを解決する必要があるのか？君の提案はそれをどう解決するのか？これをちゃんと説明できないと議論は通らないぞ。
11thekwoka2025-09-15T04:55:48Z

つまり単一ファイルの中で自前でHTMX/Alpineみたいなの作ればいいって話か。要するに軽量に自前実装しろってことだな。
12MatsSvensson2025-09-14T16:52:46Z

理想論に聞こえるけど、割と現実的だな。簡単にできるし後々レガシー地獄になるのを防げる。

5〜10年後に変な依存とカスタムタグだらけで誰も読めないコードになるより、シンプルにしておく方がマシだ。引き継ぎ時に時代遅れのフレームワークや改変されたJS/CSS/HTMLが混在してるのが一番最悪。

たとえばこんなタグが混ざってたら将来誰も理解できないだろ:

<blark flisp-cnt-brl="11.5.4.1" cn-djenja="flip22" styjl="BLUE">{{{cnt}}}</blark>

マジでやめてほしい。
13jon23d2025-09-14T13:21:01Z

リードと信頼関係築けるならそれが一番だ。段階的に設計パターン入れてドキュメント作って議論して提案するか、全部リードのアイデアっぽく見せかけて導入するか、どっちか考えろ。
14alien3d2025-09-14T11:00:26Z

うちはC#でフロントはバニラ＋最新のJS機能使ってる。axios と事前ロードの関数クラスや DTO クラス使えばフロントアプリは作りやすいよ。CI周りはアドバイスできない。Laravel と普通の PHP しか知らんからな。