近頃、小規模の受託案件を複数こなした結果、それらの現場や顧客とのやり取りからある程度共通して見えてきたことがあるのでここに記しておきたい。
お客さんの環境
受託で関わる中小企業の多くは、すでにレンタルサーバー上でコーポレートサイトやメディアを運営している。
さくらやエックスサーバーのような共用サーバーに、WordPressと静的HTMLが混在しているのが典型的な構成だ。
社内にITエンジニアはいない。お知らせの更新や画像の差し替え、表記の修正はお客さん自身がやっていることもある。
そこに「ここに追加で機能を作ってほしい」という依頼が来る。
この環境に対して、自分が慣れ親しんだRailsやNext.jsを持ち込むのは現実的ではない。
大がかりなフレームワークはルートに配置しないと動かないことが多く、既存の資産が稼働しているサーバーでは導入が難しい。
お客さんが日常的にHTMLを編集している環境にフレームワークを入れるのは、都合が悪いことの方が多い。
ではどうするか。素のPHPで書く。
基礎技術への原点回帰
レンタルサーバーと素のPHPという組み合わせは、一見すると時代に逆行しているように見える。
しかし、AIがコードを書く時代になったことで、この選択肢は以前より合理的になっていると思う。
フレームワークとは、人間が効率よく質を保つための工夫が結集したものだ。
規約や仕様に沿ってコードを書けば、一定の品質が保たれる。
しかし習得するには時間やコストがかかる。
AIを使って開発するなら、フレームワークなしでも生産性は大きく落ちない。
素のPHPにORマッパーや認証といったライブラリを組み合わせれば、たいていの要件は満たせる。
必要なのは基礎技術であり、特定のフレームワークの知識ではない。
基礎技術への原点回帰が可能な時代になってきた、ということだと思う。
引き継ぎの現実
受託で作ったものは、いつか他の人や他の会社に引き継がれる。自分の意向で抜けたい場合もある。
ここが自社事業との最大のギャップだった。
世の中には、PHPとFTPの環境でしか仕事をしたことがないITエンジニアが大勢いる。
Gitを使ったことがない人も珍しくない。そういった人たちは単価が低いことが多く、発注元の会社としてはむしろ好都合だったりする。
AIが書いたコードであっても、素のPHPなら、ほとんどのITエンジニアが引き継ぐことができる(その後維持できるかは知らない)。特別なフレームワークの経験は問われない。
逆に言えば、凝ったフレームワークやインフラを導入してしまうと、引き継ぎの際に「その技術の経験がある人」を探さなければならない。
それは手離れのしやすさという観点からすると、結果として自分の首を絞めることになりかねない。
技術的に高度であることが、受託においてはかえって仇になるという現実が見える。
レンタルサーバーの利点
改めてレンタルサーバーの利点を整理すると、こうなる。
- コストが安い クラウドと比べてイニシャルコストが圧倒的に低い。定額制の安心感も顧客目線ではありがたい
- 基盤の運用が不要 サーバーの管理はレンタルサーバー事業者がやってくれる。セキュリティアップデートやハードウェア障害を気にしなくていい
- お客さんの認知度が高い 中小企業のお客さんの既存環境がレンタルサーバーであることが多く、提案が通りやすい
- 可搬性が高い 特定のSaaSやクラウドに依存しないので、サーバーを移転するときもコードをそのまま持っていける。クラウドに持っていくことも可能だ
デメリット
もちろんデメリットはある。
- スケールが難しい 急なトラフィック増加への対応は苦手。性能の上限がサーバーのスペックに縛られる
- 非同期処理が使えない バックグラウンドジョブの仕組みがない。どうしても必要ならcronでバッチ処理する方向になる
ただし、多くの中小企業のサイトや業務システムでは、リクエストが集中するような状況はそうそう発生しない。
もしそうした規模感の要件が出てきたなら、そのときはレンタルサーバーをやめて別の基盤に移ればいい。可搬性の高い素のPHPなら、移行もそこまで難しくはない。
まとめ
受託の仕事で求められるのは、技術的に最先端であることではない。
お客さんの環境に合い、コストが安く、誰でも引き継げて、長く運用できること。
レンタルサーバーと素のPHP。古くからある組み合わせだが、AIがコードを書いてくれる今、これが意外と合理的な選択肢になっている。