2006年8月27日

経験のない人のプロジェクトマネージャ、小論文対策

プロジェクト経験の少ない方のための論文対策

 講座受講生である「今回は絶対に合格したい」さんから質問状をいただきました。 皆さんにも通用する内容なので、公開質問とさせていただきたいと思います。

 先生に添削して頂いた論文結果を見ると以下のところで大量点を落としています。経験豊富な先生には気づかれているかもしれ ませんが、私はプロジェクトの経験が少なく以下の内容を書くのにとっても苦労します。

論文対策上困っている点
  1. 職務の分離を十分理解しているか
  2. 自分が行ったことのアピールが充分できているか
  3. 採用技術選定の具体的記述があるか
  4. 活動を裏付ける、根拠を充分用意できているか
  5. 種目の適切な見識や知識・造詣をもっているか

私のようなプロジェクトの経験が少ない人でも点数が取れる論文を作成したいのですが、どのような記述をすればよろしいでしょうか?ご教授お願いします

プロジェクトマネージャ論文の要点
プロジェクトマネージャの職務の分離について

 情報処理技術者試験の論文で重要な点が職務の分離です。 通常、わが国のSEは「要件定義もするし、設計もする、さらにはプロジェクト管理もおこなう」 ことが定番となっていますが、本試験の論文でこれを論述すると落第 してしまいます。そこで、次のような工夫が必要です。

  1. 「システム設計した」などと他区分に該当する内容は論述してはいけない
  2. 「プロジェクト組織や契約内容を把握している」など管理者としての立場が明らかである
  3. 「プロジェクト目的の理解」「周知徹底」など管理職らしい行動様式が見られる
  4. 「紙ベースの管理」と「実地検分」とのバランスが良い

要は管理職としてのスタンスがはっきり論文から伝わってくるように論述することが 重要です。

自分が行ったことのアピールが充分できているか

プロジェクトマネージャとしての行動様式の正当性を確保する必要があります。 そこで次のような対策が必要でしょう

  1. 「購買管理規定」に従うなど、組織の規範に沿って行動しているか
  2. 「ISO9000」などの国際標準のプロセスを理解して行動を行っているか
  3. 「その場しのぎ」ではなくあくまで「計画的」にプロジェクトを運用しているか
  4. 「理論的・科学的手法」と「実践で発生しやすいリスク」を良く理解して相互のバランスをとり行動しているか

プロジェクトの経験がなくても、会社に存在する、プロジェクト計画書やISO9000の品質 管理マニュアルを読めば、どのような局面で、どのような行動を行わなければならないのか を学び、その規範に従ってそのまま論述してゆけばよいのです。

採用技術選定の具体的記述があるか

プロジェクトマネージャとしての採用技術は、例え、経験がなくても 次の文献を読めば妥当な採用技術が何かがわかるはずです。

  1. PMBOK(Project Management Body Of Knowledge)
  2. QC(Quality Control)の7つ道具
  3. 午後Iで出題されている問題解決技術
  4. 法律「民法の請負」「労働派遣法」などに基づく実務
  5. スコープ委員会の開催、品質管理委員会の開催など組織的な行動実績

 一番の参考書は、PMBOK(Project Management Body Of Knowledge)です。 ここに書かれている採用技術を書けば、余程のことがなければ90%合格できるはずです。

 「民法の請負」「労働派遣法」は、中小企業診断士の経営法務の問題や解説を読めば 契約の際にどのような留意点が必要なのかがわかります。

活動を裏付ける、根拠を充分用意できているか

プロジェクトマネージャは管理職ですから、品質保証マニュアルや契約書などのような 文書に基づいて管理活動を行います。その際、以下のような文書を抑えておいてください。

  1. 「請負契約書」などプロジェクトの基点となる基本文書
  2.   
  3. 「情報戦略書」など企業の行動規範となる文書(※アナリスト、監査用)
  4. 「品質マニュアル」などプロジェクトの行動規範となる文書
  5. 「テスト手順書」などの現場における具体的な行動規範
  6. 「プロジェクト計画書」「テスト計画書」などの計画書の類
  7. 「テスト結果」「開発日報」など現場から上がってくる文書

上記の文書のうち、論文のテーマに沿って必要なものをピックアップして 論文のなかにちりばめて行けばよいのです。

種目の適切な見識や知識・造詣をもっているか

論述の際には次の点に留意して行くことが大切です。

  1. プロジェクトの目的を設問ア「プロジェクト概要」で述べているか
  2.   
  3. 自分の行動様式の妥当性を文書などの客観的な物証で証明できるか
  4. ユーザアンケートによる顧客満足などに逃げることなく、採点者に対して自分のこ有働の妥当性を説得できるか

この部分は設問ウの説得力を現している基準なのです。

※ご注意:あくまでこの採点基準は加藤忠宏の採点基準に過ぎません


プロジェクトマネージャ試験・小論文支援は、
(c)(有)アイ・リンク・コンサルタント 加藤忠宏



投稿者 kato : 13:48

2006年7月31日

PM午後Iの解答法について

プロジェクトマネージャ試験の午後Iについて

生徒さんから午後Iの勉強法を尋ねられました

 最初はメールだけで対応しようかなと思いましたが、しばらくしているうちに考えたことがあるので簡潔に書きます

 この方は「解答例、そっくりの解答をするのですが不合格でした」とのことです 御本人さんはPMBOKの理解が足りないのではないかと悩んでおられますが、それだけではなさそうです。

プロジェクトマネージャ試験午後I解答時の留意点

 自分が受験生だったときに午後Iについて、考えていたことを書きます。

  1. 設問をよく読むこと
  2. どの場所に設問の解答のヒントがあるかを真剣に探索すること
  3. 例外はあるけれど、基本的に問題文中にある根拠を元に解答すること
  4. 問題文中に指摘した欠陥や無管理状態を放置する場合のリスクをしっかりと想定すること
  5. 解答にあたっては、問題文中の用語を使い解答すること
  6. 先に結論をかき、その後に理由や根拠を書くこと
解答例そっくりでも落ちることがある

 以前、システム監査技術者試験で落ちまくっていたときに、午後Iについて 反省したことがあります。それは解答例とそっくりな解答を作っていても、採点者にアピールできていないのではないか

 そこで次のようなことに注意して午後Iの解答を作ることにした。

  1. まず、基本として問題点を、あるいはプロジェクトリスク要因について問題文から抜書きする
  2. 根拠を書くときは、文書名、事実を必ず記載する
  3. 冗長な表現を使わない
  4. リスク等の理由を問われたら「~であるから」「~であるため」と語尾を統一して解答する
プロジェクトマネージャ試験午後Iはやさしい

 プロジェクトマネージャ試験の基本は次のような、あなたの行動様式がチェックされます

チェックされる行動様式
  1. プロジェクトリスクを察知して事前に対策を講じることができるか
  2. リスクヘッジの対策が適切か
  3. リスクヘッジ対策は契約書、民法など合理的なものに基づいて実施されているか
  4. 行動様式の中に顧客、上司に対する「報告・連絡・相談」が含まれているか
プロジェクトマネージャ試験はやさしい

プロジェクトマネージャ試験午後Iは高度試験のなかで一番易しい試験だと思っています。 その根拠は次のとおりです

  1. 民法、契約に関する知識以外の特別な知識は不要
  2. 問題文のなかに対外のヒントが潜んでいる

 つまりPMBOK(Project Management Body Of Knowledge)の特別な知識は 不要なのです。当たり前のことが当たり前にできれば良いのです。


プロジェクトマネージャ試験・小論文支援は、
(c)(有)アイ・リンク・コンサルタント 加藤忠宏



投稿者 kato : 08:32

2006年7月 9日

アジャイル型超々小規模プロジェクト

アジャイル的プロジェクト管理へのWeb2.0への応用

 現在,ある「遊び」のプロジェクトを企画しています。プロジェクト自身は対したものではないの ですが、メンバが分散的に存在していて、それぞれが異なる組織に所属している状況で、1つの ゴールに向けて行動しようとしている点で「プロジェクト」と位置づけて良いでしょう。

 まあ、日ごろ忙しい経営者達ですから、気晴らしにプロジェクトの名にこじつけて、会社の社長どうしが、一種のゴルフコンペの企画を行っているようなも ものだと考えて気軽に話をよんでください。

プロジェクトの条件
  1. プロジェクトメンバは全国各地に分散している
  2. それぞれのメンバは異なる組織の長(分かりやすくいうと社長)である
  3. その意味で自律的、自立的であり、それぞれ異なる意図を持って行動している
  4. プロジェクトメンバはメール、メーリングリスト、ブログ(xhtml)を使いこなしている
  5. 多忙なメンバゆえ、スカイプやチャットなど時間的拘束を要するITツールは使わない
  6. 上記の条件でITツールを使いこなしつつ情報やナレッジ、意思の共有化を図る

プロジェクトは現在活発に活動中です。このようなプロジェクト組織の構築・運用に。IT思想的には Web2.0(情報の発信、受信、検索、共有)を応用してみました。ITツール的には、 RSS,トラックバックなどのWebの動的機能などを使っています。加えて従来型のメーリングリストなどの ツールも組み合わせて(これをマッシュアップというらしいですが)みました。

アジャイル型開発について

 アジャイルアライアンス宣言によりますと、アジャイル開発 手法は次のような特徴をもちます。

  1. プロセスやツールよりもメンバーの交流を大切にする
  2. 包括的ドキュメントに傾注するよりも、プロジェクト開発に努力する
  3. 契約交渉よりも顧客的コラボレーションを重視する
  4. 計画に従順になるよりも、環境の変化に柔軟に対応する

私たちのプロジェクトはまさに上記の条件にぴったりです。なぜなら、互いの立場は対等であり、 目的が達成されれば過程はあまり重視されないからです。また、プロジェクトの参入障壁を低くして 、かつプロジェクトからの退出も自由にしてゆきたかったからです。

当たり前ですが、会社経営者の場合、仕事も家庭も地域社会との関係も重要です。そのバランス を取りつつ、プロジェクトを円満に推進しつつ、共有すべきゴールに到達してゆくにはアジャイル開発手法はまことに 都合が良かったのです。

プロジェクトへの応用について

現在、プロジェクトの真っ最中なのですけれど途中経過を報告します。

Web2.0的なツールの応用結果
  1. ブログのトラックバック機能やRSSの利用によって、それぞれがおかれている状況(多忙さ等)がよく理解できて、相互理解が円滑にできている
  2. 共有すべきドキュメントは殆ど、ハイパーテキストで存在し、文書の作成負担は少ない。また 、この結果、プロジェクト推進に専念することができる
プロジェクト運営的にみた効果
  1. 契約交渉を厳格にしないことにより参入、退出が自由で柔軟な組織となっている、また、SNS(Social Network System)的コラボレーションが得られ 参入者が動的に増えつつある
  2. 共有すべきゴールや理念を周知しつつ、環境の変化に柔軟に対応することができる

 PMBOK(Project Management Body Of Knowledge)やISO9001を批判するわけではありませんが、 発想を柔軟化することによって、他社とのコラボレーションや海外企業などの協力会社対応などに、 あるいは異なる組織文化を持つ協力会社とのプロジェクト上の協調関係にWeb2.0的対応やアジャイル 開発手法は応用できるかもしれないと考えているのです。

参考文献:「Web2.0 BOOK」小川浩、後藤康成共著
プロジェクトマネージャ試験・小論文支援は、
(c)(有)アイ・リンク・コンサルタント 加藤忠宏



投稿者 kato : 20:24

2006年5月27日

プロジェクト選択について

プロジェクト選択についての回答

読者の方からご質問をいただきました。

読者の方からのご質問内容

プロジェクト選択に関する論文を集めようと思っていますが、誰か効率よく集める方法がご存知でしょうか?是非教えてください。 宜しくお願いいたします。

基本的な御回答

 自分もプロジェクト選択に関する論文をGoogleで検索して、幾つか査読してみたのですが、新しい研究らしく、あまりたくさんの論文は出てきませんでした。

とりあえず、2本程度、論文を読んでみて、論点を整理したいと考えています。

プロジェクト選択とは

 プロジェクト選択とは、「システム開発プロジェクトにどの程度の資源(resource)を、どの期間投資するのかという選択的意思決定を行うこと 」と定義できそうです。

プロジェクト選択の必要性

 組織の保有するリソースは有限であるため、その有限なリソースを効率的に活用し、システム開発を成功に導くためには、 どのプロジェクトにリソースを投入すべきか、あるいは投入しないのかについて選択的意思決定が必要になる。その意思決定を最適化する必要がある。

プロジェクト選択の意思決定段階について

   システム開発の案件・企画段階から、開発中途(システムの要件定義段階など)のスクリーニングを経て、最終的な意思決定(例えば、開発プロジェクトの中止、廃棄など)にいたる 選択的意思決定の連鎖プロセスをプロジェクト選択と言い換えることも出来そうだ。

プロジェクト選択の手続き

 システム開発プロジェクトはステージとゲートを持つ。各ステージにおいて、プロジェクトをゲートで評価して意思決定を行う。 ここでステージとは、システム開発フェーズのなかを幾つかに分解したものをさしていて、ゲートとは意思決定のポイントをさす。

 意思決定のパターンは次のとおりである。
  • プロジェクトの継続(Go)
  • 一時停止(hold)
  • 差し戻し(Recycle)
  • 打ち切り(Kill)

 実務的にも、プロジェクトの一時停止や差し戻し及び打ち切りは良くある話である。

用語

 プロジェクト選択を理解するうえで重要な用語がある。その幾つかを示す。

  • スクリーニング:評価の結果プロジェクトの優劣を選別すること
  • コンカレントエンジニアリング(Concurrent Engineering):システム開発の並行化する手法のこと
  • 組織能力:システム開発プロジェクトの競争優位性を現実化するための知識・経験の蓄積・集積のこと

 プロジェクト選択の究極の目的は、組織利益の最適化にあります。よって、企業利益の最大化を図るための評価指標を用意して、動的な局面ごとの最適回を導き出さないといけない。

プロジェクト選択で考慮すべきこと

 プロジェクト選択で考慮すべきことがある。その幾つかを示す。

  • プロジェクトを取り巻く組織内の環境、プロジェクト自身の環境、組織外の環境を考慮すること
  • プロジェクト選択に関する意思決定要因は動的に変化していることを認識すべきこと
  • 意思決定に当たっては組織能力を十分発揮して、速やかな意思決定を実施すること
参考文献

 以下の論文を参考にしました。

  • 「研究開発プロジェクトの評価と選択における組織能力」辻本将晴,イノベーション・マネジメント2
  • 「開発プロジェクトの環境影響の評価のための実施要領」経済協力開発機構

※(c)(有)アイ・リンク・コンサルタント 加藤忠宏




投稿者 kato : 23:40

2005年9月 7日

プロジェクトマネージャ試験小論文レッスン-2(マル秘密、必勝

PM午後II小論文論述のポイント

プロジェクトマネージャ試験は管理技術の試験

 プロジェクトマネージャ試験「管理技術の試験」といえるでしょう。幾つか事例を挙げて ご説明します。

H11年問3 設計書レビュー

このような問題が出題されたときは次のように解答するとよいでしょう。

概要設計段階で、「概要設計書」について 「要件定義書」への準拠性を確認した。 「品質計画書」の品質に準拠しているかを確認した。 そのために、事前に「チェックリスト」を作成した。

 ここで、論述のポイントは以下の通りである。

  • 1.開発段階のどの段階なのかを明確にする
  • 2.対比して検証する文書名を明らかにする
  • 3.検証するときは準拠性を検討する
  • 4.チェックリストを作成し、検証漏れを排除する
H13年問1 協力会社管理

このような問題が出題されたときは次のように解答するとよいでしょう。

例えば「協力会社と委託契約を結んだ」と解答するのは平凡すぎる気が する。そこで、「協力会社との委託契約にあたり、①業務範囲を概要設計から総合テストまで、②開発基盤は当社提供 、③品質計画書は当社に準拠という方針で合意した。」と書くと合格がぐっと 近くなる。

PMの採点者に「ああ、俺もこれでやられた」と思わせたら合格

 採点者が、実務体験を思い出すような論文が書ければ、読み手の共感 を読んで合格させられる。

H13年問1 協力会社の選定について

協力会社の書面上の実績で選択した結果、思わぬ、トラブルに巻き込まれるのではないか、そういうリスク回避策 を提案するとよい。想定する事例として<次のようなケースが 考えられる。/p>

  • 1.親会社が指名した協力会社を使って実力不足
  • 2.実績だけで選んで、会社がPJの途中で倒産
  • 3.技術力は高いけれど、営業の伝達力に問題がある
プロジェクト管理者のリスク回避の手法(設問イ)

例)RFPを提出させた、先端地視察をした。・・・これだけだと弱い。それは 問題文にそうかいてあるからであり、問題文に書いてないことも書いてポイントを稼ぐ

RFPを提出させて、わざと疑問を営業に投げかけて以下のことを確認する その質問内容と意図は次のとおりである。
  • 1.迅速に目的の意図する回答が得られるか:営業とSEのコミュニケーションがよいか
  • 2.技術的に妥当と思われる解決策を代替案を含めて提示してくれるか:提案力があるか
  • 3.品質、工程管理など多岐に及ぶ配慮があるか:開発上の課題をよく心得ているか
  • 4.丁寧な書面における回答が得られるか:柔軟な対応力があるか
評価のガイドラインを示すときは箇条書き的に

 評価のためのガイドラインは網羅的に 書くと良い。「平成13年問3 品質管理(総合テスト)」を例にして考えよう。

  • 1.24時間無停止が実現できたか
  • 2.考えうる、最大のトラフィックを与えて、最低保証の性能を維持できた
  • 3.ブラックボックステストを実施して機能の十分さを確認できたか
  • 4.稼動時の故障を想定して、HDDディスク交換が無停止で実現できたか。
設問イで具体例を示して論述する ただし、泥縄にならないこと
  • 1.あくまで「想定範囲内である」という態度を貫く
  • 2.泥縄に書くと採点者に「混乱したプロジェクト」というニュアンスが 伝わってしまう。

そこで「A君に顧客からの仕様変更の要望が多数上がってきて、予想の見積りをオーバーすることになりそうな情勢だった。 ○ (監視の仕組みと検証のための行動) 私は工程の進捗と規模見積りの適正さを確保するために、2つのポイントを週次単位で監視することにした。 そのポイントは①スコープ委員会での議論、 ②サブマネージャへの顧客の直接の変更依頼」と論述を進めてゆくとよいでしょう。

PM試験小論文「取りやすく、書きやすく、事前に準備しやすく合格しやすい論文テーマ」

合格しやすい論文のテーマ選びの基準を示します。

  • 1.PMBOKにしたがって、淡々と書ける
  • 2.請負・協力会社管理
  • 3.規模見積り
(c)(有)アイ・リンク・コンサルタント 加藤忠宏



投稿者 suzuki : 09:33

2005年9月 6日

PM平成14年午後II問3の解答例の解説

PM平成14年午後II問3 小論文解答例

問3 問題発生プロジェクトへの新たな参入について

 問題文の前段を読んで以下のポイントをチェックする必要がある。

論文を作成する前の重要事項
1.1 プロジェクトの概要

成果物の機能不備、品質不良というテーマで論述すべき。

問題の早期解決→究極の命題

成果物の品質の問題

要員のモチベーション

顧客の信頼回復

問題の原因究明の具体策
問題解決の手順について
  • 1.情報システムの特性をよく理解する(状況の把握)
  • 2.プロジェクト管理上の問題を調査する
  • 3.項目の検証
  • 4.原因究明する
  • 5.対策の検討の実施
想定するプロジェクト事例

 上記の出題意図を満たすために、プロジェクト事例事前に設定してから 論述に取り掛かることにします。

24時間無停止のデータベースシステム上の業務アプリケーション開発
当社(開発側、PM側)
  • 1.24時間無停止のDBMS技術を保有する企業
  • 2.その技術を元にして、APの開発を受託
顧客側
  • 1.ネットワーク機器とサーバを用意
  • 2.機能要件を定義して、そのうえでDBMSとAPとのインターフェースを開発する
事故事例
  • 1.開発の結合テスト段階で、DBMSを利用したAPが機能せず
  • 2.顧客のクレームが多発している状態
いままでのPMの管理上の問題点
  • 1.テストで不具合が発生すると、対処的に問題を解決していた
  • 2.しかし、結合テストが進捗すると事態が深刻化した
  • 3.要員を順次投入して火に油を注いだ
原因究明の結果判明したこと
  • 1.DBMSには問題がない
  • 2.顧客が開発したインターフェースに問題があった
  • 3.APに若干の軽度なバグがあった
  • 4.これが総合して深刻な事態を発生させていた
(c)(有)アイ・リンク・コンサルタント 加藤忠宏



投稿者 suzuki : 09:32

2005年9月 5日

2005年9月5日 PM午後II平成14年問3の解答例

PM平成14年午後II問3 小論文解答例

問3 問題発生プロジェクトへの新たな参入について
1 プロジェクトの概要と機能不備の状況
1.1 プロジェクトの概要

私が関与した情報システム開発プロジェクトは、電子通信業の業務システムアプリケーション開発である。この業務システムは約30個のデータベースを中心として業務手続を構成している。

当社は24時間無停止のDBMSを商品として提供するITベンダーである。今回の開発は実績のあるこのDBMSの上で稼動する業務アプリケーションソフト(以下APという)を開発するプロジェクトである。

今回の開発組織は、当社がDBMSの導入とAP開発を行う。また、顧客は自社のネットワーク基盤の整備とインターフェース部分の開発を分担する。私が赴任する前の当社プロジェクト組織は、管理者1名とデータベース設計者3名及びアプリケーション開発プログラマ8名によって構成されていた。

1.2 成果物の不備の状況
1.2.1 不具合の発見

AP及びインターフェースの単体テストが完了し、それぞれの結合テストの段階になったとき、APからDBへ問い合わせをしても応答時間が異常に長くなったり、処理を中断してしまうなどの不具合が連続的に発生した。

1.2.2 前任者の対処と赴任直前の状況

 私の前任者である工程管理者は、顧客のクレームに迅速に対応するために、原因究明を行わず、APに問題があると判断しパッチをはめるなどの対処的問題解決を行った。

 この結果、顧客は当社の対応に不信感をもつようになった、また、AP開発要員を順次投入したため、新規要員の教育上の問題やドキュメント不備の問題が発生した。

2 問題点の調査と対策の実施
2.1 問題点の調査
2.1.1 問題解決組織の確立

 問題のあるAP及びシステムの特性は、安定したDBMS基盤上に存在する点にある。すなわち、DBMSとAPとの間に立つインターフェースの品質がシステムそのものに与える影響は大きいと考えた。

 そこで、APとインターフェースの連携の重要性を顧客に認識してもらい、この問題を解決するための問題解決委員会の共同開催を提案し受け入れられた。

2.1.2 原因究明

 抜本的な原因究明を実施するために再度DBMSの仕様を当社と顧客企業に公開した。そのうえで、チェックリストを作成し、DBMS仕様書とインターフェース及び各APの準拠性を机上でウォークスルー方式を使い相互検証を進めていった。

2.2 原因究明結果とその是正
2.2.1 原因究明結果

 DBMS仕様書とインターフェース設計書及びAP概要設計書との相互の比較を行うことによって次のことが判明した。

  • 1.インターフェース設計段階で、ユーザがDBMS仕様を読み違えている点があり、機能的不備と欠落が存在することが発見された
  • 2.AP側に軽度のバグは2箇所存在することが分かった。
  • 3.ソフトウェア全体の不具合の原因は、これらが相互作用して影響を与えていることが判明した。
2.2.2 是正対策

(1)品質管理体制  顧客と当社側の品質管理担当者が、週1度、話し合いの場を持ち、品質に影響を与える問題について話し合うと共に、DBMS仕様に関する情報提供や開発上の留意点について当社側から情報提供を行える仕組みをつくった。

(2)不具合の是正について  当社の不具合については、1週間以内に修正、テストする計画をサブリーダに提出させ実行させた。  顧客側の不具合については、当社クレーム対策用を顧客企業の了解を得て派遣し、顧客側の修正作業を応援し、作業を加速させた。

(3)顧客との信頼関係回復について  顧客との信頼関係回復のため、私は、今後の作業計画とスケジュール計画の見直し結果を作成し提出・説明した。また、今回の原因分析報告書を作成し、なぜ、今回のような問題が発生したのかについて顧客に説明し理解を得た。

2.2.3 予防対策

 今回のようなケースは二度とあってはならない。このため、次のような予防対策を実施し、チーム内に周知徹底させた。

  • 1.顧客に当社商品を提供する場合は、必ずDBMS仕様書に基づいて、説明し、顧客が誤らないように教育を実施してから開発を行う
  • 2.情報システム開発にPDS(Plan Do See)のライフサイクルを作り、ドキュメント管理を徹底させつつ、製品の作りこみを行う
  • 3.顧客クレーム体制の確立:ISO9000の要求事項を満たすように、顧客クレームに対するマニュアルを整備し、手順と方法を徹底させた。また、顧客からの重度と判断されるクレームが発生した場合、速やかにプロジェクトマネージャは報告を上司にするような体制を確立した。
3 評価と改善
3.1 評価
3.1.1 手続きの妥当性

 私はISO9000に基づく社内規定に基づいてクレーム対処を実施した。この結果は社内監査でも妥当と認められている。

3.1.2 顧客満足

 前任者は2週間にわたって顧客クレームに対処した。この後を受けて、私は1週間以内に問題点を発見し、即座に顧客と相談しつつ対処施策を提案したため、赴任10日目にすでに問題解決の目鼻はついた。また、是正対策によるプログラム修正は14日かかった。しかし、DBMSに準拠したシステムが構築できたため、最終カットオーバには間に合わせることが出来た。

3.2 改善

 今回は、前任者が、社内のクレーム対処マニュアルを無視して勝手に行動した結果発生した事件である。このようなことが二度とないように、 プロジェクト管理者は、社内品質マニュアルや手続きをよく理解して周知徹底することが顧客満足につながると考えている。

以上

(c)(有)アイ・リンク・コンサルタント 加藤忠宏



投稿者 kato : 00:08

2005年8月29日

2005年8月29日 広がる、中国へのオフショア開発

広がるオフショア開発

 日立製作所、富士通、NECなどでミドルウェアやOS等のソフト開発に関する 海外委託(オフショア開発)が進展している。2005年度の見通し として、昨年度と比較して委託件数や金額は1.5倍~2倍弱程度に拡大する見込みだ。 委託先としては中国が多い。

中国の委託が多いわけ

わが国のソフト・オフショア開発が多い理由として 次のような理由が挙げられる。

  • 米国は英語の話せるインドへの委託が多い。それと対比して日本 はソフト・オフショア開発先として中国が多くなる
  • 中国技術者1人あたりの費用は日本の半額である
  • 開発を取りまとめる担当者が日中を往復する費用が低減できる
  • 中国に発注を集中させることによって、業種別の開発ノウハウを蓄積できる
  • この結果、中国の発注先の専門性も増し、特定の業種別に集中発注できる

 この結果、日本国内での開発にくらべソフト・オフショア開発 ではコストは30%~40%削減できる

全体的オフショア発注動向

日立、富士通、NECの発注動向は次のとおりだ。

  • --------------------------------------
  •  年度 |  日立  |富士通 | NEC
  • --------------------------------------
  • 2004年度| 1,100人  |1,000人 | 150億円
  • 2005年度| 2,000人  |1,500人 | 170億円
  • --------------------------------------
  • ※出所:日経2005/8/22

 人民元の切上げも人件費割安感を生む原因となっているらしい。

システムアナリスト 加藤忠宏の見解
ユーザとしての見解

 ユーザとして、委託したソフトウェアの品質に問題が無い限り、安価な方向は 大変歓迎である。特に、ユーザサイドからみて。「なぜ、こんな不自由なシステム がこんなに効果なのか」という不満もある。そのような問題の解消策として ソフト・オフショア開発は有効であろう。また、プロジェクトマネージャ としても赤字プロジェクト回避策として有難いだろう。

SE教育者としての見解

 しかし、歓迎ばかりしてはいられない。最近、国家試験のソフトウェア開発技術者 の育成教育を行っていて思うことは、「ソフト開発技術者の論理構成能力が 低下している」という点である。特に、それはアルゴリズムの読解をさせて みるとよくわかる。SQL文は読めるが汎用的アルゴリズムが読めない技術者が多発している。 この問題の放置は「わが国ソフト開発産業の自爆」に繋がりそうな 気がしている。

PM論文作成者としての見解

 また、プロジェクトマネージャ試験の小論文作成指導者としての立場をいうと、 日本のSEでさえ、要件定義を理解させるだけで相当の苦労なのに、言葉の違う人への 指導は世話の焼ける話だ。また、相手は文化が異なる人達。そのような人達への 意思伝達の手段として、両方の言語を理解している現地の仲介者の存在も不可欠 であろうと思われる。

以上

日本経済新聞 2005年8月22日「ソフト開発 中国委託拡大」
(c)アイ・リンク・コンサルタント 加藤忠宏



投稿者 kato : 13:54

2005年8月15日

PM平成15年午後II 問1・解答例

PM平成15年午後II問1 小論文

1 プロジェクトの概要とチームの役割
1.1 プロジェクトの概要

 私が参画したプロジェクトは製造業A社の受注管理システムである。 本システムは受注から、技術検討、見積り、 生産計画出力までを開発範囲としている。 同システムは主としてデータベースと帳票画面を主体としたシステムである。 このため、システム開発に当たってはDOA法を採用していた。

 プロジェクト組織は、プロジェクト管理者としての私とデータベース 開発チーム3名、アプリケーション開発チーム4名、 ネットワークチームの2名によって構成されている。 当初、上司から打診があったとき、私は「開発チームの主力メンバーが集まらない こと」と「A社が一度システム開発後の運用に失敗していること」 を理由に辞退した。しかし、上司からA社との長年の取引を理由に説得され、 開発組織に参画することになった。

1.2 チームリーダを採用したチームの役割

私がチームリーダを外部から採用したチームは、 データベース開発チームである。 このチームは、業務分析結果であるDFDや帳票、 画面を受けてデータベースの概要設計を行いE-R図を作成後、 データベースの論理設計、正規化・実装、 SQL文の作成を行うことを責務としている。

1.3 社外リーダの採用を検討した理由

 データベースチームは、業務繁忙ゆえ、適切なリーダが他プロジェクト に投入され不在だった。また、開発メンバーは国家資格の有資格者を含めて 優秀なメンバーが投入されていたが若いメンバーが多く、 業務分析に関する知識を備えていなかった。また、 データベースサーバは開発の中核であり、他のリーダなどとの折衝を行う 必要性もあることから、コミュニケーション能力を 備えたリーダの存在が必要だった。

2 社外からのチームリーダの採用について
2.1 社内の協力会社管理体制について

 弊社では協力会社への仕事の依頼を行うための手続きとしてISO9000に準拠する「購買管理規定」が存在している。このため、本件の採用に当たってもこの購買管理規定にのっとって採用手続きを計画した。

2.2 書類選考

<弊社に協力会社として、格付け、登録されている企業及び個人 中から次の条件に該当する人物をリーダ候補として3名リストアップした。
 1.DOA開発にチームリーダとして参画した実績があること
 2.当社での開発プロジェクトに参画した経験があり、 当社の開発標準や仕事の進め方に理解がある人。
 3.若手の指導・教育経験及びスキルのありそうな人物であること。 OJTの指導スキルを持つ人。
 4.製造業の業務プロセスについて理解がある人

2.3 書類の提出と面接の実施
2.3.1 書類の提出

 私は、上司の許可を得て、当該候補3名に打診を行うと共に、業務経歴書の提出を求めた。そのうえで、その人物ごとに質問の項目を決めて、リストアップしておいた。

2.3.2 面接の実施

 チームリーダ候補者3名を個々に面接した。事前にリストアップした面接項目及び質問事項を発意した。特に、①製造業に関する業務知識がどれだけの深さあるか。②会話や説明能力に説得力があるか。③コミュニケーションが苦手な人物に対しても粘り強くわかりやすい話が出来るかなどを中心として面接を実施した。④当社の開発プロジェクトに参画したときの経験を元に開発標準や開発基盤への理解を検証した。⑤また、メンバーの力量を想定した発意を行い、適切なOJT指導プランが回答されるかどうか聞いてみた。  なお、面接は私、上司及び技術専門官の3名でジャッジすることになった。

2.4 上司との協議、他者の助言

 面接の結果を5段階評価で採点して面接に立ち会った3者の意見を総合評定した。また、それぞれの候補者と一緒に仕事をしたことのある、弊社内のメンバーの意見も参考にした。

 以上の結果から、候補者3人の中からX氏を採用した。X氏は以前、弊社で仕事をしたことのある人物で弊社の文書化のルールや開発標準に熟知していた。また仕事の進め方も良く理解している人物である。さらに、若手のOJT指導能力にも定評のある人物であり、現在は独立して独自のソフトウェア開発企業の経営者兼SEをしている人物である。

 人物的にも積極的に他とコミュニケーションが取れ、かつ顧客にも意見の言える人という評価である。

3 評価と改善
3.1 評価
3.1.1 協力会社管理の手続きの妥当性

 私は当社の「購買管理規定」にしたがって、リーダの選定、依頼手続きを行った。この手続きは社内の品質管理委員会による内部監査を受けており、妥当の評価を得ている。

3.1.2  リーダの活動内容の評価

 今回、X氏にお願いすることによって、A社プロジェクトの基幹部分は品質、納期とも顧客から高い評価を受けてノークレームであると共に、社内的にも他のアプリケーションとの連携も十分であった。

 X氏は若手教育もうまく、若手が作成したドキュメントを基にして、ディスカッション形式で若手の設計したドキュメントの問題点や改善点を指摘しながら文書品質を高めてゆく手法をとった。また、技術上の問題点についても他セクションと協議しつつ問題解決した。

3.2 改善点

 今回はX氏にお願いすることによって、プロジェクトが円滑に推移した。しかし、毎回、X氏のように適切な人物の調達が行われるとは限らない。このため、組織的にプロジェクトリーダ教育の体系的な教育体制の確立が必要と考える。また、協力会社の人物に、弊社標準で円滑に仕事をしてもらう仕組みも必要だと考えた。

(c)アイ・リンク・コンサルタント 加藤忠宏



投稿者 kato : 00:14

2005年8月 4日

2005年8月4日 ご質問に対する回答

プロジェクトの増員に関するご質問

暑いですね。今日も長野におります

DSCN2860.jpg

以前、増員に関するご質問がありましたが、以前、このブログに回答したとおりですから 恐縮ですが、もう一度、内容を良くお読みください




投稿者 kato : 09:35

2005年7月13日

2005年7月12日 平成9年PM試験午後I 問1のご質問への回答

プロジェクトマネージャ試験平成9年午後I問1について

著書の読者の方から以下のようなご質問をいただきました

論述の達人を購入し、毎日コツコツと勉強に励んでいます。 表題の件ですが、解答の内容にしっくりこない点があり質問を致しました。

設問では「C社に対して理解を求め・・・」とあります。この点を考慮すると、 影響要因のC1、C2は自社内の問題であり、 この設問の回答としては当てはまらないような気がします。 私は、段階契約を結ぶことで開発規模を確定でき、 結果として工数を削減できるといった回答を考えました。 加藤先生のご意見をお聞かせ下さい。

加藤の考え

まず、論点を確認しましょう。ご質問の内容は設問3「B氏が次の工数削減を実現するために 、C社に対して理解を求め、調整すべき内容を図1に対応して答えよ」とある点ですね。

次に状況を整理しましょう。表1.影響要因と変動率をご覧ください。

ここでプロジェクトのリスク要因となっているのは、C1,C2,C3です。 C4,C5,C6は高生産性要因となっていて工数削減要因からはずれると思われます。

さらに、設問2以降ででのリスク要因C1,C2,C3のの改善・対処が必要となります。もともと生産性の高い C4,C5,C6はそれほど緊急的な対処は必要ないと思われます。

解答を導く

議論の前提条件を確認します。問題文中に、以下のような式が乗っています

総開発工数=(基本開発工数)×(総変動率)

設問3(1)では、図1のB1→B2方向への改善を行います。これは、図から明らかなように 開発工数(この場合は人月)を減らす方向で考えます。つまり、生産性の高い要員を投入 できれば上記式の右辺の右側(総変動率)を減らせます。

同様に、設問3(2)では、図1のB2→A1方向への改善です。これは開発規模全体の工数削減が 必要になるため、仕様が確定している部分の開発に限定する必要があると思われます。

いずれにしても、内部要因とはいえ高いコストの要員を、顧客納期に間に合わせるために使うのですから 顧客Cとの調整が必要になります。

段階的開発と工数削減というご意見について

おそらく、設問文の内容が「B氏は事前にどうすべきであったか」という問題でしたら ご指摘の解答で正解でしょう。

しかし、この問題では、既に要件定義が終了している段階であり、契約も一括請負ですから 現実の納期とコストの問題解決が優先事項となります。

読者の方がおおしゃっているのは契約段階での話ですから、開発に入った本問 では当てはまらないかなと思うのです。

良い、ご質問有難うございます
Copy Right(有)アイ・リンク・コンサルタント 加藤忠宏



投稿者 kato : 00:02

2005年7月 2日

2005年7月2日 小論文作成例-1(PM H16-3)

PM 平成16年午後II問3解答例「請負契約における品質確認」

1 プロジェクトの概要と機密情報
1.1 プロジェクトの概要

 私が関与した情報システム開発プロジェクトはイントラネットべースでのグループウェア開発プロジェクトである。本システムはWWWサーバをインフラとして、動的にWebページを生成して、グループコミュニケーションを促進する。依頼主であるA社は、コンサルタント会社であり、独自の業務ノウハウを実装したグループウェアを1年以内に同システムを開発し、ネット上で販売するビジネスモデルを構築している。  本プロジェクトのメンバーは管理者としての私、Webサーバ開発チーム、グループウェア開発チーム(データベース開発を含む)及びマンマシンインターフェース開発チームの3チームの合計10人の組織である。本プロジェクトメンバーのうち、グループウェア開発チームは、協力会社であるB社メンバーで全員が構成される。 なお、開発工程のうち、業務分析、要件定義、プロジェクト開発計画はすべて弊社が担当する。

1 .2発注した工程の範囲

 B社に発注した工程の範囲は、グループウェアの基幹部分の開発であり、その業務アプリケーションのうち以下のような工程範囲である。 (1)概要設計:データベース設計を含めて、基幹部分開発に関連する入出力設計などを作成する。 (2)詳細設計:データベースの物理設計、正規化などを行う。 (3)プログラム設計:アプリケーションソフトウェアを設計・開発する (4)テスト工程:単体テスト、弊社が開発したインフラとの結合テスト、総合テストまでの範囲のテスト計画書の作成から実際のテストを実施する。  弊社とB社との関係は請負契約であった。

2 請負契約における品質確認
2.1 品質目標の設定
2.1.1 システム特性

 本システム開発は、WWWサーバベースの開発であること。また、弊社の得意なデータベース技術を利用できることなどから、バグの多さなどの品質よりも、むしろ依頼主であるA社の業務要件を満たすことのできるかどうかが品質管理が主目的となる。

2.1.2 品質計画

 そこで、私は品質計画書で次のような、品質目標を立案した。①A社の業務ノウハウをすべてグループウェア機能として実装すること、②A社の要求する基本機能はすべて実現すること、③要件品質の確認方法としてスパイラルアプローチを採用すること、④A社とのスパイラルによる品質確認は2回を限度とすることとした。また、これらの要件品質の向上には協力会社の協力も必須と考えた。そこで、B社との契約作業の期間中に設計書レビューを含めた打ち合わせが必須と考えた。

2.2 品質の確認事項
2.2.1 確認事項の詳細

 要件品質の確認事項については、B社リーダC氏と以下の点で合意した。 (1)確認時期:概要設計書作成終了後と詳細設計書終了後の2回、また、上記の品質確認状況に応じて追加確認時期を設定できるとした。 (2)中間成果物:概要設計段階で提出をうける成果物は、DFD,E-R図、機能要件階層図等の文書と画面・帳票プロトタイプである。また、詳細設計段階の提出成果物は物理データベース構造やDDL関連等の文書である。 (3)確認方法:中間成果物の確認方法は以下のとおり。 ①文書レビュー:ユーザA社を含めた設計書レビューを実施する。 ②プロトタイプ:ユーザA社の業務担当者の操作確認を得てプロトタイプレビューを実施する。

2.2.2 私の実施した品質確認上の工夫

 今回のプロジェクトの品質確認上重要なポイントは、①A社要件を網羅的に実現する、②業務特有な複雑な処理系について正確に定義する点にある。そのために私は次の点に留意しつつ、品質確認作業を進めていった。 (1)可視化技法の適用による理解の正確性確保  画面や帳票と業務プロセスとの関連性を状態遷移図やDFD等を使って明示することにより、A社、B社相互の要件定義に対する設計の準拠性、関連性を確認することができる。 (2)チェックリスト利用  A社要件を階層的チェックリスト化し、業務要件のもれ、例外事項のもれがないように配慮する必要がある。 (3)上位ドキュメントへの準拠と活用  業務要件のチェックリスト作成にあたっては、要件定義書、ユーザとの打ち合わせドキュメントを活用した。 (4)用語の標準化の徹底と合意の形成  例えば、「手順」「作業」などのように一般名詞化された用語の意味を取り違え、ユーザの意図しないシステムを構築してしまうことが良くある。このため、要件定義書の段階であらかじめ用語を定義するようにした。さらに、A,B,弊社の3者レビューで顕在化した疑問点は解決し、合意する必要がある。

3 評価と改善
3.1 評価
3.1.1 品質目標の達成

 当初、A社が弊社と打ち合わせ時に計画していた機能はすべて網羅的にグループウェアの中に盛り込まれた。  また、プロトタイプ実施によって、①潜在的にニーズも吸収できた。②さらに、操作性、画面遷移の適合性の検証も行うことができた。

3.1.2 請負先B社のコントロール

契約前に設計レビューを合意事項として盛り込むことができたので、協力会社統制が円滑に行うことができた。

3.2 改善
3.2.1 ユーザ錯誤による誤った業務定義

 3者レビュー時に、弊社作成のDFDに誤りがあることがA,B社相互から指摘がなされた。これは、DFD定義を行う際に、A社が例外業務を定義し忘れたことが原因だった。   ユーザ定義が誤っていても、複雑な業務系列の場合、弊社では正誤の判断がつかない。このような課題の解決方法として、ユーザ定義再確認プロセスが必要だろう。

3.2.2 さらなる品質向上のために

 協力会社依頼手続きのさらなる改善のため、協力会社と契約書にシステム監査権限を組み込むことも有効だと思われる。さらに、協力会社の再評価・再格付けの手続きも有効である。




投稿者 kato : 23:55

2005年6月30日

2005年6月30日 要員管理の課題について

情報システムの開発とモチベーション管理

3K脱出が難しい情報システム開発

一般に情報システム開発は3K職場と言われている。特に下請けになればなるほど、 大手の皺寄せを受けやすく、納期にや品質管理に気を使い過重労働と なりがちである。

この背景として、IT業界が建設業と業界構造が類似している点と無関係ではないだろう。 ゼネコンに相当する企業があって、その下請けが多重構造のように存在する。 それがIT業界の構造ではないか?しかし、まだ建設業界のほうがマシなような 気がする。なぜなら、IT業界は建設業に比べて人的能力に負う要因が極めて大きい からである。

組織単位で評価されるわが国プロジェクト

わが国の文化として、「仕事は組織で行うもの」という概念が選考している。 このため、個人で成果を挙げてもほとんど評価されない、逆に失敗しても 責任を問われないこともある。これが、優秀な社員のモチベーションの 低下や、組織内のモラルハザードの問題につながっているように思われる。

また、最近の若者の場合、大企業で出世するよりも新しいビジネスに挑戦し、 成功して尊敬されたいという欲求のほうが強いといわれている。これは わが国経済の成熟化と無関係ではないだろう。日本で生活する限り、まっとうに 生きている限り、生活に困ることは殆どない。

有名IT企業が失敗したように、成果報酬型が失敗した背景もここにある ように思われる。すなわち、成果報酬制度の背景には「成果主義の導入が社員 の意欲向上につながる」という経済人仮説があるからである。

PMとしての要員管理

以前、プロジェクトを管理していて、リーダを決め、組織を配置 していたにも関わらず一向に機能しなかったケースがある。無論、組織内の 能力構成や人間関係にも配慮したし、作業負荷もそれなりに配慮した にもかかわらずである

では、なぜ、このプロジェクトは機能しなかったのか。おそらく、その 原因として「複雑な雇用形態」があったように思われる。当時、当社では スタッフの勤務しやすさを考慮して、様々な雇用形態の人々がいた。 しかし、この雇用形態がプロジェクトのモチベーション低下につながったと 思われる。

具体的には、「私とあの人は大して能力が違わないのになぜ給与や勤務体系が異なるのか」 のように、自分で雇用形態を選択しているのにもかかわらず不平不満が根底にあり メンバどうしの相互理解や協調を阻害していたように思われる。

この問題は、著者が主張先から急遽帰社して、プロジェクトリーダを解任するなど直接介入して 緊急対処を行い事なきを得た。しかし、このような問題の背景として人間の嫉妬や自分だけが 仕事を押し付けられたくないなどの思惑があり根本的な解決は難しい。

参考:日本経済新聞2005年6月27日「従業員の意欲向上策」太田肇



投稿者 admin : 12:25

2005年6月26日

2005年6月25日 プロジェクトマネージャ試験の小論文は簡単だ

プロジェクトマネージャ試験小論文レッスン-1

設問ア前半部を書こう
設問アの内容は大概決まっている

プロジェクトマネージャ試験小論文の設問アは大概決まっている。具体的には 「あなたが携わったプロジェクトの概要」である。だから、次の内容をおおよそ 次の内容を盛り込んでゆくと良い。

  • 基本的な内容:開発する情報システム(業種、システム)
  • テーマが規模見積の場合など:システム開発技法(例:オブジェクト指向)
  • テーマが要員認識の場合など:メンバ構成、組織体制
  • テーマが進捗管理の場合など:進捗管理上危惧される要素
  • その他:納期、顧客の状況など

設問アの前半部の字数は400字である。書きすぎて600字を超えないようにしたい。

設問ア前半部の留意事項

設問ア前半部は、設問イを書くための要素を埋め込んでおくべき箇所である。例えば 開発規模見積りリスク低減が小論文のテーマであるならば、開発規模見積に及ぼすリスク 要因をプロジェクト概要のなかに埋め込んでおくのである。これが上記のうちの「顧客 の状況」である。


簡潔に小論文の設問ア前半部を書いてみた

私が関与した情報システム開発プロジェクトは、IT企業A社のWeb系ポータルサイト
システムである。A社はWWWサーバを自社ドメインで立上げ、利用者に検索機能を中心
にして多目的な利便性を提供することにより広告収入の増加を計画していた。


本システムは、ルータ、WWWサーバ、データベースサーバによって構成されている。
WWWサーバのアプリケーション開発は共通的なミドルウェアに加えて特別な機能を
オブジェクト指向開発を行う。


開発組織は、プロジェクト管理者である私を加えて10人である。その構成は
データベースエンジンニア、プログラマ、ネットワーク設計者で構成される。
このプロジェクトの課題は、A社ポータルサイト機能で詳細部分が未決定である
点である。このため、開発が進むにつれてA社から、追加開発要件が提起される
ことが予想された。


(c)copyright アイ・リンク・コンサルタント




投稿者 kato : 11:38

2005年6月24日

2005年6月23日 プロジェクトマネージャ短期合格法

100日で合格するプロジェクトマネージャ試験

合格率は7%程度なんだけれど、PM試験は難易度からいって難しい試験ではない。 合格できないということは、受験者の勉強不足か、あるいは、ものの考え方の どこかに欠陥がるのだ。

午前マークシートの勉強の仕方
ソフト開発の力でうかるPM試験

過去の講師経験によると、午前突破の確率は、受験者がSWないしFE試験(旧1種、旧2種) を持っているか否かで大きく異なる。当然SW試験合格者は高くなる。逆にまったくもっていない 受験者は苦しい。

IRT試験に気をつけろ!間違いない。

ご存知のとおり、IRT試験ではすべての問題に均等に配点をおかない。ここで特に注意が 必要な分野が「システム開発と運用」のような主要分野、「コンピュータと経営」のように 得意不得意がはっきりする分野は要注意だ。この分野で失点すると午前足きりにかかる可能性 が高くなる。特に知的財産権、経営分析、法規のところの失点を抑えたい

ベタの正答率で75%を目指せ

ベタな採点で正答率が75%程度なら、たとえIRT試験でも安心だ。著者は常に午前を80%近く 取る自信があるため、午前を心配する必要がない。午前55問中41問程度正答することを目標にしたい。

午後I記述式試験を突破する
SPEEDよりも正確さ

一般に、SEのかたは几帳面な方がいらっしゃるが、試験と実務は割り切って考えた方が良い。 具体的には、午後I試験では解答の正確さは多少犠牲にしても、スピードを重視して90分間で 3問を完答することを優先すべきである。

題意の把握に努めよ

解答のためのネタ探しの問題レビュー、解答作成の際に気をつけたい点が「題意」だ。 具体的に「理由」を聞いているのか、「~すべきだった」のか「問題点はどこか」と聞いて いるのかに注意したい。題意をはずして作成した設問の解答は0点になる可能性がある

契約関係に気をつけよう

午後I問題では、依頼主とのトラブル、協力会社とのトラブルなどが良く出題される。 このような問題を解決する手段として民法の契約に関連する知識や知的財産権の知識が 問われる。派遣と請負の違い、不正競争防止法とはなにかなどについての知識を整理 しておこう!極論すると、著者は1種の知識と法律の知識に加えてPMBOK(Project Management Body of Knowledge)の知識で合格したようなものである。

6月から始める午後II

SW試験、AE試験などをパスしている人は、実は午後II試験から勉強を始めた方が効率が良い。 理由は、午後IIの論述能力養成に最も時間がかかるからだ。簡単な学習計画を次に示す。

  • 6月:平成16年の午前、午後I、午後IIを一通り解いて、全体の試験の仕組みを理解する。
  • 7月:CD教材を使い、論述の基礎的部分を理解する。自分のプロジェクト経験を800字で論述する
  • 8月前半:PMBOKを精読する、用語を整理する
  • 8月後半:CD教材を使い、論述の応用部分を理解し、論文を1本仕上げてみる、添削を提出する
  • 9月:午後Iを過去3年分12問を解く
  • 10月:午後II小論文の2本目を仕上げてみる、添削を提出する。自分の論述の課題を是正する

小論文ではけして難しいことは聞かれない。重要なことは以下のことである。

  • 小論文の題意をよく理解する。読解力をつける
  • 小論文の設問ア「あなたのプロジェクト」を400字で書く準備をしておく(これは全ての 問題に出題される)
  • 小論文で得意な分野を3分野ほど作っておく。著者の場合は「規模見積り」「協力会社管理」 「進捗管理」であった。頻出分野6~7分野のうち3本に的を絞れば、当日、ヤマをはずされても慌てない
  • 各分野で使われるPMBOK用語を用意する
  • プロジェクト参加の説得力を付けるために、論述のネタにするプレジェクト事例を決めておく このときの「開発手法」「プロジェクト管理手法」をノートに整理しておく
  • 論述上、プロジェクトが理想どおりゆかない理由を問われたら、自社の責任と するよりも「顧客のせい」(例:頻繁な仕様変更要求)にすると書きやすい

以上

(c)アイ・リンク・コンサルタント



投稿者 kato : 00:01

2005年6月18日

2005年6月18日 未経験者のPM受験1

未経験者がプロジェクトマネージャ試験に合格する方法

ある方から、未経験の人が情報処理技術者試験・プロジェクトマネージャ試験に合格する方法を尋ねられました。そこで、その方を含めて、経験のない方を合格に導く方法を考えてゆこうと思います。

情報処理技術者試験・プロジェクトマネージャ試験の構造

国家試験である限り、日本国の政策があるはずである。もう少し分かりやすい言い方をすると「合格させたい人材像」があるといってよい。だから、どんなにプロジェクトマネージャとしての経験があっても、国が求める人材像とかけ離れたものであったら合格はできない。

逆に、プロジェクトマネージャとしての経験がなくても、国が設定した「プロジェクトマネージャ像」に沿うような人材であることを論文で示せれば、試験に合格することができる。それでは、どのような人材を求めているのだろうか。

プロジェクトマネージャ(以下PM)試験で求められる人材像(推定)

ヒントは平成6年に発行された「高度情報化人材育成標準カリキュラム PMテイスト」CAIT編がある。このほか、IPA

にある人材像から伺えると思います。要点を整理すると次のとおりである。

・システムの完成に全責任をもっている

・プロジェクトの規模はウォーターフォールモデル相当で100ks程度であること

ここからいえることは、「管理職の立場で論述すること」「100人月以上(著者想定)の規模の開発を論述すること」が求められる。

受験勉強の進めるまえの心構えについて

国が求める人材像を満たしつつ、ある程度の経験のあることを示すためにはどうしたら良いかが課題となる。この点については次のように考えている。

・午前・午後Iでは経験を問われない

・特に午前では、ソフト開発程度の知識があればある程度合格ラインに達する

・午後Iでは民法、著作権法などの契約法務的な知識が問われる

・午後IIの小論文では、理想と現実の対比と書き分けが必要である。具体的にはPMBOK(Project Management Body of Knowledge)では、○○といっているが、現実には××という問題がある。従って私は□□の手法で解決したという書き方がよいでしょう

皆さんのご意見をお待ちします

以上



投稿者 kato : 23:12