エンジニアが向き合うべき障害

このポエムでは、IT屋なら避けては通れない障害について話してみたいと思います。

システム障害と体験的障害

システムの安定性を表す指標としてSLAが業界でよく使われています。これは、障害時間を稼働時間で割ったパーセンテージでして、99.9％以上正常稼働するならスリーナインが保証されているシステム、といった感じで使います。

これはこれで便利でわかりやすい指標です。しかし、個人的には、サービス運営においてはこういったシステム障害に関する紋切り型な指標だけを拠り所にする運用は避けたほうが無難と考えています。

たとえば、あなたはCtoCのSNS系サービスを運用しているとします。このとき、障害をもっと大きく捉えると....

・コンテンツを投稿して数時間たっても何も反応がない

・おすすめコンテンツ紹介メールが送られてきたので開封してみたが、なにも刺さるコンテンツがなかった

・読み込みが遅くてストレスが貯まり、積極的に使いたくないと感じるようになった

・不快な記事やスパム、暴力的な表現があるコンテンツが目に止まったり通知されてきた

・フォローしたい人や情報が見つからない 自分の関心と外れている...

・アップデートのペースが遅く、利用し続けようと思うような新しい機能やしかけが提供されない

こういった体験的障害が存在し、それが全体的なUXに大きな悪影響を及ぼしていると考えられると思います。

極端な話、15分のシステム障害を全力で防ぐより、体験的障害のいくつかを治すプライオリティを高くしたほうが、トータルに提供する経験を鑑みて妥当なケースもありえると思います（技術屋的には受け入れ難いスタンスなのは理解できますが...）

システム障害と体験的障害のどちらをどのくらい重視するかは、サービスのドメインやフェーズに依存するので一概に正解はありませんが、障害をサービスの提供に問題があり利用者に何らかの不便を強いている状態と考えると、システムダウンだけが障害じゃないよね、と思うわけです。

推測するな 計測せよ

なので、ソフトウェアエンジニアリングの金言「推測するな、計測せよ」に従い、体験的障害に関わる指標を定量化してシステムモニタリングと同様にトラックしてみるのをおすすめします。redashやBIツールと組み合わせてslackなどに定時で自動ポストするのが最初は手軽でいいと思います。

上記の SNS系サービスなら例えばこんな感じでしょうか

・投稿したコンテンツに誰かの反応がない割合 => CGMやSNSで投稿に何もアクションがないのは離脱ポイントになるため

・コンテンツを作り始めたが途中で諦めた人の割合 => 作成画面のUIがイマイチ、参考となる作品がない、場の雰囲気がよくわからないなどの理由で投稿まで至らないとペインがたまり、離脱ポイントになるため

・新入り比率 => 常連ばかり優遇されると場が停滞し新規会員が入ってきにくい雰囲気になるため

・不快コンテンツ報告の数やスパム報告の数 => 雰囲気がわるくなり離脱ポイントになるため

あくまで一例ですがこんなかんじです

まとめ

障害というエンジニア的にビクッとくるワードを使っている意図として、エンジニアが一般的に思うよりこういった体験的・UX的なトラブルは「かなりやべえ」事態であり、サービスの存続にかかわる可能性が高いので、継続的にモニタするとよろしいかと！というポエムでありました。

※ 以下のツイートの背景としてこのnoteで述べたような考えがございます

良記事をスタッフ総出でピックアップすべく頑張っています。ざっくりいうと、良記事を見逃すのは障害と同じ扱いです。 https://t.co/OsFg39ldMk

— KON Yuichi (@konpyu) October 12, 2018