システム開発をしていると、常に運用のことが後回しになっており、
作ってみたけれど、結局使いにくい、運用がまわしにくいと言われてしまうことが多いと感じます。
言い訳ではありますが、私はあまり運用設計まで実施することがないので、
常に最初から案件に関わっていればと思うこともあります。
会社では常に現行システムがあるのであれば、運用がどうなっているのか、性能や環境はどうなのかを
先に調査するよう求めています。
ですが、システムを作る人間は、どうやったらできるのか、どうやって作るのか、システムとはどうあるべきか、
方法論、方式論、開発論、手法ばかりが先行してしまいます。
私たちは作る側ですので、美しく、安く、それなりに品質の高いものをはやく作りたい、
それができれば評価される世界にいます。
たしかにその世界にいるので、上記の論述は必要です。
でもその前に、ちゃんと作ったあとのことを先に考えていたいと思うのです。
私だったらこんなシステム、結局面倒になって使わなくなるだろうなということを感じるものでも、
システム開発側のルールやリスク、場合によってはスキルや作ってしまったから等の理由で
顧客にリリースしてしまいます。
それでも私の会社でも納品さえしてしまえば、Win-Winの関係を築くことができたと言ってしまっています。
これは何を先にやるべきか、あまり明確になっていなからではないかと考えています。
よくあるV字モデルは、
要件定義、基本設計、詳細設計、製造、単体テスト、結合テスト、システムテスト、ユーザー受入テストと
だいたいこのような形で記述されています。
より詳細に見ても、要件定義や基本設計で運用の詳細を見てきた案件が一度もありませんでした。
他の方はもしかしたらやっているのかもしれません。
これは自分の今後のために、反省のためにやるべきことを明確にしていきたいと思います。
まだまだ考え中ではありますが、私が考えているシステム開発の工程は以下の通りです。
一部は詳細に表現しています。
これから、さらに細かく内容を確定していきたいと思います。
第1フェーズ
顧客の現状分析と要求確定
目的定義・実現内容(業務機能・確定可能な非機能)の確定
第2フェーズのスケジューリング
第2フェーズ
現行の運用・環境分析(調査)
実現可能性の分析
実現内容(未確定部分の非機能)の確定
新規 運用内容・運用環境(想定)・保守内容の設計
第3フェーズ以降のスケジューリング
第3フェーズ
業務機能 機能分割
業務機能 機能処理フロー設計
業務機能 詳細設計
開発環境 テスト環境 構築(手順策定)
システム・運用テスト設計
性能テスト設計
第4フェーズ
業務機能 共通処理の抽出
業務機能 機能処理フローをイベントドリブンに変換
フレームワーク設計・実装
新規 移行設計
結合テスト設計
第5フェーズ
フレームワーク テスト
実装
単機能テスト(単体テスト)
第6フェーズ
結合・トランザクション・性能テスト
第7フェーズ
システム・運用確認
第8フェーズ
導入
ユーザ確認
2011年04月29日
2011年04月25日
システム開発工程
いろんな案件でシステム開発をしています。
どこも似たような感じで工程を踏んでいます。
いろいろな表現があるとは思いますし、間にこまかくあるところもあるでしょうが、概ねこのような感じではないでしょうか。
1. 要件定義 : 顧客の要件を確認する
2. 基本設計 : システムの概略についての設計を顧客に分かる言葉で表現する
この間にフレームワークの選定や開発が始まる
3. 詳細設計 : プログラム内部の設計を行う
この間にフレームワークのテストが始まる
4. 製造 : プログラム開発
5. 単体テスト : 開発したプログラム単品のテスト。だいたい製造と一緒
6. 結合テスト : 複数の機能の連結テスト
機能単位を含める場合や、規模によっては2つに分かれる
7. システムテスト : システム全体を結合してみてテスト
8. 受入テスト : 運用も含めて顧客が要求通りにできているか確認するためのテスト
でも、いつも最後のフェーズでいつも、運用に無理がきたりしています。
そうです、だれも使う人間のことなんて考えていません。
どうやって作るか、実現するか、何をシステムで機能を実現するか考えていますが、
だれがどうやって使うかは最後に決まっていませんか？
だから方式論、方法論、べき論ばかりが先行しているような気がします。
それが悪いわけではありませんが、それは我々SIerの自己満足にしかなりません。
これらは我々が品質をどうやって担保するか、安く作るかです。
もちろん、これは最終的には顧客が支払うお金に関係するためあるにこしたことはありませんし、ないのも悪いとは思います。
でもでも、それよりも本当に顧客のことを考えていますか？
私の妻は運用保守をやっています。話を聞いていて、いつも反省します。
多くのハードウェアベンダー、ソフトウェアベンダーの勝手な方式論でできる/できないという言葉に翻弄されてしまっているように聞こえます。つまり、私たちが本当はできても面倒だとか、我々が楽になるからとかが最終的に見え隠れしています。
結局、使えない、数年後にはさらに保守費を安くしたくなる、結局保守費は変わらない、結局フレームワークや作りがSIer独自で他の企業に頼れなくて縁を切れない、顧客もスキルが育たない状況です。
要は、顧客の無知に付け込んでいるようにいつも私ははたから見えているのです。
食べ物とかで無知に付けこまれて高いものを買わされると文句をいうくせに、いつも顧客との打ち合わせでは「顧客は分からないのだから」と言って、資料を用意したり隠したり。。。。。
本当は作れたものも、こちらの予算が回らなければ平気で「技術的には難しいです」なんてことも言います。
一部上場している大手SIerの全ては同じだと思います。なぜそれがわかるかというと、私の会社もそのひとつでしかも、SI専業でも5本指には入る大手です。。。
今、本当のシステム開発手順はどうあるべきか考えています。
これも完璧ではないとは思います。でも、もっともっと良いものがあると信じています。
こんなことばかり言って私は勝手で無責任の極みだとは思います。
でも、こうあるべきだと多少はよくなるというものを紹介出来ればと思います。
どこも似たような感じで工程を踏んでいます。
いろいろな表現があるとは思いますし、間にこまかくあるところもあるでしょうが、概ねこのような感じではないでしょうか。
1. 要件定義 : 顧客の要件を確認する
2. 基本設計 : システムの概略についての設計を顧客に分かる言葉で表現する
この間にフレームワークの選定や開発が始まる
3. 詳細設計 : プログラム内部の設計を行う
この間にフレームワークのテストが始まる
4. 製造 : プログラム開発
5. 単体テスト : 開発したプログラム単品のテスト。だいたい製造と一緒
6. 結合テスト : 複数の機能の連結テスト
機能単位を含める場合や、規模によっては2つに分かれる
7. システムテスト : システム全体を結合してみてテスト
8. 受入テスト : 運用も含めて顧客が要求通りにできているか確認するためのテスト
でも、いつも最後のフェーズでいつも、運用に無理がきたりしています。
そうです、だれも使う人間のことなんて考えていません。
どうやって作るか、実現するか、何をシステムで機能を実現するか考えていますが、
だれがどうやって使うかは最後に決まっていませんか？
だから方式論、方法論、べき論ばかりが先行しているような気がします。
それが悪いわけではありませんが、それは我々SIerの自己満足にしかなりません。
これらは我々が品質をどうやって担保するか、安く作るかです。
もちろん、これは最終的には顧客が支払うお金に関係するためあるにこしたことはありませんし、ないのも悪いとは思います。
でもでも、それよりも本当に顧客のことを考えていますか？
私の妻は運用保守をやっています。話を聞いていて、いつも反省します。
多くのハードウェアベンダー、ソフトウェアベンダーの勝手な方式論でできる/できないという言葉に翻弄されてしまっているように聞こえます。つまり、私たちが本当はできても面倒だとか、我々が楽になるからとかが最終的に見え隠れしています。
結局、使えない、数年後にはさらに保守費を安くしたくなる、結局保守費は変わらない、結局フレームワークや作りがSIer独自で他の企業に頼れなくて縁を切れない、顧客もスキルが育たない状況です。
要は、顧客の無知に付け込んでいるようにいつも私ははたから見えているのです。
食べ物とかで無知に付けこまれて高いものを買わされると文句をいうくせに、いつも顧客との打ち合わせでは「顧客は分からないのだから」と言って、資料を用意したり隠したり。。。。。
本当は作れたものも、こちらの予算が回らなければ平気で「技術的には難しいです」なんてことも言います。
一部上場している大手SIerの全ては同じだと思います。なぜそれがわかるかというと、私の会社もそのひとつでしかも、SI専業でも5本指には入る大手です。。。
今、本当のシステム開発手順はどうあるべきか考えています。
これも完璧ではないとは思います。でも、もっともっと良いものがあると信じています。
こんなことばかり言って私は勝手で無責任の極みだとは思います。
でも、こうあるべきだと多少はよくなるというものを紹介出来ればと思います。
2011年04月24日
Win-Winの関係
私の会社でも要件定義から保守運用まで行っています。
でも、今関わっている案件を踏まえて、確かに我社は利益を出せている案件もあります、一般的に言われるWin-Winの関係を顧客と築くこともできているかもしれません。
ただ、少なくとも私が今まで関わった案件は本当の意味でWin-Winだったのかなと感じます。
システムを作る人間は、次の段階を踏んで成長しているように思います。
第1段階 : とりあえず動くものを作る
第2段階 : システムはどうやったら動くかを考える
第3段階 : システムとはどうあるべきかを考える
第4段階 : 顧客にとってシステム開発はどうあるべきか考える
第5段階 : 方式論、方法論までシステム開発を昇華する
自分もずっとこんな考え方で、システムを技術的にどうすればよいかとか、システムはこうだと使いやすいとか、それを先に考えたりしていました。
我々SIerが言うWin-Winってきっと、本当は納品時点でのことかなと思います。もしくは、SIerにとってもっとおいしいWin-Winの形態って、運用保守までをそのSIerが担当することなんだと思います。
それは当然ビジネスなので当たり前なのかと思います。要はビジネスはどうやってお金を稼いでいくかにつながっています。Win-Winでありながらも自社にお金が継続的に入るビジネスモデルはありがたく、かつ利益の計算もしやすいものですし、顧客もアウトソーシングとまでは行かなくても、保険と同じようなものです。
これは決してWin-Winではなかった案件だと思いますが、私はたった一度だけ、要件定義から保守フェーズまで一貫して案件に関係したことがあります。
B2Cの案件で、開発はそこまで運用までは考えていませんでしたが、システムを作る人間以外が新しく何か画面を作るとき、本当に何も考えなくても作れるようにしてしまいました。
画面上のあらゆるものが部品化され、その部品すらも複数が部品化され、さらにそれが画面レベルまできたとしても画面までも部品化されていました。似たような画面を作るとき、その画面を継承して、ちょっと文言の定義を変更して、入力欄が違っても、画面でちょっと部品を追加すると、バリデーションチェックまでできます。
業務ロジックもパラメータが可変で、入力数は可変でもしっかり関連チェックされ、DBのモデルも可変であることを考慮していました。性能面もセキュリティも考慮したりもしていますが、新規で作る人は考えなくてもよっぽど変なことを無理やりしない限りは問題が発生しないようになっていました。
当然、システム開発においてここまで作り込めたらなかなかな気がします。
そして、最終的にはかなりの利益になった案件です。かなりの成功になりました。しかも、カットオーバーも問題なく、運用もほぼ問題なく進みました。そして客観的に見て使いやすさや品質もよく、顧客は満足しておりました。おそらくここまではSIerで言うところのWin-Winだったのかもしれません。
その後、どうやって作ったのか顧客から教えてほしいという話題になりました。
うちの営業は「抗議してもいいですよ」と言ってましたので、事前に上司に講義内容を決め、資料もOKをもらったあと、私が顧客の技術部門に数回講義しました。
日本人ではありませんでしたが、たった数回の講義、1回1時間の講義で彼らはプログラムもできたので、新規に画面が顧客からの要望案件がありましたが、彼らが1日で作ってしまいました。テストも1日ちょっとでした。要は、私たちが作ると営業から「10日はかかりますね〜」と持ちかけたけれど、実際は2日で作れてしまいました。
その後、その案件に関しては彼らは「自分たちで運用でき、新規の開発もできますので、御社からのサポートは不要ですよ」、と通知が来ました。もし新規案件が他にあればということで、並行で動いていた新規案件がありましたが、以降は大きな案件は発生しませんでした。
でも、もし難しくつくっていれば、彼らは自分たちで運用保守できなかったかもしれません。そうすれば、私たちに依頼が来たかもしれません。そうしたら、彼らは自社で作るよりもお金がかかったかもしれません。
では、彼らは自社で作るよりも他社に依頼したほうが安かったのか、私たちは簡単に作れるようにすべきだったのか、難しく作るべきだったのか。それとも顧客にはどんなことがあっても講義しないほうがよかったのか、それとも講義すべきだったのか、それとも中途半端な内容がよかったのか。
いったい、どれがWin-Winの関係になったのでしょうか。。。
私はWin-Winなんか考えるんじゃなく、顧客が真に使うシステム、いやいやではなく使い続けてもらえるシステムを作りたいです。
でも、今関わっている案件を踏まえて、確かに我社は利益を出せている案件もあります、一般的に言われるWin-Winの関係を顧客と築くこともできているかもしれません。
ただ、少なくとも私が今まで関わった案件は本当の意味でWin-Winだったのかなと感じます。
システムを作る人間は、次の段階を踏んで成長しているように思います。
第1段階 : とりあえず動くものを作る
第2段階 : システムはどうやったら動くかを考える
第3段階 : システムとはどうあるべきかを考える
第4段階 : 顧客にとってシステム開発はどうあるべきか考える
第5段階 : 方式論、方法論までシステム開発を昇華する
自分もずっとこんな考え方で、システムを技術的にどうすればよいかとか、システムはこうだと使いやすいとか、それを先に考えたりしていました。
我々SIerが言うWin-Winってきっと、本当は納品時点でのことかなと思います。もしくは、SIerにとってもっとおいしいWin-Winの形態って、運用保守までをそのSIerが担当することなんだと思います。
それは当然ビジネスなので当たり前なのかと思います。要はビジネスはどうやってお金を稼いでいくかにつながっています。Win-Winでありながらも自社にお金が継続的に入るビジネスモデルはありがたく、かつ利益の計算もしやすいものですし、顧客もアウトソーシングとまでは行かなくても、保険と同じようなものです。
これは決してWin-Winではなかった案件だと思いますが、私はたった一度だけ、要件定義から保守フェーズまで一貫して案件に関係したことがあります。
B2Cの案件で、開発はそこまで運用までは考えていませんでしたが、システムを作る人間以外が新しく何か画面を作るとき、本当に何も考えなくても作れるようにしてしまいました。
画面上のあらゆるものが部品化され、その部品すらも複数が部品化され、さらにそれが画面レベルまできたとしても画面までも部品化されていました。似たような画面を作るとき、その画面を継承して、ちょっと文言の定義を変更して、入力欄が違っても、画面でちょっと部品を追加すると、バリデーションチェックまでできます。
業務ロジックもパラメータが可変で、入力数は可変でもしっかり関連チェックされ、DBのモデルも可変であることを考慮していました。性能面もセキュリティも考慮したりもしていますが、新規で作る人は考えなくてもよっぽど変なことを無理やりしない限りは問題が発生しないようになっていました。
当然、システム開発においてここまで作り込めたらなかなかな気がします。
そして、最終的にはかなりの利益になった案件です。かなりの成功になりました。しかも、カットオーバーも問題なく、運用もほぼ問題なく進みました。そして客観的に見て使いやすさや品質もよく、顧客は満足しておりました。おそらくここまではSIerで言うところのWin-Winだったのかもしれません。
その後、どうやって作ったのか顧客から教えてほしいという話題になりました。
うちの営業は「抗議してもいいですよ」と言ってましたので、事前に上司に講義内容を決め、資料もOKをもらったあと、私が顧客の技術部門に数回講義しました。
日本人ではありませんでしたが、たった数回の講義、1回1時間の講義で彼らはプログラムもできたので、新規に画面が顧客からの要望案件がありましたが、彼らが1日で作ってしまいました。テストも1日ちょっとでした。要は、私たちが作ると営業から「10日はかかりますね〜」と持ちかけたけれど、実際は2日で作れてしまいました。
その後、その案件に関しては彼らは「自分たちで運用でき、新規の開発もできますので、御社からのサポートは不要ですよ」、と通知が来ました。もし新規案件が他にあればということで、並行で動いていた新規案件がありましたが、以降は大きな案件は発生しませんでした。
でも、もし難しくつくっていれば、彼らは自分たちで運用保守できなかったかもしれません。そうすれば、私たちに依頼が来たかもしれません。そうしたら、彼らは自社で作るよりもお金がかかったかもしれません。
では、彼らは自社で作るよりも他社に依頼したほうが安かったのか、私たちは簡単に作れるようにすべきだったのか、難しく作るべきだったのか。それとも顧客にはどんなことがあっても講義しないほうがよかったのか、それとも講義すべきだったのか、それとも中途半端な内容がよかったのか。
いったい、どれがWin-Winの関係になったのでしょうか。。。
私はWin-Winなんか考えるんじゃなく、顧客が真に使うシステム、いやいやではなく使い続けてもらえるシステムを作りたいです。
2011年04月11日
MS-Access バージョン管理ツール Ver 0.1.4
今日は急遽バグを修正しました。が、
明日早いのであんまりテストできていないです。
一応人柱上げです。明日テストしてみます。
急遽必要でダウンロード出来るようにしています。
ダウンロードはこちらからです。
もし問題があればすぐに修正し、新しいバージョンをアップします。
※ とはいえ、明日夜から仕事で打ち合わせが。。。
すみませんが、よろしくお願いします。
明日早いのであんまりテストできていないです。
一応人柱上げです。明日テストしてみます。
急遽必要でダウンロード出来るようにしています。
ダウンロードはこちらからです。
もし問題があればすぐに修正し、新しいバージョンをアップします。
※ とはいえ、明日夜から仕事で打ち合わせが。。。
すみませんが、よろしくお願いします。
2011年04月10日
MS-Access バージョン管理ツール Ver 0.1.3
今日はもう一件。
MS-Accessのバージョン管理ツールをバージョンアップしました。
ダウンロードはこちらからです。
まれに検索結果で古いページのみ見て、
古いバージョンをダウンロードしている方がおり、
最新が分かりにくいなぁと反省しております。
しっかりとしたページを作ります。
それまですみませんが、ブログにての通知でよろしくお願いします。
古いリンクも最新が落ちるように修正しました。
MS-Accessのバージョン管理ツールをバージョンアップしました。
ダウンロードはこちらからです。
まれに検索結果で古いページのみ見て、
古いバージョンをダウンロードしている方がおり、
最新が分かりにくいなぁと反省しております。
しっかりとしたページを作ります。
それまですみませんが、ブログにての通知でよろしくお願いします。
古いリンクも最新が落ちるように修正しました。
再び小石川後楽園デート
今日は久しぶりに奥様と小石川後楽園へ花見に行きました。
枝垂れ桜はさすがにだいぶ散っておりましたが、
まだまだ他の桜はたくさん咲いてました。
久しぶりにデートできてとても楽しかったです。
ぜひともまた一緒に行きたいです。
六義園の枝垂れ桜はもう散ってしまったようですが、
六義園の桜もみたいです。
今年の中野の桜は、まだまだ元気です。
哲学堂まですごいと思いますので、そちらも観に行きたいです。
枝垂れ桜はさすがにだいぶ散っておりましたが、
まだまだ他の桜はたくさん咲いてました。
久しぶりにデートできてとても楽しかったです。
ぜひともまた一緒に行きたいです。
六義園の枝垂れ桜はもう散ってしまったようですが、
六義園の桜もみたいです。
今年の中野の桜は、まだまだ元気です。
哲学堂まですごいと思いますので、そちらも観に行きたいです。
2011年03月31日
MS-Access バージョン管理ツール Ver 0.1.2
こんばんは。
MS-Accessバージョン管理ツールのバージョンアップを実施しました。
実装機能のひと通り動作確認を実施できました。
また、ウィンドウのリサイズに登録しました。
ダウンロードはこちらからどうぞ。
よろしくお願いします。
MS-Accessバージョン管理ツールのバージョンアップを実施しました。
実装機能のひと通り動作確認を実施できました。
また、ウィンドウのリサイズに登録しました。
ダウンロードはこちらからどうぞ。
よろしくお願いします。
MS-Accessバージョン管理ツールの更新 ver 0.1.1
MS-Accessのバージョン管理ツールの修正を少し実施しました。
ダウンロードはここから実施できます。
主な修正点は以下のとおりです。
・リストに更新日時を表示しました
・オブジェクト情報の取得方法をMSys〜から取得するよう変更しました
・インポート・エクスポートの途中でエラーがあると、処理が中断するので確認するように変更しました。
実はしっかり動かす余裕がなかったので未確認です。それでもよければダウンロードください。
すぐに0.1.2になると思いますが。。。
今日は坂本真綾さんのコンサートに行ってきました。とても素晴らしかったです。
奥様のお友達がチケットをとってくれたおかげです。
坂本真綾さん、奥様のお友達、奥様、本当にありがとうございます。
では、よろしくお願いします。
2011/03/31 ダウンロードパスの指定を間違えていましたので、修正しました。
ダウンロードはここから実施できます。
主な修正点は以下のとおりです。
・リストに更新日時を表示しました
・オブジェクト情報の取得方法をMSys〜から取得するよう変更しました
・インポート・エクスポートの途中でエラーがあると、処理が中断するので確認するように変更しました。
実はしっかり動かす余裕がなかったので未確認です。それでもよければダウンロードください。
すぐに0.1.2になると思いますが。。。
今日は坂本真綾さんのコンサートに行ってきました。とても素晴らしかったです。
奥様のお友達がチケットをとってくれたおかげです。
坂本真綾さん、奥様のお友達、奥様、本当にありがとうございます。
では、よろしくお願いします。
2011/03/31 ダウンロードパスの指定を間違えていましたので、修正しました。
2011年02月06日
MS-Accessでバージョン管理したい
中小企業は特に多いと思いますが、業務アプリをMS-Accessで作成することが多いと思います。
MS-Accessでは、1つのファイルに画面、帳票、DBといった機能を格納でき、そして簡単に作れてしまうところが魅力です。
もちろん、ファイルが壊れやすいというデメリットも多いのですが、設計だけでも使うという方も多いのではないでしょうか。(例えば、ERの設計や画面設計等)
そして、思った以上に本格的なものを作成することができます。
ですが、VSSを購入しなければバージョン管理できないという面があります。VSSを購入し、Accessにアドインを導入することで細かくフォームをバージョン管理できます。
ですが、私はSubversionやMercurialが好きなため、どうしてもVSSを使いたくなく、自分で何とかしたいなと前から考えていました。
考えた案は2つあり、いろいろとこの1年は試行していました。
1. 画面やDB、帳票のみAccessで設計し、業務処理(フォームやモジュール)の実装は、VBA以外で実行する
2. Accessのヘルプに出ていない機能を利用して、データをインポート･エクスポートする
1については、JavaからActiveX経由で実行する方法を検討しました。実はそれなりに動作するところまで実現できましたが、結局フォーム等はmdb単位になるため、あまり効果がなかったり、終了時等でのハンドリングが思ったよりも面倒で、保守性が低くやめました。
そこで2について、実現してみました。とはいえ、まだまだ作ってみたという段階でテストどころではありません。ですので、全くの保証外です。
直接バージョン管理できるものではなく、単にソースをインポート・エクスポートできるのみです。そのエクスポートしたファイルをコミットしたり、更新してmdbに更新しようというものです。
早めにTortoiseSVNとの連携と、リレーションにインポート・エクスポートに対応するつもりです。
また、今回は少し調査を目的としてライセンスを複雑にしました。ライセンスについては、このテキストを参照ください。
簡単に言えば、企業の方が利用する場合は事前に許可をとらない限りダウンロードはダメですというものです。許可をとればよいのみで、無償であるのは変りません。とはいえ、かなり厄介だとは思いますが、よろしくお願いします。
ダウンロードはここをクリックしてください。
まだまだ開発途上ですので、長い目でお待ちいただけたらと思います。
MS-Accessでは、1つのファイルに画面、帳票、DBといった機能を格納でき、そして簡単に作れてしまうところが魅力です。
もちろん、ファイルが壊れやすいというデメリットも多いのですが、設計だけでも使うという方も多いのではないでしょうか。(例えば、ERの設計や画面設計等)
そして、思った以上に本格的なものを作成することができます。
ですが、VSSを購入しなければバージョン管理できないという面があります。VSSを購入し、Accessにアドインを導入することで細かくフォームをバージョン管理できます。
ですが、私はSubversionやMercurialが好きなため、どうしてもVSSを使いたくなく、自分で何とかしたいなと前から考えていました。
考えた案は2つあり、いろいろとこの1年は試行していました。
1. 画面やDB、帳票のみAccessで設計し、業務処理(フォームやモジュール)の実装は、VBA以外で実行する
2. Accessのヘルプに出ていない機能を利用して、データをインポート･エクスポートする
1については、JavaからActiveX経由で実行する方法を検討しました。実はそれなりに動作するところまで実現できましたが、結局フォーム等はmdb単位になるため、あまり効果がなかったり、終了時等でのハンドリングが思ったよりも面倒で、保守性が低くやめました。
そこで2について、実現してみました。とはいえ、まだまだ作ってみたという段階でテストどころではありません。ですので、全くの保証外です。
直接バージョン管理できるものではなく、単にソースをインポート・エクスポートできるのみです。そのエクスポートしたファイルをコミットしたり、更新してmdbに更新しようというものです。
早めにTortoiseSVNとの連携と、リレーションにインポート・エクスポートに対応するつもりです。
また、今回は少し調査を目的としてライセンスを複雑にしました。ライセンスについては、このテキストを参照ください。
簡単に言えば、企業の方が利用する場合は事前に許可をとらない限りダウンロードはダメですというものです。許可をとればよいのみで、無償であるのは変りません。とはいえ、かなり厄介だとは思いますが、よろしくお願いします。
ダウンロードはここをクリックしてください。
まだまだ開発途上ですので、長い目でお待ちいただけたらと思います。
2011年01月09日
広告付きのゲーム
とあるジャンプの作家さん 大石浩二さん のコメントに「子供が手出しできない値段をつけないで欲しい」みたいなことが書かれていました。すでに家には最新号のジャンプ以外は捨ててしまったため詳細な文面は不明です。ごめんなさい。
それについて、私も同じ意見を持ちました。
少し作家さんの話とはそれますが、最近のゲームはやっぱり高いなぁと感じます。
とはいえ、簡単にゲームを購入できてしまうという環境ももしかしたら子供には悪影響なのかもしれませんが。。。
それはおいておいても、何とか安くできないかと考えてしまいました。
よくよく考えてみると、DSは画面が2つあります。なんだかんだで、2画面目はもてあましてしまっていることもあります。
そこで一方の画面は広告のみを常に表示させて、ゲーム会社は広告料で稼ぐことでゲームのお値段を下げられないものでしょうか。こういう意見はすでにあったりするかもしれませんが。。。すでにゲームもあるかもしれませんけど。。。
広告の内容はお父さん、お母さんが喜びそうなものから、子供のお菓子の広告など、値段は出せずとも商品の説明のみが常に表示され、気に入った広告をクリックすると詳細が出たり等です。
さらに、その広告に出てくるキャラクターを触ると、少し動いたりすると、アクションを探したりする楽しみも少しだけ出るかなとか思ったりします。
作家さんのお話は転売について言及されていたような気もしますが、新品のゲームについてもこういった形で安くするのもありなのかなと、最近の広告で稼ぐビジネスモデルを見ていると感じました。
(もしかしたら、任天堂が許可していないかもしれませんね。。。)
それについて、私も同じ意見を持ちました。
少し作家さんの話とはそれますが、最近のゲームはやっぱり高いなぁと感じます。
とはいえ、簡単にゲームを購入できてしまうという環境ももしかしたら子供には悪影響なのかもしれませんが。。。
それはおいておいても、何とか安くできないかと考えてしまいました。
よくよく考えてみると、DSは画面が2つあります。なんだかんだで、2画面目はもてあましてしまっていることもあります。
そこで一方の画面は広告のみを常に表示させて、ゲーム会社は広告料で稼ぐことでゲームのお値段を下げられないものでしょうか。こういう意見はすでにあったりするかもしれませんが。。。すでにゲームもあるかもしれませんけど。。。
広告の内容はお父さん、お母さんが喜びそうなものから、子供のお菓子の広告など、値段は出せずとも商品の説明のみが常に表示され、気に入った広告をクリックすると詳細が出たり等です。
さらに、その広告に出てくるキャラクターを触ると、少し動いたりすると、アクションを探したりする楽しみも少しだけ出るかなとか思ったりします。
作家さんのお話は転売について言及されていたような気もしますが、新品のゲームについてもこういった形で安くするのもありなのかなと、最近の広告で稼ぐビジネスモデルを見ていると感じました。
(もしかしたら、任天堂が許可していないかもしれませんね。。。)
