見出し画像

ソフトウェア開発におけるデザインとエンジニアリングの両輪

多くの企業ではデザイナーとエンジニアは別々の職種として分けられており、デザインはデザイナーが、エンジニアリングはエンジニアがするもの、ということが一般的なのではないかと思います。(そのための職種なので当たり前と言えば、当たり前ですね)

しかし、職種が分かれているがゆえに個別に語られることはあっても、お互いの関係性ついては語られることが少ないように感じます。そして、実際の開発の中ではこれらの関係性がうまく噛み合わないことで生まれてしまう問題もあります。そのため、今回はデザインとエンジニアリングの関係性とそこから発生しうる問題について書いてみたいと思います。

なお、デザインとエンジニアリング、それぞれ様々な解釈がありますので、この記事の中では対比するために以下の意味合いで用いることを予めお伝えしておければと思います。

デザイン = ユーザーの体験およびインターフェイスを考えること
エンジニアリング = インターフェイスおよび裏側の仕組みをつくること

連続的な活動

あらゆるプロダクトは、デザインとエンジニアリングの両方の工程を経て、ユーザーの手元に届けられます。どのような開発プロセスにおいても、基本的にはデザインが前工程としてあり、エンジニアリングが後工程として存在していると思います。

ここで発生しやすい問題がスケジュールです。特に納期が重視されるプロジェクトの場合、デザインとエンジニアリングの連携や作業工数のバランスがとれていないと何かしらの問題が発生しやすくなります。典型的なパターンとしては、前工程で時間を使いすぎたり、考慮漏れによって、後工程でコストが超過するなどです。

プロジェクトの失敗理由ランキング

引用元:使えないシステムが生まれてしまう理由、現場の実態

具体化と制約化

ソフトウェアを作る際、0 → 1の段階で制約が少ない場合、UIを比較的自由に設計することができます。しかし、実装が進むことで変更コストも同時に積み上がっていきます。特に運用フェーズに入ると既存の仕組みが制約になり、影響範囲を考慮しながらデザインや実装を行なっていく必要性が出てきたり、制約を超えて無理やり実装しようとすれば、コードの複雑性が増し、後に技術的負債となって開発者を苦しめることになってしまうこともあります。

下図は、製品開発におけるコスト発生のパターンですが、ソフトウェアにおいても当てはまる部分はあるかと思います。

製品開発におけるコストの発生パターン

引用元:VE活用のポイントをつかむ

品質と欲求

ご存知の方も多いと思いますが、顧客満足度に影響を与える品質の特徴を表した「狩野モデル」があります。

狩野モデル

引用元:狩野モデル | UX TIMES

人間の欲求に基づくのであれば、プロダクトが「普通に使える」ことはとても大事なことです。たとえ見た目が美しくて、機能が便利だとしても、情報が漏洩してしまったり、データが消えてしまうなど「普通に使えない」場合はユーザーに受け入れてもらうのは難しいでしょう。

UXの欲求段階モデル

機能性の欲求:基本的な機能に関する欲求が満たされると、ユーザーは満足を得る。
信頼性の欲求:継続的に使用したときに、動作が確実で一貫していると、信頼感が育まれる。
ユーザビリティの欲求:使いやすさを実感すると、ユーザーは愛着を持つようになる。
上達の欲求:生産性が高まり統御感が強化されると、ユーザーは愛着を持つようになる。
創造性の欲求:新しい工夫を加えて自分なりに使いこなせると、ユーザーは代替製品に見向きもしなくなるほど惚れ込む。

引用元:デザインの欲求階層説 | UX TIMES

もし、当たり前品質を確保できていない状態だと使い心地どころじゃなくなってしまい、魅力的品質の部分に時間を使うことが難しくなってしまいます。

デザインとエンジニアリングは両輪

先に述べたようにプロダクトが当たり前に使える必要があることを考えると、パフォーマンスやセキュリティ面を担うエンジニアリングはユーザー体験の質に影響を与えます。

しかし、余計な機能が多かったり、UIの変更容易性が低かったりすると開発工数が膨らんだり、メンテナンスが大変になったりします。その結果、開発スピードが落ちることでユーザーに提供できる価値の量は減ってしまいます。

つまり、デザインとエンジニアリングというのは相互に影響を及し合っているという見方ができます。特に継続的な発展を求められるプロダクトの場合はこれらの両輪を上手く回すことがユーザー体験の質量と持続性の向上において重要な観点だと考えています。

たとえば、要件定義の考慮漏れを防ぐためにエンジニアを巻き込むことはリスクヘッジになりますし、開発時の変更コストを抑えるためには、変更されにくい部分と変更されやすいドメインを予測し、デザインと実装を同期することは重要です。

おわりに

複数の観点からデザインとエンジニアリングの関係性とその間で発生しうる問題について述べましたが、これらの問題はプロダクトや組織によってさまざまであるため、銀の弾丸はなく、常にトレードオフの中で何が最適なのかを模索するしかないと思います。

もし、なにか上手くいかないことがある場合、それは人や役割に問題があるのではなく、それらの“間”や関係性に問題があることがあります。そのことを念頭に考えてみると、相互理解やコミュニケーションによって解決できることもあるかもしれません。

おしまい

いいなと思ったら応援しよう!