O'Reillyの読み放題で読んで心から良かったデータエンジニア向け書籍3選
1. はじめに
転職が決まって、次の職場が始まるまで1ヶ月の有給休暇をもらえた。
この1ヶ月をどう使おうか考えたとき、真っ先に浮かんだのが「学習に充てたい」だった。新しい職場で活躍できるように知見を広げておきたいという気持ちと、もう一つ、今まで業務に直結する知識ばかり追いかけていたから、純粋な好奇心で学んでみたいという気持ち。その両方があった。
ちょうど良いタイミングで、FindyのキャンペーンでO'Reilly読み放題の90日間無料体験に当選していた。当選したのは少し前だったけど、有給消化ができる11月に当てれば、まとまった時間で集中して読めると考え、無料期間を最大限活かすために登録のタイミングを少し遅らせることにした。
前職ではデータエンジニアとして約3年ほど働いていた。中央集権型のデータレイクとデータウェアハウスを組み合わせたデータ基盤を構築して、日々パイプラインを書いていた。ただ正直なところ、ずっと不安を抱えながら仕事をしていた。
「このアーキテクチャで本当にいいのだろうか」
「この技術選定は正しいのだろうか」
周りにシニアエンジニアがいない環境だったので、要件を満たすように自分で調べながらシステムを構築していた。だけど、構築したシステムや設計に対して適切なレビューをもらえる機会がほとんどなく、常に手探りの状態だった。動くものは作れる。でも「これがベストなのか」と聞かれると、自信を持って答えられない。
SparkやIcebergといった技術も、名前は知っているけど使ったことがない状態だった。次の職場ではモダンなデータスタックに触れる機会があるかもしれない。せめて概念レベルでは理解しておきたい。
そんな動機で読み始めた本が、思っていた以上に刺さった。
これから紹介する3冊は、実装テクニックを教えてくれる本ではない。「なぜそう設計するのか」「どんな選択肢があるのか」「何を基準に判断すればいいのか」という、思考の枠組みを与えてくれる本だ。前職でずっと感じていた「これでいいのか」という不安の正体が、少しずつ見えてきた気がする。
本記事で紹介する3冊は、以下の基準で選んだ。
- これまでの業務経験だけでは得られなかった気づきをくれること
- 特定のツールやプロダクトではなく、"考え方の骨格"を学べること
2. 書籍1：Data Engineering Design Patterns
"パターン思考が基盤設計の視野を一気に広げる"
書籍の概要
本書はデータエンジニアリングにおける設計パターンを体系的にまとめた一冊だ。データの取り込み、変換、保存、分析者への提供といったパイプラインの各フェーズで、どんなパターンが使えるのかが具体例とともに解説されている。
何より良かったのは、各パターンについてメリット・デメリット、どんなユースケースに向いているかが整理されている点だ。「こういう状況ならこのアプローチが有効」という設計の引き出しが一気に増える。
得られた気づき
読み始めてすぐ、前職での自分がいかに「場当たり的に」設計してきたかを思い知らされた。
たとえばデータ品質をどう担保するか考えるとき、これまでは「バリデーションを入れる」という漠然とした発想しかなかった。でも本書を読むと、データ品質をどこで強制するか、いつバリデーションを実行するか、どう監視するかなど、様々な切り口で手法が解説されている。それぞれのメリット・デメリットを比較した上で適切な方法を選ぶ。そういう思考プロセス自体が、前職の自分には欠けていた。
前職で「これでいいのか」と不安だった理由の一つが、ここにあったのだと思う。そもそも選択肢を知らなかった。比較対象がないから、自分の設計が妥当なのか判断できなかった。
本書を読んで、アーキテクチャ設計の判断軸が持てるようになった感覚がある。たとえるなら、今まで「なんとなくこの道を選んだ」と言うしかなかったのが、「この条件だからこのルートを選んだ。他のルートだとこういうデメリットがある」と説明できるようになる感じだ。
「どの技術を使うか」ではなく「どのパターンで解くか」。この問いの立て方を知っただけでも、次の職場での設計議論に臨む姿勢が変わりそうだ。
次の職場で試したいこと
新しい環境でデータ基盤に触れるとき、まずは既存のパイプラインを「パターン」の観点から読み解いてみたい。どんな設計思想で作られているのか。意図的な選択なのか、歴史的経緯の積み重ねなのか。それが見えてくれば、改善提案の切り口も見つかるはずだ。
3. 書籍2：Practical Lakehouse Architecture
"レイクハウスの本質を概念として捉え直せる"
書籍の概要
「レイクハウス」という言葉はここ数年で急速に広まった。ただ、その実態は正直よく分からなかった。Delta Lake、Apache Iceberg、Apache Hudiといったテーブルフォーマットの話なのか、データレイクとデータウェアハウスを統合するという思想の話なのか。
本書はその曖昧さを解きほぐしてくれる。レイクハウスアーキテクチャを構成する要素が一つひとつ丁寧に解説されていて、「なぜこの技術が必要なのか」という背景から理解できる。
得られた気づき
前職では、データレイクとデータウェアハウスを別々のものとして扱っていた。GCSにローデータを溜めて、BigQueryで分析用のテーブルを作る。なんとなく「これが普通」だと思っていたけど、なぜそうしているのか、他にどんな構成があり得るのかは深く考えたことがなかった。
本書を読んで、レイクハウスが「技術スタックの名前」ではなく「設計原理の集合体」だと分かった。
- なぜオブジェクトストレージ上でACIDトランザクションを実現する必要があるのか
- なぜスキーマエンフォースメントとスキーマエボリューションの両方が求められるのか
- なぜメダリオンアーキテクチャ（bronze/silver/gold）という多層構造が有効なのか
これらの「なぜ」に答えてくれる。
本書の良いところは、特定のプロダクトに依存せず、抽象的なアーキテクチャレイヤーで説明が進むことだ。だから実務経験がない技術についても「なぜこうした技術が必要とされるのか」という文脈から理解できる。
前職を振り返って
本書を読んだ後、前職で構築していた基盤を頭の中で振り返ってみた。
正直なところ、前職の環境にレイクハウスアーキテクチャをそのまま適用するのは、技術的な課題や用途に対してオーバースペックだったと思う。おそらく採用することはなかっただろう。
ただ、今後のことを考えると話は変わってくる。組織が成長したり、ユースケースが多様化したりすれば、選択肢になる可能性は十分にある。特に生成AIでの利用が広がっていく中で、大量のデータを柔軟に扱えるアーキテクチャの重要性は増していくはずだ。
「今すぐ使うか」ではなく「手札として持っておく」という意味で、この本を読んだ価値があったと感じている。アーキテクチャを考えるときに、選択肢が一つ増えた。その選択肢がいつ必要になるか分からないけど、知っているのと知らないのとでは、判断の幅が全然違う。
4. 書籍3：Data Mesh
"データの責任と価値の作り方を問い直すアーキテクチャ思想"
書籍の概要
Zhamak Dehghani氏による本書は、データアーキテクチャの議論を技術から組織へと拡張している。Data Meshとは特定のツールや実装パターンではなく、データを分散的に管理・提供するための組織原則だ。
- ドメイン所有
- データプロダクト思考
- セルフサービスインフラ
- フェデレーテッドガバナンス
この4つの柱が提唱されている。
得られた気づき
前職では中央集権型のデータ基盤を構築していた。データエンジニアチームがすべてのデータを管理して、各部門からの依頼に応える形だ。それが当たり前だと思っていた。
でも本書は、そのモデル自体がスケールしない構造的問題を抱えていると指摘する。
データの価値を最も理解しているのは、そのデータを生み出すドメインの人々だ。でも中央集権型だと、データエンジニアがドメイン知識なしにパイプラインを作ることになる。一方でドメインの人々は、自分たちのデータがどう加工されているか把握できない。
前職で感じていた「これでいいのか」という不安。その一部は、まさにこの構造的な問題だったのかもしれない。自分がドメインのことをよく分からないままパイプラインを作っている感覚があった。ドメインの人たちが「データがほしい」と言ってくるけど、彼らも自分たちのデータがどう流れているか把握していない。お互いが手探りの状態だった。
Data Meshはこの問題に対して、データを「プロダクト」として扱い、各ドメインがそのプロダクトのオーナーシップを持つことを提案する。データエンジニアの役割は、中央で全てを作ることではなく、各ドメインがデータプロダクトを作れるようにするプラットフォームを提供することに変わる。
役割観の変化
これは単なるアーキテクチャの話ではない。データエンジニアという職種の定義そのものを問い直す内容だ。
「自分は何を作る人なのか」から「自分は何を可能にする人なのか」へ。
少し補足すると、「作る人」は各部門から依頼を受けて、自分でパイプラインやテーブルを作る働き方だ。前職の自分がまさにこれだった。一方で「可能にする人」は、各ドメインチームが自分たちでデータを扱えるように、プラットフォームや仕組みを整える働き方。成果物は自分が直接作ったものではなく、「他の人が作れるようになった」という状態になる。
たとえるなら、「作る人」は料理人で、お客さんから注文を受けて自分で料理を作る。「可能にする人」はキッチンスタジオの運営者で、調理器具や食材を揃えて誰でも料理できる環境を整える。自分は料理しないけど、たくさんの人が料理できるようになる。
どちらが正解というわけではない。ただ、この二つの役割の違いを意識したことがなかったので、新しい職場で自分がどんな役割を担いたいのか、考えるヒントをもらった気がする。
もちろんData Meshをそのまま適用できる組織は限られる。でも「データの責任は誰が持つべきか」「データエンジニアは何を提供すべきか」という問いは、どんな組織でも考える価値がある。
5. 3冊を通じて浮かび上がる共通テーマ：データエンジニアは"構造と価値"を設計する仕事である
3冊を読み終えて、前職でずっと感じていた不安の正体が少し分かった気がする。
自分は「作業者」として手を動かしていたけど、「設計者」としての視点が足りなかった。なぜこの構成にするのか、他にどんな選択肢があるのか、この設計は将来どんな問題を引き起こすのか。そうした問いに答える軸を持っていなかった。
3冊はそれぞれ違う角度から、その軸を与えてくれた。
- Data Engineering Design Patterns → 「パターン」という切り口で設計の選択肢を整理
- Practical Lakehouse Architecture → 「アーキテクチャ」という切り口で技術スタックの背後にある原理を提示
- Data Mesh → 「組織思想」という切り口で技術と人の関係を問い直す
三つの切り口は異なるけど、いずれも「実装の上位にある概念レイヤー」を扱っている。そして互いに補完し合う関係にある。
パターンを知らなければアーキテクチャの選択肢が見えない。アーキテクチャを理解していなければ組織への影響を評価できない。組織思想がなければパターンやアーキテクチャは単なる技術的な好奇心で終わってしまう。
まだ実務には活かせていない。読んだだけの状態だ。でも、次の職場で実際に手を動かすとき、この3冊で得た視点がきっと効いてくるはずだと思っている。「これでいいのか」と不安になったとき、立ち返る場所ができた。
6. まとめ：O'Reilly読み放題の良さは"技術の奥にある原理"に触れられること
転職の合間の1ヶ月。この時間を使ってO'Reillyの読み放題で学習できたのは、本当に良かった。
技術書は高い。一冊5,000円を超えるものも珍しくなくて、「ハズレだったらどうしよう」という心理的ハードルがどうしてもある。でも読み放題なら、気になった本を片っ端から開ける。目次だけ眺めて閉じてもいい。この気軽さが、普段なら手に取らないジャンルの本との出会いを生んでくれた。
今回、転職の機会だけでなく、O'Reilly読み放題の無料体験を通じて学習の機会を与えてくれたFindyには感謝しかない。キャンペーンに当選したタイミングと有給消化の期間がうまく重なったのは、振り返ってみると本当にラッキーだった。
今回紹介した3冊は、いずれも実装テクニックではなく「考え方」を教えてくれる本だ。読んだ翌日から生産性が上がるわけではない。でも、新しい職場で設計判断を求められたとき、チームで議論をするとき、きっと効いてくる。
前職でずっと感じていた「これでいいのか」という不安。その不安を和らげてくれたのは、実装スキルではなく、思考の枠組みだった。
データエンジニアとして次のステージに進みたいと感じている方、新しい環境に向けて準備したいと思っている方に、この3冊を心からおすすめしたい。
Discussion