人間中心設計的活動が根付かない
HCDの考え方ややり方が根付かないという声を耳にする。上長が異動になったとたんにHCD活動をやらなくなったという話も聞く。今回は、この問題を、組織文化と個人のチカラとの関係で考えてみたい。
組織は人だ
HCDの考え方ややり方がなかなか根付かない、という声をしばしば耳にする。また、HCD的な取り組みをやっていることで有名になった組織が、上長が変わったとたんに方針転換をしてしまい、HCD活動をやらなくなってしまったという話も聞く。
古くは「ヒューマンインタフェースガイドライン」(Apple Computer (1987) “Apple Human Interface Guidelines – The Apple Desktop Interface”, Addison-Wesley)を出して、インタフェースの考え方がすごい、と世間に言わしめたアップルコンピュータの例を引くことにしよう。アップル社では1986年から1994年まで、マウントフォード(Mountford, S.J.)のもとでHIG (ヒューマンインタフェースグループ 1986-1994)が活躍し[1]、マッキントッシュをマルチメディアマシンとするための努力や、QuickTimeの開発などが進められ、世界のインタフェース業界から注目を集めていた。1988年には有名なナレッジナビゲータのビデオも作成されている。
しかし、1992年にマッキントッシュの開発と先進技術グループ(ATG: Advanced Technology Group 1986-1997)とを分離する計画が示され、それぞれの先行きに不満をもった社員がやめてゆき、1993年にはHIGも閉鎖され、アップルは統合されたインタフェースデザインを推進する場所ではなくなってしまった。筆者の知人であったストライランド(Strijland, P.)やシェイド(Shade, L.)もこの時期にHIG、そしてアップルを離れている。この時の方針を出したのはアップルに戻ってきた(マウントフォードは実名を挙げていないのだが)ジョブス(Jobs, S.)であった。これ以後、デザイン性を重視したジョブス流の戦略により、マッキントッシュやアイフォーンが成功を収めてゆくことになったが、意匠デザインや戦略デザインの陰にかくれてしまった形のユーザビリティデザインについては、HIGが構築した伝統が生き残っていたからだろうか、アップルは使いやすい、という伝説となって今に引き継がれている。ATGにおける先端インタフェース技術の芽はつみとられ、各地に分散してしまったが、HIGのうみだした「使いやすさ」はノウハウ的にアップルに残ったのだろう。そのことはデザイン性を強調したジョブスにとっては幸いなことだったといえる。
アップルにおいて、その後、どのようにしてヒューマンインタフェースデザインの伝統が生き残ったについたのかについては想像の域を出ないのだが、ATGやHIGがそのままの形で生きながらえていたら、もっと革新的で素晴らしいインタフェースが生まれていたに違いないと筆者は考えている。
このアップルの事例のように、HCDについても、上長がそれに理解がないので職場に浸透しないとか、上長がそれに関心があるので職場では活き活きとHCDができている、あるいは、HCDに理解のあった上長が異動になってしまったとたん、職場の風土がすっかり変わってしまってHCDどころではなくなった等々の話を耳にする。今回は、この問題を組織文化と個人のチカラとの関係で考えてみたい。
組織文化、組織風土
組織文化(organizational culture)という概念がある。 企業文化ともいわれるこの概念は、ブリタニカ国際大百科事典においては
企業あるいは組織の構成員の間で意識的または無意識に共有されている思考や行動の様式。企業組織は創立時からさまざまな成功や失敗の経験を積重ねていくが、その過程で文化が形成され、新規の構成員に対してもそれが正しいものとして明示的にまたは暗黙のうちに伝達される。こうした文化的側面は企業の業績にも影響を及ぼしている。
と説明されている。
ただ、上意下達型の多くの組織においては、「組織の構成員」がみずからの力で文化や風土を醸成していくというよりは、トップダウン的に「組織の上部構成員」がそれを規定していく、あるいは外枠をはめてしまっていることが多い。
この点に関して、組織の成熟度という考え方がある。有名なものとして1990年に公開され、ISO/IEC TR 15504:1998-1999を経て、ISO/IEC 15504:2003-2006という形で成立したソフトウェアプロセスアセスメントの規格と、ISO/IEC 12207:1995というソフトウェアライフサイクルプロセスの規格がある。それがCMM (Capability Maturity Model)である。日本語では能力成熟度モデルと呼ばれる。
CMMの当初の目的は、ソフトウェア開発業者の水準を評価し、外部委託を行う際の参考にすることだった。成熟度の高い業者であれば安心して委託できるから、ということである。ISO 15504では能力水準を6段階に分け、
- レベル0: 不完全である(組織は当該プロセスを実施できない)
- レベル1: 実施されている(プロセスはその目標を達成している。各個人はプロセスを実行している)
- レベル2: 管理されている(プロセスに対する品質や時間や資源要求が理解され制御されている)
- レベル3: 確立されている(プロセスは組織によって特定のやり方で実施されており、資源は定義されている)
- レベル4: 予測可能である(プロセスのパフォーマンスは予測された資源と品質限界の範囲内である)
- レベル5: 最適化している(組織は特定の要求に対して信頼性を保ちながらプロセスを適合させている)
のように表現している。開発における各プロセスの成熟度水準を棒グラフの形にすると、能力プロフィルが得られ、全体としてどの程度の水準か、どのプロセスに問題があるかを確認することができる。
この考え方をユーザビリティに適用したものが、UMM (Usability Maturity Model)である。そこでは、人間中心設計プロセスを推進するために、
- システム戦略においてHCDの内容を確認する
- HCDの手続きを計画する
- ユーザーと組織の要求を特定する
- 利用状況を理解し、特定する
- デザイン解決案を作成する
- 要求に対してデザインを評価する
- 人間中心システムを設置して稼働させる
といった7つのプロセスの各々について基本活動を定義しており、それによって成熟度の評価を行う。その具体的な評価基準は表1[2]に示すとおりで、このそれぞれの項目について、未達成(N)、部分的達成(P)、大幅な達成(L)、完全な達成(F)という評価を行う。
表1 UMMのレベル
| ID | タイトル | ID | サブタイトル(属性) | ID | マネジメントの実践 |
|---|---|---|---|---|---|
| レベルX | 認知されていない | ||||
| レベルA | 認知されている | A1 | 問題認識 | A1.1 | 問題認識 |
| A2 | 実施されているプロセス | A2.1 | 情報収集 | ||
| A2.2 | 関連した実践活動の実施 | ||||
| レベルB | 考慮されている | B1 | 利用品質の認識 | B1.1 | 利用品質の訓練 |
| B1.2 | 人間中心的手法の訓練 | ||||
| B1.3 | 人間中心的インタラクションの訓練 | ||||
| B2 | ユーザへの焦点化 | B2.1 | ユーザへの配慮の訓練 | ||
| レベルC | 実装されている | C1 | ユーザの取り込み | C1.1 | ユーザの積極的な取り込み |
| C1.2 | ユーザエクスペリエンスの導出 | ||||
| C1.3 | エンドユーザが利用品質を規定する | ||||
| C1.4 | 継続的な評価 | ||||
| C2 | 人間工学 | C2.1 | 適切な人間中心的手法の提供 | ||
| C2.2 | 適切な設備とツールの提供 | ||||
| C2.3 | 利用品質技法の維持 | ||||
| C3 | 人間工学的スキル | C3.1 | 必要なスキルの決定 | ||
| C3.2 | 適切なスキルの開発 | ||||
| C3.3 | 適切なスタッフの配置 | ||||
| レベルD | 統合されている | D1 | 統合 | D1.1 | 人間工学的プロセスの統合 |
| D1.2 | 人間工学部門と組織とのインタフェースの促進 | ||||
| D1.3 | 適切な表現の利用 | ||||
| D2 | 改善 | D2.1 | 設計フィードバックの保証 | ||
| D2.2 | フィードバックにもとづく変更 | ||||
| D2.3 | フィードバックのタイミング | ||||
| D3 | 反復 | D3.1 | 反復設計によるリスクの最小化 | ||
| D3.2 | 設計による解決案の作成の反復 | ||||
| D3.3 | 反復制御のための設計目標の利用 | ||||
| レベルE | 組織化されている | E1 | 人間中心的リーダシップ | E1.1 | ユーザビリティ構想の管理 |
| E1.2 | 利用品質の体系的改善 | ||||
| E1.3 | 組織の人間中心的な改善 | ||||
| E2 | 組織的人間中心 | E2.1 | 人間中心のやり方の組織的実装 | ||
| E2.2 | 人間中心的な技能の受容 |
この表を見ると、日本企業におけるHCDの現状は、レベルX、レベルA、レベルBが多く、一部レベルCがある、といったところではないだろうか。レベルDとなると、かなり厳しいだろう。さらにレベルEはどうだろう…いや、実は、今回の問題提起は、レベルEというものは実在しうるのだろうか、ということなのだ。レベルEは、組織文化がベースからHCD的に組み立てられている状態ともいえるわけだが、一時的にそうなったように見えることがあったとしても、前述したように、それを推進している人が異動で消えてしまうとシュンとしぼんでしまうのが普通ではないだろうか。本当に、HCDは属人性から切り離された企業文化になりうるのだろうか。
HCDの属人性
HCDではなく、品質管理運動を見ると、こちらは日本においてうまく定着したといえるだろう。それは、特定部門によって主導された運動ではなく、TQC (Total Quality Control)という形で全社的に品質管理が徹底され、QCサークルといった根っこづくりの運動によって支えられたから、ということができる。ようするに従業員全員が上から下まで自分事として品質改善を考えるという姿勢が染み渡ったことの結果、レベルE相当になったのだといえるように思う。ユーザビリティもこうなっていればレベルEになったということができるのだが。
品質管理とは異なり、HCDの方は、まだ企業に導入されてから日が浅いこともあって、特定の人ががんばることによって成立しているところがある。つまり属人的なのである。その人が地位の上のほうであれば、その人がそのポジションにいる間はHCDがその組織の文化風土になったような気のすることがある。しかしそれは幻影であり長続きはしない。人事異動があれば、その一時的な文化風土はあっさりとかき消されてしまう。
もちろん、HCDの属人性を文化風土にすることは不可能ではない。しかし、それには少なくとも当該部署にはHCDが染みついており、新任の上司がそれを無視できないようにするくらいの必要はある。ともかく上意下達が基本になっている組織…これは日本だけの特徴ではなく、たとえばアメリカのGAFAですらそういう傾向があるわけだが…というものにおいては、特に上側にHCDの自覚や理解がなければHCDを組織の文化風土にすることは困難である。そして、HCDを文化風土にするためには、単にルーチン的にこれこれの手法を適用しています、これだけの手法を知っています等、のものではなく、ちゃんとHCDが開発成果に反映されており、売り上げにも貢献しているという認識が社内に浸透していなければならない。ともかくTQCのように、組織全体が動機づけられていない場合、HCDの組織文化への組み込みは極めて、おそらくはほとんど不可能であろう。
引用文献
[1] Mountford, S.J. (1998) “A History of the Apple Human Interface Group”, SIGCHI Bulletin, 30 (2), pp. 144-146
[2] Earthy, J. (1998) “Usability Maturity Model: Human Centredness Scale” INUSE WP5 Deliverable D5.1.4 Version 1.2
