効果的なプロダクションサポートとエンジニアのマインドセット

2023-11-02

はじめに

プロダクションサポートは、ソフトウェアエンジニアリングの重要な側面です。 サービスをエンドユーザーやクライアントに提供する環境を「本番環境」と言いますが、開発が完了した後の運用こそがプロダクトにとっての文字通り「本番」であって、ソフトウェアエンジニアの仕事はプログラムを書いたら終わりではありません。

私自身、これまでのキャリアの中でソフトウェアエンジニア、クラウドのサポートエンジニア、CTO とエンジニアリングに複数の側面で関わってきましたが、どの立場であったとしてもサポート業務には関わっています。 また、クラウドのサポートを行っていたときも SRE やソフトウェアエンジニアと連携して問題解決を行っており、開発者のコミットは強かったです。

ソフトウェアエンジニアリング及びサポートのプロフェッショナルとして働いた経験から、私は「ものを作る人自身がサポートとしてプロダクトの運用に携わるのは当然の責任」という考えを持っています。
本記事では、プロダクションサポートの重要性とそれに対する効果的なアプローチについて触れつつ、プロダクションサポートに対する考え方を紹介します。

プロダクションサポートの定義とその重要性

プロダクションサポートは、ソフトウェア製品やシステムが公開され実際に運用されている環境でのサポート活動を指します。 これには、システムの監視とアラート、障害対応、定期的なメンテナンス、パフォーマンスの最適化、ユーザーサポートなどが含まれます。

  • システム監視: プロダクション環境でのシステムの稼働状態を常に監視し、異常がないか確認する
    • アラート: 監視により見つかった異常状態を通知する行為
  • 障害対応: システムに問題が発生した場合に迅速に対応しシステムを復旧する
  • メンテナンス: システムの定期的な更新やパッチ適用などのメンテナンス作業を行う
  • ユーザーサポート: エンドユーザーからの問い合わせやサポート要求に対応する

プロダクションサポートの重要性

プロダクションサポートはシステムを適切に動作させ稼働時間を最大化し、ユーザーが期待するサービスレベルを継続的に提供するために行います。
以下の観点よりプロダクションサポートは重要だと考えます。

  • システムの安定性とユーザー体験
    サポートを通じてシステムの安定性が維持し、ユーザーにとって使いやすいプロダクトを提供する

  • 信頼性の維持
    適切なサポートによりサービスの信頼性を向上させ、ユーザーからの信頼を獲得する

  • 事業成長への影響
    良質なサポートの提供によりサービスの継続利用や新規ユーザーの獲得、組織内のパフォーマンスの向上に繋がり事業の成長可能性を向上させる

サポートが不十分な場合、システムのパフォーマンスやユーザー体験に悪影響を及ぼす可能性があり、対外的に提供するサービスであればサービスの利用が継続されない可能性もあります。 そのため、システムの問題や障害に対して迅速に対応し、サービスの継続性を担保することが重要です。

サポートに向きあうためのマインドセット

プロダクションサポートを効果的に行うためには技術的スキルだけでなく、適切なマインドセットも必要です。
冒頭でも触れた通り、私自身ソフトウェアエンジニア、クラウドサポート、CTO のどの立場でもサポート業務には携わっており、サポートは生産活動を行う限り必ず関わるものだと考えています。

以下ではプロダクションサポートを効果的行うための適切なマインドセットを説明します。

  1. 問題解決へのアプローチ
  2. ストレス管理と対処法
  3. 継続的な学びと改善
  4. エンジニアとしての責任

1. 問題解決へのアプローチ


問題解決のスキルはエンジニアにとって必須です。これは具体的なテクニカルな問題だけでなく、時間管理や優先順位付けなどの課題にも適用されます。
問題発生時には、落ち着いて問題を分析し、解決策を考える必要があります。また、必要なステークホルダーへの連携や通知、マネジメントへの報告なども必要です。

どの問題が何 (誰) に影響を与え、その中でも特にリスクが高いもの (業績に関わる、セキュリティ問題等) が何かを考え、誰がいつまでに何をすべきかを明確にした上で、社内外への連絡を含めて考慮し、 問題解決に向けて優先順位を付けた行動が必要となります。

ソフトウェアエンジニアであれば自身がイニシアチブをリードする重要プロジェクトの重大局面とインシデントが重なることがあるかもしれませんし、複数のインシデントで首が回らない状況もあると思います。
このとき、チーム全体にとって重要なのは「問題のあるサービスを復旧し、サービス利用者への影響を抑えること」と意識し、ユーザーが満足出来るためにするべきことは何かという意識を持って行動することが大切です。

2. ストレス管理と対処法


サポート業務はプレッシャーが高くストレスが伴う場面もあります。 私自身、「この問題が解決しないと 2~3 桁億円規模の損失が生まれる」という場面や、「すぐに解決しないと会社が潰れる」という場面を自社・他社のサポートで見たことがありますが、対応している人へのプレッシャーはやはり大きいです。

以下にストレスやプレッシャーと向き合いつつ適切に対処する方法をいくつか挙げます。

優先順位の明確化

問題解決の部分と被りますが、優先順位の明確化はプレッシャーを軽減するためにも重要です。 プレッシャーは自身の責任感と、ステークホルダーからの早く解決して欲しいという期待によって生まれます。

当然ながら問題は念じるだけで解決するということはありませんので (クラウド環境においてはこの限りではないですが :) ) 、何から着手し、いつ頃までに何をするかを明確にすることで 自身の不安感が薄れ、ステークホルダーへの説明も行いやすくなるためのプレッシャーを軽減できます。

効果的なコミュニケーション

問題解決には、ステークホルダーとの効果的なコミュニケーションが必要です。 効果的なコミュニケーションとは必要な情報を適切なタイミングで適切な相手に伝えることです。
例えば問題の原因が特定できない場合には、その旨をステークホルダーに誠実に伝え、問題解決に向けてどのようなアクションを取るかを説明します。 また、問題解決の進捗状況を定期的に報告することで、ステークホルダーの不安感を軽減できます。

サービス利用者の立場になって考えるとわかりますが、問題が発生した場合には、問題の原因や解決までの見通しが知りたいと思うはずです。上司や自身の顧客への説明が必要な場面もあると思います。 このときに数時間待たされた上で「解決してません」と言われても納得できないのではないでしょうか。
予め状況を説明し期待値を管理することで、ステークホルダーの不安感を軽減でき、同時に自身へのプレッシャーを緩和できます。

助けを求める

システムの問題はサポート担当個人の問題ではなくチーム、組織、ひいては会社にとっても解決するべき問題です。 自身の力だけでは解決できないものは当然あるため、周りの人間に頼りましょう。
問題のある部分の開発に関わった人、特定ドメインの専門家、外部コミュニケーションのエキスパートなど、様々な観点で問題解決をサポートできる人がいるはずです。
例えば上記の「効果的なコミュニケーション」を行うためにどうしたら良いのかわからない場合はマネージャーに相談し助けを求めると良いでしょう。

自身がサポート担当のときに重大インシデントが起きたら不運を嘆き日頃の行いを悔いたくなる人もいるかもしれませんが、全てをひとりで背負うのではなく、必要に応じて周りの人を頼ると良いでしょう。 お願いする力も大切なスキルのひとつです。

適切な休息

適切な休息は、緊張感を和らげストレスを軽減するのに効果的です。 私の経験では以前重大インシデントが起きたときに、問題対応のためのカンファレンスコールが 3 日間繋がったまま対応が続くということがありました。 最近では銀行で振込ができないような大きなインシデントが起きていますが、おそらくこのような状況だったのではないかと思います。 私の経験談はグローバルチームで対応していたので日本時間が終われば他のリージョン(他国のオフィス)に引き継いでいましたし、銀行のような例はなかなか経験しない極端なものかもしれませんが、 1 日以上掛けて問題対応や解決のために尽力する状況は実際に起こり得ます。

私の経験上このような状況で PC に張り付いたまま過ごすと、緊張感が続き、睡眠不足になり、集中力が低下し、結果的に問題解決のパフォーマンスにも影響を与えます。
問題から逃げずに向き合うことは重要ですし、そういった姿勢には尊敬の念を抱きますが、エネルギーを持って問題解決を続けるためには適切な休息が必要です。 必要なタイミングで水分を取り、トイレに行き、食事をとり、睡眠をとることが必要ですし、マネジメントはそういったことが可能な体制作りが必要になります。

3. 継続的な学びと改善


プロダクションサポートを上手く行うには、継続的な学びと改善が必要です。 ここでの継続的な学びとは、

  1. 知識やスキルを習得すること
  2. 過去の経験から学びフィードバックサイクルを回すこと

の両方を指します。

知識やスキルの習得

私は個人的にトラブルシューティングの場においてこそエンジニアの実力の差が出ると考えています。 大きな主語で書きますが、現代の一般的なアプリケーションの開発のほとんどはフレームワーク (Web/ORM/API/etc.) が開発のためのレールを敷き、それにビジネスロジックをのせることで開発が進みます。 これはドキュメントを読み、フレームワークの提供する機能を使いこなせば、それなりのアプリケーションを開発できるということです。

一方で、システムの問題はどこで起きるかわかりません。 利用しているフレームワークやプログラミング言語の問題かもしれませんし、利用しているクラウドサービス、ハードウェアの CPU やメモリ、もしくはネットワークの問題の可能性もあります。 さらに、TLS や TCP のようなプロトコルの問題かもしれませんし、ユーザーの利用しているブラウザや PC、はたまた操作ミスかもしれません。

トラブルシューティングとはどこでどのような問題が起こり得るのかの仮説を複数立て、それを順番に検証し、仮説が正しいかどうかを確認する作業です。 基礎知識が足りないと仮説立案がそもそも出来ず、トラブルシューティングは満足に出来ません。

過去の経験から学びフィードバックサイクルを回す

もう一方の継続的な学びと改善のポイントは、過去の経験から学びフィードバックサイクルを回すこと、つまり問題が起きたポイントをプロダクトにフィードバックをし再発を防止するということです。

一度起きた問題は仕組みが許す限り何度も起きます。 これを防ぐためには問題が起きた原因を特定し、その原因を解決するための仕組みを作る必要があります。 具体的にはテストの追加やバグの修正、ドキュメンテーションの更新、モニタリングの追加などです。

もちろん費用対効果を考える必要はあり、頻発する問題や事業リスクの高いものを優先するなど、 問題の発生頻度、影響度、解決コストなどを考慮し仕組みを作るかどうかを判断する必要がありますが、 サポート業務の負荷を下げ他の部分への投資を促進するために、問題が再発しないためにどうするべきかと常に考えることが大切です。

4. エンジニアとしての責任


エンジニアとしての責任はプロダクションサポートの領域でも非常に重要です。

ソフトウェアエンジニアは自身でプロダクトの開発を行うので、安定性の高いアーキテクチャを選択したり効果的なテスト戦略を実施するなど、システムの安定性と品質を維持する役割を担っています。
プロダクションサポートの専任のエンジニアの場合でも、よく起きる問題や原因の傾向を分析し、開発チームへ課題を共有し改善を促すことが大切です。

また、エンジニアは継続的に新しい技術や方法を学び、スキルを向上させることも責任のひとつです。 先にも触れたように、継続的な学びは私たちが直面する様々な課題や問題に対して、より効果的に対応する力を与えてくれます。 さらに、新しい技術や方法を学びスキルを向上することは、サポートスキルを高めるだけでなく、問題の起きづらいシステムを構築することにも役立ちます。

エンジニアとしてのもう一つの重要な責任は、効果的なコミュニケーションです。 チーム内外のコミュニケーションは、プロダクトの成功に不可欠です。 問題発生時だけでなく、普段からの明確で効率的なコミュニケーションは、誤解を防ぎ、スムーズな問題解決に繋がります。
Belong ではメンバーのコミュニケーションを促すためにチーム軸と役割軸で出社の日程を考えたり、プロダクトマネージャーなど他部門のメンバーとのコミュニケーションを促すための機会も設けています。 これは、普段から自他のチームが何を行っているかを知ることで、問題が起きたときに適切な人に適切な情報を伝えることができ、問題解決に繋がるからという側面もあります。

さらに、私たちはプロフェッショナルとしての倫理規範と行動規範を守る責任も担っています。 問題から逃げず向き合い解決のために努力することはもちろん、誠実に正直ベースで情報を共有し問題解決のために協力し合う姿勢を保つことが大切です。 こういった姿勢がチーム内やステークホルダーからの信頼を得ることに繋がります。

これらの責任を自覚しプロダクションサポートに向き合うことは、エンジニアとしての成長及びプロダクトの成功にも繋がると思います。

おわりに

本記事ではプロダクションサポートとは何かに触れつつ、ソフトウェアエンジニアがプロダクションサポートを効果的に行うためのマインドセット、エンジニアとしての責任についての考えに触れました。 プロダクションサポートは、ソフトウェアエンジニアリングの重要な側面であり、サービスの運用も行う組織において開発者としては必ず関わり責任を持つべきものです。
プログラミングのように楽しいことばかりではないですが、ソフトウェアエンジニアリングのプロフェッショナルであれば、プロダクトのライフサイクルにおける継続的な支援と管理を行うことは避けては通れない道だと思います。

Belong ではこれらの考えに基づいて、SRE の考え方を取り入れた独自のプロダクションサポートの体制構築や、インシデント管理の仕組みを導入していますが、この紹介は別の機会に行いたいと思います。

プロダクションサポートまで意識したソフトウェアエンジニアリングのプロフェッショナルとして成長したい方や、エンジニアリングマネージャーとしてプロダクションサポートの体制構築に興味がある方は、 ぜひ Belong にご興味を持っていただければと思います。

https://entrancebook.belonginc.dev/