各自治体がガバメントクラウド移行の完遂のために超えねばならぬ5つの壁（データ移行編）
写真は、今年1月の「ギターマガジン」でやっていた『ギタリスト460人が選ぶギター名盤100』に挙がっていたCDを集めるために始めた"ギター名盤100の旅"で収集したものの一部です。
恥ずかしながら初めてマトモに聴いたというミュージシャンが結構いて、勉強の日々です。記事の内容とは一切関係ありません。
さて、気づけばもう8月（！）、ガバクラ移行に関わるニュースも、最近ではあまり数を見なくなった気がします。
一方で、こんな記事も。
期限守るのは「絶対無理」？ ガバメントクラウド移行、自治体も遅れ
https://www.asahi.com/articles/ASS642W39S64ULFA009M.html
会員登録なしで読める範囲から抜粋すると、
「対象の全1700自治体のうち、171の自治体が「うちは25年度末までに達成は無理だと思う」とコメント」
「運用しているシステムが大規模なところほど、期限内に達成が難しい」
「原因の一つはIT人材の不足」（やっぱりか。。。）
…なるほど、記事の続きでどれほど具体的に触れられているかはわかりませんが、やはり「25年度末までに主要な業務で利用するシステムはガバメントクラウド上へリプレイス」ということの難しさにギブアップ宣言ともとれる表明を始める自治体がポツポツと現れてきているのですね。。。
これまでの投稿でも話したように、基幹業務システムの切替って、「リソース（お金と人員／時間）があればいけるっしょ！」ではないのだということを、身をもって国中で味わっているということはもしかすると今回の取り組みでの最初の成果ではあるかもしれません ( ´艸｀)
（もっとも、「そのリソースすら用意できないんだけど…」という自治体もあるようで、それは全国一律でのリプレイス範囲と期限という計画が原因とも言える。）
今回は、基幹業務システムの切替プロジェクトで、
「リソース（お金と人員／時間）があっても上手くいかない！？」
となることが特に多いのではと個人的に強く思っているデータ移行についてその難しさの要素をいくつか語って、当事者にあたる方には覚悟（？）を、見守る方には更なる応援の気持ちを強くしてもらえれば何よりです。
そもそもデータ移行って何やるの？
まずは「データ移行」って何？という話を簡単に。
例として、新築の戸建てを購入して、来年に竣工予定。その後入居する というケースで考えます。
この場合、「入居日当日に、家財道具を新居に運び込み、家族も家に入って、その日から生活をスタートできるように諸々作業すること」
がシステム刷新のプロジェクトにおける【本番切替】に当たるものです。
そしてこれら作業が3つに大きく分類できます。
まず1つ目は、「家財道具一式を、現在の住まいやそのほか保管場所から新居へ運び込んで、意図した位置にセッティングし、使える状態にすること」
これが【データ移行】です。
そして2つ目が、「現在の住まいでこれまで続けていた生活習慣や家事の一挙手一投足を、新居での生活に合わせて切り替えること」
これを【業務切替】と呼びます。
そして最後が、「運び込んだ家財道具類、入居した家族の生活上の役割分担を運用開始できる状態にして、新居での生活一日目を開始すること」
これは【システム切替】と呼びます。
これらが全部完了して、新居への引っ越しが無事終わったね！＝【本番切替完了】と言えるということです。
そして今回話は、引っ越しでは家財道具一式に当たる、"業務を遂行する上であらゆる用途で利用する「データ」たちを新システムへ移行すること"の難しさを5つの視点で語っていきます。
1. 現行業務、システムで使っているデータの汚さ
例えば普段、仕事とかで使っているExcelとかのいわゆる台帳、「○○用連絡先一覧」とか「XXチェックリスト」のような都度記入・更新する資料。
使い始めた当初は、「必須記入の項目は、コレとソレとアレだな。よし、みんなちゃんと書いてね！」としてスタートしたはずですが、いつのまにか守られなくなった必須記入項目や、「備考」欄を用意しておいたらそこに「関係者の連絡先」を書く人がいたり、「想定外の状況になったのでその事情」を書く人が出てきたりすることって経験ありませんか？
…あるでしょ？笑
そうなんです。同じようなことが基幹業務システム使っていくうえでも起こっちゃうんですよね。だって業務事情はいろいろな理由で常に変わっていくもので、そのたびに必要な情報が増えたり減ったり、思いもよらぬ事態が発生することもたまにはあります。
そんなことを繰り返していくと、システムに蓄積されていく「データ」がどんどん
"そんな風に登録されるとは、開発当時は想定していなかった…"
状態になっていくのです。↑で挙げたExcelの例のように。
これを、「データが汚い」と表現します。
データの入れ物となるシステムからの目線ですね。
だって入れ物側としては、「この項目にはこういうことを書いてね！」と想定しているわけで、計算処理などは全部その想定に基づいて用意されているのですから。
さて、ではその入れ物であるシステムを新たに作り直して、今後はそちらを使って業務をするということになった場合、この汚いデータたちはどうすれば良いか。
選択肢としては2つしかありません。
A. 新システムには持っていかない！バックアップとしてディスクとかに残しておいて、どうしても必要になったらそれを見る。
B. 持っていかない訳にはいかんから、データとしてキレイな（入力ルールに沿った）状態に頑張って治す。
Aで妥協できるのならぼくたちは断然それを推奨します。
しかし、それこそ地方自治体の業務となるとBにせざるを得ないケースがたくさんありそうな気がしています。
じゃあ、各データの新システムとしての「キレイな状態」とはどういうもので、それに沿わないデータは各種何件ずつくらいあって、
キレイにするには何をしなきゃいけなくて、それを誰がいつまでに、どうやってやるのか。
…これを決めてデータの修正をしていかないといけないんですよ。（こういった修正をデータクレンジングと呼びます。）
そしてこれができるのは、基本的には業務を日々やっている担当者だけ！（だって業務データのナマモノを外部の人間は触れないから）
この壁を乗り越えなければ、どうしても必要なデータだけど、新システムには移行できません、、、という事態が起こりうるのです。
2. 「前提は中々確定しない、だけど結果は何より早く求められる」それが移行
「ある業務で使う機能はどんなIPO（入力処理出力）をするか」
これがシステムや各機能の仕様と呼ばれるものだとします。
するとデータ移行にあたっては、
「その機能のIPOのためには、あらかじめ用意されておくべきデータとその項目は何か」
がデータ移行の要件と言えます。移行されたデータがI（インプット）となるわけですから。
ここで一度話題を変えて、システムのテストが大まかにどういうサイクルで行われるかを見てみましょう。
まず「テスト仕様」というものを考えます。テスト対象とする機能はどれ（とどれ）で、テストの観点は何か。
その機能をその観点で、どんな操作をして検証するのか。決められた仕様を踏まえると、結果としてどういう状態になったらOKか。
では、「各機能が決められた仕様通りに動くだろうか」をテストしたい場合に準備しないといけないものは何でしょうか？
それは、「開発を終えたプログラムが動くシステム環境」と「テスト仕様書（具体的にどんな操作をするか、どうなればOKか）」、そして
「テストでシステムを操作するときに使うデータ」なんです。
となると、先に書いた通り、「機能としての仕様」が決まってようやく「そのためのデータ要件」がわかるのに、機能が仕様通りであるかを検証するテストのためには、「仕様通り機能が動くために必要なデータ」をあらかじめ準備しておかないといけないということになります。
なんだコレ！！因果律のバグかよ！
例えるなら、
「１．今日の夕飯何にしようか？」
→「２．オムライスにしようか、レシピは〜、材料は〜だな。」
→「３．よし、早速レシピ通り作ってみよう。」
→「４．卵ねえじゃん！何で用意してないのよ！」
…いや、２と３の間に材料の何をどうやって調達するか決めて、実際に調達してくるという作業があるのよ！すぐやってみたいのはわかるけど。
このように、考え始めるための前提が揃うまではあんまり動けなくて、揃ったと思った途端、
「これで合ってるか確かめたいから、急いでデータをテスト環境に欲しいんだけど！」
と言われてしまいがちなのがデータ移行の難しさ2つ目なのです。
この壁を乗り越えるためのポイントは、データ移行とはこういうものなのだということをプロジェクト内で全員が理解して、タスクの計画を立てることが大事だとぼくは思います。
手戻り覚悟で、想定でデータ移行を早めに動き始めるというのもアリですが、やはり何よりも、
「移行担当何やってんだよ、、、」
「テスト担当何も分かってねえな、、、」
とお互いのヘイトを抱えてしまうことがプロジェクトにとって最悪の事態だと思いますから。
3. ハイパーエンジニアや業務有識者「だけ」では物理的にどうにもならない
そして、新しいシステムで業務を行うためには、現在使っているシステムのどんなデータを、どんな状態にする必要があるかを考えることの難しさが立ちはだかります。
しかし、
「今使っているシステムで日々更新している〇〇データ、新しいシステムだとどんな画面から見れるの？更新できるの？」
「新しいシステムで使い始める機能A、あのデータも用意しておかないとマトモに使えないと思うけど、それって考慮できてる？」
などなど、基幹システムの切替を行うプロジェクトではこんな会話が日々交わされます。
そしてこれらに答えたり、この先の検討事項として担当していくのがプロジェクト内でのエンジニア（新旧のシステム担当）、各種業務担当者になります。
すると、想像はつくかもしれませんが、彼らには「データ移行」のことだけを考えているリソースは無くなってくるんです。
物理的に仕事に使える時間は1日8時間からせいぜい10時間とかちょっと。
ハイパー優秀なエンジニアや、担当業務は端から端まで理解している業務の有識者がその内データ移行に費やせる時間はその内せいぜい、毎日1〜2時間ってとこじゃないでしょうか。ぼくの感覚ですが。
じゃあこういうリソースの制約の中どうやって「データ移行」という大仕事を成立させるか。
そこで登場するのが「移行の推進役」とか「領域別移行担当者」たちなんです。
簡単に図にしてみましたが、こんな体制を組めるかがこの壁を乗り越えるポイントだと思うんですよね。
全領域が個別で検討して整合取れなくなることを防ぐために統括する役割（全体の推進役）を置き、
その号令の下、業務領域ごとにそれぞれの移行要件に基づいてデータ移行の設計や開発、実施を行う担当者を配置する。
こうすることでシステム、業務のメンバー（図中のシステム班、業務班）は新システムの機能検討やテスト、新しい業務運用の検討に軸足を置きつつ、
データ移行に関わる要求出しやレビューを移行担当者と行い、全体の移行推進役が各領域の移行内容を取りまとめて本番の全体作業手順やスケジュールを組み立てる。
こういう体制を組めずに遂行できるデータ移行ってごく稀だと思うんですよね。うまくいったとしても運が良かったか、複数人の徹夜など残念な犠牲の下に成り立っているような再現性のないものになる。
だからもし、データ移行の準備と実施のリソースの大半を機能検討や業務設計メンバーの兼任みたいな形で考えているガバクラ移行プロジェクトがあれば、早めに考え直して貰いたいと思う次第であります。
4. そんな大変さを理解して協力してもらうのがまた大変
と、ここまでざっと書いたことで皆さんには伝わりましたか？
データ移行という大仕事がなぜ難しいか、どんなことをしないといけないか。
きっと「へえ、そうなのね」と頭では分かってくれたかもしれませんが、もし実際に自分が業務とシステムを変えようとするプロジェクトに携わっていたとして、考えないといけないこと、こなさなきゃいけないタスクが山のようにあるときに、それらと比べるとどうしても「まだ先の話」な気がしてしまうデータ移行についてどれだけ考慮できるでしょうか。
きっと過去に同様のプロジェクトを経験してたり、よっぽど先のことを考えて計画を立てるようなタイプの人じゃないとそこに頭が回らないと思います。
だから、この感覚を持っている人がそのことをプロジェクト内に広く周知して、実際に工数を割くのは全員ではないにしても、少なくとも気持ちだけはプロジェクトメンバー全員が、データ移行という難所に向けて協力し合う意識を持っておいてほしいというのが一経験者であるぼくの想いです。
いつかきっとその意識がプロジェクト成功のための一手に繋がると信じて。
もっと言うとこの投稿が一人でも多くのガバクラ移行の関係者の目に留まり、何か一つでもこの先のデータ移行に関して先んじて手を打とうと思ってもらえることがこの「理解と共感の壁」を乗り越えるために、完全な部外者のぼくができることの一つだと考えています。
5. 移行リハーサル、という中ボス
こんなに難しい要素が潜んでいるデータ移行、当然ぶっつけ本番でうまくいくことなんてないと断言してもいいと思います。
だからこそ、移行の「リハーサル」というのをやるんです。これも本番と同じくらい綿密に計画して、準備して。
例えば、本番の移行作業が全2週間で行われるスケジュールだとしましょう。
すると、
「本当に2週間で足りるの？」
「各1日1日でそれぞれどの作業まで終わっていればいいの？」
「何かトラブルが起こったときに、誰がどういう動きをして解決にあたるの？」
「プロジェクト内への進捗報告とか障害連絡はどうやるの？」
「データごとに移行作業の手順を用意してあるけど、他のデータと合わせてどういう順番でやるべき？」
などなどなどなど、その2週間でデータ移行をやり切るために決めておくべきこと、検証しておくべきことが山積みです。
これらを移行リハーサルというイベントを複数回繰り返すことで潰し込んで、スケジュールや作業手順の問題点を極力減らしていくのです。
しかし当然、リハーサルなのですからできる限り本番と同様にやるべきで、そうなってくるとこれまた大仕事なんです。
リハーサルのための準備（スケジュール、システム環境、移行に使う元となるデータ、作業担当者の予定、作業手順書etc）とプロジェクト内での開始、終了の報告、リハーサルの運営と作業の実施、これら全て含めると先に示した体制のうち「移行推進担当」と「各領域の移行担当者」のリソースを2ヶ月間、8割方費やすと言っても過言ではありません。
これが1回じゃなくて、大抵は3回、多いと5回とかやりますからね。
逆にいうとそれくらい時間と工数を割かないと本番移行これでいける！という状態までいかないのです。
そしてもちろん、リハーサルをやってみると、次のようなことが起こります。
「想定していた期間じゃ作業終わらないんじゃない。。。？」
「移行するデータが足りてない！○○データを先に入れておかないと、このデータ入らないじゃないの！」
「プログラムの設定が想定と違う。。移行する時点では一旦そのための設定にしておいてもらわないといけなかった。。。」
「システムにデータ取り込み処理してみたらエラーが数百件出ちゃう。これは事前に対策できないから、作業の中で見つけて都度都度直して再取り込みしていくしかないのか(´×ω×`)」
いやあ、ハラハラしますね笑
データ移行とはこういうものなのです。だからこそリハーサルをやるのです。
例えるならまさに、ダンジョン内のラスボス（本番移行）に挑むまでに各階の中ボス（リハーサル）を倒して、ドロップアイテムや経験値を入手してこちらのステータスアップを図らないといけないみたいなことです。
歴代の名作ゲームたちには、皆さんにとって忘れられない中ボスが数々いたことでしょう。
ちなみにぼくはドラクエ7（PS）のヘルクラウダーと、ホロウナイトのフンコロ騎士（夢見）のことは生涯忘れません、、、
ガバクラ移行の完了までに各プロジェクトに立ちはだかる中ボス（移行リハ）たちを皆さんが無事乗り越え、ラスボス（本番移行）に立ち向かってもらえることを祈るばかりです。
「出来ません。。。」を時間をかけることで解決しても、稼働した新システムのメリットは100%享受できないと思う
話は冒頭の記事に戻りますが、25年度内でのガバクラ移行達成が出来ない自治体がいくつかあったとして、彼らが期限を延ばしてなんとかかんとか移行を成し遂げたところで、それって「ただ言われた通りに必死で新しいシステムにしがみつけただけ」じゃないかなとも思うんです。
移行切替が順調に出来ないような体制しか組めない、ノウハウがない組織がクラウドサービスの業務システムを使いこなして期間業務をこの先こなしていけるんでしょうか。
今回話したような移行の体制と似たようなものが、クラウドシステムの運営にあたっては必要になる気がしていて、それは当然デジタル庁とか中央省庁周りでは考慮されていたとしても、地方自治体がそこに巻き込まれているのだろうかということも気になるところです。
さて、前回までの投稿（テストについて、壁の話前編、後編）と合わせてこれで一通りぼくがガバクラ移行に関して吐き出せることは吐き出せた気がしています。
この先何をしようかな 笑
この記事が気に入ったらサポートをしてみませんか？