画面設計の思い出
お疲れさまです、みやもとです。
先日、OSAKA ENGINEER NIGHTというイベントに参加しました。
ネクストライブ株式会社が運営しているエンジニア交流イベントで、初回の参加から大変楽しかったので以降しばしばお邪魔しています。
このイベントは前半にLTをやったあと後半の交流会で個々に交流を深めるようにと構成されています。
地味に人見知りするため交流系イベントではそっと壁際退避していることも多いみやもとですが、何度も参加させていただいているのとほかのイベントでもよく顔を合わせる方が増えてきたからか、今回は比較的いろんな方とおしゃべりすることができました。
さておき、前半のLT3本はいずれもおもしろいお話だったのですが、中でも興味深く聞いたのは最初に発表されたUIデザインに関するLTです。
ネクストライブさんとこのデザイナー・えなさんから「UIデザインについてエンジニア側から意見されることがほとんどなかった。意見を出し合うことでより良い画面になると思うし、エンジニアとデザイナーがお互いに思ったことを言い合えるとチームとして一体感も生まれる」というような感じの内容でした。
「なるほど」と感心すると同時、今まで参画した案件における画面デザイン決定の流れをふと思い出して、なんかちょっと書いておきたいなというのが今回の記事です。
画面設計について振り返る
まず最初に、私が今まで参画してきた案件はほぼほぼ業務系システムの開発案件です。
ほとんどは既存システムの部分改修か別基盤への移行でした。
業務系システムとは
この記事を書くにあたり、念のため「業務系システム」の定義を検索してきました。
以下はレバテックの記事から引用です。
業務系システムとは、企業活動の特定の機能を効率化するITシステムのことです。大きく分けて「基幹システム」と「周辺システム」があり、生産管理システムや在庫管理システムなどの企業の主要業務を支えるものを基幹システム、名刺管理システムやCRMなどの個別の課題解決のために使うものを周辺システムとよびます。
別名として「基幹系システム」「基幹業務システム」と呼ばれることもあります。また、金融業界では「勘定系システム」という呼称が使用されることもあるようです。
業務系システムは、その名の通り企業内の業務に直接的に関わり、あらゆる物事を円滑に進めるための重要な役割を担います。それ故に、業務系システムが停止してしまったり、誤作動してしまったりすると、企業全体の業務に支障をきたすおそれがあります。そのようなことが起きないように、特に細心の注意を払う必要があるシステムだといえるでしょう。
私の案件に限って言うと、上記に加えて「公開範囲が特定企業の社内に限られるシステム」という感じでした。
たとえば保険会社なら、保険契約者が直接操作する申込画面とかではなく、契約者から申込書を受け取った社員が入力するために使う画面の方ですね。
では、そんな感じの業務系システム開発で、みやもとは画面システムとどんな感じに関わってきたでしょうか。
デザイナーが居ない
社内の人しか使わない画面だからなのか、ある程度元になる画面が存在しているせいなのか。
過去参画した案件ではデザイナーさんと一緒にお仕事する機会がありませんでした。
じゃあ誰が画面デザインするの？という疑問を抱かれる方が居るかどうかはわかりませんが、答えはエンジニアがほかの設計と一緒にやります。
私が経験した案件に限っては全部そんな感じでした。
「移行前と同じ」は無理？
大抵の場合、要件定義や設計の段階で聞くユーザーさん側からの一番大きな要望は「今使っているシステムと同じように動くこと」です。
これは内部の処理に限らず、画面の項目配置やボタンをクリックした後の表示内容も対象に含まれます。
ただし何もかもを同じにしていれば大丈夫というわけではなく、「今までの画面で不便だったところは便利になるように変更してほしい」という希望もあわせて検討することになります。
また、今動いているシステムが抱えている何らかの問題（それが無ければそもそも案件自体が不要）については解消する必要があります。
現在のシステムが抱えている問題を解消する→案件の起点なのでマスト
現在のシステムで不便なところを直す→予算の範囲でいけそうならOK
上記1.2.を除き今まで通りになるようにする→変える理由がないのでOK
こんな感じの優先順位で画面設計書を作成するのですが、これがすんなりとはいかない。
まず1.について、例えば移行前は別のシステムに分かれていたものをまとめて処理できるようにして、画面にも表示項目をその分増やす対応が必要だったとします。
この時点で画面は「移行前と同じ」にはなりません。
また、移行先システムのフレームワークやウィンドウサイズの都合により、メッセージの表示場所とか表示のタイミングとか、ちょっとした違いが出てきます。
なるべく違和感を覚えないように頑張りはするのですが、開発側が「これぐらいならそこまで変わらないだろう」と思うような違いも実際に日常業務で使うユーザーさんには大きいのでしょう。
「今までと同じところに表示してほしい」と問い合わせが来ます。
次に2.について、設計時点で要望があれば開発側もそれを取り込んで画面を作ることは可能です。
ただ、「便利」「不便」の感覚には個人差があり、どこまでそれを取りまとめて要望が出ているかというところはわかりにくいところがあります。
設計時点で聞いていた要望に対応したらユーザーテストの段階で「前と同じようにしてほしい」と問い合わせが出てきて、変更要望元との調整した結果やっぱり移行前のシステムと同じになるように変更する…というのもまぁあります。
最後に3.についてですが、これは移行前後のシステムがどういう前提で導入されたかが結構大きく影響すると思います。
特に「パッケージソフトをカスタマイズして使っていたが社内で使っている別のサービス基盤に移行してほしい」とか、移行前後のシステムがそれぞれ別の制約に従って作られている場合は移行前後でユーザーさんの違和感も大きくなりがちな印象です。
移行後システムの設計規約に従って作ったら「移行前の方が便利！」と不評で、結局規約から外れた設計になってしまうということもたまに…。
ボタンひとつの配置でも違う
私の場合、画面の設計は
機能上・コスト上の制約→実装難易度をあんまり上げたくない
システム設計上の共通規約→規約の例外を作るのは避けたい
デザイン→なるべく見やすい、使いやすいものにはしたい
という感じで考えることが多かったです。
また、画面上だけの問題であれば全体を眺めて違和感がないかどうかを優先して設計案を打診することもあります。
画面全体でフォントのサイズを揃えるとか、イベント発生時に実行する処理の有無を類似項目間で変えないとか。
ただ、あくまでそれは私の感覚によるところであって、実際にユーザーテスト等で「ボタンの左右を入れ替えてほしい」とか「この項目だけ字を小さくしてでも全部を表示してほしい」とか、「本当にそれやっていいですか？規約外れるけど大丈夫です？」と思うような要望も出ます。
そしてその対応をする中で、「ここは自分が実装しやすいことだけ考えてたかも…」とか「聞いたときはちょっとムカついたけど、直してみたらそれはそうやんな」とか、いろいろ反省するところに気付きます。
デザイナーの方の画面設計に従って作るなら、こういう後からの要望も少なくなるものでしょうか。
デザインのことを少しでも理解した上で設計するなら、出てくるであろう要望に先回りできるでしょうか。
いつかデザイナーさんと一緒にお仕事して確かめてみたい気もします。
余談
記事のヘッダ画像はEdgeの検索画面で「画面 インタフェース」と入力して検索しようとしたら勝手に生成されました。
折角なので使ってみましたが、画面いっぱいにアイコン並んでるとちょっと怖いですね…。