会社のフレームワークをLaravel にしたという話
このたび、プラムザでは長年親しんできた開発フレームワークを廃止し、Laravelベースのものに一新しようという話になりました。
、、、という話をしようと思うのですが、もうすっかりコードを書くことから遠ざかってしまいエクセル方眼ＳＥに成り下がっている私としては、フレームワーク選定の詳細な基準や、実際にサンプルを作ってみた話とか、選考対象になった各フレームワークのメリットデメリット等々までレポートする能力がありません。
そっちに興味がある方は、そのうち始まるであろう弊社PGの書くブログをお待ちください。
で、私の記事はもう少し大雑把なお話というか組織論的な話になってしまうことをあらかじめご了承ください。
----
なんでも即断即決が好きな私は、何か大事なことを決定する際に「民主的な話し合い」で決めるなどと言うのは最悪だと思っています。
もし多数決をするのであれば、「この決断には誰が適任か」を決定する手段としてはいいかもしれませんが、決断自体を多数決で行うようなことをすれば、その決断は人格を持たず、誰の責任でもなくなり、もしうまく行かなかったときにそれを再分析し、次のさらなる迅速なアクションが取るということができなくなります。
これはもう前から言っていることなんですが、フットワークが軽く、効率化を追求し、最大の効果を上げていくような組織ほど民主的ではないです。お客さんのためを思えば当然そうなります。
こういう基本的なことは、学校で教えておいた方がいい、というか私自身教えておいてほしかったと思うのですが、そんな話は今回の主題ではないのでこの辺で。。
----
前回のフレームワークを決定した時の話をします。
それを決定したのはおそらく今から7～8年前(2006年とか2007年とか)だと思います。
当時、弊社はMicrosoft系のActiveServerPage(aspやasp.net)から徐々にPHPにシフトしたものの、PHPの方は新しい試みで誰も先駆者がいなかったので、PGが各自、自分の好きなように(というかwebや本でたまたま見つけたように)組んでいました。
ある意味一番楽しい時代だったかも知れませんね。
ところがそのようなことをしていると、何かの理由で社内でPGの変更が必要になると、容易にソースを引き継げないという事態に陥りました。
また、誰かに注意して直させたはずの致命的かつ単純なバグが、別案件で何度も再発するということも起きました。
逆に誰かが工夫して編み出した便利機能も他のPGには利用されることはありませんでした。
そこで私が、当時いた相当出来るPGのI君に
「ちょっと、こういうのまずいよねぇ、、、I君、会社全体で使えるフレームワークを作ってよ」
と言ったような気もしますし、言ってもいないのにI君が勝手に作りはじめ、後から「それいいね！会社で使おう！」と都合のいいことを言ったのか、忘れてしまいましたが、いずれにしても後半はきちんとそのI君にフレームワークづくりをお願いし、完成したそれを全社に浸透させ、全PGでこれまでずっと使い続けてきました。
このフレームワークは基本的にZend Framework 1をベースにしているものですが、実はユーザー管理やグループ管理、メニューの権限管理なども含んだハーフパッケージで、非常に重宝しました。
「この部分はうちでやればタダです。」
という営業文句はお客さんにかなり刺さりました。他社の見積りではたいていそのあたりだけで1人月くらいは乗ってきてましたので。
バグも導入当初はあったと思いますが、3年も使い続けてくればほぼゼロになり、以後とても安定した成果物を生産することができました。
----
ところが。
会社の恥を晒すようではありますが、このような出来の良いフレームワークに頼っているとどうしても技術力と言うのは退化してしまいますね。
突然お客さんから指定された言語やフレームワークで実装したらバグを連発したり、実運用してみたら物凄く処理が重く、開発会社のお客さんにソースを見られて「これは初心者が作ったのですか」と言われたりする事件も何度か起きました。
これはそのフレームワークを作ったころに私が言っていたことでもあり、I君をまったく責められないのですが
「いつも悩むような処理、よくバグを出してしまうような処理はもう考えなくてもいいようにしよう」
という方針をそのまま具現化したフレームワークを使っていたら、いつしか社内にはそのフレームワークしか使えないPGが多くなり、オリジナルでページングもEメールのバリデーションも書けなくなってしまいました。
これは、やはり失敗です。
やはり、1人の出来る人間が作った方法を、別の人間が何も考えずになぞる、というのは、こと頭を使ってなんぼの開発チームとしてはやってはいけないことでした。
もちろん、
- 他人の仕事を引き継ぎやすくする
- 同じ不具合を二度と起こさない
- 誰かの工夫をみんなでシェアする
というテーマは、組織で開発している上では絶対に必要です。これがないと、組織は組織である意味がなくなってしまいますから。
ただ、目指すべきは、「誰か決めてくれたら僕は従います」という体制ではなく、みんながフレームワーク内の1行1行のソースにまで当事者意識を持つべき体制でした。
「ここはコアの部分だから手が出せません」ではなく、そこが要件に合わないのであれば、潜って行って直すような覚悟が必要だと思います。我々はフルスクラッチャーなんですから。
ということで、Zend Framework 1もサポート期間が切れるようなので、これを機に開発チーム全体でどのフレームワークを使ってやっていくか検討するように言いました。
私や取締役が出席すると会社のいいように誘導してしまいそうなので(実際はそんなことはないのですが、そうとられたくないので)、敢えて出席せず、みなフラットに意見を出し合って決めてもらいました。
、、、で、決まったのが『Laravel』という聞いたこともないフレームワーク、、、
魔法少女みたいだけど、いいじゃないですか。父さんは何も言いません。
でも一つ言えることは、この決定はとても重いということです。
今後3年4年と使い続けて行くフレームワークの選考にあたって、きちんと意見を出す場が持たれ(弊社にしては珍しく、45分会議を3回もやりました)、そこで決定したのだから、途中で少々の苦しみがあったとしても「俺、本当はあっちの方がよかったんだよなぁ」とか言わず、頑張って使い倒していかなければいけない、ということです。
今回のような議案については、「出来る人の独断」よりも「話し合って決める」ということが大事なのでしょうね。
会社としても大きな成長をしたと思います。
株式会社plumsa(プラムザ)では、システム開発に関するお悩みを受付中です↓