お久しぶりです！2024 に読んだ本を紹介していきます。

仕事関係で読んだシリーズ

『みんなのフィードバック大全』

概要：コンカー社の方が書いた、フィードバックについて書かれた本です。フィードバックとは、相手の行動や考え方に対して評価を伝えることで、相手に弱み・強みに気づきを与え、成長につなげてもらうコミュニケーションのことです。フィードバックは、良かったと思う点を伝えるポジティブフィードバックと、改善点を伝えるギャップフィードバックの２つがあり、ギャップフィードバックについては、気づきを与える軽いものと、すぐには改善が難しいことに対する改善要求の２つに分けられます。それぞれを効果的に行うためのポイントが紹介されていました。また、フィードバックを受ける側のスキルをコーチャビリティといい、成長意欲と忌避の気持ちのバランスを保った心構えができると、良いと書かれていました。

フィードバックは指摘する側、受け取る側双方にとって心理的障壁の高い作業ですが、それをうまく行うことで、本質的な成長につなげることができます。仕事をする上では、相手に要望やいわゆる”お気持ち”が芽生えたときの相手への伝え方、また、自分の発言や行動はどうだったか？のフィードバックを受けるスキルを学ぶことができました。職場の部署（グループ？）の数十人全員で読んだのですが、共通の知識があることによって、よりフィードバックをしやすく・受けやすくなったと感じました。

今までは、フィードバックは相手のために行うもので、若手の自分からは余裕があったらやろう、くらいに思っていましたが、その考えが変わりました。何かアクションを起こしたあとに、フィードバックをお願いして自分の成長に繋げられるようになりました。また、自らフィードバックを行うことでチームや組織の関係性やパワーの向上に繋がる実感も得られました。

印象的だったことや、学び

• フィードバックは立場に関係なく、組織全体でするもの。
• フィードバックをする際は、「建設的に、成長を願っている」状態のマインドですることによって効果が生まれる。
• 気づきのフィードバックは、すぐ伝えることが大事。（すぐやらないと忘れてしまうので 😢）
• 大抵の場合は誰も悪意を持っておらず、それが正しいと思ってやっている。だからこそ相手を想像するマインドが大事だし、ふまえてフィードバックを行えばよい。
• フィードバックを受けるときは、とにかく最後まで聞き、感謝の気持ちと何が有用だったかを伝える。
• ポジティブフィードバックは、ギャップフィードバックの 10 倍伝えるくらいがよい。
  • 本には書いてなかったけど調べた内容：人はネガティブな情報に注意が向いて記憶に残しやすいという「ネガティビティ・バイアス」というのがあるらしい。（その比は数倍〜20 倍くらいという複数の記述があったがソースが曖昧のため略）だからこそたくさんポジティブフィードバックをたくさんしようということなのかなと感じました。 https://mitsucari.com/blog/negativity_bias/#i-2

『システム設計の面接試験』

概要：例えば Twitter や YouTube といった大規模サービスを設計するならどういう構成にする？という、システム設計の面接試験のケーススタディの本です。

大きく２つ学びのポイントがありました。一つは、設計を進める上で要件定義をどう上手くやるか。本では始めに曖昧な仕様が示され、仕様の深堀りもする必要がありました。設計するサービスがどのような機能か、ユーザー数やリクエスト数のピークはどれくらいか、スケールアップのスピード（半年後の規模は？）などを理解し、スコープを明確にすることが重要でした。仕事ではここまでクリティカルな要件定義になることは少ないですが、仕様や特性を理解して設計を進めることは大事だと感じました。もう一つは、技術的な学びです。大規模になればなるほど、大量リクエストを捌くための負荷分散や、パフォーマンス考慮が特に学びになりました。

学びなど

• 中国では FCM(Firebase Cloud Messaging; モバイル通知の基盤)が使えないなど、地域も考慮した設計が必要
• パフォーマンス改善のために難解なアルゴリズムを使っている例があって、抽象化されたレイヤーでも難解なアルゴリズムが出てくるのが興味深かった
• サーバーを冗長化してロードバランサーを用意したとして、じゃあロードバランサーも冗長化したら…？その前段の DNS も…？と考えると、どこまで冗長化するかはどこかで線引きしないといけないんだなと思いました（笑）

関数型ドメインモデリング ドメイン駆動設計と F#でソフトウェアの複雑さに立ち向かおう』

概要：通称 DMMF という本の和訳版です。ビジネスドメイン（業務フロー）とソフトウェアモデルを一致させ、みんなが共有されたメンタルモデルで会話できることを目指しています。F# の特性を活かしてドメイン駆動設計を行う方法や、より実装に近いところでは、エラーの扱いに Railway Oriented Programming が紹介されていました。

モデリングを上手にやることと、それを型でしっかりと表すの両方を行うことで、堅牢なコードができあがります。静的型付け言語経験が少ない自分にとっては、学びが大きかったです。型がきれいについた実装が、そのまま仕様を表すドキュメントになるのも納得です。

『体系的に学ぶ 安全な Web アプリケーションの作り方 第 2 版 脆弱性が生まれる原理と対策の実践』（徳丸本）

今となっては少し古い内容で、かつての Web システムがいかに脆弱だったかとことに驚きが多かったです。また、今から開発するとなっても PaaS などのクラウドサービスを使うことが多く、セキュリティ面はそんなに考えなくても開発ができるという意味では良い時代なのかなと思いました。

技術的には、セッションや各種 HTTP ヘッダー、認証認可の概念について、そしてキャッシュ制御について学びを深めることができました。

学べて良かったこと

• TOTP(SMS で届いたりアプリで見れたりする 6 桁の数字を入力して認証するやつ)の技術：（時間＋秘密鍵 →HMAC アルゴリズム →6 桁の数字）となっていること。RFC6238 に規定されている。
• DNS は脆弱な状態になりやすいこと（浸透いうな）
• どこにでも脆弱性があること（正規表現や文字コードなどが意外だった）

『チームを動かす IT 英語実践マニュアル ~ 現役シニア・エンジニアが教える』

ちょうど 2024/12 から仕事で英語を使うようになったので、読みました。シーン別にフレーズが多数紹介されていました。特に、人に何かをお願いするときや、プロジェクト進行に関する表現の言い回しがすぐ使えて良かったです。IT 特化なので、エンジニアと仕事をする人向けの本です。

学び

• ローコンテキストに具体的に伝えたほうが良いこと。
• ノリと勢いでなんとかなること。

まとめ

以上、仕事関係で読んだ本です。振り返ってみると、ハードスキル系の本が多かったですね。来年は、仕事術やマネジメントに関する本も読んでいきたいのと、そもそも読む冊数を増やしたいと思いました 😅

今回から、Disqus のコメント欄を設置しました。スタンプだけでもぜひ押してください！