この短期連載は、社内のソフトウェア開発プロセスの標準化に日夜取り組んでいるあなたにぜひとも知っていただきたいことをお伝えしていきます。理由は、それ（ソフトウェア開発プロセスの標準化）がうまくいっているという話を、少なくとも私はほとんど聞いたことがないからです。 標準化の目的 そもそもなぜ、開発プロセスの標準化に取り組むのでしょうか。ソフトウェア開発組織の使命は、顧客のビジネスの成功に対する貢献であると、わたしは考えています。そして、日々その貢献度を上げていかなければ競争を生き残れないと感じています。事実、多くの開発組織では、表現に違いはあるものの、同様の内容を自らの使命として掲げています。そして、貢献度を上げるための手段として、自身の開発力を高めていこうとしているのです。 開発力を高めるための手段としては、 特定の分野に特化する 開発期間の短縮 開発コストの削減 品質の向上 といったことが

「従来のEJBは存在自体が間違いだった」，軽量コンテナ「Spring Framework」開発者のRod Johnson氏吠える 「エンティティBean（EJB：Enterprise JavaBeansに含まれるデータベース・アクセスのカプセル化機能）なんてないほうがよかった。エンティティBeanのせいで2～3年が無駄に失われてしまった」。現在，最も影響力のあるJava関連技術者の1人であるRod Johnson氏は，2005年6月21日に東京で開催された「JavaWorld DAY 2005」で，従来のJ2EE/EJBがいかに間違った存在だったかをとうとうと語った。「米国や英国で，新規のプロジェクトがエンティティBeanを採用したという話は，もはや1件も聞かない」。 Johnson氏は，広く使われている軽量コンテナ「Spring Framework」の開発者。J2EE開発者に大きな影響を

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 「危険な兆候５つのポイント」と題して、ものものさんが、ブログを書いているのですが。。。以下の５行しかないんです。 ・create view ・order by ・join（使っていない） ・if nest ・null おお、これは、なんか、ゲームで、地図とか、アイテムをもらった心境っすね。 このメモの推理を１つ。たぶん、これは、「ＲＤＢでの」危険な兆候かなあ。。。 はじめの、 ・create view ・order by ・join（使っていない） この３つは、佐藤正美氏のセミナーで聞いたことがある。 佐藤氏は、View禁止、Group Byをするから遅くなるといっている。 理由は、これらの処理をＲＤＢで行った場合、ワークテーブル（転置テーブルだったかな？）領域を確保するから。

ここしばらく開発現場を離れ、「こんさるたんと」のお手伝いをしている。そこでマッキンゼーの中の人と仕事をしているのだが、奴らはスゴいの一言に尽きる。激務という言葉はまさに奴らのためにある。 たしかに、私も佳境に入ると夜討ち朝駆け徹夜仕事になる。システム屋は盆と正月こそ稼ぎ時だ（悲しいけどこれ現実）。しかし、奴らの場合はそれがデフォルトで、言葉どおり休みがない。「オレも休みなんてずいぶんもらっていないよ」と言いたい人は沢山いるだろうが、もう何年も一日たりとて休んだことないよという人はいないだろ。でも奴らはそれが普通。24時間戦えますか?（死語） もちろん、という連中。 だから奴らは、通勤時間を惜しんで六本木や新宿にマンションを買っている（←激務に見合うだけ給料もハンパじゃないといっておく）。まぁマッキンゼーですら一つのステップで、激務の見返りにノウハウやパイプを吸えるだけ取って独立するつもりで

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?Swebok に尽きるかな．ウォーターフォールモデルとかPMBOKとかCMMとかCMMIとかRUPとか，その手の「何とか標準」などは大抵は論外だ．そう言ったものが「役に立つ」「きっと適用できる」と主張する人達もたしかにいる．しかし面白いことに奇妙な偶然が見られるのだ．役に立つと主張する人はソフトウエア開発経験が全く，或いはほとんどなく，下手をすると"hello world"さえも書いたことが無い*1．逆に優れた開発者で役に立つと主張する人はまずいない．なんとも奇妙な偶然だ． 以前，とある企業の方々と話をしたが，彼らは興味深い意見の持ち主だった．書類重視でウォーターフォールモデル，低レベルプログラマの大量投入による大量生産．おそらくは『上流行程神話』の信奉者．品質もメンテナンス性も全てドキュメントでなんとかし

もとはといえば燃えるプロジェクトをなんとかしようという動機で始めたPMBOK。理解に2年、普及に1年かかったが、今その果実(?)を得ているところ。既に上長を巻き込んだので、次は全社に風を起こしてみようかと。ちなみにいまだにPMPは受験していないorz。 その過程で知ってはいたが食指が動かなかったSWEBOK（ソフトウェアエンジニアリング知識体系（Software Engineering Body of Knowledge）について、akonさんが非常に興味深いエントリをしている[参照]。これは「ソフトウェア開発へのSWEBOKの適用」の書籍の紹介なのだが、SWEBOKを理解するのになかなか良いとのこと。2004改訂版が出るまでのウォームアップとして読んでみようかと。 SWEBOKとは何か。その概説（overview）をまとめるとこんなカンジ[SWEBOK overview]。 世の中には、

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） m_pixyさんのブログ、「PM見習いの読書日記」の、「その作業にかかる時間」 を読んでいて思ったこと。 揚げ足取り的なツッコミなのですが。。。 （あ）「その仕様書を作るのには１ＫＳあたり○○時間でやれますか？」と聞いてしまう理由と、 （い）設計段階での工数がひとつ前のプロジェクトの２，３倍かかってる理由と、 （う）その前のプロジェクトで設計工程起因のバグを出しまくってお客さんに迷惑かけて いる理由って、普通、おなじと思っちゃうんですけど。。 あ、ついでにいうと、 （え）EclipseやIDEAでコード書くような感覚で仕様書を書けるツールない理由も （お）ExcelやWordに書いてあるだけの仕様書より、ExcelやWordに書いてあるだけの仕様書より，ソースコードのほうが，はる

http://selenium.thoughtworks.com/index.html JavaScriptを使い実際のブラウザを介してテストするseleniumがヤバすぎる。便利すぎ。Web案件なんつーのはほんと最終フェイズになってもMVCで云うモデルに当たる部分が「仕様変更」の一言によって変更されることも多々あって、そんなときは各種testが書き直しになったりする。んで最終で時間がない状態じゃtest書き直せる訳もなく人海戦術で無理矢理なんとか仕上げる、つーのがいまのWeb案件の大概の末路の気がするんだけどそれはおいといて。 このseleniumを使えば、簡単な記述で人間が実際にブラウザを操作してテストしている部分の大半である画面遷移、フォームの入力、ヴァリデーションの正否がなどが行える。つまりインターフェイスの仕様が変わらなければ延々とテストし続けられるわけだ。最後の受け入れテストの