前回も書きましたが株式会社アスタでは今年の９月から受託の割合を減らして、自社サービスの開発と自社案件へのシフトをはじめました。
受託を受けるにしても限られた少数の顧客に頼るのではなく、なるべく多くの会社とお付き合いさせていただくほうが、新しい技術や開発フローに触れる機会が増えます。それと、とても大事なことなのですが、比較対象が多いほうが契約条件のバランス感覚が付くと考えています。
というわけで、９月から新規のお客様の受託案件がスタートしたのですが…
| PHPバージョン | フレームワーク | DB |
|---|---|---|
| 7.0 | Symfony3 | Oracle |
はじめてづくしの内容です。
さらにその後、別の案件でCakePHP2系で作られたシステムをリニュアルするために、CakePHP3とLaravelも触ることになります。
今日は私がCakePHPに出会った頃にさかのぼって、私のフレームワーク変遷を振り返ってみたいと思います。
※この記事は近況報告なので、CakePHP,Symfony,Laravelなどのフレームワークを比較するわけでも、利用法について書いてあるわけでもありません。CakePHPを10年使ってきた人がそれを手放すときの寂しさ、不安、期待について語っているので、同じような境遇にあるかた、フレームワーク選定に悩んでいる方などに読んでいただけたらと思います。
CakePHP1,2
いつからCakePHPを使ってるのか調べてみたら、「$form->datetimeの改造（2008-04-09 10:46:58）」この記事が最古の記録でした。
HappyQualityを始める前で、まだサラリーマンだった頃に書いていたブログです。懐かしいですね。
古い記事を読んでいたら思い出したのですが、CakePHPをはじめて触ったのは2008年の1月だったことを思い出しました。
前年の2007年11月に入社した会社でフルスクラッチのECシステム*1 を書くのに苦労していた頃です。
オレオレフレームワークで開発をはじめたものの、限界を感じながら正月休みに入り、
どうしようかと悩みながら調べていたらCakePHPに出会った。
そんな感じだったように記憶しています。
たしかバージョンは1.1。
それから約4年後に独立し、幾つかの小さな案件を経て、クラウド型飲食店向けのクラウド店舗管理システム*2 の案件でCakePHPの2系に移行しました。
CakePHP1.3から2系への変化は劇的で、とても実用的なフレームワークになったと感じたものです。何が？と聞かれると昔のことなのでよく覚えていませんが（笑）
これがたぶん2012年頃だと思うので、もう5年以上CakePHP2系を使ってきたことになりますね。
それ以来、DBを使わない簡単なものからDBテーブル数100以上の大きなシステムまで、ありとあらゆるプロジェクトをCakePHP2で書きました。
業務システム。グループ企業間の情報共有システム。複数言語に対応したポータルサイトやコーポレートサイト。もちろん普通のコーポレートサイトやECサイトもたくさんやりました。
レギュレーションや要求の厳しい大手企業の案件も多く、企業のプロモーション案件*3 で、SNSと連動する企画とか、インスタントウィン *4 などもやりました。
地方に居ながらこんなに多くの多彩な案件、規模の大きい案件をやらせてもらえたのは、営業力のあるリ・クリエーションと一緒に仕事をさせてもらえたからで、本当に感謝しています。*5
おかげでCakePHP2なら自分の手足のように使えます（笑）
頭で考えたことは意識しなくてもコードになっていく感じです。
DBの設計も過去に膨大なトライ＆エラーがあるおかげで、こういう時はこうするというデザインパターンが頭ではなく体に染み付いています。 *6
DBを設計し、作り込まれたBakeテンプレートで足場を自動生成。それをもとに開発するシステムは信じられないような速さで組み上がっていきます。実は先ほど話したような100テーブルを超える案件なども、デザイン部分以外はDBの設計も機能実装も、ビューのコーディング*7 まで、ほとんど私１人で書きました。
こう言うと驚かれるのですが今までのシステム案件のほとんどが、設計・機能実装・ビューのコーディングを私１人で書くか、そうでなければDBの設計だけ書いて他の方にお願いする形をとってきました。システムの意図を最も理解する設計者が機能実装すれば仕様は完璧に頭の中*8 ですから、コーディング中に手を止めて仕様を確認するムダもなくて済みます。
ビューコーディングにしてもビューで使用する変数やメソッドは全て頭に入ってるわけで、余計な資料を作る手間も確認する時間も無駄になりません。
しかし、ついに自分の手足とも呼べるCakePHPと別れなければならない日が来てしまったのです。
Symfony3
９月から新しい受託案件がスタートしました。
私にとっては過去最大規模のシステムで、チーム人数も最多の８名と聞いています。
また、今回はプログラマとしての参加なので要件定義やDB設計にも全くタッチしておらず、整備された仕様書にもとづいてコードを書くという、今まで私が経験したことのないスタイルで参加します。*9
要件は冒頭にも書いた通り、Symfony3、Oracleです。
今回はDBにも直接アクセスする権限がない状態なのでOracleの経験が無いのは問題にならなかったのですが、Symfonyには手こずりました。
苦労したのは２点。
１つは日本語のドキュメントが少ないこと。これは頑張ればなんとかなるのですがもう一つは大変でした。
CakePHPと比較すると、覚えるルールが非常に多いのです。
CakePHPしか知らない私にはSymfony自体を評価することはできませんが、SymfonyとLaravelを比べてみての考察 – オープンソースこねこねこちらの記事が腑に落ちました。
Symfonyは構造がしっかりしていて重厚
SymfonyはPHPのダメなところを改善するように作られたフレームワーク
使いはじめて日が浅いこともありますが、フレームワーク自体の構造が大きいため全体像がなかなか見えないのです。
「こういうことをしたい時はこうする」ということがわからず、英語のドキュメントや数少ない日本語記事を頼りに、噛みしめるように覚えていきます。
CakePHPならドキュメントでも、個人の記事やstackoverflowでも、コードに慣れているので、たとえ英語の情報であってもすんなり理解できるのですが、はじめたばかりのSymfonyではそれが正しい情報なのかどうかも含めて、目的の情報を探すのに苦労します。
ただしこれは、CakePHPでも経験してきたことですし、難易度の違いはあれどいずれは解消される問題だと思います。
２ヶ月ほどしか触っていないのでSymfonyの真価には触れていませんが、きちんとやればCakePHPよりもきちんとしたアプリケーションが作れそうだなと感じました。ただ、別の案件でもSymfonyを採用するか？というと、採用しないと思います。
その理由は、最後のLaravelのくだりで。
CakePHP3
先ほどの受託案件とは別に、来月からCakePHP2で書かれた販売管理システムのリニュアルのプロジェクトが始まります。
目的は一企業向けに作ったシステムを汎用化して一般提供するためのリニュアルなのですが、今まで積み上げてきた改善案や新しい機能もたくさん追加するため、DB設計も含めてフルスクラッチで作り直します。
当然のことながら、5年も前にリリースされて3系も登場しているのに、CakePHP2系で書くのはどうかなという議論になりました。
そこで候補に上がったのは当然CakePHP3です。
今まで培ってきたリソースと経験がたくさんあるので、それらを活かせるだろうという判断です。
フレームワークの選定も含めて準備だけは９月頭から進めており、日常業務の合間を縫ってCakePHP3の検証を行っていたのですが、どうやら思ったよりも学習しなければならないことは多く、過去のリソースも思っていたほどは活用できなそうです。
CakePHP3系ではモデル周りが大きく変更されていて、モデルの定義はTableに、データは連想配列からEntityというオブジェクトで扱うようになったのです。この変更に伴い、コントローラでデータの取得、保存処理の書き方も変わります。
今まで作りためてきたプラグインやビヘイビアも、書き直さなければ使えません。
さらに、頻繁に利用していたサードパーティ製のプラグインの中にもCakePHP3に更新されていないものがありました。*10
CakePHP3の変更点自体は、CakePHPのいいところを残しつつ、特徴的だったモデル周りの連想配列をTableとEntityクラスに分けることでDBとデータを直感的に扱えるようになっているので正統進化と言えそうです。そのおかげでモデルデータの扱いやすさは良くなったと思います。
コントローラやビューはそんなに変わっていませんし、命名規則やメソッド名も変わったものはありますがCakeっぽさはちゃんと残っているので、覚えは早いと思います。使いこなせるようになれば2系よりも便利な面も出てくると思うのですが・・・引っかかるんですよねぇ。
モダンなフレームワークの特徴を取り入れたCakePHP3ですが、もっとモダンでこれから主流派になりそうなフレームワークのLaravel。こいつの存在が私を悩ませるのです。
Laravel
なぜLaravelが引っかかるか…注目せざるを得ないのかについては、定期的に話題に登る「PHPフレームワーク比較 – Google 検索」の記事を読んでもらえばわかると思います。
もし私のように古いフレームワークを使っていて「そろそろ次、考えないとな〜」と思ったことのある人は、必ず見たことがあると思いますし、Laravelが怒涛の勢いで人気を伸ばしているのも既にご承知のとおりだと思います。
青線がCakePHP, 赤線がLaravelのGoogleでの検索ボリュームです。
Google Trends（世界）
Google Trends（アメリカ）
Google Trends（日本）
世界やアメリカでは３年以上も前に１位に転じており、なおも急激な右肩上がり。現在は他のフレームワークの数倍に開いています。
CakePHPが圧倒的人気を誇っていた日本でさえも、今年はじめから急激な逆転現象が起きてシェアが倍近くに開いていました。
GitHub スター数比較
青線がCakePHP,オレンジ線がLaravelです。
エンジニアが利用しているGitHubのスター数*11 も悲しいほどに開いています。。。
この事実を知りつつ「俺はCakePHP3でいくんだ！」と言えますか？
・・・私には、言えなかった。
・・・
CakePHPがLaravelと一緒に伸びているならまだしも、圧倒的に伸びているLaravelとは対象的に衰退していくCakePHP。
CakePHPは本当に素晴しいフレームワークです。愛しています。
好きなフレームワークは？と聞かれればCakePHPと即答します。
今までご飯が食べられたのもCakePHPのおかげですし、妻と出会えたのも、愛すべき娘が生まれてきてくれたのもCakePHPのおかげです。*12
それでも！この状況で選ぶべき選択肢は間違いなくLaravelなのです。
他所に勝つためにはリソースの全てを一箇所に集中して、圧倒的なスペシャリストになるしかありません。限られた少ない人的リソースを、複数の言語やフレームワークに注いでしまったら、逆立ちしたって他に勝てませんから。
一昔前のCakePHPがそうだったように、情報や人材は主流派に集まります。
クライアントやお金だってその流れについてきます。
もしフレームワークの選定を間違えてしまったら・・・？
prototype.jsを覚えていますか？
一時はCakePHPのように隆盛を誇ったprototype.js。
ところが彗星の如く現れたjQueryに席巻されて跡形もなく消え去ってしまいました。
せっかく理解を深めて手足のように使えるようになったとしても、主流派を選べなければその努力は無駄になり、再スタートを切らなくてはならないのです。
エンジニア個人としてなら好きなフレームワークを使い続ければいいと思います。
でも、会社として…特にアスタのように弱小でこれから成長していく会社なら、絶対に主流派に居続ける必要があるのです。
もちろん不安もたくさんあります。
Cakeではできたような高速開発はできるんだろうか？
Cakeでできたことが、Laravelではできなくなったりしないんだろうか？
Formヘルパーみたいなのは無いのかな？
コントロールごとにバリデーションエラーが出せるしパラメータも豊富で出力するソースもカスタマイズできたから、すごく便利で楽ができたけど同じような事ができるんだろうか？
マイグレーションを書かずにDBからマイグレーションの生成は不都合なくできるんだろうか？
不安は尽きませんが、ファイルのアップロード・イベント・ジョブ・通知・キューなどLaravelに標準搭載された便利そうな機能もたくさんあり、期待も大きいです。
来月からLaravelを本格的に使い始めるので、ブログにもLaravelの記事を書くかもしれませんが「Laravelスペシャリストへの道」どうぞご期待ください。
ダラダラと駄文を書き続けてすみません。
もし最後まで読んでくれたなら、あなたは素晴しい人だ。
機会があればぜひグラスを傾けながら、一緒にITの未来を語りましょう。*13
- プロフィールで簡単に紹介していましたが、当時のシステムは別のものに置き換わっていました(^^;)
オリジナルのデザイン入り米袋で作る出生体重のお米を販売するためのサイトだったのですが、出生体重×1円の金額計算や、赤ちゃんの写真をアップロードすると複数登録されたテンプレートと合成されてプレビューできたりと、かなり特殊なカートに仕上がりました。 [↩] - DB54テーブルで当時の私にとってはかなり難易度の高い大規模な案件でした。今でも公式サイトは残っていますが、NDA（機密保持契約）的に出せないだろうなぁ。今度聞いてみます。 [↩]
- 期間限定の企画でTVCMやメディア、店頭広告などのために作られるサイトやシステム案件 [↩]
- インスタントウィンとは、よく食料品などについているキャンペーン用のコードやQRコードで応募すると賞品がもらえたりするあれです。一般ユーザが見る表側は番号と個人情報を入れるただの入力フォームですが、裏側には番号やQRコードの発行機能、抽選を行う機能、当選者へ通知する機能、当選在庫の進捗レポート、賞品の発送管理機能など、いろいろな機能を実装する必要があります。 [↩]
- デザイン性を重視した案件や、プロモーション企画などは実績も実力もある株式会社リ・クリエーションをおすすめします。素晴しいデザイナーが何人もいますし、企画力も素晴しい。とくに新開社長の企画構成力や発想力は群を抜いているので、きっと思いもよらないアイデアを出してくれると思います。 [↩]
- DBの設計をミスると大変な騒ぎで、ちょっとした仕様変更にも耐えられなくなったり、もっと致命的な場合、想定していたビジネスロジックが書けなくなってしまうこともあります。今でこそ致命的な間違いは冒さなくなりましたが、今でも複雑なデータ構造になると最適解を選べずに反省することはあります。 [↩]
- デザインはデザイナーが描いて、素のHTMLとスタイルまでは作ってもらって、それをCakePHPのビューにコーディングするという意味 [↩]
- いくつも案件を抱えていたり、途中仕様変更+要件定義などで時間が空いてしまうと頭から抜けてしまうので、その場合は思い出すのに時間がかかりますが。 [↩]
- SIerのSEやプログラマの方にとっては当たり前のスタイルなのだと思いますが、私は逆にフルスタックしか経験が無いので色々と苦労してます^^; [↩]
- Filebinder, Imagebinderのことですが、自前でコードを書かなくてもモデルの保存時にS3にファイルをアップロードできるので、AWSでELBを使って複数台構成にする際には重宝していました。 [↩]
- Google Trendsは検索件数を元にするので、重厚長大なSymfonyのようなフレームワークのほうが検索クエリが増えやすくSilexのようにシンプルな方が少なく出る可能性もありますが、Githubは１スター＝１エンジニアなので、注目しているエンジニアの割合をGoogle Trendsよりは正確に示せていると思います。 [↩]
- 結婚して16年、娘は10歳ですが [↩]
- 長話にお付き合いいただきありがとうございましたm_ _m [↩]
