これからのパブリックガバナンスや一部の領域のガバナンスにおいて、DevOps ならぬ GovOps というものが考えられるのかなと思っています。
デジタル庁の設立や行政機関のDX、企業のDXなど、デジタル技術がいよいよ社会の中に本格的に組み込まれようとしています。DXという名のソフトウェア導入に留まる論もあれば、DXによるサービスや UX の改善、DXによる業界全体の変化を示唆する論などなど様々な論があります。
ただ個人的には、DXは「仕組み」の転換こそが本丸であり、より具体的には制度やシステムなどの『補完的イノベーション』（ブリニョルフソンら）が重要ではないかと考えています。このあたりは最近出した『未来を実装する』を参照していただくとして、なぜ GovOps なのかについて今回はお話しします。
Governance as Code
現在、デジタル技術によって Ops (Operations) が単に効率化されるだけではなく、法律やルールのDev (Development) 自体が変わってきつつあります。
ガバナンスイノベーションやアジャイルガバナンスなどで指摘されるように、デジタル技術はルールの運用を効率化するだけではなく、ルールの作り方自体を変えることができます。
たとえば国がドローンのプラットフォームを管理するようになった場合、ドローンの航空可能地域をリアルタイムに変えることができるようになります。その結果、法律で事細かに制限区域などを決める必要はなくなるかもしれません。また工場やエレベーター等でこれまで人が行っていたような点検を、センサーを使ったリアルタイムのモニタリングに変えることができれば、人による定期的な点検はの点検期間をもう少し長くできる可能性もあります。これまで1年おきだった点検を3年ずつぐらいにできるかもしれません。最近だと、eKYC はデジタル技術によって、これまでと異なる本人確認ができるようになった例でしょう。これらはデジタル技術によって運用方法が変わり、その結果ルールの作り方も変わったという例です。
オペレーションがコードによって効率化されていき、そもそもの作り方も変わる。これは IT の世界で 10 年ほど前に起こった Infrastructure as Code / Operations as Code の流れと似ています。インフラやオペレーションがコードによって定義・運用されることにより、インフラがプログラム可能になり、それによってDevの在り方も変わるというものです。
これをガバナンスの文脈に当てはめると、Governance as Code もしくは Governance by Code が起こりつつある、とも考えられないでしょうか。
GovOps
IT の世界で Infrastructure as Code / Operations as Code の流れと並行して、互いに影響しながら起こったのが、Dev と Ops の再統合でした。これがDevOps です。これをガバナンスの文脈で考えると、GovOps というものがあるかもしれません。
官僚のある種の製品が「法律」であれば、そのデプロイを早くしながらも安定的な運用を行う、というのは DevOps の狙いと似ています。
実際、アジャイルガバナンスなどで取り上げられる「規制のサンドボックス」は DevOps の段階的ロールアウトと捉えることができます。敏捷性を確保するための仕組みはおそらく類似してくると考えると、DevOpsのやり方はパブリックガバナンスやコーポレートガバナンスのこれからを考えるうえでの一つの参考になるのではないかと思います。
とはいえDevOpsを真似て「法律や条例のデプロイ回数を一日10回にする」というのはさすがに社会に混乱が生じすぎますし、ITシステムと違って法律は一般的に「巻き戻し」が難しいためそのまま真似をするのは避けた方が良いと思います。ただデジタル技術によって法案成立から運用、サービスワークフローを最適化することによって、一年に提案できる法案の数を増していくことができれば（そして国会において透明性高く・効率的に審議することができれば）、社会の変化に対して敏捷性の高いガバナンスが可能になるかもしれません。
と、同時に、「法律のデプロイ回数のために既存の法案のチェックにAIを導入する」など、官僚業務のDXにまつわる各施策の位置づけが分かりやすくなります。
GRE
またSRE (site reliability engineer) 的な考え方で、GRE (governance reliability engineer) といった類似も考えられます。
SREの考え方で使えるのはエラーバジェットとトイルでしょう。エラーバジェットはエラーの許容可能範囲を決めておき、その中でリスクを取って新しいことに慎重にチャレンジできる仕組みです。またトイルは頻繁に起こる自動化可能な手作業のことを指します。
SREであればエラーバジェットは通常アップタイムを基に行われます。行政機関の場合は適切なKPIを決める必要がありますし、当然、エラーが許容できない領域もあるため、すべてに応用できるわけではありません。ただ新たな挑戦ができる余白を作るための考え方として、一部で応用はできるのではないでしょうか。
またトイルの年間削減数を決めるのも一つのやり方でしょう。トイルとはいわば「人間がやらなくても良い苦労」です。行政の作業はトイルが多そうなので、これを削減することで、本来の住民サービスやヒアリングなどに時間を使うことができるようになるでしょう。こうした効率化はもともとやっていたことだとは思いますが、トイルという名前がつくとちょっとやりやすくなるのかなと思います。
GovOps に向けて
こうしてGovOpsというものを考えてみると、これまでDevOps界隈で培ってきた考え方はガバナンスにおいてもある程度使えるかもしれないと思います。
たとえばDevOps は文化であり、プラクティスであり、ツールであることはしばしば繰り返されますが、ガバナンスのデジタル化とは単にツールに留まるべき話ではないでしょう。
またGovOpsの改善に際しても、たとえばDevOpsでは以下のような「三つの原則」を基に考えることができます。
- フローの原則：ワークフローを高速にする
- フィードバックの原則：フィードバックフローを実現する
- 継続的な学習と実験の原則：企業文化を生み出す
これを既存のガバナンス（とりあえずパブリックガバナンス）に当てはめてみると、バリューストリームマッピングなどでワークフローを整理して、デジタル技術を使って既存の業務のワークフローを高速にする。センサーや Decidim 等を使ってフィードバックフローを実現する。継続的な学習と実験を行うなどなどです。
まとめ
今もまだ自分でも「どうかな」と自信なく思う部分はありますが、アジャイルガバナンスのレポートが出ていたので、アジャイルといえば DevOps かなと思い、それに合わせて書いてみました。実際、アジャイルガバナンスのレポートにおいては以下のような図がありますが、冒頭の DevOps (GovOps) の図と類似性があるように思います。
昔書いた xOps というスライドの中にも実は GovOps を入れています。
粗いアナロジーが中々そんなにうまくいくことはないとは思いますが、とはいえ DevOps の考え方は今後のデジタルガバメントの議論や各企業のDXの中で一つの参考になる概念なのではないかなと思っています。
www.slideshare.net
