【エンジニアの日常】エンジニア達の人生を変えた一冊 Part6

こんにちは。Findy AI+開発チームのdanです。

この記事は「エンジニア達の人生を変えた一冊」として、ファインディのエンジニアが人生を変えた本を紹介していくシリーズです。

一冊の技術書がきっかけで、新しい分野に足を踏み入れたり、日々のコードの書き方が変わったりした経験はありませんか？今回は私・danと、千田さんの2名が、自分にとって転機となった本をお届けします。

それでは、さっそく紹介していきましょう！

■ dan / エンジニア ■

普段はFindy AI+でバックエンド・フロントエンドの開発をしているdanです。若干Terraformデビューをしました。

SREの知識地図——基礎知識から現場での実践まで

SREの知識地図——基礎知識から現場での実践まで

私が紹介する「SREの知識地図」は、Site Reliability Engineeringの全体像を一冊で見渡せるように書かれた書籍です。

この本を読んだきっかけ

SRE領域にはずっと興味がありました。サービスを安定して届けることの重要性は日々の開発で実感していたものの、自分の中でSREは「サービスを支えている、すごい人たち」くらいの解像度でした。

そんなときFindy AI+の業務でドメイン切り替えの対応を担当することになりました。インフラ寄りの知識が求められる場面が増え、これはいい機会だと思い、SREについて体系的に学んでみようと決めました。

とはいえ何から手をつければいいかわからず、社内のSREチームに、どこから触れていくのがいいかと相談しに行ったところ、この本を紹介してもらいました。

本の内容

本書はSLO・エラーバジェットの設計から、モニタリングとオブザーバビリティ、ポストモーテム、オンコール体制、トイル削減、本番リリースレビュー(PRR)まで、SREの主要な概念を9章にわたって網羅しています。組織構造の選択と実際の導入事例にも触れられています。

タイトルの「知識地図」が的を射ていて、各章が独立したトピックでありながら、章をまたいで読むとSREという領域の輪郭がはっきり浮かび上がってくる構成です。

技術的なプラクティスだけでなく「SREチームをどう組織に根づかせるか」という話まで書かれているのが、この本の特徴だと感じました。

この本から影響を受けた点/学んだ点

一番大きかったのは、「信頼性は100%を目指すものではない」という考え方に触れたことです。SLOとエラーバジェットの仕組みを知り、信頼性と開発スピードのバランスを定量的に議論できるという発想に衝撃を受けました。

普段のアプリケーション開発では「落ちないこと」が当然の前提になりがちですが、SREの視点ではエラーバジェットが残っている限りリスクを取ってリリースできるし、使い切ったら信頼性の改善に集中する。このトレードオフの設計思想は、開発者としてのものの見方を変えてくれました。

現在、SREチームと隔週で定点観測会を行っているのですが、本書でSLOの概念を理解してから臨めたことで、観測結果の受け取り方が変わりました。

数値の変動から仮説を立てる思考プロセスや、そこからNext Actionにつなげる動き方など、SREチームの実践を肌で学べています。本書がなければ、観測会に参加しても表面的な数字を眺めるだけで終わっていたかもしれません。

特に印象に残った部分

ポストモーテムの章で触れられていた、障害が起きる前の小さな異変から学びを得るという考え方が印象に残っています。

Findy AI+ではアラート体制の基盤を強化する余地がありました。SREチームと一緒に、まずそこを整えるところから始め、モニタリングのダッシュボードを作り、そこから定点観測で振り返る。会を重ねるごとに着実に前進できていると実感しています。本書で読んだ「軽量に回せる学習サイクル」を、まさに今つくっている最中です。

もうひとつ、第9章の「SREの実践」で書かれていた、開発チームの課題に寄り添うというアプローチにも強く共感しました。ドメイン変更の対応でSREチームと一緒に動いたとき、ただサポートされているのではなく、同じ目線で一緒に進めているという感覚がありました。

SREプラクティスを一方的に推進するのではなく、チームが直面している具体的な課題にまず寄り添う

これはSREに限った話ではなく、自分が何かを提案するときにも同じことが言えると思います。新しいツールやプロセスを持ち込みたいとき、まず相手が今何に困っているかから入ることで提案は押し付けではなく解決策になるのではと感じました。

このような方におすすめ

自分のようにアプリケーション開発がメインだけど、インフラや運用にも関心が出てきたエンジニアにはぴったりの一冊です。SREの全体像を短時間でつかめるので、これからSRE領域に踏み出す最初の一冊として機能します。

また、すでにSRE的な業務に携わっている方にとっても、自分の実践を体系の中に位置づけ直す機会になると思います。

私の経験ではエラーの発生でSLOの数値が下がっているという議論があったときに、なぜエラーがSLOに影響するのか、サーバーが返すエラーの仕組みを変えられそうかを考える土台になったのは、本書で得た知識でした。

今気になってる本

• LLMの原理、RAG・エージェント開発から読み解く　コンテキストエンジニアリング

LLMの原理、RAG・エージェント開発から読み解く　コンテキストエンジニアリング エンジニア選書

Findy AI+ではLLMが分析したものをサービスに取り入れています。現在、機能が増えていく中で分析の精度がネックになっており、プロンプトの調整に課題を感じています。

この本ではLLMがどのように解釈して分析をしているのか、なにをさせてはいけないのかなども書かれており、サービスのためのキャッチアップ以外では、現在のAI駆動開発にも活かせる本なのではないかと思っています。

続いては、キャリアプロダクト開発部 転職開発チームの千田さんです。千田さんが選んだのは、多くのエンジニアにとってバイブルともいえるあの一冊。「良いコードとは何か」を考えるきっかけをくれた本について語ってもらいました。

■ 千田 / エンジニア ■

キャリアプロダクト開発部 転職開発チームの千田です。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

私が紹介する「リーダブルコード」は、コードの読みやすさに焦点を当てた実践的な書籍です。

この本を読んだきっかけ

新人エンジニアとして働き始めたとき、「正しいコードの書き方」がわからなくて悩んでいました。動くコードは書けるけれど、それが良いコードなのか自信が持てない。レビューで指摘されても、なぜそう書くべきなのか腑に落ちないことがありました。

そんなときに出会ったのがこの本です。エンジニアの間で定番書として名前を聞くことが多く、まずはここから始めてみようと手に取りました。

本の内容

本書は「コードは他の人が最短時間で理解できるように書かなければいけない」という原則のもと、変数名の付け方、コメントの書き方、条件分岐の整理、式の分割といったテーマを13章にわたって解説しています。

Before/Afterのコード例が豊富に載っていて、「読みやすいコードとは何か」を実践的に説明してくれます。

コードレビューのとき、なんとなく「こっちのほうがいいと思う」とは感じるのに、言葉にできない。そういう経験を持っている方は多いのではないでしょうか。この本を読むと、「なぜ読みやすいと感じるのか」を論理的に説明できるようになります。

この本から影響を受けた点/学んだ点

一番大きかったのは、コードを書く上での自信が生まれたことです。

本書を読む前は、レビューで「こう直したほうがいい」と言われても、それが一般的なルールなのか、その人の好みなのか区別がつきませんでした。本書は「理解するまでにかかる時間」を短くするという明確な判断軸を示してくれます。

この軸を手に入れたことで、「なぜこう書いたのか」を自分の言葉で説明できるようになりました。

例えば、1行に詰め込んだ複雑な式よりも2行に分けたほうが理解しやすいケースがある。短いコードこそ良いコードだと思い込んでいた当時の自分にとって、コードの良し悪しは行数ではなく読み手の理解コストで決まるという考え方は新鮮でした。

特に印象に残った部分

2つあります。

ひとつはコメントについての章です。新人の頃はコメントをどこに書けばいいのかわからず、結局ほとんど書いていませんでした。本書では「コードからすぐにわかることをコメントに書かない」としつつ、設計意図やコードの欠陥など「監督のコメンタリー」としてのコメントは積極的に書くべきだと述べています。

コメントを書くか書かないかではなく、「読み手にとって新しい情報を提供するか」で判断する。この基準を知ったことで、コメントを書く場面と書かない場面の区別がつくようになりました。

もうひとつは、説明変数と要約変数の考え方です。本書では、複雑な式や繰り返し登場する条件を変数に切り出すことで、コードの意図を明確にする手法が紹介されています。

例えばrequest.user.id == document.owner_idという式は、要素が多くて読み解くのに少し時間がかかります。でもこれをuser_owns_documentという変数に置き換えると、コードが伝えたいことは「ユーザーがこの文書の所有者かどうか」だとすぐにわかる。式が「何をしているか」ではなく「何を意味しているか」を伝えるようになるわけです。

この考え方を知ってから、条件分岐やif文の中に長い式をそのまま書くことに違和感を覚えるようになりました。変数名をつけるという小さな工夫が、コード全体の読みやすさに大きく影響することを教えてくれた例でした。

このような方におすすめ

コードを書き始めたものの、何が良いコードなのかわからないという方にはぴったりの一冊です。設計パターンやアーキテクチャのような大きな話ではなく、日々のコーディングですぐに実践できる内容が詰まっています。

また、経験を積んだエンジニアにとっても、普段無意識にやっていることを言語化し直すきっかけになると思います。レビューで「なんとなくこっちのほうがいい」としか言えなかった感覚に、言葉を与えてくれる本です。

おわりに

SREの全体像をつかむための入門書と、日々のコーディングを支える定番書。今回の2冊は方向性こそ異なりますが、私はSLOとエラーバジェットという定量的な視点を、千田さんは「読み手の理解コスト」というコードの良し悪しを測る基準を、それぞれ本から得ていました。

判断軸があると、迷ったときに立ち返る場所ができる。技術書との出会いがそういうきっかけになることを、少しでもお伝えできていれば嬉しいです。

ファインディでは一緒に働くメンバーを募集しています。少しでも興味を持っていただけた方は、ぜひこちらをご覧ください！