|
|
ジョー(通称)より (Digital DNA sohoです。)
8bit コンピュータ Mz-2000 より現在までコンピュータを使用しています。
昔を知る私としては。現在のパソコンの性能には目を見張るものがあり。
日進月歩の進歩にいつも楽しみにしています。
デジタルディエヌエイでは、熊本にてWindowsを中心とした開発を行っています。
最近は主にC#を使用し、.Net FrameWork上での開発に力を入れています。
データベースはSQL Server, Oracle, MS-ACCESSなどを利用しています。
|
ﾃﾞｼﾞﾀﾙﾃﾞｨｴﾇｴｲでは、各種ソフトウェアの開発のお手伝いをさせていただいています。
開発言語は
C#.Net , VB6 , Oracle , SQL server, Access,C, PHP等での開発を行っています。
Visual Basicのシステムから.Net への移行やAccess MDBをSQL Serverに移行など
ご相談ください。
また、各種外部連動のシステムに関してもご相談を承っています。
・たとえば、サーマルプリンターに領収書を印刷したい。
・Rs-232cで外部機器と接続しデータを収集したい。
・PDAを使いたい
Windows mobile やWindows smart phoneなど
・バーコードリーダーの開発をしてほしいなど。。。
お気軽にお尋ねください。
メールによるお問い合わせは
| コンピュータについて |
 |
SQLな勧め |
|
動かないコンピュータ |
デジタルディエヌエイの現在までの
歩みについて。
|
若者よ、SQLを身につけよ。
|
35才定年説なんて。。。 |
|
|
|
|
|
|
|
| 動かないコンピュータ2 (2009.12.18) |
コンピュータ、ソフトなければただの箱などと言われた時代もあり。ソフトの重要性を叫ばれた
時もありましたが。いくたびかソフト開発の人材が不足するなどとさけばれては、不景気、年齢
その他( 新3K職場: きつい・きびしい・帰れない)などで、この世界から転職していってしまう。
そんな事が繰り返されています。
私はコンピュータ業界特にソフトウェアのSE・プログラマなどはある種武道の道を究めようととる
武道化的な心情に近いものがあるように感じています。
ある意味、この世界は先輩・後輩のあいだにメンターと弟子的な感覚もあり、求道者的な世界を
感じる時があります。
さて、なせ゜プロジェクトは時に失敗してしまうのか。。。
このプロジェクトは成功するだろう、または失敗する確率が高いなど。現場で仕事をされている方は
ひしひしとそのプロジェクトの現状が肌で感じておられるのではないでしょうか。
その場の雰囲気やプロジェクト参加者の顔色などから、うかがい知ることが容易にできます。
失敗パターンについて
一、新しい技術にのみ興味を持ち流行に左右されるパターン
業務よりは技術に目がいきがちなパータン
今世間ではやりだ流行だで、やはりこの世界の技術者は新しいものが好き、できれば流行を追いたい
特に若い技術者などは、やはり今はこれをやっておかないと、なにまだそんな言語や環境なの。。。。
などあせりや趣味が入りやすいもの。。。
流行を追いかけて、最新の技術でサクサク動くはずが、完成すらしない、または不可解や現象になやまされつづける。。。
二、経験豊富な人材が不足、されど運用開始の日付は決まっている。
皆よくわらなない、そんな中であるものは最新技術に走り、業務知識はいきあたりばったり
業務に関する経験がないため、言われるがまま工程をこなしていき、後で矛盾が表面化する
その時にはすでに時おそし、改造がかさなりスパゲティ状態とかしていく。。。
当然、亡者の行進よろしく火の玉集団とかし連日連夜徹夜を繰り返す。
ある者は私たちがんばっているといった妙な高揚感にひたり、ある者はもうこんな職場はいやだ
といつ逃げ出そうかと時期をうかがう。。。
三、方針が決まらないパターン
あれもこれも詰め込みすぎ、理想を追い求め機能が飽和してしまい失敗するケース
予算、スキル、納期を考えれば無理がわかりそうだが、性能や環境を通り越し人から聞いた話し
やメディアでの知識の一部から、あれもこれも機能や性能を要求し、だんだんと現実から離れて
いってしまうパターン、リプレースなどでよくあるパターンではないでしょうか。
一気にダウンサイズ、や既存のクライアント/サーバからwebへ移行など。。。。
最後にこんなハズでは。。。と出ない性能や、今まで経験しなかった問題に頭を悩ますはめに。。。
四、業者に丸投げパターン
とりあえず、コンピュータはよくわからないしお金を払うんだから、後は業者が適当に見つくろって
くれるだろう。相手はブロだし。。。
なんどか打ち合わせをしたが、各部署から不満もないし(担当部署でこの時点では出来上がりを理解している人
はほとんどいない)、とりあえずあとから言われないよう、「意見がないですか。」と社内にメールしておこう。
それからいよいよ運用開始を迎え、各部署から一斉に「なんだこのシステムは」,「以前のシステムが使いやすい」
「この機能がないと使い物にならない」の大合唱。。。
急きょ、ソフト会社を呼びこのままではだめだ、この機能を来月までに至急追加してくれとねじ込む。
話しを聞いたソフト会社は、なんども確認をとったではないですか。別途見積もり、スケジュールを。。。。
担当者との間で押し問答、しわ寄せはソフト会社の開発部署へ。。。。
五、業者のいいなりパターン
コンピュータの事はよくわからないし、ほかの同業他社もおなじシステムを導入しているようだここは
業者にまかせるか。。。なに、今のシステムはつかえなくなる。。。それは大変だ。。。
で一気にシステムを維新してしまい、現場が混乱するケース。
本当に今のシステムはもうつかえないのか???
以上の内容から、私が思うことは。
この世界はだんだんと年齢が上がるにつれ、単金があがる、年配者はつかいにくい、技術が古いなど
35才定年説をうらづけるような事をよしとするものがあります。よって年齢があがると管理者・営業など
配置転換が進むところがほとんどではないでしょか。
生涯現役でソフトを組む事はできないのでしょうか。
本当に最新の技術がよいのか、技術の裏にかくれたノウハウ、経験は不要なのか、若くて安く、最新の
技術がわが社にとっての最適解なのか。。。。
もう一度考えてみられてはいかがでしょうか。
私はCOBOL言語はほとんど使用した経験がないのですが。COBOLに代表されるレガシーな言語は不要
なのか。。。もう一度問いたいと思います。
現に現在でも膨大なCOBOL資産は日々活用されており、私も最初にCOBOLをやっておけばよかったなど
と後悔することもあります。もちろん最新の技術も大好きですが。
やはりせつかく覚えた言語やノウハウが長年にわたり使用できないこの世界はどうなのかと考えさせられて
しまう所があるからです。本来は一つの言語を習得後に、業務知識をつけ改良を施していくのが理想のパターン
であると考えますが。。。
ただ私にとって救いなのはSQLを最初に仕事として使用し、その後SQLだけは長年にわたり役に立ち続けている事です。
■コンピュータについて良く分からない経営者の方へ
コンピュータの開発に関わる仕事を事業の柱として位置づけられている会社を除き、あくまでもコンピュータ
は御社にとって副次的な意味のみである事と思われます。
現在は特にコンピュータシステムが御社の背骨や神経など業務を運用していく上で非常に重要なものとなっており、システム入れ替え等はまさに御社にとっては死活問題となる場合もあるという事を知っていただきたいと思います。
特にシステムの入れ替えにあたっては、事前にプロトタイプ等で性能、使い勝手などを充分評価の上入れ替え
を検討される事をお勧めいたします。
また、運用開始の日時が絶対なのか。。。えてして発注元の企業は柔軟性をもっているが、中間に立つソフト会社が一次うけ、二次受け等に絶対厳守など通達し、下からの声が発注元がうかがい知らない場合がありえます。
プロジェクトがただならぬ状態に至った場合には、一次受けや営業はおそらく御社にたいして、できます・完成させます
しか答えないとおもわれます。おそらくその状況を放置しておくと双方ともに奈落の底に突き落とされていく事が充分考えられます。
次に危険なサインについて考えてみましょう。
・ずいぶんと当初の見積もりから、追加のコストがかかっているようだ。
システムを構築する際に、システムエンジニアはどちらか言うと無理だと思われる機能についてやたらと機能を
後回し、または削りたがるのが一般的ではないでしょうか。
システムエンジニアは総合的に見て、コスト、マンパワー、納期を考え無理のない実行できそうな計画を立てようと
努力するものです。その機能が御社にとって本当に必要ですか。よくある話ですが、最初に打ち合わせた機能から
実際の運用ではほとんどがつかわれない不要な機能が盛り込まれていたなど。
これだけは絶対にないとこまるものだけをシステムに入れるようにしませんか。
・毎晩夜おそくまでがんばっているな、昨日は徹夜かごくろうさん。
社内開発、業者による開発など、経営者の方はよく夜の明かりを観察される事をお勧めします。
毎晩夜おそくまで明かりがついている。 たしかに忙しくてしかたがない、売上も右肩あがりなら。。。
よいのでしょうが。 システム部門が徹夜の連続なら、疑ってかかつた方がよいとおもわれます。
ひょっとして、なにか重大な問題がそこに隠れているのでは、無理なスケジュールなのではないか
そのしわ寄せがいっているのではないか。。。
ソフトの世界では、何日寝なかったなどの話しを良く聞きます。わたしも最高は5日連続で徹夜ほとんど
寝ずの状態で仕事をした事があります。
本来は労働基準法など問題になりそうですが、昔であれば家に持ち帰る場合もあるでしょうし、土日に
なやみつづけることもあります。この世界では個人のスキルがたりないなどのせいにされる事が多いで
すし、会社全体の問題として意識する事が少なすぎるのではないでしょうか。
ある意味、ソフト業界は体育会系です。脳細胞よりはゴリラのように体力勝負なところがあります。
結局徹夜して意味があるのか、たしかに夜静かな時に能率のあがる事はありますが。寝ずに効率が
上がるはずはありません。 ある意味お客様へのアピールの意味がほとんと゜であると思います。
逆に途中まで完成したものを意識がもうろうとして、壊してしまいかねません。
人間の集中力には限界があります。
◆失敗しない為には
・小さなプロトタイプによる充分な事前評価を行う。
・無理なスケジュールを立てない
・無駄な機能をできるだけ思い切りそぎ落とす。
・運用開始の日を絶対のものとしない。
失敗しそうな場合は一旦プロジェクトを停止する。
・ソフト会社は最初から一社に絞らず、複数他社から情報収集する。
・開発者の顔色や健康具合, 勤務時間をみて、あまり残業がある場合は
無理な開発なのではないかと疑ってみる。また問題となっている事象に
ついて解決策を指示する。
・上記の策を実施しても、見積もり額が膨らむ事がありうるので、システム
の想定額に半額以下で当初にシステムの予算を考える。
・特に大胆にシステムを維新する場合は小さな機能から移行を考える。
事前の充分な準備および、社内の蓄積が重要とおもわれます。
つづく。
|
|
|
