はじめに

「経験」や「勘」に頼って仕事を進める文化は、時に思いがけない成果物を生み出してしまいます。
今回は、社内の勉強会をきっかけに、勤怠管理ソフトのデザインが思わぬ方向に進んでしまった職場のトラブルを紹介します。

本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。

「エンジニアにデザインを任せてはいけない理由」

これは勤怠パッケージソフトを自社開発している神奈川県の中小企業での出来事。

社内の勉強会で、自社の勤怠管理ソフトのUIデザインを改善しようという話が持ち上がった。

  • メンバーH（若手）🙂 「せっかくなので、ペルソナを設定したデザイン設計の一連のプロセスを経験し、デザインの基礎をちゃんと学びながら進めませんか?」

  • 勉強会リーダーI 😐 「ペルソナ設計ぃ？　なんか時間かかりそうだなそれ。」

  • メンバーH（若手）🙂 「UI/UXの原則も踏まえて、視認性とか操作性とか一貫性とか、意識した方がいいと思うんですけど……。」

  • メンバーJ 😑 「なんか難しい話してるなー。もっと感覚でパッと決めちゃえばよくない？」

  • メンバーH（若手）😅 「いや、一連のプロセスを理解しないとスキルの取得にならないんじゃ……。」

  • 勉強会リーダーI 😤 「今回はいいんじゃないの」

基礎的なプロセスを「面倒くさい」と感じたリーダーとメンバーたちは、結局、明確なコンセプトを決めないまま、思い思いの感覚でHTMLファイルの編集を始めた。

  • メンバーJ 😊 「ボタンのアイコン、てんとう虫にしてみようよ。」

  • 勉強会リーダーI 🙂 「こっちは星型で。バランスも良さそうだし。」

  • メンバーH（若手）😨 「……勤怠管理ソフトに、てんとう虫と星のアイコンですか？」

  • 勉強会リーダーI 😊 「可愛いからいいでしょ！」

コンセプトを誰も定めていなかったため、カラーリングの意図も統一されないまま、デザインは完成してしまった。

  • メンバーH（若手）😱 （このアイコン、実際に使う社員は何のボタンか分かるんだろうか……。）

出来上がった勤怠ソフトは、ボタンの各種アイコンがなぜか「てんとう虫」や「星」になっており、コンセプトが不明なままカラーリングの意図も分からない、残念な仕上がりとなってしまった。

xxx

解説

問題点

HTML5が登場した頃、「デザインは理論化できるので、デザイナーでなくてもデザインができる」という意見が広まったことがあります。
しかし実際には、今でもデザインはデザイナーの仕事として成り立っています。
そもそもエンジニアには、デザインの理論をきちんと理解しようとするセンスや姿勢が備わっていないことが多いのです。

これはデザインに限った話ではありません。「理論化できるから誰でもできる」というものは存在せず、「餅は餅屋」という言葉が示す通り、専門領域には専門家が必要だということが、この事例からもわかります。

対処法

独りよがりな経験則だけで判断せず、ペルソナ設計やコンセプト決めを簡略化してでも実施することが重要です。
「感覚」に頼った判断も、根拠や意図を言語化して共有する習慣をつければ、再現性のあるスキルとして蓄積できます。

おわりに

基礎的なプロセスを「面倒だから」と省略すると、その場では時間を節約できても、後で大きなやり直しコストとして跳ね返ってくることがあります。
「経験」や「勘」だけに頼らず、体系立てられた方法論を学ぶ姿勢が、組織全体のスキルアップにつながります。