SMARTCAMP Engineer Blog

スマートキャンプ株式会社(SMARTCAMP Co., Ltd.)のエンジニアブログです。業務で取り入れた新しい技術や試行錯誤を知見として共有していきます。

「仮説検証サイクル」を用いて新卒1年目エンジニアの運用ルール作成にアドバイスしてみた

はじめに

スマートキャンプでPMをしている郷田です。

唐突ですが、みなさんは障害対応の経験はありますか?

どのようなシステムを運用していても、発生したエラーをキャッチし対応を行うことはよくあることかと思います。

弊社では新卒1年目のエンジニアが担当プロダクトにおけるエラー対応を運用ルール化する旗振りを行っていたのですが、ルールを決定するための進め方に課題を感じた部分がありました。

そこで、自分が「仮説検証」の考え方を取り入れてアドバイスする機会があったので、この記事では実際の運用ルール決定プロセスを題材にそのアドバイス内容などを紹介したいと思います。

※ 前述の新卒1年目のエンジニアには今回記事化するにあたって了承をとっています。ありがとうございます!

作られた運用ルール

弊社プロダクトでは、システムのエラー発生時に、その内容が1つのslackチャンネルにリアルタイムで通知されます。

過去のエンジニアが少なかった時代には、発生したシステムエラーの対応をそのエラーの内容にあわせて得意な人が自主的に行っていました。

ですが、現在エンジニアが9人(4チーム)で1つのプロダクト開発を行うようになったところ、以下の問題が起きるようになりました。

  • システムエラーへの反応や対処が有志で行われるため、誰も対応せず見逃してしまうエラーがあった。
  • 複数のサブチームに分かれて開発しているため、他チームの担当内容は重要度が判断できなかった(ので巻き取ることができなかった)。

そこで、この問題を解決するために当初作られたルールは、いくつかアプローチ案があったうえで、採用案を決めたようでした。

以下がそのアプローチ案と採用案です。

## アプローチ案
1. 反応をする担当を1人決める
    - メリット:分担が明確
    - デメリット:担当の負担が膨大
2. 反応をする担当を複数人決める
    - メリット:担当の負担がそこまで大きくない
    - デメリット:誰も反応しない可能性がある
3. 反応をする担当を日替わりで1人決める
    - メリット:担当の負担が小さい、分担が明確
    - デメリット:担当が今日自分である事に気付かない可能性がある

## エラー対応ルール
- エラーの対応者は日替わりで1人とする(正社員のみ、祝日含む)
- Slack botで担当者を告知 & 担当者にメンションが飛ぶ

プロセスの課題

このルールは起案した新卒1年目のエンジニア1人によって作られ、他のチームメンバーにも確認して同意が取れたと判断したため、ルールの決定がされていました。

しかし、決定後にチームメンバー複数人から以下のようなコメントがありました。

- botでの担当告知はランダム or 何か決まりがある?
- 担当になった人が休みだった場合はどういう運用になるの?
- 休みの人がいる場合botだと実現できない気がするけど大丈夫?
- 差込で至急修正しなきゃいけないような内容とかが飛んできた場合って回答担当のタスクに差し込まれる感じですか?
- 日替わり担当制は良いと思うけど、どこまでが担当範囲になる?
- 一次切り分けが担当者の責務?内容によってみんなに調査お願いするみたいな感じ?
- メイン担当が見れない場合に誰も見なかったら初動遅くなるかも?

コメントから見て取れるように、運用ルールの課題感や背景が伝わっていなかったり、担当者は何をすればいいのかがわからなかったりする問題が起きていました。

そこで、複数人の関わる「運用ルール」=「プロダクト」と見立て、仮説検証型アジャイル開発に当てはめた業務の進め方をアドバイスしました。

仮説検証型アジャイル開発について

「仮説検証型アジャイル開発」とは、不確実性が高いなかで「正しいものを正しく」作っていくために、ギルドワークス株式会社 代表取締役の市谷さんが提唱しているモデルになります。

今回メンバーへの説明として参考にさせていただいた記事は以下になります

codezine.jp

このモデルを用いた理由は、実開発の前に仮説検証のサイクルが存在していることが図解にてわかりやすいと考えたためです。

実際にアドバイスした内容を以下に共有していきます。

実際にアドバイスした内容

こんにちは!郷田です。

直近の課題を感じている各slackチャンネルでの運用についてルール決めと意見だしが色々動いてて良いですね!

一方でJさん(※新卒1年目エンジニア)の考えてくれた取り決めに対して、運用するチームの皆さんからも「そもそも論」を含む質問や意見が出ているように見えました。 チームで運用するための取り決めが、もしかしたらJさんによる「ぼくの考えた最強の運用ルール」で決定されてるのではないでしょうか・・・?

上記の状態になっていると仮置きして、プロダクトマネジメントの観点からコメントをしてみようと思います。


プロダクトマネジメントを抽象的に捉えると、「チームの運用ルール」というプロダクトを作ると言い換えられます。

まず、プロダクトマネジメントでは、実開発の前には必ず「仮説検証ループ」というのが存在してます。 以下の図でいう「仮説探索(正しいものを探す)」にそれが該当します。

f:id:smartcamp:20210205180950p:plain

error対応チャンネルの現状の課題として書かれている以下は、このなかの「仮説立案」に当たると思います。

現状の課題投稿に対する反応および対処が有志によるものなので見逃してしまうエラーがある・投稿数が膨大なので有志の負担が大きい

また、これらの仮説に対するアプローチの候補は「MVP特定」に該当すると思います。

課題に対するアプローチの候補 「投稿に対する反応および対処が有志によるもの」返事をする担当を1人決める返事をする

そして、今後取るアプローチは「アジャイル開発の作るサイクル(右側のサイクル)」の話に該当すると思います。

対応ルール - エラーの対応者は日替わりで1人とする (正社員のみ、祝日含む) - Slack botで担当者を告知 & 担当者にメンションが飛ぶ

今回「仮説立案」〜「MVP特定」〜「アジャイル開発の作るサイクル」まで、すべてJさん1人だけで完成されてしまっており、「仮説探索(正しいものを探す)」サイクルがチームで1度も回らずに「つくる」段階まで来ていると思います。 つまり、「正しいものを探さずに、つくる物を決めて作っている状況」です。 よって決定したルールに対して多くの疑問がでてしまったのでは無いか?と推測することができます。

「Jさん1人だけの運用ルール」であれば影響範囲は自分だけなので1人で決定しても良いのですが、今回のプロダクトは「チームの運用ルール」です。そのため、仮説検証をチームで回すことが不確実性(ルールを作るリリースをした後に、ルールが変わる結果になったこと)を無くす最短ルートだと思います。

これが実際のプロダクト開発では、開発した後に要求が違うことがわかり手戻りが大きく発生するので「大きくコストをかけたが良いものを作れなかった。」という非常に残念なことになったりします。

...

とはいいつつ、今回作っているのはルールなので手戻りコストは低いです。 そこで、私の場合どのように進めるかを図に合わせた形で紹介してみたいと思います。

まず、以下画像のように仮説検証を段階に分けることができます。

f:id:smartcamp:20210205181003p:plain

今回はシステムを開発するわけではないので、「目的選択の段階」「実態選択の段階」「手段選択の段階」まで最初からやっちゃいます。 (普通のプロダクト開発でも、コストの低い「文言修正」などは一気にやっちゃうことはあります。)

## 現状の課題
1. システムエラーへの反応や対処が有志で行われるため、誰も対応せず見逃してしまうエラーがあった
2. 複数のサブチームに分かれて開発しているため、他チームの担当内容は重要度が判断できなかった(ので巻き取ることができなかった)。

## 課題に対するアプローチの候補
- 返事をする担当を1人決める
- 返事をする担当を複数人決める
- 返事をする担当を日替わりで1人決める

## 今後取るアプローチで郷田が良いと思っている案

- エラーの対応者は日替わりで1人とする (正社員のみ、祝日含む)
- Slack botで担当者を告知 & 担当者にメンションが飛ぶ

ここで重要なことは、「今後取るアプローチ」は、自分の案であるとしていることです。

今後取るアプローチで郷田が良いと思っている案

このタイミングで作ったルールを使うことになるエンジニアの皆さんに一度意見をもらうことで、使う人が考える問題など洗い出すことができます。

例)

日替わり担当制は良いと思うけど、どこまでが担当範囲になる? 初動を誰がキャッチするかは明確になるけど、その後の対応フローが曖昧な現状だと以下のような懸念点ありそう 一次切り分けが担当者の責務?内容によってみんなに調査お願いするみたいな感じ?

これにより、皆さんの疑問を元に、もう少し本質的なディスカッションをすることができます。

考えた例)

郷田:
そもそもエラー対応の初動レスポンスが遅くなってしまうことで、開発チームの誰が拾ってるかもわからないのが問題だと思っているのですが、このあたり皆さん問題に感じてたりしますか?

他の方:
たしかにそれはありそう。だとすると解決策としては当番制にするって話よりも、見た人は誰でもいいからまずは投稿を見たってことがわかるように「👀 」のリアクションだけつけるのはどう?その後対応できる人はスレッドにコメントを残してく感じ!
そうすればまずは投稿する側も、対応する側も見てるか見てないかだけでもわかったりすると思う。
あとは、errorの無視していいものは「🤗」リアクションをつけるとかでも良いかも。

また、実際の対応は一次切り分けもあるので、超緊急だと思う人がいない限りは翌日の朝会で取り上げるというルールにするのはどうですか?

郷田:
意見ありがとうございます!確かに、その解決策良いですね!他の皆さんも同じ意見であれば、Goodリアクションもらませんか?

👍 + 5

最後にこれらを元に「目的選択」「実態選択」「手段選択」を完了したとして、「順序選択」に移ることができます。

郷田:
この先のTODOは以下で考えてます!
- [ ] この記事を皆さんに認識してもらえているか、朝会で議題にだす
- [ ] 実際にリアクションするのを1週間試してみる
- [ ] 運用に問題があればレトロスペクティブ(KPT)で問題を感じた人がProblemとして書く

こうやって上記のように「正しいものを探す」フェーズを1サイクル回すだけでも、本質的な課題とそれに対する解決策が、チーム全員で話しながら進めることができるのではないでしょうか?

本人からのコメント

丁寧なご助言ありがとうございます…😭 確かにサイクル回さずに決めきってしまったなと反省しました🙇 いただいた内容を元に、どうするべきだったか振り返ってみたいと思います! 改めてありがとうございました!

最後に

新卒1年目のエンジニアが問題解決をしたいため自分から起案して動いた内容なので、素晴らしい活動だと感じています。

しかしうまく成果につながらないことは非常にもったいないので、今回コメントをさせていただきました。

今回は運用ルールを1つのプロダクトととして捉えて、仮説検証を回す考え方をご紹介しました。

運用ルールに限らず普段の業務の多くにも転用できると思いますので、みなさんもぜひ使ってみてください。

宣伝

私は今回話したような仮説検証を日々担当するSaaSプロダクトで行っています。

そのノウハウの一部を自社開催のイベントにて共有させていただきますので、ご興味のある方はご参加ください!

【2月25日開催】B2B SaaSエンジニアMeetup - SharingIssues Online #2 仮説検証 smartcamp.connpass.com