南山大学 数理情報学部 情報通信学科 卒業研究 発表予稿

電子商取引システムのゴール分析の方法
２００１ＭＴ０６９，村上 寿美代

２００１ＭＴ０７８，大場 千穂

指導教員 青山 幹雄

1. はじめに

3. ゴール分析の手順

本研究では，ビジネス要求に対応した電子商取引システムのゴール分析を提案する．電子商取引を経営戦略とする企業が増加する一方，システム構築には信頼性や，短期開発が求められている．より複雑化するビジネス要求を満たし，企業の利益へと繋がらなければならない．
電子商取引システム開発のでは，ビジネス要求を満たすことが重要となるので，ビジネス目的を満たす機能の抽出が重要となる[1]．そのため，ビジネス目的からシステム機能を抽出するゴール分析を行う必要がある．しかし，電子商取引システムに対するゴール分析の方法は確立されていない．そこで，我々はパターンに基づく電子商取引システムのゴール分析を提案する．

既存のシステムを用いて，ゴール分析を行う．ユースケ
ース分析により抽出された機能と，ゴール分析により抽出された機能を対応付けることにより，システムとゴールとを対応付ける[2][3]．
（1）ユースケース分析
既存のシステムの機能を抽出し，ユースケース図を用いて分析を行う．
（2）サブゴール分析
ビジネスの最終ゴールを決定し，それを満たすためのサブゴールを決定する．これを繰り返すことにより，必要となる機能を抽出できる．
（3）サービスネットワークを用いたゴール分析
サブゴール分析だけでは，電子商取引システムの機能間の関係を理解できない．そこで，提供価値を定義し，それを満たすためのケイパビリティを定義していくことで機能を抽出できる，サービスネットワークを用いる[5]．我々は機能間の関係を明確にできるサービスネットワークを用いたゴール分析の方法を提案する．
（4）MVC を用いたサービスネットワークの構造化
サービスネットワークでは機能間の関係を明確にすることができるが，機能のシステム上での位置づけは曖昧である ． そ こ で ， サ ー ビ ス ネ ッ ト ワ ー ク に 対 し て MVC（Model-View-Controller）を用いて分類するゴール分析の方法を提案する．

2. ビジネスモデル
ビジネスモデルとは，ビジネスの仕組みや構造を形式的に表現したものである．その目的は，ビジネスの構造の理解を容易にすることである．
2.1. ビジネスモデルのパターン
ビジネスモデルは，ビジネスを実行したい顧客やサプライヤなどのステークホルダーに着目し，表 1 に示す 5 つに分類できる[4]．
表 1： ビジネスモデルの分類
分類
内容
配給業
一旦商品を買い取り，再び販売(Distributor)
原材料や部品を供給者から購入し，加創造業(Creator)
工や組み立てを行い，商品として提供
売り手と買い手の仲介を行い，両者の仲介業(Broker)
やり取りが円滑に進むように支援
自然やその場所から収集された資源収集業(Extractor)
を販売
サービス供給業
顧客から材料を受取り，成果物を返す(Service Provider)2.2. モデル化の手順
本研究では配給業と仲介業に着目し，既存の電子商取引システムを分析し共通点や相違点を考慮し，モデル化を行う．まず，ユースケース分析により機能の抽出を行う．次に，シーケンス分析を行いシステムの振る舞いを分析する
ことで，機能間の繋がりを明確にする．

4. 実例に基づく分析
最も一般的な電子商取引システムであるアマゾン[6]，楽天[7]を例題として，ユースケースとビジネスゴールを検証する． 分析結果の信頼性を高めるために，bk1，三省堂，BIGMALL，Yahoo ショッピングの分析も行う．
4.1. アマゾン
アマゾンでは一つの専門店のみでショップを運営している．アマゾンは，出版社から一旦商品を買い取り，再び販売する，配給業に分類できる．
（1）ユースケース分析
アマゾンの全体構造をユースケース図で表し，ビジネス要求と構造を分析する．（図 1）南山大学 数理情報学部 情報通信学科 卒業研究 発表予稿
る．Model は，データベース，注文履歴情報となる．MVCの分類により，Controller の部分と処理の中枢を担う Modelとの関連が明らかになった．
どこでも購入可能

いつでも購入可能

多数の蔵書欲しいものが見つかる

使いやすい

入力の手間を省く

個人毎のWebコンテンツとサービス関連情報へのアクセス専用のページを作る

図 1： アマゾンの全体構造（2）サブゴール分析
図 2 に示すように，アマゾンのビジネスゴールは，書籍販売による自社の利益獲得である．サブゴールは，多くのユーザの獲得である．また，ユーザ要求を満たすことが必要となる．ゴールを分析すると，図 2 に示すようにゴールを階層化できる．

過去の注文を見る
顧客情報を登録・変更

顧客情報の管理ページの アカウント
カスタマイズ サービス

顧客DB

簡単な購入手続き

書籍内容・書評の紹介

低価格

低コストで在庫管理

Webページの利用低コストで配送

書籍取次店 アウトとの契約 ソーシング

Web上での書籍検索

Web上での書籍カタログ
支払いシステム
発注システム

その人に合った本の推薦

過去の注文管理

注文履歴

発注のための１Click
書籍情報の管理

検索機能

書籍DB

決算システム

在庫DB

図 3： アマゾンの MVC サービスネットワーク
4.2. 楽天
多くのショップが一つの Web 上に集まり，Web ショッピン
グモールを形成している．楽天は，売り手と買い手の仲介を果たしているため仲介業に分類できる．
（1）ユースケース分析
楽天の全体構造をユースケース図で表し，ビジネス要求と構造を分析する．（図 4）楽天は，売り手と買い手との仲介役のため，顧客に対する機能のほかに，出店者への機能が存在する．

図 2： アマゾンのゴール分析（3）サービスネットワークによるゴール分析
アマゾンの提供価値は，「オンライン書籍販売」，「多数の蔵書」，「簡単な購入手続き」，「低価格での書籍販売」の４つが挙げられる．それぞれに対し，ケイパビリティを定義していくと機能やデータベースを抽出することができた．
（4）MVC によるサービスネットワークの分類
アマゾンを MVC により分類すると，図 3 になる．
Controller として，検索機能やアカウントサービス，決算システムのほかに，1-Click，ページのカスタマイズが分類され

図 4： 楽天の全体構造南山大学 数理情報学部 情報通信学科 卒業研究 発表予稿
（2）サブゴール分析
図 5 に示すように，楽天のビジネスのゴールは，出店者からの利益の獲得である．サブゴールは，多くの出店者の獲得である．出店者は，多くのユーザが支持しているブローカを活用することで多くの顧客獲得を期待している．そのため，多くのユーザから支持されているモールでなければならず，ユーザ要求を満たすことが必要と考えられる．このように，ゴールを分析していくと図 5 に示すようにゴールを階層化できる．

る RMS 機能が分類される．Model はデータベースとなる．
それぞれ MVC の分類により，Controller の部分と処理の中枢を担う Model との関連が明らかになった．
どこでも購入可能

いつでも購入可能

買う以外のサービス

入力の手間を省く

欲しいものが見つかる

使いやすい関連情報へのアクセスアカウント登録をせずに同様のサービスを受ける

整理・分類
された情報

多数の商品数低コストで配送

Webページの利用

アウト
ソーシング

Web上での商品検索

商品内容・レビューの紹介

低価格

以前に見たページを見る
Web上での商品カタログアカウント登録をして特典を受ける

過去の注文を見る

支払いシステム

顧客情報を登録・変更

ページ閲覧
履歴機能

顧客情報の管理

商品情報の管理

検索機能

発注管理

アカウント
サービス
決算システム
注文履歴

買い物かご
DB

顧客DB

商品DB

在庫DB

図 6： 楽天（顧客）の MVC サービスネットワーク
誰でも購入可能

簡単な出店手続き

出店のための機能

Webページの利用

売上の増大

集客プロモーション図 5： 楽天のゴール分析（3）サービスネットワークによるゴール分析
楽天では，顧客と出店者に対して価値を提供しなければならない．顧客に対する提供価値は，「オンライン販売」，「多数の商品数」，「買う以外のサービス」，「整理・分類された情報」，「低価格での商品販売」の 5 つが挙げられる．また，出店者に対する提供価値は，「出店サポート」，「店舗運営のバックアップ」の 2 つが挙げられる．それぞれに対し，ケイパビリティを定義していくと機能やデータベースを抽出することができた．
（4）MVC によるサービスネットワークの分類
楽天の顧客側を MVC により分類すると，図 6 に示す
Controller として，検索機能やアカウントサービス，決算システムのほかに，ページ閲覧履歴機能が分類される．Modelは，データベース，注文履歴情報となる．
楽天の出店者側を MVC により分類すると図 7 になる．
出店者側の View ではスタッフが分類された．また，Controller として配送・決算優遇プログラムや店舗を構築す

ノウハウ・サポート

低コスト

商品アピール

DMの配信

支払いシステム

発注システム

情報の管理

配送・決算優遇プログラム

受注管理

商品情報の管理

顧客情報の管理

売上管理

在庫DB

商品DB

顧客DB

RMS機能

買い物かご
DB

運営のためのサポート

売上からの分析結果

アドバイス

スタッフ

図 7： 楽天（出店者）の MVC サービスネットワーク

5. 電子商取引のパターン化
アマゾンと楽天の相違点の背景には，ビジネス目的の違いが存在することが明確になった．ビジネスの目的の違いによって機能や構造，振る舞いが変化すると考える．このことから，以下のようなユースケースモデルを提案し，それぞれパターンとしてアマゾン型，楽天型と名付けることにする．

南山大学 数理情報学部 情報通信学科 卒業研究 発表予稿
(1) アマゾン型
図 8 は，アマゾン型のユースケースである．配給業の共通機能となる．インターネットを用いた小売市場において，アマゾン型を基礎としてシステムを開発できると考える．

づけを理解することができるため，MVC を用いることでより一層詳しく定義できると考えられる．そのため，MVC を用いたサービスネットワークがゴール分析に有効であると考えられる．
（2） パターン化について
配給業ではアマゾン型，仲介業では楽天型が類似の電子商取引システムを包括した構造となっていることから，パターンとして一般性があると言える．パターンにゴール分析を組み合わせて，追加機能を効率的に抽出できると考えられる．

7. 今後の課題

図 8： アマゾン型のユースケース構造(2) 楽天型
図 9 は，楽天型のユースケースである．仲介業の共通機能となる．電子商取引市場は，楽天型を基盤としてシステムを開発できると考える．

本研究では，既存の電子商取引システムを用いてゴール分析を行ったため，外部の視点から提供価値を定義した．
しかし，実際にシステムを開発する際には，システムの内部を考慮した提供価値を提供しなければならない．そのため，提供価値の決定方法が課題となる．また，MVC のサービスネットワークにより抽出された機能が，システムの内部設計とどのように結びつけるかが問題となる．
提案したパターンを用いて実際にシステム開発を行う際に，柔軟に開発が行えるパターンであるかを検討する必要がある．また，表 1 の他の分類においても有効であるか検討する．

8. まとめ本研究で提案したゴール分析の方法は，ユーザ要求を満たすシステムを，効率的に分析できることを示した．さらに，提案した MVC を用いたサービスネットワークによるゴール分析は，ソフトウェアアーキテクチャとゴールとの対応付ける方法として利用できる．今後の課題を検討することで，さらに発展していくことを期待する．

図 9： 楽天型のユースケース構造

参考文献
[1]

6. 考察
（1） ゴール分析について
サブゴール分析では，ゴールを繰り返し定義していくため，ビジネス要求を中心に機能を抽出できた．しかし，実際のシステム開発では，機能間の関係を理解することも重要であると考えられる．サブゴール分析では，機能間の関係を理解することができなかった．
そこで，サービスネットワークを用いてゴール分析を行い，さらに MVC を用いることで，ユーザインタフェースとソフトウェアアーキテクチャに分類できた．システム上での位置

[2]
[3]
[4]
[5]

[6]
[7]

樋口節夫ほか，Web システムのデザインパターン，翔泳社，2003.
I.ヤコブソンほか，ビジネスオブジェクト，ユースケースによる企業変革，トッパン，1996.
中桐紀幸，即戦UML モデリング，リックテレコム，2001.
管坂玉美ほか，e ビジネスの理論と応用，東京電機大学出版局，2003.
IBM ビジネスコンサルティング サービス IT 戦略グ
ループ，エンタープライズ・アーキテクチャ，日経 BP
社，2003.
アマゾン,http://amazon.co.jp/.
楽天, http://www.rakuten.co.jp/.