ただいま修行中...

ソフトウェア開発において、勉強中で悪戦苦闘の日々

アントニオ猪木の言葉

2008-03-31 22:40:47 | ビジネス
先日、社内のプログラムコンテストがあったので、それに参加するために、プレゼンの資料を作成しているときに、毎年動画を使用して、まったく作品とは関係ないことをしています。
今年も何かメッセージがあるものを皆に伝えたいと思い、アントニオ猪木の引退試合の動画を流しました。
その中で、どうしても「人は挑戦することを諦めたときに年を老いていく」ということを伝えたかったので、使用しました。

この言葉は元々、どこかの本に載っていた言葉を引用したようで非常に多くのことをメッセージとして残していると思います。

私は非常にこの言葉が気にいり、まったく関係はありませんが、動画を流しました。
皆にこのことが伝わったかどうかは不明ですが、自分としては非常に満足しています。(単なる自己満足ですが)

ただ、私達も色々とチャレンジすることで、可能性があるということを忘れないようにしていかなければ、自分の成長に繋がらないのだということを改めて、感じました。

Javaでのプログラミング

2008-03-25 23:53:58 | Java
今日、久し振りにJavaコーディングを行いました。
最近、C#でばかりコーディングをしていたので、メニューをつけたり、JLabelを貼り付けたりする作業をしましたが、面倒だなと思います。
一つ一つをVisualに確認できずに、コーディングをするので、確認するのに手間がかなりかかります。

MVCで作成しましょうというのは、やはりJavaでコーディングしてみると本当に良くわかります。
最初に、Javaでコーディングしていると、こういった基本的なことが自然に身についてくると思います。やはり最初に学ぶのはJavaがいいのではないかと思いました。

ちなみに、Eclipseを使用しています。VisualJ#だと割りと簡単に出来ます。


XMLのスキーマ定義について

2008-03-24 22:03:15 | プログラミング
今日、XMLスキーマの定義を初めて行い、色々なサイトを見ていると、私にとっては非常に参考になるサイトがありました。
それは、オブジェクトの広場の「UML による XML 設計ガイド 」です。

UMLで表記されているものを、XMLのスキーマの定義をするためのステップが非常にわかりやすく記述されておりました。DTD による定義・RELAX による定義・XML Schema による定義と別れており、それぞれの場合が書かれているので、じゃあどうしようかとか、こうすればいいんだというようなことが非常に良くわかりました。

今後、XMLのスキーマ定義を初めて行う人は、ぜひ参考にしてください。

春の高校野球が始まった

2008-03-23 23:15:04 | 野球
春の高校野球が始まり、もうすぐ新年度が始まります。
大体、この時期になると、春の選抜野球が行われていて、新年度が始まるなと休日にいつも思っております。
昨年は、我が静岡県勢の常葉菊川が優勝して、全国区の高校として知名度を上げました。今年も、出場するので、何としても優勝をしてもらいたいと思います。

それにしても高校野球を見ていると、外野から帰ってくる選手が全力疾走でベンチに帰ってくると姿を見ていると本当に気持ちが良くどのチームも頑張れと思います。

農業を魅力ある産業に

2008-03-20 23:46:41 | ソフトウェア開発
最近、色々と忙しく、ブログを久し振りに更新。

最近、食品偽装食の安全について色々と考えていて、何か新しいビジネスができないかと考えていたときに、農業に対して、ITというサービスを通じて、魅力ある産業にならないかなと思います。

現在、日本における農家がだんだんと減ってきております。原因は色々とあると思います。いくつか考えてみると、若い人が就業しない・儲からないなどがあります。
やはり農業を儲かり、若い人が就業するようなビジネスモデルを考えなくては、どんどん衰退していく産業になると思います。

これにはやはりITというサービスを通じて、何か役に立つことはないか、企業と個人農家(いわゆるB to C)をつなげる何かをすれば、新しいことができるのではないかと思います。

まだ農家の人がどういったことをしていて、どういった部分が実際に困っているかが私自身わかっていないので、なんともいえませんが、ITを通じて、魅力ある産業になるのではないかと思います。

業務知識よりも仕様分析

2008-03-12 23:10:18 | ソフトウェアテスト
テストケースを作成する上で、業務知識・テストケース作成のための知識やノウハウが必要になってきます。

ただし、テストケース作成を因子漏れが少なくするためには、仕様分析を行い、それに沿って、テストケースの組み合わせを考えます。

まず、テストケースを作成するときに、まずは何を確認しなければならないのかを明確にします。
次に、それらを確認するためにはどういった条件が必要であるかを考えます。

そして、それらの条件が発生する前提条件といったものを考えています。

大体、私がテストケースを作成するときにはこういったことを頭の中で考えています。テストケースが漏れる場合の大きな要因は、仕様分析不足があげられます。これが不足していたり、不十分だったりすると、漏れたり組み合わせがおかしかったりします。

マインドマップを活用したテストが書籍化されていますが、こういった新人と中堅ベテランとの差があるのだというのを伝えたかったのだと思います。

テストケース作成においては、業務知識はある程度必要で、必須なのは仕様分析をする能力ではないかと最近思います。

知識の教育よりも本質はなんであるかが重要

2008-03-10 23:02:30 | ビジネス
昨日、野球のスパイクを買いに、スポーツショップに行ってきました。
その前の日に在庫があることを確認してから、昨日ネットと同じ値段なので、そこで購入しようと決めました。

ところが、ここで店員がレジにしかいなかったので、呼んで、在庫を出してもらうことにしました。ここから在庫を出してもらうのに、約10分程度待たされました。

なかなか見つからないので、ようやく別の店員のところに聞きにいき、ようやく在庫が見つかりました。

次に、P革と呼ばれる、投手が軸足につけるスパイクが削れてしまうので、それを保護するものをつけようと思い、尋ねると、サイズがわからない・在庫があるのかどうかもわからないようで、ここで待たされること約20分間かかりました。

ようやくこちらがイライラしているのが、わかったのか、別の店員がやってきて在庫がないので、取り寄せますとカタログをみて、すぐに注文をしてくれました。

このように同じお店でも店員によって、知識が非常に豊富である人・ない人の差があるのは非常に珍しくないことであると思います。しかし、知識がない場合の対方法が変わってくると思います。
知識がないのなら別のある人に聞くなどして、待たせることの時間の無駄などを考える必要があります。

私たちの業界でもやはり知識や経験値によって左右されることがよくあります。その時の最善策を選択して、顧客にとって選ばれるサービスを提供していることが第一であることを考えなくてはなりません。

テスト駆動開発も万能ではない

2008-03-07 23:02:08 | プログラミング
ソフトウェア開発において銀の弾丸なるものは存在しなくて、テスト駆動開発も銀の弾丸にはなりえません。

なぜなら、テスト駆動開発において、最初にテストコードを記述して、赤くしてからコードを記述します。そもそもテストコードにおいて、テストケース因子が不足している、あるいは例外を想定していないテストコードであると、コードを記述していって緑になっても実際に使用するときにおいて、このパターンが駄目だということがあります。
事実、私もそうなったことがよくあります。

こういった事例からテスト駆動開発を進める上でもテストケースの作成のこつや因子の抽出方法を学ぶ必要があります。

不可解な現象

2008-03-06 23:06:21 | C#
テストコード上では、正常にListのカウントが初期化されるのに、製品にそれを組み込むと、正常なカウント数ではなくなり、エラーになってしまうことがありました。

根本の原因は不明ですが、初期化の際に、List.Clear()するとダメで、List.Remove(オブジェクト)として、一つ一つ削除すると正常に動作するというなんとも不可解な現象が発生しています。

デバックしていても、Clear()をコールして、データを作成しているところのCountを確認しても正常に表示されていて、本当に不可解です。

原因がよくわからないけど、動くからいいやではなく、なぜそういった現象が起きているのか根本の原因を探らないと、後々痛い目を見るので、調査をしなくてはなりません。

本当に不可解な現象だ。

改善のためには根本の原因が何かを考えなくてはならない

2008-03-05 22:20:56 | ソフトウェア開発
何かを改善するときなどに、なぜそれが現状問題となっているのか根本の原因を考えなくてはなりません。
ただ、自分がやりにくいからなどという自分のエゴが主導になって改善が行われても全く役に立たないものができたりすることがよくあります。

改善を行うのは、バグフィックスと同じで、あるバグを修正するのに、表面上だけで修正して、バグがなくなったと喜ぶのではなく、根本の原因を修正しないと後々痛い目にあってしまいます。

そうならないためにも、何が根本の原因であるのか、それを改善することで何がうれしいのか、効果があるのかを常に考えなくてはなりません。

改善を行うことで、重たくなってしまう場合がありますが、これは改善ではなく、改善の反対語(対義語)がわからなかったので、改悪になっているのではないかと思います。