はじめに
1つの本番インスタンスを運用するとき、複数の非本番インスタンスを利用するのが一般的です。この非本番インスタンス、どのように使うのかが良いやり方なのか、ということについて考えてみたいと思います。
現場のエンジニアだとなかなか自分でどうにかできる話題ではないかも知れませんが、理屈を理解しておくのは有益ではないかと思います。1回ではとても書ききれない話題になりそうなので、まずは一番重要なテーマ。テスト環境はいくつあるべきなのか、について。
結論
結論から言うと、ほとんど全ての場合において、システムを使って業務を行うチーム（要するに利用者）が受け入れテストをする環境と、システムを提供するチーム（要するに開発チーム）がテストをする環境の2つを、別々に用意すべきです。それらを1つで済ませようとするのは開発プロセスの困難を招きます。
理由と例外的状況についてはこれから述べます。
非本番インスタンス使い分けの検討
開発プロセスの利害関係者
つまるところ、非本番インスタンスの使い分けというのは、どういう利用目的があり、目的のどれとどれが相互に相容れないのかという話になります。そして、目的の相容れなさを生む最大の原因は、立場の違う利害関係者がいると言うことです。立場が違う利害関係者が同時に何かをしたいと言うことになると、インスタンスはそれぞれに用意せざるを得ないと言うことです。
と言うわけで、利害関係者の検討を始めるのですが、ServiceNow導入プロジェクトの場合、適用対象業務が何であるか、開発プロセスに何を採用するかにかかわらず、この人がいないとちょっとまずいという必須の登場人物が3人います。
もう少し具体的に書きますと、プロセスオーナーはプロダクトオーナーの最重要の顧客として、そのシステムの利用者を率いる人と言えます。プロダクトオーナーは配下にエンジニアのチームを持っていて、システムの仕様を決定し、システムを責任を持って提供する人です。プラットフォームオーナーはServiceNowプラットフォームの管理責任者としてプロダクトオーナーが安心してシステムを提供できる基盤を提供する人です。
プラットフォームオーナーはシングルプラットフォームを標榜するServiceNowに特有の役割ですが、残りの2つは業務用のシステムであればどんなところにも居る非常に一般的な役割です。
これらの責任ある立場の人をそれぞれ、明確に1人の人物に特定できず、たくさんの人が登場してしまう場合、システム管理の粒度が適切でない可能性があります。またこれは余談ですが「プロダクトオーナーはITベンダーであり当社にはいません」という答えがサラっと出てくるとしたらそれはコーポレートガバナンスの異常事態です。さらにひどい状態として「業務は外注しているのでプロセスオーナーは当社にいません」という主張を何の疑問も持たずにできてしまうようになると、それは事勿れ主義ここに極まれりという状態で、会社として末期状態です1。
利害関係者とテストの種類
話がそれましたが、上記3つの担当者は開発プロセスのいろんな局面でそれぞれの役割を担うことになります。今回は非本番インスタンスの使い分けがテーマなので、インスタンスの利用者が最も多くなるテストという営みについて考えます。この3人のテストに対する責任は大きく以下のように整理できます。
- プロダクトオーナーはシステムを提供する前に自分たちが正しくシステムを実装できたのかどうか、テストによって確認しなければならない。
- プロセスオーナーはシステムを受領したあと本番業務を行う前に自分たちが実施しなければならない業務プロセスをシステムが正しく支えられているかどうか、テストによって確認しなければならない。
- プラットフォームオーナーは上記2つのテストが混乱せずに実施されるように環境を提供しなければならない。
つまり、プロダクトオーナーとプロセスオーナーは相互に目的が違うテストをする責任があります。
テスト環境の使い分け
この2つのテストがある以上、ServiceNowのテストインスタンスも、プロダクトオーナー側に属するテスト環境と、プロセスオーナー側に属する受け入れテスト環境の2種類が必要になります。
もし2つのテストを隔離した環境で実施できないとすると「いま誰がテストしているのか」「いまあるデータは誰のものか」「どのような目的のテストをしているのか」と言うことを綿密に調整して、必要に応じて切り替える必要があります。これは上の3つの立場全ての人にとって大変な負担になりますし、管理を誤るとテストが大混乱に陥ってしまいます。
よくある例としては、プロダクトオーナー側で確認が終わっていなくて、まだ引き渡していない新機能がある状態のインスタンスにプロセスオーナー側が触ってしまい、言われているのと違う機能が動いている状態（動いていたらまだいい方です）になって困惑するとか、プロセスオーナー側が綿密に準備したテストデータをプロダクトオーナー側が触ってしまって壊してしまうとか、そういうトラブルが発生しやすくなります。単一のテスト環境をプロダクトオーナーとプロセスオーナーで相乗りしてテストする運用はチームの生産性をかなり下げることを覚悟しないといけません。
例外的状況
もしテスト環境が1つで十分であるケースがあるとしたら、考えられる理由は2つあります。
ひとつめは、プロダクトオーナーとプロセスオーナーが同じ人（そうでなくても、同じ立場の人）であるという状態です。自分たちの業務プロセスを支えるシステムを自分で提供している状態です。この時は上の2つのテストを厳密に分けなくても良いという判断もできます。ServiceNowの製品でいえば、IT Service Management（ITSM）のテストにおいてはこういう状態になりえます。ITSMの場合、プロセスオーナーもプロダクトオーナーも同じIT部門になりうるためです。
もうひとつは、一番初めの導入プロジェクト期間中（つまり、その時点では本番環境が稼働していない状況）で、本番環境をどちらかのテストに流用しているケースです。例えば、プロダクトオーナー側のテストを本番環境で実施して、プロセスオーナー側の受け入れテストは独立のテスト環境で行い、本稼働時にテストデータを全部消して、本番データに入れ替えてサービス開始という、いわゆる「本番昇格」をやるケースです。ただ、これはセキュリティのリスクがあって最近は避けられがちですし2、とりわけServiceNowにおいてはちょっと難しいところがあってあまりおすすめできないです3。サービス開始したら次の瞬間からどうせプロダクトオーナー用のテスト環境が別途必要になるので節約にもならないと思います。このケースはもともと持続可能な運営ではないということです。
テスト環境の呼び分け
どうでもいい話なのですが、テスト環境を二つ作ったとして、何という名前にするか。
プロダクトオーナーのテスト環境は通常単純にテスト環境と呼ばれることが多いようです。一方でプロセスオーナーのテスト環境は、受け入れテスト環境（UAT環境） と呼ばれたり、システムテスト環境（ST環境） と呼ばれたり、ステージング環境と呼ばれたり、リグレッションテスト環境（リグレ環境） と呼ばれたりします。この概念自体はServiceNowに固有のものではなく、古来から日本の情報システムの現場にはあるものなので、慣れた名称を使えば良いと思います。わたしは個人的には「受け入れテスト環境（UAT環境）」が好きですが、それは上のような利害関係者の責任範疇による分類が最もよく現れた名前だと思われるためです。
まとめ
結論は最初に述べた通りで身も蓋もありません。円滑なテストをして持続可能な開発体制を維持するためにはプロダクトオーナー用のテスト環境と、プロセスオーナー用の受け入れテスト環境は分けて持ちましょうということになります。
この話を2023年11月にとあるイベントで話したところ、実際はここの分割が進んでいないケースがかなりあるように感じました。分けるべき理由は明快なので、今後の非本番インスタンス運営の役に立つといいなと思っております。
-
ここまでの状態はまずないんですが（ゼロとは言わない）、一歩手前の状態として、「プロダクトオーナーもプロセスオーナーも社長です」と言い切ってしまうケースはときどき見かけます。そうなると、私たちみたいな外からご支援するコンサルタントは、それを仰った方との打ち合わせをやめて、社長との会議を直接やらないといけなくなります。 ↩ ↩
-
消されなかった認証情報が不正アクセスに使われる恐れがあります。なんといってもテスト担当者はそのアカウントを知っているのですから。 ↩ ↩
-
良くも悪くもServiceNowは全ての情報をテーブル上のレコードで管理するシステムなので、業務データと開発資源の切り分けが簡単にはできないことが理由です。テストに使った環境からテスト用の情報を消して本番の情報に差し替える作業手順を考えるときに、消すべき情報と残すべき情報の線引きが簡単にはできません。ではzBoot（インスタンスの初期化）すればいいかというと、これはこれでまた他の環境との整合性に問題が起こることがあり、採用しづらいです。その件はまた別の機会に。 ↩