PHPで乱立するフレームワーク
phpで何かシステムを作ろうとする時、まず立ちはだかるのは、「何のフレームワークを使うべきか？」じゃないかなと思います。
そこで、弊社がどういったフレームワーク遍歴をたどってきたか、思い出を語りながら振り返りたいと思います。
弊社のフレームワーク遍歴をお伝えすることで、なにかその選定のヒントになればと思います。
第一期：ZendFramework時代
弊社が池田と私の二人でプログラムをするようになった時代です。フレームワークとはなんぞや？の時代です。
ZendFramework（ゼンドフレームワーク)、今では全然使っている人がいません。開発は・・いまだに続いているんだろうか。。
どうしてこのフレームワークを選んだかと言うと・・
PHPってなんていうエンジンで動いているか知っていますか？
そうです。Zendエンジンですね(^^)
当時はCakePHPの全盛期でしたが、
ちょっとひねくれていた私は
「PHPのコアエンジンを作ったZend社が公式で作ったフレームワークだから間違いない！（はず）」
ということでZendFrameworkを採用しました。
このフレームワークはCakeよりも厳かな雰囲気のフレームワークでして、その機能の一部だけ他のプロジェクトで使うことが可能であったりと、
さすがZend社で公式につくられたフレームワークだなと。
しっかり設計された安定したフレームワークという印象でした。
今は使っていません。 笑
第二期：YiiFramework時代
ZendFramework期を経て、弊社はフレームワーク混迷時代に突入します。 笑
ZendFrameworkはしっかりしたフレームワークなのですが、
書き方が冗長であったり（しっかりしているが故に）「なんか違う」感がありました。
ある難解な案件でZendFrameworkに浸かりすぎて、ちょっと別の味も試してみたくなっていた時期でもあります。。
その時、彗星のように現れたのがYiiFramework（イーフレームワーク)でした。
完全にノーマークでした。
とある私が個人的に信頼している、信頼していいと個人的に感じていたプログラマの方が推していたのがYiiFrameworkでした。
個人的に全く根拠もなくこのYiiFrameworkとの出会いを大事にしたいと思い、「？」の池田を巻き込み、我々のメインフレームワークにしてみました。
このときもCakePHPは依然として黄金期だったのですが、
何故かCakePHPには魅力を感じず・・当時日本語で一切ドキュメントのないYiiFrameworkを選択しました。
その当時、YiiFrameworkはロシア・中国でのシェアがありましたが、日本では全然。アメリカ、ヨーロッパでは少しだけ、のシェアでした。
この選択は、それから長い間、弊社の特徴になったかなと思います。(その特徴がいいか悪いかは置いといて）
この出会いは私達にいい感じの化学反応をもたらし、YiiFrameworkは長らく我社のメインフレームワークとして、本当にいろいろなことを教えてくれました。
はじめて全面的に信じたフレームワークで、PHPという言語の効率的な書き方、まとめ方、読み方等、私のPHPの知識はこのフレームワークを駆使することで培われたと言っても過言ではありません。
非常にシンプル、パワフルなフレームワークで、全面的に開発者を信頼しています。
材料が提供された上で、すべての箇所を作り変える余地が残されているというか、そうするのを推奨しているフレームワークです。
RailsにCakeとは違った影響を受けたフレームワークで、割り切るところは割り切り、配列で全設定を持っていたりします。
すべてが柔軟かと言うとそうでもなく、こうするべき、という指針は存在します。
view側もPHP書いてしまうという割り切り、PHPのシンプルさ、パワフルさ、HTMLとの親和性など、他のフレームワークに影響をうけつつ、そこにPHP言語そのもののお気軽さや、開発者への信頼を与えたような、書くのがとても楽しいフレームワークでした。
YiiFrameworkのことを書くと、いろいろな思い出が蘇りますね。
第三期：Laravel時代
さて現在、弊社はフレームワークで言うと第3期に入ります。
Laravel時代に突入しています。
このフレームワーク、なにより利用者が多い。
このシェアが多いフレームワークの採用、というのは弊社初の試みでもあります。
YiiFrameworkに一切不満は無かったのですが、シェアが低いがゆえに、私達のような「YiiFramework使い」になかなか出会えなかった、という背景もあり、次のフレームワークは、PHPのフレームワークの中で確実にシェアを取っているものにしようと考えていました。
その点、Laravelは開発者も多く、私達もいろいろな開発者の人たちのドキュメントを読んで勉強しながら、「効率良い実装」「シンプルな実装」「後々メンテナンスしやすい実装」を心がけています。
同じフレームワークを使う仲間が多い、というのはとてもいいことです。
Laravelは大変良くできたフレームワークで、今風な開発には向いていると思います。
他のフレームワークの経験が活きないかというとそうではなく、フレームワークを使う勘所がなんとなくわかる、ということに留まらずに、、例えば、YiiFrameworkで体験した強力なCRUD出力機能をLaravelで実装してみるなど、他のフレームワークにあった強みをLaravelに移植して育てていくことなどできます。
Laravelは構造が自由なフレームワークで、どのようにまとめるかは、開発者に委ねられています。それ故に、チーム内でどういった方針でソースコードをまとめていくかが大事になるフレームワークです。
弊社ではADR（Action-domain-responder）という、従来のMVCを一歩進めた方式を取り入れています。
この方式により、ソースコードはより取り回しよく、再利用性も上がり、何より修正がしやすくなります。
このような、そもそもの構造から後々の事を考えた方式をとることは、お客様だけでなく、私達も助けることになると考えています。
Laravel、非常にいいフレームワークです。
多少の不満はありますが！（この不満はまた・・いずれの機会で書きます 笑）
より普遍的で普通な実装を目指します
弊社では、基本姿勢として、後々の事を考え、手を入れやすいものを作る。必要以上に作り込まない。
というプログラムの方針を持っています。
要望を実現するために、過度な作り込みが必要になる場合、エンジニアである私達が、それによるメリット、デメリットを的確に伝えることで、その後の改修コスト感やバランス感をお伝えしていければと考えています。
プログラマは一般の方々みれば、魔法使いのようなもので、一旦走り出すと、プログラマではない方からすれば、「何をしているのかわからない」状態になるかと思います。
その中で、私達自身が、後々のことも考えた実装を心がけることは、大変意味のあることだと考えています。
「ただ単に」実装しない。工夫する。
複雑なことを、できるだけ簡単な実装で実現する。
後々のことをできるだけ考えた、工夫あるまとめ方、実装を心がける。
こういったことの手助けをすることがフレームワークの役目だとおもっていますので、これからもより普遍的な、普通な実装を目指していこうと思っています。