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

[伊藤健吾，ITmedia]

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

アジャイル開発の浸透に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の方々もテスト自動化のコードを書くのですか？

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