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

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






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

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

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

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


最近の記事


リンク集




自己紹介など

    くつろぐ

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


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


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

メールフォーム

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

広告エリア2












スポンサーサイト

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

論文対策2回目 下書き

<平成14年 問2>

1.プロジェクト概要及び業務仕様の変更可能性
1-1.プロジェクト概要
 関東中心に約200店舗を有するA金融機関(以下A行と呼ぶ)は、個人住宅ローンを主力商品の一つとしている。A行では、業務の効率化、顧客サービス向上を目的とし、老朽化した住宅情報システムを再構築することになった。情報処理サービス会社B社の汎用機とA行の各店鋪にある端末を公衆回線で接続する方式から、インターネットを利用したWebベースへと刷新するものである。B社に勤務する私は、プロジェクトマネージャとして全体を統括し、指揮する立場であった。
 プロジェクト成功の条件は、審査チェック機能の品質確保にあった。その理由は、ローン承認までの時間が長いとの苦情に対してA行が審査方法を見直し、今回の再構築に伴って業務仕様を大幅に変更したからである。
1-2.業務仕様の変更可能性
 審査チェック機能は、業務仕様上4つのグループに分かれており、顧客情報、日付情報、資金情報、物件情報の各グループで構成される。私はこのうち資金情報については、開発途中での仕様変更がかなり多くなると予測した。その理由は、約250種類のチェックのうち、半数近くを資金情報が占めているうえ、現行システム開発時にも度々変更した経緯があったからである。
 また、特定の機能ではなくシステム全体に言えることであるが、画面や帳票のレイアウトについても変更が多くなると予測した。再構築にあたり従来の画面をWeb用に作り変える必要がある点について、A行担当者に話を聞いたところ、デザインや操作性を重視したいとの要望が強かったからである。
 以上のことから、今回のプロジェクトは、仕様変更が頻繁に発生する可能性があることを前提として取り組まなければならないと私は認識した。

2.業務仕様の変更についての検討及び対応(設問イ)
2-1.業務仕様の変更に対する検討
 プロジェクト立上げに際して、私は以下に述べる内容について検討した。
(1)ユーザの参画
 ユーザであるA行にとって、業務要件の整理はたいへんな作業になることが想定された。A行全体の業務の効率向上を図りつつ、200店舗すべてのシステム利用者にとって操作性を向上させることは難しい。特に画面の操作性に関しては、利用者の好みや習熟度によって差が出やすいものであるため、なかなか仕様として固まりにくく、度々変更されるものと思われた。このような状況から、私は、開発の途中であってもユーザの要求を聞き取りやすくするため、ユーザを巻き込んで開発を進める体制とすることを検討した。
(2)仕様変更ルールの策定
 A行の参画を前提として、仕様変更を行う際の手続きなど、ルールを決める必要がある。いくら変更が多いと言っても、発生の度に取り込むのは非効率だからである。そこで私は、A行担当者の協力により、いつ、どの機能にどの程度の変更が発生するか可能な限り予測して、仕様変更ルールを策定した。具体的には、週1回の仕様連絡会で、A行から新たな仕様変更依頼書の提示を、開発側B社から前週の案件に対する変更方針の回答を行う形式とした。
(3)変更の実施判定基準
 ユーザからの要求を無条件で受け入れるのではなく、変更を実施するか否かの判断が必要と考える。そこで私は、業務上の重要度、緊急度、変更しない場合の影響、変更作業工数など、幾つかの判定基準に基づいて評価するためのチェックシートを用いて、A行担当者と協議しながら進めていくことを検討した。
2-2.業務仕様の変更要求への実際の対応
 設計工程にはいると、当初予測したとおり、仕様変更が頻繁に発生した。その対応について以下に述べる。
(1)仕様変更ルールの見直し及び改善
 当初は週1回、2時間の予定で連絡会の開催を計画していたが、時間内に報告しきれないため、設計工程に限り週2回に変更した。また、仕様変更依頼書については、会議の当日でなく、依頼発生の都度、A行の担当者から私に受け渡すルールに変更した。事前にどのような変更があるのか質・量を把握し、タイムリーに影響調査を行うためである。さらに、事前に把握することで、会議では報告の時間を最小限に抑え、双方が意見を調整する時間が長く取れることをねらいとした。こうした見直しと改善により、円滑に運営することができた。
(2)判定基準によるユーザとの調整
 変更を実施するか否かの判断は、A行担当者との調整に苦慮した。ユーザとしては少しでも多くの要望を取り込みたいとばかりに、次々と変更依頼を提示してきたが、すべてを実施することは不可能であった。また、前述のチェックシートを用いて可否を判定しようとしても、単純に判定基準に当てはめて評価のできない例外的な案件もあった。そこで私は、B社内部での進捗管理に使うガントチャートを提示しながら、スケジュールに余裕がないため変更実施は難しい旨をA行に説明した。
 しかし調整がつかなかったので、私はA行担当者と協力して変更案件に優先順位をつけ、優先度の高いものに絞って対応することで合意した。例えば、審査チェックのうちで顧客情報と資金情報の連携機能など、業務上重要な案件については追加費用及び追加要員を投入して対応し、特に業務に支障が出ない案件は、変更の延期または中止とすることを決めた。

3.評価および改善点(設問ウ)
3-1.実施活動の評価
 プロジェクトは度重なる仕様変更があったものの、予定していた期限内で完了し、システムは稼働した。変更案件のうち8割は要件定義から設計工程までの間に発生し、残り2割は製造またはテスト工程で発生した。テスト中の変更は避けたかったが、画面のボタン位置や帳票の見栄えなど軽微な変更が多かったため受け入れた。また、2-2で述べた連携機能への変更も実装作業にはいってからの要件であったが、ユーザとの協議により迅速に決断したことが結果的にはよかったと思う。総じて、私の実施した活動は効果的であったと評価する。
3-2.今後の改善点
 開発中の仕様変更については、変更による修正範囲の調査をできるだけ詳細に行う必要があると考える。なぜなら、調査の結果、実現が難しい、現機能への影響が大きい、テスト工数が膨張するなど、様々なリスクが判明する可能性があるからである。したがって、変更要求に対する採用の可否を慎重に決めるため、今回使った判定基準のチェックシートに対し、変更によるリスク要因を追加するなどの改善を加え、有効に活用していきたい。

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

コメント

コメントの投稿



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

トラックバック

http://smpman.blog3.fc2.com/tb.php/86-4b8a1405

 | HOME |  ▲ page top


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