>100 Views
November 07, 26
スライド概要
JAWS FESTA 2026 個サポLT 登壇資料
フルマラソン 2:29:56 で走る日本最速ITエンジニア JBCC株式会社 カスタマー・イノベーション・ラボ Technical Expert AWS Samurai 2024 / AWS Community Builder / JAWS-UG横浜支部 / ChatGPT Meetup / Cloudflare meetup slideshare: https://www.slideshare.net/akifuminiida
サブイベント 動体 監視マラソンの裏側 マラソニ JAWS SONIC #
自己紹介 新居田 晃史(にいだ あきふみ) JBCC株式会社 カスタマーイノベーションラボ - Technical Expert X @nid777 ・ Facebook Akifumi Niida 日本最速ITエンジニア — フルマラソン 2:29:56 2010-2020(※週刊BCN編集部調べ) コミュニティ活動 JAWS DAYS 2025 実行委員長 AWS Samurai 2024 AWS Community Builder(Container) AIコーディング道場 AWS認定 JAWS-UG 横浜支部 Cloudflare Meetup ChatGPT Meetup Tokyo
開催のきっかけ 「テーマがマラソンだから、本当に走る企画をサブイベントでやりた い。マラソンといえば新居田さんなので」 発端は、企画ができたときに実行委員長の加藤さんからSlackで受けた声かけ。真っ先に名前を挙げてもらえたことへの感謝と、その信頼 に応えたい気持ちが原動力。指名されたからには、走る側にも責任 — ここから裏側の話の始まり。
本番は、9月の土曜14時スタート・約4時間の生配 信 1 ランナー5名、コースは非固定 2 ポイントを集めながら走る形式 3 最初の議論は、時間の決め方 4 あえて、一番暑い14時スタート 横浜・都内のチェックポイントを自由に選んで回る形式。みなとみらい経由は個人のコースの一例。 集めたポイントは、5人の合計制。 SONICは24時間のイベント。論点は、何時間走るか、何時に走るか。時期は9月初旬、35度も予想される暑さ。 一番暑い時間から始め、徐々に涼しくなる流れという意図的な選択。同時に、熱中症リスクが最も高い時間帯という前提で、ガードレー ルを組み直す起点。
本番の様子 — ゴールと、配信の裏側
準備その1 — 6月、AWS Summit で実機テスト 本番に近い環境での事前テスト。動かして初めて見える 使いにくさの発見 汗をかき、ポーチに入れて走り、トイレに寄っても、位 置が取れるかの確認 カタログ通りにはいかないものも存在。実際に触れたこ とによる、使う/使わないの判断 受け渡しの調整が最大の負担。大規模な本番環境の合間 を縫うこと自体、準備の一部 事前に潰した分、本番の不安は軽減。
準備その2 — 8月、皇居で耐久テスト 暑さの中での長時間走行と、ポイントの確認 停止時の暑さは一層の厳しさ 本番は14時スタート。条件の厳しさはさらに増大 感覚ではなく、閾値で止める方針の決定。
ポストモーテム→ガードレール設計 1 目的 — 何を守るかの決定 2 観測 — 守るものの状態把握 3 判断 — 閾値と判断者の事前決定 4 対処 — 止め方と逃げ道の用意 ランナーにSLAはなし。SLOは安全だけ。 対象は速さではなく、異常の兆候。 判断材料は暑さの閾値、判断者はマネージャー。 縮退運転とフェイルオーバーの、本番前の決定。 この判断と見守りを担うのが、マネージャー — 次のページで紹介
マネージャー — アクセルとブレーキ マネージャー3名 — よしださん、MAXさん、ひろみさん 安全に倒しすぎれば、面白さの喪失。ブレーキだけでは 不十分 アクセル — 盛り上げ役という大きな役割。配信と現場の 熱量づくり ブレーキ — 見守りと、止める判断の保持 走る人には兼務不可能なアクセルとブレーキを、一手に 担当 両役の両立こそ、思い切って走るための支え
ランナーにSLAはなし 唯一のSLOは、安全だけ そもそも個人や速さを競わない企画。ポイントは5人の合計制、個人 に無理をして稼がせる構造なし。目標は「全員、無事に帰ること」 のみ。 守るものの決定が、監視設計の起点 見るのは記録ではなく、異常の兆候。 SLOが先、監視は後。逆の順序では、監視は「速く走らせるため」のものに変質。
監視設計 — 決めるべき軸と、この企画の答え 観測対象(何を見るか) 観測点(どこで見るか) サンプリング間隔(どのくらいの頻度か) 欠測の扱い(止まったらどうするか) 本部は位置と暑さ。本人は時計で心拍・距離・ペースと体調の兆 候。 GPSは1分更新。WBGTは前日18時・当日10時・13時と、当日朝の作 戦会議で判定。 エスカレーション(誰が見て、誰に上げるか) 見るのは本部とマネージャー。連絡は電話番号交換による直接連 絡。緊急連絡先はスプレッドシートに集約。 本部はGPSの位置情報のみ。デバイスは各ランナー2台携行 — 冗長 構成。本人の時計は本人だけの確認用、本部への送信なし。 GPSの停止は異常扱い。 観測の副作用(何を見せないか) ヘルスチェックの点呼は廃止。配信に乗る前提自体が、率直な申告 の妨げ。 電池は遠隔監視の対象外。持続可否は実機テストで確認し、電池切れはリタイア扱い。
止め方と逃げ道の事前決定 縮退運転 — 閾値による段階制 暑さに応じて、開始時刻の後ろ倒し、走行時間の短縮、中止を使い 分け。短縮は、終了時刻を固定してスタートを遅らせる方式。事前 決定により、現場で迷う余地なし。 「止まれる」という前提こそ、思い切って走る力の源泉。 フェイルオーバーも、正規の手段 ランナー個人の退避は、電車で戻る選択。企画全体では、代替コン テンツへの切替。どちらも失敗ではなく想定内の対処で、連絡は電 話で直接。
挑戦を可能にしたガードレ ール ガードレールは、挑戦を縛るものではなく、挑戦を可能にするも の。安心して思い切って参加できたのも、ITで思い切ったチャレ ンジができるのも、このガードレールのおかげ。 誘ってくださった加藤さんをはじめ、支えてくださった皆さんへ の、心からの感謝。