Feedback Loop

久しぶりに朝から外に出る予定があり、早朝に起床するつもりだったが寝坊。待たせている人もいるのでめっちゃ焦るが新幹線の距離なのでどうしようもなく、そこから出せるだけのスピードで準備して出発。予定外の出来事が起きるとどうしても動揺してしまうが、焦ってバタバタするとさらに悪い結果をもたらすことが多い。こけて怪我するとか、逆方向の電車に乗ってしまうとか。ミス直後はできるだけニュートラルな心持ちで行動し、落ち着ける場所に来れたらゆっくり反省する。傷口を広げないための自分なりの行動指針だ。

こういう思考がどこに由来するかと考えてみると、エンジニアの事故対応の仕事が元になっている。事故とはシステムの障害や不具合のことで、特にサービスが使えなくなるなどユーザーに悪い影響を与えるものを事故とラベルづけするようなイメージ。ソフトウェアは複雑でバグをゼロにするのは難しく、事故ゼロを目指しつつも、事故が起きたときにスムーズに対応・復旧するスキルもまた必要になってくる。この事故対応をするなかでいろいろと学んだことがある。

まず、事故の原因の多くは単純なミスに起因する。ソースコードの書き間違いとか、仕様認識ミスとか、確認ミスとか。複雑で避け難いミスと比べ、単純なミスをすると自分の責任であることが明らかなので焦る。なんとか取り返そうと思う。影響ユーザー数が増える前に、誰かに気づかれる前に直したい、というモードに入る。ただここで焦って修正するとその修正が別の事故を引き起こす。ソフトウェアは複雑で、ある場所の修正がまったく別の箇所に影響する。焦って狭くなった視野では全体を見通せず、修正のはずの変更が傷口を広げていってしまう。

ベテランの先輩方をみると、事故などのアクシデントが起きたときほど落ち着いて行動する。内心はどうか分からないが笑みを浮かべている人もいる。どうしても焦ってしまう局面であることを理解し、そのうえで普段と同じ行動に努める。自分の視野が狭くなっていることを分かっていれば対応はできる。紙にパターンを書き出すとか、不具合の心当たりを人に話すとか、修正方針をレビューしてもらうとか。普段だったらしないような行動をしているな、と自分で感じたときは黄色信号。外からの視点を入れて平常心を取り戻す。自分のミスに人を巻き込むのは気が引けるが、被害が拡大するよりはマシなので人を頼って良い。自分のミスを素直に話せるか、緊急時に人に頼れるかはチームの雰囲気によるところも大きい。問題を引き起こした人が責任をとらされるチームだと自分のミスを隠したくなる。この辺りの雰囲気は普段のやり取りや以前の問題の扱われ方によって決まるので、オープンに話すのが良いという雰囲気を作っていきたいと思っている。

イージーミスをしてしまったとき、自分がこんなミスをするなんて...とショックを受け、なぜそれが起きたか分析したくなる。でも分析の前に、まずは事故の対応を優先した方が良い。ソフトウェア開発ではGitなどの仕組みによりひとつ前のバージョンに戻すことが簡単なので、まずシステムが動くことが確認されている状態まで戻し、ユーザーへの影響をなくしてから問題の分析にあたる。焦ってるとこの順番もよく間違えてしまう。

事故の対応が終わり、落ち着いたら問題の分析をする。なぜ事故が起きたのか？何があれば事前に食い止められたのか？いろんな角度から深掘りをする。連携のミス、作業者のスキル不足、確認の漏れなど根本的な原因が特定できる。今後同じような問題の発生を防ぐための仕組みを考えて構築する（再発防止策）。どんな事故であれ原因は単一ではなく、複数の要素に起因することが多い。すべての再発防止策を採用するのが正しいとも限らない。長期的にみるとフローが肥大化し、サービスの提供スピードは落ちていってしまう。ここはサービスの特性を見つつ、どれだけ時間がかかってもバグ0に近いものを選択するのか、それともイレギュラーなケースは許容して9割防げれば良いとするのか、判断が必要となる。

今回の寝坊を分析してみると、Xiaomi Smart Bandへの過信がある。Smart Bandではアラームの時間に腕時計が振動して起こしてくれるが、これが音でのアラームよりかなり起きやすい。アラームに気づかず寝過ごすことがなくなり、かなり気に入っている。海外旅行で出発が早朝になるときもこれで起きれた実績もある。そういう背景からアラームの設定をこれ単一にしてしまった。再発防止策として、今後早朝に起きる必要があるときはiPhoneのアラームと2台構えにしたいと思います（遅れてすみません）。