サイボウズ

2019年5月 7日 08:00

これからのマネジャーについて、話そう。

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

サイボウズ副社長兼サイボウズUSA社長として、サンフランシスコで働いている山田理。若手マネジャーに向けた本の制作を進めていると、社内の開発本部から「マネジャー職をなくしました」という連絡が。

開発本部でマネジャーをしてきた岡田勇樹を呼んで、山田が詳しく話を聞いてみると、「承認は決める人が決まっていればいい」「部下の成長責任を、マネジャーが持たなくていい」といった、新しいマネジャー論が出てきました。

※本記事の内容は取材当時のもので、現在の組織体制とは異なります。

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

山田

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

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

岡田

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

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

岡田

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

岡田

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

山田

そうやったね。

岡田

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

岡田

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

山田

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

岡田

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

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

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

山田

ふむふむ。

岡田

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

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

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

山田

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

岡田

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

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

山田

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

岡田

はい。そうですね。

山田

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

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

岡田

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

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

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

山田

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

岡田

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

山田

なるほどね。

岡田

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

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

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

山田

それはどうして？

岡田

壁があったんです。

山田

壁？

岡田

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

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

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

山田

うんうん。

岡田

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

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

山田

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

岡田

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

山田

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

岡田

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

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

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

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

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

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

山田

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

岡田

チームの誰かですね。

山田

あ、誰でもいいんだ。

岡田

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

山田

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

岡田

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

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

山田

うんうん。

岡田

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

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

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

山田

予算はどうしてるの？

岡田

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

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

山田

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

岡田

ははは。はい。

山田

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

岡田

そうですね。

山田

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

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

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

岡田

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