変更履歴
‣
- バルスによりα版開発完了 2018/10/28
- β版開発完了 2018/11/5
- β版リリース 2018/11/15
- 希望すれば、あらゆるメンバーが意思決定を行うことができる形に変更
- 2019/3/31までに80%以上のメンバーに体感として理解、浸透させる
- 2019/5/7 意思決定の例外を２つに変更
- 2019/8/26 アルバイト採用を代表取締役決済対象に追加
- 2019/10/23 プロポーザル雛形に金額を追記し、リンク添付の要望も記載
- 2020/5/26 プロリクの雛形について背景・目的を必須項目として標準にした。一方で効果については直感でも良いとした（直感プロリク）
- 2021/3/16 JIKKENプロリクについては、挑戦行動を称賛する為、レビューのガイドラインを定めた
- 2021/4/25 即時プロリクを定義した
- 2021/5/13 事後プロリクを定義
- 2021/10/21 メンバー呼称の変更により、メンバー部分の記述をレギュラー・メンバーと変更した
- 2021/10/25 JIKKENプロリクに対して、PNIレビューを行うことをガイドラインとした
- 2021/01/21 プロリクの意思決定を行うには４８時間たたないといけないという誤解があったので、４８時間以内に意思決定を進めることもできるということを明示的にした
- 2022/4/11 特定のプロポーザルについて、コミッターではない人にも代理プロリクを依頼することができる
- 2022/5/9 JIKKENとして、2022/7/31まで、全てのチームにおけるプロリクをコミッターでなくても出せるようにする
- 2022/7/15 でバルスが発見されたがレビュープロセスを必要としない意思決定プロセスが明示的でないために浸透していないため改めて「えいや」という意思決定プロセスを定義バルスとは
- 2022/12/14 プロリクには例外を除いて背景・目的を記述することをルールとした
- 2023/2/21 JIKKENプロリクのガイドラインとして、仮説と検証期限を加えて、検証結果をコミッターに共有するものとする
- 2023/05/12 全社サービスのリリースプロセスのガイドライン を充実化。入社したてのメンバーでも具体的なアクションがわかるように加筆、具体化しました。
- 2023/05/15 えいやを意思決定の基本とするガイドラインの対象チームを記載（broad_groupとcxo室）
- 2023/06/01 結果調和プロリクのリリース
- 2023/07/03 代入プロリクをプロリクとして起案
動画説明
少し内容が古くなってきているので、誰か解説動画を作って欲しいです
背景・目的
‣
- その結果、自己組織化された組織にして、1000名の組織になっても、Quality＆Agilityをより高めたい
- 一方でゆめみの業務は関わるサービスの規模が大きく、影響範囲・影響度も大きいので、安定して高い品質を出すためにはプロジェクト毎に、役割分担、責任範囲、プロセス、ルールが細かく定められている
- したがって、「やってみなはれ」と言われて、自由に何かを変えようとすると、暗黙・形式のルールによって「やってはいけない」となってしまう
- 実際に、１０年前までは、それによって心理的にダブルバインドという状態が発生する事があった
- つまり、暗黙、形式含めて、ルールに基づいて業務が細かく定められている以上、「やってみなはれ」として何かを変えようとすると、既存のルールを変えないといけないのである。
- その際に問題になるのが、ルールを変えるルールは何？という問題である
- 多くの会社では購買の金額毎に決裁者は決まっているが、現場業務のルールについての決裁者は曖昧になっている事が多い。
- ルールを変えるルールを明確にしなければ、暗黙・形式の現場ルールを変えることはできないと気づいて、ゆめみでは明確にルールを決める（変える）ルールを定めた
- 実際にはそのルール作りにとても苦労したが、ある時、書籍「ティール組織」における「助言プロセス」を知る事になり「これだ！」となり2018年10月に導入をした
- ゆめみでは助言プロセスをエンジニア文化で浸透している「プルリク」になぞらえて「プロリク」と名付けた
- 一方で、エンジニアとは異なる思考性を持つ人については、あまり細かな手順に捉われず、直感的に周りの人がやるやり方を観察して真似て自分なりに応用までできてしまう人もいる
- そういった人は、本ドキュメントは深く読む必要はない可能性がある事を言及しておきます
対象
- レギュラー・メンバーオプション契約対象の社員
- レギュラー・メンバーオプション対象外の社員は、就業規則・職務権限規定に基づいて承認が必要
- 参考）社員契約とメンバーオプション契約について
- 位置付けとしては、社員はあらゆるチームのコミッターにはなれず、コントリビューターにしかなれない
意思決定プロセス概要
- えいや、あるいはプロリクにより、あらゆる意思決定をコミッターが行うことができる
意思決定プロセス：えいや
‣
- バルスが発見されたものの、プロリクなしでの意思決定はまだ浸透していない
- プロセスやプロトコルがあった上で新しい習慣の浸透が定着化しているので、あらためてプロセスを明確化する
- 特に委員会活動などにおいて、関係者が多くなる中で物事を「えいや」で決めることがもっと増やせる余地がある
- えいやで決めることが良しとされる風土が構築できると、より意思決定が迅速にできたり、周りへの過剰な調整や配慮を必要としないですむ
- 内容
- えいやと言う言葉を使う事によりレビュープロセスを必要とせず意思決定を行うことができる
- 全社に影響ある意思決定についても #000_proreq_all へのレビューを必要としない
- 備考
- レビューは不要だが、事前に壁打ちなどで相談したりアイデアをもむことは可能であり、質の高い意思決定を行うための議論や意思決定をしたことを浸透させるための対話をまるっきり無視して独断で決めることを推奨している訳ではない。
- えいやで物事を進められる人は「組織の事を考えて迅速な決断ができる人」としてリスペクトされる風土を今後作っていく
- 会議において物事が進まない場合にも「えいや」で決めましょう！と呼びかけるなど物事を前に進める行動は推奨される
- 特に推奨されるのは、周りへの配慮や周りから何を言われるか気にしすぎて物事を進めない行動や、チームや組織の方向性を決めるにあたって、物事がなかなか進まない場合にえいやで決める事が求められる
- 対象外
- 職務権限規定で定める承認が必要な事項（購買・福利厚生制度策定・昇給・賞与・調達など）や、プロリクが必要と定められている意思決定については、これまで通りプロリクや承認を必要とすることは変わらない
- JIKKENとは別
- 事後報告で「やっちゃいました」とできるように明示的にした
- えいやには、のっかるのも推奨される
- えいやを意思決定の基本とするガイドラインの対象チーム(2023/05/15-)
- 900_broad_group
- cxo室
意思決定プロセス：プロリク
全員CEO制度
- 制度としては、代表取締役の権限を全て、事前に（社員ではなく）レギュラー・メンバーに移譲する形で実現する。これをもって全員CEO制度と呼ぶ
- 意思決定の例外としては「採用」
「勤怠」は代表取締役が承認を行うものとする - プロポーザルを提示して、ステークホルダーからレビューを受けた本人は、最終的に決議する意思決定内容としては、レビュー内容の中から、必要なものだけ取り入れて意思決定を行うことができる
- 全ての意見を取り入れる必要はない、あるいは全て取り入れなくても良い
- 意思決定を行った本人は、遂行責任を負う
意思決定可能な具体例
- オフィスの新設・移転
- 社内制度・ルールの立案・変更
- 新規サービスの立案
- 研究開発の実施
- 借入・投資の実施
などあらゆる意思決定（後述の意思決定の例外を除く）を行うことができる
プロリクの定義
プロポーザル・レビューリクエスト（Proposal Review Request）の略称
プロリクとは
- コミッターがステークホルダーにレビューを受ける事で「プロポーザル」のコミットを自身で行う意思決定方法
ティール型組織における「助言プロセス」を採用する 参考）ティール組織について https://nol-blog.com/what_is_teal_organization/ 参考）動画 https://youtu.be/gcS04BI2sbk
レビュー方法
- 意思決定の内容について、レビューを求められた人は、原則４８時間（２営業日という意味）以内にレビューを行うあるいはレビューができる期限を示す
- レビューがない場合については何も問題ない（No Problem）を意味するとして、意思決定を進めることができるが、４８時間以内に意思決定を進めることもできる
- 意思決定について、否決をする事はできない
- 否決、リジェクトというフローはない
- 一方で、反対意見を出すことはできる
‣
プロリクフローチャート
コントリビューターや外部チームのコミッターは意思決定を行うことができないため、権限を持つコミッターに対して、プロポーザルを作成してプロリクを実施してもらうことを提案することになるこの場合は、下記のように「プロポーザル」として提示する
上記のポイントとしては
- 相手の行動は変えられないので、コントリビューターは、提案によって相手の行動が変わることを期待しすぎてはいけないこと
- コミッターは、コントリビューターから実施要求があったプロポーザルを実施しない、という選択肢をとることもできる。
- その場合、プロポーザル要求に対して感謝はするが、理由を回答する必要は必ずしもない
- コントリビューターからのプロポーザルをコミッターが実施する場合は、やらされたのではなくて、自身の意思として実施することを意識すること
‣
プロポーザルの雛形
後述する例外を除き，すべてのプロリクに対して背景と目的の記述を必須とする．これはルールである (2022/12/14~)
- プロリクの性質上十分と考えられれば，背景・目的はそれぞれ簡単な一文程度でもよい．
- 読んだ人がなぜそのプロリクが必要なのか理解できるレベル
例外
- すでに体系だてられた制度を使う場合において，背景・目的がその制度の種類から明確であれば，省略可能
- 相当の理由を明示すれば，省略可能
- 生命を守るために必要であるプロリクについては，省略可能
期限（Time limit） レビューを受け付ける期限日。これを過ぎるとプロリク完了となる。
背景（Background） なぜ、その提案を行うに至ったかの背景や経緯
目的（Objective） 何のためにその提案を実施するかの目的や意図
提案（Proposal） 提案や意思決定の骨子
効果（Effect） 提案を行うことによるメリットや効果、狙い、理由などを示す
効果については定量的に示せなくても良い。
また、直感的にそう信じているなどという内容でも良い（直感プロリク）
金額（Cost） 購入・購買・稼働等が伴う場合に記載
参照リンク（Link） 購買を伴うプロリクの場合リンクを貼る事により
購入物のイメージがしやすくなり、競合品との比較がしやすくなる
参考）目的の重要性：P＆G
Slack投稿テンプレート
以下を貼り付けたら、 Cmd + Shift + f（Mac）/ Control + Shift + f （Windows） でマークダウンの書式設定が適用されます。
`プロリク` @here
*期限*
*背景*
*目的*
*提案*
*効果*
*金額*
*参照リンク*
‣
レビューの雛形
Pros（賛成） 良い点、提案の賛成できる点、メリット、応援の言葉、LGTM、shipit Problem（問題） 問題点、ネガティブなリスク、悪影響 Protect（防御） 問題点の解決方法、リスク回避策、悪影響を最小化するアイデアとしての対案
例）Problem・Protectは省略可能。Prosのみの場合、LGTMなどと簡易的にレビューすることもできる（LGTMはGitHubという開発文化から来ている）
‣
JIKKENプロリクのガイドライン
JIKKEN「行為」にはまず称賛を、JIKKEN「内容」には指摘をして、分離したフィードバックを行うことで、行動科学的にJIKKEN行動を強化することができる
- 実験的に行う挑戦行動については、「JIKKEN」「JIKKENプロリク」というキーワードをSlackで記載する事
- また、Slackでの投稿についてはNICE JIKKENのリアクション絵文字をつけると、相手に対して１絵文字毎に40ポイントが付与されます
JIKKENプロリクの内容には通常のプロリクに加えて以下を加えること（2023/2/21〜）
- 検証したい仮説
- 仮説検証期限
その上で、仮説検証期限までに仮説を検証した上で、検証結果はコミッターに共有を行うこととする
なお、検証した結果、当初の仮説については評価不明ということは実験なのであっても良いとする。大切なのは検証プロセスを一旦設置することである。
‣
PNIレビュー（Praise/Next/Interesting）
- JIKKENプロリクへは、Praise/Next/Interestingの順番でレビューを行うこと
Praise（称賛）
- JIKKENの試み、挑戦行動、発想に対して、最初に「称賛」「賛辞」「尊敬」の意を伝える
Next（対案）
- JIKKENを行う中で、多様な視点での対案、懸念点の指摘などを伝えて、失敗確率を下げたり、起こり得る障壁を乗り越える手助けとする
- この異論、反論をしても大丈夫と信じられる状態が心理的安全性が高い状態と言われる
Interesting（興味）
- 最後に、JIKKENが成功した結果に対して、ワクワクや興味を伝える形でレビューを終える
PNIレビュー例
Praise
大胆な施策として今回のJIKKENを提案したことは素晴らしい発想と思い切りの良さを感じました！
Next
もし実施する際には、専門家のアドバイスをもらった上で、段階的な投資をするという発想もあるかと思います
Interesting
いずれにしても、今回の施策が上手くいかなかったとしても、会社としての知見になることは間違いなく、私も何かしら支援できればと思いました
プロリクの種類について
‣
（Ａ）即時プロリク
内容
- プロリク時に「即時プロリク」と表記する事で、即時にコミット（本番反映）した事を意味する
- レビューは即時のコミット後も受け付けることになる
- コミットした後に、内容を修正する場合は、修正内容を都度、即時プロリクし直す事
備考
- ４８時間以内は、コミットした内容が本当にその内容で良いか、コミッター自身も本番の状況やレビューに注意を払う事をガイドラインとする
- 即時プロリクは、コミットを即時に行うだけであり、関係者へのレビュー依頼を省略できるわけではない
対象外
- 全社に影響あるプロリクは即時プロリクの対象外とする
‣
（Ｂ）事後プロリク
- 何かの事情でプロリクの内容が実施された、行使された、購買された後に事後でプロリクを行う場合がある
- 事後でプロリクを行うことは可能である
- ただし、事後プロリクを行う場合は、即時プロリクを行うことはできない
- また、事後プロリクにおいて４８時間以内のレビュー期間中に、その事後プロリクを無効化するプロリクが他のコミッターから出された場合に、事後プロリクが無効になる場合がある
‣
（Ｃ ）代理プロリク
- 背景
- コミッター以外の人のプロポーザルを受けて、コミッターがプロリクを出しても、レビューに対して詳細の回答ができない場合がある
- 本来はプロポーザルを出してくれた人が直接レビューに対して回答するなどやりとりをしてもらいたい場合がある
- 内容
- 特定のプロリクについては、コミッターが代理プロリクを依頼することで、コミッターではない人自身も、プロリクを特定の代理プロリクの依頼を受けたプロポーザルに限って出すことができる
‣
（Ｄ）マイクロプロリク
- 背景
- モノレポ（JIKKEN）による検証結果としてハレーションやプロリクを出す人が遂行責任を負うようにしたい
- 内容
- チームのコミッターではない人であっても、コミッターにならずにプロリクを局所的なスコープで出せるようにする
- ただし、該当するプロリクの内容の遂行や目的の達成に向けて遂行責任をコミッターとして一定期間（目安として６ヶ月間）は負うこととする
- なお、マイクロプロリクの内容については、既存のコミッターも同様に遂行責任を負うことにはなるので、既存コミッターと協力して遂行していきます
- 実施方法
- 該当するチームのコミッターにメンションをつけて「マイクロプロリク」というキーワードをSlackで記載する事
- マイクロプロリク事例
- Zoomアカウント最適化
- Twitter Blueの広報利用
- マイクロプロリクを実施する人はコミッターとして該当するプロリクの内容の遂行だけでなく、目的の達成に向けても遂行していくこと
- 例として、上記のTwitter Blueについてはリスク管理が目的なので、リスク管理についての達成に向けても遂行していくことになる
- つまり、リスク管理が達成される別の手段があれば、その手段の検討や代替案のプロリクを行ったり、目的が達成されれば必要に応じて当初のプロリクをやめるということも行う
備考
‣
（Ｅ）結果調和プロリク
- 背景
- 具体的な方法や実行案はその時点では不明であるが、最終的に目指したい状態や在り方などが先に決まっていて、そこに向けてメンバーが協力・連携しながらあるべき状態に辿り着きたい場合がある
- 特に、結果を先に示すことで、具体的な実行案が議論されることで、結果として望む結果に早く、適切に辿り着くことがある
- 逆に言えば、結果に至る実行案を示さないと、結果を目指すという方針が示せない状態があった場合に、物事が進まない硬直した状態になり得る
- 特に、組織にとって未知なもの、業界でも未知なものを実施する場合はそのようなことが起こり得る
- 目的
- 結果に対して早く辿り着けるような意思決定プロセスを明示、用意する
- 内容
- 結果調和プロリクとは、具体的な方法はメンバーが議論・協力・連携して発案・実行する前提で、目指す状態や方向性を事前に提示して進めるというやり方になる
- 結果に至るやり方、実行方法、筋書きは予定調和的ではなく、あらかじめ予想されていない事もある。しかし、そのような予想されない事態が起きた時点で、当初の筋書きに加えてしまって、結果的に望ましい状態に早く適切に辿り着くようにメンバーは振る舞う
- 備考
- えいやで方針を示すこととの違いは、プロリクで明示的に示すことによって議論や巻き込みを活発にする効果が期待できる
- また、外部環境の変化の流れにより、必ず期待する結果に至らないといけない確度が高いが、実現方法についての不確実性が高く、メンバーを巻き込む必要がある場合などは、結果調和プロリクが有効である可能性がある
‣
（Ｆ）代入プロリク
（2023/7/3プロリク起案）
- 背景
- プロリクは全員CEO制度のもと、あらゆるメンバーに権限があり、本来は誰がプロリクを出すか・出したかに依らず、コミット、リリースされた後は、そこにメンバーが従うものとしている
- 一方で、人に影響力として実態としては、誰がプロリクを出したかという、プロリクを出した人の権威も影響する
- 権威を獲得するには、小さい実績をつみかさねていくとすると、実績がない段階で大胆なプロリクを出せない可能性もある
- 目的
- 効果的なプロリクを誰もが必要に応じて出せるようする
- 内容
- プロリクを出す際に、自分ではなくて特定の他人にプロリクを出してもらうようにできる
- 周りから見れば、自分ではなくて特定の他人がプロリクを出したように見えるが、実際には裏で自分が依頼をしている
- ただし、それには、他人である相手側の合意が必要
- 特徴としては、通常は非推奨となっているSlackのDMでのやり取りなどを可能にした上で、表面的には自分が特定の他人にプロリクを出すことを依頼していることがわからないようにできる
- なお、プロリクがリリースされて一定期間経ったあと、実は自分が代入プロリクで依頼した内容と明かにして良いが、代入プロリクの狙いとしては、一定期間は明かにしない方が望ましい
意思決定の例外
誰もが意思決定を原則行うことができるが、以下の２つは例外として定める
１. プロパー・アルバイト採用（Recruitment）
プロパー・アルバイトの採用の決定は代表取締役のみが行う
２.その他
- 取締役会決議事項
補足
勤怠（コアタイムの欠勤・深夜休日出勤・休暇取得）に関する承認は、管理やシステムの都合上、プロジェクトマネジメント担当がZACで行う。一方で、あくまで意思決定は、本人がチームへのプロリクで行うものとする。
‣
全社サービスのリリースプロセスのガイドライン
- レギュラー・メンバー全員に影響あるような制度変更などについて、以下の手順を踏むこと。
- 提案内容に関連あるチーム（以下の表参照）や専門家にプロリクまたはプロポーザルを出し、草案をレビューしてもらって案の精度を高める。
- 提案内容に関連あるチームがコミッターに該当する場合は、プロポーザルまたはマイクロプロリク
- プロポーザルにする場合、コミッターに自身の提案として実施するか判断をしてもらう。
- マイクロプロリクにする場合、既存コミッターと協力して遂行責任を負う。
- 提案内容がどこにも該当しない場合
- 提案者はプロリクとして引き続き以下の対応を行う。
- 上記のレビュー完了後、 #000_proreq_all のSlackチャンネルに
@channelのメンションをつけてプロリクを出し、全員からレビューをもらう。 - 意思決定後の正式リリースは 000_announce_all に周知を行う事で実施される
- また、その際は可能な限り、ビジュアルデザインを工夫した画像を添付して、内容が伝わる様に意識する事。チラシのようなイメージ。
- この周知については、#000_help_general で総務に依頼可能
- この際に@channel のメンションをつける場合は、いったん投稿した後に、編集する際にメンションを付けると通知は飛ばずに、バッヂが付くだけになるので配慮することになる
- チーム、プロジェクトの状態が、サバイバルモードにあったり、危機的な状況であれば、最初に、意思決定プロセスとして、原則、レビューを省略した「トップダウン」に変更しますという、「意思決定プロセスの変更を行う」という意思決定を関わるチーム・プロジェクトのメンバーからのレビューをもらって実施することがのぞましい。
- チーム・プロジェクトがサバイバルモードにある状況というのは、根本原因を取り除くために、トップダウンアプローチが必要なことが多いためである。
- 専門的な知恵を持つ人がいなければ、社外の専門的な有識者にレビューをもらうことも可能
‣
| カテゴリ | Slackチャンネル | メンション先（AND条件） |
|---|---|---|
@accounting | ||
@recruit | ||
@recruit_marketing | ||
@hr | ||
@notion_design | ||
@chro | ||
@benefit | ||
@pr_media@salespromotion | ||
@branding | ||
@sales_all | ||
@broad@broad_owners@challenge_broad2022 | ||
@cdo-office | ||
@cpo-office | ||
@cto-office | ||
@cro-office |
‣
‣
取締役会決議事項の意思決定プロセス
- プロリクという意思決定プロセスは会社法を無視するものではない。つまり、取締役会決議事項については、取締役会決議が必要である。
- 取締役会は会社を守るためのゲートウェイとして、反対決議は行う事ができる事に変わりはないし、そういったゲートウェイの機能は経営が暴走しない意味で必要である
- ただし、意思決定のAgilityを担保するため、以下を工夫する
- 毎月開催される取締役会の開催を待って、承認決議を得るプロセスは取らなくて済むことができる
- 具体的には、この範囲であれば反対しないという「反対しない範囲」を事前に決議をとるプロセスを進める
- プロセスの機動性を高めるため、みなし取締役会を定めて、電子的な取締役会決議を行えるようにする事も今後あり得る（実際には事前に決議を取るような場面が少なく優先度が低い）
- 事前に決議をとった後、事前に取締役会で承認された「反対しない範囲」で、レギュラー・メンバーが意思決定を行うことができる（つまり取締役の意思決定ではなく、本人の意思決定となる）
- 例としては
- 広報の年間投資予算を取締役会として反対しない範囲を決議するなどのプロセスが考えられる
- 年間３０００万以下を決議しておく
- これは即ち、一般的な予算についての承認を得るプロセスと近い
‣
意思決定ルールの理論的背景（承認がない意味）
- あらゆる意思決定ができるとは、制度運用のテクニカルな観点で言えば、代表取締役の権限を全て事前に（社員ではなく）レギュラー・メンバー全員に移譲していると位置付けられる
- 「レギュラー・メンバーのあらゆる提案を承認する」という何でも提案が通るということと、「レギュラー・メンバーのあらゆる提案を（レビューをもらった上で）自身の権限で意思決定する」ということは同じようで異なる
- 何が異なるかといえば、前者はあくまで責任者が権限を持っており承認をした人は責任者である。その場合の意思決定の起因は責任者に由来する
- 一方で、後者の意思決定の起因はレギュラー・メンバー本人に由来する。ここに大きな違いがある。
- 組織という狭いコミュニティにおいて、自らが意思決定した内容に沿って、一貫した行動をとる事が期待されるため、遂行責任が働きやすくなるためである
- この背景には一貫性の原理と呼ばれるものがある（一貫性の原理とは）
FAQ
‣
- 原理的に、意思決定つまりプロポーザルのコミットは、コミッターが意思を決めた時点でなされたとします
- ただし、チームとしての意思決定の場合、チームのコミッターがそれに適切に従うためには当然、言語化などが必要となります
- 従って、意思決定の内容をドキュメント化したりする事が必要となります
- また、全社に影響するプロリクの場合は、いつから変更内容が実行されるかの期日も組織運営上は重要になるため、ドキュメント化だけでなく全社向けの情報周知も重要になります。
- しかしながら、ドキュメント化や周知のタイミングが意思決定のタイミングではなく、コミッターが意志を決めたタイミングが意思決定のタイミングとなります。
‣
- コンセンサス（合意）なプロセスは、誰が意思決定をしたかの所在が曖昧になりがちであり、結果として意思決定をした人のコミットメントに繋がりにくい
- プロリクは、誰もメンバーの意思決定に対して反対をすることができないのが特徴
- なぜ反対ができないかというと、代表取締役の権限を持っているので反対ができない
- ステークホルダーからのレビューをもらうが、意思決定に対して反対を強いられることはないので、コンセンサスとは違って意思決定が早い
- 意思決定の所在がコミッター本人に明確に起因されるため、自分で決めたことという意識によりコミットメントにつながる
‣
- コントリビューターがプロポーザルをコミッターに提示してプロリクの実施要求をする事は、ボトムアップと近いようであるが、 ボトムアップは大きな意思決定になればなるほど、何階層も上位の階層に意思決定の承認依頼がエスカレーションされる課題がある。
- 一方で、ゆめみの場合は、特定のチームのコミッターにダイレクトに依頼をすれば良いという事で、何階層にもわたってエスカレーションが発生することはない
- プロポーザルを受けて、コミッターが自身でプロリクを行う場合は、コミッター自身としての意思決定になり、コミッターとしての遂行責任が発生する
- これは、提案を受けて承認だけはしておくが、自分は許可しただけというような責任回避の意識が働きにくい構造になっている
- また、コミッターへのプロポーザルが受け入れられない場合には、自身がコミッターとなることで意思決定を行ったり、自身がチームを作成するといった選択肢がある（チームの分割方法）
- 現場で擦り合わせて考えた案を、上長にひっくり返される事がない点も大きく異なる
- 「特定の人の承認を必要をする」と、過去のプロリクにより既に定められている事項
- 主に職務権限規定で定める決議事項（購買、見積、押印、契約など）
‣
- チームの定義にあるようにコミッターが意思決定できる範囲を「それぞれのチームのスコープに限定する」ことで秩序を保ちます
‣
- レビュープロセスは、集団的知性（コレクティブインテリジェンス）を引き起こすことが期待されます
‣
- まず、会社法で定めるような重要な決定については取締役会が暴走を食い止める役割を果たします
- また、採用やオフィスの賃貸契約のように取り返しが付きにくいものについては、事前に暴走を食い止めるための承認プロセスをプロリクで定めておいて暴走や致命傷を防ぐことができます
‣
- コミッターは、スコープの遂行責任を負う事により、意思決定権限を持ちます。従って、問題の軽視が災いとなる場合に、それは自分の身に遂行責任として降りかかるので、軽視されない効果がまず働いています。
- ただし、コミッターも誤ったり、レビューを軽視する事が無い訳ではありません。
- その場合には、別のコミッターがその意思決定によって引き起こされる問題を回避するような「新たな意思決定」をプロリクとして事後に行う事が可能です
- 大きな意思決定がされた後、それに従うしかないという考えは、代表取締役が決定する大きな意思決定に対して逆らっては駄目、受け入れるしかないという従来の統治構造の類推から我々は想像をしてしまいがちです
- しかしながら、全員が代表取締役の権限を持っていることを思い出してみてください。インターネットサービスのように問題が起きた場合は、その後のタイミングで意思決定をすれば良いのです。
‣
- 二重連結(Double Linking) という絶対ルールによって、親チームのコミッターは子チームのコミッターにはなれないです
- 代表取締役は多くのチームのコミッターにはなれないという構造が既に運用されています。
‣
- 目的を達成するための考え方が違う場合などは、チームの分割方法 を採用することができます
- また、そのようなA/Bテストアプローチは多様な意思決定の可能性が期待されます
- 衝突が起きた場合は、コンフリクトの例と解消方法・ロールバックで一定、回避可能です
- また意見の衝突自体は人間的成長を促す良いものだという考えです（シャドーから学ぶ）
‣
- 内部統制や記録の為に、ワークフローは必要とされています
- 特に職務権限規定で稟議や申請が必要なワークフローについて
- プロリクの性質上、後から他の誰かが意思決定を上書きして無効化を行うことができます
- 従って、後から無効化をしないという事を追認する行為として承認が必要になる場合があります
- 将来に渡って、無効化しない事を明示的に記録を残すという位置づけが承認行為となります
‣
- 代表取締役の承認が必要とする特別手当であったり、リモートワークのように承認が必要とする規定が作られる事はありますので、承認が一切ない事は意味していません
- また、プロジェクトのワークプロセスにおいては、承認手続きを定めている場合もあります（そういった、承認プロセスを規定する事はプロリクで行う）
‣
- 必要はないです。対面で行う事も含めてプロリクと位置付けます。
- 会議で何かが「決まった」という時も、誰かがプロリクを行なった上で、コミットして、ある特定の一人が意思決定をして「決めた」となります。必ず、特定の誰かが「決める」事が必要となります。
‣
- 意思決定の結果が与える影響が小さかったり、ネガティブな影響についても自身にしか影響が及ぼさない、あるいは自身でその影響を回避・受容する事ができる程度の場合は、レビューを不要とします
- 実際に、自分でやれる範囲のことは、自分で専決して進めているはずです
- バルスのように、レビューを必要としない意思決定が原始的なものとなります
‣
- 即時プロリクはプロリクの直後に即座に意思決定するプロセスですが、事後でレビューを受け付ける前提となっています
- また、即時プロリクはそもそもプロリクが必要な意思決定プロセスを対象としています。例えば購買プロリクなどもそうですし、職務権限規定で定める承認が必要な項目もそうなります。
- 一方で「えいや」については、レビューを必要としない前提で、意思決定した後に事後で報告するものとなっています。
- えいやはそもそもプロリクを必要とするとして定められていない対象行為についての意思決定プロセスです。例えば、各プロジェクトにおける仕様策定や設計方針、会議設計やメンバー調整においてプロリクは実施されていません。このように、実際には多くの意思決定はえいやで決まっております。
- ただし、えいやで決めているからといって、事前の相談や壁打ち、議論や対話を全く必要としていないわけではないです。
‣
- 意思決定の原点はえいやで決まっています。これは会社に限らずあらゆる社会において原始的な意思決定方法です。
- その上で、えいやで決める中でレビューや承認が必要だと判断された事について、これまでのようにレビュープロセスや承認プロセスが適用されてにて今に至っています。
- これからも、必要に応じてプロリクや承認が必要な場面において、えいやではなく、プロリクや承認を必要とする意思決定をプロリクを通じて行う形になります
- なお、えいやは原始的な意思決定方法であるため、えいやでえいやという意思決定を廃止することはできないです
‣
