
## 概要

「SOFT SKILLS ソフトウェア開発者の人生マニュアル」

https://www.amazon.co.jp/SOFT-SKILLS-E3-82-BD-E3-83-95-E3-83-88-E3-82-A6-E3-82-A7-E3-82-A2-E9-96-8B-E7-99-BA-E8-80-85-E3-81/dp/4296000500/

という自己啓発本を読んだので、感想とノウハウをメモする。

## ノウハウ

- エンジニアもセルフプロデュースをせよ。
- セルフプロデュースに最も良いのはブログである。ブログをやれ。
- 給与は全て投資し、帰ってくるお金のみで生活せよ。そうすれば投資が終わった時にはリタイアできる。

## 感想
YouTubeやブログで著名になり不動産投資でも成功したソフトウェアエンジニアである著者の体験が元になった本。

正直あまり参考になる部分はなかった。セルフプロデュースが重要なのは初めからわかっていたし、それ以外についてもよくある自己啓発本の域を出ない。

例えば「お金に働かせてFIREしよう」といった内容で不動産投資を勧めている章もあった。ソフトウェア開発者に向けた本としては珍しいトピックだし間違ってはないのかもしれないが、そんなことを言われても行動に移せるノウハウとしてはほぼ無いに等しかった。

この本で得られたのはセルフプロデュースが重要ということのセカンドオピニオンを得たことくらいである。


「SOFT SKILLS ソフトウェア開発者の人生マニュアル」を読んだ


## 概要

技術書展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アプリケーション設計」を読んだ


## はじめに
私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エンジニアがうつ病になった話


## 概要

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

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日程度の粒度にする


## 感想

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

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

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

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


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

Spring BootのbootBuildImageでベースのイメージを差し替える


## 概要

有名な自己啓発本である 「イシューからはじめよ」

http://www.eijipress.co.jp/book/book.php?epcode=2085

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

- 得られたノウハウ、
- その他の感想。

## はじめに 優れた知的生産に共通すること
### ノウハウ

- 「悩まずに考える」 
  - 「悩む」とは、答えが**出ない**という前提 
  - 「考える」とは、答えが**出る**という前提

### 感想
仕事では答えが出ない問題は必要ないよねということでバッサリ切り捨てているが、これについてはかなり共感した。

オタクなので水槽の脳とかシミュレーション仮説とかが好きだが、こういうのも結局答えが出ないのでロマンを語る場面以外は考えるだけ無駄だよねという感覚でいる。それと似たようなことだと思った。

## 序章 この本の考え方
### ノウハウ

- 「仕事のバリューは、解の質とイシュー度で決まる」
- 「犬の道を避ける」
  - 「犬の道」とは、解の質を一心不乱に上げることでイシュー度を確保するアプローチのこと
  - まずイシュー度を高め、その上で解の質を高める方が時間効率が良い

### 感想
「斬新で革新的なものには名前をつけろ」という話が後々出てきたが、犬の道と名前をつけたのは確かに良かったんじゃないかなと思った。

言ってることは結局無駄な仕事を避けろということだが、そのためにはイシュー度を上げることが大事というのがこの本の本質だろう。
なので、第１章の内容は重要だが他の章は重要度が低い。

## 第１章　イシュードリブン
### ノウハウ
- 「スタンスを取れ」
  - 強引にでも具体的な仮説 (イシュー) を立てる
    - イシューに答えを出すため
    - 必要な情報が何か把握するため
    - 結果の解釈を明確にするため
  - とにかく言語化する
    - 言語化できない状態で明瞭な思考を行うことは難しい
- 「良いイシューとは以下の３条件を満たすもの」
  - 本質的である
  - 深い仮説がある
  - 答えを出せる
- 「一次情報を漁る」
- 「情報を集めすぎない」 
  - 集めすぎることで自分独自の視点が消える
- イシューを見つからない時は以下を行う
  - 変数を削る
  - 視覚化する
  - 最終系から辿る
  - so what?を繰り返す
  - 極端な事例を考える

### 感想
イシューを言語化すること、イシュー度が高いかどうかを定期的に見直すことが重要だと感じた。

「情報を集めすぎない」についてはエンジニア的には半分程度しか納得できなかった。確かに限界効用的に情報を集めすぎてもコスパが悪いというのはその通りだが、
独自の視点よりも車輪の再発明をしないことや仕様を見落とさないことの方が大事なのではないか？

## 第２章 仮説ドリブン①
### ノウハウ

- 「イシュー分析で解の質を高める」
  - ストーリーライン
  - 絵コンテ
- 「イシューをサブイシューに分解する」
- 「ストーリーラインを組み立てる」
  - ピラミッド構造の2つの型
    - whyの並び立て
    - 空・雨・傘

### 感想

エンジニア的には分割統治法になじみがあるのでサブイシュー云々に新鮮さはなかった。

ストーリーラインの2つの型についてはプレゼン時に使えそうなので覚えておきたい。

## 第３章 仮説ドリブン②
### ノウハウ

- 「ストーリーを絵コンテにする」
  - 絵コンテとは最終的なグラフや図表のイメージ
- 「分析とは比較すること」 
  - 定量比較の3つの型
    - 比較
    - 構成
    - 変化
- 「原因と結果から分析軸を考える」
- 「数字が入ったイメージを作る」
- 「意味合いを表現する」
  - 意味合いの本質
    - 差がある
    - 変化がある
    - パターンがある
- 「データの取得方法を明示する」

### 感想

これらもプレゼンの型として考えれば使えそうだった。
要するにプレゼン資料作りを想定して行動しろということで、いかにもコンサル出身らしい発想だなと感じた。

一方で、仕事では結局は誰かに話したり資料に残したりする必要はあるので、こういう意識は大事かもしれない。

## 第４章 アウトプットドリブン
### ノウハウ

- 「前提と洞察から取り組む」
  - ストーリーラインの中で絶対に崩れてはならない部分を潰しておく
- 「完成度を上げるよりも複数回取り組む」

### 感想

特に崩れて欲しくない実装には自動テストが欲しいよねというのと同じような感覚だった。

また、ある程度の完成度で誰かに見てもらいフィードバックをもらうというのもよく言われていることなので新鮮味は無かった。

## 第５章 メッセージドリブン
### ノウハウ

- 「ストーリーラインを磨き込む」
  - そのための3つのプロセス
    - 論理構造を確認する
    - 流れを磨く
    - エレベーターテストに備える
      - 偉い人とエレベーターで一緒になった時に説明できるか？
- 「チャートを磨き込む」
  - 優れたチャートの条件
    - イシューに沿ったメッセージがある
    - 軸の広がりに意味がある
    - 図表がメッセージを支えている

### 感想

このあたりもコンサル的だなと感じた。 プレゼン技術としては有用そう。

## まとめ

「イシューからはじめよ」のノウハウと感想をまとめた。

名著とされているイメージだったが内容が薄いように感じた。というか学者的なアプローチを期待していたらコンサル的なアプローチだったのでガッカリしたというような感想だった。

一方で、本文でも以下のように書かれている。

> 「僕は今、自分にできる限りの深いレベルまで、知的生産におけるシンプルな本質を伝えた。あとは、あなたが自分で経験する以外の方法はないはずだ」
> (中略)
> 「経験しないとわからない」と書くと「じゃあ、この本は何のためにあるのか？」と言われそうだが、
> この国では論理思考や問題解決において、新しいツールの紹介のようなものばかりが行われ、本質的な知的生産についての議論が足りないように思う。
> この本が共通の議論のベースと実践の手がかりとなればと願っている。

ということで、起こせる行動の変化としてはノウハウを意識に入れつつ自分で試行錯誤してみるくらいだろうし、それを目指しているようにも読めた。

時間が経ってこの本の内容を思い返した時に印象が変わるといいなという期待と共にレビューを終える。


「イシューからはじめよ」を読んだ


## 概要

オライリーから出ている 「レガシーコードからの脱却」

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

を読んだので、重要な章を抜き出してノウハウをメモする。

## 第1部
### 1章 何かが間違っている

ほとんどのソフトウェアは作り方や保守の仕方を間違えている。

ウォーターフォールは最後にまとめてリリースするため一か八かの博打。

### 3章 賢人による新しいアイデア

アジャイルはウォーターフォールよりは良い。

一方で、アジャイルをしているチームも技術プラクティスを上手く使えていないために期待した利益が得られないでいる。

## 第2部
### 4章 9つのプラクティス

1. やり方より先に目的、理由、誰のためかを伝える
2. 小さなバッチで作る
3. 継続的に統合する
4. 協力し合う
5. 「CLEAN」コードを作る
6. まずテストを書く
7. テストでふるまいを明示する
8. 設計は最後に行う
9. レガシーコードをリファクタリングする

### 9章 プラクティス5 「CLEAN」コードを作る
うまくカプセル化されたソフトウェアはアウトサイドインで設計することによって得られる。

- アウトサイドインプログラミング
  - コンシューマの観点で機能を設計する
  - サービスが何をやっているかを示す名前をつける
  - どう動くかは隠す
- インサイドアウトプログラミング
  - 問題を小さな塊に分解し、それらを縫い合わせる
  - 最初に実装してしまうと全体が見えなくなる

「知らぬが仏」という言葉はソフトウェアにおいては常に真である。

CLEANなコードを作る。

- C: Cohesive (凝集性)
- L: Loosely coupled (疎結合)
- E: Encapsulated (カプセル化)
- A: Assertive (断定的)
- N: Nonredundant (非冗長)

名前は説明的、能動的、肯定的なものにし、結果的にシステムがどう変化するのかを反映する。

### 10章 プラクティス6 まずテストを書く

多くのテストを書きすぎたり、実装依存のテストを書いたりするとTDDは上手く行かない。

ふるまいを表すのに必要なテストだけを書く。

「ユニットテスト」のユニットとはふるまいの単位であり、メソッド、クラス、モジュール等ではない。

### 12章 プラクティス8 設計は最後に行う

最初のアーキテクチャレベルの設計というよりはコードの詳細設計的な話。

テストを書いた後にリファクタリングで設計を変えていく方が良い。

### 13章 プラクティス9 レガシーコードをリファクタリングする

コードを変更する場合は一緒にレガシーコードをリファクタリングする。

## 感想
プラクティスの大半はテストが必要というのもあって、上手いテストを書くことが非常に重要だと感じた。

Google本でも書かれていたが、やはりユニットテストだからといってメソッド単位でテストしたり、ホワイトボックステストを書くのは良くない。

最後に設計せよというプラクティスがあったが、そのためにはホワイトボックステストがあってはならないはずである。

この辺りの考えに対する後押しが得られたのが良かった。


「レガシーコードからの脱却」を読んだ


## 概要

「最高の脳で働く方法」

https://d21.co.jp/book/detail/978-4-7993-2470-7

という自己啓発本を読んだので、感想とノウハウをメモする。

## ノウハウ
- 演出家を育てる
  - 演出家とは、自分の脳内のタスクを管理するもう一人の自分のようなイメージ
  - そのためには自分のメンタルプロセスを自覚する力を高める必要がある
  - マインドフルネス的にこの瞬間に意識をじっと集中させることがトレーニングになる
- 自分の演出家を働かせる
  - 集中する必要があるときは他の物事を極力排除する
    - 携帯の電源を切る等
  - ひらめきが必要な場合は全てを舞台から排除し、脳の微弱な波長を感じられるようにする
  - 脳の情動は接近と回避の2種類がある
    - 接近は良い状態
    - 回避は悪い状態だが、野生本能的にこちらになりやすい
  - ストレスを感じている時は回避になるため演出家を働かせることは難しい
    - そのような状況では以下を行うと良い
      - ラベリング（端的な言葉への言い換え）
      - 再評価（プラス思考で考え直す）
  - 他者とうまく協調するためには他者に接近状態にさせると良い
    - 問題ではなく解決にフォーカスする
    - よくやられているフィードバックは効果が薄い
      - ステータスが上の人間にフィードバックをもらうというだけで脅威に感じる
    - 相手のメンタルプロセスに対して質問することで相手から閃きを引き出す

## 感想
脳のリソースを舞台と演出家というメタファーで伝えている本。

舞台とは脳のメモリを指し、舞台上の役者は脳が注意を向ける事柄を表す。

どの役者をどのように配置するかを管理するのが演出家で、演出家に素晴らしい働きをさせることが全てにおいて重要なことであるという主張がされている。

著者がコンサル出身らしくコンサル仕事術的な面があり、求めていた科学的アプローチとは違った。

一方で言わんとすることはわかるし、演出家というメタファーでイメージしやすくなっているのは良かった。


「最高の脳で働く方法」を読んだ

単体テストはただの負債だから今すぐ書くのをやめるべき (かもしれない)

「Googleのソフトウェアエンジニアリング」を読んだ


## 概要

オライリーから出ている 「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は世界トップの企業で、その内部について良くまとまっていました。

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