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

ライフワークとしての資格取得ブログ 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行責任者(以下Y氏)に確認したところ、デザインや操作性を重視したいとの意向であった。こうした要求は、システム利用者個人の好みや操作習熟度に左右されるため、仕様として固まりにくいと考えられる。このことから、画面や帳票のレイアウトについても全体的に変更が多くなると予測できた。
 以上のことから、当プロジェクトは変更の発生を前提として取り組まなければならないと私は認識した。

2.業務仕様の変更についての検討及び対応(設問イ)
2-1.業務仕様の変更に対する検討
 プロジェクト立上げに際して、私は以下に述べる内容について検討した。
(1)ユーザへのプロジェクト参画の要請
 今回のプロジェクトでは、仕様の凍結時期を決めることが難しく、私は開発作業を進めながら仕様を確定していく構想を描いていた。つまり、開発の途中であってもユーザの要求を聞き取りやすくするため、ユーザを巻き込んで開発を進めることが容易な体制を作っておく必要がある。このため、Y氏に対し、仕様変更に関する私の構想を伝えたうえで、プロジェクトへの積極的な参画と協力を要請した。その結果、Y氏から承認が得られ、共同体制による開発がスタートした。
(2)仕様変更ルールの策定
 А行の参画を前提として、仕様変更を行う際の手続きなど、ルールを決める必要がある。予想以上に変更が多くなることも想定し、混乱を回避するためである。そこで私は、Y氏との協力により、いつ、どの機能にどの程度の変更が発生するか可能な限り予測して、仕様変更ルールを策定した。具体的には、週1回の仕様連絡会で、A行から新たな仕様変更依頼書の提示を、開発側B社から前週の案件に対する変更方針の回答を行うルールとした。また、管理・運営のための作業フローや手順書を準備し、関係メンバー全員に配布した。
(3)変更の採否判定基準及び判定方法
 ユーザからの要求を無条件で受け入れるのではなく、変更を実施するか否かの判断が必要になる。そこで私は、業務上の重要度、緊急度、変更しない場合の影響、変更作業工数など、幾つかの判定基準に基づいて評価するためのチェックシートを用いて、Y氏をはじめ各関係者と協議しながら進める方針とした。採否の決定は前述の仕様連絡会で行い、必要に応じて専門的な知識や技術を有するメンバーも参加させ、多角的な視点から判定することにした。
2-2.業務仕様の変更要求への実際の対応
 設計工程にはいると、当初予測したとおり、仕様変更が頻繁に発生した。その対応について以下に述べる。
(1)仕様変更ルールの見直し及び改善
 当初は週1回、2時間の予定で連絡会の開催を計画していたが、時間内に報告しきれないため、設計工程に限り週2回に変更した。また、仕様変更依頼書については、会議の当日でなく依頼発生の都度、Y氏から私に受け渡すルールに変更した。事前にどのような変更があるのか質・量を把握し、タイムリーに影響調査を行うためである。さらに、事前に把握することで、会議では報告の時間を最小限に抑え、双方が意見を調整する時間を長く取れるように工夫した。こうした見直しと改善により、遅滞なく変更要求に対応することができた。
(2)変更案件の優先順位づけ
 限られた期間や費用ですべての変更案件を実施することは不可能であった。また、前述のチェックシートでは評価しにくい例外的な案件もあった。そこでY氏と検討した結果、変更案件に優先順位をつけ、優先度の高いものに絞って実施することで合意した。例えば、審査チェックのうちで顧客情報と資金情報の連携機能など、業務上重要な案件については変更を実施し、業務への影響が小さい案件は、変更の延期または中止とすることを決めた。
(3)変更案件の滞留防止
 私は、案件管理簿により変更要求の実施、一部実施、保留、延期、中止という状態を管理していた。しかし徐々に「保留」や「延期」が増えてきたことを危惧した。一般に開発の後工程になるほど、変更による作業負荷が高くなるからである。このため、保留または延期の場合は必ず決定期限を決め、変更案件の滞留を防止するよう関係者に周知のうえ厳密に管理した。

3.評価・改善点(設問ウ)
3-1.実施活動の評価
 開発中の変更要求は100件を超えたが、プロジェクトは予定していた期間内で完了した。プロジェクトの初期段階からユーザの参加を働きかけたことで、業務仕様の変更に柔軟に対応できたと考える。ユーザとの調整に苦慮する場面もあったが、後日Y氏から「共同体制が成功の要因」との評価を得た。また、当初の予測通り、審査チェック・資金情報への変更は全体の60%と多かったが、仕様変更ルールを確立し、判定基準による客観的な判断を行ったことで、プロジェクトを適切に運営できたと思う。以上のことから、私の実施した活動は効果的であったと評価する。
3-2.今後の改善点
 開発中の仕様変更については、変更による修正範囲の調査をできるだけ詳細に行う必要があると考える。なぜなら、調査の結果、実現が難しい、現機能への影響が大きい、テスト工数が膨張するなど、様々な問題が判明する可能性があるからである。そういった調査の掘り下げや、変更によるリスク分析がやや甘かったと認識している。この点は、今回使った判定基準のチェックシートにリスク項目を追加するなどの改善を加え、今後のプロジェクトで有効に活用していきたい。


<修正ポイント・考察など>
 設問アの前半はプロジェクト概要を素直に書けばいいが、そうは言っても、出題テーマを意識した文言を少しでも含めておくと、あとが書きやすくなるようだ。そして設問アの後半であるが、ここは重要な部分である。
 下書きでは、設問イのはじめのほうで「利用者の好みや習熟度による」という言葉を使っていた。しかしこれは、仕様変更がたびたび発生する源となるキーワードになるので、設問アではっきりと書いておくべきと考えた。
 さらに、単にユーザ担当者でなくY氏という人物を登場させることによって、論文全体にリアリティーというか生々しさを感じさせるように修正してみた。人物描写が多すぎるとよくないが、協力してプロジェクトを運営したというニュアンスを表現するには効果的である。
 全体的には、読み手になるほどと思わせる内容にまとめたつもりだが、何となくまだ物足りないと感じている。もっと深く追求していこう。もっと様々な視点から書いてみよう。


<スキル基準>
 論文作成において参考になった以下の基準について、復習しておこう。
  変更管理
  4-1 変更要求の把握
  4-2 変更内容の分析と評価
  4-3 変更の承認
  4-4 変更の実施

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

コメント

コメントの投稿



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

トラックバック

http://smpman.blog3.fc2.com/tb.php/88-cc91a7da

 | HOME |  ▲ page top


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