SIerの俺が5年ぶりにAnsibleを使う案件に入って思ったこと

はじめに：5年ぶりにAnsible現場に戻ってきた話

2025年のいま、久しぶりに「Ansibleを使用する案件」に入ることになりました。

本記事では、SIerとしてオンプレ案件に戻ってきた立場から、「オンプレでAnsibleを使うことの難しさ」「現場で見えた自動化の限界と可能性」「過去の資産に救われた話」あたりを、あくまで一現場の事例としてゆるめに書いてみようと思います。

5年前のAnsible案件と、その後クラウド中心になった経緯

最初に、5年前に関わっていたAnsible案件の話を少しだけしておきます。

当時は、プライベートクラウド（IaaS）上で払い出したVM群に対して、Ansibleでシステム全体の構築を行うプロジェクトでした。弊社としては比較的珍しく、構築だけでなくその後の運用フェーズも自社で対応する前提だったため、「継続運用されること」を見据えたPlaybookを作ることが求められていました。

その案件では、サーバの初期構築や運用時の設定変更をできるだけAnsibleに寄せる方針を取っていました。いわゆる「構築だけ自動化」ではなく、「運用で使い続けられる自動化」を意識していた時期です。

その案件の終了後はパブリッククラウド案件を中心に対応していました。IaCのメインは CloudFormation や Terraform といったツールになっていき、構成管理系の自動化はプロダクトやマネージドサービス側で担われる部分も増え、日常的にAnsibleを触る機会はかなり減っていきました。

そんなこんなで「Ansibleは分かるけど、直近では触っていない」という状態でしばらく過ごしていたところに、今回のオンプレ更改案件でのアサイン、という流れになります。

オンプレAnsibleはやっぱりむずい

今回の案件は、現行システムありのオンプレ更改案件で、「Ansibleを使って構築する」ことが前提に据えられているプロジェクトでした。単に構築時のツールとしてAnsibleを利用する以外にも、Ansible による環境再構築がリストア手順の前提になっているなど、単なる補助ツールではなく、要件の一部として位置づけられるような形です。

よって、納品完了時点で「正しいPlaybookが成果物として残っていること」自体が重要なゴールになります。運用フェーズに入ってから頻繁に実行されるわけではないものの、構築・リストアの前提としてきちんと存在している必要があります。

そのうえで、久しぶりにオンプレ案件でAnsibleを触ってみて、改めて感じたのは「オンプレAnsibleはやっぱりむずい」ということでした。

クラウド案件と比べて特にしんどいと感じたポイントは、次のようなところです。

• 本番環境をイミュータブル前提にできない
• プロジェクトが進むほどPlaybookを変えたり、実行したりする心理的ハードルが上がる
• 手作業が混ざりやすく、コードと現物の乖離リスクが高い
• Ansibleを動作確認できる環境が本番環境と違い過ぎる

クラウド環境であれば、「サーバを作り直す」「別の環境を立て直して切り替える」といった選択肢を取りやすく、失敗した時も「もう一度Applyし直そう」「新しいスタックを作り直そう」でやり直しが効く場面があります。もちろんクラウドでも本番は慎重にやる必要がありますが、それでもオンプレと比べるとリカバリのパターンは豊富です。

一方オンプレだと、本番環境のサーバを簡単には作り直せないケースも多く、「"今の"この環境に対してAnsibleをどう当てるか」を慎重に検討する必要があります。段階的に手作業が入り込んだり、途中で例外対応が走ったりすると、前提が崩れ、Playbook実行時の整合性を保つのが難しくなっていきます。

イレギュラーな状況に対応してIaCを修正はするものの、実機を初期状態から構築しなおすことは到底できないため、「理論的には正しいはずだが、本当にそのPlaybookが正しく動作するか」は厳密には保証できない状況に陥りがちです。

また検証環境についても、「本番環境と全く同じ構成を用意できない」「検証環境のリソースが限られている」といった事情があり、本番環境で実行するPlaybookをそのまま動かせないケースも多々ありました。結果として、「検証環境で動いているから本番でも大丈夫」という保証が薄くなり、より慎重に進めざるを得ない状況になります。

特殊なソフトウェアの自動化がつらい

ここに追い打ちをかけてくるのが、「インストールに特殊な手順が必要なソフトウェア」の存在です。
特定ベンダが提供しているプロダクトは、そもそも自動化でのインストールをあまり想定していないような仕組みや手順書になっていることも少なくありません。

今回の案件でも、インストール手順書を読み込みながら shell モジュールを駆使してインストール用のRoleを作っていく、というかなり泥臭い作業が発生しました。「ここはこの順番で実行しないといけない」など、人間がその場で判断することを前提にした手順を、ひとつひとつコードに落としていく必要があります。

製品側がAnsible Roleを提供するようなケースもありますが、今回のPJでは「存在はしているものの、実装が古くて動かない」というパターンがありました。今回導入したAnsibleのバージョンではそのRoleがそのままでは動かず、結果として過去に作られたRoleを読み解いたものの、リスク回避のために手作業でインストールする判断となりました。せっかく用意されている自動化用の資産も、メンテナンスされていなければむしろ足かせになり得る、ということを痛感しました。

SIerの立場としてはこうした「自動化前提で設計されていないプロダクト」と向き合う機会も多く、そこも含めて自動化の難易度を押し上げていると感じます。

「構築だけ自動化」止まりの現場が抱えるモヤモヤ

もうひとつ強く感じたのが、「構築だけ自動化」で止まってしまっている現場特有のモヤモヤです。

個々の作業レベルでは、AnsibleやIaCを使って構築を効率化しているのですが、システムのライフサイクル全体で見ると、自動化されているのはそのごく一部に過ぎません。さらに、現行対応時のPlaybookがそのまま流用できないケースや、そもそもAnsibleの資産自体が残っていない・参照されていないケースもあり、結果的に手動作業に頼らざるを得ない場面が多くなってしまいます。

今回の案件でも、

• 現行システム向けのPlaybookがそのまま新システムに使えない
• 一部の領域ではそもそもAnsibleの資産が存在しない
• そのため、新たに実装をするか、手動作業を採用せざるを得ない箇所が出てくる

といった状況が見えてきました。

背景として大きいのは、「受託開発メインで、運用フェーズまで面倒を見ない案件が多い」というビジネスモデルや、「システムとして塩漬け前提で、更改までほとんど触らない」という文化です。スコープとして「構築まで」「更改まで」がゴールに設定されていると、その先の運用や次回更改までを見据えた自動化投資がどうしても正当化しづらくなります。

システムのライフサイクル全体で見れば、構築〜運用〜更改までを通してもっとちゃんと自動化したほうが、長期的には効率が良いのは間違いありません。ただ、契約や体制、予算の切り方としては「構築だけしてバイバイ」というスコープになりがちで、そのスコープの切り方自体が自動化の投資対効果を下げてしまっているようにも感じました。

個人的には、

• 「構築だけ自動化」でも一定の価値はある
• ただし、その前提に甘えてしまうと、いつまで経っても運用や更改のたびに同じ苦労を繰り返す

という二面性があるように思っています。今回の案件は、そのジレンマをかなりはっきりと見せてくれた事例でした。

Ansibleを扱える人が少ない現実と、その影響

もう一つの大きなポイントは、「Ansibleを実務レベルで扱える人が思った以上に少ない」という現実です。

今回のプロジェクトでは、Ansible経験者は自分ぐらいで、他のメンバはほとんど未経験か、見たことがあるレベルという状況でした。その結果、自動化周りの設計やPlaybookの実装・修正は、どうしても自分に集中する形になりました。

もちろん、メンバの素養的には「時間と余裕さえあれば、普通にキャッチアップできたはず」と感じる人は多かったです。ただ、実際のプロジェクトでは、

• タイトなスケジュールの中で、学習コストを捻出しにくい
• 「新しいツールを覚える」ことに対して、時間やコストの余裕が見込まれていない

といった事情があり、「学んでもらうべき」「学びたい」という気持ちと、「いまそれをやる余裕がない」という現実のギャップがありました。
立場上はメンバの育成も考える必要があるため悩ましいところでしたが、結局は他の領域での成長を優先しようと判断し、今回のPJではAnsible周りは自分が属人的に対応しました。

もし誰かが過去5年のどこかでもっとAnsibleを触っていたら、いまのプロジェクトの体制や負荷分散はかなり違ったはずです。今考えると、今回私がやったような判断を積み重ねた結果として属人化してしまっているのかな、とも思います（反省）。

自動化に関する社内研修はある程度用意されているものの、どうしても「入門編」「ハンズオンで一通り動かしてみる」レベルに留まりがちで、それを「現場の実案件での活用」にブリッジする場や時間が不足しているのかな、という印象も持ちました。

これはAnsibleに限らず、どの技術にも起こり得る話ですが、「5年ぶりに戻ってきたら、技術ではなく人の側がボトルネックになっていた」というのは、今回特に強く感じた部分でした。

それでも光った既存Roleと変数ファイル生成の仕組み

ここまで割と課題寄りの話が多かったのですが、今回の案件で「これは良いな」と感じた仕組みもあります。それが、現行対応時に作られていたRoleと、Excelのパラメータシートに紐づく変数ファイル生成の仕組みです。

まずRoleの作りとしては、基本的に

• ファイルを所定の場所にコピーする
• 必要に応じてサービス／サーバを再起動する

といった処理を、変数で制御するシンプルなスタイルになっていました。やろうと思えばもっと凝った処理を入れることもできますが、あえて「ファイル配布＋再起動」を軸に、分かりやすい責務の単位でまとめてあったのが印象的でした。

これに加えて、Excelのパラメータシートと、その中に仕込まれたマクロによる「変数ファイル生成」の仕組みが用意されていました。パラメータシートに各サーバ・各設定の値を記入しておき、マクロを実行することで、Ansibleの変数ファイル（YAML）および実際の設定ファイルが機械的に生成されるようになっていました。

この構成のおかげで、

• パラメータシートの内容を、そのまま機械的にAnsibleの実装に反映できる
• 人が手でYAMLを書き換える余地を減らせる
• Excel文化が根強い現場でも、既存フローや成果物をあまり壊さずにAnsibleと接続できる

というメリットが得られていました。

今回の更改案件では、この仕組みを新システム向けに流用しつつ、一部を改修する形で対応しました。構造がシンプルであったため、流用や改修自体はそこまで苦労せずに進められました。「Ansible側の修正よりも、Excelマクロを読み解いて直す方が難しい」と感じるレベルでした。

運用フェーズでAnsibleを継続的に使わない前提の案件であれば、こういった

• シンプルで汎用的なRole
• Excelパラメータシートからの変数ファイル生成

という組み合わせは、むしろかなり「現実解」としてバランスが良いのではないか、と思いました。「Ansibleを主役に据える」というより、「既存のパラメータ管理の延長線上にAnsibleがいる」くらいの距離感で設計されているのが、今回の案件ではうまくハマっていたように感じます。

今回の案件から学んだこと・これからやりたいこと

最後に、今回の案件を通じて感じたことと、今後似たようなプロジェクトに関わるなら意識したいことをまとめておきます。

1. 汎用的なPlaybookの価値

今回のような、更改案件や類似案件にPlaybookを転用できる可能性は、受託開発メインのビジネスモデルでは特に価値があると感じました。案件ごとにガチガチに特化したPlaybookを作り込むよりも、

• ある程度シンプルで汎用的
• 流用と改修がしやすい

といった性質を持つPlaybookやRoleの方が、長期的には社内資産として価値が高くなる場面も多いのではないかと思います。今回のRole＋Excelマクロの仕組みは、まさにその一例でした。

2. スコープにあわせた自動化の前提を意識する

クラウド案件のノリで「イミュータブルにしよう」「失敗したら作り直せばいいでしょ」と考えてしまうと、オンプレではどうしてもつらくなります。最初から、

• 構築時点だけAnsibleを使う前提なのか
• 運用フェーズでも継続的に使う前提なのか
• どこまでをAnsibleで自動化し、どこから先は割り切るのか

といった期待値を現実的な範囲で合わせておくことで、後から「思っていたのと違う…」となるのを防げる部分は多いはずです。

3. スキルトランスファーと組織としての継続性

短期のプロジェクトスケジュールだけを見れば、「いまAnsibleを学ぶ時間はないから、経験者がやった方が早い」という判断は合理的です。ただ、長期スパンで見た時に、「実案件レベルでAnsibleを扱える人」をどれだけ増やせているかは、その組織にとって大きな差になります。

社内には入門向けの研修やハンズオンはあっても、そこから一歩進んだ「現場で実際に使うための橋渡し」が弱いと、どうしても一部の人に負荷が集中しがちです。

ここは、たとえば「自動化・IaC専門チーム」のようなユニットを用意し、各案件に横断的に関わる形にするのも、解決策の一つかもしれません。

さいごに

5年ぶりにAnsible案件に戻ってきてみて、改めて思ったのは、「ツールそのものの良し悪し」ではなく、「どんな前提と文化の現場で使われるか」で体験が大きく変わる、ということでした。

みなさんの現場では、AnsibleやIaCはどんな前提と文化の中で使われていますか？
「自動化」と「現場のリアル」の折り合いの付け方は、それぞれの現場の数だけあるはずです。

この記事が、どこかの似たような案件で自動化を扱うとき、ふと頭の片隅に浮かぶくらいのヒントになっていればうれしいです。