| @ブログ

これから毎月写真でふりかえってみることにする。

SNS に写真を上げるだけではなく、自分で見え方まで考えて写真を整理してみたくなった。 Flickr に写真を上げてアルバムを作っていたようなことを自分のブログでやる感じ。

ギャラリーのライブラリは Medium Zoom だと足りなかったので PhotoSwipe に移行してみた。

| @雑談

1 月

根子岳と祖母山

正月早々、山に登った。二年連続阿蘇山。砂千里側から登って仙酔峡に下山した。北面は日が当たらず凍っており、傾斜の急なバカ尾根を下るのは怖かった。

ブログには書いていないが確か正月の初売りで Mac mini の M2 Pro モデルを買った。 Apple Silicon の速い Mac を手に入れたので Whisper CPP を使って Castro を作っていた Supertop の Podcast の文字起こしをしてブログに書こうとしていたが、未完のまままだ公開できてない。年末年始で書き上げたい。

仕事はアプリのダウンロード数をどうやったら増やせるかを延々考えていた。開発をしてダウンロードを増やすなんて無理ゲーだろうと思ってたが、頭を使って何個か施策を考えた。あとは企業向けの機能をテコ入れしていた。

2 月

多良岳から見る雲仙方面の山

熊本城マラソンに出てる。サブフォーを狙っていたが練習不足で果たせなかった。一人で出て誰も知り合いのいない熊本城マラソンは孤独だった。来年雪辱を果たしたい。

中旬のやたら寒い時期に佐賀と長崎県境の多良岳・経ヶ岳に登山に行った。パラパラと落ちてくる樹氷の下を歩くのは楽しかった。花粉がやたらきつくて寒かったけど楽しい登山だった。

仕事はやたらネットワーク効果について考えてたが、まだ思考が甘かった。その後ハイパー起業ラジオを聞いたり本を読んだりしてネットワーク効果についての知見を深めていく。

3 月

今津湾

3 月から 6 月にかけてはブログ記事がない( 3 月に熊本城マラソンの記事を書いているが、それ以外は何もない)。

3 月の頭に糸島であったトレランのレースに出た。ショートレースであまりパッとしない成績だった。まだ 300km も走ってないアルトラのトレランシューズ Outroad が破れて悲しかった。

仕事は新規ユーザーの継続率を伸ばすための A/B テストをやってた。

4 月

長垂海岸

平尾台のトレランレースロングに出た。雨降りでコンディションが悪く、関門タイムギリギリのゴールだった。このときからギリギリグセが付いている。

家の近くの山で有名なトレランチームの人たちを招いて緩い練習会をやった。グループ位置共有を宣伝できてよかった。

仕事はどうやって EC を伸ばすかを考えていた。やはり基本はネットワーク効果だと思って、ユーザーがレビューを書ける機能の土台を作っていた。日の目を見るのはだいぶ先のことになる。

あと、ユーザー登録数を劇的に増やす施策をリリースして、毎月の新規ユーザー数をかなり上積みできた。

5 月

退勤からの都市高速

南畑里山トレイルというトレランのレースに出た。楽しかったがショートレースは出し惜しみをしてしまう。レース後、体力が有り余っていた。

仕事ではこの頃から組織変更が計画されていて、自分の役割がちょっと変わりつつあった。

顧客起点を本格的に取り入れることになり、 N1 インタビューをやったりもしてた。

6 月

久住三俣山

仕事で久住に登山に行った。ミヤマキリシマ終わったあとの平日の久住は静かでよかった。

組織変更の荒波に揉まれたり、 EC のシステムをどうするかを考えたりしてた。もはや単なるプロダクトマネージャーではなくなりつつあった。

7 月

通勤風景

キリエビのロングに出た。こちらも関門 10 分前のギリギリゴール。最後の 15km くらいを近くにいた人たちと励まし合いながら一緒に走った。とても良い思い出。

仕事はなんと平社員からいきなり部長になってしまった。やることが大きく変わり、隣の部長から厳しいご指摘を賜りながら歯を食いしばって働いた。

この頃からハイパー起業ラジオを聴いて積読していたネットワーク効果の本をちゃんと読むようになった。

8 月

阿蘇山

脊梁ピストントレイルというトレランのレースに出たが、初めてリタイヤした。登りが急で、また水場がなく、とても消耗するレースだった。折り返し地点の関門時刻に間に合わず、失格となってしまった。めっちゃ悔しい。まだまだ自分は雑魚だと思い知らされたレースだった。来年は完走したい。

仕事では相変わらず EC のシステムをどうするかとネットワーク効果について考えていた。ユーザーインタビューではなく、山を歩いている人に話しかけて話を聞かせてもらうというのもやった。山を歩いてる人たちはほとんど自社アプリを使ってくれているのではないかと思っていたがそうでもなくてショックを受けた。

9 月

長垂海岸の夕焼け

PayPay ドームリレーマラソンに出た。リレーマラソン前の二週くらいは休みの日の朝に大濠公園に集まってみんなで練習したりしてた。大濠公園から西公園や南公園に走りに行った。

仕事は相変わらずゴタゴタの整理をしていた。この頃はあまり戦略的な動きができず、目の前の仕事に右往左往していた。

10 月

七ツ釜

翌月の福岡マラソンに向けて 30km 走を 2 回やりたかったが 1 回しかできなかった。しかし、初めて一人で大濠公園で 30km 走をやったのは自信になった。一人だと諦めないか心配だったけどちゃんと最後まで走れた。

仕事は相変わらずゴタゴタ処理。この頃から MAU を自分たちの力でどれくらい伸ばせるかにチャレンジすることになって、年末に怒涛の機能リリースをすることに。仕込みを始めた。

11 月

南阿蘇外輪山

オアシス再結成の報を受けてオアシスをよく聞くようになってた。その流れでアンディー・ベルがオアシス加入前にやってたバンド RIDE の曲を聞くようになった。 Vapour Trail めっちゃよい。

ランニングは福岡マラソンに出てきた、ネットタイムではあるかサブフォーをギリギリ達成した。 8 秒差。

また 11 月から会社の人たちと週に 1 回大濠公園を走るようになった。部活みたいで楽しい。

仕事ではリリースする機能の狙いや目的を社内で共有するのが難しくて難儀した。プロダクトマネージャー間で認識をそろえるのも難しいし、他部署の人と認識をそろえるのも難しかった。

12 月

会社からの景色

11 月に引き続き宮崎であった青島太平洋マラソンに出たが、記録更新はならなかった。初めてレース中にうんこしてしまった。最悪。そもそも想定外に福岡マラソンでサブフォーできてしまったせいでその後のランニングのモチベーションが落ちてしまって全然走れてなかった。

仕事は仕込んでいた機能が次々リリースされた。炎上した割に期待した効果が得られない機能や、そもそも使ってもらえない機能もあったが、一つは結構当たって成果を出せた。加えて失敗のリカバリーで出した機能も大きな成果につながった。例年、 12 月になると利用が落ち込むが、 MAU を自分たちでコントロールすることは出来なくはないということがわかったのは収穫だった。いままで大雑把に捉えていた MAU を細かく分解して、それぞれの要素ごとの継続率なんかを分析してる。まだこれといった施策はないが、来年はこの知見を活かしてさらにサービスを成長させていきたい。

2025 年の抱負

仕事

去年のふりかえりでは「何者にもなれない人生だった」と書いていた(2023 年のふりかえり)が、いきなり部長になってしまった。

プロダクトマネジメントとピープルマネジメントは別物と本には書いてあるけど、人に頼んで何かやってもらうという点ではあまり変わらないとも思う。人から信頼してもらい、自分の言葉や考えを信じてもらって行動してもらうという点は変わらない。

それを言い始めたらエンジニアだろうが営業職だろうが同じかもしれない。仕事をしていく上で人から信頼してもらうことは重要だ。そんなの誰でも知ってそうだけど、意外とそれができない。

たまたま年末に買った『プロダクトマネジメントの教科書』という本が良くて、この辺のスキル(人から信頼される、リーダーシップやオーナーシップを発揮する)ことについて実践的な内容が書かれていた。

役割に応じた働きができるよう、もうちょい戦略的に動きたい。

ランニング

ランニング実は去年に比べて距離が伸びていない。これまで毎年距離を伸ばせていたが、今年は夏くらいから走る距離が短くなっている。毎月 200km は走りたいのに、部長になってからみるみる前年同月比の走行距離が落ちている。

年間走行距離

ただ、ランニングのペース(スピード)は上がっている。去年だったらできなかったような、キロ 5 分を切るペースで 20 分間走をやれたりはしてる。なので練習の質は上げられていると思う。

来年こそは距離を伸ばして、月間 200km をコンスタントに超えていきたい。できればマラソンで 3 時間 45 分くらいでゴールできるようになりたい。少なくとも 2 月の熊本城マラソンではサブフォーを再現したい。

ブログ

2024年のブログ執筆状況

実はこの記事を含めても 11 記事しか書けていない。もう少し気負わずに日記感覚で気楽に書きたい。クソみたいな記事でも書かないよりは書いた方がマシ。書かなければ何も残らないしふりかえることすらできない。

Twitter が X になったり、 Threads や mixi2 が登場したりしたけど、セルフホストのブログが一番表現力が高く自由度も高い。死ぬ間際に Twitter や Instagram を見返すより自分のブログを見返した方が良いと思える状況にしておきたい。

| @ブログ

嘉穂アルプス 屏山

最近結構走ってるから iOS のフィットネスアプリとか HealthFit でめっちゃログや統計を確認してる。

前月との比較 直近 12 ヶ月間の月ごとの走行距離 日毎の積み上げの前年比
前月との比較、直近 12 ヶ月間の月ごとの走行距離、日毎の積み上げの前年比

いま自分は月間 100km 以上走ることを目標にしている。月間 100km はガチラン勢からしたら大した距離ではないのだが、油断して 3, 4 日走るのをサボったり雨が降ったりすると達成が難しくなるので、前月の同日と比べて進捗はどうかを確認してる。

同じような感じで進捗や達成状況を確認できる機能がブログにも必要なのではないかと思って、自分のブログのアーカイブページで年を選ぶとその年の月ごとの投稿数をグラフで表示するようにした(これまでは年で絞っても年ごとのグラフしか表示されてなかった)。

これで去年の同月に比べてどうかとか、その時期にどんな内容(カテゴリー)の記事をよく書いていたのかがわかるようになった。ランニングと同じように自分の頑張り状況が可視化されるようになった。


そもそもブログを書くことの意義とは何だろうか。大まかに二つあって、以下のように整理されるのではないかと思う。

  1. バズる記事を書いてアクセスを集める
    • 集めたアクセスで自分の認知度を高める
    • 集めたアクセスをマネタイズする(広告)
    • 世の中を変える
  2. 自分の内省のために書く
    • 読書や学習で得た知識を貯めておく
    • 考えを整理する

1 の観点でいうとアクセス数が重要なのだが、いまどきブログで小銭を稼ごうとか世界を変えようとかしてる人はいないはずで、ほとんどのブログは著者自身のために書かれてる(↑の 2 の方)と思う。自分のために文章を書きたい人にとって、書いた内容と密度や頻度、また過去に書いた記事を簡単に振り返ることができることの方が重要なはずだ。

なのに、たいていのブログサービスはアクセス解析機能はあるが、過去の自分の執筆状況を統計的に確認できる機能はない(少なくとも ameblo とはてなブログと livedoor Blog にはなかった)。アクセス数は Twitter で影響力のある人にシェアされたとか外部要因で増えることもあるから、それだけで自分のブログアクティビティを正確に測るのは難しい。

同じような話を以前にもブログに書いている。

振り返りの観点でも既存のブログはあまり良くない。たいていのブログはそもそも自分で書いた過去記事を読むのも大変だったりする。時系列に全文表示されてページネーションして辿らないといけない。

検索機能もいまいちだ。自分の考えたことを貯めておく場としてはちょっと貧相すぎる。

世の中に一般的に出回ってるブログは著者自身のためというより、いかにアクセスを集めて広告でマネタイズするかに主眼が置かれているから、内省や情報の取り出しやすさはあまり考慮されていないのだろう。いかに PV を上げるか、いかに滞在時間を長くするか、いかに回遊させるかが大事になってくる。

しかし先ほども書いた通り、芸能人や著名人を除き、ブログは自分のために書いている人が多いはずで、アクセス数を集めることよりも書き手の体験にフォーカスしたブログがあってもよいのではないだろうか。

ランニングはアプリを使ってログを取ることでいろんなデータが可視化されめっちゃモチベーションが上がる。「今月 100km 走っちゃった〜」とか、「 1km のペースが 6 分切れるようになってきた〜」とか。前年同月との進捗比較も面白い。

ブログでも「今月は 10 記事書けた〜」とか「 1000 文字以上の記事を 5 記事書いた〜」みたいな達成感はあるんじゃないかと思う。つまり、 GitHub の Contribution グラフのブログ版みたいなやつが必要だと思うのだ。

GitHub Contributions Graph

ランニングだと時計だったり Strava などのサービスが走るモチベーションを喚起してくる。一方でブログは誰も書くのを促してくれない。

ブログを書く人が少なくなったのは SNS のせいという面は間違いなくあるけど、ブログ自体の進化が足りないのだと思う。もっと書き手の脳みそをハックして、著者に書きたいと思わせるような仕組みがないとブログは衰退していくばかりなんじゃないだろうか。

突き詰めると、ブログの主なマネタイズ手法が広告しかないのが根っこの問題な気がする。読み手に広告を見せることで収益化するのではなく、書き手の使い勝手や満足度を高めることで収益化できる可能性(書き手に対して機能課金する)はないのだろうか。ランニング系のサービスやアプリは実際そうやって収益化してる(うまく行っているかはわからない)。

| @ブログ

Mac の定番ランチャー、 Alfred のような検索 UI が好きだ。こういう UI で検索できるソフトウェアやウェブサイトがあると気持ちいい。自分のブログにモーダルウィンドウの検索を追加したときも Alfred みたいにしたいと思いながら作った。

見た目は Alfred っぽくできたが、キーボードで操作できない点が気になっていた。いちいち画面右上の🔍マークを押さないと検索 UI を呼び出せないし、検索しようと思って気が変わったときにはカーソルを動かしてモーダルウィンドウの外の領域をクリックしないとモーダルを閉じられない。これが地味にストレスだった。

見た目だけでなく使い勝手も Alfred のようにしようと思ってガチャガチャやってみた。 Access Key を割り当てて Alt + Control + s で検索窓を開き、おもむろに検索文字列を入力すると結果が出てきて、矢印キー上下で候補を移動でき、 Return で選択(その記事に遷移)できる。検索をやめたいと思えば Esc でモーダルウィンドウを閉じることができる。トラックパッドやマウスに持ち替えることなく、キーボードだけで検索できるようになった。めっちゃ便利。

| @ブログ

普段は Vim などのテキストエディターで文章を書いていて、ブログの投稿画面にはできあがった内容をコピペするだけだったので、投稿画面の使いやすさやは気にしたことがなかった。画像のドラッグ・アンド・ドロップ・アップロードや、オン・ザ・フライでプレビューをできるようにしたが、テキスト自体の書きやすさを改善しようとはしてこなかった。

大筋はテキストエディターで書いたとしても、最後に推敲したり、推敲していて気が付いたおかしなところの修正は投稿画面で行うことが多い。やっぱり投稿画面の書きやすさは重要だ。特に長大な内容を編集しているときにテキストエリアが狭いととても使いづらい。ある程度大きさがあり、画面内に大量の文字が表示されるテキストエリアが好みだ。

Lokka が開発されていた 10 年以上前は解像度の小さいディスプレイが主流で、 Lokka の管理画面は小さいサイズのウィンドウで閲覧することを想定したテキストエリアのサイズになっている。今日の高解像度ディスプレイで見ると不便なので画面一杯にテキストエリアが広がるようにした。

投稿画面のレイアウトを改善

iPad からも投稿しやすいように投稿画面のレイアウトも修正した。本文のテキストエリアが広がったためスクロールしないと「スラッグ」以降の入力欄にアクセスできなくなったので、ある程度横幅のあるウィンドウのときにはこれらを右側に配置するようにした。

加えて、フォームを書きかけで保存したかどうかがはっきりせず、未保存の内容があるのに保存せずページから離脱してしまうことがあったので、変更点があるときは背景色を変えてわかるようにした。これにより記入内容を保存せずページを離脱してしまい、内容が失われるという悲劇を回避できるようになった。やり方は適当に検索して出てきた Stack Overflow を参考に、ページを読み込んだ時点で JavaScript でフィールド内の要素を JSON.stringify して data attribute に格納し、その後各フィールドの input イベントを監視して変更があるかどうかをチェックしている。

class FormObserver {
  constructor() {
    this.initializeFields();
    this.observeFieldsChange();
  }

  initializeFields() {
    const fields = Array.from(document.querySelectorAll('div.field'));
    for (const field of fields) {
      const inputElement = field.querySelector('input[type="text"], textarea, input[type="datetime-local"], select option:checked');
      if (inputElement === null) {
        continue;
      }
      field.dataset.serialize = JSON.stringify(inputElement.value);
    }
  }

  observeFieldsChange() {
    const fields = Array.from(document.querySelectorAll('div.field'));
    for (const field of fields) {
      const inputElement = field.querySelector('input[type="text"], textarea, input[type="datetime-local"], select');
      if (inputElement === null) {
        continue;
      }
      inputElement.addEventListener('input', () => {
        if (field.dataset.serialize != JSON.stringify(inputElement.value)) {
          inputElement.dataset.changed = 'true';
          field.classList.add('edited');
        } else {
          inputElement.dataset.changed = 'false';
          field.classList.remove('edited');
        }
      })
    }
  }
}

input イベントを監視すると動作がもっさりするのではないかと心配したが、そんなことはないようだ。普通に使えている。

いまのところ管理画面の HTML レンダリングはサーバーサイドで Ruby で行っているが、これ以上凝ったことをやるなら React などを使って JavaScript で HTML を組み立てる方式にしていく方が効率が良さそうだ。

| @ブログ

404 ページ、昔はそもそもなくて 404 Not Found ステータスを返すだけだったり、あっても「見つかりません」というだけのものが多かったけど、最近はサイトマップ的なコンテンツや代替となるコンテンツを表示するサイトも見かける。というわけでこのサイトでもやってみることにした。

このブログの URL は /YYYY/MM/DD/slug という形式になっている。パスの /YYYY/MM/DD の部分はお飾りで、実際は slug がユニークになっているので slug で表示すべき記事を判定している。

よくあるのが記事を公開後、 slug 部分にタイポを見つけて変更するというケース。しかしすでにその時点で記事が Twitter などでバズってたりすると、 Twitter で共有されている記事を見てやってきた人が 404 Not Found ページを見ることになる(この前の「不便になるインターネット」がまさにそうだった)。それはまずいので slug のタイポを修正すると同時に Nginx の設定ファイルをいじってタイポ修正前の URL から修正後の URL へリダイレクトするようにしていた。しかしリダイレクトごときでサーバーの設定ファイルを修正して root 権限でリロードするというのはめんどい。 SSH でログインもしなければならない。大げさすぎる。

というわけで思いついたのがこの機能で、 Ruby でクラス名やメソッド名をタイポしたときに正しい候補を表示する did_you_mean.gem を利用した。存在しない slug で URL を開くと以下のように候補が表示される。

404 Not Found

コードはこんな感じ。

# Helper
def not_found_candidates
  @not_found_candidates ||=
    begin
      slugs = Entry.published.where.not('slug REGEXP ?', '^[0-9]+$').pluck(:slug)
      spell_checker = DidYouMean::SpellChecker.new(dictionary: slugs)
      current_slug = request.path_info.split('/').last
      slug_candidate = spell_checker.correct(current_slug)
      Entry.published.where(slug: slug_candidate)
    end
end

# View
- if not_found_candidates.any?
    %p Did you mean?
    - not_found_candidates.each do |candidate|
      = link_to candidate.title, candidate.link

データベースから slug 一覧を取り出して辞書とし、 DidYouMean::SpellChecker に食わせて似たページの候補を取得して表示する。タイポありのページを訪れた人はワンクリックしなければならないという手間が増えるが、これでタイポを修正したときに面倒なリダイレクトの設定をする必要がなくなった。

なお 404 ページには検索窓や最近の記事、カテゴリー一覧も表示して回遊性を高めている。

404 Not Found ページ

| @雑談

福岡県水産海洋技術センターから見る脊振山

年が明けてからやるのはどうかと思うが、タイミングがなかったので今さらながら 2022 年のふりかえり。

ランニング

2022 年はよく走った。これまでも何度か走ってると書いていたが、ちゃんとグラフにしてみると 2022 年の 8 月までは大して走っておらず、 2022 年の 9 月から本腰を入れて走るようになったようだ。

オレンジ色の線が 2022 年のもので、9 月から傾きが急になっている。 9 月は月間 110km 走った。月間 100km はフルマラソンに出られる基準のようなのでこの頃は調子こいていた。

ランニングの頻度を上げるのに役立ったのが計画表だった。それまで漫然と走っていたが、漫然と走っていると月間 100km も走れないことに気がついた。自分は一回 5km 走っているが、それを気が向いたときに週 2, 3 度やるだけだと月間 50km くらいにしかならない。きちんとランニングした日と距離を確認していかないと目標には辿り着かない。ログは Apple Watch で取得しているが、統計データとしては見られない。なので HealthFit というアプリを使っているが、 HealthFit では目標設定ができないので Numbers でシートを作って管理することにした。これは元はてなのディレクターの二宮さんの記事の真似。

こちらが年間の週次のランニング計画。

年間ランニング計画

こちらが月間の日次のランニング計画。

月間ランニング計画

月間のシートに日次の目標と実績値を入れると、年間の週次のシートに自動反映される仕組みになってる。これによって自分は一週間に何 km 走る予定で現在目標に対してどのくらい達成しているのかを確認できるようになる。

37signals の本を読んで、計画を立てるのはアホだ、数値目標なんて意味がない、未来を先読みすることはできない、という発想に影響されて計画を立てたりするのは何となく良い印象を持っていなかったけど、月間何キロくらい走りたいとか、ベンチマークとなる具体的な数値目標がないとなかなか実績は積み上がっていかないと思う。もちろんまだ走ったことがない状態でいきなり月間 100km のような目標を立てるのは愚かだと思うが、そこそこ走れるようになってきたら(自分の力がわかるようになってきたら)計画を立てたり数値目標を設定したりするのは悪くないことだと思う。

9 月にがむしゃらに走ったおかげか、最近は走るペースが一段速くなっていて、 1km を 5 分台で走れるようになってきた。今年はちょっと色気を出して初心者向けのトレランの大会に出てみようかと思ってる。

登山

4 月に脊振山系全山縦走、 11 月に九州脊梁に行った。夏に北アルプスを予定していたが、ちょうどコロナにかかって行くことができなかった。何にせよ最近は山に登るのよりも近所を走る方が楽しいので山への足が遠のいた一年だった。登山時の体力作りで走り始めたのに本末転倒している。

仕事

一昨年は結構でかい成果を出せたが 2022 年はぱっとしない一年だった。反省したい。

生活

iPhone を買い換えて 11 から 14 Pro になった。カメラが三つになって望遠の写真を撮れるようになったのが便利。 Dynamic Island も便利。タイマーかけてるときに常に Dynamic Island で残り時間を確認できるのは相当便利。 164800 円払ってよかった( 36 回ローン)。

サウナにハマってぼちぼち行っていた。サウナーの人たちのように一週間に何回も通うというほどではないが、金曜日の仕事帰りにサウナまで走って行ってサウナに入って帰るというのを何回かやった。花金感が出て良い。

2020 年に車を買い換えたがあまりドライブしてない。アメ車なので燃費が悪い、コロナなので出かけづらい、などいろいろあるが、せっかく車を買い換えたのに使わないで置物になってるのはもったいないので有効活用したい。

そういえば 2022 年は YouTube をよく見た。 YouTube Premium に入ったので広告が表示されなくなり、邪魔が入ることなくとてもなめらかに動画を視聴できるようになった。 Netflix はあまり見ていなかったので解約し、 YouTube で素人が上げる動画をよく見た。ストーリーのない、ただ料理をしているだけとか、ただ穴蔵を掘っているだけの 15 分くらいの動画を見るのがちょうどよい。 Netflix の動画は長いし、ことあるごとに金、暴力、セックスを意識させられるので見るのがきつい。こってりしすぎている。

ブログ

Tantivy を導入して全文検索できるようにした。検索も見た目を変えてインクリメンタルサーチできるようにしたりした。年に一回くらいはバズる記事を書きたいが、 2022 年は不作だった。反省したい。

総括

仕事や生活、ブログは本当にぱっとしなかった。その代わり走ることを頑張っているのかも知れない。ランニングや登山は、大して頑張って生きていないのに走ったり山に登ったりするとめっちゃ頑張ってるかのような錯覚を得られて自己肯定感が高まる。仕事などでもちゃんと成果を出しつつ走ったりできたら良いのだけど自分の場合は逃避になってるような気がする。しかし走るのをやめたら仕事で成果を出せるかというとそうでもないし、遺伝的に糖尿病のリスクがあるので発症しないように死ぬまで走り続けるしかない。 2023 年は運動しつつ仕事やブログ書きでも一定の成果を上げたい。あともうちょいサウナに行きたい