はじめに
しくみ製作所で、ホラクラシーを導入して3年ほど経過しました。
3年経っているにも関わらず、きちんと運営したり、全体に浸透させるのって難しいなと感じていました。
特に気になっていたのは、権限を委譲するタイプのフレームワークなこともあり、サークルの階層が深くなればなるほど、情報が不透明になりやすいことでした。
元々、アジャイル開発の文化に馴染んでいたこともあり、透明・検査・適用の思想が強く、その感覚からすると、不透明性が高く感じていたんだと思います。
これまでそういった気づきがあると、歪として起票し、組織構造やポリシーで解消しようとしてきてはいたのですが、一度ゼロベースで現実を観察し直してみることにしました。
考え直していると、ホラクラシーをベースにしつつも、自分たちの会社に合致した軽いフレームワークが作れるんじゃないかと思うようになりました。
そこで、ホラクラシーの良いところは残しつつも、自分たちに適したフレームワークを作ることにしました。
そもそも、ホラクラシーって？
日本の人事部 によると以下のように記載されています。
ホラクラシーとは、「自律的なグループに決定権を分散させることで、それぞれのグループが能動的に活動できるようになる組織管理システム」のこと。
この説明は、コンパクトにホラクラシーを説明してくれていて、その通りですよね。自分の言葉でも、ざっくりホラクラシーの概要を説明してみたいと思います。
ホラクラシーでは、ガバナンスミーティングと呼ばれる意思決定の会議が規定されており、その会議で新しい役割（グループ）を作り、その役割（グループ）にどこまでの決定権を分散させるかを明示的に規定していきます。
役割（グループ）は、規模が拡大していくと同じルールで下の階層の役割（グループ）を作っていくことができます。役割（グループ）が下の階層を持つようになると、タクティカルミーティングと呼ばれる情報共有や戦略を話し合う会議を行うことも規定されており、階層が深くなってもある程度情報が伝搬される設計になっています。
これらのルールは、ホラクラシー憲法 にまとめられており、ルールの範囲内で自律的に動いていくことができます。
つまり、ホラクラシーは自律的な役割（グループ）を作り、階層的に権限を委譲していくフレームワークになっています。一言でまとめると、最初の「日本の人事部」の説明になりますよね。
下の図は、ホラクラシー導入直後の組織図です。役割（グループ）が小さい円で階層的に表現されているのが分かります。
ホラクラシー導入してみての感想
導入して良かった点
1 . 意思決定方式が明瞭になった
権限の分散方式・ルールの追加はガバナンスミーティングで、分散後は役割毎に委譲されていることが明瞭になりました。結果的に、どうやってモノゴトを決定していくかが明瞭になったのは良かったと感じています。それまで、小さなことでも誰が決めるのかが曖昧であったので、規模が大きくなるにつれて、課題感が大きくなっていました。その点はホラクラシーのフレームワークのポイントでもあり、改善したなと感じました。
2 . 役割ベースで柔軟だった
役職でははなく、役割制になっており、ヒトには上下がなく自由に組み替えられるのも良かったと思います。ただ、役割に対して長期的なアサインがかかっていたり、役職的に運用もできるので、運用が長くなるうちに、徐々に旧来型のヒエラルキー的な側面もでてきていました。
フィットが難しかった点
1 . ルールが重たい
そもそもの文章が長いので、みんなが理解して実行することは大変だなと感じていました。DAOのような実装があれば良いのですが、基本的には人間系での運用することになるので、憲法の内容も解釈がずれる部分が残ります。また、改善しにくい具体的すぎる部分もあり、ルールに対して現実を寄せていく行為が、シンプルに高コストだと感じるようになりました。
2 . 縦割り感・情報の不透明性
運用の問題もしれませんが、階層があると縦割り感が強くなっているように感じました。権限を委譲する設計思想なので、委譲後は以外と不透明なんですよね。自立分散しているのは良いのですが、全体として透明・検査・適用のような改善ループを回したいというのは根底にあり、そのことと委譲の構造の噛み合わせがあまり良くないなと感じてきました。
3 . 会議が規定されすぎている
役割（グループ）の階層構造に沿った会議（タクティカルミーティング）が規定されており、柔軟性が低く感じました。タクティカルミーティング以外にあれこれ勝手に会議をやっても良いのですが、規定されている会議があると、規定されていることだけを実行していく傾向があって、会議やコミュニケーションを考えて、改善する機会自体が減っていく感覚がありました。
通常の開発のプロジェクトでは、誰とどのように会議をするかを設計しているので、普段に比べて設計・改善できていない感覚になっていました。
新しいフレームワークで改善したいこと
ということで、ホラクラシーの役割（グループ）やガバナンスミーティングなどの概念は残したまま、以下3点を改善したフレームワークを考えることにしました。
- 軽いフレームワーク
- 情報の流れ
- 会議規定は減らし、各自が必要なコミュニケーションを考える
ホラクラシーのときよりも、情報の淀 がないことをテーマとして取り組むことにしました。
また、完全に委譲するというよりも、会社運営に関わる人と、そうでない人はゆるやかに分けてしまって、運営に関しては全体で情報を共有して、全体感を持った上で動的に動いていくイメージにしたいと思いました。
憲法から宣言へ（1. 軽いフレームワークにする）
そもそも「憲法」というと、日本語だと重たい印象があり、憲法という言葉自体を止めつつ、全体的に文章量を少なくしました。
また、アジャイルソフトウェア開発宣言 を参考に、自分たちの組織運営で大切だと思う部分をまとめました。正直、これらの原則が守られているのであれば細かい話は不要なのではとも思っています。
以下、宣言の冒頭の抜粋になります。
私たちは、ソフトウェア開発における組織運営の実践あるいは実践を手助けをする活動を通じて、
よりよい運営方法を見つけだそうとしています。この活動を通して、私たちは以下の価値に至りました。
- 理想的なルールやプロセスの遵守よりも、現実の事象や個人の尊重を、
- 整理された報告よりも、透明な情報を、
- 歪がないことよりも、歪が共有されて改善される環境を、
- 正しい指示に従うよりも、間違ったとしても自律的な判断を、
価値とします。
すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおきます。こうして見てみると、ソフトウェアの開発が中心なので、素早く改善していくということがベースになった思想が多いなと感じます。
階層性の削除（2. 情報の流れ）
組織のサークルは1つとして、役割（グループ）は完全にフラットにしました。つまり、階層性がなくなりました。全体での役割（グループ）の数は10-15程度に減らし、必要であればより削減していこうと思っています。
役割内での活動は、プロジェクトやプロセス（日々の繰り返し）のどちらかとし、役割とは別の概念として分離することにしました。
例えば、代表者印の押印のような小さい役割はプロセス、システム開発プロジェクトはプロジェクト、などというように分類していきました。
結果として、会社の運営上必要な役割（グループ）は最小とし、必要なリソースも最小化されました。このように運営上必要な役割（グループ）を最小化するという意味から、コンパクトガバナンスの名前もつけました。
初期構造で作った組織図はこちらになります。
図はフラットなので特に位置関係は意味はないのですが、近い役割（グループ）の情報を2次元で表示し、関係性が近いもの同士が自然と連携できるようにしていこうと考えました。
会議は各自が考える方式に（3. 会議を考える）
元のホラクラシーのまま、役割（グループ）をフラットにしてしまうと、その役割（グループ）にアサインされている人達全員を集める巨大な会議を開く必要がありました。
人数が多い会議では、報告的な会議になってしまうことが予想され、効果が薄くなるなと感じており、今後はそのような会議は避けたいと思っていたので、会議については、必要な人が必要な会議を設計する方式にしました。
役割（グループ）がフラットになり、1枚絵になったので、サッカーのポジション・フォーメーションのようにも見えてきて、誰がどことパスを出すか（コミュニケーションを取るか）、自分が必要ならそこに入ったほうが良いのでは、なども考えてもらいたいなと思っています。
これまで、組織構造が悪く、別の役割（グループ）と会話しにくいみたいな話もあったのですが、各自フラットにどことどのようなコミュニケーションを取ると良いのかを考えて、勝手にコミュニケーションを取れば良くなったと思います。
ただ、ガバナンスミーティングだけは全体でやるということは残しており、全体で話すべき重要なことは全体で取り扱おうと思っています。
導入後の様子
まだ、導入して1ヶ月も経過していないのですが、下のロールへの権限移譲を考えなくてよくなったので、自分のロールの目的を考えたり、全体像を見る時間が増えたなと感じています。コミュニケーションについては運用に全振りしているので、これからが課題になっていくのかなと感じていますが、今後どうなるのかしばらく観察しながら、改善していければと思っています。
