kintoneなどのソフトウエアを提供して急成長しているサイボウズ。社員が働きやすい環境を整備していることでも注目されています。同社では頻繁に勉強会や読書会が開催され、業務に生かしているそうです。今回は、読書会をプロダクト開発チームの組織変革に生かした事例について、同社開発本部シニアスクラムマスターの天野祐介さんに聞きました。
大事なのは最終学歴ではなく最新学習歴
私は2009年にプログラマーとしてサイボウズに入社しました。以後、エンジニアとして主力商品であるkintoneの開発を担当。2015年に開発本部のチームリーダーとなったのを機に、チームビルディングやシステムのコンセプトづくりに注力するようになりました。
現在は仙台に住んでおり、サイボウズには週3日勤務し、残りの2日間はフリーランスとして、社内外のチームづくりをサポートしたり、アジャイル開発に関する「スクラムフェス仙台」といったイベントを開催したりしています。
サイボウズでは、会社から「こういうスキルを身に付けなさい」と指示されることはありません。なぜなら、「主体的に学ばなければ身に付かない」と考えられているからです。ただ、社長の青野慶久が「大事なのは最終学歴ではなく、最新学習歴」と言っているように、学びやリスキリングのための制度が充実しています。
例えば、「Myキャリ」という制度では、社員が「できること」「やりたいこと」を全社に公開し、社員と部署のニーズをマッチングしています。また、「育自分休暇制度」では、退職しても最長6年間は復帰が可能で、転職や留学などにチャレンジできます。他にも、私が活用している「複業許可」や、「大人の体験入部」という他部署の業務を体験できる制度もあり、スキルアップや異動希望の検討に生かすことができます。
社員同士で学ぶ機会も多く、「週に1回、〇〇について学ぼう」といった読書会や勉強会が自発的に立ち上がることも珍しくありません。私も過去に、『ファシリテーター完全教本 最強のプロが教える理論・技術・実践のすべて』（日本経済新聞出版）『ハーバードで学ぶ「デキるチーム」5つの条件 チームリーダーの「常識」』（生産性出版）『プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける』（オライリー・ジャパン）といった本を題材にして、読書会を開いたことがあります。
優れたソフトにも「技術的負債」が発生
私は新卒時からエンジニアとしてシステム開発に携わってきましたが、仕事を進めるなかで、「もっとプロセスからムダを省けるのでは」「もっとユーザーに届ける価値を最速化・最大化できるのでは」といった思いがありました。そのため、「アジャイル」という手法を学びました。
アジャイルは、もともと「素早い」「機敏」という意味。システムやソフトウエアを従来よりも小さな単位で作って素早く世に出し、フィードバックと修正を何度も繰り返すことで完成形に近づけていく開発手法です。
現在、私はアジャイルを指導する「アジャイルコーチ」として活動しています。また、サイボウズで初の「スクラムマスター」でもあります。アジャイルが価値観だとすると、スクラムは「役割」「作成物」「会議体」を定めたフレームワーク。分かりやすく言うと、アジャイルという考え方の中に、スクラムというフレームワークがあるということになります。
私がアジャイルを学び始めたもう1つの理由に、「技術的負債」の問題があります。どんなに優れたシステムやソフトウエアでも、長く提供し続けていると設計の複雑化が進んで不具合が起きやすくなり、それを改善するのにかなりの時間とコストがかかってしまいます。
サイボウズもそうしたリスクと戦っているのですが、kintoneを今後5倍、10倍と成長させるためのシステム開発を進める際に、全体の設計を固めてから順番に開発していく従来のウォーターフォール型では厳しい。
システムのアーキテクチャー（構造）も我々の働き方も変えていかなくてはならない、という問題意識があり、私が開発本部のチームリーダーになったときに、アジャイル型のスクラムを取り入れることにしました。つまり、大きな一枚岩で動いていたのを、小さな自律分散型のチームが複数で動く働き方に変えようということです。
スクラムの導入から数年たち、もっとkintoneの成長を加速させたいと思っていたとき、 『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』 （マシュー・スケルトン、マニュエル・パイス著／原田騎郎、永瀬美穂、吉羽龍太郎訳／日本能率協会マネジメントセンター）という本に出合いました。本書の翻訳者3人はアジャイルコーチとして活躍していて、今までも何冊も翻訳されているのですが、「今回の本は特に面白そうだな」と思って注目していました。
本書では、「組織がシステム開発を行う際、その組織のコミュニケーション構造と同じ構造の設計を行ってしまう」という「コンウェイの法則」を取り上げ、システム開発において組織づくりがいかに重要かを説いています。また、「まずチーム構造と組織構造を変化させて、望ましいアーキテクチャーを実現する」という「逆コンウェイ戦略」を実現するための方法も解説しており、実践的かつ納得感が得られる内容となっています。
読書会を組織変革に生かす
私は、本書を2021年12月の発売直後に読み、今の働き方を変える必要がある現場の開発チームにとっても、組織を俯瞰（ふかん）しなければならないマネジャー層にも役立つと思いました。そこで2022年1月に各階層の社員に「読書会をしませんか」と声をかけ、原則として週1回のオンライン読書会を10回ほど、3〜4カ月ほどかけて行いました。最終的に参加したのは4〜5グループ、1つのチームは5〜20人ほどでしたので、総勢50人ほどが参加したことになります。
読書会では事前に「今回は第1章を読みましょう」と決めておき、Miroというオンラインツールのホワイトボードを使って進行しました。Miroではオンライン上で付箋が使えるので、まずはそこに全員が読んだ感想と議論したいトピックを書き込みます。そして、1人に2票を与え、議論したいトピックに投票。投票数の多かったトピックを優先してディスカッションしたり、トピックごとにブレークアウトルームに分かれて少人数で議論したりと、ここでも「自律」「少数」を意識しました。
今回、開発チームでは、「大きなチームを分割するとしたら、どの辺りが境界になるのか」「実際に分割したら、今まで当番で対応していたタスクはどうするのか」といった実践的な問題が多く取り上げられました。実務についてストレートに話し合うことができ、大きな収穫がありました。
本の内容を理解するだけであれば、それほど時間はかかりません。しかし、せっかく人が集まるので、黙々と読書をして終わりではなく、やはり「本から学んだことをどう生かすか」「自分たちはどう変わるのか」というアウトプットが重要です。
今回は、本を題材として全員が「サイボウズの組織変革」という課題に対して議論し、共通認識を持つことができたと思います。本の内容を、私たちの組織変革に直接つなげることができ、大変有意義でした。
読書会の後、実際に開発本部では、「チーム分割Try」という、総勢100人ほどのプロダクト開発組織から10数人程度のチームを小さく切り出すプロジェクトが始まりました。今は、2つめ以降のチームをどのように切り出すかを議論しているところです。
今後、ますます少人数のチームで自律的に動ける組織づくりが進んでいくと手応えを感じています。
取材・文／三浦香代子