地方のレガシーな開発環境にTypeScriptを導入したら失敗した話

こんにちは。@takokkeです。
私は大学に通う片手間で、地方の中小企業向けのコンサル会社で、プログラマーをやっています。
今回は、kintoneアプリのJavaScriptカスタマイズにTypeScriptを導入したけど、現場とのギャップで苦戦したという体験談を共有します。

🔧 きっかけ：保守性を上げたかった

当初、kintoneアプリのJavaScriptカスタマイズを行っていたのですが、以下のような課題がありました。

そこで、保守性を高めるためにTypeScript導入を決意。

従来はjQueryなどをCDNから読み込んでいましたが、これをnpmで管理する形に変更。依存管理もスッキリ。

kintoneには単一ファイルしか添付できないため、Webpackでバンドルして1ファイルに出力。モジュール分割しながら開発できるようにしました。

チームで開発していたので、GitHubでコードを管理。PRベースでレビューする体制も目指しました。

kintoneアプリのフィールド構成を型定義として自動生成できる kintone-dts-gen を導入。
これにより、実際のアプリ構成とコードの型定義を同期しやすくなり、手作業で型を書く手間を省けるようになりました。

お客様はkintoneのフィールド（カラム）を自由に変更できるものと考えており、「ラベルをちょっと変える」「項目を並び替える」ことが日常茶飯事。

ですが、型を定義してしまうと、変更がソースコードに波及して修正に時間がかかる。

「え、そんなに手間かかるの？」
という温度差がありました。

地方の中小企業ということもあり、TS経験者ゼロ。

といった声が…。
GitHub上にソースを公開しても、そもそもgitを使う文化がないため、誰も見てくれませんでした。

誰でも直感的に扱えるようにしたら、現場でも使ってもらえるようになりました。

TypeScriptやモダンな開発環境は確かに便利です。
ただ、それを受け入れられる文化や体制が整っていなければ逆効果になることもあります。

現場を変えるのも大事ですが、
「今の現場にフィットする形を探る」ことも同じくらい大切だと学びました。

対象ユーザー（運用者）との温度感を確認する
日頃からナレッジ共有の文化を育て、「この人の資料なら読んでみよう」と思ってもらえる関係を作る
X(旧ツイッター)とかによくいる AI驚き屋のような投稿をみたいと思いますか？ ツールや仕様をただ説明するだけでなく、「親しみやすい資料」「実際のトラブルを例にしたTips」「読んでる人のキャリア不安を煽らない、より実用的で建設的な内容など」、読みたくなる工夫が大切です。
フィールド変更時のCIチェックなど運用を作る覚悟を持つ
kintoneのようにノーコード側が自由に編集できる環境では、コードと構成のズレをどう検知・反映するかが重要。
型生成ツールや、レビューのフローまで含めた仕組み作りをまずは手動でもいいので作ることが必要です。

以上、少しでも誰かの判断材料になれば幸いです！
ご意見・フィードバックも歓迎です🙏

🧠 made with gpt-4o