« 2006年8月 | トップページ | 2006年10月 »

2006年9月28日 (木)

ITシステムの投資対効果

経営者がITを理解できない本当の理由(ITPro)

ユーザ側で、ビジネスをどう展開し、そのなかでITをどのように使っていくか、これを考え抜いて、「ビジネスモデル」を作る。それを受け、ITベンダは、それを実現するためのITシステムを確実に開発する。この役割分担については、ごもっともかと思います。結局は、ユーザとべンダが、互いにプロとしての責任をもって仕事を行なう、ということに尽きるのでしょう。

一方で、ITはもはや企業経営の中核となっているのだから、ユーザ側が、ITについての専門知識・スキルを持たなければならない、という主張もありますね。

これは、どちらが正しい、ということではなく、ITに対するスタンスの違いであろうかとも思います。ITをどこまでアウトソースするのか、あるいはしないのか、これは経営者の考え方によるでしょう。その企業の提供する価値の中核が、ITにあると考えるのであれば、自社ソースでITシステムの開発を行なうべきでしょうし、そうでないと考えるのであれば、アウトソースすればよい、ということになります。

少なくとも、ユーザ側でITプロフェッショナルを雇用し、自社開発するのが「正しい」とすれば、システム構築を行なうITベンダというのは、無用の長物ということになりそうです。私どもITベンダがこれを主張することは、自己の存在否定であろうと思います。

「ITシステムの費用対効果」は、基本的にはユーザ自身が責任を負うことでしょうね。記事中にもありますように、かってはシステム化すれば業務の効率化ができていた訳ですが、この部分については、ある程度やり尽くしている状態になりつつあり、最近は、ITを新ビジネスと結びつけて、より戦略的に活用する、という流れにあるのは、私も感じるところです。そもそも、新事業を立ち上げる際、「ITありき」で考えるのが常識のような感があります。

そうなりますと、「ITシステムの費用対効果」、つまり投資が回収できるか否かは、まさに新ビジネスが成功するかどうかという点に集約されてしまうように思います。ITベンダとしては、新ビジネスを必ず成功させる方法を提供することは不可能です。これは「必ず儲かる商売を教える」に近い訳でして。ITベンダに限らず、いかなる職業であろうと、これを提供することは出来ないですよね。

まあ、これは記事からはずれた話、余談ですね。記事では、新ビジネスの成否以前に、その前提となるITシステムの構築自体の成否が不確定であり、そこまで辿り着けない、と主張されているわけですから。

| | コメント (0)

Javaの次に来るもの

Javaの時代は終わった?

"Beyond Java"という書籍は初めて知りましたが、面白そうですね。有名なPaul Graham氏のエッセイ、 「普通のやつらの上を行け」 でいうところの、「普通のやつらの上」が、近いうちに「普通」になる、というようなことですかね。読んでみたいと思います。

本を読んでないので、内容については何もいえないのですけども、「習得に何年もかかるようになってしまった、というJavaの複雑性」という点について、少し考えてみたいと思います。

--
1) 溢れる慣用句、ギミック
これは、C/C++/Javaの各言語共通の特徴だと思います。言語仕様をシンプルにした結果、ある処理を書きたいとき、自然な形で書く方法がなく、これをやるための「慣用句」が、言語仕様の外に大量に生まれるという。

2) 静的型付けとデザインパターン
「静的型付け」、つまり、コンパイル時にコンパイラはオブジェクトの型を知らなければならない、というのは、実のところ、オブジェクト指向とは、あまり相性がよくないのでしょう。ある種の「デザインパターン」-Abstract Factoryとか-あるいは、Dependency Injection(依存性注入)などは、この「静的型付け」による制約を何とか回避するためのトリックのようにも見えます。実際、Javaのフレームワークは、「デザインパターン」で溢れていますし。

3) オブジェクト参照型と組み込み型
Java言語を初心者に教えるとき、おそらく一番の壁は、「オブジェクト参照型」の概念ではないでしょうか。これは結局、「スマートポインタ」の一種だと思うのです。C/C++での、「ポインタ」が学習の難度を上げている構造が、そのまま持ち込まれていると思います。もちろん、ポインタよりは「スマート」で「安全」なのですけど。

実のところ、Rubyも「オブジェクト参照型」のアイデアを全面採用しており、この面では差はないです。ただし、Rubyが「全てがオブジェクト(参照型)」であるのに対し、Javaには別に「組み込み型」というのがあります。これが、型によって変数の扱いを変えなければならないという、煩雑さをもたらしている面はありそうです。
--

Javaのような「重い言語」に比べれば、Rubyでなくとも、PerlとかPHPとか、あるいはLisp(!)などの「軽い言語」の方が、生産性が高いのは、当たり前という気もしますけど。もちろん、どのようなプログラムを開発するかにもよりますが。

「オブジェクト指向」という枠内、あるいはJavaの代替となるもの-より生産性の高いJava-という視点では、「Rubyが最良」というのは頷けます。

JVMの何がそんなに「イケているのか」は、ちょっと想像がつきませんでした。本を買って読んでみます。

--

ハッカーと画家 コンピュータ時代の創造者たち Book ハッカーと画家 コンピュータ時代の創造者たち

著者:ポール グレアム
販売元:オーム社
Amazon.co.jpで詳細を確認する

| | コメント (4)

2006年9月22日 (金)

自分色に染めてしまいたい衝動

小野和俊のブログ:人のプログラムを自分色に染めてしまいたくなる衝動 より。

かのビル・ゲイツが、その昔、自社のBASICインタプリタのプログラム・ソースを、全部書き直していた、という逸話を思い出しました。

私にも身に覚えがあります。昔、外注先から納品されたソース全てに手を加えたりしていたこともありましたね。最近はできるだけ気にしないことにしています。プログラムの「実装部分」については。インターフェイス部分は、未だに自分色を押し通していますけど。

--
レベル1)
いわゆるプログラムのスタイル(書法)レベルですね。これは気にしないようにしてます。典型的には、「インデント論争」でしょう。タブかスペースか、2個か4個か8個(!)か。ちなみに、私は「スペース2個」派なんですけど。この論争は決着不能なようですので、自分が最初に書くときは自分色ですが、すでにソースがあって手を入れるときは、そのソースを書いた人のスタイルを踏襲します。本当は、プロジェクト内で統一した方が望ましいのですけども。一度試みてあきらめました。

レベル2)
これは、結構やってるかも...
自分が手を入れるときには、場合によっては、原型を留めないくらいに変えることがありますね。それで、別のバグを混入させてしまうこともありますけど。長い目で見れば、変えておいた方が良いコードというのもあり、状況によってはやります。

レベル3)
うーん、逆にそれでちゃんと動いているのなら、ある意味すごいですけど。まだリリースしておらず、稼動実績がないのであれば、「捨ててやり直し」ですかね。ただ、最近のプロジェクトは人的・時間的リソースがひどくタイトですので、一発勝負でやり直し不可となってしまってます。ですので、初めて一緒にやるメンバーの場合、最初にユーティリティ的な、ちょっとしたクラスなりメソッドなりを作ってもらい、それで、その人を使うか使わないか、使うならどの箇所か、を判断しています。
--

もう一つ、これは「レベル1」だと思いますが、論理式の書き方をどうするか、というのもあります。
例えば、

not ((a==b) or (c==d))

と書くか、あるいは、

(a!=b) and (c!=d)

と書くか、ですね。基本的に、私は下の方が「好み」なのですけども。人によっては、上の方を好むようです。

| | コメント (2)

2006年9月21日 (木)

jMockを使うとより「文芸的プログラミング」になる?

Javaのユニットテストを書く際、jMock を使うと、より「文芸的」でコードが読みやすくなるよ("the code more literate")、という記事のようですが。

We can use constraints to construct more flexible assertions.

assertThat(a, eq("3"));

is more readable and understandable than

assertEquals("3", a);

Tom White's Blog: Literate Programming with jMock

パッと見て、下の方がわかりやすいと思ってしまいました...
JUnitでは、下の例が「通例」ですので、「見慣れている」から「わかりやすい」と感じたのでしょうかね。

英語の構文としては、上の方がより「自然」なんですね。下の"assertEquals"ですと、動詞のassertとequalが連続しているので、英文として不自然で、上の"assertThat"は、動詞("assert")+関係代名詞("that")+主語("a")+動詞("eq")+目的語("3")の順に並ぶので、自然だということのようです。

でも、これは日本人には微妙ですねえ。プログラミング言語を「英語」だと認識している人って、あまりいないような気がします。プログラミング言語は、あくまでプログラミング言語として見ているような。あるいは「暗号」の一種として。

まてよ、むしろ、日本語として読むと下の方が自然なのかしら。「aは"3"に等しいと表明する」だから、下の"assertEquals"の例を逆順に読むと、日本語の語順になるような...

ちなみに、ハンガリー語の文法は日本語と非常に類似しているそうで。ハンガリー語は、「ハンガリアン記法」の例にあるように、英語圏の人間にとっては、「読みにくい」の代名詞。でも、日本人には、その方が読みやすいという話なのでしょうかねえ。

| | コメント (0)

2006年9月15日 (金)

ソフトウエア開発の「空洞化」

ゼネコンライクなSI企業だけの話だったら、うまくいったよしよし、まあいいか、で済むのかもしれませんが、日本の実装離れは確実に進んでいるようで、空恐ろしくなりました。よく考えてみると、そこまで現地エンジニアで回るんだったら、日本の会社が関与する必然性がなくなって、実装だけじゃなく、案件そのものを根こそぎもっていかれちゃうかもしれないですしね。

もっと進んでいるオフショアによる空洞化 - Allegro Barbaro [ITmedia オルタナティブ・ブログ]

ソフトウエア開発の場合、「設計」と「実装」という分け方は、多分に便宜的なものだと思います。言葉遊びのようですけど、開発しているのは「ソフトウエア」なわけでして。「実装」もまた「設計」の一部分、「設計」の「最終工程」だと思います。この後、「製造」がコンパイラ・リンカによって行なわれる、という見方が妥当かと。

ここから、「実装」=プログラミングから切り離された「設計」などというものは、存在し得ない、というのが私の考えです。

ソフトウエアの設計手法は、 "Software crisis" 以来、構造化設計、オブジェクト指向設計と、変化していますが、これらは、設計手法が独立して考案されたというよりは、プログラミング言語の後追いで出てきたものだと思います。設計手法が先にあって、プログラミング言語が後から出来たわけではないはず。

そして、プログラミング言語自体、まだ変化し続けています。最近では、Javaにクロージャが提案されて、話題になっていたり(Peter Ahe''s Weblog など。クロージャのアイデア自体は20年以上前からあるようですが)。これは、Lisp、Haskellなどの「関数型言語」が、最近注目を浴びており、この流れに沿ったものと見ることができそうです。Rubyも影響を与えていそうですけどね。

つまるところ、今ある「(オブジェクト指向)設計手法」が、今後も通用するとは限らず、通用しなくなるときが、いずれは来るだろうということです。それは、主流のプログラミング言語の変化によって、もたらされるものであろうと。そのとき、「Javaでプログラミングするのに、COBOL前提で設計している」といったミスマッチが、また繰り返されるようになりそうですね。いや、「空洞化」が進む結果、そんな馬鹿げたことはもう日本では起きなくなるのかもしれませんけど。

P.S.
ちなみに、Borland Delphiは、Microsoft Visual Basic(VB) の「代替案」として使っています。「巨大なランタイム」、「OS(Windows)との密接な依存性」が、VBの「泣き所」でして。VB的に使えて、かつWin32ネイティブに静的リンクできるDelphi(for Win32)は、状況によっては重宝してますね。逆に、"Delphi for .NET"の存在意義を、いまだ見いだせなかったりしているんですけども。

| | コメント (0)

2006年9月14日 (木)

「エンジニアのやる気は報酬だけじゃ維持できない」?

  • Nさんは規定時間以上の作業をしない。もらっているお金以上の責任は追わない
  • Nさんが作業をしないのでほかの人がNさんの作業を肩代わりすることになってしまった
  • Nさん的には報酬に見合う作業と責任を負っている
  • 顧客企業が求める作業や責任はもっと高いもので、顧客企業の払っている報酬は見合っている
  • 双方の求める成果と報酬は実は見合っていない
    その差分は、多くの仲介企業に消えている
  • 仲介企業も思われているほど割に合っているわけではない

エンジニアのやる気は報酬だけじゃ維持できない - @IT情報マネジメント

「Nさん」なる人は、「2社の仲介を得てこのプロジェクトに参加してきました」とあり、下請け多重構造によるケースですね。

なお、「2次請け以降の『出向技術者』」という記述から、偽装請負ではないか、との指摘もあるようですが。この記事だけでは、そこまでは判断できないかと思います。「客先常駐」であっても、受託企業が勤怠管理、作業指示を行なっている、Nさんに仕事に対する裁量権がある、と言った場合には、偽装請負にはならないようですので(情報サービス業に於ける請負の適正化のための自主点検表 - 東京労働局 )。もっとも、現実を鑑みれば、実態は結構グレーでしょうけどね。

開発初期で上流工程が追い付かないという、短期案件でありがちな状況が発生し、Nさんのレイヤー(詳細設計から実装)まで、あまりスムーズに作業が落ちてきません。そのような状況で、Nさんは心配するわけでも、状況の改善を図るわけでもなく上流工程作業の完了を日々座って待っていました。

 こういった場面でモチベーションが高い技術者は、技術調査の手伝いや、あるいは外部設計の手伝いを行い、プロジェクトに貢献しようとします。さらにモチベーションの高い人はプロセス全体をどうにかしようと考え始めるものです。しかし、Nさんの場合はあくまで「自分の作業」が落ちてくるのを待ちます。

エンジニアのやる気は報酬だけじゃ維持できない - @IT情報マネジメント

うーん、私は少なくとも、「実装者」として来ていただいているのであれば、それ以外の作業をお願いしたりはしないですね。また「自発的」にその作業をしてもらえる、などと期待したりもしません。結局、「実装者」として契約しておいて、それ以上の仕事を求めるのは、フェアではないですし。穿った見方をすれば、最初から報酬を低くするために、そういう契約にしておいた、という風にもとれそうですし。

ただ、プロジェクトの状況というのは、当初想定していたどおりには行かないもので、特に「上流」工程での設計作業が詰まりがちになるのは、よくわかります。しかし、もしNさんに、「上流」工程での作業を手伝ってもらいたいのであれば、最低限、プロジェクト・マネージャーが、Nさんに打診して了解をとりつけるのが「筋」ではないでしょうか。この場合、契約が変更になるわけですからね。

もちろん、Nさんが拒否したとしても、恨む筋合いではなく。こうした事態を想定しなかった、プロジェクト・マネージャーの采配ミスでしょう。

| | コメント (2)

2006年9月13日 (水)

何を使ってブログを書くか?

"Joel on Software"の以下の記事を読みまして。

The combination I found that made me happiest was TextMate in Markdown mode. It was a surprisingly good experience. TextMate is an "emacs inspired" editor for the Mac, with tons of build-in stuff for editing different types of text files that they call Bundles. Markdown is a very simple way to format text, for example, putting *asterisks* around text that you want italicized; it generates nice clean HTML. Even Markdown  source is quite clean and still highly readable, useful if you need to post the same content to Usenet or use it in plain text somewhere.
Joel on Software : Composing in TextMate with MarkDown

「ブログを(楽に)書くのに使えるツール」というものを、みなさん、結構探しているみたいで、海の向こうでも同様なのだな、と思ったのですけど。

かくいう、私もご同類でございまして。

BlogWriteWindows Live Writer などの、いわゆる「ブログエディタ」を試してはみたのですが。何か違うな、と思いました。

結局のところ、欲しいのは、「簡単に」HTMLが作れて、それをブログにそのまま貼れる、といった「仕事」に使えるツールなんですよね。Markdown は、私も考えてはいたんですけども。Perlというのがちょっと引っかかってまして。

それで、ちょっとググッてみたら、 BlueCloth という、MarkdownのRubyポートがあるんですね。時間ができたら、これを試してみようと思っています。応用も利きそうですし。

| | コメント (0)

2006年9月 9日 (土)

「文系SE」、「理系SE」

こんなことを考え始めたのは、文系とか理系といった言葉が頭につく職種というのはSEの他に聞いたことがないな、とふと思ったことがきっかけだった。

文系経営者とは言わないし、理系お笑い芸人とも言わない。
文系警備員とも言わないし、理系コンサルタントとも言わない。
文系総理大臣とも言わないし、理系パン職人とも言わない。

もし数学者で文系だという人がいたらさすがに周りが驚いて文系数学者と呼ぶかもしれないが、これは黒い白馬のようなもので、数学者である時点で世間的には文系ではなく理系と呼ばれるだろう。

小野和俊のブログ:「文系SE」について考える

SEという職業は、他の職業の方がコンピュータを使う上での、お手伝いをする、というような位置づけにあると思います。と、すると、「文系SE」「理系SE」という言葉からは、そのSEが得意とする分野・業界が、文系であるか(会計、金融など)、理系であるか(建設、機械、電気など)という風に、おおざっぱな区別はできそうですけどね。

ただ、「その人の適性」というニュアンスで、文系理系の区別をし、なおかつ、そのレッテルを持って、人を分類してしまうのは、どうかな、と思います。少なくとも、英国数の3科目に代表される、「読み・書き・そろばん」は、文系だろうが理系だろうが、基本的な素養として必要なものだと思いますし。「文系だから数学をやらない」とか、「理系だから国語はやらない」という風には、ならないように思いますが。

それに知識というのは、ある程度、「分野」で分けられていますが、これはどちらかといえば「便宜」にすぎず、実際には、あらゆる知識には何らかの関連があると思います。例えば、「プログラミング言語」について論じたものとしては、言語学、論理学、数学、物理学など、さまざまな視点、「切り口」で論じたものがあるかと思います。また、歴史の視点で論じることもできるでしょうし、文化の視点で論じることもできそうですね。

どうも、私は、「文系」「理系」という「縛り」をかけようとする行為が、不自由に感じられてならないです。窮屈で仕方がないというのか。少なくとも、エンジニアが現実の問題に対する際には、その解決に必要な知識であるなら、どんなものでも利用すべきだと思います。その知識が「文系」に分類されていようが、「理系」に分類されていようが、そんなことには関係なく。

| | コメント (2)

ソフトウエアの設計はどこから来るのか?

ソフトウエアの開発プロジェクトで、複数の人間が「設計」を行い、複数の人間がプログラミングを行ない、それらの作業すべてが同時並行に進行する、という状況にありまして、設計手法を統一する必要性、というものを強く感じました。UML(Unified Modeling Language) が目指すものはこれだったのかな、などと考えていたのですが。

しかし、よくよく考えてみると、UMLは設計のある側面を図で表現しますが、設計そのものではないんですよね。あくまで、一つの表記法にすぎないわけです。色々な図が、ひとつの体系のもとに集まっており、それはそれで、非常に便利なものなのですけれども。私自身、結局、「表記法のカタログ」として使っているわけでして。

それで、私自身、ソフトウエアの設計手法は、どうやって習得したのか、少なくとも、UMLではない、と思いました。結局のところ、これはプログラミングを行なううち、いつの間にかできるようになっていたことでした。

ただ、プログラミングといっても、単に自分でプログラムを書くことによってではなく。おそらく、一番大きなことは、いわゆる「ライブラリ」(API)のインターフェイスを、色々と見て、それがどのような「デザイン」なのか、どういう仕組みで作られているのか、といったことを考えてきたことだと思いました。こういった風に、様々なソフトウエアのインターフェイスを「鑑賞」することで、自分の中にそういったセンスが生じてきたように思います(たいしたセンスではありませんけど)。

例えば、C++言語のStandard Template Library (STL) を見て感動したり、Ruby言語の「組み込みライブラリ」を見て、えらく感心したりするのは、ライブラリ、ひいては、ソフトウエア・インターフェイスの「デザイン」に対する、ある種の「鑑賞眼」のようなものを自分が持っているからだと感じます。

こういった、「良質の作品」を鑑賞し、そしてそれを自身のプログラミングのなかで生かそうとする、この繰り返しによって、私の「ソフトウエア設計手法」が培われてきたのだと、そう考えました。

だとすると、「設計手法を統一する」とは、単に「表記法」を統一することに留まらないわけでして(それも意味はあるとは思いますけど)。「設計センス」のようなものを統一しなければ、根本的にはうまくいきそうにないですよね。でも、こんなことは、一朝一夕に出来ることでもないですね。全員が優れた「センス」を持っていれば、他者の「センス」を理解し、「設計手法を統一すること」が出来そうですが...

---

UML モデリングのエッセンス 第3版 Book UML モデリングのエッセンス 第3版

著者:マーチン・ファウラー
販売元:翔泳社
Amazon.co.jpで詳細を確認する

Martin Fowler氏による、UMLの解説本です。非常にコンパクトでありながら実践的で、UML関連の本は色々読みましたけど、これ以上のものはないように思います。

| | コメント (0)

2006年9月 7日 (木)

ソフトウエアの設計は協業の基礎を作ること

従来、プログラマというのはコンピュータとだけ向かい合ってきた孤独な人々であり、他人との対話を苦手としている。ベック氏は自身の経験も踏まえていう。ただし、ある程度の規模のソフトウェア開発作業は他人との協業を抜きにして行うことができない。すると、プログラマ同士が対話をすることの重要性が自ずと浮かび上がってくる。ソーシャル・スキルとは、つまり人と話をすることである。単純なことだが、プログラマという職種にある人々の多くがこのことをうまくこなすことに困難を感じる傾向にあるとベック氏はいう。

XPと宮本武蔵の勝利への執念、ケント・ベック - @IT

私にとって、ソフトウエアの設計は、プロジェクトの運営と切り離して考えることはできないものですね。

ソフトウエアの設計の本質は、ソフトウエアを複数の部分に分割し、そして、各部分がどのようにやり取りをおこなうのか、を記すことにあると思います。そして、こうして分割を行なうことで、プログラマがそれぞれの部分について、ある程度独立して作業を進められるようになる、それがソフトウエア設計の目的だと考えています。

しかし、ソフトウエアの品質というものは、この分割された部分同士が繋がる箇所によって、決まってしまうように思います。したがって、「ある程度独立して作業を進め」ながらも、各部分を担当するプログラマ同士が、どれだけ密接に、きめ細かに、協業できるか、というところが、品質を決定づける最大のポイントになってくるわけでして。

XPが、ソフトウエア設計において、ソースコードを何よりも重視すべきもの、としているのは、ここから来ているように感じます。ソフトウエア設計は、「全体」から「部分」へ、「概要」から「詳細」へと進めていきますが、最後に到達する「詳細設計」は、ソースコードとなりますから。これが、もっとも正確できめ細かな設計書、というわけです。従って、プログラマ同士は、最終的には、ソースコードによって、コミュニケーションを行なう、ということになります。

ただし、ソースコードでは、あまりに詳細すぎるので、ソースコードの「上」に、その概要となる、「見取り図」となるものが必要だとも考えています。ですので別に、UMLなどを使用した設計書(ドキュメント)を用意するようにしてます。どこまでを設計書で書き、どこからをソースコードとするか、この「境界」を、色々試しつつ、探しているところです。以前は「あらゆる詳細」を設計書に書いたりしてましたが。

おっと、よく誤解されるので先に反論しておこう。先ほどの「コードは重要なドキュメントだ」という原則だけど、「コードが"唯一の"ドキュメントだ」とは言ってない。「XPではコードがドキュメントだ」とよく耳にするけど、 XPのリーダー達がそんなことを言ってるのは聞いたことがないなあ。コードを補完するには、他にもドキュメントが必要なんだ。
Martin Fowler's Bliki in Japanese - コードがドキュメントだ

XPは別にドキュメントを否定している訳ではないそうですけども、ドキュメントについて、あまり語られていないのも事実でして。ドキュメントについては、構造化分析・設計や、オブジェクト指向分析・設計などで、十分語りつくされているから、ということなのかもしれませんね。

| | コメント (0)

2006年9月 6日 (水)

複合キーの必要性はなし?

先ごろ開かれたRailsConfでは、オープニングキーノートにおいてPragDaveが「Railsでは解決できない事項」に焦点をあてていた。その中にはエンタープライジーなことも含まれていた。たとえば、複合キーを持つような、様々なデータ構造を扱うことが必要だというのだ。

これに対するDHHの反応は、この上なく痛烈な拒絶であった。

Martin Fowler's Bliki in Japanese - エンタープライズRails

ここでいう「複合キー」が何を指すのか、はっきりとは書いてありませんが。リレーショナル・データベースのテーブルが持つ、「複数列で構成される主キー」ということにして、複合キーの必要性について、考えてみます。

まず、複合キーが「必要とされる」状況を、3点挙げてみます。

---

1) 階層構造を表現したい

これはすぐに否定できますね。
単一の主キーと外部キーの関連を使って、階層構造は容易に表現できます。

2) パーティショニングを行ないたい

例えば、複数拠点にデータベースを分散配置し、それぞれの拠点で、テーブルにデータを追加したい場合ですね。さらに、拠点で入力したデータを、「中央」に集めるような場合です。

この場合は、「パーティショニング・キー」として、拠点のIDを使用し、さらに、拠点のIDと、拠点で入力の際に付けるIDを、組み合わせて「複合キー」とします。

この場合も、「パーティショニング・キー」=「主キー」である必要はなく、「主キー以外の候補キー」を、「パーティショニング・キー」とすることができます。主キーの値は、データベースごとに独自に作れば良いでしょう。

「パーティショニング・キー」=「主キー」とすることで、単純なデータベース・レプリケーションによって、データベースを分散させることができる、というのはありそうですが。いわゆる”Auto Number”機能をうまく使えば、何とかなりそうな気もします。

3) データベースをわかりやすくしたい

単なる連番で作られるような、人工的なキーよりも、より自然な「複合キー」の方が、理解しやすい、という場合があります。これはおそらく、エンドユーザが、「直接」データベースを見ることを想定してのことですね。

Martin Fowler氏の主張する、 「アプリケーション・データベース」 -データベースを単一のアプリケーションの「ストレージ」として考える-のようなものを想定すれば、こういった「わかりやすさ」は必要なくなるかもしれません。

もっとも、私の経験では、エンドユーザは「人工的なキー(の必要性)」というものを、意外に理解してくれます。あるいは、そんな「技術的なこと」には関心をもたないか、ですね。逆にプログラマの方が、こういったやり方に首をひねることが多いような気がします。おそらく、かって「階層型データベース」を使っていた経験などから、先入観を持ってしまっているのだろう、と推察しますけど。

---

Ruby On Railsでの、「全ての主キーを単一の自動連番とする」というプラクティスは、とてもシンプルで、望ましいやり方だと思いますね。「主キーの選定」は、間違えるとひどいことになりますけど、この方法なら、そういったことは起こりませんし。「主キーの選定」に頭を悩ます時間も節約できます。

私もデータベース設計では、つい複合キーを使いがちではあったのですが。最近は、可能な限り単一キーとする方が良いと考えています。こう考えるようになったのは、Railsの影響が大きいですね。

ちなみに、「T字形ER手法」でも、「主キー(「認知番号」)の複合構成は認めない」という記述があり、同じ考えを持っているようです。

---

 

データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして Book データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして

著者:佐藤 正美
販売元:ソフトリサーチセンター
Amazon.co.jpで詳細を確認する

| | コメント (0)

2006年9月 5日 (火)

「コメント率50%」の謎

先日、とあるSIerの方とお話した時に、上記のような考えで、ソースコード中のコメント率は20%を切るべき、コメントなど書かなくてもわかるようなコードこそ美しい、という話をしたところ、怪訝な顔をされてしまったことがあった。彼にはちゃんと理由を説明して納得してもらったのだけれども、もしコメント率50%と主張している人がいたら、もう一度その必要性を振り返って考えてみてもよいのではないだろうか。

小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい

少なくとも、「いまどきのプログラミング言語」を前提にしますと、「コメント率50%」はほとんど「逐語訳」に近いわけでして。確かに異常な数字だと思いますね。

「コメント率50%」がどこから来たのか、理由をいくつか考えてみました。

---

1) 昔の習慣を引きずっている

「昔の言語」-FORTRANやCOBOL-の場合、そもそも、わかりやすくコードを記述するのが不可能だったりします。変数やプログラムの名前の長さも相当制約されており、多くは"PG010001"といった、「意味不明」の名前が付けられていたりします(今どきの言語を使っているのに、今だにこういった名前を好んで使う人もいますが)。

これらの「暗号」を解読するには、ほぼソース1行あたり1行くらいの割合で、「平文」が必要になります。

2) 「英語だとわかりません」

ソースコードは英語で書かれています。英語というより、「英単語」程度なんですけどね。しかし、これでも「日本語訳が欲しい」という向きがあるようです。

3) 「プログラムが読めません」

ちょっと信じられませんが、SI業界には、「プログラムを読めないプログラマ」は存在するらしいです。コメントで解決する問題ではないと思いますが。

---

コメントを多くつけると、ソースコードがわかりやすくなる、というのは幻想にすぎないと思います。確かに、「的確なコメント」がついていれば、幾分、わかりやすくなることはあるかもしれません。が、「的確なコメント」が出来るなら、「的確なソースコード」を書く能力はあるでしょうし、結局、わかりにくいコードに、わかりにくいコメントをつけて、さらに解りづらくしている、というのが私の印象です。

| | コメント (5)

「隣同士なのになぜ話さないのか」

IPMessengerというツールがあります。広く知られているツールだと思いますが、これをインストールしているエンジニアがいます。たかだか10人くらいが同じ場所で仕事をしているのに、メッセンジャーを利用しています。これって、いったい何なのでしょうか。
...
本当に必要なことなら、メッセンジャーを打ち込んでいる前に、口に出して聞いてみるとか、口頭で説明するなど、考えられるはずです。

メッセンジャーを利用する理由って? - 「走れ!プロジェクトマネージャー!」 [ITmedia オルタナティブ・ブログ]

インスタント・メッセンジャー(IM)に限らず、電子メールや掲示板でも、同じような疑問を持たれることはありますね。「隣同士なのになぜ話さないのか」といったような感じで。私自身も、IMこそ使っていませんが、電子メールで隣の席の人、向かいの席の人などと、質疑応答や、「打ち合わせ」をやるのはよくやります。

なぜなのか、理由はいくつか考えられるのですが、まずひとつには、話すより、紙に書くより、キーボードでタイプする方が早い、というのがあります。これは一種「職業病」のようなもので、日々、朝から晩までプログラミングしていた結果でしょうね。実際、新人やプログラマでない人の前で、プログラミングをやってみせたりすると、その早さに驚くみたいです。おそらく、この時点で「普通」とはかけ離れてますね。そのときまで、自分では「普通」だと思ってましたが。まあ、それが熟練というものなのでしょうけど。

もう一つは、PCの前でずっと作業をしていると、何もかもをPC上でやりたくなってしまう、というのがあります。

PC上で作業をするとき、プログラマはPCと「会話」をしているような状態だと思います。そうすると、そこで話しかけたりするのは、「会話」に割り込むような感じで、気が引けます。また、集中しているとき、「ノッている」ときに、話かけられて作業を中断させられるのは、つらいものがあります。そのとき、考えていたアイデアをこれで忘れてしまったりして。

ところが、メールやIMだと、PCと「会話」しつつ、他の人とも会話ができる訳です。また、集中していて、話をしたくないときには、集中を妨害されることなく、しばらく「保留」にしておける、というのもあります。

単独で作業をする場合、プログラマーは心理学者のいうフロー状態になっていることが理想だ。これは、一つのことに没頭し、ほとんど瞑想状態になることである。
...
一度フロー状態になっても、直接自分に向けられた割り込みや、しつこい騒音で、いとも簡単に元の状態に戻ってしまう。邪魔されて元の状態に戻ると、再びフロー状態に入るのに15分以上かかる。その間、実質的な仕事は何もしていない。

トム・デマルコ、ティモシー・リスター著「ピープルウエア」p.79-80

「全てをPC上で行なう」ということ自体の良し悪し、というのは、別の論点があるとは思います。例えば、「現実に対する感性を失う」といったものですが。少し前、日経新聞でも特集されていましたし、真偽のほどはともかく、この手の議論は以前からありますね。

ただ、そのとおりだとしても、仕事ですから、「ほどほどにしましょう」という訳にもゆかず...
結局、「効率」優先となってしまいますね。
---

ピープルウエア 第2版 − ヤル気こそプロジェクト成功の鍵 Book ピープルウエア 第2版 − ヤル気こそプロジェクト成功の鍵

著者:トム・デマルコ,ティモシー・リスター
販売元:日経BP社
Amazon.co.jpで詳細を確認する

| | コメント (2)

2006年9月 4日 (月)

Rakeを使ってSQL-DDLファイルを作る

Rake(Ruby Make) は、make、antに代表される、「ビルド・ツール」の一つです。「タスク(task)」と、タスク間の依存関係を定義すると、その依存関係に従って、タスクを実行してくれます。もちろん、makeにあるような、「ソース」ファイル、「ターゲット」ファイルのタイムスタンプを比較して、ターゲットがソースより古ければタスクを実行、ということもできます。

Rakeを特徴づけているのは、これが、Rubyの「ライブラリ」-より正確には「言語内DSL」 -となっている点です。この特徴により、Rubyを使用してタスクをプログラミングすることができます。

私は、テーブル仕様書-データーベース・テーブルのレイアウトを書いたドキュメント-から、DDL文(CREATE TABLE文)が入っているファイルを自動生成する、といった仕事に、このソフトウエアを使用しています。これがどんな感じなのか、以下で記述したいと思います。

--

1) テーブル仕様書(Excel)をテキストファイルにする

テーブル仕様書は、Excelワークシートとして作成しています。1シート1テーブルで記述しています。1つのワークシートを、1つのテキストファイルにします。テキストファイルの名前は、テーブル名にして、中身は、ワークシートをそのままコピーしてます(タブ区切りのテキストになりますよね)。一応、この作業を自動化するマクロを書いてます。

2) 上記テキストファイルからDDL文を生成するRubyプログラムを作成する

上記のテキストファイル-定義ファイルと呼んでます-から、DDL文を生成する、Rubyプログラムを作成しています。これは、以下のような感じです。

 

# sqlgen.rb:
# テーブルDDL文の生成。
def generateTableDDL(src_file, target_file,
  schema = '', data_ts = '', index_ts = data_ts,
  pkey_extract = /^#{schema}_/)
  
  ddl = TableDDL.new(
    File.basename(src_file, '.def'),
    schema, pkey_extract)
  
  # DDLオブジェクトを構築。
  ddl.load_from_file(src_file)
  
  # DDL文をファイルに書き出す。
  ddl.generate_sql(target_file, data_ts, index_ts)
end

3) 「DDL文生成タスク」を定義する

定義ファイルから、DDL文ファイルを生成するタスクを定義します。これは、以下のような感じです。

 

# sqlgen-task.rb:
# テーブルスクリプト生成タスクの作成。
def make_sqlgen_table_task(src_dir, dst_dir,
  task_symbol,
  schema = '', data_ts = '', index_ts = data_ts,
  pkey_extract = /^#{schema}_/)
  
  Dir.glob(File.join(src_dir, '*.def')) do |file|
    target = File.join(dst_dir, 
      File.basename(file, '.def') + '.sql')
    file target => [file] do |t|
      generateTableDDL file, target, schema,
        data_ts, index_ts, pkey_extract
    end
    task task_symbol => target
  end
end

ディレクトリ"src_dir"にある定義ファイル"*.def"全てについて、対応するDDL文ファイルをディレクトリ"dst_dir"に作成するタスクです。

4) Rakefileを作成する

"Rakefile"は、Rakeがデフォルトで使用する、タスク定義ファイルです。つまり、Rakefileのあるディレクトリで、

>rake

とコマンドを打つと、このファイルにある「デフォルト・タスク」
(":default")が実行されます。

Rakefileは、以下のような感じです。

 

# Rakefile:
# テーブル作成スクリプト生成タスク。
# tabledef->createtable.sql
make_sqlgen_table_task(
  File.join(SCHEMA_DIR, TABLE_DEF_DIR),
  File.join(SCHEMA_DIR, CREATE_TABLE_DIR),
  :generate_create_table,
  SCHEMA_NAME,
  DATA_TABLESPACE,
  INDEX_TABLESPACE)
# タスク指定なしのrakeコマンドで実行するタスク。
task :default => [:generate_create_table]

--

RDBMSはOracleを使用しています。インデックス、権限付与、シノニムなどのDDL生成も、これで行なっています。こうした、「共通」の部分に加え、さらに、案件特有のものも追加したりしてまして、例えば、テーブルの「管理項目」を入力するトリガーとか、削除データを別テーブルに保存するトリガーなども、生成したりしています。

--

Using the Rake Build Language

Martin Fowler氏による、Rakeの解説です。これだけ詳しい解説があれば、十分だと思います。

| | コメント (0)

2006年9月 1日 (金)

プロジェクト管理ソフトウエア

「一番書類の量と種類が多い生産業は建設だ」といわれる。その書類も、仕様書、質疑応答書だけでなく、図面や工程管理表など多様に渡る。加えて、施主、建築家、コンサルタント、下請け、サプライヤー、インスペクターなど非常に多くの人を巻き込むのがこの仕事。だから、そういった情報を総合的に管理するソフトウェアが必要とされている。
MOZANBLOG: 建設管理用ソフトウェア

私には、建設業のプロジェクト管理に特有の要件、というのは、門外漢ですのでわかりませんが。プロジェクト管理の「一般的な要件」と思われるものを、以下の3点に絞ってみます。

  1. 書類(電子ファイル)を関係者間で共有する。
  2. 上記ファイルに対して、承認・未承認などのステータスを付ける。
  3. 関係者間で、質疑応答などの連絡事項(コメント)をやりとりする。

キーワードは、「ファイル共有」、「コラボレーション」といったものになりそうですかね。一般的には、グループウエアと呼ばれるソフトウエアの機能になりそうです。

ここで、ソフトウエア開発の世界で、よく知られているものを、2つ紹介したいと思います。

--
1) Basecamp

Web上の「サービス」として提供されている、プロジェクト管理ソフトウエアです。ファイル共有のディスクスペース5GBのもの("Our best plan")で、月額149ドル。ファイル共有には、自前のファイルサーバ("use your own SFTP server for storage")も使えるらしいですね。

機能としては、ファイル共有、ファイルのステータス管理、コメントのやりとりの他、ToDoリスト、簡単なスケジュール管理など。かなり機能を絞ったシンプルな構成のようです。

2) Trac+Subversion

こちらは、「ソフトウエア開発のプロジェクト管理」ですけども。
Subversion(SVN)は、ファイルの版管理と、メンバー間共有に使用します。Tracは、ファイルのステータス管理、コメントのやりとり、などに使用します。両ソフトウエアともに、オープンソースで、ライセンス料は不要です。

ただ、ソフトウエアが無料でも、自前でサーバマシン・ネットワーク回線などを用意して、「サービスを構築」となると、結構、費用がかかりそうですね。
--

他には、サイボウズOffice などのグループウエアも、工夫すれば使えるかもしれませんね。そのうち、Googleが無料でグループウエアを提供したりするかも...

最近は建設業界の人を積極的に雇ってこういったプログラムを開発しているようだが、まだ開発の中心はソフトウェアエンジニアだ。だから、彼らは建設のこういった複雑性を無視して、「ライセンス一個○○ドルが業界平均」と値段を勝手に決めてしまう。

特定業界向けのソフトウエアは、マーケットが限定されるせいか、とても高額であることが多いですね。価格低下も起こりにくいですし。そこがソフトウエア・ベンダーの狙いのような気もします。

となると、費用対効果を考えるなら、もっと一般向けのソフトウエアを「工夫して」使うか、あるいは、オープンソースのソフトウエアをベースにして、自分で作るか、といったあたりが「落としどころ」ですかねえ。

| | コメント (2)

« 2006年8月 | トップページ | 2006年10月 »