情報処理技術者試験☆合格への道

ライフワークとしての資格取得ブログ presented by Pman






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

にほんブログ村 資格ブログ 国家試験へ にほんブログ村 資格ブログ IT系資格へ
 にほんブログ村 資格ブログへ
 ブログの殿堂
資格・スキルアップ Ranking  ナレコム おけいこブログランキング

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

SEO対策・SEOとは
IT  資格  ブログ
受験  日記  合格  論文


最近の記事


リンク集




自己紹介など

    くつろぐ

  • ニックネーム:Pman
  • プロフィール:
     情報処理サービス会社に勤務。主に金融業のソフトウェア開発、システム運用・保守を担当。メインフレームからオープン系まで広く浅く経験。資格取得はライフワークとなりつつある。
    保有資格
    システム監査技術者
    プロジェクトマネージャ
    アプリケーションエンジニア
    テクニカルエンジニア(システム管理)
    ネットワークスペシャリスト
    情報処理技術者(一種、二種)
    電気通信主任技術者(第一種伝送交換)
    工事担任者(デジタル第1種)


  •  質問、要望、感想、応援などは
     下のメールフォームから、直接
     私あてに送ることができます。


     当ブログはリンクフリーですが、
     リンクした場合は、メール又は
     コメントで知らせていただくと
     ありがたいです。

メールフォーム

名前:
メール:
件名:
本文:

広告エリア2












スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

後ろ向きから前向きへ

 開放感を味わえるはずの時期なのに、そういう気持ちになれない。
 今までであれば、やっと終わった、しばらくのんびり過ごそうなどと思い、好きな本を読んだりしていた。試験のことなどあっというまに頭から消えていったものだが、今回は違った。頭にずっと残っているのだ。いったいどうしてだろう。
 プレッシャーが無かったと言えばウソになる。難関のプロマネ試験とはいえ、これだけ受け続けているのだからそろそろ受からねばという重圧はあった。そして重圧に耐えながらもどうにか最後まで戦い抜いたはよかったが、あとになって、次から次へと論文の内容が頭に浮かんできたのである。あそこの記述はまずかった、ああいうことを書くべきでなかったとか、本当はこういうことを書けばよかったとか・・。

 仕事が忙しければ、こんなふうに思い煩うこともないかもしれないが、皮肉にもこういう時にかぎって忙しくないのである。こうなったら、来年の春試験のことでも考えるしかないのか。ということで、ここ数日は前向きな気持ちに少しはなってきた。

 第1候補 システム監査技術者
 第2候補 テクニカルエンジニア(情報セキュリティ)

つづきはまた次回
スポンサーサイト

試験を振り返って

 今回受験したプロジェクトマネージャ試験について、振り返ってみたい。いま手元に問題がないので、私の記憶だけを頼りにまとめておく。
午前について
 本音を言うと少し意表をつかれた問題もあったが、全体的には無難な問題が多かったと思う。今年から100分55問に増え、セキュリティ分野の問題が増えることも予想したが、さほど目立って出題された感じはなかった。過去の問題をまともにやっていれば大丈夫、という印象は変わらないが、時代の流れと共に少しずつ新しい傾向の問題に移行していることも確かである。(私の結果:ITEC解答速報で46/55。足切りはクリアできそう。)
午後1について
 じつはミスに気がついて少し意気消沈している。冷静に考えれば難しくない設問に対し、何を思ったか取り違えをしてしまった。減点は避けられないが、今更悔やんでも仕方がない。出題内容としては、特に目新しいものもなく、いかにも教科書的というか国家試験らしい、整然とした問題であったと思う。ミスは誰しも多かれ少なかれあるものと割り切って考えたい。(私の結果:問1,3,4を選択。出来は70%とみていたが少し評価を下げて65%程度か。)
午後2について
 問1「重要な関係者とのコミュニケーション」を選択した。今年はセキュリティ関係がまた出題されるかとも思っていたが、やはりプロマネの本職といえば、進捗、品質、コスト、組織要員といった管理分野が基本になることを改めて感じた。ちなみに問2は進捗関係、問3はチーム編成がテーマだった。
 問2は問題文がやや長いうえ難しそうに感じたので、問1と問3を比べたが、事前に考えていたネタを使えそうと判断したのは問1だった(じつは春のシス管も問1選択という縁起を意識した!!)。
 コミュニケーションというテーマが過去にあったかどうか定かでないが、身近なテーマだけに選ぶ人は多かったのではないかと思う。ただし注意深く読んでいくと「直接の管理下にあるメンバ以外の関係者」というような前提条件がある。つまり、プロジェクトメンバ以外のキーパーソンを登場させる必要がある。論文は物語ではないが、登場人物にかかわる状況をよく説明し、わかりやすく描写しないと読み手に伝わらないという意味で、ある種のストーリー展開が求められるかもしれない。
 肝心の出来のほうは、ここ毎回同じことを思うのだが、やはり不満足であった。何とか論文らしい構成になったものの、どうしても具体性に欠けてしまう。それでも、今までの経験から判断すると、そう悪い評価にはならないだろうと感じている。(私の結果:ア:800字、イ+ウ:2000字。量はちょうど良かった。)

 これからしばらくの間は、終わったあとの開放感に浸ろう。

 いくつかミスもあったがご愛嬌。時間がたてば忘れてしまうだろう。

 早くも合格発表の日時が試験センターから発表されていたのには驚いた。

受験報告

 とりあえず、試験を終えての感触だけ報告しておく。

  午前 :8割程度。
  午後1:7割程度。
  午後2:6割程度。合否は極めて微妙なところか。

 論文は、重点的に対策を実施していたものの、やはり本番になると簡単に書けるものではない。春の試験のときと同様に、あとになってから次々とネタが浮かんできたり、文章の構成を考えたりと、後味がよくない。
 きょうは疲れたので、またあとで詳しく振り返ってみようと思う。

試験直前!決意&アドバイス

 いよいよ本番まで3日となり、気持ちも徐々に昂ってきた。このまま試験に突入するのも何だか張り合いがないので、直前特集という意味で、私の決意表明と、受験者へのアドバイスを書いておこう。

(決意)

 思えばこのブログは、昨年までの泥沼状態から始まった。情報処理試験5連敗・・。まったく何もしなかったのであれば納得もいくが、ある程度の勉強をしてこの成績である。確かに、プロマネにしてもシステム管理にしても、そう簡単に取れるものではない。それはよくわかっている。けれども、こう続けて不合格と判定されるのは屈辱だった。悔しかった。もう受験をやめてしまおうかと思ったこともある。でも、やはり悔いが残った。

 何か新しいことを始めよう。そう考えてブログを開設した。何としても連敗から脱出しなければ・・。そして、危機的な状況から抜け出し、システム管理の勉強は軌道にのった。今度こそはいけるかもしれないと半分くらい感じながら春の試験を受けた。結果は合格。うれしかった。年甲斐もなく嬉し泣きをする涙が残っていたことに驚いたのと同時に、この喜びを再び・・という気持ちが湧いた。

 プロマネの勉強を黙々と続けるしか道はない。いまの私にはこの道しか見えないのだ。もう過去のことはどうでもいい。前だけを見て歩いていこう。そう思ううちに、だんだんと論文を書くことが苦痛でなくなってきた。ランナーズ・ハイとはこのことなのか。歩くつもりが、いつの間にか走っている。長距離レースのゴールが近づいてきた。あと少し、あと少しの辛抱。そして、ラストスパート!

 問題に集中しよう!
 最大限の力を出し切ろう!
 最後まであきらめない!
 結果はあとからついてくる!


(アドバイス)

 急にテンションが上がり過ぎるのもどうかと思う。少し冷静になろう。さて、この記事を読んでいる読者の多くが、情報処理試験を受験するであろう。そこで、試験を受けるにあたっての心得みたいなものを残しておく。参考になれば幸いである。

 受験票を忘れない

 こんな当然のことをと笑う人は、きっと顔写真を貼り忘れるだろう。まだ用意していない人は、すぐ用意しよう。ちなみに私は春の試験で撮影したときの残りが1枚あったので、それを使う。縁起がいいかもしれないから。

 鉛筆は多めに持て

 芯が折れたりしたときの予備は必要。シャープペンも同じ。ちなみに私は10年以上前から1ダース(12本入り)の鉛筆を箱ごと持っていくことを続け、いまだにその12本を使い続けている。

 消しゴムは使うな

 持って行くのは構わないが、なるべく消しゴムを使わなくて済むように落ち着いて問題を解こうという意味である。特に論文試験では消しゴムを使うとけっこう時間のロスになるので、慎重に取り組もう。

 早めに会場へ行こう

 これも何度か試験を受けた経験があればわかることだろう。早く着くことによって心に余裕ができる。普段は使わない交通機関を使うのであればなおさらだ。私の場合は、遅くとも30分前、午前9時には会場にはいる。

 座布団を持っていく

 これは昔、会社の先輩に教わった。会場によっては椅子が硬かったり寒かったりする場合がある。小さめの座布団が役に立つ。不必要なら使わなければいいのだ。

 食べ過ぎない、飲みすぎない

 満腹になると眠くなる。飲みすぎるとトイレが近くなる。私の場合、朝は軽め(腹6~7分目くらい)に食べて、昼は意識して少なめ(5分目くらい)でちょうどよい。なお、前日のアルコールは控えよう。これは経験的に言えること。ぐっすり眠るには、酒に頼らず、軽い運動をしたほうがいいようだ。

 できる問題からやる

 これは鉄則。できない問題にいつまでも固執するのはいけない。どのみち満点など取れないわけだし取る必要もない。合格点を取ればいいのである。ただし、冷静に考えられるうちに難しい問題を解くという人もいる。そういう作戦ならば、それはそれでいいかもしれない。

 時間配分に気をつけろ

 これも鉄則。まじめに受けている人にとって、試験時間は一瞬で終わると思ったほうがいい。問題量に対する時間の配分を考えて取り組もう。ちなみに、携帯電話は時計として使えないので、必ず時計を持っていこう。


  では健闘を祈る!

論文対策4回目 修正版

<平成14年 問3>

1.プロジェクト概要及び参画時の状況
1-1.問題発生プロジェクトの概要
 首都圏に約100店舗を有する金融機関(以下ユーザと呼ぶ)では、汎用機による顧客情報システムが老朽化したため、Webベースへ再構築することになった。ユーザ本店のサーバに構築する顧客情報データベースの検索・更新を各店鋪から行うものである。予定工数は250人月、私が勤務するSI企業J社が受託し、機能分割した4つのサブシステム毎にチーム編成されていた。
 当プロジェクトは、稼働開始まであと3ヶ月という時期であり、マスタスケジュールによると本来はシステムテスト工程のはずであった。しかし、進捗は約1ヶ月遅れ、前工程の結合テストがまだ予定の半分しか進んでいなかった。こうした状況に加えて、プロジェクトマネージャのA氏が病気のため長期療養となったので、急遽、私が代役を務めることになった。
1-2.参画した時点でのプロジェクトの状況
 開発現場にはテスト項目表や証跡資料などが山積みされ、整理されていない様子であった。そこで私は、A氏から引き継いだ成果物一覧表に基づいて点検したところ、成果物レビューが行われた形跡(検印など)の無いものが散見される、必要な資料が不足しているなどの不備が判明した。
 また、ユーザに対しては、週1回の会議で進捗状況や品質に関する報告を行う。私は今までの報告資料からテスト項目の消化数およびバグ摘出件数の推移を確認したところ、進捗遅延だけでなく、品質不良の問題もあることを認識した。2つのサブシステムで、結合テストの途中にもかかわらず、バグ件数が既に品質評価の基準値を超えそうな気配であったからである。一部のサブシステムの品質不良は、次工程のシステムテストに悪影響を及ぼすと推定されるため、早急に手を打つ必要がある。

2.問題発生プロジェクトの管理について(設問イ)
2-1.問題点の調査及び原因分析
 上記のような状況では、得てしてバグの早期撲滅など対処的解決を急ぎがちになる。しかし、そうした目先の問題だけに焦点を当てず、なぜこのような状況になったのか、根本的な問題は何かという分析や検証から行わないと、真の解決には至らないと考える。そこで私は、以下の手順で問題点の調査と原因分析に当たった。
(1)問題点の調査方法
 まず私は、各チームの現状を正確に把握するため、J社内部で緊急会議を開催した。そして、各チームリーダに結合テストの未解決バグ数、工程完了時期の見込みなどを報告させた。また、品質管理の実施状況を把握するため、今までに起票したバグ対応票をすべて提出させ、記述内容の精度や妥当性を自ら検証した。
 一方、ユーザ側の責任者であるY氏にヒアリングを実施した。その際に、J社とのコミュニケーション、すなわち報告や連絡の仕方についての実態を聞き出し、率直な意見を求めた。ユーザの観点から、プロジェクトの運営方法に問題がなかったかを探るためである。
(2)原因分析の方法
 進捗の遅れについては様々な原因が考えられたので、特性要因図を利用して分析した。具体的には、各チームリーダや主要メンバーにインタビューし、個人の問題、チームの問題、プロジェクト全体の問題とその原因を挙げてもらい、模造紙上に図示することによって因果関係を明らかにした。そして、これまでのプロジェクト管理に欠落及び不足している事項を加筆し、チームリーダに提示することで、全体の共通認識として確認した。
2-2.明確になった原因
 調査・分析の結果、次の点が明らかになった。
(1)成果物レビューの実施方法が不明確である
 テスト結果資料のレビュー方法が曖昧なため、チーム毎にばらつきが見られた。例えば、リーダ自ら成果物の内容をチェックするチームがある一方で、各メンバーのセルフチェックをもって完了とするチームがあった。このままでは成果物の品質が保証できないと私は考えた。
(2)バグ対応管理が適切に行われていない
 本来は、各リーダが管理しA氏が最終確認する運営方法であった。しかし、リーダ自身も設計や実装に関するバグの調査などに追われ、管理が行き届かなかった。このため、未解決のバグが放置されたり、他のサブシステムに影響する事象の周知や調整が遅れたりしており、それが品質不良を引き起こす要因になっていた。
(3)ユーザへの報告・連絡が遅い
 発見したバグのうち外部設計に関わるものは、早期にユーザへ報告し設計変更などの対応方法を決める必要がある。しかし調査の結果、報告のタイミングが遅く、対応が後手に回っていたことが判明した。これはY氏からの情報でも裏付けられた事実である。このため、再テストの実施など作業の手戻りが多く発生していた。
2-3.実施した対策
 以上の問題点、並びに稼動開始まで3ヶ月しかないことを考慮し、私は以下に述べる対策を実施した。
(1)役割分担の明確化
 チームリーダは、担当するサブシステムの品質を確保する役割を担うと考える。そこで私は、各リーダに対し、個々のバグ対応よりも、チーム全体の成果物レビューや他のチームとの調整を優先させるよう、役割分担を明確にした。そして、TRMに不足していたレビュー項目を追加し周知する、チーム間の調整会議を定例化するなどの改善策を実行した。
(2)ユーザ対応の迅速化と確認
 特に外部設計に関わる改修作業は多くの工数を要することから、私から逐次ユーザへ報告し迅速に対応する方針を、全メンバーに提示した。また、会議の席上で修正点を再確認し、認識ずれの発生を防止した。
(3)段階リリースの検討及びユーザへの折衝
 残作業の工数を見積もった結果、残り3ヶ月で結合テストとシステムテストの完了は不可能であると判断した。そのため私は、最も進捗が遅れている1サブシステムは、やむを得ず稼動開始を遅らせたい旨をY氏へ伝えた。折衝の末、予定時期の1ヶ月後の納期厳守を条件とし段階リリースとすることで承認された。

3.評価及び改善点(設問ウ)
3-1.実施活動の評価
 3サブシステムは計画通りの稼働開始、1サブシステムはその1ヶ月後の稼働開始を遂げた。プロジェクト管理上の問題点を中心に調査と原因分析、改善策を精力的に実行したことで、軌道修正ができたと評価する。
 特に、チームリーダの役割を明確化したことにより、成果物レビューの実施方法が確立し、成果物の機能不備や品質不良が改善できている。最終的なバグ件数は基準値の上限を上回ったものの、収束傾向を示しており、品質は確保できたと判断している。また、ユーザへのヒアリングによりプロジェクト運営上の問題を把握しただけでなく、こうした積極性がユーザとの信頼関係を保つことにつながったと感じている。
3-2.今後の改善点
 危機的な状況を乗り切ったことで貴重な経験であったと思う反面、このようなプロジェクトは二度とあってはならないと考える。のちに復帰したA氏と共に振り返る機会があり、今後の改善点について次のような見解で一致した。
・進捗や品質の状況は、メンバーからの報告を鵜呑みにせず、成果物を提出させるなどしてプロジェクトマネージャ自身の目でも確認する必要がある。
・標準的な管理手法を確立し、メンバー全員に理解させたうえで、適切に実行されているか否かの監視や追跡を続けることが肝要である。


<修正ポイント・考察など>
 問題文の中にくり返し出てくる文言は、その問題のキーワードと捉えるべきだろう。今回の問題でいえば「成果物の機能不備や品質不良」という文言が、設問もあわせて3回も出てくることに気がつく。3回も出てくるキーワードを無視するわけにはいくまい。そのことに注意し、気合いを込めて修正してみた。
 論文は前半が特に大切ということがわかる。後半は手を抜いてもいい、という意味ではない。前半、つまり設問アの後半400字から設問イの初めの400字あたりの書き方がうまくいけば、そのあとも自然な流れで書けるということだ。今回の場合は、設問アの1-2でキーワードをしっかりと入れ、設問イにつなげたことにより、全体として筋の通った論旨の展開ができたと思う。


<スキル基準>
 論文作成において参考になった以下の基準について、復習しておこう。
  プロジェクト追跡と実行管理 3-3 問題管理
  プロジェクト追跡と実行管理 3-6 進捗管理
  プロジェクト終結 5-1 プロジェクト終了状況の確認


あとがき:
 論文対策は、約40日間の厳しい修行のようであった。ときには仕事で疲れきった日もあり、何度か挫折しそうになったが、ここで気持ちを切りたくないという思いで勉強を続けられたことに、悔いはないと感じている。試験日まで残り6日。最終確認をして本番に備えよう。

論文対策4回目 検証

下書き論文の改善メモ

1-1
 設問は「問題発生プロジェクトの概要」なので、ここで問題点について言及しておく必要がある。

1-2
 設問は「成果物の機能不備や品質不良などの状況」なので、それをきちんと書かなければいけない。

2-1
 詳しく書いたつもりだったが、論文というより単なる報告書を読んでいるような気がする。もう少し自分の主張とか考えを入れたほうがいいだろう。

2-2
 ここだけ読めば特に問題なさそうだが、これらの原因によって引き起こされた問題点、つまり「機能不備や品質不良」がきちんと表現されていなかったため、あれ?と感じる。

2-3
 (1)は抽象的すぎる。
 役割分担を明確にするために何をしたのか。もう一声!

3.
 品質向上できたと言える客観的根拠がほしい。
 項番は上記に合わせ3-1、3-2に修正しておく。

 最後の論文対策は、意外に改善すべき点の多い検証結果となった。前回は「徐々に筆がなめらかになってきた」などと評していたが、それは裏を返せば、出題の要求事項から逸脱する恐れもある、ということになる。特に今回の問題は、実際の開発現場でありがちな生々しい状況設定を書きたくなるが、そこだけに注力すると大切なポイントを忘れてしまう。書きやすいと思うテーマほど、じつは落とし穴にはまりやすいことがわかった。注意しよう。

論文対策4回目 下書き

<平成14年 問3>

1.プロジェクト概要及び参画時の状況
1-1.問題発生プロジェクトの概要
 首都圏に約100店舗を有する金融機関(以下ユーザと呼ぶ)では、汎用機による顧客情報システムが老朽化したため、新たにWebベースの新システムを再構築することになった。ユーザ本店の顧客台帳サーバと各店鋪の支店サーバ及びパソコンとの連携により、ユーザと取引のある顧客情報を一元管理するデータベースの検索などを行うものである。開発は、私が勤務するSI企業J社が受託し、予定工数は250人月、機能分割した4つのサブシステム毎にチーム編成されていた。
 当プロジェクトは10ヶ月前に立ち上がり、稼動開始まであと3ヶ月という時期であった。ところが、プロジェクトマネージャのA氏が病気により長期療養となったために、急遽、私が代役を務めることになった。
1-2.参画した時点でのプロジェクトの状況
 私が参画した時期は、マスタスケジュールによると、本来ならばシステムテスト工程のはずであった。しかし、進捗は約1ヶ月遅れており、前工程の結合テストがまだ予定の半分しか進んでいなかった。開発現場にはテスト項目表や証跡資料、バグ対応票などが山積みされていたが、整理されていない様子であり、私は品質に対する不安を抱いた。何人かのメンバーの話によると、プロジェクト開始当初は、A氏を中心に各メンバーが積極的な姿勢で作業に取り組んでいたようであった。ところが、テスト工程にはいった頃から徐々に進捗のペースが落ちていった。現在は、週1回の進捗会議で、品質面についても確認しているが、サブシステム毎にテスト項目の消化数やバグ対応件数の報告を形式的に行うだけで、より踏み込んだ議論には至らないという。
 以上の状況から私は、プロジェクトが抱える問題を解明し、早急に手を打つ必要があると認識した。

2.問題発生プロジェクトの管理について(設問イ)
2-1.問題点の調査及び原因分析
(1)調査の方法
 まず私は、J社内部で各チームリーダを召集し、緊急会議を開催した。そして、各チームの現状を正確に把握するため、結合テストの残項目数、未解決バグ数、工程完了時期の見込みなどを至急報告するよう指示を出した。また、品質を詳細に分析するため、今までに起票したバグ対応票をすべて提出させ、バグ事象や原因、対処の状況、記述の仕方などに注意して自ら確認した。
 一方、ユーザ側の責任者であるY氏にヒアリングを実施した。その際に、進捗や品質の問題だけでなく、J社の開発メンバーとのコミュニケーション、すなわち報告や連絡の仕方についての実態を聞き出し、率直な意見を求めた。ユーザの観点から、プロジェクトの運営方法に問題がなかったかを探るためである。
(2)原因分析の方法
 進捗の遅れについては様々な原因が考えられたので、特性要因図を利用して分析した。具体的には、各チームリーダや主要メンバーにインタビューし、個人の問題、チームの問題、プロジェクト全体の問題とその原因を挙げてもらい、箇条書きで図示することによって因果関係を洗い出した。そして結果を模造紙へ記入し、チームリーダに提示することで再分析し、全体の共通認識として確認しあった。
2-2.明確になった原因
(1)成果物レビューの実施方法が不明確である
 テスト実施後のレビューはスケジュール化されているものの、その実施方法が曖昧なためチーム毎にばらつきが見られた。例えば、リーダ自ら成果物の内容をチェックするチームがある一方で、各メンバーのセルフチェックをもって完了とするチームがあった。このままでは成果物の品質が保証できないと私は考えた。
(2)バグ対応管理が適切に行われていない
 各リーダが管理し、A氏が総括する運営方法であった。しかし、リーダ自身もバグ対応、すなわち設計や実装に関する不具合の調査などに追われ、管理が行き届かなかった。このため、未解決のバグが放置されたり、他のサブシステムに影響する事象の周知や調整が遅れたりして、テストの進行を妨げる要因になっていた。
(3)ユーザへの報告・連絡が遅い
 発見したバグのうち業務仕様に関わるものは、早期にユーザへ報告し仕様変更などの対応方法を決める必要がある。しかし調査の結果、報告のタイミングが遅く、対応が後手に回っていたことが判明した。これはY氏からの情報でも裏付けられた事実である。このため、再テストの実施など作業の手戻りが多く発生していた。
2-3.問題解決策
 以上の問題点、並びに稼動開始まで3ヶ月しかないことを考慮し、私は以下に述べる対策を実施した。
(1)役割分担の明確化
 チームリーダは、担当するサブシステムの品質を確保する役割を担うと考える。そこで私は、各リーダに対し、個々のバグ対応よりも、チーム全体の成果物レビューや他のチームとの調整を優先させるよう、役割分担を明確にした。
(2)ユーザ対応の迅速化
 仕様に関わる作業は多くの工数を要することから、私から逐次ユーザへ報告し迅速に対応する方針を、各リーダはじめ全メンバーへ周知した。
(3)段階リリースの検討及びユーザへの折衝
 想定される残作業の工数を見積もった結果、残り3ヶ月で結合テストとシステムテストの完了は不可能であると判断した。そのため私は、最も進捗が遅れている1サブシステムのみ稼動開始を遅らせたい旨をY氏へ伝えた。折衝の末、予定時期の1ヶ月後の納期厳守を条件とし段階リリースとすることで承認された。

3.評価及び改善点(設問ウ)
(1)実施活動の評価
 3サブシステムは計画通りの稼動開始、1サブシステムはその1ヶ月後の稼動開始を遂げた。プロジェクトは非常に厳しい状況であったが、管理上の問題点を中心に的確な調査と原因分析、解決策を精力的に実行したことで、うまく軌道修正ができたと評価している。特に、チームリーダの役割を明確に打ち出したことにより、各リーダの自覚を促し、プロジェクト全体の品質を均一に向上できたと考えている。また、ユーザへのヒアリングによりプロジェクト運営上の問題を把握しただけでなく、こうした姿勢がむしろユーザとの信頼関係を保つことにつながったと感じている。
(2)今後の改善点
 危機的な状況を乗り切ったことで貴重な経験であったと思う反面、このようなプロジェクトは二度とあってはならないと考える。のちに復帰したA氏と共に振り返る機会があり、今後の改善点について次のような見解で一致した。
・計画時、体制と役割は念入りに検討すべきである。
・進捗や品質の管理はチームリーダに任せた場合でも、必ずプロジェクトマネージャが別な角度から検証する。
・標準的な管理手法を確立し、メンバー全員に理解させることが肝要である。

論文対策4回目 問題

 問題発生プロジェクトへの新たな参画について <平成14年 問3>

 成果物の機能不備や品質不良などによって進捗が遅れているプロジェクトに、プロジェクトマネージャとして新たに参画し、問題を早期に解決する使命を与えられる場合がある。このようなプロジェクトでは、進捗管理や成果物レビューが不十分であったり、要員の士気が低下していたり、顧客との信頼関係が悪化していたりするなどのプロジェクト管理上の問題点が見られることが多い。
 新たに参画したプロジェクトマネージャは、そのプロジェクトの過去の管理方法などにとらわれることなく、新たな観点で問題点の調査や原因の分析などを行うことが重要である。まず、プロジェクトや構築する情報システムの特徴を理解した上で、プロジェクト管理上の問題点を調査する。そのためには、例えば、次のような項目を自ら検証する。
 ・プロジェクトの進捗管理や成果物の品質管理などの実施方法・実施状況
 ・成果物の作成状況やレビュー結果の反映状況
 ・プロジェクト体制や要員配置の状況
 次に、調査結果を基に、プロジェクト管理上の問題点の原因を分析する。この分析は、これまでのプロジェクトの管理に欠落及び不足していると思われる事項を重点的に行う。そして、対策を検討して実施する。例えば、レビューの管理や実施体制に原因があれば、管理帳票や記録帳票などを改訂したり、実施体制を変更したりする。このようにして、これまでの問題点を是正し、成果物の機能不備や品質不良などを早期に解決することが重要である。
 あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。

設問ア
 あなたが新たに参画した問題発生プロジェクトの概要と、参画した時点での成果物の機能不備や品質不良などの状況を、800字以内で述べよ。

設問イ
 あなたは、プロジェクト管理上の問題点をどのように調査し、その原因をどのように分析したか。また、その結果、明確になった原因と実施した対策は何か。それぞれ具体的に述べよ。

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

論文対策3回目 修正版

<平成15年 問3>

1.プロジェクト概要及び立上げ時の問題
1-1.プロジェクト概要
 関東中心に約200店舗を有する金融機関(以下ユーザと呼ぶ)では、経営基盤の強化と基幹業務のコスト削減を目的とし、財務会計システムを開発することとなった。当システムは、インターネットを利用し、ユーザ本店の基幹サーバと各店鋪の支店サーバ及びパソコンとの連携により、財務情報を一元管理するデータベースの検索・更新や帳票出力等の事務処理を行うものである。
 私が勤務する情報処理サービス会社J社は、ユーザの既存システム開発・運用を長年にわたり受託してきた。こうした経緯から、今回の新システム開発も要件定義以降をJ社が一括して受託し、私はプロジェクトマネージャとして全体を統括し、指揮することになった。
1-2.プロジェクト立上げ時の問題
 開発体制を整える段階で、私は問題を抱えていた。2名の要員が、他のプロジェクト(以下、現業と呼ぶ)の期間延長により、すぐに参加できなくなったのである。この2名はユーザ本店で常駐SEの経験があり、金融業の知識が豊富であったため、私は要件定義からシステムテストまでを通して任せるつもりでいた。要件定義は4名で行う計画のため、そのうち2名が参画できないのは致命的であった。この2名に代わる要員も候補として挙げて検討したが、業務知識の面でスキル不足は否めず、私は結局、この2名を現業との兼任という形で、当プロジェクトを立ち上げることにした。
 現業とは、店鋪統合に関わるシステム開発である。私は、上記の2名が兼任であるため、現業の責任者(プロジェクトマネージャ)とプロジェクト間の作業スケジュール調整を入念に行うべきと考えた。また、兼任となる期間はおよそ2ヵ月であり、要件定義の期間と重なるため、何らかのリスク対策が必要である。

2.プロジェクト全体に波及する問題について(設問イ)
2-1.全体に波及すると想定した問題
 一部の要員が兼任でスタートするというリスクによりどのような問題が想定されるのか、以下に述べる。
(1)進捗の遅れ
 一般に要件定義では、調査や分析といった非定型的な作業が中心となるため生産性の見積もりが難しく、綿密なスケジュールを作成しにくい。今回のプロジェクトもその傾向があり、まず曖昧なユーザ要件をいかに明確化するかがポイントになる。こうした状況において兼任で作業する場合、仮に現業でトラブルが発生したとすると、こちらの作業よりもトラブル対応が優先されてしまうのは明らかである。このため、要件定義がなかなか完了せず、そのしわ寄せが後工程に及び、進捗の遅れが顕在化するといった問題が想定された。
(2)費用超過
 進捗が遅れると、遅れを取り戻すために残業時間が増えると予測できる。つまり、プロジェクトにかかる労務費が増加し、これが続くと予算オーバー即ち赤字となってしまうことも考えられる。
(3)品質の低下
 私は、兼任となる2名の力量は十分と見ており、豊富な業務知識に基づく品質の確保を期待した。しかし、現業に多くの時間を費やすと、当プロジェクトの作業に集中できない、成果物の検証やレビューが不十分になるといったことが想定される。さらに、要件定義や基本設計の品質に問題があると、後工程で問題を解消するための多大な工数が必要となる。
2-2.問題発生の兆候の早期発見策
 上記の問題が発生する兆候を早期に発見するため、私は次の各項目について分析した。
(1)兼任している要員の作業負荷
 要件定義の2ヵ月間は、2名の要員が兼任となるため、現業及び当プロジェクトそれぞれの作業負荷を監視する必要がある。現業はシステムテスト中であり、テスト項目数を管理対象としていた。しかし、要員の作業負荷を分析するには、テスト消化状況のほかに作業時間を考慮する必要がある。そこで私は、兼任の2名に作業スケジュール並びに勤務報告書の提出を指示した。現業が過度の負担になっていないか、今後の作業への懸念材料はないか等を分析するためである。具体的には、週単位の労働時間のうち現業に費やす時間が全体の50%を超えた時は危険信号とみなし、作業の調整を行った。一方、要件定義のほうは、定期的に成果物を提出させて進捗状況を確認した。
(2)設計レビューの指摘件数
 要件定義が予定通り完了しても、次の設計工程で品質不良などの問題が顕在化することもあり得る。このため、設計レビューを重視し、レビューでの指摘件数が標準値の範囲から外れていないか分析した。その際、設計書が完成した後では修正作業による手戻りが大きくなるため、設計工程の途中に1~2回の中間レビューを行う計画とした。
 中間レビューでの指摘件数が基準に照らして多すぎる場合は、品質低下の兆候として捉えた。逆に指摘件数が少なすぎる場合は、適切なレビュアーが参加していないため問題が見つけられない、難易度の低い設計部分しか完了していない等の可能性がある。こうした分析により、品質上の問題が拡大する前に適切な処置を施すようにした。

3.評価及び改善点(設問ウ)
3-1.実施活動の評価
 プロジェクト全体に関わる大きな問題もなく、財務会計システムは無事に稼動した。兼任とした2名に関し、現業のテスト結果の検証作業がピークとなり、プロジェクト全体の進捗に影響しそうな時期もあった。しかし、現業の責任者と共に、検証作業を他のメンバーに振り分けるなど作業負荷の平準化とスケジュール調整を行い、当プロジェクトの進捗遅延や費用超過を未然に防止できた。また、設計レビューの指摘件数を工程途中で分析したことにより、品質低下を避けることができた。
 以上の通り、問題発生の兆候を早期に発見できていることから、私の実施した活動は、プロジェクトに対して有効に機能したと評価する。
3-2.今後の改善点
 プロジェクトの初期段階で様々な観点からリスクを識別し、リスク管理を計画的に実行することの大切さを感じた。J社はこのような取り組みが遅れているため、組織的な改善が必要と思われる。したがって、今回のプロジェクトの実績・評価を参考とし、問題管理の方法を標準化及び詳細化し、今後の開発プロジェクトに適用していきたい。


<修正ポイント・考察など>
 問題文にはリスクという言葉は出てこない。しかし、リスク管理を適切に行うプロセスについて述べれば、ほぼ題意に沿った論文になる。リスクそのものを軽減する対策とか、問題が発生した後の解決策などを中心に書いてしまうと、まちがいなくアウトだと思われる。そうではなく、どのようにリスクを分析し、リスクが大きな問題に広がる前に、どのように問題発生の予兆を発見したか、あるいは発見する仕組みを考えたかといった点が問われている。
 そういうところに注意し、何とか書き上げたつもりである。説明が不足している箇所は肉付けし、無駄な部分は削るという、いつものやり方である。
 しかし、あらためて初めから読んでみると、もっと興味深い内容を盛り込めないものかと思う。出題テーマにもよるのだろうが、書いても書いても内容がありきたりなものにしかならないような気がする。もう少し頑張ってみよう。


<スキル基準>
 論文作成において参考になった以下の基準について、復習しておこう。
  プロジェクト計画策定 2-A リスク管理計画
  プロジェクト追跡と実行管理 3-C リスク管理

 | HOME |  ▲ page top


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。