English
Case Study 01 業務システム

分散していた手作業を、 一つの業務システムとして再構成。

機器利用申請、予約状況の確認、承認・却下、 ステータス管理、資産管理、運用記録までを 一つの流れにまとめるために開発した、 PHP・MySQLベースの社内向けアプリケーションです。

システム構成を見る 制作実績に戻る
01 申請フローの一元化

申請、確認、ステータス管理、履歴確認までを一つの流れに整理。

02 予約状況の可視化

申請前に機器の予約状況を確認できる仕組みを実装。

03 権限に応じた管理

社員向け申請画面と管理者向け機能を役割ごとに分離。

04 運用引き継ぎ

利用者・管理者向けマニュアルを整備し、日常運用を支援。

背景

申請する側にも、 管理する側にも分かりやすい仕組みが必要でした。

利用者には、機器の空き状況を確認したうえで 迷わず申請できる流れが必要でした。 一方、管理者側には、申請状況、履歴、資産情報を 一元的に管理できる仕組みが求められていました。

私は、要件整理と業務フローの定義から、 UI設計、PHP・MySQL開発、入力チェック、 管理機能、テスト、マニュアル作成、 運用準備まで一貫して担当しました。

課題

システム設計を左右した、 3つの実務上の課題。

単に紙や手作業をフォームへ置き換えるのではなく、 社員側の使いやすさと、 管理者側の業務フローの両方を成立させる必要がありました。

01

予約状況が把握しにくい

新しい申請を出す前に、対象機器がすでに予約されているかを 利用者自身が確認できる必要がありました。 重複申請や日程の競合を減らすための重要な要件です。

02

承認処理が分散している

管理者には、申請内容の確認、ステータス更新、 コメント記録、承認・却下を 一つの画面で扱える仕組みが必要でした。

03

担当者に依存しない運用

開発者がいなくても日常業務を進められるよう、 利用者向け・管理者向けの操作マニュアルまで システムの一部として整える必要がありました。

システム構成

一つの業務フローを、 4つの機能から見る。

各項目を選択すると、社員向け申請、 入力・処理ロジック、管理機能、記録・出力が どのようにつながっているか確認できます。

社内申請システム

選択中の機能

01 / 申請

空き状況の確認から申請まで、 利用者が迷わない流れに。

利用者は機器を選択し、利用期間と目的を入力したうえで、 内容を確認して申請します。 申請前に予約状況を確認できる構成にしています。

  • 機器選択
  • 利用期間・目的の入力
  • 予約状況の確認
  • 送信前の内容確認

担当範囲

要件整理から、 実運用の準備まで一貫して担当。

社員向けの申請画面だけでなく、 管理者が確認・承認・管理・記録を行うための 業務フロー全体を設計しました。

  1. 01

    要件整理

    実装前に、業務フローを定義する。

    申請手順、利用者・管理者の役割、 ステータス遷移、予約ロジック、 必要なデータ項目を整理しました。

  2. 02

    設計

    データとアプリケーション構造を設計。

    ユーザー、機器、申請、ステータス、 利用期間、コメント、管理機能などの データ構造と関係を設計しました。

  3. 03

    利用者画面

    申請しやすく、確認しやすい導線に。

    申請フォーム、確認画面、送信処理、 入力チェック、ステータス履歴、 予約状況の確認機能を実装しました。

  4. 04

    管理機能

    管理者が必要な操作を一つにまとめる。

    申請確認、承認、却下、取消、コメント、 ユーザー管理、機器情報管理などの 管理画面を構築しました。

  5. 05

    出力

    日常の記録業務にも使えるように。

    CSV出力、印刷用の申請詳細、 絞り込み、ステータス確認などを実装しました。

  6. 06

    テスト・引き継ぎ

    動作確認と運用準備まで担当。

    入力チェック、権限、ステータス、 日付処理、エラーケースなどを確認し、 利用者向け・管理者向けのマニュアルを作成しました。

設計上の判断

新しさよりも、 実務で使いやすいことを優先。

判断の基準は、利用者の迷いを減らすこと、 管理者の操作を一元化すること、 そして引き継ぎ後も運用しやすいことでした。

01

申請前の可視化

新規申請の前に、 既存予約を確認できるようにする。

申請フォームを最後まで入力してから競合に気づくのではなく、 早い段階で空き状況を確認できる構成にしました。

02

役割ごとの画面分離

社員向けと管理者向けを、 同じ画面に詰め込まない。

利用者と管理者では目的が異なるため、 それぞれの責任と操作に合わせて 画面と機能を分けました。

03

運用の自立性

マニュアルも、 システムの一部として考える。

日常的な操作のたびに開発者へ確認しなくても済むよう、 利用者・管理者それぞれの操作マニュアルを作成しました。

テスト・導入準備

画面だけでなく、 業務フロー全体を確認。

実運用で問題になりやすい条件を中心に、 重複日程、日付チェック、権限、 ステータス変更、出力、管理機能などを確認しました。

  • 申請内容・日付の入力チェック
  • 予約競合・重複期間
  • 権限・ロールごとの挙動
  • 承認・却下・取消・ステータス更新
  • CSV・印刷用出力
  • ユーザー・機器情報管理
  • 利用者・管理者向けマニュアル

成果

申請・確認・承認・管理を、 一つのデジタルワークフローに。

利用者向けの申請機能と、 管理者が日常運用に必要とする管理機能を 一つのシステムとしてまとめました。

申請窓口の一元化 機器ごとの予約状況確認 承認・却下・取消・ステータス管理 利用者・管理者の権限分離 機器・ユーザー情報管理 CSV出力・印刷用申請詳細 利用者・管理者向けマニュアル

活かしたスキル

設計・開発・運用を横断する システム構築力。

  • 要件整理
  • 業務フロー設計
  • PHP
  • MySQL
  • JavaScript
  • フォーム・入力チェック
  • 管理画面設計
  • テスト
  • 運用ドキュメント

社内URL、ユーザー情報、機器識別情報、 データベース認証情報、本番データ、セキュリティ設定、 ソースコードは掲載していません。 一部の業務フローや実装内容は、機密保持のため一般化しています。