「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
第十六回：フレームワークを過信するな
さてさてさて、前回から一ヵ月弱での更新になりました。思いついたら即実行です。即断・即決・即行動！とか言いつつ、今回のネタは半年前から温めていたネタです。罵詈雑言が飛び出しそうなので控えていたのですが、いつか書くだろうし、今でも同じか！と判断して書くことにしました。それでは、どーぞ。超不定期連載「分かりそう」で「分からない」でも「分かった」気になれるITコラムでございまぁす。このコーナーでは、各用語の説明ページでは取り上げにくいIT関連のネタをテーマに、だらだらと思いついたことを書いていきます。皆さんが「あぁ、なんか役に立ちそうな気もするけど、役に立たないかなぁ。でも、もしかしたら役に立つかも」と思える情報を発信できるように頑張ります！
はじめに
栄えある十六回目のテーマは……ピヨピヨピヨピヨ（ぴよぴよ的ドラムロール）……じゃん！
フレームワークを過信するな
です。
「フレームワーク」には、いろいろな意味がありますけどね。
今回は「システム開発を楽に行えるように用意された、プログラムとかのひな形」を意味する「フレームワーク」が題材です。
要は、プログラミングの話で出てくるフレームワークですね。
よって、今回のコラムは、ちょびっとだけ技術者向けの内容です。
なお、先に結論を書いておくと
フレームワークを使うべきか、ちゃんと検討しろよ！ボケ！
です。
知らないふりをして、読み進めてください。
フレームワークのメリット？
フレームワークのメリットは、いろんなところでいろんな人が語っています。
「うんうん、分かる分かる」と同意できる内容も多々あります。
ただ、ですね。
一つだけ、どーーーーーーしても！納得いかないことがあるのです。
「フレームワークを使うメリットは、これだよ！」と声高に語られる中で「ここだけは物申したい！」と思うことがあるのです。
とはいえ、私は小心者です。
その場に乗り込んで「やいやいやいやい！このへっぽこがぁ！適当なことほざいてんじゃねーぞぉ！」と言う度胸はありません。
でも、自己顕示欲はありまくりです。
ということで、こっそり自分のところで「一個人の考えとして」述べることにしました。
よし、これで怒られたときの逃げ道は確保したぜ。
大人って汚いですね。
話を戻します。
フレームワークのメリットとして語られる中で私が納得できない内容は
生産性の向上（開発コストの削減）
です。
KU・SO・GA！（－Ａ－）
こんなことを言うやつがいるお陰で、何も知らないお客さまが「フレームワークを導入して、コストを抑えてください」とか寝ぼけたことを言い出すんだよ！クソが！
「フレームワークを使うと生産性が上がる！」とか言ってるやつは、腐った豆腐でも食って、腹を壊してしまえ！
はぁはぁ。
すみません。
取り乱しました。
別に「フレームワークを使っても生産性は上がらない！」と言うつもりは、ありません。
ただし、生産性が上がるための前提条件として
１．フレームワークの使い方を理解していて
２．ありがちな処理をやるとき
があると思うのです。
システムなんて、なーんにも知らないお客さまに「フレームワークってやつを使えば、安くなるんでしょ？」とかニヤニヤしながら言われてみてくださいな。
前提条件に触れないで「生産性が上がるよ！」とか言うやつに対して、怨みを抱きます。
大事なデートの日に目覚まし時計の電池が止まって寝坊してしまえ！と呪いをかけたくなりますよ、マジで。
知っているのは、知ってることだけ
そりゃーねぇ。
フレームワークは、便利な部品の寄せ集めですよ。
使い方を知っていれば、さくさくっと作れるかもしれませんよ。
裏を返せば、知らないフレームワークは使い方を勉強するところから始まるわけです。
その勉強にかかる時間もコストですぜ？
「そんなもん当たり前だろ。勉強しろよ！」と思う人は、いるでしょう。
「フレームワークを使わなくても学習コストは発生するだろ！」と思う人も、いるでしょう。
理解した上で求めてくる人は良いのです。
「学習コストを考慮しても生産性が上がる！」の判断はアリです。
おうょ！やってやらぁ！
その代わり、その分の費用も乗っけるからな！
ところがどっこい、世の中には
よく分からないけど、フレームワークってやつを使うと作るのが簡単になるんだな
と罪なき誤解をする人もいるわけです。
特に、システム開発について理解が浅いけど知ったかぶりたいお客さまほど、付け焼刃の知識を根拠にして「フレームワークを導入して、コストを抑えてください」とか言ったりします。
私が手掛けるのは小規模な案件が多いですからね。
「フレームワークの使い方を勉強するより、自前でゴリゴリ作った方が圧倒的に速い！」状況になることも少なくありません。
フレームワークを使えば、必ず生産性が上がるわけではないのです。
世界に一つだけの……
いいですか。
フレームワークというのは
よくやる処理の詰め合わせ
です。
「みんながやりたそうなことを部品として用意しておいたよ！」です。
特殊な業務フロー、オリジナリティ溢れる動作、その他もろもろ、いわゆる「世界に一つだけの……」が必要になった場合、フレームワークはリスクに変わります。
フレームワークというのは
意図的に制限を加えることで品質を標準化
していたりします。
要は「こんなことをやりたいときは、こう書け！」と決まっているわけです。
フレームワークを作った人が想定していない書き方はできません。
仮にできてもやっちゃダメです。
フレームワークのルールの裏をかく書き方をすると、フレームワークのメリットである品質の標準化と保守性が損なわれます。
「このシステムの中身は知らないけど、フレームワークについては知ってるよ～。だから、このシステムの中身も何となく想像がつくよ～」がフレームワークのメリットです。
根本たるルールを破ったら、メリットを享受できません。
フレームワークを使っていない場合、あなたが実現しようとしている処理は
・実現できる
・プログラミング言語の制限により実現できない
・その他の理由により実現できない
のどれかです。
フレームワークを使っている場合、あなたが実現しようとしている処理は
・実現できる
・プログラミング言語の制限により実現できない
・フレームワークの制限により実現できない
・その他の理由により実現できない
のどれかになります。
「フレームワークの制限により実現できない」が追加されていますね。
独創的な処理を実現しようとすると「プログラミング言語的にはやれるけど、フレームワークの制限でできない」なんて事態が起こり得ます。
このリスクは、作るプログラムが独創的になればなるほど、高くなります。
自前で書けば30分で書ける処理でした。
フレームワークのルールに従って書こうとした結果、半日かかりました。
そんな経験も少なからずあります。
フレームワークを使えば、必ず生産性が上がるわけじゃないですよ。
前に～、ならえ！
否定的な意見ばかりを書いていたので、肯定的な意見も書いておきましょう。
フレームワークを使うメリットは、一言で言えば
一体感を出しやすい
ことです。
参加人数が多くなればなるほど、フレームワークを導入する意義は大きくなるでしょう。
開発規模が大きい場合や開発と保守を違う人が行う場合、担当者ごとの技術レベルの差が大きい場合など、品質や認識を揃える上で有用です。
それらの足並みを揃えるコストが減る分、生産性が上がります。
他にも生産性が上がる要素はありますが、面倒くさいので、ここでは書きません。
基本的に私は、フレームワークさんが好きではないのです。
まとめ
今回は「フレームワークを過信するな」というテーマで、フレームワークのメリットとして取り上げられがちな「生産性の向上（開発コストの削減）」について述べてみました。
結局ですね。
フレームワークの導入で生産性が向上するかは
ケース・バイ・ケース
です。
どんなプログラムを、どんな体制で開発するかにもよります。
フレームワークと相性の良い案件もあれば、良くない案件もあるでしょう。
メンテナンスとの兼ね合いもあります。
よって、私は
対象とする案件の条件付けがない状態で「フレームワークは使うべき！」「フレームワークは使う必要なし！」の結論を出すのは無理じゃね？
と考えています。
案件それぞれに対して
「この案件では、フレームワークを使うべきか？」を検討して判断するべき
ではないでしょうか。
蛇足なおまけ
今回は
フレームワークを過信するな
というタイトルにしましたが
フレームワークを安易に否定するな
でも同じですね。
実は以前から、フレームワークのメリット・デメリットを論じている意見を読んで、違和感を覚えていました。
今回のコラムを書いていて、理由が分かったので、メモっておきます。
例えば、以下の4つの案件があったとしましょう。
１．1人が1週間で作る規模のシステム開発、メンテナンスをするのは作った人
２．1人が1週間で作る規模のシステム開発、メンテナンスをするのは別の人
３．10人が3ヵ月で作る規模のシステム開発、分野は会員サイトの作成
４．10人が3ヵ月で作る規模のシステム開発、分野は最先端の研究開発用システム
１は、フレームワークを使うメリットは薄いと思います。
２は、メンテナンスをする人次第ですが、使わなくても良い気がします。
３は、フレームワークを使った方が良い結果になりそうですね。
４は、やりたいこと次第ですが、フレームワークを使う方が無難でしょう。
１～４の案件に参加した人それぞれに対して「フレームワークってシステム開発で必要？」と聞けば、返ってくる答えは異なるはずです。
私は、どちらかと言えばフレームワークが嫌いです。
過去の案件では、フレームワークのデメリットを力いっぱい体感してきました。
フレームワークのメリットを述べている意見を見ても「う～ん、デメリットの方が大きい気がするけどな～」と感じています。
それは恐らく、１、２に近い案件を手掛けることが多いからでしょう。
逆に３、４系の案件を手掛ける機会が多ければ「フレームワーク無しの開発なんて考えられない！」となる気がします。
それを踏まえて、フレームワークのメリット・デメリットに関する意見を読むときは「どのような規模の案件を想定して語っているか」を意識する必要性を感じています。
その意識を持っておかないと、意見が的外れに感じたり、変な誤解をしてしまうリスクが上がるはずです。
思わぬところで噛み合わない論争に発展しないように、ご注意ください。
思いつきで始めて惰性で続けている「分かりそう」で「分からない」でも「分かった」気になれるITコラムですが、いかがでしたでしょうか。また何かネタがあったら、ちまちまと更新していきます。コンゴトモヨロシク。
