Access 2013以降、SQL Serverの利用に特化したファイル形式である『Accessプロジェクト(.adp)』は利用できなくなりました。パフォーマンス的には若干落ちますが、旧来の方法で、SQL Serverのストアドプロシージャ等を効率的に利用した別の方法での対応が必要となります。
そこで、すでにAccessプロジェクト(.adp)で運用されているデータベースについて、SQL Server上の資産は残したまま、
Accessデータベース側を「.adp」から「.accdb」に作り直す作業のご依頼も受け付けております。
【.adp → .accdb化のポイント】
- SQL Server上のテーブル・ビュー・ストアドプロシージャ等はそのまま継続利用する
- Access側のフォームやレポートなどのオブジェクトはそのまま受け継ぐ
- Access側のプログラムは”ADO”を継続利用する
- リンクテーブル化は必要最小限にとどめる
- 選択クエリなどはできる限りパススルークエリを利用する
- パラメータを持ったフォームでは、その基準を継承し、ローカルへの転送量を極力抑える
- [サーバー]-[接続]メニューと同等の機能を独自に実装する
- その他.....
機能を仕分ける
「システム開発にはいくらでもお金がかけられる」、「いくらお金がかかってもこれを作りたい」ということはなかなかないものです。予算的な制約の中でできるだけ安くかつ要望に沿ったシステムを作りたいというのが多くのケースではないでしょうか?。
そのような場合、やはり単に必要な機能を並べただけでは、見積り結果に対するリアクションも取りにくいものです。あらかじめ構想段階あるいは見積り依頼する時点で要望となる機能を仕分けし、その重要度や費用対効果の基準でランク付け(導入の優先順位の設定)をしておくと、予算と見積りに差異が出たとき、特に予算に制限がある場合には対応がしやすくなります。
それにはまず、要望となる機能をリストアップします。各担当者の意見などを取り入れながら、抜けのないように何が自社に必要なのかを整理します。その上で、「絶対に必要な機能」、「なくても何とかなるがあると便利な機能」、「必須ではないができれば付けておきたい程度の機能」といったように分類を行っておきます(もちろん見積り依頼する際にはそのすべてを提示するのですが)。
その際のひとつの着眼点として、機能の利用頻度を考えます。たとえば、システム導入時には「現在Excel上で管理している既存のデータを取り込みたい」と考えるのが自然です。しかしそれが本当に導入時のことだけであれば、あえて「Excelデータの取り込み機能」などは付ける必要はありません。マニュアル操作でデータ移行できるからです。ただし、決算処理のように、年に数回しかないが重要という場合もありますので、単純に頻度だけでなくその重要度もひとつの尺度としてみることも大切です。
また、必要と思われる機能でも、その代替案がないか検討することも必要です。たとえば、「画面に表示されたデータをExcelに出力したい」という要望があるかもしれません。利用頻度が非常に高ければそのような機能をシステムに組み込んでおき、ボタンのクリックひとつで実行できれば確かに作業は効率的です。しかし、その画面からデータを範囲選択してコピー、Excelのワークシートに貼り付けるということもできますので、ケースによってはシステム機能から除外しても何とか対応できるはずです。
また、Accessでアプリケーションを開発する場合、Access自体が元から持っているさまざまな機能をすることで、わざわざそれをプログラム等で作らなくて済む場合があります。たとえば、画面上のデータを並べ替えたり簡単なフィルタリング(抽出)を行ったりするだけなら、ボタンのクリック等で実行されるような仕組みにしなくても、マニュアル操作である程度は対応できる部分も多々あります。
なお、必要な機能であっても、細かい外観的なこと(たとえば色や罫線等)など、機能性や操作性そのものにあまり関係のない部分までは要求仕様に盛り込まない方がよいでしょう。
仕様を任せきりにしない
自社の業務に一番精通しているのは、何よりもシステム開発を「依頼する側」に他なりません。自分達にとって必要なものを自ら進んで提示していかないと、意志疎通が図れず思った通りのものができないだけでなく、業務分析やヒアリング調査などを行う必要も出てきたり、設計や開発に余分な時間を要したり、つまりその分だけコスト高になってしまうことがあります。また、あまりに要望が曖昧だと、あとからの仕様変更や追加に備えた保険とも言える金額が上乗せされてしまう場合もあります。
したがって、外部が作るからといってその仕様を任せきりにするのではなく、自分でできる範囲で十分ですので、何が欲しいか何をやりたいかをしっかり整理し提示することが重要です。
その際、何も本格的な“要求仕様書”といったものは必ずしも必要ではありません。要するに他人に自分の考えを伝えられればよいのです。手書きで要望する画面のイメージを伝えるのでも十分です。また考えた要望点をワープロ等でリスト化するだけでも十分です。そういったものがあれば、お互いにそれを叩き台として細かい仕様を相談しながら詰めていくきっかけになります。
ただしその際に留意点があります。あくまでも「使う側にとっての要望」を列挙するということです。画面や帳票のデザインなどは、本当に必要な点は除いて、「作る側」に委ねることも費用を抑える要因となります。どこまで要求するかどこから任せるか、なかなか分岐点の判断は難しいところですが、まずは希望を相手になるべく分かりやすく伝えて、開発者側とやり取りしながら相談していけばよいでしょう。開発者側が疑問に思えば質問に回答していけばよいのです(ただし複雑な計算をしないと算出できないような部分についてはExcelで例示するなどしてできる限り詳しく伝えた方がよいでしょう)。
開発の難易度を勝手に判断しない
システム開発やプログラミング経験、あるいは外部業者への開発依頼の経験があれば、“このくらいのシステムならいくら位が相場”というのが分かります。しかしそうでない場合はシステム開発がいくら位かかるものなのか想像もつかないかもしれません。
そのような場合のひとつの注意点は、作るのは簡単あるいは難しいだろうと思い込みで判断しないということです。「これならExcelでもできるくらいだから安いだろう」とか「これは凝った処理だから高いに違いない」と思い込んで、はじめから仕様にたくさん盛り込んだり、あるいは逆に仕様から削ったりしてしまわないようにしましょう。
とりあえずは、あくまでも必要なものは必要ということで希望の仕様を提示し、その見積り結果が予算をオーバーするようなら、“どの機能を削れば予算内に収まるか?”という相談をあとからすればよいのです。
たとえば、Accessによる開発の場合、帳票の数はもちろん少ないに越したことはありませんが、たとえばほとんど同じデザインで並べ替え方が違うだけのようなものなら費用はさほどかかりません。古いAccessのバージョンではプログラムを組んで処理しないといけないというものでも、新しいバージョンなら設定ひとつでそれが実現できてしまうということもあります。また、すべて自分で作るとなると大変な労力やプログラム知識が必要と思えるような機能でも、開発依頼先が“他社向けにこれまで何度も似たようなものを作っている”というものであれば、それを流用することで安くできる場合もけっこうあります。そのように、見た目から想像される開発難易度と作る側の難易度は必ずしも一致しないということはよくあることです。ただし、たとえばExcelと同じような操作性をAccessで作るシステムに求めるなど、「絶対ムリ」あるいは「それだけのために相当金額がかかる」という逆のケースもあるのも事実です。
要望はあとから追加しないよう吟味する
とりあえず作ってもらい、「細かいところはあとから変更してもらえばいい」という考えはしない方がよいでしょう。あとから、もしくは途中で追加・変更する場合、中には簡単に変更できる場合も少なくありませんが、それまで作った大半のものが使えずほとんど作り直しになってしまうということもあり得ます。
もし当初の契約時の仕様になかった内容である場合、追加費用が発生するのはもちろんですが、はじめから仕様に入れておけば他の仕様に込み、つまり実質的にタダで作れたのにということもありますし、はじめからいっしょに作ればかなり安くできたのに、ということもけっして少なくありません。
そのようなことのないよう、事前の要望の整理、見積り仕様の確認などは十分に行っておくべきです。どんな出来映えになるのか分からない部分があるとき、あるいは完成後の操作性などで疑問があるときは、開発者側に十分に確認しておきましょう。また特に、社内でそのシステムの利用者が多い場合や厳しいチェックがなされる場合には、担当者ごとの要望に抜けのないようにするとともに社内の意見統一を図っておくことが大切です。
あとからの追加要望は、費用的に依頼者側に異議がないのであればよいのですが、費用的なものだけなく、お互いに嫌な思いをすることになりかねません。
自分であまり作り込まない
ExcelやAccessでシステムを作る場合、その大きな利点は誰でもそれなりのものが意外と出来てしまうということです。そのような場合、最後まで自社でやってしまうのであれば何ら問題はありません。あるいはほんの一部だけ難しくてできないので外部に依頼するというのであればさほど費用もかからないでしょう。
しかし、かなりの部分まで作り込んでいて、あとになって大量の機能が未開発で残っている状態で外部に継続開発を依頼する場合はいろいろ問題が発生します。
誰が作るにしても、多少自己流になるのは致し方ありません。しかし、あまりに複雑に作り込んだものを変更依頼する場合、やはり他人がそれを変更するわけですから、「最初から作った方が早い」となってしまい、それまでやったことがムダになってしまうこともあります。また、「現在の中味がどのようになっているか、解析に時間と費用がかかる」ということもあり得ます。また、変更作業を終えたあと、その変更によってそれまであった機能に何らかの悪影響を与えていないかチェックしなければいけないということで、テストに要する時間も費用にプラスせざるを得ない場合もあります。
そのような開発を依頼された側にもやはり自分なりのやり方というものがあります。普段から使っている方法で作ったり過去に作ったものを流用したりした方が当然早くすなわち安く作ることができます。したがって、もしもはじめから最終的に外部に開発を依頼する予定であったり、その可能性があったりするのであれば、自社内ではあまり深いところまでは作り込まず、細かい部分についてはある程度依頼先に任せた方が得策です。あるいは要望仕様の検討の方に時間をかけて、はじめから外部委託を前提とした方がよいかもしれません。
ただし、「こんなイメージのものを作りたい」という試作品程度のつもりで作って、本格的な開発は全面的に外部に依頼するというのであれば、むしろ要望を具体的に依頼先に伝えられるので、よい方法かもしれません。
また、かなり出来上がったものであっても、たとえば「○○画面と同じようなパターンで別の画面を追加して欲しい」といった場合や、「画面や帳票のデザインだけは全部出来ているがプログラム部分はまったく手付かずなので全部任せたい」、「このデータをこのように使って新しい画面をつくって欲しい」と具体的な作成方法が示されているような場合には、元々の作り手(依頼する側の方)のやり方を見倣いながら同じような感じで作ることができるので、あまりプラスαの金額的なことは意識しないで開発することが可能です。
不必要なドキュメントは要求しない
基本的には「操作説明書などなくてもだいたい操作できる」というのがインタフェイスの理想です。さらには開発依頼時に画面の内容や操作方法などを要望して作らせているなら、なおさら操作説明書はいらないのではないでしょうか?。たかが操作説明書とはいえやはり作るには時間がかかります。どうしても必要でないなら、その分、開発費用を下げた方がお得なはずです。
また、操作説明書以外にも、システム開発に伴うドキュメントは多種多様にあります。作ろうと思えば何百ページでも何千ページでもできてしまいます。自社内で誰でもプログラムの内容が分かるようにしておきたいという場合もあるかもしれませんが、逆にそれに手を加えられるくらいの人ならそんなものはなくても解析できてしまうかもしれません。
「ドキュメント類はあって当然」、「何らかの書類があると安心」という声をよく耳にしますが、一方で納品された紙の多さだけに満足して結局誰も見たことも活用したこともないということも少なくないようです。システム本体と同様、ドキュメント類も使うことに意義があります。使う必要性がないならお金をかけてまで作る必要はありません。誰にも見られず書棚の肥やしにならないかその必要性をよく考えてみましょう。
保守・サポートはスキルを考えて
もしシステム運用を始めてから何かあったとき、サポートしてもらえるかどうかは重要です。しかし、初期導入時は別として、これといったトラブルもなく何年も動いているということも少なくありません。もしそうであれば、何もないのに毎月・毎年保守費用を払うのはもったいない話しです。
また、保守といってもシステム内容や規模によってまちまちです。契約時から言われるがままに任せっきりにするのではなく、どういった作業が定期的に必要なのか(してくれるのか)、どこまでが保守費用に含まれるのか、どういった部分は定期保守費用とは別にその都度料金がかかるのかなど、その内容を確認してから金額を吟味することも大切です。・・・・たとえば自動車であれば、点検作業料やオイル交換作業料は無料だがオイル代はその都度必要といった点検サポートがありますよね
また、その契約内容によっては、「ここまでなら社内の担当者のスキルで十分対応できる」ということもあるかもしれません。あるいは「トラブルが発生した都度サポート料金や修理代を払った方が安く済む」かもしれません。また、「システム改訂が多くありそうなので日常的に相談したい」といったようにサポートの頻度が高い場合もあれば、「問題なく動いていれば何もしてくれなくてよい」という場合もあるかもしれません。要するにサポートの発生頻度です。
ただトラブルの発生頻度や内容はなかなか予測できませんので、ある種の保険として考えてもよいのですが、その場合にもリスクと費用を勘案しながら、トータルで損の出ないようにある程度は自分なりに推測して保守費用を検討するとよいでしょう。
※開発関係の費用につきましては、データベースの内容や規模によって大きく変わるため、概要仕様打ち合わせ後に正式にお見積りさせていただきます。まだ構想段階であればまずは概算にてお見積りいたします。