プロジェクトの定義とデザインプロセス

"Context of use"―。
それはHCDプロセスそのものに対してもいえることではないでしょうか。

どのような手法をどのように用いてプロセス化するかというプロジェクトのデザインは、プロジェクトのコンテキストそのものを定義しなくては決まらない。もちろん、それは人間中心のデザインに限らず、すべての計画、設計、デザインにおいて―。僕はそう考えます。

ゆえに、以下の考えには賛成です。

HCDプロセスの導入は、きっちり決まった手法では無く、案件ごとに流動的なものであります。クライアントの意識や会社風土、ユーザの意識やリテラシー能力など案件ごとに様々ですよね。
HCDプロセスは「こうでなくてはいけない。」という事は無く、もっとクライアントそれぞれのコンテキストに合わせた導入方法があるのかな。

すでにアサノさんのブログには、コメントを残しましたが、ここでもあらためて整理しなおして掲載しておきます。

ステークスホルダーは複数、デザインする人工物は単数

何らかの人工物をデザインする際、ほとんどの場合、それに関わる利害関係者（ステークスホルダー）は複数にいます。その際、異なる利害関係者同士は異なる要求を持ち、さらに異なる利害関係者がもつ要求同士はたがいに排他的になるケースもあるでしょう。

ただ、利害関係者の数が多く、それぞれが異なる要求をもっていても、最終的に提示する人工物は1つに固めなくてはならない。複数の利害関係者の異なる要求をうまく調整しながら、1つのデザイン案を導き出すことが、デザインする人には求められます。

デザインを行う際には、利害関係者たちの利害をそれぞれ把握し、利害同士の関係性を理解する必要がある。そのためには、利害関係者ごとに、製品利用時の役割、利用目的、ゴールを中心とした利用のコンテキストを明確にしていく作業を行わなくてはなりません。そして、その作業を通じて、利害関係者それぞれの利害が浮かびあがってくる。
それらをいかに調節したひとつの解決策を提示できるかがデザインの課題です。複数のステークスホルダー間の利害関係をその重要度に応じて調整する際には、QFD（品質機能展開）の考え方も応用できるでしょう。

オフィス用複合機のデザインと利害関係者

オフィスなどに置かれている複合機を考えてみましょう。

一般利用者の通常利用
日常の仕事のなかで、誰もが普通にコピーをとったりプリントしたりという通常の利用ケースがあります。これは上部のUIや物理的なボタンのみで利用できたり、複合機には触れずに自身のPCからすべてコントロールできること（もちろんプリントアウトした紙を取りにいくのは除いて）が望ましいでしょう。
一般利用者のイレギュラーな利用
ただし、複合機は紙詰まりなどの問題をたびたび起こします。その際には、一般利用者にもそうした問題の自主的な解決が望まれます。下部の扉をあけて、普段は隠されている複合機の内部をのぞき、詰まった紙を取り除く作業をしなくてはいけません。使い慣れたUIやボタンによる操作とは異なる利用方法が求められます。
とうぜん、一般の利用者にそうした問題解決の作業をスムーズに行わせるためのガイドをすることが、複合機のデザインが必要になる。最初にどのレバーを引いて、次にどの部位を引き出して、詰まった紙を取り除くか。同時にUI側でも、どの部位に紙が詰まっているかを示し、問題解決の操作をどうやって行えばよいかを示すことが必要でしょう。
専門のサービスマンによる修理時の利用
ただし、すべての問題が一般の利用者で完結できるわけでもありません。複合機を使っているとどうしても、専門のサービスマンを呼んで修理してもらわなくてはならないケースも生じます。一般の利用者向けに問題解決用にデザインされた操作だけでは、問題解決ができない（どうしても紙が取り除けない、etc.）場合は、専門家の手を借りる必要があります。
その場合、修理をする専門家は、ドライバーを使ってネジをはずす、壊れた部品を交換する、などの、一般の利用者では利用できない機器のインターフェイスに触れることで修理の作業を行います。もちろん、この場合も専門家ならなんでも修理できるというものではなく、あらかじめ修理可能なインターフェイス（取り外し可能なネジや交換可能な部品）がデザインされていてはじめて、修理の専門家は自身の目的である「修理」という行為が可能になるのです。

この3つのケースを考えただけでも、各利害関係者の要求は異なり、それぞれに異なる利用を促すデザインが必要です。

さらに、複合機はネットワークにつなげて利用されることが多いので、オフィスのネットワーク管理者用にネットワークの設定などを行うインターフェイスを提供する必要もあるし、利用可能な寿命がきた場合に廃棄することを考えたデザインというのも必要かもしれません。

オフィス用複合機のマーケティングおよび事業のデザイン

以上は、あくまで複合機という人工物そのものをデザインするときの利害関係者とその要求に対するデザインとの関係を概観しただけです。

ただ、ビジネスという面で考えれば、とうぜん、それに加え、複合機を売る人、導入検討を行うクライアント側の担当者、導入の決済を判断するクライアント側の決裁者など、販売/購入という側面での利害関係者もそれに加わってきます。

そのとき、解決しなければならない問題は、必ずしも複合機そのもののデザインではなく、複合機の販売/購入にともなうコミュニケーションのデザインや価格設定など、複合機のマーケティングに関するデザインに対象が移動します。
販売側の企業の立場に立てば、販売後のメンテナンスを支える体制をどのように組織化し、全国的に展開するか、どのようなオペレーションで対応するのが効果的かということも考えなくてはいけません。

単純化すると、バランストスコアカードの4つの視点（「財務の視点」「顧客の視点」「業務プロセスの視点」「学習・成長の視点」）をバランスさせることで、最終的なビジネスゴールを達成する必要があるということになる。この4つの視点にすでに異なるステークスホルダーの視点が含まれているのにお気づきでしょうか（狭義のHCDが相手にするユーザーなどというのは、この視点の一部である「顧客」のさらに一部でしかありません）。この4つの視点をバランスさせることでビジネスゴールに向かうというのが、バランストスコアカードおよび、その可視化手段である戦略マップというツールです。
それぞれの主要成功要因（CSF）を特定し、それに測定可能な重要業績評価指標（KPI）を設定し、ビジネスゴールである重要目標達成指標（KGI）を達成するための戦略を組み立て、可視化するのです。

no-title


さらに事業として考えるなら、1つの複合機の商品開発、マーケティングだけでなく、3年後、5年後の市場やビジネスを踏まえたグランドデザインを作成することが必要となるケースもあるでしょう。
その際には、CSR（企業の社会的責任）の観点から、製造拠点のある地域の住民や従業員の家族など、より多くの利害関係者を想定したデザインが必要になります。

プロジェクトの定義があってはじめて、デザインプロセスは決められる

ビジネスとして考えれば、こんな風にいくらでも利害関係者は膨らみます。
当該のデザインプロジェクトが何を目指し、どこからどこまでを範囲とするかで、そこに含まれる利害関係者とそれぞれの重要度は異なりますし、ゴールを達成するためにどういうプロセスを経てデザインを行うかも違ってきます。

結局、どういうプロセスで、何に重点をおいてデザインするかは、
  • プロジェクトの目的
  • ゴール
  • スコープ
  • 前提・制約条件
  • 利用可能なリソース
などを定義することでしか決められません。
スコープを決める中で、組織の内部、外部の利害関係者が明確になってきます。

プロジェクトの計画を立てるという作業はまさにプロジェクト全体の作業の流れ、進め方を決めるプロジェクトそのもののデザインです。プロジェクトの目的とゴールを明確にし、ゴールにたどり着くために必要な要素をリストアップし優先順位をつけ、それぞれのタスク間の関係性を明確にした上で、必要なリソースの配分を行うのです。このプロジェクトのデザインができなければ、実際にデザイン思考で仕事をまわすことはできません。

アサノさんが「クライアントそれぞれのコンテキストに合わせた導入方法がある」というとき、こうした前提となるプロジェクトの定義との関係を"コンテキスト"と呼んでいるのではないでしょうか？

その意味で、上でも書いたとおり、HCDの手法そのものもコンテキストにあわせて利用するのが妥当だと僕は考えます。

典型的なデザインの状況にはいつも方法のわからないものがつきまとう

デヴィッド・ケリー（IDEO創始者）もこういっています。

プロセスを学習すること、注意を払うことを止めるのは不可能です。企業は、いい結果を手にしたいのなら、デザインのプロセスを理解し、改良するために努力をし続けなければならないのです。
しかし、これはプロセスが標準化できるということではありません。ある問題を理解したとしても、同じ方法で次の問題も解決できるわけではありません。典型的なデザインの状況にはいつも、方法のわからないものがつきまといます。
デヴィッド・ケリー「第8章　デザイナーのスタンス」
テリー・ウィノグラード『ソフトウェアの達人たち―認知科学からのアプローチ』

こうしたプロジェクトそのものも含めて、デザイン思考です。

具体的なデザイン作業に入る前には、プロジェクトそのものの定義・デザインが必要です。
プロジェクトの定義がデザインプロセスを決めるための前提条件となります。

であれば、プロジェクトの定義を共有できていない、外部の人間が一般論で個別ケースのデザインプロセスに関して云々いうのは、そもそもお門違いとなるケースが多いでしょう。コンテキストを理解しない言説、行動はとかくトンチンカンなものになりやすいと思います。

　

関連エントリー

この記事へのコメント

コメントを書く

この記事へのトラックバック