1月の頭くらいにナッシュを解約した。詳細は[ナッシュを解約して個人情報を全て削除してもらった](https://yuheinakasaka.github.io/gialog-diary/articles/30)に書いてある。

現在はフルリモートで働いており今までは平日の昼食は全てナッシュを食べていた。ご飯は家で炊いたもの、おかずはナッシュという感じ。この生活は1年以上続いていたわけだが、そのおかず部分がなくなってしまったので新たな移転先を考えなければならなくなった。

自分が宅食に求めているのは下記。

- それなりの味
- それなりのボリューム
- それなりの値段

過去いくつかtrialしてきた感じからいうと味に関しては正直どの宅食もそれなりに美味い。少なくともコンビニの濃すぎる味付けが苦手な自分にとっては十分マシ。

ボリュームはどの宅食もヘルシー指向を掲げていたり高齢者向けのものが多いのでどれもやや少なめ。とはいえ自分の場合は身長173体重が53~54kg前後の痩せ型で1日米1合食えれば十分なのでどこも量で気になったことはない。

値段に関しては500~800円くらいが相場なので決して安いわけではない。外食よりは安く、コンビニ弁当と変わらないくらいの値段。

宅食は安いというイメージの人も中にはいるかもしれないがそれは違って、基本はヘルシーなものを美味しく安定して家で手軽に食えるという点がメリット。ヘルシーなんて興味ないという人はそもそも宅食は使ってもあんまりメリットないと思う。

今回は上記3点を軸に宅食比較サイトなどを漁っていたところヨシケイの「[夕食ネット](https://www.you-shoku.net/)」が目に止まった。

<img width="747" alt="スクリーンショット 2023-02-02 11 44 49" src="https://user-images.githubusercontent.com/1421093/216218570-df45ed5e-f87d-4bd9-8f93-6e8271b5e69d.png">

夕食ネットの何がすごいかというと値段の１点に尽きる。上述した通り他の宅食は1食500~800円くらいだが、夕食ネットのシンプルミールは配送料込みで1食380円だ。コンビニ弁当と比較しても安い。学食みたいな値段。

経験的に宅食はどこも味もボリュームも変わらないと知っていたので値段が飛び抜けて安い夕食ネットは気になる。とりあえず夕食ネットは初回注文は半額で食べられるということだったのですぐ会員登録し注文した。

注文画面で驚いたのは当日の朝5時までの注文ならその日の夕方に届けてくれるところ。ヨシケイは歴史も古く、コープみたいなもんで独自の配送網を持っているからなせる技っぽい。その辺は新興の宅食ベンチャーとは訳が違う。

早速届いた夕食ネットの惣菜を食べてみたところ味はやはり予想通り、それなりに美味い。実家で食った記憶のあるような味がする。味としてはこれで十分。

問題はボリューム。ナッシュと比較すると副菜の量はそれほど変わらないとはいえ、メインの量は流石に少ない。惣菜全体のカロリーで比較すると計100kcal位は少なそう。高齢者や自分くらいの食の細さの人にはちょうど良いかもしれないが、普段外食ばかりの人にとってはだいぶ物足りないだろう。

ただ値段のことを考えると悪くはない。この味で自分はギリギリ足りる量だし選択肢としてはアリ。

という感じで吟味した結果、やはり昨今の経済情勢を踏まえるとこの値段は流石に魅力的すぎるのでヨシケイの夕食ネットを使っていくことにした。

とりあえず1ヶ月弱継続してみているが特に問題はない。ボリューム問題については、これに1品足すみたいな運用もありかもしれないなとは思った。たとえば自分はキムチが好きなので、デカいキムチパックが常備してあるのだが、これを夕食ネットの惣菜に足すとか、納豆を足すとか。数十円プラスにはなるが、それでもまだまだ既存の宅食より安いのでアリ。

問題というか微妙な点についてもいくつか書いておく。

まず**ヨシケイの夕食ネットはヨシケイではないということ**。

自分がこの値段で食べられている惣菜は**夕食ネット**の**シンプルミール**というやつ。[ヨシケイ](https://yoshikei-dvlp.co.jp/)の方にあるミールキットなどではない。そもそもこのサイトから夕食ネットのシンプルミールは注文できないし、このサイトから会員登録してもいけない。夕食ネットは[https://www.you-shoku.net/](https://www.you-shoku.net/)のサイトから会員登録を行う必要がある。同じヨシケイ系列だが会員情報は別。割と罠なので注意。

あとは**配送設定で玄関前に置き配できるというオプションがあるのだが全然置き配してくれない**。

普通にピンポンと呼び鈴が押されて惣菜を手渡しされる。おそらく配送時に発泡スチロールの箱に入れて配送されるのだが、ヨシケイはその箱をまた各家へ回収しにいっているのだ。で、その配達員たちは玄関前に置き配すると配達と回収の2回家を訪れる必要が出てくる。だが中身を手渡ししてしまえば箱はすぐ持ち帰ることができるので回収する手間が省けるのだろう。だから極力置き配したくないんだと思う。もちろん彼らの気持ちはわかるが置き配設定してるんだから置き配してくれよ...とは思いつつ別に家にいるのでいいか、、と諦めてる。

それと**基本クレカ支払いなんだけどなんとなくオールドタイプのサイト構成なのでやや不安がある**。クレカ情報の登録がやや怖い。メインのクレカじゃなくて限度額低めのサブカードを登録した。StripeとかPayPal使ってほしいなという気持ちはありつつも、まぁある程度歴史ある会社だろうしバックエンドも大変なのでしょうと想像できるので贅沢は言えない。

あ、あともう一つ**毎週月曜日に新メニューが登場するのだがうまそうなやつはマジですぐ品切れになる**。別に残ってるやつも悪くはないんだけどうまそうなやつはもう少し在庫増やしてくれよと思う。まぁ別にメニューが少なかったり入れ替わったりに関する要望はどの宅食でもあるので仕方ないかも。

と、こんな感じでナッシュからの移行を終えて新しい昼食ルーティーンがリビルドされた。今のところは大体うまく回っており、何より昼食費用がこれまでの4割OFFくらいの価格に圧縮されたので家計にも優しくなっていて概ね満足している。


ナッシュを解約してヨシケイの夕食ネットに変えた

- [技術的なアウトプットに疲弊したので振り返る](https://blog.arthur1.dev/entry/2023/01/08/195840)という記事を読んだ
- 内容は「たくさん技術エントリを書いてきたが全然読まれないのでモチベーションが保てない」というお話
- 気持ちはめちゃくちゃ理解できるが、少し思うところもあったので自分の考えをまとめておく
- そもそも論
  - ブコメやエントリに関連したツイートでの言及をみると「モチベが理解できない」「自分のために書くべきでは」「承認欲求のためにやってるのか」みたいなものが結構あった
  - まぁ確かに正論ではあるが、悩み相談に対する正論というのは安易だ。悩みを持つ当人への理解を捨てた浅い回答にしかならないことが多い。正論を述べる側は気持ちいいかもしれないが...。
  - 悩んでいる当人の気持ちを推し測って寄り添った回答を捻り出したいという気持ちがある
- テクニックの話
  - このエントリに対しての反応として先のそもそも論以外だと「自分はOOを気をつけている」「OOをターゲットにして書いている」など技術記事を書く時のコツを述べている人も多かった
  - しかしかの筆者がエントリで**仮説**として書いている内容を見るに、Twitterで知らん人々が適当につぶやいた「技術記事を書くときのコツ」なんかはとっくの昔に本人も考えて実践してるのでは？と思った
    - 確かに[去年は182本の記事を書いた人から見た、技術的なアウトプットに疲弊しないようにするコツ - Lambdaカクテル](https://blog.3qe.us/entry/2023/01/09/221705)で述べられているような、機械的な書き方のフォーマットのようなものはあると思うが瑣末な問題にすぎなそう
- 内容の話
  - 技術記事なので「結局は誰が？どんな内容を？書いたかがほぼ全て」という声は確かに...と思う
    - 信用できる人か否か
    - 有益な情報か否か
  - ただし良い内容なら多くの人に**すぐに**読まれる、というのは間違い
    - 情報はその人にとって**必要な時**でないと刺さらない
      - つまりすぐに多くの人に読まれるには多くの人が**その時に必要としているトピック**を選ぶ方が良い
        - 例えばChatGPTが流行ったときにすぐにAIについての話を書くとか
          - この記事は箇条書きだしフォーマットはめちゃくちゃだけど300はてブ超えた
            - [どのようにしてプログラマはAIに仕事を奪われていくかの妄想](https://yuheinakasaka.github.io/gialog-diary/articles/26)
    - しかし別にIT系メディアの運営をしてるわけではないのでそんな頑張りが必要かと言われると微妙。個人的には不毛な努力だと思う。書きたいときに書きたいことを書くべきだ。
  - 技術記事に関しては**すぐに**という制約がなければわりかし多くの人に読まれやすい
    - 特に検索流入でいつかは誰かに読まれるということが多い。数年前の記事がいきなり知らんところでバズってたみたいなこともある。数年後の自分が読むということも結構ある。
  - 最低限のクオリティを持った技術記事はその中で取り扱った技術コミュニティに対する貢献になるし、インターネット全体の資産にもなる。
  - **すぐに**多くの人に読まれたいという気持ちさえなんとかなれば良さそう
- 暖簾に腕押し
  - かのエントリでは冒頭で暖簾に腕押しという言葉が使われている
  - なぜ読まれないのか？についての考察など色々書いたりしているが結局のところ暖簾に腕押しという言葉に全てが詰まってると思う
  - それなりに時間をかけて対象も吟味してできる限りの手は尽くした、つまり頑張ったわけだ。しかしそれがすぐには報われない。
  - 自分なりによくできたと思って作ったものが、期待に反して全く評価されないという経験は誰しも多かれ少なかれあると思う
  - そもそも論の文脈で言えば、期待値(まともな技術記事は多くの人にすぐ読まれるという期待)が間違っているということになる
  - が、先に述べたようにそれを言ってもまぁ瞑想しましょうねくらいの精神論しかなくて現実的ではない解決策にしかならないと思う
- 解決策 
  - それなりに精神論的な善処は期待しつつ(重要)、かの筆者にかけられる自分からの言葉としては「Twitterを教えてくれ、フォローするよ。」だと思う
  - 流石に自分にとって有益でなければ記事をはてブしたりRTしたりはしないけど、疲弊した気持ちをアウトプットしてくれたことはありがたい。ではそれを読んで何か自分が無理ない範囲でできることがないか？を考えるとTwitterをフォローする、くらいは丁度良い感じの柔らか回答になる気がする。
  - 少なくとも1人はかの筆者の書いた技術記事を読む可能性のある人が増えるわけだ。フォローするだけなら自分にも負荷はない。
  - よっぽどの内容に難があるような人でなければ技術記事を書くことは誰であれ無理ない範囲で続けてほしい。
- その他
  - アウトプットが継続している人はほとんどが自分のために書いている。これは本当にそうだと思う。
  - 実際に30代になってくると脳のメモリやディスク容量が減ってくる。そうなると学んだことが定着しづらくなっていく。
  - 昔なら読んだ本の細かい内容を丸ごと覚えられたのに、今は読んだ本のトピックは覚えているけど細部が思い出せないという感じになりつつある
  - そういう状況になるとどうなっていくかというと、全内容を丸ごと頭に入れるのではなく、全内容にたどり着くためのインデックスだけメモリに入れておくようになる
    - 例えば昔はRubyのtimestampのフォーマット構文を丸ごと暗記していたが今はリファレンスの当該ページへたどり着くためのパスだけ覚えておく、みたいな
    - あそこに行けばOOOの情報にたどり着けるというパス情報。
  - そのインデックスを自分なりに作るのに良いのが技術メモだ。調べたことや読書の感想をとにかく文章にしてアウトプットしておく。そうすると先の例だと「timestampのフォーマットは自分のscrapboxのOOのところにあるな」という感じでパスを自分なりに集約できるようになる。これがないと毎回ググって出てきた記事を読み、その信頼性をチェックして...みたいな感じになってしまう。
  - 自分のためにアウトプットするというのは別に強がりではなくて、自分の老化した脳に対して仕方なくやらないといけない対策という側面が割とある
  - 老化は辛いね...

技術的なアウトプットに疲弊しないようにするコツという記事を読んで思ったこと

<blockquote class="twitter-tweet" data-partner="tweetdeck"><p lang="ja" dir="ltr">これまで300食以上食べてきたけど過去の事例も併せて流石に厳しい企業であると感じたのでアカウントやその他全情報を全て削除するように依頼した。<br><br>宅食「ナッシュ」に不正アクセス、約6000件の顧客情報流出か　ランサムウェアに感染<a href="https://t.co/ipna9uDdDu">https://t.co/ipna9uDdDu</a></p>&mdash; YuheiNakasaka (@razokulover) <a href="https://twitter.com/razokulover/status/1611015759601487874?ref_src=twsrc%5Etfw">January 5, 2023</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>


ナッシュに関しては2021年くらいから少なくとも計300食以上食べてきたが、[宅食「ナッシュ」に不正アクセス、約6000件の顧客情報流出か　ランサムウェアに感染](https://www.itmedia.co.jp/news/articles/2301/05/news077.html)というNEWSを受けていよいよ解約した方が良いかなと感じたのでやっと解約手続きをした。過去[〈チャット入手〉NHKも紹介した宅食ベンチャー・ナッシュ取締役「デブの人は採用しないように」「権利主張が激しい」](https://bunshun.jp/articles/-/57926)というようなNEWSも出ていたが、本当ならこの時に解約しておいても良かったのかもしれない。

しかしナッシュはクレカ情報や住所情報を管理画面から簡単に削除することができず、綺麗さっぱり解約するのが面倒そうという印象があってその時は億劫で手続きをしなかった。

今回は本格的に今後もやばそうかもという感じがしたので重い腰を上げた形になる。

ナッシュから**個人情報含めて完全にアカウント削除する方法**は少しコツがいる。通常の解約処理だけだと全個人情報をナッシュ側から削除できない(らしい)からである。

どういうことかというとナッシュ側で保持されている個人情報は通常の「アカウント情報(とそれに紐づく住所やクレカ情報など)」と「商品に瑕疵や問題が発生した際の連絡用として通常アカウントとは別に保持されている注文履歴や連絡先の情報」という2種類ある。

通常の解約処理で削除されるのは前者の方だけだ。後者は記載している通り何らかの緊急連絡用に別に保持されていて、通常のアカウント解約では削除されないとのこと(保持期間も不明)。

なので後者の個人情報を削除するにはアカウント解約とは別に問い合わせフォームから全ての個人情報を削除してほしい旨を連絡する必要がある。

自分の場合は下記のような文章を送った。

```
下記の情報を削除したいです。

- アカウント情報
- クレジットカード情報
- その他個人情報全て

当サービスからこれらを削除する方法をご教授願います。

よろしくお願いいたします。
```

すると数営業日後に折り返しメールがきて、ナッシュのアカウント解約が行われた旨が伝えられ、加えて先ほどの後者の注文履歴や連絡先などの個人情報の削除が別途数日後に行われるという旨も併せて伝えられる(自分の場合は問い合わせから6日後だった)。

少々面倒だがこれらの工程を踏んで晴れてナッシュから全ての個人情報を削除できる。

大人なので「本当に全て削除されるのだろうか？」みたいな邪推はせず、うまく対応してくれていることを祈っている。

ナッシュを解約して個人情報を全て削除してもらった

2022年の振り返りと2023年の抱負を書いていく。自分向けに書いていくのでハイコンテクストになりがち。

# 2022年の振り返り
## 仕事面
なんとか生き延びることはできた。起業してからもう10年いかないくらい経つが、1年をなんとか生き延びられるか常に不安である。毎年今年は生きられるんだろうかと常に遠くを見つめている。

メインの仕事としてはNFT関連のプロジェクトの開発をやったりしていた。主にLINE Blockchainを主戦場にしていたが、LINE Blockchainはまだまだ発展途上である。国内で自分より詳しい人は数えるほどしかいないのではないかと思う程度には熟知しているレベルになってしまった。しかしその知識と経験に需要が全く追いついていないので持ち腐れになっている。さらに現状はクリプト冬の時代突入の最中であり先行きどうなるかわからん...。

2022年は4月頃から業務委託で仕事を受け始めるということもした。既存プロダクトの改善や拡張、新規開発など手を動かす要員として働いた。技術としてはRailsとFlutterを中心に書いている。

自分は技術力としてはそれほど突出したものは無いが、会社全体として目指すべき状態とそのためにやるべき仕事を見極めて、それを最短の労力でこなすことには自信があるので、そういう立ち振る舞いとしてはまずまず貢献できたと思う。ありがたいことに社からの評価は上々だったので需給が良い感じでマッチしていたみたいだ。どんなに能力が高くてもその能力が発揮できる仕事がない&提供できないならば機能しない。雇用者側としてその点は痛いほど実感していたのでそういうすれ違いが発生していなくてよかったと思う。

内容にもよるが業務委託はまだ週1~2くらいなら受けられる可能性があるので今後また募集を出すかもしれない。

やんごとなき事情で給与(Findyの想定年収の1/2程度)は5年くらい横ばいで変わっていない。支出を抑えるか空からお金が降ってくるのを待つしかない状態なのでさらに働き口を増やして馬車馬になるか...

## プライベート(技術)
2021年夏くらいからブロックチェーンに関する技術のキャッチアップを始めて2022年の夏くらいまでは日々日々情報を追ってた。

ブロックチェーン関連ではBNFTLYというサイトを作った。詳細は[任意のURLに簡易のNFT認証を付けたリンクが作成できるサイトを作った](https://zenn.dev/razokulover/articles/3af0477a15ab51)に書いている。界隈の規模感を加味するとまぁまぁバズった気がする。

その後はZk系のプロジェクトを追ったりEthereumのThe Mergeが完了するかしないかあたりで(理由は覚えていないが)飽き始めて少し距離を置くようになった。

それ以降はCloudflare関連プロジェクトやRustを書いたりする時間に使っていた。

中でも11月に取り組んだNES(ファミコンエミュレータ)をRustで実装するプロジェクトが楽しかった。詳細は[Writing NES Emulator in Rustをやった](https://zenn.dev/razokulover/articles/1191ca55f9f22e)に書いている。[動かしてわかる CPUの作り方10講](https://amzn.to/3G9u0n7)を読んでCPUエミュレータを書いたりもした。これらの過程でプログラムがバイナリレベルで実行されていく流れが解像度高く実感できるようになったのがよかったと感じている。

今年はZenn/ブログ/Scrapboxに記事やメモや結構書いたなと思う。

Zennは25記事書いており、1,526Likesを集めた。
![Fkp50_jaMAAMCLr](https://user-images.githubusercontent.com/1421093/210347633-bc70e722-99be-4811-a365-79d065c8064f.png)

よく読まれた記事としては、下記。

- [未経験者がプログラミングを学びたいと思った時に最初に読む記事](https://zenn.dev/razokulover/articles/d312d73e319e7c)
- [1~2年目のエンジニア向けにキャリアや勉強方法について話したこと](https://zenn.dev/razokulover/articles/09f2b13b6cbd7a)
- [Writing NES Emulator in Rustをやった](https://zenn.dev/razokulover/articles/1191ca55f9f22e)

今年の4月からr7kamuraさんの[GitHub Issuesでブログを書く](https://r7kamura.com/articles/2022-05-03-github-issues-as-blog)にインスパイアされてGitHub Issuesで日記を書き始めた。そこで書いた日記の中でホットエントリしたものがいくつかある。

- [仕事力と技術力と不安に関する雑文](https://yuheinakasaka.github.io/gialog-diary/articles/28)
- [どのようにしてプログラマはAIに仕事を奪われていくかの妄想](https://yuheinakasaka.github.io/gialog-diary/articles/26)
- [最近のWeb3への雑感](https://yuheinakasaka.github.io/gialog-diary/articles/14)

Zennにしても日記にしても初心者プログラマ向けの話/キャリア系の話が人気っぽい。

そういえばScrapboxの技術メモは今年だけでも200ページを超えていたが、多くはBlockchain関連だ。

- [技術メモ](https://scrapbox.io/razokulover-tech-memo/)

それが要因でBlockchain界隈の人たちからTwitterでフォローされることが増えた。今年だけで1000人くらいフォロワーが増えている。良い機会なので基本的に技術ネタしたつぶやかないように運用を変えている。見てる人もその方が雑音が減って良いだろうし。

- [メイン垢: @razokulover](https://twitter.com/razokulover)

ただ雑音的なまじなつぶやきもやっていきたいのでサブ垢も作った。よかったらフォローして。飯の情報と雑な思考のアウトプットとハロプロの話が得られる。

- [サブ垢: @revolukozar](https://twitter.com/revolukozar)

## プライベート(技術以外)
### 日課
筋トレと詰将棋とDuolingo(ロシア語)とTanzamと適当な英語リスニングを続けた。

筋トレと詰将棋は2017年くらいから細々と継続中。

[Tanzam](https://apps.apple.com/jp/app/%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%82%A2%E3%83%97%E3%83%AA-tanzam/id1554699067)は英単語アプリ。絵と単語を紐づけて覚えるやつで、TOEIC900くらいまでの3000語以上をやった。体感としてはTOEICでわからない単語は一つの長文あたり一桁個以下になってきたと思う。まぁそれだけでいい点数が取れるわけではないので意味ないかもしれないけど自己満足としてはまずまず。

Duolingoではロシア語をやってた。簡単な文章なら辞書を引いて読めるくらいにはなったと思う。が、如何せん使う機会も場所もない。

Youtubeの[地獄の英語リスニング・トレーニング【7時間連続再生】【日本語字幕付き】](https://www.youtube.com/watch?v=kuc03HDwIVo)というやつをよく聴いていた。英語が2回読まれて日本語が1回読まれて再度英語が2回読まれる、というセットが1000文。TOEICでいうとPart2がひたすら続く感じ。読まれるスピードは結構早めなのでこれに慣れてるとTOEICのPart2は簡単に感じてくる。約10分/日くらいで半年前くらいやってて、もう5周弱くらいしたかも。体感では割と効果がある気がしてる。

### 痔
4月に痔が悪化して病院に罹った。元々痔持ちだったが病院行ったのは初めてだった。親以外の他人に初めて肛門に指を突っ込まれるという経験などを経て、外痔核のステージ2だとわかった。ステージ3からは手術が勧められる。それに片足を突っ込んでいる状況。一応は保存療法で様子見になったが手術してもいいかもよというレベルと言われてかなり凹んだ。

もう数年以上前から食事改善や生活習慣の見直しは自前でやっていてそれなりに排便環境はよかったのだが、排便方法の方に問題があったらしい。結構な力で息んで肛門に力がかかりやすい排便方法だったのだ。これが良くなかった。なのでまずはこの排便方法を治すように試行錯誤した。具体的にはお尻を突き出し体を屈ませて、便意を強くイメージ、背中のあたりから腸の内圧で便を下方へ移動させ肛門に力を加えず括約筋の方を動かして排出させる訓練。ヨガとかそういうやつに近い修行みたいなもんなんだけどこれがマスターできると肛門に不要な力がかからず排便できるようになる。不要な力がかからなければ痔核や切れ痔が出来づらくなる。小学校で教えてほしかった。

食事や生活改善も継続。具体的にはこまめな水の摂取・納豆&ヨーグルトを摂る・ご飯をお腹いっぱい食べる。ご飯を食べる量が少ないと便が押し出されず腸に留まる時間が伸びて便秘気味で硬くなりやすい、意外と盲点である。外痔核は下半身の血行が悪くなると良くないので真夏でも湯船に浸かるようになった。

それから半年ちょっと経ってやっと落ち着いた。とはいえ気は抜けない毎日だ。

痔かも？と思ったらすぐ病院へ行け。痔を舐めるな。[痔 - WEB](https://www.iwadare.jp/G-WEB/)は万人が読んでおくべきサイト。

### スタンディングデスク
痔のためだけではないが仕事や普段の作業でもスタンディングで行うようになった。椅子に座ると(自分の場合は)腰が痛くなったりお尻にも良くないことが多い。詳細は[スタンディングワークを3ヶ月ほど続けた感想](https://yuheinakasaka.github.io/gialog-diary/articles/15)に書いている。結局あれから半年以上続けているがもう常態的にスタンディングで作業できるようになった。自分には合っているようだ。

### カレー
![IMG_3859_res](https://user-images.githubusercontent.com/1421093/210355190-f8356459-da1f-4332-a859-9fe91528d045.PNG)

7月頃から平日は毎日カレーを食べるようになった。インスタにカレーだけアップロードしてる異常者になっている。

- [@razokulover](https://www.instagram.com/razokulover/)

# 2023年の抱負
## 仕事面
生き残る。どんな技術を使うかとかは気にしてる余裕ないのでなんとか生き残る。なんとか生きていく。

## プライベート(技術)
仕事で必要になりそうなものがあればそれを重点的に。それ以外だと普遍的な技術を都度掘り進める。

例えば自分はネットワーク周りの知識がとても弱い。それもあって年末に[BGPプロトコルのRust実装](https://scrapbox.io/razokulover-tech-memo/%E4%BD%9C%E3%81%A3%E3%81%A6%E5%AD%A6%E3%81%B6%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB_Rust%E3%81%A7BGP%E3%82%92%E5%AE%9F%E8%A3%85)をやったり[プロフェッショナルSSL/TLS](https://scrapbox.io/razokulover-tech-memo/%E3%83%97%E3%83%AD%E3%83%95%E3%82%A7%E3%83%83%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%ABSSL%2FTLS)を読んだりした。

こういう基本的な技術を広く固める営みは技術領域を問わず常に続けていきたい。

あとはOSSのコードをもっと読むようにしたい。今までも読んではいたけどもっと息を吸うように触れられるようにしていきたい。

## プライベート(技術以外)
日課としてはDuolingoを外し、代わりに応用情報の午前問題を毎日数問解くというのをやってみたい。それ以外は継続で。

痔が悪化しないようにできることをやり続ける。死ぬまでやっていく。

カレーは引き続き食っていく。

友人を作る。2022年は特に他人との関わりがなかったので2023年は友人を作る。方法は何も考えてないが。

# まとめ
2022年の振り返りと2023年の抱負を書いた。振り返りは実際にあったことをベースに書くので大量に書けるが抱負はこれからのことなので全然書けない。

都度都度いい感じにやっていく。

以上

2022年の振り返りと2023年の抱負

- 先日「育児など家庭の色々があって自分の時間が確保できなくなった。技術力を高めるための勉強ができなくて不安。」みたいな話を聞いた
- この悩みの直接的な解決方法としては先人の様々な体験談および対策みたいなものが世に出回っているからご家庭の状況に応じて参照すればいい思う
  - [子育てと開発を両立するコツは「無理をしないこと」。パパ／ママエンジニアの働き方とは](https://engineer-lab.findy-code.io/ikuji_findy)
  - [子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには](https://eh-career.com/engineerhub/entry/2018/05/15/110000)
  - [ITエンジニアと子育てと勉強と](https://zenn.dev/akinari_ueda/articles/3ec81c9605e732cb7912)
- それよりも「技術力を高めるための勉強ができなくて不安」という点が個人的には気になった
- 技術力とは何か？技術力が高くないとなぜ不安なのか？みたいな話
- 技術力は特に明確な定義があるわけではない
  - 例えば著名なOSSにコミットしているとか低レイヤーのプロトコルやインフラをバリバリ実装してるとか競プロで上位勢だとか、挙げ始めたらキリがなく、それっぽい何かはたくさん挙げられそう
  - つまるところ技術力というのはその人の理想次第なのではないか
- 技術力が無いとなぜ不安か
  - 「**今職を失うのではないかという不安**」と「**将来職を失うのではないかという不安**」がある
  - 前者に関しては
    - 技術力が無いと仕事がこなせない => 役立たずとしてクビになる => 職を失う => 生きていく金がない => 不安、というロジック？
  - 後者に関しては
    - 技術力が無いと職を得られない => 生きていく金がない => 不安、というロジック？
  - どちらにしても技術力の高低によって仕事をし続けられるかどうかが決まるという前提がありそう
- 技術力の高さと失職の可能性
  - 確かに技術力が高ければ職を得やすそうだしクビにもなりにくいのは確か
  - しかし技術力の有り無しは0か1の離散的な話ではなく、0と1の間に無限のグラデーションがあるはず
    - 技術力が0.2の人もいれば0.5の人もいるし0.8の人もいる
    - どれだけの力があれば失職の可能性に怯えずに済むのか。はっきりわからない部分が多い。
      - 企業ごとに技術力を0.2しか求められない会社もあるし0.8求める会社もある
      - 自分の所属する企業はどれくらいを求めているのか、自分の将来働いているであろう企業群はどの程度を求めているのだろうか
- 技術的成長はどれほど必要か？仕事が出来るだけの技術力があれば良いのでは？
  - 仕事を最低限こなせるだけの技術力があれば仕事を失わないのではないか
    - 少なくとも日本だとそんな簡単に解雇しづらいし
- 業務外の技術について
  - 現状の仕事で必要な範囲を超えた技術を学ぶことはどれだけ重要か
    - 例えばサーバーサイドエンジニアがUnityを学ぶのはその人の不安の解消に役立つのかとか
  - 不安の解消という観点では今の仕事の延長線上にある未知の技術に手を出す以外の学習は遠回り感があるのでは？
- 仕事で必要なのは技術力ではなく仕事力ではないか
  - エンジニアは技術職と言われることも多いし、仕事を遂行する能力=技術力というような考えをしがち
  - しかし仕事を遂行する力、すなわち仕事力は技術力と一致しない(もちろんガチTech企業ならほぼ一致することもあるが)
  - これは別に技術力を軽んじている訳ではなくソフトスキルを礼賛したいわけでも無く、仕事に必要な技術力は高々仕事の範囲でしかないという意味
  - その仕事特有のドメイン知識や問題の定義・解決能力、チームを巻き込む力など仕事には仕事をこなすために必要なスキルがある
  - 仕事とは**ある目標を達成すること**なので重要なのは技術力ではなく目標遂行能力だ
    - 自分はこの能力を**仕事力**と定義してる
  - 技術力というのはその中で必要になるピースの一つである。だからまずは今の仕事にどういう技術力がどのくらい必要か見極めて必要な分だけ学べば良い
- そう考えると先の若者のように「業務外で勉強する時間がなくて不安」みたいな話についてはとりあえず下記の心構えで上から順に臨むのが良さそうに思った
  - 仕事に取り組む上で必要な自分に足りていない技術力を定義すること。まずこれが重要。
  - そしてその技術の学習を業務内で出来る限り行う
    - 業務に関係のある技術なのでお賃金をもらいながら胸を張ってやるべき
  - それでもどうしても足りないのであれば仕方なく業務外で頑張る
    - ここに占める割合があまりにも多い場合は、上司のタスク割り当てが間違ってる可能性があるのでまず相談する
      - 自分の能力不足の場合、気合いでやる。しかし気合いで血反吐を吐きながらやるのは最終手段。
- 巷のスゴいエンジニアと自分を比べたり膨大で深遠な技術力という怪物を倒そうと頑張るのではなく、まずは自分に必要な最低限のサイズの目標に切り分けてそれだけを相手にするように心がける。まずは不安に囚われず余裕を持てるようになるところを目指す。
- **今職を失うのではないかという不安**に関してはこんな感じ
- では**将来職を失うのではないかという不安**に関してはどうか
  - 業務内の時間で仕事にコミットすることで得た知識がそのまま将来の不安を軽減させてくれる可能性もあるし、余裕が生まれたことで業務外でできるようになる好き勝手な技術探求で得た知見が将来の不安を軽減させてくれる可能性もある
  - どのみち将来のことはどうなるかわからない
    - 10年前のインフラ・サーバーサイド・フロントエンド・各種技術の流行りやスタンダードを思い浮かべてほしい。何が消えて何が残って何が新たに生まれるかはわからんすぎる(ある程度の方向性は予測できるにせよ)。
    - そういう意味ではハードウェアやOSやネットワークのような比較的低レイヤーな基礎技術を学ぶのが良いとかはあるかも
      - だからといってその辺の知識が将来の失職を予防してくれるかも不明。その時必要となる仕事力がないと結局は不安は拭えない。
- 第一は今コミット出来ることにコミット。そして遠い将来に関しては直感を頼りに逐一betしながら祈る。
- その他色々
  - 将来については歳を重ねて技術力どころではなくなり健康力みたいなものも必要そう。健康への投資も重要っぽい。
    - 目や腰、その他生活習慣病などのケアに追われている中年エンジニアが自分のTLにも散見されるようになってきた(TLの老化...)。
  - 未婚・DINKsなど子育てが無い人は**将来職を失うのではないかという不安**への投資がしやすいので余裕があるか？
    - 先に書いた通り将来に関しては祈り要素もあるので皆等しくほんのり不安なのは同じ
    - 置かれた立場によってそれぞれの不安要素はあるものだし、まして子の有無によって発生するもの/失っているものを比較するのは語り得ないものなので踏み込むべきではない
  - こういう人生や日常の悩みは現状把握と分解と整理が基本なので一人で抱え込まずに早めに適当に文章にするなり人に吐き出すなりすると良い。当事者だけではるつぼに嵌ってしまう。


仕事力と技術力と不安に関する雑文

ChatGPTにレシピを生成してもらうのが楽しい。適当に冷蔵庫の余り物を指定して「レシピを教えて」と聞くと良い感じに答えてくれる。

普通じゃ思いつかないようなトンチキな解答も結構あり中々味わいがあって良い。レシピに困った時に使えるかもしれない。

現実的に食えそうでかつユニークな回答を得るには「誰も食べたことがないような」とか「意外な組み合わせ」などの形容句を加えると良さそうだった。

以下、ChatGPTが生成した今後自分でも試してみたいと思ったレシピをメモしとく。

※記事が見づらくなるしググラビリティも悪くなるのでやりとりのスクショ画像は省く。自演したんじゃないかと疑われそうだけどスクショを貼ったところで画像もいくらでも改ざんできるわけで大して変わらんだろうからまぁ誤差。

# Q.  鮭とほうれん草としめじを使った今まで誰も食べたことがないような料理のレシピを教えてください。

鮭とほうれん草としめじのロール

材料：

- 鮭 1/2枚
- ほうれん草 1/2束
- しめじ 1/2袋
- 塩 小さじ1/2
- 味醂 小さじ1/2
- 卵 1個
- 小麦粉 小さじ1/2
- 作り方：

1. 鮭をスライスし、塩と味醂を加えてマリネする。
2. ほうれん草を細かく切り、しめじを洗い、水切りしておく。
3. 卵を打ち、小麦粉を加えて薄める。
4. フライパンに油を熱し、ほうれん草としめじを炒める。
5. 鮭をフライパンに入れ、表面が色づいたら反対側に折り返す。
6. 鮭の上にほうれん草としめじをのせ、お皿に並べる。
7. 卵液をひたして、鮭と一緒に焼く。
8. 焼き色がついたら、反対側に折り返し、さらに焼く。
9. 焼き上がったら、お皿に並べ、噛みやすく切って、お皿に盛り付ける。
10. お好みで、塩、醤油、レモン汁などで味付けして完成！

鮭とほうれん草としめじが柔らかく、卵液が香ばしさをプラスした、新鮮な味わいのロールができあがります。是非お試しください。

## 感想
マリネにした鮭を野菜やキノコで包んで卵で包んで焼くという料理。なんとなく美味そうな気はする。`卵を打つ`という工程が謎だが...。

# Q.卵とサラダチキンともやしとオクラを使った意外な組み合わせの料理のレシピを教えてください。

以下は、卵、サラダチキン、もやし、オクラを使った料理のレシピの一例です。

【材料】

- 卵: 1個
- サラダチキン: 1/2カップ
- もやし: 1カップ
- オクラ: 1カップ
- 玉ねぎ: 1/2個
- 薄力粉: 1/4カップ
- 中濃ソース: 1/4カップ
- 油: 1/4カップ
- 塩、胡椒、お好みのスパイス: 少々

【作り方】

1. 卵をボウルに入れ、塩と胡椒を加えて混ぜます。玉ねぎをみじん切りにし、もやしとオクラを刻んでおきます。
2. 卵をフライパンで炒め、玉ねぎ、もやし、オクラを加えて炒めます。サラダチキンを加えて炒め、薄力粉をまぶして炒めます。
3. 中濃ソースを加え、よく混ぜます。塩、胡椒、お好みのスパイスを加えて味を調えます。
4. 完成した料理を皿に盛ります。好みでサラダや白飯を添えてお召し上がりください。

このレシピは、簡単でかつおいしい料理が作れるようになるよう心がけました。ぜひ、試してみてください。

## 感想
材料を全部炒めて中濃ソースで味付けするという料理。イメージできそうで出来ない絶妙な料理。お好みでサラダに添えてもおいしいらしい。

# Q. 納豆と冷凍かぼちゃとナスとピーマンを使った誰も食べたことがないような料理のレシピを教えてください。

納豆と冷凍かぼちゃとナスとピーマンを使った料理のレシピとして、納豆とナスとピーマンのスパイス風味カレーがあります。このレシピを作るには、まず納豆を冷凍かぼちゃと一緒にフライパンに入れ、炒めます。次に、刻んだナスとピーマンを加え、スパイスを加えて炒めます。その後、カレーの素と水を加えて煮込み、好みの生野菜やサラダを添えて完成です。

## Q. 工程ををもう少し詳しく教えて?

この料理を作る手順は次の通りです。

1. 納豆を冷凍かぼちゃと一緒にフライパンに入れ、中火で炒めます。
2. 刻んだナスとピーマンを加え、さらに炒めます。
3. スパイスを加えて炒めます。スパイスは個人の好みに応じて、カレー粉やターメリック、コリアンダー、カイエンペッパーなどを使用することができます。
4. カレーの素と水を加えて、よく混ぜます。
5. 煮込み、沸騰したら火を弱めて、約 20 分間煮込みます。
6. 煮込みが終わったら、好みの生野菜やサラダを添えて完成です。

以上が納豆と冷凍かぼちゃとナスとピーマンを使ったスパイス風味カレーの作り方です。もし質問がありましたら、お気軽にお問い合わせください。

## 感想
スパイスカレーだ。納豆トッピングとかよくあるし普通に美味そう。まぁでも誰も食べたことがないような食べ物ではないな..。

詳しい工程を教えてくれない場合があるから追加で質問した。最初の質問でちゃんと付け加えておいた方が良さそう。

# Q. 鶏むね肉と適当な野菜を使った異国風の料理のレシピを教えてください。分量や工程も詳しく教えてください。

鶏むね肉と野菜を使った異国風の料理のレシピを紹介します。分量や工程は、あなたのお好みに合わせて調整してください。

【材料】

- 鶏むね肉: 大さじ1
- にんじん: 1/4本
- セロリ: 1/4本
- 人参: 1/4本
- しめじ: 大さじ1
- にんにく: 小さじ1
- みりん: 大さじ1
- みそ: 大さじ1
- にんにくみそ: 小さじ1
- にんじん: 1/4本

【作り方】

1. にんじん、セロリ、人参をおろし、1cm角に切ります。
2. 鶏むね肉を1cm角に切ります。
3. 小鍋ににんじん、セロリ、人参を入れ、弱火で炒めます。
4. 鶏むね肉を加え、炒めます。
5. しめじを入れ、さらに炒めます。
6. にんじん、セロリ、人参を加え、炒めます。
7. にんにく、みりん、みそ、にんにくみそを加え、炒めます。
8. 水でさっと洗ったにんじんを加え、炒めます。
9. 調理が完了したら、皿に盛り付けてお召し上がりください。

他の野菜やスパイスを加えることで、さまざまな味わいを楽しめます。また、このレシピは鶏むね肉だけでなく、鶏もも肉や鶏胸肉を使用することもできます。ぜひ、自分の好みに合わせて作ってみてください。

## 感想
人参とにんじんは同じでいいのかな。計3/4本使うってことか。にんにくは固形でも使うし、にんにくみそとしても使うっぽいので臭そう。でもガッツリ感はあり、ご飯に合いそうで美味そうな雰囲気はある。

プロンプトは具体的な食材を指定するのもいいが適当な野菜/肉みたいな指定の方が未知の料理になりやすくて面白いかもしれない。

# 現状の良さげなレシピを生成するためのプロンプトTips
- 「誰も食べたことがないような」とか「異国風の」といった形容句を付けた方がググっても出て来なそうな名も無い料理が出やすそう
- 「分量や工程も詳しく教えてください。」 を付けた方がいわゆるレシピっぽい文章が生成されて良い
- 食材は「適当な」で指定した方が幅広い料理が出やすい

# 随時更新予定...


ChatGPTに適当な食材を使ったレシピを考えてもらう

- 先日 OpenAI から[ChatGPT](https://chat.openai.com/chat)が Beta 公開された
- ChatGPT ではどんな質問に対しても何かしらの回答を生成してくれるのだが、ソースコードに関しても中々の筋が良さそうな雰囲気のコード片を生成してくれるということで少し話題になっていた
- こうしたプログラムを生成してくれる AI が発展していく中でどういう具合にプログラマの仕事が奪われていくのか興味がある
- 特に以下では**web アプリやモバイルアプリなどのアプリケーションの開発において**という文脈で考えることにする
- まず AI がプログラマの仕事を奪うまでにはいくつかの段階があると思う

# コード支援レベル

- 現状は[GitHub Copilot](https://github.com/features/copilot)のようなコーディング支援を行うレベルの AI はある程度実用レベルになっている
  - 自分は Copilot が生成したコード片をプロダクションコードに含めるのは権利関係の問題もあり様子見している
  - しかし Copilot を使っていないわけではなく、変数名や定型作業のサジェストや変数名の補完、コードの書き出しの補助などで利用している
    - 例えば API のレスポンスで受け取る予定の JSON をペタッと貼るとそれにあった構造体とか型が丸ッと生成されたりする。スニペットとか静的なコードジェネレータでやってたような作業が良い感じにできるなど。
  - 正直このようなコーディングの支援 AI だけではプログラマの仕事は AI に奪われないだろう。全然奪うというよりプログラマの手助けをするだけなので、これではまだまだプログラマがいないとアプリケーションは完成しない。

# ChatGPT レベル

- では ChatGPT のようにある程度まとまったサイズのコード片を生成してくれる AI が普及するとどうなるか
  - Twitter ではさまざまなプログラマがコード片の生成を試みているがその内容を見るとそのまま使えるコードが半分、修正が必要なコードが 1〜2 割、完全に間違っているコードが 3〜4 割という感じだ
  - 今のクオリティだと人が書いた方がまだ早い、もしくはプログラマによる手修正が結構必要そう。なのでプログラマがいないとまだアプリケーションは完成させられないだろう
  - ただし修正すること前提で簡単なタスク用のまとまったコード片を生成してコーディングの時間短縮、といった使い方はできるかもしれない
  - ある意味これもコーディング支援というレベルではある
    - というか GitHub Copilot が GPT-3 を使ってるから実質同じといえば同じ

# かなり高精度にコード生成できるレベル

- ではそのまま使えるコード片を ほぼ 100%のクオリティで生成できる AI が登場するようになるとどうか
  - ここまでくると AI に生成してほしいコードの内容を伝えてコード片を大量に生成してもらい、それをプログラマが組み合わせてアプリケーションという形にする流れでも現実的になってきそう
    - 例えば「メールアドレス認証するコード書いて」「CRUD なフォームのモデルとコントローラとビューを書いて」等々でいくつかの動くコード片が生成される
    - 人間はこれらをつなぎ合わせるだけでアプリケーションが完成するイメージ
      - こうしたコード片をつなぎ合わせる仕事はアセンブリエンジニアとでも呼ばれるようになりそう
  - **AI には体力が無いかつマシンさえあれば並列で大量に実行できるという人間には成し得ない強力な生産性がある**
    - 金とマシンさえあれば 24 時間並列で一気にコード生成してもらえるはず
  - よって例えば今までだと新規でアプリケーションを完成させるのに必要なプログラマが 1 人月必要だった案件でも AI にコーディング部分を大幅に代替してもらえるなら一部コード修正やレビューが必要にしても、数人日で完成させられるようなことはあるかもしれない
  - この辺りから一部のプログラマの仕事は AI に奪われたと言われるようになるだろう
- とはいえこれらは**新規開発の場合のみの話**だ
- 仕事におけるプロダクションで稼働するシステム開発の難易度の高い部分は既存システムへ追加・修正などの改修を入れるところである
- どんなに正確なコード片を生成できたり、あるいはアプリケーション全体のコードを生成できたとしてもそれは新規開発時のコーディングの代替であり、一度本番に乗ってしまったコードを運用していく際にはちょっとやそっとのコード片の生成レベルでは代替は難しそうだ

# 既存コードのコンテキストも読み取ってコード生成できるレベル

- では改修要望を書くと既存コードのコンテキストを加味した状態の追加修正が入ったコードが丸っと生成されるようになるとどうか
  - これが出来るならアプリケーションのコーディング部分を担当するプログラマはほぼ不要になるかもしれない
    - 生成されたコードを既存コードに適用するくらいで済むレベルを想定
  - 残りの仕事に必要なのは下記くらいか
    - 生成されたコードが安定して実行し続けられるように周辺環境を作るインフラエンジニア
    - 生成されたコードに問題はないか確認するコードレビューエンジニア
    - 生成されたコードが想定通りに動くか確認する QA エンジニア
    - AI のコード生成や生成したコードを管理するプロンプトエンジニア/アセンブリエンジニア?
      - AI の癖を知り既存コードとの相性の良いプロンプトを管理するご機嫌伺い役
- ここまでくると新規開発だけでなく既存システムの改修に関するコーディングはある程度代替できるのでさらに従来のプログラマの仕事は減らせるかもしれない

# さらに先の話

- さらに AI がプログラマの仕事を奪うにはどんなことが必要か
  - 生成されたアプリケーションを実行管理し安定運用してくれるインフラをなんとかしてもらう必要がありそう
    - 生成されたアプリケーションと想定するサービス品質などを指定すると自動でインフラを展開して運用までやってくれるような仕組みはできるか？
    - サーバー・ネットワーク・DB などの知識を隠蔽できるか？
    - トラブルシューティングは可能か？
      - この辺りができないとインフラ系のエンジニアの仕事はなくせなそう
  - アプリケーションが正しく動いているか保証できる必要がありそう
    - 想定外の挙動はないかコードレビューする
    - 生成されたコードが想定通りの動作をしているかテストを書く
    - 生成されたコードが想定通りの動作をしているか動作確認を行う
    - 誤作動した時にストップできる
      - この辺りを担保できないと品質保証系のエンジニアの仕事はなくせなそう
- その他仕事に関してはどうか？
  - 他の役職に関しては詳しくないので何もいえない
    - というか自分の理解が浅いかもしれない職に関して簡単に奪われる職として挙げるのは憚られる

# 雑多な話

## 生成されるコード

- AI が生成するコードは既存のプログラミング言語で書かれたコードである必要はあるのか
  - コード片を人間が読まなくても良いレベルのクオリティなら既存の言語で吐き出す意味はないのでは
    - トラブルシューティングしづらそう
    - 過去の資産(GitHub 上のコードとか)を利用するなら既存のプログラミング言語の方が吐き出しやすそうではある
- AI が吐き出しやすいようなコードを書くという価値観が新たにコーディング規約に追加されたりするかも
- そもそも実行バイナリを吐き出すだけではダメか？
  - 実行バイナリをブラックボックステストであとは QA エンジニアが検証するだけのお仕事で良いのでは
    - とはいえトラブルシューティングしづらそうなのはキツいか

## 開発体験

- 開発体験(DX)の向上は必要か？
  - AI が大方のコード生成をしてくれるなら開発体験の向上にコストをかける必要はあるのか
  - プログラマがコードに手を入れなくても良いなら lint とか formatter とか型とかもいらないのでは
- プログラミング言語やフレームワークの選定はどう変わるか？
  - AI が一番精度良く吐き出せる言語が人気になるか
  - ただまぁこれは今と変わらず要件次第になりそうではあるな

## プログラマの仕事

- プログラマの仕事はどう変わるか
  - コードを書く比重が減り、コード片を生成する作業とシステムを組み上げる作業に比重が移りそう
  - 要件を分解しシステムを構成するコード片を生成するためのプロンプト作成作業が大量に発生しそう
  - より必要になる能力
    - 業務知識への明るさ
    - 調整能力(コミュニケーション力含め)
    - 要件の分解とそのそれぞれへの解決策を文章化する能力
    - **システム全体**の設計力
  - 今も似たようなことをやってるはずだし必要な能力は変わらなそう
  - コード化する部分がめちゃくちゃ爆速になるだけか？
- フロントエンドエンジニアとかバックエンドエンジニアみたいな職域の境はなくなり、システム全体を設計して形にできる全部できる強いフルスタックな人が 1 人いればアプリケーション開発には十分というチーム構成になる可能性はあるかも
- システムの安定性を向上させたり保証する仕事の重要性が増しそう
  - 要は**AI の尻拭い**
    - テストや QA を手厚くやって AI の生成したコードの穴を塞ぐ仕事
    - コードレビューの仕事
  - QA 用 AI が出てくる可能性もあるが、その AI の QA を誰がやるのか？とかその AI は業務依存の実装になりそうなので維持管理は内製になりそう
    - AI より安いマンパワーを使った方がコスパ良いとかありそう
- インフラ周りは構築はまだしも運用を完全に AI に代替させることで仕事を奪わせるのは難しそうに感じる、というか想像できない
  - ただ自社で DC 持ってるとかよっぽど特殊な要件のアプリケーションでなければクラウドベンダが良い感じのソリューションを出してきそうではある。昔に比べたら今でも十分インフラは深い知識なくてもある程度構築運用できるし。
- 責任を取ること
  - AI のミスの尻拭いは人間がやる

## 完全に未知の概念に対応できるか

- 「イスカルテンダ王国のスルマオン暦のランフォイを求めるコード」みたいな未知の概念は AI に正しく対応できない(はず)
- AI が知らないものは人間が頑張るしかない

## AI の学習ソースはどうなるのか

- 現状は GitHub やインターネット上のコードを学習してモデルを作ってると思うが、近い将来学習ソースが枯渇するという話がある
- 将棋 AI は将棋 AI の生成した棋譜をさらに学習したりしているが、AI が生成したプログラミングのコードをさらに学習したりすれば解決するか？
  - 将棋における[floodgate](http://wdoor.c.u-tokyo.ac.jp/shogi/floodgate.html)みたいな AI が作ったソースコードが実行されたり共有されたりするものが生まれるか？

## 信頼性

- AI が生成したコードをどこまで信頼できるか
  - 例えばある手術に使われる機器のソフトウェアが一切人間の手が入っていない AI による自動生成コードで作られているとして、自分の娘がその機器で手術を受けると知ったら、今の AI のレベルなら 100%手術をやめさせると思う
  - その信頼性を**担保するための仕事**(コードを人間が書くべきといっているわけではない)はしばらくは人間の仕事になりそう
  - 特に人の営みと高度に接続する必要がある場面では避けられないように思う
    - AI にはパーソナリティや家族のような守るべきものが(現時点では)ないという点がある種の弱点(利点)な気がする
- AI は人との営みの中で何か重要なことを行うためには責任感が足りなすぎる
  - 失敗しましたごめんな！で済まない場面への対応を整備する必要がありそう
  - そうなると責任は開発(会社|者)が取るしかない。AI の尻拭いは人間がやる。
- ある程度無責任でも良い場面には使えるが強く責任が伴う場面では、失敗した場合のケアや予防策を構築する必要がある

## シンギュラリティ

- AI が考え、AI が解決案を生み出し、また AI が問題を見つけ、AI が解決を試みるみたいなシンギュラリティ的な世界は一部の分野ではもうすぐあり得そう
- 社会の中でも広く適用されるためには失敗の責任を自分で取れる、自分で尻拭いできる能力が AI に生まれたら世界は変わりそう。まだまだ SF っぽいだいぶ先の話な気もする。
- プログラマはAIの失敗の尻拭いをするために謝罪の練習をしておくと良さそう(?)

 # [追記] コード生成ではなくシステム生成できるレベル

- 昨夜もう少しちゃんと考えてみたが、そもそもコード生成というのをやめてシステム全体を生成して展開するところまで一気通貫でやってしまえるならどうか
  - 例えば仕様書とシステム構成をアップロードしたらアプリケーションコードが生成されインフラが構築され一気にAWSか何かに展開される感じ
    - 生成されたシステムをブラックボックスでテストして振る舞いなど問題なければOKみたいな。
    - これで十分な案件はかなりあるのでは。
  - これなら新規開発に関してはもうコーディングが完全にいらないしインフラ周りの仕事も消える
  - 昨日書いた時はどのみち既存システムの改修とかは既存データをどうするかとか既存インフラとのつなぎ合わせとか調整の関係で大変じゃないかと思っていたが、そもそも全て改修時にスクラップ&ビルドすれば良いなと思った
    - アプリケーションコードもインフラ側も全部都度作り直す
    - そうなると既存データとどう整合性を保つかだけが問題になる
      - であればここだけ人間が頑張れば良いのでは...
      - というかここまでできるならデータに関してもAI側でやってくれそう
  - もうこの段階まで来ると変更容易性だとか**保守性に関する概念すら全て過去の遺物**
  - あとは品質管理だけどうするかだけど、これもテストと品質水準をまとめてAIに提出し検証してもらう感じで良いのかも。
    - ブコメなどでも書かれていたが確かにここまでくるともう人間が把握できる規模ではないかもだし、どのみち機械に頼らないといけない部分も出てきそう。
    - このへんも時間の問題なのかもしれないな...

# [追記] システム開発がなくなる世界線
- ここまで簡単にシステム開発を適用できるようになると、そもそも世の中的に必要なソフトウェアが全ての業界に行き渡りあらかた開発され切ってしまったという世界線もあるか
- ある意味今でいうところの白物家電みたいな。
- そうなるとシステム開発という業種自体かなり下火になりそう


どのようにしてプログラマはAIに仕事を奪われていくかの妄想

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">動画、活字と比べるとタイパ悪すぎて嫌いなクラスタ。文字ならざっと流し読みして1分で概要わかることを動画で10分解説されるとか… <a href="https://twitter.com/hashtag/%E5%B9%B4%E5%AF%84%E3%82%8A%E3%81%AE%E6%84%9F%E6%83%B3?src=hash&amp;ref_src=twsrc%5Etfw">#年寄りの感想</a> <a href="https://t.co/zNbGbrYuBa">https://t.co/zNbGbrYuBa</a></p>&mdash; Kazuho Oku (@kazuho) <a href="https://twitter.com/kazuho/status/1584263349742628864?ref_src=twsrc%5Etfw">October 23, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

このツイートを見て自分は活字と動画のタイパというものについて色々と思うところがあったので個人的な感想をまとめておく。

まずタイパという言葉については正直初めて聞いたが、time performance(=時間効率)みたいな和製英語だと思う。なので意味としては「動画の方が活字よりタイパが良い」とは「動画の方が活字より早く情報が読み取れる/理解できる」程度の意味合いで使われていると思われる。

このツイートに対してTwitter上での意見を見ると圧倒的に同意が多く活字の方がタイパが良いに決まってるという人が多く見えた。これだけ活字の方が良いと言っている人が多いのであればそれはそうなのだろうなと思う。

中には一概に活字 >>> 動画ではなく、コンテンツによるよねと言っている人もいた。例えば技術ドキュメントのような説明書タイプのものは検索性が重要なので活字の方がよく、もしこのようなコンテンツが動画だとインデックスがなくてしんどすぎる。一方で料理の作り方や編み物の作り方は実際のビジュアルや実践風景があった方が理解しやすいから動画の方が良い。これも一理ある。

そうした意見の中で自分の**現在**のポジションとしてはどうかというと**活字で情報提供してくれるなら活字で提供してほしい**である。だが同時に動画の方がタイパが良いという人たちについてもかなりの理解ができるという感情もある。

どういうことかというと自分はこれを完全に能力の問題だと捉えているということだ。つまり運動ができる/英語が話せる/プログラミングができるみたいな先天的もしくは後天的な訓練によって得られる能力問題なのだと考えている。

というのも自分は今でこそ動画より活字の方が情報理解の速度が速くなっているがほんの数年前まではツイートの参照先で言われている動画の方がタイパが良いと思っていたタイプだ。その当時のことを思い出すと先の「コンテンツによる」という意見で出ていた実践風景のある方が理解しやすいコンテンツだけでなく説明書的なコンテンツでさえも動画の方が早くない？？と思っていた。

どうしてそう感じていたのかというとこれはそもそも**活字から情報を吸い上げる能力**と**動画から情報を吸い上げる能力**に大きな差があったからだ。例えば活字から情報を吸い上げると毎分2情報で動画から情報を吸い上げると毎分10情報得られるような感じ。こういう人は1分あたり3情報以上詰め込んである情報圧縮された動画を見た方が活字から情報を得るよりタイパは良い。

活字の方がタイパが良いと言っている人は活字から情報を吸い上げる能力が毎分20情報で動画から情報を吸い上げる能力が毎分10情報とかなんだと思う。

またTwitterでこの手の話題が挙がると活字の方がタイパが良いという意見が優勢になるんだけど、これは自分の気持ちを文章にしたり文章から情報を吸い上げる能力が一定以上ある人間、つまり**活字から情報を吸い上げる能力**が十分にある人間がTwitterには多いからだと思う。それならTwitterでは活字の方がタイパが良いという意見は刺さりにくいというのも理解できる。日本の7割くらいがYoutubeを使っている一方でTwitterはせいぜい3,4割程度(アカウントの重複含む)という利用者構成なのに活字の方がタイパ良いという意見がTwitterでこんなに多いのはTwitter独自の偏りがかかっているはず。

なおこうした話題に関して活字派と動画派の人間のどちらが優れているのかという旨の議論もされていたがこれには意味がないと思う。足が速いか否かみたいな話であり優劣の問題ではない。基本的には活字より動画からの情報吸収が得意な人は動画から情報吸収すればいい。ある意味選択肢が昔より増えたということであり良い時代になったということなのかもしれない。

とはいえ一部で動画でしか提供されていないコンテンツが増えることへの危惧というのがあるのも理解できる。先に挙げた通り動画の検索性の低さは一部のコンテンツでは致命的なほどのユーザビリティの悪さをもたらす。さらに活字の逆で動画から情報を吸収する能力が低い人にとっても厳しいはず。なのでそういう人は動画コンテンツが増えることに対して逆の生きづらさを感じるかもしれない。理想的には動画でもテキストでも情報提供されれば両者共にハッピーなのかもしれないがコンテンツ作成コストを考えると中々難しいところではある。

現状地球上に存在する書籍の量やインターネットコンテンツ量を考えると圧倒的に活字から情報吸収する能力が高い人間の方が**有利**であることは確かなので義務教育でこうした能力を開発するカリキュラムに重点をおくべきだというのは理解できる。世界的な標準語が英語なので英語が必修になっているのと同じだ。とはいえ英語が義務教育なのに多くの日本人が英語を話せないように義務教育で何かしら手を施しても活字力の定着もまた個人差が多いにあろうことは理解に難くない。

より個人的な話にはなるが自分が活字から情報を吸収する能力が動画以上になったと感じられるようになったのは26,7歳の大人になってからだ。大体ここ数年の話である。最低限の義務教育は受けてきたし大学も偏差値で言うと60以上の国立大に進学したので人並みに勉強はした方だと思うがそれでも最近までは動画 > 活字だった。そもそも学力とこうした能力に関係はないのかもしれないが。

転機としてはプログラマとして仕事をしていく上で知的生産性の衰えが一番マズイと感じることが増え、[読書に浸る時間を増やし](https://razokulover.hateblo.jp/entry/2018/12/15/153203)、[詰将棋をやったり](https://razokulover.hateblo.jp/entry/2017/01/03/153810)、[数学をやってみたり](https://razokulover.hateblo.jp/entry/2020/03/07/172956)とかなんか脳内の筋肉量増加に寄与しそうなことを色々手探りでやったあたりだ。それでもこの程度である。今でも動画はかなり見るしちょっと難しいことは動画を探す。

職業柄のディスアドバンテージがあるからこれだけ挽回に力を注げたが、それほど喫緊の課題ではない人には無理難題だと思う。

右往左往活してしまったが言いたい事があるとすると、活字から情報吸収する能力がある人は活字から情報を摂取すればいいし、動画から情報吸収する能力がある人は活字から情報を摂取すればいい、自分の置かれた立場に合わせて合理的な判断で好きなように情報摂取すれば良い。それは優劣ではなく得意不得意の問題で、ただそれだけの話。という感じ。

活字と動画のタイパについての個人的感想

たまに転職する際の企業の選び方について聞かれることがある。自分は転職を大して経験してるわけではないから具体的なアドバイスはできないだけどとりあえず**自分なりの**企業の見方について少し話すことにしてる。

それはあらゆるものを資本と資産と収益の関係でみるということだ。

といっても別に財務諸表を読むスキルをつけろと言っているわけではなく(あれば良いに越したことはない)、企業というシステムがどういうロジックで動いていて、組織やそこで働く人々が何をやっているかの大雑把な流れを把握するという話である。

# 資本を得る・資産を作る・収益を得る
まず企業の生産活動というのが何をやっているか？という大雑把な流れを整理すると下記に集約できる。

- 資本を得る
- 資産を作る
- 収益を得る

基本的にはこの３つを回しているだけだ。

例えば銀行からお金を借りて(資本を得る)、商品を作り(資産を作る)、販売して対価をもらう(収益を得る)といった具合。

資本を得るについては借入やVCや市場からの調達や得た収益が資本になったりする。
資産を作るについては製品を作ったりサービスを作ったりすることがそれにあたる。
収益を得るについては資産を活用してそれを金に変える部分のことだ。

資本を得る→資産を作る→収益を得るという各フェーズの中で営業やマーケティングや開発/生産や経理やらなんやらといった職務の人がおり、彼らがそれぞれの役割で働くことで会社が回っていく。結果的に業績が上がったり下がったりという具合になるわけだ。

# 転職に生かす
で、この企業の見方を前提にして転職に際しては自分がどの役割を担うことになるのか？ということを考える。

例えば自分の場合ならソフトウェアエンジニアなのでほぼ「資産を作る」というフェーズに従事することになるとわかる。だから企業を選ぶ際は、どういう資産(サービスや製品)を作っているか、資産(サービスや製品)の成熟度はどの程度か、どういう体制で資産(サービスや製品)を作っているのか、将来の(資産的な)展望を最初に見る。

まぁこれは誰でもやると思うが、しかしこれだけでは不十分で、一番大事なのは**その資産がどうやって収益を産んでいるのか**まで見ることだ。なぜなら資産が収益を産む構造が乏しい場合は資本が減り資産を作ることに投資する原資が減るから結果として、開発全体への体験が悪くなるし給与も上がらなくなるから。

なので一般的にエンジニアとして良いDXと良い給与を得たいなら資産が収益を生み出す構造が強固な会社を選ぶ方が良い転職になりやすいと思う。

といった感じで資本と資産と収益の観点で企業活動を見ると、自分が企業活動のどこを担い、それがその活動にどれほど寄与できるか理解しやすいし、その寄与が回り回ってDXや給与へどれほどつながりそうかというところまで意識できるようになる。

# 業務に生かす
資本を得る→資産を作る→収益を得るという考え方は普段の業務にも当てはめられる。例えばエンジニアの生産活動は企業全体で見ると資産を作る部分にあたるが、この資産を作る部分のエンジニアチームとしての生産活動をさらに分解して、資本を得る→資産を作る→収益を得るという構造にマッピングしてみる。

- 資本を得る→ 人材(スキル)・時間を得る
- 資産を作る→ 開発
- 収益を得る→ リリースと運用

少々強引だけど無理矢理マッピングしてみるとこんな感じになるはず。

で仮に自分の役職がインフラエンジニアであれば収益を得るの部分が責任範囲になるし、フロントエンド/サーバーサイドエンジニアであれば資産を作る部分が責任範囲になる、といった具合に考えることができる。

各人はその責任範囲における生産活動を行い、またその責任範囲の中で生産性を向上させられることであれば基本なんでもやっていく道理はあるはずだ。もし新しい言語やフレームワークの導入や技術的負債の返済をしたいとなった時に、この観点で自分の立ち位置を理解できていれば、自分の責任範囲の生産性をどれほど向上させそれが組織にどういう寄与をするかを説明しやすくなる。結果として上司への提言にも説得力が出るので受け入れやすくなると思う。

ここでも大事なのは**資産を作る→収益を得る**の部分。どんなに開発を頑張ってもリリースされて安定運用に乗らなければ意味がない。金をドブに捨てているのと同じことになる。という意味ではデプロイ頻度が向上する仕組みづくりが重要で近年CI/CDの仕組みの重要性やSREが取り沙汰されるのはこの資産を作る→収益を得るの間の生産性を向上させる役割を担うためだと思う。

こうした資本を得る→資産を作る→収益を得るという構造は、エンジニアの生産活動に対してもマッピングできたように他の役職でも多分できるはずで、各種部門内における資本を得る→資産を作る→収益を得るという構造のリソースを調整していく仕事がいわゆるCXOという役職だ。もちろんだけどCTOは会社全体の資本を得る→資産を作る→収益を得るという構造を調整している。

# 人生の場合
資本を得る→資産を作る→収益を得るという構造は日々の生活にも見出すことができる。無理矢理マッピングするとこんな感じか。

- 資本を得る→ 金・時間を得る
- 資産を作る→ 買い物をする・遊ぶ・勉強する
- 収益を得る→ 金を得る

労働者であれば、働いて金を得て、その金を使って何かを買ったり遊んだり勉強したりして自分という資産を豊かにして、それを労働力として使い金を稼いで...という感じ。もし株式や不動産を買ってそこから収益を得られるなら、収益を得る手段が資産それ自体になったりする。いわゆる不労所得。

ちなみにピエール・ブルデューの文化資本は資産を作る部分の資産の初期値パラメータになりそう。

まぁ人生は大体こんな感じだと思う。

ここでも重要なのは**資産を作る→収益を得る**の部分でどんなに勉強しても収益に繋げる仕組みがないなら金は得られない。自分という資産が収益を産み出すためのの生産性というものを考えるなら、資産を作る部分に力を入れるのと同じだけそこから収益を得る部分にも力を入れないといけない。

とはいえ人生が他の生産活動と違うのは別にそんな生産性なんて考えなくても良いことだ。企業活動では無理だけど人生なら自分が満足すれば何も産まなくても別にいいし生産性なんて考えなくても良い。

資本を得る→資産を作る→収益を得るという構造は人生にも見出すことはできるけど、それに意味があるのかどうかは疑問ではある。

# 最後に
資本・資産・収益の構造で身の回りの生産活動を見渡してみると、割と何にでも当てはめることができるとわかる。が、そのマッピングに意味があるかは別問題だ。

せいぜい暇人の思考実験にはなるのでこの3連休が暇でどうしようもない人にはちょうど良いかもしれない。

あらゆるものを資本と資産と収益の関係でみる

# 背景
今までは出勤やらなんやらで外を出歩くことが多かったが、リモートワークでそれらが完全になくなった。宅食を使ってるから食事も家でなんとかなってしまうし2日間外に出ないなんてこともまぁまぁあるので良くない。

厚生労働省の[身体活動・運動](https://www.mhlw.go.jp/www1/topics/kenko21_11/b2.html)によると生活習慣病やメンタルヘルスの予防には普段からの身体活動量の増加が重要らしい。が、一部周囲の先輩方によると40を超えていきなり運動を始めようとして膝や腰を痛めたりしてさらに不健康になってる人もいた。歳をとると健康のために運動しようと思ってさらに怪我をするという惨状が結構あるみたいで、これを避けるには早いうちから運動習慣をつけた方がいい。

自分は元々十数年前は大学で陸上部に入っていたので基礎的な心得はある。厚生労働省の先の資料にもある通り完全に運動経験のない人は歩くことから始めるべきだが自分の場合はそういう背景もあるのでウォーキングよりもジョギングくらいから始めても大丈夫そうと判断し久々にランニングシューズに足を通してジョギングを始めた。

# 準備
まずはジョギングを始めるための準備で買ったものがいくつかあるので書いておく。

## シャツ
一つはシャツ。ジョギング用のTシャツはいくらあっても困らんのでユニクロで3,4枚まとめて買った。[ドライEX系のシャツ](https://www.uniqlo.com/jp/ja/products/E449017-000/00?colorDisplayCode=66&sizeDisplayCode=004)がサラサラしてて良さそうだった。まぁ普通に気にならない人ならすでに持っている自前のTシャツでも良いと思う。

## 骨伝導イヤホン
![IMG_3418_res](https://user-images.githubusercontent.com/1421093/190836175-4a561518-ec86-4f53-bfc9-fd8b2e23c35b.JPG)

あとは骨伝導イヤホン。Shokzの[OpenMove](https://amzn.to/3qNIeTz)というのを購入した。実はこれはジョギング専用ということではなく元々気になってはいたんだけど、ちょうど楽天で30%OFFになっており良い機会なので購入した感じ。普通のイヤホンだと耳に入れないといけないが、汗をかくと気持ち悪い感じになるし走ってると抜け落ちそうになるので怖い。OpenMoveなら耳の上にかけるだけだし走ってもブレないので良い。加えて周囲の音がしっかり聞こえるので脇道からの急な自転車の飛び出しなどにも気付きやすいというのもある。

骨伝導イヤホンの便利さについてはこの記事がわかりやすい。自分も似たような意見だ。
- [骨伝導ヘッドセット着けっぱなしな生活を始めて1年が過ぎた](https://honeshabri.hatenablog.com/entry/aftershokz-air2)

## スマホを入れるやつ
本当は走るときは何も持たない方が楽だけど、出先での何かあった時に困るのでスマホは持ち歩きたい。普段はスマートウォッチとしてシャオミの[Mi Band](https://amzn.to/3DydBZQ)を使っているのだけど、これはスマホを携帯していないとワークアウト時の計測の精度が出ない。実測してみたがスマホを携帯している時と比べてだいぶ少なめに走行距離が計測される。たくさん走ったのに過小記録されるとモチベが落ちるので避けたい。

世の中の人々はスマホをどうやって持ち歩いてるのか調べてみたところ、[腕につけるタイプ](https://amzn.to/3LnCFEB)と[腰につけるタイプ](https://amzn.to/3Dz0U12)の人が多かった。前者は「ランニング アームバンド」とかで検索すれば良いし、後者は「ランニング ウエストポーチ」で検索すれば良い。が自分はどちらも買わずにダイソーで[200円のウエストポーチ](https://jp.daisonet.com/collections/accessory0205/products/4549131941081)を購入し、それを襷掛けして使っている。少し揺れるのでだるい感じもあるがある程度使うと慣れるし、最初は安物でいいやと思ってこれを使ってる。

## ランニングシューズ
10年前に購入したランニングシューズがあったのでそれをそのまま利用。

## ズボン
陸上部時代の短パンがあったのでそれをそのまま使ってる。

# 走る
実際に準備が整ったので走り始めた。走る前には入念にストレッチをする。準備運動を怠ると体に支障を起こすので絶対にやる。

走るコースは近所にちょうどよくランニングに適した歩道があるのでそこを適当に走ってみることにした。時間帯は朝に走るのは精神的にキツすぎるので仕事終わりの夜。涼しいし人も少ないので集中できる。寝る前すぎると交感神経が高まってしまい睡眠の質が落ちそうなので寝る2時間以上前には走ることにしてる。

初日。走り始めて500mくらいで両脚が死んだ。痛いんじゃなくて400mとかを走って乳酸が溜まり激重になった感じが両脚全体を襲っていた。自分がこんなに走れなくなっていることに絶望しながら結局10分/km程度の激遅ペースで2kmくらい走って終わった。惨敗である。

それから1日おきくらいに走り続けて今は大体10回目くらいなんだけど今は8分/kmのペースで5kmくらいは走れるところまで改善した。足の筋肉が衰えまくっており初日の惨劇を引き起こしていたが心肺機能の方はそれほど衰えていなくて思ったよりも早く走れるようになってきている。

当面は最低10分/kmで1時間くらいは走り続けられるようになることを目標にしている。別に大会に出る予定もないので楽なペースで一定時間走り続けられれば良い。

# Podcast
ところで走りつづけている際にPodcastを聴くようにしてるのだけどこれがとても良い。大体どのPodcastも1~2時間くらいなので倍速で聴きながら走り終えるとちょうどいい感じでPodcastを一つ消化できる。走ることとPodcastを聴くことしかやれないので、PCやスマホやその他の雑事が集中を妨げることもない。集中してPodcastを聴ける。

聞いているチャンネルは主に技術Podcast。今は下記のPodcastあたりを聴いているところ。

- [rebuild.fm](https://rebuild.fm/)
- [texta.fm](https://podcasts.apple.com/jp/podcast/texta-fm/id1530076592?l=en)
- [misreading chat](https://misreading.chat/)

Podcastにそんなに詳しくないので技術系のPodcastでおすすめのものがあったら教えてほしい所存。

# 感想
走ると単純に気持ちいい。元々走り慣れているのもあるが走ると不要なことを考えずに集中できるので脳が整理される。

幸い足の関節が痛くなったりということは発生していない。おそらくBMI17.6くらいの低体重なので足への負荷が少ないのと普段から家で体幹トレーニングやスクワットなどをやっているから基礎筋力はついているのだと思う。走り方も昔取った杵柄で悪くないというのもありそう。

ただ足の裏の皮が軽く剥がれたりしててそれはちょっと痛い。豆みたいなもの。これはどうしようもなさそうだが走り続けていけば落ち着くと思う。

あとジョギング後に食べるアイスが美味しすぎてやばい。これはいわゆるサウナ後に飲むオロポみたいなもので麻薬的な"良さ"がある。気をつけたい。

これからはより走りやすい季節になってくるし走るのが楽しくなっていきそう。

ジョギングを始めた

![ダウンロード](https://user-images.githubusercontent.com/1421093/188124391-18c7e3d6-c6b9-4cc9-b0f6-27db4fa6a3f8.png)

コロナで家にいることが多くなって以来、暇があればスマホのTwitterを開くことが多くなっていてあまり良くない習慣だなと思い端末からTwitterのアプリを消した。

以前はせいぜいモバイルのTwitterは移動中や外出先で待ち時間などに触る程度だったが、家で作業していると一休みがてらTwitterを開くようになってしまった。これは生活環境的な理由の他にTwitterのアルゴリズムに依るところも大きい。

以前はリアルタイム順の投稿だったりフォローしている人のツイートがメインだったが最近は1日以上前の知らない誰かの投稿がバンバンTLに流れてくる。それの何がよくないかというとどれもいいねやRTの多い目を引く内容だということだ。

目を引くインパクトのある内容は刺激が強くて、いわば味の強いスナック菓子みたいなものだから引き込まれやすい。その結果そのツイート群を次々に読んでいってしまう。ちょっとTwitterを見てただけなのにいつの間にか数十分経っていたりしてびっくりする。ユーザーの滞在時間を指標にしているTwitter側のアルゴリズムとしては優秀だがQoL的には最悪である。

良くないと感じているのは内容だけでなくTwitterの性質によるものもある。ツイートは140文字前後の文章で一つのコンテキストが完結している。この閉じた内容のテキストが矢継ぎ早にどんどん流れてくる。以前は「めっちゃうんこでた！！」みたいなどうでもいいようなテキストも流れてきたからあんまり感じなかったけど、今はある程度まとまりのある、しかも刺激の強いまとまったテキストが次々に流れてくる。次から次へと脳に流れてくるテキストは感情を強く揺さぶり、そしてすぐまた別のコンテキストのテキストが感情を揺さぶってくる。

数十ツイートそうしたテキストを浴びると、最初に読んだツイートはなんだったか覚えておらず、しかし何か興奮した感覚だけは残るという状態になる。このような脳の使い方は記憶力の低下や思考を短慮にしてしまうことに繋がりそうに感じるし、一つの事柄に対する集中力の衰えにもつながるように感じた。

読書と思考力の間の関係性にどういった効果があるのか科学的なところはわからないが、思うに一つのテーマについてある程度時間を使い考えるという体験が深い思考力を養うことにつながるのではないか。その意味では今のTwitterを長い時間見続けることはその逆の効果をもたらしそうに感じる。

もちろんTwitterでも一つのツイートに対してじっくり時間をかけて考えることもできるが、サービスの性質上それが難しい作りになっている。なので少しでもTwitterのストリームに溺れないようにアプリだけでも削除してみるという選択になった。

昔はTwitterアプリ経由のSSOでログインしないといけないサービスもあったが今は非推奨なので問題なさそう。結局PCでTweetDeckを開くのではというのは確かにそうなんだけど、自分はスタンディングデスクでPCを使うからモバイルアプリほどくつろいで閲覧できないし、Twitter以上に開発をするという誘惑もあったりするからそれほど熱中しなくて済む。

それなら退会すればいいのではみたいな話もあるが、もうかれこれTwitterを10年以上やっていて、少なからずそこでしか繋がりのない関係性もあったりするので辞めるのは不可能。そもそも現実では人間関係のようなものが全くないからTwitterまで失うと社会性が終わるので無理、という感じ。Twitter無しで生きてる人はどうやって人間と関わっているんだ...。

あとちなみにアイキャッチ画像はstable diffusionで「Twitterに囚われている人」で生成した。

スマホからTwitterのアプリを消した

RustやTypeScriptに関するちょっと込み入ったドキュメントや記事を読んだりすると「部分型」だとか「多相」のようなワードが頻出するのだけどこれらの意味があんまりよくわかっていなかった。

普段よく書いているプログラミング言語のはずなのにその(主に型の)解説で使われている単語が全くわからんというのはどうなのかというあたりに[型システム入門](https://amzn.to/3dPn7wK)(通称 TaPL)を読み始めたモチベーションがある。

しかしまぁ普段プログラミングをしていると型キャストしたりジェネリクスを使ったりとか、何かしらの形でそういったワードに由来する言語機能を**使う経験**自体はすでにあり、今更小難しい話を知らなくても使い方はわかるので大して困ることもないわけで。

それにこの先プログラミング言語を本格的に開発する予定もないし、その理論的な意味といったものに特別興味を持つことはなかったわけだがふと[TypeScriptの型メモ](https://qiita.com/dico_leque/items/06ac5837b7a333c5c8da)というQiitaの記事なんかを読もうと思うと知らない単語が大量に出てきてぐぬぬ...となるのが不便というのもまた事実。

Blockchain関連の開発の情報を追うのも少し飽きてきてたところなので良い機会と思い重い腰を上げた。

Amazonから届いて読み始めた当初は噂に違わぬ難解な書籍であるな...と感じた。その辺りの苦慮は[型に関連するよく分からん用語がありすぎる](https://scrapbox.io/razokulover-tech-memo/%E5%9E%8B%E3%81%AB%E9%96%A2%E9%80%A3%E3%81%99%E3%82%8B%E3%82%88%E3%81%8F%E5%88%86%E3%81%8B%E3%82%89%E3%82%93%E7%94%A8%E8%AA%9E%E3%81%8C%E3%81%82%E3%82%8A%E3%81%99%E3%81%8E%E3%82%8B)に書いている...。

とはいうものの実際10章くらいまでの型付きラムダ計算を理解し操作的意味論を読み下せるまで根気強く粘ることができれば、あとはそれ以降は全ての証明や演習問題は理解できるとは言わなくとも、各概念のエッセンスについて理解する土台は整う気がする。それでも全く簡単ではなく、特に後半はMLやHaskell等の関数型言語の経験がない自分には見たこともない概念だらけで苦戦した。

ちなみに型付きラムダ計算に関してはYoutubeに名大の木原准教授の講義動画があり、これが本当に大変素晴らしく、「あれ？俺、ラムダ計算完全に理解した！？！？」と錯覚させられるのでおすすめ。

- [名大・講義 計算論](https://www.youtube.com/playlist?list=PLQJysrzOMzUlaYej_MMl5929fJ5A0qdLK)

第Ⅲ章 部分型以降は、TaPL読む -> 知らない概念に出会う -> 本文を読み込む -> 意味わからん -> ググる -> 「OOOはXXXみたいなイメージやで」みたいな解説を読む -> 自分なりに噛み砕く -> TaPL読む -> 知らない概念に出会う -> ...の繰り返しになる。

今でも全然理解出来ているとは思わないが以前よりは各種ワードに対するアレルギーのようなものはなく「OOOの言語で言うところのアレね」とか「なるほど、{ ∃X, T }のことね〜」、みたいな論理記号を見てやりたいことがほんのりわかるというくらいにはなってはきた。それだけでも読む価値があったなと思う。

反面、言葉の意味的なものを知りたいだけならWikipediaなりググって各種大学の講義PDFとか読めば良いのでは？みたいな感覚もあった。あくまでTaPLは型理論を大学院以上で学んでいく学生に入門的な知識を授ける本なので、型についてちょっと知りたいくらいのレベルの人には重すぎるかも。その辺はご自身の体力とご相談という気がする。

あと今後はHaskell・OCaml、あとはidrisあたりに手を出してみるとTaPLで出てきた完全に知らんかった概念を言語機能レベルで体感できて身になりそうだな〜と思った。これはこの先の宿題としてみる。

TaPLを読んでる

東京都調布市にある深大寺という寺に行った。おそらく調布駅が最寄りだがそこから歩くとなると30分以上はかかる。吉祥寺方面から行くにいても調布側から行くにしてもバスを乗り継ぐ方が良い。車があるなら駐車場はたくさんあるので車で行くべき。そのくらいの距離感の場所にあるので少々アクセス的には面倒な場所である。

しかしながらその距離感のおかげが深大寺自体は夏休み真っ只中の晴天の日でもそれほど混雑しておらず快適に過ごせた。

深大寺には文字通り"深大寺"という寺がある。深大寺には都内では唯一の[国宝・釈迦如来像](https://www.jindaiji.or.jp/about/kokuho.php)がありそれを目当てに遠くからやってくる人々がいるようだ。自分はというと深大寺それ自体よりもその周辺の店々や自然豊かな植物園を散歩したくて行った。

![mosaic_20220820183523_600 (1)](https://user-images.githubusercontent.com/1421093/185739346-b6d01671-1439-40c4-a271-76697c1080f7.png)

深大寺は蕎麦が有名だ。なんでも周辺には20店ほどの蕎麦屋が深大寺を取り囲むように軒を連ねているらしい。もちろん自分もそばを食べた。晴れていたのでテラス席で池を目の前にして蕎麦を啜った。味はまぁ普通という感じではあったが自然に囲まれた場所で蕎麦を食べられる体験は中々よかった。

![VPih22h5iI6ab0k1660988394_1660988448_600](https://user-images.githubusercontent.com/1421093/185739573-48cc4089-722d-4215-b2b4-dcec4611a830.jpg)
![IMG_3325_600](https://user-images.githubusercontent.com/1421093/185739619-433a2c26-9248-41c0-aaf3-7ab04e60cf66.JPG)

また調布市にゆかりのある水木しげるにちなんでゲゲゲの鬼太郎に関する店もあった。寺の前に鬼太郎のモニュメントが飾られていて謎のロケーションではあったが子供を中心にそれなりな人だかりを作っていた。

![mosaic_20220820184335_600 (1)](https://user-images.githubusercontent.com/1421093/185739698-2e7ad039-91a7-4600-bcb1-433d72c8b6e9.png)

![IMG_3330_600](https://user-images.githubusercontent.com/1421093/185739737-a3934f1d-6e3a-4431-9fab-92631b5cb470.JPG)

深大寺の裏手には[神代植物公園](https://ja.wikipedia.org/wiki/%E7%A5%9E%E4%BB%A3%E6%A4%8D%E7%89%A9%E5%85%AC%E5%9C%92)という都内としてはかなり広大な植物公園(有料: 大人500円)がある。有料公園ということでこれまた休日なのに人が全然いないのでとてもゆったり過ごせる。雑木林を歩いたり、広い芝生の広場でピクニックをしたり、4000種類以上のバラが拝めるバラ園があったりとただ歩いてるだけでも飽きない。カナヘビの赤ちゃんを発見して懐かしい気持ちになったりもした。

![IMG_3338_600](https://user-images.githubusercontent.com/1421093/185739782-065cdcae-4f6f-4a1b-b34b-2ad0a2156452.JPG)

![IMG_3337_600](https://user-images.githubusercontent.com/1421093/185739819-02412eee-64f6-421b-aa51-b9115cf7335f.JPG)

いろんな園がある中でもバラ園の横にある大温室という熱帯植物を中心に展示されている施設が面白かった。ここではあの2年に1度しか咲かない花で有名な[ショクダイオオコンニャク](https://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%A7%E3%82%AF%E3%83%80%E3%82%A4%E3%82%AA%E3%82%AA%E3%82%B3%E3%83%B3%E3%83%8B%E3%83%A3%E3%82%AF)が育てられている。今回訪れた際はその姿を拝むことはできなかったが巨大なプランターはその大きさを物語っていた。その他にも背丈を遥かに超えるバナナの木や食虫植物などもあり自然のパワーを感じた。

![IMG_3341_600](https://user-images.githubusercontent.com/1421093/185739892-132d5f5a-e38a-417a-aee3-c0df139030a4.JPG)
![IMG_3346_600](https://user-images.githubusercontent.com/1421093/185739917-0168506d-ecc1-45cc-b0b9-5b781a662448.JPG)
![mosaic_20220820185044_600 (1)](https://user-images.githubusercontent.com/1421093/185739977-7e0eef04-ceef-405b-b26a-54fe63a6eb08.png)
![IMG_3343_600](https://user-images.githubusercontent.com/1421093/185740015-a0e50519-c0f2-4bc4-8463-8f4e6a5540fb.JPG)
![IMG_3353_600](https://user-images.githubusercontent.com/1421093/185740065-f3e0a56a-bb42-4d7e-8c1c-2c5ca0b795d7.JPG)

バラ園の前に百台ほどのベンチが一列に並んでいるエリアがある。誰も座ってなくて異様な雰囲気だった。しかもよく見てみると8割くらいのベンチにメッセージが彫ってあってめちゃくちゃ不気味だった。座りずらすぎる...
![IMG_3355_600](https://user-images.githubusercontent.com/1421093/185740263-e0dc2642-3c38-400b-8e3e-4c64c2ecc561.JPG)
![IMG_3357_600](https://user-images.githubusercontent.com/1421093/185740291-beabbcb1-aef1-47ff-be53-85ad9ccc1965.JPG)


都内で静かに自然を感じたいと思った時に選択として挙がるのは、

- 等々力渓谷
- 高尾山
- 奥多摩
- 秋川渓谷

くらいなものかなと思っていたのだけど、如何せん等々力渓谷以外はおいそれと気軽に行けるような位置にない。しかし深大寺は自分が今住んでいる地域からアクセスがそれほど悪くない(せいぜい1時間以内で行ける)のでいい場所を見つけた気がした。

他にも都内で自然を感じられるお手軽スポット情報があれば教えてほしい。

深大寺に行った

先日Juice=Juice(ハロプロ)と山崎あおいというシンガーソングライターとの対バンライブに行ってきた。ハロプロのアイドルと他ジャンルの歌手との対バンライブは中々珍しい。どういうファンが集まるのかなと少しワクワクしていたが、ほぼ普段の現場と変わらないハロオタだらけであった。

ハロオタといえば大体おじさんであるが、自分もその中の一人だ。だからなのかはわからないがおじさんには親近感がある。特にアイドル現場にいるおじさんはみんな幸せそうな顔をしていて好きだ。

女性アイドルのライブに行ったことのない人は想像できないかもしれないが、アラフォー・アラフィフのおじさん達がめちゃくちゃニコニコで誰の目を気にすることもなくサイリウムを振ったり踊っていたりする。たまにステージで踊っているメンバーよりキレ良く振りコピをしてるおじさんがいたりするのを見るのも良い。皆同じ方向を向いてニコニコして幸せそうな顔をしている。

街中や通勤電車で見かける勤労中のおじさん、中には疲弊してヘロヘロのおじさんも結構いる。彼らは大体みんな険しい顔をしていると思うんだけど、そういうおじさん達がアイドル現場では弾けんばかりの笑顔で楽しんでいるのでその姿を見ると嬉しくなる。

おっさん同士の肩組みみたいな馴れ合いは別に好きではないけど、おじさんになると基本的にうっすら全方面から嫌われるし頼れるものが少なくなっていくからみんなで同じ方向を見て好き勝手楽しめる時間ってすごく貴重だよと思った。

楽しそうなおじさんを見るのが好き

最近ほぼ毎日カレーを食ってるんだけど、今日はなんとなくの思い付きで火鍋をカレーにしたらめちゃくちゃ美味かったので忘れないようにレシピを書き記しておく。

# 材料(2人分)
## A) 火鍋
- 豆板醤: 大さじ1
- 花椒: 小さじ1
- 八角: ちょっと
- 鷹の爪: 1カケラ
- 桃屋のしびれと辛さががっつり効いた麻辣香油(もしない場合は普通の食べるラー油+ニンニクをガッツリ): 1/3瓶
- ウェイパー: 小さじ1
- 水: 300cc前後

## B) 具(何入れてもOK)
- とり肉: 適当
- にんじん: 適当
- 玉ねぎ: 適当
- じゃがいも: 適当

## C) カレー
- S&Bのカレーフレーク(固形でも多分OKだが安物はやめろ、最低限ジャワ): 大さじ2.5

## 作り方
### 鍋にA)火鍋を全部投入して中火にかけて煮立たせる(15分くらい)
ぐつぐつの方が火鍋感が出て良い。

### B)具を火が通るまで炒める
具は何を入れてもOK。にんじんが美味かったのでおすすめ。

### B)を火鍋に投入する
具が馴染むまで少しかき混ぜる

### C)カレー を鍋に投入する
カレーが全体に溶け切るまで混ぜる。もしとろみが足りなければルーを足す。とろみが多すぎたら水を足せ。

## 写真
![IMG_3277 2](https://user-images.githubusercontent.com/1421093/183254406-995b65fb-c721-40ba-9c85-1875b49997fb.JPG)
![IMG_3278](https://user-images.githubusercontent.com/1421093/183254480-e3a1a331-8210-4d2d-97d1-9f3459398007.JPG)
![IMG_3281](https://user-images.githubusercontent.com/1421093/183254425-1b6ba9f0-e277-4092-8a9e-a806b5e0d38e.JPG)

## 感想
基本はカレーだが遠くで中華の声が聞こえるような感じの味。花椒とニンニクとシビ辛が効いていて最高。火鍋自体で出汁みたいなものが効いているので全体として味の密度が異常。

[桃屋のしびれと辛さががっつり効いた麻辣香油](https://www.momoya.co.jp/shop/products/detail/115)がかなり重要なのでお近くのスーパーで買ってくれ。カレールーは固定のやつでも全然OKだがPBの安物はやめた方が良い。火鍋に味が負けるので。最低でもジャワあたりで。

全体的に結構辛めなのでお腹が弱い人は注意。

おすすめ。

火鍋カレー

※以下、エンジニア=ウェブアプリケーションエンジニアとして書いています

[エンジニアとして今の自分を形成した本を5冊紹介する](https://panda-program.com/posts/introduce-five-books)という記事を読み、自分だったらどの本を選ぶかなと考えてみた。

この記事を読んでみた感じ、名著が多いな〜という印象を受けた。対象読者に関しては、

> 独学でプログラムを書き始めた人やエンジニアスクールを卒業したばかりの方というよりは、実務経験を1~3年くらい積んでいるけど次に何を学べば良いかわからず、自分でイマイチ伸び悩んでいると感じている人

と著者も書いている通りちょっと実務経験のある人になっているので確かにそういう人達には丁度良さそうだなと思う。

自分もこのブログの著者が書いているようないわゆる名著の部類に入る本をそういう時期にいくつか読んではいるが、それらはタメになった本ではあるものの"今の自分を形成した"とまではいえないよなーと思う。

本というのは読むタイミングが大切だ。プログラミングを始めたての頃にClean Architectureを読んだ時の感想(ふーんとしかならなかった)と負債に塗れたプロジェクトをくぐり抜けた後に読んだClean Architectureへの感想では全く異なるはずである。

またいくら名著といっても時間と共に古くなってしまう考えや方法が出てきてしまう。技術書であればなおさらだ。よくこういう記事で挙げられる「UNIXという考え方」もその一つで、[名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか？ 〜 著者のガンカーズは何者なのかとことん調べてみた](https://qiita.com/ko1nksm/items/f1800c6ff6dd649d7429)という記事ではこの本の今では古臭くなってしまっている箇所などを丁寧に検証してくれている。

古くなってしまったからもうその本は読む必要がない、というわけではないからこそ名著であるというのもまた事実である。現代に至るまでの歴史の中で今を振り返るために、また未来を見据えるために重要なヒントをくれたりする。

では"自分を形成した"本とはどういう本なのか、それはこの道へのめり込むきっかけや感動を得た本ではないかなと思う。

それが結果的に名著と呼ばれる本であることも多いが自分にとってはどちらかというとスキルが圧倒的に未熟な頃に読んだ本、いわゆる入門書のようなものがそれにあたるのではないかと考えた。今風にいうと"駆け出しエンジニア"のようなスキルレベルの頃に読んだ本である。

未熟な頃に感動した思い出があるからこそ今もエンジニアとして仕事を続けられていると思う。なのでそういう思い出が詰まった本、思い出補正全開本を"自分を形成した本"として5冊選んでみた。思い出補正全開ゆえ今回選んだ本は決して全てがおすすめできるわけではないので悪しからず。

# [初めてのRuby](https://www.oreilly.co.jp/books/9784873113678/) 
Ruby1.8と1.9に対応している。現在3.1とかを使っていることを考えると感慨深い...。この本を読んだのは大学卒業~新卒入社した位のタイミングだ。当時の会社ではPHPでウェブアプリケーションを(なんとなく)書いていた。しかし世間はどこもかしこもRuby on Railsを使っておりミーハー心からRubyについて学ばねばな〜などと思い手に取った本だ。

完全な初学者が手を出すとわからないかもと思えるような一見無味乾燥な本ではあるけど解説がとても丁寧なので当時の自分くらいのレベルでも理解できた。この本を読み切れたことで技術書を読むことのハードルが下がった。またRubyという言語の面白さとかスピリットみたいなものが垣間見えた気がしている。と同時に各種一般的なプログラミングに関する用語についての理解も深まったのでPHPを書く時やドキュメントを読む時の理解力も上がったという副次効果もあった気がする。

対応Rubyバージョンを見て貰えば分かるとおり今読むべき本ではないとは思うけどあのぐいぐいと引き込まれる体験は確実に今の自分を形成するスタート地点になっていると思う。

# [Rails3レシピブック](https://www.sbcr.jp/product/4797363821/)
Railsといえば[Ruby on Railsチュートリアル](https://railstutorial.jp/)である。ウェブアプリケーション開発者においては言わずと知れた当時の神サイトだ。当時はまだ全て無料で閲覧できたのでその点もありがたかった。

このサイトでTwitterもどきを作ったり、このRails3レシピブックと睨めっこしながら粛々と自分の考える最強のwebサービスを開発するみたいなことを毎日やっていた。その開発体験から派生してすぐあとに起業することになるわけであるが、その時も開発時にいつも横にはRails3レシピブックがあった。

これまた対応Railsバージョンを見て貰えば分かるとおり今読むべき本ではないものの、当時の自分にwebサービス開発の楽しさを教えてくれた気がするので個人的に思い出深い本であることは確かである。

# [リファクタリング: Rubyエディション](https://www.amazon.co.jp/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0-Ruby%E3%82%A8%E3%83%87%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%B3-Jay-Fields/dp/4048678841)
起業してから一人で我流でwebサービス開発を続けていく中でコードが肥大化していきどうしたもんかね...となってしまう時期がきた。恥ずかしながらこの頃は**Done is better than perfect**よろしく、動けば良い、さっさとリリースじゃ!とガンガン積み木を重ねていくようにコーディングをしていた。実際自分以外に誰もコードを触らないわけなのでなんとかなっていたわけであるが、それなりにコードが大きくなると自分一人でもこれは不味いなと感じるようなコードが増えてきた。その時に手に取ったのがリファクタリング: Rubyエディションである。

この本は[リファクタリング 既存のコードを安全に改善する](https://amzn.to/3b3ACYK)というオリジナルのRuby版である。元の本の方はJavaで書かれているのだが、PHPとかJavascriptとか当時のweb開発の言語しか触っていなかった自分に敷居が高く感じられた。一方Ruby版の方はすでに慣れ親しんだ言語で書かれているということで臆せず読み始められた。

デザインパターンやOOPなどの実装テクニックについて見聞きしたことはあっても実際にどう使えばいいのかというのがいまいち理解できずにいたが、これを読んで腑に落ちた。実際のコードベースに取り入れやすいという環境やタイミングがぴったり合ったというのも大きいがそれにしても学んだ概念がすぐに実践で活用できたというのは気持ちよかった。

# [コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方](https://amzn.to/3J5EuFa)
ある程度webサービスなどが作れるようになるともっとコンピュータの仕組みとか低レイヤーについても知りたくなった。こういうことは本来大学でCSを学んできている人には素地としてあるのかもしれないが自分には全くその手の知識がなかった。

巷でおすすめされている本やいわゆる名著というものを手に取って読んだりはしてみたが難しいしピンとこないものが多かった。元来頭が良くなくて抽象化能力とか理解力が低いという自覚はあったので理論が延々と続くようなちゃんとした教科書が得意ではないのである。

そんな時に手に取ったのが[コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方](https://amzn.to/3J5EuFa)だ。これはNANDという電子素子から始まり、CPU、OS、コンパイル、VMと実装していき最終的にはNAND Tetrisと呼ばれるゲームまで作ろうという本。作ると言っても物理的に回路を構築したりするわけではなくHDLや好きな言語(自分はPython)でコードを書いて組み上げていくという流れになる。とはいえ本格的に論理回路から順に組み上げて一応は一通りのコンピュータがどうやって動いているのかを手を動かしながら知れるのでコンピュータへの解像度が爆上がりして感動した。

OSとか言語を作る部分は流石に全然物足りないのだけど低レイヤーを理解するための足がかりにはなるはず。この本はすでに名著の部類に入ってるし今でも十分おすすめできる。[From Nand To Tetris](https://www.nand2tetris.org/)や巷にすでに実装を行なっている人たちのコードがGitHubやQiitaやZennにたくさんあるのでそれらを参照しながら挑戦すると良いと思う。

# [Writing An Interpreter In Go](https://amzn.to/3PCmynY)
上記の本を読み始めたのと同じ理由でこの本を読んだ。タイトルの通りGolangでインタプリタを書く本である。プログラミング言語を作ってみるというのは誰もがやってみたいことの一つではあると思うが、いきなりドラゴンブックを読めるわけはないのでどうしたもんかと思っているような人に丁度良い本。

これまた解説メインではなくLexer・Parser・Evaluatorを実際に手を動かしながら順を追って解説してくれるのが嬉しい。プログラミング言語を作るっていうのはこういうことなのかと膝を叩く経験ができる。

今だと日本語版で[Go言語でつくるインタプリタ](https://amzn.to/3PZvOmd)という本になっているので手に取りやすそう。同じ著者がこの本の[コンパイラ版](https://amzn.to/3POSB3K)も出しているのでそちらも読むとさらに理解が深まると思われる。

よく考えると最初から最後までしっかりと読み込んだ洋書はこれが初めてだったかもしれない。そういう意味でも自分の身になった良い本だったなと思う。

# 最後に
[エンジニアとして今の自分を形成した本を5冊紹介する](https://panda-program.com/posts/introduce-five-books)という記事を読み、自分にとっての5冊を選んで書いてみた。

今の自分を形成した本というのは必ずしも万人にとって有益な本ではないかもしれないが、その人の人生を垣間見ることができるという意味で酒のつまみにはなるようなネタだなと思った。他の人(もっと自分より年季の入った人)の経験も読みたい。

わからない概念だったものが腑に落ちて一段解像度が上がる体験をすると感動してしまうタイプの人間なので分からないことだらけのエンジニア初期の頃に読んだ本の方が贔屓目で見てしまう。新卒の彼らに技術書をお薦めする時は慎重を期して選出するのだけどある意味おじさんの自分語りのようなレベルならばこういう少し偏った選び方もありだと思う。

そういえばこれを書くために今までどんな本を読んできたかなと振り返ってみたが、圧倒的にインターネット上の記事やドキュメントなどのコンテンツを読んでいる方が多いと思った。

今は当時にも増してweb上のコンテンツがテキスト・動画問わず溢れているので「おすすめの本」というのを挙げることにそんなに意味はなくなっていくのかもしれない。とはいえ媒体が変わっても初心者が成長していく過程でブレークスルーのきっかけとなった思い出の"何か"はあるわけでそれを共有して感慨に浸っているのをみるのはまぁまぁ面白いと思う。

最後に自分がプログラミングで万能感を得た最古の原体験として、このゆーすけベーさんのブログ記事が出発点だったなと思い出したので貼っておく。一人部屋にこもってこの記事を読みながらクローラを書いていた、フォルダに溜まっていく大量の画像を見つめながら万能感に浸っていたのがめちゃくちゃ懐かしい...

- [Rubyやってみる！（新おっぱいスクリプトもあるぉ）](https://yusukebe.com/posts/2012/0520074309/)

エンジニアとして今の自分を形成した本

4月頃に痔が酷くなり座るのが嫌になってしまった。座りたくないのであれば立って仕事をするしかないが、スタンディングデスクをいきなり買っても使わなくなるんじゃないのか？という不安もありまずは手近でスタンディングデスクっぽいものをこしらえて試してみることにした。

# 最初の1~2週間
めちゃくちゃ足が痛くなる。そりゃ毎日8時間くらいほぼ立ち続けているから当然だ。足の裏、股関節、ふくらはぎなどへの疲れがすごい。風呂に浸かってマッサージをしてた。

作業はというと割と普通にできる。腰が痛くなったり首が痛くなったりということはない。長時間座っていると腰が痛くなることがあったがそれがなくなったのは少し良かったかなと感じた程度。

会議が無駄に長くなったりするとキレそうになる。さっさと要点まとめて終われボケ...と強く思うようになる。

# 1ヶ月ほど経過
立ち続けることがそれほど気にならなくなる。2時間くらいは平気で立ったままでいられる感じ。とはいえ一日の仕事が終わると座って仕事をしている時よりも全身の疲労感は多め。

スタンディング力が高まったおかげでダラダラ続く会議への苛立ちが少し減った。さっさと終われとは思うけど...。

夏が近づくとPCからの熱と部屋全体の熱気が顔の辺りを覆う。座っている時よりも汗をかきやすくなる。30℃を超えると流石に冷房がないとキツくなった。

# 2ヶ月経過
特に普段と変わりなくスタンディングワークをしていることに特別感すら感じなくなる。

そういえばこの頃から電車で立っていることが苦ではなくなっていた。コロナ関係なく外出時はあまり人と接触したくなくて立ってることもまぁまぁ多めだったので疲れにくくなったのはありがたい。

# 2ヶ月半頃
この頃からか、足の裏の特に踵や母指球辺りが硬くなってきて時折結構な痛みが出るようになった。当時はスリッパを履いてフローリングの上に立っていたわけだが、おそらく足の裏の出っぱっている部分に力がかかりやすくなっていてタコのようなものができる寸前になっていたのだと思う。

1時間立って作業をして5分座って休み、また1時間立つみたいなインターバルをちゃんと入れるようになった。今までは疲れたら座って休憩みたいな感じだったけど疲れてなくても休憩を入れるようにした。

まぁそれでも痛みはちょくちょくやってきたりするもので途方に暮れていた。

<img width="591" alt="スクリーンショット 2022-07-25 21 04 21" src="https://user-images.githubusercontent.com/1421093/180773703-76e6eda7-e959-4104-8194-76c00a9de302.png">

# 現在
ついに足の裏の痛み問題を解決する術を発見した。地面をふにゃふにゃにするのである。

今まではスリッパを履いていたとはいえ、足場は平面で硬かった。故に足の裏への負担が偏ってしまっていた。その足場に別の部屋で浸かっていたロングな座椅子を置きその上に立って作業をするようにしてみた。すると1日中立っていても全然痛くなくなったのだ....。

さらにしゃがめばすぐ足元は座椅子なのですぐにリラックスタイムに入れる。立って良し、座って良しのロング座椅子便利すぎる。

それに合わせて足元に小さめのちゃぶ台を置いたり座椅子にクッションを追加したりしてようやく文句ないスタンディングワーク環境ができた。

# 作業環境全体像
現在の作業環境の全体像はこんな感じ(後ろの椅子はほぼ使っていない)
![IMG_3244](https://user-images.githubusercontent.com/1421093/180774838-28eb541b-9d6b-4b9b-8998-92d54f935d7a.JPG)

スタンディングデスクを購入すると結構高い(まともなやつだと5万くらいする)し合わなかったらマジで邪魔な机なので、家に最初からあったちゃぶ台とかテーブルを重ねたり魔改造してそれっぽい机にしている。

普通こういう作業環境を公開するエンジニアのブログなどでは配線周りやキーボード、ディスプレイ、椅子などもこだわりぬいて綺麗な写真を載せているのだけども、自分はそういう細部へのデザインセンスがなく美的感覚が終わっているためこんな有様になっている。

ニトリとか激安通販とかで買った家に元々あったものばかりなので、新たに費やした費用は0円。もしスタンディングワークをやめるとしても臆することなく辞められるのが利点。

そもそも論として痔を治せばこんながんばらんでも良いのでは？みたいな話もあるが、まだ手術するほどではない(と病院で言われた)のと手術後は出産後よりキツかったと知り合いの妊婦さんが言っていたのを聞いて恐れ慄いており、対処療法でギリギリまで頑張って悪化させないぞ!!!と決意したという経緯があります。。。

(ジオン注射なら日帰りで痛みもそんなにないとか色々言われてはおりますが中々踏み出せないものです...)

スタンディングワークを3ヶ月ほど続けた感想

- Web3とは何であったか
  - トークンとコントラクトと誰からでも見える台帳を使ってなんか出来そうなことないっすかねくらいの思想または活動
    - 自動販売機で金入れたら人を解さずにジュースが買えるような感じで、トークンを支払ったら人を解さずにトークンが買えたり付与したりできる仕組みを作れるスマートコントラクトというのがあり、これなんかに応用できないっすかみたいなことだけだったはず
    - NFTとかDAOとかもその応用例の一つなだけにすぎない
  - トラストレスとか分散性みたいな話はEthereumのDocsには一部記述があるがあくまで理想論として語ってるだけ。会社がvisionをHPに書いてるようなもん。
  - Internetの技術が置き換わるとかBigTechを打倒するみたいな対立構造を煽るような話では全く無い
    - そもそも既存のインターネットの上に成り立っているし、分散されたそのノードはどこのサーバーで動いているんだという話がある。お前は自宅サーバの独自のノードを稼働させてるのか？(私はブレーカーが落ちてPCが終わったりした経験がある)
      - まぁPoSになると必要なマシンパワーがかなり少なくなり最低32ETHあれば参加しやすくなるはずなのでやってみてほしい
  - Web3という何かに技術的な新しさは無い
    - あるのはWeb3論者が語る理想の世界が"今とは違う"ということだけ(良し悪しや実現可能性は問わず)
  - ブロックチェーンにしてもソフトウェア的には既存の技術を組み合わせた仕組みだしそれ自体でブレークスルーとなるかは自分にはわからない。これだけ世界中の人々を巻き込んだムーブメントを起こす基盤になっているというのは面白いけど。
  - ZKPとかは真新しいかもしれないけどクリプト固有の範疇では
- Web3という言葉は死んだ
  - 現状はバカを丸め込むためのバズワードと化した
  - 機械学習やDL界隈が盛り上がってきた時にAIという言葉が流行ったのと同じ感じ
  - 概念をまとめて名前をつけるとマーケティングが捗る
    - バカでも難しい概念を使えるようになる
      - バカでも自分の会話に取り入れられるようになる
        - この時自らは何も概念を理解できてなくても問題ない。複雑な理解の部分は相手側に委ねられるので。
          - 「Web3でやっていきましょう!」「(Web3でやっていくとは...)」
  - とはいえある現象への名づけ行為自体は概念の普及やコミュニティの拡大には役に立つので一概に悪いことではない
    - ブラック企業/毒親/非モテ/LGBTなどは複雑な現象や概念に対して言葉が定義されてバズワード化して広く普及した。良し悪しは知らんけど。
- 危険な一発逆転思想
  - 政府のWeb3政策みたいなやつ。Web2.0までは世界に遅れを取ったという敗者根性に起因してると思う。
  - Web3という概念は「ゼロからのスタートだし世界に勝てるかも」という一発逆転願望を良い具合に刺激してくれる
    - 巷のエセサロンがうまくいかない人間に対してささやく甘い言葉と同じ
      - 「未経験でも高収入」みたいなやつ
  - これは完全に自分の考えで余談だけどそもそもIT戦略に関する政府の失敗はなんだったか考えてみると、天才育成の失敗だと思う。ITの世界(というか高度に発展してきた科学が主流の時代)は1万人の凡人より1人の天才(及びそれに次ぐ数人の優秀)な頭脳によって大きく発展する傾向がある。それにもかかわらず自由と多様性の確保や研究開発への資金援助を怠り、規制及び選択と集中に舵を切ったのが間違ってたのではと思う。
- 市場と信仰
  - DEXの台頭で一定の流動性が確保されてトラストレスにトークンを売買したりできる経済っぽいものが立ち上がったのは確か
  - しかし大体において暗号通貨市場は信仰によって成り立っている印象
    - S&P500のインデックス投資ですらある意味米国経済への信仰の元に成り立っているわけではあるが、 暗号通貨市場のそれは全くその比ではない(歴史も根拠もなすぎるし既存の金融市場のおこぼれを貰ってるだけでは...)
  - 投資(投機)は自己責任の範囲でやるべきというのは当然だけど、他人へ暗号通貨の保有を勧めたりする行為はカルト宗教の勧誘と同じ(根拠なく理想を語り、甘い言葉で自己の利益を目論む行為という点で)
- 自分のポジション
  - 一言で言うとdapps作るのが楽しい、以上。くらいな感じ。現状ほぼ金になってないから盆栽いじりと同等。
    - 情報を追い始めたのは去年の夏くらいからなので割と最近。仕事上必要で情報をキャッチアップし始めた感じ。最初はEthereumから見ていった。
    - コントラクトを書いてブロックチェーンにデプロイ(有料)しておくと、適当なAPIが生えて、なんか激烈にreadのAPIリクエストしてもちょっとやそっとでは落ちない(writeに関しては同時処理できるtransactionが少ないのでそもそも激烈にリクエストできないが)使い方によっては便利じゃんとか、ウォレットをネットワーク全体通じたID代わりにできればユーザー認証周りはサービスごとに特別に作らずとも良くなり、フロントエンドだけ書けばよくてラクできそうみたいな感じで色々遊んでた感じ
      - まぁ現実はそううまくいきませんが(オフチェーンとオンチェーン間のシャトルランで死にそうになりながら...)
  - それぞれ好き勝手に好きなネットワークにコミットして俺だけの最強のWeb3をやれば良いとは思ってるけど、既存の技術や先人の肩に乗って生きているくせに彼らに敬意無く、己の利益のためだけに都合のいい嘘をついたり、対立構造を煽ったりして、大衆を分断させる卑劣な行為や言説は糾弾したい
  - 粛々と研究開発している人はたくさんいるのでそういう人達だけ相手にしていきたい


最近のWeb3への雑感

最近は複数のフォーム入力項目があるページをお仕事で作ったりしてる。その中でUIを作ってる時に動作確認をするんだけど数十項目の入力フォームをいちいちゼロから埋めてsubmitして...みたいなことをするのが結構だるい。この作業を良い感じに手助けしてくれるChrome Extensionを作った(というか作っているところ)。

- [YuheiNakasaka/FormFill](https://github.com/YuheiNakasaka/form-fill)

↓下記がデモとしてGoogle Formを埋めている例。Google Formは結構特殊でinput要素を全然使わずdivをボタンやチェックボックスにしているので一発入力できずに厳しいのだが90%くらいの要素は一気に埋められる。

https://user-images.githubusercontent.com/1421093/179355981-2729be7c-7552-4217-a9a2-1dc809997dc2.mp4

今回欲しかった機能としては、

- 任意のフォームのセレクタとvalueを指定して一発でフォームを埋めてくれる
- 入力パターンのセット(住所が東京の場合とか電話番号が070から始まる場合のパターンなど)をいくつも作成できる
- 入力パターンセットを好きに組み合わせて選択してフォームを埋めてくれる

逆に不要なものは、

- リッチなGUI

という感じ。

なので今回は入力パターンセットをまとめたJSONを指定して、それに則ってフォームを埋めてくれるようにした。開発者とか向けのデバッグでしか使わんだろうと思うしGUIは設けていない。

JSON一つあれば良いことのメリットとしては、チーム内で入力項目をまとめたJSONを作りgit管理とかしておけること。テキストファイル一つにまとめられるので共有が楽なのは良い。まぁJSONを作るのがだるいのだけども...

Chrome Extensionを作り始める際のボイラープレートとしては[chibat/chrome-extension-typescript-starter](https://github.com/chibat/chrome-extension-typescript-starter)を使った。

過去にいくつか作ったことはあったので基本的な開発の流れは覚えていたが細かい部分を忘れていたので[API Docs](https://developer.chrome.com/docs/extensions/reference/)と睨めっこしたりした。

ChromeでしかもPCでしか動かさなくて良いから考えるべき動作環境が限定的でその辺りは楽。

あとストアへのリリースはまだしてない。一旦は雑な作りだし、リポジトリとして公開しておけばそれをビルドして自前の環境で使うこともできるので後回しにしている。開発者向けなのでなおさら。

ちなみにこのExtensionはよくある住所などの自動入力のためのExtension([AutoFill](https://chrome.google.com/webstore/detail/autofill/nlmmgnhgdeffjkdckmikfpnddkbbfkkk?gl=JP&hl=ja)みたいなやつ)ではない。

あくまで複数の入力パターンを何度も実行するようなケースでしか嬉しくない。その辺りは理解しておいてほしい。

開発時のフォーム入力を少し楽にするためのChrome Extensionを作った

[目の見えない人は世界をどう見ているのか](https://amzn.to/3P9Tl3g)という本を読んだ。その中に目の見える人と目の見えない人が美術館で一緒に作品を鑑賞するソーシャルビューという試みが書いてあった。

ソーシャルビューではまず見える人が作品について語る。その際に重視するのは作品の形や客観的な情報ではなく本人の主観的な感想だ。それを聞いた目の見えない人たちはどう言った作品なのか想像しながら質問したり感想を述べたりする。このインタラクティブなやり取りの中で互いに作品の意図や意味を感じ楽しむ。このような美術鑑賞の試みがソーシャルビューである。

> 情報化の時代にわざわざ集まってみんなで鑑賞する面白さは、見えないもの、つまり「意味」の部分を共有すること

作品そのものを見るだけで得られるものはただのデータである。そのデータを受けた鑑賞者がそこにどのような意味を見出すのか。その共有を通じて目の見えない人は作品を脳内で立体的に補完し、さらにその補完した作品を受けてそこに自らの意味を見出していく。こういう営みだ。

> 作品を鑑賞するとは自分で作品を作り直すこと

「鑑賞する = 自分で作り直す」という文章に感銘を受けた。

というのも自分は鑑賞が苦手だからだ。映画やアニメや漫画などあらゆる物語に対してそのストーリーを追うことしかできない。キャラクターに感情移入することもないしストーリーの不自然さに苛立つこともない。だから深読みとか考察みたいなものもできない。登場人物のパラメータの暗記と筋書きを追うことで満足してしまう。

いわば"物語"という食べ物を食べても消化されずに排泄されてしまう感覚に近い。胃で消化されず腸で吸収されず体の一部になるような、そういう摂取の仕方が"鑑賞"なのだと思うのだけど、自分の場合は舌で感じた味くらいしか摂取できないわけだ。

大味なバトル漫画を読んだりするときは心臓がバクバクすることもある。スナック菓子を食べているような感覚。刺激の強い味はどんどん食べたくなるしよく噛まずに早食いになる。物語を異常な速度で雑に食ってると変なアドレナリンが出ちゃうのだと思う。

これは老化とか体調が悪いからとかそういうのは関係なくて昔からこんな感じである。むしろそういう自分に自覚的になってきた分まだマシだ。

鑑賞することは自分で作り直すということであるならば、自分は全く鑑賞が出来ていない。勿体無いなと思う。クリティカルシンキングだとか共感性の問題だとか、色々と理由はあるのかもしれないが浅い人間だな〜と感じてしまう。

そういえばオードリーのオールナイトニッポンで春日が何十年もジャンプを読み続けているがどの作品も誰々が強いとか弱いみたいな話だけで自分と作品との関係から出てくる感想とか考察みたいなものが一切なくて若林にdisられてたのを聞いてめちゃくちゃ共感と安心感を覚えた。俺だ〜〜〜となった。

鑑賞が出来ない

6/29、モーニング娘。とJuice=Juiceの新メンバーが[ハロプロ公式Youtubeチャンネル](https://www.youtube.com/watch?v=OIjk6pzQl30)にて発表された。

娘。には一般オーデから1人、Juiceには一般オーデから1人+研修生から1人という結果である。
[http://www.helloproject.com/news/14778/](http://www.helloproject.com/news/14778/)

雑感としては、

- 研修生から石山咲良が昇格してくれて最高
- 研修生からの昇格人数少なすぎ！？

という感じ。

石山咲良に関しては年齢的にも辞めるか否かの瀬戸際だったと思うのでここで選ばれなければもうあとはないかもしれないと誰もが思っていたと思う。なので彼女の昇格に関しては誰もがおめでとうという気持ちなはず。しかも本人がずっと好きだったグループへ加入できることになったわけなのでオタクだけでなく本人の希望も叶った形で全方位丸く収まっている感じがした。

問題はもう一つの方で、研修生からの昇格人数少なくない？というやつ。
特に今年は研修生の実力診断テストで念願のBPを獲った古株の松原&小野田ペアの昇格を心待ちにしていたオタクも少なくなかったはず。というか自分もこの2人+一般1人の計3人が娘。入りかな〜などと考えてたところもあるので今回の新メンバー発表には驚かされた。松原オタとまーオタを兼ねていた人はまーちゃんのエメグリを受け継いでくれることを確信していたんじゃないかなと思うし、ショックだっただろうと思う。

さらに追い討ちをかけたのはその後に発表されハロプロ研修生ユニットである。研修生の歴の順に上から5名が選ばれてハロプロ研修生ユニットとして活動すると発表されたのだが、これがあからさまな塩漬け感を感じさせる人選であるし活動も何をどのくらいやるのか未定なため当該メンバーのオタクは激しく落胆した。発表直後は界隈のTwitter/Space/Youtubeが研修生オタクの悲しみと怒りの声で溢れていた。

色々な話はあると思うがどうしてこういう人選になったのか少し考えてみたが、個人的にはやはり事務所の経営的にメンバーを増やす余力があまり無いのではないか？という説が濃厚なのではと思った。

OCHA NORMAのデビューもあるしハロプロだけですでに70人近いメンバーを抱えているから人件費だけでも数千万/月と固定費が膨らんでいるはず。しかしここ数年はコロナで興行は思うようにできないので経営的にまだ厳しい。が、研修生はたくさんいるし、せっかくここまで育ててきたのに辞めさせたくはない。となると取れる選択肢としては経営を圧迫しないギリギリの枠を用意して、そこに1番やめる確率の高いメンバーだけを昇格させようとなるはず。

それが石山咲良だけだったのではないか。今年BPを獲った2人は歴は長いがなんだかんだでまだ若い。石山と比べた時にギリまだ研修活動の継続ができる余力がある。

そう考えると割と今回の人選は理解できる。何より昨今の事務所は頑張ってきた研修生を辞めさせたくないのだ、ここが大事だ。だから石山昇格を急いだし、残りの研修生のための引き留め措置としてのグループを作ったのだと思う。

という感じで厳しい経営状況と研修生への親心みたいなものが生んだのが今回の人選と新体制の発表だったのではないか。

まぁ塩漬けされた側のオタク各位は放心状態だと思うし同情するが、研修生グループもまた新グルとしてデビューさせるようなOCHA NORMAパターンと決まったわけではないし、今年末~来年にかけてまた卒業するメンバーも出てきそうな雰囲気もなんとなく感じるのでそこで空いた穴を埋めるためにあっさりデビューみたいなこともあるかもしれない。

その辺りは全くわからんのだけど、今回の件で事務所も昔のように鬼ではないのかもなと思ったので、何かしらの形で彼女たちが報われるようにしてくれるんじゃないかなと淡い期待をしておく。

ハロプロ新メンバー発表に対する雑感

[Misreading Chat](https://misreading.chat/2022/05/12/92-software-development-waste/)で紹介されていた[Software Development Waste](https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/papers/icse17sedano.pdf)という論文。

この論文に載っていたTypes of Software Development Wasteというソフトウェア開発のムダについて類型されていたものが面白かったので日本語にしてみた。

# 誤った機能・製品の構築
## ムダ
ユーザーニーズやビジネスニーズに対応していない機能・製品を構築するコスト
## 原因
- ユーザーの要望
  - ユーザー調査、検証、テストを行っていない、ユーザーフィードバックを無視している、ユーザー価値の低い機能に取り組んでいる
- ビジネスの要望
  - ビジネス関係者を関与させていない、関係者からのフィードバックが遅い、製品の優先度が不明確
## 一言メモ
ユーザーの声を汲み損ねていたり、えいやで作ってしまった機能とかまぁムダですよねと言われてばそう。割とよく起こりがちである。

# バックログの管理ミス
## ムダ
作業の重複、価値の低いユーザー機能の迅速化、必要なバグ修正の遅延のコスト
## 原因
- バックログの逆転
- 同時に多くの機能に取り組む
- 作業の重複
- 十分に準備されていないストーリー(以降"ストーリー"は"機能"と同じ意味で使われてるっぽい？)
- 機能開発とバグ修正のアンバランス
- テストまたは重要なバグ修正の遅延
- 気まぐれなスラッシング(訳が微妙)
## 一言メモ
取り組むべきタスクの優先度づけがうまくできてないと、あるべき順番であるべき機能がユーザに届けられなくなるのでそういうのはムダですよねという感じか。

# リワーク(手戻り)
## ムダ
正しく行われたはずの納品物を変更するコスト
## 原因
- 技術的負債
- ストーリーの却下（例：プロダクトマネージャーがストーリーの実装を却下）
- 完了の明確な定義がない（ストーリーが曖昧、設計モックの推測）
- 欠陥（テスト戦略の不備、バグの根本原因分析がない）。
## 一言メモ
仕様の作り込みが甘かったり、そもそもユーザーテストが不十分であやふやな機能が設計されたりして作り直しが発生するのはムダですよねという感じ。技術的負債やバグ起因で作り直しが発生するのもここの無駄にカウントされてる。

# 不必要に複雑なソリューション
## ムダ
必要以上に複雑なソリューションを作成するコスト、機能、ユーザーインターフェース、コードを単純化する機会を逃す
## 原因
- ユーザーの視点から見た不必要な機能の複雑さ
- 不必要な技術的複雑さ
  - コードの重複、インタラクションデザインの再利用不足、前倒しで作った複雑すぎる技術的デザイン
## 一言メモ
オーバーエンジニアリングの結果、なんかかっこいいけど誰も容易に変更できなくなってしまったみたいな実装はたまにある気がする。しかもそれをやった人が退職してしまい結局全部書き直す羽目にみたいな、、やり直しが発生するという意味で確かにそういう実装は結局ムダと言われればムダ。

# 不要な認知負荷
## ムダ
精神的エネルギーを不必要に消費するコスト
## 原因
- 技術的負債に苦しんでいる
- 複雑または大規模なストーリー
- 非効率なツールや問題のあるAPI、ライブラリ、フレームワーク
- 不必要なコンテキストスイッチ
- 非効率な開発フロー
- 整理されていないコード
## 一言メモ
開発フローやツールや負債に起因してMPを過剰に消費させるのはムダですよねというやつ。

そういえば精神的に負荷がかかることそれ自体がどのくらい開発の生産性低下を引き起こすのか知りたいんだけどそういう研究あるかな。例えば技術的負債によって発生する精神的な負荷は自体は実は生産性を低下させてなくて、技術的な負債そのものが生産性を低下させているだけみたいな。

まぁMPが過剰に減らされるのは人間をリソースと考えるとムダだよねというのは当たり前だけど。

# 心理的苦痛
## ムダ
不要なストレスでチームに負担をかけるコスト
## 原因
- チームのモラルの低下
- ラッシュモード(締切がきつすぎるみたいな状況)
- 対人関係やチーム内の対立
## 一言メモ
これも上のやつと似ててMPの過剰消費に繋がるのでムダというやつ。

そういえばフルリモートでissueベースで働いてると対人関係みたいなものを気にすることがほぼ無くなった。issueだけの関係だと後腐れなくて事務的に処理できることが多くて楽。一方でプロダクトを作っていくチームの一員としてビルドアップから参加する必要があると柔らかなコミュニケーションが必要になるので気を遣う。

# 待ち時間/マルチタスク
## ムダ
マルチタスクに隠れがちなアイドルタイムのコスト
## 原因
- 遅いテストや信頼できないテスト
- 信頼できない受け入れ環境
- 不足する情報、人、設備
- フィードバック遅延によるコンテキストスイッチ
## 一言メモ
テストが遅すぎたりPRのレビューがスルーされたりして先に進めない時に発生する待ち時間はムダですよね、というやつ。確かによく起きがちではあるが、PRのレビューで発生する待ちはどうしようもないところがあるな...。

# ナレッジロス
## ムダ
チームがかつて知っていた情報を再取得するコスト
## 原因
- チームの解散や移動
- 知識のサイロ化
## 一言メモ
チームの移動や変更でナレッジの共有をやり直すのに発生する時間とかがムダですよねというやつ。これは暗黙知を減らすために各人が情報をオープンに見える化しておかないと発生しがち。

ベテランの特定の人に質問が集中しちゃったりするとその人の本質的な作業時間が減るのもよくある。そういうベテランはそのプロダクトのあらゆることを知っているから開発のパフォーマンスも他の人より出せるはずなんだけど、オンボーディングを手伝うコストが度々発生しちゃたりすると勿体無いな〜となる。

# 非効率的なコミュニケーション
## ムダ
不完全、不正確、誤解を招く、非効率的、または不在のコミュニケーションのコスト
## 原因
- チームサイズが大きすぎる
- 非同期コミュニケーション
  - 分散チーム、分散ステークホルダー、他のチームへの依存、チーム外の不透明なプロセス
- 不均衡
  - 会話を支配する、聞かない
- 非効率な会議
  - 集中力の欠如、振り返りのスキップ、毎日ブロッカーについて話さない(どういうこと...)、会議が長引く（例：長い立ち話）など
## 一言メモ
コミュニケーションがうまくいかないとムダですよねみたいな感じ。幅広いけどもまぁそれはそう。会議に関しても不要な話で盛り上がっちゃうとか曖昧な目的始まっちゃって終わりどころが見えずダラダラ続くみたいなことはよくある気がする。

# 雑感
ソフトウェア開発におけるあるあるネタまとめみたいな様相である。こういうムダは確かに至る所に散見されるが、これらをどうやって取り除くかというのは中々難しい問題だ。だがその辺の対処法についてはこの論文に書いていない。

この辺りのムダを取り除くためのプロセス改善の話はどういう本(や記事や論文)を読むと良いのだろうか。

ソフトウェア開発におけるムダ

![IMG_2791](https://user-images.githubusercontent.com/1421093/174434078-aca7b457-1701-4cde-a1a1-2ad6ae79acf1.JPG)


下北沢にある[202カリー堂](https://www.instagram.com/202currydou/)というカレー屋の抹茶バスクチーズケーキが旨い。

個人的には過去に食べてきたバスクチーズケーキの中で1番好き。チーズの味が濃厚、程よいとろみ、深みのある抹茶のほろ苦さ、香ばしい焼き加減、抹茶クリームの甘味が全てマッチしてて最高。少し時間が経つと(溶けて?)柔らかくなってしまいやや口当たりが微妙になるので提供されたらすぐ食べた方が良い。

店名にある通りスパイスカレー屋がメインではある(しそれ自体も普通に美味しい)んだけど、ここは抹茶のバスクチーズケーキ屋を名乗った方が良いレベル。

その他にも抹茶のプリンもマッドな口当たりでたまらん旨さだしテリーヌも良かった。スイーツ全般ハズレがない。

下北沢駅からのアクセスも良いしもちろん人気店なので休日の昼間やティータイムは最低でも1時間は並ぶがその価値はある。夜は列が落ち着いて少し早めに入れるので夜に行くのはアリかもしれない。

客層は20~30代くらいの女性が9割くらいなのでその辺はおっさんが単騎で乗り込むには少し躊躇するかもしれないけど気合いで並びましょう。

ちなみにスイーツ単体注文時はドリンクを注文しないといけないのでその点は注意が必要。

202カリー堂のバスクチーズケーキ

楽天モバイルからの移行を検討している。前々からニュースになっているが今まで1GB以下のデータ利用で無料だったのが7月からなくなってしまうからだ(追記: 2022年10月末までの最大4カ月間は月額データ利用量が1GB以下の場合、月額料金が実質無料だった →[詳細](https://network.mobile.rakuten.co.jp/fee/un-limit/info_20220513/))。
- [楽天モバイル「0円」終了。7月からは最低1078円](https://www.watch.impress.co.jp/docs/news/1408944.html)

# 要件
要件的には下記のような感じ。

- 1台目のスマホとして使える
- 電話番号は要る(電話はしない)
- SMS受け取れないと困る(が、送ることはない)
- ネットは外出時に検索等の静的サイトやアプリで使えればOK。1GB/月あれば十分。
- 家ではWi-Fiと接続する

# 合理的シンプル290プラン
これら要件を勘案した上で移行先の選択肢を検討した。

といっても候補がたくさんあってマジで訳分からんという感じだったが、いくつか調べた感じだと自分には日本通信の[合理的シンプル290プラン](https://www.nihontsushin.com/plan/plansimple.html)が合っていそうだと思った。

上記要件を全て満たした上で、ドコモ回線で1GB 290円/月というプランだ。

楽天モバイルでのデータ通信はもともと1GB/月以内に収まる使い方しかしていなかった。なのでこのプランで十分である。

さらに1GBを超えると+1GBごとに220円なので2GB使っても510円/月だけ。外出先でYoutubeを見たりゲームをするような人には全く向かないけどプライベートも引きこもりのリモートワーカーにはピッタリだと思う。

ちなみにSIM or eSIMを選べるが初期手数料はどちらも3300円かかる(どこも同じ。7月以降の楽天モバイルx3ヶ月分)。

# その他の候補
## [povo](https://povo.jp/)
基本料無料。年に2回トッピング購入が必要だがそれを加味しても440円/年で済む。多分1番安い。

選ばなかった理由は安すぎる回線は楽天モバイルみたいにどこかで終了しそうだな〜という気がするのと、トッピング購入がちょっと手間。

auの回線だし速度は十分だと思うし(ただし0円0GBの時は128kbpsになる)、何より1日だけ使い放題にしたりとかなり細かく料金をカスタマイズできるのは面白いなとは思った。

## [IIJmio](https://www.iijmio.jp/hdc/spec/)
2GB 850円/月。悪くはないけど日本通信の方が安かった。

## [NUROモバイル](https://mobile.nuro.jp/plan/)
3GB 792円/月。結構安い方だけど、これも日本通信の方が自分にあってたので却下。

## [OCNモバイルONE](https://www.ntt.com/personal/services/mobile/one/charge.html)
昔使ってたやつ。0.5GB 550円/月。月額だけ見たら安いけどさすがに1GBは欲しかったし、日本通信の方が安い。

## [HIS Mobile](https://his-mobile.com/domestic/planlp_2022splan)
1GB 550円/月。100MB未満だと290円/月になる。安いけど100MB未満のことは流石にないので却下。あとは申し訳ないがHISという名前にやや不安があった。

## その他
他にも[ahamo](https://ahamo.com/plan/)・[LINEMO](https://www.linemo.jp/)・[mineo](https://mineo.jp/price/)・[UQ Mobile](https://shop.uqmobile.jp/shop/)など色々と移行先の候補はあるが、どれも自分のユースケースには微妙で割に合わなかったので書いてない。

あくまでも今回は自分の要件に合っているのはどこか？という話であり、特定のサービスを勧めたり贔屓したりしているわけではないことはご了承願いたい。データ通信のみとか逆に20GB以上プランとかだと話が変わってくると思うし。



楽天モバイルからの移行先

「作るのにどれくらいかかりますか？」と訊かれるとイラッとしてしまうことがある。そうなってしまう理由についてある程度自分の中で言語化しておきたい。

そういう訊かれ方をする状況は大抵小規模なMTGで何かのプロジェクトの企画段階で起きる。OOなユーザー向けにXXという機能を追加しようかと思っているんですが、これ作るのにどれくらいかかりますか？といった具合だ。

こういった質問が飛んでくる場合は決まって企画側で未確定の要素が多い。こちらとしては未確定の要素があると曖昧の見積りしかできないし、当然不測の事態を想定して多めにバッファを含めた回答になる。そうすると(おそらく)想定よりも長めの期間の見積りを返された企画者は開発にそんなに掛かるのか...と不満げな様子になってしまう。こちらは困らせたくて長めに見積もりを出しているわけではないのに開発にそんなに掛かるのか...という雰囲気を出されると開発者としての力量を疑われているように感じてしまってイラッとしてしまう。

その他のパターンとしては企画の中に未知の開発が含まれている場合だ。例えばOOOというサードパーティのSDKを使ったBotシステムを作りたいんだけどもこれ作るのにどれくらいかかりますか？といった具合である。

OOOというサードパーティのSDKに関して過去に利用した経験がなく触ってみないとわからないパターン。その際はこのSDKはまだ使ったことがないのではっきりとどのくらいとは言いづらいので少し調査してからの回答でもいいですか？と聞くものの、企画者は何やら急ぎで回答がほしいようだ。そこでざっくりとでいいのでどのくらいか分かりませんかね？と言ってくる。仕方ないので未確定の要素を多めに勘案して多めの見積もりをいう。というこの一連のやり取りでイラッとしてしまう。

企画者の中にはエンジニアは技術に関して全てを把握しているかのように考えている人がいる。そんな人間がいるなら教えてほしい。自分の専門に関することならつゆ知れず、大抵ははっきりと決断しきれない技術的概念の方が多いので常に調査しながら開発している人の方が多いはずだ。

こうやって少し言語化してみると、「こんな簡単そうな開発にもこんな時間がかかるのかよ」とか「OOに関する知識ないんだ」とか **お前スキル不足なのでは？と暗に突きつけられてしまうような物言い** にイラッとしてしまうのだなとわかった。

もちろん相手にそんな気はないと思うしそれぞれの都合があると思うから仕方ないとは理解してるのでこういう企画者滅ぶべしとかは全然思ってないです。あくまでも自分の気持ちを噛み砕いて整理したいという意図で書いている。


「作るのにどれくらいかかりますか？」と訊かれるとイラッとしてしまう

最近というかここ1年くらいなんだけどアニメを全くといっていいほど観なくなった。昔は毎クールどんなアニメが放送されるのかチェックしていくつか嗜むみたいなことしていたのにこれはどういうことか。

一つは興味が薄れたこと。アニメに何を求めて観るかは人それぞれ自由だが自分の場合は声優だった。ストーリーはもちろん好き嫌いあるけど作画とか音楽についてはそんなに興味がなかった。子供の頃から"声"が好きで高校では放送部でアナウンスとかをやっていたくらいだ。一時期は声優のラジオを毎週20番組くらい録音していたりなどライフワークになっていた([radiorec](https://github.com/YuheiNakasaka/radiorec)という専用のサーバーも書いたりしてた)。ところがその興味が徐々にアイドル(ハロプロ)へと軸足が移っていき、今ではもうラジオの録音すらやめてしまった(声優情報はちょっとだけ追ってるけど)。

アニメもアイドルもどちらも追えばいいのにという意見は尤もだけど、これが年齢によるものなのか興味を絞ってその空いた分の時間でよりそれを深めたいという欲求が20代の頃よりも強まったように感じる。幅広く好奇心のままに手をつける体力が無くなったのかもしれない。

もう一つはアニメの制作現場を近くで見過ぎていること。現在はアニメーターと同居しているので近くでアニメ制作の声を聞くことができるのだがそれがとても2022年とは思えないような環境で辛くなってしまっている。元々何年も前からアニメーターの待遇が良くないと言われてはいたがこんなに大変なのかと驚いた。アニメSHIROBAKOでも炎上プロジェクトに万策尽きたと監督が騒いでいるシーンが印象的だったが、あれはリアルよりはだいぶマシである。

具体的なエピソードを挙げるのは控えるけど雇用契約は杜撰だし休みは全然無いし長時間労働(多分月300時間くらいは普通にやってる)しそれで給料が大学新卒の初任給に届かないしかつ正社員ではないみたいな感じの人(もしくはそれ以下)の人がザラにいる。食っていけないからUberなど隙間バイトをやってるみたいな人もいるっぽい。制作や演出の人たちでも似たようなもんのところが多めということでまじか...となっている。

それでも待遇改善をしようと活動している人達や団体ももちろんいるが、業界全体のほとんどが下請け構造で予算も大してないから下に落ちていく金はそもそもない。映画もそうだがこういう制作はどのくらい成功するのか読めなくて博打的な要素があるから安定させるのは至難の技だ。構造的に誰が頑張っても如何ともし難い雰囲気がある。それでもアニメが毎クール制作されているのはアニメを作るのが好きという気持ち一つで身を粉にしている人達がいるからだ。

自分は世の中のアニメの多くは彼らの削った命で生み出されているというのを間近で観てしまったのでアニメを観るのが憂鬱になってしまった。家畜の生産現場を知ることでヴィーガンになる人が多いようにアニメ制作の現場という現代のプランテーション農場をリアルに見聞きしてしまったが故にその反発でアニメを観るのがキツくなったのだろうなと思う。観た方がお金は落ちるし彼ら業界のためには良いんだろうけども...

アニメを観なくなった

会社にエンジニアが一人になってからもう10ヶ月ほどが経った。もちろん一人であらゆる開発を行わないといけないので負荷は大きい。しかし手に負えないほどの仕事があるわけではないのでなんとかなっている。実務面ではそうなのだが、それ以外の面での影響が個人的には少なからずあったなと感じている。

チームメンバーがいた頃は毎日15分~30分程度の朝会があった。ここでは前日・当日の仕事に関する話はもちろん気になったニュースや好きなアニメの話など自由に話していた。この時間を設けたのは業務上のコミュニケーションロスを減らしたいというよりはむしろPCの前で毎日作業を続けるエンジニアは人と会話をする機会が減りがちなのでとりあえず雑談しようという、ライフバランスを整えたい的な意味合いが大きかった。

別に人と会話をしなくても問題ないのではというご意見も尤もだけど、アルツハイマーで認知能力を低下させないためには規則正しい生活はもちろん他者とのコミュニケーションをおこない、ある程度脳に負荷をかけた方が衰えにくいと言われている。エンジニアは知的生産を行う脳みそが資本の職業だから認知能力を維持する時間にある程度投資してもペイするはずだ。そういう理由から朝(といっても10時とか11時とかだけど)に朝会というものを開催していた。

これが10ヶ月ほど前から無くなってしまったわけである。

加えてコロナの影響で外出も減ってしまっているし家にいながら飯が食えたり何もかも家でできてしまうから他者との接点がほぼ無くなっていることに気づいた。

自分は趣味といえば開発かハロプロくらいなので、そういう話ができる仲間を会社の外にも持っておけばよかったなと少し後悔している。ゲームが趣味の人とかは配信で盛り上がれたり内輪で連携を取るメリットもあったりするからそういう仲間がいてDiscordとかでワイワイしてたりするの見て良さ...などと思ったりする。

コロナ以前であれば勉強会やカンファレンスの現地会場で知り合いができたりする機会もあったがリモート開催が普通になっている昨今ではなかなかそういう機会も少ない。アイドルの現場も同じく。

複数人エンジニアのいる会社に所属しているとそういう機会を手軽に得られるのでお得だったな〜などと思うのであった。

とはいえプログラミングはポジティブな意味で孤独な営みであり、自分はそれが好きである。だから不特定多数の人達でワイワイと馴れ合いたいわけでは全くないけど好きなことについて様々な意見を言い合ってコミュニケーションできる相手や場(大学の研究室みたいなやつとか)は大切にしないといけなかったなと感じている。

一人が好きとかコミュニケーションが嫌いとかそういう人が多いこの職業ではある(し自分もそのタイプだ)けど、それは会話したくない人と会話したくないだけであって、楽しく会話できる有意義な時間を過ごせる相手ともコミュニケーションしたくないやつなんていないよな〜という話。

共通の話題で盛り上がれる人間 探し方 2022 が求められている。


会話

![IMG_2991](https://user-images.githubusercontent.com/1421093/171147566-a974868a-5acc-4f79-84c3-ecfab6bda74f.JPG)

ここ2週間くらい毎晩カレーを食べ続けている。きっかけは同居人がレンジで米が炊ける鍋というものを持っており、その鍋を使うとカレーも作れると教えてくれたことだ。

自分はフルリモートで仕事をしているから出来てると思うが、毎日の食事がほぼ一定である。朝は納豆・昼はnosh+0.7合の米・夜は野菜丼(冷凍野菜2,3種+卵+0.7合の米で作る親子丼みたいな味のやつ)という生活をもうかれこれ1年以上続けている(朝は納豆じゃなくBASEを食ってた時もあったがやめた)。もちろん外食に行くこともあるが土日の付き合いなどの特別な日だけだ。

こういうある意味異常な食生活が許容できている人間なので2週間毎日カレーを食うことなど大したことないのだがそれでもいくつか気づいたことがあるので書き記しておこうと思う。

# 基本レシピ
![IMG_2993_2](https://user-images.githubusercontent.com/1421093/171151680-2d6be9c8-cd2e-4740-9209-9d42aaaa9c24.JPG)

まずカレーの基本レシピだが下記。手抜きはしたいが栄養は最低限摂りたいという点から冷凍野菜をふんだんに取り入れた構成になっている。

### 材料
- カレールー: 1片
- 野菜2種: 適当
- オクラ: 適当
- 水: 90~100cc

鍋にオクラ以外を全て入れてレンジで3分~4分チンする。終わったら取り出してオクラを入れてよく混ぜれば出来上がり。そこに適当にご飯を入れてその鍋のまま食べる(洗い物を増やしたくない)。

という感じ。大体所要時間は5分。

1番重要なのは水の量。少なすぎるか？と思うくらいがちょうど良い。

鍋はAmazonにあるやつだとこの[メトレフランセ](https://amzn.to/3N57Y7g)のやつが近いかも。

野菜に関しては今まで夜は野菜丼というやつを食っており、そのため自宅の冷凍庫に冷凍野菜が常備されている。冷凍庫にはほうれん草・ブロッコリー・インゲン・ナスなどが1袋はある状態。なのでこの中から適当に2種類取って使う。

オクラだけ必須にしてるのはオクラを入れて混ぜることで粘性が増しよりドロドロになるので好みのカレーっぽくなるから。単純にオクラが好きというのももちろんある。

# カレールー
カレールーに関してはこれはまだ実験中ではあるのだが、[業務用のジャワカレー](https://amzn.to/3M2NsTJ)が抜群に美味かった。これは近所のスーパーのPBのカレールーと比較してるのもあるけど、玉ねぎや肉が入ってない分オリジナルのルーの美味さがカレー全体の味に直結しているので違いが顕著だ。

レトルトカレーも試してみたところそれなりに美味しいしささやかながらにんじんやじゃがいもや肉も入っているのでよりいつものカレーっぽくなる。弱点としては冷凍野菜を入れるとその野菜から出た水分のせいでやや水っぽくなるというのがある。あとは固形のカレールーから作る場合に比べて1食当たりの値段がPBのカレーでも60~70円くらい増える。まぁどちらも人によっては大したことないと思うのでこれはこれであり。

ただPBの固形カレーについては絶対やめた方が良い。あれは本当に味が微妙。スパイスも足りないし圧倒的にコクが足りない。にんじんや肉を入れてやっと食える味になるようなルーである。先のレシピで使うとしてもニンニクやみりん、あとは黒糖なんかを入れて調整すれば食える味にはなるがそういう調整は面倒だ。

ということで個人的には[業務用のジャワカレー](https://amzn.to/3M2NsTJ)を推したい。

# 飲み物
ほうれん草とナスが好きでよく使うが、これらは調べてみるとシュウ酸を多めに含むため丸腰で食べ続けると結石ができやすくなってしまうらしい。というのを見たのでカレーを食べるときに牛乳を一緒に飲んでいる。シュウ酸はカルシウムを同時に摂取すると腸で吸収される前にカルシウムと結合して体内に吸収されなくなるらしい。

子供の頃、尿管結石により救急車で運ばれていく父の姿が鮮明に脳裏に焼き付いており、ああはなりたくないという強い気持ちがある。

# 体重
カレーは比較的油が多く使われているので脂質を摂りすぎることになるのではないかという心配もあるが、具材を炒めたりしてない(油を敷いてない)し肉も入ってないので大した油分にはならなそうという判断をしてる。まぁこれは人によっては良くないと思うのでうまくやってほしい。自分はBMIが17台のかなりの痩せ型で太ることに関してはあんまり問題視してない。むしろ太ってくれ...という感じ。

# 栄養バランス
自分の場合は昼のnoshが日毎に別のメニューなので一応タンパク質やその他の野菜はそこでほどほどには摂っているつもり。[あすけん](https://www.asken.jp/)で1日の栄養バランスを計算すると50点~60点くらいで全体的に少なくはなるんだけど、あのアプリで満点取れるような食事にするには補助栄養食品を使ったり色々と無理しないといけないことはわかってるから気にしないようになった(余談だけどあすけんはマクドナルドのポテトが野菜扱いなので便利です)。

というかあすけんで普段食ってる1日の飯を入れて計算すれば、60点取るのもそれなりに大変なのがわかるはず。無料でできるので試してみてほしい。

# 値段
業務用ジャワカレーで先の基本レシピで作った場合、米の分も含めて1食大体100円くらい。コスパは良い。

# その他
他にはトマト缶を使うとか卵を入れるとかアレンジしてみたけどやはりプレーンの業務用ジャワカレーが1番好きだった。栄養素的にはアレンジは良いと思うけどたまにで良いかな〜と思っている。

一旦は安定したスコアを叩き出せる手抜き電子レンジカレーを作れるようになったのでしばらくは続けてみようと思う。

そもそも毎日カレー食うような人間はいないと思うので誰得情報ではあるが参考にしてくれ...

おわり

毎晩手抜き電子レンジカレーを食い続けている

[Web Development with Ruby on Rails](https://amzn.to/3N2XFRl)を読んでる。

modelにロジックは書かない、1コントローラーメソッドに対して1Serviceにしてそこに必要なビジネスロジックは詰めこむ、serviceは1メソッドしかpublicにしない、serviceのpublicなメソッドの振る舞いのみ入念にテストするという割り切った考えは前評判どおりだけど思想強ぇ〜となった。

RailsでDDDとかやろうとするとドメインの整理から始まりmodelはただのDTOにしてentityやvalue object等の実装を用意して、なんというか少なくとも実装に関してはクラスがめちゃくちゃ増えていくイメージだけど著者はむしろそういうのと逆方向(というかRailsとしては自然な方向)に逆らわず標準提供されてる道具を使って、最低限のレイヤーをサステナブルという目的(ここが重要)を達成するためだけに追加するという考えだ。

設計に絶対的な正解はなく、未来・要件・チーム・言語・フレームワークなどにあらゆる環境によって最適な選択は変わるという当たり前のことを思い知らされる感じ。

[良いコード／悪いコードで学ぶ設計入門](https://amzn.to/3PNmkuN)を読んだあとなのでなおのことその実装方針の差が面白く感じた。

良いコード設計ができるというのはこういった多種多様な設計方針や実装方法の引き出しがあり、その中から妥当なものを選択できる能力なのだろうと思う。(もっと広い意味でだけど)アーキテクチャ選択に絶対はないというのは[ソフトウェアアーキテクチャの基礎](https://amzn.to/3POoAly)でも書いてあった気がする。

自分は金にならんプロジェクト(スタートアップのすぐ解散するアプリ開発や少人数開発みたいなもの)ばかりやってきたから将来性についてあまり深く考えなくてもぶっちゃけよくて、そんなに神経質に設計について固執してこなかった。そのツケみたいなもので設計に関するスキルにややコンプレックスがあるから最近はこういう本をいくつか読んで妄想したりしている。

自分のようなバックグラウンドの人間からするとどんなにクソコードでも金を産むコードに対してまずはリスペクトが生まれてしまうという悲しい性。めくじらたててキレ散らかしてる人を見るとなんともいえない感情にならん訳でもない。もちろんそれとこれとは別なのは理解するが....

Web Development with Ruby on Railsと悲しい性

昨日gialogで作ったブログを少しカスタマイズした。

具体的にはOGPの設定やTwitterボタンの設置。

最初GitHubのAPIにそんなに詳しくないからYAML front-matterでIssueから渡ってくるレスポンスの種類にどんなものがあるのかわからなかった。とりあえずはGitHubの[APIリファレンス](https://docs.github.com/ja/rest/issues/issues)を読むと大体解決した。

OGPの画像は記事内を正規表現で走査して最初に登場する画像を設定するようにしている。`/\((http[s]*.+\.(?:png|jpg|jpeg|gif))?\)/i`みたいなやつを使っているが、後方参照のキャプチャしないやつの書き方を思い出せなくてちょっと迷った。今回はキャプチャされてもいいんだけど、気分的に無駄なキャプチャは嫌である。グローバルな一致とかだとパフォーマンス問題が起きたりするなど[詳説 正規表現](https://amzn.to/3NaYcAs)に書いてた気もするから避けられるなら避けた方が良さげ。

あとちょっと困ってるのはOGP画像が仕様を超える解像度だった場合にTwitter Cardでうまく表示されない問題がある。これはどう対応したものかちょっと考えているところ。

それと雑でもいいので検索を設置したくてGoogle検索へのリンクを配置したがまだインデックスされていないから機能しない。時間が解決するのかなこれ。。


最後にOGPのテスト。先日[和処黒木](https://twitter.com/kurokijiro)に行った時に八木メシでお馴染みの八木栞FSKと撮った牛しぐれうどんでも載せておく。
![IMG_2962](https://user-images.githubusercontent.com/1421093/170851081-73034fa3-91c3-43be-94db-dcc08b642156.JPG)

ブログのカスタマイズ

## 経緯
昨日[GitHubに日記を書く運用](https://github.com/YuheiNakasaka/life/blob/main/_posts/20220527-tutorial.md)というやつを書いたんだけど、実際にやってみると色々と微妙に使い心地がよくなくてう〜〜〜んとなってしまった。

その旨をツイートしたところr7kamuraさんがGitHub issuesをエディタにしてブログを作れるクソ便利ツールを教えてくれた。

![https://user-images.githubusercontent.com/1421093/170819012-f920b5be-ec7b-4cfd-8bb4-ef4730de3754.png](https://user-images.githubusercontent.com/1421093/170819012-f920b5be-ec7b-4cfd-8bb4-ef4730de3754.png)

## gialogを使った日記の作り方
[r7kamura/gialog](https://github.com/r7kamura/gialog)のリポジトリのREADME.mdに書かれているリンクをポチっとやって、自分用のリポジトリを適当に作成する。するとGitHub Actionsが起動し、gh-pagesへNext.js製のSGGのブログサイトがデプロイされる。これだけ。

あとはissuesを更新することでActionsがその更新を検知して変更を反映してくれるという仕組みっぽい。

サイト自体は普通のNext.js製なのでテーマの概念とかはないけども、その辺は勉強がてらコードを拡張していけばいいんじゃないですかね〜という感じ。

最近のぴよぴよフロントエンドピーポーにとってはNext.jsが一昔前のRailsだろうから大体弄れるだろうし、ちょっとした現代のWordPress感あってよいなとも思った。