ソフトウェアエンジニアとしての苦悩
落ちていく人は、自分が底を打つのを感じることも、その音を聞くことも許されない。
とても多くの人が今、君がしているのとちょうど同じように思い悩んできた。それを知ることによって君は勇気を掻き立てられるだろう。そのうちの何人かはその事に関する記録を残してきた。君もいつか同じように記録を残すかもしれない。それは美しくも互恵的な仕組みなんだよ。
2022年を振り返ると、この一年はエンジニアとしての『劣等感との戦い』の日々でした。
今回は、そんな一年の振り返りと新しい年の抱負を書かせてください。
できるたけ読んで価値のあるものを提供しようと思ったのですが、どうしても個人的な内容が多くなってしまっております。その点はご容赦いただきつつ読んでいただけると幸いです🙇♂️
引用の箇所は全てジェローム・デイヴィッド・サリンジャーの「ライ麦畑でつかまえて」(以下、ライ麦)からです。大学時代は文学部で西洋文学の研究をしており、思い入れのある作品なのでついつい引きたくなってしまいました。これは一人の青年が、自分が底を打つのを感じることも、その音を聞くことも許されない物語です。
ソフトウェアエンジニアとしての苦悩
最近までフロントエンドの技術を主な武器としてエンジニアをやってきました。
jQueryやVueを得意としていて、Reactなんかも少しだけ触れます。
Web制作を2年ほど、Web開発を2年ほど経験してきました。
しかし、兼ねてよりバックエンドの方にもスキルの幅を広げていきたいと考えており、昨年から、
「フルスタック」とまではいかなくても、FE/BE両方できるエンジニアになろうというチャレンジをしました。プロダクトの価値を迅速に上げていこうと思うなら、やはり両方ができた方がチームとしてスピードが上がります。
とはいえ、そう簡単に、おいそれとバックエンドもできるようにはなりませんでした。
そんな中、フロントエンドに精通していて、かつバックエンドのスキルも高く、さらに設計もできるメンバーもいます。そういう仲間が割と自分と同年代だったりすると、ちょっと比較してしまい時々凹んだりもすることってないでしょうか。「他人と比較しない」って言うには易しですが、なかなか実行するには難しいものです。慰めばかりの精神論で乗り越えられるような安い話ではなく、「でもそれが違うんだな。ちゃんと気になるんだよ。」ということです。
要するにね、誰かのスーツケースより君のスーツケースの方が数段上等だっていうような場合、
その相手と部屋を共にするのはかなりきついことなんだ。
君のスーツケースがすごい高級品で、相手のがそうじゃないというようなときにはね。
相手が知性のあるやつで、ユーモアのセンスを持ち合わせていたら、どっちのスーツケースが高級品かなんて、気にもしないだろうと君は考えるもしれない。
でもそれが違うんだな。ちゃんと気になるんだよ。
また、逆に自分のスーツケースが誰かのスーツケースよりとりわけ貧相なものだった場合には、必死に喰らいついていくしかないのかもしれません。
一体何食ったらそんなんになれんねやろうか。まるで鹿児島城西高校に敗れた滝川第二高校の控室のようにやるせない心持ちになるかもしれません。
そういうときに心に効く名言があるとすれば、それはLINEのエンジニアリングマネージャーの花谷(@potato4d)さんが仰っていた「常時、筋肉痛くらいがちょうどいい」という言葉です。
トレーニング理論には詳しくないのですが、「筋肉痛」という痛みは、トレーニングの結果、筋肉が傷つき肥大しつつあることの証だと思います。同じように、プログラミングの「うわー、むじー、わからん、つれー」という痛みも、スキルアップ中であることの証左だと言えるかもしれません。
つまり、なんというか、劣等感もある種、筋肉痛のようなものだと考えられなくもないわけです。周囲と比べて自分のスキルが及ばないという環境は、そこで奮起することさえできれば、成長のためにうってつけの環境だということもできそうです。
というわけで、ここ一年は「ここで折れるか、戦うか」という状況でした。
具体的に振り返っていきます。
Kotlinとの邂逅
昨年はServer-Side Kotlinを実務で書くという経験をしました。JavaもKotlinも今まで書いたことがなく、そもそもバックエンド自体、からっきしやったことがありませんでした。
Server-Side Kotlinといえば、先日、Ubieさんのこんな記事が話題になりました。
今後のプロジェクトではKotlinの採用をやめるという内容の記事です。
Why Go?
言語設計的に書き手によるブレが少なく、可読性が高いです。これはフロントエンドをやってきたエンジニアがバックエンドも触るUbieの環境と相性が良いです。
という部分が、個人的に共感ポイントでした。Server-Side KotlinはGoと比べて言語仕様が多いというか、覚えるのが難しいといってもいいかもしれません。やはりシンプルさという面で見るとGoは素晴らし言語です。自分もEffective Kotlinという本を読んだり、kotlinのアプリを作ってみるなどしましたが、すぐには上手く書けるようにならないものですね。
しかし、だんだん慣れてくると、Kotlinの良さもわかってきました。
まず、ちょっとTypeScriptと似ている部分があります。このような比較表を眺めていると、なんとなく文法が近いような気がしてきませんか。「あ、これTypeScriptでいうと、あれだな💡」という知識の紐付けができる瞬間があると、Kotlinの理解への道が開けてきます。
Kotlinについては、もう一つ個人的に気に入っている部分があります。ドメイン駆動設計に関する本がKotlin(やJava)で書かれていることが多く、DDDの理解の助けになるという面です。と言いながらも、DDDを理解するのに非常に苦労しているのですが。（これについては後述します）
結局、喉もと過ぎては熱さ忘るる、ではないですが、今となっては、Server-Side Kotlin大好きです。フロントエンドに慣れている人だと、for文でループを回さずmapなどが使える点も嬉しいですね。
SQLとの格闘
Server-Side Kotlinをマスターした後、SQLという次なる壁が目の前に立ちはだかりました。「いやSQLくらい余裕っしょ」みたいに思われるかもしれませんが、恥ずかしながらINNER JOINとLEFT JOINの違いもわからぬ人間でしたので、「ぐぬうぅぅぅぅ...」と思いながら必死にキャッチアップしました。
まずはSQL 第2版 ゼロからはじめるデータベース操作という入門向けの本を読みました。
ですが、弊社が作っているシステムは複雑なロジックを含むものなので、シンプルなSQLが書けるだけでは全く歯が立ちませんでした。サブクエリ、ウィンドウ関数、その他諸々含めて、しっかりマスターしておく必要がおかなけばなりません。そこで、達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへという本を読みました。初級から上級への橋渡しとしては最適な一冊でした。
まとめると、SQLの習得にもServer-Side Kotlinと同じくらい苦労しました。クソ雑魚タンバリンシャンシャンです。だがいつかは、SQLの実行計画なんかが読めるたりしたいシャンシャンです。
戦いはまだ続きます。
DDDとの鏖戦
遂にServer-Side KotlinもSQLも「よしなんとなく分かってきた」という手応えを感じたそんな初秋、遅ればせながら、そろそろモンスターハンターサンブレイクを買いたいと思っておりました。そんな矢先、ドメイン駆動設計と相対する運びとなりました。
専らにフロントエンドをやってきた自分には、DDDは難易度高く、つまりサンブレイクでいうところのゴア・マガラのような存在です。
まずドメイン駆動設計 モデリング/実装ガイドという本を手に取りました。これはおそらくDDDの入門書としては最良のもので、特にレイヤードアーキテクチャ・ヘキサゴナルアーキテクチャ・オニオンアーキテクチャ・クリーンアーキテクチャがそれぞれどんなもので、何を採用するのが良いのか、ということに関する説明は最高にわかりやすいです。おすすめです。
「そもそもDDDの何がおいしいの？」という部分が腑に落ちない場合は、セキュア・バイ・デザインという本も良いです。
この本を読むまでは、次のようなモヤモヤもありました。ネット上で見聞きした情報によると、
- ドメインモデルとデータモデルは分けて考える必要がある
- ドメインモデルはシステムを図式化したものでない(ドメインモデル＝モデル図ではない)
であるらしい。そこで、
...いや、じゃあなんやねん！！と。
表でも図でもないとしたら、ドメインモデルという言葉を聞いたとき、我々一体何をイメージしたらいいのでしょうか。
セキュア・バイ・デザインという本は、この疑問を、「ドメインモデルは鉄道模型のようなものだ」と例えることで非常にわかりやすく解説してくれます。
この本によれば、対象となる事業領域を解決するために必要な要素を取捨選択し、抽出したものがドメインモデルであり、ドメイン図はそれを表現するための一つの手段です。鉄道模型は、鉄道ファンが眺めて楽しむために、見た目という要は抽出していますが、大きさや重さといった要素は切り捨てています。その他色々と例え方、説明の仕方がうまい一冊で、エヴァンス本の難しさに挫けそうになった方におすすめです。
また、DDDの旨味というのも、この本でなんとなく理解できました。それは、システムが堅牢で、変更容易なものになるというところです。そして、もしシステムが変更が容易なものであれば、機能追加に必要な時間も減ります。そうすると、たとえ後発のプロダクトであったとしても、競合を追い抜くことができるかも知れません。結局、それはプロダクトの価値と競争力になります。やはり、DDDはとてもおいしい話です。
おいしい話なのですが、意味やメリットを理解したとしても、それをすぐに実行に移せるかというのはまた別の話です。故に、まだ克服できていないというか、渾沌に呻きながら苦労している状態でして、無限列車編の炭治郎のように、またすぐ目の前に分厚い壁があることを悔しガラずにはいられないマガラです。
2023年の抱負
駆け足で振り返るなどと言いながら、まぁまぁのボリュームになってしまいましたが、
まとめると、2023年の目標はシャガルマガラ、つまりは「設計力を身につけたい」です。
補足
以上が、エンジニアとして、きっとこうあるべきだろう、こういう記事を書くべきだろう、と思って考えた内容になります。ここで終わっておけばそれなりに良い記事になるかもしれませんでした。
ですが、冷静に改めて文章に起こし、客観的に眺めてみると、これは本当のところ本心ではないことに気づきました。以下、補足というか、蛇足であり、本題でもあります。
人は、焼肉で癒せないほどの痛みを抱えるべきではない
まず、自分は「そこまで頑張って技術を極めたい」と思っていなかったということです。口に出すのは控えていても、心の隅にはそんな感情がある方も、ひょっとしたら少なくないんじゃないでしょうか。
願望の二面性ということについて、ライ麦には、
弁護士も悪くないと思う、でもさ、あんまりぴんとこないんだ。
弁護士がいつもいつも無実の生命を救ってまわって、しかも、やりたくてそれをやっているんだったらそれも悪くない。
でも、そう人ってたぶん、いつの間にか、わからなくなっちゃうんじゃないかな、
自分がそうしたくてやっているのか、それともただ周りからすごい人だと思われたくてやっているだけなのか。
自分がインチキ人間かどうかなんて、自分じゃなかなかわからないものなんだ。
困ったことには、そいつはとことんわかりにくいんだよ。
というくだりがあるのですが、これはエンジニアにも通じる部分を感じます。
この引用は決して、承認欲求は否定すべきだとか、周りの目を気にするなとかいう、ありがちな話をしているのではありません。
人間は本質的に集団の中に自分のポジションを築いて、安心したいと思うものです。エンジニア界隈に当てはめるなら、スキルは我々の心の安寧にとって欠かせないものだといえます。
「人間は誰でも不安や恐怖を克服して安心を得るために生きる」
「そこでだポルナレフ、技術をつきつめることに一体何の不安がある...?」
というやつです。
ですが、不安に駆られながら生きるというのもいかがなものでしょう。
考えたいのは、自分の技術をひたすらに磨こうとすること、それは本当に純粋なる自分自身の願望なのか、あるいはただの「肉の芽」なのかです。
それが自分自身にさえわからなくなるとき、倦んで、何もする気が起きないような状態になってしまうのかもしれません。これでは筋肉痛というより、むしろただの肉離れです。
また、世の中には、子供のときから生粋のプログラミングキッズだった人もいます。子どもが外で鬼ごっこやドッジボールをしたりするような感覚で、プログラミングを趣味として生きてきた人です。「三度の飯よりプログラミングが好き」という人です。
そういう「超絶プログラマー」って、界隈の中だととてもリスペクトされるお手本のようなものなのです。だから、ついつい、自らを彼らと同一視したくなる願望がエンジニアの中にあるのではないでしょうか。しかし、そうではない人が「I am 超絶プログラマー👍」と、自分自身に対しても偽ってしまうのは、危険なものです。自分の人生を見失ってしまうかもしれません。
大半の人にとっては、三度の飯よりプログラミングが好きというのはきっと嘘になります。ほとんどの人は、プログラミングがちょっと好きだとしても、焼肉の方がプログラミングよりはるかに好きなはずです。
もし、プログラミングと焼肉の二択を迫られたら、私は両手をあげて焼肉を選びます。
ところで、 人は、焼肉で癒せないほどの痛みを抱えるべきではない、そんな名言があった気がします。なのに不思議と、焼肉では癒えない悲しみを、プログラミングから得ることもあります。それって、実は本末転倒で、ひょっとしたらくだらないことなのかもしれません。
落ち込んだときは、焼肉とプログラミング、どっちが大事なのか考えてみてください。これはちょっとしたハックです。
競うな 持ち味をイカせッッ ...?
また、取り止めもなく話は変わるのですが、
「自分ってエンジニアに向いてないんじゃないだろうか」
などと悩んだことはないでしょうか。
例えば、"HUNTER & HUNTER"という漫画に水見式ってありますよね。恐ろしく早い手刀を見逃さない人についてしか知らない方のために、一応説明しておきます。水見式というのは、水の入ったグラスに念をこめることで、自分の念能力の系統が分かるという鑑別方法です。
その念能力の系統というのは、
「強化系」
「放出系」
「操作系」
「特質系」
「具現化系」
「変化系」
の６つに分かれるのですが、何系を得意とするかは、生まれ持ったその人の性質によって決まっています。
もし、生まれもった性質が「強化系」であれば、「強化系」の念能力を習得しやすくなります。逆に「操作系」「具現化系」のような「強化系」から遠い系統の念能力は習得しにくくなります。「強化系」のカストロが「操作系」と「具現化系」の複合技である『虎咬拳』でヒソカに挑むも、あえなく敗北してしまうシーンはあまりにも有名です。
己は念能力の系統が「エンジニア系」でないのに「エンジニア」をやってしまっているのでは...?
などと、そういう懸念を抱いたことはないでしょうか。
もう一つの例として挙げられそうなのは、武勇伝というリズムネタで有名な"オリエンタルラジオ"というお笑いコンビです。彼らは武勇伝でバズった後、リズムネタだけだと芸人からは評価されないので得意ではない漫才にも挑むのですが、7年かけてようやく辿り着いたのは「ただのそこそこ面白いだけの漫才」だったそうです。結果的には、武勇伝ではあんなにヒットしたのに、漫才ではほとんど誰も彼らのことを知りません。
いや決して、「努力しても無駄」なんて言いたいわけじゃないです。勘違いしないでください。努力すれば、きっと大抵のことはできるようになるでしょう。ただ、芽が出やすい領域と、芽が出にくい領域というのがあるのではないかと思います。蛙の子は蛙以外にもなれるでしょうが、それは蛙になるよりはるかに難しいことで、向き不向きの存在は否定できません。
じゃあ得意な領域で勝負すべきかというと、話はそんなに単純でもありません。得意領域で勝負したからといって、必ずしもうまくいくとは限らないので、ここが本当に難しいところです。
自分の場合だと、西洋文学の修士を修めているので、英語と文学についてはめっぽう得意です。
「だったら英語や文学を職にしたらいいじゃないか」
「エンジニアなんてやってるのはただの虎咬拳ではないか」
そう考えることもできます。
しかし、そこに絡んでくるのは、需要と供給の問題です。文芸翻訳なんて特に、やりたい人が多いわりに、需要は大してありません。頑張っても、せいぜい400万円です。それに対して、エンジニアはその需要の高さに対して、供給が低く、よって高い年収を獲得するのが比較的に容易です。
そんなわけで、たぶん別の道を選んでいたら、今よりずっと年収は低かっただろうと思います。
「情熱を追え」と言うのは簡単ですが、実際、危険な考え方でもあります。夢を見て飛び出したバンドマンのうち、一体何人が武道館に立てるんでしょう。東京藝術大学を出た人のうち、一体何人が岡本太郎になれるんでしょう。「好きなこと」や「得意なこと」を追うとき、同時に需要と供給のことも考えないと食ってはいけません。
好きをつきつめること、そして、それがお金になるかどうか。だからこれは悩ましい選択です。どの道に進むべきか、答えはありませんが、一つだけ確かなことは、超絶プログラマーには、念系統が「エンジニア系」でない人間は一生かかっても追いつけないということです。
これはあながち、絶望ばかりでもありません。なぜなら、こうして私が今、この記事を書いているのも、夢と現実の間にある行為です。
いつだって僕らは、休む間も無く、彷徨った
それで、超絶プログラマーを目指したところでなれないことを悟ってしまうと、エンジニアとして生きていくことに嫌気がさすこともあるかもしれません。実際、ほどほどにエンジニアをやっていく、そういう道もありなのではないでしょうか。
ゆるくエンジニアをやっていくことに関して、そういえば、先日、こんな記事がバズっていました。
「気楽にエンジニアをやりながら喫茶店を営んでいる」という記事です。
こういうの正直、憧れてしまいます。
おいしいコーヒーを淹れて、鼻歌、上機嫌の開発、疲れたらコーヒーを飲んで、鼻歌、上機嫌の開発。
でも、この記事がこれだけバスっているということは、みなどこかに同じような願望があるのかもしれません。口に出すのは躊躇われるけど、
「本当はもっとゆるく生きていきたい。」
「人生を楽しみながら、ほどほどにエンジニアリングも楽しみたい。」
そういう気持ちってないでしょうか。
それは一概に悪いこととも言えません。人生のための仕事です。仕事のための人生ではありません。働くために生きているのではなく、生きるために働いていたいものです。だから、もっと肩の力を抜いて開発することを提案してみたいです。技術書なんてものは、気が向いたとき読むでも悪くありません。
エンジニアとしてあるまじきことを書いているのは重々承知ですが、「こうでなくてはならない」という枠組みは特に、充実したエンジニアリングライフを送ろうとするとき、返って邪魔になってしまうものです。「ゆとり」を持たせる、「遊び」を確保する、ということは意識しておいても決して損にはならないでしょう。
メンタルに関していえば、ワーキングハードな方向へのエントロピーは常に高いということを警戒しておかなければなりません。この界隈、10xだとか、KPIだとか、売上を今年中に3倍にするぞだとか、なんだか知らないですけど盛り上がっていて、やたらプレッシャーをかけられたりします。リリースには間に合わせなくちゃいけないし、遅れそうだからずらしてください、なんてそう易々と口には出せません。
周りが頑張っているのだから、自分も頑張らないと評価されないし、居心地も悪くなります。だから普通に生きていると、やたら残業しちゃったり、勝手にワーキングハードな方へと向かいます。これはリンゴが下へ落ちるように、自然な物理法則です。
でもだからこそ、TO BE, or not to be。ではないですが、重力に抗って生きるのか、ただ重力に負けただけの人生を生きるのか、結局のところ、それが問題なんじゃないでしょうか。
I'd like to be a coffee maker in the lie and all.
ここから先は、完全に余談なのですが、さっきからやたら引用しているライ麦には「一曲の中でたった二回しか楽器を叩かないティンパニー奏者のことが大好きだ」というセリフがあります。
こんなすごい打楽器奏者はちょっといないね。
一曲全体の中で彼がティンパニーを叩くのはたった二回くらいのものなんだ。
彼によると、誰もその奏者のことなんて見てないのに、一時間以上も続く曲の間中ずっと気を張っていて、とりわけティンパニーを叩くときになったら、しっかりナーバスな表情になるのが良いそうです。
ティンパニー奏者が曲の中でずっと集中していられる理由が、もし観客のためでないとしたら誰のためだろう、というのは文学的に興味深いテーマですが、それは置いといて、ここでは最後に『エンジニアのティンパニー奏者風生存戦略』というものを紹介します。
つまり、もし超絶プログラマーになれないとしたら、ティンパニー奏者になることを一度検討して見てはどうだろうということです。たった2回を叩くティンパニー奏者は、その楽団において中心的な役割を担うメンバーではありません。でも、たった2回のティンパニーがなければ、その曲が成立しないのもまた確かです。
わかりづらい例えですが、超絶プログラマーでない人間は、自分なりのバリューの発揮の仕方を必死に模索するしかありません。そのチームの中におけるティンパニー奏者的な振る舞い、すなわち目立たないけれど役に立つことは何かないだろうかと、一考してみる価値があります。
ここで開発チームを交響楽団に例えていることには、もちろん無理があります。FE/BEの両方ができることは価値がありますが、ヴァイオリンとチェロの両方が弾けることにはあまり価値がありません。
しかし、開発チームというものも、ある種、様々な個性のアンサンブルで成り立っています。その人にはその人にしかできないバリューの発揮の仕方があり、それが全体の生産性に対して”微妙なる化学反応"を与えます。ここで"微妙なる化学反応”というのは、我々がつい見失ってしまう「単純な技術力には還元しきれないバリュー」です。「別に大して技術力は高くないんだけど、なんとなく、このメンバーにはどうしてもいてほしい」、そんな人に会ったことってないでしょうか。思い起こせば、開発チームは実に多様な音によって成り立っています。
- アジャイル開発に関する知見が深く、チームイベントを良い方向に導いてくれる人
- 経験とキャリアの深さに裏打ちされた高い危機察知能力によって、チームに迫るピンチを事前に警告してくれる人
- 開発でありながらデザインにも知見があり、UIの妥協を許さない人
- 定期的に飲み会を開いたりランチに誘ったり、チームのコミュニケーションを活性化してくれる人
- 八方塞がりな状況でも決して腐ることなく考え抜ける、異常な突破力がある人
などなど。
そして、エンジニアが劣等感に苛まれたときというのは、「技術力」、「技術力」ばかりが頭に溢れて、そうした"微妙なる化学反応"の全てを忘れてしまいます。特に、「超絶プログラマー」への憧れをまだ捨てきれないのであれば、技術力以外の微妙なバリューついて考えることは、ただの「妥協」意外の何ものでもなく、気の進まないことかもしれません。しかし、開発はアンサンブルです。エンジニアに必要なのは、技術力ばかりではありません。
だから、エンジニアが本当に気にかけるべき関心事というのは"to shoot for some kind of perfection, and on his own terms, not anyone else's(Franny and Zooey)"であり、超絶プログラマーへの凝り固まった理想像を追いかけることでも、人に押し付けられた自分の役割を守ることでもありません。その人には決してなれないエンジニアの形があるということは、同時に、その人にしか決してなれないエンジニアとしての形もどこかに存在するということです。そう考えると、我々がなすべきことはその鋳型を見つけ、掘り起こし、形を顕にすることではないでしょうか。
"on his own terms"というこの一事が重要です。ニーチェ風にいうなら、「世界には君以外には誰も歩むことのできない唯一の道がある。それがどこへ続くのかと問うてはならないが、その道をただ進め」ということになるかもしれません。そう意味ではヴァイオリニストになれなかったとしても、ティンパニーの奏者になることには十分価値があるといえそうです。
長くなりましたが、今までの話はTO BE, or not to be。コーヒーメイカーになるか、ティンパニーの奏者になるか、それが問題だ。つまりそんな話だったのです。あるいはその両方という可能性もまた、あるのかもしれません。
ということで、改めて、なんだかとりとめのないエッセイになってしまいましたが、最後まで、お付き合いいただきありがとうございました。
Discussion