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

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






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

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

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

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


最近の記事


リンク集




自己紹介など

    くつろぐ

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


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


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

メールフォーム

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

広告エリア2












スポンサーサイト

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

論文対策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日。最終確認をして本番に備えよう。

関連記事
スポンサーサイト

コメント

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

コメントの投稿



管理者にだけ表示を許可する

トラックバック

http://smpman.blog3.fc2.com/tb.php/97-6233e2e7

 | HOME |  ▲ page top


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