業務・要件分析
現行業務、ユーザーの役割、データの流れ、外部連携の条件をまとめて構造化します。
つなぐべきなのは、システムよりも業務の文脈です。
要件を機能一覧に落とし込むだけで終わらせず、担当者の実際の業務フローと既存システムの制約もあわせて確認します。必要な連携箇所とデータの基準を先に整理し、構築後もわかりやすく、管理しやすい構造を設計します。
業務分析から切り替えまで、連携の全工程を担当します。
システムアーキテクチャ設計
既存の環境と今後の拡張計画を踏まえ、アプリケーション、データ、インターフェースの構造を設計します。
連携・統合の実装
システム間の自動連携や一括処理、データ交換の方式など、環境に合った接続箇所を実装し、検証します。
切り替え・安定化の支援
移行の範囲と検証の基準、段階ごとの切り替え手順を整理し、運用引き継ぎまでつなげます。
本日の連携状態
- 市民の申請受付から 業務処理受付内容の転送正常
- 業務処理から 精算処理結果と精算データ正常
- 外部機関での資格確認応答形式の変更を検知要確認
- 統計の集計日次集計の送信送信中
- 受信
- 検証
- 変換
- 転送
システムが分かれているところでは、同じ作業が二重に発生します。
こんなときに
分断された業務とデータ
部署や機関ごとに別々のシステムを使っているため、同じ情報を何度も入力したり、手作業で突き合わせたりしています。
レガシーシステムの制約
既存の資産を維持しながら、新しい機能とサービスを安全につなぐ必要があります。
運用まで見据えた切り替え
構築スケジュールだけでなく、データ移行、ユーザーの習熟、障害対応まで含めた現実的な切り替え計画が必要です。
現状分析から安定化まで、4つの段階で切り替えます。
現状分析
業務担当者とシステムの現状を確認し、優先して取り組む課題について合意します。
統合設計
業務、データ、画面、連携の構造を、ひとつの設計基準にまとめます。
実装と検証
機能単位で実装し、実際の業務シナリオと連携の条件に照らして検証します。
切り替えと安定化
データと利用環境を段階的に切り替え、運用の中で見えてきた改善点を整理します。
プロジェクトでまとめる成果物
- 現行業務と要件の定義書
- サービス・システムアーキテクチャ
- インターフェースとデータ連携の仕様書
- 機能ごとの実装・検証結果
- データ移行・切り替え計画
- 運用引き継ぎ資料
具体的な範囲と成果物は、初期の打ち合わせで確定します。
関連するプロジェクト実績
カード会社・保険会社の電文送受信システム
カード会社・保険会社のデータ交換を自動化するプロジェクト
- KPSの役割
- 電文データインターフェースの開発・管理、送受信のモニタリングとログ管理、安全な通信とデータ暗号化の実装
- 電文インターフェース
- 送受信モニタリング
- 安全な通信・暗号化
公団の統合精算・決済システム
複数の機関に分かれていた利用者情報と決済処理の業務を、ひとつに連携して運用するプロジェクト
- KPSの役割
- 統合精算・決済システムの構築・開発、決済端末とVAN（カード決済の承認を中継する付加価値通信網）を連携する区間のWeb脆弱性診断とセキュリティ強化
- 精算・決済システム
- Web脆弱性診断
- VAN区間のセキュリティ
中央省庁のオンライン広報Webサイト
中央省庁のオンライン広報Webサイトを民間クラウド環境に構築するプロジェクト
- KPSの役割
- 民間クラウドを基盤とした広報Webサイトの開発
- 民間クラウド
ご相談前によくある質問
よくある質問をすべて見る既存の業務システムや外部サービスとも連携できますか？
連携先が提供するAPI（データをやり取りするための窓口）、データベースへのアクセス条件、認証方式、呼び出しの制限をまず確認します。
回答をすべて見る：既存の業務システムや外部サービスとも連携できますか？既存データの移行も構築範囲に含められますか？
元データの構造と品質、移行先システムのデータモデル、個人情報の取り扱いと保存に関するポリシーを確認したうえで、移行の範囲を決めます。
回答をすべて見る：既存データの移行も構築範囲に含められますか？既存システムを段階的に刷新できますか？
業務への影響と技術的な依存関係を踏まえて、画面、機能、データ、連携の領域を切り替えの単位に分けることができます。
回答をすべて見る：既存システムを段階的に刷新できますか？
まずは、連携が必要なシステムの一覧をお知らせください。
現在の運用環境と改善したい業務を伺い、始める範囲を一緒に整理します。