(現在 過去ログ4 を表示中)

HOME HELP 新規作成 新着記事 トピック表示 ファイル一覧 検索 過去ログ

[ 最新記事及び返信フォームをトピックトップへ ]

■464 / inTopicNo.1)  桐の優位性について
  
□投稿者/ 小林深志 -(2008/07/29(Tue) 11:36:13)
    こんにちは
    お世話になっております。お知恵をお貸しください。

    私は博物館に勤務しております。8年ほど前に建て替えがあり、その時には自前のデータベースを数千万円かけて制作し、メンテナンスだけで年に数百万円かけていました。
    しかし、金額の他、自分で設計変更ができないなどの点から、個人的に以前から使用していた桐に移行することを納得してもらいました。

    その後、同じ教育委員会の中の他の部署を転々としながら、それぞれの部署で桐を導入し、ネットワークでデータを共有して使い勝手が良くなってきたところです。

    ところが、私たちの職場(地方公共団体)でシステムの見直しの時期が来ており、システム管理者としては桐からメジャーであるアクセスに移行の考えがあるようです。
    メジャーと言うだけでシステム管理者にアクセスを使っている人間がいるわけでもなく、以前に2回程度外部から講師を呼んで講習会があっただけです。私もアクセスを使ってみましたが、どんなにいいソフトでも数回の講習会と市販の教則本だけを頼りに使用するのが耐えられませんでした。

    私は桐をv2から使っており、一括処理などの難しいことはできませんが、こうした掲示板などでの皆様のすばやい対応ともに、何とかやっていけそうな気がするのです。
    なんとかシステム管理者を説得できるような理由はないでしょうか。

    一週間ほどで文書を提出しなければいけないのですが、お知恵をお貸しください。
引用返信 [メール受信/ON] 削除キー/
■465 / inTopicNo.2)  Re[1]: 桐の優位性について
□投稿者/ 桐システム開発者 -(2008/07/30(Wed) 08:11:21)
    小林深志さん
    こんにちは。
    私は桐でシステムを開発しているものです。
    小林さんの書き込みをみて、私の所見を書かせてもらいます。

    そもそもシステムとは、業務を簡単に処理が出来るようにするものです。
    システム依頼者と、システム開発者の関係は、
    システム依頼者が、使用したい処理内容を開発者に発注。
    小林さんは、数千万もかけて発注されたようです。
    システム開発者は、依頼された処理を、使いやすいように構築する。
    しかし、構築されたシステムを依頼者側が設計変更をされるのは
    開発者側からすれば少々困り者です。
    メンテナンスが出来なくなると思います。
    数千万もかけたシステムから、桐に移行するのはどうでしょう・・・?

    依頼者は、アプリケーションが桐でも、アクセスetc何でも
    関係ないと思います。

    依頼システムが依頼者の使い勝手がよければ、それでいいのではないでしょうか?

    使い勝手が悪いから、桐のお世話にならないといけないのではないでしょうか?

    以上私の開発側からの考えを書かせてもらいました。

引用返信 [メール受信/OFF] 削除キー/
■466 / inTopicNo.3)  Re[2]: 桐の優位性について
□投稿者/ 小林深志 -(2008/07/30(Wed) 10:23:53)
    No465に返信(桐システム開発者さんの記事)
    桐システム開発者さん
    こんにちは。
    > 数千万もかけたシステムから、桐に移行するのはどうでしょう・・・?
    すでにシステムを廃止し、桐への移行は終わっています。

    > 依頼者は、アプリケーションが桐でも、アクセスetc何でも
    > 関係ないと思います。
    今では自分で桐で設計していますので、システム開発者への依頼はありません。
    サーバーの管理者が、私の使い慣れた桐ではなく、ほとんど使ったこともないアクセスに変更させることを計画しているようなのです。
    そこでアクセスよりも桐のこういったところがいいという意見書を書き納得させる必要があり発言しました。

    良いお知恵はないでしょうか。

引用返信 [メール受信/OFF] 削除キー/
■467 / inTopicNo.4)  Re[1]: 桐の優位性について
□投稿者/ ONnoji -(2008/07/30(Wed) 12:26:03)
    2008/07/30(Wed) 16:07:49 編集(投稿者)
    2008/07/30(Wed) 12:40:14 編集(投稿者)

    > すでにシステムを廃止し、桐への移行は終わっています。
    > 今では自分で桐で設計していますので、システム開発者への依頼はありません。
    > サーバーの管理者が、私の使い慣れた桐ではなく、ほとんど使ったこともないアクセスに変更させることを計画しているようなのです。
    > そこでアクセスよりも桐のこういったところがいいという意見書を書き納得させる必要があり発言しました。

    以下システムをアプリケーションと言い換えます。
    現行の「桐のアプリケーション」を「アクセスのアプリケーション」に変更するのは、
    アクセスに習熟していない場合、極めて困難な作業だろうと思います。

    余談ですが、担当者が頑張ってアクセスでアプリケーションを作成したけれど、
    その後担当者が代わって、ハードディスクのゴミとなった事例はたくさん漏れ聞いています。
    もっとも、同様のことは桐の場合でも有るでしょうけれど、
    PCの初心者にとって、桐の方がアクセスよりも敷居が低くて使いやすい事は明白でしょう。

    ■PCの初心者にとって、桐の方がアクセスよりも敷居が低くて使いやすい事
    具体意的には・・・
    ・桐では、SQLの知識が無くてもデータを操作できる。
    ・桐では、高品位の帳票印字が簡単に出力できる。
    ・桐では、VBAの知識が無くても簡単にアプリケーションが作成できる。
    ということでしょう。
    つまり、SQLやVBAを知らないPCの初心者が、
    VBやVBAと同等のアプリケーションを、
    「サッと作って、ササッと直せる」という利点があります。

    ■データ資源として
    詳しい情報がないのでタラレバですが、
    サーバーの管理者がアクセスを計画するというのは、
    ・アクセスのデータがVB等で利用しやすい
    ということではないでしょうか?。
    残念ながら、桐のデータ( .tbl )は桐しか利用できません。
    ここがネックなのかも知れませんね。

    ならば、データ資源はアクセスのデータとして、
    ODBC接続で桐の外部DB( .xvw )として桐で利用するという方法が考えられます。
    この場合、従来の桐のアプリケーションは最小限度の変更で済むので有力な方法です。

    もっとも、ODBC接続で桐の外部DB( .xvw )として桐で使い場合、
    予見し得ないさまざまな問題があるかもしれません。
    いろいろ実験してみないと実用性があるかは分かりませんのでご注意ください。

    ■対応策 第1案 現状維持
    「アクセスのアプリケーション」に変更することの
    ・現場の知識レベルの困難さ、
    ・現場で必要とされる膨大な変更作業
    ・現場でアプリケーションを継続的に維持する困難さ
    などをアピールして、現状維持をサーバーの管理者に納得させる。

    これでは何も変わらないので、サーバーの管理者は、アクセスのデータ代替としてCSV形式のデータなどを必要とします。
    現場側では、サーバーの管理者の負荷を軽減するべく、データ変換の作業を負担する必要が生じると思われます。

    ■対応策 第2案 データ資源のみをアクセスにする
    データはアクセスのものとし、ODBC接続で桐の外部DBとして桐で利用する。
    ・ODBC接続( .xvw )で桐側で実用できるか否かの検証が必要。
    ・現場では、従来の桐のアプリケーションは最小限度の変更で済む。
    ・サーバーの管理者は、データをVB等で利用できる。

    この案は、ODBC接続( .xvw )で桐側で実用できるか否かがネックです。
    サーバーの管理者には不満はないでしょう。

    ■感想
    現場の人が、サーバーの管理者に「アクセスは、イヤだ・キライだ」というだけでは何も先に進みません。
    現場では「これこれしかじかの有用性がある」と腹を割って説明する必要があると思います。

    また、サーバーの管理者側にも、「それなりの理由」があるはずですから、
    現場の人は、サーバーの管理者の理由を十分に聞いてあげる必要があります。

    データ資源は、コンピュータ化(自動化)の根本の問題ですので、双方が十分に話し合って、円満に解決するのが得策です。

    しかし、サーバーの管理者が、分らず屋のコンコンチキならば、
    すべての作業をサーバーの管理者にやらせればいいです。
    アクセスのアプリケーションの設計も開発もメンテナンスもすべて、サーバーの管理者に引き受けてもらうしかないですね。
    つまり、「何から何まで分らず屋のコンコンチキが全部やれ!」ですね。ハハハ。

    もちろん、サーバーの管理者が、分らず屋のコンコンチキでないことを期待しますが・・・

    <追伸>

    現場だけで閉じたシステムであれば現状のままで良いでしょうけれど、
    他部署でもデータ資源を利用するのであれば、すりあわせが必要になると思います。

    この投稿は、あくまでも私( ONnoj )の個人的な感想です。

引用返信 [メール受信/OFF] 削除キー/
■468 / inTopicNo.5)  Re[2]: 桐の優位性について
□投稿者/ ONnoji -(2008/07/30(Wed) 17:57:41)
    > そこでアクセスよりも桐のこういったところがいい

    よくソフトウェア:甲とソフトウェア:乙の違いを比べる話がありますが、
    こういった比較は無意味です。

    例えて言えば、トヨタと日産の同じクラスの乗用車を比べるのと同じです。
    どちらも路をちゃんと走るでしょうし、燃費も良いでしょう。

    アクセスと桐は、どちらもデスクトップ・データベース・アプリケーションです。
    ジャンルから言えば同じです。

    従いまして、
    アクセスにはこれが有って、桐にはこれが無い、
    アクセスにはこれが無くて、桐にはこれが有る。
    こういう比較は無意味です。

    あえて桐の利点を挙げると…
    ・桐の方がアクセスよりも何十倍も早くアプリケーションが開発できる
    ・桐の方がアクセスよりも何十倍も早くアプリケーションのメンテナンスが可能である
    ・桐の方がアクセスよりも高品質なアプリケーションが早く開発できる
    ということは、間違えなく言えると思います。

    あえて桐の不便な点を挙げると…
    ・桐のデータ( .tbl )は桐でしか使えない
    というただ一点でしょう。

    ローカル・エリア・ネットワーク関しては、
    桐もアクセスも一応対応していますが、本格的に使うにはどちらも適していません。
    デスクトップ・データベース・アプリケーションでは荷が重いです。

    もしも、ローカル・エリア・ネットワークで本格的にデータベースを利用するならば、
    例えば、オラクルやSQLサーバー等のRDBMSが適しています。

    なお、アクセスが初心者でも簡単に使えるというのはウソだと思います。
    アクセスを使うには、データベースの(正規化)設計を正しく行う必要があります。
    データベースの正規化の知識が無いと、本当に使いにくいデータを作成してしまいます。

    また、アクセスを使うには、SQLの知識が必要です。
    アクセスのクエリーの基本はSQLです。
    しかし、UI(ユーザインタフェース)でSQLを使わなくてもデータにアクセス出来るようになっていますが、
    SQLの知識が無いと、とんでもないクエリーを作ってしまいます。

    桐の方では、
    ・データベースの正規化の知識
    ・SQLの知識
    が必要とされないので、アクセスよりも断然敷居が低いですよ。

引用返信 [メール受信/OFF] 削除キー/
■469 / inTopicNo.6)  Re[3]: 桐の優位性について
□投稿者/ 小林深志 -(2008/07/31(Thu) 09:11:47)
    ONnojiさん
    何回もありがとうございます。
    簡単さによる桐の利点がよくわかりました。
    各課のアプリケーションの使用リストを見ても、桐を利用しているのは私が在籍していたか在籍している博物館2館と教育観の本課だけなので、データの共有は問題ありません。また、アクセスを利用している課もありませんでした。これでは、身近の詳しい人に連絡して聞くなんてこともできないわけで、これも逆に説得理由になるかもしれません。
    何とか説得してみたいと思います。

    解決かどうかのチェックは、継続使用が認められたかどうかが判明した時点で入れたいと思います。

    ソフトウェアの比較では、かつてワープロソフトに一太郎と松があり、私は松のユーザーでしたが日本標準を宣伝文句とした一太郎に軍配が上がってしまいました。一太郎はまだ残っていますが、世界標準をうたうワードにかなり前から水をあけられてしまっています。
    ネットワーク管理者は、そうして無くなってしまう可能性も考えているのではないかと思われます。

    また車の例も挙げられていましたが、ネットワーク管理者から見ると、トヨタと日産の比較ではなく、トヨタと光岡自動車ぐらいにしか思えないのかもしれません。つまり、どちらも性能は変わらないかもしれないが、愛好家の趣味的存在と言うところでしょうか。

引用返信 [メール受信/OFF] 削除キー/
■470 / inTopicNo.7)  Re[4]: 桐の優位性について
□投稿者/ ONnoji -(2008/07/31(Thu) 11:24:32)
    > ソフトウェアの比較では、かつてワープロソフトに一太郎と松があり、私は松のユーザーでしたが日本標準を宣伝文句とした一太郎に軍配が上がってしまいました。
    >一太郎はまだ残っていますが、世界標準をうたうワードにかなり前から水をあけられてしまっています。
    > ネットワーク管理者は、そうして無くなってしまう可能性も考えているのではないかと思われます。

    先輩の「松」を、後輩の「一太郎」が出し抜いたことはよく知っています。
    その「一太郎」を、さらに後輩の「ワード」がコテンパンに叩き潰したこともよく知っていますよ。

    世の中がDOSからWindows95に代わって、DOS時代のソフトの大半は絶滅しました。
    これは日本だけのことではなく、世界の各国で起きた現象です。
    また、かろうじて絶滅を免れたソフトも、絶滅が危惧される状態です。

    これは、地球に大隕石が衝突して、結果的に氷河期になり恐竜たちが絶滅したことを連想させます。
    もちろん絶滅した恐竜は、ロータス123、ワードパーフェクト、dBASEなどです。
    環境の変化こそが、これらの恐竜ソフトを絶滅させた原因です。
    日本でもたくさんのDOSソフトが絶滅しました。

    日本のDOS起源の水平型ソフト(ビジネスツール)で、絶滅を免れたのは、「一太郎」と「桐」くらいではないでしょうか。
    ※垂直型ソフト(例えば会計ソフト)はそれほど影響を受けていないようですが…。

    永遠に存在し続けるソフトなんてありません。
    まるで平家のように繁栄しているM帝国にも、かげりが見えます。

    しかし、できるだけ長く同じソフトを使いたいというのが人情です。
    桐Ver.9-200X は Vista 対応ですので、Vistaマシンが枯渇するころまでは十分使えると思います。

    >また車の例も挙げられていましたが、ネットワーク管理者から見ると、
    >トヨタと日産の比較ではなく、トヨタと光岡自動車ぐらいにしか思えないのかもしれません。
    >つまり、どちらも性能は変わらないかもしれネいが、愛好家の趣味的存在と言うところでしょうか。

    「デフェクトスタンダード」というは恐ろしいものです。
    使ったことも無いのに、良い物だと信じて疑わないのですから。

    ブランドのチカラというのも恐ろしいものです。
    M帝国のソフトのほとんどが、買収したものだということを知らない人ばかりなのですから。

    また、ブランドやソフトの比較に関しては、
    大の大人でも「僕はこれが好き!、僕はこれが嫌い!」というレベルの発言ばかりしています。
    プロ野球やサッカーのファンが騒いでいること同じですね。
    さらに、お馬鹿なマス・メディアが油を注いだりするものですから、ますます子ども同士の感想戦みたいになってしまいます。

    <追伸>

    また思いつくことを書くかもしれません。
    時々この掲示板をチェックしてくださいね。

    以下の記事もご参考にしてください。
    なお、記事中のURLはリンクが切れているものが多いですのでご注意ください。

    過去の桐井戸端BBS (桐ver.9)
    30089 図書管理台帳を作りたいのですがデータベースの設計はどのようにすればいいのでしょうか 2005/05/30
    http://www.fuku3.com/habata//kbbs/kakov9/30089.htm

引用返信 [メール受信/OFF] 削除キー/



トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

Mode/  Pass/

HOME HELP 新規作成 新着記事 トピック表示 ファイル一覧 検索 過去ログ

- Child Tree -
- Antispam Version -