これは何

プラハ独自のホラクラシー「プラクラシー(PrAcracy)」のルールを明記したドキュメントです

なぜ必要なのか

プラハは2021年頃にホラクラシー (opens in a new tab)を採用したものの、以下の2点の理由から毎日そこまで深く意識する機会がありませんでした

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

最近はアガルートの自社サービス開発が始まったり、採用活動も活発化し、相互作用する仕事が増えてきました。そのためホラクラシーのルールをプラハに適した形にアレンジした「プラクラシー」を運用することになりました

プラクラシーの目的

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

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

「自分がやりたいこと」「自分が出来ること」「周りに役立つこと」の3つが重なった仕事を任されたとき、人の力は最大化されると考えています。全社員がそんな仕事を持てるようにすることがプラクラシーの目的です

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

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

なろう系っぽくプラクラシーのルールを理解する

ルールを列挙しても覚えづらいと思うので、流行りのなろう系小説っぽく社内のルールを解説してみます。茶番が見るに堪えないと感じたら 「まとめ」と書いてある部分だけ読んでいただいて大丈夫です

プラハの勤務初日

新人 😊「転生したらプラハに入社していた！今日から頑張ろう」

プラヲ 🕶️「君が新人くんだね。僕は新入社員のフォローチームのリーダーをしているプラヲです。今日が入社予定日と聞いて、楽しみにしていたよ」

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

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

新人 😊「わかりました！」

まとめ

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

チームとは

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

インザーギ ✊ 「どうも、Aプロジェクトのリーダー、インザーギです！」

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

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

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

インザーギ ✊「プラハにはチームしか存在しないよ。チームの上に別のチームがあったり、チームの中に他のチームが含まれていたり、階層構造になることはあるけど、名前は全部一貫してチームだよ」

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

インザーギ ✊「それを説明するには、チームの目的から話さないといけないね。チームには全て目的があり、その目的は背景とObjectiveと責務と権限とKey Resultsによって定義されているんだ」

新人 😊「Objective？責務？よくわからないので日本語でお願いします」

インザーギ ✊「(責務は日本語だけど...)まずはこのチームを例に見てみようか。全部書き出すと大変だから一部抜粋して紹介するよ」

チーム名：Aプロジェクトの開発

背景

• 昨年の売上は過去5年で最も伸び幅が少なかった。市場を取り尽くしてしまったことが要因として考えられるため、新たな市場にサービスを提供する必要がある

Objective

• 関係者と合意した期日までにAサービスの全機能をリリースし、全社売上の5割を超える事業を作ること

責務

• リリース日を変更する必要が生じたら関係者と合意形成すること
• 合意したSLAをリリース後も満たせるよう運用すること

権限

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

Key Results

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

目を通しておくべき情報

• (何らかのURLへのリンク)

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

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

まとめ

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

暗黙の期待を作らない

新人 😊「暗黙の期待？」

インザーギ ✊「例えば上司に仕事を頼まれて、実際やってみたら「全然違う！」って突き返されたことはない？」

新人 😊「前世でそんなこともあった気がします」

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

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

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

新人 😊「え、そんなことまでインザーギさんが決めていいんですか？」

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

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

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

まとめ

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

責務とは

新人 😊「目的を達成する方法はチームが自由に考えてよし、と...あれ、でも責務は結構具体的にやるべきことを指示していませんか？」

インザーギ ✊「鋭いね」

新人 😊「僕でなきゃ見逃しちゃうね」

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

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

インザーギ ✊「そんなイメージだね！」

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

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

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

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

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

新人 😊「はーい」

まとめ

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

権限

（数日後）

スコスコスコスコ...スコーンッ!!

インザーギ ✊「新人君おはよう。普段は尊師スタイルなんだね」

新人 😊「スコ」

インザーギ ✊「最近仕事で困っていることはない？」

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

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

新人 😊「それ気になってました」

インザーギ ✊「改めてこのチームの権限を振り返ってみようか」

権限

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

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

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

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

基盤開発チームの権限

• 基盤サービスに向けられたPRのレビュー及び取捨選択

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

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

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

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

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

まとめ

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

Key Results

（数日後）

新人 😊「EmacsではなくVimを使いましょう...っと。ツイート完了」

インザーギ ✊「業務中に宗教論争を加熱させるのはやめようか」

新人 😊「あっすみません」

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

新人 😊「Key Results？」

インザーギ ✊「あれ、まだ説明してなかったか。じゃあこのチームに与えられたKey Resultsを振り返りながら説明しよう」

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

tension

(数日後)

新人 😊「うーん...」

インザーギ ✊「何かお悩みの様子だね」

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

インザーギ ✊「なるほど、それはtensionだね」

新人 😊「いえ、僕のテンションはむしろ下がってます」

インザーギ ✊「あ、ごめん。そっちのテンションじゃなくて、プラクラシー用語としてのtensionの方を指していたんだ」

新人 😊「プラクラシーだとtensionってどういう意味なんですか？」

インザーギ ✊「プラクラシーにおけるtensionは、あるべき姿と現状が乖離していて、それにより不都合が生じている状態、という定義で考えてもらって構わないよ」

新人 😊「ほう...」

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

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

インザーギ ✊「え？どうして？」

新人 😊「え？えーと...インザーギさんは僕の上司だから？」

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

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

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

新人 😊「え、今からですか？」

インザーギ ✊「いつやるの？」

新人 😊「今でしょ！」

まとめ

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

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

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

インザーギ ✊「バロテッリ先輩、お疲れ様です」

バロテッリ ⚽「お疲れ！」

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

バロテッリ ⚽「いや、俺は先週リーダーを他の人に頼んだよ。最近ちょっと役割が多すぎてwhy always me?って感じだったから、もう少しコードを書く方に集中したくてさ」

インザーギ ✊「あ、そうだったんですね。誰が今リーダーやってるんですか？」

バロテッリ ⚽「組織図に反映しておいたから、そこを見ればわかるよ」

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

インザーギ ✊「了解です！えーと...イブラさんか。ありがとうございます〜」

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

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

イブラ 💪「いいよー」

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

イブラ 💪「あー、確かにそのtensionは他の社員からも聞いたなぁ。今2つに分かれているチームのリーダーは...プジョルとシャビか」

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

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

新人 😊「やった！」

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

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

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

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

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

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

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

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

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

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

まとめ

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

リーダー交代

（数ヶ月後）

インザーギ ✊「新人くん元気？」

新人 😊「VERY GOOD」

インザーギ ✊「それは何より。ちょっと突然だけどAプロジェクトのリーダーを他の人に任せることになったから、それを共有したくて」

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

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

新人 😊「確かに」

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

新人 😊「そっかー...やっとバイブス通じ合ってきたところだったから残念です。その場合Aプロジェクトのリーダーは不在になるんですか？」

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

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

インザーギ ✊「そうそう」

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

（翌日）

イブラ 💪「えーと、、、いた！新人くん、ちょっとこっち来て」

新人 😊「？」

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

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

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

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

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

まとめ

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

アサインミーティング

イブラ 💪「アサインミーティングは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を生じさせない方法とタイミングを君が考えるんだ」

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

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

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

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

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

イブラ 💪「飲み込みが早いな。他に質問はあるか？」

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

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

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

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

新人 😊「はい！」

まとめ

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

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

（数日後...）

イブラ 💪「調子はどうだリーダー」

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

イブラ 💪「そうか。メンバーを増やせばいいんじゃないか？」

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

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

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

イブラ 💪「そういうことになるな」

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

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

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

イブラ 💪「prahaのリーダーが一人でやることになるだろうな。限界が来たらまた新しいチームを作って、別のリーダーに移譲することになるだろう」

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

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

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

イブラ 💪「兼務も可能だ」

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

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

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

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

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

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

新人 😊「ふむ」

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

新人 😊「えーと、彼はどこにいるかな...」

クルトワ 👨「チキチキチキ....」

新人 😊「あ、青軸の音！クルトワさーん」

クルトワ 👨「はい〜？」

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

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

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

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

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

クルトワ 👨「はい〜」

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

クルトワ 👨「ふむふむ」

新人 😊「つきましてはクルトワさんに手伝っていただきたいと思った次第です」

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

新人 😊「そうですか...残念...」

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

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

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

まとめ

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

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

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

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

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

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

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

Bリーダー 👍「お願いします！」

（数時間後）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（数日後）

新人 😊「Bリーダーさん、お疲れ様です」

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

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

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

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

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

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

まとめ

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