各自治体がガバメントクラウド移行の完遂のために超えねばならぬ6つの壁（後編）
写真は、先日ブックオフで買取してもらった、過去にSwitchで遊んだソフトです。
思いの外良い値段で買い取ってもらえてちょっと驚きでした。
記事の内容には一切関係ありません。
前回記事の続きになります！
第四の壁：スケジュールと品質の壁
パートナーとともにシステムの要件定義以降がスタートしてから長きにわたってプロジェクトに立ちはだかるのが、スケジュールと品質の壁です。
この2つは常にトレードオフの関係にあることは、システム開発の経験者なら理解していると思います。
そうなんです。「とりあえずそれっぽく動けばいいから、早く納品してください」なんて話があるわけもなく、基幹業務システムとなれば特に、
「業務が止まったり、誤りが起こったりしないような品質のものを、プロジェクト開始時に決めた期限までに完成させるべし！」
ということが求められます。そして言うのは簡単だけどこれにどれだけ頭を悩ませることになることか。。。
まず、「業務が止まったり、誤りが起こったりしないように」をシステムに求めるのであれば、
・そのシステムを使う業務ってどんなインプットがあって、どういう条件でどういうアウトプットをするの？
・で、その業務はどういう権限を持つ人が出来れば良くて、逆にデータや画面を見せちゃいけない人はいたりするの？
・ルールや前例から外れたケースが発生したらどうする？処理の途中で止める？処理自体始めない？それとも？
・インプットしてからアウトプットまでにどれくらいの時間なら掛けていいの？夜間処理では何をする？
etc…...
といったようなことを、全ての対象業務について洗い出し、ユーザと決めて機能や画面の設計に落とし込んでいなければ始まりません。
しかし当然それにはかなりの時間を要するので、あっちでもこっちでも同じだけパワーをかけて要件定義・設計をしているといきなりスケジュール遅れが発生してしまいます。
今回のガバクラ移行の対象業務が17、細かくいうと20らしいのでそのくらいの規模だと（全部一括で進めるとして）要件定義と基本設計の予定期間としては6ヶ月から長くて9ヶ月ってところじゃないでしょうか。
6〜9ヶ月で全ての業務について上のようなことを検討するリソースがあれば良いのですが、ほとんどの自治体では難しいと思われます。
そこで、おそらくですが自治体によっては、
「戸籍情報管理と住民台帳管理はとことん品質を上げることとしてしっかり時間と要員を使い、逆に就学事務とか選挙人名簿管理はそこそこ品質で目を瞑ることにしてスケジュール遅延を防ごうか。。。」
というような判断が必要になってくるのだと思います。
新システム稼動直後は、就学事務や選挙人名簿管理の業務においては多少の手作業でデータ補正や連携をすることを許容しちゃって、開発する機能の数や複雑さを落とすことで他領域にかけられるリソースを稼ぐというようなイメージです。
稼働してから1年くらいして落ち着いてから、これらの箇所は追加開発をするということにすれば負荷分散になるという策です。
この手の判断に求められるのは、「業務上、ガバクラ上の新システムで出来ないと本当にマズいことって何？」を言語化してプロジェクト内外の関係者ときっちり確認、合意することが第一なんでしょうね。
それを一言で言うと、「要件定義をきっちりやる」となって、これは当たり前のことっちゃ当たり前なんですが、
結局コレなんですよ。システム導入のプロジェクトの成否をまず分けるのは。でも難しいからこそ、企業のプロジェクトになるとこの辺りに我々のようなコンサルティング会社とかが支援に入ることになります。
ガバクラ移行における要件定義支援って、それこそ各自治体個別に発注してたらキリがないと思うんだけど、そう言う支援もデジタル庁側から半ば売り込むような形でいかないと、なあなあに要件定義を終えちゃってこの先苦戦する自治体が多発するなんてことにならないかしら、と言うのは心配ではあります。
これまた手前味噌ではありますが、ぼくが働く会社で出している「システムを作らせる技術」と言う本は、特に要件定義について抑えるべき
検討箇所や整理すべき事項を体系的に解説しています。こう言う知識があるとないとでは1年後の状況に雲泥の差があるのではと思います。
https://www.amazon.co.jp/dp/4532323991
第五の壁：ユーザ教育の壁
ここまで書いてきたようなことに毎日向き合ってきていた各自治体内ののプロジェクトメンバーとは異なり、それ以外の職員の皆さんは「あぁ、毎日遅くまで大変そうだなぁ。」とは思いつつ、やはり「自分はプロジェクトの外の人」という立ち位置で長い期間を過ごすことになるんだと思います。
仮に2025年度の第4四半期に移行後のシステムを使い始める予定とするスケジュールである場合は、きっと2025年の4,5月くらいまではそんな状態じゃないかと。よっぽど意識的に巻き込む動きとかを取らない限りは。
しかし、彼らが「新システムのメインのユーザー」であることは揺るがない事実です。
なので当然必要になるのが、「現行のシステムでの業務に慣れきったユーザーたちに新システムの使い方を習得させる」という大仕事です。
いかに品質の高いシステムを予定通りの期日で完成させても、ユーザーが
「ログインパスワードって何見ればわかるの？」とか、
「メニュー名が前のシステムと違うからどこで何するのかわからないんだけど。。」とか、
「あの帳票ってどの画面で見るの？」
なんて言っていては
新システムの稼働開始もままなりません。
そのため、基幹業務システムの切替を行うプロジェクトでは、「ユーザ教育計画」と言うのを作って推進していくのがフツーです。
内容としては、上に挙げたような基本的な機能や操作説明、実機を使ってのデモ、そしてユーザー受入テストの参加、運用ヘルプデスクの設置などでしょうか。
そしてシステムの規模が大きくなればなるほど、つまりエンドユーザーの数が増えれば増えるほどこれも比例して大変さが上がるのです。
ぼくが今まで関わってきたプロジェクトは、従業員数が数千人規模の会社で使う人事や会計システムの刷新だったりしたのですが、数千人に向けて教育を行うためにどういう工夫をしていたかを少し説明します。
◆「伝導者」を立てる
プロジェクトメンバーは、システムのテストや諸々の課題解決にてんてこまいであることはあらかじめ予想できるので、
ユーザ教育に関しては、例えば部署ごととかで、
「あなたが、自分のところのエンドユーザーへ新システムについて操作方法や
便利な使い方を広める使命を負うのですよ^_^」
という人を立ててもらうのです。
そして、プロジェクトからは特にその伝導者の方々十名〜数十名くらいへ、新システムについての諸情報をインプットし、あとは伝道者の皆さんそれぞれが、自部署に合ったやり方やペースで部署内へ展開してもらうようお願いするというスタイルです。
一度、伝道者による自走が始まったらプロジェクト側としては展開の状況を気にしたり、相談に乗ったり、技術的な質問に答えたりというカタチでサポートします。
このやり方の良い点は、何よりもやはりプロジェクトメンバーの所要工数が少なくできる所と、教育を受ける側からしても、「得体の知れないことを毎日やってる人たち」から
「あなたの業務は将来こういうやり方してもらいます」
と説明されるよりも、いつも同じ部屋で仕事しているあの人から、
「あの作業のやり方がこう変わるらしいから、今までめんどくさかったアレは省略できるね。でもこんなことに気をつけないといけないですね。」
のように同じ目線で伝えてもらう方が心理的ハードルも下がるし、
「じゃあ仕事のやり方にこんな工夫したらどう？」みたいなプチ業務改革の姿勢も生まれる可能性がなきにしもあらずって気がしてきませんか？
◆新システムへの習熟度を上げることを各業務部門、課のミッションとしてもらう
伝道者の話とも関連するのですが、（会社として、あるいは自治体として）業務で使う新しいシステムを導入するという船を漕ぎ出したのだから、
「うちの部は月に数回しかシステム使わないはずだから、使う時がきたら聞きに行くよ/~」というスタンスを許容してはいけないはずです。
なぜなら、新システムを稼働させることが狙いではなく、稼働した新システムで行う業務が前より何らかの点で改善されたことを確認できて初めて、
プロジェクトのゴールが達成できたか（＝成功と言って良いのか）が言えるから。
なので、エンドユーザとなる業務部門は基幹業務システムの移行によって自分たちは何を達成したいのかをあらかじめ理解し、その達成に向けては新システムを使いこなす／業務のやり方を変えることの役割を持っていることを自覚することが重要ですよね。
「なるべく良いもの作ってよ。便利だったら使ってあげるからさ^^」というお客さんポジションでは、いつまで経ってもシステムを利用しての業務に習熟できず、ひいてはその状況が、「あの画面、なんとなく使いづらいからこういう機能も作って欲しいなあ」というような安易な追加開発の種をまき、
それに飛びつくお馴染みベンダーというベンダーロックイン状態を一層強固なものにするんじゃないかなとぼくは邪推してしまいます。
「新システムの説明会があると言われたから、うちの部からは絶対あの人は聞いておいてもらわないとマズイよ！」
「うちの課では受入テストにおいてあの業務とこの業務で今のやり方と変わる／変えるべきところを挙げきるからな！
プロジェクトの方でそれまでにマトモに動く状態にはしておいてね！」
「○○さんと△△さんは、新システムの操作説明会参加できないみたいだから、参加した人から後日レクチャーしないと」
というような声が上がる状態となると、「各業務部門、課として新システムへの理想的な姿勢をとってもらえた」と言えてプロジェクトとしても嬉しい限りです。
◆ユーザ受入テストの計画と運営は発注者が主体で進められるよう、ベンダーとの役割分担等を調整する
先に例でも触れたように、「ユーザ受入テスト」というものがユーザ教育の意味でも非常に有用です。
もちろんこのテストは単に検収、つまり、求めている品質レベルを満たしているものが納品されたかということを確認するという意味もあるのですが、
それはあくまで一面に過ぎません。
どっちかっていうと、ぼくは受入テストは発注者側が、
「おれたちはXヶ月後からはこのシステムを使って仕事をするんだ。だから事前に気になることや不安、今の仕事の問題点がどうなるのかを確認して、必要であれば改善を要求できる最後のチャンスなんだ。」
と覚悟するフェーズという意味が強いと考えます。
では、放っておけば自然とこの受入テストの環境が出来上がるのかというと、もちろんそんなことはありません。
この件については、あらかじめ、しかもかなり早いうちからプロジェクト内で「受入テスト計画」として調整を始める必要があります。
主なポイントとしては以下のようなところかと思います。
受入テストでねらうものは、単なる検収ではなく上記のようなことである旨の明言と合意
テストの対象とする業務とそこで利用する新システム機能の範囲
受入テストで、業務方メンバー、特にプロジェクト外の人たちはどの程度参加するのか
ねらいとテスト範囲を実現するためには、システムがどういう状態まで出来上がっているべきか（登録されているデータの本番らしさやインフラ含め）
受入テスト期間中に、ベンダーからはどういうサポートをしてもらうか
などなど。。。
こういった話を、要員など確保のためにも結合テストが始まる頃くらいから、各業務部門の管理職も巻き込みつつ、プロジェクト内のベンダーPMとかと始めていくのは発注者側のリーダー層のミッションです。
ベンダー側も当然、受入テストをしてもらうつもりはあるので自ら話題に上げてくるにはくるのですが、やはり目下の関心となるとその時点で着手している自分たちの開発やテストでしょうから、それに全乗っかりしてしまうとどうしても「シャンシャンで終えられそうな」受入テスト方針に落とし込まれて
しまう懸念が拭い切れないのではないでしょうか。
やはり、受入テストもしっかり活用してユーザ教育の壁も乗り越えられるよう、ここは発注者側、つまり業務方が手綱を握るところではないかと思います。
以上3点が、一部ではありますが基幹システムの導入プロジェクトにおけるユーザ教育推進の注力点です。
ここら辺のノウハウとか、ガバクラ移行における全体方針とか、実際の推進支援もデジタル庁から提供するのは難しかったりするのでしょうか？
この件に限らずですが、具体的なデジタル庁からの各自治体への支援の内容がわからないことが、ぼくの一連の投稿のきっかけだったりします。
第六の壁：データ移行の壁
開発、テスト、ユーザ教育がなんとかなりそうでも、また別の壁として立ちはだかるのがやはりデータ移行ですよね。
基幹業務システムの導入、特に現行で何らかのシステムが稼働しているためそこからの切替となると、プロジェクトの総工数の3,4割はデータ移行に使われるというのは我々の業界では言われていることです。
では何がそんなに大変なのか？これまで幾つかの基幹業務システムの切替プロジェクトでデータ移行に関わった身からその辺りをガバクラ移行を見守るみなさん向けにお話ししたいと思います。
が、前編に続き今回も長大な文章になってきたので、移行に関しては見出しだけこの場で紹介して、今後１つずつ個別の投稿にさせてください。
現行業務、システムで使っているデータの汚さ
「要件はなかなか確定しない、だけど正解は何より早く求められる」それが移行
ハイパーSEや業務有識者「だけ」では物理的にどうにもならない
そんな大変さを理解して協力してもらうのがまた大変
移行リハーサル という、人によっては名前を聞くのもうんざりな中ボスへの準備と闘い
考えれば考えるほど、国を挙げての今回の取り組みの難しさに勝手に辟易してしまいます 笑
今後ももうしばらく、ぼくの思うところを徒然と書いていきたいと思います。
この記事が気に入ったらサポートをしてみませんか？