権限管理や承認ルールを見直したい企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、誰が何をできるかを、職位ではなく業務プロセスで決めることを重視して進め方を整理します。
この記事では、基幹システムの権限管理をいつ・どのような観点で見直すべきかを整理します。情報システム担当者だけでなく、職務分掌や内部統制の観点で現状に不安を持つ管理部門・経営層にも読んでいただきたい内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
権限の見直しどきは「組織とシステムのずれ」が教えてくれる
権限管理の見直しが必要になるのは、組織変更や人の入れ替わりにシステム側の設定が追いつかなくなったときです。兼務が増えて一人が広い権限を持っている、退職者のアカウントが残っている、異動前の権限がそのまま引き継がれている。こうした状態は日常業務では問題が表面化しにくい一方、誤操作や不正の温床になり、監査で指摘されて初めて慌てることになります。
職位ではなく業務プロセスで権限を設計する
「部長だから全部見られる」という職位ベースの権限は、一見分かりやすいものの、実際の業務と乖離しやすい設計です。誰がどの業務プロセスで何を入力し、誰が承認し、誰が結果を参照するのかという業務の流れから権限を組み立てると、必要十分な設定に近づきます。特に、金額の修正・マスタの変更・締め後の訂正といった影響の大きい操作は、実行できる人を業務上の必然性がある範囲に絞ることが原則です。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある問題は、権限の種類が「管理者と一般」の2段階しかなく、少し特殊な作業のたびに管理者権限を貸し出す運用になっているケースです。貸し出された権限は返却されずに残り、実質的に全員が管理者という状態に行き着きます。古いシステムほど権限の粒度が粗く、業務の実態に合わせられないことが、この運用を生む根本原因です。
また、入力者と承認者が同一人物になれてしまう設定も、内部統制上の典型的な指摘事項です。少人数の会社では完全な分離が難しい場面もありますが、その場合でも事後チェックの仕組みや上長への通知など、代替の統制を設計しておくことが求められます。
見直しの実務は、現在の利用者一覧と権限設定を出力し、実際の業務分担と突き合わせることから始まります。この棚卸しだけで、退職者アカウント、過剰権限、承認の形骸化といった問題の大半は可視化できます。年に一度の定期的な権限棚卸しをルール化すれば、見直しを一過性で終わらせずに済みます。
自社で確認できるチェックポイント
権限管理の見直しを検討する前に、次の点を確認しておくと、問題の所在と優先順位が明確になります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
権限管理ならではの棚卸しポイント
基本のチェックリストに加えて、利用者数と権限パターンの数、退職・異動時のアカウント処理の手順、入力と承認の分離状況、締め後データの修正を誰ができるかを確認してください。特に「システム上できてしまうこと」と「業務ルール上やってはいけないこと」の差分が、リスクの正体です。この差分を一覧にすると、システムで統制すべき部分と運用ルールで担保する部分の切り分けが議論できるようになります。
棚卸しでは、システムの画面権限だけでなく、データベースへの直接アクセスやCSV出力の権限も対象に含めてください。画面をどれだけ統制しても、データを丸ごと出力できる経路が野放しでは意味がありません。情報の出口まで含めて全体を見ることが、実効性のある権限管理の条件です。
また、権限の見直しは組織変更や人事異動のタイミングと連動させると定着します。異動発令と同時に権限変更の申請が動く運用を作れば、「異動したのに前の部署のデータが見える」という統制の穴を仕組みとして塞げます。年次の権限棚卸しと異動時の即時見直し、この二本立てが基本形です。
延命・部分改善で対応できるケース
権限の課題があっても、システムの作り直しが必要とは限りません。次のような場合は設定と運用の見直しが先です。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
現行システムに権限設定の機能が備わっているなら、棚卸しと再設定、アカウント管理ルールの整備だけで、コストをほとんどかけずにリスクを大きく減らせます。承認フローの追加など小規模な改修を伴う場合でも、数百万円規模で収まることが多い領域です。
ただし、権限の粒度が粗すぎて業務に合わせられない、利用者の特定すらできない共有アカウントで運用しているといった構造的な制約がある場合は、運用の工夫だけでは限界があります。その制約自体が、再構築を検討すべきサインの一つです。
費用と期間の目安としては、権限棚卸しと再設定・運用ルール整備なら小規模な支援で済み、承認ワークフローの追加開発で数百万円・2〜3か月程度、権限体系を含めた基幹システムの再構築では全体費用の中で権限設計が要件定義の重要テーマになります。権限は後から作り込むと画面や帳票の改修が連鎖するため、再構築時には初期の設計段階で固めておくのが最も安上がりです。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
次のような状況に当てはまる場合は、設定変更の範囲を超えており、再構築とあわせた権限体系の再設計を検討すべきです。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
一般的な職務分掌に沿った運用ができるなら、パッケージの権限・承認機能を活用するのが近道です。パッケージは内部統制で求められる標準的な統制が組み込まれていることが多く、監査対応の説明もしやすくなります。ただし、自社特有の承認ルートが表現できるかは事前確認が必要です。
周辺開発で補うケース
基幹本体の権限が粗い場合に、承認ワークフローや申請管理だけを周辺の仕組みとして追加する方法です。本体に手を入れずに入力と承認の分離を実現でき、統制の空白を比較的短期間で埋められます。
スクラッチ再構築が向くケース
業務プロセスが独自で、権限と承認の要件がパッケージに収まらない場合は、再構築時に業務フローと一体で権限体系を設計します。誰が何をできるかを業務の言葉で定義できるため、監査への説明力が最も高い形になります。
マクティズムの見解
マクティズムの見解として、基幹システムの権限管理を見直すタイミングでは「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、誰が何をできるかを、職位ではなく業務プロセスで決めることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
権限の相談では、統制を厳しくしすぎて業務が回らなくなる失敗も、緩いまま放置する失敗も、どちらも見てきました。私たちは理想論を押し付けるのではなく、会社の規模と人員の実情に合った「守れる統制」を一緒に設計することを大切にしています。小さな会社には小さな会社なりの、実効性のある統制の形があると考えています。
相談前に準備しておく情報
権限の相談では、利用者数と部署構成、現在の権限パターンの概要、入力と承認の分担、監査や取引先から受けた指摘があればその内容が分かると、初回から具体的な改善案を話せます。組織図と業務分担表があれば十分な出発点になります。
実務では、現行調査で権限の実態と業務分担のずれを可視化し、開発前診断で設定変更で済む範囲・追加開発が必要な範囲・再構築で解決すべき範囲を仕分けたうえで、リスクの大きい箇所から順に手当てする計画をおすすめしています。
権限管理が整うと、監査対応の負担が軽くなるだけでなく、担当者自身も「触ってよい範囲」が明確になり安心して操作できるようになります。統制は現場を縛るためではなく、人をミスと疑いから守るための仕組みだと捉えると、社内の理解も得やすくなります。
見直しは一度にすべてを完璧にする必要はありません。退職者アカウントの整理と高リスク操作の制限から着手し、承認フローの整備へと段階的に進めるのが現実的です。
権限見直しの副産物として、業務の実態が見えてくることも多くあります。設定を棚卸しする過程で、退職者の業務が誰にも引き継がれていなかった、特定の一人にしかできない操作が集中していた、といった組織上の問題が浮かび上がるためです。権限の整理は、業務の属人化を発見する健康診断としての価値も持っています。
クラウドサービスや外部連携が増えている場合は、基幹システム単体ではなく、サービスをまたいだアカウント管理の全体像も視野に入れておくと、将来の見直しが楽になります。
見直した権限のルールは一覧表として文書化し、次の担当者へ引き継げる形にしておくことも忘れないでください。設定は仕組みに、判断基準は文書に残すのが基本です。
統制のルールは、作った後に一度は実際の異動で試し、手順が回るかを確かめておくと安心です。定着してはじめて統制と呼べる状態になります。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。権限の場合、利用者数と現在の権限パターンの概要が分かれば十分に相談を始められます。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。アカウント棚卸しと設定見直しだけを先に行い、仕組みの改修は必要に応じて検討する進め方が可能です。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。自社の承認ルートが標準機能で組めるかどうかも、選定時の確認項目として一緒に見ます。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。承認ワークフローの追加など、統制上リスクの大きい部分だけの改善からでも対応できます。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。現状の指摘事項や不安点を伺い、優先度の高いものから整理していきます。
