完全自動運転社会において事故で大事な人が死んだときにどうなるのか考える

Magic: The Gatheringの参入障壁が高すぎる理由を初心者目線で考える

【SRE】オンコールシフト最適化問題をClaudeで定式化しOR-ToolsとSCIPを用いて解く【数理最適化】

信頼性の高い設計を形式手法のTLA+とVibe Codingで作成しようとしてみた

Agent2Agent プロトコルを試して見えてきたGoogleの戦略

LINEヤフー株式会社を退職しました

2024年の振り返り 生成AIイベントとかキャリアとか

## 問題

iOSアプリにGoogle Analyticsを入れるとき、以下のように実装すると思う。

```
class AppDelegate: NSObject, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil
    ) -> Bool {
        FirebaseApp.configure()
        Analytics.setAnalyticsCollectionEnabled(true)
        return true
    }
}
```

Xcode 15.4でこれを愚直に入れたところPreviewがクラッシュするようになった。

## 解決策

以下のようにDEBUGではGoogle Analyticsを無効化することで解決した。

```
class AppDelegate: NSObject, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil
    ) -> Bool {
        FirebaseApp.configure()
        #if DEBUG
          // テストやプレビュー環境では Google Analytics を無効にする
        #else
          Analytics.setAnalyticsCollectionEnabled(true)
        #endif
        return true
    }
}
```

メインコードにDEBUGかどうかの分岐は極力入れたくなかったが、これ以外の解決策は自分には見つけられなかった。

誰かの参考になれば幸いです。

iOSアプリにGoogle Analyticsを入れるときはDEBUGではちゃんと無効にしよう

## トラペジウムを観た

トラペジウムは乃木坂46一期生の高山さん原作のアニメ映画。

https://trapezium-movie.com/

元々推しの子が好きだったりしたので、アイドルの黒い感情の話を自分は面白いと感じる節はあった。

その上で映画館で流れる宣伝や、

「賛否両論」「狂ってる」「サイコパス」

などの口コミを観て映画館に足を運んだ。

感想としては観て良かったと思う。以下ネタバレありです。

## 主人公の狂気と綱渡のような感覚

観て貰えば全員に納得してもらえると思うが、主人公も映画の構成もかなり狂っている。

そもそも主人公のサイコパス加減に共感できない視聴者も多く居たんじゃないだろうか。自分も10年前とかであれば全く共感できていなかったと思う。

しかし最近は「何者かになりたい」という欲求が本当にわかるようになってきた。仕事のやりがいとか、そういうくだらないと考えていた物に対する実感が今更ながら湧いてきて、例えば「宇宙よりも遠い場所」とかそういう話にとても共感するようになった。

また、ライブイベントに足を運ぶようになったのもあり、演者から感動を接種することも増えた。

だからただ「はじめてアイドルを見たとき思ったの。人間って光るんだって。」しか語られない主人公のモチベーションも自分は共感できた。それを踏まえても狂っているけれども。

そんな主人公がなんだかんだアイドルの夢を手にすることになるが、なんだかんだの部分が脆すぎていつ崩壊するのかとヒヤヒヤが止まらなかった。その時間が結構長く、こんなに狂った雰囲気をずっと出せるものかと感心した。

しかし崩壊は予定調和。その後どうまとめるのか予想しながら見ていたが、まさか普通に仲直りして普通に青春ものっぽくまとめるとは思わなかった。普通の感覚で言ったら青春時代を騙されてぶち壊されているわけで、そうはならんやろという感じ。最後まで狂っている。

それらの狂気にはこだわりを感じたし、それを味わえただけで観る価値はあった。

## 結局アイドルも営業マンも個人開発で一山当てたい人も同じ

鑑賞後に余韻に浸っているときに考えていたが、結局アイドルに必要な要素はこういうことなのではないか。

***青春ぶち壊されるほど騙されてもなんか許しちゃう***

つまり詐欺られようが金を搾り取られようがなんか許しちゃう。というのがアイドル性の重要な点なんじゃないかということ。スーパーチャットで稼いでいるVチューバーも同じ類。

これはとても聞こえが悪い。しかしこれはビジネスの本質でもあるんじゃないか？というのがこの記事で言いたいこと。

全て完全に原価 (人件費は含む) と等価交換でサービスを提供されるのであれば富を得ることはできない。そこに何らかの付加価値があることによって、ユーザーはその原価以上の金額を支払い、提供者は富を得るのだとする。

その付加価値の最たる例がアイドル性ではないか？

「なんか輝いて見える」「なんか応援したい」

そんなふわっとした印象が大きな付加価値となり、詐欺的とも言えるレベルの献金を可能にするのかもしれない。

そうなると例えば個人開発で売り上げを出したい開発者もどうしたら良いかの示唆が得られるんじゃないか。

自身やサービスそのものにアイドル性を付与できれば良い。そうすれば原価以上に高い金額でもユーザーは支払うかもしれない。逆に、アイドル性が無いサービスでは儲からない。

そしてそれはビジネスでは「差別化」とか「ブランディング」とか呼ばれている。

なんか繋がってしまった。

## まとめ

じゃあアイドル性って何なんだよって？自分は狂気だと思っている。

人生の貴重な時間を全て捧げて、人生が無価値になるリスクを追ってまで何かに熱中したときにのみ得られるなにかなんじゃないか。

一度きりの人生で失敗できないと思ってリスクヘッジに重点を置いている自分とは対照的で、だからこそ「トラペジウム」は面白く感じたのかもしれない

映画「トラペジウム」でなぜかビジネスの本質を得た気持ちになった

## 概要

オライリーの「プロダクションレディマイクロサービス」

https://www.oreilly.co.jp/books/9784873118154/

を読んだので、内容やノウハウをメモする。

## 全体感

UberのSREがプロダクションレディなマイクロサービスはどのようなものかについてチェックリスト的にまとめた書籍。

全体としては書籍の体は保っているものの、本当にチェックリストのようだった。

付録には本当にチェックリストという名目で箇条書きで掲載されており、確かにこれが網羅できていればプロダクションレディと言えそう。

一方で、これを全てやるのは至難の業。少なくとも日本国内だとこんなしっかりとしている企業は無いのではないかというレベル。

総じてイデア的に使うものであり、必要十分条件ではないと感じた。

(この書籍の内容が出来ていればプロダクションレディかもしれないが、プロダクションレディなサービスがこの書籍の内容を満たすとは限らない。)

## ノウハウ

本番対応の原則は以下の8つの項目である。

1. 安定性
2. 信頼性
3. スケーラビリティ
4. 耐障害性
5. 大惨事対応
6. パフォーマンス
7. 監視
8. ドキュメント

### 安定性

安定して動く、バグがない、のようなものではない。

CI/CDが整っているか、開発プロセスはわかりやすいか、など開発者目線での安定感が要点。

### 信頼性

テストは十分か、完璧なステージング環境があるか、カナリアリリースが行われているか、など。

### スケーラビリティとパフォーマンス

その名の通り。これらはまとめて語られていた。ボトルネックの明確化やキャパシティプランニングが適切に行われているかなど。

### 耐障害性と大惨事対応

これらもまとめて語られていた。単一障害点が無いこと、起こりうる大惨事が明確になっていること、障害対応手順の標準化など。

### 監視

ロギング、アラーティング、オンコールなどが適切に行われていること。ダッシュボードが整備されていること。

面白かったのは以下。

> オンコールランブックは、半分寝ている開発者でも難なくたどれるように書かれていなければなりません。

Susan J. Fowler. プロダクションレディマイクロサービス (p.233). Kindle 版. 

確かにその通りなのだが、「半分寝ている」という表現がちょっと面白かった。そんなランブックを書くことが果たしてできるのかという疑問は残るものの、やはり理想としては間違いない。

### ドキュメント

> 本番対応のよいドキュメントの目標は、サービスについての知識を一元的に管理するリポジトリを作って、メンテナンスすることです。共有すべき知識は、サービスについてのありのままの事実と、サービスが何を行い、組織全体でどのような位置を占めるかについての組織的な理解の両方です。そのため、ドキュメントが貧弱だという問題は、ドキュメント（事実）の欠如と理解の欠如の2つの下位問題に分けることができます。これら2つの下位問題を解決するには、すべてのマイクロサービスを通じてドキュメントを標準化するとともに、マイクロサービスについての理解を共有するための組織的な構造を用意する必要があります。

Susan J. Fowler. プロダクションレディマイクロサービス (p.224). Kindle 版. 

ドキュメントに関する項目があるのが非常に意外だった。他の項目は当たり前な部分が多いが、この項目に関しては新たな示唆が得られた気がする。

他にも引用しておくと以下のようにも書かれていた。

> 多くの開発者は、リポジトリ内にREADMEファイルを置くかコードにコメントをばらまいておけば、ドキュメントとして十分だと思っています。READMEファイルは必要不可欠であり、すべてのマイクロサービスのコードには適切なコメントが含まれていなければなりませんが、READMEは本番対応のドキュメントではなく、コメントはチェックアウトしてコード中を探し回らなければならなければ役に立ちません。

Susan J. Fowler. プロダクションレディマイクロサービス (p.226). Kindle 版. 

ドキュメントの有無は本当に大きい。「コードを読めばわかる」なんて表現は、個人的には場当たり的にコードを書く能力、時間しかありませんと言っているようなものだと思う。

例えばマイクロサービスとして利用している他チームのAPIを呼ぶ際に適切なタイムアウト値が知りたいとする。そんなとき「コードを読んでください」なんて言えない。API仕様書などの明示できるドキュメントが無ければ、利用者全員に対して個別に回答しなければいけないかもしれない。

全体として大規模なサービスになればなるほどマイクロサービスの利用者も増えるので、大手ほどこの問題が発生する可能性が高いはず。この書籍は全体的にそういう対象について議論しているように見える。

## まとめ

「プロダクションレディマイクロサービス」について感想やノウハウをまとめた。

誰かの参考になれば幸いです。

「プロダクションレディマイクロサービス」を読んだ

## 概要

芹澤 連 (著) の「戦略ごっこ―マーケティング以前の問題」

https://www.amazon.co.jp/%E6%88%A6%E7%95%A5%E3%81%94%E3%81%A3%E3%81%93%E2%80%95%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E4%BB%A5%E5%89%8D%E3%81%AE%E5%95%8F%E9%A1%8C-%E8%8A%B9%E6%BE%A4-%E9%80%A3/dp/4296204041

を読んだので、内容やノウハウをメモする。

## この記事で伝えたいこと

私は主にWebサービスを作っているエンジニアなので、個人開発する際にどのようにマーケティングすべきかについてこの本を読みながら考えた。

結論としては

***とにかく認知を取れ***

これだけ。データを見ると結局これに帰結する。特別なマーケティングの裏技なんてものは無い。

特に「どんな場面で想起してほしいか？」を考えて、そこをプッシュすることが重要。既存サービスと似ているサービスの場合、差別化部分より似ている部分をプッシュすることで最初は想起を得られやすい。

以降で少し詳しく書いているので時間がある方は読んでほしい。

## 書籍の感想

### 全体感

この書籍はマーケティングの基本として書かれている「購買ファネル」「顧客育成」「ブランディング」などに関して、論文などで科学的な方法で報告されている事実と、それ以外のお気持ちマーケティングを明確に区別して書かれている。

後者をやっても良いが、前者については単純に事実であることから、それを無視して後者をやっていても大した成果は得られないよね、という話をしている。

その上で、前者の科学的な成果をサーベイ的に報告しているのがこの書籍である。

### ダブルジョパディの法則

例えば、「うちは小さなブランドでニッチを攻めているので少ないロイヤル顧客に支えられている」は基本的に嘘である。真実は「小さなブランドは顧客数もロイヤルティも低い」で、大手と比べるとどちらも低くなる。

ロイヤルティだけを高めることはできず、顧客数とロイヤルティは常に一緒に動く。したがって、「小さいブランドはロイヤルティの高い顧客の満足度を高めれば顧客数が上がっていく」ということもない。

このように、どちらかが低い代わりにどちらかが高い、ということは無く両方とも低くなる、という事実をダブルジョパディと呼ぶ。

ほとんどのブランドに関して、ブランドの浸透率と購入回数は一定の曲線の上に乗ることが報告されている。

細かな差別化を行なってもこの曲線から逸脱して片方だけを伸ばすことはできない。顧客目線で差別化されている必要がある。

顧客はブランドではなく文脈で差別化している。我々がiPhoneを買うのは「下手に失敗したくないし、周りと同じものが良い」と思った時にiPhoneが思い浮かぶから買うのであり、iPhoneというブランドだから買うのではない。

### ユーザーの消費行動

特に消費財においては需要が先行する。すなわち、よく言われている

1. 注意
2. 関心
3. 欲求
4. 記憶
5. 行動

のような順序で発生するわけではない。

実際にはユーザーの行動はまず需要があり、その課題を解決するために想起される商品の集合からランダムピックされるような確率モデルで近似できる。

つまり過去の購買行動でヘビーとかライトとか分類することに大した意味はなく、ヘビーだからといって今後も大量に購入し続けてくれる証拠は全くない。ただの確率の揺らぎで、偏った結果が出たユーザーをヘビーとか呼んでしまっているだけである。

### 実際にやるべきマーケティング

ユーザーの想起集合に候補として上げられなければ絶対に購買されないし、他の指標もダブルジョパディの法則で達成できない。つまりはいかに多くの文脈で想起を得られるかがコアな部分となる。

したがって、現状リーチできていない層にリーチできる施策を行なったり、よく知らないユーザーが多い場合はまずは他のブランドとの類似点をプッシュし、そのブランドが買われる際に一緒に想起される状態にすると良いかもしれない。

また、ROIが良い施策だけやってれば良いというわけでもない。限界効用逓減の法則的にやればやるほど増分が少なくなっていく。したがって少しやってROIが良い施策をやっても思ったような効果は得られない。

## まとめ

「戦略ごっこ―マーケティング以前の問題」について感想をまとめた。

誰かの参考になれば幸いです。

エンジニアが「戦略ごっこ―マーケティング以前の問題」を読んだ

## 概要

XCodeのAssetにマルチバイト文字のファイル名のファイルを入れてはならない。

## 詳細

XCodeのAssetにマルチバイト文字のファイル名のファイル、つまりは日本語のファイル名のファイルを入れると、ビルド時にエラーが発生する。

しかも、エラーメッセージがわかりにくい。私の環境ではローカルでは全く問題がなく、XCode Cloudでビルドした場合にのみ画像が一部だけ表示されないという問題が発生した。

XCodeのAssetのUI上で名前を変更するだけでは解決しない。ファイル名を変更してファイルを上書きしなければならない。

一見問題がないように見えるところが非常に厳しい。やはりマルチバイト文字を使うのは避けるべきだと感じた。

## まとめ

XCodeのAssetにマルチバイト文字のファイル名のファイルを入れてはならない。