管理画面を作るときに気をつけていることを雑に書いてみる。
作らない
管理画面に限らずですが「作る」と 初期開発＋保守（不具合修正・機能追加/変更・FWアップグレード・認知負荷） のコストかかります。時間は常に足りないものなので、モノづくりをせずにスマートに解決できる方法があればそれを選択すべきです。
例えば「データを閲覧・分析したい」といった要件であれば管理画面で閲覧するのではなく、Metabase、Redash、Looker StudioなどのBIツールを使うことで作らずに要件を満たすことが出来ます。これらのBIツールは非エンジニアでも扱えることが多いため、作るためのコミュニケーションコストを削減できることもメリットです。 また、そもそもの要件や運用を見直すことで解決できる課題も多く、そのためには要件・ビジネスの深い理解と広い引き出しが必要になってきます。
低頻度の要件であれば手順書を残した上であえて手動で対応することも検討すると良いです。例えば年１回の１時間の作業であれば、プログラムを実装・運用するコストよりも安くなるケースもあると思います。ただし手順書が複雑、あるいはセンシティブな操作を含む場合は自動化する範囲を限定して実装するなど柔軟に対応できるとベターです。
SSOな認証を入れる
認証基盤をちゃんと作るには「登録」「ログイン」「パスワード変更」「パスワード忘れ」などの機能を作る必要があります。SSOな認証が入れられるケースだと「登録」「ログイン」のみ実装すればよいので保守性・管理性が良くなります。退職時などユーザを無効化したい場合はSSOのIdP側が無効化されれば、管理画面側もログインできなくなるので運用面においても簡単・安心です。（とはいえ、無効化する処理や運用もセーフティネットとして持っておいたほうが良いと思います）
OIDC連携できるOSSも数多くありますし、Google CloudのIAPのようにインフラレベルで対応しているケースもあるので、比較的工数をかけずに実装ができます。
証跡を残す
管理画面はマスタ管理や個人情報閲覧など重要な操作が含まれることが多いです。データの「変更」だけではなくデータの「閲覧」「ダウンロード」も重要な操作の１つです。
セキュリティインシデントなど何か障害が発生した場合に、アクセスログは重要な証跡で、セキュリティインシデントにおいては「何かをした」ことだけではなく「何もしていない」の根拠になるのは非常に心強いです。そのため管理画面には必ずアクセスログを残しておきましょう。
内容としては最低限以下の情報を含めておくと良いです。
- timestamp（いつ）
- 管理者ID（誰が）
- HTTPメソッド（どうした）
- エンドポイント（何を）
ただし、個人情報はログに残さないように気をつけてください。
パーマリンクなURL設計
不具合報告、変更依頼などのコミュニケーションにおいて、具体的なURLベースでやりとりできると認識齟齬が減ったり調査がしやすくなります。基本的には参照系のリクエストはGET、更新系のリクエストはPOST(APIではPUT/PATCH/DELETEも含む)にするのを意識してURL設計してもらえれば基本的に問題ないです。
例えば一覧検索が POST https://example.com/search という感じで、参照系の処理をPOSTにするとURLに検索条件が入らないため、URLだけでは どのパラメータを指定してアクセスしたのか の情報が落ちてしまいます。また一覧・検索系の画面ではURLパラメータを残すことで指定の検索条件をブックマークできるメリットもあります。
シンプルで統一されたUI/UXにする
パーマリンクのところと通じるところがありますが、マスタ管理系であれば以下の画面をベースにするとUI/UXが統一されて良いです。
| 機能 | エンドポイント |
|---|---|
| 一覧（検索含む） | GET /entity |
| 新規作成画面 | GET /entity/create |
| 詳細画面 | GET /entity/{id} |
| 編集画面 | GET /entity/{id}/edit |
| 新規作成処理 | POST /entity |
| 更新処理 | PUT /entity/{id} |
| 削除処理 | DELETE /entity/{id} |
Laravelには resource というルーティング定義やscaffoldがあるのでそちらを利用すると良いです。
要件によっては詳細画面が不要（編集画面で十分）なケースや、新規作成はエンジニアが手動でDB INSERTし、管理画面上は更新のみでOKといったケースもあると思うので、そのあたりはケースバイケースで。
ただ、UIを変えると開発者も利用者も認知負荷や考慮事項も増えがちなので、そのあたりは仕様を慎重に検討していくとよいかと思います。JavaScriptも開発の認知負荷を上げる要因にもなるので必要最小限の利用に留めると良いです。
利用環境を制限する
フロントエンドではブラウザごとの差分があるため、可能であれば利用ブラウザなどを制限できると良いです。例えばChromeの最新版を使う、といった制限を行うことでブラウザ間の互換性を気にしなくても良いのに加え、JSの最新の機能を使えたり、そもそもJSを書かなくてもHTML/CSSだけで対応できるようなケースも増え、工数削減や保守性の向上を見込めます。また、トラブルシューティングの際も同一ブラウザで検証できるため、対応コストが低くなります。
ヘルプ・説明を入れる
複雑な操作・危険な操作はヘルプ・説明を入れておくと安心です。 画面上部やツールチップなどでメッセージを表示しても良いですし、 wikiのURLを貼っておけば、ヘルプの更新性が上がるためオススメです。ドキュメントは基本読まれないので、管理画面の機能とリンクさせておくことで読まれやすくして、トラブルが発生したときなどでドキュメントに辿りやすくするという仕掛けにもなっています。
危険な操作には確認を入れる
JSのconfirm()や確認画面を入れておくと比較的安心です。
代理ログイン
権限系のテストを簡単に行えるように、代理ログイン（他のユーザになりすましてログイン）する機能を開発環境に入れたりすることがあります。ロール・属性操作で簡単に検証できることもあるので入れなくても十分なこともある。
使って、課題を発見して、改善しつづける
管理画面を実際に操作したり使ってみて、使いやすくするためのUIを考えてみて、常に改善しつづけていくことが大事です。使いやすさ以外にも、ミスオペが発生しやすい構造になっていないか、セキュリティ的に問題ないか、開発や確認がしづらくないか、など非機能要件にも気を配れると良いと思います。