Ubie Discovery における組織開発をソフトウェア開発的に理解する
TL;DR
- 組織開発の中でも特に組織構造を最適にするという点に注目する
- 変化が早いスタートアップ企業では、問題に対する解像度が高く課題感を感じている人が組織構造を変更できる仕組みがあると不確実性の変化への対応力が高まる
- Ubie Discovery での組織開発は、組織をコードベースに見立てて PR を送りそれを反映することで改善していくものと考えると理解しやすい
Ubie Discovery ではみんな（これは正確には全員ではないので後で説明する）プロダクト開発もやるし組織開発もやると聞くけど、組織開発というのは何をどうやっているか具体的にイメージが湧かない、という話をカジュアル面談などでよくされる。
仮に自分が社外の人だったとしたらという観点で Web 上で情報を調べてみると、概念と大枠を理解できる記事として Holacracy の記事 https://note.com/ubie/n/nd86e2a5655c0 が出てくる。
これを読むと面白そうではあるが、一人のメンバーとして実際にどういう振る舞いをすることになるかまでは触れられていないし、やはりもっと具体的なイメージを膨らませたい感じがする。
社内で実際に運用してみて、Ubie Discovery における組織開発はソフトウェア開発と類似性が高いと考えるようになった。
そこでこのエントリでは、日々の活動がより具体的にイメージできるように、Ubie Discovery の組織開発をソフトウェア開発と対応づけて説明してみる。
主にソフトウェアエンジニアを読者として対象としているが、ソフトウェア開発に少しでも携わっている人であれば誰でも理解の一助になるかもしれない。
組織開発に関する整理
そもそも論として、組織開発とはどういうもので、なぜ必要で、誰がやるのか、などを整理しておく。
組織開発とは何か？
ここでは「組織の目的（ミッション）を達成するために、必要な機能を定義してそれを最適な構造に配置する」と定義しておく。 組織開発には様々な側面があるのでこの定義が完璧なものとは思わないが、今回のエントリではこの定義を採用して話を進める。
組織開発の具体例としては以下のようなものが挙げられる。
- チームでスクラムを実施するためにプロダクトオーナーやスクラムマスターなどを役割を誰がやるか決定する
- ある API の運用をする責務は機械学習エンジニアにあるよねという全員の認識を揃える
- エンジニア全体を横串で見ることのできる CTO や VPoE などのポジションを作って人をアサインする
- 一緒に動いた方が効率がよいであろうチーム A とチーム B を合体してチーム C とする
- 採用計画を立てて採用施策を推進したり、評価精度を整備して適用したりする
- 新規事業を始めるためにチームを新たに作りそこに適切な人々をアサインする
このように小さなものから大きなものまで様々なレベルで組織開発は実施されている。
なぜ組織開発が必要か？
ある程度の人数が集まったら、みんな好き勝手に動いても一つの目的を達成するために効率的ではないので、一度組織を構築する必要があることはほぼ自明と言っていいだろう。
なので、もう少し正確にこの問を書き直すなら「なぜ一度構築した組織を継続的に開発する必要があるのか？」というものになる。
答えとしては「状況の変化に適切に対応するため」というものであり、これもあまり異論があるものではないだろう。
課題に対する理解度が深まる・新しくサービスを提供することに決める・人員が増えるなどの内的要因、法律や規制が変わるなどの外的要因、色々な状況の変化に適切に対応するための組織を継続的に構築していく必要がある。
状況の変化に対応して組織構造を変える、というのをどの程度の頻度で実施するかは向き合っている不確実性や組織規模に依存する。
100 人以上の規模になってくると大きな組織変更は大変になりがちで、見聞きした範囲では早くても半年単位とかになることが多い。
誰が組織開発をするのか？
組織が数人〜十人という規模であれば全員が全体のことを把握してるので、殊更に意識せずとも自然と全員でやるというものになるだろう。
人数が数十人〜百人を超えてくると、大きな組織開発は経営陣など一部の人のみが実行するものとなることが多い。
チーム内で閉じる小さなものは多くの人が参加するが、この手のものは組織全体に影響を与えるものではなく、組織開発をしている意識は希薄になっていく。
こうした事情から、一定規模以上の組織で働いたことしかない人にとっては、組織開発というのは経験がなくそもそも何をどうやるのかよく分からないものになっていることが多いと思われる。
組織開発に対する課題感
組織開発に対する課題は組織の規模や状況に応じて色々あるとは思うが、典型的なスタートアップ企業においては「不確実性の変化への対応が遅くなってしまう」という課題が最も深刻なものとなる。
典型的なスタートアップ企業は大きな不確実性と向き合っており、しかもその変化は激しい。
課題に対する理解度が上がることでソリューションを変えたり、そもそも解くべき課題自体を変えたり、法律や規制が変わったり、色々なことが短期間で発生してそれに対応していく必要に迫られる。
限られたリソース、特に人的リソース、を組織開発を通して最大限に有効活用して不確実性の変化に対応していきたいが、一部の人が低頻度で実施するスタイルでは十分な速度で対応できない危険性が高い。
組織構造を変えるべきだと感じている張本人とは限らない一部の人々が情報を集めて整理し、他の人から見るとどう決まってるかよく分からないプロセスで組織構造を変更し、新たに変更が必要になったらまたそれを繰り返す、このやり方で十分な速度を出すのが難しいというのは考えてみれば当然のことに思える。
仮にこのやり方で頑張って高頻度に組織構造を変更したとしても、組織開発に携わってない多くの人にとっては「なんでか知らないけどウチの組織はよく組織構造を変えてるんですよね〜」という感想を抱くというのが関の山だろう。
要は、成し遂げたい目的に対して、世の中でよく使われている手法はあまりマッチしていないのである。
理解度が高くて課題感を持っている当事者が変更することができ、変更のプロセスをその理由を含めて誰でも即時に確認でき、素早くインクリメンタルにも変更することができる、そんな手法が必要である。
Ubie Discovery の組織開発をソフトウェア開発的に理解する
組織開発は「不確実性の変化への対応」を目的としているという話をしたが、これはソフトウェア開発（ここでは自社プロダクト開発を想定）においても主たるテーマである。
抽象的な意味では目的が同じなので、実現のための方法が類似するというのは自然なことであり、先ほど挙げた必要とする手法はソフトウェア開発で日々実践していることに近い。
Ubie Discovery で採用している Holacracy という仕組みはまさに必要としている組織開発の手法となっている。
Holacracy は役割や権限を明文化し、それを構造化して管理するという手法である。
構造化された役割や権限は組織構造そのものであり、参加者全員が組織の理想と現実のギャップを埋める責任と権限を持っている（もう少し詳しく概要について知りたい場合は冒頭で紹介した記事を読んで欲しい）。
以降では Holacracy による組織開発をソフトウェア開発と対応づけて、具体的にどうやって組織開発をしていくのかを説明する。
対応関係を考える
Holacracy による組織開発とソフトウェア開発の対応関係を考えてみる。
組織構造 = コードベース
組織開発は「組織の目的（ミッション）を達成するために、必要な機能を定義してそれを最適な構造に配置する」ことだと定義したが、これは「ある課題を解くためのプロダクトのコードベースを、必要な機能を定義して最適な構造に設計して作り上げる」ということに対応している。
Holacracy では構造化された自然言語で組織構造が記述されている。
我々は向き合っている不確実性の変化を捉えながら、素早く柔軟にこの組織構造を最適化していきたいと考えている。
組織構造を変えるためのプロトコル = Pull Request ベースの開発
組織構造を書き換えるプロトコルは Pull Request ベースの開発に対応している。 ソフトウェア開発では、コードベースをよりよくするために Pull Request を送り、それを他のメンバーがレビューし、承認されるとコードベースに反映される。
Holacracy による組織開発も同様の流れで実施される。 このように組織構造を変えるべきだという Proposal を送り、それが他のメンバーがレビューし、承認されると組織構造に反映される。
この一連のプロセスは誰でも確認することができ、あらゆる変更に対してその目的などが画一的なフォーマットで与えられる。
プロトコルに即していればいつでも誰でも Proposal を送ることができるため素早い変更が可能であり、Proposal はある役割に一つの責務を追加するといった小さなものも含むのでインクリメンタルな改善も可能となっている。
実際の Proposal の例は以下のようなものである。
会社のバリューを体現した人を表彰しているが、その設計や実施は暗黙の期待となっていたため、役割として明確化するべきというものである。
Holacracy 独自の単語が多分に含まれているが、このような形で Proposal を出し、承認プロセスを経て組織構造の中に実装されていく、というのが見てとれると思う。
組織開発者 = ソフトウェア開発者
課題感を持っているメンバーであれば誰でも開発に貢献することができる。
ソフトウェア開発の方はコードベースがプログラミング言語で記述されているので、プログラミング言語に造詣が深くないメンバー（例えばプログラミング経験に乏しいプロダクトオーナー）は貢献が難しい面があるが、これは難しいだけで貢献ができないということではない。
組織構造は自然言語で記述されているので比較的容易に貢献が可能だが、前述のプロトコルについては十分に理解している必要がある。
具体例
上記の対応により、ソフトウェア開発に携わる人であればどのように組織開発をしていくのかがある程度イメージできるようになったのではないかと思う。
ここでは具体的な例を持ち出してそのイメージをもう少し膨らませたい。
機械学習エンジニアの責務として本番で稼働する XYZ API の運用を追加したい
本番で稼働している XYZ API の運用をする人が明確に定まっておらず、エラーが起きたりするとそれに気づいた人が対応しているという状況を考える。 このように暗黙の期待となっている責務は属人化しやすく、なんかあったらあの人が対応してくれるよね、となって頑張った分だけ負担が増すという辛い状況になったりする。
これは組織にとって必要な機能が明確化されてない状況であり、組織構造の中に追加されるべきものである。
エラーの度に善意で対応していた人がこれでは組織として適切ではないと考え「機械学習エンジニアという役割に XYZ API の運用という責務を追加。なぜならばこれは重要な責務だが暗黙の期待となっているため。」という Proposal を送り、他の人が承認して明確化された責務として記載されるようになった。
Holacracy はこのように役割が果たすべき責務を明確化し、その役割に人をアサインするという仕組みになっている。 人をアサインする権限を持つ役割も存在し、Ubie Discovery ではやる気と能力がある人がアサインされることが多い（組織に必要なのに適任がいなければ採用を頑張らねばならない！）。
同じようなことをやっているチーム A とチーム B を合体してチーム C としたい
チーム A で働いている人が OKR すり合わせのためにチーム B と議論した結果、共通で開発した方がいい機能を別々にしかもちょっと違った形で開発していそうということが判明した。
この可能性に気づいた人は、共同で開発しないと後々有害になりうるしリソースも最適に活用できていないと考え、変更をしようと考えた。 影響が大きそうなので、チーム A,B の人から改めて情報を収集し議論を深めて、確かに弊害になりそうと確信したので「チーム C を作り、チーム A とチーム B は削除する。なぜならば元の二つのチームは似たことをやっていて、似てるけど異なる機能を作って弊害となりうるのとリソースの無駄遣いであるため。」という Proposal を送り、関係者が承認したのでチーム編成が書き換えられることとなった。
Ubie Discovery では実際にこのような流れで数日程度で大きな組織構造の変化が発生したりする。
ちなみに正確には Holacracy ではチームという概念はなく、サークルというある共通の目的をベースとして様々な役割を構造化する概念がある（ここでは簡単のためチームと同義語と思っておいてよい）。
この例は、ソフトウェア開発において複数箇所で同じようなコードが繰り返されていて共通化した方がよい、という状況に似ているかもしれない。
（補足）Ubie Discovery では組織開発をするのは Holon という人材
冒頭で Ubie Discovery ではみんな組織開発をするけど正確にはみんなではない、ということを書いたのでそれの補足をしておく。
Ubie Discovery における組織開発はソフトウェア開発と似ているという話をしてきたが、どちらもやるということは事業と組織に必要なあらゆる側面にコミットするということであり、それがマッチする人材もいればそうでない人材もいる。
マッチする人材を Holon 人材と名付け、少なくとも Holon 人材は全員組織開発にコミットする、ということになっている（Holon というのは Holacracy の語源となった単語で、部分であり全体であるというような意味）。
一方で、自身の特定領域にコミットし、事業のリターンを最大化するのがマッチする人材もいるし組織としても必要だという議論を経て、そのような人材を Focus 人材として定義している。 Focus 人材についてはスライドを公開しているので、詳しくはこちら: Focus 人材紹介の Google Slides へのリンク
余談だが、この Holon 人材や Focus 人材などの概念を作っていくところも、ソフトウェア開発において概念を作っていくところとの類似性があるなと感じる。 Ubie Discovery の組織開発という特定のドメインについて深掘りをしていくと、世の中でよく使われている概念とは異なるものであることに気づき、新たな名前を与えてそれを育てていく必要がある（Focus 人材は最初の頃は Specialist 人材と呼んでいたが、世の中でよく使われる意味とは異なることに気づき、混乱を避けるため敢えて独自の名前を与えたという経緯がある）。
ソフトウェア開発とあまり似てないところ
ソフトウェア開発とあまり似ていない部分としては、Proposal はそれによって困りごとが発生することが明確に示されない限りは基本的に承認されるという点である。
ソフトウェア開発では論理的に良し悪しを判定できるケースが多いので、その変更はふさわしくないのでこういう変更に書き直してください、などと言いやすいが、組織開発においてはそこまで明確に言い切れるケースは少ないためである。
チームトポロジーのような組織のデザインパターン的なものがもっと成熟していけば、もしかすると変わっていくのかもしれない。
まとめ
Ubie Discovery における組織開発をソフトウェア開発と対応づけて説明してみた。 どちらも不確実性の変化に対応するという目的があり、Holacracy による組織開発はソフトウェア開発の方法と類似性が高い。
興味が出てもっと詳しく聞いてみたいという人がいたらお気軽にご連絡ください！