実践で学んだプロダクト構築/システム開発でビジネス上考慮すべき8つ
はじめに
私はエンジニアではありません。
そのため、エンジニア視点ではなく、事業責任者として、事業展開をする中でのプロダクト構築において、ビジネス視点（少しエンジニア寄り）からシステム開発において学んだことを備忘録がてら記載します。
開発組織の立ち上げから行い、試行錯誤の中で、優秀なエンジニアと日々議論を重ねた結果、構築したシステム（サービス）は100万人を超えるユーザーが利用するサービスまで成長しました。
本記事は、そんなシステムを構築する上で学んだことの内8個を、初歩的なところから、事業観点でのリアルなところまで、アラカルトで記載しています。
なお、システムはAWS上にて構築していますので、AWSを前提にしています。
スタートアップやベンチャー企業において、システムのことはよくわからないけど、事業を推進していく立場である経営者の方や事業責任者の方に少しでも役立つ記事となっていれば幸いです。
■開発管理・運用・コストの観点で考慮すべきこと
※大前提として、構築したサービスは、ウォーターフォール型ではなく、アジャイル型で、月数回の機能リリースを行う運用を取りながら、開発を進めていました。
①新機能で別の不具合が発生する「デグレ」
初歩中の初歩ですが、開発初期は結構起き、やはりこれは記載する必要があると思いました。
一つの機能を開発すると、過去に修正した機能が元に戻っている、または別の箇所で不具合が発生する…とにかく当初はこの繰り返しでした。
立ち上げ当初は、開発組織を拡大しながら機能拡充を行っていたこともあり、影響範囲の調査やテストが不十分になり、結果的にプロジェクト自体に無駄な開発工数がかかってしまいました。
（開発体制の構築という観点では、総合的に拡充はできましたが）
当然ではありますが、やはりテストは徹底すべきだということは強く学びました。
※但し、機能アップデート頻度が高い場合、テストケースをどこまで網羅すべきか、という点を考慮しながらテストシナリオを作る必要はあります。
これはおそらく多くの開発において起きている問題かと思いますが、適切に影響範囲を把握して、テストをしっかりやることで、確実に対処できる問題ですので、一つ一つ地道に対応していきましょう。
②サービスを停止させない「可用性担保」
構築したサービスは、何万人というユーザーが利用するWEBサービスでしたので、サービスリリース後は、可用性担保が課題でした。
幸いなことに、サービスがダウンするケースはほぼありませんでしたが、WEBサーバ（EC2）の冗長化構成、RDSのMultiA-Zなど、当然行うべき可用性担保がケアされていないサービスだと、サービス自体が停止してしまう問題などが起きる可能性がありますので、ビジネスサイドの方でもこの辺りは注視しておくとよいと思います。
この際注意すべき点としては、EC2の冗長化構成をした際に、サーバを無駄に準備しておくケースなどがあります。この場合、サーバ固定費が無駄になるケースが出てきますので、オートスケール機能などを適切に活用することで、可用性を高めつつ、コストを最適化することが可能です。
また、よくデータセンターの耐障害性や可用性も話題に上がるケースがありますが、下記の記事を見て頂くと、適切に対処されていますし、アライアンスなどでアライアンス先から聞かれたときもこのページを紹介すると良いと思います。
③サービス利用のUXを向上する「性能要件」
性能要件として代表的なものの一つとして、WEBサービスのページ読み込み速度「レスポンスタイム」があります。
ここは結構苦しめられましたし、事業展開をしていく上で、サービスレベルとしての信頼性に直結しますので、非常に重要視していました。
可用性担保で挙げた、EC2サーバの冗長構成やオートスケール機能での対策以外に、最近では、サーバレス構成であるLambdaというAWSのサービスで対策することも可能となっています。
Lambdaを活用することで、不要な冗長化構成を構築する必要がなくなりながら、コストも安く抑えることが可能です。
また、Lambdaは大量の並列処理を行うことが可能となっているため、大量アクセスがあった際に、高速で処理を実行することができ、結果としてレスポンスタイムを改善することが可能です。
Lambdaはサーバレスのため、サーバの冗長化などを考慮する必要がない、ということではあるのですが、注意点としては、2020年4月に、AWSで障害が発生し、Lambdaが機能しない、という事象が発生しました。
Lambdaだから大丈夫というわけではなく、このようなケースが発生した際でもサービスが稼働する状態にできるよう注意する必要があります。
また、Lambdaのようにシステム構成で対処することももちろんアリですが、非常に有効な対策であり、基本的なものは、SQLチューニングです。
エンジニアから、サーバスペックを上げないとダメ、サーバを増やさないとダメ、と言った話があった際は、この観点での対策が行われているのか、をまずは確認する（スロークエリの数）と良いでしょう。
コストを増やさずに、パフォーマンスを改善できる可能性が大きくあります。
他にも、AWS EC2の一部（T系インスタンス）には、CPUクレジット、という考え方があります。ベースラインと言われるCPU使用率が決められており、必要時にクレジットを活用してベースラインを超えてCPUを使用できる、というものです。
このCPUクレジットには注意が必要で、一定のルールによって貯められたCPUクレジットが0になると、ベースライン以下の性能しか出ないケースが存在するため、結果的に、パフォーマンスを低くする場合があります。
正しく設定されているかどうか、確認してみると良いかもしれません。
④初歩中の初歩、SSLの更新漏れ
突然、初歩中の初歩ですが、SSLの証明書期限を忘れ、証明書更新を行っていなかった、ということもありました。意外に影響が大きいです。
すごく地味な話ではありますが、注意しましょう。
⑤コストを削減する「AWSリザーブドインスタンスまたはSavings Plans」
事業P/Lを考える上で、サーバコストは非常に重要なポイントです。
AWSにはリザーブドインスタンスやSaving Plansと言われる、1年/3年分のまとめて購入により大幅に利用料が割引されるプランがあります。
※Saving Plansは2019年11月に登場した新しい割引サービスです
詳しくは下記の記事がわかりやすいですが、定常的に利用しているインスタンスがある場合は、これらの割引を使わない手はありません。
年間最大で72％もの削減ができます。比較的高価なRDSについても30％近く割引がされますので、P/Lインパクトも大きくなるため、ぜひ検討してみてください。
⑥システムの柔軟性を高める機能毎開発
大きなシステム開発を行っていると、どんどんと機能拡充がされ、結果的に機能間の影響範囲が大きくなり、新しい機能開発の工数が上がりやすくなったり、機能自体の追加が難しくなる、という課題に直面しました。
また、機能を盛り込むことで、サービスの展開とともにその機能が不要になったときに結果的に使わなくなるなど、機能自体が無駄になってしまうケースも出てきます。
そのため、開発するサービスにもよりますが、極力最小構成の機能単位での開発行い、それらの機能をAPIを活用して連携するなどすることで、追加機能の開発も行いやすく、また不必要な機能の削除も行いやすくなるため、全体のサービス設計も行いやすくなると考えています。
上記はシステムの話ではありますが、サービスリリースのスピード感を速めることに繋がりますので、ビジネスサイドの方も気にしておいたほうがよいと思っています。
⑦API連携方法について
上記の機能連携でもあるように、サービスを展開していく中で、APIによるサービス間連携を行うことが増えてくると思います。
ここでも最初から考慮しておけばよかったな、と思う開発手法がありました。それは、Pull型のAPI連携システムの構築です。
（Push型を構築していました）
APIにはPush型/Pull型があり、それぞれにメリット・デメリットはあると思いますが、私が事業を進める上で感じたPush型のデメリットとしては大きく2つです。
・APIサーバの負荷により、データ連携が遅くなること
・セキュリティ基準の高いシステムがAPIを受け入れられないこと
特に後者のデメリットは重要で、そもそもAPI連携ができなくなります。
結果的に、事業アライアンスのスピード感を遅くすることになりますので、API連携用の仕様を考慮する場合は、上記の点を考慮すると良いと思います。
PushとPullを理解を深めるために、以下の記事は参考になりました。（英語）
⑧開発優先度の決定
これは非常に悩ましい問題でした。
・マーケットニーズのある機能
・システム視点で必要性がある機能
・内部でプロダクト方針として追加したい機能
など、これらを常に天秤にかけながら、開発優先度は決めていました。
また、上記を検討する上で、開発難易度（開発規模）、緊急性（不具合対応等）、重要性（売上インパクト）などを指標にして、全体の優先順位を常にチューニングしながら運用を行いました。
例えば、
・バグや不具合は当然ながら緊急性が高いので対応は最優先に行う
・マーケットニーズが高い＝重要性も高い、が開発規模が大きくなりすぎるものは後回し
・プロダクト方針として追加したく、開発規模も小さめだからすぐ実施
といった用に、どの観点で必要な機能で、それらの影響がどのようなものなのか、を常に検討していました。
この開発優先度の決定については、正解はないと思っていますが、事業拡大に非常に大きな影響を与えるものであり、開発リソースは限られているため、常に慎重に行っていました。
まとめ
今回は、過去のプロダクト開発において学んだことを、全部ではありませんが備忘録がてらまとめました。
同じような課題を持っている方も多いのではないかと思いますし、そのような方が少しでも参考になればと願っています。
今後、今回記載していないことや、新たな開発で学んだことなど、追記などしていければと良いなと思っています。
この記事が気に入ったらサポートをしてみませんか？