kintoneで作った受発注管理が属人化した時の解決策

「うちは詳しい人がkintoneで受発注の仕組みを作ってくれたので、うまく回っています」

こう聞くと順調そうに聞こえますが、実はこれ、数年後に高い確率でつまずく典型的なパターンです。作った本人が異動・退職・産休・体調不良などで抜けた瞬間、誰も触れなくなり、業務が止まってしまう。今回はこの「kintone受発注管理の属人化」がなぜ起きるのか、そしてどう抜け出せばいいのかを整理します。

なぜkintoneは「属人化の温床」になりやすいのか

kintoneはノーコードで業務アプリを作れる自由度の高さが最大の魅力です。しかしこの自由度の高さこそが、属人化を招く原因でもあります。

作れてしまうからこそ、設計思想が1人の頭の中にしかない

受発注管理は、受注・在庫・発注・請求・入金といった複数の業務がつながっています。kintoneでこれを実現しようとすると、アプリ同士を連携させるための関連レコード設定、ルックアップ、プロセス管理、独自の計算式など、細かい設定が積み重なっていきます。

この設計は、作った本人の頭の中では筋が通っていても、ドキュメント化されていないことがほとんどです。結果として「なぜこの設定になっているのか」を説明できるのが、作った本人だけという状態になります。

「動いている」ことと「誰でも直せる」ことは別問題

kintoneのアプリは一度うまく動き出すと、日々の業務では特に問題が起きません。しかし、取引先が増えた、商品構成が変わった、消費税率が変わったといった変化のたびに、設定の修正が必要になります。このとき、作った本人以外は「どこをどう直せばいいか」がわからず、簡単な変更すら止まってしまいます。

「担当者が休むと詰む」構造

これは特に受発注管理で深刻です。受発注は毎日発生する業務なので、担当者が急に休んだり、退職したりすると、その日から業務が回らなくなります。属人化した仕組みほど、この「1人が抜けた瞬間に詰む」リスクが高くなります。

なぜ建設業でこの問題が特に起きやすいのか

建設業は、受発注管理が属人化しやすい構造的な特徴をいくつか持っています。

• 取引先の構造が複雑：元請け・下請け・孫請けといった多層的な関係や、資材の発注先が現場ごとに異なるケースが多く、標準的な受発注システムでは対応しきれない独自ルールが生まれやすい
• 現場ごとにルールが違う：現場監督や担当者ごとに発注のやり方が異なり、それを1つのkintoneアプリに落とし込む過程で、複雑な条件分岐が積み重なっていく
• 紙・FAX文化が根強く残っている：紙の注文書やFAXでのやり取りをkintoneに手入力する運用が多く、入力ルールも属人的になりがち

こうした事情から、建設業では「現場に詳しい特定の担当者がkintoneを設計し、その人にしかメンテナンスできない」という状態に陥りやすい傾向があります。

属人化のサインをチェックする

以下に当てはまる項目が多いほど、既に属人化が進んでいる可能性があります。

• kintoneアプリの設定変更ができるのが、社内に1人しかいない
• その人が休むと、受発注の確認や修正ができない
• 「なぜこの設定になっているか」を説明できる人がいない
• 新しい取引先やルール変更のたびに、その人に依頼が集中する
• アプリ内の計算式やプロセス管理が複雑化し、外部の制作会社に聞かないと直せない部分がある

解決策：ドキュメント化だけでは限界がある

よくある対策として「マニュアルを作ろう」「設定を文書化しよう」という話が出ますが、正直に言うと、これだけでは根本的な解決になりません。理由は、kintoneの自由度の高さそのものが、ドキュメント化しても追いつかないスピードで複雑化していくからです。新しい要望が来るたびに、また誰かが場当たり的に設定を足していく、という構造は変わりません。

もう一段踏み込んだ選択肢としては、次の2つがあります。

① 標準機能をベースにしたパッケージ型システムに寄せる

受発注・在庫・請求といった基本機能があらかじめ標準化されたシステムに切り替えることで、「特定の担当者しか触れない独自設定」自体をなくすアプローチです。ゼロから作り込む必要がないため、属人化の温床そのものが生まれにくくなります。

② 属人化していた運用ノウハウを、AIに引き継がせる

もう1つの視点は、「なぜこの設定にしているのか」「この取引先はこういう特殊対応が必要」といった、担当者の頭の中にしかない情報を、AIに学習させて組織の資産にするという方法です。マニュアルとして整備しきれなかった細かいノウハウも、日々の資料やコミュニケーションから拾い上げていくことで、「あの人に聞かないとわからない」状態を減らせます。

どちらか一方を選ぶというより、複雑化しやすい部分は標準機能で吸収し、それでも残る現場固有のノウハウはAIで蓄積する、という組み合わせが現実的です。

まとめ

kintoneで作った受発注管理が属人化するのは、設計した担当者の能力不足ではなく、ノーコードツールの自由度の高さそのものが引き起こす構造的な問題です。特に取引先構造が複雑な建設業では、この傾向が顕著に現れます。

ドキュメント化だけでは複雑化のスピードに追いつけないため、標準機能をベースにしたシステムへの移行と、属人化したノウハウをAIで引き継ぐ仕組みの両方を検討することが、根本的な解決につながります。

---

Wikiだるまは、受発注・在庫・請求といった標準機能をベースに、必要な分だけ機能を積み上げられる設計のシステムです。社内WikiAIによって、属人化していたノウハウの引き継ぎも同時に進められます。ご興味があれば、無料デモで実際の動作をご確認ください。