Seasar ってとっつきにくい・・

JavaのWebシステムをチューニングしたい、とのことで、解析を依頼された。

読み始めると「？」。Java っぽいけど Java じゃない。しかし何とかかんとか解読していく。そのうち、import している情報を見て「あ、これが Seasar って奴か」と気がついた。

 

読み解いたことの確認と補足のためサイトを見たが、読み解いた内容でほぼOKであった。しかし、結構骨が折れた・・。Seaser 初心者の一日目は結構読めた方だとは思うが、数日はすんなりは読めないだろう。ソースコードがシンプルな分、前提知識を多く必要とするようで、初学者にはとっつきにくい感がある。

ただ、その前提知識が頭に入れば非常に読みやすいのではないか、とは思う。

 

なお、該当部分は処理はWebシステムから起動されるバッチ処理でジョブをコントロールする。こういうのに Seaser の適用が適切なのかどうなのか、正直分からないが、ORマッパーと呼ばれる S2Dao のデータベース処理を見た限りでは「ちょっと使いにくいかも」というところが正直なところであった。

まあ、まだ使い勝手の評価ができる段階ではないことは添えておく。

 

【追記】

→これ、Seaserというよりも DI とか AOP　だ。

漢字は正しく

新人の頃、コンピュータの書籍を見ていて「？」と思ったことがある。「プログラム内臓」という表記がされていたのだ。意味的には「内蔵」のはずである。しかし、「この業界ではコンピュータ内の装置をそれぞれ臓器と見立てて、という表現をしているのだろうか？」と真剣に悩んだことがある。それほど同様の間違い、むしろ正しい方が少数派だった。

 

さて、昨今気になるのは「メモリのかいほう」だ。介抱、快方、開法、解法、開放、解放、海宝・・。まあ、だいたい二種類に集約される。開放と解放だ。どちらも見かけるが、「開け放つ」と「解き放つ」はそれぞれ英語にすると、open と release で、明らかに後者である。

 

特にHPやブログは初学者、場合によっては外国人が見ていることがある。私のブログで約3%くらいが海外からのアクセスである。そういう人が混乱しないためにも、コミュニケーションの手段としての言葉、特にちょっとした漢字のミスは極力ないように心がけたいものだ。

ほとんど自戒の念であるが・・。

 

-----

そんなこと書きながら間違ってましたので訂正しました。指摘して下さった方、ありがとうございます。

スコープ　概念　１：範囲は曖昧にしない

【スコープ　概念　１】

何かコトを起こす場合、目的があれば「何をどこまでやれるのか」はだいたい決まります。ただ、先例のないプロジェクトでは、いくら専門家が集まっても考慮漏れは発生するもの。プロジェクトが進行するにつれ最初に想定していなかった考慮点は発生してくるでしょう。

そのプロセスも含め、範囲をきちんと決めるのがこの知識エリアです。


プロジェクトスコープマネジメントでは

5.1　スコープ計画
5.2　スコープ定義
5.3　WBS作成
5.4　スコープ検証
5.5　スコープ・コントロール

が定義されています。


5.1　スコープ計画　（計画）
　プロジェクトでの作業を大まかに決めます。プロジェクトの重要度によって、今まで経験したものを元に簡単にすませるのか、時間を掛けて行うのかは変わってきます。

5.2　スコープ定義　（計画）
　スコープ計画と他の情報を基に、詳細化します。また、主な成果物も決めます。

5.3　WBS作成　（計画）
　WBSを作成します。WBSにはワークパッケージのレベルまでブレイクダウンして記載します。

　具体的にどこまでブレイクダウンすればいいのか、というだけでもかなりの説明がなされている。実際に使って慣れるのが一番であるし、経験上プロジェクトの規模によって、また立場によってレベル感の違うな、ということはあるのだが、「その作業を分解できないレベル」とされている。

　これも経験談だが、WBSに記載するのは成果物があるものだけではなく、他部署との同期をとるためのマイルストーンの埋め込みなども行った方が運営上無理が発生しにくい。


5.4　スコープ検証　（監視・コントロール）
　完了した作業の承認を受けます。


5.5　スコープ・コントロール　（監視・コントロール）
　変更があった場合、スコープの修正を行います。

 

　経験上ですが、スコープがあとあとぶれる要因は「元の要件定義が甘い」「顧客が積極的に関与していない」ということが多いです。スコープが変わると当然費用も変わってくる場合が多いのですが、ITの孫請けより下の請けだと変更でも費用が取れず、泣き寝入りしているところもたくさんありました。


　余談ですが、IT産業が成熟するためにはこのプロセスが改善されることも一つの要素だと私は考えています。