<p></p>
<h1 id="miketako3"><a class="header-anchor-link" href="#miketako3" aria-hidden="true"></a> miketako3</h1>
<h2 id="business-name"><a class="header-anchor-link" href="#business-name" aria-hidden="true"></a> Business Name</h2>
<p>蛭田 海斗 (Kaito Hiruta)</p>
<h2 id="career"><a class="header-anchor-link" href="#career" aria-hidden="true"></a> Career</h2>
<table>
<thead>
<tr>
<th>時期</th>
<th>所属</th>
<th>経験</th>
</tr>
</thead>
<tbody>
<tr>
<td>2017/05 - 2017/12</td>
<td>スマートアプリ株式会社 (インターン)</td>
<td>Laravel, iOS</td>
</tr>
<tr>
<td>2018/01 - 2019/03</td>
<td>ヴァンテージIT株式会社 (インターン)</td>
<td>Firebase, Vue, Ansible</td>
</tr>
<tr>
<td>2019/04 - Now</td>
<td>LINEヤフー株式会社</td>
<td>Spring Boot, RDB, NoSQL, DevOps, SRE</td>
</tr>
</tbody>
</table>
<h2 id="skills"><a class="header-anchor-link" href="#skills" aria-hidden="true"></a> Skills</h2>
<table>
<thead>
<tr>
<th>スキル</th>
<th>経験度</th>
<th>説明</th>
</tr>
</thead>
<tbody>
<tr>
<td>Java</td>
<td>⭐︎⭐︎⭐︎⭐︎⭐︎︎︎</td>
<td>実務で主に使用しています。</td>
</tr>
<tr>
<td>Spring Boot</td>
<td>⭐︎⭐︎⭐︎⭐︎⭐︎︎︎</td>
<td>実務で主に使用しています。</td>
</tr>
<tr>
<td>SRE</td>
<td>⭐︎⭐︎⭐︎⭐︎</td>
<td>インフラではなく原義的なSREの知見があります。</td>
</tr>
<tr>
<td>DevOps</td>
<td>⭐︎⭐︎⭐︎⭐︎</td>
<td>CI/CDを整えるなど。</td>
</tr>
<tr>
<td>Kubernetes</td>
<td>⭐︎⭐︎⭐︎⭐︎</td>
<td>実務経験があります。</td>
</tr>
<tr>
<td>Cassandra</td>
<td>⭐︎⭐︎⭐︎⭐︎</td>
<td>実務経験があります。</td>
</tr>
<tr>
<td>Redis</td>
<td>⭐︎⭐︎⭐︎⭐︎</td>
<td>実務経験があります。</td>
</tr>
<tr>
<td>MySQL</td>
<td>⭐︎⭐︎⭐︎⭐︎</td>
<td>実務経験があります。</td>
</tr>
<tr>
<td>Cassandra</td>
<td>⭐︎⭐︎⭐︎⭐︎</td>
<td>実務経験があります。</td>
</tr>
<tr>
<td>Google Cloud</td>
<td>⭐︎⭐︎⭐︎</td>
<td>Professional Cloud Developerの資格を取得しています。</td>
</tr>
<tr>
<td>Next.js</td>
<td>⭐︎⭐︎⭐︎</td>
<td>SSGを中心にですがReact関連などを基本として実装可能です。</td>
</tr>
<tr>
<td>Remix</td>
<td>⭐︎⭐︎</td>
<td>実装可能です。</td>
</tr>
</tbody>
</table>
<h2 id="products"><a class="header-anchor-link" href="#products" aria-hidden="true"></a> Products</h2>
<p>個人プロダクトです。</p>
<table>
<thead>
<tr>
<th>プロダクト</th>
<th>説明</th>
<th>要素技術</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="https://miketako.xyz" target="_blank" rel="nofollow noopener noreferrer">miketako.xyz</a></td>
<td>このサイト</td>
<td>Next.js、Cloudflare Pages、Tailwind CSS、TypeScript、Github Actions</td>
</tr>
<tr>
<td><a href="https://www.youtube.com/@code385-miyako" target="_blank" rel="nofollow noopener noreferrer">Code.385 Miyako</a></td>
<td>AI Tuber</td>
<td>ChatGPT、LangChain、VITS、FastAPI、Docker、Google Cloud</td>
</tr>
<tr>
<td><a href="https://niche.love" target="_blank" rel="nofollow noopener noreferrer">Niche Love</a></td>
<td>SNS</td>
<td>Remix、Cloudflare D1、Workers、R2、Grafana Cloud</td>
</tr>
<tr>
<td><a href="https://apps.apple.com/jp/app/blue-biscuit-%E8%A8%BA%E6%96%AD-%E3%83%A1%E3%83%B3%E3%82%BF%E3%83%AB%E3%82%B1%E3%82%A2%E3%82%B2%E3%83%BC%E3%83%A0/id6504722201" target="_blank" rel="nofollow noopener noreferrer">Blue Biscuit</a></td>
<td>メンタルケア iOSアプリ</td>
<td>Swift UI、Xcode Cloud</td>
</tr>
</tbody>
</table>
<h2 id="%E3%81%8A%E4%BB%95%E4%BA%8B%E4%BE%9D%E9%A0%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><a class="header-anchor-link" href="#%E3%81%8A%E4%BB%95%E4%BA%8B%E4%BE%9D%E9%A0%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> お仕事依頼について</h2>
<p>技術相談、技術顧問などの依頼を受け付けております。</p>
<p>基本的には</p>
<ul>
<li>本業以外の時間で週1回1時間程度のミーティング</li>
<li>チャットツールでのコミュニケーション</li>
</ul>
<p>をベースに要相談とさせていただければと思います。</p>
<p>幅広く対応可能です。技術調査から運用まで伴走させていただきます。</p>
<p>お仕事の依頼は<a href="mailto:contact@miketako.xyz">メール</a>にてお願いいたします。</p>
<p>(本業側での申請が必要なため、業務開始にはリードタイムがある場合がございます。)</p>
<h2 id="other-interests"><a class="header-anchor-link" href="#other-interests" aria-hidden="true"></a> Other Interests</h2>
<p>Look at <a href="/posts/likes">Likes</a>.</p>


みけたこ (miketako3) について

## トラペジウムを観た

トラペジウムは乃木坂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にマルチバイト文字のファイル名のファイルを入れてはならない。

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

## 概要

技術書典16にサークルとして初参加したので、感想やノウハウを備忘録としてまとめる。

https://techbookfest.org/product/t0gGBQLsrkizaw1en9skWJ

## 感想

### 本を作るのは大変

同人活動がそもそも初めてだったのだが、まず「本を作る環境」を作ることが大変だった。TechBoosterのReVIEW-Templateのコードを読み込み、

https://github.com/TechBooster/ReVIEW-Template

それを元に自分が使いやすいように整備した。それについての詳細はZennの記事にまとめた。

https://zenn.dev/miketako3/articles/d6407d5280d298

本のサイズは？余白は？ページの通し番号は？それらを適切に一から整備するのは非常に厳しい。よくわからない人はTechBoosterのReVIEW-Templateを使うのが一番だと思う。

ただし、それでも設定ファイルやReVIEWの仕様を理解する必要があり、ビルド設定やPDFの生成方法等もWebのエンジニアじゃないと馴染みがなくて辛いと思われる。

本文を書くだけである程度綺麗に出来上がるフォーマットが欲しいところ。

そして本文を書くのも当然大変で、自分の場合は目標としていたページ数まで到達しなかった。

初回ということでそこまで無理しないように作ったが、次回はもう少し構成を練ってページ数を増やすようにしたい。

### 本を売るのも大変

まず宣伝をしないといけない。マーケティングの一番最初は認知から始まる。

自分の場合はTwitterを使ってフォロワーを増やし、イベント当日にはそのフォロワーに宣伝を行なった。

また、お品書き画像を作ったり、当日の運用を考えたりと、本を売るためにはかなりの労力が必要だった。

### 得られるものは大きい

それでも、技術書典に参加して得られるものは大きい。

自分は今まで在庫を抱えるような商売をすることはリスクの大きさからなるべく避けてきた。

今回初めて同人活動とはいえそのような経験をして、かなり勉強になったと思う。

そんな大量に儲けが出たわけでは無いが、初めてで赤字ではないだけ御の字というところだろう。

オフラインも終了したら赤裸々に収支を公開したい。

## ノウハウ

### 入稿フォーマットや締め切りをなるべく早めに確認する

同人イベントに参加したことが無い場合、印刷所の入稿フォーマットや締め切り等の情報を特に早めに確認しておくべき。

日光企画においては以下で、表紙テンプレートはここからDLして編集した。

https://www.nikko-pc.com/offset/template/tonbo.html

本文の方は前述のテンプレートから生成すれば問題なかった。

印刷の専門用語が全くわからないばかりか、デザインの知識もないので、非常に時間がかかった。

表紙、本文共に入稿フォーマットは必ず最初に確認しよう。

### PhotoshopやIllustratorが無くてもなんとかなる

自分の場合は互換のAffinity Publisherを使ったが、簡易的な表紙デザインであれば無くてもなんとかなる。

他のデザインソフトでも同様だろう。ただし、最低限psd形式が読み込める方が良い。

とはいえ余裕があるならデザイナーに依頼するのが一番ではある。デザインは難しい。

今回はロゴとかヘッダーとか色々なクリエイティブも一緒に作成した。統一感を持たせるのはかなり大変だった。

![名刺表](/tech-book-fest-16/名刺表.png)
![名刺裏](/tech-book-fest-16/名刺裏.png)
![ロゴ](/tech-book-fest-16/ロゴ.png)

### 宣伝はなんだかんだX (Twitter)

現状最も認知が稼げるプラットフォームはXであるから、それをやらない手はない。

2ヶ月前あたりから意識して、1ヶ月前あたりからはフォロワーを増やす動きを意識的に行なった。

具体的にはツイート頻度を増やしたり、いいねやフォローを行なったり。

個人的にはプロ驚き屋には絶対なりたく無いという思いもありかなり辛かった部分だが、なんとか上手くバランスを取れたと思っている。

また、お品書き画像は必ず作るべき。SNSでの宣伝には欠かせないし、当日ポスター的に飾って宣伝するのにも使える。

https://x.com/miketako3/status/1794545296472711469

### 当日の設営

![設営](/tech-book-fest-16/設営.png)

今回は技術書典の手ぶらセットというものを申し込んだため、以下は用意されていた。

- テーブルクロス
- マッキー
- 決済QRコードが書かれた紙とスタンド
- ポスター的なもの
- マスキングテープ
- 色々なものを立てかけられる簡易スタンド
- デコレーションシール

それ以外にも色々と準備した。

まず何らかの形でお品書きポスターは用意しておくべき。こなれている感はかなり売り上げに関わるんじゃ無いかと思っている。

また、本は見本用に何冊か用意し、透明ブックカバーをつけておくと良い。見本だけ見て買わない人もいるが、そういう人は買っても満足してはくれないので、見てくれただけありがたいと思っておくべき。

あとは名刺を作って本と一緒に配ったり、ぬいぐるみを置いておいたり、モバイルディスプレイで画像をスライドショーしたりしてとにかく目に止まるようにした。

### 現金決済には対応しておくべき……は古いのかもしれない

現地の電波障害や、そもそも公式後払いに対応していない方のために、現金決済は可能な限り対応しておくべき……と思っていた。

私は先人に倣い、パスワード付きのZIPファイルを用意しておき、購入者にパスワードを記した紙を渡すことで対応できるようにした。

https://miketako3.booth.pm/items/5754237

しかし、実際は特に何の問題もなく全員が公式後払いでの決済をしてくれた。

1人だけ現金決済を希望された方がいたが、お願いしたら後払い決済にしてくれた。後払いはキャンペーンもやっていたので非常にありがたかった。

https://blog.techbookfest.org/2024/05/11/tbf16-event-print-order/

もはや現金は対応しなくても良いのかもしれない。

## おわりに

今回は技術書典16にサークルとして初参加して、得られたノウハウをまとめた。

次回はもう少しページ数を増やして、より多くの人に読んでもらえるような本を作りたい。

まだオフライン開催は続くが、オフラインも終了したら赤裸々に収支を公開したい。

この記事が誰かの参考になれば幸いです。

良かったらX ([Twitter](https://x.com/miketako3)) をフォローしてください！

技術書典16にサークルとして参加した

## 概要

![キーボードの写真](/make-keyboard2/img.png)

https://shop.yushakobo.jp/products/8961

Corne Cherry V4というキーボードを~~作った~~買ったので、感想と使い心地について語る。

## Corne Cherry V4

基本的なところは以前レビューしたV3と同じ。

https://miketako.xyz/posts/make-keyboard

主に違っているのは以下の点。

- 半田付け、ファームウェア導入済み
- ケース付き
- 中央に左右2キーずつが追加 (ロータリーエンコーダにも変更可能)

それぞれ詳細を書いていく

## 半田付け、ファームウェア導入済み

キースイッチどころかマイコン、端子、LEDに至るまで全て実装済みだった。

さらにファームウェアもすでにマイコンに入っていた。

これによりネジ止めとキースイッチ、キーキャップのはめ込みだけで完成するので、あとはRemapで好みのキー配置にすればすぐに使える。

もはや自作キーボードではなくスイッチなどが選べるだけで普通に市販キーボードだった。

自作キーボード界隈もここまで進化したか…という感じ。

## ケース付き

かなりすばらしい。これにより打鍵感や安定感が向上し、所有欲的な部分まで満たせるようになった。

V3では基盤剥き出しだったのでどうしてもチープな感じが抜けなかったが、ケースがついたことでそれが解消された。

## 中央に左右2キーずつが追加

V3ではProMicroが乗っていた部分にキーが追加された。

自分はロータリーエンコーダに変更することなくキーにしているが、現状使いたい機能がそこまでなく持て余している。

最初はマクロとかで活用しようと思っていたが……他のキーでできるショートカットはそのキーを押せば良いし、それ以外はAlfredで呼び出せば良い。 1ボタンでキーボードから呼び出したいものが現状思いついていないという状態。

Artisanキーキャップを使う絶好の場所なのでそういう用途としては今後使っていきたい。

## まとめ

半田付け不要でケースも付いているというところで、V3と比べると相当ハードルが下がり、かなり万人にオススメできる仕上がりだった。

40%キーボード、column staggered、というところに魅力を感じる人にはぜひ使ってみてほしい。

自分は巡り巡って結局ずっとV3を使い続けていたので、今後はV4を使い続けることになりそう。軽いキースイッチ ([遊舎工房軸](https://shop.yushakobo.jp/products/5659)) を使っているのも相まってかなり疲れにくくなった。

https://shop.yushakobo.jp/products/5659

製作者のfoostanさんに感謝。

## おまけ

私のキー配置は以下の通り。

私の知能ではレイヤーは2つが限界だったのでそれに絞り、右手だけで矢印キーを使えるようにしているのがこだわりポイント。

記号の配置は苦肉の策という感じだが、矢印キーの配置を維持しつつなるべく通常の配列から離れさせたくなかったのでこうなって安定している。

![キー配置](/make-keyboard2/img2.png)

Corne Cherry V4を買った

【第3回】生成AIなんでもLT会 主催振り返り (@miketako3)


## 概要

中村昇著の「ウィトゲンシュタイン『哲学探究』入門」をAudibleで読んだので感想をまとめる。

https://www.audible.co.jp/pd/%E3%82%A6%E3%82%A3%E3%83%88%E3%82%B2%E3%83%B3%E3%82%B7%E3%83%A5%E3%82%BF%E3%82%A4%E3%83%B3%E3%80%8E%E5%93%B2%E5%AD%A6%E6%8E%A2%E7%A9%B6%E3%80%8F%E5%85%A5%E9%96%80-%E3%82%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%82%AA%E3%83%96%E3%83%83%E3%82%AF/B0BTLR8BNQ

## 感想

### ウィトゲンシュタインの思想

ウィトゲンシュタインというと、

> 語り得ぬものについては沈黙せねばならない

とか、

> 語の意味とはその使用である

とかが有名だが、全体的に「答えが出ない問題を考えても仕方なくね？ワロタ」みたいな感じがあって、それは考え方が似ていて共感があった。

### 自分との比較

ただ「語り得ぬもの」とか「語の意味」とかそういうものへの諦観が強いように見えた。

自分は広義の意味では決定論者で、所詮有限なこの世の全要素を記述すれば全てを記述可能なはず、という立場。

したがって、この世のatomicな要素を全て物理的に記述すれば確率的に「語り得ぬもの」は無くなるはず、と思っている。この点では少し見解が違った。

まあその上での有限なステートマシン的なものとして人間を見ている自分の方が、諦観が強い可能性もあるが……。

### 書籍自体の感想

また、解説者の思想が（入門書なので当然だが）出過ぎていたので、原著を読みたくなった。

自分の思想とウィトゲンシュタインの思想が似ていたのか、ウィトゲンシュタインから引用された文は全て非常にしっくり来たので、こういう変なやつはきっと入門書のターゲットではないんだろう。

そのせいで、途中で聴く気が無くなってきてしまった。

とはいえ解説自体はとても良いもので、英語とドイツ語の違いについての解説などの補足情報が非常に丁寧だった。

普段そういうことを考えてない人にはとても良い。 

自分も非常に参考になったことは明記しておく。

### Audibleについて

散歩中に本を読みたくてAudibleを使ってみたが、非常に良かった。

まず画面を目の前に持っていなくても良い。これだけで要件としては満たされていた。

倍速にできるのも個人的には非常にマッチしていたし、読み手の声も聞き取りやすい。

ラインナップが変な自己啓発本やビジネス書ばかりなのが残念で、もう少しちゃんとした本が増えるともっと使いやすいのにもったいないサービス。

## まとめ

総じてもう少しウィトゲンシュタインに踏み込みたくはなった。

厨二病のまま大真面目に成長してしまった自分としては、似た思想の人間を常に探している節があって、ウィトゲンシュタインは比較的近いかもしれない。

次は哲学論考かな。

「ウィトゲンシュタイン『哲学探究』入門」を読んだ

## 概要

技術書典にいい加減参加したく、こんなものを作った。

https://github.com/miketako3/teckbook-template

TechBoosterのRe:VIEWテンプレートを改変したものになる。Webエンジニア目線では使いやすいかもしれない。

## 技術スタック

- Re:VIEW
  - 誤解を恐れずにいえばLaTexのラッパー
  - 技術書を描きやすいらしい
  - markdownっぽい形式の.reファイルを書いてPDFに変換できる
- VSCode
  - Re:VIEWの補完ができる拡張機能がある
  - 本当はIntelliJが良かったが…流石にプラグインを作りたくは無い
  - devcontainerは便利ではある
- Dev Containers
  - VSCodeの機能
  - Dockerを使って開発環境を構築する
  - Re:VIEWのDockerイメージが公式に配布されているのでそれをベースにすれば楽ちん
  - ということで元々のテンプレートからそのまま持ってきた
- GitHub Actions
  - 元々のテンプレートではCircleCIで校閲、Github ActionsでPDF作成としていたが、慣れや使い勝手もあり全てGitHub Actionsに変更した
  - Github前提となるので、GitLabなど用のファイルは全て削除した
- textlint
  - 文章の校閲ツール
  - スタンダードな技術だと思っているので採用した
  - PR時に自動的に実行される
- reviewdog
  - textlintの結果をPRコメントに表示してくれる
  - さすがにコメントが無いと使いづらいので採用した

## 感想

これでやっと書けるわけだが、書くまでに手間がかかりすぎる……。

もっと楽に書ける環境があると参入障壁が下がるのになーとなる。

自動校閲とか自動バージョニングとかをいい感じに入れたSaaSがあって、技術書典とか印刷会社とかとシームレスに連携できたら最強な気がする。

## 参考

https://reviewml.org/ja/

https://review-knowledge-ja.readthedocs.io/ja/latest/

https://github.com/TechBooster/ReVIEW-Template

https://zenn.dev/karaage0703/articles/52be7d25f7d76b

https://zenn.dev/b0b/articles/reviewdog_textlint_ga_tested

技術書典に向けて執筆環境を整えた

エンジニアなら自分でブログを作れ！③Markdownのカスタマイズ編

## 概要

![キーボードの写真](/make-keyboard/img.jpg)

https://shop.yushakobo.jp/products/corne-cherry-v3

Corne Cherry V3というキーボードを作ったので、制作した感想と使い心地について語る。

なお、この記事も同キーボードで書いている。

## Corne Cherry V3

column staggeredで親指３キーの４０％キーボード。左右分割になっている。

何故このキーボードにしたかというと、実機を触った際のフィット感に加えて以下の要素が決め手だった。

- 遊舎工房のキャンペーンでキースイッチが無料だった
- 数字キーが遠いと感じていた

このキーの少なさは挑戦的だったが、すでに６０％を使っていたのでまあ慣れるだろうくらいの気持ちだった。

## 組み立て

１５年振りくらいに半田付けをした。なんとかうまくできたと思う。

キースイッチのピンがよく曲がってしまったのが辛かった。

組み立ては遊舎工房のレンタル作業場を利用させてもらった。

光らせる気はなかったのでキットについてくるLEDはつけなかったが、それでも3時間かかった。レンタル代だけで３０００円かかった。

## 使用感

すばらしい。何がすばらしいかというと、数字キーや矢印キー、記号キーのためにホームポジションが崩れることがなくなりそうということ。

また、左右分割というのもすばらしい。まったく窮屈感がなく快適にタイピングできている。

記号などを打つのに複数キーの入力が必要で配列に慣れるまでまだだいぶかかるとは思うが、慣れたら今まで以上の速度で疲れず入力できそう。

## まとめ

雑な記事になってしまったが取り急ぎこのキーボードの入力に慣れたかったので書いてみた。

自作キーボードは沼だとよく言われているが、1人でも沼に引き摺り込めたら幸いである。

Corne Cherry V3を組んだ

## はじめに
私miketako3は2月末ごろからうつ病で休職していました。現在も休職中ではありますが、だいぶ体調も回復し復職も近づいてきているので、このタイミングで記事を書こうと思います。

こうした内容を公言するかどうかは悩みました。周りの人にはうつ病になりそうに無い人と思われている感覚があって、それを破壊してしまうのが嫌だったというのもあります。

ただ、うつ病なんだよねと言うことの面倒臭さよりも言わないことによる不快感が大きかったというのもありますし、公開することで誰かの助けになるかもしれないというのもあってこの記事を書くことにしました。

## 周りの人に伝えたいこと

今まで公言していなかったので当然ですが、普段と変わらず接してもらえたのがとても良かったと思っています。

今後も配慮はいらないので特に変わらず接してください。うつ病に関することは聞かれたくないとかそういうことは特にないので、普通に話に上げてもらっても良いです。聞かれれば何でも答えます。

以下長文になるので気になる方だけ読んでください。

## 経緯
コロナ禍によるリモートワークや自粛の影響で体調を崩したりもしましたが、これまでなんとかやってきていました。

しかし、2021年後半くらいから徐々に無気力感や倦怠感、体の痛みが大きくなってきました。何をするにも入り込めていない感じというか、ストレスが発散できていない感覚がありました。

2022年1月末頃に産業医に相談しましたが、その時はまだ仕事が全くできないというほどでもなかったため相談のみで終わりました。

その直後、業務的にしんどい時期が続き、とどめを刺されたように体調が悪化していきました。そして産業医に二度目の相談をしたところ心療内科を勧められ、そのまま2月末には休職となりました。急に休職したのでいろんな人に迷惑をかけたと思います。

休職後１ヶ月はほぼ寝て過ごし、3ヶ月程度経ったときには、疲れやすさが残るものの日常生活をするだけなら問題ないレベルとなりました。

そこからさらに３ヶ月程度、仕事ができる集中力を取り戻すために使い、現在ではそれなりに仕事ができそうな体調まで回復しています。

## そもそもうつ病とは何なのか

情報ソースはほぼネットのみなので詳しくは専門のソースを見てほしいですが、ある程度は自分で調べて理解したつもりです。

### 概要

うつ病とは気分障害の一種で、うつ状態 (いわゆるうつ病っぽい状態) が2週間以上続いている場合につけられる診断です。原因はよくわかっていないようですが、脳内のセロトニン等が不足したことによって起きるという説がありますし、少なくとも脳に病的な何かが起きて発症したと考えられています。ただの精神的な問題ではないということです。

いわゆる新型うつ等と呼ばれることもある適応障害とは区別され、原因を切り離した時にうつ状態ではなくなるのが適応障害で、そもそも原因が定かではないのがうつ病という理解です。(なので、適応障害の場合は業務は無理でも休日は元気だったりするわけです)

### 症状

症状としては精神的なものとお肉体的なものがあり、例えば以下のようなものがあります。肉体的な症状があるということは知らない人には意外なんじゃないかなと思います。

- 精神的
  - 気分が落ち込む
  - 意欲が無くなる
  - 集中力が無くなる
  - 不安になる
- 肉体的
  - 頭痛
  - 腰痛
  - 肩こり
  - 睡眠障害
  - 食欲不振や過食

### 診断

うつ病や適応障害の診断は操作的診断というものによって行われます。わかりやすく言えば心理テストみたいなやつです。

いまのところそれらを正確に検査するのは難しく、症状によって診断するしかありません。そのため、医者によらない客観性のある診断をするために心理テストの規格を作っているみたいなことのようです。

以下の記事によれば、うつ病の9割弱がICDという診断基準、残りがDSMという診断基準で診断されています。

http://www.kokoronomori.jp/2014/05/21/post-53

つまり、ICDやDSMを覚えれば誰でもうつ病の診断を得られる可能性があるわけです。これは、本当にうつ病に悩む人にとってはあまり良いことではないと思います。自分の症状はただの甘えなんじゃないかという気持ちになってしまいます。まあ本当に患っている人はそんな勉強する余裕は無いわけですが、ライフハック的に使用する心無い人によって偏見に晒される可能性を考えると早く検査法が確立してほしいと願うばかりです。

### 治療

うつ病の治療で重要なのは以下の4つです。

- 休養
- 環境調整
- 薬物治療
- 精神療法

そのため、精神科や心療内科でうつ病と診断されると、休職の診断書が出たり薬が処方されたりするわけです。

なお、精神科や心療内科、クリニックはほぼ同じ意味です。名付けが自由なのでばらつきがあるというだけです。

精神科で薬物治療と聞くとなんだか怖いイメージがありますが、最近は副作用が比較的少ない薬もありますし、イメージほどのヤバい薬が処方されることはあまり無いんじゃないかなと思います。

また、治療の効果は徐々に現れていきます。風邪等と一緒である瞬間からいきなり全快とはならないので、最初は寝たきりだとしても徐々に活動量が上がっていくと思います。そのため、うつ病だからといって何もできないわけではないです。これも世間一般のイメージと乖離があるんじゃないかなと思います。

### お金周り
休職中は一般的には傷病手当金というものが健康保険から支給されます。金額としては月給の2/3程度です。 また、企業によってはさらに所得保障がある場合があり、月給の2/9程度が追加で支給されます。ボーナスはありませんし、支給までにかなりタイムラグがあるとはいえ、この期間は働かずにお金がもらえるわけですね。

働かずにお金がもらえるなんて最高じゃないかと私も休職以前は思っていたのですが、やってみるとそんなに良いものではありません。

そもそも大半の期間は遊んだり出来る余裕が体調的にありませんし、精神的にも遊んでいられるような状態ではありませんでした。本来感じる必要は無いのですが、ズル休みをしているような感覚になります。

かなりの図太さがないと悠々自適に過ごすのは難しいでしょうし、そのような人はうつ病にならなそうです。

さらに、治療が進んでいないと思われれば不要に薬が増やされるわけで、副作用があることを考えればあまりやりたくはありません。

結局は真面目に治療に専念するのが一番良いわけで、そういう意味では安心して休める傷病手当金という制度は良いものだと思います。

## 自分の場合
### 症状

私の休職直前の症状は以下のようなものでした。

- 食欲不振
  - 朝昼はほぼ抜き、晩も少量のみが多かったです。
- 睡眠障害
  - 寝付くのに数時間かかり、夜中に目が覚めるような状態でした。
  - うつ病が原因かはわかりませんが寝汗がひどかったです。
- 倦怠感
  - 頭が重いという表現がこんなにも適切なのかと感動するくらいには頭が重かったです。
  - 業務後の倦怠感は酷く、ほぼ寝ていました。
- 集中力の欠如
  - 集中できるのはせいぜい1日1時間程度でした。
- 気分の落ち込み
  - 死んだ方がマシ的な考えもありました。
  - よくわからなくなり涙が出たことも一度だけですがありました。
  - 何をしても気分がよくなる感じがしませんでした。
- 体の痛み
  - 右上腹部の違和感や痛みが特にひどかったです。
    - これについては随分前からあって超音波検査もしましたが異常はありませんでした。
  - 右足の付け根の痛みもありました。
- 肩こり
  - これはデスクワークなら誰でも起こるのでうつ病によるものかどうかはわかりませんが、少なくとも現在はそこまで酷くはありません。

気分が悪くてやる気が出ないだけとかであれば個人的には休職するようなものではないのですが、集中したくてもできないという状態で流石に業務に支障がありました。

### 処方

私が処方された薬は主に抗うつ剤と睡眠導入剤です。

抗うつ剤はざっくり言えばセロトニンを増やすもので、長期間服用してじわじわ効果が出るものです。抗うつ剤は効果がない場合もあるようですが、私はそれなりには効いたような気がします。

睡眠導入剤はまあ睡眠薬です。これはかなり効果があり、寝つきもよくなり朝まで眠れるようになりました。酷かった寝汗もほぼなくなりました。

心療内科や精神科は話を聞いてもらう場所といったイメージを持っている方もいるかもしれませんが、実際にはほぼほぼ症状に応じた薬が処方されるだけです。

### 原因
少し上で書いたように原因を特定するのは難しいですが、これなんじゃないかというものはいくつかあります。詳細については書けない部分が多いですが以下に挙げます。

- 業務系
    - 慢性的なシステム障害の対応
        - [ファントムバイブレーションシンドローム](https://ja.wikipedia.org/wiki/%E5%B9%BB%E6%83%B3%E6%8C%AF%E5%8B%95%E7%97%87%E5%80%99%E7%BE%A4)
    - 深夜待機
    - 業務上のプレッシャー
    - [燃え尽き症候群](https://ja.wikipedia.org/wiki/%E7%87%83%E3%81%88%E5%B0%BD%E3%81%8D%E7%97%87%E5%80%99%E7%BE%A4)
- 生活系
    - リモートワークによる運動不足
    - 睡眠の質の低下

私に関して言えば人間関係で困ったりしたことはなく、業務自体が嫌というわけでもありませんでした。また、見かけ上の残業時間もかなり少ない方でした。

一方で、残業時間では見えない負荷もあり、特に常にシステム障害の連絡が携帯に来るというのはかなり負担が大きかったんじゃないかなと思っています。

主治医の説明でも「医学的に疲れが溜まっている状態でしょう」という旨を言われていたので、疲労が溜まっていたことは間違いないです。

### 回復するまでにしたこと

#### ~ 1ヶ月
休職後１ヶ月はほぼ寝ていました。抗うつ剤は効くまでに少なくとも2週間から１ヶ月はかかるということもあり、死んだような生活をしていました。食欲も最初は全く無かったのですが、薬が朝食後だったのでゼリーだけ何とか食べるといった食生活をしていました。

#### 1 ~ 3ヶ月
2週間から１ヶ月すると多少は活動ができるようになりました。初めは1~2時間家事をしてまた寝るという過ごし方でしたが、だんだん体調が戻っていきました。最大MPが日に日に上がっていくような感覚でした。

この頃は活動が出来るようになってくるのもあって焦りが出てくる時期でした。いっそのこと転職してやろうとか思って色々やってはみましたが、予定を積むと目に見えて体調が悪化しました。そこで転職は止めてやっぱり回復に専念することにしました。

仕事もそうですが転職なんてものはかなりのエネルギーを使うもので、それが出来るほど回復はしていなかったということです。

体力もかなり落ちていたので、回復のためにネットでオススメされていた散歩等をしたりしていました。

また、多少なら遊んだりできる余裕は生まれたので、ゲームしたりもしていました。転職のようなプレッシャーはないのでマシではありましたが、結局集中力を使うので長時間するのは難しかったですが。

#### 3ヶ月 ~ 現在
ある程度日常生活は遅れるようになったので、この時期は仕事に戻ることを想定してリハビリ的なことをしました。

個人開発してみたいものは何個かあったのでそれを作ってみたりして、徐々に活動量を上げていきました。 このブログもその一つです。本題と逸れるので詳細は割愛しますが、Next.jsとReactとTailwindでゴリっと書いています。

また、体力をつけるためにラジオ体操とかリングフィットアドベンチャーをしていたり、集中力をつける的な意味合いもあってポーカー (ノーリミットテキサスホールデム) にハマりました。誰かやりましょう。

最初は長時間活動するのは難しかったですが、現在ではフルタイムの定時くらいまではなんとか作業できるようになりました。

## まとめ
うつ病で休職したことや自分のうつ病に対する理解について書いてみました。

うつ病に関する情報は色々なところにありますが、信用に足る情報なのかがいまいちわかりづらいです。

この記事も同様ではありますが、それでも誰かの役に立つことを願っています。

また、冒頭にも書きましたが、私には普通に接してください。特にうつ病関連がタブーであるということもないです。

よろしくお願いします。

WEBエンジニアがうつ病になった話

## 概要

技術書展13で公開されていた「Nuxt3 + Firebase 捨てられるWebアプリケーション設計」

https://techbookfest.org/product/m4KEUzinvmSZhPSaWYHetH?productVariantID=jC3wRJsbgwuJJQ05JtumXe

を読んだので、感想をまとめる。

以前こちらの記事を読んで著者に興味を持ったというのと

https://shiodaifuku.io/articles/17638219-f1ef-406c-b20c-7f426d61b2af

設計部分を読みたいという動機で購入しており、メインパートと思しきNuxt3およびFirebaseの部分は大胆に斜め読みしたので、意図と違う解釈をしているかもしれない。

## 第1部
### 第1章 SOLID
よく言われているSOLID原則についてまとめられていた。わかりやすくまとまっていたし、Vueとの関連も述べられていたので使いやすいかもしれない。

https://ja.wikipedia.org/wiki/SOLID

### 第2章 結合度と凝集度
こちらもよく言われている結合度と凝集度についてまとめられていた。同様にVue (特にComposition API) との関連も述べられていた。

https://ja.wikipedia.org/wiki/%E5%87%9D%E9%9B%86%E5%BA%A6

https://ja.wikipedia.org/wiki/%E7%B5%90%E5%90%88%E5%BA%A6

Vue3.0のComposition APIの威力についてはReact hooksと似たようなもんだろうくらいで深く気にしていなかったが、旨味についての理解が深まった気がする。 

私はVue2.0の経験があり、そのときは経験が浅いのもあってスパゲッティコードと化してしまっていた。Composition APIの影響で書きやすくなっているというのもあり、機会があれば使ってみたいと思った。

### 第3章 契約による設計: Design by Contract

契約プログラミングについてまとまっていた。

https://ja.wikipedia.org/wiki/%E5%A5%91%E7%B4%84%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

Nuxtのどこで契約を意識する必要があるのか等もまとまっており、後々おそらく実例もあるのだろう。

## 第2部, 第3部
コンポーネント分割の基準等についても書かれていたが、 VueおよびNuxt, Firebaseの割合が大きいので割愛。序盤の設計原則に従ってNuxtアプリを作成するという内容となっていたようである。

## まとめ
個人的には設計部分で既知の内容が多く得られる物が少なかった。 ただ、これは私が不純な目的で本書を購入したからで、Vue, Nuxt, Firebaseというスタックで何かを作りたい人には良い本だと思う。

また、技術書展の本は他にも1,2冊購入したがどれもレイアウトや構成が凄くちゃんとした本になっていて驚いた。私もそのうちなんか書いて出してみたいと思っていたがハードルが上がってしまった。

「Nuxt3 + Firebase 捨てられるWebアプリケーション設計」を読んだ

## 概要

「ソフトウェア見積もり 人月の暗黙知を解き明かす」

https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A6%8B%E7%A9%8D%E3%82%8A-%E4%BA%BA%E6%9C%88%E3%81%AE%E6%9A%97%E9%BB%99%E7%9F%A5%E3%82%92%E8%A7%A3%E3%81%8D%E6%98%8E%E3%81%8B%E3%81%99-%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%96-%E3%83%9E%E3%82%B3%E3%83%8D%E3%83%AB-ebook/dp/B00KR96M6K

を半分程度読んだのでノウハウについて章ごとにメモする。

残り半分を読んだ段階で記事を更新する予定。

## 第1部 見積もりの考え方
### 第1章 見積もりとは

- 「見積もり」「ターゲット」「コミットメント」の違いを意識する
  - 見積もり：そのままの意味
    - 「この機能の実装は何人日」
  - ターゲット：実現したいビジネス上の目標
    - 「何日までにこの機能を提供したい」
  - コミットメント：機能を一定のレベルで期日までに納品するという約束
    - 「何日までにこの機能を提供します」
- 見積もりと計画の違いを意識する
  - 見積もりは正確性が重要
  - 計画は結果が重要
  - 偉い人にターゲットを達成するための計画を聞かれているのに見積もりを単に答えてはいけない
    - 「このプロジェクトは何人月？期限は３ヶ月なんだ」
    - 「見積もってみたところ５ヶ月かかります」
    - 「ふざけるな！」
  - 開発と期日どちらが優先かどうか尋ねる
- 良い見積もりとは偉い人の意思決定に寄与する見積もりのこと

### 第2章 見積もり能力のチェック

- 直感で「90％確か」な見積もりは、実際には「30%確か」
  - なので直感で90%とか言ってはいけない
- 見積もりなんて幅があって当然。無理に狭めようとしない

### 第3章 正確な見積もりの価値

- 意図的に過小に見積もることはすべきではない
  - 過大見積もりよりも深刻な被害が起きる
  - では過大にすれば良いかというとそうでもなく、それなりに大きくしてあとは計画とコントロールで対処せよ

### 第4章 見積もり誤差はなぜ起きる？

- 見積もり期間を増やしても見積もりの不確実性は上がらない
  - プロジェクト自体があやふやなのではどんなに頑張っても上がらない
  - 見積もり期間を増やすのではなく、要件定義や設計を固めることでしか上がらない
- 休暇、病欠、トレーニング、ミーティング等は必ず発生する。そのためのゆとりをもたせる
- 開発者の見積もりはすでに必ず楽観的であるので削ってはいけない
- 見積もりに「コントロールノブ」を持たせてはいけない
  - コントロールノブとは見積もりに入れる主観的判断のこと
  - 見積もりの客観性と共に正確性も落ちる
- 即興の見積もりはしない
  - たった15分の見積もりでさえもっと正確になる

## 第2部 見積もりの技法の基礎

### 第7章 数えて、計算して、判断する

- できるときはまず何かを数える
- 数えられない場合にのみ計算する
- 計算すらしないのは最終手段

### 第9章 専門家の判断

- タスクで分解して見積もるときは長くても2日程度の粒度にする


## 感想

「技術者の見積もりは常に楽観的」というのはその通りだと思った。
幅がある見積もりの中で最小の部分を提出する傾向があるような気がしているし、
実際過小に見積もる圧力があるということも書かれていた。

一方で、数えるだけの方がよほど正確に見積もれるというのは不思議だった。さすがにコード行数で数えるのはどうかと思うが。

過去の開発にかかった工数と関連データの保存および可視化が出来ていないと不可能な手法ではあるので、これらの重要性はかなり高い。

生産性向上とか言っておいて生産性を測る指標を可視化していないなんてことがザラにある状態では正確な見積もりなんて望めないということかもしれない。

「ソフトウェア見積もり」を読んだ

## 概要

オライリーから出ている 「Googleのソフトウェアエンジニアリング」

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

を読んだので以下のような内容について章ごとにメモする。

- 主張されている内容の概要、
- そこから得られたノウハウ、
- その他の感想。

なお、全て個人的な解釈に則って記事を書いており、ノウハウ抽出に不要な部分は大胆にカットしているので、本の内容の詳細は実際に読んで把握することをお勧めします。

## 個人的に印象に残った章

- 2章
- 7章
- 12章

## 第1部 主題

### 1章 ソフトウェアエンジニアリングとは何か

#### 概要

プログラミングとはコードを生産する行為、ソフトウェアエンジニアリングとはそのコードを保守することまでを含んだ時間的な広がりを持つ行為。

対象が違うのだから、プログラミングとソフトウェアエンジニアリングに同じベストプラクティスが通用すると一般に仮定するのは無理。

#### ノウハウ

以下の**Hyrumの法則**というものが紹介されている。

> あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様として何を約束しているかは重要ではない。
> 作られたシステムが持つあらゆる観察可能な挙動に関して、それに依存するユーザーが出てくるものである。

したがって、API仕様書に書かれていない変更をする際にも、ユーザーへの聞き取り調査の工数は含めておくのが望ましい。

#### 感想

他にも、スケールする仕組みをつくろう、手戻りを無くすよう早期に問題を発見しよう、とかそんなことが書かれていた。

## 第2部 文化

### 2章 チームでうまく仕事をするには

#### 概要

チームで仕事をするには謙虚と信頼が大事だ、等の一般的によく言われることが書かれていた。

#### ノウハウ

以下の標語が紹介されている。
> 早期に失敗し、高速に失敗し、頻繁に失敗せよ

これを実践するために、一人で黙々と作業するのは止める。誰かに頻繁にフィードバックを求める。

#### 感想

「バス係数」の概念も紹介されている。これは何人のメンバーがバスで轢かれたらプロジェクトが失敗するかという指標。

バス係数が低いと、真面目な人ほど他の人に迷惑がかかるからという理由で休みづらくなる気がする。
それで無理矢理プロジェクトを回すのは絶対によろしくないので、迷惑を顧みないほどの豪胆さが欲しい。
自分は休めるし、プロジェクトが回らなければ上にも人手の必要性が伝わるしで一石二鳥である (実行可能なノウハウかどうかは諸説あるので感想部分に書いた)。

### 3章 知識共有

#### 概要

心理的安全性は大事だとか、知識共有を率先してやることに報酬制度を設けよとかの一般論と、Google内でのレビューフローの事例等が書かれていた。

#### ノウハウ

特になし。

#### 感想

Googleの事例自体は参考になるが、銀の弾丸は無いとも書かれており、結局は自分の組織に合った方法論を構築する必要がある。
そういった意味ですぐに実行可能なノウハウは無かった。

### 4章 公正のためのエンジニアリング

#### 概要

バイアスは常にある、多様性が大事、といったことが書かれていた。
GoogleのAIが黒人とゴリラを間違えて問題になった件とか、その類の話。

#### ノウハウ

特になし

#### 感想

それはそう。くらいの感想だった。

### 5章 チームリーダー入門

#### 概要

リーダーとしてどんなことをするべきかが書かれていた。

#### ノウハウ

章自体がノウハウ集となっているので多すぎて書ききれない。
最も重要だと感じたのは「サーバントリーダーシップ」というキーワードで、可能な限りチームメンバーに仕事を移譲し、
自身はチームメンバーが円滑に仕事をすることができるように仕える、というもの。

#### 感想

リーダーになる機会がもしあれば読み直したいが、社内政治が混沌としていたりするとそう上手くは行かないんだろうなと感じた。

### 6章 スケールするリーダー

#### 概要

**スケールする**リーダー (リーダーのリーダー等) としてどんなことをするべきかが書かれていた。

#### ノウハウ

これも章自体がノウハウ集となっているので多すぎて書ききれない。
最も重要だと感じたのは「いつでも立ち去れ」という標語。結局リーダーがボトルネックになったら意味ないよねということで、
自分が立ち去っても問題なく動くチームにするべきで、具体例として1週間以上休暇を取っても問題なく機能するか等が挙げられていた。

#### 感想

5章と同じ。

### 7章 エンジニアリング生産性の計測

#### 概要

生産性を計測する際の注意点が書かれていた。

#### ノウハウ

ゴール、シグナル、メトリクスを明確に区別する (GSMフレームワーク)。

- ゴール: 達成するべき目標。
- シグナル: ゴールを達成したことを知る手段。必ずしも計測可能である必要はない。
- メトリクス: シグナルの計測可能な代替品。

メトリクスを計測する前に、それを計測した後どう行動するのかを考えるべき。

生産性のゴールにはトレードオフがあるため、一部だけを計測するのはよくない。
QuANTSのゴールを全て計測することで、網羅的に計測ができる。

| 頭文字 | 英語                           | 日本語      |
|-----|------------------------------|----------|
| Qu  | **Qu**ality of the code      | コード品質    |
| A   | **A**ttention from engineers | エンジニアの注意 |
| N   | I**n**tellectual complexity  | 知的複雑性    |
| T   | **T**empo and velocity       | テンポと速度   |
| S   | **S**atisfaction             | 満足       |

#### 感想

生産性向上はよくある組織目標だと思うが、ちゃんと考えたことは無かった。
特にGSMの区別はちゃんとしてみたい。

## 第3部 プロセス

### 8章 スタイルガイドとルール

#### 概要

コーディングスタイルガイドやコードフォーマッター大事だよねくらいのことが書かれていた。

#### ノウハウ

特になし。

#### 感想

そこまで新しい知見はなかったので感想も簡素。

### 9章 コードレビュー

#### 概要

コードレビューにおける恩恵や、Googleでの実施方法などが書かれていた。

#### ノウハウ

特になし。

#### 感想

よくあるプルリクエストのベストプラクティス (変更は小さくしろ、レビュアーのことを考えろ、できることは自動化しろ等) とほぼ変わらない印象だった。

### 10章 ドキュメンテーション

#### 概要

ドキュメントがいかに大事かということ、ドキュメントの管理について、Googleでの実例等について書かれていた。

#### ノウハウ

ドキュメントにはオーナーを付ける。
オーナーがドキュメントの変更をレビューして反映たり、最新化する責任を持つ。

ドキュメントはVCSで管理し、ソースコードと同じ管理方法にする。

#### 感想

Googleでもドキュメントについては改善途中であるらしい。ドキュメントが乱立して陳腐化するのはどこでもよくあることで、それを避けるためにオーナーを付けるのは必須だと感じた。

### 11章 テスト概観

#### 概要

テストは大事だくらいのことが書かれていた。

Googleでのテストは「単体」や「結合」等の文脈では区別されず、テスト規模のみにより大中小に分類されるとのこと。

| テスト規模 | 主な制約 | その他 |
|--|------------------------------|----------|
| 小 | 単一プロセス | sleep禁止、I/O操作禁止、ブロッキング禁止 |
| 中 | 単一マシン (複数プロセス) | localhost意外へのアクセスが禁止 |
| 大 | 複数マシン | 実質制約なし |

#### ノウハウ

破綻してほしくないものは全部テストすべき。
ビヨンセルールと呼ばれる標語に従っておく。

> 「そんなに好きならそいつにテスト付けときゃよかったのに」

#### 感想

概観というだけあってノウハウ的なところは薄かった。

### 12章 ユニットテスト

#### 概要

ユニットテストの範囲、保守性について、書き方についてが書かれていた。

脆いなテスト (無関係な要因でたびたび失敗してしまうテスト) を避けることや、テストにロジックを入れない等の一般的なことが多かった。

#### ノウハウ

脆いテストを避けるために変化しないテストを目指す必要がある。
そのためには*公開API経由で*テストすることが重要である。
公開APIの定義とは、以下の通りである。

> 我々が文章の文脈で「公開API」と述べる場合に実際に言及している対象とは、
> ユニットコードのオーナーであるチームの外部にいるサードパーティに対し、そのユニットが公開しているAPIだ。

これに従えば、WEBのAPIをチーム外に公開している場合、そのAPI内部の実装をメソッド単位でテストする*べきではない*。
そのようなテストは外部との契約に関係がないリファクタリング等で失敗するようになる。つまりは脆いテストである。

#### 感想

メソッド単位でテストするなというのは衝撃があったが、納得感もあった。

これに関しては別記事にしたいと思っている。

### 13章 テストダブル

#### 概要

テストダブルとはテスト時に使われるモックやスタブのこと。

テストダブルの種類や利用法についてまとまっていた。

#### ノウハウ

テストではなるべくテストダブルは使わず、本物の実装を使う方が良い。
テストの実行時間高速化等のメリットと、テストダブルを使用した際のリスク等のデメリットをトレードオフし、適切な場合にのみテストダブルを利用するべきである。

#### 感想

メソッドやクラス単位でテストしようとするとどうしても依存が複雑な場合はモックだらけになってしまう気がする。
前章に従ってメソッド単位でテストせず公開API経由でテストする場合には有効なノウハウに感じた。

### 14章 大規模テスト

#### 概要

大規模テストを実施する場合の考え方について書かれている。

#### ノウハウ

> 優れた設計には、リスクならびにそのリスクの軽減のための大規模テストを見極めるテスト戦略が含まれている。

つまり、設計の時点で起こりうるリスクを考え、それに対する大規模テストについて考えを巡らせておくべきである。

#### 感想

大規模なテストは辛いことが多いが、それでもメリットと天秤に掛けるべきだよねという当たり前なことに気付かされた。

大規模テストを作成する際にもう一度読み返したい。

### 15章 廃止

#### 概要

ソフトウェアの廃止は構築よりも難しいことが多いが、それでも保守コストと天秤に掛けて実施すべきということと、
その際に注意すると良いことについて書かれていた。

#### ノウハウ

特になし。

#### 感想

廃止についてはGoogleだからといって特別良いノウハウがあるわけではなく、結局難しいままなんだなと感じた。

## 第4部 ツール

### 16章 バージョンコントロールとブランチ管理

#### 概要

バージョンコントロールの概説、ブランチ管理のバッドノウハウ (長寿命のdevブランチはNG) 、リポジトリ間の依存関係について書かれていた

#### ノウハウ

特になし。

#### 感想

Googleのモノレポについて少し書かれていたが、なかなか真似しづらいので、もしモノレポ環境になったら読み直そうと思った。

### 17章 Code Search

#### 概要

Googleのコード閲覧、検索のための社内ツールであるCode Searchについて書かれている。

#### ノウハウ

特になし。

#### 感想

社内ツールについては得られる物が少なそうだったので斜め読みした。

### 18章 ビルドシステムとビルド哲学

#### 概要

ビルドシステムの一般的な事柄について書かれていた。

#### ノウハウ

特になし。

#### 感想

一般人はよくあるビルドツールでビルドすることになると思うのでここも読み飛ばした。
ビルドツールを作る側になったら読み直したいと思う。

### 19章 GoogleのコードレビューツールCritique

#### 概要

Googleのコードレビューツールのための社内ツールであるCritiqueについて書かれていた。

#### ノウハウ

特になし。

#### 感想

ここも社内ツールの話なため読み飛ばした。

### 20章 静的解析

#### 概要

静的解析の概説とGoogleの社内ツールであるTricorderについて書かれていた。

#### ノウハウ

特になし。

#### 感想

ここも社内ツールのため省略した。
静的解析も既製品を使うことがほとんどだと思うので、作る側になったら読み直したい。

### 21章 依存関係管理

#### 概要

依存関係をいかにして管理するか、およびセマンティックバージョニングについて書かれていた。

#### ノウハウ

特になし。

#### 感想

これも依存関係管理ツールを作る側になったら読み直したいと思った。
セマンティックバージョニングの限界や最小バージョン更新戦略というものを使うと良いということも紹介されていたが、そこまで役に立つものでもなかったので感想欄に。

### 22章 大規模変更

#### 概要

Google全社で実施されるような大規模変更について書かれていた。

#### ノウハウ

特になし。

#### 感想

Google規模で大規模一斉変更を指揮するような機会は一生来ない可能性の方が高いので斜め読みした。

### 23章 継続的インテグレーション

#### 概要

CIについて、テスト実施のタイミング、GoogleにおけるCIについて書かれていた。

#### ノウハウ

マージ前に実施するべきテストとマージ後に実施するべきテストがある。

開発の高速化のために、マージ前は信頼性が高く高速なテストのみを実施し、マージ後は中大規模テストのような時間がかかり多少不安定でも許容されるテストを実施するべきである。

#### 感想

ノウハウには入れていないが以下のような文言があった。

> CIはアラートである。

アラートはSLOが健全であることを担保し、CIはビルドが健全であることを担保する。
この対比は新しく、まだ模索中のようだが、一理あるなという気はした。

### 24章 継続的デリバリー

#### 概要

CDやリリースに関するベストプラクティスが書かれていた。

#### ノウハウ

> 問題を早期に切り分けられるように、あらゆる機能をフラグで保護すべきだ。

> 各リリースのリスクを低減しつつ、市場に投入するまでの時間を最小化するために、早期かつ頻繁に小さなバッチでリリースすべきだ。

#### 感想

機能フラグに関してはサービス全体の観点では同意するが、分業しているとなかなか難しいような気もした。

一方でリリースを早期に小さなバッチで行う方がより安全であるというのは同意できる。

### 25章 サービスとしてのコンピュート

#### 概要

PaaSやCaaS、サーバーレス等のコンピュートリソースについて書かれていた。

#### ノウハウ

特になし。

#### 感想

組織のコンピュートリソースを選択するような立場に無いので流し読みしたが、特に目新しいことは書かれていなかったように思う。

## まとめ

Googleは世界トップの企業で、その内部について良くまとまっていました。

興味がある人は是非本を読んでみてください。

時期	所属	経験
2017/05 - 2017/12	スマートアプリ株式会社 (インターン)	Laravel, iOS
2018/01 - 2019/03	ヴァンテージIT株式会社 (インターン)	Firebase, Vue, Ansible
2019/04 - Now	LINEヤフー株式会社	Spring Boot, RDB, NoSQL, DevOps, SRE

スキル	経験度	説明
Java	⭐︎⭐︎⭐︎⭐︎⭐︎︎︎	実務で主に使用しています。
Spring Boot	⭐︎⭐︎⭐︎⭐︎⭐︎︎︎	実務で主に使用しています。
SRE	⭐︎⭐︎⭐︎⭐︎	インフラではなく原義的なSREの知見があります。
DevOps	⭐︎⭐︎⭐︎⭐︎	CI/CDを整えるなど。
Kubernetes	⭐︎⭐︎⭐︎⭐︎	実務経験があります。
Cassandra	⭐︎⭐︎⭐︎⭐︎	実務経験があります。
Redis	⭐︎⭐︎⭐︎⭐︎	実務経験があります。
MySQL	⭐︎⭐︎⭐︎⭐︎	実務経験があります。
Cassandra	⭐︎⭐︎⭐︎⭐︎	実務経験があります。
Google Cloud	⭐︎⭐︎⭐︎	Professional Cloud Developerの資格を取得しています。
Next.js	⭐︎⭐︎⭐︎	SSGを中心にですがReact関連などを基本として実装可能です。
Remix	⭐︎⭐︎	実装可能です。

プロダクト	説明	要素技術
miketako.xyz	このサイト	Next.js、Cloudflare Pages、Tailwind CSS、TypeScript、Github Actions
Code.385 Miyako	AI Tuber	ChatGPT、LangChain、VITS、FastAPI、Docker、Google Cloud
Niche Love	SNS	Remix、Cloudflare D1、Workers、R2、Grafana Cloud
Blue Biscuit	メンタルケア iOSアプリ	Swift UI、Xcode Cloud