やわらかテック

興味のあること。業務を通して得られた発見。個人的に試してみたことをアウトプットしています🍵

モチベーションがなくなった結果、データベースについて2ヶ月間勉強した

概要

  • 新卒4年目にして業務の慢性化、スキルアップの実感の無さからモチベーションが低下した
  • 得た知識が業務で高確率で役に立つ知識(投資効果の高い)を得ようと思い立つ
  • 投資効果の高いスキルはほぼ100%どのプロジェクトでも使われるデータベースだと考えた
  • ロードマップを作って5冊の書籍を読み進めた
  • 理論、知識を身に付けたが実践が少なすぎる。もっと実践をせねば

新卒4年目にして何をやりたいのか分からなくなった

今年でエンジニアになって4年目になりました(学生時のインターンを含めると6年目)。
「プログラムを書くのって楽しいな」という気持ちからのスタートで、今、好きなことをやってお金を貰えて...まさに天職だなと感じます。

元々、情報系の専攻ではなかったため、覚えること、興味があることが多すぎて、技術書や何かしらの情報に触れない日はありませんでしたが、ある日を境にモチベーションが急低下してしまいました。今になって思えば、業務の慢性化、スキルアップの手応えの無さ、報酬が増えないことに嫌気が指していたのだと思います。

「あれ、何のためにやってるんだっけ?」という問いに対して答えが出せなくなりました。

また、今まで得た自分のスキルが業務に振り回されまくっていることに気づきました。

  • WEB開発 / バックエンド(PHP)
  • 機械学習
  • WEB開発 / フロントエンド(React.js)
  • WEB開発 / バックエンド(Golang, Rails)
  • PM, EM
  • WEB開発 / バックエンド(Rails)

色んなことがやれて楽しかったのですが、今になって思うと、どれも浅く広くで「これだけは負けない」という分野がなく、自分がやりたいことが何なのか分からなくなってしまいました。

投資効果の高いスキルを考える

さすがにまずいと思い、セルフ振り返りをしました。

今までは自分の興味を軸に闇雲にやりたいことや、身につけたいことに取り組んできました。
「じゃあ、それが無駄だったのか?」というと、そんなことはなく、確実に自分の知識や考え方は豊かになっています。
ただ、効果が出るまでの時間が非常に長い、もしくは目の前にある問題に対しての即効性はありませんでした。

別の問題に取り組んでいる時に、「そういえば...」とふと思い出すケースが大半だったのです。 出番が少ない知識は飽き性の自分とは相性が悪く、時間と共に忘れ去ってしまいます。それではせっかく得た知識が水の泡です。

今まで「これをやれば業務で高確率で役に立つ」という視点で知識を得たことがなかったので、投資効果の高いスキルを考えてみることにしました。

データベースやばい

「投資効果の高いスキルって何だろう...」と考えながら仕事をしていると、とある考えに辿り着きました。

  • 1.どのプロジェクトでもデータベース、特定の形式を持つデータを扱った
  • 2.ほぼ100%データベースを扱っているのにテーブル設計、効率的なクエリを熟知している人が周りにいないが、ニーズが非常に高い
  • 3.テーブル設計や効率的なクエリはケースバイケースであり、情報が探しにくい

2.に関して補足をしておくと、普段はRailsとActiveRecordをメインに使っているため、自分の周りではそういった傾向があります。
そんな状況下ですが、クエリの処理時間が遅いと、高速化が求められることが多々ありました。

こんなに身近なものであるにも関わらず支配的で、今も昔も知識が要求されて、他のメンバーと差別化が可能な知識はデータベースしかないと思いました。同時にこれは費用対効果の高いスキルであると言えます。

データベース設計を制する者はシステム開発を制す。
それはシステムがデータのフォーマットに合わせて作られるから(システムに合わせてデータを作るのではない)。

引用元: 第1章 データベースを制する者はシステムを制す

データベースマスターへのロードマップを考えた

まずは、現時点でデータベースへの理解がどの程度あるかの考えました。
5年前にピュアなSQLを少し触ったことがある程度でテーブルの設計やデータ操作のクエリは雰囲気でやっていました。最近はORM(ActiveRecord)を使ってデータをいじっていますが、どのようなSQLが発行されるのかはよく分かってません。

「じゃあSQLから勉強するか!」でも良いのですが、自分は飽き性な上にモチベーションが急低下中です。
明確な目標があればモチベーションを保てるので、どうなればデータベースに熟知した人物になれるのかをロードマップで考えてみました。

まず第一にSQLで何が出来るのか、何が出来ないかを把握するために、SQLの全体像を掴む必要があると考えました。
次に複雑なSQLを排除するために、アンチパターンを知る必要があると考えました。
(過去にNULLまみれのテーブルで非常に苦労させられました...)

やっても良いことを覚えるよりもやってはいけない事を覚えた方が効率的だという狙いもあります。

アンチパターンを知った上で、よいデータベース設計を学ぶ。最後に簡単なクエリで解決できない場合に上級者はどのようにSQLを考えるのかを知れば、自分の思い描く人物になれると考えました。

用意して読んだ本

さきほどのロードマップに従い書籍を用意しました。実際には一度に購入したのではなく、1冊読み終わるごとに次の書籍を購入しました。

読んだ順に記載してます。

SQLアンチパターン

SQLアンチパターン

Amazon

書籍から得た知識

  • SQL 文法
    • やれる事
    • やれない事
    • 複雑なサブクエリを用いないケースであれば記述可能
  • テーブル設計
    • アンチパターン集
    • 物理設計と論理設計
    • 正規化(第1正規化 ~ 第6正規化)
  • リレーショナルモデル
    • リレーショナルモデルが今日までパワフルなのは集合という理論と演算のため
    • リレーショナルモデルと実際のデータベースの違い(eg: 重複があるorない)
    • なぜテーブルを正規化するのか

冗長ですが、順に書籍の感想も合わせて記述します。

SQL入門

最初に読むのにぴったりなレベル感でした。テーブルの結合、集約化、サブクエリとつまづき易いとされている部分が簡潔で分かりやすく、以降の書籍を読む上で何度も参照しました。テーブル設計に関わらなくても読んでおくべき一冊かと思います。

SQLアンチパターン

後半の方が例が身近で分かりやすかったです。
自分が実際に出会ったことがあるのはジェイウォーク、ナイーブツリー、IDリクワイヤ、マルチカラムアトリビュート...と意外と多く「あ、これ知ってるな」と楽しく読めました。
全てのパターンをスラスラと説明は出来ないのですが、テーブル設計時やクエリを書く際に自分がやろうとしていることはアンチパターンではないかと辞書的に持っておけば良いかなと思っています。

達人に学ぶデータベース設計

名著として過去に勧められたこともあり選択しました。
冒頭で引用した「データベースを制するものはシステムを制する」というのは著者のミックさんのお言葉です。テーブル設計で重要なことはシステムをよく知ること。何のために何をしたいのかを知らねば適切なテーブル設計は出来ないと記載されており、頭をガツンと叩かれた気がしました。
アプリケーションを深く知るのが退屈で、データベース設計の腕を上げれば良いと考えた自分の誤りに気づきました。

データベース実践講義

「達人に学ぶデータベース設計」の中で、ミックさんは何度もリレーショナルモデルについてのトピックを扱っており、参考文献に「データベース実践講義」が紹介されており、リレーショナルモデルって何やねんと思いで「データベース実践講義」を購入しました。
現在、扱っているデータベースのテーブルやレコード、カラムという概念はリレーショナルモデルではリレーショナル、タプル、属性と表現される...とリレーショナルモデルが集合と論理を元に構築された概念だという事を知りました。

しかし、この書籍はリレーショナルモデルについての知識がない自分には難しすぎました。
2章まで読んだところで挫折しました。訳書ということもあり、表現が分かりにくかったです。

データベース実践入門

ただ、リレーショナルモデルについての興味は引き続きあったので「データベース実践入門」を購入しました。
「データベース実践講義」と比べると非常に分かりやすかったです。読むならまずこっちから。
自分の中の結論としては、リレーショナルモデルに従って設計した正規化、直交化されたテーブルや集合演算を用いたクエリはリレーショナルモデルの恩恵(効率的なクエリ実行、データの整合性が担保される...etc)を受けるということです。

逆にいえば、リレーショナルモデルから遠ざかれば遠ざかるほど、恩恵を受けられません。
しかし、リレーショナルモデルを現実のデータベースに適応するには限界があり、そのためにインデックスやトランザクションなどの機能がデータベースには用意されていることを知りました。

以上がそれぞれの書籍の感想です。

反省点: 本当に出来るようになっているのか

テーブル設計の理論や知識を知りましたが、テーブル設計は書籍を読み通した2ヶ月間で練習問題の2回しかやっていません。
アンチパターンを踏まず、本当に正規化を満たすテーブルを設計出来るようになっているかどうか分かりません。設計に関しては本当に経験を積むしかないと思います。とはいえテーブル設計の機会は業務では中々、立ち会えないものです。

どのようにしてテーブル設計の経験を積めばいいのか、すなわちテーブル設計の機会を増やすのかについては考える必要があり、今の自分は知識と理論だけで止まってしまっています。

またSQLについても同様で、集約、自己結合や相関サブクエリといった知識はある一方で書いた経験が少なすぎます。SQL入門の練習問題をいくらか解いた程度です。

双方に共通して言えることですが、もっと練習問題やサンプルケースを上手く活用しなければいけませんでした。
この件に関して外部のエンジニアの方に相談して、非常にありがたいお話を聞いたので、別の記事で紹介させて頂きます。

最後に

モチベーションが低下した中でしたが、データベースというテーマに2ヶ月間、取り組んで得られるものは多かったです。また今まで1つのテーマの書籍を連続して読むという経験はなかったので、特定分野の知識を掘り下げるのには非常に有効だと体感しました。

とはいえドラッガーがこんな言葉を残している。

実践なき理論は空虚であり、理論なき実践は無謀である
ピータードラッガー

もっと頑張らねば。