DMM を卒業しました - kawasin73のブログ

初春の令月にして、気淑く風和らぎ、梅は鏡前の粉を披き、蘭は珮後の香を薫らす ¹。どうもかわしんです。新しい元号、令和の 3 日目です。頑張っていきましょう。

さて、去る平成の 31 年 4 月 25 日にインターンしていた DMM を卒業しました。1 年と 11 ヶ月でした。

簡単にいえばこれはその退職エントリーです。

DMM に行くまでの経緯

2017 年の 3 月に起業していた会社を辞めることにし、休学していた大学に復学するまで半年ほど時間があったので新しいインターン先を探していました。

それまでの 2 年間は、 Web フロントエンドや、Rails を使ったバックエンド、iOS アプリ、Android アプリなど主にアプリケーションレイヤーのエンジニアをしていました。

しかし、プログラミング技術のコモディティ化とプログラミング人口の増加する未来に危機感を覚えて ² 、技術力に特化するためにミドルウェアやライブラリを作成するエンジニアインターンを探していました。

そこで、偶然参加した DMM が主催した勉強会の懇親会で当時人事だった星野さんとこの話をお話ししてインターン先を探していることを伝えると、DMM でできるかもしれないということで話が進み、DMM の CTO 室で 6 月からインターンをすることになりました。

どうやら、当時はパブリックにインターンの募集はしていなかったらしく、僕が DMM のエンジニアインターン第一号だったらしいです。

やってたこと

CTO 室では @mah0x211 さんに僕のメンターになっていただき、2 年弱ほとんどつきっきりで僕のメンタリングをしていただきました。

やったことは大きく以下の 3 つです。2 年もいてそこまで大きな成果が出せていないのが恥ずかしいです。

Lua で実装された KVS を Go に移植する

メンターさんが数年前に実装していたハイパフォーマンス KVS を Go に移植することをしました。実装は僕 1 人で行い、レビューや相談をメンターさんにお願いしていました。

ここで、システムコールなど様々な基礎的なプログラミングを学びました。最後のベンチマークを計測したりするあたりが結構辛かったです。

データベースの分散ルータの設計

上で実装した KVS を分散環境で使えるようにするためのルーターの実装と設計を行いました。

途中で設計をやり直して、メンターさんとホワイトボードを使いながら詰めていく形で設計をしていました。しかし、僕の技術力不足で残念ながら設計を最後まで完成させることができませんでした。

ログ転送エージェント

これは、メンターさんがメインで開発しているプロダクトの一部のタスクを僕が調査したり実装したりする形式で進めました。

僕のコードや設計に細かく丁寧にレビューをしていただき、この時が一番成長したと思います。

メンターさんから学んだこと

2年間 @mah0x211 さんにとてもお世話になり、たくさんのことを学びました。

今までの自分のプログラミングはプログラミングではなかった と感じるレベルで成長して変わることができました。

エンジニアリングに対する姿勢

まず、「ないものは自分で作る」という姿勢を学びました。

それまでの僕は、まずライブラリを探してそれを組み合わせてアプリケーションを作るイメージでした。完全に仕様を満たさないものや過多な機能を提供するライブラリであっても、作るアプリの仕様をそのライブラリに合わせて変えるなど工夫して使うようにしていました。仕様がライブラリに依存してしまっていたのです。

そうではなく、もし仕様に合致するライブラリがない場合はそれを自分で作ってプロダクトに組み込む考え方とそれを達成する技術力を学びました。

また、依存ライブラリの増大はその分だけプロダクトの保守性や品質を下げる可能性があります。プロダクトに必要のない機能がライブラリに含まれることで実行環境（実行バイナリや VM の大きさ）の肥大化や低速化に繋がったり、ライブラリのアップデートに追従する労力が発生してしまいます。

そのコストとライブラリを利用することによるメリットのトレードオフを考えてライブラリ利用か自分で実装するかの意思決定をする必要があることを学びました。

次に、「なんとなくで意思決定しない」という当たり前と言えば当たり前な考え方を学びました。

どのライブラリやミドルウェアを採用するかを「周りでよく使われているから」や「今日本で流行っているから」という曖昧な理由で決めるのではなく、ドキュメントを読んだり実際に試したりして調査することの大切さを学びました。

特に、それらの情報は一次情報である公式ドキュメントを当たる必要があり、英語を読む力も（読むのは遅いですが）身につきました。また、ドキュメントだけで理解できない場合はソースコードを読んで理解することを徹底することも学びました。

この姿勢はプログラミングの中でも必要です。外部ライブラリやシステムコールが何を返すのか、発生しうるエラーは何か全て理解した上で実装する必要があります。

特にミドルウェアの実装では、起動されてから数年単位で稼働し続けることが求められ、多少のエラーで異常終了することは許されません。全てのエラーをハンドリングするためには全てのエラーを理解する必要があります。例えば、システムコールのドキュメントとして man page をよく読むようになりました。

プログラミングの基礎

プログラミングではまず「設計が大切」であることを学びました。

大きなプロダクトを作る上では、全てのコンポーネント同士の関係を絵に描いて説明できるレベルまで設計を詰めておく必要があります。絵が複雑になったりする場合はその設計は不十分であることが自然と浮き上がってきます。

実装を始める前に設計をしっかり固めてからでないと手戻りが発生しやすくなってしまいます。

設計は「シンプルな実装を積み上げていく」ことが大切です。

設計では神の目になったつもり大雑把な動きを捉え、その流れに対してデータ構造やアルゴリズムを適用します。最初から複雑に考えるのではなく、一番小さな単位から設計を始めて、それに肉付けしていく形で仕様を満たす設計を作り上げていきます。そのためにも極力シンプルな設計を心がけなければなりません。そのほうがあとで肉付けをしやすくなります。

また、「コンポーネントとビジネスロジックを分離する」ことを意識することも大切です。まず、ビジネスロジックに依存しない足回りとなるコンポーネントを実装し、そのコンポーネントのインターフェイスを組み合わせることでビジネスロジックを組み上げていきます。

コンポーネントがビジネスロジックに依存しないことで、ビジネスロジックの修正はコンポーネントの組み合わせ方を変えるだけで対応でき、コンポーネントの修正は必要なくなるため堅牢なソフトウェアになります。また、汎用化されたコンポーネントはライブラリとして切り出すこともできます。

「データ構造とアルゴリズムは筋肉」です。様々なデータ構造とアルゴリズムを知っていることで最適なデータ構造とアルゴリズムを導入することができ、パフォーマンスの良いミドルウェアを作ることができます。AtCoder で競技プログラミングを始めて勉強するきっかけになりました。

コーディングでは、「読みやすくシンプルなコーディング」の大切さを学びました。関数の中でもサブロジックごとにコードをまとめてコメントをつけることで読みやすくなります。例としては、boltdb の作者である Ben Johnson さんのコードは、サブロジックごとに改行で区切られてコメントが付与されており、とても読みやすいです ³ 。

ドキュメンテーションの基礎

ドキュメンテーションでは「読者が上から下に引っかかりなく読むことができる」ような書き方をする姿勢を学びました。上から読んですっと読者の中に内容が入るための、前提条件や因果関係を上から順番に書いたり、表記を統一してブレないようにしたり、重複しないようにしたり、読者が疑問に思うようなことはその場で補足したりするなどの書き方を学びました。

また、僕のドキュメントの癖として英語を多用してしまう「ルー語病」がありました。英語をなるべく日本語に翻訳して書くように意識するようになりました。

あと僕のブログなどの書き物で、数字や英単語の前後にスペースが空いているのは読みやすくするメンターさんの書き方の影響です。