どんなエンジニアになりたいだろうか

Journal

Main

「どんなエンジニアになりたいだろうか 」

最近、この質問をよく自分に問う。

エンジニアになる前は「職業エンジニアになる」というハッキリとした目標があって、それに応じた小さな具体的な目標・作業内容を設定することができた。

例えば

  • JavaScriptのudemyコースを終わらせること
  • やっていきたい領域の技術を使用したポートフォリオ作品を作ること
  • ブログやレジュメサイトを公開して、自分能力のアピールをすること

これらは、未経験からエンジニアに転職する際のノウハウとしてネットでよく言われていることで、僕はこの手順を踏むことで、実際に転職することができた。

晴れて職業エンジニアになってからも、暫くは具体的な目標が僕の前に置かれているようだった。プロジェクトにアサインされて、タスクを振られても最初の数カ月は上手くこなすことができなかったが、その時もタスクをこなせるようになるためには何をしたらいいのかは明確にわかっていた。 それは先輩エンジニアの作業する姿を見て学ぶことだった。

実際にそうすることで、徐々にチームに貢献出来るようになっていった。今では、自分はある程度戦力に数えられていると思っている。

現状を整理すると、ようするに日々の業務をこなしていく中で少し余裕が出てきたのだと思う。もちろん全てを完璧にできているとは思わないが、最初の頃のような切羽詰まった感じはない。それで、新たな目標を設定したいと思っているのだと思う。

目標にするエンジニア

インターネットにはすごいエンジニアが溢れている。そのなかでも自分が日々そういったツールに助けられているからだろうか「エンジニアのためのエンジニア」に憧れを感じるようになってきている。

例えば、FFmpegの作者のFabrice BellardはQEMUの作者でもあると言うことを知ってびっくりした。どの業界にも「こんな能力のある人がいるのか」と思う人がいるものである。

それから、Reduxの作者のDan Abramovさんもすごいと思う。最近仕事でReduxにお世話になっているし、彼はブログ記事やYoutubeなどのメディアの露出が多いのでインスピレーションをいただいている。

それからGNUプロジェクトのRichard Stallman。最近LinuxのCoreutilにお世話になっている且つ、フリーソフトウェアのために尽力しているのがカッコいいと思う。

「自分がいきなり彼らのようになれるか」と問われればそりゃいきなりは無理な訳で、けと、目標として脳裏にある。 バスケをする少年がNBAの選手に憧れるような気持ちを抱いている。

ユーザーのためのエンジニア

では「優れたユーザーのためのエンジニアになる」といった目標はどうだろうか。それは要するに優れたユーザーのためのソフトウェアをつくる人、ということだろう。

僕はソフトウェアの開発者でもありながら、ソフトウェアのユーザーでもあることを最近はよく意識する。

ブラウザの他に一番お世話になっているGUIソフトウェアはObsidianなので、たとえば、「Obsidianのようなソフトウェアを作る」といった目標はどうだろうか？ この目標のためには、今からでもできることはたくさんあると思う。

ユーザーや、ビジネスを意識した実装は業務のなかでも心がけているつもりだ。

最適なメモリ効率、美しいコードベース、素晴らしいDX…。これらもユーザー、ビジネスに貢献しなければ存在価値は無い。だからといって、めちゃくちゃな実装をすれば、いずれプロジェクトに不具合が起きたりしてユーザーに悪影響をもたらす。

あるプロジェクトでは、予算も納期も余裕があって、最適なコードを書く努力をする余裕もあるが、あるプロジェクトではそんなことは言っていられない、「とにかく早く納品だ！」な時もある。

最近はそんなことをゴチャゴチャよく考える。

どのような経験を積むべきか

「どんなエンジニアになりたいか」と言う問いに対する頭のゴチャつきを少し整理してみた。

今、頭の中にもやっとあるエンジニア像に将来近づくために、これからどんな経験を積むべきだろうか。

とにかく開発の経験がもっと必要だろう。Web、モバイル問わず色々なサービスを開発・運用する経験を積む必要を感じる。優れたサービスとは何か、ソフトウェアを開発・運用すると言うことは、実際どんな行為によって成り立っているのだろうか、と理解する必要があると思う。

もっと設計の経験を積む必要がある。少し引いた、マクロな視点でソフトウェアの開発を見たい。職場のアーキテクトの仕事ぶりを見ていたりすると思う。

もっと色々な多くの優秀な開発者と仕事をしてみたい。プログラミングはYouTubeやテキスト媒体で学べるが、やはり、現場で試行錯誤するエンジニアから「何か」を感じて僕の中に取り組んでいる感じが少しある。問題を解決するプロセスというのは、本当に人によって多種多様だ。だからペアプログラミングは面白い。

以上のことをPaul Grahamの「ハッカーと画家」を読んで考えた。