「kintoneを任せていた社員が、辞めてしまいました」
こういう相談は、決して珍しいものではありません。
・社内で唯一システムを触れた人がいなくなる
・アプリの中身は誰にも分からない
・不具合が出ても、直せる人がいない
多くの経営者は、ここで「代わりの人材をどう確保するか」を考えます。
ただ、その前に考えるべきことがあります。
なぜkintone担当者は、辞めたのか？
私はSESのエンジニアとして、社内でkintoneの開発と改修を一任される立場にいました。
今回は支援する側ではなく、任される側から見えていた景色を書きます。
「一任される側」が、実際に感じていたこと
kintoneを任されるというのは、傍から見れば「頼られている」状態です。
実際、私も最初はそう受け取っていました。
自分で作ったアプリが現場で使われ、KPIの数字が改善していく。 やりがいはありました。
ただ、しばらくすると別の感覚が出てきます。
誰にも相談できない
技術的に詰まったとき、社内に聞ける人がいません。
- kintoneのJavaScriptカスタマイズで動作が想定通りにならない
- API連携でエラーが出る
こういう時、社内の誰かに「これどう思う」と聞ける相手がいないのは、思っている以上に消耗します。
AIを活用したり調べたりすれば大抵のことは解決します。
ただ、「これで合っているのか」を確認できる相手がいない状態が続くと、判断のたびに小さな不安が積み重なっていきます。
内製化の壁「あの人しか分からない」は望んで作ったわけではない
属人化という言葉には、担当者が情報を抱え込んでいるような響きがあります。
実際は逆のことの方が多いはず。
- 引き継ごうにも、引き継ぐ相手がいない
- マニュアルを作る時間があるなら、目の前の改修依頼を片付けなければならない
- 「他の人にも触れるようにしたい」と思っていても、優先順位が上がらない
私も新入社員向けの研修資料を作ったことがあります。
ただ、それは業務の合間に、自分で必要性を感じて作ったものでした。
会社から指示されたわけでも、工数として認められていたわけでもありません。
成果が見えにくい
業務改善の成果は、数字にはなります。
私が担当したプロジェクトでも、kintoneアプリの改修で1時間あたりの架電数が21.3件から24.2件に改善しました。
ただ、この数字が「誰の成果か」は、社内では意外と共有されません。
現場からすれば、システムが使いやすくなったのは当たり前のことです。
経営サイドから見るとKPIが改善したのは現場が頑張ったからに見えます。
作った本人だけが、その間に何を検討して何を捨てたかを知っています。
経営者が見落としている、担当者の3つの負担
技術的な難しさは、実は一番の負担ではありません。
それ以外の3つが、じわじわと効いてきます。
1. 承認の負担
- 新しいプラグインを1つ入れたい
- 外部サービスと連携したい
- アカウント数を増やしたい
このような依頼を受けて判断するたびに、社内で説明し決裁を取る必要があります。
技術的には5分で終わる作業でも、承認に2週間かかることがあります。
しかもITに詳しくない相手に、必要性を一から説明しなければなりません。
この説明コストは、担当者にとって開発そのものより重い負担になります。
2. 評価の負担
業務改善は、うまくいくと「何も起きていない」状態になります。
トラブルが減り、作業がスムーズになる。
つまり、成果が出るほど目立たなくなります。
一方、システムが止まった時だけは全員が気づきます。
褒められることは少なく、責められる可能性だけがある。
この非対称性は、続けるうちに地味ですが効いてくるんです。
3. 孤立の負担
社内に同じ仕事をしている人、いないんだよな。
相談相手がいないだけでなく、大変さを共有できる相手もいません。
「今週この処理を自動化して、月20時間浮いた」という話を、誰にもできない。
技術者にとって、この孤立は想像以上にこたえます。
辞める前に、必ずサインが出ている
振り返ると、限界が近づいている担当者には共通した変化があります。
- 新しい提案をしなくなる（改善案を出さず、依頼された改修だけをこなすようになる）
- 「これは仕様です」と言うことが増える（説明する労力を惜しむようになる）
- 勉強会や情報収集をやめる（今の環境で使う技術以外に興味を示さなくなる）
いずれも、表面上は「落ち着いて仕事をしている」ように見えます。
むしろ以前より業務が安定して見えるため、経営者からは問題がないように映ります。
辞めそうな雰囲気を察することができないのが非常に厄介です。
担当者が辞めてしまった今、まずやるべきこと
すでに辞めてしまった場合の対応です。 優先順位をつけて、上から順に手をつけてください。
動いている仕組みを止めない
まず、現在動いているアプリと自動処理の一覧を作ります。
特に注意すべきは、定期実行されている処理です。
タスクスケジューラーで動いている連携、期日で走る通知、月末に実行される集計。
これらは誰も触っていなくても動き続けるため、壊れるまで存在を忘れられます。
外部との接続点を洗い出す
APIキーやアカウント情報が、退職者の個人アカウントに紐づいていないかを確認します。
ここが最も危険です。
退職処理でアカウントを削除した瞬間に、連携が全部止まるケースがあります。
優先度をつけて諦める
すべてを元通りにしようとしないことです。
実際には、使われていないアプリが必ずあります。
作ったものの定着しなかった機能、一時的な用途で作ったまま残っているもの。
この機会に、本当に必要なものだけを残す判断をする方が、結果的に早く立て直せます。
辞められない会社にするために
予防の観点でやることは、これ一択です。
担当者を1人にしない
ただ、これは「もう1人採用する」という意味ではありません。
中小企業でIT人材を2人確保するのは、現実的ではないからです。
そうではなく、触れる範囲を分けるという考え方です。
- 全部を作れる人は1人でいい
- ただし、アプリの設定を変えられる人が、もう1人いる状態を作る
- 何がどこで動いているかを把握している人が、経営側に1人いる
3つ目が特に重要です。
経営者自身が「うちのkintoneで何が動いているか」を大まかに把握しているだけで、担当者の孤立感はかなり変わります。
技術を理解する必要はありません。
「今月は何を改善したのか」を聞くだけでも、状況は変わります。
担当者が孤立しないよう日頃からコミュニケーションをとることが大切ですね。
まとめ
kintoneの担当者が辞めるのは技術的な問題ではなく、承認・評価・孤立という仕組み側の問題です。
つまり、運営体制が原因であるため代わりの人を採用しても解決しません。
同じ構造が残っていれば、次の担当者も同じ理由で辞めます。
内製化は「作れる人を確保すること」ではなく「担当者が続けられる状態を維持すること」です。
まずは、自社の運営体制に問題がないか確認することから始めてみてください。
自社がこの状態に近づいていないか、確認したい方へ。
見える化・自動化・内製化の3つの軸で、いまどこに詰まりがあるのかを3分で確認できる診断を用意しました。
無料・登録不要で、その場で結果が出ます。