UNIX的なアレ

UNIX的なこととかいろいろ

管理画面と業務フロー

最近また管理画面に近いものをつくったりしていて感じたのですが、事業会社において管理画面がどのタイミングで実装されているかというのがすごく重要だなと感じたのでちょっと書いてみようと思います。

社内向けの管理画面の実装って割と後に回りがちで、最後に仕方なくなんとか実装するようなケースが多いと思うんですよね。そして、ある程度発生してきたオペレーションの実態に合わせて実装するみたいな流れになるのではないかなと。

それはそれで一つの実装の手法だと思うのですが個人的には逆のほうが良いのではないかなと思っています。

管理画面からオペレーションを設計する

まず、以下の理由から管理画面ありきでオペレーションを設計したほうが良いと思っています。

  • 既存のオペレーションありきで管理画面の要件を出すため、イノベーションがうまれづらい
  • 組織の最適化より管理画面の最適化のほうが合理的に行える
  • エンジニアの合理的な思考がオペレーション設計に向いている

まず管理画面を実装するということは社内のオペレーションを定義することになります。そのため、社内向けの管理画面をある程度作り込んでおくと、それに従って社内の業務フローができあがります。その上で実態と異なる部分を調整していくくらいが良いかなと思います。

管理画面こそクリエイティビティの発揮場所

サービスの仕様から、このあたりは社内の作業で編集したりするかな、いろいろと業務フローについて考えながら実装したりするのが管理画面だったりします。

特に新しい機能だったりするとそれに関わるオペレーションの人もいないため、当然ヒアリングすらできません。だからこそエンジニアが考えるべき部分ですし、そこの工夫がサービスの成長に寄与できるんじゃないかなとも思っています。

新しいサービスのKPIを正しく理解し、それに付随するだろう社内オペレーションを想像し、それを効率よく行えるための実装をするというのが理想的な流れですね。

管理画面を通じて表現される運営方針

また、管理画面を実装する上で作られる制約がそのサービスの運営方針にも直接的につながることもありただ機能として実装されていればいいというわけでもなかったりします。

たとえばすべての情報を閲覧・編集できるのではなく、ある種の制限などをつけておくことが、サービスの運営方針につながるということもあります。

社内向けの管理画面という意味からは少しズレますが、mediumの記事投稿画面なんかはわかりやすい例かなと思います。文字色の変更や文中における不要な文字サイズの変更などは許可しておらず、あくまで情報を伝達するメディアとして読みやすい表現に制限している。

こういった理由のある制限などはまさに管理画面でこそ実装されるべきもので、これによってサービスの運営方針や本来の使い方を感じることができます。

というわけで

管理画面をオマケとして考えるんじゃなくて、前のめりに自分からガシガシつくっていってほうが良いんじゃないかななんて思います。当然つくって終わりではないので実態に合わせて進化し続ける必要はあるわけで、その都度最適なものに作り直すくらいのスタンスが良いんじゃないかなぁなんて思っています。

以前に書いた記事です。新規サービスの立ち上げのときにはこちらも。

wadap.hatenablog.com