人間中心設計 20のコンピタンスを大解剖 (2022年度版)
🎄Money Forward Design Advent Calendar 2022の14日目の記事です🎄
今年もHCD-Netによる人間中心設計(Human Centered Design)専門家・スペシャリスト認定試験の時期になりました。
人間中心設計とは、モノや技術を中心としたものづくりではなく、利用者である人間のニーズを起点にものづくりをする設計思想です。国際標準ISO 9241-210では以下のように定義されています。
アプリーケーションをはじめとしたサービスを設計する上で、人間中心設計の考え方は非常に重要です。
人間中心設計を実現するためのプロセスを行うには、UXデザイン、サービスデザイン、ユーザビリティ評価に関わる様々な能力・技能・知識が必要です。これらを人間中心設計推進機構では「コンピタンス」と定義しています。
人間中心設計専門家・スペシャリストの認定は、実務を通してコンピタンスを満たすスキルセットがあり、それを対外から認められた方が取得できます。それぞれの認定の応募条件には以下の違いがあります。
人間中心設計専門家(認定HCD専門家):人間中心設計・ユーザビリティ関連従事者としての実務経験が、5年以上あること。
人間中心設計スペシャリスト(認定HCDスペシャリスト):人間中心設計・ユーザビリティ関連従事者としての実務経験が、2年以上あること。
2つの認定共通:コンピタンスを実証するための実践事例が3つ以上あること。学歴については特に制限なし。大学院在学中における実務活動は実務経験年数として含むことは可能。
上記の応募条件を満たした上で、コンピタンスのスキルセットがあることを審査書類で証明する必要があります。
コンピタンスは全部で20個あり、3個のカテゴリに分類されます。
A. 基本コンピタンス:人間中心設計プロセスの各プロセスを理解し実施できる13のコンピタンス
B. プロジェクトマネジメントコンピタンス:プロジェクトマネジメントに関する3のコンピタンス(専門家のみ)
C. 導入推進コンピタンス:組織への人間中心設計導入を推進する4のコンピタンス(専門家のみ)
※ 2022年よりテクニカルコミュニケーション能力(プロジェクト及び活動を円滑に実施するために必要となる基礎的な3のコミュニケーション能力)は採点項目から外れたため、本記事でも解説の対象外とします。
本記事では、これら20個のコンピタンスを正しく理解するためのヒントと注意点をまとめました。今年度受験予定の方、また人間中心設計プロセスを学びたい方は、ぜひ参考にしてみてください。
「人間中心設計」は以降、本文内では「HCD」と省略します。
全コンピタンス共通の注意事項
各コンピタンスは、プロジェクトごとに以下の3つの情報を詳細にすることで、コンピタンスが発揮されたかどうか、客観的かつ再現可能なスキルかを実証する必要があります。
目的と対象
そのコンピタンスのステップが必要とされた背景や目的。さらに、何に対してそのコンピタンスを実施(既存サービス、ユーザー属性、調査結果、プロトタイプなど)したかを記します。体制と実施内容
どのようなチーム体制で、どのような条件下(実施場所、対象人数、時間、環境など)で、具体的に何をしたのか、なぜその方法を選んだのかを記します。体制では自身の役割も記します。工夫とアウトプット
規定のやり方ではなく、プロジェクト固有の事情に合わせて行なった工夫、および最終的に作成したアウトプットを記します。さらにそのアウトプットがどのように役立ったかを記します。
HCD-Netでは記述の注意点として以下のようにも記載されています。
A. 基本コンピタンス
A1. 調査・評価設計能力
このコンピタンスは以下のように定義されています。
現状の把握を目的に、UXリサーチなどの調査を行うための計画書を作成するステップです。複数の調査手法を採用している場合、そのような調査手順とした根拠など計画全体をここで振り返ります。特に以下のような内容を振り返り整理するとよいでしょう。
なぜ調査プロセスを踏む必要があったのか
調査によりプロジェクト全体として達成したいことは何か
どのような体制で計画し、自身の役割が何だったか
どのように調査手法を選定したのか
調査手法の選定の妥当性はどのように証明したのか
調査の有効性をどのように評価する計画としたか
調査計画がプロジェクトでどのように生かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
実際に行なった調査実施の詳細
実際に行なった調査結果の評価分析の詳細
実施途中の結果分析を踏まえて行なった計画の変更
ただし、あらかじめ変更を想定した計画(プランAとプランBを立てた等)であった場合は、本コンピタンスの工夫として書いておくとよいでしょう。
A2. ユーザー調査実施能力
このコンピタンスは以下のように定義されています。
現状の把握を目的に、実際にUXリサーチなどの調査をするステップです。調査から情報を最大限引き出すために、行ったタスクや工夫などをここで振り返ります。特に以下のような内容を振り返り整理するとよいでしょう。
その調査で得たい情報の狙いや期待は何か
どのような体制で実施し、自身の役割が何だったか
実施した各調査の具体的な内容(手法、対象ユーザーのセグメント、人数、期間・時間、場所・環境など)は何か
実施を円滑に進めるために事前にどのような情報整理をしたか
調査実施中に行った工夫は何か
調査の実施結果をどのようなアウトプットに残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
実際に行なった調査結果の評価分析の詳細
ペルソナやジャニーマップなどのモデル化したアウトプット(調査結果をダイレクトにモデル化した場合でも、それは分析した結果として、そのままでいいと判断したはずなので、HCDプロセスを飛ばさない)
調査結果を踏まえて、計画外の調査を追加したり、逆に中断して計画を見直し実施をやり直した事実などがあれば、理由と併せて本コンピタンスの工夫として書いておくとよいでしょう。
A3. 定性・定量データの分析能力
このコンピタンスは以下のように定義されています。
現状の把握を目的に、調査で得た情報・データを分析するステップです。調査で得たデータの形は様々なので、それらをどう分析したか、その分析が妥当だったかを示すことがポイントです。特に以下のような内容を振り返り整理するとよいでしょう。
分析のステップが必要になった背景は何か
分析した調査結果データはどれか
その調査結果データをなぜ分析する必要があったか
どのような体制で分析し、自身の役割が何だったか
分析の手法やプロセスはどのようなものだったか
分析手法の選定の妥当性はどのように証明したのか
分析結果をどのようなアウトプットに残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
分析結果からペルソナやジャニーマップなどのモデル化を行った内容詳細
分析した結果、そのまま次ステップのモデル化が難しいという判断になった時や、それにより新たな調査が必要になった時は、その判断をした経緯などを本コンピタンスの工夫として書いておくとよいでしょう。
A4. 現状のモデル化能力
このコンピタンスは以下のように定義されています。
現状の利用者の把握を目的に、モデル化(構造化)するフェーズです。UXデザインの代表的な成果物であるペルソナやジャーニーマップを制作するタイミングでもあります。しかし、すべてのプロジェクトで必ずしも必要な成果物ではありません。なぜ必要になったのかを中心に、以下のような内容を振り返り整理しましょう。
なぜモデル化のステップが必要になったか
現状のモデル化として採用した手法とは何か
1つの成果物に対して何種類のユーザーをモデル化したか、またなぜその種類数が必要だったのか
どのような体制でモデル化を進め、自身の役割が何だったか
モデル化するために活用した調査・分析データは何か
データからどのようなプロセスを経てモデル化したか
モデル化でのプロジェクト特有の工夫は何だったか
モデル化によってどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
モデル化したユーザーが求める問題に対しての、解決策の導出プロセスやアイデア
未来のユーザー体験の提示
ペルソナやジャーニーマップで定義する軸は、プロジェクトの特性により最適な形が異なることが多いため、アレンジをした軸があれば、工夫として記しましょう。
A5. ユーザー体験の構想・提案能力
このコンピタンスは以下のように定義されています。
現状のユーザー課題に対して、解決のアイデアを導き、それが実現した未来をToBe像として描くフェーズです。ここでは様々な解決アイデアが検討されますが、アイデア群を整理しアウトプットすることでアイデアの精度を高められ、関係者との合意形成もスムーズになります。
ここでは、以下のような内容を振り返り整理しましょう。
なぜユーザー体験の構想ステップが必要になったか
ToBe像を描く対象としたものは何で、どのくらいの数の構想をしたか
どのような体制でアイデア導出〜ToBe像の構想〜提案までのプロセスを行い、自身の役割が何だったか
どのようなToBe像を描き、それが良いと判断した根拠は何か
そのToBe像が良いと判断した根拠となる対象の現状モデル(A4のアウトプット)はどのタイプで、なぜそのタイプを対象に選んだか(特に、現状モデルのタイプが複数あった場合)
構想や提案時に、前提となる現状モデル(A4のアウトプット)を関係者に伝えるために工夫した点は何か
ToBe像の構想や提案のためにどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
現状モデル化(A4)そのもののアウトプット作成のプロセス
ToBe像からさらに踏み込んだ仕様作成に関わる詳細
A6. 新製品・新規事業の企画提案力
このコンピタンスは以下のように定義されています。
新製品・新規事業に関わるコンピタンスのため、サービス改善のプロジェクトは対象外です。A5で描いたToBe像を新製品・新規事業としてビジネス化・マネタイズ化するための調査・企画・提案が対象です。以下のような内容を振り返り整理しましょう。
提案のための根拠とした、ユーザー調査結果のなかの行動・ニーズは何で、なぜそのユーザー調査結果が重要と見なしたか
合意形成のために必要と考え準備した企画書に含めた内容は何か
どのような体制で企画・提案を行い、自身の役割が何だったか
企画にあたり改めて行った調査は何か(市場調査やPEST分析などのフレームワークを用いた分析が対象)
提案の形式は何(ドキュメント回覧のみまたはプレゼンなど)で、それに応じて行った工夫は何か、提案の流れはどようなものだったか
自身の提案やアウトプットがどのような成果になったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
ユーザーのニーズからアイデアを導出し、ToBe像を描くプロセス
新製品・新規事業の提案からさらに踏み込んだ仕様作成に関わる詳細
A7. ユーザー要求仕様作成能力
このコンピタンスは以下のように定義されています。
いままでのステップで整理したToBe像を実現するために、ユーザーがサービスと通してとる行動プロセスを整理し、その際のサービスのタッチポイントでどのような課題・ニーズがあるかを整理します。以下のような内容を振り返り整理しましょう。
なぜこのユーザー要求仕様作成のプロセスが必要になったか
ユーザー要求仕様を整理した範囲はどこか
どのような体制でユーザー要求仕様を検討し、自身の役割が何だったか
ユーザー要求仕様の根拠としたユーザー調査結果は何で、なぜそれが重要だったか
ユーザー調査結果からどのようなプロセスでユーザー要求仕様を決めたか
ユーザー要求仕様を決めるにあたり、影響範囲、実現可能性、実施優先度で配慮したポイントは何か
ユーザー要求仕様としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
抽象度の高いToBe像のコンセプトに近いイメージの詳細
サービスやシステムの要求定義に関わる詳細
このステップは、ユーザー体験の構想・提案能力(A5)のステップと混同してしまうことが多いです。A5は理想系を描きますが、それを実現するかはまだ不透明です。
一方で、このユーザー要求仕様は、満たすべきユーザーの要求が確定している状態を指します。仕様書として記されたものは次のステップでシステム化することを求められます。
A5はTo Be(理想解)、A7はCan Be(現実解)という区別をすると分かりやすいかもしれません。
A8. 製品・システム・サービスの要求仕様作成能力
このコンピタンスは以下のように定義されています。
ここからようやくサービスやシステムの要求仕様を整理します。システムの場合、どのような機能をもつことでユーザーニーズが満たされるかを定義するステップです。個々の画面を設計するステップではありません。以下のような内容を振り返り整理しましょう。
なぜこのサービスやシステムの要求仕様作成のプロセスが必要になったか
サービスやシステムの要求仕様を整理した範囲はどこか
どのような体制でサービスやシステムの要求仕様を検討し、自身の役割が何だったか
サービスやシステムの要求仕様の根拠としたユーザーの要求仕様は何で、なぜそれが重要だったか
ユーザー要求仕様からどのようなプロセスでサービスやシステムの要求仕様を決めたか
サービスやシステムの要求仕様を決めるにあたり、影響範囲、実現可能性、実施優先度で配慮したポイントは何か
サービスやシステムの要求仕様としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
抽象度の高いToBe像のコンセプトに近いイメージの詳細
システム・サービスの要件定義に関わる詳細
A9. 情報構造の設計能力
このコンピタンスは以下のように定義されています。
システムの場合、ここでは実際の画面のラインナップ、画面同士の関係性、各画面内で提示すべき要素など、いわゆる情報設計(Information Architecture)をするステップです。まだ実際の画面のビジュアルを制作するステップではありません。以下のような内容を振り返り整理しましょう。
なぜ情報設計のプロセスが必要になったか
サービスやシステムの情報設計をした範囲はどこか
どのような体制で情報設計をし、自身の役割が何だったか
情報設計の根拠とした前ステップのアウトプットは何で、なぜそれを利用したか
どのようなプロセスで情報設計を進めたか
情報設計をする上で考慮したポイントは何か(ユーザビリティ、ラベリングのルール決め、実現性や拡張性への配慮など)
情報設計としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされ、どのような成果があったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
実際の画面のビジュアルデザイン制作に関する詳細
画面の操作やインタラクションに関わる仕様の詳細
A10. デザイン仕様作成能力
このコンピタンスは以下のように定義されています。
対象がシステムの場合、画面のビジュアルや操作、インタラクションを定義するステップです。UIガイドラインやデザインシステムの作成も対象です。制作する画面数によって最適な進め方が様々なので、自身のプロジェクトではどのように進めたかを振り返り、以下のような内容を整理しましょう。
なぜデザイン仕様作成のプロセスが必要になったか
デザイン仕様作成をした範囲はどこか
どのような体制でデザイン仕様作成をし、自身の役割が何だったか
デザイン仕様作成の元とした前ステップのアウトプットは何で、なぜそれを利用したか
どのようなプロセスでデザイン仕様作成を進めたか
デザイン仕様作成をする上で考慮したポイントは何か(デザイン案の提案、仕様情報の連携方法、ガイドライン上の配慮など)
デザイン仕様作成としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされ、どのような成果があったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
情報設計に関わる詳細
実際に動作を確認できるレベルのプロトタイプ制作に関わる詳細
このステップは他のデザイナーに制作自体を委託し、自身では制作に関して手を動かしていない場合が見受けられます。その場合は、デザイナーのアウトプットに対する品質担保に関わる取り組み、仕様書やガイドラインなどのアウトプット作成に関する内容などを記すとよいでしょう。
A11. プロトタイピング能力
このコンピタンスは以下のように定義されています。
対象がシステムの場合、要求仕様を画面のデザインに落とし込み、実際に動作をイメージできる形で制作し、実装前に有効性を評価するステップです。一般的にはAdobe XDやFigmaなどのプロトタイピングツールで、インタラクションや画面遷移を再現したものが該当します。
プロジェクトによっては、フロントエンドのみで実装したHTMLモックアップなども対象です。画面だけではなくコンセプト動画など、制作物を評価しブラッシュアップができればプロトタイピングに該当します。以下のような内容を振り返り整理しましょう。
なぜプロトタイピング実施のプロセスが必要になったか
プロトタイピング実施をした範囲はどこか
どのような体制でプロトタイピングを実施し、自身の役割が何だったか
プロトタイピング実施の元とした前ステップのアウトプットは何で、なぜそれを利用したか
どのようなプロセスでプロトタイピングを進めたか
プロトタイピングを実施する上で仮説検証のポイントは何で、検証のための工夫は何だったか
プロトタイピングとしてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされ、どのような成果があったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
実際の画面のビジュアルデザイン制作に関する詳細
プロトタイピング後の評価検証に関する詳細
評価とブラッシュアップを目的としない実装の詳細
A12. ユーザーによる評価実施能力
このコンピタンスは以下のように定義されています。
ユーザーによる評価は、主には制作したプロトタイピング(A11)を活用した評価のステップです。画面に関わるプロトタイプ評価で代表的なものは、実際にその画面をユーザーに操作してもらい有効性を評価するユーザビリティテストです。評価検証での以下の内容を振り返り整理しましょう。
なぜユーザーによる評価のプロセスが必要になったか
ユーザーによる評価をした範囲はどこか
実施した評価検証の具体的な内容(手法、対象のユーザーのセグメント、人数、期間・時間、場所・環境など)は何か
評価する上で有効性を判断するための評価指標・基準に何を用いたか
どのような体制でユーザーによる評価を実施し、自身の役割が何だったか
どのようなプロセスでユーザーによる評価を進めたか
ユーザーによる評価で、ユーザー負担を減らすために行なった工夫は何か
評価結果をどのように分析しブラッシュアップを行なったか
ユーザーによる評価としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされ、どのような成果があったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
評価に関わらないユーザーに対するインタビューなどの調査の詳細
ユーザーに対してではなく、専門家やプロジェクト関係者による評価
A13. 専門知識に基づく評価実施能力
このコンピタンスは以下のように定義されています。
ユーザーによる評価ではなく、ユーザビリティやUXの知見を持つ専門家が評価して問題点を抽出するステップです。プロトタイピング(A11)に対する評価だけではなく、改善プロジェクトにおける現行に対する評価も対象です。そのため、プロジェクトの序盤でこのステップが実施される場合もあります。以下のような内容を振り返り整理しましょう。
なぜ専門家評価のプロセスが必要になったか
専門家評価をした範囲はどこか
利用した専門家評価の手法は何か
どのような体制で専門家評価を実施し、自身の役割が何だったか
どのようなプロセスで専門家評価を進めたか
専門家評価で客観的に評価するために行なった工夫は何か
専門家評価としてどのようなアウトプットを残したか
アウトプットが先のステップにどのように活かされ、どのような成果があったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
ユーザーによる評価の詳細
プロジェクト関係者による通常のレビューの詳細
B. プロジェクトマネジメントコンピタンス
B1. プロジェクト企画能力
このコンピタンスは以下のように定義されています。
HCDプロセスを導入したプロジェクト全体の企画・計画が対象です。以下のような内容を振り返り整理しましょう。
なぜHCDを導入するプロジェクトである必要があったか
何を背景に発足したHCDプロジェクトなのか
HCDプロジェクトの概要は何か
どのような体制でHCDプロジェクトの企画提案を実施し、自身の役割が何だったか
HCDプロジェクト企画実現に向けて自身で行なった取り組みは何か
HCDプロジェクトの企画で検討した要素(前提条件、ゴール、プロセス、アウトプット、体制、スケジュール、達成指標など)は何か
自身が作成したアウトプットは何か
自身のアウトプットがプロジェクト実施時にどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
ユーザー調査ステップのみの計画の詳細
プロジェクト実施中の管理・調整に関わる詳細
チームビルディング・運営に関わる詳細
B2. プロジェクト調整・推進能力
このコンピタンスは以下のように定義されています。
HCDプロセスを導入したプロジェクトの開始以降の調整・推進が対象です。以下のような内容を振り返り整理しましょう。
HCDプロジェクトとしての管理対象は何だったか(予算、スケジュール、人的リソースなど)
調整・推進に関わるのプロジェクトの課題は何だったか
上記の課題を解決するために、特にHCDプロジェクトとして工夫したことは何か(社内・社外のプロジェクト関係者調整、予算・人材のリソース管理、スケジュール調整、リスク管理など)
自身の調整・推進の工夫によってどのような成果につながったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
プロジェクトの企画に関わる詳細
プロジェクトのチームビルディングや目標管理などに関わる詳細
デザイナー人材育成に関わる詳細
B3. チーム運営能力
このコンピタンスは以下のように定義されています。
HCDプロセスを導入したプロジェクトで開始時に行うチームビルディングや、開始以降の運営が対象です。以下のような内容を振り返り整理しましょう。
HCDプロジェクトの運営概要(チーム構成、体制、運営期間)はどうだったか
チーム運営でHCDプロセスの導入効果を最大化するために工夫したことは何か
自身の運営の工夫によってどのような成果につながったか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
プロジェクトの企画に関わる詳細
プロジェクト実施中の管理・調整に関わる詳細
デザイナー人材育成に関わる詳細
HCDプロジェクトでは、HCDに見識のないメンバーも体制に含まれていることが想定されます。そんな中で、HCDの価値をどのように伝え、プロジェクトを通して継続的に啓蒙し、理解を促すために行なってきたことがポイントです。
C. 導入推進コンピタンス
C1. HCD適用・導入設計能力
このコンピタンスは以下のように定義されています。
HCDが浸透していない組織に対する導入の取り組みがあれば、社内か社外かに関わらず本コンピタンスの対象です。
1プロジェクトに対するプロジェクトチームへの個別の取り組みは対象外ですが、特定プロジェクトの取り組みの成果を、組織全体に展開できた場合は対象です。その際、組織全体への展開まで含めて手順を振り返りましょう。
HCDの組織導入そのものが目的のプロジェクトの場合、個別に1つのプロジェクトとして審査書類に記します。
HCD組織導入における以下のような内容を振り返り整理しましょう。
HCDプロセスの組織導入が必要になった背景・組織課題は何か
HCDプロセス導入の対象組織と範囲はどこか
どのような体制でHCDプロセスを導入し、自身の役割が何だったか
HCDプロセス導入をどのような手順で進めていったか、またその手順にした理由はなぜか
HCDプロセス導入にあたり整備したものは何か(ガイドライン、手法の選定など)
自身が作成したアウトプットは何か
自身のアウトプットがどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
プロジェクト個別のHCD導入に関する詳細
組織への教育プログラムの開発に関する詳細
デザイナー人材育成に関わる詳細
C2. 教育プログラム開発能力
このコンピタンスは以下のように定義されています。
HCDに関する統一的な教育プログラムを開発していれば、社内か社外かに関わらず本コンピタンスの対象です。
1プロジェクトに対するプロジェクトチームへの教育は対象外ですが、特定プロジェクトの教育プログラムの成果を、組織全体に展開できた場合は対象です。その際、組織全体への展開まで含めて手順を振り返りましょう。
HCD教育プログラム開発そのものが目的のプロジェクトの場合、個別に1つのプロジェクトとして審査書類に記します。
以下のような内容を振り返り整理しましょう。
HCDの教育プログラム開発が必要になった背景・組織課題は何か
教育プログラムを導入する対象組織と範囲はどこか
どのような体制で教育プログラムを開発し、自身の役割が何だったか
教育プログラム開発をどのような手順で進めていったか、またその手順にした理由はなぜか
教育プログラムで組んだカリキュラムや教材の工夫は何か
自身が作成したアウトプットは何か
自身のアウトプットがどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
プロジェクト個別のHCD教育プログラムに関する詳細
組織へのHCDプロセス導入に関する詳細
デザイナー人材の個別の育成(OJTやスポット研修)に関わる詳細
C3. 人材育成能力
このコンピタンスは以下のように定義されています。
デザイナー人材育成のための個別の教育計画や継続的な指導が対象です。組織統一の教育プログラムは対象外です。育成対象者に対して、プロジェクトを通した経験や研修受講の機会を提供しフォローします。
組織やプロジェクトに対するスポットでの勉強会主催なども本コンピタンスに該当します。
以下のような内容を振り返り整理しましょう。
HCDの人材育成が必要になった背景・組織課題は何か
人材を育成する対象組織・チーム・人は誰か
どのような体制で人材育成を実施し、自身の役割が何だったか
育成対象者のバックグラウンドに配慮し、どのような育成プロセスを進めていったか
研修参加者の属性を踏まえて、講師やファシリテータとして行なった工夫は何か
教育に際して自身が作成したアウトプットは何か
自身のアウトプットがどのように活かされたか
他のコンピタンスに関わる以下の内容は、記さないよう注意しましょう。
プロジェクト個別のHCD教育プログラムに関する詳細
組織へのHCDプロセス導入に関する詳細
デザイナー人材の個別の育成(OJTやスポット研修)に関わる詳細
C4. 手法・方法論開発能力
このコンピタンスは以下のように定義されています。
すでにある方法論での実践ではなく、研究に基づく新たな方法論の確立が対象です。このコンピタンスは筆者の未体験ゾーンで、具体的な解説は難しいため、上記のアウトプット例で紹介されている方法論のひとつをサンプルとしてご紹介します。
このようなユーザビリティやUXをどうやって定量評価するかは、多くのプロジェクトで課題になりやすいトピックです。みなさんが関わるプロジェクトでも、新たな手法を考案しメディアで発表すれば、このコンピタンスもクリアできるかもしれません。
さいごに
人間中心設計専門家・スペシャリストは、本記事で解説した内容を読めば誰でも審査書類が書けるという性質のものではありません。実際にHCDプロジェクトを能動的に推進しプロジェクト関係者と合意形成を上手くしている状態でないと、なかなか中身のある内容は書けないと考えています。
しかし、その試練を乗り越え、人間中心設計専門家・スペシャリストへの応募と審査書類を書くことで、自身の今までの取り組みを振り返り、経験の不足ポイントを確認することができます。
今後の自身キャリアを計画する上でのメリットになることは間違いないので、ぜひこの機会にキャリアの総括を行ってみてはどうでしょうか。2023年に向けた、さらなるキャリアアップのきっかけにしましょう。
明日はShinoさんによるデザイン組織のマネジメント白書をお届けします。ぜひご期待ください 🎉
この記事が気に入ったらサポートをしてみませんか?