Lycolog

紙の書籍の魅力といえばデバイスがいらないことや、パラパラ読めること、紙の質感があることなどがあると思う。しかしまだそれより先があるのではないかと思い、私はある一つの点を思いついた。現実世界の書店、とりわけオタク向け書店の存在だ。

とらのあな、メロンブックス、アニメイト、ゲーマーズをはじめとしていくつか存在するが、昨今では男性向けの書店が閉店する傾向がある。書籍は電子化により物理書店が減っているというのはオタク向けに限らず有名な話だが、実はオタク向けに限って言うと女性向けが比較的健在という話がある。例えば「とらのあな「ほぼ全店閉店」衝撃発表の理由とは？　店舗事業撤退の裏側を聞いてみた」という記事では、とらのあなが池袋の女性向け店舗だけ残したという話が出ている。

そこで私は一つの仮説を閃いた。男性向けと女性向けでは何か決定的な違いがあるのではないかということだ。女性は機械が苦手だから、みたいなのもゼロではないと思うが、どっちかといえば携帯小説など女性向けでも電子媒体は強い力を持つと思うし、創作分野においては女性のほうがデジタルに分を持つだろう。それでも紙媒体に何かがあるというのならそれは何だろうか？というのが気になったので私は早速スーパーに出向いた。

何故ならスーパーには女性向けの書籍が多いからだ。そもそも生鮮食品や生活雑貨が主たる商材であるスーパーに本がある。これは面白いことである。取り扱う必要性がないはずのものがあるということは売れているわけだ。

取り敢えず私は目を引いた雑誌を一冊手に取った。むしろこれだけアピールされていて買うなというほうがおかしい。今までは何となく気が引けて手に取ったことはなかったが、今回ついに手に取ってしまった。正直それが目的だったのでは？と言われたら、それも否定はできない。正直女性向け漫画にも興味自体はあった。というわけで集英社のりぼんを買った。恐らく小中学生向けの雑誌だと思う。男性向けでいえばコロコロコミックやコミックボンボン辺りが近い存在だろう。なおコミックボンボンはもうないらしい。通りで最近見ないわけだ。

さて早速だがまず表紙を見てみると付録がついていることが解る。推ししか勝たんうちわセットだ。電子書籍では物理的なおまけはつけようがなく、あっても精々期間限定アクセスのデジタルコンテンツ程度だろう。

デジタルおまけはサービスの会員登録に誘導されて迷惑な販促メールがくる懸念があるうえ、内容も微妙なので魅力が低いと思っている。しかし物理は違う。開けてみるとかなり本格的なセットになっていることがうかがえた。普通に出来がいいし、ちゃんと使えそうなレベルだ。アニメイトに売ってそうだし、買うと地味に高そうなやつ。しかし付録なのでタダに等しい。

他にも折り込みページがあって見開けたり、作品ごとに紙の下地の色が違ったり、最後のページがイラストカレンダーになっていたり、クロスワードパズルのようなものがあり、懸賞応募ができるなど、何かと作りがよく、普通に尊い作りになっていて感動した。表紙だけでも十分に尊いのに一体どれほど尊さを追求してくれるのかという感じだ。尊み秀吉である。男性向けのこのクラスの雑誌がどうだったかが記憶にもうないので、今度そちらも見てみようとは思うが、ここまでではなかった気がする。

まぁここまで気分が高揚してしまっているのは、単に初めて見るものだからというのもあるとは思うし、付録も今回たまたまついていただけという可能性はあるし、そもそもこれは児童誌であって大人が読むものではないので、まともに扱うこと自体に無理があるが、紙本の魅力の一つとして数えること自体はできる気はする。特に前述したクロスワードパズルのようなものは紙に書いてこそだと思うので、これはいいものだろう。デジタルのマス目にキーボードで埋めるのは味わいがない。

しかしこの本を買って思ったのは表紙がパステル調で、ポップで非常にファンシーで、これはすごく心をくすぐられる要素が強いなというところだ。電子だとあんまこれは感動しないかもしれない。たぶん画面のフレームの一部であって、視界全体に移りこまないからかもしれない。

ちなみに単行本などは場所の都合で電子で買っているのだが、雑誌は紙で買うようにしている。紙のほうが読みやすいのと、部屋に転がしておくと目に留まって何度も読むからだ。電子はアプリを開かない限り見えないので文化から隔絶された感覚になる。PCだと寝転がって見れないし、スマホは小さい、タブレットは悪くないがそのために持ちたくないというのが正直なところだ。

また紙の本を見ていると発見があることもある。例えば今回気が付いたのは発行情報だ。りぼんには『(毎月3日発売)第70巻第6号』と書かれている。これはほかの雑誌ではどうだろう？と思い、モーニングを見てみたところ、『(毎週1回木曜日発行)(4月25日発売)第43巻第22号通巻2383号』と書かれていた。

恐らく巻数は発行年数で、号数は発行月数だと思うので、りぼんの場合は70年目の6月号であることが解る。モーニングは週刊誌なので22週目ということだろう。通号の有無に関してだが、これはモーニングがもともと第三種郵便物であった名残であると思われる。第三種郵便物には逐号番号の記載規定があるので、その名残。りぼんは第三種郵便物だった事がないか、名残がないかのどちらかだろう。

またモーニングにある「毎週1回木曜日発行」という、毎週一回と木曜日発行がダブっていて違和感を覚えるのも、これも第三種郵便物の書式規定によるものと思われる。恐らく週の発行回数を明示するために意図的に書くように定めたものなのだろう。

さてここまで内容について一切触れていないが、内容についても面白く、傾向としてはコミカルな表現が多く、恋愛ものが多い。ファンタジーやバトル、ギャグ物は少ない印象を受けた。

読者層としては2002年のJMPA読者構成データを見る限り、13歳未満が64.6%で過半数を占め、次いで13～15歳が31.2%、16歳以上が4.2%、性別では女性が100%となっている。

対象年齢的には中学生以下が一般的で、中学生も多少読んでいる感じだろう。こういう場合、親が買い与えていると思われるので男性の読者比率が0%になっているのだと思う。とはいえ、内容的にはそこまで低年齢向けかというとそこまででもなく、振り仮名こそ振ってあるものの、その中身は意外と本格的だった。小学生がこの言葉やシチュエーションわかるんか？というのがそれなりに出てくる気がしたので、そこそこませている。登場人物は高校～社会人くらいなので、割と高めである。少年誌の登場人物が軒並み高校で時が止まっているのと比べると、これは対照的だ。男性向けだと、社会人が出てくるのは青年誌以降だろう。

絵柄は少女漫画的なのはそこまで多くなく、所謂萌え絵みたいなのが多めである。少女漫画チックなのはかなり少なく、どちらかというと萌え絵に寄ってきている。ディズニーとかも昔と比べるとそっちに寄ってきている気がする（アナ雪とか）ので、これは界隈の傾向なのかもしれない。基本的には男性でも普通に読める内容だが、女の子の夢みたいなのがふんだんに詰まり気味であるため、分別のつかない男児に読ませるのは妙な誤解を生んだりする可能性があり、微妙かもしれない。

作品的にはちびまる子ちゃんが連載されており、作者がすでにこの世を去った状態なのに連載が続いているのは凄いと思った。

process.exit()のラッパーだったり、throwする関数だったりして、戻り値がneverを取る関数で、TypeScript上、後続処理がデッドロジックになるものを作る方法。

確認環境

やりたいこと

process.exit()を書くと次の行以降がデッドロジック扱いされるが、これをやりたい。

問題点

普通に実装して型推論に任せてもうまくいかない。

例えば次の左図の関数の戻り値型はneverだが、右図ではデッドロジックとならない。

このように戻り値の型にneverを直書きしても機能しない。

解決策

左図のように関数そのものの型を作ると解決できる。右図を見るとデッドロジックになっていることが確認できる。

何のためにこれをやるか

別の関数から呼んだときに、呼び側の関数の戻り値型を正しくするためだ。下図はデッドロジックになっていない状態のときのものだが、処理が死なずに通り抜けてしまうのでundefinedが帰ることになっており、この関数の呼び下でundefinedだった時の処理を書く必要が出てきてしまう。

しかし、デッドロジック扱いになっていれば下図のように戻り値の型が期待した通りの内容になる。この関数がundefinedを返すことはないので、この状態を実現するために行っている。

関連記事

• TypeScriptでprocess.exit()ラッパーの後をデッドロジック扱いにする
  • オブジェクトをラップして、そのオブジェクトに型を付けることで解決している

依存ライブラリの関係でESLint v9への移行はできていないが、取り合えずFlat configに移行した。ESLintは7.9.0から8.57.0に更新している。

確認環境

Flat configになってからeslint:recommendedは@eslint/jsに移った模様。

元の設定

{
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:jest/style",
    "plugin:jest/recommended",
    "@lycolia/eslint-config",
    "prettier"
  ],
  "plugins": [
    "@typescript-eslint"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "project": "./tsconfig.json"
  }
}

やったこと

ESLintなど必要ライブラリのアップデート

npm i -D eslint @eslint/js eslint-plugin-jest jest prettier typescript typescript-eslint @lycolia/eslint-config

新設定の作成

eslint.config.jsを作成

extendsの設定

今までextendsに書いていたものはrequireでモジュールを参照してmodule.exports = []の配列の中に書いた。typescript-eslintとeslint-plugin-jestの対応が何とも言えない。なお、この状態だとtypescript-eslintが正常に動かない。

const eslint = require("@eslint/js");
const eslintTypeScript = require("typescript-eslint");
const eslintJest = require("eslint-plugin-jest");
const eslintLycolia = require("@lycolia/eslint-config");

module.exports = [
  eslint.configs.recommended,
  eslintTypeScript.configs.recommended[0],
  eslintJest.configs["flat/style"],
  eslintJest.configs["flat/recommended"],
  eslintLycolia,
];

設定が競合して都合が悪かったので、この時にPrettierの設定を削除しているが、Flat config化とは特に関係ないので無視してよい。

@lycolia/eslint-configは私が作っているカスタム設定だが、これは特に何もせずとも使えた。

.eslintignore対応

extendsしたオブジェクトの次にオブジェクトを記述し、そこにignores: []を追加し、その中に同じことを書いた。恐らく根っこの配列はESLintの設定オブジェクトの羅列で、最終的に後勝ちでマージされる様に出来ているのだろう。

const eslint = require("@eslint/js");
const eslintTypeScript = require("typescript-eslint");
const eslintJest = require("eslint-plugin-jest");
const eslintLycolia = require("@lycolia/eslint-config");

module.exports = [
  eslint.configs.recommended,
  eslintTypeScript.configs.recommended[0],
  eslintJest.configs["flat/style"],
  eslintJest.configs["flat/recommended"],
  eslintLycolia,
  {
    ignores: [
      'dist/*',
      'coverage/*',
      '**/*.d.ts',
      '/src/public/',
      '/src/type',
      '*.config.js'
    ],
  }
];

TypeScript対応

eslintTypeScript.config()でESLintの設定配列全体を引数としてラップし、languageOptionsの中身を移植した。旧設定にあったpluginsは公式のドキュメントを見る限り不要になっている模様。

const eslint = require('@eslint/js');
const eslintTypeScript = require('typescript-eslint');
const eslintJest = require('eslint-plugin-jest');
const eslintLycolia = require('@lycolia/eslint-config');

module.exports = eslintTypeScript.config(
  eslint.configs.recommended,
  ...eslintTypeScript.configs.recommended,
  eslintJest.configs['flat/style'],
  eslintJest.configs['flat/recommended'],
  eslintLycolia,
  {
    ignores: [
      'dist/*',
      'coverage/*',
      '**/*.d.ts',
      '/src/public/',
      '/src/type',
      '*.config.js'
    ],
    languageOptions: {
      parser: eslintTypeScript.parser,
      parserOptions: {
        project: './tsconfig.json'
      }
    }
  }
);

旧設定の削除

.eslintrcと.eslintignoreを消した。

ESLint v9対応

typescript-eslintが対応していないため、現時点ではできなかった。

変更差分まとめ

-{
-  "extends": [
-    "eslint:recommended",
-    "plugin:@typescript-eslint/recommended",
-    "plugin:jest/style",
-    "plugin:jest/recommended",
-    "@lycolia/eslint-config",
-    "prettier"
-  ],
-  "plugins": [
-    "@typescript-eslint"
-  ],
-  "parser": "@typescript-eslint/parser",
-  "parserOptions": {
-    "project": "./tsconfig.json"
+const eslint = require('@eslint/js');
+const eslintTypeScript = require('typescript-eslint');
+const eslintJest = require('eslint-plugin-jest');
+const eslintLycolia = require('@lycolia/eslint-config');
+
+module.exports = eslintTypeScript.config(
+  eslint.configs.recommended,
+  ...eslintTypeScript.configs.recommended,
+  eslintJest.configs['flat/style'],
+  eslintJest.configs['flat/recommended'],
+  eslintLycolia,
+  {
+    ignores: [
+      'dist/*',
+      'coverage/*',
+      '**/*.d.ts',
+      '/src/public/',
+      '/src/type',
+      '*.config.js'
+    ],
+    rules: {
+      semi: ['error', 'always']
+    },
+    languageOptions: {
+      parser: eslintTypeScript.parser,
+      parserOptions: {
+        project: './tsconfig.json'
+      }
+    }
   }
-}
+);

ここ5年間くらいTypeScriptを書くことが多いが、何故TypeScriptで書いているかについてメリデメを大まかに整理してみる。

メリットに感じている部分

1. 静的型付けがある
   • IDEで入力保管が出るのは便利だし、型ミスによるバグも見つけやすい
2. マルチプラットフォーム
   • OSの差を意識せず開発しやすい
3. VSCodeで書きやすい
   • IntelliJ使いたくないので…
4. テストコードを書くのが楽
   • Jestは扱いやすい
5. 大抵のことができる
   • CLIアプリからWebサーバー、Webフロントエンドまでこれ一本でできるのは嬉しい

デメリットに感じている部分

1. 依存地獄
   • node_modules配下が地獄になりがち
2. Node.jsの頻繁なバージョンアップ
   • TypeScriptはNode.jsに依存しているため、どうしてもこの部分に引っ張られがち（DenoとかBunとかそういうのは関知しない）
     • fsを中心に破壊的変更がよくあり、割合壊れる
3. デバッグがめんどくさい
   • C#だとデバッガを上げるのは楽だがNode.jsはめんどくさい
   • たまに素直にブレークポイントにはまってくれないこともあり辛い
4. 言語エンジンが重い
   • 入力補完や型情報の照会などはコードが肥大化するにつれ重くなる
   • そのためにキャッシュ機能があるようだが、ブランチを切り替えるとキャッシュされた型情報を見てくるせいでうまく動かないなど面倒

内容的には16タイプあるとのことで、恒例の16 PersonalitiesやMTBI的な奴だと思う。

コマンダーという結果が出た。卓越した統率力で勝利を掴む指揮者とのこと。全体の7%らしい。多いのか少ないのかはイマイチパッとしないが、7*16=112であるため、少なくはなさそうではある。

他にも「データや理論に裏打ちされた信念をもとに先陣を切り、チームを導きます。勝利を目指し、メンバーが協力・切磋琢磨するチームを作ろうとします。卓越した統率力で勝利を掴む」などと書かれている。

正直仕事ではそこまで能動的ではないが、ネトゲをしていたころは常にリーダーをしていたし、データ収集や理論調査もよくしていて、それらの結果を基にして戦略を立て多数のチームを導いたりしていたとは思う。ROでは臨時PTや、ギルドなど内輪のパーティーを主催したり、ECOでも大規模PTを率いていた。軸となる戦略は基本的に私が立案し、細かい部分は各人がやりやすいように空白にしておくことが多かった。他の人のプレーや自らの経験、データサイトの情報などを突き合わせ分析し、必要に応じていくつかの方針を出すこともよくあった。これは方針Aがダメでも、方針B→Cなどと転換させるためのバックアップ案だ。攻略するためには失敗を厭わず何度も挑戦したり、チャンスが一回しかない背水の陣においては何が何でも攻略を成功させるために仲間を鼓舞するなど、目標達成のためにとれる手段はとるほうだったと思う。

大まかな傾向としては、キッパリと両極端に寄っているようだ。意思決定は自分で行い、その根拠はデータを重視。人間関係は関係より成果を、リーダーシップはリーダーよりフォロワーにあるらしい。

まぁこれも私がネトゲの世界で生きてきたところによる部分が大きいだろう。私がやってきたネトゲの世界、つまりMMORPGというのはいわゆるSAOのような世界だ。実力が全てで人間関係というのは実力があって初めて成り立つ。とはいえ、人間関係がゼロというわけではない。例えばいくら強くても素行があまりにも悪い人物だと迎え入れるのは難しくなる。逆にいくら素行がよくとも実力がなければそれは難しい。そういう世界だった。勿論、その相手に芽があれば多少実力がなくとも育てるということはしていた。人材はそう都合よく現れないからだ。

FF14では固定パーティーに入っていたことがあったが、そこでは毎回遅刻してくる上に、都度「予習が面倒くさい」「勝つのがしんどい」などネガティブな発言をしながら、毎回スキル回しを間違えるヒーラーがいたことがあったが、結局私はこのパーティーを一ヶ月程度で抜けた。理由は単純で、攻略失敗の半分くらいがこのヒーラーのミスによるものだったからだ。しかも高頻度で無断遅刻してくるのでまともに練習時間も取れない。多少実力があるのであれば許容できるが、何の実力もないどころか、自分の弱さを据え置くような人間の相手はできない。そういうわけで私はパーティーを抜けた。

次に項目別に詳細な結果が出ていた。

まずはコミュニケーション傾向だ。端的に言うと「ぼっち、自己中心的、合理的、仕切り屋」というところがよく出ていると思う。しかし最後の問題解決スタイルについては団結に寄っており、孤立していないのが特徴的だ。

仕事の問題解決においては自分で考えるより有識者に聞いたほうが早いのと、「有識者に聞いた」というエビデンスがあると人からの信頼獲得が容易になりやすいという経験則からやっている。これは個人の考えより有識者の考えのほうが大抵の場合有益だからだろう。

次に働き方の傾向だ。この傾向では強い傾きが見られるものの、そこまで極端に振っていないのが興味深い。

チームへの姿勢では「競争・独力」に全振りだが、プロジェクトへの姿勢では品質に寄りつつも効率性も勘案している。因みに私は計画性があることをそれなりに好むが、基本的には無計画な人間である。人生は行き当たりばったり、作った計画は投げっぱなしというのはよくあることだ。「もっともよい解決策が見つかるまで検討を繰り返す」とあるが、これはよくやる。試行錯誤をすることで生まれたパターンは重要な財産である。引き出しが多ければ多いほど臨機応変に対応しやすいからだ。

問題解決は既存の理論や仕組みを活用することが多く、基本的には古臭いほうだとは思う。知る人ぞ知る人物による電撃的な新理論みたいなのは基本すぐさまには飛びつかない。また基本的には中長期的な視野で物事を見ることが多い。無計画な人間である部分からすると、この部分には矛盾があるが、そう考えるようにしている。実は私はかつてはミーハーな方で、新しいものにすぐ飛びつき、それの真贋を判断しないまま突き進むような人間だった。結果何が起きたかというと、様々な罠にハマることになったり、或いは罠にハマる人を観測してきた。勿論そんなのは経験則であり、他の事例には適用できない可能性はある。しかし私は人生経験上、他の人より遥かに多くの経験を積んできている。例えばネトゲでは膨大な数の臨時・野良PTに参加し、実社会でもSESを通してかなり多くの案件や現場に参画した経験がある。根本の仕事もそれなりにしており、バイト経験も豊富だ。プログラミング言語やフレームワークも経験数は多いほうだと思うし、世の中の各種サービスもかなり使い込むほうだ。つまり他の人より多く物事に触れることによりある程度確定的な視野を持っており、その結果、短期的ではなく中長期的に物事を俯瞰したほうがより良いと考えている。

衝突への向き合い方は基本的に自分の意見を主張することが多い。ただ主張しても受け入れられないことは自明なので、まずは相手の意見を優先し、徐々に自分の意見を染み込ませていくという手法をとることが多い。これは多くの場合、長期戦になるので粘り強く行う必要があるし、それをしても価値があることにしかできないので、基本的には折れる回数のほうが多いかもしれない。

次はストレスの傾向だが、楽観的のことだ。

実際私は楽観的で、楽観的過ぎるために目標を忘れることさえよくある。目標を達成するために圧力をかけると自滅するので、私の目標は達成できない場合が少なくない。ネトゲでは仲間と一緒に目標を立てていたが、私生活では割とズタボロである。仕事では目標を立てることがあんまりないので何とも言えない。

また、根はネガティブで暗いのだが、基本的に物事はポジティブに考えることにしている。大抵のことはポジティブに考えられるし、そこから新しい発想が生まれることもあるからだ。またストレスが継続する場合は元凶を辿り、そこの根を断つようにすることが多い。その過程でいろいろ発見があり楽しいからだろう。

最後に理想の働き方については、これまでの総集編といった感じだ。

良くも悪くも昭和の価値観という感じで、統率性を望むのだろう。全員が全員別のことを話しているとチームがまとまらない。個人で仕事をしているのなら好き勝手言えばいいと思う。

意思決定についてはデータ志向だが、そのデータが捻じ曲げられている状況は好ましくない。例えば子育て支援をすることで子供が増えるみたいな、どこに根拠があるのかよくわからない言説とかだ。そういうデータではなく、まともな信頼できるデータなら信用する感じだ。