アメブロ

何日か書いてみて気がついたこと。

・FireFoxでコピペができないのが痛い。HTMLタグ表示にすればできるんだけど、面倒。
・ブログを書いている最中に、ThinkPadでカーソルキーの上についているキー（これ何キーなんだろう）を押すと、書いた内容が消える。復旧できない。間違って押しがち。

どっちもなかなか痛いのですが、せっかく書き始めたので使い続けてみます。
はてなのほうが書きやすいなあ。

システムエンジニアとして気になるのは、ここのシステムがOracle-RACを使っていること。
信頼性を高めるという観点では文句ないですが、金融機関のシステムじゃないんだから、もっと安い方法で頑張ってよ。

情報の向き

これはダメだ、と思うPL、PMのありがちな発言。

「この情報はxxには必要ない」

xxにはお好きな言葉をどうぞ。「末端のプログラマ」とか「リーダより下」とか。

情報って他人が絞っちゃ駄目。必要かどうかは本人が判断すべき、と私は思っています。

私も以前は「この管理系の情報はメンバには不要」とか「まだ未確定だから公開しないでおこう」とか思っていました。
もちろん悪意はありませんでした。でも、これは駄目なのです。なぜか、それは

「できるやつほど、プロジェクトの状況を把握して、自分がどう動くべきか考えて行動する」

からです。彼らは情報があればリーダの指示を待たずして自発的に動けます。
そういったメンバから情報を取り上げてしまうのは、リーダとして非常に損です。
指示待ちのメンバと自力で動けるメンバ、どっちが欲しいですか？どっちのメンバを作りたいですか？

リーダとなる人は以下のことをよーく認識しておくべきでしょう。

・メンバが何を必要としているかは、完全にはわからない。
・メンバのほうが自分より優秀な可能性がある（少なくても特定分野においては）。

どうやったら彼らが動けるかを考えるべきで、自分が指示を出してコントロールする、なんて考えるべきではありません。

ということで、私は可能な限りメンバに情報を展開することにしています。
でも、これは次善策で、本当は「情報を展開する」のではなく、「情報を見たい人が見られるようにする」のがベストだと思ってます。

メールではなくRSSリーダのイメージです。送られてくる情報を見るのではなく、自分で欲しい情報を決めて更新情報を受け取る。そうあるべきだと思っています。

情報が多すぎたり、未確定な情報が多いと現場が混乱するのでは、と考える人もいますが、そんなことはありません。

RSSリーダのフィード数が3桁を超える人はざらでしょう。それに比べたらプロジェクトの情報量なんてたいしたことないのです。みんなWeb上の情報を選別してみてますよね。たかが1プロジェクトの情報を選別できないなんてありえません。

また、未確定な情報で混乱するのは、部分的に情報を出すからです。全部情報をオープンにすれば、誰でも同じ程度の理解はできるでしょう。コンテキストさえ共有できれば、それに沿って流れてくる情報を理解する能力は、誰も大して変わらないと思いますよ。

O/Rマッピング

今回のプロジェクトに限った話ではありますが、
Object-Relationalではなく、Object-ResultSetマッピングで十分だと思っています。

データを検索するときには複数のテーブルを結合することが多い。
その場合、検索結果として、各結合対象テーブルに対応したオブジェクトが関連づいているよりも、
取得対象のデータを並べたDTOがひとつあるほうがわかりやすい。
また、テーブルが大きすぎて、全データを取得するのが望ましくないケースもある（テーブル設計が悪い、という気もします。。）

今回のプロジェクトでは、O/Rマッピングフレームワークは自作しました。
ResultSetからDTOへの変換のみをサポートするシンプルなものにしています。
変換に必要な情報はDTOにアノテーションで書きます。SQLはDAOに手書き。