「To BeとAs Isのギャップから育成計画を立てる」、言うは易しですが、実際はそう簡単にはいきません。また、「PDCAを廻す」というのも、立てた計画を実践し、結果から見直して・・・。
これだけでは、何か物足りないことにお気づきでしょうか？
|
|
|
育成計画のPDCA、仕組みの運用のPDCA |
DXというワードが浸透し始め、政府や自治体がよくIT化の話をします。例えば様々な申請などをインターネットで行える、といった類のものです。
このような話を聞くたびに、いつも違和感を感じます。それは、IT化された後の利点ばかりの説明に終始し、それをデザインし作り上げることや、問題なく使えるように運用することには、ほとんど触れられていないからです。本番運用に入った後で致命的な不具合などが発生して大変なことになっている状況も少なくありません。
それぞれ能力を持った人が当たることになるだろうし、では、適切な人はいるのかいないのか、後進をどう育成するのか、また仕組みの運用を問題なく継続していくためには、何をどうすればいいのか。本来は、事前にこれらのことを考え、プランをたてた上で、実践していく必要があるはずです。
先に書いた「To BeとAs Isのギャップ」は、To Beの求め方、As Isの把握の仕方、およびそのギャップを明らかにする方法が必要です。
また、そのギャップから育成計画を立案していく手順と道具が必要で、それも無く現場や個人任せにしているのでは、うまくいくはずもありません。
もう1つの「PDCAを廻す」についても、立案した計画を誰がどのように実践していくかを、明らかにする必要があります。あくまで計画は「仮説」でしかないので、それを検証し改善点を明らかにして計画に反映していく、という流れをプロセスとして作りこむことになります。
また、もう1つ忘れてはいけないのは、上記のPDCAだけではなく、仕組み自体の運用と改善のPDCAも廻す必要があり、それがないと仕組みを継続していくことは難しいのです。そして、そのための体制づくりや育成活動も必要になるということです。 |
|
|
要求モデル、ファンクションモデルの策定 |
 先回までのおさらいをしておきます。
企業がビジネス上の競合他社に勝ち抜き、反映していくためには、「効果的なDX推進が必須であり、ITをリードする組織や企業の実力を効率的に向上させる必要がある」ということは共通認識であるはずです。
そのためには、経営戦略や事業計画を基にして人材体系を構築し、それを中心に活用のPDCAを廻すための仕組みが必要になります。
ここで、「経営戦略や事業計画を基にして人材体系を構築」と書きましたが、その第一歩は、257話で説明した「要求モデル」(図参照)を策定することです。
要求モデルは、組織や人材に関する要件をキーワードでまとめ、企業として目指しているものをロジックツリー化して、責任者から一社員まで誰でも分かるようにしたものです。
これは、以降の作業での成果物を他者に説明するときに、大変重要な役目を果します。周りからの「なぜ」に答えるための拠り所となるのです。
次に、要求モデルで示した目指しているものを実現するために、組織に必要なタスクをまとめます。あるべき姿のTo Beファンクションモデルです。これは、258話で説明しました。
ここまでは、人材像については全く出てきません。このように企業視点から入らずに、必要な人材とその能力の定義から入るケースが多く見受けられます。
それだと取組み易いのですが、せっかく作った仕組みが現場に受け入れられなかったり、うまく廻らず継続できなかったりして、失敗する憂き目にあう可能盛性大です。
実際にそのような事例を多く目にしてきました。作成したものが、関わった人の考えだけで成り立っていて、なぜそのようになっているかを、他者にうまく説明できないからです。そのような場合、作成した人が異動になった途端に、全てがうまくいかなくなります。それでは継続できるはずもありません、
企業の人材体系は、将来を創造していくキーとなります。
人材育成だけでなく評価と切り離しては考えにくいこともあり、とりあえずやってみようという対応や、属人化されたものを作ってはダメなのです。完成度を上げていくことには柔軟に対応していく必要がありますが、一度踏み出せば失敗は許されないという決意で、本腰を入れてしっかりと進めていくものです。 |
|
|
人材体系の基本要素となるもの |
 先に書いたように、「人材体系」と言っても、基本となるのは企業戦略や事業計画です。したがって、最初に人材像から考えるのではなく、それらを実現するためのタスクを明確にするところから入り、それを人材像に落としていくというアプローチを取らなければ、経営戦略や事業計画との関係をうまく説明することはできません。
図は、タスクをブレークダウンし必要なスキルを定義している例(抜粋)です。
IT基盤プロジェクトの基本計画を立てるというタスクが左側にあり、それを右へブレークダウンしています。基本計画を立てるためには、まず構想を立案するタスクがあるということです。左側から目的−手段で1：Nの関係で成り立っています。
さらに右側を見ると、やや粒度の荒いスキル定義があり、図には載せていませんがその右には詳細のスキル定義があります。
以上のように、タスクを2段階に分類して、それを実践するために必要なスキルが定義されている構成になっています。
つまり、人ではなく経営戦略、事業計画を実現するためのタスクと能力の定義体であるということです。
企業によってタスク分類の単位や深さは変化するし、必要なスキルの内容も同じではありません。それぞれビジネスモデルや、組織体制、グループ体系、ましてや目標設定が異なるのは当然です。 |
|
|
|
|
登録:2023-03-17 10:32:44
|
