AI活用やDX（デジタル・トランスフォーメーション）、アズ・ア・サービス化によるサブスクリプションモデルの導入など、テクノロジーを駆使した新たなビジネスがさまざまな業界を席巻している。今まで非IT企業だった企業群もソフトウェア開発をコア・コンピタンスにしていく必要に迫られる中、組織全体でITシフトを進めるためのステップを書き記したのが及川卓也氏の著書「ソフトウェア・ファースト」（日経BP）だ。

及川氏は執筆に際して、ソフトウェア・ファーストを実践することで各業界に新風を吹き込んできた日本企業に取材を実施。デジタル変革のあるべき論だけではない、リアルな実情を踏まえたソフトウェア開発力向上のヒントを探った。

今回紹介するのは、サイボウズ開発本部長・佐藤鉄平氏の経験談だ。業務アプリケーションの「パッケージソフト販売」から「クラウドベースのSaaSモデル」への事業転換に成功した同社に、開発体制の変遷を聞いた（聞き手：及川卓也）

SaaSモデルにシフトしたきっかけ
及川 サイボウズさんは業務アプリ構築クラウドの「kintone」（キントーン）をはじめSaaS製品が好調ですが、かつてはパッケージ製品が中心でしたよね？

佐藤 ええ。2011年にcybozu.comとして「kintone」の提供開始と「サイボウズ Office」のクラウド化をするまでは、パッケージソフト販売が中心でした。

今もメール共有ソフトの「Mailwise」（メールワイズ）や大企業向けグループウェアの「Garoon」（ガルーン）など、一部の製品はパッケージソフトとSaaSの両方で提供していますが、11年以降は会社を挙げてクラウド型サービスへの事業転換を進めています。

及川 何がきっかけでSaaSとパッケージソフトの共存モデルにシフトしていったのですか？

佐藤 一番の理由は、パッケージソフトの売上が踊り場を迎えたことです。当社は創業が1997年で、「サイボウズ Office」を出した後10年くらいはユーザー数も売上も右肩上がりで伸びていました。それが2007年ごろになって、ユーザー数はそこそこ伸びているけれど、売上が伸びなくなってきたぞ、と。

それから11年までの約5年間は、次の主力事業を模索すべく、それこそいろんな事業を試しました。社内ではこの時期を「大航海時代」と呼んでいて、他社さんと協業してソフトウェアのセット販売を始めたり、広告ビジネスに手を出してみたり。そこまで芽が出ずに終わってしまった事業もたくさんあった中で、最終的にクラウド型のSaaSビジネスが残ったという形です。

及川 11年ごろは今と違って、クラウドサービス全体への信頼度が低かったですよね。パッケージソフトだけで頑張るという選択肢も捨てがたかったのでは？

佐藤 11年はAWSが東京リージョンを開設した年で、日本はまだクラウドの黎明（れいめい）期でした。おっしゃる通り大企業をはじめ多くの企業は「クラウドはセキュリティ上まだまだ危険なもの」という認識だったと思います。

ただ、アーリーアダプターを中心にクラウドサービスの業務利用が増え始めていたタイミングでもあって、SaaSに舵を切るなら今だろうと。当初、ユーザー数の伸びは緩やかだったものの、17年には全プロダクトの年間売上の中でパッケージソフトとSaaSの比率がだいたい半々になり、18年にはSaaSが65％と逆転するまでになりました。

及川 パッケージソフトの売上も、急激に落ちているわけではないのですね。

佐藤 はい。おおむね横ばいで推移しています。一定以上の規模の情報システム部門があって、社内のITシステムを自分たちで管理・運用できるようなお客さまの中では、個別の事情に対応するパッケージソフトのニーズがまだあるんですね。そこにSaaSという導入・運用が手軽なクラウドサービスを投入したことで、新規のお客さまが増えたという構図です。利用のハードルが下がったという表現が正しいかもしれません。

「案件中心」の開発から脱却
及川 パッケージソフトだけだった時代から、SaaSの提供も行うようになった今、開発で一番変わった点は何でしょうか？

佐藤 中長期視点のプロダクトデザインが求められるようになった点です。

パッケージソフトはライセンスの切り売りモデルなので、社内が一番沸くのは大規模案件の受注が決まったときだったんですね。例えば、ある大企業に「Garoon」の導入が決まったとすると、それだけで一気に数千万円の売上が立ち、年間売上が大きく変わります。だから、当時は案件ごとの要望に応えることが主業務になっていました。案件中心というか、機能重視の開発になっていたんです。

一方、SaaSはサブスクリプションモデルで提供しているので、受注して終わりではなく「継続利用してもらうには何が必要か？」という視点が求められます。それによって開発プロセスやUXデザイン、品質保証の考え方も大きく変わりました。

例えば案件中心の開発では、長期的に見て技術的負債になるような決断をしなければならないケースもありましたが、SaaSの開発では逆にそういう決断をできる限り排除しなければなりません。以前なら必要悪としてやっていたことでも、今は明確に「ダメだ」と言えるようになったというか。

及川 パッケージソフトだと、「こんな機能を入れてくれたら買うよ」と言われて頑張って開発しても、実際はそれほど使われないというケースもありましたよね？

佐藤 そうですね。特にエンタープライズ向けのソフトウェアは、購買を決めるのが情報システム部門の責任者などで、日々の業務で使うエンドユーザーに直接使い心地を聞くのは難しい。利用状況のログも取れないので、導入後にどう使われているかが分からないというジレンマがありました。

それがSaaSだとWebで直接ログが取れるので、エンドユーザーの使い方を確認できるようになります。これも大きな変化で、開発もユーザー満足度を高めることにフォーカスするようになっていきました。ユーザーテストも以前より頻繁にやるようになりましたね。

及川 それはそれで素晴らしい変化ですが、一方で利用状況が即座に分かるようになると、チャーンレート（解約率）やユーザーが離脱しやすい機能のようなマイナス面もあらわになります。人によっては心臓に悪い状況だと思うのですが、チームの皆さんはすぐに適応できましたか？

佐藤 その点は大丈夫でした。パッケージソフトでは知りたくても知れなかった情報なので、むしろチームメンバーのモチベーションが上がったように思います。前から、プロダクトマネジャー（以下、PM）に対して「自分たちが作ったものがどう使われているのかちゃんと測ってほしい」とリクエストするような人が多かったので。

及川 いいですね。受託体質の開発チームだと、PMが決めた仕様を実装することだけにしか興味がなく、その後の利用具合いにもそれほど関心を示さないという人が一定数いるものです。そういう人がいなかったというのは、SaaSにシフトしてユーザー中心の開発・運営をしていく上で大切なポイントになりますね。

アジャイル開発の浸透に5年ほどかかった理由
及川 先ほど開発プロセスが変わったというお話もありましたが、その変化にはスムーズに適応できましたか？

佐藤 いや、こっちはけっこう大変でした（苦笑）。継続的にプロダクトの価値を高めていくには、使い勝手の良しあしにかかわる改善をいかに素早く行えるかが重要になります。そうしてリリースしたものに対して、改めてユーザーからフィードバックを受け、さらに改善していく。このサイクルをどう回し続けるか、最初は試行錯誤の連続でした。

パッケージソフトだけだった時代は、例えば1年単位でメジャーアップデートしていたのが、今は新しいフィーチャーを毎月のように出す形になっています。小さな修正なら、もっと短い期間でアップデートすることもあります。最初はそれらをパッケージソフトと同じやり方でやっていました。要はウォーターフォールのまま、リリースまでの時間を短くしようとしていたんです。

これを半年でやれるようにしよう、次は3カ月でやってみようと段階的に短縮していく中で、いよいよウォーターフォールでこれ以上スピードを速めるのは難しいと体感で分かってきて。そのくらいから、現場で「どうやら海外のソフトウェア企業の間ではアジャイルという開発手法が流行っているらしい」「じゃあ外部からアジャイルコーチをお呼びして研修をやろう」みたいな話が出てくるようになり、徐々に変わっていきました。今では多くの開発チームがスクラムを採用しています。

及川 スクラムに慣れるまで、どのくらいかかりましたか？

佐藤 何となく形になるまでが2年くらい、本当にスクラムが定着してきたと実感できるようになったのは16～17年くらいですかね。クラウド型のSaaS提供を始めたのが11年なので、約5年かかった計算になります。

及川 開発プロセスを変えるには、相応の時間がかかるということですね。

佐藤 それに加えて、エンタープライズ向けのプロダクト開発では、開発のスピードを速めるだけでなく精度を高める取り組みも必要でした。何かしら不具合があって毎日機能や画面を修正するようだと、お客さまの業務に支障が出てしまうからです。

そこで今は、対外的なフィーチャーリリースを1カ月単位で行いつつ、内部でのレビューやテストといったイテレーション（アジャイル開発における開発プロセスの「反復」工程）は1週間単位でやれるようにしています。

及川 1カ月というリリース頻度は、どういう判断基準で決めたのですか？

佐藤 お客さまからフィードバックを受けながら、ですね。例えば「kintone」はお客さまが自由に業務アプリケーションを構築できるプラットフォームなので、機能やUI画面をユーザー自身が自由にカスタマイズできるという点が重要になります。プロダクトそのものが頻繁に変わり過ぎて、ユーザーが行うアプリケーション構築を邪魔してしまうのは避けなければなりません。この点をケアしつつ、プロダクトを進化させ続けるには、どうバランスを取ればいいのかをやりながら学んでいきました。

その結果、現時点だとアップデートは月1回ペースにして、しかも事前に内容を予告して出すのがベターだろうとなっています。さらに、高度なカスタマイズをしているお客さまや大規模なパートナー企業には、先行して検証環境を提供するようにもしています。こういう施策を組み合わせながら、プロダクトの進化と利便性向上のバランスを取るようにしています。

品質向上に向けて組織構造まで変える
及川 今のお話はプロダクト品質にもかかわる内容だと思うのですが、SaaSの提供を始めてから品質に対する考え方は変わりましたか？

佐藤 はい、大きく変わりました。パッケージソフトの開発では、出荷前の品質を上げること、つまりバグを減らすことが全てでした。致命的なバグがあった場合、当社ですぐに修正版を出したとしても、対応そのものはユーザー企業やパートナー企業にやっていただくことになるからです。だからこそ、リリース前に綿密なテスト計画を立て、QAチームのテスターが3カ月くらいかけて人海戦術でやり切る、というのが通例でした。

それがクラウド型のSaaSになると、理論上はバグがあってもすぐに直してリリースできますし、修正作業も自分たちだけで完結します。そこで、出荷前の品質チェックに時間をかけるより、MTTR（Mean Time To Repair／平均復旧時間）を短くするようなやり方にシフトしていくわけですが、このプロセスがなかなか大変でした。

及川 クラウドだから品質基準が低くなってもいい、というわけではないですしね。MTTRを短くするには不具合を即座に検知するモニタリングの仕組みづくりが不可欠ですし、素早く修復してリリースするための体制構築も重要になります。

佐藤 おっしゃる通りです。SaaSを提供し始めた2011年からしばらくは、モニタリングの仕組みも穴だらけでしたから。夜中にアラートが鳴って飛び起きたら障害とは関係ない事柄だったり、逆に重大な障害が起きているのにアラームが鳴らなかったりして、初期の頃はてんやわんやでした。

そんな状況を運用チームが中心になって改善していったのですが、次は開発全体のプロセスも変えなければならないと。設計段階からテスト・イン・プロダクションについて考える習慣を取り入れる必要がありました。

リリース前に担保するべき品質はどのレベルで、リリース後にモニタリングしなければいけない部分はどこなのか。これらをトータルで考えて品質を保証していくやり方は、パッケージソフトしか作ったことがない私たちには経験のないものだったので、慣れるまで時間がかかりましたね。今もベストなやり方を模索している状態で、19年から組織構造も変えてみました。

及川 どう変えたのですか？

佐藤 従来は職能部門制だったのを、プロダクトごとにチームを置く形にしました。

それまでは、開発本部という大きな組織の中に、エンジニアが所属する開発部やQA担当者がいる品質保証部など、職能別の組織があったんですね。PMはまた別のプロダクトマネジャー部に所属していて、それぞれの部からプロダクト開発に必要な人員がアサインされるという形でした。

ただこの形だと、エンジニアが実装して、終わったらレビューするエンジニアに渡して、それが終わったらQAに渡すという構造になりがちだったんですね。エンジニアが何を考えてコードを書いているか？ QA担当者は何を重視してテストを設計しているか？ という部分が分からないまま、ブラックボックスの状態で作業している面も少なからずありました。それに、「自分はQA担当だから品質保証部の方針を順守する」という意識も強くなってしまいます。このため職能部門をいったん廃止して、プロダクトチームだけを残しました。

及川 プロダクトへのコミットメントをより強くするのが目的ですか？

佐藤 はい。皆が同じプロダクトチームになるので、必然的にブラックボックスだった部分が減っていきます。実際、エンジニアとレビュワーとQA担当者が一緒になってコードを書くような取り組みを始めるチームが出てきて、今まで人的・時間的にコストをかけてテストしていた部分を自動化する流れも強まりました。

及川 QAの方々もテスト自動化のコードを書くのですか？

佐藤 そのための勉強がより重要になったということですね。品質保証部では以前からテストエンジニアという役割を作って自動テスト用のコードを書ける人を増やしていましたが、その動きがより強まったというか。逆に、チームによっては探索的テストをやっているときにエンジニアも同席するようになっていますし、お互いにプロダクトの品質向上に役立つことをやろうという機運が生まれたと思います。

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

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

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

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

及川 文脈とは？

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

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

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

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

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

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

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