👨‍🎓

学生が連携先の社内向けシステム開発を受託し大成功した話

に公開

WorkTrack 工数管理システム開発記録 - 企業案件から学んだプロジェクトマネジメントと技術選択

※ 本記事の公開については、事前に許可をいただいております。

はじめに

本記事では、企業連携の授業にてBSC(ブレーンスタッフコンサルティング)株式会社様から受注した工数管理システム「WorkTrack」の開発プロジェクトについて、技術的な詳細から プロジェクトマネジメントの経験まで、包括的に振り返ります。

このプロジェクトは、企業における日々の作業時間と内容を効率的に管理するための › アプリケーション開発案件でした。単なる時間記録ツールではなく、部署間の権限管理、詳細な作業分析、セキュリティ要件を満たす本格的な業務システムとして設計・実装しました。

1. システム概要と完成物紹介

1.1 WorkTrack とは?

WorkTrack は、企業の工数管理と作業内容報告を効率化する Web アプリケーションです。従来の Excel ベースの管理から脱却し、リアルタイムでの作業記録、自動集計、権限に基づいたデータアクセス制御を実現しています。

主な目的:

  • 顧客(学校・企業)サポートにかかった工数の正確な集計
  • メンバー間での作業内容共有の効率化
  • 工数データの可視化と分析による業務改善

1.2 核心機能

認証・セキュリティ機能

index

  • 2 段階認証対応: メールベースの認証システム
  • パスワードリセット: セキュアなトークンベース
  • セッション管理: タイムアウト機能付き
  • 活動ログ: 全ユーザー操作の監査証跡

作業登録機能

add-work

  • 柔軟な時間入力: 5 分単位での開始・終了時刻設定
  • 同時作業対応: 同一時刻に最大 3 つの作業を並行記録
  • 自動補完: 過去の入力履歴からの項目再利用
  • レスポンシブ UI: PC・スマートフォン両対応

作業一覧表示機能

work-list

  • 階層的権限: メンバー < 主任 < 責任者 < システム管理者
  • 部署ベース制御: 8bit フラグによる複数部署対応
  • 案件リーダー権限: プロジェクト横断的な編集権限
  • 条件付きアクセス: 自分の作業は完全編集、他者の作業はメモ追記のみ

集計・分析機能

effort-graph
effort-summary
effort-detail

  • リアルタイム集計: 工数の自動計算と可視化
  • 多角的フィルタリング: 期間・顧客・担当者・部署での絞り込み
  • CSV エクスポート: 外部ツールでの詳細分析対応
  • グラフ表示: 工数トレンドの視覚的表示

マスタ管理機能(システム責任者限定)

master

  • ユーザー管理: 部署配属と権限設定
  • 顧客マスタ: 企業情報と初期案件設定
  • 案件マスタ: プロジェクト情報と責任者設定
  • 作業カテゴリ: 階層的な作業分類システム

その他機能(システム責任者限定)

  • 未入力リマインダー: 作業記録の未入力項目を通知
  • システムログ出力: 特定期間の操作履歴を CSV 形式で出力

1.3 技術アーキテクチャ

システム構成

Frontend: HTML, CSS, JavaScript
Backend: PHP 8.2, MySQL 8.0
Infrastructure: AWS (EC2 + RDS + SES)
Development: GitHub, Apache 2.4

※ 企業様からの要望によりDockerとLaravelは不採用にしました

データベース設計の特徴

db

  • 正規化された設計: 第 3 正規形に準拠したテーブル構造

  • 多対多関係: ユーザー-部署、案件-リーダーの柔軟な関連付け

  • 監査機能: 全データ変更の履歴追跡(activity_logs, edit_histories)

    - activity_logs (活動ログ)
      用途: システム全般の活動記録
      user_id  は NULL 可能(未ログイン状態での活動も記録)
      IP アドレス、ユーザーエージェントを記録
      セキュリティ監査とシステム運用監視が主目的
    
    - edit_histories (編集履歴)
      用途: データベースレコードの変更履歴
      変更前後の値を JSON で保存
      必ずログインユーザーが存在
      データ改ざん防止と変更追跡が主目的
    
  • パフォーマンス: 頻繁なクエリ用のビュー定義

プロジェクト構造

worktrack/
├── css/
├── add_work.php
├── ...
├── components.php
├── composer.json
├── .env
├── .gitignore
カテゴリ 対象ファイル 備考
認証・セキュリティ index.php, forgot_password.php, reset_password.php ログイン/パスワード再設定
マスタ管理 master_user.php, master_department.php, master_customer.php, master_project.php, master_project_category.php, master_work_category.php, master_subcategory.php, master_list.php CRUD/API 連携
作業管理 add_work.php, work_list.php 作業登録・一覧
集計・レポート effort_summary.php 工数集計・グラフ表示
システム管理・設定 system_management.php, reminder_settings.php ログ閲覧・リマインダー設定

セキュリティ設計

  • 入力検証: SQL インジェクション・XSS 対策
  • 認証強化: bcrypt ハッシュ化 + ソルト
  • ログ監視: 不正アクセス検知システム

2. 要件定義プロセス

2.1 クライアント要件の特徴

BSC 様からいただいた要件定義書は、通常のプロジェクトと比較して非常に詳細かつ具体的でした。これは同社のシステム開発経験の豊富さを物語っており、開発チームとしては要件の解釈に迷うことが少なく、実装に集中できる環境でした。

特に詳細だった要件:

  • 技術スタック指定: PHP + MySQL + AWS 構成の明確な指示
  • セキュリティ要件: 2 段階認証、ログ監視の詳細仕様
  • 権限設計: 部署・役職による細かなアクセス制御ルール

3. アジャイル開発体制

メンバー数: 6 名

プロダクトオーナー: 筆者
スクラムマスター

開発チーム構成:

  • UI/UX デザイナー
  • フロントエンド開発
  • バックエンド開発
  • インフラエンジニア
  • テスター: 筆者含めた複数名

コミュニケーションプラン(夏休み期間中)

会議名 内容 実施日 参加者
定例会 進捗管理 第二第四月曜日 18 時から 全員
作業会 チームでの作業 毎週金曜日 13 時から 全員
レビュー タスク完了報告、レビュー依頼 タスク完了時点 タスク担当者、レビュワー
ステアリングコミッティ プロジェクト重要事項の討議 方針変更発生時、トラブル発生時 プロダクトオーナー、スクラムマスター

基本的な進め方

  1. 1 週間単位でプロダクトオーナーとスクラムマスターが作業をデベロッパーに割り当てる。

  2. わからないことがあればすぐに報告(定例会でわからないは NG)

  3. 細かな単位でコミット、プッシュしてもらい、タスク完了次第レビュー依頼をする。(プッシュ通知がなければ進捗を把握できないため)

  4. レビュワーがレビューをし、問題箇所や要件不一致箇所があれば、修正を依頼する。問題がなければプルリクエストを立ててマージする。

レビュー例

  • effort_summary.php

    1. 絞り込み項目の不足
       要件: 【作業日、顧客略名、担当部署、担当者、顧客所属、顧客地域、案件カテゴリ、案件番号:案件名】
       現在: 顧客名、作業カテゴリ、案件番号、案件名、作業内容キーワード、作業ステータス、開始日、終了日
       不足: 担当部署、担当者、顧客所属、顧客地域、案件カテゴリ
    
       例えば絞り込みの顧客名のドロップダウンはイースト株式会社になっていても、工数集計画面上では EAST になっていて、条件に引っかからない。それ以外は未検証。
    
    2. 表示項目の不足
       要件: 【顧客略名、案件名、作業カテゴリ別工数、サブカテゴリ別工数、総工数】
       現在: 【顧客名、案件名、工数(時間)】
       不足: 作業カテゴリ別工数、サブカテゴリ別工数の詳細分析表示
    
       これに関しては根本的な表示方法に問題があると思うので、明日いっしょに考えても OK。
    
       顧客名 GEN の案件名が
       Deprecated: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in /opt/homebrew/var/www/effort_summary.php on line 1223
       2.0
       と初期表示されてるバグ。絞り込みとかの別の処理をすると NULL になる。
    
       詳細ボタンが機能しないバグ。本来これはなんのためのものなのか俺にはわからないので後で教えて。
    
    3. データ出力機能の未実装
       現在はアラート表示のみ
       要件: 実際の PDF/CSV 出力機能が必要
    
  • work_list.php

    🟢 責任者権限テスト
    佐藤 花子 または 伊藤 恵子 でログイン
    全部署・全ユーザーの作業データを編集できることを確認
    
    🟢 主任権限テスト
    田中 太郎 でログイン(業務システム部主任 + 教育ソリューション部メンバー)
    業務システム部の他ユーザー作業は編集可能
    教育ソリューション部の他ユーザー作業は閲覧のみ
    
    🟢 案件リーダー権限テスト
    中村 優子 でログイン(メンバー権限 + 複数案件リーダー)
    担当案件(EAST002, GEN001, WEB001, WEB002)の他ユーザー作業を編集可能
    担当外案件は通常のメンバー権限
    
    🟢 複数部署所属テスト
    山田 一郎 でログイン(業務システム部主任 + ネットワークシステム部メンバー)
    主任権限は業務システム部のみ適用
    ネットワークシステム部では通常のメンバー権限
    

4. 開発スケジュールと主要マイルストーン

マイルストーン 完了日 成果物
要件確定 2025/5/23 RDD、技術選定書
設計完了 2025/6/27 DB 設計書
環境構築完了 2025/6/20 ローカル・AWS 環境
Figma デザイン完了 2025/6/30 全画面プロトタイプ
マスタ管理完了 2025/8/26 CRUD 機能一式
メイン機能完了 2025/8/29 作業記録・集計機能
テスト完了 2025/9/1 手動テストのみ
リリース 2025/9/6 本番稼働開始

5. 複雑な権限管理システム

permissions

// 8bitフラグによる部署権限管理
class PermissionManager {
    public function canEdit($user, $workLog) {
        // 自分の作業は常に編集可能
        if ($workLog->user_id === $user->id) return true;

        // 責任者は全データ編集可能
        if ($user->isManager()) return true;

        // 案件リーダーは該当案件のみ編集可能
        if ($user->isProjectLeader($workLog->project_id)) return true;

        // 主任は同部署のみ編集可能
        if ($user->isSupervisor() && $user->sameDepartment($workLog->user)) {
            return true;
        }

        return false;
    }
}

6. プロジェクトマネジメントの学び

6.1 直面した課題

作業負担の不均衡

問題: 一部開発者への作業集中
影響: 進捗遅延とメンバーのモチベーション低下
対策: タスクの細分化と再配分、ペアプログラミングの導入

夏休み期間中のトラブル

問題: 開発停滞とコミュニケーション不足
影響: スケジュール遅延とコード品質の低下
対策: 事前のタスク整理とタスク振り直し

具体的には main にへ間違えて push してしまったり、ブランチを切り替えずに別作業をコミットしてしまったりしました。

6.2 プロジェクトマネジメントとしての成長

定量的成果

  • 完成度: 99%(メール設定以外の全機能実装)
  • スケジュール遵守率: 100%
  • 品質: 本番稼働後の重大バグ 0 件
  • クライアント満足度: 高評価とロードマップ提案の採用

AWS Leaner Lab にて環境構築をしたのですが、IAM での権限設定ができなかったので、メーリングの設定は見送りました。

定性的成長

  • リーダーシップ: チームの方向性決定と課題解決
  • 技術的判断: アーキテクチャ設計と実装方針の決定
  • ステークホルダー管理: クライアントとの効果的なコミュニケーション

7. 今後の展望と改善点

7.1 技術的改善点

テスト自動化の導入

テスト項目の確定後

# 今後実装予定のテスト構成
├── tests/
│   ├── unit/          # 単体テスト
│   ├── integration/   # 結合テスト
│   └── e2e/           # エンドツーエンドテスト

ドキュメント整備

  • ユーザーマニュアルの作成
  • 運用手順書の充実

メール機能の完成

  • AWS SES の設定完了
  • 2 段階認証メールの実装
  • リマインダー通知の自動化

7.2 運用面の改善

監視・アラート体制

  • システム稼働監視の自動化
  • 異常検知時のアラート通知

セキュリティ強化

  • 定期的なセキュリティ監査
  • 脆弱性スキャンの自動化
  • インシデント対応手順の策定

8. 本番運用と継続的な保守体制

8.1 実際の企業導入

WorkTrack は開発完了後、BSC 株式会社様にて実際に本番運用が開始される予定です。学生プロジェクトでありながら、企業の実業務で使用される本格的なシステムとして稼働し、日々の工数管理業務に活用されていきます。

運用開始後の状況:

  • 全社員による日常的な作業記録の入力
  • 管理者による工数データの分析・レポート作成
  • 部署間での作業内容共有の効率化
  • 顧客別工数集計による正確な請求管理

8.2 継続的な保守・サポート体制

本プロジェクトの特徴として、開発完了後も継続的な運用保守を担当することになっています。これにより、実際の企業システムの運用経験を積むことができる貴重な機会となっています。

保守業務の内容:

  • システム監視: 日常的な稼働状況の確認とパフォーマンス監視
  • 障害対応: 発生した問題の迅速な調査・修正対応
  • 機能改善: ユーザーからのフィードバックに基づく機能追加・改善
  • セキュリティ更新: 定期的なセキュリティパッチの適用
  • データバックアップ: 重要な業務データの安全な保管

運用から得られる学び:

  • 実際のユーザーからのフィードバック対応
  • 本番環境でのトラブルシューティング経験
  • 継続的な改善プロセスの実践
  • エンタープライズシステムの運用ノウハウ

この継続的な関わりにより、単なる開発経験を超えて、システムのライフサイクル全体を通じた学習機会を得ることができています。

まとめ

WorkTrack 開発プロジェクトは、技術的な挑戦とプロジェクトマネジメントの両面で大きな学びを得られた貴重な経験でした。

特に注目すべきは、学生プロジェクトでありながら実際の企業で本番運用されるシステムを開発し、さらに継続的な保守・運用まで担当していることです。これにより、開発から運用まで一貫したシステムライフサイクルの経験を積むことができ、エンジニアとしての実践的なスキルを大幅に向上させることができました。

このプロジェクトで得た経験は、今後のシステム開発プロジェクトにおいて必ず活かせる財産となりました。特に、要件定義の重要性、チームワークの価値、継続的な改善の必要性を深く理解できたことは、エンジニアとしての大きな成長につながったと確信しています。


謝辞

本プロジェクトの成功は、BSC(ブレーンスタッフコンサルティング)株式会社様のご支援なくしては実現できませんでした。

特に感謝申し上げたいのは以下の点です:

  • 明確で詳細な要件定義
  • 建設的なフィードバックとサポート
  • 実践的な学習機会の提供
  • プロフェッショナルな協働関係

BSC 様との本プロジェクトは、私たち開発チームにとって技術的成長とプロジェクト管理スキル向上の貴重な機会となりました。今後もこの経験を活かし、より良いシステム開発に取り組んでまいります。

改めて、BSC 株式会社様に心より感謝申し上げます。

Discussion