2004年08月29日

インド音楽の夕べ

DSC01589.jpg近所であった「インド音楽の夕べ」へ行ってきました。
こんな田舎でやるのがもったいないくらいの、本格的なモノでした。
古典的なインド音楽を演奏したのですが、16小節でひと廻りしてシタールとパーカッションが交互にアドリブを繰り返すそうです。
終わってからゆっくりと話したかったのですが、連れて行った妻が、留守番している子供が気になるからと、早々に帰ってきました。
残念。
迫力もあって、良かったです。機会があればぜひ。

2004年08月28日

稲刈り手伝い

DSC01581.jpg 妻の実家へ稲刈りの手伝いに行ってきました。
とは言っても、せいぜい運搬ぐらいしかできませんが。
コシヒカリは遅い品種なので、今回は「五百万石」という酒米です。
実家の近くにある「朝日酒造」という酒蔵で使われるそうです。
稲穂は熟して頭を垂れていました。
DSC01582.jpg 義父さんが刈り取った籾を軽トラックに載せて農協のカントリーエレベーターへ運ぶことが僕の役割です。
大したことをしていないのですが、歓待してくれて申し訳なく思いますが、少しでもお役に立っているらしいので、ウレシイです。
DSC01583.jpg 刈り取った籾米を持ち込むと、伝票を書いて車ごと重量を量ります。
乾燥機へ投入した後、出口でまた重量を量って、最初との差が納入量になります。
簡単な検査はあるのですが、いったん投入してしてしまうと、他の方が持ち込んだ分と混ざってしまいます。
納入する酒米だけでなく、自家消費するコシヒカリもそうやって混ざって、量った分だけ帰ってきます。
農業についても、効率化を求めていますので、農家でも自分で作った米を食べるわけではないのです。

2004年08月25日

企業システム開発の現状と課題(2)

企業システム開発の現状と課題(1)より続き

ソフトウェア見積りのすべて―規模・品質・工数・工期の予測法
【開発プロジェクトはなぜ失敗するか】

残念ながら、システム開発プロジェクトは失敗するケースが多いが、プロジェクトの成否を左右する最大の要因は顧客側にある。
重要なことは、顧客システム担当のシステムスキルレベルだけでなく、ユーザー部門との力関係、顧客企業を取り巻くビジネス環境なども大きく影響してくる。
しかしベンダー側はプロフェッショナルとしてプロジェクトに参加しているのであるから、失敗した場合の責を免れることはできない。
これまで関わった失敗したプロジェクトを振り返り、ベンダー側の反省点を以下のように挙げてみよう。
  • スキル・技術力不足
    業務知識やコンピュータシステムに対する知識とセンスが欠如しているベンダーが担当したシステムは失敗する可能性が高い。
    特に最新の技術を取り入れて構築しようとしているシステムの場合は致命的である。
    知らないことを分かったように取り繕って、いい加減にシステム構築をおこなおうとするのは、プロとして不誠実であり、同業者として恥ずかしい。
  • マネジメント力不足
    システム開発にあたって本質的な管理ができていないプロジェクトがある。
    それは、数字の辻褄を合わせることで問題点を先送りし、終盤に来て破綻するケースにつながる。
    特に元請けが標準化や共通部品を担当する場合、いっこうに成果が出てこないまま、プログラミングが終わってからようやくバギーなものが出てきて、開発担当にしわ寄せが来ることが多い。
  • 見積りの失敗
    最初に述べたように、最大の要因は顧客側にあるため、初見のお客さまの実際のシステム構築費用を見積もるのは不可能である。
    そうは言っても、予算を確保しないとシステム開発はスタートしないため、様々な手法を使って見積もりをすることになる。
    しかし時間をかけて見積もりしても、顧客の思惑により予算額が最初から決まっている場合がほとんどである。
    そんなだったら最初からいくらでやってくれと言ってもらった方が、お互いに良いと思うのだが。
    値切られ、叩かれ、機能カットなどをおこない、見積もりを顧客予算に合わせて提示して、ようやくスタートすることになる。 終わってからプロジェクトを締めてみると、最初の見積もりがいかに正確であったかを実感することもあるが、もうその時点では遅い。
    往々にして予算が不足しているプロジェクトは、最初のコンサルを入れた検討段階や、ヘッドベンダーが担当する分析段階で予算をオーバーしてしまい、その後のシステム開発にそのしわ寄せがくることになる。
    特にこれまでの業務を大きく変えようとする野心的なプロジェクトに、このケースが多い。

MyMeme: 企業システム開発の現状と課題(3)へ続く

2004年08月22日

企業システム開発の現状と課題(1)

先月、某所で「企業システム開発の現状と課題」と題して講義する機会がありました。
公開できない内容はカットして、抜粋を挙げてみます。
えーと参考になるのはウレシイのですが、どこかで引用されたりすることがあれば、ご連絡ください。

【日本の企業システムの特徴】

  • 投資は大都市圏に集中
    investment.gif 首都圏と関西、東海の大都市圏で日本の情報化投資の8割を占めている。 ちなみに新潟県は首都圏の1%程度、つまり全国の0.5%程度でしかない。
    これをマーケットが未開拓であると見るか、需要がないと捉えるかは意見が分かれるところである。
    しかし、現場のシステム開発を担当している私の感触では、積極的に情報化に投資しようする企業が少ないように感じる。
    地方に本社がある企業では、それなりのシステムを組んでいるのだが、システム化予算を低く抑えようとする傾向が強い。
    参照:日本政策投資銀行 地域政策研究センター2002・2003 年度地域別設備投資計画調査


  • ベンダーも大都市圏に集中している
    vender.gif システム構築サービスを提供するベンダーも大都市圏に集中している。
    しかしそれでは需要に追いつかないため、地方のシステム構築会社から大都市圏へ出張、常駐してシステム化需要に応えている。
    総務省統計局平成11年サービス業基本調査結果一覧より
  • 受注ソフトウェアがビジネスの中心
    category.gif 日本固有のシステム化投資の傾向として、受注ソフトウェアが全体の50%を占めるということである。
    欧米の場合、業務アプリケーションパッケージを使用することが多い。
    日本の場合、企業が自社独自の業務ルールに拘ることが多く、画面、帳表などのアウトプットも複雑である。
    時には、要求仕様が厳しすぎて、システム構築に当たっての生産性を大きく損なっていることもある。
    情報処理サービス産業協会「わが国の情報サービス産業」より

RFIDハンドブック―非接触ICカードの原理と応用
【最近のトレンド】
企業業務の情報化はひと段落しているように見えるが、企業による管理レベルの格差は大きい。
きちんと原価管理ができていないメーカーやエクセルベースで管理している企業などもあり、まだまだやるべきことは多くあり、投資環境が大きく変動しない限り、システム需要が枯渇することはない。
特に近年は、端から見ていてもビジネスの速度にシステム構築や改変がついていっていないことがある。
顧客企業でも多品種少量化に加えて、ビジネススピードの向上に伴い、短納期化が進んでいる。
企業買収や合併、部門売却などビジネス環境が大きく変わるケースもあるが、それに既存のシステムが対応できていない。

最近のシステム構築のキーワードとしては、以下のように挙げられる。
  • アカウンタビリティ
    間接工数の明確化など、従来管理してこなかったデータを明確にするシステム化要求がある。
  • トレーサビリティ
    グリーン調達やPL法への対応に伴い、製造工程のデータ収集などのシステムが構築される例がある。
    また、ビジネスのグローバル化によって、日本国内の管理レベルでなく、アメリカ国内と同様の管理レベルが必要となる場合もある。
  • セキュリティ
    外部からの侵入防止はもちろんのこと、内部からの情報漏洩についても管理するよう社会的な要求がある。
    2005年4月より施行される個人情報保護法も対応する必要がある。
    それらの要求を充足するため、セキュリティビジネスのマーケットが拡大している。

【今後の見通し】
近い将来の見通しとしては、以下のように予測する。まったくの私見なので、鵜呑みにしないようにご注意。

■ソフトウェアプロダクトのコモデティ(日用品)化
デジタルデバイドとは何か―コンセンサス・コミュニティをめざして
OS、データベース、オフィスソフトなどソフトウェアプロダクトのコモデティ化の流れは止められない。
またオープンソースプロダクトの普及に伴って、システム構築に必要なプロダクトコストが激減する。
それにより、従来のビジネスモデルの崩壊が起こることになり、近い将来に大きな変動を予想する。
また、コンピュータを活用できるクラスでは、コンピュータの普及に伴って、情報リテラシが向上していく。
さらに電子認証など社会基盤の情報化が一層の進展をしていき、利便性を享受できるクラスとできないクラスとで、情報格差(デジタルデバイド)が拡大していく。


■分散と集中を繰り返してきたシステムトレンドは今後「分散」へ進む
応用Web技術
これまでコンピュータシステムは、以下のように変化してきた。
  1. データセンターでのバッチ処理
  2. オフコンによる分散処理
  3. 汎用機による集中処理
  4. クライアントサーバーによる分散処理
  5. WEBシステムによる集中処理
この順で行くと、次は「分散」がキーワードになると想定するが、最近ではWEBフォームの使い勝手の悪さからリッチクライアントが話題になっており、今のところ次の技術トレンドの最有力だが、まだこなれてきておらず、決定ではない。

企業システム開発の現状と課題(2)へ続く

2004年08月21日

中央大学同窓会

飲み過ぎました。


投稿者 isi's moblog : 01:42 | コメント (0) | トラックバック

2004年08月17日

土地開発公社の諸問題

土地開発公社―塩漬け用地と自治体の不良資産
かつて土地の値段が短期間で大幅に値上がりした時期があった。
そのため、道路の敷設や公共施設の建設にあたって、必要な土地が適切な時期に取得できないことが問題となった。
土地開発公社は、その問題を解消し、自治体が機動的に土地を取得するために設立された外郭団体である。(公有地の拡大の推進に関する法律
だが、多くの開発公社は実体がなく、自治体の長や幹部がトップとなり、自治体職員が業務を担当しているケースが多い。

土地開発公社自体には資産がないため、土地の購入資金は金融機関の融資によって調達される。融資にあたっては、自治体による債務保証がおこなわれるため、実際は自治体による借金である。
この債務保証についてのみ、議会議決が必要とされるが、土地の取得自体をチェックする機関はない。
こうした手続き上の疑念は残るが、購入した土地が有効利用されていれば、土地開発公社の目的に一応は合致している。
しかし、問題は「緊急に取得する必要がある」はずの土地がいつまで経っても利用されず、利子だけが膨らんでいることである。
膨らんだ利子は、塩漬けになった土地を開発公社から地方自治体に売却する際に、無条件に上乗せされる。
上乗せされた、本来の土地取引額との差額は税金によって負担されるのである。

また、現在のように地価が上昇せず、むしろ下がっている状況では、土地を無理して先行取得する意義は薄れている。
それにも拘わらず、現在でも土地開発公社による土地取得はおこなわれている。
議会を経ることなく土地の購入ができるため、行政当局によって恣意的に運用されているのである。
しかも土地の買収に当たっては、周辺の地価とはかけ離れた金額が職業倫理に欠ける不動産鑑定士によって提示されることがあり、行政トップが恣意的に土地を自治体へ買わせるための手段となってしまったケースがある。

こうした納税者が「預けている」税金の無駄遣いを調べ上げて告発しているのは、無報酬で活動しているオンブズマンなどの市民団体である。
行政当局や議会には責任能力や自浄能力が欠けていると見放しているので、しょうがなくやっているのだ。
こうしたチェックは、本来、報酬をもらっている議会議員や監査委員がやらなければいけない仕事なのに。
よく恥ずかしさのあまり、辞任しないものである。

さらに、土地開発公社は行政団体でないため、情報公開の対象外となっているケースも多い。
自治体が開発公社から購入した土地についての資料も非公開にしている理由として、「プライバシー保護」を挙げている。
しかし公開すべきなのは「税金の使途」であり、プライバシーを楯として公開しないことは、行政責任を放棄していると非難されるべきである。

2004年08月16日

春風亭華柳独演会

DSC01277.jpg地元で知り合いが主催する落語独演会がありました。
出演は「春風亭華柳さん」です。
なんでも落語協会を離れて、フリーでやられている方とか。
古典落語を2時間たっぷり聴かせていただきました。面白かったです。

2004年08月15日

飲み会

DSC01275.jpg高校の時からの友人と飲みに行きました。
気易い仲間なので、つい飲み過ぎてしまいました。
わざわざ来てくれたのに、一軒目で潰れてしまってゴメンよ。

2004年08月12日

東京出張

東京へ日帰り出張してきました。
先日稼働したシステムにバグが見つかったのです。
「申し訳ありません。」
ひらすら謝罪し、ついでに簡単な改修もやってきました。
ついでに新しい改修案件についても、摺り合わせをすることができました。
こちらの落ち度で、お客さまにご迷惑をお掛けしたことは戻しようがありません。
その時にキチンと非を認めて謝罪し、即座に暫定対応を提案すること。
後日修正して改めて謝罪すること。
発生させた問題に真摯に対応すれば、却って信頼を得ることができます。
逃げずに正面から対応すること。
慌てず冷静に対応すること。
お客さまの立場に立って対応すること。
最後まで問題を収拾すること。
それを心掛けることがプロとしての矜持だと思います。

2004年08月11日

地域問題勉強会

仕事を早めに切り上げて、某所で地域行政についての勉強会。
内容については、まだ書けませんが、やっぱりそうなるか!とだけ言っておく。
トップに立つ者、指導的な立場にある者は、誰よりも勉強して、誰よりもアンテナを高く張っていないとイケナイでしょ。
でも一番の問題は、そうじゃないトップを選んだことなんだよ。
オレはもう知らんよ。きちんと警告したからな。全力を尽くして説得したからな。

2004年08月10日

納涼会

某所で納涼会。講師を務めた昨日の読書会は大物財界人に臨席いただくことができなかった。合併が佳境に差し掛かっているとのこと。残念。
時間を見て空白期間の出来事をアップしていきます。

2004年08月01日

ご飯茶碗をいただく

DSC01524.jpg近所の陶芸家の方からのご厚意で、娘2人の名前入りのご飯茶碗をいただきました。
こういうプレゼントは、ものすごくウレシイですね。
金銭じゃないんです、もらった方に喜んでもらおうとする思いやりが一番ウレシイのです。