Make組ブログ

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

【募集】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で執筆されました

デジタル世界は魂ゆえに残酷だよねって話

雑談です。

VRChatの世界でよく「最終的に魂が大事」という話になります。

デジタルの世界では自分が好きな姿になれるので、逆説的に魂(つまり中の人の考え方や面白さ)が重要になってくるというわけです。これはVRでないSNSでも似たようなもので、アイコンを絵にしたり加工した写真にすればいくらでも自分の姿を演出できちゃいます(とくにAIの時代はよりそうなるはず)。そうすると理想的っぽくて残酷なもので、「で?あなたは何が面白いの?」という身も蓋もない現実がやってくるわけです。

人間はどうしても「何者かになろうとする」ものだと思いますが、それがより残酷な形で現れてしまう気がしています。でも性格は変えようもないですし、対人スキルや絵を描くなどの技術を伸ばすのは大変です。そこで思想や「私はこういう人である」という宣言をしがちなのかなと思います。

記事の結論から言うと、「リアルに帰れ」のようなことは今さら言えない世の中で、どうしましょうね?という何とも歯切れの悪い話です。手垢の付いた話題でもあります。

それを認めざるを得ない

「私はこうだ」というのは、他から証明しなくても正義なので一番簡易です。「いや急に言うなよ」と言われても「もともとそう思っていた」、「自分でも気づいていなかった」と言えば済みますので証明しようがありません。もちろん本当にそういうケースもたくさんありますし、僕自身にも皆さんに言っていないことはあります。でもその証明できない点やセンシティブな点を隠れ蓑にして、無意識が思想という自己主張を求めている気がします。

重要なのは人類の無意識下でそれが起こっているってことです。

別に僕は否定したいわけでもないですし、本当に思いを打ち明けた人を小バカにしてしまう論調も良くないと思います。ですがいい加減「そういう現実があるよね」というのは皆んなで認めたほうが良いと思います。つまり「デジタルの世界は露骨に人間的(キャラクター的)な面白さを問われるし、人間は何者かになり認められたいと思っているし、無意識が思想や考え方という楽な方法でそれを実現しがち」ということです。ましてその思想が正しいと言われていて、時代に即したものであればなおさらです。思想といっても特別な信条だけでなく、よくあるMBTI性格診断の結果をSNSに共有するのもその一部なのかなと感じています。

つまり、私はこうである!という何かが、デジタルでは求められすぎているということです。

リアルの世界にはファッションや暮らしがある

そもそも人が無意識に何かを身につけたり、人から認められたいと思うのは自然なことです。それを否定すると有史以前の壁画から否定することになりそうです。

今までのリアルな世界ではファッションや所属によりそれが満たされていたように感じます。たとえば自分の好きな服を着れば、リアルの世界であれば自分らしさの主張に役立ってくれます。僕たち自身が「自己主張に役立てよう!」と思ったわけではなく、深層心理がそれを求め、知らないうちにそれを実感しているということですね。カッコいい時計や車なんていう古臭く感じるものが昔支持されていたのは、人々にはリアルしかなかったからなんでしょうね。だって、SNSに上げたいなら車なんてコスパが悪すぎます。200万円以上するのに、新鮮な投稿は1回しかできません。

他にも家族や地域社会みたいな帰属するものがあれば、そこで自分の重要さを感じられます。子どもがいれば誰だって特別になれます(僕にとっても何気なく興味ももたれない人間である僕の親が特別なわけですし)。

でもデジタルにそれらは持ち込めません。誰だって特別になれる安直なリアルでねっとりした何かは、ネットには持ち込めないわけです。

でもリアルに帰れって話したくない

こういう話をすると「リアルに帰れ」みたいな論調になります。でもぶっちゃけ無理じゃないですか?たとえば仕事のコミュニケーションすらSlackなどのチャットが中心になっているわけで、そこにもデジタルな自分は不可避な存在なわけです。ゲームをするにもネットが中心ですし、そこにはアカウントがあり、そのアカウントを中心としたコミュニティが生まれていきます。

いや、そういったSNSとはうまく付き合い、筋トレや丁寧な暮らし、リアルの交友関係を大切にしよう!みたいな結論にするのも嫌なんです。このネットで生きるときに、何を持って自分と感じ、そこに安心できるんでしょうか。デジタルネイティブな時代に、それを用意しておく必要を感じています。

少なくとも今のSNSを中心に自分を置くとかなり精神的に良くないです(皆んな分かってるとは思いますが)。「じゃぁあなたの好きなVRだって話ですか?」というとそうでもなくて、VRChatの住民もどこかしら病んでいたり、むしろこういった問題をこじらせてるきらいがあります。

じゃぁどうしましょうか?

知らんわ…。

いえ、要はこういうことです。

  1. 人間性などに関せず手に入る
  2. 個人の才能や研鑽を必要としない
  3. 金を払う難しさや参加する手間は要求してくる
  4. 自己主張ができたり、帰属を感じられたり、所有欲を満たす

そういうもの・ことがあると良いわけです。

でもNFT、VRやAIでも解決にはなってないので難しいですが、これからもっとデジタルネイティブな世代が増える中でそういった拠り所は必要ではないでしょうか。まぁ現状、自分を俯瞰してファッション的に思想を身に着けたり主張したり、SNSの世界が中心になって時間と脳のリソースを無駄にするのをやめよう、としか帰着しませんが。

この問題はもう少し考えたいです。

いや、こうやってこの記事を書いている行為そのものもデジタル・ネット社会における自己と思想の主張なのかもしれません。

気づいてしまったか。

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