管理画面を作る際に考えること
特性
複雑な業務フローを体現していたり
ohbarye.icon BPMNでフロー定義すると便利ぽい どんなに利便性が低くても業務遂行においては使わざるを得ないため
製品やサービスに大きく依存するが、改善することで間接的な事業貢献をすることが説明しやすい
カスタマーサポートとして、24時間以内に返答するためにはテンプレート機能が必要、パフォーマンス改善が必要 etc. 営業として、契約数を伸ばすためにはレポート機能が必要 etc. 可視性を制御しなければならない機密情報・個人情報を扱うことがある
技術
業務の機能要件を満たせばなんでも良い事が多い
攻める場合
エンドユーザーにいきなり新技術を投入するのでなく管理画面で素振りをする
守る場合
一番慣れた技術で安定して速度を出す
障害が起きてもエンドユーザー向けシステムに影響を与えない
重要性
事業に大きく依存するので一概にいえない
「自分たちの事業にとってこのバックオフィスシステムはどれほど重要なのか」を予め議論しておくのは大事
FOLIOの例
管理画面と呼ぶのをやめる
管理画面のあやうさ
誰が何のために使うのかあいまいになりがち
事業拡大に伴い、気付くと利用者が増えており、どうしようもないモノリスになっている可能性 営業向け機能をいじったらCSが相乗りして使っていた機能だったので困ったとか
権限制御があとからスコープに入ることで漏れが生まれるとか
重大なコンプライアンス違反の可能性もある
「管理画面」は責務ではない
画面、ツールという言葉からもわかるように、これは ユーザインターフェイスです。それ単体で、なにか責務のまとまりになっているというわけではありません。
管理画面と呼ぶのを止め、適切な名前を付ける
管理画面という名前が責務の曖昧さを生む
たとえ全ステークホルダーが使うものであっても「何のために使うか」「何のために変更されるか」が明瞭で名前によって表現できていれば上述のような課題はうまれにくくなる
ただしめっちゃ難しいし実質不可能と思う
管理画面という名前がダサいし軽視されがち
管理画面が止まったら顧客体験を損なう、というシーンもあるはず
だとしたら顧客に提示するサービスと同等かそれ以上に重要なシステムである
各ステークホルダー向けのシステムとして設計する
システムコンポーネントを作る時に関心の分離や単一責任を考慮するのと同様に考え、適切に分離する 営業向けシステムとカスタマーサポート向けシステムは本当に同じでよいのか?
同じ「データ」を違う目的で見るなら、システムはそれぞれの目的に見合った「情報」に加工して表示しなければならない
怠った時に生まれる運用でカバーの例
「この値はこう表示されてるけどこれは営業向けだから、こう読み替えて」
誤ったオペレーションの可能性
「この機能は我々は使わないから無視して」
使いづらいUI
膨大なマニュアル(使い方の説明書)
調整コストの削減
「ある機能を変更・削除するとき、複数ステークホルダーに問い合わせなければ意思決定できない」をなくす 「ある機能を追加するとき、複数ステークホルダーに問い合わせなければ意思決定できない」をなくす
権限制御が絡む場合、全ロールに確認が必要
結局同じで良かった、とならないか?
似たものを同じものとして扱うことによる設計の失敗よりも、同じかもしれないものを分離した設計の成功のほうが多い
マイクロサービスにおける管理画面
参考