T'sWare Access(アクセス)・SQL Server・Web データベース開発

Access・SQL Server によるソフト開発ならおまかせください!

Access 29年の経験でご満足いただけるDBを提供します!

データベースの設計・開発からITの導入・活用までお手伝いさせていただきます

T'sWare ティーズウェア





Microsoft Access(アクセス)・SQL Serverによるソフト開発ならおまかせください!

T'sWare(ティーズウェア)では、みなさまのデータベースアプリケーションの設計・開発や、ITの導入・活用までお手伝いさせていただきます。

オーダーメイドのシステムを短納期・安価でお届けします。

古くなったシステムやExcel中心の業務をAccess版にリニューアルいたします。

スタンドアロンのAccessシステム開発からSQL Server対応のクライアントサーバーシステム開発、技術サポート支援など、Accessに関する広範なご支援をいたします。

なぜAccess(アクセス)なの?

Accessはリレーショナルデータベースです!データベースは大量のデータの保存や管理が得意です。

Accessでは、抽出や検索などの操作によってさまざまな角度から情報を取り出したり整理したりすることができます。

Excelなどで作った既存のデータをAccessでも活用することができます。

1つのマスタデータをさまざまな場面で再利用することができます。たとえば「顧客マスタ」データがある場合、それを見積書、売上伝票、請求書、納品書、領収書、宅配便伝票、タックシールなど、それぞれに顧客データを入力する手間なく、効率的に事務的業務を行えるようになります。

Accessはデータベースソフト開発用のソフトです! 画面や帳票を簡単にデザインすることができます。

簡易的な開発が可能である一方、出来上がったソフトの外観や機能はけっしてVisual Basicなどで作ったものに引けを取りません。

ほとんど機能を独自に組み込むVisual Basicなどによるソフト開発と異なり、Accessには、データの操作や編集に関わるさまざまな機能が初めから用意されています。そのため、新たにそれらの機能を開発する必要がありません。

VBA(Visual Basic for Applications)を使ったプログラミングによって、より高度な仕組み作りもできます。Accessというと簡易的なデータベースシステム用のソフトのように思われるかもしれませんが、VBAによって実用性には事欠かないシステム構築が可能です。

データを保存するテーブルや、抽出などを行うクエリ、入出力画面を作成するフォーム、帳票を作成するレポートなど、データベースシステムの開発に必要な環境をすべて兼ね備えています。簡単なユーザーインタフェースによって開発できます。

Access(アクセス)なら安く開発できる

基本的な画面作りや帳票作りは、非常に優れた開発用インタフェースの中で行います。マウスを中心とした非常に簡便な作業でデザインすることができますので、大幅に開発時間を短縮させることができます

画面作りや帳票作りは、多くの場合Visual Basicなどと似たような開発手順となります。しかし、データベースに保存されたデータを扱う処理については、Access自体が多くを標準で持っていますので、改めて開発する手間が少なくて済みます。プログラムやSQL文は必ずしも必要ではありません。そのため、開発時間が少なくて済みます。

T'sWareでは、長年の経験から、多くのAccess開発におけるノウハウを持っています。それらの蓄積されたノウハウやテクニックを再利用することによって、より短時間での開発が可能となっています。

システム仕様書や操作説明書などのドキュメントが不要ならさらに安価にご提供できます。操作説明書不要のインタフェースを心がけて作成します。

Access(アクセス)ならカスタマイズが容易

開発が比較的容易ということは、あとで機能を追加したり変更したりすることも容易です。

業務の拡張などに合わせて徐々にカスタマイズによる機能アップを図れば、費用投資も効率的に行えます。

Accessの場合、画面や帳票の外観など、プログラミング言語をよく知らなくてもカスタマイズできる部分がたくさんあります。ExcelやWordの作図操作の要領で、データ入力欄を追加したり、色や配置などを変更することが簡単にできます。

Access(アクセス)なら拡張性も十分

Accessでは、スタンドアロンのシステムなら十分なパフォーマンスを持ったシステム開発が可能です。

さらに、データだけをサーバー側に置くことによって、LAN上での複数のユーザー(パソコン)でデータを共有してのシステム運用も可能です。

さらにユーザー数やデータ量が増えてきてパフォーマンスが落ちてきたと思ったら、SQL Serverなどの本格的データベースシステムをバックエンドとしたシステムへと拡張(いわゆるアップサイジング)することができます。

Accessのプログラミングによって機能拡張することによって、インターネットとのデータのやり取りも可能です。またVPNのようなインターネットを使った社内ネットワークによって、遠隔地のデータを共有することもできます。

さらに出先など広範囲でのデータ共有にはクラウドのサービスを利用することもできます。クライアントはAccess、クラウド上にAccessのテーブル(できればSQL Serverがベター)を置いて運用することができます。

AccessとSQL Serverの関係

Accessは、パーソナルあるいは小規模ビジネス向けのデータベース管理ソフトです。データを保存・管理することはもちろん、その入出力用の画面や帳票といったユーザーインタフェースも簡単に作れるのが特徴です。また、そのファイルを配置するだけで、1台〜数台のパソコンでデータを共有しながら画面や帳票を扱うことができます。ただし複数のパソコンでデータ共有する場合、「ファイル共有型」ですので、ネットワークを流れるデータ量が多くパフォーマンスに劣るという弱点があります。

一方、SQL Serverはデータの管理や処理に特化したデータベース管理システムです。障害に対しても強固で、データ管理についてはAccessより高度で安定したサービスを提供します。また、多くのデータ処理をサーバー側で行うため、ネットワーク利用時のパフォーマンスが期待できます(いわゆる「クライアントサーバー型」の仕組みを作れます)。ただ、Accessの単なる上位版のような位置付けのものではまったくありません。画面などを作る機能はありませんので、やはりAccessなどのクライアントソフトをユーザーインタフェースとして利用する必要があります。

新規に開発するならAccessの基本的なシステムから始めることをお奨めしますが、すでにAccess単体でアプリケーションを導入・運用されている場合、次のような問題が起きてきたらAccessからSQL Serverへの移行(アップサイジング)を検討すべきタイミングです。

ただし、AccessからSQL Serverにアップサイジングすれば簡単に何もかも良くなるとは限りません。T’sWareでは、お客様の状況やニーズに応じた移行を検討&支援します。

SQL Serverへのアップサイジングのステップ

「Accessは簡単で安価に開発できるが大したことはできない」、「SQL Serverは高価だが高速・高機能である」は間違いです!。うまく使えばAccessでも十分ビジネスユースに耐え得ることができますし、SQL Serverも使い方を間違えればその能力を十分に活かすことはできません。

またシステム開発においても、”SQL Serverを使う”と言っただけで高価になりがちですが、実は、AccessからSQL Serverへの移行は、動作状況や運用形態、あるいは予算に応じて徐々にステップアップしていくことが可能です。Accessだけで十分かもしれませんし、また新規開発の時点からSQL Serverをメインに置いた開発を行う必要はありません。

T'sWareでは、いきなりSQL Serverをフルに使った高価なシステム提案ではなく、お客様のご予算やAccessだけの現状システムの問題点を勘案しながら、次のようなステップでのアップサイジングをご提案しています。STEP1→4の順で開発費はアップしますが、改善効果も高くなります。


STEP1:Accessだけでデータ共有する
Accessはファイル共有型のデータベース管理システムです。数人のワークグループの小規模なものなら、SQL Serverは使わずAccessだけでネットワーク上でデータを共有することができます。もしこれまでスタンドアロン(1台のパソコンのみ)で使っていたデータベースをみんなで使うようになり、かつデータ共有だけが目的なら、まずはこのステップを検討します。費用的にもかなり安価です(ただし複数ユーザーによる処理の競合を避けるための改造が必要になることもあります)。
Accessだけでデータ共有する
また、SharePoint OnlineやSharePoint Serverを利用することで、Accessのテーブルをリストとしてクラウド上に保存し、インターネットを介してクライアントのAccessからデータを共有するという構成も可能です。
クラウドを使ってデータ共有する

STEP2:テーブルだけSQL Serverに移行する
Accessで生データが保存される場所である「テーブル」だけをSQL Server上に移行します。データベースでは何よりも”データ”が大切ですので、安定性・障害性に優れたSQL Serverもしくはサーバーマシン上にデータを置くことによって、目的によってはこれだけでも効果が見込めます。パフォーマンス的には大幅な改善は見込めないこともありますが、データの保管あるいは共有という面で安定した環境を得ることができます。STEP1の状態からの移行であれば、単にテーブルを移すだけですので、費用的にも比較的安く実現できます。
テーブルだけSQL Serverに移行する

STEP3:クエリやバッチ処理などをSQL Serverに移行する
選択クエリ・アクションクエリ、あるいはVBAのプログラムを使って行っていたバッチ的なレコード処理をSQL Serverに移行します。具体的には、Accessの「クエリ」や「VBA」の処理の一部もしくは全部をSQL Serverの「ビュー」や「ストアドプロシージャ」、「ストアドファンクション」といったものに移行します。これによって、さまざまな処理がSQL Serverの置かれたサーバーマシン上だけで行われるようになり、ネットワーク上を流れるデータ量が抑えられ、結果として処理時間を短縮したりレスポンスを改善したりすることができます。特にアクションクエリなどで大量のデータを一括処理していたような場面では、大幅なスピードアップが期待できます。
クエリやバッチ処理などをSQL Serverに移行する

Access 2013以降、SQL Serverの利用に特化したファイル形式である『Accessプロジェクト(.adp)』は利用できなくなりました。パフォーマンス的には若干落ちますが、旧来の方法で、SQL Serverのストアドプロシージャ等を効率的に利用した別の方法での対応が必要となります。
そこで、すでにAccessプロジェクト(.adp)で運用されているデータベースについて、SQL Server上の資産は残したまま、Accessデータベース側を「.adp」から「.accdb」に作り直す作業のご依頼も受け付けております。

【.adp → .accdb化のポイント】

T'sWareにできること

T'sWareではAccessに関するさまざまなご依頼を受け付けております。大規模なシステム開発に限りません。画面1ケの開発・ボタン1ケのプログラミング実装からもご支援させていただきます。

大規模なシステム開発に限りません、画面1ケの開発からもご支援させていただきます!

開発担当者がいなくなってしまった、社内開発に行き詰ってしまった、そのようなニーズにも対応いたします!

動作環境やご要望など、必要に応じてAccess以外での開発も承ります。

部分開発やワンポイントアドバイスにも対応します

データベースの全部を開発してもらう必要はないという方には、ワンポイントテクニカルアドバイスや部分開発もお受けしております。

データベースを実際に変更するためのアドバイスだけでなく、Access利用のメリットやExcelから移行のメリットなど、Access全般についての疑問にもお答えします。

次のようなことでお困りの方、ぜひ一度お気軽にご相談ください。


内容や複雑度によって変わりますが、基本料金として3,000円/件〜にてお請けいたします。

メールで即座に回答できるようなご質問については3,000円/1件、実際にその環境を構築して動作確認したり、テスト開発が必要となったりするものについては、適宜金額がアップいたしますが、事前にご予算も考慮しお見積りいたします。

基本的にはメールでのやりとりによる対応となりますが、ご要望に応じて電話での質疑応答にて対応させていただきます。

開発費を抑える方法お教えします

受託のシステム開発は市販のパッケージのように”買ってきて使うだけ”という訳にはいきません。依頼する側・される側お互いにシステムの内容を考え意思疎通を図ることが大切です。そしてそれはシステムを安く作ることにも繋がります。そこで、Accessのデータベースアプリケーション開発を外部業者に依頼する際の、”依頼する側”にとっての、システム開発費用を抑えるための方法をお教えします。

機能を仕分ける
「システム開発にはいくらでもお金がかけられる」、「いくらお金がかかってもこれを作りたい」ということはなかなかないものです。予算的な制約の中でできるだけ安くかつ要望に沿ったシステムを作りたいというのが多くのケースではないでしょうか?。

そのような場合、やはり単に必要な機能を並べただけでは、見積り結果に対するリアクションも取りにくいものです。あらかじめ構想段階あるいは見積り依頼する時点で要望となる機能を仕分けし、その重要度や費用対効果の基準でランク付け(導入の優先順位の設定)をしておくと、予算と見積りに差異が出たとき、特に予算に制限がある場合には対応がしやすくなります。

それにはまず、要望となる機能をリストアップします。各担当者の意見などを取り入れながら、抜けのないように何が自社に必要なのかを整理します。その上で、「絶対に必要な機能」、「なくても何とかなるがあると便利な機能」、「必須ではないができれば付けておきたい程度の機能」といったように分類を行っておきます(もちろん見積り依頼する際にはそのすべてを提示するのですが)。

その際のひとつの着眼点として、機能の利用頻度を考えます。たとえば、システム導入時には「現在Excel上で管理している既存のデータを取り込みたい」と考えるのが自然です。しかしそれが本当に導入時のことだけであれば、あえて「Excelデータの取り込み機能」などは付ける必要はありません。マニュアル操作でデータ移行できるからです。ただし、決算処理のように、年に数回しかないが重要という場合もありますので、単純に頻度だけでなくその重要度もひとつの尺度としてみることも大切です。

また、必要と思われる機能でも、その代替案がないか検討することも必要です。たとえば、「画面に表示されたデータをExcelに出力したい」という要望があるかもしれません。利用頻度が非常に高ければそのような機能をシステムに組み込んでおき、ボタンのクリックひとつで実行できれば確かに作業は効率的です。しかし、その画面からデータを範囲選択してコピー、Excelのワークシートに貼り付けるということもできますので、ケースによってはシステム機能から除外しても何とか対応できるはずです。

また、Accessでアプリケーションを開発する場合、Access自体が元から持っているさまざまな機能をすることで、わざわざそれをプログラム等で作らなくて済む場合があります。たとえば、画面上のデータを並べ替えたり簡単なフィルタリング(抽出)を行ったりするだけなら、ボタンのクリック等で実行されるような仕組みにしなくても、マニュアル操作である程度は対応できる部分も多々あります

なお、必要な機能であっても、細かい外観的なこと(たとえば色や罫線等)など、機能性や操作性そのものにあまり関係のない部分までは要求仕様に盛り込まない方がよいでしょう。
仕様を任せきりにしない
自社の業務に一番精通しているのは、何よりもシステム開発を「依頼する側」に他なりません。自分達にとって必要なものを自ら進んで提示していかないと、意志疎通が図れず思った通りのものができないだけでなく、業務分析やヒアリング調査などを行う必要も出てきたり、設計や開発に余分な時間を要したり、つまりその分だけコスト高になってしまうことがあります。また、あまりに要望が曖昧だと、あとからの仕様変更や追加に備えた保険とも言える金額が上乗せされてしまう場合もあります。

したがって、外部が作るからといってその仕様を任せきりにするのではなく、自分でできる範囲で十分ですので、何が欲しいか何をやりたいかをしっかり整理し提示することが重要です。

その際、何も本格的な“要求仕様書”といったものは必ずしも必要ではありません。要するに他人に自分の考えを伝えられればよいのです。手書きで要望する画面のイメージを伝えるのでも十分です。また考えた要望点をワープロ等でリスト化するだけでも十分です。そういったものがあれば、お互いにそれを叩き台として細かい仕様を相談しながら詰めていくきっかけになります。

ただしその際に留意点があります。あくまでも「使う側にとっての要望」を列挙するということです。画面や帳票のデザインなどは、本当に必要な点は除いて、「作る側」に委ねることも費用を抑える要因となります。どこまで要求するかどこから任せるか、なかなか分岐点の判断は難しいところですが、まずは希望を相手になるべく分かりやすく伝えて、開発者側とやり取りしながら相談していけばよいでしょう。開発者側が疑問に思えば質問に回答していけばよいのです(ただし複雑な計算をしないと算出できないような部分についてはExcelで例示するなどしてできる限り詳しく伝えた方がよいでしょう)。
開発の難易度を勝手に判断しない
システム開発やプログラミング経験、あるいは外部業者への開発依頼の経験があれば、“このくらいのシステムならいくら位が相場”というのが分かります。しかしそうでない場合はシステム開発がいくら位かかるものなのか想像もつかないかもしれません。

そのような場合のひとつの注意点は、作るのは簡単あるいは難しいだろうと思い込みで判断しないということです。「これならExcelでもできるくらいだから安いだろう」とか「これは凝った処理だから高いに違いない」と思い込んで、はじめから仕様にたくさん盛り込んだり、あるいは逆に仕様から削ったりしてしまわないようにしましょう。

とりあえずは、あくまでも必要なものは必要ということで希望の仕様を提示し、その見積り結果が予算をオーバーするようなら、“どの機能を削れば予算内に収まるか?”という相談をあとからすればよいのです。

たとえば、Accessによる開発の場合、帳票の数はもちろん少ないに越したことはありませんが、たとえばほとんど同じデザインで並べ替え方が違うだけのようなものなら費用はさほどかかりません。古いAccessのバージョンではプログラムを組んで処理しないといけないというものでも、新しいバージョンなら設定ひとつでそれが実現できてしまうということもあります。また、すべて自分で作るとなると大変な労力やプログラム知識が必要と思えるような機能でも、開発依頼先が“他社向けにこれまで何度も似たようなものを作っている”というものであれば、それを流用することで安くできる場合もけっこうあります。そのように、見た目から想像される開発難易度と作る側の難易度は必ずしも一致しないということはよくあることです。ただし、たとえばExcelと同じような操作性をAccessで作るシステムに求めるなど、「絶対ムリ」あるいは「それだけのために相当金額がかかる」という逆のケースもあるのも事実です。
要望はあとから追加しないよう吟味する
とりあえず作ってもらい、「細かいところはあとから変更してもらえばいい」という考えはしない方がよいでしょう。あとから、もしくは途中で追加・変更する場合、中には簡単に変更できる場合も少なくありませんが、それまで作った大半のものが使えずほとんど作り直しになってしまうということもあり得ます。

もし当初の契約時の仕様になかった内容である場合、追加費用が発生するのはもちろんですが、はじめから仕様に入れておけば他の仕様に込み、つまり実質的にタダで作れたのにということもありますし、はじめからいっしょに作ればかなり安くできたのに、ということもけっして少なくありません。

そのようなことのないよう、事前の要望の整理、見積り仕様の確認などは十分に行っておくべきです。どんな出来映えになるのか分からない部分があるとき、あるいは完成後の操作性などで疑問があるときは、開発者側に十分に確認しておきましょう。また特に、社内でそのシステムの利用者が多い場合や厳しいチェックがなされる場合には、担当者ごとの要望に抜けのないようにするとともに社内の意見統一を図っておくことが大切です。

あとからの追加要望は、費用的に依頼者側に異議がないのであればよいのですが、費用的なものだけなく、お互いに嫌な思いをすることになりかねません。
自分であまり作り込まない
ExcelやAccessでシステムを作る場合、その大きな利点は誰でもそれなりのものが意外と出来てしまうということです。そのような場合、最後まで自社でやってしまうのであれば何ら問題はありません。あるいはほんの一部だけ難しくてできないので外部に依頼するというのであればさほど費用もかからないでしょう。

しかし、かなりの部分まで作り込んでいて、あとになって大量の機能が未開発で残っている状態で外部に継続開発を依頼する場合はいろいろ問題が発生します。

誰が作るにしても、多少自己流になるのは致し方ありません。しかし、あまりに複雑に作り込んだものを変更依頼する場合、やはり他人がそれを変更するわけですから、「最初から作った方が早い」となってしまい、それまでやったことがムダになってしまうこともあります。また、「現在の中味がどのようになっているか、解析に時間と費用がかかる」ということもあり得ます。また、変更作業を終えたあと、その変更によってそれまであった機能に何らかの悪影響を与えていないかチェックしなければいけないということで、テストに要する時間も費用にプラスせざるを得ない場合もあります。

そのような開発を依頼された側にもやはり自分なりのやり方というものがあります。普段から使っている方法で作ったり過去に作ったものを流用したりした方が当然早くすなわち安く作ることができます。したがって、もしもはじめから最終的に外部に開発を依頼する予定であったり、その可能性があったりするのであれば、自社内ではあまり深いところまでは作り込まず、細かい部分についてはある程度依頼先に任せた方が得策です。あるいは要望仕様の検討の方に時間をかけて、はじめから外部委託を前提とした方がよいかもしれません。

ただし、「こんなイメージのものを作りたい」という試作品程度のつもりで作って、本格的な開発は全面的に外部に依頼するというのであれば、むしろ要望を具体的に依頼先に伝えられるので、よい方法かもしれません。

また、かなり出来上がったものであっても、たとえば「○○画面と同じようなパターンで別の画面を追加して欲しい」といった場合や、「画面や帳票のデザインだけは全部出来ているがプログラム部分はまったく手付かずなので全部任せたい」、「このデータをこのように使って新しい画面をつくって欲しい」と具体的な作成方法が示されているような場合には、元々の作り手(依頼する側の方)のやり方を見倣いながら同じような感じで作ることができるので、あまりプラスαの金額的なことは意識しないで開発することが可能です。
不必要なドキュメントは要求しない
基本的には「操作説明書などなくてもだいたい操作できる」というのがインタフェイスの理想です。さらには開発依頼時に画面の内容や操作方法などを要望して作らせているなら、なおさら操作説明書はいらないのではないでしょうか?。たかが操作説明書とはいえやはり作るには時間がかかります。どうしても必要でないなら、その分、開発費用を下げた方がお得なはずです。

また、操作説明書以外にも、システム開発に伴うドキュメントは多種多様にあります。作ろうと思えば何百ページでも何千ページでもできてしまいます。自社内で誰でもプログラムの内容が分かるようにしておきたいという場合もあるかもしれませんが、逆にそれに手を加えられるくらいの人ならそんなものはなくても解析できてしまうかもしれません。

「ドキュメント類はあって当然」、「何らかの書類があると安心」という声をよく耳にしますが、一方で納品された紙の多さだけに満足して結局誰も見たことも活用したこともないということも少なくないようです。システム本体と同様、ドキュメント類も使うことに意義があります。使う必要性がないならお金をかけてまで作る必要はありません。誰にも見られず書棚の肥やしにならないかその必要性をよく考えてみましょう。
保守・サポートはスキルを考えて
もしシステム運用を始めてから何かあったとき、サポートしてもらえるかどうかは重要です。しかし、初期導入時は別として、これといったトラブルもなく何年も動いているということも少なくありません。もしそうであれば、何もないのに毎月・毎年保守費用を払うのはもったいない話しです。

また、保守といってもシステム内容や規模によってまちまちです。契約時から言われるがままに任せっきりにするのではなく、どういった作業が定期的に必要なのか(してくれるのか)、どこまでが保守費用に含まれるのか、どういった部分は定期保守費用とは別にその都度料金がかかるのかなど、その内容を確認してから金額を吟味することも大切です。・・・・たとえば自動車であれば、点検作業料やオイル交換作業料は無料だがオイル代はその都度必要といった点検サポートがありますよね

また、その契約内容によっては、「ここまでなら社内の担当者のスキルで十分対応できる」ということもあるかもしれません。あるいは「トラブルが発生した都度サポート料金や修理代を払った方が安く済む」かもしれません。また、「システム改訂が多くありそうなので日常的に相談したい」といったようにサポートの頻度が高い場合もあれば、「問題なく動いていれば何もしてくれなくてよい」という場合もあるかもしれません。要するにサポートの発生頻度です。

ただトラブルの発生頻度や内容はなかなか予測できませんので、ある種の保険として考えてもよいのですが、その場合にもリスクと費用を勘案しながら、トータルで損の出ないようにある程度は自分なりに推測して保守費用を検討するとよいでしょう

どんなソフトを作るにも、要望を仕様書等の何らかの形でまとめることは重要です。しかし”仕様書”と聞くと『そんな専門的なものはできない』と考えていませんか?。でも実は簡単です。思い描いている画面ややりたいことを整理するだけです。
『ではどんな風に書けばいいの?』とお思いの方、下記をクリックしてその例をご覧ください。

簡単な要望仕様のまとめ方の例
既存のソフトウェアを変更する場合のまとめ方の例

お見積り/ご相談


Webフォームでのお問い合せWebフォームでのお問い合せ   メールでのお問い合せメールでのお問い合せ


商談からお支払いまでの流れ

※開発関係の費用につきましては、データベースの内容や規模によって大きく変わるため、概要仕様打ち合わせ後に正式にお見積りさせていただきます。まだ構想段階であればまずは概算にてお見積りいたします。
※開発期間や時期、規模などによってはお断りすることもございます。あらかじめご了承ください。


T'sWare(ティーズウェア:代表 星野)がご相談に対応させていただきます。

T'sWareは個人事業として活動しています。パソコン1台のシステムから小中規模のネットワークシステム、各種制御機器やバーコードリーダーなどとパソコンをつないだシステムなど、多業種・多業務に渡るソフトウェア開発業務を長年に渡って行っております。また、データベースソフト(Microsoft Access)のライターとして、書籍執筆や雑誌連載を手掛けてまいりました。そのような経験を活かし、皆さまの仕事をITの面からバックアップいたします。

ご紹介PDF  プロフィール  T'sWareのトップページ


T'sWareロゴ
T'sWare ティーズウェア
https://tsware.jp/ t.hoshino@tsware.jp

なぜAccessなの? AccessとSQL Server T'sWareにできること 部分開発やアドバイス 開発費を抑える方法 お見積り/ご相談

ページ先頭へ