フリーランスのフロントエンドエンジニアとして10年目になります。
ここ3年ほどはWebアプリケーション開発を軸にしていて、その中でフロントエンドからバックエンドへ、少しずつ担当範囲を広げてきました。API連携を書くようになり、DBの設計変更にも手を出すようになりました。
ただ、広がり方には偏りがありました。バックエンドのコードは書けるようになったのに、DB設計とインフラはほとんど伸びませんでした。
最初は自分の勉強不足だと思っていました。でも振り返ってみると、伸びた領域と伸びなかった領域を分けていたのは、学習時間でも教材でもありませんでした。
レビューする人に、そこまで踏み込む時間があったかどうかでした。
これは個人の努力の話ではなく、業務委託中心のチームが持つ構造の話だと思っています。
フロントからバックエンドへ染み出せた
まず、うまくいった側の話から書きます。
私のキャリアはWebサイト制作から始まりました。HTMLとCSSを書き、WordPressを触り、コーポレートサイトやLPを作る仕事です。
途中でWebアプリケーション開発に携わる機会に恵まれ、Next.jsやTypeScriptを使う案件が増えていきました。最初はフロントエンドの実装だけを担当していましたが、進めるうちに範囲が広がります。
APIのレスポンス形式について意見を求められる。既存のエンドポイントでは足りないので、自分で追加する。データの持ち方を変えたほうが良さそうなので、DBのカラムを増やす。
意図的にバックエンドへ進出しようとしたわけではありません。案件の中で必要になって手を伸ばした結果です。ただ結果として、フロントエンドだけを書いていた頃より対応できる範囲は確実に広がりました。
染み出せたのは、レビューがあったから
なぜ広げられたのか。振り返ると答えははっきりしています。
同じ案件に、バックエンドの業務委託エンジニアがいたからです。
自分が書いたコードに指摘をもらえました。この書き方だと後で困る、この処理はここに置いたほうがいい、この分岐は不要になる。
書く、指摘を受ける、直す。このループが回っていたから、実務レベルで身についたのだと思います。
書籍や個人開発でも学べます。ただ、独学だと「動いた」で止まりがちです。動いたコードが良いコードとは限らないのに、それを判定する手段がありません。
レビューがあると、そこから先に進めます。「なぜこう書くべきか」まで届く。この差は、かけた時間の差よりずっと大きいと感じました。
例えば要件に「削除」とあった際、特に疑問も持たずに DELETE を書いたら、「後で参照する可能性があるので論理削除にすべき」というフィードバックをもらいました。
言われてみれば、そのデータの使われ方を考えると論理削除のほうが妥当です。ただ、指摘されるまで選択肢として浮かんでいませんでした。書いたコードは要件通りに動いていたので、自分では問題に気づきようがありません。
こういった設計判断は、経験がないと正解が分からない領域です。そして分からないことに自分で気づけないので、誰かに見てもらう以外に検証する方法がありません。
そして、止まった
一方で、DB設計とインフラは伸びませんでした。
念のため書いておくと、そのエンジニアがDB設計をできないわけではありません。できる人でした。
ただ、副業としての参画で、稼働時間そのものが限られていました。
週に数時間、あるいは平日の夜と週末の一部。その中で自分の担当タスクを進めるだけで手一杯になります。他人のコードを丁寧に見て、設計の意図まで遡って議論する時間は、構造的に残りません。
レビュー自体は必ず通していました。本番反映までのフローに組み込まれていて、承認なしにマージされることはありません。
それでも、結果はこうなります。動作に問題がない部分は、そのまま承認されて通っていく。実装の細かい書き方については指摘をもらえても、「そもそもこのテーブル設計でいいのか」という話にはなかなか至りません。
インフラに至っては、そもそも私が触れる機会がほとんどありませんでした。デプロイもCI/CDの設定も、すでに動いているものがあり、壊さないように触るだけ。設計の判断をする場面が回ってきません。
これは個人の問題ではなく、構造の問題
ここが、この記事で一番書きたかったことです。
業務委託は、時間を売る契約です。
契約している稼働時間の中に、「他人を育てる時間」は含まれていません。含めることもできますが、そう明示されている契約に私は出会ったことがありません。
誤解のないように書くと、レビュー自体は仕組みとして存在していました。本番反映までのフローに組み込まれていて、誰かの承認なしにマージされることはありません。
ただ、仕組みがあることと、そこで学習が起きることは別でした。
レビューには深さの段階があります。動作に問題がないかを見る。実装の書き方を指摘する。設計の意図まで遡って議論する。フローが保証するのは一段目までで、そこから先は見る側の時間と余力に依存します。
稼働時間が限られていれば、承認を出すことはできても、そこから踏み込む余裕はありません。マージは通る。コードは本番に出る。でも「なぜこの設計にしたのか」を問われる場面は生まれない。
誰も手を抜いていません。フローも機能しています。それでもチームとして教育機能は成立していませんでした。
正社員中心のチームなら、状況は違います。
オンボーディングの期間が設けられ、設計レビューの会が定期的に開かれ、ペアプロや相談の時間が業務として認められる。メンタリングが評価項目に入っている会社もあります。人を育てることが仕事の一部として扱われているからです。
業務委託中心の現場では、これが「余力があれば」になります。そして余力は、たいてい常にありません。
私自身、逆の立場になったときに同じことをしていました。フロントエンドの実装について誰かに聞かれても、自分のタスクが詰まっていれば「後で見ます」と答えて、そのまま流れる。責めているわけではなく、私もその構造の一部でした。
設計領域ほど、この問題が効く
なぜDB設計とインフラで顕著に出たのか。考えてみると理由があります。
実装は、正解が比較的はっきりしています。動くか動かないか、テストが通るか、パフォーマンスが出るか。定量的に検証できる部分が多く、独学でも一定のところまでは進めます。
設計は違います。
正解が一つに決まりません。正規化をどこまでやるか、冗長性をどこまで許すか、このデータをどのテーブルに持たせるか。どれもトレードオフの判断で、しかも「3年後にどう効くか」の見積もりを含みます。
つまり、自分の判断が妥当かどうかを自分では検証できない。
本を読めば定石は学べます。個人開発で手を動かせば、動くものは作れます。でも「自分が下した判断が、この規模とこの要件に対して適切だったか」は、経験のある人に見てもらう以外に確かめる方法がありません。
独学の限界は、時間でも教材でもなく、検証手段の不在でした。
これに気づくまで、ずいぶん時間がかかりました。学習量が足りないのだと思って本を増やしていた時期がありますが、方向が違っていたわけです。
では、どうするか
正直に書くと、まだ答えは出ていません。ただ、考えている方向はあります。
案件を選ぶ基準を変える
これまで案件を見るとき、単価と技術スタックと稼働条件を見ていました。そこに「誰と働くか」を加えるべきだったと思っています。
具体的には、こういう点です。
- チームに正社員のエンジニアがいるか、比率はどの程度か
- 自分より詳しい人がいる領域はどこか
- その人の稼働形態はどうか（常勤か、副業か）
- コードレビューがどの粒度で行われているか（承認するだけか、設計まで議論するか）
- 設計はどうやって決めているか（誰かの独断か、議論の場があるか）
「レビュー体制はありますか」と聞くと、たいてい「あります」と返ってきます。フローとしては存在していることが多いからです。聞くべきはその先で、どのくらいの深さで見ているか、設計について議論する場が実際に機能しているか。ここを確認しないと、私と同じ状況になります。
募集要項には書かれていないので、面談で聞くしかありません。ただ、こうした質問は「チームの開発体制を知りたい」という文脈で自然に聞けます。単価交渉より聞きやすいくらいです。
このことに気づいてからは、面談の際に必ずレビュー体制について聞くようになりました。まだ回数は多くないので、この質問がどこまで有効かはこれから確かめるところです。
実務以外の手段は、補助にはなる
勉強会に出る、OSSに関わる、設計を見てもらえる知人を持つ。どれも有効だと思います。
ただ正直に書くと、実務のレビューには及びません。自分が責任を持って書いたコードに、その文脈を理解している人から指摘をもらう。この条件が揃わないと、フィードバックの質が落ちます。
補助にはなるが、代替にはならない。そう考えています。
まとめ
フリーランスを続ける以上、この制約とは付き合っていくことになります。業務委託中心のチームを選ぶ限り、教育機能が構造的に存在しないという前提は変わりません。
ただ、「独学では限界がある」の中身が分かったことは前進でした。
限界の正体が学習時間なら、時間を作れば解決します。教材なら、良い本を探せばいい。でも検証手段の不在なら、打つ手は本を増やすことではなく、踏み込んで見てもらえる関係を作ることです。
そしてそれは、レビュー体制があるかどうかとは別の問題でした。フローは機能していたのに、学習は起きなかった。仕組みの有無ではなく、そこに使われる時間の話だったわけです。
同じところで詰まっている人がいたら、自分の学習量を疑う前に、まず環境を見てみることを勧めます。
コメント