プロジェクトマネージャ 2015年 午後1 問02

解答の導き方

1. 問われているのは、利用部門にプロトタイプを事前に操作してもらうことで、どのような効果を期待したかです。操作練習そのものではなく、事前に操作してもらう目的を考えます。
2. 本文では、利用者トレーニングに備えてキーパーソンがドキュメントを基に説明する計画ですが、「それだけでは利用者トレーニングがスムーズに進まないリスクがある」としています。つまり、説明を聞くだけでは、新しい業務プロセスを十分に理解できないおそれがあります。
3. そこでE課長は、業務プロセス設計工程の完了後もデモンストレーション環境を利用できるようにし、プロトタイプを利用部門に公開して、事前に操作してもらうことにしました。実際に操作することで、新しい業務プロセスの流れや操作を具体的に把握でき、ドキュメントによる説明だけの場合より理解を深められます。

誤りやすいポイント

• 「操作に慣れてもらうこと」だけにすると、操作習熟に焦点が寄り、本文で重視されている新しい業務プロセスの理解が抜けます。
• 「利用者トレーニングをスムーズに進めること」は期待する効果としては関係しますが、そのためにプロトタイプを事前操作してもらう目的を具体的に述べる必要があります。
• 追加開発の要件や機能の確認は、プロトタイプを作成する別の目的です。この設問では、利用部門に公開して事前操作してもらうことの狙いを答えます。

FAQ

解答の導き方

1. 下線②では、本番機の導入時期を標準より早め、結合テスト工程から利用できるようにしています。したがって、結合テスト工程で先行して行う作業は、本番機を使う必要がある作業だと考えられます。
2. 本文には、以前「稼働直前の総合テストで性能に関する問題が発見され、稼働が遅れた」とあります。この経験から、性能面の問題を総合テストの終盤まで見つけられないことが、稼働遅延のリスクになると分かります。
3. 工程の説明では、結合テストは開発機でMWSと追加開発分のプログラムを結合して行います。一方、総合テストでは本番機を使い、「性能や運用面の検証」も行います。そこで、本番機を結合テスト工程から使えるようにして、総合テストを待たずに性能面の確認に着手する計画だと読み取れます。
4. したがって、結合テスト工程で一部を先行して実施する作業は、性能の検証です。より広い表現では、非機能要件の検証ともいえます。

誤りやすいポイント

• 結合テストの通常の目的である、MWSと追加開発分のプログラムの連携確認だけを答えないようにします。設問では、本番機を早く導入する理由となる作業を問われています。
• 「性能や運用面の検証」の両方を答えると、本文の工程説明をそのまま挙げただけになり、下線②の意図である早期の確認が曖昧になります。
• 総合テストで行う検証をすべて結合テストに移すわけではありません。性能面の確認の一部を先行して行う点が重要です。

FAQ

解答の導き方

誤りやすいポイント

• キーパーソンが新業務プロセス案の大枠に合意している点だけを見て、設計作業に支障はないと判断しないようにします。現場が変更についていけるかという不安が残っています。
• リスクの理由を、パッケージの機能不足や追加開発の工数超過と混同しないようにします。ここでは、キーパーソンの不安が業務プロセス設計の進捗に与える影響が問われています。
• 利用者の操作習熟が問題だと読み替えないようにします。本文で示されている懸念は、操作方法ではなく、変更後の業務プロセスが現場に受け入れられるかどうかです。

FAQ

解答の導き方

1. まず、業務プロセス設計チームには、新倉庫の管理者と既存2倉庫のキーパーソンが参加します。キーパーソンは新業務プロセス案の大枠に合意している一方で、「現場がついてこられるか不安だ」と感じています。つまり、業務プロセスの変更が実際の現場で受け入れられ、運用できるのかが懸念されています。
2. E課長は、その懸念から業務プロセスの設計作業が滞るリスクを考えました。そこで、D社と企業規模や業務内容が似ており、MWSの標準機能及び標準プロセスに合わせて業務を変更し、成果を出している企業の倉庫を訪問する計画を立てています。
3. 見学先の管理者や実務リーダとのディスカッションを通じて、同じような企業が標準機能・標準プロセスを使ってどのように業務を行っているか、具体的に知ることができます。したがって、この見学で狙った効果は、MWSの標準機能及び標準プロセスに合わせた業務でも実際に運用できることを確認し、設計を進める上での不安を軽減することです。

誤りやすいポイント

• 見学の目的を、単に他社の業務をまねることだと捉えないようにします。本文で重視されているのは、MWSの標準機能及び標準プロセスに合わせた業務が成り立つかどうかです。
• 「業務効率を向上させること」だけでは、見学によって確認しようとした内容が十分に表せません。標準機能・標準プロセスで運用できることまで結び付けます。
• 目的を、キーパーソンの不安を解消することだけにしないようにします。不安の軽減は期待できる効果ですが、見学の直接的な狙いは、実際に成果を出している企業の事例から運用可能性を確認することです。

FAQ

解答の導き方

1. まず、追加開発に必要な内容がいつ明らかになるかを確認します。業務プロセス設計では、MWSに合わせて業務プロセスを見直し、「それによって、追加開発の要件も確定する」とあります。つまり、この工程に参加すれば、追加開発の範囲や必要な機能を早い段階で把握できます。
2. 追加開発チームは、業務プロセス設計が終わった後に本格的に立ち上げる計画です。一方で、チームリーダのF主任は設計段階から参加します。これは、要件が確定してから初めて内容を把握するのではなく、設計の過程で追加開発の内容を理解し、チームの立ち上げに備えられるようにするためです。
3. また、プロトタイプiiでは追加開発の候補を洗い出し、概算の工数を見積もります。F主任が設計段階から関われば、候補となる開発内容を把握した上で工数を見積もり、投入可能工数に収まるかの検討にもつなげられます。

誤りやすいポイント

• 「追加開発チームの要員を増やすため」とするのは適切ではありません。本文が述べているのは、チームリーダのF主任を業務プロセス設計から参加させることです。
• 「MWSのパラメタ設定を担当させるため」と取り違えないようにします。F主任が参加するのは、追加開発チームのリーダとして、追加開発の要件や工数を早期に把握するためです。
• 「設計の作業を手伝わせるため」だけでは、追加開発との関係が明確になりません。要件の把握、工数見積り、チーム立ち上げへの準備まで結び付けて考えます。

FAQ

解答の導き方

誤りやすいポイント

• 「投入可能工数を超過した場合」だけに注目して、追加開発の機能を単純に削ると考えないようにします。本文が求めているのは、システム化の方針に沿った再検討です。
• 追加開発の工数上限を超えないように、要員や予算を増やすことが答えではありません。工数は予算の制約に基づいて設定されています。
• 業務プロセスの見直しだけ、または標準機能で実現できるかの確認だけに限定せず、標準機能の活用と、それに合わせた業務プロセスの見直しの両面を押さえます。

FAQ

解答の導き方

1. 問われているのは、業務プロセス設計の完了条件として、新しく定義する業務プロセスがシステム化の方針に合っているとはどういう状態かです。
2. 方針では、新業務プロセス案を「業務の統合と効率向上の観点から」定義するとしています。さらに、倉庫管理パッケージの標準機能や標準プロセスに合わせて業務プロセスを決める際にも、「業務の効率向上の観点で十分に評価する」とあります。
3. したがって、パッケージの標準機能に合わせることや、追加開発を投入可能工数以内に収めることだけでは、方針への適合を満たしません。新しい業務プロセスによって、業務の効率向上が実現できていることが必要です。

誤りやすいポイント

• パッケージの標準機能や標準プロセスに合わせることだけを、方針への適合と考えないようにします。方針では、業務の効率向上の観点から評価することも求めています。
• 追加開発が投入可能工数以内であることと、業務プロセスが方針に適合することは別の条件です。工数を守れていても、効率向上が図られていなければ十分ではありません。
• 無線ハンディ端末による在庫把握など、方針に含まれる個別の要件を答えるのではなく、設問が問う業務プロセスの評価基準に着目します。

FAQ