20年前からシステム開発をしてきたエンジニアとして大切にしている姿勢
はじめまして。TAMのバックエンドエンジニアの浅野です。今年でエンジニア歴20年を迎えます。
20年前にWebシステム開発をPerlで始め、現在では主にPHPでLaravelなどのフレームワークを使ってシステム開発をしています。他にもWordPressのプラグイン開発なども行っています。TAM内ではインターンの指導などもしています。
この記事では、20年前と現在、自分がどのような仕事をしてきたか振り返ってみることで、時代の変化と、エンジニアとして大切にしたい仕事の取り組み方について考えてみたいと思います。
———
20年前のシステム開発の現場：すべてがスクラッチでひたすらに手を動かしていた時代。
最初のお仕事（25年ぐらい前）はPerlでのスクラッチ開発
初めての実務での開発に携わったのは、クーポン発行管理のシステム会社でした。1999年頃なので、まだインターネットの普及率も13%ぐらいの頃です。
この時はまだTAMには所属しておらず、派遣の会社で仕事をしていて、この案件はあるシステム会社の下請けとしてPerlとOracleで開発中の案件にサポートで入りました。
自分自身経験も浅く、「データベースって何？」の状態でプロジェクトに放り込まれました。
発注元にはシステムエンジニアがおらず、容易に相談できない環境で無我夢中だった覚えがあります。大量の資料だけ送られてきて、特に指導はなし…といったプロジェクトでした。
今では考えられないですが、半年ぐらいの開発期間中に20連勤とか徹夜とか、いっぱいしていました。
当時のエンジニアは「徹夜当たり前！」「昼夜逆転してこそ！」みたいな風潮があった気がします。とにかくすべてが模索しながらでした。
25年ぐらい前だと案件はほぼPerlだったのですが、技術の習得で大変お世話になったのは、おそらく当時個人HP作ったことのある人なら誰でも知ってるであろう、kent-webさんのページ。
ここの掲示板やショッピングカートの中身はすごく参考にさせてもらっていたことを思い出しました。今も残っていて感慨深いですね。
当時は、そうやって四苦八苦しながらスクラッチで作る案件がほとんどでした。
———
Perl中心だった案件がPHP+mySQL/Postgres中心に（20年ぐらい前）。効率化の方法を意識して模索するように。
そうやってPerlでの開発を2〜3年ほど経験した後に、PHPの案件に関わるようになりました。
最初に携わったPHPの案件は企業のアンケートフォームでした。「フレッツADSL」や「Yahoo! BB」といったADSLが登場した頃の話です。
その時のPHPのバージョンは4でした。ポケットリファレンスを買って勉強していた覚えがあります。PHPを扱う様になってからMySQLやPostgreSQLなどのDBを使うような案件が増えてきた印象です。
当時はウェブのキャンペーンや、サービスにお申し込みするためのフォーム開発が多かったのですが、私自身はアンケートフォームを作る仕事（入力項目が200個ぐらいの）が多く、毎回作るのが大変でした。
ラクをしようと自動でアンケートの項目（テキストやラジオボタンなど）を作成するシステムを作ったのですが、結果コストダウンになってクライアントに長く使ってもらいました。（複雑な項目の仕様が出るたびに四苦八苦しましたが…）
これを機にメールフォームなどベースのシステムを作っておいて、他案件に流用しやすく作ってコストダウンすることに力を入れるようになりました。
———
近年のシステム開発の現場：ツール・フレームワーク・オープンソースによる効率化する時代。設計・思考の重要度が増してきた。
明確にいつから、というのを覚えているわけではありませんが、感覚的に2010年頃からMT（Movable Type）、WordPress、EC-CUBEなどのCMSを使うことも多くなってきたように思います。
また、2010年代後半くらいからはPHPも一から書かずにLaravelといったフレームワークを使う機会が増えました。
そして、近年ではSalesforceなどをはじめとする様々なクラウドサービスが登場し、案件で使う機会が増えてきました。
こういった既存のサービスやフレームワークを使用すると、今までスクラッチで書いていたベース部分のコードの開発が必要なくなりました。
プラグインやモジュールなども揃っており、開発なしでできる幅が広がってきています。
私はというと、単純にCMSのベースの機能だけではできないような場面で、カスタマイズをする開発を担当することが多くなりました。また、開発だけでなく、CMSの選定自体に関わったり、実現可否の判断や調査をする部分にも関わることが増えてきました。
何を作るかよりも、何を利用するかを考える機会が増えたという感じです。
実際にこの数年で自分が担当した案件を洗い出してみたところ、ツールやフレームワークを使って構築したものがやっぱり多かったです。
Movable Type
テンプレートの中にPHPを組み込み動的コンテンツとして表示するのが多かったです。
動画配信ページ（塾）：MTテンプレートにPHPを組み込んで動画サイトと連携
製品サイト（スポーツ用品メーカー）：商品比較するコンテンツ（MTテンプレートにPHPを組み込み）
WordPress
プラグインを開発することが多かったです。特にデータ変換保存系。
書籍紹介（出版社）、製品紹介（医療系）、物件検索（不動産）：特殊なフォーマットのCSVやエクセルのデータをインポートする機能、検索機能
発注システム（医療メーカー）：商品検索、決済機能のないショッピングカート
結婚式場（ブライダル）：多数の式場の検索（API化）、他システムとの連携
EC-CUBE
記念品のEC（ノベルティ）：ノベルティの名入れやデザインなどを選択させ、発注する仕組み
食品系EC（高級料亭）：EC機能全般の実装
スポーツ商品系ECサイト（マクダビッド）：一部カスタマイズ
ファッション系ECサイト（trion）：EC機能全般の実装
フレームワーク
予約受付システム（医療機器）：セールスフォースと連携、API化
求人サイト：会員管理、API化
スクラッチによる開発
クーポンシステム（商社）：クーポン発券システム
ショッピングモールサイト：施設、ショップの管理システム
介護サイト：各施設の発表会に向けての投稿システム
メールフォーム系多数
———
コードを書く量は減る一方、技術の選定や調査、設計の重要度が高まっていることを感じる。
たとえば設計書。
20年前は、開発に取り掛かるため資料などは、ワイヤーフレームや構成図に簡単な説明のついただけのものがほとんどでした。バリデーションなども開発者まかせで、テスト仕様書もなく、目視で確認のみでリリースすることもありました。
それが時代とともに変わり、いまのTAMで行う業務のなかでは、要件定義・機能一覧・バリデーション設計・DB設計・API設計・テスト仕様などといった、作るべき資料のボリュームが非常に増えています。
たしかに、設計書の作成には多くの時間がかかるもの。ですが、ここで設計をキチンと固めることで、あいまいな部分が少なくなり、結果としては時間の短縮になっています。
開発フローの中で、費やす時間の配分にも変化がありました。
ツールやフレームワークの利用で、コードを書く量は体感的に減りました。一方で、新しく覚えなければならないことが増えるので、作業が減った分だけ調べたり考えたりする時間が増えたように感じます。
コードは書かなくてもいい部分が増えた一方、構築する難易度自体は変わっていない印象です。たとえば会員登録システムのフレームワークを利用したとしても、バリデーション部分や項目の種類・数などはクライアントのビジネス要件に合わせなければなりません。
こういったビジネスロジックに関する箇所は、私自身でカスタマイズしなければならないので、基礎的な知識やスキルの習得は、今の時代であっても軽視できない、重要なポイントだと思います。
あとは、さまざまなサービスを知っていると開発の手間がなくなったり、セキュリティが向上したりするのもスクラッチでしないことのメリットだと思います。例えばSalesforceやSendGridなどをきちんと理解していれば、セキュリティ面をサービス側に任せることができます。
こういった判断は、ツールやフレームワークに関する知識・経験を積み重ねたからこそできます。どれだけエンジニアとしての経験年数を積んだとしても、勉強は常にしないといけないですね。
特にTAMにいる新人エンジニアは、みな勉強熱心で、あたらしいものへの興味と探究心が尽きません。自分がいままで気づけなかったものを知る機会も多く、色々と学ばせてもらっています。
———
クライアントの実現したいことに向き合い、応えていくエンジニアであり続けたいと思う。
こうして振り返ってみると、私がバックエンドエンジニアとして活動をはじめた20年前から現在までには、いろんな技術革新があり、そのたびに新しい知識やスキルの習得が必要になってきました。いまでは、時代遅れになってしまったものもあります。
新しい技術は、うまく使えばクライアントの要望をよりよい形で実現することもできるので、学んでいく必要があります（どんどん出てくる技術を習得していくのは大変ですが・・・。）。
その一方で、クライアントのビジネスロジックに合わせるためにはカスタマイズ開発も必要で、そのためには基礎も必要ですね。
自分としては、目の前のクライアントの要望にしっかり応えようとしてきたことが、現在に繋がっているのかなと思っているので、今後もそこを一番大切にしたいなと思います。