導入（問題提起）

「申請がどこで止まっているのか分からない」「Excelで回しているので最新版が不明」「承認の証跡が残らない」。社内申請ワークフローをExcelとメールで運用している企業で、ほぼ必ず聞く悩みです。紙・Excel・メールの組み合わせは立ち上げコストが低い反面、次の壁に突き当たります。

  • 申請の所在が見えない（だれの承認待ちかが不明）
  • 更新版が乱立し、誤記入・再提出が頻発
  • 承認の証跡が残らず、監査対応に時間とコストがかかる
  • 重要書類がメール添付で拡散し、情報漏えいリスクが高い

これらは部分最適の積み上げで解決しにくく、仕組みそのものを見直す必要があります。そこで効果を発揮するのが、小さく始められるWebシステム開発です。本記事では、最小構成のPythonベースのWebシステムで申請ワークフローを「見える化・自動化・標準化」し、段階的に拡張していく具体策を、技術的視点と運用の現実解を交えて詳しく解説します。キーワードは「Excel Web化」「段階導入」「継続運用」。

課題の詳細説明

Excelや紙に依存した運用では、以下の課題が構造的に発生します。単発の対症療法では効果が続かないため、原因と影響の双方を把握することが重要です。

1. 業務の分散と属人化

  • ファイルが部門ごと・案件ごとに増殖し、統制が取れない
  • マクロや関数の互換性問題で破損・計算ミスが起きる
  • 「Aさんがいないと承認が進まない」などのボトルネックが固定化

2. 進捗の不可視化とリードタイムの増大

  • どの承認段階で止まっているかを一覧できない
  • 差戻し理由が履歴に残らず、再発防止ができない
  • 締切を過ぎての発見が多く、現場のやり直しが常態化

3. 監査証跡・コンプライアンスの弱さ

  • 誰が、いつ、どの版を承認したかが曖昧
  • IP/端末/操作ログが残らず、不正抑止にならない
  • 電子帳簿保存法や内部統制（J-SOX）への対応コストが高い

4. セキュリティリスクの顕在化

  • メール添付・私用端末での持ち出しによる情報漏えい
  • 社外誤送信や、退職者アカウント経由でのアクセスなど
  • 権限の粒度が粗く、最小権限の原則を満たせない

5. 連携・再利用の難しさ

  • 会計・購買・在庫など他の業務システムとデータ連携できない
  • 入力データが標準化されず、二重入力・転記ミスが発生
  • KPI/工数分析ができず、改善サイクルが回らない

これらは「申請の状態管理」と「データの正規化」という設計上の要件を満たしていないことが根本原因です。仕組みをWeb化し、データモデルを統一することで、課題を同時に解消できます。

解決方法

現実的な投資で効果を出すには、次の原則で進めます。

  1. 最小ユースケースから開始する

    2. - 例：購入申請、稟議、休日申請のいずれか1つ - 「1申請種×2段階承認」から始め、運用を安定させてから拡張

  2. データモデルを固定化する

    3. - requests（申請）、approvals（承認）、users（利用者）、audit_logs（監査） - ステータス機械（State Machine）を明確化：draft → submitted → approved/rejected → archived

  3. 役割と権限（RBAC）をシンプルに定義

    4. - 申請者/承認者/管理者の3ロール - 部門スコープと最小権限を徹底

  4. 通知と期限管理を自動化

    5. - 提出・差戻し・期限超過時にメール/チャット（Webhook）で通知 - 期限前のリマインドと、管理者向け滞留ダッシュボード

  5. 既存Excelの良さを活かしたExcel Web化

    6. - 入力はWebフォームに統一、必要に応じてCSVインポート/エクスポート - 会計・購買など既存業務システムへはCSV/REST APIで連携

  6. 実装ランタイムはPythonで小さく始める

    7. - 小規模ではPythonのWebアプリ（Bottle/FastAPI）+ SQLiteで十分 - 将来はPostgreSQL/MySQLに差し替え可能なアーキテクチャを選択

具体例

代表的なユースケースごとに、画面・データ・運用の観点から具体的に示します。

A. 購入申請（一般部門向け）

  • 画面：一覧（自分の申請/自分宛の承認）、新規申請、詳細（履歴/コメント）
  • 入力項目：タイトル、金額、用途、取引先、添付（見積書PDF）
  • 承認フロー：申請者 → 部門長 → 管理部
  • 自動化：提出時に次承認者へ通知、承認完了で会計にCSVをメール送付

B. 稟議申請（経営会議向け）

  • 画面：案件ボード（金額・ROI・優先度）、差戻し理由のテンプレ選択
  • 入力項目：目的、投資額、回収見込み、リスク、代替案
  • 承認フロー：申請者 → 担当役員 → 代表
  • 自動化：金額しきい値により承認段数を自動分岐、期限前リマインド

C. 休暇申請（人事労務向け）

  • 画面：カレンダー表示、重複アラート、スマホ最適化
  • 入力項目：種別（有給/代休/特別）、期間、引継メモ
  • 承認フロー：申請者 → 上長
  • 自動化：承認時にカレンダーへ反映、給与計算システムにエクスポート

データ構造（例）

  • requests: id, applicant_id, type, title, amount, reason, status, created_at, updated_at
  • approvals: id, request_id, approver_id, step, action, comment, acted_at
  • users: id, name, email, role, department
  • audit_logs: id, actor_id, action, entity, entity_id, ip, ua, at

権限の基本

  • 申請者：自分のドラフト編集・提出、差戻し再提出
  • 承認者：割当ステップの承認/差戻し、コメント
  • 管理者：様式・承認経路・マスタ管理、監査ログの閲覧

自動化シナリオ

  • 提出時：次承認者へメール/チャット通知（宛先はロール/部門で解決）
  • 期限超過：自動リマインド、管理者にハイライト
  • 承認完了：会計へCSV/メール通知、台帳へ自動登録

技術的な解説

ここでは、小規模から始められるPythonベースのアーキテクチャを具体的に紹介します。後からの拡張や置き換えを前提に、部品を疎結合に保つのがポイントです。

推奨アーキテクチャ（小規模スタート）

  • フロント：HTMLテンプレート（Jinja2）+ 素のJavaScript/Alpine.js
  • サーバー：Python（Bottle もしくは FastAPI）
  • データベース：SQLite（単一バイナリで簡易バックアップ）
  • メール/チャット通知：Webhook + SMTP（後に通知キューへ拡張）
  • 認証：セッション/クッキー（社内AD/Google Workspace連携は後から）

モデル設計（擬似コード）


from dataclasses import dataclass
from datetime import datetime

@dataclass
class Request:
    id: int
    applicant_id: int
    type: str  # purchase, ringi, leave
    title: str
    amount: int | None
    reason: str
    status: str  # draft/submitted/approved/rejected/archived
    created_at: datetime
    updated_at: datetime

@dataclass
class Approval:
    id: int
    request_id: int
    approver_id: int
    step: int
    action: str  # approve/reject/pending
    comment: str | None
    acted_at: datetime | None

ルーティング例（Bottle）


from bottle import Bottle, request, redirect, template
app = Bottle()

@app.get('/requests')
def list_requests():
    # DBから自分の申請と自分宛の承認を取得
    return template('requests.html', items=fetch_items())

@app.post('/requests/new')
def create_request():
    # フォーム入力を保存し、次承認者に通知
    save_request(request.forms)
    notify_next_approver()
    return redirect('/requests')

ステータス機械（状態遷移）

  • draft → submitted：申請者が提出
  • submitted → approved：承認者が承認
  • submitted → rejected：承認者が差戻し（コメント必須）
  • approved/rejected → archived：一定期間後にアーカイブ

実装では、状態遷移ごとにフック（Webhook/イベント）を設け、通知・ログ・外部連携を一元処理します。

RBAC（役割ベースアクセス制御）

  • ロール：applicant, approver, admin
  • ポリシー：can_approve(request, user) は「割当ステップ×部門一致×未処理」で真
  • UI：権限のない操作はボタン非表示、API側でも二重に検証

監査・セキュリティ

  • 監査ログ：全イベント（作成/提出/承認/差戻し/設定変更）を永続化
  • データ整合：外部キー制約・ソフトデリート・楽観ロック（更新衝突回避）
  • セキュリティ：CSRF対策、入力検証、ファイルアップロード制限（拡張子/サイズ/スキャン）

連携（Excel Web化と他システム）

  • インポート：既存ExcelテンプレのCSVを取り込み、申請ドラフトを一括作成
  • エクスポート：承認済みデータをCSV/JSONで出力し、会計などの業務システムへ投入
  • 将来：REST APIエンドポイントを用意し、双方向連携（Webhookでイベント駆動）

導入の流れ

いきなり全社導入せず、失敗コストを抑えつつ確実に定着させます。

  1. 現状可視化（1〜2週）

    2. - 申請種別・件数・平均リードタイム・主な差戻し理由を洗い出し - フロー図を作り、どこで詰まっているかを明確化

  2. PoC（概念実証：2〜3週）

    3. - 「1申請種×2段階承認」をPythonの簡易Webアプリで実装 - 部門代表者とテストし、必須機能と余剰機能を仕分け

  3. パイロット導入（4〜6週）

    4. - 対象部門を限定し、本番運用に近い形で実施 - KPI（滞留時間/差戻し率/再提出回数）を計測

  4. 全社展開（4〜8週）

    5. - 申請種と承認段数を段階的に拡張 - AD/SSO、PostgreSQL、バックアップ/DRなどを整備

  5. 運用改善（継続）

    6. - ダッシュボードでボトルネックを特定し、様式・ルールを更新 - 外部連携（会計/購買/在庫）をCSVからAPIに切替

まとめ

ワークフローのWeb化は、現場の負担を増やすものではなく、むしろ「入力の標準化」「状態の見える化」「承認の自動化」によって、全社の生産性を底上げする取り組みです。最初は小さく、しかし設計は将来の拡張を見据えて。Pythonを活用した小規模なWebシステム開発であれば、初期費用を抑えつつ、Excel Web化の利便性と企業統制の強さを両立できます。重要なのは、要件を盛り込みすぎないことと、運用データから学び続ける姿勢です。まずは「1申請×2段階承認」から始め、監査ログ・通知・CSV/API連携といった業務システムの基本を固め、段階的に拡張していきましょう。

Webシステム開発のご相談は monou まで → /contact