グループウェア・Webデータベースの移行先を無料のOSSで

1. 長年使ってきたグループウェアやWebデータベースのサポート終了が決まり、移行の期限が迫っている
2. 各部署が作った業務アプリが何十・何百と残っていて、情報システム部門だけでは移しきれない
3. 移行先の候補は利用者の人数ごとの料金で、全社員が使うと費用が大きくなる
4. 添付ファイルやアクセス権限、作成者・作成日時まで、元のデータのまま移したい
5. 業務アプリを作り直すたびに、開発会社に費用と期間をかけて頼んでいる
6. 移行を機に、部署ごとにばらばらだった情報共有の決まりをそろえたい
7. 社内のデータを社外のクラウドに置けない

1. いまのシステムから書き出したCSVを、テーブルにインポートできます
2. 移行モードで取り込むと、作成者・作成日時・更新者・更新日時を、CSVの値のまま残せます（テーブルの管理で「移行モードを許可」を有効にしておきます）。更新の履歴そのものは取り込めません
3. インポートのキーを決めておけば、二度目以降の取り込みで、同じキーのレコードを更新できます。並行運用の期間に、差分を何度か取り込むときに使います
4. 添付ファイルは、レコード作成APIで、ファイルの中身ごと登録できます。ユニ・チャームでは、スクリプトで添付ファイルの移行を自動化しました
5. 文書ごとのアクセス権限は、レコードのアクセス制御に置き換えます。大量の文書の権限を一つずつ付け直すのが難しい場合は、移行のプログラムで権限ごと移します。トクヤマグループでは、権限の情報も一緒にデータ移行できる仕組みを開発元と作りました

いまのアプリの画面や仕組みを、そのまま自動で変換する機能はありません。項目と使い方を見て、テーブルとして作り直します。

プリザンターの業務アプリは、画面の設定だけで作れます。情報システム部門がすべてを作り直すのではなく、各部署の担当者が自分たちのアプリを作り直す形にすると、移行の期限に間に合わせやすくなります。

1. ＴＢＫでは、情報システム部門が定期的に研修を開き、研修を受けた部署の担当者が、欲しい業務アプリを自分たちで作っています
2. 作った業務アプリを台帳で管理し、誰が何を作ったかを情報システム部門が把握することで、ガバナンスを保っています
3. ユーザーどうしで教え合う文化も生まれました

社内で作れる人を育てるには、開発元のトレーニングも使えます。

例1：添付ファイルごと、文書を登録する（API）

いまのシステムから取り出した文書を、レコード作成APIで登録する例です。添付ファイルは、ファイルの中身をBase64に変えて、添付ファイル項目（AttachmentsA）に入れます。APIキーは事前に作成しておきます。

curl -X POST "http://{サーバ名}/api/items/{サイトID}/create" \
  -H "Content-Type: application/json" \
  -d '{
    "ApiVersion": 1.1,
    "ApiKey": "{APIキー}",
    "Title": "設備点検の手順書",
    "ClassHash": { "ClassA": "DOC-0123", "ClassB": "製造部" },
    "AttachmentsHash": {
      "AttachmentsA": [
        { "ContentType": "application/pdf", "Name": "手順書.pdf", "Base64": "JVBERi0xLjcK..." }
      ]
    }
  }'

マニュアル：レコード作成API／APIキー

例2：並行運用の間、差分を何度でも取り込む（API）

切り替えまでの間は、いまのシステムにもデータが増えます。upsert APIで、いまのシステムの文書番号（ClassA）をキーにすれば、同じ番号の文書は更新、無ければ新しく作成します。何度流しても、同じ文書が二重に登録されません。

curl -X POST "http://{サーバ名}/api/items/{サイトID}/upsert" \
  -H "Content-Type: application/json" \
  -d '{
    "ApiVersion": 1.1,
    "ApiKey": "{APIキー}",
    "Keys": ["ClassA"],
    "Title": "設備点検の手順書（改訂2）",
    "ClassHash": { "ClassA": "DOC-0123", "ClassB": "製造部" }
  }'

マニュアル：レコード作成・更新（upsert）API

1. 日本国内で開発されているオープンソース。Community Editionは、利用者の人数や期間の制限なく無料で使え、商用利用もできます。ユニ・チャームでは、全社員が使う情報共有の基盤として、人数ごとの料金がかからない点を評価しています
2. 自社のサーバー（オンプレミス）や、自社で管理するAWS・Azureなどに構築できます。いまのグループウェアと同じく、社内のネットワークの中で使えます
3. WindowsとLinuxのどちらでも動き、実行環境は.NET 10、データベースはPostgreSQL・SQL Server・MySQLから選べます。Dockerのコンテナでも動かせます

オンプレミスで使えるノーコード・Webデータベース
FAQ：動作環境や推奨スペック

1. 認証：LDAP認証（Active Directoryなど）やSAML認証で、社内のアカウントのままログインできます
2. 組織とグループ：アクセス権限に使う組織とグループを、社内の組織図に合わせて作ります
3. 困ったときに聞ける：有償の年間サポートサービスで、日々の操作や設定のQ&A、トラブル時のサポート、サンプルスクリプトの提供を受けられます。フジクリーン工業では、年間サポートを使いながら、自社で移行を進めました
4. 大規模な運用：全社で使うときの応答性能を支える大規模運用サポート機能を、年間サポートの契約プランに応じて使えます

移行の計画づくりや、データの移行のプログラムをまとめて頼みたい場合は技術支援サービスがあります。

サポートが終わるグループウェアやWebデータベースの移行先として、お客様にプリザンターを提案できます。利用者の人数ごとのライセンス料が無いので、全社員が使う仕組みでも費用を抑えた提案ができます。認定パートナー制度では、開発元の支援を受けながら、移行の支援やユーザーサポートを自社のサービスとして提供できます。

お客様の側で移行を任せたい場合は、150社を超える全国の認定パートナーから、業種や地域で探せます。

認定パートナー制度のご紹介
認定パートナーを探す

1. 試す：デモ環境で、いまの業務アプリと同じものを作れるか確かめます
2. 棚卸しする：いまの業務アプリの一覧を作り、移すもの・やめるものを決めます
3. 環境を用意する：本番のサーバーにインストールし、社内のアカウントでログインできるようにします
4. 作り直して移す：部署ごとにテーブルを作り、いまのデータを移行モードで取り込みます
5. 切り替える：並行運用の間は差分を取り込み、期限までに元のシステムを止めます

1. メール・スケジュール・掲示板などを含むグループウェアの機能一式を、一つの製品で置き換えたい：プリザンターは業務データベースの移行先です。メールやスケジュールは別のサービスを組み合わせます
2. いまのアプリを自動で変換したい：自動で変換する機能はありません。テーブルとして作り直します
3. 1人の利用者を複数の組織に所属させたい：プリザンターでは、基本的に1人は1つの組織に所属します。複数の部署にまたがる権限は、グループで表します
4. 文書の更新の履歴まで移したい：移行モードで取り込めるのは作成者・作成日時・更新者・更新日時までで、更新の履歴そのものは取り込めません

• 

  お悩み解決動画

  皆さまからお寄せいただいたプリザンターのお悩みを動画で解決します。

  プリなま

• 

  関連ブログご紹介

  プリザンターに関連したバラエティに富んだブログ記事の新着をお届けします。

  関連ブログ情報
• 

  ユーザマニュアル

  はじめて触る方向けの基本説明からカスタマイズに必要な開発者向け情報まで。

  マニュアルページ