サイボウズにおいてプロダクト開発を担当する開発本部では、2016年頃からスクラムを開発現場に導入してきました。チームにスクラムマスターがいない状況も続いていましたが、2022年にはエンジニアやデザイナーなどと同様の「職能」としてスクラムマスターをバックアップする組織改編に踏み切っています。
▶ 組織のチームワークを最大化するためにスクラムマスター職能を作りました - Cybozu Inside Out
これまでもサイボウズの開発本部ではマネージャー職をいったん撤廃するなど、組織のあり方に野心的な取り組みをしてきました。そういった組織改編の狙いや、スクラムマスター職能化から約1年でどのような効果があったのかを、開発本部副本部長の岡田勇樹さんと、シニアスクラムマスターの天野祐介さん、スクラムマスター職能化にともなって専任となったToshinariさんの3人に伺いました。
- スクラムマスターがチームにコミットできる組織改編
- 自然発生的だったスクラムマスターを明示的に置くように
- チームの健全性で生産性が違ってくることを肌で感じた
- 職能とチームとのバランスが取れた組織体制を目指す
スクラムマスターがチームにコミットできる組織改編
先に、2019年に始まるサイボウズでの組織改編についてまとめておきましょう。もともとオンプレミスのパッケージソフトを開発していた経緯から、メンバーは職能や地域ごとの部署に所属し、プロダクトごとの開発チームに配置されるマトリクス組織で10年来運営されていました。これをチーム主体の組織に改編したのが2019年1月で、この際にマネージャー職を廃しています。
▶ 組織変更したら部長がいなくなりました - Cybozu Inside Out
そして3年後の2022年5月に、あらためて職能ごとの部署を導入して開発チームとのマトリクス組織に改変し、新たに「人材マネージャー」や「スクラムマスター」が職能として導入されました。
▶ マネージャー、いないと無理だったので、またつくりました - Cybozu Inside Out
開発ブログではマネージャーを廃止して復活したことにフォーカスされていますが、旧来型の部署によるマトリクスを廃して、見直した職能による新たなマトリクスに組織し直したともいえます。こういった背景をもとに以下のインタビューをお読みください。
── サイボウズの開発本部では先の組織改編による弊害を是正するため、2022年にマネージャーやスクラムマスターを職能化しています。この一連の取り組みはどのような意図で行われたものですか。
岡田 私は2014年くらいからエンジニアリング組織のマネージャーをしていて、2019年と2022年の組織改編をともに主導しました。
もともとサイボウズはオンプレミスのパッケージソフトを開発していたので、開発体制もウォーターフォール型で、半年や1年に1回にリリースするといったプロセスでした。その頃の組織は、人材マネジメントのしやすさから職能と地域による部署に分かれていて、プロダクト開発にあたって各部署からプロジェクトに人が配置される体制でした。
しかし、ビジネスがパッケージからクラウドにシフトしていく中で、開発の進め方もどんどんアジャイルに、開発チームもクロスファンクショナルで自律的に動くことが求められるようになってきました。それなのに当時のマトリクス組織では、何か課題を検討するとなってもそれぞれの部署に持ち帰っていて、どうしてもチームの意思決定が遅くなりがちという問題がありました。
それで2019年にはチームを軸とする組織に改編することで、それぞれの職能メンバーがチームに必要なことをチームの中で意志決定できるようにし、開発のスピードアップとアジャイルへのシフトを図りました。そのとき同時にマネージャー職もなくなりました。
それから3年が経過し、開発チームが自律的に動く狙いはうまくいったのですが、一方で人材マネジメントの機能が弱くなってしまいました。そこでチームを軸として良くなった部分は保ちつつ、弱くなった部分を整備するために職能ラインを新しく作り直しました。そのひとつに「スクラムマスター」職能もあるという形です。
── 一般的な職能（エンジニア、QAエンジニア、デザイナー、プロダクトマネージャー、テクニカルライターなど）や人材マネージャーはともかく、スクラムマスターまで職能化したのはなぜでしょう。
岡田 2018年以前の組織では、職能の切り方がアバウトだったんです。デザイナーとプロダクトマネージャーが同じ部署になっていたり。
新たな職能ラインを作るにあたり、できるだけ一般的なジョブタイトルを職能にしようということで、開発チームにおけるメンバーの役割をもとにソフトウェアエンジニア、QAエンジニア、デザイナー、プロダクトマネージャーと名前を振っていった。そうするとスクラムマスターの役割を果たしているメンバーもいたので、その職能も作ることにしました。
もちろん職能化するということは単なる肩書ではなく、開発組織にとってその職能の必要性が高いからマネジメントラインをちゃんと設けて、組織的に強化していこうという意図があったわけです。
天野 職能化する以前には、エンジニアなど本来の仕事があるかたわらでスクラムマスターに取り組んでいたため、どうしても仕事として評価されにくい部分がありました。チームを良くする方法を考えているとエンジニアとしては手が止まってしまい、周りからは「なんか難しい顔してる人」に見えてしまうこともあります。
その環境で真面目にスクラムマスターに取り組むのは大変です。周囲からのサポートや理解が得られないと苦しいですし、本来のエンジニアリングやQAやデザインの仕事だけしていた方が分かりやすい、ということになり、スクラムマスターを続けることが難しくなってしまう。
それを職能とすれば、スクラムマスターを主務として専念し続けることができる。組織的なサポートもあるし、教育機会も得られる。周りも「スクラムマスターとしての責任を果たそうとしている」と正しく認識できる。そういう環境整備ができたと思っています。
自然発生的だったスクラムマスターを明示的に置くように
── 現在のサイボウズで、スクラムの導入状況はどうなっているのでしょうか。導入しているチームの比率などが分かれば教えてください。
岡田 明確に何割という数字を出すのは難しいですね。チームによってメンバーも100人から5人までさまざまですし、100人のチームはさらに4つのサブチームに分かれていて、開発以外のことをやっているチームも含まれていますから。
天野 感覚的には、スタッフの半数以上がスクラムに関わっているように思います。スプリントレビューなどの用語は開発本部なら誰でも通じますし、何らかの形でスクラムイベントを取り入れているチームも多いので。
専門性が高い技術的な問題を扱っていたり、プロダクトに関連しない業務を行っていたりするチームでは、それぞれに合った仕事の進め方をしていますが、開発プロジェクトを新しく立ち上げた場合には誰が参加しても自然とスクラムっぽい現場になるし、スクラムはイベントや決まりごとが多いから止めたいといった意見が出ることもありません。
もともと社長の青野（慶久）が非常にアジャイル的な思想を持っているので、自分が2016年ごろからスクラムを積極的に導入しはじめたときも、特にその価値観や考え方にアレルギーや拒否反応はなかったですね。
── さきほど職能化される前のスクラムマスターは片手間の仕事だったという話がありましたが、そういった課題についてもっと詳しく教えてください。
天野 これまでもスクラムは行ってきましたが、スクラムマスターを置いているチームはほとんどありませんでした。どちらかというと自然発生的にスクラムマスターとして振る舞う人が出てくるくらいで、正直に言うとスクラムマスターがいるのかいないのか、いるとしてどのくらいなのか、私にもまったく把握できていないところがありました。
それでもプロダクトバックログの作成や、スプリントレビュー、スプリントプランニングなどは実施されていて、スクラムが機能している現場には見えましたが、厳密にはスクラムと言えなかったかもしれませんね。スクラムをやってはいるけど、自律的に活動できていないところに課題意識を感じていました。
そのため組織改編後に新しく立ち上げるチームには、明示的にスクラムマスターを置くようにしています。チームの中で意思決定して、仕事のやり方も改善できる、そういう自律的な小さいチームにしていくことを意識しています。
── スクラムマスターの部署には現在、何人が所属してますか。また、どのようにスクラムマスターの仕事をすることになるのでしょう。
天野 およそ15名ほどですが、時期によって多少の増減があります。スクラムマスターを主務にしているものも数名で、ほとんど兼務です。また専任でスクラムマスターを職能としているのは、まだToshinariさんひとりですね。
最近は、新しいチームを作るときに自分が立ち上げに関わっていれば「プロダクトオーナーとスクラムマスターを置きましょう」と提案します。そしてチーム内で「誰かスクラムマスターをやってください」とお願いすると、例えばエンジニアが手を挙げてスクラムマスターを兼務してくれる。
その人の主務はエンジニアですが、兼務でスクラムマスターの職能ラインにも新たに所属するのでスクラムマスターが増えます。チームが解散したり、主務に集中したいので兼務を解除したいと要望されたりすると、スクラムマスターが減ることもあります。
兼務することで仕事が増えたり、エンジニアリングだけに集中できたときより精神的な負担になったりしますが、アジャイルコーチである自分や人材マネージャーがフォローしたり、スクラムマスターとして外部の研修を受ける予算が付いたりといったサポートがあります。
スクラムマスターを兼務するのはあくまで本人の意志なので、やらされていると感じる人はいないんじゃないかと思ってます。
チームの健全性で生産性が違ってくることを肌で感じた
── Toshinariさんは、スクラムマスター職能化に合わせて専任になられたそうですが、新たに制度ができたことがキャリア選択の後押しになったのですか。
Toshinari 実は制度面での関係はあまりなくて、自分のキャリアを描いたときに「こちらに進みたい」と思ったからです。もちろん、制度が整備されたことでうまくフィットできたという面はありますが、それよりも天野さんなどアジャイルコーチの先輩がいて、頼ることができたので不安に感じることはありませんでした。
実際にチームの方向性や提案を自分ひとりで考えていると、このまま進めてよいのかどうか自信がなくなって悩むことがあるんですね。アジャイルコーチの先輩と週次の1on1ミーティングや月次のコーチングの場で相談できることが、自分が間違った方向にチームを進めていないっていう安心感につながっています。
もうひとつ良かった点として、スクラムマスター同士の横のつながりが明確になったことです。今では月に1度、スクラムマスター職能のメンバーが集まってライトニングトーク大会をしたりしています。複数のサブチームがある大規模なチームでは、1週間に1回サブチームのスクラムマスターが集まって課題を相談したりできるようになっています。
── 実際にスクラムマスターになってみて、それまでのイメージと大きなギャップはありましたか。
Toshinari 最初は「スクラムマスターとは何ぞや？」からのスタートだったので、スクラムガイドに書いてある通りにチームをサポートする役割をトップダウンで実施すればいいのかなという感覚でした。しかし実際にチームの中での活動を振り返ると最初のイメージとはまったく違って、大事なのは現場ベースでやっていくことでした。
チームが円滑に動くようにチームを育てることはあくまで第1段階に過ぎず、次のレベルでは周囲を巻き込んで開発していくことが必要だし、さらにその先では組織全体を意識しなければいけない。今ではそういったこともイメージできるようになったので、スクラムマスターになる前とのギャップはかなり大きいです。
以前はQAエンジニアとして活動していましたが、スクラムマスターがいないチームで振り返りがうまく機能しなかったり、チームの成長に目を向ける人がいなかったりして、同じチームなのにメンバー同士の距離が遠いと感じたことがありました。そうした部分に責任を持ってアプローチする存在がいることで、チーム全体の生産性も違ってくることを肌で感じています。
天野 別のスクラムマスターとコーチングした際に聞いた話ですが、当初はチームの開発量や生産性を高めることを重視していて、彼はスクラムマスターとしてそこを高めようと考えていたそうです。
ですが、実際にスクラムマスターとして活動を続けているうちに見方が変わってきて、最近では「いかにたくさん作るか」よりも「顧客が欲しいものを、素早く届けて、そこからフィードバックをもらい、きちんと価値が提供できているか」ということを重視するようになったそうです。
とても良い気づきだと思いましたし、彼も職能化でスクラムマスターを選択していたので、成長を実感してとてもうれしくなりました。アジャイルは日々の営みの中で試行錯誤しながら実践し、また学習することを繰り返しながら腹落ちし、自分事化して実感しながら、思想的な理解が深まって行くものです。そのステップを順調に進んでいますね。
── 天野さんが開発者ブログに書かれた記事（本記事冒頭に掲載したもの）を読むと、スクラムマスターは「チームを健全に保つことに責任を持つ」と定義されていて、「スクラムを確⽴させることの結果に責任を持つ」と書かれたスクラムガイド（2020年版）よりかなり大きな役割が期待されていると感じました。
天野 私は、一般的なスクラムマスターのイメージが狭すぎると認識しているんです。単に、アジャイル開発のチームに参加してスクラムを回すだけ、だと思われている。
抽象的な言い方かもしれませんが、組織にスクラムを導入する「Do Agile」の段階は、マインドに変化がない状態でアジャイル開発をやるといった世界観になるでしょう。その先に、よりアジャイルな価値観へと変化していく「Be Agile」があります。
むしろスクラムマスターの役割をスクラムの実践に限定しない方が、本来の仕事に集中してもらいやすくなると思っているんです。私のイメージするスクラムマスターはチームを健全にすることが大事な仕事であり、さらにチームの外側に働き掛けたり、組織全体に対してアジャイルなマインドや方法を浸透させるよう支援することが大切だと思っています。
スクラムマスターとして成長する上で、一般的なスクラムマスターについて学習することは大事なステップですが、活動をそこから先に広げてほしい。そのためにも、職能化によってそれができるようなキャリア設計になっていないといけないと思っています。
職能とチームとのバランスが取れた組織体制を目指す
── 今回のスクラムマスターの職能化について、現時点ではどのくらいうまくいったと認識していますか。
岡田 どんどん良くなっている実感はあります。アジャイルコーチと数名のスクラムマスター兼務がいるところからスタートして、この1年間で専任のスクラムマスターも誕生し、職能ラインとしても着実に成長して、開発チームにもしっかり価値を提供できています。
このままスクラムマスターをやりたいという人間が増えて、スキルの高いスクラムマスターに成長してもらえればと考えています。
天野 細かな施策レベルでは、任意でやっていたコーチングセッションに人がなかなか集まらず苦労したこともありましたが、職能化全体としてはうまくいっていると思います。私自身も、組織の中でスクラムマスターとして活動しやすくなった感覚があります。
── 先ほど青野社長がアジャイル的な考えを持っているという話もありましたが、サイボウズという会社自体にもアジャイルな取り組みに積極的なところがあるのでしょうか。
天野 開発スタイルとして認識されているかはさておき、アジャイル的な変化に適応するとか、より良くしていくという考え方に共感してくれる社員も多く、マインド的にはすごく浸透してると思います。総務や営業のメンバーから「開発でやってるスクラムについて教えて」と聞かれることもありますし、一緒に業務改善をしたこともあります。
例えば、弊社のブログ「サイボウズ式」編集部のリーダーから相談を受けて、一緒に問題点を相談する会を開いたり週次で振り返りをしたり、1年ほど運営の手伝いをしていました。
── 外部から見ると、スクラムマスターの職能化も含めて、今回の組織改編はかなりドラスティックに見えますが、組織改編にあたってサイボウズにとって理想像があるのでしょうか。
岡田 まだ理想が見えているというほどではないです。基本的に組織のあり方は職能によるか、事業やプロジェクトによるかのどちらかです。その間のどこに点を打てばバランスが取れるかは時々の状況によって変わりますから、どこがいいのか柔軟に探っていきたいと考えています。
今回の職能ラインで人材マネジメントはワークしていますが、まだ課題として「チームの意志決定」が残っています。今はまだ決められるチームもあれば決められないチームもある。エンジニアリングやデザインなどの役割に応じた意志決定のプロセスを整備し、チームがより効率的・効果的に動ける枠組み作りを組織的なアプローチで解決したいですね。
── さらに組織がよくなることを期待しています。ありがとうございました。
取材・構成：青山 祐輔（@buru）
編集：はてな編集部
- 岡田 勇樹（おかだ・ゆうき） @y_okady
- サイボウズ株式会社 開発本部副本部長 兼 New Business Division 副本部長
2007年新卒入社後、エンジニアとして「サイボウズ Office」や「kintone」の開発に参画。2014年に東京から地元大阪にUターンし、マネージャーとして大阪開発拠点の立ち上げを主導。2018年から開発副本部長として開発組織全体のマネジメントに従事し、現在は外国籍エンジニアの採用や英語でのチーム開発など開発組織のグローバル化にチャレンジしている。
- 天野 祐介（あまの・ゆうすけ） @ama_ch
- サイボウズ株式会社 開発本部 部長 シニアスクラムマスター
2009年新卒入社後、エンジニアとしてkintoneの開発に参加。チームリーダー経験を経て、2016年にはスクラムマスターとしてサイボウズにスクラムを持ち込み、定着させる。現在は週3日勤務でスクラムマスターのマネージャーとして活動しながら、個人事業主のアジャイルコーチとしてコミュニティ活動にも注力。
ブログ：天野 祐介 (ama_ch)｜note
- Toshinari（としなり） @10shinari
- サイボウズ株式会社 開発本部 スクラムマスター
2016年新卒入社後、kintoneのQAエンジニア等を経験し、2022年よりスクラムマスターとして注力する。小さなチームのスクラムマスターを経験した後、現在は複数のチームからなる開発チームでチーム横断的な調整や障害の解消に取り組んでいる。
