kawasin73のブログ

技術記事とかいろんなことをかくブログです

作る人と使う人

この記事は、PSI(東京大学工学部システム創成学科知能社会システムコース) Advent Calendar 2018 の 25 日目です。

はじめに

この記事は、僕がどんなエンジニアになりたいと思っているのかをつらつらと書くポエムです。

この考えを誰かに押し付けるつもりもありませんし、この考えが完全に正しいと主張している訳でもありません。「こういう考え方もあるんだな」程度に思っていただければ嬉しいです。

ここでのエンジニアは主に Web 系とかのソフトウェアエンジニアとかを想定しています。

作る人と使う人

エンジニアはプロダクトを作ります。そしてユーザーがそのプロダクトを使います。プロダクトには、作る人(エンジニア)と使う人(ユーザー)がいます。

同じようにエンジニアの世界にも作る人と使う人がいます。様々なフレームワークやライブラリを作る人と使う人です。

ライブラリを 作るエンジニア にはライブラリのインターフェイスやライブラリ自体のパフォーマンス、フレームワークの使い方などを洗練させるために高い技術力や経験が必要とされます。

そして、現代の web 系のアプリやサービスは OSS として世の中(github など)に転がっているライブラリやフレームワークを使い、組み合わせて作ることができます。

ライブラリを 使うエンジニア はライブラリやフレームワークの使い方をドキュメントなどで理解して、ライブラリ同士をつなぎ合わせるコードを書くだけでアプリやサービスが出来上がります。

そう、アプリケーションを作るのはとても簡単になってきています。それはエンジニアがより楽をしようとする生き物で、開発を楽にするライブラリやフレームワークをどんどん開発しているからです。

それによってアプリケーションを作るエンジニアには技術力はだんだんと必要とされなくなってきています。例えば、RailsWebサービスを作る上では TCP ソケットがどのように扱われているかや、Ruby ではどのようにメモリが管理されているかを気にしなくても動くアプリケーションが作れます。大学でコンピュータサイエンスを学ばなくても誰でもエンジニアになることができるようになってきました。

その一方でライブラリを 使うエンジニア にはライブラリをうまく使ってユーザーにとっての価値を創出する、ビジネス力や UX などのデザイン力が重要になってきていると思います。

これはとても素晴らしいことだと思います。誰でも自分の作りたい物を簡単に作れるようになるのは人類の生産性や創造性を向上させます。これからロボットや AI が発展していき人間が事務作業から解放された時に、自由になった時間を使って行う創造的活動を支える土台となります。

決して、作るエンジニア使うエンジニア より偉いと言っている訳ではありません。それぞれの役割が異なるだけです。作るエンジニアはエンジニアを相手にして高い生産性をもたらします。使うエンジニア は一般的なユーザーを相手にして新しいビジネス価値を生み出します。

そして、作る人と使う人は 0:100 で完全に別れている訳ではありません。使うエンジニアは、自分に必要な機能を持ったライブラリがない場合は自分でそのライブラリを作ればいいですし、作るエンジニア は、使うエンジニアがどのようにそのライブラリを使うかを知る必要があります。両方の役割を持ったエンジニアが多いのではないでしょうか。

使うだけのエンジニアでいいのか

しかし、使うだけで作ることができないエンジニアでは作ることのできるアプリケーションが限られてきます。

一般的なアプリケーションを作る上では世の中に転がっている OSS を組み合わせるだけでアプリを作ることはできるので、困ることは少ないと思います。

ただし、作りたいアプリケーションの要求を満たすライブラリがなかった時に、ライブラリを作ることができないエンジニアはそのアプリケーションを作ることを断念することになります。

技術が要因で作れたかもしれないアプリを作れなくなってしまうことはとても悔しいことです。

2 年前は僕は 使うだけのエンジニア でした。Rails サービス・iOS アプリ・Android アプリの開発、Docker を使った開発環境の構築、Terraform での AWS クラウド環境の構築など、一人前とは言いませんがフルスタックエンジニアとして自信を持っていました。

しかし、それらは全て既存のライブラリやフレームワークを使って何かを作るエンジニアで、作りたいアプリに必要なライブラリがない場合にはそのアプリは作れませんでした。

自分のその状況に危機感を抱いて、DMM にミドルウェアを作るインターンにいきました。DMM にきて早 1 年と半年が過ぎ全然成果が出せていなくて苦しんでいますが、インターンではデータベースを作ったり、分散システムの設計をさせてもらっています。

作るエンジニアになるために

使うだけのエンジニア から 作ることもできるエンジニア になるために、何かライブラリを作りたくなりますがどんなライブラリを作ればいいのでしょうか?作っても使われるとは限らないですし。

それは 自分が必要なアプリを作ってそのアプリに必要なライブラリを作る ということだと思います。

自分に必要なアプリとそれに必要なライブラリを作ることでモチベーションを保ち続けることができます。また、自分がそのライブラリのユーザーになるので使いやすいインターフェイスを自分で実験しながら試行錯誤することができます。

自分のアプリに必要なライブラリがすでにある場合はそのライブラリを無条件で採用するのではなく、その 中身をよく読んでみてパフォーマンスや使いやすさなどに課題がないかどうかを検証してみる のがいいと思います。もし、何かの課題があれば自分でより良いライブラリを作ることができます。既存のライブラリのソースコードを参考に作ることができるので障壁も低いです。

世の中にあるものだけで作るのではなく、世の中に足りないものがあったら作って利用する という姿勢が作るエンジニアになるためにはいいと思います。

僕の場合は、彼女が薬を飲むのを忘れないように Go 言語でリマインダー LINE bot の「管理上手のうさちゃん」を作りました。(詳しくは以下の記事で紹介しています)

qiita.com

この LINE bot を作る上で Go 言語のスケジューラが必要になり、既存の github スター数の多い Go のスケジューラライブラリ 3 つのソースコードを読みました。

その結果、それぞれのライブラリにパフォーマンス上の課題があることに気づき、それを解決する新しいスケジューラライブラリ /kawasin73/htask を作りました。(詳しくは以下の記事で紹介しています)

qiita.com

また、管理上手のうさちゃんを動的 IP 割り当てをされる自宅サーバーで運用するために、wanpoll という DNS の自動登録エージェントを作成しました。

qiita.com

このような感じで、必要だけど世の中にないから諦めるのではなく作ってみるという姿勢がいいと思います。

自分の目指すエンジニア像

この1年半ずっとミドルウェアなど、アプリケーションから離れた物を作ったり設計したりしてきました。この経験を通じて思ったのは、やっぱりユーザーが近いプロダクトを作るのが楽しいということです。

ハードウェアやコンパイラ、言語そのものの開発などの低レイヤーというよりは、それを具体的に誰かが使って価値を感じてもらえるアプリケーションに近いレイヤーのエンジニアが僕は楽しいと思えるようになりました。

アプリケーションを作る上で必要なライブラリやミドルウェアがない場合は、自分でそれを作ることが選択できるエンジニアになりたいです。

既存のライブラリに縛られることなく、自分の手でパフォーマンスと UX を追求していける、世の中にあるものだけで作るのではなく、世の中に足りないものがあったら作って利用する、そんなエンジニアが僕の理想像です。

参考