エンジニアの声から紐解く、人間中心設計がシステム開発現場に浸透しない理由
前回の記事では、スマートフォンアプリケーションやウェブサービスなどデジタルプロダクトの開発プロセスに人間中心設計の考え方が浸透しない理由を考察しました。今回は、様々な立場からシステム開発に関わるエンジニアの声を通じて、主に開発現場における課題を掘り下げたいと思います。
まず、今回の 10 名ほどのエンジニアへのインタビューを通じて気付いたことがあります。それは調査やユーザービリティテストが実施されていない状況に対し、当然のようにそれは悪だと私が決めつけていたことです。エンジニアの方々に話を聞いてみると、実施されない、または優先度が高くならない開発現場の様々な事情がありました。言われてみれば当たり前のことですが、思い込みは視野を曇らせます。私と同じように、多くのデザイナーがこうした背景を軽視しているかもしれません。ということで、今回は特にデザイナーに読んで頂きたい内容です。
1. そもそも要求されない
声 1「要件定義書には『使いやすさ』が評価項目として含まれていません。発注側もそれを問題視していません。当然ながら、スケジュールにリサーチやユーザビリティテストの時間が計画されることはありません。特に、社内向けシステムの開発では、開発要件の漏れやバグなどが重視される一方、使い勝手は軽視されがちです。デザインやユーザー体験に関しても同じです」（受託開発 製造会社シニアエンジニア A）
声 2「保守の案件などでは、何年もの間ずっとGUIを変えずに使い続けている社内向けシステムがあります。発注側や開発側は使いづらくても危機感は特に感じていません。」（SIer シニアエンジニア B）
システムを発注するクライアントやプロジェクトオーナーが使いやすさの必要性を感じていない、少なくとも重視していないようだという声が聞かれました。そうであれば、開発側として、開発すべき機能をまとめた要件定義書に『使いやすさ』を項目として入れる理由はありません。ユーザーのために工数を確保する必要性は、開発側から発生するものではないからです。
ユーザーにとって嬉しい体験を、サービスや製品を通して届けることが必要であるとビジネスサイドが認識していなければ、開発側の主導で使いやすさへの取り組みが行われる可能性は極めて低いでしょう。
2. 優先度が低くなる構造的な理由がある
声 3「基本的にネットワークインフラや機械制御のソフトウェア開発が会社として仕事の中で割合が大きくなりますし、プロジェクトによっては GUI (Graphical User Interface) が必要無いこともあります。サーバー側で障害が起きると影響範囲が大きくなることもあり、どうしてもフロントエンド側は優先順位的に後回しになりがちです」（受託開発 製造会社シニアエンジニア A）
声 4「受託開発の場合は、クライアントがマーケットやユーザーのリサーチを行い、開発会社側は関与しないことが一般的です。その為、開発側からは直接ユーザーが見えず、提案できることや出来ることは最初から限られてしまいます」（SIer シニアエンジニア B）
エンジニアが対応する範囲は、フロントエンド開発だけに留まらず、バックエンド開発、データベース、ハードウェア、ネットワーク、セキュリティなど多岐に渡ります。ユーザーに直接見える UI やデザインはその一部でしかなく、中でも開発側に求められるのは、バグをなくすことや、システム障害を起こさないこと、すなわち利用可能な状態を確保することです。ユーザービリティが悪かったとしても、システムが利用できなくなるよりは軽い問題というわけです。
また、直接ユーザーと関わることなく開発プロセスが進められている状況では、ユーザー体験に関係する部分を責任範囲として担保すること自体が不可能です。
3. すでに働き方ができ上っている
声 5「開発プロセスには、リサーチやユーザビリティテストの時間が計画されていません。会社として標準化されたプロセスなので、これを変更するとなる上司に確認も必要になりそれ自体が大変な作業になります。」（受託開発 製造会社シニアエンジニア A）
声 6「ユーザー要件は伝えられておらず、ウォーターフォール型の開発フローになっているので、開発途中で気付いたことがあっても、エンジニアから要件に対して提案する機会がありません」（SaaS 事業会社モバイル APP エンジニア C）
※ウォーターフォール開発は、前のステップが完全に終了してから次のステップに移るため、一度完了したフェーズに戻りません。
長年同じ開発フローでやってきた組織において、新しいプロセスを追加するのは容易な作業ではありません。教育コストがかかる上に、すぐに成果が出るとは限りませんし、大きなプロジェクトでは、プロセスを変更することによるリスクも無視できないでしょう。大がかりな変更になればなるほど、人間中心設計の本格的な導入は難しくなりそうです。
4. 文化的な壁がある
声 7「社内にデザイナーが所属していないので、外部へデザインを依頼することに心理的、または予算としてのハードルがあります。代わりに、比較的デザインが得意なエンジニアが UI を担当しますが、ユーザビリティテストなどのナレッジが社内に無かったり、勉強方法がわからないなどの問題があります」（システム会社 Web シニアエンジニア D）
声 8「設計が全て完成した後にビジュアルや UI をデザイナーへ依頼し作ってもらうので、ユーザーリサーチやユーザビリティテストなどまでやってもらうイメージがありませんでした」（SIer プロジェクトマネージャー E）
大手の一部の SIer などを除き、ほとんどの開発会社にはデザイナーが所属していません。そうした会社ではデザインを外注することが一般的ではなく、デザイナーが所属している会社でも組織の壁や物理的な距離があるなど、頻繁にデザイナーと接する機会がある開発者は少ないようです。そのため、デザイナーは絵だけをつくる職業だという認識の方や、デザイナーとどのように働ければよいのかわからないという方が多くいました。
デザイナーのいないプロジェクトでは、エンジニアが UI を担当することになります。より良いシステムを開発したいと、UI や UX デザインを学ぼうとするエンジニアもいましたが、組織的な支援を受けられる環境が身近にある方はいませんでした。
見えてきた背景と新しい疑問
数々のエンジニアへのインタビューを通じてぼんやりと見えてきたことは、開発現場で人間中心のプロセスが浸透しない、構造的かつ重層的な背景の存在でした。冒頭にも書いたように、今の状況は悪とは言えず、むしろ様々な側面を考慮した最適解と言えそうな形に収まっているようにも思えます。しかし、エンジニア側に使いやすいシステムへの関心がないわけではなさそうですし、今回の声として入れていませんが、人間中心設計のプロセスが大なり小なり導入されている事例も見られました。業界、システム規模、利用ユーザー層、プロジェクトの新規性や安全性など、様々な要因が人間中心設計プロセスを求める強度に影響しているようです。
中でも、ビジネス側の意識は、大きな影響がありそうです。そこで、次回の記事では、開発プロジェクトを発注する側の状況を確認するために、プロダクトオーナーやディレクターなどビジネスサイドへのインタビューを行い、より良いユーザー体験の必要性に対する考えや、人間中心の開発プロセスへの意識調査を行った結果を紹介します。