クラウドシフトが組織を変え、エンジニアに選択肢と自由な働き方をもたらした｜サイボウズ開発本部長佐藤氏｜TECH TEAM BUILDERS #12

1997年に愛媛県松山市で創業したサイボウズ。グループウェアの「サイボウズ Office（中小企業向け）」や「Garoon（大企業・中堅企業向け）」、国内のみならず、海外でも多くの利用者を獲得している業務アプリ構築クラウド「kintone」などの製品を開発・販売しています。

いまでこそSaaSビジネスの代表的事業者として名高いサイボウズですが、「クラウド前夜」の一時期、業績的に厳しい時期を経験しました。サイボウズは直面した課題をどのように乗り越え、現在の地位を獲得したのか。当時を知る佐藤鉄平氏に話を聞きました。

▶︎採用担当者なら知っておきたいマーケティング知識を公開中｜資料を無料ダウンロードする

優秀なエンジニアを採用するコツを公開

自社にマッチした優秀なエンジニアにアプローチできていますか？

開発に馴染みのない採用担当者や経営者にとって、エンジニア採用の要件を正しく設定することは容易ではありません。

そこで、優秀なエンジニアを採用するために押さえておきたいポイントを、1つの資料にまとめました。

専門知識を持たない採用担当者の方にも簡単に理解できる内容になっていますので、ぜひご覧ください。

まずは無料ダウンロード

サイボウズ株式会社
執行役員開発本部長
佐藤鉄平氏
東京工業大学大学院社会理工学研究科経営工業専攻修了。2007年、サイボウズにエンジニアとして新卒入社。Garoon、kintoneの開発チームを経て、2016年7月グローバル開発本部長に就任。2018年からはサイボウズ・ラボ株式会社代表取締役社長を兼任。

Contents

国内外に開発拠点を展開。約250人のエンジニアが在籍
「大航海時代」を経てたどり着いた「クラウド」という「新大陸」
ビジネスモデルの変化が促した、エンジニアの自由な働き方
組織改革を機に採用権限をチームに委譲
＜佐藤氏推奨。シード期、アーリー期の技術責任者にお勧めする情報源＞

国内外に開発拠点を展開。約250人のエンジニアが在籍

——まずは、佐藤さんの現在の立場と職務内容を教えてください。

2016年から、サイボウズ製品の機能開発を行う開発本部の本部長として、主にプロダクトマネジメントとエンジニアの組織マネジメントに携わっています。

——現在、エンジニアは何人いらっしゃいますか？

国内、海外のメンバーを合わせて250名ほどのエンジニアが在籍しています。国内は、東京、大阪、松山にあるメインの開発拠点のほか、福岡や広島のオフィス、また全国各地からフルリモートで開発に参加しているエンジニアも少なくありません。250名は、プロダクト開発にあたる開発本部とインフラを担当する運用本部のエンジニア、中国の上海、ベトナムのホーチミンの開発拠点にいるエンジニアを合わせた数字になります。

——コロナ禍により、この1年でテレワークがごく当たり前になりました。御社はそれ以前からテレワークを導入していたそうですね。

ええ。2010年に試験導入を開始したのですが、本格的に使われるようになったのは、2011年の東日本大震災以降です。事業継続性の観点と個人の働き方を見直した結果、利用者が増えました。開発でのリモート体制が確立されていったのは、大阪に開発拠点を新設した2016年あたりから。当時、東京と大阪のエンジニアが共同で開発するプロジェクトがあって普及に弾みが付いた形です。もはや国内外の各拠点にいるエンジニアが一緒に仕事をする機会は珍しくありませんから、コロナ禍においても開発現場が混乱することはなかったですね。

「大航海時代」を経てたどり着いた「クラウド」という「新大陸」

——エンジニア組織についてはいかがですか？　どのような組織体制下で働かれていらっしゃるのでしょう？

製品開発について申し上げると、kintone、Garoon、サイボウズ Officeなど、各製品の機能開発にあたる「プロダクトチーム」と、彼らを技術的に支援するために組織された特定分野に強いエンジニアからなる「エキスパートチーム」に分かれて開発にあたっています。

——国内外に複数の開発拠点をお持ちで、しかも250名ものエンジニアが在籍する大所帯です。この規模になるまでには紆余曲折があったのでは？

エンジニアの社員数は、創業以来右肩上がりで増えていたのですが、私が入社した2007年の前からしばらくは、既存事業の頭打ち感があり売上や利益率が低迷。当時を知る人は新たな成長の糧を見つけるために試行錯誤する会社の姿を、新大陸を目指して大海原を進む帆船になぞらえ「大航海時代」と呼んでいます。暗中模索の日々でした。

——潮目が変わったのはいつのことですか？

クラウド製品をリリースした2011年ごろからです。kintoneをリリース後、サイボウズ Officeのクラウド版を皮切りに、続々と既存製品のクラウドシフトを進めた結果、クラウドの販売比率が既存のパッケージの売上を遂に逆転しました。それが2017年のことです。これで自分たちの進んできた進路に間違いがないことを確信し、2019年に満を持して組織体制をクラウド開発にフィットした体制にあらためました。

図版出典：「株主会議2021 サイボウズと語る一日」

——具体的にはどのような開発体制に改めたのでしょうか？

以前は、エンジニアやデザイナー、プロダクトマネージャーといった職能ごとの部と、製品ごとのチームが交差するような体制で開発していました。いわゆるマトリクス型の組織です。2019年からはプロダクトや役割に応じたチーム型の組織で活動しています。

＜2018年までの開発組織体制＞

＜2019年から現在までの開発組織体制＞

図版出典：Cybozu Inside Out「組織変更したら部長がいなくなりました」

——なぜチーム主導型組織を選ばれたのですか？

クラウド製品を開発するのに適しているからです。売り切り型のパッケージの場合、大型受注が決まる製品を開発することが、ソフトウェアビジネスの大きな山場になります。そのためエンジニアは、大口顧客の機能要求に応えうるパッケージを開発しようと、決められたプロセス、決められたスケジュール通りに機能の実装しようと最大限の労力を注ぎます。

一方、クラウドはサブスクリプション形式で常時提供されるため「大型受注のために開発を頑張る」といったわかりやすい山場はありません。むしろ「ユーザーに継続的に価値を提供できるか」が重要なので、日々ユーザーの声に耳を傾け、改善すべきポイント、実装すべき機能を見極め、自ら価値あるサービスを開発していく必要があります。チームが一体となって動ける体制が必要だと判断し、チーム主導型の組織を選びました。

——これ以外にチーム主導型組織のメリットはありますか？

品質に関わる部分で申し上げると、パッケージは世に出したあとになって、製品に問題が見つかれば一大事。パッチを当てるにしても、お客様や導入パートナーの手を煩わせてしまうからです。だからこそリリース前に何重ものテストやチェックのために人を割くのですが、それに比べてクラウドは、問題が見つかった当日に修正版を出すことも不可能ではありません。もちろんクラウドだからと言って、品質が低くていいわけではありませんが、リリース後に解決できる選択肢があるとないのとでは大きな違いと言えます。

職能組織もウォーターフォール型の開発手法も、仕様通りのソフトウェアをスケジュール通りにリリースするのに適した仕組みですが、クラウド製品のように変化への受容度、改善のスピードが求められるサービス形態には馴染みません。チーム主導型組織は、アジャイルな開発を容易にするために必要不可欠な選択でした。

ビジネスモデルの変化が促した、エンジニアの自由な働き方

——組織改革を実行されて、エンジニアの働き方にどのような変化が現れましたか？

エンジニア組織が職能や拠点に依存しなくなったことで、大きな変化がありました。どこに住んでいようと、それまで通りチームも担当プロダクトも変わることなく、仕事を続けられるようになったからです。組織図を書き換える前から、リモートワークを前提にこうした働き方ができたのですが、実際は、エリアをまたぐような転居が伴うと、所属が変わることがほとんどでした。2019年の組織改革は、結果としてエンジニアの生活や働き方に、より多くの選択肢を提供したことになると言えます。

——組織が変わり、働き方が変わればエンジニアのみなさんの意識も変わったのではないかと思います。どのような場面で意識の変化を感じますか？

サイボウズには組織変更前から、自分とは異なる役割を担っている人の仕事を最短1日、最長で3カ月間ににわたって経験できる「体験入部」という制度があります。異動を前提としない制度で、この制度を使って得た学びを担当業務に生かすために設けた制度なのですが、チーム主導型の組織に移行してから、この制度の利用が非常に増えました。

エンジニアはエンジニア、プロダクトマネージャーはプロダクトマネージャーの枠のなかで研鑽を重ねればいいという段階から、担当するプロダクトをより良いものにするために、同じプロジェクトで働くメンバー同士、理解を深めようという段階に入ったからではないかと感じています。

——職能や拠点という「縛り」がなくなったことで、エンジニアの思考や行動もクラウドに適した形へと変化していったのですね？

そう思います。自分の仕事と部署やオフィスの所在地を切り離したことで、エンジニアはより自由になりました。部の消滅から3年。同じタイミングで発足したエキスパートチームと、プロダクトチームの連携は非常に活発です。マトリクス型組織を温存したままクラウドビジネスに移行していたら、こうした状況は生まれにくかったでしょうし、クラウドビジネスをここまで成長させることは難しかったかも知れません。

組織改革を機に採用権限をチームに委譲

——採用についてはいかがでしょうか？　組織変更や拡大に伴って求めるエンジニア像に変化はありましたか？

エキスパートチームを設立したことで採用の幅が広がりました。プロダクト開発チームは、ユーザー価値を第一目標とするクロスファンクショナルなチームです。そのため、どうしても特定の技術ドメインに対する深掘りがしにくい特性がありますが、近年求められる技術レベルはさらに高度になっています。

そのギャップを解消すべく、フロントエンド、モバイル、生産性向上などの分野で技術ドメインに特化したエキスパートチームを設立しました。これにより、プロダクト開発チームは困ったときに各分野のエキスパートから支援を受けながら目的を達成することができます。また、エキスパートチームがあることで対外的な認知度も高まり、コミュニティ界隈で名の通ったスペシャリストを採用できるようになったのは大きな変化と言えます。

参考：サイボウズフロントエンドエキスパートチームについて

——プロダクト開発に携わるエンジニアについてはいかがですか？

もともと、プロダクトによって顧客層や用途、技術的課題が異なるので、どう変化したかを端的に説明するのは難しいですね。ただ、それまで職能部門の部長が持っていた権限をチームに委譲したことによって、採用プロセスに大きな変化をもたらしたのは確かです。

かつては部長が差配して決めていた募集要件も、いまはプロジェクトメンバーがエンジニア採用チームと相談しながら決めています。スキル要件だけでなく、「どんな人と働きたいか」「どんな課題を解決してほしいか」など、募集の際に打ち出したいポイントや文言を決めて採用に臨むようになりました。これにより部長クラスにはなかなか把握しきれなかった、チームの実情に即した採用ができるようになったと感じます。

——変化によって新たな課題が浮上していませんか？

そうですね。足もとの採用ニーズと、将来を見据えて採用すべき人材のバランスをいかに取るか、また、開発の傍ら委譲された責務をまっとうするための時間をどうやって捻出するかについては、今後の課題と言えそうです。自由に議論のなかから本当に必要な人材像を導けるような環境を整えるため、私たちマネジメント層やコーチからの継続的なサポートや働きかけが必要だと感じています。

——これまでのお話から、現場からのボトムアップを原動力に組織改革を推進されている印象を受けました。実際はいかがですか？

私自身、一方的なトップダウンを好まないタイプなのもあって、2019年の組織改革も、エンジニア自身が「変えたい」「変えよう」という意識が高まりつつあったからこそ実現できたと思います。幸いなことに、自社で利用しているグループウェア上では、いまも課題意識や改善策についての活発な議論が交わされています。解決すべき課題が可視化されメンバーの意識が高まれば、また新たな改革に臨むことになるでしょう。

マネージャーに求められるのは、常に状況を冷静に見守り、機が熟したらすぐに実行に移すこと。組織づくりにしても、採用にしてもおそらく完成形はありません。行きつ戻りつしながら、その時々でベストな選択をし続けなければならないのだと思います。

——最後に、エンジニア採用に悩みを抱える方にアドバイスがあれば聞かせてください。

私たちも試行錯誤中なのですが、とりわけ高い技術力を持ったエンジニアを集めるのであれば、魅力ある課題を提示することは必要だと思います。たとえば昨年、当社のエンジニアが、Kubernetesを活用した大規模分散システム基盤のノウハウを「KubeCon + CloudNativeCon Europe 2020」で発表しました。こうした取り組みを行うのは、世界のみなさんにサイボウズのインフラの先進性を知っていただくためなのはもちろん、技術志向のエンジニアにとって魅力ある課題、課題に打ち込める環境があることを示すためにほかなりません。

力のあるエンジニアはどこも引く手あまたです。自分の大切な時間を割くに値する課題だと思えなければ、仮に好待遇で迎えたとしてもすぐに辞めてしまいます。登壇やテックブログ、面談などでも、技術的チャレンジが必要な取り組み、社会課題の解決につながる課題を提示するのは非常に重要です。どこまで相手の立場に立った提案ができるかが、採用のポイントになると思います。