GitLab に学ぶ意思決定
はじめに
前回に引き続き、「意思決定」に対する様々な考えや視点について書いてみます。
前回記事はこちらです。
自分が意思決定について考える時に、よく見返す記事のひとつとして、GitLab の「Making Dicisions」があります。
https://handbook.gitlab.com/handbook/leadership/making-decisions/
GitLab という会社は、「GitLab」という、Git リポジトリマネージャーをオープンソースとして開発しているところで、完全リモートワークを長年実現している組織として知られています。
早期からグローバルでリモートワークを成立させているだけあり、企業文化が独特で、多くの価値観が言語化され、共有されているのが特徴的だと思います。
完全にグローバルでリモートワークを前提としているので、組織の規範をすべて非同期的なコミュニケーションで伝達する必要がありますから、私達がイメージする一般企業の感覚と比べると、この価値観の言語化の重要度がとても高いのだと想像します。
この記事の中からいくつか引用しながらご紹介できればと思います。
意思決定の構成要素
この記事の中では、GitLab として意思決定をこのようにすると言い切っています。
A data gathering phase in which folks are actively asked to contribute data and perspectives that can inform decision making. This has the benefits of consensus organizations: everyone can contribute and decision makers benefit from more available data.
A decision phase in which an informed individual can make a decision without getting an approval from others. Voting on material decisions shows a lack of informed leadership. The decision phase has the benefit of hierarchical organizations: the person that does the work or their manager decides what to do, so decisions can be made quickly.
データ収集段階では、意思決定に役立つデータや視点を提供するよう、人々に積極的に求める。これにはコンセンサス組織の利点がある：誰もが貢献でき、意思決定者はより多くの利用可能なデータから利益を得ることができる。
決定段階では、十分な情報を得た個人が、他の人からの承認を得ることなく決定を下すことができる。重要な決定に対する投票は、情報に基づいたリーダーシップの欠如を示す。意思決定段階には、階層型組織の利点がある：仕事をする人またはその上司が何をすべきかを決定するので、意思決定を迅速に行うことができる。
前回の記事でも取り上げました、「正しく情報収集できているか」が、まさに Phase 1 にあたる部分だと思います。
これは前回の記事で書いたこととかなり近しいので、今回は割愛します。
Phase 2 は、やや日本的カルチャーとは異なる部分もあるように思いますので、理解に違和感のある部分があるかもしれません(自分も正しく理解できているかどうか)。
こちらによると、精度高く高速な意思決定をするには、責任を持った一人の人間が最終判断をするべきで、それは複数の人間であったり、合議的であってはならない、とあります。
レビューや有識者の意見など、多くの人の視点やアイデアと合わせて判断をした方が良い判断になる、と思う部分もありますが、その点に関してはこのように書かれています。
These phases don’t work if you take a full consensus or hierarchy approach. If you apply consensus in both the data gathering phase and the decision phase, you lose speed. Decisions also stay under the radar as team members try to limit the amount of folks they need to buy-in. If you apply a hierarchy approach in both the data gathering phase and the decision phase, they lose valuable input. We can allow others into our kitchen, because we can always send them out. Inviting people to give input is much easier if you retain the ability to make a decision by yourself.
完全なコンセンサスやヒエラルキー・アプローチをとると、これらのフェーズはうまくいかない。データ収集フェーズと意思決定フェーズの両方でコンセンサスを適用すると、スピードが落ちる。また、チームメンバーが賛同を得るために必要な人数を制限しようとするため、意思決定は水面下で行われることになる。データ収集段階と意思決定段階の両方でヒエラルキー・アプローチを適用すると、貴重な意見を失うことになる。他人を台所に入れることができるのは、いつでも送り出すことができるからだ。自分ひとりで決断できる能力を保持していれば、人々に意見を求めるのはずっと簡単だ。
情報収集は多数の人の力を借りてやるべきですが、判断はそれができる単独の個人がやることで、精度とスピードを担保する、ということですね。
DRI と Buy-in
この中で、個人的に重要に思うキーワードは 2つで、「DRI」と「Buy-in」です。
DRI (Directive Responsible Individual) とは、要するにそのトピックにおける責任者たる単一個人、です。
より具体的に期待される行動についてはこちらの節が分かりやすいと思います。
At GitLab, DRIs can make decisions that other team members disagree with. We say that collaboration is not consensus and people are not their work. A DRI may make a decision that results in (and is hence the cause of) negative feelings, but the DRI isn’t expected to make the popular decision and the person, the DRI, is not the decision that has been made. The DRI should consider input and make an informed decision, but the DRI is not responsible for how people feel. Once a DRI has made a decision, team members are asked to disagree, commit, and disagree.
GitLabでは、DRIは他のメンバーが反対する決定を下すことができます。私たちはコラボレーションはコンセンサスではない、人は仕事ではないと言っています。DRIは否定的な感情をもたらす（そしてそれ故にその原因となる）決定を下すかもしれませんが、DRIは人気のある決定を下すことを期待されているわけではありませんし、DRIという人物は決定されたものではありません。DRIは意見を考慮し、十分な情報を得た上で決定を下すべきであるが、DRIは人々がどう感じるかについて責任を負うものではない。DRIが決定を下したら、チームメンバーは反対、コミット、反対を求められる。
また、上述の、個人として意思決定できる力、というのは、誰でもよいわけではなく、このような期待値が明記されています。
The DRI should have the level of seniority and knowledgeability required to gather information and make decisions. While this will vary with the complexity and potential impact of a decision, a DRI who is well matched to the ask gives team members confidence in an informed and knowledgeable hierarchy. Team members will be more confident that their feedback has been considered and more likely to agree or disagree and commit with a decision.
DRIは、情報収集と意思決定に必要なレベルの年功と知識を持つべきである。これは、意思決定の複雑さや潜在的な影響によって異なりますが、依頼内容に適したDRIは、チームメンバーに、情報に精通した知識豊富な階層であるという信頼を与えます。チームメンバーは、自分たちのフィードバックが考慮されていると確信し、意思決定に賛成または反対し、コミットする可能性が高くなります。
次に「Buy-in」ですが、この記事では、単語自体は使われているものの、それ自体については多くは語られていないと思います。
イメージとしては DRI が実施した意思決定に「のった」「のらない」みたいなものだと理解しています。
上述の引用の中では、「disagree, commit, and disagree」と表現されていますが、DRI ではない、DRI にフォローする立場のチームメンバーに期待されるところは、高いプロフェッショナリティに基づいた遂行力みたいな部分でして、その個人がどう思うかとは別に、 DRI の決定事項をいかに高クオリティで遂行できるか？がとにかく重要である、という感じだと思います。
「メンバーが快く思わない意思決定をすることができる」という部分が、ここにあたると思います。
ひるがえって、DRI の責務としていかにメンバーを「buy-in」 させるのか、というミッションがあります。いわゆる説明責任を、より具体的に言語化したようなものだと理解しています。
「Buy-in」については「The Greatest CEO Within」という書籍でも、「to be invested in (意思決定に巻き込む、関わる、集中する)」という形で触れられておりまして、これがないとチームとしての意思決定の成功確度、遂行の精度が圧倒的に下がる(実行すらされない)と書かれています。
判断自体は、DRI が単独で実施すべきですが、その判断にチームを巻き込み、その判断のチームでの実行確度を上げる動きも求められているように思います。
It is important for your team to be invested in a decision; otherwise, their execution will be half-hearted (or won’t even happen).
チームが決断に没頭することは重要だ。そうでなければ、チームの実行は中途半端なものになる（あるいは、実行すらされない）。
アーリーステージの組織にどう適用していくか？
GitLab の意思決定と、その周辺の言語化はとても優れていると感じますが、この考え方を、特に数名~数十名規模のアーリーステージの組織に適用するのは難易度が高いと感じます。
なぜなら、アーリーステージでは、
DRI が決めづらい
事業自体が未成熟なため、社内における責任範囲が曖昧で、変化が速い。
責任範囲の線引きの難易度が高く、またそれをする必要もない。
Buy-in の必要がない(既に出来ている)
創業、またはそれに近い少数のメンバーだけで構成されているフェーズでは、精緻な言語化よりも、阿吽の呼吸で、まず PMF を目指した方が良い。
という性質があると思うためです。
一方で何もしなくても良いのか、と言われると、それも No だと考えておりまして、アーリーステージを抜けた後とはいつなのか、を察知するのは、現実問題非常に難しいためです。
組織の複雑性に気づいた段階で、いきなりすぐにクリアな組織体制を構築したり、DRI を設けたり、GitLab のような規範を構築することは簡単ではありません。
そのため、その時点で予測できる範囲で良いので、常に DRI の考え方を元にした未来の組織図を議論検討したり、事あるごとにリーダーシップやマネジメントに求める期待値(≒ Job description) を言語化したりする、などの準備が重要に思います。
まとめ
ここまでクリアに意思決定に期待すること、が言語化されている記事はあまりないと思い、個人的に頻度高くリファレンスしているものを紹介させていただきました。
あくまで GitLab という組織ではこういう在り方を志向している、というだけであり、自分の組織でどうあるべきか？は、常に自分で考えて適用していくべきだな、と思います。
この記事が気に入ったらサポートをしてみませんか？