XEROTTA

CUSTOM DEVELOPMENT / SYSTEM INTEGRATION

個社サイト開発

基幹を活かし、
クラウドを
つなぎ替える。

人事DB・資産DBなど、積み重ねてきた社内基盤。
その価値を活かしながら、新しいクラウドサービスを使える環境へ。

既存システムとSaaSの間に、データ連携と業務を担う中間システムを開発します。新サービスを導入するたびに基幹を廃止・移行する負担を抑え、貴社の運用に合う画面とワークフローを整えます。

仕組みを見る ↓Notes連携の開発例を見る ↓

01 / ARCHITECTURE

クラウドとの接続を、
基幹の外側で受け止める。

社内の正式な人事・資産データは既存基盤に残し、サービスごとに異なるID、項目、認証、更新方法を中間システムで整理します。利用者には、接続先が変わっても使い続けやすい共通の業務画面を提供します。

全体構成イメージ
KEEP / 活かす

既存の社内基盤

  • Notes/Dominoの人事DB
  • 資産管理・組織・拠点DB
  • 蓄積された業務ルール

各データの管理責任と、正式な更新元を維持。

API・管理された
ファイル連携等
CONNECT / つなぐ

中間システム

  1. 接続アダプター認証・取得・送信・項目変換
  2. 共通データモデル人物・資産・貸与関係・状態
  3. 業務サイトとワークフロー申請・承認・引き渡し・対応
  4. 運用管理照合・再送・例外・監査履歴
サービス別の
接続アダプター
CHANGE / 選び替える

クラウドサービス

  • 現在のデバイス管理SaaS
  • 追加する業務SaaS
  • 将来の置き換え先

接続条件を確認し、追加・変更の影響を局所化。

構成の説明図です。すべてのデータを双方向更新する設計ではなく、項目ごとに参照元・更新先・責任者を定義します。

01

正式なデータを分散させない

人事情報は人事DB、端末の技術状態はSaaS、社内の貸与・承認履歴は中間システムというように、情報ごとの管理責任を決めます。

02

接続先固有の仕様を閉じ込める

APIや認証、ID、状態名の違いを接続部分で吸収。SaaSの追加や置き換え時は、共通モデルとの対応を検証して切り替えます。

03

例外対応まで業務としてつなぐ

同期に失敗したデータや承認待ち、未返却などを可視化。担当者が確認・再処理できる入口を用意し、処理漏れを追えるようにします。

長く使うための設計方針接続先の追加は無条件・無改修ではありません。API提供範囲、利用規約、契約プラン、データの意味、業務変更を確認して対応します。既存基盤そのものの保守期限・セキュリティ・性能への対応も、連携開発とは別に継続して検討します。

02 / DEVELOPMENT EXAMPLE

Notes/Domino × デバイス管理SaaS ／ 構成・運用例

「誰が、どの端末を、
どんな状態で使っているか」をつなぐ。

人事情報はNotesにあり、端末の登録・設定・管理状態はSaaSにある。そこへ、払い出しの申請や返却、修理のやり取りが加わると、情報が分かれます。中間システムで人とデバイスの対応を管理し、日々の手続きを一続きの履歴にします。

以下は開発内容を説明するための想定構成・画面・運用例です。実在企業の導入実績や効果測定結果を示すものではありません。

導入前に起きやすいこと

  • 退職予定者に貸与中の端末を、複数の台帳から探す。
  • 申請はメール、承認は別システム、受領確認は紙で残る。
  • SaaSに登録されたユーザーと、実際の貸与先が一致しない。
  • 修理中の端末と代替機の関係が、担当者の記憶に頼る。

開発する管理システム

  • 人物・端末・貸与履歴を相互にたどれる共通画面。
  • 払い出し・返却・保守案件をつなぐワークフロー。
  • 未一致・同期失敗・未返却を確認する例外一覧。
  • 担当・承認・期限・処理結果を追跡できる履歴。
人とデバイスの紐付けイメージ
人事の正本

Notes / Domino

人物ID・在籍状態
所属・上長・発令日

業務上の利用関係

人物 × 資産 × 期間

貸与・共用・代理受領
申請・承認・返却・保守履歴

中間システムで管理
端末の管理情報

デバイス管理SaaS

端末ID・機種・OS
管理状態・最終同期日時

一人に複数台、複数人で使う共用機、修理中の代替機にも対応する関係モデルを設計します。

どの情報を、どこで管理するか

Notes / Domino

人物を識別する情報、在籍・所属・発令日など。氏名やメールアドレスの変更後も履歴を追える内部IDを設計し、再雇用や社員番号の再利用も区別します。

デバイス管理SaaS

管理対象の端末ID、OS、管理状態など。取得できる項目と更新頻度は製品・契約に依存します。登録者・主ユーザー・所有者はそれぞれ意味を確認します。

既存資産DBがある場合

資産番号・保有状態・保証など、既存DBで管理している項目を参照します。在庫・予約の確定元を一つに決め、中間システムから更新する範囲と反映結果の確認方法を合意します。

中間システム

人物IDと資産IDの対応、貸与期間、申請・承認・受領、返却・保守の履歴、接続先IDとの対応表を管理。氏名やシリアル番号だけを唯一の紐付け根拠にはしません。

PERSON & DEVICE / 業務管理画面イメージ・架空データ
人物情報

社員A 人物ID：P-001

所属：営業部　／　在籍：在職　／　参照元：Notes

貸与履歴・申請・対応をまとめて確認
貸与中

PC-0042 ノートPC

SaaS管理：登録済み
貸与先：社員A
受領：確認済み

修理中

PC-0018 旧端末

保守案件：M-012
代替機：PC-0042
復旧確認：未完了

返却待ち

PH-0081 スマートフォン

返却申請：R-008
回収：日程調整中
データ処理：未実施

例：同じ人物に関連する端末・代替機・返却予定を表示。貸与状態とSaaSの技術状態を分けて扱います。

03 / WORKFLOWS

台帳だけで終わらせず、
払い出しから返却・保守まで。

4つのタブから、担当者、処理の順番、例外時の扱い、残す記録を確認できます。承認条件や画面項目は、貴社の規程と業務に合わせて開発します。

人事の変更と端末の状態を、同じ管理画面で確認する。

  1. STEP 1人事・端末情報を取得連携処理
  2. STEP 2人と端末の対応を照合中間システム
  3. STEP 3業務上の利用関係を確認資産管理担当
  4. STEP 4異動・退職への対応を起票本人・所属責任者・管理担当
  5. STEP 5履歴を残して定期棚卸し管理担当・監査担当
01

人事・端末情報を取得

担当：連携処理

Notes/Dominoから必要な人事項目を、SaaSから端末ID・管理状態・最終同期日時などを取得します。既存資産DBがある場合は資産番号・保有状態・保証情報なども取得します。取得周期と対象項目は接続先の仕様に合わせます。

02

人と端末の対応を照合

担当：中間システム

変更されにくい内部の人物IDと資産IDを軸に照合します。氏名・メールアドレスだけでは自動確定せず、未一致・重複・退職者への割当を例外として分けます。

03

業務上の利用関係を確認

担当：資産管理担当

貸与中・共用・予備・修理中などを確認します。SaaSの主ユーザーや登録者と、社内で承認した貸与先が異なる場合は差異を表示します。

04

異動・退職への対応を起票

担当：本人・所属責任者・管理担当

異動による承認者や費用負担部門の変更、退職予定に合わせた返却依頼を起票します。人事更新だけで、端末の消去や回収完了を自動判定しません。

05

履歴を残して定期棚卸し

担当：管理担当・監査担当

誰が、いつ、何を変更したかを記録。本人確認や現物確認の結果と台帳を突き合わせ、実物・貸与関係・SaaS登録の差異を解消します。

例外・未完了も追える設計

照合できないレコードは保留一覧へ。担当者が根拠を確認して紐付け、再処理できるようにします。

残す記録人物ID・資産ID・接続先ID／貸与期間／所属・費用負担部門／照合結果／最終取得日時／変更・棚卸し履歴

04 / RELIABLE OPERATIONS

止まること・ずれることも、
運用の中で扱えるように。

同期失敗を見える化

取得日時と失敗理由を表示し、再試行・担当通知・保留一覧を用意。古い情報を最新の情報として表示しない設計にします。

重複処理を防ぐ

申請ID・処理IDで再送を識別し、同じ依頼で二重に払い出さないよう制御。外部APIが重複排除に対応しない場合は照会と処理記録を組み合わせ、結果を確認できない操作は自動再送せず、保留して担当者が確認します。

正しさを定期照合

差分取得だけでなく、定期的な突き合わせで取得漏れやID変更を検知。件数・未一致・例外処理の結果を確認します。

権限と情報を絞る

人事担当、承認者、資産管理、保守窓口の役割を分離。目的に必要な人事項目だけを取り込み、認証情報・ログ・保存期間を管理します。

外部の受付と完了を分ける

APIが受け付けた状態と、端末に反映された状態を別管理。遠隔操作やデータ処理は、権限・承認と結果確認を含む手順にします。

接続先を段階的に切り替える

新旧SaaSのID・状態・項目を対応付け、限定範囲で試験。並行照合と切り戻し条件を用意し、業務への影響を確認して広げます。

05 / DELIVERY

現状の業務から調べ、
小さくつないで、確かめる。

  1. 01

    現状・接続条件の調査

    Notes/Dominoのバージョン・DB・権限、SaaSのAPI・契約・制限、ネットワーク、既存台帳、承認・返却・保守の運用を確認。

  2. 02

    共通モデルと業務設計

    人と資産のID、正本、項目対応、状態遷移、例外、役割と権限、監査・保存・復旧方針を定義。画面・帳票を具体化。

  3. 03

    接続検証と段階的な開発

    読み取り・照合から始め、限定部門で申請と受領確認を試行。重複・通信断・API制限・退職・共用端末を含めて試験。

  4. 04

    並行稼働・引き継ぎ・改善

    既存台帳と照合して切り替え、運用手順・担当・障害時の対応を引き継ぎ。問い合わせや例外の実態を見て改善。

主な成果物

システム構成図 ／ データ・ID対応表 ／ 画面設計 ／ 状態遷移・承認設計 ／ 接続プログラム ／ テスト・照合結果 ／ 監視・復旧・運用手順

効果は導入前後で確認します。例：台帳照合にかかる時間、未返却の滞留、申請から受領までの所要時間、同期失敗・未一致の解消状況。改善率や費用削減額を事前に保証するものではありません。

06 / FAQ

よくあるご質問

新しいクラウドサービスが出るたびに、人事DBを移行する必要がありますか？

連携のためだけに毎回人事DBを移行する構成を避け、共通のデータ定義と接続アダプターを介して新サービスを追加する設計を目指します。ただし、API・契約・データの意味や業務要件によって接続部分や画面・業務ルールの改修が必要です。すべてのサービスに無改修で接続できるという意味ではありません。

古いNotesでも接続できますか？

利用中のNotes/Dominoのバージョン、DB設計、ACL、利用可能なAPIと出力機能を確認して判断します。HCL Domino REST APIを使える環境では公開対象と権限を設計し、使えない場合は許可された既存API、エージェント、定期ファイル出力などを検討します。必要な追加製品・改修・更新を事前に整理します。

人事情報をクラウドにすべて渡す必要がありますか？

必要ありません。端末管理に必要な人物ID・在籍状態・所属等に項目を絞り、給与・評価など目的外の情報を渡さない設計とします。中間システムの配置や通信経路、アクセス権は社内規程と接続先の要件に合わせます。

SaaSの『主ユーザー』を、そのまま端末の貸与先にできますか？

その値だけでは貸与先や現実の利用者を確定できません。登録者・主ユーザー・所有者・貸与対象者は意味が異なります。申請・受領確認・棚卸しを根拠に社内の貸与関係を管理し、SaaSの情報と差異があれば確認します。共用機や代理受領にも対応するモデルを設計します。

SaaSの乗り換え時は何を変更しますか？

認証、API、項目変換、状態対応などの接続部分を中心に変更します。接続先固有のIDを切り替える対応表を用意し、旧新サービスを並行照合してから切り替えます。共通モデルで表現できない機能や承認条件が増える場合は、中間システム側も見直します。

退職情報を受け取ったら、自動で端末を消去しますか？

退職予定を返却手続きの開始条件にできますが、遠隔消去の実行条件とは分離します。対象端末・保存要件・実施権限・承認を確認し、処理結果の確認まで管理します。人事更新だけを根拠に、不可逆な端末操作を行う設計にはしません。

既存システムを停止して一括切り替えする必要がありますか？

まず読み取り連携と照合から始め、対象部門・端末を絞って申請フローを試す進め方を検討します。並行稼働、差異確認、切り戻し条件を決めて段階的に広げます。停止可否や切替時間は既存環境と連携方式を確認して決定します。

開発費用・期間は何で決まりますか？

接続するDB・SaaSの数と仕様、データ量・更新頻度、承認経路、画面・帳票、権限、移行・照合、運用監視の範囲によって変わります。現状調査後に、初期開発、追加製品・ライセンス、保守運用を分けて見積もります。

LET’S CONNECT YOUR SYSTEMS

残したい基盤と、
使いたいサービスをお聞かせください。

人事DBや資産DBを活かせるか、どこを中間システムで受け持つか。
現状調査から、連携・業務画面・運用の設計までご相談いただけます。

個社サイト開発について相談する →社内サイト作成ツールも見る →