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

社内でスピードアップコンテスト開催に 挑戦した話 吉祥寺.pm29【オンライン】 2022/04/12 まつひさ（hmatsu47）

社内でスピードアップコンテスト開催に 挑戦した話 （但し失敗成分多め） 吉祥寺.pm29【オンライン】 2022/04/12 まつひさ（hmatsu47）

自己紹介 松久裕保（@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

• https://qiita.com/hmatsu47
• https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d
• https://note.com/hmatsu47/n/n3ad586c31dce

吉祥寺.pm トーク参加 2 回目です ● 前回は約 1 年前 ○ わたしのまわりのニュー・ノーマル 3 選 ○ https://speakerdeck.com/hmatsu47/watasifalsemawarifalseniyufalsemaru3xuan ● 某 有名企業のパーカーと T シャツをいただきました！ 4

• https://speakerdeck.com/hmatsu47/watasifalsemawarifalseniyufalsemaru3xuan

吉祥寺.pm トーク参加 2 回目です ● 前回は約 1 年前 ○ わたしのまわりのニュー・ノーマル 3 選 ○ https://speakerdeck.com/hmatsu47/watasifalsemawarifalseniyufalsemaru3xuan ● 某 有名企業のパーカーと T シャツをいただきました！ 5

• https://speakerdeck.com/hmatsu47/watasifalsemawarifalseniyufalsemaru3xuan

本日のネタ ● 社内でスピードアップコンテストをやってみた ● 出題以外のところでいろいろな技術を使ってみた ● 開催直前に問題が発生 ● 開催にはこぎつけたものの… ● あらためて浮き彫りになった組織の課題 6

きっかけ ● インフラチーム→ SRE →正式な SRE チーム発足 2 期目 ● 正式メンバーとともに、協力メンバーも増えた ● 「性能」はサイト（サービス）信頼性の重要なポイント ● 座学の機会はあるが（実務以外で）実践の機会がない 7

きっかけ ● インフラチーム→ SRE →正式な SRE チーム発足 2 期目 ● 正式メンバーとともに、協力メンバーも増えた ● 「性能」はサイト（サービス）信頼性の重要なポイント ● 座学の機会はあるが（実務以外で）実践の機会がない ● 期初の目標の一つとしてコンテストの開催を入れた ○ SRE チームリーダーと相談して決定 8

社内事情 ● 20 年 over モノの Web サービスを提供 ● 初期の 5 年間以外は Java で開発 ● 8 年ぐらい前に Web フレームワークの利用をやめた ● 社外の ISUCON などには参加しづらい雰囲気 9

社内事情 ● 20 年 over モノの Web サービスを提供 ● 初期の 5 年間以外は Java で開発 ● 8 年ぐらい前に Web フレームワークの利用をやめた ● 社外の ISUCON などには参加しづらい雰囲気 ● コンテストをやるなら自前開催の必要がありそう 10

準備① 構想 ● 前述のとおり「実務以外の実践の機会」を提供する ● 対象は SRE とその協力メンバーのうちの希望者 ○ マネージャ含む ● いきなり長時間は難しいので半日程度の軽いレベルで ● 個人戦ではなくチーム戦で ○ 他メンバーの考え方やスキルを知る機会に 11

準備② 事前周知 ● 準備の初期段階で対象メンバーの一部に意思確認 ○ 競技参加？それとも主催側？ ■ 結果としてマネージャの 1 人が主催側、ほか全員競技参加 ● 全体ミーティングで事前の開催予告（複数回） ● カスタマサポート部マネージャへの協力依頼 ○ 一時的に連携が取りづらくなる可能性があるので 12

準備③ 初回の題材選び ● 初回は「定番」中心で ○ 非効率な DB データ取得（N+1、無駄な行・列の取得） ○ テーブル構造の欠陥 ○ メモリ不足になる処理＆ヒープメモリ容量の設定ミス ● 個人研究でわざとクソコードを書いて出題のベースに ○ https://github.com/hmatsu47/kuso-code-samples （最初から公開してた） ○ 3 種類用意してそのうち 1 つをベースに出題 13

• https://github.com/hmatsu47/kuso-code-samples

準備④ 出題の調整 ● ③の出題ベースの 1 つをもとに内容を調整（Web API） ● 実際に自分でコードや設定の修正を試行 ○ 問題点を把握した状態から 1 時間強で修正できた ● ベンチマークを（普段書かない）Go で作成 ○ https://github.com/hmatsu47/kusocode-bench （これも最初から公開） ■ Go 何もわからない ○ 初期コードと修正後のコード（複数パターン）で得点を確認 14

• https://github.com/hmatsu47/kusocode-bench

準備⑤ 集客と事前説明 ● 対象メンバーに参加意思を確認 ○ 結局、対象者全員が参加表明 ● （ルールの範囲で）チーム編成は参加者の選択にお任せ ● レギュレーションを（段階的に）事前説明 15

準備⑥ 小道具の作成 ● 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

• https://github.com/hmatsu47/kuso-code-samples
• https://github.com/hmatsu47/kusocode-rank-app

問題が発生 ● 開催直前の横槍 ○ ミーティングでは異論が出なかった方面から ● 結果として ○ 時間を短縮（全体 4 時間→ 2.5 時間に） ○ マネージャ不参加に 17

当日の結果 ● やはり時間が足りず ○ どのチームも想定到達点には至らず ■ 「コードとテーブル構造の直し方」の見立てができているチームがなかった ○ 一応「面白かった」という反応は多かったが… 18

アンケートでは ● 一部「チーム戦」「競技形式」が辛かった、という声が ○ チームメンバーに迷惑を掛けてしまった ○ うまく立ち回ることができず恥ずかしい ● 必ずしも「時間が足りなかったからダメだった」という ことではなかった ○ もちろん時間も足りなかったけれど 19

コンテスト以前にすることがあった ● 参加者のつらみをなくす ○ 「失敗」を許容する組織風土 ■ 口では「失敗 OK」とは言ってもそう受け止められない雰囲気があった ● まずは「メンバーが自信を持てる」環境づくり ○ 自己肯定感大事 ○ 「実践の機会」は一旦違う形で（模索中） ● 「苦手だからパス」が許される空気も 20

結論：人類自社にはまだ早かった ● 心理的安全性の確保が先 ● サイト（サービス）の信頼性もそこから 21

コンテスト 次の開催 いつの日に 22