応用情報技術者試験 過去問 2024年（令和6年） 春期 午後 問4
CRM（Customer Relationship Management）システムの改修
C社は、住宅やビルなどのアルミサッシを製造、販売する中堅企業である。取引先の設計・施工会社のニーズにきめ細かく対応するために、自社で開発したCRMシステム（以下、CRMシステムという）を使用している。CRMシステムは、データベースとWebアプリケーションプログラム（以下、Webアプリという）から成り、C社のLAN上にあるPCから利用される。このため、営業担当者が外出先からスマートフォンやノートPCを用いてCRMシステムを利用できるようにするために、データベースは変更せずにWebアプリを改修することになった。
Webアプリの改修方針
Webアプリの改修方針を次に示す。
- 必要以上の開発コストを掛けない。
- 営業担当者が外出先で効率的にCRMシステムを利用できるように、スマートフォンに最適化した画面を追加する。
- 将来的に、CRMシステム以外の社内システムとも連携できるように拡張性をもたせる。
Webアプリの実装方式の検討
これらの改修方針を受けて、図1のWebアプリを実装するシステムの構成案を検討した。
検討したWebアプリの実装方式を次に示す。
- ユーザインタフェースとデータ処理を分ける。ユーザインタフェースは、Webサーバに HTML, Cascading Style Sheets (CSS), 画像, スクリプトなどを静的なファイルとして配置する。データ処理は、APがDBから取得したデータをJSON形式のデータで返すWeb APIとして実装する。
- ユーザインタフェースとなる静的ファイルは、PCとスマートフォンそれぞれのWebブラウザ用に個別に作成し、データ処理用のWeb APIは共用する。
- ユーザインタフェースの表示速度を向上させるために、①静的ファイルを最適化する。
実現可能性の評価
【Webアプリの実装方式の検討】で示した方式の実現可能性を評価するために、プロトタイプを用いて多くのデータを扱う機能について検証した。その結果、スマートフォンの特定の画面において次の問題が発生した。
- 扱うデータ量が増えるに連れて、レスポンスが著しく低下する。
- ②スマートフォンのCPU負荷が大きく、頻繁に使用するとバッテリの消耗が激しい。
そこで、これらの問題の原因を調べるために、Webアプリの処理を分析した。レスポンスの悪かった日誌一覧の表示画面を図2に、Web APIからの応答データを図3に示す。
{
"customer": "○△×設計事務所",
"count": 16,
"diaries": [ ←α
{"date": "2023-08-21",
"salesperson": "情報花子",
"salesprocess": "問合せ",
"diary": " (省略) "},
{"date": "2023-10-04",
"salesperson": "情報太郎",
"salesprocess": "製品概要紹介",
"diary": " (省略) "},
:
] ← β
}
スマートフォンのWebブラウザが図2の画面をリクエストしてから描画されるまでの一連の処理について、処理ごとに所要時間を測定した結果を表1に示す。
| No. | 処理概要 | 所要時間（ミリ秒） |
|---|---|---|
| 1 | Webブラウザが画面に必要となる静的なファイルを全て受信する。 | 300 |
| 2 | WebブラウザがWeb APIにリクエストして、図3の応答データを全て受信する。 | 800 |
| 3 | Webブラウザ内で日誌のデータを日付の降順にソートして、画面に表示する最大件数である4件目までを抽出する。 | 1,200 |
| 4 | 日誌本文が42文字を超える場合、先頭から41文字に文字"…"を結合した42文字の文字列にする。 | 300 |
| 5 | 日誌一覧の表示を実行したユーザが作成した日誌かさかを判別して、本人が作成した日誌には"編集"ボタンを表示する。 | 200 |
| 6 | データをWebブラウザに描画する。 | 500 |
表1から、図3の応答データのスマートフォンへの転送処理と、Webブラウザ内でその応答データを加工する処理に多くの時間を要していることが判明した。
Webアプリの見直し
Webブラウザが画面をリクエストしてから描画されるまでの所要時間の目標値を3秒以内に設定して、それを達成するために、次の三つの方式を検討した。
- ① スマートフォンのユーザインタフェースをアプリケーションプログラム（以下、スマホアプリという）として開発して、そのスマホアプリ内でWeb APIからの応答データを加工・描画する方式
- ② リクエストのあった応答データのうち、Webブラウザに描画するデータだけを返すWeb APIを開発して、スマートフォンのWebブラウザからそのWeb APIを利用する方式
- ③ ②で開発したWeb APIを①で開発したスマホアプリから利用する方式
各方式について、応答データを加工・描画するソフトウェア又はサーバと、その実現可能性を評価するために、設けた評価項目について整理した結果を表2に示す。各評価項目の評価点に対する重み付けは均一とし、また、将来的な拡張性については各実装方式を設計するタイミングで検討することにした。
なお、【実現可能性の評価】においてプロトタイプを用いて検証した方式を方式Ⓟとする。
| 方式 | ソフトウェア/サーバ | 評価項目 | 評価点合計 | |||
|---|---|---|---|---|---|---|
| データ描画 | データ加工 | レスポンス | 開発コスト | CPU負荷 | ||
| Ⓟ | Webブラウザ | Webブラウザ | × | ◎ | × | 3点 |
| ① | スマホアプリ | スマホアプリ | ○ | △ | △ | 4点 |
| ② | Webブラウザ | AP | ○ | ○ | ○ | 6点 |
| ③ | スマホアプリ | AP | ◎ | × | ○ | 5点 |
レスポンス時間の試算
表2の結果から、方式②について更に検討を進めることになり、そのレスポンスが実用上問題ないか、表1を基に所要時間を試算した。
表1中のNo.2の所要時間について考える。方式②のWeb APIからの応答データのサイズは、図3のデータのサイズの4分の1になり、サーバ側でのデータ転送には時間を要しないものと仮定すると、No.2の所要時間はaミリ秒となる。
次に、No.3～No.5の処理時間について考える。No.3の処理はDBで、No.4とNo.5の処理はAPで行われる。処理時間は各機器のCPU処理能力だけに依存すると仮定する。各機器のCPU処理能力は、スマートフォンが10,000MIPS相当、DBが40,000MIPS相当、APが20,000MIPS相当の場合、No.3～No.5の処理時間の合計はbミリ秒となる。
以上の試算の結果、方式②で十分なレスポンスが期待できることから、方式②を採用することにした。
システム構成の検討
方式②で開発したWeb APIの配置について検討した。図1のAP上に配置する案も検討したが、③将来的な拡張性を考慮した結果、図1のAPとは別に、スマートフォンやノートPCから呼び出されるWeb APIのためのAPを、新たに追加する構成にした。