トップ > 仕事&就職 > 資格 > 高度情報処理技術者試験の論文集

高度情報処理技術者試験の論文集

RSS

高度情報処理技術者試験で必要な論文について、私の書き下ろしや寄稿された論文をお届けします。IT業界で働く方、システムエンジニア・プロジェクトマネージャ・アナリストの方、必見!



メルマガの登録・解除

登録した方には、メルマ!からオフィシャルメルマガ(無料)をお届けします。


最新の記事リスト

  1. このメルマガは最新記事のみ表示されています

メルマガ情報

最終発行日:
2007-10-15
発行部数:
1012
総発行部数:
213995
創刊日:
2000-10-17
発行周期:
第5を除く月曜日+不定期
Score!:
48点

[情報処理論文 2007.10.15 NO.585] PM-寄稿

発行日: 10/15


□─────────────────────────────────□
[情報処理論文  2007.10.15  NO.585] PM-寄稿
■□■───────────────────────────────□
□■□                    発行年月日:2007.10.15
                         総発行部数:4,822

  高度情報処理技術者試験の論文集 NO.585
                          まぐまぐ:2,746
  〜 私はこれで論文を書きました         メルマ!:1,154
                         めろんぱん:  533
    皆さんもこれで論文を書いて下さい 〜  めるまが天国:  266
                                               カプライト:  123

                                                               ■□■
■───────────────────────────────□■□

□メールマガジンの主旨□──────────────────────□
  このメールマガジンは、試験の合格だけを目的としたものでは
 ありません。試験勉強を通じ、仕事のあるべき姿を学び、現実と
 のギャップを埋める事が目的です。つまり、私にとっては例え全
 ての区分に合格しようとも、メールマガジンの発行は勉強です。

  また、この主旨に賛同できる読者とのコラボレーションを期待
 するもので、私が指導者という立場を取る事はありません。従っ
 てメールマガジンの発行そのものを有料化する事はありません。

  このメールマガジンが、IT業界で働く・働こうとする方々のス
 キルアップに、少しでも御役に立てれば幸いです。


□─────────────────────────────────□

□今回の内容□───────────────────────────□

  今回は、 武藤さんから寄稿して頂いたPM論文をお届けします。
  3月に寄稿して頂いていたのですが、当時は春試験を優先で配
 信し、秋試験までにはと思っていたら、こんなに遅くなっていし
 まいました。申し訳ありません、そして、どうもありがとうござ
 いました。


□─────────────────────────────────□

□関連バックナンバー────────────────────────□

(無し)

□─────────────────────────────────□

 山口殿
 大変お世話になっています
 武藤と申します。

 私は以前山口殿のHP論文集を参考にしてPM試験に合格
しました。大変感謝しています。ありがとうございまし
た。

 遅ればせながら、そのときの論文を寄稿します。
 添削されて不適でしたら削除されても結構です




□─────────────────────────────────□

 H14-PM-問1 クリティカルパス上の工程における進捗管理について

□─────────────────────────────────□

 プロジェクトマネージャは、プロジェクト計画の作成
において、作業の実施順序を決め、資源の割当てを行い、
実行可能なスケジュールを作成する。そして、
スケジュール上のクリティカルパスを明確にする。

 クリティカルパス上にある工程は、その進捗の遅れが
プロジェクト全体の進捗に影響する。特に、作業者の増
員などの単純な対策では遅れが回復できないような工程
は、重点的に管理する必要がある。このような工程には、
問題の兆候を早期に発見するための手続を組み込み、進
捗の遅れが発生する前に対策を行うことが肝要である。

 問題の兆候を早期に発見するためには、成果物の作成
状況や未解決案件を報告させる、定期的に成果物を提出
させ報告の内容と照らし合わせるなどの手続を組み込む。
そして、例えば、設計工程において未解決案件や仕様変
更などが増えていないか、チームリーダが担当者の進捗
報告を鵜呑みにしていないかなどの観点で、問題の兆候
の発見に努め、進捗に悪影響を及ぼす状況があれば必要
な処置を取る。

 一方、進捗の遅れが顕在化した場合は、原因分析を行
い、対策を実施する。例えば、一部の担当者に負荷が集
中しているなどの原因で進捗の遅れが発生していれば、
作業量の調整や作業の実施順序の変更などを行い、遅れ
の拡大防止や早期回復を図り、計画時に考慮した許容範
囲内で、クリティカルパス上の工程の進捗を守るように
努める。

 あなたの経験に基づいて、設問ア〜ウに従って論述せ
よ。


設問ア あなたが携わったプロジェクトの概要と、クリ
   ティカルパス上で重点的に進捗を管理した工程及
   びその理由を、800字以内で述べよ。

設問イ あなたが重点的に進捗を管理した工程において、
   問題の兆候を早期に発見するためにどのような手
   続を組み込んだか。そして、問題の兆候に対して
   どのような処置を取り、進捗の遅れに対してどの
   ような原因分析と対策を実施したか、具体的に述
   べよ。

設問ウ 設問イで述べた活動をどのように評価している
   か。また、今後どのような改善を考えているか。
   それぞれ簡潔に述べよ。

  


□─────────────────────────────────□

 武藤さんから寄稿して頂いた論文(2007.3.5)

□─────────────────────────────────□


----------------------------------------------------------------------

(クリティカルパス上の工程における進捗管理について)

----------------------------------------------------------------------


----------------------------------------------------------------------
(設問ア)
----------------------------------------------------------------------
1.プロジェクト概要と重点管理工程
---------------------------------------------------------------------
1.1 システム開発と私の立場
----
 私はU社に所属するが、三年前に市外電話を提供する
電気通信事業会社であるN社のコールセンタシステム開
発に参画した。私の立場はプロジェクトリーダーであり、
15人の部下を指導しつつ開発をすすめた。

----
1.2 プロジェクト概要
----
 N社コールセンタでは、顧客情報管理,応対情報管理,
サービス情報管理が主な業務である。この開発では、デ
ータベースおよび入出力画面が中心となるため、開発手
法としてDOA(Data Oriented Approach)を採用し、ク
ライアントサーバー方式とした。

 開発規模は約百人月である。N社の新サービスが半年
後から開始されることが決定しているため、基本設計か
らカットオーバーまでは半年の期間しかなかった。

----
1.3 重点管理工程とその判断理由
----
1.3.1 重点管理工程
--
 私は、当プロジェクトにおいて重点的に進捗管理すべ
き工程は「プログラム製造工程」であり、特に画面系の
プログラム製造工程がクリティカルパスだと判断し、重
点的に管理した。
--
1.3.2 判断理由
--
 今回使用する画面パッケージは、外国製であり、日本
での開発実績が無く、U社には初めての適用である。ま
た、プログラム製造を担当する作業者は全て協力会社で
あり、U社との取引は初めてである。新製品のパッケー
ジを使用する場合は、不慣れによる生産性の低下や標準
化資料が熟成されていないため、品質低下が予想される。
また、初契約の協力会社と作業する場合には、要員の能
力や開発標準の準拠度合い等を把握し、問題発生時には、
早急な対策が必要である。


---------------------------------------------------------------------
(設問イ)
---------------------------------------------------------------------
2.問題兆候早期発見の手続き・処置と遅延対策
---------------------------------------------------------------------
2.1 問題の兆候を早期発見するための手続き
----
 問題の早期発見の為には、管理対象を明確化し、作業
予定と作業実績との差異を定期的に収集し、分析する必
要がある。

(1)WBSによる管理対象の明確化
 私は、作業項目の漏れをなくすため、WBS(Work
Break down Structure) を用い、アクティビティ単位ま
で分解し、その責任者を明確化した。

(2)PERT図と稲妻チャートでの予実収集
 あわせて、作業の順序や余裕日数,クリティカルパス
を明確にするため、チーム単位でのPERT図をチーム
リーダに作成させた。また、作業の予定と実績との差異
を図的に表現するため、稲妻チャートを作成させた。

(3)週1回の定例会議
 さらに、一週間に一度の定例会議を開催し、チームリ
ーダを招請して、開発の進捗状況を報告させた。

(4)週報等での詳細確認
 しかし、チームリーダによっては報告が曖昧なケース
もあるため、開発担当者に週報を提出させ、チームリー
ダの報告に矛盾がないかを検証した。

(5)パイロットプログラムによる技術確立
 また、処理をパターン化し、パターン毎のパイロット
プログラムを先行して作成させた。この目的は、協力会
社社員がU社開発標準を準拠しているかの検証と、パッ
ケージに潜む問題点を早期発見するためである。

----
2.2 問題の兆候に対する処置
----
(1)パッケージ不具合に起因する問題の処置
 一部の画面系のパイロットプログラムが、他の作業に
比べ3日ほど遅れていることが稲妻チャートから判った。
原因を聞いてみると、パッケージのインタフェース仕様
が実際と違うためである。私は、今後も同様の問題が発
生する可能性があると判断し、パッケージ製造会社であ
るA社と協議した。そしてA社技術担当への直接の連絡
体制を確立すると共に問題点の修正を依頼した。

(2)協力会社社員に起因する問題の処置
 パイロットプログラムのコードレビューを行ったとこ
ろ、一部の担当者がU社作成の開発標準を理解していな
いことが判明した。その理由は、標準化説明の際に該当
の担当者が不参加だったためである。標準化への準拠は、
成果物の品質や生産性・保守性・操作性等を向上させる
ための必須事項である。そこで、不参加メンバーへの再
教育を行い、パイロットプログラムの修正を行わせた。

----
2.3 進捗遅れに対する原因分析と実施した対策
----
(1)パッケージへの不慣れによる遅れ対策
 本格的なプログラム製造工程にて、一部のプログラム
が遅れていることが判った。原因は、パイロットプログ
ラムの処理パターンが少なかったためである。この対策
は、類似したサンプルプログラムをA社から提供しても
らい対処した。そして作成したパターンは標準化資料に
追加した。当初のパイロットプログラム10本に対して
追加件数は3本である。

(2)パッケージの不具合による遅れ対策
 複雑な削除処理を行う画面プログラムにて作業遅れが
発生した。原因は、パッケージの不具合である。この対
策は、N社に原因と状況を説明し、問題となっているプ
ログラム検収を後回しにすることの了解を得た。また、
A社に対しては、事前に取り決めていた手順に従い実行
ログや入出力の情報等を送ると共に、未解決案件の進捗
管理を行った。パッケージ不具合による遅れの件数は
3件である。


---------------------------------------------------------------------
(設問ウ)
---------------------------------------------------------------------
3.評価および今後の改善策
---------------------------------------------------------------------
3.1 評価
----
 稲妻チャート,パイロットプログラム等により、問題
の兆候を早期発見できた。また、兆候を基に行った処置
に対しては、A社と協議をしたことにより以降の問題が
スムーズに解決できた。あわせて、開発標準の再教育を
行なうことで、高い生産性や保守性・操作性・品質が確
保できた。

 進捗遅れの対策に対しては、PERT図により他工程
に余裕があることが判ったため、作業分担の平準化を行
い対処することができた。このため、工程内で遅延を吸
収した。

----
3.2 今後の改善策
----
 工程管理法の可視化により、問題の早期発見や余裕工
程の存在を知ることができる。しかし、それだけに頼っ
ていたのでは、タイトな開発には対応できない。今後は、
設計工程と製造工程とを別契約で実施する段階契約の採
用や、顧客の仕様変更の都度、再度計画を見直すことが
できる柔軟な契約を締結しておくことが重要であると思
う。




−以上−






□─────────────────────────────────□

 山口からのコメント

□─────────────────────────────────□

武@585>  添削されて不適でしたら削除されても結構です

 とんでもありません、合格時の再現論文はとても貴重
です。試験ぎりぎりになってしまいましたが、配信させ
て頂きます。

 でも、合格論文にあれこれとコメントをつけたところ
で、所詮後付け。少し控えめにさせて頂きます。


----------------------------------------------------------------------

ア. 設問の解釈

----------------------------------------------------------------------

 この設問は、ちょっとだけ書きにくいかなという気が
しました。その理由を含めながら、構成からコメントし
ていみたいと思います。

----
1.クリティカルパス上で重点的に管理した工程及びその理由

 以下に幾つか例示しておきますが、それなりの納得感
があれば良いでしょう。

・業務に精通した要員を手配できない:要件定義
・新開発言語を使用する      :プログラム製作
・極めて高い品質が要求される   :テスト
(人命を左右するようなシステムだったり)

----
2.問題の兆候を早期に発見するために組み込んだ手続き

 質問に例示されている通りです。

・成果物の作成状況や未解決案件を報告させる。
・成果物を提出させ報告の内容と照らし合わせる。

 その他にも、このようなことが考えられます。

・EVを用いて完了時見込み工数の変化をトレースする。

----
3.兆候に対する処置

 ここでのポイントは、進捗の遅れが顕在化する前に、
先に述べた手続きによって、兆候を把握するということ
です。兆候を把握した時点で、相当の進捗の遅れが発生
しているケースでは、次の原因分析・対策と、論述が重
複します。

・設計工程において未解決案件や仕様変更などが増えて
 いないか

 → 特定チームに仕様変更が集中しているようであれ、
 ば再度レビューを行い、問題点の棚卸しをする。

・チームリーダが担当者の進捗報告を鵜呑みにしていな
 いか

 → 実際の成果物と進捗報告のギャップをリーダーに
 示し、担当者の進捗報告を改善させる。

----
4.遅れに対する原因分析と対策

 ここは、やや頭が痛いところです。何故ならば、兆候
を見つけて、その段階で処置したならば、更なる遅れは
発生しなかったかもしれないからです。しかし、それで
は設問に沿った論文になりませんので、全く異なる要因
で、実際に遅れが発生して貰わないといけません。

 もう一つの論述の方法は、あえて章を分けることなく、
兆候を見つけた時点で、僅かながらでも遅れが発生して
いたことにし、兆候を見つけた時点での原因分析と対策
を述べてしまう方法です。

 先のコメントとは矛盾しますが、私は、後者の展開の
方が望ましいだろうと思います。何故ならば、前者の展
開をとると、「実際に発生した遅れに対する兆候は何故
検知できなかったのか」という疑問を抱かせてしまうか
らです。


----------------------------------------------------------------------

イ.設問に沿っているか?

----------------------------------------------------------------------
 さて、武藤さんの論文ですが、良く書けていると思い
ます。

 ちなみに私が難しいかなと思ったところは、前者の展
開を取られているようです。

----
山@585> 1.クリティカルパス上で重点的に管理した工程及びその理由

・外国製パッケージで、日本での使用実績無し。
・はじめての協力会社との取引。
・よって、プログラム製造工程を重点管理する。

----
山@585> 2.問題の兆候を早期に発見するために組み込んだ手続き

武@585> (1)WBSによる管理対象の明確化
武@585> (2)PERT図と稲妻チャートでの予実収集
武@585> (3)週1回の定例会議
武@585> (4)週報等での詳細確認
武@585> (5)パイロットプログラムによる技術確立

----
山@585> 3.兆候に対する処置

武@585> (1)パッケージ不具合に起因する問題の処置
武@585> (2)協力会社社員に起因する問題の処置

----
山@585> 4.遅れに対する原因分析と対策

武@585> (1)パッケージへの不慣れによる遅れ対策
武@585> (2)パッケージの不具合による遅れ対策

 上記原因による遅れは、突然起きたのか、兆候を事前
に把握することができなかったのか、という疑問は先の
コメントの通りですね。


----------------------------------------------------------------------

ウ.その他

----------------------------------------------------------------------
 パイロットプログラムということに関する論述でやや
疑問を感じました。というのは、パイロットプログラム
の本質とは何だろうということです。

 武藤さんも論述されている通り、基本は品質保証の手
段だと思います。(少なくともこの論文では)

武@585>                  新製品のパッケー
武@585> ジを使用する場合は、不慣れによる生産性の低下や標準
武@585> 化資料が熟成されていないため、品質低下が予想される。

 品質不良は勿論手戻りにより、進捗にも影響を与える
ので、パイロットプログラムはプロジェクトを予定通り
進めることに対しても効果的なのですが、ワンクッショ
ン入っている分、ちょっと受け入れにくいかなと思いま
した。

 ここは、進捗管理を問われている質問なので、「新製
品のパッケージなので、見積もり時の生産性が発揮でき
るか不明である。よって、パイロットプログラムにより、
生産性の検証を行った。」とした方がストレートで良
かったかもしれません。

----------------------------------------------------------------------
武@585>                       この対
武@585> 策は、N社に原因と状況を説明し、問題となっているプ
武@585> ログラム検収を後回しにすることの了解を得た。

 直接は記述されていませんが、U社とN社は請負契約
では無いのでしょうか?

 もしそうなら、プログラム単位に検収を上げて貰うと
いうことも、それを遅らせることについてN者の了解を
得るということもちょっと不思議に感じます。




□─────────────────────────────────□



□論文募集□────────────────────────────□

 1.さんしのごいさんからAU論文(2007.3.12)
 2.oleoさんからAU論文(2007.3.28)

  秋試験優先で配信中。


□あとがき□────────────────────────────□

  残り1週間になりましたね。 9月はそれなりに勉強時間を取れ
 ていたのですが、10月になってからはサッパリです。これまでの
 積み重ねによる実力が問われる試験になりそうです。


□─────────────────────────────────□
 電子メールマガジン 高度情報処理技術者試験の論文集
 ペンネーム   : 山口 ヒカル
 メールアドレス : yamahjs@mx36.tiki.ne.jp
 ホームページ  : http://ww5.tiki.ne.jp/~nmura/js/
□─────────────────────────────────□
 a.論文の寄稿・コメント、その他ご意見・ご感想は上記アドレス
  まで願いいたします。
 b.寄稿して頂いた論文・コメント、その他ご意見・ご感想につい
  ては、特にお断りする事無くメールマガジンにてご紹介・回答
  させて頂きます。
 c.メールマガジンに掲載して欲しく無い内容や、私信については、
  その旨を必ず記述して下さい。但し、申し訳ございませんが、
  その場合、個別に返答させて頂くか否かは当方で判断させて頂
  きます。

 ※最後に、本誌の内容の無断転載を禁じます。転載・掲載をご希
 望の際は事前にご連絡ください。
□─────────────────────────────────□
 このメールマガジンは、以下の配信システムを利用しています。
 ☆『まぐまぐ』 http://www.mag2.com/m/0000019742.htm
 ☆『メルマ!』 http://www.melma.com/ (ID:m00021304
 ☆『めろんぱん』 http://www.melonpan.net/ (ID:88
 ☆『めるまが天国』 http://melten.com/m/8838.html
 ☆『カプライト』 http://cgi.kapu.biglobe.ne.jp/m/8791.html
 *購読の停止は、上記よりお願いします。
□─────────────────────────────────□

ブックマークに登録する

TwitterでつぶやくLismeトピックスに追加するはてなブックマークに追加del.icio.usに追加Buzzurlにブックマークニフティクリップに追加Yahoo!ブックマークに登録
My Yahoo!に追加Add to Google

規約に同意してこのメルマガに登録/解除する

登録/解除

メルマ!のおすすめメルマガ

  1. 競馬史上最強の法則 〓ジェノミクス〓

    最終発行日:
    2016/12/05
    読者数:
    1289人

    【まぐまぐ殿堂入り/155万馬券的中マガジン】発行16年の実績(2000年創刊)JRA主催競馬予想大会チャンピオンで総読者数18000名に支持される[現役プロ]の錬金術とは?!独自理論[表と裏]の存在証明⇒毎週会員情報[Sセミナー]と同じパラメータ+推奨馬を提供〓推奨馬の的中率83%!

  2. 私だけの『シンデレラ・ストーリー』

    最終発行日:
    2015/12/02
    読者数:
    1815人

    東洋医学と西洋エステが融合した世界初のエステを生んだジョジアン・ロールのメルマガ。ダイエット(特に足やせ)や美白効果のあるノウハウ紹介、大人気「今日の素敵なストーリー」など満載!読者限定プレゼント有!

  3. 筋トレでダイエット メリハリボディになる100の秘密

    最終発行日:
    2008/01/31
    読者数:
    2234人

    筋肉を鍛えるという事はただ単に体を大きくすることではありません。体を引き締めたり、体重を絞ったり、運動競技能力を向上させる事も出来ます。 これからダイエットやエクササイズを始める方に効率の良い身体の作り方をお教えします。

  4. 運命の女神に好かれる法則

    最終発行日:
    2016/10/07
    読者数:
    3447人

    「運命の女神に好かれる法則」とは、「運命の女神の常識」と「人間の常識」の違いを理解し、「運命の女神」に好かれ生き方(ノウハウ)をまとめたものです。「運命の女神」に好かれて、幸運・強運のチャンスをつかみ人生の成功者になりましょう。

  5. 87日で学ぶ!基本英文法

    最終発行日:
    2009/01/28
    読者数:
    1118人

    大学受験・TOEIC・英検で必須の英文法の基礎・基本を3ヶ月で!毎日のメール チェックのついでに読むだけで、be動詞などの初歩から比較・現在完了・受動 態・不定詞・動名詞・分詞構文・仮定法まで学べます。

発行者プロフィール

山口 ヒカル

山口 ヒカル

http://ww5.tiki.ne.jp/~nmura/js

メールマガジンの発行を通じて、どうしても欲しかったPM/ANだけでなくAU/SMまで合格しました。一時期浮気をして、PMPの取得に走ったりしましたが。ということで、趣味はIT資格取得? と思われるかもしれませんが、吹奏楽ではTUBAを吹き、4年間PTA活動をしたり、と本当に忙しい毎日を送っています。でも、仕事だけじゃない生活が、色んな視点を私に与えてくれるのだと思っています。