2025年4月13日·2 分
社内サービスリクエスト用ウェブアプリの作り方
社内のサービスリクエストを収集・承認・SLA追跡・レポートするウェブアプリを、計画、設計、構築する方法を学びます。安全性と運用性を重視した実践ガイドです。
社内のサービスリクエストを収集・承認・SLA追跡・レポートするウェブアプリを、計画、設計、構築する方法を学びます。安全性と運用性を重視した実践ガイドです。
画面設計や技術選定の前に、社内サービスリクエストアプリが何を解決するのかを具体化してください。多くのチームはすでに「仕組み」を持っています——ただしそれはメールスレッド、チャット、スプレッドシート、雑談に散らばっているだけです。その状態は作業を隠し、重複したリクエストを生み、「誰が担当で、いつ終わるのか？」という簡単な問いに答えにくくします。
まずは短く鋭い問題定義とv1の目標を書きます。例: 「ITアクセスと施設修理のための単一の従業員リクエストポータルを提供し、明確な担当、必要な承認、SLAの可視化を実現する。」
社内リクエストは通常、いくつかのカテゴリにまとまります:
初日からすべてのエッジケースを解く必要はありませんが、明確な開始スコープ（例: 「ITアクセス＋施設修理」）を選びましょう。
現状の障害点を平易な言葉で書き出します:
このリストがアプリで何を直すべきかの北極星になります。
主要ユーザーとそれぞれのニーズを定義します:
ローンチ後に追跡できる目標を設定します: 解決時間の短縮、1チケットあたりの追跡回数の減少、初回応答速度の向上、明確な責任（例:「全リクエストは1営業時間以内に担当者が割り当てられる」）など。これらはプロダクト判断を導き、アプリが機能していることを示す根拠になります。
画面やワークフローを設計する前に、誰がアプリを使い、各人が何を許可され期待されるかを明確にします。多くの社内サービスリクエストシステムはロールが曖昧なため失敗します: 次のステップの所有者が分からず、リクエストが行ったり来たりします。
従業員（申請者）
従業員は数分でリクエストを提出でき、消えないと確信できるべきです。
承認者（Approver）
承認者は支出やアクセス、ポリシー決定を管理します。
担当者 / 解決者（Agent / Resolver）
実際に作業を行い進捗を伝えるのが担当者です。
管理者（Admin）
システムを整理し安全に保つのが管理者の役割です。
各リクエストタイプについて次を定義します:
仕様に簡単なRACI表を入れておくと混乱が防げ、後のワークフロー設計が楽になります。
v1の社内リクエストポータルは、従業員が明確なリクエストを提出でき、それが正しいチームに素早く届き、完了まで全員が情報を得られることを重視すべきです。初日からすべてのエッジケースを詰め込もうとすると納期が遅れ、結局ユーザーに必要なものを見逃します。
小さなカテゴリセット（例: ITヘルプ、施設、HR、購買）から始めます。各カテゴリは動的フィールドをサポートして、フォームが関連ある項目だけを尋ねるようにします。
含めるべきもの:
v1では予測可能な割り当てが必要です: カテゴリ、部署、ロケーション、キーワードルールで振り分けます。優先度（低/中/高）と1つのシンプルなエスカレーション経路（例: 「24時間未割当」や「高優先度が4時間アイドル」）を追加します。ルールエディタは最小限に保ち、後で柔軟性を増せます。
まずは単段階承認（マネージャーまたは予算責任者）をサポートします。承認が重要なら条件付き承認（例: 「$500超はFinance」）を追加します。多段階チェーンは、主要なリクエストタイプでない限り後回しにします。
受信確認、割当、情報要求、承認/却下、完了などについてメールとアプリ内通知を含めます。承認者や担当者に対する期限前リマインダーも追加します。
提出前とリクエスト一覧で、カテゴリ・ステータス・申請者でフィルタできる検索を提供します。「類似リクエスト」やナレッジページへのリンクを追加して、一般的な問題はチケットを開かずに解決できるようにします。
明確なリクエストデータモデルがあれば、フォームの一貫性、ワークフロー自動化、信頼できるレポーティングが実現します。まずは組織内で「リクエストとは何か」と、毎回必ず取るべき詳細を決めましょう。
初期フォームは簡潔に保ちつつ、受け取る側が差し戻しなく動けるだけの情報を含めます。実用的なベースラインは次の通りです:
カテゴリは作業の組織化方法を反映すべき（IT, Facilities, HR, Finance）。サブカテゴリは繰り返し発生する作業タイプ（例: IT → 「アクセス申請」「ハードウェア」「ソフトウェア」）を表します。ユーザーに優しい名前にし、重複（「オンボーディング」と「新入社員セットアップ」など）を避けてください。
カテゴリが増えたら名前を黙って変更するのではなくバージョン管理し、レポーティングと混乱を防ぎます。
バリデーションで曖昧なチケットやルーティング情報の欠如を防ぎます:\n\n- 最低限の説明文字数を必須にする（または「目標は何か？」のようなガイドプロンプト）\n- デフォルトを用意する（例: 緊急度は「通常」）\n- ディレクトリから申請者プロファイルを自動入力する\n- 関連ある場合のみ動的フィールドを表示（例: 施設のときだけ「建物」を表示）
チームが解釈をしないシンプルなライフサイクルを選び、各ステータスの意味を定義します:\n\n- New → In Triage → Waiting for Info → Pending Approval → In Progress → Done\n- 取り下げや無効なリクエストにはCanceledを含める
遷移ルール（誰がPending Approvalにできるか？Waiting for Infoはいつ使えるか？）を書き出し、ステータス変更、割当、承認、主要な編集の監査トレイルを保存します。
サービスリクエストの成功は、従業員がどれだけ速く申請でき、チームがどれだけ簡単に処理できるかにかかっています。構築前にコア画面と各ロールの“ハッピーパス”をスケッチしてください: 申請者、承認者、担当者。
申請フォームは単一の圧倒的なページではなく、案内するフローとして扱います。カテゴリに応じたステップ表示（または段階的開示）で、従業員には関連する項目だけを見せます。
期待値を明示する: 必須情報、通常の応答時間、提出後に何が起きるかを表示します。ツールチップやヘルパーテキストで往復の手間を防ぎます（「‘緊急’とは何か？」「どのファイルを添付すべきか？」など）。
リクエストを処理する人には、素早くソートとトリアージができる受信箱スタイルの一覧が必要です。現実の作業に合うフィルタを付けます:\n\n- ステータス（new、waiting on requester、pending approval、in progress、done）\n- カテゴリ（IT、Facilities、HR、Financeなど）\n- 担当者またはチーム\n- 日付範囲（作成/期限）
一覧の行は「これは何で、次に何をすべきか？」が一目で分かるように設計します: タイトル、申請者、優先度、現状ステータス、期限/SLA指標、次のアクション。
詳細ページは協働の場です。次を組み合わせます:\n\n- ステータス変更と承認のタイムライン（監査トレイルを平易に表示）\n- 申請者に見えるコメント\n- スタッフのみの内部メモ\n- 添付（誰が見られるか/ダウンロードできるかの権限設定）
主要アクション（承認/却下、割当、ステータス変更）は目立たせ、二次的アクションは見つけやすくしつつ邪魔にならないようにします。
最初のワイヤーフレームからアクセシビリティを計画します: すべての操作でキーボードナビゲーション、十分なコントラスト（色だけで状態を示さない）、スクリーンリーダーで動作するラベルを用意します。
ワークフローがあれば「フォーム＋受信箱」以上の予測可能なサービス体験になります。早めに定義しておけばリクエストが停滞せず、承認が任意にならず、誰もが「完了」の定義を理解できます。
バックアンドフォースを減らすクリーンな提出パスから始めます:\n\n- 作成: 従業員がリクエストタイプを選び（例: ITアクセス、施設修理）、必要な項目だけに回答する\n- 確認: 提出前にカテゴリ、緊急度、ロケーション、添付など主要項目の要約画面を表示する\n- 追跡: 提出後にリクエストID、現状ステータス、次に期待されるステップ（例:「4時間以内にトリアージ」）を提示する
トリアージはシステムが共有メールボックスにならないために重要です。\n\n- 自動割当: リクエストタイプ、ロケーション、部署、オンコールローテーションに基づいて割り当てる\n- 優先付け: 明確なルール（インパクト×緊急度）で決め、感覚に頼らない\n- 確認: Waiting for Info に移し、構造化された質問テンプレートで情報を求める。時計は無言でリセットせず、ログを残す
承認はポリシー駆動かつ一貫性を持たせます:\n\n- 承認マトリクスを定義（例: 「新規ソフト購入 > $200 はマネージャー＋Finance」）\n- ロールベースの権限で、特定カテゴリを承認できる人だけが決定できるようにする\n- 低リスク項目（パスワードリセット等）や緊急時のバイパスルールを設け、理由を必須にする\n- 誰が承認したか、いつか、何が変わったか、コメントを含めて監査トレイルに残す
エスカレーションは罰則ではなくセーフティネットです。\n\n- 期限切れ前にSLA警告を送る（例: 制限時間の75%到達時に担当者とチームリードへ）\n- シフト交代時の引き継ぎは所有権移行とノートを伴う\n- 再割当には理由コードを必須とし、人員配置やルーティングの問題を後で特定できるようにする
うまく設計すれば、これらのワークフローはリクエストを動かし続け、従業員には予測可能な結果を、チームには明確な責任を与えます。
良いスキーマはメンテナンス性、レポーティング性、進化のしやすさを高めます。まずはクリーンな「コア」テーブル群を目指し、柔軟性や分析用のテーブルを追加してください。
ほとんどの画面で触るテーブルから始めます:\n\n- users: id, name, email, status, created_at\n- roles: id, name（例: Employee, Approver, Agent, Admin）\n- user_roles: user_id, role_id（多対多）\n- teams: id, name; と team_members（team_id, user_id）\n- requests: id, requester_id, category_id, title, description, status, priority, assigned_team_id/assigned_user_id, created_at, updated_at, resolved_at\n- comments: id, request_id, author_id, body, visibility（internal/public）、created_at\n- attachments: id, request_id, uploaded_by, file_name, storage_key, size, created_at\n
requests.statusは制御された値の集合にし、ライフサイクル分析のためにタイムスタンプを保存してください。
リクエストタイプごとに新しいテーブルを作らずに済むように:\n\n- categories: id, name, default_team_id, active\n- form_fields: id, category_id, key, label, type, required, sort_order\n- request_field_values: request_id, field_id, value（テキスト/JSON）\n- approvals: id, request_id, step, approver_id, decision（pending/approved/rejected）、decided_at\n- sla_policies: id, category_id, priority, response_due_minutes, resolve_due_minutes\n
監査トレイル用に audit_events を作り、request_id、actor_id、event_type、old_value/new_value（JSON）、created_at を保存します。ステータス変更、割当変更、承認を明示的に追跡します。
レポーティング用にビュー（将来的に専用テーブル化も可）を用意すると良い: 解決/応答時間（SLA追跡）、チーム/担当者別バックログ、カテゴリ・優先度別ボリュームなど。
requests(status, created_at)、requests(assigned_team_id)、audit_events(request_id, created_at) にインデックスを張り、一般的なクエリを高速化してください。
サービスリクエストアプリは「変更しやすい」ことが成功の鍵です。v1はチームがフォーム、承認ステップ、SLAルールを追加するにつれて進化します——だから流行ではなく、チームが維持できる技術を選んでください。
多くの社内ツールでは「安定した選択」が勝ちます:\n\n- フロントエンド: React または Vue とコンポーネントライブラリ（例: Material UI、Ant Design、Vuetify）。フォーム、テーブル、モーダルの一貫性が早く実装できます。\n- バックエンド: Node/Express, Django, Rails, または .NET。チームが最も得意なものを選ぶとワークフロー自動化やチケットロジックが速く品質良く実装できます。
もっと早く動きたい場合（特に社内ツールでは）、Koder.ai のようにチャットでサービスリクエストポータルを記述してイテレーションできるビブコーディングプラットフォームを検討しても良いでしょう。Koder.aiは一般的にフロントにReact、バックにGo + PostgreSQLをターゲットにし、ソースコードのエクスポートやデプロイ、スナップショットとロールバックをサポートします。価格帯はFree/Pro/Business/Enterpriseがあり、パイロットができます。
/requests, /approvals, /attachments のような素直なエンドポイントが欲しければRESTが向きます。UIが同じリクエストデータの多様なビューを多用し、柔軟性が必要でかつ複雑さを受け入れられるならGraphQLを検討します。アーキテクチャはv1ではモジュラーモノリスが理想的です: リクエスト、承認、通知、レポーティングといったモジュールを明確に分けつつ一つのデプロイ可能なアプリにする。マイクロサービスより運用が簡単です。
社内リクエストはスクリーンショットやHR書類を含むことが多いです。\n\n- ファイル保存: オブジェクトストレージ（S3互換）を使い、署名付きURLでバックエンドを経由させずに配信する\n- ポリシーに応じてウイルススキャンを追加（特にメール経由取り込み時）
Dockerでコンテナ化すると環境が一貫します。ホスティングは組織が既に使っているマネージドプラットフォーム（PaaSやKubernetes）を選んでください。選定時は次を満たすことを確認します:\n\n- ロールベースのアクセスと監査トレイル\n- リクエストフォーム進化のためのデータベースマイグレーション\n- 遅延のある承認フローを診断するための可観測性（ログ＋メトリクス）
選択肢を比較する際は意思決定基準を短く文書化しておくと、後任が助かります。
社内向けでも、ID情報やリクエスト内容、時には機密添付を扱うため、セキュリティは「後回し」ではありません。早期にいくつかの基本を押さえると将来の手戻りを防げます。
SAMLやOIDCによるシングルサインオン（SSO）を優先し、従業員は既存のアカウントを使えるようにします。Entra ID/Active Directory/Google Workspaceのようなディレクトリと統合し、入社/異動/退職の更新を自動化します。
ロールベースアクセス制御（RBAC）で、申請者、承認者、担当者、管理者の可視性を明示します。サポートグループは自分に割当られたリクエストのみを見られるようにし、従業員は自分のリクエストのみ（場合によっては自部署も）見られるようにします。
通信は全てHTTPSで暗号化します。保存データでは必要なフィールドやファイルを暗号化し、コードに資格情報を置かないようにします。シークレットマネージャやVaultを使い、鍵は定期的にローテーションします。
承認、アクセス変更、給与関係のリクエストなどでは変更不可な監査トレイルを保持します。監査ログは追記専用にし、アクセス制限を設けます。
ログインや主要エンドポイントにはレート制限を設け、入力の検証とサニタイズを行い、ファイルアップロードを保護（タイプチェック、サイズ制限、必要ならマルウェアスキャン）します。これらの基礎があればチケットシステムやワークフロー自動化はミスや悪用に対して耐性がつきます。
アプリは人が通知を見て対応して初めて機能します。統合はリクエストポータルを日常業務に馴染ませ、「また別のタブ」にならないようにします。
行動を促す最小限の通知セットから始めます:\n\n- 割当: 割当先（とバックアップ）へ通知\n- コメントとメンション: 関与者が返信や@メンションで通知を受け取る\n- 承認: 承認者を明確な承認/却下の行動へ促す通知\n- SLAリスク: 期限切れが近いときにオーナーへ警告し、通過したらエスカレーション\n\nメッセージは簡潔にし、リクエストへのディープリンクを含めます。組織がSlackやTeams中心ならチャット通知を送りますが、メールも監査性やチャットを使わないユーザーのために残しておきます。
Okta、Azure AD、Google Workspaceと同期して組織構造と紐づけると:\n\n- 部署/ロケーションによる自動ルーティングが可能\n- マネージャー承認をマネージャーフィールドで実現できる（承認者をハードコーディングしない）\n- ロールベースのアクセスが異動時に最新のまま維持される
同期はスケジュールとログイン時に行い、エッジケース用に管理者のオーバーライドを残しておきます。
オンサイト訪問や面接、機材引き渡しが関わる場合はカレンダー統合で時間候補を提案し、承認後にイベントを作成します。カレンダーはリクエストから派生させ、リクエストを単一の信頼できる情報源に保ちます。
構築か購入かを判断する際は、自分たちの統合要件を /pricing のパッケージと比較するか、一般的なパターンを /blog/it-service-desk-basics で調べてください。
パフォーマンスを測らなければ改善できません。レポーティングはボトルネックを見つけ、要員増を正当化し、ビジネスに対する信頼性を示す手段です。
全員が理解できる小さなSLAセットから始めましょう。\n\n初回応答時間は提出から最初の人のアクション（コメント、確認要求、割当、ステータス更新）までの時間です。\n\n解決時間は提出から完了（クローズ）までの時間です。\n\nSLAルールはカテゴリと優先度ごとに明示します（例:「アクセスリクエスト: 初回応答4営業時間以内、解決2営業日以内」）。また時計を一時停止する条件（申請者の応答待ち、サードパーティ承認、情報欠如など）を決めてください。
レポートはダッシュボードだけに置かないでください。担当者とチームリードには行動しやすい運用画面が必要です:\n\n- 担当者キュー: “自分のチケット” と次のアクション、期限、最長待ち順情報\n- チームバックログ: カテゴリ/優先度別、キャパシティ指標（担当者あたりのオープン数）\n- エイジングチケット: 開始からの経過時間順、SLAリスク（期限が近い/超過）\n これらのビューがSLA追跡を実務に結びつけます。
管理者向けに軽量のダッシュボードを用意し、短時間で答えを得られるようにします:\n\n- 時間ごとのボリューム推移（週/月）\n- 上位カテゴリとどこから来ているか\n- ボトルネック: 一番長く停滞するステップや承認
グラフはクリック可能にして、数字の背後にある実際のリクエストにドリルダウンできるようにします。
優れたUIがあっても、オフライン分析を好む利害関係者はいます。フィルタ済みリストのCSVエクスポート（チーム、カテゴリ、日付範囲、SLA状態）を提供し、財務や監査チームが管理者権限なしで分析できるようにします。
良い社内リクエストアプリのローンチは大きな発表よりも制御された学習です。v1を速やかに改善するプロダクトとして扱い、完成品と考えないでください。
パイロットはボリュームが意味を持ち、リスクが管理できる1つの部署や1つのリクエストタイプ（例: ITアクセスや施設修理）から始めます。パイロットの成功基準を定義してください: 提出から解決までの時間、完了率、手作業修正がどれくらい発生するかなど。
パイロットが安定したら波状的に拡大します: 部署追加、フォーム追加、そして自動化追加。アプリ内に「何が変わったか」ページやリリースノートを置き、ユーザーが驚かないようにします。
信頼を壊す経路に重点を置いたテストを行います:\n\n- ユニットテスト: バリデーションルール（必須項目、添付、日付ルール）\n- 統合テスト: ワークフロー（ルーティング、承認、通知、SLAタイマー）\n- ユーザー受け入れテスト（UAT）: 実際の申請者と承認者による現実的シナリオでのテスト
UATは主要ワークフローに合わせたチェックリストを作り、作成、編集/キャンセル、承認/却下、再割当、クローズ、（許すなら）再オープンを検証します。
現在スプレッドシートやメールで管理しているリクエストを移行する場合、何をインポートするか決めます（オープン項目、過去90日分、全履歴など）。少なくともインポートするのは: 申請者、カテゴリ、タイムスタンプ、現状ステータス、継続性のために必要なメモ。移行された項目は監査トレイルで明示的にラベル付けしてください。
クローズ時にアプリ内アンケートを追加します（「解決しましたか？」「フォームに問題はありましたか？」）。利害関係者と短い週次レビューを行い、フィードバックを振り分けてバックログを整備します: 信頼性の修正を最優先、使い勝手は次、新機能は最後に。
まずは狭く、かつ件数が多いスコープを選びます（例: ITアクセスリクエスト + 施設修理）。現状の問題点（埋もれるメール、所有者不明、監査トレイルなし）を文書化し、主要ユーザー（申請者、承認者、担当者、管理者）を定義し、測定可能な成功指標（例:「全リクエストは1営業時間以内にオーナーが割り当てられる」）を設定してください。
多くの社内リクエストは次のような繰り返し発生するカテゴリに収まります:
頻度が高く問題になっているカテゴリから開始し、ワークフローが安定してきたら拡張します。
少数で明示的なロールと明確な権限を使います:
仕様書に簡単なRACI表を入れると、所有権や引き継ぎが曖昧になりません。
“悪い”チケットを出しにくくすることに注力します:
これでフォローアップが減り、ルーティングや承認が速くなります。
v1は予測可能でシンプルなルーティングにします:
ルールエディタはシンプルに保ち、実際のパターンを見てから複雑化させます。
まずは単段階承認（マネージャーや予算責任者）で始め、ポリシーで必要な場合のみ承認を要求します。
多段チェーンは、もしそれが主要なリクエストタイプでない限り後回しにします。
小さく共有されたステータスライフサイクルを使い、それぞれの意味を明確にします。例:
誰がどの遷移を行えるかを明記し、ステータス変更・割当変更・承認の監査トレイルを保存して決定の追跡性を確保します。
コアとなる3画面と詳細画面を重視します:
アクセシビリティは最初のワイヤーフレームから考慮します（キーボード操作、色依存しない状態表示、スクリーンリーダー対応ラベル）。
実用的なスキーマ例:
早期に取り入れるべきエンタープライズの基本:
これらがあれば、HR/財務/セキュリティ関連のリクエストが来ても作り直しを減らせます。
users, roles, user_roles, teams, requests, comments, attachmentscategories, form_fields, request_field_valuesapprovals, sla_policiesaudit_eventsrequests(status, created_at)やaudit_events(request_id, created_at)など、よく使うクエリにインデックスを張っておくとキューやタイムラインが高速に動きます。