FC2ブログ

2014年 春季情報処理プロマネ解答速報 その2

記事ジャンル:情報処理試験



2014年 春季情報処理試験プロジェクトマネージャ試験を振り返る(その2)


今日も、2014/04/20に行われた情報処理試験プロマネの問題を振り返ります。
午後I試験の当方の回答例をたたき台にして議論をして頂ければと思います。

以下は、4/22に皆さまに配布したメルマガを引用します。




----------------------- 以下メルマガ引用 ----------------------------------

VOL. 59(part2) / 60号
                          発行日:2014/04/22
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

    2014年向け  情報処理試験 プロマネ完全対策

    --- あなたの合格率を確実に上げます ---
       
      「 プロジェクトマネージャ受験対策室 
      
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

発行者:みんなのSE創研 佐藤 創( http://creative-1st.com/ )


(注)本稿は等幅フォントでの参照を前提として記載しています。罫線などがず
  れて表示される場合は、ブラウザ及びビューアのフォントを等幅フォント
  に変更されることをお勧めします。

(注)本メールマガジンは長文になるため、複数に分割して配信される場合があ
  ります。メルマガのサブジェクトに(1/2)などの表記がある場合は分割され
  ていることを示します。


ご提供する受験対策の基本方針:
 ┌───────────────────────────────┐
 │ 受験勉強をラクに進められて、学習効果もある、        │
 │             長続きする勉強を体験して頂く    │
 └───────────────────────────────┘
 この基本方針の実現を目指します!


┌──────────────────────────────────
│●今回の目次
└──────────────────────────────────

 (1)メールマガジンについて

 (2)午後I試験速報:私の回答例(問2)
 



┌──────────────────────────────────
│(1)メールマガジンについて
└──────────────────────────────────
 
 本日もプロマネ試験の振り返りをしていきましょう。
 
 今回は午後I試験の問2について、当方の回答例をご参考までに示します。
 
 
 今週は不定期発行となります。また発行時間についても、午後にずれ込む事
 もございますので、その点だけ何卒ご了承を頂きたくお願い致します。
 
 
 また、今週は有料版・無料版ともに同じ内容でお届けいたします。
 
 
 有料版のメルマガは、4月30日に発行するメルマガで最終回となります。
 そして同日をもって有料版メルマガは廃刊とさせて頂きます。
 
 有料版が廃刊になっても皆様とのご縁を持たせて頂きたいと考えております
 ので、廃刊の後はよろしければ無料のメルマガへのご登録をお願い致します。
 
 なお廃刊になると自動的に皆様は購読解除となり、その時点で課金もストッ
 プします。特にご購読解除のお手続きは必要ございません。
 
 
 有料版の廃刊後はこちらへのご登録をお願いします。

 ・無料版 情報処理試験プロマネ対策 強化塾
  ⇒ http://www.mag2.com/m/0000260646.html

 なお4月30日頃に、有料版のメルマガが皆様のお役に立てたのかどうかに
 ついて、アンケートでご意見を頂戴したいと考えております。ぜひアンケー
 トへのご回答にご協力いただけますと幸いです。






┌──────────────────────────────────
│(2)午後I試験速報:私の回答例(問2)
└──────────────────────────────────

 個人的な回答例を示します。
 なお回答内容の正しさについては何らの保証は致しませんので、その点はご
 注意ください。この内容をたたき台として議論をして頂けますと幸いです。



問2.プロジェクトの進捗管理
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

(1)全体的な所感
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 かなり進捗管理だけに焦点を当てた問題です。これだけ狭い領域から出題さ
 れるのもなかなか珍しいかもしれません。
 
 そういう意味でややとっつきにくい印象を受けた受験者は多かったかも知れ
 ません。ただ、よくよく問題文を読んでいくと、それほど難しい問題ではあ
 りません。
 
 知識で回答する部分もあるものの、問題文に記載されている状況を分析し、
 進捗面などのリスクを回答させる問題もあるので、知識問題と問題文の読み
 取り問題とのバランスは悪くないと思います。
 
 また問題数も比較的少ないです。その分間違えられない、というプレッシャ
 ーはありますが。。
 
 ただ当方の個人的な感触だけが根拠ですが、6割は問題なく取れていると思
 います。
 
 
 

(2)当方の回答
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 当方の回答は以下となりました。
 回答の後にカッコでA~Cを記入していますが、個人的な自信度です。
 (A):9割以上の確率で正答しているはず
 (B):最低でも部分点はもらえる(回答の方向性はズレていない)はず
 (C):やや自信はなし
 
       0     5    10    15    20    25    30
      ├────┼────┼────┼────┼────┼────┤
 
 設問1   P社プロセスに納得できず開発効率が悪化する(A)

 設問2(1)Xiに子アクティビティiの計画工数を用いる(A)
    (2)所要期間を通じて毎日均等に進捗率が上がる前提(A)
    
 設問3   下線2:
       クリティカルパス上のアクティビティの作業遅れにより全体進捗が
       遅延するリスク(A)
       
       下線3:
      ・多くのレビューを担当し稼働計画に余裕がないため品質不良となる
       リスク(B)
      ・多くのレビューを担当し稼働計画に余裕がないためレビュー品質不
       良となるリスク(B)
       
 設問4  ・内部設計工程以降でQA表の細かな仕様の把握漏れが発生すること(A)
      ・内部設計工程以降で仕様の把握漏れが発生し、手戻りや品質不良が
       発生すること(A)




(3)回答の説明
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 設問1は、P社の確立したプロセスに統一しなかった理由を問われています。
 どんな問題を引き起こすことを恐れたか?と問われているので、発生する問
 題という形で回答を作成します。
 
 〔プロセス改善の方針〕セクションをしっかりと分析・理解すれば回答の方
 向性はいくつか見えてきます。
 
 まず、E社情報システム部の今のプロセスの特徴を列挙します。良い点と悪
 い点を○×で示します。良くも悪くも読み取れるのは-にします。
 
 
 ○チームワークが強く、開発の効率は悪くない
 -その時々の判断で開発を進めている
 ×新規にメンバが参画する際には進め方を習得するまで時間がかかる
 ○課長はこれまでの成功体験に自信を持っている
 -ノウハウの共有によるスピーディな対応を好む
 ×進捗遅延や品質問題は度々発生する
 ×大規模開発に対応するにはプロジェクトマネジメントの改善が必要
 
 
 全体的にはメンバ全員が一丸となって、具体的なノウハウを口頭などで共有
 し、コミュニケーションを密に取ることで、臨機応変に開発を進めている状
 況が読み取れます。臨機応変なので過去の方法を体系的にまとめていること
 はないので、プロジェクトによっては進捗遅延や品質不良が発生します。
 
 
 この状況に対してQ課長の示した方針は以下です。
 
 ・課長のマネジメントの問題点を具体的に指摘し気付きを与える。
  ⇒課長の成功体験や自信、開発効率が良いという成果を否定せず、これま
   での一定の成果を評価する、という意味があります。
   
 ・気付きを契機に規定されたプロセスの必要性を納得してもらう。
  ⇒その場限りの対応ではなく、繰り返し発生する問題に対応するためには
   一定の品質が担保されたプロセスを適用することが必要であることを、
   心理的にも徐々に納得してもらうアプローチを採用しています。
   
 特に「規定されたプロセスの必要性を納得してもらう」というところが重要
 なヒントになっています。
 
 
 Q課長の示した方針は、今までの成果を認めつつも、規定されたプロセスを
 徐々に納得してもらう、ということを示しています。逆に、この方針を経ず
 に一気にプロセスを統一したらどうなるでしょうか。
 
 
 各開発課の課長は、これまでと全く異なる規定されたプロセスを適用します
 が、そのプロセスを適用することの意義を全く理解できない、納得できない
 という結果になるでしょう。そして、プロセスをごっそり入れ替えるのです
 から、各課長が不慣れなプロセスを用いて開発を行うため、これまでの経験
 や自信などが効果的に発揮できず、開発効率が悪化することが懸念されます。
 
 
 こうした点をまとめれば回答になると思います。「プロセスの納得度」と
 「開発効率の悪化」の2点を踏まえて回答を作成します。細かな文言の違い
 は許容されると思います。
 
 
 
 
 設問2(1)は、親アクティビティの進捗計算が誤っているので直せ、とい
 う問題です。設問2(1)と(2)は完全に知識問題なので、ここが対応と
 して一番難しい設問だと思います。
 
 さて、まず親アクティビティの進捗率計算のどこが間違っているのでしょう
 か。
 
 問題文に記載されている進捗率計算の方法でまずは計算してみましょう。す
 ると、
 
 8.5日 ÷ 22日 = 0.386 ⇒ 38.6%
 
 という進捗率になります。
 
 
 これの何が間違っているのでしょうか。
 
 実は、あからさまな間違いではない、というのが当方の意見です。これは、
 所要日数ベースの進捗率を用いたい、というニーズが妥当なのであれば、こ
 れはこれで正しい情報だと思います。
 
 しかし、より精度の高い進捗率を求めるならば、分子・分母を所要日数では
 なく、所要工数にする必要があります。
 
 
 なぜ工数にすると進捗率の精度が高まるのでしょうか。問題に記載されてい
 るアクティビティ3-1-1-4を見てください。レビュー工数は0.3人
 日であることが分かりますが、所要日数だと最低でも1日となります。
 
 工数でとらえると、1日単位ではなく、実際の作業の重みづけが正確にでき
 るようになります。
 
 具体例で考えましょう。例えば、0.1人日で終わる作業が10個あったと
 します。問題文の進捗率で考えるならば、分子は10日間となります。しか
 し、実際には0.1×10=1人日の重みづけの作業量しかありません。
 
 親アクティビティの全所要工数が100人日、作業期間30日間だったとし
 ましょう。この場合、1人日とはたった1/100の重みづけしかない作業
 です。しかし、これを日数で計算してしまうと、10/30の重み付けにな
 ってしまい、本来重みづけの低い作業なのに、過剰に進捗率が良く見えてし
 まいます(逆に重みの高い作業が進捗率上は軽く見えることもあります)。
 
 
 これは、進捗管理上けっこう陥りやすい罠で、日数計算ではなく、コスト計
 算で集計しないと精度の高い進捗率は求めることができません。
 
 ただし、外部に請負契約で発注している場合は、協力会社のコストを管理集
 計することは契約違反です。こうした場合には、簡便的に日数を用いて、1
 日当たり7.5Hといった前提条件を付与し、日数ベースによる進捗管理を
 行うことになります。
 
 なので、ケースバイケースで、日数を用いるかコストを用いるのか判断する
 必要が出ます。こうしたことを理解しているのかどうかを問う問題でした。
 
 
 さて以上のようにコストベースで進捗率を出すためには、分子・分母に工数
 を用います。すると、
 
 12.3人日 ÷ 30.6人日 = 0.4019 ⇒ 40.2%
 
 の進捗率になります。
 
 
 進捗率の出し方にはこれ以外にも様々あり、深読みすれば別の回答を作成す
 ることもできます。
 
 計画工数を用いるだけではなく、残工数も用いて、
 
 (計画工数 - 残作業工数)÷ 計画工数
 
 で進捗率を出すこともできます。これはEVMと同じ考え方です。
 
 
 まあ、いろいろと手法はありますが、問題文の進捗管理表には残作業工数や
 実工数などの情報はなかったので、消去法で回答は求められていないと判断
 しました。
 
 よって回答例のような内容になります。
 
 
 
 
 設問2(2)ですが、これも安易に計画して、スケジューリングの前提条件
 を理解していないケースがあるので出題されているのだと思います。
 
 具体的にアクティビティ3-1-1-1を見てみましょう。所要日数が5日
 に対して進捗率60%です。評価対象日は5日目なので、本来はこの日に、
 進捗率100%になっていなければなりません。
 
 で、実績線は4月1日~4月3日まで引いてあります。進捗60%なので、
 1日の進捗率が、60%÷3日=20%/day ということが読み取れます。
 
 
 つまり、所要期間中は毎日定率で進捗率が上がっていくことを前提として計
 画をしている事になります。
 
 こうした前提条件を理解した上でスケジューリングしているのか、もしくは
 単に日数で割ったら結果的にそのような前提条件を付与してしまったのか、
 ということを分かっていますよね、と問われている実務的な問題です。
 
 
 
 
 設問3は、下線2と下線3のリスクを、理由と共に述べよ、という問題です。
 回答の作成の仕方としては、「○○のリスク」と文末をしめて、その前に理
 由(つまりリスク要因)を記載する、という形になります。
 
 ややヒントが多すぎて文言の作成に迷うのですが、絶対に外せないヒントさ
 え抑えることができれば正答できる問題だと思います。
 
 まず下線2と3は、それぞれ
 
 ・プロジェクト全体スケジュール
 
 ・多くの成果物の品質
 
 の観点からリスクを洗い出します。最大のヒントは、
 
 
 〔アクティビティに対するリソース割り当て〕
 ・プロジェクトのリーダであるG主任が、クリティカルパス上のアクティビ
  ティの約7割、レビューのアクティビティの約7割を担当している
  
  
 というところです。もうここでばっちり対応付けができます。あとは付加的
 なヒントで、
 
 ・G主任の稼働計画は、長時間の残業を前提にしている
 
 ・G主任の担当アクティビティに遅れが発生している
 
 ・G主任の稼働計画は余裕がない
 
 といったところも背景として踏まえることができます。
 
 
 クリティカルパス上のアクティビティが多ければ、それだけ遅延がプロジェ
 クト全体に波及するリスクも高まります。
 
 レビューの多くを担当していて稼働計画に余裕がなければ、それだけ品質レ
 ビューに時間を割けなくなり品質不要のリスクが高まります。
 
 こうした当たり前のことを回答として書ければ方向性としては間違いないと
 思います。
 
 
 
 
 設問4は、後の工程で生産性や品質の低下につながる問題とはどんな問題か?
 を問われています。よって、発生すると想定される問題の内容を回答します。
 
 「後の工程」という表記に注意しましょう。後の工程とは、現工程以降の工程
 のことです。現在は外部設計なので、内部設計以降の工程で発生することが想
 定される問題を取り上げる必要があります。
 
 ヒントは、
 
 
 〔外部設計の遅延対策〕
 ・この作業を省略し、後の工程で設計書とQ&A表を見比べて作業を行うこと
  にすれば、遅れは5日間で収まる。最終的な反映作業は、テストと並行して
  行うドキュメント整理期間に実施する。
 
 
 というところです。
 
 細かな仕様を外部設計書に反映せず、テスト工程まではQ&A表と外部設計書
 を見比べて作業を行う、という提案です。
 
 こんなことをした場合、まずもって発生しそうな問題は、細かな仕様を内部設
 計書にしっかりと落とし込めず漏れてしまうという問題です。仕様のトレーサ
 ビリティが確保できなければ、内部設計以降で品質不良による手戻りが発生し
 ます。
 
 それがテスト工程まで気付かない、なんてことになれば、手戻りの工数も大き
 くなってしまいます。こうした問題を危惧したのだと想定されます。
 
 それをまとめれば正答できます。あまり文言にこだわらず、仕様が後工程でき
 ちんと反映されない、という点を中心に回答すれば問題ないでしょう。
 
 
 
 
 今回は以上です。
 問3については、次回にご報告いたします。
 
 
 
 
 
 
 今回のメルマガは以上です。

 学習の途中で分らないこと、気になることなど、なんでも構いませんので、
 お気軽にご質問・ご意見を送付いただければ幸いです。本メルマガへの返信
 でOKです。できる限り回答させていただきます。
 
 今回も最後までお付き合い下さりありがとうございました。

 (メルマガ筆者:佐藤 創)


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
メールマガジン:2014年向け情報処理試験プロマネ完全対策
        -あなたの合格率を確実に上げます-
発行者:みんなのSE創研(プロジェクトマネージャ受験対策室) 佐藤 創
サイト:http://creative-1st.com/

メールマガジンの登録・解除は以下からお願いします。
登録・解除:http://www.mag2.com/m/0001620884.html

ご意見・感想を募集しています。今後取り上げて欲しい内容など、
何でも良いのでお気軽にご意見して頂きたく思います。ご意見等は
本メールへの返信でお願い致します。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━





関連記事
↓記事が参考になったらクリックお願いします

テーマ : 資格試験
ジャンル : 就職・お仕事

コメントの投稿

非公開コメント

プロフィール

so-tan

Author:so-tan
佐藤 創。仙台のIT業界でシステム開発に従事しながら、情報処理試験プロマネの受験対策を実施(「このブログについて」参照)。情報処理技術者システムアナリスト、プロジェクトマネージャ、中小企業診断士。日々自分のキャリアや様々な問題に悩みつつも、前向きに問題に立ち向かえる自分でありたいと願う。そんな日々の記録です。
Twitter → @sato__so__
FB → facebook.com/creative.1st.pm

人気の連載エントリ
当ブログではテーマに沿った連載エントリがあります。掘り下げた議論がお好きなら以下からどうぞ。
  1. 受託・派遣型の中小ソフトウェア業が抱える課題
  2. 情報サービス産業の今を俯瞰する
  3. 自分の強みを仕事に活かし仕事を楽しむ
  4. 情報システム派生開発プロセスの工夫
全記事表示リンク

全ての記事を表示する

カテゴリ
最新記事
最新コメント
最新トラックバック
月別アーカイブ
アクセスカウンター
検索フォーム
RSSリンクの表示
リンク