私がPHPでオープンソースのフレームワークを使う経緯と理由

皆さんPHPでフレームワークはどんなのを使っていますか?
CakePHPとかLaravel、Symfony、CodeIgniter・・・昨今はいろいろなフレームワークがあって悩みますよね!
でも意外と「会社のオリジナルフレームワーク」だとか「自作のオレオレフレームワーク!」という方も多いんじゃないでしょうか?

私が新卒で入社して6年ぐらいまでは自作のフレームワークを使っていました。
でも今はタイトルの通りオープンソースのフレームワークを使っています。

今回は私が自作のフレームワークからオープンソースに移った経緯と理由を書いていきます。

オープンソースを使う経緯

最初は自作のフレームワークを使っていた

「フレームワークっていつサポート切られるかわからないし、インストールとかめんどくさい。
ライセンスもいつ変わるかわからないしな・・・。
自分で作っちゃったほうが拡張しやすいから、作っちゃお!」
という安易な自作のフレームワークを使っていました。

「PHPパーフェクトガイド」とか技術書をあさったり、当時あったフレームワーク(名前は忘れた)を分解したりして自作したものです。
自作だと1回作ってしまうと拡張するのが超簡単だったりするので、その当時はかなり重宝していました。

無理やり機能追加による複雑化。仕様書も忙しくて作れない

しかし長く使用していると、作成時は気が回っていなかったセキュリティとかセッション管理の機能とかで問題が出てくるようになりました。
当然すぐに機能の追加。
でも後付けで無理やり作るので、変な構造になってしまいどんどん複雑化していきます。
しかも仕事も次から次へと降ってくるので、仕様書を作る暇もありません。
作った本人しか全容を把握していないし、時間がたつと何を作ったか忘れてしまうこともありました。

でも、自分一人でプログラムを組む分には何とかなっていました。

初めてのチームプレイ!仕様説明がめんどくさい。そして無茶ぶりへ

ある日、会社としては比較的規模の大きい開発の仕事がきました。

今まで1プロジェクトにデザイナーとエンジニアが1人づついれば回っていたのですが、今回のプロジェクトはエンジニアを3人も投入します。
しかもそのうち2人は会社に入ったばかりの人。

仕様を説明しなければいけないのですが、当然1時間やそこらで説明しきれるものではありません。
しかも仕様書もない。

だから私は最終的に、
「ソースを見て理解して! 質問は受け付けるよ!」
と結構な無茶ぶりをすることになりました。

質問地獄。さらに発覚するコアシステムの不具合

無茶ぶりしてすぐに質問地獄にあいます。
よく使う機能ならすぐに説明できるのですが、普段使わない機能は思い出すのに時間がかかります。
しかもいろんなプロジェクトを経てできたフレームワークなので、昔のプロジェクトでしか使わないような機能も残っていたりしていろいろな弊害を生み出していきます。

さらに不運が起きます。
フレームワークのコアの部分で不具合を発見したのです。
当然パッチなんてものはどこにもないので自分で作るしかない。

自分の生産性を高めるために作ったフレームワークによって、自分の仕事が全然進まないという事態に陥ったのです。
幸い2人のエンジニアはスキルが高めだったので、不具合が直った中盤以降は質問も減って何とか納期に間に合わせることができました。

もう面倒見てられねぇよこんなフレームワーク

このプロジェクトで「自作フレームワークはチーム開発に向かない」と気づきました。
会社のメンバーとも話して自作フレームワークを捨てて、オープンソースのフレームワークを使うことが決定したのです。

さようなら、オレオレフレームワーク・・・

オープンソースフレームワークを使う理由

フレームワークの仕様書を作らなくていい

はっきり言って、これが一番のメリットです。
多くのエンジニアやプログラマーにとって、プログラムの仕様書のドキュメントを作る時間が一番キツイ仕事ではないでしょうか?
でもチーム開発には仕様書がないと大変です。

オープンソースのフレームワークには必ず仕様書があり、チュートリアルがあります(怪しいフレームワークを除く)。
英語の場合も多いですが、最近では日本語のドキュメントもあるので安心できます。
仮に英語しかなくても、サンプルコードみたいなものが書かれていることが多いので何とかなるでしょう。

仕様書を作る必要がないだけで、かなりの時間節約になるはずです。

わからないことがあっても、Google先生に聞ける

自作のフレームワークだと不具合があった時、ソースコードをにらめっこして自分で特定しなければいけません。
それがプロジェクト用に追加した機能の不具合なのか、元からあるフレームワーク自体の不具合なのかを特定するのはかなりの労力を使います。

その点オープンソースのフレームワークであればGoogle先生やコミュニティで検索することができます。
比較的簡単に問題を解決できるでしょう。

Composerを使えば簡単にフレームワークを共有できる

自作フレームワークは自由度が高いゆえに、プロジェクトごとに進化を遂げていることが多いです。
しかもプロジェクトごとにメンバーが違ったりするので、誰のパソコンのフレームワークが最新なのかわかりにくくなっていたりします。
最新フレームワークを持っているメンバーのPCからデータを抜き出して、チームに配るのも一苦労。

オープンソースならComposerで簡単にみんなが共通のフレームワークを利用できるので安心です。

チーム開発やオフショアするときにすごい楽

オフショアで開発するときは本当に楽になります。
自作フレームワークだと仕様書を作らないといけないし、下手したら英語で作る必要が出てきます。
はっきり言って「そこ力と金使うところじゃないから!」って思いますよね。

「CakePHP使って」「Laravel使って」

と言えば解決するオープンソースは偉大です。

最後に

自作フレームワークは悪ではない

勘違いしないでいただきたいのは、自作のフレームワークを作ることは悪いことではありません。
オブジェクト指向の勉強になるし、コーディングスキルも上がります。

ただ、仕事で使うのはあまりにも向いていないということです。