バックエンド開発に必要な能力の半分以上は言語力以外の部分

ChatGPT時代の戦い方

言語経験年数だけ見るのは間違い

ソフトウェアエンジニアの能力を測る指標としてしばしばプログラミング言語の経験年数が使われることがあります。Perl〇〇年、Go〇〇年というやつですね。

一方で例えばWebフロントエンド開発にHTMLやCSS部分のコーディングが含まれるように、Web開発ではロジックの伴う純粋なプログラミング言語の部分だけでなく、マークアップ言語のようにプログラミング言語以外と戯れている時間も意外と多いものです。

クライアント開発だと分かりやすくデザインとロジックが分離されていてその棲み分けがしやすいのですが、サーバー側ではしばしばそういう視点が忘れられてプログラミング言語力が唯一絶対と誤解されがちな印象があります。

JavaっぽいRubyのコードを見てイラッとしたこともあるので、言語力が重要なのはもちろんそうなのですが、バックエンド開発に必要な能力の半分以上は言語力以外の部分、とりわけミドルウェア力なのではと自分の中である程度整理ができたのでまとめておきます。

SQL力

インターネット回線の高速化によりデスクトップアプリからWebアプリに開発の主軸が移るにつれ、データストアはおおむね1ユーザーだけを考えればいいから複数ユーザーのデータを保存する手法に移行しました。

ユーザーが要求した情報を返す時に、複数ユーザー分データをカジュアルにアプリ層に持ってきてハンドリングするとパフォーマンス上問題になることが多く、極力SQL、クエリー言語の世界で完結させて最小のデータをDB層からアプリ層に送るがバックエンド開発のベストプラクティスの一つです。

プログラミング言語も大事ですがデータベース操作言語も同じくらい大事。

テーブル設計力

Webサービスは24時間稼働が想定されていることも多く、メンテナンスで停止期間ができることは通常歓迎されません。

それがDBの寿命はアプリの寿命より長いと言われがちな部分で一度設計に失敗したテーブル設計は後からリファクタリングが容易でないことも多いです。

RDBでなくNoSQLにすれば簡単になるかというと必ずしもそうではなく、RDBのJOINを実現しようとすると、書き込み時にAxBの組み合わせテーブルを作成しないといけなかったりするので、むしろより事前設計が重要になる場合もあります。

API設計力

Web画面だけの時代からアプリやIoTだったり、複数クライアントから呼ばれるようなバックエンドの場合、データの取得や変更はAPI経由で行われます。

一番よく使われるAPIはRESTのJSON APIかと思いますが、最近はGraphQLだったり、Protocol BuffersでgRPCだったり、サーバー間通信、サーバークライアント間通信の選択肢も増えてきています。

GETのAPIで副作用があるとバグを起こしてしまったり、APIが細かすぎてリクエストが増えて捌ききれない、テーブル直結のAPIを作って変更耐性がなどなどAPIの設計には考慮するポイントがいくつかあります。

キャッシュ設計力

社内システムで限られた人しか使わないだと違うかもしれないですが、たくさんの人が使うシステムの場合、どこかでアプリ層で毎度計算するよりキャッシュを使って複数ユーザーでレスポンス(の一部)を使いまわした方が経済的に合理的になる場面があります。

一方で最近はレコメンドやパーソナライズが一つのキラーフィーチャーになっている場合もあり、個別の最適化と全体のサーバー台数削減のバランスを取るようなキャッシュ設計、戦略を描けるかが大事です。

アプリサーバー外に出すパターンだとRedisかMemcachedがキャッシュストアとして使われることが多い印象。

境界設計力

APIの設計にも通じるのですが、開発人数が増えてくるに連れてモノリスが限界になる会社も出てきており、マイクロサービスだったりモジュラーモノリスだったり、マルチモジュール化を進める会社も増えてきています。

どういう境界分けで名前空間やサーバーを分けるかは一つの技術的チャレンジであり、会社によっては専任のアーキテクトを置いていることもあります。専任がいない場合通常はバックエンド担当者の検討範囲になります。

検索設計力

検索機能は簡単なものならRDBでも実現はできるのですが、パフォーマンス面で問題が起きることも多く、どこかのタイミングで検索専用のデータ構造を事前に作ったデータストアが必要になります。

古くはSolrで最近だとElasticsearch、今後はmeilisearchも選択肢になりうるかなというところ。

こういったドキュメントDBはRDBとは違った設計能力が必要です。

デザイン力

アプリしかやっていない業態でサーバーとクライアントが完全に分離されたシステムもなくはないですが、そういったサービスでも管理画面はWeb画面として作っていたり、バックエンド担当と言っても、フロントエンド部分を何も知らずにできるかというとそうではないですね。

スタートアップだとバックエンドとフロントエンド兼任という場合も多いです。

インフラ力

バックエンドサーバーをホストする環境は古くは会社のオンプレサーバー、次にsshするような名前のついたサーバー、最近だとDockerで管理されたクラスターなんかでしょうか。

専任のインフラ担当がいる組織もありますが、いない場合バックエンド担当が兼任することも多いです。

仕様提案、説明力

ここら辺はバックエンドというよりWeb開発全般ですが、PMが作りたいという機能の技術的に難しい部分を説明したり、時には技術的に簡単だけどやりたいことに近い代案を提示する場面もあります。

To Bのビジネスだと複数PMが必要が持論なのですが、とはいえいない場面ではある程度PMの負荷を減らすために代わりをつとめる場面もあります。

ChatGPT時代は言語力の価値は目減るか

多少間違っている場合もあるのですが、ChatGPTを使うと今まで以上にプログラミング言語の変換は簡単になりました。実際プログラミング言語変換のサービスもちらほら出てきています。

その言語特有の書き方もあるので、ChatGPT時代は言語力の価値は目減るかでいうと高度な部分ではそうならないようには思います。一方で初学者の参入障壁は明確に減ってきて、よりフルスタックになっていくように思います。

最近だとElasticsearchのPerl bindingがサポート終了になったり、機械学習系ならRからPythonに移るトレンドがあったり、今後の言語の流行り廃りによってミドルウェア側がサポート終了になることはありそうです。

一方で例えばRuby 3年の求人にPerl 9年、Ruby 1年の人は不適でしょうか？0年だとつらい、個人開発でもいいので熱量が欲しいという観点は確かにあるのですが、エンジニア経験のない人ほど言語力を過大評価している傾向は感じます。サーバー<=>クライアント間の移動だと確かに難易度のレイヤーが一つ上がりはするのですが、バックエンド開発経験は確かに活きるものがあるなと。