Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

ガリが市営ジムに1年通って体重を7キロほど増やした

やったぜ!って話です。

もともと体重49kgの体脂肪率5%(誤差の範疇なので5%になる)だったのですが、今は56kgくらいに増やせました。

今が人生で一番健康だと思います。

僕は生まれてから30年間ずっと痩せてました。どうしても食えないし、太らないし…、と言うと「ズルい!」みたいな反応をもらいますが当人は真剣に悩んでいました。だってさ、すぐ風邪を引くし寒いし、貧血起こすし虚弱体質だったわけですよ。結構大変なんですよ。機能性ディスペプシアとか逆流性食道炎とかも患ってましたからね。

何度も体重を増やそうとしたもののうまくいかず、やっとうまくいったという話です。良かった。

週2ジム

まぁ何ていうか結局は運動が大事でした。

胃腸科のお医者さんに言われるたびに思いました、「ストレスを減らして運動しろってしか言えないのか!」って。「こちとらストレスと運動不足で稼いどんじゃい!」って、でも発想が逆なんですね、現代人が無駄にストレスを抱えて運動してないのが異常 ということです。運動しなきゃ!じゃなくて、椅子に16時間座ってるのが人類にとっておかしいということです(ハッザ族もよく歩くらしいですし)。

運動というとカロリーを消費するイメージがありますが、まず体力と食欲が必要なので意外にも運動が必要でした。昔、プールに通っていたこともあったのですが、そのときは太りにくかったので筋トレが良いと思います(逆に痩せたいならプールってめっちゃ良いと思う)。

ジム
1年ほど週2でジムに通い、しっかり筋トレをしました。友だちと「ダイエット」Discordチャンネルで励ましあいながら1年ジムに通っていました。まぁ、週2回のうち1回がプールだったり、宅トレだったりのときもあります。あんまり目標を設定しすぎると辛いので、無理しないってやつです。一応、Apple Watchと「俺の筋トレ記録」というアプリで計測しています。

だいたいベンチプレス、チンニングやラットプルダウン、レッグプレスなどの一般的な種目をやっていました。デッドリフトとスクワットは難しいのでやってません。基本はマシントレーニングにするのが、安全で良いと思います。でもベンチプレスは楽しいのでおすすめ。

ジムは市営のジムなので、1回150円のところか200円のところ。なので月に1200円ほどです(市営って良いですね)。ただそれゆえにモチベの管理が大変でした。市営ジムだと「高い金はらった!」って感覚がないので、個人の努力次第という感じ。

たったの週2回だけどがんばって続けたよ…。今は週1.5回くらいの怠けぶりですが、まだ続けています。

食べる

食べました。

始めたのが23年の4月くらいからで、計測は途中からですが線形回帰しています。

体重の推移

途中で落ちているのはインフルエンザになったときです。

結局は食べないと痩せるのはまじです。正直、ジムに通うよりもこっちのほうが大変。ただ食べられない人間が無理に食べると嫌になるものです。

ガリが太るポイントは以下です

  • 食事を抜かない
  • まじでちょっとずつで良いから増やす(おかわりとか、間食とか)
  • カロリー計算をしすぎない
  • 乳酸菌入りのエビオスを飲む

食事を抜かないなどもそうですが、なるべく小さくカロリーを稼ぐのが重要でした。「二郎食うぞ!」となるとそのさき数日体調を崩すので、いたって普通の食事をちょっと気持ち多めに食べました。筋トレしてるのもあり、食えるときは食えるようになってくるって感じです。

とはいえガリにとって 最初の数カ月は筋トレというかリハビリ です。まず健康的な人間になるために2、3ヶ月はかかった感じなので、焦りは禁物ということ。最初はモチベが高いので無駄に色々やったり頑張りすぎるけど、体が追いつかないからやめとけ。

あと意外にも痩せる人間ってカロリーに敏感だったりするんですよね。なので逆にあんまり気にせず、とりあえず食いたければ食うというのが良いと思います。僕もジムの帰りにビッグマックセットにマックフルーリーを足したりできるようになりましたが、とりあえず太るターンのときは食いたいだけ食うのが良いです。

ダーティバルク最高!

結果どうだったか

まじめな話、運動も食事も楽しくなったし、人生がだいぶ好転しました(ギラギラ輝く目)。というか以前は食事が義務的な感じで、楽しめる余裕が少なかったのですが、今は食事にもわりと興味を持てています。

あと外に出ても疲れにくいし、体の芯まで冷える感じがしないなど、今まで自分が「そういうもん」と思っていた不快感が改善しました。まるで老人の悩みが解決したみたいですが…。

とはいえ遺伝子には勝てない感じがあって「食えないものはいまだに食えない」感じがします。友人たちを見ていると今の僕以上に普通の感覚で食っていて、「あぁ、僕は努力してやっと普通の成人男性になれたんだ」と思いました。遺伝子ってすごいですね。

というわけで僕に「痩せてて良いですね」とちょっと皮肉っぽく言っていた人たち、僕はがんばって体重増やしましたし、「1年間、週2回ジムと本気でダイエット」はできたよ!と伝えたいです。体質の改善がどれだけ大変かは僕もよくわかります。一緒にがんばりましょう。

ぜひ 「脚太くなったね!」 とか「背中ぶ厚くなったね。背中の種目何やってる?」とか言ってくれたほうが嬉しいです。

執筆:@hirokiky
Shodoで執筆されました

【募集】DjangoCongress JPの開催地を募集します

こんにちは。今日は少しお願いがあります!

DjangoCongress JPの開催地・会場を募集しています。

例年開催しているDjangoCongress JPですが、次回の開催地と会場がまだ決まっていません。とくに東京以外の場所で「ぜひここでやろう!」という方を求めています。会場スポンサーとしてトーク枠を1つ提供しますので、ぜひ採用や会社のブランディング等にご活用ください。

Djangoはユーザーも多く、業務で使われることもたくさんあるWebフレームワークです。その知見を定期的に交換したり、仕事の紹介ができる場は必要だと思っています。また今回はDjangoに限らず、Pythonでの非同期Webというトークも募集したいなと目論んでいます。

募集要項

背景としてはこういうものです:

  • 東京以外でもイベントをやりたい。以前は長野でやりました
  • 東京以外で開催する場合、現地の熱意ある人(現地スタッフ)が必要
  • DjangoCongress JPは会場のスポンサーのみ募集しているため会場費はほとんど出せない

ありがたいことに東京では会場を貸してくださる企業さんなどはいらっしゃるのですが、東京以外だと少ないのが現状です。東京ばかりでイベントがあるのって悲しくないですか。この機会にどうでしょう?!

会場に求めるものとしてはこのあたりです:

  • 時期は2025年2月ごろ
  • 会場のキャパシティは多くて100人くらい
  • トラック数(部屋数)は理想で2つ、1つでもOK
  • Wifi、電源、投影用のスクリーンがある
  • お昼ごはんを食べに行く場所が近隣にある(会場でのランチ提供はしないため)

応募方法

hirokikyもしくはdjangojaのTwitterアカウントか、django-jaのDiscordにご連絡ください

最後に

お願いばかりになって恐縮ですが、DjangoPythonを今後も盛り上げるためにご協力ください。

もちろん会社の採用に役立つとか、ブランディングになるとかもありますが、一番大切だと思うのはコミュニティへの還元です。僕たちは常日ごろ、オープンソースの恩恵を常に受けています。コミュニティ運営やスポンサーシップというのはとても大切な貢献(コントリビューション)だと僕は思っています。とくに今はコロナ禍が終わって、またもう一度そのコミュニティを作り直す大変な時期です。

ぜひ、賛同してくれる方はお力を貸してください!

執筆:@hirokiky
Shodoで執筆されました

結局、migrate機能ってなぜ必要なの? WebフレームワークのDBマイグレーション機能の意味を解説します

DjangoなどのWebフレームワークにはマイグレーションという機能が搭載されています。ですがこのマイグレーションという機能の必要性が分かりにくい(いまいちピンときていない人がけっこう多い)ので背景を踏まえて説明します。

マイグレーションとは何なのか?

Webフレームワークのマイグレーション機能はDjangoRailsに付属している機能です。

そもそもDBマイグレーションは、すでに本番環境等にリリースされたデータベースを破壊せずに、アプリ側で使いたい新しいテーブルやカラムを追加(もしくは変更、削除)することです。毎回データベースをすべて削除して1から作り直してしまえば「DBマイグレーション」は考えなくて済みますが、そうするとユーザー情報や過去に書いた記事などがすべて消えてしまいます。

そういった問題を解決するため、Webフレームワークなどが「マイグレーション」という機能を提供しています。ですが便利すぎるゆえ、逆になぜ必要なのかも分かりにくくなっています。フレームワークのモデルを書き換えると、なぜかマイグレーションファイルを作ってマイグレーションを実行しろと言われますね。マイグレーションファイルが作れなかったり、なぜかデータベースに適応できなかったりトラブルが起こったりもします。そこで…

マイグレーション、要らないのでは?

消したほうが楽なのでは?

など言われてしまうのですが、そうではありません。めちゃくちゃ便利ですごい機能なんです。

この記事ではマイグレーション機能がない世界でのデータベースの運用を説明し、改めてマイグレーション機能の必要性を理解しようと思います。

マイグレーションがない世界へようこそ

マイグレーション機能がない世界を考えてみましょう。

まずモデルとしてはこういったユーザーの情報を考えます。

class User(models.Model):
    name = models.CharField(...)

無事にアプリを本番リリースし、以下のようなデータベースが動いていると考えましょう。ユーザーのテーブルがあり、IDとユーザー名が管理されています(IDフィールドは勝手に作られます)。

このテーブルがアプリ上のUserモデルに対応しているわけですね。

ここで新機能として「自己紹介欄」を追加したくなりました。Djangoのモデルで言うと、この2つ目のフィールドを追加した状態にします。

class User(models.Model):
    name = models.CharField(...)

    # ↓↓↓ このbioをアプリに追加 ↓↓↓
    bio = models.CharField(...)

この場合、最終的には以下のようなテーブルがデータベース上に必要となります。最初は bio に何も入っていなくても良いですが、ユーザーが好きに自分のことを書けるようにしたいわけです。

さてプログラム的には bio というカラム(モデルのbioフィールド)を利用するよう書き換えたわけですが、今すでに存在しているデータベースには bio というカラム(フィールド)がありません。

プログラム上は bio を使うように書き換えたのに、本番データベースにはそのカラムがないわけです。これは困りました。データベースを一旦削除して再度作り直すと、せっかく集めたユーザー情報も消えてしまいます。

ここで以下の3点がポイントになります:

  1. データベース(RDB)側のテーブル定義を変更しないといけない
  2. プログラム上の「Userモデル」等を書き換えても自動的にデータベースは変わらない
  3. データベースを変更しないままアプリがbioを使おうとするとエラーになる

これはMySQLPostgreSQLなどのリレーショナルデータベースがテーブルの定義(データ構造)をしっかり決めてデータを管理するデータベースだからです。アプリ側で bio というデータを使いたいとなった以上、データベースに変更が必要です。

データベースにカラムを追加するにはどうすれば良いでしょうか? 正解は ALTER TABLE ... ADD とカラムを追加するSQLをデータベースに実行することです。

このSQLを実行するとデータベース上に bio カラムが作られ、bio を使うアプリをリリースしても正常に動作するというわけです。これがDBマイグレーションの基本的な考え方です。

SQLを管理する

さてこの ALTER TABLE ... ADDSQLを実行すべきなわけですが、アプリを書き換えたタイミングでこのSQLを用意しておく必要がありますね。

class User(models.Model):
    name = models.CharField(...)
    
    # ↓↓↓ このbioをアプリに追加した時点で、更新用のSQLが必要になる ↓↓↓
    bio = models.CharField(...)

そこでこの変更を加味して、SQLのファイルを作っておくことにしました。こうすれば他の人が見ても「リリース時にSQLの実行が必要なんだな」と分かりますし、自分でも思い出せて便利ですね。

0002_user_bio.sql というファイル名で作っておきましょう。

ALTER TABLE user
ADD bio VARCHAR(200) DEFAULT '' NOT NULL;

このSQLmigrations というディレクトリーに入れておくことにしました。ついでに、データベースを作る際に実行したSQL0001_initial.sql として置いておきましょう。

migrations/
    - 0001_initial.sql
    - 0002_user_bio.sql

これでOKです!

こうしてデータベースの変更をSQLとして管理し、Webサービスを運営していくことができました。

自前の管理で起こり得るトラブルは何?

実際に昔はWebフレームワークのDjangoにはマイグレーション機能がなく、このようにSQLを保存して管理したりしていました。SQLで管理していれば良いほうで、その場その場でSQLを書いて間違えてしまったりもありました。

どういった問題が起こるのでしょうか。こういったことが考えられます:

  • どこまでマイグレーション用のSQLを実行したか分からなくなる
  • モデル(テーブル)の変更内容と違うSQLを書いてしまう
  • 書くべきSQLがデータベースの種類ごとに少しずつ違う
  • そもそもDBマイグレーションを管理しておらず各データベースの状態が分からなくなる

昔はけっこうこういった問題があり、うんうんうなりながら何とかしたわけです。

そこで登場するのがマイグレーションという機能です。Djangoでは先に South というマイグレーション用のツールが登場し、一般的に使われるようになりました。その後、このSouthの開発者を中心にDjangoマイグレーションという機能が組み込まれていきました。

マイグレーション機能が解決することは?

マイグレーション機能のポイントは以下です:

  1. モデルの変更を検知して、自動的にマイグレーションファイルを作成する
  2. マイグレーションファイルからSQLが作られ、データベースに変更が適応される
  3. データベースごとにどこまでマイグレーションを実行したか履歴を管理する

さきほどSQLで管理していた migrations/0002_user_bio.sql などは migrations/0002_user_bio.py というものに置き換わります。ですが内容はまったく同じです。このマイグレーションファイルを自動で生成してくれるので、自分で適応すべき変更差分を書く必要がありません。また、使っているデータベースの種類に応じて、SQLも適切に書き換えてくれます(SQLを直接生成しないのはこのため)。

またDjangoマイグレーション機能はデータベース自体に「どこまでマイグレーションを実行したか」の履歴を保存しておいてくれるので、 python manage.py migrate と実行するだけでデータベースごとに必要な変更が取り込まれます。django_migrations という自動で作られるテーブルで管理されており、マイグレーションを実行したタイミングで適応済みの履歴も自動で更新されます。

つまり、SQLで管理していたような作業をすべて自動でまかなってくれるということです。Djangoではこういった仕事が必要となることを見越して、機能として提供しています。

おさらいするとこうなります:

Djangoマイグレーション系のコマンド

ここでDjangoが提供しているコマンドを見てみましょう。先ほどSQLで管理していた例を思い出しながら、各コマンドが何をしてくれているかを理解しましょう。

makemigrations

モデルの変更を検知してマイグレーションファイルを作成します。マイグレーションファイルは上記したような「変更を管理するSQL」と似たものです。

たとえばユーザーに bio のフィールドを足すと、 migrations/0002_user_bio.py のようなファイルが生成され、これが ALTER TABLE ... ADD bio ... というSQLに相当します。

migrate

DBマイグレーションを実行します。対象のデータベースからまだ適応されていないマイグレーションファイルを検知して、マイグレーションファイルからSQLを生成し、データベースにSQLを適応します。

migrate --plan

現在対象のデータベースに対して、これから実行されるであろうマイグレーションの内容を表示してくれます。

migrate --fake

マイグレーションの変更を適応せず、実行履歴のみ「適応したこと」として更新します。すでに別の方法で変更が取り込まれている場合などに実行します。

showmigrations

管理されているすべてのマイグレーションと、どこまで適応されたかの状況を表示します。

sqlmigrate

指定されたマイグレーションファイルをSQLにして表示します。SQLで管理する例であげていたような ALTER TABLE ... ADD などのSQLです。対象になっているデータベースに応じてSQLの方言もあわせます。

squashmigrations

指定された複数のマイグレーションを1つにまとめます。まだ適応されていないマイグレーションが複数ある場合に、このまとめられたマイグレーションを実行するだけで済むようにします。

他にも湧いてくるであろう疑問と答え

話としてはだいたい終わりました。

ここで、これまでの説明を踏まえて湧いてくるであろう疑問に答えておきます:

  • まだ本番データベースなどを管理していないのに migrate しろと言われるのはなぜ?
    • ローカルで開発中に使っているデータベース(SQLite)などの更新に必要です
  • 本番にリリースしていない場合、マイグレーションファイルは必要?要らなくない?
    • ローカルのDBの管理もあるので使っておくと良いです
    • 慣れないうちはマイグレーションファイルを下手に削除したりいじったりしないほうが無難です
  • makemigrations したときに one-off default どうこうと質問されるのは何?
    • カラムを追加するときに既存DBでの値をどうするかを聞かれます
    • フィールドにデフォルト値等があればその値になりますが、ない場合は一時的なデフォルト値が必要と言われています
    • 今回の bio であればデフォルトで空文字やNULL可能としておけば自動で空文字やNULLが入れられます
  • 開発中にマイグレーションファイルが大量にできてしまいます
    • squashmigrationsコマンドでまとめることができます
    • 慣れていれば、開発ブランチで適応された変更をまとめたマイグレーションに自分で作り直すのも可能です(ローカルのSQLiteの変更履歴も操作が必要です)
    • ファイルの数が極端に多くなる場合は、もう少しモデルの設計をじっくり考えてから開発したほうが良いかも
  • 本番データベースにマイグレーションを適応するタイミングはどうすれば良い?

おわりに

今回はざっくりとDBマイグレーションについてとWebフレームワーク等が提供するマイグレーション機能の意味を説明しました。Webフレームワークやツールが便利になるごとに、なぜそれが必要なのかは逆に分かりにくくなってしまいます。ですがこうして背景を一つひとつ理解していくことで、その意味をお伝えできると嬉しいです。

執筆:清原 弘貴 (@hirokiky)、レビュー:清原 弘貴 (@hirokiky)
Shodoで執筆されました

正しい生き方を求めた結果が今なら最初から自分の好きに生きたほうが良かったのでは

っていう時代になりつつあるのかなと感じるこのごろです。

というか皆んなインターネットに疲れてしまった。

まぁこれは完全に僕の戯言なのでデータがどうこうというわけではないです。エッセーでごわす。

何だかインターネットに疲れてしまって、インターネットにある「正しい生き方と価値観でなきゃいけない」的な感覚がしんどくなってきている。インターネットで色々な価値観に触れたり、他人の言葉を聞くと自然と正しさを模索してしまうものです。というか、そうしないと炎上してしまう的な背景もあるのでそうなりがち。とくに2016年とか2017年くらいから、よりインターネットなどで「正しさ」的な価値観が広まった感覚があります。僕はTwitterが好きなので、タイムラインの並びが時系列順じゃなくなったころからその感覚が強い。タイムラインが「自分のチャット」から「世界の意見」になったのも大きいのかもしれない。

また感染症や戦争や大地震と、インターネットを見ていて心が疲れてしまう要素が最近は多い。知れるのはとても良いことだけど、付き合い方を考えないと自分の心が潰れてしまう感じがする。というか潰れそうな人を多く見ている。インターネットでの振る舞いを頑張ったが結局「手に入った世界がこれか」という気持ちが僕にあります。特に最近Twitter(現在はX)の居心地が悪く過激なのもあって、色々と自分を律してインターネットを頑張る意味とは何かと虚無になっている。

クズ的なコンテンツもウケている肌感があって、マンガだとヤニ猫、地元最高!があったり、芸人だと粗品、カミナリ、金属バットあたりもウケている感じがします。もう皆んな何だか疲れちゃって、そういう奔放な人でありたい欲求が高まってるのかもしんない。それこそ数年前のTwitterでタバコと言えば嫌煙家が必死に叩いていた印象があって、僕の友だちなどもすごい剣幕で否定していたのを覚えている。僕は人前では吸わないものの喫煙者なので、友人にキレられるのはすごく辛かった(直接僕にキレてないわけだが)。最近はもう分煙が進みまくったおかげで嫌煙家も目につかなくなっているし、タバコを吸う猫がコンテンツとしてウケているのは何かの転換を感じる(キレ散らかしてたのに何やねんという気持ちもちょっとある)。

ここでタイトルの仮説なんだけど、もう皆んなインターネットで正しく生きることに疲れてしまって、平和なクズで良いじゃん的な空気感に憧れてるのかもしれない。感覚的には70年代のヒッピームーブメントに近い。他人にちょっと迷惑はかけつつも、まぁお互い様だよね的な世界観。もちろん個々への配慮みたいなのは大事にしつつ、でも過剰に気にしたり心が疲れるのは違うよねって流れ。10年前くらいに僕は成人漫画のレビューをTwitterに書いていたのだけど、知人に苦言を呈されてやめてしまった。あれを続けるくらいのメンタリティが欲しいなという気もしている。いや立場上、もう難しいかもしんないけど。

結局ここで言いたいのは、皆んなが求めていた配慮のある世界みたいなのも、まずは自分の弱いところとかダメなところを認めて許し合うことから始めるべきだったのかもしんないってことです。たとえばだけど男性の中にある生きづらさの共有とか、もっとされてほしかった。ここ数年は他人にそれをしなきゃと思ってたけど、自分がないがしろになってしまったという。そしてインターネットに疲れてしまった。だからクズである自分を認めてほしいな(クズなコンテンツって良いなと感じる)ということです。まぁ、完全に仮説というか、僕がそう感じているだけなのかもしんない。

まぁだからこそ他人への配慮とかは大切にしつつ、自分も好きに生きて、それでも良いねって思いあえる世界を作りたいねって話でした。All You Need Is Loveってことで。

執筆:Kiyohara Hiroki (@hirokiky)
Shodoで執筆されました

名を売るには人類はアホすぎる

人間は名を売りたいと思うものの、人間の脳を考えるとその席は少すぎるし消えていくという話です。

人生があるのなら、自分の存在価値を最大限大きくしたい、と思うのは野心のある人なら自然なことに思います。誰かに自分の名や存在を知ってほしいという感情は誰の中にもあって、とくにクリエイターや起業家、エンジニアであれば持つことを推奨されるまであるものです。

でも最近僕が思うのは、人類の脳の容積に対して「知ってほしい人」の数が多すぎるということです。これはある意味で需要と供給と言えるかもしれません。存在を知ってほしい人間の数が需要であり、人が認知・記憶できる存在の総量が供給ということで、需要に対して供給が追いついていない状況と感じるということです。

僕も本を出したり、登壇したり、自分が作ったサービスをビジネスにしたりとなかなか幸運な人生を歩ませてもらっています。ですが一歩外に出たり、違うコミュニティに参加すれば全く知られてはいないものです。それは著名人にとっても同じで、ナーシャ・ジベリという偉人レベルのプログラマーもほとんどの人は知らないでしょう。僕もあなたもクリケットの神様であるサチン・テンドルカールのことは全く知らないと思いますし、イギリスの人は大谷翔平をたぶん知らないでしょう。ひろゆきは今、日本で有名ですが、数年前まではオタクしか知りませんでしたし、数年後には大抵の人が忘れるでしょう。

もちろん「何か世界に変化を起こせるんだ」という感覚と希望は重要ですし、それは事実です。ですがここで言いたいのは、そんな存在すら人々の記憶には無限に残らないということです。世界に爪あとは残せるかもしれませんが、その存在の広まりには限界があり、記憶からは薄れていってしまいます。人間の脳の物質的な容量と、動物の性質としての興味・関心の量が決まっているのでこうならざるを得ません。遡って考えてみると、僕たちが憧れた存在というのも、どうやら僕が思うほど周りは熱狂的に思っていないということです。スティーブ・ジョブズは宇宙に穴を開けた存在ですし尊敬していますが、今の若い人たちはあんまり知らないようです(イーロン・マスクのほうが知られているっぽい。悲しい)。もちろんジョブズ大谷翔平というレベルになれれば幸せなことですが、そもそもそうなる確率を夢見るのはあまりに残酷ですし、時代背景や遺伝、運も大いに関係します。

たとえば僕を起業家と呼んでみましょう。仮に会社が上場すれば「世界を変えた」という感覚は味わえるかもしれません。ですが2023年に上場した企業の名前を1つでも知っているでしょうか。まして創業者の名前を知っているでしょうか(僕は知りません)。残念ながら、僕たち起業家が夢見る未来というのも、僕たち起業家にとってすらどうでも良いものなんですね。もちろんそれを機に起業家セミナーに呼ばれたり、Abemaの討論番組にでも出れば認知されていくでしょう。でも安部敏樹と肩を並べWikipediaにページができても、安部敏樹ですら大多数にとっては「見たことはあるかも」という世界です。

人間の脳の限界と、脳が得たい認知を考えると小さな村を想定せざるを得ません。小さな村ではすべての人間がお互いをよく知っています。お互いの存在を大切に思い、受容しています。死んだあとも先祖として知ってくれるかもしれません。それはやっぱり狭い世界で密に交流するからこそ生まれるものです。僕も近所で子どもの存在を通して「〇〇ちゃんのパパ」と認知されていますし、一緒に食事に行ったりもします。

こう考えると僕のような野心家が最も嫌う「地元では有名なやつ」タイプこそが幸せに生きる方法なのかもと思ってしまいます。というよりも、どんな有名人もあるグループに認知された「地元では有名なやつ」でしかないという結論です。起業家・テックコミュニティにしろセレブにしろ、結局は「ある分野で認知されている人」という域は絶対に出られないのでしょう。なぜならその人達を認識したり、尊敬したりする人たちが共通の特徴をもつ集団だからです。本当に普遍的に知られているのはキリストとコカコーラくらいじゃないでしょうか。

昔、母が言っていました「どこぞの社長や工場の偉いさんやろうがパチンコ屋にきたらただのオッサンや」。これはこの話の本質をつく言葉です。僕の生まれ育った地域は工場などがたくさんあったので、工場の社長や偉いさんなどもパチンコ屋に行くわけですね。そこで周りの人なども妙に気を遣ったりするわけですが、パチンコ屋にきた以上そんなことは関係ない(従業員でもない限り)という話です。Awitchの「てか、お前誰?」に並ぶパンチラインだと思います。逆に言えば僕たちはよく分かってもいないのに「すごいらしい」で反応的に評価すること(ハロー効果)をやめるべきなんでしょう。

まとめると有名になりたいと思っても「その界隈では有名な人」の域はほぼ脱出できないということです。人間の記憶や興味の量には限界があるので、「ある特徴をもった集団に知ってもらう」のが限界だろうということでした。逆に言えば皆んなキリストやコカコーラにはなれないので「知ってる人が知ってる人」になって幸福を感じれば良いですし、興味のない相手には「お前誰」と言ってやれば良いのでしょう。

絶望と安寧が入りまじった悟りになりましたが、「それでもやりたい内在する何か」こそが大事なことなのかもしれません。

執筆:清原 弘貴 (@hirokiky)
Shodoで執筆されました

トムソーヤの冒険の記憶

小学生のころトムソーヤの冒険を読みました。何かよく聞く名前だし、名著らしいし読むかという打算的な気持ちもあったと記憶しています。

読んでみると、思ったより冒険はしないんですね。というよりも僕が期待していたのはもっと壮大な「インディージョーンズ魔宮の伝説」くらいの冒険なのですが、トムソーヤは「地元」で話が止まります。だからこそ子どもにとっての「冒険」であったり、大人の恐ろしい世界を垣間見たり、子どものずる賢さや素直さが読めて面白いわけです。

そんなちょっとガッカリした記憶はあるのですが、それでも記憶に残っているのが、ペンキを塗る話と自分の葬式の話です。ペンキの話は、嫌な仕事を楽しいフリをしてやって、他人にやらせるという有名なやつです。読んだときは「すげぇ!」と思った記憶があります。そんなことして良いの?(良いんだ!)という感覚です。この有名な話が僕の記憶にもちゃんと残っているというのが、自分事としても感心してしまいます。当時、タイトル以外のネタバレは食らっていない状況だったので、新鮮な気持ちで読んで面白かったんでしょうね。

葬式の話も「自分が死んだときの周りの反応を見たい。自分の大切さを分かってほしい」という純粋な欲求と好奇心をくすぐられた気がします。というよりもSNSを中心にしたメンヘラ的な感情ってこれなんじゃないですかね。その感情を理解して書かれているし、それを面白いと子ども(の僕)も思うもんなんですね。

だからマーク・トウェインはすごいんだ、と今になってドヤ顔で言ってやりましょうか。
名著を褒めとけばカッコいいみたいなんがありますが、あれやってる人ダサいのでやめとこう。

執筆:Kiyohara Hiroki (@hirokiky)
Shodoで執筆されました

32歳になりました

0x20歳、というネタをやる歳になりました。

Shodoという事業でやっていますが、0を1にできたのでこれからは1を100にしていきたいです。

でも期待以上には答えたいじゃん
高いハードルはダッシュをしてハイジャンプ
出る杭がもっと出て黙らす外野

Dripping' Life / ピーナッツくん

open.spotify.com

過去分

blog.hirokiky.org

blog.hirokiky.org

blog.hirokiky.org

blog.hirokiky.org

blog.hirokiky.org

執筆:Kiyohara Hiroki (@hirokiky)
Shodoで執筆されました