フルスクラッチとは、既存のコードを使わずに
ゼロからソフトウェアを開発するIT用語です。
なんとなく響きはカッコよさそうですよね。
「フルスクラッチで作ります！」
というと、
他人が作ったライブラリやアルゴリズムを
利用しなくても自分でゼロから作れるんだという
アピールにもなるからです。
でも、
自分が作ったものが他人の手によって機能追加や
仕様変更される可能性が高いソフトウェアの場合、
フルスクラッチだと困ります。
なぜかというと、
「どういう理由でこのコードがこの場所にあるのか？」
「変数や関数、クラスの命名ルールはどう決めたのか？」
などといったプログラミング上のルールや設計方針が
他人にはわからないからです。
すると、
ソフトウェアに手を入れるたびに（人が変わるたびに）
コードの秩序が崩れていきます。
秩序が崩れたコードは矛盾や無駄が混入しやすいので、
不具合（バグ）の原因を生みやすくなります。
一見して正常に動いているように見えても、
実は穴だらけだったりします。
特定の条件で操作すると仕様通りに動かないとか、
よくあることです。
これ、言ってみれば
「元々正しく作ってあったものを壊している」
ことにほかなりません。
ずっと同じ会社の同じ開発チームで開発後の保守対応も
やっていく場合なら、個人の慣習やスキルに依存する
フルスクラッチはなおさら歓迎されません。
ウェブサイトもそうです。
いくらHTMLやPHPに精通しているからといって、
「自分ルール」
の押しつけにほかならないフルスクラッチで作ると、
納品して自分の手を離れてから機能追加や仕様変更が
あったときにどんどん品質が下がっていきます。
自分はもう手を離れたからいいかもしれませんが、
困るのはお客様です。
最初に納品されたものに手を加えるほど品質が下がり、
不具合（バグ）を直すコストがかさみ、
そのために運用を停止しなければなりません。
その期間はウェブサイトが利用できないので
サイトから得られたかもしれない売上げを逃します。
お客様に「無駄な出費」を強いてしまうわけです。
プログラムを触る人はそこまで考えないといけない。
作って終わりではなく、
作ったあと他人の手に渡っても品質が落ちないように
「理路整然としたコード」
「コードの理由と目的がわかるコメント」
「再利用性の高いコンポーネント」
「依存関係の少ないモジュール設計」
「統一感のある命名規約」
といった、表には決して見えない品質の重要性を
しっかりと認識して作ること。
それがプロの仕事です。
そこで役に立つのが「フレームワーク」です。
フレームワークを採用して作れば、
誰が作ってもフレームワークのルールに従った
プログラムになります。
だから、品質の低下を抑えることができます。
フルスクラッチで作られたウェブサイトを
１０年も運用していると、
もう中身はぐっちゃぐちゃになります。
家電製品の寿命は１０年とか言われますが、
ウェブサイトも１０年経てば
インターフェースの流行りも変わりますし、
ちょっとした機能追加をするのにも
必要以上の手間（ぶっちゃけ金です）を要します。
より効果的なフレームワークを取り入れて
再構築するべき時期だと思います。
家電は買い替えるのに、
ウェブサイトの再構築は渋る。
それってすごくおかしなことなんです。