Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

B1dca90d4b3ffd2ccd918774e1ba170d?s=128

hmatsu47
PRO

April 12, 2022
Tweet

More Decks by hmatsu47

Other Decks in Technology

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