【ガバクラ移行】基幹業務システムの切替プロジェクトの「テスト」は想像の32倍くらい大変
写真は福岡県糸島の牡蠣小屋で去年食べた牡蠣。記事の内容とは一切関係ありません。
まず初めに、「32倍」というのはなんとなくの数字ではなく、「想像の2倍」が少なくとも5つ登場するから、
2の5乗でイコール32ってことです。あくまで自論ですが。
経験済みの人には十分わかっていることだと思うんですが、今使っているシステムから新しいやつに切り替えようってプロジェクトでは
その新しいシステムの品質が十分なもの、つまり切り替える目的を達成できるものになっているかを確かめる工程、「テスト」が必ず存在しますし、プロジェクト全体の工数（所要時間）のうち3〜4割、いやもしかしたら半分くらいはこのテストに使われます。
それくらい重要な工程だし、人手と時間がかかる難しい工程だということが大前提です。
そして、ガバクラ移行で扱うような基幹業務システムの切り替えとなると、その大変さがブチ上がります。
今回は、ぼくが考えるその「大変さをブチ上げる理由」を挙げて、2024年が始まったばかりの現在日本各地でこういうことに苦労しながら必死で新しい業務とシステムを追求している人たちがいることをわかってもらえたらいいなと思います。
（尤も、ぼく自身はそれらの「中の人」ではないので、もしかしたら多少の現場との相違はあるかもしれませんが）
改めて投稿の意図を伝えておくと、ガバクラ移行の中の人でもなんでもないぼくがこういう話をnoteに書くのは、
今現在、日本全国の自治体では中々無謀とも言えてしまうようなくらい困難なITプロジェクトに取り組んでおり、これらの成否が、「日本はIT後進国だよなぁ」という世間のムードを跳ね除けるか肯定するかの重要な根拠になると思うからです。
だから一人でも多くの人が、「中の人がんばれ！」と思えるようになればいいなという勝手なお節介です。
大変な理由その１：機能領域ごとの進捗や品質の差
「基幹業務システム」となると、その機能領域はめっちゃ多岐に渡ります。人事給与システムを例にすると、大きく分けても
発令情報管理、社員別個人情報の管理、各種情報の申請/承認、給与計算のためのデータ管理、給与計算、人事評価、組織情報管理、組織間の諸情報照会、…いくらでも挙がりそう。
そしてガバクラ移行のプロジェクトで扱っているシステムは以前の投稿でも触れたように20の業務領域、しかもそれらが相互にデータを共有して成り立つものになります。
で、そうなってくると当然、各機能領域を複数のチーム、場合によっては会社すら異なることもあるチームで分担して作っていくことになります。機能Aはaチーム、機能Bはbチーム、CとDはxチーム、、、とか。
するとこれもまた当然、領域つまりチームによっていろんな違いが生じてきます。それこそチームの雰囲気やメンバーのスキルや特性の違いに始まり、これらがゆくゆくは「進捗状況」や「成果物の品質」の違いとなって現れてくることになります。
aチームはスケジュール通りに成果物を仕上げているみたいだけど、どうもドキュメント類が粗いし、リーダーが出来をチェックしているか怪しい。。。
bチームはいつも「数日予定より遅れています」とはいうものの、関係者を十分巻き込んでドキュメントを仕上げ、その内容をリーダーが具体的に報告の中で触れているからチェックも出来てそうだ。
xチームは、外からは何やっているかイマイチ見えないけど大丈夫かな？そろそろ成果物の締め切りだけど。。。
そしてこのような分担しての設計や開発が一通り終わると、次に迎えるのが「結合テスト」や「総合テスト」と呼ばれる、各機能同士を結び付けて
実際に業務で使われる通りにデータを入力→処理→出力したり、一日の流れ通りにシステムを操作して次の日期待通りの結果が出ているかを確認したりするテストです。
そして！ここで顕著に、機能領域ごとの違いが原因となって「思うようにテスト進まねえぞ…」という事態が起こるのです。
ある機能と結合してみるとやたら障害が挙がるぞ。。。もしかしてこの機能、単体でもマトモに動かないんじゃないか？
あのチームが作った設計書をもとにテストのシナリオを作ろうとしたけど、設計書の記載が粗くてテストの切り口を決めようがないんですけど…
え！？うちが担当していた機能をそんな使い方をする予定だったなんて聞いてませんけど！？だからそんなテストできないっすよ！
あ、その画面の設計/開発した人は異動しちゃいました。引き継ぎ？うちのチームでは誰も。。。リーダーの指示なかったし。
こういった、「チームごとの違い＝機能領域ごとの違い」をいかに吸収して同じスタートラインに立って結合テストや総合テストを始められるようにするか、というところに頭を悩ます役割が基幹業務システムの切り替えプロジェクトには必要になります。
（放っておいてもみんな一定のラインに達するなんてことができればいいんですけど、大抵そうはいかない）
この役割を担う人はある程度のプロジェクト経験や、システム開発のノウハウを持った人である方がいいので、ここに割くリソースをどう捻出して、各チームとの調整や全体スケジュールとの整合取りをどう仕切っていくかということが、プロジェクトの大変さを「×2」するポイントになると考えます。（こういうことを考えなければ考えないで、それはそれで工数が2倍になるとかいう逃れられない運命が 笑）
大変な理由その２：業務パターンやデータパターンの洗い出しができる人が（ほぼ）いない
「総合テスト（システムテストと呼ぶこともある）」がいわゆる良いテストになるかどうかを決める要因の1つは、テストシナリオの網羅製だと思うんですよね。
つまり「いかに多くの、実際の業務上発生しうるシステムの使われ方やデータのパターンをテストの中で扱えるか」。
もちろん、時間や人手さえかければ考えうるあらゆるケースを濃淡なく全部確かめるなんてこともできますが、
そんなことをしていては予算超過やスケジュール遅れで、プロジェクト外に対して説明や交渉が必要になりますし、かけたお金や時間に比例してシステムの品質が上がるのかというと実はそうでもないと思います。
ポイントは、「網羅製が十分なテストシナリオをいかに効率よく作るか」ではないかと。
そしてこれが大変さ2倍の理由の1つだと考えます。
テストシナリオの洗い出しのざっくりプロセスは次のようなものになるはずです。
1. システムの中で定義されているデータの「テスト上有意な組み合わせ」を機械的に挙げきる
2. 1によって生じる処理方法の違い、処理結果の違いを機械的に挙げきる
3. 業務におけるシステムの使われ方とタイミング（業務イベント）を挙げきる
4. 1,2,3を組み合わせて、「業務イベント×データの組み合わせ」を洗い出す
5. 4を基に、総合テストとして、「いつ、誰が、どんな操作を行い、その結果はどうなっているべきか」を書き出していく
この中で、「システムのことをしっかり理解している人」が1と2を、「業務のことをしっかり理解している人」が3を担当し、
それぞれで協力して4,5をやっていくのが望ましいんですが、これが大変。
「このデータの組み合わせはこの業務イベントの中で扱うから、他の業務イベントで改めて扱わなくていいよね」とか
逆に「このデータの組み合わせは実はある特定の業務においては特殊な意味を持つから、『何月に扱うか』という切り口でシナリオを複数用意しないといけないよね」とか、、、
こういう難しいこと考えないといけないのに、総合テストをスタートさせるときにはシナリオが揃っている必要があるから、
プロジェクトを止めないためには各機能の開発と並行してシナリオ検討をしないといけないけど、「システムのことをしっかり理解している人」も「業務のことを（略」も開発の方に時間を取られっぱなしでどうしよう。。。
こうしてもたらされるのが、「業務パターンやデータパターンの洗い出しができる人が今はいない」という状況。
大変さ×2、効率良いシナリオを諦めるとここでも工数×2 泣
大変な理由その３：テスト環境のやりくりで1ヶ月後のプロジェクトの状況が決まる
システム導入のプロジェクトに関わった経験がないとピンとこないかもしれませんが、「環境」という言葉がよく飛び交います。
もちろん自然環境とか、労働環境とかの意味ではなく、要は「システムが動くためのサーバやそれへのアクセス経路のまとまり」を指します。
各機能の開発が行われる「開発環境」とは別に、結合テストや総合テストを行う際にはそれ用の「テスト環境」を用意する必要が
出てくるんですが、そこには「最新の開発状況が反映されたシステム」と「やろうとしているテストに必要ないろんなデータ」、
テストの内容によっては「他のシステムと繋がるための経路」や「現在稼働中のシステムの一部」などが備わっていることが条件です。
そう言われると、だんだんこの環境やりくりの重要性が伝わってきたと思います。例えば、
来月の初めから、準備したシナリオを使って総合テストを始めるけどそのためには一通りのマスタデータが揃っていないと、、、
開発環境のマスタはテストデータばっかりだし、テスト用に環境を作らないと！そのためには○○チームにこの日までにマスタ準備
してもらって、それで、、、
綺麗なデータが入った状態にするなら「移行リハーサル」で使った環境でそのままテストすればいいじゃん！あれ？でもリハの環境は
周辺のシステムと繋がっていないんだった、、、環境から環境へデータだけ丸ごとコピーする必要があるぞ…
え！？結合テストの終了が予定より1週間遅れるの？でもそのテストで使っている環境は来週から別のテストで使うんだけど…
1週間だけ空いている環境はないのか…でもテストの内容を考慮するとあの環境なら間借りできるんじゃないかな？テストチームのリーダーと相談しなきゃ！
こういった調整に走り回る役が必要になるんです。
そして調整をミスったり遅れたりするとスケジュール通りの開発やテストが立ち行かなくなることに直結します。
うまく環境利用をしていくための、環境利用計画の策定とプロジェクト内への周知、そして計画通り行かなそうなニオイを察知して先回りして動けるカンの良さ、これらを兼ね揃えた「環境大臣（ぼくが関わったプロジェクトでは大抵こう呼ばれてました）」」を立てて環境を回していく。めちゃくちゃ大変なのです。
大変な理由その４：「定例進捗会議」が存在してしまう事によるテストへの影響
プロジェクトの規模が大きくなればなるほど、避けて通ることが難しくなる「定例進捗会議」というマモノ。
PMをはじめとしてプロジェクト内のリーダー陣が集い、報告フォーマットにしたがって各チームが「予定に対する進捗」、「現在直面している課題への対応方針」などを報告していくという形式になることが多いです。
が、しかし、想像以上に、色々とこの進捗会議に向けて準備の工数が掛かります。
そして、「テスト」の報告をするときにややこしいのが、「定量的に報告できてしまうからこそ、説明が難しい」ということだとぼくは感じています。例えば、
「こういう切り口でのテストケースが全部で300予定されていて、予定通り120本まで消化しています。」
「障害発生数は累積で32件です。想定より少し多いです。」
という予定と状況の報告には、
・300という総数は十分なのか、なぜ十分と判断したのか。
・それとは別にどんな切り口のテストをやろうとしているのか、どういう理由でテスト実施の順番を決めたのか。
・逆に、やる予定がないテストとしてはどう言うものがどれだけあって、なぜやらなくて良いと考えるのか。
・発生している障害32件の内訳はどうなっているか、機能別で見ると？原因別で見ると？
対策は何か考えているか、いつまでに対策が打てればいいのか。
以上のような裏付けや示唆が用意できていないと、報告を受けた側が期待する情報にならず、「テストの状況、マズいのでは」
なんて言われちゃいます。
そのため、テストフェーズには毎週の進捗会議に向けて上記のようなことを取りまとめ、分析し、必要であれば対策を関係者と合意する と言う地道なシゴトが不可欠になりテスト運営事務局が疲弊していきます。
複雑で多岐にわたる業務を徹底的に効率化するための仕組みであるからこそ、基幹業務システムのテストとなるとあっちやこっちで常に何かが起こり、状況を取りまとめるだけでも相応のコストを要する、しかもそれを毎週エラい人たちから報告を求められる、と言うのが、
大変ポイント4つ目かなと。
大変な理由その５：「本物データ」を使ってできるテストにはいろんな制約がある
③の環境の話と若干かぶる所もあるのですが、テストで使えるデータが「いかに本物っぽいか」はテストの質を左右する重要なファクターになります。
会計仕訳データを例にすると、貸借の科目が全然関連がないようなものをテスト用に何千件と用意しても、「あ、きちんとデータ登録、表示できるね」のテストくらいにしか使えないと思います。
それを、実際にその会社が行う取引に沿うように、「売掛/売上・仮受消費税」、「普通預金・支払手数料/売掛金」、「仮受消費税/仮払消費税・未払消費税」みたいに一連の仕訳が繋がって、金額も妥当だったりした方が、
テストで動かしていて、「あれ？これマズくない？」と気づけることが多くなるのは想像できると思います。
じゃあこういう、「本物っぽいデータ」を使ってテストするにはどうすればいいか。
それは実はシンプルで、「現在の業務で使っている本物のデータ」をテスト環境に入れて使っちゃえばいいのです。
しかしそれも言うは易しなんですよね。「本物のデータを新しいシステムに入れる」って言うのはそれはもうデータ移行をするってことに等しいので、システムベンダー（テストする人たち）にデータを渡せばよしなにやってくれるってものでもなくて、ちゃんと新システム（まだ開発中なのでこれから先もいろいろ変更点が出ること前提）で使える状態のデータを用意するにはしかるべき作業手順でデータを入れていくことになります。
そうなると、テストデータの用意だけで1ヶ月とか余裕でかかっちゃうことになり、
「XX日からしかテストできませんよ！」
かつ、
「来月からは他のテストのためのデータ準備を始めるから、それまでに今のテストやり切ってね！」なんていう状況が生まれるのです。
これが「本物データ」を使う際の時間的制約。
他にも、本物データを本当にそのまんまテストに使うと、個人情報がテスターに丸見えになってしまってそれはマズいので、
大抵は「マスキング」といって氏名を「テスト 太郎」に一律変換したり、連絡先をダミー文字列に置き換えたりするんですが、
このマスキングによって、本物では氏名が全角20文字以上ある海外出身の方がいるけどそれに気付けず、「氏名入力フォームの最大桁数は全角15文字」という仕様の問題点にテストの中で気づけない、なんていうマスキングによる制約というのもあります。
ガバクラ移行となると、扱われるデータの範囲も量も膨大で、本物に近いそれを使ったテストの重要性は一層増すことは想像に難くないです。
しかしそれを用意するコストと、使うことによる制約の大きさも計り知れないでしょうから、これもまた各地のプロジェクトでみなさんが苦しむポイントになりうるのかなと考えています。
1700の自治体があるということは、、、
こうして、思ってたより32倍大変なテストをやることになるチームが、日本全国に1000以上あるということを思うと
そしてそれを知る国民はわずかだということを思うと、ITの業界の端くれとしてちょっと悲しくなります。
ガバクラへの基幹業務システム移行完了目標は25年度末なので、流石にそろそろ、「現場ではこんな感じ」なんていう報道が出てきてもいい頃なんじゃないかなーと思います。
でも最近は大ニュースだらけで、報道があったとしてもこの話題が注目を浴びることはないかもしれないですね。。。
まあとにかく、ガバクラ移行の現場の皆さん、引き続き体に気をつけて頑張ってください。
この記事が気に入ったらサポートをしてみませんか？