プロジェクトマネージャ 2018年 午後1 問01
SaaSを利用した営業支援システムを導入するプロジェクトに関する次の記述を読んで、設問1~3に答えよ。
E社は、中堅の運輸会社である。E社は、カスタマイズした営業支援ソフトウェアパッケージ(以下、現行営業支援システムという)を、自社に設置したサーバにインストールしている。また、パッケージベンダの保守サービスも利用した上で、自社の情報システム部で運用・保守をしている。利用者は営業活動を行う営業部の担当者、営業活動の実績管理などを行う営業部の管理者及び広告・宣伝活動を検討する事業企画部の担当者である。利用者のデータはマスタとなる人事システムのデータから取得している。全ての利用者に対して同一の利用者権限を付与しており、取得データには役職コードを含めていない。利用者は全ての営業活動の関連データが閲覧可能であり、機密性が高いデータは登録されていない。過去15年間のデータを蓄積しているが、業務に用いているのは直近5年間のデータである。
E社は、営業活動を高度化するために新たな営業支援システム(以下、新営業支援システムという)を導入するプロジェクトを立ち上げた。プロジェクトマネージャ(PM)には、情報システム部のF課長が任命された。
このプロジェクトは、営業活動の機密性が高いデータも用いた実績分析や広告・宣伝活動におけるターゲット分析などの業務の高度化対応に加え、システムの運用・保守の作業負荷軽減や運用・保守の費用の最小化、システムのキャパシティ拡張の柔軟性確保を目的としている。短期間での稼働開始が必須であることから、SaaSの利用を検討することにした。
プロジェクトの目的を踏まえ、複数社のSaaSを調査して、次の特徴を考慮した結果、役員会で新営業支援システムにはSaaSを利用することに決定した。
・様々なサービスがメニューとして用意されているので、利用者のニーズに沿って業務を高度化するサービスを利用でき、かつ、稼働開始までの期間を短くできる。
・サービスと機能の利用範囲、利用時間、サービスレベル、利用者数、データ容量などに基づき課金されるので、利用内容及び利用量に応じた費用負担となる。
・サービス提供者が、合意したサービスレベルで効率よくシステムの運用・保守を行うので、E社はシステムの運用・保守作業の負荷を軽減できる。ただし、用意されている機能を拡張するようなカスタマイズを行う場合は、カスタマイズ費用に加えて、拡張機能に対する保守費用も必要となる。
・月次などの合意した期間で契約の見直しが可能であるので、キャパシティ拡張の柔軟性が高くなる。
・サービス提供者のデータセンタにデータが保管され、機密レベルなどに応じた情報セキュリティ対策が講じられる。
〔システム化方針〕
F課長は、プロジェクトの目的達成に向け、SaaSの特徴を考慮して次のシステム化方針を定めた。
・複数社のSaaSを評価して、E社にとって最善のSaaSを選定する。
・高度化する業務に対して必要十分なサービスと機能を見極めて導入し、適切なサービスレベルで合意することで、過度な費用負担にならないようにする。
・業務の高度化に必要となる、機密性が高いデータも登録する。そのために、部署コード及び役職コードを用いて利用者権限を適切に付与し、所属部署及び役職に応じたデータを閲覧できるようにする。
・機能を拡張するようなカスタマイズはせず、業務プロセスを見直して、用意されている機能だけを用いることで、新営業支援システムを短期間で稼働開始させると同時に、aを図る。営業部の担当者は、見直した業務プロセスで日常的にデータを入力するので、日常業務に影響を受けることになる。そこで、営業部の担当者の業務負荷が許容範囲に収まるように、導入時に設定する画面表示や入力項目制御などを工夫する。また、新営業支援システムの稼働開始前に、習熟のためのトレーニングを行う。
・要件定義で、見直した業務プロセスや新営業支援システムの画面イメージに関して、利用者と意識合わせを確実に行い、要件定義以降の工程での手戻りのリスクを軽減することで、計画どおりに稼働開始させる。
・過去から現在までの利用者数、データ容量などの推移に基づき、過度にならない一定の余裕を見込んだ利用量で初回の契約を締結する。また、月次で利用者数、データ容量などの推移を把握し、bを確認する。
〔SaaSの選定〕
F課長は、SaaSの特徴を考慮して、現行営業支援システムの登録データのうち、今後の業務に用いる最小限のデータだけを新営業支援システムに移行して、残りのデータは外部媒体に保存することにした。現行営業支援システムの登録データと新営業支援システムへの移行内容を表1に示す。

F課長は、システム化方針、表1に示す現行営業支援システムの登録データと新営業支援システムへの移行内容、及び表2に示すSaaS選定の観点から、複数社のSaaSを評価した。その上で、Z社のSaaSを利用することを役員会に報告し、承認を得た。

〔要件定義〕
F課長は、情報システム部の担当者、営業部の管理者及び担当者並びに事業企画部の担当者から成るワーキンググループを組織し、要件定義を行った。ワーキンググループのメンバは、Z社のSaaSのメニューから利用するサービスを選定し、サービスに用意されている機能を前提として新営業支援システムの要件を整理した。その上で、システム化方針を踏まえ、整理した要件の採否を次の観点から判断した。
・業務の高度化に寄与するものであり、業務遂行に対して過度になっていないこと
・c
ここで、機能要件の整理・採否の判断に際しては、Z社から提供を受けた操作画面のサンプルを用いて、営業部の担当者が入力などを行った。このように、ワーキンググループのメンバが動作状況を確認することで、見直した業務プロセスや新営業支援システムの画面イメージの意識合わせを確実に行った。また、ワーキンググループのメンバが具体的な動きを確認することで、cの確認も行った。
非機能要件の整理・採否の判断に際しては、SaaS選定時に整理した業務処理量及び障害時の最低限の業務継続の範囲を前提として、サービス時間及び目標復旧時間などを定義して、これらに合致するサービスレベルで合意した。
設問1:〔システム化方針〕について、(1)、(2)に答えよ。
設問1(1)
問題文を見る新営業支援システムの導入において、用意されている機能だけを用いる狙いは何か。aに入れる狙いを20字以内で述べよ。
模範解答
a:システムの保守費用の最小化
解説
解答の導き方
-
空欄の前後には、用意されている機能だけを使って新営業支援システムを短期間で稼働開始させ、「同時に」何を図るかが示されています。したがって、稼働開始の短縮とは別の効果を考えます。
-
SaaSの特徴として、用意された機能を拡張するカスタマイズには「カスタマイズ費用に加えて、拡張機能に対する保守費用も必要」とあります。カスタマイズを行わなければ、この拡張機能に関する保守費用を避けられます。
-
システム化方針では、機能を拡張するカスタマイズをせず、業務プロセスを見直して用意された機能だけを使うとしています。これは、カスタマイズによって発生する保守費用を抑えるためです。よって、空欄にはシステムの保守費用を最小化する狙いが入ります。
誤りやすいポイント
- 「短期間で稼働開始させる」だけを答えにしないようにします。これは、用意された機能を使うことで得られる効果ですが、空欄は「同時に」図る別の狙いを問うています。
- 運用・保守の「作業負荷の軽減」と、保守「費用の最小化」を混同しないようにします。本文では、カスタマイズによって拡張機能の保守費用が必要になることが、費用を抑える根拠として示されています。
- SaaSの利用料全体を減らすことが主な狙いだと考えないようにします。ここで注目するのは、カスタマイズに伴って追加される保守費用です。
FAQ
Q: カスタマイズをしないことは、稼働開始までの期間にも影響しますか?
A: 影響します。カスタマイズを避け、用意された機能を使うことで、短期間での稼働開始にもつながります。ただし、この設問の空欄が問うているのは、稼働開始の短縮とは別の狙いです。
A: 影響します。カスタマイズを避け、用意された機能を使うことで、短期間での稼働開始にもつながります。ただし、この設問の空欄が問うているのは、稼働開始の短縮とは別の狙いです。
Q: 保守費用を抑えるために、なぜ業務プロセスを見直すのですか?
A: SaaSの機能を拡張するのではなく、業務の進め方を用意された機能に合わせれば、カスタマイズとその拡張機能の保守が不要になるためです。
A: SaaSの機能を拡張するのではなく、業務の進め方を用意された機能に合わせれば、カスタマイズとその拡張機能の保守が不要になるためです。
関連キーワード: SaaS、カスタマイズ、保守費用、業務プロセス、システム導入
設問1(2)
問題文を見る月次で利用者数、データ容量などの推移を把握して何を確認するのか。bに入れる確認内容を20字以内で述べよ。
模範解答
b:・契約した利用量を見直す必要性
・契約条件に沿った利用になっていること
・次契約の利用者数及びデータ容量
解説
解答の導き方
-
まず、月次で把握する対象は「利用者数、データ容量などの推移」です。単に現在の数値を記録するのではなく、その推移を何の判断に使うのかを考えます。
-
SaaSは、利用者数やデータ容量などに応じて課金されます。また、合意した期間ごとに契約を見直せます。したがって、実際の利用状況を契約内容と照らし合わせ、契約した利用量が現在の状況に合っているか、見直しが必要かを確認することが重要です。
-
利用量が契約の範囲を超えていないか、契約条件に沿った利用になっているかも確認します。利用量の推移は、次の契約で見込む利用者数やデータ容量を判断する材料にもなります。
このため、確認内容には、契約した利用量を見直す必要性や、契約条件に沿った利用になっていること、次の契約で見込む利用者数・データ容量が含まれます。
誤りやすいポイント
- 利用者数やデータ容量の推移を把握するだけで、何を確認するかまで述べないと、設問への答えとして不十分です。
- 利用量が増える場合だけでなく、利用量が減る場合も契約内容の見直しにつながります。利用状況に対して契約が過大になっていないかも確認します。
- 月次で推移を確認することは、毎月必ず契約を変更することを意味しません。契約を見直す必要性や、次の契約に用いる利用量を判断するための確認です。
- 契約の見直しだけに注目せず、実際の利用が契約条件に沿っているかという確認も含めます。
FAQ
Q: なぜ利用者数やデータ容量を月次で確認するのですか?
A: これらは課金や契約する利用量に関係するためです。推移を把握することで、契約が実際の利用状況に合っているかを判断できます。
A: これらは課金や契約する利用量に関係するためです。推移を把握することで、契約が実際の利用状況に合っているかを判断できます。
Q: 月次の確認後、毎月契約を変更する必要がありますか?
A: 必ず変更するということではありません。利用状況を確認し、契約を見直す必要があるかを判断します。
A: 必ず変更するということではありません。利用状況を確認し、契約を見直す必要があるかを判断します。
Q: 次の契約の利用者数やデータ容量は、なぜ確認するのですか?
A: 過去から現在までの推移を、次の契約で必要となる利用量の見積りに活用するためです。
A: 過去から現在までの推移を、次の契約で必要となる利用量の見積りに活用するためです。
関連キーワード: SaaS、従量課金、利用量管理、契約見直し、キャパシティ計画
設問2:〔SaaSの選定〕について、(1)~(3)に答えよ。
設問2(1)
問題文を見る今後の業務に用いる最小限のデータだけを新営業支援システムに移行する理由を30字以内で述べよ。
模範解答
・データ容量を抑えて、費用負担を少なくしたいから
・SaaSの利用にかかる費用負担を少なくしたいから
解説
解答の導き方
-
SaaSの費用は、利用するサービスや機能だけでなく、「利用者数、データ容量などに基づき課金」されます。したがって、SaaSに保管するデータ量も費用に影響します。
-
E社は「過去15年間のデータを蓄積しているが、業務に用いているのは直近5年間のデータ」です。今後の業務に使わない古いデータまで新営業支援システムに移す必要はありません。
-
表1でも、移行する顧客・案件・営業活動のデータは対象を絞り、残りのデータは外部媒体に保存する方針です。つまり、必要なデータは利用できる状態を保ちながら、SaaSに保管するデータ量を抑えようとしています。
-
以上から、移行データを最小限にする目的は、SaaSのデータ容量を抑え、利用にかかる費用負担を小さくすることだと判断できます。
誤りやすいポイント
- 「古いデータを使わないから移行しない」とだけ答えると、移行対象を絞ることで得られる費用面の効果が示されません。データ容量に応じて課金される点まで結び付けます。
- 過去のデータをすべて削除することが目的だと誤解しないようにします。本文では、移行しないデータは外部媒体に保存するとしています。
- 運用・保守作業の負荷軽減を理由にするのは、この設問の直接の根拠とは異なります。本文でデータ容量が課金要素として挙げられている点に注目します。
FAQ
Q: なぜデータ容量を減らすとSaaSの費用を抑えられるのですか?
A: SaaSの料金は、データ容量などの利用量に基づいて決まるためです。業務で必要なデータに絞れば、不要なデータを保管する分の料金を抑えられます。
A: SaaSの料金は、データ容量などの利用量に基づいて決まるためです。業務で必要なデータに絞れば、不要なデータを保管する分の料金を抑えられます。
Q: 移行しない過去データは失われますか?
A: 本文では、移行しないデータを外部媒体に保存するとしています。新営業支援システムに移さないことと、データを廃棄することは別です。
A: 本文では、移行しないデータを外部媒体に保存するとしています。新営業支援システムに移さないことと、データを廃棄することは別です。
Q: データ容量以外に、SaaSの費用に関係するものはありますか?
A: 本文では、サービスと機能の利用範囲、利用時間、サービスレベル、利用者数なども課金の基準として挙げられています。
A: 本文では、サービスと機能の利用範囲、利用時間、サービスレベル、利用者数なども課金の基準として挙げられています。
関連キーワード: SaaS、従量課金、データ容量、データ移行、費用最適化
設問2(2)
問題文を見る利用者データを現行営業支援システムからは移行せず、人事システムから必要なデータを取得する理由を35字以内で述べよ。
模範解答
・現行営業支援システムでは役職コードを取得していないから
・役職に応じたデータの閲覧に必要な利用者権限を適切に付与したいから
解説
解答の導き方
-
現行営業支援システムでは、利用者のデータを人事システムから取得しています。ただし、本文には「取得データには役職コードを含めていない」とあります。つまり、現行営業支援システムの利用者データには、役職に応じた権限設定に必要な情報が不足しています。
-
現行システムでは全利用者に同一の利用者権限を付与し、全ての営業活動の関連データを閲覧できる状態でした。一方、新営業支援システムでは、部署コード及び役職コードを用いて利用者権限を適切に付与し、所属部署及び役職に応じたデータを閲覧できるようにする方針です。
-
したがって、現行営業支援システムの利用者データをそのまま移行しても、役職に応じた権限を適切に設定できません。人事システムから必要なデータを取得することで、部署や役職に応じた利用者権限を設定できるようにすることが、移行しない理由です。
誤りやすいポイント
- 現行営業支援システムの利用者データが古いことを理由にするのは適切ではありません。本文で明示されている問題は、取得データに役職コードが含まれていないことです。
- 「部署コード」だけに注目しないようにしましょう。新営業支援システムでは、部署コードと役職コードの両方を使って権限を設定します。
- 利用者データを移行しない理由を、単に「人事システムがマスタだから」とだけ説明すると、新システムの権限設定とのつながりが伝わりません。役職に応じた閲覧制御に必要な情報を得るため、という点まで示すことが大切です。
FAQ
Q: 現行営業支援システムの利用者データには、部署コードも含まれていないのですか?
A: 本文で明記されているのは、取得データに役職コードが含まれていないことです。新営業支援システムでは部署コード及び役職コードを使う方針なので、必要なデータを人事システムから取得します。
A: 本文で明記されているのは、取得データに役職コードが含まれていないことです。新営業支援システムでは部署コード及び役職コードを使う方針なので、必要なデータを人事システムから取得します。
Q: 利用者データを移行せずに人事システムから取得するのは、利用者情報の更新を簡単にするためですか?
A: そのような利点も考えられますが、この設問の根拠は、現行の利用者データに役職コードがなく、新しい権限設定に必要な情報が不足していることです。
A: そのような利点も考えられますが、この設問の根拠は、現行の利用者データに役職コードがなく、新しい権限設定に必要な情報が不足していることです。
Q: 役職コードは何のために必要ですか?
A: 役職に応じた利用者権限を設定し、役職に応じたデータの閲覧を可能にするためです。
A: 役職に応じた利用者権限を設定し、役職に応じたデータの閲覧を可能にするためです。
関連キーワード: 利用者権限、役職コード、部署コード、マスタデータ、アクセス制御
設問2(3)
問題文を見るサービス利用終了時に保管されたデータの返却を受けることによって、どのようなリスクを回避しようとしたのか。25字以内で述べよ。ここで、利用者へのデータ返却後の消去に関するリスクは除くものとする。
模範解答
新営業支援システムの保管データを失うリスク
解説
解答の導き方
-
設問は、SaaSの利用を終了するときに、保管データの返却を受けることで避けようとしたリスクを尋ねています。なお、利用者への返却後にデータが消去されるかどうかは、考える対象から除きます。
-
表2の「サービス利用終了時対応」には、利用期間中に保管されたデータが返却されるかを確認する観点があります。これは、SaaSのデータがサービス提供者側に保管されるため、利用終了後もE社が必要なデータを保持できるかを確かめるものです。
-
返却されなければ、利用期間中に新営業支援システムに保管したデータをE社が手元に残せず、失うおそれがあります。したがって、回避しようとしたのは、新営業支援システムの保管データを失うリスクです。
誤りやすいポイント
- 利用者への返却後にサービス提供者側のデータが消去されるか、というリスクに答えないようにします。設問では、その点は除外されています。
- サービスの停止や利用継続ができなくなるリスクではなく、利用期間中に蓄積したデータを失うリスクに焦点を当てます。
- 返却対象は、導入時に移行したデータだけとは限りません。表2の「利用期間中に保管されたデータ」が対象です。
FAQ
Q: なぜ利用終了時にデータの返却が必要なのですか?
A: SaaSの利用を終えた後も、E社が保管データを保持し、必要に応じて利用できるようにするためです。
A: SaaSの利用を終えた後も、E社が保管データを保持し、必要に応じて利用できるようにするためです。
Q: 設問で除外されている「返却後の消去」は、どのリスクに関係しますか?
A: 返却後もサービス提供者側にデータが残ることによるリスクです。この設問で答える、データを返却されずに失うリスクとは区別します。
A: 返却後もサービス提供者側にデータが残ることによるリスクです。この設問で答える、データを返却されずに失うリスクとは区別します。
Q: 返却の対象は、移行したデータだけですか?
A: 表2では「利用期間中に保管されたデータ」とされているため、移行データに限らず、利用期間中に保管されたデータが対象です。
A: 表2では「利用期間中に保管されたデータ」とされているため、移行データに限らず、利用期間中に保管されたデータが対象です。
関連キーワード: SaaS、データ返却、データ保全、サービス終了、データ移行
設問3:〔要件定義〕について、(1)~(3)に答えよ。
設問3(1)
問題文を見る機能要件に関し、ワーキンググループのメンバで意識合わせを確実に行うことによって、どのようなリスクを軽減できるか。25字以内で述べよ。
模範解答
・要件定義以降の工程での手戻りのリスク
・計画どおりの期間で稼働できないリスク
解説
解答の導き方
-
問われているのは、機能要件についてワーキンググループのメンバが意識合わせをすることで、どのようなプロジェクト上のリスクを抑えられるかです。単に「要件の認識違いを防ぐ」と答えるのではなく、その認識違いが後の工程や稼働開始にどう影響するかまで考えます。
-
システム化方針には、見直した業務プロセスや画面イメージについて「利用者と意識合わせを確実に行い」、その結果として「要件定義以降の工程での手戻りのリスクを軽減する」とあります。したがって、まず抑えられるのは、後続工程で要件の食い違いが判明し、作業をやり直すリスクです。
-
要件定義では、Z社から提供された操作画面のサンプルを使い、営業部の担当者が実際に入力などを行っています。書面上の説明だけでなく、画面や操作の具体的な動きをメンバで確認することで、業務プロセスや画面の理解がそろい、後から認識の違いが見つかる可能性を抑えられます。
-
手戻りが発生すると、後続工程の作業が増え、計画していた稼働開始時期に間に合わなくなるおそれがあります。本文でも、手戻りのリスクを軽減して「計画どおりに稼働開始させる」としています。よって、軽減するリスクは、要件定義以降の手戻りと、計画どおりの期間で稼働できないことの両方です。
誤りやすいポイント
- 「認識違いを防ぐ」だけで終わらせず、その結果として抑えられる手戻りや稼働時期への影響まで考えます。
- 営業部の担当者の業務負荷やトレーニングに関する記述は、別の課題です。この設問では、機能要件の意識合わせによって軽減できるリスクを答えます。
- セキュリティや障害対応のリスクではありません。設問の対象は、画面や業務プロセスを具体的に確認することによる要件定義以降のリスクです。
FAQ
Q: 操作画面のサンプルを使うと、なぜ手戻りを減らせるのですか?
A: 実際の画面や操作を確認することで、文章だけでは気付きにくい要件の誤解や不一致を、後続工程に進む前に見つけやすくなるためです。
A: 実際の画面や操作を確認することで、文章だけでは気付きにくい要件の誤解や不一致を、後続工程に進む前に見つけやすくなるためです。
Q: 手戻りが減ることと、計画どおりに稼働開始できることはどうつながりますか?
A: 後続工程での修正や再作業が少なくなれば、追加作業によってスケジュールが遅れる可能性も低くなります。
A: 後続工程での修正や再作業が少なくなれば、追加作業によってスケジュールが遅れる可能性も低くなります。
Q: この設問で、サービスレベルに関するリスクを答える必要はありますか?
A: いいえ。ここでは機能要件の意識合わせが対象です。サービスレベルは、非機能要件の整理・採否判断で扱われています。
A: いいえ。ここでは機能要件の意識合わせが対象です。サービスレベルは、非機能要件の整理・採否判断で扱われています。
関連キーワード: 要件定義、機能要件、手戻り、利用者参加型設計、プロジェクトスケジュール
設問3(2)
問題文を見るcに入れる、要件の採否を判断した際の観点を30字以内で述べよ。
模範解答
c:営業部の担当者の業務負荷が許容範囲に収まること
解説
解答の導き方
-
要件の採否を判断する観点は、まず「業務の高度化に寄与するものであり、業務遂行に対して過度になっていないこと」です。もう一つの観点である[c]には、業務への効果や過度な機能の有無とは別に、利用者側で考慮すべき条件が入ります。
-
本文では、営業部の担当者が日常的にデータを入力するため、「日常業務に影響を受ける」と説明されています。さらに、その負荷を許容範囲に収めるため、画面表示や入力項目制御を工夫し、稼働開始前にトレーニングを行うとあります。このことから、担当者の作業負荷が導入時の重要な検討事項だと分かります。
-
要件定義では、操作画面のサンプルを使い、営業部の担当者が実際に入力などを行っています。具体的な操作を確かめることで、画面や入力手順が実際の業務で使えるか、担当者の負担が許容できるかを判断できます。したがって、[c]には、営業部の担当者の業務負荷が許容範囲に収まることを入れるのが適切です。
誤りやすいポイント
- 業務の高度化への寄与だけを答えると、すでに示されている最初の観点と重複します。[c]では、利用者である営業部の担当者への影響に注目します。
- 「画面が使いやすいこと」だけでは、本文が判断しようとしている内容を十分に表せません。画面操作を確認する目的は、担当者の業務負荷が許容範囲かを確かめることです。
- 非機能要件で定義するサービス時間や目標復旧時間と混同しないようにします。ここで問われているのは、機能要件の検討における利用者の負荷です。
FAQ
Q: なぜ画面のサンプルを使って確認するのですか?
A: 実際の入力操作を通じて、画面や入力手順が見直した業務プロセスに合っているか、担当者に過度な負担がかからないかを確かめられるためです。
A: 実際の入力操作を通じて、画面や入力手順が見直した業務プロセスに合っているか、担当者に過度な負担がかからないかを確かめられるためです。
Q: トレーニングを行うことも、[c]の判断に関係しますか?
A: 関係します。本文では、日常業務への影響を抑えるための対策として、画面表示や入力項目の工夫とともに、稼働開始前のトレーニングを挙げています。ただし、[c]に入るのは対策そのものではなく、確認する観点です。
A: 関係します。本文では、日常業務への影響を抑えるための対策として、画面表示や入力項目の工夫とともに、稼働開始前のトレーニングを挙げています。ただし、[c]に入るのは対策そのものではなく、確認する観点です。
関連キーワード: 要件定義、機能要件、業務プロセス、ユーザビリティ、業務負荷
設問3(3)
問題文を見るサービスレベルの合意の際に、サービス時間及び目標復旧時間などの定義において、なぜ業務処理量及び障害時の最低限の業務継続の範囲を前提としたのか。その理由を25字以内で述べよ。
模範解答
過度な費用負担にならないようにしたいから
解説
解答の導き方
-
設問は、サービス時間や目標復旧時間などのサービスレベルを定義するとき、業務処理量と障害時に継続する業務の範囲を前提とした理由を尋ねています。
-
本文では、SaaSの費用は「サービスと機能の利用範囲、利用時間、サービスレベル」などに基づいて課金されると説明されています。つまり、求めるサービスレベルを必要以上に高くすると、費用も大きくなる可能性があります。
-
また、システム化方針では「必要十分なサービスと機能」を選び、「適切なサービスレベル」で合意することで、過度な費用負担を避けるとしています。
-
そのため、実際の業務処理量と、障害時に最低限継続できればよい業務の範囲を基準にすれば、必要な水準を見極められます。全業務を通常どおり継続するような過剰な水準を求めずに済み、費用を抑えられることが理由です。
誤りやすいポイント
- 障害時にも業務を継続できるようにすることだけを理由にすると、設問の「なぜその範囲を前提としたのか」に十分答えられません。継続範囲を必要最小限に定めるのは、サービスレベルを過剰にしないためでもあります。
- 業務処理量や障害時の継続範囲を、SaaSの性能や復旧を確認するためだけの条件と捉えないようにします。本文では、過度な費用負担を避ける方針とのつながりが重要です。
- 「費用を抑える」だけでなく、必要な業務に見合ったサービスレベルを設定することが、その理由につながります。
FAQ
Q: サービスレベルを高く設定すると、なぜ費用負担が増えるのですか?
A: SaaSはサービスレベルなどに応じて課金されるため、業務に必要な水準を超えて高く設定すると、必要以上の費用が発生する可能性があります。
A: SaaSはサービスレベルなどに応じて課金されるため、業務に必要な水準を超えて高く設定すると、必要以上の費用が発生する可能性があります。
Q: 障害時の業務継続範囲を「最低限」とするのはなぜですか?
A: 障害時に必要な業務を絞ることで、求める復旧水準を実際の必要性に合わせられ、過度なサービスレベルや費用を避けやすくなるためです。
A: 障害時に必要な業務を絞ることで、求める復旧水準を実際の必要性に合わせられ、過度なサービスレベルや費用を避けやすくなるためです。
Q: 業務処理量は、どのようにサービスレベルの定義に役立ちますか?
A: 実際に処理する量に見合った水準を検討する基準になります。業務量を踏まえることで、必要以上に高い性能などを求めずに済みます。
A: 実際に処理する量に見合った水準を検討する基準になります。業務量を踏まえることで、必要以上に高い性能などを求めずに済みます。
関連キーワード: SaaS、サービスレベル、非機能要件、業務処理量、目標復旧時間



