メール インフラストラクチャ製品開発プロセスにおける上位 5 つの課題
公開: 2023-03-20電子メール インフラストラクチャは、電子メッセージの送信、受信、および保存を可能にする相互接続されたシステムです。 そのため、B2B であろうと B2C であろうと、情報交換を促進する上で重要な役割を果たします。
その点について、Radicati Group Inc. は、送信された電子メールの総数が 2027 年に 4000 億近くになると見積もっています。また、世界中のユーザーの数は、同じ年に 50 億に達すると予想されています。
電子メール トラフィックの量が増え続ける中、堅牢で信頼性の高い電子メール インフラストラクチャを持つことの重要性は否定できません。
ただし、信頼性の高い電子メール インフラストラクチャの開発と維持には、問題がないわけではありません。 この記事では、電子メール インフラストラクチャ製品の開発プロセスで組織が直面する上位 5 つの課題について説明し、それらを克服するための実用的なソリューションを提供します。
1: スケーラビリティ
チャレンジ
トラフィックが増加し続けるため、電子メール インフラストラクチャは負荷の処理に苦労する可能性があります。 企業は、成長に対応し、サービスの中断を回避するための予防措置を講じる必要があります。
コンセプト開発と並行して対策のブレーンストーミングを行うことは好ましいことです。 そうでない場合、開発者は MVP のリリースでそれを行う必要があります。そうしないと、次のリスクが生じます。
- 生産性の低下
- 顧客満足度の低下
- 潜在的な金銭的損失
- ドメインオーソリティ評価の低下
- 送信者の評判の低下
ソリューション:
- クラウドベースのインフラ
- 負荷分散
クラウドベースのインフラストラクチャの使用
クラウドベースのインフラストラクチャにより、開発者はサードパーティのメール サービスのスケーラビリティと信頼性を活用できます。 次に、彼らは増大する顧客のニーズに対応するために必要なリソースを確保します。
有望に聞こえますが、実際にはどのように機能するのでしょうか?
サードパーティの電子メール サービスは、大規模な集中型データ センターを使用してデータを保存および処理します。 そのため、ソフトウェア開発会社は、自社に投資することなく、最新のテクノロジとリソースを活用できます。 そして、それは一石二鳥です。
- このアプローチにより、運用コストが大幅に削減されます。
- また、増大するニーズを満たすスケーラブルなソリューションを組織に提供します。
ここで強調すべき重要なことは、クラウドベースのインフラストラクチャを 1 つずつ開発する必要があるということです。 これは、クラウドでいくつかのタスクの実行を開始し、現在の負荷 (この場合はメールまたはユーザー リクエストの量) に基づいてタスク自体をスケーリングするのが最善であることを意味します。
ただし、クラウドベースのタスクはその場しのぎにスケーリングするべきではありません。それぞれの製品開発戦略を決定することが重要です。 さらに重要なことは、それに関連する課題やボトルネックがあるかどうかを知る必要があることです。
負荷分散の実装
もう少し深く掘り下げる前に、負荷分散はクラウドベースのインフラストラクチャと一緒に実装する必要があることに注意してください。 せいぜい、1 つの製品開発フェーズ内です。
現在、ロード バランシングとは、複数のクラウド内アーキテクチャおよびタスクにまたがるワークロードの分散を指します。 主な利点は、既存の製品がトラフィックのピーク時でも増加したボリュームを処理できるようになることです。
ワークロードは複数のサーバーに分散されるため、メール トラフィックの量によって 1 つのサーバーが抑制されることはありません。 したがって、サービスの中断やボトルネックが発生する可能性は大幅に低くなります。
さらに良いことに、ロード バランシング アルゴリズムを使用して、通常は次の 2 つの要因に基づいてワークロードの分散を動的に調整できます。
- リクエスト数。
- 各サーバーの処理能力。
地獄のような宿泊施設のプラットフォームを構築する
さかのぼる 2012 年、Airbnb の製品開発プロセスは極めて重要な段階にありました。
彼らは、プラットフォーム全体を拡大しながら、ターゲット ユーザーの頭を直撃していました。 しかし、ユーザーからのフィードバックにより、変更要求、紛争、および払い戻しを含む驚くべき数のエッジ ケースが明らかになりました。 当時、これらはすべて電子メールを介して手動で処理され、リクエスト処理をサポートするバックエンドがなかったため、ビジネスのスケーリングに大きな負担がかかりました。
Airbnb はリスクの高い選択に直面していました。1 年以内に 1000 人以上を雇用するか、特殊なケースを処理する自動化されたフレームワークを構築するかです。
はい、彼らは後者を選びました。
当時、Airbnb のプロダクト マネージャーであったジョナサン ゴールデンは、容赦なく優先順位を付ける必要がありました。 主な目標は、エッジ ケースを処理および分類する自動化されたクラウド ソリューション (バックエンド フレームワーク) の計画を作成することでした。
フレームワークが整備されたことで、Airbnb は迅速にブロックを解除し、年間 300% から 600% のペースで拡大を続けました。 これらのパーセンテージは、Airbnb の初期の指数関数的成長を示していることに注意してください。
ただし、この例から得られる製品開発のポイントは、すべてをクラウドに移行してワークフローを自動化するだけではありません。
- 最初に技術的な課題を手動で処理することが不可欠です。 そうしないと、開発者が根本的な問題を十分に認識していない可能性があります。
- 企業は、スケーリングの自動化や負荷分散などを適用する前に、あまり長く待つべきではありません。 間に合わないと、課題が大きくなりすぎて、克服するのが非常に難しくなる可能性があります。
- 製品ロードマップの他の問題に適用できるソリューションまたはフレームワークを常に作成するようにしてください。 そうすることで、チームの機敏性が大幅に向上します。
2: セキュリティ
チャレンジ
電子メール インフラストラクチャのセキュリティ、またはセキュリティの欠如は、組織が潜在的な顧客と効果的に通信する能力に直接影響するため、非常に重要です。
製品開発チームは、実用最小限の製品を開発するかなり前の早い段階で、この課題に対処する必要があります。 しかしそれだけではありません。 完成品を扱っている場合でも、定期的なセキュリティ監査を優先する必要があります。
機密情報は電子メールで交換されることが多いため、セキュリティ違反によって機密情報が漏洩する可能性があります。 これは、評判の低下、顧客の信頼の喪失、法的影響の可能性など、組織に深刻な結果をもたらす可能性があります。
さらに、すべてのチームが潜在的なセキュリティ リスクを理解し、暗号化とセキュリティ プロトコルを回避できる違反を防止することが重要です。 そのようなリスクの 1 つにソーシャル エンジニアリングがありますが、これについては次のセクションのいずれかで詳しく説明します。
ソリューション:
- 暗号化
- 安全なプロトコル
- 定期的なセキュリティ対策の更新
SSL や TLS などの安全なプロトコルは、転送中の電子メール データの暗号化および認証サービスを提供します。 このため、電子メール インフラストラクチャ製品のロードマップにおける防御の最前線と見なすことができます。 さらに、組織は内部のセキュリティ対策を定期的に見直して更新する必要があります。
どうやって？
たとえば、ソフトウェアを開発している会社は、エンジニアやその他の利害関係者がコード ベースや git などへのアクセスを制限するための内部ポリシーを確立する必要があります。アクセス権。
開発チームは通常、リスト権限の原則を使用して、より高いレベルのセキュリティを実現します。 これは、より多くのアクセスがオンデマンドで提供され、すべてにアクセスできる人がほとんどいないことを意味します。
以前、移動データ (転送中のデータ) を暗号化する SSL と TLS について説明しました。 しかし、企業は保管中のデータの暗号化を検討し、そのデータへのさまざまなアクセス レベルを確立する必要もあります。
「ピンキー約束、私たちはあなたをハッキングしません!」
これはややネガティブなビジネス ケースですが、セキュリティには常にソフトウェアと人という 2 つの側面があることを明確に示しています。
2023 年 1 月、Mailchimp はセキュリティ侵害を受け (12 か月以内に 3 回目)、133 人の顧客の機密データが流出しました。 ソーシャル エンジニアリングは、詐欺師が機密情報にアクセスするために使用した戦略でした。
基本的に、これは、オンライン詐欺師が疑いを持たず、おそらく経験の浅い Mailchimp の従業員を使用して、保護されたデータにアクセスすることを意味していました。 詐欺師は、従業員の資格情報をフィッシングで盗み、システム自体ではなく、従業員をハッキングしました。 それにもかかわらず、約 133 人のクライアントの機密情報が公開されました。
肝心なのは、セキュリティの技術的側面は防弾である必要があるということです。 しかし同時に、会社は手順を確立し、フィッシングやその他の種類のオンライン被害者にならないように従業員を教育する必要があります。
3: 信頼性
チャレンジ
信頼性は、システムが長期にわたって正しく一貫して機能する能力を決定します。 そのため、新製品開発プロセスのさまざまな反復における最大のハードルの 1 つです。
なぜ？
信頼性がなければ、ユーザーは電子メールが期待どおりに配信および受信されることを確信できず、最終的に価値提案を台無しにしてしまいます。 確かに、これは電子メール インフラストラクチャの場合ですが、ここにはより大きな図があります。
SaaS の最終製品の信頼性は、ブランドの評判とその提供能力に直接影響します。 MVP であっても、すでに成功している製品であっても、RAM の使用量の増加、ユーザー リクエストの急増、予期しないインフラストラクチャの負荷など、さまざまな種類の障害に耐える必要があります。
ソリューション：
- 冗長化とバックアップシステムの実装
- 定期的なインフラ監視
冗長性とは、同じデータの複数のコピーを異なる場所に保存することです。 そのため、1 つのシステムに障害が発生した場合でも、使用できるバックアップがあります。 いくつかのテクノロジーがそれを可能にしますが、最も顕著なのは負荷分散で、電子メールが複数のサーバーに分散されて障害のリスクが軽減されます。
次に、定期的なインフラストラクチャの監視により、開発者が実際の問題になる前に問題を検出して解決できるようにするメトリックが提供されます。 これは、監視ツールと定期的なシステム チェックで実行できます。 または、開発チームが概念テスト中に SWOT 分析を適用して、最適なアプローチを決定できる場合もあります。
監視といえば、開発者が監視に加えてアラームを作成するのが最善です。 たとえば、次の状況ではアラームを設定する必要があります。
- プロセスがより多くのメモリを消費し始めた場合。
- 特定のデータ処理/コンピューティングの問題がある場合。
- 500コードレスポンスの場合。
これらのアラームは、社内のアーキテクチャ サポートとオンコールの製品管理に関連しています。 どちらも、ソフトウェア開発プロセス中、またはソフト製品の発売時に確立する必要があります。
簡単に言えば、懸念されるイベントによってトリガーされたアラームがある場合、エンジニアは真夜中でもすぐにそれに飛びつくべきです。
巨人はどのようにそれをしたか
Google 自体は、信頼性の課題を早い段階でうまく克服した製品設計戦略の好例です。 同社のインフラストラクチャは、複数レベルの冗長性を備えた設計になっています。 これにより、検索エンジンの巨人は、内部障害が発生した場合でも、ユーザーの電子メールが期待どおりに配信および受信されることを保証できます.
もう 1 つの例は、負荷分散システムとバックアップ システムを使用して信頼性の高い電子メール インフラストラクチャを実装した Microsoft です。 これらの対策により、Microsoft は、大幅な成長と需要の増加に直面しても、電子メール サービスの信頼性を高く保つことができました。
しかし、残念ながら、もうそうではありません。 製品のライフ サイクル中に、Microsoft が適切な市場調査と競合他社の分析を実行できなかった可能性があるいくつかの変曲点がありました。これについては、「期待されるパフォーマンスの管理」セクションで詳しく説明します。
4: 相互運用性
チャレンジ
相互運用性は、電子メール インフラストラクチャまたは任意の SaaS サービスが、他のアプリケーションと統合して適切に機能する能力を示します。
通常、統合には次のものが含まれます。
- 顧客関係管理 (CRM)
- エンタープライズ リソース プランニング (ERP)
- データストレージ
メリットは何ですか？
さまざまなアプリケーション間で情報をシームレスに交換する機能は、企業が情報に基づいたデータ駆動型の意思決定を行うのに役立ちます。 さらに、製品関連のプロセスを合理化できます。 おまけに、高い相互運用性により、ユーザー エクスペリエンスが大幅に向上します。
製品コンセプトをブレインストーミングする際には、この側面に対処する必要があることに注意してください。 そして、ターゲット市場で利用可能なものに対して統合オプションを比較検討することは有益です.
ソリューション：
- オープンスタンダード
- クロスプラットフォームの互換性
オープン スタンダードは、さまざまなシステムの連携を可能にする公開仕様です。
電子メール インフラストラクチャの主要なオープン スタンダードには、Simple Mail Transfer Protocol (SMTP)、Post Office Protocol バージョン 3 (POP3)、および Internet Message Access Protocol (IMAP) が含まれます。
互換性に関しては、電子メール インフラストラクチャは、さまざまなオペレーティング システム (Windows、macOS、Linux) やさまざまな Web ブラウザー (Google Chrome、Mozilla Firefox、Safari など) で動作するように設計する必要があります。
ただし、オープン スタンダードを組み込み、クロスプラットフォームの互換性を確保することは簡単ではありません。 SMTP を例にとると、多くの場合、開発者は特定の調整を行う必要があり、場合によっては暗号化を追加することさえあります。 この修正やその他の製品固有の修正を簡単に行うには、AWS などの相互接続されたプラットフォームを使用することをお勧めします。
最後に、開発チームは、ソフトウェアをサードパーティの統合で適切に機能させるために、署名、スパム ソリューション、DNS レコードなどに細心の注意を払う必要があります。
一言で言えば、製品開発プロセスの各段階で標準的なフォーマットとプロトコルに従うことです。 その後、エンジニアは必要に応じてバックエンド ワークフローとフロントエンドをカスタマイズできます。
少し余裕を持って
Slack が私たちのコラボレーション方法を再発明したと信じているなら、それは間違いではありません。 しかし問題は、彼らがそれをどのように行ったかです。
Slack が市場投入段階で安定したソリューションを持っていたという事実は無視しましょう。 そして、欲求不満のITワーカーの大群を変えることに成功した機知に富んだマーケティング戦略を忘れましょう. ここで重要なことは、変換後に何が起こるかです。
まず第一に、Slack に入るハードルは非常に低いです。 ただし、想像できるほとんどのユースケースをカバーしています。 その後、チームを Slack に移行するのは非常に簡単です。 ユーザー管理は手間がかからず、統合のリストは延々と続きます…
ビジネスの規模と範囲に応じて、Jira、Notion、Coda、Google アプリなどを接続して、すべての通知とデータ チャネルを 1 つの屋根の下に置くことができます。 すべて数日または数時間以内に。
最も印象的なのは、Slack の相互運用性がほとんど設定して忘れられることです。 必要なものをすべて統合すれば、いつでもクリック 1 つでデータまたは通信ソースから離れることができます。 そして、そのユーザー エクスペリエンスは他の追随を許しません。
5: パフォーマンスへの期待を管理する
チャレンジ
パフォーマンスへの期待を管理するという課題は、製品がエンド ユーザーのニーズと要件を確実に満たすようにすることです。 そのため、特に SaaS を開発する場合は、パフォーマンスの期待をユーザーの期待と同一視しても問題ありません。
明確にするために言うと、電子メール インフラストラクチャ製品、または任意の SaaS の成功は、エンド ユーザーとターゲット カスタマーがそれをどれだけうまく認識しているかに大きく依存します。 つまり、製品がユーザーのパフォーマンスの期待をどれだけ満たしているかです。
電子メールへの依存度が高まるにつれて、ユーザーはインフラストラクチャが安全で高速で信頼できるものであることを期待しています。 さらに、ユーザーは次のことを望んでいます。
- 使いやすい
- 複数のデバイスからアクセス可能
- メール トラフィックを大規模に処理できる
ソリューション：
- テスト
- 最適化
- 明確なコミュニケーション
- フィードバックループ
当然のことながら、定期的なテストと最適化は、製品開発プロセスの不可欠な部分である必要があります。 ユーザーからのフィードバックを収集するための調査、フォーカス グループ、A/B テストの実施などが含まれる場合があります。
明確なコミュニケーションは、信頼と透明性の構築に役立つため、テストと密接に関連しています。 多くの場合、コミュニケーションには、開発プロセスに関する定期的な公開更新、インフラストラクチャの変更に関するユーザーへの通知、およびユーザーが生成したパフォーマンスの問題への対処が含まれます。
すべてのコミュニケーションとテストにより、開発者は適切な顧客フィードバックを得ることができ、顧客のニーズと期待を満たすのに役立ちます。 ここで重要なステップは、与えられたフィードバックを製品開発プロセスに統合することです。
簡単に言えば、これはシステムのすべての欠点に注意を払うことを意味します。 ビジネス分析を行って、商品化を損なうことなく製品を改善するために適用する方法論をよりよく理解することさえあるかもしれません.
次に、重要なステップは、すべての調査結果を実行可能なタスクと更新に変換して、ソフトウェアをさらに合理化することです。
ただし、アプリケーションをテストおよび監視する際には、留意すべき点がいくつかあります。 たとえば、ストレス テストは、コードの実行速度が遅いかどうかを判断します。 ただし、何かが遅く実行されているという事実は、更新を必要としません。 開発チームは、どの更新プログラムがパフォーマンスにとって重要であり、どの更新プログラムがリソースを最適に使用するために優先順位を下げることができるかをしっかりと理解する必要があります。
巨人たちの戦い
前述のように、このセクションでは、Microsoft がパフォーマンスの期待に応えられず、競合他社の成功に道を譲った可能性がある分野を探ります。 これには、Apple と Google の両方が関与するちょっとした話があります。
2021 年 9 月に MPP (Mail Privacy Protection) をリリースするまでに、Apple はすでにメール クライアントの市場シェアで Google を上回っていました。 当時、Apple のシェアは 59% 近く、Google は約 28% でしたが、Microsoft の Outlook は約 5% と大きく後れを取りました。
では、マイクロソフトが打ちのめされた理由は何でしょうか?
その答えを見つけるには、もう少し過去を振り返る必要があります。
Google は、ほぼ 20 年前の 4 月 1 日に Gmail を開始しました。 Microsoft がそれがエイプリルフールの冗談ではないことに気付くのに、それほど時間はかかりませんでした。 Windows の父は、約 10 年間、支配的であり続けるために懸命に努力しました。 しかし、Gmail が 2015 年に市場を席巻すると、ほとんどが Outlook の下降スパイラルでした。
しかし、なぜ？
その理由は、パフォーマンスに対する期待の失敗であると主張しても差し支えありません。 基本的に、Gmail はより高速で使いやすく、より合理化されたインターフェイスを提供していました。 より多くの機能とはるかに大きなストレージ (1GB – 当時の Outlook の 500 倍) と相まって、Gmail が勝ったことは驚くべきことではありません。
今日に目を向けると、Google が 10 年前の Microsoft と同じような窮地に立たされる可能性があることは明らかです。 さて、失敗した主要なパフォーマンスの期待は追跡です。 マーケティングであれトランザクションであれ、インバウンド電子メールの数を考えると、人々は電子メール イベントを非表示にしておくことを好みます。
確かに、開封率、地理位置情報、およびデバイスを追跡することがますます難しくなっているという事実は、マーケターを胸焼けさせます. しかし、統計は、それがまさにユーザーの期待であることを示しています。
Apple の電子メール開発チームは早い段階でこの傾向に気付き、電子メールのノイズを最小限に抑える実行可能なソリューションを最初に提供しました。 この種のパフォーマンスの期待、監視、および更新により、近い将来、Apple が電子メール クライアント スペースを支配する可能性があります。
良い製品を作る
ここまでで、製品開発プロセスにおける重要な課題についてしっかりと理解できたはずです。 強調するために、開発している製品の種類は実際には問題ではありません。
説明されている課題は、ニッチや、主に製品開発サイクルにとらわれません。 まだ構想段階にあるとしても、製品が安全で、信頼性が高く、スケーラブルであることは確かです。 そして、スタートアップ段階に達したら、製品アイデアのスクリーニングと検証にとどまらないでください。
最後に、製品開発プロセスには、あらゆる段階で多くの調査、分析、および実装計画が必要であることを覚えておくことが重要です。 幸いなことに、この記事では、堅実なロードマップと重点的に取り組むべき重要な領域について説明しました。
