フロー理論で分析する、フレームワークの開発効率
結論を先に書くと、「フローを積極的に誘発するフレームワークほど開発効率が高い」という話。
「生産性」は、ソフトウェア開発では適切じゃない
さて、shot6さんのブログ経由で、フレームワークと生産性の話が話題になってることを知った。
■生産性という幻想 (風邪で寝込んでいる間に)
http://d.hatena.ne.jp/shot6/20080622#1214129732
さらにその記事の言及元 ↓
■Springの生産性
http://www.arclamp.jp/blog/archives/spring_productivity.html
「生産性」という単語は、ソフトウェア開発においては適切じゃないと前々から思ってる。
shot6さんは「生産効率の定量化」という意味において、幻想だと言ってる。たしかにその通り。
生産性は、設計が決まったものを設計書どおり繰り返して作り出すときの性能を表しているが、
現在のソフトウェア開発は設計と製造に垣根はない。
ソースコードも詳細な設計ドキュメントと考えることが可能であり、
つまり「製造＝設計」といえる。そこに生産性は存在しない。
「クリエイティビティーの性能」を数値化できれば良いのだけど、そう言う方法は現在無い。
「めんどくさくなさ」、がフレームワークの「開発効率」の評価指標
ただ元記事で使われている生産性という単語は
「めんどくさくなさ」（ ! めんどくささ ）という意味だと思う。
フレームワークの生産性という場合、
「同じことをするのに、どれだけめんどくさいか？」
という点を評価して、そのFWの生産性と呼ぶのが一般的に使われている語感と最も近いと感じる。
ここで生産性という言葉を使ったが、先述の通りどうも適切ではない。
ここで言うフレームワークの「生産性」は、フレームワークの「開発効率」と呼ぶべきだ。
Seasarが開発効率の向上を目指しているのは、紛れもないことと思う。
それはFWの設計思想として、優先順位の最上位に何をもってきているかということであって、
Springは開発効率よりも、包括的であることを選んでいると思う。
正しくは「フローへの入りやすさ」がフレームワークの開発効率
上記で、「めんどくさくなさ」がフレームワークの開発効率の評価の指標だというように言ったけど、
もうちょっと突っ込むと「フローへの入りやすさ」という表現の方がいいかもしれない。
フロー（Flow）とは、簡単に言えば熱中状態だ。
http://ja.wikipedia.org/wiki/%E3%83%95%E3%83%AD%E3%83%BC
エンジニアの生産性のピークは、フロー状態（ゾーンにいるとき）だ。
だからこそ、私は「フローを積極的に誘発するフレームワークほど開発効率が高い」と考えている。
フローを誘発するための条件
上記Wikipediaの中の、フローの構成要素の中でも、以下の4つはフローに入るための条件だ。
1. 明確な目的（予想と法則が認識できる）
2. 専念と集中、注意力の限定された分野への高度な集中。（活動に従事する人が、それに深く集中し探求する機会を持つ）
5. 直接的で即座な反応（活動の過程における成功と失敗が明確で、行動が必要に応じて調節される）
7. 状況や活動を自分で制御している感覚。
特に、SeasarのHotdeployは、「5. 直接的で即座な反応」を得るうえで非常に優秀だと思う。
さらに「7. 状況や活動を自分で制御している感覚。」にもつながる。
「設定より規約」というルールも生産性に寄与する。
「2. 専念と集中、注意力の限定された分野への高度な集中」につながるからだ。
規約を覚えれば「1. 明確な目的（予想と法則が認識できる）」も得やすい。
