管理画面開発の進め方：業務に合わせた画面と権限の設計手順

管理画面の開発というと、データベースにある情報を一覧で表示し、検索して、詳細を開いて編集できる画面を思い浮かべる方が多いかもしれません。もちろんそれも必要ですが、データを見る画面を並べただけの管理画面は、実際の運用ではあまり役に立ちません。運用担当者が知りたいのは「データの中身」ではなく「今日、自分が何を処理すればよいか」であり、やりたいのは「データを編集すること」ではなく「申し込みを承認する」「問い合わせに回答する」「返金を処理する」といった業務だからです。

管理画面の開発を成功させる要点は、運用担当者の作業フローから出発することです。誰が、どんなきっかけで、どの情報を見て、何を判断し、どんな操作をするのかを洗い出し、その流れに沿って画面と操作を設計します。そのうえで、担当者の役割に応じた権限と、誰が何をしたかを追える操作ログを組み込みます。

この記事では、業務に合わせた管理画面を設計・開発するための手順を、作業の洗い出し、画面の設計、権限の設計、操作ログ、開発の進め方の順に解説します。自社サービスや業務システムの管理画面を企画する担当者、開発会社に管理画面の開発を依頼する方に向けた内容です。

管理画面が「使われない」理由

管理画面を作ったのに、運用担当者が使わずに表計算ソフトや手作業に戻ってしまう、という話は珍しくありません。その理由の多くは、次のどれかに当てはまります。

• 作業の起点がない：一覧画面はあるが、「今日処理すべきもの」がどれか分からない。結局、担当者が別の表で管理している
• 画面を行き来しないと作業が終わらない：1件の処理のために、会員の画面、注文の画面、問い合わせの画面を順に開く必要がある
• 一括で処理できない：同じ操作を何十件も1件ずつ行う必要がある
• 判断に必要な情報が足りない：承認するかどうかを判断するのに、別のシステムや資料を確認しなければならない
• 間違えたときに戻せない：誤って操作すると元に戻せないため、担当者が操作をためらう
• 権限が粗すぎる、または細かすぎる：全員が何でもできてしまう、あるいは必要な操作ができずに上長に頼む必要がある

これらはどれも、データの構造から画面を考え、運用担当者の作業から考えていないことが原因です。管理画面は社内の人しか使わないため、顧客向けの画面に比べて後回しにされ、開発の終盤に「とりあえずデータを見られる画面」として作られがちです。しかし、サービスの運用が回るかどうかは管理画面の出来に大きく左右されます。顧客向けの画面と同じように、使う人と作業から設計する価値があります。

手順1：運用担当者の作業を洗い出す

最初の手順は、管理画面を使う人と、その人が行う作業を洗い出すことです。次の項目を表にまとめていきます。

この洗い出しは、担当者に話を聞くだけでなく、実際の作業を横で見せてもらうのが効果的です。担当者自身が当たり前だと思っている確認作業や、別の表で管理している情報が見つかることがよくあります。洗い出した作業は、業務フロー図にしておくと、関係者で認識をそろえやすくなります。

作業に優先度を付ける

洗い出した作業すべてを、最初から管理画面で実現する必要はありません。次の観点で優先度を付けます。

• 頻度と件数が多く、手作業の負担が大きい作業
• ミスが起きると顧客や売上への影響が大きい作業
• 現在、エンジニアがデータベースを直接操作して対応している作業
• 担当者が増えたときに、属人化して回らなくなる作業

逆に、頻度が低く、件数も少ない作業は、当面は手作業や既存のツールで対応し、管理画面には入れない判断もできます。新規事業の初期段階での考え方は、MVPの管理画面は最小限でよいかでも詳しく解説しています。

手順2：作業フローに沿って画面を設計する

作業の洗い出しができたら、作業ごとに画面と操作を設計します。ポイントは、データの種類ごとに画面を作るのではなく、作業ごとに必要な画面を考えることです。

作業の起点となる画面をつくる

運用担当者が管理画面を開いて最初に見るのは、「今、自分が対応すべきもの」の一覧であるべきです。たとえば、承認待ちの申し込み、未回答の問い合わせ、決済に失敗した会員、期限が近い案件などを、担当者ごとに表示します。件数と、期限を過ぎているものが一目で分かるようにすると、対応漏れを防げます。

1つの画面で判断と操作が完結するようにする

申し込みを承認する画面であれば、申込内容に加えて、その人の過去の利用履歴、本人確認の結果、決済の状況など、判断に必要な情報を同じ画面にまとめます。承認・差し戻しのボタンも同じ画面に置き、差し戻しの場合は理由を選んで入力できるようにします。

一括処理と絞り込みを用意する

同じ操作を多数の件数に行う作業には、一覧から複数件を選んで一括で操作する機能を用意します。一括処理は便利な反面、誤操作の影響も大きいため、実行前に対象件数と内容を確認する画面を挟みます。

状態の変化と次の作業をつなげる

承認したら申込者にメールが届き、次の担当者の一覧に表示される、といったように、操作の結果として次に何が起きるかを設計します。業務の状態（受付・確認中・承認済み・差し戻し・完了など）を決めておくと、画面の設計と処理の流れがそろいます。

画面の数が多くなる場合は、画面遷移図を描いて、作業ごとにどの画面をどの順で使うかを確認しておくと、無駄な行き来を減らせます。

画面設計の判断基準

手順3：権限と操作ログを設計する

担当者の役割に応じた権限

管理画面は、顧客の個人情報や売上、サービスの設定など、重要な情報と操作を扱います。誰でもすべての操作ができる状態は、誤操作や情報の持ち出しのリスクを高めます。

権限は、手順1で洗い出した担当者と作業をもとに設計します。担当者の役割をロールとして定義し、ロールごとに「見られる情報」と「できる操作」を決めます。

• カスタマーサポート：会員情報と問い合わせの閲覧・回答。返金の申請はできるが、実行はできない
• 経理：決済と請求の閲覧、返金の実行、売上の出力
• 商品担当：商品情報の登録・更新。会員の個人情報は閲覧できない
• 運用責任者：すべての閲覧と、承認が必要な操作の承認
• システム管理者：管理者アカウントの追加・停止とロールの変更

このように、重要な操作を「申請」と「実行」に分け、別の担当者が行うようにすると、誤操作や不正を防ぎやすくなります。権限の具体的な決め方は管理画面の権限設計で詳しく解説しています。

操作ログと取り消しの仕組み

管理画面での操作は、顧客の情報や売上に直接影響します。誰が、いつ、何を変えたのかを後から確認できる操作ログは、トラブルの原因調査や、顧客への説明、社内の監査に欠かせません。

操作ログには、操作した担当者、日時、操作の種類、対象のデータ、変更前と変更後の値を記録します。特に、個人情報の閲覧や出力、返金、権限の変更、設定の変更といった重要な操作は、必ず記録します。詳しい設計の考え方は管理画面の操作ログ設計でまとめています。

あわせて、誤操作から回復できる仕組みも検討します。

• データの削除は、すぐに消さず「削除済み」の状態にして、一定期間は復元できるようにする
• ステータスの変更は、直前の状態に戻せるようにする
• 一括操作の前に、対象件数と内容を確認する画面を挟む
• 顧客にメールが届くなど、取り消せない操作の前には、その旨を明示する

担当者が「間違えても戻せる」と分かっていると、操作をためらわずに済み、作業の速度も上がります。

手順4：開発の進め方

画面と権限の設計ができたら、開発に進みます。管理画面の開発は、次の進め方をすると手戻りが少なくなります。

1. 優先度の高い作業から作る：手順1で付けた優先度の高い作業の画面から開発し、早い段階で担当者に使ってもらう
2. 既製の部品やテンプレートを活用する：一覧、検索、フォーム、権限の管理など、管理画面に共通する部品は、既製のテンプレートやフレームワークを使って開発量を減らす
3. 本物に近いデータで試す：架空のデータでは気づかない、件数の多さや例外のパターンを、本物に近いデータで確認する
4. 担当者に実際の作業を行ってもらう：画面を見せて意見を聞くだけでなく、実際の作業を一通り行ってもらい、迷った箇所、時間がかかった箇所を記録する
5. 並行運用の期間を設ける：既存の作業の方法から切り替える際は、一定期間は並行して運用し、問題がないことを確認してから切り替える
6. 公開後も改善を続ける：担当者からの要望と、作業時間の変化を定期的に確認し、改善を続ける

管理画面は、顧客向けの画面に比べてデザインの作り込みは少なくて済む一方、業務の理解と細かな使い勝手が成果を左右します。担当者が開発の初期から関わる体制を作ることが、最も重要なポイントです。

既存のツールとの役割分担を決める

管理画面ですべてを完結させようとすると、開発の範囲が際限なく広がります。問い合わせの管理はヘルプデスクツール、売上の集計はBIツール、社内の連絡はチャットツールといったように、既存のツールに任せる部分と、管理画面で行う部分の線を引いておくと、開発すべき範囲が明確になります。

線を引く際の目安は、「自社サービスのデータを変更する操作は管理画面で行い、閲覧・集計・連絡は既存のツールでもよい」という考え方です。データを変更する操作を外部のツールから直接行うと、権限の管理や操作ログが二重になり、どこで何が変わったのか追いにくくなるからです。

また、管理画面の操作をきっかけに、チャットツールへ通知を送る、表計算ソフトに出力する、といった連携を用意すると、担当者の作業の流れを大きく変えずに管理画面を導入できます。新しい管理画面への移行は、担当者にとって負担になりがちです。既存のツールと組み合わせて、無理なく使い始められる形を考えることも、設計の一部です。

具体的な場面で考える：申し込み審査の管理画面

架空の例で考えます。あるサービスでは、利用の申し込みを受けると、担当者が申込内容と提出書類を確認し、問題がなければ承認して利用を開始してもらう流れになっていました。管理画面には申し込みの一覧と詳細の画面がありましたが、担当者は申し込みの状況を別の表計算ソフトで管理し、提出書類はメールで確認していました。

作業を洗い出すと、担当者は毎朝メールと管理画面を見比べて新しい申し込みを表に転記し、書類を開いて確認し、承認するときは管理画面でステータスを変更してから、申込者に手作業でメールを送っていました。書類に不備がある場合は、申込者とのメールのやり取りを表に記録していました。

この流れをもとに、管理画面を作り直しました。最初に開く画面を「対応待ちの申し込み」の一覧にし、受付からの経過日数を表示します。詳細画面には申込内容と提出書類、過去の申し込み履歴をまとめ、承認と差し戻しのボタンを置きました。差し戻しの理由を選ぶと、定型の文面で申込者にメールが送られ、ステータスが「書類待ち」に変わります。書類が再提出されると、再び対応待ちの一覧に表示されます。

これにより、表計算ソフトへの転記と手作業のメール送信がなくなり、対応漏れもなくなりました。データの構造自体はほとんど変えておらず、変えたのは「作業の流れに沿った画面と操作」だけです。

よくある失敗と避け方

データの種類ごとに画面を作る

会員、注文、問い合わせといったデータの種類ごとに一覧と詳細の画面を作るだけでは、作業のたびに画面を行き来することになります。作業ごとに必要な情報を1つの画面にまとめます。

運用担当者が開発に関わらない

要件を決めるのが企画の担当者だけで、実際に使う運用担当者が開発の終盤まで画面を見ないと、使いにくい点が公開直前に大量に見つかります。初期から担当者に試してもらいます。

権限を後回しにする

最初は全員が管理者として何でもできる状態で始め、後から権限を分けようとすると、すべての画面と操作を見直すことになります。少ないロールでもよいので、最初から権限の仕組みを組み込みます。

例外のパターンを想定していない

正常な流れだけを想定して作ると、二重の申し込み、情報の不足、期限切れといった例外が起きたときに、結局エンジニアがデータベースを直接操作することになります。手順1で例外を洗い出し、管理画面で対応できるようにします。

検索性能と件数の増加を考えていない

公開時点では数百件だったデータも、運用を続けると数万件、数十万件に増えていきます。一覧の表示や検索、ファイルの出力が、件数が増えるにつれて遅くなり、担当者の作業が止まる原因になります。設計の段階で、数年後の件数を見込み、一覧には期間や状態での絞り込みを標準で用意し、大量の出力は画面とは別の処理で行う、といった対策を入れておきます。

開発前のチェックリスト

• 管理画面を使う担当者と、その作業が一覧になっている
• 作業ごとのきっかけ、頻度、判断に必要な情報、操作、例外が書き出されている
• 作業に優先度が付き、最初の版で実現する範囲が決まっている
• 担当者ごとの「対応すべきもの」の一覧画面が設計されている
• 1件の処理が1つの画面で完結するように、判断材料がまとめられている
• 担当者の役割に応じたロールと、見られる情報・できる操作が決まっている
• 重要な操作の操作ログと、誤操作から回復する仕組みが決まっている
• 担当者が開発の初期から試せる体制がある

よくある質問

Q. 管理画面は既製のツールで済ませられませんか？

データの閲覧と簡単な編集が中心であれば、データベースの管理ツールや、管理画面を素早く作れるツールで済ませられる場合があります。業務の流れに沿った画面、権限の細かな制御、操作ログが必要な場合は、開発が必要になることが多いです。費用の比較は管理画面の開発費用で解説しています。

Q. 管理画面のデザインはどこまで作り込むべきですか？

見た目の美しさより、情報の見やすさと操作の迷いにくさを優先します。既製のテンプレートや部品を使えば、一定の見やすさは確保できます。担当者が長時間使う画面では、文字の大きさや情報の密度、キーボードでの操作のしやすさが作業の効率に影響します。

Q. 既存の管理画面を改善するには、どこから始めればよいですか？

担当者の作業を横で見せてもらい、時間がかかっている作業、別のツールで補っている作業、エンジニアに依頼している作業を洗い出すことから始めます。その中で頻度と影響の大きいものから改善すると、効果を実感しやすくなります。

Q. 管理画面の開発期間はどう見積もればよいですか？

画面の数よりも、作業の数と複雑さ、権限の細かさ、外部との連携の有無で決まります。作業の洗い出しと優先度付けができていれば、範囲を絞った見積もりが取りやすくなります。

Otsumuに相談できること

管理画面を使う担当者が少なく、作業もデータの確認と簡単な編集が中心であれば、既製のツールや管理画面のテンプレートを使って、社内のエンジニアで十分に作れます。この記事の手順1の作業の洗い出しだけでも、何を作るべきかがはっきりするはずです。

一方で、運用担当者が増えて作業が回らなくなっている、エンジニアがデータベースを直接操作して例外対応をしている、権限や操作ログを求められているが今の管理画面では対応できない、といった状況では、業務の整理と画面の設計を一緒に行える外部の力を借りると、短期間で改善できます。

Otsumuは、自らも事業を手がける立場から、運用担当者の作業の洗い出しと業務の整理を出発点に、管理画面の設計・開発・運用改善まで一気通貫で支援しています。目的から逆算して必要な画面と操作に絞り、AIを活用した開発で少人数・短期間で形にします。支援内容は管理画面開発のページでご覧いただけます。運用作業そのものを減らしたい場合は、自社サービス運用の自動化コンサルティングもあわせてご検討ください。

「今の管理画面のどこから直すべきか」といったご相談も歓迎しています。まずは30分の無料相談でお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01