![見出し画像](https://assets.st-note.com/production/uploads/images/145749312/rectangle_large_type_2_4019790ea39c863407931817d34bd112.png?width=1200)
人間中心設計からモデルベース開発まで、最近考えていること。
以前の記事を書いてから相当時間が開いてしまいました。いくつか理由はあるのですが、一番大きいこととしてはこのブログでおこなっていた個人でのデザイン研究を会社の業務として利用するようになり、リアルな話が公開しにくくなったというのがあります。
デジカメの創成期から立ち上げに関わりデジタルならではのUXデザイン/体験設計を通して、それを実現するためのシステム全体のデザインプロセスに着目し研究してきました。自分としては会社の価値を上げる研究と思っていたのですが認められず上司から個人研究を勧められた形になりました。
業務ではさまざまな製品分野に関わっていましたがデジカメなら個人で購入し体験することができると考え、デジカメを通して体験設計やシステムデザインについてnoteに書くようになったといういきさつです。
つまり、元々会社の業務として研究していたものですから、タイミングが合えばいつでも取り入れられるレベルにあったということになります。
概念的な話だけですがまずは文章としてまとめておきます。図解してもう少し分かりやすく伝えられればと思いますが、それは時間のある時にやっていくことにします。
どんな変化がおきているのか
多くのメーカーは、設計や製造の技術を背景にした製品開発が仕事となっていて、機能アップ・性能アップを軸としたモデルチェンジの業務が多いという状況にありました。つまりモノに着目した軸だけで効率的に新製品を生み出せば売れるという時代を過ごしてきたわけです。
2000年を前後してマイコンをベースとしよりきめ細やかな機能を提供する競争が始まり、いわゆるデジタル化された製品が増えると同時にそれを使いこなせないユーザビリティ問題が出てきました。
当初は、機能を使えるようにさせる「適切なUIデザイン」が目的でしたが、更にデジタル社会に進む中でモノの価値から使用効果を含む体験価値へ「適切なUXデザイン」を目指すようになっていきました。
製品の高度化にユーザーが付いていけないことが原因で起きる失敗や事故は、産業革命以降の自動車や飛行機の登場、ロボットやAIまで起きており、ユーザーの目的に合ったUXをユーザーの思考モデルにあったUIで提供する必要が必須になったと言えます。
![](https://assets.st-note.com/img/1719754279604-P4smCg58pD.png?width=1200)
やっぱり人間中心設計
2000年ごろにISO13407といういわゆる「人間中心設計(HCD)プロセス」がでてきました。基本的な考え方はそれよりもずっと前から人間工学やデザインの分野ではありましたが、あらゆるモノゴトを包括した基本的な原則としてISO化されたことが重要でした。(その後HCPはISO9241-210に継承)
一時期、ユーザー要求だけを聞いていても本当に革新的なデザインはできない、だから人間中心設計はオワコンという話がでてきたことがありますが、これは論点がかなりズレている考え方です。
ユーザーに要求を聞くのではなく、ユーザーはUXを実現する3要素①ユーザー、②利用状況、③解決策(製品やサービス)が一つのシステムとして機能しなければならないことを人間中心設計プロセスは言っています。とくにユーザーの不確定要素の影響が大きいために「そこに注意して進めましょう」という意味で人間中心と言っているのです。また想定通りにいかない(多くはユーザーが理由)ので、システムの目的を達成できるまで人間を丁寧に扱う設計を要求しているのです。
良いデザインをおこなうためには①ユーザー、②利用状況、③解決策の3要素をしっかりと、(A)深く調査、(B)構造最適化、(C)評価の繰り返しとしてプロセスおこなうことが重要になります。つまり①~③を1つのシステムとして(A)~(C)で扱っていくことが実際の活動ということになります。
特に新しい体験や新しいやり方(手段)を採用する革新的なデザインについては、調査の段階から通常のモデルチェンジとはレベルの異なる解像度と範囲・次元を意識して活動しなければならず、一部だけを頑張るだけでは破綻してしまう可能性が高まります。
構造化シナリオと構造化プロトタイピング
体験システムは登場アイテム(①~③に含まれる全要素)がそもそも多く、それらの関係を適切に扱うプロセス(A~C)があり、一度にまとめて考えようとすると単純化し過ぎてしまったり、特定の部分に着目し過ぎてしまったりして扱うことが非常に難しいという面があります。そこで考えられたのが「構造化」の手法です。
バリューシナリオ、アクティビティシナリオ、インタラクションシナリオという3階層に切り分けて扱うことで、前段のステップで技術や実現性に引っ張られることなく純粋なバリューを明確にし、それらを体験価値に落とし、最後に現実的な手段として製品・サービスが持つ情報設計・操作設計へと落とし込んでいくことが「構造化」ではできます。
また実際の製品やサービスの開発ではシナリオだけでなく、構造化プロトタイピングが重要になってきます。プロトタイプと言うと実際のモノを作ることになり、結果として技術や実現性に引っ張られてしまう従来のプロトタイピング(試作)ではなく、構造化シナリオに平行してバリューだけを検証するプロトタイプ、アクティビティだけを検証するプロトタイプを経て、ようやくモノのプロトタイピングを作ることで、手段を限定することなく上位目的を達成する幅広い手段の発想に繋げることができるようになる効果も期待できます。
![](https://assets.st-note.com/img/1719755528432-mSUBpWJeeO.png?width=1200)
モデルベース開発と体験設計
シナリオとプロトタイプを構造的に扱うと言っても、規模の小さなシステムではWordやPowerPointを駆使してまとめ上げることができますが、IoTの時代にサービスと紐づかないものはほとんど無く、グローバルを相手にするならばユーザーや利用状況の多様性は増加していきます。
それらを、過去の経験に基づく感覚的に扱ったり、チープなツールでやっているつもりになっていると、ビジネスが博打になってしまい、最悪の場合は人命にかかわるような事故に繋がることさえあるのです。
モデルベース開発は飛行機や自動車のような大規模な開発分野で発展してきました。特に近年の自動運転車の開発ではソフトウェアの規模が桁違いに大きくなりオブジェクト指向の考え方と共に無くてはならないものになっています。
そのような製品設計のためのモデルベース開発を、体験設計にまで拡張してユーザーや利用状況の情報を構造的に扱うという考え方になってきています。考えてみれば体験設計をシステムと考えれば、特に人間特性として誤差範囲の大きいオブジェクトとして記述できれば同じように扱えるというのが基本的な考え方になります。
この考え方は単に大規模・複雑化してきていることだけでなく、品質管理やリスク管理によって設計に根拠や保証を求める要求が強くなってきていることも影響しています。
![](https://assets.st-note.com/img/1719755472014-5MR1LeDUrD.png?width=1200)
この記事が気に入ったらサポートをしてみませんか?