クラウド人材育成 OJT編 クラウドエンジニア・技術コンサルタントの育成の基本はメーカーの工場にある (後編)

クラウド推進事業本部 シニア・マネジャーの青柳雅之と申します。私はAWSやAzure、GCPといった主要なパブリッククラウドを使用したIT Modernization、ビッグデータ分析基盤等の構築やクラウド人材育成を担当しています。

以前の記事、「組織のAWSケイパビリティをカスケード式に拡大する」,「クラウド人材育成　組織に拡大したAWSのケイパビリティを短期のリスキリングでAzureのケイパビリティに転換する(1)」では、クラウドの技術コンサルタントを育成する方法を紹介しました。この記事の前編では、これらのトレーニング方法を実施するに至った背景や考えを記載しました。後編では社内のトレーニング後に実際にOJTを実施する際の要点をまとめてみます。

プロジェクトにおけるOJT
カスケード式トレーニングによって、メンバーはクラウドの主要サービスを理解し、すぐに仕事に取り掛かれる状態になります。メンバーがこの状態にあれば足手まといにならず戦力になり、人数的にスケールすることが可能です。カスケード式トレーニングは社内におけるトレーニングでしたが、OJTでは次を実施することで早期にメンバーがリーダーとして独り立ちできると考えています。

• 計画とスコーピング
  プロジェクト開始前からプロジェクト開始直後に、ステークホルダーとスコープを合意出来たら、なるべく細かく計画を立てて前倒し作業を行います。すでにアセットがあったりトレーニング済みであれば相当な前倒しができるはずです。メンバーが慣れてきたらタスクの組み立ても実施してもらうのが良いでしょう。前倒し作業を行うことで心理的な余裕が生まれ、より高い品質のアウトプットが作成できます。これも脳科学的なアプローチです。世の中には締め切り直前ではないと仕事ができない人もいます。私もそうでした。それは時間が限られていると集中できるからです。そのような場合、前倒しの締め切りを作ってしまって、それまでにタスクを完了させるようにしましょう。
• 利用ガイドラインからスタート
  新しくクラウドを導入する新しい技術を使用したPoCであっても、そのPoC環境を作成する過程ではクラウドのベストプラクティスに沿った考えを組織が身に付ける必要があります。我々のメンバーはそのベストプラクティスを理解し顧客に説明できなくてはなりません。カスケード式トレーニングを終了したメンバーであれば比較的容易な仕事だと思われますので、リーダーがメインでやるのではなくメンバーがメインで行います。
• 継続的なHackFest
  カスケード式トレーニングで基本的なところはHackFestによりハンズオンを実施していますが、プロジェクトによってはトレーニングでカバーしていない領域も出てきます。クラウドベンダーのサイトには多くのサンプルやチュートリアル、ドキュメントがありますのでこれらから必要なものを抜粋してメンバー全員が手を動かすのが良いでしょう。例えば１日３０分から１時間、必ず時間を取るようにすればどのような領域でも２，３週間でサイトにあるチュートリアルを終わらせることが可能だと思います。
• 個人ワークとグループワーク
  生産性を下げるやり方は、方針を決めたり資料の構成を決める際に、最初からブレストを行うことです。常に話し合いながら資料を作成しているので時間もかかるし、自分が発言しなくてもスキルのある人のアイデアで物事が進み、一部の多大な寄与する人と、大多数のぶら下がるフリーライダーに分かれてしまう可能性があります。物事を決める際は各自が個人ワークでアイデアを考え、グループワークとしては会議の中でお互いに持ち寄り短時間で決定するのがよいです。これにより各自が必ず寄与することができますし、スキルも上がります。
• 会議のファシリテーションの実施
  メンバーが個人ワークを繰り返していれば、アウトプットを出す習慣が身についてきます。会議での発言はリーダーではなくOJT中のメンバーが中心に行います。リーダーはそれをサポートします。若いメンバーを議事録作成に専念させるとあまり成長しません。議事録作成で得られることもあるかと思いますが、その時間をプログラミングとか技術資料作成、会議での討議に使ったほうがスキルが伸びるのは確実です。会社によっては議事録作成はスタッフの仕事と決めているところもありますが、議事録は手の空いている人が書けばいいのです。会議での発言をメンバー中心で行うことにより、将来のリーダーの代替候補が多数できることになります。リーダーはより高度な仕事に移ればいいし、メンバーが育てば休みも取りやすくなります。
• メンバーのVisibilityを上げる
  顧客との会議において発言の場を与えることでメンバーのVisibilityを上げますが、社内向けにもVisibilityを上げます。たとえば社内の会議で仕事の内容を発表してもらったり、育成に関する自分のタスクを委譲して仕事をしてもらいます。特にコンサルタントとしては、人に教えられるスキルを重視しています。

どのような仕事にも対応できる多能工を増やす　AWSやAzure、GCPのトレーニング同時に行う
当初はゆっくり順番にAWS/Azure/GCPを学んでいく予定でしたが、ビジネス側のデマンドでそうも言っていられなくなり、また、トレーニーの成長も早く、Azureに続いてGCPの学習グループも立ち上がりました。AWSの経験者、もしくはカスケード式トレーニングの修了者が学習していますので、おそらく習得が早いです。最近入社した社員はこの３つのクラウドのうち、同時にいずれか２つのクラウドの学習グループに入ることが多いです。学習はおそらく大変ですが、これらのパブリッククラウドは似ている部分も多いため、異なるクラウド間の差異を知ることで実は個々のクラウドの理解も深まるというメリットもあります。

プロジェクトリーダーやその上のマネジメントの仕事
プロジェクトリーダーが一番技術に詳しく、下のメンバーを引き上げる育成能力を持つことが理想です。完全には無理だとしても、その方向に向かうかどうかは、その上のマネジメントの考え方に依存します。マネジメントが、「既存のプロジェクトリーダーには技術力もないし、育成も能力的に無理だしリスキリングも厳しい、管理と調整だけやらせよう」と思うのであれば、おそらく共有リソースモデルを選択するでしょう。この構成でメンバーに不満がなければ、まだ有効に機能すると思います。しかし、マネジメントが、「一部のスキルもやる気もあるメンバー」に「技術を向上する気持ちもスキルもない人たち」のサポートをさせる意識でこの体制を構築した場合は問題が出るかもしれません。「日々努力をして技術力をキープしている正直者が損をする」モデルになるため、ハイスキルのメンバーほど待遇によっては、より技術力のある他の組織に流れていくのではないかと思います。「クラウド人材育成　組織に拡大したAWSのケイパビリティを短期のリスキリングでAzureのケイパビリティに転換する(1)」の内容の再掲になりますが、以下に記載します。

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

図：共有リソースモデル

課題解決者は、専門家としてのナレッジをもってこそ活躍できる
技術的な要素を廃した意味における課題解決者と言えども、顧客とのコミュニケーションや、ファシリテーション能力、ロジカルシンキングだけだけでは新しい何かを生み出すことは難しくなっています。技術はエンジニアを呼びますから、では通用しなくなるでしょう。ビジネス課題から適用する技術を考えるだけではなく、常に最新の技術をキャッチアップし、新しく得た技術知識を起点にビジネス課題への解決策を考えることも必要となる時もあるでしょう。今、クラウドに携わっている若手社員が、いずれは技術も管理もできるマネージャーとなり、我々の本部が技術面で真に強い組織になることを望んでいます。