各自治体がガバメントクラウド移行の完遂のために超えねばならぬ6つの壁（前編）
写真は、先月人生初挑戦した競馬で訪れた大井競馬場です。
初挑戦の感想としては、「ドラクエ3のカジノのモンスター闘技場くらいの冷静さで見ちゃってた自分がいたので、多分自分は賭け事で熱くなれる人間ではないとわかった」です。記事の内容とは一切関係ありません。
2025年度末までの完了目標に対して、ガバクラ移行に苦戦してすでにその達成が危ぶまれている自治体もあると思われます。
でも。システム導入のプロジェクトに関与したことのない人には「なんで決められた期限までに出来ないのよ！(# ﾟДﾟ)」と思われることもあるのではないでしょうか。
特に国や市区町村の取り組みですからね。。。うまく行かないのならそれはそれでちゃんと説明してよって思う人も少なくないのかもしれません。
なので今回は、ぼくのこれまでの経験などから推察した、ガバクラ移行でも直面する可能性が高い「システム導入のプロジェクトに立ちはだかる手強い壁」を6つ紹介して
「あー、こりゃ確かに他の仕事とは違って一筋縄では行かないよね…」という共感を少しでも持ってもらえたらいいなと思って書きます。
第一の壁：庁内体勢の確保の壁
まず、ガバクラ移行については「やろうぜ！」という号令はデジタル庁からされていると見て良さそうですhttps://www.digital.go.jp/policies/local_governments
これはどうやら、新型コロナウィルスの流行時に政府から国民へ出された補助金支給にあたって、国民の口座情報などの収集や補助申請の受付などといった業務で予想以上の負荷や時間がかかり、
「あ、日本の行政って全然IT化出来てない…（やっぱり）」
と政府も国民も実感せざるを得なかったという経験に端を発した構想のようです。
うん。非常に妥当な課題意識だと思いますし、ようやく気づけてよかったねと感じます。
ただ、逆に言えば、「負荷も時間も掛かっちゃったけど、なんとか補助金支給やり切れた」というのも事実だと思うんですよね。
（色々と細々した問題もあったかもしれませんが）
そうなってくると、行政サービスのIT化を押し進める仕事というのは、「大事だけど、急ぎでやらないとダメなわけじゃないよね」と捉えられがちです。
特に現場に近ければ近いほど。
この絵でいうとまさに右上に位置すると。もちろん人によっては「左上なんだ！」という強い思いを持ってたりしますが、少なくとも日々現場で事務手続きや住民サービス（＝左上）にあたっている方々からすれば右上にならざるを得ないでしょう。
そして、右上についてデジタル庁から「やりますんで、おたくのとこの市区町村で人員を当ててね！」と号令がかかった時、
現場の思いとしては当然、「いやいや、他にたくさん左上の仕事が山盛りなのに、今そんなのに時間避けるかよ！」という
ものになり、積極的にプロジェクトに関与してくれるメンバーがどれほど立てられるか、ということが最初の壁として立ちはだかるのです。
ガバクラ移行の道のりは長く険しいものになることは後述しますが、プロジェクトチームの体制図にとりあえず名前だけ書いておく程度の関与では、いずれどこかで大きな問題や遅延を招くことは想像に難くないかと。
必要なのは、「今の業務を改善したい、変えたいと思いプロジェクトの目的を理解して主体的にタスクを推し進めてくれるメンバー」なのでそもそもこういう人員がどれだけ存在するか、彼らを巻き込んだ体制が構築できるか、がガバクラ移行プロジェクトの成否を左右する、最初にして、もしかしたら最大の壁と言えるかもしれません。
そう考えると、「現在の業務、システムへの問題意識」をいかに広く庁内に広めるか、共感してもらうかというのが体制構築のカギな気がしてきます。いわゆる情シスと呼ばれる各自治体のIT部門ではこの手の問題意識のタネを持っているかもしれません。
「○○業務を今のシステムでやってると、夜間バッチだけでは処理が追いつかなくて結構な頻度で手動処理しちゃってるんだよね。。。効率悪い。。。」
とか、
「法改正で、元は全然別の申請フォームを使っていた2つの申請手続きに共通点が増えたんだけど、今のシステムでは別物で扱っちゃってて無駄が多いんだよね。」
みたいな。
こういう話を「これはチャンス！」と庁内に広めて、解決するなら今でっせ！と売り込んで（？）行くような動きがあるともしかしたら思わぬところから協力の手が差し伸べられたりしないのかなあ。
自治体内の部署がどれだけ縦割り感があるかは存じ上げないので、妄想の域を出ないのですが。
第二の壁：オーナーシップの壁
さあ、このメンバーでガバクラ移行を進めるぞ！と決まったとして、集められた各メンバーのスタンスはどうでしょうか？
彼らはおそらく、普段は各課で決められた手順やルールに沿って業務を遂行し、「こういう結果が出たらその仕事は完了」
というようないわゆるルーチンワークの達人たちであり、各課では優秀なまさに精鋭部隊だと思います。
しかしプロジェクトワークとなると各自のやらねばならぬこととその進め方がガラッと変わってきます。
まずそのやらねばならぬこと自体が、所与のものではなかったりします。
つまり、「何をインプットにするか」、「どういう形のものが成果物となるか」などからして正解が最初から与えられるわけではなく、
他のメンバーや上司と話しながら調整して都度決め、やってみて「あれ？変えた方がいいぞ。」と思ったらまた軌道修正して、
というのを適宜繰り返しながら「やらねばならぬこと」を明らかにしていくという動きが全員に求められます。
そうなってくると、いかにルーチンワークの達人であっても仕事との向き合い方に戸惑うことが多いと思われます。
これを「オーナーシップの壁」と呼ぶことにします。「自分に求められている仕事の成果を自分で決めて関係者と合意して、それが達成できるように進め方も自分で考えていく」という姿勢をメンバーが持つことができるかどうかが勝負です。
昨今ではこういうことができる人を「DX人材」とか呼んでたりするみたいですね。
呼び方はなんでもいいんですが、名前だけ決めてもそういう人が生まれるわけじゃないので、特にシステム部門とかの課長部長の皆さんなんかは悩んでるポイントなんじゃないでしょうか。
手前味噌ですが、ぼくが働いている会社では「プロジェクトリーダーおよびプロジェクトチーム養成学校」と言って、プロジェクトワークに使える考え方や振る舞いを身に着けるための数ヶ月にわたるワークショップを昨年から始めています。
https://pages.ctp.co.jp/ctpbootcamp.html
デジタル庁でも「窓口BPRアドバイザー派遣事業」として、まずは窓口業務のBPRとDXを糸口として有識者からのアドバイスを行うような取り組みをしているようです。
このようなアドバイスで得られるのは、「何をやるか」だけでなく、「何をやるかをどうやって考えるか」であるべきじゃないかとぼくは思います。
よく言う、「井戸の掘り方や魚の釣り方を教える」みたいな話。
ガバクラ移行を対象としたこう言った支援の枠組みもきっと用意されてる、もしくは近々されるのではと思います。
…さすがに、全くこの辺りの支援なしっていうわけにはいかないと思うので、あると信じてます。
第三の壁：パートナー探しの壁
庁内の体勢と心積りは万全に思えたところで、次に立ちはだかるのがやはりパートナー探しでしょう。
システム導入に関わったことがある方はもしかしたら一番最初にこの心配が頭に浮かぶかもしれません。
実際、世のガバクラ移行関連のニュースとか見てみると、「ITベンダーに対応できるリソースが足りなくなるのでは！？」とかの言説をよく目にします。
そもそものガバクラ移行の狙いの1つが、「今は各自治体が長年同じITベンダーに依存している状況であるため、それを転換して様々なパートナーと協業できる基盤としてガバクラを活用する」というものなのに、本件が原因でガバクラ移行が進まないとなると本末転倒というか、目的に対する手段が誤っているってことになる気がしますね。
しかし、ぼく個人としてはこう思います。
「昔ながらのやり方でシステムを作ってもらおうとしてたら、そりゃベンダー側も多大なリソースがないと請けられないだろうけど、
今回のガバクラ移行をきっかけにしてシステム導入プロジェクトにおける発注者とベンダーの役割を再考して、将来に向けても
ベンダーロックインにならないような成果を挙げる ってのを目指せないだろうか。」と。
こう書くと無謀なことのように見えますが、要は従来のような「業務がやってることをベンダーさんしっかり把握して、いい感じのシステムを納品してよ」
を辞めるってことです。推測を含みますが、地方自治体の基幹業務システムってこういうやり方で出来上がっちゃったものが少なくないのでは、と。
このような、餅は餅屋、システムのことはぜーんぶシステムベンダー、というような考え方では請けるベンダー側としては労働集約型のビジネスモデルで案件に当たる考えに傾かざるを得ず、
そうなってくると多大なリソースを費やして請けた側としては、「この顧客と太く長い付き合いで食いつなぐぞ！」と考えて、
今後出てくるであろうシステムへの要望にとことん付き合えるように、詳細仕様は社内でガッチリ掴みつつ、開発当初に業務をシステムに落とし込んだノウハウは門外不出にしておくことで、半永久的にお仕事をもらえる仕組みの完成です。
ガバメントクラウド上に基幹業務システムを移すことで、ベンダーロックインに陥らないようにする は確かに一つの原因解消の手段として
妥当かもしれませんが、それだけでは不十分で、発注者側がどこまでシステム開発に踏み込めるかがもう一つの鍵なんじゃないかと。
ガバクラ移行で新しい関係性を持って協力しあえるITベンダーを見つけるためには、発注者である自治体側に次の覚悟が必要なんじゃないかってことです。
「きちんと自治体側から要件を整理して伝え、業務観点での品質担保も各フェーズで責任を持って行う。」
「納品を受けた設計ドキュメントやシステムは、自分たちの資産として把握、使いこなす。」
「あなた作る人、わたしそれを買う人、というスタンスを辞めてイチプロジェクトメンバーとしてガバクラ移行をやり遂げる」
もちろん、覚悟として思っているだけでは足りず、パートナー選定にあたって上記を「我々の役割です」と明言した方がいいです。
従来のオンプレシステムで付き合わされた運用に、今度はガバクラで付き合わされるのか…！？なんて身構えているベンダーとしては
これらが発注者側の役割として明言され、遂行されることへの安心感ったらないんじゃないかと。
パートナー探しの壁へは、従来通りのシステム導入プロジェクトのパートナーではなく、システムを発注者とベンダーで真の意味で協業して作り上げるプロジェクトのパートナーを探すというスタンスで臨むことが必要なんじゃないかなと考えたりします。
後半へつづく、、、
書き始めたら想定以上の文量になったので続きあと3つは後日。。。