読了。概ね「おっそうだな」という無難なことが書き連ねられているので、自分の仕事効率化したい人は読んで損はないと思う。習慣化の話とか「それができたら苦労はせんわ」って感じなので、まず自分の意識を変えなければならない。この手の本には必ず書いてあるけど、大体の人はそれができんから別の方法求めて本買うのよね。完全に術中にかかっている。やらなければはじまらない（ねこます名言集より

読み終わったけど最後まで退屈。なんか求めてたやつと全然違った。
『メルカリ 希代のスタートアップ、野心と焦りと挑戦の5年間』と同じような読後感。おじさんは現場の生の声が聞きたいのよ。
https://unsolublesugar.com/20181125/175657/

半分くらい読んだ。
組織における離職の負の連鎖とかの話も出てくるので、個人の問題だけでなく人事や経営などの立場の人が読むべき本っぽい。辞める理由も個人毎にあるわけで、辞めること自体をすべて悪として認識してはいけない。

• 積極的離職：「働きがい」が低下、やりがいを求めてステップアップ系。評価基準の変更や昇給が頭打ちになるなど
• 消極的離職：「働きやすさ」の低下が原因。もうこの会社で働きたくないなど「現状からの回避」としての離職
• 離脱：「心身コンディション」の悪化によるメンタルダウンや身体疾患で、休職や退職せざるを得なくなる状況

もちろん対応も異なるので、適切な対処を検討していく必要がある。

マイナス感情の発生対象は大きく3要素に分けられる

1. 心身コンディション
2. 働きやすさ
3. 働きがい

これらのバランスが崩れると離職やメンタルダウン、やる気の低下などの問題が起きる。周囲のマイナス感情にも影響を及ぼし、個人から組織へと伝染していく。

メンタルヘルス対策は順番が重要

1. メンタル不調者対応
2. メンタル不調者早期発見/早期対応
3. メンタル不調者発生予防

読了。良書。

届いたので読み始めた

読了。微妙、、、

Chapter4で突然アジャイルとスクラムの話になる。

サンプルアプリ見て既存機能の把握と課題を探り、既存仕様に変更を加えることなく利用技術変更して、より開発しやすい環境・実装を実現していくという、わりとカジュアルにレベルの高いハンズオンをいきなりブチ込んで来る。

ひたすらパッケージインストール。何のためにそのパッケージを入れる必要があるか等の説明もなく、フロントエンド初心者向けとは思えない。

Chapter7はCI/CDの話。
Chapter8は解析とモニタリング。
Chapter9、チーム開発とWebへの貢献。またスクラムの話出てきて、OSSやWeb仕様策定の話を紹介して終わり。

「フロントエンド開発入門」と言いつつ、開発全般の話に触れている本。

内容としては悪くないのだが…おそらくこの本のタイトル見て買おうと思う人たちは、Web画面作成のことを知りたくて手に取るものと思われる。

そういう意味では若干タイトル詐欺感ある。

iPodから始まったAppleのコンシューマー向け製品を体現する「i」のネーミングマジパネェ。
DELLとかの製品ラインナップのネーミングとの比較は納得せざるを得ない

面白いけどずっと広告屋さんのジョブズ思い出話なので、人によっては退屈かも。
年内の通勤時間には読み終わりそう。

読み終わった。まぁまぁ。
Appleというかジョブズの「シンプルの哲学」を知るには良い本だと思う。
最後の方でインテル、IBM、HP、マイクロソフト関連のエピソードも出てくるので、そのあたりの歴史把握するのにも役立つ。それぞれのボリューム薄いのでほんとに触りだけだけど。

読了。良本。

読了。微妙だった。

オンラインでのコミュニケーション

電子メールやソーシャルメディアへの投稿、ブログなどの文書コミュニケーションに関するtips

• [送信] ボタンを押す前に精読する
• スペルチェッカーにかけ、自動修正機能でおかしな修正がないかチェックする
• フォーマットは簡潔で明確なものに
• 引用は最小限に。100行もの自身のメールを引用され「賛成です」と1行添えられて喜ぶ人は居ない
• 人を非難したり煽ったりするのは後々自分に返ってくるのでやめよう。面と向かって言わないようなことをオンラインで表現してはいけない
• 送信前に宛先一覧を確認。電子メールで上司の悪口を書かないようにする

よい設計の本質

• よい設計は悪い設計よりも変更しやすい
• ETC原則「Easier To Change」（変更しやすくする）
• ETCはルールではなく価値である
• ETC原則に従ったコードを記述する上で、ポジティブな面が大きいか、ネガティブな面が大きいか、その双方かを考える
• ポジティブな面を強調し、ネガティブな面をなくすにはどういった手が打てるか？

DRY原則はコード以外にも適用される

• DRY原則「Don't Repeat Yourself（繰り返しを避けること）」はメンテナンスを容易にする唯一の方法
• コードの一部を変更する際に複数の場所を変更しようとしている？複数の異なるフォーマットを変更している？コードとドキュメント、データベースのスキーマを保持する構造を変更しなければならない？
• 再利用しやすいようにしておく

直行性

• 「直行性」とは独立性、結合性の低さを表す
• 関係のない者同士の影響を排除すること
• 直行性の高いシステムを構築すれば「生産性の向上」と「リスクの低減」という2つの大きなメリットを享受できる
• 直行性を考慮したアプローチによって再利用も促進される
• コードの密結合を最小化する、グローバル変数を避ける、類似機能を避ける
• 直行性はドキュメントにも適用できる

読了。言うまでもなく超良書。
手元において何度でも読み返したいやつ。これ系は物理本が最適。

読んだ。SDGsの概要知るには良い本。ただし概要と簡単な事例紹介がメインなので、各事項の詳細を追いたければ別資料を漁るべき。これ一冊読めばすぐ取り組めるというものではないのであしからず。