社内でスピードアップコンテスト開催に挑戦した話

吉祥寺.pm29【オンライン】 2022/04/12

Transcript

1. 社内でスピードアップコンテスト開催に 挑戦した話 吉祥寺.pm29【オンライン】 2022/04/12 まつひさ（hmatsu47）
2. 社内でスピードアップコンテスト開催に 挑戦した話 （但し失敗成分多め） 吉祥寺.pm29【オンライン】 2022/04/12 まつひさ（hmatsu47）
3. 自己紹介 松久裕保（@hmatsu47） • https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています 以前 MySQL 8.0 の薄い本を作って配っていました ◦ Qiita の記事： https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d ◦ GitHub リポジトリの他、印刷版を BOOTH で配布していました ◦ 2021/5 発行の 8.0.24 対応版を最後に更新停止しました https://note.com/hmatsu47/n/n3ad586c31dce 3
4. 吉祥寺.pm トーク参加 2 回目です • 前回は約 1 年前 ◦ わたしのまわりのニュー・ノーマル 3 選 ◦ https://speakerdeck.com/hmatsu47/watasifalsemawarifalseniyufalsemaru3xuan • 某 有名企業のパーカーと T シャツをいただきました！ 4
5. 吉祥寺.pm トーク参加 2 回目です • 前回は約 1 年前 ◦ わたしのまわりのニュー・ノーマル 3 選 ◦ https://speakerdeck.com/hmatsu47/watasifalsemawarifalseniyufalsemaru3xuan • 某 有名企業のパーカーと T シャツをいただきました！ 5
6. 本日のネタ • 社内でスピードアップコンテストをやってみた • 出題以外のところでいろいろな技術を使ってみた • 開催直前に問題が発生 • 開催にはこぎつけたものの… • あらためて浮き彫りになった組織の課題 6
7. きっかけ • インフラチーム→ SRE →正式な SRE チーム発足 2 期目 • 正式メンバーとともに、協力メンバーも増えた • 「性能」はサイト（サービス）信頼性の重要なポイント • 座学の機会はあるが（実務以外で）実践の機会がない 7
8. きっかけ • インフラチーム→ SRE →正式な SRE チーム発足 2 期目 • 正式メンバーとともに、協力メンバーも増えた • 「性能」はサイト（サービス）信頼性の重要なポイント • 座学の機会はあるが（実務以外で）実践の機会がない • 期初の目標の一つとしてコンテストの開催を入れた ◦ SRE チームリーダーと相談して決定 8
9. 社内事情 • 20 年 over モノの Web サービスを提供 • 初期の 5 年間以外は Java で開発 • 8 年ぐらい前に Web フレームワークの利用をやめた • 社外の ISUCON などには参加しづらい雰囲気 9
10. 社内事情 • 20 年 over モノの Web サービスを提供 • 初期の 5 年間以外は Java で開発 • 8 年ぐらい前に Web フレームワークの利用をやめた • 社外の ISUCON などには参加しづらい雰囲気 • コンテストをやるなら自前開催の必要がありそう 10
11. 準備① 構想 • 前述のとおり「実務以外の実践の機会」を提供する • 対象は SRE とその協力メンバーのうちの希望者 ◦ マネージャ含む • いきなり長時間は難しいので半日程度の軽いレベルで • 個人戦ではなくチーム戦で ◦ 他メンバーの考え方やスキルを知る機会に 11
12. 準備② 事前周知 • 準備の初期段階で対象メンバーの一部に意思確認 ◦ 競技参加？それとも主催側？ ▪ 結果としてマネージャの 1 人が主催側、ほか全員競技参加 • 全体ミーティングで事前の開催予告（複数回） • カスタマサポート部マネージャへの協力依頼 ◦ 一時的に連携が取りづらくなる可能性があるので 12
13. 準備③ 初回の題材選び • 初回は「定番」中心で ◦ 非効率な DB データ取得（N+1、無駄な行・列の取得） ◦ テーブル構造の欠陥 ◦ メモリ不足になる処理＆ヒープメモリ容量の設定ミス • 個人研究でわざとクソコードを書いて出題のベースに ◦ https://github.com/hmatsu47/kuso-code-samples （最初から公開してた） ◦ 3 種類用意してそのうち 1 つをベースに出題 13
14. 準備④ 出題の調整 • ③の出題ベースの 1 つをもとに内容を調整（Web API） • 実際に自分でコードや設定の修正を試行 ◦ 問題点を把握した状態から 1 時間強で修正できた • ベンチマークを（普段書かない）Go で作成 ◦ https://github.com/hmatsu47/kusocode-bench （これも最初から公開） ▪ Go 何もわからない ◦ 初期コードと修正後のコード（複数パターン）で得点を確認 14
15. 準備⑤ 集客と事前説明 • 対象メンバーに参加意思を確認 ◦ 結局、対象者全員が参加表明 • （ルールの範囲で）チーム編成は参加者の選択にお任せ • レギュレーションを（段階的に）事前説明 15
16. 準備⑥ 小道具の作成 • Web API 動作確認用フロントエンドを React で作成 ◦ https://github.com/hmatsu47/kuso-code-samples ◦ 即興で作ったので props の型適用を忘れたまま本番へ • 得点掲示板を（はじめての）Vue 3 で作成 ◦ https://github.com/hmatsu47/kusocode-rank-app ◦ 開始早々バグが発覚したので慌てて修正（が、まだバグが） ▪ 謎の「残り時間 01:89:60」「1 分に 1 回残り時間が 60 秒長くなる」 16
17. 問題が発生 • 開催直前の横槍 ◦ ミーティングでは異論が出なかった方面から • 結果として ◦ 時間を短縮（全体 4 時間→ 2.5 時間に） ◦ マネージャ不参加に 17
18. 当日の結果 • やはり時間が足りず ◦ どのチームも想定到達点には至らず ▪ 「コードとテーブル構造の直し方」の見立てができているチームがなかった ◦ 一応「面白かった」という反応は多かったが… 18
19. アンケートでは • 一部「チーム戦」「競技形式」が辛かった、という声が ◦ チームメンバーに迷惑を掛けてしまった ◦ うまく立ち回ることができず恥ずかしい • 必ずしも「時間が足りなかったからダメだった」という ことではなかった ◦ もちろん時間も足りなかったけれど 19
20. コンテスト以前にすることがあった • 参加者のつらみをなくす ◦ 「失敗」を許容する組織風土 ▪ 口では「失敗 OK」とは言ってもそう受け止められない雰囲気があった • まずは「メンバーが自信を持てる」環境づくり ◦ 自己肯定感大事 ◦ 「実践の機会」は一旦違う形で（模索中） • 「苦手だからパス」が許される空気も 20
21. 結論：人類自社にはまだ早かった • 心理的安全性の確保が先 • サイト（サービス）の信頼性もそこから 21
22. コンテスト 次の開催 いつの日に 22