« 2006年4月 | トップページ | 2006年9月 »

2006年8月30日 (水)

「アーキテクトはコードを書くべし」

I've been reading a great book from the Pragmatic Programmer group called Practices of an Agile Programmer. One of its chapters is titled "Architects Must Write Code", which includes this gem: "Real insight comes from active coding." Tim Lindholm, Distinguished Engineer and Java ME Architect, put it more succinctly eleven years ago when we worked on the JDK team together: "there are coders and there are bullshitters*." (I hope he is still coding now that he is an architect!)

Tom Ball's Blog: Is Writing Code a Career Limiting Move?

「アーキテクト」(設計者)はコードを書くべきで、なぜなら、実際にコードを書いてみることで、ソフトウエア設計に対する現実的な視点が得られるのだから、という主張です。

Java ME のJDK開発時に、Tim Lindholmという人は、こう言ったとか:「ここには、コードを書いている人間と、たわ言ばかり言っている人間がいる」

ソフトウエアの設計というものは、詳細なレベルになるほど、プログラミング言語の影響をものすごく受けると思います。したがって、そのプログラミング言語で、実際にコードを書き、充分に精通していないと、まともな設計はできないと思います。

以前、RDBMSを使用した、C/S型ソフトウエアの詳細設計書で、明らかにCOBOLを意識して書かれたものを見たことがあります。そこには、「入力ファイル->処理(プログラム)->出力ファイル」が延々と連なっているフローチャートが書かれていました。

それで、実装はどうなっているんだろうと、データベースを覗いてみますと、大量の「ワークテーブル(ワークファイル)」が作られていました。複数ユーザで同時に使用することは考慮されておらず、データベース全体を、そのプログラム1つが「占有」するような作りだったように思います。

結局のところ、ソフトウエアの設計を適切に行なうには、その時点での、OS、ミドルウエア、そして、プログラミング言語に精通していなければならない、ということですね。そして、精通するためには、実際にコードを書いていなければならない、ということだと思います。プログラミングの「環境」、そしてソフトウエアの設計方法は、時代とともに変わっていきますから。

| | コメント (0)

チープだけど効果的な「ソリューション」

何だか、感心してしまいました。

「ちょっと、その操作を見せてください。」と言って見せてもらった。まさに、単純作業だった。ページを開いてコピーして、次ページをクリックしてコピーして... 「これっ、パソコンで自動処理させませんか?」と言ったところ、「そんなことできるの?」という。

 パソコンのキーボードマウスの動きをプログラミングさせることが出来るのだ。これを使って、単純作業をパソコン自身に覚えこませて起動することで、自動化が実現できるのだ。

単純作業は派遣を使うより、プログラミング - ITコンシェルジュの Try ! & Error ? [ITmedia オルタナティブ・ブログ]

個人的な印象なのですが、「キーボード・マウス操作の記録・再生」を行うソフトウエアというのは、「テストの自動化」の文脈でよく出てくるように思います。「これで回帰テストが簡単にできます」みたいな謳い文句で。

でも、このソフトウエアで、「単純作業を自動化」というのは、考えもしなかったですね。恥ずかしながら。

プログラマにとっては「単純作業を自動化」というのは、日頃から意識して実行することですけど、これは主として、「スクリプト言語 で自動化」というアプローチでして。UNIX系OSなどの「テキストべース」のインターフェイスが好まれるのも、ひとつには、これが念頭にあるわけです。コマンドをテキストファイルに並べてやるだけで、自動化できますから。(もちろん、これはこれで大事なことだと思います。プログラマにとっては。)

しかし、「キーボード・マウス操作の記録・再生」だけなら、プログラマでなくとも簡単に出来てしまうので、本当に、「チープで効果的」(褒め言葉です)なアイデアだと思いました。

特に、中堅・中小企業のお客さまには、こういった方法は、すごく受けると思います。多少、不細工でも、お金をかけずに目的(効率化など)を達成する。大げさで高価な「ソリューション」よりも、こういったものの方が喜んでいただけますね。

| | コメント (0)

2006年8月29日 (火)

システム開発の対価はどうあるべきなのか

【例えば、ITアーキテクトって何?】
...
ITmedia いちばん楽しそうな仕事ですね。

林 いちばんおいしいところでもあります。

成本 そうなんです。先日、六本木を歩いていましたら、ビルの建築現場があり、アーキテクトの名前が掲げられていました。一人の名前がそこに書かれているということが、すべてを象徴していると思います。
...
【ITアーキテクトの報酬は?】

ITmedia 建築士事務所の報酬は、法律に基づいて算出基準が定められていて、工事費の10%前後と大体決まっています。

成本 IT業界もそれに近づくためには、見積手法が確立されないといけません。見積もれないから人月になってしまっていたわけです。成果物の価値をどう見積もるかが重要になります。
...
ITmedia エンタープライズ:「契約と対価」から導くITエンジニアの将来像

システム開発において、「人月単価からの脱却」というのは、ときどき出てくる意見ですね。上の記事では、建設業に例えており、これも良くつかわれる比喩だと思います(私自身もたまに使いますが)。

ところで、当の建設業界の人の話を読ませてもらいますと...

ある設計料入札で、とある設計事務所が「1万円」で設計を落札したらしい。彼は、中途半端な設計で後のすべてはゼネコンにやってもらう予定だった。でも建物が出来れば自分の名前が社会にでるとか。
MOZANBLOG: 耐震計算偽装

日本の設計費は安い。これは以前にポストしたように日本人がプロフェッションという「サービス」にお金を払うという文化が無いため。モノには払うけど、人には払わない。だから、モノを建ててくれるゼネコンにはお金を払いやすく、ゼネコンは設計料や研究費を「モノ」の値段にドンブリ勘定に含める。
MOZANBLOG: 日本の建設費は高いか

「モノ」「サービス」の値段というのは、発注側・受注側双方の「綱引き」、交渉で決まってくるものですから、一方的に、こちらがこれだけ「人月」がかかっているので、払ってくれ、という風にはいかないですよね。

現実には、「綱引き」で決まった価格に、人月を合わせるようなことをしており、これが、「デスマーチ」を頻発させることとなっていたわけで。実際、「買い手市場」のときには、「赤字プロジェクトの大量発生」が問題となっていたように思います。

つまり、「人月単価」を使っていても、市場の価格メカニズムの影響は受ける、ということでして。これが「人月単価」の概念と矛盾を起こしているのは、確かですね。「成果物ベース」とするのは、もしそれが可能なのであれば、正しいのかもしれません。

もっとも、「成果物ベース」としたところで、競争がある限り、価格低下は続くと思います。むしろ促進されるかもしれませんね。

どうも、ベンダー側が「人月単価の脱却」を唱えることが多いように思いまして。それに、「買い手市場」で価格が下がり続けていたときに、言われ始めたようにも思ったので、ちょっと気になりました。

|

2006年8月27日 (日)

「サーバ台数の見積もり」について

  1. Web/AP/DBサーバで実行される、トランザクション1件あたりのCPU時間(xミリ秒)
  2. 1秒間に処理する必要のあるトランザクション数(y件/秒)
  3. 仕事量 w = x * y / 1,000(xにyを乗じる)
  4. 必要CPU数 w' = w / (MP係数 / 1台あたりCPU数 * CPU使用効率)
  5. サーバ数 = w' / 1台あたりCPU数
  • MP係数:「非対称マルチプロセッサ(Symmetric Multi Processor)」でCPUを増やしたときのマシン性能の向上率を示す値。例えば、MP係数が1.8ならば、CPUを2つ搭載したマシンは、CPUを1つ搭載したマシンの1.8倍の性能を発揮することを意味する。
  • CPU使用効率:100%ではなく、50%~70%の余裕を持った値を使用すること。

[月間]ジャバワールド  2006年10月号(vol.113)p.53-54

最近、この手の「サービス基盤」や、「キャパシティ・プランニング」を特集する雑誌が多いですね。それだけ、この問題に頭を悩ませている人が多いということかもしれません。かくいう、私もその一人のわけですが。

ただ、上記のように、「細かな数字を積み上げる」式の見積もりというのは、計画段階では、あまり意味を持たないようにも思います。というのは、結局、推定に推定を重ねてしまう形となりますので、数字を積み上げるうちに、誤差が大きく拡大してしまって、現実的な数字が出にくいように思うからです。記事中にもありますが、「過去の事例を参考に」して、エイヤと目安の数字を出してしまう方が、案外、うまくいったりしてしまうんですよね。

実際に運用を開始して、ユーザ数やPV数が取れるようになると、こういった計算も意味のあるものに出来るとは思うのですが...

---

Java World (ジャバ・ワールド) 2006年 10月号 [雑誌] Book Java World (ジャバ・ワールド) 2006年 10月号 [雑誌]

販売元:アイ・ディ・ジー・ジャパン
Amazon.co.jpで詳細を確認する

Software Design (ソフトウエア デザイン) 2006年 09月号 [雑誌] Book Software Design (ソフトウエア デザイン) 2006年 09月号 [雑誌]

販売元:技術評論社
Amazon.co.jpで詳細を確認する

WEB+DB PRESS Vol.34 Book WEB+DB PRESS Vol.34

販売元:技術評論社
Amazon.co.jpで詳細を確認する

| | コメント (0)

2006年8月24日 (木)

「文芸的プログラミング」を試みる。

Documentation and source code are written into one source file. Both the complete source code and its documentation can be extracted from this file with specific utilities. The information is written and presented in a reading order suitable for human consumption with detailed explanations. The code is automatically rearranged for ordinary processing by other computer tools, such as compilers or interpreters.
「Literate programming」(Wikipedia)

Donald Knuthが提唱した「文芸的プログラミング」のコンセプト-ソースコードとドキュメントを一つのものとして扱う-は、Java言語のJavaDoc や、Perl言語のPOD などの「埋め込みドキュメント」に受け継がれています。

私は、プログラムの「詳細設計書」のようなもの、つまり、プログラムの呼び出しインターフェイス仕様を書いたり、プログラムの処理を書いたりするドキュメントを、今まで、必要に応じて作成していたのですが、やはり、これは、「ソースコードそのもの」を、そのまま仕様とするようにすべきだと思いました。結局、プログラマは、ドキュメントをソースにコピーするような作業をやりますから、初めからソースファイルに書く方が、無駄がないですよね。

よく、OracleデータベースのPL/SQL言語(ストアド・プロシージャ)を使用して、アプリケーション・ロジックをサーバに置く、ということをやっています。このインターフェイス仕様を書くのに使えるツールはないか、とネットを探し回った結果、PLDoc というソフトウエアを見つけました。

以下のように、日本語も、ちゃんと使えるようになっています。
(ver0.8.3です。ver0.8.3.1では使えなくなってしまってます。)

pldoc -doctitle \"Samples\" -overview overview1.html -d Samples -inputencoding Shift_Jis sample*.sql

エンコードで、"UTF-8"だけでなく、"Shift_Jis"も使えるのは有難いですね。HTMLをUTF-8にするのは良いのですが、ソースコードは、OSネイティブな文字コードを使いたいので。

しばらく、このツールを使って、インターフェイス仕様を書いているのですが、今のところは、順調にいっているようです。「紙にしにくい」というのは、難点かなと思っていますが、プログラマ以外は読まない類のドキュメントですので、問題はなさそうです。

ちなみに、数ある「埋め込みドキュメント」のツールの中では、RDOC(Ruby Documentation System) が秀逸だと思います。ソースコードまで見られるのは、素晴らしいですね。

---

Book 文芸的プログラミング

著者:ドナルド・E. クヌース
販売元:ASCII
Amazon.co.jpで詳細を確認する

| | コメント (4)

2006年8月22日 (火)

「どこかに、逃げ込んでいないか」のコメント

 システム開発のプロジェクトに携わっていると、僕自身が開発しないせいかよく見えてくることがあります。それは、エンジニアが逃げていること。
....
 給料を貰っているのだから、自分はプロだ。最近、そう考える人も少ないのかも知れません。70点、80点の合格点で良い。そう考えているのでしょうか。100点を目指したいとは思わないのでしょうか。

どこかに、逃げ込んでいないか- 「走れ!プロジェクトマネージャー!」 [ITmedia オルタナティブ・ブログ]

システム開発でも、ある程度経験を積んで、中堅・ベテランと呼ばれるようになると、自分の決めたレベルで、仕事を「こなす」ようになり、より上のレベルで仕事をしようとする意欲が薄れる、という人は、わりと多いのではないでしょうか。

ただ、この産業は、まだ未成熟で、ある意味、「まとも」といえる仕事は出来ていないと思います。過去の経験といっても、失敗ばかりとまでは言いませんが、満足すべきものではないのは確かですね。「100点を目指す」というより、それ以上、より上のレベルを目指していかないと駄目だと思います。

といっても、ハードなお仕事ですので、私もよく逃げたくなりますね。忙しいときほど、無性に、映画を見たり、音楽を聴いたり、小説を読んだり、したくなります。現実逃避衝動ですね。プロジェクトが終わるまで我慢して、結局、プロジェクトが終わったときには、燃え尽きて、そういったことも何もしたくなくなるわけですが。

久石譲氏の著作は、帰りに本屋によって買ってきました。今、ぱらぱらと流し読みしていますが、面白そうですね。

失敗の原因は自分のうちにある。

新しいことに挑戦しようとするとき、経験則で水を差す人がいる。その人にとって、経験がプラスになっていない。むしろ進歩を妨げている。

などなど。

宮崎駿監督のものは、主に対談ですが、既に何冊か出てますので、後は、鈴木プロデューサーのものが読みたいですね。

| | コメント (0)

2006年8月20日 (日)

オブジェクト指向は「進歩」なのか

オブジェクト指向プログラミング(OOP)が広く使われるようになり、オブジェクト指向が、ソフトウエア開発の「銀の弾丸」である、といった、普及当初の過剰宣伝気味の論調から、最近は、オブジェクト指向は本当に必要なのか、といった疑問の論調も出てきているようです。

OOPを使ったからといって、ソフトウエア開発の様々な問題が解決できるわけではありませんし、逆にOOPを使わなくとも、解決できることもあるかと思います。OOPがプログラミングに新たな概念を持ち込んだことで、かえって、問題を複雑にしている、という見方も出来るかもしれませんね。

私はOOPというものは、理論的・原理的に導き出されたものではなく、開発現場の要請から生まれてきたものだと思っています(OOPを嫌うプログラミング理論の研究者がいるのはその証左かと)。結局のところ、これはソフトウエアのモジュール化の延長線にある、と思います。

OOPによって、ソフトウエアのモジュール化をより高度な形で行えるため、ソフトウエアの「分割」を、より自然な形で行えるようになったのではないでしょうか。従来の手続き型プログラミングで起こりがちだった、プロジェクト・チームのメンバー構成にあわせ、「作業単位」によってソフトウエアをモジュールに分割する、という不自然なことをやらずにすむようになったのではないでしょうか。

ソフトウエアそのものの論理的構造に基づいて、ソフトウエアを自然な形でモジュールに分割し、そして各モジュールを、プロジェクト・メンバーの作業単位として割り当てることができる。これが、OOPのもたらした「進歩」のひとつであろうと思います。

---

脱オブジェクト指向のススメ - 雇われIT社長の乱心ブログ [ITmedia オルタナティブ・ブログ]

この記事を考えたきっかけです。

---

C++の設計と進化 Book C++の設計と進化

著者:エピステーメ,ビョーン ストラウストラップ
販売元:ソフトバンククリエイティブ
Amazon.co.jpで詳細を確認する

私が初めてオブジェクト指向の勉強をしたのは、Bjarne Stroustrupの、「プログラミング言語C++」によってでした。C++言語は、現在に至るまでの、「オブジェクト指向ムーブメント」の「原点」なのですよね。きっと。 

| | コメント (0)

ウォーターフォールとXP

ウォーターフォール型のソフトウエア開発プロセス-最初に、ソフトウエア設計のすべてをドキュメントに記した後、コーディング・テストへと進む-と、エクストリーム・プログラミング(XP)の開発プロセス-要件(ストーリー)ごとに、テスト・コーディングを繰り返す-は、ある意味、両極端な開発プロセスの「モデル」だと思います。

おおまかにいって、ウォーターフォール型の開発プロセスというのは、管理者(マネージャ)側からみた場合の、ソフトウエア開発の「あるべき姿」であり、一方で、XPというのは、制作現場(プログラマ)側からみた場合の、「あるべき姿」という風に思います。

「モデル」というものの果たす役割-わかりやすく説明するための抽象化-を考えると、両者とも十分にその役割を果たしています。「非現実的である」という批判は、どちらの開発プロセスに対してもありそうですが、それは「モデル」というものはそういうものであり、現実にそのとおり実行すれば良い、ということを意味する訳ではないと思います。

現実の開発プロセスは、この両極を折衷したところにあると考えるのが妥当ではないでしょうか。そのバランス-ウォーターフォールに寄るかXPに寄るか-は、プロジェクトの置かれた状況によって、決まってくるのだと思います。

---

Waterfall model (Wikipedia)
ウォーターフォール型開発プロセスについて、詳しく解説した本というのは、寡聞にして知らないのですが、このWikipediaのエントリは、歴史的経緯を含め、よく解説されていると思います。

Extreme programming (Wikipedia)
同じく、エクストリーム・プログラミングのWikipediaエントリです。

---

XPエクストリーム・プログラミング入門―変化を受け入れる Book XPエクストリーム・プログラミング入門―変化を受け入れる

著者:ケント ベック
販売元:ピアソンエデュケーション
Amazon.co.jpで詳細を確認する

XPの提唱者である、Kent Beckによる入門書ですね。

---

エクストリームプログラミングの名のもとに集められたアイデアの中には、素晴らしいものがたくさんあり、それほど大したことがないものがいくつかあり、そして非常に危険なアイデアが1つある。その危険なアイデアとは、計画やデザインは時間の無駄、というものだ。

Joel on Software p.267

| | コメント (0)

2006年8月19日 (土)

DB設計を理解するのに最低限の知識

現在の業務アプリケーション開発では、必ずといってよいほど、リレーショナル・データベースを使用します。しかし、お客さまは当然のこと、プロジェクト・メンバーも、リレーショナル・データベースの基礎的な知識が不足していることが多いです。

リレーショナル・データベースの設計を行うには、当然、相応の知識が必要ですが、その設計の意図するところを理解するにも、最低限のことは知っておく必要があります。

お客さまや、プロジェクト・メンバーに、この「最低限のこと」をどうやって説明すれば良いのか、考えてみたのですが、結局のところ、主キーと外部キーの2点に集約することができそうです。テーブル(表、リレーション)とはなにか、というレベルから説明しなくてはならないこともありますが、大抵は、直感的に理解していただけるようです(説明することも難しくはないと思います)。

そこで主キーと外部キーについて、以下のような文書にまとめてみました。
「リレーショナル・データベースの設計について」

なお、「外部キー値のNULLを禁止する」必要はなく、外部キーがNULLであっても、外部結合操作(左、右、両方)など、テーブル操作で支障をきたしたりはしないようです。この部分は、いずれ変えるつもりです。

---

データベース実践講義―エンジニアのためのリレーショナル理論
同著者の「データベース概論」という本があり、これは、リレーショナル・データベースの百科事典のような本で、ありとあらゆる論点が網羅されており、よく参照します。こちらは、その抜粋版といった趣ですね。

 Refactoring Databases: Evolutionary Database Design (Addison Wesley Signature Series)
データベース設計のリファクタリング集です。私はこの本の巻末にある、「UML Profile for Data Modeling」を参考にして、データモデル図を作っています。この図法が一番わかりやすいですね。

データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして
「T字型ER」法による、データベース設計を解説した本です。UMLデータモデル図で、主キー(Identifier)の箱を分けているのは、この本の影響です。

楽々ERDレッスン
データベース設計の基礎を、専門的になりすぎず、わかりやすく解説しています。特に、主キーの設計の部分については、例が良く、参考になりました。

---

A UML Profile for Data Modeling
書籍”Refactoring Databases”より、UML解説部分がWebサイトで公開されています。

| | コメント (0)

SIの積算手法(基盤部分)

先日、後輩がWebアプリケーションの基盤部分(インフラ)、つまりハードウエア・ネットワーク・ミドルウエアの調達・見積もりで悩んでいまして。私も以前にその手の仕事をやったことがあるので、色々助言したり、余計なことを言って混乱させたりしていましたが、何とか、見積もりが完成したようです。

この手の仕事をやるときに、いつも思うのが、SIの見積もりに関して、積算手法といいますか、見積もりで使える数式なり表なりグラフなりが、どこにも存在しないことですね。

昔、建築設備の見積もりシステムのようなものを開発していたことがあるのですが、建設や機械などの分野では、ある程度、定式化された積算手法があるのですよね。例えば、空調設備なら、ビルのフロア面積から、必要な空調機の容量を出し、その容量の機械だと、このくらいの値段になる、というのが、数式・表・グラフなどを駆使して導き出せるようになっている訳です。

SIでも、アプリケーションに係る部分は、それこそ、個別の要件によって、まったく違ってきますので、定式化は不可能かとは思うのですけど。でも、こういった基盤部分については、ある程度、定式化ができるのではないかと思います。例えば、同時接続のセッション数から、Webサーバ・DBサーバに必要な計算機容量(CPU数クロック数・メモリ搭載量など)を出して、その容量だと、おおよそ、この値段になります、といった感じで。

どうなのでしょうかね。メーカーさんなんかは、内部でこうゆう定式化された積算手法をお持ちだったりするのでしょうか。まあ、メーカさんがお持ちでも、こういった情報は機密扱いで、外には出ないでしょうね。それは、建設や機械でも同じですから。こういった仕事は政府関係じゃないと難しいけど、それこそ、政府もSI調達業務があるわけですから、やっても良いと思いますね。

| | コメント (0)

2006年8月12日 (土)

『「ソフトウェア開発」は「モノ作り」ではない 』を読んで

以下は、
「ソフトウェア開発」は「モノ作り」ではない 

を読んでのコメントです。

私はSIerに所属しています。
他の多くの人と同様、現状に非常に危機感をもっています。

「納期どおりに高品質のシステムを納品する」は、
お客様にしてみれば、「当たり前」のことです。
それが出来ない方がどうかしてますよね。
お客様のお怒りはごもっともと思います。

「コミュニケーション能力」については、私も似た考えです。
個人的には、できない言い訳ばかりしているから、
「コミュニケーション能力」が問題とされるのかなと思います。
が、問題の根本は、技術力がないからですね。

「ソフトウエア開発」は「映画製作」(特にアニメーション映画)
に良く似ていると思います。

スタジオジブリの『「もののけ姫」はこうして生まれた。」という
ドキュメンタリー・ビデオをご存知でしょうか?
スタジオジブリの仕事振りが描かれているのですが、
私達の仕事の参考になるところがあります。

1) 監督

一般的には、プロジェクト・マネージャー(PM)ですが。
どうも、この業界では、
「進行管理」がPMの仕事と考える傾向があるような気がします。
PMの仕事は、「プロジェクトを完遂させること」であり、
そのために、ありとあらゆることが仕事となるはずです。
「進行管理」はそのための一手段でしかないですね。
ちなみに、映画では、「進行管理」係の人が別にいるようです。

オーケストラの指揮者は、
オーケストラで使用する楽器すべてに精通しているとか。
もちちん、楽曲についても、すべてのパートに精通していなくては駄目ですよね。

2) 原作・脚本

「要件定義」や「基本設計」にあたるかと。
「何を作るか」のグランドデザインですね。

3) 原画チーム

アニメーションの「核」となる部分の絵を書く人達です。

ソフトウエアの場合、特に優れたプログラマが、
プログラムのモジュール構成・クラス構成を考え、
各モジュール・インターフェイスを作る部分でしょうか。

ソフトウエアの要になる部分のプログラミングをしたり、
「お手本」を作ったりすることですかね。

4) 動画チーム

アニメーションの原画をもとに、
原画間の動きの部分の絵を描く人達です。

ソフトウエアの場合は、「原画チーム」の作った「枠」を、
埋める形でプログラミングする人達ですね。

----

「もののけ姫」はこうして生まれた。 「もののけ姫」はこうして生まれた。

販売元:ブエナ・ビスタ・ホーム・エンターテイメント
発売日:2001/11/21
Amazon.co.jpで詳細を確認する

| | コメント (0)

« 2006年4月 | トップページ | 2006年9月 »