意思決定プロセス(プロリク)
🚵‍♂️

意思決定プロセス(プロリク)

変更履歴

変更履歴
  • バルスによりα版開発完了 2018/10/28
  • β版開発完了 2018/11/5
  • β版リリース 2018/11/15
    • 希望すれば、あらゆるメンバーが意思決定を行うことができる形に変更
    • 2019/3/31までに80%以上のメンバーに体感として理解、浸透させる
  • 2019/5/7 意思決定の例外を2つに変更
  • 2019/8/26 アルバイト採用を代表取締役決済対象に追加
  • 2019/10/23 プロポーザル雛形に金額を追記し、リンク添付の要望も記載
  • 2020/5/26 プロリクの雛形について背景・目的を必須項目として標準にした。一方で効果については直感でも良いとした(直感プロリク)
  • 2021/3/16 JIKKENプロリクについては、挑戦行動を称賛する為、レビューのガイドラインを定めた
  • 2021/4/25 即時プロリクを定義した
  • 2021/5/13 事後プロリクを定義

動画説明

背景・目的

  • 簡単に言えば「やる人が決める!決めたらやる!」但し「やる前に相談してちょ♩」という事
以下は詳細の背景
  • その結果、自己組織化された組織にして、1000名の組織になっても、Quality&Agilityをより高めたい
  • 一方でゆめみの業務は関わるサービスの規模が大きく、影響範囲・影響度も大きいので、安定して高い品質を出すためにはプロジェクト毎に、役割分担、責任範囲、プロセス、ルールが細かく定められている
  • したがって、「やってみなはれ」と言われて、自由に何かを変えようとすると、暗黙・形式のルールによって「やってはいけない」となってしまう
  • 実際に、10年前までは、それによって心理的にダブルバインドという状態が発生する事があった
  • つまり、暗黙、形式含めて、ルールに基づいて業務が細かく定められている以上、「やってみなはれ」として何かを変えようとすると、既存のルールを変えないといけないのである。
  • その際に問題になるのが、ルールを変えるルールは何?という問題である
  • 多くの会社では購買の金額毎に決裁者は決まっているが、現場業務のルールについての決裁者は曖昧になっている事が多い。
  • ルールを変えるルールを明確にしなければ、暗黙・形式の現場ルールを変えることはできないと気づいて、ゆめみでは明確にルールを決める(変える)ルールを定めた
  • 実際にはそのルール作りにとても苦労したが、ある時、書籍「ティール組織」における「助言プロセス」を知る事になり「これだ!」となり2018年10月に導入をした
  • ゆめみでは助言プロセスをエンジニア文化で浸透している「プルリク」になぞらえて「プロリク」と名付けた
  • 一方で、エンジニアとは異なる思考性を持つ人については、あまり細かな手順に捉われず、直感的に周りの人がやるやり方を観察して真似て自分なりに応用までできてしまう人もいる
  • そういった人は、本ドキュメントは深く読む必要はない可能性がある事を言及しておきます

対象

  • メンバーオプション契約対象の社員
  • メンバーオプション対象外の社員は、就業規則・職務権限規定に基づいて承認が必要

意思決定プロセス概要

  • プロリクにより、あらゆる意思決定をコミッターが行うことができる
    • 但し、意思決定を行うには、それぞれのチームのコミッターになる必要がある
  • 制度としては、代表取締役の権限を全て、事前に(社員ではなく)メンバーに移譲する形で実現する
    • 意思決定の例外としては「採用」「勤怠」は代表取締役が承認を行うものとする
  • プロポーザルを提示して、ステークホルダーからレビューを受けた本人は、最終的に決議する意思決定内容としては、レビュー内容の中から、必要なものだけ取り入れて意思決定を行うことができる
    • 全ての意見を取り入れる必要はない、あるいは全て取り入れなくても良い
  • 意思決定を行った本人は、遂行責任を負う

意思決定可能な具体例

  • オフィスの新設・移転
  • 社内制度・ルールの立案・変更
  • 新規サービスの立案
  • 研究開発の実施
  • 借入・投資の実施

などあらゆる意思決定(後述の意思決定の例外を除く)を行うことができる

プロリクの定義

プロポーザル・レビューリクエスト(Proposal Review Request)の略称

プロリクとは

  • コミッターがステークホルダーにレビューを受ける事で「プロポーザル」のコミットを自身で行う意思決定方法
ティール型組織における「助言プロセス」を採用する 参考)ティール組織について https://nol-blog.com/what_is_teal_organization/  参考)動画 https://youtu.be/gcS04BI2sbk

レビュー方法

  • 意思決定の内容について、レビューを求められた人は、原則48時間(2営業日という意味)以内にレビューを行うあるいはレビューができる期限を示す
  • レビューがない場合については何も問題ない(No Problem)を意味するとして、意思決定を進めることができる
  • 意思決定について、否決をする事はできない
    • 否決、リジェクトというフローはない
    • 一方で、反対意見を出すことはできる

プロポーザルの雛形

🎣

背景・目的は必須とする事を標準とする

期限(Time limit)   レビューを受け付ける期限日。これを過ぎるとプロリク完了となる。

背景(Background)   なぜ、その提案を行うに至ったかの背景や経緯

目的(Objective)   何のためにその提案を実施するかの目的や意図

提案(Proposal)   提案や意思決定の骨子

効果(Effect)   提案を行うことによるメリットや効果、狙い、理由などを示す

💁🏻

効果については定量的に示せなくても良い。 また、直感的にそう信じているなどという内容でも良い(直感プロリク

金額(Cost)   購入・購買・稼働等が伴う場合に記載

参照リンク(Link)   購買を伴うプロリクの場合リンクを貼る事により

 購入物のイメージがしやすくなり、競合品との比較がしやすくなる

レビューの雛形

Pros(賛成)   良い点、提案の賛成できる点、メリット、応援の言葉、LGTM、shipit Problem(問題)   問題点、ネガティブなリスク、悪影響 Protect(防御)   問題点の解決方法、リスク回避策、悪影響を最小化するアイデアとしての対案

例)Problem・Protectは省略可能。Prosのみの場合、LGTMなどと簡易的にレビューすることもできる(LGTMはGitHubという開発文化から来ている)

JIKKENプロリクのガイドライン

JIKKENには称賛を
  • 実験的に行う挑戦行動については、「JIKKEN」というキーワードをSlackで記載する事
  • また、JIKKENプロリクについてのレビューについては、実験への試み、挑戦行動、発想に対して、まず最初に「称賛」「賛辞」「尊敬」の意を伝えた上で、懸念点、リスク事項の指摘、ツッコミを行うこと
image
image

フローチャート

image
image

コントリビューターや外部チームのコミッターは意思決定を行うことができないため、権限を持つコミッターに対して、プロポーザルを作成してプロリクを実施してもらうことを提案することになるこの場合は、下記のように「プロポーザル」として提示する

image

 上記のポイントとしては

  • 相手の行動は変えられないので、コントリビューターは、提案によって相手の行動が変わることを期待しすぎてはいけないこと
  • コミッターは、コントリビューターから実施要求があったプロポーザルを実施しない、という選択肢をとることもできる。
    • その場合、プロポーザル要求に対して感謝はするが、理由を回答する必要は必ずしもない
  • コントリビューターからのプロポーザルをコミッターが実施する場合は、やらされたのではなくて、自身の意思として実施することを意識すること

即時プロリクのガイドライン

内容

  • プロリク時に「即時プロリク」と表記する事で、即時にコミット(本番反映)した事を意味する
  • レビューは即時のコミット後も受け付けることになる
  • コミットした後に、内容を修正する場合は、修正内容を都度、即時プロリクし直す事

備考

  • 48時間以内は、コミットした内容が本当にその内容で良いか、コミッター自身も本番の状況やレビューに注意を払う事をガイドラインとする
  • 即時プロリクは、コミットを即時に行うだけであり、関係者へのレビュー依頼を省略できるわけではない

対象外

  • 全社に影響あるプロリクは即時プロリクの対象外とする

事後プロリクの位置付け

  • 何かの事情でプロリクの内容が実施された、行使された、購買された後に事後でプロリクを行う場合がある
  • 事後でプロリクを行うことは可能である
  • ただし、事後プロリクを行う場合は、即時プロリクを行うことはできない
  • また、事後プロリクにおいて48時間以内のレビュー期間中に、その事後プロリクを無効化するプロリクが他のコミッターから出された場合に、事後プロリクが無効になる場合がある

意思決定の例外

誰もが意思決定を原則行うことができるが、以下の2つは例外として定める

1. プロパー・アルバイト採用(Recruitment)

プロパー・アルバイトの採用の決定は代表取締役のみが行う

2.その他

  • 「特定の人の承認を必要をする」と、過去のプロリクにより既に定められている事項
    • 主に職務権限規定で定める決議事項(購買、見積、押印、契約など)
  • 取締役会決議事項

補足

勤怠(コアタイムの欠勤・深夜休日出勤・休暇取得)に関する承認は、管理やシステムの都合上、プロジェクトマネジメント担当がZACで行う。一方で、あくまで意思決定は、本人がチームへのプロリクで行うものとする。

全社サービスのリリースプロセスのガイドライン

  • メンバー全員に影響あるような制度変更などについては、メンバーが全員参加している 000_proreq_all のSlackチャネルでレビューをもらうこと
    • その際には、@channel のメンションをつけて、全員に通知がいくようにする
    • 但し、いきなり全メンバーにプロリクを出す前に、提案内容に関連あるチームに最初にプロリクを行い案を揉むのが良い
    • 開発に例えると下記のようにまずは開発環境で草案をレビューしてもらって案の制度を高めていくのが良い
  • 正式リリースは 000_announce_all に周知を行う事で実施される
    • また、その際は可能な限り、ビジュアルデザインを工夫した画像を添付して、内容が伝わる様に意識する事。チラシのようなイメージ。
    • この際に@channel のメンションをつける場合は、いったん投稿した後に、編集する際にメンションを付けると通知は飛ばずに、バッヂが付くだけになるので配慮することになる
    • image
  • チーム、プロジェクトの状態が、サバイバルモードにあったり、危機的な状況であれば、最初に、意思決定プロセスとして、原則、レビューを省略した「トップダウン」に変更しますという、「意思決定プロセスの変更を行う」という意思決定を関わるチーム・プロジェクトメンバーからのレビューをもらって実施することがのぞましい。
  • チーム・プロジェクトがサバイバルモードにある状況というのは、根本原因を取り除くために、トップダウンアプローチが必要なことが多いためである。
  • 専門的な知恵を持つ人がいなければ、社外の専門的な有識者にレビューをもらうことも可能

取締役会決議事項の意思決定プロセス

  • プロリクという意思決定プロセスは会社法を無視するものではない。つまり、取締役会決議事項については、取締役会決議が必要である。
  • 取締役会は会社を守るためのゲートウェイとして、反対決議は行う事ができる事に変わりはないし、そういったゲートウェイの機能は経営が暴走しない意味で必要である
  • ただし、意思決定のAgilityを担保するため、以下を工夫する
    • 毎月開催される取締役会の開催を待って、承認決議を得るプロセスは取らなくて済むことができる
    • 具体的には、この範囲であれば反対しないという「反対しない範囲」を事前に決議をとるプロセスを進める
      • プロセスの機動性を高めるため、みなし取締役会を定めて、電子的な取締役会決議を行えるようにする事も今後あり得る(実際には事前に決議を取るような場面が少なく優先度が低い)
    • 事前に決議をとった後、事前に取締役会で承認された「反対しない範囲」で、メンバーが意思決定を行うことができる(つまり取締役の意思決定ではなく、本人の意思決定となる)
  • 例としては
    • 広報の年間投資予算を取締役会として反対しない範囲を決議するなどのプロセスが考えられる
      • 年間3000万以下を決議しておく
      • これは即ち、一般的な予算についての承認を得るプロセスと近い

意思決定ルールの理論的背景(承認がない意味)

  • あらゆる意思決定ができるとは、制度運用のテクニカルな観点で言えば、代表取締役の権限を全て事前に(社員ではなく)メンバー全員に移譲していると位置付けられる
  • 「メンバーのあらゆる提案を承認する」という何でも提案が通るということと、「メンバーのあらゆる提案を(レビューをもらった上で)自身の権限で意思決定する」ということは同じようで異なる
  • 何が異なるかといえば、前者はあくまで責任者が権限を持っており承認をした人は責任者である。その場合の意思決定の起因は責任者に由来する
  • 一方で、後者の意思決定の起因はメンバー本人に由来する。ここに大きな違いがある。
    • 組織という狭いコミュニティにおいて、自らが意思決定した内容に沿って、一貫した行動をとる事が期待されるため、遂行責任が働きやすくなるためである
    • この背景には一貫性の原理と呼ばれるものがある(一貫性の原理とは

FAQ

コンセンサスとの違いは何ですか?
  • コンセンサス(合意)なプロセスは、誰が意思決定をしたかの所在が曖昧になりがちであり、結果として意思決定をした人のコミットメントに繋がりにくい
  • プロリクは、誰もメンバーの意思決定に対して反対をすることができないのが特徴
  • なぜ反対ができないかというと、代表取締役の権限を持っているので反対ができない
  • ステークホルダーからのレビューをもらうが、意思決定に対して反対を強いられることはないので、コンセンサスとは違って意思決定が早い
  • 意思決定の所在がコミッター本人に明確に起因されるため、自分で決めたことという意識によりコミットメントにつながる
ボトムアップとの違いは何ですか?
  • コントリビューターがプロポーザルをコミッターに提示してプロリクの実施要求をする事は、ボトムアップと近いようであるが、 ボトムアップは大きな意思決定になればなるほど、何階層も上位の階層に意思決定の承認依頼がエスカレーションされる課題がある。
  • 一方で、ゆめみの場合は、特定のチームのコミッターにダイレクトに依頼をすれば良いという事で、何階層にもわたってエスカレーションが発生することはない
  • プロポーザルを受けて、コミッターが自身でプロリクを行う場合は、コミッター自身としての意思決定になり、コミッターとしての遂行責任が発生する
    • これは、提案を受けて承認だけはしておくが、自分は許可しただけというような責任回避の意識が働きにくい構造になっている
  • また、コミッターへのプロポーザルが受け入れられない場合には、自身がコミッターとなることで意思決定を行ったり、自身がチームを作成するといった選択肢がある(チームの分割方法
  • 現場で擦り合わせて考えた案を、上長にひっくり返される事がない点も大きく異なる
あらゆる意思決定をメンバーが行うことができるとすると、混沌とした状態にならないか?
  • チームの定義にあるようにコミッターが意思決定できる範囲を「それぞれのチームのスコープに限定する」ことで秩序を保ちます
あらゆる意思決定をコミッターが行うことができるとすると、間違った意思決定がなされないか?
  • レビュープロセスは、集団的知性(コレクティブインテリジェンス)を引き起こすことが期待されます
レビュープロセスでは、反対ができないため暴走が起きた場合はどうなるのか?
  • まず、会社法で定めるような重要な決定については取締役会が暴走を食い止める役割を果たします
  • また、採用やオフィスの賃貸契約のように取り返しが付きにくいものについては、事前に暴走を食い止めるための承認プロセスをプロリクで定めておいて暴走や致命傷を防ぐことができます
組織に致命傷とはなる事は防げるとしても、レビューによって問題点やリスク回避方法などが示されたにも関わらず、そのレビューが軽視されて問題が起きた場合は見過ごすしかないのか?
  • コミッターは、スコープの遂行責任を負う事により、意思決定権限を持ちます。従って、問題の軽視が災いとなる場合に、それは自分の身に遂行責任として降りかかるので、軽視されない効果がまず働いています。
  • ただし、コミッターも誤ったり、レビューを軽視する事が無い訳ではありません。
  • その場合には、別のコミッターがその意思決定によって引き起こされる問題を回避するような「新たな意思決定」をプロリクとして事後に行う事が可能です
    • 大きな意思決定がされた後、それに従うしかないという考えは、代表取締役が決定する大きな意思決定に対して逆らっては駄目、受け入れるしかないという従来の統治構造の類推から我々は想像をしてしまいがちです
    • しかしながら、全員が代表取締役の権限を持っていることを思い出してみてください。インターネットサービスのように問題が起きた場合は、その後のタイミングで意思決定をすれば良いのです。
あらゆるメンバーが代表取締役の権限があるとしているが、実際に大胆な意思決定をメンバーがしても、結局、最後には代表取締役に決定を覆されるということになるのでは?
  • 二重連結(Double Linking) という絶対ルールによって、親チームのコミッターは子チームのコミッターにはなれないです
  • 代表取締役は多くのチームのコミッターにはなれないという構造が既に運用されています。
代表取締役が意思決定を覆すことがないとしても、チームのコミッター同士がお互いの意思決定の結果を上書きしあったり、無効化しあったりによって、意思決定の衝突が起きないか?
  • 目的を達成するための考え方が違う場合などは、チームの分割方法 を採用することができます
    • また、そのようなA/Bテストアプローチは多様な意思決定の可能性が期待されます
  • 衝突が起きた場合は、コンフリクトの例と解消方法・ロールバックで一定、回避可能です
    • また意見の衝突自体は人間的成長を促す良いものだという考えです(シャドーから学ぶ)

X-pointやZACといった社内ワークフローにおいて承認行為があるのはどういう位置づけか?
  • 内部統制や記録の為に、ワークフローは必要とされています
    • 特に職務権限規定で稟議や申請が必要なワークフローについて
  • プロリクの性質上、後から他の誰かが意思決定を上書きして無効化を行うことができます
  • 従って、後から無効化をしないという事を追認する行為として承認が必要になる場合があります
  • 将来に渡って、無効化しない事を明示的に記録を残すという位置づけが承認行為となります
承認行為は一切ないのか?
  • 代表取締役の承認が必要とする特別手当であったり、リモートワークのように承認が必要とする規定が作られる事はありますので、承認が一切ない事は意味していません
  • また、プロジェクトのワークプロセスにおいては、承認手続きを定めている場合もあります(そういった、承認プロセスを規定する事はプロリクで行う)
プロリクはSlackで行う必要があるのか?
  • 必要はないです。対面で行う事も含めてプロリクと位置付けます。
  • 会議で何かが「決まった」という時も、誰かがプロリクを行なった上で、コミットして、ある特定の一人が意思決定をして「決めた」となります。必ず、特定の誰かが「決める」事が必要となります。
全ての意思決定においてレビューを必要とするのか?
  • 意思決定の結果が与える影響が小さかったり、ネガティブな影響についても自身にしか影響が及ぼさない、あるいは自身でその影響を回避・受容する事ができる程度の場合は、レビューを不要とします
  • 実際に、自分でやれる範囲のことは、自分で専決して進めているはずです
  • バルスのように、レビューを必要としない意思決定が原始的なものとなります