「問題解決勉強会」という社内勉強会をしました。
以前、社内のSlackでこの記事が話題になりました。
この記事では掘り下げていませんが、 「問題を切り分ける力」を掘り下げていくと、以下の様になると思います。
- 問題の原因の仮説を立てる
- 仮説を検証する実験計画を立てる
- 得られた結果から問題を切り分ける
この「1. 問題の原因の仮説を立てる」というのは、
経験と知識が求められて、新人エンジニアには難しいところだと思います。
じゃぁそのへんの知識共有する会をしましょう！
ってことで、レク形式の社内勉強会を開催しました。
題して、「問題解決勉強会」
その第一回を5/24に実施しました。
概要
WEB開発チーム、インフラチーム、アプリチームで混合チームを作成し、
出題される障害に対してチームごとにどれだけ可能性を挙げられるかを競い合う大会。
実地方法
- オープニング
- 乾杯
- 出題
- シンキングタイム(15分)
- 回答発表&議論(1チーム5分)
- 優勝チームの発表
目的
弊社ではWEB開発チーム、インフラチーム、アプリチームとチームが分かれています。
それぞれ別の観点からお題の障害の原因となる事象を挙げていくことで、 自分が思いつかなかった観点の可能性を学ぶことができます。
また、同じ案件以外だと絡みが生まれにくいチームを横断するコミュニケーションが発生することで、 困った時に頼れる人脈も作れると良いなと思っています。
ルール
基本ルール
お題の障害が発生しうる原因となる仮説をチームごとに出し、
どのチームが一番多くの仮説を出せるかを競い合います。
今回はGoogle Slideを用いて、1チーム1ページのスライドを作成して、 作成後に仮説をプレゼンするような形式で発表しました。
お題について
今回のお題で出したのは
- サーバ構成
- いつデプロイしたか
- いつ障害が報告されたか
- どういう処理が行われるシステムか
みたいな感じでした。
この辺は割とフレキシブルに変更していいと思います。
解答発表と議論
解答発表時にチーム内で思いついた仮説を発表します。
他のチームはその仮説に質問・指摘ができます。
もしその指摘で無効と判定されたらその仮説は無効になります。
質疑応答が終わった時点で一番残ったチームの勝ちになります。
仮説の議論について
よくあったのが、言い方が違うけど同じ仮説という指摘でした。
例えば、
「DBの負荷上昇による障害」と「バッチ処理により負荷が上昇した」 という２つの仮説があった場合、 「バッチサーバが死んでもWEBサーバが生きていれば表示はされるのでは？」 みたいな質問が来ます。 ここで、「バッチ処理によりDBの負荷が上昇した」と答えた場合 重複する仮説としてどちらかが消えることになります。
こんな感じのやり取りを続け、仮説に対して議論していきます。
あとは、課題で判明している内容と矛盾していないかを議論していきます。
弁が立つ人が応答すると結構生き残る事が多かったりします。
実際にやってみた感想
個人的に面白かった仮説
障害自体が誤認説
「ユーザーからの連絡で発覚した」という書き方だったので、 そもそも障害が発生しているかどうかは未確定な状態でした。
なので、そもそも障害自体発生していないのではないかという方向で仮説を立てていて面白かったです。
攻撃説
AWSのadmin権限を乗っ取られた場合の攻撃の話やDNSハイジャックの話などがインフラチームの人から上がり、 開発チームが思いつきにくいところの仮説がたくさん上がって興味深かったです。
参加者に好評でした
まず、感想を聞いた参加者の全員が「良かった」って感想で、
ほぼ全員に次回はいつですか？って聞かれました。
このリアクションでほぼ成功かなとおもいます。
また、「自分が思いつかない仮説があって勉強になった」という意見も多く、
楽しく学べる会できたのかなと思います。
他にも、今回参加できなかった人も「次は参加する！次いつやるの？」みたいな意見が多く、
参加者から楽しさが伝わってるみたいです。
次回予定
6月にもう一度同じお題で、参加できなかった人中心に開催する予定です。
というわけで、問題解決勉強会を実施しましたが、 気になる方はぜひやってみてはどうでしょうか。
もしかしたらそのうち一般公開して行うかも知れませんので、 そのときには告知すると思うので、参加してもらっても良いかも知れませんね。
