1．はじめに（クラウドシフトに向けた取り組みと課題）

中部電力では，オンプレミスで運用しているプライベートクラウド上に，インターネット向け大規模開発プラットフォームを構築しており，一般のお客さまや取引会社・協力会社などを対象とした20を超えるシステムが稼働している．2024年度中に大規模開発プラットフォームの保守限界を迎えることから，システム全体の刷新が必要となった．

一方，中部電力グループにおけるDXの取り組みとして，「業務の変革」・「お客さまサービスの変革」があり，それらを実現する1つの方向性として，「新たなITアーキテクチャ・開発体制を整備し，DX推進とコスト抑制を図る」，すなわちパブリッククラウドへ順次シフトする（以下，クラウドシフトという）ことが大目標として掲げられた．

このインターネット向け大規模開発プラットフォームのクラウドシフトを契機に，オンプレミスで稼働している基幹系システムのクラウド推進を加速するための集中的な支援体制と標準ITアーキテクチャを整備する取り組みを，2022年度からスタートすることが決定した．

この方針決定を踏まえ，中部電力グループの唯一のIT子会社である 当社は，全社技術統括部門（CoE（Center of Excellenceの略称））として技術コンサルティング部を2022年4月に発足し，全社横断的にクラウドシフトおよびソリューションの標準化を推進するクラウドCoE（以下，CCoEとする）の役割を担う実行体制を整備した．

CCoEは，システム構成・ITサービス・開発手法を変革するための標準ITアーキテクチャを整備し，各システムの開発プロジェクトでの活用や継続的かつ発展的に標準化を進めることを目的に，業務の役割と業務遂行に必要な技術・スキルを定義し，3つの機能に分類した．

具体的には，標準ITアーキテクチャを企画・運営し全社活動として推進する「①標準ITアーキテクチャの企画」，標準として利用するソリューションを決定し，開発手法・フレームワークやシステム共通的に利用可能な部品等の標準化を行う「②開発標準化」，開発標準化の活動で作成したクラウド利用に関する各種ガイドライン等を各システムの開発プロジェクトに対して展開し，標準の活用方法やクラウド技術支援などの各種活動を行う「③プロジェクト推進支援」の3つである．

「①標準ITアーキテクチャの企画」，「②開発標準化」は技術コンサルティング部がリードし，約1年間という短期間でプラットフォーム領域を中心とした標準の整備や各種ガイドラインの作成がほぼ完了した．

一方，「③プロジェクト推進支援」は，標準を各システムに展開しつつ，各システムで得た新たな知見・ノウハウは「②開発標準化」として取り込み，各システムの所属組織を含む全社大で共有するといった循環型の標準化を目指していることから，メンバーは，本務をそのまま各所属組織とし，CCoEを兼務する形とした．

プロジェクト推進支援メンバーは，目標とした30名の兼務社員を確保することができたが，各所属組織の本務業務が繁忙のため，クラウド技術の習得や各種ガイドラインの活用に向けた習熟度向上の時間が十分に確保できずプロジェクト推進支援活動が停滞するなどの各種問題が顕在化した．

また，オンプレミスで開発した従来のアプリケーションアーキテクチャを踏襲したシステムが多く，本来目指すべきクラウドネイティブ^☆1なアプリケーションアーキテクチャが積極的に採用されない，いわゆるアプリケーションモダナイズの課題が浮き彫りとなった．

これらの課題を解消するため2つの対策に取り組んだ．1つ目は，当社にマッチした効果的かつ即戦力化を目指したパブリッククラウド人財の育成である，2つ目は，パブリッククラウドの特性を最大活用するアプリケーション開発手法の標準化推進，ならびに各プロジェクトの問題解決支援などを行うアプリケーションモダナイズ活動である．

以下では，中部電力グループのクラウドシフトを推進するCCoEの役割や各種取り組みと，プロジェクト推進支援活動を通じて発覚した人財育成・アプリケーションモダナイズの両課題とその対策，および今後の展望について述べる．

2．CCoEの取り組みと課題

2.1　CCoE概要と取り組みについて

当社におけるCCoEは，業務の役割と必要な技術・スキルを定義した上で，円滑な業務遂行が可能とする3つの機能に分類し，キャリアパスとして上位を目指せる機能構成とした．本節ではこの3つの機能ごとに項を立てて詳細を述べる．

2.1.1　標準ITアーキテクチャの企画

顧客ニーズ・市場動向を踏まえ，標準化に取り組む領域を標準ITアーキテクチャとして定め，時代の変化に合わせて持続的に更新する．

• （1）標準ITアーキテクチャ推進

  標準ITアーキテクチャの計画や推進人財育成などの全体計画の立案や運営ルール等を整備し，全社の戦略・計画を担う部署と一体となり標準化を推進する．

• （2）標準ITアーキテクチャ企画・更新

  次に採用する技術検討やロードマップの策定，技術開発計画等を検討し技術統括部署に上申する．

2.1.2　開発標準整備

開発手法・フレームワーク・共通備品の標準化を行い，現場の開発生産性向上に寄与する．

• （1）標準化推進

  PaaSやIaaS等のパブリッククラウド・サービスの標準化や開発フレームワーク，システム間連携など標準化を推進し，標準ソリューションを決定する．

• （2）開発運用スタイル変革

  パブリッククラウドを主体としたDevOps^☆2やアジャイル開発などの標準のツール類や体制・工程・作成ドキュメント等を検討・推進する．

• （3）開発標準運営

  開発運用スタイル変更や，アジャイル開発実績等を踏まえて，契約方法，プロジェクト管理・品質管理手法の運営ルール化等を検討・整備して，全社展開する．

• （4）ナレッジベース・ポータル運営

  標準ITアーキテクチャをターゲットに，ガイドライン・技術ノウハウ・活用事例・FAQなどの有益なナレッジを全社共有して，開発標準化を推進・浸透させる．
  　各プロジェクトで標準適合を確認するため，アセスメントシートを整備する．

2.1.3　プロジェクト推進支援

集中的に標準ITアーキテクチャ・パブリッククラウド技術・アジャイル開発スキルを先行習得し，各プロジェクトの推進支援を担うことで，現場への展開を行う．

具体的には，プロジェクト推進支援に必要となるパブリッククラウド・アジャイル開発・標準ITアーキテクチャ等のスキルを有した技術者を育成し，製造部門と一体となってプロジェクトを推進する．プロジェクトのアセスメント結果より，課題・ニーズや標準とのギャップを把握し，支援内容を判断・調整する．

2.2　CCoEの課題

CCoE活動を通じて2つの課題が浮き彫りとなった．

2.2.1　アプリケーションモダナイズの課題

プロジェクト推進支援の重要な活動として，各プロジェクトの企画・要件定義フェーズにおいて，標準ITアーキテクチャ推進活動で定義した標準ソリューションの適用，標準ガイドラインへの適合性をそれぞれ確認するアセスメントがある．

具体的には，計18種類の標準項目に対して，標準適合可否・適用ソリューション・標準適用しない場合の理由などを確認するための「標準ITアーキテクチャ・アセスメントシート」を活用してアセスメントを実施している．

この活動を通じて，標準ソリューションの適用率は一定数を超えているものの，オンプレミスで開発した従来のアプリケーションアーキテクチャを踏襲したシステムが多く，本来目指すべくクラウドネイティブなアプリケーションアーキテクチャが積極的に採用されず，以下のようなアプリケーションモダナイズ化の課題が浮き彫りとなった．

• 要求される処理能力に対して適切なリソースを確保し，柔軟性を備えたスケーラビリティの高い構成である「スケールアウト・スケールイン」の実装が考慮されていない．
• コードのテストやデプロイ作業の自動化などアプリケーション開発をより効率的，かつ迅速に実現可能なDevOpsが適用されないケースが多く，パブリッククラウドの特性を活かしきれない．

開発標準化活動で作成した各種ガイドラインは，標準化推進のために必要となる全体方針や標準ソリューション定義，活用イメージ，ルール等を対応範囲としており，具体的な実装方法や各種手順書作成などは，アプリケーションを開発・保守する各部門の対応範囲である．

そのため，アプリケーション部門で先行的に実装へ向けた検討や各種検討を実施して実現性を確立した上で，各プロジェクトで適用するというステップが望ましいが，現状においてその枠組みが確立されていないことが課題であると結論付けた．

この課題に対する施策として，クラウドネイティブなアプリケーション開発手法の標準化の促進と個々のプロジェクトの技術課題を解決する「アプリケーションモダナイズ活動」に取り組んだ．

2.2.2　パブリッククラウド人財育成の課題

当社の人事部門では，人財育成施策の体系に合わせた豊富な社内研修メニューが整備されている．2022年度時点におけるパブリッククラウドに関する社内研修は，基礎研修に限定されており，今後の研修ニーズに合わせて拡充していく方向性であったため，2022年度に実施したプロジェクト推進支援メンバーへのパブリッククラウド人財育成は，CCoE内での対応が必要となった．

そこで，CCoE内に人財育成を推進するための事務局体制を確立し，人財育成の実行計画を作成することとした．効果的な人財育成計画とするため，プロジェクト推進支援メンバー全員に対して，クラウドに関するスキルレベルや業務経験，本務部署のプロジェクトの業務概要や従事時間などを事前にヒアリングし，分析を進めた．

その結果，育成対象者の大半が今回のクラウドシフト対象のプロジェクトのメンバーであるがクラウドの業務経験がほとんどなく，かつ現行業務繁忙により人財育成やプロジェクト推進支援活動に従事する時間の捻出が厳しいことが分かった．

このため，各自が業務繁忙の中でも自由に学習ができ，個人知識レベルに応じてクラウドの基礎から高度技術までの研修を選択可能とする方針とした．

具体的には，クラウド技術関連は，社内で利用し始めたオンライン学習プラットフォームを最大活用し，数百ある研修コンテンツから他社利用実績など参考に約30コンテンツを選定した．また，標準ITアーキテクチャ関連はCCoEから選出した社内講師によるオンライン形式の学習に加え，オンライン会議の録画機能を活用して動画として保存し，研修に参加できないメンバーにも閲覧可能とした．

人財育成事務局が主体となり，約4カ月間のパブリッククラウド人財育成の推進した活動結果や，受講者からのアンケート結果などから，以下の課題を確認した．

• 研修受講を各自のペースに任せたこともあり，全体的に研修期間が間延びし，受講者のモチベーション維持・向上に苦慮した．
• 研修環境整備や研修開催日程が合わないなどの理由により，早期技術習得に有効である実機操作を伴う研修が実施できなかった．
• 根本的な課題として，業務繁忙により技術習得の時間が十分に確保できない．

このようなパブリッククラウド人財の育成課題は，製造現場でも同様であるため，全社的な課題に対する施策として，教育時間の確保が比較的容易な新入社員を対象に，集中的かつ効果的な教育によって，クラウドの即戦力化を目指した「パブリッククラウド実践教育」に取り組んだ．

3．課題解決に向けて取り組む施策

3.1　アプリケーションモダナイズ活動

3.1.1　取り組みの背景

CCoEの発足後，開発プロジェクトのパブリッククラウド移行数は増加していた．しかし，パブリッククラウドの従量課金を活かせるアーキテクチャの採用や，変化へ柔軟・迅速に対応するためのDevOpsなどの手法の採用が進まず，開発・保守にかかるコスト最適化やDX推進に必要な効率化・高速化は進んでいなかった．

原因としては，次の２点が考えられた．

• パブリッククラウドの特性を理解し，必要な分だけリソースを使う弾力的な運用を実現するためのアーキテクチャを検討・適用できるスキル・マインドを持った人財の不足．
• DevOpsという従来とは異なる開発・運用手法を理解し，プロジェクトへ適用できるスキル・マインドを持った人財の不足．

こういった人財を以降，アプリケーションアーキテクトと呼称することとする．

アプリケーションアーキテクト人財の不足は，開発プロジェクトのリスクという形で内在し，DX推進の妨げになっていた．開発プロジェクトのパブリッククラウド移行が次々と進行していく中で，アプリケーションアーキテクト人財の確保は急務であった．

しかし，アプリケーションアーキテクトはIT技術者市場の中でも希少性が高いため，パブリッククラウド移行プロジェクトの拡大に合わせて，大量に人財確保することは困難な状況であった．市場からの人財確保が難しい以上，当社内で人財育成を進める必要があったが，こういった人財の育成は数年スパンで行う必要があり，早期育成もまた困難な状況であった．

一方で，開発プロジェクトは待ったなしの状況のため，アプリケーションアーキテクト人財の確保と育成という，2つの課題を同時に解決する必要があった．

そこで，少数精鋭のアプリケーションアーキテクトをリーダーとしたアプリケーションモダナイズチームを立ち上げることでこの課題を解決することを考えた．

3.1.2　施策概要

アプリケーションモダナイズチームの目的は大きく以下の2つである。

• （1）アプリケーションアーキテクトによる開発プロジェクトの伴走支援

  開発プロジェクトと伴走しながら，技術的な課題を解消することで，クラウドネイティブなアプリケーション開発を推進していく．

• （2）アプリケーションアーキテクト人財を育成しパブリッククラウド拡大へ対応する

  開発プロジェクトの課題を解消していく中で，各チームメンバーへのスキルトランスファーを進め，次世代アプリケーションアーキテクト人財の育成を行う．

このアプローチを取ることにより，2つの課題解決の両立を狙った（図1）．

アプリケーションモダナイズチームのリーダーには，開発プロジェクトが抱える異なる種類の課題に対して網羅的に対応できる人財を登用した．具体的には，次の人財を登用した．

• パブリッククラウドの特性を理解し弾力的な運用を実現するアーキテクチャの検討・実装経験がある人財．
• DevOpsやアジャイル開発の経験が豊富な人財．

一方でチームのメンバーには，当社で数年間の開発経験がある若手メンバーと入社間もないメンバーをそれぞれ登用することとした．

理由としては，アプリケーションアーキテクトのスキル・マインドは，従来型のオンプレミス中心の開発スキル・マインドとは異なる部分が多いため，従来型の開発経験が少ないメンバーを登用することで，バイアスが掛かることなく早期の育成につながると考えたからである．また，開発経験や開発スキルが異なるメンバーを同じチームにすることにより，段階的なスキルトランスファーが行えると考えた．具体的には次のとおりとした．

1. 取り組み初年度

   リーダーから，数年開発経験があるメンバーに対して，アプリケーションアーキテクトに必要なスキルや，チームを推進していくためのリーダーシップを実戦の中で伝えていき，次期リーダー候補を育成していく．次期リーダー候補のメンバーは，入社間もない開発経験の少ないメンバーに対して，学んだスキルを教えることで，スキルの理解や定着度を高めていく．

2. 取り組み次年度以降

   次期リーダー候補のスキルが一定の水準に達したところで，リーダーと役割を交代して，当該分野のリーダーにチャレンジをする．

このように段階的なスキルトランスファーを行うことで，アプリケーションアーキテクト人財の育成拡大が図れると考えた（図2）．

3.1.3　委託先の選定

アプリケーションモダナイズチームの発足にあたり，各チームのコアとなるアプリケーションアーキテクト人財，および育成のスキーム確立については委託によって対応することとした．

なぜならば，社内に在籍するアプリケーションアーキテクトは希少であり，またすでに複数のプロジェクトにアサインされている状況だったため，人財確保が困難だった点が挙げられる．

また，社内のアプリケーションアーキテクトを育成するカリキュラムや，キャリアパスが確立していなかったこともあり，今回その確立も含めて委託先に依頼することとした．

委託先の選定にあたっては，アプリケーションアーキテクト人財の育成実績があり，今回必要なスキルを持ったアプリケーションアーキテクトを複数派遣ができるA社に決定した．

3.1.4　アプリケーションモダナイズチームの発足と活動方針

2023年4月にアプリケーションモダナイズチームを発足した．プロジェクト特性に合わせた対応を想定して，立ち上げ時には2チーム制を取ることとした．

各チームの編成としては，1人ずつ核となるメンバーとしてアプリケーションアーキテクト人財を配置し，数年開発経験のあるメンバーと開発経験の少ないメンバーをそれぞれ配置した．

各チームのスキル・経験をなるべく均等にすることで，開発プロジェクトに対する課題解決能力や，アプリケーションアーキテクトの人財育成能力についても大きく差が出ないような工夫を行った．

アプリケーションモダナイズチームの活動は，アジャイル開発をベースに進めることにした．主なねらいは次の2点となる．

• プロジェクトで発生する課題に対して柔軟に対応する．
• アジャイル開発手法やDevOpsツール活用のスキルを実践しながら身につける．

アジャイル開発やDevOpsの知識や経験については，現場のプロジェクトだけでは身につけることが困難なため，本活動の中に取り入れることで，自然体でのスキルアップを目指した．

3.1.5　プロジェクト伴走アプローチ

本活動の目的の1つである開発プロジェクトの技術課題の解決アプローチを紹介する．

まず各チームは，中部電力グループ内で業務システムとして今後具備して欲しい機能や非機能について調査を行った．その結果，システム変更が容易に行える柔軟性を確保するための「システム疎結合化技術」に注目が集まっていることが分かった．「システム疎結合化技術」とは，システム間やシステム内の機能をAPI^☆3やキャッシュサービス^☆4などを活用することで，機能間の依存度を下げる技術である．これにより，システムの変更を行った際の影響範囲を限定化し，またシステムの利用状況に合わせて柔軟にアプリケーション実行環境を増減することができるようになる．

こういった技術をプロジェクトへ適用することで，変化へ柔軟・迅速にシステム対応することや，弾力的なクラウド運用するためのアーキテクチャの採用につながると考えた．

アプリケーションモダナイズの各チームは，提案の軸となる技術（例：システム疎結合化技術）を設定した上で，対象プロジェクトを調査した．その結果，複数のプロジェクトが候補に挙がったため，次の評価軸で対象プロジェクトを設定した．

• 適用した際に得られる効果の大きさ．
• 提案した際に受け入れが可能な工程のタイミング．

次に，対象プロジェクトに対して，アプリケーションモダナイズチームが仮説として考えるシステム課題とその対応策について提案を行った．あるプロジェクトに対して実際に提案した内容を紹介する．

• （1）システム課題仮説

  　対象プロジェクトのアーキテクチャでは，スケールアウト／スケールインを考慮できておらず，パブリッククラウドの従量課金を活かし，リソース量を柔軟に変更することが困難であり，コスト低減が図れないと考えた．

  具体的には、クライアント端末とアプリケーション間のセッション情報を、アプリケーション実行サーバで保有する構成となっていた。この構成では、システムの利用状況に応じてサーバをスケールアウト／スケールインを実施すると、システムの利用中断や、再ログインが必要になるなど、利用者の利便性を大きく損なう可能性があった。

• （2）対応策

  アプリケーションで利用するセッション情報の保存先をアプリケーション実行サーバから外部の共有キャッシュサーバへ切り替える．これを実現するためのアーキテクチャ図や，実装サンプルアプリケーションを開発し，プロジェクトへ提供する．

提案初期は，仮説として設定したシステム課題やその対応策について，なかなか理解を得られないことが多かった．これに対しては，開発プロジェクト側の疑問や質問に対して，1つ1つ丁寧に対応していくことで信頼を少しずつ獲得するアプローチを取った．その結果，開発プロジェクトの理解を得ることができ，共同でアプリケーションアーキテクチャの検討を進めることができた．

プロジェクト伴走対応では，上記内容も含め以下のような活動を実施した（表1）．

3.1.6　アプリケーションアーキテクト人財育成アプローチ

次に，アプリケーションアーキテクトの人財育成をどのような形で進めたかを紹介する．

まず本活動のベースとなるアジャイル開発に関する知識習得から進めることとした．なぜならば，アジャイル開発経験があるメンバーもないメンバーも居たため，ベースラインをメンバー間で合わせることで，活動を進めていく中でのコミュニケーションコストを抑えることができると考えたためである．アジャイル開発経験が豊富なリーダーを中心に，座学やワークショップを開催することで，メンバーのベースラインの引き上げを行った．

具体的には最初の半月間で以下の内容をワークショップ形式で実施した．

• ワーキングアグリーメント（チーム活動のルール策定）
• 個人目標／チーム目標の設定
• スキルマップの作成（各メンバーの保有するスキルを自己申告）
• インセプションデッキ（簡易なプロジェクト計画書作成）
• ユーザーストーリー（利用者を意識したユースケース想定）

本ワークショップは以下のねらいを達成するために行った．

• アプリケーションモダナイズチームの活動目的・目標や活動ルールを自分たちの言葉で合意することで自分事化を促進する．
• 各メンバーのスキルを可視化することで活動前後の成長度合いを計測する．
• 対象とするプロジェクトの課題に対して，利用者目線で仮説を立てる．

アジャイル開発のスキル・経験については，開発プロジェクトと伴走する中で解決が必要となる課題・タスクを一定の検討期間であるスプリント^☆5の中で実際に対応することで獲得を図った．

スプリントの終了に合わせて，振り返り（レトロスペクティブ^☆6）を実施することで，良かった点・改善が必要な点・次回のスプリントで挑戦したい点などをメンバー間で共有した．これにより，スプリントを1つ完了するごとに，改善を積み重ねていき，チーム活動の生産性を高めることができた．

また，これら一連の活動をDevOpsツールで運用していくことで，DevOpsツールの使い方や，向き・不向きといった特徴についても学習することができた．

提案の軸となる技術（システム疎結合化技術）については，各チームのアプリケーションアーキテクトを中心に，技術の勉強会をメンバー間で行った上で，サンプルアプリケーションの開発をモブプログラミング^☆7で行いながら進めた．これにより，上級者の開発方法や思考を初級者も見聞きすることで経験することができ，スキルトランスファーを効率的に進めることができた．

3.1.7　結果と考察

今回のアプリケーションモダナイズ活動は下記の期間，体制で実施した．

• 活動期間：2023年4月中旬～9月（約5カ月間）
• 活動したチーム数：2チーム
• 活動メンバー数（リーダー含む）：8名

これを踏まえ，活動の目的となっていたプロジェクト伴走の活動実績や，アプリケーションアーキテクト人財の育成実績結果を示す．

• （1）プロジェクト伴走の活動実績
  • 対象プロジェクト数：2プロジェクト
  • プロジェクト伴走活動実績数：4項目（表1）
  • プロジェクト課題対応数：18

  1つの開発プロジェクトに対して，1チームを割り当て，プロジェクト伴走を実施した．

  約5カ月間で1チーム平均2つのソリューション提供や新技術の検証を行うことができた．

  提案したソリューションは，それぞれ開発プロジェクトに採用された．これにより，スケールアウト／スケールインに対応したアプリケーションを実現することができた．

  またプロジェクトで発生した技術的な課題については，要件定義タイミングの早期に検証を行い解決した．これにより，後工程での手戻りを抑制し，手戻り発生によるコストの低減やアプリケーション自体の品質強化に貢献できたと考えている．

• （2）アプリケーションアーキテクト人財の育成結果
  • 育成対象人数：6名
  • サブリーダー（次期リーダー候補）経験者数：3名
  • 取り組み前後のスキルセット変化（育成対象者）

  アプリケーションアーキテクトの人財育成の結果としては，育成対象の6名，および次期リーダー候補であるサブリードの3名の取り組み前後のスキルセット変化で評価した．

  まずアプリケーションモダナイズの活動を進めていく上で必要となるスキルセットを9つ設定し，到達度合いに応じて数値で重み付けを行った上で，取り組み前後で評価を行った（表2）．

  

  育成対象メンバー平均では，アジャイル開発経験，PaaSサービス技術知見，新規領域や技術へのチャレンジ姿勢が1ポイント以上向上した（図3）．

  

  サブリーダー経験者に絞って評価をすると，メンバー平均で挙げた項目以外にコミュニケーション力が1ポイント以上向上した（図4）．

  

  5カ月という限られた期間ではあったものの，開発プロジェクトとの伴走と，外部登用のリーダーからのスキルトランスファーを通じて，各メンバーの一定のスキルアップを図ることができたと評価している．

  今回の結果と評価を踏まえて，スキル強化が必要な領域を設定し，改善施策を実施していく予定である．また，次世代リーダーの育成については，サブリーダー経験者を中心に，リーダーの役割を担ってもらうことにより，リーダーに必要なスキル強化を図っていきたい．これにより，早期のアプリケーションアーキテクト人財の育成を行っていく予定である．

3.2. パブリッククラウド実践教育

3.2.1　取り組みの背景

クラウドシフトの大目標が掲げられたものの，当社の製造現場では，従来の標準であるオンプレミスにおける業務システム開発・保守の業務割合が高く，現場に配属された新入社員は，オンプレミスの業務システム保守を数年間経験し，業務知識・技術・スキルを習得後，システム開発案件を担当するケースが多い．また，システム開発案件を担当してもシステム規模が大きい，担当システム数が多いなどの要因から，プロジェクトおよび委託先のマネジメントをする役割の比重が高く，技術力が身につかないケースもある．

このような人財育成アプローチでは，社員が新たな技術を身につけて，内製で開発できる技術力を身につけるまでに時間を要するのが現状である．目の前のクラウドシフトを進めていくためには，従来とは異なるアプローチで，戦略的にパブリッククラウド人財育成に取り組む施策の必要性が高まってきた．

3.2.2　施策概要

当社がクラウドシフトをリードするために，即戦力となるパブリッククラウド人財の育成を目指した短期集中研修として，3カ月間の「パブリッククラウド実践教育」を新たな施策として実施した．主な目標は次の3点である．

• 即戦力となるクラウドエンジニアを早期に育成する．
• 標準ITアーキテクチャに準拠したシステム開発ができるクラウドエンジニアを育成する．
• 2023年度中にクラウドクラウドベンダーが実施する中級資格の合格を目指すことができる技術者を育成する．

この目標を達成可能な委託事業者を選定することとした．

3.2.3　教育対象

教育の対象者は，教育期間として定める3カ月間専任可能な新入社員および若手社員とした．

新入社員および若手社員を優先した理由は，専任させ易いことに加えて，新技術への対応力があり，かつ成長意欲・向上心も高いため，パブリッククラウド人財として育成することで，今後拡大するパブリッククラウドのシステム新規開発・再開発の貴重な戦力としての活躍が期待できるからである．

また，受講者が学びを活かして活躍できるように，配属先部署にはあらかじめ「受講後はパブリッククラウド業務に従事させること」を前提条件とした．

3.2.4　委託先の選定

委託先の選定にあたっては，委託先決定における評価ポイントを定め（表3），その充足度の最も高く，パブリッククラウドの実践的な技術力と人財育成のノウハウを兼ね備えたB社に決定した．

3.2.5　標準に則した教育カリキュラム

より実践的なアプリケーション開発スキルを習得するために，委託先であるB社が実際に新入社員向けに行っているカリキュラムをベースにテーラリングすることで，標準ITアーキテクチャに準拠したカリキュラムを設定した（図5）．

教育効果を高め，学習内容の定着につながるように，各コースに連続性を持たせた構成とした．具体的には，顧客の要件に合わせてオンプレミスで設計・開発したアプリケーションを，クラウドへリフト＆シフトしたのちに，受講者自らが拡張機能を企画・実装するアジャイル開発にチャレンジする流れである．受講者はこれにより「標準に則したクラウドシフト経験」を獲得することができる．加えて，最終段階である開発演習では講義で扱っていない技術を受講者で自ら調べながら取り組むスタイルを取り入れることで，実際の現場で活かすことのできるスキル習得を目指した．

3.2.6　学びの定着を促進する工夫

教育の効果を最大化し，学びの定着を促進するため，目標意識・活動サイクル・仲間意識の3つの観点で工夫を図った（図6）．

• （1）目標意識
  • 当社がおかれている状況や目指す方向性をキックオフ時に明確に説明することで目標意識の醸成を図る．
  • 各コースの学習目標に対して，受講前／中間／最終で習熟度を定点観測することで目標に対する自身の成長度合いを可視化する．
• （2）活動サイクル
  • 講師・受講者間，受講者同士のコミュニケーションを重視するために，対面・集合型で開催する．
  • 演習を多く設定し，講義で学んだ知識を活かしてアウトプットすることを重視する．
  • 学習者の課題や悩みを日々解消するために，システム開発経験を有する技術者をメンターとしてアサインし，伴走型でサポートする．
  • 受講者に経験や前提知識の差はあったが，それぞれが成長できるよう受講者同士で協力し教え合うことを重視した．これにより，未経験者はじっくりと知識の定着を図り，経験者は自分が学習するだけでなくほかの受講者に教えることで一段上の知識定着を目指す．
• （3）仲間意識
  • 感謝を気軽に伝えあうことができるスマホアプリを導入し，受講者同士の相互関与，コミュニケーション強化を図る．
  • 合宿や懇親会などのイベントによって一体感の醸成を図る．
• （4）その他
  • 研修の途中で経営層向けの成果発表の場を設け，モチベーションの向上を図る．

3.2.7　結果と考察

教育の効果を測定するために受講者へのアンケート・配属現場へのヒアリングを次のように実施した結果を次に示す．

• （1）研修各コースの評価

  受講者に対して，各コース終了時に「満足度」のアンケート調査を実施した．その結果，各コース評価は，平均4.9となり，前年度に実施したプロジェクト推進支援の人財育成における研修評価である平均3.8を上回った（表4）．

  

  この結果は，実際に報告会を聴講した役員／人事部／上長としても同様の印象であり，今回のカリキュラムが受講者にとって非常に有意義なカリキュラムであったことが判断できる．

• （2）学習目標に対する習熟度の成長

  受講者に対して，学習目標に対する習熟度の重み付けを設定し，研修の受講前・受講後で，アンケート調査を実施した（表5）．

  

  その結果，学習目標に対して，研修受講前は技術スキルの項目で「できていない」と評価するメンバーが多かったが，研修受講後には「だいたいできている」に変化した（図7）．

  

  新入社員を中心とした若手の自己評価であるため「できている」と自信を持って申告しづらい点を差し引いても，学習目標に対する成長を十分に実感できる研修であったと判断できる．

• （3）製造現場の評価

  研修の1カ月後に受講者の所属する上長・指導員に対し，受講者の業務内容，IT技術／プログラミング言語／クラウドの習熟度，今後の研修に対する期待／希望をヒアリングした．その結果，クラウド／プログラミング言語などの基本的な技術知識が定着している，業務指示などの会話が成立する，不明な点は自身で調べる姿勢・スキルが身についているなど「配属後の教育負荷が減った」というコメントがあった（表6）．

  

  比較対象がなく定量的な評価はできないが，このヒアリング結果から，各製造現場でパブリッククラウドにおけるシステム開発に必要なベース知識・スキルを1から指導する必要がなくなっているため，製造現場の負荷軽減を果たしているといえる．

4．今後の展望

アプリケーションモダナイズ活動・パブリッククラウド実践教育ともに，2022年度下期に企画・計画を立案し，2023年4月から本格的に始動した発展途上の取り組みであったが，期待以上の成果が得られた．そのため，2023年下期以降も本取り組みを継続することを決定し，さらに拡大・発展させていく計画である．

本章では，それぞれの活動の今後の展望について紹介する．

4.1　アプリケーションモダナイズ活動の高度化

2023年度上期は，現行基幹系システムのクラウドシフトで共通的な課題となり得る「アプリケーションのセッション疎結合化」を技術テーマとして選定し，2つのクラウド化プロジェクトを対象に伴走型支援を実施した．本テーマを先行的に検討・検証することで，柔軟性を備えたスケーラビリティの高いクラウドネイティブなアプリケーションの提案を要件定義段階で実現することができ，プロジェクトに貢献可能な活動であることを確認できた．

一方，新規事業システムは，現行基幹系システムとは異なり現行仕様がなく，プロダクトオーナーのシステム要件や仕様を順次決定し，最適なアプリケーションアーキテクチャの実装の検討・検証が必要となってくる．

それらの状況を踏まえて，2023年度下期は，より多くのプロジェクトのデリバリに貢献するため，基幹系システムのクラウドシフトでかかえる全社横断の技術課題や難易度の高い技術テーマに取り組むとともに，個別の課題・ニーズにも迅速かつ柔軟に対応していく予定である．

また，新規事業システムをモダナイズ活動の支援対象に加え，より高度でクラウドネイティブなアプリケーション開発にチャレンジする予定である．これらの知見・ノウハウを全社大に共有・展開するとともに，本活動を通じてアプリケーションアーキテクトの育成を加速させていく．

4.2　パブリッククラウド人財育成の全社への拡大

2023年度のパブリッククラウド実践教育は，戦略的かつ試行的な位置づけとして，CCoE主導で実施してきた．

本教育の満足度・習熟度は，受講者から軒並み高評価であった．また，役員・人事部門が参加した報告会において，受講生のプログラミング・クラウドの技術力・プレゼン力が向上し，研修受講前からの成長は明らかに高くなっていたため，期待以上の成果があったとの評価を得ることができた．

これらを受け，2024年度は人事部門主導に変更し，技術系新入社員全員を対象に新入社員研修のカリキュラムに本研修を組み込む方向で検討を進めている．

受講人数が大幅に増え，研修期間を3カ月から4カ月へ1カ月間延長する方向性であり，さらなる効果的な研修とするため，クラウド学習の充実化，スキルレベルに合わせた複数の研修コースの提供などさまざまな工夫・改善を検討している．

一方，すべての役職員を対象に，会社業績に貢献し得るスキルの習得を目指した「学ぶ時間と機会の創出」を全社的に推進している．

この施策に対応するため，2年目以上の社員を対象に，現業務を担当しながら効果的なパブリッククラウド技術のリスキリングが可能な教育も併せて検討していく予定である．

5．おわりに

中部電力グループにおける標準ITアーキテクチャ活動のさらなる推進に向けて，アプリケーションモダナイズ活動やパブリッククラウド人財育成をCCoE主導で試行的に計画・実行し，いずれも経営層に高い評価を得た．

この実績・経験を踏まえ，全社機能である経営戦略部門・人事部門とも連携し，2024年度の経営戦略・人財戦略として計画的に実行する方向で検討中である．

現在，標準ITアーキテクチャ活動は，経営層の全面的なバックアップを受け，全社向けに情報発信するステアリング会議を毎月開催しており，全社大で推進する機運が高まっている．

今後の基幹システムのクラウドシフト加速や，新規事業システムなどの新規領域への積極的な参加に向けて，全社一体となって取り組んでいきたい．

最後に，本稿で述べた取り組みを進めるにあたり，多大なるご協力を賜った，協力会社および関係者の皆さまに，紙面をお借りして感謝の意を表する．