N2 ToolBox(跡地)

跡地です。引っ越しました。http://d.hatena.ne.jp/nosen

フレームワークの生産性

2009-06-29 22:53:39 | 意見
たけぞうさんの日記より

フレームワークの選択は開発者の趣味?

これは釣られるエントリだなぁ。。

「フレームワークによる開発効率の差は開発者視点の趣味レベルの話でしかない」
「何を使っても開発コストは大差ない、それよりも安心して導入できることが大切だ」

と言われてしまったたけぞうさんの気持ちはすごくよく分かるのですが、
相手の方の意見は簡単に全否定することが難しい主張だと思います。

一般的に言って、あるプロジェクトが高い生産性を発揮したとして、
その生産性がプロジェクトを構成する特定の要素によって達成されたものかどうかを証明することは、
ほぼ不可能に近いと思います。

プロジェクトの生産性は、
「どういうフレームワークを使って開発するか」ということのほかに、
「どんな開発者が開発するか」
「どんな顧客のために開発するか」
「どんな作業環境で開発するか」
などなど、様々な要素に影響を受けるからです。

これら種々の要素のうち、特定のフレームワークが特に生産性の向上に寄与することを明らかにするためには、
フレームワークだけを他のものに交換し、
その他の条件はもとのままでプロジェクトを再実行する必要があります。

この「他の条件はもとのままで」ということは、実現不可能です。
同じ開発者が開発するとしても、その開発者には前にそのプロジェクトを実行した経験が
蓄積されてしまっているので、すでにその開発者の状態がすでにもとのままではない。
これは顧客についても同じことが言えます。
だからといって、開発者を他の人に入れ替えてしまったら、さらに条件が変わってしまいます。

加えて、特定の開発者が特定のフレームワークを使うから生産性が高くなる、等の
要素間の相互作用が生産性に影響を与える可能性まで考えると、

「あるフレームワークにはプロジェクトの生産性を高める効果がある」

ことを客観的に証明することはほぼ不可能であることが分かります。

それゆえ、

「フレームワークの生産性には、趣味レベルの違いしかない、どれ使っても一緒じゃん」

的な主張に対して効果的な反論をすることは難しいのです。

だからといって、冒頭の主張が正しいとは、僕は全く思いません。

同様の理由により、

「十分な安定性があれば、どんなフレームワークを採用しようと結果は変わらない」

こともまた証明することはできないからです。
というか、そもそも「十分な安定性」も同様に決して証明できないでしょう。

プロジェクトはその定義からして1回こっきりのもの、そして再現性の無いものに対して
科学的な手法で何かを証明することは出来ません。

陳腐なたとえですが、
それは1回こっきりの人生、いい大学に入って、大企業に就職したから幸せだなんて、
だれも言い切れないのと同じことです。

だから、フレームワークを選択するという問題は、むしろ宗教的な問題なのだと僕は思います。

大事なことは、開発者が自分が使うフレームワークの有用性を信じることができるかどうか。

少なくとも、いやいや押し付けられたフレームワークを使って開発者の生産性が向上することはありません。
それは、客観的に証明するというよりも、人間の共感する力によって理解すべきことです。

プロジェクトを成功に導くために、全力を尽くすのがプロだとすると、
たけぞうさんが遭遇した冒頭の意見は、その意見自体が正しいかどうかということよりも、
それを言ってしまうことによって、
「実績はそれほどでもないかもしれなけど、開発効率はいいはずだ」と
フレームワークの力を信じる開発者のモチベーションを意識せずに
殺してしまっているという意味で、空気の読めない素人くさい意見だと僕は思います。


死神の目を欲しがる人が欲しい

2008-04-16 07:55:34 | 意見
3月から4月にかけて、事業計画、とか、利益目標だとか、そういう言葉を偉い人が口走るのを耳にします。
また金の話か、とそれを聞いて私などはうんざりする訳です。
利益を上げることは企業の存在意義、金の話をするのは別に汚いことではないのに、なぜか彼らの話に私は奇妙な違和感を覚えます。

多分世の中には、
「明日が今日と同じ日であることを望む人」と
「明日が今日と違う日であることを望む人」
の二種類の人間がいるのです。

彼らは前者、私は後者です。
これは、優劣とか善悪じゃなくて、単純に人間の性格の「違い」でしかないことです。

明日が今日と同じ日であることを望む人にとって、利益を上げることは「目的」です。
会社に対して利益という責任を果たすことによって、今日と同じ明日を迎えられることが保証されます。
利益を上げるために、どういう手段をとるかは、まぁ、どうでも良い。

明日が今日と違う日であることを望む人にとって、利益を上げることは「結果」です。
なにかユニークなサービス、プロダクト、ビジネスモデルを展開する事によって、今日と違う明日を生み出すことができます。
利益はその結果ついてくるもので、結果をはかる指標です。
だめだったらだめだったらで、多少給料が下がったりするのはやむなし、来期は目標をクリアできるように頑張ろう。
それだけです。

私は特に守るべきものもないし、明白に今日と違う明日を望む人種です。
給料が上がるとか下がるとかじゃなくて、なにか今までにないユニークな
成果をあげることで、プロジェクトを成功に近づけることができるのであれば、
残り寿命が半分になることと引き換えにする取引をしても良いとさえ思っています。

NTTデータ本体のほとんどの部署は
「今日と同じ明日を望む人」にとって居心地の良い会社です。
だから、経営陣の語るビジョンや事業計画などは、どうしても私には言い訳じみて聞こえてしまう。
そのビジョン、その事業計画でなくても、明日が今日と同じ日であれば
かれらの目的は達成されるのですから、そこには必然性と説得力が欠落しているのです。

うちの会社はそれでも、せっかくセンタンとか恥ずかしげもなく名乗ってしまってるんですから、
もっと尖って、今日と違う明日を目指す人が増えて欲しいと思うんですけどね。
少なくとも私は空気などいっさい読まずに突っ走りますが。

でも私がすごい勢いで会社批判とかしても、その結果立場が悪くなったりとかは一切ないし、
毎年それなりにお給料はあがっていたりするので、
うちの会社には意外に懐が広いというか、大らかなところもあるんですけどね。

誰かの役に立つものを作れるから、プログラミングは楽しい。:63.8kg

2008-04-09 07:45:51 | 意見
なぜプログラミングが楽しくなくなったのかにて、浜口さん曰く、

 ともかく、プログラマーのレベル認定をきちんとしそれに対応する処遇を行うこと、そしてプログラマーが創造的な能力を発揮できるよう、仕様をきちんと決めるということの重要性を世の中全体で認識し、ソフトウエア開発の仕事の割合をふやしていくことが必要なのだ

浜口さんの中では仕様を決めるという仕事とプログラミングという仕事は別のものという認識のようです。つまり、プログラマの能力とは、決められた仕様をどれだけ早く、正確に、ソースコードに落とせるかで決まってくる、と。

私はそうは思いません。プログラマの仕事には、仕様を決める作業も含まれるべきであると思います。なぜなら、ソフトウェアの動作はソースコードによって決まるからです。さらに、最近のプログラム言語は抽象度が高いので、仕様と切り離せる純粋に技術的な問題はプログラマにあまり残されていないという事情もあります。
このような理由から、私は明確な「ソースコードが仕様だ」派なのです。

仕様を決める作業と、コーディングの作業を別のものと考えたときに、仕様を決めるという作業に取り組む態度としては、以下の2通りの考え方があります。

1. ざっくり決める
2. こまかく決める

もし、プログラマに仕様を決めることを求めないのであれば、
1. の態度をとった時、仕様に書かれていない部分のソフトウェアの動作は不定となります。2. の態度をとったとき、実質的にはコーディングとほぼ同じ作業を仕様を決める作業の中で行わなければならない。しかも、仕様書はソースコードと違ってコンパイルもテストも出来ないので、仕様書のバグを検出できる可能性は、ソースコードのバグを検出できる可能性よりずっと低くなります。

どちらにしても、顧客が得をする作業分担ではなさそうです。
プログラムがかけないSEも、仕様に思いを馳せないプログラマも、顧客にとってのソフトウェアの価値を高めるということに関しては、等しく無能なのです。

だから私は、

「プログラマの仕事とは顧客の求めるものを作ることであり、仕様書どおりのものを作ることではない」

というのです。

優秀な人でも意外に基本的な知識が欠落していることはあるし、パフォーマンスが環境に左右される部分も多いので、単純なレベル認定でプログラマの能力をはかることは困難ですが、
それでも、自分以外の誰かのためにプログラムを書きたいという思いをもち、そのためにどれだけ真摯な努力を積み重ねているかが一つの判断基準になるとは考えています。

面接とかでそこを見抜くのがまた難しいのですが。。


技術の進歩が顧客満足につながってない:63.8kg

2008-03-07 08:28:48 | 意見
昨日いただいたコメントです。

----
>仕事の方では立場上マネジメントに手一杯でコードを書く機会に恵まれない昨今ではありますが、
>せっかく好きこのんでIT業界に転職したんだから、ひとかどのプログラマになりたい、
という気持ちは、まだ捨てていません。

共感します。。。
日本の多く会社はなんでプログラミングを下っ端の仕事だと思い込んでいるんですかね。
業務システムのプログラミングは確かにそんなに技術力のいらないツマラナイものが多いですが、そんな空気なのかろくにプログラミングの知識がないまま「マネジメント指向がいいんだ」と思ってしまっている若い人が多くて、これは業界全体の損失なんじゃないかと思う今日この頃です。
---

これは、本当に根深い問題ですよね。
技術の進歩に、既存のシステム開発の習慣や、業界の構造がついていってないんですよ。

技術が進歩して、プログラミングの生産性が上がっても、
なぜか、

「より多くの工程を一人で担当できるようになった」

ではなく、

「より多くの機能のプログラミングを一人でできるようになった」

になってしまうのですね。

決して「プログラミングを自分でやる」方向にはいかず、
「コードを書く人たちをマネジメントする」方向にいってしまう。
プログラミングの生産性が上がっても、要求開発や設計の生産性は
あがらないから、結局、実装の工程に渡す中間成果物を生成するために、
多大なコストをかけることになるのに。

日本のSIerの顧客は技術の進歩が本来もたらすべき恩恵を受けられていないと
思います。

「業務システムのプログラミングは技術力がいらないからツマラナイ」

のではなく、

「技術力がないからつまらないシステムしか作れない」

のだとおもいます。

そろそろWebアプリケーションは難しいって主張した方が良いと思う

2008-03-04 01:03:11 | 意見
皆さん、あたりまえのようにWebアプリケーションを作ってると思いますが、
実は、それってそんなに簡単なことじゃないなって、よく思います。

前提知識が多すぎるんですよね。
言語だけをとっても、少なくとも

- JavaScript
- HTML
- JavaかPerlかPHPかRubyかPythonかC#かその他の汎用言語
- SQL

の4つをマスターしていなくてはなりません。
これらは、1つ1つをとってみてもとても奥が深く、極めることの難しい言語です。
さらに、JavaScriptとHTMLについては、ブラウザ毎に挙動が違います。
SQLはDBMSごとに方言がありますし、チューニングとかいい始めるとそれだけで一つの専門分野です。

通信プロトコルについては、HTTPはもちろん、メールを送るシステムであれば、SMTPについても
知っていなければなりません。

実装を楽にするフレームワークも無数にあって、どれを使ったモノやら、
楽になってんだか苦しくなってんだかいまいち不明です。
フレームワークやアーキテクチャの流行りもころころ変わります。
利点といえば、フレームワーク作りたい病の人(=私)が混乱に乗じてまた新たな
フレームワークを作りやすい、ということぐらいです。

そして、これらの複雑さを隠蔽しようとしても、まず、ろくなことになりません。

多分、ユーザは、みんな作ってるという理由で、Webアプリケーション作るのは簡単だと
思っているのではないでしょうか?

確かに、ちゃんとしてないWebアプリケーション作るなら簡単ですが、
ちゃんとした Webアプリケーション作るのは、結構大変なことだってことを、
ちゃんとした Webアプリケーション作りたい人たちは、もう、堂々と主張した方が
良いんじゃないかと思います。


工程で分割発注

2008-02-25 06:22:59 | 意見
最近聞いた話なのですが、お役所系の案件は、1個のでかい案件を1社がまるごと受注するのは
良くない、とされているらしく、分割して発注する、という流れになっているそうです。

その分割の仕方というのが、なんと「工程で分割」になっている模様。

分割発注自体は、意図はわからんでもないし、よいと思うんですが、
工程で切っちゃうのは止めた方がいいとおもうんだけどな。

やってみないと分からないですが、
上流担当会社と下流担当会社の間での調整あるいは責任の押し付けあいに、
かなりの手間がかかりそう。そして、そのコストは国民の血税でまかなわれる訳で。。


こころの病を考える

2008-02-04 23:45:42 | 意見
きょうび、だれでも身近に一人や二人は心を病んで仕事を休んでいる
人がいるのではないでしょうか?

専門的なところは分かりませんが、
私の感覚的には、自分の知的な能力の限界を越えた状況下に置かれたとき、
人は己の無力に絶望して心を病んでしまうのではないかと思っています。
そして、現代の社会で生き延びていくためには、とても人間の知力で対処
できるとは思えぬ複雑な問題に対処せざるを得ないことが多々あるため、
こんなにも心を病んでしまう人が多いのではないかと。

最近、少なくとも日本では、餓死したりする人も少ないようだし
(僕のまわりでは一人もいません)、身体的に厳しい状況におかれることは
2,000年ほど前に比べるとだいぶ少なくなって来たようですが、
しかし、心の痛みは、飢餓のような身体的な苦痛よりも大きい場合が
あるように思います。

身体的な苦痛の行き着くところは多分死なので、行き止まりがありますが、
精神的な苦痛は、それがどんなに激しくても身体が生きている限りは
ずっと続くからです。

そう考えると、物質的には豊かになっても、必ずしも生きやすい世の中に
なったとは言えないと思うのです。


がんばれ! ふつうのソフトウェアエンジニア

2007-02-16 22:14:23 | 意見
このメッセージは、自分自身に向けたものでもあるし、
うちのチームのメンバのみんなに対するものでもあるし、
同じ業界で働いていて、ソフトウェアでずっと食べていこうと
思っている人々に向けた言葉でもあります。

私は社会人2年目で全然別の仕事から転職して以来、
もう丸6年 ほどこの業界で細々と暮らしていますが、
長く経験を積めばつむほど、自分がソフトウェアエンジニアとして
はごくふつうの能力しかもっていないことがわかってきました。

けれども同時に、ことSI業界に関しては、ふつうのエンジニアでも、
最高ではないかもしれないけど、十分役に立つソフトウェアを作ることは
できる、ということもわかってきました。

私は C のような今となっては低水準の言語のことはよくわからないし、
エクセレントな Eclipse プラグインを書くことも、
バイトコードを自在に操ることもできません。

でも私はソフトウェアをつくる仕事を面白いと思うし、
自分の作ったソフトウェアが誰かのための価値を生み出している
ということを感じながら仕事をしたいと思っています。

特別な才能に恵まれたエンジニアでなくてもそう願う権利はあると
思うのです。そして、誰かのためにソフトウェアを書きたいと
いう思いさえあれば、それを実現することは可能だと思うのです。
そのことには、まだまだ数は少ないけど、実践してきた経験の中で
大分確信がもてるようになってきました。

問題は、私のみる限り、現在多くのプロジェクトにおいて、
このあたりまえに実現できるはずのことが実現できず、
さんざプロジェクトのメンバを疲弊させた挙げ句、
くずおれるようなクオリティのシステムしかリリースできていないことです。

それは、Maven2本でも、このBlogでも何回か発言してきたとおり
SI業界の構造的な問題であり、簡単に変えることは難しい
のかもしれません。

それでも、私は少なくとも自分のチームだけでも、この
あたりまえがある程度定常的に実現できる世界を作るよう努力したい。
うまくいってもダメでも、いけるとこまでやってみたい。
これが、私が30代前半で取り組みたいと考えていることです。
(他の場所ではあたりまえに実現できていることならば、
それはそれなりにショックですね。)

私が NTTデータという日本で最も巨大で、最も官僚的で、SI業界の病巣を
もっとも良く体現しているSIerのそのまた子会社という微妙な場所で
仕事してるので特にそのように思うのかもしれません。
とてもしんどいですが、この場所でこのような課題に取り組むことは、
それなりに意味のあることなのではないかと考えています。

自分と、自分のチームを勇気付けるためと、願わくば、
同じ思いをもつ人が増えてくれればと思って
私は次のようにいいたいのです。

----
ふつうのエンジニアにも、より価値の高いソフトウェアを書く権利がある。

ふつうのエンジニアは、その権利にもっと貪欲であるべきだ。

理不尽な現実に耐えることばかりが、

ふつうのエンジニアの給与の対価ではないのだ。

現状をベースに考えるのはやめよう。

どうしたらより価値の高いソフトウェアをつくることができるか、

そのあたりまえの疑問からスタートしよう。

あたりまえでない現状を、あたりまえと認めてしまっていては、

あたりまえの権利を手にすることはできないのだから。

自分の頭で考え、自分の言葉でオープンな議論をしよう。

決められた手順に基づくのではなく、

よりよい結果をイメージして、理解に基づいて行動しよう。

考えて行動することによってしか、

何かを変えることはできないのだから。

当然の権利を要求することは、恥ずかしくも醜くもない。

恐れず声を上げよう!

がんばれ! ふつうのソフトウェアエンジニア。


SI業界の構造的な問題とみた

2006-12-26 00:24:46 | 意見
バカ専用フレームワーク、キャッチーな表現ですな。
自分の中で何かのスイッチが押されてしまいました。私はもう、こういう話題には
自動的に反応してしまうようにできている人間なのです。
一種の病気です。なのでこの件について言いたいことは本当に
山ほどあるのですが、あんまり言い過ぎると心が荒れるので、少しだけ。

大手SIer謹製のフレームワークの裏の目的は、
なるべく単純作業を沢山増やして、スキルの低い人でもやる気のない人でも
なんでもとにかく人を大量にやとって、
プロジェクトの規模を無駄に大きく見せて、
沢山売上げを上げることなのだと思います。

ぶっちゃけ大手SIerにとっては生産性とか品質なんてどうだって
良いのです。彼らにとって大事なのはとにかく、売上。
多少使い勝手が悪かろうとみかけのバグ密度さえ低ければ
問題ない契約になってますしね。

逆に効率が良くなってもっと少ないコストでシステム開発が
できるようになってしまったら、相対的なマージンが少なくなって
自分達の給料とか福利厚生が維持できなくなってしまうのではないでしょうか。

例えば、うちのおやごさんに関していうと、
昨年度の売上げが、約9,000億円、従業員数が約8,400人。
従業員数には人事、経理、総務、研究開発などの間接部門の人数も
含まれていますから、開発に携わる人間は1人あたり軽く1億を越える
売上を上げる必要があることになります。
SIにおいて1人で1億以上の価値を生み出すことはなかなか難しいので、
基本的な企業情報を見ただけですでに何らかの
水増し戦略が必要であることは明白でしょう。

ITゼネコンというのは、大きくなりすぎて自分で自分の重力を支えきれなく
なりつつある老いた恒星のようなものです。
そして多くの中小SIerはそうした大手の体力にすがらなければ
やっていけないのです。本当にこれはSI業界の構造的な問題であると
思います。

さすがにフレームワーク作ってる人達はそこまで意図してやってる
わけではないです。彼らは彼らなりに、
現場のニーズに応えようと一所懸命やってると思います。
ただ、結果として、皮肉にもそういう役割を果たしてしまっているのだと
思います。


頭にくるのはそういう無駄の多いプロジェクトに限って大量の
税金
投入されてるプロジェクトだったりすることです。


そのキングファイル 1さつ 1せんまん ああ ぼくの税金


さて、今日もヤケ酒のんで寝るかな。