« 2005年6月 | トップページ | 2005年8月 »

2005年7月

2005/07/26

Think small

 はぶさんの日記を読んで「think small」「分割統治」の考え方は、プログラミングだけでなく、決断のようなマネジメントの側面でも使える事実に改めて気付かされた。

 また、別のBlogでは、考える総量100kgl(kgl=考える)をチームごとに分割したとしても、どこかにしわ寄せされてしまい、何も状況が変わっていない経験談が載せられている。

 物事を小さく分割して、難しさを落としていくこと。
 決断する勇気を小さく分割して、すぐに決断できる内容に落とすこと。
 小さくすれば、イテレーションを短くできるから、失敗したとしてもすぐに取り返せる。
 マネジメントに携わるポジションにいると、役割分担できるようにするために仕事を分割していく。
 「Think small」は一つの技術。

| | コメント (0) | トラックバック (0)

2005/07/24

XPファシリテーションによる信頼形成

 明日から開かれるソフトウェア・プロセス・エンジニアリング・シンポジウム2005(SPES2005)で「XPファシリテーションによる信頼形成 ~ 実践!計画ゲームによる顧客と開発者との信頼づくり ~」が催される。
 関西のXP関係者が殆ど集合して、実演するとのこと、内容が興味津々。
 すごく行きたいーが、当然仕事で無理。

 仕方ないので、本を2冊購入してきた。

ファシリテーション入門 日経文庫

コーチング・マネジメント―人と組織のハイパフォーマンスをつくる

 2冊とも、軽く読める本だが、書評が良くて以前から気になっていた本。
 マネジメントに関するハウツー本は何となく訝しくて敬遠気味だったが、アジャイル関係を漁っているうちに、一つの知識体系としてまとめられている気がする。知識があるだけでも意外に役立つ。
 チームを回す技術は奥が深い。

| | コメント (2) | トラックバック (0)

2005/07/16

再帰SQL part2

yuuntim さん、半年前に書いた記事「再帰SQL」のコメントありがとうございます。
最近はOOAからどんどん離れて業務屋さんになった経験も踏まえて、もう一度考えを整理してみます。

【1】再帰SQLはツリー構造の情報を検索する時に使える

あの時は再帰SQLの意味や使い道が全く分かっていなかった。しかし、今の仕事のおかげで、再帰SQLは重要であり、色んな所で使えることを経験した。
再帰SQLが使われる具体例は二つすぐに思いつく。
一つは、個人の組織情報が階層構造になっている場合、もう一つは、商品がカテゴライズされていてカテゴリ情報が階層構造になっている場合だ。
組織構造の例は、アナパタのパーティそのもので、再帰構造になっている。
どちらにせよ、組織マスタとかカテゴリマスタのテーブルに階層構造の情報がツリー構造で保持されている時に有効になる。
但し、当然のことながら階層が深いほど、再帰SQLのレスポンスは悪くなる。

【2】再帰SQLはOracleでは普通に使われている
Oracleでは、CONNECT BY 句を使えばよい。
例えば、下記の例は良く出てくる。

--job='PRESIDENT' が、親子関係の頂点で、親子関係は empno=mgr が条件である従業員を検索する
select empno,level,lpad('-', 2*(LEVEL-1),'-') || ename ename ,mgr,job from emp
connect by prior empno = mgr start with job='PRESIDENT

余談だが、connect by 句はSQL本をいくら漁ってもなかなか出てこなくて、調査に随分苦労した。ツリー構造のデータなんて、生産管理でも良く出てくるのに、何故解説がないのだろう?
実はSQL ServerやDB2では上記SQLは使えないし、再帰SQLも最近までサポートされていない。Oracleだけver8以前からもサポートされていたらしい。さすがOracle。

【3】「生産管理・原価管理システムのためのデータモデリング」再考
今頃になって読み返して、まだ理解できていない点はありますが、少しずつ腑に落ちつつある。

「部品構成のループのチェック」についてすぐに思い浮かぶのは、ツリーを深く下がって検索する時に最下層がどこまでなのかを既に把握できていれば、計算しやすくなるはずだろうということ。
だから、構成品の削除・更新があるたびにLLCを再計算しているわけだ。これは確かに重い処理だと思う。

「所要量計算(あるいは原価計算)を行う品目の順序を決定する」処理の解説、yuuntim さんありがとうございます。
親品目の所要量の総計が計算できた後に、下層の品目の計算を行うために、LLCの昇順で降りていくわけですね。なるほど。この計算はすごく重たそう。
MRP所要量計算のアクションダイアグラム(P176参照)はPL/SQLで書いたとしたら、一時変数のカーソルでループ処理するために、すごく読みにくいだろうなあと勝手に想像します。

この本はまだ奥が深いです。また読み直します。

最近はクラス図よりもER図を片手に仕事する時が多い。仕様を理解できない時、ER図からインスタンスごとのリレーションを結んで、データがどのようにつながっているかを自然に書き散らすようになった。その感覚はオブジェクト図を書いているのと同じ。
データモデリングだろうがオブジェクト指向モデリングだろうが、やっていること、考えるやり方は結局似ている気がする。

| | コメント (0) | トラックバック (0)

« 2005年6月 | トップページ | 2005年8月 »