kintone内製化、続かない本当の理由 ——体制面で気をつけたい5つのこと

「よし、kintoneを内製化するぞ」と決めたはずなのに、半年後には静かに止まっている。そんな会社を、私たちはこれまで数多く見てきました。

内製化がうまくいかない理由は、いくつかの種類に分けられます。今回はその中でも、私たちが日々の支援の中で特に大事にしている「体制」の視点から、気をつけているポイントを共有します。

「ツールの使い方」や「業務の整理の仕方」以前に、体制面でつまずいているケースは少なくありません。（Excelや紙の運用をそのままkintone化してしまう、といった「業務の整理の仕方」に起因するつまずきは、別の機会に詳しくお伝えします。)

kintone内製化の体制面でよくある5つのつまずきパターン

担当者を「決めただけ」で、属人化している

「kintoneに詳しそうだから」という理由で任命し、あとは本人任せ。その人しか作れない・触れないという属人化の状態が続くと、「内製化した」つもりが、実態は「特定の担当者しか分からないシステム」になってしまいます。異動や退職が起きた瞬間、運用そのものが止まってしまうリスクも抱えたままです。

責任の所在が「なんとなく」のまま

誰が管理者なのか、新しいアプリを作るときに誰が承認するのか、困ったときの問い合わせ先はどこか。これらが決まっていない状態です。責任者が不在なので、命名規則や申請フローを整える人がおらず、似たようなアプリやマスタが乱立していきます。同じように、異動や退職に合わせて権限を見直す人もおらず、退職者の権限が残り続けてセキュリティリスクにもつながります。

リリース後の改善が回っていない

リリースをゴールにしてしまい、「作って終わり」になっているケースです。現場からの改善要望が溜まる一方で対応されず、そのうち「使われないアプリ」になっていきます。使いにくさを伝えても反映されない経験が続くと、現場は次第にkintoneを開かなくなり、Excelや紙に戻ってしまいます。

内製と外注の境界が引かれていない

「全部自分たちでやる」と決めた結果、難所で手が止まってしまうケースです。担当者が8割まで作れても、残り2割で行き詰まり、相談できる相手が社内にも社外にもいないまま、1人で何週間も抱え込むことも少なくありません。気づけば「外注した方が早かった」という状態になります。内製化は「何でも自前でやること」ではなく、「どこを自分たちでやり、どこを頼るかを選べること」のはずですが、その境界線を決めていない会社は多いです。

内製化が「正式な仕事」として扱われていない

工数として計上されず評価の対象にもならず、「本業の合間にやる善意の活動」のままになっています。通常業務との兼務で時間が取れず、経営層や上司の後ろ盾もないため、忙しい時期に真っ先に後回しにされ、長続きしません。

kintone内製化の体制面を整える5つの仕組み化ポイント

① 役割を「兼務」ではなく「分担」で設計する

1人に作業や権限を集中させず、複数人で担当する、またはバックアップ担当を必ず置きましょう。あわせて、運用の手順や設定の意図をマニュアルとして残しておくことも大切です。私たちが支援するときも、マニュアルは基本的にお客様自身に作成してもらうことが多いです。誰かが異動や退職をしても、運用が止まらない状態を作ることがゴールです。

② 責任の所在を決めて見える化する

管理者は、システム管理者とアプリ管理者を別の人にする、部門ごとにアプリ管理者を置いてシステム管理者は全体の統括に専念する、といった分け方があります。管理者、アプリ作成時の承認者、困ったときの問い合わせ先を決めたら、見える場所に書いておきましょう。

資料にまとめてフォルダに置くだけでは、誰も見ないまま忘れられてしまいます。kintoneなら、システム管理者や承認者、問い合わせ先はポータルのお知らせに、アプリ管理者は各アプリの説明欄に書いておけば、普段kintoneを開くたびに目に入ります。

命名規則や申請フローは、その責任者が運用を回すための手段として、最低限のものから始めれば十分です。半期や年次など棚卸しのタイミングを決め、担当者の異動や退職に合わせて権限を見直すことも欠かせません。

③ 作った後の「改善」の仕組みを作る

リリース後も定期的に振り返り、現場の要望を拾う場を設けましょう。頻度は月に1回、30分程度からでも十分です。要望を誰が受け付け、どのタイミングで対応を判断するかまで決めておくと、「使われないアプリ」を防げます。

「使いにくさを伝えても反映されない」という経験が重なると、現場はkintoneを開かなくなります。そこで、要望を受ける窓口を、kintoneの要望アプリに一本化するのも一つの方法です。

要望ごとにレコードを作り、あるレコードについて話すときは別のツールを使わず、そのレコードのコメント欄でやりとりする。日々のやりとりがkintoneに集まるほど、要望も拾いやすくなり、kintoneを使う習慣も根づいていきます。

④ 内製と外注の線引きと、相談先を持っておく

「このレベルの難易度・緊急度なら外部に頼る」という判断基準を、あらかじめチームの共通認識にしておきましょう。目安としては、プログラミングが必要なカスタマイズや、外部システムとの連携、複雑なアプリ設計などが挙げられます。

また、止まると業務への影響が大きいものは、緊急度が高いものとして早めに相談するのがおすすめです。抱え込んでから判断するのではなく、抱え込む前に判断できる状態を作ることがポイントです。

あわせて、困ったときに相談できる先を社内外に用意しておくことも重要です。外部ベンダーは「困ったときの窓口」としてだけでなく、役割分担しながら伴走する「もう一人のメンバー」として位置づけると、専門性が必要な部分や繁忙期の負荷を無理なく分散できます。

⑤ 内製化を「正式な業務」として位置づける

担当者の工数として確保し、評価の対象にも組み込みましょう。あわせて、経営層や上司に内製化の目的と進捗を共有し、後ろ盾を得ておくことも大切です。善意や頑張りだけに頼らない体制にして初めて、内製化は一時的な取り組みではなく、継続的な仕組みになります。

まとめ

内製化が続かない理由は、体制面だけを見ても数多くあります。

• 役割を兼務でなく分担で設計する
• 責任の所在を決めて見える化する
• 作った後の改善の仕組みを作る
• 内製と外注の線引きと相談先を持っておく（ベンダー活用も含む）
• 内製化を正式な業務として位置づける

「気づけば1人に頼りきりだった」「気づけば誰が責任者か分からなくなっていた」を防ぐには、特別なツールよりも、こうした地道な体制設計の積み重ねが効きます。

なお、冒頭で触れた「業務の整理の仕方」も、内製化を続けるうえで欠かせない視点です。こちらは、また別の機会に詳しくお伝えします。

体制の話は、1社だけで抱えて考えるより、他社の実情を聞きながら考えたほうが気づきが多いテーマでもあります。キミノマホロでは、毎回異なるテーマで参加者同士が気軽に情報交換できる交流イベント「きみのまほろば〜」を、大阪と東京で毎月交互に開催しています。「うちの体制、大丈夫かな」と思った方は、よければのぞいてみてください。

📺動画でチェック！

本コラムと連動した動画を公開しています。こちらも是非ご覧ください！