ちょっとした縁で、govtech というものに興味を持っていたところ、ちょうど 2019/02/10 に govtech summit 2019 が開催されると知り、参加してみました。

僕は govtech にはこれまで関わりの無い、そこらへんにいるフリーランスエンジニャー（フロントエンド風味）です。

当日の様子は動画が上がっていたり、Togetterでまとめられています。発表とかを正確に追いかけるならこちらの方がいいでしょう。

以下は僕なりにまとめたものです。

govtechって何よ？

govtech とは最近流行りの○○techの1種で、役所でやるような、たらい回されたり、平日昼間しかやっていないような、面倒なアナログ手続きをデジタル化しようぜという話です。

僕が観測した範囲では、govtech summit 2019の主な参加者は行政にまつわる人たち（スーツ組）と、ベンチャー企業や僕のような興味本位のエンジニア（Tシャツ組）がメインで、少し大手企業の人がいるといった感じでした。

馬鹿踊りをしよう

発表の中で「馬鹿踊り」をしようというものがありました。

これはTEDでやっていた「ムーブメントを起こす方法」についての講演で、最初「馬鹿踊り」を始めた人がいて、最初は1人だけで踊っていたが、2人目が参加したことが大きな転換点となって、あとはフォロワがどんどん増えていったというものです。

イノベータ理論でいえば、イノベータが何かしらのイノベーションを起こす。行政とスタートアップが組んでgovtechを始めるというのが、ここでいう「馬鹿踊り」をし始めた1人目にあたります。

中央省庁だったり自治体だったりで、一部の先進的な人がデジタル化（govtech）に取り組んでいるものの、デジタルを使いこなしてカイゼンしていこうぜ！なんていう人はごく希です。そのため、govtechというムーブメントは「馬鹿踊り」であるといっているのです。

2人目というのは、1人目に続いて踊り出す人、govtechに興味を持ち実際に参加するアーリーアダプタのことで、発表していた方いわく「ムーブメントにおいては2人目の存在がとても重要」「今日、この会場に来ているみなさんが2人目になって欲しい」とのことでした。

現時点だとまだアーリーアダプタというよりは、一緒にイノベータになろうぜという誘いなのかもしれません。ちなみに発表では、イノベータ理論については触れられておらず、僕がそう解釈しただけです。

Digital or Die!

日本は今後高齢化が進み労働人口も減り、何かしら手を打たないと、色々なものが回らない時代が来ます。

そうなると、デジタル化によって浮いた人員を本来人間がやるべきことに注力することで、効率よく回そうという考えに至るのも当然な話です。

ただ、それが当然じゃないというのが困難なところで、少しずつカイゼンしていく必要があります。

経産省の方が "Digital or Die!" の発表で3つ挙げられていたのが

・ デザイン思考
・ アジャイルな開発
・ データ分析

UI/UXクソなのをデザイン思考でカイゼンする、アジリティ（素早さ）が足りていないのでアジリティのある開発をする、データを見ることでより正しい結果を導き出すといった取り組みが必要だとのことです。研修にも取り入れているのだとか。

例えば補助金申請システムの電子化では、改革をおこすのであれば、プライバシーが絡んでくる個人向けよりは、登記など情報が既に公になっている法人向けの方がテストケースとしてはより簡単で、マインドのカイゼンとしての一歩に適していたからとのことです。

経産省は、やるべきことをやろう、新しいことにチャレンジしようというマインドを持っているけど、どうしても省庁によっては温度感が異なるということで、彼らの「馬鹿踊り」が「馬鹿」ではない、本物のムーブメントになればいいなと思います。

神戸市の取り組み

govtech summit 2019 は神戸市の主催です。

・ ためまっぷ
・ Digiground
・ 「場のデジタル化」による個人の多様な働き方の実現
・ 孝行デマンドバス
・ 地域統合バスロケの整備実証実験
・ RPAツール Monstar Robo
・ 毎月手作業で行っているレセプトチェックの自動化実証

この中で個人的に興味深かったのがバスロケです。（ほかだと、レセプトチェックを機械学習で解決する話は技術的に興味のあるネタです）。

 バスロケーションシステム

バスロケは、バスにありがちな時刻表通りには運行できないという、バスあるある対策の1つで、今バスがどこにいるかをバス停やアプリ上で表示するというものです。

ところが、それぞれの運営会社ごとに異なるアプリが乱立していてとても不便です。かといって行政主導で何かの統一アプリを出しても人気が出るとは限らず、単に乱立を増やすだけになりかねません。

そこで行ったのが、アプリの統一は出来なくても、データ仕様が統一されてさえいればデータを扱うアプリを作りやすくなるし、オープンソースでやっていくことも可能なのでは？ということでした。

・ バスロケ世直し隊

とても素晴らしいのですが、これのオチとして、民間業者や国土交通省とのやりとりはうまくいったのだけど、神戸市バスではシステムの都合上、実証実験としては失敗だったということでした…。

失敗をちゃんと発表できるスタンスが、とても素晴らしいです。

govtechにおける課題

バスロケの実証実験では、バスの運行に関してステークホルダーが多すぎた、実証実験を行った課では裁量が足りない、やりとりが遅いなどの問題があったようです。

ぶっちゃけトークでは問題点として

・ スタートアップと自治体職員で考え方が違う
・ 透明性が足りない、説明責任が果たされていない

などが挙げられてました。

速度の問題

これはスタートアップにとっては死活問題で、スタートアップは時間との勝負なので、悠長にやっていたら簡単に資金が干上がります。スタートアップは、ある期間で成果を出さなければならない、時限付きの存在です。

ところが、行政という現在もっとも安定している組織で働いている人にとっては、スタートアップだろうが大企業だろうが「民間」として、ひとくくりに捉えてしまうそうです。

会議を行って「持ち帰って検討し二週間後に」みたいなノリだったそうで、アジャイルな開発やスタートアップとはとても相性が悪いところです。

短くマイルストーンを切って実証実験なり、スタートアップ支援なりしないと、スタートアップ自体が耐えきれません。

透明性の問題

エンジニアは、プログラミングというものと深く向き合っていて、その経験上、透明性という概念を大事にします。

たとえば、あるAPIを呼び出したのに、謎の理由ではじかれれば、「え？なんで？」となります。エラーメッセージ、ログ、プロトコル（仕様）、そういった部分で透明性が足りないシステムは、エンジニアから見ると「クソシステム」です。

「これだめです」といわれたときに、十分な説明責任が果たされていなければ、その後の意思決定に支障が出ます。速度との戦いであるスタートアップにとっては、速度を落とす要因となり、やはりこれも致命傷になりかねません。

組織の問題

問題を解決するためには、ステークホルダーを適切に巻き込み、他人事ではなく自分事に変えていく必要があります。

ところが行政には組織の問題が常につきまといます。

巨大組織・縦割り組織としての（民間にもある）問題だったり、行政固有の2年ごとに異動しなければいけない（つまり担当者が変わってしまう）という問題があります。

行政としては組織構造の改革、民間としては適切なプレゼンテーション、あるいは相互の橋渡しをする人材などが必要でしょう。

相互理解の重要性

経産省の方をはじめとして中央省庁の人、あるいは自治体の人、スタートアップやCode for Japan活動の人たち、みんな頑張っているという印象はありました。

経産省の方がしてた発表を聞く限りは、スタートアップ的な文化に理解を示し、それを尊重し、自らもちゃんと実践できているのだと感じました。

ただ、神戸市の件では、相互理解が足りていなかったのかなと？という印象が残ります。

コミュニケーションはお互いがいて成り立つものなので、どうしても相互理解を深めるしかありません。

行政の方は、エンジニアやスタートアップの文化を理解する必要があります。それはプロジェクトをうまく進めるためには必要ですし、不適切なスタートアップにだまされないためにも必要です。

スタートアップは、行政というものがどういうものか理解し、適切なプレゼンテーションをしなければなりません。

場合によってはスタートアップと行政の橋渡しをする人がとても重要になってきます。

ただコンサルタントみたいな立場の人が間に入るだけでは、スタートアップから見れば単に話し相手が変わっただけで、速度の改善どころかレスポンスを落とす存在になりかねません。

現場に入って必要なステークホルダーを巻き込み、行政・スタートアップ・本人が当事者として動けるような、プロジェクトマネジメントできる人が望ましいでしょう。

個人的感想

エンジニア、それもスタートアップにいるようなタイプの人は、暗黙知や属人性を嫌い、透明性、冪等性を良しとする文化があります。

govtech を進めていくならGitHubに、JSON SchemeなりRFCめいた仕様書があがって、問題があれば issue / PR で相談できるようなスタイルが一番望ましいと思っています。

ピザ2枚理論（Amazonのジェフ・ベゾスが提唱した、ピザ2枚を食べる人数くらいがプロジェクトには適切という考え方）も重要です。

ステークホルダーが増えれば増えるほど速度が落ちるので、人員が増えすぎてもだめですが、「行政側」と「スタートアップ側」が分かれている状況ではアジャイルな開発にはほど遠いです。

今の時代はリモートでやりとりできるので、物理的に離れていても密に連携することは可能です。もちろん物理的に同じ場所にいることが一番望ましいので、可能であれば一週間に一回くらいは物理的に同じ場所で進めていくべきかもしれません。

適切な課題の設定と、それに必要なチームビルディングが大切になります。

僕も同感で、働き方改革しようぜ、という気持ちです。

ほかに、話を聞いていて思ったのは、個々の開発を小さくし、全体として変化に対応出来る柔軟なスタイルに持って行かないとつらいのでは？というものです。マイクロサービス的な考えは検討すべきなのではと思いました。

まとめ

僕自身、行政の手続きとかめんどくさいと常々思い続けてるというか、特に今のようなシーズンにそう思うのですが、冒頭で述べたようなちょっとした縁が無ければ、govtech に興味を持つこともなかったと思います。

「知る」ということはとても大切だし、そのためには適切な情報発信が欠かせません。少しでもその助けになればと思い、このブログを書きました。

・ Code for Japan (medium / slack)
・ Code for Kobe

というような活動もあるようです。

govtechをとりまく動きはかなり面白いものです。働き方改革を（笑）で終わらせないためには、それぞれの立場でできることが色々あります。

アジャイルな開発が好きなエンジニアやデザイナがやれることがとても多く、僕自身興味深いなと思いました。今後、適切な活躍の場が増えるのではないか？と感じています。