平成31年春期試験午前問題 午後問9

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

システム更改プロジェクトのスケジュールの作成に関する次の記述を読んで,設問1,2に答えよ。

 P社は,家電製品の製造・販売を行う中堅企業である。これまでオンプレミスで運用してきた会計システムと人事給与システムが,更改時期を迎えた。P社では,開発コストと運用費用の削減,及び事業継続性の確保を図るために,両システムともクラウドサービスを利用して更改することになった。そこで,情報システム部のQ部長は,クラウドサービスを提供する発注先候補に対して,提案依頼書を発行し,具体的な提案を求めた。
 数社から提出された提案書を評価した結果,会計システムはR社が製造業向けに提供しているSaaSを,人事給与システムはR社の提供しているPaaSを,それぞれ利用することにした。R社のクラウドサービスでは,セキュリティが強化された新しいOS(以下,新OSという)と新しいミドルウェア(以下,新MWという)を採用している。
 Q部長は,両システムを更改するプロジェクトのプロジェクトマネージャにS課長を指名し,120日以内にシステム更改を完了させることをプロジェクト目標の一つとして,作業内容を整理して,スケジュールを作成するよう指示した。

〔システム更改の作業内容の整理〕
 更改する両システムを利用する部署からの要求は,次のとおりである。
  • 会計システムを主に利用する経営企画部と経理部は,各種の財務データを取得,集計,分析するSaaSの機能について,P社向けに一部の改修を要求している。両部は,"この改修を加えれば,十分に業務に適合可能である"と判断している。
  • 人事給与システムを主に利用する総務人事部は,"P社特有の人事制度及び職位に基づく給与体系への対応と,プログラムを改修することなく,人事評価区分及び給与区分の追加・削除ができること"を要求している。
 これらの要求は,情報システム部の支援の下,要件定義書としてまとめられた。S課長はまず,要件定義書に基づき,システム更改の作業内容を次のとおり整理した。
  • 会計システムの更改
    • P社の経理業務に適合させるために,R社のSaaSに対して小規模のカスタマイズを行う。
  • 人事給与システムの更改
    • 総務人事部の要求に対応するために,現行の人事給与システムのソフトウェアを改修して,R社のPaaSに配置し,実行できるようにする。
    • ソフトウェアの改修は,R社のPaaSを利用し,P社の情報システム部の開発要員だけで,全ての作業を行う。
    • ソフトウェアは,人事,給与及び共通の三つのモジュールで構成され,全てのモジュールのプログラムを改修する必要がある。各モジュールとも改修の規模及び改修の難易度は同等である。

〔システム更改スケジュールの作成〕
 次に,S課長は,システム更改スケジュールを明確にするために,プロジェクトで実施すべき作業項目と成果物(文書)を洗い出して,表1の作業一覧を作成した。
pm09_1.gif
 人事給与システムの外部設計からプログラム製造・単体テストまでの各作業項目では,設計チーム及び製造チームは,三つのモジュールに対応して,両チームとも4人ずつの三つのグループに分ける。三つのグループとも,生産性は同じである。三つのグループは,同時に作業を開始し,それぞれ並行して作業を行う。作業が完了した後は,既に計画されている他のプロジェクトの作業を行う。
 また,ソフトウェア設計とプログラム製造・単体テストについては,各作業項目とも全グループの作業が完了した時点で,S課長が成果物の品質を判定する。良好と判定されると,各チームは次の作業に着手するルールにする。
 続いて,S課長は,表1の作業一覧に基づいて,図1の作業工程図を作成した。
pm09_2.gif
 S課長が,表1の作業一覧と図1の作業工程図について,Q部長に説明したところ,会計システムの更改においては,①フィット&ギャップ分析が完了した時点で,必要に応じて作業一覧と作業工程図を修正するよう,指示があった。

〔システム更改スケジュールの見直し〕
 会計システムのフィット&ギャップ分析が完了した時点で,作業一覧と作業工程図の見直しは,不要であると判断された。
 一方,人事給与システムの外部設計の途中で,総務人事部から,"人事評価区分及び給与区分の見直し時期を早めるので,開発期間を短縮してほしい"という要請があった。そこで,S課長は,作業IDの B3 から B5 までの連続する作業の経路が,cの一部となるので,人事給与システムのソフトウェア設計からソフトウェア適格性確認テストまでの作業を対象として,クラッシング及びファストトラッキングの考え方を用いて,開発期間を短縮することにした。開発期間を短縮できた場合には,P社の事業運営において,1日当たり5万円のコストの削減が見込まれる。開発期間の短縮案として,開発要員を追加して作業計画を見直す案(以下,案1という)と開発要員を追加しないで作業計画を見直す案(以下,案2という)を評価して,採用する案を決定することにした。
 S課長は,案1と案2の評価に当たっては,次の前提を置いた。
  • 案1
    • 新OSと新MWの環境でのシステム開発経験がある開発要員を設計チーム,製造チームにそれぞれ10人ずつ追加し,設計チーム,製造チームとも22人の体制で,ソフトウェア設計からソフトウェア適格性確認テストまでの作業を行う。
    • 追加する開発要員の生産性は,業務要件を理解するのに必要な時間を考慮して,当初計画の80%で見積もる。
    • 開発要員を追加した場合の三つのグループの生産性は同じである。
    • 開発要員の追加によって増加するコストは,当初の開発要員と同じく,工数1人日当たり5万円とする。
  • 案2
    • 開発要員を追加しないで,設計チーム,製造チームとも12人の体制のまま,ソフトウェア設計からソフトウェア適格性確認テストまでの作業を行う。
    • 人事給与システムの設計チーム,製造チームの開発要員は,既に計画されている他のプロジェクトの作業に優先して,人事給与システムの作業に参加するように調整する。
    • 既に計画されている他のプロジェクトの作業が遅延し,P社の事業運営において増加するコストを150万円と見積もる。
    • 当初の予定どおり,人事給与システムのソフトウェア設計の作業は設計チームが担当し,プログラム製造・単体テストの作業は,製造チームが担当する。両チームとも,それぞれ一つのグループで作業を行う。当初の計画では,三つのモジュールについて,同時に作業を開始し,それぞれ並行して作業することにしていたが,この方式をやめて,両チームとも,人事,給与,共通のモジュールの順に作業を行う。一つのグループで行っても作業効率は,当初と変わらない。これによって,ソフトウェア設計の作業が全て完了する予定であった日の16日前から並行してdの作業を開始することができ,開発期間が短縮できる。
 S課長は,これらの前提に基づき,案1と案2の評価を表2のように整理した。
pm09_3.gif
 S課長は,この評価を基に,総務人事部と話し合った結果,増加コストを考慮して,案2を採用することにした。そこで,S課長は,開発期間の短縮を確実に実現するために,設計変更が発生した場合には,プロジェクト内で直ちに情報を共有するルールを設定するとともに,ソフトウェア設計及びプログラム製造・単体テストの各作業項目において,②成果物の品質判定のタイミングを見直すことにした。

設問1

〔システム更改スケジュールの作成〕について,(1),(2)に答えよ。
  • 図1中のabに入れる適切な数値を求めよ。
  • 本文中の下線①について,どのような場合に,作業一覧と作業工程図を修正する必要があるか。30字以内で答えよ。

解答例・解答の要点

  • a:21
    b:54
  • カスタマイズの規模が事前の想定とかい離した場合 (23文字)

解説

  • 図1の作業工程図はプレシデンスダイアグラムと呼ばれるものです。

    プレシデンスダイアグラム法は、個々の作業を四角で囲み、作業同士を矢印で結ぶことで作業順序や依存関係を表現する図法です。
    作業同士の関係を表すという意味ではアローダイアグラムと同じですが、アローダイアグラムでは作業を矢印で、結合点を丸のノードで示すので、記述方法が根本的に異なります。またアローダイアグラムでは、ある作業の終了が別の作業の開始条件となる「終了-開始」(FS:Finish to Start)の依存関係しか表現できませんが、プレシデンスダイアグラムではこの他に、「開始-開始」(SS:Start to Start)、「開始-完了」(SF:Start to Finish)、「完了-完了」(FF:Finish to Finish)の関係を記述できることが特徴です。

    プレシデンスダイアグラム法では、凡例に貼るように個々の作業を表す四角の四隅に数字を記述することがあります。これはそれぞれ次の意味をもちます。
    pm09_4.gif
    プレシデンスダイアグラムを作図する場合は、まずは各作業を四角で囲み、依存関係に注意しながら最早開始日と最早完了日を書き入れます。
    pm09_5.gif
    全体の最短完了日数が14日とわかるので、そこから逆算して最遅終了日、最遅開始日を書き入れます。(クリティカルパス上の作業は、最早開始日=最遅開始日、最早終了日=最遅終了日になります)
    pm09_6.gif
    aについて〕
    作業A3の最早開始日が入ります。最早開始日とは、その名の通り最も早くその作業を開始できる日です。
    表1「作業一覧」を見ると、作業A3は作業A2が完了すれば開始でき、作業A2は作業A1が完了すれば開始できるとわかります。作業A1及び作業A2ともに所要日数は10日なので、作業A3の最早開始日は、プロジェクトの開始日である1日目に所要日数「10日+10日=20日」を足した21日目となります。

    a=21日

    bについて〕
    作業B1の最遅終了日が入ります。最遅終了日とは、プロジェクト全体がスケジュール通りに完了するために、その作業を少なくとも完了していなくてはならない日です。
    最終結合点で最早終了日=最遅終了日となっている120日がプロジェクト全体の所要日数です。この120日から作業C・作業B5・作業B4の所要日数を引いたものが答えになります。表1「作業一覧」を見ると、作業Cの所要日数は10日、作業B5は20日、作業B4は36日なので、

     120日-10日-20日-36日=54日

    作業B1が少なくとも54日目までに終了していれば、後続作業の所要日数66日を足しても120日でプロジェクトは完了するということです。

    ※作業B4の最遅終了日が90日と記載されているので、単純に「90日-36日=54日」でも良いと思います。

    b=54日

    なお、本問のプレシデンスダイアグラムに数値を入れると次のようになります。
    pm09_7.gif
  • フィット&ギャップ分析は、企業の業務プロセス、システム化要求などのニーズと、ソフトウェアパッケージの機能性がどれだけ適合し、どれだけかい離しているかを分析する手法です。

    会計システムを利用する経営企画部と経理部は、更改に当たり「SaaSの機能について,P社向けに一部の改修を要求」しているので、フィット&ギャップ分析により、現行の会計システムとSaaSで提供される機能を比較して、カスタマイズが必要な部分を洗い出しその開発規模を見積もることになります。
    表1「作業一覧」では、会計システムのカスタマイズが10日と見込まれていますが、フィット&ギャップ分析の結果によってはカスタマイズの規模が大きくなり、追加作業や所要日数の増加が生じる可能性があります。この場合、作業一覧や作業工程図を変更しなければなりません。これが本設問の肝要な部分です。

    ∴カスタマイズの規模が事前の想定とかい離した場合

設問2

〔システム更改スケジュールの見直し〕について,(1)~(4)に答えよ。
  • 本文中のcに入れる適切な字句を,10字以内で答えよ。
  • 本文中のdに入れる作業項目を,表1の作業IDから選択して答えよ。
  • 表2中のefに入れる適切な数値を求めよ。
  • 本文中の下線②について,品質判定のタイミングをどのように見直すべきか。35字以内で述べよ。

解答例・解答の要点

  • c:クリティカルパス
  • d:B4
  • e:32
    f:70
  • 各モジュールの各作業が完了したタイミングで品質判定を行う (28文字)

解説

  • cについて〕
    B3からB5までの作業を短縮するためにクラッシング及びファストトラッキングの適用を検討しています。クラッシングとファストトラッキングは、どちらもプロジェクトの期間を短縮する方法です。
    クラッシング
    クリティカルパス上の作業に追加資源を投入することでプロジェクト全体のスケジュールを短縮させる方法。メンバの増員や時間外業務の拡大などが該当する。
    ファストトラッキング
    開始当初の計画では直列に並んでいた作業を同時並行的に行ったり、作業の前後を入れ替えたりすることで期間短縮を図る方法。
    プロジェクト全体の期間を短縮するにはクリティカルパス上の作業を短縮しなければなりません。よって、cにはクリティカルパスが入ります。

    プレシデンスダイアグラムにおけるクリティカルパスは、最早開始日=最遅開始日、かつ、最早終了日=最遅終了日となる作業の繋がりです。実際に完成したプレシデンスダイアグラムを見ると、B3からB5はどれもクリティカルパス上の作業となっています。
    pm09_8.gif
    c=クリティカルパス

  • dについて〕
    案2では、3つのモジュールを順次開発します。従前の計画では全モジュールを並行して作業するので、どのモジュールのソフトウェア設計も24日目の完了でしたが、順次開発になれば、人事モジュールのソフトウェア設計は8日後、給与モジュールは16日後、共通モジュールは24日後に完了することになります。
    pm09_9.gif
    この変更により8日目に完了した人事モジュールについては、9日目から"プログラム設計・単体テスト"の工程に移ることができます。本来はソフトウェア設計の作業がすべて完了する予定であった日の翌日25日目から開始する予定でしたから、本来の16日前から"プログラム設計・単体テスト"の作業を開始できます。"プログラム設計・単体テスト"の作業IDはB4ですから、dにはB4が入ります。
    pm09_10.gif
    d=B4

  • eについて〕
    案1では、設計チーム・製造チームにそれぞれ10人ずつ追加します。これにより、"ソフトウェア設計"から"ソフトウェア適格性確認テスト"までの作業の所要日数が短縮されます。

    現状の要員数は"ソフトウェア設計"・"プログラム製造・単体テスト"及び"ソフトウェア適格性確認テスト"ともに12人であり、追加された要員10人の生産性は当初計画の80%ですので、どの工程でも要員追加後の実質的な生産性は、

     12人+(10人×80%)=20人日

    となります。これは現状の12人日の5/3倍に相当しますから、要員追加後の所要日数は当初予定の所要日数の3/5倍となります。"ソフトウェア設計"・"プログラム製造・単体テスト"及び"ソフトウェア適格性確認テスト"の所要日数の合計は「24日+36日+20日=80日」ですから、その3/5倍は48日です。つまり、短縮できる日数は「80日-48日=32日」となります。

    【別解】
    計算量は多くなりますが、各工程の工数を算出して20人日で割ることで要員追加後の所要日数を求めることも可能です。
    • ソフトウェア設計 … 12人×24日=288人日
    • プログラム製造・単体テスト … 12人×36日=432人日
    • ソフトウェア適格性確認テスト … 12人×20日=240人日
    • 合計 … 288+432+240=960人日
    各工程ともに20人日の生産性で作業を進めるので、所要日数は「960人日÷20人日=48日」、短縮可能な日数は「80日-48日=32日」となります。

    e=32

    fについて〕
    案2では、P社の事業運営において増加するコストが150万円と見積もられています。しかし、開発期間を短縮できた場合には1日当たり5万円のコスト削減が見込まれていますから、案2の短縮日数分のコスト削減金額を差し引いた金額が実質的な増加コストとなります。

     150万円-(5万円×16日)=70万円

    f=70

  • 現状では3つのモジュールの開発を並行して行っていたので、各工程の完了したタイミングで3つのモジュールをまとめて品質判定していたことになります。しかし、案2を採用すると各モジュールが順次開発になり、全てのモジュールの作業完了を待つことなく次の工程に移っていきます。現状の品質判定タイミングのままだと、品質判定が行われる前に次工程に取り掛かることになるため品質不良による手戻りが生じる可能性が考えられます。これを回避するためには、各モジュールの各作業が完了したタイミングで、その都度品質判定を実施する必要があります。
    各モジュールの各作業が完了したタイミングとは、「人事モジュールのソフトウェア設計が完了した」とか「給与モジュールのプログラム開発・単体テストが完了した」などの時点です。

    ∴各モジュールの各作業が完了したタイミングで品質判定を行う

Pagetop