2015年10月入社でコアエンジンチームの@kompiroと申します。普段は下記の３つの業務に従事しています。
- お客様が自社の情報を把握するためのデータアグリゲーション機能の開発
- マイクロサービスに切り出したデータアグリゲーション機能をEKSに移行
- チーム横断で開発者のみんなが開発しやすい環境の構築
そんな私ですが、最近しくじり開拓者のつどいという社内イベントを開催しています。これは障害対応の一環として始めたイベントです。今日はしくじり開拓者のつどいというイベントをみなさまに紹介するとともに、背景となる障害に対する考え方と障害対応の流れを解説します！
freeeの開発文化と障害対応
こちら弊社の紹介スライドからの引用です。
freeeのエンジニアチームが大切にする開発文化が言語化されたものが
- 失敗して攻めよう
- 何でもやれる、何でもやる
- 必殺技
- カッとしてシュッとやる
- 世話を焼いていくスタイル
です。この中でも「失敗して攻めよう」は私が入社した6年前から言語化されています。その本文は「学びのある失敗をして最速で成長しよう。学びのある失敗とはチームやプロダクトの成長につながる失敗。学びのある失敗をしていないのは挑戦が足りない。」です。
そのため、障害を起こしたからといって怒られたりすることはありません。しかし、お客様に迷惑をかけているので、できる限り迅速な対応が求められます。
障害発生に作成する障害報とエンジニアのうごき
障害が発生したときの流れを簡単にご説明します。まず、障害を見つけたら「障害対応するぞ」とSlackにメッセージを入れます。すると、障害報を作成するためのGoogleFormへのリンクが表示されます。
実際のフォームはこういう形になっています。
このフォームに必要事項を入力すると、
- 障害報GoogleDocを作成
- 障害報のリンクと障害対応を行っているGoogle meetのURLが書かれたアラートを飛ばす
アラートの内容はこんな感じです。
障害報のアラートを見たエンジニアは、障害の内容をみて必要に応じて障害対応に参加します。
一定以上の規模の障害の場合、速やかにユーザーへのアナウンスが必要です。サービスのstatus更新やSNSへの発信、社内の他のエンジニアだけでなく、実際にユーザーからお問い合わせがくるカスタマーサポートチームやセールスチームへの情報共有などが必要です。しかし、障害が発生したチームは原因調査及び復旧を可及的速やかに行うことに集中すべきです。障害発生してるチームが障害対応を速やかに行えるよう、支援するチームがあります。
我々はこの障害対応支援チームのことを「鬼殺隊」と呼んでいます。鬼殺隊の由来はご存じ鬼滅の刃です。障害を鬼に見立てたのと、ちょうど鬼滅の刃のアニメ1期がTVで放映されていたころにこのチームが発足したので名づけられました。アニメ2期楽しみですね。
障害解決と障害からの学びを支援する鬼殺隊
鬼殺隊は速やかに障害に対応することを支援する、数名の有志のエンジニアチームです。曜日ごとに担当が決まっており、一定以上の規模の障害があるとその障害対応に必ず参加することになっています。障害発生しているチームの手が回っていないところを支援するように動きます。
例えば、鬼殺隊のメンバーは障害対応中下記のような活動を行います。
- 他のチームに状況共有するために定期的に障害の状況を３行程度にまとめてアナウンスする
- 障害報に影響ユーザー数が書かれていないなど、記載漏れがある場合は障害発生チームに伝える
- 障害対応後に義務付けられている障害のふりかえりが実施されていない場合は障害発生チームにアナウンスする
鬼殺隊のメンバーは、役割上、普段触らないサービスの障害対応に入ることが多く、鬼殺隊活動は、他のチームでどう障害対応をしているのかを学ぶ場になっています。毎週鬼殺隊のメンバーは集まって障害対応自体をふりかえったり、今後の障害対応を改善するにはどうしたらいいかを話し合っています。しくじり開拓者のつどいはこの鬼殺隊の障害対応の改善の話し合いで生まれました。（注: 鬼殺隊は任期があるため、現在は私は鬼殺隊のメンバーではありません。）
「失敗して攻めよう」と言われても、好んで失敗したい人はいない
障害対応の流れをまとめてみました。障害対応にかかわる人は少なくない人が動くこともあり、好き好んで発生させたい人は皆無です。どうすれば障害の発生を少なくしたり、速く対応できるようになるのでしょうか？
一番良いことは障害に学び、繰り返さないことです。障害から学ぶ場があれば、
- 最近他のチームで起きた障害とその傾向を把握できる場を設けたい。（例: マイクロサービス化が進んだため、ネットワークでのトラブルが増えている）そうすることで、自チームで同じ障害を起こさないようにレビューで指摘できる人が増えるはず。
- 経験豊富な中途入社の方でも入社が最近の場合、freeeで過去、どんな障害が起きたのか、ご存じないはずです。どういったポイントが障害になりやすいか、学ぶ機会を設けたい。（例: freee特有のSPOFになりやすいポイントがどこか）そうすることで前職の経験を活かしてfreeeのサービスを改善することもできるはず。 障害対応に参加したメンバーにとって、障害対応自体が学ぶ場になっています。学んだ内容を言語化し、共有する場を設けたい。
- そうすることで学びを促進して障害自体を減らしたり、同様の障害が起きた時に過去の学びを想起し、速やかに対応できる人が増えるはず。言い換えると、「世話を焼いていくスタイル」を実践できる人を増やしたい。
こういう狙いで始めたのがしくじり開拓者のつどいです。
しくじり開拓者のつどいとは？
しくじり開拓者のつどいは障害からの学びを共有する場です。ランチタイムにやることもあれば、夜にお酒を飲みながらやることもあります。（発表者もお酒を飲みながらです）参加者はラジオ感覚で気軽に聞けるよう、笑いを大事にしています。参加感を大事にするために、できればカメラONを推奨していますし、障害からの学びを深めるため、何かわからないこと、気になることがあればマイクをONにして質問したり、提案したりできます。参加者も障害から少しでも学びを深めたいので、freeeの社内にいる人であればどなたでも参加できます。専用のSlackチャンネルでにぎやかすことも推奨してますし、Meetのチャットも開放しています。障害から真摯に学ぶ場。それがしくじり開拓者のつどいです。
しくじり開拓者のつどいに至るしくじり
実はfreeeでは以前「失敗.js」と呼ばれる開発における失敗談共有のイベントがありました。このイベントは下記の構造を持っていました。
- 失敗.jsが開催される前月に一定以上の障害を起こした人が発表することになっていた
- 発表者と聴講者に分かれていた
障害を起こした人が発表していたことから、どうしても後悔の気持ちが前に出てきて重い雰囲気になりがちでした。また、聴講者から質問しようにも責めている雰囲気になりがちでした。「失敗.js」では誰も笑う人のいない、お通夜や裁判のような重苦しい場になっていたのです。これでは学びの場にすることができず、続けられませんでした。 とはいえ、失敗から学ぶことは大事です。何かいいものはないかと探してみると、TV番組に「しくじり先生」があるじゃないですか。障害自体を「しくじり」と表現し、TVのように笑いのある場にすればよりよい学びの場にできないか、という仮説の基、4月に私が発表者として障害からの学びを共有する「しくじり先生」を開催しました。
やってみた私の感想ですが、一方的に私が学びを共有する場になってしまいました。参加者からの質問だったり、提案だったり、学びの共有が難しく感じました。自分のMC力のなさが大きな要因の一つですが、「先生」という名前だと「先生と生徒」という構造になってしまうのだろうと気づきました。
より深い学びの場とするために、いわゆる「問題vs私たち」の構造にしたい。
みんなが障害という問題に向き合い、解決策についてワイワイ話す場にする。そうすることで障害をおこさないこと、及び障害が起きても最速で復旧することにフォーカスできる、強いチームを目指しています。
そうなるように改名したのが「しくじり開拓者のつどい」です。「開拓者」の由来は、新大陸上陸後の開拓から来ています。freeeでは海モチーフの名前を付けることが多く、新しいサービスを立ち上げること（市場を見つけること）を「新しい大陸を見つける」と表現したりします。我々エンジニアは新大陸を開発する開拓者、というわけです。 freeeの開発文化の一つ「失敗して攻めよう」を大事にすれば大事にするほど、freeeのエンジニアはしくじることが増えていくはずです。個人的にゆくゆくは「しくじり開拓者のつどい」ではなく、「開拓者のつどい」という名前になり、よりカジュアルに各々のしくじりを話し合い、しくじりからの学びを深める場にしていけたら、と思っています。
こういったfreeeの開発文化に興味を持っていただいた方は、よかったらカジュアル面談に話を聞きに来てください。一緒に成長していきましょう。
