シリーズ化してしまいつつある
情報処理における学会と産業界というのは、かなり距離がある。
したがって、２つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。
前回の最後にこう書いた。
ただ、参考資料の４４シートの話は、こういう風な流れにはなっていない。
つまり、もう一つのお話がのこっているんだけど、それについては、またこんど。
ここで出てくる、参考資料とは、
~ トヨタ カンバン方式に学ぶ ~
ITシステム開発・管理への適用と実践技法
2. リーン・ソフトウェア開発
http://www.metabolics.co.jp/SoftwareProcess/SRC040903/LSD02.pdf
で、このシリーズの前回の話は、
「アジャイルでやるのは、下流工程にならないと、問題が見えないことがあるから」
だった。しかし、その参考資料の４４ページにあるのは、
「アジャイルでやるのは、生産性が高くなり、リスクが下がったから」
となっている。
もちろん、この理由は正しい。
今日は、こっちの理由についてみてみる。
■実務上は、大学で教えるより、もっと簡単にプログラムが作れる。
なぜか。
フレームワークを使って開発するから。
フレームワークは、結構、いろんなことをやってくれる。
共通なメソッドなども使える
さらに、ビューは１からコーディングしなくても、
画面レイアウトをＨＴＭＬで作成すると、
それが流用できる。
ってなことで、簡単にプログラムが作れる。
CakePHPだと、すごく簡単にできるときもある。
10分で作るCakePHPアプリ アプリケーション編
http://moyashi.jp/cake/cake_app.html
実務上、そんなに簡単なシステムはありえない。
しかし、Railsっぽい話を教えないと、今の現場の感性とは、
合わない気がする。
（ＭＤＡとRailsを関連付けて話す必要があるはず）
また、フレームワークだと、修正のさいでも影響範囲は限定される。
ってなことで、生産性が上がった。
■大学は、実務上、一番大切なことを「教えることはできない」
一般にフレームワーク開発において、一番大切なことは
「ハリウッドの法則」
だ。
「私を呼び出すな、必要なら私から呼び出す」
ってことだ。
つまり、フレームワークから呼び出すので、フレームワークが対応していないような
イベントなどを制御するのは、とてもむずかしいというか、やっちゃいけない
ことになる。なので、フレームワークを使った場合、最適なＧＵＩなどが存在し、
それに逆らわなければ生産性があがるが、逆らえば生産性はとてつもなく下がるのだ。
だから、フレームワークが大事で、それに設計はもちろん、要求までも左右される。
・・・なんてこと、大学では口が裂けてもいえない。
まず、「ハリウッドの法則」って、論文が出ていない（たぶん、詳しく調べてないけど）
論文がない、著名な先生の本になっていない＝大学でそんなこと、教えられないでしょ！
次に、これを認めてしまうと、要求は、フレームワークというプログラミング手法に
影響を受けることになる。
こんなことは、認められない。
要求の権威、ロバートソン（だんなさんでも、おくさんでもいいけど）
はむしろ逆のことを言っている
要求は、実装にひきづられてはいけない。
要求は「何を」を定義するので「どうやって」は定義してはいけない
■現実は、フレームワーク導入はかなり早く決まり・・
しかし、例えばスマホ＆ＰＣ同時開発の場合、ネイティブアプリより、
ＨＴＭＬ５で作ったほうが早い。
機種によって切り分けるのはＣＳＳ３でやったほうがはやい。
なので、ＨＴＭＬ５＆ＣＳＳ３と決めてしまうと、
使い勝手とレスポンス等がびみょ～に影響を受けてしまう。
現実的には、フレームワーク導入は、ＲＦＰ中、ないしはそれに対する提案書作成時
等、かなり早く決まってしまい、フレームワーク前提で、使い勝手とかを考えることも
（ことが？）多い。
つまり、現実的には
生産性向上・費用低減
→フレームワーク採用（それ前提で費用見積もり）
→使い勝手、処理スピードなど非機能要求に影響
という構図になっている。
だけど、そんなことはいえない。
要求の前に設計方針を決めることなんて、やっちゃいけないことになっている。
大学では、デザインパターンは教えても、
フレームワークはあんまり教えない。
それは、こんなところに理由があるのかもしれない。
ここで、要求→設計という流れを話したが、
実は、大学のソフトウェア工学の教育方法と
現場との違いは、根本的な相違点がある。
それは、
パターンっていうのは、計算機工学の考え方の基本なんだよ！
http://blog.goo.ne.jp/xmldtp/e/0cf44129a90e47cefa3ac5d3d7a04f75
に書いたことでもあるんだけど、
ダック・タイピングを認めるか否か
が決定的な違いになる。大学の教育は、抽象から演繹的に落としていき、具体になっていく。
それに対し、現在の開発は、ダッグタイピングを認め、帰納的、ないしはアブダクションによって意思決定していくことが多い（たぶん、演繹的に考えるより多い）
それについては、次回書く予定。
アクセス
トータル
ランキング
