平成28年秋期試験午後問題 問9

問9 プロジェクトマネジメント

⇱問題PDF
ガソリンスタンド事業における料金システムの更新に関する次の記述を読んで,設問1~3に答えよ。
 A社は,石油製品を販売している中堅企業であり,ガソリンスタンド事業では,十数店のガソリンスタンドで小売をしている。ガソリンスタンド事業における基幹システムは,本社のサーバで稼働している料金システムと会計システムで構成される。各ガソリンスタンドでは,給油量や料金情報などが給油機から店内の店舗POS端末に送られ,さらに,給油や売上に関するPOSデータを収集する料金システムで,企業などの契約顧客向けの請求処理が実行される(図1)。また,会計システムはソフトウェアパッケージ(以下,パッケージという)を導入したものであり,料金システム上の売上金額や給油量などのデータは,会計システムにデータ連携している。現行の料金システムの機能は,POSデータ収集,顧客管理,契約顧客を対象とした料金請求管理及び入金管理である。この料金システムは,ガソリンスタンド業界各社を主要顧客としている中堅のシステムインテグレータであるB社が,A社の仕様に合わせてソフトウェアを開発し,サーバなどのハードウェアと一括して納入した後,引き続き保守も実施している。
pm09_1.png
 A社が,セルフサービス方式の給油機(以下,セルフ給油機という)を導入しようとしたところ,セルフ給油機に対応した新しい店舗POS端末と料金システムとのインタフェース部分を変更する必要があることが分かった。B社に見積りを依頼したところ,改修費用が高額になることが分かったので,改修せずにサーバOSのサポートが終了する時期に合わせて,料金システムを更新することにした。その後,サーバOSのサポート終了が近づいてきたので,今回,料金システム更新プロジェクト(以下,本プロジェクトという)を立ち上げることにした。
 本プロジェクトの責任者となったA社システム開発室のC室長は,①導入期間や費用を考慮して,パッケージの導入を前提にして提案するようにB社に依頼した。B社には該当する自社開発のパッケージがないので,提案の作成に当たって,複数社のパッケージを調査し,提案に盛り込んだ。パッケージの候補を複数列挙したB社からの提案では,顧客管理機能を含めてA社の料金システムで必要な全機能をサポートしている製品はなかったが,機能の多くをサポートしている製品は幾つかあるとのことであった。また,候補として挙げられたパッケージは全て,パラメータでの機能変更が限られており,A社で必要とする機能とのギャップは,追加プログラム(以下,アドオンという)で対応するか,業務の変更で対応することになるとの提案であった。
この提案を基に,C室長は,料金システムを更新するために次の内容を含んだシステム化構想書を作成した。
  • 現行の会計システムにデータ連携できること
  • セルフ給油機に対応した新しい店舗POS端末が利用できること
  • 顧客管理機能にサービス履歴照会などの機能を有していること
 経営会議において,C室長が作成したシステム化構想書が承認され,複数のパッケージを検討する条件で,提案どおり,システム導入をB社に発注することが決定した。また,本プロジェクトのプロジェクトマネージャには,C室長が任命された。C室長は,部下1名,及びB社のベテランSEであるD氏の計3名体制で,パッケージ選定を含む要件定義工程から導入までのシステム開発計画書の作成に取り掛かった。

〔B社におけるパッケージ導入の知見〕
 システム開発計画書の作成に先立ち,C室長は,B社にパッケージ導入時の留意点を照会した。
 B社では,ガソリンスタンド業界をはじめ,様々な業界の企業にパッケージを導入してきている。D氏が,パッケージの導入事例を調査したところ,次のような事例があることを把握し,C室長に報告した。
  • パッケージ選定前の業務要件定義の作業が十分に行われなかったので,必要機能を洗い出せず,業務に適合しないパッケージを選定してしまった。その結果,アドオン量が膨らみ,コスト超過になった。
  • 要件定義工程における利用者側要員の関与が不足していた。その結果,要求機能とパッケージの機能とのギャップを正確に把握するための,フィット&ギャップ分析に必要なaや業務データなどの要件を事前に洗い出すことができなかった。また,ギャップによる業務への影響の検討も不十分であったために納期の遅延などが発生した。
  • 要件定義工程において,パッケージ機能の詳細を十分に把握していなかったので,アドオンで対応すべき機能を洗い出せずに機能不足でのリリースになった。

〔要件定義工程の手順〕
 C室長は,システム開発計画書を作成するに当たり,D氏から報告された事例を参考に対策を講じ,要件定義工程を二つに分けて,次のように進めることにした。
 最初の工程は,パッケージ選定などのために,候補となるパッケージに対してフィット&ギャップ分析を実施する工程であり,次の手順で実施することにした。
  • ガソリンスタンド事業部門の要員が中心となって,業務要件を事前に洗い出し,要求機能としてまとめる。
  • B社のSEが中心となって,要求機能のうち,候補となるパッケージがサポートしていない機能をギャップとして洗い出す。
 2番目の工程は,パッケージ選定後に詳細なアドオン検討や業務方針策定を実施する工程であり,次の手順で実施することにした。
  • B社のSEが,前工程でギャップとして洗い出した機能について,アドオンでの対応が可能かどうか,可能ならばそのbを見積もり,要員単価を当てはめてアドオンの開発コストを算定する。
  • B社のSEとガソリンスタンド事業部門の要員が連携し,ギャップとして洗い出した機能についてアドオンで対応できない場合の業務への影響を検討する。

〔要件定義工程におけるC室長の工夫点〕
 C室長が,D氏から聞いた事例を踏まえ,システム開発計画書で工夫しようとしている点は,次のとおりである。
  • A社,B社,及びパッケージ開発会社の調整窓口を明確にして,情報の流れを統制する。
  • 要求機能を正確に伝えることなどによって,フィット&ギャップ分析とアドオン開発を適切に実施できるように,②A社内の各関連部門の要員最低1名が,要件定義工程から参加し,ガソリンスタンド事業部門の要員のうち少なくとも1名を専任とする体制を作ることを明示する。
  • ③パッケージ選定後に,パッケージ開発会社から複数のSEを参加させる

〔外部委託会社との契約とC室長の工夫点〕
 C室長は,パッケージ開発会社の選定に当たり,評価表であるcを事前に準備することによって,パッケージ開発会社を公正に選定することにした。
 また,B社やパッケージ開発会社との契約は,派遣契約とはせず,要件定義工程と外部設計以降の2段階に分け,要件定義工程では成果物の詳細が明確でないために,d契約とすることにした。パッケージ開発会社の参加期間は限定的であるが,その間は,④A社の社内で業務を遂行してもらうようにする。

設問1

料金システム更新の作業工程について,(1)~(3)に答えよ。
  • 本文中の下線①について,B社に依頼した理由は何か。20字以内で述べよ。
  • 本文中のaに入れる適切な字句を解答群の中から選び,記号で答えよ。
  • 本文中のbに入れる適切な字句を5字以内で答えよ。
a に関する解答群
  • 画面構成
  • 業務環境
  • 業務プロセス
  • サーバ構成
  • 入力方式

解答例・解答の要点

  • A社の業務に精通しているから (14文字)
  • a:
  • b:工数 又は 開発規模 (10文字)

解説

  • 本文中の記載より、現行システムは、B社がA社の仕様に合わせてソフトウェアを開発したことや、サーバなどのハードウェアと一括して納入した後、引き続き保守も実施していること、並びにB社がガソリンスタンド業界各社を主要顧客としていることから、B社は現行のシステムやA社の業務に詳しいことが推測できます。
    新システムを開発する際は、A社の業務プロセスや現行システムの仕様を把握する必要があり、その点においてB社は知見があるため認識の違いが発生するリスクも少ないと考えられます。

    ∴A社の業務に精通しているから

  • aについて〕
    フィット&ギャップ分析は、企業の業務プロセス、システム化要求などのニーズと、ソフトウェアパッケージの機能性がどれだけ適合し、どれだけかい離しているかを分析する手法です。パッケージを導入する際には、フィット&ギャップ分析を行って、パッケージがカバーしている業務プロセスと自社の現行業務プロセスがどれだけ適合し、又はかい離しているかを判断しなければなりません。

    よって、フィット&ギャップ分析に必要な情報とは「業務プロセス」となります。

    また、本問では〔B社におけるパッケージ導入の知見〕として、要件定義工程における利用者側要員の関与が不足していたという記述があります。要件定義工程では、利用者の要求事項をもとに要件を定義します。そのために必要な情報として、業務にかかわる人はだれか、業務をどのような流れで行うか、扱うデータにはどのようなものがあるか、などを明確にする必要があります。
    比較基準となる現行業務プロセスの情報が不足していれば、フィット&ギャップ分析の結果も不十分なものになってしまいます。選択肢の中で上記ポイントを表しているものは「業務プロセス」となります。

    a=ウ:業務プロセス

  • bについて〕
    ソフトウェア開発の費用は、文中にある要員単価と開発規模により算出できます。プロジェクト全体の費用としては、その他ハードウェア、ソフトウェア、サービスなどのコストを合算することになります。
    本問で問われている開発コストは「要員単価×工数」で求められるので、bには開発規模を示す字句が当てはまります。

    b=工数 又は 開発規模

設問2

〔要件定義工程におけるC室長の工夫点〕について,(1),(2)に答えよ。
  • C室長が,本文中の下線②のような体制にした目的は何か。35字以内で述べよ。
  • 本文中の下線③について,パッケージ開発会社のSEを参加させた理由は何か。〔B社におけるパッケージ導入の知見〕を参考に,25字以内で述べよ。

解答例・解答の要点

  • ギャップを業務変更で対応したときの影響を正確に把握するため (29文字)
  • アドオンで対応可能かを正確に判断したいから (21文字)

解説

  • D氏から聞いたパッケージの導入事例に挙げられている(1)~(3)は、新システム導入にあたっての失敗例であることから、C室長の工夫点は失敗をあらかじめ防ぐための対策となっています。

    失敗例では、利用者側要員の関与が不足していたために、ギャップにより業務への影響の検討が不十分であったことが報告されています。業務を把握している要員を要件定義から参加させることは、これを防ぐための対策と言えます。
    〔要件定義工程の手順〕の最後では、「ギャップとして洗い出した機能についてアドオンで対応できない場合の業務への影響を検討する」ことになっています。つまり、アドオンで対応できない場合にはパッケージに合わせて業務を変更するということです。この場合、業務を変更することによる影響を正確に把握するためには、利用者側要員の関与が不可欠になります。

    ∴ギャップを業務変更で対応したときの影響を正確に把握するため

  • パッケージ選定後の工程は、〔要件定義工程の手順〕によると、2番目の工程として、要求機能に対するパッケージの機能のギャップを、アドオンで対応可能か検討を行うとされています。
    提案されたパッケージは、B社は自社開発のパッケージではなく別の会社のパッケージですので、〔B社におけるパッケージ導入の知見〕(3)に記述されているように、B社もパッケージの機能を詳細に把握しているわけではありません。パッケージ開発会社のSEに参加を要請するのは、パッケージに精通している人にB社SEの作業をサポートしてもらい、アドオンで対応すべき機能を正確に判断するためであると言えます。

    ∴アドオンで対応可能かを正確に判断したいから

設問3

〔外部委託会社との契約とC室長の工夫点〕について,(1)~(3)に答えよ。
  • 本文中のcに入れる,PMBOKガイド第5版において使用されている適切な字句を解答群の中から選び,記号で答えよ。
  • 本文中のdに入れる適切な字句を5字以内で答えよ。
  • 本文中の下線④において,A社の要員と外部の要員とは,法令上適正な指揮命令関係にあることが必要である。A社の要員が法令遵守上,業務の遂行において気をつけることを20字以内で述べよ。
c に関する解答群
  • RFP
  • 統制自己評価
  • 発注先選定基準
  • 発注内示書

解答例・解答の要点

  • c:
  • d:準委任 (3文字)
  • 作業者に直接業務指示しない (13文字)

解説

  • cについて〕
    「パッケージ開発会社を公正に選定する」という記載より、開発会社を選定する基準を予め用意しておくということがわかります。発注先選定基準は、供給元からの提案の等級付けや採点のために作成し使用するものであり、開発会社の候補先に公開する場合もあります。選定基準を作成しておくことで、私見によらない公正な選定ができます。また、開発会社はより要求に合った提案を作成しやすくなります。

    その他の選択肢の説明は以下の通りです。
    • Request For Proposalの略で、日本語で「提案依頼書」と呼ばれています。発注側の要件を正しく伝え、ベンダからの提案が的を射たものにするために作成する資料です。
    • CSA(Control Self Assessment)とも呼ばれます。組織内の統制をとる方法が適正か、また有効かどうかを組織自らが評価し改善する手法です。
    • 正しい。PMBOK第5版によれば、「発注先選定基準:納入者が契約獲得に向けて満たすか越えなければならない属性。これは購入者が納入者に求める属性である」と定義されています。
    • 発注内示書は、発注元に発注を行う意思があることを示す書面です。
      ソフトウェア開発会社は、作業に着手する前に契約を結ぶ必要がありますが、発注元の社内手続きの遅れなどにより作業着手が遅れることがあります。開発会社が作業に着手した後で、実際は発注が行われなかった場合は、費やした費用を請求できるのか問題になります。開発会社側のリスクを軽減するために、発注内示書を作成することがあります。
    c=ウ:発注先選定基準

  • cについて〕
    「成果物の詳細が明確でない」というキーワードにより、請負契約ではないことがわかります。また、本文中に「派遣契約とはせず」とあるので、契約形態は準委任契約であることが分かります。
    それぞれの契約形態の特徴は下記のとおりです。
    請負契約
    受託した業務・成果物の完成を目的とする契約です。そのため、契約を行う時点で成果物の詳細が明確になっている必要があります。要件定義工程では成果物が具体的に想定できないものなので、請負契約はなじみません。
    派遣契約
    人材の提供に対して対価が発生する契約です。
    派遣元企業が、自分が雇用する労働者を自分のためにではなく、他の事業主(派遣先企業)に派遣して、派遣先から指揮命令を受けて派遣先のために労働させる契約です。
    準委任契約
    通常の委託契約(請負契約)と同様に別の組織に業務を委託する契約ですが、仕事の完成を契約の目的とする請負契約と異なり、委託された仕事の実施自体を目的とする契約形態です。受託者は善良な管理者の注意をもって委任事務を処理する義務を負うものの、仕事の完成についての義務は負いません。
    d=準委任

  • 準委任契約の指揮命令系統を理解しておく必要があります。
    準委任契約では発注者は委託先(本問ではパッケージ開発会社)の管理者に対してのみ作業指示を行うことができます。作業者それぞれに対して指揮命令を行う場合は派遣契約でなければなりません。
    このような性質上、外部の要員がA社に常駐して作業に当たる場合でも、A社の要員が外部の要員に対して直接指示を行うことはできません。準委任契約であるにもかかわらず直接指揮命令をした場合には労働者派遣法違反となります。

    ∴作業者に直接業務指示しない
模範解答

Pagetop