フリーランスになってから最初の約5年は、Webサイト制作が中心でした。HTML/CSSやWordPressでの制作には慣れていましたが、Webアプリケーションの開発は未経験で、2022年10月に参画した現在の業務委託先が、初めてのアプリ開発案件でした。
最初に任されたのは、外部ベンダーが開発したLaravelアプリを引き継ぐ開発要員という役割です。この記事では、そこからの約2年間で、サイト制作の経験がどこまで通用して、何が足りなかったのかを振り返ります。
結論から言うと通用しなかった経験はありませんでした。ただ単純に「アプリケーションならではの経験」が足りなかったなと言う感じです。
最初の2週間にやったことは、別の記事に書いています。
最初の壁は「どのファイルを読むか」だった
最初にぶつかったのは、Laravelというフレームワークの習得と、自分が書いていないコードの解読が同時に来たことです。
特に時間がかかったのは、ある事象が起きたときに、どのファイルを読めば原因にたどり着けるのかを見極めることでした。サイト制作では、画面に出ている結果から逆算して、HTMLやCSSを追えば原因に届きます。ところがアプリケーションでは、画面の裏でルーティング、コントローラ、モデル、DBがつながっています。
私はまずフロントのファイルを読みにいきましたが、当然、原因がそこにないことも少なくありませんでした。見るべき場所を間違えたまま時間が過ぎる、ということを最初のうちは何度も繰り返しましたし、成果が出ないこの時間にとても焦ったのを覚えています。エンジニアなら誰でも経験することがと思います。
小さなissueから、地道に追いかけた
キャッチアップのためにやったことは、特別なことではありません。
まず、小さなissueから対応しました。その過程で、関連するファイルを開き、呼び出されている関数を追いかけます。その関数がスクラッチで書かれたものなのか、Laravelの組み込み関数なのかを、検索や公式ドキュメントで確かめる。この繰り返しで、コードの構造を少しずつ頭に入れていきました。
当時は、今のようにAIを自由に使える環境ではありませんでした。そのため根気のいる作業でしたが、もともとコードを読むのが好きだったので、そこまで苦にはなりませんでした。この性格には助けられたと思います。
見立てが違っていた点：足りなかったのはアプリの経験だった
参画前は、「サイト制作の経験があるから、フロント側から入れば何とかなる」と考えていました。
実際に、サイト制作の経験が通用しなかった場面はありませんでした。ただ、アプリケーションならではの経験が足りておらず、最初は苦労しました。
コンポーネント化の意識
サイト制作でも再利用する場面はあり、コンポーネント化という考え方は持っていました。ただ、アプリケーション側ではReactを使っていたこともあり、より厳密に、純粋な部品として成り立っているかどうかまで考えながら開発する必要がありました。同じ「再利用」でも、求められる水準が違いました。
DB設計
WordPress開発でDBに触れることはありましたが、テーブル設計やリレーションを考えた経験はなく、DBは「コンテンツを入れる箱」くらいの認識でした。アプリケーションではDBの設計が機能の土台になるため、ここは一から学ぶことになりました。
セキュリティ、認証・認可
不特定多数のユーザーの個人情報を扱う、toCのような開発経験がありませんでした。入力値の扱い、認証・認可といった部分は、一つずつ覚えていきました。
CRUD
個人開発でToDoアプリを作ったことはありましたが、データの作成・参照・更新・削除を一通り扱うという、アプリの基本形を実務で経験するのは初めてでした。一方で、アプリケーション開発の醍醐味はここにあると感じました。
つまり、「経験が通用しなかった」わけではなく、「経験の種類が違った」というのが実感に近いです。
なお、DB設計については、別の記事でも別の角度から書いています。
約2年後、別のNext.jsアプリの担当に移った
参画から約2年が経った頃、会社の方針でLaravelアプリの開発はいったん止めることに。そして、より優先度の高いNext.jsアプリについて、外部ベンダー主導の体制から社内チームに切り替えたい、ということでした。
私は、チャンスだと思いました。ReactやNext.jsの開発をしたくて自主学習を続けていたものの、実務経験のないフリーランスには、その経験を積む機会がなかなか巡ってこなかったからです。
Laravelの2年間が役立ったこと
Laravelでアプリケーション開発をしていたおかげで、技術スタックが違っても、API、認証、データの流れは理解できていました。バグが起きたときに、どのあたりを疑えばいいかという勘所も、何となくつかめている感覚がありました。
この土台があったため、Next.jsやSupabaseといった新しい技術の理解に時間を使うことができました。
Laravelの経験では補えなかったこと
一方で、Next.jsでは、Laravelでは考えなくてよかったことが増えました。たとえば、次のような点です。
- 処理をサーバー側で動かすか、クライアント側で動かすかの切り分け
- キャッシュやレンダリング方式の扱い
- Supabaseのような外部サービスを前提にした、データアクセスと認可の設計
Laravelは多くの機能が最初から揃っているフレームワークでした。Next.jsは、周辺のライブラリや構成を自分たちで選ぶ場面が多く、その分、判断することが増えます。ここは、Laravelの経験だけでは補えず、改めて学ぶ必要がありました。
逆の判断もありだと思う理由
引き継ぎ案件にとどまって、1つのアプリを長く見続ける選択も、十分に合理的です。
1つのアプリを長く見ることで、そのアプリの開発でリード的なポジションを目指せます。また、そのアプリの歴史を見てきた人にしかできない開発判断も、確かにあると思います。
私の場合は、担当が移ったのは自分の選択ではなく、会社の方針でした。結果として、市場価値の高い技術スタックの開発経験を積めたことは、キャリアにとってプラスになりました。ただ、これは巡り合わせの面もあり、同じ状況で逆の結論を出す人がいても不思議ではありません。
まとめ：チャンスは、信頼を得た場所から来た
そもそも新しい案件に声がかかったのは、その委託先である程度の信頼を得ていたからだと思っています。
フリーランスは、未経験の技術で参画することが難しい立場です。引き継ぎ案件のような地味な仕事でも、きちんとやり切って信頼を積むことで、未経験の技術に挑戦するチャンスを得られることがあります。もし今、希望の技術に触れられていない人がいたら、こうした形でチャンスを得る方法もある、ということを持ち帰ってもらえればと思います。
コメント