サイボウズの開発本部がマネジャーをなくしてみた「いないと無理なら、またつくればいい」

マネジャーが場所ごとにいる必要はない

山田

ねらったわけじゃないのに、すごくいいタイミングだよね。マネジャーに関する本の出版を進めていたら、「開発本部がマネジャーをなくした」って。

山田 理（やまだ・おさむ）。サイボウズ 取締役副社長兼サイボウズUSA(Kintone Corporation)社長。1992年日本興業銀行入行。2000年にサイボウズへ転職し、責任者として財務、人事および法務部門を担当し、同社の人事制度・教育研修制度の構築を手がける。2014年からグローバルへの事業拡大を企図し、米国現地法人立ち上げのためサンフランシスコに赴任し、現在に至る。

岡田

「マネジャーをなくした」というと、すごいことをした感じがしますが、正確にいえばプログラマーや品質保証、デザイナーなどの職種と拠点で分ける部署を解体したんです。

岡田勇樹（おかだ・ゆうき）サイボウズ 開発本部副本部長。2007年に新卒でサイボウズに入社。エンジニアとして「サイボウズ Office」や「kintone」の開発に携わる。2014年にマネジャーとして大阪開発拠点の立ち上げを主導。

岡田

これがマネジャー、つまり部長職を廃止する前の開発本部の組織図です。

岡田

縦割りで、「西日本開発部」「東京品質保証部」などの各部署から、メンバーを各プロダクトチームにアサインしていました。

山田

そうやったね。

岡田

こちらがマネジャーを廃止したあとの組織図。

岡田

各拠点にひもづいた部署を解体し、チームごとの組織にしました。プロダクトチームから、部長がいなくなっていることがわかると思います。

山田

具体的にはどういうことから変えたの？

岡田

まずは、マネジャーたちがそれぞれどんな業務をしているのかを書き出して、委任できる先を整理していきました。

キャリア採用や承認作業は各チーム、新卒採用や給与評価は組織運営チームへと委任できることがわかりました。

また、1on1などのメンタリングは、各メンバーがどのメンバーとも自由にできる体制をつくることにしました。

山田

ふむふむ。

岡田

あとは特定のプロダクトチームに属さず、すべてのプロダクトチームを支援するチームも用意しているんです。

たとえば、アジャイルコーチチームや生産性向上チーム、フロントエンドチームがそれにあたりますね。

成長の場はつくるけど、責任はとらへん

山田

マネジャーの仕事には、「下の人を育てる」ことがあるけど、人材育成はどうしているの？

岡田

勉強会です。同じ分野に興味がある人同士のコミュニティを用意しています。もちろん、自発的に立ち上がることもあります。

そのなかで、自分で興味があるところに入ってもらって、勝手に自分で学んでもらおうと。

山田

場はつくるけど、「成長の責任はとらへん。スキルを磨きたかったら、そのコミュニティに入っとけ」と。

岡田

はい。そうですね。

山田

裏を返せば、成長したくなければ入らんでもええけど、誰もそれに対しては、責任はとらんと。

今までだったら、マネジャーがメンバーを成長させなきゃダメだし、モチベートする責任をもっていたけど、それがないんだ。

岡田

成長支援のターゲットは「成長したい」と思っている人。

成長したくない人は、そもそもコンセプトから外れるんで、そこに上司が責任を持たなくてもいいなと。

チームを職種ごとに分けていたら「壁」ができていた

山田

そもそも、どうして組織を変えようと思ったの？

岡田

まず前提として、全体的にマネジャーが不足しているという問題があったんです。そこから、マネジャーやメンバーへのヒアリングを進めていったら、いろいろな問題が浮き上がってきて。

山田

なるほどね。

岡田

たとえば場所は違っても取り組むプロダクトや、評価基準は一緒。それなのに、マネジャーは各拠点にいて、拠点によって評価するマネジャーが違う。

なので、最初は地域ごとに分かれる体制をなくして、組織形態を変えようと思っていました。

でも、メンバーにヒアリングをしていくなかで、「同じプロダクトに携わるメンバーの部署が分かれていないほうがいい」と気づいたんです。

山田

それはどうして？

岡田

壁があったんです。

山田

壁？

岡田

各チームのミッションは、突き詰めていくと絶対に対立します。

モノをつくるチームは「早くつくりたい」。デザインチームは「美しくつくりたい」。品質保証チームは「バグが出ないものをつくりたい」。運用チームは「SLO(*1)を達成したい」。

(*1)提供するサービスのレベルや品質に関する目標。Service Level Objectiveの略。

山田

うんうん。

岡田

でも、職種ごとのミッション達成を目指すのではなく、各職種が連携してプロダクトのユーザー価値を最大化するのが本来の目的であるべきだなと。それを実現できる組織体制は何かと考えました。

同じプロダクトチームに所属するプログラミングが得意な人と、デザインが得意な人の所属部署が分かれていない状態にすれば、対立が起こりにくくなるんじゃないかという結論に達したんです。

山田

組織が変わって4か月くらい経ったけど、実際に状況は変わった？

岡田

少しずつですが、「チームのミッションに向かって、何ができるのか」という議論ができ始めています。

山田

いいね。逆に、職種ごとにチームをつくるメリットってないの？

岡田

進め方がウォーターフォール・モデル(*2)だったときは、職種と工程がひもづいていたので、職種ごとに分かれていたほうが、仕事をやりやすかったです。

でも、制作するプロダクトがパッケージからクラウド中心になったことで、開発のやり方もアジャイル、スクラム(*3)に変わりました。

リリース間隔も短くなって、一緒のタイミングでいろんな部署が動くようになったんですよね。だから時代に合わせて組織も変えるべきだなと。

(*2)システムの要件定義から設計、製造、テストまで、各開発フェーズの計画をあらかじめ決め、段階的に進めていく開発モデル。

(*3)設計、テスト、実装を短期間で繰り返しながら開発を進める、アジャイル開発の一種。少人数でチームを組み、短期間のサイクルで開発を進める。

あみだくじで「承認する人」を決めてもいいよね

山田

出張のときの決裁は、誰が決めてるの？

岡田

チームの誰かですね。

山田

あ、誰でもいいんだ。

岡田

たとえば、僕のチームはあみだくじで休暇の承認をする人を決めました。

山田

偉い、偉くないとか、年齢じゃなくて。

岡田

はい。承認する人は誰でも大丈夫だなって。

あとは本を買うときの事前審査。これも誰が決めてもいいなと。

山田

うんうん。

岡田

みんなが読めるグループウェア上に「この本を買いたいです」って書けばいいだけ。

見える化ができているので、変なものを買う人はいないだろうと。

情報をオープンにすれば予算の管理も不要になる？

山田

予算はどうしてるの？

岡田

予算の決定権限は、チームではなく、本部長にあります。

お金の使い方は人によって幅があるので、やり取りをオープンにするだけで、うまくいくのかなと不安で。

山田

オープンにした上で、あやしい使い方を試みるのって、結構大変やし、勇気もいるけどね。

岡田

ははは。はい。

山田

情報をオープンにしたときに、「その本いる？」「その費用いる？」って、チームメンバーからつっこまれているなら、フィードバックはされているわけだよね。

岡田

そうですね。

山田

ほとんどの人は、ちゃんと使いたいし、つっこまれたらイヤだろうし、できるだけみんなに「いいね」って言われながら行動したいじゃない。

みんなにつっこまれても、あやしい使い方をし続ける人がいるなら、対処法を考える必要が出てくると思うけど。

「情報をオープンにしたうえで、チームか個人が判断をすればいい」って考えたら、予算も委任できるんじゃない？

岡田

なるほど。予算もオープンにして、お互いにフィードバックをもらえる仕組みが大事ですね。これから考えていきます。

実際にやってみて無理ならマネジャーを復活させればいい

山田

僕は「マネジャーかくあるべし」っていう理想は持っているんだけど、一方でマネジャーが全部を兼ね備えるのは「無理だ」とも思っていて。

山田

「マネジャーとは」っていう理想はわかったけど、実際に全部を実行できるわけじゃないし。そう思うと、いま開発本部がやっている

「みんなで分担したらいいやん」
「成長って誰も責任とらんでいいやん」
「成長できる場所だけつくればいいやん」

という取り組みには、僕もチャレンジしたいなと思っている。

岡田

「マネジャーが全部兼ね備えるのは無理」っていうのは、社内で何かきっかけがあったんですか？

山田

ええー。だって僕、こんなに一生懸命マネジャー研修とかやってんのに、全然浸透してないんだもん。

岡田

ははは。

山田

「かくあるべし」って理想があっても、自分も含めて、実際にどれだけの人が実行できてるかどうかは疑問だなと。マネジャーっていう肩書で、実際はマネージできてない人が山ほどいるわけじゃない。

山田

組織形態を変えて困ったことはあった？　デメリットとか。

岡田

まだ、4か月しか経っていないので、何をするべきかがチームに浸透していなくて、メンバーが迷っていますね。承認に関しても、「何を承認すればいいのかわからない」という感じで。

山田

役割分担ができていない。

岡田

そうです。これまでマネジャーの業務内容をみんなが知らなかったので「そんなことやってたんだ」と。まだチームで試行錯誤している状態です。

山田

マネジャーを復活させましょう、となることもありえる？

岡田

ははは。はい。そうなるかもしれません。実際にマネジャーなしでやってみて、チームで「無理！」ってなる可能性はあるよねって。そうしたらまた考えます。

山田

そのプロセスはおもしろいね。いったんなくなったけど、必要になってまた生まれるんだ。

岡田

これまでの「職種×地域」の体制は、10年以上続いていました。その延長で続けてきたので、組織を変える思考自体がなかったんです。

今後は、なるべくいろいろなフィードバックを集めて、組織自体を小さいサイクルで改善していきたいですね。

2019年5月14日「管理職って別にいらなくない？」マネジャーを廃止した開発本部に、給与評価や異動の仕組みを聞いた

2019年2月28日マネジメントはいらない、論文数で評価しない──R&Dの理想を追求したサイボウズ・ラボは、こんな組織になった