新卒3年目のエンジニアが捉えた「技術の文脈」について

第一事業部ソフトウェアエンジニアのyashiheiです。新卒入社3年目として何か書けることが無いかなと思案したのですが、最近考えることが多い「技術の文脈」について書いてみようと思います。

文脈を意識するようになった

入社した頃と、今を比較して、色々と見えるものが増えてきて仕事も面白くなってきたと感じるようになりました。その一因として技術の表面だけを捉えるのでは無く、この技術はどうして誕生したのか？何を解決したかったのか？といった文脈に着目するようになったのが大きいと考えてます。

私達ソフトウェアエンジニアは普段から多くの技術に触れていますが、その多くの技術はある日脈絡も無しにいきなり誕生した訳では無いのです。何かしらの問題認識があり、それを解決したかった作者の想いがあります。そこを汲み取って、私達の問題解決に使えるか検討する必要があります。

そう考えるように至ったきっかけを振り返ってみます。

1年目のWebAPI開発

今思えばとてもいい経験だったのですが、Webに関する経験がほぼ無い状態で、1年目にRuby on Railsで作られたWebAPIの開発チームに参加しました。

これは結構、思ったよりも大変なことで、とにかく新たに触れる技術が多かったです。そもそもSQLから分からないのでORMが何吐いてるのか良くわからないし、RubyはC++/C#をメインに触ってた人にはとても奇妙だし、Railsも独自の哲学があるし…、と学びが一杯あって楽しいっちゃ楽しいですが、正直追いきれてなかったところもあったと思います。

何故追いきれてなかったということを振り返ると、やはり文脈となる知識の欠如があるのかなと思ってます。Web周辺技術に慣れ親しんでからのRailsと、いきなりのRailsだと見える世界が全然違う筈です。

Railsには強い思想があってそれに基づいた設計が成されています。でも初学者はそれに中々気づけないのですよね。初めてのフルスタックWebフレームワークがRailsなので、客観的に眺めることが難しいのです。

こうした状態だと、表面しか見えてないので型を守ることしか出来ないです。プロジェクトの既存の構成を見て、とりあえずこう組めば問題無いなと。それが何故そういった形をしてるか、こうしたら良いのではという応用が一切利かないです。

アーキテクチャに振り回される日々

2年目に入る少し前から、プロジェクトを異動することとなり、今度はクライアントエンジニアとして頑張ることになりました。

そのプロジェクトではClean Architectureを採用してました。とにかくやたらレイヤーを区切ってて一つの機能を仕上げるのにもファイルを幾つも幾つも作って一苦労という印象でした。

当時の自分はアーキテクチャに関する知識が乏しかったので、これはこういうものなのだと受け止めて、型を守ることだけを考えて、コードを書いてました。

ただ、一方でこれは何処かおかしいぞという疑問がふつふつと湧いてきました。なので、DDDやアーキテクチャについての本やブログを読んだり、先輩と既存のアーキテクチャに関して議論するといった学習を通して、理解を深めていきます。

このあたりで、型をただただ守ることが危ういことに気付く訳ですね。私達が作ってるものに今の設計は合ってるのか？と。設計の文脈を読み解いて今の状況に応じてオーダーメイドする必要があるのではと。

守破離

状況に応じたオーダーメイド。つまりこれは「守破離」の「破」に繋がるところだと思います。

• 「守」…忠実に既存の型を学ぶ
• 「破」…状況に応じて既存の型に自分なりの答えを加えていく
• 「離」…新たなオリジナルの型を作る

最初は型を守ることで精一杯なのですが、それだけでは応用が利かなくて立ち行かなくなる。文脈を捉えた上で、状況に応じた自分なりの答えを加えていくのが「破」や「離」に繋がるのかなと。

どうやったら文脈を捉えられるか

公式のチュートリアルやら、やってみた系の記事で技術の表面だけなら直ぐに分かります。

ただ「技術の文脈」や思想といったものは意識して追いかける必要があるのかなと思います。会社だと身近に詳しい人が居て、それだけで勉強になりますね。

• 一次ソースを捉える
• コミュニティをウォッチする
• 身近に達人が居たら、達人の話に耳を傾ける

例を上げると、RailsだったらDHHの声(※1)に耳を傾けてみたり、普段触ってる言語のproposal(※2)に目を通してみたり、Clean Architectureだったらボブおじさん(※3)の書いた本(※4)を読んでみるとか、そうやってより源流に近いところに喰らいついて行く必要があるのかなと思いました。

最後に

まだまだ道半ばですが、技術にただ振り回されるのでは無く、文脈を捉えた上で「破」や「離」に到達出来るようなソフトウェアエンジニアを目指したいです。

※1: https://rubyonrails.org/doctrine
※2: C#だとhttps://github.com/dotnet/csharplang/tree/main/proposals
※3: https://twitter.com/unclebobmartin
※4: https://www.amazon.co.jp/dp/B07FSBHS2V