サイボウズは「SaaSシフト」をどのように成功させたのか：「案件中心」から「顧客中心」へ（3/3 ページ）

[伊藤健吾，ITmedia]

※本記事はアフィリエイトプログラムによる収益を得ています

職能組織制かプロダクトチーム制か、組織変革の心得

及川　開発組織の在り方として、職能組織がいいか、現在のサイボウズさんのような事業主体組織がいいかは状況によって変わってきます。佐藤さんが他社の開発責任者に組織づくりのアドバイスを求められたら、どんな助言をされますか？

佐藤　開発組織の在り方を考えるときの大前提になるのが、全社的な組織文化だと思うんですね。サイボウズの場合、「公明正大」「多様な個性の尊重」「自立と議論」などいくつかの行動指針があって、全員でそれを実践できる土壌があったからこそ、プロダクト開発のあるべき姿をその時々で議論し合って変えていくことができました。

　こういう土壌がない企業でいきなり組織構造を変えても、なかなか機能しないと思います。そこで、まずは目指す方向性が自社の組織文化にとって許容されるものかどうかを考えなければなりません。

　その上で、職能部門制かプロダクトチーム制のどちらがいいかを判断するには、これまでの「文脈」をしっかり見極める必要があると思っています。

及川　文脈とは？

佐藤　今、何ができていて、何ができていないのかを見極めることです。サイボウズの場合、先に職能ありきの組織があって、各組織の努力で職能ごとに求められるスキルやキャリアパスがある程度確立できていました。つまり、ソフトウェア開発の基礎になる部分は一定のレベル以上でき上がっていたわけです。

　ただし、次の時代に向かってクラウドネイティブなやり方でプロダクト開発をしなければならなくなったとき、前述した職能部門制のデメリットをプロダクトチーム制のメリットが上回るようになってきたと判断したので、ガラリと変えました。もし、これをメンバーの職能レベルが低い状態で行っていたなら、プロダクトごとに誰が何をどのレベルでやるべきか、分からない状態で組織運営をすることになっていたかもしれません。

及川　きちんとした職能組織があって、メンバー個々人がスキルを身に付けてきたからこそ、事業主体のチーム編成に変えても機能するということですね？

佐藤　ええ。さらに言うと、この議論は状況によって行ったり来たりするものだと考えているので、将来的には再び組織構造を変えることもあり得ると思っています。皆のスキルアップ曲線が緩くなってしまい、「この領域を深堀りしている人がいなくなってきたんじゃないか」となったら、きっと職能部門制に戻そうという議論が出てくるはずです。

及川　そのときの会社の状況やメンバー個々人のレベルによって、職能制かプロダクトチーム制かを柔軟に変えていくことが大事なのですね。

佐藤　しかも、その判断基準はどちらかをゼロにして、どちらかを10にするという極端な形にはならないと思っています。事実、当社も19年に組織構造を変える前はクロスファンクショナルなマトリックス組織でやっていましたし。また、職能部門制をやめた一方で「フロントエンド」や「モバイル」などいくつかのテーマのエキスパートチームを拡充しました。そうすることで、チーム横断で特定分野の価値向上に貢献できる専門家も育てていこうという考えです。

及川　なるほど。貴重な体験談をお話いただきありがとうございました。