第19話 フレームワークの甘いワナ
みなさま、新年明けましておめでとうございます。硬派担当のにゃん太郎です（笑）。今年もわたしの考えを述べつつ、みなさまといろいろ意見交換ができると幸いです。本年もよろしくお願いします。
名前だけ見るとふざけているようで、とても硬派ではないのですが、この「にゃん太郎」という名前はわたしの奥さんが実際にわたしを呼ぶ時に使っています。付き合い始めた頃からなので、すでに10年以上になります。長いこと使っているので、時々外出先でも奥さんに「にゃん太郎」って呼ばれます（ぉぃ）。
さて、今年の最初のテーマは「フレームワーク」です。最近のソフトウェア開発にはなくてならないものを通り越して当たり前になっています。フレームワークと呼ばなくても構造的にフレームワークになっているものもけっこうあります。わたし自身はシステム開発においてフレームワークの必要性というか有用性は理解していますし、先ほども書いたとおり、なくてはならないものだと思います。ただ、何でもかんでもフレームワークって言うのはソフトウェアエンジニアとしてはどうかと考えています。やや長いですが、お付き合い下さいませ。
■なぜ、フレームワークを使うのか
フレームワークは「骨組み」という名前が示す通り、ソフトウェアを形成するベースとなる「枠」をあらかじめ構成したものです。骨組みといってもフレームワークによってその範囲はまちまちなので、汎用的なものから特定用途（Webアプリなど）や特定業務（金融など）、オープンソースから製品まで幅広く存在します。また、ライブラリ的なものから開発環境と深く結び付くものまであります。誤解を恐れず言えば、OS自体も本来はハードウェアが変わっても同じアプリケーションが動作することを機能の1つとして挙げられるため、アプリケーションから見た場合、一種のフレームワークとみることができます。ライブラリやクラス、Windowsではコントロールも場合によっては同じような使い方をします。そういう意味では割合、無意識のうちにフレームワークを利用しているとも言えそうです（ただし、ここではOSやライブラリなどを含めてしまうとかなり広範囲になるため基本的に一般に言われているフレームワークのみを扱います）。
では、なぜフレームワークを利用するのでしょうか。理由は大きく分けて2つあると思います。1つは「生産性の向上」です。ソフトウェア開発をしていれば分かると思いますが、同じような処理を何度も行うことがあります。例えば、文字入力、画面表示、ウィンドウを閉じるなどです。特定業務だと同じような処理（計算式など）もあるでしょう。これらを1から開発した場合、ビジネスロジック以外の処理を相当量作成しなくてはなりません。組み込み開発のようにハードウェアがその時々で変わり、OSがない場合などは仕方がないのですが、パソコンなどの汎用機では現実的ではありません。わたしがソフトウェア開発の仕事を始めた20年前から「人材不足」と言われており、慢性的な人手不足を考慮すると、いろいろな方向性を持ったフレームワークが存在するのは必然だと考えられます。
もう1つは「品質の向上」です。ソフトウェア開発を1人で行い、その人が一生メンテナンスするなら問題はないのですが、実際そんなことはありえません。あっても1人で開発するぐらいだと思いますが、それも現状では例外と言えます。複数の人間でチームを作って開発を行う場合、問題になるのがメンバーのスキルが平均化しないということです。
これは「早い・遅い」だけでなく、バグが「多い・少ない」も関係してきます。ソフトウェアは関数レベルで考えると基本的に入出力が決まっていて、そこに至る過程を設計、コーディングします。作った本人以外は意識してコードを読まない限り、他人にはブラックボックスであることが多いと思います。そう考えると、コーディング量を極力減らした方が品質は安定し、向上が期待できます。特にコーディング規約や命名規則もある程度統一しているものが多いため、それに合わせたコーディングを行えば保守性も向上します。
ソフトウェア開発においてフレームワークが有用でなくてはならないのは、おそらく誰しもが認めるところだと思います。
■フレームワークで生産性は向上するか
まったく利用しないケースに比べたら、必ず向上します。例えば、Windowsのアプリケーションを作る場合を考えてみます。テキストエディタを開いてゼロからWindowsAPIを使用してウィンドウを作成する所から始めるよりは、ひな形のウィンドウをあらかじめ作成してもらい、そこにコントロールをパズルの様に置いて画面を作成し、必要な動作（ボタンを押した時など）を記述した方がはるかに早いでしょう。
さすがに例が極端過ぎますが、もうちょっと一般的に「フレームワーク」と呼ばれているものについて考えてみます。
「フレームワーク」と聞いてピンとくるものでおそらく多いのは、Windowsの「.Net Framework」ではないのでしょうか。Javaなら「Struts」とか、PHPなら「CakePHP」や「Zend Framework」、「Ruby on Rails」もそうでしょう。「O/Rマッピング」もフレームワークでしょうか。仕事でもプライベート（趣味）でもお目にかかる機会はかなりあると思います。商用では「楽々Framework II」や「オブジェクトワークス」なんていうのがあります。大企業がユーザーだと「オープンソースでは何かあった時、サポートはどうなるんだ」と考える所が日本では多いため（わたしの実体験です）、商用フレームワークを導入する余地はあると思います。言ってしまえば、コストを取るかサポート（これは企業から見た場合、信頼性と同じ）を取るかでしょうけど。OracleやSQLServerも多少はそういう側面があると思います。
これらフレームワークを使った場合と使わなかった場合、生産性に大きな違いが出るのでしょうか？ わたしの経験上、そんなに差があるとは思えません。むしろ変わらない気さえします。
単純にプログラムの「工数」は減ると思います。設計もかなりビジネスロジックに特化したものが書けると思います。でも、生産性はナゼかあまり上がるとは思えません。せいぜいテスト項目がやや減るので、その分別な検証ができるかな、という程度です。
わたしの経験なのでひょっとしたら「いや、うちはフレームワークのおかげで生産性も品質もものすごく向上したぞ！」とおっしゃる方がいると思います。それはそれでけっこうなことだと思いますし、できればそうであって欲しいとさえ思います。
現場の人に「フレームワークを使うんだから、納期短くても大丈夫だよね？」なんて言おうものならほとんどの人が「えー」と言うと思います（もっとも、使っても使わなくても短くなることには反対するでしょうが）。誰しもフレームワークを使うからといって、短期間に開発ができるとは思っていないからです。逆に新しい（自分が知らない）フレームワークだったら、かえって覚えるのに時間がかかるとさえ考えるエンジニアもいると思います。おそらく現場レベルでは「フレームワーク＝言語仕様」に近いイメージがあるんじゃないのでしょうか。これがわたしが生産性が上がらないと思う理由です。
■フレームワークを使う理由
建前は「生産性と品質の向上」ですが、実際は「一から作るより楽だから」という答えが圧倒的に多いと思います。もうちょっと良い言葉にするなら「保守性も考慮して」でしょうか。個人的には免罪符のような気もします。
ただ、それなりに理由があり、特に「どう考えても工期が短い場合」などは有用だと思います。わたしはフレームワークの利用を「悪い」とは思っていません。でも「楽だから」という観点から使うことはエンジニアとしてはダメだと考えています。補足しますが、「楽すること」が悪いのではありません。特に考えもなく目先の「楽」を考えることがダメだと言うのです。同じ「楽」を考えるならもう少し長いスパンで考えるべきです。
エンジニアが同じような処理を1つにまとめて極力コーディング量を減らす努力をした上で「楽をする」と言うのは間違いではありません。それこそバグ修正や機能変更時にはそれが功を奏するでしょうし、ソフトウェア開発の基本です。本来、フレームワークというのはそのような観点に立った上で成り立っているハズです。それを理解した上で使用することは良いのですが、それを忘れて単純に「このフレームワークを使った方が早くできそうだから」と考えるのはエンジニアとしては失格です。結果として早くできないことも多いでしょう。
わたしは仕事でソフトウェア開発を行う場合、他人（他社・他プロジェクト）が作ったフレームワークは生産性と品質の向上にはあまりつながらないと思っています。ウィンドウやボタンのひな形など共通処理には必要ですが、フレームワークを使用して開発するには複雑なシステムが多いからです。
■フレームワークの盲点
フレームワークの多くは便利な機能と引き換えに開発者にいろいろな制限を強いることが多いです。一番多いのはコーディングスタイルでしょう。フレームワークの利点を生かすのと引き換えに開発者にはルールの順守を求めます。ルールが順守できるのであれば、フレームワークを利用するメリットは大きいと思います。ただ、ルールにはメリットだけではなくデメリットも隠れています。フレームワークを利用して生産性や品質の向上を図るのならば、このデメリットをきちんと把握する必要があります。
「.Net Framework」を例に少し考えてみます。最近は仕事でよく使うのですが、ちょこちょこっとしたツールを作るには非常に有用だと思います。簡単なコーディングでかなりのことが短時間にできて、確かに生産性は高いと感じます。ところがそんな調子でそれなりの規模のアプリケーションを作るとけっこうハマります。一気に処理速度が落ちたり、例外の実装が適当だとアプリケーションが落ちたり、エラー時に止めるべき処理が止まらなかったり。そうそう、突然前触れもなくアプリケーションが終了してしまうことや、ダンプすら出ない時もあったので、障害の特定に時間がかかったこともありました。
「簡単」なことのメリットは確かにあります。このメリットは単に動くものを作るならば意味はありますが、仕事ではそれだけではダメです。確かにメモリ管理の必要もあまりなく、使用するクラスやメソッドは分かりやすいです。ただし、それらがどのように動作しているかをある程度把握していなければ、アプリケーションの規模が大きくなるにつれて管理しきれなくなり、あちこちにほころびができます。「簡単＝楽」ではありません。
フレームワークを使いこなすには、ある程度内部でどのような動作を行っているかを知る必要があります。ちなみに「.Net Framework」にもいろいろな資料があるので仕事で利用する人は一度読んでみることをオススメします。知らずに表向きの便利さだけでコーディングすることが、どれだけ危険かが分かると思います。キツい言い方をすれば、分からなければこれから先、エンジニアで生きていくのは難しいかもしれません。
■行儀のよいシステムはあまりない
フレームワークを使ってしばしば思うのですが、自分が実現したい機能がどうしてもできない時があります。そういう時はフレームワークから外れて処理をカスタマイズすることがあると思います。以前も書きましたが、アメリカなどではパッケージソフトウェアを「カスタマイズ」することはまずありません。せいぜい機能追加程度です。フレームワークに対しての考え方も同様で、その枠内でできるように機能を実装します。システムを自分たちに合わせるのではなく、自分たちがシステムに合わせることが基本としてあるので、システム開発という面については非常に合理的だといえます。それができないなら一から設計することを考えます。
対して、日本では大企業になればなるほど、システムを自分たちに合わせるようベンダなどに要求してきます。ベンダも商売なのでパッケージソフトウェアをベースにカスタマイズするか、一から構築するならフレームワークなどを使って構築しようとします。言いかえれば、使える所をなるべく使って工数をできるだけ減らし、その分、利益を上げようと考えるのです。これはこれで合理的に見えますが、ここに罠があります。
システムに人間が合わせることは、人間にシステムを合わせるよりも遥かに簡単です。最初は使いづらかったり、誤操作もあるでしょうが、使っていけば、そのうち多少不便でも慣れてきて、それに合わせて業務を改善したりできます。不足分は追加でツール等を作るなどして補えます。でも、システムは自分では改善できません。必ず人が手順を確認して設計、製造、テストを繰り返して改善します。これが小規模ならいいのですが、場合によっては広範囲になることもあります。最初の青写真通りにシステム開発が進み、プロジェクトが終われば良いのですが、そんなケースはまれで、途中で何かしら問題が発生することが普通だと思います。そうなると工数を減らすどころか逆に増えて行きます。大なり小なりこの構造がいまだに変わっていないのでデスマーチや失敗プロジェクトはなくなりません。
日本のシステム開発（商売）の考え方にはフレームワークやカスタマイズは合わないとわたしは思います。
■フレームワークがエンジニアをダメにする
最初の方で、チームで開発を行う場合「スキル」のばらつきが問題になると書きました。スキルにばらつきがあるのは経験や思想も絡んでくるので仕事では仕方ないと思います。ただ、フレームワークでこれを解決しようと考えるならそれは誤りではないのでしょうか。
大半のエンジニアはフレームワークの「使い方」はマスターしようと考えますが、フレームワークの「しくみ」をマスターしようとはあまり考えていないと思います。ブラックボックスはブラックボックスのままで開発を行います。先ほども書きましたがフレームワークの枠内で開発ができればそれでも問題は少ないのですが、現実問題としてフレームワークの枠内では処理しきれない機能を実装することは往々にしてあります。
これをフレームワークのしくみを知った上で行うのと、知らずに行うのでは障害時にその差が出てきます。知らずに「できるから」とやってしまうことのリスクはかなり高いといえます。特にネット上にはその手の情報はたくさんあります。でもすべてが「正しい」わけではありません。「キーワードでググる」→「見つかって取りあえずコピペ」→「簡単な動作チェックでOK」→「これでよし！」とやってしまうエンジニアがいる以上、安易なフレームワークの使用は危険だといえます。
「O/Rマッピング」についても同じです。データモデルに違いがある以上、技術的に「O/Rマッピング」というのは必然性があると思います。特に中小企業レベルでは予算や納期、データ量などを考えると非常に有用だと思います。RDBMSやSQLを知ってる人間が分かった上で使用する分には良いと思いますし、実際にわたしもある小規模企業のお客様のシステムを構築した時に使いました。でも、ここからデータベースを使ったソフトウェア開発を行ってしまうことは「O/Rマッピング」に過剰な期待を生む結果になりやすいです。つまり、無理してRDBMSやSQLを学ぶ必要はないんだと勘違いする輩が出てきます。そのままエンジニアとして経験を重ねて上流工程を行うと、規模によってはえらいことになります（そのあたりは生島さんのコラムの方を読んで下さい）。実際、そういうエンジニアのおかげで、火消しに入ったプロジェクトで作業に入る前にお客様に怒られたことがあります（けっこう理不尽だと思いますが）。
フレームワークが悪い訳では決してなく、フレームワークを使うエンジニアが横着なのが悪いのです。作業が多いとか納期が短いとか理由はいくらでも付け足せますが、エンジニアという肩書きがあるなら最低限、フレームワークの構造や仕組みは理解すべきだと思います。生産性や品質の向上はそれを行ってこそ達成されると思うべきです。
■基本は自作で
わたしは、フレームワークに関しては、自分たちで作ることをオススメします。SIerでもソフトハウスでも自社で開発を行うところはフレームワーク専用部署（チーム）があっても良いんじゃないでしょうか。ゲームを作るソフト会社ではグラフィックや音楽など自作のツールやフレームワークを使って開発するとよく聞きます。出来合いのツールやフレームワークではなかなかかゆいところまで手が届かないからでしょうが、これは一般的なフレームワークを使った開発をする場合にも言えると思います。
フレームワークを生産性や品質の向上につなげるなら最初は大変でしょうが、ある程度時間が経つと逆に開発コストが下がると思います。会社の経営体力と採算分岐点にもよりますが、普通にやればエンジニアのレベルも同時に上がって行くので一石二鳥だと思います。これが目先の「楽」ではなく、長期的なスパンで考えた「楽」です。自作だと何かあっても調査や入れ替え、バージョン管理も容易になるでしょう。
昔はフレームワークに良く似た考え方でライブラリ化、クラス化などが社内で盛んに行われていたと思います。最近ではツールやライブラリが市販されて時間と技術がお金で手に入るようになりました。そしてインターネットやオープンソースソフトウェア等の普及で情報もソフトも誰でも安価で容易に手に入るようになりました。
それがあるからか、最近ではソフトウェア開発でも積極的にそれらを取り入れるようになり自社で技術の蓄積を行わない所も増えてるように感じます。たくさんの情報やソフト（商品）から選択肢が広がったのと引き換えにエンジニアは大事なモノを失った気がします。
フレームワークを作るということはそれなりのスキルも要求されます。既存のものを利用するのもソフトウェア開発では重要だと思いますが、エンジニアである以上自分でできるだけ作る気概だけは失ってほしくはないものです。
コメント
インドリ
あけましておめでとうございます。
同感です。私も技術者が技術者らしくなくなったと感じております。
フレームワークは自分で作るか、自分で作れるる程に既存のフレームワークを研究するのがいいですよね。
それに加えて、オブジェクト指向を理解せず、再利用を生かせない会社が多いと私は考えております。
オブジェクト指向言語を使うから再利用できるのではなく、経営戦略を持ってオブジェクト指向開発をして初めて再利用が実現します。
それにも関わらず、日本の経営者は「知らなくてもいい」という態度でいい加減な経営をしている姿が目立ちます。
一体自分が何を売っているのかや、どの様に経営をするのかを考えずに「知らないものを売る」だけでは不景気になるのは至極当然だと私は考えております。
こういった背景もあり、技術者ではなく、無知な経営者に合わして給料をもらうサラリーマンが増えたと思えてなりません。
経営者がちゃんと自分の売るものを把握し、会社の無形財産を管理し、明確な意思を持って経営を行い、サラリーマンを技術者に変えなければなりません。
しかしながら、クラウド（昔でいうところのメインフレームでは？）が流行っているのを鑑みると、業界全体が「無知でも儲ける方法」を模索している気がしてなりません。
ですから、業界全体の質が落ちていると思われます。
無形資産を管理出来ないIT業界に明るい未来はないでしょう。
年初めから暗いコメントで済みません。
saki1208
あけましておめでとうございます。
私も同感です。
便利なツールやライブラリ、フレームワークを使うことで楽になった気になって
いますが、結局、それらに振り回されている気がします。
それらのバグ回避のために余計なコードを記述したり、バージョンアップの際に
その所為で正常動作になくなったり、なんてことすんだ!!みたいな...
ツールの類いでは裏で暗黙的に実施してくれることもちゃんと理解した上で作業
しないと場合によっては大変なことになりますし、既存のフレームワークもその
ままでは不十分な場合もあると思うのですが、大抵の場合「魔法の杖」扱いにな
っているんじゃないでしょうか。
.Net Framework にしても素のままですべてOKな訳ではなく、さらに自分たち
用のフレームワークを構築する必要があると私は考えます。
まぁ、サラリーマンという雇用形態がコの業界(だけではなく、技術者全般でしょ
うけど)には不向きなんじゃないかと思いますね。
はじめまして、ちょりぽんと申します。
10年前に業界デビューした私の処女作は、
・テキストエディタ
・JDK
・DB2
・Websphere Application Server
という構成で、HTML出力を含んだ全てのロジックをdoPost内に実装したという、非常に男らしい実装になってしまいました（笑）先輩から『JSPは？』と訊かれ、『なんすかソレ？』とか言ってました（笑）
この案件は1か月で無事にリリースでき、運用中もトラブルなく終了となりました。（２日もあれば先輩が構築できるシステムだったので、私に対する様子見という意味合いが強かったのでしょう。）
作りの問題は置いといても、この経験があったからこそ、今までフレームワークと上手く付き合ってこれたのだと思います（もちろん上記案件ではSQLも直書き）。上記の案件を終えてから、これまで触れてきたフレームワークも、全て解っている事を簡略化するTOOLにしか見えなかったことが大きいですね。Visual Age for Javaに初めて触れた時も、裏でコマンドを発行しているだろうことは、容易に想像できましたし、Strutsに出合った時も、やはり解っていることを簡略化するためのTOOLだと捉えたものです。
WEBアプリですと、画面表示が崩れるのであればフレームワークから出力されるHTML構文を先ずチェックしますし、サマった金額が不正だったり、レスポンスが遅かったりすれば、先ず発行されたSQL構文に着眼する。上記の案件を経験していたからこそ、このアプローチが身に付いたのだと思います。
現在Ruby on Railsを用いた実務を継続中ですが、未経験の新人さんがイキナリこれを触ることが恐いと思っています。それほど良く出来ている。便利なフレームワークが当たり前になってしまうと、突発的なトラブルに対応できないエンジニアになってしまうと危惧しています。
あと、フレームワークそのものを知らなければ、余計に工数が膨らんでしまうことにも同意です。EMF(Eclipse Modeling Framework)の実務で経験しましたが、フレームワークで想定された拡張方法を見落としてしまい、ゴリゴリとコードを書いてしまったりしました（それでも大量のコードを伴って実現できてしまうのが恐い）。
『なんか解んないけど動いちゃった』という、陥りがちな落とし穴を多く提供してしまうのは、フレームワークの功罪だと思っています。
やはり、便利な道具が提供してくれるインスタント・アプリは仕事の本質ではないということを、我々の世代が若手に伝えていくことが責務なのだと痛感しています。
にゃん太郎
インドリさん、ありがとうございます。
> 鑑みると、業界全体が「無知でも儲ける方法」を模索している気がしてなりません。
> ですから、業界全体の質が落ちていると思われます。
「無知」まで言うと極論ですが、ようするに最小の手間で最大の利益を考え過ぎているのでしょうね。それ自体は商売の基本なのですが、最近は儲けに向き過ぎる傾向はあると思います。その流れにエンジニアを巻き込んでしまうと安易な考えを持ったエンジニアになってしまいます。その結果、質が落ちていきます。
利益が無いと成り立たないとどうしようもないので、その辺りのトレードオフが難しい所ではないのでしょうか。
にゃん太郎
saki1208さん、ありがとうございます。
> 便利なツールやライブラリ、フレームワークを使うことで楽になった気になって
> いますが、結局、それらに振り回されている気がします。
長い事業界にいるとたいていこう思うんじゃないでしょうか？それでも毎回同じような事を繰り返してしまうような気がします（他人ごとではないですよね）進歩が無いような気もしますが、それ以上にいろいろな制約（人手が足りない、予算が無いなど）でそうせざるを得ないのは悩ましい所だと思います。
> まぁ、サラリーマンという雇用形態がコの業界(だけではなく、技術者全般でしょ
> うけど)には不向きなんじゃないかと思いますね。
以前のコラムにも書きましたが、私も同感です。ただ傾向としてエンジニアの大半が技術的な事に関心はあってもそれ以外の事にあまり関心がない人が多いのでエンジニア側からみるとサラリーマン以外は不向きとも言えます。難しい問題だと思います。
にゃん太郎
はじめまして（かな？）ちょりぽんさん、ありがとうございます。
> 便利なフレームワークが当たり前になってしまうと、突発的なトラブルに
> 対応できないエンジニアになってしまうと危惧しています。
私の周辺ではすでにそういう兆候はあります。トラブルが起こるとライブラリやフレームワークのせいだと思いこみ、そこで思考が停止してしまって「原因がわかりません」と言ってきます。せめてある程度調べてアタリをつけて欲しいのですが自分の範囲外になると「分からないので出来ません」ときっぱり言われます。
> やはり、便利な道具が提供してくれるインスタント・アプリは仕事の本質ではない
> ということを、我々の世代が若手に伝えていくことが責務なのだと痛感しています。
そうですね。だからこういうコラムを書いていると言うのはあります。根性論だけを押しつける気はありませんが、便利なものを上手に使いながら大事な「手間」だけは省かないよう若手を指導して行かないとこの業界は本当に未来が無くなりそうです。
通りすがり
オープンソースで作られたフレームワークでも
フレームワーク専用部署で作られたフレームワークでも
使う人間がそれらのチームに所属していない人間であれば
どちらのフレームワークを使っても結果は同じでは？
にゃん太郎
通りすがりさん。
> どちらのフレームワークを使っても結果は同じでは？
あなたがそう思うならそうなんでしょうね。
Ｓｏｄａ
フレームワークの自作ってのはかなり大げさな感じがしますが・・・
勉強のためにフレームワークを自作するってのは理解できます。
でも、それだけのために自作するってのは趣味の範疇かなと。
・・・というか、そこまでしないとフレームワークがまともに使えないってのは色々な意味で悲しいような気が(^^;
>日本のシステム開発（商売）の考え方にはフレームワークやカスタマイズは合わないとわたしは思います。
にゃん太郎さん自身がこのように考えているのですから、作ったフレームワークは単発での利用が多くなるわけですよね？
それを仕事で作るってのはリスクのほうが大きくないですか？
便利なフレームワークなどにより、作る部分は減りますが・・・
人間は贅沢な生き物で、減った部分に対し、新たな要望部分が加算され続けますよね。
画面表示などはわかりやすいです、楽に表現できるようになっても、よりゴージャスに、よりわかりやすくとなって行きます。
これはハードの進化の影響もありますが、やりたいことは際限なく増えていきますよね。
私は、時代の変化により、覚えなくても良い技術のかわり覚えなくてはいけない技術が追加されると思っています。
フレームワークなどは覚えなくても良い技術を沢山生み出していると考えることもできます。
覚えなくても良い技術といっても、失われるわけではありません、ごく一部では必ず残ります。
研究者として、細かな技術を学ぶことも重要だと思いますが、今、お客が求めているのは、研究者ではないと思うのですよ。
ネジの１つから作り上げるフルスクラッチなものよりも、適切な既製部品を上手く組み合わせたもののほうが望まれてるんじゃないかな？
そして、既製部品を上手に使える技術こそが、一番多く望まれているんだと思います。
将来的にプログラマというのは、ごく一部を除いて居なくなるのが理想なんですよねぇ、きっと。
人間がやりたいことをコンピューターが認識してくれればいいのですからｗ
こーVBが登場した時にも同じような議論があったような気がします。
あぁ、DOSからWindowsになったときもそんな感じだったかなぁ。
その時から考えて、作業量は減ったかと考えると・・・減ってはいないように感じます。
結局、自分が知っていることを新しい人間が知らないということへの不安や不信感があるだけではないかなぁ？
本当に楽ができるようになったのならば、プログラマやＳＥの絶対数は減っていくのだと思います。
・・・が、まだまだ減るほど楽はできてないような気がしますね。
ＰＳ．
>通りすがりさん
>どちらのフレームワークを使っても結果は同じでは？
そりゃ、作った場所が違うだけですからね、使う人のフレームワークに対する意識が同じなのは当たり前ですわなｗ
それ以外の点ではカスタマイズがしやすかったり、フレームワーク自身のバグを見つけやすかったりするんでしょうね。
にゃん太郎
Ｓｏｄａさん、ありがとうございます。
> フレームワークの自作ってのはかなり大げさな感じがしますが・・・
コラムの最後にも少し書いてありますが、現実的には仕事としては難しく、現状を考えると理想論だと思います。実際には「フレームワーク」は明確に定義する事が難しいぐらいいろいろな「骨組み」が存在します。それらが2重、3重になって引き起こす問題点に対して大半のエンジニアが対処しきれない現状があり、それらを勘案した上でのコラムの内容になっています。
> にゃん太郎さん自身がこのように考えているのですから、作ったフレームワークは
> 単発での利用が多くなるわけですよね？
> それを仕事で作るってのはリスクのほうが大きくないですか？
個人としては単発の仕事の人もいるでしょうがシステム（プロジェクト）として考えるなら単発という事は少ないと思います。そう考えてメンテナンスやバージョンアップを考えると自分たちで手を入れられる範囲が大きい事は技術的にはメリットだと思います。ただし、それを実現できるスキルを持ったエンジニアや束ねられるマネージャが存在しないとそれがリスクになる事は間違いないと思います。
> ネジの１つから作り上げるフルスクラッチなものよりも、適切な既製部品を上手く
> 組み合わせたもののほうが望まれてるんじゃないかな？
> そして、既製部品を上手に使える技術こそが、一番多く望まれているんだと思います。
さすがに私もネジ1本からとも思いませんよ（笑）そこまで言うならハードウェアからOSまで全部設計した方が良い、と言う所まで行ってしまうのでさすがにその方が良いとも思えません。ただ、どこまで「既成部品」を使うかが本質なのだと思います。ビジネス的にはある機能を実装する場合、自前で作るか、他社から買うか、オープンソースをベースにするかなどの選択肢がフレームワークに限らずあると思います。それをどうするかを考えるのは基本的に上の方の権限を持った人たちですが、それに従うのは現場のエンジニアです。ですから「既製部品を上手に使える技術」も大切だと思います。
誤解して欲しくないのは既成部品を使わず自分で作れ、と言っている訳ではない事です。使うならそれなりに仕組みを知ってから使うべきだと言ってるだけです。事実、「.Net Framework」はある程度どういう形で動作するか知らないと「簡単だから」と言う側面だけで作って行くと出来てからバグ取りにかなり時間を使う事になる事も多々あります（当然、そうではないケースもありますよ）それが出来ないなら専門の部隊を作って自作した方が最終的にはデスマーチも失敗プロジェクトも減るんじゃないか、と思っているだけです（ただ、私も経験した訳ではないので本当に減るかは分かりませんけど）
これも私の経験ですが（と言うより今現在ですが）対応OSの問題もあると思います。お客様が最新OS（うちは基本的にコンシュマー向けが多いので）を望まれてもソフトで実現している重要な機能を持った「既成部品」が対応するまでどうしようもないと言う事もあります。こんな時冗談抜きで「作った方がいいのかなぁ、でも時間や技術的な事で無理そうだしなぁ」と考えます。
どんな方法が「ベスト」なのかはそれぞれ置かれている状況によって違うのですが、理想論的にコラムを読んでもらえるのが書いてる本人から言えばありがたいです。でも、同意だけではなくてツッコミも欲しいので、いろいろコメント頂けるのはありがたいです。
VoX
にゃん太郎さん、初めまして。
私にはこう見えます。
上の人は“少なくとも自分がリタイアするまで”ほとんど意味のないドキュメントの山に法外な値段をつけて売ろうとする。
下の人は“どうせすぐSEになるから”下流のことなんか覚えなくて良いや、と思っている。
全部を全部変えられないから、一部の有志がそういう人たちを引っ張るのが現実的なんだと今は信じています。そのためのフレームワークなんだとも思っています。
にゃん太郎
VoXさん、ありがとうございます。
> 全部を全部変えられないから、一部の有志がそういう人たちを引っ張るのが現実的
> なんだと今は信じています。そのためのフレームワークなんだとも思っています。
仕事の場合、いろいろな立場で考える人がいるので一概には言えませんが、本来はおっしゃるようにそうであって欲しいと思います。ただ、フレームワークの乱立？かどうかは分かりませんが、エンジニア自体1番大切な（と、私個人は思ってます）しくみを考える事をしない人が増えたような気がします。小手先のごまかしで知らない人がみたら「すげー」って見えるような危ういシステムを作るためにフレームワークを使ってる気がしてならない事が多々あります。そういう意味では便利なフレームワークは「もろ刃の剣」でしょうね。気のせいだったらそれはそれで良いんですが、難しいところです。
MASASHIGE
にゃん太郎さん、はじめまして。MASASHIGEと申します。
SE/PGとして働き始めて５年目になります。
入社してから今まで、いくつかのWebアプリケーション（特にJava）のシステムを開発してきました。
それぞれのプロジェクトにおいて、業務ロジックの実装と並行して、
フレームワークの新規作成や業務仕様に合わせたカスタマイズ、
自作されたフレームワーク（ドキュメントなし）の仕様調査と開発メンバーへの展開などを担当してきました。
「自分が使っている部品の仕様は把握して使え」ということならその通りだと思います。
ただ、今回の話って、フレームワークにあまり関係がないというか、限った話ではない気がするのですが、違いますか？
.NET Frameworkばかりが例として挙がっているので、そう感じてしまうのかもしれませんが…
.NET Frameworkは、並記されているStrutsなどのソフトウェアフレームワークとは違い、
主に実行環境や開発環境そのものを指しますよね。
javaで例えるならJREとかJ2EEに近いものだと思っております。
それらって言語仕様ですよね？
WindowsフォームやASP.NETなどのアプリケーションサービスのことを指しているのだとしても、
話の展開に違和感を感じます。
WindowsのFormアプリケーションを作る目的があった場合に、Windowsフォームを使う理由は楽をするためですか？
生産性と品質は何に比べて向上するのでしょうか。
そもそも、Windowsフォーム以外に選択肢ってあったんでしょうか。
Formアプリケーションで開発するには複雑なシステム、というのも思いつきません。
ソフトウェアフレームワークに限った話として読み解く場合、
フレームワークを利用する目的は、『開発者に勝手なことをさせないため』だと思っております。
制限を強いることができる、ということの方が、便利な機能が提供されていることより重要です。
均一の作りで遊びがないことが最終的に品質の向上につながるのであり、
それはフレームワークによって枠組みが提供されるから実現できるのだと思っております。
そして、大半の処理はフレームワークの枠内で出来ます。
（出来ないならフレームワークが意味なくなってます。フレームワークをアプリ用にカスタマイズしましょう）
もし、フレームワークの枠外で処理をする必要があるのであれば、
ちゃんとフレームワークの枠の境界がどこなのかを認識してやることが大事ですよね。
（そしてなんちゃって開発者にやらせないことが重要…）
ググってコピって、はフレームワーク関係なくやる輩がいるので（エンジニアとは言いません）、
そこはフレームワークの安易な使用とは関係ないと思います。
フレームワーク内でググってコピってやられても困るし、フレームワーク外でも困ります。
そこはフレームワークの弊害というより、社員教育などの問題かと…
以上、乱筆乱文、失礼いたしました。
にゃん太郎
MASASHIGEさん、ありがとうございます。
フレームワークの「フレーム」は枠組みという意味以外に「枷」という意味もあると思います。その意味ではMASASHIGEさんのおっしゃる強制を強いると言うのは本質だと思います。
仕事でフレームワークを扱っていらっしゃるようなので、コメントを読むとなるほどな、と思いました。
Javaと.Net Frameworkは表面上では良く似ています。特にC#なんかはどう考えてもJavaを意識してある意味「Microsoft Java」って言えるようなものになっていて、明らかにJavaが得意なエンジニアを容易に誘導するための戦略言語だと勘ぐれます。.Net FrameworkをJavaと同じように言語仕様と見えてしまうのは分かりますし、これは多分Microsoftの戦略が成功しているのだと思いますが、実際は似て非なるものです。.Net Frameworkが言語仕様ではない一番の理由は.Net Farmeworkの上にVB/C++/C#と言う異なる言語が使用できるからで、特にVSにおいては1つのソリューション内でこれら3つの言語がプロジェクトとして一緒に使用できるのは共通フレームワークである.Net Frameworkの利点の1つだと思います。私は携帯用のJVMを設計したことがあるのでその違いは明確に理解しているつもりです。フレームワークをあまり意識させない.Net Frameworkは実行環境という部分では便利で秀逸だと思います（ただ、コンシューマで使うにはちょっと大きすぎてJavaには劣ると私は感じています）
エンジニアにとって.Net Frameworkの利点はJava的にな使い方が出来る事ですが、私から見れば逆にそうしてしまった中途半端なアーキテクチャが逆にデメリットの気がしてしまい非常に残念です。もっともビジネスとして考えた場合、仕方のない選択肢だったのは想像できますが。
WindowsのFormアプリケーション（個人的にはこの表現にも少し違和感があります）はやろうと思えば（.Net Frameworkを利用する、しないは別で）winmainからテキストエディタなどでフルスクラッチする事も出来ます。現実的にはMFCのクラスライブラリをVSのウィザードを使ってベースを生成してそれを使って行く事だと思います（これも一見フレームワークに見えますが、実際はプログラムで必要な処理部分を生成するだけなのでちょっと違うと思ってます）このあたりはそれなりに敷居が高いこともあり、VBや.Net Frameworkというものが出てきたのは流れとして必然だと思います。
> 均一の作りで遊びがないことが最終的に品質の向上につながるのであり、
> それはフレームワークによって枠組みが提供されるから実現できるのだと思っております。
> そして、大半の処理はフレームワークの枠内で出来ます。
これが理想ですが、出来合いのフレームワークでは日本のシステム開発の場合、ユーザーの要求が必ずしも枠内だけで収まらない事は良くあると思います。その時優秀なエンジニアであれば枠内で収まるような折衷案を出してユーザーに提示する事が出来るでしょうが、現実はユーザーの方が強い事もあり、枠をはみ出さないといけない事の方が多いでしょう。そうせざる得ない原因はエンジニアにはありませんが、そうなった時の「仕方ないから」とやっつけでやってしまうエンジニアに危機感を感じます。
管理者として現場にいると経営陣から言われる事もエンジニアがそうなってしまう理由も非常に理解できるので完全にジレンマなのですが、それでもエンジニアには楽をする本筋を考えて欲しい理由からやや極端なコラムになってます。フレームワークを日常で扱っている人の意見はなかなか聞けないのですが、こういうコメントを頂くとコラムを書いた事は成功かな、とうれしい限りです。
MASASHIGE
にゃん太郎さん、お返事ありがとうございます。
にゃん太郎さんのフレームワークに対する捉え方を勘違いし、
見当違いのコメントをしてしまっていたようです。
申し訳ございません。
＞Javaと.NET Frameworkの違い
わざわざ説明していただき、ありがとうございます。
言語仕様、と言ったのはまずかったですね。すみません。
.NET Frameworkを一番狭義に捉えた場合、そこに含まれるものは
「実行エンジン(CLR)」と「標準クラスライブラリ」であると認識しております。
それは、javaで言うとJREに含まれているもの（JVMと標準クラスライブラリ）なのではないか、
中身の作りは似て非なるものであっても、
その役割はStrutsなどのソフトウェアフレームワークよりもJREに近いものなのではないか、という認識がありました。
言語仕様、と言う言葉を使ったのはそのためでした。
上記の認識から、.NET FrameworkとStrutsを並記して「フレームワーク」として
語っておられるのを見て、その枠の大きさの違いに戸惑い、
内容が.NET Frameworkが提供するクラスライブラリの仕様に関する部分でもあったため、
「ソフトウェアフレームワーク」の話ではないとしてコメント致しました。
＞出来合いのフレームワークでは日本のシステム開発の場合、
＞ユーザーの要求が必ずしも枠内だけで収まらない事は良くあると思います。
私の短い経験の中では、未だにそのような事態に遭遇したことがありません。
プロジェクトの一部の機能がはみ出すことは確かにありましたが、
そのせいでフレームワークに載っている他の部品や画面に影響が出たことはなく、
全てプロジェクト内でコントロール出来ていた（はみ出し部分はスキルの高い人へ振る）ため、
上記のような発言をしました。
やはり、上手くいかない所が多いのですね、世の中…
少ない経験で自分の環境に当てはめた一方的なコメントで失礼致しました。
丁寧に返答していただき、ありがとうございました。
Ｓｏｄａ
うーん、MASASHIGEさんとのやりとりなどをみていると、フレームワークを題材としたのがイマイチだったのかもしれませんねぇ。
こー素直にコラムを読んでしまうと、.NETを使う人は、.NETが作れるぐらいじゃないとイケナイとも読めますよね。
コラムの趣旨は、「仕様」を理解せずに「使用」するのが良くないということだと思います。
フレームワークではなく、自作ライブラリや自作コントロールのほうが、話が絞れてよかったんじゃないかなぁ。
そうすると、ひでみさんの「自分で説明できないコードを1行たりとも書くな！」に終結されてしまうんでしょうが(^^;
実際問題として、既存のフレームワークでは駄目で自作するしかないような状況って少ないんじゃないですかね？
多くの場合、カスタマイズする余地があると思いますし、そこからも外れるようなら別のフレームワークを選定することもありますよね。
・・・といっても、私は主にフレームワークとして、MFCを使っており、他のフレームワークというと.NETぐらいしか近くにないので、感覚が違うのかもしれませんね(^^;
IT業界には詳しくないので、ライブラリ感覚で作れるようなフレームワークがあるのかどうかわからなかったり(^^;
にゃん太郎さんはMFCをフレームワークというには違和感があるようですし、その感覚もわかります。
まぁ、それだけ人によって規模やらイメージが違うんでしょうね、フレームワークってやつは(^^;
「仕様」を理解するのには、実際に作ってみることが一番だという考えも理解できます。
ただ、それができる人は、初期段階で「仕様」も理解できると思うのですよ。
それができなかった人が、自作しても、「本質」に気がつける可能性は低いんじゃないかなと。
フレームワークを自作できるってことは、フレームワークを理解しているからできることですよね。
フレームワークを自作するから、フレームワークを理解できるかといえば、違うんじゃないかなと。
「フレームワークを自作した」という「結果」に対し、「フレームワークを理解している」というのが「前提」や「過程」。
「結果」を使って「前提」を生み出そうとしているようにも見えるのですよ。
それは、なかなか難しいのではないかと。
「本質」を掴めるかどうかは、その人の「センス」なんだろうなぁと思うのですよ。
何年やってても、その「センス」が身に付かない人もいると思うのですよ。
その逆で、始めから持っている人もいますし。
向き不向きっていったほうがわかりやすいかなぁ。
根本的な考え方の違いというか、取り組み方の違いというか(^^;
駄目な人はなにやっても駄目というか(^^;
本の解説やソースコードを見ただけで、わかった気になってる人とかいるじゃないですか。
一昔前（いやもっと昔かｗ）、雑誌にゲームのソースコードが記載され、それを打ち込んだだけでゲームを作ったと言ってしまうような人とかｗ
今も昔も作ることへの考え方が違う人は多いんじゃないかなーと。
便利な道具が多くなってきたので、そういう人が目立つようになっただけだと思うのですよ。
道具がそういう人を増やしたのではなく、出来る人と出来ない人の差がわかるようになっただけで、潜在的な出来ない人の数は、かわらないような気もします。
いや、そう信じたい・・・かな？ｗ
にゃん太郎
MASASHIGEさん、Ｓｏｄａさん、ありがとうございます。
まとめレスですが、ご容赦下さい。
お2人のコメントを読んでみてありがたかったのはそう考えてもらえる事がこのコラムの狙いだったからです。ですから
> コラムの趣旨は、「仕様」を理解せずに「使用」するのが良くないということだと
> 思います
と言うのはまさしくその通りです。ただ、MASASHIGEさんの意見が誤りっていう事ではなく、それも意見としてはそうだと思います。逆に書いて頂き非常にありがたいです。普段フレームワークを扱っていらっしゃるようなので、余計に考えるところがあるとは思います。いろいろ考えてこの先もやって欲しいと思います。謝る必要はないので、また他のコラムでもコメントを頂けると幸いです。
> 私の短い経験の中では、未だにそのような事態に遭遇したことがありません。
これはおそらくフレームワーク部分をMASASHIGEさんが担当しているからだと思います。
フレームワークに関しては
> まぁ、それだけ人によって規模やらイメージが違うんでしょうね、
> フレームワークってやつは(^^;
これが本質だと思います、コラムにも書きましたが「どこまで」という範囲をきちんと定義する事は難しいと思います。私は自分のコラムでは個々の「技術」に関して概要に触れる事はあっても内容にまで触れる事は基本的にしないようにしています。でも、コラムにするにはある程度「決めつけて」おかないとなかなか話を進められないので確信犯的にやや極端にやっている所はあります。ですから、
> こー素直にコラムを読んでしまうと、.NETを使う人は、.NETが作れるぐらいじゃない
> とイケナイとも読めますよね。
こう読んでもらえるぐらいに書いてます。
これからもやや「極端に」書くとは思うので、その都度読みながら心の中で「極端だなぁ」とツッコんでもらえれば嬉しいです。
実はこのコラム、内容的にはフレームワークではありませんが、本質的な部分はまだ次に続きます。その内容はＳｏｄａさんのコメントの後半部分にある程度書かれているので今回はレスしないでおきます。次のコラムも読んでその上でまたコメント頂けると嬉しいです。
じょりちょこ
うーん、正直、レベルが低すぎるような...
フレームワークがある場合とない場合を比較すると、意思決定しなければならない局面の数が違ってくると思います。特に、Ruby on RailsのようなConversion over Configulationの考え方のあるフレームワークだと、そのプロジェクトで重要ではない部分はデフォルト設定で済ませる、ということができますよね。
Strutsのように、やたらめったら設定ファイルを書かなければならないフレームワークの場合でも、それが一種のチェックリストのような役割を果たしていて、設計の抜け・漏れをそこで発見できたりすることがありますよね。
フレームワークなしでスクラッチで開発する場合でも、そうした抜け・漏れをチェックするための標準的な設計テンプレートを用意することはしないでしょうか。
---
フレームワークの内部構造を理解せず、なんちゃってで開発しているとドツボにはまる、というのはわかります。でも、それはフレームワークに限った話じゃないですよね。言語処理系についてもそうだし、ライブラリについてもそうだし、ミドルウェアについても、OSについても、プロトコルについても、ファイルシステムについても言えます。どこにでもそういう罠はあるわけです。
個人的には、70年代末からコンピュータを触って来て、初期の貧弱なハードウェアにおいて機械語でプログラミングを体験できたことは、いろいろなことに役だっているなあという感慨はあります。だから、何事もなるべく低水準の世界まで降りて行って体験した方が、高水準の世界だけで物事を考えるより間違いないという実感はあります。
しかし、趣味とは関係なく、単純に「お仕事」として業務アプリケーションのプログラミングに取り組んでいる人が、いまどき、ワンボードマイコン上の機械語プログラミングを楽しめるとも思えませんし、企業もそんな研修を社員に課すことに価値を見出したりもしないと思います。
言えそうなことは、フレームワークでもなんでも、表面だけを見てその内部構造を知らないと危ないけど、内部構造を徹底的に探究するだけの時間はないことがほとんどだから、「自分はそれを知らない」ことを自覚し、必要に応じて詳しい人に教わるようにする、予断で設計上の決断をしたりしない、くらいでしょうか。
Symfonyユーザ
私は昨今、PHP言語とSymfonyの組み合わせでシステムを開発しています。
にゃん太郎さんの言うとおり、私もFWは自作する方が、技術者のため部署のためになると思います。
Symfonyもバージョン１と２ではずいぶん違います。
フレームワークに各種個性がありすぎて、誰が見ても書きやすいはずのフレームワークという肩書きには矛盾があると思います。
それどころか、Symfonyエンジニアが見つからないなんて問題が発生します。
技術が多様化すればするほど、マッチするエンジニアが少なく、習得に時間がかかります。
これでは、あまりにも意味がないと思います。
また、従来スタンダードなPHP言語のみで開発していたころより、ずっと開発工数がかかってしまいます。
さらに、標準ORMであるDoctrineの性能が悪すぎて、検索システムでは5倍もの時間がかかっています。
普通にSQLを書いた方が圧倒的に早いのです。
より標準化されるから、どんな技術者から見てもわかりやすいはずなのに、
回りくどいフレームワークを使って、もはやPHPの原形のないプログラムを読んだり書いたり、構造を理解するよりずっと早いと思います。
あとは、設計書や規約だけしっかりしたものがあれば、良いわけです。
それらを独自フレームワーク化すればよいだけです。
志御
フレームワークは、多くの場合勘違いされていると思います。フレームワークを使用すると生産性が上がるとか、品質があがるとか…。
いわゆる、フレームワーク伝説です。
フレームワークで生産性や品質が上がるのは、フレームワーク化している範囲に限定されると思います。StrutsやSpringを使用したところで、画面や業務ロジックのシステムごとの個別の仕様をフレームワーク化しているわけではない、と言うことだと思います。
そこを理解しないエンジニアがあまりにも多すぎる（実際には、フレームワークを選択したアーキテクトやユーザー）。
Strutsに限って言えば、自分がMVCアーキテクチャに基づいてJavaを実装できるだけだと認識しています。
Strutsは基本的に、リクエストされたURLにマッピングされた処理（Action）が自動的に呼び出されることをフレームワークとして実現していて、Actionの内容は、システム仕様の実現したい画面のアクション（イベント）は、システム設計者がきちんと設計する必要があります。Strutsは画面の抽象化すら行っていないフレームワークなので、Strutsを使ったからと言って生産性が上がるわけもないと思います。
逆を言えば、MVCをルールに従って実現できると言う点においては、Strutsで十分とも言えます。
一時期流行った、DIコンテナも同様で、インジェクションやインターセプトなども、AOPの概念的な思想をプログラミングとして表現できるに過ぎないと思います。
「基本は自作で」は、半分賛成で半分反対です。
画面（UI）やバッチ、システム間連携、周辺装置連携、その他もろもろをきちんと分析していくと、必然的にある程度のパターン（デザインパターンではなく、もっと大域的なパターン）が見えてくると思います（OOPで言うところのコンピュータ領域）。その部分においては、フレームワーク化できると思います。また、ある業務（ドメイン）に関するものも、業務（の概念的な部分）を分析していけば、パターンは絞られてくるので、フレームワーク化できると思います。その辺は、どんどんフレームワークを使って楽するべきです。
しかし、それ以外は、きちんとシステムを分析して、設計していくべきです（つまり自作部分があると言うことです）。
IT業界でシステム開発しているとおかしなことに気がつきます。
案件の話が出てきた際に、どのようなフレームワークを使うかが大よそ決まっています。それは、システムの具体性がないのに、アーキテクチャーが（中途半端に）決まっているとも言えます。
自分の考えですが、要件を詰めて分析した上で、実現方式を詰めていくことで、現存するフレームワークを選べるようになるのではないでしょうか。で、当てはまるフレームワークがなければ、フルスクラッチや現存フレームワークの流用を考慮して行くのが、本筋だと思います。
そうでなければ、フレームワーク伝説に振り回されっぱなしだと思います。