目的
Mini ITSM Board は、ITILの考え方に着想を得て、インシデント管理・問題管理・変更管理の流れを小さく体験できるようにした静的Webアプリです。
目的は、本格的なITSMツールを作ることではなく、業務アプリに必要な情報構造や画面遷移を、ポートフォリオ上で確認できるプロトタイプとして形にすることです。
単なるCRUDアプリではなく、インシデントを起点に、問題管理や変更管理へつながっていく業務上の関係性を表現することを重視しました。ITILそのものを厳密に実装するのではなく、業務フローの考え方を伝えられる小さなWebアプリとして制作しています。
制作方針
制作方針は、静的Webアプリとして公開できる範囲で、業務管理アプリらしい構成を作ることです。
バックエンド、認証、データベースは持たず、データ保存には localStorage を使用しています。これにより、ConoHa WING上に静的ファイルとして配置でき、公開・確認・修正のサイクルを軽く保てる構成にしました。
また、インシデント、問題、変更という関係性が決まりやすい領域を題材にすることで、限られた画面数でも業務アプリとして自然なデータのつながりを見せられるようにしました。実装支援としてCodex CLIも活用し、業務アプリ系の要件を大きめの単位で渡したときに、どの程度まとまった画面構成や操作性まで作れるかも確認しています。
制作時に意識したこと
制作時には、見た目だけの管理画面ではなく、インシデント・問題・変更の関係性が画面上で分かることを意識しました。
インシデントを登録し、必要に応じて問題へエスカレーションし、さらに変更へつなげる流れを、データと画面の両方で表現しています。加えて、ユーザーやサービスの管理画面も用意し、業務アプリとしての背景情報が見える構成にしています。
実装はCodex CLIに要件を渡して進めました。完成後は、確認観点を整理し、自動テスト、lint、buildの結果や懸念点を確認したうえで、優先度の高い修正のみを反映しました。最終的なローカル確認と公開判断は人間側で行っています。
今回の試行では、ITILという既存の業務文脈を指定することで、比較的短い指示でも有効なコンテキストを渡せる感覚がありました。一方で、今後はさらに曖昧な依頼や、逆に要件定義・設計を細かく与えた場合との違いも比較したいと考えています。
構成
- Dashboard
- オープン中のインシデント数、優先度の高いインシデント数、調査中の問題数、承認待ち変更数などを表示
- Incidents
- インシデントの登録、編集、ステータス管理、問題・変更への関連付け
- Problems
- 問題の登録、根本原因、回避策、既知エラー、関連インシデントの管理
- Changes
- 変更の登録、リスク、影響、承認状態、予定日時、実施結果の管理
- Users
- 報告者、担当者、承認者などに使うユーザー情報の管理
- Services
- 対象サービスと重要度の管理
- Data Management
- JSONエクスポート、JSONインポート、サンプルデータリセット、全データ削除
- localStorage
- ブラウザ内にデータを保存し、リロード後も状態を保持
- ConoHa WING
- Viteのbuild成果物を静的ファイルとして配置
学び
今回の制作では、業務アプリの要件を小さな静的Webアプリに落とし込むことで、画面構成、型定義、サンプルデータ、保存処理、READMEまで一貫した形で整理できることが分かりました。
特に、ITILという既存の業務フレームワークを参照したことで、インシデント・問題・変更といった概念の関係性を短い説明で共有しやすくなりました。業務アプリのように構造がある程度決まっている題材では、AIコーディングツールに任せられる範囲も広いと感じました。
一方で、AIが作ったものをそのまま公開するのではなく、確認観点の洗い出し、優先度付け、修正判断、ローカル動作確認、公開判断は人間が担当する必要があります。実装を任せることと、成果物として出せる状態かを判断することは別の工程だと感じました。
また、Viteアプリをサブディレクトリに公開する場合は、base path の設定と、dist フォルダではなく dist の中身をアップロードする点が重要でした。静的Webアプリであれば、ConoHa WINGでも十分に公開できることを確認できました。
今後
今後の改善案としては、SLA管理、コメント・作業ログ、承認ワークフロー、ナレッジ管理、CMDB、権限制御、バックエンドDB化などが考えられます。
ただし、このProjectでは本格的なITSMツールを作ることよりも、業務アプリの構成をポートフォリオ上で確認できる範囲にまとめることを重視しました。そのため、まずは静的Webアプリとして公開できる範囲に絞っています。
今後は、より曖昧な依頼でも同程度の成果物ができるのか、逆に要件定義や設計を細かく与えると品質がどの程度変わるのかを比較したいです。また、業務アプリだけでなく、ゲーム系の制作でも同じようにざっくり依頼できるのかを試してみたいと考えています。