クラウド人材育成の仕組み化 どこまで自分でやり、どこから人に任せるか
アクセンチュア株式会社テクノロジーコンサルティング本部金融サービスグループ アソシエイト・ディレクターの青柳雅之です。
私は金融サービスグループのクラウドに関するプラクティスのリードとして、クラウド人材の育成にも関わっています。人材育成はこれまでは自分が主体的に行ってきた部分もあるのですが、今期は何人かのリーダーを作り、メンバーに施策をリードしてもらうことになりました。
自分一人で育成をスケールするのは限界があります。そこで各育成施策でリーダーを選定しましたが、その上のプラクティスリードとして、自分はどこまで考えて実行し、どこからを各リーダーに任せるのかと言う線引きを考えました。これが仕組み化にも効いてきます。 なお、人選については、クラウドの育成施策のリーダーをどのように選ぶかに記載しています。
任せる側がやること①:計画/報告用定型フォーマットを作る
次のスライドは、各施策で計画および報告用に私が定義したフォーマットです。中身はサニタイズしています。Google Cloud/AWSを中心にハンズオンを実施しています。Azureも開始する計画です。
各施策で計画/報告用定型フォーマットを作ることにより、報告内容に抜け漏れがなく、一定の情報が入ってきます。自分がリーダーに報告してほしい情報が入っているわけです。全施策でこれを使うことにより、報告内容の粒度もそろいます。計画と報告は同じフォーマットを使います。進捗時にこの計画に対する進捗を書けばいいようにフォーマットを作っています。また、数値目標も書くようにしています。
任せる側がやること②:計画を作る
これは任せられる側のリーダーのスキルにも依存しますが、基本、クラウド人材育成はITスキルでリーダーを選んでいないので、計画は任せる側が骨子を作ります。そこにリーダーの意見を入れます。ハンズオンの施策を例にとると、ハンズオンで何をやるべきかのリストは任せる側の私が作ります。そのハンズオンも私が一通り事前に行います。ただし、これはリーダーが慣れてくればリーダー自ら更新できるようになるのは経験的にわかっています。次の計画も自分で作れるようになります。
任せる側がやること③:マネジメントサイクルを作る
マイクロマネジメントをすると、私の負荷も高いしリーダーも成長しません。そこで、会う機会を月1にしました。リーダーは上記のフォーマットに沿って月に1度報告書を書き、私ともう一人のマネジメントと面談をします。そこで私は悩みを聞いたりアドバイスをするだけです。課題の多くはリーダーに担ってもらいます。実際に私がやるのは他の誰かにつないだり、よい情報のありかをアドバイスするくらいです。彼らの仕事を直接肩代わりはしせん。これは、かつてハーバードビジネスレビューに掲載されたおそらく有名な論文、Management Time : Who’s Got the Monkey?にヒントを得ています。ここでいうサルは、課題です。部下が持ってきたサルを自分で背負ってはならない、ということです。上司が自分でサルを背負ってしまうと、その上司は忙しくなるうえに、部下も育たないということが書いてあります。
任せる側がやること④:役割を決める
実は、このブログに書いているように、「任せる側(私)がやること」と「各施策のリーダーがやること」を決めることがこれにあたります。プラクティスリードとその下の各施策リーダーの役割を決めます。これがぶれると私が育成を直接行う羽目になります。
各施策のリーダーがやること①:具体的なタスクへの落とし込み
常に計画に記載されている課題を認識し、数値目標も気にしながら具体的なタスクに落として施策を実行していきます。
各施策のリーダーがやること②:不足するスキルのキャッチアップ
リーダーとはいえ、不足スキルもあると思います。そこをキャッチアップすることで自らの能力もあがります。サルをその上司に渡さないことで、自分のスキルが上がります。上司の私はより戦略的なことを考える時間が出来ます。
各施策のリーダーがやること③:報告
定型フォーマットに沿って記載を行い、報告します。フォーマットの右下に「今月の状況」の欄があるのでそこを更新します。また、その上の数値目標である「目標と実績」も更新します。
まとめ
定型フォーマットを最初に自分で作り、あとは各施策リーダーが月に1度持ってくるのを待つだけになりました。かなり負荷が低いです。
振り返ってみると当たり前のことを書いていますが、これが出来てないと任せる側が下に降りすぎて実作業を行い、結局は広い範囲で管理を行うことが不可能になってしまいます。
Discussion