こんにちは、エンジニアのshinです。
アジャイル開発を良いマラソンランナーに例えるなど、開発をマラソンに例えることはよくあります。
私自身も以前から、開発とマラソンには共通点があると感じており、
今回は、ランサーズで実施しているスクラム開発をハーフマラソンに取り入れてみるという逆のアプローチを試みましたので紹介します。
バックログにタスクを積む
マラソンは、計画的な練習など準備が大きな割合を占めます。
特に1週間前～前日の過ごし方が重要になりますので、
タスクリストを作って実行していきます。
前日までにやること(例)
- 体調を整える
- 早く帰る(カレンダー登録)
- 朝食を買う
- 服装やシューズの準備をする
- 逆算して起きる時間を設定する
また、マラソンレースの当日は朝早いことが多いので、
慌てることがないようにやることをタスク化しておきます。
当日やること(例)
- 朝食食べる(約3時間前)
- 会場に行く(乗換案内)
- 受付する(約1時間前)
- 走る
設定タイムはバーンダウンチャートで見える化
1キロのあたりの目標タイムを設定します。
ポイントとしては、過去の結果からベロシティを推測して
最初から無理な目標は立てないようにします。
私の場合、ベストタイムは1時間45分なのですが、
3年前の記録になるので、半年前に走った記録1時間52分を加味して、
ベストを5分/km、ベターを5分10秒/km、マストを5分20秒/km
に設定します。
この目標タイムはバーンダウンチャートをイメージすると
走っている途中でも頭の中で把握できてわかりやすいです。
「持続可能なペース」を保てているか？を問いながら、
1キロごとのタイムと調子を見ながら目標を都度設定し直します。
イテレーションを繰り返す
これらの準備を整えてスタートしたのですが、さっそく問題が起きました。
1キロごとにあると思っていたキロ看板が見当たりません。
どうやらこのレースでは5キロごとにあるようです。
これは焦ります。
ただ、開発プロジェクトでもそうですが、
いくら綿密に計画を立てても想定外のことは起きます。
大事なのは、
- 想定外のことに悩み過ぎず、ひとまず最初のイテレーションはやりきってみる
- 各イテレーションが終わったときに振り返りして、問題があれば改善する
ことなんじゃないかと思います。
ペースが遅いんじゃないか、逆にオーバーペースなんじゃないか
など不安にはなりましたが、
1キロごとで設定したタイムを5キロごとに変換して、
自分を信じて最初の5キロを走りきりました。
そして、最初のイテレーション(～5キロ)の振り返りをKPTでやります。
K 設定目標のベストを上回るペース。
「持続可能なペース」を保てているか？
イエスなので、このままのペースで
P とは言え、オーバーペース気味なのでこれ以上は上げないように
T 他の人のペースに引っ張られないようまわりを無視してマイペースで走り、
次の5～10キロの結果をもって、10～15キロの目標を設定する
最後の最後まで細部にこだわる
10キロ、15キロと同じぐらいのペースで進めることができたので、
このまま流れで行ってもベストタイムは達成する感触がありました。
ただ、目標を達成できそうとなると次の目標をという欲が出てくるもので、
最後の力を振り絞ってラストスパートした結果、1時間43分をギリギリ切ることができました。
数秒ではありますが、最後の最後までこだわりを持つことで
より良いアウトプットが出て次にもつなげられたと思います。
ハーフマラソンの自己べスト更新というのは、
年初に立てた目標の1つで、残り1か月で達成できました。
まとめ
- 計画・準備を事前にやっておく
- 目標の見える化
- 想定外があっても最初のイテレーションは信じてやりきってみる
- 振り返りをする
- 最後の最後までこだわる
- 様々な粒度でPDCAを回す
マラソンも開発も引き続き目標達成していきます！
