私は約7年間、PHP でプログラミングをしてきました。その間に、私が発見したもの。それはフレームワークとライブラリ（コンテンツ管理プラットフォーム周辺のエコシステムなど）、そして、PHP を選んだプログラマーたちの巨大コミュニティです。私と同じツールを使っているにせよ、いないにせよ、プログラマーたちの多くは、本当の友人になりました。私が参加したカンファレンスでの基調講演の多くから判断するに、私たちはお互いに助け合い、学び、成長し、より良いソフトウェアを構築し、キャリアにおいて次のステップを踏み出すときには、一丸となってお互いをサポートしてきたと思います。そう信じているのは、私だけではないでしょう。

言語としての PHP は、「まっとう」なプログラマーたちに、皮肉を言われ、馬鹿にされ、過小評価され、批判され、嘲笑されて、最低の極みともいえるような評価を受けてきました。そのプログラマーたちは、我々をアマチュア集団とみなしています（彼らには過去に何か嫌な思い出でもあるのかもしれませんが、私は今、それについては何も知らないという立場で話をしています。PHP 7 が PHP をより成熟した言語にしたのと、まったく同じことですね）。それでも、PHP はそんなことには動じません。コミュニティはより強固なものとなり、新しい製品、ライブラリ、ツール、機能を構築し続けています。

しかし、PHP コミュニティは壊れてしまいました。私たちの大きなエコシステム内には、変わりゆくものを認めようとしない人たちの派閥が存在します。彼らは、自分たちの偏見を頑なに守り、広い意味でのソフトウェアコミュニティでよく見かけるような、誹謗中傷をおこなっています。辱めと信用の失墜のために、仲間たちの手で無情にも個人情報が世界に晒された例や、プライベートな会話が公になってしまっている例もあります（彼らのプライベートな面が誰かに悪影響を及ぼすかどうかはともかくとして、こういった会話は秘匿されておくべきです）。

私はこの問題が起こっているサブコミュニティのメンバーではないので、当記事では細かくは触れません。とはいえ私は、より広範囲な PHP コミュニティのメンバーですから、PHP 内部の小さな派閥の問題は、PHP 界全体の問題だと認識しています。ひとつのプロジェクトだけに参加している人というのは少ないので、意見や批判、解釈などは、直接関与していない人たちにも伝わるものです。よって、サブコミュニティ内の軋轢が、広範囲に影響するのは当然のことだと思うのです。

もちろん、直接的にも間接的にも、多くの人に影響を及ぼす大きな問題は、Laravel 、Symfony フレームワーク、Doctrine ORM の支持者の間で、軋轢が高まっていることです。他の言語を学び、使用しているプログラマーが PHP デベロッパーを見下しているのと同じように、多くの Symfony また Doctrine の支持者が、Laravel について、同様に批判的な発言をしています。

それに対抗して、Laravel の支持者たちは、激しい敵対心を持って、批判に対し攻撃的に応戦する傾向があります（建設的な対応とそうでない対応、どちらの意味でも）。こういった状況では、サブコミュニティがサイロ化されていくことも、またサブコミュニティ同士が、お互いへのやんわりとした批判を、自分たちのメソッドに対する全面的な攻撃と認識してしまうのも当然です。

プログラミングの経験がある人のほとんどは、何らかの理由で、自分の使っているコードを批評した経験があるでしょう。批評といっても、「なんなんだよこの使えない言語は？」から「こういうときは SOLID 原則やデザインパターンを適用すれば、時間の節約にもなりますし、イライラもせずに済みますよ」まで、いろいろです。どのような批評をするか、また批評をどう受け止めるかは、あなたがプロとして成長するための基盤となり、また周囲の人たちがあなたをどう評価するかの決め手となります。リーダーに従い、その能力を認める人たちが、仲間たちに対してどのような振る舞いをするかを決めることが、コミュニティのリーダーとしての一番大事な仕事なのかもしれません。

ベテランプログラマー、コミュニティの長老、プロジェクトリーダー、ロールモデルたちが、Twitter や Reddit などのプラットフォーム上で、叩き合いをやっています。あるフレームワークのスケーラビリティについてや、あるライブラリのコアメソッドの行数などについて、陰険な批判のコメントが見受けられます。一連のやりとりを読んだ人は「この人たちは、外野から、このフレームワークやツールを使うなと主張しているのだ。そして、その選択が絶対に正しいと思ってるのだ」と思うに違いありません。

要は、こういった議論を続けるということは、よくある問題の解決に対し、他のアプローチを試してみるというチャンスを、経験の浅いデベロッパーから奪うことなのです。率直に自分自身を表現すること、周囲の人たちに笑われるのを恐れずに、それぞれのフレームワークの利点と落とし穴について、議論する機会さえ与えないということなのです。彼らが仕事をする上で、どうやったら適切なツールを選択していけるのか、学んでいこうとするのを妨げているのは、私たちなのです。

間違いなく、私たちはキャリアの前進を妨害しています。彼らにとっても、PHP デベロッパーのエコシステムに対しても、有害です。またこれは、PHP でのウェブアプリケーションの構築を学び始めた、新入り の PHP デベロッパーにとっても障壁となります。すでに多くの若手プログラマーが PHP に対してネガティブなイメージを持っているという事実を考えれば、これ以上の参入障壁など、あってはならないはずです。

恥ずかしながら、私もそのうちの一人でした。自分と同じことをしている集団が優位な状況で、そのトレンドの波に乗るのは容易いのです。ロンドンで行われた Symfony meetup では、誰かが何かの流れで Laravel について発言して、会場が大爆笑に包まれました。次の日、新人出席者の一人が、それによって肩身の狭い思いをしているとコメントするのを聞くまで、私は何も感じていませんでした。Symfony ファンが落としたボールが、誰かに不快感を与えてしまったことに気づいた瞬間でした。そして私も、そのユーザーの内の一人だったのです。詳しくはこちらを読んで下さい: https://www.meetup.com/symfony/events/229755129/

Symfony Live London カンファレンスの後、ざっくりとではありますが、私は Fabien Potencier に、我々のコミュニティが分裂してしまっているという懸念について話しました（注：Symfony が推奨フレームワークとはいえ、Laravel v4 & 5、Zend も私の専門です）。私は Fabien の反応を深く掘り下げるつもりはありません。理由はいくつかあるのですが、ひとつは、多くを推測してしまうと、彼の過去の行いに対し「ああすればよかったのに」などと批評することになってしまい、彼に対しフェアでないからです。次に、彼は私に、同様のテーマで記事を書く予定があると教えてくれたからです。しかし彼は、Symfony 1.x の開発者が Zend との比較を行っていたとき、多くの批判が寄せられていたという事実を教えてくれました。

Symfony 1 を知らない若い人に説明すると、Symfony 1 には、Doctrine 1 と ActiveRecord パターンが実装されていました。デフォルトで多くの追加機能が含まれていて、ビジネスロジックをフレームワークに結合するのが非常に容易でした。あなたの仕事を楽にしてくれる待望のツールとして、説得力のあるフレームワークだったのです。

Symfony 2 では、すべてがガラリと変わりました。Symfony を使用している開発者は、ツールを選ぶ際や、プロジェクトの詳細を決める際、より多くの選択肢と柔軟性を求めていました。オリジナルがもう目的を果たしていないとわかれば、他のライブラリを簡単に組み込めて、簡単に交換できなければならなかったのです。

Symfony の本質は、バージョン1から2になるまでの間で、オリジナルとは別ものと言えるほどに、急激に進化しました。すべてのツールがパッケージングされ、Symfony 以外のパッケージとの相互運用性の面からいえば、ある意味無礼とも言えるほどの独善的なフレームワークが、変化を遂げたのです。

Symfony は長い道のりを歩み、再利用可能なパッケージと、コンポーネントのセットに変換される形に進化しました。PHP-FIG の推奨事項を取り入れれば、他のフレームワーク、ライブラリ、CMS システムに、コンポーネントを簡単に組み込むことができます。Symfony の開発者は、フレームワークが達成されたことをとても誇らしく思っていて、どのようにそれをやり遂げたのか、ノウハウを分かち合いたいと考えています。

私は Laravel のドキュメンテーションについて、Symfony に比べてアクセスしやすく、フレームワークとしても、はるかに入門者に優しいと感じています。かつて話したことのあるデベロッパーも、ほとんどが私の意見に同意してくれました。近頃は Symfony よりも Laravel のほうがカラーが強いので、ドキュメントが抽象的になることもなく、与えられたツールで、直接的に目標を達成することができるでしょう。

Laravel について、初心者のフレームワークや RAD （Rapid Application Development）専用のツール、というラベルを付けたがる傾向が強く見られますが、複雑なプロジェクトでは使うことをおすすめしません。そんなことを言えば、Laravel ユーザーからは当然、「〇〇のサイトでも使われてるんだよ、うるせえな」と返ってきます。 Doctrine ユーザーは「ActiveRecord なんかとっくに削除したよ、お前のとこの ORM 本当使えないな」と言い返します。そしてあらゆる人が「はぁ？ファサード？」と割り込んできます。公園で「俺の親父にかかれば、お前の親父なんて一発なんだからな」とやり合っている子供を見ているかのようです。

Laravel と Eloquent に対する個人的な意見になりますが、データベースに外部キーとインデックスを追加するときに、余計な手間がかかるのが不満です。データ構造の設計において、このプライオリティはかなり高めにしておくべきだというのが、私の考えです。私は別会社から Laravel のプロジェクトを引き継いだ経験が数多くありますが、ひとつとして外部キーやインデックスを持っているものはありませんでした。もちろんこれは、データの整合性から見ても、パフォーマンスの面から見ても、問題になりえます。

また私は、Laravel とその周辺のトレーニングリソースの多くは、ユーザーがコードをフレームワークに強く結びつけすぎているように感じます。以前の職場では、Laravel 4 から Laravel 5 への単純なアップグレードであるはずの作業に、何ヶ月もの時間を費やしているデベロッパーがいました。彼が時間を割いていたのは、コントローラ上のファイルやロジックのファイルをコピーし、書き直す作業でした。もしコードが分かれていれば、この会社はアップグレードにかかる費用を大幅に削減でき、そのデベロッパーはもっと早く新機能の開発作業に移れたはずです。

Laravel は、創始者の主張どおり、大規模なアプリケーションに利用できると思います。しかし、アプリケーションを拡張する際、ドキュメンテーションに何を見出していくのか、その試行錯誤の経験を十分に積んでいるデベロッパーでないかぎり、そんな使い方をしようとは思いつきもしないでしょう。

はっきり言ってしまえば、コードを Symfony のコントローラーに結合するのは簡単です。しかし Symfony のコミュニティの人たちは、なぜ結合すべきでないのか、その理由を嫌というほど知っているように、私には思えるのです。Symfony ユーザーが、コードを分割するというアイデアを嘲笑しているケースは一度も見たことがありませんが、Laravel ユーザーがそのプラクティスを馬鹿にして笑っている場面は実際に見てきています。おそらくこのユーザーというのは、コードの分割について十分な知識があって、現在のプロジェクトのスコープには収まらない人たち、もしくは先ほど言及した、集団思考の波に飲まれている若手デベロッパーでしょう。その優れたアイデアを認めようとしないリーダーに、彼らのチャレンジ精神は削がれてしまっているのです。

コード分割から派生して起こったこの議論は、より深刻な問題の一症状に過ぎません。我々デベロッパーが持つ問題の核心は、好みのツールをみずから選択し、同様の問題を同様の方法で解決した人たちと、団結しすぎてしまうことです。よく知っているものを使い続けることによって、自分自身に制限がかかってしまいます。同じ思考を持つ集団の中に浸かりきることで、コーディングの成長は止まってしまいます。ゴールデンハンマーを使うことで、みずからのキャリアの妨げとなりえる、足かせを作り上げてしまうのです。ある方法で何かを解決したからといって、他の誰かのアプローチがより良いとか、悪いということはありません。そこには、違いがあるだけなのです。

私が最も懸念しているのは、経験の浅いデベロッパーの選択に、潜在的に及ぼす影響の可能性です。人間誰しも、誰かに個人的にアドバイスをした後、その人が同じ道をたどれば、満足感をおぼえるものです。しかし、若いデベロッパーたちに、我々のバイアスをかけて、「面倒くさいし別の方法は試さなくていいか」と思わせてしまってはいけません。そのアドバイスと、「PHP でプログラミングなんかするなよ」と伝えることに、一体何の違いがあるというのでしょう？

私たちは環境を有害化しています。学んだり、実験したり、遊んだり、開発しようとする人たちの邪魔をしています。私たちがすべきことは、経験に基づいてアドバイスをし、他の解決策を試そうとする人たちのサポートをすることではないでしょうか。

あなたの上に立つ人が、どのように人を批判し、また批判を受けるのかを見てみましょう。そして、考えてみてください。「これは建設的な、コミュニティを良くするためのフィードバックだろうか？この人は、私が何かを学び取るべき人だろうか？」と。

コミュニティのリーダーは、こう考えてみてください。「私は、自分の足かせを周囲の人にも嵌めてはいないだろうか？自分の選択が、他の人に悪影響を及ぼしたことはないだろうか？」と。保守的なネット上の叩き合いや怒りの感情は、集団の中で発生する問題を解決してはくれません。私たちが今やっていることは、人々から、このグローバル・プログラミング・コミュニティの仲間になろうという意欲を削ぐ行為です。