GovOps: DevOps とガバナンス

これからのパブリックガバナンスや一部の領域のガバナンスにおいて、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では以下のような「三つの原則」を基に考えることができます。

1. フローの原則：ワークフローを高速にする
2. フィードバックの原則：フィードバックフローを実現する
3. 継続的な学習と実験の原則：企業文化を生み出す

これを既存のガバナンス（とりあえずパブリックガバナンス）に当てはめてみると、バリューストリームマッピングなどでワークフローを整理して、デジタル技術を使って既存の業務のワークフローを高速にする。センサーや Decidim 等を使ってフィードバックフローを実現する。継続的な学習と実験を行うなどなどです。

まとめ

今もまだ自分でも「どうかな」と自信なく思う部分はありますが、アジャイルガバナンスのレポートが出ていたので、アジャイルといえば DevOps かなと思い、それに合わせて書いてみました。実際、アジャイルガバナンスのレポートにおいては以下のような図がありますが、冒頭の DevOps (GovOps) の図と類似性があるように思います。

昔書いた xOps というスライドの中にも実は GovOps を入れています。

粗いアナロジーが中々そんなにうまくいくことはないとは思いますが、とはいえ DevOps の考え方は今後のデジタルガバメントの議論や各企業のDXの中で一つの参考になる概念なのではないかなと思っています。

xOps: エンジニアがスタートアップの成長の原動力となる日 from Takaaki Umada

www.slideshare.net

コロナ後のアクセラレーター環境の変化

コロナウィルスとそれによる感染症である COVID-19 による変化は、スタートアップやその周辺のエコシステムの一部を変えると考えています。

もちろん変わらないもの、一度変わって元に戻るものも多数あると思いますが、私自身に影響がありそうなもので、今起きている変化でしばらく定着/影響しそうなものをいくつか挙げてみます。

オンラインアクセラレーターの増加

今後、オンラインのみのアクセラレーターの数は増えるのではないかと思っています。

たとえば、https://pioneer.app/ など、もともとリモート専用のアクセラレーターがありましたが、今回のCOVID-19による強制的なオンラインへの移行で、プログラムの提供だけであればオンラインでできる部分がある、という実感を得られた事業者の方々も多いのではないかと思います。その影響で、今後はオンラインを中心としたアクセラレーターが日本でも世界でも増えてくるのではないでしょうか。Y Combinator なども続々とオンラインコンテンツを増やしてきています。

日本にいたとしても（英語などのほかの言語ができれば）リモートのアクセラレーターに参加することができる、というのは起業家にとってはとても良い変化です。一方、アクセラレーター運営側の視点に立ってみれば、世界中に競合がいるようになります。その競争を勝ち抜くのか、もしくは巻き込まれたくないのであれば、ローカルやオフラインの独自の価値をどのように出していくかが勝負のポイントとなりそうです。

スタートアップの数の減少

私の聞いている範囲では、起業家の数が減少しつつあります。実は4月や7月ごろはそれほどそうした話は聞きませんでした。しかし最近になって、案件が減っているという話を聞き始めています。

感染拡大期に起業家の数がすぐに減らなかったのは、すでに準備済みの起業家が多かったからかもしれません。ただそのプールが尽きつつあるのではないかと考えています。たとえば 2007 - 8年の金融危機のときもビジネスに如実に影響が出てくるのに半年程度かかったと聞いています。同程度の遅延があるとすれば、そろそろ来るタイミングです。

一方、2008年の経済環境との違いは、実体経済が傷ついていることや、スマートフォンなどの目立ったトレンドがないこと、そして人と会えないということによるアイデアや共同創業者探しの難しさなど、新しいことを始めるには少し難しい環境だということです。

仮にビジネスを始めたとしても、リモートワークで行う場合、新しいアイデアの探索などには向いているようには思えませんし、実際にコンテストなどを見ていても昨年などに比べると、アイデアの質が相対的に見て下がっているように感じています。これはオフライン環境での壁打ちなどができなくなっていることなどが実は大きいのではと思っています。

もちろん既につながりがある場合や探索より深化 (exploitation) のフェーズの場合はリモートワークでもある程度進むことができるとは思いますが、アイデアを固める段階やピボットを何度もしなければいけない状況では、リモートは難しいでしょう。

逆に言えば、本当に良いスタートアップには資金が集まりやすくなるとは思います。その結果、アクセラレーターを経由するスタートアップはもしかしたら減るかもしれません。

そのうえで

こうした変化を想定したうえで、支援側として何が本当のバリューだったのかをきちんと考えていかないといけないなと思っています。まだその答えは見えていませんが、引き続き考えていきたいと思います。

スタートアップのセールスパイプライン管理

スタートアップの初期のセールス活動において、「〇件の受注」といったゴールにしようとしたとき、どうしてもゴールとなる案件数はかなり小さくなります。場合によっては「今期は1件の100万円以上のLOI獲得」という「1案件のWin」がゴールになるかもしれません。

しかしそのような設定をしてしまうとゴールの達成率は「ゼロか1か」になってしまい、進捗の管理ができません。進捗が管理できなければ本当にゴールを達成できるのかどうか予想できないですし、進捗が見えなければチームのモメンタムの維持も難しくなります。

そこでKGIとして「今期は1件の100万円以上のLOI獲得」と置いたときには、重みづけされた金額や案件数をKPIにして、進捗を管理していく方法があります。

セールス経験者にとっては基本的なやり方ですが、セールス経験のない方々はあまり知らないようなので、簡単に解説しておきます。

基本的な計算式

金額や案件数をセールスステージで重みづけして進捗を計算します。ただしこの重みづけされた予想金額自体をゴールにするのではなく、あくまでKGIに対するKPIという位置づけのほうが良いと思います。ゴールは実際の売上で、それを達成せずにKPIを達成しても意味はありません。これはあくまで進捗確認用のものです。

金額ベースの場合

見込み案件の金額　×　セールスステージ　＝　予想金額

予想金額の合計がKPIになります。

案件数ベースの場合

見込み顧客の案件数　×　セールスステージ　＝　予想案件数

予想案件数の合計がKPIになります。

Google Sheet での管理

こうした案件管理に時間を多く割くべきではありません。なので最初は Google Sheet などでも構わないと思います。あとでどうせ変わります。以下のような簡単な表を作るところから始めてみてください。

計算例

もし2020年第3四半期のゴールが「500万円以上の案件受注」だった場合、上記の表の案件を見てみると、2020年第3四半期の金額ベースのKPIの計算は

• A社 100 万円 × 10%
• B社 200万円 × 50%
• C社 130万円 × 20%
• D社 400万円 × 40%
• E社 300万円 × 20%
• F社 100万円 × 50%

で、310 万円となります。（※線が引いてあるのは9/30までにクローズしないため計算から抜きます）

なので、現時点では 310/500 = 0.62 (62%) がKPI上の進捗率となります。

案件数ベースで「2件以上の100万円以上の案件受注」であれば、50%+40%+50%=1.4件です。なので 1.4/2 = 0.7 (70%) の進捗率となります。

CRM での管理

Google Sheet ではなく CRM を使うという手もあります。

とりあえず HubSpot CRM （無料）を入れて、Outlook もしくは Gmail のアドインをインストールすれば、すべてのメールログとコンタクト先が HubSpot CRM 上に溜まっていきます。案件管理もそのコンタクト情報に紐づけることができたり、他のチームメンバーと案件の進捗状況がシェアできるので管理は楽になります。（ただし面倒そうであれば迷わず Google Sheet を使いましょう。面倒でCRMがアップデートされなくなると意味がありません）

また、画面上のメニューの [レポート] -> [ダッシュボード] から「セールス」テンプレートのダッシュボードを作り、「ステージ別の取引種駅の予測」のレポートの設定を「今四半期」にしておけば、四半期のForecastを自動的に取ってくることができます。

セールスステージの定義

自社のセールスサイクルやプロセスに合わせて設定するべきですが、まだそうしたサイクルなども分かっていなければ、とりあえず仮説ベースで設定しましょう。個人的にはアポが取れて10%、決定権者にデモができてようやく40%かなーという印象です。

HubSpotを使う場合、HubSpot 標準のセールスステージを使うのも良いかもしれません（ただ標準のものはちょっとざっくりしすぎのような気もしますが）。個人的には0%のステージを作っておいて、アタックリスト（コンタクトする予定のリスト）のステージも入れておくと良いかなと思います。

ゴールから必要な案件数を逆算する

ゴールとなる金額や案件数を基に、何件の見込み顧客が必要なのかを逆算してみてください。

これまでの感覚としては、1件のWinに対して、30件はコンタクトをするぐらいがちょうど良いのかなと思います。コールドメールだとそのうち1/5にアポが取れれば良いほうです。それらに加えて既存のつながりをうまく活用すれば、このコンバージョンはもっと高くなると思いますが、それでもたぶん10件にアポが取れるかどうか、というチームが多いのではないでしょうか。

そのほかの情報

HubSpot によるパイプライン管理の記事も参考にしてください。

動画でも簡単に解説しています。

www.youtube.com