2014年04月02日

午後2対策(ネタを仕込んで準備 経験って何ですか?) 情報処理技術者試験プロジェクトマネージャ合格のためにやるべきこと

■ネタを仕込んで準備(経験って何ですか?)



こちらの本にも論文の書き方が書かれています。
だがしかし、この本は、事例集の部分だけを活用します。
参照するのは、事例だけね。



こっちの本で、論文の書き方を学びましょう。
本の内容をブログでなぞるのは意味がないように思います。
本を熟読して、理解してください。

この論述対策本は、モジュール化がキーワードです。
ようは、論述のネタをモジュール(どこにでも組み込めるように)を用意しておく。
問に対応するようにモジュールを当てはめて、論述するという方法です。

経験不足だから、モジュールが用意できないというあなた!
そんな、あなたのために、プロジェクトマネージャ合格論文の書き方・事例集 (情報処理技術者試験対策書)があるのです。
いくつかの気にいった事例から、いいとこ取りでモジュール作成してみましょう。

経験がないは言い訳になりませんよ。 
IPAのプロジェクトマネージャー試験、小中学生が合格  という事実があるのですから、、、、orz

気を取り直して、、、、

私が本の指示に従い用意したモジュールを晒します。

このモジュールで論述したものは、後程紹介します。
★題材モジュール+題材補強用モジュール★

1.題材
・客先A社の設備管理システムのシンクラインアント化プロジェクト

2.体制
・A社利用部門 設備管理部:参画なし レスポンス確認のみ
・A社情報システム部 2名
・B社はA社子会社
・B社の体制
 ・PMの私
 ・共通機能チーム
  リーダー + 2名 計3名 技術部メンバ
  シンクライアントサーバ移植のため業務知識が不要
  技術部の要員にOS移殖のノウハウ蓄積
 ・テストチーム
  設備管理システム保守チームから3名 
  リーダー ベテランSE C氏 、若手2名
 ・シンクライアントミドルウェアベンダー技術者 1名

3.期間
・6か月

4.規模
・30人月 共通 3人×6ヵ月=18人月 ケース設定 3人月 テスト 3人×3ヵ月=9
 ・共通基盤 18機能
  印刷共通、スキャナ共通、共通ログ出力 FD出力機能は廃止
 ・業務機能
  98機能 1機能廃止 EUC用データ抽出機能

5.背景・経緯、目標
・背景・経緯
 クライアント端末リースアップに伴い
 ハードウェアコスト&リリース運用コストの削減できる
 シンクライアント方式にシステム構成の変更
・目標
 ハードのコスト削減
  ・既存 PC 1000台×30万円=3000万円
  ・新システム サーバ 70万×5台 350万円
   + シンクライアントPC 1000台×15万円 1500万円 計1850万円
   1000万円以上のコストダウン
 リリースコストの削減
  ・1000台へリリースが5台でOKの実現
 納期厳守
  ・リース満了日が確定しているため

6.特徴
 ・短納期 既存PCのリース期間満了までに完了が必須
 ・A社情報システム部門主導のシステム構成変更
  現行業務機能に変更がなく、利用部門の参画なし。
 ・シンクライアント化に伴い、クライアントOSで稼働していたプログラムをサーバOS上で稼働するように移植作業を行う。
 ・97全機能を正常パターン、異常パターンでテストする テスト工数が多い。
 ・A社の他クライアントサーバシステム(計18システム)も順次シンクライアント化していく予定
 ・本プロジェクトは、パイロット的な位置づけ。
  B社の製造部門全体を支援する技術部に移殖ノウハウ蓄積をする計画。
  技術部門メンバをプロジェクトに参画させる。

★実施内容アピールモジュール★ <コミュニケーション関連>

▼デイリースクラムの採用
 ・アジャイル開発のメソッドのひとつ。
 ・毎朝、昨日の成果(必須)、本日の目標(必須)、課題(ある場合のみ)をメンバ全員が発表する。
 ・発表内容に対する質疑はこの場ではしない。状況の共有のみとする。これにより、短時間で完了し、時間を無駄にしない。
 ・質疑・検討が必要な場合は別で打ち合わせ等も設ける。
 通常は、週次の進捗会議で進捗を確認していたが、デイリースクラムにより進捗状況や懸念事項の把握がタイムリーに行えるようになった。
 ・メンバからの報告内容が、WBSベースのスケジュールと合致しているかを確認し、相違がある場合には個別に確認・フォローをおこなった。
また、発表された課題は、課題一覧に記載し、対策を個別のミーティングで検討した。
 ・課題とその解決方法をメンバ全員にメールし、共有した。これにより、類似事象で他メンバが時間を取られないようになることを狙った。

▼会話チェック表
 ・メンバとの会話チェック表を作り、もれなく週に一度は直接会話した。
 会話内容、メンバの表情、残業時間などをメモした。気になることがあれば、即時なんらかの対応をした。

★実施内容アピールモジュール★ <ユーザ部門関連>

▼利用部門の参画を要請。
 キーマンを見極め参画を要請。
 利用部門の意志統一や窓口の一本化によるコミュニケーションの効率化を狙った。

★実施内容アピールモジュール★ <利害調整をアピールする内容>

▼レスポンスの目標値
システム構成変更は、情報システム部門の要求であって、利用部門としては関与しない。とにかく、現行機能担保さえしてくれればよいというばかり。
現行担保とは何かを合意しなければ、要求を満たせないと説得し、プロジェクトへの関与を粘り強く要求した。

▼要求仕様の解釈で問題発生 
EUC用データ抽出機能は、廃止という要求仕様。
背景:EUC用データ抽出機能は、条件指定しその条件に合致するデータをFDへ出力する機能。
利用者各自がデータを自由に加工した場合に、誤った観点で集約・加工したデータをお客さまや対外的に提供してしまうことがリスクとなる。このために、EUC用データ抽出機能は廃止し、業務的に必要なものは業務帳票として出力するようにA社内のシステムポリシーが変更された。
EUC用データ抽出機能でしか使用していない共通機能である共通FD出力機能も廃止と判断した。
しかし、共通機能である共通FD出力機能も削除すると要求仕様となっていない。共通FD出力機能は、今後別機能で利用予定があることが発覚した。
運用開始一カ月前に本件が発覚したとして、、、
プロジェクト終盤の1か月は本番移行準備作業を進める必要があり、FD出力共通機能の新システム構成への対応工数を確保は困難。また、新システムの構成上、シンクライアントサーバから営業所のシンクライアント端末のFDへの書き込みをする必要があり、難易度が高い。
FD出力共通機能は、現時点では業務機能で利用していないので緊急性が低い。
FD出力共通機能については、本プロジェクト完了後に、別スケジュールで対応したい旨を申し入れた。
A社からは、リリースタイミングは、別でもよいがFD出力共通機能は、本プロジェクトのスコープであるため、追加費用はB社で負担することを条件に了承された。

★実施内容アピールモジュール★ <マネジメントプロセス関連>

▼スケジュール
 技術部に移殖ノウハウ蓄積をするための施策。
 ノウハウをドキュメント化するタスクをWBS化し、スケジュールに落とし込んだ。

▼リスク想定
 印刷性能の低下 計算センターのシンクライアントサーバで生成された印刷ファイルを営業所まで転送して印刷するため
 スキャナ性能の低下 営業所のLAN上にあるスキャナーで取り込んだ画像を計算センターのシンクライアントサーバで処理し、シンクライアント端末に転送し表示させるため
 クライアントOSとサーバOSの非互換
 対策:開発環境を早期に準備し、代表業務機能で事前確認。WBS化して確実実施。
 不具合発生時の検討要員として、シンクライアントミドルウェアベンダーの技術者への相談窓口を確保した。また、相談では解決しない場合を想定し、技術者派遣のコストをコンティンジェンシー予備費として部門長に許可を受け計上した。

▼リスクの回避
・システム構成変更対応 と 新規機能の追加 を同時にやらない。
 OS移殖の問題なのか新規機能の問題なのかの切り分けを明確化する。

▼スコープ 非機能要件
 利用部門の要求 レスポンスは、現行担保
 高負荷時なのか 平常時なのか
 そもそも 高負荷、平常時とは何を指すか?
 現行機能を調査して、数値化して合意するアプローチとした。


ネタを仕込んで準備(経験って何ですか?) は、ここまで、続く

午前対策
午後1対策

目次 午後2対策
準備編
事例を読む
書いてみる
ツールにこだわれ
採点者目線を意識
論述式じゃない実は記述式
こんなアプローチ
ネタを仕込んで準備(経験って何ですか?) ← 今ここ
■書いてみたよ その1
■書いてみたよ その2

kakobon at 23:12│Comments(0)TrackBack(0)

トラックバックURL

コメントする

名前
URL
 
  絵文字