home
スポンサーリンク
2015-11-17

いま一般的なIT技術の常識が、必ずしも最適解とは限らない

情報技術を正しく取捨選択し、常識にとらわれない柔軟な発想をすることが、大事だということです。

ITエンジニアのくせに常識にとらわれている人が多すぎる

私は最近、よく思います。ITエンジニアという、仕組みをゼロから作り上げる職業に就いているくせに、常識にとらわれている人が多すぎるということ。これは日本人だからなのでしょうか。

例えば、PHPでちょっとしたWebアプリを作る案件に従事することになったとします。

多くのエンジニアはそこで、第一声、

PHPのフレームワークは何にしようか

とぬかします。バカかと。

いや、別にPHPのフレームワークが悪いとか、そういうことを言っているわけじゃなく、本当にそれがあなたの中での最適解なの? 考え抜いた答えなの?? と問いたいわけです。

そのフレームワークを使うまでもないプロジェクトで、わざわざフレームワークを使う理由はなんなの? と。

ITエンジニアのような知識労働者が、考えるのをやめて、定石どおりにしかシステムを作らなくなってしまったら、もう存在している価値などないのです。そのうちコンピューターが代わりに仕事をしてくれるようになるでしょう。

自分で現状の最適解を導き出せないとしても、インターネットの海を探せば、様々な選択肢と知識が得られます。

古い技術を前提にして話を進めるのを、もういい加減やめませんか?

古くからある技術は安定しているという幻想

どのような要因をもってして、安定したシステムが納品できるのでしょう。

それは設計者が古くからある安定した技術を使っているから、ということだけというのは絶対にありえません。設計者がきちんと技術を理解し、全体のスケーラビリティを考えてアーキテクチャーを選定したからに他なりません。安定した技術を使えば失敗しないなんて考えているのなら、それは大間違いです。

事実、私は当たり前のようにPHPフレームワークを導入し、破綻したプロジェクトをいくつか見てきました。MVCモデルのアーキテクチャーは、それだけですべてのプロジェクトに万能に対応できるようになるというものではないのです。

にも関わらず、プロジェクトの規模や特性を考えずに、いとも簡単にフレームワークの導入を決めるプロジェクトが多すぎます。

jQueryで作られた混沌としたJavaScriptの多さ

Webのフロントエンド(HTMLやCSSやJavaScript)の世界でもそうです。バックエンドに比べ、まだ技術の歴史が浅く、未だに数多くの大幅な仕様策定を繰り返していますが、かつては当たり前のように何も考えずに導入されてきたものがあります。

それが、jQueryです。

jQueryを導入することで、「HTML」と「ビジネスロジックを含むJavaScript」との分離を容易に図ることができます。

これは、デザイナーとフロントエンドエンジニアの担当範囲を明確に分けることができ、なおかつ既存のHTMLを容易に再利用できるため、多くのプロジェクトで広く使われてきた構造です。

しかしながら、現実に目を向けてみると、世の中にはもう修正などの手がつけられないほどに複雑化し、拡張性が皆無で、混沌としたjQueryを用いたコードが非常に多いです。

jQueryを使えば、それでいいなんてことは絶対にあり得ないのです。

確かに可読性が向上し、生のJavaScriptに比べれば学習コストが減少するかもしれませんが、きちんと設計しなければそれらのメリットも意味を成しません。

そして現在では、Backbone.jsやAngularJS、React.jsといった、jQuery以外のライブラリ/JSフレームワークが多く登場し、広まってきています。そしてjQueryでは成し得なかった、大規模プロジェクトの拡張性の高い実装や、SPA(シングルページアプリケーション)のような複雑な実装も、比較的簡単にできるようになりました。

決してjQueryが悪いとDisってるわけではありません。小規模WebアプリやWebサイトなどではまだまだ現役の技術です。

私がDisっているのは、規模や拡張性を一切考えず、何でもかんでもjQueryを導入する、アホどもです。最近は他の選択肢が増えましたから、フロントエンドに関してはそういう人も減りましたが。

そこでバックエンド、先ほどのPHPのフレームワークの例です。

MVCモデルの破綻

PHPのフレームワークに関しては、JavaScriptほどフレームワークごとにアーキテクチャーに差がありません。ほとんどがMVCモデルか、それに近いアーキテクチャーになっています。

MVCモデルは、Webアプリケーションの設計の基本となる考え方です。フレームワークを使わずとも、拡張性を考えてクラス実装すれば、MVCモデルに近い形になるはずなのです。

つまり、フレームワークを使わなければならない理由など、もはやほとんどないのです。「よほど納期に迫られていて且つ担当プログラマーがみんなそのフレームワークに慣れている」や、「セキュリティ設計の簡素化(ミスによる脆弱性作りこみリスクの低減)」などの理由がないと、あまり導入するメリットはないと思っています。

それよりも、きちんとした設計の方が、よっぽど重要なのです。破綻したプロジェクトたちは、みんなその辺りがしっかりなされていませんでした。

また、私個人の考えとして、純粋なMVCモデルは、中規模開発にしか向いていないと考えています。小規模開発の場合、MVCのMとVだけで構成した方が早く、また大規模開発の場合は、往々にしてMVCだけじゃ足りなくなります。

フレームワークが悪いのではありません。フレームワークを使うにしろ、その辺りの設計を考える必要があるということです。

まとめ

PHP/JSのフレームワークを勉強したから、もう最適なシステム設計/実装できる!と思っていたら大間違いです。それは、フレームワークという狭い世界を知っただけに過ぎません。

フレームワークを使用しないピュアなプログラミング言語の学習と、オブジェクト指向プログラミングの考え方なくして、拡張性の高いシステムの設計は不可能ですし、自由な発想は生まれず、最適解を見つけることはできないでしょう。

土台の知識をしっかりと、そしてそこから生まれる柔軟な発想から、システムを設計することこそが大事だと思っています。

MVCモデルとオブジェクト指向プログラミングの考え方については、以前、こちらの記事「オブジェクト指向言語を使っても、オブジェクト指向設計にはならない! MVCモデルとオブジェクト指向」で解説しています。

コメントを残す

スポンサーリンク
スポンサーリンク
ツイートする
シェアする
オススメする
ブックマークする
購読する