GovOps: DevOps とガバナンス

Governance as Code
GovOps
GRE
GovOps に向けて
まとめ

これからのパブリックガバナンスや一部の領域のガバナンスにおいて、DevOps ならぬ GovOps というものが考えられるのかなと思っています。

f:id:takaumada:20210221085933p:plain

デジタル庁の設立や行政機関の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を導入する」など、官僚業務のデジタル化にまつわる各施策の位置づけが分かりやすくなります。

GRE

またSRE (site reliability engineer) 的な考え方で、GRE (governance reliability engineer) といった類似も考えられます。

SREの考え方で使えるのはエラーバジェットとトイルでしょう。エラーバジェットはエラーの許容可能範囲を決めておき、その中でリスクを取って新しいことに慎重にチャレンジできる仕組みです。またトイルは頻繁に起こる自動化可能な手作業のことを指します。

SREであればエラーバジェットは通常アップタイムを基に行われます。行政機関の場合は適切なKPIを決める必要がありますし、当然、エラーが許容できない領域もあるため、すべてに応用できるわけではありません。ただ新たな挑戦ができる余白を作るための考え方として、一部で応用はできるのではないでしょうか。

またトイルの年間削減数を決めるのも一つのやり方でしょう。行政の作業はトイルが多そうなので、これを削減することで、本来の住民サービスやヒアリングなどに時間を使うことができるようになるでしょう。こうした効率化はもともとやっていたことだとは思いますが、トイルという名前がつくとちょっとやりやすくなるのかなと思います。

GovOps に向けて

こうしてGovOpsというものを考えてみると、これまでDevOps界隈で培ってきた考え方はガバナンスにおいてもある程度使えるかもしれないと思います。

たとえばDevOps は文化であり、プラクティスであり、ツールであることはしばしば繰り返されますが、ガバナンスのデジタル化とは単にツールに留まるべき話ではないでしょう。

またGovOpsの改善に際しても、たとえばDevOpsでは以下のような「三つの原則」を基に考えることができます。

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

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

まとめ

今もまだ自分でも「どうかな」と自信なく思う部分はありますが、アジャイルガバナンスのレポートが出ていたので、アジャイルといえば DevOps かなと思い、それに合わせて書いてみました。昔書いた xOps というスライドの中にも実は GovOps を入れています。

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

なお、Governance as Code もしくは Governance by Code が行われる場合、たとえば帰納的な推論が必要な部分では、いわゆるAIが使われるようになるかもしれません。そうなってくると、AI が差別をしないかといった問題はより重要な問題になってくると思います。またコード化に応じたリスクも色々発生するため、そのあたりの対処も必要になるでしょう。そのあたりについてはまた。

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

www.slideshare.net

2020-09-09

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

トレンド

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

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

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

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

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

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

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

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

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

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

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

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

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

そのうえで

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

2020-07-09

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

セールスツール

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

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

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

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

基本的な計算式

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

金額ベースの場合

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

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

案件数ベースの場合

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

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

Google Sheet での管理

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

f:id:takaumada:20200709100446p:plain

計算例

もし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がアップデートされなくなると意味がありません）

f:id:takaumada:20200709102427p:plain

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

f:id:takaumada:20200709103506p:plain

セールスステージの定義

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

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

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

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

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

f:id:takaumada:20200709115038p:plain

そのほかの情報

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

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

www.youtube.com

2020-04-20

企業文化のバリューは信条から行動へ

Ben Horowitz の「Who You Are - 君の真の言葉と行動こそが困難を生き抜くチームをつくる」が発売されました。原題は「What you do is who you are」であり、「あなたの行動があなたを表す」と訳するべきでしょうか。

本書で Ben Horowitz は企業文化を「従業員の判断基準」だと言い、「行動」を中心にした企業文化の捉え方を提示しています。そして企業理念ではなく、行動規範を作ることを重視しています。

トップがいないところで人々がどんな判断をするかこそが、企業文化というものだ。社員が日々の問題解決に使う一連の前提が、企業文化だ。誰も見ていないときにどう行動するかが、企業文化なのだ。

侍は武士の原則を「価値観（バリュー）ではなく、「徳（バーチュー）」と呼んでいた。徳とは行いであり、価値観とは単なる信条だ。この本でも書いているように、行いこそ影響力がある（ここからは、理想形を「行動規範」と呼び、ほとんどの企業が掲げている信条を「企業理念」と呼ぶことにする）。

こうした行動の重視は近年の日本のスタートアップにおけるバリューの質の変化をうまく表しているように思います。

日本でも近年、スタートアップが自社のカルチャーやバリューを公表して、採用を促すことが増えてきました。従来の大手企業では「Trust」や「Integrity」、「Transparency」や「Honesty」など、単語で重要視する信念を表すことが多かったように思いますが、最近のスタートアップのバリューはもう少し文字数が増えている傾向にあります。

そうした文字数の増加という量的な変化の裏には、バリューの内容に関する質的な変化もあると考えます。それは「行動を促すバリュー」になってきている、という点です。つまり、本書と同じく、バリューに対する信条から行動への変化がその裏にあるのではないでしょうか。

もちろん、従来もバリューの中に行動規範が含まれるケースも多かったと思います。ただ最近ではそれぞれのバリューに「具体的な行動の例」が付記されることも多くなってきているように思いますし、またそうした行動を誘引するような「ルール、プロセス、制度」（評価制度含む）を各社が用意しているようです。

事例を見ながら少し振り返ってみます。

事例

海外の各社の事例はたとえばこのページに、日本の各社の事例はweareでまとまっているようです。その中からいくつか取り上げてみたいと思います。

Salesforce

比較的古い企業に属するSalesforceはTrust、Customer Success、Growth、Innovation、Giving Back、Equality for All、Wellbeing、Transparency、Funと単語が並んだ形のバリューとなっています。

Adobe

Adobe も比較的古い企業ですが、Genuine、Exceptional、Innovative、Involvedと単語です。

Airbnb

比較的新しい企業と言えるAirbnbはBe a host、Champion the mission、Be a cereal entrepreneur、Embrace the adventureと少し文のようになっていて、「Be a cereal entrepreneur」のようなちょっと引っ掛かりのある（説明が必要な）バリューが含まれているのが特徴的です。

Twilio

Twilio もまだ比較的新しい企業です。特徴的なのは10つのバリューを「行動」「意思決定」「どうやって勝つか」の3つのカテゴリに分けている点でしょう。「行動」の部分ではBe an owner、Empower others、No shenanigans、「意思決定」の部分ではWear the customer’s shoes、Write it down、Ruthlessly prioritize、「どうやって勝つか」の部分ではBe bold、Be inclusive、Draw the owl、Don’t settleとなっています。

マネーフォワード

本書の推薦文を寄稿されている辻さんが創業されたマネーフォワード社は、バリューを「行動指針」と訳し、「User Focus」「Technology driven」「Fairness」とされています（代表メッセージのページ）。ここではバリューを価値観や信念ではなく、行動だとされています。

メルカリ

メルカリ、メルペイはしばしばその企業文化やバリューが記事にもなります。3つのバリュー、「Go Bold」「All for One」「Be Professional」は信念に近いものの、Go Bold は迷ったときの行動の判断軸になるものでしょう。

余談ですが、「Go Bold」のような行動指針、「Be 〇〇」で理想状態を示すこと、そしてチームに関するバリュー（All for One）、という3つの構成は分かりやすくて真似しやすいなと思います。

atama+

カルチャーに投資しているという記事が上がるatama+社ですが、最初にバリューを「Wow students」と置き、そのうえで大切な行動として「Think beyond」「Speak up」「Love fun.」を設定されています。行動、という明示をされている点がここでもマネーフォワード社と似ています。

SmartHR

採用スライドの先駆けともなったSmartHRでは、「自律駆動」「早いほうがカッコイイ」「最善のプラン C を見つける」「一語一句に手間ひまかける」「ワイルドサイドを歩こう」「人が欲しいと思うものをつくろう」という風に、どのような行動をとるべきか分かりやすいバリューが設定されているように思います。

ミラティブ

同じく採用スライドが多く取り上げられたミラティブ社では、ミラティブのカンパニーページで、「期待を超え続ける」「スキルを磨き続ける」「深い愛を抱き続ける」「常識を超え続ける」「そして楽しみ続ける」という5つのバリューを掲げています。これらも特定の行動を促すバリューに近いでしょう。

10X

タベリーを運営する 10X 社は、「10x から逆算する」「自律する」「背中を合わせる」という3つのバリューが、具体例 (Do's) とともに紹介されています。24ページ目から、バリューが策定された背景も含めて解説されている珍しいドキュメントです。

speakerdeck.com

CADDi

バリュー自体は「大胆」「卓越」「一丸」「至誠」と単語をベースとしたものですが、すでにカルチャーブックを作り、そちらで行動指針をまとめているところが特徴的なように思います。

speakerdeck.com

FoundX

FoundX での私たちのバリューは以下の 3 つにしています。

⭐ 良い模範であろう
🪑 HRT💕とともにテーブルの同じ側に座ろう
🧪 エビデンスとともに実験をしよう

（絵文字もつけてます）

こうしたバリューは実行に密接に結びつくと感じている次第です。たとえば以下はまだ書きかけですが、私たちの活動システムマップ（解説）であり、こうしたバリュー一つ一つが付加価値を加える活動を強化するように動くのだなと感じています（もちろん、逆に弱めるところもありますがそれはトレードオフだと思っています）。

f:id:tumada:20200420132711j:plain

ルール、プロセス、制度

行動を縛るという点ではルールやプロセス、制度も一つのやり方です。

そのための本書からの有効なアドバイスの一つは、「ショッキングなルールをつくる」というものでしょう。

たとえば起業家とのミーティングに1分遅れたら10ドル支払う、というようなa16zのルールは、「起業家への尊敬を持つ」というバリューを書くよりも、よっぽど分かりやすくその行動を促してくれます。Amazonの「パワーポイントの禁止」も、Amazonでのドキュメントを重視する文化に寄与しています。それと同様に、印象に残るバリューやルールを各社が考えるようになってきているように思います。

先日の Coral Capital の西村さんが書かれた『「フクロウを描け」と会社のバリューに書く理由』という良い記事がありましたが、おそらく少し解説が必要なルールやバリューを入れておくと良いのでしょう。そして毎日使うようなバリューが良いことが本書では指摘されており、確かに…と思った次第です。