2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

株式会社オズビジョンのユッコ (@terra_yucco) です。
今日は珍しく仕事の話を書こうと思います。

トラブルについて

システムを運営していると、トラブルはつきものです。
そして、よほど軽微なものや、自然収束するもの以外は、だいたいにおいて対応が必要です。
たとえ、それがあなたのプログラムやインフラによるものではなく、オペレーションミスや外部起因だとしても。

トラブル対応、疲れますよね。
気が重いし、本来の仕事は遅れるし、しんどいですよね。

でも、私はここで声を大にして言いたい。

「トラブル対応は成長のチャンス」

なぜトラブル対応を率先してやるべきなのか?

考え方はそれぞれありますし、もちろんトラブル対応だけが成長の手段ではありません。
しかし状況が許すのであれば、以下の理由により、私はトラブル対応は率先して取るべきだと考えています。
(事業会社ならではの考え方なところもあると思います)

  • トラブルの収束が速くなるかも
  • システムやサービスに詳しくなれる
  • トラブルがビジネスに及ぼす影響を学ぶことができる
  • 他部署の温度感や理解度を知ることができる
  • 関係各位から感謝される

以下にそれぞれについて書いていきます。

トラブルの収束が速くなるかも

もし対応が必要なトラブルの場合。
誰も手を挙げなければ、マネージャなりリーダなりがチームの状況を確認し、作業を空けられるメンバをアサインして調査・対応が開始されると思います。ただし、この場合、各チームの状況を横断的に見た上で、調整をして決定するというフローを踏む必要があります。
チームやリーダの合意を得る必要がありますが、ここで誰かが手を挙げれば、その時間を大幅に短縮できる可能性があります。収束を速くできれば、一般的には影響範囲も小さくなる傾向にあります。

※もちろんスキル・知識及び業務状況により「他の人がやったほうが全体最適である」ということは往々にしてあります。そういう理由で最適化するのはまた別の話。

システムやサービスに詳しくなれる

トラブルは花形機能や、頻繁に改修されている機能に対して発生するとは限りません。むしろ、滅多に使われない機能に発生したケースの方が、調査や対応が大変な場合が多いと感じます。

もちろん自分が担当している機能以外を含め、サービスの全体像を熟知できていれば理想ですが、日々の業務で関係ない箇所のコードリーディングをする時間なんてものはまあそうそうありません。そういう機能にトラブルが発生したときほど、知るチャンスだと思います。
(とはいえ、トラブルなく動いてくれるのが一番なのですが)

トラブルがビジネスに及ぼす影響を学ぶことができる

例えばオズビジョンのメインプロダクト「ハピタス」は BtoBtoC のモデルであるため、トラブルが発生した場合の影響対象は大きく分けて 3 つあります。

  • ハピタスに広告を掲載しているクライアント
  • ハピタスを利用しているユーザ
  • 社内運営者

一例として「ユーザの登録は通常通り行えているけれど、どこ経路で登録したかが保存されない」場合、エンジニアとしてはデータ欠損が気になります。また、そのデータを使う人、即ち社内で Web 出稿の効果測定を担当しているチームは数値が取れなくて困りますが、クライアントやユーザは特に困りません。

ただ、例えば「そのときの登録経路で特別なキャンペーンを実施していて、登録したユーザに何らかの特典を付けていた」場合は、その特典の内容に応じてクライアントやユーザにも影響が出てきます。
もちろん、キャンペーンがコードに組み込まれていればエンジニアでも調査でたどり着くことはできます。ですが、運用で対応しているキャンペーンの場合など、ビジネスサイドとトラブルという共通の敵に立ち向かうことで、新たな知見を得ることができます。

処理は作るけれども、その先のデータが何に使われているかわからないというケースはよくあると思いますが、トラブル対応に関わることでその先に触れることができ、視座を上げる・視野を広げる役に立つことは間違いありません。

他部署の温度感や理解度を知ることができる

これは書いてある通りで、上の項目とも近いのですが。
エンジニア的には大したこと無い内容で対応もすぐできるけど、ビジネスへの影響としては由々しき事態だった、なんていうことは珍しくありません。
また逆に、エンジニア的にはすぐに重大な影響が出ているとわかる内容でも、表に出ている事象だけではその影響が他部署にはピンと来ないことがあります。

こういった温度感や理解度の違いを知ることができますし、理解度の差を埋めるために説明をする機会が多いと、要約力や説明力も身について良いこと尽くめだと思っています。

関係各位から感謝される

これはまあ多くを語るまでもないと思います。自分でもやりきったら嬉しいと思います。

…自己満足や承認欲求の塊と言うなかれ!かのマズローさんもおっしゃるように、ここが満たされて初めてさらに上の自己実現を目指すフェーズへ行けるのです。

Conclusion

トラブルは発生してほしくありませんし、発生時の対応は大変ですが、その機会に得られるものもたくさんあると思います。
もし、直面した場合はぜひ手を挙げてみてほしい、そんな Qiita Post でした。

なお、オズビジョンのメンバーはトラブルに対して温度感の高い人が多く、事象の共有から体制構築・収束まではどんどん改善されてきています。機会があれば今後、実際どのようにトラブルに対応しているのか、ハピタス事業部の例を共有する Post を書きたいと思います。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?