■ 発表カテゴリ

• Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）

弊社ではInfrastructure as Code（IaC）を活用しており、仮想サーバで構築・運用しているサービスに対してはAnsibleを用いてセットアップ（インストール）、運用保守（アプリ更新や設定変更）を行っています。
しかし、組織として改善は多く試みたものの理想には到達せず、Ansibleは塩漬け状態に陥っていました。触ることができるメンバーが限られ、文化の浸透が進まないことによる心理的ハードルが高い状況となっていました。

そこで今回は、Ansibleの課題に焦点を当て、CI/CDパイプラインの改善を通じて開発者体験と品質向上を実現したプロセス改善を紹介します。
具体的には、CTOとチームでPath to Productionを議論し、パイプライン戦略を決定したこと、有識者からのレビューを元に更新した取り組みをお話しします。
CI/CDパイプライン整備することで開発者体験の向上と品質改善が向上され、クラウド移行プロジェクトでの恩恵もありました。

IaCのCI/CD周りに課題感を持っている方に改善事例や取り組みのポイントを持ち帰っていただけると幸いです。

■ 発表の詳細（1000字程度）

Ansible CI/CDパイプラインのプロセス改善をどのように進めていったのかを中心に話し、組織やプロダクトにどのような影響を与えたのかを話します。

1: 長年塩漬けされたAnsibleの歴史と課題（課題発見、原因分析）

組織として過去に何度かAnsibleをはじめとした構成管理ツールを導入しましたが、運用に対して向き合うことができず、何度も塩漬けされることになりました。
こういった状況からメンテナンスもされておら開発者体験や品質が悪く、開発難易度も上がっていました。（テスト、CI/CDがない）
上記のような課題を抱える状況ではプロダクト開発・運用に悪い影響を与えてしまうため課題解消が必要でした。

2: 課題を解消するための解決方法（取り組んだこと）

CI/CDパイプラインの改善は簡単にキックオフ→あるべき姿を考える→フェーズ分割→実装→レビュー会という流れで進めました。
とくに解決に向けて良かった点が3点あります。

a: Path to ProductionをCTOのたたき台をもとにチームとCTOで考えることができたこと（効率的な進め方とフェーズ分け）

IaCのあるべき姿について、たたき台を作ってもらい共有の機会をもらいました。
チームとしては先行して必要になるであろうOffline Testsの整備を先に進めていたので解像度がすこし上がっている状態でした。
その上で過去運用ができていなかった点も実際の体験から議題に上げ、考慮するべき点を洗い出し、あるべき姿を全員で議論して作ることができました。

b: 見積もり結果を元に、まずは最小の独立したシナリオ（複数プレイブック）での実現を目指すことにした

初期見積もり時点では複数のシナリオに対してあるべき姿を適用しようとしました。
ですが長年運用しているサービスのため、シナリオ数も多くすべて適用しようとするとクラウド移行プロジェクトをはじめとして中長期のロードマップに影響が出てしまいます。
議論した結果、CI/CDパイプラインを最小の独立したシナリオ（複数プレイブック）で動かすことをまずは目指すことにしました。
最小の独立したシナリオを構築することで、他シナリオの展開もスムーズに行うことができ、クラウド移行プロジェクトにおいても円滑に進めることができるという判断です。

c: 第三者のレビュー・フィードバック会を途中で行い、あるべき姿の更新ができたこと（より品質の向上へ）

当初考えていた理想のパイプラインを独立したシナリオ（複数プレイブック）でほぼほぼ動かせる見通しが経ったタイミングで実施をしました。
パブリッククラウドサービスでSolution Architectを担当している方、社内でAnsibleを積極的に利用しているSREチームのエンジニアに見てもらいました。
その結果、Stack Tests周りでの提案をもらい、1日で実装を行い品質向上に繋げることができました。

3: 開発プロセスや組織に対する影響（取り組んだ結果や効果、今後の展望）

IaCにおいてもCI/CDを当たり前の状態に持っていくことで、セットアップ（インストール）、運用保守（アプリ更新や設定変更）においての開発者体験の向上や品質の向上を行うことができました。
また、運用ができていなかった塩漬け状態からあるべき姿を徹底的に考えることで、社内システムや運用状況に合わせたCI/CDパイプラインを構築することができました。
改善する土台を作ることができたので、品質向上においてまだまだ取り組むべきことや他プロダクトの展開を行っていきます。

4: まとめ（結論）

昔から存在しているサービスはオンプレミスでの運用が続いており、長年問題を抱えていたIaC（Ansible）の課題に向き合いました。
課題を解決するために、パイプライン戦略についてあるべき姿を議論したり、有識者のレビュー・フィードバックを得て、開発者体験の向上・品質の向上ができるCI/CDパイプラインを作ることができました。
CI/CDパイプラインを作ることで、クラウド移行プロジェクトにおける仮想サーバのセットアップを早め、運用保守を行いやすい体制を整えられるという恩恵を受けることができました。

■ 対象聴衆とその人たちが得られるもの

• 対象聴衆
  • IaCにおけるCI/CDパイプライン戦略に興味がある、課題感を持っている、実際に改善に取り組んでいる方
  • Ansibleを利用しているエンジニア
• 得られるもの
  • どのような課題があって、実際に取り組みを行ったのか、実践的な改善事例を知ることができる
  • IaCにおけるCI/CDパイプライン戦略の考え方、CI/CDパイプライン構築の進め方

■ なぜこのトピックについて話したいのか（モチベーション）

長年塩漬け状態にあったAnsibleの運用から脱却し、あるべき姿のCI/CDパイプラインを議論・構築することで、IaCでの開発者体験と品質を向上させることができました。
AnsibleのCI/CDパイプラインの事例が少ない中、最小の独立したシナリオ（複数プレイブック）にて、あるべき姿を約1か月半という短い期間で構築することができ、現在進めているクラウド移行プロジェクトにおいても活用することができています。
短い期間ではあるものの内容として濃い期間を過ごすことができ、学びも多かったので、他の組織やチームの参考となるように事例を共有したいと考えています。また、IaCにおけるCI/CDパイプライン戦略についてどうあるべきかも議論してみたいです。