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

ライフワークとしての資格取得ブログ 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ベースの新システムを再構築することになった。ユーザ本店の顧客台帳サーバと各店鋪の支店サーバ及びパソコンとの連携により、ユーザと取引のある顧客情報を一元管理するデータベースの検索などを行うものである。開発は、私が勤務する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氏と共に振り返る機会があり、今後の改善点について次のような見解で一致した。
・計画時、体制と役割は念入りに検討すべきである。
・進捗や品質の管理はチームリーダに任せた場合でも、必ずプロジェクトマネージャが別な角度から検証する。
・標準的な管理手法を確立し、メンバー全員に理解させることが肝要である。

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

コメント

コメントの投稿



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

トラックバック

http://smpman.blog3.fc2.com/tb.php/95-86a9a67b

 | HOME |  ▲ page top


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