平成27年度 システムアーキテクト試験 午後Ⅱ論文答案習作

第1章 業務機能追加、変更の対象とした情報システム

1.対象となった情報システム及び業務の概要

　私が業務機能追加、変更の対象として携わった情報システムは、ECサイトプラットフォームのシステムであ る。

　今日、インターネット上販売を手掛けるサイトは多く存在するが、ECサイトプラットフォームは、ECサイトとしてインターネット上販売を行うための共通機能を、小売側が手軽に利用するためのプラットフォームである。

　すなわち、販売する商品の登録と、配送、決済に関する小売体制をプラットフォームに登録するだけで、ECサイトをプラットフォーム上で半自動的に構築し、EC事業を行うことを可能としている。

　私は、このECサイトプラットフォームの業務課題対応について、システムアーキテクトとして関わった。

2.機能変更または追加を必要とした業務課題

　最初のバージョンのプラットフォームを運用してしばらくした後、以下の要望を顧客から受けた。

①販売者ごとにカスタマイズ処理を追加したい。

　共通機能を提供しているプラットフォーム上では、機能が共通でユーザビリティが高い一方、販売者ごとに個性を出すことが困難である。

　例えば、販売後にSNSへの投稿を行ったり、販売結果を保存しておいて、後日メールでレコメンドする機能等、販売者ごとにそれぞれ異なるサービスを行いたい、という要望を複数の販売者から個別に聴取した。

②販売結果をレポーティングしてほしい。

　販売者側としては、販売実績を管理し、実績を元に品揃えを最適化したいとの要求があるが、販売実績については、最初のバージョンでは単なるCSVファイルのオフライン出力しかできず、ビジュアライゼーションによる視覚的な分析には難があった。

　このため、グラフや多変量解析など、より高度な解析、出力を可能として欲しい旨の要望を受けていた。

第2章 業務機能の変更と追加

1.具体的な変更、追加機能

　私は、上記の業務課題について、以下のように変更、追加を行った。

　①販売者ごとのカスタマイズ処理については、プラットフォーム上の購入処理末尾に、販売者独自の処理を挿入することで対応した。

　具体的には、販売者は予め実施したいサービス内容を『販売者独自処理』として(プログラムやAPI呼び出しとして)記述しておく。

　購入者が購入を確定するボタンをクリックした際、ECサイトプラットフォーム側は、決済処理とともに、当該販売者独自処理を呼び出す。

　これにより、購入確定後に、販売者独自処理が実行され、販売者ごとに独自のサービスを実行できる仕組みとしている。

　例えば、販売終了後、販売商品の情報をTwitterに自動投稿する処理や、リコメンド用データベースに販売商品のIDを保存しておく、などといった独自処理を定義、実行することができるようになっている。

　②販売結果のレポーティングについては、購入確定後に、データ解析を行う他事業者のクラウドサービスに対して、自動的にWeb APIを呼び出し、当該API経由で販売データを転送し、データ解析クラウドサービス内に販売データを蓄積させ、当該サービスにおいてレポーティング機能を提供するように、販売データの出力を行うようにした。

　販売者は、ECサイトプラットフォーム側ではなく、データ解析用他クラウドサービスにアクセスすることで、自身の販売履歴を解析したレポーティングサービスを受ける、という形態になる。

　加えて、販売者が独自にレポーティング機能を準備した場合に備え、販売結果を取得可能なWeb APIを自社サイトに準備し、当該APIを販売者側のレポーティング機能から呼び出すことにより、販売者自身でレポーティングできるようにした。

2.課題への対応性について

　以下、各課題ごとに対応性について言及する。

　①販売者ごとのカスタマイズ処理については、購入完了後のフォローによる差別化が販売者側の主たる要望であり、購入中のカスタマイズは不要という要求であった。

　このため、購入終了後のみ、販売者の独自性が発揮できればよく、購入終了後のカスタマイズ機能提供で十分であった。したがって、当該機能変更は、販売者にとって十分な課題対応性を有していたといえる。

　②販売結果のレポーティング機能については、後述の通り、自社がレポーティング機能を独自開発しないことを意図したものでもあったが、販売者としては、『レポーティング機能は、ECサイトプラットフォーム機能とは独立して利用したい』『プラットフォーム上ではなく、自らデータを取得して自由に解析したい』という潜在的な要望があり、この潜在ニーズと照らしあわせても、販売者が有する課題への対応性は十二分であったと結論される。

第3章 機能変更、追加時の工夫

　以下、当該機能変更、追加に関する工夫について述べる。

1.既存情報システムへの影響最小化

　販売者ごとのカスタマイズ処理については、ECサイトプラットフォーム側で、購入完了後にある特定の名前のメソッドを呼び出す処理を追加している。この呼出処理においては、販売者が独自処理を定義していなければ何もせず、独自処理を定義していればその処理を呼び出すことになっている。

　これにより、販売者ごとのカスタマイズ処理実装にあたっては、既存のECサイトプラットフォーム側への設計、実装変更をほとんど実施する必要が無い。したがって、カスタマイズ機能実装にあたっての、既存情報システムへの影響は、当該カスタマイズ機能の処理結果を除いては全く存在しない、という設計とした。

　さらに、呼びだされた独自処理は、ECサイトプラットフォームのプロセスとは別のプロセスとして実行される。したがって、仮に販売者独自処理に不具合があり、プロセスが不正終了した場合であっても、すでに動いているECサイトプラットフォームの機能実行には何ら影響しないという実装にもなっている。

2.既存機能の活用

　販売結果のレポーティングについては、ECサイトプラットフォーム自身で解析を行った場合、既存の設計や実装に対して中規模な変更が発生する見通しであった。このため、あえて自社のサービスとしてレポーティング機能を独自開発するのではなく、既存の他事業者のサービスや、販売者自身のレポーティング機能と連携することで、すでに存在するレポーティング基盤を活用し、機能実現を図ることにした。

　これにより、自社はECサイトプラットフォームに特化した機能実現、追加、保守に注力できるばかりではなく、完成度の高い既存のレポーティング基盤を販売者に提供する形となり、既存機能の活用によって、より販売者のニーズに合致したサービス連携、機能実現を図ることができている。