マネージャーを否定しない組織をつくる
RSGT2020が1/8~10に開催された。 昨年は楽しかったの一言に尽きたが、今年はとにかく考えさせられた。
というのも、私にとってここ2~3年のテーマだった、Agile × マネージャーというドンピシャなキーノートがSahotaさんよりあったためだ。
本記事では、このキーノートに焦点をあてる。
マネージャーを否定してはいけない
Sahotaさんのセッションで最も印象に残った言葉が、「組織を変革させるとき、誰も取りこぼしてはいけない」というものだ。
私がBas(LeSSの提唱者)の認定スクラムマスターの研修に参加したとき、どんな役割を今やってますか？と質問された。 私はそのときScrumを推進する人ではあったが、Scrum Masterではなかった。なぜなら、私の行う役割にはエンジニアの評価やエンジニアの採用も入っていたからだ。 そのときはEngineering Managerという肩書きを知らなかったので、とりあえずProject Managerと言った。他の参加者にもXX Managerという役割を持っている人がいた。
そこでBasに言われたのは、「おめでとうございます。Scrumではマネージャーという役割はいないです。だから、あなたの役割は無くなります。」という言葉だった。
この言葉に正直、良い気持ちはしなかった。 なぜなら、自分のやっている役割は必要性があってやっているものであり、自分の役割が変わったところで、その仕事は無くならないと思ったからだ。*1
このときから、私のAgileな組織におけるマネージャーとは何かを考える旅が始まった。
開発メンバー vs マネージャーという対立構造は悲劇しか生まない
Agile界隈で私の苦手な風潮はマネージャーを否定する言葉だ。
「邪魔してくるマネージャーをチームからブロックしろ」
「マネージャーの役割はチーム開発では不要だ(だって、Scrumはそれで成り立つでしょ)」
確かにそれはチームという目線から述べたら正しいのかもしれない。 多分、私もチーム開発だけを見ている立場のときにそういう発言をしていたと思う。 でも、その言動は組織を運営する立場(=マネージャー)からすると、とても鋭い刃だった。
一方で、このマネージャーの否定発言こそが悲劇を生み出しているのではないか。 現マネージャーはもちろんだが、特に、Agile開発をしていたメンバーがマネージャーの立場になった途端、その矛先は急に自分に向く。 自分のやっていることは悪なのではないか、自分はチームを邪魔する人間になっているのではないか、などと言った自己を否定する言葉を使いながら。
実際、自分もこのように感じてしまい、Agileの理想から外れている自分と、その一方でAgileを否定したくない自分で葛藤した。 結果として、Agileコミュニティからも少し身を引いた場面がある。 組織運営をしているマネージャーにとって、Agileコミュニティは正直居心地が良くなかった。
一方その頃、Engineering Manager(EM)コミュニティが立ち上がった。 組織運営をする立場の人間が多かったので、その方が居心地が良かったし、何より現実的に今自分が困っている課題を議論できた。 結果として、EMコミュニティの活動が増えていった。
ではまたなぜAgileコミュニティとつながりを持つようになったか。 それは、EM.FMを通してEM像だったり、私の考える組織設計について、 Agileコミュニティにいる方々からとてもポジティブな意見をいただく機会が増えたからだ。
Agileコミュニティの理想ではないマネージャーという存在が、現実的に必要な役割として認識されたのだ。
ヒエラルキーと自己組織化
私の組織ではマネージャー職を設け、一種のヒエラルキーを作っている。 その中でAgile開発をしようとして、Agileの掲げる自己組織化という理想とのギャップに苦しめられていた。
Sahotaさんは、このギャップについて、ティール組織を使って説明していた。 以下は、Sahotaさんの発表内容の一部を切り取って、私の理解しているギャップの根源を述べる。 参考にしたのは、以下の本である。
![[イラスト解説]ティール組織――新しい働き方のスタイル](https://images-fe.ssl-images-amazon.com/images/I/51DS9KN-D7L._SL160_.jpg "[イラスト解説]ティール組織――新しい働き方のスタイル")
- 作者:フレデリック・ラルー
- 出版社/メーカー: 技術評論社
- 発売日: 2018/11/27
- メディア: 単行本（ソフトカバー）
多くの会社はヒエラルキーから成る"オレンジ"(あるいは"アンバー"*2 )組織である。 一方、Agileの理想とするのは、自己組織化された"ティール"組織である。
理解しなければらないのは、オレンジ組織がいきなりティールを目指そうとすると問題が起きる、ということである。 本当はそれらの間にあるグリーンを作り上げ、そこからティールを目指すのが本筋である。*3
では、グリーンとオレンジの違いは何か。肝となるのは権限委譲である。 マネージャーの役割を認めながら、権限・責任をメンバーに委譲していくということだ。
グリーン組織の重要な観点として、権限委譲された組織を目指すということは、ヒエラルキーを維持しているということだ。 これは一見矛盾しているように思えるが、一つ一つ丁寧に権限委譲していくプロセスが自己組織化された状態にするために大事なことだ。
Agile開発の文脈では、この権限委譲のプロセスが定義されていない*4ため、 どうしても開発メンバー vs マネージャーという対立構造を生んでしまわざるを得なかったのではないかと思う。
権限委譲を促進させるためのコツ
では、権限委譲をどうやったら促進させることが出来るのだろうか。 権限委譲には私の経験上、スキルの壁・信頼の壁・勇気の壁の3つの壁がある。
1. スキルの壁
メンバー側に権限・責任をもらうだけのスキルが無いと、そもそも委譲されることは難しい。 マネージャーと良く話し合い、どんなスキルが足りていないかを良く話し合おう。
2. 信頼の壁
スキルがどんなにあっていても、メンバーが信頼されていないと委譲は進まない。 信頼を貯める行動を取り、メンバーに任しても大丈夫だと信頼されるようになろう。 そして、マネージャーはXY理論のX理論(人間は本来なまけたがる生き物で、責任をとりたがらず、放っておくと仕事をしなくなる)ではなく、Y理論(人間は本来進んで働きたがる生き物で、自己実現のために自ら行動し、進んで問題解決をする)に立つということも重要である。
3. 勇気の壁
全て委譲出来るかどうかはマネージャーの勇気にかかっている。 マネージャーの恐れをメンバーに伝え、メンバーを信頼しよう。
マネージャーがいない組織を実現できるのか
この問いについて、私はまだ解を持っていない。 ティール組織をまだ理解しきれていないし、どのような実装が自分の組織にうまく適合するのかシミュレート出来ていない。
サイボウズ社の水戸さんの発表は、マトリクス型組織だったところからマネージャー職を廃止したということで、自分の組織と似たようなところもあり、とても参考になりそうだ。
私はAgileの考えに強く共感しているし、コミュニティにもかなり助けてもらった。 だからこそ、マネージャー否定の連鎖を止めたい。
Sahotaさんのセッションは、正にそれそのものだった。 私はSahotaさんからこれまでやってきたことに対して、勇気をもらった気がした。
RSGTのチケットが瞬殺され、プロポーザル採択の倍率が3倍から5.5倍になり、世の中にAgileの考えが広まっていく流れが見えた。 そして、Agileが広まれば広まるほど、私のようにマネージャーが苦しむのは今後間違い無い。
私のやることは、マネージャーを否定しない組織をつくり、そしてその実装例を広めていくことなんだろう。
(追記) @ikuodanakaさんが、この記事では伝えきれていなかった、マネージャーって何をする人なのか、どうなっていく存在なのかを書いてくださった。 note.com
