商談管理アプリの設計を行います。
なお、今回は小規模システム且つローコード開発のため基本設計のみで詳細設計・プログラム設計はありません。
設計のインプットなる要件定義書は「はじめてのプリザンターアプリ作成：商談管理２(要件定義)」を参照してください。
システム設計
システム構成図、サブシステム間連携方式等の設計を行います。
- システム構成図: システム・業務・機能の構成がわかる構成図
- サブシステム間連携: 方式や制約およびインターフェース設計
アーキテクチャー設計
システム・データ・プログラム等の基盤・方式を設計します。
システムアーキテクチャー
今回は、フルマネージドサービスのプラットフォーム (PaaS)のAzure App Service上で商談管理アプリの構築を検討します。
- Webサーバー: Azure App Service
- OS: Windws Server
- DBサーバー: Azure SQL Database
- ランタイムスタック: .NET8、プリザンターはC#で開発されているため
- アプリケーションサーバー: Pleasanter
データアーキテクチャ
DBはAzure SQL Databaseを使います。ストレージはAzure Storageとなります。
プログラムアーキテクチャ
アプリケーションサーバーのプリザンターでローコード機能(JavaScript)が利用できますが今回は使用しません。
インフラ設計
サーバーやネットワーク等のインフラに関する設計を行います。
今回は、プリザンターをAzure App Service上に構築します。
機能設計
機能要件で定義した業務機能(画面・帳票・バッチ・API等)の設計を行います。
今回の、商談管理アプリで作成する機能は以下となります。
- 顧客情報: 顧客情報を管理、テンプレートで作成、全組織更新権限を付与
- 商談管理: 商談情報を管理、テンプレートで作成、顧客情報とリンクを設定、営業部・開発部は更新権限、管理部は参照権限を付与
- クロス集計: ビューで状況別月別商談件数と状況別月別商談金額を作成
機能設計は以下の通りです。
- 画面設計書: 機能概要・サイト種類(テンプレート：記録テーブル)・画面レイアウト・項目説明等
非機能設計
非機能要件で定義した品質や性質を実現するための設計を行います。
性能設計
- 利用者数・アクセス頻度・大量なデータ検索等、運用面を把握し、Azure App Service・Azure SQL Databaseのリソース(CPU/RAM/ストレージ等)のスケールアップ・スケールアウト設計を行います。
- 大量データを使って複雑なアルゴリズム等の処理による性能影響がある場合にも同様です。
- なお、プリザンター上で実装するプログラムに起因する場合は運用で代替できるか検討します。
信頼性
- Azure App Serviceのダウンタイムは99.95%となっており冗長化も可能です。
可用性
Azure App Serviceは可用性ゾーンを設定することで冗長化設計が可能です。
保守性
- プリザンターにはユーザーマニュアルが存在します。
- プリザンターはOSSでGitにソースコードもアップロードされています。
- プリザンターのローコード開発言語はjavaScriptとなっており開発人口は多く存在します。
拡張性
- プリザンターはノーコード・ローコード開発ツールで拡張性は無限ですが、サイトは2,000サイト、レコードは1サイト当たり100,000レコードを目安に運用することが推奨されています。
- 無償版のプリザンターでは１サイトで扱える項目数は256個ですが、有償版にすることで900個まで拡張は可能です。
移植性
- プリザンターはWindows/Linuxで.net frameworkが動く環境であれば移植可能です。
- 移行ツールは、サイトパッケージのエクスポートとインポート機能でアプリとデータの移行が可能です。
ユーザビリティ
- テーマ選択が可能でシンプルで使い勝手の良いUIです。
- ノーコード開発ツールでGUIでアプリ作成が可能です。
アクセシビリティ
- 利用者の中に高齢者や障害者がいる場合はアクセシビリティの設計を行います。
セキュリティ
- Azure App Serviceで提供するセキュリティサービスの設計を行います。
- プリザンターは標準のセキュリティ機能として、SAML認証・LDAP認証・LDAPユーザー同期・Windows認証・ユーザー招待・二要素認証・パスワードポリシー・アカウントロック・IPアドレス制限等が存在し、導入するセキュリティ機能の設計を行います。
- 今回は標準設定のままとしセキュリティ機能の実装は行いません。
データ設計
DB・ファイル・通知・メッセージ等の設計を行います。
DB設計
- 顧客情報: 項目・型・必須・読取・重複・規定値・選択肢・検索機能利用・アンカー・ポストバック・非表示等を設計
- 商談管理: 上記同様
プリザンターエディタ機能を使うと画面と同時にDBの構築も行ってくれます。性能改善等でDBチューニングが必要になった場合以外は直接DBを修正することはありません。
顧客情報
今回、顧客情報はテンプレートで作成しそのまま使います。作成方法は「はじめてのプリザンターアプリ作成：商談管理１」の「商談管理をテンプレートから作成する」を参照してください。
商談管理
以下項目以外はテンプレートのまま使用します。
| 項目 | 型 | 必須 | 読取 | 重複 | 規定値 | 選択肢 | 検索 |
| 顧客名 | 分類A | □ | □ | □ | □ | *1 | ☑ |
*1:商談管理の顧客名を入力から顧客情報を検索できるように変更。SiteIdは顧客情報のテーブル管理＞全般タブのサイトIDを転記
[
{
"SiteId": 99999,
"SearchFormat": "[Title]",
}
]ファイル設計
今回の商談管理ではファイルを扱わないため割愛します。
通知設計
- 通知機能: レコード更新時の通知設計を行います。通知の種類はメール、Slack、ChatWork、LINE、LINEグループ、Teams、Rocket.Chat、InCircle、HTTPクライアントから選択できますが今回は使用しません。
- メール機能:商談管理で作成した商談レコードを共有するために通知としてプリザンター標準機能のメール機能を使用します。
メッセージ設計
- ガイド機能: 顧客情報・商談管理のテーブルの管理のガイド機能で各画面のガイダンスを設計しますが今回は使用しません。
- 通知機能: 上記参照
- 画面メッセージ: スクリプトやサーバースクリプトで情報・警告・異常メッセージの表示が可能ですが、今回はノーコード開発のため設計しません。
システム運用設計
マスターやバッチ等のシステム運用について設計します。
マスター設計
- ユーザー・グループ・組織: プリザンター標準機能、人事異動時に更新を行います。
- テナント管理者:プリザンター標準機能、今回は設定しません。
- 特権管理者:プリザンター標準機能、今回は設定しません。
バッチ設計
今回の商談管理ではバッチはないため作成しません。
サイジング
業務量を見積もり、インフラリソースを確保します。
- 顧客情報: 日次・週次・月次・年次のデータ量(レコード・ファイル)を計算、また、次年度以降の成長率を加味した業務量を計算し、必要なインフラリソースを決定します。
- 商談管理: 同様
フィジビリティ
アーキテクチャー・機能設計で設計したシステム・機能が実現可能か、運用に耐えられるか検証を行います。
構成管理
システムを安定稼働させるためにハードウェア・ネットワーク・ソフトウェアの構成を管理します。
変更管理
要件・仕様変更を管理しQCD(品質・コスト・納期)・プロジェクト(体制・スケジュール等)・システム・機能への影響を管理します。
まとめ
今回導入する商談管理アプリは、システム規模も小さく・難易度も易しいため、基本設計にそこまでの時間を要することなく作成することができるかと思います。
次回は実装について説明をしていきます。
