ノーコード・ローコードにおいてどのようにバージョン管理を行うか

ソースコードを書く開発ではバージョン管理にGitツールを使うのが一般的ですが、ノーコード・ローコードプラットフォームではではどのようにすべきでしょう？最近ここについて考えているので、現時点での考えをシェアします。

製品によって違いはあると思いますが、この記事では私が普段扱っているServiceNowを前提とします。

ノーコード・ローコードではコードに対応するものがない

名前の通りなのですが、ノーコード・ローコードではソースコードに対応するものがなく、環境に直接設定変更を行います。

その上、（ServiceNowでは）一部バージョン管理されるものもありますが、マージなどの概念はなく、上書きされてしまいます。バージョン管理されないものについては、最終更新断面しか見ることができません。

とはいえ、直接環境を変更した上で、何のドキュメントも残さない場合、誰がいつ何を変更したか、というのを追うのが難しくなります。その結果、変更に対する影響調査などが困難になる可能性があります。

王道アプローチは設計書・仕様書を残す

私の職場でも行っている、おそらく王道アプローチは、ノーコード・ローコードにおける開発物である設定値を、設計書・仕様書としてExcelファイルなどに残す方法です。別の記事でも書きましたが、設定画面をそのままExcelに起こしたような設計書・仕様書を起こすことはあまり意味があるとは言えませんが、少なくとも変更のたびに更新をしておけば、どのタイミングで、何が変わったかは追うことができます。

しかし、元々GUI画面で設定を行うノーコード・ローコードの値を無理やり文書化しようとすると、Excelであれば可読性は上がるがGitツールなどでは差分を見るのが難しいですし、YAMLやJSON形式でテキスト化すると可読性が落ちます。

また、ノーコード・ローコードでは、仮に設計書や仕様書を残したとしても、結局設定画面を見た方が早い場合が多く、設計書・仕様書は手間がかかる割にあまり使われない資料、となることが多いです。

このように、設計書・仕様書を残す方法は、王道ですが、ノーコード・ローコードの性質を考慮した最善のやり方ではないように思います。

代替案

そこで、検討中のよりノーコード・ローコードに合った方法を紹介します。どれか1案で代用することも、組み合わせることも可能だと考えています。

設計書ではなく変更履歴のみを残す

まず個人的に有効ではないかと考えているのが、変更履歴を残すという考え方です。これは、何のために何を追加/変更したか、という変更履歴だけを残して置き、細かい設定項目は実際の環境を見る、というやり方です。

上述したように、仮に細かい設定値をコピーして作った設計書・仕様書があっても、実際に見るのは環境です。そのため、あくまで変更対象と簡単な変更内容、そして変更理由のみを管理しておくことで、少ない手間で将来の影響調査などに役立つ情報を残すことができます。

リリース時に変更内容をレビューする

ServiceNowにおいては、環境に行われた変更は開発環境から本番環境にリリースする際に、変更一つ一つを細かく確認することができます。有識者が内容をレビューすることで、どんな変更が入るのかを確認することができます。

自動テストを定期的に回しテストが失敗するレベルの変更は検知できるようにする

ServiceNowでは、テスト自動化機能があります。これを活用し、自動テストを作成し、日次などで回しておけば、既存機能に影響があるような変更が入った場合には、気づけるようになります。

おわりに

皆さんの現場ではどのようにやっていますか？何かいい方法があれば教えていただきたいです。また、上記検討中ですので、私の職場で運用を確立できたらまたシェアしたいと思います。