Skip to main content Skip to Footer

Blog - Cloud ComputingCommentary from our cloud experts around the globeBLOG アクセンチュア・ クラウド・ ダイアリーズ

July 02, 2018
クラウド人材育成 組織に拡大したAWSのケイパビリティを短期のリスキリングでAzureのケイパビリティに転換する(1)
By: 青柳 雅之

クラウド推進事業本部/オペレーションズ本部 シニア・マネジャーの青柳雅之と申します。私はAWSやAzure、GCPといった主要なパブリッククラウドを使用したIT Modernizationを担当しています。オペレーションズ本部のクラウド人材育成を担当しています。

以前の記事「組織のAWSケイパビリティをカスケード式に拡大する」では、AWSの技術コンサルタントを育成する方法を紹介しました。今回は以下の内容を記載します。

  • AWS技術コンサルタント育成のためのカスケード式トレーニングの実施結果
  • AWSの技術コンサルタントをAzureの技術コンサルタントにリスキリングする取り組みの紹介

タイトルに(1)と付けたのは、後日、Azureを学習するうえで抑えるべき技術について、もう少し詳しく紹介させていただいたり、育成の効果を報告させていただきたいからです。

AWSだけではなく、他のパブリッククラウドにも対応できるようにリスキリングを行うことで幅広い知識を持った技術コンサルタントを育成します(多能工化)。リスキリングとは、技能スキルの再教育という意味を持ちます。

GCPへの取り組みについても行っておりますが、紙面の都合もあるため今回はAzureに限定し、別の機会に記載します。今回紹介するリスキリングの考え方の基本はクラウドの種類が異なっても変わらないはずです。


技術コンサルタントは多能工であるべき
我々が所属する部署はあらゆるクラウドを扱うことから、また、需要の変動に応じて柔軟なチーミングが可能になることから、技術コンサルタントは多能工であるべきだと考えています。

  • プロジェクトリードをする人、クラウド導入戦略を担当する人、クラウドのアーキテクティングをする人、クラウドに関する運用を含めたサービスマネジメントを企画する人、すべてが一定以上のクラウドの技術スキルを保持すべきです。例えば、クラウド導入戦略の担当は上流だから、クラウドでシステムを構築できなくてもいいということはありません。
  • あるパブリッククラウドだけを知っている、というのではなく主要なパブリッククラウドすべてについて、少なくとも基本は理解すべきでしょう。
  • クラウドへのマイグレーションを計画して実施する人、サーバーレスのアプリケーションを開発したり、AIのサービスのビジネスシナリオを考える人が同一のメンバーでも問題ありません。

多能工化を行わない場合、これしかできません、という人が増えてプロジェクトアサインが難しくなるのに加え、特定分野では希少リソースとなるメンバーが発生します。つまり、この人がアサインできないからプロジェクトを提案できません、ということになりかねません。同じパブリッククラウドを使用する中でもリスキリングは必要ですが、今回はAWSからAzureにリスキリングする観点でブログを記載します。


少数の高スキルメンバーを共有リソースとするモデル
多能工化を行わないゆえに希少リソースが発生した場合、もしくは高スキルのメンバーの数自体が少ない場合、彼らを「共有リソース」として配置し、多くの現場のプロジェクトの支援に当たらせる組織も多いと思います。この「共有リソース」は、CoEと呼ばれることもあります。本来は高スキルのメンバーをプロジェクトリーダーにしたいのですが、数が少なくてできないが故の苦肉の策です。この「共有リソースモデル」では次のような問題点があります。


図:少数の高スキルメンバーを共有リソースとしたモデル。別ウィンドウで開きます。

図:少数の高スキルメンバーを共有リソースとしたモデル


  • 共有リソースは、プロジェクトメンバーが困った時に呼ばれて対応するというパッチワークになりがち。
  • 共有リソースがプロジェクトを支援するまでは、プロジェクトメンバーは試行錯誤を繰り返す。
  • 共有リソースは少数のため十分な支援を各プロジェクトにはできない。そのため、プロジェクトによっては失敗もありうる。
  • 技術を理解していない「管理と調整型のプロジェクトリーダー」は、目指すところが自分の想像とスキルの範囲内となってしまい、突出した成果は出しづらい。

過去に当ブログ「クラウドCoEとクラウドEA」でも記載しましたが、このモデルでは高スキルメンバーに依頼が殺到して、メンバーが疲労していきます。彼らはCoEと呼ばれることもあり、基本的にはトラブルが発生した時の火消し役であったり、悩み相談室です。
現場メンバーはこの共有リソースの存在ゆえに、自らが学ぼうという姿勢は持ちません。わからなければ聞けばいいという人が増えて、現場のプロジェクトのメンバーと共有リソースにいる高スキルメンバーのスキルの差も埋まりません。また、現場には技術に詳しくないメンバーをアサインするのが前提になりプロジェクトリスクが高まる、本来は先端的な技術を使って事例や組織のアセットを作っていく能力のある高スキルメンバーが、スキルの低い人のサポートに労力を割かなければならない、といったデメリットもこの共有リソースモデルにはあります。
もっとも、現場のメンバーのスキルも業務遂行上問題のないレベルであり、共有リソースはさらに高スキル…というのであればこのモデルでも問題はないと思いますがそういうケースは少ないかもしれません。

この「共有リソースモデル」の背景には、スキルの高くないメンバーのスキルを上げるのは、初めから難しいと諦めている考えがあります。もしも彼らのスキルが底上げされれば、共有リソースの負荷が大幅に下がりますし、プロジェクトによっては彼らの支援が不要になる場合もあるでしょう。共有リソースのメンバーも火消し役やサポートではなく、プロジェクトをリードする立場になれるかもしれません。


技術と管理に優れたプロジェクトリーダーがプロジェクトを率いるモデル
プロジェクトの規模にもよりますが、プロジェクトリーダーはプロジェクト管理もできる最も技術に詳しいメンバーが務めるのが理想です。それにより顧客との会話も早く済み、メンバーのレベルを引き上げることが可能です。共有リソースモデルから、このようなモデルに組織を変えるには、高スキルのプロジェクトリーダーの数を増やすために現在のメンバーのケイパビリティを引き上げるという時間のかかる地道な努力が必要です。


図:技術と管理に優れたプロジェクトリーダーがプロジェクトを率いるモデル。別ウィンドウで開きます。

図:技術と管理に優れたプロジェクトリーダーがプロジェクトを率いるモデル


  • メンバーはリーダーの仕事のやり方をOJTで覚えることができる。技術的に未成熟なメンバーが、高スキルのプロジェクトリーダーになる期間は「共有リソースモデル」と比較して短い。
  • プロジェクト自体は、プロジェクトリーダーの目指す高いレベルに向かう。

我々のクラウドチームのプロジェクトでは「共有リソースモデル」は存在しませんが、一部のプロジェクトはSME(領域専門家)をアサインして共有リソースモデルに近い形をとっている場合があります。そこで我々は、クラウド技術のケイパビリティを組織に蓄積する、技術コンサルタントにリーダー経験を積ませ、技術も管理もできる人材を増やす、といった流れをさらに強くしたいと考えています。
クラウドの技術面では、まずは部署内に有識者が多く、トレーナーのサポーターを確保しやすいAWSを全員がマスターするようにし、その後にリスキリングしてAzure、GCPにも対応できるようにします。


AWS技術コンサルタント育成のためのカスケード式トレーニングの実施結果
前置きが長くなりましたが本題に入ります。第1タームとして4名の学習グループからスタートしたカスケード式トレーニングは、無事にカスケードされて2か月半後に3つの学習グループとなりました。第1学習タームのトレーニー5名のうち4名がトレーナーとなり、新しいトレーニーは総勢13名が加わりました。第1学習タームの中の1名は別の部署に所属するメンバーであり、その部署のクラウドケイパビリティ構築のために参加してもらいました。今後、その部署の育成はこの方に担って頂く予定です。なお、このメンバー以外に我々の部署にはすでにパブリッククラウドの十分な経験を持つメンバーもおり、彼らはトレーニングの対象外となっています。経験の浅い人、未経験の人をいかに素早く技術コンサルタントとして立ち上がらせるか、というのがこのカスケード式トレーニングの目的です。最初にトレーニーだったメンバーの多くは、トレーナーになると同時に実際のAWS案件にアサインされ、AWSの経験が十分にあるスーパーバイザーのもとでスムーズなスタートを切っています。当人たちにも聞いてみましたが、もしカスケード式トレーニングに参加していなくて座学だけでは無理だったとのことでした。


図:カスケードした学習チーム。別ウィンドウで開きます。

図:カスケードした学習チーム


トレーナーである私のサポートとして参加していた五十嵐は、AWSのスキルが高く人に教えるという点でも高いスキルを持っているため、私に代わってAWSの技術コンサルタントを育成するリーダーとなってもらうことにしました。第1学習タームで一通りトレーニングを経験した今、できる限り早くこのように権限を委譲することで多くの若いメンバーが組織運営の経験を積めることを期待しています。私はその他のクラウドも含めた育成全般の企画に重点を移します。


五十嵐 志鳴。別ウィンドウで開きます。

写真:五十嵐 志鳴
クラウド推進事業本部


第1学習タームでは、クラウドの経験はなくてもエンジニアとしての能力の比較的高い人を選抜したため、次のタームで、ほぼ全員にトレーナーをやってもらうことができました。トレーニーはトレーナーになって初めて知識の定着が確実になります。今後、すべてのトレーニーがそのようなレベルになれるかどうかはまだわかりませんが、仮に13名のうち50%がすぐにトレーナーになれれば、7(13人の50%)x5名(1つの学習グループの人数の標準)=35名のトレーニーが生まれるはずです。育成はカスケード式に広げられるので、将来は現在クラウドに携わっていないエンジニアを対象にリスキリングするのもいいかもしれません。


Azureのケイパビリティへのリスキリング
弊社のAzureのプロジェクトの多くは、マイクロソフトと共同で設立した子会社のアバナードと行っています。お客様は複数のパブリッククラウドの導入を検討されることも多く、アクセンチュアの立場としては包括的にプロジェクトを見ることになります。その際に、アバナードにAzureのメインの部分を担当してもらいますが、我々もAzureの高いケイパビリティを持てば、アバナードとともにより高いレベルの価値が提供できます。現時点でも部署内にAzureのプロフェッショナルも存在していますが、Azureのプロジェクトに対応できるメンバーをさらに増やすために、AWSの技術コンサルタントとして育成したメンバーを可能な限り、Azureの技術コンサルタントにリスキリングする計画を立てました。

私はアクセンチュアに入社する前はAWS(プロフェッショナルサービス本部)に3年、マイクロソフトに15年(研究開発本部とコンサルティングサービス統括本部)勤めていたわけですが、直近はAWSにほぼ専念しており、Azureの仕事の比率は低いものでした。そんな中、マイクロソフト時代の同僚でAzureのプロフェッショナルである、元エバンジェリストの鈴木章太郎がアクセンチュアに去年入社して、一緒に仕事をしするようになりました。ちなみに我々は最近、コンテナ周りの仕事をしています。そこで、今度は彼にトレーナーをやってもらい、Azureでこのカスケード式トレーニングを回すことになりました。今度は私もトレーニーです。また、彼はAWSのカスケードに参加してAWSのスキルも身に付ける予定です。この時の彼はトレーニーです。


鈴木 章太郎。別ウィンドウで開きます。

写真:鈴木 章太郎
金融サービス本部 テクノロジーコンサルティンググループ シニア・マネジャー


Azureのカスケード式トレーニング
Azureの学習グループのメンバーは私を含めて5名。トレーナーは鈴木です。メンバーは将来Azureの案件へのアサインを行う予定のマネジャー層以下の若いメンバーが中心であり、AWSの第1学習タームのメンバーも数名入っています。これらのメンバーは基本、AWSの経験はあります。鈴木や私はAzureの仕事の経験がありますが、他のメンバーはAzureの経験はありません。このAzureの次のカスケードでは、現在AWSのトレーニングを受けている他のメンバーが参加し、この学習グループのメンバーがトレーナーを行うことでしょう。

AWSの学習タームでは、Blackbeltと「よくある質問」をメンバーに毎週自習してきてもらい、週に30分X2回のクイズ形式で知識を問うて来たわけですが、Azureの学習リソースも選択肢が豊富なため、何を自習用のリソースとして使用するかを鈴木とTeamsを使ってディスカッションしました。

例えば、AWSを知っていればAzureの機能も理解しやすい部分はありますが、AWSのみ知るメンバーがAzureを理解するのに最初に苦労するのはアカウントの考え方と想定しました。この理解を深めるにはどの教材がよいかをTeamsでテキストベースかつ非同期にディスカッションしました。AWSであれば基本的にアカウントとIAMユーザーの概念を理解すればいいところを、Azureの場合は、アカウント、サブスクリプション、リソースグループといったエンティティを理解し、さらにユーザーによってEAポータル、アカウントポータル、Azureポータルと見るポータルも異なることも理解しなければなりません。


図:学習で使用するリソースをTeamsでディスカッション。別ウィンドウで開きます。

図:学習で使用するリソースをTeamsでディスカッション


Azureの学習グループもAWSの時と同様、毎週学習する形式をとりますが、アカウントとセキュリティ、ネットワークの概念を押さえた後は、プロジェクトで使用するサービスをまずは重点的に学習します。現時点ではコンテナです。

この学習グループも含め、カスケード式に広がっている学習グループは、Teamsにおいて[Cloud Consulting Training]というチームの下にチャネルを持っています。チームのメンバーは全チャネルを参照できるため、他の学習グループのディスカッション内容を参照することも可能です。図では各パブリッククラウドの学習タームが走っていることがわかります。チャネル名の最初にある年月はスタート時期、そのあとのアルファベット2文字は部署名の略称です。※一部、名称は変更しています。


図:カスケード式に広がっている学習グループのチャネル。


トレーニングへのさらなる工夫
より効率よく、より効果が出るようにトレーニングの改善を行っていきます。これについてはクラウドの種類は問いませんがAzureのトレーニングで試す予定です。

①ハックフェスト(Hackfest)の実施
カスケード式トレーニングでは、トレーニーが学習リソースの自習を行いながら、実際のトレーニングではトレーナーが1問1答をする形式です。並行して基本的なハンズオンもトレーニーに実施してもらいます。これだけでも、トレーニング修了者がプロジェクトに入った場合は、スーパーバイザーが経験者であればスムーズに作業に入れます。しかしもっと学習効果が高い方法はないかと模索していました。

たまたま私がAzureのコンテナサービスの検討、検証をしていた際に、その様子をTeamsのチャネルに書いていました。そこに鈴木がいろいろ書き込みをしてくれて、想定よりもだいぶも短い時間で目的の検証を終えることができました。これは疑似的なハックフェストではないかと思いました。ハックフェストとは、チームがあるテーマに新技術で取り組む際に、その領域のプロフェッショナルも参加してメンバーを支援し、一定期間、一緒にパイロットシステムの構築に取り組むというものです。マイクロソフトのエンジニアの方も積極的に実施しているようです。ハックフェストは実装スキルを短時間で得ることができるため、今後は短い時間のハックフェストを随時トレーニング中に取り入れられないかと考えています。技術ドキュメントを長い時間読んだり、技術アセットを流用して資料を作成しても本当の技術スキルは身に付きません。まずは自分で手を動かすことです。

➁利用ガイドラインによるケイパビリティの拡大
多くのお客様より、クラウドの利用ガイドラインを作りたいという要望を受けます。クラウドをビジネスとしている会社には当然ながらそのようなアセットは社内に保持していると思いますが、私の部門も一式作成して保持しています。カスケード式トレーニングの合間にも、随時ガイドラインをテーマにディスカッションを行いました。クラウド経験者はもちろんのこと、カスケード式のトレーニングを受けたメンバーがこの利用ガイドラインをリファレンスとして使うと、作業効率が加速します。


図:組織で保持しているクラウド利用ガイドライン。別ウィンドウで開きます。

図:組織で保持しているクラウド利用ガイドライン


リスキリングのサイクルを早める
今回はAWSからAzureへのリスキリングに関してのみ記載しましたが、これに限らず、様々な分野で期間の短いリスキリングが必要になってきています。パブリッククラウドベンダーからは、次々と新しい技術が発表されます。これらのどれが市場でヒットするかは正直わかりません。しかしながら、実績のある技術だけ選んでレディネスやアセット作成を行うようだと常に他社の後塵を拝すことになります。ハードウエアの投資額が大きく、金利も高い時代は投資する対象や社員を教育する分野を時間をかけて慎重に選択したかもしれないですが、現在では次々と出てくる新しい技術に対して、ハックフェストでとりあえず動かしてみて感触をつかむ、仮説でもいいのでビジネスシナリオを作ってみる、カスケード式トレーニングで行っている自習とQ&Aの学習を行う、を早いサイクルで行ってみるとよいと考えています。クラウドサービスなので安いコストで機能を試すことが可能です。1つのサービスであればカスケード式トレーニングでもおそらく2週間分である30分 X 2回~4回で概要はつかめるでしょう(その間にそのサービスのドキュメントを読むという自習は必要ですが)。新しいサービスすべてについてしっかりとアセットを作成しておく必要はないです。これは需要がなくて案件化に至らなかった時のリスクヘッジです。しかし、これらの活動を短期間で行うことでメンバー間でそのサービスの内容を理解でき、実際にオポチュニティが来た時にすぐに準備に取り掛かれるようになります。たとえその技術が自分の案件で使われなくても、このような活動を続けていれば、メンバーは様々な技術に触れることになり、技術の見極めが多角的な視点でできるようになるのではないでしょうか。


「経験がないからやらせない」はメンバーのモチベーションを下げるだけ
アクセンチュアに入社するまでに、これまで私が経験してきた職場の多くではこの、「経験がないからやらせない」という考えを持つ上司が必ずいました。何か新しい技術が会社でリリースされたとしましょう。それに関わるために最初にトレーニングを受けて技術を習得し、それなりの時間を使ってアセットを作り、会社の投資予算で顧客先で導入できるのはごく一部の恵まれた人たちでした。私から見るとこのようなよい機会を得られる人たちは、「上司に気に入られた人たち」、「上司からの評価が高い人」のみでした。当たり前だという人もいると思いますが、私はあえてディスアグリーします。私がやりたいと言っても、「あなたには経験がない」、「それは別の人がやるから」と言われましたが、「そもそも機会ももらえないのに経験がないはないでしょう」、「なんでこの人たちは経験ないのにアサインされるんですか?」と反論したものです。また、誰もがやりたがらない仕事については、いくら経験がなくても強制アサインされることもありました。そのような理不尽なことはエンジニアの方なら一度以上は経験しているはずです。

自分がマネジャーになったら絶対にこのようなマネジャーにはならないと心に決めていました。第1タームのメンバーは現在、弊社でNew IT(Big Data/AI/IoT/Container等)と呼ばれている分野の学習に取り組んでいます。すでにこの分野の案件も実施が決まっており対応できるメンバーを増やしています。New ITの育成トレーニングに参加したメンバーのリストをマネジング・ディレクターの戸賀に提出すると、それを参考にアサインが決まりますので、この分野に携わりたいコンサルタントにとっては、モチベーションにつながっています。

現時点のメンバーの評価や状況を見て駄目だと判断して、彼らが希望する新しいことにチャレンジさせないのは、組織のケイパビリティ向上の芽を摘んでしまうことになります。「あなたは経験ないからやらせません」「あなたは評価が低いから新技術を使う仕事はアサインしない」というのは、マネジャーとしては稚拙とも言えます。少なくとも、メンバーのやりたい仕事をそのメンバー自身が証明できる場を与えることもマネジャーの仕事ではないでしょうか。このトレーニングへの参加はその証明の1つとなっています。

Popular Tags

    最新の記事

      アーカイブ