1．運用自動化が求められる背景

1.1　取り組みの背景

本稿で紹介する取り組みでは，背景としてシステム運用業務の抱える課題がある．

システム運用業務とは，企業等に導入されているシステムの安定稼働のために日々実施する運用管理業務を指す．具体的には，サーバの起動停止，定期的な点検，システムやネットワークの稼働監視等が該当する．

このシステム運用業務では昨今，運用技術者の不足が問題となっている．その理由として，主にシステム運用業務を取り巻く以下のような現状がある．

• DX等に伴うIT活用のさらなる推進による情報システム資産の増加
• スピードと品質を両立するためのヒューマンエラー対策のコスト増大
• ゼロトラスト環境下でのセキュリティ対策に対応するための作業の増加

クラウド利用拡大などのプラットフォームの多様化へ対応するため，システム運用の手順は複雑化し，業務量は右肩上がりに増加している．このため，従来の運用業務のやり方では，運用技術者の人手不足は急速に深刻化していく．

よって，複雑・多様化する運用手順を標準化して属人化を排除する，人間系の作業を可能な限りシステム化する（運用自動化の推進），といったシステム運用に必要となる業務量の削減対応が，昨今における企業にとっての喫緊の課題となっている．

1.2　本稿の概要

ほくでん情報テクノロジー（以下，当社）は，ほくでんグループ本社の電気事業にかかわる情報処理業務全般をサポートしている．当社においても電力自由化による制度変更への対応等から情報システム資産の増加が進み，運用技術者の人手不足が大きな課題となってきた．

課題解決の方策として，当社では構成管理ソフトウェア「Ansible（アンシブル）」 [1]を活用した運用業務自動化による省力化を目指し，基盤の整備や実運用業務への適用拡大に取り組んでいる．

本稿では，統合的な運用自動化基盤の構築に関する取り組みと成果を事例に，システム運用における人手不足に対するその有効性および今後の展望について，以下の構成で考察する．

• 統合的な運用自動化基盤の検討
• Ansibleによる自動化の検証
• 運用自動化の適用効果
• 今後の展望

2．統合的な運用自動化基盤の検討

2.1　統合的な運用自動化基盤とは

システム運用業務における人手不足の解決策として，特に注目されているのが「運用自動化」である．運用自動化とは，これまで人手で行ってきた作業の一部または全部を，ソフトウェア等を利用することでシステムに代替させることを指す．Excel [2]マクロを利用したPC業務の自動化等は従来から広く用いられてきたが，近年では専用のソフトウェアを利用することで，監視オペレーションやサーバ上でのコマンド操作といったシステム運用業務全般に自動化を拡大することが注目されている．

当社ではこれまでにも，部分的なシステム運用作業の自動化に関する取り組みが行われてきた．しかしそれは，各担当者が自身の担当する作業の一部を自動化するのみに留まっており，「業務ごとに自動化に利用したツールが異なる」「担当者のスキルレベルの違いにより自動化の範囲やレベルに差が生じる」「部分最適化され再利用できない」「作成者以外がメンテナンスできない」といった課題があった．よって，成果は限定的なものとなっており，人手不足解消の対策としては改善が必要な状況であった．

そこで，今回の運用自動化の取り組みでは，個別のソフトウェア導入ではなく，統合的な運用自動化基盤を構築することで，人手不足解消へ寄与できるものと仮定した．

統合的な運用自動化基盤とは，具体的にはさまざまな業務に対し横断的に利用できる自動化の基盤を指す．

従来の自動化と比較すると，ツールの使い分けが不要であり，ワンストップであらゆる業務に活用可能な点に新規性がある．対象業務を拡大する際や利用者を増員する際にも，単一の操作方法を学習すればよいため，個別最適化された自動化に対し学習コストの観点でも優位である．

2.2　取り組みの目的

今回の取り組みでは，これまでの部分的な自動化の有効性の低さに対し，統合的な運用自動化基盤の構築による課題解決を図ることで，システム運用業務の時間削減を目指した．

システム運用業務の時間削減を実現するためには，一度実装した自動化が，さまざまなシステム運用業務や環境にそのまま活用できる必要がある．たとえば，業務A単体での自動化による時間削減効果が1時間と仮定した場合，同じ自動化が業務Bおよび業務Cにもそのまま適用できれば，時間削減効果は単純計算で3倍の3時間となる．これをさらに業務D，業務Eへも適用拡大できれば，運用業務全体における自動化の割合を高め，人間系の作業を減らすことで人手不足解消の効果を発揮できる．

そこで，今回の取り組みでは，次の3点をポイントとして基盤構築および検証を実施することとした．

• ①　プラットフォームによるツールの分散の解消

  システム運用の対象となるサーバには，さまざまなプラットフォームが存在している．OSの違いにより，Windows [3]ならばバッチプログラム，Linux [4]であればシェルプログラムを別々に用意する等，従来の部分的な自動化では業務ごと，プラットフォームごとにツールにばらつきがあった．このため，各ツールの利用方法を学習しなければ自動化を利用できず，それが少なからず活用のハードルとなっていた．また，ツールのメンテナンスや利用拡大を行うにも，多岐にわたるツールのノウハウを全員で共有し続けることは難しい．このため，結果としてツール単位での属人化が発生し，運用自動化の浸透を阻害する要因となっていた．

  このことから，多様なプラットフォームに対し横断的に利活用できる運用自動化基盤の整備を目指した．

• ②　運用担当者のスキル差異の補填

  システム運用担当者のスキルにはそれぞれ違いがあるため，ツールの利用に求められるスキルがハードルとなる場合があった．運用自動化の手段としては，たとえばExcelのVBA [5]やシェル，バッチの開発といったプログラミングの知識を必要とするものも存在する．しかし，開発経験のない担当者の中には，こうしたツールの利用に抵抗を感じる者もいる．

  今回の取り組みでは，担当者間での利用の差が生じないような，ユーザビリティの高い運用自動化基盤の実現を検討した．

• ③　運用自動化の適用範囲の拡大

  運用自動化の適用範囲をより広範囲へと拡大することで，従来は限定的であった運用自動化の適用効果をより高めることができ，システム運用業務の時間削減へ繋がるものと考えた．

  システム運用業務全体へ自動化を適用できれば，一つひとつの作業の前後に実施している関連作業も自動化できる可能性がある．こうした作業は単体での作業時間は短いものであっても，大量の情報システム資産へ適応する際に，トータルで運用コストを圧迫している．ヒューマンエラー対策のための2名以上でのダブルチェック作業，セキュリティ対策のためのワンタイムパスワード発行作業等が代表例であり，これらの作業を一部でも廃止することができれば，さらなるシステム運用作業の時間短縮が図られると想定した．

3．Ansibleによる自動化の検証

3.1　自動化ソフトウェアの製品選定

当社における運用自動化の取り組みでは，先述のポイントを踏まえ，利用するツールに「Ansible」を採用した．以下に，Ansibleの概要と採用理由を説明する．

3.1.1　Ansibleの概要

Ansibleとは，RedHat社 [6]が開発するオープンソースの構成管理ソフトウェアである．Ansibleは幅広いプラットフォームに対応しており，指定したサーバへリモートでCLI^☆1の操作を行う機能を持つ．したがって，サーバ上へのソフトウェアのインストールや設定といった操作も，管理サーバ上で実行指示を行うことで，あらかじめ用意した設定ファイルに従って自動的に実行できる．

たとえば，複数のサーバへユーザを追加する業務を想定すると，人間系で作業する場合は対象サーバへ1台ずつログインして一つひとつ操作を行う必要がある．このため，サーバ台数が多くなると，その分作業量が台数に比例して増加する．また，このような定型的な作業の反復は，対象台数が増えるほど，「単調な作業による意識低下」「慣れによる手順の誤り」「錯覚・勘違い」といったヒューマンエラーの発生も懸念される．

これに対し，Ansibleのような構成管理ソフトウェアを利用すると，あらかじめ用意した「ユーザを追加する」という作業内容と「対象サーバの情報」に従って，ソフトウェアが自動的に作業を実行する．設定ファイルに定義した内容を忠実に実行するため，入力ミスや見落としといった作業ミスは発生しない．ワンコマンドで複数台の作業を一度に実行できることから，設定次第では，夜間や休日に無人で作業を実施することも可能となる．

標準的なAnsibleの実行環境は以下のような構成となる．

Ansibleによる自動化業務は次の手順で実行する．

• ①　運用担当者はAnsible管理サーバへログインし，設定ファイルを指定してAnsibleの実行コマンドを入力する．
• ②　コマンドの入力を受けたAnsibleは設定ファイル上の処理を順次実行し，実行結果をAnsible管理サーバ上のコンソールへ返す．
• ③　運用担当者はコンソール上に表示された実行結果を確認し，処理が正常または異常終了したことを判断する．

3.1.2　Ansibleを採用した理由

こうした構成管理ソフトウェアは，AnsibleのほかにもChef [7]やPuppet [8]等，オープンソースで多く公開されている．今回の取り組みでは，以下の3つの観点でそれらのソフトウェアを比較・検討し，Ansibleの採用を決定した．

• ①　エージェントレス

  構成管理ソフトウェアの多くは，管理対象となる業務サーバ上にエージェントと呼ばれるソフトウェアのインストールが必要となる．こうした場合，展開にあたり多数のサーバ上にエージェントをインストールする作業が発生するほか，定期的にバージョンアップを実施する等のエージェント自体の管理・保守が必要となる．

  Ansibleの特徴として，このエージェントが不要であるという点が大きな優位性となった．

• ②　学習コスト

  新たなソフトウェアを導入する際，その学習コストが少なからずネックとなる．一般的に構成管理ソフトウェアの設定ファイル形式はRuby[9]等を使った独自の形式を多く採用しており，利用者は専用の言語および記述方式を学習する必要がある．

  対して，Ansibleは設定ファイルにシンプルなYAML^☆2[10]形式を採用しているため，設定ファイルの可読性が高く，学習コストを低く抑えることが可能であった．

• ③　認知度

  検討にあたり，ソフトウェアの普及状況，将来性についても確認を行った．次図のとおり，Ansibleは2015年にRedHat社が買収したことで注目を集め，検討した当時すでに構成管理ソフトウェアの代名詞ともなっていた．また，認知度の高さに付随して，AnsibleのIT業界での評価の高さ，利用者が多く技術情報が広く公開されている点が採用の後押しとなった．

3.2　自動化の適用

当社では，統合的な運用自動化の適用に向け，「業務選定」「PoC」「適用」という3段階のステップで取り組みを実施した．当社における運用自動化の具体的な流れについて，次に紹介する．

3.2.1　対象業務の選定

当社でははじめに，Ansibleによる自動化の適用へ向け，自動化の対象とする業務の選定を行った．

システム保守・運用業務を担う当社の関連部署内において調査を行い，定型および定例で実施している約230業務を洗い出した．すべての業務を一覧化した後，Ansibleの得意分野を踏まえた実現性，難易度，効果の高さを予測して重み付けを行い，対象とする業務の精査を行った．各観点では，主に以下の条件に合致する業務を優位として予測を行った．

• 実現性　　：CLI操作が中心であること
• 難易度　　：詳細な手順が整備されていること，人間系での判断を必要とせず機械的に処理が可能であること
• 効果の高さ：年間の業務量がより多いもの

中でも実現性と効果の高さについては，取り組みの目標の達成にかかわる重要な要因であると考え，評価点への重み付けを行った．

次表は，実際に業務の選定を行った際に整理した業務選定評価の一部を抜粋したものである．

次に，業務選定評価の結果をもとに，次フェーズであるPoCの対象業務を決めるため，実際にAnsibleを利用した技術検証を実施し，実現性の確認を行うこととした．

重み付けにより選定された上位3業務について，Ansibleの設定ファイルを試作し，検証環境上での自動化を試行した．技術検証を実施したことで，実際にAnsibleを利用して当社のシステム運用業務の一部が自動化可能であることが確認できた．また，検証時に実施したワンサイクル分の時間測定結果から，「サーバ上の情報取得業務」が最も効果が高いと予測されたため，PoCの対象業務として選定された．

3.2.2　PoCの実施

業務選定で選ばれた「サーバ上の情報取得業務」について，一部の本番環境を利用したPoCを実施した．

PoCでは，次フェーズである実運用業務への適用へ向け，次の点について確認と整備を行った．

• ①　自動化による時間削減効果の確認

  実際の業務サーバ複数台に対して自動化した業務を数サイクル実施し，時間の測定を実施した．自動化を適用することにより，業務の前後作業（収集データの集約等）に一部変更が入ったものの，全体として現状の人間系での作業と比較して時間削減効果があることが確認できた．

• ②　運用上のハードル有無の確認

  対象となるシステム運用業務の担当者にAnsibleの利用方法を伝え，実際と同様の運用サイクルを回してもらった．実際の担当者が前後作業も含めて運用業務を試すことにより，実運用業務への適用を行った場合にも運用上のハードルがないことを確認した．

• ③　セキュリティ面の整備

  実運用業務への適用に向け，Ansibleのセキュリティ面の検討を実施した．運用性の向上とセキュリティの堅牢さを可能な限り両立させるため，ほくでんグループ本社の担当者や当社のセキュリティ担当者を交え，取り得る対策を入念に検討した．その結果，Ansible管理サーバを，よりセキュアなセグメントへ移動することとした．そのほかにもアクセス制御や認証，通信プロトコル等の多岐にわたり，ほくでんグループ本社のセキュリティポリシーを順守するように，セキュリティ面の整備を実施した．

セキュリティ面の整備においては後述する課題点が発見されたが，運用面も含め，現時点では実運用業務への適用に向けたクリティカルな課題はないことが確認できた．

3.2.3　実運用業務への適用

PoCにて運用面およびセキュリティ面での課題がなく，時間削減効果が得られる目途が立ったことから，「サーバ上の情報取得業務」について対象サーバ全台（約50台）へのAnsibleによる自動化の適用を進めた．

また，並行して技術検証を実施し，対象業務の拡大も図った．対象業務拡大にあたっては，実際にシステム運用業務を担当する社員が中心となって活動を行った．運用担当者が学習しながらAnsibleの設定ファイルを作成することで，自らの業務を自動化するノウハウを得ることに成功した．

自動化を適用したシステム運用業務には，たとえば以下のようなものが挙げられる．いずれも一つひとつは難易度が低く短時間の作業だが，大量のサーバに対して繰り返し実施する場合に非常に手間のかかる業務である．

• サーバ上の情報取得（コマンドの実行結果取得）
• ファイルの配置
• パッチ適用

自動化の対象業務が追加されたことにより，本番業務サーバ全体へのAnsibleの適用を進めた．Ansibleはエージェントレスのソフトウェアだが，利用にあたっては管理サーバとエージェント間での疎通のため，エージェントとなる業務サーバ側で一部設定変更が必要である．このため，今後のさらなる自動化拡大に向け，約400台の業務サーバへの設定変更を実施した．

3.3　課題事項

Ansibleの導入過程では，さまざまな課題が発生した．代表的なものについて以下に紹介する．

3.3.1　ヒューマンエラー防止の課題

Ansibleを利用して自動化することにより，従来と比較するとヒューマンエラーは削減される．理由としては，人間系での作業が自動化されることにより見落としや操作ミスが減少すること，Ansible管理サーバ上での操作のみとなり業務サーバ上での直接の操作が不要となる点が挙げられる．

しかし，Ansible実行時のコマンド入力には設定ファイルを指定する必要があるため，入力するコマンドが長くなる傾向にある．また，処理の内容に応じて指定する設定ファイルを取り違えないよう注意が必要となる．こうしたことから，Ansible管理サーバ上でのコマンド入力ミスが完全には防げないという課題があった．

3.3.2　セキュリティ面の課題

セキュリティの課題としては，実行権限の制御と実行履歴の保存の2つの課題が存在した．

Ansibleを実行できるユーザは，Ansible管理サーバ上のOSユーザ単位での制御となっていた．このため，対象サーバや実行する処理内容に応じた権限制御はできず，将来的な適用拡大を見据えた際に，細かな権限のコントロールに課題があった．

また，Ansibleの実行はターミナルソフトウェア上からのコマンド実行となるため，誰が・いつ・どんな処理を実行したか，という記録はターミナルソフトウェアのログレベルでしか残すことができない．後から確認できるよう，取り忘れがなく，全利用者間で一元的に参照可能な履歴の管理方法を検討する必要があった．

3.3.3　推進体制の課題

運用担当者の中には，業務の人手不足を解消したいという思いはあっても，新しい技術を導入することには少なからず抵抗を感じるメンバも存在した．これは，人手の足りない中，新技術の教育に充てる時間の捻出が難しいため，直感的に技術導入に対する速やかなメリットを感じづらいためである．

このことから，統合的な自動化の実行環境についてさらなる利便性の向上を目指し，運用担当者により多くのメリットを感じてもらいたいと考えた．具体的には，教育コストを抑える観点でも，直感的に操作が可能で担当者のスキルレベルに左右されないGUIの実行環境の実現を検討した．

また，操作性だけではなく，機能面でも実装したい機能が存在した．自動化された業務の中には，毎日や毎月といった定期実行する業務が存在する．そうした業務を定期的に人間系で実行指示するのは，自動化が不十分であると言える．定期処理については，あらかじめ設定したスケジュールに従って自動実行できるような機能があれば，担当者は出社後に実行結果のみを確認すれば良くなり，自動化による一層のメリットを享受できる．

3.4　改善対応

前述の課題に対して実施した工夫点の内容を以下に示す．

3.4.1　実行基盤環境の整備

Ansible実行環境に関する課題をクリアするため，当社では運用自動化の実行基盤としてAnsibleの統合管理ツールである「AWX」 [12]の構築を検討した．

「AWX」とは，AnsibleをWebブラウザ上からGUIで利用できるオープンソースのソフトウェアである．さらに，API^☆4やジョブの実行制御機能，簡易ワークフロー等も標準機能として提供されている．

前述した課題については，実行環境にAWXを利用することで，それぞれ以下のように解決を図られると想定した．

• ①　ヒューマンエラー防止の課題

  利用者はWebブラウザ上からAWXにログインすると，対象を選択して実行ボタンをクリックするだけで処理が実行できる．この際，サーバの実機へ直接ログインする，コマンドを入力するといった操作は不要であり，簡易な操作でよいためヒューマンエラーの防止に役立つ．

• ②　セキュリティ面の課題

  AWXではログインユーザに対してグループ単位での権限の制御が可能となるため，細かな実行権限の制御が実現できる．さらに，AWX上から実行された処理は自動的に実行履歴が保存され，後から誰が何の処理を実施したか結果も含めて確認できる．

• ③　推進体制の課題

  AWXはブラウザを利用したGUIでの操作のため，あらゆるスキルレベルの担当者が簡単に利用できる．また，ジョブの実行制御機能も提供されているため，複数の処理を順番に実行させる，特定の処理を定期的に自動実行させるといった制御も可能となる．

今回の取り組みでは，次図のようにAWXを構築し，自動化の実行基盤の強化を図った．構築された実行基盤上には，これまでに作成した自動化の設定ファイル一式を移行し，操作性・機能性に問題がないこと，想定どおり課題が解決されることを確認した．

3.4.2　利用手順の整備と周知

環境の整備が完了次第，新たな実行環境を利用するための手順書を作成し，運用担当者への周知を図った．利用手順書はさまざまなスキルレベルの担当者が参照することを考慮し，実際の操作画面のハードコピーを多く含めることを意識して作成した．

手順書を用いて運用の引継ぎを行う際にも，単純に書面を周知するだけではなく，実機の画面操作を交えた学習会も実施した．これにより，運用担当者に具体的な操作イメージを掴んでもらうことに成功し，運用担当部門内での横展開をスムーズに進めることができた．

4．運用自動化の適用効果

4.1　適用結果と考察

当社では，統合的な運用自動化基盤を構築することで，システム運用業務の人手不足解消へ寄与できるものと仮定して今回の取り組みを実施した．結果，目的を達成し，運用自動化による人手不足解消の効果を確認することができた．

図は，2021年度に実際に運用自動化を適用して実施した，3つの業務の時間削減効果を表したものである．いずれの業務についても90%以上の時間削減を達成し，年間で合計約68時間の時間削減を実現した．中でもパッチ適用のような大量サーバへの一括作業を行う業務は，年間を通して繰り返し発生するため成果を上げやすく，類似業務への応用が期待されている．

また，最大の時間削減効果を得たサーバ上の情報取得業務については，実際の業務を担当している運用担当者より「毎月50台ものサーバにログインして実施していた作業がなくなりストレスから解放された」「類似する業務についてはすべて自動化していきたい」という肯定的な意見が寄せられた．この点は，今後のさらなる自動化拡大への意欲を醸成できたものと考える．

今回の取り組みでポイントとして挙げた3点について，具体的に以下の成果があった．

• ①　プラットフォームによるツールの分散の解消

  AnsibleおよびAWXは，クライアント側の環境要件を満たせばプラットフォームを問わず利用が可能なため，実際にWindowsやLinux，仮想や物理といった環境に左右されず活用できている．また，ツールの使い分けが不要となったことにより，全員での利用手順の共有がしやすくなり，課題であった属人化が排除された．このことは，担当者の異動によって自動化が利用できなくなるといったリスクの回避にも繋がる． 現在は，複数のツールに分散している部分最適化された自動化を標準化し，構築した運用自動化基盤へ移行する取り組みを進めている．

• ②　運用担当者のスキル差異の補填

  AWXを利用した実行基盤を整備したことで，ブラウザからのGUI操作が可能となった．AWXはワンクリックで処理を実行するといった直感的な操作が可能なため，自動化の利用のハードルが低くなり，担当者のスキル差異の問題を解消できた．

  統合的な運用自動化基盤の構築後は，AWXの操作方法のみが分かればよいため，学習のコストも低く，自動化の利用は非常にシンプルで便利なものになった．手順が共通化されたことで運用も効率化され，運用業務の時間削減効果もより一層享受することが可能となった．

• ③　運用自動化の適用範囲の拡大

  運用業務の時間削減へ繋がったポイントとして，これまで自動化が成されてこなかった範囲への自動化の適用拡大がある．人間系の作業をシステムに代替させることで単純な処理時間の高速化が図られることに加え，さまざまな対策のための人の張り付きが解消されたことで，実際には削減された時間以上に人手を削減する効果が得られた．

  たとえば，AWXによりWebブラウザ上から処理の実行結果が確認できるようになったため，これまでヒューマンエラー対策のために実施してきた2名以上でのダブルチェック作業が不要となった．さらに，業務サーバへ直接ログインする必要がなくなったため，セキュリティ対策のために実施していたワンタイムパスワード発行作業も不要となった．こうした作業はいかに軽微な作業であっても必須であったため，大量サーバへの処理については特に顕著な効果を発揮した．

システム運用業務の時間削減という定量的な効果が確認できたことで，統合的な運用自動化基盤の構築がシステム運用における人手不足問題の解消に有効であることが分かった．

一方，対象業務に対し90%以上の割合での時間削減が達成できたものの，本取り組みでは期間的に限られた業務への適用しか成し得なかったため，削減時間の合計は1人月に満たない．この点については今後も継続して自動化の適用拡大を進め，成果の拡大を図っていきたい．

5．今後の展望

統合的な運用自動化により，人手不足解消につながる成果を上げられたことから，当社では今後も運用プロセスの標準化と自動化適用範囲の拡大，提供機能の拡充を目指す．当社で検討している具体的な展望の例を以下に述べる．

5.1　ワークフローシステムとの連係による開発担当者への利用拡大

運用自動化の仕組みについて，現状は運用担当者のみが利用しているが，将来的には開発担当者へも利用の裾野を広げ，一層の活用を進めたい．全社で利用するにあたってキーとなる機能が，ワークフロー機能である．

ワークフロー機能と自動化基盤を連係させることにより，開発担当者から運用担当者へ依頼している業務サーバの情報取得処理等を，すべて自動化することが可能となる．具体的には，現在別々の仕組みで実施しているサーバの情報採取とその申請を，ワンストップで実現できるといった活用方法が期待される．

今回導入したAWXでは簡易ワークフローの機能を有しているが，現時点では簡易機能にとどまり，本格的なワークフローの実装は難しいことが判明している．しかし，AWXの特徴としてAPIの提供を行っていることから，他ツールとの連係を柔軟に行えるというメリットがある．

APIを利用して他製品のワークフローツールと連係させることができれば，運用担当者が実施する作業だけではなく，その前後に必要となる作業の調整や申請についても一連の自動化に含めることができる．結果として，開発担当者が依頼元となる業務サーバからのログファイルの採取や設定ファイルの確認等へも運用自動化の適用範囲を拡大可能である．

5.2　サーバ構築業務への自動化適用

システムの運用業務だけでなく同様に定型的な作業であるサーバ構築作業へも自動化基盤の活用を広げたい．具体的には，前述のワークフロー機能と合わせることで，利用部門からの申請に基づきサーバインフラを自動で構築する仕組みを検討している．

現在はExcelで作成した申請書を紙で回覧し，受領したサーバ構築担当者が申請内容に応じてサーバ環境を構築している．ワークフロー機能を利用することでペーパーレス化が図られることに加え，管理者は承認操作を行うだけで申請内容に応じたサーバが自動的に構築可能となる．対象となるプラットフォームの多様化が進んだことで，構築担当者が実施しているサーバ構築の手順は多岐にわたっているが，一度自動化できれば処理は再利用が可能なため，以降は違いを意識する必要がない．

対象とするサーバは，仮想サーバやクラウド上のIaaS等が想定される．現在は物理サーバの導入が減っているため，大半のケースに適用でき有用であると予想できる．

なお，サーバインフラの仮想化，クラウド化に伴い，近年のシステムではリソースのライフサイクルが短くなり，管理対象も膨大に増加している．こうしたリソースを手動で管理することは非効率であるため，自動化基盤を活用することで，新規構築や環境変更，廃止への迅速な対応を可能とし，早期リリースというアジリティの向上にも寄与できるものと考える．

6．まとめと最新事例

本稿では，当社で実施したAnsibleおよびAWXの導入による統合的な運用自動化基盤の構築事例に基づき，システム運用における人手不足解消への有効性について述べた．

当取り組みを通じて得た知見は多い．中でも重要なことは，システム運用の効率化のためには，システム運用担当者の協力が不可欠であり，技術面だけが先行することでは成功し得ないということである．担当者に目的やメリットを示し，いかにして技術を浸透させていくかが鍵となるということが，取り組みを通じた大きな気づきとなった．

当社で導入した運用自動化基盤は2021年度より本格的に運用部門での利用が開始しており，2022年度には約600台の業務サーバに対する大規模な監視ソフトウェアのバージョンアップ作業への活用が開始されている．

このように，その有効性から特に大規模なサーバ台数を対象とした作業への利用要望は多く挙がっており，それに応えるべく，引き続き運用自動化基盤の活用を推進していきたい．

運用自動化の適用を拡大していくことで，今後も当社における一層の課題解決の一助となることに期待するとともに，当社の成功事例が人的リソース不足や自動化の推進に悩みを抱える多くの企業のヒントとなれば幸いである．

最後に，業務多忙のなか当活動にご協力をいただいた皆様，および本稿執筆にあたりご支援をいただいた皆様に対し，この場を借りて心よりお礼を申し上げる．