初めましての方は初めまして。お久しぶりの方はお久しぶりです。虎の穴のY.Mです。
このブログが始まった頃に、よく記事を書いていました。
月日は流れて、現在はEC開発のリーダーをやっております。
今回は技術的な内容というよりは、開発プロセスの内容を少し書きます。
書こうと思ったワケ
弊社のブログを眺めていたところ、これまで虎の穴の開発文化を紹介したことがなかったなと感じました。
チームでの開発をする上では、技術力はもちろん大事ですが、そのチームの開発文化が品質に大きく影響してきます。
ブログを読んでいただいている皆さんに、少しでも「こんな仕事のやり方をしてるよ」というのを知ってもらうべく、久しぶりに筆をとりました。
今回はそのとっかかりとして、一番エンジニアが頭と心を痛めるであろう『障害の事後対応』について書きます。
せっかくオタクエンジニアとして書くので、ちょっとゲーム仕立てにしてみます。
「サービス継続」というゲーム
みなさんゲームは好きでしょうか。私は大好きです。
難しいステージのクリアを目指すために試行錯誤している時は最高に楽しいですし、それによってクリアができたら脳汁が溢れてしまうほどです。
ゲームで失敗した時、
- なんでダメだったか
- 何をすればダメなポイントを無くしてクリアできるか
というのは、ゲーマーみんな自然と考えているんじゃないかと思います。
今回のゲームのルールは簡単です。
- 24時間365日、オタクの方に喜んでもらえるサービスをフル稼働させる
- オタクの方に喜んでもらえるよう、機能を定期的に追加していく
- 複数人協力型ゲーム。メンバは増えたりもする
そしてこのゲームにはオジャマが登場します。それが障害です。 この障害を倒したり、避けたりしながら、効率よくゲームを進めましょう！
障害が発生した！
早速出てきました。敵です。
これがなかなか厄介な敵で、一度倒しても、何もしなければまたすぐに登場してきます。
そして登場するたびに、我々が守っているサービスを止めていきます。効率厨のゲーマーとしては大問題です。
まずは敵の情報を取りまとめる
障害を倒し終わった後、晴れやかな気持ちで秋葉原の街に飲みに繰り出す。。。をしていると、すぐに同じ障害がやってきます。
まずは障害に関する情報を取りまとめます。
EC開発チームでは、まず以下のフォーマットで起きた内容をまとめ、wikiに記載しています。
# タイトル（障害の内容を簡潔に書く） ## 発生日時 - いつ起きたか ## 検知者・検知方法 - 誰が気づいたか - 何によって気づいたか ## 事象・影響範囲 - 何が起きたか - 誰に影響が出たか ※表面的な事象。非エンジニアがみて、何がおきたかわかるレベルで記載する ## 直接原因 - 何が直接の原因となったか ## 暫定対処内容 - 影響を広げないためにやったこと - 一時的に乗り越えるためにやったこと ## 根本対処内容 - 完全な復旧のためにやったこと
Point 「事象」と「直接原因」を分けて書く
エンジニアにありがちなのは、まず「直接原因から報告しようとしてしまう」姿です。
「◯◯APIのレスポンスとして、想定していない××が返されました。それによって△△の機能が一時的に。。」などから説明されても、頭に入ってきません。
まずは敵の見た目を整理して、次に万が一遭遇した時に「あの敵だ！あいつはこんな攻撃をする！」とわかるようにしておきます。そのために、事象と影響範囲から記載します。
そのあとに「あいつはこうやると倒せる！」という情報を書きましょう。それが対処内容です。
もう遭遇しないようにしよう 再発防止を考える
この厄介な敵ですが、出現するトリガーがあるようです。
そしてそのトリガーを引かないようにすることで、なんとこの敵は二度と現れません！
EC開発チームでは、以下のフォーマットで整理して、wikiに追記します。
## 作りこみ（バグを作りこんでしまった） ### 根本原因 - 直接の原因が発生した理由はなぜか ### 再発防止策 - 何をしたら作り込まなくなるか ## 流出（バグをテストで見つけ損ねた） ### 根本原因 - なぜテストで見つけられなかったか ### 再発防止策 - 何をしたら見つかるか
Point 目的をはき違えない
目的はあくまで「次に発生させないこと」。これだけを意識します。
「wikiを書くこと」は目的ではありませんし、まして「偉い人を無理やり納得させること」も目的ではありません。
本来の目的以外のことには時間を使わないようにしています。
根本原因 どうやって考える？
さて、敵が出現してしまったトリガーはどこでしょう。効率よくゲームを進めるために、押さえておきましょう。
この手のものを考える時に一番有名なのは「なぜなぜ分析」でしょう。
そして開発の現場で度々「意味がある」「システム開発においては意味がない」と色々な意見が上がります。
個人の感想だけで書くならば、「なぜなぜ分析はシステム開発でも意味がある」です。
ただし、「なぜなぜ分析のフォーマットを埋めるために頑張ることは意味がない」です。
なのでEC開発チームでは「なぜ」を考えることはしますが、その「なぜ」を考える回数は決めません。これ以上「なぜ」が出てこないなと言える状態までになったら、そこで打ち切ります。また、考えても意味がないな、と思われる「うっかりミス」なんかは考えず、そのまま次の再発防止策検討へ移ります。
「なぜなぜ分析」の手法については、ここでは割愛いたします。調べると文献がたくさん出てきますので、もしご存知でない方は調べてみてください。
再発防止策 何をする？
敵が出てくるトリガーがわかったら、今度はそれを引かないようにしましょう。
ここを間違えると、また敵が現れて、ゲームの効率がどんどん落ちていきます。複数人協力型ゲームですので、効率が悪いと、パーティーから抜けてしまう人も出てきてしまうかもしれません。
理想的な再発防止
理想的な再発防止策としては、以下のようなものがあります。
- 原因となる問題を意識しなくてよくなる（リファクタして該当の問題が起きないような作りにしてしまう） -> やった！敵が出なくなりました
- 自動化・自動検知化 -> やった！敵のいる位置を自動で避けられました
- 問題が起きることを前提のシステムにする -> やった！敵が出ても弱かったので無視して進めました
どれを選んでも、楽しく効率よくゲームを進められそうですね。
虎の穴ラボの再発防止策としては、極力上記の方向に落とし込みます。
自動化などある程度タスクになるものは、バックログ化して随時実装していきます。
選んではいけない、なんちゃって再発防止
以下のようなものはよくない例です。
- チェックリストに書く -> 見ません。
- ダブルチェックをする -> 見逃します。
- 注意する -> 絶対に忘れます。
これらを選ぶと、敵はまた以前の敵のまま現れて、手痛い攻撃をしてきます。ゲームオーバーが見えてきます。
ゲームをしていく中で
- 敵を自動的に倒してくれるアイテム
- 『敵を頑張って探してね』『敵に気をつけてね』と書いてある紙
この二つがあったら、どっちを選ぶでしょう。
前者しかありえませんね。
みんなで経験値をゲット！レベルアップ
このゲーム、ここまでの内容を実施すれば、実施した人に経験値が入ってレベルアップします。
さらにこれをみんなと共有すれば、全員に同じ経験値が行き渡って、全員がレベルアップします。
EC開発チームでは週に1回、30分の情報共有定例を設けています。
- 開発している内容自体の共有
- 開発していて気をつけたほうがいいと感じたことの共有
- 障害の報告（ここまでのフォーマットを共有します）
これによって、チーム全員がレベルアップするよう努めています。
ちなみに、私はRPGにおいて、パーティー全員のレベルが同時に上がっていかないと許せない人種です。
まとめ
今回はゲームに例えながら、虎の穴ラボでやっていることを紹介させていただきました。
重要なポイントは以下の通りです。
- 障害の情報はすぐに整理して取りまとめる
- 再発防止策は、自動化や発生しなくなる方法を選ぶ
- チーム全体で共有して、全員でレベルアップ
当たり前といえば当たり前ですが、ゲームっぽく書いてみることで、その重要性が伝わったのではないかと考えています。
虎の穴ラボでは、開発のプロセスというものも重要視しています。また決まりきったルールは開発効率を落とす枷にしかならないと考えており、常にブラッシュアップを続けてより良い手法を探しています。
今後も、虎の穴ラボの開発プロセスに関する記事をどこかで書かせていただきます。以下の内容を書いていきたいですね。
- 虎の穴ラボにおけるスクラム開発（現在スクラムでのチーム運営を実施中です）
- 振り返りの手法
- 開発機能の決定までの流れ
P.S
残念ながら、COVID-19の感染被害の防止の為中止となった技術書典ですが、虎の穴ラボでは用意していた同人誌を技術書典 応援祭にて0円にて頒布しております。 ぜひ御覧ください。 techbookfest.org
加えて今回は、有償版の同人誌も作成しております。Go、Kotlin、Rustに関連する内容をまとめた、内容の濃い薄い本になります。 こちらも、ぜひ入手してお楽しみください。 techbookfest.org
虎の穴ラボでの開発に少しでも興味を持っていただけた方は、採用説明会やカジュアル面談という場でもっと深くお話しすることもできます。ぜひお気軽に申し込みいただければ幸いです。 虎の穴ラボのエンジニアが、開発プロセスの内容であったり、「今季何見ました？」といったオタクトークであったり、何でもお応えします。
