少人数でSaaSを運営する際のシステム保守の考え方
こんにちは。牧です。
システムの保守にかかる工数の一般的な目安は、15%と言われています。年間の営業日を約244日と仮定すると、36.6日≒月3日≒月24時間かけて良い計算です。
しかし、少人数の会社にとって、これはあまり参考にならない数字だと最近感じるようになりました。というのも、セキュリティ対策やサポート切れが迫るソフトウェアのアップデート、不具合発生時の調査への工数が、それ以上にかかってしまうこともあるからです。
今回は、弊社のように少人数でSaaSを運営している会社が、メンテナンス工数を安定化させるために何を考えているのかまとめます。本記事が皆さんの日常業務を見直すきっかけになれば幸いです。
既存機能と新機能のバランスについて
メンテナンスにかかる工数は、必要としているコンポーネント、依存しているライブラリの数によって大きく変わります。 まずは外部依存の少ない設計と、その最小限の依存関係におけるDRYなコードやテスト実装（複雑さをGUIに転嫁したローコードは目標としない）が基本です。
しかし、限界はあります。
新機能の追加ばかりを優先してしまうと、管理対象が増加するため、その後で新しい挑戦をする余裕が失われます。逆に安全性と向き合う時間が増えすぎた場合は、新機能開発に打ち込めない期間が増えるため、プロダクト全体の成長やモチベーションに悪影響が出てしまいます。
追加と削除はセットで考える
必要なメンテナンスを行いながら無理なく計画を進めるためには、新機能の追加を考える際、代わりに何を手放すか、削除するかを同時に考慮しなければなりません。
弊社における直近の議論では、クラウド電話システム「CallConnect」の通話メモ入力欄で「タグ・メンションのプルダウン入力を追加すべきだ」という意見が出ました。
しかし、コールコネクトの通話メモ入力欄には、既にキーボード操作に対応したタグ・メンション機能が存在します。機能として重複するため、ユーザーの画面にプルダウンが見えている必要性はどの程度あるか？既存機能を削除するのか？といった論点で話し合いが進みました。
また、管理工数も問題になりました。既存機能を削除できない場合、増えた機能の分だけ、コードが増えてしまうからです。
最終的にはプルダウン入力は追加せず、既存機能の仕様のままという結論になりましたが、常に追加と削除はセットで考えておく必要があります。
大概の議論であれば数分の話し合いで結論を出せますが、難しい話になると議論が長期化するため、コミュニケーションコストも考慮しなければならなくなります。
重いけど削除はできないもの＝再構成を検討
削除できない重要な機能については、既存機能のメンテナンスを切り捨てて、より管理しやすい互換・上位機能を新しく作るという考え方もあります。広報的なインパクトは生み出せないかもしれませんが、その後の管理工数が減るのであれば、早めに行動するほどその後動きやすくなります。
いつ考えるかが重要な管理対象もある
一方で、対応がほぼ無期限で先延ばしになる管理対象も存在します。
例えば、UNIX時間表現における2038年問題については、直面する1~2年前から大掛かりな点検とアップデートを強いられるシステムも多くなるかと思います。また、対応後もすべてのコンポーネントが正しく動作する保証はありません。
この問題については、かなり先の話である点と、各プロダクトだけを修正しても安全性を確保できない点があるため、今考えるべきではないと判断できます。
こういった管理対象については、一旦視野から外しておき、適切なタイミングになったら時間を取ることが重要になります。
まとめ
既存機能にもコストが発生することと、そのコストが増え続けることは無視できない問題です。判断を誤ると、よくわからない機能が増えて、代わりに人手が不足してしまいます。
私たちはコールコネクトの機能を設計・考慮していく中で、常々、管理対象が増えるかどうか、増えるのであれば何を削るかということを考えてきました。効率よく使っていただくためにも、冗長な機能は追加されないプロセスになっています。
今後も、少人数だからこそチーム全体で開発意識や問題意識が合わせやすい点を強みとして、よりシンプルな機能提供を心がけていきます。