こんにちは、LeadGrid事業部でディレクターとして働く水嶋です。

自社でSaaSサービスを展開しているけれど、実際にSaaS開発ってどうやって進めるんだろう？よりよい進め方ないのかな？と疑問に思っている方必見！ 実際にSaaS型CMS『LeadGrid』を開発しているエンジニアたちに、SaaSのサービス開発のポイントについて聞いてみました！

まず簡単にLeadGridの紹介をします。

LeadGridとは、リード獲得に必要な機能を備えたCMSサービスです。非エンジニアでも直感的にサイトの更新・編集ができます。LeadGridチームでは、新規のお客様のサイト制作、ならびに導入いただいているお客様のためにより使いやすい機能開発を進めております。

機能のアップデートは、2週間ごとにアップデートをしています。機能アップデートといっても、ユーザーの方が使うCMS管理画面のアップデートや、サイトの表示スピードを速くするためのアップデート、LeadGridチームで使用する管理画面の利便性を上げるアップデートまでさまざま。

本記事では、LeadGridの開発エンジニアに、上記の開発で心がけていることやこだわっていることをインタビューしてみました。

SaaSの開発で難しいこと・意識していること

Q. LeadGridのようなSaaSサービスの開発について、意識していることや大切にしていることを教えてください。

A1.
日々サービスを向上させて、ユーザーに満足していただく必要があります。そのため、ユーザーにかかわる新機能をリリースするときには、利用するユーザー像を定義して、ユーザー目線で分かりやすく、簡潔にゴール（目的）に辿り着けるUIを意識しています。

またLeadGridは、非エンジニアの方でも直感的に操作できることを目指したCMSです。ストレスにならないよう、説明不要なUI,UXを作ることも心掛けています。元からあるCMSの機能をアップデートするときには、必要なはずなのに実装されていなかった仕様なども改めて考慮し、追加するように意識しています。

A2.
インフラでは、サービスの安定運用と機能拡張のための整備を心がけています。やはり多くの企業様に使用していただくにあたって、セキュリティの観点はとても重要です。パッチワークだとあとで整備するのに困るので、自分以外のエンジニアが触るときも困らないように、きれいに整備することを心がけています。

A3.
社内のディレクターなど非エンジニアが管理する画面では、無停止で運用できるように心がけています。新規サイトを作るとき、ディレクターは毎日LeadGridの管理者管理画面を触ります。アドミン管理画面の改善をすることで、ディレクターが操作しやすくなる。そうすれば、結果的に新規でLeadGridを導入いただくお客様のサイト開発のスピードも上げられる。

また、どれだけ事前に調査をしてもバグが出てしまうことがあるので、とてもむずかしいと感じています。

A4.
リリースまでのスピードを速くすることです。リリースしてはじめてフィードバックをいただけるのが、SaaSの特徴。どんなに考えていても、ユーザーに使ってもらってはじめてわかることがあるので、スピードとクオリティのバランスをとりながら開発を進めています。

Q. 上記のような開発を行っていくなかで、難しく感じるのはどのようなことですか？

A1.
自由度が高くなり、かつ制限があると複雑化してしまうことがあるので、「簡潔にわかりやすく」を意識しています。いろいろ機能をつけたくなりますが、たくさんの機能をつくること＝使いやすくなるわけではありません。ただ、なるべくエンジニアが介入しないよう、ユーザーに自由に使っていただきたいので、そこのバランスが難しいです。

A2.
これまで経験のない機能の実装をおこなったりもするので、キャッチアップする時間があまりないなかで、スピードも求められるのが大変です。

A3.
日々、顧客の課題は増えていき、とくべき課題の優先順位が変わっていくため優先順位が変わっていくため、柔軟に対応することが求められる点に難しさを感じています。

A4.
使いやすく、ユーザーに優しいUXを考えること。正解がないので、一般的な挙動に関しては、参考をしっかり見るようにしています。とはいえ、リリースしてから「この機能がわかりづらい」と言われることもあるので、説明不要でも理解してもらえるようなUXは難しいと感じます。

Q. 開発しているとき、どんなことがおもしろかったり、楽しかったりしますか？

A1.
ユーザー側に立って考えて、使いやすいと思ってもらえるときや、自分が実装した機能をいろいろな人が使っているんだなあと思ったときです。

A2.
機能を簡潔にわかりやすくすること、機能として便利なものを作ることは楽しいと思います。

A3.
開発メンバーが増加したとしても、リリースまでの開発速度が低下しないようなプロセスづくりや体制づくりも心がけています。

A4.
試行錯誤して問題を解決するプロセスや、難しい機能をうまく実装できた瞬間などは達成感があります。

Q. メンバー全員、向上心やモチベーションが高いように感じます。なぜそのようなメンバーが集まっているのでしょうか？ 開発メンバーについて教えて下さい！

A1.何かをつくることが好きな人が多いと思います。自分は2年目ですが、自分よりあとに入ってきた新卒の子でも、自分が知らないことを知っていたり、伝えていないやり方を知っていたりするので尊敬しています。自分もがんばらなければと思います。

A2.メンバー全員、業務外での勉強量がすごいです。技術を追っていくというよりは、趣味で開発をしたりする過程でわからない技術を調べて、日々のインプットにつながっているんだなあと思います。試験とかも自ら積極的に受けていて、モチベーションが高いなと思います。とても信頼しています。

A3.デザイナー視点でいうと、開発メンバーは全員開発が好きそうですね（笑）。管理画面のUI,UXの提案をすると、ユーザビリティとエンジニアの視点からもっとよくしたいと様々な角度の意見をいただけるので、よりよいUI,UXがつくれる環境です。仕事でタスクとしてやっているというより、本当に開発が好きで、「こうしたほうがいいよね」とこだわりを持っている人たちばかりです。

一年半で開発メンバーが3倍に。どのような体制やコミュニケーション方法で開発を行っていますか？

私もLeadGridには2年前から加わりましたが、この1年間でエンジニアの人数がかなり増えたように思います。開発できる範囲やスピードも上がったと思いますが、そのぶん、開発体制などは柔軟に変化させなければいけなかったと感じています。そのあたりを詳しく聞かせてください。

Q. 開発初期といまとでは、ミーティングの方法や頻度などに変化はありましたか？

A1.
ミーティング方法には、3段階の変革期があるかなと思います。

【立ち上げ期】
必要に応じて話し合いをしていく感じでした。とくにツールなどは使っておらず、ただ開発をすすめていました。

【立ち上げから半年】
新メンバーが入り、メンバーの開発状況の共有が必要になったことで、ミーティングという概念が出てきました。このときから毎日、朝のミーティングで、自分のやっている開発の進捗などを報告し始めます。JIRAもカンバン形式で、タスクだけきって使い始めました。

【現在】
アジャイル開発の中の一手法である「スクラム開発」をベースに取り入れ、開発を進めるように変わりました。それに伴い、タスクも「エピック」「課題」「サブタスク」などの粒度で分けて作成していき、管理やリリースの効率化を図っていきました。はじめは、1週間のエピックでおこなっていましたが、いまは2週間でエピックをきっています。

Q. ミーティング形態を変えるきっかけについて、どのようなことがあったのでしょうか？

A1.
初期の頃、1週間で何回もミーティングの形態を変えていたので、メンバーから「慣れないからせめて2週間は続けさせて！！」と怒られたことがあります（笑）。そのくらい試行錯誤していました。ここ3ヶ月くらいは変わってないけど、まだまだ改善点あると思っています。

A2.
ミーティングの頻度について、社内の別チームでいろいろトライしたり、はまらなかった方法を聞いて応用していったりしました。社外部の開発の話も参考に、ミーティングの体制や手法などを吸収していました。

A3.
ミーティングではないですが、『gather』というツールをつかって、常に相談できる環境になっています。毎回Google Meetをつなげるのが大変だったので、gatherで好きなときに聞けるようにしています。常にいなければいけないわけではなく、返答がないときもありますが、顔出しをしないので、気軽に相談できますね。

A4.
ミーティングは常に見直しをしていて、非効率なミーティングは形式の見直しを行ったり、逆に必要なMTGは随時取り入れたりしております。現在は、毎日デイリースプリントを実施し、スプリント終了日にはスプリント計画に対しての評価のための、スプリント振り返りミーティングを実施しております。

Q. 開発チーム全体でとりいれてよかったツールトップ3を教えて下さい！

① gather（ギャザー）
コロナになり、リモートでの開発のなか、すべてオンラインでコミュニケーションをとるのは難しいと感じたメンバーが提案してくれました。複数人でも可能なので、毎回Google Meetのリンクを発行する手間や顔出しの心理的不可が減り、気軽に相談できる環境になったと思います。

② mabl（メイブル）
E2Eテスト自動化ツールチェックツールで、アップデート実施時などに、既存機能のデグレーションをいち早く気づくために利用しているツールです。これを導入することにより、人によるモンキーテストの割合が削減され、より安全により早いテストの実施が可能になりました。

③ bugsnag!（バグスナッグ）
コンソールログでバグが出ているのを、Slack通知で知らせてくれるツールです。「スプリント内でこれだけバグが出ました」など、エラー件数を減らすことが可視化できるようになりました。日時、コード上のどこでエラーが発生したかがわかるので、バグ問い合わせと照らし合わせることで調査スピードが速くなりました。

Q. 開発体制の仕組み化や効率化のために、意識していることを教えてください！

A1.
新しいメンバーが入ったときのオンボーディングコスト（＝新しいメンバーが組織に馴染むのを促進させる取り組み）はなるべく仕組み化をしています。理想は2週間後に独り立ちすることですが、まだまだ改善の余地ありです。

たとえば、1人目に入ってきたメンバーに対して、2時間の説明をしなければいけないとしたら、2人目が入ってきたときには、1時間で説明できるようになっていないといけないと思っています。

最初のメンバーへの2時間の説明は「これを説明しないといけないんだな」という発見の時間にする。そして2人目以降は「説明しないといけないものをどう速く説明できるか」という点で考え、常にドキュメント化をしています。

より良いプロダクト開発/提供のためには、組織拡大のしやすさは重要な観点だと思うので、属人化しにくい体制構築を心がけています。

A2.
ひとつのパーツを作ったら共通化して、別の開発をしているメンバーが使えるようにしています。ほかには、人によってコーディングの仕方が違い、設計が煩雑になっていたので、コードを読み解くのにも時間がかかっていました。それをチームとしてファイルなどの作り方を決めて、シンプルなコードにすることで、コードを読み解くスピードを速くし、属人化しないように整えています。

まとめ

• SaaSの開発では、リリースして終わりではなく、リリースして顧客からのFBを得てからが本番のため、スピードとクオリティのバランスを保ちつつ開発していくことが大切である
• 開発が好きなメンバーがいるからこそ、SaaSの改善のスピードがかなり速くなる
• 非効率なMTGは形式の見直しを行ったり、逆に必要なMTGは随時取り入れたりしている。相談しやすい雰囲気やそれを作るためのツールを導入することで、最適なコミュニケーションをする。
• より良いプロダクトをより早く開発し提供するためには、属人化しないようにする必要があるのでドキュメント化や、コード設計そのものの見直しを行う。

以上、開発メンバーのみなさんへのインタビューでした。ご協力いただきありがとうございました！

ディレクターとしても、このような開発メンバーがいることで、安心してお客様にサービスを提供できることができると思えるインタビューになりました。

なお株式会社GIGでは、リード獲得に必要な機能を揃えたCMS／CRMツール『LeadGrid』の提供はもちろん、SaaS開発のご支援もおこなっています。お気軽にお問合せください。

水嶋 結

株式会社GIG LeadGrid事業部ディレクター。立教大学現代心理学部を卒業後、新卒でGIGに入社。現在は、ユーザー目線で仕事ができるWeb業界に興味をもち、ディレクターとしてコーポレートやサービスサイト、メディアサイトなど多岐にわたるサイト過去30社以上のディレクションを担当。