11/26(土)19:00-21:00、闇のIT営業勉強会の第一回を行った。

今回の話題提供者はジョン・スミス氏（仮名）。元広告代理店勤務。自治体・省庁に対して補助金事業などの企画提案営業を行なっていた他、補助金の受付や交付などの実務を行う補助金事務局の中の人をやっていた経歴を持つ。学生時代からNPO法人を立ち上げるなど、ソーシャル領域における10年以上の活動歴がある。

あまりにも「結局は『人』次第」な環境に辟易し、現在は某IT企業に転職して、ビッグデータ×地域をテーマに活動中とのこと。

前半：講義パート(1h)

最初の1時間は、話題提供者から、補助金事業の流れについての基礎的な話を聞いた。

国のプロジェクト（国プロ)ができるまで

国の省庁がプロジェクトを立ち上げるには、いくつかのフェーズがある。ジョン・スミス氏によれば、以下のフェーズに分割される。

①最初に内閣官房が大まかな目標を掲げる。
②内閣官房内で検討会議が行われる。
③方針が固まった時点で、所轄の中央省庁に渡される
④中央省庁の担当者が民間にヒアリング等を行いながら具体化する
⑤概算要求(8月末）

＊

さて、この検討会議が、なかなかに闇深い。

内閣官房の現在活動中の会議はWeb上で公開されているが、その数は執筆時点(2022/12/9)で210個に登る。

今回は、その中のデジタル田園都市国家構想実現会議の会議資料の一部を見たが、中でも⾯⽩法⼈カヤック 代表取締役CEOの柳澤⼤輔氏が第8回会議に提出した資料が、検討会議の闇を指摘している。

まず、参加人数が多い。たかだか30分から1時間程度の会議に20名程度の参加者がいる。しかも、ほとんど全員が大臣や取締役などの肩書を持っている。

その上で、発表時間が厳守であり、皆各自が用意した原稿を読んでいる。

最近「エンジニアのやる気を削ぐ会議術」という記事がバズっていたが、人数を増やす、事前に資料を配った上で、当日資料を読み上げるなどの会議のアンチパターンを地で踏んでいる。

「事前に視聴した上で、当日の質問・議論に望む方が、委員の皆様が同じ時間に集まる価値が出てくるのではないかと思いました」とあるが、要するに今の状態では決まり切った文面をお互いに読み合っているだけなので、今の在り方では同じ時間に集まる価値が感じられない、ということなのだろう。

とはいえ、検討会議はさまざまな立場の委員を呼び、懸念事項や観点を洗い出すことが主な目的だと思われるので、これでも機能はしているのかもしれない。

＊

このような検討会議を通過した後、プロジェクトは担当の省庁に渡され、担当者が民間にヒアリング等を行いながらプロジェクトを具体化していく。

この時に、省庁の担当者は、つながりがある民間の人にヒアリングや相談をするそうだ。個人的には、これは結構面白い論点だと思う。省庁の人間は頻繁に異動するため、かならずしも特定の施策の専門家ではない。多くの場合、省庁の担当者よりも民間の人間の方が施策に対する肌感を持っている。予算の都合上、4~6月には来年やることを決めなければいけない、という都合もある。それゆえ、省庁の担当者は、プロジェクトが回ってきた検討の初期段階で、過去にプロジェクトを依頼した相手などにいろいろ尋ねるのだという。

ジョン・スミス氏も、このタイミングで相談などを受けながら、検討会議の資料を読み込み、提案をまとめていくそうだ。大事なことは議事録の文脈を読むこと、書かれてない間を埋めてあげることだという。例えば、検討会議の参加者の一人がポロッと言っていた（が、メインのポンチ絵には入っていない）意見を企画に盛り込んであげる・・・などが大事らしい。

この段階で事業スキームに対する変更提案を出していくこともある。例えば、元々は国から直接民間団体に補助金を配るスキームだったが、中間に民間の補助金事務局を挟むことを提案する、などを行なっていく。民間の補助金事務局を通すことで、データをより活用しやすくなる、広報などの強みを生かしてより効率的な予算活用ができる、などのメリットがある。概算要求の時点で事業スキームがかなり固まってしまうので、概算要求の前に民間が食い込める余地や理由を作ることが企画営業の腕の見せ所になっているという。

このように、概算要求資料を作る時点で、民間の人間が、民間の視点で概算要求資料をレビューする（例：「これじゃ誰も手をあげないですよ」など）ことがあるらしい。

＊

8月末には概算要求がある。財務省との調整や国会を通すなどの必要があるため、概算要求時点で「いい感じのペーパー」を用意する必要があるらしい。

補助金の交付

補助金事業を受託した後、補助金事務局が行う業務についても詳しく話を聞いた。

補助金事務局の最大の目的は、補助金予算をちゃんと執行することにある。「予算執行率が7割以下だったら死刑」という発言も飛び出した。

そのために、補助金の公募要件の設計や広報、説明会などを行う。申請受付、審査委員会の設置なども行う。最終的に採択事業者を決定した後は、採択事業者のPRや進捗管理なども行う。

9割の事業者は補助金の手続きを一人で完遂できないので、補助金交付のための事務手続きの尻拭いの作業が非常に重いという。この辺の手続きが進まなくて補助金が執行できないと、補助金事務局側が責められるので死ぬ気で尻拭いをするとのこと・・・。

予算全体の中で事務局の取り分はだいたい1-2割くらい。思ったよりも少ない印象だ。

なお、補助金の審査は事務局ではなく外部の審査委員会にお願いするとのこと。事務局が審査すると、応募者の追求から言い逃れしにくいという事情があるらしい。

後半：質疑応答・議論パート(1h)

後半は話題提供者の話を踏まえて、議論や質問応答を行った。

補助金喰いのプロ

なんと議論の中で、補助金喰いのプロと出会ったことがある、という参加者からの報告があった。「○○のプロダクトを作るから1000万必要だ」という理由で補助金の交付を受けたあと、最低限要件を満たしていると言えなくもない程度の（ほぼmockの）システムを構築することで、100万円程度の人件費で1000万の補助金を得られるらしい。

もちろん補助金担当者から指摘を受けることがあるが、ITがメインではない補助金事業だと、検査はスクショを貼ればOKだったりする。指摘してきた担当者に逆ギレして担当者のリソースを食い潰すことで、担当者も「手続きに多少の不備があっても、補助金を払って対応をさっさと終わらせる」モードに入るので、なんとか検査を乗り越えられる・・・らしい。また、事務局には内部通報などの仕組みもあり、一度やらかした団体は記録に残るが、それらのブラックリストは管轄を跨いで共有されることはあまりないので、地域や管轄を越えれば同じやり方が通用するとのことだった。

もちろん、補助金適正化法では「補助金で著しく利益を上げることは不適切」とされているので、これは違反である。ジョン・スミス氏曰く、ITプロダクトの検査の仕組みなどはアップデートされているので、今では通用しないかもしれないとのこと。

データ活用の難しさ

また、行政がデータを活用する際の壁がどこにあるのか？という話も出た。

行政事業の場合、年度ごとに新しい事業になってしまうため、該当年度の事業のデータを次年度以降の別事業に活用することができないことが多いのだという。「中身はほとんど同じなのに別事業」になってしまうことの弊害がある。また、省庁や所轄団体を跨いでデータを渡すことには大きなハードルがあるとのことだ。

それゆえ、国や自治体が主体的に関連データの活用を行うとなると、省庁の調整を行う必要があり、ハードルが沢山ありコストが非常に高い。民間に任せてしまった方がマシ・・・という構造があるらしい。

ジョン・スミス氏によれば、根本的な課題は、予算が「課題」ではなく「事業」に付くことにあるという。年度ごとに予算がつく仕組みのため、同じ課題に対し、それを解決するチーム・プロダクトを経年で伸ばしていく・・・という視点がない。そのため、データを保持したり、仕組みを改善したり、ということが進まず、毎年同じようなことを新しい予算でやっている・・・という現状が起こりやすいのだという。

感想

ここからは主催の私の感想を述べていく。

「予算を先に決める」という仕組みのヤバさ

初歩的なことではあるのだが、補助金事務局の仕事の成果を測る指標として「予算の執行率」が用いられている、というのは個人的に衝撃だった。最近バズった下の記事でも似た記述がある。

補助金事務局の業務も「採択事業者として選んでしまったからには、なんとかして補助金を払わないといけないので、補助金交付のための事務手続きの尻拭いをする」という構造がある。話題に出た「補助金喰いのプロ」も、まさにこの部分をハックしている。「予算が予定通りに消費されていることが、正しく進捗していることを表す」ので、進捗をあげたいと願うならば、それぞれの担当者は「予算がついてしまった以上、なんとかして払わなければいけない」のだ ※1

似たような事例で、観光系の予算が（コロナの波を予測できなかったせいで）使いきれず、「億単位で予算が余ってしまったので、何かいい使い道はありませんか？」と尋ねられるケースも存在するという。

もちろん、この部分に対する対抗策はいろいろあり、実際には予算の執行率以外の指標もいろいろあるらしいが、それだけでこの問題を防ぎきれているわけでもなさそうに思える。

「闇のIT営業」としては、公的機関の担当者がこのような「予算を予定通りに消費したい」というニーズを抱えていることは把握しておく必要があるだろう。

また、「先に高い予算を宣言させる」ことが非常に重要なハックになりそうだ。予算を組んでいるタイミングと、納品のタイミングの間には、大きな時間的ズレがある。そして、予算を組んでしまった以上、担当者には「予定通りに予算を払わなければいけない」という圧力が働く。「予算交渉のポンチ絵の段階では、なんかすごいことをやりそう」に見せることで、実際に開発の段階になってから大した作業が必要なかったとしても、高い単価を維持することができるかもしれない。逆に言えば、予算を組んでいるタイミングが勝負であり、いざ開発するタイミングになってからアップセルを狙うことは難易度が高いようだ。

「上」が重すぎる意思決定フロー

このような「予算」型の意思決定が行われる背景には、ある解決策が実行されるまでに関わっている人間が多すぎる、という点があると思われる。来年やることを、前年度の4-6月には決めなければならない。しかもそのためには、先程の検討会議のような、たくさんの偉い人間の時間を大量に消費する謎会議が何度も行われなければならない。

これだけの重さがある意思決定機関が上段にある以上、上段で意思決定されたことは、下の人間にはなかなか覆しにくい。まして、前年度に決めてしまったことなどは、今年度にはそう簡単には覆せない。

一度決まってしまったからという理由で、意味のないプロジェクトが動き続けている・・・というのは、民間でも非常に思い当たることが多い話題ではある。このような「上」が重すぎる意思決定フローは、「無駄なプロジェクト」が生み出される大きな要因だと思われるので、闇のIT営業勉強会としては非常に関心が高いテーマである。

逆に言えば、実行してから柔軟に事態に対応するような意思決定が苦手であるため、闇のIT営業としては、将来的に発生しうるリスクや可能性を強調し、先に予算を積ませることが重要であるかもしれない。ウォーターフローのプロジェクトにおいて、多くの人は「バッファを積む」ことでなんとか問題を回避しようとしてきた。予算を積む段階で、将来発生しうるリスクを定量的に説明できれば、リスクを最大限に見積もった予算を通すことがより楽になるかもしれない ※2

行政の中に「一貫したチーム」がいない

ジョン・スミス氏が、根本的な課題として、予算が「課題」ではなく「事業」に付くことを指摘したのは面白い点だと思った。行政の人間の多くは、特定領域の専門家ではない。かれらは予算という形で外部に事業を委託するが、これらは年度ごとに細切れになるため、現場の知見や仕組みの改善が蓄積されていきにくい。

ジョン・スミス氏は現在IT企業で働いているが、「顧客の課題を解決しながら、プロダクトに還元すること」に関心があるという。同じ課題に対し、毎年同じように予算を費やしていても、それらがソリューション（プロダクト）への還元されていかないこと、行政の中に「チームを育てる」という育成機能がないことは、行政の課題の一つであると考えられる。

このような行政組織の時間的一貫性のなさは、民間団体に対し、逆に癒着のチャンスを与えているように思える。行政組織は内部に知見の蓄積ができないため、知見の蓄積がしたければ特定の民間団体に一貫して任せるしかないのだ。逆に言えば、知見の蓄積をアピールしていくことで、行政と長く付き合っていくことが可能性が高まると思われる。

第二回告知

闇のIT営業勉強会の第二回は、12/22(木)19:00-21:00に開催する。

勉強会の場では、本レポートには書けないような、具体的なプロジェクト名や固有名詞が出る話も聞ける。

勉強会への申し込みフォームはこの記事の中にある。

闇の自己啓発の共著者のひでシス氏など、当初の想定より豪華なメンバーが集まっている。今のところIT系の企業の社長や代表が多いが、今後はユーザ側（自治体など）の参加者も集めていきたいと思っている。あなたもぜひどうぞ。

※1 市役所で働いている知人にも聞いたところ、「予算が常に全く余らないことはないけど、基本的に余るかもしれないというやり方は受け入れにくいかも」「予算余らせたら、その分は来年から削られる可能性も高い」「今はコロナがあるからイベント予算が余るみたいなこともザラだけど、通常時だったらなぜ余ったかなぜ払わなかったかを追及されるかも」とのこと。
「前の年に決めた予算を１円も余すことも、１円も超えることなく使い切らないといけない」というのは言い過ぎにしても、予算を使い切る方が、予算を余らせるよりは面倒がない・・・というのは真実であるようだ。予算がさまざまな会議を通して決まった者である以上、予算を予定通りに使うことには説明が要らないが、予算を余らせることには納得のいく説明ができなければならない、というのが根っこにあるのだろう。

※2 いちおう言っておくと、これは皮肉であり、意思決定の重さに伴うコストをバカにしている記述である。意思決定が「重い」ということは、それだけリスク対応に対して積むべきお金の量が増えるということだ。

一般に、ITプロダクトを作成する際、初期コンセプトの状態で工数の見積もりを行うと、見積もりのプロが行っても、±4倍（25%~400%）のブレがある。

来年度ある施策のためにITプロダクトを作ろうという計画があり、まだ初期コンセプトしか決まっていない段階で、来年度の予算を決めなければいけないとしよう。もしこの状態で、90%以上の確率でプロダクトが完成することを目指すなら、期待される金額の4倍を積まなければならない。そして一度決まった予算が予定通りに消費することが求められる以上、どれだけ工数を下げる手段が後から見つかっても、その選択が取られることはないのだ！

まさにこのような不確実性をどう扱うかという問題の中で、IT業界においてはアジャイル技法が選択されるようになってきたのだが、現在の行政の仕組みは、このようなプロジェクトマネジメント技法の進化に全く追いついていない。行政の仕組みが不確実性を扱うことに全く向いていないことは明らかであろう。