GitHub Actionsで業務効率化――開発現場以外でも便利なCI/CDの実践例：GMOペパボに学ぶ「CI/CD」活用術（終）（1/2 ページ）

GMOペパボにおける開発現場のCI/CD実践例を紹介する本連載。最終回は、開発現場以外でのCI/CDの応用例を紹介します。

[加治 洵，GMOペパボ]

　本連載第2回までは、主に「ソフトウェア開発の現場」で実施されるCI/CD（継続的インテグレーション／継続的デリバリー）の実践による自動化と効率化や実践内容を紹介しました。しかし、GMOペパボでのCI/CDの活用はソフトウェア開発の現場にとどまりません。第2回でも言及したように、CI/CDの仕組みは自動化による業務の効率化を可能にします。最終回はどのような業務効率化を進めているのか一例を紹介します。

ソフトウェア開発におけるCI/CDが組み込まれるフローとは

　あらためてソフトウェア開発においてCI/CDが組み込まれるフローを分析してみます。詳しい内容は第1回、第2回で言及していますが、抽象度の高い視点で見てみると以下のフロー構造が見えてきます。

1. 変更される対象がプログラマブルな構造を持っている
2. 変更は、その構造に対する差分として見ることができる
3. 変更そのものを検知する仕組みがある

　ソースコードは構造を持っているため、管理対象がソースコードであるうちは、意識せずともgitやGitHubを利用するだけでこれらの特徴を押さえたCI/CDの実現が可能でした。

　裏を返せば、これらの特徴を踏まえた変更のフローを作り上げることで、ソフトウェア開発以外の分野でも、CI/CDを活用できるようになります。

情報システム部門で活用するCI/CD

　ここまでの前提を踏まえ、筆者の所属する情報システム部門でどのような視点を持ちCI/CDの検討を始めたのか、その活用に至るまで紹介します。

申請、承認、適用のフローとソフトウェア開発

　CI/CDを組み込めるようなフロー構造を持つ業務があれば、CI/CDの仕組みを用いて日々の業務を効率化できます。例えば、申請を受け付け、承認を得た上でその申請内容を何らかのシステムに反映するといったような業務フローにはCI/CDの仕組みを組み込める可能性があります。図1にそのフローを示します。

図1　申請→承認→適用のフロー

　ここからは、より具体的な実例を持ってソフトウェア開発以外でのCI/CDの実践を紹介します。

Google Groupsへの追加申請、承認、適用にCI/CDを活用する

　GMOペパボでは、メーリングリストの管理、運用に「Google Groups」を利用しています。Google Groupsは「Google Drive」の共有先などにも利用可能であることから、情報資産のアクセス権管理を目的として、一部のGoogle Groupsの変更には担当部門の承認が必要という運用をしています。CI/CDの仕組みを組み込む前の運用では、下記のような運用をしていました。

図2 CI/CDの仕組みを組み込む前のGoogle Groups運用フロー

　この運用フローでは申請者、承認者、作業者の3人が関わります。そして、反映作業は手作業でした。そのため複雑な申請内容や大量の変更が必要な場合は作業時間が長くなります。作業者が増えたり減ったりした場合には、フローの引き継ぎも必要になります。

　この旧来の運用フローでCI/CDを活用するためには課題がありそうです。それを抽出するために、まずはこの運用がされる背景を分析してみましょう。

　まず申請者は、Google Groupsに変更を加えたい動機があります。また、Google Groupsはメーリングリストとして機能するだけでなく、Google Driveへのアクセス権の付与にも使用できます。つまり、情報資産へのアクセスをコントロールするために、管理者による承認・否認の機会と仕組みが必要になります。

　では、作業者はどうでしょうか。このフローの中で、申請者と承認者は何らかの判断をしています。しかし、作業者はただ作業をしているに過ぎません。組織が小さく、申請の件数も少ないうちは問題になりませんが、組織が成長するにつれてこのような申請の件数は増え、作業者の負担が増えます。組織の成長が進むと、このような作業をこなすための人材を雇用する必要も出てきます。

　分析した結果を基に、このフローが抱える課題を抽出してみます。1つ目の課題は、このフローの最初の申請は構造的に解釈ができない点です。申請書がたとえ電子化されていたとしても、申請書がプログラマブルな構造を持たない限り、CI/CDを始めとした自動化を実現するフローに組み込めません。

　2つ目の課題は、作業者が手作業をしているという点です。CI/CDのような自動化を提供する仕組みが組み込まれていないため、変更の量がそのまま作業量に反映され、組織のスケールアップに弱い構造をしています。

　3つ目の課題は、この作業の質にゆらぎが生じ得るという点です。Google Groupsへのメンバー追加程度の作業なら、質の差は対応までの時間の差ぐらいのもので済むものの、やはり組織のスケールアップに応じてその差は無視できないほどのものになります。