LINEとかってこうやって実装されているんだ！こういうアルゴリズムあるんだ！とわくわくするような本でした。
システムの勉強するぞ！と意気込んで読むのではなくて、小説のような趣味枠として読めた本です。
翻訳本とは思えないほど読みやすいのもおすすめポイントです。
超序盤はどうして冗長化するの？ロードバランサって何しているの？など経験の浅いSEさんに、インフラはどうしてこういう構成にしているのかという基礎的なことを教えてくれます。
次に私でも使う機会がある（かもしれない）アルゴリズムが学べます。
中盤以降は既存システムの構築事例がわかるようになっています。
今回は３点に絞らず、いつかつかう（機会があるといいな）単語とその簡単意味を、将来使いたくなった時のためにメモしておきます。
今回もあんまり刺さらない1冊でした。
そもそもこういった本を読もうとした理由としては「仕事でメンバーに作業内容を伝えたいけど、うまく言葉で伝えられない」という課題があったからなのですが、その課題を解決するための本ではなかったからです。商品を売り込むことがメインの例となっていて営業さん向けの本という印象でした。
はじめに「言語化」の意味を定義しておくと
著者の言う言語化とは「自分の頭の中で描いているものと同じものを描けるような言葉にすること」です。
ただし、この「言語化」はこの本を読んでもできるようになるとは思えませんでした。
「言語化」のためのノウハウは紹介せず、自分にも使えるかなというところだけ抜粋して3つ挙げたいと思います。
他社との差別化
そもそも商品を売り出すときに必要なのは「差別化」ではなく「相手が欲しいものを提供すること」
商品を販売する＝新しい現場に参画するときや競合がいるときに請負契約を取りたいとき、と考えればSEの私でも使えるところがあると思っています。 他社では手に入らない、というのを伝えるのはできないかと思いますが（どんな他社さんと競合してるのかわからないですからね） 困っていることを解決するために、自分たちならこれができますということは伝えられるかと思います。就職の面接と似ていますね。
あるべき姿ではなく、とるべき行動を示す
例えば「健康的な生活をおくってください」では、わからない。「健康的な生活」は最終的な理想形なので、具体的な行動を示さないといけない。具体的な行動は「練習メニュー」として考えるとよいらしい。
「健康的な生活」でいえば、「まずは野菜をしっかりとるようにすることから始めましょう」とかそういうこと。
ちょうど「最近食生活が乱れているから直さないとな…」と思っていたので「食生活を正す」というあるべき姿ではなく「まずは食べる時間をある程度固定する」ことから始める、と行動を決めておきたいと思います。言語化というよりは具体的なアクションプランを考えたという感じがしないでもないですが…。
自分だけの言葉で伝えたいときのコツ
このブログを書く時の参考になりそうです。今は読者の想定もなく書いているので、焦点は絞れていないように思います。 読書メモは将来自分が「この本どんなだったっけ…」ってなったときに読み返せるようにしたいので、将来の自分に「こんな本だったよ！ここが役に立つよ！」を教えることを想定して書くようにしようかな？
ただの作業者からリーダークラスになってくると、チーム外の人との会話が増える。
会話する相手が増えると、自分では使わなかった用語がぽろぽろでてくる。
その都度コッソリ検索するが、検索しながら会話についていくのは大変なのでいろんな用語は知っておいて損はない。
そんな用語を１記事５個くらいに抑えて地道に公開していきたい。
わわわさんが大変わかりやすいので、そちらを参照してもらった方がいい。
wa3.i-3-i.info
一言でいえば「今はこうだから今後はこうしたい」という意味だと思っている
家事、家政、ホテルの清掃の話ではない。
「システムの運用に伴って発生する無駄なデータの削除などを定期的に行い、長期的に運用可能な状態を維持すること」とある。
e-words.jp
自分の言葉でいえば「サーバのいらないデータを定期的に消してディスク溢れないようにお掃除しとこ」
ゴミがあふれてから掃除するんじゃなくてちゃんと定期的に掃除しようね
合意。
日本語のが短いんだから日本語で言ってくれ。
このあたりはセットで覚えるとよい。
システムを最初から開発すること。０を１にする。
システムの機能追加や性能完全。１を２にする。
システムを別の環境に移行する。別の言語に変えることもある。１を壱にするとでもいえばいいのか。
漏れなく・ダブりなく
結論から言うと、自分には悪本でした。
タイトル詐欺で、技術書特有の内容はほとんどなかったことが非常に残念。
新人レベルの人ならいいかもしれないが、中堅レベルだったりすでに読書術の本を何かしら読んだことがあれば必要ないです。
まぁその中でも、「これは覚えとこ」「そういえばその手があったか」と思えた部分を３つ挙げます。
技術書は「入門書」「専門書」「逆引き」を読むとよい
これで「理解した」といえるのだとか。新しい言語とかは入門書とかで終わりがちなので、わかったつもりになっていただけかもしれない。
本の要約サイトや動画を読む
時間のない自分には大変ありがたい方法ですね、動画自体があまり好きではないため動画という選択肢が頭になかったです。時代遅れでした。
洋書を読む
英語が大の苦手なので避けていましたが、今は英語翻訳が優秀なので選択肢に入れてもいいですね。
さっそくオライリーの本を買おうと思ったけど…高い...。
サブスク情報もありましたが、プライベートな時間は１日１時間程度しかないので今の自分には難しそうです。
学生～社会人まで使える勉強技術攻略本という感じでした。
読み終わった本のうち2度目はないな、という本は処分してしまうのですが
こちらは将来子供が大きくなったらまた読み返したい、読ませたいと思えたので蔵書に加えました。
自分の復習を踏まえて最も心に残ったor実践に活かそうと思ったことを３つだけあげたいと思う。
全体的にはよかった本なのですが 、トピックによってエビデンスが「AはBよりN％上回っていた」という具体的な数値があるのに対し「AはBより成績がよかった」と具体的数値がない場合があったり、
「A⇒BだからA’⇒B’」というような、似た事例だけどこれをイコールとすることには納得いかない…というようなケースがあるので、この本を完璧に実践するぜ！ではなく、これはいいなってところだけを模倣するのがいいとおもいます。
勉強し始めにいきなり１０個どーんと紹介されてもイマイチ頭に入らない
プロジェクトマネジメントプロセス10個を自分用にまとめてみる
１つ１つの名前をよく見ると、どれも確かに必要よねという内容になっている。
マネジメント名から作業名が連想しにくい部分については太字にしている
他のマネジメントエリア（下記の２～９）をまとめて実行する
変更要求、プロジェクトの終結もここに含まれる
作業範囲を計画し、コントロールする。
設定期間で完了するように順序を設定、コントロールする。
コストを見積もり、予算配分をする。承認された予算内でプロジェクトを完了させるための管理を行う。
※コストはスコープやスケジュールと合わせて統合的にコントロールする
プロダクトが要求品質を満たすことを保証する。
成果物、プロダクトプロセス、プロジェクトマネジメントプロセスのすべてが品質保証活動の対象
資源を量、種類を見積もり＆確保する。
プロジェクト組織の役割分担、指示報告の系統も定める
プロジェクトで必要な情報の作成、収集、配布、蓄積、最終処理の計画とコントロールを行う
必要な情報をどう提供するのかステークホルダごとに計画、実行する。
※ここはまだ詳細を勉強中でピンと来てない。あとで修正したい
好機と脅威を共にリスクとして扱い、改善の幅は最大、悪化は最小にとどめることを目的とする。
ほかのマネジメントエリアと相互作用を必要とする。
実行組織の外部から製品やサービスを調達する。受け入れ業務なども該当する。
ステークホルダからの期待や影響度の分析に基づき
ステークホルダからプロジェクトに効果的な関与が得られるようにマネジメントする。
こちらのサイトを参考にコード変えたり設定変えたりしてみたけど、永遠にTomcatの404エラー
HTTPステータス 404 – 見つかりません。 タイプ ステータスレポート メッセージ 要求されたリソース [/webapi/] は利用できません。 説明 オリジンサーバーは、ターゲットリソースの現在の表現を見つけられなかったか、またはそれが存在することを開示するつもりはありません。 Apache Tomcat/8.5.84
SpringBoot3はTomcat10でないと動かないですってよ！ Tomcat10にしたら動くようになったので間違いなし、でも会社の環境はTomcat10にできない…
