🚧 サンプル原稿 — 公開前にレビューが必要です。スクリーンショット差し替え、お客様情報の有無確認、技術詳細の公開可否判断を含む。
課題
現場の業務報告は、紙・メール・口頭が混在しており、案件の進捗が情シス課やマネジメント層から見えない状態が長く続いていた。
- 報告タイミングがバラバラで、最新状況がいつ・誰の頭の中にあるのか判らない
- 紙の報告書はそもそも回覧されず、ファイリングされて埋もれる
- メール報告は宛先のばらつき、CCの抜け落ちで情報が偏在
- 月次集計に都度時間がかかり、現場と管理側の双方に負担
「情シスとして、報告のために時間を使うのではなく、業務そのものに使ってもらう仕組みが必要」という認識が出発点となった。
アプローチ
外注での開発ではなく、情シス課での内製化を選択。理由は3点:
- 現場ヒアリングで得た課題感が、外部仕様書化の過程で薄まることを避けたい
- 改修サイクルを内側で回せれば、現場の声に翌週レベルで応えられる
- 業務ロジックを社内に残し、長期保守を可能にしたい
最小機能で立ち上げ、現場での実利用を経て段階的に拡張する戦略を取った。
主要機能(初期リリース)
- 案件登録・更新・進捗ステータス管理
- 担当者割り当て・通知
- 期日アラート(担当者・上長に自動通知)
- ダッシュボード(進行中/遅延/完了の俯瞰)
- CSV エクスポート(月次集計)
技術選定の理由
| 採用技術 | 選定理由 |
|---|---|
| Next.js | サーバーサイドレンダリングと CSR の両立、Vercel ライクな DX |
| TypeScript | 型安全による保守性、内製チームでの引き継ぎやすさ |
| PostgreSQL | 集計クエリと整合性を担保しつつ、運用上の知見が社内に多い |
| Prisma | スキーマ駆動で DB 進化が追いやすく、レビュー容易 |
過剰な技術スタックを避け、内製チームが面倒を見られる範囲に意図的に絞った。
効果
導入から数ヶ月で得られた変化(数値は仮置き、社内レビュー時に確定):
- 月次集計作業の時間が大幅に削減
- 案件の遅延検知が即時化(従来は月次の集計時にしか気づけなかった)
- 業務報告にかかる現場の手間が低減
- 「ダッシュボードを見れば判る」という共通言語が生まれた
学びと展望
- 外注の見積もりよりも、社内のサイクル時間を縮めることが効果を生んだ
- 報告は仕組みで担保すべきもの。属人化させない設計が現場の安心感に直結する
- 今後は、現場で発生する例外事象の記録との連携を検討中