人間中心設計 20のコンピタンスを大解剖 （2022年度版）
※重要※
本記事の内容はHCD-Netの公式見解ではありません。
筆者の私見による解説記事です。
🎄Money Forward Design Advent Calendar 2022の14日目の記事です🎄
今年もHCD-Netによる人間中心設計（Human Centered Design）専門家・スペシャリスト認定試験の時期になりました。
人間中心設計とは、モノや技術を中心としたものづくりではなく、利用者である人間のニーズを起点にものづくりをする設計思想です。国際標準ISO 9241-210では以下のように定義されています。
システムの使用に焦点を当て、人間工学及びユーザビリティの知識と手法とを適用することによって、インタラクティブシステムをより使えるものにすることを目的としたシステムの設計及び開発へのアプローチ。
アプリーケーションをはじめとしたサービスを設計する上で、人間中心設計の考え方は非常に重要です。
人間中心設計を実現するためのプロセスを行うには、UXデザイン、サービスデザイン、ユーザビリティ評価に関わる様々な能力・技能・知識が必要です。これらを人間中心設計推進機構では「コンピタンス」と定義しています。
人間中心設計専門家・スペシャリストの認定は、実務を通してコンピタンスを満たすスキルセットがあり、それを対外から認められた方が取得できます。それぞれの認定の応募条件には以下の違いがあります。
人間中心設計専門家（認定HCD専門家）：人間中心設計・ユーザビリティ関連従事者としての実務経験が、5年以上あること。
人間中心設計スペシャリスト（認定HCDスペシャリスト）：人間中心設計・ユーザビリティ関連従事者としての実務経験が、2年以上あること。
２つの認定共通：コンピタンスを実証するための実践事例が3つ以上あること。学歴については特に制限なし。大学院在学中における実務活動は実務経験年数として含むことは可能。
上記の応募条件を満たした上で、コンピタンスのスキルセットがあることを審査書類で証明する必要があります。
コンピタンスは全部で20個あり、3個のカテゴリに分類されます。
A. 基本コンピタンス：人間中心設計プロセスの各プロセスを理解し実施できる13のコンピタンス
B. プロジェクトマネジメントコンピタンス：プロジェクトマネジメントに関する3のコンピタンス（専門家のみ）
C. 導入推進コンピタンス：組織への人間中心設計導入を推進する4のコンピタンス（専門家のみ）
※ 2022年よりテクニカルコミュニケーション能力（プロジェクト及び活動を円滑に実施するために必要となる基礎的な3のコミュニケーション能力）は採点項目から外れたため、本記事でも解説の対象外とします。
本記事では、これら20個のコンピタンスを正しく理解するためのヒントと注意点をまとめました。今年度受験予定の方、また人間中心設計プロセスを学びたい方は、ぜひ参考にしてみてください。
「人間中心設計」は以降、本文内では「HCD」と省略します。
全コンピタンス共通の注意事項
各コンピタンスは、プロジェクトごとに以下の３つの情報を詳細にすることで、コンピタンスが発揮されたかどうか、客観的かつ再現可能なスキルかを実証する必要があります。
目的と対象
そのコンピタンスのステップが必要とされた背景や目的。さらに、何に対してそのコンピタンスを実施（既存サービス、ユーザー属性、調査結果、プロトタイプなど）したかを記します。体制と実施内容
どのようなチーム体制で、どのような条件下（実施場所、対象人数、時間、環境など）で、具体的に何をしたのか、なぜその方法を選んだのかを記します。体制では自身の役割も記します。工夫とアウトプット
規定のやり方ではなく、プロジェクト固有の事情に合わせて行なった工夫、および最終的に作成したアウトプットを記します。さらにそのアウトプットがどのように役立ったかを記します。
HCD-Netでは記述の注意点として以下のようにも記載されています。
教科書的な一般的記述ではなく、プロジェクト固有のポイントを具体的に記述してください。守秘義務の関係でシステムやクライアントについて具体的に書けない場合は、利用したHCDの技術・知識、HCD業務を進める上での工夫などに焦点を当てて記述してください。
コンピタンス記述書はなるべく具体的に書いてください。できれば既に対外発表しているなど、公開の制約が少ないプロジェクトを優先的に選んでいただくのが望ましいです。
「目的と対象」は、そのコンピタンスの発揮は何について行い、それはどういうことをしたいから（目的）なのか？を記載頂くことを想定しています。
A. 基本コンピタンス
A1. 調査・評価設計能力
このコンピタンスは以下のように定義されています。
人間中心設計プロセス（HCDプロセス）に基づく調査、評価の計画を企画提案できる能力のこと
・プロジェクトそのものの企画提案ではなく、プロジェクトの中で調査、評価のプロセスを取り入れるための計画や、企画提案を実施したことが対象となる
・実施するプロジェクトについて、HCDの観点から課題を適切に掴み、プロジェクトのゴールや目的に応じてHCDに関する適切な調査・評価計画を立案し、それらの具体的な実施内容を設計できる（評価／調査仕様を作成できる）ことが期待される
・プロジェクトの対象領域に関わる文化的な背景や知識などの情報を把握し、調査・評価すべき事項を判断・選択した上で、プロジェクトの進行に合わせてHCDに関わる調査・評価活動を計画することが求められる。また、個別の調査・評価活動の設計のみならず、プロジェクト全体で必要となる調査・評価活動の実施計画を作成することが期待される
アウトプット例：
以下を記述した調査・評価の企画書、提案書など
・調査・評価の目的
・実施内容
・用いる手法の特徴やそれを選んだ理由の説明
・プロジェクト全体におけるHCDプロセスの位置づけ
・調査・評価結果をどのように活用するか
現状の把握を目的に、UXリサーチなどの調査を行うための計画書を作成するステップです。複数の調査手法を採用している場合、そのような調査手順とした根拠など計画全体をここで振り返ります。特に以下のような内容を振り返り整理するとよいでしょう。
なぜ調査プロセスを踏む必要があったのか
調査によりプロジェクト全体として達成したいことは何か
どのような体制で計画し、自身の役割が何だったか
どのように調査手法を選定したのか
調査手法の選定の妥当性はどのように証明したのか
調査の有効性をどのように評価する計画としたか
調査計画がプロジェクトでどのように生かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
実際に行なった調査実施の詳細
実際に行なった調査結果の評価分析の詳細
実施途中の結果分析を踏まえて行なった計画の変更
ただし、あらかじめ変更を想定した計画（プランAとプランBを立てた等）であった場合は、本コンピタンスの工夫として書いておくとよいでしょう。
A2. ユーザー調査実施能力
このコンピタンスは以下のように定義されています。
ユーザーの利用状況や本質的要求などを把握するために、現場でユーザーの利用文脈調査を適切に実施できる能力のこと
・「ユーザーによって対象を評価すること」ではなく、「ユーザーやその周辺の状況を調査すること」に関わるコンピタンスである
・この能力は下記の2つの能力によって構成される
- 適用する調査手法や実施方法、対象者の選定について、調査の目的や位置づけに応じて適切に判断/選択する能力
- 選択された調査手法や実施方法などに基づいて、自ら適切に調査を実施する能力
- 上記の他、質問紙調査などユーザーなどに対して調査を実施し、ユーザーに関するデータを取得する手法であれば、それらの実施能力が対象となる
・選択された調査手法や実施方法などの実施能力として代表的なものに、以下がある
- インタビュー設計実施能力：対象者との対話を通じて、目的に対し適切な発話を引き出し、言語データを得る能力のこと。インタビュー実施にあたって対象者とラポールを形成し、調査の目的を深く理解した上で対象者の反応に対して適切な発言促進をかけ、事実や本音を引き出すことが期待される
- 観察実施能力：ユーザーと利用状況の観察を通じて、さまざまな事象に気づき、目の前で起きていることと既存知識を結びつけ、洞察を行う能力のこと。実施にあたっては、調査者自身の活動が対象者に与える影響を理解し、適切な方法でデータを取得することが期待される
アウトプット例：
・インタビュー設計実施能力：半構造化インタビュー、文脈的質問
・観察実施能力：行動観察、エスノグラフィー
現状の把握を目的に、実際にUXリサーチなどの調査をするステップです。調査から情報を最大限引き出すために、行ったタスクや工夫などをここで振り返ります。特に以下のような内容を振り返り整理するとよいでしょう。
その調査で得たい情報の狙いや期待は何か
どのような体制で実施し、自身の役割が何だったか
実施した各調査の具体的な内容（手法、対象ユーザーのセグメント、人数、期間・時間、場所・環境など）は何か
実施を円滑に進めるために事前にどのような情報整理をしたか
調査実施中に行った工夫は何か
調査の実施結果をどのようなアウトプットに残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
実際に行なった調査結果の評価分析の詳細
ペルソナやジャニーマップなどのモデル化したアウトプット（調査結果をダイレクトにモデル化した場合でも、それは分析した結果として、そのままでいいと判断したはずなので、HCDプロセスを飛ばさない）
調査結果を踏まえて、計画外の調査を追加したり、逆に中断して計画を見直し実施をやり直した事実などがあれば、理由と併せて本コンピタンスの工夫として書いておくとよいでしょう。
A3. 定性・定量データの分析能力
このコンピタンスは以下のように定義されています。
収集した定性的/定量的データを、目的に対して適切な手法を用いて分析し、ユーザーの特性を把握できる能力のこと
・A2コンピタンス（ユーザー調査実施能力）相当の調査によってユーザーの本質的欲求や利用状況などに関して収集された定性・定量データを分析し、
調査・評価の目的に沿った、ユーザーの行動や状態の特徴を把握できる能力のこと
・インタビュー発話などの定性データ、アンケート調査などの定量データをもとに分析を行い、ユーザーの本質的なニーズを抽出した、といったことが期待される
・さまざまな手法により取得したデータに対して、調査の目的とデータの性質に適した解析手法を用いて分析し、客観性・再現性のある結果を抽出することが期待される
データの例：
・質的データ：インタビュー発話データ、操作映像、音声
・定量データ：質問紙回答、ライフログ、アクセスログ、操作パフォーマンス系データ（生理計測値、メンタルワークロードなど）
解析法の例：
・定性的分析：グラウンデッドセオリー法、KJ法、上位下位関係分析、KA法、導線解析
・定量的分析：記述統計、推測統計、多変量解析
現状の把握を目的に、調査で得た情報・データを分析するステップです。調査で得たデータの形は様々なので、それらをどう分析したか、その分析が妥当だったかを示すことがポイントです。特に以下のような内容を振り返り整理するとよいでしょう。
分析のステップが必要になった背景は何か
分析した調査結果データはどれか
その調査結果データをなぜ分析する必要があったか
どのような体制で分析し、自身の役割が何だったか
分析の手法やプロセスはどのようなものだったか
分析手法の選定の妥当性はどのように証明したのか
分析結果をどのようなアウトプットに残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
分析結果からペルソナやジャニーマップなどのモデル化を行った内容詳細
分析した結果、そのまま次ステップのモデル化が難しいという判断になった時や、それにより新たな調査が必要になった時は、その判断をした経緯などを本コンピタンスの工夫として書いておくとよいでしょう。
A4. 現状のモデル化能力
このコンピタンスは以下のように定義されています。
ユーザーの利用状況や本質的欲求などについて、調査データや分析結果に基づいてモデル（構造）化できる能力のこと
・モデルとは、複雑なシステムや現実の物事から、その本質（あるいは理想的状態）を抽出し、図や模型、数式などの形式に表現したもの。モデルは、概念モデル・物理モデル・数学モデルなど多数ある
・A4では現状のモデル化を対象とし、理想的なユーザー体験の構想・提案は対象外（A5. ユーザー体験の構想・提案能力に該当）
・ユーザーの価値観・日常行動・業務の作業内容など、モデルを使用する目的に応じて、現状の活動・振る舞い・情報などをモデル化することが期待される
・モデル化にあたっての、ユーザーの現状を、調査データ（A2）および分析結果（A3）などを用いて記述することが期待される
アウトプット例：
ペルソナ、ワークモデル分析、KJ法、カスタマージャーニーマップ(AsIs）、KA法（価値マップ）
現状の利用者の把握を目的に、モデル化（構造化）するフェーズです。UXデザインの代表的な成果物であるペルソナやジャーニーマップを制作するタイミングでもあります。しかし、すべてのプロジェクトで必ずしも必要な成果物ではありません。なぜ必要になったのかを中心に、以下のような内容を振り返り整理しましょう。
なぜモデル化のステップが必要になったか
現状のモデル化として採用した手法とは何か
１つの成果物に対して何種類のユーザーをモデル化したか、またなぜその種類数が必要だったのか
どのような体制でモデル化を進め、自身の役割が何だったか
モデル化するために活用した調査・分析データは何か
データからどのようなプロセスを経てモデル化したか
モデル化でのプロジェクト特有の工夫は何だったか
モデル化によってどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
モデル化したユーザーが求める問題に対しての、解決策の導出プロセスやアイデア
未来のユーザー体験の提示
ペルソナやジャーニーマップで定義する軸は、プロジェクトの特性により最適な形が異なることが多いため、アレンジをした軸があれば、工夫として記しましょう。
A5. ユーザー体験の構想・提案能力
このコンピタンスは以下のように定義されています。
製品・システム・サービスにおける理想的なユーザー体験を構想・提案できる能力のこと
・ユーザーの本質的な要求やニーズ特性に基づいて、対象製品やシステムおよびサービスの利用に関するさまざまなタッチポイント（一連の関わり合いの各場面）における、ユーザーの満足をもたらすような理想的なユーザー体験を構想・提案すること
・A5では理想的なユーザー体験の構想・提案を対象とし、現状のモデル化は対象外（A4. 現状のモデル化能力に該当）
・理想的なユーザー体験のコンセプトや、対象製品・サービスとユーザー体験との関係をわかりやすく表現し、関係者に説明することが期待される
アウトプット例：
カスタマージャーニーマップ(ToBe）、UXDコンセプトツリー、ストーリーテリング、理想シナリオ
現状のユーザー課題に対して、解決のアイデアを導き、それが実現した未来をToBe像として描くフェーズです。ここでは様々な解決アイデアが検討されますが、アイデア群を整理しアウトプットすることでアイデアの精度を高められ、関係者との合意形成もスムーズになります。
ここでは、以下のような内容を振り返り整理しましょう。
なぜユーザー体験の構想ステップが必要になったか
ToBe像を描く対象としたものは何で、どのくらいの数の構想をしたか
どのような体制でアイデア導出〜ToBe像の構想〜提案までのプロセスを行い、自身の役割が何だったか
どのようなToBe像を描き、それが良いと判断した根拠は何か
そのToBe像が良いと判断した根拠となる対象の現状モデル（A4のアウトプット）はどのタイプで、なぜそのタイプを対象に選んだか（特に、現状モデルのタイプが複数あった場合）
構想や提案時に、前提となる現状モデル（A4のアウトプット）を関係者に伝えるために工夫した点は何か
ToBe像の構想や提案のためにどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
現状モデル化（A4）そのもののアウトプット作成のプロセス
ToBe像からさらに踏み込んだ仕様作成に関わる詳細
A6. 新製品・新規事業の企画提案力
このコンピタンスは以下のように定義されています。
ユーザー理解から生まれた視点、価値から生まれた新たなコンセプトを、関係者に提案し実現に向けて合意をとれる企画提案能力のこと
・製品、システム、サービス、あるいは事業や研究テーマなどに関わるコンセプトが対象となる。人間中心設計（HCD）視点によるイノベーティブな企画提案のための活動を計画できる能力も含む
・所属業界や所属組織においてこれまで生み出されなかった新しい概念に対し、調査結果やモデルなどを活用し、アイデアの具現化だけでなく実現へ向けた提案ロジックの構築も期待される
アウトプット例：
ビジネスモデルキャンバス、ビジョン提案型デザイン手法、ピッチ資料、事業企画書、リサーチ分析結果
新製品・新規事業に関わるコンピタンスのため、サービス改善のプロジェクトは対象外です。A5で描いたToBe像を新製品・新規事業としてビジネス化・マネタイズ化するための調査・企画・提案が対象です。以下のような内容を振り返り整理しましょう。
提案のための根拠とした、ユーザー調査結果のなかの行動・ニーズは何で、なぜそのユーザー調査結果が重要と見なしたか
合意形成のために必要と考え準備した企画書に含めた内容は何か
どのような体制で企画・提案を行い、自身の役割が何だったか
企画にあたり改めて行った調査は何か（市場調査やPEST分析などのフレームワークを用いた分析が対象）
提案の形式は何（ドキュメント回覧のみまたはプレゼンなど）で、それに応じて行った工夫は何か、提案の流れはどようなものだったか
自身の提案やアウトプットがどのような成果になったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
ユーザーのニーズからアイデアを導出し、ToBe像を描くプロセス
新製品・新規事業の提案からさらに踏み込んだ仕様作成に関わる詳細
A7. ユーザー要求仕様作成能力
このコンピタンスは以下のように定義されています。
ユーザー調査データや分析結果および構想・提案したユーザー体験を用い、ユーザー要求仕様として表現できること。また、それらに対し適切な優先順位、評価指標を設定できること
・具体的なシステムに対する要件定義ではなく、ユーザーが実現したい内容、解決したい課題についての記載が求められる
・顕在化している要求だけでなく、ユーザーの本質的要求（潜在的要求）についても抽出できていることが期待される
アウトプット例：
ユーザーシナリオ、ユーザー要求仕様書、コンセプトシート、利用品質メトリクス、アクセシビリティを考慮し拡張したペルソナなど
いままでのステップで整理したToBe像を実現するために、ユーザーがサービスと通してとる行動プロセスを整理し、その際のサービスのタッチポイントでどのような課題・ニーズがあるかを整理します。以下のような内容を振り返り整理しましょう。
なぜこのユーザー要求仕様作成のプロセスが必要になったか
ユーザー要求仕様を整理した範囲はどこか
どのような体制でユーザー要求仕様を検討し、自身の役割が何だったか
ユーザー要求仕様の根拠としたユーザー調査結果は何で、なぜそれが重要だったか
ユーザー調査結果からどのようなプロセスでユーザー要求仕様を決めたか
ユーザー要求仕様を決めるにあたり、影響範囲、実現可能性、実施優先度で配慮したポイントは何か
ユーザー要求仕様としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
抽象度の高いToBe像のコンセプトに近いイメージの詳細
サービスやシステムの要求定義に関わる詳細
このステップは、ユーザー体験の構想・提案能力（A5）のステップと混同してしまうことが多いです。A5は理想系を描きますが、それを実現するかはまだ不透明です。
一方で、このユーザー要求仕様は、満たすべきユーザーの要求が確定している状態を指します。仕様書として記されたものは次のステップでシステム化することを求められます。
A5はTo Be（理想解）、A7はCan Be（現実解）という区別をすると分かりやすいかもしれません。
A8. 製品・システム・サービスの要求仕様作成能力
このコンピタンスは以下のように定義されています。
ユーザー要求仕様をもとに、製品・システム・サービスに必要な機能を定義し、それらを要求仕様として表現できる能力のこと
・ユーザーの要求の定義ではなく、それを受けて製品・システム・サービスを具現化する方向性を示した要求仕様についての記載が求められる
・各スコープにおける相互の影響や優先順位、実現可能性も含めた、具体的かつ現実的な機能の定義が期待される
・アクセシビリティに関する要求に優先度を付けた仕様やアクセシビリティガイドラインを適切に活用できることも期待される
アウトプット例：
基本設計書、要求仕様書、ユーザーストーリーマッピング、Design Doc、製品要求仕様書（PRD）
ここからようやくサービスやシステムの要求仕様を整理します。システムの場合、どのような機能をもつことでユーザーニーズが満たされるかを定義するステップです。個々の画面を設計するステップではありません。以下のような内容を振り返り整理しましょう。
なぜこのサービスやシステムの要求仕様作成のプロセスが必要になったか
サービスやシステムの要求仕様を整理した範囲はどこか
どのような体制でサービスやシステムの要求仕様を検討し、自身の役割が何だったか
サービスやシステムの要求仕様の根拠としたユーザーの要求仕様は何で、なぜそれが重要だったか
ユーザー要求仕様からどのようなプロセスでサービスやシステムの要求仕様を決めたか
サービスやシステムの要求仕様を決めるにあたり、影響範囲、実現可能性、実施優先度で配慮したポイントは何か
サービスやシステムの要求仕様としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
抽象度の高いToBe像のコンセプトに近いイメージの詳細
システム・サービスの要件定義に関わる詳細
A9. 情報構造の設計能力
このコンピタンスは以下のように定義されています。
製品やシステム、サービスの使用に際し、ユーザーが情報を理解しやすく、またユーザー自身が情報を探しやすくなるような構造を、要求仕様に基づいて設計できる能力のこと
・ユーザーニーズとコンテンツの属性をもとに適切な情報構造を設計したり、ラベリングの一貫性を持たせたりできることが求められる。Webやアプリのみに関わらず、ユーザーにどのような情報構造を設計し、わかりやすく提示するかが重要
・情報構造の設計の意図を持たず、ワイヤーフレームを書いただけでは情報構造の設計能力とは言えないので注意
アウトプット例：
コンテンツインベントリ、サイトマップ、状態遷移フロー、命名規則リスト、類義語リスト、メタデータ仕様書、ナビゲーション設計書、API設計書、メニュー構造、ドキュメントの構造、ワイヤーフレーム
システムの場合、ここでは実際の画面のラインナップ、画面同士の関係性、各画面内で提示すべき要素など、いわゆる情報設計（Information Architecture）をするステップです。まだ実際の画面のビジュアルを制作するステップではありません。以下のような内容を振り返り整理しましょう。
なぜ情報設計のプロセスが必要になったか
サービスやシステムの情報設計をした範囲はどこか
どのような体制で情報設計をし、自身の役割が何だったか
情報設計の根拠とした前ステップのアウトプットは何で、なぜそれを利用したか
どのようなプロセスで情報設計を進めたか
情報設計をする上で考慮したポイントは何か（ユーザビリティ、ラベリングのルール決め、実現性や拡張性への配慮など）
情報設計としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされ、どのような成果があったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
実際の画面のビジュアルデザイン制作に関する詳細
画面の操作やインタラクションに関わる仕様の詳細
A10. デザイン仕様作成能力
このコンピタンスは以下のように定義されています。
ユーザー要求仕様・システム要求仕様・情報構㐀設計をもとに製品・システム・サービスをデザインでき、仕様あるいは実体として表現(視覚化)できる能力のこと
・デザイン対象となるものとしては、インタフェース、画面遷移、UIガイドライン、物理的な操作インターフェース、LED報知パターン、報知音、取扱説明書などがある
・仕様あるいは実体として表現（視覚化）できる点にとどまらず、その表現（視覚化）を適切にプレゼンテーション・資料化・改善案の提示ができることも期待される
アウトプット例：
インタフェース仕様書、ワイヤーフレーム、UIガイドライン、デザインシステム、報知仕様書、取扱説明書、ハードウェアデザイン設計書
対象がシステムの場合、画面のビジュアルや操作、インタラクションを定義するステップです。UIガイドラインやデザインシステムの作成も対象です。制作する画面数によって最適な進め方が様々なので、自身のプロジェクトではどのように進めたかを振り返り、以下のような内容を整理しましょう。
なぜデザイン仕様作成のプロセスが必要になったか
デザイン仕様作成をした範囲はどこか
どのような体制でデザイン仕様作成をし、自身の役割が何だったか
デザイン仕様作成の元とした前ステップのアウトプットは何で、なぜそれを利用したか
どのようなプロセスでデザイン仕様作成を進めたか
デザイン仕様作成をする上で考慮したポイントは何か（デザイン案の提案、仕様情報の連携方法、ガイドライン上の配慮など）
デザイン仕様作成としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされ、どのような成果があったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
情報設計に関わる詳細
実際に動作を確認できるレベルのプロトタイプ制作に関わる詳細
このステップは他のデザイナーに制作自体を委託し、自身では制作に関して手を動かしていない場合が見受けられます。その場合は、デザイナーのアウトプットに対する品質担保に関わる取り組み、仕様書やガイドラインなどのアウトプット作成に関する内容などを記すとよいでしょう。
A11. プロトタイピング能力
このコンピタンスは以下のように定義されています。
製品・システム・サービスの企画や開発の途中段階で、ユーザーの要求仕様や製品・システム・サービスの要求仕様を、設計案やデザイン案として提示するためのプロトタイプを作成できる能力のこと
・プロトタイプには、ペーパープロトタイプから詳細プロトタイプまであるが、単なる試作ではなく、各開発フェーズ・目的・作成期間に応じた、適切なプロトタイプの作成が期待される
・プロトタイプの作成にあたっては、主に、開発初期フェーズや検証フェーズで、短期間かつ迅速なラピットプロトタイピングを主導することが期待される
・作成されたプロトタイプを用いた評価によって得られた結果は、製品・システム・サービス要求仕様およびデザイン仕様に反映されることが期待される
アウトプット例：
コンセプトムービー、各種モックアップ、シミュレーション、アクティングアウト（製品やサービスを使用する場面の寸劇）
対象がシステムの場合、要求仕様を画面のデザインに落とし込み、実際に動作をイメージできる形で制作し、実装前に有効性を評価するステップです。一般的にはAdobe XDやFigmaなどのプロトタイピングツールで、インタラクションや画面遷移を再現したものが該当します。
プロジェクトによっては、フロントエンドのみで実装したHTMLモックアップなども対象です。画面だけではなくコンセプト動画など、制作物を評価しブラッシュアップができればプロトタイピングに該当します。以下のような内容を振り返り整理しましょう。
なぜプロトタイピング実施のプロセスが必要になったか
プロトタイピング実施をした範囲はどこか
どのような体制でプロトタイピングを実施し、自身の役割が何だったか
プロトタイピング実施の元とした前ステップのアウトプットは何で、なぜそれを利用したか
どのようなプロセスでプロトタイピングを進めたか
プロトタイピングを実施する上で仮説検証のポイントは何で、検証のための工夫は何だったか
プロトタイピングとしてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされ、どのような成果があったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
実際の画面のビジュアルデザイン制作に関する詳細
プロトタイピング後の評価検証に関する詳細
評価とブラッシュアップを目的としない実装の詳細
A12. ユーザーによる評価実施能力
このコンピタンスは以下のように定義されています。
製品・システム・サービスの企画や開発の初期段階、または途中段階でユーザーに評価対象を提示することにより、評価対象がユーザーに適しているかどうかを判断するためのテストを適切に実施でき、プロジェクトの目的に合わせ結果を適切に分析できる能力のこと
・「ユーザーを調査すること」ではなく、「ユーザーによって対象を評価すること」に関わるコンピタンスである
・提示する評価対象は、企画や開発の初期段階においては現状の製品や先行する競合製品などが対象となることが多い。これらを先行事例として評価することで問題点を洗い出すことなどを目的として実施される。 開発の途中で実施する場合は、プロトタイプなどその時点での成果物を評価対象とし、ある仮説を検証することなどを目的として実施される
・プロジェクト全体における評価の目的によって、適切な評価対象を選択することが求められる
・適用する評価指標や評価基準、実施方法、対象者（ユーザー）、評価メンバーの選定については、各開発フェーズ、ユーザーの利用時（運用）において評価の目的や位置づけに応じて適切に判断・選択することが期待される
・実施にあたっては、対象者にかかる身体的・心理的負荷や心理的バイアスを理解して、評価課題や評価環境を適切に設定し、対象者に適切な教示を行うことが期待される
・評価結果は、認知科学などの学術的な知見に基づいて客観的に分析し、次の活動に役立てることが期待される
アウトプット例：
コンセプト受容性評価、αテスト、シナリオの受容性評価、製品・システム・サービスのユーザビリティ評価
ユーザーによる評価は、主には制作したプロトタイピング（A11）を活用した評価のステップです。画面に関わるプロトタイプ評価で代表的なものは、実際にその画面をユーザーに操作してもらい有効性を評価するユーザビリティテストです。評価検証での以下の内容を振り返り整理しましょう。
なぜユーザーによる評価のプロセスが必要になったか
ユーザーによる評価をした範囲はどこか
実施した評価検証の具体的な内容（手法、対象のユーザーのセグメント、人数、期間・時間、場所・環境など）は何か
評価する上で有効性を判断するための評価指標・基準に何を用いたか
どのような体制でユーザーによる評価を実施し、自身の役割が何だったか
どのようなプロセスでユーザーによる評価を進めたか
ユーザーによる評価で、ユーザー負担を減らすために行なった工夫は何か
評価結果をどのように分析しブラッシュアップを行なったか
ユーザーによる評価としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされ、どのような成果があったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
評価に関わらないユーザーに対するインタビューなどの調査の詳細
ユーザーに対してではなく、専門家やプロジェクト関係者による評価
A13. 専門知識に基づく評価実施能力
このコンピタンスは以下のように定義されています。
人間中心設計（HCD）および関連する専門知識を用いて、製品・システム・サービスのユーザビリティ、ユーザーエクスペリエンス、ユーザーインタフェースなどの良し悪しの判断・指摘ができる能力のこと
・実施にあたっては、認知科学などにおける学術的な理論や法則、およびユーザビリティの経験則などに基いて、客観的に評価を記述できることが期待される
・適用する評価手法や実施方法、評価メンバーの選定について、評価の目的や開発のフェーズ、ユーザーの利用状況に応じて適切に判断・選択することが期待される
アウトプット例：
ヒューリスティック法、ウォークスルー法、タスク分析
ユーザーによる評価ではなく、ユーザビリティやUXの知見を持つ専門家が評価して問題点を抽出するステップです。プロトタイピング（A11）に対する評価だけではなく、改善プロジェクトにおける現行に対する評価も対象です。そのため、プロジェクトの序盤でこのステップが実施される場合もあります。以下のような内容を振り返り整理しましょう。
なぜ専門家評価のプロセスが必要になったか
専門家評価をした範囲はどこか
利用した専門家評価の手法は何か
どのような体制で専門家評価を実施し、自身の役割が何だったか
どのようなプロセスで専門家評価を進めたか
専門家評価で客観的に評価するために行なった工夫は何か
専門家評価としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされ、どのような成果があったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
ユーザーによる評価の詳細
プロジェクト関係者による通常のレビューの詳細
B. プロジェクトマネジメントコンピタンス
B1. プロジェクト企画能力
このコンピタンスは以下のように定義されています。
人間中心設計を適用するプロジェクト（HCDプロジェクト）を企画、計画できる能力のこと
・プロジェクトに対し、なぜHCDを適用する必要があるのかを関係者に説明し、企画承認に向けた取り組みを実施できることが求められる
・プロジェクトに必要な要件や前提事項を明確にし、プロジェクトのゴール、プロセス、アクティビティ、成果物、チーム構成などを適切に企画することが期待される
アウトプット例：
プロジェクト企画書、プロジェクト計画書など
HCDプロセスを導入したプロジェクト全体の企画・計画が対象です。以下のような内容を振り返り整理しましょう。
なぜHCDを導入するプロジェクトである必要があったか
何を背景に発足したHCDプロジェクトなのか
HCDプロジェクトの概要は何か
どのような体制でHCDプロジェクトの企画提案を実施し、自身の役割が何だったか
HCDプロジェクト企画実現に向けて自身で行なった取り組みは何か
HCDプロジェクトの企画で検討した要素（前提条件、ゴール、プロセス、アウトプット、体制、スケジュール、達成指標など）は何か
自身が作成したアウトプットは何か
自身のアウトプットがプロジェクト実施時にどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
ユーザー調査ステップのみの計画の詳細
プロジェクト実施中の管理・調整に関わる詳細
チームビルディング・運営に関わる詳細
B2. プロジェクト調整・推進能力
このコンピタンスは以下のように定義されています。
人間中心設計を適用するプロジェクト（HCDプロジェクト）に対するプロジェクトマネジメント能力のこと
・プロジェクトの実現に向けて、HCDプロセスと各種活動の本質的な意味を十分に理解し、目標達成に向けて利害関係者の調整を含め都度、適切に取り組みを実施できることが求められる
・プロジェクトの推進にあたって関係するさまざまな部門やチーム、クライアントとの調整、および、プロジェクトのリソース（予算、人材）およびスケジュール、リスクなどを管理/調整することが期待される
アウトプット例：
プロジェクト計画書、マスタースケジュールなど
HCDプロセスを導入したプロジェクトの開始以降の調整・推進が対象です。以下のような内容を振り返り整理しましょう。
HCDプロジェクトとしての管理対象は何だったか（予算、スケジュール、人的リソースなど）
調整・推進に関わるのプロジェクトの課題は何だったか
上記の課題を解決するために、特にHCDプロジェクトとして工夫したことは何か（社内・社外のプロジェクト関係者調整、予算・人材のリソース管理、スケジュール調整、リスク管理など）
自身の調整・推進の工夫によってどのような成果につながったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
プロジェクトの企画に関わる詳細
プロジェクトのチームビルディングや目標管理などに関わる詳細
デザイナー人材育成に関わる詳細
B3. チーム運営能力
このコンピタンスは以下のように定義されています。
人間中心設計を適用するプロジェクト（HCDプロジェクト）において、チームビルディングやチームワークを維持・仲介・推進できる能力のこと
・プロジェクトの実現に向けて、メンバーのスキルを十分に理解し、目標達成へ向けてアウトプットが最大化するように、チームを運営できることが求められる。HCDに関わる考え方の共有や、手技法の活用が含まれることが望ましい
・プロジェクトチームがHCDの目標を共有し、個々のプロジェクトメンバー間のコミュニケーションに配慮し、その能力を十全に発揮できるようリードすることが期待される
アウトプット例：
プロジェクト計画書、プロジェクト憲章、WBSなど
HCDプロセスを導入したプロジェクトで開始時に行うチームビルディングや、開始以降の運営が対象です。以下のような内容を振り返り整理しましょう。
HCDプロジェクトの運営概要（チーム構成、体制、運営期間）はどうだったか
チーム運営でHCDプロセスの導入効果を最大化するために工夫したことは何か
自身の運営の工夫によってどのような成果につながったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
プロジェクトの企画に関わる詳細
プロジェクト実施中の管理・調整に関わる詳細
デザイナー人材育成に関わる詳細
HCDプロジェクトでは、HCDに見識のないメンバーも体制に含まれていることが想定されます。そんな中で、HCDの価値をどのように伝え、プロジェクトを通して継続的に啓蒙し、理解を促すために行なってきたことがポイントです。
C. 導入推進コンピタンス
C1. HCD適用・導入設計能力
このコンピタンスは以下のように定義されています。
人間中心設計プロセス（HCDプロセス）の組織への導入やそれを実践する体制を構築する企画・計画が立案できる能力のこと
・HCDプロセスの導入にあたって関係者の同意を取り付けるための交渉力や、継続運用が可能な仕組みを構築できる能力も含める
・一つのプロジェクトへHCDプロセスを導入した事例は対象外
・複数のプロジェクトへHCDプロセスを導入し、結果としてプロセスが組織に導入された事例を対象とする
・マネジメントの立場から、組織のポリシー（理念・戦略・方針）に沿ったユーザビリティやユーザエクスペリエンスの目標を設定し、組織や部門に対して、HCDプロセスの全部あるいは一部を導入する計画を立案することが期待される
・HCDプロセスの実施にあたり、以下を行うことが期待される。
- 導入の対象とする組織に合わせた実施体制の構築および適用する手技法を選択すること
- ガイドラインの策定、ドキュメントの整備、標準化、運用ルールの策定などを行うこと
アウトプットの例：
HCDプロセスを社内（あるいは社外）の開発プロセスへ導入する稟議書、提案書
補足：社外の事例とは、自身がコンサルタントを行い、相対する組織にHCDプロセスが導入された場合や、ガイドラインが策定された場合などを想定
HCDが浸透していない組織に対する導入の取り組みがあれば、社内か社外かに関わらず本コンピタンスの対象です。
１プロジェクトに対するプロジェクトチームへの個別の取り組みは対象外ですが、特定プロジェクトの取り組みの成果を、組織全体に展開できた場合は対象です。その際、組織全体への展開まで含めて手順を振り返りましょう。
HCDの組織導入そのものが目的のプロジェクトの場合、個別に１つのプロジェクトとして審査書類に記します。
HCD組織導入における以下のような内容を振り返り整理しましょう。
HCDプロセスの組織導入が必要になった背景・組織課題は何か
HCDプロセス導入の対象組織と範囲はどこか
どのような体制でHCDプロセスを導入し、自身の役割が何だったか
HCDプロセス導入をどのような手順で進めていったか、またその手順にした理由はなぜか
HCDプロセス導入にあたり整備したものは何か（ガイドライン、手法の選定など）
自身が作成したアウトプットは何か
自身のアウトプットがどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
プロジェクト個別のHCD導入に関する詳細
組織への教育プログラムの開発に関する詳細
デザイナー人材育成に関わる詳細
C2. 教育プログラム開発能力
このコンピタンスは以下のように定義されています。
人間中心設計（HCD）に関する教育プログラムを開発できる能力のこと
・特定の組織や組織の規模に限らず、教育機関などにおけるプログラムやカリキュラムの開発を対象とする
・教育プログラムは、社内で利用するもの、社外で利用するものの両方を対象とする
・個別のプロジェクト内でのOJTや自主的な教育・学習活動については対象外とする（OJTや自主的な教育はC3へ記載）
・HCDプロセス、またはHCDに関する手技法などに関する教育プログラムを開発することが期待される
・HCDに関する体系的な知識やノウハウが得られる教育プログラムやカリキュラムの開発が期待される
アウトプット例：
HCDに関する教育・研修プログラム、HCDに関する学習教材
HCDに関する統一的な教育プログラムを開発していれば、社内か社外かに関わらず本コンピタンスの対象です。
１プロジェクトに対するプロジェクトチームへの教育は対象外ですが、特定プロジェクトの教育プログラムの成果を、組織全体に展開できた場合は対象です。その際、組織全体への展開まで含めて手順を振り返りましょう。
HCD教育プログラム開発そのものが目的のプロジェクトの場合、個別に１つのプロジェクトとして審査書類に記します。
以下のような内容を振り返り整理しましょう。
HCDの教育プログラム開発が必要になった背景・組織課題は何か
教育プログラムを導入する対象組織と範囲はどこか
どのような体制で教育プログラムを開発し、自身の役割が何だったか
教育プログラム開発をどのような手順で進めていったか、またその手順にした理由はなぜか
教育プログラムで組んだカリキュラムや教材の工夫は何か
自身が作成したアウトプットは何か
自身のアウトプットがどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
プロジェクト個別のHCD教育プログラムに関する詳細
組織へのHCDプロセス導入に関する詳細
デザイナー人材の個別の育成（OJTやスポット研修）に関わる詳細
C3. 人材育成能力
このコンピタンスは以下のように定義されています。
人間中心設計（HCD）に関する教育や訓練をおこなう機会を設けたり、みずから組織・メンバー・関係者のHCDに関するスキルを向上できる能力のこと
・適切な人材育成計画を立案し、OJTによる訓練、業務内外の研修、講義、ワークショップ、対話など、HCDを学ぶ機会を作ること
・教育プログラムの開発は除く（教育プログラムはC2に記載）
・講師やファシリテーターを担当することにより、組織・部門・プロジェクトメンバー・関係者のHCDに関するスキルを向上させることが期待される
アウトプット例：
講師やファシリテーターを行った研修や研修プログラムの概要（実施日時、参加人数、場所、実施概要）
デザイナー人材育成のための個別の教育計画や継続的な指導が対象です。組織統一の教育プログラムは対象外です。育成対象者に対して、プロジェクトを通した経験や研修受講の機会を提供しフォローします。
組織やプロジェクトに対するスポットでの勉強会主催なども本コンピタンスに該当します。
以下のような内容を振り返り整理しましょう。
HCDの人材育成が必要になった背景・組織課題は何か
人材を育成する対象組織・チーム・人は誰か
どのような体制で人材育成を実施し、自身の役割が何だったか
育成対象者のバックグラウンドに配慮し、どのような育成プロセスを進めていったか
研修参加者の属性を踏まえて、講師やファシリテータとして行なった工夫は何か
教育に際して自身が作成したアウトプットは何か
自身のアウトプットがどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
プロジェクト個別のHCD教育プログラムに関する詳細
組織へのHCDプロセス導入に関する詳細
デザイナー人材の個別の育成（OJTやスポット研修）に関わる詳細
C4. 手法・方法論開発能力
このコンピタンスは以下のように定義されています。
人間中心設計（HCD）に関する手技法や、方法論を開発できる能力のこと
・HCDの実践を支援する開発プロセスや開発方法論あるいは手技法の研究/開発、およびHCDの実践に必要なコンピタンスに関わる研究/開発を行い、独自の整理・体系化・一般化に基づき新たな手法化、方法論化を行うこと
・独自の研究に留まらず、組織内外への積極的な公表やドキュメント化など、成果を外部化することが期待される
アウトプット例：
NEM法、UXカーブ法、SEPIA法、開発した手法が掲載された社内外のメディア（論文、雑誌、Web媒体など）
すでにある方法論での実践ではなく、研究に基づく新たな方法論の確立が対象です。このコンピタンスは筆者の未体験ゾーンで、具体的な解説は難しいため、上記のアウトプット例で紹介されている方法論のひとつをサンプルとしてご紹介します。
NEM法（Novice Expert ratio Method法）：設計者とユーザの間に生まれる操作モデルのギャップを客観的なデータとして抽出する定量的評価手法。両者の操作時間（ある操作ステップから次の操作ステップに移るまでの時間）を比較することにより操作性の問題箇所を効率よく発見することができる。
このようなユーザビリティやUXをどうやって定量評価するかは、多くのプロジェクトで課題になりやすいトピックです。みなさんが関わるプロジェクトでも、新たな手法を考案しメディアで発表すれば、このコンピタンスもクリアできるかもしれません。
さいごに
人間中心設計専門家・スペシャリストは、本記事で解説した内容を読めば誰でも審査書類が書けるという性質のものではありません。実際にHCDプロジェクトを能動的に推進しプロジェクト関係者と合意形成を上手くしている状態でないと、なかなか中身のある内容は書けないと考えています。
しかし、その試練を乗り越え、人間中心設計専門家・スペシャリストへの応募と審査書類を書くことで、自身の今までの取り組みを振り返り、経験の不足ポイントを確認することができます。
今後の自身キャリアを計画する上でのメリットになることは間違いないので、ぜひこの機会にキャリアの総括を行ってみてはどうでしょうか。2023年に向けた、さらなるキャリアアップのきっかけにしましょう。
明日はShinoさんによるデザイン組織のマネジメント白書をお届けします。ぜひご期待ください 🎉