※酔っ払った勢いで書いてるからご容赦いただきたい
今日、というかついさっき、自社でやってるサービスで障害が出た。原因は調べてるところなので確かなことはまだ言えないが、おそらく一時的にアクセスが集中して負荷が高まったことだろうと思ってる。で、その際のやりとりを見ていたんだけど、同じ会社の社員であってもお互いの共通言語でしゃべらないと欲しい情報が出てこない/伝えたと思っているのに伝わってないという状況が生まれていたので忘備録として残しておく。
起きたこと
アラートが飛んできて、だいたいチームのコアメンバーはslack上でオンラインになったときのことだ。サービスはアクセスしてもローディングから動かず、画面が表示されない。さて困った。その際にプロダクトの責任者が「いまつながらないからってリロードされても負荷が高まるだけだろうからメンテ状態に切り替えたい」という話しをした。そして、下記のような会話があった。
プロダクト責任者「お知らせを出したいから今の影響範囲を教えて欲しい」 エンジニア責任者「影響範囲としてはサーバとの通信が走る箇所はみんあ死んでる状況だと思う。詳細は別途。」 プロダクト責任者「具体的にはどういう状況になってるか教えてもらえる？」 エンジニア責任者「AのAPIが多分詰まってる原因になってて、併せてBのAPIが死んでるくさい」
濁してるのでかなりざっくりとした(かつ、ふわっとした)感じになってしまったがだいたいこんな感じの会話だった。僕はこの時「あ、話しかみあってないな」と思い、下記のように質問して会話を続けた。
ときD「お知らせに『いまユーザから見てどういう状態になっているか』を書いときたいと思うんだよね」 ときD「たとえば、CしたらDができないとかって情報教えてもらえるかな」 エンジニア責任者「通信走ると駄目っぽいんでログイン時点で蹴られますね」 エンジニア責任者「通信が走らない状態、画面眺めてるだけだったり、Eのページとかを見てるだけなら普通に動いてるはずです」 プロダクト責任者「了解、お知らせ出しておきます、すまんけど対応よろしく！」 エンジニア責任者「うす、そちらも対応ありがとう。進捗随時共有します」
プロダクト責任者からすればお知らせを出す=ユーザに対しての説明を行いたい、という気持ちがあり、エンジニア責任者からすれば「具体的に何がエラーになっているか」を正確に伝えたい、という気持ちがあったのだ。
共通言語
現にこういうケースに遭遇した時、どちらがいい悪いってのはないと思ってる。見方としてはエンジニア責任者がさっと答えを出せなかった、と見えそうだが、文脈がーとか普通に考えればーとかあっても僕としてはどっちとも取れる質問をプロダクト責任者がしてたと思う。そしてそれは当然だし、エンジニア責任者とプロダクト責任者どっちがいい悪いの話じゃないと思っているのだ。その理由がタイトルにあるような「『自分の言語』じゃなくて『チームの言語』でしゃべらないと伝わらない」というところ。両者はお互いの言語でお互いの問い/解を出している。でも、もっと早い解決策はある。ではなにがそれを阻害したか。それは「お互いが自分の言語ででしか話をしなかった」からだと思っているからだ。
自分の「常識」や「文脈」ってのはそんなに強固なものじゃない
これを理解*1している人は少ない。経験則で申し訳ないが。そういうものなのだ。上で挙げた例なんて典型的で、お互いのバックグラウンドによって左右されてしまうことの方が多い。ではこういったことを起こさないためになにをすればいいかと言えば、チーム内で共通言語を作るor障害のレベルに置いて共有するべき情報を明確に定義することにほかならない。だって考えてみれば当然だろう。ユーザがサービスにアクセスできない状況にあったとき。「まずなにをするか」が共有できてないからプロダクト責任者は自分の考える「影響範囲」を尋ねるし、エンジニア責任者は「聞かれた影響範囲」を答える。ただただ、「こういうった状況であれば」「誰に対してどういう情報を出すべきか」の認識がずれているのだ*2。齟齬が生まれるのは些細なことから始まる。ではどうやったら僕らは正しい情報を「情報が欲しい」と言っているやつに届けられるのか。
共通認識
僕がこの事態に遭遇して、最初にやったのは「障害レベルに応じた、『どんな情報を』『だれに渡すのか』」を定義することだった。目的さえわかっていればうちの社員は強い。その目的が共有できてないところが齟齬の発端だったのだ。「普通に見ればわかる」「文脈を追えばわかる」、様々なコメントが来そうだが、少なくとも僕は、自分がエンジニアであったら「具体的なAPIがどう詰まっていたか」を答えると思う。なぜなら「ユーザの」という共通認識がない状態で具体的な起きている状況を聞かれているからだ。普段の会話ではある程度意味を明確にするために言葉を変えるなりなんなりするのに、気心知れてているやつにはおざなりになったりする。
不具合レベルの制定
僕はプロダクト責任者の言い回しが悪かったとは思わない。だって優先順位がなかったんだから。そして同じくエンジニア責任者のレスポンスも、「まったく悪くなかった」と断言できる。条件やソート基準が示されてなかったからだ。だから僕は自社で下記のルールを追加した。
- 各プロジェクトは「緊急時の確認手順」を制定すること - 各プロジェクトごとに「なにが起きたら駄目か」を明言すること - 各プロジェクトごとに「それぞれの不具合に『不具合レベル』を決めること」 - 『不具合レベル』に応じて誰に何の情報を定時するか決めること
今回のケースではプロダクト責任者はどこまで影響が大きいのかという気持ちで『なにが起きたら駄目か』を明言」していなかった。エンジニア責任者は『不具合レベル』がわからんので聞かれたことに対して愚直/誠実に返答した。それぞれ、最初に定義すれば解決していたことについてお互いの会話がなりたっていなかったのだ。これはどう考えてもカロリーの無駄遣いで、今後こんな状況を作っては経営者としてよろしくないなと思えたことなのでまとめておいた。
しかしながら
こういった齟齬を減らして運用できる人ってのは本当に少ない。その前提で、なにか困ったことがある優秀な方はぜひ連絡をください。
