kintoneの経費申請・業務自動化に関する記事

kintoneで承認フローを組む際の基盤は「プロセス管理」です。プロセス管理は、レコードに対して「ステータス」「アクション」「作業者」の3要素を定義し、誰がどの状態のレコードを次のどの状態へ進められるかを制御する機能です。申請→承認→完了といった一直線のフローであれば、ノーコードで数分あれば構築できます。

一方で、プロセス管理は「分岐」の表現力に制約があります。金額に応じて承認者を変える、部門によってルートを切り替えるといった条件分岐は、アクションの条件式やフィールドの値で部分的に実現できるものの、条件が増えるほど設定が読み解けなくなり、担当者が変わった時点で誰も触れないアプリになりがちです。承認ルートの設計は、機能で解けるかどうかではなく、運用が続くかどうかで判断するのが実務的です。

経費申請をkintoneで運用すると、申請フォームと承認までは問題なく回ります。詰まるのはその前後です。前段では領収書の読み取りと金額の転記が手作業で残り、後段では承認済みデータを会計システムの仕訳に落とす工程が人手に戻ります。kintoneはAPIが充実しているため連携自体は可能ですが、OCR・会計・購買のそれぞれと個別に繋ぎ込むと、保守対象のスクリプトが増え続けます。

購買稟議ではさらに構造的な問題があります。kintoneで承認されるのは「買ってよい」という意思決定までで、実際の発注は承認後に誰かが購買サイトへログインして手で行います。この分断があるため、承認された金額と実際の発注額がずれる、在庫切れで再申請になる、といった手戻りが起きます。承認と購買を同じ導線に載せられるかどうかが、この領域の効率を決める分かれ目です。

監査対応の観点では、kintoneの標準の監査ログで「いつ・誰が・何を変えたか」はある程度追えますが、保存期間や出力形式、購買・支払といった外部システム側の証跡との突合までは面倒を見てくれません。IPO準備や内部統制の強化が視野に入っている場合は、申請から支払までを1本の証跡として通せる設計を先に決めてから、kintone側の運用を組むほうが手戻りが少なくなります。

コース選定も設計に影響します。ライトコースではプラグインやカスタマイズに制約があるため、外部連携を前提とした構成を取るならスタンダードコース以上が前提になります。利用人数だけでなく「何を外部と繋ぐか」からコースを逆算してください。