CakePHPはなぜ普及しない

質問

弱小SIerでPMの端くれやってます。
普段はsastrutsやasp.net mvcでの基幹業務系案件が多いのですが、今回新しく、一般向けのLAMP案件を担当することになり、仲良くしていただいているフリーPGの方から、cakePHPについて推薦を受けました。
いろいろと調べていると、自分がこれまで馴染んでいるMVC系で、責任範囲は明確だし、コーディングはけっこう簡潔、コミュニティも活発で、良いことづくめのような気がしました。
で、社内および（及び主として開発担当される）外部協力会社数社に相談をもちかけましたたところ、あっさりNGを出されました。

皆様が言うには、あえてcakeのような外部のフレームワークを採用しなくても、MVCモデルや、テンプレート対応は十分に可能で、高品質で迅速な開発が可能だそうです。
一部の熱狂的な開発者をのぞき、そもそも実開発で、CakePHPはほとんど採用されていない、ということでした。
自分としては判断に苦しむ内容で、相手が学習コストを嫌っているだけのように思えるのですが、皆様の中で同様に、「CakePHPはここが問題（だから使わない）」というお考えをお持ちの方がいらっしゃいましたら、具体的な問題点をお聞かせ願えないでしょうか？
Web上の記事には、基本的（ていうか勉強レベル）のものしかなく、具体的な開発例を交えての評価が少ないような気がしていて、今後のこともあり、非常に気になります。

php案件での開発における基本スタンスに関わる問題なと思いますので、ご教示下さい。
よろしくお願いいたします。

回答No.10

dragonoid

う～ん・・・私が思うに、普及していないのではなく、お手軽という点で普及はしてるが、評価が低いというか、評価が両極端なんだと思います。
でも、私が知る限りでは、PHPではCake案件が一番多いんですけどね・・・

他と比べてCakePHPが「万能」でも「特に素晴らしい」わけでもありませんし、
そもそもビジネスにおいて、それぞれのフレームワークの利点は、
プロジェクトの目的や開発チームの状況、立ち位置によっても変わってくるのではないでしょうか？

Cakeに限りませんが、例えばプロジェクトごとにメンバーを入れ替えたり、有用なプロパーを採用しきれなかったり、要するに外部スタッフを多用してるようなところや、独自でフレームワークを開発している時間がないところでは、一般的に普及しているオープンソースなフレームワークの方が、チーム全体としての学習コストや開発コストが有利という理由で導入してる場合も多いようで、そういう意味で汎用性を保つことが可能です。

私が知っているいくつかのところでは、人員の補充という事情でパイの多いCakeを採用しているというところもあります。

でも、チーム内に共有資産があって、空気の入れ替えの少ないチームでは、これらの利点は少ないかもしれません。

そもそも「外部のフレームワーク」(笑)と言ってる時点で、彼らにはオープンソースのメリットはないのでしょう。
また「MVCモデルや、テンプレート対応は十分に可能で、高品質で迅速な開発が可能・・・」ということですが、確かにその通りです。
フレームワーク開発やテンプレートエンジン開発は難しいものではありません。
しかし「一部の熱狂的な開発者・・・」や「・・・そもそも実開発で、CakePHPはほとんど採用されていない」の部分はおそらく誇張でしょうか、一般的にはそんなことはありませんよ。
前述したように、公共機関含め、かなり多くのプロジェクトで採用されているのを知っています。
熟知すればWeb上でそれを見分けることもできるようになるでしょう。

ただ、他の利点やCakeの弱点をあまり知らずにCake導入というのはちょっと早計な気はします。
フレームワークは、それぞれ一長一短があり、それぞれの特徴をきちんと知った上で、目的やチーム事情に合ったフレームワークを選定できるのが私はベターだと思います。

例えば、PHPしか知らないプログラマが、PHPは素晴らしいと言ったところでその説得力は欠けますよね？フレームワークも同様ではないでしょうか？

最後に私感ですが、Cakeは最近やっとマシにになってきたものの、ちょっと雑というか、フレームワークデザインパターンをあまり知らない開発者が作ったことがすぐに分かります。
また、厳密な方々からすれば、MVC混乱の元凶、えせMVCとも言われてしまってますね。
また、中～大規模なプロジェクトにはとても向かないでしょう。
また、特にCakeはあくまで簡略化ツールとして割り切るべきであって、標準化すると有能なプログラマは育ちにくいという声も多いようです。
それこそ、独自フレームワークの中身をいじらせた方が、育成という点ではまだマシなんでしょう。
それでも、Cakeの特徴が目的や状況にマッチしていれば大きなメリットになると思います。

回答No.9

bizdb

PHP初心者が書いたようなクソみたいなコードだから
coreファイル見るとわかる

回答No.8

senbeyya

開発対象は　基幹業務と連携する Web アプリケーションでしょうか？
それとも「一般」とおっしゃっているので、基幹とは関係のない種類のアプリケーションでしょうか。

すべてのお客様および案件に CakePHP が適しているとは限らず、他のフレームワークが適している場合もあります。いろいろ試されてみて、より良い選択肢をお客様にご提案されてみてはいかがでしょうか。
もし試すのが大変でしたら、各フレームワークに中立の立場の人（どこかの信者ではない人）、または会社に有料で教えを請う方が早いかもしれません。

なお、私の知っている例では、某外資系コンピューターメーカーの製品で構成されている基幹システムの場合、フレームワークに Zend Framework を利用した事例を複数聞いています。
CakePHP を検討したこともあったそうですが、トラブル発生時のサポートに不安があり、候補から外されたと聞いています。

回答No.7

abfg_sdf

発注者としても、開発者の立場でも、CakePHPその他の開発を実施し、
また日本と、米国の両方で仕事をしてきた立場で回答させていただきます。

CakePHPが普及しない理由は、開発者と発注者である客の両方に原因があると思います。
普及しない原因を語る前に、なぜフレームワークを使うとよいかを両方の立場から、
整理しておきます。

フレームワークのよい点は、発注者側の立場では以下の点が大きいです。
1.規約にのっとっていれば、第3者でもわかるので、運用業務の安定性が高い
2.基本的なマニュアルがそろっている
3.世界中で多くの案件に長期間にわたって採用されており、その過程において信頼性が
　高く、随時バージョンアップされている。
　たとえ自社では問題が発生していなくても（たまたま露呈していない）、
　バージョンアップなどにより未然に防げる。

一方開発者の立場からいい点は
1.1からすべて自前で作る必要がない。
2.基本的な仕組みが多くの人の手でテストされている。
3.ノウハウが世界中にある

両立場に共通して、早く安く品質高くできる&運用できるといえます。
（この点、「ただし」がつくので、後述します。）

ほかにもたくさんありますが、上記のメリットは大きいと思います。

ではなぜ普及しないかというと、
A.発注者が要求仕様を譲らない。
B.開発者が知らない。学習コストを嫌う。
　PHPという言語＋Cakeというフレームワークを知らないといけない。
　（でも大したことないと私は自分でやって思いましたが。）

これがでかいと思います。「ただし」に該当する点になります。

つまり、フレームワークにも癖がありますので、その癖に合わせて
発注者が要求仕様を変えることで利用のメリットは大変大きくなるのですが、
発注者側のシステム開発に対する無理解により、要求仕様を強要し
結果として、フレームワークの上に追加開発が増え、使う意味があまりなかった。
ということが多発するのです。

一方で、開発者もフレームワークを知らないので、どのように仕様変更することで
本来の目的を達成しつつ、システムの追加開発を最小化できるか、
という提案ができないのです。
また、仕様を変えることを聞き入れてもらえないとわかっているので、だったら
最初から仕様に合わせて作ったほうが早いから勉強する必要なしとなるのです。

またある程度のレベルの開発会社になると、その会社独自のフレームワーク・
規約・開発手順を持っていて、それで開発したいという場合もあるかと思います。

この問題は、CakePHPなどに限らず、他のシステム（業務用基幹ERP）などでも
発生しています。
アメリカ人に、なぜ日本は追加開発が膨大なのかと首をひねられます。
（なんでも米国式がいいとは思わないが、ここは米国式のほうが良さそうな
　気がします。）

発注者の立場で経験するのは、CakePHPに限らずフレームワーク採用する際に、
フレームワークに沿った仕様変更は厭わないので
そのGAPを埋める提案をしてほしい。と開発者にお願いしても、
残念ながらいい答えの返ってくる開発者は非常に少ないです。

そういう形で仕事ができる機会が極端に少ないんだと思います。
（実際私のほうからフレームワーク・プラグインなどを調べて、
　簡単に導入できるよう要求仕様を変更することも多々あります。
　特にCakePHPはコミュニティが世界規模で充実してますしね。）

質問にあるように
「外部のフレームワークを採用しなくても、MVCモデルや、テンプレート対応は
　十分に可能で、高品質で迅速な開発が可能」
これ、よく聞きます。
が、じゃあ第3者でもわかるようにドキュメントもあるかというと、ないんですよね。
テストはどこまでしましたか、テストケース見せてくださいと言って出てくることはないです。
（テストケースは本来は客側が作るものなので、弊社では自分で作りテストしていますが、
　テストするとたいていのベンダーはまぁ悲惨な状況です。）
作った人にしかわからない・運用・メンテできないものができてしまうんです。
また、基本的な機能の実現はCakePHPなどを使ったほうが早い（仕様の融通が利けば）
（ドキュメントもすでにある）。

私はかつて、テーブル構造のデザインとアクセス権限をExcelで定義したら、
読み込み、CakeのBake機能でMVC構築、Plugin使ってログイン機能他を自動で
5分程度で開発完了する開発などしてました。
最初からいろいろ用意されているCakeじゃないと無理ですね。

先ほど述べたＡＢ二つの要因があいまって「日本では」普及しにくいんだと思います。
でも、CakePHPでの開発結構多いと思いますけどね。

CakePHPの生まれたアメリカは、フレームワークとか規約とかマニュアルとか
実は大好きです。(発注者も開発者も)

CakePHPはじめとしたフレームワークの導入に対しては、まずは発注者側の意識改革から
スタートしないと難しいと思います。

SIerのお立場とのことですので、まずお客さんと話すときに、
フレームワークを使う場合とスクラッチ開発の場合の
メリットデメリットをきちんと話して、理解を得られるようであれば
使うということでいかがでしょうか？

客がフレームワークを選ぶ前に、フレームワークが客を選んでしまうのが日本のシステム開発の現場かと思います。
つくづく日本では客側がシステム開発環境を壊してしまったなぁと、
この20年みてきて思います。

ちなみに私がフレームワークを使う開発でベンダーを選定する際は、
何社かに小さな部分の開発を有料で発注し、その出来を見て決めてました。
同じテストケースを実施してバグの発生度合いを見る。
CakePHP使われたらわかると思いますが、
フレームワークじゃないほうが勝つのは難しいですよ。
最近はスクラッチ開発といった時点でお断りしています。
よく言われる、「車輪の再発明は意味がない」ということですね。
（「四角い車輪の再発明」とも言われますが）

ただしこれも私がフレームワークに合わせて要求仕様を変更することも
受け入れていることが前提です。
わがままな客であれば話は別です。

システムは開発したら終わりじゃなくてお守りがずっと続くんですよね。
作った人がやめたので、ちょっとわからないですね。最初から作り直したほうが
早いかもしれませんといわれるのはこりごりです。

追伸：CakePHPという選択について。
発注者の立場でお願いする際に、
Cake/Symphony/Zend/Code Igniter含め7,8つほど自分で開発してみて試しましたが、
私はCakePHPに落ち着きました。
理由はコミュニティ/ドキュメントの充実とフレームワーク構造のわかりやすさですかね。
これは人それぞれだと思います。
SNS用機能が最初から充実してるフレームワークなど他も特徴あるので
案件別に使い分けるのもありかと思います。

ちなみに私の考えるCakePHPの弱点は、バージョン2でかなり改善されたが、
MVCの切り分けがびしっとできていないところ。（まぁある程度は仕方ないかなと）
Vといいつつ、Ｖの中にロジックを入れざるを得ないため、
WEBデザイナーとプログラマの役割分担のためにデザイナーもＶ部分のコードの
理解が必要。(純粋PHPならデザイナでもわかる人多いですが、ここが大きいかも)

その改善のためのSmartyとの連携Pluginあるが、CakePHPで使うSmartyの書き方が
純粋なSmartyの書き方と違うところがあるためノウハウ面で少し難あり。
他は気になるほどでもないですね。Pluginも充実してますし、
いいフレームワークだと思います。

回答No.6

tachiaoi2

自分的には、素のPHPや、中途半端な内製フレームワークを使うリスクの方が高いと思いますがね？
世界の知の集約を取り入れない日本の現状が、世界的なソフトウェアの遅れを助長しているのかも？

日本の大手のシステム会社のソースより、世界の有名なオープンソースの実装の方がレベルが高く、粒がそろっていて信頼における気がしますね。コミッターのレベルも高いし。
採用する段階で、ソースコードを評価すればわかりますよ。

なんか、残念な話ですね。

開発効率は圧倒的に、CakePHPが優位、かつ、ちゃんとしたクラス構造なので、バグがあればオーバーライドするればいいし。

CakePHPがダメなんて言ってる方は、損をしているし、周りの開発メンバは不幸ですね。

回答No.5

LesIs

＞あえてcakeのような外部のフレームワークを採用しなくても、MVCモデルや、テンプレート対応は十分に可能で、高品質で迅速な開発が可能

この他社多数の方々がおっしゃる様にPHPを扱える方からすればフレームワーク自体が邪魔なだけです。

深く考えなくて結構です。

自転車に乗れない方が補助輪をつけて乗れるようになると同じように
既に乗れる方に、補助輪つけて走りましょうなんて熱弁しても
そりゃ皆さん補助輪なんていまさら要らない、逆にカーブや曲がり角で自由が聞かなくて邪魔だと言うでしょう。

回答No.4

besei

>自分としては判断に苦しむ内容で、相手が学習コストを嫌っているだけのように思える
これ、学習コストのロスは、重要な要素だと思います。
そして、これを解消する為の提案を何もしないから、却下されるのでは？

個人で寝る間を惜しんで勉強しても、イザ開発段階でそのフレームワークでは、回避できないことがわかった時の工数が、馬鹿になりません。
おまけにフリーだから、まともに教育orアドバイスしてくれる機関なんて無いでしょう？
ネットで調べまくって、結局出来ないor時間切れで調べきれない、聞く相手もいない、とわかった時の悲しい気持ちを何度も味わうと、「MSみたいな余計なことするなよ。（怒）」って、心底感じていますよ。

回答No.3

tracer

>自分としては判断に苦しむ内容で、相手が学習コストを嫌っているだけのように思える

そのままお返ししますが、すべてのフレームワークを試されてから、「CakePHPを採用しない理由が分からない」という発想をお持ちですか？すべてとはいわないものの、代表的なフレームワークを実践する学習コストを払っていますか？

フレームワークにはそれぞれの特徴があります。たとえば、メンテナンス性に優れたフレームワーク。チームワークでこそ威力を発揮するフレームワーク。とにかくシンプルを追求したフレームワーク。いろいろありますね。当然、そこにはそれぞれのメリット・デメリットがあります。

「CakePHPはここが問題（だから使わない）」ではなく、「CakePHPである必要がない」から使わないのです。
繰り返しますが、まずはいろんなフレームワークを試してください。
その上で、「CakePHPでなければならない理由」を考えてみてください。
ないとは言い切れませんが、そんなものはほとんどの状況で見つけることはできないでしょう。
あるとしたら、「既存のプロジェクトで採用されていたから」「チームに既に浸透しているから」くらいじゃないでしょうかね。

お礼

お説ごもっとも。納得のご指摘です。
ただ、数あるphpフレームワークについて、主だったところだけでもCake/Symphony/Zend/Code Igniter/Fuel。。違いがよくわかりません。
内容や違いを明快に説明してくれるサイトをさがしても、発見できませんでした。
（自分の検索の仕方が悪いのだと思いますけど。。）

自分としては、もっとも入門書が多く、見た目簡単そうで、Webサイトが充実し、Q&A掲示板などが活発そうなCakeを選びました。
（教えてGooのphpカテゴリにはフレームワークの話題はほとんど出ませんが）
定番のフレームワークがない、というのが一番の問題のような気がしてきました。。。

回答No.2

noname#177743

私自身は基幹業務の経験はないのですが、CakePHPの案件は前にやったことがあるので参考までに。

>相手が学習コストを嫌っているだけのように思えるのですが
　↑
だろうと思います。「CakePHP 導入実績」とか「CakePHP 導入事例」で検索すれば、既に2007年ごろから続々と導入されていることがわかると思います。「そもそも実開発で、CakePHPはほとんど採用されていない」という前提自体が、半ば思い込みに近いもののように思えます。

外部協力会社数社というのは、PHPを中心にされているところでしょうか。あるいはJavaなどのエンタープライズ中心でしょうか。Javaが中心のところだと、（Javaに比べると）全然導入は進んでないという印象をもたれるところは多い気がします。特にエンタープライズ中心に開発をしているところからすれば、Javaに比べればPHPそのものが「全然使われてない」わけで、もともと中小の開発事例が中心のPHPですから、大手からすれば「全然使ってない」といわれるのもやむを得ないかもしれません。

ただ、実際には既にPHP自体はJavaを上回るほどにWeb開発で使われています。対象とする市場が違うために基幹業務系の人には「使われていない」と思われている、ということはあるでしょう。

外部協力会社の方々がいっていることは、CakePHPに限らず、例えばRailsについても全く同様にいえるわけで、だからといって「Railsは現場で全然使われてない」という人はいないでしょう。やはり自身の業務において対象に含まれていないので目に入らない、という面が強いのではないのでしょうか。

>CakePHPはここが問題

これは必ずしもCakePHPの問題ではありませんが、おそろしく簡単にMVCベースのアプリケーションができてしまうため、さまざまな細かい詰めをおろそかにしてしまう面はあるかと思います。例えばエラー画面がCakePHPデフォルトのままだったりするサイトはけっこうあるようです。CakePHPがダメというのではなく、逆に手軽に作れてしまうため、私も含めへっぽこ開発者でも利用できるため、結果として「CakePHPで作ったサイトは質が悪い」と印象を持たれている感はあるかも知れません。

また、CakePHPは、１年ぐらい前？に2.xにアップデートされたのですが、この段階でかなりな仕様変更があり、旧バージョンからの移行でけっこうあちこちトラブっていました。この種のフレームワークはメジャーバージョンアップ時に割とドラスティックな仕様変更があったりします。JavaのStrutsが数年前に1.3.8でアップデート完全停止したのに未だに使われていたりするのとは対照的で、とにかく変化のスピードが速いため、枯れた技術を重視する基幹業務系では毛嫌いするところはあるでしょう。

後、大規模なところになると、例えばTwitterがRailsからJava（Scala）に移行した例などから、「ライトウェイト言語は小さなサイト用だ。スケーラビリティを考えれば最終的にはJavaか.netだ」と考えているところは多いと思います。基幹業務系だと、やはり「ライトウェイト言語に対する信頼性」を疑問に思っている面はあるのではないでしょうか。

全体として、「CakePHPそのものに大きな問題があるとは思えないが、基幹業務のような枯れた技術を最優先する分野では将来的なことまで考えると避けたほうが無難」ということなのだろうと思いました。

お礼

長文のご回答、有難うございます。
今回の案件はBtoCサイトで、運用もVPS/LAMPベースだったため、自分自身あまり経験のないphpを使うにあたり、協力会社さん任せの実装にしたくなかったために、こういう話題になっています。
正直言いまして、協力会社さんは基幹業務系の経験が少なく、コンシューマ向けの開発が多いように聞いていまして、それなのにフレームワークに懐疑的。エッ？となった次第です。
もう一度先方とよく話し合ってみます。
ありがとうございました。

回答No.1

gogogorogoro

まず、PHPにおいての絶対的なフレームワークが存在しないこと。(RubyにおいてのRuby on Railsの様な)
CakePHP以外にも定番的にPHPで使われるフレームワークには
・symfony
・Zend Framework
などが存在する。

MVCは別にしてPHPにおいては公式のライブラリ集となるPEARがある意味フレームワークとも言えなくもない。

>皆様の中で同様に、「CakePHPはここが問題（だから使わない）」というお考えをお持ちの方がいらっしゃいましたら、具体的な問題点をお聞かせ願えないでしょうか？
CakePHPに限らずにフレームワーク全般に言えることだけど
PHPにおいて先に書いたけど絶対的なフレームワークが存在しないことから
あるフレームワークが絶対的な存在となったときにその他のフレームワークが淘汰されてしまう可能性がある。
そうなるとレンタルサーバのような環境だとPHPのバージョンをユーザが選べない場合
淘汰されてフレームワークが更新されないと今後そのフレームワークを使っているシステムが使えなくなるかの有為が出てくる。
PHPはバージョンアップでの機能変更によって過去のソースがうまく動かなくなることがしばしばある。
たとえずPHP5.3系になったときにいくつかのCMSなどで問題が発生したこともある。

>MVCモデルや、テンプレート対応は十分に可能で、高品質で迅速な開発が可能だそうです。
VにあたるテンプレートエンジンはPHPにおいてはSmartyが絶対的な存在とまでは行かなくても
かなりの人気を持っている。
フレームワークにおいてもVに関しては自前の物以外にもSmartyがわざわざ使えるようにしてある物も
あるくらいに人気がある。

後、根本的事になるけどPHPだけの開発者にはMVCが馴染みが無くて嫌っている場合もある。
PHPにおいてフレームワークはMVCモデルで作られているとか言ってもVは比較的簡単に分けれるけど
MとCが明確に分けづらい気がする。
PHPのフレームワークはMVCぽい事をしているだけ。
(javaや.net系だとオブジェクト指向のためにしっかりオブジェクト指向で作られたプログラミング言語だけどphpは構造型プログラミング言語にオブジェクト指向をとってつけた言語仕様のためだと個人的には考える。)

お礼

「定番のフレームワークがない」
「PEARがある意味フレームワーク」
「テンプレートエンジンはPHPにおいてはSmartyが人気」

なるほど。。あえてMVCを採用しようという動機が弱いのですね。。
自分としては後々メンテが楽そうなので、Cakeがいいと思ったのですが。。
難しいものですね。