地方のレガシーな開発環境にTypeScriptを導入したら失敗した話
こんにちは。@takokkeです。
私は大学に通う片手間で、地方の中小企業向けのコンサル会社で、プログラマーをやっています。
今回は、kintoneアプリのJavaScriptカスタマイズにTypeScriptを導入したけど、現場とのギャップで苦戦したという体験談を共有します。
🔧 きっかけ：保守性を上げたかった
当初、kintoneアプリのJavaScriptカスタマイズを行っていたのですが、以下のような課題がありました。
- kintone上で作った、本番環境とテスト環境で、フィールドコードが異なると目視で探さないといけない
- コードの品質にばらつきがある ベンダーに頼むと
varなど古い文法を使ってきたり、変数名が日本語だったりする - 誤字や型のミスがランタイムでしか気づけない
そこで、保守性を高めるためにTypeScript導入を決意。
🛠️ やったこと
1. CDNからnpm管理へ
従来はjQueryなどをCDNから読み込んでいましたが、これをnpmで管理する形に変更。依存管理もスッキリ。
2. Webpackでバンドル
kintoneには単一ファイルしか添付できないため、Webpackでバンドルして1ファイルに出力。モジュール分割しながら開発できるようにしました。
3. GitHubでソース管理
チームで開発していたので、GitHubでコードを管理。PRベースでレビューする体制も目指しました。
4. kintone-dts-genでアプリのフィールド情報をシステマティックに検知
kintoneアプリのフィールド構成を型定義として自動生成できる kintone-dts-gen を導入。
これにより、実際のアプリ構成とコードの型定義を同期しやすくなり、手作業で型を書く手間を省けるようになりました。
😨 しかし、現場では…
1. フィールド名変更に対応できない
お客様はkintoneのフィールド（カラム）を自由に変更できるものと考えており、「ラベルをちょっと変える」「項目を並び替える」ことが日常茶飯事。
ですが、型を定義してしまうと、変更がソースコードに波及して修正に時間がかかる。
「え、そんなに手間かかるの？」
という温度差がありました。
2. 現場にTypeScriptを理解する人がいない
地方の中小企業ということもあり、TS経験者ゼロ。
- 「トランスパイル？なにそれ？」
- 「minifyされたJSコード、何書いてあるのか全くわからん」
といった声が…。
GitHub上にソースを公開しても、そもそもgitを使う文化がないため、誰も見てくれませんでした。
🧯 対策：TypeScriptをやめた
- 結局、TypeScript＋Webpack構成をやめて、元の素JS（JavaScript）に戻しました。
- 代わりに、バージョン管理アプリをkintone内に自作。
- ファイルはそこに手動添付＆マージする運用に変更。
誰でも直感的に扱えるようにしたら、現場でも使ってもらえるようになりました。
💡 まとめ：最適な技術は「現場が運用できるもの」
TypeScriptやモダンな開発環境は確かに便利です。
ただ、それを受け入れられる文化や体制が整っていなければ逆効果になることもあります。
現場を変えるのも大事ですが、
「今の現場にフィットする形を探る」ことも同じくらい大切だと学びました。
📌 もしこれからTS導入を検討するなら
- 対象ユーザー（運用者）との温度感を確認する
-
日頃からナレッジ共有の文化を育て、「この人の資料なら読んでみよう」と思ってもらえる関係を作る
X(旧ツイッター)とかによくいる AI驚き屋のような投稿をみたいと思いますか？ ツールや仕様をただ説明するだけでなく、「親しみやすい資料」「実際のトラブルを例にしたTips」「読んでる人のキャリア不安を煽らない、より実用的で建設的な内容など」、読みたくなる工夫が大切です。 -
フィールド変更時のCIチェックなど運用を作る覚悟を持つ
kintoneのようにノーコード側が自由に編集できる環境では、コードと構成のズレをどう検知・反映するかが重要。
型生成ツールや、レビューのフローまで含めた仕組み作りをまずは手動でもいいので作ることが必要です。
以上、少しでも誰かの判断材料になれば幸いです！
ご意見・フィードバックも歓迎です🙏
🧠 made with gpt-4o