承認ルート設定は、画面が1つ増えるだけのように見えますが、実際には評価業務の全体を正しく回す「仕組み」を構築するため、開発費が増加いたします。本資料では、費用の内訳と、抑えるための選択肢を、できる限り分かりやすく整理いたしました。
ご覧いただく画面は「承認ルート設定」1つの追加です。一方で、増加した費用の大半は、その画面の裏側で動く処理・組織連動・権限制御・検証にあります。
画面（入口）は確かに1つ増えます。ただし承認ルート設定は氷山のように、水面上に見える設定画面はごく一部で、費用の中心は水面下の「登録したルート通りに正しく回り、正しい人にだけ見える」ことを担保する部分にあります。
承認ルート機能の開発工数を、ざっくり分けたイメージです（比率は目安）。
御社の要件（等級別ルート・検認機構図・閲覧権限）に沿うと、次の要素が積み上がります。右上の印は工数の重みの目安です。
一般（本人→課長→部長→人事）、管理職（本人→部長→執行役員→人事）、部長級（本人→本部長→社長）など、人によって承認者が変わる出し分けロジックが必要です。
誰の上司が誰か、という組織階層を保持し、そこから承認者を自動決定します。人事異動での付け替えにも耐える設計が要ります。
「本人と評価ライン上の人だけが見られる」制御を、承認ルートから自動生成します。セキュリティ要件のため、実装も検証も慎重に行います。
未提出→自己記入→一次→二次→確定の各ステップ管理に加え、差戻し、代理承認、承認者不在時のエスカレーションなど例外系の作り込み。
各回付での通知、締切リマインド、承認が滞留した際のアラート。メール／Teams 連携を含みます。
「等級 × ルート × 差戻し × 兼務・例外」の組合せが増えるほど検証ケースが膨らみます。増分の中でも意外と大きい部分です。
承認ルートを“管理画面で自由に組める形”にするか、“開発時に固定で作り込む形”にするかで、費用と運用性が変わります。
| 観点 | 設定画面 あり（自由に編集） | 設定画面 なし（固定実装） |
|---|---|---|
| ルートの登録 | あり 管理者が画面上でルートを登録・変更できる |
なし 主要2〜3ルートを開発時に作り込む |
| ルート変更時の対応 | 管理者が画面で即時に変更 | 変更のたびに改修（都度費用が発生） |
| 閲覧権限の制御 | 登録したルートから自動生成 | 固定ルートに紐付けて実装 |
| 初期開発費 | 高め（設定機能＋検証が増える） | 抑えられる |
| 向いているケース | 組織変更が多い／自社で運用を回したい | ルートがほぼ固定で当面変わらない |
「なし（固定実装）」でも、承認フロー自体は動きます。違いは“変更を誰がどう行うか”です。
「まず必要な範囲だけ」に絞る進め方です。組み合わせてご検討いただけます。
主要ルート（一般／管理職）を作り込み、ルート編集は改修対応にする。運用上ルートがほぼ変わらない場合に有効です。
兼務の合議や承認者不在時の自動回避などの例外系を初期スコープから外し、例外は手動運用で吸収します。
通知チャネルをメールに絞り、Teams等の連携は運用が固まってから追加します。
初期は固定ルートで運用を開始し、ルートを自由に組みたくなった段階で設定画面を追加する二段構えにします。
「承認ルート設定 あり／なし」で開発費がどう変わるか、内訳見積を表でご用意できます。どの機能がいくら効いているかを可視化すれば、社内でのご説明にもそのままお使いいただけます。