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

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






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

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

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

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


最近の記事


リンク集




自己紹介など

    くつろぐ

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


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


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

メールフォーム

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

広告エリア2












スポンサーサイト

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

論文対策3回目 検証

下書き論文の改善メモ

1-1
 過去2回と異なるプロジェクトを題材にしてみた。様々なネタで書けるようにしておきたいので、これはこれでいいと思う。

1-2
 兼任メンバー2名をどうしても必要とする理由として、業務に精通している事だけでは、やや弱い気がする。もう少し深みを出したい。

2-1
 QCDを意識して忠実に書いてみた。流れとしてはいいが、やや抽象的で説明不足か。もう少し具体的に書きたいところ(特に品質)。

2-2
 「作業負荷」は、あと一息。どのように分析したのかもう一声!
 「レビュー指摘件数」は、ほぼOK。

3-1
 評価もおおむね書けているが、早期に問題を発見できたというニュアンスが欲しい。

 論文対策も3回目で、徐々に筆がなめらかになってきた気がする。本番では2時間で書き切らなければならないので、途中で筆が止まらないよう一気に書く訓練をしておきたい。あとは、プロジェクトマネージャとして専門性を感じさせるキーワードを盛り込む、なるべく定量的な表現をする、といったことに留意すればいいだろう。
スポンサーサイト

論文対策3回目 下書き

<平成15年 問3>

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

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

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

論文対策3回目 問題

 プロジェクト全体に波及する問題の早期発見について <平成15年 問3>

 情報システム開発のプロジェクトでは、顧客側の業務担当者の参加が約束されていなかったり、一部の要員の力量が不足していたり、一部の要員がほかのプロジェクトを兼任しスケジュール調整が難しかったりするなど、部分的に問題を抱えたままプロジェクトマネージャの判断でプロジェクトを立ち上げる場合がある。
 プロジェクトの遂行時には、これらの問題の解決が遅れたり、不十分であったりすることがある。その結果、例えば、要件定義が確定しなかったり、設計品質が低下したり、進捗が遅れたりするなどのプロジェクト全体に波及する問題になることがある。
 プロジェクトマネージャは、プロジェクトの立上げ時に抱えていた問題から波及するおそれがあるプロジェクト全体の問題を事前に想定し、その兆候を早期に発見することが必要である。そのためには、プロジェクトの立上げ時に抱えていた問題に応じて、例えば、次のような項目の傾向を分析することが重要である。
 ・要件に対する質問への回答の遅れ日数
 ・要件定義の変更回数
 ・設計レビューの指摘件数
 ・兼任している要員の作業負荷
 あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。

設問ア
 あなたが携わったプロジェクトの概要と、プロジェクトの立上げ時に抱えていた問題について、800字以内で述べよ。

設問イ
 設問アで述べた問題が解決できない状況において、プロジェクト全体に波及するどのような問題が発生すると想定したかを述べよ。また、どのようにしてその発生の兆候を早期に発見したか、分析した項目とともに、具体的に述べよ。

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

秋期試験の応募者数速報について

 試験センターのサイトで公表されている。ちょっと気休めに見ておこう。
 今回から秋にも受験できるようになったソフトウェア(SW)を除き、すべての試験区分で応募者数が減少している。昨年まで急上昇していた情報セキュリティ(SS)も、ついに減少に転じた。とにかく、全体的に見ても、活気が感じられない数字であることは確かだ。だからと言ってやる気がなくなるわけではないが・・。
 さて、プロマネの数字を挙げておく。
  プロジェクトマネージャ(PM)
   応募者数 14,082
   前年同期 15,883
   増減数  -1,801
 まあこんなものだと思う。ちなみにアプリケーションエンジニア(AE)は今回大きく減少し、プロマネよりも少ない応募者数(12,392)であった。SWに流れたためと推測できるが、それにしても、PMがAEよりも多いことに違和感をもったのは私だけだろうか・・。

論文対策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 変更の実施

論文対策2回目 検証

下書き論文の改善メモ

1-1
 設問アの前半は、前回の修正版からそのままコピーした。しかし、今回のテーマは変更管理なので、品質も大切であるがそれを強調しないほうがいい。

1-2
 立上げ時点で仕様が固まらない理由は設問イの2-1で述べているが、ここで触れたほうがいいかもしれない。
 仕様が確定しないから変更の可能性が高い、というストーリーにする。

2-1
(1)勝手に決めている。ユーザへの協力要請および承認が必要。
(2)ルールを目に見える形にする。手順書、実施要領など。
(3)判定基準をもう少し具体的に。何をもって承認するか。

2-2
(1)実際の仕様書にどのように反映したのか不明。変更ルールだけでは不十分と思われる。
(2)「スケジュールに余裕がないため変更実施は難しい」??
 前文で判定基準に当てはまらないと言っているのに突然スケジュールの話が出るのはおかしい。

3-1
 予測していた資金情報への変更状況について述べていない!
 設問アの1-2と照合させてみる。

3-2
 やや論点がぼやけている気がする。改善すべき点を明白にする。

 思いつくまま挙げてみたが、やはり全体的に、少し雑に書いてしまったようだ。直そうと思えばいくらでも直せるという気がする。もう少しじっくりと読んで研究し、一つ一つのフレーズと全体との整合性に注意し、納得のいくまで推敲を重ねてみよう。

論文対策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.今後の改善点
 開発中の仕様変更については、変更による修正範囲の調査をできるだけ詳細に行う必要があると考える。なぜなら、調査の結果、実現が難しい、現機能への影響が大きい、テスト工数が膨張するなど、様々なリスクが判明する可能性があるからである。したがって、変更要求に対する採用の可否を慎重に決めるため、今回使った判定基準のチェックシートに対し、変更によるリスク要因を追加するなどの改善を加え、有効に活用していきたい。

論文対策2回目 問題

 業務仕様の変更を考慮したプロジェクトの運営方法について <平成14年 問2>

 近年、インターネットを用いた新しいビジネスモデルの構築など、未経験領域のアプリケーションが増加している。アプリケーションによっては、プロジェクトの初期の段階で業務仕様をすべて定義しきれなかったり、早期に凍結できなかったりすることがある。
 このような場合、プロジェクトの立上げに際しては、まず、全体の業務仕様のうち、変更の可能性のある部分とそれらの変更の発生時期を、利用者の協力を得て可能な限り予測することが肝要である。そして、業務仕様の変更に柔軟に対応できるようプロジェクトの運営方法に工夫を凝らす必要がある。そのために、例えば、次のような事項を検討する。
 ・プロジェクトの初期の段階から利用者がプロジェクトへ参画する。
 ・短いサイクルで段階的に開発するなど、変更に強い開発プロセスモデルを採用する。
 ・予想される変更の影響を局所化できるように設計を工夫する。
 ・開発期間、費用に余裕を含めたり、見直し時期や調整方法を顧客と取り決めたりしておく。
 プロジェクトの実行に際しては、個々の変更要求に対して、様々な観点から評価する。例えば、利用部門から見た変更の緊急性や効果、変更しないことによる不便さの度合い、開発部門から見た開発期間や費用への影響などを総合的に判断して、採用の可否を決める。また、必要に応じてプロジェクト体制やスケジュールなどを調整する。
 あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。

設問ア
 あなたが携わったプロジェクトの概要と、プロジェクトの立上げの際に変更の可能性があると予測した業務仕様とその理由を、800字以内で述べよ。

設問イ
 プロジェクトの立上げに際して、業務仕様の変更に柔軟に対応するためにどのような事項を検討したか。また、プロジェクトの実行に際して、業務仕様の変更に対してどのように対応したか。工夫した点を中心に述べよ。

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

論文対策1回目 修正版

<平成13年 問3>

1.プロジェクト概要とテストでの確認項目・判定基準
1-1.プロジェクト概要
 関東中心に約200店舗を有するA金融機関(以下A行と呼ぶ)は、個人住宅ローンを主力商品の一つとしている。A行では、業務の効率化、顧客サービス向上を目的とし、老朽化した住宅情報システムを再構築することになった。情報処理サービス会社B社の汎用機とA行の各店鋪にある端末を公衆回線で接続する方式から、インターネットを利用したWebベースへと刷新するものである。B社に勤務する私は、プロジェクトマネージャとして全体を統括し、指揮する立場であった。
 プロジェクト成功の条件は、審査チェック機能の品質確保にあった。その理由は、ローン承認までの時間が長いとの苦情に対してA行が審査方法を見直し、今回の再構築に伴って業務仕様を大幅に変更したからである。
1-2.テスト段階での確認項目及び判定基準
 私がテスト計画書に盛り込んだ内容を以下に示す。
(1)確認項目
 対象機能を、新規作成分、修正分、再利用分の3つに分けた。そして、個々のプログラムの単体テスト、再利用部分を含むプログラム間の結合テスト、システム全体の総合テストの各工程毎に、テスト項目消化数、不良摘出件数を確認項目とした。なお、プロジェクトの特性を考慮し、審査チェック機能を重点的に管理する。
(2)判定基準
 上記(1)の通り工程毎に目標値を設定したが、最終的な結果だけではなく途中経過も大切である。そこで私は、過去の類似プロジェクトのデータを参考にして、テスト項目消化数と不良摘出件数について、それぞれ日々の予定数を累積グラフで表した。実績値がこのグラフに近い曲線になり、不良の件数が収束していれば、品質は確保されているものと判定する。

2.テスト段階における品質確保の方策(設問イ)
2-1.テスト実施状況
 単体テストでは、テスト項目消化数は予定通りで、不良摘出件数は目標値より10%ほど少なかった。ただし累積グラフは収束傾向を示していたため、品質の判定基準は満たしていると判断した。ところが、結合テスト工程になると、予定していたテスト項目数の半分も消化していない段階で、すでに不良件数が目標値に近づいており、今後も増えると予測できた。私は、品質上の問題があると考え、早急に原因の究明に当たった。
2-2.判定基準を満たさなかった原因の分析・究明
(1)分析方法・分析結果
 審査チェック機能は全部で約250種類の判定ロジックから成り、顧客情報、日付情報、資金情報、物件情報の4グループに分かれる。さらに各グループ毎に単項目チェックと項目間関連チェックに分かれる。そこで私は、どのグループで不良が多いのか傾向を分析するために、パレート図を利用した。分析の結果、資金情報の関連チェックでの不良が、全体の約60%を占めていた。また、詳細設計の記述誤りや記述漏れに起因する不良が半数近くあった。
(2)原因の究明
 以上の結果から、私は資金情報の設計担当者に対し、再度、設計書を確認するよう指示した。また、設計上の不備を発見しやすくするため、業務に詳しい他の担当者にも協力してもらった。その結果、単項目チェック仕様の変更による関連チェック仕様への影響が、完全に洗い出されていなかったことが判明した。資金情報は設計の難易度が高いうえ、仕様変更の頻度が他に比べて多かったことも、不良が多く作り込まれた要因であった。
2-3.分析結果に基づく施策
 原因分析をもとに、私は、当プロジェクトの品質を確保するため、以下に示す対策を実施した。
(1)要員体制の強化
 前述のような不良の傾向や仕様変更への対応が不十分であった根本的な原因は、私自身がプロジェクトの各メンバーの能力を正確に把握できていなかったことにある。このため、要員体制を強化することにした。
 具体的には、審査チェック以外の機能を担当していた2名のメンバーを、資金情報のテスト要員に加えた。この2名は、A行業務の豊富な知識と経験により能力を発揮し、既に自分たちの作業を終えていたからである。私は、増強したメンバーに不良の摘出および不良の除去を集中的に行わせる、あるいは、各機能間の整合性という観点でテスト結果を検証させることにより、システム全体としての品質確保をねらいとした。
(2)ユーザによる仕様確認の交渉
 単項目チェック仕様の変更による関連チェック仕様への影響調査が不足していたことから、私は、品質の安定化のために、ユーザであるA行にも協力を求めるべきと判断した。そのため、外部仕様に関わる影響点を整理してA行へ報告し、設計変更の方針について確認してもらうよう交渉した。この確認が遅れると品質の保証ができないうえテストの進捗が止まり、最悪の場合はシステムの稼動開始が遅れる可能性もあるため、最優先でお願いしたい旨をA行に申し入れた。
(3)テスト方法の効率化
 期間・コスト・資源が限られたテスト工程では、不良を効率的に発見し除去するための工夫が必要になる。そこで私は、テスト方法を見直し、効率向上のための改善を図った。例えば、ある機能で使用したテストデータを別の機能で再利用する、同じような不良がないかを調べる専任メンバを配置する、不良の状況を管理簿にまとめ優先順位の高いものから除去していくなど、様々な対策を実施した。

3.評価および再発防止策(設問ウ)
3-1.実施活動の評価
 限られた期間内で集中的に不良の除去ができ、無事に稼動開始を迎えることができた。結合テストは見直しの影響から、テスト項目消化数が予定より約20%増、不良摘出件数が予定より約15%増という結果であったが、不良累積グラフは収束傾向を示している。また、次工程の総合テストでは、特に問題は見られなかった。
 一方、ユーザによる仕様確認については、交渉の末、A行側の担当者から理解が得られた。その結果、仕様の曖昧な部分が明確になり、短期間で設計品質を向上させることができた。また、テスト方法の見直しにより項目消化のペースが高まった。
 以上のことから、品質は確保できており、私が実施した活動は効果があったと評価している。
3-2.再発防止策
 特定の処理で不良が作り込まれた真の原因は、処理の難易度と要員のスキルを正しく把握できていなかったことによる。また、テスト前に摘出できなかった原因は、個別のチェック機能の設計レビュー時、全体の関連性や影響点という観点が不足していたからである。
 したがって、今後は、適材適所の要員配置や作業量の平準化などに配慮しながら、設計書及びテスト項目のレビューなど事前の検証に力を入れたい。テスト工程に限らず、あらゆる段階において品質を意識したプロジェクトの運営が必要であろう。


<修正ポイント・考察など>
 悪いところだけを部分的に直そうとしても、うまくいかないことがわかった。論述内容に矛盾がなく全体のバランスを考えた構成にするため、結局、全面的に修正を加えることになった。
 もっとも大きな修正点は、2-3(3)を「スケジュール調整」から「テスト方法の効率化」に変えたことである。題意に合わせるための処置であるが、このように修正したことにより、設問ウの評価でも、効率化について触れておく必要がある。
 また、下書きでは具体的な不良の件数を出していたが、数値を書いたからといって必ずしも説得性が増すということにはならない。むしろ、書き過ぎると逆に不自然というか、うそっぽい印象を与える場合もある。したがって今回は、~%というふうにしてみた。
 全体的には、無駄な記述をなくし、無難にまとまった感じがする。ただ、あらためて読んでみると、何だか面白みがない、という印象を受けた。採点者へのアピール効果のあるトピックスや書き方をさらに研究しようと思う。

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

論文対策1回目 検証

下書き論文の悪い点

 設問ア 1.2 
  ・テスト段階の確認項目を明確に示していない。
  ・判定基準も単に数字を出したに過ぎず、基準とする根拠が弱い。

 設問イ 2.3
  ・明らかに論点からずれている。
  ・スケジュール調整と品質管理が結びつかない。

 設問ウ 3.1
  ・累積グラフの収束傾向で評価するなら、アの判定基準で言及すべき。

 ほかにも細かく見るといろいろあるが、以上に挙げた点はおそらく致命的だと思う。あまり深く考えずに書いていたかもしれない。特に、設問アで書くべきことがきちんと書けていないと、そのあとの設問イ、さらには設問ウも、何となく締まりがないというか、論述の展開がうまくいかないようだ。

論文対策1回目 下書き

 私が一昨年に準備していた論文を、ほとんど原文のままアップする。前々回の記事で「これじゃ受からん」と感じた論文である。いったい何がダメなのか考えてみてほしい。これを下書きとして修正したものを、追って掲載する予定。

<平成13年 問3>

1.プロジェクト概要とテスト計画(設問ア)
1.1.プロジェクトの概要
 A社は、個人住宅ローンを主力商品の一つとする金融機関であり、関東中心に約200店舗を展開している。長引く不況の中、A社では経営基盤の強化策として、システムを再構築することになった。再構築の目標は、オンライン端末による審査、承認、決済等の業務を効率化し、顧客サービス向上とコスト削減を図ることである。
 私の勤務するソフトウェア会社B社は、十数年前からA社システム開発を手掛けてきた。そのチーフリーダを経験してきた私は、今回の再構築プロジェクト立ち上げにあたりB社取締役から権限を委譲され、プロジェクトマネージャに任命された。
1.2.確認項目とその判定基準
 当プロジェクトを成功に導くための必須条件は、審査チェック機能の品質確保と考えた。その理由は、住宅ローン申込から承認までの時間がかかり過ぎるとの苦情を受けたA社が、審査方法を簡略化する方針を定め、これをシステム化要件の骨子としたからである。以上を考慮し、私はテスト計画に次の事項を盛り込んだ。
(1)確認すべき項目
 工程完了毎に品質を確認するため、下記レベル毎にテストの不良摘出件数を定めた。また、不良累積グラフを日々更新し、予定実績管理を遂行した。
 1審査チェック機能の改造部分(単体レベル)
 2審査チェック機能の非改造部分(結合レベル)
 3審査チェック機能の他機能連携(全体レベル)
(2)判定基準
 B社開発標準をもとに不良の目標件数を、上記1では63件、2では28件、3では7件と設定した。開発標準では規模当たりの不良件数を定めており、過去の実績から、信頼できる数値であると私は判断した。

2.テスト段階における品質確保の方策(設問イ)
2.1.テスト実施状況
 単体テストは不良55件で完了し、判定基準を満たしたと判断した。この段階で10件以内の増減は許容範囲と設定していたからである。ところが、非改造部分を含む結合テストは、まだ半分を消化していない段階で、不良件数が目標値28件を超えていた。
2.2.判定基準を満たさなかった原因分析
 結合テストの状況から、品質上の問題があると私は考え、早急に原因を分析した。分析方法は、審査チェック機能のどの部分に不良が多いのか傾向を調べるため、パレート図を用いることにした。チェック仕様は、顧客情報、日付情報、資金情報、物件情報の4グループに分かれ、それぞれのグループはさらに単項目チェックと項目間関連チェックに分かれる。これらをパレート図で分析した結果、資金情報・関連チェックでの不良が全体の約7割を占めていた。
 この部分で不良が多い原因を調査するために、私は仕様の再確認を行うよう設計者に指示した。また、仕様の不備を発見しやすくするために、他の有識者にも協力してもらった。調査の結果、単項目チェック仕様の変更による関連チェック仕様への影響が完全に洗い出されていなかったことが判明した。資金情報は変更項目が多いうえに設計の難度が高いことも、不良が作り込まれた要因であると分析している。
2.3.分析結果に基づく施策
 上記の結果から私は、当プロジェクトの品質を確保するために、以下に示す対策を実施した。
(1)体制の見直し
 最初に、プロジェクト体制を見直し再編成を行った。前述のような不良の傾向は、管理者である私が各要員の能力を的確に把握できていなかったことに起因すると考えたからである。
 再編成にあたっては、結合テスト残期間に限り、審査チェック機能に割り当てる要員の増強を図った。増員メンバ2名は、審査チェック以外の他機能を担当していたが、2名とも高スキルであったため、既にテストを完了していたからである。私はこの2名を、作業負荷が大きく難度の高い資金情報に追加した。不良の摘出および不良の除去を集中的に行うためである。さらに、審査チェック機能全体の整合性を確認させることも意図したのである。
(2)仕様の見直しと外部交渉
 前述のように、単項目チェック仕様の変更による関連チェック仕様への影響調査が不足していたことから、仕様の再検討が必要であると考えた。そこで私は、資金情報のテストを中断し、影響調査に専念するよう担当者に指示した。
 影響点のうち、外部仕様に関わるものはすぐにA社へ報告し、仕様を決定してもらうよう交渉した。この決定が遅れるとテストの進捗が止まり、最悪の場合はシステム稼動開始にも影響しかねないため、最優先でお願いしたい旨をA社に申し入れた。
(3)スケジュール調整
 テスト期間は限られていた。結合テストを期限内に終わらせないと、次のシステムテスト工程の開始が遅れることになる。しかし、仕様の再検討、プログラム修正、再テストに費やす時間を見積ったところ、結合テストの完了を10日間遅らせざるを得なかった。一方、システムテスト計画を確認したところ、結合テスト完了が遅れる資金情報に関わる内容は7日目から開始であった。
 そこで、資金情報の代わりに7日目から可能なテスト項目を精査したところ、12日目から開始予定の物件情報に関するテストを前倒しで実施できることが判明した。そして、物件情報の後に資金情報のテストを行っても支障ないため、これらの実施順序を組み替えた。

3.評価および再発防止策(設問ウ)
3.1.実施活動の評価
 仕様上の問題を集中的に検証した結果、外部仕様で2件、内部仕様で7件の不良を摘出できた。以降のテストでは2件摘出し、結合テスト全体では40件となった。これは当初の判定基準28件を超えているが、不良累積グラフは収束傾向を示しており、実質上、品質は確保できたと判断している。テスト後半の高スキル要員投入による不良の早期発見、および、10日間延長による十分な試験項目の消化と確認が功を奏したと考える。
 外部仕様の不良2件は、本来、次工程のシステムテストで発見すべきものであったが、今回の仕様見直しにより机上で発見できたことは大きな収穫であった。その理由は、仮にこの2件が事前摘出されずにテストで発見された場合、作業の大幅な手戻りが発生していたと予測されるからである。
 以上のことから、当プロジェクトにおける品質確保のための活動は、的確なものであったと評価している。
3.2.再発防止策
 特定の処理(資金情報・関連チェック)で不良が作り込まれた原因は、当初の計画で、処理の難易度と要員のスキルに関して正しく分析できていなかったためである。また、テスト前に摘出できなかった理由は、個別のチェック機能の設計レビュー時、全体の関連性や影響点という観点が不足していたからである。これらのことから、今後はプロジェクト計画の段階で「なぜこの体制にしたのか」「なぜこの要員にこの役割を与えたのか」という理由を明確化すると共に、設計レビュー観点の拡大とテスト確認項目の事前検証を特に重視していきたい。
 テスト段階に限らず、あらゆる視点から総合的に判断し、プロジェクトを円滑に運営していくのが私の責務であると考えている。

論文対策1回目 問題

 本日から、論文対策として、私の勉強成果についてアップしていくことにする。1回目は、品質管理をテーマとしたオーソドックスな問題を取り上げる。以降、幾つかのテーマに対して分析・研究した内容を紹介していきたい。

 テスト段階における品質管理について <平成13年 問3>

 システム開発のテスト段階では、開発したシステムが十分な品質を確保しているかどうかを判断するために、確認すべき項目とそれらの判定基準を定め、品質の測定を行う。測定の結果、不良が多い、不良の累積グラフが収束傾向を示さないなど、判定基準を満たさないことがある。このような場合、プロジェクトマネージャは、その原因を分析し、分析結果に基づく対策を実施して、稼動開始日までに品質を確保する必要がある。
 原因分析では、不良が作り込まれた処理や工程を究明するために、パレート分析や特性要因図などの手法が有効である。そして、期間・コスト・資源などが限られたテスト段階では、作り込まれた不良を効率的に除去する必要がある。例えば、原因分析の結果から、特定の処理に不良が多いという傾向が判明すれば、同じような処理を行っているプログラムを机上で点検したり、集中的にテストしたりする。また、テスト方法を変更する、体制を見直すなど、状況に応じた対策も重要である。
 さらに、原因を掘り下げ、再発防止策を検討することが求められる。上記のような場合、特定の処理に不良が作り込まれた原因や、テスト段階前に摘出できなかった理由などを分析し、今後のシステム開発に生かすようにすることが重要である。
 あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。

設問ア
 あなたが携わったプロジェクトの概要と、テスト段階で確認した項目及びそれらの判定基準を、800字以内で述べよ。

設問イ
 テスト段階において品質を確保するために、測定結果が判定基準を満たさなかった原因をどのように分析し、その結果に基づいてどのような対策を実施したか。工夫した点を中心に具体的に述べよ。

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

 | HOME |  ▲ page top


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