プラクラシー

PrAha独自のホラクラシーである「プラクラシー(PrAcracy)」のルールを明記したページです。

プラクラシーとは？

プラクラシーは、ホラクラシーをPrAhaに適した形にアレンジした組織体制のことです。

ホラクラシーは、明確な役職や上下の階級を設けず、誰もが意思決定できるフラットな組織体制を指します。

なぜプラクラシーが必要なのか

PrAhaは2021年頃にホラクラシーを採用していました。

しかし、以下の2点の理由から意識する機会がほとんどありませんでした。

• 覚える用語やルールが多すぎた
• 独立したプロジェクトに取り組む社員が多かったためホラクラシーで社内を整理するまでもなかった

ただ、2022年6月にアガルートにM&Aした影響で、アガルートの自社サービス開発がはじまり、採用活動も活発化し、相互作用する仕事が増えてきました。

ですので、ホラクラシーでの経験を踏まえた上で、プラクラシーを導入することにしました。

プラクラシーの目的

以下の2つです。

1. 社員が能力を最大限に活かせる状態を作ること
2. マネージャーが居なくても回る会社を作ること

1. 社員が能力を最大限に活かせる状態を作ること

以下の3つが重なった仕事を任されたとき、人の力は最大化されると考えています。

• 自分がやりたいこと
• 自分ができること
• 周りに役立つこと

全社員がそんな仕事を持てるようにすることがプラクラシーの目的です。

2. マネージャーが居なくても回る会社を作ること

ものづくりが好きな人が集まっている弊社ではマネージャーをやりたがる人が少ないので、マネージャーの役割を分割して仕組み化して、マネージャー不在でも回る会社を作る方が建設的だと考えました。

プラクラシーのルールを理解する

ルールを列挙しても覚えづらいと思うので、新人が入社したものとして社内のルールを解説します。

「まとめ」と書いてある部分だけ読んでいただいても大丈夫です。

プラハの勤務初日

新人「今日からプラハに入社だ！頑張ろう！」

プラヲ「君が新人くんだね！僕は新入社員のフォローチームのリーダーをしているプラヲです！」

新人「チーム？リーダー？ よくわかりませんがよろしくお願いします。早速ですが、僕は今日から何をすれば良いですか？」

プラヲ「新人くんは、プロジェクトAの開発というチームにアサインされているから、詳しくはそこのリーダーに聞いてみてね」

新人「わかりました！」

まとめ

• チームという概念がある
• チームにはリーダーがいる

チームとは？

新人「おはようございます、新人です！プロジェクトAのリーダーさんはいますか？」

A男「どうも、プロジェクトAのリーダー、A男です！」

新人「まだ会社のことがよくわかっていないのですが、チームって何ですか？」

A男「チームというのは1名以上の社員から構成される組織の最小単位で、一般的な会社で言う「課」と思ってもらえたら大丈夫だよ」

新人「なるほど。部とか事業部は存在しないんですか？」

A男「プラハにはチームしか存在しないよ。以下の階層構造になることはあるけど、名前は全部一貫してチームだよ」

• チームの上に別のチームがある
• チームの中に他のチームがある

新人「何となくわかりました。ところで、ここは何をするチームなんですか？」

A男「それを説明するには、チームの目的から話さないといけないね。チームにはすべて目的があり、その目的は以下によって定義されているんだ」

• 背景
• Objective
• 責務
• 権限
• Key Results

新人「Objective？責務？よくわからないです」

A男「まずはこのチーム↓を例に見てみようか。全部書き出すと大変だから一部抜粋して紹介するよ」

## チーム名
- プロジェクトAの開発
　
## 背景
- 昨年の売上は過去5年で最も伸び幅が少なかった。
- 市場を取り尽くしてしまったことが要因として考えられるため、新たな市場にサービスを提供する必要がある
　
## Objective
- 関係者と合意した期日までにサービスAの全機能をリリースし、全社売上の5割を超える事業を作ること
　
## 責務
- リリース日を変更する必要が生じたら関係者と合意形成すること
- 合意したSLAをリリース後も満たせるよう運用すること
　
## 権限
- 追加で3名までエンジニア・デザイナーを採用してチームに加える権限
- リリース日を決定する権限
　
## Key Results
- マージできたPRの数(週次)
- 次回リリース予定の機能とリリース予定日(週次)
- 全機能のリリース予定日(月次)
　
## 目を通しておくべき情報
- (何らかのURLへのリンク)

新人「なんだか、1つのチームに対してずいぶん色々と細かく明文化されているんですね」

A男「これがプラクラシーのキモとも言える、暗黙の期待を作らないことに繋がるんだ」

まとめ

• チームは組織の最小単位
• チームの中にチームが入っていたり、チームは階層構造になる
• チームには、以下が必ず明文化されている
  • 背景
  • Objective
  • 責務
  • 権限
  • Key Results
  • 目を通しておくべき情報

暗黙の期待を作らない

新人「暗黙の期待？」

A男「上司が 「こういうことをしてくれるだろう」と暗黙的に期待していることが多いと、やって欲しいこととやることのミスマッチが起きやすいんだよね。そうならないように仕事を頼む上で大事なポイントは明文化しておくのがプラクラシーなのさ」

新人「明文化しておけば誤解も起きづらいですもんね。完全に理解しました！ただ、「背景」とか「Objective(直訳:目的)」は何となくイメージがつくんですが、「責務」ってなんでしょう？Objectiveだけじゃダメなんですか？」

A男「まず前提として、チームはObjectiveを達成する手段を制限なく自分達で自由に考えて良いんだ。例えばサービスAを作ることがObjectiveだとしたら、自社のエンジニアで作るのではなく外注する選択肢もあるよね」

新人「え、そんなことまでA男さんが決めていいんですか？」

A男「理論的にはね！ただ、このチームの1つ上に位置するチーム のリーダーからこのチームを託されたときのアサインミーティングで質問してみたら、今回は自社エンジニアで開発して欲しいと回答されたので、外注は選択肢から除外したよ。それ以外のことは基本的にリーダーの僕が決めていいんだ」

新人「へ〜、色々決められているけど、決められたことの達成方法は自由に任されているんですね」

A男「その通り。何がほしいかは伝えるけど、どう実現するかは指示しない。それがプラクラシーの基本だ」

まとめ

• 暗黙の期待がコミュニケーションミスを生む
• 暗黙の期待を作らないために、徹底的に明文化する
• チームのObjectiveは決まっているが、その達成方法はチーム内で自由に考えて構わない

責務とは？

新人「目的を達成する方法はチームが自由に考えてよし、と」

新人「あれ、でも責務はやるべきことをかなり具体的に指示していませんか？」

A男「そうだね。目的の実現方法は基本的に任せるけどこれだけは必ずやってほしい、という行動が責務として記載されるんだ。あまりにも想像と違うことをされてしまうと、周りが困ってしまうからね」

新人「なるほど。プロジェクトAの場合『リリース日を変更する必要が生じたら関係者と合意形成すること』って責務が加えられていますね。この仕事の進め方だけは絶対に守ってほしい、ってことか」

A男「そんなイメージだね！」

新人「期待されるSLAを守ること、って責務も書いてありますね。期日通りにリリースされても品質がボロボロだとダメだから、それを事前に責務として明言してくれているんですね」

A男「そうそう。ただ、このチームのObjectiveに「全社売上の5割を超える事業を作る」って書いてあるよね。仮にSLAが責務に書かれていなかったとしても、ボロボロのサービスでこの目的が達成できるとは思えない。となると品質面も妥協できないことは自分達でも判断して考えるべきなんだ。

細かく明文化すると「それは書いていないのでやりません」っていうマニュアル文化が生まれがちだけど、それはプラクラシーの本質を理解していないんだよね。暗黙の期待を減らして合意形成を支援するための明文化であって、ここまでやればOKと思考停止するための明文化ではないからね」

新人「暗黙の期待を避けるために期待を明文化するけど、書かれた内容に盲従するだけではいけないんですね。難しい」

A男「最初は難しいけど、徐々に慣れてくるよ！じゃあ早速このチームで明日から働きはじめてもらおうか」

新人「はい！」

まとめ

• 基本的な仕事の進め方は自由。ただしこれだけは必ずやって欲しい、というタスクはチームの「責務」として明文化される
• 暗黙の期待が生まれてしまうのを避けるために明文化するが、明文化されたこと以外はやらなくて良いというマニュアル文化が生まれてしまうのは本来意図していることではない

権限

（数日後）

A男「新人君おはよう。最近仕事で困っていることはない？」

新人「あります！会社横断の基幹サービスと連携する部分を書いているのですが、このコードレビューは誰にお願いすれば良いのでしょうか？」

A男「ちょうどいい質問だね！チームに与えられた権限について話そうか」

A男「改めてこのチームの権限を振り返ってみよう」

## 権限
- 追加で3名までエンジニア・デザイナーを採用してチームに加える権限
- リリース日を決定する権限

A男「ここには基幹サービスに関することは特に書いていないね。じゃあ改めて僕らの会社の組織図を見てみようか↓」

praha
├── オンボーディングチーム
│   └── 新入社員のフォローチーム
├── ミラクル新規事業チーム
├── 営業チーム
├── 情報整理チーム
├── 経理チーム
└── 開発チーム
    ├── プロジェクトAの開発チーム <- イマココ!
    ├── Bプロジェクトの開発チーム
    ├── DX改善チーム
    ├── 技術力底上げチーム
    └── 基盤開発チーム 👈 

A男「この組織図を見た感じ、基盤開発チームが関係してそうだね。ここの権限を見せてもらおう↓」

## 基盤開発チームの権限
- 基盤サービスに向けられたPRのレビュー及び取捨選択

新人「あ、それっぽいことが書いてある！」

A男「基盤サービスのコードレビューはこのチームの権限だから、このチームに頼まなければいけないことがわかったね」

新人「こういう風に権限が明文化されていると、誰が何をやって良いのかわかりやすくて便利ですね」

A男「同じ会社で働いていると、複数のチームが同じリソースを共有することが多々あるからね。 リソースに対する操作がバッティングしないように、誰がリソースに対する権限を持っているのか明記しておく必要があるんだ」

新人「完全に理解しました」

まとめ

• チームには「権限」が与えられる（与えられないこともある）
• 誰がどのリソースに対して何の権限を持っているのか、が権限の項目には明記される
• 複数チームが同じリソースに対して競合する作業を行なうことを防ぐためにある

Key Results

（数日後）

A男「そろそろKey Resultsを報告する時期だから、今週このチームでクローズされたPRの数を集計して報告してもらっても良いかな？」

新人「Key Results？」

A男「まだ説明してなかったね。じゃあこのチームに与えられたKey Resultsを振り返りながら説明しよう」

• マージできたPRの数(週次)
• 次回リリース予定の機能とリリース予定日(週次)
• 全機能のリリース予定日(月次)

A男「うちのチームにはこういうKey Resultsが決められているから、1つ目のKey Results「マージできたPRの数」を毎週集計してspreadasheetを更新しているわけだよ」

新人「要は1つ上のチームリーダーに報告する内容ってことですかね？」

A男「チームの階層構造についてしっかり覚えているみたいだね！ひとまずそう捉えてもらって構わないよ。例えばうちの組織図で言うと「開発チーム」は「プロジェクトAの開発チーム」とか、1つ下のチームのKey Resultsには興味があるだろうね」

praha
├── オンボーディングチーム
│   └── 新入社員のフォローチーム
├── ミラクル新規事業チーム
├── 営業チーム
├── 情報整理チーム
├── 経理チーム
└── 開発チーム 👈このチームのリーダーは
    ├── プロジェクトAの開発チーム 👈このチームのKRを知りたい事が多い
    ├── Bプロジェクトの開発チーム 👈このチームのKRを知りたい事が多い
    ├── DX改善チーム 👈このチームのKRを知りたい事が多い
    ├── 技術力底上げチーム 👈このチームのKRを知りたい事が多い
    └── 基盤開発チーム 👈このチームのKRを知りたい事が多い

新人「ひとまず？ってことは、例外があるんですか？」

A男「その通り。プラクラシーで特徴的なのは、KRは社内の誰にいつ要求されても、必ず開示する必要があるということだね」

新人「え！じゃあ僕がミラクル新規事業チームとか、全然自分が関係ないチームにKRを聞いても教えてくれるんですか？」

A男「そうだよ。プラクラシーで大事にしているのは情報の透明性だから、上長とかを経由することなく直接あらゆるチームのKRを閲覧できるようになってるよ」

新人「へ〜。でも全然関係ないチームにしょっちゅう聞かれたら面倒臭そうですね」

A男「そうなんだよね。だから大体のチームは「KRに興味ある方はこちらをみてください」とわかりやすく組織図にリンクを貼っていたりするよ。こうすれば見たい人は勝手に見て解決できるから」

新人「そうやって情報の透明性を担保していくんですね。了解です、集計してきます！」

まとめ

• チームはKey Resultsに定められた頻度で指標を更新し、閲覧可能な状態にしなければいけない
• KRは社内の誰にいつ要求されても必ず開示する必要がある
• この仕組みを通して情報の透明性を担保していく

tension

(数日後)

新人「うーん」

A男「何かお悩みの様子だね」

新人「あ、お疲れ様です。最近DX改善チームから「こういうツールを入れてください」と言われたんですが、逆に技術力底上げチームからは「外部ツールに頼らず可能な限り自前で作りましょう」と言われて、どちらのいうことを聞くべきなのか困惑してるんですよね」

A男「なるほど、それはプラクラシーの「tension」だね。プラクラシーにおけるtensionは、あるべき姿と現状が乖離していて、それにより不都合が生じている状態、という定義だよ」

A男「例えば今回のケースでは、新人くんは2つのチームから異なる指示を受けてどう動けば良いかわからなくなってしまった。これは本来あるべき姿ではないと思うんだ」

新人「そうですね。前にも似たようなことが起きたので、組織を横断して技術力を高めるチームが1つにまとまっていた方が良い気がします。A男さん、なんとかしてくれませんか？」

A男「え？どうして？」

新人「えーと、A男さんは僕の上司だから？」

A男「プラクラシーに上司とか部下という概念はないよ。僕は自分のチームのリーダーではあるけど、新人くんの困りごとをすべて解決するのはリーダーの役割ではないんだ。だからtensionに関しても、それを感じた本人が解消に向けて動くことが求められるよ」

新人「えー、そんなー！僕は誰に相談すればいいんだろう」

A男「とはいえ、役割じゃないからといって困っている人を見捨てて良いわけではないから、僕ができる限りの支援をしよう。まず開発チームのリーダーに引き合わせるから、その人に相談してみようか！きっと開発チームのリーダーならこのtensionの解決に一役買ってくれるはず」

A男「今から開発チームのリーダーに会いに行こう」

まとめ

• あるべき姿と現状が乖離していて、それにより不都合が生じている状態をtensionと呼ぶ
• tensionを解決するのは、tensionを感じている本人の責務
• 周りはtensionを解決しようとしている人をできる限り支援することが求められる

tensionからチームが再構成される瞬間

（2人でオフィスを移動する）

A男「安倍さん、お疲れ様です」

安倍「お疲れ！」

A男「うちのメンバーが現状のチーム構造にtensionを感じているみたいなので、相談させてもらえないでしょうか。安倍先輩は開発チームのリーダでしたよね？」

安倍「いや、俺は先週リーダーを他の人に頼んだよ。もう少しコードを書く方に集中したくてさ」

A男「あ、そうだったんですね。誰が今リーダーやってるんですか？」

安倍「組織図に反映しておいたから、そこを見ればわかるよ」

praha
├── オンボーディングチーム
│   └── 新入社員のフォローチーム
├── ミラクル新規事業チーム
├── 営業チーム
├── 情報整理チーム
├── 経理チーム
└── 開発チーム リーダー: 安倍->岸田(4月1日から)
    ├── プロジェクトAの開発チーム リーダー: A男
    ├── Bプロジェクトの開発チーム
    ├── DX改善チーム
    ├── 技術力底上げチーム
    └── 基盤開発チーム

A男「了解です！えーと、岸田さんか。ありがとうございます！」

（2人でオフィスを移動する）

A男「岸田さんお疲れ様です。うちのメンバーがtensionを感じているらしいので、少し相談に乗っていただけないでしょうか？」

岸田「いいよー」

新人「えーと、実はかくかくしかじかで」

岸田「あー、確かにそのtensionは他の社員からも聞いたなぁ。今2つに分かれているチームのリーダーは、麻生さんと小泉さんか」

praha
├── オンボーディングチーム
│   └── 新入社員のフォローチーム
├── ミラクル新規事業チーム
├── 営業チーム
├── 情報整理チーム
├── 経理チーム
└── 開発チーム
    ├── プロジェクトAの開発チーム
    ├── Bプロジェクトの開発チーム
    ├── DX改善チーム リーダー: 麻生さん <- この2つのチームをまとめようかな
    ├── 技術力底上げチーム リーダー: 小泉さん <- この2つのチームをまとめようかな
    └── 基盤開発チーム

岸田「俺がリーダーを務めているチーム内の統廃合に関しては俺が決められるから、1つのチームにまとめることにしようか」

新人「やった！」

岸田「ただ今回のチーム統合により新たなtensionが生まれるといけないから、次の開発チーム定例で開発チーム配下のリーダーを集めて話し合ってみるよ」

新人「僕の提案をきっかけにチーム構成があっという間に変わってしまった。すごいスピード感だ」

岸田「tensionを報告した当事者として君もミーティングに参加してね」

新人「あ、僕も参加するんですね」

岸田「そりゃそうさ。もしかしたらチームを統合する以外の解決策が提案されるかもしれない。新しく提案された解決策が本当にtensionを解消できるか、tensionを報告した君が一番よく判断できるだろう」

新人「えー！チームの統廃合に関わる大事な話が、僕のtensionに対する意見で決まっちゃっても良いんですか？僕の意見でプジョルさんとシャビさんのどちらかがリーダーではなくなってしまうのは、なんだか申し訳ないというか」

岸田「プラクラシーでは、チームの統廃合とか、誰がどれだけ上のチームのリーダーだとか、そんなのは些細なことだ。状況が変化しているのに組織だけ変化しないままtensionが放置されることは、何としても回避しなければいけない。最高だと思っていた組織形態も、社員が増えることで破綻することがあるだろう？そうならないためにも、状況に合わせて組織が有機的に変わっていく必要があるんだ」

新人「組織全体がすごく柔軟なんですね。わかりました、責任持ってtensionを定例で報告します！」

(そして数日後、定例での話し合いにより麻生さんのDX改善チームは「技術力底上げチーム」に統合された)

praha
├── オンボーディングチーム
│   └── 新入社員のフォローチーム
├── ミラクル新規事業チーム
├── 営業チーム
├── 情報整理チーム
├── 経理チーム
└── 開発チーム
    ├── プロジェクトAの開発チーム
    ├── Bプロジェクトの開発チーム
    ├── 技術力底上げチーム
    └── 基盤開発チーム

まとめ

• プラクラシーでは、tensionを解消するためにチームが新しく誕生したり、統廃合されることがある
• 自チーム内の構成を変える（新しく作る、変える、消す）権限はチームのリーダーに移譲されている
• ただしチーム構成を変える際は、新たなtensionが生まれないことに留意しなければいけない
• 大事なのは、組織がどんな状態になっていればtensionを最小限に抑えられるか考えること
• 状況の変化によって新たなtensionが生じたら、tensionを解消するために組織も変わっていかなければいけない
• 置かれた状況と組織のミスマッチによるtensionを防ぐことがプラクラシーの最大の目的

リーダー交代

（数か月後）

A男「新人くん元気？」

A男「ちょっと突然だけどプロジェクトAのリーダーを他の人に任せることになったから、それを共有したくて」

新人「え！どうして降格に？何か悪いことしたんですか？」

A男「降格ではないよ！リーダーはあくまでポジションの1つで、偉いわけじゃないからね。インフラエンジニアがフロントエンジニアになるぐらいの話さ。どっちの方が偉い、とか考えないだろ？」

新人「確かに」

A男「どうしてリーダーをやめるかと言うと、僕はミラクル新規事業チームのメンバーでもあるから、そっちにもう少し時間を使いたくてね」

新人「そうなんですね。その場合プロジェクトAのリーダーは不在になるんですか？」

A男「チームのリーダーが居ない場合、1つ上のチームのリーダーがそのポジションを担うから、今回の場合は岸田さんが暫定的にプロジェクトAのリーダーだね」

新人「なるほど。岸田さんも開発チームのリーダーをやめた場合は、praha全体のリーダー、つまりCEOがプロジェクトAのリーダーになるってことですね」

A男「そうそう」

新人「だいぶプラクラシーの組織構造がわかってきました。明日から岸田さんがリーダーか〜どんなチームになるんだろう、楽しみだな」

（翌日）

岸田「えーと、いた！新人くん、ちょっとこっち来て」

新人「？」

岸田「君をプロジェクトAのリーダーにアサインするから、アサインミーティングやろうか」

新人「へ？僕がリーダーですか？」

岸田「うん。A男くんから聞いた推薦理由にも納得感があったし、プロジェクトAのメンバーに聞いても新人くんが良いってことだったからさ。君に決めた」

新人「それは光栄です、頑張ります！とは言ったものの、プロジェクトAのリーダーって何をすれば良いんです？」

岸田「それを説明するのがアサインミーティングだな。早速始めよう」

まとめ

• リーダーが交代することもある
• チームにリーダーが居ない場合、1つ上のチームのリーダーが、リーダーを兼任する
• 誰かをリーダーにアサインするときはアサインミーティングを行なう
• リーダーはポジションの1つなので、昇格や降格という概念は不適当

アサインミーティング

岸田「アサインミーティングは2部構成だ。まずは前半でチームの目的を説明するために、背景、OKR、権限などを伝える 。このチームの概要を振り返ろう」

## チーム名
- プロジェクトAの開発
 
## 背景
- 昨年の売上は過去5年で最も伸び幅が少なかった。市場を取り尽くしてしまったことが要因として考えられるため、新たな市場にサービスを提供する必要がある
 
## Objective(目的)
- 関係者と合意した期日までにサービスAの全機能をリリースし、全社売上の5割を超える事業を作ること
 
## 責務
- リリース日を変更する必要が生じたら関係者と合意形成すること
- 合意したSLAをリリース後も満たせるよう運用すること
 
## 権限
- 追加で3名までエンジニア・デザイナーを採用してチームに加える権限
- リリース日を決定する権限
 
## Key Results
- マージできたPRの数(週次)
- 次回リリース予定の機能とリリース予定日(週次)
- 全機能のリリース予定日(月次)

岸田「ここに書かれている内容で、理解できないことはある？」

新人「ないです。チームのobjectiveとか前々から明文化されていたので」

岸田「よし。アサインミーティングの後半はアサインされた側からの質疑応答の時間だ。こっちがメインだから、好きなだけ聞きたいことを聞くと良い」

新人「じゃあ権限について。エンジニアを増やす権限については言及されていたと思うんですが、減らす権限はありますか？」

岸田「ある。Objectiveを達成できていてKey Resultsも順調なら、どれだけの人員でプロジェクトを遂行するかは君が決めていい。他に何か聞きたいことはないか？」

新人「では続いてKey Resultsについて。「全機能のリリース予定日」をKRから削除しても良いですか？これまでも滅多に当たることがない不正確な数値だったので、KRとして報告する必要もないと思いまして」

岸田「ふむ。無意味なKey Resultsは削除した方がよさそうだが、全機能がリリースされるタイミングは知っておきたいな。理由はこの機能のリリースに合わせて盛大にCMを打つ予定だからだ。開始時期を決める情報が欲しい。何か他の形で有益な情報を出してもらえないか？」

新人「わかりました。どんなKRが適しているかチームとも会話してから提案しても良いですか？」

岸田「大丈夫だ。ではKRに関してはこれにて完了。他に何か聞きたいことはないか？」

新人「チームの中をさらに細かく複数のチームに分けて、そのなかでリーダーをアサインしても大丈夫ですか？」

岸田「大丈夫だ。 それはこのチームに限らずチームリーダーに等しく与えられた権利だ。好きなように細分化してくれ。 他に何か聞きたいことはないか？」

新人「Objectiveに書かれている『全社売上の5割を超える事業』って結構しんどいので、3割に減らすことはできませんか？」

岸田「だめだ。5割は死守してほしい」

新人「どうしてですか？」

岸田「そうだな、ここについては俺も背景を詳しく知らないobjectiveになっていたな。PrAhaのリーダーに理由を聞いて、後日君に共有しよう。他に何か聞きたいことはないか？」

新人「いえ、ありません！」

岸田「よろしい。ではアサインミーティングは終了だ」

まとめ

• チームのリーダーに誰かをアサインする際は、必ずアサインミーティングを実施しなければいけない
• アサインミーティングは、チームの目的を伝える時間と、質疑応答の時間に分かれた２部構成
• チームの目的が明文化されていれば前半はアッサリ終わることが多い
• 後半は好きなだけ質問をする
• チームの中をどう分割するかはチームリーダーが決めて良い

リーダーを交代したくなったら？

新人「あ、最後に。リーダーを誰かに譲りたい、あるいは辞めたいと思ったら、いつでも実行して良いんですか？」

岸田「時期は君が判断して良い。このチーム、同じ階層の他チーム、上下のチームに新たなtensionを生じさせない方法とタイミングを君が考えるんだ」

新人「タイミングは自分が決めていいんですね」

岸田「ただリーダーをやめる場合、自分1人で最適な判断を下せるケースはほとんどないと思った方が良い。周りに相談して、意見を集めて、tensionが生まれないことを確認してからやめるんだ。自分では大したことないと思っていても、周りから見たら影響が大きいことはあるからな。特に1つ上のチームリーダーには相談した方が良いだろうな」

新人「逆に僕が残りたくてもリーダーではなくなることもあるんでしょうか？」

岸田「ありえるな。1つ上のチームのリーダーが必要だと判断したら、下のチームのリーダーを代えることもあるだろう。その時は「今のリーダーのままだとこのようなtensionが生じているから、リーダーを代える必要がある」といった具合に、どういうtensionを解決するためにリーダーを交代するのか説明した方が良いだろうな」

新人「なるほど。チームを新しく作るのはtensionを解決するため、チームを減らすのもtensionを解決するため、リーダーを代えるのもtensionを解決するため。組織再編で生じるすべての出来事がtensionを解消するために行なわれなければいけないんですね」

岸田「飲み込みが早いな。他に質問はあるか？」

新人「いえ、ありません！」

岸田「よし。じゃあアサインミーティングは終了だ」

新人「いっぱい質問したのに、全部答えてくれてありがとうございます」

岸田「アサインミーティングで質問に答えるのはアサインする側の義務だ。 気にするな。明日から頼んだぞ」

新人「はい！」

まとめ

• リーダーをやめるときは、同じ階層のチームや上下のチームに新たなtensionを生じさせない方法とタイミングを考えて、自分で決める
• 最適な方法とタイミングを自分1人で判断できることはほとんどない。少なくとも1つ上のチームのリーダーには相談した方が良い
• リーダーの任命権は1つ上のチームリーダーが持っているため、時には自分の意思に反してリーダーを交代することもある
• あらゆる組織再編はtensionを解消するために行なわれる
• 質問に答えるのはアサインする側の義務なので、アサインされる側は好きなだけ質問をして構わない

チームにメンバーを増やしたくなったら

（数日後）

岸田「調子はどうだリーダー」

新人「やばいです。全然タスクが終わりません。リーダー業務に圧倒されて全然実装時間が取れないから、開発スケジュールが押しちゃってます。もう1人メンバーが欲しいですね」

岸田「そうか。メンバーを増やせばいいんじゃないか？」

新人「確かに、そろそろ増やしても良いかも。でもどうやって増やせばいいんですかね？」

岸田「めぼしいやつを見つけたら声をかけて、承諾されたらアサインミーティングをするだけだ」

新人「言ってしまえば他のチームから引き抜くってことですかね？」

岸田「そういうことになるな」

新人「でも、声をかけた人が元々いたチームから、誰もいなくなってしまうこともありますよね？」

岸田「それは仕方のないことだ。そういう状況が起きるからこそ自分のチームを魅力的に保つインセンティブがリーダーに働いて、組織全体の浄化作用が働く」

新人「ひえー、結構シビアですね。誰もいなくなったチームが会社にとってすごく大事だったら、どうするんですか？」

岸田「PrAhaのリーダーが1人でやることになるだろうな。限界が来たらまた新しいチームを作って、別のリーダーに移譲することになるだろう」

新人「すごくダイナミックに組織が統廃合していきますね」

岸田「そうだ。絶えず変化する環境に対応するにはそれぐらい組織自体も変わっていかなければいけないからな」

新人「じゃあ、チーム間の引き抜きは遠慮なく行なうということで。ところで兼務もありですよね？」

岸田「兼務も可能だ」

新人「引き抜くチームのリーダーと調整する必要はありますか？」

岸田「調整の責務は、まず声をかけられたメンバーにある。チームを抜けたら、普通はtensionが発生するからな。**引き継ぎをする、自分の仕事を自動化する、代わりのメンバーを探す、リーダーに相談する。**こういう行動を通して tensionの発生を最小限に抑えた上でチームを移動する。 それがスマートな社会人だ」

新人「逆にリーダーは何もしなくても良い、ってことですかね？」

岸田「そんなことはない。場合によってはチームリーダー同士で移動時期や方法について話し合う必要もあるだろう。想定外のチームが関わることもあるから全体定例会などで情報を周知することも考えた方が良いだろうな。誰かがチームを移動する場合は、その移動に関連する全員がtensionを最小限に抑えることに注意する必要がある。プラクラシーの場合はリーダーのみならずメンバーも注意しなければいけない、という話だ」

新人「そういうことか。メンバーに求める立ち回りが普通の会社よりも多いですね。普通はそういうのは全部リーダーに任せるものだと思ってました」

岸田「良いポイントだ。普通の会社は社員を子供扱いする。子供に過度な自由を与えると何をしでかすかわからないし、まだ自分の行動に責任を取れない。だから分別ある大人が管理する必要がある、というのが根本的な思想だ」

岸田「プラクラシーでは社員を大人扱いする。大人なら自分がどう動いたら周りのチームにどんな影響が出るか考えられるし、自分の行動に責任を取れる。自由を与えても適切に扱えるから誰かが管理する必要はない、というのが根本的な思想だ」

新人「そのぶん求められることは多い、ということですね」

岸田「その通りだ。だからチームを移動する際も、自分がどう行動すべきかはメンバーが判断するのが基本だ」

新人「プラハって自由な社風だな〜と感じていたんですが、周りに配慮することが結構多いですね。思ったより窮屈かも？」

岸田「自由と身勝手は別だからな。プラハの社員なら他者の自由を侵害することなく、会社の成長を促進するために自由を適切に扱ってくれる、という信頼関係が根底にあるんだ。例えばプラハでは就労時間を管理していないだろう？」

新人「そういえば確かに。サボろうと思えばいくらでもサボれますよね」

岸田「しかし君がサボったら誰かが君の仕事をカバーする必要があるから、 君の行動が他人の行動を制限する。それはただの身勝手だ。 プラハの社員なら自由と身勝手の違いを理解して行動できる大人であると、会社が君を信頼している」

新人「その信頼が裏切られたとしても、プラクラシーを続けるんですか？」

岸田「普通は裏切られたタイミングで経営方針を見直して、ルールと管理を増やして、普通の会社に近づいていくのだろうな。だが、たかだか一度や二度の痛みで、プラハの社員が長い時間をかけて築き上げてきた信頼関係を壊してしまうのは勿体ないことだと俺は思う。これから入社する人にも、この信頼関係を大事にしてほしい」

新人「わかりました。今回の話を踏まえて、1人声をかけてきます！」

まとめ

• チームにメンバーを増やしたくなったら、自由に他のメンバーやリーダーに声をかけて構わない
• チームは兼務することも可能
• ただしメンバーのチーム移動によって生じるtensionが最小限に保たれるよう、移動に関わる全員が配慮する必要がある
• プラハは社員を大人扱いする。管理されなくても自分の行動に責任をとれることが期待されている
• プラハの社員は自由だが、身勝手ではない

メンバーをチームにアサインする

新人「あ、福田さーん」

福田「はい〜？」

新人「先日チームリーダーになったのですが、人手が足りていないからメンバーを増やしたいんです。仕事を手伝っていただけないでしょうか？」

福田「アサインミーテイングをしたい、ってことですね。アサインミーティングは基本的に断ることができない行事ですし、大丈夫ですよ！」

新人「あ、断っちゃいけないんでしたっけ」

福田「話を聞いた結果仕事を引き受けないことはOKなんですが、話をそもそも聞かないのはNGですね」

新人「じゃあ遠慮なく！アサインミーティングお願いします！」

福田「はい〜」

新人「かくかくしかじかでこのようなチームの目的がありまして〜」

福田「ふむふむ」

新人「つきましては福田さんに手伝っていただきたいと思った次第です」

福田「そうですね〜。面白そうですしできることなら引き受けたいのですが、今担当している他の仕事の方が会社にとって重要度が高いと僕は感じました。なので残念ながらお受けできそうにありません」

新人「そうですか。残念です」

福田「でも断っておしまいだと、人が足りない、という新人さんにとってのtensionが残ったままですよね。自分の周りにもこのチームが人を募集していることを伝えてみましょうか？良い人が手を上げてくれるかもしれません」

新人「それはものすごく助かります！ありがとうございます」

（後日福田さんの声かけに応じた1人とアサインミーティングを実施した結果、メンバーに加わってくれることになった。こうして新人のtensionは解消された）

まとめ

• チームに誰かを誘う際はアサインミーティングを実施する
• アサインミーティングの結果、仕事を引き受けないことはOK
• アサインミーティング自体を断るのはNG
• 仕事を断った場合はtensionがそのまま残ってしまうため、可能な限りその解消にむけて協力する

チームが生まれないケース

新人「うーん、最近ちょっとプロジェクトの進捗が遅れがちだなあ」

B男「あ、新人さんのプロジェクトAもですか？」

新人「あ、BプロジェクトのB男さん。似た課題を抱えていますね」

B男「弊社はプロジェクトマネジメントに関する知見が不足していますからね。その辺りに専門知識を持った人が横断でプロジェクトマネジメントを担っても良いのではないでしょうか？」

新人「それは確かにいいアイデアですね！すぐ新しいチームを作りましょう！開発チームと同列に位置付けた方が良いだろうから、これはPrAhaのリーダーに相談してきます」

B男「お願いします！」

（数時間後）

PrAhaリーダー「どうもPrAhaリーダーです」

新人「かくかくしかじかでプロジェクトマネジメントチームを作りたいのですがいかがでしょう？」

PrAhaリーダー「なるほど。解決したいtensionは何でしたっけ？」

新人「プロジェクトの進捗が当初予定より遅れがちなことです」

PrAhaリーダー「率直な感想ですが、新しいチームを作らなくても解決できる問題に聞こえますね。開発チームの岸田さんは何て言っていましたか？」

新人「いえ、岸田さんには何も聞いていません。PMチームを作るとしたら開発チームと同じ階層になると考えたので、開発チームの1つ上のチームであるPrAhaリーダーに相談しようと考えました」

PrAhaリーダー「そういうことでしたか。ただ残念ながら私は各チームの細部までは把握していないので、今回の新チーム設立に関しては判断できそうにありませんね」

新人「あれ、そうなんですか！一番上のチームのリーダーって、言ってしまえば社長ですよね。社長ならなんでも判断できると思っていました」

PrAhaリーダー「確かに僕は便宜上この法人の社長ですが、それはあくまで日本で会社として認められるためにやっているだけなんですね。社長であろうと、皆さんと同じルールのもとで動いています。ですから僕も他のチームのリーダー同様、1つ下のチームまでしか影響を及ぼせません。例えば直下の開発チームをなくす、みたいな決断なら下せるのですが、開発チームのさらに1つ下のチームのことまで具体的に決める権利は、僕にもありません」

新人「もしプロジェクトAの開発をこうしたい！と社長が考えて、それに岸田さんがずっと反対していたらどうするんですか？」

PrAhaリーダー「そこまで反対されるということは、岸田さんが持っている大切な情報を僕が持っていないことを示唆しています。ですから僕は岸田さんと話し合い、お互いの情報と見解を共有しながらお互いが合意できる結論を出すのがベストですね」

新人「話が全然まとまらなかったらどうするんですか？」

PrAhaリーダー「最終手段としては、開発チームのリーダーを他の人に譲ってもらうことになるでしょうね。リーダーの任命権は1つ上のチームのリーダーにありますから」

新人「なるほど、プラクラシーにおいては全員がルールの上に平等に存在していて特別扱いされる人はいないということですね」

PrAhaリーダー「そうなりますね」

新人「ありがとうございます。おっと、話が脱線してしまった。何の話をしてましたっけ」

PrAhaリーダー「PMチームを新しく作りたいけれど僕では判断できないという話でしたね」

新人「あ、そうだった。困ったな、どうしよう？」

PrAhaリーダー「今回のチーム追加が誰に影響を与えそうか僕から提案しましょうか。今までプロジェクトマネジメントは各開発チームが担当していましたから、開発チームリーダーの岸田さんは会話に参加した方が良いでしょうね。クライアントに対する説明責任を持っている営業チームも影響を受けると思います。オンボーディングチームも影響を受けそうです。思い当たるのはこれぐらいかな」

新人「そしたら、ひとまず全社のSlackで今回の新チームについて意見を募って、今教えていただいた関係者を集めて協議してから、また相談しますね」

PrAhaリーダー「はい、お願いします！」

（数日後）

新人「B男さん、お疲れ様です」

B男「お疲れ様です！Slackみましたよ、結構いろんな意見が集まっていましたね」

新人「諸々の意見と協議した結果、今回は新しいチームを作らないことになりました。残念です」

B男「そんなに落ち込まないでください！確かに当初の提案は新しいチームを作ることでしたが、より良い解決策に落ち着いたのであれば、それはそれで良いのではないでしょうか？」

新人「そうか、目的はtensionを解消することで、新しいチームを作ることではないですもんね」

B男「そうですそうです。常に「これは何のtensionを解決しようとしているのか」と考え続けるのがプラクラシーのコツだと以前僕も教わりました」

新人「なるほどな〜。僕も明日からそれを意識してみます！」

まとめ

• チームリーダーの任命権は、1つ上のチームのリーダーが持っている
• tensionを常に意識する。新しいチームを作ることがtensionを解決するための最適解とは限らない
• 新しいチームを作るときは、誰が影響を受けるのか検討しなければいけない
• 社長だからと言って特別扱いされることはなく、他のチームリーダーと同じ役割や権利を持ち、プラクラシーのルールに則って動く