管理画面を開発することになったとき、どう作ればいいのか分からないかもしれません。管理画面のデザインに関する記事はたくさんありますが、設計については情報が少ないという問題があります。

私はこれまでいくつかのプロダクト開発に携わってきました。そのほとんどが管理画面をもっていました。この経験を元に、管理画面を設計する上でなにを考えればいいかを解説します。また、プロダクトのフェーズにおける管理画面の考え方についても整理します。

この記事を読むことで、管理画面の作り方がよくわからない状態から、どう作りはじめればいいかがわかるようになると思います。

Hiroki Zenigami

テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。

Follow @zenizh

管理画面は、「プロダクトの運用を目的としてデータを管理するための画面」のことをいいます。基本的には運用者のみがアクセスや操作を許されています。管理画面を作る上で、まず「利用者」と「目的」のふたつを押さえておくことが大切です。

管理画面の利用者には、大きく分けると次のふたつの役割がいます。

• 運用者
• ユーザー

ユーザーとは、たとえばブログサービスにおける投稿画面のようなイメージです。この記事では、前者の「運用者」が使う管理画面について書いていきます。

また、管理画面の目的には、大きく分けると次のふたつがあります。

• オペレーションのため
• データ分析のため

この記事ではどちらもふまえますが、どちらかというと前者のオペレーションを目的とした管理画面について書いていきます。

では、管理画面をどう作ればいいのか、なにを考えて作ればいいのかについて書いていきます。これはプロダクトの種類について変わってくるので、ここでは共通する普遍的なことについてまとめます。まず表にまとめて、それからひとつずつ見ていきます。

まず認証をどうするか決めます。GoogleやSlackなどのアカウント連携がよさそうです。どのアカウントを使うかは、組織が利用しているプラットフォームに応じて決めればいいです。あとは、IPアドレスによる制限をかけるなど、他の手段とあわせて認証するとセキュリティが強化されます。

実装がラクだからといって、プロダクト本体のユーザー基盤を利用してしまうと、セキュリティの担保が難しくなったり、管理画面がプロダクト本体と密結合になってしまうので、基本的には避けた方がいいと思っています。

次に認証した運用者の役割によって許可する操作を分けていきます。たとえばアルバイトや業務委託の方など、アクセスしていいデータが変わってくることがあるので、これを分けます。

やり方としては、まず管理画面上の操作の一覧をスプレッドシートなどに書き出し、許可する役割をセットで書いておくことで、実装しやすくなります。テストも書きやすくなります。

管理画面は大切なデータを扱う画面です。不具合があってデータに不整合が起こってしまうと大変なので、当然ですがテストを書きましょう。テストを自動で実行し、不具合を検出できる環境も作っておきます。

誰がいつどんな操作をしたのかを記録します。組織によっては必要になるので、事前に確認しておきましょう。

システムのバグや操作ミスなどでデータが意図しない形になってしまったときに、もとに戻すためにバックアップが必要になってきます。管理画面がなくても必要ですが、念のために項目として書いておきます。

管理画面にどんな機能を作るかを決めていきます。管理画面といっても、通常のプロダクト開発と同じやり方で作ります。つまり、基本的には「それがないと成り立たない機能のみ」を作ります。

作るだけではなく、使わなくなった機能はどんどん消していきましょう。これについては「プロダクトに機能を追加するかどうかを判断する方法」で詳しく説明しています。

体験とは操作をしたときのメッセージ表示やアラートの出し方などです。運用者もユーザーと同じで、マニュアルに書いたところで操作ミスなどは必ず起こります。このミスができるだけ起きないよう、メッセージの出し方やアラートを出す基準を決めましょう。

どんなデザインにするかを決めます。管理画面のデザインにはコストをかけられないかもしれませんが、見た目がよくないと運用のモチベーションに影響してきます。これって結構大切だったりします。CSSフレームワークなどを使って、最低限の見た目は整えるようにしたいです。

機能を作ることは負債であるという認識をもつことが大切です。たとえば分析はRedashを用いるなど、できるだけ外部サービスを利用するようにしましょう。

上で管理画面の設計指針についてまとめました。ただ、管理画面の作り方はプロダクトのフェーズによっても変わってきます。とくに、Product Market Fitの前後で変わります。

PMFをめざしている段階では、日々変化するプロダクトに対応できるよう、オペレーションをまわしていく必要があります。このための開発スピードがなにより大切になってきます。開発スピードを優先するために、管理画面を作るためのフレームワークなどを用いることを検討します。

PMFを達成したということは、ある程度オペレーションが固まったことを意味します。この段階では長期的な運用を見据えて、自前で管理画面を作ることを検討します。

PMFをめざす過程では機能の追加・削除が繰り返されると思います。汚くなった機能やソースコードを一度整理するのもこのタイミングがよさそうです。

管理画面は、基本的にはプロダクトと同じです。ユーザー=運用者が抱える課題を解決するために、管理画面を作ります。このため、誰が運用者なのか、運用者はなにを解決したいのか、どう解決するのかを、ひとつひとつ検証しながら作っていくべきです。

つまりリーンスタートアップの考えに基づいて作っていきます。もちろん、一度作って終わりではなく、継続的に開発していく必要があります。

管理画面は主にオペレーションのために運用者が使う画面です。運用者をユーザーととらえ、リーンスタートアップの考え方に基づいて作っていくことで、よりよい管理画面になっていきます。管理画面を作るときはプロダクトのフェーズに応じた作り方をすることで、小さいコストで作っていけます。

プロダクト開発

【2023年】エンジニアの本でおすすめの5冊を紹介します

2023-4-2

働き方

エンジニアの転職で登録したい7つの転職サイトと転職エージェント

2022-12-30

働き方

エンジニアの副業で登録したい5つのサイトやサービス【フリーランス】

2022-12-30