[昭和怪事ラボ001]システム中心のデザイン依存によって失われているもの？
「何故このサービスは使って貰えないのだろう？」「PoC (Proof of Concept)段階の協業はできても、その先のサービス利用にまで至らないのは何故なのだろう？」と頭を掻きむしるプロジェクトリーダー。
皆さんの周囲でも、よく聞く・見るシーンでしょうか？
こんにちは。HCI (Human-Computer Interaction)という分野を専門に研究しているnacoです。
この記事では、私たちの次に取り組むプロジェクトが、このようなPoC止まりの怪事を回避できるように、システム中心のデザインと、ユーザ中心のHCIデザインの生み出す大きな違いについて、見ていこうと思います。
つくるのはITシステムですか？それとも、ユーザが行動できるサービスですか？
何百時間という時間を費やして、幾つもの技術的難所を超えて、設計書に沿ったパーフェクトなシステムができました。
良いコラボレーション関係を築いたお客様たちと、PoCも実施でき、洗い出したシステム要件は全て実装したはずでした。
それなのにもかかわらず、待望のサービスリリース後、サービス契約者は伸びない。いったんサービス契約をして下さったお客様も、継続的に使用しては下さらない。
さて、ここにいたって、プロジェクトリーダーは“何が間違っていたのだろう？”と考え始めます。必死に考えて、出来上がったシステムを精査してみても、答えが見つからない。その場合、つくっている対象（ITシステム）の輪郭を見直していく必要があるのかもしれません。
あなたがつくるのは、ITシステムですか？それともユーザが何かしらの行動ができる為のサービスですか？
前者だと、もしくは後者だと、迷わず答える方には、この記事は無用のものかもしれません。
少し迷った方は、ぜひ続きも読んでみて下さい。
システム中心のデザイン と ユーザ中心のHCIデザイン
システムをつくるのか、ユーザが行動できる為のサービスをつくるのか、このいずれを選択するかによって、デザインの方向性は大きく異なります。ここでは、次の2つのデザインの違いを使ってみていきたいと思います。
システム中心のデザイン…ここでは、冒頭のプロジェクトリーダーが行ったような、“システム要件にあうように構築されるシステム”デザインを指します。システムがネットワーク負荷に耐えられるか、必要なセキュリティ基準を満たしているか等、確かに重要な点が多々あります。ただ、上図をみてみて下さい。これだけを行うと、何かが抜けているように見えませんか？
ユーザ中心のHCIデザイン…上図のようにこちらは、システムではなく、まず、ユーザへ着目します。“ユーザの持つゴールやニーズを満たして、ユーザが行動できるように構築されるシステム”デザインを行います。上記のシステム中心のデザインと大きく異なるのは、ユーザの姿がかなりクリアだということです。ユーザがどのようなゴールやニーズを持っているのかということを理解しなければデザインが始まりません。
もう一歩踏み込んで考えてみましょう。
図中のユーザ中心のＨＣＩデザインの注目点は大きく2つのパートに分かれています。User-Centered（ユーザ中心）な情報デザインと、Engagement-Centered（エンゲージメント中心）なインタラクションデザイン。前者は、ユーザの属性やスキル等に合わせ “情報” をデザインし、後者は、いかにしてユーザがその「情報にアクセスしたい」・「情報を共有したい」と思うかに合わせ “インタラクション：相互作用” をデザインします。つまり、このユーザ中心のＨＣＩデザインにおいては、システムの提供する情報（テキスト、音声、画像、動画、ＶＲ空間等）へ、アクセスしたいと思ってもらえるにはどうすれば良いか、ということの検討が含まれています。
あなたは、システム中心のデザイン依存によって何を失いますか？
この記事のタイトルにある“システム中心のデザイン依存によって失われているもの”とは何なのか、見当がついてきた方もいらっしゃるかもしれませんね。
システム中心のデザインのみに依存してシステム開発プロジェクトを行った場合、以下のことは不明瞭です。
・ユーザは誰？
・ユーザはどんなゴールやニーズを持ってる？
・ユーザに適切な情報とは？
・ユーザは情報へアクセスしたい/情報を共有したいと思ってくれる？
つまり、システム中心のデザインのみに依存してシステム開発プロジェクトを行う場合、いるかどうかも分からないユーザに向けてシステムやサービスを構築するわけですから、実際に使って下さる方がいるかどうかは、運頼りになってしまうわけですね。
“システム中心のデザイン依存によって失われているもの”は、あなたの立場によって答えが異なるかもしれません。開発関係者であれば、プロジェクトに投資した時間や予算といったリソースかもしれません。営業関係者であれば、そのようなユーザのゴールに合っていないシステムの納入を受けたお客様からの信用かもしれません。人事関係者であれば、そのような不毛なプロジェクトから逃げ出した優秀な人材かもしれません。
このシリーズ[昭和怪事ラボ] PoC止まりの怪事編では？
「まずは、このサービスのユーザ価値を検討しましょう！」と、ユーザ中心のHCIデザインを推奨するUX(User Experience)デザイナやHCI研究者と、プロジェクト進行のプレッシャーにさらされるエンジニアやプロジェクトリーダーの対立というのは、どんなプロジェクトでも大なり小なり抱える問題なのかもしれません。
しかし、システム中心のデザイン依存によって失われているものの大きさに気が付き、改善したいと思うならば、単にITシステムをつくるのではなく、ユーザが行動できる為のサービスをつくるべく、デザインの段階から思考を切り替えていく必要があります。
システムをつくってから、その後に余ったリソースでユーザの解像度を上げても、できることは、限定されてしまいます。結果として、ユーザのゴールやニーズを実現することはできず、“PoC止まり”のプロジェクトとなってしまうことも多々あります。
ユーザ中心のHCIデザインには、正解がありません。なかには、デザイナの才能に依存していると諦めている方もいらっしゃるかもしれません。この“PoC止まりの怪事編”では、“PoC止まり”を増産してしまう怪現象の解決に、システマティックに取り組める一助となるような記事をまとめられたらと思っています。特にユーザ中心のHCIデザインについて、HCI研究者の立場から、皆さんと一緒にその構造を解きほぐしていけたらと思います。
【関連記事】
[昭和怪事ラボ000]昭和のままのスキルに気付いた時、私たちと、その組織は、成長し始める？
https://note.com/kmcxfujitsu/n/n63b22a0ef2a3
[昭和怪事ラボ002]ユーザがあなたのサービスを使わない理由？
https://note.com/kmcxfujitsu/n/n4ba15679c822
[昭和怪事ラボ003]ユーザの目的は実現しない、けど使い続けてもらえる不思議なサービス？
https://note.com/kmcxfujitsu/n/n0b8104c1140c
[昭和怪事ラボ004]会議室のツルが鳴かずにすむ戦略的な判断基準？
https://note.com/kmcxfujitsu/n/ned841df6d1e9
[昭和怪事ラボ005]デザイン原則にのっとっても、「私向けのサービスじゃない」と思われてしまう理由？
https://note.com/kmcxfujitsu/n/n92eef5f449fb
文責：naco
[昭和怪事ラボ]シリーズ全体では、その他の昭和時代から連綿と正体不明のままになっている怪現象にも取り組んでいきたいと思っています。“PoC止まりの怪事編”は今のところ5本くらいにまとめようかなと考え中です。リクエストなどあれば、ぜひお願いします～