iCDは、「タスクディクショナリ」と「スキルディクショナリ」で構成されたシンプルで柔軟性のあるスキル標準の最新版です。
今回は、iCD導入・活用の要件分析に続くステップ、「タスク分析」について説明します。
|
|
|
活用プロセスの考え方 |
 何度か説明してきましたが、ITSS、UISS、CCSFの活用プロセスはすべて同じです。今回のiCD活用プロセスも少し名称の変更はありましたが、同様の流れとなっています。
iCD活用プロセスの「試行と確定」までが「導入プロセス」で、人材開発の仕組みの構築プロセスです。「現状把握」以降は、構築した仕組みを実際に回す運用プロセスになります。
企業や組織がiCDを活用する一番のメリットは、経営戦略や事業計画を基に、将来を踏まえて求められる活動内容、およびそれに必要な実行能力を明らかにできることです。To Beが明確になることによって、現状との差異から適切な育成計画や人員計画を立てることが可能となります。これはPDCAのPlanの部分が、より最適化されたものになるということで、効率的で効果のある仕組みの運用を実現することができます。 |
|
|
タスク中心の考え方 |
人材育成は人材戦略にのっとっていないと意味がありません。では人材戦略は、というと経営戦略や事業計画を基に考えられたものでないと、つじつまが合わなくなります。
この関係は、言われればその通りと答える方が殆どだと思いますが、なかなかうまくリンクできないという現実があるのも確かです。
繰り返しになりますが、スキル標準の導入失敗事例の多くは、人材やスキルから設定していくという方法をとっています。なぜなら、これが一番やりやすいからです。こんな人材が必要だ、そうすればこういうスキルが必要だという流れです。そう考えた時点で、どうすればいいか分からなくなった方は、ITSSなどの職種や定義をそのままでいいのではないかという考えに至ってしまいます。これでは、自社の戦略や計画など微塵も入れ込むことはできません。
仮に試行錯誤して作り出せたとしても、他者への説明がしにくい、ということと作った方が異動などで担当から離れた場合に破綻してしまうことが殆どです。
つまり、説明できないものや引き継げないものを、PDCAを回して運用していくことはできない、ということです。
そこで、人やスキルからではなくタスクから考えてみる、という方法がUISS、CCSFそしてiCDでも採用されています。これは、2003年にファイザーにITSSを導入した時に作り出した方法論で、ITSS活用の手引きやUISSの導入活用プロセスでも採用されています。
このように企業導入を考えたときに、個人の視点である人材やスキル定義から考えるのは簡単なのですが、経営戦略や事業戦略を基にした組織視点のあるべき姿を求めるには、タスク(当初は機能と言っていましたが)、しかもTo Beのタスクを明らかにするところから入ることが重要なポイントです。 |
|
|
タスク分析」について |
「タスク分析」のステップは、これまでは組織機能検証と呼んでいました。組織機能の検証をして自社のTo Beタスクを導き出すという作業自体が、タスクを分析することに他ならないということで「タスク分析」という名称に変更しました。
では、タスク分析について詳しく説明していきます。
iCD活用プロセスの最初のステップである「要件分析」だけがiCDから何も提供されません。企業ごとにビジネスモデルや目標、考えが異なるわけですから当然です。
しかし、このタスク析からはタスクディクショナリとして提供されますので、有効に活用していくことができます。
まずは、現状の組織とタスク一覧のマッピングを行い検証します。企業や組織としての「To Beタスクの構成を明らかにする」ためのステップになります。タスクの漏れはないか？責任不在のタスクはないか？を各部署の責任者による確認を行ないます。
iCDのタスクディクショナリは、非常に広い範囲をカバーしています。したがって自社のビジネスモデル上(将来において)、必要のないものを削除するということが基本的な作業となります。しかしながら、たとえばデータセンターの運営に特化しているビジネスを主体としている場合、ITSMやデータセンターの運営のタスクが求められることになります。そうすると、大きなタスクのくくりでは範囲としてカバーできているが、具体性に欠けるということも考えられます。そうしたケースは、タスクをブレークダウンして粒度を細かくしていく作業も必要になってきます。
ここでは組織の評価をしたいわけではなく、先ほど定義したように「To Beタスクを求める」ということが目的です。また、要求分析で、こうありたいという将来像を明らかにしたわけですから、現在実施していなくともTo Beタスクとして構成の中に入れなければなりません。その観点から今すぐ実施しておくべきなのか、少し先でいいのかという区分けも必要です。
逆に、手厚く内部で実施しすぎているのでは、というタスクも浮かび上がります。これらを基に、As Isを包含したTo Beのタスク構成を明らかにします。しかし、あくまで机上での設定なので「仮説」ということも忘れてはなりません。
タスク分析のポイントをまとめると次のようになります。
・タスクディクショナリ/タスク一覧をベースに、仮説のTo Beタスクを作成する
・人材や役割は意識しない
・組織検証は組織の評価ではない
-現在実施できているタスクはどれか
-将来を見据え、現在できていないが実施する必要のあるタスクはどれか
-必要なのにタスク一覧にないものがあるか
-将来的に必要のないタスクはあるか
・タスク内容が不明な時は、タスクプロフィールを参照する
①タスク理解、識別
業務、システム種別、開発方式等、タスクの種類や特性をあらわす属性情報。
利用者が、各タスクの意味を理解し、識別するためのもの。
②ビジネスタイプ
ビジネスタイプ別のタスクセット。
自社の業態に最も近いタスクセットをもとに、必要なタスク範囲の見当をつけるためのもの。
～次回はTo Beタスクの設定、役割分担の考え方に入っていきます。
|
|
|
|
|
登録:2022-03-11 21:23:49
|
