のんちゃん。あーい。
by tsuyodrive
S M T W T F S
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
カテゴリ
全体
中小企業診断士
ネットワークスペシャリスト
情報処理技術者試験
デザインパターン
ラリー
仕事
自転車
会社
バスケ
カート
未分類
以前の記事
2007年 05月
2007年 03月
2007年 02月
2007年 01月
2006年 06月
2006年 05月
2006年 04月
2006年 02月
2006年 01月
2005年 10月
2005年 09月
2005年 08月
2005年 07月
2005年 06月
2005年 05月
2005年 04月
2005年 03月
2005年 02月
2005年 01月
2004年 12月
2004年 11月
2004年 10月
2004年 09月
フォロー中のブログ
ライフログ
検索
その他のジャンル
ファン
記事ランキング
ブログジャンル
画像一覧


<   2004年 11月 ( 9 )   > この月の画像一覧

オブジェクト指向で考える。

3年前から本格的にオブジェクト指向の世界で仕事してきました。
私の仕事はCATIA V5のカスタマイズであり、基本的にVC++とCAAとCOMと呼ばれるコンポーネント技術(?)を使っての開発。
もうバリバリオブジェクト指向なのです。

ところが。

できあがった設計書や、ソースについてよーく考えてみました。確かに設計書ではクラス設計書、フィーチャ属性表、インターフェース仕様書などを作っています。ソースもコメントは//だし、オブジェクトをnewしたり、フィーチャからQueryInterfaceしたりしています。確かにオブジェクト指向が理解できないと書けない仕様書・ソースです。
しかし、これらがオブジェクト指向を使って開発しているものとはもはや言い難い。そう思えるようになってしまいました。
いや、言い方が悪いのかもしれません。
オブジェクト指向における技術は読めるし、理解できる。しかし、徹底的に活用しているかというと、必ずしもそうではないのです。
端的な例で言うと、一番初めに6つのコマンド(機能)ができて、それらを元にさらに次のリリース、リリースと行くに従いコマンド数が増えていきました。
あるとき、CATIAのバージョンUPに伴いいくつか新しい付加機能を追加する必要があり、操作性の一貫性を保つためそれらを開発したコマンド全てに追加しました。
またあるとき、内部ライブラリを一新するため、それまでのGUIは踏襲しながら新しい機能へ挿げ替えを行ったため、同じ顔つきながら別のコマンドが増えていきました。
コマンドの数は新旧合わせると約70個、その7割は似て非なるコードのコピーで作られています。
理由は「同じような機能を開発するから」ただそれだけ。

オブジェクト指向を理解できる人たちが携わって、なぜ似て非なるコードが大量生産されてしまっているのでしょうか?これは非常に大問題です。
なぜなら、これから新しい追加機能を付加することが不可欠となったとき、全てのコマンドに対して(少なくとも新しいコマンドに対して)、まったく同じコードをそれぞれにコピーして、それぞれの単体テストを行い、結合テストを行う必要がでてきます。もしくは、共通の機能に不具合があり早急に修正が必要とされる場合、似て非なるコードをコピーしているため全てのコマンドに対して(少なくとも新しいコマンドに対して)、同じ修正を加える必要が出てきてしまうのです。

オブジェクト指向って、何でしたっけ。
継承って、どういうときに使うのでしょうか。
この問題は実はずーっと見てみぬフリをしてきましたが、開発が先細りになるにつれ人が減ってきたのに、くだらないメンテナンス工事に無駄な工数を使い、通常の開発を圧迫するようになってきているのは判っていました。
よくよく考えたら、種をまいているのは自分たちではないですか。

結局、新しい(オブジェクト指向は決して新しい技術ではないですが)ものを理解しても、それまでの慣習や、あまり面倒を抱え込みたくないという意識から、目先に簡単に移るやり方へと流れてしまう傾向があるようです。本来、このような構造プログラミングからオブジェクト指向プログラミングへの移行は大きなパラダイムシフトを伴うものですが、
開発する人が何が変わったかを本質的に捉え、どう生かさなければいけないのかをじっくり考えてから取り組まないと、結局何も変わらないということなのでしょう。

このような問題を解く鍵は、「オブジェクト指向を使うと何がうれしいのか?」を良く考えることです。また、日頃抱えている問題や課題をどう解決するべきか?それを良く考えることです。
今この二つをつき合わせて思いつくのは次のような事柄です。
『オブジェクト指向の特に「継承」を上手に利用すると、少ないコードで、属性をちょっと変えるだけで多くのインスタンスを作り出すことができる。これはすなわち、共通のGUIや機能を持っているコマンド群には全て適用できる話である。コード量が減ればその後のテスト、工事、改善、不具合対応のすべてにおいて費用削減が可能となるはずである。』

長い文章ですみません。
しかし、今後自分のやるべきことが何かはっきりとしてきました。
オブジェクト指向をもっともっと徹底活用することで開発費用を下げ、生産性を向上させ生産余剰能力を増やし、他社に真似のできない開発プロセスを開発すること。です。
[PR]
by tsuyodrive | 2004-11-30 03:16 | 仕事

土日。

先週は土曜・日曜とどちらも夕方練習があり、軽く筋肉痛がやってきました。

特に日曜日は男子7人女子8人と集まり、大体別々になって練習をやりました。女子は6号とボールサイズの違いもあり、できれば練習も別にしたほうが都合が良い今日この頃です。
しかし2対2まではまだよかったけど、3対3になるともう大変。
集中力を切らさないように間にフリースローをまぜながら4セット。
いつもは2セットなので目一杯練習してへとへとです。

いつも通りorzパスミスを何回かやってしまったので、相手を良く見るくせをつけないといけません。ただ、日曜日はよくシュートを打って行ってこれがまたよく決まったので少し状態がよくなってきたような感じです。
ボールハンドリングの練習を15分以上こなしてみたのが良かったのかも。今後もまずボールに15分触り、それからシューティングをしようと思います。

メンバーはうまい人たちばっかりだったので、自分と組むときとうまい人同士で組むときとでオフェンスの幅というか流れの良し悪しが歴然としたのがorz
でもそんなに違うわけじゃないので、何が違うのかをもうちょっと研究しないといけないです。
[PR]
by tsuyodrive | 2004-11-30 02:52 | バスケ

財務会計スタート。

財務・会計の講義受講をようやくスタートした。
しかし、Web講義受講開始を3週間分ずらした影響で、企業経営の基礎講義後半と、事例演習その1をスキップした状態。
そして財務・会計もすでに3コマ分遅れてしまっている。
もっとペースアップしないと間に合わんですorz

財務会計、覚えることは多そうだけど、これの前に視聴した
「簿記マスター」の内容がよく、簿記初心者の私でもおおよそ理解できた。
わかると楽しいので、この流れを絶やさないようにやっていきたい。

「簿記マスター」おすすめです。
[PR]
by tsuyodrive | 2004-11-24 12:48 | 中小企業診断士

2004年WRCが幕を閉じた。

今日オーストラリアラリーをTVで見た。
サインツが最後の華を飾れず、レッキ中にリタイヤ(っていうのかな)してしまった。
あちゃー。
他のワークスドライバーも次々とリタイヤしてしまった。
つまらない結末。
盛り上がりの欠けるラリーとなってしまった。

福井敏雄さんも番組内でおっしゃってたが、FIAのやり方がどうなの、って思う。
ワークス2人まで、とかタイヤレギュレーションとか、ポイント制の変更とか。
F1でもそうだけど、レギュレーションを頻繁に変更してやりたい放題。
それもなんかつまらない方向へ変更するのが好きなのか、現にそうなっている。

ワークス8台はやっぱつまらないですよ。
ドライバーも育たないし。もっと多くのドライバーがエントリーしないとねぇ。
30台くらいワークスで出たほうがおもしろいと思うんだけどな。
もちろん、コスト削減、話はわかるけどさ、エンターテイメントなんだから興味をそぐような真似してたら悪循環にはまるだけのような気がする。
たとえばスバルやスズキなんかはラリージャパン特需とかあるだろうし、
べつにコスト削減策なんて打つ必要はないと思う。むしろ積極的に参加し、青と黄色の強烈なインパクトをカスタマーに与えることができれば、利益に繋がるじゃないですか。

そもそも、コスト削減策をFIAが提案しなくても良いと思うのだが。
内政干渉というか、よけいなおせっかいなんじゃないのかな・・・。

で、来年はプジョーとシトロエンがそろって撤退。
となるとフォードとスバルだけ?になるのかな。三菱はどうなるのか。
これでWRCといえるのか。
Works Reduce Cost の略になったりして(一応オチですorz)
[PR]
by tsuyodrive | 2004-11-22 02:59 | ラリー

新しい開発手法を求めて。

TOC(制約条件の理論)を、「ザ・ゴール」シリーズ(全部で4つ)を2回ほど読んで学んだ。
思考プロセスもちょっとずつ使うようにしている。
まだ飛躍的な効果を生むには至っていないが、まだそんなに使ってないので当たり前。

今後、新しい開発プロセスを開発できれば、自社の利益拡大に繋がると思っているのだが、
それをTOCを利用してやってみたい。
もちろん、最近のトレンド(?)であるXPなどのアジャイル手法も参考程度に読んでいるが、
小規模開発にしか使えないのだとしたら意味あるのかないのか分からない。
少なくとも現在の手法からの切り替えで発生しうる問題を解決しなければ望めないだろう。

どちらかというと、日本的なスタイルをちょっとずつ変化させるほうが納得しやすい気もする。
一気にごそっと変えると不安が増幅して不平・不満が増大し、失敗する可能性が大きくなる気がする。
そして、今のスタイルにTOCを適用しても十分効果が得られると思う。

ただ、思考プロセスを会社で工数を使ってやっていくのはまずだめだろう。
認知度が低すぎるし、上の方は変化を嫌う傾向がある(それでいて何か無いかとわめく。矛盾しているよなー)。
結局、休暇中に考える時間を設けてコツコツとツリーを作る必要があるわけだ。
そうなってしまうと、余暇を上手に使えない私にはなかなかハードルが高くなってしまうのである・・・。
いやしかし、ここでやらねばいつやるのだ。
今はすぐにそれを生かす環境がないが、生かす環境が揃ったときに間に合わないというのでは意味が無いし。
[PR]
by tsuyodrive | 2004-11-22 02:42 | 仕事

今日のカートメモ

久々のカートだ!最近忙しくてなかなかやる機会に恵まれなかったのだった。
午前中は前日の雨の影響で走るのを控えた。
コース2箇所で水溜りがある。タイムでないもん。

エンジン回転が伸びないのでニードルを色々変えてみた。
カートショップの人に色々聞いてみる。

まずHi15Lo90で走る。
基本的にはトータルで105分らしい。
で、プラグのさきっちょがちょっと湿っている時はLoを絞る。
逆に焼けすぎて白くなるときは開ける。
きつね色にこんがり焼けてるときはグー。
白煙があがる時はガスが濃いので走りながらHiを絞る。効果がでるのに時間がかかるので2,3周様子を見た方が良い。だそうな。

今日前半は38.59秒、14560回転。

後半はタイムは伸びなかった。
一応、日差しが弱くなりタイヤがグリップしないからアクセルがあまり開けられなくなるので、という言い訳をしてみる。
エンジンは割りとよく回るようになって、14730回転まで回った。
最終コーナーではかならずお尻が出ちゃうので回りきらないということもある。
早めに向きを変えて、直線的なアプローチで最終コーナーを攻めてみるか?
うーん。
[PR]
by tsuyodrive | 2004-11-13 15:14 | カート

いすぉがすぃ。

あーーーー忙しい
勉強もままならない。と言い訳してみる。

てゆーか世の中(?)財務会計に入ろうとしているときにあたしゃまだ最初の企業経営理論の基礎問練もできてねーです。
こまったな

こんなのみてないで勉強しなきゃなぁ。
[PR]
by tsuyodrive | 2004-11-10 00:50

XML。

いきなり、XMLに興味を覚えた。
なぜなら、仕事で有効に活用できるかもしれないと思ったからである。
現在開発中のシステムはシステムダウンや致命的な例外が発生するとトレースファイルを吐く。これがユーザーさんのところから毎週60~70個くらいの規模で私のところに届く。このトレースファイルを分析・整理して、我々の開発部分に不安定なところがないか確認するのが仕事である。

通常、再現手順が判れば問題解決は非常にたやすい。なぜなら再現手順により問題が見つけやすいからだ。しかし、私のユーザーはまずデータが機密であるためおいそれと出せない。次にユーザーさんの負荷が高く、丸1日操作している中のほんのひとかけらの操作について覚えていないことの方が多い。3つめにトレースファイルの分析が送られてくるのは翌週であるため、分析を開始してからユーザーへのヒアリングができるまでにものすごくタイムラグがある。これも再現手順を聞きだしにくくなっているひとつの要因である。

また、トレースファイルを分析するのは結構骨だ。1ファイルあたり200行~300行くらいある。情報を一つ一つ注意深く追う時間などは割けない。そのようなことをしても効果が薄いからだ。また、開発メンバーへの問題のディスパッチが遅れてしまう。できるだけ早い段階で問題をディスパッチし、早期解決に努めなければならない。そのためには効率よく情報を取捨選択する必要があるのだ。
しかしながら、トレースファイルだけを一つ一つ追いかけても、問題がどこにあるのかとてもわかりづらいというのが現状である。非常に不毛な作業を強いられているのだ。

そこで、この状況を打開すべく、思いついたのがトレースファイルのXML化と、パターンファイルをXMLファイルでDBにして活用すること。
ユーザーは何度か同じことにチャレンジし、同じところでダウンしているという操作がトレースファイルから伺える。これは再現手順を覚えている可能性が非常に高いはずだ。
また、プラットフォーム既知の問題というのはある程度トレースファイルの出力がパターン化されている。このパターンと一致するようなトレースは「既知」としてこれ以上調査する必要はないはずだ。
あまたのパターンを目で追いかけ、行き当たりばったりにチェックするのは正確さを欠くばかりか時間がかかってしまう。こんなことに注力するより、問題をもっと詳細に分析することに注力すべきである。

トレースファイルはただのテキストファイルなので、これまではある程度のフィルタリングとしてcygwinのC Shellを利用してgrepやawkなどでふるいにかける程度だった。
これをさらに強化し、誰でもどこでも使え、分析ノウハウを漏らさず分析に適用するようなツールが必要だと感じた。

XMLはXMLパーサと呼ばれるファイルの「読み・書き」ができる機能が用意されている。
これをVC++で作ったモジュールから呼び出せばXMLを自由自在に操作可能だ。
(他にもJavaやらPerlやらVBやらあるらしいが、門外漢なので省略)
しかもファイルIOのデバッグから開放されるというメリットもある。
加えて、プラットフォーム開発元(フランス)などに分析結果をそのまま送ることもできるだろう。(今のままでは日本語部分が文字化けを起こすだろうが、Unicodeに変換することにより、文字化けを起こさずデータを失わなくて済むというメリットも。)

さらに言えば、SQLなどは他のパッケージが必要であり、利用PC上で環境設定を余儀なくされるが、XMLはツールさえ作ってしまえばそれをデリバリするだけで使えるはず。
XMLファイルはテキストなので特別なツールがなくても読める。
これは非常に大事なことだ。

トレースファイルは見出し毎に出てくる内容が異なるが、見出し一つ分のステートメントをタグで囲んでしまい、あとはローカルなフォーマットを適当に定義してやればそれだけでXMLファイル完成である。
その後はXMLのツリーを読み込み、メモリ上で加工するだけとなる。
報告文書作成については、csvで出力しExcelで整形して見せることも比較的簡単だろう。
(手動の集計作業もツールでやってしまえる)

XMLを使うのは初めてなのでインプリに多少時間をとられるかもしれないが、やって損はないだろう。むしろ柔軟で強力なソリューションとなるかもしれない。
[PR]
by tsuyodrive | 2004-11-02 03:37

追いつかない。

さすがに、10/1から始まっている講義を3週間過ぎてから始めたのでなかなか追いつかない。普段こなすくらいの量しかできない。これは結構大変だと実感した。
予習も復習もあまりできず、とりあえず授業を聞くのみ。サブノートはまず1枚書いてみた。時間かかる。

そもそも、講義が1回あたり2時間半もある。残業で夜遅く帰ってきて、ご飯作って食べてマターリしているとすぐに寝る時間がやってきてしまう。2時間半も集中して受けるのは難しい。
やはり土日に集中可能な時間を確保して講義を聴講し、平日は演習や復習に充てたほうがよさそうである。
[PR]
by tsuyodrive | 2004-11-02 01:01 | 中小企業診断士