yukiotechblog

「いいエンジニアはキャリア構築スキルがある」が身にしみるようになってきた

career

酒井潤さん「いいエンジニアはキャリア構築スキルがある」

私が敬愛するソフトウェアエンジニアである酒井潤さんが言っていた話で「いいエンジニアはキャリア構築スキルがある」というものがあります。

https://www.youtube.com/watch?v=hvWE-Fty_dc

平たく言うと、以下のとおりです。

  1. 良い企業に一度入っておくと人材価値が上がる
  2. 大企業は難しいトピックを扱っていることが多いため、技術力が上がる

学生時代に聞いたときはピンとこなかった

この考えに最初に触れたのは学生の時で、「まぁそりゃそうだよな、、いい企業に入れればその後の転職活動時に有利だよな」といった程度の印象で、あまりピンときませんでした。

ただなんとなくこの話が頭の片隅にありました。

大規模サービスを扱う企業で働きたかった

私はいつか大規模サービスを扱う企業で働いてみたいなという思いがありましたが、最初は中規模くらいのサービス開発に携わっていました。

とはいえ、その当時の私のスキルはRailsで簡単なWebアプリを作ったことがある程度のレベルだったので、そのような会社に入るためにはそれ相応の準備が必要だなと考えていました。

大規模サービスで評価されるような成果を上げようとした

まずは書類選考を通す必要があるということで、大規模サービスを扱う企業でも評価されるようなレジュメに書ける成果をなんとかして挙げられないかと考えました。

例えば、大規模サービスでは大量データをDBで扱うためチューニングの仕事をやったり、より大量データを効率的に処理するためのリアーキテクチャを進めたり、分散DBへの移行プロジェクトをリードしたりといったことをやっていました。

技術を仕組みから理解する必要が出てきた

このような仕事をやろうと思うと、表面的な技術理解だけでは太刀打ちできないケースが色々と出てきます。

例えば、クエリチューニングをする場合、カーディナリティ・統計情報・実行計画・構文の評価順序ということを知っていないと、問題を切り分ける際に正しく対処することができません。

また、RDBから分散DBに移行する際もそれぞれの仕組み上の違いを理解していないと、どのようなところで性能劣化しやすいのかといったことを早期段階で把握することができないため、後々になって性能問題に発展する可能性も出てきます。

所謂RDBは参照系の処理はリードレプリカで水平スケールできるが更新系の処理は水平スケールさせることができず、シャーディングなど運用負荷が高いスケーリング手法を取る必要が出てくる。

一方で分散DBであるNewSQLではRaftによる分散合意をしながらコミットするため更新系もノード数を増やすことで水平スケールするが、分散したデータにアクセスする範囲クエリには弱い。

技術の仕組みを転用して設計に反映できるように

そんな感じで仕組みから理解することが習慣化していくと、ある技術の仕組みが普段の開発の設計に活きてくるようになりました。

例えば、RDBではデータを更新する際に主に以下の手順で処理を踏みます。

  1. 更新内容に対応するトランザクションログをメモリに記録
  2. メモリ(バッファキャッシュ)のデータページを更新する
  3. コミット時にトランザクションログをディスクへフラッシュする
  4. データページは後で都合のよいタイミングでディスクへフラッシュする

この一連の処理にはさまざまな工夫が凝らされています。

  • ログを追記という形で記録することで、シーケンシャルアクセスで高速に永続層に書き込みを行うことができる
  • 永続化されたログさえあれば、状態を復元できるようになるため、クライアントに早期でリターンできる
  • データページを後で記録するディスクはするディスクはログを記録するものより安いディスクを使うことでコストを落とす

これらの考えをアプリケーション開発に転用するとデータ書き込み時は最小限のイベントデータを追記型で高速に記録して、後に参照しやすい形に整形するCQRS+ESのようなものにも行きつきます。

またさらにハイレベルな設計として, イベントブローカへのイベント発行と同一トランザクションでDBにイベントデータを追記することで耐障害性を高める「トランザクショナルアウトボックスパターン」という設計パターンにも源流にはRDBの仕組みに通じるものが感じられます。

このようにミドルウェアの仕組みを知っているからこそ上位のアプリケーション設計に活かせるということが多数あるなと思っています。

AIが台頭してきた現代ではどうか

AIが十分に発達して完全にソフトウェア開発が自動化されるまでは、人間に品質担保を責任が求められると思うので、それまでは品質を判断するうえでのこういった知識は役に立つのではないでしょうか。

勇気を持ってキャリア構築を優先してみる

エンジニアキャリアの最初期のときは、「なんだかキャリア構築を優先するのって純粋な知的好奇心に反する気がして恥ずかしい」「興味の赴くまま開発に没頭する天才エンジニアとは全然違ってダサい」といった感じでネガティブな気持ちになることが多かったです。

ですが、裏を返すと技術のことが何よりも大好きな天才ではない限りは、恥ずかしい気持ちを振り払ってキャリア構築も大事にしてみてもいいのではないでしょうか。