"言われたものを作る"をやめた話。受託開発でHCDを実践するとプロジェクトはどう変わるか？

HCD（人間中心設計）とは何か？

まずこの記事で取り上げるHCDについて、簡単にご説明します。

HCDとは「Human Centered Design（人間中心設計）」の略で、ユーザーの利用状況や課題を起点に設計を進めるプロセスです。ISO 9241-210として国際標準化されており、以下の4つのステップを反復することで成立しています。

1. 利用状況の把握・明示：誰がどんな環境でどう使うかを理解する
2. ユーザーの要求事項の明示：満たすべき要件を定義する
3. 設計による解決案の作成：定義された要件に基づいて作る
4. 要求事項に対する評価：設計がユーザーの要求を満たしているか検証する

このサイクルを繰り返すことで、ユーザーの実態から離れた設計になることを防ぎます。「作って終わり」ではなく「作りながら確かめる」というプロセスそのものを指すのがHCDです。

UX・デザイン思考との違い

HCDと似た言葉として「UX」「UXデザイン」「デザイン思考」があり、それぞれ異なる概念です。

UX（ユーザーエクスペリエンス） は、ユーザーが製品やサービスを通じて得る体験そのものを指します。あくまで「対象」であり、良いUXを実現することがゴールです。

HCD は、そのUXを良くするための設計プロセスです。「何を作るか」ではなく「どのように進めるか」の枠組みを定めたものです。

UXデザイン は、HCDのようなプロセスを活用しながら、実際に体験を設計する活動です。デザイナーの職能や実践を指します。

デザイン思考 は、UXに限らずビジネス課題全般に応用できる問題解決のアプローチです。より広い文脈で使われることが多く、共感・問題定義・発想・試作・テストという5つのステップを行き来しながら進めます。

簡単に言えば、「良いUXを実現するための方法がHCD（人間中心設計）であり、それを実践する活動がUXデザイン」 という関係です。

受託開発の現場で何が変わるのか？

Before：「言われたものを作る」プロセス

多くの受託開発では、このような流れで進むことが多いのではないでしょうか。

発注者が要件を定義する → デザイナーがワイヤーフレーム・デザインを作る → エンジニアが実装する → リリース

その結果、「思っていたのと違う」「使いにくい」という事態を招くことがあります。

このプロセスの問題は、ユーザーが登場するのがリリース後だという点です。発注者の頭の中にある「こう使うだろう」「こうあるべき」といったイメージと、実際のユーザーの行動や文脈にはしばしばギャップがあります。そのギャップが、リリース後の大幅修正や「使われないシステム」のような結果につながります。

After：HCDを取り入れたプロセス

HCDを取り入れると、プロセスの出発点が変わります。

ユーザーの利用状況・課題を把握する → 発注者・デザイナー・エンジニアが同じ解像度で課題を共有する → 設計・実装・検証を繰り返す → リリース後も改善サイクルが回る

ユーザーが最初から設計の中心にいるため、「作ってから気づく」ではなく「作る前に確かめる」ことができます。

① 発注者との関係が変わる

従来の受託開発では、開発会社は「要件を受け取り、実現する側」です。HCDを取り入れると、「課題を一緒に定義するパートナー」という関係に変わります。

発注者が「こういう機能がほしい」と言ったとき、その背景にある「なぜほしいのか？」「誰がどう使うのか？」が設計の出発点になります。発注側のビジネスゴールを理解して、プロダクトがどんな役割を果たすのかを明確にする過程で、発注者自身が気づいていなかった本質的な課題が見えることも少なくありません。

たとえば、「Webサイトをリニューアルしたい」という要望から始まった特定業界向けの開発プロジェクトでは、リニューアル背景やユーザーの実態をヒアリングしていく中で、発注者自身が既存アプローチに迷いを持っていることがわかりました。そこでHCDプロセスを活用してユーザー像と目的達成までのシナリオを言語化し、新しいアプローチのアイデアを検討しました。これは、要件を受け取るだけでは気づけなかった視点です。

② 設計の根拠が変わる

HCDを取り入れることで、設計の判断に根拠が生まれます。「なんとなくこうした」「要件にあったからこうした」ではなく、「ユーザーがこういう行動をするからこうした」という説明ができるようになります。

これは発注者との合意形成にも直結します。根拠のある提案は説得力を持ち、「なぜこのデザインなのか」という議論がしやすくなります。先述のプロジェクトでもデザイン意図が伝わったことで、発注者が安心して判断できる状態になりました。

③ 手戻りが減る

設計段階でユーザーの実態を確認しておくことで、リリース後の「思っていたのと違う」が大幅に減ります。

一般的に、問題を発見する時期が遅くなるほど修正コストは上がります。設計段階で気づけば修正はデータ上の話で済みますが、リリース後に気づけばコード・デザイン・テスト・再リリースのすべてに影響します。HCDの「作りながら確かめる」というアプローチは、このコストを前倒しで削減する効果があります。

④ チームの動き方が変わる

HCDを取り入れると、プロジェクトチームのメンバーがユーザー像を共有した上で動けるようになります。「言われた通りに作る」から「なぜこう作るのか」を理解して作ることの変化は、チームの当事者意識にも影響します。

ユーザーの文脈を知っているエンジニアは、実装上の選択肢を検討するときにもユーザー視点を持ち込めますし、「この仕様だと使いにくくなる可能性がある」という気づきを、実装段階で発信できるようになります。

HCDはフルスペックでなくていい

「HCDといっても、予算や時間が充分にない」という声もあるでしょう。ただ、HCDはフルスペックで実施しなければ意味がないわけではありません。

たとえば、こんな小さな一歩でも効果があります。

• 要件定義の前にユーザーインタビューを1回行う：ユーザーの実態が把握できるだけで、設計の精度が上がる
• ワイヤーフレームを発注者だけでなく実際のユーザーに見せてみる：想定外の反応が設計の見直しにつながる
• リリース後に数人のユーザーに使ってもらい観察する：次の改善サイクルの起点になる

実際にいくつかの現場で、ユーザーから小さなフィードバックを得て、その後の改善活動に活かしたこともあります。

受託開発でHCDを実践するとき、最初から完璧なプロセスを目指す必要はありません。「ユーザーのことを確かめるステップを、どこかに一つ入れる」ことが第一歩です。

おわりに

「言われたものを作る」は、一見効率的に見えます。要件が明確で、スコープが決まっていて、工数も読みやすい。しかしその先に「使われないシステム」があるとしたら、誰も得をしません。発注者も、ユーザーも、開発チームも。

HCDは、その構造を変えるプロセスとも言えます。ユーザーを設計の出発点に置くことで作るものの精度が上がり、手戻りが減り、発注者との関係が「依頼を受ける側」から「課題を一緒に解くパートナー」へと変わります。

「要件通りに作れるか？」ではなく「ユーザーにとって正しいものを作れるか？」を問うことが、良いプロダクト開発への第一歩。正しい形にたどり着くまで繰り返し問いを立てながら、今後もより良いプロダクト開発を追求していきたいと思います。

ジークスでは、顧客体験を重視したシステム・アプリケーション開発の伴走支援を行っています。HCDプロセスを取り入れて「使われるプロダクト」をつくりたい方は、ぜひお気軽にお問い合わせください。