「1789」（弁論原稿公開第３弾）
弁論公開第３弾。
同期大会「烏龍杯」での弁論です。
2024年8月10日
烏龍杯争奪弁論大会
第２弁士 早稲田大学 SMKR弁士
演題「1789」
〈原稿〉
導入
みなさん、こんにちは。
〇〇大学〇〇〇〇学部の〇〇〇〇と申します。
サークルでは、〇〇〇〇で、政治を勉強しています。
またアルバイトでは、国会議員の学生秘書を、３年間務めています。
大学、サークル、アルバイト、すべてで政治漬けの学生生活を過ごしてきました。
本日は、よろしくお願いいたします。
という自己紹介を、何十回もしました。
就活です。
そうすると、必ず、こう聞かれました。
官僚には、ならないんですか？ と。
分からんでもないですが、自分には、ひとつの軸があります。
政治改革。
行政が、より効果的に、合理的に動けるように、改革をすることです。
国会対応など日常業務に追われる官僚では、できません。
国や自治体を支援して、数年に１回の改革を現実にする。
改革の場数を踏める仕事として、公共分野の経営コンサルタントを選びました。
そんな公共コンサルの業界、実は今、絶好調です。
それは、地方公共団体の情報システムの標準化、通称、「自治体標準化」、によるものです。
自治体情報システムの現状
これを議論するために、まずは、自治体の情報システムの現状をご説明します。
ここでいう「情報システム」は、非常に多岐にわたります。
住民基本台帳などの「保存」するシステム、固定資産税や児童手当などの「徴税」や「給付」のシステムなど、自治体でコンピューターを使う、すべての仕事が含まれます。
これが今、どうなっているか。
一言で言うと、「バラバラ」、です。
どれくらいかというと、全国で同じシステムを使っている分野は、ゼロです。
その結果、自治体を超える手続きは、ものすごく不便です。
１つは、自治体と、民間の関係です。
こないだ、パスポートの申請に行ったんですね。
まず住民票は、地元の〇〇〇市役所でもらえました。
次に戸籍謄本、僕はなぜか本籍地が〇〇〇なので、１時間かけて〇〇区役所に行ってきました。
そしてやっと、有楽町のパスポートセンター、これは東京都がやっています。
申請と受け取りの２回、行きました。
ほんっとに面倒くさかったです。
他にも、引越しの手続きや、市区町村をまたがる会社の活動など、バラバラな情報システムが問題になります。
２点目は、自治体同士、あるいは自治体と国との関係です。
例えば、コロナ禍での10万円給付といった、自治体を通じた国の政策。
自治体ごとにシステムを改修する必要があり、時間やコストがかかっています。
自治体標準化
こうした「バラバラな自治体情報システム」を解決するため、自治体標準化が進められています。
3年前、「地方公共団体情報システムの標準化に関する法律」が施行されました。
これにより、2025年度末までに、戸籍や年金など、主要な20の業務で使うシステムを揃えることが、義務付けられました。
まず、デジタル庁主導で、国がシステムの仕様を決めます。
次に、各自治体がシステムを開発する会社、いわゆるベンダーに発注して、システムを開発します。
標準化の理念
この自治体標準化は、僕は、ぜひ実現してほしいと思っています。
人口が減少する日本は、もはや無駄な仕事をしている場合じゃありません。
コスト削減、さらには業務の削減が必要です。
公務員が、公務員にしかできない仕事をする。
山積みの課題を究極的に解決できる、この国の行政府に力を与えるために、自治体標準化は絶対に必要です。
1718の市区町村、47の都道府県、1つの国。
合わせて「1789」個の政府が、日本の希望です。
しかし今、標準化対象の20の業務を、自治体ごとに苦労して開発しています
1789に20をかければ、3万5000もの個別のシステムが、バラバラに動いている。
これが自治体の現状です。
たとえば、〇〇〇〇〇〇〇。
日本には1800の店舗があるそうです。
それぞれの店が、それぞれコーヒー豆を買ってきて、それぞれのメニューを作って販売する。
ありえないですよね。
それを１つにする。
これが自治体標準化の理念です。
問題提起
僕が就職してからの１年間、最後の最後、標準化に向けてどうしても解決できない課題の、解決を支援する仕事ができるんじゃないかと、楽しみにしていました。
しかし、到底そうは言えない状況になっています。
〇〇じゃないですよ。
システムの開発が遅れている。
そして、今後もっと遅れそうな状況なんです。
開発の遅れ
開発プロセスのうち、７つのポイントで、マイルストーン、つまり完了期限の目安が決められています。
つい４日前、総務省への情報公開請求で、驚きの結果が出ました。
今年の４月末時点での集計です。
３月末のマイルストーンを完了している割合。
あるべき数字は、当然100%です。
それがなんと、31.4％。
さらには、去年の年末のマイルストーンでさえも、43.2%の進捗です。
中身を見ても、20個の業務すべてが満遍なく遅れています。
遅れた原因は２つあります。
１つ目は、システムエンジニアの不足。
そもそも、3万5000ものシステムを一気に切り替えるなんて、前代未聞です。
自治体と似たお堅い金融業界では、１つの銀行のシステム移行に、最低４年かかると言われています。
自治体標準化を2025年までに全て完了させるのは、物理的に実現可能性が低いんです。
名前は伏せますがあるベンダーの幹部は、このままだと、2025年に間に合う自治体の方が、少ないだろうと言っていました。
２つ目の原因は、開発の順番がグチャグチャなことです。
システム開発は、仕様を固めるところから始まります。
しかし国が作る仕様書は、いつまで経っても完成版が出てこないんです。
今年の4月に、20の業務のうち16が改訂されました。
そのため、開発のスケジュールが狂いまくっています。
しかも、つい一昨日、近いうちにまーた改訂があると聞きました。
これでは、開発が完了するはずがありません。
事業者間協議
こうした中で必要なのは何か。
それは、デジタル庁のリーダーシップ、ではないでしょうか。
状況を打開するために知恵を絞り、推進する。
それが、担当省庁であり、言い出しっぺであり、自治体システムを救える日本唯一の希望である、デジタル庁の役割です。
それなのに、今デジタル庁がやっていることは、もはやビックリとしか言いようがありません。
今年６月の検討会で、ある大事な議論がありました。
それは、違う会社が作ったシステム同士を、どのように連携させるかです。
いやいや、連携するために標準化するんでしょ？
と、思ったんじゃないでしょうか。
まあ難しい話なので簡単にいうと、あるシステムがどのような機能をもっているか、という外側は標準化されますが、その中身、データ構造が各ベンダーに任されているんです。
これがバラバラなので、データのやり取りができません。
〇〇〇が作ったシステムと、〇〇〇が作ったシステムの間では連携できますが、〇〇〇が作ったシステムと、〇〇〇〇〇〇が作ったシステムは、一緒には使えないんです。これじゃあ、標準化とはほど遠い、今とあんまり変わらない、もう、謎な状況になってしまいます。
さすがにこれじゃまずいんで、デジタル庁は６月に方針を決めました。
それは、「事業者間の協議で解決する」、というものです。
こんなんできる訳ないですよ。
せっかく自分の会社でシステムを作ったのに、他の会社の、しかもゴリゴリの競合他社のシステムに寄せるなんて判断は、無理ですよ。
河野太郎大臣は、民間企業同士の競争領域、などと言い訳していますが、そんなはずありません。
求める商品の提供を前提として、どう差別化するか、それが競争領域です。
競争の結果、標準化という目的が微塵も達成されないのならば、そんな注文はやめてしまうべきです。
現状のまとめ
ここまでをまとめます。
バラバラな自治体の情報システムを、イマドキのものにする、自治体標準化。
しかし残念なことに、エンジニア不足と、標準仕様書が二転三転、あげく、打開策は「事業者間の協議」。
自治体標準化が完了する未来は、いまだ見えません。
あるべき開発のあり方
では、どうすれば良いのでしょうか。
その要素は、３つ。
１つ目は、開発プロセスの適正化。
標準仕様書を確定させてから、各自治体に落とし込んでいくという順番を踏むことです。
２つ目は、実現可能な開発計画。
3万5000もの無茶なシステム更新、今のままでは、どれかを優先することはできず、全体が遅れるという選択肢しかありません。
３つ目は、標準システムを、業務ごとに揃えること。
ベンダー同士の協議なんて頼りになりませんし、かといってデジタル庁はもはやギブアップ状態です。
これらを踏まえて、短期と中期に分けて、政策を提案します。
解決策
まず、今すぐに取るべき、短期的な行動。
それは、2025年度末、という期限の凍結です。
この問題の全ての元凶は、この無茶な期限を閣議決定したことです。
もともとは、2030年であったものを、菅政権のときに、官邸が押し切って、5年短くしました。
まずは、この、あと１年半しかない期限を凍結し、体勢を立て直すべきです。
次に、今後２、３年で取るべき政策。
それは、国が、1業務ごとに、1事業者と、契約することです。
20ある業務それぞれ、落札をした１つのベンダーが、すべての自治体の、その業務のシステム開発を担当します。
これにより、標準仕様書の策定もベンダーが担います。
そして、自治体に実装するまで、一気通貫の契約ができます。
そうすれば、〇〇〇と〇〇〇〇〇〇が、それぞれ作っているから連携できない、といったことは起きません。
すべて〇〇〇が作れば、事業者間の協議、そのものがなくなります。
このような、おそらく数百億円規模の大型契約は、大手のベンダーが落札すると思われます。
もちろん、エンジニアの人数には限りがあります。
しかし大手だからこそ、民間企業相手の大規模プロジェクトと同じように、下請けの協力会社と一緒に開発をします。
故に、現場でどの企業のエンジニアが開発するかはあまり変わりませんが、契約関係があります。
そのため、事業者間の協議は必要なく、１次受けの大手が上流で作った標準仕様書を、全国の現場に浸透させることができます。
さらに、20の業務を1つずつ開発できるようになります。
そのため、IT業界全体のキャパシティを圧迫しないように、現実的な開発スケジュールを組むことができます。
締め
さて、最後に、超長期の話をさせてください。
標準化で、自治体は今と比べれば 非常〜 に良くなりますが、救われることはありません。
どうしても避けられない人口減少、４割の自治体が「消滅可能性自治体」と呼ばれています。
東京で育ち、卒業後も東京に軸足を置いて、1789個の政治をどのように良くしていくか。
半年後から、まずは民間企業で全力で取り組みます。
そこに限界を感じた時、それこそが、僕が民間ではない世界に、いよいよ挑戦するときだと思っています。
その決意を申し上げて、人生最後の政策弁論を終わります。
ご清聴、誠にありがとうございました。
〈所感〉
結果としては、優勝をいただきました。
テーマ、構成、声調・レトリック、質疑まで、今の自分がやりたいことをやりきることができ、大変満足しています。
とはいえ、前回に引き続き、脆弱性のある弁論であることも確かです。
まず、全体的に解像度にばらつきがあります。
例えば「データ連携ができない」ということは、本来は情報技術の知識を含めてとても細かい理解が必要であるにも関わらず、例示によりなんとなくの理解を促すにとどめています。
また、一貫した論理を最重要視し、ガバメントクラウドなどの関連する論点をバッサリと削っています。
これらは、やはり弁論という、限られた時間・口頭のみという制約によるものです。
テーマは、中央地方関係と情報通信という、興味分野ど真ん中のものを取り上げました。
時事的な話題でもあり、迷走しつつある現状に対して解決策の仮説を提示する、という面で意義のあるものだと考えています。
初の弁論（2021年小野梓杯）・初の外部大会（2021年桜門杯）でもやはり中央地方関係を取り上げており、人生最後の政策弁論もこのテーマを選ぶことができ、とても嬉しいです。
「東京で育ち、卒業後も東京に軸足を置いて、1789個の政治をどのように良くしていくか」という想いは４年間変わることなく、卒業後も本職として取り組むことにしました。
構成については、もう４年生ですし、例によって弁論テンプレ的な考えは一切無視をしています。
かといって
後述しますが、実務的な（初歩的な）フレームワークの考え方を用いて論理を構築しています。
声調は、直前まで原稿の短縮に追われていたこともあり、本番通りの声量では１度しか練習できませんでした。
それでも、４年かけて場数を踏んだ結果として、自己ベストのパフォーマンスを発揮できたと思っています。
例えば導入のところ。
という（高い声）自己紹介をォ、何十回（若干裏声）もやってきました。
ﾏｧ就活ゥ、です。
というように、特に意識せず抑揚をつけて読むことができるようになったことを、録画を見返して気づきました。
（学生弁論界の方は、TwitterにYouTubeの限定公開URLを記載しておりますので、もしよろしければご覧ください。）
レトリックの面でも、「バラバラ」などのキーフレーズを使って、うまく伝えられたように思います。
そして質疑は、本noteでその内容は割愛していますが、ほぼ完璧にこなすことができたと思っています。
それは何より、地方自治体と国の関係を４年間考え続け、自治体標準化についてもここ半年ほど注目してきたという、普段からの思考（＋来年４月までの内定者課題である基本情報技術者試験の勉強）がもたらしたものです。
弁論大会に出ることになり短期間で知識を詰め込んだ過去の大会と比べると、こうした積み重ねが明らかに違いました。
質問を聞きながら頭の中で答えの方向性を考え、議論を楽しむ余裕を持つことができました。
〈解説〉
この弁論は、複数の実験的な構成を試しています。
「プロット」「解決策に必要な要素」「解決策」の３点に分けて説明します。
プロット
原稿を書き始める前に、以下のプロットを確定させました。
つかみ
就活の話から繋げて軽く問題提起
As is①：自治体情報システムの現状
自治体情報システムとは何か
自治体間で連携できていない：バラバラ
事例：パスポート申請の話
Solution①としての自治体標準化（＝To Be②）
連携できる状態
To be①：自治体標準化が目指す姿
効率化・合理化により、人間が人間にしかできない仕事に集中する
レトリカルに盛り上げる
As Is②：開発の遅れ
情報公開請求で判明した遅れ
Problem②：遅れ→解決策の絞り込みに接続
SEのキャパシティ
開発プロセス
Solution②の方向性：理想の開発施策
デジタル庁のリーダーシップによる開発
誤ったSolution②：事業者間協議
分析のまとめ
ゴールイメージ：解決策に必要な要素
開発プロセスの適正化
実現可能性のある開発計画
協議によらないデータ連携
正しいSolution②：政策
短期：今すぐに取り組むべき政策
期限の凍結
開発体制の立て直し
中期：２〜３年で予算化・実施すべき政策
１事業者に１分野を任せることで、仕様策定と実装まで一気通貫の契約
事業者は下請けに発注するのでやることは変わらないが、契約関係があるのでプライム企業が仕様を策定できる
締め：超長期の話
短期はこの場の提言に過ぎないが、超長期は今後の人生をかけて取り組みたい
見ての通り、「現状分析→原因分析→政策」という弁論のテンプレ的な概念からは完全に逸脱をしています。
カタカナで言うと「As Is / To Be分析」ですが、要は現実と理想のギャップを辿ることで解決策を導出する、そのプロセスを２回繰り返すのが、この弁論の根幹です。
（とはいえ、ConsultantはおろかAnalystでさえないただの学生ですから、フレームワーク云々にこだわるというよりは、新たな構成方法を考えるきっかけ程度のものです。）
まず、「As is①：自治体情報システムの現状」と「To be①：自治体標準化が目指す姿」を結びつけるのが「Solution①としての自治体標準化」です。
これは、弁論全体から見れば現状分析や前提確認にあたる部分であるとともに、これ自体がTo Be②として後半に繋がってきます。
そのため、弁論が目指す姿やその理念を伝える効果、問題の重大性を伝える効果があります。
その上で「As Is②：開発の遅れ」を提示し、最後に提示する解決策が解決しようとする問題を明らかにしています。
目指すTo Be②は前半①で明らかになったように自治体標準化を成し遂げることですが、現実には「Problem②：遅れ」が生じています。
そして、その現実を打開するための解決策の方向性を「Solution②の方向性：理想の開発施策」で軽く提示しつつ、実際には「誤ったSolution②：事業者間協議」が行われつつあるという問題点を指摘します。
これにより「バラバラな自治体情報システム」や「開発の遅れ」という、直接解決することはできない問題から、「誤った解決策をとっている」という、解決策の転換によりすぐに解決できる課題を特定するに至りました。
ここまでを「分析のまとめ」で再度示し、「ゴールイメージ：解決策に必要な要素」を導出、「誤ったSolution②：事業者間協議」を修正する「正しいSolution②：政策」を提示しています。
なかなかテクニカルな構成ですが、耳で聞いていて違和感のない流れにできたと思います。
解決策に必要な要素
分析から直接政策を提示するのではなく、分析と政策を結びつける段階として「解決策に必要な要素」を列挙しています。
これにより、分析がもたらす示唆を明確に示すとともに、解決策の納得感を得ることができます。
また、政策の唐突感をなくすことができます。
ここまでで既に政策の妥当性は説得済みであり、あとはこれに当てはまる政策を提案するだけです。
そうすれば質疑応答は、政策がもたらす副作用に関するものが大半を占めることが想定されました。
これを一つ一つ潰していけば、弁論全体としての説得力は最大の評価を得られるものと考えました。
解決策
弁論における解決策は、それがどれくらいのスパンであるにせよ、ある１つの時間軸に絞られることがほとんどです。
この弁論では実験的に、短期・中期・長期に分けた政策を提示することで、理想の実現に向けたステップを明確に・網羅的に示すことを試そうとしました。
ただし、長期については自治体標準化の理念そのものであることから、新たなものを提示する必要はないため、実際には短期・中期を示しました。
なお、もし片方に絞るならば、中期の政策が主軸になります。
ここまでご覧いただき、ありがとうございます。
以上が正真正銘、人生最後の政策弁論です。
感想・質問などをお待ちしております。
残すは来年３月の紫紺杯にて、目の前の学生弁論界のみなさまに向けた弁論を企んでおります。
今後ともよろしくお願い申し上げます。