1. 無料アクセス解析

crossroad's Blog

Javaを中心にした技術ネタなど。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

ドキュメント作成...雛形は思考の足かせにもなる

ドキュメント作成について、日ごろ感じていることを書きます。

ドキュメント作成においてつきものなのが「雛形」です。
プロジェクトによっては全く雛形のないところもありますが、
厳格なところでは相当細かく雛形を作っているところもあります。

で、この雛形には一長一短があると思っていて、盲目的に
「雛形にあわせなければ駄目」「雛形にあわせておけば大丈夫」
と言うのはよろしくない
と思います。

と言うのは、雛形を意識しすぎることで「雛形にあわせてドキュメント
を作ること」が目的になってしまう
と思うからです。
当然、ドキュメント作成には問題を整理したり、明確化したり、
他の人とのコミュニケーション手段だったりと、「本来の目的」
があるはずなのですが、それを見失って雛形通りのドキュメントが
できれば安心してしまう
のです。

ユーザも含め、何か形になるもの...ドキュメントがあると内容は
ともかくとして安心してしまう
のが落とし穴です。
得てして、こういうドキュメントの内容は肝心な部分が抜け落ちていたり、
単に「それっぽいことが書いてあるだけ」になりがちで、後工程で
全く使えなかったりします。
そうなると、意味の無いものを作るのに労力を割いていたことになってしまいます。

そこで、ですが個人的には雛形は優先度を下げてしまって、フリーフォーマット
でドキュメントを作るのが良い
と思っています。
自分の頭の中にある情報・イメージをそのままドキュメント化します。
ExcelでもWordでもPowerPointでも、FreeMindでも、ただのメモでも
何でも良いので、ドキュメントの「本来の目的」にあわせて表現・理解しやすい
と思う形でドキュメント化
します。
当然、雛形がベターな表現方法であればそれを使います。
雛形が使いにくければ使いません。(使わざるを得ないことも多いですが)

特にテスト項目表なんかはよくある表形式よりも、マトリクスにして
テストの組み合わせパターンを整理したり、図示したほうがテストの主旨や
テスト項目の考え方がよくまとまります。

ドキュメント化してみてはじめて、テスト項目の漏れ抜けに気づくこともあります。
これはドキュメントが理解しやすい形で表現されていればこそ、だと思います。
ドキュメントの内容を直感的に理解できない、頭の中のイメージと直結しないと、
脳内でドキュメントと頭の中のイメージをマッピングするオーバーヘッドが
かかってしまい、問題に思考を集中できません


綺麗な見た目より、その内容こそがドキュメントの価値だと思います。
当たり前ですが、ただ形式的にドキュメント作成していると、案外そのことを
忘れていることが良くありますので要注意ですね。

スポンサーサイト

テーマ:プログラミング - ジャンル:コンピュータ

  1. 2006/10/17(火) 01:17:03|
  2. ソフトウェア開発 一般
  3. | トラックバック:0
  4. | コメント:0

ソフトウェア開発における人的リソースの使い方

プロジェクト管理において、人的リソースの使い方は大きく二通りあると思います。

1.問題・役割を分担し、各人が並列で動く。
2.1つの問題に対して全員で直列に取り組む。

一般的には、1.が多いと思います。
作業を分担して並列に動いた方が、効率が良いからです。

しかし、アジャイル開発においては2.の指向が強いようです。
例えば、XP(eXtreme Programming)では、個々のタスクこそ担当者
に割り当てますが、基本的には問題を全員でシェアし、成果物である
ソースコードも全員で共有します。
コード共有所有と言うプラクティスが定められている程です。

で、実際のソフトウェア開発にどちらが適しているか。。。
プロジェクトの規模や政治的事情、チーム体制、要員のスキルレベル等の
要因によって一概には言えないと思いますが、個人的には2.のほうが
ソフトウェア開発には適している
と思います。

広く言われていることですが、ソフトウェア開発は高度な知的作業であり、
単純化された作業とは違う
からです。
単純作業であれば並列化することで効率が上がりますが、知的作業では
いかに「考えるか」が重要でその為には分担するより集中的に取り組む方が
より良い解を得られやすい
と思うからです。

1.のように並列化することによるデメリットは、

a.技術者のスキルレベルにバラツキがあるので、成果物の品質も一定しない。
 特に、今のように外注要員に依存したプロジェクトでは、組織的に技術スキルを
 共有することが困難で、より属人的な...つまり、個々の技術者のスキルに
 大きく依存している...ためより顕著な問題です。

b.プロジェクトのスピードが落ちる。
 1つの問題に全員で取り組むと効率が悪そうだが、実は並列化して
 技術者のスキルレベルに依存するほうが効率が悪い
事が多い。

 同じエラーに何人もひっかかって時間を浪費したり、1人で行き詰ってしまったり、
 開発したプログラムの品質が悪すぎて破棄せざるを得なくなったりするからです。

c.より良いか良い決方法が見つからない。
 人間、1人で考えれることはたかが知れています。3人寄れば...で
 複数人で問題に取り組むことでより良い解決方法が見つかります

d.自分さえ良ければ良いと言う発想になりがち。
分担しているので、自分の担当分さえ上手く行けばそれでよく、
 プロジェクト全体を見ようという動機が軽薄になる


 結果、互いに問題を共有したり、指摘しあったり、改善しようとしたり
 と言う活動が行なわれないので、プロジェクト全体の品質が下がる。

e.自分の担当外の部分には口出ししにくい雰囲気になりやすく、
 他の人の担当部分について意見しにくくなる

 これも、改善の活動が行なわれなくなるので、全体の品質低下を招く。

f.共通化・リファクタリングが困難になる。
 並列で動いてしまうので、共通部品化しても「今更変更できない」となったり、
 リファクタリングを拒まれたりする。

 結局、誰もが自分の担当分の手戻りを恐れているわけですが、
 これは「自分の担当」と言う意識があるからこそです。
 プロジェクトの成果物はチーム全体のものであり、プロジェクトの
 問題も全員で取り組むべきだ、と言う意識があればこのような
 ネガティブな考えは発生しないはずです。

g.スキルトランスファーできない。ある問題に対しての解・ノウハウを
 持っている人が限定されてしまうので、その人がプロジェクトを離脱
 すると、とたんに対応できなくなる。

h.ドキュメント駆動にならざるを得ない。
 暗黙値の共有がうまくできないので、いちいち形式値化=ドキュメント化
 せざるを得なくなり、ドキュメント化のオーバーヘッドがかかる
 言葉で話せば数分で済むことがドキュメント化とそのメンテナンス
 によって数十分、数時間を費やしてしまう。

などなど。。。が考えられます。


効率化を追求するあまり、並列化することが多いですが、このような
デメリットがあることも認識する必要があると思います。

テーマ:プログラミング - ジャンル:コンピュータ

  1. 2006/10/15(日) 01:55:21|
  2. ソフトウェア開発 一般
  3. | トラックバック:0
  4. | コメント:0

Mavenトラブル事例-site+jCoverage+ジェネリクスでユニットテストエラー

久しぶりにMavenトラブル事例。

JavaSE5.0のジェネリクスを使って実装した場合、
Maven1.xのsiteゴールを実行すると、JUnitテストでエラーが発生します。

java.lang.ClassFormatError: LVTT entry for 'hoge' in class file hoge/Hoge does not match any LVT entry

原因は若干複雑で、jCoverageとBCELが関係しているようです。
jCoverageは内部的にBCELを使用しているようなのですが、
BCELがジェネリクスに対応していないようなのです。
(ですので、project.xmlでjCoverageレポートを指定していなければ問題は発生しません)

で、その影響(クラスローディングの関係)を受けて、JUnitテストで
上記エラーが発生するようです。


対応としては、プロパティ
 maven.junit.fork = yes
 maven.junit.jvmargs = -noverify

を指定すると、クラスファイルの検証が無効になり、エラーを回避できます。
(project.propertiesに書いておくと良いと思います)


テーマ:JAVA - ジャンル:コンピュータ

  1. 2006/10/13(金) 23:06:34|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:0

ワールドトレードセンター

映画「ワールドトレードセンター」を観て来ました。

実話を元にした映画だそうで、あの時TVで遠巻きに観ていたニュースの
現場の様子が少しはわかった感じがします。

主人公が生き埋めになり、生と死の狭間の状況に陥っている様は
観ていて苦しみが伝わるようでした。
体が動かない、漆黒の闇、呼吸もままならない、重症を負っている、
自分なら発狂してるだろうな、とか思いながら観ていました。

当然と言うか、アメリカの映画なので同時多発テロの悲惨さを訴えた
内容でしたが。。。大きな視点で見ればアメリカだけが悲劇を負っているわけではないわけで。

その後のイラク戦争をはじめ、アラブ諸国にも悲劇は起こっているんですよね。

テロはもちろん許されない、ただそれを大義名分に戦争を起こすのは
やはりその悲劇を拡散させているだけなんじゃないかと改めて思いました。

しかし、そうは思っても自分に何ができるか。。。何もできないんですよね。
戦争をはじめてしまう一部の権力者、それをどうすれば止めれるのか。
術を思いつきません。

ただただ、世界中で犠牲になった人の冥福を祈るのみです。。。

そして、今の自分がいかに平和で幸せな環境に生きているか。
それに感謝せずにいられません。

テーマ:映画感想 - ジャンル:映画

  1. 2006/10/09(月) 00:24:15|
  2. 日記
  3. | トラックバック:0
  4. | コメント:0

デジタル時代のモノ作り~ビジネスとは

今、ワールドビジネスサテライトで、
「デジタル時代の物作り」と銘打った特集をやってました。
(チラッとしか見てませんが)

そこで、ソニーの人が
「アナログ時代と比較して何倍もの技術者を投入しないといけない。
 (それだけの技術者を使うのは)マネージメントが難しく、
 どこの会社も苦労してるんじゃないか」

と言ったことを言ってました。
# ソニーは電池の不具合や、PS3の発売延期、その他製品も初期不良が多いことで有名ですね。
# ちなみに私はSONY製品はほとんど買いません。

確かに、マネジメントに苦労しているのは、多くの会社がそうだと思います。
しかし、デジタル時代だから技術者が必要、と言うのは違うと思いました。

この手の報道番組では、いかにもそれらしい理由をつけてるんでしょうが、
実際は今の日本のモノ作りはもっとドロドロした世界だと思います。
要は「金」ですね。
それも「いかに人件費をけちって金を儲けるか」が全てと言っても過言では無いと思います。

人件費を削減するため、多くの会社はアウトソーシングや派遣技術者を使います。
これらの技術者は一時的にプロジェクトに関わるだけなので、そもそもプロジェクトに
愛着もなく、努力する動機に乏しいです。
これはすなわち、仕事の質の低下を意味します。

さらに悪いのは、孫請けの横行です。
メーカがA社にアウトソースすると、A社はB社に、B社はC社にと
次々とアウトソーシングします。
結果、メーカは1人月100万円の技術者を雇ったつもりでも、実際は
1人月40万の新人レベルの技術者だったりする
わけです。

こう言った技術者に対して、A社なり、B社なり、C社なりが責任を
持つのであれば良いのですが実際は、それも技術者任せです。
つまり、安い技術者を雇い、その技術者が求められる成果を出せなくても
その会社は大した保障はしません。
せいぜい技術者に「がんばってくれ」と言うだけです。

技術者の側は、安い報酬で過酷な仕事を要求されるのでモチベーションは下がります。

結果、まともなモノ作りなどできないんです。

今、日本のモノ作りは危機的な状況にあると思います。
安易なアウトソーシングに加え、若者の労働意欲の低下もあるので、質の高い仕事の
できる人がどんどん減っていると思います。

人件費のマージンでしか利益をあげることができない、そんなビジネスモデルでは
駄目なんじゃないか、と一技術者として常々思います。

「金を儲けるのがビジネスだ」という方もいらっしゃるかもしれません。
もちろん、利益をあげるのは企業の存在理由のひとつではありますが、
やることをやらずして、価値を生み出すことをやらずに、安易に金儲けに走る。
それを「ビジネス」なんて聞こえの良い言葉で包むのに違和感を覚えます。

「ビジネス」がなんだか胡散臭い言葉に聞こえてしょうがない今日この頃です。

  1. 2006/10/07(土) 00:21:51|
  2. 日記
  3. | トラックバック:0
  4. | コメント:0

Tomcatへの再配備で、Log4JでNullPointerExceptionが発生

Log4Jを使ったログ出力をするWebアプリケーションで、
以下のような例外が発生しました。


java.lang.NullPointerException
at org.apache.log4j.spi.LocationInfo.init(LocationInfo.java:104)
at org.apache.log4j.spi.LoggingEvent.getLocationInformation(LoggingEvent.java:191)


発生するのは、Tomcatを停止させずにWebアプリケーションを再配備した後です。
Tomcatを再起動すれば例外は発生しなくなります。

Log4JのLocationInfoのソースコードを見ると、内部で使用している
StringWriter型のstaticフィールドがnullになっているのが原因のようでした。
ただ、なぜnullになるのかまでは良くわかりません。

対応としては、Webモジュールの/WEB-INF/libに入れていたLog4JのJarファイルを、
TOMCAT_HOME/common/lib下に配置する
ことで例外が起こらなくなりました。

テーマ:JAVA - ジャンル:コンピュータ

  1. 2006/10/06(金) 23:12:38|
  2. ソフトウェア開発 Java
  3. | トラックバック:0
  4. | コメント:0

プロフィール

crossroad

Author:crossroad
関西在住。男。
フリーランスのソフトウェアエンジニア。
エレキベース(Rock&Roll)とお酒が好物でございます。

カテゴリー

タグリスト

Java F1 フリーランス ベーシスト HARRY TheStreetSliders iPhone FX お酒 Seasar Maven eclipse Wicket マイホーム 野球 プロジェクトファシリテーション Rails Ruby UML お店 ソフトウェア Tomcat S2Flex2 jsf Teeda Eclipse タグライブラリ ajax タスク europa mylyn trac 

ブログ内検索

最近の記事

最近のコメント

最近のトラックバック

カレンダー

09 | 2006/10 | 11
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -

月別アーカイブ

全ての記事を表示する

全ての記事を表示する

Twitter


RSSフィード

リンク

このブログをリンクに追加する

アクセスカウンタ

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。