WordPressとどう違う？Drupalの強みと導入事例

業務系システムは、開発期間が長期化することが多く、一度リリースして、UI改善のためにまた作り直すというのがなかなか現実的ではありません。

また近年、企業イメージアップやさらなる業務効率化を目指して、業務系システムであっても、機能拡張だけでなく、ビジュアルデザインや操作性の改善に注力されるお客様も少なくありません。

そのため、多くの案件では、開発初期もしくは提案段階で簡易的なサンプルサイトやモックアップを作り、ビジュアルデザインを共有することで、関係者間でフィットギャップを確認し、完成形へ作り上げることが大切です。

ある案件で、お客様と要件を決めて、画面の設計をし、ビジュアル化したときの話です。「なんとなく余白があるからグラフも表示しよう」「この値を見ながら入力したいから、この画面にはあれもこれも表示させたい」など画面いっぱいに表示要素を詰め込んでしまうことがありました。また「この大きな表はスマホでもタブレットでも閲覧や操作をしたいけど、レスポンシブWEBデザインだからスマホやタブレットでも問題ないよね?」とマルチデバイスでの遜色ない操作性と表示レスポンスへ配慮が必要になったこともありました。

通常、制作者は、システムに含まれるあらゆる表示要素を切り出し、パズルのピースに見立てて、画面へ配置、装飾し、動きを加えて、1つの画面を完成させます。そのため、後からパズルのピースが加わることによって、画面がうまく完成できずに煩雑なソースコードになってしまったり、ブラウザや環境、コーディングやライブラリに制約が生まれたりと、UI表現の幅や運用のしやすさにも大きく影響します。

要求要件の整理が大切なのは、業務系システムに限った話ではありませんが、小手先では修正しきれないことが多い業務系システムだからこそ、予め最終的に外せないポイントをあらかじめ計画しておくことがとても大切です。

多くの業務系システム案件では、現状何らかの代替手段で業務を行っており、それらの課題解決策として新システムを生み出すことが多いです。

これらの課題の背景には、利用者の属性(業種、職種、業態、立場、役割)によるシステムとの関わり方が関連することも多く、課題解決のためには、現業務の実態や顕在・潜在課題、利用者の慣れや習慣を知っておく必要があります。特に、画面操作や画面配置に課題がある場合には、UIを決めるうえで非常に重要な情報になるのです。

一般論にこれらの案件特化した情報を織り交ぜながら新システムのUIを決め、利用者にとって必要なUIを拡張していくことが大切であり、利用者の満足度が高まるだけでなく、利用者の業務効率化につながると考えます。

大規模案件になると、開発チーム、デザイン・コーディングチーム、インフラチームと複数チームで案件に携わることも多く、膨大な情報から必要事項を抽出し、最適な設計する必要が出てきます。

フロントエンドでは容易に実現できても、バックエンドでは煩雑かつ実現不可ということもあります。例えば、表の便利機能について、印刷やファイル出力をしたいという要望を受けた際、フロントエンドは印刷ボタン、ファイル出力ボタンをつければいい話ですが、バックエンドではそれにまつわる追加開発が必要になります。

こういったシステムにまつわる様々な制約という事情を理解し、工夫を凝らしながら、チーム全体でシステムを作り上げることが大切です。