ソフトウェア・シンポジウム 2022 in 盛岡

COTS 利用プロジェクトへの GSN の適用
田中 康
有限会社ケイプラス・ソリューションズ，奈良先端科学技術大学院大学
ytanaka@kplus-solutions.com，yasushi-tanaka@is.naist.jp
要旨
業務改革や新サービス開発，そして，IT システムの新規開発およびシステム刷新プロジェクトのコスト超過や有用性実現の失敗を解決するために，業務プロセス設計
主導によるシステム要件定義の取り組みを行なっている[1]．しかし，業務プロセス設計はユーザ企業の参画含め，現状の業務プロセスを分析し，改善のための業務プロセスを再設計するといった一連の過程を踏む必要があり，期間とコストがかかることが実施を困難にする要因のひとつであった．
業 務 で の 活 用 思 想 が 明 確 な COTS （ Commercial
Off-The-Shelf）製品を適用するプロジェクトでは，業務プ
ロセス設計フェーズに GSN（Goal Structuring Notation）[2]を適用することによって，現状プロセスのモデル化と分析の過程を踏まずに，あるべき業務プロセスをトップダウンに設計することができ，さらに，実働，期間共に大幅な短縮を実現することができた．

われる「業務レベル」を中心に，目標とする経営ゴールが定義される「経営レベル」，業務を支援する IT システムに対する要求仕様が定義される「要求仕様レベル」の 3 層を定義している．
業務レベルでは，経営目標達成を阻害している業務
プロセスの問題を特定するために，現状の業務（As-is 業務）プロセスをモデル化して問題の発生原因の分析を行う．そして特定した原因分析をもとに，あるべき業務（To-be 業務）の設計を行う．

経営レベル

経営目標

As-is
業務プロセス

業務レベル

要求仕様レベル

As-is
IT システム仕様

業務改善へ

To-be
業務プロセスTo-be
IT システム仕様
IT システム開発へ

1. はじめに

図 １ 逆 V モデル

一般的な上流工程のアプローチは，ユーザからの要求を受け取り，受け取った要求をシステム要件として解釈して定義し，ユーザとの合意を得るところがプロジェクトの開始地点となっている．しかし，今でもなお，約半数近くの IT システムの導入や刷新プロジェクトが失敗に終わっている．さらにその主要な要因に関しても，要件定義をはじめとする上流工程の不備にあることが原因としてあげられている．この状況はソフトウェア工学がはじまって以来続いている[3]．このような上流工程での問題に対して筆者は，「逆 V モデル」と呼んでいる業務プロセス設計主導
での上流工程アプローチを行なっている[1][4]．

1.2. 逆 V モデル実行上の課題
筆者は，日立製作所との協業で，様々なプロジェクトに対して逆 V モデルを適用し，実績を積み上げてきた．
しかし一方で，逆 V モデルに従って業務プロセスの分析と設計を行う場合，前半の As-is 業務プロセスのモデル化と分析に約 1.5 ヶ月，To-be 業務プロセス設計に約 1.5 ヶ月の期間が平均して必要となる．
さらに，業務プロセスの分析と設計を行うためには，ユーザ企業から複数名の参加者を頼まなければならない．
参画を頼むユーザ企業側の人員は，対象業務に精通している必要があり，また，設計した業務を現場に実装するフェーズでは，業務改革の推進的な役割も担う人員である必要があるため，ユーザ企業で中心的な役割を担っている社員である場合が多く，そのような人員の工数を確保することが難しい場合も多い．

1.1. 業務プロセス設計のための逆 V モデル
逆 V モデルとは，図 １に示すように，開発の V モデル
を逆さまにした形のプロセスであることから命名したものである．逆 V モデルは，業務プロセスの分析と設計が行

85

SEA

ソフトウェア・シンポジウム 2022 in 盛岡

ユーザ企業側に業務マニュアルなどがある場合は，それらをもとに現状のプロセスを記述することによって As-is
業務のモデル化の期間を短縮することもできる．しかし，業務マニュアルが実際の業務を十分に反映していない場合も多く，正確な As-is 業務をモデル化することができないこともある．業務の問題分析をするためには，精度の高い As-is 業務プロセスモデルが無いと，問題を発生させている原因の特定が難しくなってしまう．正しく問題を特定することができないと，To-be 業務プロセス自体の設計品質も低くなってしまう．
逆 V モデルに従った上流工程では，業務プロセスの改善と，改善設計された業務プロセスからそれを支援す
る IT システムの要件を導出することができるため，改善された業務プロセスの定義と，それを支援する IT システムの仕様とのトレーサビリティーを確保することができる．その一方で，上流工程に期間とコストがかかることが問題であった．
そ の よ う な 中 ， Salesforce 社 の SFA （ Sales Force
Automation）という営業支援ツールの導入プロジェクト支援の依頼があった．しかし短期間で結論を出さなければならないという制約があり，逆 V モデルの適用が難しいと判断した．代替のアプローチ方法を検討する中で，業務プロセス基本設計へ GSN を適用することによって，プロ
セス設計を効率よく進められるのではないかという仮説レベルで検討を進めていた方法を適用することとなった．

ールには，それが実現されていることを示す証拠が接続される．
システムの安全性を担保するためには，与えられた前提条件のもとで，さまざまな方法（戦略）を考えることができる．前提条件を満足しているのであれば，どの戦略が正しいということではない．GSN を用いてゴールを達成するための戦略を定義し，戦略を実現するための内容が戦略実現に対して十分であれば，末端のノードである証拠を上げることによって，遡求的にゴールが達成できることを保証することができるという論法である．

ゴール
達成すべき内容

戦略
検討方針

サブゴール
検討方針に従って分解した内容

前提
検討方針の前提

サブゴール
検討方針に従って分解した内容

証拠

2. 業務プロセス設計への GSN 適用の検討
欧州では近年，システムの安全性を確保する責任が開発者や運営者に移行している．そのような中，開発するシステムが，要求される安全レベルを達成していることの根拠のある論拠を構築し提示することが求められている[2]．GSN は，そのようなシステムの安全性論証などで用いられる記法である．

図 ２ GSN COMMUNITY STANDARD VERSION 1 に基づ
く GSN の代表的な記法

2.2. PReP モデルへの GSN 適用の検討
逆 V モデルでは，業務レベルの設計方法として PReP
（プレップ）モデルを用いている．PReP モデルは，業務プ
ロセスを，「成果物」と呼んでいる概念実体の関係で構造的に記述するプロセス記述手法である[4] [5]．
設計には，その前提条件と，検討された方略がある．
多くの場合，設計された結果は提示されるが，その裏で検討された戦略が明示的に記述されることは少ない．さ
らに，戦略検討の前提条件が整理されて記述されることも少ない．
PReP モデルを用いて逆 V モデルの右側である，業務プロセスの設計を行う際にも，実現のための戦略があり，その前提となっている条件がある．現時点での PReP モ

2.1. GSN の記法
GSN の一般的な記法を図 ２に示す．GSN では，システムが達成すべきゴールと，ゴール達成を実現するための方法や考えかたを構造的に可視化するための記法が定義されている．GSN のトップレベルには，システムが達成すべきゴールが定義される．ゴールの下に，達成すべきゴールを実現するために検討された方針が戦略として記述される．戦略には，戦略が達成されるための前提条件が紐つく．そして，戦略を実現するための方略がサブゴールとして戦略の下に展開される．それぞれのサブゴ

86

SEA

ソフトウェア・シンポジウム 2022 in 盛岡

デルは，設計の結果のみが記述される仕様であるため，検討された戦略やその前提条件を整理する記法は組み込まれていない．GSN は，PReP モデルを記述するツール開発の検討の中で To-be 設計をする際に適用が検討されていた．

フトウェアを毎回開発するとなるとコストが高くなってしまう．
そこで，十分な品質や機能が確認されている市販の既製品，すなわち COTS を活用することで開発期間の短縮やコスト削減を行うことが研究された．民生分野においても同様に，システム開発の一部，もしくは全体に市販製品を採用することを COTS と呼んでいる．
近年では，クラウド上にアプリケーションや API を配備することによって，ユーザー企業がすぐに COTS を利用することができるサービスである SaaS（Software as aService）も主流となっている．Salesforce 社の SFA もそのような COTS のひとつである．特に，営業業務領域でのSalesforce 社の製品はデファクト的な存在であり，多くの企業が導入を試みている．

2.3. 類似手法と本アプローチとの違い
ゴールとゴールを達成するための戦略とその達成方
法を構造的に分析・展開する類似のアプローチとして，
ゴール指向のソフトウェアメトリクス手法である GQM（Goal-Question-Metric）[6]に組織戦略の観点を加えた
GQM+Strategies の研究がある[7]．
GQM+Strategies の研究では，例えば早稲田大学ゴー
ル指向経営研究会は，組織目標と戦略の整合化への適用を目的としている[8]．この研究は，バランスト・スコアカード（Balanced Scorecard）[9] などと同様な目的を持つものであると考えられる．すなわち，企業の経営目標と，そこから展開される組織戦略とを整理し，さらに財務指標などのメトリクスとの整合性を管理する方法として
GQM+Strategies の応用を研究しており，組織目標管理が主要な関心事となっていると理解される[10]．一方で，PReP モデルでは，業務プロセスと組織とは直行するものであるとしている．組織は企業内のリソースを管理するための手段であり，企業価値を生み出すものはあくまでも業務プロセスであると考えている[4]．
また，高井らは，経営目標からシステム要件をつなぐ方法として，GQM+Strategies の適用研究を報告している[11]．高井らのアプローチは，GQM+Strategies を用いて経営目標から構造化された戦略と戦略達成のためのサ
ブゴール構造をシステムエンジニアに引き渡す．システムエンジニアはそこからユースケースなどを用いてサブゴールを実現するためのシステム要件を展開して SysMLのアクティビティ図などに展開する．一方で PReP モデル
は，高井らのアプローチである GQM+Strategies を用いた
ビジネス分析とシステム要件定義の間を接続する方法であると考えることができ，概念実体による構造観点で業務プロセスをモデル化することによって，設計した業務プロ
セスとシステム要件とのトレーサビリティーを確保している[4] [5]．

3.1. 失敗率の多い COTS プロジェクトシステム導入や刷新プロジェクトの約半数の 47.2％が失敗に終わっているという日経コンピュータの調査報告[3]では，最も失敗しやすいシステム導入プロジェクトの報告もある．成功率が最も低かったプロジェクトは CRM（Customer Relationship Management）と SFA で，その成功率は 43.7%であった．まさに，導入プロジェクトの 6 割近くが失敗に終わっている．
業務で用いられる COTS 製品の中でも，例えば会計関係のツールは，会計業務自体が標準化されているため，仕様も固定化しやすい．一方で，顧客管理や営業業
務は，その業務プロセスが標準化されておらず，人に依存している部分が多い．また，企業の文化などによって，活動方法などもさまざまであったりする．そのため，仕様変更が相次いだり，COTS に収まらない部分の追加開発が多くなったりしてしまい，最終的に，COTS 利用の目的である開発期間短縮やコスト削減が実現できない結果となってしまうと考えられる．
3.2. COTS プロジェクト失敗の要因
このような COTS プロジェクトの失敗要因と原因構造を
営業支援ツールの導入を例に考察する．COTS 製品導入プロジェクトを見ると，開発者としては，導入する COTS
製品の仕様を確定したいと考える．検討した仕様を営業部門に説明するために，COTS 製品がどのように動作するか，もしくは，製品をどのように使うのかを説明する資料が作られる．例えば，「名刺情報を取得する」や「取引先を登録する」といった操作が記述された資料が作成される．これらの記述は，一見，業務プロセスを記述しているように思えるが，実際には，システム開発者が検討してい3. COTS 活用とその失敗
防衛産業や航空宇宙産業などでは，そこで利用されるソフトウェアの品質が人命に直結するため，非常に高い品質が求められる．一方で，高い品質が要求されるソ

87

SEA

ソフトウェア・シンポジウム 2022 in 盛岡

4. 人依存の業務プロセスに COTS を適用するにはるシステムの仕様を記述したものである．
IT システムは，業務を支援するための手段である．そのため，まず業務プロセスを定義し，定義された業務プロ
セスのどの部分をどのように支援するかといった観点でシステムの仕様が定義されるべきである．前述の逆 V モデ
ルは，このような業務レベル設計を中心にして，IT システ
ムの仕様を定義するための方法を示すものである．
しかし，図 ３に示すように，COTS 製品が適用される先の営業活動の業務プロセスが定義されていない状態
で COTS の仕様を定義しようとすると，仕様が見えてくる
過程で，見えてきた仕様に対する要求が変動したり，「それだったら，このようなことができる機能も欲しい」といった機能追加が要求されたりする．

日本の場合，営業活動が人に依存している部分が非常に多いと想定される．実際に，依頼のあった Salesforce
SFA の導入プロジェクトでも，人依存の営業活動からの脱却が経営目標となっていた．
プロセスが人依存の状態は，ソフトウェア開発組織の能力成熟度モデルでは，レベル 1 と診断される状態である．営業活動は場当たり的であり，活動がうまく進む場合もあるが，成功は個人の能力に大きく依存してしまう．また，管理層からは，進捗の見通しが立たないといった状態である．
逆 V モデルに則って，現状のプロセスを定義しようとした場合，人に大きく依存した組織では，営業ごとに異なる
様々な活動から，統一的，もしくは標準的な活動をモデル化する必要があり，時間とコストが非常にかかると予想される．このような人依存の組織に対して As-is の分析からはじめる逆 V モデルはコスト的に見合わないのではないかと考えられる．しかし，それ以上に COTS 製品を導入する場合に問題となる点がある．

営業活動

機能追加
COTS仕様
仕様変更

4.1. 逆 V モデルに準じても失敗してしまう可能性
COTS 製品はその設計背景に，特定の業務の進めか
たや，想定されている利用方法があると考えられる．そのため，COTS 製品の導入が目的化された場合，業務プロ
セスの改善が先行せずに，導入した COTS 製品に仕事の仕方を合わせるといった逆転が起こりがちである．
また，COTS 製品の中には，導入先からの様々な要求を受け入れて，当初考えられていた以上の機能が盛り込まれていくものもある．その結果，機能が総花的になってしまい，業務での利活用方法が複雑になったり，曖昧化
してしまったりする製品もある．
一方で，しっかりとした業務設計思想に基づいて設計された COTS 製品では，スコープとして想定している業務での活用方法も明確である．ところが，その活用方法を十分に考慮せずに To-be 業務プロセスを設計してしまうと，
図 ４に示すように COTS 製品の仕様の背景にある業務プロセスとの差異が潜在してしまう．その結果，設計した
To-be 業務プロセスから導出されたシステム要件と，COTS 製品仕様との不整合が生じてしまう可能性がある．

COTS仕様図 ３ COTS 導入失敗要因．COTS 製品を適用する先の営業
活動の業務プロセスが定義されていない状態で COTS を適用
すると，機能追加や仕様変更が発生してしまう．

88

SEA

ソフトウェア・シンポジウム 2022 in 盛岡

5. COTS 導入プロジェクトでの GSN の適用
To-be業務プロセス

差異

COTS仕様背景にある
業務プロセス

要求と仕様の不整合

反映

COTS仕様図 ４ To-be 業務プロセスと COTS 仕様と COTS 仕様の背景にある業務プロセスの整合性の問題

4.2. COTS 製品仕様の背景にある思想を取り込む
Salesforce SFA は，米国でのインサイドセールスや営業の考えかたが背景にある製品である．その考えかたは「ザ・モデル」として書籍化されている[12]．
日本での営業活動が未だに人依存であるのに対して，
米国では，顧客が地理的に離れたところに散在しているという問題から，効率の良い営業プロセスが検討，設計されてきた．Salesforce SFA を使用するということは，この設計された営業プロセスを取り入れるということでもある．製品仕様の背景にある長年検討され，設計された業務プロ
セスを取り入れることによって，自社の業務プロセス自体を加速的に改善することも期待できる．
しかし一方で，多くの COTS 製品は，製品仕様の背景にある業務プロセスが，導入先の業務プロセスのどの部
分にどのように組み込むべきかかが明確に定義されていない場合がある．Salesforce SFA の場合も，手元にあるのは「ザ・モデル」という書籍だけであった，そこから To-be
業務プロセスを一足飛びに導き出すことは難しいように思えた．そこで，その中間段階として，「ザ・モデル」を参照して，今回の顧客の経営的問題を解決するための業
務プロセスの基本設計にあたるものを記述してはどうかと考え，以前検討をしていた GSN の適用を試行した．

COTS 製品の導入は，それが目的ではない．あくまでも経営ゴール実現が目的であり，COTS はそのための手段である．一方で，COTS 製品は，その設計思想として，経営レベルのゴールが定義されているはずである．そして定義されたゴールを実現するための業務プロセス，そして業務プロセスを支援するために，その製品の仕様が決定されているはずである．しかし，COTS 製品の仕様の背景にある経営ゴールが，自社の経営ゴールと完全に一致するとは限らない．COTS 製品を経営ゴール達成のための手段として取り入れるならば，COTS 製品に想定されているゴールを評価して，自社に組み込む部分を検討し，そして選定する必要がある．
COTS 導入プロジェクトにおけるゴール選定から，業務
設計，そして仕様定義までの考えかたと GSN 適用の基本的なアプローチを図 ５に示す．まず，COTS が想定するゴールから自社の経営ゴールに組み込む部分を選定する．これに，GSN のゴール定義記述を用いる．次に，ゴールを実現するための戦略を COTS 仕様の背景から定義する．これに，GSN の戦略と戦略の前提条件記述を用いる．さらに，戦略を達成するための方法をサブゴールに展開する．展開したサブゴール構造が業務プロセスの基本設計となる．この基本設計をもとに，PReP モデルによって業務プロセスの詳細設計を行う．PReP モデルでは，設計した業務プロセス上で，それを実行するためのシステムを計画し，システムの要件を定義する．これによって，ゴールからトレーサビリティーの取れたシステム要件までを構造的に導出することができる[4]．

COTS設計思想

経営ゴール
COTSゴール

COTS仕様の背景にある業務プロセス

COTSが想定するゴールから自社の経営ゴールに組み込む部分を選定する→ GSNのゴール定義

営業プロセス
COTS適用プロセス

COTS仕様選定したゴールを実現することのできる
COTS仕様の背景にある業務プロセスを定義する→ GSNの戦略定義とサブプロセス定義→ GSNを基本設計として，PRePモデルで詳細化する

PRePモデルによって設計した業務プロセスから
システム要件を定義する

図 ５ COTS 導入と GSN による業務プロセス設計の流れ

89

SEA

ソフトウェア・シンポジウム 2022 in 盛岡

6. Salesforce SFA での GSN 適用の実際

6.2. 戦略の検討

前項の図 ５に示した流れに沿って GSN を適用して，
To-be 業務プロセスの基本設計を行なった．基本設計のための入力としては，Salesforce SFA の背景となっている
書籍「ザ・モデル」を参照した．基本設計の結果を図 ６に示す．GSN による業務基本設計の実例を、順を追って説明する．

このように定義したゴールを達成するための戦略はいろいろ考えられるが，今回は「営業戦術を外材化し利用する」と定義した．人依存の状態では，効率的に営業活動を行なっている人と，そうでない人がいる．効率的に営業活動を行なっている人の知見を外材化して組織として再利用することができれば，全体としてのリソース効率が上がると考えたからである．
今回のプロジェクトのヒアリング時にも，組織課題として，
人依存の状態からの脱却が挙げられていた．ベストプラ
クティスとしての知見を組織として再利用できる状態にすることによって，特定の人の能力に依存する状態から，組織として管理された状態にレベルを上げることができると考えられる．

6.1. ゴールの設定
組織への Salesforce SFA 導入のゴールとしては，「営業リソースが効率的に活用されている」と設定した．このようなゴールを設定した理由としては，「ザ・モデル」で解説されている営業プロセスの背景に，役割の明確な定義と機能分割による効率的な営業活動が目的であることを読み取ったためである．また，営業活動では，重要な資源は人であり，人という限られたリソースが効率的に活用されている状態は，経営視点から考える営業活動のゴールとして十分性があると考えたからである．
ゴール

営業リソースが効率的に活用されている戦略の前提条件戦略

サブゴール

営業戦術を外材化し利用する

営業戦術定義属性が定義されている

営業進捗に照らして戦術が策定され進捗に照らして見直されている

定義された営業戦術が個々の営業に活用されている

営業進捗が報告されている

戦略と戦術の評価用に
フォーキャストが集計されている

営業基本戦略が年度営
業目標と営業進捗に照らして見直されている

営業戦術策定営業活動

営業進捗報告フォーキャスト集計

営業戦略評価当該顧客営業戦術

営業進捗

パイプライン進捗

フォーキャスト

営業基本戦略

更新された
（属性）

状態
（属性）

更新された
（属性）

更新された
（属性）

更新された
（属性）

サブゴール実行プロセス想定される管理
すべき主な成果物

図 ６ Salesforce SFA 適用の業務基本設計として GSN を利用した例

90

SEA

ソフトウェア・シンポジウム 2022 in 盛岡

GSN での戦略定義では，定義した戦略の前提条件の定義が重要である．どのような状態であれば，営業戦術を外材化し利用できるかが今回の前提条件となる．
一般的にも，知見を外在化するには「何を知見として外材化すべきか」の定義が重要である．能力のある人が，自分がなぜそれをうまくやっているかを適切に言語化できるとは限らない．うまく行なっている行為を構成する独立した要素を言葉として定義すること自体が，技術として重要な部分である．
これに対しても「ザ・モデル」の中で，例えば「（営業）パイプライン」といったような営業活動を管理するための言葉が要所要所で説明されていた．それらの考えかたを整理して，営業フェーズごとに必要となる活動と管理を定義する言葉を整理した．整理と構造化には，図 ７に示す
ように，マインドマップを使用した．























する」といったように，それぞれがひとまとまりの活動である．業務プロセスをモデル化するための考えかたをまとめ
た PReP モデルでは，経営ゴール達成のリスクを管理する
ためのひとまとまりの活動を一つの業務として定義している[4]．GSN で定義したサブゴールも，検討された戦略を実行するひとまとまりの活動であり，PReP モデルで定義する一つの業務に対応すると考えることができる．この部
分は，GSN と PReP モデルとをシームレスに繋げる上で重要な点である．そこで，サブゴールの下に，それぞれひとつずつの業務を紐付けた．
さらに，各業務から出力される主要な成果物を定義し，定義した成果物と各業務との入出力関係から，基本となる業務間の構造を定義した．業務とそこから出力される
主な成果物（ひとつとは限らない）によって業務の基本関係を記述することを，PReP モデルでは業務鳥瞰図の作成と呼んでいる．対象スコープに含まれる業務とそれらの関係を俯瞰するという意味である．ここまでの段階で，GSN を使ってゴールの定義から PReP モデルの鳥瞰図までを展開することができた．



6.5. To-be 基本業務プロセスの構文設計ÃʍɽʍƃȢ:ȢɁɰǉĀȢƃȶ

GSN を用いた業務基本設計は，業務の静的な関係構
造のモデルである．設計では，構造的モデルに加えて構
文的なモデル（時間軸での関係）も必要である．そこで，それぞれの業務に登場すると考えられるアクターと，各業
務プロセスの構文的な関係を図 ８のように定義した．図６で定義した「営業戦術策定」は週次で駆動するとした．
商談後の「営業進捗報告」は日次で行い，その結果が「フォーキャスト集計」される．集計された結果をもとに営業戦術が「営業戦術策定」の中で週次で見直される．月
次で集計されたフォーキャストをもとに，営業目標に対する進捗が評価され，全体の戦略を見直すための「営業戦略評価」が会議体として開催される．このような定義はあくまでもひとつの設計であり，様々なバリエーションが考えられる．ここで設計した基本プロセスが妥当であるかは，
導入先の組織の判断に委ねられる．












 ӗ




ӗ

ӗ

ӗ

ӗ

ÝȴȈɽɽǉǁӗĀȈɥǉȢȈȶǉӗĩɥɰȈǁǉӗ:ɁȴȴȈɽӗŚɁȶ

























図 ７ マインドマップを使った営業活動フェーズごとに使用する概念の整理（部分）6.3. サブゴールの定義
基本設計の最後に，定義した戦略を実現するためのサブゴールを設計した．サブゴールの設計は，あくまでも設計行為であり，正解はないものである．ただし，ここでも「ザ・モデル」の中で記述されている営業やインサイドセ
ールスといった活度の記述から，戦略の実現に関連しそうな活動を抜き出して組み立てた．

Weekly
営業戦術策定担当マネージャ6.4. サブゴールへの業務の紐付け

担当営業

営業進捗に照らして戦術を策定し進捗に照らして見直す

定義したサブゴールは，例えば「営業進捗に照らして戦術を策定し進捗に照らして見直す」，「営業進捗を報告

Deily
商談

営業進捗報告Monthly
フォーキャスト集計

営業戦略評価

担当営業

担当営業

集計担当

会議体

定義された営業戦術を個々の営業が活用する

営業進捗を報告する

戦略と戦術の評価用にフォーキャストを集計する

営業基本戦略を、年度営
業目標と営業進捗に照らして見直す

図 ８ To-be 業務プロセスの基本設計

91

SEA

ソフトウェア・シンポジウム 2022 in 盛岡

6.6. To-be プロセスの詳細設計

景にある設計思想の把握から基本設計までが 2 日．基本
設計から PReP モデルによる業務プロセス詳細設計までが 1 日（実働は 3 時間）であった．

PReP モデルの鳥瞰図と基本的な構文設計ができあがれば，定義した業務ごとに詳細設計を行うことができる．
鳥瞰図では，それぞれの業務への入出力が定義されているので，それらを手がかりに，それぞれの業務プロセスを設計することができる．図 ９は GSN で定義した業務プ
ロセスを PReP モデルで設計した例である．PReP モデル
では，設計した業務プロセス上でシステム要件を定義す
るが，COTS 製品適用の場合は，COTS 製品で提供されている機能を PReP モデルの業務プロセス上にマッピング
することによって，COTS 製品でカバーできる範囲，あたらに開発が必要な部分などを特定し定義することができる．

表 1 To-be 業務プロセス設計までの時間および期間比較
方法

Goals

Date : 2022/03/13In1Ⴀᴗ㐍ᤖ䛻↷䜙䛧䛶ᡓ⾡䜢⟇ᐃ䛧㐍ᤖ䛻↷䜙䛧䛶ぢ┤䛩

2Business process goal 2

3

Business process goal 3

4

Business process goal 4

5Business process goal 5

Actor

Out

Ⴀᴗᡓ⾡䛾᭦᪂䛸ᢎㄆႠᴗᡓ␎▱ぢே㈈⟶⌮ID:o-3Ⴀᴗᇶᮏᡓ␎

ᙜヱ㢳ᐈႠᴗᡓ⾡᭦᪂䛥䜜䛶䛔䜛

ᢎㄆ䛥䜜䛯Ⴀᴗ䝕䞊䝍⟶⌮
ID:o-2ᢸᙜ䝬䝛䞊䝆䝱

Ⴀᴗ䝕䞊䝍⟶⌮
ID:o-2ᙜヱ㢳ᐈႠᴗᡓ⾡ᙜヱ㢳ᐈႠᴗᡓ⾡᭦᪂䛥䜜䛶䛔䜛

᭦᪂䛧䛯

期間（日）

16

56

GSN

4

4

（GSN/逆 V モデル）%

25

7

8. まとめႠᴗᡓ⾡⟇ᐃ
ID : 1-1

実働（日）逆 V モデルᢸᙜႠᴗႠᴗᇶᮏᡓ␎

᭦᪂䛥䜜䛶䛔䜛Ⴀᴗάືၟㄯ
ID:o-1

図 ９ PReP モデルによる詳細設計の例

7. 基本設計までにかかった時間・期間の比較
逆 V モデルと GSN それぞれに対して，業務プロセスの To-be 設計までにかかった期間と実働工数を表 1に比較する．逆 V モデルでの時間及び期間は，今回の SFA
導入ケースと同規模の業務を想定した場合の経験からの見積もり値である．また，期間はその長さを比較するため，
休日も含めた週 7 日で計算した．
逆 V モデルでは，ユーザ企業からの参加が必要であるため，分析や設計のためのワークショップを毎日開催することは難しいため，実質的に週に 1 回の開催サイクル
で進める場合が多い．そのため，期間としては長くかかってしまう．
今回の GSN を適用した設計にかかった期間としては，
ヒアリングに 1 日，「ザ・モデル」から Salesforce SFA の背92

今回の結果を見ると，設計思想が読み取れる COTS製品の場合は，GSN を利用して，その思想からトップダウンに To-be 業務プロセス設計を進めることによって，時間を大幅に短縮できる可能性があることがわかった．さらには，ユーザ企業からの参加者の時間拘束を行わずに，
To-be 業務の設計までを進めることができるため，コスト的にも大きな期待が持てる．
一方で，逆 V モデルの場合は，ユーザ企業からの参加者との協働によって現状の分析から設計までを進める．
そのため，To-be 設計が終わったと同時に，ユーザ企業
側の主要メンバーの共通理解の獲得と合意形成も完了
する．GSN を使ったトップダウン設計では，To-be 設計までが数日で済んだとしても，その結果を提示し，理解と合意を形成する工数と，その段階で差し戻しに合うリスクを考えると，1 回の設計ライフサイクルの単純な比較をするのは危険であるとも考えられる．
COTS 製品を開発する側への指針としては，総花的に機能を盛り込むのではなく，業務目的とその実行プロセスの観点からの明確な設計思想に裏付けされたソフトウ
ェア製品を開発することが，ユーザ側の業務に貢献する価値を提供するという観点では重要であると考えられる．
また，その設計思想を外材化し，できれば，想定している
ゴールとそれを実現する際の業務のあり方を再利用できる形式で記述するところまでを COTS 製品の開発として捉えることによって，ユーザ側での利用価値が上がるものと考えることができる．

SEA

ソフトウェア・シンポジウム 2022 in 盛岡

参考文献[1] 田中康, 渡辺薫, 超上流工程における業務プロセスのモデル化 -PReP モデルの BPM への適用-, ソ
フトウェアシンポジウム 2013，2013[2] Tim Kelly, Rob Weaver, The Goal Structuring
Notation - A Safety Argument Notation, Proc. of
Dependable Systems and Networks 2004 Workshop
on Assurance Cases, 2004
[3] 日経コンピュータ，2018 年 3 月 1 日号 pp.26-39[4] 田中康，PReP MODEL 現実世界をデザインする，
Amazon 出版，２０２２[5] 田中康，飯田元，松本健一，成果物間の関連に着目した開発プロセスモデル PReP，情報処理学会論文誌，2004 年「社会人学生」論文，2005[6] Victor Basili, G. Caldiera, Dieter Rombach, Goal,
Question, Metric Paradigm, Encyclopedia ofSoftware Engineering, Vol.1, pp. 528-532, 1994.
[7] Victor Basili, Adam Trendowicz, Martin Kowalczyk,
Jens Heidrich, Carolyn Seaman, Jürgen Münch,Dieter Rombach 著，鷲崎弘宣，小堀貴信，新谷勝
利，松岡秀樹 監訳，早稲田大学グローバルソフト
ウェアエンジニアリング研究所ゴール指向経営研究会 訳，ゴール＆ストラテジ入門：残念なシステムの無くし方（GQM+Strategies），オーム社，2015．
[8] 新谷勝利，平林大典，定量的な目標管理手法のウ
普及活動の展開〜組織目標達成と IT 導入の整合性 を 図 る 「 GQM+Strategies® 」 の 活 用 〜 ， SEC
journal, No.33, 2013.
[9] Kaplan R.S, Norton D.P, "The balanced scorecard:
measures that drive performance", Harvard Business
Review, Jan–Feb，pp71-80，1992．
[10] 鷲崎弘宣，新谷勝利，青木耀平，志村千万輝，野村典文，GQM+Starategies による組織目標と戦略の整合化及び目標定量管理の実践と拡張 -SEC WG
及び早稲田大学ゴール指向経営研究会の活動より-，SEC journal Vol.12 No.4 Mar. 2017.
[11] Toshinori Takai, Katsutoshi Shintani, Hideki Andoh,
Hironori Washizaki, Continuous modeling supports
from business analysis to systems engineering in IoTdevelopment, 2020 9th International Congress on
Advanced Applied Informatics (IIAI-AAI), 1-15
Sept. 2020.
[12] 福田康隆，ザ・モデル，翔泳社，2019

93

SEA