名前だけではなく、
そこに至る話を。

自分で作ったアプリ。 種目を選び、日付とセットごとの重量・回数を入力します。保存データが履歴、負荷量の計算、推移グラフの土台になります。公開ページは、この履歴を閲覧専用で見せるものです。 Kraftwerkが生まれた話を読む →

背景がわかるデータ。 セッション指標、総負荷量、歩数、期間の切り替えで、1回の運動を週・月の流れの中で捉えられます。

育てられる作りに。 CSVやヘルスデータの取り込みで履歴を持ち運べるようにし、元の記録を変えずに表示側へ新しい指標を加えられます。

KRAFTWERK / 開発の歩み

紙の記録から、見える進歩へ。

自分の筋トレのために作ったアプリを、四つの場面で紹介します。

01手書きノート02デジタル化03自作アプリ04現在の進歩

1 / 4

始まりは、ノートでした。

ぴったりのアプリが見つからず、日付と回数を手書きしました。これは実際の腕立て伏せのページです。

小さな構成に、広がる死角。 最初は数台のサーバーとログ解析のスクリプトだけでした。基盤が大きくなると規模にも複雑さにも追い付かず、何より、起きた後のことしかわからない仕組みでした。

上司もお客様も、監視ツールではありません。 問題が起きるまで、なぜ待つのでしょう。上司やお客様が最初に障害を知らせた時点で、運用は後手です。障害そのものに加え、社内外でチームへの信頼も損ないかねません。

典型例は、TLS証明書の期限切れ。 2000年には、今のような更新自動化はありませんでした。Let’s Encryptの登場はずっと後の2015年です。接続エラーで気付く前に、期限を監視する必要がありました。要件や発行元はさまざまで、自動更新も監視が必要です。

検知し、届け、記録を残す。 最初はNagiosとZabbixを選びました。異常を検知し、動ける人へ通知する必要があり、特に24時間365日のオンコールチームへ届けました。当時は費用の制約で高可用性構成ではなかったため、確実な検知と素早い対応が品質維持の要でした。監視自体が停止リスクをなくすわけではありません。年月とともにSMS、WhatsApp、PagerDutyも使いましたが、すべて2000年に使っていたという意味ではありません。

単発の障害から、傾向へ。 性能指標を残すことで、負荷、遅延、余力が時間とともにどう変わるか見られます。後にGrafanaとCheckmkも加わりました。悪化を早く見つけ、向かう先をデータで理解するという目的は変わりません。

変わらない考え方。 監視はダッシュボードを並べることだけではありません。誰かに問題を教わる前に、チームが動ける機会を作るものです。

当時の参考：Let’s Encryptの初の公開証明書発表（2015年）。